On Wed, Jun 16, 2010 at 22:13, Miklos Maroti <mmar...@math.u-szeged.hu> wrote: > Hi Stefano, > > On Wed, Jun 16, 2010 at 4:30 PM, Stefano "Kismet" Lenzi > <kismet...@gmail.com> wrote: >> On Wed, Jun 9, 2010 at 10:24, Miklos Maroti <mmar...@math.u-szeged.hu> wrote: >>> Hi Giancarlo, >>> >>> The RF230HWACk driver does not use the hardware CSMA engine of the >>> chip, only hardware ACKs. The driver automatically retries to send >>> messages. You might want to enable acknowledgements to guarantee >>> delivery. >>> >>> Miklos >> >> Dear Miklos, >> >> Thank you for the reply, but I think that we need clarify a bit the >> environment. >> >> SCENARIO: Broadcast communication among nodes >> GOAL: Reduce packet loss by using the transmission mode shown on >> Figure 7-8 at page 36 of the AT86RF230 Datasheet >> >> PRECONDITION: >> As far as I know, the broadcast communication disable the transmission >> of ACK on the AT86RF230 radio, do you agree? > > Yes (although if you set your node address to 0xFFFF then it will > happily return an ACK because of a hardware bug)
I read the errata and it seems that the ACK is sent only if the acknowledgement request subfield is set, does it mean that when I set RF230_HARDWARE_ACK all the packet sent by radio has the acknowledgement request subfield set ? Please consider that in our scenario we do not want to use the ACK but we set the RF230_HARDWARE_ACK to enable the transmission mode shown on Figure 7-8 at page 36 of the AT86RF230 > >> The activation of the RF230DriverHwAck enable the Flow Diagram >> depicted on Figure 7-8 at page 36 of the AT86RF230 Datasheet for the >> AT86RF230 radio, doesn't it? >> The default configuration provided by TinyOS 2.1.1 for AT86RF230 radio >> ( when the RF230DriverHwAck ) avoid the transmission of packets when >> the first Clear Channel Assessment (CCA) fails (see Figure 7-8 on page >> 36 of the AT86RF230 Datasheet ), is this correct? > > Correct. > >> We argued such >> behaviour by looking at the initRadio function ( see >> RF230DriverHwAckP.nc line 273 ). >> Moreover, by looking at initRatio and the AT86RF230 datasheet we >> argued that the AT86RF230 radio is configured to a fixed back-off >> value which is ZERO ( see RF230DriverHwAckP.nc line 274 ), are we >> right? > > Yes. > >> IMPLEMENTATION: >> Considering that all the PRECONDITION statement as correct we decided >> to modify the initRadio funcion of RF230DriverHwAckP.nc source, with >> the changes reported in Giancarlo's mail. In particular, we changed >> the initialization values for the registries XAH_CTRL, CSMA_SEED_0, >> and CSMA_SEED_1 to the default values provided by the datasheet. In >> our understanding, the Giancarlo's initialization values should enable >> up to FOUR transmission attempts when CCA fails and it should enable a >> real random generation of the back-off value to wait before performing >> again the CCA. >> >> So our questions are: >> - Is any of our precondition wrong? > > No, all of your preconditions are correct. > >> - is our implementation correct with respect to the AT86RF230 datasheet? > > I do not know how well you have handled the complexities, especially > regarding the interrupt pins and reading the TRAC_STATUS register. > Well I think that we haven't handled it at all.. because we changed only the lines that I mention and our application uses the Send and Receive interface for the communication > Even if you did everything correctly, there is a subtle problem: you > did not read the errata on page 89. Especially, when you enable > automatic retransmission, then you cannot reliably detect if your > packet has received a matching ACK or not (errata 3), and the TRX_END > interrupt might have some problem (errate 5). All of the workarounds > suggest to set MAX_FRAME_RETRIES to 0 and implement frame retries in > software. This is what the code does. > > Do you know the source of your packet loss? Yes, we believe to know the source of the problem. It should be related to channel access. In fact, we made some experiment with to identify the source of the problem. The simplest configuration which shown the packet loss was the following. A network composed by 4 node, a sink (connected to the PC), a timer node, and two leaves nodes. The timer node was sending a beacon packet once every second, while the leaves nodes when received the beacon packet they answered by sending a packet to the sink. The result of the experiment shown a packet loss of 50% of the packet sent by the leaves node to the sink, with an equal distribution between the leaves. > Did you try to fiddle with the software collision avoidance algorithm? Which "software collision avoidance algorithm" are you referring to? How can I fiddle with it? As I mentioned above, please consider that in our scenario we do not need the ACK. >> - does any piece of code in TinyOS override the CCA behaviour? > > No, it should not. As far as I know, your implementation should work. > Actually, our implementation does not seem to work. In fact, the packet losses are mostly the same. > Best, > Miklos > >> >> Best regards, >> Stefano "Kismet" Lenzi >> >>> >>> On Tue, Jun 8, 2010 at 6:37 PM, Giancarlo <giancarlo.ri...@gmail.com> wrote: >>>> I'm a newbie TinyOs programmer and i'm searching advice/help to use >>>> CSMA/CA under IRIS. >>>> >>>> I need a low packet loss to track continuos data from sensors. >>>> I've seen on AT86RF230 chip manual that i need to use Extended >>>> Operating Mode , that i need to initialize registers 0x2C (XAH_CTRL) >>>> ,0x2D (CSMA_SEED_0) ,0x2E (CSMA_SEED_1). >>>> On TinyOs source code (2.1.1) i made the (hoped) according modifications : >>>> >>>> DEFINEd in RF230DriverLayer.h Extended Operating Mode by RF230_HARDWARE_ACK >>>> >>>> In RF230DriverHwAckP.nc I wrote in the three registers values >>>> according with the chip manual , by the way i found XAH_CTRL and >>>> CSMA_SEED_0 initialized to 0 and no trace of initialition of >>>> CSMA_SEED_1 >>>> >>>> in this way (btw chip reset value) >>>> >>>> uint8_t CSMA_retry = 56; >>>> uint8_t CSMA_seed_init = 194; >>>> uint8_t CSMA_seed_0init = 234 >>>> . >>>> . >>>> . >>>> writeRegister(RF230_XAH_CTRL, CSMA_retry); >>>> writeRegister(RF230_CSMA_SEED_0, CSMA_seed_0init); >>>> writeRegister(RF230_CSMA_SEED_1, CSMA_seed_init); >>>> >>>> Recompiled, flashed , no improvements , packet loss levels are the >>>> same than before. >>>> >>>> Am i doing well or i just making some errors? >>>> >>>> thanks for any advice >>>> >>>> Giancarlo >>>> _______________________________________________ >>>> 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 >>> >> > _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
