IEEE 802.15.4 ACK Frame seems to get lost

RE: IEEE 802.15.4 ACK Frame seems to get lost

MeisterBob — Wed, 20 Jan 2021 14:41:03 GMT

I tracked it down to ack_is_requested() in nrf_802154_core.c. In this function the destination address is compared to the own address to determine if an ack is requested (Yes, that has nothing to do with the ack request). I replaced this with the implementation from the v1.9.0 driver - just check if the ack request bit is set. Maybe I should update the driver in my environment.

RE: IEEE 802.15.4 ACK Frame seems to get lost

MeisterBob — Wed, 20 Jan 2021 09:43:49 GMT

I threw the debugger onto the problem and checked the NRF_RADIO register in both cases. The Registers differ in 4 values. When I receive an ACK frame:

EVENTS_DEVMISS: 0x00000001
EVENTS_CCASTOPPED: 0x00000000
RXCRC: 0x000028b4
RSSISAMPLE: 0x0000001c

When the ACK is NULL the values are

EVENTS_DEVMISS: 0x00000000
EVENTS_CCASTOPPED: 0x00000001
RXCRC: 0x000096f5
RSSISAMPLE: 0x0000001b

RXCRC and RSSISAMPLE need to be different, maybe the two events help finding the problem.

RE: IEEE 802.15.4 ACK Frame seems to get lost

MeisterBob — Mon, 18 Jan 2021 16:09:59 GMT

I changes the code from above (Line 9):

void nrf_802154_transmitted_timestamp_raw(const uint8_t *p_frame, uint8_t *p_ack, int8_t power, uint8_t lqi, uint32_t time) {
  if (p_ack != NULL) {
    /* ACK received, check if pending bit is set */
    ack = (p_ack[FRAME_PENDING_OFFSET] & FRAME_PENDING_BIT) ? IEEE802154_ACK_PENDING : IEEE802154_ACK_NO_PENDING;
    nrf_802154_buffer_free_raw(p_ack);
  } else {
    if ((p_frame[1] & 0x20) == 0x20) {
      /* the ACK frame seem to have been lost */
      ack = IEEE802154_ACK_INVALID;
    } else {
      /* no ACK requested */
      ack = IEEE802154_ACK_NO;
    }
  }
}

devzone.nordicsemi.com/.../ack.pcapng

The first Frames have the ACK request bit set but there is no ACK, nrf_802154_transmit_failed() is called. Frame 5 (seq_no 3) is a Ping from the nRF device with ACK request that is ACKed with pending Bit set (Frame 6). As it should be, nrf_802154_transmitted_timestamp_raw() is called with the p_ack set and ack is set to IEEE802154_ACK_PENDING. So far so good.

All the other Frames have the ACK request Bit set as well and nrf_802154_transmitted_timestamp_raw() is called as it should be, but p_ack is 0x0 and ack is set to IEEE802154_ACK_INVALID. Imho that shouldn't happen. If there is an ACK, p_ack should be set, if there is no ACK nrf_802154_transmit_failed() should be called instead of nrf_802154_transmitted_timestamp_raw().

RE: IEEE 802.15.4 ACK Frame seems to get lost

Edvin — Mon, 18 Jan 2021 14:57:13 GMT

Hello,

I am not sure I understand your reasoning. (I have not tried to set it up like this on this level). Do you have any projects that you used to conclude with this? And how do you expect it to work? Also, do you have a sniffer trace of this? Do you see from the sniffer trace that the packets require ACKs? And does the sniffer trace contain any ACKs?

Best regards,

Edvin