Reverse Engineering a Quadcopter RC, or: How to not miss the needle while throwing the haystack in the air (Part 4)

Part three of this series covered tagging into the SPI communication between an Arduino Uno and a nRF24L01+, followed by the transceiver inside the quadcopter RC. We have seen registers being read from and written to for initializing the transceivers and how the pairing of the quadcopter might be initiated.

In this part we will look at what really happens during pairing, have a brief look at the messages sent by the RC during normal operations and then we’ll try to create our own RC.

Step 8 Pairing and normal operation

As we have seen in step 7, the RC is initializing the transceiver and then starts sending messages on alternating addresses with alternating payload. Below is the part that would actually interrupt the transmission cycles and make the quadcopter stop blinking, indicating that the pairing was successful:

SPI RC pairing.png

RC pairing procedure

So the pairing process seems to go like this:

  • Set TX and RX address to 101 101 101 101 101
  • Send out RC address
  • Check for acknowledge package
  • Set TX and RX address to RC address

The SPI interface of the RC goes silent after the pairing and would only become active again after moving the throttle to max and then to min (probably a precaution to make sure the throttle is set to zero before sending anything to the quadcopter). Moving the throttle stops the RC LED from blinking and the RC would beep. Since the beeping was a bit annoying and too loud for testing over and over during the nights (wife and kids already started asking questions…), I soldered the little piezo speaker out.

The procedure during normal operation (after successfully pairing and setting the throttle) looks like this:

SPI RC sending 3.png

RC procedure during normal operation

Again, a very simple procedure, repeating itself every 4ms:

  • Read the status register
  • Flush the transmission register
  • Clear the status flags
  • Send the control data
  • Power up the transceiver (which is actually a bit strange)

The data package seems to be quite simple, too:

The data packages sent by the RC during normal operation

As we might have expected from the init process, there is 8 bytes per package.

  • Byte 0 and 1 controlling throttle and yaw would range between 0 and 255
  • Byte 3 and 4 controlling pitch and roll, ranging between 65 and 191 or 1 and 255, depending on the position of the +/- switch
  • Byte 7 indicates the positin of the +/- switch with ‘-‘ is equal to setting bit 4, resulting in a value of 16. For the “flip over” command, which is being activated by pressing down the pitch/roll stick on the RC, bits 0 to 3 of the last byte seem to get set, adding 15 to the switch value.

As for the counters in bytes 2, 5 and 6, I’m not sure what they are supposed to indicate. Counter 0 would start somewhere at around 50 and count up, while the time intervals for each step seem to get longer and longer starting from about 1700 ms. Counter 1 and counter 2 start with values 101 and 116 (sometimes more, sometimes less) and would count backwards at totally different intervals. All counters jump back and forth between the numbers at each step, indicating that the numbers might be rather measurements than hard counters. I started playing with the voltage for the RC, changing it between 2.7 and 4.0 VDC and it does seem to have an effect on the counters. Maybe there is even a feedback from the quadcopter concerning its battery status. Unfortunately the quadcopter seems to be quite particular about the power input and won’t work when connected to a regulated external power supply.

EDIT: With a fully charged quadcopter, the counters start at 11, 124 and 125, so it is quite possible that there is a feedback coming from the aircraft regarding the battery power. Maybe when we start sending stuff ourselves to it, we will have more details…

EDIT2: As it seems, the quadcopter does not send any feedback to the RC, which is quite bad when reaching battery low, as the aircraft just drops dead from the sky without any warning. Would be nice to have the RC beep before the battery is dying.

Anyhow, we seem to have everything we need to create our own RC, so let’s move on to the next step:

Step 9: Wrapping it all up – DIY RC with an Arduino Uno Nano and a Wii Nunchuck



EDIT: Just out of my own experience with quadcopters disappearing on neighboring grounds, before you start building and using the DIY RC, please note the disclaimer, especially the part where it says “at your own risk”…

The grand finale. And this is what you need:

  • Arduino Nano (low footprint, can run from a 9V battery without any converters)
  • nRF04L01+ transceiver
  • Wii Nunchuck
  • 9V battery holder with battery
  • Small breadboard
  • 11 wires
  • Source code from my github repository

This is how to hook it up:

RC pins.png

Connecting the DIY quadcopter RC

The grey part on top of the wiring matrix is what you see looking at the nunchuck connector. Make sure to connect its VCC only to 3.3VDC, even though it might be running fine with 5VDC, it is not recommended according to most of the nunchuck tutorials.

The source code should be pretty much self explanatory. It’s using the same RF24 library as in the earlier steps, together with a lightweight nunchuck library based on what I found on the Arduino Playground and todbots github repository. (Back in 2008 Tod created these neat adapters for the nunchuck, not sure if he is still selling them. Sticking the pins of the jumper wires into the connector did work for me just fine)

Adding a few calibration values matching your own controller (minimum / maximum range of the joystick x and y axis obtained by defining DEBUG mode and commenting out the pairing, tweaking pitch and roll for more or less agility) and… off you go.

As soon as I get a little practice, I might add a video to this step (if the quadcopter doesn’t crash and burn in the meantime, but so far it seems to be quite forgiving…).
A few battery charges and many more crashes later, here’s a quick demo:

Just in case you are wondering why on earth I would want to start the quadcopter from a soccer goal: First, the video was taken during the 2016 European soccer championship in France. And second… due to it’s very small size and weight, the quadcopter was quite sensitive to ground effect, so I figured starting out of ground effect (HOGE) would be easier…


It’s been quite a journey from reading the documentation over listening to the radio communication and eavesdropping on the SPI interface to the DIY quadcopter RC.

My wife, rational as she is, asked me “what was it good for”? Well, first of all: It was fun. There was a mystery and I was able to solve it (even though there might be a few little secrets left). Second: I learned more about reverse engineering in general and the SPI interface in particular, and that it is not as hard as it might seem. Third: I created my own RC, which might not be that big of a deal or more accurate than the original one, but still, it is working and that’s a big reward.

But where to go from here? Anything is possible, you could…

  • …add channel hopping to the DIY RC

As it seems, the original RC switches channels during normal operation, probably based on the number of lost transmissions. This might explain why my aircraft is acting up a little from time to time (it cannot be all pilot induced…!). You have to keep in mind that Wifi and Bluetooth are both working on the same frequency and if you’re living in a crowded neighborhood with a lot of access points and chordless speakers… well, you do the math.

  • …add a different input to the DIY RC

The Wii Nunchuck was rather easy to use. You might even try and hook up the Arduino to the trainer port of your much fancier RC. (Did that to use the two free channels of my Futaba T7C, controlling the pan / tilt of a camera mounted to my RC plane, but that’s a different story to be told) Or control it with a smartphone like the Parrot AR.Drone.

  • …watch the quadcopter with a camera or a kinect and have your PC control it autonomously
  • …add some sensors or even a camera to the quadcopter
  • use the RC for other projects (control other things, have it act as a USB joystick or connect it to the trainer port of another RC and practice with your favorite RC simulator)

The list could continue forever (e.g. adding an on/off switch to the quadcopter or a bigger battery). For me, apart from the promised video, this project seems to be complete.

About Michael Melchior

Aviator, computer scientist, enabler and mentor.
This entry was posted in Projects, QC-360-A1 and tagged , , , , , . Bookmark the permalink.

1 Response to Reverse Engineering a Quadcopter RC, or: How to not miss the needle while throwing the haystack in the air (Part 4)

  1. Pingback: Reverse Engineering a Quadcopter RC, or: How to not miss the needle while throwing the haystack in the air (Part 3) | Michael Melchior

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s