On Jun 22, 9:33=A0pm, "Rowan Sylvester-Bradley" <ro...@sylvester- bradley.org> wrote:> =A0- I'm therefore best to use a simple free standing PCB with a > microprocessor with a RTC and two serial ports capable of flexible baud > rates. One runs at 62,500 baud and receives the characters from the RS485 > bus. The other runs at 115,200 baud or higher and sends to the PC. The > receive interrupt handler receives the bytes, timestamps them and writes > them into a buffer. The main program reformats the bytes and timestamps i=n a> form suitable for the PC and writes them into an output buffer. The send > interrupt handler sends them to the PC.Avoiding the PC as the timer is a good idea, but you maybe able to simplify your Dual-UART code, if you simply arrange to SEND one 115200 Bd byte, every 100us. That gives you 11.52 bit times, or 1.52 stop bits with parity. ( > 1 stop bit is a good idea if running continual streams anyway) Code is then very simple, and time is implicit : IF the RS485 has data THEN send it on, with parity set, ELSE send a time-check value, with parity unset. Simple place counting at the Bucket arrival rate gives you the time to 0.1ms, and you can go better if you use the time-values to indicate actual arrival times. (tho you can't quite tag every byte with 8 bits, but could tag every byte to 4 bits, to resolve to 6.25us, getting close to the best possible start bit precision, and finer than the likely host TxClock) Each incoming 16 byte block, can contain up to 10 RS485 bytes and 6 time stamps, and has a time-width of 1.6000ms. -jg
Monitor RS232 comms with millisecond resolution
Started by ●June 20, 2010
Reply by ●June 22, 20102010-06-22
Reply by ●June 23, 20102010-06-23
On Tue, 22 Jun 2010 16:44:24 -0700 (PDT), "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> wrote:>On Jun 22, 8:47�am, "Boudewijn Dijkstra" ><sp4mtr4p.boudew...@indes.com> wrote: >> Op Tue, 22 Jun 2010 13:09:52 +0200 schreef Tauno Voipio � >> <tauno.voi...@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...@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.
Reply by ●June 23, 20102010-06-23
On Jun 23, 12:29=A0am, Paul Keinanen <keina...@sci.fi> wrote:> On Tue, 22 Jun 2010 16:44:24 -0700 (PDT), "robertwess...@yahoo.com" > > > > > > <robertwess...@yahoo.com> wrote: > >On Jun 22, 8:47 am, "Boudewijn Dijkstra" > ><sp4mtr4p.boudew...@indes.com> wrote: > >> Op Tue, 22 Jun 2010 13:09:52 +0200 schreef Tauno Voipio > >> <tauno.voi...@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...@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). =A0Obviously 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.
Reply by ●June 23, 20102010-06-23
On Tue, 22 Jun 2010 23:56:58 -0700 (PDT), "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> wrote:>On Jun 23, 12:29�am, Paul Keinanen <keina...@sci.fi> wrote: >> On Tue, 22 Jun 2010 16:44:24 -0700 (PDT), "robertwess...@yahoo.com" >> >> >> >> >> >> <robertwess...@yahoo.com> wrote: >> >On Jun 22, 8:47 am, "Boudewijn Dijkstra" >> ><sp4mtr4p.boudew...@indes.com> wrote: >> >> Op Tue, 22 Jun 2010 13:09:52 +0200 schreef Tauno Voipio >> >> <tauno.voi...@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...@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.
Reply by ●June 23, 20102010-06-23
"Paul Keinanen" <keinanen@sci.fi> wrote in message news:9pe3269vevlnos3fn3j1ne6dv7tnfgm293@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
Reply by ●June 23, 20102010-06-23
El 21/06/2010 18:37, d_s_klein escribi�:> On Jun 20, 4:34 pm, "rowan.bradley"<rowan@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." > > RKJust be aware that ms resolution does not mean ms precision! -- Saludos. Ignacio G.T.
Reply by ●June 23, 20102010-06-23
On 2010-06-23, Paul Keinanen <keinanen@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
Reply by ●June 23, 20102010-06-23
On Wed, 23 Jun 2010 14:13:14 +0200, "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> wrote:>"Paul Keinanen" <keinanen@sci.fi> wrote in message >news:9pe3269vevlnos3fn3j1ne6dv7tnfgm293@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.Hehe. But this means you actually _have_ something with an ISA bus on it!! These days... well. I keep an older 80386DX and 80486DX machine around (three, actually) all nicely sporting lots of ISA slots. Also have proto ISA boards I can use to slap up an easy custom circuit on. No way could do that with PCI. My 80486DX boots up Win98SE at 33MHZ and 64Mb RAM (with an external cache made from discrete static rams) faster than my WinXP boots on a 2.94GHz cpu. I actually prefer to use it, too. On your point, yes. A crystal change on any of the usual spate of old ISA boards would easily solve the problem. Forgotten lore. Jon
Reply by ●June 23, 20102010-06-23
On 2010-06-23, Jon Kirwan <jonk@infinitefactors.org> wrote:> On Wed, 23 Jun 2010 14:13:14 +0200, "Meindert Sprang" ><ms@NOJUNKcustomORSPAMware.nl> wrote: > >>"Paul Keinanen" <keinanen@sci.fi> wrote in message >>news:9pe3269vevlnos3fn3j1ne6dv7tnfgm293@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. > > Hehe. But this means you actually _have_ something with an > ISA bus on it!! These days... well.Then use a PCI card.> On your point, yes. A crystal change on any of the usual > spate of old ISA boards would easily solve the problem. > Forgotten lore.It works for PCI cards as well. -- Grant Edwards grant.b.edwards Yow! An Italian is COMBING at his hair in suburban DES gmail.com MOINES!
Reply by ●June 23, 20102010-06-23
On Wed, 23 Jun 2010 21:04:55 +0000 (UTC), Grant Edwards <invalid@invalid.invalid> wrote:>On 2010-06-23, Jon Kirwan <jonk@infinitefactors.org> wrote: >> On Wed, 23 Jun 2010 14:13:14 +0200, "Meindert Sprang" >><ms@NOJUNKcustomORSPAMware.nl> wrote: >> >>>"Paul Keinanen" <keinanen@sci.fi> wrote in message >>>news:9pe3269vevlnos3fn3j1ne6dv7tnfgm293@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. >> >> Hehe. But this means you actually _have_ something with an >> ISA bus on it!! These days... well. > >Then use a PCI card. > >> On your point, yes. A crystal change on any of the usual >> spate of old ISA boards would easily solve the problem. >> Forgotten lore. > >It works for PCI cards as well.I like ISA and simpler software. Although I understand reflection wave principles, clock line skew and serpentine clock lines, and the like, I very much appreciate being able to use simple logic, wire-wrapping techniques, and custom circuit design with the ISA bus. It is a low-tech bus that can be reached by hobbyists. PCI, and not merely because of the hardware but also because of other aspects (plug and play), out of reach of most hobbyist tools and skills. And I also understand the desire to get rid of the south bridge, chipset side-band channels to support ISA DMA over a bus that simply cannot and does not support ISA DMA timing requirements, interrupt mapping, and so on. It's pretty obvious this was a huge source of continuing chipset bugs and needed testing regimes, as well. But I like ISA. Jon
