Monitor RS232 comms with millisecond resolution
in [Embedded]
|
Prev: MAKE UPTO $5000 PER MONTH! $2000 IN FIRST 20 DAYS!
Next: Dexcel Electronics Designs is Hiring in Chennai
From: robertwessel2 on 23 Jun 2010 02:56 On Jun 23, 12:29 am, Paul Keinanen <keina...(a)sci.fi> wrote: > On Tue, 22 Jun 2010 16:44:24 -0700 (PDT), "robertwess...(a)yahoo.com" > > > > > > <robertwess...(a)yahoo.com> wrote: > >On Jun 22, 8:47 am, "Boudewijn Dijkstra" > ><sp4mtr4p.boudew...(a)indes.com> wrote: > >> Op Tue, 22 Jun 2010 13:09:52 +0200 schreef Tauno Voipio > >> <tauno.voi...(a)notused.fi.invalid>: > > >> > On 22.6.10 1:35 , Peter Greuter wrote: > >> >> Le Tue, 22 Jun 2010 10:33:29 +0100, "Rowan Sylvester-Bradley" > >> >> <ro...(a)sylvester-bradley.org> a crit : > > >> >> .... > > >> >>> - The standard ISA or motherboard serial port can't do 62,500 baud.. > > >> >> I am surprised that nobody reacted to this statement : as always it > >> >> depends a lot on the programs involved ! But for instance under > >> >> MS-DOS it is possible to reprogram the baudrate divider of a > >> >> typical 16X50 UART by sending just two bytes to two output port > >> >> registers after the initialisation sequence to get more than the > >> >> standard baudrates. The {COMMO} communication program by Fred P. > >> >> Brucker included this possibility in the later version in the setup > >> >> part. > > >> > Forget the PC. > > >> > 62500 bit/s needs a raw clock of 1.000 MHz, which is not available > >> > by any integer divider from 18.432 MHz > > >> Dividing by 18 yields 1.024 which is only 2.4% off. > > >Which is problematically far off, unless you can guarantee that the > >sender is no more than about 1.3% off in the other direction (slower > >than spec). Obviously if the sender is off in the same direction, > >there's considerably more slack). > > Since the OP required receive only capability, configure the actual > data network with 2 stop bits and the monitoring receiver with 1 stop > bit. > > In asynchronous mode, the synchronization occurs at the leading end of > the start bit, defining the sampling point in the middle of the actual > data bits. With a clock frequency error, the sampling point moves away > from the middle of the bit and in the worst case falls into the > next/previous data bit. > > With two stop bits transmitted, there is a larger distance between the > start bits of two bytes. When the receiver expects only one stop bit, > the actual sampling point for the first (and only) stop bit can fall > outside the actual first start bit transmitted into the second stop > bit transmitted. This is quite OK and the receiver enters the idle > state, waiting for the next proper start bit. You still need to be adequately synchronized for each data bit. While doubling up the stop bit might net you some extra slack on the stop bit, the prior (data or parity) bit still has to be sampled not-too- near its edge. Besides, your idea puts the slack in the wrong place. With the available (x18) divider, the receiver will be running too fast, and will be sampling the stop bit too early - lengthening the stop bit doesn't actually help. If you used a x19 divider, the extra slack might help in detecting the stop bit (since the slack will now add in the helpful direction because the receiver will be running too slow), but you'll be even farther off center for the preceding parity/data bit. But still, if the OP can guarantee the accuracy of the sender's clock (to rather better than the RS-232 standards), it should be possible to receive the stream with a x18 divider.
From: Paul Keinanen on 23 Jun 2010 04:12 On Tue, 22 Jun 2010 23:56:58 -0700 (PDT), "robertwessel2(a)yahoo.com" <robertwessel2(a)yahoo.com> wrote: >On Jun 23, 12:29�am, Paul Keinanen <keina...(a)sci.fi> wrote: >> On Tue, 22 Jun 2010 16:44:24 -0700 (PDT), "robertwess...(a)yahoo.com" >> >> >> >> >> >> <robertwess...(a)yahoo.com> wrote: >> >On Jun 22, 8:47 am, "Boudewijn Dijkstra" >> ><sp4mtr4p.boudew...(a)indes.com> wrote: >> >> Op Tue, 22 Jun 2010 13:09:52 +0200 schreef Tauno Voipio >> >> <tauno.voi...(a)notused.fi.invalid>: >> >> >> > On 22.6.10 1:35 , Peter Greuter wrote: >> >> >> Le Tue, 22 Jun 2010 10:33:29 +0100, "Rowan Sylvester-Bradley" >> >> >> <ro...(a)sylvester-bradley.org> a crit : >> >> >> >> .... >> >> >> >>> - The standard ISA or motherboard serial port can't do 62,500 baud. >> >> >> >> I am surprised that nobody reacted to this statement : as always it >> >> >> depends a lot on the programs involved ! But for instance under >> >> >> MS-DOS it is possible to reprogram the baudrate divider of a >> >> >> typical 16X50 UART by sending just two bytes to two output port >> >> >> registers after the initialisation sequence to get more than the >> >> >> standard baudrates. The {COMMO} communication program by Fred P. >> >> >> Brucker included this possibility in the later version in the setup >> >> >> part. >> >> >> > Forget the PC. >> >> >> > 62500 bit/s needs a raw clock of 1.000 MHz, which is not available >> >> > by any integer divider from 18.432 MHz >> >> >> Dividing by 18 yields 1.024 which is only 2.4% off. >> >> >Which is problematically far off, unless you can guarantee that the >> >sender is no more than about 1.3% off in the other direction (slower >> >than spec). �Obviously if the sender is off in the same direction, >> >there's considerably more slack). >> >> Since the OP required receive only capability, configure the actual >> data network with 2 stop bits and the monitoring receiver with 1 stop >> bit. >> >> In asynchronous mode, the synchronization occurs at the leading end of >> the start bit, defining the sampling point in the middle of the actual >> data bits. With a clock frequency error, the sampling point moves away >> from the middle of the bit and in the worst case falls into the >> next/previous data bit. >> >> With two stop bits transmitted, there is a larger distance between the >> start bits of two bytes. When the receiver expects only one stop bit, >> the actual sampling point for the first (and only) stop bit can fall >> outside the actual first start bit transmitted into the second stop >> bit transmitted. This is quite OK and the receiver enters the idle >> state, waiting for the next proper start bit. > > >You still need to be adequately synchronized for each data bit. While >doubling up the stop bit might net you some extra slack on the stop >bit, the prior (data or parity) bit still has to be sampled not-too- >near its edge. At 62.5 kbit/s the bit time is 16 us, thus +/-8 us error from the nominal sampling point from the middle of the bit period would be allowed. Assuming startbit+8 data bits + 2 stop bits transmitted, the Rx sample point for the last data bit could be theoretically +8 us after the transmitted bit period midpoint. The transmitted midpoint is 8+8x16=136 us from the start of the start bit. The worst case Rx sample point would be at 136+8=144 us, corresponding to 8.5 Rx clock times, i.e Rx clock period of 16.94 us or 59028 bits/s. The sample point for the 1st stop bit would be 9.5 bit times from the start bit at 160.94 us, well before the next transmitted start bit at 176 us (or later). Clearly 57600 bits/s would be out of question. Those calculations assume nominal clock frequencies and extreme steep edges. >Besides, your idea puts the slack in the wrong place. With the >available (x18) divider, the receiver will be running too fast, and >will be sampling the stop bit too early - lengthening the stop bit >doesn't actually help. If you used a x19 divider, the extra slack >might help in detecting the stop bit (since the slack will now add in >the helpful direction because the receiver will be running too slow), >but you'll be even farther off center for the preceding parity/data >bit. With 18.432 MHz crystal divided by 19 and then applying the internal UART x16 oversampling would produce 60632 bits/s Rx bit rate. >But still, if the OP can guarantee the accuracy of the sender's clock >(to rather better than the RS-232 standards), it should be possible to >receive the stream with a x18 divider. In the real world, the RS-232 parts are supposed to be slew rate limited, causing ISI, which of course limits how far from the nominal sample point you can go. Especially any noise in the start bit edge detection will also add error to the Rx sample points along the data bits. However, the original poster was talking about RS-485 network, in which even slew rate limited drivers are good for at least 250 kbit/s, thus the edges would be rather sharp.
From: Meindert Sprang on 23 Jun 2010 08:13 "Paul Keinanen" <keinanen(a)sci.fi> wrote in message news:9pe3269vevlnos3fn3j1ne6dv7tnfgm293(a)4ax.com... > At 62.5 kbit/s the bit time is 16 us, thus +/-8 us error from the > nominal sampling point from the middle of the bit period would be > allowed. Funny, all the discussions about baudrates and errors. I'd use an ISA COM card and simply replace the crystal... done it, works like a charm. Only 5 minutes work. Meindert
From: Ignacio G. T. on 23 Jun 2010 08:56 El 21/06/2010 18:37, d_s_klein escribi�: > On Jun 20, 4:34 pm, "rowan.bradley"<rowan(a)n_o_s_p_a_m.sylvester- > bradley.org> wrote: >> Anyone know the quickest or easiest way of recording a serial data stream >> and timestamping each byte with a resolution of at least 1ms (preferably >> finer)? I can only find cheap or free programs with less resolution, or >> very expensive solutions, often involving special hardware. >> >> I only need to monitor one port, and I don't need to send any characters >> (actually I'm snooping on an RS485 bus). >> >> I'm prepared to use an old PC with a "real" serial port, run MSDOS, Linux >> or whatever other OS will do the job, use some sort of microprocessor to >> capture the data (preferably one I'm familiar with, such as 8051 family or >> PIC) or anything else so long as it's quick and cheap. I just need to get >> the job done, preferably tomorrow! >> >> If possible I'd like it to run at a non-standard baud rate (62,500 baud). >> >> Thanks - Rowan >> >> --------------------------------------- >> Posted throughhttp://www.EmbeddedRelated.com > > Have you seen this:<http://www.232analyzer.com/232default.htm> ?? > > According to their hype, "All monitoring modes available in > 232Analyzer software come with timestamps in milliseconds." > > RK Just be aware that ms resolution does not mean ms precision! -- Saludos. Ignacio G.T.
From: Grant Edwards on 23 Jun 2010 09:41
On 2010-06-23, Paul Keinanen <keinanen(a)sci.fi> wrote: > Since the OP required receive only capability, configure the actual > data network with 2 stop bits and the monitoring receiver with 1 stop > bit. That's assuming that: 1) The OP can change the configuration of the data network. [If that were the case, why not just change it to 57600 or 115200?] 2) The OP has a UART with an 18MHz clock instead of the standard 1.8MHz clock. I'd bet both of your assumptions are false. -- Grant Edwards grant.b.edwards Yow! I'm definitely not at in Omaha! gmail.com |