DIY CAN bus reader for RaceChrono
 

Hey folks,
Recently I've been working on a DIY data logging device for my BRZ.

I'm happy to report that I've just uploaded all the code, as well as a decent amount of documentation, to GitHub!
The whole build cost me ~$50, compared to hundreds of dollars I'd pay for a comparable off-the-shelf device.

Check this out:
https://github.com/timurrrr/RaceChronoDiyBleDevice Overview of the project
https://github.com/timurrrr/RaceChro...can_db/ft86.md Everything I've learned about the CAN bus for FT86 platform

If you know anything useful for track enthusiasts about the FT86 CAN protocol that's not reflected on the second page, I'd be happy to add it!

Here's an example of data captured by that device at T6 at Laguna Seca during a recent 86DC event:
https://i.imgur.com/IPBZ5cI.png

And here it is used for virtual gauges in RaceChrono: https://www.youtube.com/watch?v=Ct4L6gD2d5A
As you can see, it has a much higher update rate (25 Hz) than is typical for OBD-II Bluetooth adapters.
Most importantly for me, it allows me to log the brake pressure!

Anyone with basic soldering skills should be able to create a similar device for themselves.
If you don't know how to solder, etc., I'm sure you can find a friend who will be happy to help, and you'll both learn something along the way.

I need to warn you that you assume any and all risk from connecting a DIY device to the CAN bus of your car.
If you mess up something badly, it can cause costly repairs and/or injuries.
Don't mess up badly :bonk:

Fantastic!

Its absoutely better than any other expensive data loggers on the market. I'll try to follow your instruction.

:thumbup:

Looks like this could be a fun quarantine side project to tinker on. I haven't used racechrono before, so just want to confirm a few things.

In addition to your github build sheet, I would also need:

- some type of android device
- racechrono pro app.


Is the data stored in racechrono? can it be exported?

Will an old android device become bottleneck and/or what features should I look for in the device?

Yes, the data is stored in the RaceChrono app on the phone. There are a bunch of export formats available in RaceChrono, including CSV and RaceRender/DashWare.

Any reasonably old Android phone with Bluetooth Low Energy support should suffice. You may want a larger screen and USB-C fast charging if you want to clearly see the phone screen while driving.

If you have an Android Auto head unit and want to project the app on the head unit you'll need the phone to be rooted, and not all phones are easy to root. Some say Motorola E5 is a good cheap rootable phone for this purpose. Or you can buy a used/refurbished Google Pixel.

Squiggly lines alert! :popcorn:

I did some minor refinements and updates to both the hardware and the software (everything updated on GitHub), and went to a local AutoX.

There was an interesting wide-tight-wide left corner that I wanted to review.
One of the features was the bumpiness of the surface around that corner.
I'm blown away how much resolution there is in the data captured with this cheap DIY device!

Speed vs inputs
https://i.imgur.com/uShAQqU.png

Speed: cyan (50 Hz update rate)
Accelerator: green (25 Hz)
Steering: purple (25 Hz)
Brake: orange (50 Hz)

Individual wheel speeds
https://i.imgur.com/ku1aSie.png

Front left: cyan blue (25 Hz)
Front right: purple (25 Hz)
Rear left: green (25 Hz)
Rear right: orange (25 Hz)

You can see in the first phase of the corner the unladen left wheels briefly locked up when I went over bumps.
Then after the apex you can see that the inner rear wheel started turning at the same rate as the outside wheels (but not the inner front wheel!), occasionally slipping when going over bumps.

I'm curious what happened at the ~2s mark with the brake pressure.
I don't remember releasing the brake pedal that much.
I wonder if it was the ABS intervening after I went over bumps.
Need more tests to say for sure!

Nice work!
I really like the RaceChrono app and this definitely takes it to the next level.

Here's a couple more examples of what kind of data you can get with this device:

1) Individual wheel speeds

Here's a launch in the beginning of a run, followed by a couple of corners at a recent autoX:

https://i.imgur.com/OufXIBP.png
Front left: cyan blue (25 Hz)
Front right: purple (25 Hz)
Rear left: green (25 Hz)
Rear right: orange (25 Hz)

You can see in the beginning the rear wheels spinning at roughly constant rate, whereas the front wheels speed up with the "real" speed of the car. If you look closely, you can see the slope of the graph for the front wheels increases slightly as the car's own speed approaches the speed at which the rear wheels are spinning (or, in other words, as the rear wheels spin less relative to the speed of the car they generate slightly more traction).

At t = 2025 you can see the rear left wheel starting to slip in a left corner until the LSD engages.
At t = 2026 ... 2030 you can see how a slalom looks like.
At t = 2033 you can see the fronts locking up as I brake on a bumpy patch of the track.

2) Combined acceleration vs pedals

https://i.imgur.com/x6ZzLrc.png
Accelerator: green (25 Hz)
Brake: orange (50 Hz)
Combined acceleration, from the CAN bus: purple (25 Hz)
Combined acceleration, from GPS: cyan (10 Hz)

I was looking at how well (or not well) I trail brake on a ~55 mph straight into a ~25 mph hairpin.

As you can see, the accelerometer data on the CAN bus is pretty noisy.
This is typical for digital accelerometers, and usually some filtering is needed.
Also you can see the GPS data is slightly offset/delayed.
Both of these issues are fixable, see this discussion on the RaceChrono forum.

Even without filtering IMO the data from the CAN bus is more useful than the 10 Hz data from the GPS.
For example, right before braking I know I was going in a straight line at the rev limiter, so should be ~0 G's.
Indeed, I see a brief drop to 0 in the data from the CAN bus. For comparison, the minimal value in the GPS data here is 0.5 G's!
The CAN-based "combined acceleration" graph jumps up quickly as I step on the brake pedal;
whereas the graph based on the GPS data takes ~0.5 sec to get from the minimal value to the first local maximum.

Great news! Starting v7.1, RaceChrono allows adjusting the timing data from CAN and OBD devices relative to the GPS data, and even can do that automatically.

As an example, here's T6 at Laguna Seca:

https://youtu.be/j01LALSN7dQ?t=68

Here's the data log from that lap, after aligning GPS and CAN data:

https://i.imgur.com/ZFq1I6H.png

Purple line: GPS speed
Cyan line: Speed as reported on the CAN bus (from rear wheels)
Green line: Accelerator
Orange line: Brake pedal

Now that GPS and CAN data is aligned in time, you can see that the tire "slip" between 3s and 5.5s.
It's very clear that the GPS data is wrong when going under a bridge.

Here's another great example of what kind of data can be acquired from the CAN bus.


This is me losing the car a little bit after crossing a wet patch in an otherwise dry corner:

https://youtu.be/SOq_YOf_Nr4

Data:

https://i.imgur.com/lDi1VJq.png

Green line: Accelerator
Cyan line: Steering wheel angle
Purple line: Combined acceleration (from the CAN bus, unfiltered)
Orange line: Yaw speed a.k.a. rate of vertical rotation (degrees per second)

As you can see from the data, around 1229.5s I hit the wet patch and the car briefly lost ~50% of its grip. I then pressed the throttle too much and, despite counter-steering, the car started to enter a spin. I then counter-steered way too much, and lifted the throttle — which of course made the car snap to the outside. Luckily, I was able to quickly correct my mistake and tuck the car back in the correct direction, avoiding the walls.

Now I need to change my pants and go find a skidpad :D

Attempts to get Arduino Program Compiled is failing
 

Hey timurrrr,

I just want to say that this project you've created is awesome and I really want to try to make this device for my BRZ. Before I buy the parts, I wanted to make sure I could get your program to compile on my Arduino UNO as a test, but ran into a snag with a library inclusion.


I've done a bit of Arduino stuff in the past but not a whole lot so this may be a noob question and solution.



So, I downloaded the two libraries you created which are needed for the RaceChronoDiyBleDevice software to run. When I try to test compile RaceChronoDiyBleDevice.ino, Arduino IDE complains that there is no library for algorithm that is defined within the RaceChronoPidMap header file.

Arduino: 1.8.19 (Linux), Board: "Arduino Uno"
In file included from /home/bfitzy/Arduino/libraries/RaceChrono/src/RaceChrono.h:4:0,
from /home/bfitzy/Arduino/RaceChronoDiyBleDevice/RaceChronoDiyBleDevice.ino:4:
/home/bfitzy/Arduino/libraries/RaceChrono/src/RaceChronoPidMap.h:4:10: fatal error: algorithm: No such file or directory
#include <algorithm>
^~~~~~~~~~~
compilation terminated.
exit status 1
Error compiling for board Arduino Uno.

Any ideas what I'm missing here? Orignally I thought maybe I needed to update g++ but seems like I'm running the newest compiler. I'm running Debian based PopOS btw.



Thanks in advance!
Brad

You won't be able to compile this project for an UNO, as that is a very basic board that doesn't have all the necessary hardware (e.g. BLE).
Apparently, they didn't even bother providing the standard C++ <algorithm> header that has a lot of helpful utils :)

I suggest you get an nRF-based board to play with, they aren't that expensive.

Forgot to post that this project has been updated to work on 2022+ GR86/BRZ.
The primary focus now is 2022+ cars, but it should still work fine on gen1 cars.
You just need to tweak one of the files to specify which car you have.
If you forget to do that, the code will fail to compile, and the error will nudge you in the right direction.

Demo from a track day in my 2022 GR86:

https://www.youtube.com/watch?v=R1ucTVodH9Q

I have a OBDlink MX+ that I use with Racechrono and I basically can log everything I want except brake % or brake pressure. I'm a bit lazy so I'd rather not build this reader just to get that one variable. Would you happen to know if I can access that via OBD?
@timurrrr I see in another thread that you found it for the first gens. Any idea if we have it for the second gen cars?

I suggest you don't use the OBD-II protocol, as it's very slow.
Use the CAN protocol instead.

RaceChrono supports reading CAN data via OBD-II port on gen1 cars,
you just need to add it as a CAN reader instead of an OBD reader in RaceChrono settings.
Here is the data mapping:
https://github.com/timurrrr/RaceChro...mended-can-ids

gen2 cars have no CAN data on the OBD-II port, or at least not without some currently unknown tricks.
Since I already had a DIY device, I just use it instead of trying to figure out half-measures such as OBD-II PID for the brake pedal.

Do you have any plans to make and sell these? I’d be more than happy to buy one off of you instead of making one myself and failing haha.

Realistically, not anytime soon.
I already don't have enough time (or energy!) to do everything I want to do on weekends.
On weekdays I have a paid job.

The only way I could possibly justify working on something like this for money
is if it could offset taking a day or two of unpaid leave.
Given the low volume, the resultant price tag for a product I'd consider
high enough quality to charge money for would be way too high.
(That being said, if anyone has a business proposal, DM me)

The goal these GitHub projects is to provide a foundations for others to use for their own tinkering.
If you can't make a DIY data reader yourself, you might know a friend who already has
some Arduino / electronics experience to help you.

Hey timurrrr,

After some time tinkering around I finally built this device and got it working via the OBD2 pins 6 and 14. It's freaking awesome! Since I've got it paired with RaceChrono, the device has been working well. I'm now in the process of creating a harness to connect to the CAN Bus access point behind the infotainment.

I have a couple questions though now that I've gotten this far.

1) I saw that you posted a TODO to get fuel remaining working on your GitHub readme. Doing some digging, I saw that you also posted in a RaceChrono forum showing the fuel remaining PID and equation. I can't seem to get this to work. I know the PID is 0x2129 or 8489 base ten as shown in RaceChrono. The equation I'm using is the same as you mentioned "A * 0.5". Any ideas? I can see that 0x2129 shows up in the received PIDs when looking at the serial monitor with a laptop connected, but no dice with RaceChrono. No data seems to be received for it. Every other data field seems to be working.

2) Is it required to use a 16MHz chip or will the 8MHz chip work fine? I understand that the clock will run half as slow and there's no reason not to run a 16MHz chip. I'm just frankly horrible at soldering and kept mucking up MCP2515 boards lol.

Thanks again!
Brad

Posts like this make my heart feel warm! Thank you for sharing.

0x2129 is an OBD-II PID, not a CAN ID.
RaceChrono adds to this confusion by (incorrectly?) referring to CAN IDs as "PID" in the equation editor UI.

I have a local branch with changes that allow sending OBD-II requests from the board. I need to clean it up a bit before I can push it to GitHub. IIRC you're one of the first one (if not the first) to ask for OBD requests :)

That is a benefit of this DIY project over off-the-shelf solutions such as OBDLink MX+ which only supports operating in one mode (OBD-II or CAN) at a time.

Try it with 8 MHz and let me know how it goes! :popcorn:
You'll need to update the QUARTZ_CLOCK_FREQUENCY constant in the code.

I switched to 16 MHz quartz early on because I had some connection reliability issues. It later turned out that those were caused by using unregulated USB power on Vin of the MCP, so it is very much possible that 8 MHz quartz is sufficient.
This will save some cost, and definitely simplify the project for future DIYers!

I just completed building the final product nicely hidden away behind the passenger side glove box area. I have the breadboard double sided taped down and seems like it will hold well. I do not have access to a 3D printer, but making a nice enclosure would be the final step. I can not wait for my next local track event to test this out for real!

I'll be following the GitHub for future updates because fuel remaining would be an awesome data point to have! The use case is endurance racing. I personally would not get much use out of it but a friend of mine races his fleet of 86 race cars in lucky dog events. Having this information available would be much easier to gauge when a splash is needed.

Lastly, turns out 8MHz quartz is sufficient and works just as well as the 16MHz example.


Cheers,
Brad

This product + OBDLink MX+ might solve most of your needs.
I haven't personally tested it, but an approach like this should work.

Hey !

Thanks for this nice DIY project.

I have some experience in basic electronics, and I work in IT so I have some programming experience too, so that could be useful.

I will very likely give a shot to your tutorial for the DIY reader on the connector behind the head unit.

One of my main interest, in addition to the fun of having a nice DIY project like that, is to try to implement a Door Autolock functionality, which we know is already doable due to projects like the Trac-box, or some ODB devices that require to connect on the OBD port.

I don't want to pay $200+ for the Door Autolock functionality, and I my OBD port is already taken by my OBDLink MX+, so I will try to find a way to achieve a similar result using the connector behind the head unit.

What a great find this thread is. anyway

Ive been kicking around the idea of having physical gauges on my sim racing rig and there are some examples online and videos on youtube. Ive placed an order for some Arduino's and MCP2515 boards. Figuring i would have to sniff the bus on my 86 for a bit to find out how to control the gauge cluster outside of the car.

I don't have a lot to contribute at this point, but would like to.



here are some of the video's Ive been using to get started with CanBus comms, He goes way out of scope but its nice to see that data that can be pulled.

https://youtu.be/cAAzXM5vsi0 Part 1
https://youtu.be/ZhYc95b6WoU Part 2
https://youtu.be/ifjCRsCPfa4 Part 3


I hope to have some data for you in the future.

@timurrrr
How does the OBDLink MX+ get configured to run in OBD2 mode vs running in CAN mode?

I just got one and plan on having the following

1. OBD2 splitter
2. OBD2 gauge on one end (oil temp, coolant temp, rpm, speed)
3. ODBLink MX+ on the other
4. RaceChrono linked up to the OBDLink MX+ but only through CAN (oil temp, coolant temp, speed, rpm, throttle position, brake position)

If I configure RaceChrono only with the CAN ID's you mentioned on GitHub is that considered putting the OBDLink MX+ in CAN mode? I looked through the OBDLink MX+'s documentation but couldn't find any mention of "modes" anywhere.

BTW thanks for the work on this project. I'm going to take a crack at building one for a friend's Gen 2 after I get my own situation sorted.

In RaceChrono "Settings", you add your OBDLink MX+ either in the "OBD-II readers" section, or in the "Other devices" section with the "OBDLink LX/MX/MX+ Bluetooth (CAN-bus)" type.

Thank you, I saw that in the settings but since it didn't explicitly say "mode" I wanted to double check that there wasn't something I had to do with the OBDLink MX+ itself.

I have a 22 BRZ and picked up an ANSIX Auto Can Adaptor as a solution to the Gen 2 OBD port. Which OBD tool would be required to run Race Chrono?

https://ansixauto.com/2022-brz-gt86-can-adapter/