[Tinyos-devel] PacketLink interface, CC2420 impl, problems with Broadcast packets TinyOS 2.0.2.2

[J. Ryan Stinnett]

Alright, that may be true, as I haven't check the CC2420 specs in a 
while.  However, in most cases it is not useful to ACK a broadcast 
packet (at least with a hardware ACK), since multiple nodes would try to 
send an ACK to the same node at about the same time, causing a 
collision.  Perhaps this was in mind when the ACK handling for 
broadcasts in the radio stack was written?  I imagine David will have 
some input here.

- Ryan

Razvan Musaloiu-E. wrote:
> Hi!
> 
> On Thu, 6 Sep 2007, J. Ryan Stinnett wrote:
> 
>> Avinash -
>>
>> Broadcast packets are not ACKed at all.
> 
> If a broadcast packet has the 'Acknowledge request' set then it will be 
> acked by the CC2420 chip.
> 
> -- 
> Razvan ME
> 
>> If I understand correctly, you are checking in the sendDone event 
>> whether or not the packet was ACKed, and retrying if it was not, 
>> correct?  This check should not be performed on broadcast packets 
>> since ACKs are never sent for them.
>>
>> - Ryan
>>
>> Avinash Sridharan wrote:
>>> Hi All,
>>>  I am not sure if this is the right forum to send this mail, or 
>>> should I be sending it to the TinyOS-help mailing list.
>>>
>>> I was using the the PacketLink interface on the Tmote Sky's with the 
>>> CC2420 stack. In my code I have broadcast beacons that are send out 
>>> at periodic intervals. When I started using the PacketLink interface 
>>> I started seeing a considerable drop in my throughput (this is 
>>> observed using logs from the mote).
>>>
>>> I added some code to see the number of retransmission attempts for 
>>> each packet being sent out. In my test case I had a fully connected 
>>> network (with all links having a PRR of ~ 1). Ideally I should be 
>>> seeing all packets being ACKED and the number the sent attempts on 
>>> packets being 1. This was the case for the packets that were being 
>>> unicasted however for the broadcast packets the transmission attempts 
>>> were always the maximum number of retries and they were never ACKED 
>>> (this was true for all broadcast packets).
>>>
>>> On digging a bit deeper I realised that the CC2420PacketC (which 
>>> provides the PacketAcknowledgement interface) does not check for the 
>>> destination address and simply returns the ACK field in the metadata. 
>>> Once I added a condition for the checking the broadcast address (and 
>>> always returning true for BROADCAST), performance returned to normal.
>>>
>>> Is this a valid bug ? Is the fix correct, or should this condition be 
>>> handled at some other point ?
>>>
>>> regards,
>>> Avinash
>>>
>>>
>>> -- 
>>> Phd Dept. of Electrical Engineering
>>> University of Southern California
>>> http://www-scf.usc.edu/~asridhar
>>>
>>>
>>
> 
>