This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NB-IOT JIO SIM Not connecting asset tracker Work Up to RRC Connected and stuck there.

Using NB- IOT JIO SIM in india, not connecting asset tracker Work Up to RRC Connected and stuck there. This is custom code very similar to asset tracker example. We are using custom board, same setup works fine on Ibasis SIM in USA.

[00:00:00.215,576] [0m<inf> asset_tracker: Connecting to LTE network.[0m
[00:00:00.215,942] [0m<inf> asset_tracker: This may take several minutes.[0m
[00:00:00.223,205] [0m<dbg> lte_lc.lte_lc_system_mode_set: Sending AT command to set system mode: AT%XSYSTEMMODE=0,1,1,0[0m
[00:00:00.259,643] [0m<inf> lte_lc: PDP Context: AT+CGDCONT=0,"IPV6","JioIPIoT"[0m
[00:00:00.267,608] [0m<dbg> lte_lc.lte_lc_system_mode_set: Sending AT command to set system mode: AT%XSYSTEMMODE=0,1,1,0[0m
[00:00:27.635,711] [0m<dbg> lte_lc.at_handler: +CEREG notification: +CEREG: 2,"C061","00282218",9
[0m
[00:00:27.636,444] [0m<inf> asset_tracker: LTE cell changed: Cell ID: 2630168, Tracking area: 49249[0m

trace-2021-07-13T00-06-58.563Z.pcapng

trace-2021-07-13T00-06-58.563Z.bin

  • 1. Yes, the problem isn't the reset loop but the logs aren't showing why the Attach isn't succeeding, because the Attach request is being blocked by the reset loop. So we needed a trace where the reset loop isn't blocking the Attach request to be able to see the reason for failure, which is most likely the same reason on MFW 1.2.3. 

    2. I would assume the marking on the SIP is the correct version, but I will double check this. 

    Your log revealed why the Attach doesn't succeed. The network does not allow to access with this SIM card (no matter which MFW version used), because there is no roaming agreement etc. If it should be possible to access the network with this card, you need to contact the carrier to resolve this.

  • 1. Yes, the problem isn't the reset loop but the logs aren't showing why the Attach isn't succeeding, because the Attach request is being blocked by the reset loop. So we needed a trace where the reset loop isn't blocking the Attach request to be able to see the reason for failure, which is most likely the same reason on MFW 1.2.3. 

    I thought reset loop only present in MFW  1.3.0 and not in MFW  1.2.3, so I assumed there will be no reset loop blocking in MFW 1.2.3.

    Your log revealed why the Attach doesn't succeed. The network does not allow to access with this SIM card (no matter which MFW version used), because there is no roaming agreement etc. If it should be possible to access the network with this card, you need to contact the carrier to resolve this.

    I already contacted them, earlier they are asking for more detailed log Like I said in earlier posts. Let me send them new log, but they are asking for LTE Physical, MAC, RRC, NAS signaling so don't know they can support.

    So in the both new logs there is no reset loop observed. Right?

  • There is no roaming as they are the only cellular provider in India at the moment for NBIOT, and they have PAN India NBIoT working.

  • Hi, 

    Hardik.Harpal said:
    I thought reset loop only present in MFW  1.3.0 and not in MFW  1.2.3, so I assumed there will be no reset loop blocking in MFW 1.2.3.

     Yes, the reset loop is only present in MFW 1.3.0. The reset loop isn't the problem, but it was preventing us from seeing the reason for the ATTACH request being rejected. 

    RRC and NAS is visible in the PCAP file that you have attached earlier. And they show the reject PDU from the network. 

    We don't understand why they want LTE physical or MAC. The reject is clear and visible, and the failure is in the NAS level, not below, meaning RRC PDUs should not be needed either.

  • Ok thanks 

    2) I have nrf9160 SIP marked B0, but it is showing Model: NRF9160_xxAA_REV2.in nrf programmer but as per modem firmware download section it is showing  \different B0 = Rev1 and as per guideline it is recommended to use rev1.3.0 on B1 = Rev 2 So can you clarify I am hesitating to use modem fw version 1.3.0 on our custom board I had one board with modem FW1.3.0 due to some hardware issue that board is not working. I need to upgrade modem fw in another board but is it safe.

    Can you check above, not that urgent, but we definitely need clarity on this? We just ordered few from digikey 2 months back, but it is same B0 marking but with Rev2 read n programmer. 

Related