Visto che questa sera ho a disposizione tempo, radio e segnali forti, ho voluto fare una prova di ricezione di una stazione locale che usa DMR. Si tratta di una utility della mia città, che non sono riuscito ancora ad ascoltare con il mio fido Radioddity.
Ci ho messo un po’ per trovare la giusta configurazione dei parametri operativi, ma alla fine funziona ed anche bene. Le stazioni che sono più distanti arrivano molto male, ma è un ottimo inizio.
Dopo la vendita della mia amata, ma inutilizzata bici, ho deciso di investire i soldi in una radio. Sono tanti anni che non acquisto una radio che sia un minimo al passo con i tempi e, malgrado la posizione schifosa di casa, ho deciso di fare il “grande passo”.
Di radio ne ho passate parecchie, con una costante: il TS400S/AT che mi segue dal 1992, ma che ormai, ha dato tanto e necessita di un po’ di riposo. Negli anni si sono succedute tante radio nel mio shack, tutte (a mio avviso) fantastiche:
– TS711 e TS811 (rivendute per mancanza di spazio);
– FT736R con 50MHz, toni e filtro CW (rivenduto in un momentaccio);
– FT857 (rivenduto per inutilizzo);
– FT817 (ancora sulla mia scrivania)
Oltre ad una serie molto nutrita di portatili che giacciono su uno scaffale in attesa di tempi migliori.
L’idea è quella, in previsione del prossimo ciclo solare, di acquistare una radio che mi consenta di lavorare le bande più giocose: 50MHz, 144MHz e 28MHz. Sfruttando qualche apertura in E-Sporadico, ho qualche possibilità di divertimento anche io che sono in una “valle di lacrime”. Pertanto mi sono messo a caccia di una radio che potesse soddisfare queste pretese:
– presenza dei 50MHz;
– copertura delle HF;
– copertura dei 144MHz;
– budget max 1000euro.
In pratica un classico quadribanda, o, in alternativa, una radio che possa coprire VHF ed UHF e lasciare al fidato TS440 il compito dei 10m. La ricerca è stata interessate in quanto erano anni che non sfogliavo un sito di radio. Le opzioni non sono tantissime:
– FT847 usato (interessante ma un po’ datato);
– IC 9100 usato (troppo costoso);
– IC 7100 usato (non ha accordatore);
– IC 9700 fantastico ma… fuori budget;
– FT736R usato, sarebbe un gradito ritorno ma si trova poco;
– FT991A uhm… abbiamo un canditato!
Detto fatto mi sono messo a studiare il manuale del 991A per capire se avrebbe fatto al caso mio, mi sono documentato sul sito di I6IBE per vedere quanto si poteva hackare il sistema ed alla fine mi sono deciso: vada per il 991A. Mi sono messo a caccia dell’apparato sul mercatino di arifidenza, dove ho comperato il 90% delle radio che sono passate sul tavolo. Con un po’ di pazienza, sono riuscito a trovare un gentilissimo OM della zona 9 che mi ha venduto la radio e l’altoparlante esterno.
Dal punto di vista tecnico, il 991A non è “rivoluzionario”. Non si tratta di un apparato che utilizza la tecnologia SDR al massimo della sua espressione. Lo schema a blocchi è piuttosto “classico” con (solo) due connettori di antenna che alimentano selle sezioni RF “classiche” ed una catena di mixer per le conversioni di frequenza. Il DSP entra in gioco in “banda base”, dove viene utilizzato per realizzare filtri, denoising ed elaborazione del segnale (trasmesso e ricevuto). Nulla di nuovo sotto il sole, architettura consolidata ma che, attingendo a tecnologie ben più moderne del mio fidato TS440S/AT, riesce ad essere contenuta in uno spazio molto più compatto.
Impressioni di uso, dopo qualche settimana. Ormai sono convinto che con questi nuovi dispositivi sia NECESSARIO ed imprescindibile leggere accuratamente il manuale. La lettura deve essere fatta con l’apparato davanti agli occhi, per potere capire l’effetto delle numerose configurazioni possibili. Personalmente ho seguito numerosi tutorial su youtube per “farmi una idea” di quello che avrei potuto configurare. Alcuni tutorial si sono rivelati inutili o deludenti, altri sono stati invece fondamentali. In particolare, consiglio i contributi di ND3N:
– settings per SSB;
– settings per il CW;
– settings per WSJT;
Sono ottime basi per potere ragionare e costruire un setup personalizzato.
Riassumendo, mi piace:
– la compattezza del dispositivo, anche se questo si paga con una maggiore densità di calore e con una ventola che funziona spesso;
– la carcassa dell’apparato è perfettamente liscia, non ci sono alettature, pertanto non accumula polvere ed è facile tenerla pulita;
– le impostazioni sono semplici, il touch screen risponde molto bene e si controlla bene con le dita, senza ricorrere agli sticks;
– dopo qualche settimana ho preso confidenza con i menù e le configurazioni e riesco a fare “quello che voglio” con relativa semplicità;
– sono soddisfatto del funzionamento del front-end, almeno nelle mie condizioni operative;
– è presente una presa USB che consente di gestire in modo semplicissimo, il transceiver dal calcolatore.
Sono rimasto meno soddisfatto da:
– la presenza di solo 2 connettori di antenna (è il prezzo da pagare alla compattezza del sistema);
– manca la possibilità di collegarsi via ethernet.
Sono contento di avere acquistato questa radio di “nuova generazione”. Si tratta di un passo avanti notevole per me, soprattutto in termini di facilità di interfacciamento.
More to come!
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.
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.
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”.
Dopo qualche giorno di lavoro, la situazione è la seguente. Tocca solo capire quanto durerà la ventola!
Situazione: bagno cieco, con sfogo dell’aria in giardino. Dopo i lavori di ristrutturazione del bagno, c’è stata la necessità di “prolungare” il tubo esistente (diametro 10cm), per spostare verso il basso il punto di adduzione dell’aria. Per realizzare la prolunga, ho preso un pezzo di tubo da 80 e lo ho infilato nel tubo esistente. Commettendo un grossolano “errore da cojone”. Il tubo di sezione minore ha “ostruito” quello di sezione maggiore, per la presenza di una “curva” ed il risultato è stato che nel bagno, abbiamo creato una serra.
Nella serra, lungi dal crescere piantine, l’umidità ha fatto in modo che la parete “fredda” producesse tanto salnitro da staccare la pittura.
Disperato dalla situazione, ho deciso di cambiare aeratore, installandone uno molto potente della Vortice. Si tratta del modello “CA WE D HABITAT 100 ES“, un ventilatore centrifugo da condotto, per installazione esterna. Prodotto davvero costoso ma fatto molto bene, con un motore potente e silenzioso accreditato da una portata minima di 80 m3/h e massima di 265m3/h. Per installarlo bastano 10 minuti, è davvero un gioco da ragazzi. Solo che dopo 2 ore che lo avevo montato sono “emerse” alcune richieste:
Andiamo per gradi. Il ventilatore prevede una morsettiera con “fase, neutro, max”, ove l’ultimo terminale deve essere connesso alla fase per mandare il motore alla velocità massima.
Per realizzare la temporizzazione, ho acquistato su Amazon, un temporizzatore CS3-1B, ovvero un piccolo relè a stato solido, con due trimmer per regolare lil ritardo di attivazione e la durata dell’alimentazione del carico. Prevede l’ingresso della “fase neutro” e di una fase interrotta che è il “segnale” che regola l’alimentazzione del carico e, allo spegnimento della luce, fa partire il timer che regola il ritardo di spegnimento del carico. E’ una unità piccolissima, che si può mettere anche dentro una 503. Il primo problema è risolto.
Allo spegnimento della luce del bagno, la velocità deve essere massima. Questo lo ho risolto con un relè con bobina a 220V. Il morsetto di attivazione della velocità massima è collegato sulla uscita del relè temporizzato attraverso il contatto “normalmente chiuso” del relè. Alla accensione della luce del bagno, il relè si “apre” e la ventola gira alla velocità minima. Allo spegnimento del relè, il contatto si chiude (NC) e la ventola commuta al massimo.
Per gestire la temporizzazione notturna, ho acquistato (sempre su Amazon) un timer meccanico su DIN, che ho inserito in “serie” all’uscita del contatto del relè. In questo modo, dopo le 22.30, anche se è presente tensione sul piedino di doppia velocità, il timer ha il contatto aperto e questa funzione è inibita.
Le specifiche sono state tutte rispettate, il cliente (mia moglie) è contento ma nella parte superiore della ventola c’è un certo affollamento… Adesso non rimane che aspettare che la parete si asciughi e poi ritinteggiare tutto.
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.
Situazione: un conoscente, che per convenzione e privicy chiameremo “esse”, crea per errore un “supporto per l’installazione di windows 10” sul disco dei backup. Windows, vede uno disco da 1TB e decide di formattarlo. Esse mi chiama dicendo che il disco che si chiamava “pippo”, ha cambiato nome e dentro ci sono solo files di windows.
In passato avrei detto “pace è andato tutto”. Questa volta mi sono incaponito e forse sono riuscito a recuperare un po’ di dati. Ho lavorato solo in ambiente Linux (Ubuntu).
Step zero: non avere fretta. Il data recovery è un processo lungo, lunghissimo. La fretta aumenta il numero di dati che vengono persi.
Primo step: non si lavora MAI sul disco originale. Pertanto ho preso un disco da 2TB (ex videosorveglianza, lentissimo), e lo ho installato nella mia WS. Ho fatto una immagine del disco originale con “dd” e ho messo in un cassetto il dispositivo. Da questo momento in poi ho lavorato SOLO sulla immagine, per preservare i dati e la meccanica del disco originale.
Secondo step: cercare di recuperare la tabella delle partizioni vecchia. Per questo mi sono avvalso del tool testdisk, usando la funzione di “deep search”. Una volta ricostruita la tabella delle partizioni, il problema è stato: come recupero i dati da un filesystem compromesso? I tool nativi di Linux, come ntfsrecover, non sono riusciti a fare nulla in quanto richiedevano l’uso di chkdsk. Ho provato montare la partizione recuperata in windows, usando losetup per creare un loop device e qemu-image per creare un file qcow2 relativo solo alla partizione ntfs: nulla, windows si rifiuta di collaborare.
Terzo step: cercando in rete mi sono imbattuto in un paio di programmini davvero interessanti. Non avendo fretta (step zero) ho deciso di provare. Il primo si chiama scrounge-ntfs ed è attualmente al lavoro. Richiede pochi input (start-end) della partizione NTFS e una cartella di appoggio. Attualmente ha recuperato 378GB di materiale, organizzando tutto in una unica directory.
L’altro software si chiama scalpel e mi sembra maggiormente orientato al data recovery in ambito forense, soprattutto in presenza di dati intenzionalmente cancellati.
Il processo è ancora in corso (sono passate solo 24 ore). Prima o poi finirà.
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.
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!
Ieri sera, dopo una lunga attesa, ho deciso di aggiornare il firmware della Mikrotik hAP Ac2 (RBD52G-5HacD2HnD-TC) alla versione 6.49. Ho fatto questa operazione un sacco di volte e non ho mai riscontrato problemi.
Anche ieri sera, ho selezionato “Download and Install” ed ho atteso. Malgrado la lunga attesa, il sistema non è tornato disponibile. Ho provato a spegnere e riaccendere, a resettare… nulla. Ho pensato di avere bricckato la MKT, ma prima di buttarla nel cesto del “recupero componenti”, ho voluto fare una prova con “netinstall”.
Si tratta di un software che ha la funzione di bootp e consente di sfruttare il boot da rete per installare il sistema operativo su una Mikrotik, anche se winbox non la dovesse riconoscere. In pratica è la ultima spiaggia prima del ” recupero componenti”. Sapevo che questo programma fosse “ostico” da fare girare su windows ed in effetti così è stato. Malgrado i tentativi di:
– disabilitare il firewall;
– spegnere/disabilitare tutte le periferiche non 802.3;
Non c’è stato verso di avviare il programma che risponde SEMPRE con un errore di bind(), ovvero con l’impossibilità di creare un socket. Amareggiato da questo comportamento ho fatto una prova con WINE in ambiente linux. Il programma viene eseguito ma, in questo caso, penso non gradisca la presenza di più indirizzi IP sullo stessa interfaccia BR0.
La soluzione del problema è arrivata tirando fuori, dallo scatolone dei ricordi, un vecchio adattatore USB – Ethernet della DLINK. Un oggettino del 2009 che ancora funziona. Linux lo ha riconosciuto subito, ho assegnato a questa interfaccia l’indirizzo IP 192.168.88.2 ed ho avviato la versione per linux di netinstall. Avendo preventivamente scaricato la immagine da mettere sulla Mikrotik, il processo di flash è statto “relativamente” veloce e non ha restituito alcun errore. Ho riavviato la MKT e tutto sembra funzionare correttamente.
Dispositivo recuperato ma che fatica!!!!
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).
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.
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!
