Hi Lewis, On Tue, Mar 27, 2012 at 8:48 AM, Oldrine Lewis <ole...@sutron.com> wrote: > Hi Miklos, > > Removing the CSMA/Tx retries seems to have fixed the issue. I have not seen > any corrupted packets since. > I am kind of surprised that the AT86RF230 has bugs even in the core > functionality
Great to hear that. Software is reliable, hardware is not :). By the way, a lot of hardware bugs are documented in the errata, and they specifically recommend implementing the retry logic and CSMA in software. The ATMEGA128RFA1 chip does not seem to be affected by those bugs however. Best, Miklos > > Thanks, > Lewis > > > > -----Original Message----- > From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti > Sent: Monday, March 26, 2012 12:47 AM > To: Oldrine Lewis > Cc: tinyos-help@millennium.berkeley.edu > Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check > > Hi Lewis, > > On Mon, Mar 26, 2012 at 5:42 AM, Oldrine Lewis <ole...@sutron.com> wrote: >> >> >> Hi Miklos, >> >> I have not tested with lower data rates. I will get rerun my tests with a >> lower data rate and also get the status of the registers. >> However, in the meantime, I captured another corrupted packet where the >> radio actually resend the correct packet, but it was probably discarded by >> SubReceive.receive() in UniqueLayerP.nc cos it appeared to be a duplicate >> packet. >> >> First Packet ( corrupted data) >> 61 88 40 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 9A 02 07 00 27 00 00 C2 >> 00 00 67 03 05 00 >> Second Packet (resend by the radio) >> 61 88 40 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 AA 02 01 00 2B 00 01 02 >> 00 00 01 00 05 00 > > This is completely overwritten (it has many errors from the AA on). > >> Is there any situation where the sending radio might retransmit messages >> that are broadcast? > > Strange, it should not have resent the packet unless 1) you use > PacketLink, or 2) you use LowPowerListening. Maybe you can add > debugging on the sender side as well... > > Best, > Miklos > >> >> Thanks, >> Lewis >> >> >> -----Original Message----- >> From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos Maroti >> Sent: Sunday, March 25, 2012 11:14 PM >> To: Oldrine Lewis >> Cc: tinyos-help@millennium.berkeley.edu >> Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check >> >> Hi Lewis, >> >> Very interesting. The RF230 should not have done that: in section 8.2.4 it >> says: >> >> "In RX_AACK states, if FCS of the received frame is not valid, the >> radio transceiver >> rejects the frame and the TRX_END interrupt will not be generated." >> >> Do you see this behavior with very low data rates? Can you also print out the >> >> TRX_STATUS, TRX_STATE, PHY_RSSI and VERSION_NUM registers just after >> you have downloaded the message at line 695 just after the call >> SELN.set();. Would be nice if any change in these registers could >> detect the bad CRC check. Also, does enabling the RADIO_DEBUG produces >> any output with "java net.tinyos.tools.DiagMsg"? >> >> Best, >> Miklos >> >> On Mon, Mar 26, 2012 at 2:05 AM, Oldrine Lewis <ole...@sutron.com> wrote: >>> Hi Miklos, >>> >>> I began seeing quite a few of the corrupted packets, so I added some debug >>> statements(RF230DriverHwAckP.nc) to output the raw received data just >>> before signaling RadioReceive.receive(rxMsg); >>> >>> >>> >>> Sender : Node addr 2 >>> >>> Receiver : Node addr 3 >>> >>> Tx Type: Broadcast >>> >>> >>> >>> Byte#15 should have been 0x01 instead of 0x51. >>> >>> >>> >>> Received data >>> >>> 61 88 49 22 00 FF FF 02 00 3F 08 0B 12 10 51 04 00 AA 02 01 00 34 00 01 02 >>> 00 00 01 00 05 00 >>> >>> >>> >>> Expected data >>> >>> 61 88 49 22 00 FF FF 02 00 3F 08 0B 12 10 01 04 00 AA 02 01 00 34 00 01 02 >>> 00 00 01 00 05 00 >>> >>> >>> >>> Thanks, >>> >>> Lewis >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos >>> Maroti >>> Sent: Wednesday, March 21, 2012 2:01 AM >>> To: Oldrine Lewis >>> Cc: tinyos-help@millennium.berkeley.edu >>> Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check >>> >>> >>> >>> Hi Lewis, >>> >>> >>> >>> On Tue, Mar 20, 2012 at 6:26 AM, Oldrine Lewis <ole...@sutron.com> wrote: >>> >>>> Hi Miklos, >>> >>>> If multiple packets arrive in quick succession, and we reject the first >>>> packet because radioIrq was set, will radioIrq go ahead and interrupt the >>>> micro again? If it does, is it possible that we might end up downloading a >>>> subsequent packet which might have been corrupted? >>> >>> >>> >>> The RF230 has a TRX_UR interrupt (underrun/overrun) which will be >>> >>> triggered if the pointer used to fill up the FIFO from the demodulator >>> >>> passes the pointer that is used to read the content via SPI. To my >>> >>> understanding this will indicate all data corruption errors coming >>> >>> from overwriting packets. >>> >>> >>> >>> Best, >>> >>> Miklos >>> >>> >>> >>>> Thanks, >>> >>>> Lewis >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> -----Original Message----- >>> >>>> From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos >>>> Maroti >>> >>>> Sent: Tuesday, March 20, 2012 12:04 AM >>> >>>> To: Oldrine Lewis >>> >>>> Cc: tinyos-help@millennium.berkeley.edu >>> >>>> Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check >>> >>>> >>> >>>> Hi Lewis, >>> >>>> >>> >>>> On Tue, Mar 20, 2012 at 2:42 AM, Oldrine Lewis <ole...@sutron.com> wrote: >>> >>>>> Hi, >>> >>>>> >>> >>>>> I am a little confused too cos the FCS check should be automatically done >>>>> in >>> >>>>> the extended mode. >>> >>>>> >>> >>>>> The corrupted packet I noticed had an incorrect length (argument in >>> >>>>> Receive() event signalled in the app) and also some of the data bytes >>>>> were >>> >>>>> corrupted. I have not yet been able to capture another corrupted packet >>> >>>>> since. >>> >>>> >>> >>>> With very low probability a corrupted packet can still pass the CRC >>> >>>> check, maybe you have seen one. Would be nice to know if it would have >>> >>>> passed a manual CRC check. >>> >>>> >>> >>>>> Today, I noticed that I was losing a few packets, which I think was due >>>>> to >>> >>>>> another Interrupt arrving from the RF230 (crcValid = ! radioIrq;). This >>> >>>>> however did not result in a corrupted packet. >>> >>>>> >>> >>>>> Is it possible that multiple packets arrivng in quick succession might >>>>> cause >>> >>>>> data to get corrupted under some circumstances? >>> >>>> >>> >>>> I think yes, a new packet can overwrite an old one, that is why I have >>> >>>> the IRQ check there. >>> >>>> >>> >>>> Best, >>> >>>> Miklos >>> >>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Thanks, >>> >>>>> >>> >>>>> Lewis >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -----Original Message----- >>> >>>>> From: mmar...@gmail.com [mailto:mmar...@gmail.com] On Behalf Of Miklos >>> >>>>> Maroti >>> >>>>> Sent: Sunday, March 18, 2012 8:45 PM >>> >>>>> To: Oldrine Lewis >>> >>>>> Cc: tinyos-help@millennium.berkeley.edu >>> >>>>> Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Hi Lewis, >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> In the extended mode (which the RF230DriverHwAckP uses) all packets >>> >>>>> >>> >>>>> with an invalid CRC are discarded. The software ack driver >>> >>>>> >>> >>>>> (RF230DriverLayerP) does not use the RX_CRC_VALID flag because it was >>> >>>>> >>> >>>>> not present in the rev A of the chip. (Looking at the docs know I >>> >>>>> >>> >>>>> cannot find a record of this fact, maybe it was there but >>> >>>>> >>> >>>>> undocumented?) I am curious how you have seen corrupted messages. Can >>> >>>>> >>> >>>>> you have specific examples? Do you see them with the softwareack >>> >>>>> >>> >>>>> driver as well? >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> Miklos >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Sun, Mar 18, 2012 at 8:28 PM, Oldrine Lewis <ole...@sutron.com> wrote: >>> >>>>> >>> >>>>>> Hi, >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> I have a simple test where one node broadcasts packets and it is >>>>>> received >>> >>>>>> by >>> >>>>> >>> >>>>>> multiple nodes. I noticed that I was occassionally receiving some >>> >>>>>> corrupted >>> >>>>> >>> >>>>>> packets. The packets were transmitted correctly because one of the other >>> >>>>> >>> >>>>>> nodes received the packet correctly. >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> On doing a little investigation, I noticed that the lower layer driver >>> >>>>> >>> >>>>>> (RF230DriverHwAckP.nc) does not check the RX_CRC_VALID flag in the >>> >>>>>> register >>> >>>>> >>> >>>>>> PHY_RSSI (0x06) which is updated with the result of the FCS check on the >>> >>>>> >>> >>>>>> received packet. >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> Would adding another check improve the Receiver reliability? >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> Thanks, >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> Lewis >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> >>> >>>>> >>> >>>>>> _______________________________________________ >>> >>>>> >>> >>>>>> Tinyos-help mailing list >>> >>>>> >>> >>>>>> Tinyos-help@millennium.berkeley.edu >>> >>>>> >>> >>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
