Network Rejection WP7702

mangOH Red
1

I’ve been having a terrible time getting the mangoh red to connect to a network. I’ve finally gone back to using the mangoh red firmware and the Sierra wireless SIM card, as any other combination just do not seem to work. In any case, even with the Sierra Wireless SIM card, I get network rejections when left on autoconnect. Does anyone know how to ensure a good network registration? I can’t seem to trace down what the intended reason is besides “Location area not allowed”. Here’s my log, and the steps I’ve taken to follow this so far.

Sep 10 13:19:06 swi-mdm9x28-wp user.info Legato:  INFO | modemDaemon[1513]/modemDaemon T=main | le_mrc.c NetRegRejectHandler() 1621 | Network Reject Ind with reject cause.12, domain.3, RAT.4, mcc. and mnc.
Sep 10 13:19:06 swi-mdm9x28-wp user.info Legato:  INFO | dcsDaemon[1466]/dcsCellular T=main | dcsCellular.c DcsNetRegRejectHandler() 756 | Network Reject Ind with reject cause.12, domain.3, RAT.4, mcc. and mnc.
Sep 10 13:19:41 swi-mdm9x28-wp user.info Legato:  INFO | modemDaemon[1513]/modemDaemon T=main | le_mrc.c NetRegRejectHandler() 1621 | Network Reject Ind with reject cause.12, domain.3, RAT.4, mcc. and mnc.
Sep 10 13:19:41 swi-mdm9x28-wp user.info Legato:  INFO | dcsDaemon[1466]/dcsCellular T=main | dcsCellular.c DcsNetRegRejectHandler() 756 | Network Reject Ind with reject cause.12, domain.3, RAT.4, mcc. and mnc.
Sep 10 13:56:43 swi-mdm9x28-wp user.info Legato:  INFO | modemDaemon[1513]/modemDaemon T=main | le_mrc.c NetRegRejectHandler() 1621 | Network Reject Ind with reject cause.12, domain.3, RAT.4, mcc. and mnc.
Sep 10 13:56:43 swi-mdm9x28-wp user.info Legato:  INFO | dcsDaemon[1466]/dcsCellular T=main | dcsCellular.c DcsNetRegRejectHandler() 756 | Network Reject Ind with reject cause.12, domain.3, RAT.4, mcc. and mnc.
Sep 10 13:57:18 swi-mdm9x28-wp user.info Legato:  INFO | modemDaemon[1513]/modemDaemon T=main | le_mrc.c NetRegRejectHandler() 1621 | Network Reject Ind with reject cause.12, domain.3, RAT.4, mcc. and mnc.
Sep 10 13:57:18 swi-mdm9x28-wp user.info Legato:  INFO | dcsDaemon[1466]/dcsCellular T=main | dcsCellular.c DcsNetRegRejectHandler() 756 | Network Reject Ind with reject cause.12, domain.3, RAT.4, mcc. and mnc.

Three quarters the way down this page, it seems to indicate the location area is not allowed. Odd, as the modem has connected to these towers previously. This is not the only rejection code I’ve seen.

When trying other SIM cards on the standard wp7702 firmware (not the mangoh red firmware), I’ve seen codes 8, 10, 12, 13, 15, and 17.

I would like to know what I can do in order to solve this rejection code 12, and if anyone has any ideas as to why I’m getting flat out rejected with other SIM cards, I would love to hear your ideas.

2

Also, very rarely will the module connect to LTE around here. Connects to GSM service just fine but LTE gets rejected with the above mentioned codes constantly. The lab I work in is located downtown, so it isn’t a quality-of-service problem. Signal levels are consistently high.

3

Hi CT1
I’m seeing almost an identical issue with FX30 (WP77) in Australia using Telstra. Registration bouncing between allowed (works for between 15 and 180 mins) and being rejected for 10-90 mins. Bouncing the radio or forcing a manual at+creg often causes a reconnect. reject cause code 12 is a frequent offender.
Any luck solving this one?
Thanks
Brett

4

Are you using fw 14?
Did you turn off psm mode and edrx mode?

5

Hi Jyijyi

R14, I believe PSM and EDRX are disabled.

Details below.
R14.1.1.002 Firmware for Generic GCF
FX30_WP77xx_full_R14.1.1.002-generic_gcf-SWI9X06Y_02.36.06.00.cwe
ati8
Legato Ver: 19.11.5.a1621d58_27c4cd8552e17e79fdc3b0c91ff8bce9_modified
Yocto Ver: SWI9X06Y_02.36.08.00 2021-05-14_12:13:48
OS Ver: Linux version 3.18.140 (oe-user@oe-host) () #1 PREEMPT Fri May 14 11:13:23 UTC 2021
LK Ver: 1.3.0_9c047c35f7
RootFS Ver: SWI9X06Y_02.36.08.00 2021-05-14_12:13:48
UserFS Ver: unknown
MCU Ver: 002.015
OK

at+gmr
SWI9X06Y_02.36.06.00 63d944 jenkins 2020/12/10 19:12:28
OK

at+cedrxs?
+CEDRXS:
OK

at+cpsms?
+CPSMS:0,“01100000”,“00000000”
OK

at+cedrxrdp
CEDRXRDP: 0
OK

I’ve got a ticket logged with M2MOne (Australia) 101862 but they’ve been on holiday over Christmas we haven’t made any progress. This topic seemed very similar. Jasper doesnt even notice the loss of registration until we reconnect and then sees it as user requested.

Any ideas appreciated.
Brett

6

A bit more data. The following logs are from the FX30 at the time that the deregistration occurs. AT+CREG at the time indicates network rejection as well. I believe that reject code 12 is Location Area not available.

Jan 9 20:38:25 fx30 user.info Legato: INFO | dcsDaemon[3218]/dcsCellular T=main | dcsCellular.c DcsCellularConnEventStateHandler() 254 | State of connection 1 transitioned from up to down
Jan 9 20:38:25 fx30 user.info Legato: INFO | dcsDaemon[3218]/dcsCellular T=main | dcsCellular.c le_dcsCellular_RetryConn() 1300 | Initiated retrying connection 1; retry attempt 1, backoff 1 secs
Jan 9 20:38:25 fx30 user.info Legato: INFO | dcsDaemon[3218]/dcsCellular T=main | dcsCellular.c DcsCellularConnEventStateHandler() 311 | Wait for the next retry before failing connection 1
Jan 9 20:38:25 fx30 user.info Legato: INFO | xtensorCore[8262]/xtensorCmpt T=main | connectionManager.c ChannelEventHandler() 699 | ChannelEventHandler: Channel state DOWN after event: 0
Jan 9 20:38:25 fx30 user.info Legato: INFO | modemDaemon[1263]/modemDaemon T=main | le_mrc.c SignalStrengthIndHandlerFunc() 879 | Signal Strength Ind Handler called with RAT.4 and ss.0
Jan 9 20:38:25 fx30 user.info Legato: INFO | dcsDaemon[3218]/dcsCellular T=main | dcsCellular.c DcsCellularPacketSwitchHandler() 726 | Packet switch state: previous 1, new 0
Jan 9 20:38:25 fx30 user.info Legato: INFO | dcsDaemon[3218]/dcs T=main | dcs_db.c le_dcs_EventNotifierTechStateTransition() 311 | Notify all channels of technology 2 of system state transition to down
Jan 9 20:38:25 fx30 user.info Legato: INFO | xtensorCore[8262]/xtensorCmpt T=main | connectionManager.c ChannelEventHandler() 699 | ChannelEventHandler: Channel state DOWN after event: 0
Jan 9 20:38:25 fx30 user.info Legato: INFO | modemDaemon[1263]/modemDaemon T=main | le_mrc.c NetRegRejectHandler() 1461 | Network Reject Ind with reject cause.12, domain.3, RAT.4, mcc. and mnc.
Jan 9 20:38:25 fx30 user.info Legato: INFO | dcsDaemon[3218]/dcsCellular T=main | dcsCellular.c DcsNetRegRejectHandler() 751 | Network Reject Ind with reject cause.12, domain.3, RAT.4, mcc. and mnc.

This is in AEST time.

The Channel Event Handler is in my Legato App and detects the loss of registration – based on sample code from Legato site. At this stage, it is monitoring only and doesn’t try to resolve the outage. It feels like open TCP connections may aggravate the issue but I may be imagining this and this may be a red herring. airVantage also seems to struggle with the issue.

7

Hi Brett,

This issue plagued me a while ago, but I think it was cleared after I performed a clearing of the UPLMN list, along with the FPLMN list. Edit: Try clearing the FPLMN list first, and testing extensively with that. I know my operator has told me that their UPLMN list should give the best performance and they would prefer if I didn’t delete it. Additionally, they specified that the FPLMN list will be rebuilt as the SIM searches through networks.

Another seemingly simple issue that caused odd failures like this- ensure your legato profile matches the one you’re running on the device. We went through a number of different firmwares while finding one that actually worked for us. Usually the apps fail outright, but sometimes they will indicate incorrect or confusing errors.

8

Hi. A progress update.

We’ve been testing in Australia and New Zealand where some networks dont have 2G or are about to phase it out. SW Support have provided us with a new firmware release for the cellular engine side of things. It seems that when 2G isn’t available or has a really poor signal, a recently discovered issue causes the modem to de-register from perfectly good 4G network and go wandering for a while before going back to 4G. The new firmware is heading towards general release but not quite yet. If you’re in an area where 2G isn’t that great and you’ve got WP77xx, this could be (but may not be) the source of intermittent loss of Registration. The SW team have been really helpful with this one and the improvement is very encouraging.

Cheers
B

9

Hi, it looks like we face the same issue here in Quebec. Issue with Telus but not Rogers (still running 2G). Could you provide firmware details and versions that made you progress.

10

Hi Christophe

I understand that the cellular firmware is included in the current BETA release for cat-M FX30 (swi-fx30-catm-4.0.0.beta) but I’d hold off taking that leap until the crinkles have been ironed out (SW are working through the issues in Australia).

We’re testing using an internal release (details below) which is available from SW support. I’m uncertain if that too is beta or not but it is very much more stable where the network doesn’t have 2G.

The file we’re using (more stable):

FX30_WP77xx_full_R14.2.1.001-telstra-SWI9X06Y_02.36.08.02.cwe

The file from the SW website (not stable in Australia Telstra or New Zealand Spark – neither have 2g)

FX30_WP77xx_full_R14.1.1.002-generic_gcf-SWI9X06Y_02.36.06.00.cwe

With the 02.36.08.02 installed:

ati

Manufacturer: Sierra Wireless, Incorporated

Model: FX30(WP7702)

Revision: SWI9X06Y_02.36.08.02 c3f5ef jenkins 2021/09/07 08:00:51

IMEI: 354723090223313

IMEI SV: 6

FSN: VU050686681510

+GCAP: +CGSM

OK

ati8

Legato Ver: 19.11.5.97b4c834_656c465708c8a8e9268d32c5005651c5_modified

Yocto Ver: SWI9X06Y_02.36.08.02 2021-09-22_05:38:17

OS Ver: Linux version 3.18.140 (oe-user@oe-host) () #1 PREEMPT Wed Sep 22 05:30:50 UTC 2021

LK Ver: 1.3.0_9c047c35f7

RootFS Ver: SWI9X06Y_02.36.08.02 2021-09-22_05:38:17

UserFS Ver: unknown

MCU Ver: 002.015

Hope this helps, please let us know what you find. We’re still seeing lesser issues with poor signal areas where it doesn’t reconnect when the signal returns (tunnels, removed antennas etc) but we’re working with SW on this.