I am using this device for my Arduino that connects to the OBD-II port of my car to get various information such as speed, rpm, etc. I am using this for a digital Nixie tube speedometer using the smart Nixie tube from a Kickstarter project.

I pass the information to the Nixie tubes through serial and get information from the OBD-II through serial as well. I am getting speed updates about every 20 seconds and that is incredibly slow when the device can supposedly update up to 100 times per second.

I originally was using an Arduino Uno and using software serial for the tubes, but I figured the slowdown was due to interupts interfering with the hardware serial, so I switched to the Arduino Mega 2560 to use a second hardware serial pin to hopefully fix the problem, yet the same issue is occurring.

Here is my code... There must be something I'm doing wrong. Serial2 is for the Nixie tubes.

This question came from our site for electronics and electrical engineering professionals, students, and enthusiasts.

1

The call to Serial2.available() looks suspicious, what happens if you remove it? That calls checks for incoming data, not that it's OK to send data.
– PeterJApr 23 '14 at 4:37

I will edit that out. I added that to see if it would help because without it I'm still getting slow responses.
– evan.stoddardApr 23 '14 at 4:38

Seem to be missing the source for obd.read() there.
– John UApr 23 '14 at 8:14

1

Can you add some sort of indication, like blink an LED, to show what's delaying? Is it that the code waits between reads, that the reads happen really slowly (low baud rate? faulty comms routine? long negotiation period?) or that the car waits a long time to respond? etc. etc.
– John UApr 23 '14 at 8:41

The read is a relatively high baud rate.
– evan.stoddardApr 23 '14 at 12:19

This limits kphValue to just over 100, if you want to go higher than that there are two option:

multiply by 62 and divide by 100;

use longer integers int32_t [-2147483648:2147483647], which comes with enough room for multiplying by 621371 and dividing by 1000000, but will perform slower and with a larger memory footprint. Do you really need that accuracy?

Yes and what about the computation delay added by the usage of floating point numbers with a MCU that has no floating point support.
– Blup1980Apr 23 '14 at 6:55

Not sure if the first part is correct, while I normally wouldn't write it that way I'd expect kphValue would be converted to a double for the calculation phase. Just gave it a quick try on a PC C++ compiler and result was 621 for an input of 1000.
– PeterJApr 23 '14 at 7:12

@Blup1980 - It will be slower but even a very slow micro should be able to do those calculations in a jiffy. If you were doing the conversion 1000 times per second then you might notice a delay.
– John UApr 23 '14 at 8:16

@Blup1980 where do you see floating point numbers in my answer?
– jippieApr 23 '14 at 17:57

1

@jippie You said that your implementation using integers is better because of the better accuracy. But I wanted to add that it's also better in term of speed because there is no floating point. But it would even be better if you multiply by 636 and divide by 1024 where the divide can be computed as logical shifts instead of a multi cycle divide operation.
– Blup1980Apr 23 '14 at 19:25