LoPy stops detecting BLE advertisements

[Frida]

20000 then I made a keyboard interrupt, on the latest software.
I have Ruuvi tags running in the other end of my house and recieve from them.
20000 ~ 5.55... hours.

20000 10edb0e93366 74

[alanm101]

@frida That's good news. So what must we conclude? Does the Pycom version of the BLE code break when the beacons are from Estimote? Sadly I don't have other physical beacons, but I can make a couple of devices emulate beacons. I'll try that.

[duffo64]

@alanm101 said in LoPy stops detecting BLE advertisements:

So what must we conclude? Does the Pycom version of the BLE code break when the beacons are from Estimote?

Same thing for Estimote and EMbeacons on WiPy. See here.

[alanm101]

@duffo64 Thanks, that's good info. Maybe one needs to buy a few ESP32s and use them to broadcast BLE ads. I wonder whether that would be better. Anyone tried that yet?

[alanm101]

@jcaron I ran a test with gc every few cycles. Free RAM was around 50000. After 33 minutes scanning died. <Sigh>

[duffo64]

@alanm101 Tried a ton of times, but at this point I am pretty sure that this behaviour is not due to a free memory issue.
Just having high hopes about IDF 3.0 that is due in a few days. Oh, well....

[alanm101]

My next demo is on the 16th <shudder...>. Any ideas? Use Lopy for WiFi scanning and Lora broadcast, with a separate ESP32 for BLE scanning? Or abandon the Lopy and use an ESP32 with a Lora chip? Both options will stress my ability, so advice gratefully accepted,

[alanm101]

@duffo64 I empathise duff. But I don't think it's an IDF issue. Seems fine with native IDF 2.1 and raw C code.

[alanm101]

On reflection, I proposed a stupid solution. In a complex environment, you cannot dictate specific technologies. Estimotes abound, whether we like it or not.

[crumble]

@alanm101 you may be right. Increase the complexity in your test environment.

It seems that you are using unblocked communication. So yor timings are not the same when your device is connected to your PC or runs stand alone. Femove the print statements or write to an SD card to make the timings compareable.

You may receive corrupt data in your demo. Fix A beacon on yourself and your pet. Walk in and out of the BT range during the test. Send data over BT with your mobile.

And more important. Test your system wit the same settings as the demo. If you cannot increase the amount of beacons in your test, reduce the amount in the demo.

[alanm101]

@crumble Good thoughts. However, since some of the original posts, there are new indicators. In a controlled environment (home) where I have 4 beacons, the simple test fails when using Lopy and the Pycom firmware downloaded early this week. See the test code posted a few hours ago.

Using DIOT ESP32 dev board with official espressif firmware and a simplified version of the gatt_client example, no problems in the same environment.

Btw, the demo environment is usually at an exhibition centre where there are myriad devices and beacons.

[jmarcelino]

@alanm101
What is this gatt_client.c code? do you mean the gatt_client project at https://github.com/espressif/esp-idf/tree/master/examples/bluetooth/gatt_client ?

Did you change any esp_ble_scan_params_t there?

I’m glad you got good results with IDF directly, but I still feel it’s not optimal. My plan is to use the HCI layer directly to scan beacons and skip 90% of the stack.

[alanm101]

@jmarcelino Yes, that's the code.

Changes:
Line 313: Changed time from 30s to 20000s.
Lines 331 - 347 removed.

I'm getting interesting results with further tests. Will post later.

[alanm101]

This is depressing.

I put all my beacons in a faraday cage (aka microwave oven) and turned off all bluetooth devices. I checked with the Nordic app; no bluetooth signals. I then disabled bluetooth on my phone.

I fired up a single ESP32 to broadcast an advertisement once per second, using the ble_adv example from the IDF. The serial output of the ESP32 confirmed 1 per second. Fired up the simple code posted before on the Lopy. After around 100 minutes, it stopped picking up beacon signals. After a hard reset, it started working again, so it was not the ESP32 that stopped advertising.

One thing is strange. Even though the ESP32 is definitely advertising once per second (I can post the serial log and the code), the Lopy is picking up 2.3 - 2.5 advertisements per second. What? Is this expected behaviour? I fired up the Nordic app again and still just the ESP32 broadcasting.

I'm beginning to think this is a lost cause. Controlled environment, controlled broadcast, one beacon broadcasting once per second, but still the Lopy fails. Anything else I should try before giving up on the Lopy?

[jmarcelino]

@alanm101
Don’t give up yet :) This BLE scanning problems have been on my “to look into” list for far too long and I’ll look into it next week.

[alanm101]

@jmarcelino Thanks J. If there's anything else I can try meanwhile that might shed more light, please let me know.

[alanm101]

This post is deleted!

[alanm101]

@alanm101 My ignorance knows no bounds. The adv is broadcast on 3 channels, hence the multiple events per broadcast. My new tests are <cough> compensating for that.

[alanm101]

Test1: Single beacon using ESP32 at one second intervals.

Changes to ble_adv/main/app_bt.c
Lines 157-158:
uint16_t adv_intv_min = 256x3; // 160ms
uint16_t adv_intv_max = 256x3; // 160ms

<The 'x' is replaced with an asterisk. Some issue with uploading.>

Result: 2 hours with no problems.

Test2: Single beacon using ESP32 at one second intervals.

Changes to ble_adv/main/app_bt.c
Lines 157-158:
uint16_t adv_intv_min = 256x2; // 160ms
uint16_t adv_intv_max = 256x2; // 160ms

<The 'x' is replaced with an asterisk. Some issue with uploading.>

Result: 50 minutes, advs no longer detected.

[alanm101]

I'm no longer convinced that this is a Lopy/uPython issue. I hacked raw C code and ran on a generic ESP32 using newly acquired knowledge. The code failed. It could be my hacks were wrong or perhaps the ESP32 or the IDF is screwed. I'm now trying new uPython code on the Lopy.