[Tinyos-help] LPL on Telos

cristiano cristian.dealti at saee.com
Wed Sep 28 00:00:24 PDT 2005


I don't know the reason. I feel sometimes discouraged in seeing I'm the only
one interested in LPL on telos. I think LPL is difficult on telos due to the
different radio interface that doesn't let you format abitrary frames like
in mica2.
I also think that low duty cycle operations on this new platform should be 
better
achived through scheduled approachs like S-MAC, or beacon mode of Zigbee
instead of preamble sampling techniques. S-MAC hasn't been ported yet to
telos motes and Zigbee-like beacon enabled networks are a dream.
Anyway, again about LPL i tried out a different approch before the one 
described. Following a
presentation slide by Chipcon i filled out TXFIFO with a SHR.

0x00, 0x00, 0x00, 0x00, 0xA7, 0x00, 0x00, 0x00, 0x00, 0xA7, 0x00, 0x00,
0x00, 0x00, 0xA7, ...

When the mote wakes up it is able to detect SFD very quicky. The main
problem in this approach is that after expired the check inteval the
transmitter is forced to stop transmission of  SHRs in order to fill the
FIFO with actual message so opening a contention interval.
Do you think that this approach is feasible?
The actual sequence I used is:
0x00, 0x00, 0x00, 0x00, 0xA7, 0x01, 0x00, 0x00, 0x00, 0x00, 0xA7, 0x01
Are you interested in knowing why?
OK that's all my knowledge inside this matter. I hope to listen to other
contributions.

I my prior posting:
"It has to wait at least twice the buffer duration to be sure to catch at
least one frame."
should be read:
It has to wait at least twice the sequence duration to be sure to catch at
least one frame."




----- Original Message ----- 
From: "henri dubois-ferriere" <henridf at gmail.com>
To: "cristiano" <cristian.dealti at saee.com>
Sent: Wednesday, September 28, 2005 12:43 AM
Subject: Re: [Tinyos-help] LPL on Telos


sorry for the basic question -- any idea how come so "few" people are
interested in LPL on telos? what do people do for deployments on
batteries?

thanks
henri

On 27/09/05, cristiano <cristian.dealti at saee.com> wrote:
>
> Hi,
> To those (few) interested in Low Power Listening on telos. I followed the
> hint by Joe Polastre about a LPL implementation on telos platform.
> I first set TX_MODE = 2 which lets you send TXFIFO contents cyclically.
> When
> you issue a TXON (or TXONCCA) strobe the
> radio first inserts automatically a SHR like in TX_MODE = 0 (the default
> transmission mode) and then TXFIFO contents (128 bytes)
> are sent. No processing (I believe) is done by CC2420 on TXFIFO contents.
> In
> particular no FCS is computed and added at the end.
> When the 128th byte of TXFIFO has gone the process restarts itself by
> sending the first byte in the FIFO.
> I write to TXFIFO a 128 byte buffer made by repeating twice the sequence:
>
> 21                                    /* 802.15.4 length */
> CC2420_DEF_FCF_HI, CC2420_DEF_FCF_LO, 0, TOS_BCAST_ADDR, 0xFFFF, 0x0A,
> 0x7D,
> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,    /* A message */
> FCS,                                    /* Computed-by-me FCS */
> 0x00, ...,
> 0x00, 0x00, 0x00, 0x00, 0xA7    /* A synchronization header */
>
> whose length is 64 byte.
> The initial part of the sequence is a 802.15.4 compliant frame. The FCS is
> computed on MAC header and MAC payload. FCS is not
> computed and inserted automatically by CC2420 in TX_MODE = 2 test mode.
> Then many 0s are written to the sequence and finally a SHR is appended.
> I set one node to periodically send this sequence for 200 ms (+20%).
> Another
> node is programmed to wake up every 200 ms to
> listen to the channel.
> This node first performs a CCA. If CCA is successful it stays on and waits
> to receive a frame otherwise it goes back to sleep.
> It has to wait at least twice the buffer duration to be sure to catch at
> least one frame.
> I succeded in this experiment, the frames are correctly received by the
> sleeping node.
> There are, as far as I can see, two major problems:
> 1) A test mode is used. Maybe this test mode won't be available in future
> steps of the chip.
> 2) Since the sleeping node starts listening at a random point of the
> incoming bit stream and a SHR can be present as part of the
> frame e.g. in the data field of the frame, a false start of frame
> detection
> may occur. A stuffing/encoding mechanism would be needed
> at least to escape the SFD.
>
> Any comments and suggestions are greatly welcome.
>
> Cristiano De Alti
> SAEE s.r.l.
> Amaro, Udine, Italy
> _______________________________________________
> Tinyos-help mailing list
> Tinyos-help at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
>
>



More information about the Tinyos-help mailing list