IR komm. hjälp?
IR komm. hjälp?
Hejsan!
Jag kodar endel med PIC (16F628) och har nu smått börjat skissa på en robot, så nu behöver jag trådlös komm.
Tycker IR verkar bra, behöver bara skicka lita data mellen PCn och PIC.
Frågan är: hur kopplar/programmerar man IR diod/ IR mottagare?
Jag har läst lite på forumet om IR men jag förstår inte riktigt, nån som kan förklara från grunden?
(är ganska grön på elektronik, kodar i C)
Jag kodar endel med PIC (16F628) och har nu smått börjat skissa på en robot, så nu behöver jag trådlös komm.
Tycker IR verkar bra, behöver bara skicka lita data mellen PCn och PIC.
Frågan är: hur kopplar/programmerar man IR diod/ IR mottagare?
Jag har läst lite på forumet om IR men jag förstår inte riktigt, nån som kan förklara från grunden?
(är ganska grön på elektronik, kodar i C)
Om det ska vara "från grunden" så får du nog hitta någon bra sida på nätet (t.ex).
Jag tror inge vill sitta och skriva allt "från grunden" här...
Om du har någon specifik fråga så, shoot!
> Frågan är: hur kopplar/programmerar man IR diod/ IR mottagare?
Som databladet säger, hur annars?
IR-lysdiod kopplas som (i princip) vilken lysdiod som helst.
IR-mottagaren kopplas lite olika beroende på om det är
en enkel IR-diod eller (bättre) en av av avstämda mottagarna...
Men som sagt, vad är problemet?
Jag tror inge vill sitta och skriva allt "från grunden" här...
Om du har någon specifik fråga så, shoot!
> Frågan är: hur kopplar/programmerar man IR diod/ IR mottagare?
Som databladet säger, hur annars?

IR-lysdiod kopplas som (i princip) vilken lysdiod som helst.
IR-mottagaren kopplas lite olika beroende på om det är
en enkel IR-diod eller (bättre) en av av avstämda mottagarna...
Men som sagt, vad är problemet?
Om du med "vanlig serie komm", menar seriell data i "UART format",
så är det inte det mest lämpliga. Men det beror lite på vilken
mottagare du använder.
Normalt vill man ha ett protokoll som alltid ger nivåändringar
regelbundet. "Manchester" är nog den vanligaste varianten.
Google på "IR communication PIC manchester" ger över 220.000 träffar,
så det är bara att dyka i och börja läsa och hacka kod...
http://en.wikipedia.org/wiki/Manchester_code
så är det inte det mest lämpliga. Men det beror lite på vilken
mottagare du använder.
Normalt vill man ha ett protokoll som alltid ger nivåändringar
regelbundet. "Manchester" är nog den vanligaste varianten.
Google på "IR communication PIC manchester" ger över 220.000 träffar,
så det är bara att dyka i och börja läsa och hacka kod...

http://en.wikipedia.org/wiki/Manchester_code
Ett exempel:
Man tar en avstämd irmottagare och kopplar på parallellporten då den är überenkel att läsa av mha VB+portio. Man kan testa sitt program enkelt genom att bygla kablar mellan stiften eller köra 5V i kontakten se att det fungerar. Det som bör kontrolleras är att mottagaren klarar av att ge logisk etta.
Är man osäker på att själva kommunikationen(irdiod-->mottagare) fungerar kan man köra pic direkt på porten utan större fara för brunna saker.
Sen kör man en irdiod på timer eller pwm i 38kHzeller vilken frekvens den avstämda mottagaren nu har i PICen. Sen kan man avbryta eller starta detta frekvenståg i sitt program hur man önskar ha det.
Att mottagaren fungerar kan man oftast enkelt testa genom att rikta en vanlig fjärrkontroll mot den.
Sen i VBprogrammet kan man exempelvis mha Timer känna av porten en gång /sekund eller en gång/(1/100) sekund och tända eller släcka ett fält beroende på etta eller nolla.
VB kan vara c eller java eller cobol huvudsaken är att man kan hantera parallellporten i det enkelt.
Man tar en avstämd irmottagare och kopplar på parallellporten då den är überenkel att läsa av mha VB+portio. Man kan testa sitt program enkelt genom att bygla kablar mellan stiften eller köra 5V i kontakten se att det fungerar. Det som bör kontrolleras är att mottagaren klarar av att ge logisk etta.
Är man osäker på att själva kommunikationen(irdiod-->mottagare) fungerar kan man köra pic direkt på porten utan större fara för brunna saker.
Sen kör man en irdiod på timer eller pwm i 38kHzeller vilken frekvens den avstämda mottagaren nu har i PICen. Sen kan man avbryta eller starta detta frekvenståg i sitt program hur man önskar ha det.
Att mottagaren fungerar kan man oftast enkelt testa genom att rikta en vanlig fjärrkontroll mot den.
Sen i VBprogrammet kan man exempelvis mha Timer känna av porten en gång /sekund eller en gång/(1/100) sekund och tända eller släcka ett fält beroende på etta eller nolla.
VB kan vara c eller java eller cobol huvudsaken är att man kan hantera parallellporten i det enkelt.
Det är den där pwm pulsen jag inte fattar...
I manchester varier puls-längd och paus beroende på data.
Men vad menar ni med modulering? Ni säger att det brukar vara 38khz.
> Sen kör man en irdiod på timer eller pwm i 38kHzeller vilken frekvens den avstämda mottagaren nu har i PICen
Ok, den där pwm-pulsen, ska man ha 2 st, en för data och en för modulering?
I manchester varier puls-längd och paus beroende på data.
Men vad menar ni med modulering? Ni säger att det brukar vara 38khz.
> Sen kör man en irdiod på timer eller pwm i 38kHzeller vilken frekvens den avstämda mottagaren nu har i PICen
Ok, den där pwm-pulsen, ska man ha 2 st, en för data och en för modulering?
Kolla databladet för t.ex en TSOP-variant.
Där finns de *bra* förklaringarna.
38 KHz (eller däromkring) är *bärvågen*. Den kan t.ex skapas med PWM modulen i en PIC.
Denna bärvåg ska sedan moduleras så att det skapas pulser. Denna modulering
kan (t.ex!) fixas genom att PWM modulen stängs av/på med lämpliga intervall.
Hur dessa pulser ska se ut (inom vilka gränser) framgår av databladen
för dessa IR-mottagare.
Där finns de *bra* förklaringarna.
38 KHz (eller däromkring) är *bärvågen*. Den kan t.ex skapas med PWM modulen i en PIC.
Denna bärvåg ska sedan moduleras så att det skapas pulser. Denna modulering
kan (t.ex!) fixas genom att PWM modulen stängs av/på med lämpliga intervall.
Hur dessa pulser ska se ut (inom vilka gränser) framgår av databladen
för dessa IR-mottagare.
- bengt-re
- EF Sponsor
- Inlägg: 4829
- Blev medlem: 4 april 2005, 16:18:59
- Skype: bengt-re
- Ort: Söder om söder
- Kontakt:
Det finns en "fullösning" för den som inte orkar koda så mycket - ta en pic med ccp och uart. Ställ in ccp så att den ger 38kHz (eller vad du nu har till dina mottagare) - koppla utgången ifrån uarten via en andgrind och detta sedan till drivtrissan för IR-dioden.
Som mottagare väljer du en vanligt 38kHz modul till mottagarpicen och kopplar den på uart ingången.
Voila - en serielänk - inte den bästa, det medges och lite muppigt att behöva sätta en extern grind, men det fungerar skapligt. 19200 (eller däromkring) brukar fungera - visst det finns en stor nackdel med detta - består tecknet du skickar av enbart ettor så finns risk att mottagaren mättas och går låg med datafel som följd. Det finns många bättre lösningar. Fast hög som startbit och "not return to zero kodning" med andra ord att en ständig etta flippar mellan hög och låg och en nolla förblir låg fungerar bättre, men då dår det i princip inte att använda uarten (eller så måste du preparera det du skickar eller hellre skriva bitbang rutiner eller interuptdrivna rutiner själv).
Som mottagare väljer du en vanligt 38kHz modul till mottagarpicen och kopplar den på uart ingången.
Voila - en serielänk - inte den bästa, det medges och lite muppigt att behöva sätta en extern grind, men det fungerar skapligt. 19200 (eller däromkring) brukar fungera - visst det finns en stor nackdel med detta - består tecknet du skickar av enbart ettor så finns risk att mottagaren mättas och går låg med datafel som följd. Det finns många bättre lösningar. Fast hög som startbit och "not return to zero kodning" med andra ord att en ständig etta flippar mellan hög och låg och en nolla förblir låg fungerar bättre, men då dår det i princip inte att använda uarten (eller så måste du preparera det du skickar eller hellre skriva bitbang rutiner eller interuptdrivna rutiner själv).
- bengt-re
- EF Sponsor
- Inlägg: 4829
- Blev medlem: 4 april 2005, 16:18:59
- Skype: bengt-re
- Ort: Söder om söder
- Kontakt:
Eller så kör man pulslängskodad - det har jag gjort någon gång. 400us hög för etta och 800 us för nolla (eller tvärtom). Ha en längre puls som startkondition så får man automatiskt skydd för om mottagaren råkar se något mitt i istället för startbiten.
Fördelen med att koda båda ettor och nollor är det är lättare att detektera dålig mottagning och färre felaktiga meddelanden slussas vidare - nackdelen är att det tar längre tid att sända och att det blir lite stökigare att skriva koden.
Hur jag gjorde koden.
<interupt vid change eller hög på mottagarpinnen>
Detektera hög
räkna upp
gå till detektera hög så länge biten är hög
kontrollera om räknarvärdet är innom intervallet för startbit
Om inte nolla räknaren och lämna interuptrutinen
Fånga pulslängderna på 8 (eller 9) bitar
Om 8 (eller 9) bitar inte detekteras, nolla räknaren och lämna interuptet (någon bit är missad)
Fångat rätt antal pulslängder
Utvärdera pulslängderna med <> på att avgöra om det är giltiga bitar
om inte nolla räknaren och lämna interuptet
Allt gick bra och du har en byte med förhoppningsvis gitigt data
Lämna interuptet och skriv ner datat i buffer så att din kod kan utvärdera det när den har tid. Bäst är att göra en egen FIFO så att du kan polla datat helt asynkront om det är det som din rutin vill.
EDIT:
Finns oändligt många olika sätt att göra detta på - inga problem normalt att göra det "on the fly" så spar du 8-9 byte ram, men gör man så här så kan man bygga funktionen även i högnivåspråk där man inte har kolla på timingen. I assambler är detta upplägg fånigt då det ger onödigt mycket kod.
Fördelen med att koda båda ettor och nollor är det är lättare att detektera dålig mottagning och färre felaktiga meddelanden slussas vidare - nackdelen är att det tar längre tid att sända och att det blir lite stökigare att skriva koden.
Hur jag gjorde koden.
<interupt vid change eller hög på mottagarpinnen>
Detektera hög
räkna upp
gå till detektera hög så länge biten är hög
kontrollera om räknarvärdet är innom intervallet för startbit
Om inte nolla räknaren och lämna interuptrutinen
Fånga pulslängderna på 8 (eller 9) bitar
Om 8 (eller 9) bitar inte detekteras, nolla räknaren och lämna interuptet (någon bit är missad)
Fångat rätt antal pulslängder
Utvärdera pulslängderna med <> på att avgöra om det är giltiga bitar
om inte nolla räknaren och lämna interuptet
Allt gick bra och du har en byte med förhoppningsvis gitigt data
Lämna interuptet och skriv ner datat i buffer så att din kod kan utvärdera det när den har tid. Bäst är att göra en egen FIFO så att du kan polla datat helt asynkront om det är det som din rutin vill.
EDIT:
Finns oändligt många olika sätt att göra detta på - inga problem normalt att göra det "on the fly" så spar du 8-9 byte ram, men gör man så här så kan man bygga funktionen även i högnivåspråk där man inte har kolla på timingen. I assambler är detta upplägg fånigt då det ger onödigt mycket kod.
Sorry, jag var lite snabb med svaret...
*Självklart* ska man göra som Bengt-re säger, man ska ha
två olika pulslängder som representerar "1" resp "0".
Och eventuellt start och stop, om man behöver det.
Jag kollade inte vad net4all skrev tillräckligt noga. Alltså
inte så som net4all beskrev det...
Notera att start flagga/bit igentligen inte behövs eftersom
det alltid kommer en puls oavsett om det är en "1" eller
en "0" som första bit. En paus får sedan representera
"stoppbit".
När jag gjorde en IR länk mellan två PICs för ett tag sedan
så valde jag pulslängder så att när en timer gick för att mäta
pulslängd så kom ett par olika bitar i timerns slutväde att
direkt reprensentera "0", "1", "start" o.s.v. Bara en enkel BTFSx
för att se vad det var som kom...
*Självklart* ska man göra som Bengt-re säger, man ska ha
två olika pulslängder som representerar "1" resp "0".
Och eventuellt start och stop, om man behöver det.
Jag kollade inte vad net4all skrev tillräckligt noga. Alltså
inte så som net4all beskrev det...
Notera att start flagga/bit igentligen inte behövs eftersom
det alltid kommer en puls oavsett om det är en "1" eller
en "0" som första bit. En paus får sedan representera
"stoppbit".
När jag gjorde en IR länk mellan två PICs för ett tag sedan
så valde jag pulslängder så att när en timer gick för att mäta
pulslängd så kom ett par olika bitar i timerns slutväde att
direkt reprensentera "0", "1", "start" o.s.v. Bara en enkel BTFSx
för att se vad det var som kom...
Det skulle alltså kunna gå till så här:
Sändaren sänder först startbit på tex 800us, sedan kommer 8 data bitar med korta pauser imellan, pulslängden varierar beroende på om det är en etta eller nolla och sist en stopbit på 700us.
Stop och start ska väll vara olika långa så att PICen inte tar fel?
Ex:
_______--------_---_-----_-----_---_-----_---_---_-----_-------_______
start 0 1 1 0 1 0 0 1 stop
Mottagaren mäter varje puls och avgör om det är start, 1, 0 eller stop?
PICen räknar data-bitarna och kollar så att stop kommer efter dom, om det inte gör det så klassas medelandet som störning.
Dom här borde funka tillsammans eller hur?
Elfa IR diod: 75-203-56
Elfa IR "mottagare" 75-202-81
Edit: en till fråga
Sändaren sänder först startbit på tex 800us, sedan kommer 8 data bitar med korta pauser imellan, pulslängden varierar beroende på om det är en etta eller nolla och sist en stopbit på 700us.
Stop och start ska väll vara olika långa så att PICen inte tar fel?
Ex:
_______--------_---_-----_-----_---_-----_---_---_-----_-------_______
start 0 1 1 0 1 0 0 1 stop
Mottagaren mäter varje puls och avgör om det är start, 1, 0 eller stop?
PICen räknar data-bitarna och kollar så att stop kommer efter dom, om det inte gör det så klassas medelandet som störning.
Dom här borde funka tillsammans eller hur?
Elfa IR diod: 75-203-56
Elfa IR "mottagare" 75-202-81
Edit: en till fråga