La necessità...

Partendo per una breve vacanza in IF9, incerto se avrei avuto possibilità di operare dal residence, ho messo in borsa solo il fido 817, un'antenna veicolare multibanda e qualche pezzo di filo.

I pezzi di filo si sono dimostrati inadeguati a garantire la risonanza dell'antenna connessa direttamente alla radio, però con un minimo di inventiva si risolve...

I soli 5w in SSB (sì, lo so... per il QRP il CW è un must...) hanno limitato i contatti a tuttta l'Europa, ma i segnali in ingresso facavano pensare che con i canonici 100w avrei potuto lavorare tutti i continenti.

Qualche calcolo molto a spanne porta a una curva d'efficienza del genere per l'antenna, quindi una grande attenzione alla MUF è essenziale per avere risultati.

la SDR V-UHF da €30 - 2

In effetti le cose attorno a questi dongle economici si sono mosse piuttosto velocemente.

Come accade in genere gli utenti Windows hanno la vita semplificata a fronte di qualche vincolo nella flessibilità, e cominciano ad apparire le prove su strada.

Chi smanetta con GNURadio ora ha a disposizione dei comodi "mattoncini": questo è il modo per fruirne.

Intanto è utile verificare che il dispositivo venga correttamente rilevato all'inserzione:

sinager@SIRAD:~$ dmesg
...

[308285.600019] usb 1-4: new high speed USB device number 8 using ehci_hcd

Qualora lo stick non sia connesso ad una porta USB 2.0 efficiente (occhio a hub e prolunghe) il dispositivo verrà riconosciuto lo stesso, ma con un warning:

[309411.513952] usb 4-2.3: new full speed USB device number 14 using uhci_hcd
[309411.617948] usb 4-2.3: not running at top speed; connect to a high speed hub

Il warning si accompagna inevitabilmente a mancato funzonamento degli script, tipicamente con questo errore:

rtlsdr_demod_write_reg failed with -9

Come indicato nella pagina di osmocom-rtl è necessaria una versione di GNURadio recente.

Le istruzioni per compilare ci sono tutte, ma gli esempi nella pagina fanno ancora riferimento all'utilizzo del ricevitore attraverso uno scarico dei dati su un file. In effetti dopo aver compèletato l'installazione sarà disponibile un nuovo blocco in GNURadio Companion:

Connettendo un solo stick non è necessario riempire il campo "device argument" con l'indirizzo.

Adattando alla bella e meglio uno script di OZ9AEC ho messo assieme un ricevitore per la NFM e in prima battuta i risultati non sembrano male.

Sul FFT si vedono chiaramente prodotti da intermodulazione ma ciò non mi sorprende con il ricevitore collegato all'antenna esterna in parallelo agli altri ricevitori. Sicuramente con un po' di attenuazione e qualche filtro esterno le cose possono migliorare.

Nell'eventualità qualcuno sia interessato, lo schema GRC è a disposizione.

la SDR V-UHF da €30

Nelle ultime due settimane si è parlato parecchio di questi giocattoli nella comunità dei radio-smanettatori: qualcuno degli sviluppatori di V4L si è infatti accorto, più o meno per caso, che dai dongle basati sul chip RTL2832 era possibile estrarre i dati I/Q grezzi e quindi impiegarli come una SDR a larga banda.

Ogni giorno ci sono sviluppi e novità, con rilasci di software a patches.

La soluzione più avanzata oggi è quella basata su GR-baz, tuttavia non sono ancora arrivato a sperimentarla perché richiede una versione di GnuRadio precedente a quella che ho installato.

Per il momento sto facendo qualche prova con il codice messo a disposizione da quei mostri di Osmocom e uno schema GRC basato su quello di DL6KBG che si trova in questa discussione.

Per inciso il mio ricevitore è un Terratec Moxon DabStick, reperito su eBay dalla Germania per €31 inclusa spedizione.

Questi i passaggi che ho fatto per avere lo stream di dati verso Gnuradio:

1. scaricato il codice di Osmocom
2. impostato le regole per rendere il device accessibile a tutti gli utenti e non solo a root, sulla falsariga di quanto fatto per il FunCubeDongle ovvero:
   
   • una volta connesso, verificare codice produttore e id della periferica con lsusb. L'output per il DabStick è qualcosa del genere:
     Bus 001 Device 007: ID 0ccd:00b3 TerraTec Electronic GmbH
   • creare una rule per lo stesso:
     sudo nano /etc/udev/rules.d/20-rtl.rules
     contenente:
     SUBSYTEMS=="usb" ATTRS{idVendor}=="0ccd" ATTRS{idProduct}=="00b3" MODE:="0666" SYMLINK+="RTL"(notare come Vendor e idProduct riflettano quanto ottenuto con il lsusb).
     Salvare il file e aggiornare le regole:sudo udevadm control --reload-rules
3. modificato il sorgente di Osmocom (/rtl-sdr/src/main.c) in modo da scrivere l'output in una named pipe, modificando la riga 400,
   da così:   file = fopen(filename, "wb");
   a così:    file = fopen(filename, "a+b");
   e compilato
4. creato la named pipe: mkfifo out.bin
5. lanciato il comando di acquisizione:
   ./rtl-sdr ./out.bin -s 250000 -f 144800000 
6. a questo punto l'output del dispositivo non si accumula più in un file che può assumere dimensioni colossali, ma viene riversato in tempo reale in una specie di imbuto dal quale GNURadio si alimenta, a patto di mettere il file out.bin come sorgente.

Ora rimane da mettere a punto un migliore schema in Gnuradio Companion.

Come in tutti questi oggettini sembra esserci bisogno di un po' di attenuazione o filtraggio in ingresso.

infiniti passaggi

Il progetto del rotore az/el si sta trascinando da tanto tempo che sembra un po' la fabbrica di San Pietro. In realtà il poco tempo libero deve coniugarsi con una serie di elementi lunghissima da mettere in fila.

Il controller basato su Arduino deve colloquiare col pc in qualche modo, che sia seriale o usb. Dal mio shack alle antenne ci sono circa 35 metri di cavo e provare in usb non mi sembra neanche il caso. 

D'altro canto, sperando che sia ancora sano, ho ancora un cavo di rete che arriva sul tetto, dai tempi in cui giocherellavo con il wifi e avevo piazzato un WRT54 remoto. Sperando che il cavo sia ancora buono, ho rispolverato l'NSLU2 che giaceva inutilizzato nell'armadio, con l'idea di utilizzarlo come piattaforma remota cui connettere il controller.

L'NSLU2, detto anche "Slug", una volta flashato con OpenWRT supporta SOCAT, un piccolo demone che permette di fare bridging tra tcp e porta seriale. 

In questo modo:

1. sul pc in stazione gira ROTCTLD, in attesa dei comandi da qualsiasi software che supporti Hamlib;
2. ROTCTLD pensa di trasferire i comandi al controller connesso sulla porta seriale;
3. in realtà i comandi finiscono su un device virtuale creato dal client SOCAT, che attraverso la connessione di rete li manda all'NSLU2;
4. sul NSLU2 il server SOCAT riceve i pacchetti via rete, e li riversa sulla porta seriale rappresentata dall'Arduino;
5. infine il controller fa il proprio lavoro.

I comandi associati sono questi, just in case:
Slug:

socat tcp-l:54321,reuseaddr,fork file:/dev/ttyUSB0,nonblock,waitlock=/var/run/ttyUSB0.lock

PC per la creazione del device:
socat pty,link=$HOME/rotore0,waitslave tcp:<indirizzo NSLU2>:54321
Hamlib / ROTCTLD:
rotctld -m <codice rotore> -r $HOME/rotore0

Solo scoprire quale versione di firmware alternativo per l'NSLU2 fosse idonea è stata una piccola avventura in sé, essendo ormai un dispositivo obsoleto. Alcune distribuzioni non dispongono di SOCAT precompilato, mentre altre portano a dei vicoli ciechi per quanto riguarda l'installazione.

Da ultimo rimaneva da risolvere il problema del bottone on/off, giacché il simpatico apparecchietto normalmente non si riaccende da solo quando gli manchi l'alimentazione. Fortunatamente anche per questo si trovano in rete soluzioni già elaborate ed ho scelto di implementare la #10, che funziona senza problemi.

Ma come facevamo prima di internet?

Aspettavo fiducioso il lancio del RaspberryPI, con l'intenzione di compilarci hamlib e far girare direttamente tutto in remoto, ma come sappiamo la commercializzazione finora è stata un disastro. Le ultime notizie da parte di RS, che non ha concesso ordini all'Italia in prima battuta, sono che prima o poi ne potrò ordinare un esemplare (ma uno solo, eh!).

Inseguire i satelliti 2

Il progetto procede ed è ormai completamente funzionale.
Nel mezzo ci sono state alcune battute d'arresto legate a inconvenienti stupidi: per esempio un cavo dei sensori che fa contatto a intermittenza (ma non quando lo controllate col tester!) puó far perdere una settimana come niente quando avete meno di un'ora al giorno da dedicare all'hobby.
In ogni caso tutta esperienza che entra.

 Questa è la piastra nella versione finale: l'Arduino Nano si puó montare direttamente su uno zoccolo per integrati (al centro a dx). 4 led segnalano le direzioni di movimento.

I sensori sono connessi attraverso due cavetti telefonici a 4 poli che portano alimentazione e comunicazioni i2c.
In basso a sx ci sono i due SSR con il condensatore bipolare necessario al rotore.
Al centro in alto l'integrato che controlla l'attuatore in cc.

Inseguire i satelliti - 1

Mi son messo in testa di costruire un sistema a basso costo di inseguimento per i satelliti.
Il progetto avrà una sua pagina su www.tarapippo.net, quindi non espando qui perché finirei per scrivere due volte le stesse cose.
Però intanto posto un video.

Antenna civetta

Qualche tempo fa ho avuto occasione di acquistare sul mercato del surplus un'antenna risonante sulle bande dei 78 e 380 MHz e dotata di antenna GPS preamplificata incorporata. Il prodotto dovrebbe essere questo, anche se le specifiche di lunghezza non coincidono.

Per una somma di poco superiore ai €20 si portavano via, oltre all'antenna, un duplexer per quelle bande e alcuni cavi di raccordo intestati BNC e SMA. Insomma un ottimo affare.
L'antenna, verosimilmente destinata alle vetture della Polizia, è virtualmente indistinguibile da una per autoradio. Così ho pensato di adattarla per l'uso sulle bande amatoriali in macchina, fornendo meno indizi a chi sarebbe felice di fregarsi le apparecchiature installate.

I passaggi seguiti per la conversione sono descritti in questo album fotografico.