Roaming sim card on EHS6 | Telit Cinterion IoT Developer Community
February 27, 2017 - 12:23pm, 6098 views
I am using a roaming SIM card on EHS6 module and facing some difficulties when selecting network operator.
1, I sometimes experience switching of network operators. The module sometimes stays on a network for a few seconds and then switches to another network.
2, When disconnection happens, I send AT+COPS=0 but receive error: "operation temporary not allowed" or no response from module. I wait for 5 minutes but still no response, so I send some random character and the operation was aborted.
3, I try sending AT+COPS=2 to deregister, then send AT+COPS=0 to test and the above mentioned happens.
I saw this thread https://iot-developer.thalesgroup.com/threads/ph8-network-selection-roam...
Probably I am facing the same problem?
I am wondering if probably there are cases where AT+COPS=0 is not supposed to be used?
In the thread that you have mentioned the user application was sending AT+COPS=0 and that was the cause of switching the roaming networks.
How about the network quality - maybe this is a reason of frequent network changing or problems with network selection.
Network quality was fine. I would do further test to double check.
I noticed that when +COPS:2, AT+CSQ still returns a valid rssi (+CSQ: 15,99 for example). Is it the correct behaviour, shouldn't it be +CSQ: 99,99
May I ask why for roaming SIM, after I send AT+COPS=2, there's +PBREADY URC
The URC is not observed when using local SIM.
After AT+COPS=2 the module should deregister form the network which can be confirmed by AT+COPS?. The best CSQ answer would then be 99,99. Is this value changing after deregistration? Maybe it shows the last available value.
The +PBREADY should only be thrown after the module has finished reading the data from SIM card which happens after start, entering PIN or inserting SIM card. Can you check the ATI1 reply?
This is my log:
9:05:57.402> +CREG: 5
9:06:49.826> +CREG: 0
9:07:31.764> +CREG: 5
9:07:35.073> +CREG: 0
9:08:05.341> +CREG: 5
9:09:26.222> +CREG: 0
9:09:57.112> +CREG: 3
9:09:57.674> +CREG: 0
9:10:06.161> +CREG: 3
9:10:06.161> +CREG: 0
9:10:49.970> +CREG: 5
9:13:06.955> +CREG: 0
9:16:42.965> REVISION 03.001
9:16:42.965> A-REVISION 00.000.49
9:17:23.592> +COPS: 2
9:17:28.776> +CSQ: 18,99
I am not sure what is happening. Why are there constant registration/degregistration as well as SIM authentication?
This does not happen all the time but I wish to understand when/why it happens to handle it properly.
FYI, I am using a MVNO SIM
The log is very strange. There are frequent network deregistrations followed by +PBREADY as if the SIM card was removed and inserted. That could suggest some problems with the SIM card or communication with the card. Maybe the SIM is broken - have you tried other SIM cards from that provider? Maybe there's some hardware problem with the SIM interface - what hardware are you using, do you have more than one set? Finally maybe there's some incompatibility with this particular MNO. Generally MVNO should not be a problem.
I do not face this problem with local sim card, so I think the hardware is fine. I have tried other SIM cards from the same provider too.
This frequent deregistration followed by +PBREADY is not always observed upon start-up. However, it's always the case when I use AT+COPS=2. This is an example:
19:21:50.230> +CREG: 5
19:21:55.034> +COPS: 0,0,"Singtel",2
19:22:05.955> +CREG: 0
19:22:38.155> +CREG: 5
19:22:43.084> +CREG: 0
19:22:48.888> +CREG: 3
19:22:48.888> +CREG: 0
19:29:30.214> +COPS: 0,0,"StarHub",2
I think when I use AT+COPS=2, the module should not attempt to *********** to a network but the log shows otherwise.
Do you think I need to change something in the SIM Toolkit?
After the manual deregistration the module should stay unregistered until some other **** is selected with AT+COPS command.
But it is also written in the AT commands specification "When SIM PIN is disabled or after SIM PIN authentication has completed and
"+PBREADY" URC has shown up the powerup default <****>=2 automatically changes to <****>=0, causing the ME to select a network."
There is +PBREADY in your log and that would explain the network registration. But still something is malfunctioning - +PBREADY should not be there.
How about the module - do you have more modules to check if that one is not damaged.
I think that the problem might be in the communication between the SIM and the module, particularly some operator's applications on SIM might contribute to these problems. So some tracing of this communication might be necessary. Maybe you could also contact the SIM provider if their cards are using any unstandard or extensive communication with the device.
I have tested on a few modules of the same firmware version, including an EVK too.
Another observation I have is that if I send a second AT+COPS=2, there would be no +PBREADY, but the module cannot register to any network afterwards: sending AT+COPS=0 results in no response from the module (no 'ERROR' even). I have to send some random character to terminate the operation. An AT+COPS? check gives response +COPS:2
16:35:07.920> +CREG: 5,"01A5","000CEAC5",4
16:49:05.037> +CREG: 0
16:54:31.720> +COPS: 2
16:54:37.086> +CPIN: READY
Do you think the hanging is caused by the SIM or module?
I think that it's not possible to claim without any tracing. No reply for at+cops=0 doesn't look good but on the other hand it was possible to break the command.
This seems to be a very specific problem that occurs with the specific provider only. I think that you should contact your local distributor. Maybe they have some experience with this operator and will be able to advice or do some tracing that would be necessary to push this further.
There is an update for your firmware so you could also try to verify with the newer version or older but this might not bring anything new.