Quanto sono precisi i tempi di pulseIn ()?

Sto usando la pulseIn()funzione per elaborare la codifica dei dati binari basata su PWM. Funziona bene per distinguere gli impulsi che hanno lunghezze significativamente diverse, ad es. 500us contro 1500us. Ciò lo rende più che sufficiente per la gestione dei telecomandi IR tipici.

Tuttavia, voglio creare il mio sistema IR che può utilizzare più di 2 lunghezze di impulso, in modo che il trasferimento dei dati possa avvenire più rapidamente. Idealmente, vorrei usare 8 diverse lunghezze di impulso per la codifica ottale (ad es. 200us, 400us, 600us, ecc.).

Ho notato variazioni piuttosto significative nei valori restituiti da pulseIn()(+/- 10%). Mi aspetto che almeno in parte venga introdotto dai moduli trasmettitore e ricevitore IR, ma non ho abbastanza attrezzature per verificarlo.

Supponendo di poter mitigare quell'errore esterno, è pulseIn()probabile che sia abbastanza preciso da distinguere tali impulsi simili?

La funzione pulsein () è molto lossy, in quanto è un loop rigido e restituisce un numero * i cicli di clock previsti che impiega per loop

...
// wait for the pulse to stop
while ((*portInputRegister(port) & bit) == stateMask) {
  if (numloops++ == maxloops)
    return 0;
  width++;
}

// convert the reading to microseconds. The loop has been determined
// to be 20 clock cycles long and have about 16 clocks between the edge
// and the start of the loop. There will be some error introduced by
// the interrupt handlers.
return clockCyclesToMicroseconds(width * 21 + 16); 

Il metodo più accurato per catturare i tempi di un PIN è utilizzare la FUNZIONE DI IMMAGINE INGRESSO. Guarda questo esempio . Consente l'acquisizione dell'ingresso a 1x della CPU per la massima risoluzione e ogni fronte del pin di ingresso cattura il valore dell'orologio del timer per la lettura dal servizio di interruzione generato. Consente inoltre l'interruzione del trabocco del timer in modo da mantenere un tempo assoluto elevato, da acquisire. Poiché il 1x rotolerà piuttosto rapidamente. Le acquisizioni memorizzano il tempo in un array per la lettura dal loop principale.

Dove per segnali su IR la libreria tipica da usare è la libreria shirriff / Arduino-IRremote . Dove ha diverse demo in grado di leggere e inviare l'IR da un segnale demodulato. Consentire a uno di costruire uno schizzo del proprio design. Questo codice originariamente crea un interrupt del timer che esegue il polling del pin di input con una frequenza determinata da

#define USECPERTICK 50  // microseconds per clock interrupt tick

nel file IRremote.h. Per i miei scopi l'ho cambiato in 25 noi. Dove lo trovo ancora può mancare in modo intermittente flussi di impulsi.

Si noti che la demodulazione si realizza meglio all'interno del ricevitore IR, che a sua volta emette questo segnale di interesse. Dove aggiungere qualche sfondo. Utilizzando la tipica modulazione 38KHz, equivale a una risoluzione minima di 26,3 uS per ciclo di impulsi. La libreria di Sherriff mostra che la maggior parte dei baud o bit sono nell'ordine di 10+ impulsi. Che sembrano soddisfare i tempi desiderati.

microtherion / Arduino-IRremote fork del lavoro di shirriff migliora la ricezione sostituendo il polling di interruzione del timer del pin con l'uso di PinChangeInterrupts. Che ho unito nel mio fork mpflaga / Arduino-IRremote , che aggiunge molte altre funzionalità.

Quindi potresti usare una qualsiasi delle librerie sopra. Oppure crea la tua app che utilizza uno dei seguenti per acquisire bordi.

1. sondaggi su un evento Timer (ad es. 50uS)
2. cattura i micros () su un PinChangeInterrupt
3. usa Input Capture Interrupts per prendere l'ora esatta

Ecco alcuni dati di pulseIntest di un test. Un Arduino ha inviato quelli che avrebbero dovuto essere impulsi 14us, e l'altro ha sputato questi dati:

18,18,18,12,18,18,18,18,18,18,18,18,18,18,18,18,18,24,19,18,18,18,18,18,24, 18,18,18,19,18,18,12,18,18,19,18,18,18,18,18,18,18,18,18,18,18,19,18,19,24, 18,18,18,18,18,18,18,24,18,18,18,18,18,18,18,18,18,18,18,18,18,19,18,18,18, 18,18,18,18,18,18,18,19,18,18,18,11,18

Come puoi vedere, gli impulsi non sono affatto precisi. Il tempo sarebbe più preciso se le estremità di invio e ricezione fossero scritte in assemblea o addirittura scaricate sui propri processori.