I plan to deploy some borons in rural locations where cellular coverage might be weak (at least for Boron’s carrier). When I make the enclosure for the device, I will be bringing out some LEDs to show status. Two desirable features for display are (1) an LED that is on when the device is NOT connected, and (2) some indication of cell reception which doesn’t depend on first connecting, then getting RSSI. For (1) maybe the idea is to invert a gpio? Is there a better idea? For (2) I have no idea.
Why (2) would be useful - help the rural user determine whether reception is the problem when (1) is indicated, so they might move/select a better location for the device.
The first problem is easy. By using SYSTEM_THREAD(ENABLED) your application code runs even when not connected and you can update a GPIO connected LED to show the connection status.
The second problem depends on the device. For 2G/3G devices, you can scan for towers when not connected. The problem is that this is a blocking, minutes long operation, so it’s better as a troubleshooting tool than every use tool, because while scanning you can’t be connecting to cellular, and that would needlessly delay the process. This feature is not available on LTE Cat M1 (u-blox SARA-R410M-02-B) devices, so there’s no choice but to connect first.
As suggested, this was added to the application. Then in setup, there is Cellular.on(), waitUntil(Cellular.connecting), turn on GPIO connected LED, and waitUntil(Cellular.ready) - after which the GPIO LED is turned off. Here is what I observe. The GPIO LED does come on, then there are normal flashes of green (between 8 and 15 seconds, I am not certain), then a single flash of white and the GPIO LED turns off, and this pattern repeats indefinitely.
It appears that the attempt to connect to the cellular network gives up and there is a System.reset() somehow. Previously when I encountered something like this, the only resolution was to unpower the Boron for some hours or maybe even overnight. After such a delay with everything off, when I powered on again it was able to connect.
Is this normal? If so, I wonder how to automate. In the main loop, if Particle.connected turns false, should the Boron just go into deep sleep for some hours?
That’s not the expected behavior. The device should never reboot under those circumstances. The cellular modem will power cycle, but that’s after 5 or 10 minutes (depending on the Device OS version). But there’s no white blink.
The blinking green to white blink is typically the device rebooting because of insufficient power. Which Boron is this? The Boron 2G/3G requires the LiPo battery in the default configuration.
Great suggestion thank you! I can try that right now, I have a battery all set up, just need to plug it in. - And the pattern does not occur with the battery, it steady blinking green, then connected.
What if instead of a battery I instead use USB power from a 3A adapter, would that be sufficient?
A 2A or greater tablet charger generally works. The caveat is that if you use an old tablet charger that does not use DPDM to negotiate a higher power limit, or are powering by the VUSB pin, the default input current limit is 900 mA and that’s a little low to successfully connect in all cases, especially 2G. It’s possible to override this setting in software.
The Boron LTE should operate down to 500 mA so it should work off almost any USB port, except for the random odd 100 mA port. But it does seem like it’s rebooting.
You could get a Boron Cloud Debug Log. Another clue is that the debug serial will disconnect when the device reboots.