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
