LoPy stops detecting BLE advertisements

juansezoh

@papasmurph @RichardTXD Do you have any progress you can share from reading beacons? Can you explain why the advertisment feature only gives me one beacon at a time ?. I hope you can help me, thank you very much.

papasmurph

@juansezoh That's simply how it works, but if you call the function fast enough you'll get all "pings" anyway. None will be returned if there are no pings available.

To avoid detection to stop altogether after a while I do this:

while True:
    if not bluetooth.isscanning():
        print("Restarting scan")
        bluetooth.deinit()
        bluetooth.init()
        bluetooth.start_scan(10)

    time.sleep(1)

Here's a complete example that works in a stable way. I ignore UUID in this case. I use rssi - power as a coarse way of determining distance.

from network import Bluetooth
import pycom
import time
import gc

pycom.heartbeat(False)
timeSleep = 0.01

bluetooth = Bluetooth()

def new_adv_event(event):
    if event.events() == Bluetooth.NEW_ADV_EVENT:
        anydata = True
        while anydata:
            device = bluetooth.get_adv()
            if device != None:
                rssi = device.rssi
                data = [b for b in device.data]
                if data[5] == 0x4c and data[6] == 0x00 and data[7] == 0x02 and data[8] == 0x15:
                    majorid = data[25] * 256 + data[26]
                    minorid = data[27] * 256 + data[28]
                    power = data[29]
                    if power > 127:
                        power -= 256

                    pycom.rgbled(0x000800)
                    print("iBeacon: " + str(rssi) + '/' + str(power) + ' (' + str(rssi - power) + ') ' + str(majorid) + '/' + str(minorid))            
                else:
                    pycom.rgbled(0x000008)

                time.sleep(timeSleep)
                pycom.rgbled(0x000000)
            else:
                anydata = False
            
bluetooth.callback(trigger = Bluetooth.NEW_ADV_EVENT, handler = new_adv_event)

while True:
    if not bluetooth.isscanning():
        print("Restarting scan")
        bluetooth.deinit()
        bluetooth.init()
        bluetooth.start_scan(10)

    time.sleep(1)

juansezoh

@papasmurph Hi, very thanks, I made new tests, I think the problem is in the beacons of Radius Networks, I tell you any progress.

papasmurph

@juansezoh My experience is that Radius beacons work fine, but maybe the ping frequency and power are set too low. Preferably set 1 Hz / 1 second and 0 dBm. Also, see if they are set to ping iBeacon, Eddystone or both via the configuration app.

pwest

@papasmurph :
Have you found your method to be reliable? I refactored my code to follow your pattern (which I prefer over what I had (Thanks!)), but my system still eventually fails to see beacons. I put a simple print statement directly above your time.sleep(1) line, and it indicates that bluetooth.isscanning() = True. But, of course, no advertisements are being processed. After my most recent failure, I had to unplug the board before it would again see BLE advertisements: the reset button didn't do the trick.

papasmurph

@pwest I haven't seen it fail. I have 10+ beacons, both iBeacon and Eddystone, and both types are detected properly. It seems to miss some pings, but enough are detected for it to be called reliable over time. It's a while since I worked on that use case, so I'll let a LoPy run continuously for a few days to see if it ever fails.

Note though: The workaround is no doubt to circumvent a bug somewhere in the system software (I doubt it's in hardware). Pycom, or the ESP team, needs to fix that anyhow.

I now use the very latest firmware (1.7.9b1 I think). It still doesn't work (continuously) if I use start_scan(-1), so the bug is still there.

LoPy detecting beacons

papasmurph

@papasmurph It still runs in a stable fashion after a complete day.

pwest

@papasmurph
Maybe that's my problem: I was still starting the scan with the -1 value thinking that the routine at the end would reset it when/if it stopped scanning. I now understand that your idea is to limit its scan interval to a short time and then restart it. I just changed the scan time to 60. I'll kick it off now and see how it does over night. Not that I think it should matter, but I've currently got a couple of Kontakt.IO beacons and a couple of TrackR beacons in the room

papasmurph

@pwest -1 will make it scan forever, which in this case triggers a bug somewhere in the system, so it stops. I recommend 10 seconds for now, as it's proven to work.

Smeedy

Slightly off-topic here. I'm running a project along the same lines to catch BLE environmental sensors broadcasting adv data, creating a byte array with the relevant parts, and pushing them up to the LoRa network.

You should scan for n*11 (n>=1) seconds to be sure you catch-'em-all as every sensors is required to emmit at least every 10.24s (see a Nordic blog for some nice details). You could miss a beat, so using n=2 will increases your change of catching all transmissions.

In real live I'm not missing that much sensor adv data and as it is only environmental (temp, humidity) it is not important to have them all. Scanning drains your battery so we scan for 11 seconds and then we go into sleep.

papasmurph

@Smeedy Many use cases don't have to range all the time. E.g., I've been discussing a case where equipment would have beacons, and by ranging once an hour or so at strategic indoor locations the company would know where the equipment is during the day.

Smeedy

@papasmurph Indeed it depends on the use-case. I was not making myself clear.

There's the minimum scan-time of 10.24s for a single BLE sweep if you want to make sure you want to catch every adv packet from every possible BLE device. This is covered in Section 7.8.5 Part E Vol2 of the BLE specs
There's a period to perform this sweep and this is dependant on the use-case. I scan for 11 seconds and go to sleep for 10 minutes. This varies from use-case to use-case.

If you know your BLE sensors on the site, you can even tweak the sweep time. We've set the adv interval as slow as possible to converse energy on the sensor part.

papasmurph

@Smeedy This is not entirely true for beacons though. You could set up a beacon to post iBeacon or Eddystone compliant advertisements much less often than that (minutes apart or more). I use to set the interval to 1 second, so that they are detected in time, but the equipment scenario I mentioned could ping much less often, and that way save on battery, unless externally powered. The problem with advertising that seldomly is that the "detector" needs to scan continuously to not miss any advertisements. So it's very much a case by case consideration.

alanm101

@papasmurph @RichardTXD

Guys, I seem to have found a pattern.

When the Lopy is plugged onto the Pycom expansion board with source via MicroUSB, Bluetooth scanning is far more stable. If I power it via VIN or 3.3v on a breadboard or directly from battery to pins, Bluetooth scanning stops after a while, even with all the tricks mentioned above. Not even a H/W reset helps; I have to disconnect/reconnect the power source.

Could it be that the Pycom expansion board is supplying some current to a pin that somehow alleviates the problem? Perhaps someone else can verify for feedback to Pycom?

jcaron

@alanm101 the 3.3v pin of the LoPy is an output, not an input. You should power it via the 5.5v pin only.

jmarcelino

@alanm101
Not all batteries can deliver the peak current the LoPy needs during WiFi/Bluetooth operation. Try adding a capacitor.
(and definitely follow @jcaron's advice, only power via the VIN pin)

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.

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

LoPy stops detecting BLE advertisements

Pycom on Twitter