LoPy stops detecting BLE advertisements

[alanm101]

@jcaron @jmarcelino Here's the code and the serial output. You will notice that, without warning or raised exception, the scanning becomes unsuccessful at around 3450 seconds (58 minutes). That's indicated by the repeated beacon ID and rssi, despite having moved that beacon out of range when the repetition started. As always, advice greatly appreciated. Options: a) repeat test on Lopy using standard espessif's standard firmware, b) repeat test with a standard ESP32.

from network import Bluetooth
import pycom
import time
import gc
import binascii
import machine

mybeaconids = ['d3e0f6cd4ca9','eea068fa3738','f51e1bced835','ea204c29bb1f','e9f1db4814ef']
enditall = False

pycom.heartbeat(False)
timeSleep = 0.01

bluetooth = Bluetooth()
starttime = time.time()

devid = ''
rssi = ''

def new_adv_event(event):
    global devid, rssi
    if event.events() == Bluetooth.NEW_ADV_EVENT:
        anydata = True
        while anydata:
            adv = bluetooth.get_adv()
            if adv != None:
                devid = binascii.hexlify(adv[0]).decode('utf-8')
                rssi = str(adv[3]*-1)
            else:
                anydata = False

bluetooth.callback(trigger = Bluetooth.NEW_ADV_EVENT, handler = new_adv_event)

print('Starting BLE scan')
bluetooth.init()
bluetooth.start_scan(-1)

p_in = machine.Pin("G17",machine.Pin.IN, pull=machine.Pin.PULL_UP)

loopcnt = 0
while True:
    loopcnt += 1
    if not bluetooth.isscanning():
        print('--------- Restarting BLE scan')
        bluetooth.deinit()
        bluetooth.init()
        bluetooth.start_scan(-1)

    # to keep the log manageable, print details only every 500 loops.
    if loopcnt%500 == 0:
        print(time.time() - starttime, devid, rssi)
    if p_in() == 0:
        print('pin')
        break
    time.sleep(0.05)

bluetooth.callback(None)
bluetooth.stop_scan()
bluetooth.deinit()

print('Run time in seconds ', time.time() - starttime)





------  Serial output. 


rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff9010,len:12
ho 0 tail 12 room 4
load:0x3fff9020,len:388
load:0x40078000,len:11584
load:0x4009fb00,len:848
entry 0x4009fc9c
Starting BLE scan
25 f51e1bced835 74
50 6c8009ac5ece 71
75 d5e2f8cf4eab 76
100 7e0504d53526 51
125 e9f1db4814ef 73
150 7e0504d53526 49
175 7e0504d53526 52
200 730088c7c467 49
225 6c8009ac5ece 78
250 6c8009ac5ece 72
275 d5e2f8cf4eab 75
300 d5e2f8cf4eab 75
325 d3e0f6cd4ca9 67
350 7e0504d53526 49
<snip>
...
</snip>
2850 6c28333b9548 52
2875 73bc08769bce 62
2900 d5e2f8cf4eab 66
2925 f7201dd0da37 76
2950 73bc08769bce 61
2975 6c28333b9548 50
3000 73bc08769bce 59
3025 d5e2f8cf4eab 63
3050 73bc08769bce 62
3075 ea204c29bb1f 69
3100 73bc08769bce 58
3125 73bc08769bce 58
3150 73bc08769bce 58
3175 6c28333b9548 51
3200 6c28333b9548 51
3225 73bc08769bce 62
3250 d3e0f6cd4ca9 63
3275 6c28333b9548 50
3300 73bc08769bce 58
3325 d5e2f8cf4eab 63
3350 6c28333b9548 51
3375 d5e2f8cf4eab 63
3400 6c28333b9548 50
3425 6c28333b9548 51
3450 73bc08769bce 62
3475 73bc08769bce 62
3500 73bc08769bce 62
3525 73bc08769bce 62
3550 73bc08769bce 62
3575 73bc08769bce 62
3600 73bc08769bce 62
3625 73bc08769bce 62
3650 73bc08769bce 62
3675 73bc08769bce 62
3700 73bc08769bce 62
3725 73bc08769bce 62
pin
Run time in seconds  3743

MicroPython v1.8.6-776-gd01a46cd on 2017-09-29; LoPy with ESP32
Type "help()" for more information.
>>> 

[jmarcelino]

@alanm101
Thank you, that information is very helpful.

Yes it would be interesting to compare with the C level ESP-IDF code on the ESP32.

I'll look into it in the coming days.

[jcaron]

@alanm101 What's the advertising interval of your beacons? If you change the advertising interval or the number of beacons, does the time scanning fails change?

[alanm101]

@jcaron Time to failure is random. Just ran another test in same controlled environment (home). Failed after 13 minutes.

Unfortunately I'm using Estimotes that cannot be transferred to me so frequency is a) fixed, b) unknown. The Estimote app refuses to divulge the info. Nordic's app can't list it either. If it will help, I can move them out of range and turn my phone into an iBeacon for a new test.

Update: Can't seem to set update frequency for virtual beacon. At least not with the software I have.

[jcaron]

@alanm101 AFAIK there’s no frequency selection in BLE, it uses frequency hopping on predefined frequencies.

[jcaron]

@jcaron ah sorry you meant the frequency of the advertisements. It’s usually not possible to find on the receiver side (as it does not necessarily listen all the time), but there are often ways to change it on the beacon (it’s a matter of compromise between time to discovery and power consumption)

[alanm101]

@jcaron Yes, I meant broadcast rate/frequency. Apologies. Sadly I can't configure these.

[jcaron]

@alanm101 this: https://community.estimote.com/hc/en-us/articles/204100806-What-are-the-default-settings-of-Estimote-Beacons-How-to-edit-settings- says you should be able to adjust them.

Alternatively you may want to try to see if varying the number of beacons has an influence on the time to failure. Just in case it’s a simple matter of the code failing after receiving a given number of advertisements (which would also explain the issue you had at the exhibition).

[alanm101]

@jcaron Sadly, you have to "own" the Estimotes to make changes. The ones I have were allocated to someone else who now has no access to the registered email.

I'm running a test with the native IDF on a DOIT ESP32 board. Hacked the gatt_client.c code. No problems so far (58 minutes).

[jcaron]

@alanm101 haven’t checked the whole thread to see if you already explored this option, but it might be interesting to log free memory and/or call the garbage collector periodically...

[alanm101]

@jcaron In a past experiment, I called the gc every few cycles. No difference. Free mem. Hmm. That's a good call. Btw, it's now 3 hours with native IDF on a DOIT ESP32 board. No problems.

@all (Edited for clarity) Question: is it safe to flash the native IDF onto a Lopy? That would potentially eliminate hardware and IDF. I suspect flashing the standard IDF won't brick the Lopy, but opinions welcome before I try that.

[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.