pcmhacking.net

Yeah the timing will get you every time I think. Most software will have timeouts somewhere, and due to network lag your not going to be able to get around this in a generic way. You would be better off putting an API in your app remote control it from elsewhere, but still have the flash process or log process running local to the car / pcm. Then again, that is kinda reinventing the wheel as you can drive a pc remotely now. Phones would be a different story though, maybe you could put some kind of way to remote control a flash on someone elses phone across the internet, but still drive the flash process from the phone.

antus wrote:Yeah the timing will get you every time I think. Most software will have timeouts somewhere, and due to network lag your not going to be able to get around this in a generic way. You would be better off putting an API in your app remote control it from elsewhere, but still have the flash process or log process running local to the car / pcm. Then again, that is kinda reinventing the wheel as you can drive a pc remotely now. Phones would be a different story though, maybe you could put some kind of way to remote control a flash on someone elses phone across the internet, but still drive the flash process from the phone.

This was a contract job, basically trying to make a handheld tool (like tech2) connect to an interface which sends it over the internet to a customers car.. then sends back its responses ect. Theres a couple companies offering solutions currently although they all are all hitting the ping issue from current reports. The reason technicians want this is because some tools use proprietary scantools, or are locked to one specific J2534 tool thus cannot use upcoming tools (like obdx) to perform over the web. Its alot of risk for a technician to be doing something like this to be honest, some tools will never work due to such tight timeout requirements.

Implementing remote support into J2534 API directly is so far ALOT more reliable and easier to do, since the J2534 protocol basically waits until the DLL API responds, which gives it infinite time to complete.


The initial pre-release of OBDX GT tools has now completed, the first public release of OBDX tools should hopefully be up early next week
I will be updating the website with the GT programmers reference manual along with GT J2534 installer shortly too.

OBDX also has a few new prototypes on the way. This is to start implementing a Ford specific tool (for MS CAN, Kline and PWM) along with a dedicated J2534 tool which will be in a larger case (similar to an MDI) so that we can put every protocol into one tool.

Exciting to see so much happening!!

Tazzi wrote: Exciting to see so much happening!!

You are! I’m that excited I had to go have some quiet time.

But as usual, nice work.

Today just keeps on giving!
New prototype in. We will now be testing out:
1) Inbuilt triple can (No relays needed!) so support HSCAN,MSCAN, GMLAN and FD CAN (On HS and MS pins)
2) Kline/L-Line
3) PWM
4) FEPs for Fords programming (simply bridges battery to pin13)

With those added, we should be covering basically all common OBD2 protocols plus more

I know I probably shouldn't be this excited to have more work.. but this is basically the last 10years of everything I have learnt being rolled into a tool

Oh nice . It might be a bit early at the moment, but do you have an approximate pricing on this interface?

vs ss wrote:Oh nice . It might be a bit early at the moment, but do you have an approximate pricing on this interface?

It’s hard to say as we have no idea if we can fit this into our current case design, or if cost of the processor is going to get better or worse ect. Fitting it all into a small case means using more complex pcba options and techniques, along with more layers, which has serious impact on price as well.

It’s more important to get working firmware at the moment, then we will work on finding the most viable production methods, and whether a custom case needs to be made ect.

Gotcha! Yeah thought It might of been a bit stupid to ask at this point in time. Anyway I shall remain watching for progress updates.

You may already considered this idea, but the only way to overcome the lag issue is to run some code within the tunnel at the guest.
Something like that open the tunnel, upload some code to guest run the code from there and use the host only as control interface. When first stage is done pcm identification, Upload more code to guest tunnel that contains all the flashing info needed. It is something like modified team viewer with the difference that code that needs running is uploaded on demand to guest ram and run from there.

kur4o wrote:You may already considered this idea, but the only way to overcome the lag issue is to run some code within the tunnel at the guest.
Something like that open the tunnel, upload some code to guest run the code from there and use the host only as control interface. When first stage is done pcm identification, Upload more code to guest tunnel that contains all the flashing info needed. It is something like modified team viewer with the difference that code that needs running is uploaded on demand to guest ram and run from there.

Yeah, I did start going down that path to add more 'smarts' to the guest side, but it then becomes a nightmare to manage due to every single manufacture/model/year would need to be accounted for which is a giant task.

I might come back to this after I have processed further with this new prototype and also with the new app I have been working on.

I bought a Holden Barina ECU since that works on Kline. It does not have an L-line which is a bit of a bummer, but will research for a vehicle with that at a later date, or alternatively, we can use an emulator to design for it.
Kline is surprisingly used in alot of vehicles, which is why its on a high priority list to complete. Next is them PWM, although I have had reports that Fords that used PWM needed to be put into a diagnostic mode by doing funky things with ignition switching with brakes depressed ect, I have yet to confirm any of that but as far as I am aware with a Ford AU Falcon, which used PWM, you could just start communicating to it without any problems

I have one of those Ford ECUs here as well. Figured Id wire it up and check it works with a standard ELM to ensure it actually is PWM, since again, its all going off things indicated online.

I believe we have double the flash size on this new processor, which is more then enough to add the two protocols above, along with FD CAN. Other protocols we have had only a little bit of interaction has been SCI and CCD for the FCA vehicles, although this starts getting into an extremely niche protocol which likely would only fit and be used on dedicated J2534 scantool.

I really am notorious for biting off more then I can chew

I have been made aware of many dealership software's migrating to J2534 5.00 and dropping 4.04 support. Whats interesting about this, is theres only a couple scantools which currently support the 5.00 API. Theres not much changes other then an update to writing network frames, and also identifying scantools for initial connection routine... other then that, its basically all the same plus supporting some newer protocols.

I have someone thats interested in trying out the OBDX GT with Nissan vehicles which has migrated to the 5.0 API, so as soon as I publish the 4.04 J2534, Ill make a quick edit for the 5.00 and see how it goes.
I wasn't kidding when I said I am going to make OBDX an all in one universal tool, no more of this bullshit where different tools needed for different software (excluding supported protocols).