I have recently been involved in working on embedded microcontroller systems that send real time monitoring data to a Windows PC over a COMM port. (It is actually a RS485 port at the embedded mocrocontroller end as opposed to an RS232 port to allow the host application to request periodic data from one of several sources in turn). I have found that even on really fast host computers that there can be delays of about 10 to 20 milliseconds in packet turn around time when native COMM posts of the host machine are used (under Win2K or WinXP). A good part of this delay is due to the fact that any decently designed windows app does not stay in a tight polling loop working a packet protocol and instead uses a timer to manage the turnaround and response polling in case the comm driver event interrupts timeout.

In addition to that information note that I often use USB to RS232 adapters or USB->RS485 adapters and have noted additional delays in packet turn around time at the host app end of up to 60 milliseconds due to additional delays of COMM port handshaking line control support through the USB driver down to the USB/COMM port bridge.

These delays are real and must be dealt with. As I stated in the previous post is that the delays are not going to change much whether I try to send 100 packets per second or 4 packets per second. In the first case the turn around delays caused by the host OS and application would kill even an implementation of 100 small packets per second with a single data item in each packet. On the other hand 4 packets per second each with 25 data items packed in would work with plenty of time to spare!! Ahd rare is the Windows application where a 0.25 second latency to the first data samples going to be a problem.......particularly when the data flow initiates from a user clicking a button.

Michael Karas