Difference between revisions of "CC1100/CC2500 Known Issues"
(→Low Power Communications) |
m |
||
| (One intermediate revision by one other user not shown) | |||
| Line 6: | Line 6: | ||
1. The range is significantly decreased. This could be due to the extremely short receive check. We should try increasing the length of a receive check to see if that solves the range problem. | 1. The range is significantly decreased. This could be due to the extremely short receive check. We should try increasing the length of a receive check to see if that solves the range problem. | ||
2. The radio sometimes goes into WoR mode waiting for a packet to be received sometime in the future, only to never come out of WoR mode. I see with a logic analyzer that the radio does, in fact, say it's in WoR mode. But when the next packet is transmitted, the microcontroller is not notified of a receive event. Without the radio doing its job, how is the microcontroller supposed to know something is wrong? This could be related to the length of that receive check. This issue occurs very intermittently. I tried to add a kick timer to WoR to give the radio a kick every once-in-awhile, and that seemed to work with limited success. | 2. The radio sometimes goes into WoR mode waiting for a packet to be received sometime in the future, only to never come out of WoR mode. I see with a logic analyzer that the radio does, in fact, say it's in WoR mode. But when the next packet is transmitted, the microcontroller is not notified of a receive event. Without the radio doing its job, how is the microcontroller supposed to know something is wrong? This could be related to the length of that receive check. This issue occurs very intermittently. I tried to add a kick timer to WoR to give the radio a kick every once-in-awhile, and that seemed to work with limited success. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Compile Order == | == Compile Order == | ||
| Line 42: | Line 37: | ||
If you're going to do a dual-radio platform, don't try to operate both radios simultaneously. One possibility is to simply turn both radios off at boot through manual SPI bus commands. | If you're going to do a dual-radio platform, don't try to operate both radios simultaneously. One possibility is to simply turn both radios off at boot through manual SPI bus commands. | ||
| + | |||
| + | [[Category:CC1100-CC1101-CC2500]] | ||
Latest revision as of 04:22, 23 November 2009
Low Power Communications
Wake-on Radio
Wake-on Radio has some reliability issues: 1. The range is significantly decreased. This could be due to the extremely short receive check. We should try increasing the length of a receive check to see if that solves the range problem. 2. The radio sometimes goes into WoR mode waiting for a packet to be received sometime in the future, only to never come out of WoR mode. I see with a logic analyzer that the radio does, in fact, say it's in WoR mode. But when the next packet is transmitted, the microcontroller is not notified of a receive event. Without the radio doing its job, how is the microcontroller supposed to know something is wrong? This could be related to the length of that receive check. This issue occurs very intermittently. I tried to add a kick timer to WoR to give the radio a kick every once-in-awhile, and that seemed to work with limited success.
Compile Order
You need to reference the CC1100.h / CC2500.h / CC1100ControlC / CC2500ControlC files before adding BlazeC to the compile mix. The CC*00.h files define the size of arrays within the Blaze radio stack. Not having those definitions setup before compiling in BlazeC causes lots of problems, and you won't be able to turn on your radio.
Typically, ActiveMessageC should be responsible for pulling in files in the correct order.
Note that compiling in the CC1100ControlC or CC1100.h file is enough to give your platform CC1100 capabilities. Similarly, compiling in the CC2500ControlC or CC2500.h file will give your platform CC2500 capabilities. Your ActiveMessageC file just needs to reference one or both of those CC*00ControlC files to tell the radio stack which radio types it has attached.
Bad Crc?
Problem: I have a sender node running the RadioCountsToLEDs app and a receiver node running the BaseStation App. I also have it setup to toggle LED2 if a bad CRC is detected as I did yesterday. It flashes receive LED1 for sometime but after awhile the receiver node starts flashing the LED2 instead of the receive LED1. I can fix the problem by pressing the reset button on the sender node and it will go back into normal routine but start over from count 0 obviously.
Solution: For MSP430 platforms, enable DMA on the SPI bus talking to the radio. This is done by adding a command to your Makefile:
CFLAGS+=-DENABLE_SPI0_DMA
If your SPI bus isn't fast enough, you'll be transmitting corrupted packets.
Dual-Radio Platforms
You cannot have two radios turned on at the same time on a single platform. The logic may work, but you won't have much luck sending or receiving packets. This is because the two crystals driving the signal on the two separate radios interfere with each other on a platform with a single power supply.
Our dual-radio platforms currently use FET's to physically turn the radios on and off. The SPI bus lines are also buffered to prevent the radio from being powered through the SPI bus.
Finally, the radio stack will only handle one radio turned on at a time anyway. The SplitControlManager prevents you from turning on two radios at once. There is a lot of overhead, RAM- and ROM-wise, required to operate both radios simultaneously, so we explicitly don't support it.
If you're going to do a dual-radio platform, don't try to operate both radios simultaneously. One possibility is to simply turn both radios off at boot through manual SPI bus commands.
