My first build: CAN-Bus and GPS through Bluetooth LE

aol

I've just released my first build in open source. It's reference device to showcase the new Bluetooth LE "do it yourself" APIs for GPS and CAN-Bus data in RaceChrono Pro v6.0 (beta). Let me know what you think.

https://github.com/aollin/racechrono-ble-diy-device/

hexen

I will follow this post, it's interesing for programmable ECU

TriB

Great work and good documentation! Thumbs up :)

CedTurbo

Hello, I have a DTA ECU with CAN-bus, I try to understand your code => you make the choice of the IDs readed directly in the app ? I would like to build it this winter. Thanks

aol

I'm not sure if I understand the question. The app writes to the UUID 2 to create a filter. This selects which packet IDs are read and which are just dropped.

CedTurbo

Ok, I understand now. In the app, we see the CAN-IDs available and the filters are sent through the BLE. Am I right ? Your code is very nice but complicated for me. I read some documentations on the BLE Characteristics but I have also to understand the CAN Bus documentation. Somes years ago, I read the Serial Stream on a old ECU with an Arduino, it was easier. :) Thanks for your explanations, I will order the parts and try it.

CedTurbo

Hello, I received my parts and I look at more your code. The Arduino IDE doesn't want to compile because the Adafruit's library has been modify. I made two corrections but I can't test it for the moment. 1°: void canBusFilterWriteCallback(BLECharacteristic& chr, uint8_t* data, uint16_t len, uint16_t offset) { to void canBusFilterWriteCallback(uint16_t offset,BLECharacteristic* chr, uint8_t* data, uint16_t len ) {

2°: void bluetoothStart() { Bluefruit.configPrphBandwidth(BANDWIDTH_MAX); Bluefruit.begin(); uint8_t mac[6] = { 0, 0, 0, 0, 0, 0 }; Bluefruit.Gap.getAddr(mac); to void bluetoothStart() { Bluefruit.configPrphBandwidth(BANDWIDTH_MAX); Bluefruit.begin(); uint8_t mac[6] = { 0, 0, 0, 0, 0, 0 }; Bluefruit.getAddr(mac);

It compile now, I don't use the GPS'code. If you can look at and say me if I am in the good way.

Best Regards

aol

Probably just different version of the Adafruit libraries. I believe your change mirrors the functionality exactly. I will revisit the project at some point.

CedTurbo

I will try on my car ASAP and keep you informed.

GiuseppeBinomi

Hi everyone!

I would like to briefly introduce my project to you. I have an old Kawasaki ZX6R (2002, carburetor) which has neither OBD-II nor CAN-Bus. Instead I collect my data using some sensors and an Arduino with Bluetooth LE. I have a 9-DOF IMU to read accelerations and calculate lean angle. By counting pulses (frequency measurement) I get the pretended speedometer value and RPM and calculate the gear form that. There´s an external GPS board connected to the Arduino, so I know the real speed and can send a corrected pulse signal to the speedometer. The throttle grip position can be determined by measuring the voltage of throttle valve sensor and so on... quite a bit of stuff already.

Thanks to the documentation on GitHub from the first post, I was able to get all the Bluetooth LE stuff to work already! (I haven't tested GPS yet).

So far I have 3 questions/remarks:

OBD-II channels vs. CAN-Bus channels I see in OBD-II channels I can define a postfix, so for example I can separate suspension travel front and rear. Is that option missing for CAN-Bus channels? I couldn´t figure out how this can be done.
Combined acceleration I know the combined acceleration is usually calculated by RaceChrono from the GPS data. As I can directly measure all accelerations very fast and reliable, I want to use it rather than GPS data. I can send longitudinal and lateral acceleration in separate channels, but how to combine them? There is an entry "combined acceleration" in the list of channels that can be created, but how is it meant to use?
Bluetooth LE payload To increase the data throughput, I packed several data values under the same PID. For example Gear and RPM can be packed in only 2 bytes (3 bit for Gear, 13 bit for RPM/2). Throttle and Brake position need only one byte each and so on. You can put a lot of different data into a single 8-byte parameter. This way I achieve much higher update rate because I don´t have to send the BLE characteristic everytime for each single value. Actually a BLE characteristic can transfer 20 byte, 4 bytes are used for the PID, so 16 bytes of payload would be possible. Unfortunately only 8 bytes can be accessed in the channel. Is it worth considering increasing the bytes per chanel?

Thanks for your great work and documentation!

Best regards

aol

Hi @GiuseppeBinomi

Sounds like a great project! I've been thinking adding a dedicated IMU input API, but it will work through CAN-Bus API too :)

I will check that there's no bug related to this. It should work just same as OBD-II...
Combined acceleration is basically sqrt(pow(lateralAcc) + pow(longitudinalAcc)). You can easily add that channel, if you have both accelerations available.
Yep, I don't see a reason why it could not be variable packet length. I will experiment with it, and if it works will roll out to next major version.

GiuseppeBinomi

Thanks for your fast reply!

Ah now I see the combined acc channel is a scalar value. I misunderstood that. I thought about the video overlay for combined acceleration which is a 2-D chart. I can show longitudinal acc and lateral acc channel in two charts, then the red dot is bouncing up and down in one chart and bouncing side to side in the other chart.

When I add the combined acc channel from GPS to the overlay this is obviously a 2-D value.

So my problem is, I have 2 scalar values (longitudinal and lateral acc) from CAN-Bus channels and I want them to show up combined in the 2-D chart. I can calculate the vector length like you suggested, but then it is still a scalar (1-D value) value, not showing the direction of the force.

Best regards

aol

Looks like a bug, a wrong field is showing up when you press "show more"
That gauge uses three different channels. The number is "combined" and y-axis is "longitudinal" and x-axis is "lateral". What you need to do is to calculate lateral and longitudinal accelerations from your 3D IMU. For a car it would be easy, just point your sensor so that one axis is aligned to lateral and one is longitudinal. For a motorbike longitudinal would work same way, but to get lateral acceleration, you need to rotate the 3D matrix according to the lean angle...

PS. Both 1. and 3. will be addressed in the next release, minor or major which ever comes first.

GiuseppeBinomi

I agree, I have to care about correct calculation for my accerleration values. In theory I should know how to do the mathematical part, it will be more difficult to verify the results in praxis. For now, I will just simulate reasonable values for testing.

I created 3 CAN-Bus channels, lateral acc, longitudinal acc and combined acc. I add a new analog gauge to the video overlay, device is CAN-Bus and channel is combined accerleration. What I get is an empty gauge (no red dot) with just the number G (combined). Additionally I can add a gauge for lateral and longitudinal acceleration. So I have 3 gauges confirming that I send 3 reasonalbe values but I can´t get them all into a single gauge.

When the device is changed to GPS and channel is combined acceleration, I get the numger G and the red dot moving around x and y axis according to the accelerations calculated form the GPS. This is what I want to achieve but with my CAN-Bus values, not from GPS.

I think the combined acceleration gauge has no idea where to get the x and y data from when the device is different from GPS.

aol

@GiuseppeBinomi don't worry about the overlay. The editor is too restrictive, and the gauges them selves have too much hardcoded stuff. I'm rewriting all this for the spring release, allowing much more flexibility and configurability.

J_D_W

@GiuseppeBinomi your project sounds similar to my first RC project in 2016. I put my first data logger to RC using BT and RC3 strings on my 2000 ZX-6R. Read speed and RPM from the raw signals. Moved up to a 2009 ZX-6R for the track now but still no bike provided channels to read

@GiuseppeBinomi / @aol What kind of update rate can you do with the BLE solution (Android)? I am still using RC3 over RFCOMM with my solution but I am starting to figure out what I want to change data logger wise for next season. Trying to figure out if I want to do my 100Hz logging to SD Card still and just pass minimum data to RC. Or can I use RC as the main logging and pass all the data to it?

Thanks, Jeff

aol

@J_D_W about 20 CAN-Bus (or "CAN-Bus") messages per second with a device built according to my DIY instructions. Each CAN-Bus message can hold several channels.

I'm thinking about a RC4 protocol that would be RFCOMM (or TCP/IP) and ASCII just like RC3, but interpreted from hexadecimal values same way as the CAN-Bus messages - with an equation and channel settings. This way you could transmit anything and translate the data in RaceChrono just like you wish...

J_D_W

@aol thanks for the information. I also took some time last year to implement the RaceTech binary format you added but never got it working well enough to use. Some of my encodings were definitely off, part of my thinking at the moment is if I debug that. I didn't even get to sending it to RC, I just logged it to my SD card and tried to load with Race Tech and had some issues.

My current thinking is to continue with my path from last season. Log enough for timing and at track analysis over RC3 which already includes what I need at 10-20hz. And log high bandwidth (brake sensor, suspension movement) directly to SD Card in CSV or Circuit Tools format for later looking at if I see something I want to zoom into (ie chatter or specific issue in a corner). Thinking about possibilities of playing with GPS RTK modules to see if I can get GPS tracking into the sub-meter range.

Thanks for all the hard work you put into the app! Jeff

aol

@J_D_W Sorry for not following up with the Race Tech format better. I got maybe carried away with the possibilities of it, but later I learned that the format specification is just too ambiguous. The main issue with their format is, that the order of the packets is not clearly defined. So you will have to make big assumptions and some (or most) of them will be wrong, in terms of compatibility with Race Tech's own products.

Now my DIY roadmap is to add more Bluetooth LE APIs, and maybe introduce the new RC4 format.

J_D_W

@aol after digging into the Race Tech stuff myself I agree with your plan to move forward. Your new direction is better documented and fully in your control, I would do the same. There format is documented but how they use it is not. So no need to say sorry. I'm kinda glad you say the above as it makes me feel better about not getting it to work and won't feel so bad when I remove it from my code :)

Jeff