WL1831MOD: Follow up on Slow BLE response times after second device is connected

Hi,

The print of "MWS victim %i, MWS aggressor %i" reflects the AFH state machine's inputs from the MWS mechanism. Basically, the WL18xx devices have provisions to handle coexistence through the MWS as described in the BT core spec. It's unlikely that you are using that though, which is implied by the prints - it's always reported that all 79 BT channels are available to use. In effect, no channels are reserved by the MWS mechanism. As such, I don't think that print is of relevance to your issue.

Regards,

Michael

Hi Michael,

The screenshot shows that all 37 BLE channels are available for the channel map. However, in other locations of the .lgr log file, we see that the number of available channels dips as low as 28. I would love to attach the .lgr file to this message so that you could look at it. But this bug reporting tool does not seem to let me insert or attach a .lgr file, even though that is a proprietary TI format.

How can I submit the full .lgr file to you?

Hi,

Please try renaming your .lgr into a .lgr.txt file or simply a .txt file. Changing the file extension should allow you to evade the filetype filter. At least that's how I can upload arbitrary files to my posts on E2E - your posting permissions might be different.

Regards,

Michael

I tried renaming LQ3.0.2_bad_run_1.lgr to LQ3.0.2_bad_run_1.lgr.txt and inserting it here.

The major changes made to the TI website over the weekend have made things much worse. Previously, I could browse upload and insert renamed files, but the new changes seem to prevent that. 

Could you provide me with a link to upload files to? When we ran into this problem with the associated bug(e2e.ti.com/.../3534489 ), we were provided with a way to upload binary files, including the .lgr files. Unfortunately, we never got any response about their contents. It was not even clear if anyone at TI had opened the .lgr files with the TI Bluetooth Logger.

Hi Elliot,

The latest E2E site update is something that I'm adjusting to as well.

I have sent you a friendship request to your account, and in the request you should see a link to a file share that you can upload to. It's public write, so you can upload your .lgr there. I could post the link in this thread, but given that it's publicly writable we'd run the risk of someone else editing that folder.

Let me know if you can access the shared folder and upload your file.

Regards,
Michael

Hi Michael,

I uploaded LQ3.0.2_bad_run_1.lgr to your location. Can you see it?

--Elliot

Hi Elliot,

I've download your .lgr file and have it opened in my logger tool now. Please give me a day or two to review and analyze your logs.

Regards,

Michael

Did the lgr file suggest anything to you?

Hi,

Looking at the .lgr file, there doesn't appear to be anything obviously wrong. The channel map does get a low number of channels occasionally, but never below the 20 channels that is the minimum for AFH according to the BT spec.

Was the log data captured in real time, with the timestamps being valid? There is a section of the log towards the middle, starting around entry 29600 where it appears that the AFH channel classification process happens repeatedly, more than expected perhaps. To confirm my understanding of the issue, does this correspond to the period of time where the BLE response time issue occurs?

It seems like the channel classification is trigged by the lm_lc_gemini_coex interrupt. I will need to check and see what causes that interrupt.

Regards,
Michael

The .lgr file data was captured in real time, so the timestamps should be valid. It is rather difficult to correlate the timestamps from the .lgr file with our application log timestamps. In principle, if we rerun the tests, we should be able correlate the timestamps. It will take awhile to get that set up, so I am not planning to do it right away.

Note that we have mostly managed to avoid the problem by changing the Bluetooth connection interval from 7.5ms to 10ms when talking to the sensors with the WL18xx controller.

We do not see this problem when using Bluetooth controllers running on Mac, Windows, Chrome, Android, etc, so we think that the problem is with wl18xx controller and not the sensors. The 7.5ms connection interval works fine with these other hardware configs.

The clearest data that we have seen that seems to implicate the WL18xx was obtained using WireShark. Does this suggest anything to you?

The screenshot of WireShark is in the original bug at https://e2e.ti.com/support/wireless-connectivity/wifi/f/wi-fi-forum/955480/wl1831mod-slow-ble-response-times-after-second-device-is-connected .

I cannot insert files here, but I uploaded wireshark1.png and Eureka_fail.pcapng to tidrive.ext.ti.com .

Thanks,

Elliot

Hi Elliot,

Thanks for uploading those files to the ext drive, I have them on my PC now.

In general, the issue is probably not something easily isolated and can be attributed to how if you have multiple LE links to different devices with a very low connection interval you could trigger some bottleneck or similar condition that delays all of your link. The main fix is to increase the connection interval, which you've done, so that the controller isn't as stressed.

I'm still looking into what might be causing the delay in your specific case, but it does look to be more of a symptom of a more general phenomenon with the WL18xx and is less specific to your use case.

Regards,

Michael