Op basis van je laatste opmerking zou ik willen voorstellen om de invoer te overbemonsteren. Neem verschillende opeenvolgende samples op, en dan zou je output moeten zijn wat de meerderheid van de opgenomen samples is.

Stel dat je bijvoorbeeld 10 samples opneemt. Als u een ruispiek krijgt, worden slechts een of twee van de samples beschadigd, terwijl de meeste de juiste waarde hebben. Als u feitelijke gegevens krijgt, zullen de enen uiteindelijk in aantal groter zijn dan de nullen en zal de uitvoer veranderen.

Er zijn veel manieren om met ruis in software te werken, en ze worden steeds effectiever om te implementeren in software in plaats van hardware, waardoor de systeemkosten worden verlaagd.

In plaats van het zelf uit te leggen, heb ik ga je door naar Jack Ganssle, een embedded systems-consultant die ik ben gegroeid door het lezen van de artikelen van.

Hij heeft een lijst van zijn artikelen online staan, de eerste die ik je zou willen geven, gaat over analoge ruis in embedded systemen. Het tweede artikel waar ik je naar moet linken, gaat over het gebruik van software om ruis in je systeem te verminderen.

Ik zou ook zijn artikel willen voorstellen in het afvlakken van digitale inputs en zelfkalibrerende systemen. Nadat ik tijd had doorgebracht met het werken met ingebedde systemen, heb ik een deel van deze informatie hard uit mijn eigen fouten gehaald, maar ik vond het echt leuk om zijn manier van denken te lezen. Het zelfkalibratiesysteem was voor mij heel duidelijk, maar de manier waarop hij voorstelde was waardevol voor mij. Je hebt de informatie misschien niet nodig, maar zijn artikelen hebben me geholpen.

Ik heb ontdekt dat Digital Signal Processing en de Microcontroller van Grover en Deller het enige boek over filters zijn dat ik kan begrijpen. Helaas is het moeilijk goedkoop te vinden.

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

Vraagt ​​uw software deze invoer af, of gebruikt u een interruptschema om deze te verwerken?

Als u aan het pollen bent, leest u de invoer waarschijnlijk veel sneller dan de verwachte veranderingen in de signaal. Als de ruis goed gescheiden is, zeer hoge frequentiepieken, zouden deze eruitzien als geïsoleerde samples met de 'verkeerde' polariteit. U kunt dit verzachten door de meest recente N-samples te bewaren en te besluiten de invoer te lezen, afhankelijk van de polariteit die in de meerderheid is. D.w.z., als N = 5, dan is je invoer een '1' als je 3, 4 of 5 '1'-bits hebt; als je 0, 1 of 2 '1'-bits hebt, is je invoer een' 0 '. Dit is eigenlijk gewoon een soort laagdoorlaatfilter in software.

Als je de ingang gebruikt om interrupts te activeren bij verandering (beide kanten), kun je de interruptroutine (ISR) een timer laten starten om korte tijd later een tweede onderbreking veroorzaken, maar langer dan de ruispiektijd. In plaats van dat de ingangspen ISR direct signaalbits verzamelt, laat je de timer ISR het doen. Als het signaal bijvoorbeeld laag is en er komt een hoge piek, start de stijgende flank de timer, maar voordat de timer afloopt, wordt deze door de dalende flank van de spike gereset, dus als de timer-onderbreking eindelijk afgaat, We kijken naar het signaal, niet naar de ruis. Het signaal, aan de andere kant, zal de timer slechts één keer starten, en de timer ISR zal het nieuwe signaalniveau kunnen pakken.

Van deze twee, Polled vs Interrupt, persoonlijk zou ik gaan voor de ondervraagde benadering zijn b / c (1) interrupts gewoon ingewikkelder, en (2) een pathologisch geplaatst paar spikes kan je nog steeds valse invoer geven.

Misschien is de "ruis" een probleem dat wordt veroorzaakt door het ontbreken van codering. Eenvoudige zenders en ontvangers vereisen NRZ - Manchester-code wordt vaak gebruikt.