Telemetry Bridge

Telemetry Bridge


A pretty typical approach to solar car telemetry is a wireless Controller Area Network bridge bridge. A CAN bridge simply listens for every message on a CAN bus and ships it off wirelessly to a support vehicle.

WiFi is a common and convenient radio to use for such a task, but for ease of development I decided to give a pair of nRF24L01+ radios a try. The nRF24L01+ is nice because it is dirt cheap, low power, has a SPI interface and is reasonably high bandwidth for how simple it is. This radio provides a packet interface, making it ideal for bridging CAN packets over.



This is pretty striaght forward. I wired it right up to an Arduino UNO's SPI port. The nRF24L01+ is a 3.3v part, but its pins are 5V tolerant. It even works off the built in 3.3V rail on an Arduino. I eventually chose to use a discrete 3.3V regulator because I wanted to also use the higher power version NRF24L01 + PA + LNA.

The Arduino in the solar car had a CAN shield for interfacing to the car. The arduino in the support vehicle just dumped received packets out of its built in serial port at 2Mbps.


The nRF24L01+ has many modes of operation that makes it very flexible but also a pain to figure out how to maximize bandwidth. I wanted > 250Kbaud full duplex communication, but that was nearly impossible until I discovered the ACK+payload operating mode. In this mode, one radio exculsively sends new payloads, while the other radio sends ACK packets which include a packet of data. The ACK is also nice because the radios can be configured to automatically retransmit packets until they are confirmed to be delivered. Using this mode, I was able to get over 350Kbaud of useful data through. I chose the solar car's radio to be the master, and the support vehicle's radio to be the ACK'er.

Instead of only sending a packet when a CAN message arrives, I set up the master to send empty packets whenever the radio was otherwise idle. This gives the ACK'er the most opportunities to respond with data, and it also acts as a link quality metric, since the packet rate reflects the theoretical max packet rate.

Each packet, in addition to an optional CAN message, includes a bunch of counters that are useful for assessing performance. RX count, TX count, CAN messege error count, etc. These counters were neat to look at while racing Quantum in Abu Dhabi. I could tell that Quantum's CAN bus was poorly built because of its frequent CAN bus errors. :-)

Black Magic

Because I'm crazy I decided to try building my own 2.4Ghz Yagi antenna. Once I figured out how to properly create a balun it actually performed well to! Sasha Zbrozek from Stanford Solar Car helped me do some real world testing driving around in traffic. We stuck a low gain duck antenna on the master in a lead car and tried various antennas in the chase car.

Antenna Type Stopped in Traffic Highway Driving
High gain omni Slight drop in bandwidth Data loss during normal driving
Patch antenna Solid bandwidth Slight drop in bandwidth
Yagi Solid bandwidth Solid bandwidth


In Abu Dhabi we ended up using a patch antenna because there wasn't a good place to mount the yagi. In practice, the patch antenna was totally great. In an hour of driving I only lost 4 CAN messages total!


For some reason, I had to re-flash the ACK'ing node using the Arduino IDE whenever starting it. Otherwise it wouldn't work for some reason. I assume it's some bug in the serial-to-USB firmware on the Arduino UNO R3.

The nRF24L01+ modules didn't seem to play well with the NRF24L01 + PA + LNA modules. Pairing like radios I could get 1500 packets/second through. Pairing dissimilar radios together I could only get 15 packets/second! I don't know why this is, especially since they use the same chip.

Update: So, it turns out counterfeit nRF24L01+ chips are quite common, and they have an inverted feature bit in the RF frame when using variable payload sizes! This means that at least one of my radios is counterfeit. (The "correct" radio could be real, or it could be a more correct counterfeit.)