DTM test w/ nAN34 examply.py

[Hsu]

Hi Sir,

For EN 300 328 V2.1.1, I reference below setting.

https://devzone.nordicsemi.com/f/nordic-q-a/21643/en-300-328-v2-1-1-receiver-blocking-test-setup/84959#84959

.

IC: 51822

PCB: nRF51-DK x 2

SDK: SDK_12.3.0\examples\dtm\direct_test_mode\pca10028\blank

I follow above link and assign the "RADIO_MODE_MODE_Nrf_250Kbit" to "m_radio_mode" in "ble_dtm.c"

# ble_dtm.c

static uint8_t           m_radio_mode        = RADIO_MODE_MODE_Nrf_250Kbit;//RADIO_MODE_MODE_Ble_1Mbit;

As download nAN34_v1.01.zip, I modify the COM port to examp.py, and run the command as below.

py -2 example.py

But I got the high packet loss as show below.

Any configuration I miss for 250K test? (1M link speed is OK, TX/RX PER is 0%)

Thank you.

BRs, Han

[bjorn-spockeli]

HI Hanyu, 

can you reduce the test packet length to 5 and the runtime to 50, i.e. 

    setup['Length'] = 5                    #Length of the test package

    setup['Runtime'] = 50                  #How long the Receiver should be receiving. In ms

and see if that improves the PER?

Best regards

Bjørn

[Hsu]

Hi Bjørn,

It improves the PER, thanks for your help.

Based on the original setting, the 10 bytes should not long.

I think it should work at 250K/1M/2M link speed.

Could you share why reduce the length/runtime can improve the PER?

Thank you.

BRs, Han

[bjorn-spockeli]

Hi Hanyu, 

the an empty DTM test packet is 10 bytes, so adding a payload length of 10 will result in a total packet length of 20bytes. When using the 1Mbit Radio mode, the radio will use 8uS per byte, so 20byte * 8uS/byte = 160uS. However, when using the 250kbit mode, the transmission time per byte is increased by a factor of 4, i.e. 32uS per byte, so the same 20byte packet will now take 32uS/byte*20byte = 640uS to transmit. 

If we look at the DTM code from SDK 12.3.0, we can see that the code assumes that 1Mbit is used as it uses the 8uS/byte factor to calculate the transmission time of a packet of a given m_packet_length.  

 // Set the timer to the correct period. The delay between each packet is described in the
        // Bluetooth Core Spsification version 4.2 Vol. 6 Part F Section 4.1.6.
        if ((m_packet_length + DTM_ON_AIR_OVERHEAD_SIZE ) * 8  <= 376)
        {
            mp_timer->CC[0]       = 625;                        // 625uS with 1MHz clock to the timer
        }
        else if ((m_packet_length + DTM_ON_AIR_OVERHEAD_SIZE ) * 8  <= 1000)
        {
            mp_timer->CC[0]       = 1250;                        // 625uS with 1MHz clock to the timer
        }
        else if ((m_packet_length + DTM_ON_AIR_OVERHEAD_SIZE ) * 8  <= 1624)
        {
            mp_timer->CC[0]       = 1875;                        // 625uS with 1MHz clock to the timer
        }
        else
        {
            mp_timer->CC[0]       = 2500;                        // 625uS with 1MHz clock to the timer
        }

        // Configure PPI so that timer will activate radio every 625 us
        NRF_PPI->CH[0].EEP = (uint32_t)&mp_timer->EVENTS_COMPARE[0];
        NRF_PPI->CH[0].TEP = (uint32_t)&NRF_RADIO->TASKS_TXEN;
        NRF_PPI->CHENSET   = 0x01;
        m_state            = STATE_TRANSMITTER_TEST;

In our case the DTM code will send a packet every 625uS as the total packet length is 20byte, but each packet will take 640uS when using the 250kbit mode. 

In the python code it also assumes that a packet will maximum use 625uS per packet.

	def _calculateTimeForPackage (self):
		"""Calculate how long time from start of one package to the start of next"""
		return 0.625*2

So I think if you modify the DTM code(dtm_cmd() in ble_dtm.c) as shown below to take in to account for the 4 time increase in transmit time. 

 if ((m_packet_length + DTM_ON_AIR_OVERHEAD_SIZE ) * 32  <= 376)
        {
            mp_timer->CC[0]       = 625;                        // 625uS with 1MHz clock to the timer
        }
        else if ((m_packet_length + DTM_ON_AIR_OVERHEAD_SIZE ) * 32  <= 1000)
        {
            mp_timer->CC[0]       = 1250;                        // 625uS with 1MHz clock to the timer
        }
        else if ((m_packet_length + DTM_ON_AIR_OVERHEAD_SIZE ) * 32  <= 1624)
        {
            mp_timer->CC[0]       = 1875;                        // 625uS with 1MHz clock to the timer
        }
        else
        {
            mp_timer->CC[0]       = 2500;                        // 625uS with 1MHz clock to the timer
        }

and multiply the total time from one packet to the next in the python script by 2

	def _calculateTimeForPackage (self):
		"""Calculate how long time from start of one package to the start of next"""
		return 0.625*2

then I think you should get better results with the payload length set to 10 in the python script. 

Best regards

Bjørn 

[Hsu]

Hi Bjørn,

It's clear.

Thank you.