• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 8 replies
  • Subscribers 74 subscribers
  • Views 2976 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 205129
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Gazell - Lots of failed to pair attempts

DonaldInspiro

Hello,

We are having problems with Gazell pairing. Both the host and the device are using the Gazell stack from the nRFgo SDK 2.3.0.10040 ported to run on an Atmel SAMD20J18 connected to an nRF24L01+.

During the pairing process, the negotiation of the host address fails a lot. When the host address is finally received, the process fails to get the host ID.
The strange thing is, that when pairing has succeeded, the encrypted commands are always send succesfully without fail. (which seems to indicate that sync and freq hopping works properly)

Pairing power has been set to max so distance between the devices (~10cm) should not be a problem.

Pairing requests are not always received in the host. If a pairing request is received by the host, it does not guarantee that the host address is received in the device.

Do you have any idea how we might improve the succesrate for pairing?
What Gazell parameters might we look into for tweaking?

Best regards,

Donald

  • 0

    Hi Donald

    Do you have any nRF24LE1 kits available, so you can test the original SDK implementation and compare it to the Atmel implementation for the nRF24L01+?

    What is the clock frequency of your Atmel processor?

    The pairing procedure is a bit timing sensitive, and if I am not mistaken there are some crude delay functions in GZP that might change when using a different MCU. 
    Most likely your issues are caused by packets being sent at different times after porting. 

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    Hello Torbjørn,

    I do not have a nRF24LE1 reference kit available.
    The Atmel SAMD20 is configured to run at 48MHz, but the delay method has been ported to delay the correct amount of time.

    Could you provide me with the correct timings for the pairing process so that I can check which timings might need re-configuring?

    Best regards,
    Donald

  • 0 in reply to DonaldInspiro

    Hi Donald

    I did some testing on the device side, and changed the code to toggle a pin inside the gzp_delay_rx_periods(..) function. 

    During pairing I see two delays on the device side, one following the other. The first delay is approx. 200ms long, and the second one is 352ms long. In between them there is a short break of 3.5ms. 

    The example is based on the dynamic pairing example in SDK v15, using default settings only. 

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    Hello Torbjørn,

    I have also added toggling of an IO pin an I see the same delays (212ms & 320ms). However, since the system address handshake fails, the time between the delays is 92ms and the 350ms delay is executed twice (which seems to match the implementation of gzp_address_req_send() in gzp_device.c)

    After multiple retries I had a successful transfer of the system address and the time between the delays was reduced to 19ms. In this instance I also had just 2 delays (213ms and 374ms).

    Best regards,
    Donald

  • 0 in reply to DonaldInspiro

    After also adding IO pin toggling to the host, I noticed that the ACK payload is written way too late (1600ms after receiving the initial request). The bulk of the delay seems to be caused by the while(gzll_get_state() != GZLL_IDLE) statement in gzp_host.c. Could you explain what events influence the gazell state? And what might possibly be the reason for the long delay?

    Best regards,
    Donald

Related
Terms of service