Waveshare SIM7080G Cat-M/NB-IoT HAT

Curiosity

Waveshare SIM7080G Cat-M/NB-IoT HAT ($32.99): breakout 30.5×65 mm formato HAT Raspberry Pi 40-pin per il chip SIMCom SIM7080G. NB-IoT + Cat-M + GNSS + GSM disabilitato (vs 7070G che ha GPRS). Onboard USB-C con bridge FT232R per testing AT senza RPi. Sul bench Visla bench-validated 2026-06-06 con SIM 1NCE su Vodafone IT roaming — entrambi NB-IoT e Cat-M registrano + HTTP GET ok. Da datasheet board level idle 39 mA, PSM module-only 3.2 µA (alta credibilità su chip + LDO MP1482 minimal). Path alternativo al LilyGO T-SIM7080G per chi vuole modem isolato dall’ESP32.

⚡ Bench 2026-06-20 — mappa comando→consumo pulita (senza RTS→PWRKEY)

Terza sessione, con lo script interattivo sim7080_bench.py che pilota in un colpo solo DPS-150 (alimenta+misura) e modem (UART). Scoperta chiave: il cablaggio RTS→PWRKEY usato nella sessione precedente era una trappola — l’RTS tenuto resettava il SIM7080 ogni ~18s (reboot loop) e gonfiava il floor. Staccato il filo, il modem si pilota a mano col PWRKEY e i numeri diventano puliti e stabili (monitor 0 reboot).

Mappa comando→consumo @ VBAT 3.8V (Cat-M, TIM via 1NCE; include ~2 mA di overhead HAT = LED + level shifter + USB-TTL):

PSM-observe 120s: floor stabile a 2.1 mA (tuffi a 2.1, picchi periodici a ~4.5 = finestre di paging/DRX). La PSM (2.1 mA) è più bassa di RF_OFF (3.5 mA) perché CFUN=0 tiene il core sveglio mentre la PSM addormenta l’intero modulo. Il chip nudo in PSM è ~3.2 µA da datasheet: i 2.1 mA residui sono l’overhead della HAT.

⚠️ Correzione vs sessione 2026-06-19: il “~9 mA stabile” misurato sotto era gonfiato dal reboot loop dell’RTS→PWRKEY. Senza quel filo, idle reale = 6.5 mA, PSM = 2.1 mA. NON cablare RTS→PWRKEY per svegliare via software: accendi/spegni il modem a mano (PWRKEY è un toggle) e disabilita lo sleep con CPSMS=0+CEDRXS=0+CSCLK=0 per i test attivi.

⚡ Bench 2026-06-19 — DPS-150 (VBAT diretto) + scoperta “firmware non hardware”

Seconda sessione: alimentazione e misura via DPS-150 sul pin VBAT a 3.8V diretto (bypassa il buck → vede il consumo del solo modem), UART via Waveshare USB-TTL sui pin, PWRKEY pilotato via RTS (setRTS = wake software). ⚠️ L’RTS→PWRKEY si è poi rivelato una trappola (reboot loop ogni ~18s che gonfia il floor) — vedi sessione 2026-06-20 sopra per i numeri corretti.

Risultato PSM/sleep su Cat-M (LTE-M, TIM B3, VBAT 3.8V): registrato Cat-M, poi la rete pusha eDRX/PSM → il modem dorme da solo → corrente ~9 mA (min 6.6 mA) per 165s — ⚠️ gonfiato dall’RTS (vero idle 6.5 mA / PSM 2.1 mA, vedi sopra). Conferma comunque che NB-IoT e Cat-M scendono entrambi nei mA bassi (vs Cat-1 A7670 che resta a 38 mA → vedi test consumi).

⚠️ SCOPERTA — “modem muto/garbage” = PSM, NON hardware rotto

Durante il bench ho erroneamente messo 5V sul pin VCC (è il logico 3.3V) e temevo di aver bruciato il translator. NON era così. Il modem appariva “muto/garbage” perché su Cat-M entra in PSM/eDRX entro pochi secondi e l’UART si addormenta — sembra rotto ma sta solo dormendo.

• Prova del firmware-non-hardware: con AT+CPSMS=0 + AT+CEDRXS=0 + wake via RTS→PWRKEY, il modem risponde su entrambi i path (40-pin e 8-pin del VCC incriminato) → il translator ha retto i 5V, nessun danno.
• Sintomo ingannevole: se il DPS è spento il modem non assorbe (0 mA) e l’UART dà solo rumore → sembra rotto. Sempre verificare prima che ci sia alimentazione, poi che non sia PSM.
• Per test attivi su Cat-M: disabilita PSM/eDRX subito dopo il boot (CPSMS=0+CEDRXS=0) o tieni un RTS→PWRKEY per risvegliarlo via software; altrimenti si riaddormenta tra un comando e l’altro (UART instabile 5/10).
• VCC va lasciato SCOLLEGATO (lo gestisce il jumper level). I 5V vanno solo su VBAT (3.4–4.2V) o sul pin 5V del 40-pin — mai su VCC.

🔌 Collegamento header 8-pin (per MCU esterno, es. XIAO)

La fila di 8 pin in alto è il modo comodo per collegare un MCU esterno (più semplice del 40-pin RPi). Ordine sulla board: VBAT · GND · VCC · GND · RXD · TXD · DTR · PWR.

📋 VBAT su header — le 3 HAT SimCom Waveshare a confronto (per misure a VBAT diretto, bypassando il buck onboard): A7670E ✅ pinheader VBAT dedicato · SIM7080G ✅ header 8-pin (VBAT·GND·VCC·GND·RXD·TXD·DTR·PWR) · SIM7070G ❌ solo header 6-pin (5V·GND·RXD·TXD·DTR·PWR), VBAT interno dal buck MP1482 non esposto (da schematico). A VBAT 3.7–4.2V misuri il solo modem; col 5V c’è la perdita del buck (~+65% a basso carico).

🚨 ALERT — leggere prima di cablare

• ❌ MAI 5V sul VBAT → va dritto al modem (max 4.2V) = lo bruci. Il VBAT vuole 3.4–4.2V (LiPo).
• ❌ MAI 5V sul VCC → è il logico 3.3V; 5V → la TXD del modem esce a 5V → frigge l’ingresso RX della XIAO (max 3.3V).
• ✅ I 5V vanno SOLO sul pin 5V del 40-pin (lì il buck li abbassa a 3.8V). Non c’è 5V sulla fila degli 8.
• ❌ NON alimentare dalla micro-USB del HAT mentre usi questo header → il FT232R litiga sulla TXD del modem → modem muto. Tienila staccata.
• ⚠️ GND sempre obbligatorio condiviso (UART senza massa comune = silenzio).
• ⚠️ PWRKEY è active-LOW: impulso a GND ~1s per accendere (non HIGH). Oppure jumper PWR su B (auto-on).
• ⚠️ Jumper level su 3.3V (mai 5V con MCU 3.3V). SIM 1.8V only (no SIM telefono).

Setup consigliato senza batteria (la più semplice): 🔴 5V dell’Expansion → pin 5V del 40-pin del HAT · ⚫ GND ↔ GND · 🟡 D6/TX → RXD · ⚪ D7/RX → TXD · micro-USB HAT staccata · jumper level 3.3V · poi impulso PWRKEY a GND (o jumper PWR=B) per accendere.

🎯 PSM deep test 2026-06-06 — chip CONFERMA +CPSMSTATUS: 1 ✅

Test con config proper per ENTER PSM:

• AT+CSCLK=1 → abilita slow clock per sleep
• AT+CNMI=0,0,0,0,0 → disattiva URC SMS
• AT+CMER=0,0,0,0,0 → disattiva indication events
• AT+CFUN=0/1 → reapply network mode
• AT+CPSMS=1,,,"00100001","00000000" → TAU 30s, Active 0
• AT+CGATT=0/1 → re-attach network per negotiate PSM
• 180s silence observe

Risultato fondamentale: AT+CPSMSTATUS? ha risposto +CPSMSTATUS: 1 = il chip è ENTRATO in PSM ufficiale ✅

PSM observe (180 secondi silence)

Cosa significa il min 10.9 mA

Il chip in PSM scende a 3 µA datasheet. I 10.9 mA che vedo sono:

• ~7-8 mA buck MP1482 quiescent + LDO + LED
• ~3 mA TTL FT232RNL idle
• = 10-11 mA irriducibili overhead board

Quando il chip è in PSM vero, risparmia ~14 mA rispetto al floor “idle registered” (33 mA → ~10 mA). Ma per scendere ai 3 µA chip-only servirebbe rimuovere LED + buck + LDO + bridge = sostituire il HAT con BK-SIM7080G core board.

Confronto: vecchio test (no CSCLK) vs nuovo (proper config)

→ La differenza è 3× riduzione del floor semplicemente abilitando CSCLK e silenziando URC.

Dati raw

• PNG: /shield/waveshare-sim7080g-psm-deep-2026-06-06.png
• CSV (8376 samples): /shield/waveshare-sim7080g-psm-deep-samples-2026-06-06.csv
• Script: test-moduli/waveshare-sim7080g-hat/visla-psm-deep-test.py

🔋 PSM + MQTT bench-test 2026-06-06 — VODAFONE IT CONCEDE PSM ✅

✅ Vodafone IT 1NCE concede PSM su Cat-M

Risposta della rete a AT+CPSMS=1,,,"00100001","00000000":

+CPSMS: 1,,,"00000110","00000000"

La rete ha negoziato e accettato PSM con:

• T3412 Extended (TAU) = 00000110 = 6 × 2s = 12 secondi (rete ha ridotto da 30s che ho chiesto)
• T3324 (Active timer) = 00000000 = 0 secondi (entra in PSM appena idle)

Questo è un risultato cruciale per Visla Tag: Vodafone IT concede PSM via Cat-M su SIM 1NCE → autonomia µA fattibile in produzione.

⚠️ Floor consumi 33 mA — NON sono i µA reali del chip

Durante PSM_OBSERVE (90s silence post-CPSMS) il FNB58 mostra:

• Floor minimo: 33.8 mA (board overhead)
• Avg: 72.54 mA (con spike RRC paging periodici)
• Spike max: 352 mA (negoziazione RRC durante PSM transitions)

Il chip SIM7080G probabilmente scende ai 3.2 µA datasheet, ma il floor del board (MP1482 buck + 3 LED + LDO + TTL FT232 overhead) maschera tutto. Per misurare davvero µA chip-only servirebbe:

• BK-SIM7080G core board (no LDO/LED)
• Modifica Waveshare HAT con dissaldatura LED + ponticello su VBAT pin
• Oppure misura direttamente con PPK2 a livello chip VBAT pin

❌ MQTT a test.mosquitto.org → AT+SMCONN ERROR

Tentato connessione MQTT plain port 1883:

AT+SMCONF="URL","test.mosquitto.org","1883"  → OK
AT+SMCONN                                     → ERROR

Cause possibili:

1. 1NCE blocca outbound 1883 plain (security policy, suggeriscono TLS 8883)
2. DNS resolution fallita (non ho configurato AT+CDNSCFG)
3. SMCONN timeout per latency NB-IoT (15s troppo poco)

Da debuggare: provare MQTT TLS su 8883, o broker più vicino (HiveMQ EU, broker self-hosted), o HTTP POST come fallback (validato sopra ✅).

Stats fasi PSM+MQTT test

Implicazioni per Visla Tag production

Dati raw

• PNG: /shield/waveshare-sim7080g-psm-mqtt-2026-06-06.png
• CSV (5432 samples @ 32Hz): /shield/waveshare-sim7080g-psm-samples-2026-06-06.csv
• Script template: test-moduli/waveshare-sim7080g-hat/visla-psm-mqtt-test.py

📊 Cycle test FNB58 2026-06-06 — 2 cicli Visla v2 production-like

Setup: FNB58 inline tra Mac e Waveshare USB-TTL (switch 5V) → HAT pin header (no USB-C HAT). PWR_KEY pilotato via RTS del FT232RNL = controllo completo software senza MCU esterno. SIM 1NCE su Vodafone IT Cat-M.

Fasi del ciclo (2× ripetuti)

Osservazioni chiave

1. TX peak Cat-M raggiunge 471 mA (cycle 1) e 540 mA (cycle 2) — è il burst di trasmissione 0.125W class 5 LTE su VBAT 3.8V
2. Floor idle ~34-40 mA = overhead board level (TTL FT232RNL ~15 mA + LDO MP1482 quiescent + 3 LED + bus VBAT translator)
3. PHASE_E (DEEPSLEEP) resta a ~74 mA ⚠️ — significa che AT+CPOWD=1 non basta per scendere a µA reali. Il MP1482 buck del HAT continua ad alimentare, e il chip in shutdown viene comunque tenuto in stato “wake-on-UART” da pull-up VBAT
4. Per veri µA serve AT+CPSMS=1 (PSM enable con timer TAU) prima dello shutdown, oppure rimozione fisica di power (impossibile via software qui)
5. Stesso ciclo replicato 2 volte mostra ripetibilità ottima (avg±5%)

Cycle averages

Su 2 cicli completi (~134s totale, 4304 sample @ 32Hz):

• Avg corrente totale: ~70 mA
• Energy per ciclo: 70 mA × 67s × 5.1V = ~6.7 mWh ≈ 1.31 mAh @ 5V (sul TTL+HAT)
• Equivalente chip-only: sottraendo ~15 mA overhead TTL → ~55 mA effettivi HAT
• Battery 18650 3500mAh @ ciclo 67s ogni 5min: ~3-4 giorni (con questo cycle, NO PSM)

Per autonomia >30 giorni serve abilitare PSM (AT+CPSMS=1) e ridurre i cicli alla frequenza dettata dalla rete.

Dati raw bench

• PNG overlay: /shield/waveshare-sim7080g-cycle-bench-2026-06-06.png
• CSV samples: /shield/waveshare-sim7080g-cycle-samples-2026-06-06.csv
• Script template: test-moduli/waveshare-sim7080g-hat/visla-v2-cycle-fnb58.py

⚡ Bench-test Visla 2026-06-06 — connessione confermata 1NCE/Vodafone IT

Setup: HAT standalone (no RPi), USB-C diretto al Mac, SIM 1NCE (ICCID 89882280666225121627) inserita, antenna LTE collegata. Identificazione via FT232R /dev/cu.usbserial-BG00W8YJ @ 115200.

Identificazione modem

Test NB-IoT mode (AT+CMNB=2 + CNMP=38)

Test Cat-M mode (AT+CMNB=1 dopo CFUN=0/1)

HTTP GET confermato (Cat-M)

AT+SHCONF="URL","http://httpbin.org"  → OK
AT+SHCONN                             → OK (8s connect)
AT+SHREQ="/ip",1                      → +SHREQ: "GET",200,32
AT+SHREAD=0,32                        → {"origin":"18.184.88.141"}

IP egress 18.184.88.141 = AWS Frankfurt range = NAT 1NCE che routa tutto via Germania.

PDP context attivo

AT+CGDCONT=1,"IP","iot.1nce.net"  → OK
AT+CNACT=0,1                       → +APP PDP: 0,ACTIVE
AT+CNACT?                          → +CNACT: 0,1,"100.107.94.9"

IP CGNAT 100.107.94.9 = tipico IoT carrier-grade NAT, non raggiungibile dall’esterno ma supporta egress MQTT/HTTP/CoAP.

🆚 NB-IoT vs Cat-M — quale scegliere

🔋 Consumi datasheet Waveshare HAT

Dal wiki Waveshare (board level + module level):

Overhead board level = 29 mA (idle 39 - module 10): è il LDO MP1482 + RT9193-33 + 3 LED + FT232R + voltage translator.

Per misure µA-level reali PSM serve bypassare LED + alimentare VBAT diretto.

🆚 Confronto vs LilyGO T-SIM7080G (validato bench Visla)

🛠 Setup per test su Mac (no RPi)

1. Jumper PWR → posizione B (PWR tied to power supply, auto-on standalone)
   • In posizione A (default RPi) richiede GPIO P4 high → senza RPi non boota
2. Voltage level jumper → 3.3V (default, NON spostare a 5V — SIM7080G I/O tolera max 3.3V)
3. SIM card 1.8V only — NB-IoT/Cat-M, no SIM telefono 3V regolare
4. Antenna LTE obbligatoria, GNSS opzionale per test cellular
5. PWR_KEY → tieni premuto ≥1.5 sec dopo USB-C connesso → boot dopo 5-10s, STA LED dovrebbe lampeggiare quando registrato

LED indicators

• 🔴 PWR = power supply 3.8V presente
• 🔴 STA = modem status (acceso fisso = booted)
• 🟢 NET = network status (lampeggio = registrato/data)

Sintassi AT base testata

AT                              # alive check
AT+CMNB=2                       # forza NB-IoT (1=Cat-M, 3=both)
AT+CNMP=38                      # LTE only
AT+CGDCONT=1,"IP","iot.1nce.net"
AT+CNACT=0,1                    # attiva PDP
AT+SNPING4="8.8.8.8",3,32,1000  # ping
AT+SHCONF="URL","http://...     # HTTP setup
AT+SHCONN                       # HTTP connect
AT+SHREQ="/path",1              # 1=GET 3=POST
AT+SHREAD=0,<bodylen>           # leggi body

Specs tecniche complete

✅ Quando usare questa scheda

⚠️ Gotcha noti dal bench

1. Autobaud iniziale necessario: i primi byte dopo PWR boot sono garbled ((U\xa8H\xe8j\xaaH\xf8). Inviare burst di 5-10× AT\r\n per sync — poi parla pulito a 115200. Via pin header servono 10× burst (linea un po’ più rumorosa dei cavi Dupont vs traccia PCB interna)
2. PWR jumper default è A (RPi mode): senza RPi devi spostare a B per auto-boot
3. CFUN=0/1 richiesto per cambio CMNB: senza re-init il cambio NB-IoT↔Cat-M non si applica
4. SHREAD body length: parsare il numero da +SHREQ: "GET",200,N e passarlo a SHREAD=0,N — senza N esatto restituisce ERROR
5. CGNAT IP: l’IP assegnato 100.x.x.x non è raggiungibile da fuori — funziona solo per egress (MQTT publish, HTTP GET, ecc.)
6. No GSM/GPRS fallback: a differenza del 7070G, questo NON ha 2G — se area senza Cat-M né NB-IoT, niente connessione

📌 Nota importante: cablaggio pin header (NO inversione TX/RX)

Se colleghi un host esterno (XIAO ESP32, STM32, Arduino, Waveshare USB-TTL) al 40-pin GPIO header del HAT invece di usare la USB-C onboard, NON serve invertire TX/RX al connettore. La PCB del HAT fa già l’incrocio internamente seguendo la convenzione Raspberry Pi.

Cablaggio diretto (match labels)

I label sul pin header sono dal punto di vista del Pi/host (TXD = host transmit, RXD = host receive). L’incrocio verso il modem (TX host → RX modem) avviene dentro la PCB del HAT, tu non te ne preoccupi.

Regola pratica:

• Su HAT/breakout RPi-compatibile → match labels (TX↔TXD, RX↔RXD), niente inversione
• Su chip modem nudo (es. BK-SIM7080G core board, PCB custom) → inversione manuale (TX↔RX)

⚠️ Importante quando usi pin header

• SCOLLEGA la USB-C del HAT prima di usare il pin header — altrimenti il FT232R onboard compete con l’host esterno sulla TX modem (linea corrotta, modem silent)
• GND obbligatorio condiviso (memo feedback_uart_modem_gnd_shared.md)
• Voltage level jumper su 3.3V se host è XIAO/STM32 (mai 5V su logica 3.3V)
• Alimentazione 5V può venire da pin 2/4 del header o esternamente — non da host MCU 3.3V

Bench-validated 2026-06-06: identico comportamento HTTP GET su path USB-C vs path pin header (stesso CSQ, stesso ping, stessa response IP egress).

🔗 Risorse

• 🏭 Waveshare wiki SIM7080G HAT
• 🛒 Waveshare $32.99
• 📄 SIM7080 AT Command Manual V1.02
• 📄 SIM7080 Low Power Mode Application Note
• 🧠 Vai alla chip card SIM7080G
• ⚡ Vai alla card LilyGO T-SIM7080G per confronto