We have an WP7609 development board and it has issues with connecting to the LTE band 7 BTS. However, if we downgrade the R16.0.1, it was able to connect fine. Is this the known limitation on R16.3 (Generic — GCF)?
I don’t see problem to register network with LTE Band 7 with FW R16.3:
at!gstatus?
!GSTATUS:
Current Time: 84 Temperature: 33
Modem Mitigate Level: 0 ModemProc Mitigate Level: 0
Reset Counter: 1 Mode: ONLINE
System mode: LTE PS state: Attached
IMS reg state: NOT REGISTERED IMS mode: Normal
IMS Srv State: NO SMS,NO VoIP
LTE band: B7 LTE bw: 20 MHz
LTE Rx chan: 3349 LTE Tx chan: 21349
LTE CA state: INACTIVE
EMM state: Registered Normal Service
RRC state: RRC Connected
PCC RxM RSSI: -64 RSRP (dBm): -98
PCC RxD RSSI: -83 RSRP (dBm): -120
Tx Power: -- TAC: 0652 (1618)
RSRQ (dB): -13 Cell ID: 01E5110D (31789325)
SINR (dB): 0.2
OK
ati3
Manufacturer: Sierra Wireless, Incorporated
Model: WP7609
Revision: SWI9X07Y_02.37.06.05 b15b59 jenkins 2022/09/27 07:54:33
IMEI: 359782080112345
IMEI SV: 18
FSN: WA803370012345
+GCAP: +CGSM
OK
ati8
Legato Ver: 19.11.6_225ac9b7882467c5c7f9e0bf4cdb5523
Yocto Ver: SWI9X07Y_02.37.10.02 2022-02-11_09:57:45
OS Ver: Linux version 3.18.140 (oe-user@oe-host) (gcc version 7.3.0 (GCC) ) #1 PREEMPT Fri Feb 11 09:40:40 UTC 2022
LK Ver: SWI9X07Y_02.37.10.02
RootFS Ver: SWI9X07Y_02.37.10.02 2022-02-11_09:57:45
UserFS Ver: unknown
MCU Ver: 002.015
OK
at!impref?
!IMPREF:
preferred fw version: 02.37.06.05
preferred carrier name: GENERIC
preferred config name: GENERIC_002.121_002
preferred subpri index: 000
current fw version: 02.37.06.05
current carrier name: GENERIC
current config name: GENERIC_002.121_002
current subpri index: 000
OK
Thanks Jyijyi. we are able to make it work, but not as straight forward as it should be. The quote from the person who did the testing:
"After additional experimentation, we were able to connect to the CMW 500 if we set up for 5MHz instead of 20MHz. Once an initial connection was made at 5MHz, we were able to connect at 20MHz even after power cycling the UE and CMW 500. We repeated the entire process with a different UE and again found that an initial connection of 5MHz was required to make subsequent connections at 20MHz. "
not sure if this is CMW500 issue, from my log, it is already in BW 20MHz
Thanks. We will test it with BTS to see what happens.
Hi jyijyi, we tested with the BTS and seeing the same problem.
“same behavior with MBO, it doesn’t connect to 20 MHz cell initially but if we configure MBO to 5 MHz, then it connects and then when switching to 20 MHz config in MBO, it works fine”
Is there any way to get L1 logs on the cell selection to know what is going on?
Thanks
in linux, you can install MBPL USB driver and tool and capture the QXDM log:
we are thinking about using the tool at https://source.sierrawireless.com/resources/airprime/tools/airprime-swilog/#sthash.SGBXvEyk.dpbs to get the logs. More info from the team:
here’s further info regarding the 20 MHz BW troubleshooting:
-
Verified that it is not SIM dependent, same behavior observed between eSIM and Phy SIM
-
Verified that the same behavior is happening between Magellan UE and Mango Dev Board with WP7609 modem
-
Scenario 1 (fail): UE does not connect to 20 MHz cell with center frequency @ 2645 MHz (EARFCN 3000) ← This is our baseline / target configuration
-
Scenario 2 (success): UE connects to 5 MHz cell with center frequency @ 2645 MHz (EARFCN 3000) and then is able to connect to 20 MHz cell with center frequency @ 2645 MHz (EARFCN 3000)
-
Scenario 3 (fail): UE does not connect to 20 MHz cell with center frequency @ 2640 MHz (EARFCN 2950)
-
Scenario 4 (success): UE connects to 20 MHz cell with center frequency @ 2635 MHz (EARFCN 2900)
-
Scenario 5 (success): UE connects to 20 MHz cell with center frequency @ 2630 MHz (EARFCN 2850)
Unfortunately, and unlike Scenario 2, in Scenario 4 & 5, after the successful connection, when we change the EARFN back to 3000 the UE fails to connect.
All above tests were done with real MBO/eNB with PLMN ID 999:99
have you tried with real network with LTE band 7?
you mean with the real carrier like ATT, TMO? No, all tests are done with the BTS in the lab.
No idea how to validate your equipment in the lab…
If you connect to real network, at least can make sure if this is module problem
We are in the US and B7 is not available. If we are using the tool you mentioned above, is there any particular logs we need to look for?
what is the target country you are going to deploy for this product?
Australia?
For the DM logging tool, you can use the default filter
no country :). this is a special project for NASA
we will provide both UE and BTS for our use case. We re-tested with R16.0.1 and experienced the same problem, so this issue is not release related
after you capture the DM log, you can send to distributor for further analysis
how can you verified the equipment in the lab is working?
Did you try with cell phone?
Other LTE module?
we tried with B3 and it is working fine. These are tests we did on B7:
as you can see only the red ones are having problem
how about using EARFCN 3349 instead of 3350?
From my test, I can register network with this EARFCN:
at!gstatus?
!GSTATUS:
Current Time: 84 Temperature: 33
Modem Mitigate Level: 0 ModemProc Mitigate Level: 0
Reset Counter: 1 Mode: ONLINE
System mode: LTE PS state: Attached
IMS reg state: NOT REGISTERED IMS mode: Normal
IMS Srv State: NO SMS,NO VoIP
LTE band: B7 LTE bw: 20 MHz
LTE Rx chan: 3349 LTE Tx chan: 21349
LTE CA state: INACTIVE
EMM state: Registered Normal Service
RRC state: RRC Connected
PCC RxM RSSI: -64 RSRP (dBm): -98
PCC RxD RSSI: -83 RSRP (dBm): -120
Tx Power: -- TAC: 0652 (1618)
RSRQ (dB): -13 Cell ID: 01E5110D (31789325)
SINR (dB): 0.2
OK
We are discussing about using EARFCN 2950 as it is close from our target EARFCN 3000. Just wonder what is wrong with those problematic EARFCN.