Yeh, that's really important!I think it will be quiet useful me too!
However, about TinyAlloc, I don't understand the meaning of:
"if a single dereference is to be stored, the handle must be locked first"
How is it possible to lock something as a pointer?
if for example i need to handle a pointer to a buffer, how should i work?
and how Handle is defined?
cheers
Daniele
-----Original Message-----
From: David Moss [mailto:[EMAIL PROTECTED]
Sent: Wed 9/13/2006 6:22 PM
To: 'Diego Bartolomé Arquillo'; [EMAIL PROTECTED]
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: RE: [Tinyos-help] low power listening in tinyos-2.x for CC2420
?
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
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Diego Bartolomé Arquillo
Sent: Wednesday, September 13, 2006 8:24 AM
To: [EMAIL PROTECTED]
Cc: tinyos-help@Millennium.Berkeley.EDU
Subject: RE: [Tinyos-help] low power listening in tinyos-2.x
for CC2420 ?
Hi Avinash,
Low power listening have not sense using CC2420 because this
chip is compliant with the standard IEEE 802.15.4. This standard defines a 4
bytes preamble length and LPL needs a long preamble in order to work properly.
The CC1000 is not compliant with 802.15.4 and allows you to change the preamble
length. When you send a packet using LPL, a long preamble is transmitted. The
recipient of the packet is idle and periodically it scans the channel to look
for a packet. If the preamble and the period are adapted, the recipient can
receive the useful information of the packet.
Best regards,
Diego
_____
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de
Avinash Sridharan
Enviado el: miércoles, 13 de septiembre de 2006 2:35
Para: tos
Asunto: [Tinyos-help] low power listening in tinyos-2.x for
CC2420 ?
Hi,
I am working with the tmote sky platform and running
tinyos-2.x (beta 2) on it. I wanted to check with the community if there is low
power listening support existing for CC2420 based platforms in tinyos-2.x. Low
power listening was introduced as BMAC by Joe Polaster in tinyos-1.x for the
CC1000 chips, but I could not find reference implementations of BMAC for CC2420
in tinyOS-2.x. Also if BMAC is not available for tinyOS-2.x (atleast in the
near future) is it available as part of the Boomerang distribution.
Thanks,
Avinash
--
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
