Dear Oldrine, On Wed, Nov 7, 2012 at 5:06 PM, Oldrine Lewis <[email protected]> wrote: > I have been doing some testing with the RF230 drivers (IRIS motes) for a > while now and ran into a few glitches. > > The drivers usually work fine, but in a congested RF environment where > multiple nodes might be trying to transmit at the same time, I noticed that > quite a few few packets were lost due to buffer underruns. This might be a > serious issue because the transmitter will get an Ack ( if hardware acks > are enabled) but the receiver application will not get the message. I
This is known, that if the software cannot keep up and the hardware is sending acks, then we loose packets. As you have mentioned, in this situation you should not use TASKLET_IS_TASK because in this case arbitrary time can pass before we service the radio (from task context). > experimented with software Acks but found that to be equally shaky in a > congested environment. The software ack layer makes sure that the packet passes CRC checks, we can download it without underrun and we can store it in main memory buffer, and only then will it issue an ack message. Can you tell why is the software ack is flaky for you? > > I also noticed that a few interesting features supported by the radio > hardware were not exposed to the outside ( through defines in the Makefile), > that might come handy > > · Frame retries > > · CSMA retries > > · MIN_BE bits in the register CSMA_SEED_1 All true. Using these would not be compatible with the cc2420 driver, so I did not use them. Also, read all the errata about the chip where they recommend NOT to use these features and implement it in software. > > Now, back to the original issue, in order to prevent the radio from dropping > packets due to underruns, as soon as the IRQ interrupt is received, if the > RF230 state was changed to PLL_ON ( as recommend in the user manual) and > then set to RX_AACK_ON after the last byte has been downloaded, will greatly > reduce buffer underruns. As an added measure of safety I also added an FCS > check if the IRQ interrupt triggered before I finished downloading the > entire message. This means that in case an underrun occurs we only discard > messages that got corrupted (fail the FCS check). I am still in the process > of testing these changes to make sure that they work as expected. Would like to see the code when you think it is ready. Even in this case you cannot avoid message loss, because of the hardware ack since the mcu might be in an atomic context and cannot execute the interrupt routine. Also, with your changes please try out the apps/LinkBench application which will measure the performance of your changes under various workloads. In particular, you might increase the number of dropped packets by increasing the number of acked but not correctly received packets. Best, MIklos > > All the changes are applicable to RF230DriverHwAckP.nc. > > > > If running in a congested RF environment I do not recommend using the flag > TASKLET_IS_A_TASK. > > > > Please feel free to provide suggestions/recommendations > > > > 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
