OBDX Development - Developer Tools and Suggestions

[Tazzi]

USB-B, the gold standard in the automotive industry. Just not Micro USB again please...

Until we can find someone with the skill set to create OBD cases in 3D modelling software, We are at the mercy of the premade designs.

I personally dont have issues with micro. I have major issues with the "mini" which is whats used on the tactrix and GM MDI.

Ill load up pcmhacking on the phone later to grab a snap of the case we are building towards currently.

I do have a 3D scanner, so Im tempted to just scan this case, and potentially fatten it out so we have a bit more room for this new tool design. Which may become the next generation of the VX/FT/GT tools also, since I would like to get Kline on all tools, plus PWM on the FT.

[Whiteford]

Speaking from experience in the field, Micro is far less durable than "mini". It is like comparing two pieces of crap though, at the end of the day, they are both terrible.

[Tazzi]

Id say its from techs hitting cables when plugged in the dash which can result in damaging the USB port.

The micro on tactrix is already kinda loose and its only been used a dozen or so times on a bench setup, so I can totally understand how that can become unstable.

I actually find USB C to kinda wear down faster for "slipping" in and out of a device. After having several type C devices, depending how often you plug into then, I find the actual hooking mechanism in the USB port itself (Not the cable) appears to wear out so it can be pulled out easier. But.. this seems to happen with all USB ports hence the endurance.

The only thing thats lasted the longest of anything I have ever dealt with is USB B. Its just extremely bulky is all.

[Whiteford]

I couldn't agree more

[hjtrbo]

DB9 served well for years. Maybe a retro edition for future release?

[Tre-Cool]

even efilive went away from the old using rj45 connectors for the obdi plug to using a molex type connector.

i need to cut and remake the cable every now & then when the locking tab breaks off.

[Tazzi]

I am interested to learn whether the EU is going to force all electronics to use USB C, since this will probably dictate if we move all new designs to C in the future.

The one exception is the new design we are working on which is USB B.

[Charlescrown]

Maybe not EU. I buy from Wes Components and they sent out an email saying USB C was now the new industry standard. Ah whay did Apple hold out and we now end up with this.

[Tazzi]

Use BLE they said, it’ll be fun they said

After searching for what seems for ever (2years?). I have FINALLY come across a BLE module that has a through put which is acceptable.. in fact.. I’d go as far as saying absolutely incredible.

Using our current wireless module with BLE (not classic Bluetooth), I found I could get around maybe 4k bytes per second. It was very slow and not suitable for doing big flashes.

With the new module I am testing with, I was able to get 40k bytes per second with BLE! That’s 10x the speed!

To put this into perspective, a P01 ecu memory size is 512k. I can transfer 512k in a bit over 13seconds.
In comparison to the old BLE, it takes 2min 8seconds.

One of the biggest differences here is BLE5 and also sending at 244bytes per frame at 5ms intervals.
The theoretical max value of this would be 48.8k/sec. Only way to increase more here is increasing the frame size but my iPhone is locked at 244bytes. If I could do the 512byte frames, could ramp this up to around 100k/s, which I suspect the newest iPhones would support.

This is a massive leap forward for iOS speeds. Even though wifi would work for iPhones, using BLE is a lot less hassle for the end user so I’m excited to put together a demonstration app for flashing via BLE for real time life examples.

Unfortunately there are cons to using this new module. It does not support wifi or classic bluetooth. This means basically every single OBD2 Android app will no longer work with OBDX tools since they are almost all designed for classic bluetooth, whereas iPhone obd2 apps have to support BLE or WiFi.
The module is also 4x the cost of current solution, so that’s another big factor.

With that said, this will likely be put on a OBDX tool that is strictly designed for speed with smartphone apps. So it’s not really intended to be used as a generic scanner, but a dedicated tool for smartphone (more on that soon!).

[Tazzi]

Im back in action after a holiday away.

OBDX is getting so many cool things being worked on at the moment, its alot of fun!

The J2534 API for all tools will be getting an update which will enable the ability to turn on WIFI and Bluetooth connections.
An update for the tools will also need to be run to utilize this update to fix a WIFI speed issue.

Bluetooth does actually require running another exe in the background to process the bluetooth connection, since the bluetooth API cannot be directly integrated into the J2534 API due to conflict between managed/unmanaged memory, so I have setup a local socket connection between the J2534 API and the bluetooth API.. its alittle bit of double handling but it does achieve the goal.

The next item I have been excited playing with, is the potential for addition of an SDCard to a new design we are working on. With that, I have been able to do semi and fully automated setups for read/writing engine computers using the tool (Pretty damn cool!!!!!). Logging can also be setup to begin saving logs to the SDCard, and can then be later uploaded to a PC using wireless or USB connection.

This is all abilities being worked on as per customer requests, obviously aimed towards the remote tuning industry, but its the next generation in remote tuning when combined with a smartphone app to manage and handle tunes loaded onto a device.