OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
hjtrbo
Posts: 125
Joined: Tue Jul 06, 2021 6:57 pm
cars: VF2 R8 LSA
FG XR6T
HJ Ute w/RB25DET

Re: OBDX Development - Developer Tools and Suggestions

Post by hjtrbo »

Just fucken awesome work tazzi. Eagerly awaiting public release!
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

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
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

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 ... fier_(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
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Doesn't look like much has changed on the main screen here, but, there is ALOT happening in the back end.

I have entered in around 300..ish.. live data parameters.. and honestly... majority of them probably will not ever be looked at. There is an absolute shitload more that can be added, but for now it is not worth while until moving into other ecus (Such as diesel). Unless there is something someone specifically requests, those will be the initial parameters.
There are heaps of flag based parameters that could be added, although I have been a bit uncertain what to do with them. Some are bit mapped based where only one bit will ever be enabled at a time, whereas others are multiple bits at a time to indicate multiple options enabled. This becomes a bit of a nightmare to display without individually showing each bit mapping as true/false which may end up being the only viable method to use. I have had to create a few custom math based routines for the bit map based parameters to allow bit shifting/masking and then comparing for a specific value.

Todays goal is to have the PID selection menu processing the data into DPID setup frames. Along with identifying how many DPID buffers are available in the ECU since this can vary between OS's from what I have found.
obdxplorerhomeupdate.PNG
obdxplorerhomeupdate.PNG (70.01 KiB) Viewed 5387 times
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

There are literally no words to describe the pain I have gone through trying to use a devexpress datagrid UI, Iv spent an ungodly amount of hours over the course of two weeks trying to make it work.. but without a heap of hackery.. its just not wanting to play nicely the way its needed. The devs tried helping, but it seems I must use a database thats defined in a specific way to allow the comboboxes inside the datagrid to auto fill with a list of strings. Ontop of that, the UI does not allow manually defining each cell thus it cant even be done manually.

So.. I have fallen back to the old faithful data grid by microsoft since its not painfully over complicated. What annoys me most.. is I had it doing exactly what I wanted in about 25mins. The 100+ hours I invested learning the new grid UI could have likely actually completed the entire logging side of the application!!!! :roll:

Lesson learnt... new is not always better!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Working with flag parameters has been an interesting task to work out how to actually display and calculate them.
Alot of GM flags are a combination of bit math and addition to check specific values.

An example may be:
start bit 4
bit length 3
Then over those three bits, it may have:
1 = driver window down
2 = driver window up
3 = passenger window down ect ect

Or it can also be if a specific bit which has specific meaning.
So I have set up the bit math ie. ( ((x @>> 1) @& 0x1) ==3 ) so that it does the require shifting and masking.. then allows checking if the value matches something expected. A true or false answer can then be submitted.
Im currently using the mXparser plugin, will require purchasing a commercial usage although its not very pricey.

I have just finished the routine that dynamically assigns each PID to a frame. This was originally going to be a user based entry, but there does not appear to be any benefit doing it like that.
Each DPID object the holds the list of PIDs in it, which can then be compared against the received frames DPID number and finally loop through each PID in that object to calculate the result.

Last thing is to then either bind variable to the gauges so they auto update, or just make a simple void routine to check each gauges marked ID against the PID and update if matching. The later is probably the easier option plus allows introducing a replay mode to replay a log.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Logging is outputting nicely, left it going for a few hours today and didnt skip a beat.
Its obviously not in car, but wanted to ensure there was not going to be any issues with tester present messages ect.
Im going to be measuring the frames per second instead of the PIDs per second, since technically each 'frame' is multiple PIDs, so it becomes a bit messy to try count parameters per second.

Its currently just splitting out to the debug view just so I could verify that the math parser is working the way it should be.

I will get able to go for a run in my ute once I complete the DPID setup for the CAN side 8-)
OBDXplorer_logging.PNG
OBDXplorer_logging.PNG (87.53 KiB) Viewed 5181 times
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Finally coming into our last stages of the logger. We have the list view now working, graphing and now finishing off the dash display.

Couple things to note though which may cause delays:
1) I am not happy with how the bitwise parameters are setup yet. A perfect instance of this is a PID for locations of O2 sensors, where each bit defines a different O2 sensor location if its present. The only real valid way of displaying this is to set each individual bit as its own parameter to select from in the list, that way its calculation would simply be true/false (Or Yes/No). This makes it much more feasible to display on graphs and much easier to understand.
The main issue here is the way the system is currently designed setup logging for each PID, it relies on each PID to have its own unique value. Splitting up Flag PIDs into individual options means they technically have the same ID so the automated DPID setup routine will need to verify if the same PID has already been loaded into a DPID and skip to the next.

2) For the life of me, I cannot get the graphing to set the axis Y colour to match the series line colour. This is actually kinda important since it make it possible to which axis is which. Currently I have set it up to allow 6 parameters per graph, with a max of 6 graphs, so this would provide 36 PIDs to display on all the graphs. I will need to figure a method of removing/replacing per graph so its user configurable. Alternatively I need to figure out how to make a scrollable graph which adds a new graph pane after a specific number of sensors are added.

3) I have no clue how to deal with setting the dash display options. Selecting from the main parameter screen becomes a bit of a nightmare. So I believe the only real option is either a right click on the gauge to set the parameter, or a pop up box which will allow customizing the gauges.. or even loading a preset maybe?
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Logging logging logging.. honestly, I could go without looking at a graph from quite a while after this.
After some trial runs with the software on a P59,P01 and P04 ecu, it seems our average frames per second is around 10-12 ish.
When 2 DPIDs are loaded up (roughly 6-8parameters together), this means there is about 5-6 frame updates from the ecu per second per DPID.

This then corresponds to 6 frame updates per PID per second. So, its not exactly lightening fast which I am not exactly thrilled about, but it is consistent. The speed is how fast the ECU is pumping it out, it is not controlled by the software in anyway.

Singular PIDs could probably be read faster by manually polling the ECU, I know that can get upwards of 40-60frames per second off the top of my head. But obviously this reduces as more pids are requested and time must be shared polling.

I have limited the chart to 16 PIDs (4 charts). Personally... I would never need to look at that much all at once, as it starts becoming a mess doing so. Will need a method to change around the charts setup at some point so that IF you select more then 16 parameters, you can then define which will show in the 4 charts of graphs.

This just encourages people to only log what is absolutely necessary so that the update rate per PID is maximized, rather then trying to log 40+ PIDs are once simply because they are there!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
In-Tech
Posts: 778
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: OBDX Development - Developer Tools and Suggestions

Post by In-Tech »

It really does sound good, Tazzi. The ability to lower the pids polled and increase the frame rate is awesome. AE is about the only reason you would need to monitor that fast. TPS, MAP, RPM(maybe), AFR. If there is a way to monitor external AFR/Lambda and TPS/MAP at 25hz, what a gift :thumbup:

The stuff you do always impresses :thumbup:
Post Reply