RM520N-GL firmware issues (bugs) in latest release

IoT Modules 5G Module
1

Hello, I hope I am posting this information in the correct place to be viewed by the devs of this module so they can investigate and issue a fix (updated firmware) as soon as possible.

These issues below relate to firmware version RM520NGLAAR01A08M4G_01.200.01.200

  • When connected via 5G NSA, incorrectly reports 5G band n78 at 80Mhz (SCC) when it should be at 100Mhz.

  • When connected via 5G NSA, the module can loose 5G band n28 (and maybe others) in some situations. It will not reconnect to the band unless a power cycle occurs. More information on this below.

In my situation we have 5G NSA coverage in our area. This is controlled by 4G LTE band B1 which gives access to 5G bands n28/10Mhz and n78/100Mhz. When the first SCC band is n28 and n78 the second, everything appears to function correctly. However, due to weather conditions and our location it can be that the module prefers n78 as the primary SCC band, When this happens n28 no longer connects and will not connect as the 2nd SCC band. Once this happens the module remains in this configuration, even when the weather would put n28 as the preferred band again. A power cycle has to happen to resolve this so both bands may be usable as SCC bands at the same time.

More information on testing I tried when this issue has manifested.
AT+QNWPREFCFG=“nsa_nr5g_band”,1:28 allows a connection to SCC n28 only, AT+QNWPREFCFG=“nsa_nr5g_band”,1:78 allows connection to SCC n78 only. AT+QNWPREFCFG=“nsa_nr5g_band”,1:28:78 only allows SCC n78 to connect.
After a power cycle AT+QNWPREFCFG=“nsa_nr5g_band”,1:28:78 connect both SCC n28 / n78 together.

I hope my explanation makes sense.

2

Want to mention another issue with this firmware.

When connected via 5G NSA, The operator name is reported twice. For example;

AT+COPS?
+COPS: 1,1,“elisa elisa”,13
OK

elisa should only be named once and not twice.

3

Dear @Montey
As you mentioned, due to weather condition, is there n28 cell during this situation? Or the signal of n28 is poor, it can’t connect.
And after power cycle, module will trigger to search network again.

For your issue, it is better to provide log to us. Which OS did you use?

4

Hi @silvia

Yes,when this situation happens the n28 cell is still available as the 4 AT+QNWPREFCFG commands show . it appears from my understanding that the module will not use n28 after a condition where n78 becomes the primary NSA band.

It is not a case of the issue happening when the weather gets worse, its more the opposite. When the temperature drops under about -6, reception of n78 becomes better.

The issue being n28+n78 provides far better bandwidth throughput than n78 only or n28 only, and the bug I see being n78+n28 never connecting together in this order.

What might be helpful is if there’s an AT command available for the RM520N-GL that allows forcing (or locking) the preferred and secondary 5G SCC bands when in NSA mode. Is there one that is not documented in the last command document, the one I have is dated July 2023?

When the situation happens again, I will get a log for you.

5

Hi @silvia

The issue I had with bands n28 dropping has happened again when using firmware RM520NGLAAR01A08M4G_01.200.01.200. In my hunt for information trying to resolve this issue I came across a newer firmware online RM520NGLAAR03A03M4G_01.200.01.200 and I thought I would give it a test before providing the log information you requested.

With firmware RM520NGLAAR03A03M4G_01.200.01.200 the issue with n28 disappearing is resolved and the module now appears to correctly connect to n28+n78 or n78+n28 depending on which is the preferred network when using NSA. To confirm this, I also flashed back to the old firmware to confirm the issue presented itself again, and finally again to this new version to confirm its resolved.

The other two issues I reported are also resolved, The incorrect bandwidth is resolved and is also mentioned in the release notes and the service provider name being shown twice is also resolved.

One new issue with RM520NGLAAR03A03M4G_01.200.01.200 presents itself however, very often SINR values are returned as invalid / -32768. For example;

AT+QENG=“servingcell”

+QENG: “servingcell”,“NOCONN”
+QENG: “LTE”,“FDD”,244,05,52408,93,100,1,5,5,5974,-100,-6,-71,-32768,12,0,-
+QENG: “NR5G-NSA”,244,05,989,-122,1,-18,641280,78,12,1

OK

or

AT+QSINR

+QSINR: 18,18,-32768,-32768,LTE
+QSINR: -32768,1,-4,-3,NR5G

OK

Silvia, is there a newer firmware you can provide that resolves this SINR issue or does this point to a issue with the module? SINR was reported correctly with the earlier FW revision.

6

Dear @Montey
Currently, RM520NGLAAR03A03M4G_01.200.01.200 is the latest on in R03 baseline.