chiarimento decodifica segnale infrarosso

nessuno?

Se ti accontenti:-p

homepage/jvc.htm

Secondo me no, 38kHz e' la portante, tu non la vedi, vedi solo le onde quadre con i tempi che dici, io userei un tempo che sia multiplo di quei segnali, che so 50us. Comunque inizierei a immagazzinare i dati a partire da un fronte (usando un interrupt?), e poi a cadenza di 50us (o 25us) continuerei a leggere o ad attendere il fronte contrario, immagazzinando l'onda o i tempi in cui cambia.

Se ti accontenti..., se non ricordo male dovrei avere un articolo che forse spiega come fare:-\

mandi

premetto che anch'io ne vorrei sapere di piu' perchè è da parecchio che cerco di capire come poter memorizzare un burst di informazioni ( quindi mi accodo alla tua richiesta) , comunque ....

e se misuri la durata di un evento quando esso si verifica ? Cioè: hai una determinata porta a zero, ad un certo punto la stessa passa a 1perchè si è verificato un interrupt (segnale infrarosso alto), contestualmente parte un timer che ne misura la durata. Quando la porta ritorna a zero, il timer si blocca e registri la durata dell'evento.

Che ne pensi ?

o che cerco di capire come poter memorizzare un burst di

la porta ritorna a zero, il timer si blocca e registri la

Di solito si usano le funzioni di capture dei timer. Con gli AVR posso spendere qualche commento in pi=F9, coi PIC no, sono prevenuto. :(

Tipicamente, quando cambia il fronte del segnale, il capture register memorizza il conteggio del timer e pu=F2 generare interrupt. Con (quasi) tutto comodo, il software legger=E0 tale valore memorizzato senza essere penalizzato da eventuali interrupt ancora pendenti o funzioni di disable_interrupt attive. Al prossimo capture_interrupt, si proceder=E0 a sottrarre il nuovo valore dal vecchio per conoscere il conteggio assoluto intercorso tra due fronti. E cos=EC via per i capture successivi. Di solito, quindi, il timer =E8 free-running. Questa condizione =E8 comoda perch=E9 pu=F2 essere usato anche per altre temporizzazioni (tramite i classici registri compare, ad esempio). Oppure in overflow per una base dei tempi utile ad altro (scansione di tasti, polling vari, ecc.).

Piccio.

Contrario ha scritto:

I 38KHz. sono di solito la frequenza della portante usata per trasmettere l'informazione.

Questo serve per decidere l'inizio della decodifica; devi aspettare un segnale alto per 9,5 mSec., poi 4 mSec. a livello low e, dopo aver ricevuto questi segnali, puoi iniziare a ragionare sui dati in arrivo.

Se dopo (600 + x uSec.), con x < di 550 uSec., il segnale e' basso, ricevi uno zero, altrimenti ricevi un uno. Poi aspetti che il segnale torni a uno e inizi la ricezione del nuovo bit...

Se prima hai registrato il tempo che intercorre fra un bit di start e l'altro e magari hai anche registrato il numero di bit che puoi ricevere, passare alla decodifica dovrebbe essere semplice. Spero di averti dato un punto di partenza. ciao Angelo

Ciao Mandi grazie in primis per la risposta

quindi potrei gestire il tutto con un contatore parallelo che viene resettato ad ogni cambio di fronte...(cioè se da 0 il valore della portaN passa ad 1) controllando di volta in volta il valore e quindi assegnando 0 oppure 1

tutto relativo alla frequenza di clock del circuito immagino...

inizio a fare un pò di prove...

spero di riuscire..

Contrario

Ciao Mario

anch'io ho pensato alla stessa idea...

ora provo a metterla in pratica...

ci aggiorniamo qui se ti va...

Contrario

Ciao Piccio... ok..ci sono..

grazie per il tuo tempo

Contrario

Ciao Angelo si...credo di aver inquadrato abbastanza bene il problema... mi metto all'opera e poi vi faccio sapere...

grazie per il tuo aiuto

Contrario

Frena gli entusiasmi! :) Tipicamente i telecomandi IR si avvalgono di due modi di emissione: flash e carrier. Normalmente =E8 usato il carrier mode, ovvero, burst di impulsi composti da almeno 6 impulsi IR. La durata ON dell'impulso viaggia spesso intorno agli 8 microsecondi mentre la durata OFF altri 16 microsec. o pi=F9, in funzione della frequenza della portante. Di fatto, i ricevitori IR tipici con tre pin demodulano e filtrano gi=E0 il segnale, per cui il fatto della frequenza della portante non riveste alcun impegno software, almeno nel ricevitore. Dal sensore esce quindi l'informazione gi=E0 demodulata, ovvero, onde quadre di periodi sull'ordine delle centinaia di microsecondi, gestibili comodamente da interrupt. I protocolli sono vari, ma ho notato in tantissimi telecomandi per telecamere che il protocollo si articola come segue:

- preambolo (periodo di lungo burst composto da un treno di impulsi avente lo scopo di stabilizzare il ricevitore IR e definire le temporizzazioni)

- codici (pacchetto di bit pi=F9 o meno lungo, minimo 16)

Probabilmente, nelle specifiche alcuni codici hanno funzioni precise. Dopo il preambolo, probabilmente trovi lo start_bit, utile per definire precisamente la base dei tempi del trasmettitore (molti usano risonatori ceramici non troppo precisi). Lo start bit, solitamente, corrisponde allo "0". Seguono i codici veri e propri, definibili in 2 campi: indirizzo e comando. Ho visto burst fino a 48 bit. In ultimo, un bit di parit=E0 per verificare la correttezza della ricezione. Pu=F2 essere presente anche un bit di stop. Dopo l'emissione, =E8 essenziale una pausa per distanziare i codici tra loro e sincronizzare il ricevitore.

Certi telecomandi, poi, hanno, nell'emissione di un comando, dei bit in toggle, cio=E8 variano durante l'emissione e in genere indicano la persistenza della pressione del comando o comunque la continuit=E0 della pressione del tasto (rari e forse abbandonati). Altri, dopo il rilascio del tasto, emettono un codice di fine_trasmissione, analogamente alle tastiere PC.

Venendo all'interpretazione dei codici, fa fede la distanza tra fronti identici pi=F9 che la durata del burst. Fissata una base dei tempi "T" (bit start), di soliti gli uni e gli zeri corrispondono a multipli (2T o 3T). Alcuni telecomandi sono anche posizionali (un "1" in posizione pari dura diversamente da quello in posizione dispari) per garantire maggiore immunit=E0. Un chip interessante =E8 l'M710 dell' ST. Lo implementai qualche tempo fa, sia in TX che in RX.

Ciao. Piccio.

Se usi gli AVR AT90S2313 posso inviarti i sorgenti di una sperimentazione funzionante, sia TX che RX. Posso anche pubblicarli qua: non sono "enormi".

Piccio.

eeeetttepareva a te che era così facile?!?!? non è mai troppo facile...vero?! ^_^

sarebbe comodo utilizzare l' INT0 (uso PIC) e far generare l'interrupt al cambiamento

Passato il 10 fallimento inizierò ank'io a pensarci a questo chip ^__^

Purtroppo uso PIC Piccio per l'esattezza ora sto usando il 16F877A

grazie mille in ogni caso per la tua disponibilità e competenza...

Contrario

Piccio ha scritto: (...)

ho fatto qualcosa di simile con un pic e protocollo rc5; l'approccio a input capture piuttosto che a timer fisso che sovracampiona il segnale è molto migliore, perchè spesso il trasmettitore è molto impreciso rispetto alle specifiche; con l'input capture ci si può quindi risincronizzare con l'ultimo fronte e addirittura impostare una tolleranza sui tempi minimi/massimi.

Non è impossibile da fare anche su un pic serie 16: certo molto piu macchinoso e indebuggabile del c sui pic24 che ho implementato io (una

"Contrario"

"Mario"

di capire come poter memorizzare un burst di

Nella programmazione in basic, c'e' un argomento che potrebbe essere attinente: "La codifica Manchester" chissà che non possa essere d'aiuto, visto che interpreta i fronti di salita e discesa. Comunque vediamo se qualcuno ne sa di piu' ....