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

Gazell Ack not received after data transfer

I'm working on a very simple Gazell build - basically the gzll_ack_payload example with some of it pulled out, since I'm working on a board with no LEDs or buttons to run that specific build against. It's a board with the nrf51822 onboard

The device is passing a single byte every few seconds with a call to nrf_gzll_add_packet_to_tx_fifo() but following the send, the device always goes into the nrf_gzll_device_tx_failed() call.

On the host side, it's receiving the payload in nrf_gzll_host_rx_data_ready() successfully and calling nrf_gzll_add_packet_to_tx_fifo() immediately after. That call returns success but the device never receives the Ack in return.

Following is my nrf_gzll_host_rx_data_ready() function on the host which is basically pulled straight out of the ack example:

void nrf_gzll_host_rx_data_ready(uint32_t pipe, nrf_gzll_host_rx_info_t rx_info) {

   uint32_t data_payload_length = NRF_GZLL_CONST_MAX_PAYLOAD_LENGTH;   
   packet_received = true;
   pop_ok = nrf_gzll_fetch_packet_from_rx_fifo(pipe, data_payload,
        &data_payload_length);
   ack_payload[0] =  inputVal;    
   push_ok = nrf_gzll_add_packet_to_tx_fifo(PIPE_NUMBER,ack_payload,TX_PAYLOAD_LENGTH);

   // Debug output to serial
   char msg[128];
   sprintf(msg,"%u ", data_payload[0]);
   serial(msg); 

}

The only significant change on the host side is I have enabled UART to pass information instead of the LED feedback from the example. I don't know if that could potentially be causing a conflict... Is there any way I could have configured the host to not return an Ack? I'm at a loss as to how to diagnose this problem. Could anyone give me a push in the right direction, by any chance?

  • Follow up comment on this problem: Actually, the send isn't being fully received, just the first character of the send. I was originally just sending a status bit, but as I tried to send more information, I noticed that if the payload was more than 1 byte, it also wasn't being received properly by the host, so that's likely where it's breaking down.

  • The problem seems to be caused by setting the data rate to 250 kbit incorrectly. Once I switched the data rate back to default, the problem went away and the acks came through without a problem. I shifted my nrf_gzll_set_datarate(NRF_GZLL_DATARATE_250KBIT) call to be before nrf_gzll_init() call and that seemed to work

    Since there's no documentation I can find on setting the datarate, I'm assuming that was the cause of the problem. If anyone can provide me with a link to where I could read a little more on setting gazell parameters like datarate, or just confirm whether I've diagnosed this correctly, I'd appreciate it.

    Thanks.

  • Hi Kevin

    I assume you have read the Gazell user guide? This, combined with the API reference, is all the documentation we have for the Gazell library.

    For 250kbps to work properly you might have to increase the timeslot period, since the packet takes longer to send at the slower bitrate.

Related