Quando qualcosa non funziona nel DMR, la domanda più frequente è:
“Il problema è nella mia radio, nel ripetitore, nell’hotspot oppure nella rete?”
Non sempre è semplice rispondere.
Una comunicazione digitale attraversa infatti numerosi elementi:
RADIO
↓
COLLEGAMENTO RF
↓
RIPETITORE / HOTSPOT
↓
CONNESSIONE INTERNET
↓
MASTER / NETWORK
↓
ALTRO RIPETITORE
↓
ALTRA RADIO
Un guasto o una configurazione errata in qualunque punto della catena può produrre apparentemente lo stesso risultato:
non sentiamo nulla.
Per questo motivo i network digitali mettono a disposizione alcuni strumenti diagnostici molto utili. Il più conosciuto è il cosiddetto Parrot, o echo test: trasmettiamo un breve messaggio e il sistema ce lo riproduce.
Sembra una funzione banale, ma utilizzata correttamente permette di verificare in pochi secondi buona parte della catena radio-network.
In questo articolo vedremo:
- cos’è il Parrot;
- cosa verifica realmente;
- cosa invece non può verificare;
- come utilizzarlo correttamente;
- come interpretare l’audio ricevuto;
- RSSI e BER;
- dashboard e log MMDVM;
- problemi di hotspot;
- problemi di codeplug;
- problemi di rete;
- una procedura diagnostica sistematica.
Che cos’è il Parrot?
Il termine inglese Parrot significa letteralmente:
pappagallo.
Il nome descrive perfettamente il comportamento del servizio.
Noi diciamo:
“IZ1XXX prova audio uno due tre.”
Il sistema registra temporaneamente il nostro audio digitale e, terminata la trasmissione, lo riproduce verso la nostra radio:
“IZ1XXX prova audio uno due tre.”
È quindi sostanzialmente un echo server vocale.
Nei codeplug radioamatoriali DMR viene spesso inserito come contatto dedicato. In molte configurazioni BrandMeister viene utilizzato il contatto privato 9990, anche se il servizio effettivamente disponibile può dipendere dal master e dal network utilizzato; è quindi sempre opportuno verificare la documentazione della rete a cui si è collegati. Documentazione radioamatoriale italiana dedicata ai codeplug BrandMeister include infatti “Parrot” come contatto privato 9990.
Perché il Parrot è così utile?
Supponiamo che premiamo il PTT.
Sul display appare:
TG 22215
TS2
CC1
ma nessuno risponde.
Questo non significa necessariamente che la radio non funzioni.
Potrebbero esserci semplicemente:
- nessun utente in ascolto;
- un Talkgroup dinamico non attivo;
- un problema lato network;
- un problema nel percorso di ritorno;
- una configurazione errata.
Con il Parrot eliminiamo gran parte dell’incertezza perché conosciamo già il comportamento atteso.
Trasmettiamo:
PROVA D2ALP
UNO DUE TRE
e sappiamo che dovremmo ricevere indietro:
PROVA D2ALP
UNO DUE TRE
Se questo avviene, abbiamo già dimostrato che numerosi elementi della catena stanno funzionando.
Cosa verifica realmente un Parrot test?
Immaginiamo di utilizzare un hotspot.
Il percorso può essere:
RADIO
│
▼
HOTSPOT
│
▼
MMDVMHOST
│
▼
INTERNET
│
▼
MASTER DMR
│
▼
SERVIZIO PARROT
│
▼
MASTER
│
▼
HOTSPOT
│
▼
RADIO
Se ascoltiamo correttamente la nostra voce di ritorno, possiamo ragionevolmente concludere che:
- la radio trasmette;
- la frequenza TX è corretta;
- il Color Code è compatibile;
- il Time Slot utilizzato è compatibile;
- il DMR ID viene almeno riconosciuto nel percorso;
- l’hotspot riceve la nostra RF;
- il modem MMDVM sta decodificando il DMR;
- il collegamento verso il master funziona;
- il server ha ricevuto la nostra chiamata;
- il percorso network di ritorno funziona;
- l’hotspot sta ritrasmettendo;
- la nostra radio riceve;
- l’audio vocoder è decodificabile.
È quindi un test sorprendentemente completo.
Ma il Parrot non verifica tutto
Questo è altrettanto importante.
Se il Parrot funziona non significa automaticamente che:
- tutti i Talkgroup funzionino;
- tutti i ripetitori siano raggiungibili;
- il roaming sia configurato correttamente;
- una determinata rete esterna sia disponibile;
- il bridge verso un altro sistema funzioni;
- un TG dinamico sia attivato;
- il Talkgroup desiderato sia statico sul ripetitore.
Il Parrot verifica soprattutto la nostra catena di base.
In termini diagnostici:
Il Parrot è uno strumento per isolare il problema, non una certificazione dell’intero network.
Come effettuare correttamente il test
La prima regola è conoscere le istruzioni della propria rete.
Non bisogna assumere che “Parrot = sempre TG9990”.
Su molte configurazioni BrandMeister viene utilizzata una Private Call verso l’ID 9990; guide operative per hotspot descrivono esplicitamente questa procedura.
Il concetto fondamentale è distinguere:
GROUP CALL
da:
PRIVATE CALL
Un contatto programmato con il numero corretto ma con il tipo di chiamata sbagliato può non produrre il risultato desiderato.
Configurazione tipica del contatto
Nel CPS della radio potremmo creare:
Nome: PARROT
ID: 9990
Tipo: PRIVATE CALL
e successivamente un canale:
Nome: PARROT RPT
RX: frequenza ripetitore
TX: frequenza ripetitore
CC: Color Code del ripetitore
TS: slot previsto
Contact: PARROT
Con hotspot simplex potremo invece avere:
RX/TX: frequenza hotspot
CC: 1
TS: secondo configurazione
Contact: PARROT
I parametri reali devono naturalmente corrispondere alla configurazione del proprio hotspot o ripetitore.
Quanto deve durare il test?
Non serve fare una trasmissione di un minuto.
È sufficiente una frase breve:
“IZ1XXX, prova Parrot, uno due tre quattro cinque.”
Cinque-dieci secondi sono più che sufficienti.
Un test troppo lungo:
- occupa inutilmente risorse;
- rende più difficile confrontare prove successive;
- non offre generalmente informazioni aggiuntive.
Cosa dobbiamo ascoltare?
Il Parrot è particolarmente utile perché ci permette di ascoltare noi stessi come ci riceve il sistema.
Possiamo quindi valutare:
- intelligibilità;
- volume;
- distorsione;
- clipping;
- rumore;
- audio robotizzato;
- interruzioni;
- pacchetti mancanti.
È però importante interpretare correttamente ciò che sentiamo.
Caso 1: audio perfetto
Trasmettiamo:
“Prova uno due tre.”
e riceviamo:
“Prova uno due tre.”
con audio pulito e continuo.
È una forte indicazione che il percorso:
RADIO → RF → RIPETITORE/HOTSPOT → NETWORK
e quello inverso funzionano correttamente.
A questo punto, se non riusciamo a utilizzare un determinato TG, il problema va cercato altrove.
Per esempio:
- Talkgroup;
- slot;
- routing;
- sottoscrizione dinamica;
- configurazione network.
Caso 2: il Parrot riceve ma l’audio è bassissimo
Possibili cause:
- livello microfonico troppo basso;
- microfono distante;
- impostazione mic gain errata;
- accessorio audio difettoso;
- foro del microfono ostruito.
Il fatto che la comunicazione digitale venga stabilita significa che la parte RF può essere perfettamente funzionante, ma l’audio inserito nel vocoder è insufficiente.
Caso 3: audio estremamente forte e distorto
Possibili cause:
- microfono gain troppo elevato;
- parlare troppo vicino;
- accessorio microfonico non adatto;
- clipping prima della codifica digitale.
Un errore comune consiste nel pensare:
“Digitale significa audio sempre perfetto.”
No.
Il DMR trasporta digitalmente ciò che il microfono e la catena audio gli forniscono.
Se il segnale audio di ingresso è pessimo, verrà codificato un pessimo audio.
Caso 4: audio robotizzato
Questo è molto interessante.
Se alcune sillabe diventano:
- metalliche;
- robotiche;
- spezzate;
- incomprensibili;
il problema può essere RF.
Il vocoder AMBE può ricostruire l’audio entro determinati limiti, ma quando gli errori aumentano, la qualità degrada rapidamente.
Possibili cause:
- BER elevato;
- segnale marginale;
- interferenza;
- multipath;
- hotspot mal calibrato;
- offset RX/TX non corretto;
- desensibilizzazione.
Caso 5: parole completamente mancanti
Per esempio diciamo:
“IZ1XXX prova radio dal centro di Tortona.”
e ascoltiamo:
“IZ1XXX… radio… centro… Tortona.”
Qui potrebbero esserci perdite di frame.
Il sistema digitale non degrada necessariamente in maniera graduale come l’FM analogica.
Può passare da:
AUDIO PERFETTO
a:
AUDIO ROBOTICO
e poi:
BUCHI / SILENZI
fino alla perdita completa della comunicazione.
È il cosiddetto digital cliff, che analizzeremo in uno degli articoli successivi.
Il Parrot e il BER
Se utilizziamo un hotspot MMDVM possiamo ottenere una seconda informazione estremamente importante:
BER
Bit Error Rate.
Nei log MMDVM possiamo trovare righe simili a:
DMR Slot 2
received RF end of voice transmission
BER: 0.5%
RSSI: -57 dBm
MMDVM-Host mantiene infatti un conteggio degli errori e dei bit durante la ricezione DMR e al termine della trasmissione può registrare il BER calcolato; nel codice vengono analizzati anche gruppi di 141 bit per i voice frame.
Questo permette di trasformare il Parrot da semplice prova audio in uno strumento molto più preciso.
RSSI e BER: due informazioni differenti
Supponiamo che il dashboard mostri:
RSSI: -50 dBm
BER: 0.2%
Abbiamo:
- segnale forte;
- pochissimi errori.
Situazione eccellente.
Ma potremmo anche avere:
RSSI: -50 dBm
BER: 7%
Segnale forte ma moltissimi errori.
Come è possibile?
Perché RSSI e BER misurano due fenomeni differenti.
RSSI
Indica essenzialmente quanta energia RF viene ricevuta.
BER
Indica quanti bit vengono interpretati erroneamente.
Un segnale può essere forte ma deformato.
Per esempio:
- frequenza leggermente errata;
- livello di deviazione/modulazione errato;
- interferenza;
- saturazione;
- multipath.
Il ricevitore vede tanta RF, ma non riesce a interpretarla correttamente.
Dashboard dell’hotspot
Un hotspot basato su MMDVM è un eccellente banco prova.
Durante una trasmissione possiamo osservare:
- callsign;
- DMR ID;
- Talkgroup;
- Time Slot;
- durata;
- BER;
- RSSI, se disponibile;
- sorgente RF o network.
Possiamo quindi distinguere:
RF → HOTSPOT
da:
NETWORK → HOTSPOT
Questa distinzione è fondamentale.
Diagnosi: il dashboard non vede il mio PTT
Premiamo PTT.
La radio sembra trasmettere.
Il dashboard non mostra assolutamente nulla.
Probabili aree da controllare:
Frequenza
TX radio e RX hotspot devono coincidere.
Color Code
Deve essere quello corretto.
Time Slot
Deve essere compatibile con la configurazione utilizzata.
Modem
MMDVM potrebbe non ricevere correttamente.
Offset
La radio e l’hotspot potrebbero non essere sufficientemente allineati in frequenza.
Potenza e distanza
Un hotspot a dieci centimetri da una radio a 5 W non è necessariamente una buona idea.
Il front-end può essere sovraccaricato.
Diagnosi: il dashboard vede il PTT ma il Parrot non ritorna
Questa situazione è molto interessante.
Abbiamo dimostrato che:
RADIO → HOTSPOT
funziona.
Ora dobbiamo guardare verso:
HOTSPOT → NETWORK
Possibili cause:
- hotspot non connesso al master;
- password hotspot errata;
- server errato;
- connessione Internet;
- servizio Parrot non disponibile sul master utilizzato;
- contatto configurato come Group anziché Private o viceversa secondo la rete;
- routing non corretto.
In altre parole:
se il dashboard vede la RF, smettiamo di modificare a caso la frequenza della radio.
Abbiamo già localizzato il problema più avanti nella catena.
Diagnosi: vedo il ritorno sul dashboard ma non sento nulla
Supponiamo:
NETWORK RX
compare sul dashboard.
Quindi il server sta inviando il Parrot all’hotspot.
Ma la radio rimane muta.
Ora il problema è probabilmente nel tratto:
HOTSPOT → RADIO
Controllare:
- frequenza RX radio;
- Time Slot;
- Color Code;
- criteri di ammissione;
- Private Call reception;
- squelch digitale;
- impostazioni della radio;
- eventuali filtri.
Diagnosi per esclusione
Questa è la metodologia più importante.
Non dobbiamo cambiare dieci impostazioni contemporaneamente.
Dobbiamo dividere il sistema.
Fase 1
RADIO → HOTSPOT
Il dashboard vede la radio?
NO
Problema RF/configurazione locale.
SÌ
Passiamo avanti.
Fase 2
HOTSPOT → NETWORK
Il master riceve?
Se no:
- Internet;
- autenticazione;
- configurazione server.
Fase 3
NETWORK → HOTSPOT
Compare traffico RX?
Se sì, il network ritorna correttamente.
Fase 4
HOTSPOT → RADIO
La radio apre l’audio?
Se no, controllare il percorso RF di ritorno.
Quattro domande invece di cinquanta tentativi casuali.
Il Parrot come prova dell’audio microfonico
Il Parrot è probabilmente il sistema migliore per regolare il microfono.
Possiamo fare tre prove:
MIC GAIN LOW
MIC GAIN MEDIUM
MIC GAIN HIGH
registrando mentalmente o annotando il risultato.
L’obiettivo non è avere:
l’audio più forte possibile.
L’obiettivo è:
l’audio più intelligibile possibile senza distorsione.
Una voce eccessivamente compressa o saturata può risultare fastidiosa anche se apparentemente molto forte.
Mantenere sempre la stessa frase
Per confrontare due configurazioni conviene utilizzare la stessa frase.
Per esempio:
“IZ1XBB prova audio DMR, uno due tre quattro cinque.”
Proviamo:
- Gain 1;
- Gain 2;
- Gain 3.
Se cambiamo frase ogni volta, il confronto diventa meno affidabile.
Parrot e calibrazione MMDVM
Qui entriamo in un argomento più tecnico.
Il modem MMDVM deve essere correttamente calibrato.
Parametri errati possono produrre un BER elevato anche quando il segnale RF è molto forte.
Il software DVMHost, per esempio, prevede procedure di calibrazione nelle quali si modifica il livello TX osservando il BER ricevuto e cercando di minimizzarlo.
Lo stesso principio viene applicato frequentemente nella taratura pratica degli hotspot MMDVM.
L’obiettivo non deve essere:
“far diventare il segnale più forte.”
Deve essere:
“far diventare la demodulazione più corretta.”
L’offset di frequenza
Uno dei classici problemi degli hotspot economici è un piccolo errore di frequenza.
La radio trasmette nominalmente:
433.550000 MHz
ma l’hotspot potrebbe interpretare correttamente il segnale solo applicando una piccola compensazione.
Se l’errore è significativo, il risultato può essere:
RSSI molto forte
BER alto
Questo è un indizio molto utile.
Se radio e hotspot sono vicinissimi ma il BER è elevato, difficilmente il problema è la potenza insufficiente.
È più sensato verificare:
- offset;
- calibrazione;
- sovraccarico;
- firmware;
- qualità RF.
Attenzione alla radio troppo vicina
“Più vicino è meglio” non è sempre vero.
Una portatile a pochi centimetri da un hotspot può generare un segnale estremamente forte.
Il piccolo ricevitore del modem potrebbe saturare.
Possiamo quindi avere paradossalmente:
30 cm → BER 4%
e:
3 metri → BER 0.3%
Non è impossibile.
Durante una diagnosi conviene quindi effettuare prove a differenti distanze.
Il ruolo dei log
Il log è uno degli strumenti più importanti e contemporaneamente più ignorati.
Una riga come:
received RF voice header
ci dice che il sistema ha riconosciuto l’inizio della comunicazione.
Una riga finale con:
BER: 0.5%
ci dà informazioni sulla qualità della decodifica.
Il codice MMDVM-Host registra esplicitamente, al termine di una chiamata DMR, durata, BER e — quando disponibile — valori RSSI minimo, massimo e medio.
Questo è molto più utile di:
“Mi sembra che arrivi bene.”
Un semplice protocollo di prova
Quando configuriamo una nuova radio o hotspot possiamo utilizzare sempre questa procedura.
Test 1 — Accesso RF
Premere PTT e verificare che il dispositivo riceva.
Test 2 — Identificazione
Controllare:
Callsign
DMR ID
Destination
TS
Test 3 — BER
Effettuare una trasmissione di circa 5-10 secondi.
Annotare il BER.
Test 4 — Parrot
Verificare il percorso completo di andata e ritorno.
Test 5 — Qualità audio
Ascoltare:
- volume;
- distorsione;
- drop;
- robotizzazione.
Test 6 — Talkgroup reale
Solo dopo che i primi cinque test sono superati ha senso provare un TG vero.
Non utilizzare TG affollati come strumento diagnostico
Un comportamento poco elegante consiste nel fare continuamente:
“Prova prova prova, mi sentite?”
su un Talkgroup nazionale o internazionale.
Se esiste un servizio Parrot, utilizziamolo.
È precisamente ciò per cui è stato creato.
Una breve prova su un TG reale può naturalmente essere legittima, ma per calibrare microfono, BER e configurazione possiamo lavorare senza disturbare decine di ripetitori.
Echo test e bridge multiprotocollo
Su reti complesse possiamo utilizzare il concetto di echo test anche per capire dove si interrompe un bridge.
Supponiamo:
DMR
↓
BRIDGE
↓
YSF
Il Parrot DMR funziona.
Quindi sappiamo che:
RADIO → DMR NETWORK
è operativo.
Se il bridge verso YSF non funziona, non ha senso iniziare cambiando:
- microfono;
- frequenza hotspot;
- Color Code.
Abbiamo già dimostrato che quella parte funziona.
La diagnostica per segmenti permette di evitare ore di prove inutili.
Tabella diagnostica rapida
| Sintomo | Possibile area |
|---|---|
| Nessun PTT sul dashboard | RF / frequenza / CC / slot / modem |
| PTT visibile ma niente Parrot | Network / autenticazione / servizio |
| Parrot arriva al dashboard ma non alla radio | RX radio / RF hotspot |
| Parrot audio basso | Mic gain / microfono |
| Audio distorto | Gain eccessivo / clipping |
| Audio robotico | BER / RF / calibrazione |
| BER alto con RSSI basso | Copertura insufficiente |
| BER alto con RSSI molto forte | Calibrazione / interferenza / overload |
| BER basso ma nessun TG | Routing / TG / network |
Parrot e ripetitori
Lo stesso principio può essere applicato attraverso un ripetitore pubblico, se il network collegato supporta il servizio.
La differenza principale è che non abbiamo accesso diretto al modem.
Quindi potremmo non vedere:
- BER;
- RSSI;
- log RF.
Il sysop del ripetitore potrebbe invece disporre di queste informazioni.
Questo rende il Parrot particolarmente utile anche per comunicare una diagnosi al gestore:
“Dal punto X il Parrot mi ritorna completamente robotico.”
Il sysop può confrontare quell’informazione con il BER registrato dal ripetitore.
Non confondere uplink e downlink
Supponiamo che il Parrot ritorni male.
Quale tratta è debole?
Potrebbe essere:
RADIO → RIPETITORE
oppure:
RIPETITORE → RADIO
Il semplice ascolto non permette sempre di distinguerle.
Se il ripetitore registra BER elevato sul nostro ingresso, il problema interessa probabilmente l’uplink.
Se invece il ripetitore riceve perfettamente ma noi ascoltiamo male il ritorno, potrebbe essere il downlink.
Ancora una volta:
misurare è meglio che indovinare.
Conclusione
Il Parrot è molto più di un curioso effetto che ripete la nostra voce.
È uno dei più efficaci strumenti diagnostici disponibili nel DMR.
In pochi secondi può verificare buona parte della catena:
RADIO
↕
RF
↕
RIPETITORE / HOTSPOT
↕
NETWORK
Abbinandolo a:
- dashboard;
- log;
- RSSI;
- BER;
possiamo trasformare una diagnosi basata su tentativi casuali in una procedura sistematica.
La regola fondamentale dovrebbe essere:
non modificare tutto finché non funziona: individua prima in quale punto della catena si trova il problema.
Il Parrot ci permette precisamente di fare questo.
E quando viene utilizzato insieme al BER diventa un vero e proprio piccolo strumento da laboratorio per comprendere come la nostra radio viene realmente ricevuta dal sistema.