> 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 [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
