LoPy stops detecting BLE advertisements
-
@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.
-
@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.
-
@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.
-
@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.
-
@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.
-
@jmarcelino But this is BLE. Is there any peak current to speak of?
-
@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)
-
@alanm101 the 3.3v pin of the LoPy is an output, not an input. You should power it via the 5.5v pin only.
-
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?
-
@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.
-
@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.
-
@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.
-
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.
-
@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.
-
@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 It still runs in a stable fashion after a complete day.
-
@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 :
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.
-
@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.
-
@papasmurph Hi, very thanks, I made new tests, I think the problem is in the beacons of Radius Networks, I tell you any progress.
