Quectel BG95-M3

Modem multi-mode LTE Cat-M1 + NB-IoT (Cat NB2) + EGPRS 2G. Punto di riferimento per asset tracker IoT a basso consumo: PSM nativo, eDRX, anti-jamming integrato. Usato in iStartek PT60L-MN95-LTEM (analizzato da Visla R&D).

📋 Specs tecniche (confermate da bench Visla)

🔥 Configurazione critica AT+QCFG="iotopmode"

⚠️ Importante: iotopmode è PERSISTENTE in NVRAM modem. Una volta scritto, sopravvive a reboot. iStartek lo imposta a 1 in factory e non lo espone al cliente nel Parameter Editor.

🏆 Banco Visla (16/07/2026) — modulo vivo, bring-up riuscito

Core board PH-7 (C4-P02) — la stessa che ospita l’EG915U-EU: “scheda core QuecPython BG&EG, applicabile all’intera serie BG95, EG915UEUAB, EG912UGLAA”. Alimentata a 5V su VIN (pin 35) dal DPS-150.

ATI       →  Quectel · BG95-M3 · Revision: BG95M3LAR02A03
AT+QGMR   →  BG95M3LAR02A03_01.014.00.000
AT+CGSN   →  869616065911912
AT+CFUN?  →  +CFUN: 1

✅ Esito finale: registrato in LTE Cat-M su Vodafone IT (dettagli sotto) — dopo aver rimosso il jumper PWK_ON, che causava un boot loop da 3 s.

📊 Consumi misurati (DPS-150 su BAT a 3.8V)

⭐ PSM LTE-M misurato (bench 22/07/2026) — su Vodafone LTE-M: AT+CPSMS=1,,,"00100001","00000001" → la rete concede Active-Time = 2s (CEREG=4 → ...,"00000001","00000110", Periodic-TAU 60min; QPSMS? conferma). La corrente da 17 mA idle crolla a 0.0 A (deep PSM) in ~30s → più profondo E più rapido del Cat-1 bis EG800Q (che restava ~1 mA, Active-Time 16s-2min). È qui l’autonomia vera dell’LTE-M. Wake dal PSM: impulso PWRKEY via RTS (la UART dorme in PSM).

⚠️ Sweep operatori LTE-M (1NCE, 22/07): in Italia LTE-M = solo Vodafone. Forzando AT+COPS=1,2,"<PLMN>",8: Vodafone 22210 ✅ (unico che aggancia LTE-M); WindTre 22288 / TIM 22201 / Iliad 22250 ❌ (falliscono la selezione LTE-M → ripiegano/ricerca). Contrasto col Cat-1 bis, dove la stessa 1NCE raggiungeva WindTre + Vodafone. → Trade-off misurato: LTE-M = PSM più profondo ma ti lega a Vodafone; Cat-1 bis = PSM a µA (su Qualcomm) con più operatori + 4G universale.

🔧 Gotcha RTS→PWK: con la RTS cablata a PWK, ogni apertura della seriale resetta il modulo (auto-reset tipo Arduino). Per uno sweep tenere UNA sola sessione seriale aperta (script test-moduli/quectel-usb-at/bg95_ltem_sweep.py), non aprire/chiudere per comando.

AT+QGPSLOC=2 → +CME ERROR: 516 = “not fixed now” → manca l’antenna GNSS sul connettore dedicato.

⭐ Il set di feature reale (interrogato al modulo, non dal datasheet)

Metodo: CME 58 = comando inesistente · CME 4 = esiste ma altra sintassi (lezione A7672E/EG915U).

⚠️ Il connettore BT/WiFi sulla PH-7 NON prova la feature: la carrier è generica (serve anche EG915U/EG912U). Stessa lezione dell’A7672E. Sul BG95 quel connettore è morto.

🔥 Tutto lo stack Visla in un chip — e con QuecOpen

Dalla pagina prodotto Quectel: “ARM Cortex A7 processor supporting ThreadX” · “Support VoLTE, QuecOpen®, eSIM” · “up to 70% reduction in PSM leakage and 85% reduction in eDRX current vs predecessor”.

GNSS + MQTT nativo + SSL + PSM + eDRX + Jamming + QuecOpen = il tracker Visla completo, single-chip. Da confrontare col SIM7080G (Tag attuale), dove MQTT nativo NON funziona (SMCONN: operation not allowed → obbligatorio TinyGSM+PubSubClient, [[feedback_sim7080_mqtt_tinygsm_not_native]]). Qui AT+QMTOPEN c’è.

⭐ I due dati che contano per il Visla Tag

Il PSM risponde — è la discriminante per un tag a batteria, e l’EG915U non ce l’ha. Confronto diretto col SIM7080G, l’attuale scelta del Tag.

🔌 Accensione: PWRKEY via RTS del Waveshare (niente pulsanti)

L’USB-C non basta: la board va alimentata su VIN e il modulo non parte da solo. La guida ufficiale dice “Press PWK to power on (unless PWK_ON is shorted)” — ma il PWK è anche il pin 26 (PWR) dell’header, quindi si pilota da software:

Waveshare RTS → pin 26 (PWR) · sequenza: idle pin BASSO → impulso ALTO 1.5 s → ritorno BASSO → RDY + APP RDY

⚠️ La board INVERTE il PWRKEY: sul modulo il PWRKEY è attivo basso, ma sull’header serve un impulso alto (c’è un transistor in mezzo). Stesso trucco del SIM7080G ([[feedback_sim7080g_pwrkey_via_rts]]).

p = serial.Serial("/dev/cu.usbserial-XXXX", 115200, timeout=0.3)
p.setRTS(True);  time.sleep(0.5)     # idle: pin BASSO
p.setRTS(False); time.sleep(1.5)     # impulso PWRKEY: pin ALTO
p.setRTS(True)                       # rilascio  → RDY

Script pronto: test-moduli/quectel-usb-at/bgat.py.

🚨 LEVEL_LINE: senza questo l’header è muto

La PH-7 ha un traslatore di livello con riferimento esterno: serigrafia 2V3~5V5 / Level_Line sul bordo. I moduli sotto hanno IO a 1.8V; sei tu a decidere il livello dell’header.

3.3V del Waveshare → pin 24 (LEVEL_LINE) — senza, i pin UART non trasmettono nulla e sembra un guasto. C’è anche LT_EN (pin 10, serigrafia “High Level EN”).

Questo spiega il silenzio totale iniziale, scambiato per cablaggio sbagliato.

Cablaggio Waveshare → PH-7 (verificato)

☠️ Esemplare BRUCIATO al banco (16/07/2026) — errore di procedura

Bruciato il regolatore VIN della board (il modulo BG95 è sopravvissuto: vedi sotto). Causa: VIN portato da 5V a 9V in un colpo solo, con limite di corrente a 2A, su un collegamento non verificato col multimetro.

prima:  5V → 7-58 mA, enumera come 2c7c:0700, risponde in AT
comando: set 9V / 2A
dopo:   1.732 V @ 2.024 A  → in limite = CORTO
        e a 5V/300mA: 1.114 V @ 300 mA → corto persistente
        nessuna enumerazione USB via VIN

La serigrafia dichiara VIN 5V~16V, quindi 9V sembrava dentro specifica. Ma la serigrafia era letta da una foto e VDD (pin 27) è un’uscita a bassa tensione, a pochi mm da VIN (pin 35) su un header 2.54mm: a 5V un pin sbagliato sopravvive sembrando quasi normale (e può causare il boot loop che si sta indagando), a 9V muore all’istante.

🚨 REGOLA: prima di alzare la tensione → limite di corrente basso (200-300 mA), salita a gradini (sweep del DPS-150), verifica del pin col multimetro. E non riaprire un’ipotesi già smentita senza un fatto nuovo: era già stato stabilito che il boot loop c’era sia su USB sia su VIN → non era alimentazione. ([[feedback_never_raise_voltage_without_sweep]])

✅ Recuperato: alimentare da BAT (pin 38) a 3.8V

Il BG95 è sopravvissuto — a morire è stato solo il regolatore onboard VIN→VBAT. Alimentando su BAT (pin 38) + GND (pin 37) a 3.8V si scavalca lo stadio guasto e il modulo funziona al 100%: risponde a tutto e si registra in Cat-M (tutti i dati di rete sotto sono stati presi così, dopo il guasto).

3.800 V   69.9 mA   ✅ tensione regge, nessun corto
3.750 V   72.0 mA   ✅

⚠️ BAT = 3.3–4.3V (typ 3.8) — mai 5V. Staccare l’USB-C (la ricarica è attiva di default e combatte contro l’alimentatore) e il filo da VIN.

💡 Se un rail muore, provare a bypassarlo: su queste board VIN passa per un regolatore, BAT no. Un guasto al regolatore non implica un modulo morto.

🎯 RISOLTO: il boot loop era il jumper PWK_ON (cappuccio giallo)

Il modulo si riavviava ogni ~3 s (su USB, su VIN, su BAT — indifferente a tutto). Colpevole: il jumper giallo montato di fabbrica sui pad PWK_ON (zona EG | BG, accanto a GND PWK VDD).

Doc ufficiale: “Press PWK to power on unless PWK_ON is shorted; the board will power on automatically.” → PWK_ON chiuso = PWRKEY tenuto premuto in permanenza.

⭐ Il BG95 interpreta il PWRKEY tenuto giù come “spegniti”: la stessa board si comporta in modo opposto con le due famiglie. → Con un BG95: TOGLIERE il jumper PWK_ON e accendere con l’impulso RTS.

Conseguenza a valle: col loop attivo AT+QCSQ dava "NOSERVICE" e CSQ 99,99 — non era l’antenna: un Cat-M/NB-IoT impiega decine di secondi/minuti a scandire e registrarsi, e riavviandosi ogni 3 s non completava mai la scansione. Tolto il jumper, si registra in 15 secondi.

🔬 Come è stato provato che erano reboot veri (e non URC spurie): ATE0 spegne l’echo ed è volatile (solo RAM). Dopo ogni RDY l’echo tornava acceso da solo → solo un riavvio può farlo. Il primo tentativo di verifica era circolare (contare RDY per dimostrare che le RDY erano reboot): serve una prova indipendente.

🏆 REGISTRATO in LTE Cat-M — Vodafone IT (16/07/2026)

AT+COPS?    →  +COPS: 0,0,"vodafone IT",8        ← 8 = eMTC (LTE Cat-M)
AT+QNWINFO  →  +QNWINFO: "eMTC","22210","LTE BAND 3",1850
AT+QCSQ     →  +QCSQ: "eMTC",-94,-116,146,-10    ← RSSI −94 · RSRP −116 · SINR −10
AT+CEREG?   →  +CEREG: 0,5                       ← registrato (roaming)
AT+CGATT?   →  +CGATT: 1                         ← attached
AT+CPIN?    →  READY · IMSI 901405122512160 · ICCID 89882280666225121601 (1NCE)

⭐ Cat-M funziona in Italia su Vodafone (banda 3) con SIM 1NCE in roaming — conferma indipendente di [[project_lilygo_nbiot_field_findings]] (“LTE-M Orvieto c’è; NB-IoT TCP fantasma”), stavolta su hardware Quectel.

USB: si presenta come 2c7c:0700 — Quectel, Incorporated / Quectel LPWA Module (nome reale, ≠ l’EG915U che dichiara “Android”).

🧪 Note dal bench Visla

• ✅ Anti-jamming nativo via AT+QJDR=1 + URC +QJDR: JAMMED / NO JAMMING — genera Event Code 50/51 per iStartek
• ✅ AT+QGMR restituisce firmware version (es. BG95M3LAR02A03_01.200.00.000 visto su PT60L)
• ✅ Boot time: ~6 secondi da power-on a +CPIN: READY
• ✅ PSM real-world: testato in Italia su SIM 1NCE (Voda Italy NB-IoT B20) — funziona con AT+CPSMS=1,,,"<TAU>","<Active>"
• ⚠️ Cat-M1 in Italia: deployment limitato. Voda IT NB-IoT B20 ovunque; Cat-M1 solo zone urbane principali → preferire iotopmode=1 (NB-IoT only) o iotopmode=3 (NB-IoT preferred) per Italia
• ⚠️ MT-SMS richiede attach completo MM. In LIMSRV (limited service) SMS in entrata NON consegnati
• ✅ GNSS integrato (correzione 24/06/2026): il BG95-M3 HA il GNSS onboard (GPS+GLONASS+BeiDou+Galileo+QZSS, max 2 costellazioni simultanee) — comandi AT+QGPS=1 per attivare, NMEA dal modem. ⚠️ Per Visla resta valida la regola del GPS dedicato (memoria: il GNSS del modem subisce de-sense durante la TX LTE → fix peggiore vs chip GPS+antenna separati)

⌨️ AT command utili

⚠️ Gotchas

• ✅ Il BG95-M3 ha GNSS integrato (smentita nota precedente “no GNSS / serve M4” — era errata)
• BG95-M3 ≠ BG95-M1 (M1 ha solo NB-IoT, no Cat-M1)
• Variante regionale: BG95-M3 è multi-band globale. Per produzione EU verificare specifiche bande certificate
• Il GNSS integrato si attiva via AT+QGPS=1 e il modem restituisce direttamente NMEA (no chip GPS esterno necessario per il fix base) — ma de-sense in TX LTE → per qualità Visla usa GPS dedicato
• Anti-jamming +QJDR triggera solo per jamming RF cellulare; jamming GPS dedicato richiede chip GPS separato

🔗 Risorse

• Quectel BG95 series product page
• Quectel BG95-M3 datasheet V1.5 PDF (2024)
• Quectel BG95 AT commands manual
• 🔬 Usato in: iStartek PT60L-MN95-LTEM teardown Visla

🎯 Use case Visla

Candidate primario per Visla Tag Long-Life + Visla Asset Lite NB-IoT:

• Stesso form factor di BG77 (NB-IoT only) ma con Cat-M1 fallback per roaming USA
• Più completo di SIM7080G (no eDRX, no audio) → migliore per asset tracking premium
• Confronto vs SIM7080G:
  • BG95-M3 vince: certificazioni più estese (FCC + GCF + ANATEL), Qualcomm chipset, supporto Quectel maturo
  • SIM7080G vince: prezzo ~€1-2 meno, audio integrato, OpenSDK comunità più attiva