OBDX Development - Developer Tools and Suggestions

[In-Tech]

Yes, it can be very frustrating.

Oh, I'm sorry, after re-reading, you were looking for diagnostic requests. From memory, the ground points turned out to be critical for stream reliability.

Good on ya

[Tazzi]

So far so good with the PWM.

Learning quite a bit about other J2534 devices, ELMs ect.
The ELM circuit is a bit lazy, we see the following kind of timing occuring from it:

Code: Select all

L: 33
H: 15 - SOF

L: 17
H: 7  -This is first bit (0)

L: 9
H: 15 -This is second bit (1)

L: 9
H: 15 -This is third bit (1)

L: 17
H: 7  -This is fourth bit (0)

L: 18
H: 6  -This is fifth bit (0)

L: 10
H: 15  -This is sixth bit (1)

L: 17
H: 7   -This is seventh bit (0)

L: 17
H: 7   -This is eighth bit (0)

Basically for PWM, the Start of Frame (SOF) is ~50micros, where 2/3rds of it will be low, and 1/3rd will be high, hence our 33micros low then 15micros high. It wont always be 50micros as per the SAE standard, but 48 is close enough.

The next 8 sets of Low/highs are each bit of the first byte that was sent from the ELM which decodes to 0x64. Each bit is ~24micros, again split into 2/3rds + 1/3rd for low and high. Do keep in mind the above is based on the PWM - line which is at a constant 5v. When the line is low for 2/3rds then high for 1/3rd, this represents a 0 bit. Whereas if low for 1/3rd and high for 2/3rds, this is 1 bit.

The interesting part here, is you can see the timings for a bit 1 are closer then that of bit 0. This occurs due to the ELMs circuit is a bit lazy, where its not driving the pin state down fast enough. While monitoring data from the ELM, occasionally we would get as close as 3micros difference between the LOW and HIGH which is cutting it VERY close.

In comparison, we get the following response from the ECU:

Code: Select all

L: 31
H: 17 -SOF

L: 7
H: 17 -This is first bit (1)

L: 8
H: 16 -This is second bit (1)

L: 16
H: 8 -This is third bit (0)

L: 16
H: 8  -This is fourth bit (0)

L: 16
H: 9 -This is fifth bit (0)

L: 7
H: 17  -This is sixth bit (1)

L: 15
H: 9     -This is seventh bit (0)

L: 15
H: 9  -This is eighth bit (0)

At no point does the ECUs response change more then about 1 micro, its very precise and constant the whole way through. This could be due to using a dedicated J1850 transceiver though, which will likely produce such results.

Where it gets interesting, is going to highspeed PWM.. this doubles the speed, so we hit 83.2kpbs.
Timing for SOF drops to 25micros, and timing for each bit is 12micros. This means each bit is split into 8 or 4microseconds.
This just gives a bit of insight for how tight timing is for this, a couple micros lazy either way would result in an undetermined bit result.

At this time, I don't yet know how to put this PWM ECU into highspeed mode, the only way I can simulate it is using a J2534 scantool and also my own PWM prototypes.

The J2534 in use seems to be favorable to making a larger gab between the two bits, aiming for 3-4micros for the 1/3rd section and then 9-10micros for the 2/3rd section.
This tends to give a good clearance of 5+micros which is more then enough difference to identify.

When playing around with sending data to the J2534 tool, it appears timing can be fairly out and it still picks it up. So if I sent a 3micro low, and then a 13micro high, it still manages to decode this even though the high is just as long as the entire bit is suppose to be. My guess on this is its simply determining if the low is longer then the high to identify the bit. If I make the gab large enough, the J2534 doesnt pickup the frame so there is a limit.

PWM will not make it into our Ford dedicated tool, the OBDX Pro FT, simply due to space requirements. We basically have a choice of keeping FEPs or keeping PWM, and we feel FEPs is the better option. Eventually we will have a tool that has PWM on it, just not yet.

Hopefully the above helps any developer looking to create a PWM tool, surprisingly theres even less about PWM then there is for VPW!

[Tazzi]

We have our first MAUI NuGet available: https://www.nuget.org/packages/OBDXMAUI/1.0.0.1
This NuGet is what will be referenced in the MAUI template applications I have been building. Basically this library exposes two core classes: J2534 and Scantool

The Scantool class is a raw implementation of the OBDX tools. What I mean by raw, is it is using the direct corresponding commands to control the OBDX device to provide the fastest and most streamline communication.
The J2534 class is a 'fairly' close implementation of the J2534 SAE standard. Its not a perfect implementation of J2534 spec since we have to use ASYNC functions, meaning functions cannot use references, thus some variables had to be moved around.
The J2534 uses the scantool class for all of its communication/control, it basically is just exposing the same J2534 command structure that developers are familiar with.

I have not yet made any documentation for using the NuGet, but will upload a MAUI project to GitHub soon that demonstrates how to use both J2534 and Scantool options to connect to an OBDX tool, read a basic mode 20 from a GM ECU and finally read the battery voltage from the scantool.

I have added in all the permissions handling into the OBDXMAUI NuGet so it will request as needed, end user still needs to add these permission so their project though. I have also added in an option to allow selecting what kind of communication is being used (USB, Classic BT, BLE, Wifi). At this moment, only classic Bluetooth for Androids is implemented, but I am in the works for adding direct USB connection for Android.
For iOS, we are going to be limited to BLE (Extremely slow - Not recommended at all) or WIFI. The WIFI implementation is not working on all devices, I have narrowed it down to the iphones routing stack not selecting the correct interface thus fails to communicate on certain phones. I am still waiting to have a iOS guru look into this with me to specifically target an interface.

[Tazzi]

For iOS support, Pete and I are working on a new scantool that is specifically designed for wireless speed.

This is the tool that caused us to join the Apple MFi program so we can use an MFi approved bluetooth dongle, this allows us to create a classic Bluetooth connection with iOS to achieve speeds of around 18-20k bytes per second.
This doesnt sound like heaps compared to android devices that can theoretically achieve around 40-60kbytes on bluetooth classic, but its a HUGE leap over BLE.

My testing with BLE 4.2 demonstrated we could do around 2kbytes/sec, and thats with ALOT of hackery to get anywhere near that, and even then it was not consistent/reliable hence it is not recommended. The BLE could be used for doing little diagnostic requests, but it would not be ok for full reflashing vehicles with.
The newer tool with classic bluetooth support for iOS will (unfortunately) be quite a bit more compared to our current tool range, this is purely due to the change in parts, requirements of MFi and then the difficulties of actually getting all the parts assembled for us.

It realistically is more a tool designed for established companies which are moving from PC applications to smartphones with the requirement of supporting both Android and iOS with fast connections.

[Tazzi]

Right so, I have 100% narrowed it down to microsofts iOS code implementation which is failing creating a socket connection.

In iOS Xcode running on a MAC, the following code works:

Code: Select all

@IBAction func buttontouch(_ sender: Any) {

    var inputStream: InputStream!
    var outputStream: OutputStream!
    var readStream: Unmanaged<CFReadStream>?
    var writeStream: Unmanaged<CFWriteStream>?
    
    
    CFStreamCreatePairWithSocketToHost(kCFAllocatorDefault,
                                       "192.168.4.1" as CFString,
                                       23,
                                       &readStream,
                                       &writeStream)
    
    inputStream = readStream!.takeRetainedValue()
    outputStream = writeStream!.takeRetainedValue()
    
    inputStream.schedule(in: .current, forMode: .common)
    outputStream.schedule(in: .current, forMode: .common)
    
    inputStream.open()
    outputStream.open()
    
    let data = "ATI\r".data(using: .utf8)!
    data.withUnsafeBytes {
        guard let pointer = $0.baseAddress?.assumingMemoryBound(to: UInt8.self) else {
            print("Error joining chat")
            return
        }
        outputStream.write(pointer, maxLength: data.count)
        
    }

The MAUI equivalent is displayed below. The only difference is there is no option to do "Unmanaged<CFReadStream>".
When running the MAUI code, there is a fault inside of the readStream/WriteStreams under the internal DispatchQueue variables stating: "System.Exception: Could not initialize an instance of the type 'CoreFoundation.DispatchQueue': handle is null."

Either the implementation for this is broken in MAUI, or its missing something to initialize the CFRead/CFWrite memory streams. Microsofts documents shows a few examples using those streams, and always leaves them as null, so I would expect its internal issue in the CrearePairWithSocketToHost.

On a side note, apparently native iOS libraries can be p-invoked, so could make something in iOS, then just reference it in the MAUI application. I really would rather not, since thats a huge headache.

Code: Select all

CFReadStream readStream ;
            CFWriteStream writeStream;
 
       
            CoreFoundation.CFReadStream.CreatePairWithSocketToHost("192.168.4.1", 23, out readStream, out writeStream);
  

            NSInputStream InputStream = ObjCRuntime.Runtime.GetNSObject<NSInputStream>(readStream.Handle);
            NSOutputStream OutputStream = ObjCRuntime.Runtime.GetNSObject<NSOutputStream>(writeStream.Handle);

            InputStream.Schedule(NSRunLoop.Current, NSRunLoopMode.Common);
            OutputStream.Schedule(NSRunLoop.Current, NSRunLoopMode.Common);

            InputStream.Open();
            OutputStream.Open();

            byte[] buffer = Encoding.ASCII.GetBytes("ATI\r");
            OutputStream.Write(buffer);

[Tazzi]

Without much success from the Microsoft team to identify whats wrong, looks like the only path forward is creating a library which uses the ios native code.

I have found a couple examples to follow:
https://medium.com/@tema.denisoff/how-t ... 3c54d2173c
https://learn.microsoft.com/en-us/xamar ... ve-interop

*Hopefully* its not going to be too painful. Considering its just a basic library to expose connect, disconnect, read, write ect. One thing I am a bit unsure about is attaching events so I can drive the application to read new data as soon as they arrive.
I would rather not have to be constantly polling the BytesAvailable() method, since its a waste of resources to constantly poll millions of times when its not required.

The only other method I guess is an adjustable timer could be created, where after "x" amount of milliseconds it will increase the delay between checking, then once it finds data it can switch off the delay.

[Tazzi]

Not having alot of luck recently with Maui!

The USB Android implementation was going great, until trying to get reading working. I can happily transmit to the OBDX scantool, but cannot read back. All routines used are using Android specific code so there should be no problems.

But, typical Maui, it has to be difficult. Using the exact same code but in Android studio, it happily reads and writes to the OBDX tool via usb. So something is not being handled correctly through the API wrapper that Microsoft has.

I already know the USB serial worked since a free Android app that allows connecting to usb serial (and has a link to its project online) was able to connect and work correctly too.

I'm guessing the only way to make this work is to make a native Android library just like needed for ios WiFi socket. To say it's frustrating, is an understatement.

[In-Tech]

Not having alot of luck recently with Maui!

So something is not being handled correctly through the API wrapper that Microsoft has.

To say it's frustrating, is an understatement.

I feel ya bro. It seems anything Microcrap these days turns into a headache

[MudDuck514]

Hi all;

Tazzi, are you now using an FTDI USB Interface?
Or does the Android OS now include support for others?

Mike

[Tazzi]

Hi all;

Tazzi, are you now using an FTDI USB Interface?
Or does the Android OS now include support for others?

Mike

Nah, our OBDX tools are a ST processor, so its using the inbuilt CDC protocol that android supports.

Android OS supports an API called Android.Hardware.USB (Along those lines) which allows exposing all the connected devices to the USB slot. From there you can get the USBDevice information (VID/PID), request permission to connect to the device, get the read/write endpoints and finally start communicating with the device.

Iv found a couple Xamarmin plugins which apparently expose the native Android java implementation, so if thats the case, it *should* fix the issue in maui that I am getting.

*Edit
Yep, just as I thought, works perfectly using a library created in java directly. Well.. least I can continue adding the USB support in.