OBDX Development - Developer Tools and Suggestions

[Tazzi]

Impressive work Tazzi!

Thankyou! Its getting there slowly.

I need to fix up the 'extended addressing' since Im doing a bit of a hack work around.
Extended address is when we get things like this:
101 FE 01 3E

Where the first byte FE, is our extended addressing byte. Basically used as a global "Everyone look!".
The length byte is then next 01, and finally data byte of 3E.

The way OBDX is currently designed, when I send the data... what gets sent to the CAN line is the following:
101 02 FE 3E
The OBDX tool does not know that its an extended address, so it treats it as a data byte.

The way I kinda beat this was temporarily disabling formatting on the tool.. sending the frame, then re-enabling the formatting. It really shouldn't be done like that, hence a smarter solution needs to be created.
The best way I can see currently, is to have a setting in the tool which when enabled, checks the first byte of the data, and if it is 0xFE (or whatever assigned byte), it then uses that as the extended address.

Technically, there should never be an instantance where FE is the first byte, and we want it in our data frames.. since there is no 'FE' mode... so it should not hurting implementing that method

[Tazzi]

Its now been correctly implemented for extended addressing... and flashing now works actually faster again
The OBDX GT flashes 20 calibrations including kernel onto a VF BCM in 9.5seconds.
For reference, the fastest J2534 I have ever found has been the Bosch MDI which usually flashes calibrations only on BCM in around 12ish seconds.

Technically... it can be made to go faster, but the issue then comes to if the module can handle receiving information that quickly

Both GMLAN and HSCAN have been tested with my own flashing software. Next is to test 'high speed' gmlan programming (83.333) which is only on a few GM modules that I know of. Assuming that works.. we have full GM compliancy.

[hjtrbo]

[antus]

so much win - well done!

[Tazzi]

Typical, techline wouldn’t load all afternoon for me, so we will try tomorrow.

Was able to successfully read and write an e38 also. So I’m extremely happy with it.

The inner OCD in me wants to complete the D-PDU for the OBDX GT after j2534, although I don’t think I have recovered from the initial trauma I had from getting the VT going!

[Tazzi]

As always.. SPS has to do something stupid to cause delays.

Its now requesting just basic standard "CAN" with no formatting... so this:
13:41:33:186 : PassThruConnect Called
Protocol ID: CAN
Flags ID: NONE
Baud Rate: 500000

The protocol that we expect it to request which is does intiially to auto pickup the VIN is: ISO15765

The difference being, that ISO15765 has all the nice formatting of messages as we would expect, and CAN is just RAW CAN, everything needs to be manually processed... so... back to the dll...

*Edit
I am genuinely taking this personal now. I could swear an engineer is watching these posts and just changing up SPS to troll me...
Engineer: "Haha... Jason hasn't implemented the RAW CAN protocol, lets use that for 6 CAN frames then go back to normal ISO15765.."
Me: "Hold my beer...."

[Tazzi]

Techline flashing has been a success!
After going through a few more stupid hoops.. including having to implement a 'loopback' mode... we are flashing with techline

VEBCMProgramming.PNG (23.45 KiB) Viewed 2651 times

VEBCMSuccess.PNG (9.38 KiB) Viewed 2651 times

[Tazzi]

Now the next bit of hackery was I did the above, remotely.

I left my laptop with the car and OBDX connected.
Then bounced the SPS calls from my desktop, through my server.. to the laptop and finally the OBDX tool. This all being done straight out of the J2534 DLL.

Now my concerns here:
1) When in RAW CAN mode, this relies on the dealership software to handle things like flow control which is extremely time sensitive. From what I saw with SPS, it only used this mode for getting some basic calibration IDs, it didn't need to do any complex stuff, but I did notice it was sending 'tester present' messages manually which means a big lag in a server response could result in a failed flashing session. When it actually did the writing, it did use the proper flow control type setup with periodic messages (scantool handles it all) so even a lag in the server would not result in failed session. But this does not mean every GM module is like that.

2) Opening a giant CAN of worms (Yes... that was my poor attempt of a pun )

As far as I am aware, I could not find much about companies offering a solution like this. I do believe its intentional by the big J tool companies, but I am working out if that is due to they want to cover their asses, or are they actually looking out for the local diagnostic technicians? Since theres no way they haven't actually implemented it, I am just one man smashing on a keyboard... surely a whole team can do a better task of it.

Bare with me here, remote programming could result in a 'race to the bottom' kind of scenario, where folks with unlimited techline charge peanuts for flashing/performing diagnostics on a vehicle over the web. Just because something is cheap, doesn't mean its good quality. So I can see this having an impact on local technicians losing out on work due to others offering unreasonable pricing. I mean, if someone offered to program a BCM for less then a normal VIN license with SPS, it would be hard to say no? But as any good tech knows, its not always that simple. Things do not go smoothly always, or wrong parts are fitted, or fuses need to be pulled ect.
It also opens a liability of a programmer to just 'up and leave' if they mess up. If someone from another country went and wiped your keys by trying to add a new one.. your left kinda stranded with nothing to do?

I dunno, maybe I am over thinking it.

[hjtrbo]

It also opens a liability of a programmer to just 'up and leave' if they mess up. If someone from another country went and wiped your keys by trying to add a new one.. your left kinda stranded with nothing to do?

I dunno, maybe I am over thinking it.

Who gets the call to fix it.....

[Tazzi]

Who gets the call to fix it.....

An unexpecting sucker like my self, who doesn't get told the whole story until I figure it out
Fixing other peoples muckups is never fun, it becomes a game of trying to decipher what they missed with to fix back up.

Some of my most hated mess ups are fixing immo related problems on Global A. Once a module has a mismatched VIN to immo, it then requires bruteforcing the immo code which can take over a day to find.