LoPy stops detecting BLE advertisements

[papasmurph]

@jmarcelino But this is BLE. Is there any peak current to speak of?

[jmarcelino]

@papasmurph
Yes, the BLE power requirements on the Pycom boards (and any ESP32 device) - as it stands - is not very different from WiFi (high)

It's been mentioned this is because the BLE RF duty cycling hasn't been implemented. Maybe coming from the next major release of the underlying ESP-IDF.

So for now there is a very high current (>100mA) just to have BLE on and then even higher peaks during transmission/reception. This is beyond the reach of most small batteries, causing instability.

[alanm101]

@jcaron I checked and it seems you are correct. The Lopy did warm up considerably during the test as mentioned in other threads. I will avoid. Apparently the Lopy can handle 3.3v on the VIN.

Of course, none of this explains why Bluetooth gives up looking for advertisements when the Lopy is not on the Pycom expansion board (in my experience). Just glad I found that workaround, but it really screws up the form factor of my device. Perhaps an electronics genius can figure out that we must ground one of the other pins, or whatever.

[alanm101]

@jmarcelino I'm trying to deploy with an 18650 LiPo on the VIN. I think that should be sufficient. Perhaps my wires from the 18650 to the pins are too thin/low quality to support the current demanded. I'll look into that, thanks.

[papasmurph]

@jmarcelino That's bad. I'm already not relying on the LoPy regarding LoRa for other than experiments. Products that have LoRa (and MCU and sensor(s)) integrated are in comparison extremely battery-efficient, promising a year or years of operation.

[alanm101]

@jmarcelino I bought a second Pycom expansion board so that both Lopys can be powered through MicroUSB, each with a separate 2.1A power supply. Stability has improved, but the board running WiFi, BLE, and Lora is still crashing after 30 minutes or so. This capacitor you mentioned jmarcelino, what size would you recommend? 100µF or as high as 1000µF? Thanks for the advice.

[alanm101]

@alanm101 I had a demo today. It did not go well. Last night in the hotel room, there were no issues with my solution running for several hours. Today, the Lopy stopped finding BLE advertisements every few minutes. Even a machine.reset() every 50 cycles made no difference, nor did some other solutions proposed elsewhere in this thread. This is soul-destroying. I understand that modules like Lopy are not intended for full-blown production solutions, but for makers who are trying to enter a market, some degree of reliability is important.

The demo environment was saturated with high-tech. The hotel room, not so much. Perhaps that had a negative influence that led to the instability.

Bottom line; the Lopy is, in my opinion, untrustworthy. I wish there was a possibility to return the two Lopy and two expansion boards. Sadly, in my neck of the woods (South Africa) that's not gonna happen. Since I'm stuck with the chips, I will follow other suggestions to hook up a serial monitor to look for esp-idf errors, once I've regained some dignity and enthusiasm after today's embarrassment.

[jcaron]

@alanm101 did it stop finding any BLE advertisements at all, or specifically those you were looking for?

[alanm101]

Apologies for yet another post. Please issue a cease and desist if this it too much.

Anyway, back at the hotel, and further tests (sans my serial monitor that's pining away at home). Perhaps the complexity of the demo environment was a factor. The code I'm running now at the hotel suggests that volume of BLE advertisements overwhelmed the chip. So one must figure out how to code around this. A callback that intelligently discards? I'm getting out of my depth on this and will happily accept derision from the community but would prefer constructive guidance.

[alanm101]

@jcaron All advs. I specifically put in debug code to determine this. As mentioned, the machine.reset() had no impact, yet a physical reset via the reset button got the BLE scanning showing results.

[alanm101]

No code change. No power supply change. At the hotel, no problems. The hypothesis that the chip can't handle technologically complex environments appears to have some merit.

Hopefully a community member will highlight a solution.

[jmarcelino]

@alanm101
I'm afraid it's impossible to highlight any correct solution based on so little information.

You're saying that the module - mounted on the expansion board, not a breadboard or something custom - stops scanning BLE beacons in "complex technological environments"?

Can you post what appears in the serial output (from the Expansion Board USB port) from the module when this happens? This is crucial to understanding - and potentially fixing - the problem.

[jcaron]

I wouldn't be too surprised if some specific advertisements could break the scanning code. However without an idea of what that advertisement could be, it might be difficult to find out.

If you have some other device that can capture all BLE advertisements, it could be useful to get that capture so that each advertisement could then be tested again the BLE code to see how it handles it.

[alanm101]

@jcaron @jmarcelino Thanks for the comments guys. I will be spending quality time on this and will give feedback sometime. No problems when it ran all night at the hotel. Only my 4 iBeacons in range though.

[alanm101]

@papasmurph Please help me understand how you posted the code? When I try pasting inline, it's a mess. I don't have permission to upload a file.

[papasmurph]

@alanm101 Three left apostrophs (```) on separate lines before and after the code.

[alanm101]

@papasmurph Thanks!

[alanm101]

@jmarcelino My goodness j, I'm embarrassed. Somehow I concluded that the expansion board has a separate debug serial output. So I hooked up on pins G1, G2 and GND as per other posts and found it's the exact same serial output as via the MicroUSB serial output. I'm seeing no extra output other than my own debug print statements. I will post the full source code and the serial output a little later.

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