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 experimented with software Acks but found that to be equally shaky in a congested environment. 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 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. 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
