RC5 Decoder von P. Danegger

[Masl (Gast)]

Hallo.
Ich hätte da gerne mal ein Problem. Nämlich das folgende:
Ich habe gerade versucht mit der Software von Peter Danegger (in einem 
anderen post hier irgendwo ^^) wenn ein Mega8 irgendein Signal empfängt 
eine LED zu toggeln.
Blöd nur, dass er anscheinend mit den Signalen, die er bekommt nichts 
anfangen kann. (Definitiv sind hier RC5 Fernbedienungen unter denen, die 
ich hier grad probiere).
Der uC läuft mit 4MHz internem Takt. Ich würde gerne einen 4MHz Quarz 
anschließen, hab aber keine Ahnung, auf welchen von den geschätzen 20 
Werten der Fusebits ich selbige setzen muss (Slow, Middle, Fast, ...)

Im Anhang der für die aktuelle GCC version angepasste code.

Danke Schonmal! Gruß M.

[Tobi (Gast)]

Kannst ja mal zum Test die LED Toggeln, wenn der Empfangspin was 
empfängt, also ein Test, ob die Schaltung ok ist.
Hast du einen richtigen Fernbedienungsempfänger am Pin (z.B. TSOP1736), 
richtig geschaltet?

[Masl (Gast)]

Hey Tobi,

Also die Beschaltung sieht folgendermaßen aus:
GND an GND
V+ an +5V
die Datenleitung an PD2 und über 10kOhm an +5V

Ich hab jetzt mal ne LED mit der kathode an die Datenleitung vom TSOP 
geschaltet und man sieht wie das teil flackert, wenn ich ne Taste auf 
einer Fernbedienung drücke.

Oder meinst du den Port-Toggle befehl an einer anderen Stelle einfügen, 
wenn ja an welcher?

[Masl (Gast)]

Ich hab jetzt auch mal testweise

if(!(PIND & (1<<PD3)))
    {
      PORTC ^= (1<<PC5);
        }

in der Hauptschleife eingefügt und die LED an PC5 flackert dann 
entsprechend, wenn auf den Fernbedieungen rumdrücke.

[Tobi (Gast)]

Aja, dann funktioniert die hardware ja schonmal.
Die RC5 software von P-Dannegger sollte ja auch funktionieren, vllt hat 
er einen anderen Takt benutzt, nicht 4 MHz, oder von deinen 
Fernbedienungen ist keine RC5. Ich hab 3 zuhause, und keine davon ist 
RC5.
Ich geh jetzt schlafen. Gute Nacht

[Masl (Gast)]

Morgen allerseits,

was mir grad auffällt ist, dass ich einen TSOP1738 und nich den 36 drin 
habe, könnt's daran liegen?

Gruß

[gast (Gast)]

am tsop liegts nicht. wenn du einen 1738 anstatt einen 1736 nimmst 
klappt das trotzdem -  nur mit geringerer reichweite. hast du schon die 
timer pulsezeiten angepasst auf deine taktfrequenz??

[gast (Gast)]

da du ja "TCNT0 = -2", "PULSE_MIN (uchar)(XTAL / 512  RC5TIME  0.4 + 
0.5)" etc. nicht an deine taktfrequenz von 4mhz angepasst hast. scheinst 
du den code nur kopiert zu haben. versuch ihn doch einfach mal zu 
vertsehen. dann wirst du feststellen, dass peter die ganze sache für 
eine anderen taktfrequenz geschrieben hat. ich glaube er hatte 16mhz. 
das heisst, dass du den timer/prescaler neu berechnen und die "512" 
anpassen musst.

[joachim (Gast)]

Hallo!

Das mit der 512 kann schon bleiben; lediglich der XTAL sollte an den 
Quartz angepaßt werden. Ich habe diese Routine schon mit diversen 
Quartz-Frequenzen ausprobiert und es klappte immer. Es gibt lediglich 
Probleme, wenn die Fernbedienung nicht die passenden Sequenzen sendet; 
das ist bei Universalfernbedienungen halt auszuprobieren, bei welchen 
Einstellungen das funktioniert. Der TSOP selbst ist da relativ 
entspannt, was die Frequenz angeht; 36 - 40 khz decken die Teile schon 
ab (mit leichten Einbußen in der Empfindlichkeit). Probier mal ein 
bißchen rum

[gast1 (Gast)]

>Das mit der 512 kann schon bleiben; lediglich der XTAL sollte an den
>Quartz angepaßt werden. Ich habe diese Routine schon mit diversen
>Quartz-Frequenzen ausprobiert und es klappte immer. Es gibt lediglich
>Probleme, wenn die Fernbedienung nicht die passenden Sequenzen sendet;
>das ist bei Universalfernbedienungen halt auszuprobieren, bei welchen
>Einstellungen das funktioniert. Der TSOP selbst ist da relativ
>entspannt, was die Frequenz angeht; 36 - 40 khz decken die Teile schon
>ab (mit leichten Einbußen in der Empfindlichkeit). Probier mal ein
>bißchen rum

Dann hast du immer Glück gehabt das sich der Wert nicht groß geändert 
hat. Er muss auf jeden Fall neu berechnet werden. Schon alleine weil 
TCNT0 bei 4MHz und 256 Prescaler auf -5 angepasst werden muss um die 
32µs einzuhalten. Versucht doch bitter erst einmal den Kode zu 
verstehen.

[Masl (Gast)]

Hallo ihr,
also ich werde mir demnächst mal ein oszi beschaffen und mir angucken, 
was der TSOP da so produziert, so langsam fange ich an an den 
Fernbedienungen zu zweifeln.

Ja gast, so ganz verstanden hab ich den Code noch nicht, hier allerdings 
mal ein zitat aus der beiligenden index.htm:
"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."

Gruß

[joachim (Gast)]

Naja; bei Frequenzen von 3,8xxx bis 8 Mhz funktioniert die Routine; alle 
Werte der Fernbedienung werden bei mirsauber erkannt. Poste doch mal 
Deine main.c und Deine Schaltung

[Masl (Gast)]

Den Code findest du im 1. Post im Anhang, die Schaltung habe ich im 3. 
Post beschrieben

Habe jetzt einen externen Quarz mit 4MHz angeschlossen mit folgenden 
FUSE settings: CKSEL=1111 und SUT=11, falls das irgendwie weiterhilft

[Masl (Gast)]

So, Oszi ist da, sogar gleich ein Rolls Royce unter den Oszis, hab ich 
von dem Vater meiner Freundin ausgeliehen bekommen.
Nach ein bisschen rumtüfteln an der Signalerfassung klappt das sogar 
ganz prima ... Ich brauch auch so ein Teil :D

Also hier mal ein paar Bilder die ich von dem Signal gemacht hab:
Das gesamte Signal: http://marcelk.info/ir/tek0006.png
Der Afnang des SIgnals: http://marcelk.info/ir/tek0005.png
Wenn eine Taste gedrückt ist, wird dieses SIgnal wiederhohlt: 
http://marcelk.info/ir/tek0004.png

Das mit den Bildern vom Oszi hat leider nicht so geklappt, falls ihr 
euch die anderen in dem Verzeichnis noch anguckt. Ich hab da mit den 
Cursorn noch die Länge der Pulse vermessen, aber da wo diese 
Informationen normalerweise stehen, ist leider der "Datei Speichern" 
Dialog vom Oszi ^^

Naja, ich hoffe ihr schlachtet mich jetzt nicht, aber das ganze sieht 
nach dem JVC Protokoll aus, doch kein RC5 ... argh
Sorry, ich habe wirklich fest daran geglaubt, das wäre RC5, weil ich mal 
einen IR-Empfänger für den PC gebaut habe (Serieller Port) und ich 
dachte die Software dafür kann nur RC5, die ist nämlich mit allen FBs 
die ich hatte klar gekommen. Die Software konnte aber anscheinend noch 
ein paar mehr Protokolle!

Aber vielen Dank und ein dickes Sorry für alle die versucht haben mir zu 
helfen, super Community hier ;)

Gruß Masl

[Rolf I. (for_ro)]

Hallo Masl,
der aufgezeichnete Code ist sicher kein JVC, da der nur 16-bit lang ist.
Ich würde auf extended-NEC tippen. Also 16-bit Adresse, 8-bit Befehl und 
8-bit negierter Befehl. Demnach wäre das deine Sequenz:
00001000 10110111 11010010 00101101
Schau mal hier für die Beschreibung:
http://www.sbprojects.com/knowledge/ir/nec.htm

Gruß

Rolf

[Masl (Gast)]

Oh stimmt, auf die gesamt länge hab ich garnich geachtet, dämlich von 
mir ^^

Danke dir, mal schauen ob ich demnächst mal zeit finde dafür nen Code zu 
schreiben.

Danke dir

[Bernhard M. (boregard)]

Masl schrieb:
> Oh stimmt, auf die gesamt länge hab ich garnich geachtet, dämlich von
> mir ^^
>
> Danke dir, mal schauen ob ich demnächst mal zeit finde dafür nen Code zu
> schreiben.
>

Ich habe den Code von Peter umgeschrieben (d.h. das Prinzip 
beibehalten), so daß der NEC code dekodiert wird. Allerdings nicht der 
extended (mit 16 bit Adresse), sondern nur der Standard mit 8 bit 
Adresse (d.h. das 2. Adressbyte ist das negierte 1. Adressbyte); das 
kann man aber leicht ändern.

Ich kann ja den Code heute abend mal posten, wenn Interesse besteht....

Gruß,
Boregard

[Masl (Gast)]

Hi Bernhard,

ja, das wäre super.
Ich hab zwar gestern auch schon bisschen rumgetüftelt und einen halbwegs 
funktionierenden code gebaut aber deiner ist bestimmt eleganter

Gruß

[Masl (Gast)]

Halli hallo,

hier mal der Code den ich gebastelt hab.
Ich komme aber partout nicht drauf, warum mit das ding auf dem LCD (is 
ein 40x4 Zeichen LCD) nur 16 bit anzeigt.

Auf dem oszi sehe ich schön wie bei jeder 1, also bei nem langen low 
puls PD6 toggelt, aber irgendwie scheint da noch der wurm bzw käfer drin 
zu sein ;)

Vielleicht sieht von euch einer spontan, woran es liegt.
Gruß

[Masl (Gast)]

Ok, hab jetzt einen Code der funktioniert.
Vielleicht kann mir trotzdem einer erklären warum der im vorigen Post 
nicht funktioniert hat, hab den Fehler nämlich nicht gefunden, sondern 
schreibe jetzt die 16 Bit Adresse und die jeweils 8 Bit Commands in 
einzelne Register.

Der Code ist noch nicht wirklich fertig, will alles noch mit 
Präprozessor-Intelligenz versehen um den code leicht auf die aktuelle 
Umgebung anpassbar zu machen.

Wer verbesserungsvorschläge hat - immer her damit ;)

Gruß Marcel

[Masl (Gast)]

Anhang vergessen ...

[Bernhard M. (boregard)]

So,

nach Problemen mit Rechner und USB-Stick...

Jetzt der versprochene NEC Decoder von mir.
Aufgerufen wir sie im 125usec interrupt, dies findet sich im 
IRQS_PER_SECOND wieder.

Der empfangene 32 bit code besteht:
nec_data & 0xff000000 : invertiertes Datenbyte
nec_data & 0x00ff0000 : Datenbyte
nec_data & 0x0000ff00 : invertiertes (oder erweitertes) Adressbyte
nec_data & 0x000000ff : Adressbyte

Man kann noch eine erweiterte Konsistenzprüfung machen, über Datenbyte 
oder auch über Adressbyte (wenn man keine erweiterten Adressen zulässt).

(Der repeat ist auskommentiert, man sollte da nicht tmp nehmen, sondern 
einen gespeicherten gültigen Wert...).

Gruß,
Boregard

/*************************************************************************
 * (C) Bernhard Michler 2009
 * Based on ideas and code of Peter Danneggers rc5 decoder
 *
 * File          :      ir_nec.c
 * Created       :      August 2009
 * Author(s)     :      Bernhard Michler
 *
 *
 * DESCRIPTION:
 * Routines for IR receivers, decoding the ancient the widely spread 
 * Japanese NEC code.
 *
 ************************************************************************/
#include <avr/io.h>
#include <avr/interrupt.h>
#include "config.h"
#include "ir-nec.h"

volatile uint32_t       nec_data;       // store result


void irnec_init (void)
{
  nec_data = 0;
}


uint32_t get_nec_data (void)
{
    uint32_t tmp;
    uint8_t  intStat = SREG;
    cli();
    tmp = nec_data;
    nec_data = 0;
    SREG = intStat;
    return (tmp);
}


/************************************************************************/
/*                                                                      */
/*                      NEC Remote Receiver                             */
/*                                                                      */
/*              Author: Bernhard Michler                                */
/*                                                                      */
/************************************************************************/
// NEC / Japanese...
// 13.500ms     - start
//  2.250ms     - "1"
//  1.125ms     - "0"
// 90.000ms     - key repeat
#define NECP_MIN       (uint8_t)(IRQS_PER_SECOND * 0.875e-3)
#define NECP_ZERO      (uint8_t)(IRQS_PER_SECOND * 1.750e-3)
#define NECP_ONE       (uint8_t)(IRQS_PER_SECOND * 3.000e-3)
#define NECP_REPEAT    (uint8_t)(IRQS_PER_SECOND * 12.00e-3)
#define NECP_MAX       (uint8_t)(IRQS_PER_SECOND * 15.00e-3)


void irnec_int (void)
{
    static uint8_t  irrc_bit;                   // bit value
    static uint8_t  irrc_time;                  // count bit time
    static uint32_t irrc_tmp;                   // shift bits in
    static int8_t   bit_cnt;                    // count bits
    uint32_t        tmp     = irrc_tmp;         // for faster access
    int8_t          tmp_cnt = bit_cnt;

    if (++irrc_time > NECP_MAX)
    {
        irrc_time = 0;
        tmp_cnt = 0;
    }

    // signal change ??
    if ((irrc_bit ^ xIRRC_IN) & 1<<xIRRC )
    {
        irrc_bit = ~irrc_bit;                   // 0x00 -> 0xFF -> 0x00
  
        if ((irrc_bit & 1<<xIRRC) == 0)
        {
            // it was a change 0 -> 1, so check
            // pulse length now:
            if ((irrc_time < NECP_MIN   ) ||   // too short, error
                (irrc_time > NECP_REPEAT))     // start pulse
            {
                tmp_cnt = 0;
            }
            else if (irrc_time > NECP_ONE)
            {
                // repeat pulse
//                nec_data = tmp;
            }
            else
            {
                // bit received
                tmp_cnt++;

                tmp >>= 1;

                if (irrc_time > NECP_ZERO)
                    tmp |= 0x80000000;

                if (tmp_cnt == 32)
                {
                    nec_data = tmp;
                    tmp_cnt = 0;
                }
            }
            irrc_time = 0;
        }
    }
    bit_cnt  = tmp_cnt;
    irrc_tmp = tmp;
}

[Bernhard M. (boregard)]

Bevor die ersten Beschwerden kommen, daß etwas fehlt...

Hier mein Testprogramm für Mega 8 mit 2*16 Display, auf dieses Display 
wird der empfangene Code ausgegeben, und zwar in die obere Zeile NEC, in 
die untere RC5 (mit Peter Code decodiert).



Gruß,
Boregard

[Max (Gast)]

Hallo Bernhard!

Vorweg: vielen Dank für deine "Erweiterung" um den NEC-Code.

Allerdings krieg ichs nicht hin, das Teil mit einer bestimmten 
Fernbedienung zum Laufen zu bringen :-(
Mit meiner Yamaha-FB klappt alles bestens. Mit der hier allerdings 
nicht: http://www.ltt-versand.de/product_info.php/info/p36217.html

Ich dann mit dem LA von einem Kumpel mal die Zeiten gemessen:

      A     B   C D   E
¯¯\_______/¯¯¯¯\_/¯\_/¯¯\
  |    start   | 0 |  1 |

smarites: (µs)
A: 9075 .. 9130
B: 4420 .. 4490
C: 485  .. 550
D: 480  .. 550
E: 1615 .. 1645

yamaha: (µs)
A: 9040
B: 4370
C: 655
D: 460
E: 1580

Ich verstehe allerdings anhand dieser Zeiten nicht mal, warum die 
yamaha-FB funktioniert. Die haben irgendwie nichts mit den Zeiten in den 
defines zu tun.

An deinem Code hab ich nur die Ausgabe angepasst und als printf über die 
UART geschrieben. Hier kommt bei der "smaries"-FB meisten nur Fehler 
oder sinnlose Sequenzen an.

Hilfe :-)

Grüße,
Max

[Frank M. (ukw) (Moderator)]

Max schrieb:

> Mit meiner Yamaha-FB klappt alles bestens. Mit der hier allerdings
> nicht: http://www.ltt-versand.de/product_info.php/info/p36217.html

Das Ding macht auch das NEC-Protokoll.

> smarites: (µs)
> A: 9075 .. 9130
> B: 4420 .. 4490
> C: 485  .. 550
> D: 480  .. 550
> E: 1615 .. 1645
>
> yamaha: (µs)
> A: 9040
> B: 4370
> C: 655
> D: 460
> E: 1580
> [/pre]

Das korrekte Timing beim NEC-Protokoll ist:

A = 9000µs
B = 4500µs
C = 560µs
D = 560µs
E = 1690µs

Da ist die Smarties-Fernbedienung sogar näher dran als die Yamaha. 
IR-Fernbedienungen haben vom Timing her oft bis zu 40% Abweichungen vom 
Idealwert, siehe auch

http://www.mikrocontroller.net/articles/IRMP

Dort findest Du auch einen IR-Decoder, der beide Fernbedienungen (Yamaha 
als auch die Smarties-FB) durch Berücksichtigung gewisser Toleranzen 
(40% beim NEC-Protokoll) ohne Probleme "versteht".

Gruß,

Frank

[Max (Gast)]

Frank M. schrieb:
Hallo Frank,

danke für deine Antwort!
Um Missverständnissen vorzubeugen: ich weiß, dass das NEC-Code ist und 
dass es im Thread eigentlich um RC5 geht, aber ich hab mich an der 
NEV-Variante von Bernhard Michler versucht.

> Dort findest Du auch einen IR-Decoder, der beide Fernbedienungen (Yamaha
> als auch die Smarties-FB) durch Berücksichtigung gewisser Toleranzen
> (40% beim NEC-Protokoll) ohne Probleme "versteht".
Ich hab mir deinen IRMP auch schon angesehen, bin aber nicht richtig 
warm damit geworden, weil dieses riesige Stück Software für mich 
Overkill ist.
Ich will auch nicht verschiedene Codes oder Timing-Varianten eines Codes 
erkennen, sondern nur diese eine bunte FB :-)
Darum hab ichs zuerst mit diesem Dekoder versucht und ihn ja eigentlich 
auch zum Funktionieren gebracht. Nur nicht mit der richtigen FB :-(

Wenn ich hier wirklich nicht zum Ziel komme, kommt der IRMP zum Einsatz.
Gut zu wissen, dass die Smarties-FB damit funktioniert!

Nochmal danke,
Grüße,
Max