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. <razv...@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. <razv...@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. <razv...@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
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
