Developer


After having had some performance issues with 2.4ghz Xbee modules I just finished up a quick project for long range two-way communication. The system is based on HACCOM HAC-LM96 500mW 433mhz 9600 baud radio modems. Range is 2km (1.2 miles) ground level, so the system should be good for really long range communication when the plane is up in the air.


Components used:
HAC-LM96 radio modem - $52
Turnigy UBEC - 3A switched DC-DC converter - $8
Teensy 2.0 - Arduino compatible board - $19

To make it plug-and-play with my Futaba 9C radio I took the casing from an old defect RF transmitter module and put the UBEC and Teensy board inside. The UBEC is connected to the 9C V+ pin (9.6-12V) and supply 5V for the Teensy board and the HAC radio modem. Sadly the HAC modem is slightly to large for the transmitter module casing, so i had to use an extra box for the HAC modem.


The Teensy MCU converts 8 channel PPM from the 9C radio into serial data for the HAC modem. The Teensy board is my favorite Arduino compatible board, has more i/o in a smaller formfactor and a proper USB interface.

In the airplane the serial data is received by the HAC modem and either transmitted directly to the autopilot or converted back into servo PWM pulses using another Teensy board. This way I can use the HAC modems as a pure R/C control system if I need to, freeing up the 2.4ghz band for live video link etc.

To use the system as a two-way telemetry system you connect the Teensy board in the RF transmitter casing to a computer using a USB cable and either talk directly using the USB interface or use a virtual serial driver for normal two-way serial communication.

Edit: Here is the source code for the Teensy PPM decoder and rf433 transmission system.
Teensy_PPM_Decoder.pde rf433.h
E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • i've been following the project Thomas links to from a distance.
    it is a very well conceived project but (in my opinion) does lack a central project page so there is a lot of reading of the rambling RCGroups thread before you can appreciate the details.
    in summary it uses embedded 2.4GHz modules that come with embedded microcontroller and access to free development environment for the microcontroller.
    you essentially have all the electronics you need for either TX or RX on the one pre-made (and fairly inexpensive) module.
    range is around 2km if i remember correctly.


    while we are all posting alternative projects, you might want to look at mine:
    http://sites.google.com/site/mrdunk/

    while i accept all the XBee and radio modem solutions out there are easy to implement (and "good enough" for UAVs) none of them are ideal in terms of latency and packet control for real time applications.

    my project uses CYRF6936 based RF modules.
    because you have direct control of the CYRF6936 RF chip you are not tied to any timing structure and are free to implement whatever structure you like.

    in my system data packets are recalculated before retransmission if they occur in a different PWM frame so latency is always less than the 20ms servo update time.

    i'm currently getting 100% transmission success out to around ~1km. RF link status and battery life data is currently displayed on blinkenlights on the transmitter or display of all telemetry data can be achieved by plugging a laptop into the TX.

    the next step in my project is to move away from the pre-made RF modules and start using the CYRF6936 directly so i can use fast RF switches to switch between diverse antennas.


    dunk.
  • btw i have had mixed results with the Intuitive Circuits OSD. It has a nasty habit of freezing up on me (either losing sync with the monitor or dropping the serial link - not sure which yet). Think i might try something else...
  • I have built and use a similar system using 60mW xbees running at 38.4kbps. I know this has been tried before by a few with mixed results, but im pretty happy with it. It is much shorter range than what you have (range test i get about 200mtrs max) but im flying helicopters, not fixed wing so its good enough for me. My general system is that the aircraft is the master. It sends a byte to request the latest info and the hand controller replies with a packet (header+data, no error checking). I have not noticed any problems with the data integrity, no glitches or pauses (other than going out of range).

    I have a Intuitive Circuits OSD feeding to a 7 in headrest DVD screen in the centre - i dont like small monitors. Anything about xbees that i have not noticed that i should be aware of?


    I have not measured the latency, but is not human perceivable at least.

    I have modified a arduino nano as a receiver - an xbee in a sparkfun shield plugs straight in.


    Can post the code but i honestly have not done anything tricky.
  • Very nice post. i was looking into getting a amp and panel antenna for my dx7 but i might check this out
  • Developer
    Thank you. I got the modems at http://www.hactech.com/
  • Developer
    @Carlito: The modem latency is 12ms. Not ideal, but plenty good enough for the kind of flying you do with UAV's. As Greg mentioned there are solutions for transmitting data trough audio channel. In fact it is not that long ago we all used analog voice band telephone modems to connect to the internet. But when you look at how much noise and signal ghosting there is on a typical analog video link, you would need a robust transmission system.

    @Greg: First of all there really wasn't all that much trouble to go trough. 1 day to get a feel for the modems and 2 days to implement the system. With the 433mhz modems I get both radio control and two-way telemetry in one system. And since the system is two-way both airplane and ground station instantly know when the connection is lost. I always do extensive ground testing with any new code, and the control loop is designed so that the proven manual control code remains unchanged and unaffected by autopilot changes. And with the kind of range we are talking about here, there is no way you can manually recover the plane if there is a glitch far out anyways. One of the uses I envision is to be able to observe and do adjustments from the ground station while the UAV is performing large area type of missions like photo mapping. 900mhz is not an option since I am operating in Europe, and as I said earlier I have had some issues with Xbee. So I wanted to try something else.
  • Impressive Project, now I must say--why go to all that trouble. I use a 15 yr old 72 MHz airtronics and a good double conversion receiver and have more than enough range. Farther than you can see a small plane. I also have tested an pair of Xbee 900 pro's (50 mW) At 1.2 miles on the ground in my car. I was recording GPS data from the ardupilot system in the car back home on my customized Ardustation (sd card data logger). Then I viewed it on Google Earth wear the 1 Hz dots stopped.
    Anyhow I believe you should have regular RC control and a failsafe multiplexer system in case of a computer glitch.

    @ Carlito, Yes that is very much possible and has probably been done. They make DIP chips for this. 1 in, 1 out. Look for an FSK chip (Freq Shift Keying). They send one tone for a 1 and another for 0.
  • Developer
    Sure, I just included the source code in the blog post.
  • Here's is what I've done: http://t413.com/websvn/filedetails.php?repname=Arduino&path=%2F...

    That file is used by both my remote and receiver to get and send data. The remote code I'm using is called Combo Remote (also on my websvn), and it uses a adxl345 digital accelerometer and a gamecube remote for human interaction. There'll be a writeup soon, once I have my quad working again.

    I'd really like to see how yours works.
  • Developer
    Thanks. I am doing the same as you. Each of the eight R/C channels are converted into a 0-255 value and transmitted as a 11 byte packet with header and checksum at 40hz. Resulting in 440bytes/sec, leaving 760 bytes/sec free for telemetry. I know 256 steps for servo control does not sound like much. But in reality (with the exception of some high-end digital servos) a normal servo is not capable of being controlled any finer then 256 steps.
This reply was deleted.