OBDX Development - Developer Tools and Suggestions

[pmcquay]

Wierd. Everywhere I google, P1665 is evap vent. My truck is nothing special, its an 0411 swapped 96 gmc sierra, running os 12212156, so it thinks its a 2002 express van with a 5.7.

[Tazzi]

Wierd. Everywhere I google, P1665 is evap vent. My truck is nothing special, its an 0411 swapped 96 gmc sierra, running os 12212156, so it thinks its a 2002 express van with a 5.7.

Odd, could be an error int the documentation I have. Id have to simulate it to the tech2 to confirm. Or even a workshop manual should also confirm actually.

[Gatecrasher]

This is an old DVD based copy of SI. Should be accurate enough for a 2002 vehicle.

For reference P0446 is Evap Vent System Performance and P0449 is Evap Vent Solenoid Control Circuit. I can't find an engine oil pressure code for this engine at all.

I noticed similar discrepancies when I was looking through some DTC tables in Universal Patcher.

[Tazzi]

This is an old DVD based copy of SI. Should be accurate enough for a 2002 vehicle.

P1665.jpg

For reference P0446 is Evap Vent System Performance and P0449 is Evap Vent Solenoid Control Circuit. I can't find an engine oil pressure code for this engine at all.

I noticed similar discrepancies when I was looking through some DTC tables in Universal Patcher.

Very odd!
Must be a mistake in the documentation I have!

[antus]

It looks like GM changed it, maybe you'll need to do a VIN lookup by year, or list it as both.

[Tazzi]

It looks like GM changed it, maybe you'll need to do a VIN lookup by year, or list it as both.

I actually see the option where it allows redefining the meaning of certain fault codes, its not common but it does appear to actually happen, I have never paid attention to that before!

[Tazzi]

We are getting close for the remote J2534!
My initial tests have been VERY positive. I can't actually really tell that I am over the internet for small flashes since the round trip time is negligible for me.

But.. I have been having issues with using external resources for the remote API, basically using other DLLs to make all of this possible.
I found out the hard way that if a J2534 application is using the same resource (DLL) that the remote api does, it can result in a resource conflict if they are running two different versions.

This means I have to either:
1) Hackup the library resources I am using to change the GUID and namespaces so it identifies differently
2) Download any github open source options and make similar alterations so it is a separate interface.

This has stumped me for the last week or so unfortunately as I have been trying to allow consuming more then 1 version of DLL, but it doesn't appear windows is setup to allow that.
There are some documentations which demonstrating using two different version DLLs, but the issue is the J2534 application is not something we have control over and cannot specifically define which version their app should use, only our own.

For a relatively simple concept, this has turned into 6 applications (including server side) having to work seamlessly together

For those watching and REALLY eager to use this (You know who you are), we are getting close!

[antus]

I dont understand where the clash is. Wouldn't your driver communicate over TCP (or UDP?) and only have one driver dll loaded on the source pc and one on the target PC, and if so then thats your J2534 API so you can keep it static between versions?

[Tazzi]

I dont understand where the clash is. Wouldn't your driver communicate over TCP (or UDP?) and only have one driver dll loaded on the source pc and one on the target PC, and if so then thats your J2534 API so you can keep it static between versions?

The remote J2534 API DLL is used by the J2534 application (Lets use PCMHammer for instance).

If PCMHammer was to use something like, Newtonsoft JSON DLL library which is different to the version of the remote J2534 API, it results in failure to use the API.

I dont understand the real nitty gritty parts of whats happening, other then the remote J2534 API will not load the embedded resource it has for the JSON DLL as it will try to use the one that PCM Hammer has already consumed.

Im not sure how well thats explained, but basically its just a giant headache.

[Tazzi]

Alright, I have some official times in for using remote over a direct USB connection.
Keeping in mind, I am acting as both Technician and client, and the server is on the other side of Australia meaning ever single message sent has a 100ms round trip.

So I am programming a GM Body Control Module on a bench using an OBDX Pro GT.

When doing calibrations only:
- USB J2534 Time = 13seconds
- Remote J2534 Time = 32seconds
This is a 2.45x difference.

When doing Operating System and Calibrations:
- USB J2534 Time = 106seconds (1min 46seconds)
- Remote J2534 Time = 196seconds (3min 16seconds)
This is a 1.89x difference

The reason the OS difference was not as bad is simply due to it sent larger "chunks" which means the time was better spent. Compared to the calibrations only option which does lots of little files meaning it has more wasted time waiting between each response which is why the direct USB option is able to complete so much faster.

All in all, I am REALLY happy with it.

I will be doing some tests using some other J2534 software to get some more comparisons during the week.