Mayur -

 

Not sure what the difference is, since PacketLink uses
PacketAcknowledgements to setup and test for acks.  The PacketLink layer
simply retries messages when they don't get through, and is completely
optional.  If you're only interested in the PacketAcknowledgement layer,
then not compiling in the PacketLink functionality is the way to go, saving
you memory footprint.

 

 

 

 

 

  _____  

From: Mayur Maheshwari [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 12, 2007 9:38 AM
To: David Moss
Cc: tinyos-help@millennium.berkeley.edu
Subject: Re: PacketLink/RadioBackoff unexpected behavior

 

Hi David,

 

Thanks once again for your inputs.

 

I understand that there is SPI contention problem. However, I installed
"TestPacketLink" app which does not use flash at all and still the acks are
not received. Moreover, when I install the TestAcks app (which uses
PacketAcknowledgement) the transmitter starts receiving acknowledgements.
Also, what is the advantage of using PacketLink over PacketAcknowledgements
except for the application level retries/delays in the latter? 

 

Any ideas?

 

Secondly, it is fine till the transmitting mote with small backoff is able
to get its packets first to the receiver. This way the receiver should be
able to send the acknowledgement first to the mote with small backoff so
that it again send other packets early. 

 

Mayur,

 

The problem with PacketLink is the fact that your acknowledgements are being
dropped.  The wasDelivered() command simply forwards to
PacketAcknowledgements.wasAcked(). This could be caused by several things,
but since you're probably using flash, that's probably the reason why.  The
SPI bus arbitration prevents the radio from handling acknowledgements
correctly while the flash is in use.  This is a known issue, and I have a
fix going on my machine but don't have it ready for release.  The fix
involves forcing the CC2420 to hang onto the SPI bus while it is waiting for
an acknowledgement. 

 

On your second issue, the backoffs should be in units of microseconds.
Again, the CC2420 has to acquire the SPI bus before it can read a packet
from the chip and this process, combined with actually reading bytes over
SPI, could potentially last longer than the backoffs you have specified.  In
other words, the SPI bus will probably remain active and read both packets
in simultaneously because there's not a big enough time delay between the
two transmissions.  Statically specifying your backoff period like you have
should force mote A to get its packet through first, but you probably won't
be able to detect which transmitter transmitted first unless you check both
packets' source addresses. 

 

Hope that helps,

-David

 

 

 

 


  _____  


From: Mayur Maheshwari [mailto: [EMAIL PROTECTED] 
Sent: Monday, June 11, 2007 4:29 AM 
To: David Moss; tinyos-help@millennium.berkeley.edu 
Subject: PacketLink/RadioBackoff unexpected behavior

 

Hi David,

 

It was nice of you that you helped me with the information on blackbook.
However there seems to be problem galore ;)

 

1. PacketLink

I tried using the PacketLink interface in one of my apps and it fails to
receive the acks. Previously, I was using the PacketAcknowledgements
interface and it was running absolutely fine. However, it seems that the
wasDelivered(msg) event in PacketLink returns FALSE all the time. 

 

I tried testing the app TestPacketLink in
\tinyos-2.x\apps\tests\cc2420\TestPacketLink and the acks were never
received and the Transmitter toggled led0 every 2 secs. Again, I tested the
TestAcks in \tinyos- 2.x\apps\tests\cc2420\TestAcks which uses the interface
PacketAcknowledgements and this does gives positive results.

 

2. RadioBackoff

 

I tested radiobackoff by having events in an app installed on two motes(A
and B). I initialised the Initial Backoff times as 11 and 300 for both the
motes resp. Now, I installed another app on another mote C which broadcasts
and when A and B receive this broadcast they unicast their messages to C. It
was expected that the message from mote B should be delayed by ~ 300 ms but
I noted both the messages getting into C simultaneously.  To be more clear
on this aspect I recorded the events in a video and played at slower speeds
but to no avail. The Leds on the mote C blink in 2~3 ms delay and I could
not determine which packet went first. Would you be able to share some code
in this regard. 

 

Thank you once again for all the help.

Mayur

-- 
Mayur Maheshwari( <mailto:[EMAIL PROTECTED]>
[EMAIL PROTECTED])

"Karmanye Vadhikaraste Ma Phaleshu Kadachana, 
Ma Karma Phala Hetur Bhurmatey Sangostva Akarmani" 




-- 
Mayur Maheshwari([EMAIL PROTECTED])

"Karmanye Vadhikaraste Ma Phaleshu Kadachana, 
Ma Karma Phala Hetur Bhurmatey Sangostva Akarmani" 

_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to