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”. ?
1 Like
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.
3 Likes
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.
1 Like
Thanks for clarification!
@rickkas7 one more question on this. Do you think the keep-alive value that the carries have set for port-forwarding can differ from tower to tower or geographical area? Any chance the 23 min value particle used can be too short for certain areas?
It's dependent on the APN, not the tower, so the keep alive is generally sufficient everywhere. However, you could try setting it lower as a test, but it will of course increase your cellular data usage.
Got it. Also in Console the "Last Heard" value represents the last keep-alive timestamp, correct?
@rickkas7 I did some testing based on what you said about the keep-alive/port forwarding and I was able to reproduce it a few times. I'm only able to call particle variables up to a minute after the the "Last Heard" timestamp updates. After that they fail. Reviewing the Device Diagnostic file shows it has been switching between AT&T and T-Mobile's network over the last month. The testing I did was while connected to AT&T.
Any chance Roaming is involved? Is there anything else that can be done? Would deactivating and reacting the device help with reseting the SIM settings or lock-in a carrier?
Update: Did additional testing and I can reproduce it consistently. Happy to share the device ID if needed.
1 Like