OBDX Development - Developer Tools and Suggestions

[Tazzi]

I’ll also assume it’s fixed because I no longer risk using it.

Thats not a problem. Each to their own!
Since our focus is working with willing developers and individuals, we cannot expect everyone to be like that or be willing to take time away to email logs.

Regardless, back to it!

This morning I have been lucky enough to have a cardaq3 and MDI2 on loan, we have some interesting results flashing some of the trouble some GMLAN based modules.

The main points for cardaq3:
1) When the module requests 1ms, it is doing approximately 2-4ms
2) Out of 30 flashes on one of these modules, we have had 12 failures (37% failure rate)
3) When forcing it to 2ms (I am sending the flow control before the module responds), we are seeing 5-8ms delay (0% failure rate)
4) We see random spikes of longer delay times, I would guess this is interrupts running in the scantool operating system.

The main points for MDI2:
1) 100% failure rate with Techline, it would not accept flashing the bootloader. Appears to be too large for its memory??
2) Similar delays to what the MDI1 does. Occasionally had next to no delay directly after a tester present message which appears to be a fault/timing issue.
3) When flashing with my own software, only 1 failure out of 30.

With that said, I believe I am out of options for tools to test against that I know supports GMLAN
I can genuinely understand why technicians have a dozen different J2534 tools now since every tool manufacture has a different delay multiplier that they follow as a safety barrier.

I don't believe having to use OEM specific tools is needed, the MDI2 is meant to be GMs flagship tool and it technically doesnt seem to even support this properly

I guess I am just going to keep going through module after module with delaership tools and OBDX tools until I find something that doesnt work to repeat all the tests again!

[Tazzi]

Updates have rolled out for VX, GT and FT scantools.

This update is to help address to the controllers that request a slower communication between CAN frames which the OBDX adds a bit of a 'buffer zone' ontop of.

I have flashed several thousands of times with a bunch of OBDXs all hooked up to the bench between various GM/Ford/FCA modules, so I am feeling very confident on it.

The latest release of the OBDX Pro VX J2534 API driver is also up, along with an update for both the FT and GT J2534 APIs.
All of these J2534 APIs will require the tools on their latest versions to be able to run, a warning message will pop up indicating an update is required if running old firmware.

The OBDX Pro FT developers guide has also been updated and uploaded to the downloads page too.

[Tazzi]

An update for the GT J2534 (v1.5) will be available shortly, I am going to be marking it as 'beta' on the website since I need to find some more VPW based ECUs to test with GM Techline/GDS2 and other J2534 tools before I feel confident pushing it to the core API.

This update makes a small edit to how filters are dealt with for VPW to jerry rig a fix for PCMHammers current 021 release.

[Tazzi]

Ahhhhh HA!! I have finally found a VERY incompatible ECU that affects all scantools that I have found so far.. Finally something the GM MDI absolutely cannot handle.

Im working on a FCA based ecu currently, and it does the following:

Code: Select all

07E8  8  30 08 00 AA AA AA AA AA 

07E0  8  21 00 00 0C 00 00 00 20 
07E0  8  22 00 00 00 00 00 00 00  
07E0  8  23 00 00 00 00 00 00 00 
07E0  8  24 00 00 00 00 00 00 00 
07E0  8  25 00 00 00 00 00 00 00  
07E0  8  26 00 00 00 00 00 00 00  
07E0  8  27 00 00 00 00 00 00 00  
07E8  8  30 08 00 AA AA AA AA AA 
07E0  8  28 00 00 00 00 00 00 00  
(Stops here and errors) 

Looking at our first flow control (FC) message from the engine computer:
07E8 8 30 08 00 AA AA AA AA AA
Where
7E8 = engine computer ID
30 = flow control message
08 = Send only 8 frames only, and then I MUST send another FC before you can proceed. (I call this FC mini blocks)
00 = Send as fast as you can

Now... after 7 frames... the flow control got sent.. yet the MDI was waiting to send 8 fames and THEN receive the FC.
When it doesn't see the FC after the 8th frame, it errors.

As far as I am aware, only the factory witech tool seems to handle this and actually work.
My guess is the ECU is incorrectly counting, so the 8th frame technically is the start of the next FC mini block, and the witech tool is seeing the message then restarting its counter instead of erroring.

Not a single tool seems to handle this so far, since it completely breaks the SAE standard.

But.. easy to fix when you know what your looking for.
Next tool update will have a check if any CAN frames are received while writing in a FC mini block.
If it detects a flow control message early, it will update its internal counter to reset and continue writing.

A simple yet effective fix.

[Tazzi]

Been having a blast with development on our prototype OBDX Pro ONE recently. This tool is designed to have all the main OBD protocols (with J2534/DPDU support), and any of the major new OBD protocols such as GMLAN, MSCAN and FD CAN.

We have finally dialled in on a PWM circuit we are happy with, along with implementing IOS4142 and its newer brother KWP2000 (both kline).

With those now implemented, there is technically no other core OBD2 protocols to support. The last couple to implement realistically is FD CAN (Which is very simple to add) and also ethernet.
For ethernet, it looks like manufactures are quite literally just using a USB to ethernet adaptor which gets soldered to an OBD2 header, so really its all software based to have that up and working.

Other then that, the only real other things to do is add relays for various pin switching. Pete and I have been discussing the idea of adding a grounding relay to the design, to allow applying ground to a specific pin (likely 15). This is due to various software manufactures out there using 'unlock boards' or 'boot boards' that require controlling a relay where they use a pin on the scantool to activate and deactivate.'

The processor we intend to use provides a heap more flash and ram space which opens up alot more room for new abilities, but funny enough, I believe I have run out of possible ideas!
The only other possibility we thought about was having direct ADC connections for external sensor logging, but since our case does not have any open slots, its not really realistic to do.

[???]

do you have any desire to add the functionality or whatever it's called so the extended pids from modules other than the ecm work with tq app or other phone apps?

I have one of those 30$ ones that they work with, but wouldn't mind keeping that in my other car and using my OBDx as the daily dongle too.

[Tazzi]

do you have any desire to add the functionality or whatever it's called so the extended pids from modules other than the ecm work with tq app or other phone apps?

I have one of those 30$ ones that they work with, but wouldn't mind keeping that in my other car and using my OBDx as the daily dongle too.

Is this for GM vehicles? I have the paid torque app, I don't believe I have had any issues with torque although I dont think I have used the enhanced PIDs before.
I wonder if they are doing something weird with filters.

What vehicle are you connecting to also? Is it VPW or CANbus based?

[???]

I've tried it with 2 gm vehicles and 2 apps.

a 2011 yukon hybrid, I found the pids online for the hybrid battery stuff. it's nice to see easily. the standard preloaded pids work, but the added ones don't. this is the next vehicle I'm going to use the OBDx to do module upgrades from the acdelco site.

and a different app called car scanner pro for my 2014 volt. the app comes preloaded with the hybrid pids and some others. I don't have them to add to tq app, so I just use car scanner. with the OBDx, it displays the simple engine stuff but not the extras. this is the car I specifically bought the OBDx to upgrade a module on, there was a updated software for the battery charging/balance module and I missed the free window for gm to do it. so I was able to do it myself with your tool for less than gm would charge me.

I have a 08 c6 I can try to test on. but I don't have any extra pids for it. I would like to find stuff like tranny temp, I know it's there in hp tuners and my clone tech 2 but those are a hassle, so I don't pull those out unless there's a problem. I don't know how to snife out pids, even thou I'd really like to lean that. right now I rely on others.

as for VPW or CANbus based. I believe the 14 volt is can bus, the yukon is older because the clone tech 2 works on it, I don't know what vpw stands for thou. 08 was the first year of the model, and I don't think they changed anything on it till 2013 or 14

[galapogos01]

The only other possibility we thought about was having direct ADC connections for external sensor logging, but since our case does not have any open slots, its not really realistic to do.

This is a real requirement if you can fit a connector in the case - ADC logging for things like Widebands etc. can make tuning a lot easier. The current workarounds are not pretty, and competing adapters have not been able to make their API work for companies such as PCMTec.

Keep up the good work!

[Tazzi]

The only other possibility we thought about was having direct ADC connections for external sensor logging, but since our case does not have any open slots, its not really realistic to do.

This is a real requirement if you can fit a connector in the case - ADC logging for things like Widebands etc. can make tuning a lot easier. The current workarounds are not pretty, and competing adapters have not been able to make their API work for companies such as PCMTec.

Keep up the good work!

Our thought processor here is by using a standalone module to log ADC that hooks up to the CAN network (Using an OBD splitter or similar), this lets it work with all of our current scantool range