LoPy stops detecting BLE advertisements
-
@papasmurph It still runs in a stable fashion after a complete day.
-
@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 -
@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.
-
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.
-
@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.
-
@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 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.
-
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?
-
@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 But this is BLE. Is there any peak current to speak of?
-
@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.
-
@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.
-
@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.
-
@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 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 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.
-
@alanm101 did it stop finding any BLE advertisements at all, or specifically those you were looking for?
-
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.
-
@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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login