User in Guernsey cannot connect to the network with NRF9160

Hi,

I have a customer in Guernsey that received one of our Thingy91 hubs and he's not able to connect.

Here is some troubleshooting facts :

- when he moves to London the device connects successfully

- when he looks to the available networks locally with his iphone, there is actually an LTE network see snapshot.

- if he puts our SIM in his phone, it works properly establishing a connection.

- when he looks to the available networks through the Thingy:91 with the LTE Link Monitor using AT+COPS? command : nothing is reported

What may be wrong with this location? are there "special" LTE networks that the NRF9160 cannot see?

What troubleshooting would you suggest to move ahead?

Thanks for your help

LP

Parents
  • Hi,

    Is there LTE-M or NB-IoT coverage on Guernsey?

    The nRF9160 only works with LTE-M and NB-IoT, and not "normal" LTE like a cell phone.

    - when he looks to the available networks through the Thingy:91 with the LTE Link Monitor using AT+COPS? command : nothing is reported

    This would indicate that there isn't LTE-M or NB-IoT (whichever the modem is configured to use) coverage at that location.

    Best regards,

    Didrik

  • That's right, nothing reported with AT+COPS?  See the trace below.

    To better understand the underlying topic, an LTE and an LTE-M network are two different protocols that do not necessarily go together?

    It depends on how the overall network (or maybe the single antenna) are configured?

    How can we check the coverage then? checking with a smartphone may be misleading since it will find 4G=LTE but not check for LTE-M

    Is there any available documentation on this practical aspect? I am not finding it on the web.

    LP

    2022-12-13T09:36:22.369Z DEBUG Application data folder: C:\Users\user\AppData\Roaming\nrfconnect\pc-nrfconnect-linkmonitor
    2022-12-13T09:36:22.466Z INFO Using nrf-device-lib-js version: 0.4.13
    2022-12-13T09:36:22.466Z INFO Using nrf-device-lib version: 0.12.8
    2022-12-13T09:36:22.466Z INFO Using nrfjprog DLL version: 10.16.0
    2022-12-13T09:36:22.467Z INFO Using JLink version: JLink_V7.82a
    2022-12-13T09:36:22.501Z DEBUG App pc-nrfconnect-linkmonitor v2.0.2 official
    2022-12-13T09:36:22.501Z DEBUG App path: C:\Users\user\.nrfconnect-apps\node_modules\pc-nrfconnect-linkmonitor
    2022-12-13T09:36:22.502Z DEBUG nRFConnect 3.12.0, required by the app is (^3.12.0)
    2022-12-13T09:36:22.502Z DEBUG nRFConnect path: C:\Users\user\AppData\Local\Programs\nrfconnect\resources\app.asar
    2022-12-13T09:36:22.502Z DEBUG HomeDir: C:\Users\user
    2022-12-13T09:36:22.502Z DEBUG TmpDir: C:\Users\user\AppData\Local\Temp
    2022-12-13T09:36:22.504Z INFO Installed JLink version does not match the provided version (V7.66a)
    2022-12-13T09:36:30.205Z INFO Modem port is opened
    2022-12-13T09:36:30.222Z DEBUG modem >> AT+CFUN?
    2022-12-13T09:36:30.264Z DEBUG modem << +CFUN: 0
    2022-12-13T09:36:30.269Z DEBUG modem << OK
    2022-12-13T09:36:59.885Z DEBUG modem >> AT+CFUN=1
    2022-12-13T09:36:59.937Z DEBUG modem << OK
    2022-12-13T09:37:06.439Z DEBUG modem >> AT+CFUN?
    2022-12-13T09:37:06.449Z DEBUG modem << +CFUN: 1
    2022-12-13T09:37:06.469Z DEBUG modem << OK
    2022-12-13T09:37:06.477Z DEBUG modem >> AT+CGSN=1
    2022-12-13T09:37:06.488Z DEBUG modem << +CGSN: "352656101505934"
    2022-12-13T09:37:06.494Z DEBUG modem << OK
    2022-12-13T09:37:06.502Z DEBUG modem >> AT+CGMI
    2022-12-13T09:37:06.517Z DEBUG modem << Nordic Semiconductor ASA
    2022-12-13T09:37:06.520Z DEBUG modem << OK
    2022-12-13T09:37:06.527Z DEBUG modem >> AT+CGMM
    2022-12-13T09:37:06.536Z DEBUG modem << nRF9160-SICA
    2022-12-13T09:37:06.538Z DEBUG modem << OK
    2022-12-13T09:37:06.546Z DEBUG modem >> AT+CGMR
    2022-12-13T09:37:06.554Z DEBUG modem << mfw_nrf9160_1.3.2
    2022-12-13T09:37:06.557Z DEBUG modem << OK
    2022-12-13T09:37:06.560Z INFO Nordic Semiconductor ASA nRF9160-SICA [mfw_nrf9160_1.3.2] SerNr: 352656101505934
    2022-12-13T09:37:06.564Z DEBUG modem >> AT+CEMODE?
    2022-12-13T09:37:06.575Z DEBUG modem << +CEMODE: 2
    2022-12-13T09:37:06.578Z DEBUG modem << OK
    2022-12-13T09:37:06.593Z DEBUG modem >> AT%XCBAND=?
    2022-12-13T09:37:06.604Z DEBUG modem << %XCBAND: (1,2,3,4,5,8,12,13,18,19,20,25,26,28,66)
    2022-12-13T09:37:06.608Z DEBUG modem << OK
    2022-12-13T09:37:06.625Z DEBUG modem >> AT+CMEE?
    2022-12-13T09:37:06.635Z DEBUG modem << +CMEE: 0
    2022-12-13T09:37:06.637Z DEBUG modem << OK
    2022-12-13T09:37:06.645Z DEBUG modem >> AT+CMEE=1
    2022-12-13T09:37:06.651Z DEBUG modem << OK
    2022-12-13T09:37:06.655Z DEBUG modem >> AT+CNEC?
    2022-12-13T09:37:06.664Z DEBUG modem << +CNEC: 0
    2022-12-13T09:37:06.666Z DEBUG modem << OK
    2022-12-13T09:37:06.671Z DEBUG modem >> AT+CNEC=24
    2022-12-13T09:37:06.678Z DEBUG modem << OK
    2022-12-13T09:37:06.684Z DEBUG modem >> AT+CGEREP?
    2022-12-13T09:37:06.693Z DEBUG modem << +CGEREP: 0,0
    2022-12-13T09:37:06.695Z DEBUG modem << OK
    2022-12-13T09:37:06.700Z DEBUG modem >> AT+CGDCONT?
    2022-12-13T09:37:06.709Z DEBUG modem << OK
    2022-12-13T09:37:06.714Z DEBUG modem >> AT+CGACT?
    2022-12-13T09:37:06.720Z DEBUG modem << OK
    2022-12-13T09:37:06.726Z DEBUG modem >> AT+CGEREP=1
    2022-12-13T09:37:06.733Z DEBUG modem << OK
    2022-12-13T09:37:06.738Z DEBUG modem >> AT+CIND=1,1,1
    2022-12-13T09:37:06.745Z DEBUG modem << OK
    2022-12-13T09:37:06.750Z DEBUG modem >> AT+CEREG=5
    2022-12-13T09:37:06.760Z DEBUG modem << OK
    2022-12-13T09:37:06.764Z DEBUG modem >> AT+CEREG?
    2022-12-13T09:37:06.774Z DEBUG modem << +CEREG: 5,4
    2022-12-13T09:37:06.778Z DEBUG modem << OK
    2022-12-13T09:37:06.796Z DEBUG modem >> AT%CESQ=1
    2022-12-13T09:37:06.804Z DEBUG modem << OK
    2022-12-13T09:37:06.810Z DEBUG modem >> AT+CESQ
    2022-12-13T09:37:06.820Z DEBUG modem << +CESQ: 99,99,255,255,255,255
    2022-12-13T09:37:06.822Z DEBUG modem << OK
    2022-12-13T09:37:06.834Z DEBUG modem >> AT%XSIM=1
    2022-12-13T09:37:06.843Z DEBUG modem << OK
    2022-12-13T09:37:06.849Z DEBUG modem >> AT%XSIM?
    2022-12-13T09:37:06.860Z DEBUG modem << %XSIM: 1
    2022-12-13T09:37:06.862Z DEBUG modem << OK
    2022-12-13T09:37:06.872Z DEBUG modem >> AT+CPIN?
    2022-12-13T09:37:06.882Z DEBUG modem << +CPIN: READY
    2022-12-13T09:37:06.885Z DEBUG modem << OK
    2022-12-13T09:37:06.898Z DEBUG modem >> AT+CPINR="SIM PIN"
    2022-12-13T09:37:06.917Z DEBUG modem << +CPINR: "SIM PIN",3
    2022-12-13T09:37:06.920Z DEBUG modem << OK
    2022-12-13T09:37:06.934Z DEBUG modem >> AT+CIMI
    2022-12-13T09:37:06.943Z DEBUG modem << 234500093370919
    2022-12-13T09:37:06.946Z DEBUG modem << OK
    2022-12-13T09:37:06.947Z INFO IMSIdentity: 234500093370919
    2022-12-13T09:38:08.689Z DEBUG modem << +CEREG: 4
    2022-12-13T09:40:25.786Z DEBUG modem >> AT+COPS=?
    2022-12-13T09:40:26.795Z ERROR Error: 'AT+COPS=?
    ' timed out
    2022-12-13T09:40:44.284Z DEBUG modem << +CEREG: 2
    2022-12-13T09:41:17.932Z DEBUG modem << +CEREG: 4
    2022-12-13T09:41:55.439Z DEBUG modem << +CEREG: 2
    2022-12-13T09:43:04.800Z DEBUG modem << +CEREG: 4
    2022-12-13T09:43:24.958Z DEBUG modem << +COPS:
    2022-12-13T09:43:24.961Z DEBUG modem << OK
    2022-12-13T09:46:27.658Z DEBUG modem >> AT+COPS=?
    2022-12-13T09:46:59.168Z DEBUG modem << +CEREG: 2
    2022-12-13T09:47:01.356Z DEBUG modem << +CEREG: 4
    2022-12-13T09:47:44.749Z DEBUG modem << +CEREG: 2
    2022-12-13T09:47:44.755Z DEBUG modem << +COPS:
    2022-12-13T09:47:44.761Z DEBUG modem << OK
    2022-12-13T09:47:44.771Z DEBUG modem >> AT+COPS?
    2022-12-13T09:47:44.780Z DEBUG modem << +COPS: 1
    2022-12-13T09:47:44.783Z DEBUG modem << OK
    2022-12-13T09:48:18.300Z DEBUG modem << +CEREG: 4
    2022-12-13T09:49:00.558Z DEBUG modem << +CEREG: 2
    2022-12-13T09:50:10.201Z DEBUG modem << +CEREG: 4

  • This is a weird answer,

    Bouygues Telecom  and Société Française du Radiotéléphone are two french carriers. I have them at home (I'm in france) but my customer shouldn't have them in Guernsey and he took the trace with a NRF DK board in the island. The only way to explain those networks being found is that some signal from continental France, 50km, away is reaching the island ?  https://www.ariase.com/mobile/carte-antennes?iframe=1&partner=ariase&lat=49.43889157913611&lng=-2.2973269173533026&zoom=9.133815980236399&interactive=1

    or that the device has some memory in the trace from when I had it home in france?

    Maybe the root cause is related with this to explain what's going on there...

    I do not thing user made an AT%XBANDLOCK because we used the original nordic app to run the tests

    img_app_bl/debug/thingy91_asset_tracker_v2_debug_2022-12-08_188a1603.hex               =>  Asset tracker v2 firmware for nRF9160, modem debug enabled, NB-Iot and LTE-M network modes

    Hologram covers Guernsey with Sure carrier (https://support.hologram.io/hc/en-us/articles/360035213914-What-countries-and-carriers-do-you-support-)

    As I told you we can also use a SIM from Jersey Air limited. This network seems to have NB-IoT active. Using thingy91_asset_tracker we should see it and be able to connect with their own SIM right?

    What kind of test would you suggest to do now?

  • Hi, and sorry for the late reply.

    What board are they using?

    lzpons said:
    he took the trace with a NRF DK board
    lzpons said:
    mg_app_bl/debug/thingy91_asset_tracker_v2_debug_2022-12-08_188a1603.hex

    That file is for a Thingy:91, not a DK.

    lzpons said:
    Hologram covers Guernsey with Sure carrier

    I am not able to see if this agreement supports LTE-M and/or NB-IoT or not. It might not be covered.

    Getting a modem trace with the Jersey Air SIM would also be useful.

  •   below are two tests traces run by the customer on Thingy91 board (no DK) using the thingy91_asset_tracker_v2_debug_2022-12-08_188a1603.hex app together with a locally purchased Jersey Airtel SIM.

    - First test runs app in default mode

    trace-2023-02-08T19-14-25.294Z_JerseyAirtel_SIM.bin

    trace-2023-02-08T19-14-25.294Z_JerseyAirtel_SIM.bin

    - Second test has been forced to nbiot

    trace-2023-02-09T10-28-05.811Z_JerseyAirtel_SIM_NBIOT_forced.bin

    AT%XSYSTEMMODE=0,1,0,0
    AT+CGDCONT=0,"IPV4V6","cdp.iot.t-mobile.nl"
    AT+COPS=1,2,"23403",9
    AT+CFUN=1

    trace-2023-02-09T10-28-05.811Z_JerseyAirtel_SIM_NBIOT_forced.bin

    As a reminder (because there is already a long tread here) what we are seeking is to undersdand

    - is there or not any LTE-M network available we can connect to?

    - otherwise can we connect to nb-IoT as an alternative?

    - If none are available what is the suspected reason?

    Hope you can diagnose something.

  • In the JerseyAritel_SIM trace, manual network selection requested to 208 20 (Bouygues Telecom) which is not found. Could you try to send AT+COPS=0 (set automatic network selection), then AT+CFUN=0 (store the settings to non-volatile memory), and then reset the device?

    In the JerseyAirtel_SIM_NBIOT_forced trace, this was the teams analysis:

    Not forced to use NBIOT (looking at the trace, it looks like you tried to set NB-IoT only mode  while the modem is running. This is not allowed. %XSYSTEMMODE must be used while the modem is offline), but forced (i.e. manual network selection) to 234 03 (Jersey Airtel). There is one tracking area available (in NBIoT), but network rejects Attach with cause #15 "No suitable cells in tracking area". This means that device is not allowed to operate in this tracking area with this SIM subscription. In the end of the log modem finds another tracking area and initiates Attach procedure. This time the Attach is not successful because signalling connection is lost before receiving Attach Accept. This is a bit unexpectable, because mapped RSRP was 47 at the time the cell was found. Although, there were some change in radio conditions because at first this cell was not found at all. Assuming the SIM subscription should work with Jersey Airtel, for some reason network releases the RRC connection in the middle of Attach procedure. We don't know the reason, but have seen similar now and then.

    Looking at the traces, it also looks like you are trying to set the APN manually. Are you sure you are using the pre-compiled applications, and not a custom one?

    It might also be that these settings has been stored in the modem previously. You can try to delete all saved data in the modem with the %XFACTORYRESET AT command. Resetting the user data should be enough. Note that this command also must be used while the modem is offline, so it can be a good idea to use AT+CFUN=4 first.

  • As a way forward, the modem team suggest you ask Airtel if the device/SIM card is supposed to be able to connect at that location:

    I can see from IMSI that the home network is 234 03 Jersey Airtel. From log we can see that tracking area 0A33 gives the Attach reject #15 "No suitable cells in tracking area". Customer could ask from the operator why their SIM subscription is not allowed to work in that tracking area. In another tracking area (09CF) network releases the RRC connection before Attach Accept is received, which seem not to be due to signal quality from modem point of view. This kind of unexpected RRC connection releases we have seen earlier but we have no workarounds for that and we don't know why this happens. But I think this is not network's way to reject the device, meaning that without this unexpected release the Attach might even get accepted.

Reply
  • As a way forward, the modem team suggest you ask Airtel if the device/SIM card is supposed to be able to connect at that location:

    I can see from IMSI that the home network is 234 03 Jersey Airtel. From log we can see that tracking area 0A33 gives the Attach reject #15 "No suitable cells in tracking area". Customer could ask from the operator why their SIM subscription is not allowed to work in that tracking area. In another tracking area (09CF) network releases the RRC connection before Attach Accept is received, which seem not to be due to signal quality from modem point of view. This kind of unexpected RRC connection releases we have seen earlier but we have no workarounds for that and we don't know why this happens. But I think this is not network's way to reject the device, meaning that without this unexpected release the Attach might even get accepted.

Children
  • Hello Didrik,

    Thanks for the latest answer. It was helpful. We went back to the SIM provider asking them what their SIM was capable. It seems that not all the support people at Airtel was aware SIM was supporting only data (on a mobile) and that this is not the same than data for M2M. Finally we found an expert in their team who advised us properly and providing a SIM that supports NB-iot in their own network (Airtel).

    So as a summary, this was the main issue with all this support ticket : The SIM was not connecting because had the wrong "configuration". New SIM specially focused on M2M and nb-iot is able to connect.

    (still facing some small issues on getting time from the network, but this is another topic.

    I believe can close this ticket.

    Thanks A LOT for your help and patience.

    Lorenzo

Related