DonsDeals Blog: Designing an RF Transceiver (MRF49XA)

Search My Blog

Wednesday, February 8, 2012

Designing an RF Transceiver (MRF49XA) - Alternet

RF Transceiver (MRF49XA)

From The personal and professional blog of William Dillon

February 7th, 2012

Overview

I’ve started work on a prototype USB RF Transceiver dongle using the MRF49XA and an Atmel AT90USB series micro controller. Along with the change in hardware, I’ve made a change in the packet format as well. The old packet format was based on the MRF49XA sample code from Microchip, ported to the AVR.

Prototype build using AT90USBKey

The source code (still early) is available on GitHub. For now, it’s designed for use with the Atmel AT90USBKey (user’s guide). The schematic I used for connecting the USBKey to the transceiver is essentially a direct mapping of the attached schematic (below). The only real difference is that the Atmel chip is slightly different. Notice in the above image that almost all of the interface wires go to port B on the AVR. This proved rather convenient as it was easy to construct the wiring harness using rainbow ribbon cable, which I highly recommend. A little heat shrink tubing helped keep the wires from wiggling and breaking. There are complaints about the pin spacing used for these ports, because you can’t install standard .1″ headers. That is a bit of a disappointment, but it does work quite well with direct soldered wire. The only “stray” wire is for the interrupt request, which is installed on the wrong port in the image. On the schematic, it’s connected to pin C7, but for the USBKey it should be on pin E4.

It cannot be said how nice it is to ditch the dedicated programmer for the built-in AT90USB boot loader. Whenever you need to rev your code, just reset the controller while holding down the HWB button. You don’t even need to unplug the USB connector. The USB system will “re-enumerate” the device as a “DFU Programmer,” and you can simply download the program. Hit the reset button again and you’re back up & running!

As I often do, I’ve hacked together a simple frame to keep the prototype from self-destructing while I develop it on the couch. I just took a scrap piece of acrylic and drilled some holes for the mounting holes on the USBKey. To mount the transceiver I used velcro adhesive tape.

A bizarre, but kinda cool, feature of the USBKey is that it comes shipped with firmware that allows it to be a USB device and host. If you plug it into your computer it will appear as a USB flash drive, containing all the documentation and software, and a mouse using the little joystick. If you power it using the 9v battery clip it behaves like a computer; you can plug in a mouse and make the LEDs blink by moving it around. It also includes a few extra sensors that you can use for playing around with USB, such as a thermometer.

Software

The software part of the project centers around the LUFA USB Framework written by Dean Camera (see the excellent tutorial by Christoph Redecker). LUFA is licensed using the relatively permissive MIT license. I’ve licensed my code under the GPL version 2, which I think I can do given the licensing of LUFA.

I had great aspirations of adding forward error correction to the transceiver. When I used it before, I had significant bit errors in the communication path. I had hoped that I could eliminate these while not increasing the transmit power. I started with Phil Karn’s encode_rs_8 and decode_rs_8 functions. These functions are great, and really easy to use. The problem, though, is that they use a lot of RAM. The functions are what’s called a fixed-length (255, 223) Reed-Solomon code. What this means is that the whole “code word” is 255 bytes (or symbols), and 255-223=32 bytes of it are parity. You can use them with less than the full code word size, by filling unused data with zeros, but the math still requires several arrays that are 255 bytes long. This was a non-starter on the AT90USB162, which has 512 bytes of ram total. Therefore, I had to abandon dreams of FEC; at least using these functions. I decided that the best course of action was to define as basic a packet format as possible that would allow any form of data as its payload.