BLE-to-ShockBurst bridge for Syma X4 quadcopters

The complete set: quadcopter, nRF51-DK, Android device, and gamepad.

The Syma X4 quadcopter uses a radio protocol called ShockBurst that was made popular by Nordic Semiconductor sometime around 2004. Contemporary Nordic devices still support ShockBurst; the following video demonstrates the quad being flown using a cheap gamepad and an nRF51 development kit (nRF51-DK).

The next video replaces the gamepad with an Android app that uses Bluetooth Low Energy (BLE). Although the quad does not support BLE, the nRF51 can use its single radio to receive commands over BLE and translate them into ShockBurst packets before forwarding them to the quad.

The Quadcopter

The Syma X4 quadcopter is sold together with its transmitter for less than $40. It is fun to fly and is a solid quadcopter to use as the base for an embedded project:

• 2.4GHz control protocol with channel hopping
• 4 control channels (pitch, roll, yaw, throttle) plus a flip function
• Onboard, 3-axis gyro automatically stabilizes flight
• 6.0" x 5.5" x 1.1" 
• Weighs a little over 1oz with battery
• 3.7V 350mAh LiPO Battery
•  ~7 minutes of flight time per charge
•  ~50 minutes to recharge via USB

This little guy is surprisingly resilient to crash damage.

 

The Transmitter

The transmitter is easy to disassemble and the radio IC sits on its own module (marked "LOG1501E") along with a simple wire antenna.

The transmitter after removing a few screws.

Although the radio IC is covered in epoxy, there was reason to suspect that the radio was a clone of Nordic's nRF24L01+ transceiver.

The bottom of the radio module is pushed into a slot in the transmitter's main board and the module's leads are soldered to the main board on the opposite side. The module's pinout looks like this:

The bottom of the radio module where it interfaces with the transmitter's main board. The colored wires were added to make attaching probes easier.

The radio is controlled via SPI so capturing some traffic was the first step to learning more about it. The leads on the transmitter's board are easier to solder wires to than the radio inside the quad itself. The Logic 4 logic analyzer produced an SPI trace that looked like this. The nrf24l01p-decode utility was created to decode the SPI trace into a more readable version.

The Protocol

The quad uses the radio's 250kbps baud rate as well as a hardware-based, 2-byte CRC. Note that a software-based CRC byte must also be generated and included in every control packet.

The quad listens for bind packets on address {0xAB, 0xAC, 0xAD, 0xAE, 0xAF} when it starts up. It uses channel hopping to minimize interference and cycles through the following channels during the first step of the binding process: 75, 48, 64, and 9. The default bind packet for my transmitter is {0xA2, 0x00, 0x02, 0xDF, 0x1C, 0xAA, 0xAA, 0xAA, 0x00, 0x1E}. Note that part of this packet is the address that the quad will use to listen for control packets after the binding process is finished: {0x1C, 0xDF, 0x02, 0x00, 0xA2}.

A different set of channels is used for control packets. These channels are probably dependent on the control address that is assigned to the quad during the binding process but this has not been confirmed. For now, the control channels that are used are: 22, 30, 54, and 62.

Packets are sent every 4ms and two packets are sent in each channel.

Each type of packet that is sent during the binding process should be sent at least 30 times to ensure that the quad receives it. The process looks like this:

1. Send the bind packet so the quad can parse the address that it must listen to in order to receive control packets
2. Send a control packet with the throttle set to minimum
3. Send a control packet with the throttle set to 246
4. Send a control packet with the throttle set to minimum

After this sequence is finished the quad's headlights should switch from blinking to steady to indicate that the binding process was successful.

The control packet has the following format:

Control packet payloads are 10 bytes long.

Finally, note that the packets that are sent from the transmitter to the quad are not acknowledged by the quad so there is no way to know whether or not the quad is receiving packets or has completed the binding process.

The Development Kit

The nRF51 has a powerful feature called the Multiprotocol Timeslot API; this API allows the application on the nRF51 to access the radio whenever the radio is idle (even while in a BLE connection).

If the Android app does not accept the 30ms Connection Interval that is requested by the firmware on the nRF51 then the firmware disconnects. The radio requires about 10ms per BLE Connection Event and during those events as many as three ShockBurst control packets are cancelled. The quad assumes that these packets were lost due to noise so as long as the channel hopping stays in sync there is no problem resuming control after the Connection Event finishes.

As many as three control packets are dropped when the radio is busy with BLE.

The quad can be flown without issue even when the nRF51-DK is sitting adjacent to a WiFi router. Although the maximum range has not been determined, the quad can be flown far enough away that it is no longer possible to see which way it is pointing.

The Gamepad

The gamepad shown above has had its wires stripped so they could be poked into one of the headers on the development kit but it is otherwise unmodified. For reference, the gamepad's pinout looks like this:

The Trenro gamepad wires were colored: VCC:white, CLOCK:blue, LATCH:yellow, DATA:red, GND:black.

If the gamepad is used then its VCC and GND pins should be plugged into VDD (NOT 5V) and GND on the nRF51-DK. Additionally, the gamepad's LATCH pin should be plugged in to P01, CLOCK should be plugged in to P02, and DATA should be plugged in to P03.

The Code

The firmware is based on the Nordic UART Service (NUS) example project in the nRF51 SDK.

The ShockBurst protocol is provided by the micro-esb library. One of the features of the nrf24l01p-decode utility is that it will output configuration code for the micro-esb library.

The firmware (quad_bridge_fw) and the Android app (QuadBridge) have been published on github.