MC7455: !SELRAT: Unknown RAT mode

IoT Modules MC/EM Series
1

Hello,

As part of a solution to a different problem, we are trying to use at!selrat=1 to lock a MC7455 on an AT&T network to UMTS mode.

The modem is on an AT&T-certified image running SWI9X30C_02.24.05.06.

The above selrat command does not work however (it always uses LTE), and at!selrat? results in:

!SELRAT: Unknown RAT mode. Use AT!SELRAT to set band.
00000027
00000000

We get “Unknown RAT mode” whatever selrat value we use. We tried doing an at!rmareset=1, after which selrat is correctly reported as " 00-Automatic", but it also resets the PRI, which in turn causes a different FW-version to load. As soon as we load our preferred image again, we again get “Unknown RAT mode”, without having changed selrat at all (this happens even if we force-download the fw-image).

We tried this on a different instance of the same hardware, and there everything is working as expected without any problems. Hence our best guess at the moment is a corruption of the filesystem or settings storage.

We would like to ask for assistance what could be the problem, and how to recover this unit from its corrupted state. Note we can only use QMI and AT commands, as the unit is located in an embedded device at a far-away remote location (different continent).

Thank you,
Karoly

2

Hi Károly,

at!band is the preferred way to lock the modem to a certain technology:

at!band=?
Index, Name
00, All bands
01, Europe 3G
02, North America 3G
06, Europe
07, North America
08, WCDMA ALL
09, LTE ALL

OK

Thanks,
James

3

Hi James!

Thank you for your input. The reason we used at!selrat is because it’s what was recommended to us in the linked thread by a Sierra Wireless FAE. Note too at!selrat works as advertised/expected when tried on a different unit. The question in this thread relates not to how to lock the modem to 3G, but how to recover it from this (possibly damaged?) setting on a specific unit.

Nevertheless, we can try at!band too, but it would still leave the question if this unit is in any kind of damaged software state, and if it is, what other consequences it might have in the future. So we’d rather vote for recovering it rather than ignoring the problem and using a different setting. All I want to say is, even if at!band is recommended over at!selrat (though it seems at this point expert opinions differ on this matter), it’d be best to resolve any errors in this unit, which at the moment pertains to at!selrat.

1 Like
4

Hi Károly,

I understand your concern.
!selrat is OK too, but it sets different bitmasks, kinda lower layer.
You will get “unknown RAT” If the current RAT configuration doesn’t match one of the defined sets. Basically the AT command is failing to show the bitmask.
For example:
at!selrat=?
!SELRAT: Index, Name
00, Automatic
01, UMTS 3G Only
02, Not Supported
03, Not Supported
04, Not Supported
05, Not Supported
06, LTE Only
07, Not Supported
08, Not Supported

Just an example 08 has CDMA but this modem doesn’t support CDMA so the AT will return “unknown RAT”
Even though the bitmask sets CDMA the modem will ignore it.

We used to use !selrat to lock the modem to 3GPP2 (CDMA).
For 3GPP the preferred way is !BAND.
If the modem is operational and at!band is showing the correct bitmasks I wouldn’t worry.

Can you please provide
Ati
at!impref?
at!image?
at!priid?
at!selrat?
at!selrat=?
at!band?
at!band=?
at!entercnd=“A710”
at!band=? (issue this again)

“but it also resets the PRI, which in turn causes a different FW-version to load. As soon as we load our preferred image again”
Which PRI is loaded before the switch?
And what is your preferred PRI?
At!priid?

Thanks,
James

5

Hi James,

You will get “unknown RAT” If the current RAT configuration doesn’t match one of the defined sets. … Just an example 08 has CDMA but this modem doesn’t support CDMA so the AT will return “unknown RAT”
Even though the bitmask sets CDMA the modem will ignore it.

That’s the strange thing. As you’ll see below in the at!selrat=? output, the modem reports that it supports both 0 (auto) and 1 (3G only) for selrat, and those are the only values we’ve used, yet we still receive the error when we request its current value. Even if we set it again using at!selrat=0 (which is also the factory default), we still get the error after that. And also, these values work just fine without error on a different unit of MC7455, the only difference being the provider net and the modem image (to account for the different provider).

Which PRI is loaded before the switch?
And what is your preferred PRI?

Before the switch we have firmware 02.24.05.06 and PRI ATT_002.027_000. This is our preferred image. After the rmareset it goes back to PRI 02.20.03.00_GENERIC (because ATT_002.027_000 vanishes), which in turn is linked to firmware 02.20.03.00 in another slot and causes that to load. At this point (after rmareset) selrat? shows a correct value of 0, but either of issuing selrat=1 or just switching back to our preferred image (even if we don’t touch selrat) causes selrat? to be reported as unknown again.

Can you please provide

Here are the outputs (with our preferred image loaded):

> ati
Manufacturer: Sierra Wireless, Incorporated
Model: MC7455
Revision: SWI9X30C_02.24.05.06 r7040 CARMD-EV-FRMWR2 2017/05/19 06:23:09
MEID: 35907206141801
IMEI: 359072061418014
IMEI SV: 12
FSN: LQ738185880410
+GCAP: +CGSM

OK

> at!impref?
!IMPREF:
preferred fw version: 02.24.05.06
preferred carrier name: ATT
preferred config name: ATT_002.027_000
current fw version: 02.24.05.06
current carrier name: ATT
current config name: ATT_002.027_000

OK

> at!image?
TYPE SLOT STATUS LRU FAILURES UNIQUE_ID BUILD_ID
FW 1 GOOD 128 0 0 ?? 02.20.03.00?
FW 2 GOOD 1 0 0 ?? 02.20.03.22?
FW 3 EMPTY 0 0 0
FW 4 GOOD 129 0 0 ?? 02.24.05.06?
Max FW images: 4
Active FW image is at slot 4

TYPE SLOT STATUS LRU FAILURES UNIQUE_ID BUILD_ID
PRI FF GOOD 0 0 0 002.027_000 02.24.05.06_ATT
PRI FF GOOD 0 0 0 002.017_000 02.20.03.00_GENERIC
PRI FF GOOD 0 0 0 002.020_000 02.20.03.22_SPRINT
PRI FF GOOD 0 0 0 001.000_000 00.00.00.00_OEMPRI918
PRI FF GOOD 0 0 0 002.026_001 02.20.03.22_VERIZON
Max PRI images: 50

OK

> at!priid?
PRI Part Number: 9906491
Revision: 001.002
Customer: Generic-M2M

Carrier PRI: 9999999_9904594_SWI9X30C_02.24.05.06_00_ATT_002.027_000

OK

> at!selrat?
!SELRAT: Unknown RAT mode. Use AT!SELRAT to set band.
00000027
00000000

OK

> at!selrat=?
!SELRAT: Index, Name
00, Automatic
01, UMTS 3G Only
02, Not Supported
03, Not Supported
04, Not Supported
05, Not Supported
06, LTE Only
07, Not Supported
08, Not Supported
09, Not Supported
0A, Not Supported
0B, Not Supported
0C, Not Supported
0D, Not Supported
0E, Not Supported
0F, Not Supported
10, Not Supported
11, UMTS and LTE Only
12, Not Supported
13, Not Supported
14, Not Supported

OK

> at!band?
Index, Name
00, All bands

OK

> at!band=?
Index, Name
00, All bands
01, Europe 3G
02, North America 3G
06, Europe
07, North America
08, WCDMA ALL
09, LTE ALL

OK

> at!entercnd=“A710”
> at!band=?
Index, Name, GW Band Mask L Band Mask TDS Band Mask
00, All bands 0002000007C00000 00000100330818DF 0000000000000000
01, Europe 3G 0002000000400000 0000000000000000 0000000000000000
02, North America 3G 0000000004800000 0000000000000000 0000000000000000
06, Europe 0002000000400000 00000000000800C5 0000000000000000
07, North America 0000000004800000 000000000300185A 0000000000000000
08, WCDMA ALL 0002000007C00000 0000000000000000 0000000000000000
09, LTE ALL 0000000000000000 00000100330818DF 0000000000000000

                                               0000010000000000 - B41
                                               0000000020000000 - B30
                                               0000000010000000 - B29
                                               0000000002000000 - B26
                                               0000000001000000 - B25
                                               0000000000080000 - B20
                                               0000000000001000 - B13
                                               0000000000000800 - B12
                                               0000000000000080 - B8
                                               0000000000000040 - B7
                                               0000000000000010 - B5
                                               0000000000000008 - B4
                                               0000000000000004 - B3
                                               0000000000000002 - B2
                                               0000000000000001 - B1
                              0002000000000000 - B8  (900)
                              0000000004000000 - B5  (850)
                              0000000002000000 - B4 (1700)
                              0000000001000000 - B3 (1700)
                              0000000000800000 - B2 (1900)
                              0000000000400000 - B1 (2100)

OK

Thank you very much for your help.

6

Hi Károly,

Thanks for providing the info.

Your configuration is good. The modem is not using the unknown settings, you should be OK.
I wish I could tell you why the SELRAT bitmask is wrong.
I tried to replicate the issue on my modem unsuccessfully. I guess I know why we don’t document !selrat in the AT guide.
I’d try to reload a previous ATT FW and upgrade it again, this might resolve the issue because the carrier PRI reprograms the bitmask. I’m not sure it would change !SELRAT though because as I mentioned before SELRAT has its own bitmask.

Thanks,

James

7

Hi James!

I am not very surprised that you cannot reproduce it. As I said we are only experiencing this issue on a single hardware instance, so we suspect there must be some software damage to this module. Also as mentioned earlier, we are seeing the same problem with a different PRI (earlier version GENERIC), so switching PRI doesn’t solve our issue.

Right now the modem seems to ignore the corrupt SELRAT bitmask. As a workaround we can try AT!BAND. But best would be if we could reinitialize the modem somehow, a way to reformat it or something. Something similar to RMARESET=1, but I guess RMARESET doesn’t reformat its filesystem, it just copies default files over from a secured placed. But this doesn’t help if the settings storage is corrupted. Is this plausible, or is it a completely wrong guess?

8

I’d try to roll back to a previous ATT image and upgrade it to 02.24.05.06 to fix the selrat issue.
Apart from the selrat issue do you see any other problem?
Definitely use at!band.

9

Ok, I will try what you said. Can you give us a link to an older ATT image? Your FW page here only lists the latest version.

10

Hi James,

We tried the alternative firmware that you sent us, unfortunately it did not help in repairing at!selrat.

Now we are back to our preferred modem image again, and we have some positive initial results regarding to at!band. We could use it successfully in a quick test to lock the modem to 3G. We are continuing evaluation for a few more days (we already rolled it out to our problematic unit), and with a bit of luck, this will resolve our other issue too.

Thank you,
Karoly

11

at!selrat continues to be defective on this modem instance, but using at!band instead we could achieve the same effect and so we solved our problem.