OBDX Development - Developer Tools and Suggestions

[oldtinfords]

Great news Tazzi.
I have to say thanks again for your recent support & committment to ongoing developement. The latest updates to the FT have made a big difference.

I'm looking forward to having another tool to use with FORScan Lite on iOS, when the FORScan team adds support for for the FT

[Tazzi]

More updates!
I had a developer identify a unique issue where disabling the OBDX's auto formatting for CAN was causing the CAN frames to send as 29bit instead of 11bit as desired.
This really only affects individuals which were needing to handle every single last CAN frame individually with zero auto formatting which is not very common and is why this one has snuck past us!

This fix will roll out in the next OBDX firmware updates.

Next on our list (finally), remote J2534 programming.
I have been itching to get back to this project, since there has been a lot of requests for this over the years.
There are various options out there for sharing a USB over the internet or streaming CAN data over the internet, both options have quite strict latency requirements to work.

Where J2534 over the web differs, is the command/request is transferred over the internet, rather then trying to stream the USB data, what this means is:
1) Less strict latency requirements, since the actual communication to the tool is done at the client side directly and not passing USB data over the web.
2) USB and wireless can be used since the host application is not needing to explicitly connect to the tool.
3) A client can use a smartphone instead of a PC.
4) Allowing both local or even international programming (International would take a long time for flashes!!)

The main aim here is to have a client application as both a PC and android app and eventually implement iOS (This requires more attention being iOS is so particular with everything).

Majority of the work has already been implemented, it is just a matter of stress testing the API to identify when a server should auto scale to handle higher traffic.

If interested in testing this out, now is the time to contact! Currently I am testing between computers locally, internationally and also while using a VPN to give various different circumstances, but will be good to get live user feedback

[Denny]

Hi Tazzi. That's awsome. I would love to check it out. So only the client would need the hardware? Or both? Thanks.

[Tazzi]

Hi Tazzi. That's awsome. I would love to check it out. So only the client would need the hardware? Or both? Thanks.

Only the client would actually need the hardware.

The host side would need nothing connected.

[Denny]

Hi Tazzi. That definitely opens up some possibilities, especially for people like me just starting out. What is your latest and greatest OBDX model? Any new products coming soon that I should wait for? Thanks.

[Tazzi]

Hi Tazzi. That definitely opens up some possibilities, especially for people like me just starting out. What is your latest and greatest OBDX model? Any new products coming soon that I should wait for? Thanks.

It should open some doors for quite a few people that are wanting to get into the remote side of things!
Some of the subscription based J2534 applications out there are quite expensive, so it can be hard to recover costs without charging high amounts per job. Having remote J2534 with OBDX will allow individuals with these softwares to offer solutions to customers that may not be in their immediate area, and also allow offering to customers with just a smartphone.

The current tool line is the OBDX Pro FT, GT and VX.

We will eventually have a version 2 edition of the above tools, along with an OBDXPro ONE tool, but we do not have any estimated times on this.

[Tazzi]

I must have changed this a dozen times now and I am unsure which way to go about it for the connection for a Host and client for remote J2534.

Using things like teamview and anydesk as the example "remote" setups to connect between a host/client, there is always a point where the client must provide information to allow a connection.
The two methods from these vendors are:
1) Provide a ID number and password
2) Provide a ID number, and client actually clicks accept on incoming request

Both have their pros and cons, but I still find it a bit of a fuss to get the client to send what is needed to the host.

with that said, currently I have set it up to:
1) Client connects up and is prepared for a host to join the session.
2) An automated short token is generated and displayed to the client (for example: R4M2-X7Q8) which they give to their host
3) Host enters code and joins the session.
4) Host and client can then communicate via a text chat system, both can disconnect from the session at any time.

Even though the code is relatively short, it still seems easy to muck up in some way, especially if someone is having to repeat over the phone.
Maybe having the ability for the client to enter in the hosts email to contact them with the code?

I am trying to design from the clients usage, since it is likely they will have the least computer/technical experience in comparison to the host.

On the security side of things, I have spent a considerable amount of time thinking how someone may attempt to abuse the system.
The most obvious is preventing someone from bruteforcing a random connection, along with ensure all data remains safe.

I have solutions to prevent mass spamming to join/create sessions (From host or client side) along with ensuring only two people (host and client) can be joined in a session. This also includes the prevention of simulation/clone of a client or host session.

Something that I am planning to implement is an option to enable encryption of the entire data packet (inside of the SLL socket) for another layer of protection, although this can introduce further latency on the communication, but may be wanted when doing any flashing of sensitive information requiring security codes.

Making progress, but just need to settle on a connection method!

[Tazzi]

A new update for the OBDX Pro GT Tech2win DPDU API driver will be available on the OBDX Pro site shortly.

I made some progress with dealing with a couple issues:
1) tech2win It will attempt to set filters for protocols which have not even been connected yet (But it still requires/uses these filters).
2) It opens 8 CAN connections all at the same time (2x MSCAN, 2x HSCAN, 2x GMLAN, 2x ECAN)

Item 1 has been fixable by keeping a temporary record of all the "new" protocol IDs that it provides when setting filters, then matching these against when a new protocol is actually opened and connected.
The correct procedure is the OBD protocol is to be 'created' and then the allocated ID for that protocol is then used for every command for that protocol (Such as setting filters), but unfortunately this is being done backwards. This primarily causes a problem when more then 1 protocol is required (ie.. HSCAN and GMLAN) where there is a bug in the tech2 emulator coding that incorrectly handles this.

Item 2 has required a bit of smart coding to handle the mess of CANs. Basically MSCAN/ECAN are both ignored, since I am unaware of any GM vehicle which uses either of these for the entire lifetime of tech2 based vehicles.
The GT will now switch to the required protocol when a write network message is requested, which allows it to communicate and read on both networks at the same time.

This fixes an issue where performing the vehicle module presence request in tech2win would result in only 1 CAN line of modules appearing, this now allows for both (GMLAN and HSCAN) to be read at the same time.

I can now see and understand why there are very very few companies on the planet which offer tech2win support, the ones that do typically have a driver that is specifically designed for tech2win since it requires some 'interesting' adjustments outside of the spec to keep it happy.

If all protocols could be enabled at the same time then this could probably be handled clearly, the "opening/closing" of protocols could be ignored since I believe the tech2 enables all OBD protocols at the same time then just requests to read/write to each individually as needed. Unfortunately the OBDX cannot enable every single one at once, but this is something to look at in future tool revisions.

[Tazzi]

While testing the new OBDX v2 tools, I have been diving into the CAN FD support which also implemented the iso ISO15765 revisions.

The really big change is going from a max packet size of 4kb to 4gb (Yes, gigabytes), I had mentioned this quite a while ago (Fri Mar 10, 2023), but only now jumping in to see what the industry is actually doing about this.
I have been excited to see what other manufactures have chosen to do to meet this requirement, either stream or partition the blocks as a 4gb ram buffer is pretty much unheard of in any tool.

With that said, I cannot find a manufacture which currently uses the J2534 5.00 API and looks like even Bosch doesn't yet have 5.0 support added in either.

I would be curious if anyone has come across 5.00 on any dealer software? A quick search doesn't seem to provide any confirmed results!

*Edit

Apparently Nissans dealership software uses it. Dealing with Nissan parts will be a first for me, time to get some parts in!

[Tazzi]

Still more work to do with Tech2win.

I have had an end user find that clicking the Read All DTCs from all modules results in missing a couple of the modules in the vehicle.
I am going to guess this will be one of these tricky incorrectly set filters going on or possibly a completely new issue.

Going to keep soldering on with applying patches to each of these issues. Its starting to sound easier to make my own tech2win at this point