pcmhacking.net

After some delay, here is the k-line log with multiple modules on multiple pins. I quickly look at it and it is really hard to tell anything out of it.

Tested are all modules present on the car, some ar not existent but t2win still tries to make a connection, so important data should be there.

If you need some specific module`s more detailed log, I will do my best to get it.

kur4o wrote:After some delay, here is the k-line log with multiple modules on multiple pins. I quickly look at it and it is really hard to tell anything out of it.

Tested are all modules present on the car, some ar not existent but t2win still tries to make a connection, so important data should be there.

If you need some specific module`s more detailed log, I will do my best to get it.

Thankyou!!! Every last bit of help/logs makes a big difference for development for us.


Iv been a little bit quiet as I have been neck deep in learning and development with BLE.
I learnt that our ESP module we currently use supports BLE4.2, so we should be able to transfer at 240byte blocks... but my android phone only does 20byte blocks which is the default BLE 4.0 size. The max block size is determined by the slave (phone) thus I cannot force it to do bigger blocks.

Now, BLE5 allows large blocks too. By my understanding and the BLE5 standard, its default is 240+ bytes per block. My android phone also supports BLE5, so I am hoping it will just instantly allow larger blocks right off the bat.

I have also been researching how to maximise throughput in BLE, and it appears its all timing based. Even at 20bytes per block, theoretically you can transfer at high rates but your timing between frames (inter frame delay - IFR) must be spot on.
Basically transferring without acknowledgements is what we need to do at the max size (MTU) block size allowed with a very small delay between frames. Since our ESP is designed to be a "passthrough", we would need to change how it deals with data blocks larger then 20bytes from our actual scantool processor so that it can send data at perfect sized blocks with a predefined IFR. With enough work, I do feel like we could make our current ESP get to a reasonable BLE rate, but we are certainly entering a realm that is very much tailored to a speed based applications and not just basic diagnostics.

For me personally, I need something that can transfer larger blocks by BLE for iOS for my own applications, so this does affect me personally for upcoming applications, thus is a priority for myself too.
The latest releases from microchip (RN4678) have both BLE5 and classic bluetooth, they also have the option to install an iOS MFI chipset to allow using classic bluetooth on iOS. I have some of these on the way, and am hoping that the BLE5 will give that extra boost that we are after. Its datasheet indicates we should be able to maintain a through put of up to 6-7kbytes/s which should give us the desired outcome we are after. If not... onto MFi compliance.... see next post...

This then leads to the next side quest... iOS MFI (Made For iPhone). Now, I love apple products minus MACs, but they make it incredibly difficult to make products for them.
To be able to get the little MFI chipset to allow classic bluetooth, we have to send scantool samples to apple so they can test it out. I am not too sure how they plan to test it, I cannot even ask the question unless I sign up for them (Which then also includes the NDA) but basically its pay first and ask questions later situation.

I would assume this should be pretty straight forward for Pete and I, since the RN4678 is specifically designed to accept the MFI chipset through a dedicated i2c connection and all the firmware is predone. Since the product is wireless, we do not need to meet any power consumption based criteria, and would only need to meet the wireless criteria which microchip has already done for us.

The only concern I have is apple actually forces MFI licensees to meet packaging criteria, where every single last supported apple product much be listed along with a variety of other things. You'd think this would be the easiest step, but apparently if your packaging doesn't meet their high standards, they force you to restart the entire testing again from the beginning including testing the hardware and to pay again. Our packaging is just a amazon bag (for safety indications on plastic sleeves as required by Amazon) with an starter guide sheet with the scantool itself, which I worry is not going to be 'classy' enough, as Apple gets you to ship in your packaging specifically to investigate. I did a bit of research over the last couple days, and cannot find a single iOS MFI product using a plastic sleeve, every single last product uses a carton box which I believe is by design due to apples criteria.

For me personally, wasting resources... on a box... is just painful. Thankfully this process is quite easy in the United States with multiple online vendors allowing to design a custom box online. Its a complete waste of time, but, for the sake of meeting the criteria... it will need to be done.

From what I can find online, it appears you can get samples of the mfi chipsets to use while developing, and there is no limitation on how many you can buy, but you would not be allowed to publish an application on the apple store which uses your hardware until the hardware is approved.
This means we could... at least... get some prototype classic bluetooth dongles working so any interested developers can begin adding support while we pushing forward with getting approved.

Pete did mention if going down this road, we could likely just use our current ESP module and have this approved for MFI. My only concern here is trying to implement the iAP2 protocol which is what authorizes/negotiates with iOS devices and allows connection. There is likely some critical broadcast information sent out that allows iOS devices to even display the module for connection. And diving into the ESP's low level bluetooth registers is not for the faint hearted.

Once I am signed up for MFi, I will obviously know more but wont be able to post about any specific details unfortunately.

Hiya,
I am as well upset about anything apple. Fock, look at my sentence structure.
Undecided too. You are much more eloquent than I.

After hitting wall with iOS BLE connectivity, I have moved to trying to connect via WIFI. Although this falls under their local network privacy restrictions which then requires additional entitlements approval (Basically being allowed to open a socket connection which must be manually approved by apple). While waiting for the entitlements approval, my next step forward realistically is attempting the MFi implementation so that I can connect an iphone by classic bluetooth.

Unfortunately I cannot discuss any details of MFI for its development due to NDA, but considering how difficult it has been to open any kind of communication to my iphone, I am sure I will basically have an open ended trouble shoot ticket with apple during this process.

Not only are we now a guru with dealing with BLE... apparently I know how to become one with Wifi to get a socket connection using iOS.

When opening a socket with MAUI, we keep on getting the same No Route to Host error. This typically indicates that you are entering an incorrect IP address, which is true in the sense that the iphone appears to be using the wrong network adapter.

Using a handle little ios app called "Network Tools", we are able to see all the various network details for my iphone.
While connected to the OBDX GT wifi.. we get:

Wifi IP - 192.168.4.2
Cellular - 10.x.x.x (My cell ip)
DNS Servers: 192.168.4.1
Proxy: NA
Default Gateway: 192.168.4.1
External IP: NA

If I click on "routes" tab, we get:
1) Destination: default, Gateway:192.168.4.1 (our esp32)
2) Destination: default, Gateway:10.x.x.x(cellular)
3) Bunch of other random ones

And finally, on interfaces we see:
1) Bunch of random interfaces
2) pdp_ip0 (cellular)
3) en0 (wifi) - destination ipv4: 192.168.4.255, address ipv4: 192.168.4.2, netmask: 255.255.255.0

When using the inbuilt ping option in the app to probe the ESP, it successfully sends and gets a response on 192.168.4.1. Then when opening a TCP socket connection to 192.168.4.1 on port 23, it succeeds instantly.
What I dont understand is how the exact same code works on one iphone, but not on another iphone. Both identical models and firmwares.

I feel like it has something to do with the "default" destinations. I would have thought disabling my cellular should have fixed this.. but in some messed up way.. its still not working.
I am feeling like this might be a MAUI problem... so will likely need to try make a socket using iOS specific code to eliminate that potential.

On the MFi side of things. We have multiple MFi iap2 capable bluetooth devices on the way to trial with. Assuming we find an option we are happy with, then we will continue with the procedure to have an MFi approved tool so that developers can create applications on iOS using classic bluetooth. The positive side here, is developers do not need to join the MFi program, you will be able to just use a template application that we provide that allows communicating to iOS and Android devices.

When you have multiple ip addresses, there is a route table that manage which address -which subnet uses in windows. Something similar should be in Ios. On the non working ipohne it is likely a local network request gets routed to WAN gateway.

On windows you can take a look at how routing is set ->cmd->route PRINT

kur4o wrote:When you have multiple ip addresses, there is a route table that manage which address -which subnet uses in windows. Something similar should be in Ios. On the non working ipohne it is likely a local network request gets routed to WAN gateway.

On windows you can take a look at how routing is set ->cmd->route PRINT

Ill grab a screen shot from my iphone, the "Network Tools" app has a tab which states Routes which I indicated a couple on my previous post.

I started to try implement the socket via iOS but I need to see a working example to be able to try copy it into MAUI's platform specific code.

To ensure some sort of progress is being maintained while exploring multiple other wireless controllers, I have finally gotten a MAUI example template up and running which currently will connect to OBDX tools by classic bluetooth on Android devices.

It will not connect or do anything for iOS at this time until I have a clear working solution for Wifi since BLE is too slow. BLE would be fine for viewing some basic sensor data, but in no way is fast enough for flashing.

The template has both a raw Scantool option to communicate with the tool for reading and writing. Along with a J2534 implementation with follows the J2534 command structure fairly closely, but altered to work with async setup.
This should allow developers to migrate from their dedicated PC j2534 apps to mobile apps without too much hassle.

Will likely open an OBDX github to host the templates since we will have PC and MAUI examples. I just need to finish off putting all the code into a nice library, this will allow developers to update their applications to use the latest OBDX plugin without completely breaking their code.

Hi all,

So, does this mean you are planning an Android Diagnostic App?

Mike