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

Wixel radio communication


I need bi-directional radio link between two wixel devices. I have already already adapted the wireless_serial app and it has been working “somehow”. Unfortunatelly there are some problems like the java client app stops sending the data and I don’t know where is the problem. Lately I found out it can by somehow connected with delay between each transmision so it can be that if I’m to quick the remote wixel receives wrong data and get’s crazy. So anyway I need to rewrite it to make it more reliable.

In this case I don’t want to use the example wireless serial app anymore as I was unable to make it work reliable. I found there is library radio_link. But to be able to use it I cannot use the wireless_serial app anymore on the usb connected wixel. So I will need to write my own app on both wixels.

The problem is I’m kind of lost in all this communication possibilities. There is also radio_com that is implementation of some streaming communication for example for tilt-mouse app(stream of bytes between two devices), but than it sends some buffer.

So the main question which library should I use to be able to send packets half-duplex way. Does these libraries support some CRC check or can I still receive wrong data? Which examples to look in.

Thanks for answer


You shouldn’t need to “adapt” the wireless serial app, as it behaves much like a wired serial connection between two devices. Like a wired connection, you have to send and receive data at the appropriate rate, when data are actually available and sender and receiver are ready, or it won’t work properly. If you need to make the sender wait until the receiver is ready, use the provided DTR, RTS, DSR, and CD signal lines.

From the wireless serial app documentation:


Data will be lost if the Wixel receives bytes on the RX line faster than the radio can convey them to the other Wixel. If you have trouble, try reducing the amount of data sent to the RX line by lowering the baud rate or adding delays to your microcontroller’s code.[/quote]


Hello. In contrast to the RX/TX lines, the wireless_serial app’s USB interface (provided by the usb_cdc_acm library) and the radio interface (provided by the radio_link) library both have flow control and buffers built in, so there should not be a problem with sending data too fast through those interfaces.

You said that your Java client app stops sending the data. You might have experienced a situation where the Wixel’s USB receive buffers got filled up, so the USB virtual COM port TX buffers on the computer filled up, so that all writes to the COM port had to block indefinitely. I don’t know what would the root cause was though. The Wixel’s wireless_serial app is supposed to be reliable and if there is some bug in it then we want to fix it. It would be very useful if you could make the bug happen faster, then reduce the system to the simplest possible system that reproduces the bug, and describe the situation in detail to us.

The three main libraries for writing a wireless app with the Wixel are radio_link, radio_com, and radio_queue. All of those use the CRC feature of the CC2511’s radio, so you should not receive bad data.



Thanks for answer, seems the next version built on radio_link library is working well. But I found something strange, I’m using LED_GREEN(1); in the code to show same state change. There is strange behavior when the usb is connected the green LED is working when usb is not pluged in it doesn’t work I checked the voltages when on battery, but it seams to be ok. What should be the cause, is there any behavior connected with USB??. I’m using these libraries:
#include <servo.h>
#include <cc2511_map.h>
#include <wixel.h>
#include <usb.h>
#include <usb_com.h>
#include <radio_link.h>
#include <random.h>
#include <stdio.h>
#include <uart1.h>
#include <math.h>


The Wixel’s green LED is wired so that it can only turn on when USB is connected; it is powered from USB. This design allows us to use one pin to check for USB power and to control the LED.



Thanks for explanation. I lately realized some complication with power supply. Let say I’m using motor(9V), servo(6V) and wixel logic voltage(let say 3.3) and battery 9V. Before I used linear regulator to convert to 5V(I had this one by hand) and wixel was satisfied, servo worked and brushed motor have been happily working. But I’d like to make it some how more “professional”.

How to do it, how to get let say three voltages from i.e. 9V battery? Current divider is easiest one, but not very reliable. Using more linear regulators with different power output?? Linears are probably taking lot of battery power, because of this they have the heat-sink attached, haven’t they? I found out there are different kind of regulator “switched” one. But still I will need more of them:-/

Or is it enough to have one regulator for wixel to get logic level and the rest just supply through current divider? Servo and motor are I suppose not so sensitive.

Any hint appreciated.

Thanks in beforehand




As stated in the announcement at the top of this forum, 9V batteries are not generally strong enough to drive motors. You will probably need something that can supply more current. If you want to get up to 9V, you could use 6 Alkaline AA batteries.

You don’t need to get three different voltages from the battery if you just power the Wixel using the VIN line, which can take voltages as high as 6.5 V.

I would probably power the motor directly off of the battery voltage and then find an appropriate regulator for the servos and Wixel that can produce 5 V or 6 V from the battery power. To choose a regulator, you will need to know the range of voltages going into it (which might be approximately 9 V for you), the desired voltage you want to get out of it (5-6 V), and the amount of current you will be drawing from the regulator. The Wixel will only take about 30 mA so the current draw will be dominated by your servo. A good rule of thumb is to have 1 A per servo. A bigger, more powerful servo would require more current. Once you know these three requirements, you should be able to select an appropriate step-down regulator from our website.