LoPy stops detecting BLE advertisements
-
@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.
-
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.
-
@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.
-
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.
-
@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.
-
@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.
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