Visto che questa sera ho a disposizione tempo, radio e segnali forti, ho voluto fare una prova di ricezione di una stazione locale che usa DMR. Si tratta di una utility della mia città, che non sono riuscito ancora ad ascoltare con il mio fido Radioddity.
Ci ho messo un po’ per trovare la giusta configurazione dei parametri operativi, ma alla fine funziona ed anche bene. Le stazioni che sono più distanti arrivano molto male, ma è un ottimo inizio.
Non mi sono mai interessato molto al traffico satellitare. Vuoi per mancanza di spazio per le antenne, vuoi perché non si può fare tutto nella vita.
Recentemente mi sono nuovamente fatto incuriosire dalla ISS, per creare delle registrazioni da mostrare agli studenti del corso di “sistemi di telecomunicazione”.
L’idea è quella di mostrare loro gli effetti del rumore e le caratteristiche di un canale satellitare e di cogliere occasione per parlare di LEO, MEO e GEO.
Obbiettivo dell’esperimento: cercare di registrare un segnale audio decente dai passaggi della ISS, utilizzando il ricevitore SDR (Airspy Mini) che ho installato presso il mio ufficio e collegato ad una antenna Diskona della Hoxin (presa su ebay a circa 60 euro). Qualche problemino è emerso:
– ogni tanto la rete di casa faceva perdere qualche pacchetto di troppo;
– il segnale audio della ISS in modalità SSTV è piuttosto bassino;
– sono un cialtrone ad usare MMSSTV;
– ho avuto troppe difficoltà a salvare i dati in “banda base”, perdo frame. Questa cosa è da approfondire!
Malgrado tutti i limiti, anche quelli ambientali (fare acquisizioni con un lattante in braccio non è proprio agevole), qualche cosa nel paniere c’è rimasto. Tre immagini, piuttosto noisy e anche un po’ fuori sincronia. Per essere una “prima volta” best-effort, sono soddisfatto.
Da qualche tempo è comparsa, sul tetto dell’Università, una stazione meteo piuttosto carina: Davis Vantage Pro 2. Il sensore è installato sul tetto della torre a quota 195, la stazione nel piano sottostante. Le due unità comunicano “wireless”. I dati della stazione mi interessano per diversi motivi:
– mi piace sapere quanto fa caldo/freddo al lavoro;
-mi interessa correlare questi dati con i dati AIS in modo da valutare la propagazione troposferica in funzione del tempo atmosferico.
I dati della stazione meteo è difficile ottenerli in modo “ufficiale”: la stazione è collegata ad un portatile che non è accessibile dalla rete. Inoltre non ho idea di chi la abbia installata. Pertanto c’è un solo modo: i dati “me li prendo”. Sfortunatamente il programma rtl_433 non riesce a demodulare queste informazioni:
– rtl_433 demodula ASK mentre le Davis usano FSK;
– rtl_433 non interpreta il protocollo Davis;
La soluzione è arrivata da rtldavis, un programma scritto in go lang, che effettua le seguenti operazioni:
– accesso alla chiavetta rtl-sdr;
– algoritmi DSP per la demodulazione del segnale;
– algoritmi per la decodifica del protocollo.
Peccato che l’autore abbia terminato lo sviluppo del codice senza terminarlo (la parte di di decodifica del protocollo non è terminata). Inoltre il codice è studiato per le stazioni americane e deve essere modificato per lavorare nella banda ISM italiana.
Modifica al codice go lang: il file è “protocol.go“. Le informazioni sulla frequenza dei canali usate in Europa ho provato a ricavarle con una chiavetta SDR ma occorre essere piuttosto precisi. Fortunatamente ho trovato questo articolo in cui ci sono parecchie informazioni. In America si usano 51 canali, in Europa 5. Il codice è il seguente:
p.channels = []int{
868066711, 868181885, 868297119, 868412292, 868527466,
}
p.hopPattern = []int{
0, 2, 4, 1, 3,
}
Compilato il codice in “go”, l’output è piuttosto “criptico”:
600222FFC3004DD9
8002241FBB00C0B9
…
Ho provato a realizzare l’interprete del protocollo in go, ma ammetto che non ho ricavato nulla: non sono stato in grado, in tempi brevi, di trovare informazioni tali da permettermi di implementare delle funzioni facilmente. Ho deciso per un approccio alternativo: scrivere un interprete in Python che esegua queste funzioni:
– ricevere in input il protocollo raw;
– decodificare il protocollo;
– inserire i dati in mysql;
Le specifiche del protocollo sono perfettamente specificate in questo sito.
Nelle parti maggiormente criptiche mi sono fatto aiutare da questo codice, realizzato per arduino ma… sempre buono.
Output del programma:
Data 2019 02 17 Ora: 12 51
91030 500283FF710086F8
Input Lenght 2
Colonna
500283FF710086F8
Output Lenght 8
[’50’, ’02’, ’83’, ‘FF’, ’71’, ’00’, ’86’, ‘F8’]
Element 0 50
Element 1 02
Element 2 83
Element 3 FF
Element 4 71
Element 5 00
Element 6 86
Element 7 F8
Summary
Station id 0
Message Type 5
Message Type Rain Rate
Wind Velocity 3.21
Wind Direction 183.35
Wind Gust 0
Humidity 0
Rain 0.0
Rain Rate mm/h 0.0
Temperature C 0
Solar Radiation 1798.36
UV Index 0
SuperCap 0
Debug inserimento dati nel DB
Debug – anno: 2019
Closing down
Cosa scaricare:
– programma originale in “go” dell’autore Douglas Hall
– si compila e si mette in /usr/local/bin/
– Script in python:
– versione 2 — funziona da riga di comando: rtldavis 2>&1 | python weather_decoder_2.py
– versione 3 — Avvia automaticamente rtldavis come subprocess.
Il pacchetto completo si può scaricare da questo link.
Recentemente in casa sono comparsi dei simpatici oggettini che sono detti “baby monitor”. Si tratta di una coppia trasmettitore/ricevitore che dovrebbe dare ai neo-genitori, la sensazione di avere una vita normale, potendo ascoltare da remoto vagiti e gemiti dell’infante.
Non si tratta di una invenzione nuova: ricordo perfettamente che “tanti ani fa” lavoravano in FM a 29700kHz. Si potevano ascoltare molto facilmente con ricevitore, davano parecchio fastidio alle automobiline radiocomandate e li ricevevano anche i walkie-talkie giocattolo (che erano in AM).
I baby-monitor di adesso hanno dimensioni molto contenute, antenne interne e batterie ricaricabili. Per intenderci una cosa di questo tipo. Leggendo le specifiche si apprezza la frequenza di funzionamento compresa tra 1800MHz e 1900MHz, in piena banda DECT. In effetti leggendo il manuale:
– Trasmissione vocale tramite sistema basato su tecnologia digitale DECT.
– Range operativo in campo aperto senza ostacoli di circa 300 metri.
DECT è uno standard che nasce per la telefonia cordless che prevede l’uso di codec audio a 32kbps e 64kbps (G726,G722) su 10 canali nella banda 1800MHz, 1900MHz. Il layer fisico usa FDMA/TDMA con TDD. La modulazione usata è GFSK ma può implementare anche modulazioni più aggressive.
In rete ho trovato un interessante articolo con questo titolo: “RE-DECTED: AN RTL-SDR DECT DECODER”. Nell’articolo si fa riferimento ad un codice contenuto su git-hub: re-DECTED. Il sistema è costruito attorno a Gnuradio e richiede un hardware in grado di sintonizzare i 1900MHz. Per questo è consigliato l’uso di un SDR basato su E4000, il compianto tuner della Elonics o di un ricevitore generico in grado di lavorare a 2.4Ms/s. Anche AIRSPY mini è tagliato fuori: arriva fino a 1700MHz. Pertanto ho deciso di modificare il codice per farlo lavorare con ADALM PLUTO.
Il codice elaborato da “znuh” prevede l’uso di diversi elementi:
– un eseguibile C dectrcv.c che riceve i dati dalla interfaccia localhost, visualizza i frames ricevuti e li redirige alla interfaccia dummy0;
– il codice python che avvia una configurazione su GNURADIO che esegue la ricezione del segnale RF;
– il codice GNURAIO è nel file dectrx.grc che può essere aperto anche con GNURADIO.
Il primo step è modificare il codice grc per introdurre il nuovo “sdr source” adalm pluto. Il primo problema è che il PLUTO non campiona a 2.4Ms/s, ma a 3Ms/s. Il blocco di ricezione invece vuole proprio questo valore. Pertanto è necessario modificare il “rational resampler”. Nella formulazione originale il flusso a 2.4Ms/s viene interpolato per 24 e decimato per 25, ottenendo 2304000. Per avere 2.4Ms/s a partire da 3Ms/s occorre moltiplicare per 0.8, ovvero interpolare per 4 e decimare per 5.
Una volta effettuata la modifica non resta che avviare nella sequenza giusta i software e godersi l’output con “wireshark”. Per creare l’interfaccia dummy in un sistema Ubuntu è meglio seguire questo tutorial.
Si potrebbe decodificare anche l’audio ma, sinceramente, non ne ho la minima voglia!
Il nuovo GRC si può scaricare da qui.
RTL_433 è un progetto che ho scoperto per caso, navigando senza rotta in giro per la rete. Il sito di riferimento è su github. Si tratta di un simpatico programmino che rileva la presenza di una chiavetta SDR lo sintonizza a 433,920 MHz e si mette in ascolto su una finestra di 250kS/s. In questa fetta di spettro sono allocati sensori e telecomandi a bassa potenza. In particolare le stazioni meteo che hanno sensori wireless usano la modulazione ASK per trasmettere i dati al concentratore.
Il programma rtl_433 riesce a demodulare i segnali dei sensori ed a interpretare il protocollo ed i dati da esso trasmessi. La cosa è molto interessante soprattutto considerando che i sensori sono dispositivi di debole potenza ed il loro raggio di azione è molto limitato. Pertanto, a meno di installazioni piuttosto bizzare, i dati ricevuti rispecchiano le condizioni meteo della zona in cui sono posizionati.
Il programma si presta bene a “sostituire” una stazione meteo, sfruttando quella di qualche ignaro vicino o consente di confrontare la propria stazione con quelle commerciali.
L’installazione del sistema è banalissima, basta compilare il sorgente scaricato da github ed eseguire il binario rtl_433. Nella mia installazione ho dovuto aumentare la frequenza di campionamento in quanto mi sono reso conto che c’erano diversi sensori “lontani”. Pertanto adesso il sistema lavora a 1024kS/s.
Collegata la chiavetta ad una antenna diskona, è iniziata la festa. I segnali dei sensori sono decodificati facilmente ed il programma restituisce un sacco di informazioni utili, anche dal punto di vista comunicazionisitico: SNR – RSSI – NOISE.
A questo punto l’appetito viene mangiando: come fare per immagazzinare i dati ricevuti in un database (MariaDB) in modo da potere rendere in forma grafica alcuni parametri?
In rete ho trovato questo interessante progetto in Python. Ho quindi preso spunto da questo script per cercare di combinare qualche cosa in Python. Ne è venuto fuori uno script che immagazzina tutti i dati nel database e registra i dati grezzi in formato JSON su un file. A corollario di questo ho anche scritto una serie di script php che consentono di accedere ai dati in forma tabulare e di rappresentare l’andamento dei parametri fisici (temperatura, umidità) e radioelettrici (rssi,snr,noise) in funzione del tempo.
Grafico dei parametri fisici e radioelettrici:
Questa immagine è molto interessante. Mostra l’andamento della temperatura nel tempo. Il fatto è che… le minime sono coerenti con quanto misurato anche da altri sensori. Le massime sono completamente sballate (a gennaio è improbabile raggiungere i 36 gradi). Morale della favola? Il sensore è probabilmente installato al sole, in un contenitore di plastica.
Da casa riesco a ricevere una stazione “dignitosa” marca Fine Offset. Penso sia una cosa di questo tipo. Posso confrontare la temperatura rilevata dalla stazione commerciale e la mia: c’è un ottimo accordo di notte. Di giorno c’è qualche discrepanza: 11.7 mia contro 8.8 commerciale ma non conosco l’esatta ubicazione della stazione. Sicuramente il mio schermo solare deve essere perfezionato: apertura sul fondo in primis, ventilazione forzata in secundis.
Chissà cosa viene fuori ad installare il sistema sulla torre di ingegneria?
Finalmente un Spyserver anche a casa. Ho trovato una vecchia scheda Odroid XU3 che ha richiesto un po’ di coccole prima di potere essere messa in produzione. La XU3 è un bel Single Board Computer (SBC), dotato di due processori quad-core:
processor : 7
model name : ARMv7 Processor rev 3 (v7l)
BogoMIPS : 120.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc0f
CPU revision : 3
Il problema principale è trovare una distribuzione che supporti un Kernel “decente”, almeno 4.x . Sul sito di riferimento del prodotto si trovano delle immagini piuttosto recenti e dedicate al prodotto XU4. Per rendere usabile questa immagine sono necessari alcuni step aggiuntivi che sono descritti in questo articolo. Alla fine di tutto il procedimento il sistema funzione, manca solo di installare spyserver:
Messo in esecuzione il software, il carico sulla CPU è piuttosto esiguo.
[DISPLAY_ULTIMATE_SOCIAL_ICONS]
Finalmente ho installato il preamplificatore che avevo acquistato su Aliexpress per i 1090MHz, da associare al mio sistema di ricezione ADS-B.
Il cambiamento di prestazioni è notevole: sono passato da una distanza massima ricevuta di 100 miglia nautiche ad oltre 180, con picchi superiori a 200.
Anche il numero di aeromobili “visti” dal sistema è notevolmente aumentato, passando da circa 700 a valori sopra il 1000. Considerando il cablaggio “creativo” sono davvero molto soddisfatto del miglioramento ottenuto!
Nella immagine che segue, la situazione del ricevitore “fotografata” il 14 giugno 2017.
Per attivare una stazione di ascolto presso la Torre della Facoltà di Ingegneria dell’Università Politecnica delle Marche, ho dovuto rimettere le mani su dei vecchi filtri in cavità che erano stato acquistati per il progetto iRGP negli anni 90. Ricordo che, all’epoca li avevamo tarati utilizzando un bell’analizzatore di spettro con tracking generator.
Dovendo ritarare il sistema per adattarlo alle nuove condizioni operative (WebSDR, ne riparleremo) ho deciso di procedere in un altro modo, soprattutto per evitare di scarrozzare l’analizzatore di spettro in giro per la Facoltà. Mi sono servito di un noise generator e di un ricevitore SDR.
Il noise generator è un prodotto molto semplice ed economico, acquistato per pochi dollari su ebay. Lo avevo acquistato alcuni anni addietro per fare delle prove di larghezza di banda su una IF.
Il ricevitore SDR è il famoso AIRSPY MINI, corredato da una versione aggiornata di SDR# e dall’utilissimo SpectrumSpy. Questo programma trasforma il ricevitore SDR in un analizzatore di spettro a larga banda e consente di fare delle misure piuttosto interessanti, anche se piuttosto limitate in dinamica ed in tempo di risposta.
Nelle due immagini che seguono, la risposta in frequenza del filtro in cavità prima della taratura e dopo la taratura.
Scegliendo in modo opportuno lo “span” dell’analizzatore è possibile ottenere una risposta del sistema molto rapida, che consente di apprezzare facilmente le minime variazioni di taratura.
PMSDR is a small, cheap and high quality SDR Receiver. It was conceived by Martin Pernter Iw3AUT some years ago. I have been using it for both hobby and scientific research, loving its stability and ease of use.
After a long time, during which the receiver collected dust on a shelf in my office, I decided to bring it again to life for the WebSDR project. I’ll not give details on the work of PA3FWM, please visit its site to learn about its work.
The WebSDR project is addressed both to hamradio enthusiast both to students of the University where I work. SDR technologies are wide spread and it’s time to talk about this subject in the telecommunications oriented courses that are held at University. So I think that the possibility to show some real application of SDR can support the learning path of students, trying to catch their curiosity.
Phase 1 of the projects requires to setup a basic system, using PMSDR and RTL-SDR dongle in order to evaluate performances and get acquainted with WebSDR software.
RTL-SDR.
Configuring the dongle to work in WebSDR is quite easy. It requires the installation of rtl-sdr package in order to provide rtl_tcp command.
After connecting the dongle to the PC, you can check it has been correctly recognised with the lsusb command.
websdr@websdr:~$ lsusb
Bus 002 Device 002: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T
In order to let the dongle receive and forward data, you can use the rtl_tcp program. It will create a socket and stream I/Q samples through it. Put this command in your rc.local file to execute it as a daemon during computer boot.
rtl_tcp -a 127.0.0.1 -p 65144 -f 145000000 -d 0
Remembre that if you want to change the receiving frequency, you have to modify THIS script, otherwise nothing will happen. The command stated shows -p switch, in order to set the streaming port, the -f to set the working frequency and -d to address a specific device in case you have multiple dongles.
WebSDR configuration lines for RTL-SDR are very simple:
#rtl_sdr per i 3cm
band 3cm
device !rtlsdr 127.0.0.1:65144 85
samplerate 2048000
centerfreq 681000
antenna lnb
The “85” shows the amount of ppm correction to apply in the frequency.
PMSDR
Setting up the PMSDR may be a little “tricky”. First of all you have to consider this is a “near-zero IF SDR”: it will provide an audio baseband signal to a sound-card. First of all you have to setup an ALSA sound system. If you (like me) are not very familiar with Linux audio world, well “don’t panic”. The sound-card I use with PMSDR is USB connected. So let’s check it:
websdr@websdr:~$ lsusb
Bus 002 Device 002: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 002: ID 041e:30df Creative Technology, Ltd
Now it’s time to hadle permissions for using the soundcard:
websdr@websdr:~$ cat /etc/udev/
hwdb.d/ rules.d/ udev.conf
websdr@websdr:~$ cat /etc/udev/rules.d/90-creative.rules
ACTION==”add”, SUBSYSTEM==”usb”, SYSFS{idVendor}==”041e”, SYSFS{idProduct}==”30df”, GROUP=”audio”
websdr@websdr:~$
Now you should be able to use the “magic” command:
websdr@websdr:~$ arecord -l
**** List of CAPTURE Hardware Devices ****
(…)
card 1: Pro [SB X-Fi Surround 5.1 Pro], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
Before trying to go any further is mandatory to check if ALSA can support your hardware. In any other case all your efforts will result in a total loss of time. According to ALSA site, the SB X-Fi in UNSUPPORTED.
So let’s give up and try another Audio Adapter, this time embedded device:
root@websdr:~# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 2: ALC662 rev1 Alt Analog [ALC662 rev1 Alt Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
WebSDR configuration file wants to know 3 parameters: card,device, subdevice. Using this command we can retrive all data we need, as the card number is “0”, the device is “0” and the device is “0” as well. Write this parameters and forget them.
Now you need a way to interact with PMSDR internal PIC in order to program the internal oscillators. More over, if your PMSDR is equipped with a Downconverter board, you have to program it as well. There is a small,yet realiable and easy-to-use, client which was written by Andrea Montefusco and is available on sourceforge. You have to build it, so install gcc and read carefully the installation notes. After the program has been built, run it by “pmsdr”. There is an embedded help system.
Linux PMSDR 2.0/2.1 control program, version 2.5.1
Original code by Martin Pernter IW3AUT
Linux porting by Andrea Montefusco IW0HDV
www.obdev.at – DG8SAQ-I2C
Interface 0 claimed.
Firmware reports version 2.5.0
Si570 detected.
CY22393 detected.
Downconverter Board detected.
Si570 on Downconverter Board detected.
Type ‘help’ or ‘?’ for get online help.
/tmp/PMSDRcommands FIFO unavailable [No such file or directory]
Input switched to standard input.
—> help
<command> [<value>] //
FREQUENCY : f <d> // f 7050000 == ( 7.050,000 kHz)
F3Harmonic : f3 <d> // f3 100300000 == ( 100.300 MHz)
FREQUENCY Dc : fd <d> // down converter conversion frequency in Hz
FILTER : filter <d> // 0 (no filter),1 (2-6MHz),2 (5-12MHz),3 (10-24MHz), 4 (<2MHz)
DFILTER : dfilter <d> // 0 (down converter bypass), 1 (VHF filter), 2 (UHF filter), 3 (unfiltered)
QSDbias : qsdbias <d> // qsdbias 512 (default), 346-692 (interval allowed)
QSDmute : qsdmute <on,off> // qsdmute on, qsd off (i.e. 0,1
STOREfreq : memf <d> // store init freq into PMSDR EEPROM f 585000 == (585,000 kHz)
STOREfreq3 : memf3 <d> // store init f3/3 into PMSDR EEPROM
RESTORE freq : rmemf // restore init freq from PMSDR EEPROM
PRINTlcd : plcd <col> <row> <message_text> // print the message text at specified coord on the LCD
QUIT : quit // exit from pmsdr
HELP : help // this help!
INPUT-SEQUENCE-example:
->help,filter 4,f 1611000,f 585000,memf 585000,filter 0,f3 100300000,quit
In order to set PMSDR for 2m reception you need to program downconverter first:
dfilter 1
fd 116000000
In this way 144MHz is downconverted to 28MHz. So the next step is
filter 0
f 28000000
save it!
memf 28000000.
Now let’s go back to WebSDR and let’s write some configuration for PMSDR as well:
#pmsdr per i 2m
band 2m
#alsa devices are: card/dev/subdev
device $hw:0,0,0
samplerate 96000
centerfreq 144320
Some screenshot taken with lab equipment, showing the receiver busy in demodulating a carrier at 144.290 MHz (frequency choosen where the waterfall was clean).
So the work is over. Everything should be fine and you should be able to run the server. I’m still very disappointed that I was unable to use a better soundcard. I did some testing with a PCI M-Audio Audiophile 2496 but I was unable to let it work.
Finalmente è arrivata!!!
(questo articolo è in attesa di essere pubblicato dal 3 ottobre 2016)
Packaging minimale, ottima imbottitura, grande protezione e dentro la chiavetta! Completamente in alluminio, con un bel connettore SMA femmina installato. Il tempo di collegarla al PC e già funziona. Non richiede driver o procedure perverse di installazione. Davvero un dispositivo Plug ‘n Play.
Ho scaricato l’ultima versione di SDR# ed ho avviato la ricezione: eccellente! Il front-end è meno predisposto alla intermodulazione, lo spettro visualizzato è pulito ed i segnali si vedono decisamente peggio.
Forse lascia sul terreno qualche cosa in termini di guadagno: le conversazioni su satelliti MIL a 256 MHz non riesco a riceverle, ma sono piccoli dettagli.
La possibilità di visualizzare una porzione molto ampia di spettro è fantastica ed apre la scena a numerose applicazioni, anche in ambito didattico. Ecco qualche screenshot di SDR# della simpatica applicazione “analizzatore di spettro” che vedo molto bene in congiunzione con il generatore di rumore ad ampio spettro per fare qualche prova sui filtri in cavità. Antenna televisiva, in paese. La prima con 100MHz di span e la seconda in full Bandwidth.
Costa… vero… ma ne vale davvero la pena!!!