Controlling Nimble BLE Advertising Scan Channels on S3

[jonsmirl]

I know it is a shared radio and it is going to miss packets, but is it possible to get sharing to a point where if I send a BLE packet three times 100ms apart it will get at least one of the three 98% of the time? Wifi is running in STA mode so shouldn't the wifi side have fixed timing windows where it needs to listen?

BTW, under normal conditions, the sensor only reports once every five minutes or so (not once per second like I am testing with). Missing 30 packets in a row would mean missing the sensor reports for over fifty minutes which is way too long.

One way to solve this would be to provide a set of BLE timings such that the BLE receiver is guaranteed to be listening for at least one of the packets. Say I transmit the three packets at 100ms intervals then if the S3 listened for BLE on a 110ms 50% duty cycle it would be guaranteed to be listening for at least one of the packets. If I add a fourth packet at 100ms, then it could listen to BLE for 110ms and wifi for 340ms. But I would need to be told how the ESP core is constructing the duty cycle and windows.

I also want to check out 125Kb BLE Coded Phy for a longer range but I need a bug fix from TI before I can enable it. I am wondering if I can send a single packet with the coded PHY versus three at 1MB.

[irahul]

Hi @jonsmirl

It's not only scan windows to take into consideration for scanning in BLE. They operate with a scan interval and a scan window, where it will scan for the duration of the scan window every scan interval. However, BLE isn't a surefire protocol where you can expected a scanner to receive 100% of advertising packets no matter what you do, since the 2.4GHz band is generally a busy/noisy band and there is no ACKing in just BLE scanning. If you need no packet drops I would suggest connecting to the device and use ACKing to make sure every packet is received properly.

[jonsmirl]

My goal is to send three ADV packets and get at least one of them 95% of the time. The sniffer sitting next to the S3 is dropping zero of these packets, the radios are only 40cm apart. I believe the high drop rate I am seeing is because the S3 radio is not listening to BLE when I send the packets. I am wondering if there is a packet gap timing I can use to ensure that at least one of the three arrives in a window where the S3 is listening.

[irahul]

Hi @jonsmirl,

May i request you to please share the sniffer log ? Also, kindly confirm that there no filtering being done in the application side, when ADV reports are received ( e.g. dropping / ignoring adv report if certain field is not present in the received report )

[jonsmirl]

Check this comment out:
viewtopic.php?f=13&t=37638#p126149

The problem is not the S3 and its BLE stack. If I run the use standalone BLE on the S3 I get a perfectly acceptable 3% packet loss. The problem is when I turn on esp-matter, then the packet loss jumps to 20%+, with some long streaks of 100% loss. I believe it is an issue with WIFI coexistence.

This implies to me that during some periods my BLE transmissions are getting synchronized with when WIFI is active (both receive and transmit) and the S3 is using the radio for WIFI and not BLE. If they are synchronized, that will cause 100% BLE packet loss.

So what I am looking for is how to set the spacing between my three ADV packets which will minimize the probability of all three coinciding with WIFI using the radio. It looks like 100ms spacing is not a good spacing to use (aren't WIFI beacons at 100ms too?). I can start experimenting with spacing and try to guess a better spacing. Or maybe Espessif can look at the WIFI coexistence code and determine a spacing that is known to work.

[linrh321]

Hi, the period and time slice will change automatic according to the BLE and WIFI status, so we need to specify the working scenarios of the two protocols to know the coexistence period and time slice.

Assume that WIFI is connected, and BLE is scanning, then I recommend to send 3 adv packets with interval 35ms at once. If wifi status is not connected, please tell me the wifi status.

The period and time slice may change in the future, but anyway, please try the 35ms interval first and let me know the results. (Please make sure that the status of the wifi does not change during the test)