pcmhacking.net

I figured Id split that response above from this next one.

OBDX Pro is still very much alive and moving, time between my posts have been increasing as free time has been decreasing.
Our next OBDX designs have had their final testing for the new OBD protocols including PWM, Kline and CAN FD. There is still quite a bit of work with designing the circuit board to fit everything we want on it, but its coming along!

Where most of my time has been going, is working on new software for myself, along with helping a heap of developers integrate OBDX into their software.

From developers creating software that does some cool GM/FCA ECU unlocking, through to adding custom commands to allow unique CANBus/Filter controls, its been quite an interesting adventure!

I have had almost every single developer asking me about the best wait to connect to iOS devices, with everyone asking how to get fast bluetooth, and the short answer is, you don't!
After going back down the iOS BLE Bluetooth rabbit hole... one last time... I can conclude that BLE 5.0... is just not there yet, close... but not enough.
BLE 5.3, looks like it will be the closest thing to classic bluetooth, infact, it SHOULD be faster, but this is only present in the absolutely newest androids and iphones, so it will be something I likely revisit again in a couple years time.

But for fast communication on an iOS device, WIFI is the way to go. There is a little latency between each command but it still allows fast flashing similar to that of classic bluetooth.
Developers do need to note that when using OBDX WIFI on an iphone, you must use the correct Web Request commands to tell the iphone to use Cellular data when making any requests otherwise it will try using the OBDX to make internet requests and take a good 2minutes before it automatically switches to cellular data.

Looking forward to the next devs that contact!

Is there anyway to do real time tuning for p59 with an obdxpro GT via USB? I normally just use it to flash when the engine is off but I'm rebuilding my motor with a longer stroke and better cam and would like to be able to change the tune if necessary during my break in without having to kill the motor. I figure this is probably beyond the scope of the tool, but thought it wouldn't hurt to ask before looking into something like an RTLS1

That’s definitely not something that OBDX would be looking into due to the work involved.

Basically would need to redirect the map location to be copied into ram once the ecu boots up, and then modify this ram map to allow real time tuning.

So..while it’s certainly possible to do. And the theory of it isn’t that complex… but in reality, it’s a lot of reverse engineering to identify the exact routine/references to redirect, and finding safe ram to redirect too which all changes between every single Operating System.

So your telling me the hardware should be capable of if I can write the software? Since i'm running the 7603 os which does have a good amount of info on it in this site. Just a VE table in RT would be really helpful. Probably above my skill level but nothing to be lost by trying. Thank you for taking the time to explain to me the theory of what I need to do

Have a look at the hpt realtime cos which they call rtt. You'd need to implement something like that in the pcm operating system and a pc side tool that works with it. Possible? yes. Worth it? not so sure.

Whiteford wrote: ↑Thu Mar 07, 2024 4:29 pm I can't give you the information you require as I no longer use your product due to multiple failed attempts on majority of testing I did with it on modules that we have discussed in the past including GM and Ford.

You had stated the speed was not the issue referring me back to the software developers.

Good to see you have identified speed is not just baud rate but timing too.
You are 100% correct a module will dictate the speed at which it will accept data, to my knowledge it does not define the time delay between frames as you have now determined.

How you will confirm what each module requires will require a lot of testing on your behalf.

It would appear that your software is not J2534 compliant.

Compliance is violence

I do love my job, but it certainly takes me down paths where I question my sanity to fix issues which shouldn’t be my issue

So.. our next fun filled drama!
Tech2win does a bit of fuckery with OBD protocols when requiring to speak to more than one at a time for a specific action.

Let’s take the SDM Primary Key Learn in a Holden VE commodores.

What suppose to happen is the following:
1) open GMLAN protocol
2) read primary key from airbag module
3) close GMLAN protocol
4) open HSCAN protocol
5) send primary key to engine computer

What actually happens is:
1) open GMLAN protocol
2) read primary key from airbag module
3) write primary key to engine computer.

For those following along.. we are missing two extremely important steps! Tech2win doesn’t set the protocol!

How does GM MDI manage to work then? Well.. it’s a bit of a hack that they have hard coded to make it work with tech2win.

In short, they basically monitor the requested “read” filter and what OBD protocol it was previously used for, then switch to that protocol automatically without actually being told to.

This is not how the DPDU spec is designed for, so.. guess I’m going to follow in the MDI developers steps to fix it with a DLL update.

It’s not a simple task unfortunately but.. I’ll get it sorted!

The more you post the more it makes sense why our dealer equipment is such a cluster fuck

gmtech825 wrote: ↑Fri Aug 09, 2024 10:00 pm The more you post the more it makes sense why our dealer equipment is such a cluster fuck

X1000
I'm kinda shocked, today is friday and neither globalconnect nor tldc has crashed all day.. It's still early and I did have a 30 minute radio usb programming crash right at the end earlier so I got to do that twice..