BG95-M3 firmware BG95M3LAR02A03_01.016.00.000 suitability for Europe and CSQ 99,99 / NOSERVICE issue

ert · June 19, 2026, 12:24pm

Hello Quectel team,

We are using a Quectel BG95-M3 module on our custom STM32H573 board.

The firmware version read from the module is:

BG95M3LAR02A03_01.016.00.000

Module information:

ATI response:
Quectel
BG95-M3
Revision: BG95M3LAR02A03

AT+QGMR response:
BG95M3LAR02A03_01.016.00.000

Target region:
Europe

Current issue:
The module boots correctly and UART communication works, but the module cannot register to the network.

The most important symptom is that signal quality is always reported as unknown / not detectable:

AT+CSQ
+CSQ: 99,99
OK

AT+QCSQ
+QCSQ: “NOSERVICE”
OK

AT+CEREG?
+CEREG: 0,2 or +CEREG: 0,4
OK

So the module appears to be searching for the network, but it cannot detect service or measure signal quality.

Relevant logs:

AT+CFUN?
+CFUN: 1
OK

AT+CSQ
+CSQ: 99,99
OK

AT+QCSQ
+QCSQ: “NOSERVICE”
OK

AT+CEREG?
+CEREG: 0,2 or +CEREG: 0,4
OK

Current configuration:

AT+QCFG=“nwscanmode”
+QCFG: “nwscanmode”,0

AT+QCFG=“nwscanseq”
+QCFG: “nwscanseq”,020301

AT+QCFG=“iotopmode”
+QCFG: “iotopmode”,2

We also observed that the same setup appears to register on a Quectel BG95 evaluation module, but on our custom board the NET_STATUS LED pattern is different. On the evaluation module the LED is long ON / short OFF, while on our custom board it is long OFF / short ON.

Because of the persistent CSQ 99,99 and QCSQ NOSERVICE results, we are also checking the RF path, antenna connection, MAIN antenna routing, RF matching, VBAT stability during network search, and NET_STATUS polarity on our custom board.

Questions:

Is firmware version BG95M3LAR02A03_01.016.00.000 suitable for operation in Europe?
Is this firmware still recommended for BG95-M3, or should we upgrade to a newer firmware branch?
Is this firmware compliant with current EU requirements, including RED / RED DA requirements if applicable?
What is the latest recommended BG95-M3 firmware version for Europe?
Could the current iotopmode=2 setting cause the module to search only NB-IoT and fail to register if the operator requires LTE-M or another RAT?
Can iotopmode=2 or band/scan configuration cause AT+CSQ to stay at 99,99 and AT+QCSQ to report NOSERVICE?
What QCFG settings do you recommend for automatic network search in Europe for BG95-M3?
Should we set the following for initial testing?

AT+CFUN=0
AT+QCFG=“nwscanmode”,0
AT+QCFG=“nwscanseq”,020301
AT+QCFG=“iotopmode”,0
AT+QCFG=“band”,0,0,0
AT+CFUN=1,1

For diagnosis, should we run AT+COPS=? with a long timeout, for example 300 seconds, to confirm whether the module can see any operators?
If AT+COPS=? returns no operators and AT+CSQ remains 99,99, would you recommend prioritizing RF path / antenna / hardware checks, or could firmware/configuration still cause this behavior?
Are there any known issues with BG95M3LAR02A03_01.016.00.000 related to network registration, CSQ 99,99, NB-IoT/LTE-M scanning, or European operator compatibility?

Could you please confirm whether our firmware version is suitable, and if not, provide the recommended firmware package, release notes, and upgrade procedure?

Thank you.

Linkin-Q · June 24, 2026, 3:17am

Hi @ert

[Q1]
Are you sure that version is BG95M3LAR02A03_01.016.00.000? We have never published this version.

[Q2]

Where did you get this version, i think you need upgrade to a newer firmware

[Q3]

No, Current version not including RED/DA ceritification.

[Q4]

I will send you latest version which including RED/DA, please try to upgrade to this latest version.

[Q5]

iotopmode=2 means both eMTC & NBIOT. So, module will try both on LTE-M1 and NB network.

[Q6]

No, i think should be other reasons casue this issue.

[Q7]

If there is LTE-M1 network only, i suggest to use: AT+QCFG=”ioopmode”,0, AT+QCFG=”nwscanmode”,3,AT+QCFG=“nwscanseq”,020301

[Q8]

Please refer to [Q7].

[Q9]

Yes, you can set AT+COPS=? to check available network around device.

[Q10]

If AT+COPS=? returns no operators, probably there is no available network in this area, you can change to another area to test or using other board to do a comprasion test.

[Q11]

No, network registration is a general function. it should be working on each version.

ert · June 24, 2026, 9:29am

Hi,

Thank you for your detailed answers.

Please find our replies below.

[Q1] Firmware version

We observed the following locally:

Module: BG95-M3
ATI revision: BG95M3LAR02A03
AT+QGMR was observed as:
- BG95M3LAR02A03_01.016.00.000
- BG95M3LAR02A03_01.016.01.016 after wake/settling

We understand from your reply that BG95M3LAR02A03_01.016.00.000 was not a published version. This is exactly what our module returned during testing, so we suspect the module may have an old, factory, or intermediate firmware.

[Q2] Firmware source / upgrade

The modules were obtained as samples from your local distributor, EMPA. We do not know the original firmware source or whether it was a production, factory, or intermediate release.

Please send us the latest firmware package for BG95-M3 and the recommended upgrade procedure/tool.

[Q3] RED/DA certification

Understood. We note that the current firmware does not include RED/DA certification.

[Q4] Latest RED/DA firmware

Thank you. Please send the latest BG95-M3 firmware version including RED/DA certification, together with release notes and upgrade instructions.

[Q5] iotopmode=2

Understood. iotopmode=2 means both eMTC and NB-IoT are enabled, so the module will try both LTE-M1 and NB-IoT networks.

For the next test, we will avoid mixed mode unless needed.

[Q6] Network issue cause

Understood. We agree that the issue may have another cause.

For reference, our current status is:

FWID diagnostic: PASS
AT stability: PASS
SIM status: CPIN READY
RF disable: airplanecontrol is disabled
Board RF path check:
- CELL_ANT pad to GND is open circuit with BG95 removed
- CELL_ANT pad to GSM U.FL center is approximately 0.5 ohm
- So the board RF path does not appear to be shorted or open

We also found one hardware/control-line issue on our side: the BG95 PWRKEY pin is being pulled low during normal operation by the STM32/control circuit. We are correcting this so that PWRKEY is released/inactive during normal operation and only pulsed intentionally when required.

[Q7] LTE-M1 recommended settings

Understood. We will test with your recommended LTE-M1 settings:

AT+QCFG=“iotopmode”,0
AT+QCFG=“nwscanmode”,3
AT+QCFG=“nwscanseq”,020301

Please confirm that iotopmode is the correct command name, because Q7 seems to contain a small typo as ioopmode.

[Q8] LTE-M1 settings

Understood. We will refer to Q7 for the LTE-M1 test profile.

[Q9] AT+COPS=? scan

Understood. We will run:

AT+COPS=?

with a long timeout and log the full result.

[Q10] No operators found

Understood. If AT+COPS=? returns no operators, we will test in another location and also compare with another board if available.

[Q11] Network registration and firmware version

Understood. We note that network registration is a general function and should work on each version.

However, since our module reports a firmware version that you mentioned was never published, and since the current firmware does not include RED/DA certification, we would still like to upgrade to the latest official RED/DA firmware before making the final conclusion.

Current GSM-only test result for reference:

+CREG: 0,4
+CSQ: 99,99
+COPS: 0
+QNWINFO: No Service
+QENG: “servingcell”,“SEARCH”

After fixing PWRKEY handling and upgrading the firmware, we will test:

Your recommended LTE-M1 configuration
AT+COPS=? scan
Another location if no operators are found
Comparison with another board if needed

Please send the latest BG95-M3 RED/DA firmware package, release notes, and the recommended firmware upgrade steps.

Best regards,
Burcak

Linkin-Q · June 26, 2026, 1:33am

Hi @ert

I will send you latest version via email which including RED/DA. please try with this latest version.

Q7] LTE-M1 recommended settings

Yes, should be AT+QCFG="iotopmode",0