pcmhacking.net

Found a small little error in the GT J2534 dll that is affecting support with PCM Hammer due to a mask irregularity, so there will be an update rolling out for that very shortly!

The times are in using PCM Hammer:
When using over the web: 3min 55sec, average Kbps was 21-22
When using USB it was: 2min 25sec, average Kbps was 32-33

Basically 1min 30sec difference, This is an increase of 1.62x

Next up is using PCMtec. As that is a very fast, CAN heavy setup, I will be interested to see how it handles.

Using PCMTec for a full read, its a VERY big difference.

This is simply due to the number of J23534 commands being used which results in alot of down time (ie.. clearing buffers ect).

Full read by USB should only be around 2m 33s on the TC1791 ECU on the bench.
Via remote, it is over 25mins
It is 10x slower when theres alots of operations with smaller blocks.

If I was to cut out 2-3 additional commands that it does, I could likely wipe out almost 10mins off the time. This could be further optimized if I spoke with the devs to increase size of frames and stuff like that, but other it would likely be at the 15min mark (Which is ungodly long).

If doing a virtual read, this would have been near instant, or at least skipped over the OS and read calibrations only which would have been much more faster.
Doing a calibration only write was very quick, since their software only writes where there is a change, so that would be the better solution.

I also successfully flashed using Techline. Again, calibrations are nice and quick, but the OS writes can be a little slow to complete depending on the size of the file and the size that is being uploaded.

Still happy with the results though, have flashed at least 70+ modules over the web now without fault.

Next up... in car!

I kept flashing stuff, for the sake of flashing at the moment with this remote API

I managed to bring down the full read with PCMTec to 16mins, this is almost half the time it was, simply by removing some debugging text and being smart with J2534 commands.

It has made me think of doing a couple things for J2534 devs:
1) Give the option to batch commands
2) Give the option to send and compile/run native code on the client side.

Option 2 is a bit more crazy, since it would allow creating and running any code. This would enable devs to forward entire routines to the client side.. run them.. and get the result... all while still being J2534 compliant.

Anyways, next part is to finish off the server programming, then it will be ready for the wild for further programming!

So from 25min read... down to 16min... now down to 6min 45seconds with PCMTec...

Tested it again with the GM BCM OS+Cal programming, and that is now down to 156seconds (2min 36seconds) from what it was before at 196seconds (3min 16seconds).

I am out of ideas for cutting any further time out, we are using all time as optimal as possible now, so Id say thats going to be the best I can get without having a server closer to me. I am REALLY happy with that result!

Tazzi wrote:So from 25min read... down to 16min... now down to 6min 45seconds with PCMTec...

Tested it again with the GM BCM OS+Cal programming, and that is now down to 156seconds (2min 36seconds) from what it was before at 196seconds (3min 16seconds).

I am out of ideas for cutting any further time out, we are using all time as optimal as possible now, so Id say thats going to be the best I can get without having a server closer to me. I am REALLY happy with that result!

That's an impressive improvement with PCMtec Tazzi. It'd be interesting to know how long it takes to do a full read & write of a Falcon PCM & TCM.

oldtinfords wrote:That's an impressive improvement with PCMtec Tazzi. It'd be interesting to know how long it takes to do a full read & write of a Falcon PCM & TCM.

*Connects up an FG ECU*

So this is a Spanish Oak 1024k.. a full read (non-virtual) has taken :3min 21seconds
Via a wired connection, its about 1m 45seconds

So just shy of double the time.

It looks like with PCMTec, most of the times are around the 'double' mark if the round trip latency is 100-120ms.

It all depends how a J2534 software utilizes the J2534 commands at the end of the day, which is why I am doing all the tests

I just did a recovery writing test (longest option available), and its a bit longer, but this is due to smaller blocks being used to write I believe.
Via wired, its 54seconds.
Via remote, its 2min 58seconds.

Personally I am still very happy with the results.

Well.. I successfully managed to flash an Operating System over the web with the OBDX remote API, from Australia to United States
Due to the extremely high ping, this should have taken a good 10-15minutes, instead, it was done in 1min 50sec.

I kinda cheated though, I made a basic implementation of the J-command forwarder, where I passed all the commands in one message and then monitored the responses as they came back to detect if any of them report an error.
This effectively allows for long complex routines to run on the client side directly.

I took this a step further, and integrated codedom on the client side, which allowed me to actually transmit code to perform the unlock algorithm at the client side and inject it into a following frame so the entire seed/key process was completed without having to be negotiated with the host.

So what does all this mean exactly?
Well, basically it means a J2534 developer could create a setup which allows executing an entire routine in 1 single command.
With that in mind, and once I have migrated the client side onto a smartphone platform, this would allow J2534 developers to enter the remote industry with minimal modifications or time difference for flashing/reading procedures.

Theres ALOT more changes I need to do with the above though, since alot of this was fixed to suit the my exact needs, but, the proof of concept has been completed.

I would suggest being careful with this and not going too far. At some stage, if the device in the car is the GT, it might make more sense to rdesktop in to a pc on the other side, than applying too many smarts at the protocol level. At some stage you risk breaking another tool, even if you get away with it with another. Perhaps you need an option were you can turn remote J2534 optimisation on or off, or apply different set of tweaks per application. But if the apps change there is still risk with that and a growing amount of testing for you to do if you want to advertise compatibility with tool x version y as tools and versions andd targets tested grow.

antus wrote:I would suggest being careful with this and not going too far. At some stage, if the device in the car is the GT, it might make more sense to rdesktop in to a pc on the other side, than applying too many smarts at the protocol level. At some stage you risk breaking another tool, even if you get away with it with another. Perhaps you need an option were you can turn remote J2534 optimisation on or off, or apply different set of tweaks per application. But if the apps change there is still risk with that and a growing amount of testing for you to do if you want to advertise compatibility with tool x version y as tools and versions andd targets tested grow.

The feature I noted above would only be possible if a developer was to implement our custom (non standard) J2534 commands. I always maintain backwards compatibility when adding new features to tools in the event it affects all capabilities. But I do understand what your saying.

The standard remote J2534 API simply runs on a "per request" basis just like a normal J2534 DLL driver does. The only optimization is does is it passes any received network data straight back to the host instead of waiting for a read request.

Ahh I see. Nicely done then. Opt-in only for developers who want to take advantage of it to use it. BTW Dumb question, people keep asking me what to buy. Is the GT the does it all with all protocols including the Ford stuff?