OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
Site Admin
User avatar
Posts: 7303
Joined: Sat Feb 28, 2009 8:34 pm

Re: OBDX Development - Developer Tools and Suggestions

Postby antus » Fri Sep 23, 2022 10:35 am

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: viewtopic.php?f=7&t=1396

User avatar
Posts: 2974
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Fri Sep 23, 2022 11:09 am

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
Site:www.envyouscustoms.com
Mob:+61406 140 726
Image

Posts: 589
Joined: Thu Nov 03, 2011 7:57 pm
Location: perth wa

Re: OBDX Development - Developer Tools and Suggestions

Postby vs ss » Fri Sep 23, 2022 4:19 pm

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
Posts: 2974
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Fri Sep 23, 2022 5:33 pm

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 246 times
Your Local Aussie Reverse Engineer
Site:www.envyouscustoms.com
Mob:+61406 140 726
Image

Posts: 589
Joined: Thu Nov 03, 2011 7:57 pm
Location: perth wa

Re: OBDX Development - Developer Tools and Suggestions

Postby vs ss » Fri Sep 23, 2022 7:00 pm

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

User avatar
Posts: 2974
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Fri Sep 23, 2022 11:50 pm

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
Site:www.envyouscustoms.com
Mob:+61406 140 726
Image

Posts: 589
Joined: Thu Nov 03, 2011 7:57 pm
Location: perth wa

Re: OBDX Development - Developer Tools and Suggestions

Postby vs ss » Sat Sep 24, 2022 1:10 am

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:

Posts: 567
Joined: Sun Apr 10, 2016 9:20 pm

Re: OBDX Development - Developer Tools and Suggestions

Postby kur4o » Sat Sep 24, 2022 4:15 pm

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
Posts: 2974
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Mon Sep 26, 2022 10:54 am

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
Site:www.envyouscustoms.com
Mob:+61406 140 726
Image

User avatar
Posts: 2974
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Wed Sep 28, 2022 7:05 pm

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
Site:www.envyouscustoms.com
Mob:+61406 140 726
Image

Previous

Return to Tools

Who is online

Users browsing this forum: No registered users and 2 guests