1-wire radio control protocols

Ramble...

 These protocols are used typically to communicate between a radio reciever and flight controller, or any other kind of controller in a flying drone, robot, or something else.

 

I'm considering here, ibus, sbus and PPM

 FUTABA S-BUS

------------

This is the protocol used by Futaba receivers, servos, and some other things. It's a serial
1-wire protocol and uses an unusual bit rate of 100kbaud.

Some details are here:
https://os.mbed.com/users/Digixx/notebook/futaba-s-bus-controlled-by-mbed/
https://github.com/uzh-rpg/rpg_quadrotor_control/wiki/SBUS-Protocol

The S-bus signal is "upside down" - normally low, and uses low=0, high=1.

S-bus also requires some "bit twiddling" because it uses 10 bits per channel and splits them between several bytes.

 Pros: Many digital receivers support it.

Cons: A pain in the arse to decode, difficult to simulate, USB serial dongles usually can't decode it.

TURNIGY / HOBBYKING / FLYSKY - I-BUS

Ibus uses a bit rate of 115,200 baud, which is a "standard" speed. I-bus is "the usual orientation", normally high, low=1, high=0 (this is consistent with most other serial protocols)

Ibus uses simply 2 bytes per channel and outputs the number of microseconds wide that a pulse would be if the channel was transmitted as a servo pulse (1000 - 2000 with 1500 as the centre).

Pros: Much simpler than S-Bus to decode, can decode with a USB-Serial dongle easily.

Cons: Only Flysky (like) receivers support it.

PPM

PPM is a scheme of multiplexing several channels of servo pulses on the same wire. It still uses 1000-2000 microsecond pulses for the channels, but sends them sequentially with a longer sync pulse.

 

If your microcontroller doesn't have a crystal, you might not be able to detect the 1500us centre pulses accurately, and need to trim the centre position. The microcontroller might vary its speed slightly depending on voltage and temperature.  (Radio receivers need a crystal to operate their radio, so their timing must be spot on)

 

 

Pros: Widely supported

Cons: Analogue; need exact timing to get centre position trimmed correctly. Electrical noise could cause channels to get mixed up with crazy results. Supports fewer channels than sbus or ibus.

 

Malenki-Nano receiver - development pictures

Here are some pictures of prototypes of the Malenki-Nano.

Prototype 0

This was a veroboard / stripboard which was already used for development of my earlier ESC. The MCU was atttiny1614, and the radio module was "dead bug" installed with hot glue and bodge wires.

Motor drivers were mostly none, but I did add a rz7899 on a breakout board at some point. There are various sockets in the front side of the board and quite a few LEDs, I can't remember why I put them all there or what plugged in where.

 

Prototype 1

 I created a PCB with rz7899 motor drivers x3 and components on both sides. It used the attiny1614 which was hand-soldered quite easily due to its 1.27mm pitch.

Unfortunately this prototype died a fiery death caused by a short circuit connected to a lipo.

This was a lot bigger than it needed to be, so I looked for other motor drivers to replace the (excellent, reliable) rz7899.

Prototype 2

This hand-soldered prototype uses the mx113l motor drivers, which are in a little sot23-6 package, but don't handle as much current as the later ones.

Soldering the attiny3217 was quite tricky (no pins, 0.5mm pitch pads) 

This board unfortunately had a couple of design mistakes which were not easily corrected - I added a bodge wire to make the radio work, but the weapon channel is still broken.

It still drives ok and I use it to test firmware in a robot (pictured).

 Prototype 3

I finally got it right! The motor drivers are now drv8837d which are really tiny and drive 1.8 amps. Hand-soldering this prototype was not easy and I broke one board completely before I made this prototype work.

Production board

The first production run. These were panelised with 2 boards per panel, so you can see the "mouse bites" where they were separated. A machine soldered these ones.

Programming pins rig

I made this rig to do programming and testing, to avoid the need to clip / unclip at least three test clips (without creating any shorts...)

 

I can hold the pins down with a test-device, then wait while the firmware is written. It then automatically starts in a special test mode which flashes all the LEDs on the programmer (using the motor drivers) so that I know all the motor drivers are working ok.

Electronics assembly with Kicad and JLCPCB Assembly

I am shortly getting this assembled:



Thanks to JLCPCB Assembly.

Designed with Kicad  

A big thanks to all EEVBlog forum users and EEVBlog forum user "essele" who created this Kicad plugin for jlcpcb assembly which I have now forked to work with panelised boards

Also thanks to Flemming Frandsen for kicad-util which generated the pcb panelisation. I have forked this to work with Kicad-nightly.