Thread: Skinnable OBD software

screenshots?!?!

The refresh time is probably better then that if you apply some logic to it. For example, there should be at least three priority levels assigned to various gauges. RPM and speed should be refreshed every time, for example. The check-engine light should be checked too. That's three things that would be checked every time. All the other things, like oil temperature, etc, can be checked less often. Maybe once every 5-10 seconds. There's nothing that will happen that will make your water temperature spike in 5 seconds, for example, because the physical sensors have smoothing logic in them to keep the needle from bouncing around.

Finally, you can check all the rest of the stuff in increments every half minute or so. If it's not vital and doesn't change fast, you don't have to update it all the time.

The reason to monitor whether the check-engine light is on, btw, is simple. If it is, then something bad is happening, and that should trigger a new sequence of scans. If it lights up, your interface should first alert you, then scan every item on the OBD bus. That'll take a few seconds, but display the data as it comes over the pipe, and highlight any that exceed known good tolerances or are in an error condition. At this point, getting fast refreshes on speedometer/tach data is secondary to getting the whole picture.

This is a good little software but this program sent my m10000 cpu from 112f to 160f. Can you rewrite this in vb6 so it doesn't kill my cpu everytime i run it.

Originally Posted by joshthepilot

I would say speed and rpm need to be updated constantly for the smooth look. 2 for speed and 2 for rpm in one second? You have no standards for quality apparently.

Yes, and like I said, those would be the ones that should get sampled all the time. To make it look smooth in the animation, you use trend data. The only reason your animation looks jumpy is because you were only displaying the actual data as it came in. If you plotted the curves and applied a smoothing function, you could have needles that bob around organically using the datapoints being provided.

I don't think the personal attack is really warranted, this is a matter of technology implementation. In regards to me having no sense of quality, that's kind of inaccurate. I'm actually a software quality engineer, and my resume includes managing the QA for releases of some pretty darn succesful software, some of which you may have installed on your computer.

Ok, except since the RPM and Speedo are the two highest priority items, they'll never be superseded by anything else. Anything else I can help with? You seem awful comfortable stating 'that'll never work', and 'you're an idiot for trying to make that work'. The confidence you have in your ability to find the One True Solution is admirable, if misplaced.