OBDX Development - Developer Tools and Suggestions

[MudDuck514]

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.

Thanks for the answer.
I was curious because the ONLY device I had at the time was a Galaxy Note 8 with Android 7.1.1 and IT would ONLY recognize FTDI interfaces.

Mike

[Tazzi]

Welcome back to another late night with Tazzi and his unspoken discoveries.

I have been doing lots of PWM development recently, as per the Ford AU ECU bench setups, and recently learnt something that I found zero documentation online about.

For those that are not in the know, VPW and PWM are very similar in terms of the protocol layout, but there is one key different that I have found.
VPW does not appear to ever use 'inter frame response'(IFR), whereas PWM does. This is actually quite important, since the PWM ECUs appear to use the IFR as a way to recognize if the scantool has seen the response, if it has not, it attempts to resend the same message another two more times before giving up.


So what does this actually look like? Well.. here is an example:
Scantool sends 64,10,F1,9,0,CF ... 40microsecond delay... ECU sends IFR byte of 0x10... end of frame
ECU sends C4,F1,10,7F,9,0,0,0,11,AB... 40microsecond delay... Scantool sends IFR byte of 0xF1.. end of frame

The 40micro delay is meant to actually be around 50micros, to signify End Of Data (EOD), but, it appears the ECU determies anything over around 35micros as EOD since it sends its IFR byte after about 35-40microseconds from the last bit sent from the scantool. Another classic example of designs not quite sticking the a standards spec!

As I was not expecting any of this, I had to whip out the scope to spot what was going on. Below is a picture of both PWM negative and positive wires, I have highlighted the end of the last bit of a message sent to the ecu, and then the start of the IFR response. You can visually count 8 bits that occur (00010000= 0x10). Everything before that is the actual frame sent to the ECU.
I was surprised to not find a single person talk about this online, I realise its explained in the J1850 documents, but its not exactly well explained plus it doesnt stick to the standard very well. Ontop of that, the IFR appears to be completely pointless, I can send any single byte to the ECU after its sent its message back and it accepts it. Most J2534 tools and also ELM cables send 0xF1, but I sent every value from 00 to FF and every single one was accepted.

The IFR is controlled by a single BIT in the first byte of the header frame, bit 3, if this is 0 then an IFR is required, hence a byte of 0x64 (0110 0100) and 0xC4 (1100 0100) both required the IFR. Supposedly multiple bytes can be sent as an IFR, but these bytes are never passed back to the scantool, so its absolutely pointless.

[Cincinnatus]

I find your research fascinating. Curious though, red highlighted bit isn't bit 5?

[Tazzi]

I find your research fascinating. Curious though, red highlighted bit isn't bit 5?

Bits are one of these weird things that has some rules to follow.

When dealing with bits where the Most Significant Bit (MSB) is first, you always count from right to left.

So there are 8bits, but common programming terminology counts them as 0,1,2,3,4,5,6 and 7th bit which is a total of 8.

Hence my highlighted red bit is bit 3

[Cincinnatus]

Thanks for the explanation Tazzi

[Tazzi]

I know I have gone over this a couple times already, but there are alot of devs following along with progress here so I will repeat it again.

The OBDX Pro FT is our dedicated Ford scantool, it will support standard dual wire CANbus (HSCAN - pins 6/14), MS CAN (pins 3/11) and will also support 18v FEPs.

This tool does not (unfortunately) have PWM or kline. The reason for this is we physically cannot fit anymore on the circuit board. Our only options would be to completely remove the wireless module to recover about 1 quarter of the board space. This would make it a USB only tool.
This is find for people wanting to use a USB J2534 only, but as many devs know (And have reached out about it), majority of clientelle do not have a laptop anymore, thus wireless is very desirable.

We might be able to fit either PWM or Kline (not both) if we move to a smaller wireless module. This all depends on how much space can be recovered from our current wireless module to another. Ontop of that, we do not want to compromise the wireless reliability which takes priority over everything.

The PWM work done above is so we have a protocol design that we can use in the future along with any contract work for customers looking for something specific.

[Tazzi]

Our last addition for PWM is testing high speed mode. After searching for a good couple hours, its clear that it has never been publicly posted for how this is achieved.

I believe this would be related to the ECU needing to be security unlocked first (seed/key) and then the ECU can be requested to go high speed. Due to the security requirements, there probably has not been many individuals which have worked it out other then companies offering flashing capabilities currently.

I would assume this would be done when using IDS or FJDS, so I will need to log this process so I can then replicate it on the bench to monitor the bit pulses at high speed from ECU and our scantool.

Im pretty sure IDS is forced to use VCM2, so might give FJDS a go first

[antus]

you can def. get early ids to do it with gm mdi with the driver hacks weve posted before

[Tazzi]

you can def. get early ids to do it with gm mdi with the driver hacks weve posted before

Fantastic idea!

*Edit
MDI reports back it does not support settings FEPs, so results in the procedure failing to proceed.
Ill need to go find my VCM2

*Edit2
Looks like both my Ford AU falcon PCMs don't want to be reflashed. They keep failing at the same point after FEPs is engaged (Which Iv confirmed 18v).

[Tazzi]

I tinkered around with the PWM AU ECUs quite a bit today. Neither seemed to want to play nicely with IDS for flashing.

It requests to ignition off, then it applies FEPs, then asks to ignition on (All simple tasks). I have confirmed 18v goes to pin13 on the AU falcon ECU as per the wiring diagrams.

When ignition turns on, we get a few frames spit out from the ECU, then 1 from the Scantool, and then no more responses.

Code: Select all

00 05 10 04 00 08 0B 61 00 31 - From ECU
00 05 10 04 00 08 0B 61 00 31 - From ECU
00 05 10 04 00 08 0B 61 00 31 - From ECU
C4 10 F5 31 A0 00 D8 39 01 9F - From Scantool
C4 F1 10 7F 31 A0 00 D8 22 66 - From ECU
C1 5A F5 B0 FD - From Scantool

We then get an error on the IDS screen saying Error 9 - 0x0851082

I played around with the numbers repeating it back to the ECU, and the "D8" in the ECU response after the scantool message is just repeating the D8 from within the scantool message.

The "22" in the ECU response seems to occur no matter what I send when using mode 31. If I send the frame and manually spam the frame, the 22 turns into 12. But then nothing else happens.

I feel like IDS was suppose to unlock the ECU first, but it doesnt appear to be doing that which is very odd.
When I request the seed from the ECU quickly, I also get a "22" at the end, so this would make me believe it means security timeout.

I then tried a security unlock request, and this to my surprise is a 2byte seed. I have always been use to seeing the 3byte seed/key on Fords.
When we do this:
64,10,F1,27,01

We get back:
C4,F1,10,67,01,00,XX where the XX is a byte that changes each time.

The seed can be requested every 6second.
OR
If you send an attempted key, it seems you can request the next seed straight away... so.. with that logic... we *could* brute force every single combination of seed/key.
Since it appears only 1 byte of the seed is changing, there is 256 possibilities (00 to 0xFF), and the response from the ECU is seems to indicate 2byte response, assuming there is only 1 byte that actually changes, then there would only be around 65,000 is combinations.

Or, alternatively if the Key ends up actually being 2bytes used, we have 256*65,536 = 16,777,216 combinations. Assuming there is no time lockout, we could request frames pretty quick.

Alternatively... I just find another software to try on the ECUs