AC9260 drizzle creating a connection event on BLE, 8265NGW - data length extension problem with last Bluetooth driver

[VLebe2]

Hi.

First problem is:

8265NGW - uses same driver for Windows as a AC9260. But changes made in the latest driver regarding time variables for LL_LENGTH_RSP and LL_LENGTH_REQ are not affected by this board.

Question: why?

Second problem is:

AC9260 - after negotiation about connection interval = 10mSec the master must observe this interval since on it, the slave sends notifications, but master sends connection events with very large delays.

This is an analysis of delays:

time between connection intervals <10mSec (2-7) - 26,27%

time between connection intervals 10mSec (8-12) - 12,7%

time between connection intervals 20mSec (18-22)- 4,06%

time between connection intervals >=40mSec (40-275) - 31,86%

at the same time, the position ">=40mSec" includes intervals from 40 to 275 mSec !!!

Obviously, because of this, there is an uneven and very often just a failure delay when sending notifications from slave.

In the experiment, 4 nodes were connected. The transmission rate of each node is 100 packets per second, each packet is 24 bytes length.

Can this problem be solved?

Best regards,

Vyacheslav.

[AdrianM_Intel]

Hello VLebe2,

Thank you for posting on the Intel® communities.  

I will check the information please allow me some time to get back to you.

Regards,

Adrian M.

Intel Customer Support Technician

A Contingent Worker at Intel

[AdrianM_Intel]

Hello VLebe2,

I would like to update the thread.

We have some questions.

Questions:

• Can you please provide us the exact steps you are taking in order for us to test this behavior in our end?
• Can you please also provide sniffer log files?
• Just to make sure and double-check is this new issue happening with the latest driver for Intel® Wireless-AC 9260 21.60.2?

Best regards,

Adrian M.

Intel Customer Support Technician

A Contingent Worker at Intel

[VLebe2]

Hi Adrian.

First, I`m sure that we use last driver 21.60.0.4. Not 21.60.2 because that driver for Wi-Fi.

Steps:

• we have 4 bonded peers
• after peer is powered on, then windows connect to it and our software use that connection to communicate.
• before connect to peers I start wireshark and catch one of peer to log.

Sniffer logs for 8265NGW attached to reply.

In lvi_intel_8xx_dle_shift.pcapng - start row is 10390.

In lvi_intel_8xx_dle_shsolder.pcapng - start row is 1701.

About AC9260 connection event periods see log: lvi_intel_dle_2.pcapng, "Time" row.

[AdrianM_Intel]

Hello VLebe2,

Thank you for your response.

I appreciate the information provided, please allow me some time to update this thread.

Regards,

Adrian M.

Intel Customer Support Technician

A Contingent Worker at Intel

[AdrianM_Intel]

Hello VLebe2,

I would like to update the thread, We are still working on this case.

Can you please provide the following log files so we can further investigate it?

Virtual Snoop Log(HCI) 

ellisys log 

I will send you a private message since those files might contain any kind of personal information.

Best regards,

Adrian M. 

Intel Customer Support Technician

A Contingent Worker at Intel

[AdrianM_Intel]

Hello VLebe2,

We would like to gather some information that will be very useful to continue with the investigation.

Can you please share the following information.

• BTOE: (Bluetooth other end device – the one connecting to Intel BT controller). Can you please confirm if the BTOEs are also Intel BT controller or other non-intel controllers? can you specify if they are laptops or device category?
• Is there a possibility that you can share the script injecting the data periodically?
• Can you please share the Ellisys log files?

Hope to hear from you soon.

Best regards,

Adrian M.

Intel Customer Support Technician

[AdrianM_Intel]

Hello VLebe2,

Were you able to check the previous post? 

Let me know if you need more assistance. 

Best regards,

Adrian M.

Intel Customer Support Technician

[VLebe2]

Hello AdrianM_Intel,

.

1. Other device - is our custom board with bluetooth chip nRF52832 and custom application. It is non Intel controller.
2. Do not understand question. From our device we send notifications to inlel board 100 packets per second. We use 4 or 6 our devices every send by 100 packet to intel.
3. We dont have any Ellisys analysis systems and dont have any Ellisys software.

Best regards,

Vyacheslav.

[AdrianM_Intel]

Hello VLebe2,

Thank you for your response.

Please allow me some time to update the thread, thank you for the information provided.

Regards,

Adrian M.

Intel Customer Support Technician

[AdrianM_Intel]

Hello VLebe2,

I would like to update the thread, we are currently investigating this behavior and we would like to collect more details.

Can you please answer the following questions?

• We would like to know what is the mechanism being used for bombarding the Intel board with 100 packets per second?
• Are you using a custom firmware or a tool which triggers the Nordic BT device to push the packet?
• Can you please share a screenshot how you are sending the packet every 10ms once? Would this require device synchronization?

Additionally all the data that is seen is MIC failure. ( From the sniffer log)

• Can you please capture the sniffer logs with Teledyyne Sodera or Ellisys?
• From the Virtual snoop log(Provided on Feb3) it is very clearly seen that the packet arrival rate from THunderPeak to Host SW was less than 10ms. Is it possible that we are looking into Windows and application delays?
• How are you tracking the oncoming data, apart from the Nordic Sniffer?

Best regards,

Adrian M.

Intel Customer Support Technician

[VLebe2]

Hello Adrian, 

We already submitted all necessary information considering our case in our previous answers.

Unfortunately, our technical team have made a decision to use the solution from other manufacturer, so we don't have enough time to investigate your product. 

I hope we will have the opportunity in the future to work with your solutions more closely. Thank you Adrian for your help and assistance on this important case. 

Best regards,

Vyacheslav