Q2686 loses registration


#1

Hi,

I’ve been having problems for a while now with a Q2686 (and whatever is in the new Fastrak Xtend) losing network registration. Its hard to pin down as it happens very rarely, maybe every few months. A reboot recovers the situation, but I’d rather not go there.

Whatever it is that’s happening, my OpenAT app is fine and all appears normal. But the modem is no longer registered (no flashing light and AT+CREG=0,0). Before I reboot it, does anyone have any ideas what might be going on, or what I might be able to do in my app to catch this ‘event’ and recover automatically.

Ideally i’d like to prevent it from happening at all. Failing that, presumably I could periodically check CREG in my app and invoke some kind of automatic recovery.

The modem doesn’t seem inclined to re-acquire the network on its own.

On the most recent occasion, the device in question had been dormant for several months (no calls or texts). On other occasions the devices in question have been very busy. Is it possible that the network could give up on a subscriber that makes either too few or too many calls/texts.

Any help much appreciated.


#2

Is the device in an area of poor signal?

In particular, is it in an area with poor signal on the SIM’s “home” network, and (much) better signal on other networks - but with no roaming rights to those networks?

In that situation, the device is prone to lose the “home” network (due to poor signal) and camp on to an “other” network in “Emergency Calls Only” mode - and get “stuck” there.
AFAIK, the only escape from this situation is a reboot.


#3

It could be anything. You should check your module, your SIM card, your operator, signal level, antenna, power source and all possible combinations of theese. A good way to behave if your module does +CREG: 0,0 is to wait a bit (your module could reregister by itself) and then reboot.


#4

Thanks for intriguing responses, lots to think about. Signal strength is a good 20+ (according to csq), but the period in question can be very long (months) so presumably its possible that the local cell might have dropped out briefy during that time (eg maintenance) and that my modem has camped onto another network. Never come across that before, or rather I never noticed it before.

Rebooting works everytime, but I’m still looking for a better understanding and a better way of dealing with it. I’ll let you know how I get on.


#5

Tried everything but only reboot worked, just like you said, annoying because now I have to wait for another several months for it to happen again.

I did get a bit of info though. While the modem was locked in its unregistered state none of the SIM commands seemed to work (all returned +CMEE Error 13, ie SIM failure). I tried substituting a known working SIM and got same thing, just errors. Meanwhile the SIM I had just taken out was working just fine in my phone. I’ve now put the original SIM back, rebooted the module and all is well. SIM commands also work as expected. Until next time.


#6

OK, apparently…

When a cell is updated/maintained in any way (eg software upgrade) it is rebooted and forgets all of its previous connections (empty routing table). The connections are not restored automatically, but are picked up gradually as mobile devices move into the cell.

This is OK for mobile devices being passed around a network, but when a device is static, such as an M2M modem, it stays registered to a particular cell tower. So during cell maintenance the M2M modem is dropped from the network and thereafter remains off indefinitely. The only way to recover is to reboot the device. Sounds sort of plausible although I am yet to understand why this is not a problem with mobile devices.

This might happen several times a week or every few months. It depends on the network provider and on their maintenance program.

Apparently its a fairly standard and well understood M2M problem and has a standard fix - reboot the device every 24 hours, which i’m hopeful I can do automatically in software. Doesn’t sound very nice, but if that’s the standard fix, that’s what I’ll have to do.


#7

Even a static device has ongoing signalling with the BTS - and should be doing periodic location updates.

Indeed

Only if there’s just one tower “visible” - more usually, if you watch the +CREG unsolicited notifications, you should see the device switching between available towers.

This is one reason why the CSQ signal strength reading alone is not a very useful indication of “good” coverage…

In general, other towers should be abel to take over the service.

But, even if no other tower is available, the modem should be able to detect the fact that it has lost service.

The modem should be able to reconnect when the BTS reappears - but, if it doesn’t, a reboot is needed.

Because, as you say, they don’t get left in one place for extended periods!

I do occasionally get strange behaviour like this with my phone; eg, with the phone sitting on my desk, I will get a notification of new voicemail - but the phone did not ever ring for the incoming call!

Yes, you can.


#8

Thanks for your experiences:
Here’s mine

https://forum.sierrawireless.com/t/gprs-maintaining-link-wregc/4655/1

https://forum.sierrawireless.com/t/gprs-maintaining-link/3146/5

because of the network outage issue, it looks like rebooting every 24 hours is the only safe option.


#9

Ok it looks like a scheduled reboot every 24 hours is one solution, but that means I might be off the air for up to 24 hours and not know it. Might there be a way for my App to keep track of the network connection state (eg CREG notifications) and do an additonal unscheduled reboot as required. Does that sound plausible ?


#10

Yes, you should certainly keep track of the +CREG state (possibly also monitor +WIND 8 and 7).
If that shows that you’ve been unregistered for “too long”, then do a reboot.

You have to decide what constitutes “too long” for your particular requirements - but note that it can take several minutes to register in certain circumstances…

Note also that networks can “blacklist” a device which (in their opinion) reboots “too often”…

But that’s only part of the story!

If something goes wrong “further up” in the network, you could remain registered, but lose comms.

This is certainly the case with GPRS: If you leave the connection idle for “too long” (operator and/or subscription dependent), your session will time-out at the APN but you will not lose registration;
in fact, you get absolutely no notification whatsoever of this - the situation is undetectable other than by sending a message & verifying that you get a genuine response from the other end.

Therefore the only fully reliable way to confirm that you really are still connected is to have some kind of end-to-end “heartbeat” between your remote device and your “server”.


#11

Rather than resetting, have you tried unregistering from the network?
AT+COPS=2
…and then, sometime later, re-registering:
AT+COPS=0 (automatic, or 1 for manual registration - see examples in the “AT command interface guide”)


#12

Hello Johnysoft,
I have had a similar problem with Q64s where in low signal strength locations, they would occasionally get into a state where they give the CMEE 13 error to most AT commands. I have found that you can produce this problem at shut down(AT+CPOF=1) where the signal status changes right around the time they attempt to register/de-register. I attempted to fix this problem by shutting just the phone down (AT+CFUN=4) 30 seconds before complete shutdown. This made it worse, it would happen often. I produce the problem by either disconnecting the aerial until registration is lost then reconnecting as they begin to close down OR when registered disconnect the aerial close to close down time. Seems to happen only in a low signal strength locations as with good signal strength locations they are able to register/de-register without an aerial and problem does not occur.


#13

There may be Another Way: https://forum.sierrawireless.com/t/undocumented-side-effect-of-at-cops-0/4871/1


#14

Well I have a similar issue but it happens in different conditions.
When my application uploads data throught FTP … during the transfer at some random point, occasionally, the modem deregister GPRS, GSM and everything else. The bearer closes I get an unsolicited +WBCI: 0 +CREG 0 and the WIND signal of network lost.
In this case I have noticed that both CSQ and COPS return ERROR in this condition. So I use them as an indicator for reboot (an external PIC receives the command from the Q2686) and then reboots everything.


#15

Are you getting a power supply glitch or drop-out?

That could certainly mess-up your GSM/GPRS - even if it’s not (quite) enough to completely restart the whole module…

Take a look at the FAQ/Wiki thread - there’s a load of stuff about power supply problems there.

viewtopic.php?f=7&t=3766&start=0

GSM modules in general - not just SiWi/Wavecom - are quite demanding on their power supplies…


#16

Dear All,
It is Nothing But a Sierra wireless Bug… I am facing this problem frequently in Vehicle tracking system. even it does not get back network after coming back to home network. also it is not coming up even with Hard reset . We need to completely remove the power source and apply back. then only it comes.