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)

> 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.

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? Did you try to fiddle with
the software collision avoidance algorithm?

>  - does any piece of code in TinyOS override the CCA behaviour?

No, it should not. As far as I know, your implementation should work.

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

Reply via email to