Are the packet corruption caused by fase positive of CRC? Essentially I'm just trying to see if these corrupted packets are due to the inherent limit of the radio stack or some bug in my code.
Best regards, On Wed, Apr 20, 2011 at 3:07 PM, Xiaohui Liu <[email protected]> wrote: > Thanks for your reply. > > So you mean received packet payload can be different from its payload at > the sender side? If so, what's the probability for this case to happen, > approximately? Does this apply to UART stack as well besides radio stack? > > > On Wed, Apr 20, 2011 at 2:40 PM, Omprakash Gnawali < > [email protected]> wrote: > >> On Tue, Apr 19, 2011 at 9:31 AM, Xiaohui Liu <[email protected]> wrote: >> > Hi everyone, >> > A packet is sent with AMSenderC[AM_TYPE].Send.send and it has a payload >> of, >> > say, 0xFF. After the packet is received by >> > AMReceiverC[AM_TYPE].Receive.receive, sometimes I find it has a >> different >> > payload (i.e., not 0xFF). But the probability for this to happen is low, >> > around 1 out of 1000 packets. Is this expected in TinyOS or does this >> mean >> > there is something wrong with my code? In general, can I regard the >> payload >> > of a packet received by AMReceiverC[AM_TYPE].Receive.receive is the same >> as >> > its payload when sent by AMSenderC[AM_TYPE].Send.send? Or should I add >> some >> > more error-detection or even correction to ensure this >> assumption? Thanks. >> >> As long as your error detection or correction can guarantee these >> properties. Most likely you will be able to increase the probability >> of detection or correction but it would be hard to guarantee that. >> >> - om_p >> > > > > -- > -Xiaohui Liu > -- -Xiaohui Liu
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
