Universeller IR-Receiver für viele Protokolle

Frank B. #1588180
Lesenswert?
• ▲
▼ 
Anbei ein Stückchen Code zum IR-Empfang.
Es ist theoretisch für so gut wie alle Fernbedienungsprotokolle 
einsetzbar.

Die Idee dahinter:
Die Kenntnis des Übertragungsprokolls ist nicht notwendig, es kommt nur 
darauf an, für jede Taste auf der FB einen anderen Wert zu bekommen.

Das Programm misst die Hi-und Lo Zeiten der Übertragung, speichert sie 
in einer temporären Tabelle, normiert sie und wendet dann eine 
Hashfunktion (hier der Einfachheit halber CRC32, weil der STM32 das in 
Hardware kann, es gehen aber auch andere nicht zu einfache 
Hashfunktionen) darauf an.

Ergebnis ist ein 32-Bit Wert, der für jede Taste auf der FB anders ist.

Bei manchen Protokollen bekommt man mehrere Werte, das liegt an den 
Protokollen selbst. In diesem Fall einfach den ersten benutzen... :-)

Die Normierung ist der Knackpunkt, und noch verbesserungswürdig, 
allerdings gehen bereits jetzt sämtliche bei mir im Betrieb und in den 
Schubladen "endgelagerten" befindliche Fernbedienungen problemlos :-)
Das ein oder andere Protokoll wird sicherlich nicht funktionieren, aber 
das allermeiste geht, glaube ich.
Wichtig ist, daß das zur FB passende IR-Empfänger-IC benutzt wird (u.a. 
passende Trägerfrequenz) , andernfalls sinkt die Erkennungsrate 
drastisch.


Portierbar auf so gut wie jede andere CPU (nat. auch AVR), es braucht 
nur einen Eingangspin, einen Timer, sowie eine gute Hashfkt. 
(http://de.wikipedia.org/wiki/Hash)
Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Frank B. #1589225
Lesenswert?
• ▲
▼ 
Name schrieb:
> Und dass funktioniert wirklich ?

Viel besser als man angesichts des kurzen Quelltextes glauben mag.

Bei meiner SIRCs (Sony) FB die ich hauptsächlich in meinem aktuellen 
Projekt verwende z.B. habe ich bisher keinen einzigen Empfangsfehler 
festgestellt.

Man kann das ganze noch geschickter mittels eines Input-Capture machen,
zugunsten einer leichteren portierbarkeit habe ich allerdings die 
Version ohne gepostet. Wenn die CPU viel mit anderen 
(höherpriorisierten) Interrupts zu hat, ist Input-Capture auf jeden Fall 
besser.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Frank B. #1589303
Lesenswert?
• ▲
▼ 
Di Pi schrieb:
> auch ein interessanter ansatz, einfach garnicht zu erkennen, was der
> hersteller senden wollte, sondern nur pulse durch einen CRC32 wursteln.
>
> Wie siehts da beim rc5-protokoll mit dem togglebit aus? das wird man
> doch eigentlich nicht einzeln erkennen können, oder?

Einzeln nicht. Wozu auch - wenn man will kann man das Toggelbit - das in 
einem anderen Rückgabewert (ir_getkeypress()) resultiert - auswerten.

Auch Wiederholungscodes sind so natürlich auswertbar - wenn man möchte.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Frank B. #1592629
Lesenswert?
• ▲
▼ 
Hier eine Hashfunktion, die auf einem AVR wesentlich schneller und 
kürzer als CRC32 ist, und für die IR-Routine ausreichend zu sein 
scheint:

Es handelt sich um einen abgespeckten Jenkins hash 
http://en.wikipedia.org/wiki/Jenkins_hash_function

1
int hash;

2


3
static inline void hash_reset(void) 

4
{

5
    hash=0;

6
}

7


8
static inline void hash_calc(uint32_t dat) 

9
{

10
    hash += dat;

11
    hash += (hash << 10);

12
    hash ^= (hash >> 6);

13
}

14


15
static inline uint32_t hash_get(void) 

16
{

17
    return hash;

18
}
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren