GX LII-2 – Diario di laboratorio: misure di Bode ed elaborazione con GNU Octave

Introduzione

Oggi ho passato diverse ore al banco cercando di portare avanti le nuove campagne di misura, ma una parte consistente del tempo se n’è andata per inseguire un problema che inizialmente sembrava provenire dal circuito sotto prova.

Durante le acquisizioni compariva infatti un rumore ad alta frequenza, con andamento a burst. Ero praticamente convinto che la causa fosse l’alimentatore: il disturbo compariva e scompariva senza una logica evidente e, in alcuni momenti, spariva completamente. Sono arrivato quindi a sostituire l’alimentatore, ma il problema si è ripresentato identico.

A quel punto ho iniziato a guardare con più attenzione tutta la catena di collegamento e ho finalmente individuato la causa: uno dei cavi BNC RG58 aveva il connettore danneggiato e presentava un falso contatto sulla massa. Muovendo il cavo il collegamento poteva tornare temporaneamente normale, spiegando perché in alcuni momenti il rumore sembrava sparire senza motivo. Ho quindi sostituito il connettore e il disturbo è scomparso.

Una parte delle acquisizioni effettuate sul partitore da 100 Ω + 100 Ω è stata quindi registrata mentre questo difetto era ancora presente. Per il momento ho deciso di conservarle: il disturbo è prevalentemente ad alta frequenza e appare in larga parte comune ai due canali, mentre l’elaborazione in GNU Octave ricava la funzione di trasferimento dal rapporto tra i segnali e dalla componente fondamentale estratta mediante il fit armonico. Per questo mi aspetto che l’effetto sul risultato finale sia limitato, ma non considero queste acquisizioni definitive: se durante il confronto con le altre serie dovessero emergere anomalie, rifarò senza problemi le misure interessate.

Risolto il guasto, ho potuto riprendere il lavoro vero e proprio della giornata: nuove acquisizioni sul banco di calibrazione e soprattutto un’importante evoluzione dello script GNU Octave che utilizzo per elaborare automaticamente le misure A/B.

Automazione della preparazione delle acquisizioni

La prima modifica che ho introdotto oggi riguarda una parte molto semplice del lavoro, ma che diventa rapidamente noiosa quando le frequenze da acquisire iniziano a essere molte.

Fino ad ora, per ogni nuova serie di misura dovevo preparare manualmente i nomi dei file da utilizzare sull’oscilloscopio, rinominarli successivamente sul PC e infine creare il file di associazione utilizzato dallo script GNU Octave per collegare ogni frequenza alle corrispondenti acquisizioni A e B. Con 30 frequenze, e quindi 60 acquisizioni per una singola serie, è un lavoro ripetitivo e soprattutto facile da sbagliare.

Ho quindi scritto un piccolo script per Windows che automatizza tutta questa preparazione. Lo script riceve in ingresso un semplice file di testo contenente l’elenco delle frequenze da acquisire, chiede le directory di lavoro e genera automaticamente tutti i file necessari.

Per utilizzarlo è sufficiente creare un file .txt nel quale ogni riga contiene una frequenza espressa in kHz, ad esempio:

10kHz
20kHz
30kHz
50kHz
80kHz
100kHz
120kHz
140kHz
160kHz
180kHz
200kHz
220kHz
240kHz
260kHz
280kHz
300kHz
320kHz
350kHz
370kHz
400kHz
430kHz
450kHz
480kHz
500kHz
530kHz
550kHz
580kHz
600kHz
650kHz
700kHz

A partire da questo elenco lo script crea i file destinati alle acquisizioni dell’oscilloscopio, inizialmente contenenti semplicemente la scritta VUOTO, e prepara anche il file di associazione che verrà poi utilizzato dallo script di elaborazione in GNU Octave.

In questo modo, prima di iniziare una campagna di misura, tutta la struttura dei file è già pronta: durante le acquisizioni devo semplicemente sovrascrivere i file predisposti con i CSV prodotti dall’oscilloscopio, senza dover ogni volta riscrivere o ricostruire manualmente nomi e associazioni.

Metto a disposizione qui anche lo script; le istruzioni complete sono contenute nel file stesso, ma per l’utilizzo normale è sufficiente preparare l’elenco delle frequenze, una per riga, e seguire le richieste visualizzate durante l’esecuzione.

Lo script Octave è diventato il programma di analisi del GX LII-2

Parallelamente alle misure ho continuato a sviluppare lo script GNU Octave utilizzato per l’elaborazione dei CSV acquisiti con l’oscilloscopio. La versione attuale, bode_batch_macro_armoniche_clipping_v4.m, ormai fa parecchio di più rispetto alle prime versioni, che avevano essenzialmente il compito di ricavare modulo e fase.

A questo punto lo considero a tutti gli effetti il programma di analisi del banco GX LII-2.

L’ingresso rimane volutamente semplice: una tabella associa a ogni frequenza i file delle acquisizioni A e B. La misura B può anche mancare, mentre nei CSV Rigol mantengo sempre la stessa convenzione:

CH1 = VSENSE
CH2 = VOUT

e quindi:

Estrazione della fondamentale e analisi armonica

Per ciascun canale lo script non utilizza direttamente il valore picco-picco della forma d’onda, ma esegue un fit ai minimi quadrati comprendente offset DC, fondamentale e armoniche.

Nella configurazione attuale utilizzo tre armoniche. Il diagramma di Bode viene però calcolato esclusivamente dalla fondamentale: da CH1 e CH2 vengono ricavati i rispettivi fasori complessi e successivamente il rapporto che fornisce modulo e fase.

Questo rende l’elaborazione molto selettiva alla frequenza realmente iniettata. Rumore, burst e componenti a frequenze differenti finiscono principalmente nel residuo del fit invece di entrare direttamente nel calcolo del Bode.

Le armoniche rimangono comunque disponibili come diagnostica. Per ogni canale vengono infatti riportati H2 e H3, il loro livello in dBc, il THD, l’RMS del residuo e l’offset DC. Questi parametri non modificano il risultato del Bode, ma sono molto utili per capire in quali condizioni è stata effettuata la misura.

Compensazione delle acquisizioni A e B

Una volta elaborate tutte le frequenze viene effettuato l’unwrap della fase e la misura B viene riportata sulla branca corretta di 360°.

Quando entrambe le orientazioni sono disponibili, il risultato finale viene ottenuto combinando A e B. È questa la compensazione che sto utilizzando per ridurre la componente di errore antisimmmetrica introdotta dall’orientamento del trasformatore.

Nel modello che sto utilizzando:

per cui la combinazione delle due orientazioni permette di eliminare la componente antisimmmetrica EA​, lasciando quella comune EC​.

Se l’acquisizione B non è disponibile, lo script utilizza semplicemente la misura A.

Confronto automatico con LTspice

È rimasto anche il confronto con la simulazione LTspice. Se fornisco il relativo file, lo script importa modulo e fase, esegue l’unwrap, interpola la simulazione alle frequenze realmente misurate e porta anche la fase simulata sulla branca corretta.

Per ogni punto vengono quindi calcolati gli scarti:

oltre agli errori medi assoluti di modulo e fase.

Una nuova diagnostica della deformazione della forma d’onda

La novità più importante della versione attuale riguarda la ricerca di compressione o deformazione coerente della sinusoide.

Non volevo costruire un semplice detector che reagisse a un singolo picco, perché proprio le misure di oggi hanno mostrato quanto facilmente possano comparire burst o disturbi impulsivi completamente estranei alla reale distorsione del segnale.

Lo script ripiega quindi tutti i cicli acquisiti su un unico periodo, divide il periodo in 180 intervalli di fase e, per ogni intervallo, calcola la mediana dei campioni appartenenti ai diversi cicli.

Si ottiene così una forma d’onda rappresentativa estremamente più robusta rispetto all’osservazione di un singolo ciclo: spike, burst e rumore non coerente tendono a essere fortemente attenuati dalla mediana.

Da questa forma viene sottratta la fondamentale ideale. Prima di valutare la deformazione viene inoltre eliminato qualsiasi spostamento verticale globale, in modo che una sinusoide semplicemente traslata verso l’alto o verso il basso non venga interpretata come distorta. Lo shift rimosso viene comunque registrato nel report.

La ricerca della compressione non viene effettuata soltanto sul punto massimo e minimo, ma su due regioni estese attorno alle creste positiva e negativa della sinusoide. In questo modo posso distinguere una deformazione prevalente sul semiperiodo positivo, su quello negativo oppure su entrambi.

Inoltre non è sufficiente che il residuo sia grande: almeno il 75% della regione interessata deve mostrare una deviazione con segno coerente con la deformazione cercata.

Questa condizione si è rivelata particolarmente interessante proprio oggi. Il rumore prodotto dal falso contatto del cavo BNC aumentava enormemente il residuo della misura, ma non possedeva la struttura coerente richiesta dal detector, e quindi non veniva classificato come clipping.

Le soglie che sto utilizzando attualmente sono indicative: sotto il 2% non considero significativa la deformazione, tra 2 e 5% viene prodotto un warning e oltre il 5% la deformazione viene segnalata come forte.

È però importante chiarire il significato di questa diagnostica: il programma può evidenziare una deformazione coerente della forma d’onda, ma questo da solo non dimostra che la causa sia una Vgen troppo elevata. Per stabilire una relazione causale bisogna verificare sperimentalmente che la deformazione cresca aumentando Vgen.

Altre informazioni ricavate automaticamente

Lo script calcola anche l’asimmetria A/B in modulo e fase, cerca automaticamente eventuali crossing a 0 dB e 0° e può effettuare un fit razionale opzionale della funzione di trasferimento complessa.

Nella configurazione attuale il fit utilizza 3 poli e 1 zero e riporta posizione dei poli e degli zeri, appartenenza a LHP o RHP, frequenze equivalenti e RMS dell’errore del modello in dB e gradi.

Anche questa parte è indipendente dalla diagnostica della deformazione: serve semplicemente a ottenere ulteriori informazioni dalla funzione di trasferimento misurata.

Output automatici

Al termine di ogni elaborazione vengono prodotti automaticamente:

..._risultato.txt
..._misure_A.txt
..._misure_B.txt
..._misure_finali.txt
..._modulo.png
..._fase.png
..._clipping.png

Il report completo contiene quindi praticamente tutto ciò che mi serve per ricostruire successivamente una misura: fondamentali, armoniche, THD, residui, offset, diagnostica della deformazione, asimmetria A/B, risultato compensato, confronto LTspice, errori, crossing e stima di poli e zeri.

La catena di elaborazione è ormai diventata sostanzialmente:

CSV → fit armonico → fasori fondamentali → misure A/B → unwrap e allineamento → compensazione A/B → confronto LTspice

mentre, parallelamente:

forme d’onda → ripiegamento dei cicli → mediana per fase → rimozione dello shift → ricerca della deformazione coerente

Il vantaggio è che, mentre le campagne sperimentali stanno diventando sempre più lunghe, una parte crescente dell’analisi viene eseguita in modo ripetibile e documentato dallo stesso programma.

Un esempio dell’output dello script

Per mostrare concretamente il tipo di elaborazione prodotto dalla nuova versione dello script, ho utilizzato una delle serie acquisite oggi sul partitore 100 Ω + 100 Ω con Vgen variabile. La campagna comprende 30 frequenze e, per ciascun punto, le due acquisizioni A e B; lo script lavora sui CSV completi, con fit armonico a tre componenti e con la convenzione CH1 = VSENSE, CH2 = VOUT.

Non voglio ancora utilizzare questa serie per trarre conclusioni definitive sul comportamento del banco: una parte delle acquisizioni è stata effettuata prima di individuare il problema del connettore BNC descritto all’inizio dell’articolo. In questa fase mi interessa soprattutto usarla per mostrare cosa restituisce automaticamente il programma.

Il primo output è il normale grafico del modulo. Sono riportate separatamente la misura A e la misura B, il riferimento LTspice, la loro combinazione finale e il fit poli/zeri. Le due orientazioni del trasformatore mostrano chiaramente errori di segno opposto, mentre la curva risultante dalla combinazione A/B rimane molto più vicina al riferimento. Ad esempio, tra 50 e 120 kHz il risultato finale rimane compreso tra circa 0,01 e 0,04 dB.

Lo stesso avviene nel grafico della fase, dove vengono visualizzati A, B, la media compensata, LTspice e il modello ottenuto dal fit razionale. Anche qui lo scopo della figura non è ancora valutare quantitativamente il banco, ma verificare immediatamente il comportamento delle due acquisizioni e il risultato prodotto dalla compensazione.

Il terzo grafico è invece dedicato alla nuova diagnostica globale della deformazione. Per ciascuno dei due canali, nelle configurazioni A e B, viene rappresentato l’indice di compressione coerente calcolato dallo script. Le due linee orizzontali indicano le soglie attualmente impostate al 2% per il warning e al 5% per una deformazione elevata.

Questa diagnostica non deriva dall’osservazione di un singolo picco: il programma ripiega molti cicli sulla stessa fase, utilizza la mediana e richiede che la deformazione sia coerente su una regione estesa della forma d’onda. Nel report vengono quindi distinti casi di possibile compressione da condizioni nelle quali il residuo può essere elevato ma manca una struttura coerente, situazione compatibile invece con rumore o spurie.

È proprio il tipo di controllo che mi interessa avere durante le prossime campagne: non soltanto ottenere automaticamente modulo e fase, ma avere insieme alla misura anche gli elementi necessari per capire quanto posso fidarmi del punto acquisito e in quali condizioni è stato ottenuto.

I post precedenti