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?
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?
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): ...
One thing to try is fixed value messages to see if there are any bit
pattern dependencies.
Also being 16 bits, the CRC has a 1/65K chance of being falsely
positive (I think).
MS
Alan Marchiori wrote:
> I noticed strange behavior with some TOS code I was working on
> recently. I thought it was a protocol error, but it turned out that
> the cause was receiving packets with erroneous data. It is my
> understanding that the PHY layer CRC should provide adequate
> protection from erroneous packets (i.e., the crc is checked at the PHY
> layer and invalid packets are discarded and the likelihood of an
> erroneous packet having a valid CRC is extremely low). To investigate
> this further, I wrote a simple application that sends out packets
> formated as follows:
>
> #define JUNK_LEN 16
> typedef struct data{
> uint16_t junk[JUNK_LEN];
> uint16_t crc;
> }data_t;
>
> uint16_t j;
> for(j=0; j< JUNK_LEN; j++){
> pkt->junk[j] = call Random.rand16();
> }
> // JUNK_LEN is in words, convert to bytes
> pkt->crc = call Crc.crc16(&pkt->junk[0], JUNK_LEN<<1);
>
> On the receive side (in the receive event handler), I then verify that
> the application-level CRC is correct. Below is the typical output
> (nodes transmit randomly around 3 packets per second). "rx" is the
> lifetime total of receive events signaled. "err" is the number of
> those with an application level crc error. "lenerr" is the number
> where the length was incorrect (I have never seen this happen). I see
> crc errors with both with the DMA and software SPI radio interfaces
> using telosb motes. Just looking at the data, it seems DMA has fewer
> CRC errors (possibly suggesting a software problem?). Has anyone else
> seen this problem or looked into it further? I can send the test code
> if anyone is interested. For now, I guess I'm going to include an
> app-level CRC in my data packets.??
>
> Alan
>
> 2011-04-14 10:10:52,420 - printf - INFO - (9004): TICK (tx (last 60
> sec): 197, rx: 73386, err: 1, lenerr: 0)
> 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)
> 2011-04-14 10:10:56,930 - printf - INFO - (9028): TICK (tx (last 60
> sec): 180, rx: 78493, err: 1, lenerr: 0)
> 2011-04-14 10:10:56,980 - printf - INFO - (9008): TICK (tx (last 60
> sec): 207, rx: 77481, err: 0, lenerr: 0)
> 2011-04-14 10:10:59,270 - printf - INFO - (9010): TICK (tx (last 60
> sec): 180, rx: 78353, err: 4, lenerr: 0)
> 2011-04-14 10:11:00,520 - printf - INFO - (9019): TICK (tx (last 60
> sec): 188, rx: 76016, err: 1, lenerr: 0)
> 2011-04-14 10:11:01,620 - printf - INFO - (9012): TICK (tx (last 60
> sec): 185, rx: 77847, err: 1, lenerr: 0)
> 2011-04-14 10:11:03,270 - printf - INFO - (9021): TICK (tx (last 60
> sec): 201, rx: 73821, err: 1, lenerr: 0)
> 2011-04-14 10:11:05,600 - printf - INFO - (9014): TICK (tx (last 60
> sec): 180, rx: 74860, err: 1, lenerr: 0)
> 2011-04-14 10:11:06,010 - printf - INFO - (9023): TICK (tx (last 60
> sec): 196, rx: 76486, err: 1, lenerr: 0)
> 2011-04-14 10:11:06,280 - printf - INFO - (9003): TICK (tx (last 60
> sec): 194, rx: 76595, err: 0, lenerr: 0)
> 2011-04-14 10:11:07,961 - printf - INFO - (9016): TICK (tx (last 60
> sec): 208, rx: 73878, err: 1, lenerr: 0)
> 2011-04-14 10:11:08,270 - printf - INFO - (9025): TICK (tx (last 60
> sec): 193, rx: 69613, err: 1, lenerr: 0)
> 2011-04-14 10:11:09,360 - printf - INFO - (9005): TICK (tx (last 60
> sec): 189, rx: 79283, err: 1, lenerr: 0)
> 2011-04-14 10:11:10,180 - printf - INFO - (9018): TICK (tx (last 60
> sec): 192, rx: 75160, err: 0, lenerr: 0)
> 2011-04-14 10:11:10,340 - printf - INFO - (9027): TICK (tx (last 60
> sec): 204, rx: 78511, err: 1, lenerr: 0)
> 2011-04-14 10:11:12,650 - printf - INFO - (9009): TICK (tx (last 60
> sec): 183, rx: 77493, err: 0, lenerr: 0)
> 2011-04-14 10:11:12,940 - printf - INFO - (9029): TICK (tx (last 60
> sec): 205, rx: 72160, err: 2, lenerr: 0)
> 2011-04-14 10:11:13,410 - printf - INFO - (9007): TICK (tx (last 60
> sec): 180, rx: 76247, err: 1, lenerr: 0)
> 2011-04-14 10:11:14,930 - printf - INFO - (9020): TICK (tx (last 60
> sec): 213, rx: 77005, err: 2, lenerr: 0)
> _______________________________________________
> 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
