This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

wl18xx BLE passive scan / coexistence, debug and profile?

Hi,

Experiencing a Wi-Fi performance drop when the wl183x is running passive scan (one paired device).

The odd thing is when the BLE device is turned on => connection established with the wl18xx, the performance issue is gone...
Removing the paired device => the problem disappears.

So, the question is how to best debug and monitor the wifi-coex timing as the passive scan (I assume) runs autonomous from within the wl18xx firmware!?

bts in use: TIInit_11.8.32.bts from github.com/.../am335x

I wouldn't expect a few devices in the passive scan list to affect wifi like this. So need some expert advice from TI.

Thanks David

  • Hi David,

    Can you share the performance numbers before & during the BLE scan?
    I believe you are talking about the BLE reconnection scan which is spec recommended and initiated by the Host (not the firmware).

    The timings can be configured by the host. Typically the reconnection scan is for 30s, but I think you can stop it before that as well.
    Please check the bluetooth stack code...

    Regards,
    Gigi Joseph.
  • Hi Gigi,

    It's not an attempt to "reconnect" from the "host-side", what I mean is when we whitelist the LE device to later find it once it advertises itself using passive scanning on the WL18xx.


    * When you say BLE reconnection scan, can you please state the "HCI VS Command". 

    * How do I best get a verbose debug the co-ex state and what exactly is running on the BLE side in the WL18xx?
      (preferably without solder-in to the BT_UART_DBG if possible)

    Thanks David

  • Hi David,

    There are no specific VS commands for BLE scans. Its the standard spec command (LE_Set_Scan_Param & LE_Set_Scan_Enable)

    Some stack define a "reconnection scan" which is nothing but an aggressive scan (Eg: interval: 60ms & window: 30ms) whereas the background scan will have, say. interval: 800ms & window: 8ms.

    It depends on what parameters you have for scan interval/window

    To understand what is going on in the BLE side in WL18xx, you must need to pull out the BT_UART_DBG pins.

    Regards,
    Gigi Joseph.
  • Hi Gigi,

    I will collect some logs to know for sure the passive scan params in use. In general I believe the BlueZ hci_core.c defaults would be (like you said "aggressive"), le_scan_interval = 0x0060; le_scan_window = 0x0030; (N * 0.625 msec).

    Can you please guide me to where I can read about how the co-ex algorithm operates on the wl8, i.e. timing and priority details of wifi to ble handover, time/penalty (if any) when the radio has to scan on 2402, 2426, 2480 MHz, i.e. the wait + air-time lost for the Wifi.


    Related to above data, is there a good/practical way to profile (μs) the co-ordination scheme for bluetooth and wlan as well as any timing related changes like TSF's -> TBTTs, window widening for BT or similar that could affect performance.


    Thanks David
  • Hi David,

    The CoEx algorithm is implemented in the firmware, and it is proprietary information.
    However, there is an application note available at: processors.wiki.ti.com/.../WiLink8_-_TI_Coexistense_Tutorial_1.pdf . You can take a look at it.

    As for the CoEx parameter tuning, there are some available in the wl18xx/main.c (".sg.params").
    But I strongly recommend against modifying any of it as the ones that are already there are the optimized ones...

    Regards,
    Gigi Joseph.
  • Hi Gigi,

    Good to see the pdf-doc showing the fundamentals. I'm still very interested in getting real "practical" timing info for the co-ex algorithm for different scenarios as I wrote above, i.e. AP+STA, STA+BLE, BLE Scan and so on.

    We did a quick test here running We see about 20-40% packet loss, sending 2M UDP over iperf while passive scanning BLE @ interval: 60ms, window: 30ms. (note the Wifi has both a STA and AP interface up), see the graph below.

    We have a suite up & running so please let me know a good/practical way to run detailed profiling runs showing the co-ordination scheme for bluetooth and wlan as well as any timing related changes like TSF's -> TBTTs, window widening for BT or similar that could affect performance. We can hook up BT & WL DBG as well.

    best David

  • Hi David,

    As I previously told, this is proprietary information, so I can't give you more details than what I already shared.
    About the issue, I see that you have defined 3 roles:

    1. BLE that needs 33% of the time (probably more if the timing is strict)
    2. AP – not sure what the AP runs, but still needs time to support Beacon sending and answering Probe Req from other devices (so, even in Idle will need 25-30% of the time)
    3. STA – Running traffic – have less than 30% left of the time (+- 10% is contact switch)

    Even with this, 2M UDP should be available - unless you are running without retry (NO ACK for instance)?

    Can you share a sniffer log?

    Regards,
    Gigi Joseph.