I have a project that uses two wixels. One of the wixels (the slave) has a switched power supply. The other wixel (the master) has a continious power supply. Each wixel, when powered up, broadcasts it’s own ID 2X a second. Think of it as a ping or a beacon signal.
When the master wixel powers up it looks to see if another wixel (the slave) is powered up and sending it’s ping message. If the master senses the slave is powered up, it staus awake… However, if the slave is powered down the master will sense that the slave is no longer present, and after 10 seconds the master will go to sleep to conserve power.
The master can be woken up again by a pin interrrupt, and that works fine. The problem is that after being woke up it is not always able to read the ping message being transmitted by the slave, so it goes back to sleep again…
So it sort of goes like this…
- Master and Slave get powered up and are connected and working properly.
- The Slave gets powered down.
- The Master no longer senses the Slave is running and goes to sleep.
- The Slave gets powered up and is running. The Master is still sleeping.
- The Master is woken up by a pin interrupt.
- The Master, for some reason, does not see the ping messages being transmitted by the Slave (*This is where the design fails)
- Because the Master, after being woken up, does not re-connect with the Slave, it goes right back to sleep…
If both wixels are on the same Radio channel how can they not see eachothers messages once they are activated?
Now the worst part is it does not do this 100% of the time. Often the Master is woken up and it works just fine.
Radio is a very unreliable medium, due to many sorts of noise. You simply can’t expect a “few” signals (like a ping or a beacon) to get through 100% of the time. All reliable methods of radio communication rely on multiple transmissions or error-correcting protocols.
How far apart are your wixels? The orientation also matters – are the antenna portions parallel to each other?
Of course, there may be other problems with your approach, which isn’t described in any detail.
The Wixels are about 5 feet apart but do sit behind some plastic covers. The program does message protocol checks and was based (loosely now) on I/O example app. I’m quite sure the problem is not due to a few signals getting lost here and there based on how it works. It’s as if it has a complete loss of link between the two wixels and it also seems related to me putting one of them to sleep and rewaking it.
I guess I’m trying to understand if I should be re-initializing the radio when it wakes up? or if there is some type of syrconization clock involved in maintaining the radio connection… One thing I know for sure is that once they seem to loose radio connection, no meaasges get through at all. It’s as if the radio is dead. But when it’s working, it works perfectly.
Unless you describe your approach in some detail, it seems unlikely that anyone will be able to help figure out what is wrong.
As far as I understand the radio portion of the CC2511, the only error checking is packet based (protocol, sync word, checksum, etc.) and so the concept of “link” must be defined in your software. Perhaps if you simplified the procedure to just detect valid packets, that will help you figure out what is wrong with the link (and wakeup). In fact, it would probably be useful to know if invalid packets have arrived.
Actually the few responses you have made are being very helpful. My use of the term “link” is a really just a poor choice of a word on my part it seems. Which changes my whole thinking on where to look for the problem.
For some reason I thought there had to be some sort of synchronization or something between two wixels for them to be able to communicate. If I read your comments correctly the way it works is more like the following…
- Wixels are set to a specific radio frequency
- The radio itself has no links, clocks, or synchronization taking place between the wixels
- The success (or failure) of message packets being Transmitted and Received properly is limited to the quality of radio signal and in the message (packet) protocol being used.
That alone has made me think of things I can do to try and narrow in on the issue…
OK. So I’m still confused… In this thread I’m told the Wixels do not have a “LINK” that gets established. Yet we have an example app called “test_radio_link app”
/** test_radio_link app:
This app lets you test the radio_link library. This app is mainly intended for
people who are debugging the library.
And in the “test_radio_signal_rx app” it says this…
- The average Link Quality Indicator (LQI) of the packets received. According to
the CC2511F32 datasheet, the LQI is a metric of the quality of the received signal.
“LQI is best used as a relative measurement of link quality (a high value indicates
a better link than what a low value does), since the value is dependent on the
So I’m still trying to figure out of these devices develop a “Link” or not? The reason why I ask this is because my app appears to be loosing the radio link for an unknown reason… They simply stop responding to eachother… If I power cycle either of the two wixels the link is established again immediatly. And as time goes on, at some point they will simply stop working again?
It could be a buffer getting full for all I know. What I was hoping to do was to see if there was a way for me to test if the radio link between the wixels is OK and set an LED light to indicate that. But I cannot seem to get an answer to if there IS a link or not…
The only thing the Wixel’s radio module really knows about is individual packets; it does not really have the concept of a link. That is something we can build in software.
The word “link” in the radio_link library is a reference to the “link” layer in the OSI model. The word “link” in the datasheet is different; the LQI register just contains information about the last packet that was received.
Is it possible that your devices are getting into some state where they each happen to transmit packets at the same time, so they can never receive a packet from the other? I have seen that happen before when I powered up two Wixels that were running identical programs and the random number generator was not seeded using the Wixel’s serial number.
Always nice to get your input. You explain things in a way that I can understand. Fact is both wixels ARE actually running the exact same program. They use a parameter to tell which one should act as the master and which is the slave. But that said, they are actually both transmitting on the same delay cycle (20ms). I could simply change that so one is staggared to the other…
Moving on to buffers. is it possible that the RX or TX buffers are loading up? Is there a way to manage check the state of these buffers? Maybe I should run a loop that processes all the packets in the buffer every time to ensure they stay empty…
Hello, Tim. The RX and TX buffers are maintained by whatever radio libraries you are using. I am not sure if you are using radio_link or radio_queue, but each of those has functions that will tell you if there are any free TX packet buffers or any RX packet buffers ready to be processed. The libraries are documented here:
Do you have an oscilloscope available? The Wixel radio module has some debug signals you can enable to get more information about what is happening.
Not sure if your having the same issue, but I notice in my application that static charges will stop a wixel from working. They seem to be somewhat sensitive. I’ve had one stop when I tried to measure an output with a voltmeter. I was not physically touching the wixel. I’m in Las Vegas where the humidity is usually very low so this happens to me often. I should be grounded but that’s not always possible. A power cycle is required to bring the wixel back online. That’s what you said you had to do, which is what made me think that maybe you might be having a similar issue.