Once in a while (one every few weeks) my Boron temporarily is unresponsive to function calls or variable calls for a few minutes. During these episodes it continues to breath cyan but no data is returned. After one of these episodes I pulled a vital check and below is what I see. Is there a way to get more information on the “disconnect_reason”:“error” or “disconnect_reason”:“unknown”. ?
Most likely, it’s not possible to get a better reason. Here’s the long, technical, reason why:
Particle cellular devices use CoAP over DTLS (datagram TLS) over UDP over cellular PDP (data connection).
The mobile carrier data networks are a private network (10.x.x.x) with port-forwarding to the public Internet, not unlike a home router. However since port forwarding uses a finite number of public IPv4 addresses, the carriers like to free unused ones as often as possible.
The amount of time is the keep-alive, and Particle SIMs have an unusually long one of 23 minutes. Some 3rd-party SIM are as low as 30 seconds. Basically, you need to transmit this data often to avoid having the port forwarding deleted. In order to conserve data, data is only transmitted when requested from the device (publish), from the cloud (function, variable), or to keep the connection alive (keep-alive).
If your port forwarding is deleted, the Particle device won’t know about it immediately. There’s no notification to the device from the mobile carrier that the port forwarding no longer exists.
During the period from the port forwarding being deleted to the next transmission, the device has no idea that it can’t be communicated to from the cloud-side and will still be breathing cyan.
This can happen not only because the keep-alive expired, but really any reason the mobile operator decides to free the port forwarding. Unfortunately, there’s no easy solution to this. You can minimize the period of not knowing by shortening the keep-alive, but this will increase data usage. You can transmit acknowledged data more frequently, but that will increase data operations.
Thanks @rickkas7 that makes sense.
While I have you on a slightly unrelated note ( I can create a new forum thread if needed), in my code I do periodically run:
CellularSignal sig = Cellular.RSSI();
What would you recommend the minimum wait time should be before running this function again.
The Cellular.RSSI call requires access to the modem but does not use data. It is only going to return the data from the last time the cell tower communicated with the device, so I probably would not call it more than every 30 seconds, but that’s more of a hunch than a set-in-stone rule. You can call it less often.
However, the bigger problem is that because it accesses the modem, it may block for a period of time up to 10 minutes, if the modem is busy doing something else.
If you require high performance of loop, we recommend putting Particle.publish and Cellular.RSSI in a separate thread so if the modem is busy, the loop will not be blocked.
Thanks for clarification!