Pololu Robotics & Electronics
My account Comments or questions? About Pololu Contact Ordering information Distributors

Correct use of radio_mac


Hi All,
I am trying to use radio_mac to capture packets from a transmitting device. I want it to scan through some channels as quickly as possible, only waiting on each channel long enough to determine if a Carrier is present, or to receive a whole fixed length packet. I have been looking at both the CC2511 datasheet and radio_mac.[ch] and the documentation thereof.

I have created a radioMacEventHandler function in my code, but it is never being called. Other than including radio_mac.h, and calling radioMaxRx(pkt_ptr, timeout), to initiate the first channel scan, do I need to do/call anything to have it processed?

I cannot find the info within the datasheet that explains how to use DMA and the radio to send/receive packets. I am only interested in receiving the packets.

I did find information in the datasheet that indicates that you can reliably calibrate the FS for each “channel” first up and store these, occasionally re-calibrating them, and reusing them to enable a much faster scan through the channels, such as frequency hopping, and am using this method.

But the issue right now is that the ISR never seems to call the radioMacEventHandler.
Thanks in advance.



The documentation for the radio_mac library from the Wixel SDK can be found here:


You will need to call radioMacInit at the beginning of your program to start the library. radioMacTx() or radioMacRx() should only be called from inside the event handler that you define. You will also need to call radioMacStrobe() at some point to trigger the first interrupt. You might want to look at some of the higher-level libraries that use radio_mac for examples of how it can be used. One such library is radio_queue. You can also read the source of the radio_mac library to see how it works.

Information about radio and DMA can be found in CC2511F32 datasheet, sections 13.4 (TX/RX Data Transfer) and 12.5 (DMA Controller). For simple example code that shows how to use DMA to receive radio packets, you can look at the test_radio_signal_rx app in the Wixel SDK.



Thanks David,
I have thoroughly read the documentation on the radio_mac library, and am calling radioMacInit prior to any other use of it. I have managed to get it working (not precisely sure how I got it going, but it is) and scanning the 4 channels.
Right now, I am allowing the FS to be calibrated automatically as it moves from IDLE to RX, and not bothering to manually calibrate for now.

I have used radio_link.c as an example of radioMacEventHandler. All appears to be functioning, but I cannot capture a packet from the device I am trying to communicate with.

I have a previous application that uses radio_queue to capture the packets, which works well, but often misses them. The source device transmits bursts of 4 packets, one on each channel 500ms apart, every 5 minutes. My original application listened on the first channel with no timeout until it captured a packet. If the packet CRC was wrong, it would then try the other channels. The problem with this is that occasionally it does not get the first packet, or gets a packet that is invalid, and then misses the real packet.

My thought was to scan the 4 channels rapidly, allowing only sufficient time for a packet to be captured (packets are less than 4ms long @50kbps, so I settled for around 20ms timeout on each channel). I have set up the modem to the correct data rate, and configured it for fixed packet length. But it only ever captures packets without a valid CRC.

As I am very new to this chip, though I have a great deal of radio comms experience, I was wondering if those with greater experience could suggest what I am doing wrong, or what to look for in case I am completely on the wrong track.
The app is quite lengthy, but if anyone wishes to look at it I can post a link to github. It needs a LOT of cleaning up and a better logic engine behind it, but I want to get the basic right before I embark on that.
Thanks again and Cheers


I do not have any ideas about why all the packets you are receiving in the new application have an invalid CRC.

I do not see how your plan of switching radio channels every 20 milliseconds will work. It seems like it would be possible for your Wixel to be on the wrong channel for each of the four packets in the burst.

You might try listening on one channel until you receive a packet, and then recording the time of it using the Wixel’s getMs() function. You might want to uncomment the “T4CC0 ^= 1;” line in the ISR in time.c in order to make that measurement more accurate. Once you have that time, you can use it to predict when the other packets will come in, and you can make sure that you are listening on the right channel to receive any packets you need. All of this is assuming that the timing of the other device is precise.

I would be interested to know what kind of device you are receiving packets from and what you are going to do with it.



Hi David,
Yes, I am aware that scanning the channels can be fraught with missing a one of the burst packets, which is why I am trying to do it as fast as possible. The problem I am having with doing it by listening on one channel until I get either a packet with good CRC and processing it, or a packet with bad CRC and therefore setting up to try and capture the next channel, is that quite often the first channel packet is missed. Rarely, granted, but often enough to be frustrating.

I really want to eliminate missing a packet as much as possible. I had thought of scanning the channels VERY fast (ms or so) looking for a carrier or data rate sync, and then locking onto the channel for a period sufficient to capture a packet, or time out and move on. Such a scheme would likely be the best.

Also complicating the matter is that I need to sleep the wixel in between the 5 minute “dead time” to conserve power.

The device is a small sensor device that transmits to a receiver device that does NOT miss packets. Unfortunately the receiver device is very limited in the types of data it is presenting when it processes the raw signal data into inferred values, and I am wishing to capture the sensor device data and use it in another application to get a richer inferred data set.

Essentially, I want to duplicate the efficacy of the proprietary receiver device at capturing packets using the wixel, so I can analyse and process the data in a different application, via another communications method. Essentially a bridge device.
Thanks again.