Quando scrivo un articolo di solito tendo sempre a non dare per scontato quello che vado a descrivere, per questo motivo farò 2 accenni ai prodotti a cui faccio riferimento, e successivamente come abbinarli correttamente fra loro.
E’ un comodo servizio che è in grado di fornirvi accesso al vostro pc/server/raspberry, con sistema operativo gnu/linux, anche se questi sono collegati dietro una rete che non vi fornisce un ip pubblico, quindi quando il dispositivo è dietro una rete non raggiungibile direttamente dall’esterno (es. connessione tramite 3g, o wisp che non forniscono ip pubblico).
Dopo essersi registrati viene fornito uno script python con un token univoco che, una volta lanciato sul dispositivo, installerà il necessario per il funzionamento e, in fine, vi fornirà accesso alla porta 22 SSH e 80 HTTP tramite un tunnel gestibile direttamente dal vostro browser collegandosi alla loro interfaccia web (è disponibile anche un app per ios/Microsoft Store/android).
il primo dispositivo è gratuito, mentre per gli altri dovrete pagare un abbonamento.
Inutile dilungarsi troppo su questo prodotto noto a tutti i radioamatori, attualmente è lo “standard de facto” per gestire modem e gateway digitali radioamatoriali (hotspot o ripetitori), il tutto comodamente da interfaccia web leggera e veloce.
Fatte le dovute premesse, passiamo al “problema”.
Come molti di voi avranno avuto modo di valutare, PI-STAR è in grado di mantenere la propria “solidità” e garantire all’utente un funzionamento “out-of-the-box” grazie al proprio “recinto” costruito attorno al sistema operativo; vale a dire che, pur essendo un sistema operativo basato su raspbian (debian per raspberry), e pur mantenendone tutte le caratteristiche funzionali, gli sono stati creati di proposito dei vincoli da parte dello sviluppatore per evitare che un intervento sul sistema da un utente più smaliziato possa comprometterne il funzionamento e l’installazione dei futuri aggiornamenti che vengono periodicamente rilasciati.
Questi vincoli implicano, fra l’altro, filesystem in sola lettura di default, specifici permessi a file e directory, script che ad ogni riavvio ripristinano file all’interno di specifiche directory, e proprio su quest’ultimo punto mi soffermerò nelle prossime righe.
La prima volta che ho provato ad installare dataplicity su pi-star ho riscontrato una spiacevole anomalia, infatti il dispositivo restava raggiungibile solo fino a quando non si effettuava un riavvio del sistema, a quel punto non era più possibile in alcun modo ripristinarlo.
Non vi nego che, per mancanza di tempo e anche per un pizzico di pigrizia, inizialmente l’escamotage fu abbastanza bizzarro e insolito, ma di rapida soluzione, infatti per un periodo facevo disinstallare l’agent e reinstallarlo automaticamente ad ogni avvio del pi-star, ma questo comportava un ritardo notevole all’avvio del sistema e un deciso grado di complessità che non giovava certamente alla stabilità, ma successivamente ho indagato dando una rapida occhiata ai log e su cosa accadeva al PI-STAR durante il riavvio.
La conclusione è stata fortunatamente molto semplice, il servizio di dataplicity che fornisce il tunnel chiamato supervisor, genera i suoi file di log di default in /var/log/dataplicity , tutto normale direte, se non fosse che pi-star ad ogni riavvio si prende il disturbo di eliminate dai log tutto quello che non fa parte del suo default, fra cui anche la directory in questione, e ovviamente supervisor non riusciva più a partire non trovando più il percorso dei log.
Fortnatamente il servizio supervisor prevede un file di configurazione che trovate in /etc/supervisor/supervisord.conf
Aprendolo vi troverete un file simile a questo, e come potete notare dalle righe evidenziate, ho modificato il percorso su cui il servizio va a scrivere i log /var/log/dataplicity/supervisord.log semplicemente eliminando la directory dataplicity e facendo scrivere i suoi log direttamente in /var/log
; supervisor config file[unix_http_server]
file=/var/run/supervisor.sock ; (the path to the socket file)
chmod=0700 ; sockef file mode (default 0700)[supervisord]
logfile=/var/log/supervisord.log ; (main log file;default $CWD/supervisord.log)
pidfile=/var/run/supervisord.pid ; (supervisord pidfile;default supervisord.pid)
childlogdir=/var/log ; (‘AUTO’ child log dir, default $TEMP); the below section must remain in the config file for RPC
; (supervisorctl/web interface) to work, additional interfaces may be
; added by defining them in separate rpcinterface: sections
[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface[supervisorctl]
serverurl=unix:///var/run/supervisor.sock ; use a unix:// URL for a unix socket; The [include] section can just contain the “files” setting. This
; setting can list multiple files (separated by whitespace or
; newlines). It can also contain wildcards. The filenames are
; interpreted as relative to this file. Included files *cannot*
; include files themselves.[include]
files = /etc/supervisor/conf.d/*.conf
Una volta garantito un percorso valido per i log, tutto torna a funzionare regolarmente ad ogni riavvio.
Buona sperimentazione e al prossimo………”problema”
Stavo provando il nuovo RASPBERRY PI 3B+, la nuova versione con il SOC in metallo, poche (e inutili)le migliorie rispetto a classico 3B in verità!
in pratica 200Mhz di clock in più (ne avevamo sul serio bisogno?), LAN GIGABIT (finta, è sempre su bus USB2 e oltre 300Mbit non si va!), POE (si bello…..ma solo con accessorio opzionale!); io onestamente avrei barattato tutte le nuove caratteristiche con un bel GB di ram in più, ma niente!
Comunque vado a collegarci una delle mie fide MMDVM_POG ed ecco l’amara sorpresa……il raspberry non da alcun cenno di boot, o segno di vita a monitor, in pratica solo led rosso acceso!
Inizialmente ho pensato a una sd corrotta o che fosse l’immagine di PI-STAR beta a creare il problema, ma poi ho provato a rimuovere la MMDVM_POG dalla GPIO ed ecco che per magia si avvia correttamente! Bene………non resta che indagare allora!
Faccio una prolunga fra la GPIO e il connettore della POG, e provo a scollegare un pin alla volta (tranne ovviamente +5 GND TX RX) ed ecco la sorpresa………3V3……….si i 3,3Volt se connessi fra la POG e la GPIO bloccano l’avvio della scheda!
Per ora il consiglio che posso darvi e di dissaldare o comunque scollegare quel pin se volete che funzioni anche sulla 3B+, ma nel frattempo indagherò ulteriormente, se dovessi avere ulteriori info le aggiungerò a questo articolo!
STAY TUNED!
E’ da un po’ che gira sul noto sito di aste online questa versione “particolare” di MMDVM, e incuriosito me ne sono fatta arrivare una dagli amici asiatici.
Di cosa si tratta? Beh a prima vista ricorda la MMDVM-PI ufficiale, ovvero la versione MMDVM senza ARDUINO DUE che si monta direttamente come shield su RASPBERRY PI, ma in effetti ci troviamo di fronte ad un altro progetto, più semplificato ma altrettanto efficace, la MMDVM_POG, che prende il nome dal suo ideatore SQ6POG.
Le differenze sostanziali fra le 2 board sono innanzitutto le CPU, tutte e 2 delle ARM CORTEX a 32 Bit (e ovviamente nessuna delle due monta cpu ATMEL AT91SAM3X8E da 84Mhz di ARDUINO DUE) che condividono il produttore della CPU (ovvero STMicroelectronics), ma modelli differenti; infatti la MMDVM-PI monta una performante cpu serie ST32F4xx da 180Mhz mentre la POG un ST32F105 dai modesti 72Mhz; l’altra differenza è sulla parte di filtraggio, la POG è molto più simile a una MMDVM SHIELD classica, ma tolto questo le differenze sono praticamente terminate.
La MMDVM_POG si presenta con una serie di led di stato che indicano, fra le altre cose, la modalità di funzionamento (DSTAR, DMR, YSF, P25) ad eccezione della nuova NXDN non ancora presente al momento della progettazione del pcb; oltre a questi è presente ovviamente un led di stato alimentazione, di attività sulla seriale, uno di ricezione, uno di trasmissione e quello dello stato del PTT. Sono presenti i soliti 2 trimmer per la regolazione hardware dei livelli di ingresso e di uscita, il pinout di tipo “dupont” con i collegamenti necessari per collegare uno o 2 RTX incluso RSSI (schema come da foto), un jumper per abilitare il bootloader del micro per programmarlo (che vedremo in seguito), sulla mia versione è stato anche installato un TCXO da 19,2Mhz per garantire la stabilità della cpu in condizioni di temperature alte. Leggi il resto di questo articolo »
Chiunque ha a che fare con misurazioni di antenne in ambito radioamatoriale e non, conoscerà sicuramente il Mini Vector Network Analyzer, scelto per il suo costo contenuto e per le sue prestazioni che non hanno nulla da invidiare a quelle di analizzatori di antenne più blasonati (RIGEXPERT, MFJ); disponibile in versione standard o pro, questo simpatico analizzatore ha solamente un grosso handicap…non è standalone, necessita infatti di un PC ad esso collegato per farlo funzionare, questo con tutti i problemi e la scomodità che ne derivano.Ecco quindi che il collega Dan (YO3GGX) ci viene in soccorso con BLUEVNA, un’applicazione per android 2.2 o superiori in grado di interfacciarsi con il dispositivo attravesro il bluetooth e di interagire con tutte le sue funzionalità (SWR, |Z|, Return Loss, Phase, Rs, |Xs| per miniVNA e signed Xs per miniVNA Pro), permette il salvataggio e l’esportazione di dati nella memoria del tablet/telefono in formato CSV, ZPLOTS ed S1P e di salvare screenshot in formato PNG, permette di calibrare l’analizzatore per ogni sua funzionalità, sia che lo usiate come analizzatore di antenna o per la creazione/taratura di filtri o misurazione di cavi, memorizzando le calibrazioni in modo da riutilizzarle in futuro senza doverle ripetere ad ogni avvio.
Il software è in versione 0.6beta al momento in cui viene redatto questo articolo, è disponibile gratuitamente nel play store di google o dal sito di Dan; purtroppo al momento non supporta l’EXTENDER, quindi è in grado di misurare frequenze fino a 180Mhz (200Mhz per il pro), ma Dan nel suo forum non nega la possibilità futura di supportarlo.
Di seguito il link al sito di Dan yo3ggx dove potrete trovare, in oltre, software per android per gestire remotamente via bluetooth radio della famiglia FT-8X7 della YAESU, e info su interfacce host CAT<>BLUETOOTH per gli stessi e anche per il minivna standard, sprovvisto di tale funzionalità, per poterlo usare remotamente wireless come il PRO.
Mi è capitato in questi giorni di imbattermi in discorsi con amici non radioamatori che asserivano di usare un sistema di comunicazione con i loro PMR chiamato FREE RADIO NETWORK, che permetteva l’utilizzo del pc o di comuni radio PMR legalmente dichiarate al Ministero Delle Comunicazioni per comunicazioni attraverso dei gate voip con un apposito software strutturato stile chatrooms; io ho subito manifestato scetticismo e mi sono congedato per informarmi meglio.
Il primo approccio con il sito sembra buono, infatti tengono subito a precisare la legalità della loro attività, infatti specificano che si possono utilizzare esclusivamente radio di libera vendita e con le eventuali rispettive licenze, e che queste non devono avere alcuna modifica non permessa dalla loro regolamentazione, quindi sono ammessi LPD, SRD, PMR, CB 27Mhz, queste ultime due con il pagamento dei 12 euro e della regolare concessione ministeriale, inutile dire che si possono usare anche radio radioamatoriali con licenza radioamatoriale, a patto che tutti questi dispositivi operino sulle rispettive frequenze legalmente concesse.
Mi sono poi soffermato su un punto, quello in cui parlano dell’uso del sistema con una radio collegata al pc tramite apposita interfaccia, e di creare un gateway con un ripetitore simplex accessibile a tutti attraverso questa radio connessa al PC, e a questo punto il mio cervello ha fatto delle considerazioni……
Il sistema permette l’utilizzo di radio connesse a un PC, quindi a tutti gli effetti in quel momento si sta realizzando un ripetitore simplex connesso a un gateway internet, cosa che, a norma di legge, è realizzabile ESCLUSIVAMENTE da associazioni a carattere nazionale legalmente costituite, cito testualmente il DECRETO DEL PRESIDENTE DELLA REPUBBLICA 5 ottobre 2001, n.447
Art. 41. – Stazioni ripetitrici
1. Le associazioni a carattere nazionale dei radioamatori legalmente costituite possono conseguire, nel rispetto delle disposizioni recate dall’articolo 8, commi 1, 2, e 38, l’autorizzazione generale per l’installazione o l’esercizio:
a) di stazioni ripetitrici analogiche e numeriche;
b) di impianti automatici di ricezione, memorizzazione,
ritrasmissione o instradamento di messaggi;
c) di impianti destinati ad uso collettivo.
2. L’installazione o l’esercizio di stazioni di radiofari ad uso amatoriale sono soggetti a comunicazione; la stazione deve essere identificata dal nominativo di cui all’articolo 37 relativo al radioamatore installatore seguito dalla lettera B preceduta da una sbarra.
Per farla breve, solo associazioni a carattere nazionale possono installare stazioni ripetitrici autonome previa richiesta di autorizzazione, con tanto di scheda tecnica del ripetitore/radio in uso e il rilascio di relativo nominativo di stazione, e devono ESCLUSIVAMENTE attenersi al piano di frequenze assegnato dal ministero; quindi, nessun cittadino, radioamatore o meno che sia, può installare a casa o in qualsiasi luogo stazioni ripetitrici autonome non presidiate, figuriamoci ripetitori su altre frequenze, che non prevedono neppure l’utilizzo di un ripetitore.
In sostanza, l’utilizzo di comunicazioni via PC è consentito, l’utilizzo del sistema mediante gateway simplex collegando una radio invece NON è concessa, a maggior ragione non è concessa su frequenza dove l’uso di ripetitori non è neppure regolamentata, ed è un discorso valido anche per altre forme di comunicazioni radioamatoriali come ECHOLINK o similari.
Questo è quanto….a voi le considerazioni….
Oggi ho finalmente ricevuto la tanto desiderata interfaccia DUTCH STAR MINI HOT SPOT nella sua ultima revisione hardware e software.
Per chi non sapesse di cosa si tratta, abbiamo avanti una completa soluzione D-STAR da interfacciare a una comunissima radio analogica VHF/UHF e ad un banalissimo PC.
Come si nota dalla foto, è di ottima fattura, comprende un pic con il firmware di gestione della scheda stessa, un convertitore MAXIM USB<>RS232, e per ultimo, ma non per importanza, il modulatore GMSK CMX589AD2, il cuore del sistema D-STAR!
Il modulo viene fornito di una manualistica in lingua inglese molto accurato, e con un foglio di licenza, infatti il codice sorgente del PIC on board non è open, tuttavia la licenza è cedibille in caso di vendita (infatti viene assegnata al nominativo dell’acquirente), e si ha un anno dal momento del download e dell’attivazione della licenza per scaricarsi aggiornamenti gratuiti del firmware, dopo si potranno acquistare separatamente.
E’ possibile utilizzarla per fare un repeater standalone, collegando 2 radio e lasciando al pic il compito di commutare e decifrare, oppure con l’ausilio di un pc e con una sola radio per realizzare un hot spot gateway connesso su internet.
I software utilizzabili per taratura e test dell’apparecchio sono disponibili sia per windows che per linux, e per entrambi in architettura 32 e 64 bit, è comunque compatibile con tutti i software funzionanti con la scheda SATOSHI da cui il progetto prende spunto.
Al momento ho effettuato solo i test di echo e di taratura avvalendomi di un RTX ICOM IC-706MK2g connesso alla dutch star e un ICOM IC-E92D come radio D-STAR; le operazioni di taratura hanno comportato non pochi problemi, infatti i livelli di ricezione e trasmissione sono molto delicati e variano da radio a radio, prima di sentire della voce uscire dalla radio e non un fastidioso fruscio ci vorranno tante micro tarature ai trimmer dei livelli sulla board.
Prossimamente proverò un server linux connesso ad internet tramite una internet key in altura per iniziare a testarlo realmente sul campo!
Per qualsiasi domanda contattatemi pure usando l’apposito FORM!
Per acquistare la scheda il link è http://www.dutch-star.eu/
STAY TUNED!