Fråga:
Hur exakt är tidpunkten för pulseIn ()?
Peter Bloomfield
2014-02-20 17:03:18 UTC
view on stackexchange narkive permalink

Jag har använt pulseIn () -funktionen för att bearbeta PWM-baserad binär datakodning. Det fungerar bra för att skilja pulser som har signifikant olika längder, t.ex. 500us mot 1500us. Det gör det mer än tillräckligt för hantering av typiska IR-fjärrkontroller.

Jag vill dock skapa mitt eget IR-system som kan använda mer än två pulslängder, så att dataöverföring kan ske snabbare. Helst skulle jag vilja använda 8 olika pulslängder för oktal kodning (t.ex. 200us, 400us, 600us, etc.).

Jag har märkt ganska betydande variationer i värdena som returneras av pulseIn () dock (+/- 10%). Jag förväntar mig att åtminstone en del av det introduceras av IR-sändar- och mottagarmodulerna, men jag har inte tillräckligt med utrustning för att verifiera det.

Förutsatt att jag kan mildra det externa felet är pulseIn () sannolikt att vara exakt nog för att skilja sådana liknande pulser?

Två svar:
#1
+11
mpflaga
2014-02-21 09:38:55 UTC
view on stackexchange narkive permalink

Funktionen pulsein () är mycket förlorad, eftersom den är en hård slinga och returnerar ett tal * de antagna klockcyklerna som krävs per slinga

  ... // vänta på pulsen för att stoppa under tiden ((* portInputRegister (port) & bit) == stateMask) {if (numloops ++ == maxloops) returnerar 0; bredd ++;} // konvertera avläsningen till mikrosekunder. Slingan har bestämts // att vara 20 klockcykler lång och har cirka 16 klockor mellan kanten // och slingans början. Det kommer att inträffa något fel av // interrupt handlers.return clockCyclesToMicroseconds (bredd * 21 + 16); 

Den mest exakta metoden för att fånga tidpunkten för en PIN-kod är att använda INPUT CAPTURE-FUNKTIONEN. Titta på detta exempel. Det möjliggör ingångsfångst vid 1x CPU för maximal upplösning och varje kant på ingångsstiftet fångar timerns klockvärde för avläsning från den genererade Interrupt-tjänsten. Det gör det också möjligt för timeröverflödesavbrottet för att upprätthålla stor absolut tid. Eftersom 1x rullar ganska snabbt. Fångarna lagrar tiden i en matris för läsning av huvudslingan.


Där för signaler över IR är det typiska biblioteket att använda shirriff / Arduino-IRremote -biblioteket. Där den har flera demo som kommer att läsa och skicka IR från en demodulerad signal. Att låta en bygga en skiss av sin egen design. Denna kod skapar ursprungligen en timeravbrott som avfrågar ingångsstiftet med en hastighet bestämd av IRremote.h-filen. För mina ändamål har jag ändrat den till 25 oss. Där jag hittar detta fortfarande kan det ibland saknas pulströmmar.

Observera att demoduleringen uppnås bäst inom IR-mottagaren, som i sin tur matar ut denna intressanta signal. Var ska man lägga till lite bakgrund. Med den typiska 38KHz-moduleringen motsvarar en minsta upplösning på 26,3uS per pulscykel. sherriffs bibliotek visar vanligtvis att de flesta bauds eller bitar är i storleksordningen 10+ pulser. Som verkar uppfylla dina önskade tider.

microtherion / Arduino-IRremote gaffel av shirriffs arbete förbättrar mottagningen genom att ersätta tidsavbrottets avfrågning av stiftet med användning av PinChangeInterrupts. Som jag har sammanfogat i min egen mpflaga / Arduino-IRremote gaffel, som lägger till flera andra funktioner.

Så du kan använda något av ovanstående bibliotek. Eller skapa din egen app som använder någon av nedanstående för att fånga kanter.

  1. omröstningar på en timerhändelse (t.ex. 50uS)
  2. fångar mikros () på en PinChangeInterrupt
  3. använder Input Capture Interrupts för att fånga den exakta tiden
Strålande svar. Arduino-IRremote är ett bibliotek av mycket hög kvalitet. Lättläst och har en mycket genomtänkt design som gör att den är mycket pålitlig.
#2
+2
TheDoctor
2014-02-20 20:22:36 UTC
view on stackexchange narkive permalink

Här är några testdata för ett pulseIn -test. En Arduino skickade vad som skulle vara 14us pulser, och den andra spottade ut dessa data:

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

Som du kan se är pulserna inte alls korrekta. Tiden skulle vara mer korrekt om sändnings- och mottagningsändarna skrevs i sammansättning eller till och med laddades till sina egna processorer.



Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...