The curiosity and demand for RaceCapture/Pro CAN bus integration is quite high based on all of the feedback and activity we’ve been seeing. Our friend Zandr showed us this One Cool Hack in Lua scripting that was especially clever: a clean way to map CAN bus IDs to function calls that extract and map telemetry data.

Spurred on by his creativity, I took it a step further and created a basic framework that you can use to map CAN bus data to RaceCapture/Pro virtual channels in a rather clean way. Dying to see it now? Check it out in our wiki and scroll to the bottom of the page.

This approach assumes the common CAN bus mapping format of (offset, length, multipler, adder) to extract a fully scaled value from an 8 byte CAN bus message.

Basically turning something like this:

CAN ID 1234: [xx] [03] [E8] [xx] [xx] [xx] [xx] [xx]

into 1000 RPM.

Overall, the framework provides a straightforward way to adapt virtually any ECU or CAN system. Thanks Zandr!

Another fun part of this experiment was linking two RaceCapture/Pro system together via the CAN bus port, using a short 6″ RJ45 ethernet cable. One was simulating an external system (say an ECU) by using a simple Lua script to push CAN bus data to the other RaceCapture/Pro.

two_RCPs — Ever wanted to play with TWO RCPs at the same time??

One thing leads to another

The CAN mapping framework was destined for our high level CAN bus info page for RaceCapture/Pro, but then after inspiration and fervent typing it turned into a full integration guide for how to map a new CAN bus system to RaceCapture/Pro. Check out the Integration Guide in our wiki

The guide includes some rather universal tips on how to do CAN bus reverse engineering. We do love systems that are boringly well documented, but the fun challenge is proper reverse engineering undocumented systems – people love mysteries and challenges. Fortunately for you, CAN is pretty easy to reverse engineer if you follow a few basic steps.