OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
User avatar
lsxautumn
Posts: 21
Joined: Sun Oct 30, 2022 6:36 am
cars: 02 sierra 2500HD LQ4 4L80E
AKA a void that eats all my money

Re: OBDX Development - Developer Tools and Suggestions

Post by lsxautumn »

Tazzi wrote:
I will have an update roll out tomorrow for the OBDX Pro GT which will allow you to turn on J2534 debug logging. This will allow me to see exactly what tis2000 is requesting and we can see why its failing. :thumbup:

I will put a post here when the new OBDX GT driver is released.
Sounds awesome, I'm going to make a fresh windows 7 32 bit VM because I tried tinkering with it again but no success and now Its not even letting me get as far as it was. Also gonna try to see if enterprise edition vs ultimate makes a difference because I know tis2000 will only work with xp pro with win xp machines. I'll be checking for the update so I can send logs here.
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 »

lsxautumn wrote: Sounds awesome, I'm going to make a fresh windows 7 32 bit VM because I tried tinkering with it again but no success and now Its not even letting me get as far as it was. Also gonna try to see if enterprise edition vs ultimate makes a difference because I know tis2000 will only work with xp pro with win xp machines. I'll be checking for the update so I can send logs here.
Just updated the GT drivers with logging now. You should be good to go!
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 »

kur4o wrote:Hi Tazzi,

I got some question that is related to driver being used for t2win discovery. It uses some form of active advertising of the tool, so it can be selected by t2win dialog. I think you already dialed it in the driver.

Can you share some more info what processing is involved for that active advertising. I am trying to make a simulator that will work with some ford programs, but they need active advertised tools to be selected, no passive dlls works.
To get Tech2win to display the tool as an option, you need to make sure you are responding the function:

Code: Select all

 
static public T_PDU_ERROR PDUGetModuleIds(IntPtr pModuleIdList)
where pModuleIdList is a pointer, which stores a 4byte pointer. (So a pointer that stores the address of another pointer).
The object type of the pointer stored is PDU_MODULE_ITEM

The object PDU_MODULE_ITEM contains the item type and a pointer to a list of type PDU_MODULE_DATA
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: OBDX Development - Developer Tools and Suggestions

Post by kur4o »

Thanks Tazzi, that makes sense. I was under impression it uses the same logic with mdi device discovery service that gmident.exe is doing.

Seems t2win is a little different function for discovery.

It seems the only option will be to make a ping network type of service, or whatever it is to make ford program see the tool or emulator dll.
Actually we can joint efforts and make the OBDX tools to be discovered by the ford IDS, it will be a great breakthrough.
Not sure what will come of at the end, but it may be something really simple, or a long time project.
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 »

kur4o wrote:Thanks Tazzi, that makes sense. I was under impression it uses the same logic with mdi device discovery service that gmident.exe is doing.

Seems t2win is a little different function for discovery.

It seems the only option will be to make a ping network type of service, or whatever it is to make ford program see the tool or emulator dll.
Actually we can joint efforts and make the OBDX tools to be discovered by the ford IDS, it will be a great breakthrough.
Not sure what will come of at the end, but it may be something really simple, or a long time project.
The D-PDU API was certainly a very over complicated process to integrate. I ended up mimicking the MDI exactly to ensure I could actually make t2win see the tool.
Once I had it showing 'MDI', I then back tracked all the additions I had done and converted it all to OBDX spec.

As for Ford IDS. Basically IDS is only looking for the Ford VCM2 'name', non blacklisted serials and must be on the newest version available.
All of these can easily be modified from the J2534 DLL. Its more the fact if Ford is going to throw a hissy fit about it :roll: :lol:
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 »

I am actually getting a bit excited for this next release. Remote J2534 Programming. 8-)

I recently programmed a clients BCM, instrument cluster and radio over the web with J2534 using an OBDX Pro GT.
There was something quite satisfying about achieving this remotely, as typically my customers would have had to ship the parts in to complete this!

The customer was originally going to ship the parts to have programmed here, but since he already had a GT available, we went with J2534 over the web using a socket connection to the server between myself and the customer. I expected there to be a fair bit of lag being it was across the world, but it was still extremely quick.!

Things I need to do before release:
1) Setup a cleaner host/client configuration application to allow connections to each other (pass through a socket connection on the server)
2) Test ping from host and client to server to ensure it is within acceptable tolerances
3) Automatic server selection based on ping results (looking to open a few).
4) Prevent high ping connections from working

The purpose of the last item is to prevent flashing across the world or off poor cellular signal. This is purely for the fact of minimizing problems and huge flashing times.

Currently the client side must use a laptop with a basic software which sets up the OBDX Pro scantool, connects to a server and waits for a connection.
Eventually Id like to look at migrating it to an android app as well as smartphones are obviously alot of common for people to have.
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 »

Oh wow thats living the dream, well done!
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
In-Tech
Posts: 779
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: OBDX Development - Developer Tools and Suggestions

Post by In-Tech »

:thumbup: :thumbup: :thumbup: :thumbup: :thumbup: :thumbup:
Tazzi wrote:I am actually getting a bit excited for this next release. Remote J2534 Programming. 8-)

I recently programmed a clients BCM, instrument cluster and radio over the web with J2534 using an OBDX Pro GT.
There was something quite satisfying about achieving this remotely, as typically my customers would have had to ship the parts in to complete this!

The customer was originally going to ship the parts to have programmed here, but since he already had a GT available, we went with J2534 over the web using a socket connection to the server between myself and the customer. I expected there to be a fair bit of lag being it was across the world, but it was still extremely quick.!

Things I need to do before release:
1) Setup a cleaner host/client configuration application to allow connections to each other (pass through a socket connection on the server)
2) Test ping from host and client to server to ensure it is within acceptable tolerances
3) Automatic server selection based on ping results (looking to open a few).
4) Prevent high ping connections from working

The purpose of the last item is to prevent flashing across the world or off poor cellular signal. This is purely for the fact of minimizing problems and huge flashing times.

Currently the client side must use a laptop with a basic software which sets up the OBDX Pro scantool, connects to a server and waits for a connection.
Eventually Id like to look at migrating it to an android app as well as smartphones are obviously alot of common for people to have.
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:Oh wow thats living the dream, well done!
Im sure Im poking the bear with this one.
To my understanding, other J2534 providers like drewtech are kinda looking into this, but they are only allowing their techs (As in drewtech technitians/employees) to connect wirelessly and use their software subscriptions to program modules thus it ends up as a pay per use setup.

I would be interested to see what what the total added time that occurs due to the latency when doing a full read/write of an ECU on either a GM or Ford one for connecting to someone here locally in Australia. That way I can provide a better estimation of added time lag on bigger flash operations.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: OBDX Development - Developer Tools and Suggestions

Post by kur4o »

If you found a way for the flash routines to live longer on pcm ram and use the iso15765 protocol with big buffer, I think lag won`t be an issue, Only downfall will be complete interruption of internet for longer period of time.
Post Reply