Ogni tanto capita di dovere rimettere mano al saldatore per fare qualche operazione un po’ delicata. Ultimamente un collega mi ha portato una scheda di acquisizione delle Texas Instruments, alla quale si è letteralmente strappato il connettore USB.
La scheda è molto costosa e difficilmente disponibile sul mercato, con tempi di attesa fino a 53 settimane. Il problema è che il connettore, nel suo viaggio, si è portato dietro i pad di saldatura ed alcune tracce, pertanto è necessario lavorare “di fino” per mettere a posto tutto.
La riparazione non è da premio Nobel per la saldatura e darebbe sicuramente problemi con un sistema che lavorasse a velocità maggiori (USB3). In questo caso, ha funzionato tutto al primo colpo, il calcolatore riconosce la scheda, trasferisce i dati e tutti vissero felici e contenti.
Lo strumento AMIQ è stato introdotto nel mercato a fine anni ’90. SI trattava di un “trittico” di strumenti nati per la prototipazione ed il test su sistemi di telecomunicazione, composto da un generatore in banda base (AMIQ) un modulatore/generatore a radio frequenza (SMIQ) ed un analizzatore di spettro vettoriale (FSEA20). In pratica era possibile generare una sorgente dati (anche PRBS), scegliere in che modo modulare il segnale, aggiungere eventuali pre-distorsioni ed inviare queste forme d’onda al modulatore che la restituiva ad RF. Il generatore poteva essere collegato direttamente ad un DUT per verificarne il funzionamento o per fare misure di BER. Un sistema fichissimo per quegli anni, una cannonata.
Tale tripudio tecnologico è entrato in laboratorio nel 1997, ed ha servito per tanti anni, come cardine delle nostre attività di laboratorio e di dimostrazione agli studenti. Recentemente stanno iniziando alcuni problemi, SMIQ ha un problemino al circuito ALC ed AMIQ è del tutto morto.
Visto che non si trovano facilmente ricambi per questo oggetto abbiamo deciso di aprirlo per vedere se era possibile riparare lo strumento in casa. AMIQ è essenzialmente un calcolatore, che è collegato con una scheda di generazione di segnale attraverso un connettore su bus ISA (si, il buon vecchio bus ISA). Aprendo il coperchio il difetto è stato subito evidente: sono saltati tutti i condensatori della motherboard. Quindi bisogna procedere ad un recapping.
Detto fatto ho acquistato per due volte i condensatori a basso ESR su Ebay e su Aliexpress e poi ho faticosamente proceduto al faticoso recapping. Dissaldare e saldare i cap è stata la cosa più facile, visto che non c’è stato verso di persuadere la MOBO a non bloccarsi in mancanza della scheda video e della tastiera. Il sistema effettua il boot correttamente, Caldera FreeDos parte, si avvia anche il batch del programma AMIQ, ma, scollegando VGA e tastiera, tutto si blocca.
Ho fatto moltissimi tentativi ed alla fine ho giocato la carta del nuovo BIOS: ho riflashato la motherboard con una versione meno vecchia del BIOS e tutto ha ripreso a funzionare in modo regolare. Per informazione, la motherboard è una MSI 5169 versione 4.0, della quale si trovano molte informazioni in rete (fortunatamente). Il disco installato è un 2.5″ di “vecchia scuola”, bassa densità di scrittura, bassa velocità di rotazione e daffidabilità garantita, anche se… ho fatto una immagine (non si sa mai).
Ed ecco qui la torre: AMIQ in testa, che genera una QPSK da una PRBS23, il buon SMIQ che modula una portante a 100MHz e FSEA20 che mostra lo spettro. Ho analizzato la trasmissione anche in modo vettoriale e la costellazione è pulita e perfetta. Sullo sfondo della foto si vede anche il software di controllo (WinIQsim), che gira su una macchina fisica con Windows XP e scheda PCI per la connessione GPIB con lo strumento. Che bello rivedere lo strumento funzionante.
Adesso tocca ad SMIQ ma per questo ci vogliono i professionisti… ne riparliamo!
Lavorando come ammaestratore di bit da qualche anno, la maggiore soddisfazione è nell’avere una rete che funziona bene e che garantisce le massime prestazioni che l’hardware consente. Inutile sperare di avere ciò che non si ha e mai si potrà realizzare, quindi accontentiamoci di quello che viene.
Nei giorni precedenti alcuni utenti della mia rete hanno fatto dei trasferimenti dati consistenti verso alcuni servizi di storage internazionale. Tanta tanta roba, trasferita in tanti giorni sfruttando la maggiore parte della banda disponibile.
E’ stata una sorpresa anche per me, arrivare in ufficio e trovare sul NMS un bel muro di bit che testimoniavano il corretto funzionamento del sistema.
Net Load su una interfaccia ottica.Net Load su un apparatoTraffico sulla interfaccia di uscita dell’ente.
Considerando che i nodi sono connessi ad 1Gbps, arrivare ad una banda di 973Mbps è (almeno per me) tanta roba. Non è tutta farina del mio sacco, ci sono anche altri colleghi che lavorano con me per fare in modo che questo “miracolo” si compia. Quindi grazie anche a loro!
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:
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 sistemaPressione 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.
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!
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.
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.
Due to a server failure, the AIS server is offline. Unfortunately we don’t have any spare hardware to setup a new environment with data backup. We will remain offline till new hardware comes.
Correzione di un piccolo BUG nel sito web che presenta i dati dell’AIS: se sono presenti delle imbarcazioni che hanno un apostrofo nel nome, la mappa non funziona. Ho corretto il codice, inserendo una piccola funzione che elimina del tutto gli apostrofi dal nome. Il precedente approccio con un escape character non era valido.
Ho aggiunto la funzione di “ricerca” informazioni nel menu a nuvola che si apre cliccando su una stazione. Adesso compare la voce “search” che redirige al sito di MarineTraffic e visualizza il risultato della ricerca di quel particolare MMSI. Interessante potere visualizzare le foto della imbarcazione e i dati aggregati raccolti da MarineTraffic.
In questi giorni di caldo ed umido, le VHF iniziano ad essere un bel terreno di caccia. Soprattutto su un mare caldo e chiuso come l’Adriatico. Puntuale come tutti gli anni si presentano condizioni molto vantaggiose per i collegamenti a lunga distanza. Questo non sfugge al nostro sistema AIS che il 30 maggio ha fatto registrare il “pienone”, come evidenziato dalla figura.
