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!