RW 2.X CANCorder

Combine together a CAN bus and a datalogger and we obtain the CANCorder.


The CANCorder is a device on RW-2x that uses a Beaglebone Black by TI as the groundwork to create a device that not only records all the data on the CAN bus but to also provide a quick and easy way to access the current data on the CAN bus and the past data recorded.

Equipped with a custom built cape created by team member Jenn Holt and a USB WiFi dongle, the Beaglebone Black transformed into the CANCorder and provided us with the basic features to start off the project: a way to access CAN data.


With the hardware settled, the only thing left to focus on was software. The Beaglebone Black comes with Angstrom installed but we decided to install Ubuntu on a SD card and run the Beaglebone Black off of that operating system instead. By running the entire system from the SD card, backups became much easier since only an image of the SD card had to be made instead of backing up and flashing eMMC memory.

Originally the plan was to use Java for the software but this quickly became troublesome. Some of the early issues included trying to get a properly working JRE on an ARM processor, compiling the code into a single executable JAR, and trying to configure a script to run the JAR automatically on startup. Once all these issues had been resolved and the code reached its starting test phase, the largest issue of all arose: a Java function call that took upwards of two seconds to complete. What was causing the call seemed to be deep within a library ported to Java from C that made reading off the CAN bus possible in Java. Overall, the performance Java did not live up to expectations and was not fast enough for our application. Eventually after being unable to determine a solution to speed up the software, it was decided to give up Java for something more low level. C was determined to be the solution to slow data logging which was the largest issue we were dealing with at the time. Using SocketCAN drivers as a framework, the rest of the software was created using C in a similar structure to that of Java. However, the data structures had to be modified since C is not an object orientated language. The change in programming languages however paid off since there was over a 200% performance increase over the Java software originally designed.

An early goal for data logging was to use a database file to cross check the various CAN messages that the CANCorder intercepted. To do this, the software parses a specially formatted file that holds all the CAN messages we are interested in data logging along with the information needed to decode each message. The data parsed by the software then had to be stored in a way that allowed quick searching later on. An AVL tree was chosen since it self balances itself as nodes are inserted and allows for quick searching. Since adding nodes would occur only once during execution and nodes would never be removed, the inefficiency with these two operations was not a concern.

Once the tree's holding the information on how to translate the incoming CAN messages have been created by parsing through our database file, it's time to start reading in messages and data logging. Using the open source SocketCAN functions and drivers, CAN messages queue up and wait for the program to fetch each one and process it. Once a CAN message is removed and ready for processing, it enters into the function responsible for decoding the incoming bits to decimal values.

Since a single CAN message often holds multiple signals, the software needed to translate each signal by masking out all the bits except those that correspond to the signal currently being evaluated. After the software performs various other bit operations such as shifts, the data can then be read as an integer, float, or double depending on which type the signal is supposed to be. All the information on how to decode the signals is found in the signal AVL tree. The translated signal is then stored in the signal AVL tree as well.

In a separate thread, the actual data logging occurs. The data logging is critical and therefore must always be in a running state regardless of whether there is CAN messages being translated. The software design flow was chosen to allow each thread access to the latest information translated from the CAN bus. Since all the values are stored in the signal AVL tree, the data logging function has to only read the values from each node in the tree, concatenation the data into CSV format, and then write the data to the output file. Care was taken in the code to prevent two different threads from reading and writing to the same data at the same time. Since we need these actions to repeat over the entire race duration, the software continues an endless loop of translating and data logging until the device eventually is turned off. It also sends out it's own heartbeat message so that other nodes can recognize that the CANCorder is still active data logging the CAN bus.

Although the software seemed to run fine in a virtual simulation of the CANCorder, a significant issue presented itself when the code was ran on the CANCorder itself. During high bus loads, the SocketCAN library would get stuck in a loop which eventually caused the system to hang followed by a system crash. After finally discovering the source of the issue was SocketCAN, a quick reply by the creators of SocketCAN returned us back on track with a solution. The Ubuntu kernel we were using had an outdated version of the SocketCAN drivers. By applying a few patches which were quickly pointed out by our helped SocketCAN friends, the crashes and hangs were gone and we had a fully functional data logger.

Additional Features

While having logs of all the onboard sensors during the race is extremely important and nice to have, the team decided this wasn't enough for the CANCorder. Due to the CANCorder basically being a Beaglebone Black which in itself is a very small computer, there was a lot more functionality that could be obtained from the device.

For example the CANCorder was bound to be mounted deep within the motorcycle and the ability to access logs easily and quickly was a major requirement for the project. Therefore, the CANCorder was setup with a small USB WiFi dongle with the RTL8192cu Chipset. After resolving other various WiFi driver issues, the CANCorder had the ability to be accessed wirelessly.

Although the CANCorder met all basic functionality requirements at this point, there was one last feature implemented. Instead of having to wirelessly download the logs to view the data on the CAN bus, it was decided that being able to view the data currently on the CAN bus would be particularly useful while working on the motorcycle in the paddock and during last minute system checks before the race. Therefore, a web server was set up on the CANCorder along with a website with the current CAN bus information. By connecting wirelessly to the CANCorder and browsing the hosted web page, everything on the CAN bus can be viewed as the CANCorder translates and data logs it.

What's great about the CANCorder is that it's completely extendable. For our next bike, the base software and hardware setup has already been created so more focus can be placed on extra features to be integrated into the package. The ideas are already there, it's just a matter of time.