Jonatans projektblog

Mina lediga stunder de senaste veckorna har gått till att få inmatnings-enheterna att fungera. I synnerhet de två rattarna samt fjärrkontroll.

Rattar

Till de två rattarna använder jag rotary encoders. Det är vridströmställare utan stopp som levererar två digitala pulser, där den ena är förskjuten 90° jämfört med den andra:

Genom att hela tiden hålla reda på när en signal växlar från hög till låg eller tvärtom, och vad som senast hände, kan man avgöra om ratten vrids åt höger eller åt vänster. Det hela fungerar riktigt bra, och jag har inte ens behövt använda någon avstudsningsteknik.

Jag hade från början tänkt använda en vanlig potentiometer till volym-ratten, eftersom det är en fördel om den har fasta min- och max-lägen. Men för att göra konstruktionen lättare och för att vinna ytterligare lite flexibilitet har jag bestämt mig för att använda samma komponenter för båda rattarna.

Fjärrkontroll

Från början hade jag tänkt undvika att implementera fjärrkontrol-hantering, och istället använda fjärrkontroll-sensorn från min gamla X-box. Eftersom signalerna på gamepads och sensorer som ansluts till X-box är USB-kompatibla så är det enkelt att löda på en vanlig USB-kontakt på sensorn och ansluta till en PC istället. Det finns bra stöd i LIRC för det. Instruktioner för hur man omvandlar sensorn till vanlig USB finns här.

Jag gjorde detta för ett par månader sedan, och det fungerade bra. Men när jag nu plockat upp den igen har något gått sönder, så den upptäcks inte alls som USB-enhet längre. Så vad göra. Köpa ny? Nähä. Då får jag fixa IR-stöd själv istället.

Till saken hör att min TV har en fjärrkontroll som kan växlas mellan två lägen: TV och STB. Vad STB står för vet jag inte, men det vore perfekt om man kunde använda samma fjärrkontroll till TV:n och HTPC:n, genom att växla mellan dessa två lägen.

Så jag beställde en IR-sensor (75-303-89 på Elfa) och anslöt den till interface-kortet med hjälp av en experimentbräda. Noterade direkt att signalnivåerna var de rätta så nu var det bara att ta reda på protokollet från fjärrkontrollen och börja knacka kod.

Efter analys med oscilloskop kom jag fram till att fjärrkontrollen använder ett protokoll utvecklat av NEC. Det finns beskrivet tillsammans med en uppsjö andra IR-protokoll på denna utmärkta sida!

Hanteringen är ganska enkel. Jag har lagt ett interrupt på digital-ingången från IR-sensorn. Vid varje nytt interrupt (uppåtgående eller nedåtgående flank) kontrollerar jag om den nya nivån och tiden sedan senaste interruptet är de beräknade, med en viss marginal på tiden. Sedan startar timern om och interrupthanteringen avslutas. När sista interruptet mottagits, och kommandot är komplett (32 bitar) så inaktiveras interruptet tills kommandot hanterats av huvudloopen.

När huvudloopen uppfattar att ett IR-kommando är komplett så skickar den ett USB-interrupt till PC:n. Samma sak med rattarna och knapparna.

XBMC

Det sista steget är att informera XBMC om vad som händer. Jag har skrivit ett enkelt program som dels väntar på USB-interrupt (dvs väntar på att ta emot kommandon från interface-kortet) och dels har en anslutning till XBMC via EventServer/Client protokollet (ett enkelt envägs UDP-baserat protokoll för att skicka just knapptryckningar och liknande).

I och med detta är hela kedjan klar, från fjärrkontroll till ir-sensor till avr till usb till pc till xbmc. Men det finns ett problem:

Fjärrkontrollen fungerar och man kan navigera runt i XBMC. Men navigeringen är inte mjuk. T.ex om man höjer volymen genom att hålla volymknappen inne på fjärrkontrollen så går den stötvis. Eller om man trycker ”enter” på ett underbibliotek t.ex, så kan den skicka två knapptryckningar istället för ett så att man hamnar någon helt annanstans än man tänkt sig.

Jag misstänker att det finns två anledningar till detta. Fjärrkontrollen skickar ut upprepningskommandon med ett förmodat jämnt tempo. Men någonstans längs den komplicerade kedjan innan dessa når XBMC kan tidsförskjutningar uppstå, med en ryckig navigering som följd.

Det andra problemet är att, som sagt, upprepningskommandon skickas av fjärrkontrollen. Dessa skickas exakt 110 ms efter det förra kommandot startade. Eftersom varje nytt kommando tar ca 86 ms att skicka innebär det att första upprepningskommandot kommer bara 24 ms senare. Har användaren inte hunnit släppa knappen på den tiden skickas nästa kommando direkt.

Jag funderar på olika sätt att lösa detta. Ett sätt är att konfigurera programmet så att vissa knappar bara skickar en impuls. Dvs, volymknappen fortsätter fungera som nu och skicka upprepade knapptryckningar, medan enter-tangenten bara skickas en gång.

Ett annat sätt är att skicka en ”knapp nertryckt” signal till XBMC när första kommandot mottages och sedan skicka ett ”knapp släppt” kommando först när det gått 110 ms utan att någon upprepningskod mottagits.