Hi,
Since September 15, 2026, 6 of our 60 Boron LTE-M devices (EtherSIM) in Quebec, Canada have had major connectivity problems. Before that date they had been stable for months. Devices on carriers other than Bell were not affected; all of the affected devices are on Bell (302610).
The 6 affected devices run two different products / firmwares ( on product A, [Y] on product B), and the problem started on the same day for both, so we don't think either application firmware is the cause.
Setup
- Boron LTE-M, EtherSIM (internal SIM)
- Modem: u-blox SARA-R510, firmware
03.15,A00.01 - Device OS: [Device OS version]
- Network: Bell
302610, LTE Cat-M1 (roaming),UMNOPROF: 90 - Power is fine:
source=VIN battery=CHARGED soc=93.5% vcell=4.02Vthroughout - Signal when connected: RSSI -88 to -93 dBm
Symptoms
- Once offline, the device never reconnects on its own. These do not recover it:
- the Device OS modem resets (every ~10 min);
- our application watchdog: a full modem power cycle after 15 min offline, then a modem power-off and MCU reset after 1 h;
- a USB reset.
- The only way we have found to bring a device back is to boot it into safe mode and then back into the application firmware. It then connects, usually after a few minutes.
- The session then lasts about 45 to 60 minutes, the network drops it, and the device stays offline again until the next safe mode round trip.
What a 4-hour AT trace shows (Sept 30, 11:08 to 15:12 local time)
The SIM rotates between three IMSIs after each Device OS RF reset. Bell only accepts one of them:
| IMSI (masked) | Home network | +CEREG results |
|---|---|---|
732123xxxxxxxxx |
Colombia 732-123 | 5 (registered, roaming): the only profile that ever connected |
234106xxxxxxxxx |
UK 234-10 | 213 x 3 (denied), 84 x 0, 4 x 4 |
234502xxxxxxxxx |
UK 234-50 | 73 x 3 (denied), 68 x 0 |
Each IMSI change follows a Device OS RF reset:
11:13:31.825 [ncp.client] TRACE: Sticky EPS denied state for 261 s, RF reset
11:13:31.827 [ncp.at] TRACE: > AT+CFUN=0
11:13:31.850 [ncp.at] TRACE: > AT+CFUN=1
11:13:32.139 [ncp.at] TRACE: < 732123xxxxxxxxx (AT+CIMI, was 234502... before)
11:16:12.242 [ncp.at] TRACE: < +CEREG: 5,"dac4","0879290d",7
11:16:18.983 [system] INFO: Cloud connected
The session then ends with a network-initiated termination and deregistration (about 57 min later):
12:13:38.337 [lwip.ppp] TRACE: rcvd [LCP TermReq id=0x2]
12:13:38.340 [system.nm] INFO: State changed: IP_CONFIGURED -> IFACE_LINK_UP
12:13:38.364 [ncp.at] TRACE: < +CEREG: 0
...
12:14:38.459 [ncp.at] TRACE: < 234106xxxxxxxxx (AT+CIMI)
12:16:09.057 [ncp.at] TRACE: < +CEREG: 2,3 (denied, repeated for minutes)
The same sequence happened a second time (switch to 732-123 at 12:29:24, connected at 12:32:02).
After 13:19 the SIM never returned to the 732-123 profile. It only alternated between 234-10 and 234-50, both denied, until the end of the trace two hours later. Device OS kept resetting the modem as expected:
[ncp.client] WARN: Resetting the modem due to the network registration timeout
This message appears about every 10 minutes (13:45, 13:56, 14:06, 14:17, 14:28, 14:43, 14:54, 15:04).
Questions
- Did anything change around Sept 15, 2026 in EtherSIM roaming on Bell (302610) in Canada, for example the UK IMSI profiles (234-10 / 234-50) losing access to Bell LTE-M?
- Why does the SIM keep rotating between the denied 234-xx profiles and not go back to the 732-123 profile that works? Can the IMSI selection or priority be adjusted for our devices or our region?
- Why does a safe mode round trip bring the device back when modem resets, modem power cycles and MCU resets do not? Does booting into safe mode reset the SIM / IMSI selection state, or something else in the modem or network state?
- Is the network-initiated
LCP TermReq++CEREG: 0after about 1 hour expected for the 732-123 profile on Bell? - Is there anything we should change on the device side (Device OS version, modem settings, timeouts) while this is being investigated?
I can share the full trace, device IDs and ICCIDs privately with Particle staff.
Thanks!