To investigate this issue a little further, I wrote a simple program that sends out unicast packets as fast as possible by posting a message sending task in the SendMsg.sendDone() event handler. All unicast packets are sent to a fixed mote id and contain payload of 48 bytes. The application code does not touch TOSMsg header fields. The application turns on the ACK by calling MacControl.enableAck() in StdControl.start().
I ran this program on 3 TmoteSky motes. One of the mote has the mote id which will receive all the unicast messages. At the same time, I have another TmoteSky and a MicaZ both running TOSBase overhearing the packets being transmitted.
From the TmoteSky TOSBase log, I see many short packets being
recorded. Most of these packets have only 5 bytes of payload and bogus destpan addresses. However, the MicaZ TOSBase log does not have packets with such short length. It seems that MicaZ TOSBase was able to receive those packets completely while TmoteSky TOSBase sometimes report packets chopped short with corrupted destpan addresses. In CC2420RadioM.nc line 629, I saw this note: // JP NOTE: rare known bug in high contention: // radio stack will receive a valid packet, but for some reason the // length field will be longer than normal. The packet data will // be valid up to the correct length, and then will contain garbage // after the correct length. There is no currently known fix. It looks like what happened in my case is that some messages received by TmoteSky TOSBase mote got corrupted along the way up the radio stack. The corrupted length field is *shorter* than normal under high contention. I still don't know what race condition caused this problem but it seems to happen only on Telos platform under high load. After reproducing this length corruption problem, I tried the same test without ACK being enabled (by calling MacControl.enableAck() ). What's interesting is that I see no short packets when ACK is disabled. Somehow enabling ACK is disturbing the receiving path in the CC2420 stack running on Telos platform? -Bor-rong On 8/8/06, Philip Levis <[EMAIL PROTECTED]> wrote:
On Aug 8, 2006, at 12:17 PM, Bor-rong Chen wrote: > Hi > > Has anyone seen destpan field in TOSMsg being something other than > 65535 (0xffff)? > > From packets logged from one of our application by a modified > version of TOSBase, I'm seeing some packets with pMsg->destpan set > to various values. Many of them have 255 (0xff00), others having > rather random values such as 58082, 21967, 19936 ... > > I'm running TinyOS 1.1.15 and this network has both MicaZ and > TmoteSky motes. > > As far as I can tell, pMsg->destpan is only set in tos/lib/ > CC2420Radio/CC2420RadioM.nc and is always set to TOS_BCAST_ADDR in > Send.send(): > > // destination PAN is broadcast > pMsg->destpan = TOS_BCAST_ADDR; > > Ideally this value should always be TOS_BCAST_ADDR (0xffff) but for > some reason it is not the case when I try to diagnose our network > with TOSBase. Has anyone seen this before? Any idea what is causing > this? A memory access bug that's overwriting some part of the packet? Phil
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
