I have a couple of Boron LTE OS 0.9 that have been running a simple loop program (1 ms delay) with a particle.variable and particle.function.
For several weeks/months. Randomly, I’ve been able to go to Console and send or receive data.
However, on one instances, even though the devices were breathing cyan and there was no status warnings for particle services, the console could not connect to devices.
On power reset, they both reconnected to particle cloud and they again were connected to console.
I am interested in using Boron for mass deployment, but this has caused me to have some hesitation.
My question…
Any ideas about why the devices were breathing cyan but had to be re-powered in order to connect back to particle cloud.
Or, any thoughts about automatic device reset if “real” connectivity is lost? Even though breathing cyan?
There are some known issues with the communication with the NCPs (network co-processors) that may contribute to the loss of connectivity and reporting a valid connection while there isn’t.
The next release should help most of these issues.
Hello, Im having similar issues. My boron is breathing cyan but I can connect to it. I cant send it code, I cant send it a signal. It still will not work when restart. Should I turn to DFU mode and re flash system bin?
You can always revert to DFU to flash new firmware, but when OTA consistently fails it’s probably the running code that torpedoes the attempt. Try Safe Mode and see if OTA works then.
Hello, My Boron is acting similar. I have it set up to send text messages when certain conditions are met and it will send the messages out even though I can’t reach it through the app or through the IDE. After cycling power, everything works as it should until it enters this state. I had an issue at work with an automation device on a cellular modem. It ended up being an issue with how the AT commands were setting the cfun state of the modem. We were not able to change the cfun settings, so we had to publish data at intervals to keep the connection active. I have been experimenting with the keepAlive timing, but this seems to be more of a work around than a fix. I was wondering if anyone has tried to control the modem functions to resolve this issue?
So, do I understand correctly that the NCPs are a firmware implemented NCP?
Is there a work around to get real status of Cloud connection and then do a simulated cold boot or real power cycle?
Or reset particle network connection to fresh condition?
Nope, the Boron uses the ublox module as co-processor while the Argon uses an ESP32 and the main nRF52840 controller talks to these coprocessors to make them do what it needs.
For the ESP32 Particle has provided their own firmware for that NCP to offload as much work as possible, but AFAICT the ublox firmware is still the stock version (although possible updates should be possible to upload).
However, either communication between the main controller and the NCP or the firmware on the NCP itself may have some issues (as does any software) and hence contribute to unexpected behaviour.
Having said that, version 1.1.0 should have tackled some of the known issues already.
You can go through the AT command set for the ublox module and try any of them via Cellular.command().
Sorry, I didn’t clarify… On my Boron, I am using Twilio for the messaging. In this state it will not accept incoming messages, but it is able to send outgoing messages. I confirmed this by triggering a high temperature alarm and receiving the Twilio message. This confirmed that the program was still running and the Boron was able to establish an outbound connection to the cloud. I am not quite sure if the cell connection is timing out (been increasing keep.Alive frequency) or the modem is going into a sleep state and not properly waking on incoming messages. I am new to the Boron, so I am trying to understand the modem functions.