RaceChronoDiyBleDevice

RaceChronoDiyBleDevice copied to clipboard

https://github.com/timurrrr/RaceChronoDiyBleDevice/blob/93c31e1ae916a2890c355cbe482acd9c0ce50642/configs/ft86_gen2.h#L22

Are there any constraints besides file size which are causing you to restrict read rate? I am interested in capturing 100Hz+ signals at their native speed.

Bluetooth Low Energy (BLE) has limited maximum bandwidth. If you try to send more than BLE allows, some information will be dropped, one way or another. By dividing the rate programmatically, you get more control over how it gets dropped.

Part of the inefficiency of the current implementation is that for messages we try to communicate via BLE, we send send all the bytes of the message -- even if only 1 bit is actually needed by RaceChrono. Furthermore, sending each BLE packet requires a non-trivial amount of overhead due to packet header (length, checksums, etc.).

It should be possible to improve the effective data rate by squeezing the same amount of useful information into fewer bytes and/or fewer packets. For example,

1. truncating the bytes after the "useful" bytes in each CAN message (allows retaining all CAN IDs and equations in RaceChrono)
2. dropping all non-important bits from each CAN message, and only sending the important ones (will require changing some of the equations in RaceChrono, might be worth reporting them under different CAN IDs to avoid confusion)
3. re-packaging data from multiple CAN messages into one extra-efficient "mega message"

1 or 2 should be easy to do.

GR86 unfortunately requires 3 high-speed channels (3 bytes from 64, 2 bytes from 312, 3 bytes from 313), and 312 is only used for the steering angle – isn't very efficient. It should be possible to re-package the data (see (3) above) into 2 or even 1 packet sent at a higher rate.

Another possibility is to change the transport from BLE to Wi-Fi altogether, but that would require changes in RaceChrono DIY protocol.

That being said, if you just want to monitor the CAN bus with an Arduino (i.e. no RaceChrono) and/or your laptop, the arduino-CAN library should be able to handle most/all CAN messages.