Monitor RS232 comms with millisecond resolution

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 (even less from the old 1.8432 MHz crystal).

MS-DOS in no solution, either. It uses BIOS for I/O, and the BIOS contains so long interrupt disables that the required timing resolution is not reliably available.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio
Loading thread data ...

stream

(preferably

characters

Linux

to

or

get

The "A" side of the differential signal should be the inverted signal just so it will work with single ended signals.

Rick

--------------------------------------- Posted through

formatting link

Reply to
gnuarm

There are a wide variety of capabilities in the domain of USB logic analyzers. Be sure to read the specs on the Saleae and ensure that it can support the tasks you want to use it for. For example, its input voltage range is -0.5 to 5.25 V. It may become unhappy if it's connected directly to a +/- 7 (or +/- 12!) RS-232 line.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Am 22.06.2010 12:35, schrieb Peter Greuter:

It does, but not quite as much as you think it does.

Of course it is. But that doesn't lift restrictions given by the quartz the UART runs off. Ever wondered where those strange numbers like

115200, 57600, etc., come from? They're integer dividers of the PC's original quartz frequency of 1.8432 MHz, divided by 16 for oversampling. 62500 Baud is not, and no achievable baud rate is anywhere near enough to get working communication.
Reply to
Hans-Bernhard Bröker

Ah, the confusion of the A and B line that anyone who has ever done anything with RS485 has run in to and into which will run all who are going to use RS485 to eternity.

Probably all due to a mistake in the original 75176, see for example:

formatting link

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Repel them.  Repel them.  Induce them to relinquish the spheroid.
 Click to see the full signature
Reply to
Stef

Some of the blame for the confusion certainly rests with the standards body. I've got a copy of a 1978 version of the RS-422A spec where the drivers ("generators") are clearly drawn and labeled as

|\ | \------A | \

---| / | /o-----B |/

just like the usual datasheet symbols from Maxim et al. Following normal conventions this would imply that "A" is non-inverting and "B" is inverting.

But since UARTs universally (?) idle with a mark-high, and since the

*text* of the standard states that "the A terminal ... shall be negative with respect to the B terminal for a binary 1 (MARK or OFF) state," the *inverting* output really should have been "A."

So, basically, we're screwed.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

If accurate timestamps were your only concern on Windows that should not be a problem. On modern PCs it is fairly easy to implement a high resolution timer with approximately microsecond resolution using the QueryPerformanceCounter / QueryPerformanceFrequency Windows API functions.

Regards, Chris Burrows CFB Software

formatting link

Reply to
Chris Burrows

That's not entirely true if you are using a multi-core CPU. You will need to lock the time-stamping thread to one particular core otherwise you may get differences between the time-stamps. This is because Windows doesn't synchronise the timestamp values between cores.

You can also use the multimedia API (timeGetTime & friends) to get millisecond accuracy but you must then ensure that the thread says that it wants this sort of resolution with timeBeginPeriod. I've found though, that some machines only timestamp to 2ms even though 1ms has specified.

Andrew

Reply to
Andrew Jackson

Dividing by 18 yields 1.024 which is only 2.4% off.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
 Click to see the full signature
Reply to
Boudewijn Dijkstra

It does look like an excellent deal. I was especially impressed that they plan to support Linux. It would be nice if it worked with lower voltages (some projects I've worked with ran at

Reply to
Grant Edwards

No, it dosn't.

Except there _is_ no divisor that will give you 62500. The clock input to a PC UART is 1.8432 MHz. The baud clock needs to be 16x the baud rate.

Divisor Baud

1 115200 2 57600 3 38400 4 28800 ... ...

Please explain how you write a divisor value of 1.8432 to the divisor register.

--
Grant Edwards               grant.b.edwards        Yow! Make me look like
                                  at               LINDA RONSTADT again!!
 Click to see the full signature
Reply to
Grant Edwards

When you have multimedia playing, the OS changes the timer resolution. If you are relying on it, you have to be very careful about what else on the PC might be changing the resolution.

A bizarre consequence of this is that if you are using standard windows timer APIs, you can get more accurate timing as long as you play a movie on the machine... Only in the windows world!

And at best, all you can get is a timestamp of when the call to the timestamp function took place. You have no way of controlling the reaction time between a character coming into the uart, and your user code seeing that character. Add to that the fact that your thread can be interrupted at any time, and pre-empted for unpredictable times (even if your thread is given "real time" priority), and you can't get any guarantees about the timing accuracy. If you only need the timings to be mostly correct most of the time, it's probably okay to within about

10 ms. With commercial real-time addons for windows, you can get a bit more reliability and accuracy - probably in the 1 ms range (though I have never used such addons).

With Linux and a kernel with real-time enabled (many distro's enable it by default, I think, or at least have a real-time kernel in their repositories) will easily give you sub-ms sampling and accuracy. Of course, it still won't let your PC uart handle the non-standard baud rates.

Reply to
David Brown
[regarding RS485]

If you're using products from two different vendors, then just hook it up. If it doesn't work, then switch the wires. Seriously, the labels on RS485 terminals might as well be random...

--
Grant Edwards               grant.b.edwards        Yow! I'm having a
                                  at               tax-deductible experience!
 Click to see the full signature
Reply to
Grant Edwards

And if you ship RS485 equipment and write a manual, or write in-house wiring instructions, put something along those lines in the manual without making it sound too stupid. ;-)

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

A mushroom cloud has no silver lining.
Reply to
Stef

That is why you need to call timeBeginPeriod to "lock" the resolution to that which you require!

Wait until you play with WASAPI on Windows 7/Vista.

That's correct: I wasn't defending Windows, merely pointing out some functions that might be appropriate.

No, but Linux would be a lot easier. One could write a time-stamping line discipline, for example, fairly easily.

Andrew

Reply to
Andrew Jackson

Hello Le Tue, 22 Jun 2010 14:03:01 +0000 (UTC), Grant Edwards a écrit :

eventually my fault :-(

I read in the OP post "(actually I'm snooping on an RS485 bus)." so I thought about a (PCI) RS485 card.

The one I am using comes from VScom and has a high-speed option to permit 921 600 bd so there must be a way to write 8 x 1.8432 ~15 to some registers but I didn't find the corresponding API in their manual :-( I found only the sentence :

"The 16C950 UART used on the H-series cards has some hardware option to get very high bit rates, up to 3.6 Mbps. Of course these bit rates can not be used on RS 232, but there are other advantages. The maximum serial speed is raised, so there are more possible bit rates available in the usual range of RS 232 transmission. This allows to use some more rather unusual settings for transmission rates, some special hardware may require."

I think that other RS485 cards for PCs aren't either limited to

115 200 bd, really low for RS485 ;-)

My big fault : I didn't notice

that probably means a standard RS232 port, may be even with a INS8250 UART limited to 57 600 bd ;-)

Kind regards from France

Peter Greuter

Reply to
Peter Greuter

It would be highly unusual for a DOS based program to use the BIOS for serial I/O. I think MS-Kermit had the option to do so but it was not the normal default.

A few would use the BIOS for setup, but serial I/O bypassed the BIOS and was usually, but not always, interrupt driven.

Robert

Reply to
Robert Adsett

You are right about very primitive support for the serial I/O in BIOS, and that it was (almost) never used. However Tauno mentioned long interrupt disables in the BIOS (for entire HDD sector transfer operation, for example) that could disrupt timing if you have to go through any MSDOS or BIOS function.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

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).

Reply to
robertwessel2

n a

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

Reply to
-jg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.