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!).