BLE Sniffer dropping packets.

[Robin]

Hello Nordic World,

We are attempting to use the Nordic Sniffer app on a DK52 board to sniff and troubleshoot BLE communication issue with our board/app and iphone/app.  During sniffing we can also watch a display on the iPhone that shows a transmitted count value.  When inspecting the packets for each transmission, we find missing packets on the Wireshark display that the iPhone properly displays the count for.  Obviously the packet was sent. 

Why might this happen?  I have a suspicion that it may be dropped on the USB transaction, but have no way to confirm this.

Any help is greatly appreciated,

Thanks to all,

Robin @ TL

[Sigurd]

Hi,

Could you save and upload the sniffer traces you suspect are missing packets?

[Robin]

Hello Sigurd,

I have attached a short capture file with a missing packet.  if you look at the value column  you will see that there are two values shown at packet 1 and packet 134,  There should have been another packet displayed at 69.  The packet was definitely transmitted, as it was received and shown on the master within the load of these packets is a string message with a countdown.  The countdown value in packet 1 is  "64".  The countdown value in packet 134 is "62".  There should have been a load at packet 69 with the a countdown value of "63".

Thank you again,

Robin @ TL

.missing data packet.pcapng

[Sigurd]

Hi,

Yes, I agree. For event counter #3022 /master packet#68, the slave response is missing. The NESN and SN is correct, so it was only the sniffer that missed this packet.

The sniffer should be able to handle the connection configuration and the throughput shown in the sniffer-log, so my main hypothesis is that the sniffer lost the packet due to 2.4 GHz noise.

[Robin]

Hi Sigurd,

Mysuspicions are more in line with the post below from Torsten.  Do you know of any way to over come this shortcoming such as a higher end DK board, or slowing down packet sends ? (we don't need high throughput),  We too cannot come up with the high cost of any of the commercial units we have been able to find.

Thank you kindly,

Robin @ TL

[Sigurd]

Robin said:

Do you know of any way to over come this shortcoming such as a higher end DK board, or slowing down packet sends ?

Well, in the case that this is actually not due to 2.4 GHz noise, then the following items might help to mitigate the issue.

1. Make sure to use the latest nRF Sniffer firmware (As of today, this is version 3.0.0)

2. Make sure that the Segger J-link chip on the DK is running the latest J-link OB firmware. Download the latest J-Link Software and Documentation Pack. Open J-Link Configurator(JLinkConfig.exe), right click on the probe/programmer, and click "update firmware" to make sure that latest firmware is flashed.

[Robin]

Sigurd,

Are you in agreement with the stated case that the DK board cannot handle the requisite usb traffic?  As much as it appears this may be the problem, I find it hard to believe Nordic would offer such a solution, and the data density in our packets is very low.  We do need a more stable solution, but if you're well convinced that the DK board can handle this app, I will start investigating elsewhere.

Thank you again

Robin @ TL

[Sigurd]

Robin said:

Are you in agreement with the stated case that the DK board cannot handle the requisite usb traffic? 

No. Not in your case. Your sniffer log is very different from Torsten's. The sniffer log you posted, shows 1M PHY with very little data being sent. The Segger J-link chip on the DK should be able to handle this traffic. My main hypothesis is still that the sniffer lost the packet due to 2.4 GHz noise.

[Robin]

Sigurd,

Thank you again.  FYI, I may have found a faulty USB cable connection.  Yet to verify against the sniffer, but definitely a problem cable.

Robin @ TL

[Robin]

Hello once again Sigurd,

You may close this case.  I found a faulty USB cable in my system.

Continuous Gratitude,

Robin @ TL