Serial Communication Timing Problem
-
I am receiving between 40 and 50 bytes from a some asynchronous serial equipment at 9600 baud. I am suppose to receive this data within 50 milliseconds after it being sent. When I compare the two timestamps it is more than 80 milliseconds. I am currently using a thread to read the data and do the timestamp immediately. Any ideas how one could configure the COMMTIMEOUTS optimally to reduce the delay. Maybe I need to look at something else in my program. Any ideas. Thanks Cheers
-
I am receiving between 40 and 50 bytes from a some asynchronous serial equipment at 9600 baud. I am suppose to receive this data within 50 milliseconds after it being sent. When I compare the two timestamps it is more than 80 milliseconds. I am currently using a thread to read the data and do the timestamp immediately. Any ideas how one could configure the COMMTIMEOUTS optimally to reduce the delay. Maybe I need to look at something else in my program. Any ideas. Thanks Cheers
Timers under windows and external hardware aren't things that play particularly nicely from my experience. Some fairly obvious suggestions are: Make sure that you are using a high resolution timer QueryPerformanceCounter() rather than timeGetTime(). timeGetTime() only has a resolution of 10ms, but it can be even worse than that in some situations. If you are sleeping in you polling thread, don't expect to wake up on time if you call Sleep(), delays can be out by huge ammount from a hardware perspective - 200ms for a sleep of 10ms is quite likely. If you aren't sleeping, check to make sure that the CPU isn't being choked by your polling thread or another thread being a hog. It might not cause problems now, but it may down the track. Solutions depend on the application - how time critical is time critical? Is it better to lose data and stay on time? Or do you always need to get every byte? One of the projects I'm working on at the moment is using MaRTE[^] a real time embedded operating system. In the past we have designed custom hardware to cache data to ensure that the PC always keeps up. It's a case of requirement specifications dictatating software design very tightly :)
If you can keep you head when all about you Are losing theirs and blaming it on you; If you can dream - and not make dreams your master; If you can think - and not make thoughts you aim; Yours is the Earth and everything that's in it. Rudyard Kipling
-
Timers under windows and external hardware aren't things that play particularly nicely from my experience. Some fairly obvious suggestions are: Make sure that you are using a high resolution timer QueryPerformanceCounter() rather than timeGetTime(). timeGetTime() only has a resolution of 10ms, but it can be even worse than that in some situations. If you are sleeping in you polling thread, don't expect to wake up on time if you call Sleep(), delays can be out by huge ammount from a hardware perspective - 200ms for a sleep of 10ms is quite likely. If you aren't sleeping, check to make sure that the CPU isn't being choked by your polling thread or another thread being a hog. It might not cause problems now, but it may down the track. Solutions depend on the application - how time critical is time critical? Is it better to lose data and stay on time? Or do you always need to get every byte? One of the projects I'm working on at the moment is using MaRTE[^] a real time embedded operating system. In the past we have designed custom hardware to cache data to ensure that the PC always keeps up. It's a case of requirement specifications dictatating software design very tightly :)
If you can keep you head when all about you Are losing theirs and blaming it on you; If you can dream - and not make dreams your master; If you can think - and not make thoughts you aim; Yours is the Earth and everything that's in it. Rudyard Kipling
Thanks for your input. It is appreciated. I do use a QueryPerformance counter to check the time. Timing and the data is critical. Other instruments that sends synchronous data at 19200 baud are received at less than 50ms. Unfortunately the instrument in question is the only one that sends asynchronous data at 9600 baud. I will check out the threads in the mean time. Thanks again