hi.
thanks a lot for your answer. Philip.
I try to test mote transmission time outdoor, but results are the same as
before ( no intereference with other 2.4G Hz traffic).
The ACK listening time is always ( default) implemented in cc2420 radio
stack of telosb motes? cause my mote sends
messages in BROADCAST ---> there is always an ACK listening time after
sending the message?
this max ACK listening time should be of 256 ticks ( 7,8 msec ) from
'opt\tinyos-2.x\tos\chips\cc2420\CC2420.h'
If i add an average ack listening time to total transmit time i should
found that 40 bytes payload packet should be sent in:
about 2 msec ------------>to send 40bytes payload + 18 bytes ( preamble +
header + CRC ) at 250kbit/sec-----> (58*8)/ 250 000
+
about 5 msec ( average initial backoff ( max backoff time - min backoff
time )/2 )
+
about 3,8 msec ( average ACK listening time (max ack listening time/2) )
=
about 11 milliseconds ---->that is a value much similar to average
transmission time founded in motes...
But this ack listening time is not implemented in Tossim simulation?
I try to set 'mac.setAckTime()' to some values ( 256, 512 ,1024 ) in my
python script , but the average transmission time in tossim simulation is
the same as before...so it not influences tossim simulation.
I also change CC2420_ACK_WAIT_DELAY ( setting to 10 jiffies ) in cc2420.h,
but this seems not influence the average transmission time in TmoteSky.
My problem is that tossim simulation don't give me values that i can compare
with real behaviour of TmoteSky motes
( average transmission time in tossim = 6,8 ms , average transmission time
in Tmotesky = 10,2 ms )
I think that there is some backoff time / delay ( of about 3 ms ) that is
implemented for telosb platforms, but is NOT implemented
in tossim simulation .
Can anyone say to me a possible explanation for this difference between
tossim simulation and rela behaviour in motes?
every idea is welcome....
P.S. the components that i use are:
---------------------file staticC.nc ---------------------------
configuration staticC {
// this module does not provide any interface
}
implementation {
components MainC, StaticP;
components ActiveMessageC;
components new AMSenderC(AM_DATAFIELDSTATICMSG);
components new AMReceiverC(AM_DATAFIELDMULEMSG);
StaticP.Receive -> AMReceiverC;
StaticP.AMSend -> AMSenderC;
StaticP.AMControl -> ActiveMessageC;
StaticP.Packet -> AMSenderC;
.....
.....
}
----------------------------------file StaticP.nc
----------------------------
module StaticP{
provides {
interface Init;
}
uses {
.......
.......
interface Receive;
interface AMSend;
interface SplitControl as AMControl;
interface Packet;
.....
....
}
}
------------------------file Makefile-----------------------
COMPONENT=STATICsNAIVEC
PFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS ( i also try with this line
commented )
PFLAGS += -DCC2420_NO_ADDRESS_RECOGNITION
.......
.....
------------------------------------------------------------------
Best regards
Thanks very much for your help
Sorry for my frequently questions
2008/6/9 Philip Levis <[EMAIL PROTECTED]>:
>
> On Jun 8, 2008, at 12:32 PM, salvatore galati wrote:
>
> hi all.
>> I'm a student of Information Engeenering at University of Pisa.
>> I'm working on a thesis on data transfer protocol in WSN.
>> I'm using TmoteSky motes an TinyOs 2.x on cygwin.
>> My problem is that i can't be able to exstimate the average transmission
>> time of a packet of 40bytes payload.
>>
>> When I run Tossim simulations ( with "make micaz sim" ) i found that the
>> average transmission time is about 6,8 milliseconds ( time between
>> AMSend.send() and AMSend.sendDone() )
>> but when I install my application on motes (with "make telosb install" ) i
>> found that the average transmission time is about 10 milliseconds
>> ( telosb mote send packets back-to-back and is the only mote that send
>> packets ----> NO possible collisions )
>>
>> It is possible that this time difference is caused by backoff times or
>> other delays?
>> Both Micaz and Telosb platforms uses CC2420 Radio stack, so i think that
>> backoff time should be the same.
>> In my python script i don't change the default values of backoff times:
>>
>> from TOSSIM import *
>> t = Tossim(n.variables.variables())
>>
>> mac = t.mac()
>>
>> mac.setInitHigh(640) ( should be initial backoff maximum value )
>> mac.setInitLow(20) ( should be initial backoff minimum value )
>> mac.setHigh(160) ( should be congestion backoff maximum value )
>> mac.setLow(20) ( should be congestion backoff minimum value )
>>
>> Otherwise from 'opt\tinyos-2.x\tos\chips\cc2420\CC2420.h' and
>> 'opt\tinyos-2.x\tos\chips\cc2420\csma\CC2420CsmaP.nc' i think that
>> initial backoff is random and bounded between 10-320 ticks ( 0,3 ---->9,8
>> milliseconds )
>> congestion backoff is random and bounded between 10-80 ticks ( 0,3---->
>> 2,4 milliseconds )
>>
>> Tossim values are double in regard to cc2420 values founded in
>> 'opt\tinyos-2.x\tos\chips\cc2420' directory.
>>
>> I don't understand why in telosb mote ( 250kbit/sec bit-rate) there is
>> this average transmission time of 10 milliseconds:
>>
>> theorically a 40 bytes payload packet should be sent in:
>>
>> about 2 msec ------------>to send 40bytes payload + 18 bytes ( preamble +
>> header + CRC ) at 250kbit/sec-----> (58*8)/ 250 000
>> +
>> about 5 msec ( average initial backoff ( max backoff time - min
>> backoff time )/2 )
>> =
>> about 7 milliseconds ( this value is similar to tossim average
>> transmission time)
>>
>>
>> Please anyone can explain to me why there is this difference between
>> tossim simulation and test on motes?
>> or anyone can send to me a datasheet , document, pubblication in which I
>> can found an explanation of backoff time values in cc2420 radio stack on
>> telosb motes?
>> It is very important to me.
>>
>
> It's possible your motes are sensing other 2.4 GHz traffic (e.g., 802.11)
> and backing off in response to it. There's also the ACK listening time.
>
> Phil
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
