Hello, I am running into what seems to be an unusual problem and would appreciate some direction from the community if this may need to be escalated to the devs.
The summary of the issue is that when you attempt to disconnect from the cloud/cell the device locks up for about 5 minutes, then resets. The code runs fine in the US, but when the same code is used in Malawi, Africa, this problem occurs, seems to be a network issue?
I am using the Boron 2G/3G as the core of a data logger system. I have a unit running here in the US, and I have units deployed to Malawi Africa. The code works perfectly on the US units, but on the Malawi based units, they seem to crash and reset after a small part of the code was executed. After quite a bit of remote debugging, I isolated the issue and it seems to be a problem cooperating with the cell network in Malawi (Airtel/Zain/Celtel ltd, 3G). You can see the relevant code below
void setup() {
const uint8_t val = 0x01; //Used to set key if not setup using the mobile app
dct_write_app_data(&val, DCT_SETUP_DONE_OFFSET, 1);
//Other setup
modem.power(PowerState::On);
modem.connect(true, Timeout::fromNow(DefaultModemTimeout));
Particle.publish("Reset", String(System.resetReason()), PUBLIC); //Publish "error"
delay(15000); //Wait a period for
Particle.disconnect(); //Disconnect cloud //FAIL
modem.connect(false, Timeout::fromNow(DefaultModemTimeout)); //Disconnect modem //FAIL
}
If these final two lines (commented FAIL) are commented out, the system works properly and proceeds on. If not, the system hangs for 5 minutes or longer, then simply resets and starts over. There have been occasional instances (I think about a dozen in the last week of trying to debug this) in which the code did proceed anyway, this happened in two clusters, not uniformly distributed. The modem.connect() function is something we wrote to clean up the process for us, can see below, but the important part is that it calls a Cellular.disconnect() and a Cellular.off() in order to “turn off” the system.
ErrorCode Modem::ParticleModem::connect(bool newState, Timeout timeout) {
if (newState) {
if (Cellular.ready()) { return ErrorCode::None; }
if (!Cellular.connecting()) {
Cellular.on();
Cellular.connect();
}
// Wait for Cellular.connecting() to turn on then off
// It's possible (but highly unlikely) for us to miss the connecting step entirely and go straight to ready, check that too
// Technically we could miss the same way on a FailedToConnect but that seems even less likely
Utility::waitConditionTimeout([]{ return Cellular.connecting() || Cellular.ready(); }, timeout);
Utility::waitConditionTimeout([]{ return !Cellular.connecting(); }, timeout);
if (Cellular.connecting()) {
return ErrorCode::TimedOut;
}
else if (Cellular.ready()) {
Particle.connect();
if (!waitTimeout(Particle.connected, timeout)) { return ErrorCode::TimedOut; }
return ErrorCode::None;
}
else {
return ErrorCode::FailedToConnect;
}
} else {
if (Cellular.ready()) { Cellular.disconnect(); }
Cellular.off();
if (Utility::waitConditionTimeout([]{ return !Cellular.ready() && !Cellular.connecting(); }, timeout)) {
return ErrorCode::None;
}
return ErrorCode::TimedOut;
}
}
It should also be noted that once this error was removed, it proceeded to the rest of the code, any time the system would attempt to disconnect from the network (either by the above method, or by going into STOP mode sleep) the same lock up and reset would occur. In order to get the code to run properly, all disconnects had to be removed, and had to ass .network(NETWORK_INTERFACE_CELLULAR) to the sleep settings to keep things connected.
Note: This issue only occurs on devices in Malawi so it seems it must be a network contingent issue.
It seems to me that Particle is not happy with how the disconnects are being handled on the network, maybe a different, more graceful, disconnect is required? Seems strange this would be carrier related, but that is the only explanation I can find in the variation between the performance of the US devices and the Malawi devices.
Any help or direction would be appreciated! Not disconnecting is a patch for now, but this is intended to be a low power data logger system, and so this is not an acceptable long term solution
Carrier Note:
Malawi Carrier Info
Operator: Airtel/Zain/Celtel ltd.
Access Technology: 3G
Cell Global Identity: 650-10-7007-352005
US Carrier Info
Operator: T-Mobile
Access Technology: 3G
Cell Global Identity: 310-260-29895-33583731