Data Rate required over bluetooth?

[pyjamasam]

Not an issue per-say, but something I would like to know, and I wasn't sure the best way to contact you :-)

I am curious as to the data rate that you're seeing from the OBDLink MX+. I'd like to see about putting together a BLE CAN bus device using some of the low cost CAN bus chips and BLE chips. I am just concerned about the data rate that needs to be sustained.

I realize that the MX+ is more than likely having filters applied so you aren't streaming the entirety of the CAN bus traffic on it, but are you applying dynamic filters based on the gauges/items on the screen? Or do you have a fixed list that you apply just to limit the traffic to a sane level?

Also I'd be more then happy to help contribute to getting this new hardware bit working with the code base. But thats a conversation for later :-)

I am fine to continue this conversation out in the public through this issue, or if you'd prefer we can continue it in private using what ever method you're comfortable with. Just let me know.

[jake-b]

The MX+ uses an STN1100 which has onboard filtering to reduce the amount of data over the serial connection. I do not specifically know the baud rate of this connection, because those details are hidden to me by the accessory API.

tesLAX will keep track of the gauges you have displayed and request PASS filters for those messages from the OBDLink MX+. In an upcoming version, I am adding log recording, with an option to disable this filtering when logging.

My understanding is that the Tesla CAN Bus is over capacity, and can't really be read at the 500k baud rate of ISO 15765. I can also tell you that you'll get occasional buffer overruns from the MX+ with the default set of gauges, but you'll get constant overruns if you disable the filtering completely. This also means that as the number of gauges goes up on your tesLAX screen (assuming they have different message IDs) you'll see more buffer overruns.

I would speak to @joshwardell who knows more about this than I do. I myself intend to build a canbus simulator for development purposes using similar hardware to what you describe above.

[joshwardell]

As Jake mentioned, unfortunately Tesla absolutely packs its CAN with data, pushing 55-60% utilization at 500Mbps, and that is multiplied many more times with the ASCI STN1100 protocol, and far beyond the bandwidth to send all the data over BLE. In reality though, it seems the ODB adapter is the limiting factor, as none seem to be powerful enough to handle that amount of data. The OBDLink branded modules seem to do a better job than the inexpensive adapters, but the still not only drop but also corrupt messages. I've seen plenty of it in the past with ScanMyTesla as well. They were designed to transmit the much slower OBDII data in an ICE car. Both phone apps configure the OBDLink to filter down the data to just the gauges shown on screen to make the most of it. When logging with scanmytesla, if you enable ALL data, you will not only see tons of dropouts and corrupt messages, but only of the fraction of the messages to make it through. I use real can hardware to capture my logs.

[pyjamasam]

Was the Mbps a typo? I am seeing ISO 15765-4 maxing out at 500 kbps. I am going to pick up some MCP2551 canbus boards and some BLE 5.0 boards and see what I can piece together.

I am also tempted to throw an arm in the middle and come up with some kinda filtering/compression.

The MCP2551 apparently can deal with 1Mbps. BLE 5 with the 1Mbps PHY should hit about 500ish Kbps, and with a 2Mpbs PHY it should be able to around 900 Kbps.

With a binary protocol and even compression layered on top of that it seems like streaming all the frames should be doable.

[joshwardell]

Yes, of course, it is 500k. But that is raw hex data. I think the ODB dongle protocol is formatted ascii, so data is several times more bulky.

If you want to move data across more efficiently it would be much simpler to just make your own interface as I am doing.

[pyjamasam]

This whole conversation is really old now. CANServer deals with all this very elegantly! Closing this issue as its no longer needed to be open.