Software On ELM Street - OBD2 Software Development

[Tazzi]

When doing adr's for crash testing at work a couple of years ago,i know a lot of data is captured in the SDM that can be accessed in a fatality with the correct legal procedures
ie brake pedal position vs throttle pedal position vs yaw rate vs steering angle position vs RPM vs 4 x wheel speeds vs vehicle speed....and the list goes on.
Tazzi I went through my stuff looking for a TCM that I thought I did have,but had no luck.

I recall seeing alot of data in the SDM. There was also a tonne of tables that the tech2 didnt utilize.. although you could clearly see engine speed, vehicle speed. So I guess that must be the info stored in the SDM!
Cheers for looking mate
But I *think* I have sourced out a VZ TCM and a VE V6 ecu (hopefully!)

And the freeze frame data has been around since the VR $11 and $12 code.

Ahh nice, so freeze data has been around for a fair time. Guess it is a useful diagnostic tool for when an error does occur.

[Charlescrown]

I don't know if you have checked out this bloke and what he is doing. http://freematics.com/
He seems to have made some interesting gear for OBD2

[Tazzi]

I don't know if you have checked out this bloke and what he is doing. http://freematics.com/
He seems to have made some interesting gear for OBD2

Yeah I saw that on kickstarter a while ago now. Its cool how it opens up a whole new era for the microcontroller fans. But, you could make your own CAN shield for an arduino for ~$7 including all parts ect.
I did notice that device doesnt support VPW though, but Im not surprised since hes using a protocol interpreter, and there are no "interpreters" for VPW that I know of. It must be developed from scratch, as Iv learnt the hard way with the arduino haha.

I was hoping to utilize the can shied I posted up previously with a bit of bluetooth tech to start developing an OBD2 app for the android/iphone users. Again, itll be based/focused on GM/Holdens.. but thats not for a while

[Tazzi]

Got VPW integrated with the engine gauges and logging at roughly 45 frames per second.
It doesnt use DPID's. Might add that in the future.

Next on the list. Adding in Max and Min values for each PID. This is needed so that the gauges will display correctly, have the correct dial values ect. Im going to be making educated guesses, although try and error on real cars might be better.
Also, I want to add in the units somewhere.. will need to chuck in a label somewhere.

VIN,Serial and faults count on main screen have been added in for VPW. Still need to implement Freeze data and also the PID search. But after those have been added, itll be pretty much complete.

Thats it for tonight...Taz out.

[VL400]

Next on the list. Adding in Max and Min values for each PID. This is needed so that the gauges will display correctly, have the correct dial values ect. Im going to be making educated guesses, although try and error on real cars might be better.

For just error handling type of min/max you can likely work it out on the fly. The ECU will return a value 8/16/32bit, so you know the data size and the equation for it. If its an 8 bit value, just run the equation through with 0 and 255 values to get your min and max.

[Tazzi]

Next on the list. Adding in Max and Min values for each PID. This is needed so that the gauges will display correctly, have the correct dial values ect. Im going to be making educated guesses, although try and error on real cars might be better.

For just error handling type of min/max you can likely work it out on the fly. The ECU will return a value 8/16/32bit, so you know the data size and the equation for it. If its an 8 bit value, just run the equation through with 0 and 255 values to get your min and max.

Perfect, thats mate. Didnt think of that!

[Tazzi]

Everything has been done except the min/max for the gauges.
I thought about what you said VL, and not sure how well that will work, since if something is a 16bit integer, max value of 65000ish will mean that the gauges will display 65000 as max

Using RPM as an example, means that it will barely display the reading (eg 2000rpm) since that value will be insignificant compared to 65000.

Sooo.. I was thinking of another way around this.. the gauges can automatically update their max/min values maybe? So if a value greater than the max is found.. the max will then be calibrated to larger than that value. This also means I would be counting on no errors though.
Dunnooo.. will see what works out best.

[Tazzi]

All done and dusted.. I think. Unfortunately it looks like the PIDs that the CAN ecu support dont all work for the LS1. Currently, the initial startup shows that only 24 PIDs from the VZ PID list are supported.

Sooo... this has to be looked into.. I think the best solution to this, is on startup, all valid PIDs will be added into an array for selection in the engine data tab. If engine info is not obtained on startup (if checkbox is unticked), it will perform the PID test when the PID box is first opened.
This way, every PID that is worked out and collected, can be placed into the main PID list and then later checked for support.

Alternatively.. and this solution is much quicker. Just define different static arrays for VZ V6 and LS1 ecus. Nice and easy.. but no flexibility.

[Tazzi]

Bugger it.. went the extra mile and made the app search for valids PIDs for that ECU, where only these valid PIDs can be chosen in the engine data tab.
At least this will be beneficial when moving onto new controllers.

And, the freeze frame for CAN is working 100% every time. Iv got that completely sorted.

[vlad01]

Nice work!