OBDX Development - Developer Tools and Suggestions

[Whiteford]

I have various J2534 compatible software that I'm happy to trial this on for you.

[Tazzi]

Just sent you an email Tazzi. I have a few ideas to toss around that you might be interested in. We would also love to trial your cable. I can't believe I didn't come across this earlier, I would have reached out over a year ago!

The two requests are:

Can you compile a 64bit J2534 DLL? 32bit is very limiting memory wise and we would love to have a 64bit driver DLL so we can compile PCMTEC as a 64 bit program. Tactrix have been dragging their feet despite many requests to build a 64 bit DLL.

Would you be interested in making a sample android application that can talk to the cable via USB with a Java wrapper for a J2534 interface? USB is preferable as its more performant and simpler, however direct USB access may be an issue with the latest version of android (I haven't developed for Android in a long time). I'm sure you can see where we are heading with this. Xamarin would allow us to cross compile our flashing code for android, then use a java/c wrapper library to access your cable via USB to allow flashing. This would allow us to build a very simple slave flashing application, we have huge demand for this (eg 1000+ units).

Just responding to that email now

In short, I believe yes we can make a 64bit driver DLL. The only reason I didn't do this earlier is simply because I have not seen a single other manufacture make a 64bit version, everything has always been 32bit and saved into the program files (x86) folder, so I assumed this was done for a reason.

[Tazzi]

I have various J2534 compatible software that I'm happy to trial this on for you.

The more software the better. Since I know for a fact that some softwares will interact differently hence why some tools work and others don't.
It tends to be filters/masks being set incorrectly which causes the main issues.

[Whiteford]

I have various J2534 compatible software that I'm happy to trial this on for you.

The more software the better. Since I know for a fact that some softwares will interact differently hence why some tools work and others don't.
It tends to be filters/masks being set incorrectly which causes the main issues.

Send me a PM when you have time to discuss

[Tazzi]

Send me a PM when you have time to discuss

Will do!

After a bit of mucking around, we now have our triple CAN prototype up and going. This will be the next evolution of canbus control, I am going to allow all three to be run at the same time since its clear that protocols such as DPDU are going to run multiple protocols at the same time. This shouldnt be much of an issue, this will mean full compliancy with Tech2win.

I can now start implementing the Kline standard completely, along with testing out MSCAN and FEPs with the J2534 standard.
I know I use to have some sort of Ford documentation about FEPs, but for the life of me cannot find it. I do have my own research documented (from back in 2016...) which indicated I could go into FEPs at anything over around 8v, thus using battery voltage onto pin13 is all that will be required.

Pete and I have discussed the idea of a Ford dedicated tool, which will basically mean removing ALDL,VPW and GMLAN, then replacing with MSCAN, FEPS, Kline and potentially PWM (VPW's cousin).

[Tazzi]

Moving forward with CAN FD, theres a few possibly standards to look at. I believe a quick peep at a J2534 log indicated that FD CAN for GM is 2mbps so this would make sense that these standards are being referred to:

https://www.sae.org/standards/content/j1939-22_202209/

https://www.sae.org/standards/content/j1939-17_202012/

https://www.sae.org/standards/content/j2284/4_202211/

https://www.sae.org/standards/content/j2284/5_202211/

[kur4o]

If you want to add full coverage of k-line for tech2win, prepare to switch it between multiple pins. Pin 7 being the main and upto 3-4 different pins are being used for k-line. I can make a list if you need one.

I can get you some logs of tech2win talking to different modules[pcm,ipc,sir,abs and so on] in car on different pins.

[Tazzi]

If you want to add full coverage of k-line for tech2win, prepare to switch it between multiple pins. Pin 7 being the main and upto 3-4 different pins are being used for k-line. I can make a list if you need one.

I can get you some logs of tech2win talking to different modules[pcm,ipc,sir,abs and so on] in car on different pins.

That would be fantastic!

I wasn’t aware Kline switched between that many pins.

[MudDuck514]

SNIP

Would you be interested in making a sample android application that can talk to the cable via USB with a Java wrapper for a J2534 interface? USB is preferable as its more performant and simpler, however direct USB access may be an issue with the latest version of android (I haven't developed for Android in a long time). I'm sure you can see where we are heading with this. Xamarin would allow us to cross compile our flashing code for android, then use a java/c wrapper library to access your cable via USB to allow flashing. This would allow us to build a very simple slave flashing application, we have huge demand for this (eg 1000+ units).

Hi all,

As far as I can tell, Android has ONLY ever had support built-in for the FTDI USB Interface!
Tazzi would have to change the interface chip on his device to an FTDI one - and those are more expensive than the one he is currently using (AND may still be "unobtanium")

Mike

[Tazzi]

SNIP

Would you be interested in making a sample android application that can talk to the cable via USB with a Java wrapper for a J2534 interface? USB is preferable as its more performant and simpler, however direct USB access may be an issue with the latest version of android (I haven't developed for Android in a long time). I'm sure you can see where we are heading with this. Xamarin would allow us to cross compile our flashing code for android, then use a java/c wrapper library to access your cable via USB to allow flashing. This would allow us to build a very simple slave flashing application, we have huge demand for this (eg 1000+ units).

Hi all,

As far as I can tell, Android has ONLY ever had support built-in for the FTDI USB Interface!
Tazzi would have to change the interface chip on his device to an FTDI one - and those are more expensive than the one he is currently using (AND may still be "unobtanium")

Mike

We use the STM processors, and as far as I can find online, the default Android USB CDC drivers are suppose to work with them.
Its all theory until I personally test it out though.