OBDX Development - Developer Tools and Suggestions

[Tazzi]

OBDX J2534 installer has been made, I will update the first page with a link shortly.
Logs are made mandatory at the moment and are saved to: C:\Users\<YOUR USERNAME>\AppData\Roaming\OBDX Pro\J2534\Logs

Every single session will save a new file. Files will also update based on the date.
An SPS session roughly creates a 1750kb file for writing to a P01.

Antivirus's are probably going to flip out, so do be aware of that. I have just started the process for an EV Certificate, but this could take over a month to actual have done to start signing the applications with.

[antus]

Most excellent. If it supports my VT i'll do some testing and report back.

[hjtrbo]

Awesome Taz. I'd like to be one of your first customers. Have a few things to do on the car so will be able to provide good logs. E67 + T43

[Tazzi]

First page now has updates on OBDX projects being currently worked on.
Along with also the OBDX pro VT J2534 DLL v1.0.0.0 Installer.

As before, installer may throw a virus error, but it is infact safe. I tested with GM SPS2 and PCMHammer before uploading, both worked perfectly with it.
I will release the DPDU API after I clean up its coding and redirect the logs to a dedicated folder, just like J2534.

Next, as OBDX's support both USB and wireless, I can implement wifi or bluetooth connectivity for both J2534 and D-PDU. I might toy with it and just see how latency holds up with it, but Im wondering if its not done by any of the big guys for a reason.

[MudDuck514]

First page now has updates on OBDX projects being currently worked on.
Along with also the OBDX pro VT J2534 DLL v1.0.0.0 Installer.

As before, installer may throw a virus error, but it is infact safe. I tested with GM SPS2 and PCMHammer before uploading, both worked perfectly with it.
I will release the DPDU API after I clean up its coding and redirect the logs to a dedicated folder, just like J2534.

Next, as OBDX's support both USB and wireless, I can implement wifi or bluetooth connectivity for both J2534 and D-PDU. I might toy with it and just see how latency holds up with it, but Im wondering if its not done by any of the big guys for a reason.

Awesome work Tazzi.

Don't some of the GM MDI tools support WiFi?

Looking forward to the release of the DPDU support.

Mike

[Tazzi]

Awesome work Tazzi.

Don't some of the GM MDI tools support WiFi?

Looking forward to the release of the DPDU support.

Mike

That’s correct, but they are not a direct connection (point to point) off the top of my head meaning you have to set it up with a router ect (I believe).

The OBDXs support a direct wifi connection so it’s a bit more straight forward.

I’ll test using Bluetooth, I expect it will be fine since lsdroid uses Bluetooth on android devices.

Almost done with dpdu. Currently working on having windows AV not lose its shit with the registry/dpdu xml editor. If I remove the xml editing.. it seems to not trigger. It must believe it’s injecting unsafe edits to a file it shouldn’t need to. Maybe renaming the original xml then creating a fresh one might bypass it.

[Tazzi]

OBDX VT Tech2win (D-PDU) API installer is now up.

Tested using Tech2win with Holden card on a VY LS1 and VZ LS1 ECU.
I have not tested with the GM card for USA vehicles, but that will be the next thing to test out.
Do note you MUST have the OBDX driver installed otherwise the OBDX API will not detect the cable.

Next, selecting other modules of the car which do not use VPW can result in crashing tech2win. Please make sure you are only selecting modules that use the VPW (J1850) protocol.
If you are unsure if it does, you will find out pretty quickly as tech2win will either say "Unsupported", "No communication" or will crash. Selecting an unsupported module will not damage the vehicle, but may result in tech2win getting hung up.

Logs are mandatory on this beta, logs will go to: C:\Users\<USER NAME>\AppData\Roaming\OBDX Pro\D-PDU\Logs
In the event of crashing or problems, simply zip up the newest log and upload here for review. No personal information is collected in the logs, it only shows the API requests to/from from tech2win.

*Edit
Removed installer since I am missing adding the root directory location in the registry. Just updating the command line app to fix that up. This is required so that the tech2win knows where to look for the root DPDU directory which indicates all the installed manufactures and locations of their library files.

[Tazzi]

Almost fixed up. I had a mistake which was not writing to the correct WOW6432 folder required for 64bit computers.
Will be back up by end of today.

Something that I think might be of interest to technicians, is over the web diagnostics and programming.
Now, this is extremely experimental, but I connected my laptop to my phones hotspot, then in my j2534 coding.. I had it forward the request to my server.. which then forwarded it onto my desktop.. and finally to the scantool. This did successfully flash the PCM, it did take longer.. but it worked.

The reason I believe this works, is due to two things:
1) When a call is made to the J2534 DLL, the DLL then has full control. Techline has to 'wait' until J2534 dll returns back from the function. This means it can take as long as it needs.
2) My PC and phone are both in Australia, and connecting to a server in Singapore.. so the delay was not (That) long.

I tried googling this, and doesnt seem to really have much information of companies attempting it.

Now, I KNOW the P01/P59's manually send the tester present messages instead of using the inbuilt periodic message routines that J2534 supports. This is important since if there was a large lag between messages, then the rest of the car modules may wakeup.. and force the ecu back into 1x mode.. and possibly make the GM kernel dropout.

Possible solutions for this:
1) When using internet flashing, possibly enforce sending periodic tester present messages? This will keep the vehicle happy even when waiting for the next command.
2) Use Azure or Amazon servers to ensure (extremely) fast connections.

Now to top this off... there is NO reason for using a laptop on the client end. A smartphone would also work in this situation, since its taking commands from the server.. and forwarding to the scantool.

[Tazzi]

D-PDU for tech2win is back up again.

Please note there is most then likely some slow memory wastage with tech2win, I still need to go through with a fine tooth comb to release allocated memory since tech2win just 'closes' entire sessions without calling the correct requests to clear memory first.

Next on the list.. is back to development with the OBDX Pro GT, and getting CAN bus (500kb/s) and gmlan working for J2534.

[Tazzi]

Since trying to develop with SPS2 is extremely painful, we are going to develop with GDS2.
Logging GDS2 with the MDI.. we see it starts up opening a protocol of ISO15765 (CANBus) and sets to 500,000 which is to be expected.

It also sets it up to accept 11bit and 29bit frames.

It then sets 16 29bit filters.. and then fires off a single frame. From there it begins trying to search for a response which it does not.
Finally it clears each filter, disconnects from that protocol and reads the scantools version.

It repeats the above gain using different 29bit filters.

On the third protocol attempt, it sets 11bit filters and then fires off 7DF 09 02 , which is a universal SAE command that the engine computer should respond with its VIN.

We then receive two updates from the PassThruReadMsgs which are:
1) TX_MSG_TYPE|TX_INDICATION
2) START_OF_MESSAGE

The first message is simply telling us the TX was successful, and the second message is indicating its received the initial frame from the ECU, and that it has multiple parts.

read message request spits out:

Code: Select all

PASSTHRU_MSG (1 of 1)
        ProtocolID:                               ISO15765
        RxStatus:                                 No Flags Set
        RxStatus:                                 0 
        TxFlags:                                  No Flags Set
        TxFlags:                                  0 
        Timestamp:                                $09EF884A (166692938) 
        DataSize:                                 24 ($18) 
        ExtraDataIndex:                           24 ($18) 
        Data [Read]:                              00 00 07 E8    49 02 01 31    47 32 5A 48    35 37 4E 31    
                                                  38 34 32 35    35 35 30 36    

    pNumMsgs:                                     4581F754 
    pNumMsgs [IN]:                                300 ($12c) 
    pNumMsgs [OUT]:                               1 ($1) 
    Timeout:                                      0 

We can see here that out data size is the entire size of the data that has come in.
The extradataindex is set to the end of the datasize since it is unused.

Our data here indicates:
7E8 = from ECM
49 = response to mode 09 request
02 = sub mode
01 = (1)
and rest is 16 digits of VIN: G2ZH57N184255506
The first character in this vin is 1.

At this point, GDS2 has accepted the scantool and is ready to select the vehicle/module