Archivi tag: rtl-sdr

Davis Instruments ed rtl-sdr

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.


Ogni scusa è buona!

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.

Schema a blocchi originale, credit a znuh
Schema a blocchi modificato per Adalm Pluto

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.

Output per programma in C, credi znuh
Output del programma GRC, modificato per vedere anche la banda base.
Output di Wireshark, con i pacchetti DECT.

Si potrebbe decodificare anche l’audio ma, sinceramente, non ne ho la minima voglia!
Il nuovo GRC si può scaricare da qui.

rtl_433

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.

Universal Radio Hacker alle prese con il segnale in banda base.

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.

Posizione dei sensori nella banda 433MHz.

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.

Sensori ricevuti e parametri, in forma tabulare.

Grafico dei parametri fisici e radioelettrici:

Andamento della temperatura.

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.

RSSI nel tempo.

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?

Spyserver – Test 1 Failed!

Ho provato ad installare ed a fare girare Spyserver sulla cubieboard che ho installato in soffitta. Mi sarebbe piaciuto potere avere un “punto” di ascolto remoto a casa.

Il software sulla cubieboard 2.0 con il nuovo “armbian” si configura che è un piacere. Tuttavia ho riscontrato i seguenti problemi:

  • spyserver non va molto d’accordo con fr24feed, collide un modulo del kernel. Per fare la prova ho dovuto disabilitare momentaneamente il feed del mio ricevitore ADS-B.
  • Le prestazioni del sistema sono insufficienti. Spyserver si avvia correttamente, accetta la connessione ma, anche riducendo all’osso i parametri, l’audio è fortemente frammentato.

Morale della favola: nulla da fare. La CPU della Cubie non ce la fa a gestire il carico. Pertanto devo inventarmi qualche cosa che non sia “comperare una Odroid”. Fino ad ora le prestazioni migliori le ho ottenute con una AIRSPY Mini collegato direttamente al mio desktop, ma si tratta di un I5 con 16GB di ram, pertanto di potenza e memoria ce ne sono da vendere!

[DISPLAY_ULTIMATE_SOCIAL_ICONS]

Gli aeroplani

La mia prima esperienza con la decodifica del sistema ADS-B risale a qualche anno fa. Avevo giocato con un bellissimo ricevitore della Kinetic Avionic e con il suo programma Basestation.

Mi sono nuovamente cimentato con questa attività, mettendo in campo una chiavetta basata su RTL2832U e tuner 802T. L’antenna è (udite udite…) autocostruita, realizzata qualche anno fa e lasciata a fermentare sul davanzale dell’ufficio. Lo schema è quello presentato sul numero di Aprile di RadioKit Elettronica da Alberto Zanutto. Lo schema si trova anche in giro per la rete.

 

Il tutto è collegato alla ormai immancabile Cubieboard che funge da server. Per fare delle prove in locale ho usato il software rtl_adsb, che restituisce tutti i dati raw. Dopo queste prime prove, ho rediretto l’output del programma su un socket:
rtl_adsb | netcat -lp 8080

PLanes_03

Per decodificare i dati RAW ho trovato un fantastico programma scritto da Joerg Bredendiek. Questi mantiene un sito davvero ricchissimo di  informazioni, che vi invito a visitare (anche se la lingua potrebbe essere un ostacolo). Il software da lui scritto si chiama adsbscope27 e si può scaricare da qui. Funziona molto bene e consente anche la connessione come client di rete.

Dopo qualche ora di funzionamento sono riuscito a ricevere moltissime informazioni e mi possono davvero ritenere soddisfatto. Considerando la PESSIMA posizione della mia antenna e della mia casa, riuscire a ricevere qualche cosa è davvero un miracolo.

PLanes_02

E adesso? Adesso sto pensando di mettere i dati a disposizione del sistema flightradar24, in quanto la ricezione in questo modo è divertente ma… dopo che ho visto che funziona… mi annoia!

Buon divertimento!!!

Sdr Server

Qualche tempo addietro, un radioamatore della zona (IW6ATQ) mi ha fatto vedere un software davvero interessante. Si tratta di una suite client server, mirata all’utilizzo di apparati SDR in rete.

Il software in questione è rilasciato da sdr-radio.com e si tratta della suite SDRconsole ed SDRserver in versione v2.

Test bed la composto dalla solita chiavetta RTL2832 con chipset 820T, collegata ad un calcolatore con processore ATOM, un ABACO che ha ormai parecchi anni sulle spalle ma li porta benissimo. Su questa piattaforma gira un sistema operativo Microsoft t 32bit. Ho installato tutto il software necessario ed avviato la utility rtl_tcp. Concettualmente è molto semplice: rtl_tcp invia i dati al server SDR, il quale provvede a effettuare la loro distribuzione ai client che si connettono. Il comportamento del server può essere ottimizzato per sfruttare al meglio le caratteristiche della connessione di rete.

1  4

Mi sono messo a giocare un po’ con questo sistema nella rete locale, caratterizzata da prestazioni di tutto rispetto. Le prime prove mi hanno lasciato davvero stupito: audio molto intermittente e lentezza nella risposta ai comandi. Dopo essermi connesso al calcolatore remoto ho scoperto che le risorse di CPU necessarie per fare girare il software dignitosamente sono eccessive per la potenza di calcolo di cui dispongo. Se la CPU sale sopra il 40% la qualità di ricezione cala molto, soprattutto cercando di ascoltare un WFM. Dopo avere ridotto molto la dimensione della FFT le cose sono migliorate un poco, anche se l’esperienza di uso è rimasta molto deludente.

Nulla da eccepire sul software, molto ben studiato sial lato client che server. Ha una struttura a pannelli che richiede un minimo di assuefazione ma è discretamente intuitivo da utilizzare. Una volta effettuata la connessione, sembra di usare un sistema residente localmente (soprattutto lavorando in banda stretta).

2 3

Il risultato grafico dell’ascolto (o tentato tale) di una emittente FM stereo è il seguente:

5

Morale della favola, un ottimo prodotto che, se abbinato ad un calcolatore di nuova generazione, sarà in grado di offrire ottime prestazioni e tante ore di divertimento!

 

 

ADS

Acronimo di Automatic Dependent Surveillance è una tecnologia, ormai ben nota, attraverso la quale gli aerei trasmettono in broadcast alcuni dettagli sulla loro posizione. I segnali sono trasmessi a 1090MHz e fino a qualche anno addietro erano ricevibili attraverso apparecchiature piuttosto costose prodotte dalla Kinetic Avionics. Adesso basta una chiavetta basata su RTL 2832 dal costo di 12 euro,  un antenna ed un filtrino per potere fare esperienza in questo senso.

Ho provato anche io a cimentarmi con questa ricezione, memore dei bei risultati ottenuti con il ricevitore SBS-1 che avevo usato tanti anni addietro. Il programma che ho usato lo ho scelto da questo sito ed è RTL1090. Si tratta di un ricevitore dedicato che effettua uno streaming dei dati attraverso porte TCP o UDP. Per la visualizzazione dei dati occorre avere un altro software che li riceva e li presenti all’utente. Per questo ho usato VirtualRadar, programmino che si configura in 10 minuti e funziona alla perfezione.

ads_02

Ho iniziato una sessione di ascolto in ufficio e, dopo  un po’, sono riuscito a visualizzare i miei primi aerei.

ads_01

Poca, pochissima cosa, ma sono con una antenna interna, e 5 metri di RG58.

DSC_1181

Ho riprovato da casa e non sono riuscito a combinare nulla. I motivi sono molteplici.  A casa ho l’antenna sul tetto, ma è una bibanda per 144MHz/430MHz. Non ho idea di come si possa comportare a 1 GHz. Il cavo che uso è un RG213 (ne ho circa 20 metri) che i suoi 5-6dB se li mangia sicuro. Il codino di connessione è realizzato con 1m di RG58 che ne perde almeno un’altro. Morale della favola: sarebbe strano se arrivasse qualche segnale!

SDR# sempre più forte.

Questa mattina ero alla ricerca di un modo per potere ricevere più canali contemporaneamente con SDR#. Mi sono imbattuto in questo sito che presenta solo plug-in per il software SDR#.

Il sito è in Russo, ma google translate consente una facile lettura in Inglese. Dopo qualche lettura mi sono deciso ad utilizzare l’installer proposto dal sito ed a inserire tutti  i plugin nella mia versione di SDR#. L’installer ha fatto bene il suo dovere ed ha richiesto solo un intervento manuale per configurare i VFO multipli, andando ad editare il file “Plugins.xml”.

<sharpPlugins>
    <add key="IQ Balancer" value="SDRSharp.IQCorrection.IQCorrectionPlugin,SDRSharp.IQCorrection" />
    <add key="Noise Blanker" value="SDRSharp.NoiseBlanker.NoiseBlankerPlugin,SDRSharp.NoiseBlanker" />    
    <add key="BasebandRecorder" value="SDRSharp.BasebandRecorder.BasebandRecorderPlugin,SDRSharp.BasebandRecorder" />
    <add key="TimeShift" value="SDRSharp.TimeShift.TimeShiftPlugin,SDRSharp.TimeShift" />
    <add key="DSD" value="SDRSharp.DSD.DSDPlugin,SDRSharp.DSD" />
    <add key="DCSDecoder" value="SDRSharp.DCSDecoder.DCSDecoderPlugin,SDRSharp.DCSDecoder" />
    <add key="CTCSSDecoder" value="SDRSharp.CTCSSDecoder.CTCSSDecoderPlugin,SDRSharp.CTCSSDecoder" />
    <add key="Digital Audio Processor" value="SDRSharp.DAP.DAPPlugin,SDRSharp.DAP" />
    <add key="Digital Noise Reduction" value="SDRSharp.DNR.DNRPlugin,SDRSharp.DNR" />
    <add key="Zoom FFT" value="SDRSharp.ZoomFFT.ZoomFFTPlugin,SDRSharp.ZoomFFT" />    
    <add key="AudioRecorder" value="SDRSharp.AudioRecorder.AudioRecorderPlugin,SDRSharp.AudioRecorder" />    
    <add key="Frequency Scanner" value="SDRSharp.FrequencyScanner.FrequencyScannerPlugin,SDRSharp.FrequencyScanner" />
    <add key="Frequency Manager" value="SDRSharp.FreqMan.FreqManPlugin,SDRSharp.FreqMan" />
    <add key="AuxVFO-1" value="SDRSharp.AuxVFO.AuxVFOPlugin,SDRSharp.AuxVFO" />
    <add key="AuxVFO-2" value="SDRSharp.AuxVFO.AuxVFOPlugin,SDRSharp.AuxVFO" />    
    <add key="AuxVFO-3" value="SDRSharp.AuxVFO.AuxVFOPlugin,SDRSharp.AuxVFO" />
    <add key="AuxVFO-4" value="SDRSharp.AuxVFO.AuxVFOPlugin,SDRSharp.AuxVFO" />
</sharpPlugins>

E’ un mare di roba. Lo so. Le ultime 4 righe consentono di avere 4 VFO indipendenti e di ascoltare quini 4 canali contemporaneamente ed in modo del tutto indipentente. Il front end adesso è piuttosto affollato:

Sdr_Complete

Un dettaglio sulla barra di sinistra:

Sdr_Complete1

Il breve video che segue mostra l’uso di 4 VFO per monitorare 5 canali contemporaneamente (4 VFO + VFO di sintonia). Interessante notare come, una volta agganciata la frequenza, il VFO la tracci anche al variare della frequenza centrale di sintonia.

Buon Ascolto!