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

dtm data sent

Hi,

I'm using pca10040 and prebuild hex with s132 from sdk 12. Now I'm wondering how can I get number of sent data? If I set it as transmitter - send via uart 0x8094 i get response 0x0000 and when i stop test with 0xc000 i get success status 0x8000 - how could i get number of bytes that were sent out?

On the receiver side, I start receiver test with cmd 0x4094 and also get response 0x0000. When I stop test with 0xc000 i get response 0x87e7...

So after py code check I guess that rcv get 0x07e7 packets, but how should i found out how many was it sent on transmitter side?

Thank you for info.

BR, Matej

  • FormerMember
    0 FormerMember in reply to FormerMember

    The interval between each packet depends on the packet length, see BT Core Specification v. 4.2, vol 6, part F, section 4.1.6. Therefore self._calculateTimeForPackage() will always return the same value.

    If there is one transmitter and multiple receivers, all receivers should theoretically receive the same number of packets. In reality, it may however vary slightly due to packet loss.

    If the receiver works fine, I would think that the transmitter works fine as well. To test if the receiver and transmitter works, you can test a BLE application. In a BLE applictaion, the radio will use both RX and TX mode.

    I don't know how it will work to use do multiple DTM test at the same time in the same environment. I would think there could be some potential interference problems..

  • One more questions about dtm payload... On the receiver side I choose 0x0f payload, but on transmitter side I choose payload PRBS9 ... but the number of sent/received packets are still matching... so the content of message is not checked? Thank you for info.

  • I'm using PCA10040 with direct_test_mode_pca10040_s132.hex and usb dongle with direct_test_mode_pca10028_s130.hex prebuild hex files from nRF5_SDK_12.0.0_12f24da...

    Then i run receiver as 0x4095 and i get rsp 0x0000; after that i run transmitter 0x8094 and i get rsp 0x0000. After that i stopped transmitter at first with 0xc000 and i get rsp 0x8000; at the end i stopped receiver with 0xc000 and i get rsp 0x9d2c - what means reporting event 0x8000 and 0x1d2c received packets...

    In that case pattern are different and I assume that number of received packets should be 0... Please correct me if I'm wrong.

    Thank you!

  • FormerMember
    0 FormerMember in reply to FormerMember

    The DTM example checks that bit pattern is correct, using check_pdu(): in dtm_wait() (ble_dtm.c), the number of packets successfully received is only increased if the CRC is okay and check_pdu() is true.

     if ((NRF_RADIO->CRCSTATUS == 1) && check_pdu())
                {
                    // Count the number of successfully received packets
                    m_rx_pkt_count++;
                }
    

    From what I understand, you are not testing using the python script that comes with nAN-34? If using that script, the chosen bit pattern will be transmitted to both the upper tester and the DUT.

    To check why it doesn't give the correct result on your side, I would recommend you to run the receiver in debug mode. It will corrupt the results if hitting a break point, but it can help understanding why the PER is 0 %.

Related