SuperbitRF

What is SuperbitRF?

SuperbitRF is a project to design our own datalink/radio receiver. The ultimate goal is to get the receiver to work with our own datalink modem and also normal DSM2/DSMX transmitters. However, the main focus is to get a very small datalink which will be integrated in the autopilot PCB.

Components

Superbit CYRF

Superbit USBRF

How it works

In general you will have either a USB datalink modem or a DSM2/DSMX transmitter which can be bound to the datalink/radio receiver on the autopilot. During the binding process, the receiver will know if it is binding to a USB datalink (in DSMX or DSM2 mode), DSM2 transmitter or a DSMX transmitter. After binding, the receiver tries to keep in sync with the USB datalink or transmitter and will forward the packets received to either the paparazzi datalink or the radio control.

The SuperbitRF USB modem uses the normal DSM2/DSMX protocol, which can be chosen inside the firmware. For more information on how the DSM2 and the DSMX protocol works, see DSM.

The source code

The firmware for the SuperbitRF USB modem is open source and can be found at Github SuperbitRF Firmware. As of this writing (Aug 2013), the source code for the datalink receiver (which will run on the autopilot) is not finished yet.

SuperbitRF in depth

The SuperbitRF firmware for the USB dongle consists of 3 different build targets: Transmitter, Man In The Middle (MITM), and Receiver.

• The Transmitter (used for GCS) target is capable of sending Paparazzi joystick commands in DSM2 or DSMX to normal DSM2/DSMX receivers and the SuperbitRF receiver. It is also capable of receiving downlink messages and sending uplink messages to a SuperbitRF module.
• The MITM target (used for GCS) is only capable of receiving downlink messages and sending uplink messages to a SuperbitRF module, but this is possible in combination with a normal DSM2 or DSMX transmitter.
• The Receiver target (used for airborne) is capable of receiving DSM2 and DSMX commands from a normal DSM2/DSMX transmitter or the SuperbitRF transmitter, and is also capable of transmitting downlink messages and receiving uplink messages from a SuperbitRF module.

The SuperbitRF always takes PPRZ messages as input and also always outputs PPRZ messages.

Next to the firmware of the SuperbitRF USB dongle we also have a integration of only the CYRF6936 chip inside Paparazzi. This part can do the exact same as the Receiver target from the SuperbitRF dongle, except that this time all the processing is done directly inside Paparazzi.

Transmitter USB Dongle

This was functional in the beginning, but now probably doesn't work anymore. It doesn't have the normal DSM2/DSMX transmission part in it yet and only has the PPRZ uplink and downlink.

MITM USB Dongle

This is functional now with DSMX, but there are still some timing problems. The up- and downlink works and keep workings when the transmitter is shut down. When the transmitter is down the receiver (the USB dongle on the airframe or the integrated cyrf code in Paparazzi) is capable of sending downlink messages at a higher rate because the receiver timing of the syncing mode is used to transmit and receive packets to the MITM. When the transmitter is on the receiver is in transfer mode and the transmitter sets the timing for the receiver and thus also for the MITM. So the timing between the MITM and the receiver is very hard to tune, because the MITM doesn't know when the receiver is in transfer mode or not, and each transmitter is sending at a different timing. This is why getting the timing right is so difficult.

Receiver USB Dongle

This part receives the DSM2 and DSMX packets, but doesn't receive the data packets from the SuperbitRF dongle yet. It also doesn't parse the DSM2 and DSMX packets to normal PPRZ packets yet. This is mainly used for debugging a transmitter to see what the timing is and see if it is properly working. This is also the basis for the integrated CYRF6936 receiver inside paparazzi.

SuperbitRF receiver software (inside Paparazzi)

This consists of two parts, the radio_control subsystem and the telemetry subsystem. The radio_control subsystem works independently from the telemetry subsystem, but uses the same code. The telemetry subsystem isn't tested without the radio_control subsystem, but it works when the transmitter is not sending (not in a optimised way because it is also continuously synchronising to get back the radio control signal). But for now everything seems to work in DSMX mode(because DSM2 still has some timing issues and is harder to debug) in combination with the MITM usb dongle.

Getting started

For now I only have a small explanation on how to bind the MITM, the integrated CYRF6936 paparazzi and a normal DSMX or DSM2 transmitter with each other, later I will add more information when it is working.

To MITM USB dongle automatically starts in binding mode, so you don't need to do anything besides plugging it in. When you have done that you start your autopilot with the bind plug, like a normal Spektrum receiver. Both the MITM and the autopilot are now in binding mode and waiting for the transmitter to send binding packets. Next, power on your transmitter in binding mode. When the MITM is done binding the yellow LED will go on. When the autopilot is done binding you don't see anything until it's synchronised with the transmitter, then the normal RC led will go on. It doesn't matter if you bind the autopilot and the MITM not at the same time, it only matters that they are bound to the exact same transmitter. When the binding is done everything should work!

Progress

• 19/07/2013 - We now have the MITM working in combination with a normal transmitter in DSMX mode (DSM2 mode still has some problems) and also have the receiver part inside Paparazzi working. The transmitter and the receiver target of the superbitRF aren't fully functional yet, but the main focus was the MITM target. There are still some strange things happening in the timing, but we need to look more into the timings of different RC transmitters because that affects the MITM timing.
• 09/07/2013 - Also got the downlink working!
• 03/07/2013 - Got a fully working RC!
• 02/07/2013 - After some simple logic analysing we figured out the faults and now we have a working SPI connection between the superbitRF and the Lisa M. Already implemented the binding procedure inside Paparazzi and we are receiving packets, but we didn't implement the handling of the binding packet.
• 01/07/2013 - We connected a cyrf6936 chip directly to the spi bus of a Lisa M and are trying to receive the MFG id, manufacturer id, from the cyrf6936. Having some problems with that so we are going to sniff the spi connection and the reset pin with a logic analyser.
• 28/06/2013 - We sniffed a normal dsm2 receiver spi bus connection to the cyrf6936 chip and found the errors in our own protocol. We are now able to bind to a normal DSM2 and DSMX transmitter trough DSM2 and receive the channels. The next step is to implement DSMX and make our own datalink work together with a normal transmitter. (We used saleae logic with a simple php script to analyze the cyrf6936 spi connection)
• 20/06/2013 - Hacked the SITL(NPS) of paparazzi to enable a hardware datalink and tested the Quad Lisa M simulator with normal telemetry. Everything worked great, tweaked some of the timings of the receiver and transmitter, and we now have a reliable datalink!
• 19/06/2013 - Made the datalink more reliable, and both the receiver and transmitter know when a packet is lost and resends it. Als did manage to get a simple datalink with an AR.Drone 2.
• 18/06/2013 - We currently have a datalink working between two SuperbitRF usb modems. It isn't that reliable yet, but we are working on improving it. We can already bind to a normal DSM2/DSMX transmitter, but can't get the syncing to work. We are also working on testing the datalink transfer rate and testing how paparazzi handles the packet loss you have with a unreliable radio datalink.
• 11/06/2013 - Received the SuperbitRF usb modems and did some simple testing with blinking light and receiving the radio chip ID.

The contributors

• Piotr (working on the hardware)
• Bart Remes
• Freek van Tienen (working on the software)