I have written a “simple” application that uses radio_network by Carlo Bernaschina. The application, generally speaking, is composed by:
- a transmitter that samples data (sampling frequency 6kHz) and send them with a random delay choosen between 1 and 15 ms.
- a receiver that convert data in hex format and send them to a PC via USB.
The problem is that I am working with 13 different wixels and with 6 of them the radio transmission is very much slower and irregular than with the other 7 wixels.
Does anyone have similar problems? Maybe an hardware bug? I’m pretty sure that radio_network by Carlo Bernaschina works correctly… otherwise I can’t explain why the application works very well on 7 wixels and why it doesn’t work on other 6.
By the way, three of the 6 wixels that don’t work are totally new: I received them this morning from exp-tech.de
I checked the system also using radio_queue protocol and the result is the same, so I may exclude problems with Carlo’s protocol.
Hello. I am sorry you are having trouble with your Wixels. Could you please post the serial numbers of your Wixels? Also, please indicate which Wixel is being used as the receiver, which Wixels are properly-working transmitters, and which Wixels are poorly-performing transmitters.
Here they are:
Not working wixels
I can also send you the application for testing.
Thanks a lot, Wixels are part of my MSc thesis
I believe your problem is caused by manufacturing variations in the Wixels. The Wixels you have are from three manufacturing periods, in which we changed crystals. I’ll call them phases to make them easier to talk about:
Phase 2 Wixels (March 2012 to September 2013):
Phase 3 Wixels (September 2013 to October 2014):
Phase 4 Wixels (October 2014 to present):
The clocks on phase 2 Wixels tended to run a little fast, and this was improved in phase 3 and improved more in phase 4. However, phase 4 clocks tend to be a few ppm lower than nominal, so the frequency difference is most pronounced between phase 2 and phase 4 Wixels. What we have seen is that while phase 2 Wixels work with phase 3 Wixels, and phase 3 Wixels work with phase 4 Wixels, phase 4 Wixels have trouble communicating with phase 2 Wixels.
You didn’t say which Wixel you are using as the receiver, but I suspect it is one of the phase 2 Wixels because every phase 4 Wixel is performing poorly for you. Is it feasible for you to try using one of the phase 3 Wixels as the receiver? Please let us know if that resolves your issue. If that does not work for you, we can also try changing the tuning in firmware.
I did some tests and I found that Wixels of phases 2 and 3 can communicate each other very well, while Wixels belonging to phase 4 can speak efficiently only with Wixels within the same phase.
By the way, my teacher asks if it is possible to replace crystals (and if it is the only change needed) in order to uniform behavior of wixels.
Changing the crystal or the two capacitors next to the crystal might help solve this problem, but I do not recommend doing this yet. There is something else we can try which should be much easier.
The radio receiver in the CC2511F32 has a frequency offset compensator that helps adjust the receiver when it is receiving a packet with a different frequency than it was expecting. The settings we currently supply in the Wixel SDK limit the range of this compensation to plus or minus 75 kHz, but if we increase it to be larger than about 100 kHz, then that should be enough for all the different phases of Wixels to communicate. I recommend increasing it to 300 kHz.
In your copy of the Wixel SDK, in libraries/src/radio_registers/radio_registers.c, please find the line that says:
FOCCFG = 0x1D;
Please change that line so it says:
FOCCFG = 0x1F;
This change should not affect the transmitters. Can you apply this change to your receiver and let me know if that makes the Wixels perform better?
Thank you, David. I will do this test ASAP, since actually I’ve another problem to deal with… and for this reason I open another post