LoPy stops detecting BLE advertisements

[papasmurph]

@stef You can reconfigure any beacon (including Kontakt's) to ping less often. 0.25 is usually unnecessarily short and drains the battery fast, unless they are USB-attached of course. Try 1 second. I recommend that you scan for 10 seconds and collect all detected beacons in a list, send the list (in some clever format) and then activate sleep. I don't understand why you miss any pings with that high frequency. The Pycom should detect all and queue them (up to 8) that should all be visible via get_adv if you just call it often enough (at least every 50 milliseconds or so), or better, use a callback with an internal loop for "strays", the way I do it now. I've noticed not all pings show up, but I have assumed that's a bug.

[RichardTXD]

@stef
Hi Stef. We use Kontakt beacons also. I have something like 90 to 100 beacons in the office with me, set on Level-2 power and 500mS interval.
I notice a speed difference in scanning depending on code. I can get close to 1,000 packets a minute or down below 600 depending on the code. One run I got 103,000 packets in about 2 hours. A different set of code with different garbage collection I got about 90,000 packets in 3.5 hours approx. Quite a difference.
I'm not that worried about lost packets; the possibility of collisions and broken packets is very high - and then there are my 2 or 3 WiFi devices in the office also pushing out RF. Broken and lost packets are a given imho. There is no way they won't collide.
With 3 beacons and 250mS gap there would be less collisions but I would not rule it out. Maybe set a longer interval in the beacons and increase the scanning window.
Latest test-tweak of the code has run for 1hr 20m approx. Nothing special. I would have thought 24 to 48 hours 'good' but not great if it falls over then. The problem is that it falls over and seems to die.No error message. No recovery.

[RichardTXD]

@papasmurph
I mostly agree - and strongly agree on battery.
To a small degree I'd be surprised with 3 beacons if you collected all advertizing packets every time for a period or more than a few seconds.
Problem/advantage is that shorter intervals give better geolocation. iDevices seem to do an averaging and lots of packets make it more stable iirc. They work via RSSI and it is a real struggle. Android seems to report everything (could be wrong on that).
We use 500mS as we need better battery life - and accept the lesser accuracy.
The marketing material I see that claims 1 metre and better accuracy makes me smile. In the office standing still it is very variable with 500mS.
Problem with 1 second and low power, Level-0, is that it is very possible to move past it and not get a reading in an iDevice as it doesn't get enough hits. Battery life is great tho.
I suppose it depends on the application & tradeoffs.
Packet collisions... that is my theory as to what is happening. I may be wrong - happy to be adviced by those more knowledgable but it would seem logical.
Multipath is also an issue we see in the field. Reflections of the same packet arriving time shifted as a result of a reflecting surface. Seen this in the field with just one beacon and small dead spots in a zone where it is working all around. Same effect as 'ghosting' all those years ago on television but leads to broken packets.
Agree, a longer sample time would be good.

[papasmurph]

@RichardTXD I have an iOS/Android app (CliqTags Spotter) for detecting beacons and geofences, and it has a hidden page/pane that shows all beacon activity in a stable list (once a beacon is found it's stays in its place, unless it goes away for a longer time, so it's easy to see what happens with any specific beacon), and it shows many more pings than my Python app, so there's a difference. I also tried with BLE Scanner and got similar results. In a setting with only one or two beacons near by the app detects almost all pings. I was not aware of the use case. I use beacons mostly as pure proximity markers, not for absolute location, even though that's no doubt an interesting field that I'd like to get into, and I understand the relevance of a higher frequency for that use. Regarding accuracy: Try holding a beacon between you and the detecting device. Water and metal are beacon killers. But the main issue here is of course that it stops.

[stef]

@papasmurph
I start a simple test on Lopy and an generic board : Scan for 60 secondes a Kontact Beacon ( only one - 350ms message freq ) , the beacon is put on the Lopy .
Then i just count how many time this beacon appear for 60s

TOTAL CAST : 60000/350 =170
TOTAL for python test on Lopy ( 4x - reset after each ) :100-103-130-128
TOTAL for C test (4x) on ESP32_core_Board_V2 ( esp32-idf ) :99-110-120-115

so , in the two cases , we have min. 30% packet lost.

Someone can test with other beacons or hardware ?

Stéphane A.

[papasmurph]

@stef I moved away all other wireless devices 5 or so meters away and kept only one beacon. I got 31 pings in 180 seconds, with ping interval of 1 second, so 83% loss. WiFi was active on the LoPy. BLE Scanner has a loss of < 5-10% at the same distance.

[RichardTXD]

@stef
@papasmurph
@daniel
'Stef' I'm thinking your testing shows that the Pycom software sits on top of the ESP32 firmware, same as the ESP32_core_Board_V2 as both have very similar performance.
From reading various posts it is apparent that Expressif are still working on their firmware.
I would feel disappointed at the results also. It seems somewhat poor imho - I would have expected better in an RF clean environment. Getting close to 100% is probably a big ask.
Maybe try shutting down the WiFi and in particular the server - that may have an impact (if it is sending out SSIDs I would have thought so). Interested to hear how you go on that.
For myself, we are just wanting to receive the packets. We are not ranging, just want to know we are nearby so losing a few isn't an issue.

What is a killer for us is the way it fails. Silently. We can't survive bugs like that. It is a show stopper and I've been looking at options with other products last night and today. I don't mind if it fails occasionally, so long as I can know quickly and take corrective action.

For now I'm (dis)satisfied that the BLE is both very insensitive "deaf" and also buggy. I've probably spent 2 days and not been able to make it not crash after a few hours at most.
I'll monitor when updates come out and give them a try. Even the most simple code to read all BLE advertisements over time fails. It is simple to test but it does take time. About 3.6 hours is my record so far.

I haven't tried turning off the server either - might do that now and report if there is any major change.

I'll be focussing on testing the 24/7 capability of the product (WiPy) in other areas, clock, timers, I2C and WiFi. If it won't do that then there is probably little point proceeding.

[stef]

@RichardTXD

Yes , my use of LoPy is only based on detection , not data transfer ( as we are doing location ) . If it's help , i can test a long time BT loop directly with ESP32 Framork ( if that's working it's a python problem , if not we just have to wait for IDF update ).

[RichardTXD]

@stef
I'm trying scanning for just 10 seconds, then de-init the bluetooth, re-init it and scan for another 10 seconds. I get all the packets from the queue every 0.1 second. It's been running for just over 3 hours now. Read 168,000 packets and over 1100 resets. This simple snippet of code

    if bluetooth.isscanning() != True:
        bluetoothResets += 1
        print('   Turning on bluetooth. Resets = ' + str(bluetoothResets))
        bluetooth.deinit()
        bluetooth.init()
        bluetooth.start_scan(10)
        LogRecord(LOG_startScanning)

I would be interested to hear how your packet counting goes with the WiFi disabled & the server turned off.

[RichardTXD]

@stef
It has been running for about 18.5hours now and received 960,000 packets.
That dumb bit of code seems to keep it alive - at the expense of turning off bluetooth and turning it on periodically - at least with very simple code. I'll update the code till it breaks again...

[papasmurph]

@RichardTXD Great. I'll try that approach. Thanks. Update: So far stable, after 10 or so hours. I'll keep it going.

This is the code I use now. I ignore iBeacon UUID at the moment, as all of them use my UUID.

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

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