OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by antus »

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.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

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 :D
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!!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
vs ss
Posts: 591
Joined: Thu Nov 03, 2011 7:57 pm
cars: hsv enhanced vs ss
vt xu6
fb holden
toyota landcruiser
vt ss s1
Location: perth wa

Re: OBDX Development - Developer Tools and Suggestions

Post by vs ss »

Tazzi wrote: Exciting to see so much happening!!

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

But as usual, nice work.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

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 8-)

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 :D
prototypeobdx1.jpg
prototypeobdx1.jpg (495.01 KiB) Viewed 1577 times
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
vs ss
Posts: 591
Joined: Thu Nov 03, 2011 7:57 pm
cars: hsv enhanced vs ss
vt xu6
fb holden
toyota landcruiser
vt ss s1
Location: perth wa

Re: OBDX Development - Developer Tools and Suggestions

Post by vs ss »

Oh nice :thumbup: . It might be a bit early at the moment, but do you have an approximate pricing on this interface?
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

vs ss wrote:Oh nice :thumbup: . 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.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
vs ss
Posts: 591
Joined: Thu Nov 03, 2011 7:57 pm
cars: hsv enhanced vs ss
vt xu6
fb holden
toyota landcruiser
vt ss s1
Location: perth wa

Re: OBDX Development - Developer Tools and Suggestions

Post by vs ss »

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. :thumbup:
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: OBDX Development - Developer Tools and Suggestions

Post by kur4o »

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.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

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 :roll:

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.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

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

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). 8-)
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Post Reply