Good comments... I finally found another instance of what seems like
the same problem here:
https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2008-January/002363.html
It doesn't sound like it was ever resolved. Other than "you might get
a erroneous packet in 50k". This still seems too high for me.
To continue investigating this I modified CC2420ReceiveP.nc and
changed the first line to the second. This removes the cc2420 CRC
check and should pass up any successfully received message regardless
of the cc2420 CRC.
//if ( ( buf[ rxFrameLength ] >> 7 ) && rx_buf ) {
if (rx_buf){
Then I added code in my application to check the CRC in the packet
metadata. The interesting thing is after about 500k packet receptions
I have not seen a single packet where the CC2420 signaled a CRC error.
On the other hand, I did detect about 10 CRC errors in the
application-level CRC.
cc2420_metadata_t* metadata = call
CC2420PacketBody.getMetadata( msg );
if (!metadata->crc){
printf ("HW CRC ERROR!\n");
printfflush();
}
My conclusion is that the CC2420 is not actually checking the CRC. I
can resolve my problem by simply adding an application-level CRC to my
packets, but I think this is a serious issue that needs to be
addressed.
On Fri, Apr 15, 2011 at 12:23 PM, Michael Schippling <[email protected]> wrote:
> Some thoughts....
>
> First I would make sendPacket() a task rather than calling
> it directly from the two events. I suspect that each of those
> events is a task as well -- I know Timer.fired() in T1 is --
> but it makes the partitioning a bit cleaner.
>
> Second, I wonder if printf() is corrupting something?
> The simplest thing would be to just toggle an LED when you
> get a bad CRC just to make sure. With a little more pain,
> you could implement a separate serial message for reporting.
>
> One would expect parts of the header and regular CRC to
> get corrupted if it was a radio or hardware problem. And
> you have no way of counting how many messages fail at that
> level. Perhaps add a sourceID and serial number to each
> message so you can keep track?
>
> Otherwise the code looks ok to me...
>
> MS
>
>
> Alan Marchiori wrote:
>>>
>>> So it seems that you have multiple base-stations?
>>> Or how are you getting log messages from different motes?
>>
>> there are no base stations or every mote is a base station, depending
>> how you view it. It is a testbed configuration where all motes have
>> serial forwarders connected and I connect to all of them to receive
>> printf messages. Every mote both transmits and receives.
>>
>>> I have never checked the internal integrity of messages
>>> but have also not noticed any glaring bit errors in
>>> "normal" use.
>>>
>>> Anyway...KISS...I would reduce everything to the simplest
>>> configuration with the most basic program, no queuing, and
>>> probably just the default payload size. Start with one
>>> re-mote and one base and then scale up. Try using known
>>> message content as well as random. Ramp up the speed.
>>> All the usual... It could be that you have a loose pointer
>>> in your program that corrupts the message before transmission.
>>
>> I created a version without queuing and still see similar error rates.
>> I then modified the code to send out a constant bit pattern (all
>> 0xa55a) and then print out the received values in the case of an
>> error, here are the first two I saw after about 60k received packets
>> (right around a uint16 rollover....):
>>
>> 2011-04-14 16:30:59,070 - printf - INFO - (9005): CRC ERROR: 725a b8b8
>> 6ab8 9ce9 15ff 8ba9 7b97 b8de 4e7 7847 714e 7d4e cd43 cd42 cde3 cd43
>> 2011-04-14 16:31:41,620 - printf - INFO - (9005): CRC ERROR: a55a a55a
>> a55a a55a a55a a55a 665a 66cc dec6 6756 464e 6655 6666 c66f ee66 d55d
>>
>> the first one is total garbage, the second is more interesting that it
>> starts out as correct (a55a) and then on the 7th byte becomes corrupt.
>>
>> The new code is at:
>> http://thor.mines.edu/trac/attachment/wiki/Projects/Crc/crcAppQueueless.nc
>>
>> If anyone can see anything wrong with this code, I'd be very
>> interested to solve/better understand this problem.
>>
>> Thanks,
>> Alan
>> _______________________________________________
>> Tinyos-help mailing list
>> [email protected]
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
