This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

GZLL host not responding to more than 3 pipes

I am trying to set up a GZLL star network on the 51822. I understand that a single GZLL host can support up to eight devices but whenever my host attempts to communicate with more than 2 devices each communicating under a unique pipe the host controller seizes. It is still receiving packets from the other devices but it is unable to add any ACK packets to its tx fifo buffer.

Are there any examples of a host that will communicate with 8 devices simultaneously? Am I correctly understanding that each device should communicate via its own pipe?

  • Hi,

    It is correct that each device shall communicate with the host using an unique pipe. If you setup two devices on the same pipe (ie: same RF address), you will get a collision and your communication will not work properly.

    If I understand correctly, the communication works with 8 devices -> 1 host, but the ACK payload is unreliable? If yes, could you please elaborate on what's happening?

    Note that the host only has a 3 payload deep buffer in the FIFO. This means that if you upload 3 payloads on one pipe, where the device seldom sends payloads to the host (device does not poll the host often enough compared to other devices), you will use up all the space and block other devices from receiving an ack-payload.

    In general; it is very important to check your error codes given by the gazell function calls to see if there is anything that's failing.

    Cheers, Håkon

  • Thank you for your response Håkon. I am using the example project "gzll_ack_payload". I have one programmed with the host firmware and three programmed with the device firmware. The pipe in each of the devices is set to 0, 1, and 2.

    I power up the host first. I then power up device with pipe 0 and everything is fine. I then power up device with pipe 1 and everything is fine. The moment I power up the device using pipe 2, all communications cease. This works invariably with the devices powering up in any order (e.g. If I power up 1 and 2 first and pipe 0 last then everything freezes when pipe 0 comes online).

    EDIT: It seems the host is returning errors on 'nrf_gzll_add_packet_to_tx_fifo'. The error return value corresponds to NRF_GZLL_ERROR_CODE_INSUFFICIENT_PACKETS_AVAILABLE. This only happens when the third pipe tries to communicate with the host.

  • Hi Sean, That makes sense. You have filled up your FIFO, and the device is not fetching the ack-payload fast enough. If you instead send two payloads from the device.

    1. prepare ACK-payload
    2. dummy-payload to fetch payload

    Then it should work properly.

    Cheers, Håkon

  • Hi Håkon, thank you for the response. I don't really understand what the device sending two payloads is supposed to accomplish or how that would be implemented on the host side. My host is the one reporting the insufficient packet error so wouldn't I need to be doing something on the host side to alleviate this issue?

  • This is because you have limited space in your FIFO on the host side. You cannot upload more than 3 ACK-payloads. To resolve this, you will have to handle this on the host and device side. The device can simply send the command "Prepare an ACK payload for me", and then the host recognizes this command and uploads a packet into the host-FIFO. Then the device can send another payload to fetch the ACK-payload from the host. Or you can do this the other way around. Device can send payload #1, then if it has not received an ACK-payload, it sends dummy-payload #2 to retrieve the ACK-payload.

Related