timing of reads from serial port on windows

Question

I'm trying to implement a protocol over serial port on a windows(xp) machine. The problem is that message synchronization in the protocol is done via a gap in the messages, i.e., x millisecond gap between sent bytes signifies a new message. Now, I don't know if it is even possible to accurately detect this gap.
I'm using win32/serport.h api to read in one of the many threads of our server. Data from the serial port gets buffered, so if there is enough (and there will be enough) latency in our software, I will get multiple messages from the port buffer in one sequence of reads.

Is there a way of reading from the serial port, so that I would detect gaps in when particular bytes were received?

Answer 1

If you want more control over a Windows serial port, you will have to write your own driver.

The problem I see is that Windows may be executing other tasks or programs (such as virus checking) which will cause timing issues with your application. You application will not know when it has been swapped out for another application.

If possible, I suggest your program time stamp the end of the last message. When the next message arrives, another time stamp is taken. The difference between time stamps may help in detecting new messages.

I highly suggest changing the protocol so that timing is not a factor.

Answer 2

Are you saying that the protocol is a 1ms. gap? Nothing else delineates the messages, like STX, SOH, ???

What is the device? Who is the manufacturer?

Answer 3

I've had to do something similar in the past. Although the protocol in question did not use any delimiter bytes, it did have a crc and a few fixed value bytes at certain positions so I could speculatively decode the message to determine if it was a complete individual message.

It always amazes me when I encounter these protocols that have no context information in them.

Look for crc fields, length fields, type fields with a corresponding indication of the expected message length or any other fixed offset fields with predictable values that could help you determine when you have a single complete message.

Another approach might be to use the CreateFile, ReadFile and WriteFile API functions. There are settings you can change using the SetCommTimeouts function that allows you to halt the i/o operation when a certain time gap is encountered.

Doing that along with some speculative decoding could be your best bet.

Answer 4

It sounds odd that there is no sort of data format delineating a "message" from the device. Every serial port device I've worked with has had some form of a header that described the data it transmitted.

Just throwing this out there, but could you use the Win32 Asynchronous ReadFileEx() and WriteFileEx() system calls? They allow you to attach a callback function, and then you might be able to manage a timer within the callback. The timer would only provide you a rough estimation, however.

If you need to write your own driver, the Windows Driver Kit has a sample that shows how to write a serial port driver. I can't imagine that you'll be able to override the Windows serial port bus driver(the driver that directly controls the serial port on your Windows machine), but you might be able to write a driver that sits on top of the bus driver.

Answer 5

I thought so. You all grew up with the web, I didn't, though I was present at the birth. Let me guess, the one byte is 1(SOH) or 2(STX)? IMVEO it is enough. You just need to think outside the box.

You receive message_delimiter followed by 4 (as length) and then 4 bytes of data. A valid message is not those 6 bytes.

    message_delimiter - 1 byte
    4 - length - 1 byte
    (4 data bytes) - 4 bytes

A valid message is always bounded by the message_delimiter, so it would look like

    message_delimiter - 1 byte
    4 - length - 1 bytes
    (4 data bytes) - 4 bytes
    message_delimiter - 1 byte