Jerry Avins wrote: (snip)> stop-bit time is an approximate minimum -- approximate because receive > and send clocks might be a few percent apart. There is no maximum time. > Stuttering is allowed.>> The baud rate for RTTY by the way is 45.45 baud. This will almost >> certainly mean you'll have a non-integer number of samples which very >> slightly complicates things.Since there is a few percent tolerance on the clock, you might as well assume there is always an non-integer number of samples. The UART will resync. on each start bit.>> If you're using a PC to decode, an easy >> option is to use floating point for your clock and when you reset >> without a state change, subtract the floating point number of samples >> per bit from the counter rather than zeroing it.There are a lot of problems that should not be done in floating point, and I would add this one. -- glen
FSK modem: bit/timing recovery
Started by ●January 23, 2007
Reply by ●January 25, 20072007-01-25
Reply by ●January 26, 20072007-01-26
Howard Long wrote:> "DSP-Newbie" <No@way.invalid> wrote in message > news:mn.c2ab7d715664af75.59994@way.invalid... >> RTTY mostly uses Baudot 5 bit code, + 1.5 start & 1 stop bit. > > Now you've got my memory working, I believe it's 1 start and 1.5 stop. I > must admit I'd forgotten about using 1.5 bit times for a stop for RTTY. > > The baud rate for RTTY by the way is 45.45 baud. This will almost certainly > mean you'll have a non-integer number of samples which very slightly > complicates things. If you're using a PC to decode, an easy option is to use > floating point for your clock and when you reset without a state change, > subtract the floating point number of samples per bit from the counter > rather than zeroing it.That's pretty close to 1KHz/22, not very hard to get with most clocks. For simplicity's sake, I usually clock at 16x, but 11 or 22 is also alright. A 1KHz clock will divide each transmitted bit into 22 parts. If that's too busy, sample the signal every 2 ms, using 2 0f three samples at the presumed middle of the bit, counting from the start bit. That will be pretty robust. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●January 27, 20072007-01-27
Howard Long wrote:> "DSP-Newbie" <No@way.invalid> wrote in message > news:mn.c2ab7d715664af75.59994@way.invalid... >> >> RTTY mostly uses Baudot 5 bit code, + 1.5 start & 1 stop bit. > > Now you've got my memory working, I believe it's 1 start and 1.5 stop. I must > admit I'd forgotten about using 1.5 bit times for a stop for RTTY. ><mode=blushing> Hmmm... you're absolutely right! </>> The baud rate for RTTY by the way is 45.45 baud. This will almost certainly > mean you'll have a non-integer number of samples which very slightly > complicates things. If you're using a PC to decode, an easy option is to use > floating point for your clock and when you reset without a state change, > subtract the floating point number of samples per bit from the counter rather > than zeroing it.Actually, 50/75/100 baud are also common. 45.45 is mostly used by radioamateurs.
Reply by ●January 27, 20072007-01-27
Howard Long wrote:> "DSP-Newbie" <No@way.invalid> wrote in message > news:mn.c2ab7d715664af75.59994@way.invalid... >> RTTY mostly uses Baudot 5 bit code, + 1.5 start & 1 stop bit. > > Now you've got my memory working, I believe it's 1 start and 1.5 stop. I > must admit I'd forgotten about using 1.5 bit times for a stop for RTTY. >Yes, the 1.5 (or even 2) stop bits allowed time for a clutch to drop out and then pull in again on the early mechanically-decoded machines.> The baud rate for RTTY by the way is 45.45 baud. This will almost certainly > mean you'll have a non-integer number of samples which very slightly > complicates things. If you're using a PC to decode, an easy option is to use > floating point for your clock and when you reset without a state change, > subtract the floating point number of samples per bit from the counter > rather than zeroing it. > > Howard > >With only 5 data bits and a stop bit the maximum timing allowed is around 8 per cent. Clocking for 45.0 Baud introduces 1 per cent error which will have a negligible effect on the error rate. Regards, John
Reply by ●January 28, 20072007-01-28
John Monro wrote: (snip regarding fractional baud rates and floating point)> With only 5 data bits and a stop bit the maximum timing allowed is > around 8 per cent. Clocking for 45.0 Baud introduces 1 per cent error > which will have a negligible effect on the error rate.One percent should be fine. I wonder why they quote them accurately. The IBM 2741 runs at something close to 134.5 baud, which is not a convenient fraction for any baud rate generator, but close enough in any case. The character rate is supposed to be close to 14.8, full speed for the selectric typewriter printing mechanism. -- glen
Reply by ●January 28, 20072007-01-28
glen herrmannsfeldt wrote:> John Monro wrote: > > (snip regarding fractional baud rates and floating point) > >> With only 5 data bits and a stop bit the maximum timing allowed is >> around 8 per cent. Clocking for 45.0 Baud introduces 1 per cent error >> which will have a negligible effect on the error rate. > > One percent should be fine. I wonder why they quote them accurately. >My guess is that it may have originated from the gearing of the mechanical decoding mechanism, relative to the speed of a 50 or 60 Hz synchronous motor driving the teleprinter. I am not really confident of this explanation though, because the only teleprinter I have examined closely used an AC universal motor with an centrifugal speed regulator that could be adjusted over a range of at least ten per cent. Regards, John> The IBM 2741 runs at something close to 134.5 baud, which is not a > convenient fraction for any baud rate generator, but close enough in > any case. The character rate is supposed to be close to 14.8, > full speed for the selectric typewriter printing mechanism. > > -- glen >
Reply by ●January 29, 20072007-01-29
John Monro wrote: (snip regarding fractional baud rates and such)> My guess is that it may have originated from the gearing of the > mechanical decoding mechanism, relative to the speed of a 50 or 60 Hz > synchronous motor driving the teleprinter. I am not really confident of > this explanation though, because the only teleprinter I have examined > closely used an AC universal motor with an centrifugal speed regulator > that could be adjusted over a range of at least ten per cent.I do wonder some about the mechanical systems like the ASR33, if you run them at just slightly slower than full speed such that the clutch is just releasing and then pulls in again how well it works. I don't believe the 2741 works the same way, though I am not so sure about it. -- glen
Reply by ●January 29, 20072007-01-29
glen herrmannsfeldt wrote:> John Monro wrote: > > (snip regarding fractional baud rates and such) > >> My guess is that it may have originated from the gearing of the >> mechanical decoding mechanism, relative to the speed of a 50 or 60 Hz >> synchronous motor driving the teleprinter. I am not really confident >> of this explanation though, because the only teleprinter I have >> examined closely used an AC universal motor with an centrifugal speed >> regulator that could be adjusted over a range of at least ten per cent. > > I do wonder some about the mechanical systems like the ASR33, if you > run them at just slightly slower than full speed such that the clutch > is just releasing and then pulls in again how well it works. I don't > believe the 2741 works the same way, though I am not so sure about it.I believe that the ASR33 and 35 used synchronous motors. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●February 1, 20072007-02-01
Hello Glen "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:n6SdnU5oTc9Z6STYnZ2dnUVZ_sCinZ2d@comcast.com...> Jerry Avins wrote: > > (snip) > >> stop-bit time is an approximate minimum -- approximate because receive >> and send clocks might be a few percent apart. There is no maximum time. >> Stuttering is allowed. > >>> The baud rate for RTTY by the way is 45.45 baud. This will almost >>> certainly mean you'll have a non-integer number of samples which very >>> slightly complicates things. > > Since there is a few percent tolerance on the clock, you might as > well assume there is always an non-integer number of samples. > The UART will resync. on each start bit. >Well, you are totally right, assuming we do, as I am sure we do in this case, few symbols/frame and plenty of samples/symbol.>>> If you're using a PC to decode, an easy option is to use floating point >>> for your clock and when you reset without a state change, subtract the >>> floating point number of samples per bit from the counter rather than >>> zeroing it. > > There are a lot of problems that should not be done in floating > point, and I would add this one. > > -- glen >Glen, I respect your comment, but could you expand as to why not? Not a flame - a technical Q that could change the way I am doing things on a project right now. Thanks. Cheers, Howard
Reply by ●February 3, 20072007-02-03
Howard Long wrote: (snip)>>Since there is a few percent tolerance on the clock, you might as >>well assume there is always an non-integer number of samples. >>The UART will resync. on each start bit.> Well, you are totally right, assuming we do, as I am sure we do in this > case, few symbols/frame and plenty of samples/symbol.(snip)>>There are a lot of problems that should not be done in floating >>point, and I would add this one.Well, the easiest way is that floating point should be used for quantities that have a relative uncertainty, and fixed point for ones that have an absolute uncertainty. Many physical measurements have a relative uncertainty, that is the uncertainty in measuring increases as the quantity increases, or at least that is all that is needed. This is often true of length and time measurements over many orders of magnitude. For others the uncertainty stays constant, or only varies over a small number of orders of magnitude. This is usually true for money. I expect my checking account balance to the cent, even if I have tens of thousands of dollars. It does surprise me sometimes to see a house priced at $499,999, where $500,000 is only 0.0002% more, though they could do $499,999.99. Baud rate generation is usually done by taking a crystal oscillator and dividing it down using a programmable counter. -- glen
