OBDX Development - Developer Tools and Suggestions

[In-Tech]

Well shoot, it looks like that turbo diesel file is actually running an Allison 6spd not a 6L90e.

[Gatecrasher]

I was wondering about that...

[antus]

Its definitely a valid way to figure things out. If you can dump the data in a formatted way you can partly or fully automate generating XDFs. Some of the earlier XDFs for Aussie OSs from the 90s were done that way. The data was in the same order each time, and the same equations came up over and over so it was possible to pick up a known OS, and compare to the OS that was released next chronologically and re-align the data after new calibration items were identified, and find the equations by trying the common ones and finding what one made the raw data match the formatted data.

[Tazzi]

Its definitely a valid way to figure things out. If you can dump the data in a formatted way you can partly or fully automate generating XDFs. Some of the earlier XDFs for Aussie OSs from the 90s were done that way. The data was in the same order each time, and the same equations came up over and over so it was possible to pick up a known OS, and compare to the OS that was released next chronologically and re-align the data after new calibration items were identified, and find the equations by trying the common ones and finding what one made the raw data match the formatted data.

Definitely a good method. And typically engineers/calibrators just keep 'adding' to an existing template which is why calibrations and mappings can appear fairly similar, or only slightly shifted.

Iv found that after a parameter has been found, typically you can search that offset and find where its reference in the operating system which usually have a unique ID that is tied to it. This can then be used to find in other operating systems. I believe this is how universal patcher works also.

Todays battle is sussing out 64bit J2534 support. Technically the SAE J2534 documentation was designed around 32bit and not 64bit.

For 32bit, its just a matter of updating the registry under Local_Machine->Software->wow6432Node->passthrusupport4.04.
I would assume a 64bit DLL would mean the same but under Local_Machine->Software->passthrusupport4.04.

No software I have uses 64bit thus I cannot verify if anything picks up the install correctly or not.

I did also notice the standard does indicate I am 'suppose' to add 32 at the end of the J2534 DLL to signify 32bit. So I will make an update for that so its possible to have both 32bit and 64bit loaded side by side for the GT... not that anyone would need to do that

[Tazzi]

New v1.0.0.1 update for the J2534 API for the GT
This update targets a couple things:
1) PassThruSetProgrammingVoltage- This is used for setting power or ground to specific pins. This is currently not used and is updated to indicated ""ERR_NOT_SUPPORTED" instead of "ERR_FAILED". The actual firmware to process this command is there, but since the GT is unable to power/ground any pins, it has been set to no supported. Our up coming FT scantool will supports power to pin 13 for FEPs.

2) PassThruGetLastError - This is the error logging command which basically just passes back a string in a 80byte array. Effectively I just have to allocate 80bytes of memory and then pop the string in. I am not aware of any tool which uses this command, but for the sake of J2534 error logging, it may come in handy with future developers.

3) Error catching - Every last command has had overall error catches implemented which will throw a "ERR_FAILED" message, and save a debug error message to PassThruGetLastError and to the overall error log.

One other command to keep compliance would be adding the READ_PROG_VOLTAGE for PassThruIoctl command, since this would read back the voltage that has been set. This would theoretically be the 12+v from battery as our FT tool is simply going to use a relay to connect battery to pin13. We do have battery voltage read capability, so this can be correctly implemented.

Our latest OBDX Pro FT revision is on the way. This will be our dedicated Ford tool which will support HSCAN,MSCAN and FEPs. It does have the hardware for FD CAN so this will also be supported in the future. Its basically a modern Ford tool only since we have left off PWM and Kline.

Another post to come shortly for another new product in development.

[Tazzi]

We want to produce a DIY hardware that meets what we needed years ago, since if it meets ours... its likely going to meet alot of others.
Pete and I both kinda came from the same issue of finding good hardware to design with. We both only found 1 solution which even came remotely close which was the M2 Macchina. Although this fell short on working firmware, examples and also a CAN controller issue on gmlan, this was the nail in the coffin for me.

For what we are wanting to do, this would likely need to go onto something like kickstarter since it would have to be a dual PCB board with dual sided assembly along with custom wiring harness to allow in dash setups, both of which need minimum order quantities to even be slightly viable.

The M2 was a huge step towards easy to use DIY hardware.. but.. we know we can do it better.

Currently we are looking at having:
- Triple CAN (HS CAN, MS CAN, GMLAN)
- VPW, Kline and ALDL
- Multiple input/outputs to allow controlling external parts or reading from existing parts
- SDCard for logging
- Addon slot to support 3rd party modules (GPS, ethernet ect)

Are there any recommendations for what you would like to see on such hardware?

[Tazzi]

Few firmware/software updates rolling out:

OBDX Pro GT firmware v1.0.0.2
- To address a couple new settings for developers
- Update to padding byte addressing

OBDX Pro GT J2534 API v1.0.0.1
- Default padding bytes set to 00 instead of AA. (SAE J2534 actually says default should be 00, different tools have this as a different default value).
- Implemented the ISO15765_PAD_VALUE so software can change this value (GM SPS doesnt seem to change this... MDI is default AA even though SAE standard says 00).
- Implemented read READ_PROG_VOLTAGE. Not available for GT but in preparation for the OBDX Pro FT
- Implemented PassThruSetProgrammingVoltage. Not available for GT but in preparation for the OBDX Pro FT

Majority of the above is to accommodate for Ford vehicles. They will not work unless the padding byte is 00, at least the Ford BA ECU's I have on the bench will not.
I have double checked against a dozen GM modules and these changes do not cause any conflict.

[Tazzi]

Learnt something new the last couple days.
Ford ECUs can read and write flash FAST. Typically I find the OBDX sends so quick that it actually results in ECU failing to capture all frames and error out. But, appears the Ford ECUs can deal with busloads running at almost 100% capacity!

One issue though, making the J2534 API running at full speed ends up actually killing many other module support since they cannot keep up. The SAE standard says that slower modules should tell the scantool to go slower, but many of them do not, which results in problems.

To solve this issue, I am leaving the J2534 API at the known working configuration, and adding some developer options in the J2534 API that allows adjusting timing parameters so tweak their designs.

Have been playing with the PCMTec software over the past few days, and can say I am VERY impressed with how its all been put together, along with how fast the team is to correspond with fixing up any issues or questions!

[rolls]

Have been playing with the PCMTec software over the past few days, and can say I am VERY impressed with how its all been put together, along with how fast the team is to correspond with fixing up any issues or questions!

Right back at you Jason. The speed you sent us updated firmware was phenomenal. I think you answered more questions in 1 day than tactrix did in 5 years.

Looking forward to offering this as our preferred PCMTEC cable very shortly. Hopefully with a phone app available it will increase your sales enough to give you funds to really take this to the next level.

Also a shout out to Whiteford for letting me know we had managed to miss this project completely until a week ago.
Dealing with developers in the same time zone who just get shit done is very refreshing.

[Tre-Cool]

I somehow missed a link on where to buy the cable, so ordered mine last night.

Kicking myself i never got pcmtec when you were offering it on here, but as i only really dabbled sporadically with the ford stuff had no real interest in it, kicking myself now.