OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
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 »

In-Tech wrote: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:
I found with my own software, the first thing people do is select every single parameter, then ask why the refresh rate is so slow. Never at any point do they think to try reducing number of parameters! At least this way, we seem to kind of maintain a similar refresh rate regardless.
If resolution becomes an issue, we can add some sort of priority system where a specific number of PIDs can be manually polled to increase their display rate.

Last few things to add in left:
1) Dash display. This is not ideal in anyway currently, have to right click and then select the desired PID to display for that gauge. This wouldn't be so bad except I have not implemented a save dash configuration yet.
Eventually there will be some sort of option to select pre-saved dash setups. If a PID previously selected is not available for that vehicle, it will simply leave that gauge blank.

2) Add an auto log saving functionality, also allow exporting into a different format such as CSV.
Exported files will likely have a csv setup of: Time/Date, Parameter Name, Unique ID, Value, Units

The "to-do" list for everything else is absolutely huge still do, but after having the above done, I will feel good for an initial release.
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 »

Its not the most 'pretty' setup, but it is working.

Ill work on the word wrapping for the text in a later revision, but for now, its dynamically adding the max/min values to every single gauge along with units and title.
This surprisingly took longer then expected to get all the gauge ranges and numbers to line up nicely... but its done.
DashDisplayOBDXplorer.PNG
DashDisplayOBDXplorer.PNG (260.02 KiB) Viewed 2112 times
Just need to add the same thing for the center chart... then add an export log option.. and we should be basically good for a release!!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
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 »

Hey Tazzi,

For the homebrew guys, (if you can make sense of what i'm saying), is there a way to have your cable and software running behind the scenes and have the live data available for me to grab with my app and display it on custom gauges that I make?

Reason I ask is for guys like me that haven't got the skills or haven't invested the time to get a custom GM LAN solution up and running by mimicking an HP Tuners device etc to poll for data, we could use your suite of tools to nominate certain PIDs, and you would expose it for us with a easy to use API that we can get running in Visual Studio so that we can write a simple app to do what we want with the PID's. In my case, I would create a custom gauge app with alarms etc and display them on my vehicles mylink via the appropriate GVIF interface boxes.
Untitled.png
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:Hey Tazzi,

For the homebrew guys, (if you can make sense of what i'm saying), is there a way to have your cable and software running behind the scenes and have the live data available for me to grab with my app and display it on custom gauges that I make?

Reason I ask is for guys like me that haven't got the skills or haven't invested the time to get a custom GM LAN solution up and running by mimicking an HP Tuners device etc to poll for data, we could use your suite of tools to nominate certain PIDs, and you would expose it for us with a easy to use API that we can get running in Visual Studio so that we can write a simple app to do what we want with the PID's. In my case, I would create a custom gauge app with alarms etc and display them on my vehicles mylink via the appropriate GVIF interface boxes.
The OBDX tools support the basic ELM command set, so you could use that. You could also use a HC05 bluetooth module in master mode to connect to the dongle wirelessly with your microcontroller project (Which is polling for PIDs ect).
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
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 »

Thanks for that Tazzi. Say I was looking for PIDs that aren't normally available in any app I've ever downloaded from the play store but HP Tuners can get them, can I get those enhanced pids using elm commands? Sorry for the newb questions. Once I get into the project all will be much more obvious to me.
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:Thanks for that Tazzi. Say I was looking for PIDs that aren't normally available in any app I've ever downloaded from the play store but HP Tuners can get them, can I get those enhanced pids using elm commands? Sorry for the newb questions. Once I get into the project all will be much more obvious to me.
If accessible with HP, then its a matter of figuring out the PID value and its calculation to then use with an ELM style application. :thumbup:
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 »

OBDXplorer is finally at a ready state for its initial release. As mentioned (multiple times), theres still heaps to add in, but I would rather have it in peoples hands to trial and provide feedback then spend another few hundred hours in development with no testing for things that need fixing or attention.

I do need to apply some news posts to the obdx pro website so they are reflected in the software. These posts are fed directly from the websites news log (currently only 1 up from long ago), but the intention is to use the posts for informing of updates, new tools or even other softwares available to use which may be of interest to obdx users. Otherwise we are good to go for its release 8-)

On an entirely separate topic, Pete and I have been contacted alot in regards to FD CAN support due to a lack of compatible tools currently on the market from supply issues.
The OBDX GT is capable of FD CAN, but our issue is that the entire flash is used up currently thus I am unable to actually fit the required edits to support the FD CAN protocol. There are some optimization settings I can run in the compiler, although the issue here is they mess with some internal routines and interrupts which are vital for stable bluetooth, usb and CAN. Im sure if I follow some rabbit holes, I may be able to come up with a solution to fix those, but theres no telling what other core items are affected without prolonged usage.
The alternative is going through the quarter mil lines of coding and condense as much as possible. There is three things I know off the top of my head which will help:
1) convert any large if statements to case statements. This does seem to save quite a bit after running over hundreds of statements.

2) The current ELM library checks each character received for both upper and lower case, for example, if will check both "A" and "a" for a specific command. This could be compressed by converting all received data to upper or lower case before being processed. This would honestly remove multiple hundreds of lines of checks, and should hopefully free at least 1k of flash.

A solid fix would be to split firmware into both ELM and DVI protocols. It could work as a dedicated DVI/J2534 firmware, that would be its only real use since CAN FD does not exist in an ELM based application on the planet currently.
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
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by antus »

The ASCII designers did a good job coding some optimisations in to the protocol. Check this: https://catonmat.net/ascii-case-conversion-trick you can just loop through the input bytes before the payload and set or clear bit 6 on each byte to convert to upper or lower in just a couple of bytes of C/ASM.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
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 »

antus wrote:The ASCII designers did a good job coding some optimisations in to the protocol. Check this: https://catonmat.net/ascii-case-conversion-trick you can just loop through the input bytes before the payload and set or clear bit 6 on each byte to convert to upper or lower in just a couple of bytes of C/ASM.
Legend. Between that change and some other case adjustments, have saved about 1k bytes. Not enough to finish FD can.. but... its a start!
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
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by antus »

Do you find yourself doing lots of bit level manipulation? There are many sheets of 'bit hacks' out there which are great to optimise code in small embedded applications like this https://cheatography.com/jsondhof/cheat ... bit-hacks/ https://graphics.stanford.edu/~seander/bithacks.html
You might find you can save some bytes using smaller data types too - depending your coding style if your using 32 or 64 bit data bytes in places where you know the range would fit in a single byte (signed or unsigned) you can shrink the ram usage and the code that does the work with those variables by using smaller data types. You have to be careful though, its easy to get too excited and shrink something too far, and it can be difficult to find what you did. Make sure you use git for your code or something, so that you can divide and conquer if something like that comes up by running different firmware revisions to see where it was introduced and what you changed at that time.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Post Reply