OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

hjtrbo wrote:Is it poss to do what to some apps do. When you deny a required permission it just exits out of the app. Brutal but effective.
Yeah, thats what I am trying to do, it will just do pop up saying application is unable to run without "xyz" permission.

But even doing that is being a bit of a headache. I will need to go over some more examples to see where Im going wrong.
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
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Update time!
MAUI is an interesting demon to play with. I am enjoying using it, but, the basically enforced usage of async functions is a bit annoying. I typically run everything into a separate thread regardless, but certain actions seem to still hang unless running as async which makes zero sense, it appears its almost hard coded to expect a async function to be used even if the correct handling is used on a separate thread with main UI invoking... regardless... I have updated all my imported code to async to keep it from having a mental break down.

Also have made some progress with communication using Bluetooth Low Energy (BLE). Originally I wanted to use bluetooth classic on android and BLE on iphones, but for the sake of simplicity, we are going with BLE.
Also, bluetooth classic was causing myself a heap of grief to implement which appears to be an issue with Maui. It seems data can be read from a port faster then if its actually received, resulting in receiving corrupted data, only way around this is adding in random delays to slow down reading process which isn't acceptable. I would check if bytes were available in the port before reading each individual byte, but still would have the same problem.

For simplicity, we are going with BLE since this means both android and iphones should be able to share the same 'core' coding for BLE handling. I still need to test with the iphone, but there shouldnt be differences other then permissions required for iphones.

Permission have to be the biggest pain in the ass ever, it took two 12hour days of trial and error to get a combination of permissions that actually allowed scanning for BLE devices with MAUI. All examples indicate adding the permissions to the android manifest.. which honestly.. did absolutely jack shit. With the correct permissions, we can scan for devices and then filter from there. Inbuilt filtering does not work, at least not with the plugin I am using, it should work... but... it doesnt... instead we get a list of all devices and just filter by name to show all OBDX Pro devices available.

So far BLE seems to be pretty quick, it does setup the tool and get some information from it (same as OBDXplorer does). Next is adding in a navigation menu to search between vehicles/options and finally the juicy stuff, actually testing full reflashing with BLE. Technically speaking, BLE is rated for 1Mbit/s, so.. this is twice as fast as highspeed canbus technically. We should be able to be transfer 128k bytes per second.. so any large 2000+ bytes should be fine. Now.. this is all theoretical until we try it 8-) I expect results to show slower then expected above, purely due to the nature of wireless lag, but I think it will be acceptable.
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
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

So we have a home screen.
After clicking the connect scantool button, it will do its connections (While prompting the user) and finally change to green and say "Open Vehicle Menu".
What I need to work out though is adding tabs that will allow switching between news, scantool details and vehicle details.
Simply because there is currently no way of showing other details after connecting to the scantool and car.. so having those will allow a little bit more information to the end user :thumbup:

Next is making sure our vehicle navigation is sorted. Currently its reading the VIN from the engine computer, decoding the VIN to identify the vehicle and then building the supported modules list from there. I just need to not implement a basic VIN decoder to get this next part done!
LayoutNCSFlasher.PNG
LayoutNCSFlasher.PNG (75.03 KiB) Viewed 1691 times
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
vs ss
Posts: 591
Joined: Thu Nov 03, 2011 7:57 pm
cars: hsv enhanced vs ss
vt xu6
fb holden
toyota landcruiser
vt ss s1
Location: perth wa

Re: OBDX Development - Developer Tools and Suggestions

Post by vs ss »

Finally got to sit and have a read of this today. This looks really awesome mate, nice work as usual :thumbup:
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

I have hard coded it for now, since its just easier to make progress then making a full fledged definition file for vehicles to navigate screens, this can be something to complete at the end.

The smarter option would be to use a definition file to build the list of options to change , although I do find this hard to implement due to the nature of complexity of the calculations on some options. Some require multiple bytes in different locations changed, whereas others are just an 'on/off' switch. So, even though it goes against what coders are taught, I believe making a "page" per module is best. These pages can inheret a base page which will have the main options to set such as protocol, filters ect so the scantool can automatically setup.

Using tabs along the top of the page as different categories for the module will be the easiest solution I believe instead of everything being in one giant list which can be a bit overwhelming. Or even if its to split up calibration writing and DID writes since they are very different flashing time requirements.

Should have a demo of programming something soon!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
vs ss
Posts: 591
Joined: Thu Nov 03, 2011 7:57 pm
cars: hsv enhanced vs ss
vt xu6
fb holden
toyota landcruiser
vt ss s1
Location: perth wa

Re: OBDX Development - Developer Tools and Suggestions

Post by vs ss »

Nice! I actually understood that :lol: It will certainly be a great tool to the industry and I’ll trust whichever way you lay it out or build things as your certainly an asset for people like me/us who like tinkering with our cars without relying on dealers ( that usually don’t have the tool access to change things we need ). Then can’t turn things on like your custom tool can due to access. Anyway that might make sense and cheers for this! Rambling over
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

10k lines so far (Excluding the OBDX class).. soooooooooooooo many more to go. :lol:

Majority of this is related to automating the connection process to read the VIN and identify the car, then identify modules present to dynamically create the vehicle modules navigation screen.

The actual module pages are split into three tabs which include:
1) Options
2) Flashing
3) Information

Basically options is our more simple changes that do no require full reflashing.
Flashing is for programming in new OS and/or calibrations to the module, along with any custom edits that are calibration based.
And information is just details about the module including VIN, partnumber ect.

Couple little things I will need to think about is placement of security related features such as key programming, ECM security linking ect. I guess this can come under options with its own tab system along the bottom to switch between different options screens possibly.

This weeks goal is having a working demonstration to program a VE BCM and VE Radio.
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
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Update time!
Our first batch of OBDX GTs for pre-release have sold. We will have another lot of stock to release in the United States soon.

Next, the app will be on hold for a couple weeks while Pete and I create a prototype J2534 gateway tunnel. The tunnel is designed to turn two J2534 tools into a passthrough over the internet. In short, it will look something like this:

Scantool or Handheld tool -> Tunnel J2534 Tool #1 <-> Tunnel API <-> Tunnel J2534 Tool #2 -> Customer Car


Hence the J2534 tools are basically just passing the data to/from the desired scantool to the customer car. There are similar devices out there which do this, but use dedicated hardware designed to capture every single last CAN frame and pass over the internet. I have MAJOR concerns about lag and how this will affect things like CAN flow control and message formatting like that which have extremely strict time constraints, but I believe this can be eliminated by the J2534 which have inbuilt flow control handling thus can keep each side of the tunnel happy and handle the inter frame formats.

To minimise lag, a direct socket connection between the host and client would be ideal. This eliminates lag from bouncing off a server, but does mean alot more setting up for the host to open ports ect. As a prototype, we will start with direct socket connections between host and client to ensure it works the way I imagine. As far as Im aware, the above has never been attempted using J2534 tools in this fashion, its well outside of what they were intended for.. but... it just might work...

For the fastest possible connection, if moving to a server, will likely need to be a gaming grade server. Id preferably want to work with a windows based server, but since this is basically a basic socket connection app, it wouldnt take a whole lot of work.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: OBDX Development - Developer Tools and Suggestions

Post by kur4o »

What you are looking for that might be less trouble to implement fully iso15765 protocol to overcome can segmentation. I don`t see a reason you use second device, It will be much better to make the device Network based, like the Mdi, maybe some ethernet controller.

I did some test with mdi over poor quality wireless network, and there was noticable decrease in performance
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

kur4o wrote:What you are looking for that might be less trouble to implement fully iso15765 protocol to overcome can segmentation. I don`t see a reason you use second device, It will be much better to make the device Network based, like the Mdi, maybe some ethernet controller.

I did some test with mdi over poor quality wireless network, and there was noticable decrease in performance
This is kinda the route I ended up going which worked much more reliable.

So, a basic CAN passthrough does work, but its extremely unstable as soon as there is a ping of more then around 60-70ms. This is because CANBus has formatting requirements such as 'flow control' which is used for read/write multiple lines of CAN data at once. If the response is longer then I believe 50ms (ish), the module assumes failure to respond.

I did successfully reflash an ECU and also BCM using a local socket connection on my network, ping was basically 0 since its my own home network. So I introduced delays in the coding to simply not pass a response for "X" milliseconds until it started causing problems, and this occurred from 40-70ms depending on the module being communicated to. I understand gaming grade servers are explicitly designed to provide the lowest possible latency, but, this does not excuse the host or client ends from having terrible lag which is uncontrollable. Making the assumption that an end use is not going to use a hotspot/poor connection is just asking for mass amounts of complaints and problems, even though it could be part of T&C's. A system to test ping is easy enough to implement as well to limit such failures.

Now, using a SAE ISO implementation where all the CAN flow control is automatically handled was successful, I was able to introduce a delay of 500ms, and this still worked (Although extremely slow!). The issue with this method is it requires the tools to be aware of the vehicle and modules being connected to, so it knows which frames to filter for, which to setup for flow control ect. For instance, on a GM vehicle to communicate with the engine computer, filters/flow control would need to be implemented on 7E0,7E8,5E8 and 101. This covers the ECU for diagnostics and flashing routines.
If multiple modules need to be communicated to, then their IDs would also need to be known to apply filters for.

This does then introduce quite a difficult task of mapping every module for every vehicle/manufacture so the above method can work. So it 'could' be done, but its WAY more work then I was intending for a concept.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Post Reply