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 <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of Miklos > Maroti > Sent: Wednesday, March 21, 2012 2:01 AM > To: Oldrine Lewis > Cc: [email protected] > Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check > > > > Hi Lewis, > > > > On Tue, Mar 20, 2012 at 6:26 AM, Oldrine Lewis <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of Miklos >> Maroti > >> Sent: Tuesday, March 20, 2012 12:04 AM > >> To: Oldrine Lewis > >> Cc: [email protected] > >> Subject: Re: [Tinyos-help] IRIS motes corrupted data received - CRC check > >> > >> Hi Lewis, > >> > >> On Tue, Mar 20, 2012 at 2:42 AM, Oldrine Lewis <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of Miklos > >>> Maroti > >>> Sent: Sunday, March 18, 2012 8:45 PM > >>> To: Oldrine Lewis > >>> Cc: [email protected] > >>> 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 <[email protected]> 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 > >>> > >>>> [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
