RC System Hardware v.0.1.

This page has been superseded.

For a more up to date description of this projects hardware check here:

RC System Hardware.

Anyone building their own PCBs will still find the "First Prototype" section interesting but otherwise i recommend you use the updated page.

The transmitter board and receiver board is to be kept as similar as possible for the time being to speed up development time. This way only one set of circuit boards needs to be developed.

Block diagram:

[Power monitoring]

|

[RF module] -- [AVR microcontroller] -- [I/O pins] -- [servos / sensors / input device]

Pictures.

First prototype of the receiver board with RF module connected.

Professionally manufactured PCBs will bring the size down considerably.

First prototype of the controller. The same PCB as the receiver is used.

Plans are to include output to an LCD display via the UART for monitoring battery life, signal strength, altitude, airspeed, etc.

RF Modules.

The requirements of an RF module for this system were:

- 2 way communication.

- 500m or greater range.

- Pre-approval by the various authorities who regulate RF transmission of the module format so this system can legally be built by a wide range of people.

- Light weight. (under 20g)

- Low cost. (under 50Euro.)

- 4000bps minimum. (easily exceded by most options.)

Several I/O modules were investigated but surprisingly few suitable ones are readily available in small numbers to hobbyists.

The successful contenders fell into 2 categories: UART controlled modules and SPI controlled modules.

Most of the UART based modules i saw were simple to use, half duplex devices. Packet format was all taken care of. The microcontroller just reads from and writes to the UART. This leaves the user with little control over latency.

the most promising of these was the XBee-PRO.

1600m range LOS. (Line Of Sight.)

Around 30Euro.

3g in weight.

Pre-approved in most countries so no issues with radio licencing.

It had the added advantage over most UART based modules that it is possible to affect when packets are sent giving some control over latency. (ie. the time between data being sent to the UART and it arriving at the other end.)

Of the SPI controlled modules most of the ones i found were based on the Cypress CYRF6936 chipset, often just being an CYRF6936 and a RF amplifier on the module.

The module i ended up settling on was a Unigen UGWJ4US which barely even has it's own datashet but instead just refers the user to the CYRF6936 one.

1000m range NLOS. (Non Line Of Sight what ever that means...)

14Euro. (see hidden costs later.)

The datasheet does not actually give a weight (the datasheet omits a lot of things...) but it is 34.7mm x 23.0mm x 6.0 mm and i estimate around 5grams.

Pre-approved in most countries so no issues with radio licencing.

The CYRF6936 chipset allows a huge amount of control over transmission types, data rate, packet size, etc. so the only issue with latency or transmission time will be working out how to configure the required option.

So, why did i choose a CYRF6936 based module rather than something like the XBee?

They are more flexible. There are far more options when it comes to setting up the transmission type.

This comes at a price though: the learning curve is far steeper and the Datasheet is somewhat obscure.

Add to this the lack of documentation on the web and it's quite a daunting prospect for a hobbyists.

I do suspect though the reason i chose the CYRF6936 approach is that i like the pain.

And why did i choose the Unigen UGWJ4US over all the other CYRF6936 based modules?

It was bang per buck. 1000m range / 14Euro.

Problems with RF Modules.

I opted for the Unigen LETO-LPA WirelessUSB (TM) Radio Modules, UGWJ4USHN33A Series Long Range Modules.

As it turns out though i wish i'd used a different module.

The Datasheet for the LETO UGWJ is terrible. For the most part it is just a copy of the Cypress CYRF6936 datasheet which is fine but there are serious omissions in the datasheet when it comes to controlling the modules RF switch and amplifier.

What is not apparent from the datasheet is that the PACTLn pin on the module is not controlled by the CYRF6936. This pin appears to be the receive amplifier and must be controlled by the atmega AVR microcontroller.

To keep things simple i also opted to control the modules PACTL pin in the same way. The PACTL pin appears to control the modules TX amplifier.

An interested developer contacted me by email and told me which CYRF6936 register controls the Unigen UGWJ4US PACTLn pin.

The CYRF6936 register 0x0C (XTAL_CTRL), Bits 7,6 should be set "01 = Active LOW PA Control" for correct operation.

Obscure but there you go.

The microcontroller pins connected to PACTL and PACLTn will be configured on the microcontroller as inputs to stop them interfering with the RF module.

This leaves them available for other similar RF modules like the Artaflex which need these pins driven.

Alternative RF modules.

Close to 2 months development time was wasted on the PACTLn issue due to inadequate datasheet so i must admit i'm a little grumpy at Unigen right now.

In that vein, i would recommend considering this module from Artaflex: http://www.artaflexmodules.com/product.html?id=4 at 27Euro as an alternative.

The module is listed as 1km outdoor LOS on the datasheet.

The RF switch on this module must be controlled manually which means it cannot be used in transaction mode. To do this logic is applied to pins 11 and 12 on this module which will need to be provided for in firmware but this is a simple addition to the TX and RX code.

For shorter range applications the Unigen UGWG LETO range at 10Euro could be used with no modifications to firmware or hardware. (pins 11 and 12 on this module are unused.)

The range of these modules is either 30m or 50m LOS, depending on which bit of the datasheet you read. (Inconsistent Unigen Datasheer? Really?)

Microcontrollers.

Only AVR microcontrollers were considered for this project because that is what i know. I have the development environment already set up and they are the only platform i know that comes in on budget with enough power to handle the fast data through-put the CYRF6936 based RF modules are capable of.

When it came to which AVR,

- A lot of flash memory so my code would not be limited by the platform.

- 16bit hardware timers with multiple output pins so i can control servos in hardware, simplifying timing in my code. 6 such pins minimum.

- Small footprint. The receiver end will probably end up going on a tiny PCB if i ever have some professionally made so it has to be small. 15mm square max.

- Low cost. I'm probably going to loose a few of these learning how to fly so a 10Euro limit.

The AVRFreaks.net comparison chart is the only tool you need for choosing an AVR.

In the end i chose an atmega2561. Yes, i know it's over budget with unit price around 14Euro on Digikey. Bite me. All the other features fit.

6 servos can be controlled in hardware although additional sevos could either be added to an i2c breakout controller or just timing PWM on the other I/O pins in software if required.

Ample analogue inputs as well as a hardware SPI interface for the RF module are also available and an UART for debugging.

Power Monitoring.

One of the most important sensors to have on a long range RC aircraft is battery voltage followed by current draw.

As the radio system is 2 way reporting this information back to the controller is easy.

So the main battery pack can be monitored the main battery plugs straight into the receiver board. The receiver does not use this connection for power, instead taking power from the usual BEC.

The Motor controller and BEC then draw power from the receiver board after the power monitoring stage.

A simple voltage divider is used to measure battery voltage.

It was considered to measure the voltage of each cell in a LiPo pack but it was decided this used too many valuable analogue inputs on the microcontroller.

To measure current draw so battery life can be integrated a power resistor is used. The voltage across this resistor is measured through an op-amp designed for this task: ZXCT1009.

Although this has been provisioned on the circuit board it has not yet been implemented and tested.

Servos, Sensors and Input Devices.

Form the microcontroller's point of view there is little difference between servos and sensors on the aircraft and the input device on the ground. They are all controlled by microcontroller I/O pins.

There are a few different kinds of I/O pin though.

First there are the Output Compare pins of the 16bit timers.

These pins are useful for controlling servos as no timing software is required to generate servo control pulses.

The atMega2561 has 6 of these pins (3 per 16bit timer).

Analogue Input pins are useful for a wide range of sensors and inputs. 1 is used for measuring battery voltage and 1 more will be used for measuring current draw on both the airplane and at the controller.

From the 8 total, this leaves 6 spare analogue inputs which should be enough for reading joystick inputs at the controller and sensors on the aircraft.

There is also an i2c bus and SPI bus which can be used to connect the main board to secondary microcontrollers if I/O ever becomes short on the main board.

One of the microcontrollers UARTs will be available for debug output as well as outputting information received from the aircraft on the ground station. This data will then be accessable via laptop or separate LCD enabled microcontroller board.

The UART on the aircraft will be available for connecting GPS modules or other UART driven hardware.

For the prototype a Sony PS2 controller is connected to general purpose I/O pins. This could easily be replaced by more conventional potentiometer type joystick connected to analogue inputs but the PS2 controller is a nice ergonomic solution while testing.

First Prototype. (Modified 24/03/2009 to include control of PACTLn pin)

Building the Prototypes on Homemade PCBs.

A lightweight double sided copper clad board was used for the PCBs and etched using the Toner Transfer method.

While the RF module it's self proved inexpensive there were a few hidden costs. The antenna connection was a somewhat obscure mini coaxial connector which is difficult to find connectors for. This connector type is used on a few computer wireless network cards (eg. IBM laptops wireless cards) and can be found on E-bay but Digi-Key stocks ready made up cables as well. (Search for "U.FL")

The RF modules also require a 2mm pitch connector.

This all brings up the price of using the Unigen RF modules to around 20Euro each. Still good value for the result.

As was already mentioned, a Sony PS2 controller was connected to microcontroller I/O pins as an input device.

Adding control of PACTLn (pin 11), control of PACTL (pin 12) was also added to enable the use of other RF modules (eg. Artaflex: http://www.artaflexmodules.com/product.html?id=3) while using the same hardware.

These mocrocontroller pins can be configured as inputs when used with the Unigen UGWJ4US so as not to interfere with the pins level.

Homemade PCB Circuit Diagram.

*** Please note, this schematic and the Eagle files in the download section has a small error: The ZXCT1009 current sensing chip is in correctly orientated. ***

The Eagle PCB files for making these boards using the Toner Transfer method can be found in the Downloads section.

The Next Prototype.

The next prototype will be made on a professionally made PCB and include connectors for 2 RF modules allowing for antenna diversity as well as enabling the use of 2 separate channels concurrently.

<< Home. RC System Firmware. >>