Archivi categoria: Elettronica

Esp8266 – Un progettino easy.

Ho realizzato diversi sensori di temperatura basati su ESP8266 e DHT22, ormai ho il codice pronto, diversi alimentatori a 5V o 3.3V e posso fare un deploy molto veloce.

Partendo da un sensore che avevo “pronto” e funzionante in ufficio, ho voluto fare alcuni miglioramenti per fare un po’ di esperienza ed imparare qualche cosa. L’obbiettivo che mi sono prefissato è il seguente:
– aggiungere un display 16 x 2 collegato con I2C al micro, per visualizzare umidità e temperatura;
– implementare un client MQTT per visualizzare i dati di consumo elettrico sul display.

I classici display 16×2 sono controllabili attraverso un protocollo che prevede collegamento in parallelo di diverse linee dati. Si trovano alcune interessanti informazioni in questo link. Questo approccio era molto carino ai tempi dei PIC, dove le linee di I/O erano molte. I dispositivi ESP non hanno, a parte rare implementazioni che integrano dei moltiplicatori di I/O, tutte queste linee. Meglio ricorrere ad un convertitore I2C. Sono dispositivi a bassissimo costo che si possono facilmente reperire su Aliexpress o ebay ad un prezzo ridicolo ( da 1 a 2 euro).

Sono basati su PCF8574T, prodotto dalla NXP e catalogato come “Remote 8-bit I/O expander for I2C‑bus with interrupt”: volendone banalizzare il funzionamento, è possibile controllare e leggere lo stato della porte I/O attraverso opportuni comandi sul bus I2C.

Per farlo interagire con ESP8266, mi sono trovato molto bene con la libreria LCD_I2C, nella versione 2.3.0.
L’oggetto LCD è istanziato con poche righe di codice, ed è poi accessibile con delle funzioni per il posizionamento del cursore e la scrittura dei dati:
int lcdColumns = 16;
int lcdRows = 2;
LCD_I2C lcd(0x27, 16, 2);

L’unica seccatura è quella di dovere caricare uno sketch dedicato alla scansione del BUS I2C per trovare l’indirizzo dell’expander. In rete si trovano diversi tutorial, completi di codice.

Le funzioni per il posizionamento del cursore e la scrittura dei dati sono molto semplici:
lcd.setCursor(0, 0); // Or setting the cursor in the desired position.
lcd.print("T=");
lcd.print(tempe);

In poche parole, il collegamento del display al modulo ESP ha richiesto davvero pochissimo tempo.

La gestione di MQTT ha richiesto un minimo di attenzione in più, soprattutto per capire “come fare cosa” e gestire in modo opportuno funzioni e temporizzazioni. Il broker MQTT è residente su un server linux. Il sensore deve collegarsi al broker, iscriversi ad un canale e mostrare sul display il valore della potenza attualmente impiegata a casa. Non voglio reinventare la ruota, pertanto rimando ad una ricerca su Google il reperimento delle informazioni sul funzionamento del protocollo.
Per il corretto funzionamento della libreria, bisogna prevedere “a monte” la connessione del dispositivo alla rete, via cavo o via wireless, come mostrato da queste righe di codice:
WiFiClient WFclient;
PubSubClient client(WFclient);

Una volta istanziato l’oggetto client, occorre connettersi al broker ed essere pronti a ricevere i messaggi pubblicati sul canale di interesse. La connessione è gestita direttamente nel loop, ed occorre assicurarsi che nel loop non ci siano inutili perdite di tempo:
void loop() {
if (!client.connected()) {
reconnect();
}
client.loop();


Le funzioni accessorie sono la “reconnect”, che gestisce la connessione al broker (ampiamente documentata in rete).

Altra funzione importante la callback che si occupa della ricezione e della visualizzazione del messaggio MQTT:
void callback(char* topic, byte* payload, unsigned int length) {
Serial.print("Message arrived [");
Serial.print(topic);
lcd.setCursor(0, 1); // Or setting the cursor in the desired position.
lcd.print("P=");
Serial.print("] ");
for (int i = 0; i < length; i++) {
Serial.print((char)payload[i]);
lcd.print((char)payload[i]);
}
Serial.println();
}

Mettendo insieme ESP8266, codice, un level-shifter ed un paio di regolatori, sono riuscito a creare questo “mostro” che legge la temperatura da un sensore DHT, la mostra su un Display e, in calce a questo, mette il valore della potenza “consumata” da casa che gli arriva via MQTT. Come ogni progetto ci sono delle criticità che devo risolvere:
– il display fa schifo. Si tratta di uno dei tanti 16×2 che ho comperato alle fiere ai tempi dei PIC16F84, quando con 50.000 lire ti potevi comperare qualceh 16F84, un paio di 628 e una manciata di display per fare qualche progettino nerd. Per risparmiare prendevo sempre i “non retroilluminati”. Solo che adesso non si legge nulla. Devo mettere un nuovo 16×2 con retroilluminazione o passare ad un OLED.
– la board è alimentata da un trasformatore DIN da 8V, pertanto ho inserito un ponte, un elettrolitico ed un regolatore a 5V. Solo che il regolatore scalda e devo inserire un piccolo dissipatore per evitare che si surriscaldi. Appena lo smonto per mettere il nuovo display, faccio anche questa modifica.

Possibilità di miglioramento:
– inserire un pulsantino per gestire altre visualizzazioni: temperatura esterna, potenza assorbita dalla heat-pump, potenza prodotta dall’impianto FV etc.
– provare un display oled.

Home Assistant – Mqtt e sensori custom

Grazie alla segnalazione di alcuni studenti del corso di “Laboratorio ICT per la nautica e la domotica”, mi sono imbattuto in Home Assistant, una piattaforma per la gestione domotica molto gradevole e ben funzionante. In passato ho usato OpenHAB, ho dato una occhiata veloce a Domoticz ma HA mi è piaciuto tanto che lo eletto a base per lo sviluppo di un nuovo progetto.
Ho diversi sensori a casa, volti alla misura della temperatura in alcune stanze “critiche”, delle condizioni meteo e dei consumi elettrici. I dati raccolti da questi sensori (realizzati su base ESP8266), sono trasferiti ad un server collettore usando il metodo POST in HTTP. Sul server ci sono alcuni script PHP che raccolgono i dati, danno una prima “scremata” e li inseriscono in un database MariaDB. La fruizione dei dati avviene attraverso un terrificante sito web interno, che, attraverso delle tabelle, organizza i dati e consente di tracciare dei grafici scegliendo una diversa base dei tempi. Tutto questo “accrocco” funziona in modo decente, non ho mai perso dati, tutto è catalogato ordinato e preciso. Ci sono anche dei difetti: aggiungere delle automazioni è piuttosto complesso, la visualizzazione dei dati è poco “user friendly”, manca una APP per potere gestire tutto comodamente da SmartPhone.

Una volta conosciuto HA, ho deciso di migrare (piano piano) i dati su questa piattaforma, facendo in modo che il sistema riconosca quanto già presente in rete, ed integrando a mano tutto il resto.
Il primo step è stato installare HA in modalità completa (Home Assistant Operating System) come macchina virtuale nel server di casa. Operazione davvero banale, grazie all’uso di libvirt ed al fatto che ho già altre VM per il monitoraggio della rete dati. La piattaforma è risultata subito perfettamente funzionante ed ha “riconosciuto” alcuni dispositivi come il mio smartphone e la TV. Per integrare altri dispositivi ho seguito due strade:
– uso dei plugin custom presenti nella community di HA o su GItHUB;
– uso “massivo” di MQTT.
La prima via, ha risolto il problema dell’integrazione dello split Daikin (che mi ha fatto penare davvero tanto) e dei router MikroTik. Con la seconda strada ho “sistemato” i sensori custom, senza la necessità di doverli riprogrammare.

Ho quindi installato il broker mqtt usando “mosquitto”, in ambiente linux e modificato lo script PHP che processa i dati in ingresso al server. Questo è stato arricchito da una riga che, sfruttando mosquitto_pub, consente di pubblicare su un canale i dati ricevuti e metterli quindi a disposizione di tutti gli oggetti mqtt.
exec("mosquitto_pub -h localhost -p 1883 -t '/csensors/".escapeshellarg($name)."/temp"."'"." -m ".escapeshellarg($json_string_temp));

exec("mosquitto_pub -h localhost -p 1883 -t '/csensors/".escapeshellarg($name)."/humi"."'"." -m ".escapeshellarg($json_string_humi));

Queste due righe di codice consentono di replicare i dati di temperatura ed umidità ricevuti dai sensori remoti sul sistema MQTT.
La verifica del funzionamento è semplice, basta usare
mosquitto_sub -h localhost -p 1883 -t '#' -v
per mettersi in ascolto su tutti i canali e verificare il corretto scambio di messaggi:
/csensors/xxxx01/temp {"sensore"="xxxx01","value"="24.20"}
/csensors/xxxx01/humi {"sensore"="xxxx01","value"="49.00"}
/csensors/yyyy01/temp {"sensore"="yyyy01","value"="33.00"}
/csensors/yyyy01/humi {"sensore"="yyyy01","value"="31.50"}
/csensors/xxxx01/temp {"sensore"="xxxx01","value"="24.20"}
/csensors/xxxx01/humi {"sensore"="xxxx01","value"="49.00"}


Una volta che i dati sono disponibili sul sistema MQTT, occorre istruire HA per poterli leggere ed elaborare. Per questa operazione è necessario modificare la configurazione del sistema. Io mi sono trovato molto bene con il componente aggiuntivo “Studio Code Server“, che avevo già usato per integrare il NAS e modificare la configurazione dell’oggetto TV.

Ogni dispositivo MQTT deve essere creato appositamente, istruendo HA sul canale da sottoscrivere, il valore da leggere ed i suoi attributi. Il file ha sintassi YAML e particolare cura deve essere prestata alla indentazione.
mqtt:
sensor:
- name: "Temperatura yyyy"
state_topic: "/csensors/yyyy01/temp"
unit_of_measurement: "°C"
device_class: "temperature"
- name: "Umidita yyyy"
state_topic: "/csensors/yyyy01/humi"
unit_of_measurement: "%"
device_class: "humidity"


Terminata la redazione del file di configurazione è necessario riavviare HA per fare in modo che i dispositivi vengano integrati nelle “entità”. A questo punto è immediato aggiungerli ad uno dei tanti pannelli di controllo e visualizzazione che si possono creare.

KNX Bus Monitoring a basso costo

Supponiamo che si voglia realizzare un monitor del bus KNX in una installazione domestica con “valore aggiunto” domotico. Le strade possibili sono diverse e variano a seconda del tipo di portafoglio e di installazione realizzata.
Per gli utenti Gewiss che hanno prodotti della serie “easy”, la funzione di monitoraggio è offerta dal software Easy Controller, che tuttavia non registra le informazioni su disco.
Per chi voglia avere un approccio generico, è possibile usare ETS5/6 in modalità “demo” in modo da non dovere pagare la costosissima licenza.
Il limite di questi software è costituito dal fatto che NON nascono per una applicazione di monitoraggio del bus, ma offrono questo servizio a supporto del “debug” delle applicazioni.

In entrambi i casi è necessario disporre di una interfaccia tra bus KNX e calcolatore, con collegamento via rete LAN, seriale o USB. Le interfacce di marche blasonate sono molto costose. Il mercato pullula di interfacce low-cost, da usare direttamente connesse alla Raspberry o che richiedono un collegamento seriale. La maggiore parte sono le tpuart, che sono ampiamente citate negli esempi trovati in rete.
Volendo fare qualche prova con la “valigia domotica Gewiss”, ho acquistato su Aliexpress, una semplice interfaccia USB/KNX (KNX Downloader) al prezzo di 56 euro. Non sono pochi ma sono una frazione rispetto a quanto richiesto dai “big players”.

L’idea è quella di integrare questo dispositivo in ambiente Linux (Ubuntu server) ed associarlo a KNX per potere realizzare un logger. Gli step sono:
– installare Ubuntu server su una macchina virtuale;
– compilare, fare funzionare knxd in modo dignitoso;
– fare comunicare KNXD con l’interfaccia;
– fare in modo che knxd “tiri fuori i dati” dal bus knx in qualche forma.

Complice il fatto che sono un principiante di KNX, questo processo mi ha richiesto un sacco di tempo e per questo vorrei documentarlo al meglio.
KNXD (maggiori informazioni qui) (oppure qui)
Installare questo software con un pacchetto debian o ubuntu significa perdere tempo. knxd DEVE essere ricompilato e per farlo, occorre prima scaricare “qualche” libreria e pacchetto aggiuntivo:
– apt install libtool
– apt install libusb-1.0-0-dev
– apt install libsystemd-dev
– apt install build-essential
– apt install libev-dev
Fatto questo è possibile clonare il repository: git clone https://github.com/knxd/knxd.git e procedere, come indicato sul sito, alla compilazione:
– cd knxd
– git checkout main
– sh bootstrap.sh
– ./configure –your-chosen-options
– make
– make install
Lo step che può dare “grattacapi” è quello che esegue bootstrap.sh, script deputato (anche) al controllo della presenza di tutto il necessario per la compilazione. Il build del software richiede qualche minuto ma termina con successo. Una volta eseguita l’installazione, tutti i binari si trovano al loro posto.

Lo step successivo è dare in pasto a knxd il dispositivo giusto. Il KNX-Downloader viene riconosciuto immediatamente ma occorre rendere l’accesso al device più libertino.
root@knx:~# lsusb
Bus 001 Device 003: ID 0403:6898 Future Technology Devices International, Ltd TSY KNX-USB Data Interface
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root@knx:~#


Usando udevadm: si crea il file /etc/udev/rules.d/70-knxd.rules ed al suo interno si inserisce questa stringa:
SUBSYSTEMS==”usb”, ATTRS{idVendor}==”067b”, ATTRS{idProduct}==”2303″, GROUP=”users”, MODE=”0666″
In questo modo, quando il sistema udev, riconosce il device, così come descritto da idVendor e id Product, associa ad esseo il permission 0666.
Per verificare che knxd possa digerire il dispositivo c’è un comodissimo comando: findknxusb:
root@knx:~# findknxusb
Possible addresses for KNX USB devices:
device: 1:3:1:0:0 (TSY Technology:TSY KNX-USB Data Interface)

Una volta verificata questa possibilità non rimane altro che configurare knxd, e su questo punto ho impiegato diverso tempo.

Chiariamo che knxd non è altro che un router tra il mondo knx ed il mondo ip, in pratica è possibile configurarlo per fare in modo che ad una PDU KNX corrisponda un pacchetto ip e viceversa. knxd può essere configurato attraverso un file di configurazione (che DEVE avere estensione .ini) o attraverso la riga di comando, passandogli una serie di parametri che, fortunatamente sono molto ben documentati, in questo sito.
Dopo diverse prove e grazie a questo sito, la stringa funzionante è questa:
knxd –trace=5 –error=5 –eibaddr=0.2.118 –client-addrs=0.2.20:20 -D -T -R -S -i -b usb:
Due parole di spiegazione:
– trace ed error: livello di debug e di report durante l’esecuzione del software;
– eibaddr: indirizzo del device softare knxd. Come se fosse l’indirizzo dell’adattore USB;
– client-adds: spazio degli indirizzi dei client che si connettono lato ip.
– D : discover. Consente a knxd di rispondere ai pacchetti di discover;
– T : abilita la funzione di tunneling;
– R: consenti lo scambio di pacchetti multicast, usato da altri router knx;
– S: seleziona l’interfaccia ip, sulla quale è presente la default route;
– i: aggancia knxd su tutti gli indirizzi ip< configurati sul dispositivo;
-b: specifica il dispositivo L2 da usare per la connessione
– usb: nella versione attuale, non richiede di specificare il dispositivo da usare. KNXD cerca tra i dispositivi, quello più adatto ai suoi scopi.
SE tutto va a buon fine:

root@knx:~# knxd –trace=5 –error=5 –eibaddr=0.2.118 –client-addrs=0.2.20:20 -D -T -R -S -i -b usb:
W00000125: [ 1:main] Consider using a config file.
W00000126: [ 1:main] knxd should not run as root
Layer 0 [16:B.usb/USBdr 0.020] starting send_Local
Layer 0 [18:B.usb/usbL 0.020] SendUSB(064): 01 13 09 00 08 00 01 0F 01 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0 [18:B.usb/usbL 0.020] StartSend 5595789896d0
Layer 0 [ 4:server/Server 0.020] Open
Layer 0 [ 4:server/Server 0.020] Opened
N00000127: [22:router.pace_] The ‘pace’ filter without a queue acts globally.
Layer 0 [16:B.usb/USBdr 0.031] send_Local done
Layer 0 [18:B.usb/usbL 0.035] RecvUSB(064): 01 13 0B 00 08 00 03 0F 02 00 00 01 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 2 [16:B.usb/USBdr 0.035] recv_Data(064): 01 13 0B 00 08 00 03 0F 02 00 00 01 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 2 [17:B.usb/Conv 0.035] send_Init 3
Layer 0 [17:B.usb/Conv 0.035] starting send_Local
Layer 0 [18:B.usb/usbL 0.035] SendUSB(064): 01 13 0A 00 08 00 02 0F 03 00 00 05 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0 [18:B.usb/usbL 0.035] StartSend 5595789719a0
Layer 0 [17:B.usb/Conv 0.047] send_Local done
Layer 2 [23:B.usb/CEMI 0.047] OpenL2

A questo punto occorre trovare un software che possa decodificare il traffico knx in modo da poterlo elaborare in modo opportuno.
I candidati sono due:
knxtool e knx-logger.
–knxtool (maggiori informazioni qui ed anche qui)
Programma che consente di interagire con il bus knx. La descrizione in rete non rende giustizia a questo tool, davvero complesso. Invocando il comando con lo switch “list” si ottengono tutte le opzioni di esecuzione:

Tra le tante opzioni sono evidenti i “bus monitor” ed il “vbusmonitor”. In rete ho trovato alcune indicazioni in merito ad un non corretto funzionamento di “busmonitor”, pertanto mi sono concentrato su “vbusmonitor”.
La sintassi di knxtool, prevede che venga invocato indicando l’indirizzo ip dell’interfaccia alla quale si deve collegare:
root@knx:~# knxtool vbusmonitor1 ip:192.168.188.176
L’avvenuta connessione è mostrata anche da knxd:
Layer 0 [24:A.tcp/CConn 3987.870] ReadMessage(002): 00 13
Layer 0 [24:A.tcp/CConn 3987.870] Send(002): 00 13

A questo punto il sistema è “pronto” per interpretare i telegrammi che transitano sul bus knx.
–knxlogger ( maggiori informazioni qui )
Tool essenziale, con una minore configurabilità rispetto al precedente. Per la invocazione richiede solo l’indicazione dell’ip sul quale fare la connessione.
root@knx:~/knx-logger# ./knx-logger ip:192.168.188.176
2022-05-16 07:21:15 Write FROM 0.2.5 TO 24/0/14 VALUE


Fortunatamente sono in una situazione ideale: ho la valigia domotica a disposizione, collegata al calcolatore con una interfaccia USB Gewiss e posso monitorare il traffico KNX con l’applicazione “Easy Controller Software“. Contemporaneamente ho una macchina virtuale che esegue Ubuntu server, ove è in esecuzione knxd ed il logger. Pertanto posso fare un parallelo tra azione (pressione di un pulsante) e modo in cui i due software registrano e visualizzano l’evento.

Configurazione di sistema
Pressione di un pulsante sul dimostratore.

Il modo in cui knxtool mostra il telegramma dipende dallo switch con il quale è stato invocato:
vbusmonitor1:
L_Busmon: BC 02 05 C0 0E E1 00 81 EA :L_Data low from 0.2.5 to 24/0/14 hops: 06 T_Data_Group A_GroupValue_Write (small) 01
vbusmonitor2:
BC 02 05 C0 0E E1 00 81 EA
vbusmonitor3:
(0, f9e953b3) BC 02 05 C0 0E E1 00 81 EA

Nel primo caso le informazioni hanno una componente “human readable”: Il telegramma è stato inviato dal dispositivo 0.2.5 (coerente con l’analizzatore Gewiss) ed ha un determinato payload. L’intepretazione della stringa deve essere fatta attraverso delle funzioni (python ne prevede di native – untested) o riferendosi alla specifica del protocollo.

Come ultimo step, ho voluto fare un monitoraggio del bus anche con ETS5, versione professional. Mi ha colpito il fatto che all’avvio, ETS abbia “visto” anche knxd come interfaccia usabile per la configurazione/monitoraggio del sistema.

Premendo il “solito” pulsante, il risultato di ETS è maggiormente prolisso:

Conclusione:
in questo non breve articolo, ho presentato una soluzione economica per il monitoraggio della bus KNX. I test di funzionamento sono stati svolti utilizzando un dimostratore domotico commerciale ed hanno dato ottimi risultati.

Odroid XU3

Da diversi anni ho installato una Odroid XU3 in uno spazio attrezzato, ove funge (essenzialmente) da piattaforma per Spyserver. Malgrado sia un oggetto piuttosto datato, lavora molto bene e non è particolarmente avida di energia.
Recentemente ho notato che tende ad essere un po’ calda, pertanto, oltre a sostituire la ventolina che non ne poteva più, ho provato a fare un po’ di hack sul controllo della rotazione.
Ho letto un interessante articolo su un forum, in cui viene spiegato in modo molto semplice come cambiare la logica di intervento della ventola. Le impostazioni che ho configurato sono un po’ aggressive: alla temperatura di 50°C la ventola gira al 50%, a 65°C si sale all’80% ed oltre i 75°C arriviamo al valore di 95%. Considerato che la ventola è inserita in un contesto piuttosto “caldo” è meglio “prevenire”.

Situazione di partenza, temperatura media 64°C

Dopo qualche giorno di lavoro, la situazione è la seguente. Tocca solo capire quanto durerà la ventola!

Dopo la cura!

Stazione meteo: 3.0

Da diversi mesi ho smontato la stazione meteo che avevo sul tetto. Finalmente mi sono deciso a farne una nuova. Le motivazioni sono semplici: voglio passare dalla connettività wireless a quella cablata e fare tesoro di quanto scritto in questo articolo.

La nuova piattaforma sarà inizialmente basata su una Raspberry Pi 2. Ormai questo hardware è molto vecchio e non si adatta a lavori molto intensi per carico di CPU. Meglio quindi relegarlo alla data acquisition, visto che a bordo c’è tutto quello che serve: SPI, I2C, Camera ed ethernet. Spero solo che la CPU “regga” il caldo, ma se non dovesse risultare stabile ho pronto un “piano B”. Le caratteristiche della nuova piattaforma:
– alimentazione singola a 12V con regolatori interni per 5V e 3.3V;
– Raspberry PI 2 con camera;
– sensore BME 280 interno per rilevare pressione e la temperatura interna del box;
– sensore DHT 22 esterno per umidità e temperatura;
– convertitore A/D MCP3424A per lettura della velocità del vento;
– rimozione del sensore di direzione del vento (almeno per ora);
– predisposizione per sensore di pioggia;

In questi giorni di sviluppo hardware e software ho anche riaperto la vecchia stazione meteo che era operativa dal 2018 ed ha preso notevoli “botte” di grandine e caldo. La situazione all’interno del box è molto molto buona. Non ci sono segni di ossidazione. Solo i cavi hanno sofferto notevolmente e si sono rovinati (devo rinforzarli). Spero di ripristinare le funzionalità entro fine marzo.

In fase di apertura.
La board
Cavo danneggiato dal pressacavi
Nessun segno di ossidazione

La giornata del saldatore

Ieri, dopo parecchio tempo, ho rimesso mano al saldatore per sistemare un paio di lavoretti arretrati.
Il primo è relativo ad un “trapianto di memoria” in una vecchia chiavetta USB nella quale si è bruciato il controller. La persona che mi ha affidato il dispositivo è riuscita a trovare un oggetto IDENTICO, che ha reso possibile l’operazione di espianto della memoria e inserimento nella chiavetta con il controller funzionante.
L’operazione è stata piuttosto articolata in quanto è stato necessario dissaldare il chip di memoria originale (fatto con la tecnica della colata di stagno), pulire bene i pad e poi risaldare il chip di memoria. Fortuna il saldatore con stilo SMD. La chiavetta, per pura fortuna non si era danneggiato il chip di memoria, è risultata subito funzionante ed ha consentito di recuperare tutto il contenuto.

Le chiavette gemelle
Particolare del chip di memoria risaldato
Chiavetta funzionante.

Il secondo intervento è stato relativo al ripristino di un cavo HP 11730A, usato per la connessione della testina generatrice di rumore ad un NFA 8975A. Per motivi di ageing uno dei pin si è rotto, rendendo impossibile il riconoscimento della testina e la misura.
Dopo qualche tentativo, sono riuscito a risaldare il pin e la testina viene riconosciuta. Non è un lavoro da poco in quanto il cavo è dannatamente costoso!

Il pin riparato.

UCCM – GPSDO la coppia

Finalmente è arrivato il GPSDO che attendevo, come rimpiazzo del buon vecchio Trimble che si è (o è sempre stato) rotto. Un paio di giorni per compiere il trapianto di organo e, finalmente, sulla mia Timing-Desk ho due GPSDO up and running.
Anche questo Samsung è passato subito in stato locked con valori di TFOM stabili ad 1. Si tratta di una unità non propriamente “gemella” dell’altra: il quarzo installato è di dimensioni notevolmente maggiori (sempre marcato Samsung).

Lady Heather per il nuovo Samsung.

La posizione stimata dai due dispositivi è davvero molto “prossima”, visto che usano lo stesso ricevitore GPS (Ublox Lea-6t) e sono nelle stesse condizioni operative:
Samsung 1 (old)
Lat: 43.5866244N Long: 13.5170058E Alt: 226.24
Samsung 2 (new)
Lat: 43.5866200N Long: 13.5170047E Alt: 225.99
Distanza stimata su WG84 di 0.5m, non male.

In modo molto barbaro ho fatto una misura di frequenza, mantenendo il vecchio Samsung (OSM da qui in poi) come riferimento per il counter ed il nuovo come DUT. La misura è incoraggiante.

Misura di frequenza di NSM vs OSM.

Adesso occorre solo aspettare che arrivi il Thunderbolt e qualche accessorio per farlo funzionare:
– amplificatore di distribuzione a 10MHz;
– distributore del segnale GPS a 4 vie (utile anche per una idea futura);
– HUB e convertitori USB-RS232 per il controllo ed il monitoraggio dei sistemi.
Intanto mi godo il monitor!

Trimble UCCM GPSDO – EOL

In un vecchio articolo ho parlato di un oscillatore UCCM Trimble che, dopo molti anni, era riuscito a dotare di case, alimentatore e monitor. Una volta collegato il ricevitore all’antenna, Attivato il monitoraggio del ricevitore mi sono reso conto che qualche cosa non andava: in pratica l’UCCM non passa mai allo stato di LOCK (luce che lampeggia velocemente), in quanto, sembra, che la board non riesca a disciplinare l’oscillatore.
Ho chiesto idee e suggerimenti anche sull’ottimo forum eevblog, ma senza particolari esiti. Pertanto ho provato a giocare un po’ con oscillatore e board, per cercare di capire dove potesse essere il problema.

Il primo step è stato quello di smontare l’oscillatore dalla board, collegarlo ad una fonte di alimentazione lineare e stabile e fare qualche misura di corrente e frequenza. In questa fase ho valutato:
– assorbimento in corrente, deve essere non costante. Il quarzo (OCXO) deve assorbire parecchia corrente in fase di Warm-UP e poi deve stabilizzarsi a valori “ragionevoli;
– frequenza iniziale del quarzo, con il terminale Vtune posto a massa.
Per fare queste acquisizioni ho rispolverato LabView, su una comoda macchina virtuale Windows 10. Gli strumenti usati sono un multimetro da banco HP 34401A ed un counter HP 53131A. Quest’ultimo ha un reference 10MHz esterno, proveniente dal GPSDO Samsung.

Corrente in funzione del tempo.

Il “forno” funziona bene. Il tempo di riscaldamento è ragionevole e, trascorso tale transitorio, la corrente si assesta su valori bassi. Fino a qui, tutto ok. Anche la frequenza di uscita è stabile e centrata attorno ai 10MHz, non ci sono particolari deviazioni, tutto sembra rientrare nella norma (anche se non avendo un datasheet, la norma è un concetto un po’ vago). Ho anche tracciato un grafico della funzione “Frequenza vs Vtune” del quarzo, anche questo è piuttosto lineare (la “gobba” nella parte iniziale è dovuta ad un diverso metodo di misura).

Lo step successivo è stato quello di rimontare l’oscillatore nella board per monitorare la corrente assorbita dalla board, la frequenza di uscita e la tensione di controllo. In teoria la tensione di controllo, dopo un po’ di swing iniziale, dovrebbe assestarsi su un valore costante, mentre il sistema va in lock ed inizia a funzionare regolarmente.

Corrente della board

tensione di controllo.

Anche qui… ci siamo, almeno in teoria. Solo che il sistema, anche monitorato da Lady Heater, non raggiunge mai lo stato di LOCK, mantenendo valori di TFOM molto alti (3 – 7). Inoltre il valore della differenza di fase è molto “ballerino” arrivando a valori molto bassi (4.5 E-6) per tempi brevissimo per poi ricadere in alto (1 E-2). Qualche problema c’è sicuramente. Sarà la board? Sarà l’oscillatore? Non sono in grado (per adesso) di dirlo. Intanto ho ordinato un altro GPSDO per fare “la coppia” in attesa che arrivi un altro giocattolo molto interessante.

Counter HP 53131A

Da qualche tempo, in ufficio, ho un counter HP 53131A. Leggendo nella lista time-nuts, ho scoperto che non è un fenomeno nella misura della frequenza, soprattutto a 10MHz. Malgrado questo, vorrei provarlo con i software di KE5FX, pertanto mi sono dotato di una interfaccia GPIB – USB della National Instruments ed ho provato a fare colloquiare il PC con il counter.

Malgrado i mille tentativi non sono mai riuscito nell’impresa fino a quando mi è sorto un atroce dubbio: vuoi vedere che l’adattatore non fa contatto con la presa sullo strumento? Questo malgrado io abbia serrato completamente le viti di bloccaggio dell’adattatore stesso. Pertanto ho recuperato due vecchi cavi GPIB, ho tolto la abbondante polvere ed ho collegato l’adattatore: tutto perfettamente funzionante.

Inutile sottolineare il mio disappunto per questa cosa. Il lato positivo è che adesso ho collegato sia il counter che il multimetro via GPIB e posso, con un po’ di fantasia, controllarli da LabView per fare qualche misura “long term”. Da questo punto di vista è molto utile avere LabView su una macchina virtuale nella WorkStation dell’ufficio, in modo che possa lavorare anche quando non sono sulla scrivania. Nei prossimi giorni qualche considerazione su un GPSDO che non vuole saperne di funzionare!

GPSDO: finalmente stabile

Quasi una settimana di utilizzo dei due GPSDO, tempo di fare qualche considerazione “a caldo”:
1- L’interfacciamento dei due dispositivi con il calcolatore mi ha fatto penare. Avevo preso un convertitore USB seriale su PCB, ma è risultato “non funzionante”, pertanto ho dovuto optare per la classica “frusta” USB-RS232.
2- Devo modificare il circuito di alimentazione: un solo LM317 è poco e la temperatura che raggiunge il dispositivo è decisamente alta. Meglio usarne due in parallelo e montarli sui dissipatori in alluminio che la scatola prevede, possibilmente uno per lato.
3- Il “trimble” viene “digerito” da Linux senza problemi e Lady Heather ne mostra i (pochi) parametri in modo immediato. Più complesso collegare il Samsung: ho dovuto usare un artificio. Esportare la seriale /dev/ttyUSB1 in rete con ser2net e poi collegare Lady Heater via IP:
ser2net -C 3202:raw:0:/dev/ttyUSB1:57600 -l
sudo ./heather -tz=UTC -ip=192.168.1xx.yy:3202
La mia impressione è che il software e l’hardware non si accordino sulla velocità dell’interfaccia.
4- Il Trimble mostra tutta la sua età: stabilizza poco il PPS e ha un valore di TFOM pari a 4. Considerata l’età è tanto che ancora funzioni bene.
5- Adesso che tutto funziona… vorrei uno splitter GPS a 4 porte ed un ThunderBolt da mettere a sistema, per vedere se le performances che promette (e di cui tutti parlano) sono reali.

Sistema funzionante e settato.

Dallo screenshot si nota come, a parità di antenna, cavo e condizioni “al contorno”, i due sistemi rilevino una posizione leggermente differente:
Trimble:
Latitudine: 43.5866217 N – Longitudine: 13.5170019 E- Altezza: 224.19m
Samsung:
Latitudine: 43.5866175 N – Longitudine: 13.5170086 E- Altezza:223.89m
La differenza di altezza è di 30cm, la distanza è di 71.5 cm. In pratica il Trimble è “in alto a sinistra” rispetto al Samsung.

Immagine del setup completamente operativo

Con l’occasione ho riacceso il counter HP 53131A ed il mio EIP 350, almeno si sono un po’ riscaldati. Mi sono divertito a calcolare la deviazione standard del rapporto tra gli intervalli del segnale PPS. IL conteggio è stato fatto su 10k secondi ed ha mostrato un valore molto interessante: 1.09uS.

Valore della deviazione standard del rapporto tra i periodi PPS.

Notare come sia comparso un altro giocattolo: un vecchissimo counter HP 5315B trovato nello scatolone dei cespiti (monnezza). Lo ho accesso a vita persa ed ha funzionato subito. Sicuramente è possibile rimetterlo in riga ed ho trovato un interessante articolo per dotarlo di un ingresso 10MHz esterno. Ne riparleremo.