Re: [Tinyos-help] microsecond ftsp on TelosB without cc2420x

[Janos Sallai]

The two stacks differ in how the SFD interrupts are handled on the
receiver, and in when the received packet is downloaded from the radio
chip's FIFO. The default stack saves the SFD timestamp in a queue. After
the SFD interrupt, the default stack waits until the entire packet is
received into the radio chip's FIFO buffer. Only after the entire packet
has been received does it start downloading it to a message_t structure in
the MCU's RAM. When the download of the packet is complete and the CRC is
OK, the corresponding timestamp is removed from the queue and placed in the
metadata of the message_t structure. In the default stack, FIFO download of
one packet may overlap with the reception of a subsequent packet. Of
course, if something goes wrong during reception (e.g. length byte
corrupted, bad CRC, etc.) the timestamp corresponding to the SFD event of
that particular bad message must be discarded. This timestamp might not be
at either end of the timestamp queue. Peope suspect that this what's done
wrong in the CC2420 code, because the timestamp mixup only happens under
heavy load, when the timestamp queue is "long".

The CC282X stack, on the other hand, doesn't maintain a timestamp queue. If
an SFD event occurs, it stays in interrupt context until the entire packet
is downloaded from the radio chip's FIFO buffer. The bytes are downloaded
as they are received (vs. the default stack, where the download starts
after the entire packet is received). This way, if the message reception is
complete, we can be sure that the correct timestamp is associated with the
buffer.

Janos


On Sun, Nov 18, 2012 at 9:23 PM, Xiaohui Liu  wrote:

> Hi,
>
> According to this 
> figure,
> there is definitely some bug for timestamping in the default CC2420 radio
> stack, especially under heavy load. Can you please tell me how timestamping
> is done in CC2420X and how it avoids the potential bug CC2420 stack has?
> Thanks.
>
>
> On Thu, Nov 15, 2012 at 4:00 PM, Xiaohui Liu  wrote:
>
>> Thanks.
>>
>> Anyone else wants to share some experience implementing microsecond ftsp
>> on TelosB?
>>
>> -Xiaohui Liu
>>
>> On Thu, Nov 15, 2012 at 3:49 PM, Janos Sallai <
>> janos.sal...@vanderbilt.edu> wrote:
>>
>>> You will probably have to change the clock source (change T32khz to
>>> TMicro). I'm not familiar with the code, so I can't tell you where this has
>>> to be done in the code.
>>>
>>> Also, you'll have to prevent the MCU from sleeping, because the TMicro
>>> clock stops when the mote goes to sleep.
>>>
>>> Janos
>>>
>>>
>>> On Thu, Nov 15, 2012 at 2:39 PM, Xiaohui Liu  wrote:
>>>
 Hi,

 Thanks again. Still one question in line.

 On Thu, Nov 15, 2012 at 3:35 PM, Janos Sallai <
 janos.sal...@vanderbilt.edu> wrote:

> Hi,
>
> > So essentially, ftsp only works with cc2420x stack, not cc2420.
>  The cc2420 stack has a timestamping bug, so it won't work well.
>
> > What are the changes to the default cc2420 stack if the fix is to be
> ported to it?
> I can't tell that. I found the cc2420 stack to be very complicated.
> Instead of trying to figure out how to fix the timestamping bug, I wrote a
> complete new stack from scratch.
>
> > I find something under $TOSDIR/platforms/telosa/chips/cc2420x/ and
> $TOSDIR/chips/cc2420x, but not sure which files to look at.
> The file that contains the cc2420x timestamping implementation
> is tos\chips\cc2420x\CC2420XDriverLayerP.nc.
>
>
> > Provided that the fix solves the timestamping issue, what else has
> to be changed to make microsecond ftsp work with cc2420 stack?
>  If you can fix the timestamping issue on the cc2420 stack, then FTSP
> should work correctly.
>
 32khz and millisecond ftsp should work. What about *microsecond* ftsp?
 What changes are necessary?

>
>
 > BTW, can you please also help answer my previous 
 > question
 >  related
> to timestamping?
> That question is related to the cc2420 stack, so I can't answer this.
> I more than happy to answer questions related to the cc2420x stack, 
> though.
>
> Janos
>
>
>
>
>
> On Thu, Nov 15, 2012 at 2:12 PM, Xiaohui Liu wrote:
>
>> Hi,
>>
>> So essentially, ftsp only works with cc2420x stack, not cc2420.
>>
>> What are the changes to the default cc2420 stack if the fix is to be
>> ported to it? I find something under
>> $TOSDIR/platforms/telosa/chips/cc2420x/ and $TOSDIR/chips/cc2420x, but 
>> not
>> sure which files to look at.
>>
>> Provided that the fix solves the timestamping issue, what else has to
>> be changed to make microsecond ftsp work with cc2420 stack?
>>
>> BTW, can you please also help answer my previous 
>> question

Re: [Tinyos-help] Sleeping in TKN154

[David Rodenas]

Hi Jan
I asked about switching off periodically the radio transceiver in order to plan 
a duty cycle. Then, you told me I should use the MLME_RX_ENABLE interface 
provided by the Ieee802154NonBeaconEnabledC component. Well, I've done that, I 
mean, I've set a timer which represents a wakeup interval that when it expires, 
it should activate the radio transceiver during a time interval equal to 
RxOnDuration. My problem is that I'm not really sure if this really works. The 
reason is that a mote acting as a receiver node receives data when it should be 
sleeping! Here a brief explanation of my test with pseudocode:
start() // the app starts{   initialize Rx_enable component (call 
Init.init(););   start periodic wakeup interval wiTimer;   call 
MLM_RX_ENABLE(RxOnDuration);}
MLME_RX_Enable.confirm() {} // It confirms that the radio is enabled
wiTimer.fired () // the witimer expires{   /** Here I should call again 
MHME_RX_ENABLE with RxOnDuration.* call MLME_RX_ENABLE(RxOnDuration);* 
However, to this test, I do not make the call. As a result, the * radio 
should be disabled and the node cannot receive anything*/return;}
recv() // receive data (MCPS_DATA.indication()){   // Here I have another node 
that periodically broadcasts a message.// When this message is received, it 
activates one of the receiver node'leds.}
What am I considering that it's wrong? Does MHME_RX_ENABLE really work and 
after RxOnDuration, the radio goes to sleep mode?
Thanks,
David


> Date: Wed, 14 Nov 2012 12:45:25 +0100
> Subject: Re: [Tinyos-help] Sleeping in TKN154
> From: ha...@tkn.tu-berlin.de
> To: drod...@outlook.com
> CC: tinyos-help@millennium.berkeley.edu
> 
> Hi David,
> 
> there are two places where you can implement such duty-cycling: (a) on
> top of the MAC: your component would wire to MLME_RX_ENABLE interface
> provided by Ieee802154NonBeaconEnabledC and you would have a periodic
> timer that fires at the desired ON-Time. In the event-handler you
> would call MLME_RX_ENABLE with a "RxOnDuration" parameter matching
> your ON-time interval. If timers are not accurate enough for you
> (because they fire in task context), you (b) could use Alarms instead.
> Then you would have to modify the MAC. You could extend RxEnableP with
> your own async duty-cycle configuration interface and also modify its
> interface towards DispatchUnslottedCsmaP (which you would also have to
> extend / make async). Unless you need such accurate timing, you'd
> probably go for option (a) ->  you can make some tests to find out
> when the radio actually changed state (to see if it satisfies your
> timing requirements): just set the "tkn154debug" flag and you will get
> statistics via printf (see apps/tests/tkn154/README.txt for details).
> 
> Jan
> 
> On Wed, Nov 14, 2012 at 11:32 AM, David Rodenas  wrote:
> > Hi all
> >
> > I am interseted in programming a duty-cycling scheme by making use of the
> > TKN154 libraries. In particular, I want to induce the motes to periods of
> > activity (ON) and inactivity (OFF) over the IEEE 802.15.4 non-beacon mode.
> > As example:
> >
> > ||++-++-++---
> > ||+ ON |  OFF  | ON |  OFF
> > | ON |  OFF...
> > ||++-++-++---
> > ||+IEEE 802.15.4 NON-BEACON MODE
> > ...
> > ||+-
> >
> > My problem is not how to sinchronize nodes for transmission and reception;
> > it's knowing which components or libraries can I use to control de CC2420,
> > and switch the radio ON/OFF periodocally. I've been trying to figure out how
> > to do it through the LowPowerListening component (but I cannot use it
> > because my protocol does not requires the transmission of preambles), or
> > taking shots in the dark with the TKN files at /tos/lib/mac/tkn154, but I am
> > completely lost.
> >
> > Please, any help possible would be appreciated.
> >
> > Thanks
> >
> > David
> >
> > ___
> > Tinyos-help mailing list
> > Tinyos-help@millennium.berkeley.edu
> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
  ___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Re: [Tinyos-help] Linking Format and Coap

[Konstantinos Veroutis]

Hello again,

thanks for the quick response. I tried to define the TOSH_DATA_LENGTH in
the make file but i received many redefinition warnings.  Then i tried to
send a coap request with payload bigger than 54 bytes but again i never
received it at the destination. In some level the packet gets discarded.
The COAP_MAX_PDU_SIZE is set at 700.

Do you think that this happens because of the above warning or am i missing
something in the implementation that handles the fragmentation? I should
mention that i am using coap-03 . So what i am asking is  if it is possible
to send data bigger than the 802.15.4 frame without having to handle the
fragmentation yourself.

Thnx in advance,

V. K.


On Tue, Nov 20, 2012 at 2:17 PM, Markus Becker 
wrote:

> > Hello to everyone!
> >
> > Newbie to this list.. I'm trying to send a response from the sensor motes
> > (TelosB) following the linking format template, i.e. reply with a char *
> of
> > the following format: ";attribute1=10;attribute2=5;". However I
> > experience severe limitations with the length of the string that prevent
> > the response from being sent (If I guess correctly).
> >
> > Any ideas on how to overcome this? Does libcoap provide any mechanism for
> > sending messages bigger than the maximum payload of the 15.4?
>
> You might want to play with TOSH_DATA_LENGTH, so that the actual fixed size
> TinyOS 15.4 message payload is larger. blip should also fragment the CoAP
> payload.
>
> For the CoapBlip version currently in SVN and in the last release, the
> maximum
> CoAP payload is set to:
>
> support/sdk/c/coap/pdu.h:#define COAP_MAX_PDU_SIZE   700 /* maximum
> size of a CoAP PDU */
>
> If you want, you could also try coap-12 CoapBlip, which is currently in our
> development git.
>
> Markus
>
> > Thnx in advance,
> >
> > V.K.
> 
> | Dipl.-Ing. Markus Becker
> | Communication Networks
> | TZI - Center for Computing Technologies
> | University Bremen
> | Germany
> 
> | web: http://www.comnets.uni-bremen.de/~mab/
> | mailto: m...@comnets.uni-bremen.de
> | telephone: +49 421 218 62379
> | building: NW1 room: N2260
> 
> ___
> Tinyos-help mailing list
> Tinyos-help@millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
___
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help