Generera IR-signaler med PWM eller UART?

[hanzibal]

Hejsan!

Om jag förstått grejen med IR-signaler så funkar dessa i princip som så att man skickar ut s.k. "burst pairs", skurpa eller ON/OFF-par som vardera anger antalet perioder hög nivå (ON) och antalet perioder låg nivå (OFF) modulerade på 38kHz fyrkant. Detta alltså då för "vanliga" 38kHz-system som används för TV, sterero mm för hemmabruk (t.ex. NEC-formatet).

Jag vet att Jesper implementerade en IR-sändare med PWM i denna manick (som jag f.ö. köpt men ännu inte laddat in mjukvaran i eftersom jag saknar JTAG-programmerare som är löjligt dyra):
http://elektronikforumet.com/forum/view ... hp?t=45390

Jag antar då att man måste programmera om PWM-modulen (ändra duty cycle) för varje ON/OFF-par, vilket ju i så fall lär kräva en hyggligt snabb MCU. Rätt mig gärna på denna punkt!

Eftersom jag istället har en hyggligt långsam MCU så är min fråga nu om det kanske vore möjligt att producera en IR-signal m.h.a. en vanlig UART. Man skulle då alltså välja en lämplig baudrate i förhållande till 38kHz och sedan modulera IR-pulsern som data på TX-pinnen, varvid man skickar hela pulståget i ett nafs till UART:en. Man måste såklart anpassa datat så att det i slutändan ger motsvarande skurpar på TX kopplad till en IR-diod.

Skulle detta funka månne?

[MiaM]

Jag tror att pulstågen alltid är längre än ett RS232-tecken (även om man t.ex. trixar genom att använda stoppbiten för att få 9 bitar långa tecken).

Du skulle alltså behöva en synkron serieport av nåt slag.

[hanzibal]

Japp, du har säkert rätt - tror att vissa pulser kan vara i 100-tals perioder. Har för mig att man använder 16 bitars tal för att ange varje skurpar...

Jag vet inte hur RS232 ser ut men kanske att man ändå kan skapa motsvarande signal genom att skicka noga utvalt data. Min erfarenhet av IR är att mottagare inte är särskilt nogräknade, d..v.s de ser inte små "glapp" i pulserna.

Är det kört?

[JimmyAndersson]

Det beror på hur "hyggligt långsam" din MCU är och vad det är för MCU.

T.ex så går det med en PIC-krets med CCP (Capture/Compare/PWM) och UART.
Låt den PWM-modulen generera modulationsfrekvensen, t.ex 38kHz.
Koppla sedan den utgången och utgången från UART'n till en AND-grind.
Utgången från AND-grinden kopplas till en IR-diod.

Istället för AND-grind så kan man låta UART'n stänga av/på PWM-modulen.

En baudrate på ca 19200 baud brukar ge rätt pulståg.

[hanzibal]

Smart som f-n!

Du råkar inte också veta hur man då bör modulera datat på UART:en i förhållande till given sekvens av ON/OFF-par?

EDIT: Ok, "you got me" - det är ingen "riktig" MCU utan det är .NET Micro Framwork på en 48 Mhz Atmel ARMx (Netduino). Tror den gör ca 200Hz i förhållande till inhemsk assembler ...

[MiaM]

Jag håller med JimmyAndersson, låt hårdvara generera 38kHz-signalen. (Bäst är kanske att verkligen döda oscillatorn istället för att bara grinda signalen, då får du i alla fall förhoppningsvis en renare start av 38kHz-signalen när du släpper på signalen. Det kanske inte har nån praktiskt betydelse).

Gamla långsamma hemdatorer på 80-talet orkade i alla fall att ta emot 1200bps genom en vanlig i/o-pinne (75/1200-modem på C64, t.ex.), då var det 1MHz processorfrekvens och 6502 hade ju inte alls lika fräcka instruktioner som modernare mikrokontrollers antagligen har. Mottagning kräver dessutom klart snabbare burk än sändning.

Med modulation på 38kHz så lär själva datahastigheten vara klart lägre, och det borde väl "alla" mikrokontrollers orka på en vanlig paralell ut-pinne (pio, gpio eller vad de kallas på just din mikrokontroller), antar jag.


Går det inte att köra riktig kod inline i Netduinon?

Det kritiska är egentligen inte mikrokontrollerns hastighet utan att den inte blir avbruten / kan hålla takten exakt.

Det kanske till och med går att köra detta på nån slags interrupt via timer?

[blueint]

Det är väl selektiviteten på RC filtret i mottagaren som är avgörande för hur långt man kan avvika från centerfrekvensen?

Annars kan man ju byta kristallen till något jämnt delbart med 38k och skicka 0xAA (0b10101010) med lite fräcka val av startbitar, stopbitar, paritet osv.. borde man klara det.

[JimmyAndersson]

Det sistnämnda var en kul och udda idé. Kanske lite svårare att hålla koll på iofs.


MiaM:
"Bäst är kanske att verkligen döda oscillatorn istället för att bara grinda signalen, då får du i alla fall förhoppningsvis en renare start av 38kHz-signalen när du släpper på signalen."

Ah, just det ja. Det borde ge lite bättre möjlighet att ta emot rätt data ifall de yttre förutsättningarna inte är så bra.
(T.ex långsam IR-diod eller långt avstånd.)


Hanzibal:
Det låter intressant med .NET framework till en microkontroller. Det måste jag kika lite på.
I det här fallet är det språkvalet en fördel, för det kan vara lite jobbigt att få till i assembler utan kilometerlång kod.

"Du råkar inte också veta hur man då bör modulera datat på UART:en i förhållande till given sekvens av ON/OFF-par?"

Tyvärr är jag inte riktigt med på hur du menar. Berätta gärna mer om vad du funderar på.

[sodjan]

> Jag antar då att man måste programmera om PWM-modulen (ändra duty cycle) för varje ON/OFF-par,

Nej, man sätter bara PWM modulen on/off, oftast bara en enda bit att toggla.
Duty cycle är hela tiden 50% (eller vad sm nu är optimalt för drivningen
av IR dioden) och det ändrar man aldrig efter initiering.

Sedan får man ordna med timingen på annan sätt, men kan t.ex fixa ett interrupt
på overflow av PWM modulen och sedan räknar man pulser i ISR'en. Man vet ju
hur långa de olika pulserna ska vara. På så sätt får man även rena pulser,
d.v.s inga fjutt pulser till IR-dioden. Man använder även overflow interruptet
för att slå på PWM modulen igen så att det startar med en hel och ren puls.

Eller så gör man på något annat sett, det finns flera metoder...

USART tror jag inte på, fjärr-signaler ser normalt ganska annorlunda ut.

[MiaM]

Utan att veta säkert så tror jag att man nog snarast vill ha omkring 10% dutycycle för att driva IR-dioder. Därför vill man också ha rätt bra avkopplingskondensator och hög strömstyrka genom dioden när den moduleras.

OBS, provkör först med seriemotstånd som bara ger "normal lysdiodström" (10-20mA) (och mycket närmare avstånd till IR-mottagaren) till man vet att pulsbreddsförhållandet är vettigt, sen kan man byta till klart högre ström. Jag är inte säker men tror att man kanske kör t.ex. 200mA i spikarna eller nåt sånt. Läs datablad/applikationsexempel/scheman på nätet.

Därför skulle 0xAA nog inte funka så bra att skicka ut med UART'en istället för att ha en separat 38kHz-generator. Då skulle man snarast skicka 0xEE eller nåt sånt (med nollor = ström genom dioden, eftersom idletillståndet på seriedatat är en etta).


Men nog måste det väl gå att göra det mesta i .NET men just IR-sändningen i nån slags native-kod på mikrokontrollern? Det här är ju ett perfekt exempel på när det är vettigt att blanda mikrokontrollerassembler med högnivåspråk, kör microkontrollerassemblern för IR-sändningen och högnivåspråket för resten.

[hanzibal]

Hej igen och tack för alla svar!

Så här ser IR ut och jag tror att jag fattar vad ni menar att jag skall göra:

ir_pulser.JPG

Det stämmer alltså (som Sodjan skriver) att man skall ha 50% duty cycle och det handlar alltså om att (inte som jag skrev från början) att genera sådana 50%-perioder motsvarande antalet ON-perioder respektive "helt tysta" 100%-perioder motsvarande antalet OFF-perioder.

Precis som en del skrivit så låter jag alltså PWM-modulen köra ut 50% cykler på 38kHz. Jag kan sedan koppla denna till en interrupt och låta MCU:n räkna antalet ON-perioder (hög till låg-växlingar). Baserat på detta låter jag interrupt-hanteraren toggla en ut-pinne som går låg efter x ON-perioder. OFF-perioderna får jag väl syntetisera med en timer-loop däremellan. Motsvarande IR-signal fås sedan genom att AND:a PWM med min ut-pinne. Tror inte min PWM-modul har overflow-interrupt och osäker på om MCU:n hinner toggla vid interrupt - detta få se. I övrig korrekt uppfattat?

Det beror på hur "hyggligt långsam" din MCU är och vad det är för MCU.

Det är en Netduino som iofs kör på en 48Mhz 32-bitars CPU men dock interpreterande så netto-hastigheten är ganska blygsam.

Går det inte att köra riktig kod inline i Netduinon?

Njä, man programmerar C# eller VB och det finns ingen vettig "inline C" eller "inline assembler". Fez har bättre möjligheter för detta, deras Cerb40 (STM32F4-baserad DIL40) är relativt kraftfull.

Det låter intressant med .NET framework till en microkontroller. Det måste jag kika lite på.
I det här fallet är det språkvalet en fördel, för det kan vara lite jobbigt att få till i assembler utan kilometerlång kod.

Japp, det är väsentligen enklare att snabbt få till stånd en prototyp med .NETMF C# (eller VB) än C eller assembler (jag kan samtliga) men det beror såklart en del på vad man skall göra, vissa saker låter sig helt enkelt inte göras i .NETMF emedan andra saker skrivs på en rad i C# kontra 200 i C...

"Du råkar inte också veta hur man då bör modulera datat på UART:en i förhållande till given sekvens av ON/OFF-par?"
Tyvärr är jag inte riktigt med på hur du menar. Berätta gärna mer om vad du funderar på.

Detta kan kvitta nu, jag menade alltså hur man med UART:en kan generera den signal som nu ovan interrupthanterare ger på ut-pinnen före AND:en.

[sodjan]

> Det stämmer alltså (som Sodjan skriver) att man skall ha 50% duty cycle...

Nja, det är väl en tolkning du gör utefter bilden där den kanske *ser ut* så.
Duty cycle är inte viktigt för den övergripande diskussionen utan får
anpassas så att det blir en effektiv IR-överföring. Då läser in något
i bilden som inte finns där.

> Baserat på detta låter jag interrupt-hanteraren toggla en ut-pinne som går låg
> efter x ON-perioder. OFF-perioderna får jag väl syntetisera med en timer-loop däremellan.
> Motsvarande IR-signal fås sedan genom att AND:a PWM med min ut-pinne.

En onödig omväg. Det är i stor sett exakt samma jobb att toggla PWM-modulens
on/off bit (eller utpinnens TRIS bit) direkt istället för en separat I/O pinne och ha
en extra extern grind.

> Tror inte min PWM-modul har overflow-interrupt

Njae, det brukar vara den timer som PWM modulen styrs av som har en overflow interrupt.

> Det är en Netduino som iofs kör på en 48Mhz 32-bitars CPU men dock interpreterande så netto-hastigheten är ganska blygsam.

Jahaja, ja det kan ju bli en utmaning. Det borde väl gå att bygga egna utökningar till
miljön och länka in när själva .NET-whatever miljön inte räcker till?

[hanzibal]

Bilden visar ifos tydliga halvperioder med 1:or och motsvarande med nollor (blir helperioder med nollor). Dessutom har jag tidigare bit-bangat detta med PIC-assembler så det stämmer faktiskt (gjorde en Nexa-sändare med en PIC18).

Grejen med .NETMF är att man jobbar på hög nivå vilket ju har sina fördelar. Å andra sidan så blir det (som alltid) besvärligt när man vill bege sig utanför mallen och i fallet Netduino finns alltså inga vedertagna vägar att göra några utvidgningar. Vad jag vet kan man i .NETMF endast sätta frekvens och duty-cycle, något annat i fråga om de andra sakerna du nämner finns inte så det blir i så fall att (som jag skriver) att koppla PWM-utgången till en ingång med interrupt och se om man hinner toggla en annan pinne att AND:a med.

Det var just det senare jag, från början, tänkte att man kanske kunde överkomma genom att använda UART:en istället (eller ev. i kombination med PWM).

[hanzibal]

Men nog måste det väl gå att göra det mesta i .NET men just IR-sändningen i nån slags native-kod på mikrokontrollern? Det här är ju ett perfekt exempel på när det är vettigt att blanda mikrokontrollerassembler med högnivåspråk, kör microkontrollerassemblern för IR-sändningen och högnivåspråket för resten.

Håller med till 100% duty cycle men just Netduino saknar alltså tillförlitliga metoder för just detta. Däremot har Fez (GHI Electronics), som också gör .NETMF-moduler, alltså bättre stöd för denna typ av utvidgningar.

När det gäller Netduino så gillar jag denna DIL24:a på 48Mhz Atmel ARM7 med 152kB Flash och 64kB RAM:
http://www.netduino.com/netduinomini/specs.htm

Från GHI har jag också ett par av dessa STM32F4-rackare i DIL40 på 168Mhz, FPU (!), 1MB Flash och 192kB RAM:
http://wiki.tinyclr.com/index.php?title ... _Developer

[sodjan]

> Bilden visar ifos tydliga...

Ja, och det är ju det jag säger, du övertolkar bilden.
Nu så tror jag säkert att även 50% fungerar helt OK, men
det är inte självklart att det är det optimala för IR-länken.

> Vad jag vet kan man i .NETMF endast sätta frekvens och duty-cycle,

Och därmed så startat PWM modulen också direkt?
Finns det inget sätt att hantera fysiska register alls??
Det är ju väldigt märkligt, har inte t.o.m Arduino den möjligheten?

> ...att koppla PWM-utgången till en ingång med interrupt...

Å fy fasen vilken lösning...

> ...STM32F4-rackare i DIL40 på 168Mhz, FPU (!), 1MB Flash och 192kB RAM:

Jahaja, är det alltså typ en sådan plattform som det hela handlar om !?