Thanks Hans,
Your code will give me another project to experment with after I get my board made.
Currently waiting for 3.3v regulators.
I see in the aprs.spin you are using the level method for RX without the feedback resistor, and you have the audio dc biased to mid supply.
Is this what you would recomend for APRS?
CK
I just build the easiest configuration and it works just fine. But I can imagine that there are better ways. I am thinking about adding a LM358 so I use the discriminator output of my tranceiver.
Modems, RS-232, and the phone system have always been fascinating reading for me.
In particular I've been quite interested in reading about the various RS-232 signals in the past like... RI - Ring Indicator, RTS/CTS - Request to send/Clear to send, CD - Carrier Detect, DTR - Data terminal ready, etc. Interesting to read the history of these signals.
"Error detection" and "error correction" are quite interesting. (Parts of a message can be garbled in transmission and the other end can reconstruct the message with error correction!)
And something interesting about modems and phone systems is that phone systems have an "Echo" when you are talking and there are "echo suppressors" which cut this portion of the conversation out. But this wrecks havoc with modems trying to send information both ways at the same time. So a certain frequency that modems send will "turn off" the echo suppression on a phone connection.
Hans, I tried downloading your zip file and using it in the prop software, but it turns up weird in the software. It just has one file "aprs" with no ext.
-Larry KI6ZQY 73's to all
Capdiamont said...
Hans, I tried downloading your zip file and using it in the prop software, but it turns up weird in the software. It just has one file "aprs" with no ext.
I've had a similar issue lately downloading from the forum if a filename has any spaces in it. Have you tried renaming it with the correct extension first?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
Phil: I was just looking at the circuit at the top of the page. Couldn't the PTT interface be simplified by removing 1 resistor and the transistor and making P23 an OC driver such that it outputs GND for PTT (inverted from now) and is made an input when not?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The OC transistor isolates the Prop from high voltages that might be present in the transceiver. Also, without it, the Prop end of the resistor would never be lower than 3.9V, due to the protection diodes, even when the pin it's connected to is programmed as an input. This may be low enough to cause current to flow into the series resistor and force the transceiver to be transmitting all the time.
A little demonstration of the APRS decoder (using VGA output). Still needs a lot of work. I will post an updated version later.
Regards,
Hans
Well,
I suppose I should throw out what I've been working on as well in case a synthesis of our work may be useful. I have gotten stuck solving some synchronization issues.
I took a decidedly different approach toward implementation, aiming for the implementation of a KISS TNC first, before attempting to handle APRS packets.
I had noticed that transmissions that I started decoding at random alignment sometimes did not decode, so part of the mess in my code is from trying to work through this problem.
I also changed around the method for changing the noise, slice, and hysteresis so as to free up a bit in the status register that I used to indicate the detection of a flag to to the SPIN wrapper from the assembler module.
The archive I'm attaching is not a propeller tool archive, which I know may draw some complaints. It is a dump of my work in progress and includes some things that I found I could not easily include in such an archive. One of these is my modified version of Jason Wood's CRC routine so that it could calculate the CCITT 16bit CRC. I have also included several versions of my aprs_phy code. This dump also includes a modified modem_monitor.spin to match up with my local version of the modified monitor I posted back to the forum a few months ago.
I am quite sad to see that this thread has been dormant for almost a year. I am very keen to get AX.25 working using the Bell 202 object. So I decided to tackle the problem myself. Does anybody have the energy, or interest, to help troubleshoot my (almost working) code. Or has someone achieved this already?
Thanks for a great object! Its working well with legacy Bell 202's for me in an application.
Question though - I'm trying to program up some arbitrary waveform generators to simulate "ideal" and AWGN-corrupted signals to get a handle on achievable bit error rate.
For the object (and Bell 202 in general), is this the correct sequence of events for a valid signal?
Assert mark for ~50ms
Assert space as a start bit
Transmit 8 bits, LSB first
Assert mark as a stop bit
Are the start and stop bits the same length as the data bits? Do I have the polarities correct? And ... am I missing an odd parity bit?
I've read such standards as there are available on the web for 202 AFSK, but remain a little confused!
Each character consists of a start bit (space), 8 data bits (1=mark, 0=space), and one or two stop bits (mark). The 50 ms mark is for the beginning of each transmission to establish a carrier, not for each character. As to parity, that will be protocol-dependent and, AFAIK, is not part of the Bell 202 specification.
Many thanks; things are working very well right now. It will be a while before I get some concrete results but the code looks very solid from a standpoint of performance in AWGN.
Congrats Phil!
On your Ticket and the awesome project! It's funny, I just started searching for the answer to a need for a custom caller ID box and I found this.
It is hardware design from the 1980s and contains some fascinating design features that appear to be well suited to port over to the Propeller.
The first feature is a "scrambler". This means the currently transmitted bit is the EXOR of the current data bit, plus the bits that were transmitted 12 and 17 bits earlier. This means a stream of all 1's comes out a pseudo random pattern that has an equal number of 1s and 0s which gives DC balancing, as well as some other benefits explained in the article.
The other rather clever mathematical trick is to create a pulse that fits into the bandwidth. Internet searches can lead into some complex maths with nyquist filtering, and perhaps the best description is the second picture on this site http://en.wikipedia.org/wiki/Raised-cosine_filter showing how a pulse starts off as a small wavy line, then turns into a big pulse, then goes back to a small wavy line.
One of these pulses is a bit of data. You overlay that with bits before and after, deliberately smearing out the bit. So a bit might overlap with 4 bits before and 4 bits after. So that is 9 bits and you can use a lookup table to work out all 512 combinations of those bits and what the waveform would look like in each case. In the hardware solution, they used an eprom with the waveforms preprogrammed and sent it out through a DAC. The propeller would do this so well in software. It might even be fast enough to generate the waveform on the fly.
I had to read the article a few times to get the gist of it, bit it is a really clever solution to squeeze more data through a noisy channel.
I like the way the final result sounds almost like noise. And how the impulse response looks similar to the waveform of a photon. Maybe intergalactic lifeforms use such a system to communicate?! Or more to the point, I hope SETI are not just looking for boring carrier wave modulated data because an advanced alien civilisation would always be trying to squeeze more data out of the available bandwidth.
But it does strike me as some rather beautiful maths that could be transform many chips into something that would run nicely on the propeller. I think the hardware solution was working in 8 bits but you could smear out a data bit over more bits - eg 16 and fit that in a 64k lookup table which is well within the various external ram solutions for the prop. Or a compromise, maybe a 4k lookup table which smears it out over 12 bits.
I'm still getting my head around all the maths. Thoughts would be most appreciated.
Drac: Did you read the SFT (s... fourier transform). There was a link in the whats new section, first 2 pages yesterday. Its a 10-100 times faster FT. This should be a real boost to doing software modems and radios at much higher speeds. IIRC the Rockwell modem ICs for up to 33.6K were a pair of 12MHz DSPs. A prop should be able to beat this easily provided one can get the algorithms right.
im sorry if this is a silly question or if this has been discussed somewhere in this long thread.
i just saw this project last night for the first time, it should definately get more exposure these are the kind of things that make the prop just awesome, i mean it may as well be a 7 dollar fpga. anyways i few weaks ago i saw an article about using the video genarator to wirelessly transmit over uhf. would there be any technical or legal issues with making prop based uhf modems
I am looking for a circuit design that would let me interface the (U.S. based analog) phone line to the Propeller. I'd like to use the modem object to read the CallerID information. Can anyone point me to a design that will show me the basics for converting the levels appropriately so that I can accomplish this without causing any problems to the phone line or to the prop?
I've been looking at this problem for a couple of weeks, on and off. I've been studying the phone line voltage levels while ringing, and when providing CallerID data. I found that the ring signal was greater than 60v, but I wasn't able to get a solid read on the amplitude of the data portion which occurs after the first ring. I saw the data on my scope, but never managed to dial in the amplitude settings just right to get a valid answer. It's not clear to me yet what voltage level it is, and if it needs to be reduced to 3.3v levels, or if it's already too low and needs to be amplified to 3.3v levels. (Of course more time with my scope will reveal this) I'll have to take a more careful look and spend more quality time with the scope. There was only so much time I was willing to take the house phone out of service while I did my testing. :-)
I have a 600ohm 1:1 isolation transformer at the ready. It looks like a lot (but not all) telephone to micro device used these isolation transformers, so I picked one up. Of course, I've seen a few DSP based designs that didn't use any visible transformer at all.
I'm sure there are a variety of circuits that would work. This is just for experimentation... could use some guidance on getting it right.
Joel, What you want is called a DAA (data access arrangement). This is a type-approved interface between the phone line and some logic (and analog stuff). These used to be made with an isolation transformer and some opto-isolators along with some analog stuff. Mostly it detects the ring signal, can take the phone line off-hook, and limits the audio energy put back on the phone line from the DAA. It also protects the user equipment from power surges on the phone line and the phone line from unreasonable voltages in the user equipment.
Thanks for the replies. I see that the Cermtek part referred to is no longer readily available, but now I know to look for other DAA's instead. Mouser has a variety of them, so I'll see if something looks similar to the Cermtek part.
It would be great if there was a way to do this using off the shelf discreet components. I'll study this some more and see what I can figure out about it. If not, I'll go for a DAA integrated circuit and play with that.
One thing you may consider is finding a computer with an AMR slot, and an AC'97 interface. Under Linux, you can access the phone line as an audio device, and that's how the modem actually works. All processing is done on the host side.
Well I haven't done much. I don't have a transceiver to dedicate. Budget kind of thing.
I got wind of OpenTrac in APRSSIG email list. Seems simpler, and I was able to decode some of the specification sheet examples using Basic Stamp. The stamp cannot generate AFSK. The prop backpack looks ideal to me for APRS/OpenTrac. Can the prop backpack be used as is?
Why do we not use more than two tones to represent more than just ones and zeros? If we could detect sixteen different tones, we could send a nib with a single tone(MFSK?)
What is the limit for vhf/2m? With 70cm/UHF being on a secondary for hams in the US, I would like to see the speed pushed on VHF. However greater bandwidth comes with higher frequency.
For instance 9600 is usually done in 70cm, and 1200 usually done in 2m.
Comments
For the last few weeks I have been working on a AX25/APRS decoder with this object. Let me know when you are interested.
Regards,
Hans
Yes, a AX25/APRS decoder would be neat to experment with on ham packet.
Do you have a working prototype?
Fred (VE7DEP)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
________________________________
Work:www.vhf.ca··Play:www.Costalegre.ca
A little demonstration of the APRS decoder (using VGA output). Still needs a lot of work. I will post an updated version later.
Regards,
Hans
Your code will give me another project to experment with after I get my board made.
Currently waiting for 3.3v regulators.
I see in the aprs.spin you are using the level method for RX without the feedback resistor, and you have the audio dc biased to mid supply.
Is this what you would recomend for APRS?
CK
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
________________________________
Work:www.vhf.ca··Play:www.Costalegre.ca
I just build the easiest configuration and it works just fine. But I can imagine that there are better ways. I am thinking about adding a LM358 so I use the discriminator output of my tranceiver.
Hans
Post Edited (TheRaven) : 5/24/2010 6:52:41 AM GMT
In particular I've been quite interested in reading about the various RS-232 signals in the past like... RI - Ring Indicator, RTS/CTS - Request to send/Clear to send, CD - Carrier Detect, DTR - Data terminal ready, etc. Interesting to read the history of these signals.
"Error detection" and "error correction" are quite interesting. (Parts of a message can be garbled in transmission and the other end can reconstruct the message with error correction!)
And something interesting about modems and phone systems is that phone systems have an "Echo" when you are talking and there are "echo suppressors" which cut this portion of the conversation out. But this wrecks havoc with modems trying to send information both ways at the same time. So a certain frequency that modems send will "turn off" the echo suppression on a phone connection.
Here is a bit on that...
http://en.wikipedia.org/wiki/Echo_cancellation
-Larry KI6ZQY 73's to all
I think you'll have to use a different unzipper.
Regards,
Hans
I've had a similar issue lately downloading from the forum if a filename has any spaces in it. Have you tried renaming it with the correct extension first?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I mean, if I went around sayin' I was an emperor just because some moistened bint had lobbed a scimitar at me they'd put me away!"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Well,
I suppose I should throw out what I've been working on as well in case a synthesis of our work may be useful. I have gotten stuck solving some synchronization issues.
I took a decidedly different approach toward implementation, aiming for the implementation of a KISS TNC first, before attempting to handle APRS packets.
I had noticed that transmissions that I started decoding at random alignment sometimes did not decode, so part of the mess in my code is from trying to work through this problem.
I also changed around the method for changing the noise, slice, and hysteresis so as to free up a bit in the status register that I used to indicate the detection of a flag to to the SPIN wrapper from the assembler module.
The archive I'm attaching is not a propeller tool archive, which I know may draw some complaints. It is a dump of my work in progress and includes some things that I found I could not easily include in such an archive. One of these is my modified version of Jason Wood's CRC routine so that it could calculate the CCITT 16bit CRC. I have also included several versions of my aprs_phy code. This dump also includes a modified modem_monitor.spin to match up with my local version of the modified monitor I posted back to the forum a few months ago.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--RvnPhnx
Thanks for the help, guys
Thanks for a great object! Its working well with legacy Bell 202's for me in an application.
Question though - I'm trying to program up some arbitrary waveform generators to simulate "ideal" and AWGN-corrupted signals to get a handle on achievable bit error rate.
For the object (and Bell 202 in general), is this the correct sequence of events for a valid signal?
Assert mark for ~50ms
Assert space as a start bit
Transmit 8 bits, LSB first
Assert mark as a stop bit
Are the start and stop bits the same length as the data bits? Do I have the polarities correct? And ... am I missing an odd parity bit?
I've read such standards as there are available on the web for 202 AFSK, but remain a little confused!
V/R
Mike
-Phil
Many thanks; things are working very well right now. It will be a while before I get some concrete results but the code looks very solid from a standpoint of performance in AWGN.
V/R
Mike
On your Ticket and the awesome project! It's funny, I just started searching for the answer to a need for a custom caller ID box and I found this.
Once Again, Congrats!
It is hardware design from the 1980s and contains some fascinating design features that appear to be well suited to port over to the Propeller.
The first feature is a "scrambler". This means the currently transmitted bit is the EXOR of the current data bit, plus the bits that were transmitted 12 and 17 bits earlier. This means a stream of all 1's comes out a pseudo random pattern that has an equal number of 1s and 0s which gives DC balancing, as well as some other benefits explained in the article.
The other rather clever mathematical trick is to create a pulse that fits into the bandwidth. Internet searches can lead into some complex maths with nyquist filtering, and perhaps the best description is the second picture on this site http://en.wikipedia.org/wiki/Raised-cosine_filter showing how a pulse starts off as a small wavy line, then turns into a big pulse, then goes back to a small wavy line.
One of these pulses is a bit of data. You overlay that with bits before and after, deliberately smearing out the bit. So a bit might overlap with 4 bits before and 4 bits after. So that is 9 bits and you can use a lookup table to work out all 512 combinations of those bits and what the waveform would look like in each case. In the hardware solution, they used an eprom with the waveforms preprogrammed and sent it out through a DAC. The propeller would do this so well in software. It might even be fast enough to generate the waveform on the fly.
I had to read the article a few times to get the gist of it, bit it is a really clever solution to squeeze more data through a noisy channel.
I like the way the final result sounds almost like noise. And how the impulse response looks similar to the waveform of a photon. Maybe intergalactic lifeforms use such a system to communicate?! Or more to the point, I hope SETI are not just looking for boring carrier wave modulated data because an advanced alien civilisation would always be trying to squeeze more data out of the available bandwidth.
But it does strike me as some rather beautiful maths that could be transform many chips into something that would run nicely on the propeller. I think the hardware solution was working in 8 bits but you could smear out a data bit over more bits - eg 16 and fit that in a 64k lookup table which is well within the various external ram solutions for the prop. Or a compromise, maybe a 4k lookup table which smears it out over 12 bits.
I'm still getting my head around all the maths. Thoughts would be most appreciated.
i just saw this project last night for the first time, it should definately get more exposure these are the kind of things that make the prop just awesome, i mean it may as well be a 7 dollar fpga. anyways i few weaks ago i saw an article about using the video genarator to wirelessly transmit over uhf. would there be any technical or legal issues with making prop based uhf modems
I've been looking at this problem for a couple of weeks, on and off. I've been studying the phone line voltage levels while ringing, and when providing CallerID data. I found that the ring signal was greater than 60v, but I wasn't able to get a solid read on the amplitude of the data portion which occurs after the first ring. I saw the data on my scope, but never managed to dial in the amplitude settings just right to get a valid answer. It's not clear to me yet what voltage level it is, and if it needs to be reduced to 3.3v levels, or if it's already too low and needs to be amplified to 3.3v levels. (Of course more time with my scope will reveal this) I'll have to take a more careful look and spend more quality time with the scope. There was only so much time I was willing to take the house phone out of service while I did my testing. :-)
I have a 600ohm 1:1 isolation transformer at the ready. It looks like a lot (but not all) telephone to micro device used these isolation transformers, so I picked one up. Of course, I've seen a few DSP based designs that didn't use any visible transformer at all.
I'm sure there are a variety of circuits that would work. This is just for experimentation... could use some guidance on getting it right.
Thanks for your help.
Joel
Here's one commercial device.
After reading what he had to say, I decided to take his advice and hack a cell phone (the hard way).
Thanks for the replies. I see that the Cermtek part referred to is no longer readily available, but now I know to look for other DAA's instead. Mouser has a variety of them, so I'll see if something looks similar to the Cermtek part.
It would be great if there was a way to do this using off the shelf discreet components. I'll study this some more and see what I can figure out about it. If not, I'll go for a DAA integrated circuit and play with that.
Thanks to both for writing back.
Joel
I got wind of OpenTrac in APRSSIG email list. Seems simpler, and I was able to decode some of the specification sheet examples using Basic Stamp. The stamp cannot generate AFSK. The prop backpack looks ideal to me for APRS/OpenTrac. Can the prop backpack be used as is?
Why do we not use more than two tones to represent more than just ones and zeros? If we could detect sixteen different tones, we could send a nib with a single tone(MFSK?)
What is the limit for vhf/2m? With 70cm/UHF being on a secondary for hams in the US, I would like to see the speed pushed on VHF. However greater bandwidth comes with higher frequency.
For instance 9600 is usually done in 70cm, and 1200 usually done in 2m.
Dstar is 4800 on 2m and 70cm, 128k on 23cm
I have a question about the aprs decoder soft of post #64
I use it and it works .
Now I want to use multiple aprs receivers on one Propeller, but stuck after 2 with memory size.
In the aprs.spin the RBUFSIZE = 4096 eating all the memory.
I can't resize it , output go to junck after couple of seconds. Even with original demo
My reciver buffer size need a max of 200 bytes.
I try to get 4 aprs receivers to one serial in one prop.
Is there somebody who can give me a clue why ?
Thanks
Ltech