GX-TXT-v3: prime misure con fotodiodo reale e telecomando IR
Dopo aver caratterizzato la GX-TXT-v3 utilizzando il fotodiodo virtuale, è arrivato il momento di passare al funzionamento per cui il circuito è stato effettivamente progettato: ricevere il segnale infrarosso prodotto da un telecomando reale.
Nelle prove precedenti il fotodiodo virtuale mi ha permesso di applicare alla scheda segnali controllati e ripetibili, studiando separatamente l’effetto della corrente equivalente, della regolazione della sensibilità e del numero di impulsi sul nodo HOLD e sul tempo di accensione del LED.
L’ultima parte di questa caratterizzazione è descritta nell’articolo precedente:
GX-TXT-v3: numero di impulsi, tensione HOLD e tempo di accensione del LED
In questa nuova sessione sostituisco quindi il generatore di corrente artificiale con un fotodiodo reale e utilizzo come sorgente un normale telecomando IR. L’obiettivo non è ancora effettuare una misura assoluta della potenza ottica, ma osservare come il circuito risponde a un segnale reale e cominciare a caratterizzarne in modo sperimentale la catena di ricezione.
In particolare voglio osservare direttamente il segnale ricevuto, riconoscere la portante IR, analizzare la struttura dei burst e verificare come questi segnali si propagano attraverso la GX-TXT-v3 fino alla carica del nodo HOLD e alla conseguente accensione del LED.
Poiché passando a una sorgente ottica reale anche la geometria della misura diventa importante, ho preparato un setup molto semplice per mantenere il più possibile costanti la distanza e la posizione relativa tra telecomando e fotodiodo. Non è un banco ottico di precisione, ma è sufficientemente riproducibile per ottenere misure comparative nelle stesse condizioni.
Per tutte le acquisizioni ho mantenuto una distanza di circa 20 cm tra il fotodiodo e l’emettitore IR del telecomando. La distanza e la posizione sono state controllate utilizzando la riga e i riferimenti visibili nel setup.
Setup utilizzato per le prove con fotodiodo reale. La riga, il riferimento sulla scatola e la posizione della scheda permettono di ripetere la geometria di misura con sufficiente accuratezza per confronti relativi.
Il fotodiodo utilizzato
Per queste prove ho utilizzato un EVERLIGHT PD333-3C/H0/L2, un fotodiodo PIN al silicio in contenitore plastico trasparente da 5 mm, scelto come ricevitore IR della GX-TXT-v3.
Il componente presenta una sensibilità spettrale compresa indicativamente tra 400 e 1100 nm, con massimo di sensibilità a 940 nm, quindi proprio nella regione normalmente utilizzata dai LED infrarossi dei telecomandi. Il datasheet specifica inoltre un tempo di salita e discesa tipico di circa 45 ns e una capacità totale tipica di 18 pF, valori che lo rendono ampiamente adeguato a seguire una portante nell’ordine dei 38 kHz utilizzata nelle prove.
Il datasheet riporta inoltre una corrente inversa illuminata tipica di circa 40 µA con irradianza di 1 mW/cm² a 940 nm e una corrente di buio tipica di circa 5 nA. Questi valori sono condizioni di caratterizzazione del componente e non devono naturalmente essere confusi con la corrente effettivamente prodotta nel setup sperimentale utilizzato in queste misure.
Datasheet ufficiale Everlight: PD333-3C/H0/L2 – datasheet PDF
Perché l’ampiezza su VIR non fornisce direttamente la fotocorrente
L’ampiezza misurata sul nodo VIR non può essere convertita direttamente nella fotocorrente generata dal fotodiodo. Nel fotodiodo virtuale la corrente era ricavabile facilmente dalla tensione ai capi della resistenza posta sull’emettitore del transistor, perché quel nodo aveva una relazione nota e sostanzialmente univoca tra tensione e corrente. Nel circuito reale, invece, il fotodiodo lavora direttamente sul nodo VIR e la tensione osservata dipende anche dall’impedenza equivalente presentata dall’intero stadio d’ingresso, che in questa prova non è stata misurata. Per questo motivo l’escursione di VIR va considerata qui come misura dell’ampiezza del segnale ricevuto, non come misura diretta della fotocorrente.
Elaborazione del segnale VIR con GNU Octave
L’acquisizione completa del nodo VIR contiene un numero molto elevato di campioni e non avrebbe senso analizzarla solamente osservando la traccia sullo schermo dell’oscilloscopio. Ho quindi esportato il segnale in formato CSV e sviluppato uno script specifico in GNU Octave, GXTXT_analisi_VIR_protocollo_v2_2.m, dedicato alla ricostruzione della struttura temporale del comando IR.
Lo script legge direttamente il formato CSV generato dal Rigol, ricostruisce l’asse temporale utilizzando i parametri Start e Increment e, prima di iniziare l’elaborazione completa, esegue un pretest rapido per verificare che il file sia leggibile e che il segnale contenga effettivamente una portante compatibile con quella attesa.
L’analisi determina automaticamente il livello di riposo di VIR, la polarità degli impulsi, la frequenza e il periodo della portante, la larghezza degli impulsi e il duty-cycle. Successivamente raggruppa i cicli consecutivi della portante nei diversi MARK, misura gli SPACE che li separano e ricava per ciascun burst durata e numero di cicli.
Il programma produce inoltre una tabella completa degli eventi MARK/SPACE, un riepilogo numerico e diversi grafici che permettono di passare dalla forma d’onda analogica acquisita sul fotodiodo a una rappresentazione temporale molto più leggibile del comando trasmesso.
Lo script non cerca volutamente di assegnare subito un nome al protocollo: l’idea è ricostruirne prima sperimentalmente portante, burst e intervalli temporali e confrontare solo successivamente questi dati con la struttura dei protocolli IR conosciuti.
Per chi volesse utilizzare o modificare lo script ho preparato anche un breve manuale d’uso, nel quale sono descritti il formato dei dati richiesto, il pretest, i livelli di verbosità, i principali parametri configurabili, i file prodotti e le indicazioni per l’esecuzione su PC o server.
download script:
Risultati dell’acquisizione sul nodo VIR
Per osservare l’intera trasmissione senza perdere il dettaglio della portante ho effettuato una seconda acquisizione più lunga, mantenendo un solo canale attivo sul nodo VIR. L’oscilloscopio è stato impostato a 50 ms/div con una profondità di memoria di 12 Mpts e una frequenza di campionamento di 10 MSa/s.
Il CSV risultante contiene quindi 12 milioni di campioni e copre circa 1,2 s, una finestra molto più ampia della durata effettiva della trasmissione osservata. Questo permette di verificare che gli eventi presenti nella registrazione non siano troncati dal termine dell’acquisizione.
L’oscillogramma mostra chiaramente una prima sequenza molto più articolata, seguita dopo alcune decine di millisecondi da un ulteriore burst isolato. A questa scala temporale non è possibile distinguere i singoli cicli della portante sul display dell’oscilloscopio, ma essi rimangono completamente conservati nei dati acquisiti grazie al campionamento a 10 MSa/s.
Portante IR
L’elaborazione con GNU Octave misura un periodo mediano della portante di 26,3 µs, corrispondente a una frequenza di 38,0 kHz.
La larghezza mediana degli impulsi rilevati sul nodo VIR è di 15,1 µs, dalla quale lo script ricava un duty-cycle apparente del 57,4 %.
Questo valore non rappresenta però direttamente il duty-cycle con cui viene pilotato il LED IR del telecomando. La misura viene effettuata sul nodo VIR, dopo la conversione ottico-elettrica del fotodiodo e attraverso la risposta analogica dello stadio d’ingresso; inoltre lo script determina la durata dell’impulso rispetto a una soglia posta al 30 % dell’escursione rilevata. Il valore va quindi interpretato come caratteristica della forma d’onda osservata su VIR, non come misura diretta del duty-cycle ottico del trasmettitore.
Il dettaglio della forma d’onda mostra inoltre che il segnale sul nodo VIR non è una semplice onda quadra ideale: i fronti presentano una forma arrotondata e l’ampiezza varia leggermente da ciclo a ciclo. Questo è del tutto compatibile con il fatto che stiamo osservando direttamente il comportamento del fotodiodo e dello stadio d’ingresso analogico, e non l’uscita digitale di un ricevitore IR integrato.
Struttura temporale della trasmissione
Lo script ha individuato complessivamente 35 intervalli nei quali la portante è presente, indicati come MARK, separati dagli intervalli di assenza della portante, indicati come SPACE. La porzione complessiva compresa tra il primo e l’ultimo evento riconosciuto dura circa 111,4 ms.
Le durate non sono distribuite casualmente, ma si raccolgono in pochi gruppi ben distinti. Dei 35 MARK rilevati, 33 hanno una durata mediana di circa 568 µs; sono inoltre presenti un MARK di circa 9,02 ms e un ulteriore MARK isolato di circa 3,20 ms.
| Evento | Durata caratteristica | Numero di occorrenze |
|---|---|---|
| MARK breve | 568 µs | 33 |
| MARK lungo | 9,021 ms | 1 |
| MARK isolato finale | 3,201 ms | 1 |
| SPACE breve | 590,6 µs | 20 |
| SPACE lungo | 1,6966 ms | 12 |
| SPACE iniziale lungo | 4,5404 ms | 1 |
| SPACE molto lungo | 44,1726 ms | 1 |
In particolare risultano molto evidenti due famiglie ricorrenti di SPACE, una attorno a 0,59 ms e una attorno a 1,70 ms. Anche i MARK associati alla parte centrale della trasmissione presentano invece una durata sostanzialmente costante.
Rappresentazione dell'intera acquisizione del nodo VIR mediante massimo e minimo locale. La lunga finestra temporale permette di distinguere la trasmissione dal restante intervallo di quiete.
Come leggere il riepilogo
GX-TXT-v3 - ANALISI VIR / PROTOCOLLO IR - V2.4
============================================================
CSV : VIR_10x_DC_50ms_12M.csv
Campioni : 12000000
Sample rate : 10.000000 MSa/s
Durata acquisita : 1199.999900 ms
VIR
------------------------------------------------------------
Baseline : 8.880000 V
Polarita : impulsi verso il basso
Ampiezza pretest : 2.840000 V
Soglia : 0.852000 V rispetto baseline
PORTANTE
------------------------------------------------------------
Periodo mediano : 26.300000 us
Frequenza : 38.022814 kHz
Pulse width mediana : 15.100000 us
Duty-cycle stimato : 57.414 %
COMANDO
------------------------------------------------------------
Burst MARK : 35
Inizio : -0.015100 ms
Fine : 111.415900 ms
Durata : 111.431000 ms
CLASSI MARK [us]
Classe Mediana Media Min Max N
1 568.000 556.879 541.600 594.400 33
2 3201.400 3201.400 3201.400 3201.400 1
3 9021.100 9021.100 9021.100 9021.100 1
CLASSI SPACE [us]
Classe Mediana Media Min Max N
1 590.600 584.020 564.200 590.700 20
2 1696.600 1703.175 1696.500 1722.900 12
3 4540.400 4540.400 4540.400 4540.400 1
4 44172.600 44172.600 44172.600 44172.600 1
Il file di riepilogo raccoglie in forma compatta i principali risultati numerici ricavati automaticamente dallo script. La prima parte descrive l’acquisizione: numero di campioni, frequenza di campionamento e durata complessiva della registrazione. Seguono i parametri del nodo VIR, cioè livello di riposo, polarità del segnale, ampiezza rilevata nel pretest e soglia utilizzata per distinguere la presenza della portante.
La sezione PORTANTE riporta periodo, frequenza, larghezza mediana degli impulsi e duty-cycle. Nel caso analizzato la frequenza misurata è circa 38,0 kHz, con un periodo di 26,3 µs.
La sezione COMANDO indica invece quanti MARK sono stati riconosciuti e l’intervallo temporale compreso tra il primo e l’ultimo evento rilevato. Infine, le tabelle CLASSI MARK e CLASSI SPACE raggruppano automaticamente le durate simili, riportandone mediana, media, minimo, massimo e numero di occorrenze. È proprio questa suddivisione in poche classi temporali ricorrenti che consente, nel passo successivo, di ricostruire la codifica logica del comando senza dover interpretare manualmente milioni di campioni.
Dal segnale al protocollo IR
Una volta ricostruita la successione dei MARK e degli SPACE, il passo successivo consiste nel capire quale protocollo abbia prodotto quella particolare struttura temporale. Non è sufficiente conoscere la sola frequenza della portante: molti protocolli utilizzano frequenze molto simili, spesso comprese tra 36 e 40 kHz.
Per riconoscere un protocollo conviene quindi considerare contemporaneamente diversi elementi: frequenza della portante, tipo di codifica, durata dell’intestazione iniziale, durata dei MARK e degli SPACE elementari, numero di bit trasmessi e comportamento durante la ripetizione del comando.
Un primo elemento particolarmente utile è il modo in cui vengono rappresentati i bit. Nei protocolli a pulse distance, come NEC, è principalmente la durata dello SPACE a distinguere uno 0 da un 1, mentre il MARK rimane pressoché costante. Nei protocolli a pulse width, come Sony SIRC, avviene sostanzialmente il contrario. RC5 e RC6 utilizzano invece una codifica bifase, nella quale l’informazione è associata alle transizioni del segnale.
| Protocollo | Portante tipica | Codifica | Intestazione indicativa | Tempi caratteristici | Lunghezza tipica |
|---|---|---|---|---|---|
| NEC | 38 kHz | Pulse distance | MARK 9 ms + SPACE 4,5 ms | MARK ≈560 µs; SPACE ≈560 / 1690 µs | 32 bit |
| Samsung | 38 kHz | Pulse distance | MARK ≈4,5 ms + SPACE ≈4,5 ms | MARK ≈560 µs; SPACE ≈560 / 1680 µs | 32 bit, con varianti |
| Panasonic / Kaseikyo | 37 kHz | Pulse distance | MARK ≈3,46 ms + SPACE ≈1,73 ms | MARK ≈432 µs; SPACE ≈432 / 1296 µs | 48 bit |
| Sony SIRC | 40 kHz | Pulse width | MARK ≈2,4 ms | MARK ≈600 / 1200 µs; SPACE ≈600 µs | 12, 15 o 20 bit |
| Philips RC5 | 36 kHz | Bifase / Manchester | Non usa un leader analogo a NEC | Unità temporale ≈889 µs | 14 intervalli logici circa |
| Philips RC6 | 36 kHz | Bifase | MARK ≈2,67 ms + SPACE ≈0,89 ms | Unità temporale ≈444 µs | Dipende dalla variante |
La tabella è volutamente sintetica e serve soltanto come guida al riconoscimento. Esistono numerose varianti e protocolli differenti possono condividere una parte dei tempi caratteristici. Per una trattazione più completa rimando alle fonti indicate, evitando di replicarne qui la descrizione dettagliata.
Fonti utilizzate per il confronto dei protocolli IR
Per il confronto dei protocolli ho utilizzato principalmente due riferimenti. SB-Projects – IR Remote Control Theory fornisce una spiegazione molto chiara dei principi della trasmissione IR, della portante, dei MARK e degli SPACE e delle diverse tecniche di codifica; le pagine dedicate ai singoli protocolli sono utili per approfondirne struttura e temporizzazioni. link a SB-Projects – IR Remote Control Theory Arduino-IRremote è invece un riferimento particolarmente utile per verificare in modo operativo i protocolli attualmente gestiti, le frequenze di portante e la distinzione tra codifica pulse distance, pulse width e bifase/Manchester. La libreria include, tra gli altri, NEC, Samsung, Panasonic/Kaseikyo, Sony, RC5 e RC6. link a Arduino-IRremote
Identificazione automatica del protocollo
Dopo aver ricostruito la sequenza MARK/SPACE ho utilizzato un secondo script GNU Octave, GXTXT_identifica_protocollo_IR_v1.m, con lo scopo di confrontare automaticamente i dati sperimentali con alcuni dei protocolli IR più comuni.
Lo script utilizza il file eventi_mark_space.csv prodotto dall’analisi precedente e considera contemporaneamente la frequenza della portante, la struttura dell’header, le durate dei MARK e degli SPACE e il numero di bit riconosciuti. I protocolli considerati in questa prima versione sono NEC family, Samsung, Panasonic/Kaseikyo, Sony SIRC, Philips RC5 e Philips RC6.
Il risultato non viene deciso sulla base di un singolo parametro: a ogni protocollo viene assegnato uno score che rappresenta quanto i tempi misurati si discostano da quelli attesi. Più piccolo è lo score, migliore è la corrispondenza. Quando la struttura lo permette, lo script prova inoltre a ricostruire direttamente la sequenza di bit e i byte trasmessi.
GX-TXT-v3 - IDENTIFICAZIONE PROTOCOLLO IR - V1
============================================================
Eventi sorgente : eventi_mark_space.csv
Portante : 38.022814 kHz
CLASSIFICA
------------------------------------------------------------
1) NEC family score= 0.0084 ALTA
header err 0.006, carrier err 0.001, data err 0.019, mark err 0.014, bit=32
2) Samsung score= 0.1877 POSSIBILE
header err 0.514, carrier err 0.001, data err 0.026, mark err 0.014, bit=32
3) Sony SIRC score= 0.2058 POSSIBILE
header err 0.389, carrier err 0.049, bit-mark err 0.053, space err 0.060, bit=28
4) Philips RC5 score= 0.2212 POSSIBILE
carrier err 0.056, header err 0.000, biphase-unit err 0.361
5) Philips RC6 score= 0.3053 BASSA
carrier err 0.056, header err 0.561, biphase-unit err 0.271
6) Panasonic / Kaseikyo score= 0.3279 BASSA
header err 0.423, carrier err 0.028, data err 0.329, mark err 0.315, bit=19
RISULTATO
------------------------------------------------------------
Candidato migliore : NEC family
Score : 0.0084
Confidenza : ALTA
Bit riconosciuti : 32
Bit TX-order : 00010000011010000100110110110010
Byte LSB-first : 0x08 0x16 0xB2 0x4D
NEC addr complement : NO
NEC cmd complement : SI
Interpretazione : NEC extended / variante NEC-family possibile
NOTA
L'identificazione e' basata sui timing misurati. Protocolli o varianti
che condividono la stessa modulazione possono richiedere analisi del
payload, del repeat frame o del comportamento su pressioni prolungate.
Interpretazione del risultato
Il confronto individua con margine netto la famiglia NEC: lo score ottenuto è 0,0084, classificato dallo script con confidenza alta, mentre il secondo candidato, Samsung, si ferma a 0,188. Vengono inoltre riconosciuti esattamente 32 bit.
La sequenza ricostruita corrisponde ai quattro byte 08 16 B2 4D, interpretati con ordine LSB-first. Il byte del comando, 0xB2, è seguito correttamente dal suo complemento 0x4D, mentre i primi due byte non sono complementari tra loro. Per questo lo script non classifica il frame come NEC standard, ma come NEC extended o comunque variante della famiglia NEC, con indirizzo a 16 bit 0x1608 e comando 0xB2.
È importante distinguere i due livelli dell’analisi: dai tempi misurati l’appartenenza alla famiglia NEC risulta molto forte; l’interpretazione più specifica come NEC extended deriva invece dalla struttura dei quattro byte e va quindi considerata il passo successivo della decodifica, non semplicemente il risultato della misura della portante.
Verifiche di coerenza della decodifica
I risultati permettono anche alcune verifiche interne indipendenti. Il frame contiene 33 MARK brevi, mentre i bit decodificati sono 32: il MARK aggiuntivo è proprio quello necessario a chiudere la trasmissione dell’ultimo bit. La struttura osservata risulta quindi coerente anche dal semplice conteggio degli eventi.
Una seconda verifica si ottiene contando gli SPACE. Nella parte dati sono presenti 20 SPACE brevi e 12 SPACE lunghi, per un totale di 32 bit. Nella codifica ricostruita gli SPACE lunghi corrispondono ai bit logici a 1: contando gli 1 nei quattro byte 08 16 B2 4D se ne ottengono esattamente 12. Il conteggio degli eventi temporali e la decodifica dei byte arrivano quindi indipendentemente allo stesso risultato.
Anche la temporizzazione macroscopica fornisce un’ulteriore conferma. Terminato il frame principale, viene misurato uno SPACE di circa 44,17 ms seguito da un nuovo MARK; sommando la durata del frame precedente, questo nuovo evento inizia circa 109 ms dopo l’inizio della prima trasmissione, valore compatibile con il periodo di ripetizione della famiglia NEC, dell’ordine di 108–110 ms.
L’ultimo MARK dura però solamente circa 3,20 ms e non costituisce quindi un repeat NEC completo, che dovrebbe iniziare con un MARK di circa 9 ms seguito da uno SPACE di circa 2,25 ms. Una possibile spiegazione è che la trasmissione sia stata interrotta dal rilascio del pulsante durante l’inizio del repeat; questa interpretazione resta tuttavia un’ipotesi e può essere verificata facilmente con una nuova acquisizione mantenendo il tasto premuto più a lungo.
Conclusioni
Con queste misure la GX-TXT-v3 è passato dal fotodiodo virtuale utilizzato nelle precedenti caratterizzazioni a una sorgente IR reale. Il test è stato volutamente limitato a un solo telecomando e all’osservazione diretta del nodo VIR: lo scopo non era ancora caratterizzare l’intera catena di amplificazione e rivelazione, ma verificare cosa fosse possibile ricavare direttamente dal segnale prodotto dal fotodiodo.
Il risultato è già piuttosto completo. Il segnale su VIR permette di osservare chiaramente la portante a circa 38,0 kHz, distinguere i singoli burst, ricostruire la successione di MARK e SPACE e, partendo esclusivamente dai dati acquisiti con l’oscilloscopio, arrivare alla sequenza binaria trasmessa e all’identificazione della famiglia del protocollo.
Anche gli strumenti software sviluppati durante la prova sono diventati parte del sistema di misura: il primo script trasforma il CSV dell’oscilloscopio in una descrizione temporale del segnale, mentre il secondo confronta la sequenza ottenuta con alcuni protocolli IR comuni. Questo permette di mantenere separata l’osservazione sperimentale dall’interpretazione successiva dei dati.
Questa prova non rappresenta però ancora una caratterizzazione completa della GX-TXT-v3. Ho osservato principalmente il nodo VIR e utilizzato un solo telecomando; resta quindi da studiare come segnali differenti attraversino i successivi stadi del circuito e come le loro caratteristiche si riflettano sul nodo HOLD e, infine, sul tempo di accensione del LED.
Il passo successivo sarà quindi provare diversi telecomandi reali, acquisendone i segnali e cercando di identificarne sperimentalmente i protocolli. Non sarà necessario ripetere per tutti acquisizioni estremamente dettagliate come quella utilizzata in questo articolo: una volta verificato il metodo, sarà possibile privilegiare il confronto tra portante, struttura dei burst e protocollo riconosciuto.
Una seconda serie di prove potrà poi tornare sul comportamento della GX-TXT-v3 vero e propria. L’idea è scegliere un telecomando di riferimento, regolare il trimmer di GAIN in modo da ottenere una condizione definita con il trimmer di SENSE circa a metà corsa e utilizzare quella configurazione per confrontare telecomandi differenti osservando soprattutto la tensione raggiunta su HOLD e il conseguente tempo di accensione del LED. In questo modo sarà possibile collegare finalmente le caratteristiche del segnale IR reale alla risposta complessiva del circuito.