Hop til indhold

Hjemmelavet Ihc Inputmodul Direkte Til Controllers Databus


Kenth Jensen
 Share

Recommended Posts

Hey

 

Jeg tror lige jeg starter en ny tråd op her, for at undgå at det ellers drukner i en masse gamle indlæg i min gamle tråd.

 

Jeg går og overvejer at lave mit eget input modul med et "Netduino plus 2" board, som skal snakke direkte sammen med IHC controlleren via databussen, som et originalt LK input og output modul gør.

 

Dette skal bl.a. bruges til at lave min egen IR modtager, gammel tråd om emnet findes her:

http://www.ihc-user.dk/forum/topic/3323-ir-modtager-og-logitech-harmony-one-universal-fjernbetjening/?p=31215

 

Jeg har googlet lidt rundt for at finde ud af hvilken protokol IHC benytter sig af mellem controlleren og input og output moduler, og jeg fandt nedenstående:

http://en.wikipedia.org/wiki/Intelligent_Home_Control

 

Så vidt jeg kan se, burde det være rimelig let at efterligne denne protokol med "Netduino plus 2" boardet, og det ser også ud til at andre herinde har haft held med tilsvarende.

 

I den forbindelse dukker der et par spørgsmål op.

 

I tilfældet hvor brugeren ikke trykker på nogle knapper på remoten, og alle indgange skal være Off, er det da nødvendigt at generere disse pulser overhovedet, tænkte at det ville være lettere kun at genere pulserne inkl header og paritets pulserne når der rent faktisk var en af indgangene der gik On, resten af tiden må det jo blot svare til at der rent fysisk slet ikke er forbundet et input modul på denne dataindgang på controlleren, og det ville spare en masse processorkraft på Netduino boardet

 

Hvor præcis skal timingen være, tænker på hvor meget breddere og smallere pulserne må være for at controlleren stadig forstår dem.

 

På forhånd mange tak for input ;)

Link til kommentar
Del på andre sites

Hej Kenth

 

Det er lidt på samme måde. 

Der sendes en 16 bit integer, hvor bit'ne er encoded med forskellig puls/pause længde.

Først sendes et startbit, så sendes rumtemperatur, dernæst gulv temperatur og til sidst en checksum.

Integer er jo heltal, og jeg mener at det er temperatur * 10.

Prøv at søge lidt. Jeg kan huske der er en der har postet arduino kode til det.....

Link til kommentar
Del på andre sites

Hej Kenth

 

Jeg har før brugt Arduino som IR sender/modtager sammen med IHC og det fungerer ganske problemfrit. Jeg mener at have skrevet lidt om det her, og ellers er der også skrevet lidt på forumet på tooms.dk. Koden jeg brugte er postet på Tooms forum under IHC/IHC output protokol (6. emne).

 

Så vidt jeg husker er IHC ikke særlig kræsen i forhold til længden er pulserne. 

 

Du har givetvis ret i forhold til at du ikke behøver at sende noget ud når alt skal være OFF. Men det er vel begrænset processorkraft det tager alligevel, er det ikke?

 

Held og lykke.

 

Vh Anders

Link til kommentar
Del på andre sites

Jesper, har har kigget nu kigget lidt på protokollen brugt til temperatur sensorerne, men den protokol er alt for langsom til at bruge til IR modtager, det ser ud til at tage op til ca et halvt sekund at sende en enkelt værdi over via denne protokol, hvilket er fint til temperaturer der ændrer sig meget langsomt, men til en remote kontrol hvor man skal kunne regulere lyset op og ned, duer det ikke.

Men det er da fint at tage alle muligheder med i ens overvejelser, og det havde da også kunne være lækkert at kunne lave det uden at skulle hacke sig direkte ind på databussen på controlleren.

 

Anders, godt at høre det kan lade sig gøre, jeg er også faldet over en tråd inde på tooms forum som du har skrevet i.

 

Jeg må vel bare prøve at se om controlleren kan acceptere at der kun er pulser når man sender noget med remoten.

Tænker at dette vil være en fordel at processoren i Netduino boardet skal lave så lidt som muligt, da den nok samtidig skal køre en webserver og lytte til IR inputs fra photodioden, sidst nævnte er dog interrupt baserede.

 

Men hvis jeg samtidig skal bruge mere end de 16 input kanaler, jeg kan opnå på en enkelt datainput på controlleren, vil jeg let kunne bruge 2 datainputs hvis jeg kun skal genere pulserne på en output port på boardet ad gangen.

 

Det fede ved at "simulere" denne protokol direkte er at jeg også vil kunne simulere et output modul så jeg kan sende ting fra controlleren til Netduino boardet.

 

Jeg er dog lidt i tvivl om hvordan paritets bitten virker.

Taget fra wikipedia:

One addition parity pulse; an even number of pulses is 0 parity and odd number pulses is 1 parity

 

Dette er jo lidt noget sludder, der er jo altid samme antal pulser, uanset hvor mange inputs der er 1 og 0.

Mon der i stedet menes at paritets bitten er 1 hvis der er et lige antal høje bits, og 0 hvis der er et ulige antal høje bits.

Noget der ved det?

Link til kommentar
Del på andre sites

Anders, prøvede du at genere pulserne til controlleren, eller modtog du dem fra controlleren?

 

Jeg kan se det kan lade sig gøre at modtage pulserne og time hver enkelt bit via Microsoft.SPOT.Hardware.Utility.GetMachineTime().Ticks;

 

Der hvor jeg ikke lige kan gennemskue det, er når bittene skal generes af boardet og sendes til controlleren.

Timeren i micro frameworket har en opløsning på 1 millisekund, men der skal laves pulser på henholdsvis 150, 300 og 450 micro sekunder.

 

Man kan selvfølgelig lave en while løkke der looper rundt indtil ticks er nået op på den rigtige værdi, men tænker at det vil loade processoren og at det i stedet skal være noget event baseret, da boardet samtidig skal kunne modtage IR kommandoer fra remoten på præcis samme tidspunkter

Link til kommentar
Del på andre sites

Jeg er i tvivl om jeg prøvede begge veje.

 

Nu kender jeg ikke noget til NetDuino. Men mon ikke der er en puls funktion som kan lave meget præcise pulser? Jeg kan se at den har 6 PWM udgange og de kører typisk fra en timer som genererer en interrupt. Dette vil ikke belaste dit system ret meget da det eneste den interrupt skal gøre er at sætte en bit. Hvis det er lavet rigtigt burde det være mindst lige så nemt som at læse pulser.

Link til kommentar
Del på andre sites

  • 2 months later...

Ett tips är att informationen på wikipedia stämmer inte helt, periodtiden är 625uS/bit, och "paritetsbiten" verkar alltid vara 1.

 

Jag har gjort min egen input-modul som kan läsa 56st knappar via en 8-linjers charlieplexing-bus och sedan matar in det på fyra kanaler på IHC-controllern. (så småningom ska jag ordna så modulen även läser in 1x8bit alternativt 2x4bit AD-kanaler på resterande 8 bitar som blir över på sista IHC-kanalen). Så småningom är när jag städat upp i koden och dokumenterat det hela lite bättre är planen att släppa kod, schema och layout som open sorurce så klart :)

 

Min IO-modul är baserad på en ATMEGA88 programmerad i C (AVR-studio) och kommunikationen måste hanteras av ett timer-interrupt som anropas var 156:e us (första två faserna är utgången 0, tredje fasen är den 1, sista fasen biten som ska skickas, repetera detta 16+1ggr, sista biten är alltid 1, delay innan nästa 16bitars ord kan skickas, klart!), försökte först for-loop med delay:er men det gick inte alls för timingen blev inte tillräckligt exakt. Jag har aldrig gjort nått med arduino, men vad jag sett gjorts av andra med den kompilatorn bör det gå bra tat få till timingen där med.

 

Då output-modulerna använder samma protokol kan man börja med att skicka till en sådan, den är mer förlåtande med timingen, IHC-controllern är lite känsligare med timingen.

Link til kommentar
Del på andre sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Gæst
Svar på dette emne...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loader...
 Share

×
×
  • Tilføj...

Important Information

Privatlivspolitik og We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.

1200x630bb.png

ok