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 »

Today's adventures are to see if my PC's bluetooth low energy (BLE) will integrate with the J2534 driver nicely and allow read/writing chunks of data without huge loss of speed. I know classic bluetooth is able to keep up with minimal time difference, so hopefully BLE should still be in the same ballpark.

Our wireless driver uses an ESP32, alot of online documentation indicates this allows up to 90Kbytes/s which is WAY more then we require. In saying that, this is likely assuming a 1 way direction of data which would allow constant flow of large chunks of data. Whereas data from an OBD port would be small chunks in comparison so sending many small chunks with the inherent small delay caused by wireless will likely drop that output alot.
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 »

Just your standard midnight madness update with Tazzi! :lol:

Have not had a chance to progress with BLE testing in J2534, but, we have a new update for the OBDX Pro GT J2534 API v1.0.0.4. This update addressed a couple important items:
1) Delay between CAN frames has been reduced from 1000microseconds to 10microseconds
2) Delay before sending flow control message reduced from 5000microseconds to 1000microseconds.
3) OBDX can be detected without the OBDX driver installed.

Why does this matter? Well this really only affects when doing long read and write procedures, typically large calibration or OS updates.

The reason they were not at these values originally was due to setting a 0 delay results in some car ecus failing to respond since the CAN frames from the scantool are sent so fast, that the car ecu actually drops messages.
The SAE standard says I should not need delays if the ECU says that it does not require them (Which is part of the flow control message), but real life results indicate different, without these delays I was able to consistently make various GM modules fail updates.

This would also be why some J2534 tools are faster then others, as they all have a little delay between frames, whether it be intentional or due to the firmwares operating system causing delays, its enough to ensure compatibility with as many car modules as possible.

I have then extended the ability to customise these options via custom J2534 commands to allow developers to edit them if wanting faster results. The current change above made a huge difference to large read and writes, and again shaving more seconds if reducing both to 0.

The next part is the OBDX cable can now be detected without the OBDX driver installed, the J2534 API searches for the VID/PID of the USB connection as a backup since its a common issue for customers to plug the cable in and not install the driver. This modification will also roll out into the next update of Tech2win DPDU API and OBDXPlorer.
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 »

Couple updates regarding J2534 again.

I need to update the J2534 installer for 32bit OS machines. A couple people running windows 7 32bit OS's have come across the issue that the J2534 registry installs to Programs Files (x86) when it should be going into Program Files (My mistake!).

Next, is TIS2000. It is ancient software.. but... for the sake of supporting everything... I have been made aware of a couple problems:
1) An update to the J2534 DLL is needed to ensure the RXD buffer is emptied after 'disconnect' is run. Might as well also do this on "connect" to be safe.
2) On J1850-VPW, tis2000 sets a filter and mask of 0. This means EVERYTHING is passed through, this command appears to be ignored by the cardaq and MDI.

Issue 1 occurs when tis2000 requests a 'echo' of the frame it has written, but then closes the protocol connection instantly and then opens a new connection. Open reading messages, the first message it is seeing is the "echo". (Easy fix for this!).

Issue 2 is an easy fix, but is another perfect example of scantool manufactures actually ignoring the SAE standard and creating their DLLs based on softwares available. This makes sense why the MDI and drewtech tools do not respond to setting a mask and ID of 0 since these tools would have been used with tis2000 once upon a time. When allowing ALL frames through from the car, this results in tis2000 to error out when programming modules since tis2000 only sends tester present messages after every successful message message from the module saying it has written the data.

When the module is slow, and takes multiple seconds to respond with a 'successful' message, the rest of the car modules wake up and start talking. As soon as any car chatter is then sent to tis2000, it then errors. If the module being flashed was faster, then the issue wouldn't occur. To eliminate the issue, the ignoring the mask/ID of 0 completely fixes it. Technically the car still wakes up but tis2000 doesnt see the messages and still proceeds (Stupid... I know).
This wont affect the GT from streaming J2534 live data from the car, since I have programmed it to ONLY ignore an ID and MASK of 0. If you set the ID to anything else and a mask of 0, then it will result in allowing to stream all data.

Finally. Iv spent more time then Id like to admit on BLE. All libraries for BLE are designed for async functions, it does not play nicely on non-async. J2534 does not allow async functions so a non-standard J2534 is being made to test out flashing using BLE. Its been a bit of a pain in the ass... but alot of progress has been made.
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 »

Oh actually something else Iv found quite interesting, Fords FEPs and J2534 requirements.
There is next to nothing available about FEPs that I can find online other then its used for PCMs and needs 18v. What I was more interested in was the amperage requirements, since a common issue with Mongoose and Tactrix cables appear to be blowing up the FEPs pin.

After a bit of searching, I found the J2534 information indicates that programming voltage pins must support up to 150mA. Its not a whole lot, but, getting to 18v with 150mA means a boost (stepup) regulator is required. Going from 5v to 18v is very much possible, but this ends up requiring 600mA from 5v to produce the 18v at 150mA, and thats not including powering anything else on the tool! The solution here is using a buck boost regulator setup that will allow us to accept a range of input voltages using the battery voltage pin, and scale it up to 18v. The only concern we will have here is ensure to only power the buck regulator when the battery voltage is high enough (between 10-16v) which ensures we do not pull too much current through the buck, and only operate during safe conditions.
To help prevent popping the regulator if there is a shortage, an automatic resettable fuse will be used to pop around the 500mA area. This entire circuit is about a quarter of the board space we have, hence its not exactly small or simple design!

Our new OBDX Pro FT will not be using the boost regulator setup for FEPs, since we just physically do not have the space for it, but it will be used on our eventual dedicated J2534 tool that will likely be the size of an MDI. The OBDX Pro FT uses a relay to bridge FEPs to battery voltage which appears to be enough to work for all modern Ford PCMs, but is apparently an issue on older Ford PCMs (We haven't tested older, but have been indicated so).

Just a bit of interesting information is all!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
In-Tech
Posts: 778
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: OBDX Development - Developer Tools and Suggestions

Post by In-Tech »

Very nice Tazzi, self healing fuses are cool as shit. I am using much higher amperage so am jealous of your price :)
User avatar
rolls
Posts: 407
Joined: Wed Sep 07, 2016 11:22 am
cars: bf xr6t falcon

Re: OBDX Development - Developer Tools and Suggestions

Post by rolls »

Tazzi wrote:Oh actually something else Iv found quite interesting, Fords FEPs and J2534 requirements.
There is next to nothing available about FEPs that I can find online other then its used for PCMs and needs 18v. What I was more interested in was the amperage requirements, since a common issue with Mongoose and Tactrix cables appear to be blowing up the FEPs pin.
Simply current limiting it might be a simpler idea as the actual real world usage should barely use any current at all. I think the blown pins are due to shorting it out with improper circuit protection in place.
In-Tech
Posts: 778
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: OBDX Development - Developer Tools and Suggestions

Post by In-Tech »

agreed, it's the spike. Generally a current limiting diode will suffice, otherwise a resistor can do current limiting spikes too which is funny, a lot of people use a resistor so the caps don't blow up :lol:
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 »

rolls wrote:Simply current limiting it might be a simpler idea as the actual real world usage should barely use any current at all. I think the blown pins are due to shorting it out with improper circuit protection in place.
Basically what we are trying to achieve 8-)
Just limiting the maximum current it can draw using a self healing fuse. That way we should prevent serious damage to the tool or vehicle.
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 »

More hours then I would like to admit with BLE, but we have full reflash of a 480kb Operating System for a GM BCM.
Usually flashing this OS takes 2mins by USB, whereas by BLE it takes 6.5mins so its roughly 3x as long.

I have certainly learnt more about BLE then I ever though, important notes so far:
1) BLE 4.2 supports up to 250ish bytes per block... but, most devices never use this/
2) The client (Smart Phone/PC) is the one that determines the MTU (Maximum Transmission Unit) size. This is how large of a block you can send/receive.
3) Android device automatically set the MTU to 20bytes. This is intentionally since the bluetooth stack can vary between devices and their memory limitations.
3) Sending data with a response (verification that data was received) is painfully slow. Sending without response is much faster.

This is not really a very viable option, but it does prove it can be done. The current method requires sending chunks of 20bytes to the processor without verification and a small delay between packets. Once the entire frame is sent, the OBDX tool responds with successful once the block is successfully sent so even if BLE failed to send a block, the OBDX tool would inform us that data is missing.

As a diagnostic application, BLE 4.X would ok, but for full reflash abilities it is not really ideal. For people like myself which offer custom calibration changes on BCMs and radio systems, it just doesn't quite cut it.

BLE5 would be something better suited here since it has double the transfer speed, and the most important feature being its message capacity is 255bytes by default, so this is already 10fold of BLE4.X (This assumes Android doesn't still default 20bytes... but I don't believe it will).

I have some of the newest ESP variants on the way to test out the BLE5 implementation, assuming this works well, we might be migrating to this wireless controller.
Something that I am not too happy about if moving wireless controller is the newest ESP processors do not support bluetooth classic, they only support BLE5 and wifi.
Basically every single OBD2 android application uses classic bluetooth connection, there are only a few that offer connection to BLE devices, and these then require contacting the developers to add the device name to their BLE supported list.
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 »

Ultimately, wifi would be the best fit for speed and size of data that can be sent... BUT... this results in any tablets without simcards to be unable to use internet. And devices with a simcard will still struggle with internet usage at the beginning as they try to use the connected OBDX wifi device as an internet point which they cannot, then typically ask the user if they want to use cellular data due to lack of internet from wifi connection.

For applications like I produce which require internet access for things like account information and downloading calibrations, having no internet is not an option, this does basically eliminate wifi as an option here.

One final solution is to utilize something like the RN41APL or RN42APL which is a classic bluetooth module that has been apple certified. This means we can use the classic bluetooth connection on iOS and android, since iOS prevents you from using classic bluetooth unless the wireless device has a special authentication chip implemented on the tool. These SoC have this already done, so its just a matter of soldering them onto the board and away you go.

Whats the catch with using these modules? Well... they are at the "End of Life" cycle. This doesnt mean you cannot get them, it just means that eventually ordering them would require buying them by the reel. Along with being harder to get your hands on in smaller quantities for development. The next gotcha is they do not support BLE meaning all generic OBD2 applications for iOS are no longer supported.


It could be that OBDX needs to split between tools used for generic diagnostics, and tools used for commercial/professional wireless flashing?

*Edit
Aha! Theres a newer revision that can be used: RN4678APL
This supports bluetooth classic and BLE5... so we have best of both worlds! We lose wifi.. but.. its worth the loss in my opinion

And just for reference: https://microchipsupport.force.com/s/ar ... ted-by-iOS
Basically to get information about using it with apple, need to be registered for MFI and contact their team.
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