CC2650: Packet error rate test problem

What sort of environment is the test run in? Even if the test is conducted the board used in the test could pick up other signals from the air. In other words, is the DUT placed close to a different source sending on 2.4 GHz? (wi-fi etc) Is it the same result regardless of channel used?

Hello Torstein,

Thank you for responding.  Here are the comments from the customer:

------------------

The test is being run as conducted and the same behavior happens even when the frequency command is 0x0947 which is 3275 MHz (in the MBANS allocation) where there is nothing else OTA. 

Here is a screenshot of the test running:  (Note that the rate is only 4 packets/sec) and this is early in the capture so only 31 packets have been sent, however the “Received not OK” shows up as 1498.

------------------

- David

 

I don't see the same on my side. I used two CC2650 LPs and selected 802.15.4. The LPs has the on board antennas selected. On my desk I get a lot of false packets on the RX but far from the number you see, I get one false packet every few seconds. Then I went into the lab and there I see a false packet each 30 seconds or more. I tested the lowest channel, one channel near the middle and the last.

Thank you for the reply TER.  I just repeated the test here with the TI CC2650EM=7ID v1.2 boards.  I was thinking that these boards might behave differently as my original test was with my layout which uses the JTAG connection for the test.

However, the results are similar.  Please see the picture I posted.  The sequence number is 367, the received OK count is 377 and even though there are only a few errors in the scrolling display, the "Received Not OK count is 9611.   Again, it appears that this count increases abruptly when you see an error appearing in the status window.  This adversely effects the BER.  

I suppose I could dump the data to a file and compare with the known transmitted sequence and calculate BER manually.  I don't know how your algorithm computes BER without the receiver knowing what the transmit payload is.  It would be great if that was an editable field that we could enter.  

Could you do a screen dump of the full window on both the RX and TX side?

Why did you delete the screen dump you uploaded?

I talked to tools and the received not ok could be confused if you receive a out of sequence packet. Eq, if you have received packet number 034 and the next one has counter value 100 Studio assumes that you have lost 66 packets. Interestingly I don't see the same, see screenshot:

Update -

I deleted Friday's screen dump because I remembered that I had mistakenly set the wrong target configuration.  I have been switching back & forth between the TI board and my own prototype.  The TI board is a 7ID based unit with DC/DC enabled and my board is a 5XD without DC/DC enabled.  So, this morning I retested the TI board with the correct settings.  Here are the new pictures.  It still appears to jump the "Received Not OK" count upon an out of sequence packet.  It does seem strange that the sum of the packet count and the "Received Not OK" count equals the sequence number reported in the bad packet. It seems that the tool is not able to ignore out-of-sequence packets even if the correctly received packets are all there as indicated by all of the correct sequential numbers are there.

BTW, I am using SmartStudio 7 version 2.7.0 on Windows 10 1703, 64 bit,  version 15063.074.  The processor is an Intel Core i7 -4800MQ @ 2.7 GHz with 24 GB RAM (on the Rx end).  The Tx end is an HP Z240 desktop workstation using the same version of SmartStudio with Windows 10 1607, 64 bit,  version 1493.1770.  The processor is an Intel Xeon E3 1245 v5 @ 3.5 GHz with 16 GB RAM.

In this case I think the best advice is to dump data to file and filter out the short packets on the sensitivity limit to do the calculations.

Have you tried to shield the DUT and/ or move it to a different room for the test to see if the amount of not ok goes down?

I ran the test with the Rx end in a shielded box (Ramsey STE2900) with -90 dBm into my DUT.  It ran for over 200 seconds with no errors, but got an out-of-sequence packet which brought the sequence number from 9856 to 62281.  The BER was "0" before that and 0.98 % after.  Here is the capture:

I noticed that your screen capture shows the Rx as 89 and the Rx Bad as 11 even though the scrolling status went from sequence number 50 to 24968. Can you say which version of the tool you are using?

I'm using 2.7.0.

At least it looks like you would be able to do your tests with a shielded room even though it's not optimal.

Torstein,

I was able to reproduce the problem in my office on a CC2650 Launchpad.  I have only one Launchpad, so I am not actually transmitting anything.  Instead, I just put the device into RX mode using SmartRF Studio v2.7.0.  The device receives some random packets from someplace.  This can take anywhere from a few seconds to several minutes.  Here is an example of what happened:

The device received the first valid packet, #18656 at 11:40:18.  Some 2.5 minutes later, it finally received another valid packet, #64914.  SmartRF Studio took the number of missing packets, 64914 - 18656 - 1 = 46257 as "Received Not OK" and used them in the packet error rate computation (which now stands at 100%).

This seems consistent with what you previously said about SmartRF Studio getting confused if an out of sequence packet is received.

OK, fair enough.  But the question is, how/why is this affecting the "Bit Error Rate?"  The bit error rate was zero prior to receipt of the second packet.  It then jumped to 1.14% (as it now shows).  I can understand the missing packets affecting the Packet Error Rate, as SmartRF Studio treats the missing packets as not being received OK.  But for bit error rate, something else seems to be going on.

Regards,

David

One more thing.  SmartRF Studio does not always treat missing packets as being received not OK.  Here is a screen shot of multiple out-of-sequence packets being received.  The received not OK count stands at zero, as does the bit error rate:

- David

The last screenshot is what I see when I tested this. When I discussed this with Tools they didn't have a clear explanation of why it's a difference in how the calculation is done. For me it also look like a 2.4 GHz issue (or rather due to a lot of traffic on the air ) since I have never seen this at all testing at sub 1 GHz.