View source for CC1100/CC2500 Recent Updates

'''Status: OPERATIONAL'''

== July 10, 2008 ==
* Created an rssi directory containing Ccxx00RssiC/P.  This provides the Read<uint8_t> interface.  You must access it directly from your application layer because it is not pulled into the radio stack by default.

== July 7, 2008 ==
* Created a Ccxx00PlatformInitC component to power down all radios on startup.  You cannot have multiple radios operating on the same platform at the same time, due to crystal interferences.  Previously, we used hardware FET's to physically turn off radios that are not in use, and only have one radio on at a time.  By powering them all down before boot, we don't have interference and can automatically save energy for applications that never use the radio.

== May 8, 2008 ==
* Found range issues with WoR, possibly related to the length of the receive check on the radio. Also found that the radio sometimes goes into WoR mode, but doesn't do its job of receiving a packet.  These wake-on radio issues will have to be dealt with later.
* Added a BMAC implementation, which keeps the same transmit functionality as WoR, but places the receive check under the control of the microcontroller.  Found that the radio chip does not notify the microcontroller that there is activity on the channel, even though I have a transmitter nearby.  This long preamble transmission detection needs to be solved for BMAC to finish getting debugged.
* Added an XMAC implementation to get something reliable.  The receive check is really bad, since the radio has to stay awake for 20-25 ms.  However, since XMAC is not what we'll be using in the future, I'm not too concerned about the poor receive check.  I just want reliability at this point, and some radio duty cycling. XMAC is currently the preferred low power communications method since WoR and BMAC need more testing.
* Fixed a lock-up problem in BlazeTransmitP where the RxIo line is always high but the receive branch is not downloading the RXFIFO contents.  The transmit branch may flush out the RXFIFO on overflow if the receive branch isn't doing its job, which gives the receive branch a kick on the next RxInterrupt event.  
* Changed the SplitControl architecture with LPL to place LPL inline with SplitControl's start() and stop() commands.  This breaks the former WoR implementation as it exists now (since WoR had the LPL plug-in under the control of the Ccxx00PowerManagerP module), but allows BMAC and XMAC to work.

== April 14, 2008 ==

* Added LinkPacketMetadata for CTP
* Fixed the non-WoR transmitter lock up issue by toggling CSN before and after disableWor().
* Updated some SRX while loops to test for SIDLE state, and only strobe SRX. Really no effect.
* Attempted MCSM0 = 0x3C and 0x2C with no luck.  0x1C it is.
* FIXED WOR ACKNOWLEDGMENTS by disabling the WoR RC oscillator and putting WoR into power down mode in the transmit branch.
* Added the same WoR power down toggles in WorP's SRX while() loop, this needs to be evaluated to see if the CC2500 WoR power down issue persists
* Enforce the acknowledgment gap on receive.  It improves ack success rate by a small amount.  Added a WoR kick timer.
* Transmit: added a check in the TX packet transmission state for an RxIo line, which gives the receive branch priority and increases ack success rate in edge cases where the CSMA backoff occurs at the same time the RxInterrupt fires. The Tx aborts and the Rx branch receives the packet and acks.
* Removed hardware address recognition in the CC2500/CC1100 header and control files. This was causing non-destination nodes to jump in and start transmitting right away, causing acknowledgment collisions or delayed acknowledgments. Every node now receives every packet, and filters the packet strictly in software.
* Added SFRX and SFTX commands after SIDLE strobe in WoR. Not sure if this has any effect.
* Made the alarm generic, which may have increased code size.  We should evaluate whether or not this was a wise decision given that acknowledgments seem to work fairly well with long preamble transmissions.
* Added a progressive congestion backoff. Increased the transmit duration for a WoR packet.
* Wrap PaReg.write()'s with Csn.clr() / Csn.set().


== March 27, 2008 ==
* Fixed a WoR bug: Do not change WoR settings if the SPI bus cannot be granted immediately. Other parts of the system are obviously in use.  This fixes the acknowledgment + wor problem.
* Increased the CSMA minimum backoff to 20. This should be re-evaluated after extended backoffs are implemented.
* Removed the software CRC footer hidden from the application layer, found by reading SPI bytes as they were unloaded from the RX FIFO.
* Tried to calibrate every 4th time, but that broke things. So that setting stayed the same.
* Retransmit an acknowledgment 3 times. The first time, transmit it right away, especially if the radio is not IDLE.  For the 2nd and 3rd retransmits, force the radio into IDLE mode before the transmit, which causes calibration and improves acknowledgment reception performance for some reason.
* Increased the ACK wait period to 400, improving ack reception performance, but degrading throughput.
* Removed useless information in Lpl.h
* Added comments about the do-while() in BlazeTransmitP, so I don't try to remove it again.
* Changed FIFO_THR to 0xE, meaning it won't get triggered until the packet is fully received
* Set the CSN back high before passing it on to AckSend in AckSend.sendDone().
* Wrap PaReg.write()'s with Csn.clr() / Csn.set().
* Added a progressive congestion backoff.
* Increased the transmit duration for a WoR packet to 5 ms instead of 3 ms

== February 26, 2008 ==
''Updates''
* I am continuing to port unit tests over from the former alpha version.
* Built a randomized radio stimulation application that will toggle radios on and off, send to different radios, sit idle on radios for a short period of time, etc. to help test for any remaining lock up issues, especially on dual-radio platforms.  No issues to report.

== February 20, 2008 ==
''Updates''
* Found a bug in BlazeTransmitP and WorP in a while-loop meant to guarantee RX mode. It wasn't handling the BLAZE_S_SETTLING state. The radio would calibrate for awhile, then enter a settling state just before going into RX mode. The while-loop, not handling the SETTLING state, would try to put the radio into RX mode again from scratch.  The next command the uC would send is a SIDLE strobe, during which the radio replies "BLAZE_S_RX".  So RX mode was canceled, and the whole thing would cycle through again.. and again.. infinitely.
* The same bug applied to BlazeReceiveP when trying to force the radio into RX mode. Fixed it.

== February 19, 2008 ==
''Updates''
* Experienced a lock-up overnight with the duty cycling WoR-enabled full throughput transceivers.  Upon power cycling the locked up node this morning, the other node locked up as well.  I put my hand near the other node and it continued executing code for a moment before locking up again.  Temperature issue maybe?
* Removed InterruptState files from /spi

== February 18, 2008 ==
''Updates''
* Setup two WoR-enabled full throughput transceivers with ack requests.
** Solved the lock-up problem by fixing the RX while-loop in BlazeTransmitP.  Not sure what the problem was, so my lack of knowing what's going on may mean there's a better solution.  But this works.
* Setup two duty cycling WoR-enabled full throughput transceivers with ack requests; no lock-ups.
* Removed CyclicBlazeTransmitP from /ccxx00/transmit

== February 15, 2008 ==
''Updates''
* Found a bug in TinyOS's BaseStation application where the FCF byte is corrupted by the serial stack.
* Discovered 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.
* Changed some of the architecture of the Ccxx00PowerManagerP to allow components to be turned on in a different order than how they're turned off.
* Placed Lpl under the control of the Ccxx00PowerManagerP component, instead of inline in the radio stack.
* Removed SubControl interfaces from Lpl.
* Added RxInterrupt into WorP to let it know when WoR has been disabled by a receive
* Nodes lock up when transmitting and receiving LPL/WoR messages.  It appears that WoR is enabled somehow when the node attempts to transmit, and the lock up only occurs after receiving a packet.

== February 14, 2008 ==
''Updates''
* Initial results are in: 250 ms receive check intervals results in ~5.1 mAh/day consumption, 100% reliability. Don't quote this as the final value though, I expect it to drop lower after another test or two.
* Experimented with Event1=0x0 and Event1=0x7. Both detected the transmitter just fine, but surprisingly the 0x7 value was more energy efficient.
* Built unit tests for LPL to test toggling SplitControl and LowPowerListening.setLocalSleepInterval(...) at various times.  All tests pass.
* Found a bug in BlazeReceiveP where a filtered packet will cause the receive branch to stop receiving more packets.
* Shortened the destpan field to a uint8_t, which is the size of the standard am_group_t defined in AM.h
* Changed the behavior of both GDO2 and GDO0.
** GDO0 is now the RX interrupt
** GDO2 is now the CHIP_RDY indicator
* Removed Gdo0_io, Gdo2_io, Csn, and Power connections into CC1100ControlP and CC2500ControlP, since they were never used.
* Found that it's necessary to check if CHIP_RDY before interacting with it when coming out of WoR.

== February 7, 2008 ==
''Status''
* '''OPERATIONAL''': Working on WoR

''Updates''
* Call BlazeCommmit.commit() in a task to get out of async context with ActiveMessageAddress.changed()

''Tests''
*

== February 6, 2008 ==
''Status''
* '''OPERATIONAL''': Working on WoR / Frequencies

''Updates''
* Committed a few compile errors fixes

''Tests''
*

== February 5, 2008 ==
''Status''
* '''OPERATIONAL''': Working on WoR

''Updates''
* Got WoR to duty cycle this morning.  Need to perform power measurements
* Renamed the CCxx00's PowerManagerC/P component to Ccxx00PowerManagerC/P to avoid naming conflicts with the PowerManagerP component provided in the ATmega128 uC driver.
* Created a CyclicBlazeTransmitP module for transmitting a stream of packets during the wake up period instead of just a preamble.
* Created an RxNotify interface to notify of reception regardless of whether or not the packet was valid
* Connected and implemented LowPowerListening - Duty Cycle % is not supported.
* Binary milliseconds not supported in LowPowerListening - use true milliseconds instead.
* Can send and receive using LowPowerListening, but more debugging is required.

''Tests''
* Verified WoR register settings
* Tested LPL/WoR Rx/Tx functionality

== February 4, 2008 ==
''Status''
* '''OPERATIONAL''': Working on WoR

''Updates''
* Carrier sense / clear channel assessment on GDO0 is operational.
* Developed a WoR interface
* Added SendNotifier to ActiveMessageC for CTP + LPL integration

''Tests''
*

== February 1, 2008 ==
''Status''
* '''OPERATIONAL''': Performing tweaks to optimize metadata, per-packet PA settings, and I'm beginning to experiment with wake-on-radio.

''Updates''
* Lockup issue report: the radio was found to be in the STXON state which the stack never strobes.  STXON is one bit off of the STX command over SPI. The radio would never enter TX mode in the forced acknowledgment transmit while-loop strobing TX. I added abort functionality to this loop with 10240 retries, which was arbitrarily chosen.
* Removed interfaces/PacketCrc.nc, interfaces/BlazeControl.nc, interfaces/PowerCycle.nc, interfaces/ReceiveController.nc, and interfaces/BlazeReceive.nc
* Added better packet filtering to BlazeReceiveP. 
* Removed the power settings constraint from BlazePacket - now you can set any power level in the metadata up to 0xFF.
* Added wiring in CsmaC/P to support future per-packet PA settings.
* Implemented per-packet PA settings in CsmaP. Note we do not check to see if Transmit is busy sending an acknowledgment before adjusting the PA.

''Tests''
*

== January 31, 2008 ==
''Status''
* '''OPERATIONAL''': I have 3 CC2500's transmitting, receiving, duty cycling power every half second, and sending acknowledgments reliably.

''Updates''
* Figure this out: I add in error code LED's around while-loops in BlazeInit, and the node doesn't lock up. I take the LED's away, and the node locks up.  Timing issue?
* I added a BusyWait.wait(1000) just after the burst init, and the MSP430 seems to regularly initialize now with no problems. Need to try this on the Atmel platform.
* Wired the SplitControlManager.Send / SubSend interface into the rest of the stack to prevent transmission attempts while the radio is off.
* Deleted the old "blazeradio" directory, which contained the prototype for the blaze radio stack.  The tinyos-2.x-contrib/blaze/tos/chips/ccxx00 directory contains the current stable, non-hacked-up version.

''Tests''
* RadioCountToLeds application, modified to duty cycle the radio and request acknowledgments.

== January 30, 2008 ==
''Status''
* '''NON-OPERATIONAL''': I want to get it operational today, then focus on Wake-on-Radio / LPL.

''Updates''
* Changed the Makefile for the apps/RadioCountToLeds to point to the new ccxx00 directory and new sub-directories.
* Got the entire CCxx00 stack to compile.
* Added a BusyWait(5000) timer to BlazeInitP.SplitControl.start() to give the radio some time to power up without having to make sure each platform complies. This helped the tmote2500 platform with manual resets. The reception rate tapers off after 10-20 seconds, which is bad.

''Tests''
* init/MultiStartStop PASSED on tmote2500 / blaze
* receive/BasicReceive PASSED on dual tmote2500's
* receive/BroadcastWithAcknowledgement PASSED on dual tmote2500's
* receive/ReceiveWithAcknowledgement PASSED on dual tmote2500's
* am/TestBroadcastWithAck PASSED on dual tmote2500's
* am/TestBroadcastWithoutAck PASSED on dual tmote2500's
* receive/AckSendReceive PASSED on dual tmote2500's
* receive/MultiAckBroadcastSendReceive PASSED on dual tmote2500's
* receive/NoAckSendReceive PASSED on dual tmote2500's

== January 29, 2008 ==
''Status''
* '''NON-OPERATIONAL''': Testing the Transmit branch, evaluating the Receive branch. Will wire everything back together soon.

''Updates''
* Truncated the FCF word to a single byte by removing implied settings like ''Source Address Mode'', ''Destination Address Mode'', ''IntraPAN settings'', etc.  Only the bit-fields contained in the first byte of the original FCF word are kept: frame type, security enabled, frame pending, ack request.
* Added long-preambles to the packet transmission functionality for future Wake-on-Radio/B-MAC implementation
* Updated the Csma component to use the latest AsyncSend interface.
* Added SplitControl functionality to the Csma component.
* Created a PowerManager component to turn power on and off to various components in the right order.
* Brought over other directories from the original ''blazeradio'', including receive, unique, link, lpl, am, etc.
* Edited the BlazeReceive component to be compatible with the latest AsyncSend interface and Transmit implementation.
* Added the AckSend interface back into BlazeTransmitP so the Receive branch won't get AckSend.sendDone() events when the transmit branch finishes every transmission.
* Modified BlazeC to pipeline SplitControl into the stack; still needs testing.

''Tests''
* Long Preamble Application created
* CsmaSendReceive
* MultiCsmaSendReceive
* MultiCsmaBroadcastSendReceive

== January 28, 2008 == 
''Status''
* '''NON-OPERATIONAL''': Working on Transmit branch.

''Updates''
* Performed a spectral analysis of the CC2500 radio, found the default channel to be 2.4269 GHz instead of the 2.44243 GHz predicted in the CC2500.h file.
* Seems as though the LNA / RSSI CS threshold is setup incorrectly, which would prevent the radio from entering Tx mode.
* Found good settings for 315 MHz that will not block the transmitter (in a quiet environment) from carrier sense: AGCCTRL2=0xDB; AGCCTRL1=0x70.  This probably decreases the range, and needs further evaluation.
* Verified 2.4 GHz RSSI thresholds.
* CC2500 AGCCTRL2=0xC7; AGCCTRL1=0x50 sets up good thresholds for the CC2500.

''Tests''
* Created a MultiTransmitApplication program to test RSSI thresholds
* Created a CC1100 & CC2500 Jammer

== January 23, 2008 == 
''Status''
* '''NON-OPERATIONAL''': Working on the SplitControl pipeline through the radio stack, while solidifying BlazeInit.

''Updates''

* Removed the Blaze development platform HplCC1100PinsP and HplCC2500PinsP, replaced them with a generic module called HplCCxx00PinsP.
* Removed the hacks from BlazeInitP after getting the dual-radio platform to pass PowerCycle testing
* '''Note''' the dual-radio platform cannot power on both radios simultaneously, even if all pins and interrupts are completely disconnected in software. Each radio must be powered on separately with FET switches.
* Removed load() and loadDone() from the AsyncSend interface.
* Modified the arguments to the AsyncSend.send interface: ''async command error_t send(void *msg, bool force, uint16_t preambleDurationMs);''
* Added 5 more bytes to the burst init sequence to include AGCCTRL1 for CCA thresholding. Trying AGCCTRL1 at 0x70 instead of 0x0 to adjust the relative RSSI threshold. 

''Tests''
* Integration PowerCycle test passed on a blaze2500 platform (10000 power cycles)
* Integration PowerCycle test passed on a blaze1100 platform (10000 power cycles)
* Created a PowerCycle application in the ccxx00/integration/dual test directory for continuous debugging.
* Integration PowerCycle test passed on the blaze dual-radio platform (20000 power cycles)
* MultiTransmit test created for new AsyncSend interface and implementation

== January 22, 2008 == 
''Status''
* '''NON-OPERATIONAL''': In a state of flux, dividing the prototype Blaze radio stack (blazeradio) into a new ccxx00 directory which will contain the final CCxx00 radio stack architecture.

''Updates''
* Updated all .platform files to point to the new ccxx00 directory
* Created a SplitControlManager component to reside just underneath the RadioSelect module. 
* Isolation unit tested the SplitControlManager.  All tests pass.
* Removed SplitControl functionality from RadioSelect module. The RadioSelect module is now entirely responsible for converting the non-parameterized Send and Receive interfaces it provides into parameterized Send and Receive interfaces it uses.
* Wired SplitControlManager into CC2500ControlP and CC1100ControlP to prevent Configuration commits to the radio registers when the radio is off.
* Removed SplitControl managing functionality from BlazeInit.
* Removed the BlazePower interface, replaced it with internal functions in BlazeInitP. The SplitControl and BlazeCommit interfaces are the only interfaces that should be interacting with the hardware. Also removed BlazePower connections from CC2500ControlC and CC1100ControlC. 


''Tests''

* Isolation test created for SplitControlManager in a new ''blaze/tos/chips/ccxx00/'' directory in TUnit:  ''blaze/tos/chips/ccxx00/isolation/SplitControlManager''.
** All tests pass.

* Integration test for BlazeInit SplitControl interface (''ccxx00/integration/cc2500/init/PowerCycle'') - duty cycle the power on and off.
** Test passed on a tmote2500 platform (10000 power cycles)

== January 21, 2008 == 

''Status''
* '''NON-OPERATIONAL''': implementing better SplitControl architecture.

''Updates''
* Reduced the number of SPI register burst init elements from 39 to 25, decreasing the time it takes for init.
* Added the RadioReset interface and HplRadioResetC/P modules to allow the driver to check the SO line to see that the radio has been automatically powered up on reset.
* Removed RfResource and PriorityQueue from the radio stack.
* Removed while-loop hack functionality in BlazeInitP - this still needs to be tested with various hardware

''Tests''
* Created AutomaticPor test to test the RadioReset interface, which I have implemented for the MSP430-based platforms

== January 20, 2008 ==

''Status''
* '''OPERATIONAL'''. Stable on the MSP430.  Full of hacks to try to get the hardware working. The radio typically refuses to go into TX mode on Atmega128 platforms.

= See Also =

* [[CC1100/CC2500|CC1100/CC2500 Radio Stack]]

[[Category:CC1100-CC1101-CC2500]]