Archivi categoria: Elettronica

Spyserver su Odroid XU3

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:

  • apt-get install build-essential cmake libusb-1.0-0-dev pkg-config
  • wget https://github.com/airspy/airspyone_host/archive/master.zip
  • apt-get install rtl-sdr
  • apt install librtlsdr-dev
  • installazione di spyserver e configurazione del software.

Messo in esecuzione il software, il carico sulla CPU è piuttosto esiguo.

 

Reinstallazione Server – La storia Infinita

Ancora non sono arrivato alla fine del processo di reinstallazione della cubieboard con sistema operativo Armbian (ne ho già parlato in un mio post precedente).

Alcune note relativamente all’installazione del software necessario a fare funzionare il modulo BM280 in ambiente Armbian. Tutta l’ìnstallazione avviene utilizzando PIP ma occorre prestare attenzione alla sequenza corretta degli eventi:

  • setuptools
  • wheel
  • protobuf
    apt-get install libprotobuf-dev protobuf-compiler
  • apt-get install build-essential python-pip python-dev python-smbus git
  • Esportare le variabili:
    export MYSQLXPB_PROTOC=/usr/bin/protoc
    export MYSQLXPB_PROTOBUF_INCLUDE_DIR=/usr/include/google/protobuf
    export MYSQLXPB_PROTOBUF_LIB_DIR=/usr/lib/arm-linux-gnueabihf
  • pip install mysql-connector

Procedere quindi con l’installazione del modulo:

git clone https://github.com/adafruit/Adafruit_Python_GPIO.git
python setup.py install

Ultimo step l’installazione di jpgraph che, nelle ultime versioni di PHP da qualche grattacapo.
Come mostrato in questo post è possibile fare funzionare il modulo eseguendo una patch al file /jpgraph/src/jpg-config.inc.php : Si aggiungono queste righe:

// Patch for Debian PHP
define('ANTIALIASING', false);

if(!ANTIALIASING){
    function imageantialias($image, $enabled){
        return true;
    }
}
// End

How to dismantle a PhD Thesis

Parafrasando gli U2, mi sono dedicato alla distruzione controllata del prodotto del mio Dottorato di Ricerca. Durante lo studio ho sviluppato un sistema trasmettitore – ricevitore operante a 76GHz, per la caratterizzazione del canale in ambiente marino. Per la realizzazione avevo attinto al catalogo dei prodotti di DL2AM (Phillip Prinz) ed avevo speso una fortuna.

Dopo la fine del dottorato, gli apparati sono stati usati da un paio di tesisti e poi sono rimasti sullo scaffale, in attesa che si concretizzasse un progetto che non ha mai visto la luce. Recentemente, complice il fatto che vorrei investire dei soldi in un acquisto “sportivo”, ho deciso di smontare tutto e vendere i componenti di maggiore pregio.

A 3/4 anni di distanza, sono rimasto molto soddisfatto dello stato di conservazione del sistema e del lavoro che avevo fatto.

Alcune foto dei tempi che furono.

Setup alla “lavagna luminosa” per centraggio del lanciatore nella guida circolare:

Incollaggio dei diodi, eseguito a mano libera e con una lente di ingrandimento delle “patatine”. Lavoro poi controllato allo stereomicroscopio.

A sinistra un diodo per microonde incollato sulle sue microstrisce, a destra il diodo pronto per il trattamento. Le dimensioni sono 0.6×0.3 mm.

Lavoro di tesi (Fioritto – Spoletini) eseguito al mare, per caratterizzare il comportamento del canale in base al mutare dell’umidità dell’aria. Il ricevitore era corredato di sensori di temperatura umidità e pressione atmosferica.

Il ricevitore oggi, in fase di “disinnesco”:

Alcuni dettagli del ricevitore:

distributore di alimentazioni e telaio (la scatola gewiss è nera in quanto pitturata in grafite)

raspberry pi (notare tutti i cavi della GPIO con termorestringente) e preamplificatore 144MHz

scheda di controllo con Si570, convertitori A/D per il monitoraggio delle tensioni e del livello del segnale ricevuto

Il lavoro ultimato. Tutti i blocchi sono stati separati ed ora è il momento di recuperare i componenti attivi e passivi.

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!

Cubieboard – nuovo sistema operativo

Il mio scarso amore per questa scheda non è mai stato celato. Ritengo questo progetto davvero male gestito e male documentato. Fino a qualche settimana fa ho utilizzato un sistema operativo piuttosto datato sulla scheda, che mi ha fatto letteralmente impazzire per configurare alcuni software. Dopo due anni di onorato servizio (la CB2 sarà tosta da configurare ma è davvero granitica), ho deciso di cambiare sistema operativo. Mi sono rivolto ad ARMBIAN, in particolare alle informazioni che possono essere acquisite QUI.

Il sistema è andato su in modo meraviglioso, senza troppi problemi. Non funziona la connessione HDMI (nessuna nuova) ma il resto è perfetto. Non solo: essendo un sistema “moderno” supporta python 3 e php7 e questo ha reso del tutto inutilizzabile il sistema di gestione del meteo (amarezza e tristezza). Vale la pena di installarlo e riscrivere tutto (sigh) da capo.

ARMBIAN: segnatevi questo nome!

Esp8266 – Note!

Sono ancora al lavoro per cercare di ripristinare la stazione meteo. In questi mesi purtroppo non ho molto tempo da dedicare a questa attività, pertanto il lavoro è mostruosamente lento.

Ho montato un primo prototipo sul circuito stampato e mi sono accorto di avere omesso alcuni componenti. Nel tentativo di “metterci una pezza” ho bruciato il convertitore AD ed ho quindi deciso di ripartire da capo. Il sistema è fuori dalla scatola e, come prima cosa, lo voglio verificare completamente sul banco.

Cosa ho notato/imparato in questo periodo:

  • I test effettuati su un circuito montato su uno stampato e dentro una scatola, rischiano di essere irripetibili, devastanti ed inutili. Meglio smontare tutto e lavorare sul banco. Per fare delle prove ho messo 5V sulla linea I2C. ESP8266 non ha gradito, incenerendosi.
  • quando un MCP3424A si rompe, gli ingressi è facile che vadano a bassa impedenza. Si nota con un voltmetro che la caduta ai capi del partitore di ingresso è maggiore di quella che dovrebbe essere. Questo può accadere se il convertitore è stato alimentato una tensione eccessiva, se ha ricevuto 5V sulla I2C o una tensione eccessiva su un canale.
  • Non fidarsi dei connettori maschio/femmina a passo 2.54 (quelli che vengono usati comunemente sulle raspberry o arduino). Ho perso un paio di ore di tempo con un connettore che cessava di funzionare non appena veniva inserito il maschio al suo interno.  Provato con il tester era tutto ok, inserito il maschio il contatto si isolava. E’ un bel problema debuggare un simile fatto!
  • ESP8266 quanto effettua il boot parte a 74880 baud. Si può facilmente verificare con una programmino chiamato “minitermi.py” in ambiente linux. Dopo la fase di boot, passa a 115200, quindi non è possibile leggere correttamente il boot o la fase successiva.

 

adelmo@hp-ufficio:~/ESP8266_NONOS_SDK/bin$ sudo miniterm.py /dev/ttyUSB0 115200
— Miniterm on /dev/ttyUSB0 115200,8,N,1 —
— Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H —
{l␀$��|␀�#␂�o␌␄␌�␌$�␄c|����␓��|␒#�␌B��oN�␀$oN���␄b␜p��l{l{lp�o�␐␂␌␄�␌d␌␄␌␄␌␄c␄o�|␂l␄l��p␄��oN�␂l��␀$`␂�␓␒no␌$`␂␎␂n{���n␄␌��$`␂p�n�␐␃␄␌r�����␌␌␄␌#␌N�|␂쏞��p␄��oN�␂␌␄l ␂�␛␒oN␌$`␂␎␂nr�ےo␄␌␃�l ␃p�o�␐␂␌␄{�ܜ���d␌␄b␄o�|␃$�ی␜p␌��Nn�␂␌␌d`␃�␛␒oN␄l ␂␏␂or����␂␌␄�$l ␃␏r���␂␌␄�$l ␃{l��o܄�No����{␒non�␌l�brrd␀␌�␒�$�␒ے��␄␌␄␌␄�␌␄��$l$␡{l␀␌�␛�l$dn��␃␄␌␄␌␌␄�␄␌���l␎$␀␄�␒�$��o�␂n��o~␛␂��ll�b␌␌dlp”�␂b{���$`o$����$`#$`␂l���␂␃␄�␡␂���nd�|␒#␒␌␀␂l␄␌␄l ␃{ldon’t use rtc mem data
{l��s�
Ai-Thinker Technology Co. Ltd.

ready

 

Esp8266 – No WiFi Connection

Dopo l’allagamento della mia stazione meteo, ho deciso di riprogettare tutto il sistema. Ho quindi realizzato un circuito stampato in modo da abbandonare per sempre la realizzazione filata su mille-fori. Il PCB lo ho disegnato con Eagle e realizzato presso Millennium Dataware, come sempre. Ho dovuto correggere qualche piccolo errore derivante dalla poca attenzione e massima fretta nello sbroglio delle piste, ma tutto ha funzionato bene. Almeno dal punto di vista elettrico.

Nel momento in cui sono andato a ricaricare il firmware sulla scheda mi aspettavo un funzionamento “alla prima botta”. Invece il dispositivo si è bloccato nella fase di connessione all’access point, restituendo codice di errore “6” da WiFi.Status(). In pratica: nessuna connessione. Malgrado questo io sul’AP ero in grado di vedere il modulo come “autorizzato” o connesso. Per sbrigliare meglio questa matassa ho deciso di utilizzare un AP realizzato con una RouterBoard Mikrotik, in modo da potere approfittare delle funzionalità di logging.

Il codice che gestisce la connessione verso l’AP è il seguente:

Serial.println("");
Serial.println("WIFI INIT");
Serial.println("");
WiFi.macAddress(MAC_array);
for (int i = 0; i < sizeof(MAC_array); ++i){
sprintf(MAC_char,"%s%02x:",MAC_char,MAC_array[i]);
}
Serial.print("Unit Mac Address is: ");
Serial.println(MAC_char);
Serial.println("");
Serial.print("Connecting to ");

Serial.println(ssid);

// IP,DNS,GATEWAY,SUBNET
WiFi.mode(WIFI_STA);
WiFi.begin(ssid, password); //Gestione della connessione ad un AP
WiFi.softAP(ssidSA, passwordSA, 1, 1); //Gestione del SoftAP e hidden SSID
WiFi.setOutputPower(0); // Impostazione della potenza di uscita

while (WiFi.status() != WL_CONNECTED) {
Serial.println(WiFi.status());
delay(1000);
Serial.print(".");
}

Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());

Cercando una possibile soluzione in rete mi sono imbattuto in questo post, in cui si legge:

WL_CONNECTED is only returned if the wifi interface has connected an has IP address
in DHCP mode this means you got the IP form the DHCP server. in Static mode you have set the IP yourself.

Detto fatto: ho configurato la mia MikroTik per lavorare come dhcp server e per effettuare il NAT della rete WiFi verso la rete di casa e… funziona!

Nota bene, in caso l’assegnazione dell’IP sia statica, il codice deve essere modificato in questo modo:

IPAddress host(192,168,**,**); //used for socket,mysql,mqtt 
IPAddress ip_wifi(192,168,**,**);
IPAddress dns_wifi(192,168,**,**);
IPAddress gw_wifi(192,168,**,**);
IPAddress subnet_wifi(255,255,**,**);

void setup() {
  Serial.println("");
  Serial.println("WIFI INIT");
  Serial.println("");
  //WiFi Management
  Serial.print("Connecting to ");
  Serial.println(ssid);
   
   WiFi.mode(WIFI_STA);
   WiFi.config(ip_wifi,dns_wifi,gw_wifi,subnet_wifi);  
   WiFi.begin(ssid, password);     
   WiFi.softAP(ssidSA, passwordSA, 1, 1); 
   WiFi.setOutputPower(0);        
   
  while (WiFi.status() != WL_CONNECTED) {
    delay(1000);
    Serial.print(".");
  }

 

GPSDO quanti grattacapi!

Qualche anno fà ho acquistato una scheda Trimble 57964-15, oscillatore quarzato associato ad un ricevitore GPS. La schedina è molto interessante dal punto di vista elettrico, minimalista e molto compatta. Ha 2 uscite: segnale sinusoidale a 10MHz e PPS.

Il vero problema di questa scheda è farla funzionare nel mio ufficio (ovvero dove ho tutta la strumentazione che necessita di essere sincronizzata). Da mio ufficio io vedo pochissimo cielo e sono orientato ad OVEST.

Il povero ricevitore GPS riesce quindi a tracciare pochissimi satelliti contemporaneamente, il massimo raggiunto con notevoli sforzi è stato 4. Questo porta inevitabilmente ad un degrado delle prestazioni del sistema che non riesce ad attivare il PLL.

Leggendo in rete ho trovato che:

I think that most probably your GPSDO board didn’t finished selfsurvay mode which is signalized by fast flashing green LED. My board 57964-05 sends 10us pulse on the connector in
tracking mode. The full operati ng mode requires at least 10-15mins to get a PPS
output with good GPS signal (better forget about using indoor or window located antenna).
You can check the mode u sing terminal connected to J5 pins (57600,N,8,1) typing one of these commands:

trimble is marginally better than the lucent, but still pretty helpless with a puck antenna in a window with full view of the sky. the oscilloquartz star4 with the same antenna in the same location absolutely obliterates them both in terms of gps sensitivity and lock

Insomma… serve cielo! Bisogna che mi inventi qualche cosa per ottenere una migliore visione dei satelliti. Certo che mettere una antennina sul tetto….

 

Va bene che affoghi ma…

Recentemente ho raccontato della mia stazione meteo “allagata” dalla condensa e dall’acqua piovana. Sto cercando di ripristinarla e mi sono imbattuto in “cose mai viste”. L’ossido che si è formato è talmente consolidato che si è letteralmente “mangiato” lo stagno e molti dei contatti passo 2.54. Ci sono delle parti decisamente corrose dall’ossido. Alcuni cavetti wire-wrap che uso per le connessioni sono recisi (non so se dal corto-circuito o dall’ossido stesso). Malgrado tutto sono riuscito a ripristinare il circuito che adesso è in fase di test.

Devo assolutamente fare uno stampato!!!

 

Aiuto, affogo!

La stazione meteo è ormai attiva da qualche tempo, e ha dato enormi soddisfazioni funzionando in modo perfetto per diversi mesi.

Qualche giorno fa c’è stato un violento temporale, con tanto di allagamento del parcheggio antistante casa. In corrispondenza di questo evento la stazione meteo ha smesso di funzionare. A prima vista un problema di comunicazione I2C, visto che i dati registrati erano tutti “0”. Riavviata la stazione non c’è più stata connessione.

Mi sono recato sul tetto ed ho smontato i coperchi. Lo scempio è completo:

  • Sezione di controllo allagata, con segni di ossidazione evidenti su alcuni connettori e “condensa” sul coperchio.
  • Sezione del sensore di pioggia completamente allagata con segni di condensa anche in questo caso e pesante ossidazione.

Cosa può essere successo? La scatola del sensore di pioggia secondario è realizzata con una scatola da esterni di tipo “economico”, senza pressacavi con guarnizione. In questa scatola è entrata acqua ed umido.

La scatola è collegata alla sezione di controllo attraverso un cavo dalla guaina piuttosto “rigida”, che ha fatto la funzione di “tubo”, facendo arrivare aria molto umida che si è condensata sulle pareti. Con il calo delle temperature, l’umido è aumentato tanto, arrivando a bagnare molto il circuito, rendendolo non funzionante.

Interventi di ripristino:

  • rendere la scatola del sensore secondario veramente “stagna” con silicone e nastro vulcanizzante, oppure rimuoverlo del tutto, visto che in definitiva serve a poco.
  • rendere la scatola dell’elettronica non comunicante con la scatola del sensore secondario, tappando il “tubicino” con il silicone.