Understanding DTM example

[eyalasko]

Hello, 

As our product (nRF52832, SDK14.2) is heading to radio certification, I was playing around with the DTM example but have some open questions.

I've flashed the DTM example to our device (DUT) and into a DK (PCA10040) that should emulate the tester.

Both the DUT and the 'Tester' are connected to serial terminal running on a PC (see figure 2 in nAN34)

In order to run LE_Receiver_Test on the DUT I do the following:

• Send 'Test RESET' command to both DUT & Tester
• Sending 'LE_Transmitter_Test' command to the Tester - Command code 0x8080 (Channel = 0, length = 2, packet type = 0)
• Send 'LE_Receiver_test' command to the DUT - Command code 0x4080 ((Channel = 0, length = 2, packet type = 0)
• After few seconds stops the DUT by sending command 'LE_Test_End' (0xC000)

I get a 'packet response event' from the DUT with some number (MSbit = 1 , e.g. 0x83B3).

For some reason beyond my grasp, I get similar packet response even if length & packet type values do not match between the Tester and DUT

My questions are:

• How fast does the transmitter test sends out test packets ?
• Do the packets number reported in the packet response events reflect the true number of good packet received?
  if so, how come that the number is not consistent. I get relatively large numbers even for very short receiver test (see screen caps)
• How can I calculate the PER as I don't know how many packets were transmitted?
• Strangely, many received packets are reported even if transmitter and receiver's test parameters are not matching... 

Thanks for any advice.

[Håkon Alseth]

Hi,

 

 

How fast does the transmitter test sends out test packets ?

This depends on the packet size. It varies from 625 us to 2500 us, in 625 us steps. 0 to 37 bytes payload length gives 625 us frame.

See Vol 6, part F, chapter 4.1.6 for details on the length of a frame, as there's a formula for calculating this there.

 

Do the packets number reported in the packet response events reflect the true number of good packet received?
if so, how come that the number is not consistent. I get relatively large numbers even for very short receiver test (see screen caps)

 Yes, it gives back the overall packets it received. This will differ based on how long the test has been running, so you can use that time to calculate how many packets you expected to receive vs. what you actual received.

 

How can I calculate the PER as I don't know how many packets were transmitted?

See the above.

 

Strangely, many received packets are reported even if transmitter and receiver's test parameters are not matching... 

 The receiver has a certain address that it expects to receive packets on (0x71764129 in little endian), and regardless of the payload type, it shall receive the data, provided that your radio PHY is in order.

 

Kind regards,

Håkon

[eyalasko]

Thanks for the super-fast response.

If I understand correctly - packet received correctly is a packet where the packet address received correctly even if the payload has errors?

Is there a way to extract the received packet and verify the payload in software for better PER calculation?

Thanks again.

[Håkon Alseth]

eyalasko said:

If I understand correctly - packet received correctly is a packet where the packet address received correctly even if the payload has errors?

Sorry, forgot to mention the CRC checking. There's a 3 byte CRC attached to the end of the payload which is checked in firmware, and it will only tag the packet as "good" if the CRC matches with the payload content.

eyalasko said:

Is there a way to extract the received packet and verify the payload in software for better PER calculation?

No, DTM does not include this possibility, as it should already be done on the device-under-test (DUT) side. 

 

Kind regards,

Håkon