Diario di laboratorio – Un NE555 a transistor come test per Giux-CalcLab
In questi giorni sto lavorando a Giux-CalcLab, un ambiente di calcolo scientifico che sto sviluppando sul mio server. Il primo modulo al quale sto dedicando attenzione è un simulatore SPICE basato su ngspice, con editor, gestione delle simulazioni server-side e un visualizzatore dei risultati.
Per metterlo alla prova volevo qualcosa di un po’ più interessante del solito circuito RC.
L’idea è stata semplice: provare a riprodurre il funzionamento di un NE555 utilizzando soltanto componenti discreti.
Non un modello SPICE del 555 e nemmeno un sottocircuito già pronto, ma transistor NPN e PNP, diodi, resistenze e condensatori.
Scarica la netlist:
Un test utile anche per il simulatore
Un circuito di questo tipo è interessante perché permette di verificare contemporaneamente parecchie cose:
- modelli personalizzati di transistor NPN e PNP;
- modelli di diodo;
- molti nodi interni;
- analisi transiente abbastanza lunga;
- misure automatiche con
meas; - visualizzazione contemporanea di diverse grandezze;
- gestione di una netlist significativamente più articolata di un semplice esempio didattico.
La simulazione è stata eseguita sul server e il risultato è arrivato regolarmente al nuovo Waveform Viewer.
Ed è qui che la prova è diventata più interessante del previsto.
Prima sorpresa: il circuito non oscilla
L’obiettivo era ottenere il comportamento tipico dell’astabile con 555: il condensatore di temporizzazione avrebbe dovuto caricarsi e scaricarsi fra due soglie, provocando la commutazione del latch interno e, di conseguenza, l’attivazione e la disattivazione del transistor di scarica.
La prima simulazione, invece, ha mostrato un circuito praticamente fermo.
L’uscita rimaneva alta e i diversi nodi interni tendevano rapidamente verso valori costanti.
Ho quindi separato nel viewer i segnali su due pannelli.
Nel primo ho osservato i nodi logici interni e l’uscita:
v(OUT)
v(QA)
v(QB)Nel secondo i segnali legati ai comparatori e al condensatore di temporizzazione:
v(CAP)
v(REFHI)
v(REFLO)
v(DISCH)Ed è stato immediatamente evidente dove cercare il problema.
Le soglie non erano dove avrebbero dovuto essere
Avevo utilizzato il classico divisore formato da tre resistenze uguali, concettualmente analogo a quello interno al 555.
Con un’alimentazione di 9 V mi sarei aspettato valori vicini a:
- 3 V per la soglia inferiore;
- 6 V per la soglia superiore.
La simulazione mostrava invece valori molto più bassi, circa 2,1 V e 4,2 V.
Anche il condensatore di temporizzazione rimaneva bloccato attorno a 3,1 V, senza riuscire a raggiungere la soglia superiore.
Il motivo è abbastanza semplice: nella mia prima implementazione gli stadi a transistor utilizzati come comparatori interagiscono troppo pesantemente con i nodi che dovrebbero semplicemente osservare: in particolare il nodo REFHI viene fortemente caricato, mentre anche il condensatore di temporizzazione risente dell’impedenza degli ingressi.
Il circuito quindi raggiunge un punto di equilibrio:
Il condensatore non raggiunge la soglia superiore
↓
Il comparatore non commuta
↓
Il latch rimane nello stesso stato
↓
Il transistor di scarica non interviene
↓
L’uscita rimane alta
In altre parole, il problema non era nel simulatore: mi stava mostrando esattamente un problema del circuito.
Anche gli errori sono risultati utili
La prova ha fatto emergere anche alcuni limiti dell’attuale validatore delle netlist.
Per ragioni di sicurezza, le simulazioni inviate al server vengono controllate prima dell’esecuzione. Il validatore è volutamente restrittivo, ma durante questa prova è diventato evidente che alcune regole sono ancora troppo semplicistiche.
Per esempio sono state inizialmente rifiutate sintassi SPICE perfettamente valide come nomi descrittivi dei componenti e dei nodi, oltre ad alcune forme di sorgente e di misura.
Per continuare il test ho temporaneamente rinominato gli elementi utilizzando identificatori semplici come:
R1
R2
Q1
Q2
D1
V1Il validatore dovrà essere migliorato in modo da interpretare il contesto sintattico della netlist, invece di considerare alcune parole o alcuni caratteri pericolosi indipendentemente dalla posizione in cui compaiono.
È uno di quei problemi che probabilmente non sarebbe emerso altrettanto facilmente utilizzando soltanto piccoli circuiti preparati appositamente come esempio.
Un vero test di laboratorio, anche se virtuale
Questo esperimento mi è piaciuto particolarmente perché rispecchia abbastanza bene il modo in cui normalmente lavoro al banco.
Si parte da un’idea, si costruisce qualcosa, si misura il comportamento e spesso il primo risultato non è quello previsto.
A quel punto il risultato sbagliato diventa più interessante di quello corretto, perché costringe a capire cosa sta succedendo.
In questo caso il “banco” era il mio server, gli strumenti erano ngspice e il visualizzatore delle forme d’onda, ma il procedimento è esattamente lo stesso.
La prossima è quindi modificare lo stadio dei comparatori per ridurre il carico sui nodi di riferimento e sul condensatore, fino ad ottenere finalmente la caratteristica carica e scarica fra circa 1/3 e 2/3 della tensione di alimentazione.
A quel punto vedremo se questo piccolo 555 discreto inizierà finalmente ad oscillare.
Un secondo circuito, più semplice: il multivibratore astabile
Il circuito discreto ispirato al 555 resta quindi da correggere. Nel frattempo, per continuare a mettere alla prova il simulatore con un circuito dal comportamento dinamico facilmente riconoscibile, ho caricato una seconda netlist: un classico multivibratore astabile realizzato con componenti discreti.
Scarica la netlist:
Questa prova è volutamente più semplice del tentativo precedente con il 555, ma è utile perché il comportamento atteso è molto chiaro: i due rami del multivibratore devono commutare alternativamente e produrre forme d’onda periodiche facilmente riconoscibili.
La simulazione è stata eseguita correttamente e, questa volta, il circuito oscilla davvero.
Segnali visualizzati nel Waveform Viewer
v(2) e v(3) — tensioni sui collettori dei due transistor principali del multivibratore.
v(4) e v(5) — tensioni sulle basi dei due transistor principali, influenzate dalla carica e scarica dei condensatori di accoppiamento.
v(6) e v(7) — uscite dei due stadi PNP collegati ai collettori del multivibratore.
v(8) e v(9) — tensioni dopo le rispettive reti RC di uscita, quindi versioni filtrate dei segnali dei due rami.
Interpretazione
A differenza del primo circuito ispirato al 555, che tendeva verso uno stato stazionario, qui si osserva immediatamente un comportamento periodico.
I due transistor principali commutano alternativamente: quando uno dei due conduce, il collettore scende verso massa mentre quello opposto risale verso la tensione di alimentazione. I condensatori di accoppiamento trasferiscono rapidamente le variazioni da un ramo all’altro e determinano, insieme alle resistenze di polarizzazione, il tempo necessario alla commutazione successiva.
Le forme d’onda dei due rami risultano quindi sostanzialmente complementari, mentre sui nodi di base si osservano le caratteristiche variazioni dovute alla carica e alla scarica dei condensatori.
Questa simulazione rappresenta un test più significativo per il sistema rispetto a un semplice circuito RC: vengono gestiti contemporaneamente più transistor, modelli NPN e PNP, diodi, diversi nodi interni, misure automatiche e più tracce distribuite su pannelli differenti.
Conclusione
C’è ancora parecchio lavoro da fare, sia sul simulatore sia sull’interfaccia, e queste prove stanno facendo emergere diversi dettagli da correggere e migliorare.
La cosa importante, però, è che il progetto comincia finalmente a prendere forma: le simulazioni vengono eseguite sul server, i risultati possono essere analizzati direttamente dal browser e il sistema sta diventando sempre più vicino all’idea iniziale.
Spero di poter arrivare presto a una versione abbastanza stabile da poterla condividere e far provare anche ad altri.