Radio test in 802.15.4 -mode

Question

I'm running the SDK 17 radio test example on two nRF52840 DKs. My goal is to do a PER measurement in 802.15.4 -mode. 
 I configure the boards to use ieee802154_250Kbit mode, the same channel and same payload pattern for both boards. 
 I can get the reception to work for a little while. If I tell the sender to send 100 packets, I usually get 100 received packets. But for anything longer the reception seems to stop at some point. 
 
 For instance if I set the transmitter to send 10000 packets (start_tx_modulated_carrier 10000) and monitor the reception by issuing "print_rx"-commands on the receiver, the packet count initially increments but stops at some point. Usually at a few hundred packets. Now if I issue a new "start_rx"-command the packet count again starts to increment from zero (as expected), but again stops at some lowish value. 
 I also tried a lower packet rate by setting the transmitter to duty cycle modulation. If I do "start_duty_cycle_modulated_tx 10", ie 10% duty cycle, it is even easier to monitor the received packet count as it increments slower. But again the count stops incrementing fairly soon. And restarting the rx makes the reception work again for a while. 
 
 If I redo all of the above using ble_1Mbit -mode it all works. I can send 10000 packets and receive 10000 packets. So it seems to be related to the 802.15.4-mode. 
 All testing so far has been done at my desk, with the DKs a few centimeters apart. 
 
 Any ideas on how to make this work would be appreciated.

mrono · Answer

I've tried to compare the radio test examples from SDKs 15.3 and 17.0.2. A lot has changed, but I found something interesting among the changes. In SDK 15.3 the function radio_config writes directly to the radio registers. First it unconditionally writes this to the PCNF1 register: // Packet configuration: // Bit 25: 1 Whitening enabled // Bit 24: 1 Big endian, // 4-byte base address length (5-byte full address length), // 0-byte static length, max 255-byte payload . NRF_RADIO->PCNF1 = (RADIO_PCNF1_WHITEEN_Enabled << RADIO_PCNF1_WHITEEN_Pos) | (RADIO_PCNF1_ENDIAN_Big << RADIO_PCNF1_ENDIAN_Pos) | (4UL << RADIO_PCNF1_BALEN_Pos) | (0UL << RADIO_PCNF1_STATLEN_Pos) | ((sizeof(m_tx_packet) - 1) << RADIO_PCNF1_MAXLEN_Pos); A few lines later it checks if we wanted 802.15.4 -mode, and does this: NRF_RADIO->PCNF1 = (IEEE_MAX_PAYLOAD_LEN << RADIO_PCNF1_MAXLEN_Pos); So it overwrites the previously set PCNF1 configuration. SDK 17 does almost the same thing, but uses a configuration struct: /* Packet configuration: * payload length size = 8 bits, * 0-byte static length, max 255-byte payload, * 4-byte base address length (5-byte full address length), * Bit 24: 1 Big endian, * Bit 25: 1 Whitening enabled. */ memset(&packet_conf, 0, sizeof(packet_conf)); packet_conf.lflen = RADIO_LENGTH_LENGTH_FIELD; packet_conf.maxlen = (sizeof(m_tx_packet) - 1); packet_conf.statlen = 0; packet_conf.balen = 4; packet_conf.big_endian = true; packet_conf.whiteen = true; And again a few lines later, if 802.15.4 was requested: packet_conf.maxlen = IEEE_MAX_PAYLOAD_LEN; But done this way, the previous contents of packet_conf are not overwritten. And PCNF1 ends up different than in SDK 15.3. If I add code to reset the other PCNF1 fields (balen, big_endian, whiteen) to zero, I can receive 802.15.4 packets again. So this looks like a mistake made during refactoring. Although the original way was in my opinion a nasty surprise to leave for the future maintainer. Could someone at Nordic check if I'm on the right track here?

Radio test in 802.15.4 -mode

Consequences

Workaround

Consequences

Workaround