Network Rejected

Hey All,

We have 2 of our 25 WP8548 units that are struggling to connect to cellular networks. I have tried swapping SIM cards on these units but the problem stays with the hardware. I find that the Network Operator (Rogers Wireless) is discovered with strong signal strength, but it doesn’t register.

In the logs I see “Network Registration failed error code 21” and “Code 2” and “Code 14”. I also see “Network Reject Ind Handler called with Rat.4, mcc. and mnc.”

Thanks for the help


Hi @coastalbrandon,

A couple of other things to check:

  1. Is the SIM pin locked?
    Use cm sim to get info on the state of the sim (should be something like unlocked and ready);
    Use cm sim info to get detailed info on the sim

  2. Have you got the correct APN set for the ISP?
    Use cm data to get the info for the data connection (including the current APN)

And … I’m assuming you’ve got a mangOH or FX30 here … if you’ve removed and reinserted the SIM while the WP85 is powered up, you will have to reboot the device as neither of these platforms have got a SIM holder with the SIM detect switch, and the only way to ‘reregister’ the presence of the SIM is to reboot…

Hope this helps.

ciao, Dave

Hey @davidc

Here is an output from CM SIM and CM Data. These are sierra SIM cards (not trial SIM cards). We have about 15 WP8548 boards sitting side by side in our office and two of the units really struggle to get on cellular networks. Below is also a log output, which is possibly also related to this forum post.

> ug  9 15:43:34 swi-mdm9x15 user.debug Legato:  DBUG | sensorToCloud[918]/sensorToCloud_exe T=main | _main.c main() 69 | == Starting Event Processing Loop ==
> Aug  9 15:43:35 swi-mdm9x15 user.info Legato:  INFO | sensorToCloud[918]/sensors T=main | analoginputs.c analog_initSpiHandle() 77 | Initializing SPI handle
> Aug  9 15:43:35 swi-mdm9x15 user.debug Legato:  DBUG | sensorToCloud[918]/framework T=main | le_spi_client.c DoConnectService() 363 | ======= Starting another client for 'sensorToCloud.sensors.le_spi' service ========
> Aug  9 15:43:35 swi-mdm9x15 user.info Legato:  INFO | sensorToCloud[918]/sensors T=main | analoginputs.c analog_initSpiHandle() 81 | SPI open result: 0
> Aug  9 15:43:35 swi-mdm9x15 user.info Legato:  INFO | sensorToCloud[918]/avPublisher T=main | avPublisher.c _avPublisher_COMPONENT_INIT() 1004 | sensorToCloud started
> Aug  9 15:43:35 swi-mdm9x15 user.debug Legato:  DBUG | sensorToCloud[918]/framework T=main | LE_FILENAME le_mem_ForceAlloc() 841 | Memory pool 'framework.Default Timer Pool' overflowed. Expanded to 2 blocks.
> Aug  9 15:43:35 swi-mdm9x15 user.debug Legato:  DBUG | sensorToCloud[918]/framework T=main | LE_FILENAME le_mem_ForceAlloc() 841 | Memory pool '.le_avdata_ClientData' overflowed. Expanded to 1 blocks.
> Aug  9 15:43:35 swi-mdm9x15 user.warn Legato: -WRN- | dcsDaemon[826]/le_pa_dcs T=main | pa_dcs_linux.c pa_dcs_SetDefaultGateway() 568 | Default gateway or interface is empty
> Aug  9 15:43:35 swi-mdm9x15 user.debug Legato:  DBUG | sensorToCloud[918]/framework T=main | LE_FILENAME le_timer_Start() 1260 | threadRecPtr->timerFD=16
> Aug  9 15:43:35 swi-mdm9x15 user.debug Legato:  DBUG | sensorToCloud[918]/framework T=main | LE_FILENAME le_mem_ForceAlloc() 841 | Memory pool 'framework.FdMonitor' overflowed. Expanded to 11 blocks.
> Aug  9 15:43:35 swi-mdm9x15 user.debug Legato:  DBUG | sensorToCloud[918]/framework T=main | LE_FILENAME le_mem_ForceAlloc() 841 | Memory pool 'framework.hashMap_refFdMonitors' overflowed. Expanded to 12 blocks.
> Aug  9 15:43:35 swi-mdm9x15 user.warn Legato: -WRN- | modemDaemon[875]/le_pa T=main | pa_sim_qmi.c MapSimState() 858 | More than one application 2
> Aug  9 15:43:35 swi-mdm9x15 user.warn Legato: -WRN- | modemDaemon[875]/le_pa T=main | pa_sim_qmi.c MapSimState() 858 | More than one application 2
> Aug  9 15:43:35 swi-mdm9x15 user.info Legato:  INFO | modemDaemon[875]/le_pa T=main | pa_mrc_qmi.c pa_mrc_GetNetworkRegState() 2062 | called
> Aug  9 15:43:35 swi-mdm9x15 user.warn Legato: -WRN- | modemDaemon[875]/le_pa T=main | pa_sim_qmi.c MapSimState() 858 | More than one application 2
> Aug  9 15:43:56 swi-mdm9x15 user.debug kernel: [   60.891927] NMEA read driver miss interrupt, abandon current buff
> Aug  9 15:44:12 swi-mdm9x15 user.debug kernel: [   76.891896] NMEA read driver miss interrupt, abandon current buff
> Aug  9 15:44:20 swi-mdm9x15 user.info Legato:  INFO | supervisor[487]/supervisor T=main | supervisor.c HandleRebootExpiry() 524 | Expired reboot timer
> Aug  9 15:44:24 swi-mdm9x15 user.warn Legato: -WRN- | modemDaemon[875]/le_pa T=main | pa_sim_qmi.c MapSimState() 858 | More than one application 2
> Aug  9 15:44:26 swi-mdm9x15 user.info Legato:  INFO | gpsMonitor[863]/location T=main | location.c getLocation() 87 | Failed to get reading... retrying in 1 seconds
> Aug  9 15:44:28 swi-mdm9x15 user.debug kernel: [   92.891683] NMEA read driver miss interrupt, abandon current buff
> root@swi-mdm9x15:~#

hi @coastalbrandon,

From the screenshot you have posted, I notice that the device has 0 signal strength. No signal is going to stop the devices attaching to the network and the SIM cards authorising a network connection.

I would check the hardware - make sure the antenna connections are OK onto the board, maybe try a different fly lead to the antenna in case there is a fault in the cable.

Until you get some signal strength registered, you’re not going to get any connectivity.

PM me for more info in Sierra SIMs.

ciao, Dave

Hey David,

I should have probably gotten a better screenshot, I took it too quickly. Normally we see Signal Strength of 4 or 5 (good or excellent). You can see that from my screenshot on the original post at the top of this topic.

Brandon

Hiya @coastalbrandon,

Arrgh. Only saw the bottom screenshot this time.

Out of interest, as you are using the Sierra SIMs:

  1. are both the devices you’re having problems with trying to connect to Rogers?
  2. Are the rest of the devices that are working also connected to Rogers?

ciao, Dave

Hi @coastalbrandon, in another thread you also mentioned that this happens after some period of connectivity. Is that always the case? If the loss of registration occurs after a long period of normal connected operation, is there a consistent timing to when the drop occurs (eg. after 12 hours of connectivity)? Do you know if these particular devices have always had this behaviour? Is connectivity restored immediately if you power cycle the modem? How long have you observed the device in this rejected state, and does it ever recover automatically?

Regarding the lack of signal strength, @davidc has a good suggestion, but in case that’s intermittent, it might be indicative of the “rest” time the modem takes between full network scans, when unable to successfully register. I notice the first post had a strong signal. For power savings, the modem won’t maintain a constant full network scan, since conditions are not expected to change instantly. I think the full scan will occur after about 45 seconds of this rest time, during which I think 0 signal strength will be reported (since there is no active signal monitoring).

Hey @davidc and @rkirk

  • This connectivity to the cellular networks happens on reboot and plagues individual units more than others, from our observations. We have re-flashed the firmware on the units and re-installed our software on the units. We have seen at least one unit behave better after the firmware is re-flashed, but it wasn’t an extremely controlled test.
  • I have tried different Sierra SIM cards and different antennas, all with the same results.
  • Usually we connect to Rogers on either GSM or UMTS. These units will sometimes connect just fine, sometimes it will never connect.
  • We have seen some units connect to Bell or Telus, but very consistently it seems like Rogers wins.

That’s interesting about the Signal Strength and the power saving. We constantly see this issue though when it has Good or Excellent signal strength, we also see it find Bell and Telus providers and skip over them as well. Rogers definitely seems to be somewhat of a preferred network or something.

Hello @coastalbrandon, Do you still have this issue with those two units? Can you test it infront of a callbox. If it is not possible to test, you can contact the distributor to send it back to Sierra for the RMA process.

Hi @riotc, we had those units sent back to Sierra and one of the units had a failed 3G module in the WP8548.

HI
this topic can be considered as solved , as the issue is handled by Sierra RMA,
best regards,