OBDX Development - Developer Tools and Suggestions

[ironduke]

No more techline disconnect being down would be fantastic, now if your software could spit out the warranty programming codes that would be even better!!! It was down yet again this morning for hours. We even started a bingo board with all the disconnect errors on the gm forum, guessing Chris wasn’t to impressed with that, lmao..

[Gareth]

Someone needs to clone the techline server

[Tazzi]

No more techline disconnect being down would be fantastic, now if your software could spit out the warranty programming codes that would be even better!!! It was down yet again this morning for hours. We even started a bingo board with all the disconnect errors on the gm forum, guessing Chris wasn’t to impressed with that, lmao..

I see countless people screenshot downtime and login errors. I understand its quite a big operation they are running, and is probably tens of thousands of users every day, plus at some time they have to push updates live, but for failure to even login to their account is just painful. I guess this happens when programs get over complicated with too many people working on it at the same time

Someone needs to clone the techline server

Slowly but surely.. I will collect every calibration from every GM module on the planet

The most time consuming part is making sure that vehicle is correctly identified, and then make sure the correct calibrations are auto loaded to it based off its RPOs/Vehicle Type/Hardware ect.
Unfortunately cannot rely on using the online calibration lookups anymore, there are several Holden modules (And Cadillac/GMC/Chev) VINs which do not display any information, and loading them through techline also shows an error that there is nothing present, yet an identical vehicle with a different VIN will load up. Its these kinds of screw ups which I am targeting.

[Tazzi]

To be the fastest? Or the most safe?

You would think its blindly obvious to always choose the safest route right, but somehow I have managed to find a bit of a dilemma for J2534 tools.

I have come across a bunch of GM modules which fail updates with using various J2534 tools over GMLAN. These same tools work perfectly fine with other modules.
But when using the GM MDI, it will work every single time without fault.

So.. what gives? Whats the difference?
Speed... literally... speed.

Slower car modules will report back how fast to write to them when flashing.
For example, they say there needs to be a minimum of 1ms between every CAN frame.
The OBDX Pro can happily maintain that delay exactly.... and so can a few other top end tools.

Now, the key word here is "minimum". This means that larger delays can be used.
Obviously for speed, we want to use the minimum required time between CAN frames to max out the flashing speed. But.. it appears this minimum is not actually enough for a bunch of GM modules. This is the same problem I came across with the newest GM ECUs where they wanted 100micro seconds, although that was also incorrect.

Not only is 1ms still not long enough, I actually have to do 4-5ms between every single frame for it to work reliably.
Thats 4-5x longer then what the module actually reports back as acceptable. So.. how on earth are tool manufacturers suppose to cater to this??

It looks like the MDI intentionally does a longer timeframe just to add a safety barrier. Most scantool manufactures do not do this.

Not all modules are affected by this problem though. Thus putting a safety barrier of 4-5x the normal time means flashing takes 4-5x longer overall.

As always, I go for the side of reliability and safety, but it means any developers specifically coding with OBDX Pro tools that know a module can take the fastest speeds, will need to actually manual override this delay (Part of the newest firmware updates coming out).

[Whiteford]

You will find this to be the case with not only GM...

And would explain why your tool is far less reliable then OEM tools

[Tazzi]

double post

[Tazzi]

You will find this to be the case with not only GM...

And would explain why your tool is far less reliable then OEM tools

If you can give me an example of a module/vehicle, I can boot it up on the bench to see whats going on? As you can see, Im an active (And vocal) developer about issues, since its the only way to actually get feedback, along with make progress.
I prefer reliability over anything, its just a funny concept to say that it can actually write faster then what a module can actually accept (Even though its doing exactly as its told! ).


Today I pulled out the old faithful AVT which also supports GMLAN. Same issue!
Probably makes sense why so many people have issues flashing various modules using J2534 or other tools like an AVT.

Since I can control every last aspect of the tool, its easy to handle and adapt for.

[Whiteford]

I can't give you the information you require as I no longer use your product due to multiple failed attempts on majority of testing I did with it on modules that we have discussed in the past including GM and Ford.

You had stated the speed was not the issue referring me back to the software developers.

Good to see you have identified speed is not just baud rate but timing too.
You are 100% correct a module will dictate the speed at which it will accept data, to my knowledge it does not define the time delay between frames as you have now determined.

How you will confirm what each module requires will require a lot of testing on your behalf.

[Tazzi]

I can't give you the information you require as I no longer use your product due to multiple failed attempts on majority of testing I did with it on modules that we have discussed in the past including GM and Ford.

You had stated the speed was not the issue referring me back to the software developers.

Good to see you have identified speed is not just baud rate but timing too.
You are 100% correct a module will dictate the speed at which it will accept data, to my knowledge it does not define the time delay between frames as you have now determined.

How you will confirm what each module requires will require a lot of testing on your behalf.

Actually, the time delay is defined as per the SAE standard for ISO15765.

The flow control message (ie 7E8 30 00 01) is what defines it.

The byte where I have put “1” indicates a minimum of 1ms delay between every single CAN frame. This is the delay which is actually incorrect.

When that value is 0, it means run at full speed.

Iv tested flashing Ford clusters, BCM, ECUs and anything else I have here without problems. So unless you have some other guidance on specific modules, I will assume it’s sorted. This firmware and j2534 update will be pushed shortly.

If you provide a year and module that you are messing with, I can either use factory tools are whip something up to flash it for testing. I’m happy to purchase any modules to mess with.
Unfortunately saying “it doesn’t work” isn’t very helpful for a developer

The obdx tool itself does its job perfectly. It’s these discoveries that I post about which allow me to make it account for car manufactures problems (since that’s what they are), which I’m now seeing many other tools with the same problem.

I’d love to see what a cardaq does on these GM GMLAN vehicles, see if it has pushed in an additional buffer zone for delays when requested by a module.

[Whiteford]

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