On Dec 12, 7:46�am, Mark Borgerson <mborger...@comcast.net> wrote:> In article <rufgc89c170lh0o16ddk022rrsrhgq5...@4ax.com>, robertwessel2 > @yahoo.com says... > > > > > > > > > On Tue, 11 Dec 2012 23:43:54 -0800, Mark Borgerson > > <mborger...@comcast.net> wrote: > > > >In article <nh8gc81516b289uhcdla34qrm3d1dhm...@4ax.com>, robertwessel2 > > >@yahoo.com says... > > > >> On Tue, 11 Dec 2012 21:22:45 -0800 (PST), j.m.granvi...@gmail.com > > >> wrote: > > > >> >On Saturday, December 8, 2012 3:17:16 AM UTC+13, Ivan Shmakov wrote: > > >> >> BTW, is there an easy way to autodetect the baud rate while > > >> >> using an AVR UART? > > > >> >Most AutoBaud designs also send a known character to calibrate, and a pause. > > > >> > If you want to auto-detect on random data, that is more complex, and you will (usually) discard info while you are deciding. Then, even if your hardware is smart enough to quickly lock onto a bit-time, you next have to decide which is actually the Start bit... > > > >> > So there is no magic solution, but you can make systems that behave in a known way, reliable. > > > >> It's impossible to make baud autodetection 100% reliable without the > > >> cooperation of the sender. �Consider that at 8-N-1, the single byte > > >> 0xB5 is indistinguishable from the pair 0x67, 0x67 at double the baud > > >> rate. �Hardly the only such example, just a handy one. �For a simple > > >> doubling of the baud rate at 8-N-1, an indistinguishable pair of bytes > > >> exists at the higher baud rate for any byte where the fourth bit (from > > >> the high end) is one and the fifth is zero at the lower baud rate. > > > >I think that's true if you define " without cooperation" �to mean that > > >the receiver has absolutely no prior knowledge of the message from > > >the sender and the data stream is continuous with no significant > > >inter-character intervals. �If you know that the data is ASCII > > >text in a given language, you probably have enough �data to get > > >the baud rate correct, given a large enough sample size. > > > >It the data stream is encrypted �binary data in a continuous > > >stream, you've got more to worry about than just the baud rate! > > > I'd consider sending a known (or at least constrained) stream to be > > cooperation. �Obviously the tighter the constraints, the more quickly > > you can get to a required confidence level in your baud rate > > detection. > > > As for inter-character gaps - it depends on the speeds and characters > > in question - so long as the low speed characters meet the xxx10xxx > > format requirement, then the double speed stream simply looks like two > > immediately adjacent characters, and gaps between individual low speed > > characters are just gaps between high speed pairs. > > > My point was more that automatic baud rate detection is a hack, albeit > > a useful one in some circumstances, although it will always have > > limits. �And frankly the use of RS-232/async ports should not be a > > first choice these days. > > I still find them useful when connecting to oceanographic instruments. > I have been able to get full-speed usb (12mb) through a pair of > waterproof connectors, despite the impedance problems. �I haven't > yet tried to get USB through the connector and 20meters from the > deck to the dry lab on a research vessel. �I've also tried > Zigbee radios, but they run into problems with aluminum pressure > cases and deckhouses.I don't get it. If you got a hole for RS232 cable, you certainly can run an (water-proof) antenna through the case. 20 meters is no big deal for 802.15.4 (or ZigBee).> > One advantage that serial ports have over USB is that, with > a properly designed receiving system, you have controlled > latency that can allow time-stamping of incoming data. �That's > more difficult with USB or radio links where the data gets > mashed together into packets and the reception time has little > relation to the transmission time.Yes, it's difficult to time-stamp the receiving end, but you can always time-stamp the transmitting end. We put timing data in the packet itself.
baud rate autodetection on AVR 8-bit?
Started by ●December 7, 2012
Reply by ●December 12, 20122012-12-12
Reply by ●December 12, 20122012-12-12
On Wed, 12 Dec 2012 10:50:32 -0800 (PST), linnix <me@linnix.info-for.us> wrote:>On Dec 12, 7:46�am, Mark Borgerson <mborger...@comcast.net> wrote: >> >><snip> >> >> One advantage that serial ports have over USB is that, with >> a properly designed receiving system, you have controlled >> latency that can allow time-stamping of incoming data. �That's >> more difficult with USB or radio links where the data gets >> mashed together into packets and the reception time has little >> relation to the transmission time. > >Yes, it's difficult to time-stamp the receiving end, but you can >always time-stamp the transmitting end. We put timing data in the >packet itself.That's nice for some purposes, not nice for others. For example, if you are designing an instrument (which is what I do for work) that may be part of a closed loop control system (such as, for example, a GaAs boule puller) then time stamps do NOT HELP you at all. What matters entirely is the rigorous repeatability of the phase delay of measurements and smaller loop times. You want a very short loop and zero variance in the measurement timing (a delay cannot be avoided, but what you need _most_ is no variation of that delay -- it must be the exact same value every time, if possible.) Jon
Reply by ●December 12, 20122012-12-12
In article <a643e02a-fa5f-41de-a83e-5bb572f2e0c7 @i7g2000pbf.googlegroups.com>, me@linnix.info-for.us says...> > On Dec 12, 7:46�am, Mark Borgerson <mborger...@comcast.net> wrote: > > In article <rufgc89c170lh0o16ddk022rrsrhgq5...@4ax.com>, robertwessel2 > > @yahoo.com says... > > > > > > > > ><<SNIP>> > > I still find them useful when connecting to oceanographic instruments. > > I have been able to get full-speed usb (12mb) through a pair of > > waterproof connectors, despite the impedance problems. �I haven't > > yet tried to get USB through the connector and 20meters from the > > deck to the dry lab on a research vessel. �I've also tried > > Zigbee radios, but they run into problems with aluminum pressure > > cases and deckhouses. > > I don't get it. If you got a hole for RS232 cable, you certainly can > run an (water-proof) antenna through the case. 20 meters is no big > deal for 802.15.4 (or ZigBee).There is limited space on the end caps for new holes. There is already a hole for power and RS-232/USB which needs to be there as the power is plugged/unplugged at that connector. It's also more than a hole---it's an underwater bulkhead connector that costs about $100 and has to hold pressures up to 5000PSI. That last requirement is a step above "waterproof". Next there's the problem of getting the signals through the aluminum or steel bulkheads and watertight doors. Another issue with Zigbee is configuring the radio addresses so that the host communicates with the proper instrument. That's a bit more complex than plugging in the connector and selecting COM1.> > > > > One advantage that serial ports have over USB is that, with > > a properly designed receiving system, you have controlled > > latency that can allow time-stamping of incoming data. �That's > > more difficult with USB or radio links where the data gets > > mashed together into packets and the reception time has little > > relation to the transmission time. > > Yes, it's difficult to time-stamp the receiving end, but you can > always time-stamp the transmitting end. We put timing data in the > packet itself.That is the case with most instruments I've designed in the last decade. Oceanographic instruments have long service lifetimes. The one I am redesigning now was first operated in 1990. It used clocks, counters and CMOS logic state machines to feed data from an ADC to a UART and up an RS-485 cable about 500m to the surface. The data was streamed in 2- byte pairs at near the cable capacity at 115KB. Since there was no RTC in the subsurface system, the surface program was responsible for time- stamping the data, merging it with GPS data, and recording. My goal for the near-term replacement of the subsurface instrument is to be able to use the same surface software----which means duplicating the timing of the old instrument. Mark Borgerson
Reply by ●December 12, 20122012-12-12
On Wed, 12 Dec 2012 12:42:50 -0800, I wrote:>exact same value every timeexact same delay every time Jon
Reply by ●December 12, 20122012-12-12
>On Wed, 12 Dec 2012 10:50:32 -0800 (PST), linnix ><me@linnix.info-for.us> wrote: > >>On Dec 12, 7:46�am, Mark Borgerson <mborger...@comcast.net> wrote: >>> >>><snip> >>> >>> One advantage that serial ports have over USB is that, with >>> a properly designed receiving system, you have controlled >>> latency that can allow time-stamping of incoming data. �That's >>> more difficult with USB or radio links where the data gets >>> mashed together into packets and the reception time has little >>> relation to the transmission time. >> >>Yes, it's difficult to time-stamp the receiving end, but you can >>always time-stamp the transmitting end. We put timing data in the >>packet itself.Time stamping at the source helps in many situations, however, you _need_ a reliable timing generator at the source. Of course, if the source device is connected to a good GPS or IRIG time source, things should be pretty easy. However, if you have to synchronize the local clock at the signal source over the same serial link, there are a few pitfalls, mainly to various jitter sources. In order to avoid these jitters in serial communication, you may have to use something like NTP (Network time protocol) adapted for serial links, in order to average out jitter in individual synchronization attempts over the serial link. Of course, the NTP principle assumes equal propagation delay in both direction, which can usually be achieved in serial communication.
Reply by ●December 12, 20122012-12-12
On Wed, 12 Dec 2012 23:22:54 +0200, upsidedown@downunder.com wrote:> >>On Wed, 12 Dec 2012 10:50:32 -0800 (PST), linnix >><me@linnix.info-for.us> wrote: >> >>>On Dec 12, 7:46�am, Mark Borgerson <mborger...@comcast.net> wrote: >>>> >>>><snip> >>>> >>>> One advantage that serial ports have over USB is that, with >>>> a properly designed receiving system, you have controlled >>>> latency that can allow time-stamping of incoming data. �That's >>>> more difficult with USB or radio links where the data gets >>>> mashed together into packets and the reception time has little >>>> relation to the transmission time. >>> >>>Yes, it's difficult to time-stamp the receiving end, but you can >>>always time-stamp the transmitting end. We put timing data in the >>>packet itself. > >Time stamping at the source helps in many situations, however, you >_need_ a reliable timing generator at the source. > >Of course, if the source device is connected to a good GPS or IRIG >time source, things should be pretty easy. > >However, if you have to synchronize the local clock at the signal >source over the same serial link, there are a few pitfalls, mainly to >various jitter sources. > >In order to avoid these jitters in serial communication, you may have >to use something like NTP (Network time protocol) adapted for serial >links, in order to average out jitter in individual synchronization >attempts over the serial link. > >Of course, the NTP principle assumes equal propagation delay in both >direction, which can usually be achieved in serial communication.In Jon's application, the communications link is part of the control loop. It's the actual jitter on that that's the problem - it doesn't matter how accurately you time when the datum was produced at the device, the controller, at the other end of the communications cable can't generate a response until that datum actually shows up. A USB isochronous pipe might fit the application, although certainly not at the distances he's talking about.
Reply by ●December 12, 20122012-12-12
On Wed, 12 Dec 2012 15:39:28 -0600, Robert Wessel <robertwessel2@yahoo.com> wrote:>On Wed, 12 Dec 2012 23:22:54 +0200, upsidedown@downunder.com wrote: > >> >>>On Wed, 12 Dec 2012 10:50:32 -0800 (PST), linnix >>><me@linnix.info-for.us> wrote: >>> >>>>On Dec 12, 7:46�am, Mark Borgerson <mborger...@comcast.net> wrote: >>>>> >>>>><snip> >>>>> >>>>> One advantage that serial ports have over USB is that, with >>>>> a properly designed receiving system, you have controlled >>>>> latency that can allow time-stamping of incoming data. �That's >>>>> more difficult with USB or radio links where the data gets >>>>> mashed together into packets and the reception time has little >>>>> relation to the transmission time. >>>> >>>>Yes, it's difficult to time-stamp the receiving end, but you can >>>>always time-stamp the transmitting end. We put timing data in the >>>>packet itself. >> >>Time stamping at the source helps in many situations, however, you >>_need_ a reliable timing generator at the source. >> >>Of course, if the source device is connected to a good GPS or IRIG >>time source, things should be pretty easy. >> >>However, if you have to synchronize the local clock at the signal >>source over the same serial link, there are a few pitfalls, mainly to >>various jitter sources. >> >>In order to avoid these jitters in serial communication, you may have >>to use something like NTP (Network time protocol) adapted for serial >>links, in order to average out jitter in individual synchronization >>attempts over the serial link. >> >>Of course, the NTP principle assumes equal propagation delay in both >>direction, which can usually be achieved in serial communication. > >In Jon's application, the communications link is part of the control >loop. It's the actual jitter on that that's the problem - it doesn't >matter how accurately you time when the datum was produced at the >device, the controller, at the other end of the communications cable >can't generate a response until that datum actually shows up.Exactly. The analogy I like to use is this: Imagine you need to poke a long, thin, flexible bamboo rod into the entry hole of a bird house. You only get to hold the rod at the end and the hole is at your eye level 50' away. Now generalize this idea for the above: the length of the pole is the loop delay. It is easier to do if the pole is short. VERY MUCH easier, in fact. Distance makes a LOT of difference -- it's non-linear. Then also, now imagine that the length of the pole is varying all over the place as you try? The less variation in length there is, the easier the job is. No variation is best, even if you are stuck with a very long pole -- because you can design an algorithm that can anticipate the flexing, at least. But if the length is shifting almost at random, it greatly complicates any attempt to design such an algorithm. Of course, it's dead easy to design an algorithm with a short rod. The changes in control at your hand are immediately reflected and so it's child's play then. Anyway, that kind of gets the idea across. Time stamping will tell you what you might have wanted to have done. But it is useless 20/20 hindsight. Your GaAs boule has huge ripples and you are wasting lots of money in your process and you start looking for a different solution and you fire those who couldn't understand how to do a proper closed loop control design.>A USB isochronous pipe might fit the application, although certainly >not at the distances he's talking about.I think I don't know enough about USB to comment here. Yes, I read through much of the over 1000 pages of the USB 2.0 document -- not entirely enjoying it, either. But I seem to recall that the shortest timer on the host side is set at 1ms. And I honestly don't know how that translates into allowable variability -- but I suspect it means a need to plan that much, 1ms, variability. And even then, it might be worse under circumstances I'm not well informed about being as ignorant as I am about USB nuances. RS-232 isn't "great guns." It's still serial. But with RS-422 for example I can at least get fairly quick transfers of data and at precision intervals that are as known and as predictable as the crystal clocks I'm using to time them. I will usually select a processor with fixed (or very small variability in) latencies relative to timer interrupt events -- the ADSP-21xx processor for example has zero variability (if it isn't busy with interrupts locked out, of couse) in its interrupting response. These things can be important, at times. Jon
Reply by ●December 12, 20122012-12-12
On Wed, 12 Dec 2012 15:13:51 -0800, I wrote:>I think I don't know enough about USB to comment here. Yes, I >read through much of the over 1000 pages of the USB 2.0 >document -- not entirely enjoying it, either. But I seem to >recall that the shortest timer on the host side is set at >1ms. And I honestly don't know how that translates into >allowable variability -- but I suspect it means a need to >plan that much, 1ms, variability. And even then, it might be >worse under circumstances I'm not well informed about being >as ignorant as I am about USB nuances.Not to mention variability in managing USB packets and all of the conditional code whose branch edges (different branch pathways) do not all execute in exactly the same number of cycles so that there is a fixed delay which can be planned on. Compilers do NOT provide a method to force fixed timing through all code edges, either.>RS-232 isn't "great guns." It's still serial. But with RS-422 >for example I can at least get fairly quick transfers of data >and at precision intervals that are as known and as >predictable as the crystal clocks I'm using to time them. I >will usually select a processor with fixed (or very small >variability in) latencies relative to timer interrupt events >-- the ADSP-21xx processor for example has zero variability >(if it isn't busy with interrupts locked out, of couse) in >its interrupting response. These things can be important, at >times.In the case of simple serial communications, I can much more easily arrange equal timing in all branches of the rather short and simple code, by inspection. So I can guarantee, to the cycle, that there is no variability. Which is good. Jon
Reply by ●December 12, 20122012-12-12
On Wed, 12 Dec 2012 15:13:51 -0800, Jon Kirwan <jonk@infinitefactors.org> wrote:>>A USB isochronous pipe might fit the application, although certainly >>not at the distances he's talking about. > >I think I don't know enough about USB to comment here. Yes, I >read through much of the over 1000 pages of the USB 2.0 >document -- not entirely enjoying it, either. But I seem to >recall that the shortest timer on the host side is set at >1ms. And I honestly don't know how that translates into >allowable variability -- but I suspect it means a need to >plan that much, 1ms, variability. And even then, it might be >worse under circumstances I'm not well informed about being >as ignorant as I am about USB nuances.USB 2.0 has service intervals down to 125us, isochronous transfers reserve bandwidth slots. With USB 3.0 ("Superspeed"), I think the guaranteed jitter is 200ns, It's higher than that for hi-speed, but I don't remember the value. In most cases it's going to be the software stack that's going to be the limiting factor on jitter. The audio guys seem to be slightly unhappy, apparently wanting 100ns jitter guarantee.>RS-232 isn't "great guns." It's still serial. But with RS-422 >for example I can at least get fairly quick transfers of data >and at precision intervals that are as known and as >predictable as the crystal clocks I'm using to time them. I >will usually select a processor with fixed (or very small >variability in) latencies relative to timer interrupt events >-- the ADSP-21xx processor for example has zero variability >(if it isn't busy with interrupts locked out, of couse) in >its interrupting response. These things can be important, at >times.There are certainly advantages to a very lightweight stack. OTOH, it doesn't sound like you application would really ever make any use of automatic baud rate detection.
Reply by ●December 12, 20122012-12-12
On Wed, 12 Dec 2012 18:41:45 -0600, Robert Wessel <robertwessel2@yahoo.com> wrote:>On Wed, 12 Dec 2012 15:13:51 -0800, Jon Kirwan ><jonk@infinitefactors.org> wrote: > >>>A USB isochronous pipe might fit the application, although certainly >>>not at the distances he's talking about. >> >>I think I don't know enough about USB to comment here. Yes, I >>read through much of the over 1000 pages of the USB 2.0 >>document -- not entirely enjoying it, either. But I seem to >>recall that the shortest timer on the host side is set at >>1ms. And I honestly don't know how that translates into >>allowable variability -- but I suspect it means a need to >>plan that much, 1ms, variability. And even then, it might be >>worse under circumstances I'm not well informed about being >>as ignorant as I am about USB nuances. > >USB 2.0 has service intervals down to 125us, isochronous transfers >reserve bandwidth slots. With USB 3.0 ("Superspeed"), I think the >guaranteed jitter is 200ns, It's higher than that for hi-speed, but I >don't remember the value. In most cases it's going to be the software >stack that's going to be the limiting factor on jitter. The audio >guys seem to be slightly unhappy, apparently wanting 100ns jitter >guarantee. > >>RS-232 isn't "great guns." It's still serial. But with RS-422 >>for example I can at least get fairly quick transfers of data >>and at precision intervals that are as known and as >>predictable as the crystal clocks I'm using to time them. I >>will usually select a processor with fixed (or very small >>variability in) latencies relative to timer interrupt events >>-- the ADSP-21xx processor for example has zero variability >>(if it isn't busy with interrupts locked out, of couse) in >>its interrupting response. These things can be important, at >>times. > >There are certainly advantages to a very lightweight stack. > >OTOH, it doesn't sound like you application would really ever make any >use of automatic baud rate detection.Oh, yeah. I'm on about something different, of course. Just responding to this proposed idea that time-stamping solves all problems. Jon
