dtm data sent

RE: dtm data sent

FormerMember — Fri, 03 Mar 2017 08:54:23 GMT

The frequency of operation is set by the tester, and sent to the DUT (via f.ex. UART) when starting the test.

RE: dtm data sent

Matej — Thu, 02 Mar 2017 16:09:26 GMT

dtm command is 16 bits long... combined from cmd (bit 15 and 14; reset, receiver, transmitter and test end), frequency (bits 13:8 channels from 0 to 39), length (bits 7:2 from 0 to 37) and payload (bit 1 and 0 - prbs9, 0x0f and 0x55)...

So while testing I noticed that not matter what length or payload I choose on receiver side, because it's parsed from received data (which was set on transmitter side)... now I'm wondering, if it is important to set frequency/channel on reciever side or its listening on all chanells from 0 to 39?

RE: dtm data sent

FormerMember — Thu, 02 Mar 2017 14:04:54 GMT

What do you mean by frequency?

RE: dtm data sent

Matej — Thu, 02 Mar 2017 09:37:01 GMT

I run debuger and actually check function check_pdu... and m_pdu.content contains the which pattern was received and it's length... so when i run receiver manually via dtm cmds, it does not make sense about setting the pattern and length because its read out from received packet... what about a frequency?

RE: dtm data sent

FormerMember — Thu, 02 Mar 2017 08:21:44 GMT

Okay, I see. If you run the receiver chip in debug mode, does it increase the number of received packets even if the bit pattern is wrong?

RE: dtm data sent

Matej — Thu, 02 Mar 2017 08:01:36 GMT

No, we are not using py scripts, because guys in production performs a lot of other tests and whole test app is written in .net... and it's easier for them to integrate dtm test to existing app and sending dtm cmds via serial port... but it seems that there is some strange behaviour...

RE: dtm data sent

FormerMember — Wed, 01 Mar 2017 12:20:29 GMT

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 %.

RE: dtm data sent

Matej — Wed, 01 Mar 2017 10:13:27 GMT

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!

RE: dtm data sent

FormerMember — Wed, 01 Mar 2017 09:59:27 GMT

How do you do that test?

RE: dtm data sent

Matej — Thu, 23 Feb 2017 07:44:09 GMT

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.

RE: dtm data sent

FormerMember — Thu, 09 Feb 2017 14:16:22 GMT

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

RE: dtm data sent

Matej — Thu, 09 Feb 2017 13:47:19 GMT

I have one more question - about testing multiple boards - at the same time... If golden sample is transmiter, then all testers are receivers - then in theory all of testers should have the same number of received packets right? But if receiver works fine - we can not conclude that also transmiting works fine... What do you advise to test multiple boards at the same time? if it's even possible

RE: dtm data sent

Matej — Thu, 09 Feb 2017 13:22:01 GMT

Kristin, thank you for rsp... but this self._calculateTimeForPackage function in py always returns 0.625 so I'm on the same if I count number of calls for dtm_wait() - which returns each 0.625 ms... Now I'm wondering if it is possible that for some reason transmitter could not send out a packet? Then maxpackages would be a higher, then a number of packets that were sent out... In that case we can't detect if problem is in transmiter of receiver - but we should trust the golden sample and thats it... Now I get it ;) Thank you once again Kristin!

RE: dtm data sent

FormerMember — Thu, 09 Feb 2017 12:24:28 GMT

For the transmitter test, the packet error rate is calculated in the upper + lower tester only, based on the duration of the test time and the number of packets received. In the python script, the packet error rate is calculated the following way:

def _calculatePER(self, receivedPackages):
	"""Calculates the PER"""
	maxpackages = int (round(self.runtimeinms / self._calculateTimeForPackage ()))
	lostpackages = maxpackages - receivedPackages
	lostpackages = max(0, lostpackages)
	self._debug("Received: %s Max: %s Lost: %s" % (receivedPackages, maxpackages, lostpackages))
	per = int (round((float(lostpackages) / float(maxpackages)) * 100))
	return per

RE: dtm data sent

Matej — Thu, 09 Feb 2017 08:42:41 GMT

Thank you for reply Kristin! What about an idea to add counter to dtm_wait function in ble_dtm.c file? (Incrementing it before for loop - in case that m_state is equal to STATE_TRANSMITTER_TEST)

RE: dtm data sent

FormerMember — Wed, 08 Feb 2017 11:56:58 GMT

For the transmitter test, there is no report of the number of transmitted packets. The number of transmitted packets is calculated based on the time the test is running and the interval between the packets. That method will result in a small error, but if the test is running for some time, that error can be discarded.