Difference between revisions of "CC1100/CC2500 Recent Updates"

From TinyOS Wiki
Jump to: navigation, search
(→‎February 4, 2008)
(→‎February 4, 2008)
Line 1: Line 1:
 +
== February 4, 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.
 +
 +
''Tests''
 +
* Verified WoR register settings
 +
 +
 +
 
== February 4, 2008 ==
 
== February 4, 2008 ==
 
''Status''
 
''Status''

Revision as of 09:22, 5 February 2008

February 4, 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.

Tests

  • Verified WoR register settings


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

Retrieved from "http://tinyos.stanford.edu/tinyos-wiki/index.php?title=CC1100/CC2500_Recent_Updates&oldid=739"