How long should I sleep my thread while waiting for OBD data from ECU

Question

I am developing an OBD2 scanner app for windows using C#. I was hoping someone could tell me the optimal time to wait for a response (using thread.Sleep()) from the car's ecu before reading the response from the serial port.

I am developing using a bluetooth adapter and the Baud rate is 9600. I've currently got my wait period set to 100ms, but I am hoping to go much shorter than that if possible. I just don't want to run into a situation where I try to read data when the port is not ready. I want to get a good trade-off between a smooth GUI and comfortable margins for error.

UPDATE: thanks of the ideas. Handling DataReceived is a good general idea but the reason I'm sleeping a thread is that I need to poll the ECU repeatedly at intervals so that I can do things like update an RPM gauge. I am trying to find a sweetspot where I am getting as many reps as possible from the ECU, without overwhelming it. If I were polling it once only, then simply handling an event would be fine, but I need to know what an acceptable interval would be between polls. I will definitely change my code to be event-driven, but I still need to know how long is a respectable time between polls.

Use the DataReceived event to accumulate the response. The response will likely raise the event more than once for a complete response. At 9600BPS you receive 1,200 chars/second or one character every 0.000833 seconds. You don't need Thread.Sleep. — dbasnett, Jun 05 '13 at 13:33
Just a hint, change '010C' into '010C1'. This way the OBD-II adapter reports back as soon as he has 1 answer. Makes the timeout way shorter, and it should be possible to read 20 times a second. And with a bluetooth connection there is no real baudrate. — Eric Smekens, Jun 05 '13 at 20:34

score 2 · Answer 1 · answered Jun 05 '13 at 13:32

2

Instead of using Thread.Sleep(), it may be more appropriate to spawn a background thread that continuously tries to read from the stream. When the data has been fully read, then fire an event for the main thread to handle. As long as you have opened the port, there shouldn't be a problem.

answered Jun 05 '13 at 13:32

Rubixus

757
4
11

The DataReceived event fires automagically when there is data. – dbasnett Jun 05 '13 at 13:37
@dbasnett: That's true, but OP should make sure that data he receives is complete. His worker thread can keep its own buffer and will check when all the data has been received before passing it to the main thread. Designing a simple packet structure can make this relatively easy. – Rubixus Jun 05 '13 at 13:43
Did you see my comment on the original post? – dbasnett Jun 05 '13 at 15:22

score 0 · Accepted Answer · answered Jul 12 '13 at 07:24

I decided to follow the lead of my car's built-in trip computer and refresh the values once every 1000ms, or more accurately, to refresh 10 values per second, one at a time at 100ms, 200ms, 300ms, etc.

I also prioritised things that change more often, like instant consumption, RPM and a few specialised sensors. Things like battery voltage, temperature and fuel levels only need to realistically be polled every 5, 10 and 20 seconds respectively, so there's lots of room for prioritisation.

How long should I sleep my thread while waiting for OBD data from ECU

2 Answers2