So it seems that you have multiple base-stations? Or how are you getting log messages from different motes?
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. And I will also posit that I don't have the brain power to figure out the error rate for the 16bit CRC, but I think it should be much lower than what you are seeing. I just presume that Murphy holds. MS Alan Marchiori wrote: >> Are you using the "standard" user level send/recv interfaces, >> and what version? (On telosb I gather). If your code differs >> in any respect from the demo programs, can you post it? > > tos 2.1.1, telosb, and yes it is a bit more complex because there are > queues on both the tx and rx paths (on top of AMSender/AMReceiver) > with a shared buffer pool. I did this because the code I am really > working on has queues as well. I'll investigate without queues, but > if this breaks something, something is seriously wrong. > > I put the code up at: > http://thor.mines.edu/trac/wiki/Projects/Crc > > For anyone to look at. > >> There are a couple things I don't understand already though. >> >> First, your message length is 34 bytes, which I think is slightly >> larger that the default length. Have you changed the default? > > CFLAGS += -DTOSH_DATA_LENGTH=114 > >> Then in your output: >>> 2011-04-14 10:10:53,690 - printf - INFO - (9026): TICK (tx (last 60 >>> sec): 205, rx: 76273, err: 1, lenerr: 0) >>> 2011-04-14 10:10:53,960 - printf - INFO - (9015): TICK (tx (last 60 >>> sec): 189, rx: 74755, err: 4, lenerr: 0) >>> 2011-04-14 10:10:55,200 - printf - INFO - (9006): TICK (tx (last 60 >>> sec): 194, rx: 73377, err: 5, lenerr: 0) >>> 2011-04-14 10:10:55,220 - printf - INFO - (9017): TICK (tx (last 60 >>> sec): 199, rx: 74364, err: 4, lenerr: 0) >> I presume the timestamp "10:10:53,960" is hr:min:sec,msec and the rx >> count you said is the total received ever. However rx goes down from >> :53,690 to :53,960 and by way more than you report receiving over the >> (last 60 sec): ... > > these lines were all from different motes, the number in the first set > of ()'s is the SerialForwarder tcp port number. This was collected on > a dense 28-mote testbed. > >> One thing to try is fixed value messages to see if there are any bit >> pattern dependencies. > > interesting idea. Maybe send out a packet with 16 copies of an > increasing counter and see what happens. > >> Also being 16 bits, the CRC has a 1/65K chance of being falsely >> positive (I think). > > I sure hope not. This would be true if the CRC was just a uniformly > random value; it's not. It is computed over the payload. > Furthermore, the PHY CRC is correct over the TOS packet but within > that packet there is a block of data with an invalid CRC. So, > presumably just the right (or wrong) bits were modified to keep the > PHY CRC valid while invalidating the inner CRC. It would seem > possible to compute the probability of this happening under certain > conditions (e.g., uniformly random payloads or something). As much > fun as that sounds, I'll leave it up to someone else to compute, or to > correct me on. > > Alan _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
