Skinnable OBD software

kocke · 04-11-2005, 09:35 AM

Because of the software I found is not very usable at my carPC, I designed my own software, with a bigger interface.

Now I have a last versión, skinnable and multilanguage software.

The software uses the elm interface.

It's multithread: the principal thread reads from the interface, another thread writes to the port, another display the vehicle speed, other display the motor speed, and other, at the start time initializes the interface.

The software is customizable: always displays the vehicle speed and the motor speed, and the other info are the pids the user wants to display.

The software is skinnable, The layout of the software is defined at the obd.skin file. It's possible to switch between two skins, one for the day and other for the night.

Also, the program is multilanguage, I have the spanish and the english languages, but other are simply to add. Within the file idiomas.ini we will put the languages we are supporting, and we have some files with the name of the language and some diferent extensions with the infos (.obd and .pids). Also we have the file settings.ini to configure some settings.

The software also display if the MIL light is active and the diagnostic trouble codes present (DTC's).

We can configure some timeouts to suit to our car and there is a debug mode to display the raw responses, so we can adjust the timeouts.

You need the .NET framework to use it, and you also need to register the NetComm.OCX (regsvr32 netcomm.ocx).

You can download from: http://212.145.142.35/bp/obd.nsf/obd.zip

Regards

ShawJohn · 04-11-2005, 11:31 AM

screenshots?!?!

RoyN · 04-11-2005, 12:45 PM

amazing! gonna test it out VERY soon!

cant wait!

@josh: this is dependant on the interface... I think the elmscans are 1hz or 2hz... that is, one sensor data per second (or 2 sensors per second) This means that if you have speed and rpm, one of them will be updated at each second, which would take 2 seconds to have both updated. (I'm pretty sure of this, although if we can get more updates I would be really happy! ehhee)

Chairboy · 04-11-2005, 12:53 PM

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.

kocke · 04-11-2005, 01:02 PM

The timing is:
- ask for vehicle speed
- wait 300 ms (configurable timeout)
- ask for engine speed
- wait 300 ms
- ask for another pid

so we have the vehicle speed every 900 ms.

the screeshots are taken from my desktop, not from the car, I added the speed values over, and I didn't add values for the other pids

Regards

goosey2099 · 04-11-2005, 05:25 PM

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.

Chairboy · 04-11-2005, 06:01 PM

Quote: 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.

RoyN · 04-11-2005, 06:59 PM

Guys guys... no need to freak out on each othre!

Chairboy, ur almost at post#1000!

eheheh congrats!

You are both correct... Josh is saying that 2 updates per second would make a jumpy gauge, Chairboy is saying that you should update it 2 times per second, but program the gauge to actually take .5 seconds to reach the last value that just came in... that would make it smooth it out...

Chairboy · 04-11-2005, 07:27 PM

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.

DavidL · 04-12-2005, 12:43 PM

Here's a sample recording. You can see the resolution of the RPM. Each dot is a data sample. The graph line "connects the dots". As you can see, it's pretty smooth. Much more accurate than an analog meter which by it's physical nature is damped.

DavidL · 04-12-2005, 07:34 PM

I wouldn't call damping delaying. I would call it minimizing amplitude shifts over short term spikes. When an analog meter gets a "jolt" of signal, it immediately responds. Just not as dynamically as the signal implies due to it's mass.

The recording was taken with an Ease Diagnostics Wireless Vehicle Interface. www.obd2.com and graphed with their Pro Scan Tool software.

antimatter · 04-12-2005, 10:26 PM

thanks mods for deleting that crap

frodobaggins · 04-12-2005, 10:41 PM

Quote: Originally Posted by antimatter

thanks mods for deleting that crap

np

RoyN · 04-13-2005, 02:43 PM

Frodo & Ziplock... thanks for maintaining the peace!

I'll send some your way.....hhehehe

Erorus · 04-13-2005, 04:18 PM

Glad to hear it's truly multithreaded.. that's how one should write stuff like this that writes asynchronously to a port. (My VB6 class isn't multithreaded b/c VB6 can't really do threads.)

Instead of waiting 300ms to send the next command, may I suggest just waiting until you get the ELM's prompt ">" back and then send the next command then? I think the ELM won't send a prompt if it can't accept the command; correct me if I'm wrong.

Any luck using the ELM in binary mode? Supposedly it's a little faster but I didn't have the patience to code for it.

Finally, there's gotta be some .NET class for serial I/O where you don't have to rely on an ancient ActiveX component. I have little .NET experience so I can't really help find it, but there's got to be something out there.