OBDX Development - Developer Tools and Suggestions
Re: OBDX Development - Developer Tools and Suggestions
Yep I understand, I think I have managed to get past it.. basically when its asking to do CANbus, Im making it return back an invalid parameter... and it seems to skip and move on back to VPW.
With that said.. we are now reading live data!!
With that said.. we are now reading live data!!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: OBDX Development - Developer Tools and Suggestions
Just a quick video showing tech2win working. It seems to load live data so much faster then the dear old MDI, I use to think it was just tech2win being slow, but it appears to be heavily reliant on the DPDU DLL processing speed.
Only thing left is to test with more VPW modules connected, or in an actual car!
Theres quite a few hours of development to put into this to clean up some coding, and finish off other routines including those used to close/shutdown tech2win.
Ontop of that is making an installer to add the DPDU DLL plus register it into the Windows directory (C:\Program Files (x86)\D-PDU API) so that it can be found by Tech2win.
The D-PDU implementation is also specifically targeting GMs tech2win only. I say this simply because of how tedious this API is, and its been specifically designed only around with tech2win to meet its specific requests and requirements. I know theres a couple other dealership softwares out there which support DPDU api including Chrysler, but those will need to be looked at on another rainy day.
Once the J2534 and D-PDU APIs are released, can finally move back to the OBDX GT to add a few new commands to make J2534/D-PDU implementation easier for ALDL/CANBus, along with finishing off the GT's reference manual documentation.
Only thing left is to test with more VPW modules connected, or in an actual car!
Theres quite a few hours of development to put into this to clean up some coding, and finish off other routines including those used to close/shutdown tech2win.
Ontop of that is making an installer to add the DPDU DLL plus register it into the Windows directory (C:\Program Files (x86)\D-PDU API) so that it can be found by Tech2win.
The D-PDU implementation is also specifically targeting GMs tech2win only. I say this simply because of how tedious this API is, and its been specifically designed only around with tech2win to meet its specific requests and requirements. I know theres a couple other dealership softwares out there which support DPDU api including Chrysler, but those will need to be looked at on another rainy day.
Once the J2534 and D-PDU APIs are released, can finally move back to the OBDX GT to add a few new commands to make J2534/D-PDU implementation easier for ALDL/CANBus, along with finishing off the GT's reference manual documentation.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

- antus
- Site Admin
- Posts: 9034
- 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







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
-
- Posts: 311
- Joined: Fri Jul 30, 2021 5:49 pm
- cars: 97 Corvette
92 Camaro
2005 Silverado
2001 Savana 2500
1998 c3500hd
1998 tahoe
Re: OBDX Development - Developer Tools and Suggestions
Looking forward to buying a gt! Impressive work Tazzi, 

Re: OBDX Development - Developer Tools and Suggestions
Cheers guys!
Will keep pushing on. Working on the installer today for J2534, I bet antivirus's are gonna absolutely freak out with this since its adding to the registry, creating folders and saving applications.
Also need a settings application to enable/disable debug logs, along with any other basic options/changes that might be required.
I mean, it can't be worse then the flags that VX nano's get, since their installers add files into the system32 folder. I mean.. that has to be the biggest 'no no' of all time. I believe its done for obscurity so people don't find the DLL which handles all the J2534 comms, but it almost always gets deleted by all antivirus's.
I have been talking to Pete about making a harness for OBD2 to OBD1 12pin so that the new GT will also work with the older trucks. Main issues here is the 12pin doesnt have a battery pin.. so it will require external power such as USB. Next issue is all the cheap OBD1 to OBD2 harnesses have incorrect pinouts, since we require pin E+M on the OBD1 to connect to pin 9 on the OBD2. Best options I can see is either cutting off the OBD2 header on those harnesses and wiring to an OBD2 header.
Or, use an open ended version such as this: https://www.med-obd.com/cable-daewoogm- ... p-855.html
And wire that to an OBD2 header. I don't see huge amount of people going to use it for the older GM trucks, but if it works with tech2win, it might be worth the hassle for a few.
Will keep pushing on. Working on the installer today for J2534, I bet antivirus's are gonna absolutely freak out with this since its adding to the registry, creating folders and saving applications.

Also need a settings application to enable/disable debug logs, along with any other basic options/changes that might be required.
I mean, it can't be worse then the flags that VX nano's get, since their installers add files into the system32 folder. I mean.. that has to be the biggest 'no no' of all time. I believe its done for obscurity so people don't find the DLL which handles all the J2534 comms, but it almost always gets deleted by all antivirus's.
I have been talking to Pete about making a harness for OBD2 to OBD1 12pin so that the new GT will also work with the older trucks. Main issues here is the 12pin doesnt have a battery pin.. so it will require external power such as USB. Next issue is all the cheap OBD1 to OBD2 harnesses have incorrect pinouts, since we require pin E+M on the OBD1 to connect to pin 9 on the OBD2. Best options I can see is either cutting off the OBD2 header on those harnesses and wiring to an OBD2 header.
Or, use an open ended version such as this: https://www.med-obd.com/cable-daewoogm- ... p-855.html
And wire that to an OBD2 header. I don't see huge amount of people going to use it for the older GM trucks, but if it works with tech2win, it might be worth the hassle for a few.
- Attachments
-
- GM-OBD-12P-OBD1-to-16Pin.jpg (16.98 KiB) Viewed 2514 times
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

- antus
- Site Admin
- Posts: 9034
- 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
usb power is good, otherwise the connection drops when power cycle the car with the key.
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
-
- Posts: 311
- Joined: Fri Jul 30, 2021 5:49 pm
- cars: 97 Corvette
92 Camaro
2005 Silverado
2001 Savana 2500
1998 c3500hd
1998 tahoe
Re: OBDX Development - Developer Tools and Suggestions
Gonna chime in and just say that I wouldn't concern with obd1 as it's so obsolete that unless it's super easy, it's a bad investment of time since getting modern compatibility is so much more important. Just my 2¢.
Re: OBDX Development - Developer Tools and Suggestions
I agree to a certain extent. I provide diagnostic tools/softwares for OBD1 (ALDL) here, and the only reason they are popular is because I make the software easy to use. Otherwise people were absolutely screwed, having to go to dealerships at $150 minimum to hookup a scanner. This is more then it is to buy the diagnostic tool and just read out your self, in your own time.Cincinnatus wrote:Gonna chime in and just say that I wouldn't concern with obd1 as it's so obsolete that unless it's super easy, it's a bad investment of time since getting modern compatibility is so much more important. Just my 2¢.
Even having a 'diy' solution to post up for those wanting to spend the time to get connected to the U.S ALDL port with an OBDX tool is better then nothing. From my readings, theres a few (very average) ADX's for logging some live engine data, but thats about it for the trucks. Having the ability to use Tech2win does give the average joe quite the advantage... and might even encourage programmers to make some standalone software for them

On a side note.. I am bias to ALDL. Cause well... its caused the least headache in comparison to VPW and CANbus.

Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: OBDX Development - Developer Tools and Suggestions
Seems Im being backed into a corner by Windows, seems its getting more strict with what applications modify.
To make one of the required edits for the DPDU installer, we need to add or edit a file in Program Files(86)/D-PDU API/pdu_api_root.xml
To edit that, we obviously require administrator privilege's. This seems to be triggering Antivirus's to instantly stop the program from adding to that location or editing the file that exits.
I signed the program with one of my own Envyous certificates.. and the AV no longer triggers. I do feel like almost all AVs have becomes incredibly over precautious lately, and basically remove anything they don't have much history on.
So might have to look at doing an EV certificate for OBDX before this can be properly released to the public. As AVs are clearly wanting to be able to pint point companies/individuals to blame if they were to distribute a virus.
To make one of the required edits for the DPDU installer, we need to add or edit a file in Program Files(86)/D-PDU API/pdu_api_root.xml
To edit that, we obviously require administrator privilege's. This seems to be triggering Antivirus's to instantly stop the program from adding to that location or editing the file that exits.
I signed the program with one of my own Envyous certificates.. and the AV no longer triggers. I do feel like almost all AVs have becomes incredibly over precautious lately, and basically remove anything they don't have much history on.
So might have to look at doing an EV certificate for OBDX before this can be properly released to the public. As AVs are clearly wanting to be able to pint point companies/individuals to blame if they were to distribute a virus.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: OBDX Development - Developer Tools and Suggestions
I ran into the same problem with a fresh install of Win 8.1 recently, I found that editing the registry to bypass the restrictions was the best workaround, then when I was happy with the installation setup, restore the registry string back to what it was.Tazzi wrote:Seems Im being backed into a corner by Windows, seems its getting more strict with what applications modify.
To make one of the required edits for the DPDU installer, we need to add or edit a file in Program Files(86)/D-PDU API/pdu_api_root.xml
To edit that, we obviously require administrator privilege's. This seems to be triggering Antivirus's to instantly stop the program from adding to that location or editing the file that exits.
I signed the program with one of my own Envyous certificates.. and the AV no longer triggers. I do feel like almost all AVs have becomes incredibly over precautious lately, and basically remove anything they don't have much history on.
So might have to look at doing an EV certificate for OBDX before this can be properly released to the public. As AVs are clearly wanting to be able to pint point companies/individuals to blame if they were to distribute a virus.
I even went to the point of adding the certificate of signed files to the trusted root authority in the registry and still was prompted with nags about permissions.