Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder

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.

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...

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

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.

1

#include "irmp.c"

gefunden in main.c im Codevison Teil.

Warum das ?

... ... schrieb:
>

1

> #include "irmp.c"

2

>

>
> 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

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

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

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.

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____________

Hi,

jetzt muss ich wegen der Logging Funtkion einmal nachfragen:

1

                if (s_ctr > c_endBits)

2

                {                                                       // if stop condition (200 sequenced ones) meets, output on uart

3

                    uint16_t i;

4

5

                    for (i = 0; i < c_startcycles; ++i)

6

                    {

7

                        irmp_uart_putc ('0');                                   // the ignored starting zeros

8

                    }

Also werden immer 2 '0' ausgegeben? Denn c_startcycles = 2 ist fix 
defined!?

1

#define c_startcycles                     2                         // min count of zeros before start of logging

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

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

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.

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

Gruß
f

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

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

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.

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

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

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

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

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

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:

1

enum zahl { NU_LL, EINS, ZWEI, DREI, VIER};

2

3

uint8_t

4

funktion (enum zahl xx)

5

{

6

  xx >>= 4;

7

  return xx;

8

}

Dann steht in der lss-Datei:

1

00000046 <funktion>:

2

uint8_t funktion (enum zahl xx)

3

{

4

  xx >>= 4;

5

  return xx;

6

}

7

  46:  82 95         swap  r24

8

  48:  8f 70         andi  r24, 0x0F  ; 15

9

  4a:  08 95         ret

Die lss-Datei ist dann identisch beim Code von:

1

uint8_t funktion (uint8_t xx)

2

{

3

  xx >>= 4;

4

  return xx;

5

}

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

Beispiel B:

1

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

2

3

uint8_t

4

funktion (enum zahl xx)

5

{

6

  xx >>= 4;

7

  return xx;

8

}

Jetzt braucht die Beispiel-Funktion wesentlich mehr Speicherplatz:

1

00000046 <funktion>:

2

uint8_t

3

funktion (enum zahl xx)

4

{

5

  xx >>= 4;

6

  return xx;

7

}

8

  46:  85 95         asr  r24

9

  48:  85 95         asr  r24

10

  4a:  85 95         asr  r24

11

  4c:  85 95         asr  r24

12

  4e:  08 95         ret

EDIT:

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

Beispiel C:

1

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

2

3

uint8_t

4

funktion (enum zahl xx)

5

{

6

  46:  24 e0         ldi  r18, 0x04  ; 4

7

  48:  96 95         lsr  r25

8

  4a:  87 95         ror  r24

9

  4c:  2a 95         dec  r18

10

  4e:  e1 f7         brne  .-8        ; 0x48 <funktion+0x2>

11

  xx >>= 4;

12

  return xx;

13

}

14

  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

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

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

[...]
>> @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

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

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

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

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

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

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

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

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

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

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

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

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:

1

        case IRMP_NEC_PROTOCOL:

2

        {

3

           ...

4

        }

Darunter einfügen (also noch vor dem #endif:

1

        case IRMP_APPLE_PROTOCOL:

2

        {

3

            irsnd_protocol = IRMP_NEC_PROTOCOL; // APPLE protocol is NEC with fix bitmask instead of inverted command

4

5

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

6

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

7

8

            irsnd_buffer[0] = (address & 0xFF00) >> 8;                                                          // AAAAAAAA

9

            irsnd_buffer[1] = (address & 0x00FF);                                                               // AAAAAAAA

10

            irsnd_buffer[2] = (command & 0xFF00) >> 8;                                                          // CCCCCCCC

11

            irsnd_buffer[3] = 0x8B;                                                                             // 10001011

12

            irsnd_busy      = TRUE;

13

            break;

14

        }

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

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

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

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

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

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

Sorry, Anhang vergessen.

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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.

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

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

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

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

1

#define IRMP_REPETITION_TIME  (uint16_t)(F_INTERRUPTS * 100.0e-3 + 0.5)  // autodetect key repetition within 100 msec

in

1

#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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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:

1

#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:

1

#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

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

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

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

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

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

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:

1

#define IRMP_TIMEOUT_TIME                       16500.0e-6                    // timeout after 16.5 ms darkness

2

#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

ä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 ?

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

So, da ist dann mal der Scan von der FB mit NEC Protokoll.

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

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.

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

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

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

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 !

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

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ß

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

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

eku schrieb:

1

> #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.

1

> #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?