Fernbedien RC5 Empfänger

[Peter D. (peda)]

Anbei die Beschreibung und der komplette Code (AVR-GCC) meiner RC5
Empfangsroutine.

Sie hat folgende Vorteile:

- Der Timer ist durchlaufend und dadurch noch für weitere
Zeitbasis-Anwendungen verfügbar.
- Es wird nur ein Interrupt verwendet, dadurch ist der Code einfacher
und kleiner
- Es erfolgt eine Bitsynchronisation und damit sind selbst Abweichungen
von 10% ohne Einfluß
- Es erfolgt eine Pulsprüfung und dadurch werden Störungen bzw. Codes
anderer Fernbedienungen weitgehend unterdrückt


Peter

[Jochen (Gast)]

Klingt gut, werde ich direkt bei mir einbauen ;)

[Kai Markus Tegtmeier (Gast)]

Hallo, Peter!

Vielen Dank für die gute Anregung. Ist doch immer sehr fruchtbar, wenn
man sich über seine Codes mal austauscht. Ich habe immer darauf
vertraut, dass bei einer (zu) grossen Abweichung sicherlich irgendwann
einmal ein Biphasenfehler auftritt, der die weitere Verarbeitung
abbricht. Aber mit Bitsynchronisation ist das Ganze natürlich noch viel
eleganter gelöst. Respekt!

Viele Grüße
Kai

[Eddi (Gast)]

Hallo Peter

Genau das habe ich gesucht. Läuft tadellos und war selbst für mich
problemlos zu integrieren obwohl ich erst seit ein paar Tagen in C
programmiere. VIELEN DANK !

Gruß

Eddi

[schneidertobi (Gast)]

Hi,
eine Anmerkung zu dem Code:
Man sollte die rc5_data Variable besser als volatile deklarieren, sonst
kann es vorkommen, dass der gcc einem die Variable nicht wie gewuenscht
weiterreicht.

Tobias

[Peter D. (peda)]

Habe soeben festgestellt, der Eingangspin muß immer Pin 7 eines Ports
sein, damit der Compiler funktionierenden Code erzeugt.

Woran das liegt, weiß ich nicht.

Mein AVR-GCC.EXE ist von 21.09.2003.


Peter

[Sebastian Schildt (Gast)]

Hi!

Ich habe den Source gerade erfolgreich (nochmal danke dafür) auf einem
AVR 2323 eingesetzt. Der Eingang is Pin0. Geht problemlos (zum Glück,
das Ding hat ja gar keinen Pin 7, auf irgend einem Port :) )

 gcc version 3.3.1 aus WinAVR

MfG

Sebastian

[Peter D. (peda)]

Vergeßt mein letztes Posting, das ist totaler Quatsch.

Der Code ist einwandfrei und funktioniert mit jedem Bit !


Ich hab das Problem nur mit einer älteren Version, muß also bloß noch
rauskriegen, worin sich diese unterscheiden.

So ist das mit den großen GB-Festplatten.
Man hat viele Versionen eines Programms rumliegen und weiß dann nicht
mehr, welches nun die richtige ist.
Hab mir also meinen eigenen Code wieder vom Web runter laden müssen
:-)

Danke, Sebastian

Peter

[Alex (Gast)]

Hallo,

ich habe gerade mal versucht Peters Code zu verstehen. Hierbei ist mir
aufgefallen, dass zweimal der folgende Vergleich gemacht wurde:
(temp & 0x4000)
Warum wird das 15. Bit des empfangenen Codes überprüft, wo dieses doch
eigentlich immer Null sein sollte. Der RC5-Code ist doch eigentlich auf
14 Bit beschränkt.
Vielleicht kann mir ja mal wer auf die Sprünge helfen ;-)

Gruss, Alex

[Peter D. (peda)]

Das dient nur dazu, um nicht-RC5-Codes zu unterdrücken.

Werden also zuviel Flankenwechsel erkannt, wird kein weiteres Bit mehr
eingelesen und am Ende das Paket verworfen.


Peter

[Alex (Gast)]

Achso, vielen Dank für den Hinweis.

Alex

[Dirk (Gast)]

Hi,

ich hab mir heute dein Code angeschaut. Ich hab ein kleines Problem
deine folgende Aussage zuverstehen.

"Der Timer ist durchlaufend und dadurch noch für weitere
Zeitbasis-Anwendungen verfügbar. "

Ich habe dein Code wie folgt verstanden.

Der erste Timeroverflow0 kommt bei 16,xx ms ((Xtal 4Mhz / Presc. 256)*
timer0 (256)). Jetzt wird nach dem ersten Timeroverflow das
Timerregister auf 254 gestellt (TCNT0 = -2), somit kommt jetzt alle
128µs der Overflow von Timer0.

Wie soll man jetzt andere Zeitbasen erreichen? Über eine Variable die
in der ISR erhoeht wird? oder habe ich einfach nur ein Detail
übersehen?

Ich hoffe du kannst mir da ein bischen auf die Spruenge helfen.

Mfg

Dirk

[Peter D. (peda)]

Genau.

Der Interrupt kommt immer gleich, egal ob was empfangen wird oder
nicht.

Damit kann man darin bequem weitere Softwaretimer (Register
runterzählen) mit einfügen. Diese Softwaretimer können natürlich nur
ganzzahlige Vielache der Interruptzeit sein.


Andere RC5 Routinen stoppen den Timer aber, d.h. dort kann man den
Timer nicht noch anderweitig benutzen.


Peter

[Shazter (Gast)]

Hi,

ok dann hab ich es richtig erkannt. Ich bedanke mich für deine kurze
Bestätigung.

Mfg
Dirk

[Ulf Timmerlade (Gast)]

Hallo!

Danke für Deine Dekodierroutine, Peter!

Ich konstruiere gerade einen Drehstrom-Umrichter für meinen
Selbstbau-Stromgenerator, der per AVR angesteuert werden soll.
Fernbedienung soll sein, damit das Gerät vom Haus aus in der offenen
Garage gestartet werden kann.

In den nächsten Tagen weiß ich, ob die Software läuft. (ich sehe schon
die ersten Transistoren bei den kommenden Testläufen abrauchen ;-))

Deine Interruptroutine habe ich nur leicht angepasst übernommen; ich
hoffe, das ist OK. (Es stand nichts zur Softwarelizenz dabei)


Warum deklarierst Du rc5_bit, rc5_time und rc5_tmp nicht einfach in der
Interruptroutine als Speicherklasse static? (Ist vielleicht eine
Geschmacksfrage; ich finde das übersichtlicher)


Gruß,
Ulf

[Michael (Gast)]

Hallo Peter, eine Frage:
TCNT0 auf -2 setzen, ist das ein kleiner Spaß, oder was verbirgt sich
dahinter? Mein IAR-Compiler läßt diese Anweisung gar nict zu. Bitte um
Erklärung.
Michael

[Dirk (Gast)]

Hi,

ich hab doch da schon eine Erklaerung und da es mit GCC programmiert
ist kennt maybe dein IAR das register unter der Bezeichnung nicht.

Mfg

Dirk

[Michael (Gast)]

Doch doch, das Register kennt er schon. Eine Zuweisung mit dem Wert 254
funktioniert ja auch. Aber das Register ist per Deklaration ja
unsigned. Deshalb funktioniert es nicht. Ich wollte nur wissen, welcher
tiefere Sinn sich dahinter verbirgt. Mehr nicht.
Michael

[Peter D. (peda)]

Der Timer 0 kann doch nur aufwärts zählen.

Um nun die Schritte bis zum nächsten Interrupt anzugeben, stellt man
sie üblicher Weise als negative Zahl dar.
Ist ja viel besser lesbar.

Was paßt dem IAR daran nicht ?


Peter

[Michael (Gast)]

Peinlich, peinlich, IAR macht das, ich habe mich vertippt.
Entschuldigung in die Runde. Und worauf ich hinaus wollte hat Peter mit
der Lesbarkeit erklärt. Vielen Dank.
Michael

[D.E. (Gast)]

Hallo,

die Flankenerkennung ist mir etwas unklar...

(rc5_bit ^ xRC5_IN) macht das EXOR vom kompletten Register (8 Bit)
mit dem Inhalt vom Zustand davor, das ist mir klar, aber wie "fischt"
die Routine jetzt raus ob sich auch der IR Eingangspin bewegt hat ?

Wenn ichs soweit verstanden habe ist xRC5_IN der komplette Port "D"
mit 8 Bit und xRC5 ist das Eingangsbit für den IR Sensor oder ?
Das & 1<<xRC5 macht mir Kopfzerbrechen ...

Grüße

D.E.

[D.E. (Gast)]

#-) Brett vorm Kopf.

xRC5 ist natürlich nicht der Pin sondern nur die Port-Pinummer,
so macht es einen Sinn...

Grüße

D.E.

[Walter (Gast)]

Hallo guten Abend zusammen,

sorry für die blöde Frage aber wo bekomme
ich denn die passende IR Empfängerdiode her ??

M.f.G
Walter

[Dominik (Gast)]

Hallo Walter,

probier mal www.reichelt.de
Da hatte ich mir ne TSOP1738 bestellt.

Gruss
Dominik

[Carsten (Gast)]

Erstmal respekt für die Applikation...
da ich absoluter Newbie beim Controller-Programmieren bin, habe ich
mich für Assembler entschieden.
Hat schonmal jemand diese Applikation in Assembler umgesetzt ?
...by the way...
mit welcher Trägerfrequenz arbeiten die standard rc5-Fernbedienungen
eigentlich ?

[Thorsten (Gast)]

Die Trägerfrequenz beträgt 36kHz.

[Carsten (Gast)]

Danke Thorsten,
jetzt muss ich "nur" noch versuchen als "dummer" VB-Programmierer
den C-Code in Assembler zu konvertieren.
...das wird witzig...
vielleicht hat ja doch schon jemand sowas fertig grins

[Dirk (Gast)]

Hi,

da hilft www.google.de. Bei Atmel gibt es ein Appnote mit Source fuer
ASM.

Mfg
Dirk

[Carsten (Gast)]

Hallo Dirk...
ich google bereits seit mehreren Tagen.
Ok, irgendwann werde ich wohl mal fündig.
War ja auch nur ne Frage, man muss das Rad ja nicht zweimal erfinden.
Werde bei Atmel mal weitersuchen.

Ach ja, Du solltest Deine Maustaste mal entprellen !

[Stefan Seegel (Gast)]

Hallo!

Nach nächtelangem Debuggen krieg ich meinen RC5 Empfänger einfach nicht
zum laufen, auch glaub ich tret' das Teil gleich in die Tonne,
grummel...

Beim debuggen fällt auf dass ständig die rc5_time kleiner MIN_BIT_TIME
ist (im Souce steht da als Kommentar "to short"). Was heißt das ?
Prellen auf der Leitung ? Fernbedienung funktioniert am Fernseher, das
Signal sieht am Oszi sauber aus.

@Peter
Warum hast du eigentlich nicht als Timer-Vorteiler 256 genommen und
setzt dann immer TCNT auf -2, so dass ein fclk / 512 erreicht wird ?
Hab mal versucht mit Timervorteiler auf 1 und ohne TCNT zu setzen,
dadurch wird dann das SIGNAL mit fclk / 256 angesprungen, also doppelt
so schnell (hab auch die defines entsprechend geändert), hat aber auch
alles nix gebracht.

Hat jemand ne Idee, bevor ich in die Gummizelle muss ?!?!

Stefan

[peter dannegger (Gast)]

"Hat jemand ne Idee, bevor ich in die Gummizelle muss ?!?!"


Was hast Du denn für einen Quarz ?
Ist etwa noch der interne RC aktiv ?
Kannst Du irgendwas über die UART ausgeben ?

Der häufigste Fehler ist, daß die FB keinen RC5-Code sendet.


Peter

[Stefan Seegel (Gast)]

Hi Peter,

danke für die rasche Antwort.
System Clock war zunächst 4.0 MHz intern, hab dann, weil ich dachte die
interne Clock ist zu langsam/ungenau, einen externen 7,3728 MHz
drangehängt. Uart steht zur Verfügung und wird fleißig zum debuggen
benutzt (somit stimmt auch die Clock).

"Der häufigste Fehler ist, daß die FB keinen RC5-Code sendet."
ACH, da schau an, dachte dass sogut wie alle Fernbedienungen RC5 sind
?!?! Es handelt sich um so eine 6in1 Fernbedienung, die mit meinem
Fernseher, CD Player etc funzt. Sollte das ganze etwa kein RC5 Signal
sein !? Welche Fernbedienungen senden denn RC5 aus ?

...Das würde auch erklären warum ich mir immer noch nicht den
zusammenhang zwischen meinem OSZI Schirmbild und einem richtigen
RC5-Signal (z.B. Spettel.de) erklären kann...

Stefan

P.S. Was gibts denn sonst noch für Fernbedienungsprotokolle ?! Würde
gern diese Fernbedienung hernehmen....

[D.E. (Gast)]

Hi !

RC5 stammt ursprünglich von Philips. Deine FB ist doch vermutlich mit
Codes auf versch. Geräte einsellbar.

Meine Empfehlung ist erstmal die Codes für die Philips Geräte
ausprobieren, da ist eigentlich immer etwas in RC5 dabei, wenn auch
nicht alle Philips Geräte RC5 verwenden #-)

Mit dem Oszilloskop ist ja schnell gemessen ob es ein RC5 oder etwas
anderes ist....

Grüße

D.E.

[Stefan Seegel (Gast)]

Tach D.E.,

ja, hab grad im Web noch n bissl recherchiert, den Code den ich da
unglücklicherweiße erwischt habe scheint der "sircs" code von Sony zu
sein. Grrrr, da kann ich mich lange dumm und dusselig debuggen!
Mal sehen, entweder ich implementier mir eben ne sircs routine oder ich
such in der fernbedienung nach nem rc5-code...

Danke soweit,

Stefan

[Andreas Hesse (Gast)]

Hallo,

ich habe mal verschiedene Universalfernbedienungen verglichen und dabei
festgestellt, dass die vielfach gleiche Codenummern haben. Vielleicht
könnten wir die mal vergleichen, dann brauchst du nicht zu suchen.

Der RC5-Empfänger von Peter hat im übrigen bei mir direkt (nach
Anpassung der defines) funktioniert. Danke noch mal an Peter.

Gruss
Andreas

[D.E. (Gast)]

Diese Seiten enthalten viele Informationen, auch zu versch.
Protokollen.

http://www.ustr.net/infrared/index.shtml

http://www.xs4all.nl/~sbp/knowledge/ir/ir.htm


Grüße

D.E.

[FeeJai (Gast)]

Funktioniert der Code mit dem ATMega8 ohne Änderungen? Ginge er auch mit
Attinys? ich kann leider kein C!

[FeeJai (Gast)]

Ich weis, ich hab hier ne ziemlich doofe Frage gestellt, aber wäre
jemand trotzdem so nett zu antworten?

[Stefan Seegel (Gast)]

Ne, ist keine doofe Frage,

ohne das mal getestet zu haben würde ich sagen dass der Code auf nem
Mega8 mit Sicherheit läuft, und auf nem ATTiny auch, alles was man
braucht ist 1 Input Pin (der sollte wohl bei allen atmels vorhanden
sein) und einen Timer, der zyklisch den Zustand des Pins abfragt.
Wenn du aber kein C kannst wird das mit dem C-Code nicht so ganz
einfach...

Stefan

[Andreas Hesse (Gast)]

Hallo,

prinzipiell sollte der Code auch auf einem Tiny laufen, sofern der
internen RAM hat. Dazu müssten die UART Routinen aber entfernt werden.
Für die Bausteine ohne RAM bin ich nicht sicher, ob man da C verwenden
kann. Da könnte man aber den RC5 empfänger in Assembler schreiben. Ich
glaube da gab es mal ein App Note von Atmel.

Gruss
Andreas

[FeeJai (Gast)]

Jetzt hätte ich nochmal ne blöde Frage.

Könnte mir das jemand assemblieren (assembler) unhd als code für den
AT90S2313 hier posten? Damit müsste es doch auch laufen!

[Andreas Hesse (Gast)]

Hm,
ich verstehe nicht ganz, was Du genau vor hast.
Willst Du den C-Code von Peter als HEX-File haben, oder den
Assembler-Output des Compilers?
Wenn Du den HEX-Code benötigst, um eine Schaltung zu testen, müssten Du
noch die verwendete Taktfrequenz mitteilen (und eventuell die
Baudrate?).

Bei Atmel gibt es die Application Note 410 mit Beschreibung und
Assemblerquellen.
(http://www.atmel.com/dyn/products/app_notes.asp?family_id=607)

Gruss
A.Hesse

[FeeJai (Gast)]

Hi!

Erst einmal vielen Dank. Ich hätte gerne beides für den AT90S2313 mit
einem 2,4576 Mhz Oszillator! Ich finde es wirklich super von euch, dass
ihr euch extra für mich diese Mühe macht.

Felix

[Stefan Seegel (Gast)]

???

Ja was soll den der Code machen ?! Nutz ja eher nix wenn einfach die
RC5 Befehle dekodiert werden, irgendwas muß ja damit passieren ?!
Ansonsten gehts genausogut wenn man eine Fernbedienung auf eine
Schachtel Streichhölzer richtet, die macht das gleiche wie ein
AT90S2313 der RC5 Daten einfach nur dekodiert :-)

[FeeJai (Gast)]

Hi!
Ich dachte, der Atmel würde die Befehle über das UART ausgeben!
Felix

[[e-mail] (Gast)]

Hi,

ja, der Atmel sendet dann über den Uart.
Hex File ist im Anhang. Der RC5-Pin ist PD2.
Baudrate ist 9600.

Gruss
Andreas

[Stefan Seegel (Gast)]

Ja, wenn man dem Atmel sagt er solls über die UART ausgeben macht er das
auch ;-)
Aber die RC5 Routine alleine macht wohl nicht so viel Sinn...

Viel Spaß beim RC5 dekodieren

Stefan

[FeeJai (Gast)]

Danke, werds übermorgen mal ausprobieren!

[pebisoft (Gast)]

hallo, dieses programm ist gut gelungen und funktioniert. klasse,
mfg pebisoft

[pebisoft (Gast)]

hallo, bei mir funktioniert es tadellos.
mich würde noch einmal eine senderoutine interessieren. danke
mfg pebisoft

[max.p (Gast)]

hallo, was muss ich ändern damit das ganze mit 16 mhz fungtionier? ich
komm erlich gesagt mit den timern nicht ganz zurecht. was mir
aufgefallen ist, dass im code "TCCR0 = 1<<CS02; //divide by 256"
steht. im datenblatt sthet aber das das es dann ein 128er teiler ist.
was ist jetzt richtig? hab leioder noch keien empfänger zum
ausprobieren, wolte aber zumindest die SW schon mal verstehen.

mfg
Max

[Malte (Gast)]

Hallo,
dein Code funktioniert wunderbar, danke :-). Ich musste allerdings in
der MAIN.H bei den #include Einträgen entsprechend ein avr/ vor den
Dateinamen einfügen damit es funktioniert. Müssen die Variablen die in
der Interrupt Routine verwendet werden nich eigentlich alle als
volatile definiert werden? Als letztes wüsste ich wie weit ich den Code
verwenden darf, da ich gerne den Quellcode für die Steuerung eines
Roboters, der eine leicht veränderte Form deines Codes verwendet, auf
meine Homepage stellen würde.

@all
Wenn in der MAIN.C die Zuweisung für UBRRH und UCSRC auskommentiert
werden, läuft das ganze auch auf den älteren AT90S. Ich habs mit einem
AT90S4433 und einem AT90S2313 getestet.

@max.p
Also im Datenblatt des ATMEGA16 bedeutet TCCR0 = 1<<CS02 einen Teiler
durch 256, ein Teiler 128 ist überhauptnicht vorhanden.

[Peter D. (peda)]

Alternativ kannst Du alles, was unter \avr steht, eine Etage nach oben
kopieren, dann sparst Du Dir die extra Schreibarbiet.

Verwenden kannst Du alles uneingeschränkt, ein Urhebervermerk wäre
nicht schlecht.

Peter

[max.p (Gast)]

hallo malte
ok, du hast recht, hab jetzt in ein paar anderen datenblätern
nachgesehen. Ich hab nur in dem vom mega128 geschaut. Danke

mfg
Max

[DeltaEx (Gast)]

Kann mir einer sagen was in denn Zeilen gemacht wird?

#define RC5TIME   1.778e-3    // 1.778msec
#define PULSE_MIN  (uchar)(F_CPU / 512  RC5TIME  0.4 + 0.5)
#define PULSE_1_2  (uchar)(F_CPU / 512  RC5TIME  0.8 + 0.5)
#define PULSE_MAX  (uchar)(F_CPU / 512  RC5TIME  1.2 + 0.5)

und was dei 1.778e-3  das e-3 machen sowie
bei
#ifndef F_CPU
#define F_CPU 10000000e6     /* Quarz mit 10.0000 Mhz  */
#endif

das e6 ??

vielen dank

[Tobias Schneider (Gast)]

Das ist expotential schreibweise. 1.778e-3 wird einfach zu 0.001778. So
kann man die Zahlen besser lesen und vertippt sich auch nicht so
schnell.
Wie Peter aber auf F_CPU=10000000e6 kommt weis ich auch nicht.
Ist F_CPU vll. schon im Makefile definiert worden und der Fehler ist
sonst niemandem aufgefallen?

Gruß Tobias

[Tobias Schneider (Gast)]

Hm,
wo hast du den das
#ifndef F_CPU
#define F_CPU 10000000e6     /* Quarz mit 10.0000 Mhz  */
#endif

gefunden? Im zip finde ich nichts was so aussieht

[DeltaEx (Gast)]

Das ist nicht von Peter. Das habe ich so definiert.
Wollte 10 Mhz angeben. Ist das Falsch? wie gebe ich 10 Mhz ein?

#ifndef F_CPU
#define F_CPU 10000000e6     /* Quarz mit 10.0000 Mhz  */
#endif

Nach deiner erklärung müsste es nach der Schreibweise
0.000001
sein.

[Thorsten (Gast)]

10000000e6 = 1e13 = 10000000000000Hz, das ist glaube ich etwas viel :)

10MHz wären 10e6 = 1e7

[Daniel (Gast)]

Hallo zusammen,

ich hab ein echtes Problem, ich versuche hier seit einiger Zeit den
Code zum Laufen zu bekommen. Leider klappt es einfach nicht.
Ich bekomme andauernd die unten genannte Fehlermeldung.
Das Makefile ist eigentlich aus einem alten Projekt übernommen und
müste theoretisch funktionieren.
Den Code von Peter habe ich auch übernommen (danke dafür), ich habe nur
die Datei main.h in fernbedienung.h umbenannt.
Mir ist aufgefallen, dass wenn ich Make clean mache die Datei rc5.c
gelöscht wird... das kann doch nicht gut sein, oder?

Viele Grüße,

Daniel

ps: meine Dateien hängen an!

avr-gcc (GCC) 3.4.3
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


Linking: fernbedienung.elf
avr-gcc -mmcu=attiny26 -I. -gdwarf-2 -DF_CPU=8000000UL  -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=fernbedienung.o  -std=gnu99 -MD -MP -MF
.dep/fernbedienung.elf.d fernbedienung.o RC5/RC5.C
C:/Programme/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/include/avr 
/signal.h
--output fernbedienung.elf -Wl,-Map=fernbedienung.map,--cref    -lm
cc1plus.exe: warning: command line option "-Wstrict-prototypes" is
valid for C/ObjC but not for C++
cc1plus.exe: warning: command line option "-std=gnu99" is valid for
C/ObjC but not for C++
RC5/RC5.C: In function `void __vector_6()':
RC5/RC5.C:27: warning: converting of negative value `-0x000000002' to
`unsigned char'
C:\Programme\WinAVR\bin\..\lib\gcc\avr\3.4.3\..\..\..\..\avr\bin\ld.exe: 
fernbedienung.o:
file format not recognized; treating as linker script
C:\Programme\WinAVR\bin\..\lib\gcc\avr\3.4.3\..\..\..\..\avr\bin\ld.exe: 
fernbedienung.o:1:
parse error
make.exe: *** [fernbedienung.elf] Error 1

> Process Exit Code: 2

[Malte (Gast)]

@Daniel:
Also ich bekomme bei deinem Quelltext den gleichen Fehler, wenn ich im
Quelltext:
1: include "../dd1draht.h" auskommentiere
2: die Groß-kleinschribung der Dateinamen korrigiere
3: Die Pfandangaben zu RC5.C anpasse
4: im Makefile DEBUG = dwarf-2 auskommentiere
Ich wüsste jetzt auch nicht weiter. Aber du scheinst das irgendwie als
c++ und nicht als c zu compilieren, vielleicht liegt es ja daran.

[Daniel (Gast)]

Hallo,

danke für die Hilfe, ich habe es ausprobiert... und aufgegeben, wenn
ich den code direkt in die hauptdatei stecke funktioniert es prima!

Andere Frage: Wie könnte man denn eigentlich auch "nicht RC5" Signale
empfangen? Gibt es dazu Projekte?

Viele Grüße,

Daniel

[pebisoft (Gast)]

hallo, diese rc5-routine ist fehlerfrei. ein klasse programm.
weiter so peter d.
mfg pebisoft

[JojoS (Gast)]

habe die Routine jetzt auch mal ausprobiert es hat auf Anhieb
funktioniert, aber mit folgendem Problem:
ok: Gerät 0, Ziffern 0..9 z.B. werden korrekt auf Terminal ausgegeben
nicht ok: Gerät 0, andere Funktionen wie z.B Codes 24 und andere
'höhere'. Auch Gerät 5 (VCR) das gleiche: Ziffern ok, aber z.B. Stop
oder Play machen eine Ausgabe ('0 5 53') und dann passiert nix mehr,
µC braucht Reset.
Die FB ist original Philips (RT202) und auch mit einer anderen von
einem Philips CD Player zeigt das gleiche Verhalten.
Das Projekt läuft auf einem STK500 mit ATMega32 Proz, Takt ist 3,686
Mhz, serielle auf 9600 bit/s eingestellt, Zeichen und Startmeldung
kommen auch korrekt auf dem Terminal an. Empfangsdiode ist eine
SFH5110-36. Die RC5 Routine ist die aus dem ersten Posting hier.
Hat jemand eine Idee was da faul sein kann ?

[JojoS (Gast)]

habe den Fehler gefunden, meine IR-Diode war an PortB angeschlossen. In
der Beispielroutine in main.c wird aber PortB modifiziert:
    if( i ){
      DDRB = i;        // LED output
und damit wird meine IR-Diode totgeschaltet wenn das richtige Bit
getroffen wird...
Damit wäre aber doch noch ein kleiner Fehler in dem Beispiel: Wenn die
Led's gesetzt werden sollen dann müsste es doch
   PORTx=i;    // oder PORTx=~i; wenn LED's invertiert sind
heissen. Und in der initialisierung muss noch
   DDRx=0xff;
   PORTx=0xff;   // wenn LED's invertiert sind
gesetzt werden.

Damit wäre die erste Hälte meines Projektes fertig. Jetzt möchte ich IR
Code noch umsetzen und auf einem Funkmodul (FS20 von ELV) ausgeben.
Damit habe ich dann ein IR->Funk Gateway und ich kann mit meiner
Universal FB auch Licht und andere Geräte schalten (die eben per FS20
Funksystem angebunden sind).

[Danilo Reinhardt (Gast)]

Hallo,

ich bekomme leider den Code auf einem Mega8 mit 4MHz Takt (external
Crystal) nicht zum laufen.

Ich habe inzwischen verschiedene Fernbedienungen (2x Sony, 1x Pioneer,
1xNoname) getestet, ohne auch nur das geringste zu empfangen.

In der ISR geht er nie in die Abfrage die mit "change detect"
kommentiert ist. Woran könnte das liegen?

Danke und schönes WE!
Ciao Danilo

[Danilo Reinhardt (Gast)]

Nun, nach ner Nacht schlaf hat die kosmische Strahlung dazu geführt das
es schonmal besser funktioniert. Das heißt er empfängt, verwirft aber
das empfange in der Zeile mit dem Kommentar "only if 14 bits
received". Deutet dies auf ein Timing Problem hin, oder liegts daran
das alle FB hier nicht RC5 senden?

Ciao

PS: habe inzwischen noch 2 FB getestet, gleiches Ergebnis. Ich glaube
also eher an ein Timing Problem.

[Peter D. (peda)]

"oder liegts daran das alle FB hier nicht RC5 senden?"

Bei Sony und Pioneer bin ich mir zu 99.9% sicher, daß die einen eigenen
Code nehmen.

Versuchs dochmal mit einer Kombi-FB und stelle die auf Philips bzw.
probiere alle Codes durch.


Peter

[Danilo Reinhardt (Gast)]

@Peter, danke für die Antwort.

Hab  mal der Pioneer nen Phillips Code beigebracht, leider ohne Erfolg.
Vielleicht find ich eines Tages raus warum es nicht ging, bis dahin muss
ich halt zum uC laufen LOL

Ciao und Danke!

[Jens (Gast)]

Analysiere doch den gesendeten Code einfach. Wenn du kein Speicherscope
hast, gibs auf den Soundkarteneingang. Habe ich auch gemacht, hat recht
gut funktioniert.

[Frank (Gast)]

Ich bekomme das auch nicht zum laufen. :(

Ich habe einen AT90S4433 und benutze PD3 als Eingangspin (weil der
Empfänger da physisch prima dranpaßt) und als Empfänger habe ich einen
TSOP1736. Der TSOP1736 bekommt eine VCC von 3 V.

Ich habe eine FB, die eigenlich Philips-RC5 senden sollte (von einem
Grundig-Sat-Receiver).  Die kann man auch Fernseher von Philips
umstellen.

Nun weiss ich nicht, wo das Problem liegt: Ist die Fernbedienung doch
nicht RC5 oder der TSOP defekt oder der Pin nicht richtig initialisiert
...?

Über die serielle Schnittstelle kann ich zwar was empfangen. Ich habe
auch schon ein paar puts() in die Interrupt-Routine eingefügt. Aber ich
habe nicht das Gefühl, dass sich da irgendwas ändert, wenn ich auf der
FB irgendwelche Tasten betätige.

@Jens:
Blöde Frage, aber wie sollte man den Eingang der Soundkarte benutzen?
Wird dort der Out vom TSOP angeschlossen? Wenn ja, müßte man ja
ausschliessen können, das der dann defekt ist, wenn was ankommt. Und
was sagt mir dann das empfangene Signal? Woran erkennt man, dass das
RC5 ist?

Frank

[Jens (Gast)]

Du legst das Out vom TSOP auf den Eingang der Soundkarte (Masse nicht
vergessen) und zeichnest z. B. mittels Cooledit das empfangene Signal
auf. Das Programm zeigt dir dieses dann als Wave-File auf dem
Bildschirm an. Da du die Abtastrate und somit die Zeit zwischen zwei
Samples kennst, kannst du mit den Cursorfunktionen des Programms
messen, wie lange die einzelnen Impulse bzw. Impulsfolgen dauern.
Daraus wiederrum kannst du ableiten, ob es sich um RC5 handelt oder
nicht.

Die Soundkarte in Verbindung mit Cooledit funktioniert quasi als
Digitalspeicheroszilloskop.

Jens

[Frank (Gast)]

@Jens

War ein guter Tip.

Wenn ich den TSOP in der Schaltung lasse, bekommt er eine VCC von 3 V.
Da kann ich mit der Soundkarte auch nichts messen (Kein Wunder, dass
der Controller keine Reaktion zeigt.). Wenn ich ihn aber mit 6 V
versorge, kommt ein Signal an. Komisch, im Datenblatt stand doch (wenn
ich mich recht entsinne) VCC 0,x .. 6,0 V. Da liegen die 3 V doch
mitten drin!? Oder arbeitet der TSOP nur mit TTL-Pegeln?

[Jens (Gast)]

> VCC 0,x .. 6,0 V.

Das sind die "absolut maximum ratings", die nur aussagen, dass der
Baustein innerhalb dieses Bereichs nicht sofort kaputt geht.

Es gibt allerdings auch 3V-Varianten des TSOPs, nur leider sind die
schwer erhältlich.

[Danilo Reinhardt (Gast)]

Ich benutze zwar den TSOP18xx aber im Datenblatt Seite 2 "Application
Circuit" steht "tolerated supply voltage range : 4.5V<VS<5.5V". In
der Datentabelle angegeben ist "Supply Voltage -0.3 to 6.0V".

Von daher sollten 3V wohl nicht reichen, was leider auch in meiner
Schaltung gleich mal zum Problem wird. :)

[Frank (Gast)]

"Supply Voltage -0.3 to 6.0V".

Und was heißt das? Ich dachte erst, in diesem Bereich arbeitet das
Ding. Aber das kann ja nicht sein... Ist das wirklich nur die Angabe,
dass das Teil da nicht kaputt geht? Wieso heißt das dann "Supply
Voltage"?

[Jens (Gast)]

Naja, wie willst du es sonst nennen? Die Supply Voltage darf halt nicht
außerhalb dieses Bereichs liegen, sonst machts (vielleicht) peng!

[chris (Gast)]

hallo,
kann ich auch einen TSOP 1738 (38kHz) benutzen ?
 Chris

[Simon K. (simon)]

Hey.

Ich hab den Code eingebunden und ein wenig vom Einbau her verändert. Am
Code selbst habe ich nur in der Mainloop was verändert (mit
rc5_data_last).

Ich habe nun folgendes Problem:
Dürcke ich auf eine Taste, so erscheint das passende im
Terminalfenster. Drücke ich danach auf eine andere Taste, erscheint den
dazu passenden Code, jedoch mit dem Togglebit getoggelt. Ich weiß nicht
ob das richtig ist, aber mein nächstes Problem ist, halte ich eine
Taste gedrückt, kommt die Taste einmal an (mit getoggeltem Togglebit)
und dann garnichts mehr.

Der code ist im Anhang. Vielleicht will ja mal jemand kurz
drüberschauen.

[Simon K. (simon)]

Kann es sein, dass es richtig ist, dass das Togglebit getogglet wird
wenn 2 Tasten unmittelbar hintereinenader gedrückt werden

ABEr das Togglebit bleibt gleich, wenn man die Taste gedrückt hält?

[Pete da Heat (Gast)]

>>Kann es sein, dass es richtig ist, dass das Togglebit getogglet wird
>>wenn 2 Tasten unmittelbar hintereinenader gedrückt werden

>>ABEr das Togglebit bleibt gleich, wenn man die Taste gedrückt hält?

Ja, das ist ja genau der Sinn des Toggle-Bit. Zu Erkennen, ob eine
Taste dauerhaft gedrückt wird oder mehrmals hintereinander.

Pete

[Simon K. (simon)]

Ähm, ist das nicht so, dass bei langem drücken das Toggle Bit getoggelt
wird und bei einmal drücken das immer 0 oder 1 ist?

[pebisoft (Gast)]

hallo, gute sache(routine).

habe diese umgesetzt in fastavr-basic 1:1.
läuft klasse. hatte nicht gesacht, das dieses fatsavr-basic es so gut
kann. progge damit schon 5 monate.

mfg pebisoft

[Pete da Heat (Gast)]

Hallo Simon

quote: "Das Toggelbit ändert seinen Wert bei jedem Tastendruck.
Dadurch kann man das lange Drücken einer Taste (und damit das
wiederholte Senden eines Befehls) vom wiederholten Drücken der selben
Taste unterscheiden. "

zu lesen auf: http://www.sprut.de/electronic/ir/rc5.htm

Pete

[Jan (Gast)]

hallo zusammen,

ich habe bisher vergebens versucht einen TSOP1738 an meinem ATmega8 zum
laufen zu bekommen. In sämtlichen Schaltplänen wird immer wieder der
TSOP1736 oder SFH5110-36 erwähnt. Unter Linux (LIRC) läuft mein
TSOP1738 tadellos, nur halt an meinem Board nicht. Wenn ich ein Piezo
Schallwandler an die Data Leitung anschließe hört man ganz deutlich das
er funktioniert. Nur mein Atmel kann mit dem Signal nichts anfangen. Hat
jemand eine Idee ??  Läuft denn der 1738 überhaupt an dem Atmels oder
bin ich gezwungen mit einen 1736er zu bestellen ??

[Lupin (Gast)]

das sind alles die gleichen nur die demodulationsfrequenz ist anders.

ich würde vermuten es liegt eher an deinem programm. hast du den 1738
an nen interrupt pin? alles richtig eingestellt? Haben AVR und 1738 die
gleiche masse? :P

[Jan (Gast)]

Hi Lupin,

danke erstmal für deine schnelle Antwort.!.
Da ich noch Newbie bin bitte ich um Entschuldigung... ;-)

Denn du hattest völlig recht, es lag tatsächlich an meinem Programm.
Nach wirklich langen suchen im Netz bin ich dann auf mein Problem
aufmerksam geworden. Und zwar hatte ich im Bascom "If Address = 0
Then" stehen und somit funktionieren natürlich auch nur RC5
Fernbedienungen von Fernseh-Herstellern die die "Adresse 0" senden
:-)

Nachdem ich die Fernbedienung meines Fernseher ausprobierte,
funktionierte gleich alles auf Anhieb ;-)
Der TSOP1738 läuft jetzt tadellos mit meiner Schaltung zusammen,
und ich kann damit z.B. Relais schalten...

** Ich wünsche allen noch eine schöne Weihnachtszeit und einen gesunden
Rutsch ins neue Jahr**

[Hilel (Gast)]

Hallo zusammen.
Hat jemand von Euch den Code von Peter für ATMega128 und 16 MHz
Taktfrequenz angepasst? Ich verwende den TSOP1736 an PINE.5 und bekomme
das Programm (noch) nicht zum laufen. Muss der Eingangspin
Interrupt-fähig sein? Ich sehe nur das Timer0-Interrupt.
Danke im voraus

[Hilel (Gast)]

Hat sich erledigt.
Danke.

[André (Gast)]

Hallo zusammen,

ich weiß nicht, ob es noch jemanden interessiert, aber Daniel hat am
03.06.2005 gepostet, dass er immer Fehlermeldungen und Warnungen des
Compilers bekommt. Unter anderem auch:
"cc1plus.exe: warning: command line option "-Wstrict-prototypes" is
valid for C/ObjC but not for C++"
Das kommt daher, dass der Compiler sich die Endung des Sourcefiles
(hier: .C) anschaut und ein großes .C als C++-Datei und ein kleines .c
als C-Datei unterscheidet und entsprechend kompiliert.
Wenn man gem GCC-Compiler als Option -xc mitgibt, werden auch
.C-Dateien als C-Dateien behandelt.
Das ganze kommt aus der UNIX-Welt, wo zwischen Groß- und
Kleinschreibung unterschieden wird.

Gruß André

[Frank (Gast)]

Hi, super Code !
Ich versuche grade ihn zu verstehen, weil ich so ändern möchte, daß er
mit nicht-invertiertem Eingang funktioniert. Ich brauche das für eine
Kabelgebundene Steuerung ( d.H. ich habe keine Empfängerdiode, sondern
den Eingang über ein langes Kabel mit dem "Sender" verbunden, den
Träger filtere ich mit einem Kondensator (1.8nF)+Widerstand (10K)
heraus (es geht um eine Hifi-Steuerungsgeschichte)). Klar könnte ich
mit einem Transistor invertieren, aber warum ein zusätzliches
Bauteil..:-)

1.
"if( (rc5_bit ^ xRC5_IN) & 1<<xRC5 ){ rc5_bit = ~rc5_bit; ..."

erkennt wohl die Flanke, und "if( !(rc5_bit & 1<<xRC5) ) tmp |= 1;"
setzt das Bit in TMP. Was ich nun nicht verstehe:
Nirgendwo gibt es eine initiale Zuweisung für rc_bit. Oder habe ich die
einfach nicht gesehen ? Wenn das Programm das erste Mal läuft ist der
Wert von rc_Bit doch zufällig. Verstehe ich da etwas falsch ? Oder ist
das egal ?

grübel....

2.
Ist es korrekt, dass ich für meine nichtinvertierten Signale einfach
nur die Zeile auf if( (rc5_bit & 1<<xRC5) ) tmp |= 1;" ändern muss ?


Danke im Voraus !
Frank

[Werner B. (Gast)]

@Frank,

invertiere doch einfach das gelesene Bit VOR der Auswertung. So musst
Du am getesteten Code nichts ändern!

[Frank (Gast)]

@Werner:

LOL, manchmal denkt man einfach zu kompliziert. Natürlich hast Du
Recht. Warum um alles in der Welt bin ich nicht selbst darauf
gekommen...

Naja, den Code muss ich natürlich trotzdem ändern (halt die Stellen wo
der eingangspin gelesen wird). Aber das macht die Sache einfacher :-)

Danke !
Frank.

[Frank (Gast)]

@Werner:

Funktioniert prächtig!

Wen eine Kabelsteuerung interessiert:
Man braucht einen Tiefpass um den Träger loszuwerden. Also Kondensator
1,8nF und Widerstand 10K parallel an GND, das andere Ende an den
Eingangspin. Jetzt noch im Source die Zeile "if( (rc5_bit ^ xRC5_IN) &
1<<xRC5 ){ rc5_bit = ~rc5_bit; ..." auf "if( (rc5_bit ^ (~xRC5_IN)) &
1<<xRC5 ){ rc5_bit = ~rc5_bit; ..." ändern und fertich.


Frank.

[Bärenmarke (Gast)]

Hallo! Die Beschaltung nehme ich so vor wie im Datenblatt vorgeschlagen?
Muss ich irgend einen speziellen PIN nehmen?


http://www.reichelt.de/inhalt.html?SID=17R2AJ1KwQARIAAFFVd9c21a427bea00e9bc5d79fd8cef9c46028;ACTION=7;LASTACTION=6;SORT=artikel.artnr;GRUPPE=A54;WG=0;SUCHE=TSOP;ARTIKEL=TSOP%25201736;START=0;END=16;STATIC=0;FC=669;PROVID=0;TITEL=0;DATASHEETSEARCH=TSOP%201736;FOLDER=A500;FILE=TSOP1730_TSOP1736_TSOP1738_TSOP1756%2523VIS.pdf;DOWNLOADTYP=1;DATASHEETAUTO=;OPEN=1

[Sebastian F. (haseluenne)]

Hallo! Da kein externer Interrupt benötigt wird, sollte der Pin egal
sein. Hab das jetzt aber nicht überprüft. Beschaltung steht bei den
Kollegen von
http://www.roboternetz.de/wissen/index.php/RC5-Decoder_f%C3%BCr_ATMega

[Nik Bamert (Gast)]

So ich habs nun heute auch mal ausprobiert, einfach genial,
funktioniert perfekt :-)

[karl-heinz (Gast)]

ich habe ihn sogar so geändert, das ich jetzt auf einmal 12bit empfangen
kann. benutze ich für eine steuerung, 1 datenbyte 8bit und ein
steuer-nibble 4bit. klappt wunderbar. 12bit kann ich auch mit einem
schwung senden, habe ich selber geschrieben.

[Peppe (Gast)]

Hallo,
ich bin gerade auf dieses Projekt aufmerksam geworden, da ich noch ein
Tsop rumliegen hatte habe ich ihn direkt mal an mein Atmega 8
angeschlossen. Hat auf anhieb funktioniert, echt prima.
Ich habe eine 8 in 1 fernbedienung aber ich bekomme es einfach nciht
hin das ich ausser Device 0 etwas anderes empfangen bzw decodieren
kann. kann das an der Source liegen?? ich habe irgendwo gelesen man
müsste ein pullup Widerstand mit anschliesen, das habe ich nicht
gemacht. könnte es daran liegen??
Gruß Peppe

[Sebastian Bäumler (Gast)]

Hallo,

ich habe mal eine Frage zur Pause zwischen zwei frames?
Vielleicht wurde es schon beantwortet, und ich habe es nur überlesen.

Wie lang ist die minimale Pausenlänge zwischen zwei frames, damit diese
als richtig interpretiert werden kann. Oder reicht es, wenn nach dem
14Bits des ersten Frames die startbits des zweiten frames kommen?

Ansonsten freue ich mich schon darauf den Code vom Peter
auszuprobieren!

[Sebastian Bäumler (Gast)]

Hallo,

meine Frage hat sich erledigt!

Zwischen zwei Frames muss min. 114ms Pause sein.
Diese Information habe ich auf
http://mikrocontroller.cco-ev.de/de/IR-Protokolle.php gefunden.

Falls das falsch ist, sagt mir doch bitte Bescheid!
Gruss Sebastian

[Clemens Schmiegel (Gast)]

Hallo,
Könnte mir jemand weiterhelfen indem er mir sagt wie ich den code
anpassen muss, damit er auf einem Atmega8 mit dem internen Timer läuft?
das wär spitze.

[gehts noch ? (Gast)]

Nein

[Clemens Schmiegel (Gast)]

Aha, und warum nicht? es ist ja bestimmt ganz einfach, oder? ich habs
nur noch nicht hinbekommen.
Es gibt einige Sachen die mich verwirren.
1. "Der Timerinerrupt wurde so eingestellt, daß er alle 512 Zyklen
aufgerufen wird. Damit ergeben sich bei 4MHz je Bitzeit
4e6/512*1.778e-3=14 Aufrufe des Timerinterrupts. Das ist ausreichend
fein gestaffelt, um die verschiedenen Zeitbedingungen testen zu können.
Bei höheren Quarzfrequenzen kann man die Zyklenzahl entsprechend
erhöhen."
Welche Zyklenzahl brauch ich denn?
2. "#define  XTAL    11.0592e6"
Das bedeutet das ein externer Quarz mit 11MHz angeschlossen ist, oder?
Und kann ich jetzt einfach sagen: #define FCPU  16e6 , und XTAL überall
durch FCPU ersetzen?
3. Wie müsste ich den Vorteiler einstellen?

[Clemens Schmiegel (Gast)]

hat sich erledigt... ich habs gepeilt...

[Christina (Gast)]

Wird als Hardware nur ein Fototransistor genutzt, der bei Infrarotlicht 
einen Pin auf Masse zieht?

Könnte jemand die Beaschaltung ganz kurz nochmal beschreiben? Danke =)

[Malte _. (malte)]

Die Beschaltung ist ein TSOP17xy mit einem kleinem Kondensator zur 
Glättung in der Versorgungsspannung und der Ausgang direkt an den AVR 
geschaltet.

[Christina (Gast)]

danke :)

[Di P. (drpepper)]

Ich lese hier von TSOP1736 und TSOP1738...

Heißt das, dass es immer mit beiden Frequenzen (36 und 38kHz) 
funktioniert?

[Jörg (Gast)]

Hallo,

auch ich habe das Rad nochmal erfunden, aber etwas anders. So wie oben 
konnte ich das in meinem bestehenden "System" nicht einbauen, u.A. kein 
Timer mehr frei, zu lange Interrupt-Responsezeiten.

Ich verwende nun den Capture-Interrupt, was verschiedene Vorteile hat:
- Interrupt-Antwortzeit ist weitgehend egal
- nur soviele Interrupts wie Flanken im Signal
- Synchronisation kommt gratis dazu
- er war noch frei   ;-)

Die Capture-Hardware liest bei einer entsprechenden Flake den Timer aus, 
merkt sich den Wert und wirft einen Interrupt. In der ISR kann ich mir 
nun "in Ruhe" die Differenzen der Zeitmarken ansehen, auf Gültigkeit 
checken und die Dekodierung darauf aufbauen. Ich invertiere dabei die 
aktive Flanke, um beide Richtungen mitzukriegen. Der Code dieser ISR ist 
eigentlich recht kompakt. War aber trotzdem trickreich, den zum Laufen 
zu kriegen.

Außer dieser ISR gibt es noch etwas Code an einer Stelle meiner 
bestehenden "Infrastruktur":
In einem "Heartbeat"-Interrupt checke ich auf hängende (unvollständige) 
Dekodierung und setze ggf. den Dekoder zurück.
Dort ist auch ein weiteres Timeout implementiert, was das Loslassen der 
Fernbedienungstaste erkennt. Also wenn keine Code-Wiederholungen mehr 
empfangen werden.

Bei ernsthaftem Interesse kann ich das mal posten. Erfordert aber noch 
etwas Arbeit, es auf ohne "Nebenwissen" lesbar zu vereinfachen. Ich 
mache z.B. keine direkten Registerzugriffe, sondern verwende eine 
selbstgestrickte, dünne Abstraktionsschicht. Die ISRs senden ihre 
Ergebnisse durch eine Queue zum Hauptprogramm, statt nur gemeinsam 
genutzte Variablen zu verändern.

Das Prinzip mit dem Capture-Interrupt sollte auch für andere 
Fernbedienungscodes taugen. Ich bin immer noch auf der Suche nach einem 
lernfähigen Universalempfänger...

Gruß
Jörg

[Oliver (Gast)]

"... u.A. kein Timer mehr frei"

????

Der Trick bei allen Programmen von P.D. besteht doch darin, eben nicht 
exklusiv einen Timer zu belegen, sondern nur einen frei laufenden 
Timerinterrupt mitzunutzen. Und das so einer "nicht mehr frei ist", gibt 
es nicht.

Aber trotzdem schön, daß dein Implementierung auch läuft :-)

Oliver

[Jörg (Gast)]

@Oliver:
Ich korrigiere mich auf "kein externer Interrupt mehr frei". Der 
Capture-Pin hingegen war verwendbar.
Dessen unbenommen halte ich ich den Capture-Interrupt allgemein für 
geeigneter. Damit kriegt man einen präzisen Zeitstempel der Flanke, 
unabhängig von Interrupt-Latenzen, welche nur kleiner als die Pulsbreite 
sein brauchen.

[Peter D. (peda)]

Jörg wrote:

> Dessen unbenommen halte ich ich den Capture-Interrupt allgemein für
> geeigneter. Damit kriegt man einen präzisen Zeitstempel der Flanke,
> unabhängig von Interrupt-Latenzen


Und was willst Du mit dem präzisen Zeitstempel anfangen, ihn ins Album 
kleben ?

Es reicht doch völlig, wenn man die Flanken eindeutig zuordnen kann.


Peter

[Jörg (Gast)]

@Peter:
Darin besteht doch die Decodierung, kurze und lange Pulse (=Differenz 
der Zeitstempel) zu unterscheiden.
Habe ich das so unklar beschrieben?

[Peter D. (peda)]

Jörg wrote:
> @Peter:
> Darin besteht doch die Decodierung, kurze und lange Pulse (=Differenz
> der Zeitstempel) zu unterscheiden.

Sach ich doch.
Eine übertriebene Genauigkeit ist also völlig unnötig.

Wenn ein Impuls 4..6 Zeitscheiben und der andere 8..12 breit ist, kannst 
Du schon klar erkennen, obs ein kurzer oder langer ist. Geeigneter gehts 
nicht.


Peter

[Oliver (Gast)]

Da erwartest due einen Puls der Länge 1000, und die blöde, völlig 
ungeeichte FB sendet alles mögliche zwischen 980 und 1020, nur niemals 
genau 1000. Und nu? Was machst du jetzt mit den Zeitstempeln?

Oliver

[Jörg (Gast)]

Ihr macht's mir ja nicht leicht...  ;-)

Natürlich erlaube ich für die Flanken eine gewisse Toleranz. Aber ich 
will sie auch nicht unnötig vergrößern, nur weil ich meine 
Interruptlatenzen auch noch draufrechnen muss. Sonst interpretiert das 
Programm wohlmöglich auch nicht-RC5 Pulsfolgen fälschlicherweise, aus 
meinem Fernbedienungszoo. (Eine Flanke außerhalb der Toleranzbandes 
bricht das Dekodieren ab.)

Ich versuche zu erklären, dass ich im "System" noch andere 
Interruptquellen habe, deren Latenz schon bald in die Nähe der 
Pulsdauern kommt. Nested Interrupts kann ich nicht, dann müßte ich in 
der Software einige Klimmzüge machen um alles reentrant zu kriegen. Der 
Atmel kann keine Priorisierung der Interrupts, sonst könnte man dem 
IR-Interrupt eine Sonderstellung einräumen.

Lange Rede, kurzer Sinn: Wenn eine Capture-Hardware existiert und 
verfügbar ist, dann sollte man die doch gegenüber "einfachen" externen 
Interrupts bevorzugen.

Jörg

[Peter D. (peda)]

Jörg wrote:

> Lange Rede, kurzer Sinn: Wenn eine Capture-Hardware existiert und
> verfügbar ist, dann sollte man die doch gegenüber "einfachen" externen
> Interrupts bevorzugen.

Der Schuß kann aber auch nach hinten losgehen.

Die Sensoren liefern auch gerne mal kurze Störimpulse, die würden dann 
sofort gecaptured.

Beim Sampeln ist die Warscheinlichkeit wesentlich geringer, daß so ein 
Störimpuls mit dem Sampletakt zusammen fällt.

Außerdem habe ich noch im Programm drin, daß zu kurze Impulse ignoriert 
werden und auf die nächste Flanke getriggert wird.

Nicht immer muß also ein zu schnelles Capture auch sinnvoll sein.


Du hast natürlich recht, daß andere Interrupts stören können, wenn sie 
zu lange dauern.


Peter

[Jörg (Gast)]

Guter Input mit den Stör-Spikes, da werde ich nochmal drauf schauen.

[Tobias Tezlaff (Gast)]

Hallo,

ich habe mich nun nochmal mit deiner (Peter) RC5 Routine befasst.

Dein Testcode um per UART die RC5 Daten angezeigt zu bekommen 
funktionierte auf Anhieb!

Nun habe ich noch eine Frage.
Ich möchte je ein Char für den Gerätecode und den Tastencode haben.
Warum klappt das hier nicht?

//Variablen allgemein
volatile unsigned char Bild = 0;
//und für RC5
uint i;
char s[30];
char DeviceAdress = 0;
char KeyCode = 0;

im Main:

//RC5
cli();
i = rc5_data;      // read two bytes from interrupt !
rc5_data = 0;
sei();
if( i ){

  DeviceAdress = itoa( i >> 6 & 0x1F, s, 10);  // Device address
  //  puts( DeviceAdress );
  //  putchar(' ');
  KeyCode = itoa((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code
  //  puts( KeyCode );
  //  puts( "\n\r" );

  //NullPosition
  if ( DeviceAdress == 1 ){
   bInt0 = 1;
  }
  switch ( KeyCode ){
   case 0 : Bild = 0;break;
   case 1 : Bild = 1;break;
   case 2 : Bild = 2;break;
   case 3 : Bild = 3;break;
  }
}

wenn ich die beiden Zeilen:
  //  puts( DeviceAdress );
  //  putchar(' ');

und
  //  puts( KeyCode );
  //  puts( "\n\r" );

reinnehme, sehe ich im Hyperterminal die beiden Zahlen, GeräteCode und 
KeyCode.

Danke im voraus...

Gruß Toby

[Tobias Tezlaff (Gast)]

Hallo,

habs schon gefunden.

die beiden Zeilen um aus dem RC5 Code die beiden Byte zu machen müssen 
so lauten:

DeviceAdress = i >> 6 & 0x1F;  // Device address
KeyCode = (i & 0x3F) | (~i >> 7 & 0x40); // Key Code

Ich muß die bytes ja nicht in ASCII umwandeln, da ich diese ja nicht per 
UART senden will.

Gruß Toby

[Enrico Tabatzi (Gast)]

Ich habe das Program gerade auf ein atmega 8 mit internen 4Mhz Taktgeber 
getestet, aber leider funktioniert es hier nicht. Kann es sein das der 
interne Oszilator nicht genau genug arbeitet?

Und gibt es eine Möglicht diese Taktgeben irgendwie zu kalibrieren?

Gruss,
Enrico

[Werner B. (Gast)]

> Kann es sein das der interne Oszilator nicht genau genug arbeitet?

Nein. Der Takt ist prinzipiell Egal (solange er nicht bei 100kHz oder 
darunter liegt).

[Werner B. (Gast)]

Upps, sorry. War in Gedanken bei den "Enprell" - Problemen.
Der Takt muss WESENTLICH höher als die 36kHz des IR Signals sein.
Das elegante an diesem Code ist eben gerade dass er recht unempfindlich 
gegen Frequenz/Taktabweichunge ist. 4MHz ist aber OK. Bist du dir sicher 
dass die Fuses auf 4MHz stehen?

[Wolfgang (Gast)]

Hallo Peter,

Ich vermute mal das es in der Anweisung statt

 itoa((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code

 itoa((i & 0x3F) | (~i >> 6 & 0x40), s, 10);

sein soll da (~i >> 7 & 0x40) immer Null ist.

Gruß Wolfgang

[Simon K. (simon)]

Moin, ich hab mal eine kleine Frage zum Verständnis der 
Manchester-Codierung, die ja bei dem RC5 Protokoll benutzt wird.

Wenn ich das richtig sehe, ist die Kern-funktion diese:

#define  xRC5_IN    PIND
#define  xRC5    PD7      // IR input low active

uint8_t rc5_bit = 0;
uint8_t rc5_val = 0;

SIGNAL (SIG_OVERFLOW0)
{
  if( (rc5_bit ^ xRC5_IN) & 1<<xRC5 )
  {  
    rc5_bit = ~rc5_bit;

    rc5_val <<= 1;
    if( !(rc5_bit & 1<<xRC5) )  
      rc5_val |= 1;  
  }
}

Sprich: Jede Flanke wird gesampled und das Bit unten hereingeschoben.

Frage: Kann das so funktionieren? Ich glaube nämlich, dass die 
Zeiterkennung, die in deinem Code noch miteingebaut ein elementarer 
Bestandteil der Bit-erkennung ist und nicht nur Fehlerbehandlung.

In dem deutschen Wikipedia-Artikel zum Manchester-Code sieht man ein 
Beispielscode:
http://de.wikipedia.org/wiki/Manchester-Code

Hier sieht man nämlich eindeutig, dass nicht jede Flanke ein Bit 
darstellt. Sondern im Beispiel von zwei aufeinanderfolgenden nullen oder 
zwei einsen nur jede zweite flanke ein Bit darstellt.

Liege ich also richtig in der Annahme, dass man nicht einfach jede 
Flanke einlesen kann? Vielleicht habe ich ja noch irgendeinen Trick in 
deinem Code übersehen?

PS: Oder sollte ich lieber eine andere Decodierungsart wählen, wenn ich 
nur reinen Manchester decodieren will?

[Peter D. (peda)]

Simon Küppers wrote:

> Liege ich also richtig in der Annahme, dass man nicht einfach jede
> Flanke einlesen kann? Vielleicht habe ich ja noch irgendeinen Trick in
> deinem Code übersehen?

Stimmt, es wird nicht jede Flanke eingelesen:

if( rc5_time < PULSE_MIN )      // to short
      tmp = 0;

Peter

[Simon K. (simon)]

Peter Dannegger wrote:
> Simon Küppers wrote:
>
>> Liege ich also richtig in der Annahme, dass man nicht einfach jede
>> Flanke einlesen kann? Vielleicht habe ich ja noch irgendeinen Trick in
>> deinem Code übersehen?
>
> Stimmt, es wird nicht jede Flanke eingelesen:
>
>

> if( rc5_time < PULSE_MIN )      // to short
>       tmp = 0;
>

Dank dir. Blöd ist nur, dass man im Vorhinein die Frequenz wissen muss, 
bzw. die Frequenz im Betrieb vom Manchester-Signal ableiten muss.
Du hast ja ersteres genommen.
Bei letzterem hätte man wieder das Problem, dass ein Timer für die 
Manchester-Geschichte draufgeht, da man ja immer unterschiedlich 
reloaden muss.

[Lars Lochmann (Gast)]

Ich hab mal versucht einen PAP für die Empfangsroutine zu erstellen. (Im 
Anhang)
Ich denke es funktioniert so ungefähr. Was meint ihr?

[zett (Gast)]

Ich nutze seit gestern auch die RC5-Auswertung von Peter.

Da ich die Adresse und den Befehl jeweils auf einen PORT schreibe habe 
ich alle Codezeilen die das UART betreffen auskommentiert.

Zu meiner Überraschung lief der Code bei mir nicht mehr bzw. nicht mehr 
wie zuvor.

Ich habe es auf folgende zwei Code Zeilen eingrenzen können:

>      itoa( i >> 6 & 0x1F, s, 10);  // Device address
>      itoa((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code

wenn ich die raus schmeiße geht nichts mehr.

Dieses Verhalten kann ich mir nicht erklären.

mit den beiden Code Zeilen + die Deklaration von s läuft der Code 
einwandfrei.

[Lars Lochmann (Gast)]

Ich hoffe du hast die puts() Funktionsaufrufe auch heraus genommen. 
Sonst könnte es sein dass er sich in der Funktion aufhängt, weil er über 
Pointer auf Null prüft. Also nach den itoa() da stehen die puts() die 
musst du dann auch heraus nehmen.

[zett (Gast)]

@Lars: Danke für die Reaktion.

Wenn ich die drei auskommentierten Zeilen auskommentiert habe geht 
nichts mehr.

PS: Ich weis da da zu viel includiert ist. Kann es daran liegen?

#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <avr/interrupt.h>
#include "dev/rc5.h"


int main( void )
{
  uint i;
  long myCount = 0;
//  char s[30];

  TCCR0 = 1<<CS02;      //divide by 256
  TIMSK = 1<<TOIE0;      //enable timer interrupt

  DDRB  = 0xff;
  DDRC  = 0xff;
  DDRD  = 0x00;   
  PORTB = 0xff;
  PORTC = 0xff;
  
  sei();
  for(;;){        // main loop
    cli();
    i = rc5_data;      // read two bytes from interrupt !
    rc5_data = 0;
    sei();
    if( i ){
      PORTB  = (i ^ 0xFF);        // LED output
      PORTC  = (((i >> 6) ^ 0xFF) & 0x1F);
//      itoa( i >> 6 & 0x1F, s, 10);  // Device address
//      itoa((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code
      myCount = 0;
    } else {
      if (myCount < 80000)
      {
        myCount++;
      } else {
        PORTB  = 0xff;
        PORTC  = 0xff;
        myCount = 0;
      }
    }
  }
}

[Lars Lochmann (Gast)]

Die itao() Funktion braucht bissl Zeit. Ich vermute du möchtest, dass 
die LED's bei einem empfangenen Signal nur kurz leuchten? Deshalb die 
mycount Geschichte am Ende? Wenn die itoa()s faheln hast du natürlich 
viel Zeit übrig. Darum könnte das für dich zu einer "fehlerhaften" 
Anzeige kommen.
Ich würde
        PORTB  = 0xff;
        PORTC  = 0xff;
einfach mal auskommentieren und dann kucken was passiert.

[zett (Gast)]

Nö, dann geht immer noch nichts ;o(
Ich habe auch mal eine kleine Warte Zeit eingefügt (eine Dumme schleife) 
was auch nichts brachte. Also wenn es kein Timing Problem ist was dann?

Das Programm geht ja mit dem itoa. Aber ich kann mir Verhalten einfach 
nicht erklären.

Ich sehe es einfach nicht.

[Lars Lochmann (Gast)]

Es müsste eigentlich funktionieren. Ich habe gerade mal probiert. Wobei 
ich die DDR Regsiter zum ein und ausschalten der LEDs verwendet habe.
Hast du auch dioe richtige File kompalliert bzw. funktioniert da alles 
auch mit der my Count sache.

[zett (Gast)]

Also das ich den richtige File kompiliere ist sicher. Da ich die 
Funktion ja jeder Zeit einschalten in dem ich einen der beiden "itoa" 
befehlen aktiviere.
Ich verstehe es einfach nicht. Aber ich werde weiter testen. Was kann 
ich in dem Zusammenhang noch falsch gemacht haben? Die Geschichte mit 
dem myCount funktioniert auch so wie ich es mir wünsche.

Ich bin mir recht sicher das mein Programm nicht mal in die true 
Bedingung der if Abfrage kommt. was aber eine Abfrage innerhalb der if 
== true Abfrage nicht beeinflussen kann.

Danke nochmals für Deine Tipps.

[zett (Gast)]

So ich habe neue Erkenntnisse dich ich aber nicht verstehe.

Also die itoa Zeilen habe ich auskommentiert. Dafür habe ich aber eine 
dummy Funktion gebaut die nichts sinnvolles oder Zeit intensives macht.

void zett(void)
{
  int mytrash;
  mytrash++;
}

diese Funktion rufe ich an der Stelle wo vorher die itoa standen auf.

Dann geht das ganze auch. Warum weis ich aber immer noch nicht.

[Peter D. (peda)]

zett wrote:

> Also die itoa Zeilen habe ich auskommentiert. Dafür habe ich aber eine
> dummy Funktion gebaut die nichts sinnvolles oder Zeit intensives macht.
>
> Dann geht das ganze auch. Warum weis ich aber immer noch nicht.

Versuch mal:

volatile uint rc5_data;

Der GCC hat die unangenehme Eigenschaft, Zugriffe auf globale Variablen 
wegzuoptimieren.
Der Aufruf einer externen Funktion hindert ihn daran, da diese ja die 
Variable ändern könnte.

Ich falle da auch regelmäßig drauf rein.

In MC-Programmen ist es allerdings gang und gäbe, daß Interrupts globale 
Variablen ändern.
Der Keil C51 optimiert diese daher grundsätzlich nicht weg.
Die Optimierungen des GCC sind jedoch vorrangig auf größere CPUs 
ausgelegt, d.h. Mikrocontroller typische Programmabläufe fallen da etwas 
hinten runter.

Rein formal entspricht das aber dem C-Standard, daher wird sich daran 
auch nichts ändern.
Man würde daher am liebsten sämtliche Variablen als volatile definieren, 
allerdings wird dann die Optimierung ausgeschaltet.

Es hilft also nichts, man muß beim GCC immer ein wachsames Auge haben 
und bei derartigen Effekten darauf prüfen. Auch wenn ulkige Effekte nach 
einem Compilerupdate auftreten, liegt das oft an einer 
volatile-Fallgrube.

Wenn Du etwas Assembler kannst, hilft es auch, sich das Listing 
anzusehen. Dann sieht man schnell, wenn etwas unerwünscht wegoptimiert 
wurde.


Peter


P.S.:
Vielleicht erbarmt sich ja mal ein GCC-Guru und generiert wenigstens ne 
Warnung, wenn "Code possible without effect" auftritt, also ne Schleife 
ne Variable auswertet, die sich aus GCC-Sicht "nie" ändert.

[zett (Gast)]

Das war es. Vielen Dank!

Vor allem aber für die Erklärung warum man da ein volatile einfügen 
sollte. Die Funktion war ja gegeben. Ich konnte mir aber keinen Reim 
darauf machen.

Mit einer Warnung wäre ich vielleicht selbst darauf gekommen.

Schönes Wochenende noch.

[Coder (Gast)]

Hallo,

passend zum Thema habe ich gerade für den RC5 Code einen Beitrag im 
Fernbedienungsportal veröffentlicht:
http://fb-vz.de/rc5-code/
Evt. hilft er euch bei euren Problemen weiter

[Dirk M. (dirkm)]

Hallo,

versuche seit mehreren Stunden den RC5 Code zum laufen zu bekommen..

Leider bisher ohne Erfolg :-(

Das "RC5-Dekoder:" beim Start wird normal gesendet aber es kommen keine 
Codes..

Verwende einen ATTiny2313@16Mhz Quarz und einen TSOP1136.

Musste für den ATTiny etwas bei dem Timer anpassen, denke mal da liegt 
auch irgendwo der fehler :-/

Ware super nett wenn jemand eine Idee hat bzw sich mal den Quellcode 
anschaut :-)

Gruß
Dirk

[Simon K. (simon)]

Sicher, dass deine Fernbedienung RC5 kodiert sendet?

[EDAconsult Udo Kuhn (Gast)]

Hallo Peter Dannegger,

super GCC-Code von Dir, opimieren durch weglassen, sowas kommt gut an. 
Kein C++ Code war so klein wie dieser, von allen die ich bisher 
gesichtet. Habe diesen schon länger in Betrieb aber wusste nichts von 
diesen Forum und Beitrag.

Zu dem Problemen mit den Empfängern, wenn auf den Schaltungen 
Spanungswandler sind, z.B. -5V für Display's oder ähnliches, dann 
braucht der Empfänger eine Entkopplung mit einem Wiedersand in der 
Stromversorgung.

+5v----.--|100ohm|---.-----+5V IRempfänger SFH50X oder andere
       |             |
      ===           ===
      --- 1- 10uF   --- 1-10uF
       |             |
      _|_           _|_

Udo

[sven s. (Gast)]

ein 100nf an alles dran so wie man das auch machen sollte bringts auch.

gruss sven

[Rainer Milenski (Gast)]

Kann jemand bitte mal ein Schaltbild reinsetzen? Ich checke noch nicht 
so 100%ig wie der TSOP1736 angeschlossen wird.
Bin in Elektronik (noch) ein blutiger Anfänger. Vergönnts mir :-)

Gruß, Rainer

[Holger K. (krulli)]

http://www.qslnet.de/member/dg1xpz/elektronik/avr/rc5_empf.html

[Rainer Milenski (Gast)]

Danke!!! :-)

[Torny (Gast)]

Hallo,

kann bitte jemand die .hex Datei für ( ATMega16 @ 4MHz-Intern ) zur 
Verfügung stellen, ich versuche schon seit Stunden, nichts läuft, ich 
bekomme zwar die Meldung
"RC5-Dekoder", aber weiter tut sich gar nichts, ich habe probiert 
einfach die  Signale von TSOP1736 zu empfangen und im Terminal 
auszugeben, das funktioniert, aber wenn ich die gepostete Sourcecode 
kompiliere, dann passiert außer Textausgabe nichts mehr. Als 
Fernbedienung benutze ich Imex IM-1313, die habe ich damals mit "lirc", 
benutz und lirc geht doch nur mit RC5, oder? OK, dann hab ich probiert 
die ganzen Philips Geräte-Codes einzugeben (es ist eine universal 
Fernbedienung), funktioniert auch nicht. Nun bin ich langsam verzweifelt 
und weiß nicht weiter, deswegen bitte ich euch um ein Tipp oder die .hex 
datei damit ich zumindest sehen kann dass es wirklich funktioniert und 
ich was falsch gemacht habe.

Vielen Dank für die Hilfe!

[Jens R. (jeronnimo)]

Hi Torny,

send mir Deine Mail Adresse ([e-mail]), dann kann ich Dir 
meinen C Code für RC5 senden. Ich habe gerade was ähnliches 
programmiert, läuft super. Zwar mit MEGA8 aber die Anpassungen sind ja 
nur marginal.

Gruß Jens

[Mehmet K. (mkmk)]

Servus Peter

Herzlichen Dank für Deinen Beitrag.
Nur als ich keine Befehl-Codes empfangen konnte, die grösser als 63 
waren, stiess ich auf die Zeile

itoa((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code

Meiner Meinung nach müsste es aber

 .... (~i >> 6 & 0x40) ....

lauten.

Soweit ich weiss, wird ja das 2. und nicht das 1. Startbit als 7. 
Command-Bit verwendet.

[Neuling (Gast)]

Hi,

ich versuche gerade den Code auf einen 8051 abzuändern.

Was mir jedoch Schwierigkeiten bereitet:

In der Main.h Datei steht ja folgendes:

#define  xRC5_IN    PIND
#define  xRC5    PD7

Der Pin PD7 ist mir klar,das ist halt einfach ein Portpin,aber was ist 
der PIND - ist das auch ein Portpin?

Wenn ja,für was benötige ich einen zweiten Portpin,oder sieht die 
Schaltung nicht so aus wie auf dieser Seite?

http://www.roboternetz.de/wissen/index.php/RC5-Decoder_f%C3%BCr_ATMega#Schaltplan

[Kai G. (runtimeterror)]

PIND ist der 8-Bit-Port selbst
PD7 ist die Nummer des Pins an dem besagten Port

[Neuling (Gast)]

Hi,

würde das dann bei einem 8051 so aussehen?

P0.7 Nummer des Pins
P0 8bit Port

[Kai G. (runtimeterror)]

ich kenne den 8051 nicht, scheint aber dasselbe auszudrücken.

[Peter D. (peda)]

Neuling wrote:
> Hi,
>
> würde das dann bei einem 8051 so aussehen?
>
> P0.7 Nummer des Pins
> P0 8bit Port

Der AVR-GCC kennt keine SBITs, daher die Schreibweise mit Masken.

Schreib statt PIND, P0 und statt PD7 dann 7 für P0.7


Peter

P.S.:
Man kann dem AVR-GCC SBITs beibringen, aber das habe ich erst später 
gemerkt.

[TobyTetzi (Gast)]

Hallo Peter,

Ich nutze deinen RC5 Code erfolgreich, danke dafür.

Nun habe ich aber mal eine Frage:
Da ich einen eigenen IR Sender habe, also keine handelsübliche
Fernbedienung, würde ich den Code gerne kürzen.
Ich brauche eigentlich nur 6 Bit zur Steuerung meines Projektes.

Kannst Du mir evtl. weiterhelfen, wenn ich den Gerätecode nicht 
übertragen will, und auch nicht auswerten will.
Klar weiß ich, das es dann nicht mehr mit einer "normalen" FB geht.

Mein Problem besteht darin, das ich Daten per IR übertragen will,
diese 6 Bit aber schneller als alle 24 ms kommen müssen.
Da das RC5 Protokol aber 24ms Zeit braucht, ist es zu langsam.

Vielleicht könnte man ja ein Protokoll "bauen", das ein Byte übertragt?!
2 Bit als Startbit
8 Bit Daten Byte
= 10*1,778ms = 17,78ms für ein Byte.
Evtl. kann man die länge der Bits noch kürzen, da eine SFH5110 bei 
6*36kHz
schon für ein eindeutiges Signal reicht, lt.Datenblatt.
So könnte man z.B. statt 32*36kHz nur 16*36kHz für ein Halbbit nehmen.
Spart nochmal die Hälfte an Zeit.

Danke schon mal, für die Hilfe.

Gruß Toby

PS: Interessant wäre dann sogar einen Sender und Empfänger zu bauen.

[Peter D. (peda)]

TobyTetzi wrote:

> Ich brauche eigentlich nur 6 Bit zur Steuerung meines Projektes.

Erzähl doch einfach mal, was Du an dem Code nicht verstehst, um die 
Änderungen selber zu machen.


Peter

[TobyTetzi (Gast)]

Hallo Peter,

grundsätzlich muss ich mich, glaube ich, erst mal mit der
RC5 Systemathik auseinandersetzen. Dann verstehe ich auch deinen Code.

Ich möchte, auch wenn es jetzt etwas Off Topic ist, mal anders beginnen,
um mein Problem zu schildern.

Ich habe ein Rotordisplay in meinem RC-Heli gebaut.
Die Steuerungen der Leds, die in den Blättern verbaut sind, drehen sich 
mit. Ich erfasse die Drehzahl per Hallsensor, und übertrage RC5 Code vom 
nichtdrehenden Teil des Helis zum Rotor, um zwischen verschidenen 
Bildern
umschalten zu können.
Nun möchte ich gerne den Hallsensor im drehenden Teil einsparen, da es 
zu viel Bauaufwand ist.
Getestet habe ich es folgendermaßen:
Hallsensor am festen, nicht drehenden Teil des Helis.
Bei jedem Hallsignal sendet nun eine Steuerung einen IR Puls zu dem 
Rotor.
Die Pulslänge wird im Rotor ausgewertet, und dementsprechend die Bilder 
angezeigt.
Der Beginn des Pulses ist gleichzeitig das Startsignal, also der 
Referenzpunkt der Anzeige. Ersetzt also den Hallsensor am drehenden 
Teil.

Nun ist mir die Sache mit der Pulslänge aber zu störanfällig, so das ich 
dachte, ich könnte den RC5 Code so ändern, das ich damit die Übertragung 
bewältigen kann.
Da der RC5 Code im Original etwa 24ms für eine Übertragung braucht, bei 
2000 U/min eine Umdrehung ca. 30ms benötigt, bekomme ich da schon 
Probleme.

Also muss ich 2 Dinge mit der IR Routine erledigen:
Beim beginn der Übertragung fesstellen, das es das Startsignal ist.
Die Übertragungsgeschwindigkeit erhöhen, bzw. die Datenlänge kürzen.

Vielleicht habe ich ja einen enormen Denkfehler, vielleicht weiß jemand 
eine Intelligentere Lösung des Problems.


So, werde mich nun erstmal mit der RC5 Systemathik beschäftigen.

Gruß Toby

[Bernhard (Gast)]

Hi,

@Peter: die Vorschläge von Dir hab ich übernommen.

Hab den Code jetzt mal auf den 8051 angepasst.
Ich habe versucht möglichst den ganzen Code möglichst 1:1 zu übernehmen 
um Fehler zu vermeiden.
Jedoch komme ich nie in die

if(i)
{

.....

}

Schleife.

Bei den Funktionen cli(); und sei(); war ich mir nicht sicher was die 
eigentlich machen. Ich hab im Forum nach den beiden Funktionen gesucht 
und hab die folgendermaßen ersetzt:

cli();  --> EA = 0;
sei(); --> EA = 1;

Das Prorgamm hab ich angehängt.

Bernhard

[TobyTetzi (Gast)]

Hallo Peter,

ich denke, ich habs nun verstanden. ;-)

Ich habe deine Code mal so geändert, das ich 2 Startbits und 8 Datenbits 
empfangen kann.
Siehe Anhang.

Ebenso habe ich meinen IR Sender umgebaut, damit er dieses Protokoll 
sendet.
Anhang kommt sofort.

Ich bitte allerdings, den ganzen Code Müll zu entschuldigen.

Nun muss ich nur noch sehen, wie und wo ich ein Bit setze, damit ich 
auswerten kann, ob es das Startsignal für meine Anwendung ist.
Ich denke, ich sollte es nach den beiden Startbits machen.

Gruß Toby

[TobyTetzi (Gast)]

So,

hier nun der IR Sender.

Gruß Toby

[Peter D. (peda)]

Bernhard wrote:
> Jedoch komme ich nie in die
>

> if(i)
> {
> 
> .....
> 
> }
>

>
> Schleife.


Kein Wunder.
Erstens kannst Du nie 1µs Interruptrate erreichen, weil der Code schon 
länger dauert.
Zweitens ist das Quatsch mit Soße.
Lies Dir mal diese Zeile durch:

#define RC5TIME   1.778e-3    // 1.778msec

Du mußt also ne Interruptrate haben, die mindestens die Hälfte ist (zum 
abtasten) aber nur so groß, daß die Vergleichswerte in ein Byte passen.
Und dann mußt Du die darunter liegenden Vergleichswerte anpassen, da die 
Rate ja nicht 512 beträgt.
Z.B. ne Interruptrate von 0,18ms paßt gut.

Und nimm den Reloadmodus, sonst mußt Du ne 16Bit Addition zum Reload 
machen oder Du kriegst nen riesen Fehler.
Ein Reload am Ende des Interrupts ist besonders schlecht (maximaler 
Fehler).

> cli();  --> EA = 0;
> sei(); --> EA = 1;

Ja

Peter

[Bernhard (Gast)]

Danke,ich hab die Änderungen in mein Programm übernommen.

Aber irgendwo scheint noch der Wurm drinnen zu sein,denn wie auch vorhin 
geht er mir nicht in die Schleife.
Zuerst hatte ich den TSOP 1838 ohne Zusatzbeschaltung direkt an den µC 
geschalten,dann hab ich den Schaltungsvorschlag aus dem Datenblatt 
übernommen.
(den 100Ohm Widerstand + den 4,7µF Elko(statt dem 4,7µF Elko hab ich 
einen 10µF Elko genommen,ich hoffe das macht das Kraut auch nicht 
Fett?!))


p.s: Ich hab zwei verschiedene Fernbedienungen ausprobiert,die eine 
Fernbedienung funktioniert sicher(ist jeden Tag in Verwendung). Aber ich 
bin mir bei beiden nicht sicher welches Protokoll sie verwenden...
Angenommen ich hätte hier Fernbedienungen die nicht das RC5 Protokoll 
verwenden,würde dann ein Blödsinn im Terminal aufscheinen oder gar 
nichts?

Bernhard

[Bernhard (Gast)]

Entschuldigt,hab das Programm vergessen.


Bernhard

[TobyTetzi (Gast)]

Hallo,

ich habe festgestellt, das bei falschen FB's nicht angezeigt wird.

Das soll wohl daran liegen, das die anderen Codes längere/kürzere Pulse 
und mehr/weniger bits haben.

Es sind dann halt völlig andere Protokolle.

Gruß Toby

[Peter D. (peda)]

Bernhard wrote:

> p.s: Ich hab zwei verschiedene Fernbedienungen ausprobiert,die eine
> Fernbedienung funktioniert sicher(ist jeden Tag in Verwendung). Aber ich
> bin mir bei beiden nicht sicher welches Protokoll sie verwenden...
> Angenommen ich hätte hier Fernbedienungen die nicht das RC5 Protokoll
> verwenden,würde dann ein Blödsinn im Terminal aufscheinen oder gar
> nichts?

Ja das RC5 ist warscheinlich tot, d.h. keine aktuellen Geräte benutzen 
es mehr.
Inzwischen wird ja alles in China hergestellt und die benutzen für 0 und 
1 kurze und lange Impulse (wie Morsecode) und erstmal nen extra langen 
als Startbit.

Eventuell mal ne Universal-FB probieren.

Mein Programm ist so ausgelegt, daß es alles, was nicht RC5 ist, 
verwirft.


Peter

[Bernhard (Gast)]

Ich hab mir jetzt mal eine Univeralfernbedienung geschnappt und ein 
bisschen mit der herumgespielt.
Ich hab die Fernbedienung auf die verschiedenen Philips Gerätecodes 
programmiert und jeweils dazwischen die Funktion ausprobiert - kein 
einziger Gerätecode funktionierte.
Auch ein automatischer Suchlauf der Fernbedienung selber brachte kein 
Ergebnis..

War Philips vielleicht der falsche Ansatz?! Doch laut Google setzten 
einige TV Geräte von Philips das RC5 Protokoll ein.

Habt ihr einen Vorschlag?

Bernhard

[Lorenz .. (lorenz)]

Bei mir tut eine Universalfernbedienung (mit Philips-Gerät 
eingestellt)prima. Habe auch mehrere original Philips-Fernbedienungen 
getestst - tut prima. Egal ob Receiver, TV oder DVD-Codierung.

[technikus (Gast)]

Hi,

teste mal Grundig oder Marantz Codes. Viele von denen funktionieren bei 
mir prima.

technikus

[Matthias (Gast)]

Hallo Zusammen,

ich versuche nun schon seit 2 Tagen meine RC5 Routine zum laufen zu 
bekommen.
Ich verwende einen Tiny44 mit dem internen Takt.
Ich will mir, nur damit ich weiß dass er die RC5 Routine richtig 
durchführt, auf Port PA3 eine LED an- bzw. ausschalten!
PA2 soll der Eingang meines IR- Empfänger sein!

Wäre super wenn mir da jemand weiterhelfen könnte!

Grüße
Matthias

[Matthias (Gast)]

Achso hab ich ganz vergessen!
interner Takt = 8MHz

[Johann L. (gjlayde)]

@Peter:

for(;;)
{
   EA = 0; //entspricht cli(); 
   i = rc5_data;
   rc5_data = 0;
   EA = 1; //entspricht sei(); 
   if(i)
   {

rc5_data = 0 ist doch ein erlaubtes RC5-Kommando (addr=0 (TV), flip=0, 
cmd=0). Hier würde besser 0xffff als Leerwert dienen oder ein anderer 
Wert, dir kein gültiges RC5-Frame darstellt.

[Matthias (Gast)]

wo soll ich da den wert 0xffff reinschreiben?
also auf einem Atmega8 hat das Programm schonmal funktioniert!
nur auf dem Tiny läuft es nicht!

[Johann L. (gjlayde)]

@Matthias: 0xffff wird Deinen Fehler nicht beheben.

Was soll denn das?

    Keycode = ((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code

Das ist gleichbedeutend mit

    Keycode = 10;

[Frank L. (franklink)]

Bernhard wrote:
> Ich hab mir jetzt mal eine Univeralfernbedienung geschnappt und ein
> bisschen mit der herumgespielt.
> Ich hab die Fernbedienung auf die verschiedenen Philips Gerätecodes
> programmiert und jeweils dazwischen die Funktion ausprobiert - kein
> einziger Gerätecode funktionierte.

Ich habe die Routine von Peter schon sehr lange im Einsatz, ich verwende 
pauschal die Codierung 1112 von Phillips. Da ist die Steuerung für AMPs.
Als FB setzte ich eine 8 in 1 vom blauen C ein.

Gruß
Frank

[Matthias (Gast)]

@Georg:

Keycode = ((i & 0x3F) | (~i >> 7 & 0x40), s, 10); // Key Code

bedeutet einfach dass ich mir dn Code der hinter einer Ziffer auf der 
Fernbedienung in der Variable abspeichere.
Aber du hast recht, in dem ......,s,10) könnte der Fehler liegen!

Ich werds am Montag gleich mal testen!
Falls sonst noch jemand Fehler in dem Quelltext findet, bitte melden!

Danke
Gruß
Matthias

[roboter (Gast)]

wie weiss man eigentlich aus der rc5-routine, wann das ir-signal 
anfängt?

ich sehe keinen interrupt, sondern nur eine timer-überlaufroutine.

normal müsste doch über einen interupt das signal gegeben werden "die 
rc5-signale kommen jetzt an" und dann die auswertung.

mfg

[Peter D. (peda)]

roboter wrote:
> wie weiss man eigentlich aus der rc5-routine, wann das ir-signal
> anfängt?
>
> ich sehe keinen interrupt, sondern nur eine timer-überlaufroutine.

Das Geheimnis liegt hier:

if( (rc5_bit ^ xRC5_IN) & 1<<xRC5 ){    // change detect
    rc5_bit = ~rc5_bit;        // 0x00 -> 0xFF -> 0x00

Damit wird erkannt, ob sich der Pegel seit dem letzten Interrupt 
geändert hat.
Und dann wird mitgezählt, wann er sich wieder ändert.
Ist diese Zeitdauer im gewünschten Bereich, wird angenommen, daß es ein 
RC5-Signal ist und die einzelnen Bits eingeschoben.


Peter

[Felix (Gast)]

Hallo,

erstmal Danke für den Code.

Will ihn anpassen damit er mit 16 Mhz funktioniert.

Hab da aber ein paar fragen.

In deiner Erklärung schreibst du von 4 Mhz als Frequenz.

XTAL ist aber auf 11.0592e6 gesetzt.

Ansonsten würde ich

#define PULSE_MIN (uint8_t)(XTAL / 512 * RC5TIME * 0.4 +0.5)
#define PULSE_1_2 (uint8_t)(XTAL / 512 * RC5TIME * 0.8 +0.5)
#define PULSE_MAX (uint8_t)(XTAL / 512 * RC5TIME * 1.2 +0.5)

in

#define PULSE_MIN (uint8_t)(F_CPU / 2048 * RC5TIME * 0.4 +0.5)
#define PULSE_1_2 (uint8_t)(F_CPU / 2048 * RC5TIME * 0.8 +0.5)
#define PULSE_MAX (uint8_t)(F_CPU / 2048 * RC5TIME * 1.2 +0.5)

ändern. F_CPU ist 16e6.

Beim Timer hab ich den Prescaler auf 1024 gestellt, des müsste passen.

Wäre super wenn du mir kurz ne Rückmeldung geben kannst ob des so passt.

Danke!

[roboter (Gast)]

warum testest ud deinen code nicht?

ist doch einfacher wie das fragen.

bei mir läuft er mit 16mhz und auch mit 8mhz.

[Felix (Gast)]

Ja, hab ich inzwischen auch.

Und es hat leider nicht funktioniert.
Nach allem was ich bis jetzt herausgefunden habe, denke ich, das es an 
der Funktion zur erkennung des RC5-Codes liegt.

Mein Program hat einen LernModus wo es RC5-Codes erkennen und 
abspeichern soll.

Wenn ich statt der normalen rc5 Funktion einfach eine leere Aufrufe 
bleibt das Programm in der Endlosschleife. Sonst springt es nach ca 0,5 
sec. raus. Es muss also etwas "erkannt" haben. Habe auch schon den PIN 
mal gewechselt um irgendwelche störeinflüsse auszuschließen.

Im Debugger läuft das Programm auch einwandfrei durch. Allerdings läuft 
der Debugger auch mit 4Mhz, mein Atmega8 aber mit 16.

Habe den Code angehängt. F_CPU wird vom Compiler auf 16000000 gesetzt.


Wäre echt super wenn sich das jemand anschauen und mir helfen könnte.

Danke.

[Felix (Gast)]

Niemand? :-(

Bin für jeden Tipp dankbar

[Hive (Gast)]

Hat es schonmal jemand mit 1MHz Takt bzw. 128 Zyklen probiert oder 
könnte das zu knapp werden?

[Hive (Gast)]

geht auch auf einem tiny25 mit 1MHz, allerdings wohl schon knapp.
der interrupt besteht aus 76 befehlen, ohne signal braucht er aber nur 
40 zyklen.
man muss den timerinterrupt auf irgendwas im bereich 100µs einstellen, 
und dann RC5CYCLES zurückrechnen.

#define RC5CYCLES  162 // tatsächlicher wert ist langsamer, messen.
#define PULSE_MIN  (uint8_t)(XTAL / RC5CYCLES  RC5TIME  0.4 + 0.5)
#define PULSE_1_2  (uint8_t)(XTAL / RC5CYCLES  RC5TIME  0.8 + 0.5)
#define PULSE_MAX  (uint8_t)(XTAL / RC5CYCLES  RC5TIME  1.2 + 0.5)

TCCR0B=1<<CS01; // 1mhz durch 8 = 125khz bzw. 8µs
TIMSK=1<<OCIE0A;

ISR(TIM0_COMPA_vect)
OCR0A=TCNT0+16; // 16 * 8 takte = 128 takte

sicherheitshalber das volatile einbauen.

danke für das programm.

[Hive (Gast)]

es ist natürlich

.. * RC5TIME * ..

[Hive (Gast)]

Hier noch Hinweise:

Das Programm muss zunächst das Toggle-Bit prüfen, da die Codes meistens 
mehrmals gesendet werden (will man meistens nicht, manchmal ja 
(Lautstärke)).

Die Bits stehen in der Variable i, und werden durch schieben und 
maskieren zu einem echten Byte gemacht.
Der Befehlscode steht schon an der richtigen Stelle und wird nur 
maskiert, bekommt aber noch das zweite Startbit als 7. Bit dazu (RC5X):

(i & 0x3F) | ((~i >> 6) & 0x40)

(Fehler im Original, siehe 
Beitrag "Re: Fernbedien RC5 Empfänger")

[Baugatz (Gast)]

Hallo Peter,

eine kurze Frage zu Deinem Code:

die Zeilen:

 if( rc5_time < PULSE_MIN )      // to short
      tmp = 0;

sollen zu kurze Impulse abfangen, müsste dann aber nicht auch noch 
rc5_time auf null gesetzt werden?

Danke im Voraus?

[steve (Gast)]

hallo liebe IR freunde :)

ich habe den Code ebenfalls benutzt, erstmal ein großes lob an peter 
dafür!
leider habe ich ein kleines problem, ich muss schon wirklich massiv 
lange auf die bedienung drücken bis er dann doch endlich mal im terminal 
was ausspuckt (ich lasse mir alles über einen virtuellen comport 
rausschicken. ich benutze einen usb pic von microchip dafür und hab die 
routinen also etwas umgeschrieben aber das wesentliche ist das von 
peter).
leider hatte ich den kondensator, den sie im datenblatt für störungen 
empfehlen nicht da. kann es sein dass es daran liegt??? das was im 
terminal ankommt ist nämlich an sich schon richtig, nur leider kommt es 
wirklich viel zu selten dafür dass ich so lange auf der taste bin. 
mehrmaliges drücken bringt auch keinen erfolg. den 100ohm widerstand vor 
vcc hab ich mal reingebaut...
vielen dank!

[bottle (Gast)]

@steveläßtsichfurchtbarschlechtlesendeintext.

[Steffen O. (derelektroniker)]

Hallo,
ich habe den Thread jetzt nicht ganz gelesen, daher weiß ich auch nicht, 
ob es irgendwo schon geschrieben wurde: Ich hab vor einiger Zeit bei 
Conrad mal einen TSOP gekauft, weiß aber nicht genau, welchen. Die 
unterscheiden sich ja nur in der Frequenz. Was beeeinflußt diese 
Frequenz, und muss ich die jeweilige Frequenz von meinem Empfänger 
wissen?
Ansonsten, die Beschaltung ist doch von GND des Empfängers zu VS einen 
100nF Kondensator, und in die VS- Leitung einen 100 Ohm Widerstand, 
oder?

Vielen Dank schon einmal im Voraus.
Gruß, Steffen

[Malte _. (malte)]

Probiers es einfach mal mit der 38Khz Version. Ist die Frequenz höher 
oder niedriger wirst du auch einen Empfang haben, nur schlechter. Wenn 
ich das Datenblatt richtig lese läge die Empfindlichkeit bei 36kHz immer 
noch bei 70%  der genau passenden 38Khz.

[Steffen O. (derelektroniker)]

Ach ja, was ich vergessen hatte: Benötige ich einen Baudratenquarz, oder 
kann ich den µC mit 4Mhz takten?
Und: Kann ich als Baudrateneinstellung auch 9600 Baud verwenden?

Vielen Dank schon einmal im Voraus.
Gruß, Steffen

[Steffen O. (derelektroniker)]

Noch was: Ist das Programm 100% kompatibel zum ATmega8? Oder muss ich da 
noch was an den UART- EInstellungen ändern?
Und, kann es zu komplikationen mit der UART- lib von Peter Fleury 
kommen?


Vielen Dank schon einmal im Voraus.
Gruß, Steffen

[Steffen O. (derelektroniker)]

Hallo,
ich habe es nun auch geschafft, der Empfänger funktioniert einwandfrei - 
Danke Peter!!!
Ich verwende den Code mit TSOP 1736 an PC5, bei mit 4Mhz getaktetem 
Mega8, und mit 9600 Baud. Klappt ohne Probleme!
Jetzt muss ich nur noch den Code ein wenig umschreiben, dass eben am PC 
nur eine 1, oder 2, usw. ankommt, also nicht immer 101, oder so, da ich 
es am PC mit einem selbstgeschriebenem Programm auswerten will.

Gruß, Steffen

[Valerian S. (val)]

Hallo zusammen!

Bei mir läuft die ISR von Peter einwandfrei!

Und die Decodierung reiner "1" Bitfolgen kann ich nachvollziehen. Doch 
wie wird eine "1" gefolgt von einer "0" decodiert, das es ja keinen 
Flankenwechsel zwischen den beiden Bits gibt!!! Folglich wird rc5_time 
nicht zurückgesetzt und es müsste tmp=0 weden, weil für

rc5_time>RCTIME_1_2

die

if((rc5_bit^xRC5_IN)&1<<xRC5) - Bedingung nicht erfüllt wird.

Es ist doch richtig, dass nach der Mittelflanke von "1"

rc5_bit=xRC5_IN=xRC5=1 sind bis dann die nächste Flanke (Mitte von "0") 
kommt oder?

Für eine Erklärung wäre ich sehr dankbar!

Gruss

[Richard B. (rbrose)]

Hallo zusammen,

der Code funktioniert bei mir wunderbar. Danke!
Habe aber eine Frage. Und zwar will ich NUR erneut gedrückte Tasten 
rausfiltern. Das heißt also wen ich eine Taste gedrückt halte ... soll 
es aber nur 1 mal empfangen. Und dann wieder bei nächsten drücken.

Das halten einer Taste soll unterdrückt werden.

Wie mach ich das? Wie prüfe ich das Togglebit?

[Richard B. (rbrose)]

Ich habe das so gemacht:

    toggle_tmp = i >>11 & 1;
    if(toggle_tmp == old_toggleBit) 
    {
      i = 200;
    }
    
    old_toggleBit= i >>11 & 1;

Aber so wird jede zweite gedrückte Taste unterdrückt :-(

[Christian R. (supachris)]

Richard B. wrote:
> Hallo zusammen,
>
> der Code funktioniert bei mir wunderbar. Danke!
> Habe aber eine Frage. Und zwar will ich NUR erneut gedrückte Tasten
> rausfiltern. Das heißt also wen ich eine Taste gedrückt halte ... soll
> es aber nur 1 mal empfangen. Und dann wieder bei nächsten drücken.
>
> Das halten einer Taste soll unterdrückt werden.
>
> Wie mach ich das? Wie prüfe ich das Togglebit?

Toggle-Bit merken und Befehl nur weiter verarbeiten, wenn es sich 
geändert hat? Das änder sich ja auch, wenn eine andere Taste gedrückt 
wird, nicht nur beim Neu-Drücken der gleichen Taste. Hier kannst du in 
der main.c gucken wie ich das auf dem MSP430 gemacht hab: 
Beitrag "Fernbedien RC5 Empfänger mit MSP430" wollte das nämlich für 
DVBViewer Bedienung auch so haben.

[Richard B. (rbrose)]

Hallo Christian,

vielen Dank für den Hinweis.
Habe das jetzt auch so wie bei dir gemacht ... aber leider wir ein 
weiter Tastendruck ausgegeben wenn ich die Taste halte. Und nicht nur 1 
mal :-(
Sieht jemand vielleicht den Fehler?

int main(void)
{  
  uint16_t i;
  uint8_t x;

  volatile uint8_t Command;
  volatile uint8_t Address;
  volatile uint8_t Toggle;


  uint8_t LastCommand;
   uint8_t LastAddress;
   uint8_t LastToggle;


    // uart_init(UART_BAUD_SELECT(19200, F_CPU));
  rf12_init();          // ein paar Register setzen (z.B. CLK auf 10MHz)
  rf12_setfreq(RF12FREQ(433.92));  // Sende/Empfangsfrequenz auf 433,92MHz einstellen
  rf12_setbandwidth(4, 0, 0);    // 200kHz Bandbreite, -6dB Verstärkung, DRSSI threshold: -79dBm 
  rf12_setbaud(19200);      // 19200 baud
  rf12_setpower(0, 5);      // 1mW Ausgangangsleistung, 120kHz Frequenzshift

  
  DDRD = 0xFF;   // Output 
  PORTD = 0xFF; //am Anfang alles aus

  DDRB |= ( 1 << DDB0) | ( 1 << DDB1 ) | ( 1 << DDB2 ); //Anzeige wählen Output

  PORTB |= (1 << PB0); 
  PORTB &= ~(1 << PB1);  
  PORTB &= ~(1 << PB2);   


    ///Timer for IRC5
   TCCR0B = (1<<CS02);      //divide by 256    
  TIMSK |= (1<<TOIE0);      //enable timer interrupt

  sei();

  while(1) 
  {    

    cli();    
      i = rc5_data;      // read two bytes from interrupt !
    rc5_data = 0;    
      sei();    
      
    if(i==0)
      i=200;      

    Command = (uint8_t)i & 0x3F;      //Dekodieren
    Address = (uint8_t)((i >> 6) & 0x1F);
    Toggle = (uint8_t)((i >> 11) & 0x01);

    if((LastCommand == Command) && (LastAddress == Address))
    {
      if(LastToggle == Toggle)  //Prüfung auf Änderung des Toggle-Bits
      {
        i=200;
      }
    }


    for(x=1;x<10;x++)
    {
      if( get_key_press(i, x) )
      {                      
        if(liednummerCount < 4)
        {
          liednummer =  liednummer*10+x;
          liednummerCount++;        
        }                
      }
    }  

    if( get_key_press(i, 0) )
    {      
      if(liednummerCount < 4 && liednummerCount > 1)
      {
        liednummer =  liednummer*10+0;
        liednummerCount++;
      }                  
    }

    if( get_key_press(i, 13) )
    {            
      liednummer =0;
      liednummerCount = 1;      
    }
    if( get_key_press(i, 46) )
    {      
      convertIntToSendString();            
    }

    

    if(liednummer == 0)
    {
      currentSeg1 = pgm_read_byte(&c_led[10]);   
      currentSeg2 = pgm_read_byte(&c_led[10]);
      currentSeg3 = pgm_read_byte(&c_led[10]);   
    }
    else if(liednummer > 0 && liednummer < 10)
    {
      currentSeg1 = pgm_read_byte(&c_led[liednummer]);   
      currentSeg2 = pgm_read_byte(&c_led[10]);
      currentSeg3 = pgm_read_byte(&c_led[10]);   
    }
    else if(liednummer > 9 && liednummer < 100)
    {
      uint16_t showDigits10[2];
      getDigits(liednummer,showDigits10,2);

      currentSeg1 = pgm_read_byte(&c_led[showDigits10[1]]);   
      currentSeg2 = pgm_read_byte(&c_led[showDigits10[0]]);
      currentSeg3 = pgm_read_byte(&c_led[10]);   
    }
    else if(liednummer > 99 && liednummer < 1000)
    {
      uint16_t showDigits100[3];
      getDigits(liednummer,showDigits100,3);

      currentSeg1 = pgm_read_byte(&c_led[showDigits100[2]]);   
      currentSeg2 = pgm_read_byte(&c_led[showDigits100[1]]);
      currentSeg3 = pgm_read_byte(&c_led[showDigits100[0]]);   
    }  
    
    //Letzten Tastendruck speichern

    LastCommand = Command;
    LastAddress = Address;
    LastToggle = Toggle;
              
  }
}

[Christian R. (supachris)]

Warum setzt du das i=200 bei gleichem Toggle Bit? Und deine main 
Schleife arbeitet doch trotzdem immer alles durch, egal, ob da eine neue 
Taste gedrückt wurde oder nicht?
Du musst halt gucken, ob LastToggle ungleich Toggle ist, und erst dann 
dein restlichen Zeugs abarbeiten.
Und wieso i=200 bei i=0? Gibts keine Fernbedienung mit GeräteCode 0 und 
Befehl 0? Was ist mit Taste "0" beim TV?