OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
Posts: 22
Joined: Mon Jan 21, 2019 10:35 am

Re: OBDX Development - Developer Tools and Suggestions

Postby Whiteford » Tue Nov 15, 2022 5:26 pm

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

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

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Tue Nov 15, 2022 5:49 pm

rolls wrote: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. :lol:
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
Posts: 3381
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Tue Nov 15, 2022 6:35 pm

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

Posts: 22
Joined: Mon Jan 21, 2019 10:35 am

Re: OBDX Development - Developer Tools and Suggestions

Postby Whiteford » Wed Nov 16, 2022 10:47 am

Tazzi wrote:
Whiteford wrote: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

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

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Wed Nov 16, 2022 11:38 am

Whiteford wrote: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).
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
Posts: 3381
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Wed Nov 16, 2022 6:53 pm

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

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

Re: OBDX Development - Developer Tools and Suggestions

Postby kur4o » Wed Nov 16, 2022 8:26 pm

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.

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

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Wed Nov 16, 2022 9:18 pm

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

Posts: 391
Joined: Wed Jul 05, 2017 8:30 am
Location: North TX, USA

Re: OBDX Development - Developer Tools and Suggestions

Postby MudDuck514 » Thu Nov 17, 2022 4:43 am

rolls wrote:
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

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

Re: OBDX Development - Developer Tools and Suggestions

Postby Tazzi » Thu Nov 17, 2022 9:14 am

MudDuck514 wrote:
rolls wrote:
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. 8-)
Its all theory until I personally test it out though.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image

PreviousNext

Return to Tools

Who is online

Users browsing this forum: No registered users and 4 guests