Dal tuo ultimo commento, suggerirei di sovracampionare l'input. Registra diversi campioni consecutivi, quindi il tuo output dovrebbe essere qualunque sia la maggior parte dei campioni registrati.

Ad esempio, supponi di registrare 10 campioni. Se si verifica un picco di rumore, solo uno o due dei campioni saranno danneggiati, mentre la maggior parte di essi è il valore corretto. Se ottieni dati effettivi, alla fine gli 1 supereranno gli 0 e l'output cambierà.

Esistono molti modi per lavorare con il rumore nel software e stanno diventando sempre più efficaci da implementare nel software invece che nell'hardware, riducendo i costi di sistema.

Invece di cercare di spiegarlo da solo, io ti passerò a Jack Ganssle, un consulente di sistemi embedded di cui sono cresciuto leggendo gli articoli di.

Ha un elenco dei suoi articoli online, il primo che vorrei che vedessi è sul rumore analogico nei sistemi embedded. Il secondo articolo a cui devo collegarti riguarda l ' utilizzo di software per ridurre il rumore nel tuo sistema.

Suggerirei anche il suo articolo su levigare gli ingressi digitali e sistemi di autocalibrazione. Dopo aver passato del tempo a lavorare con i sistemi embedded, ho raccolto alcune di queste informazioni dai miei errori, ma mi è piaciuto molto leggere i suoi modi di pensare. Il sistema di autocalibrazione era molto ovvio per me, ma il modo in cui suggeriva di farlo era prezioso per me. Potresti non aver bisogno delle informazioni, ma i suoi articoli mi hanno aiutato.

Ho scoperto che Digital Signal Processing e il microcontrollore di Grover e Deller sono l'unico libro sui filtri che posso capire. Sfortunatamente, è difficile da trovare a buon mercato.

http://www.google.com/books?id=GzVmQgAACAAJ

Il tuo software esegue il polling di questo input o utilizzi uno schema di interrupt per elaborarlo?

Se stai effettuando il polling, presumibilmente leggi l'input a una velocità molto più alta rispetto ai cambiamenti previsti nel segnale. Se il rumore è ben separato, picchi di frequenza molto alta, questi sembrerebbero campioni isolati di polarità "sbagliata". È possibile mitigare questo problema mantenendo gli N campioni più recenti e decidendo di leggere l'input come qualsiasi polarità sia la maggioranza. Ad esempio, se N = 5, se hai 3, 4 o 5 bit "1", il tuo input è un "1"; se hai 0, 1 o 2 bit "1", il tuo input è uno "0". Questo è in realtà solo una sorta di filtro passa-basso nel software.

Se stai usando l'ingresso per attivare gli interrupt al cambiamento (entrambi i fronti), puoi fare in modo che la routine di interrupt (ISR) avvii un timer per causare una seconda interruzione poco dopo, ma più lungo del tempo di picco del rumore. Anziché fare in modo che il pin di ingresso ISR accumuli direttamente i bit di segnale, lo fai fare al timer ISR. Ad esempio, se il segnale è basso e arriva un picco alto, il fronte di salita avvia il timer, ma prima che il conteggio del timer scada, il fronte di discesa del picco lo reimposta, quindi quando l'interruzione del timer alla fine si spegne, tu stai guardando il segnale, non il rumore. Il segnale, d'altra parte, darà il via al timer solo una volta e il timer ISR sarà in grado di acquisire il nuovo livello di segnale.

Di questi due, Polled vs Interrupt, personalmente andrei per l'approccio con sondaggio, le interruzioni b / c (1) sono solo più complicate e (2) una coppia di picchi posizionati in modo patologico potrebbe comunque fornire un falso input.

Forse il "rumore" è un problema causato dalla mancanza di codifica. Trasmettitori e ricevitori semplici richiedono NRZ: spesso viene utilizzato il codice Manchester.