On Sep 13, 2006, at 9:22 AM, David Moss wrote:
I am in the final stages of implementing a CC2420 low power
listening library for TinyOS 2.x. I'm not intending it to be
compliant with any kind of standard; instead, I want it to be
functional. This does not require long preambles, and does not
require peer-to-peer synchronization.
Initial results on a tmote indicate 5.09 mAh/day at 2-second
receive check intervals. This will probably get lower.
Since it's not quite finished and I'm not sure if/when I'll
contribute it, I'll explain how I have implemented this in case you
want to try it yourself:
Summary: On the Rx end, it's a periodic channel energy check. On
the Tx end, it's a repetitively transmitting message.
1. Edited CC2420TransmitP to provide a "CC2420Cca" interface that
allows external components to sample the status of the CCA pin when
the radio is on and not doing anything. The "getCca()" command
simply verifies the state is good to go, then sets the backoff
timer to the CC2420_BACKOFF_PERIOD. The backoff timer fires,
ensuring the Rx mode has been set for enough symbol periods for the
CCA pin to be valid, and then sends back the reading in an event.
2. Built a CC2420DutyCycle component that duty cycles the CC2420
radio on and off. After the radio turns on, the CCA is checked
three times in a row. If one of these checks indicates that the
channel is *not* clear, then someone is transmitting. The radio is
left on indefinitely at this level, only to be turned back off
again by higher levels of this architecture after packets are done
receiving. If nobody is transmitting, turn the radio off
immediately. Total time the radio is on (in the current version):
3.7 ms from start to finish, but most of that time is spent at a
lower power (<5mA) starting up the radio.
3. Built a low power listening module that provides send/receive
interfaces and sits on top of the duty cycling component. When low
power listening is enabled, the duty cycling is turned on. When a
message is detected and received at this level, the message is
passed up to the application level and leaves the radio on for a
brief period of time in case other messages are coming. If this
time expires, the radio turns off and continues duty cycling.
Ideally, an ack is returned as well.
On the transmitting end, the send event in this LPL module actually
retransmits the message over and over again up to the length of the
duty cycle period, and adjusts the backoff period to be very short
so there is not much space between messages. If an ack is heard,
it quits transmitting early (an advantage over the long preamble
method!) and signals sendDone. Otherwise, sendDone gets signaled
after the duty period expires.
There you have it, low power CC2420 duty cycling, very similar to
CC1000's BMAC.
The new TinyOS 2.x CC1000 low power listening does energy checks on
the channel as well, instead of preamble checks, only firing up the
bias of the radio and leaving the rest of the radio off. This
receive check ("RSSI Pulse Check") scheme does not require long
preambles if your message (with short preambles) is being sent over
and over again for a full receive period. By sending repeating
messages, you can also cut the transmission length short if you
receive an ack in the middle, saving on Tx energy and decreasing
transmission latency. I've tested this.
-david
This is very cool. Once you feel comfortable with its stability, it's
definitely something that the 2.x core release could benefit from.
Let me know if that's something you're interested in pursuing.
I think that there's a lot of agreement in the community that this is
a really critical thing to have. There are two papers in SenSys that
propose different LPL approaches with the CC2420.
X-MAC, from CU Boulder, uses channel polling, but rather than just
sending a long preamble, the transmitter sends very short packets; as
soon as one is acknowledged by the recipient (showing that it is on),
the transmitter sends the full length packet. They have a tech report
online:
http://www.cs.colorado.edu/department/publications/reports/docs/CU-
CS-1008-06.pdf
The second is SCP-MAC, from USC/ISI. SCP-MAC uses loose time
synchronization based on preamble sampling in order to decide when to
start sending a preamble. So rather than send a really long preamble,
you send a much shorter one and start doing so a little bit before
you expect the receiver to sample the channel:
http://www.isi.edu/~johnh/PAPERS/Ye05a.html
Note that both of these are earlier (tech report) versions of the
papers; the final papers may have different results, evaluation, etc.
Go to SenSys to hear the talks, it's good for your soul, etc.
One of the goals in TinyOS 2.x is to have well defined interfaces and
abstractions; with such a stable ground in place, it becomes easier
to perform comparative evaluation (assuming that systems follow
TEPs). It would be great to take these three approaches and evaluate
them side-by-side.
Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
