[Tinyos-help] Checking CRC

[Philip Levis]

On Jun 1, 2007, at 7:48 AM, Jon Green wrote:

> Does anyone know how I can check if a packet passed CRC check in a  
> nice
> platform independent way? I can't find any abstraction for CRC  
> checks...
>
> I have an application that is occasionally getting packets with
> malformed data in them. When it gets a bad packet, a good packet  
> always
> arrives soon after with the same DSN, which means it didn't ack the  
> bad
> packet, and the other mote sent the data again. This leads me to  
> believe
> that the packet failed the CRC check.

Another possibility is that the corrupted packet did not have the ack  
bit set in its header.

>
> I'm working with a MicaZ mote. From what I see in the source, the CRC
> field gets set in the metadata, but nothing ever gets done with it.
> There is no link layer module for received packets, so the bad packet
> makes it all the way to the application layer. Now at the application
> layer I'm trying to figure out if there is a nice way to check if it
> failed CRC without using CC2420Packet. Has anyone faced this before  
> and
> how is the accepted way to deal with it?

The radio hardware generates the CRC on the transmitter and checks  
the CRC on the receiver. If you look in CC2420ControlP, it is setting  
AUTOCRC.

CRCs are not infalible. It's possible for a corrupted packet to pass  
CRC and be passed to the application layer. Typically the way to  
check this is to add a CRC at the layer you care about (the end-to- 
end principle). I've definitely seen corrupted packets make it to the  
application layer. One result of this that you can see is packets  
which do not arrive at layer 3 being acked at layer 2; if the AM  
field is corrupted, then the packet will be dispatched to a different  
handler.

Do you have a CC2420DK packet sniffer? That could help you see what's  
going on. It might also be helpful do dump the entire 15.4 packets to  
the serial port; the header bits might give some insight into what's  
going on.

Phil