[Tinyos-help] CRC in CC2420

[Avinash Sridharan]

Ah ok,
 Thanks a lot. The specs makes sense, I guess need to look at other
places to understand the false acknowledgments. Any idea as to why
this might be occurring ?

regards,
Avinash

On Thu, Feb 19, 2009 at 6:30 PM, Razvan Musaloiu-E. <razvanm at cs.jhu.edu> wrote:
> Hi!
>
> On Thu, 19 Feb 2009, Avinash Sridharan wrote:
>
>> Dear Razvan,
>> I am using Tiny OS-2.0.2, I wanted to follow up on this question. I
>> have enabled software ACK in my system and see quite a few false
>> positives (for topologies with link qualities as bad as 30%). My guess
>> is that though the CRC is failing, the CRC field is not checked before
>> the complete packet is read. While the software acknowledgment is sent
>> out the minute the header information is read (which could still be
>> correct though the data is corrupted).  Please correct me if my
>> description of the behavior of software acknowledgment is not exact.
>
> The specs [1] (page 42, first paragraph after Figure 23) says that SACK and
> SACKPEND will not generate an ACK if the CRC is not valid. So the current
> implementation should work properly.
>
> [1] http://www.ti.com/lit/gpn/cc2420
>
> --
> Razvan ME
>
>> Given my above description is correct, just to see if I can see any
>> reduction in the number of false positive ACK's I wanted to move the
>> software acknowledgment to be generated after performing the CRC test.
>>
>> I was planning to modify the current code from :
>> if ( ( buf[ rxFrameLength ] >> 7 ) && rx_buf ) {
>>       uint8_t type = ( header->fcf >> IEEE154_FCF_FRAME_TYPE ) & 7;
>>       signal CC2420Receive.receive( type, m_p_rx_buf );
>>       if ( type == IEEE154_TYPE_DATA ) {
>>         post receiveDone_task();
>>         return;
>>       }
>>     }
>>
>>
>> to ------
>>
>> if ( ( buf[ rxFrameLength ] >> 7 ) && rx_buf ) {
>>       uint8_t type = ( header->fcf >> IEEE154_FCF_FRAME_TYPE ) & 7;
>>       signal CC2420Receive.receive( type, m_p_rx_buf );
>>       if ( type == IEEE154_TYPE_DATA ) {
>>          call CSN.set();
>>         call CSN.clr();
>>         call SACK.strobe();
>>         call CSN.set();
>>         call CSN.clr();
>>
>>         post receiveDone_task();
>>         return;
>>       }
>>     }
>>
>> Of course I will turn of the current initiation of software
>> acknowledgment.   Wanted your feedback on these code changes.
>>
>> Thanks and regards,
>> Avinash
>>
>>
>> On Tue, Feb 17, 2009 at 12:18 PM, Razvan Musaloiu-E. <razvanm at cs.jhu.edu>
>> wrote:
>>>
>>> Hi!
>>>
>>> On Tue, 17 Feb 2009, Jordi Pérez wrote:
>>>
>>>> Hi!
>>>>
>>>> I have just tried it, and it works correctly. I see the bad and the
>>>> correct
>>>> packets.
>>>>
>>>
>>> There was a bug in my patch (Mike point it out to me). I attached the
>>> correct one now. :-)
>>>
>>> --
>>> Razvan ME
>>>
>>>> 2009/2/17 Razvan Musaloiu-E. <razvanm at cs.jhu.edu>
>>>>
>>>>> Hi!
>>>>>
>>>>> On Mon, 16 Feb 2009, Jordi Pérez wrote:
>>>>>
>>>>>  Hi Razvan!
>>>>>>
>>>>>> I tryed to understand the code to disable the filtering you said, but
>>>>>> I
>>>>>> can't. Do you mind explaining me the things I have to change?
>>>>>>
>>>>>> In RXFIFO.readDone event when I modify something, the program doesn't
>>>>>> work.
>>>>>> So I don't know how disable it.
>>>>>>
>>>>>> In the SubReceive.receive event I changed the word Snoop to Receive,
>>>>>> but I
>>>>>> don't really know if it is correct.
>>>>>>
>>>>>> Can you help me please?
>>>>>>
>>>>>
>>>>> I attached a patch that takes out the parts that discards the packets
>>>>> with
>>>>> bad CRC. It's against the latest CVS and you can apply it with this
>>>>> requence
>>>>> of commands:
>>>>>      cd $TOSROOT
>>>>>      patch -p1 < cc2420-ignore-crc-patch.diff
>>>>>
>>>>> Warning: I didn't have time to test this! I only made sure that it
>>>>> compiles
>>>>> fine. :-) Give it a try and if it doesn't work at it should I'll look
>>>>> more
>>>>> into it.
>>>>>
>>>>> --
>>>>> Razvan ME
>>>>>
>>>>>
>>>>>  2009/2/12 Razvan Musaloiu-E. <razvanm at cs.jhu.edu>
>>>>>>
>>>>>>  Hi!
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 11 Feb 2009, Jordi Pérez wrote:
>>>>>>>
>>>>>>>  Dear all,
>>>>>>>
>>>>>>>>
>>>>>>>> For CC2420, if AUTOCRC is set, will the hardware reject CRC-error
>>>>>>>> packet automatically?
>>>>>>>> If true, then is it possible to receive those packets but with
>>>>>>>> AUTOCRC still
>>>>>>>> being set? I want to receive this packets and rebuild them.
>>>>>>>>
>>>>>>>>
>>>>>>>  The CC2420 is not discarding the packets with bad CRC. What does is
>>>>>>> to
>>>>>>> indicate using a bit that the packet was bad (page 38, section 16.4
>>>>>>> from
>>>>>>> [1]). The TinyOS driver for CC2420 inspects this bit and discards the
>>>>>>> packets if that bit is not 1. You can see this happening in the
>>>>>>> RXFIFO.readDone event from CC2420ReceiveP.nc. The switch branch of
>>>>>>> interest
>>>>>>> is 'case S_RX_PAYLOAD:'.
>>>>>>>
>>>>>>> The other filtering that you'll have to disable is in the
>>>>>>> SubReceive.receive event from CC2420ActiveMessageP.nc.
>>>>>>>
>>>>>>> [1] http://focus.ti.com/lit/ds/symlink/cc2420.pdf
>>>>>>>
>>>>>>> --
>>>>>>> Razvan ME
>>>>>>>
>>>>>>
>>>>
>>>
>>
>



-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar