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

DTM test w/ nAN34 examply.py

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

  • 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
  • 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

  • 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 

Related