En god ide til hvordan man sampler strukturen i et IR RC signal.

Google lirc, det er godt nok til linux, men det er værd at læse koden for at se hvordan det virker.

Så kunne man vælge at søge på winlirc, der er til windows :O)

/Hauge

Evt. kan du registrere tidspunktet for hver positiv og negativ flanke der kommer ud af din IR-modtager, det er i hvert fald den nemmeste og mindst krævende metode. Det skal selvfølgelig ikke være "hf"'en, men efter detektering.

Mvh Hauge

Ja, det mener jeg også de gør.

Hvis det skal være bedre skal man til at forstå kodningen og der er rigtigt mange forskellige, men RC5 er vist nok en af de mere populære...

Ja. Men som sagt så skal jeg kunne genkende ALLE fjernbetjeninger med undtagelse af B&O selvfølgelig.

Men jeg har gået og tænkt lidt over det. Og er kommet på et lille tanke eksperiment... Har hverken be eller afkræftet om det virker. Men lad os sige at jeg har målt alle tidspunkterne for shiftene. Så derefter smide dem ind i en hash generator (fx MD5). Så man ender op med måske 32 bit. Altså en algoritme ala CRC. Derefter når man får andre målinger gør man det samme og ser om resultatet bliver det ens.

Men, som med MD5 kan to forskellige indputs give samme resultat. Fordelen er bare at outputet ikke fylder noget i forhold til indputtet. Alle indput ender med samme størrelse. Desuden er det jo meningen af chanden for at man møder to indputs der giver samme output skal være meget lille plus man behøver ikke gemme de oprindelige data.

Kan nogen gennemskue om jeg har fat på den lange ende?

MD5: er en hash generator, der bliver brugt til mange t> Jan Thogersen wrote:

Det du er ved at udlede, er en generisk hash-tabel. Idéen er sådan set god nok, og de fungerer normalt således:

- For hver værdi du vil gemme, beregnes en N-bit hash (vælg selv passende N)

- Du slår op i en N^2-element liste med pegere til lister.

- Hver liste du har en peger til, indeholder værdier med samme hash-kode.

- Når du vil finde en værdi igen, starter du med at beregne hash-koden ud fra din input-værdi

- Denne værdi bruges til at slå op i listen over lister

- Den aktuelle liste gennemløbes (fx med binær søgning eller lineær iteration), og den eftersøgte værdi findes (eller ej)

Det du spørger om, er hvordan du kan undgå at gemme de lange koder, og er i grunden ikke relateret til hash-tabller, da disse bruges til at forbedre søgetider for store datamængder.

Det du kunne gøre i stedet, er:

- For hver værdi beregnes en passende i-princippet-unik hash-kode (fx MD5)

- Når alle værdier er beregnet, sorteres de, og gemmes i en liste

- Denne liste kan nu gennemsøges hurtigt, og du har ikke brug for at gemme det komplette datasæt.

Det er relativt simplet, (forhåbentlig) noget mindre end at gemme alt, og du slipper for hash- og CRC-koder.

Kan det bruges?

Men så vidt jeg har forstået Jan, skal han netop ikke gemme det modtagne signal, men blot kunne genkende det næste gang det kommer. Dette kan han vel fint klare ved at lave f.eks. en md5-sum ud fra det modtagne signal. Eks. Han modtager signalet 1234, som giver summen ABCD. Summen ABCD bliver nu gemt. Når han så senere modtager signalet 1234, vil det igen give summen ABCD som jo betyder at det er det samme signal han modtog tidligere.

Har jeg helt misforstået hvad Jan vil?

Det er jo også det jeg siger :-)

Præcis!

Så har vi begge.

:-) Ok, så misforstod jeg bare dig - min fejl. Undskyld hvis jeg bragte mere forvirring over sagen :-/ heh.

Halv forvirring er halvgodt, så fuld forvirring må være helt i orden :-)

Ja, I forstod det begge. Og Christian, det er næsten samme løsning vi havde tænkt. Så min ideen om ikke at gemme hele koden med bare en form for sum må kunne virke.

Men sagen er lidt mere kompliceret end det. For når jeg nu måler tiderne vil de aldrig være helt ens, heller ikke selv om det burde være det præcis samme signal. Så der skal også være plads til noget elasticitet i summerings algoritmen.

Men det kan vel gøres ret simpel fx ved at dividere tiderne ned, så de m> J>

Det skulle undre mig om de ikke alle kører med fast frekvens på modultionen? I så fald kan du nøjes med at registrere tiden mellem puls on/off... Samtidig vil jeg tro at de også alle kørere med faste modulationsfrekvenser - men det er nok lidt sværere at dekode simpelt og sikkert.

/A

Det bør bestemt virke, ja, men kun hvis du bruger en ikke-triviel sum. Kollisionsundgåelse er netop et designkriterium ved fx MD5 og SHA-1.

Ja det er slemt fordi en tid sagtens kan ligge lige på grænsen mellem to bit-værdier, og den vil så stadig svinge.

Hvis tiderne har en fast granularitet, bør du i stedet prøve at lægge end halv periode til, før du dividerer. Det bør stabilisere tiderne, så de altid afrundes til det samme.

Om det virker i praksis skal jeg ikke kunne sige.

De gør de ikke.

Du kan finde en beskrivelse af mange forskellige koder i dette program:

under serial kommunikation.

Først: Jeg kender ikke noget til denne form for kommunikation!

Dernæst: Kan man ikke måle og beregne frekvensen inden man begynder at dekode indholdet?

HKJ wrote: