OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
Post Reply
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

This first post will be updated with links and information related to OBDX Pro tools and development. :thumbup:

OBDX Pro VT J2534 API Installer: https://obdxpro.com/downloads/
OBDX Pro VT DPDU API Installer: https://obdxpro.com/downloads/

Features and tools being worked on currently include:
• OBDX Pro VC and GT Firmware Finalization
• OBDX Pro GT J2534 API - CANBus and ALDL
• OBDX Pro DVI protocol example projects in Visual Studio
• OBDX Pro VC and GT Developers Reference Manuals



********************************************************************************************************************************
********************************************************************************************************************************
****************Original Post Below****************
Before OBDX was even an idea, it was loose wires on a breadboard, trying to get Petes hardware design to work with a custom command set I built some time ago, to say the first prototype was a bit sketchy.. is an understatement :lol:

Fast forward a couple years and we now have a few new products on the horizon to release which include:
• OBDX VC - This is the USB only (in an ELM style case) edition with VPW only, this is designed to be as cheap as humanly possibly.
• OBDX VX - This is also USB only (in an ELM style case), which will be ALDL, VPW and High Speed CAN
• OBDX GT - This is the big brother to the VT, in our normal VT style case with USB,BLE,Classic Bluetooth and WIFI which will support ALDL, VPW, HSCAN and GMLAN.

With the above said, from day 1, I have had the mind set of having useful developer options and commands inside the tools firmware, basically everything I personally would have wanted when either making software or when reverse engineering cars or tool responses. I did not want just a remake of current tools, I wanted them to allow devs to have almost direct control and access to the communication line without any restrictions.

The most recent additions into the firmware have been these two items:
1) A timer to set send off custom messages. (Useful for tester present messages)
2) Auto responder, which will automatically send off a specific message when it receives a specific message
Both of which are supported using the ELM command protocol also (just use a simple serial terminal to send string commands).

Those two are something I use on a daily basis for my own R&D. They have made reverse engineering a hell of alot faster and easier, and also made flashing modules safer since the scantool continues to send the tester present even if a software was to lockup for whatever reason.

From a scantool, is there any features anyone would want implemented? I am all for making these the most versatile scantools on the planet. :thumbup:

Things I have thought might be useful to implement:
• Battery voltage monitoring - auto send a message when voltage drops below certain threshold
• Eeprom area - for custom user data or software settings.
• Sleep mode - detect no communication from software after X time and go into low power mode?
Last edited by Tazzi on Wed Apr 27, 2022 4:06 pm, edited 3 times in total.
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 range looks good.

Standalone logging would be a nice feature? Maybe the big boy gets some storage on i2c?

Also please test the Bluetooth ALDL implementation against some of our ADXs for 11P/12P/Enhanced including with oseplugin. The lag introduced by BLE might mean ADXs which work on Pcmhacking ALDL interfaces do not on these. If thats the case I think you should warn users of this or state not compatible with ...? before they have problems to assist with unhappy customers and support.
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
Gareth
Posts: 2505
Joined: Fri Mar 14, 2014 8:37 pm
Location: Bacchus Marsh, Vic

Re: OBDX Development - Developer Tools and Suggestions

Post by Gareth »

+2 for logging
According to chemistry, alcohol is a solution...
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 range looks good.

Standalone logging would be a nice feature? Maybe the big boy gets some storage on i2c?

Also please test the Bluetooth ALDL implementation against some of our ADXs for 11P/12P/Enhanced including with oseplugin. The lag introduced by BLE might mean ADXs which work on Pcmhacking ALDL interfaces do not on these. If thats the case I think you should warn users of this or state not compatible with ...? before they have problems to assist with unhappy customers and support.
Hmm, stand alone logging would probably be something that could be implemented once an SD card is added. We cant do that until the case is able to accommodate which is when we will do a full custom case mold/manufacture. Fantastic idea though!
I guess this could also move onto monitoring external sensor readings as well, just have a simple 0-5v analog reading using some screw headers on the side also.

As for ALDL support with Tunerpro, the ALDL part uses a command line structure, so its not raw ALDL frames that are sent to/from the tool.
The pros of this method means the tool looks for heartbeat or free space to send a message instead of the smartphone/computer. Once the frame has successfully sent, it will respond with a success message (Much like the AVT). Any frames received back are passed through (as per usual) straight to smartphone/pc using the command structure. So even if its BLE or a long distance WIFI, the tool doesnt rely on the timing of the smartphone/PC since it does it itself. :thumbup:

The cons of this method, is all softwares that rely on the raw ALDL communication then lose their support until support with the command structure is added.
So... its support could be added into tunerpros ADX's, but the commands would need to be implemented and offsets for data changed since the received data frame will have command structure data/length at the beginning (just like AVT).
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: OBDX Development - Developer Tools and Suggestions

Post by bubba2533 »

Standalone logging is a top priority for me.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
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 »

I guess as a temporary solution, a simple iOS/Android app could be made to just save the data to a CSV file which could then be analysed later?
I'll ask Pete about it, likely will need to shuffle some pins around to access the SPI pins and either get flash or sdcard slot added :)
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 »

Ive been doing some searching for something to recommend, but it seems mainstream SOIC-8 chips dont have anything that'd be big enough. So TF card would likely be your best option in a package of that size. But an Android/IOs app using the interface as an interface would probably tick the box for most people and be a lot easier for you to implement and people to use. And it could come later without any changes to the hardware.
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
MudDuck514
Posts: 397
Joined: Wed Jul 05, 2017 8:30 am
cars: 2001 Pontiac Grand AM SE
LD9 2.4l I4, 4T40E
2005 Chevrolet Venture
LA1 3400 V6, 4T65E
Location: North TX, USA

Re: OBDX Development - Developer Tools and Suggestions

Post by MudDuck514 »

Hi all;

Tazzi, Is this a good time to inquire about the GM D-PDU API support for Tech2Win?

Mike
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 »

MudDuck514 wrote:Hi all;

Tazzi, Is this a good time to inquire about the GM D-PDU API support for Tech2Win?

Mike
Well, its not 'hard' to add. Its just time consuming. Have to ensure all the main commands and their settings are added.
There were two individuals which contacted me about this, both wanted to make it and sell it for a small fee. I have yet to hear anything more or see any progress so its likely going to have to fall back onto myself to make it. :roll:
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 »

Places like drewtech put the D-PDU and J2534 into the same DLL. Since the "commands" are all communicating to the same instance/object of the scantool itself, it wouldnt matter if they are in the same DLL.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Post Reply