Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jens C. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

erstmal höchstes Lob für dieses Projekt an Frank M. und seine Helfer!

Ich teste derzeit ein wenig mit dem IRMP und mir stellt sich folgende 
Frage:

Durch das IRMP_FLAG_REPETITION kann ich auswerten, ob eine Taste kurz 
oder lange gedrückt wurde. Aber wie erfahre ich wann sie losgelassen 
wird/wurde?

> Beispiel:
>
>    if (irmp_data.flags & IRMP_FLAG_REPETITION)
>    {
>      finger_blau (irmp_data.command);
>    }
>    else
>    {
>      einzeln (irmp_data.command);
>    }

> Dies kann zum Beispiel dafür genutzt werden, um die Tasten 0-9 zu
> "entprellen", indem man Kommandos mit gesetztem Bit IRMP_FLAG_REPETITION
> ignoriert. Bei dem Drücken auf die Tasten VOLUME+ oder VOLUME- kann die
> wiederholte Auswertung ein und desselben Kommandos aber durchaus
> gewünscht sein - zum Beispiel, um LEDs zu faden.

Wenn ich mit meiner FB im NEC Protokoll die "Plus" oder "Minus" Taste 
länger gedrückt halte, bekomme ich zwar bei der zweiten Auswertung das 
Repetition Flag gesetzt, aber weiter bekomme ich keine Auswertungen, 
d.h.ich bekomme nicht mit, wann die Taste losgelassen wurde :-)

Oder habe ich da einen falschen Denkansatz...

Gruß Jens

von Di P. (drpepper) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
naja, wenn das signal nicht mehr kommt, wurde die taste losgelassen. Die 
FBs senden ja keine extra-sequenz, wenn man eine taste loslässt.
Sie senden nur solange die taste gedrückt ist immer wieder in festen 
zeitabständen eine bestimmte bitfolge, die IRMP immer wieder aufs neue 
interpretiert.

von Jens C. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ Di Pi

Guten Morgen,

die Taste wurde nicht losgelassen, die Sequenzen werden noch empfangen 
(mit Oszi beobachtet) aber irmp_get_data(...) liefert mir nach dem 
IRMP_FLAG_REPETITION gesetzt wird FALSE zurück.

Also, das/mein Problem muss woanders liegen

Gruß Jens

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,

Jens C. schrieb:

> die Taste wurde nicht losgelassen, die Sequenzen werden noch empfangen
> (mit Oszi beobachtet) aber irmp_get_data(...) liefert mir nach dem
> IRMP_FLAG_REPETITION gesetzt wird FALSE zurück.

Ich habe das mal gerade emuliert mit dem IRMP-Executable und 
IR-Data/nec-repetition.txt. Da gibt es tatsächlich ein Problem mit den 
Wiederholungen von Repetition-Frames. Diese werden zwar erkannt, aber 
bis auf den ersten Repetition-Frame werden alle weitere verworfen.

Ich schaue gleich mal nach dem Grund und melde mich dann nochmal.

Gruß,

Frank

P.S.
Ich hatte Dein Schreiben auch erstmal so verstanden wie Di Pi...

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Das Problem mit den Wiederholungen von NEC-Repetition-Frames konnte ich 
lösen. Daher gibt es eine neue Version zum Download:

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

Änderungen:
  - Bugfix beim Erkennen von mehrfachen NEC-Repetition-Frames
  - Konfiguration in irmpconfig.h ausgelagert, siehe Doku im
    IRMP-Artikel
  - Einführung einer Programmversion in README.txt: Version 1.0

von Jens C. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

herzlichen Dank für´s Update/BugFix.
Jetzt funktioniert´s problemlos...

Schönen Tag noch
Gruß Jens

von Simon K. (simon) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Simon K. schrieb:
>> Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen
>> worden. Die Binaries und der Code für den PC könnte man doch in ein
>> Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.
>
> Es gibt keinen "Code für den PC" und auch keinen "AVR-spezifischen
> Code", der Source ist für beide derselbe. Das einzige, was hier
> PC-spezifisch ist, sind die beiden Executables irmp.exe bzw. irsnd.exe.

Ach so. Aber die Source Files kann man doch von den Executables 
separieren.

> Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in
> vielen Threads herum, lässt seinen Mecker los und verschwindet dann
> wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst
> nehmen.

Was lässt dich das annehmen? Soll ich mich dafür entschuldigen, dass ich 
nicht den ganzen Tag im Forum bin und alle Threads lese und beantworte?
Außerdem: Wenn man schon ein Projekt ins Forum stellt, dann sollte man 
sich auch der Kritik annehmen können. Ansonsten könntest du deinen Kram 
nämlich auch für dich behalten, wenn du auf sowas allergisch reagierst.
Ansonsten finde ich die Bemerkung ziemlich unangebracht und macht auf 
mich einen ziemlich eingebildeten Eindruck.

von ... .. (docean) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
#include "irmp.c" 

gefunden in main.c im Codevison Teil.

Warum das ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
... ... schrieb:
>
> #include "irmp.c"
> 
>
> gefunden in main.c im Codevison Teil.
>
> Warum das ?

Ich kenne CV nicht, das hat Klaus Leidinger so angepasst, vermutlich um 
die Sources alle ins main zu integrieren, damit man sie dann alle durch 
einmaliges Compilieren des main-Sources mitzuübersetzen kann. Ob es eine 
andere Möglichkeit gibt (Erstellen eines Makefiles etc), um die einzeln 
zu übersetzenden Module zusammenzulinken, entzieht sich meiner Kenntnis.

Wenn Du es besser weisst, wäre ich für Verbesserungsvorschläge dankbar.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Frank M. schrieb:
>> Simon K. schrieb:
>>> Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen
>>> worden. Die Binaries und der Code für den PC könnte man doch in ein
>>> Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.
>>
>> Es gibt keinen "Code für den PC" und auch keinen "AVR-spezifischen
>> Code", der Source ist für beide derselbe. Das einzige, was hier
>> PC-spezifisch ist, sind die beiden Executables irmp.exe bzw. irsnd.exe.
>
> Ach so. Aber die Source Files kann man doch von den Executables
> separieren.

Schauen wir mal in die Liste der Dateien im SVN:

IR-Data/
README.txt
irmp.aps
irmp.c
irmp.exe
irmp.h
irmpconfig.h
irsnd.aps
irsnd.c
irsnd.exe
irsnd.h
irsndmain.c
main.c

Es sind also gerade mal 10 Dateien (und ein Ordner) im SVN-Repository, 
die übrigens im dazugehörenden Artikel 
http://www.mikrocontroller.net/articles/IRMP ausführlichst dokumentiert 
sind. Gestern waren es übrigens sogar noch lediglich 9 Dateien.

Was ist daran "lieblos in ein Verzeichnis geworfen"? Du hast vermutlich 
nur die Ignore-List unter 
http://www.mikrocontroller.net/svnbrowser/irmp/ gesehen und hast daraus 
dann vorschnell geschlossen, dass da "Code für den PC" extra drin ist. 
Die Dateien der Ignore-List sind ja gar nicht im SVN enthalten - ganz im 
Gegenteil: sie sind ausgeschlossen. Das meinte ich mit "oberflächlich 
lesen".

Und die beiden EXE-Dateien sind mit voller Absicht im Hauptverzeichnis, 
um auf die dazugehörenden Scan-Dateien unter IR-Data einfach zugreifen 
zu können - wie es auch im IRMP-Artikel dokumentiert ist. Lägen sie in 
einem weiteren Unterverzeichnis, dann wäre der Zugriff auf den Ordner 
IR-Data ein wenig komplizierter und für den Anwender unverständlicher - 
Stichwort: "../IR-Data".

>> Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in
>> vielen Threads herum, lässt seinen Mecker los und verschwindet dann
>> wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst
>> nehmen.
>
> Was lässt dich das annehmen?

Weil es mir schon mal sauer aufgestoßen ist, nämlich im 
WordClock-Thread:

http://www.mikrocontroller.net/topic/156661#1482557

Zitat:

| Nehmt es mir nicht übel, aber im Moment kommt mir der Thread ein wenig
| "Amateurhaft" vor. Nicht, dass ich es spontan besser könnte, aber solche
| "Dann sammeln wir mal, was drauf kommt"-Projekte enden nicht selten im
| Desaster.

Mittlerweile wurden 320 Platinen der "amateuerhaften" 
WordClock-Schaltung sammelbestellt und auch verteilt! Desweiteren sind 
180 dazugehörende Frontplatten produziert worden. Die "amateurhafte" 
Schaltung funktioniert nicht nur reibungslos, macht Farbe mittels 
HUE-Fading, sondern sie ist auch für Anfänger absolut nachbausicher.

Auf Deine oberlehrerhaften Töne bzgl. der Behandlung der ISP will ich 
erst gar nicht eingehen. Merkst Du eigentlich gar nicht mehr, wie Du die 
Leute von oben herab behandelst?

> Soll ich mich dafür entschuldigen, dass ich
> nicht den ganzen Tag im Forum bin und alle Threads lese und beantworte?

Nein, mich stört das 
Einmal-Drüberfliegen-und-dann-Senf-dazugeben-Gehabe. Erinnert mich an 
das Markieren-Gehabe von Katzen.

> Außerdem: Wenn man schon ein Projekt ins Forum stellt, dann sollte man
> sich auch der Kritik annehmen können.

Du nennst das "Kritik". Ich nicht.

> Ansonsten könntest du deinen Kram
> nämlich auch für dich behalten, wenn du auf sowas allergisch reagierst.

Wenn Du Dir diesen Thread (oder auch den WordClock-Thread) mal 
genauestens durchlesen würdest, wirst Du feststellen, dass ich auf 
angebrachte Kritik immer eingegangen bin. Deine Kritik ist aber 
einfach nur von oben herablassend, deshalb schreibst Du ja jetzt hier 
auch wieder mal "deinen Kram". Diese Formulierung spricht Bände.

> Ansonsten finde ich die Bemerkung ziemlich unangebracht und macht auf
> mich einen ziemlich eingebildeten Eindruck.

Glashaus, Steine.

Gruß,

Frank

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>>> #include "irmp.c"
>> >
>> gefunden in main.c im Codevison Teil.
>>
>> Warum das ?
>
> Ich kenne CV nicht, das hat Klaus Leidinger so angepasst, vermutlich um
> die Sources alle ins main zu integrieren, damit man sie dann alle durch
> einmaliges Compilieren des main-Sources mitzuübersetzen kann. Ob es eine

Ja, genau das ist der Grund.
Alle die sich mit CV auskennen, wissen natürlich das das auch im Setup 
eingestellt werden kann... und können es problemlos ändern. So brauche 
ich das Projektfile nicht dazupacken.

Viele Grüße,
Klaus

von Simon K. (simon) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Es sind also gerade mal 10 Dateien (und ein Ordner) im SVN-Repository,

Du bist echt nicht kritikfähig. Beruhig dich, lass es halt so, aber 
unterlasse solche dämlichen Bemerkungen, dass ich nicht ernst zu nehmen 
sei.
EDIT: Der einzige der hier Leute von oben herab behandelt bist du, wenn 
überhaupt.

> Was ist daran "lieblos in ein Verzeichnis geworfen"? Du hast vermutlich
> nur die Ignore-List unter
> http://www.mikrocontroller.net/svnbrowser/irmp/ gesehen und hast daraus
> dann vorschnell geschlossen, dass da "Code für den PC" extra drin ist.
> Die Dateien der Ignore-List sind ja gar nicht im SVN enthalten - ganz im
> Gegenteil: sie sind ausgeschlossen. Das meinte ich mit "oberflächlich
> lesen".

Nö habe ich nicht.

> Und die beiden EXE-Dateien sind mit voller Absicht im Hauptverzeichnis,
> um auf die dazugehörenden Scan-Dateien unter IR-Data einfach zugreifen
> zu können - wie es auch im IRMP-Artikel dokumentiert ist. Lägen sie in
> einem weiteren Unterverzeichnis, dann wäre der Zugriff auf den Ordner
> IR-Data ein wenig komplizierter und für den Anwender unverständlicher -
> Stichwort: "../IR-Data".

Ist doch wunderbar, wie gesagt, dann lass es halt so. Es ist ja dein 
Projekt.

>>> Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in
>>> vielen Threads herum, lässt seinen Mecker los und verschwindet dann
>>> wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst
>>> nehmen.
>>
>> Was lässt dich das annehmen?
>
> Weil es mir schon mal sauer aufgestoßen ist, nämlich im
> WordClock-Thread:
>
> http://www.mikrocontroller.net/topic/156661#1482557
>
> Zitat:
>
> | Nehmt es mir nicht übel, aber im Moment kommt mir der Thread ein wenig
> | "Amateurhaft" vor. Nicht, dass ich es spontan besser könnte, aber solche
> | "Dann sammeln wir mal, was drauf kommt"-Projekte enden nicht selten im
> | Desaster.

Ganz toll, da kann selbst ich mich nicht mehr dran erinnern.

> Mittlerweile wurden 320 Platinen der "amateuerhaften"
> WordClock-Schaltung sammelbestellt und auch verteilt! Desweiteren sind
> 180 dazugehörende Frontplatten produziert worden. Die "amateurhafte"
> Schaltung funktioniert nicht nur reibungslos, macht Farbe mittels
> HUE-Fading, sondern sie ist auch für Anfänger absolut nachbausicher.

Schön, habe ich mich halt geirrt. Irren ist menschlich. Zu dem Zeitpunkt 
wo ich das gepostet hat, war das auch (von mir) so noch nicht abzusehen.
Oder willst du mir jetzt vorhalten, dass ich mich geirrt habe? Ich habe 
nämlich kein Problem damit.

Außerdem: Wo denn sonst noch? Liest du alle Threads in denen ich poste?

> Auf Deine oberlehrerhaften Töne bzgl. der Behandlung der ISP will ich
> erst gar nicht eingehen. Merkst Du eigentlich gar nicht mehr, wie Du die
> Leute von oben herab behandelst?

Haha, ist klar! Kritikfähigkeit, wo bist du? Oberlehrerhaft? Ich denke 
wir missverstehen uns.

>> Soll ich mich dafür entschuldigen, dass ich
>> nicht den ganzen Tag im Forum bin und alle Threads lese und beantworte?
>
> Nein, mich stört das
> Einmal-Drüberfliegen-und-dann-Senf-dazugeben-Gehabe. Erinnert mich an
> das Markieren-Gehabe von Katzen.

Und mich stört das: Du urteilst über Sachen die du nicht weißt. Ich habe 
ein paar Wochen lang den Thread verfolgt, bis es mir zu viele Posts 
wurden pro Tag.

>> Ansonsten finde ich die Bemerkung ziemlich unangebracht und macht auf
>> mich einen ziemlich eingebildeten Eindruck.
>
> Glashaus, Steine.

Ja, oder so ähnlich.
Der schlauere gibt auch nach. In dem Sinne.

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
Och mensch Frank,
füttere solche Trolle doch nicht auch noch.
Die werden noch übermütiger, wohlgenährter und am ende vielleicht auch 
noch geschlechtsreif.

                            _________________________
                   /|  /|  |                          |
                   ||__||  |       Please don't       |
                  /   O O\__           feed           |
                 /          \       the trolls        |
                /      \     \                        |
               /   _    \     \ ----------------------
              /    |\____\     \     ||
             /     | | | |\____/     ||
            /       \|_|_|/   |    __||
               \            |____| ||
          /   |   | /|        |      --|
          |   |   |//         |____  --|
   * _    |  |_|_|_|          |     \-/
*-- _--\ _ \     //           |
  /  _     \\ _ //   |        /
*  /   \_ /- | -     |       |
  *      _ c_c_c_C/ \C_c_c_c____________

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

jetzt muss ich wegen der Logging Funtkion einmal nachfragen:
                if (s_ctr > c_endBits)
                {                                                       // if stop condition (200 sequenced ones) meets, output on uart
                    uint16_t i;

                    for (i = 0; i < c_startcycles; ++i)
                    {
                        irmp_uart_putc ('0');                                   // the ignored starting zeros
                    }

Also werden immer 2 '0' ausgegeben? Denn c_startcycles = 2 ist fix 
defined!?
#define c_startcycles                     2                         // min count of zeros before start of logging

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hugo Portisch schrieb:
> jetzt muss ich wegen der Logging Funtkion einmal nachfragen:
> Also werden immer 2 '0' ausgegeben? Denn c_startcycles = 2 ist fix
> defined!?

Ja, momentan sind es zwei. Früher waren es mal 4, aber dann lief der 
Scanner bei sehr kurzen Impulsen erst gar nicht los. Daher hab ich das 
auf 2 geändert. Davon solltest Du aber nicht ausgehen, dass das so 
bleibt. Vielmehr solltest Du für das Logging über USB einfach die Zahl 
c_startcycles übertragen und nicht das c_startcycles x Nullen. Der PC 
kann dann aus der Zahl 2 (oder 4 oder wasweiss ich) einfach zwei 0en 
machen.

Gruß,

Frank

von Frank L. (florenzen)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das Problem mit den Wiederholungen von NEC-Repetition-Frames konnte ich
> lösen.
[...]

Auch von mir ein Dankeschön, auch wenn's erst spät kommt. Ich bin zur 
Zeit "etwas" überlastet und erst heute zum ausprobieren gekommen.

Gruß
f

von Florian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

das Projekt ist echt supper Großes lob!
Eine frage hätte ich allerdings.
Ist es theroretisch auch möglich die IR-Signale einer
Bang & Olufsen FB zu erkennen?
Problem könnte sein das die Trägerfrequenz bei 455Khz liegt,
und ich nix brauchbares zum Protokoll gefunden habe.
(Kann mann da evtl die eingangsschaltung anpassen oder
geht das mit dem aufbau)

Gruß

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
Die Trägerfrequenz ist ja egal, solange du den passenden Empfänger dafür 
hast. Die Frage ist halt, wie die Daten darauf kodiert sind.

von Frank L. (florenzen)


Bewertung
0 lesenswert
nicht lesenswert
Morgen oder übermorgen werde ich eine B&O FB aufzeichnen und die Daten 
an Frank schicken.

Gruß
f

von Florian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Da bin ich mal gespannt...
Hatte noch vergessen zu erwähnen das ich im Forum
ein Projekt von Rene
(http://www.gutwenger.com/ -> Projekt Beo2pc) gefunden habe
Da stört halt das Beolink "Auge",welches er als
empfänger nutzt, für 70,- =)

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Frank Lorenzen schrieb:
> Morgen oder übermorgen werde ich eine B&O FB aufzeichnen und die Daten
> an Frank schicken.

Hi Frank,

welchen Empfänger zum demodulieren benutzt Du für die B&O Signale? Die 
IR sendet ja mit 455KHz. Hast Du den von B&O oder einen TSOP7000 
aufgetrieben? (wo?)

Danke für eine Info,
Klaus

von Frank L. (florenzen)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe einen TSOP7000 den ich vor einiger Zeit mal bei Farnell 
bestellt hatte. Wie ich gerade sehe ist der aber bei Farnell nicht mehr 
erhältlich weil abgekündigt.

TME hat ihn noch im Programm aber z.Z. 0 Stück auf Lager, vielleicht 
fragst du bei denen mal an ob sie erwarten nochmal welche zu bekommen?
Bei TME nicht von den Preisen verwirren lassen! Die muß man erst von 
Zloty auf Euro umstellen ;-)

HtH.

Danke Klaus. Ohne deine Nachfrage wüsste ich nicht das der TSOP7000 
abgekündigt ist

Gruß
f

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt hier http://www.vishay.com/ir-receiver-modules/agc-list ein 
Hilfstool zur Auswahl, aber ich bin etwas verunsichert. Ich würde gerne 
möglichst viele Protokolle empfangen können, daher sollte es ein 
AGC1-Receiver werden. Auf der anderen Seite ist dieser am 
empfindlichsten ggü. Störungen - stellt dies für IRMP ein Problem dar?

Der Empfänger läuft als IR-Tastatur von ione und ich habe (noch) keine 
Ahnung welches Protokoll das ist. Ein TSOP17xx kommt nicht in Frage, da 
ich nur 3,3V zur Verfügung habe.

von Abdul K. (ehydra) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
455KHz ist eine gängige Frequenz für ZF-Verstärker im HF-Bereich. Im 
Prinzip kann man also alles aus diesem Bereich übernehmen. Eine 
Fotodiode mit TCA440 beispielsweise.

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich weiß leider nicht einmal die Frequenz. Ich habe beim Hersteller aber 
eben wegen des Protokolls angefragt - mal sehen was die antworten. 
Vielleicht ist es ja irgendein bereits unterstütztes Standardprotokoll.

von Frank L. (florenzen)


Bewertung
0 lesenswert
nicht lesenswert
Zum Thema B&O Fernbedienungen habe ich gestern von einem Bekannten recht 
interessante Informationen bekommen:

Das B&O Fernbedienungs-System wurde wohl bisher von Loewe hergestellt. 
Da Loewe aber mittlerweile zu großen Teilen von Sharp aufgekauft wurde 
und Sharp an der Produktion von Baugruppen für B&O wohl wenig Interesse 
zeigt wird es in Zukunft wohl ein neues FB-System von B&O geben.

Man munkelt die Fernbedienung soll der Harmony sehr ähnlich sehen ;-)
Ob dieses System dann aber noch 455kHz IR unterstützt?

Gruß
f

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank Lorenzen hat mir die B&O-Daten geschickt, ein Scan hat aber erst 
mit einer Interrupt-Frequenz von 15kHz funktioniert, da die Pulsdauern 
extrem kurz sind und die Scan-Routine erst bei einer Mindestlänge 
startet.

Interessantes Protokoll, was da benutzt wird. Die Pulsdauern sind immer 
gleich, im Durchschnitt lediglich 210 usec, das spart Strom. Die Pausen 
bestimmen die Wertigkeit der Bits - wie bei den meisten anderen 
Protokollen auch.

Der Aufbau ist:

4 Startbits + 18 Datenbits.

1. Startbit: Pause  3000 usec, entspricht einer 0
2. Startbit: Pause  3000 usec, entspricht einer 0
3. Startbit: Pause 15000 usec, das eigentliche Startbit
4. Startbit: Pause  3000 usec, entspricht einer 0

Die Werte der 18 Datenbits selbst werden über drei statt zwei 
verschiedenen Pausenzeiten gebildet, das macht das ganze so besonders:

Pause 3000 usec: 0
Pause 9000 usec: 1
Pause 6000 usec: Wiederholung des letzten Bits

Mit dieser Regel werden aus den Tasten "0" bis "9" die numerischen Werte 
0 bis 9, das passt also ganz gut. Eine Adresse scheint die FB nicht 
auszusenden, die ersten drei Datenbits sind immer 0, so passen die 18 
Bits glücklicherweise gut in die 16 Code-Bits von IRMP.

War nicht ganz einfach, das Ding zu knacken - wegen der dritten 
Pausenzeit von 6000 usec, die ich erstmal verstehen musste. Morgen baue 
ich den Algorithmus in den IRMP ein, vervollständige die Protokoll-Doku 
im IRMP-Artikel und stelle eine neue Version zum Download zur Verfügung.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Version 1.1 von IRMP ist verfügbar:

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

Änderungen:
  - Neues Protokoll: BANG_OLUFSEN (B&O)

@Frank Lorentzen: Würde mich über Feedback freuen, ob es klappt. Bitte 
einmal für 10kHz und einmal für 15kHz testen, da ich selbst nur mit der 
Scan-Datei testen konnte. Danke Dir noch einmal für die Scan-Datei, 
diese ist nun auch im Verzeichnis IR-Data abgelegt, einmal als 10kHz- 
und einmal als 15kHz-Verion.

Gruß,

Frank

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ Frank M.
Würde es sich bzgl. deiner Änderung von eben 
http://www.mikrocontroller.net/wikisoftware/index.php?title=IRMP&diff=46141&oldid=prev 
nicht anbieten ein enum zu verwenden, oder gibt es bestimmte Gründe 
warum du das nicht machst?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> Würde es sich bzgl. deiner Änderung von eben [...] nicht anbieten ein enum
> zu verwenden, oder gibt es bestimmte Gründe warum du das nicht machst?

Natürlich kann ich auch ein enum nehmen. So habe ich halt die Zahlen 
konkret vor mir und muss nicht immer mit dem Finger abzählen, was denn 
nun die IRMP-Ausgabe "protocol = 14" konkret bedeutet ;-)

Okay, ich stelle das beim nächsten Update um.

Gruß,

Frank

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> was denn
> nun die IRMP-Ausgabe "protocol = 14" konkret bedeutet

Du kannst ja auch dort den (?) enum nehmen... Also z.B.
"protocol = IRMP_BANG_OLUFSEN_PROTOCOL"

Siehe: 
http://openbook.galileocomputing.de/c_von_a_bis_z/015_c_strukturen_010.htm

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:

> Du kannst ja auch dort den (?) enum nehmen... Also z.B.
> "protocol = IRMP_BANG_OLUFSEN_PROTOCOL"

Ja, das ist mir schon klar, dass ich das kann. Mir ging es darum, dass 
jeder - egal ob er den Wert auf einem LCD, auf dem UART oder auf einer 
numerischen 7-Segment-Anzeige ausgibt, sofort sehen kann, was denn die 
"14" bedeutet.

> Siehe:
> http://openbook.galileocomputing.de/c_von_a_bis_z/015_c_strukturen_010.htm

Mir sind enums nach mittlerweile 25 Jahren C-Programmierng wohlbekant, 
aber danke für den schönen Link ;-)

Gruß,

Frank

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nachteilig ist allerdings der erhöhte Speicherbedarf, da enums 16bit 
haben (können?)...

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Mir ging es darum, dass
> jeder - egal ob er den Wert auf einem LCD, auf dem UART oder auf einer
> numerischen 7-Segment-Anzeige ausgibt, sofort sehen kann, was denn die
> "14" bedeutet.

Verstehe. Damit hast du natürlich recht. Das war nur ein Vorschlag und 
deswegen stellte ich oben die Frage nach den Gründen...

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> Nachteilig ist allerdings der erhöhte Speicherbedarf, da enums 16bit
> haben (können?)...

enums werden immer auf den kleinst-möglichen Typ abgebildet, der möglich 
ist.

Beispiel A:
enum zahl { NU_LL, EINS, ZWEI, DREI, VIER};

uint8_t
funktion (enum zahl xx)
{
  xx >>= 4;
  return xx;
}

Dann steht in der lss-Datei:
00000046 <funktion>:
uint8_t funktion (enum zahl xx)
{
  xx >>= 4;
  return xx;
}
  46:  82 95         swap  r24
  48:  8f 70         andi  r24, 0x0F  ; 15
  4a:  08 95         ret

Die lss-Datei ist dann identisch beim Code von:
uint8_t funktion (uint8_t xx)
{
  xx >>= 4;
  return xx;
}

Die Variable xx ist also in beiden Fällen 8 Bit breit.

Beispiel B:
enum zahl { NU_LL = -2, EINS, ZWEI, DREI, VIER};

uint8_t
funktion (enum zahl xx)
{
  xx >>= 4;
  return xx;
}

Jetzt braucht die Beispiel-Funktion wesentlich mehr Speicherplatz:
00000046 <funktion>:
uint8_t
funktion (enum zahl xx)
{
  xx >>= 4;
  return xx;
}
  46:  85 95         asr  r24
  48:  85 95         asr  r24
  4a:  85 95         asr  r24
  4c:  85 95         asr  r24
  4e:  08 95         ret

EDIT:

Hier wird 4x mittels asr geschoben, weil nun int8_t statt uint8_t 
verwendet wird.

Beispiel C:
enum zahl { NU_LL = 300, EINS, ZWEI, DREI, VIER};

uint8_t
funktion (enum zahl xx)
{
  46:  24 e0         ldi  r18, 0x04  ; 4
  48:  96 95         lsr  r25
  4a:  87 95         ror  r24
  4c:  2a 95         dec  r18
  4e:  e1 f7         brne  .-8        ; 0x48 <funktion+0x2>
  xx >>= 4;
  return xx;
}
  50:  08 95         ret

Hier wird dann tatsächlich eine 16-Bit-Operation verwendet, weil der 
Wertebereich von 0-255 überschritten wurde.

Ergo: Wenn man den Wertebereich von 0 bis 255 nicht überschreitet, ist 
alles in Butter. Trotzdem lasse ich das so, wie es ist - aus obigen 
Gründen.

Gruß,

Frank

von Frank L. (florenzen)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
[...]
> Änderungen:
>   - Neues Protokoll: BANG_OLUFSEN (B&O)
>
> @Frank Lorentzen: Würde mich über Feedback freuen, ob es klappt. Bitte
> einmal für 10kHz und einmal für 15kHz testen, da ich selbst nur mit der
> Scan-Datei testen konnte.

Das ging aber schnell! Ich teste selbstverständlich - leider nicht mehr 
heute sondern erst morgen, mein Testaufbau hat aus unerfindlichen 
Gründen den Geist aufgegeben.

Ich habe noch eine zweite B&O Fernbedienung gefunden, sieht von Design 
auch wie eine Beolink 1000 aus hat aber weniger und anders beschriftete 
Tasten ("Video Terminal Bang & Olufsen" steht drauf). Die Teste ich 
morgen gleich mal mit.


Ich bin außerdem noch auf ein Problem gestossen: SIRCS scheint nur für 
die ersten ein, zwei Frames zu funktionieren obschon die FB dauerhaft 
ein Signal aussendet. Ich habe aber noch nicht geschaut woran das liegen 
könnte.


Gruß,

f

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank Lorenzen schrieb:

> Ich bin außerdem noch auf ein Problem gestossen: SIRCS scheint nur für
> die ersten ein, zwei Frames zu funktionieren obschon die FB dauerhaft
> ein Signal aussendet. Ich habe aber noch nicht geschaut woran das liegen
> könnte.

Die kannst Du ja dann bei der Gelegenheit mal direkt scannen und mir die 
Datei zuschicken.

Gruß,

Frank

von Frank L. (florenzen)


Bewertung
0 lesenswert
nicht lesenswert
[...]
>> @Frank Lorentzen: Würde mich über Feedback freuen, ob es klappt. Bitte
>> einmal für 10kHz und einmal für 15kHz testen, da ich selbst nur mit der
>> Scan-Datei testen konnte.
[...]

Funktioniert wunderbar sowohl mit 10 als auch mit 15kHz.
Danke dir.

Sorry daß ich so Wortkarg bin, aber ich bin heute wirklich hundemüde.
Gruß,
f

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank Lorenzen schrieb:

> Funktioniert wunderbar sowohl mit 10 als auch mit 15kHz.

Freut mich.

> Sorry daß ich so Wortkarg bin, aber ich bin heute wirklich hundemüde.

Danke für den Test - auch wenn ich Dir nicht den Schlaf rauben wollte 
;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Analog zum IRMP ist nun das Bang&Olufsen-Protokoll auch im IRSND 
integriert.

Download:

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

Viel Spaß,

Frank

von J. K. (kum)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

habe einige Probleme IRMP+IRSND für einen IR-Tranciever gemeinsam zum 
Laufen zu bewegen.

AVR-GCC, Atmega8, lfuse0xe2, hfuse0xd9, Kompilleren klappt, Flashen 
auch, irsndmain.c wird nicht mitkompilliert.

Mangels MAX232 und LCD wollte ich einfach eine Led toggeln, damit ich 
erkennen kann, ob definierter Tastendruck erkannt wird. Das habe ich 
ohne Erfolg mit TSOP7000 (B&O) und TSOP1738 (Apple) probiert. Output 
TSOP hängt an Pin9. Der TSOP1738 könnte auch ein TSOP1736 sein. Kam aus 
der Bastelkiste und ich kann mich nicht mehr genau erinnern, welchen ich 
damals bestellt hatte.

In der Steckbrett-Schaltung ist zusätzlich ein BC548 mit Fotodiode oder 
einfache Led an Pin17 untergebracht. Ein irmp_send_data lässt die 
normale Led zumindest wie ein IR-Code blinken, aber mit einer Fotodiode 
reagiert kein getestetes Gerät.

Jetzt ein anderer Test: Direktes Durchschleifen des IR-Signals auf eine 
normale Led, die dann in der Theorie genauso blinken sollte wie der 
empfangene Code. TSOP7000 keine Reaktion. Beim  TSOP1738 reagiert die 
Led ab und zu mal auf einen Tastendruck - die Led blinkt aber nur sehr 
kurz auf und das sieht keinesfalls wie ein IR-Code-Blinken aus. Auf eine 
RC5-FB reagiert er gar nicht.

Entweder liegt ein einem fehlerhaften zusammenfügen der Sourcen von IRMP 
und IRSND und der Anpassungen an den Atmega8 oder an der Schaltung? Oder 
beides ;-)

Habe den Quell-Code mal angehängt. Wäre für einen Hinweis dankbar.

Gruß, Kum

von J. K. (kum)


Bewertung
0 lesenswert
nicht lesenswert
Hallo noch mal,

also ich vermute ein Timing-Problem. Beim Empfang funktioniert es schon 
nicht richtig und ab und zu denkt irmp es hätte was dekodiert und 
schickt dieses verkrüppelte Paket an irsnd und daher blinkt es mal kurz 
auf. Lasse ich ein definiertes Paket direkt von irsnd abarbeiten, dann 
erscheint es wie IR-Code-Blinken, aber wahrscheinlich zu langsam bzw. 
irgendwie fehlerhaft. Komme einfach nicht dahinter...

Viele Grüße, Kum

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
J. Kum schrieb:

> AVR-GCC, Atmega8, lfuse0xe2, hfuse0xd9

Habe die Werte gerade mal in den Fuse-Calculator

   http://www.engbedded.com/fusecalc/

eingegeben.

2 MHz ist ein bisschen zu wenig, oder?

Gruß,

Frank

von Frank L. (florenzen)


Bewertung
0 lesenswert
nicht lesenswert
Nicht nur das. Zu allem Übel ist im Makefile 8MHz angegeben.
Das kann nicht funktionieren.
Fuse doch bitte mal auf h=0xD9 l=0xE4

Gruß,
f

von J. K. (kum)


Bewertung
0 lesenswert
nicht lesenswert
Lieber Frank, Lieber Frank,

wie peinlich. Den Kalkulator von Mark (<-- auch ein ganz, ganz netter 
Kerl) habe ich benutzt und war mir da auch ganz sicher. Oje, oje, ist 
das peinlich ... vielen, vielen Dank für den Hinweis. Neue Fuses: die 
Schaltung und das noch viel tollere Stück Software rennt wie der Teufel!

Dann kann ich jetzt weiter damit rumspielen ... ich freu mich.

Viele Grüße, Kum

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank L. und B&O Anwender,

Frank Lorenzen schrieb:
> Ich habe einen TSOP7000 den ich vor einiger Zeit mal bei Farnell
> bestellt hatte. Wie ich gerade sehe ist der aber bei Farnell nicht mehr
> erhältlich weil abgekündigt.
>
> TME hat ihn noch im Programm aber z.Z. 0 Stück auf Lager, vielleicht
> ...
> Danke Klaus. Ohne deine Nachfrage wüsste ich nicht das der TSOP7000
> abgekündigt ist
>

Ich hab den TSOP7000 gerade von Darisus http://www.darisus.de erhalten, 
dort gibt es auch den TSOP1156 und der Shop ist auch sonst bestens 
sortiert (nicht nur) im Bereich IR-Empfänger.

Ich hoffe das war keine unzulässige Werbung...

Viele Grüße,
Klaus

von siegmar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klaus Leidinger schrieb:
> Ich hab den TSOP7000 gerade von Darisus http://www.darisus.de erhalten,
> dort gibt es auch den TSOP1156 und der Shop ist auch sonst bestens
> sortiert (nicht nur) im Bereich IR-Empfänger.
>
> Ich hoffe das war keine unzulässige Werbung...


Gerade diese Tips, bezüglich Lieferquellen, finde ich besonders wertvoll 
!!

Noch einen schönen Abend
Gruß
Siegmar

von J. K. (kum)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

stehe bzgl. IRSND und der Unterstützung für Apple auf dem Schlauch. Im 
Artikel ist das Protokoll als "supported" beschrieben, aber kann im Code 
kein

#define IRSND_SUPPORT_APPLE_PROTOCOL

finden. Auch kein umswitchen von NEC zu Apple analog zu IRMP. Dort wird 
zunächst NEC geprüft, und dann auf Apple geswitched, weil Protokolle 
sehr ähnlich. Bei IRSND müsste es doch eine ähnliche Vorgehensweise 
geben, oder nicht? Wenn Apple --> switch zu NEC. Diesen Part kann ich 
aber nirgends finden.

Vielen Dank, Kum

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
J. Kum schrieb:

> stehe bzgl. IRSND und der Unterstützung für Apple auf dem Schlauch. Im
> Artikel ist das Protokoll als "supported" beschrieben, aber kann im Code
> kein
>
> #define IRSND_SUPPORT_APPLE_PROTOCOL
>
> finden.

Tut mir leid, das hat historische Gründe:

Das Apple-Protokoll lief früher im IRMP als NEC-Protokoll mit einem 
bestimmten Bit-Muster in den Datenbits des Frames (keine Invertierung, 
sondern festes Bitmuster in den Datenbits 24 bis 31). Später habe ich 
das Apple-Protokoll im IRMP separiert, das aber im IRSND einfach 
vergessen. Ich werde das im IRSND nachholen.

Gruß,

Frank

von J. K. (kum)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Später habe ich
> das Apple-Protokoll im IRMP separiert, das aber im IRSND einfach
> vergessen. Ich werde das im IRSND nachholen.

Mach dir keinen Stress ;-) Hatte versucht mich selbst darum zu bemühen 
es in irsnd.c einzupflegen, aber das ging vollends in die Hose.

Vielen lieben Dank für dein Engagement.

Viele Grüße, Kum

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
J. Kum schrieb:

> Mach dir keinen Stress ;-) Hatte versucht mich selbst darum zu bemühen
> es in irsnd.c einzupflegen, aber das ging vollends in die Hose.

Hier ist der Fix, den kannst Du in irsnd selbst einbauen:

Wie bisher:
        case IRMP_NEC_PROTOCOL:
        {
           ...
        }

Darunter einfügen (also noch vor dem #endif:
        case IRMP_APPLE_PROTOCOL:
        {
            irsnd_protocol = IRMP_NEC_PROTOCOL; // APPLE protocol is NEC with fix bitmask instead of inverted command

            address = bitsrevervse (irmp_data_p->address, NEC_ADDRESS_LEN);
            command = bitsrevervse (irmp_data_p->command, NEC_COMMAND_LEN);

            irsnd_buffer[0] = (address & 0xFF00) >> 8;                                                          // AAAAAAAA
            irsnd_buffer[1] = (address & 0x00FF);                                                               // AAAAAAAA
            irsnd_buffer[2] = (command & 0xFF00) >> 8;                                                          // CCCCCCCC
            irsnd_buffer[3] = 0x8B;                                                                             // 10001011
            irsnd_busy      = TRUE;
            break;
        }


Das wars. Ein IRSND_SUPPORT_APPLE_PROTOCOL wird es nicht geben, denn es 
ist einfach IRSND_SUPPORT_NEC_PROTOCOL auf 1 zu setzen. Ich werde das 
auch so nochmal im IRMP-Artikel erläutern.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Version von IRSND im Downloadbereich:

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

Änderungen:

 - Unterstützung des APPLE-Protokolls
 - Konfiguration über irmpconfig.h - analog zum IRMP
 - Einige Codeoptimierungen, um Flash-Speicher zu sparen

Viel Spaß,

Frank

von Patrick H. (patrickhh)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

endlich bin ich heute dazu gekommen den IRMP mal aufzubauen und zu 
testen. Hab mal alle FB aus meinem Sortiment zu Hause rausgekramt, um zu 
sehen, was die alle so "senden". Da kamen schon einige Protokolle 
zusammen:
NEC, RC5x, RC5, SIRC, RC6, KASEIKYO

Jetzt noch zu einer FB (wahrscheinlich Fernseher) von Grundig (FB Typ: 
TP 715). Die wurde von IRMP nicht erkannt. Kannst du mal schauen, ob es 
möglich ist, diese mit in IRMP zu integrieren.
Im Anhang findest du die Scans.

Außerdem habe ich in meinen Dokus noch ein Grundig-Protokoll gefunden.
Vielleicht kann das ja mal einer gebrauchen.


Danke schon mal für deine/eure Unterstützung...


Gruß

PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Patrick,

Patrick Hh schrieb:

> Jetzt noch zu einer FB (wahrscheinlich Fernseher) von Grundig (FB Typ:
> TP 715). Die wurde von IRMP nicht erkannt. Kannst du mal schauen, ob es
> möglich ist, diese mit in IRMP zu integrieren.
> Im Anhang findest du die Scans.

Ich habe mir die Scans angeschaut: Das ist eine Manchester-Codierung - 
ähnlich zu RC5, aber doch wieder ganz anders...

> Außerdem habe ich in meinen Dokus noch ein Grundig-Protokoll gefunden.
> Vielleicht kann das ja mal einer gebrauchen.

Die Doku ist spitze, sie beschreibt genau die Signale, die ich in Deinen 
Scans fand. :-)

Ich schaue mal, dass ich das Grundig-Protokoll in den IRMP integriere. 
Leider ist es wegen der Manchester-Codierung nicht damit getan, einfach 
nur die Preprocessor-Konstanten für die Timings zu definieren.

Gruß,

Frank

von Patrick H. (patrickhh)


Bewertung
0 lesenswert
nicht lesenswert
Das ging ja schnell!

Das hört sich ja schon mal ganz gut an. Ist auch nicht so eilig für 
mich.

Dann viel Erfolg. Mal sehen ob es klappt.

Schönen Abend noch...


PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Ich schaue mal, dass ich das Grundig-Protokoll in den IRMP integriere.

Habe es erfolgreich einbauen können, kostet auch nur "150" weitere Bytes 
im Binary.

@Patrick:
Bevor ich nun ein neues Release mache, würde ich das gerne einmal von 
Dir testen lassen, deshalb hänge ich hier nur mal die geänderten Sources 
dran, bevor ich ein neues Download-Paket zusammenstelle.

Wäre auch nicht schlecht zu wissen, wie IRMP auf längere Tastendrücke 
reagiert, eventuell muss ich da noch nacharbeiten. Hilfreich wäre da ein 
Scan mit länger gedrückter Taste - aber nicht zu lang, da sonst der 
Log-Buffer überläuft.

Das Grundig-Protokoll hat einiges gemeinsam mit RC5. Ich werde mal 
schauen, ob ich da noch einiges an gemeinsamen Code für RC5 und Grundig 
zusammenfassen kann, um noch etwas an Flash-Speicher einzusparen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, Anhang vergessen.

von Patrick H. (patrickhh)


Bewertung
0 lesenswert
nicht lesenswert
Super,

ich werde es heute Vormittag mal testen (Jetzt ist es schon zu spät).

Eine andere Frage hätte ich da auch noch. Ist es möglich den Controller, 
wenn er gerade nichts Empfängt, schlafen zu legen? Ich denke da an den 
externen Interrupt. Wenn der TSOP ein Signal bekommt, dann erwacht der 
Controller und macht dann seine IR-Erkennung.
Die Funktion währe für den Batterie/Akku Betrieb sehr von Vorteil.
Denn jetzt ist der Sromverbrauch schon bei 15mA.

Wenn dies Funktionieren würde, was muß ich dann im Programm hinzu fügen. 
Leider hab ich es nicht so mit der C Programmierung (mache lieber .asm)


Gruß

PatrickHH

von Patrick H. (patrickhh)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

es Fuktioniert! Codes werden Zuverlässig erkannt. Wenn eine Taste länger 
gedrückt wird, dann wird der Code erneut zurückgegeben. Das Repetition 
Flag wird dann aber nicht gesetzt.
Ich habe nochmal ein Scan gemacht, wo ich die Taste etwas länger 
gedrückt habe.

Bezüglich Repetition Flag und SIRC:
Bei mir wird bei einem längeren Tastendruck der Code nur einmal 
Ausgegeben. Auch wenn ich eine Taste länger drücke. Ich bekomme keine 
Wiederholung! Ist das so gewollt?
Da ich ja schon mal mit dem Logging beschäftigt war, habe ich auch noch 
von meiner SonyFB einige Scans gemacht.

Danke nochmal und Gruß


PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Patrick,

Patrick Hh schrieb:

> Eine andere Frage hätte ich da auch noch. Ist es möglich den Controller,
> wenn er gerade nichts Empfängt, schlafen zu legen?

Ja, wäre möglich.

> Die Funktion währe für den Batterie/Akku Betrieb sehr von Vorteil.
> Denn jetzt ist der Sromverbrauch schon bei 15mA.

Das Problem ist aber, dass der TSOP allein schon permanent 5mA zieht. 
Und den kannst Du nicht "schlafen legen".

> Wenn dies Funktionieren würde, was muß ich dann im Programm hinzu fügen.
> Leider hab ich es nicht so mit der C Programmierung (mache lieber .asm)

Muss ich mir erstmal selbst anschauen, ich habe mich bisher damit noch 
nicht beschäftigt.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Patrick Hh schrieb:

> es Fuktioniert! Codes werden Zuverlässig erkannt.

Freut mich :-)

> Wenn eine Taste länger
> gedrückt wird, dann wird der Code erneut zurückgegeben. Das Repetition
> Flag wird dann aber nicht gesetzt.

Hatte ich befürchtet. Aus Deinen Scans ging das nämlich nicht hervor.

> Ich habe nochmal ein Scan gemacht, wo ich die Taste etwas länger
> gedrückt habe.

Prima, werde ich mir anschauen.

> Bezüglich Repetition Flag und SIRC:
> Bei mir wird bei einem längeren Tastendruck der Code nur einmal
> Ausgegeben. Auch wenn ich eine Taste länger drücke. Ich bekomme keine
> Wiederholung! Ist das so gewollt?

Nein, aber ich muss zugeben, dass ich das mangels Sony-FB auch niemals 
austesten konnte.

> Da ich ja schon mal mit dem Logging beschäftigt war, habe ich auch noch
> von meiner SonyFB einige Scans gemacht.

Sehr schön, dann bekomme ich das dann wohl auch für SIRCs endlich mal 
richtig gelöst.

Gruß und Dank,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Patrick Hh schrieb:

> es Fuktioniert!

Eins vergaß ich noch zu fragen: mit welchem IR-Empfänger hast Du die 
Signale aufgenommmen? In der Grundig-Doku las ich was von 485kHz, das 
ist genaz schön viel für einen "normalen" TSOP.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Patrick Hh schrieb:

> Wenn eine Taste länger
> gedrückt wird, dann wird der Code erneut zurückgegeben. Das Repetition
> Flag wird dann aber nicht gesetzt.

Ich habe gerade Deine Scans mit

./irmp < IR-Data/Grundig_TP715_lange.txt |less

unter Linux getestet.

Da bei längerem Drücken der Scan-Buffer irgendwann überläuft, geht der 
Scan zwar nach 3 Frames einer jeden Taste voll in die Hose, aber irmp 
setzt bei mir trotzdem das Repetition-Flag beim zweiten Frame:

# 1 lange (wird in IRMP als 11 Dezimal ausgewertet)
protcol = 15, address = 0x0000, code = 0x0011, flags = 0x00
protcol = 15, address = 0x0000, code = 0x0011, flags = 0x01
-------------------------------------------------------------------
# 2 lange (wird in IRMP als 12 Dezimal ausgewertet)
protcol = 15, address = 0x0000, code = 0x0012, flags = 0x00
protcol = 15, address = 0x0000, code = 0x0012, flags = 0x01
-------------------------------------------------------------------
# 0 ganz lange (wird in IRMP als 10 Dezimal ausgewertet)
protcol = 15, address = 0x0000, code = 0x0010, flags = 0x00
protcol = 15, address = 0x0000, code = 0x0010, flags = 0x01

Kannst Du das nochmal überprüfen?

Gruß,

Frank

von Patrick H. (patrickhh)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

also ich benutze den TSOP mit 38KHz. Mit 36KHz habe ich es eben auch 
noch mal getestet -> Funktioniert auch.

Ich habe auch nochmal den langen Tastendruck getestet, aber ich bekomme 
das Flag nicht gesetzt. Hoffe es liegt nicht an meinem Programm. Ich 
habs (noch) nicht so mit der "C" Programmierung.
Ich lasse mir den Code und das Flag (wie im Artikel beschrieben) via 
RS232 (danke an Klaus Leidinger) senden. Eigentlich nicht viel.

> Das Problem ist aber, dass der TSOP allein schon permanent 5mA zieht.
> Und den kannst Du nicht "schlafen legen".

Mein TSOP verbraucht im Ruhezustand nur ca. 1mA!


Gruß

PatrickHH

von Tishima (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Patrick Hh schrieb:
> Bezüglich Repetition Flag und SIRC:
> Bei mir wird bei einem längeren Tastendruck der Code nur einmal
> Ausgegeben. Auch wenn ich eine Taste länger drücke. Ich bekomme keine
> Wiederholung! Ist das so gewollt?
> Da ich ja schon mal mit dem Logging beschäftigt war, habe ich auch noch
> von meiner SonyFB einige Scans gemacht.

Hallo!

Ich beschaeftige mich zur Zeit auch mit dem IRMP Code.
Das Phänomen mit dem SIRC Protocoll kann ich auch bei mir beobachten, 
und der Samsung Empfang verhält sich genauso, es werden keine neuen 
Codes bei langem Tastendruck ausgewertet.

Scans kann ich leider nicht machen da aus unerklärlichen gründen die 
eingebauten UART Funktionen bei mir nicht funktionieren wollen, ich zeig 
die empfangenen Bytes mit der UART Routine von Peter Flury an.


mfg,
Bjoern

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tishima schrieb:

> Ich beschaeftige mich zur Zeit auch mit dem IRMP Code.
> Das Phänomen mit dem SIRC Protocoll kann ich auch bei mir beobachten,
> und der Samsung Empfang verhält sich genauso, es werden keine neuen
> Codes bei langem Tastendruck ausgewertet.

Das Problem mit dem SIRCs-Code habe ich dank Patricks Scan-Datei 
reproduzieren können. Sony-FBs senden bei jedem (kurzem) Tastendruck 2 
bis 3 Wiederholungen. IRMP erkennt aber auch die vierte, fünfte usw. 
Wiederholung als Low-Level-Wiederholung statt als langen Tastendruck und 
unterdrückt diese dann.

In manchen SIRCs-Dokus steht, dass jeder Frame 2mal (in anderen Dokus 
steht 3mal) automatisch wiederholt wird.

Jetzt habe ich ein Problem: Patrick hat 3 Tasten lange gedrückt.

Taste A: 8 Frames aufgezeichnet
Taste B: 9 Frames aufgezeichnet
Taste C: 9 Frames aufgezeichnet

Wie habe ich das nun zu verstehen?

Möglichkeit 1:

Taste A: 1 Frame + 1 automatische Wiederholung - das ganze 4 mal?
Taste B: 1 Frame + 2 automatische Wiederholungen - das ganze 3 mal?
Taste C: 1 Frame + 2 automatische Wiederholungen - das ganze 3 mal?

Warum wiederholt die FB bei Taste A jeden Tastendruck nur 2mal, bei den 
Tasten B und C dreimal? Das widerspricht sich.

Möglichkeit 2:

Taste A: 1 Frame + 1 automatische Wiederholung + 6 Wiederholungen wegen 
langer Taste

Taste B: 1 Frame + 1 automatische Wiederholung + 7 Wiederholungen wegen 
langer Taste

Taste C: 1 Frame + 1 automatische Wiederholung + 7 Wiederholungen wegen 
langer Taste

Das hieße dann: Der erste Frame wird automatisch wiederholt, alle 
weiteren geben die Länge des Tastendrucks wieder und werden daher nicht 
automatisch 2- bzw. 3-fach gesendet...

Ich tendiere zu Möglichkeit 2, habe leider nichts spezielles darüber 
gefunden, wie lange Tastendrücke codiert werden.

Dein Problem mit der Samsung-FB scheint ähnlich gelagert zu sein, werde 
ich mir näher anschauen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Patrick,

Patrick Hh schrieb:

> also ich benutze den TSOP mit 38KHz. Mit 36KHz habe ich es eben auch
> noch mal getestet -> Funktioniert auch.

Okay, dann habe ich das mit den 485kHz falsch interpretiert.

> Ich habe auch nochmal den langen Tastendruck getestet, aber ich bekomme
> das Flag nicht gesetzt. Hoffe es liegt nicht an meinem Programm. Ich
> habs (noch) nicht so mit der "C" Programmierung.

Gut, dann muss ich nochmal den Source prüfen. Danke für Deine 
Bestätigung.

> Mein TSOP verbraucht im Ruhezustand nur ca. 1mA!

Laut Datenblatt zieht der 5mA. Nun gut, da scheint der Wert im 
Datenblatt ein Maximalwert zu sein.

Gruß,

Frank

von Patrick H. (patrickhh)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

was ich noch in meinen Unterlagen zu SIRC gefunden habe ist:

"Die Übertragung muss nach einer Pause noch mindestens zweimal (fünfmal 
bei Camcorder) wiederholt werden, sonst wird von einem Übertragunsfehler 
ausgegangen."

Das hört sich so an, als ob die Wiederholungen von Gerät zu Gerät 
unterschiedlich sein können.

Vielleicht hilft die Info...


Gruß

PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Patrick Hh schrieb:

> "Die Übertragung muss nach einer Pause noch mindestens zweimal (fünfmal
> bei Camcorder) wiederholt werden, sonst wird von einem Übertragunsfehler
> ausgegangen."

"Zweimalige Wiederholung" heisst 3x derselbe Frame, okay.

Aber was passiert bei längerem Tastendruck? Habe ich dann N x 3 Frames?
Oder 3 Frames + N weitere?

Gegen N x 3 Frames spricht, dass die erste Taste aus Deinem Scan exakt 8 
Frames erzeugt hat. Das ist nicht durch 3 teilbar.

> Das hört sich so an, als ob die Wiederholungen von Gerät zu Gerät
> unterschiedlich sein können.

Noch schlimmer. Wie lange unterdrücke ich also Wiederholungen, bevor ich 
sie wieder an die Applikation mit gesetztem Repetition-Bit weitergebe?

Ich habe mir jetzt nochmal sämtliche Sony-FB-Scans im Verzeichnis 
IR-Data angeschaut, die ich von verschiedenen Leuten bekommen habe.

Dort habe ich folgende Häufigkeiten finden können:

49 x 3 Frames
65 x 4 Frames
18 x 5 Frames
 2 x 6 Frames
 4 x 7 Frames
 2 x 8 Frames
 3 x 9 Frames

Auffallend ist:

1. Es werden mindestens 3 Frames gesandt.

2. Danach kann jede x-beliebige Anzahl von Frames erfolgen, es gibt
   keine ganzzahligen Vielfachen von 2 oder 3 Frames.

Ergo werde ich den Code derart ändern, dass die erste und zweite 
Wiederholung des Original-Frames ignoriert wird und anschließend jede 
weitere Wiederholung des Frames (innerhalb des Zeitrahmens natürlich) 
mit gesetztem Repetition-Bit an die Applikation wieder zurückgemeldet 
wird.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tishima schrieb:

> Das Phänomen mit dem SIRC Protocoll kann ich auch bei mir beobachten,
> und der Samsung Empfang verhält sich genauso, es werden keine neuen
> Codes bei langem Tastendruck ausgewertet.

Frage: geht es um SAMSUNG oder SAMSUNG32?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Eine neue Version von IRMP ist unter

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

verfügbar.

Änderungen:

1) Neues Protokoll: Grundig

2) Behandlung von automatischen Frame-Wiederholungen beim SIRCS-,
   SAMSUNG32- und NUBERT-Protokoll verbessert.

Zu Punkt 2:

Beim SIRCS-Protokoll werden nun bei Frame-Wiederholungen nur noch der 
zweite und der dritte Frame ignoriert, alle weiteren Wiederholungen 
werden als langer Tastendruck gewertet und das entsprechende 
Repetition-Flag gesetzt.

Bei SAMSUNG32 und NUBERT wird jeder 2. Wiederholungsframe ignoriert, 
weil hier wohl immer 2 Frames gesendet werden. Ein dritter, fünfter usw. 
Frame wird als langer Tastendruck gewertet und das entsprechende 
Repetition-Flag gesetzt.

Viel Spaß,

Frank

P.S.

@Patrick:

Da bei meinen Tests mit Grundig einwandfrei das Repetition-Flag gesetzt 
wird, wenn derselbe Frame N-fach wiederholt wird, kann ich das 
Verhalten, was bei Dir auftritt, nicht nachvollziehen. Hilfreich wäre da 
ein Auszug des Sources, den Du zur Ausgabe von irmp_data.flags 
verwendest.

von Tishima (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ha

Frank M. schrieb:
> Frage: geht es um SAMSUNG oder SAMSUNG32?
>
> Gruß,
>
> Frank

Hallo!

Kann ich jetzt momentan garnicht sagen. Der Ausgabestring ist ja bei 
beiden SAMSUNG im Beispiel Code gleich. An das Protkoll Byte kann ich 
mich garnicht erinnern. Wenn ich meine Universalfernbedienung nochmal 
dazu überedet kriege SAMSUNG Codes auszuspucken, werde ich mal aufs 
Protokoll Byte achten.

gruß,
Bjoern

von Tishima (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!

So habe eben den neuen Code getestet.

Sirc wird nun sauber bei mir erkannt, jedoch beim Samsung32 Code haut 
ein langer Tastendruck immer noch nicht hin.

gruß,
Bjoern

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Version 1.3.1 von IRMP verfügbar, Download unter

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

Änderungen:

 - Bit-Maske für SAMSUNG32 korrigiert, das niederwertigste Bit wurde 
bisher
   komplett ignoriert

 - Timing-Werte für SAMSUNG32 geändert

Ebenso ist nun die Version 1.3.1 von IRSND verfügbar, Download unter

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

Änderungen:

 - GRUNDIG-Protokoll hinzugefügt

 - Behandlung von Frame-Wiederholungen für SIRCS, SAMSUNG32 und NUBERT
   korrigiert

Viel Spaß,

Frank

von Patrick H. (patrickhh)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

> zu: Grundig
also hier mal meine main.c.
Als Compiler nehme ich GCC. Als Controller nehme ich einen Mega8.

Wenn ich eine Taste lange drücke, dann bekomme ich auch nacheinander die 
Codes angezeigt, jedoch ohne das Flag.

> zu: SIRC
Den Code kann ich erst am Wochenende testen. Dann gibts Feedback.


Gruß


Patrick

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tishima schrieb:

> Sirc wird nun sauber bei mir erkannt,

Prima, freut mich.

> jedoch beim Samsung32 Code haut ein langer Tastendruck immer noch nicht hin.

Was bekommst du stattdessen? N x denselben Befehl? Oder nur 1x?
Und es handelt sich definitiv um SAMSUNG32?

IRMP erkennt lange Tastendrücke bei Protokollen, die nicht explizit 
einen Repetition-Frame oder einen anderen Mechanismus dafür bieten, 
einfach daran, dass die Frame-Wiederholungen innerhalb von 100 msec 
reinkommen.

Um da jetzt weiterzukommen, bräuchte ich einen Scan von Dir. Du sagtest, 
Du benutzt die Fleury-Lib auf dem UART? Lass die mal weg, dann sollte es 
gehen. Der Scan wird mit 9600Baud, 8bit, no parity ausgegeben.

Gruß,

Frank

P.S.
Ich habe gerade eben eine neue Version 1.3.1 hochgeladen, da war sowieso 
noch ein Fehler beim Erkennen des SAMSUNG-Kommando-Codes. Das 
niederwertigste Bit wurde verschlabbert. Dürfte aber keine Änderung bei 
Dir bzgl. langer Tastendrücke bringen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Patrick,

Patrick Hh schrieb:

> Wenn ich eine Taste lange drücke, dann bekomme ich auch nacheinander die
> Codes angezeigt, jedoch ohne das Flag.

Bei jeder FB? Oder nur bei Grundig? Wenn es bei jeder FB ist, dann liegt 
die Vermutung nahe, dass in Deiner main-Funktion der Wurm drin ist. 
Schaue ich mir an.

Gruß,

Frank

von Patrick H. (patrickhh)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

> Bei jeder FB? Oder nur bei Grundig? Wenn es bei jeder FB ist, dann liegt
> die Vermutung nahe, dass in Deiner main-Funktion der Wurm drin ist.

Bis jetzt nur bei der Grundig. Bei Anderen z.B. RC5 oder NEC bekomme ich 
beim dauer Drücken das Flag gesetzt.


PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Patrick Hh schrieb:

> Bis jetzt nur bei der Grundig. Bei Anderen z.B. RC5 oder NEC bekomme ich
> beim dauer Drücken das Flag gesetzt.

Hm, dann kann es nicht an der main-Funktion liegen, habe sie mir auch 
angeschaut, sieht alles okay aus.

Bin nun etwas ratlos. Warum klappt das bei mir mit den Scans und bei Dir 
nicht?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Patrick Hh schrieb:

> Bis jetzt nur bei der Grundig. Bei Anderen z.B. RC5 oder NEC bekomme ich
> beim dauer Drücken das Flag gesetzt.

Ich habe mir nochmal die Doku zum Grundig-Protokoll angeschaut. Dort 
haben die Info-Frames, die bei längerem Tastendruck wiederholt werden, 
einen Abstand von 117,76ms.

In der Scan-Datei müssten die Info-Frames bei einem so großem Abstand 
eigentlich alle in einer separaten Zeile stehen. Tun sie aber nicht, sie 
sind alle in einer Zeile.

Meine Frage: Hast Du da vielleicht mittels Editor etwaige Mehrfachzeilen 
zu einer einzigen Zeile zusammenkopiert - zum Beispiel zwecks 
Übersichtlichkeit? In den Scans haben die Info-Frames nämlich lediglich 
einen Abstand von 2ms. Dieser Zeitrahmen liegt weit unterhalb der 100ms, 
die ich zur Erkennung von langen Tastendrücken als obere Grenze 
definiert habe. Das würde auch erklären, warum bei der Auswertung der 
Scans das Repetition-Bit auch gesetzt wird.

Meine Bitte: Ändere mal in irmp.c die Zeile
#define IRMP_REPETITION_TIME  (uint16_t)(F_INTERRUPTS * 100.0e-3 + 0.5)  // autodetect key repetition within 100 msec

in
#define IRMP_REPETITION_TIME  (uint16_t)(F_INTERRUPTS * 150.0e-3 + 0.5)  // autodetect key repetition within 150 msec

ab und teste die Grundig-FB nochmals mit langen Tastendrücken.

Die 100ms sind als Grenze wohl zu knapp, denn laut Grundig-Doku sind wir 
mit 117ms knapp drunter. Fragt sich nur, warum in den Scans nur 2ms als 
Pausen zwischen den Frames zu sehen sind....

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Bjoern,

Tishima schrieb:

> [...] jedoch beim Samsung32 Code haut
> ein langer Tastendruck immer noch nicht hin.

Für Dich gilt dasselbe: Ändere bitte mal die 100 msec in 150 msec, siehe 
Code im vorherigen Posting. Der Grund, warum beim SAMSUNG32-Protokoll 
keine langen Tastendrücke erkannt werden, könnte derselbe wie bei der 
Grundig-FB sein.

Gruß,

Frank

von Patrick H. (patrickhh)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

> Meine Frage: Hast Du da vielleicht mittels Editor etwaige Mehrfachzeilen
> zu einer einzigen Zeile zusammenkopiert - zum Beispiel zwecks
> Übersichtlichkeit?

Ich habe, glaube ich, bei den Scan-Daten alles in eine Zeile gemacht. 
Denn mein Terminal Programm setzt nach jeder Übertragung ein "CR/LF" am 
Ende. Das habe ich eigentlich nur entfernt. Vielleicht lag es ja daran.
Kann am Wochenende ja nochmal ein anderes Terminal Programmm benutzen 
und nochmals einen Scan machen.

> Meine Bitte: Ändere mal in irmp.c die Zeile......
Werde ich testen. Wird aber erst am Wochenende was.

Gruß

PatrickHH

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Patrick,

Patrick Hh schrieb:

> Ich habe, glaube ich, bei den Scan-Daten alles in eine Zeile gemacht.

Jau, dann hattest Du mich mit der Scan-Datei auf die falsche Fährte 
geführt und ich dachte, 100ms reichen völlig aus ;-)

> Werde ich testen. Wird aber erst am Wochenende was.

Bin mir nun ziemlich sicher, dass es mit der Änderung funktionieren 
wird.

Gruß,

Frank

von Tishima (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Für Dich gilt dasselbe: Ändere bitte mal die 100 msec in 150 msec, siehe
> Code im vorherigen Posting. Der Grund, warum beim SAMSUNG32-Protokoll
> keine langen Tastendrücke erkannt werden, könnte derselbe wie bei der
> Grundig-FB sein.

Hallo!

Habe soeben die neue Version getestet mit ner Phillips 
Universalfernbedienung, der Samsung32 Code wird nun richtig erkannt, 
auch ohne das ich den Wert auf 150 geaendert habe.
Meine Pollin UFB will nun garkeinen SAMSUNG32 Code mehr ausspucken 
obwohl ich mir sicher bin den selben device Code eingeben zu haben, wie 
bei den letzten Tests.
Aber die UFB ist eh der letzte Chinaschrott und wird von mir nicht mehr 
verwendet.

So, ich klink mich hier erstmal aus und bastle mit Eventghost rum um 
meine Software zu steuern die ich benötige.


Viel, Spaß noch....

mfg,
Bjoern

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tishima schrieb:

> Habe soeben die neue Version getestet mit ner Phillips
> Universalfernbedienung, der Samsung32 Code wird nun richtig erkannt,
> auch ohne das ich den Wert auf 150 geaendert habe.

Freut mich :-)

> So, ich klink mich hier erstmal aus und bastle mit Eventghost rum um
> meine Software zu steuern die ich benötige.

Viel Spaß, ich hoffe, Du erzählst nachher etwas über Dein Projekt, wenn 
es dann fertig ist.

Frank

von Patrick H. (patrickhh)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

ich habe die neue Version getestet:

SIRC funktioniert jetzt auch mit langen Tastendruck. Das Flag wird nun 
auch gesetzt.

Bei Grundig wird nun auch das REPETITION Flag gesetzt, wenn ich die 
REPETITION TIME auf mindestens 120ms setzte. Also stimmen die Werte, die 
im Datenblatt stehen.


Vielen Dank nochmal für deine Unterstützung...


Gruß

PatrickHH

von eku (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> eku schrieb:
>
>> Reicht für die Analyse wenn ich die UART-Ausgaben mit IRMP_LOGGING=1
>
>> aufzeichne?
>
> Ja, müsste reichen, am besten so viele Tasten wie möglich und dann in
> der Form:

Anbei die Protokolle für Gigaset M740AV (gigaset.txt) ud Nokia D-Box 2 
(dbox.txt). Letztere wird seit der Unterstützung des Grundig-Protokolls 
wechselnd als RC(x) und Grundig erkannt. Die Codes sind aber Müll.

Die Unterstützung sowohl in IRMP als auch in IRSND wäre super!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Patrick,

Patrick Hh schrieb:

> SIRC funktioniert jetzt auch mit langen Tastendruck. Das Flag wird nun
> auch gesetzt.

Freut mich.

> Bei Grundig wird nun auch das REPETITION Flag gesetzt, wenn ich die
> REPETITION TIME auf mindestens 120ms setzte. Also stimmen die Werte, die
> im Datenblatt stehen.

Gut. Dann werde ich auf Nummer sicher gehen und die REPETITION TIME fürs 
nächste Release auf 130ms setzen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Anbei die Protokolle für Gigaset M740AV (gigaset.txt) ud Nokia D-Box 2
> (dbox.txt). Letztere wird seit der Unterstützung des Grundig-Protokolls
> wechselnd als RC(x) und Grundig erkannt. Die Codes sind aber Müll.

Ich habe gerade mal reingeschaut. Das Gigaset-Protokoll scheint auch 
Manchester-codiert zu sein, da sowohl Pulsdauern als auch Pausen in ein- 
und zweifacher Länge vorkommen. Die Zeiten sind sehr knapp, da ist die 
Abtastrate von 10000/sec fast zuwenig. Muss ich mal schauen, dass ich da 
ein System reinbekomme.

Die D-Box scheint eine Abart des Grundig-Protokolls zu verwenden, 
offenbar ist hier einfach das Telegramm länger als 10 Bits, nämlich 16. 
Deshalb steigt der Grundig-Code nach 10 Bits aus und die restlichen 6 
Bits werden als RC5 erkannt, da die verbliebenen Daten-Bits ohne 
Start-Bit so "aussehen" wie RC5. Ich schaue, dass ich die beiden 
Protokolle über eine variable Längenerkennung auseinanderdividiert 
bekomme. Dann sollte die Erkennung sowoh für D-Box als auch für Grundig 
funktionieren.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich habe gerade mal reingeschaut. Das Gigaset-Protokoll scheint auch
> Manchester-codiert zu sein, da sowohl Pulsdauern als auch Pausen in ein-
> und zweifacher Länge vorkommen. Die Zeiten sind sehr knapp, da ist die
> Abtastrate von 10000/sec fast zuwenig. Muss ich mal schauen, dass ich da
> ein System reinbekomme.

Laut LIRC Datensatz gelten folgende Parameter:
  bits           8
  eps            30
  aeps          100
  one             0     0
  zero            0     0
  pre_data_bits   24
  pre_data       0x10
  gap          210000
  min_repeat      2
  toggle_bit      25

und für doe DBox
[code]
  bits           8
  eps            30
  aeps          100

  one             0     0
  zero            0     0
  pre_data_bits   24
  pre_data       0x10
  gap          210000
  min_repeat      2
  toggle_bit      25
[code]

Hilft Dir das?

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> und für doe DBox

kleiner Fehler im Posting
name  D-BOX2
  bits            8
  flags SHIFT_ENC|CONST_LENGTH
  eps            10
  aeps          300

  header        510  2520
  one           450   550
  zero          450   550
  pre_data_bits   1
  pre_data       0x0
  post_data_bits  8
  post_data      0xC5
  gap          59500
  repeat_bit      0

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Anbei die Protokolle für Gigaset M740AV (gigaset.txt) ud Nokia D-Box 2
> (dbox.txt). Letztere wird seit der Unterstützung des Grundig-Protokolls
> wechselnd als RC(x) und Grundig erkannt. Die Codes sind aber Müll.

Ich habe das Nokia-Protokoll in den IRMP integriert. Mein erster 
Eindruck hat sich bestätigt: Das Nokia-Protokoll unterscheidet sich nur 
durch 16 Datenbits (8 Adressbits + 8 Kommandobits) statt 9 Datenbits (0 
Adressbits + 9 Kommandobits) beim Grundig-Protokoll. Das Timing ist 
annähernd gleich.

Anbei die geänderten Sources. Kannst Du das mal testen, auch was lange 
Tastendrücke angeht? Wenn es bei Dir funktioniert, werde ich ein neues 
Release für IRMP erstellen.

Gruß,

Frank

P.S.
An der Gigaset-FB bin ich noch dran.

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Frank M. schrieb:
> Anbei die geänderten Sources. Kannst Du das mal testen, auch was lange
> Tastendrücke angeht? Wenn es bei Dir funktioniert, werde ich ein neues
> Release für IRMP erstellen.

Die Dekodierung funktioniert nun. Aus Mangel einer Grundig-FB kann ich 
nicht testen, ob diese auch noch geht. Die dekodierten Codes 
unterscheiden sich allerdings von 
http://lirc.sourceforge.net/remotes/nokia/DBOX2. Hat das was zu 
bedeuten?

Mit den Änderungen kann ich irsnd.c nicht länger übersetzen.
irmp/irsnd.c: In function 'ir_tx_process':
irmp/irsnd.c:526: error: 'SIRCS_REPETITION_CNT' undeclared (first use in this function)
irmp/irsnd.c:526: error: (Each undeclared identifier is reported only once
irmp/irsnd.c:526: error: for each function it appears in.)
irmp/irsnd.c:527: error: 'SIRCS_REPETITION_TIME' undeclared (first use in this function)
irmp/irsnd.c:576: error: 'SAMSUNG32_REPETITION_CNT' undeclared (first use in this function)
irmp/irsnd.c:577: error: 'SAMSUNG32_REPETITION_TIME' undeclared (first use in this function)
irmp/irsnd.c:661: error: 'DENON_REPETITION_CNT' undeclared (first use in this function)
irmp/irsnd.c:662: error: 'DENON_REPETITION_TIME' undeclared (first use in this function)
irmp/irsnd.c:678: error: 'NUBERT_REPETITION_CNT' undeclared (first use in this function)
irmp/irsnd.c:679: error: 'NUBERT_REPETITION_TIME' undeclared (first use in this function)
irmp/irsnd.c:713: error: 'GRUNDIG_REPETITION_CNT' undeclared (first use in this function)
irmp/irsnd.c:714: error: 'GRUNDIG_REPETITION_TIME' undeclared (first use in this function)


von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Die Dekodierung funktioniert nun.

Freut mich!

> Aus Mangel einer Grundig-FB kann ich nicht testen, ob diese
> auch noch geht.

Macht nix, das habe ich bereits mit den mir vorliegenden 
Grundig-Scan-Dateien gemacht. War ein wenig Arbeit, eine vernünftige 
Abbruchbedingung zu finden, um Grundig und Nokia zu unterscheiden, die 
sich tatsächlich nur in der Anzahl der Bits unterscheiden ;-)

> Die dekodierten Codes
> unterscheiden sich allerdings von
> http://lirc.sourceforge.net/remotes/nokia/DBOX2.

Ich weiß nicht, wie lirc die Codes generiert, ich vermute, die haben da 
noch einen weiteren Abstraktionslayer mit drin.

Die Codes, die IRMP ausspuckt, halte ich jedoch für absolut plausibel, 
da Taste 0 = 0x00, Taste 1 = 0x01, .... Taste 9 = 0x09 ist. Ausserdem 
habe ich heute morgen noch eine weitere Nokia-TV-Scan-Datei per Mail von 
einem anderen IRMP-Anwender erhalten, so dass ich da einen Quercheck 
machen konnte. Lediglich die Adresse unterschied sich, passt also alles 
wunderbar.

> Mit den Änderungen kann ich irsnd.c nicht länger übersetzen.

Das liegt daran, dass ich den IRMP-/IRSND-Source in der Zwischenzeit 
weiterbearbeitet und optimiert habe, deshalb hatte ich auch nur die 3 
Dateien zwecks Test hier ins Zip-Archiv gepackt. Mit dem nächsten 
Release gibt es dann wieder einen einheitlichen Stand.

Vielen Dank fürs Feedback,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Version 1.4.0 von IRMP verfügbar, Download unter

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

Änderungen:

 - Neues Protokoll: NOKIA

 - Erkennung von langen Tastendrücken beim Grundig-Protokoll

Ebenso ist nun die Version 1.4.0 von IRSND verfügbar, Download unter

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

Änderungen:

 - NOKIA-Protokoll hinzugefügt

Viel Spaß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Anbei die Protokolle für Gigaset M740AV (gigaset.txt) [...]

Wie gestern schon angedeutet: Die Pulse/Pausen sind arg kurz. Es handelt 
sich um ein 23-bittiges Manchester-Protokoll, wobei jeder Frame einmal 
zusätzlich wiederholt wird. Leider ist die Aufzeichnungsrate von 
10000/sec hier zu niedrig, um eindeutige Werte zu erhalten. Fast jede 
Wiederholung ist nicht identisch mit dem Original-Frame, weil ein Puls 
mehr oder weniger schon das Bit im Frame kippen lässt.

Kannst Du dieselben Scans nochmal mit F_INTERRUPTS 15000 machen? Dann 
sollte die Genauigkeit ausreichen.

Gruß,

Frank

von eku (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Kannst Du dieselben Scans nochmal mit F_INTERRUPTS 15000 machen? Dann
> sollte die Genauigkeit ausreichen.

Samplerate 15kHz anbei.

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Samplerate 15kHz anbei.

Vielen Dank, die Datei ist echt brauchbar. Ich habe das Protokoll soweit 
"enschlüsseln" und den IRMP-Source anpassen können. Ich habe mal zum 
Testen die geänderten Sources angehängt.

Leider bleibt noch eine klitzekleine Unklarheit:

In der 10kHz-Datei wurde jeder Frame wiederholt, wobei in der 
Wiederholung immer das 15te Bit invertiert wurde. Dieses Bit hat 
offenbar eine ähnliche Bedeutung wie das Toggle-Bit beim RC5-Protokoll.

In der 15kHz-Datei gibt es diese Frame-Wiederholungen nicht.

Das kann zwei Gründe haben:

  a) Du hast beim 10kHz-Scan die Tasten länger gedrückt. Dann ist das
     15. Bit ein Flag für langen Tastendruck.

oder

  b) Die Wiederholungen wurden wegen der höheren Samplerate
     "verschluckt", d.h. es werden immer (auch bei kurzen
     Tastendrücken) 2 Frames verschickt, wobei das 15. Bit den
     automatischen Wiederholungs-Frame kenntlich macht.

Ich tippe mal auf Fall b).

Aber das lässt sich leicht herausfinden:

Sollten beim angehängten Source auch bei kurzem(!) Tastendruck 
konsequent immer 2 identische Frames erkannt werden und IRMP beim 
zweiten Frame das REPETION-Flag setzen, dann handelt es sich um Fall b) 
und ich muss das im Source noch gesondert behandeln.

Meine Bitte: Kannst Du das bitte testen? Am besten mit F_INTERRUPTS = 
15000. Wenn Du dann noch Lust/Zeit hast, kannst Du das ganze auch mal 
bei F_INTERRUPTS = 10000 testen und eine Aussage über die Erkennungsrate 
bei der niedrigeren Samplerate treffen.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Sollten beim angehängten Source auch bei kurzem(!) Tastendruck
> konsequent immer 2 identische Frames erkannt werden und IRMP beim
> zweiten Frame das REPETION-Flag setzen, dann handelt es sich um Fall b)
> und ich muss das im Source noch gesondert behandeln.
>
> Meine Bitte: Kannst Du das bitte testen? Am besten mit F_INTERRUPTS =
> 15000. Wenn Du dann noch Lust/Zeit hast, kannst Du das ganze auch mal
> bei F_INTERRUPTS = 10000 testen und eine Aussage über die Erkennungsrate
> bei der niedrigeren Samplerate treffen.

Mit 15kHz wird zuverlässig erkannt. Die FB sendet nur ein Frame. 
Allerdings braucht es nur wenige Millisekunden für die 
Tastenwiederholung, die dann zuverlässig als solche von IRMP erkannt 
wird.

Mit 10kHz stimmen zwar die Codes, aber die Wiederholung wird nur 
sporadisch von IRMP als solche erkannt. Das ganze ist also, wie Du schon 
vermutetest, grenzwertig.

Ich habe kein Problem, IRMP mit 15kHz abtasten zu lassen. Siehst Du noch 
eine Stellschraube, um vielleicht mit 10kHz hinzukommen?

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Mit 10kHz stimmen zwar die Codes, aber die Wiederholung wird nur
> sporadisch von IRMP als solche erkannt.

Gerade noch einmal getestet. Der Gerätecode wird nicht zuverlässig 
decodiert.

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mit 15kHz werden keine anderen Protokolle erkannt. Woran kann das 
liegen?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Mit 15kHz wird zuverlässig erkannt. Die FB sendet nur ein Frame.

Prima.

> Allerdings braucht es nur wenige Millisekunden für die
> Tastenwiederholung, die dann zuverlässig als solche von IRMP erkannt
> wird.

Dann lasse ich das mit der Extra-Auswertung des 15. Bits. Da ich dieses 
nur "ab und zu" im 10kHz-Scan gesehen habe, kann es auch sein, dass es 
einfach ein zufällig gekipptes Bit war. Wie gesagt, bei 10kHz liegen die 
Zeiten zu nah beieinander, um noch zuverlässig 0 oder 1 erkennen zu 
können.

> Mit 10kHz stimmen zwar die Codes, aber die Wiederholung wird nur
> sporadisch von IRMP als solche erkannt. Das ganze ist also, wie Du schon
> vermutetest, grenzwertig.

Okay, dann werde ich das im Source so machen, dass bei 10kHz der 
SIEMENS-Gigaset-Decoder unter Angabe einer Warnung deaktiviert wird.

> Ich habe kein Problem, IRMP mit 15kHz abtasten zu lassen. Siehst Du noch
> eine Stellschraube, um vielleicht mit 10kHz hinzukommen?

Nein. Bei dem 10kHz-Scan überlappen sich die Puls-/Pausenlängen 
teilweise. Hat einfach keinen Zweck.

Danke für Dein Feedback,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Mit 15kHz werden keine anderen Protokolle erkannt. Woran kann das
> liegen?

Upps, weiß ich nicht. Es kann höchstens sein, dass eine gemessene 
Puls-/Pausen-Länge die 255 überschreitet. Ich dachte aber bisher, dass 
bis 15kHz noch alle Variablen mit uint8_t reichen... muss ich nochmal 
gegenchecken.

Welche anderen Protokolle hast Du denn getestet?

Notfalls könntest Du mal auf 14kHz runtergehen.

Gruß,

Frank

von Torsten K. (nobby)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hy,

ich versuche gerade das IRMP zu benutzen um damit NEC Codes zu meinem 
Receiver zu schicken. Der will aber nicht reagierren.
Ich habe das Modul von Klaus Leidinger nachgebaut, das zeigt mir den 
richtigen Code an, den ich sende, aber der Receiver mag nicht.
Ich hab mir das Signal der echten FB mal angeschaut und hier als Bild 
abgelegt. Da sieht man, das der eigentliche Befehl nur einmal kommt, und 
danach nur noch sowas wie "Taste noch gedrückt" ?

Das Timing der Repeats ist dieses:
9,1mS low, 2,1mS High, 700µS Low, 95,6mS High, dann gehts wieder mit 
9,1mS Low los.

Könnte die "Nichtfunktion" damit zusammenhängen, bzw. ist es möglich 
dieses Signal noch anzuhängen ??

Gruß
Torsten

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Upps, weiß ich nicht. Es kann höchstens sein, dass eine gemessene
> Puls-/Pausen-Länge die 255 überschreitet. Ich dachte aber bisher, dass
> bis 15kHz noch alle Variablen mit uint8_t reichen... muss ich nochmal
> gegenchecken.

Ich bin mir sicher, dass es da Überläufe gibt. Entferne mal den Cast 
uint8_t vor den Konstanten (Timing) an drehe die Compilerwarnungen hoch.

> Welche anderen Protokolle hast Du denn getestet?

NEC, Nubert, Denon, RC5, Grundig, Nokia

> Notfalls könntest Du mal auf 14kHz runtergehen.

Bring nichts. Bei 11kHz funktionieren die anderen, aber Siemens wird 
nicht zuverlässig erkannt. Wir werden die Konstanten auf 16 Bit 
verbreitern
müssen. Ob das generell so ist oder nur wenn F_INTERRUPTS > 10000 
überlasse ich Dir.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:

> Ich habe das Modul von Klaus Leidinger nachgebaut, das zeigt mir den
> richtigen Code an, den ich sende, aber der Receiver mag nicht.

Das heisst also, der reagiert überhaupt nicht? Oder nur 1mal auf eine 
Taste?

> Ich hab mir das Signal der echten FB mal angeschaut und hier als Bild
> abgelegt. Da sieht man, das der eigentliche Befehl nur einmal kommt, und
> danach nur noch sowas wie "Taste noch gedrückt" ?
> Das Timing der Repeats ist dieses:
> 9,1mS low, 2,1mS High, 700µS Low, 95,6mS High, dann gehts wieder mit
> 9,1mS Low los.

Das entspricht genau dem, was in

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

unter Protokoll "NEC, Tastenwiederholung" steht:

   9000µs Puls, 2250µs Pause, 560µs Puls, ~100ms Pause

Dieser Frame wird eigentlich nur geschickt, um eine Taste zu 
wiederholen, also dem Empfänger mitzuteilen, dass Du noch immer die 
Taste drückst.

> Könnte die "Nichtfunktion" damit zusammenhängen, bzw. ist es möglich
> dieses Signal noch anzuhängen ??

Schickt Deine Original-FB denn diesen Wiederholungsframe auch aus, wenn 
Du die Taste nur kurz drückst? Wenn nicht, reagiert dann der Empfänger 
in Deinem Gerät?

Wenn Deine FB diesen Wiederholungsframe generell sendet, egal wie lange 
Du die Taste drückst, dann würde ich dieses absonderliche Verhalten 
Deiner FB über ein Bit in irmp_data.flags nachbilden.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Ich bin mir sicher, dass es da Überläufe gibt. Entferne mal den Cast
> uint8_t vor den Konstanten (Timing) an drehe die Compilerwarnungen hoch.

Werde ich mir ansehen.

> Bring nichts. Bei 11kHz funktionieren die anderen, aber Siemens wird
> nicht zuverlässig erkannt. Wir werden die Konstanten auf 16 Bit
> verbreitern müssen. Ob das generell so ist oder nur wenn F_INTERRUPTS
> 10000 überlasse ich Dir.

Das wäre bitter, denn nicht nur der Code würde größer werden, sondern 
auch das Laufzeitverhalten könnte kritisch werden.

Ich werde das überprüfen und dann nach einer geeigneten Lösung suchen.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerade mal die Timings und Zählervariablen auf 16Bit verbreitert. Bis 
auf Denon funktioniert wieder alles bei 15kHz. Mehrverbrauch etwa 1kByte 
Flash.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Ich bin mir sicher, dass es da Überläufe gibt. Entferne mal den Cast
> uint8_t vor den Konstanten (Timing) an drehe die Compilerwarnungen hoch.

Entfernen darf man die Casts auf keinen Fall, denn dann sind die 
Konstanten alle Floats und die Floating-Point-Lib wird dann aktiv.

Die größten Werte im Source sind

NEC_START_BIT_PULSE_TIME mit 9000e-6

bzw.

BANG_OLUFSEN_START_BIT3_PAUSE_TIME mit 15625e-6

Damit rechne ich jetzt mal aus:
#define NEC_START_BIT_PULSE_LEN_MAX             ((uint8_t)(F_INTERRUPTS * NEC_START_BIT_PULSE_TIME * MAX_TOLERANCE_40 + 0.5) + 1)

Da kommt heraus bei 15kHz:

15000 x 9000e-6 x 1.4 + 0.5 + 1 = 136,5 -> 137

Jetzt noch:
#define BANG_OLUFSEN_START_BIT3_PAUSE_LEN_MAX   ((uint8_t)(F_INTERRUPTS * BANG_OLUFSEN_START_BIT3_PAUSE_TIME * MAX_TOLERANCE_05 + 0.5) + 1)

Bei 15kHz:

15000 x 15625e-6 x 1.05 + 1 = 247,09375 -> 247

Das passt also alles noch in den Wertebereich von 0 bis 255. Das Problem 
muss woanders liegen. Irgendwas läuft bei 15kHz über, aber was? Ich habe 
auch in Erinnerung, dass Klaus Leidinger den IRMP damals auch mit 15kHz 
erfolgreich getestet hat...

Ich werde weitersuchen,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Gerade mal die Timings und Zählervariablen auf 16Bit verbreitert. Bis
> auf Denon funktioniert wieder alles bei 15kHz. Mehrverbrauch etwa 1kByte
> Flash.

1 kByte sind 30%. Das ist mir zuviel. Ich vermute auch, dass diese 
"Gewaltaktion" eigentlich nicht notwendig ist, siehe meine Berechnungen 
oben.
Es gibt irgendwo ein 8-Bit-Problem im Source bei 15kHz, aber mir wäre es 
lieber, den Übeltäter zu finden statt den Teufel mit dem Bezelbub 
auszutreiben...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Da kommt heraus bei 15kHz:
>
> 15000 x 9000e-6 x 1.4 + 0.5 + 1 = 136,5 -> 137

Rechenfehler, korrekt ist:

15000 x 9000e-6 x 1.4 + 0.5 + 1 = 190,5 -> 190.

Der Wert bleibt trotzdem unter 256...

Ich habe auch eben mal ein kleines Programm geschrieben, um mir alle 
Timingwerte ausgeben zu lassen. Keines erzeugt bei 15kHz einen 
8-Bit-Überlauf.

Also weiter suchen...

Gruß,

Frank

von Simon K. (simon) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sind es denn auch genau 15kHz? Zum Beispiel mit 15,625kHz (Ist ja eine 
durchaus übliche Frequenz, wenn man einen 2^n Vorteiler benutzt).

Bang & Olufsen:
15625 x 15625e-6 x 1.05 + 1 = 257,3

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Zur Tastenwiederholung bei NEC.

Der Receiver reagiert garnicht.

Wenn ich die Taste an der FB dauerhaft drücke bekomme ich auch dauernd 
das Wiederholungssignal.

Die Taste so kurz zu drücken ist nicht wirklich einfach, außerdem sehe 
ich das dann ja auch nicht, was tatsächlich gesendet wird.
Ich müßte mal den zusätzlichen IR Empfänger direkt über den Receiver 
legen, damit ich dann mit dem Scope das Signal nachmessen kann.
Ich hab aber mal versucht die Taste ganz kurz zu drücken, da scheint der 
auch zu reagieren.

Das Signal selber, welches ich verschicke sieht vom Timing nahezu gleich 
aus, da habe ich an den Defines extra nachverändert, aber der Receiver 
reagiert trotzdem nicht.
Ich habe auch schonmal die IR Diode aus der FB an meiner Schaltung 
benutzt, weil ich eine ungewöhnliche Wellenlänge vermutet habe.
Das wars auch nicht.
Sehr merkwürdig.....

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:
> Zur Tastenwiederholung bei NEC.
>
> Der Receiver reagiert garnicht.

Kannst Du mir Scan-Dateien zukommen lassen? Die Tasten 0-9 würden 
reichen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Gerade mal die Timings und Zählervariablen auf 16Bit verbreitert. Bis
> auf Denon funktioniert wieder alles bei 15kHz. Mehrverbrauch etwa 1kByte
> Flash.

Ich habe gerade mal stichprobenweise einige der mir vorliegenden 
Scan-Dateien mit dem Editor von 10kHz auf 15kHz "gestreckt", indem ich 
immer 00 durch 000 und 11 durch 111 ersetzt habe. Dann IRMP mit 15kHz 
unter Linux übersetzt und gegen die Scan-Dateien laufen lassen.

Ergebnis: überhaupt kein Problem, alle Scans wurden einwandfrei erkannt 
und dekodiert. Das NEC-Protokoll lief bei mir sogar noch bei 20kHz 
korrekt (mit entsprechend gestreckten Scan-Dateien).

Allerdings habe ich beim 20kHz-Test dann auch vom Compiler Warnungen 
bzgl. IRMP_TIMEOUT_LEN bekommen. Das läuft über ab 15425 Hz:
#define IRMP_TIMEOUT_TIME                       16500.0e-6                    // timeout after 16.5 ms darkness
#define IRMP_TIMEOUT_LEN                        (uint8_t)(F_INTERRUPTS * IRMP_TIMEOUT_TIME + 0.5)

F_INTERRUPTS darf also durchaus zwischen den Werten 10000 und 15000 
liegen.

Das Problem bei Dir muss woanders liegen. Ein Grund könnte sein, dass 
bei 15kHz der Time-Slot für die 15kHz-ISR zu eng wird, d.h. also 
Interrupts verlorengehen. Dagegen spricht, dass das Siemens-Protokoll 
immer noch korrekt erkannt wird. Ausserdem dürfte Deine 16-Bit-Version 
das Laufzeitverhalten noch weiter verschlimmern. Hattest Du vielleicht 
bei der 8-Bit-Version und F_INTERRUPTS = 15kHz noch das IRMP_LOGGING 
aktiviert? Das kostet natürlich auch noch einiges an Zeit.

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
ähm, ja, eigentlich schon.
Muß ich dann nur die Zeile
#define IRMP_LOGGING                            0 
// 1: log IR signal (scan), 0: do not (default)
verändern in #define IRMP_LOGGING                            1 
// 1: log IR signal (scan), 0: do not (default)

Und dann den Empfäng mit Hterm pro Taste Speichern ?
oder kannst Du mit vielleicht die fertige Hex mailen ?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:
> ähm, ja, eigentlich schon.
> Muß ich dann nur die Zeile
> #define IRMP_LOGGING                            0
> // 1: log IR signal (scan), 0: do not (default)
> verändern in #define IRMP_LOGGING                            1
> // 1: log IR signal (scan), 0: do not (default)
>
> Und dann den Empfäng mit Hterm pro Taste Speichern ?

Ja, genau, siehe auch IRMP-Artikel.

Am besten schreibst Du dann am Schluss noch jeweils einen Kommentar vor 
jede Zeile, eingeleitet mit '#', z.B.

# Taste 1
0000011100000....

Gruß,

Frank

von Torsten K. (nobby)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, da ist dann mal der Scan von der FB mit NEC Protokoll.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:
> So, da ist dann mal der Scan von der FB mit NEC Protokoll.

Danke, habe es mir angeschaut, bei jeder Taste wird nicht nur der 
normale NEC-Protokoll-Frame geschickt, sondern immer auch zusätzlich 
noch ein Repetition-Frame. Da ich annehme, dass Du die Tasten (bis auf 
Taste 1) immer nur kurz gedrückt hast, will Dein Empfänger wohl auch 
immer den Repetition-Frame "sehen", bevor er reagiert.

Ich werde in den IRSND einbauen, dass man über das Setzen eines Flags 
genau dieses (atypische) Verhalten reproduzieren kann.

Vielen Dank für den Scan,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Oh, so eine Anpassung wäre ja Klasse, aber es würde ja auch erstmal eine 
"Testversion" reichen, vielleicht liegt es ja doch noch an was anderem.

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:
> Oh, so eine Anpassung wäre ja Klasse, aber es würde ja auch erstmal eine
> "Testversion" reichen, vielleicht liegt es ja doch noch an was anderem.

Ich dachte auch an eine "Testversion", nur war die mal nicht eben in 5 
Minuten zusammengehackt ;-)

Ich habe nun irsnd folgendermaßen erweitert, dass irmp_data.flags die 
Anzahl der Tasten-Wiederholungen angibt, also:

flags = 0: Normales Senden des Frames - wie bisher
flags = 1: 1-malige Wiederholung
flags = 2: 2-malige Wiederhulung
usw.

Dabei gelten folgende Besonderheiten:

Bei SIRCS werden sowieso immer 3 Frames gesandt - so erfordert es das 
Protokoll. Bei flags = 1 werden dann daraus 4 Frames, bei flags = 2 dann 
5 Frames usw.

Bei NEC werden die Wiederholungen als Repetition-Frames gesandt, also 
nicht der komplette Frame n-mal wiederholt.

Für Grundig und Nokia werden im Moment noch alle Pakete (welche aus 3 
Frames bestehen, nämlich Start-Frame + Info-Frame + Stop-Frame) n-malig 
wiederholt, also nicht nur der Info-Frame, wie es sein soll. Da muss ich 
noch nacharbeiten.

Bei allen anderen Protokollen wird einfach der Original-Frame n-mal 
wiederholt, mit entweder (mir) bekannten Pause-Zeiten zwischen den 
Frames oder mit der (von mir willkürlich gewählten) Pause-Zeit von 
45msec.

Um nun Dein Problem mit dem Skymaster-Empfänger zu lösen, musst Du vor 
dem Aufruf von irsnd_send_data() einfach irmp_data.flags = 1 setzen. 
Dann wird erst der Original-Frame gesandt, anschließend eine Pause von 
40ms gemacht und letztendlich der Repetition-Frame gesandt.

Im Anhang die Testversion.

Viel Glück!

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

erstmal vielen Dank für die schnelle Anpassung !!

Das Problem lag aber an einer anderen Stelle, manchmal kann es so 
einfach sein.
Nachdem ich den Receiver auseinander geschraubt hatte, und direkt am 
Empfänger gemessen habe, ist mir noch eine andere Idee eingefallen.

Diese neue Atmelgeneration hat ja einen elendigen Jitter vom RC 
Oszilator, daher habe ich mal einen 8mHz Quarz an den Prozessor gelötet, 
und schon hat es sofort funktioniert !!
Auch das einfache Senden des NEC-Codes, auch ohne Wiederholung hat 
gereicht !!
Ich denke aber, diese Fähigkeit der Wiederholungseinstellung sollte 
erhalten bleiben, denn das könnte vielleicht auch mal in anderen Fällen 
zu gebrauchen sein.

Ich werde jetzt mal an die Schaltung von Klaus auch einen Quarz hängen, 
da nämlich der RC5 Code bei mir nicht immer gut erkannt wird.

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:

> Diese neue Atmelgeneration hat ja einen elendigen Jitter vom RC
> Oszilator, daher habe ich mal einen 8mHz Quarz an den Prozessor gelötet,
> und schon hat es sofort funktioniert !!

Danke für die Rückmeldung :-)

> Auch das einfache Senden des NEC-Codes, auch ohne Wiederholung hat
> gereicht !!

Prima.

> Ich denke aber, diese Fähigkeit der Wiederholungseinstellung sollte
> erhalten bleiben, denn das könnte vielleicht auch mal in anderen Fällen
> zu gebrauchen sein.

Ja, auf jeden Fall, damit kann man dann direkt ein Kommando n-fach 
schicken, was durchaus sinnvoll sein kann, z.B. zur Regelung von 
Lautstärken oder Helligkeiten etc.

> Ich werde jetzt mal an die Schaltung von Klaus auch einen Quarz hängen,
> da nämlich der RC5 Code bei mir nicht immer gut erkannt wird.

Ich werde im IRMP-Artikel entsprechend vermerken, dass die ganze 
Geschichte mit Quarz um einiges stabiler ist.

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Dann kannst Du vielleicht auch mal auf diese Seite verlinken:
http://www.scienceprog.com/avr-internal-oscillator-jitter-research/
Da sind ein paar erschreckende Bilder zu sehen !

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:
> Hallo Frank,
>
> Ich werde jetzt mal an die Schaltung von Klaus auch einen Quarz hängen,
> da nämlich der RC5 Code bei mir nicht immer gut erkannt wird.
>
Hallo Torsten,
die Xtal Pins sind in meiner Schaltung leider für das LCD benutzt (wegen 
Kompatibilität mit Codevision). Für GCC kann die Pinbelegung natürlich 
auch einfach geändert werden. Ein Kalibrieren des Oszillators würde 
vielleicht auch helfen?

Gruß,
Klaus

von Torsten K. (nobby)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte den mit dem internen Wert calibriert, das hat aber nicht 
geholfen.
Das bringt auch nichts, wenn der am Jittern ist. Der Mega8 ist da noch 
gut, der Mega48/88/168 ist total am Jittern, wenn das dann bei der 
Signalgenerierung passiert, könnte ich mir gut vorstellen, das da 
vielleicht ein paar Bits nicht mehr erkannt werden ??
Ich hab hier das dazu passende Mesbild mal angehängt, Quelle dazu ist:
http://www.scienceprog.com/avr-internal-oscillator-jitter-research/

Sagt mal, hat schon jemand das Protokol einer Siku Controll angeschaut. 
Das ist eine Infrarot Fernbedienung für Modellauutos, wird gerner im 
1/87 bereich benutzt. Das läuft allerdings mit 455khz und ist ständig am 
senden.

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Version 1.5.0 von IRMP verfügbar, Download unter

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

Änderungen:

 - Neues Protokoll: SIEMENS (Gigaset)

Ebenso ist nun die Version 1.5.0 von IRSND verfügbar, Download unter

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

Änderungen:

 - Neues Protokoll: Siemens (Gigaset)
 - Simulation von langen Tastendrücken durch Angabe von Wiederholungen
   in der Variablen irmp_data.flags.

irmp_data_p.flags gibt die Anzahl der Wiederholungen an, z.B.

 irmp_data_p.flags = 0: Verhalten wie bisher
 irmp_data_p.flags = 1: 1 Wiederholung, d.h. Ausgabe von 2 Frames
 irmp_data_p.flags = 2: 2 Wiederholungen, d.h. Ausgabe von 3 Frames
 usw.

Sind Wiederholungen angegeben, wird entweder der Frame nach einer Pause 
(protokollabhängig) neu ausgegeben oder ein protkollspezifischer 
Wiederholungsframe (z.B. für NEC) gesendet.

ZU BEACHTEN:

Da bisher irmp_data_p.flags von IRSND nicht ausgewertet wurde, ist 
unbedingt ab Version 1.5.0 darauf zu achten, dass irmp_data_p.flags vor 
dem Aufruf von irsnd_send_data() einen definierten Wert hat!

Viel Spaß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Frank M. schrieb:
> Das Problem bei Dir muss woanders liegen. Ein Grund könnte sein, dass
> bei 15kHz der Time-Slot für die 15kHz-ISR zu eng wird, d.h. also
> Interrupts verlorengehen. Dagegen spricht, dass das Siemens-Protokoll
> immer noch korrekt erkannt wird. Ausserdem dürfte Deine 16-Bit-Version
> das Laufzeitverhalten noch weiter verschlimmern. Hattest Du vielleicht
> bei der 8-Bit-Version und F_INTERRUPTS = 15kHz noch das IRMP_LOGGING
> aktiviert? Das kostet natürlich auch noch einiges an Zeit.


Ich bin am verzweifeln. Nutze Timer0 eines Mega32 als freilaufende 
Zähler (gemäß Peter Danegger) für die 15kHz-Interruptquelle. Will 
einfach nicht funktionieren. An der Interrupthäufigkeit kann es 
eigentlich nicht liegen.
Hast Du noch 'ne Idee, wo ich suchen könnte?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

> Ich bin am verzweifeln. Nutze Timer0 eines Mega32 als freilaufende
> Zähler (gemäß Peter Danegger) für die 15kHz-Interruptquelle. Will
> einfach nicht funktionieren. An der Interrupthäufigkeit kann es
> eigentlich nicht liegen.

Es ist also weiterhin so, dass bei 15kHz nur das Siemens-Protokoll 
funktioniert? Die anderen nur bei Verbreiterung der Zählervariablen auf 
16 Bit?

Zeigst Du mal Deine Timer-(Initialisierungs-)Routinen?

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Zeigst Du mal Deine Timer-(Initialisierungs-)Routinen?
#define IR_HZ          15000    /* interrupts per second */

#define MAX_OVERFLOW   255UL
#if (F_CPU/IR_HZ) < MAX_OVERFLOW
#define HW_PRESCALER   1UL
#define HW_PRESCALER_MASK  _BV(CS00)
#elif (F_CPU/IR_HZ/8) < MAX_OVERFLOW
#define HW_PRESCALER   8UL
#define HW_PRESCALER_MASK  _BV(CS01)
#elif (F_CPU/IR_HZ/64) < MAX_OVERFLOW
#define HW_PRESCALER   64UL
#define HW_PRESCALER_MASK  _BV(CS01)|_BV(CS00)
#elif (F_CPU/IR_HZ/256) < MAX_OVERFLOW
#define HW_PRESCALER   256UL
#define HW_PRESCALER_MASK  _BV(CS02)
#elif (F_CPU/IR_HZ/1024) < MAX_OVERFLOW
#define HW_PRESCALER   1024UL
#define HW_PRESCALER_MASK  _BV(CS02)|_BV(CS00)
#else
#error F_CPU to large
#endif
#define SW_PRESCALER   ((F_CPU/HW_PRESCALER)/IR_HZ)

static uint16_t prescaler;

init()
{
  /* init timer0 to expire after 1000/IR_HZ ms */
  TCCR0 = HW_PRESCALER_MASK;
  OCR0 = SW_PRESCALER - 1;
  TCNT0 = 0;
  prescaler = (uint16_t) IR_HZ;

  /* enable interrupt */
  TIMSK |= _BV (OCIE0);
}

ISR (TIMER0_COMP_vect)
{
  uint8_t data = PIN (IR_RX_PORT) & _BV (IR_RX_PIN);

  if (data == IR_RX_MARK)
    IR_RX_LED_ON; /* Kontroll-LED */
  else
    IR_RX_LED_OFF;

  ir_rx_process (data);

  if (--prescaler == 0)
    prescaler = (uint16_t) IR_HZ;
#if (F_CPU/HW_PRESCALER) % IR_HZ
  if (prescaler <= (F_CPU / HW_PRESCALER) % IR_HZ)
    OCR0 += SW_PRESCALER + 1;   /* um 1 Takt längere Periode um
                                   den Rest abzutragen */
  else
#endif
    OCR0 += SW_PRESCALER;       /* kurze Periode */
}

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> #define IR_HZ          15000    /* interrupts per second */

Ich verstehe nicht, warum Du es Dir so schwer machst. Du musst nicht 
genau auf 15000 Hz kommen, es ist nur wichtig, dass F_INTERRUPTS exakt 
ist. Wenn
also für ein bestimmtes TCCR0 und OCR0 etwa 14750 Hz rauskommen, dann 
stellst Du halt F_INTERRUPTS auf 14750 und gut ist.
> #error F_CPU to large

Ohne die Angabe von F_CPU sind die Preprocessor-Makros für mich schlecht 
nachvollziehbar. Sind es 8MHz mit internem Oszillator?
  ir_rx_process (data);

Was ist ir_rx_process()? Entspricht das der ISR vom IRMP? Ich vermute, 
Du hast soviel im Source umgebaut, dass es vielleicht deshalb nicht mehr 
funktioniert.

Ausserdem hast Du meine beiden Fragen nicht beantwortet, hier nochmal:

Es ist also weiterhin so, dass bei 15kHz nur das Siemens-Protokoll
funktioniert? Die anderen nur bei Verbreiterung der Zählervariablen auf
16 Bit?

Also:

A. Berechne einfach geeignete Werte für TCCR0 und OCR0, so dass das
   Ergebnis möglichst knapp unter 15000 ist.

B. Setze F_INTERRUPTS auf den exakten berechneten Wert.

C. Rufe in ISR(TIMER0_COMP_vect) einfach nur irmp_ISR() auf


Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> eku schrieb:
>> #define IR_HZ          15000    /* interrupts per second */
>
> Ich verstehe nicht, warum Du es Dir so schwer machst. Du musst nicht
> genau auf 15000 Hz kommen, es ist nur wichtig, dass F_INTERRUPTS exakt
> ist. Wenn also für ein bestimmtes TCCR0 und OCR0 etwa 14750 Hz
> rauskommen, dann stellst Du halt F_INTERRUPTS auf 14750 und gut ist.
>> #error F_CPU to large

Mein AVR soll neben IRMP noch andere Aufgaben erfüllen, mit nur einer
ISR. Warum soll ich Werte selbst berechnen, wenn es der Präprozessor 
übernimmt.

> Ohne die Angabe von F_CPU sind die Preprocessor-Makros für mich
> schlecht nachvollziehbar. Sind es 8MHz mit internem Oszillator?

16MHz Quarz

>   ir_rx_process (data);
>
> Was ist ir_rx_process()? Entspricht das der ISR vom IRMP? Ich vermute,
> Du hast soviel im Source umgebaut, dass es vielleicht deshalb nicht
> mehr funktioniert.

Nö, ich habe IRMP und IRSND in eine Bibliothek gepackt. Den eingelesenen 
Wert gebe ich an irmp_ISR(). Ansonsten habe ich nichts verändert.

> Ausserdem hast Du meine beiden Fragen nicht beantwortet, hier nochmal:
>
> Es ist also weiterhin so, dass bei 15kHz nur das Siemens-Protokoll
> funktioniert? Die anderen nur bei Verbreiterung der Zählervariablen
> auf 16 Bit?

Ja, bis auf Denon funktionieren die anderen Protokolle mit 15kHz und 
16Bit-Zählern.

> Also:
>
> A. Berechne einfach geeignete Werte für TCCR0 und OCR0, so dass das
>    Ergebnis möglichst knapp unter 15000 ist.
>
> B. Setze F_INTERRUPTS auf den exakten berechneten Wert.
>
> C. Rufe in ISR(TIMER0_COMP_vect) einfach nur irmp_ISR() auf

Probeweise werde ich das mal so machen. Mittelfristig soll IRMP/IRSND 
aber im Kontext meiner Anwendung für den AVR laufen. Ich stelle mir das 
als Modul für Ethersex auf einem Pollin Net-IO vor. Kommando- und 
Webinterface zur Fernbedienung der HiFi-Geräte.

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> A. Berechne einfach geeignete Werte für TCCR0 und OCR0, so dass das
>    Ergebnis möglichst knapp unter 15000 ist.
>
> B. Setze F_INTERRUPTS auf den exakten berechneten Wert.

F_INTERUPTS=16000000/8/133=15037

Siemens, Nokia, RCx, Nec, Grundig gehen, nur Denon nicht. Hilft ein 
IRMP_LOGGING zur Analyse?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Siemens, Nokia, RCx, Nec, Grundig gehen

Auch mit 8-Bit-Zählern? Freut mich.

> nur Denon nicht. Hilft ein IRMP_LOGGING zur Analyse?

Ja.

Gruß,

Frank

von eku (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>> Siemens, Nokia, RCx, Nec, Grundig gehen
>
> Auch mit 8-Bit-Zählern? Freut mich.

Ja. Mit 20kHz läuft dann aber der Pausenzähler über. Bemerkt schon der 
Compiler

>> nur Denon nicht. Hilft ein IRMP_LOGGING zur Analyse?
>
> Ja.

Anbei. Diesmal habe ich die bei 10kHz dekodierten Codes vor die Sequenz 
geschrieben. Hoffe das hilft. Bei 20kHz wird es mit Denon nicht besser. 
Ich hatte zu8nächste Rundungsfehler bei den Konstanten (10kHz +50%) in 
Verdacht, aber die Verdoppelung macht es nicht besser.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Ja. Mit 20kHz läuft dann aber der Pausenzähler über. Bemerkt schon der
> Compiler

Gut, das habe ich auch erwartet.

> Anbei. Diesmal habe ich die bei 10kHz dekodierten Codes vor die Sequenz
> geschrieben. Hoffe das hilft. Bei 20kHz wird es mit Denon nicht besser.

Ersetze in irmp.c die Zeile
#define DENON_1_PAUSE_LEN_MIN                   ((uint8_t)(F_INTERRUPTS * DENON_1_PAUSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)

durch
#define DENON_1_PAUSE_LEN_MIN                   ((uint8_t)(F_INTERRUPTS * DENON_1_PAUSE_TIME * MIN_TOLERANCE_30 + 0.5) - 1)

Dann geht es.

Gruß,

Frank

von eku (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Frank M. schrieb:
> Ersetze in irmp.c die Zeile

Geht. Pefekt. Ich hoffe, auch den Sendeteil bald testen zu können.

PS: Es kommt keine Warnung wenn, Siemens mit 10kHz compiliert wird.

PS2: Einen hab' ich noch :-) Siehe Anhang. Ist eine IR-Tastatur aus 
China (Pollin 711 056). IRMP dekodiert bei 15kHz RCx + Siemens je Taste.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Geht. Pefekt. Ich hoffe, auch den Sendeteil bald testen zu können.

Na slso.

> PS: Es kommt keine Warnung wenn, Siemens mit 10kHz compiliert wird.

Das verstehe ich nicht. Wann kommt denn eine Warnung? Die Aussage, wann 
keine Warnung kommt, hilft mir nicht weiter. Redest Du von IRMP oder 
IRSND?

Am besten zeigst Du mal den Compiler-Output.

> PS2: Einen hab' ich noch :-) Siehe Anhang. Ist eine IR-Tastatur aus
> China (Pollin 711 056). IRMP dekodiert bei 15kHz RCx + Siemens je Taste.

Ein 42-Bit-Protokoll, keine Ahnung, was das sein soll. Aber relativ 
einfach zu dekodieren - allerdings nicht mehr bei 10 kHz. Ich schaue mir 
das mal näher an.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> eku schrieb:
>> PS2: Einen hab' ich noch :-) Siehe Anhang. Ist eine IR-Tastatur aus
>> China (Pollin 711 056). IRMP dekodiert bei 15kHz RCx + Siemens je Taste.
>
> Ein 42-Bit-Protokoll, keine Ahnung, was das sein soll. Aber relativ
> einfach zu dekodieren - allerdings nicht mehr bei 10 kHz. Ich schaue mir
> das mal näher an.

Habe das Protokoll soweit dekodiert. Von den insgesamt 42 Bits (1 
Start-Bit, 40 Daten-Bits, 1 Stop-Bit) werden nur effektiv 12 Bits 
genutzt. Anbei eine Testversion. Nette Geschichte, damit kann man eine 
PC-Tastatur einfach an einen µC anbinden.

Wäre klasse, wenn Du mal sämtliche Tasten scannen könntest, ich habe 
noch nicht entscheiden können, ob das Protokoll mit LSB- oder MSB-first 
funktioniert. Meine Vermutung ist LSB-first, aber richtig kann man das 
erst erkennen, wenn sämtliche Tasten der Matrix (es sieht nach einem 
Matrix-Code aus) bekannt ist.

Auf jeden Fall bestelle ich mir mal ein paar von den Dingern. Bei 1,95 
EUR ist das ja kein großes Risiko ;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Ersetze in irmp.c die Zeile
> #define DENON_1_PAUSE_LEN_MIN     ((uint8_t)(F_INTERRUPTS * DENON_1_PAUSE_TIME * MIN_TOLERANCE_20 + 0.5) - 1)
> durch
> #define DENON_1_PAUSE_LEN_MIN     ((uint8_t)(F_INTERRUPTS * DENON_1_PAUSE_TIME * MIN_TOLERANCE_30 + 0.5) - 1)
> Dann geht es.

Nach nochmaligem Studium von

   http://www.mikrocontroller.com/de/IR-Protokolle.php#DENON

habe ich festgestellt, dass die obige Lösung den Fehler nur vertuscht 
hat. In Wirklichkeit ist der Timing-Wert in irmp.h
#define DENON_0_PAUSE_TIME                       1050.0e-6                      //  1050 usec pause

falsch. Es muss heissen:
#define DENON_0_PAUSE_TIME                       775.0e-6                       //  775 usec pause

Dann kann man den Toleranzwert für DENON_1_PAUSE_LEN_MIN wieder auf 20 
Prozent zurückschrauben, also die obige Änderung in irmp.c wieder 
rückgängig machen, denn die Abweichungen der Denon-FB von den 
Idealwerten sind dann wieder wesentlich geringer.

Sorry, mein Fehler. Werde ich im nächsten Release berücksichtigen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Version 1.6.0 von IRMP verfügbar, Download unter

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

Änderungen:

 - Neues Protokoll: FDC (IR keyboard)
 - Timings vom DENON-Protokoll korrigiert

Ebenso ist nun die Version 1.5.0 von IRSND verfügbar, Download unter

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

Änderungen:

 - Neues Protokoll: FDC (IR keyboard)
 - Timings vom DENON-Protokoll korrigiert

Damit kann man nun die bei Pollin erhältliche Infrarot-Tastatur FDC-3402 
(Bestellnr. 711 056) auch am µC nutzen.

Achtung:

Die Protokolle SIEMENS und FDC werden sowohl für IRMP als auch für IRSND 
beim Compilieren automatisch abgeschaltet, wenn F_INTERRUPTS kleiner als 
14500 Hz ist. Grund: Die Erkennung bei niedrigeren Scan-Raten ist nicht 
stabil.

Das ganze erkennt man in irmpconfig.h an folgendem Block:
/*--------------------------------------------------------------------------------------------------------------
 * Change settings from 1 to 0 if you want to disable one or more decoders.
 * This saves program space.
 * 1 enable  decoder
 * 0 disable decoder
 *---------------------------------------------------------------------------------------------------------------
 */
#define IRMP_SUPPORT_SIRCS_PROTOCOL             1       // flag: support SIRCS                 uses ~100 bytes
#define IRMP_SUPPORT_NEC_PROTOCOL               1       // flag: support NEC + APPLE           uses ~250 bytes
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL           1       // flag: support Samsung + Samsung32   uses ~250 bytes
#define IRMP_SUPPORT_MATSUSHITA_PROTOCOL        1       // flag: support Matsushita            uses  ~50 bytes
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL          1       // flag: support Kaseikyo              uses  ~50 bytes
#define IRMP_SUPPORT_RECS80_PROTOCOL            1       // flag: support RECS80                uses  ~50 bytes
#define IRMP_SUPPORT_RC5_PROTOCOL               1       // flag: support RC5                   uses ~250 bytes
#define IRMP_SUPPORT_DENON_PROTOCOL             1       // flag: support DENON                 uses ~250 bytes
#define IRMP_SUPPORT_RC6_PROTOCOL               1       // flag: support RC6                   uses ~200 bytes
#define IRMP_SUPPORT_RECS80EXT_PROTOCOL         1       // flag: support RECS80EXT             uses  ~50 bytes
#define IRMP_SUPPORT_NUBERT_PROTOCOL            1       // flag: support NUBERT                uses  ~50 bytes
#define IRMP_SUPPORT_BANG_OLUFSEN_PROTOCOL      1       // flag: support Bang & Olufsen        uses ~200 bytes
#define IRMP_SUPPORT_GRUNDIG_PROTOCOL           1       // flag: support Grundig               uses ~150 bytes
#define IRMP_SUPPORT_NOKIA_PROTOCOL             1       // flag: support Nokia                 uses ~150 bytes

/*--------------------------------------------------------------------------------------------------------------
 * THE FOLLOWING DECODERS WORK ONLY FOR F_INTERRUPTS > 14500!
 *---------------------------------------------------------------------------------------------------------------
 */
#if F_INTERRUPTS >= 14500
#define IRMP_SUPPORT_SIEMENS_PROTOCOL           1       // flag: support Siemens Gigaset       uses ~150 bytes
#define IRMP_SUPPORT_FDC_PROTOCOL               1       // flag: support FDC keyboard          uses ~150 bytes
#else
#define IRMP_SUPPORT_SIEMENS_PROTOCOL           0       // DO NOT CHANGE! F_INTERRUPTS too low!
#define IRMP_SUPPORT_FDC_PROTOCOL               0       // DO NOT CHANGE! F_INTERRUPTS too low!
#endif

Analoges gilt für irsndconfig.h.

Den IRMP-Artikel habe ich an den entsprechenden Stellen angepasst.

@Hugo Portisch:

Warte bitte noch ein wenig mit der Umsetzung auf die V-USB-Version, ich 
schätze, dass ich bzgl. des FDC-Protokolls noch etwas anpassen muss.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Vielen Danke für die prompte Reaktion. Ich komme erst am Abend zum 
Testen.

Ich hätte da noch ein paar Änderungswünsche für IRMP um mir dsa Patchen 
der Quellen zu ersparen:
Index: irmpconfig.h
===================================================================
--- irmpconfig.h        (Revision 21)
+++ irmpconfig.h        (Arbeitskopie)
@@ -81,6 +81,8 @@
  * Set IRMP_LOGGING to 1 if want to log data to UART with 9600Bd^M
  *---------------------------------------------------------------------------------------------------------------------------------------------------^M
  */^M
+#ifndef IRMP_LOGGING^M
 #define IRMP_LOGGING                            0                             // 1: log IR signal (scan), 0: do not (default)^M
+#endif^M
 ^M
 #endif /* _WC_IRMPCONFIG_H_ */^M

Der UART-Code kompoliert nicht auf einem Mega32. Die Registernamen 
enthalten keine Null ('0'). Die Initialisierung der Baudrate besser wie 
folgt (Mega32, andere Registernamen anpassen):
#define BAUD UART_BAUD
#include <util/setbaud.h>

  UBRRH = UBRRH_VALUE;          /* set baud rate */
  UBRRL = UBRRL_VALUE;
#if USE_2X
  UCSRA = _BV (U2X);
#else
  UCSRA = 0;
#endif
#ifdef URSEL
  UCSRC = _BV (UCSZ1) ^ _BV (UCSZ0) ^_BV (URSEL);
#else
  UCSRC = _BV (UCSZ1) ^ _BV (UCSZ0);    /* 8 Bit */
#endif
  UCSRB = _BV (TXEN);           /* enable TX */

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Ich hätte da noch ein paar Änderungswünsche für IRMP um mir dsa Patchen
> der Quellen zu ersparen:

Ich habe Deine Änderungswünsche eingearbeitet und bei der Gelegenheit 
die UART-Register bzw. -Kontanten portabel definiert, so dass das 
Übersetzen nun auf jedem ATMEGA funktionieren sollte.

Kommt dann im nächsten Release.

Gruß,

Frank

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
>>@Hugo Portisch:

>>Warte bitte noch ein wenig mit der Umsetzung auf die V-USB-Version, ich
>>schätze, dass ich bzgl. des FDC-Protokolls noch etwas anpassen muss.

Ok, danke für die Info!

Wie sieht denn dann der empfange Code der FDC aus?
Also als IRMP_DATA Struct?

Stehen in Command dann die ASCII Werte?
Was für Werte hat z.B. die Windows Taste, STRG, Alt,...

Entsprechen diese dieser Liste:
http://msdn.microsoft.com/en-us/library/ms645540.aspx

Bitte 1-2 Beispiele als irmp_data posten damit ich das sehen kann. 
Danke!

Ich hätte nähmlich die Idee, wenn das FDC Protokoll empfangen wird dies 
direkt von der DLL in Tastendrücke umzuwandeln damit es wie eine 
"normale" Tastatur funktioniert.

Da bin ich einmal gespannt. Beim letzten Protokoll (Siemens) waren nur 
mehr 98 Bytes von meinem Atmega8 frei (8k - 2k Bootloader). Jetzt wird 
es schon happig alle Protokolle mit hineinzupacken...

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hugo Portisch schrieb:
> Wie sieht denn dann der empfange Code der FDC aus?
> Also als IRMP_DATA Struct?
>
> Stehen in Command dann die ASCII Werte?
> Was für Werte hat z.B. die Windows Taste, STRG, Alt,...

Eher nicht. Bislang ist noch unklar, ob fürs Drücken und Loslassen 
getrennte Codes gesendert werden.

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
>>Eher nicht. Bislang ist noch unklar, ob fürs Drücken und Loslassen
>>getrennte Codes gesendert werden.

Auch wär interressant wie es dann mit mehreren Tastendrücke aussieht. 
Also z.B. STRG-C, WIN-D, SHIFT-A, STRG-ALT-ENTF,....

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hugo Portisch schrieb:

> Wie sieht denn dann der empfange Code der FDC aus?
> Also als IRMP_DATA Struct?

Ich habe mal den Output vom IRMP unter Linux angehängt.

> Stehen in Command dann die ASCII Werte?
> Was für Werte hat z.B. die Windows Taste, STRG, Alt,...

Nein, für mich sieht das wie ein Matrix-Code aus, halt so, wie die 
Tastatur verdrahtet ist. Vielleicht kannst Du ja mehr damit anfangen.

Im Moment werte ich die Bits 0-15 als Adresse, die Bits 25-36 als 
Kommando aus. Wenn man sich den Scan der FDC-Tastatur im Detail (siehe 
irmp-fdc-detail.txt) anschaut, dann sieht man, dass bei der 
"Wiederholung" sich in den Bits 20-24 etwas ändert. Ob das jetzt ein 
Repetition-Code ist, der durch längeres Drücken entstanden ist, oder 
tatsächlich die Zustände "Drücken" und "Loslassen" beschreibt, weiss ich 
noch nicht. Dazu habe ich noch zu wenig Infos.

> Ich hätte nähmlich die Idee, wenn das FDC Protokoll empfangen wird dies
> direkt von der DLL in Tastendrücke umzuwandeln damit es wie eine
> "normale" Tastatur funktioniert.

Jau :-)

Eher noch interessanter finde ich, einen µC einfachst mit einer 
kompletten PC-Tastatur auszustatten - für die Bedienung von Menüs, 
Konfigurationen etc.

> Da bin ich einmal gespannt. Beim letzten Protokoll (Siemens) waren nur
> mehr 98 Bytes von meinem Atmega8 frei (8k - 2k Bootloader). Jetzt wird
> es schon happig alle Protokolle mit hineinzupacken...

Das wird knapp.

Ich sehe da aber noch Einsparungspotential. Durch geeignete 
Parametrisierung könnte ich die Behandlung der Manchester-basierten 
Protokolle (Bi-Phase) für RC5, RC6, GRUNDIG, NOKIA und SIEMENS noch 
weiter zusammenfassen und dadurch Code einsparen. Könnte dann aber etwas 
CPU-intensiver werden.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier nochmal eine kompaktere Darstellung, siehe Anhang. Sehr schön sieht 
man hier, dass die 4 Bits 20-23 in der Wiederholung von 0 auf 1 
wechseln.

Entweder ist das ein "Loslassen"-Flag oder das Zeichen für eine 
Wiederholung. Das müsste eku mal systematisch testen - durch kurze und 
lange Tastendrücke.

Da bei einigen Tasten der zweite Frame fehlt, nehme ich mal an, dass eku 
hier die jeweilige Taste nur kurz gedrückt hat. Damit wären die 4 
1er-Bits ein Zeichen für die Wiederholung, nicht das Loslassen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Nein, für mich sieht das wie ein Matrix-Code aus, halt so, wie die
> Tastatur verdrahtet ist. Vielleicht kannst Du ja mehr damit anfangen.

Es ist definitiv ein Matrix-Code, ich habe mal die mir zur Verfügung 
stehenden Tasten-Scans bitweise gruppiert:
# 1
  ADRESSE        ??????   REPEAT ?????    SPALTE  ZEILE  ?
11111100000000   000000   0000   010000    00101  1111   1
11111100000000   000000   1111   010000    00101  1111   1
-------------------------------------------------------------------
# 2
11111100000000   000000   0000   110000    00001  1111   1
11111100000000   000000   1111   110000    00001  1111   1
-------------------------------------------------------------------
# 3
11111100000000   000000   0000   001000    00110  1111   1
11111100000000   000000   1111   001000    00110  1111   1

Dann ergibt sich folgende Matrix, die genau zu obigem Schema passt:

         Spalte   Spalte   Spalte   Spalte   Spalte   Spalte   Spalte             Spalte   Spalte   Spalte   Spalte
          00011    00101    00001    00110    00010    00100    00000              00111    00011    00101    00001
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+
       +        +        +        +        +        +        +        +         +        +        +        +        +        +        +
 ZEILE +        +   1    +   2    +   3    +   4    +   5    +   6    +   ZEILE +    7   +    8   +    9   +   0    +        +        +
  1111 +        +        +        +        +        +        +        +    0111 +        +        +        +        +        +        +
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+
         Spalte   Spalte   Spalte   Spalte   Spalte   Spalte   Spalte             Spalte   Spalte   Spalte   Spalte
          00011    00101    00001    00110    00010    00100    00000              00111    00011    00101    00001
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+
       +        +        +        +        +        +        +        +         +        +        +        +        +        +        +
 ZEILE +   Q    +   W    +   E    +   R    +   T    +   Z    +   U    +   ZEILE +    I   +    O   +    P   +        +        +        +
  1011 +        +        +        +        +        +        +        +    0011 +        +        +        +        +        +        +
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+
         Spalte   Spalte   Spalte   Spalte   Spalte   Spalte   Spalte             Spalte   Spalte   Spalte   Spalte
          00011    00101    00001    00110    00010    00100    00000              00111    00011    00101    00001
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+
       +        +        +        +        + LEER   +        +        +         +        +        +        +        +        +        +
 ZEILE +        +        +        +        + TASTE  +        +        +   ZEILE +        +        +        +        +        +        +
  0001 +        +        +        +        +        +        +        +    ???? +        +        +        +        +        +        +
       +--------+--------+--------+--------+--------+--------+--------+         +--------+--------+--------+--------+--------+--------+

Leider hat eku nur die Tasten 1234567890, qwertzuiop und die Leertaste 
gescannt. Bis dahin passt das Schema aber wie die Faust aufs Auge.

Fragt sich nur, was die Bits bedeuten, die ich mit Fragezeichen versehen 
habe. Vielelicht die Bits für STRG, ALT, SHIFT?

Bin gespannt auf mehr Input von eku.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Leider hat eku nur die Tasten 1234567890, qwertzuiop und die Leertaste
> gescannt. Bis dahin passt das Schema aber wie die Faust aufs Auge.

Nun sei doch nicht su ungeduldig :-) Kommt Zeit, kommt Scan :-)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Nun sei doch nicht su ungeduldig :-) Kommt Zeit, kommt Scan :-)

Och, lass mich doch... das ist spannender als Sudoku-Spielen ;-)

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bekomme leider mit der Pollin Tastatur immer nur RC5 oder Siemens 
Protokoll angezeigt. Bei mit läuft das ganze auf einem Mega 168 mit 8mHz 
Quarz.
Hab natürlich die Version 1.6 und den  F_INTERRUPTS auf 15000 gestellt.

Gruß
Torsten

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich habe Deine Änderungswünsche eingearbeitet und bei der Gelegenheit
> die UART-Register bzw. -Kontanten portabel definiert, so dass das
> Übersetzen nun auf jedem ATMEGA funktionieren sollte.
>
> Kommt dann im nächsten Release.

Ich nutze SVN und freue mich über jeden Commit. Ich brauche kein 
Release, Zwischenstand aus SVN reicht mit.

von Torsten K. (nobby)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab hier mal einen kleinen Scan von den Tasten 0 bis 9 eingestellt, 
vielleicht hilft das für eine kurze Analyse.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:
> Ich hab hier mal einen kleinen Scan von den Tasten 0 bis 9 eingestellt,
> vielleicht hilft das für eine kurze Analyse.

Deine Tastatur hat ein ganz anderes Timing.

Die Pulszeiten in Deinem Scan sind etwa doppelt so lang wie die bei eku. 
Ausserdem gibt es zwischendurch "Aussetzer", wo die Pulszeiten sogar auf 
die 4-fache Länge anwachsen.

Dagegen haben die Pause-Zeiten nur die Hälfte der Länge wie bei der 
Tastatur von eku - und das mit einer erheblichen Streuung.

Ein paar Fragen dazu:

1. Bist Du sicher, dass der Interrupt-Takt 15kHz und nicht mehr beträgt?

2. Welchen Timer benutzt Du?

3. Werden andere FBs bei 15kHz und 8MHz-Takt ohne Probleme erkannt?

4. Gab es Compiler-Warnungen?

5. Bist Du sicher, dass der Quarz auch genutzt wird und nicht nur der
   interne Oszillator läuft?

Vielleicht reicht auch bei der Vielzahl der mittlerweile unterstützten 
Protokolle und dem erhöhten Interrupt-Takt von 15kHz der Takt von 8MHz 
nicht mehr aus.

Schalte mal soviel wie möglich an Protokollen ab und teste dann nochmal.

Ich habe mir die Tastatur mittlerweile selbst bestellt, damit ich in den 
nächsten Tagen auch mal selbst testen kann.

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Na,

also was den Quarz angeht, das habe ich im AVR Studio so eingestellt, 
bzw. die Fuse so gesetzt.

Ob der Proz. wirklich den Interrupt-Takt 15kHz hat müßte ich mal 
nachschauen/messen.
Ich nutze den OCR1A.
Andere FBs mit 15kHz habe ich nicht.

Ich werde morgen mal nachmessen, ich kann auch den wirklichen Takt des 
IR Signals mal mit dem Scope nachmessen, dann sehen wir ja was los ist.

Gruß
Torsten

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Änderungswunsch für irmp_ISR(): return irmp_ir_detected;

Vorteil: nach Aufruf von irmp_ISR() weiß der Aufrufer sofort, ob eine 
Sequenz dekodiert wurde und muss nicht extra irmp_get_data() aufrufen. 
Konsequenterweise könnte der Test auf irmp_ir_detected in 
irmp_get_data() entfallen. "Geradeaus-" uns "Kasko-"Programmierer 
benötigen den Test.

Vergelcihe mit irsnd_ISR(): liefert irsnd_busy zurück. Die 
while-Schleife in irsnd_send_data() finde ich schlecht. Sowas regelt man 
über Return-Codes. Soll doch der Aufrufer entscheiden, wie er darauf 
reagiert.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Änderungswunsch für irmp_ISR(): return irmp_ir_detected;

Kann ich gerne einbauen. Ich selbst würde das aber nicht nutzen und auch 
nicht in Beispielen dokumentieren. Denn normalerweise wird irmp_ISR() 
aus einer Interrupt-Funktion aufgerufen... und diese ist 
definitionsgemäß void.

Okay, Du könntest Dir dann in der Applikation eine globale Variable 
setzen und dann irmp_get_data() gezielt aufrufen.

Aber wo ist der Unterschied? irmp_get_data() macht sofort einen return, 
wenn irmp_ir_detected == FALSE. Das einzige, was Du maximal sparst, ist 
ein Funktionsaufruf.

> Vorteil: nach Aufruf von irmp_ISR() weiß der Aufrufer sofort, ob eine
> Sequenz dekodiert wurde und muss nicht extra irmp_get_data() aufrufen.

Ich sehe da keinen Vorteil, sorry. Ich sehe da nur schlechten 
Programmierstil.

> Konsequenterweise könnte der Test auf irmp_ir_detected in
> irmp_get_data() entfallen.

Nein, werde ich auf keinen Fall rausnehmen, sonst muss der Programmierer 
genau das machen, was ich oben beschrieb: irmp_ISR() aufrufen, den 
Return-Wert in einer globalen Variablen speichern und in der 
main-Routine dann auf diese globale Variable testen.

Da ich mich schon seit 25 Jahren mit UNIX beschäftige, selbst auch schon 
einige Device-Treiber für UNIX und LINUX geschrieben habe, denke ich, 
dass mein Verfahren eher einem vernünftigen Interface entspricht.

> "Geradeaus-" uns "Kasko-"Programmierer benötigen den Test.

Was sind "Geradeaus-" uns "Kasko-"Programmierer? ;-)

Beschreibe bitte ein Szenario, wo das nötig ist. Das einzige, was Du mit 
Deinem Verfahren sparst, ist ein Funktionsaufruf aus Deiner 
Main-Routine.

> Vergelcihe mit irsnd_ISR(): liefert irsnd_busy zurück.

Ja, aber nur deshalb, damit man irmp_ISR() und irsnd_ISR() so 
kombinieren kann, dass sie sich nicht ins Gehege kommen, vergleiche dazu 
den IRMP-Artikel:

http://www.mikrocontroller.net/articles/IRMP#Source-Code_2

<zitat>

Möchte man IRMP und IRSND parallel verwenden (also als Sender und 
Empfänger) schreibt man die ISR folgendermaßen:
ISR(TIMER1_COMPA_vect)
{
  if (! irsnd_ISR())          // call irsnd ISR
  {                           // if not busy...
      irmp_ISR();             // call irmp ISR
  }
  // call other timer interrupt routines...
}

Das heisst: Nur wenn irsnd_ISR() nichts zu tun hat, dann rufe die ISR 
des Empfängers auf. Damit ist der Empfänger solange abgeschaltet, 
während irsnd_ISR() noch Daten sendet. Die Timer-Initialisierungsroutine 
ist für IRMP und IRSND dann natürlich dieselbe.

</zitat>

> Die
> while-Schleife in irsnd_send_data() finde ich schlecht. Sowas regelt man
> über Return-Codes. Soll doch der Aufrufer entscheiden, wie er darauf
> reagiert.

Naja, darüber kann man streiten. Wenn der Ausgangsbuffer eines seriellen 
Kanals voll ist, dann wartet die UNIX-Systemfunktion write() auch, bis 
wieder "Platz" da ist. Jedenfalls im Normalfall - solange man das nicht 
mittels eines ioctl-Aufrufs umstellt. Dasselbe gilt in der Regel 
eigentlich auch für Windows-Systemfunktionen. Analoges gilt auch für 
TCPIP-Stacks, wenn Du da auf Sockets schreibst. Die Dinger warten immer, 
wenn das Gerät (z.B. Ethernet-Karte) zu langsam ist.

<EDIT>
Die Dinger warten immer aus Sicht der Applikation, nicht aus der Sicht 
des Kernels natürlich.
</EDIT>

Ich schlage da folgenden Kompromiss vor:
uint8_t irsnd_send_data (IRMP_DATA * irmp_data_p, uint8_t do_wait)

Das heisst: mittels TRUE oder FALSE für do_wait kannst du selbst 
bestimmen, ob irsnd_send_data() sofort mit einem Fehler zurückkommen 
soll oder selbst wartet, bis das "Ausgabegerät" - also die IR-Diode - 
wieder frei ist.

Gruß,

Frank

P.S.
Ich werde im Laufe des Tages mal ein Update im SVN einspielen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Es ist definitiv ein Matrix-Code, ich habe mal die mir zur Verfügung
> stehenden Tasten-Scans bitweise gruppiert:

Mittlerweile bin ich bei der "Entschlüsselung" weiter. Die Matrix ist 
noch einfacher, als ich zunächst gedacht habe. Ausserdem steckt in dem 
IR-Telegramm der Tastatur Redundanz drin, nämlich nicht nur Zeile und 
Spalte, sondern auch noch ein Key-Code, der sich eigentlich aus Zeile 
und Spalte berechnen lässt.

Im Moment sieht das bisher entschlüsselte Format folgendermaßen aus:
-------------------------------------------------------------------
# 1
  ADRESSE        STATUS   REPEAT KEYCODE   SPALTE ZEILE   KEYCODE Spalte Zeile
11111100000000   000000   0000   01000000  1011   1111       2      13    15
11111100000000   000000   1111   01000000  1011   1111
-------------------------------------------------------------------
# 2
11111100000000   000000   0000   11000000  0011   1111       3      12    15
11111100000000   000000   1111   11000000  0011   1111
-------------------------------------------------------------------
# 3
11111100000000   000000   0000   00100000  1101   1111       4      11    15
11111100000000   000000   1111   00100000  1101   1111
-------------------------------------------------------------------

(Alle Binärzahlen mit LSB-first lesen!)

Verbleibt nur noch die Entschlüsselung der 6 Bits, die ich mit "STATUS" 
bezeichnet habe. Da vermute ich mal, dass dort die Zustände der 
Sondertasten - wie SHIFT, STRG, ALT usw. - gesendet werden. Es kann 
natürlich auch sein, dass die ADRESSE im Telegramm in Wirklichkeit 
kürzer ist und weitere Bits des Blocks ADRESSE mit Infos versehen sind. 
Die bekomme ich aber erst raus, wenn weitere Scans vorliegen.

Da obige Binär-Zahlengruppen immer mit LSB-first gelesen werden müssen, 
ergibt sich folgende Matrix:
         Spalte
         15   14   13   12   11   10   9    8    7    6    5    4    3    2    1    0
       +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
 ZEILE +    +    + 1  + 2  + 3  + 4  + 5  + 6  + 7  + 8  + 9  + 0  +    +    +    +    +
  15   + 0  + 1  + 2  + 3  + 4  + 5  + 6  + 7  + 8  + 9  + 10 + 11 + 12 + 13 + 14 + 15 +
       +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
 ZEILE +    + Q  + W  + E  + R  + T  + Z  + U  + I  + O  + P  +    +    +    +    +    +
  14   + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 + 31 +
       +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
 ZEILE +    +    +    +    +    +    +    +    +    +    +    +    +    +    +    +    +
  13   + 32 + 33 + 34 + 35 + 36 + 37 + 38 + 39 + 40 + 41 + 42 + 43 + 44 + 45 + 46 + 47 +
       +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+
 ZEILE +    +    +    +    +    +    +    +    +    +    + -  +    +    +LEER+    +    +
  12   + 48 + 49 + 50 + 51 + 52 + 53 + 54 + 55 + 56 + 57 + 58 + 59 + 60 + 61 + 62 + 63 +
       +----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+----+

In den Kästchen ist - soweit bekannt - eingetragen:

1. Aufdruck der Taste, also 1234567890, QWERTZUIOP und LEER
2. Keycode der Taste

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Okay, Du könntest Dir dann in der Applikation eine globale Variable
> setzen und dann irmp_get_data() gezielt aufrufen.

Interruptroutine und Anwendung (main) sind bei mir über FIFOs sowohl in 
Sende- als auch in Empfangsrichtung ge/ent-koppelt. Das erklärt 
hoffentlich meine Änderungswünsche:
ISR (TIMER0_COMP_vect)
{
  uint8_t data = PIN (IR_RX_PORT) & _BV (IR_RX_PIN);

  if (data == IR_RX_MARK)
    IR_RX_LED_ON;
  else
    IR_RX_LED_OFF;

  if (irmp_ISR (data) != 0)
    { // Sequenz dekodiert -> umspeichern
      uint8_t tmphead = FIFO_NEXT (ir_rx_fifo.write);
      if (tmphead != ir_rx_fifo.read)
        {
          if (irmp_get_data (&ir_rx_fifo.buffer[tmphead]))
            ir_rx_fifo.write = tmphead;
        }
    }
#ifdef IR_TX_PORT
  if (irsnd_ISR () == 0)
    { // Sender frei -> neue Sequenz laden
      if (ir_tx_fifo.read != ir_tx_fifo.write)
        irsnd_send_data (&ir_tx_fifo.buffer[ir_tx_fifo.read = FIFO_NEXT (ir_tx_fifo.read)]);
    }
#endif

Eine Verriegelung von Sender und Empfänger habe ich bewusst "ausgebaut".

Ich kann auch weiterhin auf den SVN-Stand meinen Patch anwenden und Du 
lässt alles so wie es ist.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:

> Interruptroutine und Anwendung (main) sind bei mir über FIFOs sowohl in
> Sende- als auch in Empfangsrichtung ge/ent-koppelt. Das erklärt
> hoffentlich meine Änderungswünsche:

Nett, Du könntest damit ja Megabytes an Daten übertragen ;-)

> Ich kann auch weiterhin auf den SVN-Stand meinen Patch anwenden und Du
> lässt alles so wie es ist.

Nein, ich baue den Return-Wert in irmp_ISR() ja ein, kann ja durchaus 
für manche Szenarien sinnvoll sein. Ebenso das wait-Flag in irsnd_ISR().

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sodele, Version 1.6.1 ist nun im SVN.

Änderungen:

 - Interface von irmp_ISR() geändert: gibt flag zurück, ob Frame
   empfangen wurde

 - Interface von irsnd_send_data() geändert: Nun auch Senden ohne
   Warteschleife möglich

 - UART-Routinen angepasst, damit das IRMP-Logging ohne Änderung
   auf allen ATMEGAs läuft

 - Debug-Output-Format angepasst für:

     Silent-Mode:  Option -s
     Verbose-Mode: Option -v
     Normal-Mode:  <keine Option>

Da diese (teils gravierenden) Änderungen noch nicht im IRMP-Artikel 
dokumentiert sind, gibt es auch noch keinen Download über den Artikel. 
Vielmehr werde ich dort vermerken, dass die SVN-Version keine 
Release-Version ist.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich werde im Laufe des Tages mal ein Update im SVN einspielen.

Danke, aber UART0_UDR ist nicht definiert. Fehlt im Block '#ifdef 
UBRR0H'.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Danke, aber UART0_UDR ist nicht definiert. Fehlt im Block '#ifdef
> UBRR0H'.

Upps, ich hatte das durch eine schematische Änderung in die Konstante 
UART0_UDR_BIT_VALUE geändert... war natürlich Käse.

Ist korrigiert,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe jetzt meine Tastatur mal vermessen, direkt am IR Empfänger.
Gemessen mit einem Tektronix 2014.

2120 mS Low
920 µS High
330 µS Low
690 µS High
310 µS Low
680 µS High

Die 690 µS High, 310 µS Low wiederholen sich 6 mal.
Dann kommt

190 µS High
350 µS Low

Das wiederholt sich auch viele male und wird dann auch mal von einer
690 µS High, 310 µS Low Kombination unterbrochen.

Ich hab das mal so ins define umgesetzt

#define FDC_START_BIT_PULSE_TIME                2120.0e-6
#define FDC_START_BIT_PAUSE_TIME                 920.0e-6
#define FDC_PULSE_TIME                           330.0e-6
#define FDC_1_PAUSE_TIME                         690.0e-6
#define FDC_0_PAUSE_TIME                         190.0e-6

Ich bin mir nicht sicher ob ich das richtig gemacht habe, aber immerhin 
bekomme ich damit auch mal einen FDC Datensatz, allerdings tauchen dann 
auch noch RC5 und Siemens mit auf.

Wenn ich RC5 und Siemens beim compilieren deaktiviere erhalte ich die 
FDC Datensätze. Soweit mir das aussieht auch bei jeder Taste einen 
anderen.

Gruß
Torsten

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank und Torsten!

Auch ich kann mit IRMP keinen FDC-Code dekodieren, wechselnd RCx und 
SIEMENS. Beim Testen ist mir noch aufgefallen, dass last_pause noch von 
anderen Protkollen als RCx und SIEMENS benötigt wird -> Compilerfehler.

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hy eku,

dann versuch doch mal die defines von mir und schalte den Siemens und 
RC5 ab, dann sollte es gehen.
Vielleicht hilft das Frank um zu erkennen woran es noch liegen kann.
Ich bin gerne bereit das hier weiter mit dem Scope zu vermessen.

Um nochmal auf die Taktung zu kommen.
Ich habe bei mir mal einen Pin wechseln lassen, wenn der in den OCR 
Interrupt geht.
Mit dem 8mhz Quarz habe ich exakt 15kHz, mache ich das mit dem internen 
RC Oscal bin ich bei 15,6kHz.
Daran ändern auch das auslesen des Oscal Calibration Byte nichts, das 
kann an der Toleranz liegen.

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Torsten,

Torsten Kalbe schrieb:

> ich habe jetzt meine Tastatur mal vermessen, direkt am IR Empfänger.
> Gemessen mit einem Tektronix 2014.
>
> 2120 mS Low

Sicher, dass es nicht 2120 µs waren? ms kommt mir verdammt lang vor ;-)

> 920 µS High
> 330 µS Low
> 690 µS High
> 310 µS Low
> 680 µS High
>
> Die 690 µS High, 310 µS Low wiederholen sich 6 mal.
> Dann kommt
>
> 190 µS High
> 350 µS Low
>
> Das wiederholt sich auch viele male und wird dann auch mal von einer
> 690 µS High, 310 µS Low Kombination unterbrochen.

Das sieht ziemlich kaputt aus. Diese Timings habe ich auch im Scan 
gesehen, konnte es aber kaum glauben, denn bei ekus Tastatur waren 
Timings:

Start-Bit   1390µs Puls, 640µs Pause
0-Bit        200µs Puls, 145µs Pause
1-Bit        200µs Puls, 475µs Pause
Stop-Bit     200µs Puls

Siehe auch IRMP-Artikel:

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

Dort habe ich alle Timings dokumentiert.

Bis auf das Start-Bit waren also alle Pulse gleich lang. Bei Dir ist das 
komplett anders. Die 190µs-Pause fällt auch komplett aus dem Rahmen.

> Ich hab das mal so ins define umgesetzt
>
> #define FDC_START_BIT_PULSE_TIME                2120.0e-6

Korrekt

> #define FDC_START_BIT_PAUSE_TIME                 920.0e-6

Korrekt.

> #define FDC_PULSE_TIME                           330.0e-6

Jepp.

> #define FDC_1_PAUSE_TIME                         690.0e-6
> #define FDC_0_PAUSE_TIME                         190.0e-6

Da glaube ich eher, dass es umgekehrt ist. Die 0en kommen öfter vor als 
die 1en. Aber das ist erstmal nebensächlich, dann ist das bei Dir halt 
erstmal invertiert.

> Ich bin mir nicht sicher ob ich das richtig gemacht habe, aber immerhin
> bekomme ich damit auch mal einen FDC Datensatz, allerdings tauchen dann
> auch noch RC5 und Siemens mit auf.

Das passiert, wenn sich ein Bit im Frame nicht an die vorgegebenen 
Zeiten hält. Dann "sucht" IRMP nach dem nächsten Start-Bit, um sich 
wieder zu synchronisieren. Dabei "erkennt" IRMP dann ein Daten-Bit des 
FDC-Stroms als Start-Bit von RC5 oder Siemens und klinkt sich dann dort 
wieder ein - fälschlicherweise. Da muss man dann die Toleranzen für die 
Daten-Bits höher drehen - nicht für die Start-Bits. Ich schicke Deinen 
Scan gleich nochmal durch den IRMP unter Linux und passe die Toleranzen 
an. Vielleicht klappt das. Allerdings sind bei Deiner Tastatur 
erhebliche Streungen im Timing. Vielleicht ist das Ding ja einfach nur 
kaputt?

> Wenn ich RC5 und Siemens beim compilieren deaktiviere erhalte ich die
> FDC Datensätze. Soweit mir das aussieht auch bei jeder Taste einen
> anderen.

Gut, ein Hoffnungsschimmer. Dann probiere ich mal, das als 
"FDC2"-Protokoll zu implementieren. Blöd, dass es da wieder eine 
Variante gibt. Bin mal gespannt, was meine bestellten Tastaturen 
aussenden... hoffentlich nicht noch eine dritte Variante...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:
> Auch ich kann mit IRMP keinen FDC-Code dekodieren, wechselnd RCx und
> SIEMENS. Beim Testen ist mir noch aufgefallen, dass last_pause noch von
> anderen Protkollen als RCx und SIEMENS benötigt wird -> Compilerfehler.

Wieso das? Das lief doch vorgestern noch bei Dir... ich habe die Timings 
seitdem nicht mehr geändert... merkürdig.

Habe gerade nochmal den Source im SVN gegen die Scan-Datei von Dir 
laufen lassen: FDC wird eindeutig erkannt. Du musst da noch irgendwas 
geändert haben... eine andere Erklärung habe ich nicht. Oder spinnt 
Deine Tastatur jetzt auch so rum wie die von Torsten?

Gibt es da vielleicht auf der Unterseite der Tastatur einen 
Schiebeschalter, mit dem man das Protokoll umschalten kann, damit sich 2 
baugleiche Tastaturen in einem Raum nicht ins Gehege kommen? Bei 
Funktastaturen habe ich das schon öfter mal gesehen...

Gruß,

Frank

von Torsten K. (nobby)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab hier mal Taste 1 in "Bildform".

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:

> 190 µS High
> 350 µS Low

Hier mal der irmp-Output von Deinem Scan (Option -a zeigt nur Timings):
# Model No.:FDC-3402
-------------------------------------------------------------------
# Taste 1
pulse: 33 pause: 12
pulse: 7 pause: 9
pulse: 5 pause: 10
pulse: 5 pause: 10
pulse: 6 pause: 10
pulse: 5 pause: 10
pulse: 6 pause: 9
pulse: 5 pause: 3
pulse: 5 pause: 3
pulse: 5 pause: 2
pulse: 6 pause: 2
pulse: 6 pause: 2
pulse: 6 pause: 2
pulse: 6 pause: 2
pulse: 5 pause: 3
pulse: 6 pause: 1
pulse: 6 pause: 3
pulse: 6 pause: 1
pulse: 6 pause: 2
pulse: 6 pause: 2
pulse: 5 pause: 3
pulse: 14 pause: 1
pulse: 6 pause: 2
pulse: 6 pause: 2
pulse: 5 pause: 3
pulse: 5 pause: 10
pulse: 6 pause: 2
pulse: 6 pause: 2
pulse: 5 pause: 3
pulse: 5 pause: 3
pulse: 5 pause: 3
pulse: 5 pause: 2
pulse: 6 pause: 10
pulse: 4 pause: 3
pulse: 5 pause: 11
pulse: 6 pause: 9
pulse: 6 pause: 9
pulse: 5 pause: 10
pulse: 6 pause: 10
pulse: 5 pause: 10

Das Start-Bit ist okay, die Pulsdauern schwanken zwischen 5 und 7, also 
zwischen 330µs und ca. 470µs.

Die Pausen sind offenbar:

9 - 11 = 600µs - 733µs  für 1-Bit
1 - 3  =  66µs - 200µs  für 0-Bit

Und diese Zeile ist der Knackpunkt (s.o.):

pulse: 14 pause: 1

Hier wurde gar keine Pause aufgezeichnet, weil sie einfach zu kurz war!
Dadurch "verlängert" sich die Pulsdauer auf ziemlich genau das Doppelte. 
In Wirklichkeit sind das aber 2 Bits, nämlich in etwa so was:

pulse: 7 pause: 0 <--- Pause zu kurz, wird nicht erkannt
pulse: 7 pause: 1 <--- Pause wird erkannt

Fazit: 15kHz sind zu kurz, um diese Frames mit den sehr kurzen Pulsen 
verlässlich zu detektieren. Das obige Phänomen tritt bei fast allen 
Tasten in Deinem Scan auf, nämlich ungefähr bei 50% der Scans.

Du könntest mal auf 20kHz hochgehen - und die Compiler-Warnungen 
entweder ignorieren oder vermeiden, indem Du z.B. BANG_OLUFSEN (und 
evtl. weitere) abschaltest, bis alle Compiler-Warnungen weg sind.

Gruß,

Frank

von Torsten K. (nobby)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab alle Protokolle ausser dem FDC abgeschaltet, aber trotzdem zwei 
Warnungen bekommen.

Tasten 1 bis 4 hängen hier an.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:
> Ich hab alle Protokolle ausser dem FDC abgeschaltet, aber trotzdem zwei
> Warnungen bekommen.

Okay, darum kümmern wir uns später.

> Tasten 1 bis 4 hängen hier an.

Danke, habe ich mir angeschaut, Deine ausgewählten Timings nochmal ein 
wenig abgeändert, die Toleranzen geändert und das Ganze als Protokol 
FDC2 (= 19) implementiert. Der Source ist im SVN. Damit werden Deine 
Tasten bei 20kHz erkannt. Das Ergebnis der Codes ist identisch mit denen 
von eku.

Deine Tastatur encodiert die Tasten also genauso wie die von eku, aber 
das Timing ist verschieden.

Nochmals meine Frage: Kein Schiebeschalter unter der Tastatur, wo man 
das Timing vielleicht umschalten kann, damit man 2 baugleiche Tastaturen 
in einem Raum nutzen kann?

Test bitte mal den Source bei 20kHz. Sollte Deine Tasten nun einwandfrei 
erkennen.

Ein Knackpunkt ist aber da noch: Ich musste die Toleranzen für RC5 auf 
0% runterschrauben, da das FDC2-Protokoll vom Startbit her mit dem 
RC5x-Protokoll kollidiert. Da muss ich mir also was einfallen lassen, 
denn im Moment wird bei Toleranz von 0% kein RC5 mehr erkannt :-(

Naja, erstmal ist die SVN-Version als Testversion zu sehen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:
> Auch ich kann mit IRMP keinen FDC-Code dekodieren, wechselnd RCx und
> SIEMENS.

Ich bin mir ziemlich sicher, dass Du es geschafft hast, Deine Tastatur 
auf das Timing von Torsten umzuschalten, welches ich mittlerweile als 
FDC2 implementiert habe (siehe SVN). Das Timing von FDC2 kollidiert 
tatsächlich mit RC5 - vom Startbit her. Da suche ich noch nach einer 
Lösung.

> Beim Testen ist mir noch aufgefallen, dass last_pause noch von
> anderen Protkollen als RCx und SIEMENS benötigt wird -> Compilerfehler.

Danke für den Tipp, tatsächlich wird es bei allen Manchester-codierten 
Protokollen benutzt, also auch noch für Grundig und Nokia. Werde ich 
korrigieren.

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Einen Schalter finde ich nicht, vielleicht hat das Ding intern einen 
Jumper oder ähnliches.
EKU schrieb doch aber, das es bei Ihm auch nicht funktioniert hat.

Könnte es vielleicht auch am IR Empfänger liegen 36/38kHz ?

Pollin schreibt zu der Tastatur, das man Applikationen im Internet 
finden könnte, hat da schonmal jemand etwas gefunden. Vielleicht ist da 
auch was übers Timing zu sehen. Ich hab leider bisher nichts gefunden.
Sonst warten wir mal ab, wie es mit weiteren Tastaturen aussieht.

Es gibt übrigens bei Pollin noch einen weiteren Tastaturentyp für 1 
Euro.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:
> Einen Schalter finde ich nicht, vielleicht hat das Ding intern einen
> Jumper oder ähnliches.

Hm, blöd.

> EKU schrieb doch aber, das es bei Ihm auch nicht funktioniert hat.

Es funktioniert aber bei mir mit den Scan-Dateien, die eku hier

Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

angehängt hat.

Hier die Timing-Daten, die ich aus ekus Scan-Dateien gewonnen habe:
#define FDC1_START_BIT_PULSE_TIME                1390.0e-6                       // 1390 usec pulse
#define FDC1_START_BIT_PAUSE_TIME                 640.0e-6                       //  640 usec pause
#define FDC1_PULSE_TIME                           200.0e-6                       //  200 usec pulse
#define FDC1_1_PAUSE_TIME                         475.0e-6                       //  475 usec pause
#define FDC1_0_PAUSE_TIME                         145.0e-6                       //  145 usec pause

Und hier Deine:
#define FDC2_START_BIT_PULSE_TIME                2120.0e-6                       // 2120 usec pulse
#define FDC2_START_BIT_PAUSE_TIME                 920.0e-6                       //  920 usec pause
#define FDC2_PULSE_TIME                           400.0e-6                       //  400 usec pulse
#define FDC2_1_PAUSE_TIME                         660.0e-6                       //  660 usec pause
#define FDC2_0_PAUSE_TIME                         145.0e-6                       //  140 usec pause

Zwischen diesen Werten liegt ungefähr ein Faktor 1,5.

Dafür gibt es folgende Möglichkeiten als Erklärung:

1. Beide Tastaturen arbeiten vom Timing her tatsächlich identisch
   und einer von Euch beiden arbeitete bei der Scan-Aufnahme mit
   einem Fehler von 150% bei der Timerparametrisierung.

2. Die Tastaturen arbeiten mit einer Abweichnung von 150% - vielleicht
   kosten sie deshalb nur knapp 2 EUR bei Pollin ;-)

Das FDC1-Timing (von eku) kollidiert aber seit Version 1.6.1 nicht mehr 
mit RC5 (weil ich die Toleranzen für RC5 auf 10% reduziert habe), das 
ist nur beim FDC2-Timing (von Dir) der Fall. Also könnte es sein, dass 
die Möglichkeit 1 bei eku der Fall war (zum Zeitpunkt des Scannens), er 
den Fehler mittlerweile korrigiert hat und deshalb nun in dieselbe 
RC5-Falle reinläuft wie Du.

Oder seine Tastatur hat sich umgestellt auf das andere Timing. Nur ein 
neuer Scan von eku kann das aufklären.

Ich bin gespannt auf die Lieferung meiner Tastaturen - ich hatte einfach 
mal frech 5 Stück bestellt. Dann hoffe ich, dass wir mehr Licht ins 
Dunkel bringen.

> Könnte es vielleicht auch am IR Empfänger liegen 36/38kHz ?

Glaube ich nicht.

> Pollin schreibt zu der Tastatur, das man Applikationen im Internet
> finden könnte, hat da schonmal jemand etwas gefunden. Vielleicht ist da
> auch was übers Timing zu sehen. Ich hab leider bisher nichts gefunden.

Nein, da habe ich nichts gefunden.

> Sonst warten wir mal ab, wie es mit weiteren Tastaturen aussieht.

Ja.

> Es gibt übrigens bei Pollin noch einen weiteren Tastaturentyp
> für 1 Euro.

Nämlich welchen?

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

das Signal selber habe ich mit dem Scope gemessen, und da hatte sich ja 
das Timing bestätigt, welches ich mit der Schaltung gescant habe.

Die Tastatur hat ja ein paar "Funktionstasten", vielleicht kann man 
durch drücken einer solchen gefolgt von einer zweiten das Timing 
verstellen, das wäre eine Möglichkeit.


Die zweite Tastatur ist diese:
http://www.pollin.de/shop/dt/MDk5ODgyOTk-/Computer_und_Zubehoer/Hardware/Tastaturen/Infrarot_Tastatur_SWK_8650.html

Die scheint aber ein ganz einfaches Signal zu haben, könnte ich Dir auch 
mal einen Scan zu schicken.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:

> das Signal selber habe ich mit dem Scope gemessen, und da hatte sich ja
> das Timing bestätigt, welches ich mit der Schaltung gescant habe.

Stimmt. Wenn Du aber ekus 15kHz-Scan-Datei und Deine 15-kHz-Scan-Datei 
einfach mal in den Editor lädst, siehst Du, dass sowohl Pausen und auch 
Pulsdauern bei eku um den Faktor 1,5 kürzer sind. Dafür haben die Pausen 
in ekus Scan-Datei eine wesentlich geringere Schwankung, so dass der 
Fall "Pause=0" bei ihm trotz kürzerer Zeiten nicht auftritt. Deshalb 
funktionierte es mit seinen Scan-Dateien und meinem linux-irmp mit 15kHz 
perfekt.

Damit bleiben als Möglichkeiten übrig:

1. Beide Tastaturen arbeiten vom Timing her identisch und eku hat
   versehentlich mit 10kHz statt 15kHz (wie angegeben) gescannt.

2. Die Tastaturen arbeiten tatsächlich mit einer Abweichnung von 150%

> Die Tastatur hat ja ein paar "Funktionstasten", vielleicht kann man
> durch drücken einer solchen gefolgt von einer zweiten das Timing
> verstellen, das wäre eine Möglichkeit.

Jau.

Frage: Hattest Du die 1.6.2 mit den von mir angepassten Timings und dem 
neuen Protokoll "FDC2" (=19) aus dem SVN nochmal testen können?

> Die zweite Tastatur ist diese:
> 
http://www.pollin.de/shop/dt/MDk5ODgyOTk-/Computer_und_Zubehoer/Hardware/Tastaturen/Infrarot_Tastatur_SWK_8650.html

Ahja. Die Beschriftung der Tasten ist laut Pollin aber verschieden. Hast 
Du da eine mit deutschem Layout?

> Die scheint aber ein ganz einfaches Signal zu haben, könnte ich Dir auch
> mal einen Scan zu schicken.

Gern!

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Wenn Du aber ekus 15kHz-Scan-Datei und Deine 15-kHz-Scan-Datei
> einfach mal in den Editor lädst, siehst Du, dass sowohl Pausen und auch
> Pulsdauern bei eku um den Faktor 1,5 kürzer sind.

Ich komme erst am Wochenende dazu, weitere Scans aufzuzeichnen. Das 
FDC-Protokoll mag zwar im Linux-IRMP erkannt werden, bei mir mit 15kHz 
definiitiv nicht, auch wenn ich RCx und SIEMENS abklemme. Mehr dazu 
morgen.

von eku (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anbei die Tastaturbelegung meiner FDC.

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
15kHz und FDC: return von irmp_ISR() und irmp_get_data() ist jeweils 1, 
aber proto, address und command sind Null

20kHz und FDC: dito

kurze Tastendruck: 3 Frames, 2. und 3. mit Repeat
langer Tastendurck: n Frames, 2. bis n. mit Repeat

20kHz und FDC2: proto FDC2, address 3F, command 0x00-0xFF

kurze Tastendruck: 2 Frames, 2. mit Repeat
langer Tastendurck: n Frames, 2. bis n. mit Repeat

Mit 20kHz liefert irmp_ISR() häufig 1 (irmp_detected), auch wenn keine 
IR-Signale gesendet werden.

von Torsten K. (nobby)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

die Tastatur habe ich noch nicht mit dem neuen FD2 getestet, mache ich 
aber heute noch.

Meine andere Tastatur von Pollin hat eine QWERTY Layout, die Return und 
Sondertasten sind in einer mir momentan fremden Sprache :-)


Ich habe soeben einen neuen Scan einer IR Fernbedienung für 
Modellfahrzeuge aufgenommen, die würde ich sehr gerne entschlüsseln 
können, dann kann ich nämlich endlich meine Rennbahn entsprechend 
verbessern !!

Das ganze sieht auch sehr sehr übersichtlich aus, hab das schon fast 
selber entschlüsselt :-))

Hier eine erste Analyse:

Eine Fernbedienung kann eine Senderadresse von 0 bis 3 haben,
daher 4 Fahrzeuge.

Es können 3 AD Werte und 8 Schalterstellungen gesendet werden.

Die oberen zwei bits scheinen festzulegen, was gesendet wird.
Davon ausgehend das ein langer Puls, 900µS, 1 entspricht:

00, 10, 01, hier werden die AD Werte gesendet
11, dann werden die Schalterstellungen gesendet.

Die nächsten zwei Bits sind dann die vier möglichen Adressen.


Ist das vielleicht zu implementieren ?

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Habe jetzt die neu SVN installiert und das funktioniert sehr gut !
Ich bekomme immer FDC2 Codes angezeigt und auch plausible Hex-Zahlen.
Taste 1 entspricht 0x02 und Taste a ist 0x1F.

Frank, Du hast irgendwo geschrieben, ich könnte meinen Scan auch in 
einen Editor laden und könnte dann das Diagramm sehen ?
Was ist damit gemeint ? Kann ich damit so "schöne" Bilder erzeugen wie 
in Deiner Doku zu sehen ist ?
Ich habe allerdings nur Windows laufen.

Gruß
Torsten

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Torsten,

Torsten Kalbe schrieb:

> Das ganze sieht auch sehr sehr übersichtlich aus, hab das schon fast
> selber entschlüsselt :-))

Sieht sehr einfach aus, sag mir noch die Frequenz, mit der Du das 
gescannt hast.

> Ist das vielleicht zu implementieren ?

Jau, das kriege ich hin. Ich melde mich dann, komme aber wohl frühestens 
heute abend dazu.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Torsten Kalbe schrieb:
> Habe jetzt die neu SVN installiert und das funktioniert sehr gut !

Freut mich.

> Ich bekomme immer FDC2 Codes angezeigt und auch plausible Hex-Zahlen.
> Taste 1 entspricht 0x02 und Taste a ist 0x1F.

Passt, das ist der "Keycode", den ich oben in die Matrix geladen habe.

> Frank, Du hast irgendwo geschrieben, ich könnte meinen Scan auch in
> einen Editor laden und könnte dann das Diagramm sehen ?

Nein, kein Diagramm, Du siehst im Editor halt Folgen von 0en (Puls) und 
1en
(Pause). Bei Dir sind sie 1,5mal länger, also z.B.

00000000000000000000
0000000000000

> Was ist damit gemeint ? Kann ich damit so "schöne" Bilder erzeugen wie
> in Deiner Doku zu sehen ist ?

Die Bilder sind ein Oszi-Bild, nix weiter.

> Ich habe allerdings nur Windows laufen.

Dann scanne Deine Rennbahn-FB mit 10kHz ein und gebe dann ein:

irmp.exe -a < rennbahn.txt

Dann siehst Du eine Häufigkeitsverteilung als "Spektrum", das Ding 
"malt" Dir dann mit ASCII-Zeichen ein paar (unförmige) Glockenkurven. 
Geht aber erst mit Version 1.6.3, die ich gestern nachmittag ins SVN 
eingecheckt habe.

Beispiel für eine ekus Scan mit 15kHz:
--------------------------------------------------------------------------------------------------------------
START PULSES:
 20 oooooooooooooooo 3
 21 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 18
average: 20.86 = 1390.48 usec
--------------------------------------------------------------------------------------------------------------
START PAUSES:
  9 ooooooooooooooooooooooo 4
 10 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 17
average: 9.81 = 653.97 usec
--------------------------------------------------------------------------------------------------------------
PULSES:
  3 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 1517
  4 oo 41
average: 3.03 = 201.75 usec
 20  1
 21 o 16
average: 20.94 = 1396.08 usec
--------------------------------------------------------------------------------------------------------------
PAUSES:
  2 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 741
  3 oooooooooooooooooooooooo 179
average: 2.19 = 146.30 usec
  7 ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 515
  8 ooooooooooo 85
  9 o 10
 10  7
average: 7.20 = 480.28 usec
--------------------------------------------------------------------------------------------------------------

Daraus kann man die Länge der Pulse/Pausen dann direkt ablesen :-)

irmp.exe -l <rennbahn.txt

Dann siehst Du die Längen der Pulse und Pausen in Zahlen - als Listing.

irmp.exe -v <rennbahn.txt

Zeigt Dir dann Protokoll-Infos an - aber nur, wenn irmp das Protokoll 
bereits kennt.

irmp.exe <rennbahn.txt

Dasselbe, aber kompakter, Fehler werden unterdrückt.

Zusammenfassung:

  -a  analyze
  -l  list
  -v  verbose

Das oben beschriebene gilt - wie gesagt - nur mit der neuesten 
SVN-Version, bei den vorherigen Versionen haben die Optionen andere 
Bedeutungen/Ausgabeformate.

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

der Scan von meiner FB ist mit 20kHz gemacht, war noch so eingestellt 
von dern vorherigen Versuchen mit der Tastatur.

Gruß

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Torsten,

Torsten Kalbe schrieb:

> Ich habe soeben einen neuen Scan einer IR Fernbedienung für
> Modellfahrzeuge aufgenommen, die würde ich sehr gerne entschlüsseln
> können, dann kann ich nämlich endlich meine Rennbahn entsprechend
> verbessern !!

Habe das Protokoll in IRMP eingebaut, den Source findest Du im SVN. 
Protocol RCCAR (=20), RC5 muss dafür abgeschaltet werden.

Jeder Frame hat 13 Bits, ich habe sie allesamt mit MSB in irmp_data.code 
abgelegt. Das Ermitteln der Bedeutung der Bits überlasse ich damit Dir, 
Du brauchst Dir ja einfach nur mal die von IRMP ausgegebenen Codes als 
Binärzahl hinzuschreiben.

Viel Spaß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hy,

das funktioniert klasse !!!

Die 13 bits sind auch sehr einfach aufgeteilt. Es müßte aber so 
eingebaut werden, das auch irmp_data.address benutzt wird.

Da es ja in Summe nur 13 bits insgesamt sind, sind die oberen drei immer 
null.
Dann folgen zwei, die die Art der Daten angeben, dann folgen die 
eigentlichen zwei Adressbits, dann 7 Datenbits, das letzte Bit ist wohl 
sowas wie ein Verify, das sorgt dafür, das immer eine ungerade Zahl an 1 
bits gesendet wird.
Aufgeteilt ist es also so:

xxxCCAADDDDDDDDV

Ich weis jetzt nicht, wie kompliziert es ist, aber ich fände es am 
besten, wenn die mit AA bezeichneten bits im irmp_data.address 
übertragen werden, dort wo jetzt immer Null kommt:
xxxxxxxx xxxxxxAA

Ins irmp_data.command käme dann:
xxxxxCCV DDDDDDDD

Gruß
Torsten

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Mir ist jetzt noch etwas aufgefallen.
Bei den Datenbits scheint es LSB first zu sein, also so:
xxxCCAA D0 D1 D2 D3 D4 D5 D6 D7 V

besser wäre dann, wenn das irmp_data.command so aussähe:

xxxxxCCV D7 D6 D5 D4 D3 D2 D1 D0

Natürlich kann man diese ganze Bitmanipulation auch im Hauptprogramm 
machen, aber bei den anderen Protokollen wird das ja auch entprechend 
übergeben.

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Was ich gerade feststelle ist, das es bei den Adress IDs auch so ist.
Bei den Commandbits wird es dann genauso sein, daher wäre auch da eine 
entsprechende Sortierung besser.

Also nochmal, bisher kommt das alles so im irmp_data.command an:

xxx C0 C1 A0 A1 D0 D1 D2 D3 D4 D5 D6 D7 V

Demnach sollte irmp_data.address so aussehen:
xxxxxxxx xxxxxx A1 A0


Das irmp_data.command würde ich so aufbauen:

xxxxx V C1 C0 D7 D6 D5 D4 D3 D2 D1 D0

Das verify-Bit habe ich ganz nach vorne gestellt. Damit ergibt sich, das 
der zweite Char dann die Daten sind und im ersten steht der Befehl und 
das Verify. Der Befehl kann dann direkt ausmaskiert werden, ohne danach 
noch geschoben zu werden.

Wäre das so ok, bzw. hab ich das verständlich rübergebracht ?

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Habe das Protokoll in IRMP eingebaut, den Source findest Du im SVN.
> Protocol RCCAR (=20), RC5 muss dafür abgeschaltet werden.

Hier machts sich eine Designschwäche des Dekoders bemerkbar. Dies 
passierte nicht, wenn zunächst die Pegelzeiten gespeichert und getrennt 
auswertet werden, d.h. alle Protokolle auf den Puffer testen. Das 
Festlegen auf ein Protokoll an Hand des Startbits führt bei mehreren 
Protokollen in die Sackgasse.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Torsten,

Torsten Kalbe schrieb:

> Also nochmal, bisher kommt das alles so im irmp_data.command an:
>
> xxx C0 C1 A0 A1 D0 D1 D2 D3 D4 D5 D6 D7 V
>
> Demnach sollte irmp_data.address so aussehen:
> xxxxxxxx xxxxxx A1 A0
>
>
> Das irmp_data.command würde ich so aufbauen:
>
> xxxxx V C1 C0 D7 D6 D5 D4 D3 D2 D1 D0

Du kannst in irmp.h folgendes einstellen:
#define RCCAR_LSB               1   // LSB...MSB

Dann hast Du das schon mal auf LSB first umgestellt.

Der Frame sieht nach Deinen Ausführungen so aus:

Bit 0  1  2  3  4  5  6  7  8  9  10 11 12
    C0 C1 A0 A1 D0 D1 D2 D3 D4 D5 D6 D7 V

Damit die Adresse in irmp_data.address landet, könntest Du schreiben:
#define RCCAR_ADDRESS_OFFSET    2   // skip 2 bits
#define RCCAR_ADDRESS_LEN       2   // read 2 address bits

Dann sollte in irmp_data.address die Adresse stehen.

Jetzt zu den Kommando-Bits, das ist ein wenig schwierig, denn IRMP kann 
über die Preprocessor-Konstanten bisher nur Adress-Bits und 
Kommando-Bits in irmp_data.address und irmp_data.command aufteilen, wenn 
sie direkt aufeinanderfolgend sind.

Wenn Du schreibst:
#define RCCAR_COMMAND_OFFSET     4      // skip 4 bits
#define RCCAR_COMMAND_LEN        9      // read 9 bits

... dann fehlen Dir C0 und C1. Das Ganze funktioniert also nicht.

Daher empfehle ich, die Preprocessor-Konstanten bis auf die 
LSB-Geschichte unangetastet zu lassen und erstmal alles als data 
aufzufassen, also bitte nur ändern:
#define RCCAR_LSB               1   // LSB...MSB


Die Aufteilung in Adresse und Kommando kannst Du erst am Ende machen, 
nämlich in irmp_get_data().

Dazu fügst Du folgenden Block in irmp_get_data im case-switch ein - 
analog zu den anderen:
#if IRMP_SUPPORT_RCCAR_PROTOCOL == 1
            case IRMP_RCCAR_PROTOCOL:
                // frame in irmp_data:
                // Bit 12 11 10 9  8  7  6  5  4  3  2  1  0
                //     V  D7 D6 D5 D4 D3 D2 D1 D0 A1 A0 C1 C0   //         10 9  8  7  6  5  4  3  2  1  0
                irmp_address = (irmp_command & 0x000C) >> 2;    // addr:   0  0  0  0  0  0  0  0  0  A1 A0
                irmp_command = (irmp_command & 0x1000) >> 2 ||  // V-Bit:  V  0  0  0  0  0  0  0  0  0  0
                               (irmp_command & 0x0003) << 8 ||  // C-Bits: 0  C1 C0 0  0  0  0  0  0  0  0
                               (irmp_command & 0x0FF0) >> 4;    // D-Bits:          D7 D6 D5 D4 D3 D2 D1 D0
                rtc = TRUE;                                     // Summe:  V  C1 C0 D7 D6 D5 D4 D3 D2 D1 D0
#endif

Baue das bitte so ein. Wenn es klappt, übernehme ich die Änderungen in 
IRMP.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Hier machts sich eine Designschwäche des Dekoders bemerkbar.

Ja, ich weiss, das hatte Dich ja schon vor Monaten (im Januar) gestört.

> Dies passierte nicht, wenn zunächst die Pegelzeiten gespeichert und getrennt
> auswertet werden, d.h. alle Protokolle auf den Puffer testen. Das
> Festlegen auf ein Protokoll an Hand des Startbits führt bei mehreren
> Protokollen in die Sackgasse.

Du hast nur zu einem Teil recht. In diesem Fall (RC5 und FDC2) würde 
auch das nachträgliche Auswerten des Gesamtframes nichts bringen. Es gab 
nämlich im FDC2-Protokoll durchaus Scans, die komplett ohne Fehler 
durch den RC5-Decoder durch laufen. Diese würden auch mit Deiner 
nachträglichen Methode fälschlicherweise als RC5 erkannt werden.

Der Grund liegt am Manchester-Code. Dieser besetzt leider mit den 4 
möglichen Abfolgen

  1-fach Länge Puls
  2-fach Länge Puls
  1-fach Länge Pause
  2-fach Länge Pause

ein breites Spektrum an möglichen Zeiten. Da bei RC5 das Start-Bit nicht 
ausgezeichnet ist (es hat dieselben Timings wie die nachfolgenden 
Daten), ist das geradezu ein Multiprotokoll-Decoder-Killer. Die 
Entwickler bei Siemens haben aus den Erfahrungen auch gelernt und das 
bei RC6 geändert: dort gibt es ein Start-Bit mit einem Timing, das nicht 
in den Daten selbst verwendet wird.

Bei den Pulse-Distance-Protokollen ist das anders. Da gibt es nur 2 
Möglichkeiten (im Start-Bit):

  1-fach Länge Puls
  1-fach Länge Pause

Daher gibt es hier naturgemäß untereinander wesentlich weniger Konflikte 
- bisher nämlich keine.

Deine damals schon vorgeschlagene Methode, den Frame erst nachträglich 
zu bewerten und zu dekodieren, ist wesentlich aufwendiger und kostet 
nicht nur einen Buffer zum Speichern des Frames, sondern auch einen 
wesentlichen Mehraufwand an Code. Ausserdem würde Deine Methode in der 
Kombination RC5+FDC2 oder RC5+RCCAR genauso kläglich versagen, denn auch 
bei der nachträglichen Auswertung würdest Du bestimmte FDC- und 
RCCAR-Frames komplett als RC5 auffassen können, ohne eine Regel zu 
verletzen.

IRMP wechselt sogar on-the-fly das erkannte Protokoll, z.B. vom SAMSUNG 
auf das SAMSUNG32-Protokoll, ebenso vom Grundig- auf das 
Nokia-Protokoll, wenn plötlzich mitten im Frame andere Bedingungen 
auftreten. Was IRMP nicht kann, ist von einem Manchester-Protokoll auf 
ein Puls-Distanz-Protokoll zu wechseln, da hier die bisher decodierten 
Bits nicht mehr "umzurechnen" sind.

Mein Fazit: Aus obigen Gründen halte ich an der Methode, wie IRMP die 
Protokolle detektiert, fest. Dass es bei mittlerweile 20 Protokollen, 
die IRMP "versteht", zu Konflikten kommen kann, halte ich für durchaus 
normal. Wenn diese Konflikte auch nur bei exotischen Protokollen (bzw. 
Kombinationen) auftreten, halte ich das auch für durchaus akzeptabel. 
Ich kann mir auch nicht vorstellen, dass ein Decoder für eine Rennbahn 
auch noch RC5 kennen muss.

Bei den Main-Stream-Protokollen gibt es im IRMP keine Konflikte. Das 
reicht für die meisten Anwendungen aus.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Dazu fügst Du folgenden Block in irmp_get_data im case-switch ein -
> analog zu den anderen:
>
> #if IRMP_SUPPORT_RCCAR_PROTOCOL == 1
> ...
> #endif

Ein blöder Tippfehler: Statt den beiden "||" muss es natürlich jedesmal 
"|" heissen, also:
#if IRMP_SUPPORT_RCCAR_PROTOCOL == 1
            case IRMP_RCCAR_PROTOCOL:
                // frame in irmp_data:
                // Bit 12 11 10 9  8  7  6  5  4  3  2  1  0
                //     V  D7 D6 D5 D4 D3 D2 D1 D0 A1 A0 C1 C0   //         10 9  8  7  6  5  4  3  2  1  0
                irmp_address = (irmp_command & 0x000C) >> 2;    // addr:   0  0  0  0  0  0  0  0  0  A1 A0
                irmp_command = (irmp_command & 0x1000) >> 2 |   // V-Bit:  V  0  0  0  0  0  0  0  0  0  0
                               (irmp_command & 0x0003) << 8 |   // C-Bits: 0  C1 C0 0  0  0  0  0  0  0  0
                               (irmp_command & 0x0FF0) >> 4;    // D-Bits:          D7 D6 D5 D4 D3 D2 D1 D0
                rtc = TRUE;                                     // Summe:  V  C1 C0 D7 D6 D5 D4 D3 D2 D1 D0
                break;
#endif

Gruß,

Frank

von eku (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Ich komme erst am Wochenende dazu, weitere Scans aufzuzeichnen.

Die versprochenen Scans bei 20kHz, Reihe für Reihe von oben nach unten 
(vgl. Beitrag "Re: IRMP - Infrared Multi Protocol Decoder").

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Könntest Du bitte die Variable irmp_pause_time auf uint16_t setzen um 
den Überlauf bei höheren Sampleraten zu verhindern.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Die versprochenen Scans bei 20kHz, Reihe für Reihe von oben nach unten

Danke, schaue ich mir an, bin gespannt...

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Könntest Du bitte die Variable irmp_pause_time auf uint16_t setzen um
> den Überlauf bei höheren Sampleraten zu verhindern.

Habe ich mir auch schon überlegt, die Variable last_pause muss dann aber 
auch auf 16 Bit erhöht werden.

Kostet zusätzliche 220 Programmcode und mehr Prozessorlast.

Ich überlege es mir noch (bzw. suche nach einer Alternativlösung, evtl. 
unter Benutzung einer Überlaufvariablen). Umschalten auf 16 Bit würde 
ich das auch erst ab F_INTERRUPT > 15000. Darunter braucht man es nicht.

Gruß,

Frank

von Torsten K. (nobby)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

jo das funktioniert.

Aber warum soll denn die Adresse nicht schon damit ummaskiert werden, 
das würde doch immerhin eine gewisse Gleichmäßigkeit zu den anderen 
Protokollen haben.

Damit die Adresse in irmp_data.address landet, könntest Du schreiben:
#define RCCAR_ADDRESS_OFFSET    2   // skip 2 bits
#define RCCAR_ADDRESS_LEN       2   // read 2 address bits

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.