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 through
Greeleaf used to sell a serial data analyzer program for DOS. It even came with a Y-cable so that you could monitor two data lines. In my experience, it's either that or something hardware-based. If you find a good solution let us know.
If I had to do it I would grab a serial to USB board such as DLP Designs sells (has an ftdi chip on it). Then get a dev board with an atmega128 (or any micro with 2 serial ports). Hook up the rs485 to a transceiver such as a 75176, then to one of the micro's serial ports. The other port you connect to your usb board. Write a small program that receives the bytes, adds the timestamp, then writes it out over the second port (which you can run at a few hundred kilobaud to keep up). On the pc side, my favorite way to do it is to write a python program, using pyserial to read the port. This can easily keep up with 1 megabaud on a reasonable PC. This system would be able to generate the timestamp within a few microseconds of the byte's arrival, limited by your micro's (and C compiler's, if you use C) interrupt latency.
If I was doing it I would use a low-cost (< $100) off-the-shelf ARM development board - but that is because I could program it much more quickly and easily than an 8051 or a PIC as I already have most of the code written.
define 'cheap'
Doesn't sound too difficult - unless I'm missing something?
I'm not certain that is possible with what I have in mind but am optimistic.
-- Chris Burrows CFB Software Astrobe: ARM Oberon-07 Development System
You can get quite accurate time stamps by disabling the UART FIFO and assuming you are on a Pentium or newer processor with the RDTSC instruction, read the Time Stamp Counter in the Rx interrupt routine, first put the received byte in the software Rx queue, followed by 8 bytes from the TSC.
On the user mode side, read 9 bytes at a time, the first being the actual byte received, the rest the time stamp. To convert the TSC to milliseconds, you have to know (or measure) the CPU clock frequency.
With the UART FIFO disabled, the maximum baud rate depends on the interrupt latency of the system, e.g. for how long the interrupts are disabled. Also some peripherals (such as graphic cards, ethernet or IDE controllers) may effectively block interrupts for a long time, however, the situation has improved a lot since the 1990's.
Are you actually interested in *every* byte or just "certain" bytes (e.g., are you looking at, perhaps, the timing of *messages*?)
If you can find something that you can easily write / deploy code on, this is a one page program.
IIRC, a "real PC" will give you problems hitting 62,500. I think the baud rate clock is fed from too low of a frequency to give you enough precision to hit "any" baudrate you want (esp at higher rates, obviously)
I'm not sure an IBM PC uart can run at that rate. I think
57600 is doable, though. Something that bothers me about your request is this 1ms resolution. At 62500 bps, one stop and one start, this is 6250 cps. That works out to 160us per character. Yet you don't seem to __require__ better than 1ms resolution? (I do read you saying that you'd like better.)
Okay. None of that really helps. The IBM PC is everywhere, so I understand that desire. But I don't think you can nail the rate at 62500. If you can use 57600, I think that works on the PC. There is a 16-bit timer on the PC. It doesn't interrupt fast enough for you, but you can read it when the characters arrive. So if you use DOS, write in assembly code, can accept the 57600 bps rate, then it's doable. I keep new boxes of DOS 5.0 laying about and 80386 and 80486 machines here with nice ISA buses, just for doing stuff like this. But you may not have them. And new PCs seem to be avoiding RS-232 ports more and more.
USB would barely get you by (one of those USB to RS-232 things), as I believe the max 'pace' is 1ms there. (I don't know USB that well, but I disagree with Paul on this subject unless you dig _really_ deep into the USB VxD level of stuff.) In general, I don't know how closely you can track it through through the HID driver and all of the Windows layers. I'd probably avoid it, imagining the work there to be way too much to bite off for too little potential.
Which gets to either someone's device you can buy -- you've already looked -- or else something you pony up. I'd wire something up from crap I have around here. Some don't have the level shifters, but you are only looking to receive, not send, so you can easily use a BJT and a few resistors there (cheap and easy.) Software is extra, of course.
If you did have one of those USB-RS232 units and could wire up to it (I got one included in the $24 MSP430 Chronos kit I bought, for example), you might choose a micro with two UARTS and wire one of them to the USB-RS232 connector and send serial data in that direction that includes the received characters and their time stamps for logging onto the PC and wire the other one to monitor your 62500 bps line. Add time stamps and send to the USB side. Not too much software that way and you have a huge data logger, then. (You didn't mention how much data must be logged, which is yet another potential problem.)
Everything depends on many factors some of which are
1/ Do you want relative timestamp from power up or first byte received?
2/ Do you want linked timestamp (actual time) to some time stamp reference (even one system's time clock)?
3/ With later mentioned 62500bps, your accuracy could end up +/-1ms
4/ Are you timestamping each byte, or a block of data?
5/ Are you timestamping the
- line start bit falling edge, middle or effective end - line Stop bit effective rising edge, middle or effective end - Byte coming out of a UART (with hardware latency from start bit) effectively Data Ready flag, which becomes skewed even with two or more bytes from double buffering or FIFOing and software/interupt latency. - Start/middle/end of any message block
6/ How much data are you expecting to capture per second/min
7/ How large a time stamp range do you need, i.e. do you need one that runs for minutes, hours, days or longer. This affects the overhead of any timestamp, the bigger it is the more to process. Also the more bytes that have to be timestamped the larger the dataset.
Using and external device will make getting that baud rate easy, how big your data set is, the time stamp data has to be affects how much storage buffering of data and in turn potentially latency for timing as recording gets bigger. If on a PC the act of updating screen or saving some of the data to disk could impact on recording timing on a heavily loaded link.
If you must timestamp every byte, I would consider a seven bit relative time stamp between bytes, with MSB set as 1. Full time stamp always to have MSB set to 0, thus huge amount of data set can saved if you need a 4 byte or larger timestamp for the whole dataset. If time delta greater than 127 steps, send full time stamp.
Even at 62500 bps, you are potentially storing 6250 bytes/second, with a four byte timestamp on ech byte you are then storing 5 x as much data EVERY second. This of course increases to 9x as much for 8 byte timestamp. So your data storage, buffering and processing requirements increase drastically for an external unit.
Mean while in a PC storing data to disk could cause gaps in time stamp accuracy, depending on how good the disk drivers and hardware actually are.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Timing Diagram Font
GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
For those web sites you hate
- it's able to record and decode serial data and of course the resolution is several orders of magnitude better than you require. Not cheap but a good logic analyzer is often useful.
Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
If you only want to analyse a serial data stream and if you are sure, that the bits are correct, you can simply read the data with a PC.
I don?t think, that you need a microcontroller.
The simplest way is, you take the B wire (or D-) of the RS485 signal and connect it via a 1K resistor with the RXD* line of the PC and the GND line of your RS485 Device with the GND-Line of the PC-Com-Port. This is electrically not ideal, but should normaly work. But You should not connect the TXD* line (the one, where you see about -8V) of the PC to the RS485 bus.
A better solution of course would be the use of a RS485 tranceiver which is used only in read-mode, e.g. max485.
Now take a simple program, e.g. in Turbo-Pascal under DOS or Delphi under Windows and record the data.
For a one-cannel solution, i would prefer delphi. For a two-channel solution, where i need the timing between the two signals, it might be better in DOS.
With some experience in serial communication, this should be done in about half an hour.
With MSDOS or Windows, you can use every baudrate that is a factor/divider of 115200.
Without changing system timing, MSDOS won't give you 1ms resolution only 1/18.5 Hz. Not sure about all forms of Windows and system clock resolution.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Timing Diagram Font
GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
For those web sites you hate
I kind of scanned through he replies and I don't think I saw this mentioned.
*IF* you don't have much data to dig through, or you have lots of time on your hands, you can use a logic analyzer and get ns resolution if you want. Many of them have settings to mark a channel as a serial input of differing type, UART, I2C, SPI and so on, and then mark the data up appropriately. All you need is access to the logic side of the transceiver, or the logic signals for on board busses. I am only mentioning it because I have used it for a very similar purpose. So, the software the comes with the Digi View from Tech Tools will let you set multiple inputs up as serial data with any baud rate and combo of start and stop bits, parity and so on, and display the massaged data bytes with full timing info available on every level transition, including the start bit.
Typically the UART requires a clock that is 16x the baud rate, thus, for 62.5 kBaud, the crystal frequency would have to be multiple of 1 MHz.
Take some ISA/PCI UART board and replace the crystal (oscillator) with one that oscillates on some exact MHz close to the original frequency and adjust the divisor accordingly.
Thanks for all the helpful replies. I'm coming to the following conclusions: - Windows can't do what I want, or at least not without a huge amount of work trying to get the most accurate timestamps possible, and even then it would be only barely good enough. - I could possibly do it on a PC with MSDOS, but I would effectively be programming it as a microprocessor. - The standard ISA or motherboard serial port can't do 62,500 baud. - 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 in a form suitable for the PC and writes them into an output buffer. The send interrupt handler sends them to the PC.
So long as the PC can keep up, either because the baud rate is high enough or because there are sufficient gaps in the incoming data for the buffers to empty (in practice the data comes in short bursts with gaps between so with decent sized buffers this won't be a problem).
One other thing I learned - the Saleae logic analyser looks a really interesting device for a very good price - I think I may get one of those...
Le Tue, 22 Jun 2010 10:33:29 +0100, "Rowan Sylvester-Bradley" a écrit :
....
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.
Kind regards from France
Peter Greuter
--
my oldies at http://www.teaser.fr/u/pgreuter/albumel.htm
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.