OBDX Development - Developer Tools and Suggestions

[Tazzi]

We are still progressing along the remote J2534 API train.

We have it communicating with basic commands currently along with validating client/host sessions ect. Extremely close now!

Remote1.png (81.44 KiB) Viewed 2115 times

Remote2.png (202.3 KiB) Viewed 2115 times

[antus]

Damn what a cool thing, love it!

[Tazzi]

Damn what a cool thing, love it!

Thanks!
So far it seems to be working quite smoothly, hence have gone above and beyond to try keep the UI easy to follow.
Its now a slightly simpler design:

Remote3.png (93.12 KiB) Viewed 2066 times

I hooked up my PC to my phones hotspot, and the round trip from me to the client and back through the server was around 210ish ms.
This ends up around 105ish ping which I think is pretty incredible to a server on the other side of Aus over cellular.

Anyways, todays job is to try have have some J2534 applications load up data from some parts and get to their calibration screens.
If successful, this means we are ready to do some full flashes!

[Tazzi]

Thinking about it all... J2534 devs could maximise throughput by queueing up messages to send in one request.
For instance queue up 100 requests which may be used to read an ECUs memory, and send the received data back as it comes in.
This would mean 100x less requests made to the client. With an average of 110ms, that would be around 10seconds saving time. It would actually end up being even more then that as there would be no wasted time between requests on the client side.

This could then be extended to a queue of J2534 commands to be run all in a row. Infact, could request Open, Connect, SetFilter, IOCtrl, WriteMsg and ReadMsg all in one transmit from the host to the client.
Basically, a dev could almost upload and entire flash routine in a single hit, and then just monitor the responses back for each command. The only time where interaction would be needed is obviously when seeing an error code or calculating something from read code specifically (Even that could be automated technically).

[antus]

You are almost describing TCP data connections, and TCP Window size where the packets keep going out, and can get up to <window size> ahead of the Acks coming back. And if a packet is dropped the receiver can say resend from packet X. The routers don't need to cache packets of up to <window size> count, thats in the client PC network stack so does cost memory for each connection. And window size is self scaling to limits that can be configured for longer / more laggy connections. Like anything I guess there are ways, and things that could be done but J2534 is complicated enough without making it more complicated where this was never an envisaged use case.

[Tazzi]

Thats right, this is way out of the scope of what J2534 was suppose to do. But, if theres one thing I have learnt when dealing with J2534 and developers, is they are always looking to push things to the edge as they have been so limited for so long.

[antus]

Damn right, thats pretty much what pcmhacking is all about! And now that J2534 has moved beyond factory tools to the wider aftermarket, internet connectivity is widely available remote access makes a lot of sense.

[oldtinfords]

Looks great! I can't wait to try it

[Tazzi]

Damn right, thats pretty much what pcmhacking is all about! And now that J2534 has moved beyond factory tools to the wider aftermarket, internet connectivity is widely available remote access makes a lot of sense.

Thats it!
I have started putting together a little 'advanced' menu that can allow setting up the tool to do automatic tester present messages and things like that. So even if dealership software does not enable this, it could be controlled manually by the tool itself meaning any big latency will not cause a problem

I left my phone hot spot to my computer for a bit over an hour, and the average ping was around 100ms to a server in sydney (from WA) while it did a constant back and forth between client and host. The highest round trip time was 280ms, where the average was around 205ish. This is obviously in the middle of suburbia where reception is strong though. I don't expect people to be using cellular, but in the event a customer is using cellular, its nice to be prepared.

While the latency testing was going on, I carried on with ensuring credentials were never stored (token base) and finalised the UI design. This will likely be the final setup of the UI which I am happy with. Everything from here onwards is in the backend of the application/server to make it as seamless as possible.

Remote4.png (110 KiB) Viewed 1949 times

Remote5.png (103.91 KiB) Viewed 1949 times

[Gampy]

I see it now, a new generation of keyboard tuners relaxing on their yachts in some exotic bay satellite tuning with their youtube education.

I gotta admit though what you are doing is extremely cool out of the box thinking ...

I just don't like the down side of it, it's gonna get used, misused and abused!

But it is what it is and it's where this new world is ...

-Enjoy