OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
Posts: 35
Joined: Tue Jul 06, 2021 6:57 pm

Re: OBDX Development - Developer Tools and Suggestions

Postby hjtrbo » Sat Jun 18, 2022 9:21 am

Just fucken awesome work tazzi. Eagerly awaiting public release!

User avatar
Posts: 2912
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Mon Jun 20, 2022 11:25 am

hjtrbo wrote:Just fucken awesome work tazzi. Eagerly awaiting public release!

Thanks!
Slowly getting there.

Had to drag out the white board to properly design the ECU implementation class so that its ready to deal with other manufactures for future support, since the way GM does it compared to say Chrysler (FCA) or Ford is not the same.

Anyways, we are up to making the tool do its initial fingerprint scan of the car.
I have a popup which displays with a progress wheel indicating whats going on as it runs through all the PIDs to build its supported list. The box along the top now indicates how many supported PIDs there are, and expands the dropdown menu to show the vehicle details that it found.
Your Local Aussie Reverse Engineer
Site:www.envyouscustoms.com
Mob:+61406 140 726
Image

User avatar
Posts: 2912
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Thu Jun 23, 2022 2:54 am

After quite a few trials and errors, I believe iv setup an ecu implementation class which should be fairly future proof.

I have basically set it up to send the SAE standard requests to get the ecu to report back (ie 68 6A F1), and if it gets a response, it will then request the VIN and work out which manufacture/ecu class to use for the rest of the application.

For now, we only have two main classes, GM VPW and GM CAN. I’d love to go to the extent of decoding vins all the way to give every last detail including RPOs, but this would become quite a lot of work for every manufacture eventually.
For now, just identifying the actually manufacture is all that’s needed, which can be easily determined off the first 3 digits of the VIN. (https://en.m.wikibooks.org/wiki/Vehicle ... (VIN_codes)/World_Manufacturer_Identifier_(WMI))

We should also be seeing the G in the second digit for GM which makes it easy to determine, there are some outliers to this such as a Holden Colorado is MMU for its start of the vin, or some early Holden’s are 6H8.. so there will need to be a few checks in there.

Next step is now applying a method for selecting the desired PIDs. Since there is limited space for how many can be monitored, I have used a tree view to visually indicate how many spaces are left in each 8-) DPID frame. This helps show/explainhow many can be monitored at once, and helps setup the frames so there are no unused spots.

In the event that a specific sensor does not need to be displayed often, these can also be set to a polling method which can be set in intervals of 50,100,250,500,1000,2000,5000ms. This would be for any non time sensitive readings.

Another reason for the tree view setup for PIDs, is for when histograms are enabled which will auto select specific sensors that must be monitored.

Assuming no major setbacks with the DPID setup routines, we should be getting our first demo video with live data within the next week
Your Local Aussie Reverse Engineer
Site:www.envyouscustoms.com
Mob:+61406 140 726
Image

Previous

Return to Tools

Who is online

Users browsing this forum: No registered users and 10 guests