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 Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Gibt es einen Grund, warum der struct Name "IRMP_PACKED_STRUCT" in der 
32 bit Version fehlt (irmpsystem.h Zeile 227ff.)?
Und wo ist der Unterschied zwischen beiden?
1
#if IRMP_32_BIT == 1
2
3
typedef struct
4
{
5
    uint8_t                             protocol;                                   // protocol, e.g. NEC_PROTOCOL
6
    uint16_t                            address;                                    // address
7
    uint32_t                            command;                                    // command
8
    uint8_t                             flags;                                      // flags, e.g. repetition
9
} IRMP_DATA;
10
11
#else // not IRMP_32_BIT == 1
12
13
#if defined(PIC_C18)
14
#  define IRMP_PACKED_STRUCT
15
#else
16
#  ifndef IRMP_PACKED_STRUCT
17
#    define IRMP_PACKED_STRUCT          __attribute__ ((__packed__))
18
#  endif
19
#endif
20
21
typedef struct IRMP_PACKED_STRUCT
22
{
23
    uint8_t                             protocol;                                   // protocol, e.g. NEC_PROTOCOL
24
    uint16_t                            address;                                    // address
25
    uint16_t                            command;                                    // command
26
    uint8_t                             flags;                                      // flags, e.g. repetition
27
} IRMP_DATA;
28
29
#endif // IRMP_32_BIT == 1

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Armin,

ich habe Deine Mail mit gleichlautendem Text bereits erhalten, hatte 
aber noch keine Zeit, alle Fragen zu beantworten. Ich fange mal hier an.

Armin J. schrieb:

> ich habe mal eine Testprogramm geschrieben, das alle Protokolle sendet
> und die dann mit AllProtocols auf einem anderen Arduino empfangen.
>
> 
https://github.com/ukw100/IRMP/blob/master/examples/SendAllProtocols/SendAllProtocols.ino

Habe ich mir noch nicht angeschaut.

> dabei ist mir ein Fehler aufgefallen:

Danke, werde ich korrigieren fürs nächste Release.

> Einige Protokolle z.B. RECS80, RC6, RECS80EX, RC6A, lassen sich nur mit
> einem guten Empfänger IC decodieren, aber viele gehen so.

Was heißt "guter Empfänger"? Von der Frequenz her passender?

> Ich habe auch  die direkte Verbindung getestet, das geht jetzt mit
> IRSND_GENERATE_NO_SEND_RF aber da klappt sogar NEC nicht.

Diese Änderung IRSND_GENERATE_NO_SEND_RF ist offenbar von Dir. Wenn 
sogar NEC nicht geht, muss die Implementierung fehlerhaft sein.

> Die Protokolle A1TVBOX + TELEFUNKEN + ab FAN bis IRMP16 können gar nicht
> decodiert werden.

dito.

> Bei FDC und SIEMENS bekomme ich das Protokoll zwar erkannt, aber das
> Comand stimmt nicht.

dito.

> Ich hab noch nicht alle überprüft, aber die Inkonsistenzen sind doch
> hoch.

In einer Unix-Pipe "irsnd ... | irmp ..." funktionieren sie alle, wenn 
man diejenigen Protokolle, welche zueinander in "Konkurrenz" stehen, 
speziell betrachtet.

> Hast Du eine Erklärung dafür? Hab ich was übersehen? Hast Du mal alle
> getestet?

Ich teste immer mit oben angegebener Pipe, ist im Artikel auch so 
dokumentiert.

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Was heißt "guter Empfänger"? Von der Frequenz her passender?

Ein TSOP 31238 Modul, nicht die VS1838B Module vom Chinesen.
Das 31238 ist aber eigentlich schlechter, da es die Marks um 60 statt 
-20 Microsekunden wie bei VS1838B verlängert.

> Diese Änderung IRSND_GENERATE_NO_SEND_RF ist offenbar von Dir. Wenn
> sogar NEC nicht geht, muss die Implementierung fehlerhaft sein.

Ist klar!
In dem Fall IRSND_GENERATE_NO_SEND_RF wird nur ein Low ausgegeben, statt 
dem 38 kHz Signal. Sooo viel falsch machen kann man da gar nicht.

Aber vielleicht liegt es daran, dass ich zum Senden 19 kHz benutze und 
zum Empfangen die standard 15 kHz?
Die ersten 8 Protokolle (einschliesslich DENON) klappen bei 
IRSND_GENERATE_NO_SEND_RF, nur NEC wird als Siemens erkannt (eigentlich 
sehr komisch, aber wahr!), danach gibt es teilweise unerkannte 
Protokolle.
Mit IR Übertragung (da kommt das Pulse Shaping des Empfängers Moduls 
dazu), klappt NEC und RC6, aber dafür RECS80 nicht.

> Ich teste immer mit oben angegebener Pipe, ist im Artikel auch so
> dokumentiert.

Ist das der Grund, warum der Telefunken Fehler bisher nicht aufgefallen 
ist?

Ausserdem konnte ich die Dokumentation auch nach längerem Suchen nicht 
finden :-(

IRMP ist schon eine tolle Library, aber wenn man damit einen Sender 
bauen will, ist es doch wohl nur eingeschränkt zu empfehlen, was sehr 
schade ist.

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Armin J. schrieb:
> Mit IR Übertragung (da kommt das Pulse Shaping des Empfängers Moduls
> dazu), klappt NEC

Wenn NEC über IR funktioniert, dann sehe ich wirklich nicht, warum das 
über Draht nicht funktionieren soll - im Gegenteil.

Ich habe hier auf µc.net auch schon einigen Anwendern empfohlen, für 
Kabel-Übertragungen NEC zu verwenden, habe ihnen auch die entsprechenden 
Tipps gegeben, wie sie im Source die Modulation abstellen können. Es hat 
bei allen auch so perfekt funktioniert. Allerdings waren das allesamt 
reinrassige AVR-Anwendungen ohne Arduino-Laufzeitsystem.

Ich weiß von Hörensagen, dass Arduino selbst einige Timer in Beschlag 
nimmt. Kann es sein, dass diese Arduino-Timer dafür sorgen, dass der 
IRSND-Output einen Jitter hat?

> Aber vielleicht liegt es daran, dass ich zum Senden 19 kHz benutze und
> zum Empfangen die standard 15 kHz?

Kommt auf das Protokoll an. Warum nimmst Du ausgerechnet 19kHz?

> aber dafür RECS80 nicht.

RECS80 verwendet sehr kurze Pulse, es könnte sein, dass 15KHz dafür zu 
wenig ist. Bei 15kHz sind das höchstens 4 Low-Messungen für einen Puls. 
Ich habe auch in Erinnerung, dass ich dafür früher als Empfehlung 20kHz 
in irmpconfig.h geschrieben habe. Ich habe auch nochmal nachgeschaut. 
Jetzt steht da 15kHz drin... sollte ich wieder ändern.

Schaue Dir bitte auch mal IR-Data/recs80-15kHz.txt an. Da siehst Du die 
extrem kurzen Pulse (4 Nullen).

> Ist das der Grund, warum der Telefunken Fehler bisher nicht aufgefallen
> ist?

Keine Ahnung, warum. Es könnte sein, dass der Fehler sich erst nach den 
Telefunken-Tests eingeschlichen hat.

> In dem Fall IRSND_GENERATE_NO_SEND_RF wird nur ein Low ausgegeben, statt
> dem 38 kHz Signal. Sooo viel falsch machen kann man da gar nicht.

Okay, dann schalte auf der IRMP-Seite das Logging ein und schicke mir 
die Scans. Dann kann ich mehr dazu sagen.

> IRMP ist schon eine tolle Library, aber wenn man damit einen Sender
> bauen will, ist es doch wohl nur eingeschränkt zu empfehlen, was sehr
> schade ist.

Armin, dieser Allgemeinplatz stimmt so nicht. Du testest das unter 
Bedingungen, die ich nicht kenne. Und das nicht nur mit eigenhändigen 
Source-Änderungen, sondern auch unter einer Arduino-Laufzeitumgebung, wo 
es (für mich) viele Unbekannte gibt.

Ich kann Dir auch gern die notwendigen Änderungen schicken, um dem IRSND 
in der  nativen Umgebung (ohne Arduino) die Modulation abzugewöhnen. 
Vielleicht entdeckt man dann ja im Verhalten einen Unterschied.

> Ausserdem konnte ich die Dokumentation auch nach längerem Suchen nicht
> finden :-(

Siehe Kapitel IRMP: IRMP unter Linux und Windows und 
IRSND: IRSND unter Linux und Windows, speziell den Abschnitt "IRSND 
unter Windows".

Dort steht:
1
Nun kann man direkt mit IRMP anschließend testen, ob das erzeugte Telegramm auch korrekt ist:
2
3
           ./irmp-15kHz < nec.txt
4
5
bzw. unter Windows:
6
7
           irmp.exe < nec.txt
8
9
Das Ganze geht auch ohne Zwischendatei, nämlich:
10
11
           ./irsnd-15kHz 2 00FF 0001 | ./irmp-15kHz
12
13
bzw. unter Windows:
14
15
           irsnd.exe 2 00FF 0001 | irmp.exe
16
17
IRMP gibt dann als Ergebnis folgendes aus:
18
19
           11111111000000001000000001111111 p =  2, a = 0x00ff, c = 0x0001, f = 0x00
20
21
IRMP konnte also aus dem von IRSND generierten Frame wieder das Protokoll 2, Adresse 0x00FF und Kommando 0x0001 decodieren.

Ich muss zugeben, dass die Überschrift "IRSND unter Windows" hier falsch 
ist. Da fehlt eine Zwischenüberschrift, da der zitierte Text für IRSND 
für Linux und Windows gilt. Offenbar ist diese beim Split des 
IRMP-Artikels vor langer Zeit verlorengegangen.

Also bitte:

Schicke mir die Scans und ich sage Dir mehr.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich muss da nochmal nachhaken:

Armin J. schrieb:
> Die ersten 8 Protokolle (einschliesslich DENON) klappen bei
> IRSND_GENERATE_NO_SEND_RF, nur NEC wird als Siemens erkannt (eigentlich
> sehr komisch, aber wahr!),

Du hast geschrieben, dass Du IRMP mit 15kHz laufen lässt und dann 
SIEMENS statt NEC erkannt wird.

Das ist eigentlich unmöglich:
1
cc -Wall -DF_INTERRUPTS=10000 irmp.c -o irmp-10kHz
2
In file included from irmp.c:23:0:
3
irmp.h:212:4: warning: #warning F_INTERRUPTS too low, SIEMENS protocol disabled (should be at least 15000) [-Wcpp]

Für SIEMENS muss eine höhere Frequenz eingestellt werden, damit das 
Protokoll überhaupt aktiviert wird.

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Siehe Kapitel IRMP unter Linux und Windows und
> IRSND unter Linux und Windows, speziell den Abschnitt "IRSND unter
> Windows".

Die Links sind für mich leer :-(
1
IRMP unter Linux und Windows
2
Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)
3
4
Diese Seite enthält momentan noch keinen Text. Du kannst sie erstellen, ihren Titel auf anderen Seiten suchen oder die zugehörigen Logbücher betrachten.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Armin J. schrieb:
> Gibt es einen Grund, warum der struct Name "IRMP_PACKED_STRUCT" in der
> 32 bit Version fehlt (irmpsystem.h Zeile 227ff.)?

Weil derjenige, der die 32-Bit-Version in IRMP eingebaut hat, eine Menge 
außer acht gelassen hat. Nein, das war nicht ich. Leider ist es meistens 
so, dass diejenigen, die mir Source-Änderungsvorschläge zukommen lassen, 
das große Ganze dabei nicht im Blick haben und nur ihre konkrete Lösung 
für ihr meist ganz spezifisches Problem sehen.

Dann kommt da eine unvollständige Lösung raus, die erst ein halbes Jahr 
später bemerkt wird. Mittlerweile bin ich da auch viel skeptischer und 
baue Änderungsvorschläge nur mit Unwillen ein, weil ich meist auch nicht 
übersehen kann, an welcher Ecke das Ganze dann nach hinten losgeht.

Und das, obwohl ich da mittlerweile eine umfangreiche Test-Suite unter 
IR-Data gebaut habe, die jedes Mal, bevor ich ein Release rausgebe, 
komplett durchlaufen muss.

Ich werde wohl in der nächsten Version die 32-Bit-Variante wieder 
entfernen. Diese wurde lediglich dafür eingebaut, um eine ganz spezielle 
Fernbedienung mit 32-Bit-Merlin-Protokoll vollständig dekodieren zu 
können - ohne dabei zu bedenken, dass dabei alle anderen FBs, welche das 
16-Bit-Merlin-Protokoll verwenden, dann nicht mehr decodiert werden 
können. Auf Deutsch: Dieser Patch ist unbrauchbar. Also fliegt er in der 
nächsten Version wieder raus.

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Kommt auf das Protokoll an. Warum nimmst Du ausgerechnet 19kHz?

Weil das die Hälfte von 38 kHz ist. Ich mache beim Senden bit banging 
mit 76 kHz. Im Oszilloskop sind die Impulse und Pausen 580 us statt 560 
us lang. Bei 15 kHz wären es 600 us.

> Für SIEMENS muss eine höhere Frequenz eingestellt werden, damit das
> Protokoll überhaupt aktiviert wird.
15000 reichen aber, 14999 vielleicht nicht...

> Armin, dieser Allgemeinplatz stimmt so nicht. Du testest das unter
> Bedingungen, die ich nicht kenne. Und das nicht nur mit eigenhändigen
> Source-Änderungen, sondern auch unter einer Arduino-Laufzeitumgebung, wo
> es (für mich) viele Unbekannte gibt.
Na Ja soooo unbekannt sind die Arduino Bedingungen auch nicht und die 
Hardware ist unter 5€ zu haben.
Aber als Experte kann ich dir sagen, dass der einzige Interrupt 1 mal 
pro Millisekunde für 15 Mikrosekunden ist, sonst hast Du für IRMP nur 
nacktes Blech.
Die Timer werden auch unter Arduino von Hand gestrichelt. und das Bit 
setzen mit digitalWriteFast ist 1 clock.

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Armin J. schrieb:
> Die Links sind für mich leer

Sorry, mein Fehler, ich hatte sie zu stark gekürzt. Ich habe das jetzt 
im Beitrag korrigiert. Hier nochmal:

IRMP: IRMP unter Linux und Windows
IRSND: IRSND unter Linux und Windows

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Armin J. schrieb:
> gestrichelt
->gestreichelt

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Armin J. schrieb:
> Weil das die Hälfte von 38 kHz ist. Ich mache beim Senden bit banging
> mit 76 kHz. Im Oszilloskop sind die Impulse und Pausen 580 us statt 560
> us lang. Bei 15 kHz wären es 600 us.

Ich schaue mir Deine Änderungen dazu an und vergleiche es mit meinen 
Änderungen bzgl. Kabelübertragung, die nachweislich funktioniert haben - 
gerade für NEC.

> Für SIEMENS muss eine höhere Frequenz eingestellt werden, damit das
> Protokoll überhaupt aktiviert wird.
>
> 15000 reichen aber, 14999 vielleicht nicht...

Ich habe solche Sperren nicht ohne Grund in den Source eingebaut. Dabei 
habe ich auch die nötigen Toleranzen in die Bewertung, ob 15000 für ein 
Protokoll reicht, einfließen lassen. Kann ja sein, dass eine bestimmte 
SIEMENS-FB auch mit 15000 erkannt wird. Es kann aber auch sein, dass 
eine andere SIEMENS-FB nicht damit funktioniert oder das Aktivieren von 
SIEMENS sogar die Erkennung eines anderen Protokolls aufgrund der 
"schlechten Auflösung" behindert!

Wenn Du solche Sperren wieder entfernst, warum soll ich mich dann Deiner 
Meinung nach noch hier rechtfertigen?

Wird denn NEC erkannt, wenn Du SIEMENS manuell deaktivierst?

Schicke mir bitte IRMP-Scans

1. NEC von einer NEC-FB (als Zeitreferenz)
2. NEC von kabelgebundenem IRSND
3. RS80 von kabelgebundenem IRSND

> Na Ja soooo unbekannt sind die Arduino Bedingungen auch nicht und die
> Hardware ist unter 5€ zu haben.

Ich benutze Arduino nicht - schon gar nicht für AVRs. Nur ab und zu 
gezwungenermaßen für ESP8266, weil es da keine richtige Alternative 
gibt. Und ich werde mir Arduino nicht aufzwingen lassen. Ich finde ja 
Deine Motivation gut, Dich für IRMP/IRSND unter Arduino einzusetzen, 
aber ich kann Dir nur sagen, dass mich überhaupt nichts motivert, das 
selber unter Arduino zum Laufen zu bringen. Sonst hätte ich das längst 
schon gemacht!

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Wenn Du solche Sperren wieder entfernst, warum soll ich mich dann Deiner
> Meinung nach noch hier rechtfertigen?

Hallo, was ist denn das?
Ich habe F_INTERRUPTS  auf 15000 so wie im standard!
Und dann greift die Sperre F_INTERRUPTS < 15000
num mal nicht!!!

von Armin J. (arminj)


Bewertung
-2 lesenswert
nicht lesenswert
Frank M. schrieb:
> das selber unter Arduino zum Laufen zu bringen. Sonst hätte ich das längst
> schon gemacht!
IDE Installieren, Library laden https://www.ardu-badge.com/IRMP, 
Beispiel auswählen, übersetzen und hochladen. Serial Monitor anwerfen, 
freuen.
Bis auf den ersten Schritt mache ich alles in unter 2 Minuten 
(initial!).
Das nächste Beispiel dauert dann nur noch eine Minute :-)

Schade, dass viele noch glauben, Arduino sei nur Bastelkram. Einen AVR 
kann man bis auf den Bootloader komplett in Arduino auf dem nackten 
Blech programmieren, auch den 1 ms Timer kann man auschalten.
Man kann aber auch die Arduino Annehmlichkeiten verwenden, wenn man sie 
benötigt.
Und das flashen eines Programms geht schon super schnell.
Der Compiler und die Flags werden auch gepflegt!

Die IDE insbesondere der Editor is zugegebenermaßen grottig, aber wer 
eine bessere IDE sucht, nimmt eben das Eclipse Plugin Sloeber 
https://eclipse.baeyens.it.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Armin J. schrieb:
> Hallo, was ist denn das?
> Ich habe F_INTERRUPTS  auf 15000 so wie im standard!
> Und dann greift die Sperre F_INTERRUPTS < 15000
> num mal nicht!!!

Okay, sorry, mein Fehler. Ich habe hier ein Makefile unter Linux, 
welches irmp direkt für 10kHz, 15kHz und 20kHz übersetzt.
1
make -f makefile.lnx
2
cc -Wall -DF_INTERRUPTS=10000 irmp.c -o irmp-10kHz
3
In file included from irmp.c:23:0:
4
irmp.h:212:4: warning: #warning F_INTERRUPTS too low, SIEMENS protocol disabled (should be at least 15000) [-Wcpp]
5
cc -Wall -DF_INTERRUPTS=15000 irmp.c -o irmp-15kHz
6
cc -Wall -DF_INTERRUPTS=20000 irmp.c -o irmp-20kHz

Die Fehlermeldung kommt lediglich für 10000 kHz, ich hatte mich da in 
der Zeile verguckt. Du hast recht, für 15kHz wird SIEMENS nicht 
ausgeschlossen.

Nichtsdestotrotz: Wenn die Verbindung IRSND -> IRMP via IR einwandfrei 
funktioniert, warum sollte das bei Kabelverbindung (welche ein besseres 
Medium ist) nicht gehen?

Wie schon gesagt: Ich schaue mir Deine Nicht-Modulations-Routinen im 
IRSND an und werde sie mit meinen vergleichen. Ich hatte die dafür 
notwendigen Modifikationen für Kabelvariante bereits mehrfach hier im 
Forum gepostet - muss nicht unbedingt in diesem Thread gewesen sein.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Armin J. schrieb:
> IDE Installieren, Library laden https://www.ardu-badge.com/IRMP,
> Beispiel auswählen, übersetzen und hochladen. Serial Monitor anwerfen,
> freuen.

IDE habe ich bereits wegen ESP8266, okay. Aber warum muss ich mir noch 
eine Plattform ans Bein binden, wenn ich sie nicht brauche? Ich bin 
mittlerweile komplett auf STM32 übergegangen und da brauche ich Arduino 
als Programmierumgebung weiß-gott-nicht.

> Bis auf den ersten Schritt mache ich alles in unter 2 Minuten
> (initial!).

Ich muss erstmal:

- Eine halbe Stunde suchen, um überhaupt noch 2 AVRs zu finden
- Mir 2 Platinen löten oder Steckbretter aufbauen
- 2 Programmieradapter dranbauen
- Meinen alten AVR-Flasher suchen
- Testen

Dann sind 2-3 Stunden um, die mir persönlich überhaupt nichts bringen, 
sondern mir meine wertvolle Freizeit rauben.

Da schaue ich lieber in Deinen Source, wie Du die IR-Modulation durch 
Bit-Banging ersetzt hast. Das geht schneller.

> Das nächste Beispiel dauert dann nur noch eine Minute :-)

Und dann? Schmeiße ich die Arduino-Boards in die Ecke oder verkaufe die 
an Dich? Ich brauche die nicht. Verkaufst Du anderen auch 
Waschmaschinen, obwohl sie einen Herd suchen?

> Schade, dass viele noch glauben, Arduino sei nur Bastelkram.

Das ist mir wirklich vollkommen egal, ob das Bastelkram ist. Ich brauche 
es einfach nicht, genauso, wie ich gerade keine Waschmaschine brauche - 
weil ich bereits eine habe. Ich weiß nur, dass viele Arduino-Anwender 
sich einfach irgendwelche Libs ohne Sinn und Verstand zusammenklicken. 
Und dann nennen sie das "Programmieren". Dann schlagen sie im Forum auf 
- ohne überhaupt Ahnung davon zu haben, was sie da eigentlich gemacht 
haben. Sie können dann noch nichtmals ihre Probleme konkret schildern.

Okay, es mag da Ausnahmen geben - Dich natürlich eingeschlossen. ;-)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Da schaue ich lieber in Deinen Source, wie Du die IR-Modulation durch
> Bit-Banging ersetzt hast.

Armin, wo finde ich Deine Änderungen bzgl. IRSND_GENERATE_NO_SEND_RF? 
Auf github finde ich nix in irsnd.c.h.

Hier ein paar Links, wo die User irsnd.c ohne Modulation, entweder über 
Kabel und/oder RF433 MHz erfolgreich getestet haben - nachdem Sie meine 
Tipps zur Entfernung der Modulation im Source umgesetzt hatten. 
Funktionierte selbstverständlich auch mit NEC:

Beitrag "IRMP und IRSND als Protokoll für 433 MHz Sender/Empfänger funktioniert nicht so ganz"
Beitrag "IRSND Ausgabesignal invertieren"
Beitrag "IRSND läuft nicht (richtig)"

Tipp: Um die Modulation herauszuwerfen, sind Anpassungen in irsnd_on(), 
irsnd_off() und irsnd_init() nötig - letzteres auch wegen komplementärem 
Ruhepegel.

von Armin J. (arminj)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dass Du jetzt auf STM32 bist, kann ich gut verstehen, damit hab ich 
damals angefangen :-). Das war mir aber gar nicht so klar, und du hast 
Recht, dafür ist Arduino ziemlich Schrott.

> Armin, wo finde ich Deine Änderungen bzgl. IRSND_GENERATE_NO_SEND_RF?
> Auf github finde ich nix in irsnd.c.h.

Ich habe mein Zeug alles in den irmpArduino*, irsndArduino* und den 
IRTimer* Dateien gekapselt, um Dich nicht zu ärgern ;-)


Kannst Du mal deine Tests mit unterschiedlichen Frequenzen laufen 
lassen?

Wenn Ich Siemens ausschalte, wird NEC erkannt.

Ich hänge mal eine Datei mit den Sende und Empfangsprotokoll ran. Da ist 
nur beim Empfang Siemens ausgeschaltet. Daran kann man die 
Inkonsistenzen, die ich meine, schwarz auf weiss sehen.
Das mit dem Bit bang beim Senden mache ich um einen 2. Timer für die 38 
kHz Erzeugung zu sparen.
Das ganze wird aber auf den STM32 auch nicht anders sein.

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Armin J. schrieb:
> Ich habe mein Zeug alles in den irmpArduino*, irsndArduino* und den
> IRTimer* Dateien gekapselt, um Dich nicht zu ärgern ;-)

Ah, okay, werde ich mir anschauen. Vielleicht schaffe ich dies dieses 
Wochenende.

> Kannst Du mal deine Tests mit unterschiedlichen Frequenzen laufen
> lassen?

Du meinst, unter Linux? Die Pipe gibt keine Timestamps mit rüber, 
sondern nur Nullen und Einsen - genau wie es IRMP_LOGGING auch tut. Aus 
diesem Grunde funktioniert die Pipe nur bei IRSND und IRMP, welche mit 
gleicher Frequenz übersetzt wurden.

Aber Deine angehängte Log-Datei ist ganz interessant. Schon ein 
Querlesen zeigt mir, dass da noch nachgebessert werden muss: Es macht 
zum Beispiel keinen Sinn, einen größeren Wert für command vorzusehen, 
als das Protokoll überhaupt zur Verfügung hat.

Beispiel: Nikon hat fürs Kommando nur 2 Bits. Ein command mit dem Wert 
0x54 wird dann bereits im IRSND gekürzt auf 2 Bits und damit 0x00. Was 
dann IRMP auch korrekt mit command=0x00 anzeigt ;-)

Aber ich sehe auch noch was anderes, zum Beispiel dieses:
1
Protocol=FAN  Address=0x61 Command=0x61 Repeats=1         P=NUBERT  A=0x0 C=0x30

Wie ich erst Monate nach Implementierung von FAN und NUBERT erkannt 
habe, handelt es sich hier um dasselbe Protokoll - aber von IRMP auf 
verschiedene Weise aufgrund der dürftigen Datengrundlage interpretiert, 
was das letzte Bit angeht. Das erklärt auch die Diskrepanz von
1
C = 0x30 * 2 + 1 = 0x61
Ich werde beide Protokolle bei Gelegenheit zusammenführen und ihm dann 
wahrscheinlich den Namen NUBERT geben. FAN entfällt dann.

Auch Deine anderen mit Fragezeichen gekennzeichneten Zeilen werde ich 
mir genauer anschauen, wobei ich mir aber ziemlich sicher bin, dass es 
sich hier größtenteils um Protokoll-Konflikte handelt, die ich mit der 
Statemachine, welche on-the-fly dekodiert, nicht mehr auflösen kann. 
Vermutlich kann man auch hier durch gezieltes Deaktivieren von 
bestimmten Protokollen die anderen auch zum Leben erwecken ;-)

Wirklich alle Protokolle auf IRMP einzuschalten ist schlicht unmöglich. 
Aber das kann man nun wirklich nicht IRSND anlasten - egal ob 
kabelgebunden oder über IR.

Auch meine Test-Suite setzt zwar alle Protokolle in irmpconfig.h auf 1, 
lässt aber durchaus den Compiler diejenigen Protokolle wieder 
zurücksetzen, welche in Konflikt mit anderen stehen. Um das allumfassend 
zu lösen, muss man den Gedanken der On-The-Fly-Dekodierung fallenlassen 
und stattdessen erst den kompletten Frame einlesen und dann als 
Gesamtheit dekodieren. Dann kann man durch Versuch-und-Irrtum immer 
wieder von vorn anfangen, also den Frame "zurückspulen". Das geht aber 
On-The-Fly nicht.

Jetzt kommt die Frage nach Nutzen vs. Aufwand. Die meisten IRMP-Anwender 
interessieren sich für Dekodierung eines konkreten Protokolls, manche 
für gleichzeitige Dekodierung einer Handvoll Protokolle. Es gibt 
eigentlich keinen, der eine eierlegende Wollmilchsau will, also alle 
unterstützten Protokolle zur gleichen Zeit dekodieren möchte. Ich lege 
mir jedenfalls keine 50 Fernbedienungen gleichzeitig auf den 
Wohnzimmertisch ;-)

Noch etwas zu:
1
IRMP16  Address=0x27 Command=0x27            P=ONKYO  A=0x27 C=0x27

Das IRMP16-Protokoll habe ich "erfunden", um damit effizient und 
möglichst fehlerfrei Daten zwischen 2 Mikrocontrollern via IR zu 
übertragen. Da hier ein konkretes Szenario vorliegt, wo man 
praktischerweise nur dieses eine Protokoll aktiviert und alle anderen 
deaktiviert, habe ich auf etwaige Konflikte wie z.B. ONKYO keine 
Rücksicht genommen. Von daher halte ich den Einsatz von IRMP16 in einem 
ALL-Protocols-Test für nicht sinnvoll.

Mein Fazit:

Dein All-Protocols-Ansinnen ist ein Anspruchdenken, was prinzipbedingt 
nicht hundertprozentig erfüllt werden kann - und auch gar nicht erfüllt 
sein muss. Es reicht, wenn die Anwender(!) das bekommen, was sie wollen.

> Wenn Ich Siemens ausschalte, wird NEC erkannt.

Aha. IRSND ist also vermutlich gar nicht schuld. :)

Fragt sich nur noch, warum IRMP kabelgebunden auf SIEMENS beharrt. Die 
Timings sind hier durchaus unterscheidbar und sollten auch nicht in 
Konflikt stehen.

Hier helfen wirklich nur Scans weiter. Wäre klasse, wenn Du hier welche 
mittels IRMP_LOGGING erstellen könntest. Die kann ich dann direkt in den 
IRMP unter Linux reinschicken und das Verhalten debuggen.

Übrigens wurden mit dieser Vorgehensweise mindestens 80% aller von IRMP 
unterstützten Protokolle in den IRMP eingebaut: Die Leute haben mir ihre 
Scans geschickt, ich habe sie mit
1
     irmp-15kHz -a < scan.txt
analysiert, dann das Protokoll implementiert, mit
1
     irmp-15kHz -v < scan.txt
debuggt und letztendlich mit
1
     irmp-15kHz < scan.txt
den Abschluss-Test gemacht. Dafür brauchte ich weder eine Fernbedienung 
noch einen µC nebst TSOP.

> Das mit dem Bit bang beim Senden mache ich um einen 2. Timer für die 38
> kHz Erzeugung zu sparen.

Das ist ja auch richtig, wenn der Pegelwechsel auch mit dem 1. Timer 
angesteuert wird. Deine Angabe von 580us statt 560us bei 19kHz ist auch 
kalkulierbar:
1
Raster ist: 1 / 19000 = 52,6315 us
Der an 560 nächstgelegene ganzzahlige Wert als Multiplikator ist 11:
1
11 * 52,6315 us = 579 us

Ebenso kann man auch den Fehler für 15kHz berechnen:
1
Raster ist: 1 / 15000 = 66,6667 us
Der an 560 nächstgelegene ganzzahlige Wert als Multiplikator ist 9:
1
9 * 66,6667 us = 600 us
Obwohl eigentlich
1
8 * 66,6667 us = 533 us
noch minimal besser ist. Hmmm, werde ich bei Gelegenheit mal 
untersuchen.

Aber 580 oder 600 us für NEC sind kein Problem, denn IRMP arbeitet hier 
mit Toleranzen von satten 30%.

> Das ganze wird aber auf den STM32 auch nicht anders sein.

Hast Du Dir mal meine Links auf die verschiedenen IRSND-Threads 
angeschaut? Da hatte ich die entsprechenden Tipps gegeben, wie man für 
AVR (nicht STM32!) die Modulation ausschaltet. Wichtig ist auch die 
Einstellung des Ruhepegels in irsnd_init(), denn der Pin muss hier für 
eine Kabelverbindung auf HIGH statt LOW gestellt werden. Zumindest ist 
das für den ersten zu sendenden Frame wichtig. Danach sollte der 
Ruhepegel sowieso korrekt stehen.

: Bearbeitet durch Moderator
von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Wow, soviel Text, ich könnte das nicht und bin ehrlich beeindruckt!

> Auch Deine anderen mit Fragezeichen gekennzeichneten Zeilen werde ich mir 
genauer anschauen, wobei ich mir aber ziemlich sicher bin, dass es sich hier 
größtenteils um Protokoll-Konflikte handelt, die ich mit der Statemachine, welche 
on-the-fly dekodiert, nicht mehr auflösen kann.

Verstehe ich das richtig, dass die Statemachine da auf der falschen 
Fährte ist und dann nicht fertig werden kann?
Dann muss ich die aus den 39 gleichzeitig zu Empfangenden rausnehmen.
Vielleicht kann man ja die Konflikte dann auch per #error ausgeben.

> Die meisten IRMP-Anwender interessieren sich für Dekodierung eines konkreten 
Protokolls
Es gibt aber auch viele Anwender, die eine FB haben und das Signal 
verarbeiten wollen, ohne das Protokoll zu kennen. Dafür ist das mit den 
39 gleichzeitig eben perfekt!
Und es ist einfach schön sagen zu können "seht her, diese super Library 
kann 39 Protokolle simultan empfangen" (was übrigens der Grund ist, dass 
es in Tasmota integriert werden soll :-))
Du siehst, ich bin auch ein bischen stolz auf Deinen Code.

> Das IRMP16-Protokoll habe ich "erfunden",...
Ich habs schon aus der All Liste entfernt.

> Aha. IRSND ist also vermutlich gar nicht schuld. :)
Schuld ist eh keiner, nur wundert es mich auch, warum die Statemachine 
gerade dabei auf die falsche Fährte gelockt wird.

> Dafür brauchte ich weder eine Fernbedienung noch einen µC nebst TSOP.
Aber die Scans enthalten ja das Verhalten des unbekannten User 
Empfängers, also das Verlängern des Marks / Verkürzen des Spaces. Und 
mit einem anderen Empfänger gibt es dann Probleme, die sind echt sehr 
unterschiedlich, wie ich oben schon geschrieben habe, also von 60 bis 
-20 us Verlängerung des Marks. Und ausserdem sendet man ja dann die 
verlängerten Marks, die dann vom Empfänger wieder verlängert werden.
Ist schwierig, ich weiss, andere Libraries haben dafür z.B. #define 
MARK_EXCESS_MICROS    100, die sie beim Timing berücksichtigen. Ist nur 
kompliziert, das nachträglich einzubauen.

> Hast Du Dir mal meine Links auf die verschiedenen IRSND-Threads angeschaut?
Hab ich nicht, aber ich habs wahrscheinlich genau so umgesetzt wie dort 
beschrieben, es funktioniert ja auch :-).

Den Scan mache ich jetzt, aber stört da die serielle Ausgabe nicht das 
Timing?

von Armin J. (arminj)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier die Tabelle mit einem STM32 BluePill als Empfänger, der Sender ist 
immer noch ein AVR. Es gibt merkwürdigerweise einige Unterschiede.

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Das mit den Scans geht nicht. Die ANALYZE_PRINTF5 etc schreiben auf 
stdout und den gibts ohne Runtime nicht.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Armin und Frank,

ich habe auch mal getestet, auf zwei STM32F103 über IR mit TSOP4838 aus 
China.
Dabei waren alle mit 20kHz möglichen Protokolle an.
So wie bei Armin geht A1TVBOX und MITSU_HEAVY nicht, SIEMENS wird als 
A1TVBOX erkannt, SAMSUNG48 wird verdoppelt/wiederholt erkannt, bei DENON 
und FDC keine Wiederholung.
Im Gegensatz zu Armin geht TELEFUNKEN, aber FDC nicht.
BANG_OLUFSEN, Lego gehen auch nicht.
RECS80 und RECS80EX gehen selten.

Wenn ich bescheiden bin, und nur die ersten ca. 15 nicht-exotischen 
Protokolle aktiviere, geht fast alles. Nur SIEMENS wird nicht erkannt 
und bei SIRCS und DENON stimmt die Adresse nicht. IRSND muss mit 20kHz 
laufen, mit 15 kHz wird fast nichts erkannt.

Bei den Tests habe ich die Firmware aus 
https://github.com/j1rie/IRMP_STM32 benutzt.

Was ganz anderes: Es gibt von mir auch einen Tastatur-IR-Empfänger:
https://www.vdr-portal.de/forum/index.php?thread/132289-irmp-auf-stm32-ein-usb-hid-keyboard-ir-empf%C3%A4nger-einschalter-mit-wakeup-timer/
https://github.com/j1rie/IRMP_STM32_KBD
Das wäre vielleicht was für die Link-Sammlung.

von Klaus R. (klaus2)


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> BANG_OLUFSEN, Lego gehen auch nicht.

...interessant, hatte mit nämlich mal ne universal FB gebaut, die zwar 
alles mögliche kann, aber das eigentliche Ziel, eine "kleine Kopie" des 
B&O MCP5500 Monsters nicht hinbekommen hat.

Klaus.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:

> Dabei waren alle mit 20kHz möglichen Protokolle an.
> So wie bei Armin geht A1TVBOX und MITSU_HEAVY nicht, SIEMENS wird als
> A1TVBOX erkannt, SAMSUNG48 wird verdoppelt/wiederholt erkannt, bei DENON
> und FDC keine Wiederholung.
> Im Gegensatz zu Armin geht TELEFUNKEN, aber FDC nicht.
> BANG_OLUFSEN, Lego gehen auch nicht.
> RECS80 und RECS80EX gehen selten.

Danke, werde ich mir bei Gelegenheit anschauen.

> Was ganz anderes: Es gibt von mir auch einen Tastatur-IR-Empfänger:
> 
https://www.vdr-portal.de/forum/index.php?thread/132289-irmp-auf-stm32-ein-usb-hid-keyboard-ir-empf%C3%A4nger-einschalter-mit-wakeup-timer/
> https://github.com/j1rie/IRMP_STM32_KBD
> Das wäre vielleicht was für die Link-Sammlung.

Sicher, nehme ich auf :)

Gruß und Dank,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> Jörg R. schrieb:
> BANG_OLUFSEN, Lego gehen auch nicht.
>
> ...interessant, hatte mit nämlich mal ne universal FB gebaut, die zwar
> alles mögliche kann, aber das eigentliche Ziel, eine "kleine Kopie" des
> B&O MCP5500 Monsters nicht hinbekommen hat.

B&O läuft mit 455(!) kHz Modulation, das ist mit einem 38kHz-TSOP bei 
bestem Willen nicht zu empfangen. Als ich damals B&O eingebaut habe, hat 
das bei einem User, der für mich das B&O-Protokoll scannte, auch 
funktioniert - aber nur mit diesem speziellen TSOP. Die Bezugsquelle 
wurde auch genannt. Meiner Erinnerung nach war das in diesem Thread.

von Klaus R. (klaus2)


Bewertung
0 lesenswert
nicht lesenswert
...ja, das weiß ich - natürlich habe ich den korrekten TSOP. Die FB 
quittiert auch den korrten Empfang. Nur reagiert die B&O nicht drauf. 
Bei allen anderen geräten im haushalt geht die Universal-FB...aber mgl, 
dass B&O MCP5500 ein anderes Protokoll verwendet...denn die FB ist IR, 
aber *bi*-direktional :)

Klaus.

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> Bei allen anderen geräten im haushalt geht die Universal-FB...aber mgl,
> dass B&O MCP5500 ein anderes Protokoll verwendet.

Kann IRMP denn die Original-B&O-FB dekodieren? Wenn nicht, ist das wohl 
ein abweichendes Protokoll.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Nachtrag zu den nicht-exotischen Protokollen: Bei SIRCS, DENON und IR60 
geht die Wiederholung nicht.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Meine Ergebnisse der nicht-exotischen Protokolle:
1
gesendet      empfangen    Fehler
2
01001f003f00  010000003f00 SIRCS keine Adresse
3
02001f003f00  02001f003f00 OK
4
03001f003f00  03001f003f00 OK
5
04001f003f00  04001f003f00 OK
6
05001f003f00  05001f003f00 OK
7
07001f003f00  07001f003f00 OK
8
08001f003f00               DENON geht nur manchmal
9
09001f003f00  09001f003f00 OK
10
0f001f003f00  0f0000003f00 OK
11
10001f003f00  10001f003f00 OK
12
11001f003f00               SIEMENS geht nicht
13
14001f003f00  14000f003f00 OK
14
15001f003f00  15001f003f00 OK
15
18001f003f00  180000003f00 OK
16
1b001f003f00  1b001f003f00 OK
17
1c001f003f00  1c001f003f00 OK
18
gesendet     empfangen                  Fehler
19
01001f003f01 010000003f00 010000003f01  SIRCS keine Adresse
20
02001f003f01 02001f003f00 02001f003f01  OK
21
03001f003f01 03001f003f00 03001f003f01  OK
22
04001f003f01 04001f003f00 04001f003f01  OK
23
05001f003f01 05001f003f00 05001f003f01  OK
24
07001f003f01 07001f003f00 07001f003f01  OK
25
08001f003f01 08001f03c000               DENON geht nur manchmal, Kommando falsch
26
09001f003f01 09001f003f00 09001f003f01  OK
27
0f001f003f01 0f0000003f00 0f0000003f01  OK
28
10001f003f01 10001f003f00 10001f003f01  OK
29
11001f003f01                            SIEMENS geht nicht
30
14001f003f01 14000f003f00 14000f003f01  OK
31
15001f003f01 15001f003f00 15001f003f01  OK
32
18001f003f01 180000003f00               OK
33
1b001f003f01 1b001f003f00 1b001f003f01  OK
34
1c001f003f01 1c001f003f00 1c001f003f01  OK

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe meine Universal Fernbedienung auf Siemens gestellt. Erkannt 
wird mal Siemens, mal Grundig, mal Ruwido.
Sony wird als Sony erkannt, aber auch mit Adresse 0.
Denon wird als  NEC erkannt.
Die letzten beiden könnten an der Fernbedienung liegen oder an 
IRSND/IRMP.
Bei Siemens scheint sowohl bei IRSND als auch bei IRMP der Wurm drin zu 
sein.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> 11001f003f00               SIEMENS geht nicht

Jörg R. schrieb:
> Ich habe meine Universal Fernbedienung auf Siemens gestellt. Erkannt
> wird mal Siemens, mal Grundig, mal Ruwido.

Für Siemens hatte ich mal vor langer Zeit eine testweise Änderung 
gemacht. Warum, weiß ich nicht mehr, ist zu lange her. Jedenfalls hatte 
damals diese Änderung den Weg ins Release gefunden - wohl eher 
versehentlich.

Das war für 15kHz auch kein Problem, erst bei 20kHz machen sich dann die 
Unterschiede bemerkbar.

Am besten macht man meine Änderung in *irmpprotocols.h* wieder 
rückgängig.
Alt:
1
/*-------------------------------------------------------------------------
2
 * SIEMENS & RUWIDO:
3
 *------------------------------------------------------------------------- */
4
5
#if 0
6
#define SIEMENS_OR_RUWIDO_START_BIT_PULSE_TIME    275.0e-6                      //  275 usec pulse
7
...

Neu:
1
/*-------------------------------------------------------------------------
2
 * SIEMENS & RUWIDO:
3
 *------------------------------------------------------------------------- */
4
5
#if 1
6
#define SIEMENS_OR_RUWIDO_START_BIT_PULSE_TIME    275.0e-6                      //  275 usec pulse
7
...


Also einfach aus "if 0" ein "if 1" machen.

Ich werde das so fürs nächste Release ebenso anpassen.

Klaus, kannst Du das mal mit Deiner Siemens-FB testen?

: Bearbeitet durch Moderator
von Klaus R. (klaus2)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Klaus, kannst Du das mal mit Deiner Siemens-FB testen?

...ich habe nur B&O MCP5500, aber der ist gerade eingemottet.

Klaus.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Klaus R. schrieb:
> Frank M. schrieb:
>> Klaus, kannst Du das mal mit Deiner Siemens-FB testen?
>
> ...ich habe nur B&O MCP5500, aber der ist gerade eingemottet.

Sorry, ich meinte Jörg, er hatte das ja mit einer Universal-FB getestet.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Mit der Änderung ist es leider wie zuvor, Siemens mit IRSND -> IRMP geht 
nicht und Fernbedienung -> IRMP bringt mal Siemens, mal Grundig, mal 
Ruwido (es könnte sein, dass jetzt öfter Siemens kommt als vorher).

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Mit der Änderung ist es leider wie zuvor, Siemens mit IRSND -> IRMP geht
> nicht und Fernbedienung -> IRMP bringt mal Siemens, mal Grundig, mal
> Ruwido (es könnte sein, dass jetzt öfter Siemens kommt als vorher).

Danke für den Test. Kannst Du bei Gelegenheit ein paar Scans per 
IRMP_LOGGING erzeugen?

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

> Kannst Du bei Gelegenheit ein paar Scans per IRMP_LOGGING erzeugen?

Du hast urprünglich für meine M740AV das SIEMENS implementiert. Die 
Scans dazu müsstest Du noch haben.

Die M740AV sind seit längerem entsorgt, die FB besitze ich aber noch. 
Bei Bedarf erstelle ich Logs. Aber eigentlich hast Du die schon.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Du hast urprünglich für meine M740AV das SIEMENS implementiert. Die
> Scans dazu müsstest Du noch haben.

Ja, die 15kHz-Scans von Dir habe ich noch und werden im Ordner IR-Data 
mit ausgeliefert. Die laufen einwandfrei durch - mit 15kHz. Diese Daten 
sind auch  meine Referenz für Siemens.

Der obige Patch war auch für die Variante mit 20kHz - da konnte der IRMP 
die von IRSND erzeugten Frames nicht mehr erkennen. Nach dem Patch 
(exakteres Timing) ging das wieder.

Offenbar gibt es bei Siemens aber mitunter stärker abweichende Timings - 
jedenfalls bei der Universal-FB von Jörg. Deshalb bat ich ihn um Scans, 
um Unterschiede feststellen und eventuell berücksichtigen zu können.

@Jörg: Mit welcher Frequenz wurde der IRMP übersetzt? Mit 20kHz oder 
15kHz?

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
IRSND und IRMP waren auf 20 kHz.
Bis ich dazu komme, Scans zu machen, kann es aber etwas dauern.
Möchtest du Scans mit 15 kHz oder mit 20 kHz?

Die Frage ist auch, wie aussagekräftig Scans meiner URC 7541 sind.
Vielleicht wären Scans von eku's M740AV FB mit 20 kHz interessanter?

Ich bin übrigens deshalb bei IRMP auf 20 kHz, weil ich neben den 
nicht-exotischen auch RCMM an habe (das wurde im VDR Umfeld so gewünscht 
von Fujitsu-Siemens Activy Besitzern). Ich hatte aber zuerst ohne RCMM 
getestet, und ob mit oder ohne RCMM gab es bei der Erkennung keinen 
Unterschied.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> IRSND und IRMP waren auf 20 kHz.

Gut zu wissen.

> Bis ich dazu komme, Scans zu machen, kann es aber etwas dauern.
> Möchtest du Scans mit 15 kHz oder mit 20 kHz?

Vielleicht sind Deine geschilderten Probleme mit 15kHz weg? Von daher 
erscheinen mir 20er sinnvoller.

Jörg R. schrieb:
> Die Frage ist auch, wie aussagekräftig Scans meiner URC 7541 sind.

Sehr: Du hast Probleme mit Deiner FB. Die kann ich nur lösen, wenn ich 
davon Scans habe. Außerdem ist ein Vergleich mit der "Referenz" auf 
jeden Fall sinnvoll.

> Vielleicht wären Scans von eku's M740AV FB mit 20 kHz interessanter?

Die kann ich leicht in einen 20kHz-Scan umwandeln, indem ich die Anzahl 
der 0en und 1en mit 1,33 multipliziere.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
OK.
Mal eine Verständnisfrage,

Frank M. schrieb:
> Das war für 15kHz auch kein Problem, erst bei 20kHz machen sich dann die
> Unterschiede bemerkbar.

ich hätte gedacht 20kHz ist "besser" als 15kHz, wieso kann 20kHz 
Probleme machen, die bei 15kHz nicht auftreten?

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> ich hätte gedacht 20kHz ist "besser" als 15kHz, wieso kann 20kHz
> Probleme machen, die bei 15kHz nicht auftreten?

Wie ich oben geschrieben habe, hatte ich abweichende Timings in 
irmpprotocols.h mit "#if 1" reingestellt - warum, weiß ich nicht mehr. 
Durch die Umrechnung von Zeiten in Längen, die abhängig von der 
Abtastfrequenz sind, kommen natürlich Rundungen rein. Dann wird zum 
Beispiel aus  gerechneten 6,4 Tastungen ein Wert von 6. Bei 15kHz war 
diese Umrechnung (per Macros in irmp.c) noch im Rahmen der Toleranz.

Bei 20kHz, wo die Umrechnung genauer wird, fielen die Längen aus ekus 
Referenz-Scans raus. Da wird dann zum Beispiel eine 8,5 zur 9 als 
Mindestlänge. Wenn dann eine Länge von 8 gemessen wurde, wurde 
Ruwido/Siemens verworfen.

Wie gesagt: Es waren einfach schlechte Timing-Werte, die bei gröberer 
(15kHz) Tastung nicht aufgefallen sind.

: Bearbeitet durch Moderator
von Andreas S. (1ras)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

danke für dieses tolle Projekt!

Da ich heuer die Beleuchtung meiner Weihnachtskrippe mit der 
Fernbedienung der Weihnachtsbaumkerzen mitschalten möchte, bin ich auf 
IRMP gestoßen. Nur leider benutzt diese Fernbedienung ein bisher nicht 
implementiertes Protokoll. Ich habe es deshalb dokumentiert und als 
Untergruppe von NEC implementiert, da das Anfangstiming sehr ähnlich ist 
und es sich so gleichzeitig aktivieren lässt.

Die Zeiten sind mit dem Oszi gemessen und über die Daten zweier 
Fernbedienungen gemittelt. Die Weihnachtsbaumkerzen mit dieser 
Fernbedienung stammen von Melinera (Lidl, 
https://www.lidl.de/de/melinera-15-led-weihnachtsbaumkerzen/p311723).

Vielleicht kannst du damit etwas anfangen und es in IRMP aufnehmen.

Grüße

Andreas

von Malte _. (malte) Benutzerseite


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
vielen dank für IRMP. Ich habe damit eine kleine Platine entwickelt, mit 
der ich meine Osram LED Deckenlampen und meinen Lg Beamer ansteuern 
kann. Beide verwenden das NEC Protokoll. Und weil das meine erste 
Schaltung mit einem STM32 statt eines AVRs war, brauchte ich 3,3V. 
Leider ist mir hier gleich einen Fehler unterlaufen, so dass jetzt ein 
Spannungsregler im TO-92 Gehäuse als Workaround notwendig ist.
Bei IRSND sind alle Protokolle aktiviert, bei IRMP die ersten 15. Damit 
werden ca 26KiB Flash benötigt. Wenn man die STM HAL Lib rauswirft, 
wären noch 3-4KiB zusätzlich für Erweiterungen frei. Mit 12MHz Takt 
läuft der IRPM Interrupt mit 20kHz problemlos. Mit maximal 48MHz hätte 
der STM32 hier auch noch Reserven.
Wie genau muss eigentlich das Timing bei Infrarot sein? Ursprünglich 
wollte ich einen pinkompatiblen STM32L082KZT6 nehmen und hatte den auch 
schon gekauft - dann aber im letzten Moment festgestellt, dass dieser in 
dem Gehäuse keinen externen high speed Quarz (kein HSE, nur LSE) 
unterstützt. Der hätte mit 192KiB Flash mehr als genug Reserve für 
weitere Protokolle.

Falls jemand Interesse hat, ich hätte 4 Platinen, hergestellt bei 
Aisler, zum Selbstkostenpreis von 3,20€ + Porto (0€ Selbstabholung in 
Bielefeld, 1€ als Brief - maximal eine Platine - das Risiko trägt der 
Empfänger, oder bevorzugt 3,20€ als Einwurfeinschreiben - da gibts eine 
Trackingnummer) abzugeben.
Das komplette Projekt gibt es hier:
https://github.com/Solartraveler/irusb

Ein Fehler ist mir beim Zusammenspiel von IRSND und IRMP aufgefallen:
Setzt man IRMP_32_BIT in irmpconfig.h, so bleibt irsnd bei der 16Bit 
Definition und je nach dem welches Include man als erstes eingebunden 
hat, ist dann command in IRMP_DATA 16 oder 32Bit und damit erhält IRSND 
oder IRMP falsche Daten. Einfach die Definition von IRMP_32_BIT in 
irsndconfig.h hinzufügen (wie bei irmpconfig.h) reichte nicht, da 
irsnd.h, im Gegensatz zu irmp.h, erst irmpsystem.h inkludiert und danach 
irsndconfig.h. Hier die Reihenfolge der Inkludes zu vertauschen war auch 
keine Lösung, da irsndconfig.h die ARM_STM_HAL Definition aus 
irmpsystem.h benötigt. Als Workaround habe ich dann ARM_STM_HAL noch mal 
in irsndconfig.h definiert.

von Andreas S. (1ras)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bezüglich der Fernbedienung der Melinera (Lidl) Weihnachtsbaumkerzen, 
hier noch eine größere Menge an IR-Daten mit 20kHz, damit lässt sich das 
Timing noch etwas genauer bestimmen. Ich komme dann auf

Start Bit: 8800µs pulse, 4100µs pause
0 Bit: 440µs pulse, 590µs pause
1 Bit: 970µs pulse, 1140µs pause

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,

Andreas S. schrieb:
> Ich habe es deshalb dokumentiert und als
> Untergruppe von NEC implementiert

Sehr saubere Arbeit! Vielen Dank! Ich integriere Deine Erweiterungen in 
das nächste Release.

Andreas S. schrieb:
> hier noch eine größere Menge an IR-Daten mit
> 20kHz, damit lässt sich das Timing noch etwas genauer bestimmen.

Super, danke, je mehr Input, desto besser.

: Bearbeitet durch Moderator
von Jörg R. (jrie)


Angehängte Dateien:
  • Scan1 (891 Bytes, 4 Downloads)
  • Scan2 (4 KB, 5 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Meine Scans liefern merkwürdige Ergebnisse, ich finde den Fehler nicht.
Scan1 habe ich etwas editiert, der passt zu den IRMP Ergebnissen.
Scan2 ist uneditiert.
Mit HTerm über einen PL2303 empfangen.

von Jörg R. (jrie)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Da ich dachte, irgendwo wäre ein Fehler in meinem Versuchsaufbau, habe 
ich jetzt noch mal komplett von vorne angefangen.
Ein anderes STM32-Board, neu gebaut, neu geflasht, neu zusammengesteckt.
Die Ergebnisse haben aber wieder dasselbe Strickmuster.
HTW_.txt ist mit Hyperterminal unter Windows, cutecom.log3 mit cutecom 
unter Linux. Die sind so ähnlich, dass sie einander bestätigen.
Zum Vergleich noch mit RC5 und demselben Aufbau, cutecom.log.RC5, der 
ist so wie erwartet.
Es waren jeweils die Tasten 0, 1, 2, ... bis 9.

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Die Ergebnisse haben aber wieder dasselbe Strickmuster.

Danke erstmal, Jörg. Ich bin da etwas ratlos, das ist irgendwie eine 
Mischung aus Siemens, Grundig und Ruwido. Nicht nur IRMP kommt da ins 
Schleudern, sondern ich auch, wenn ich die Muster "per Hand" mit den mir 
vorliegenden Daten abgleiche.

Rätselhaft sind auch die kurzen Frames dazwischen, die ich überhaupt 
nicht zuordnen kann. Ob das eine Buffer-Beschränkung der 
Logging-Funktion ist, welche aufgrund der hohen Sample-Rate "vollläuft"?

Sehen die Scans mit 15kHz genauso verrückt aus, entsprechend um die 
Längen gekürzt? Hier würde mir ein kurzer Test mit einer oder zwei 
Tasten reichen.

Wenn der 15kHz-Test dasselbe Chaos liefert, nehme ich an, dass die 
Universal-FB einfach fehlerhafte Frames erzeugt. Oder kannst Du damit 
tatsächlich ein Siemens-Gerät ansteuern?

Ich werde aber noch ein paar Analysen vornehmen, vielleicht fällt bei 
mir noch der Groschen, wie man die Daten "einordnen" kann.

von Jörg R. (jrie)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein Scan mit 15kHz anbei.
Ich habe kein Siemens-Gerät.
Ich bin auch überhaupt nicht sicher, was die FB da wirklich sendet (mir 
ging es ja auch eigentlich um das von IRSND gesandte Siemens und die FB 
habe ich nur zur Differentialdiagnose eingesetzt).

Ich habe auch Scans von per IRSND gesendetem Siemens gemacht (mit 
20kHz). Dabei (cutecom.log.irsnd.siemens) wird Siemens und A1TVBOX 
erkannt (A1TVBOX ist falsch). Das ist auch mit 15kHz so 
(cutecom.log.irsnd.siemens3.15k).

: Bearbeitet durch User
von Jörg R. (jrie)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und noch ein Scan von Sony per IRSND, auch bei 15kHz verschwindet die 
Adresse.
Denon per IRSND geht mit 15kHz (mit 20kHz ging es nur manchmal).

von Jörg R. (jrie)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Scan mit allen Protokollen von 1 bis 49.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Super, vielen Dank! Damit habe ich nun genügend Hausaufgaben zu tun ;-)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Ich habe auch Scans von per IRSND gesendetem Siemens gemacht (mit
> 20kHz).

Danke, den Fehler habe ich beseitigen können. Es lag am nicht gerade 
optimal ausgelegten Biphase-Decoder (Manchester Codes). Von daher muss 
ich hier mit den Toleranzen anders arbeiten als zum Beispiel bei 
Pulse-Distance. Ich habe das für SIEMENS nun angepasst, werde das im 
Laufe der Zeit auch für andere Biphase-Protokolle nachholen.

Jörg R. schrieb:
> Und noch ein Scan von Sony per IRSND, auch bei 15kHz verschwindet die
> Adresse.

Welche Adresse hast Du denn benutzt?

Die Sony-Codierung ist etwas speziell, da sie variable Bitlängen 
benutzt. Die Mindest-Bitlänge ist 12. Hier ist die Adresse immer 0. 
Später hat das Sony dann das Protokoll um Adress-Bits erweitert und die 
Länge des kompletten Frames variabel gestaltet. Diese kommen aber erst 
zum Tragen, wenn die Bitlänge größer als 12 ist. Dabei hat Sony das 
Protokoll abwärtskompatibel erweitert, was einen ziemlich komplizierten 
Aufbau des Frames zur Folge hat.

Eine Adresse kommt erst zum Tragen, wenn die Bitlänge größer als 12 ist, 
man also eine zusätzliche Bitlänge definiert. Diese zusätzliche Länge 
wird bei IRSND im oberen Byte der 16-Bit-IRMP-Adresse angegeben.

Ist die IRMP-Adresse also größer 0x0100, dann wird die Sony-Adresse im 
unteren Byte auch ausgewertet, sonst nicht. Die maximale zusätzliche 
Bitlänge ist 8. So ergibt sich für IRMP-Adressen der Wert 0x0000, sonst 
ein Wert zwischen 0x01nn bis 0x08nn, wobei nn die eigentliche 
"physikalische" Sony-Adresse ist.

Beispiel:

Die IRSND-Adresse 0x030A bedeutet: Zusatzliche Bitlänge ist 3, also ist 
die resultierende Bitlänge 12 + 3 = 15. Die Sony-Adresse ist das untere 
Byte der IRSND-Adresse, also 0x0A.

IRMP beim Decodieren macht das dann umgekehrt: Kommt ein Frame mit der 
Bitlänge 15, dann wird im oberen Byte der IRMP-Adresse 0x0300 gesetzt. 
Anschließend wird die Sony-Adresse 0x0A wieder draufaddiert. Resultat 
ist dann ebenso 0x030A als empfangene IRMP-Adresse.

So ist das ganze dann auch transparent für IRSND und IRMP anwendbar.

Fazit: Du kannst eine Sony-Adresse erst ab der IRMP-Adresse 0x0100 frei 
verwenden. Offenbar hast Du jedoch eine IRMP-Adresse verwendet, welche 
kleiner als 0x0100 ist. Damit ist die zusätzliche Bitlänge für IRSND 
null und damit wird auch keine Sony-Adresse im Frame verwendet. In 
diesem Fall stehen alle 12 Bits im Frame für das Kommando zur Verfügung.

Ja, das ist kompliziert. Aber es ist konsistent ;)

: Bearbeitet durch Moderator
von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Danke, den Fehler habe ich beseitigen können.

Danke für's Fehler beseitigen :-)

Frank M. schrieb:
> Du kannst eine Sony-Adresse erst ab der IRMP-Adresse 0x0100 frei
> verwenden. Offenbar hast Du jedoch eine IRMP-Adresse verwendet, welche
> kleiner als 0x0100 ist.

So ist es. Danke für die Erklärung.

Jörg R. schrieb:
> Denon per IRSND geht mit 15kHz (mit 20kHz ging es nur manchmal).

Aber auch da ist das Kommando falsch (0x003f wird zu 0x03c0). Oder ist 
das auch ein Spezialfall?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Jörg R. schrieb:
>> Denon per IRSND geht mit 15kHz (mit 20kHz ging es nur manchmal).
>
> Aber auch da ist das Kommando falsch (0x003f wird zu 0x03c0). Oder ist
> das auch ein Spezialfall?

Das schaue ich mir heute im Laufe des Tages an.

Allgemein gilt, dass man mit den meisten Protokollen nicht transparent 
Werte von 0x0000 bis 0xFFFF übertragen kann, da der Wertebereich 
(Bitlänge) von Adresse bzw. Kommando das gar nicht abdeckt.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Jörg R. schrieb:
>> Denon per IRSND geht mit 15kHz (mit 20kHz ging es nur manchmal).
>
> Aber auch da ist das Kommando falsch (0x003f wird zu 0x03c0). Oder ist
> das auch ein Spezialfall?

Viele IR-Protokolle haben Spezialfälle. Ja, hier ist noch einer.

Denon sendet sicherheitshalber immer 2 Frames, wobei beim zweiten Frame 
die Kommando-Bits invertiert werden. Dabei gilt die Regel, dass das 
unterste Bit beim Senden zunächst 0 ist und im Wiederholungsframe dann 
1.

Daraus folgt, dass nur gerade Kommando-Werte erlaubt sind. 0x003F ist es 
nicht.

Ja, ich war hier inkonsequent: Eigentlich nehme ich solche 
protokollspezifischen Bits nicht mit ins Kommando rein, sondern 
generiere diese im IRSND normalerweise automatisch. Umgekehrt beim 
Dekodieren im IRMP werden diese Regeln zwar geprüft, aber solche Bits 
werden dann ausgeblendet und wandern nicht mit in das Kommando-Wort. 
Hier habe ich es damals aber getan - warum, weiß ich auch nicht mehr. 
Vermutlich, weil dann die Kommando-Codes besser mit einschlägig 
zugängliche Quellen/Tabellen für Denon-und Sharp-Fernbedienungen 
vergleichbar waren.

P.S.
Das zweitunterste Bit im Kommando entscheidet übrigens darüber, ob es 
sich um ein Denon- oder ein Sharp-Gerät handelt: 0 = Denon, 1 = Sharp

: Bearbeitet durch Moderator
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Unterstützt IRMP auch 8051er Derivate (SDCC compiler)? :)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Unterstützt IRMP auch 8051er Derivate (SDCC compiler)? :)

Nicht, dass ich wüsste. Du kannst das aber gern umsetzen. IRMP braucht 
einen Timer und einen GPIO-Pin. Das ist alles.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Mampf F. schrieb:
>> Unterstützt IRMP auch 8051er Derivate (SDCC compiler)? :)
>
> Nicht, dass ich wüsste. Du kannst das aber gern umsetzen. IRMP braucht
> einen Timer und einen GPIO-Pin. Das ist alles.

Werd ich ausprobieren :)

Neulich hab ich mal ein paar Zeilen Änderungen für einen STM32F3xx 
eingebaut ... Wenn das Projekt auf github/gitlab gehostet wäre, hätte 
ich schon einen PR submittiert.

Aber svn fass ich nicht mehr an :)

*edit*: vermutlich kommt SDCC mit den Makros nicht klar ... ich schau 
mal, wie das dann gehen könnte.

*edit2*: Wahrscheinlich müsste man den GCC Präprozessor nutzen und den 
Output per SDCC kompilieren. Sollte machbar sein :)

*edit3*: IRMP unterstützt SDCC mit STM8 ("__SDCC_stm8") - nice^2

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:

> Neulich hab ich mal ein paar Zeilen Änderungen für einen STM32F3xx
> eingebaut ... Wenn das Projekt auf github/gitlab gehostet wäre, hätte
> ich schon einen PR submittiert.

Schick mir die diffs, ich baue sie ein.

> *edit*: vermutlich kommt SDCC mit den Makros nicht klar ... ich schau
> mal, wie das dann gehen könnte.

Die einzigen Macros, die Probleme machen könnten, sind die Variadic 
Macros. Diese habe vor einigen Monaten durch mehrere ersetzt. Von daher 
sehe ich kein Problem.

> *edit2*: Wahrscheinlich müsste man den GCC Präprozessor nutzen und den
> Output per SDCC kompilieren. Sollte machbar sein :)

Bevor Du so einen Hack anfängst, sag mir besser, welche Makros nicht 
funktionieren. Da kann man bestimmt noch etwas anpassen.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Mampf F. schrieb:
>
>> Neulich hab ich mal ein paar Zeilen Änderungen für einen STM32F3xx
>> eingebaut ... Wenn das Projekt auf github/gitlab gehostet wäre, hätte
>> ich schon einen PR submittiert.
>
> Schick mir die diffs, ich baue sie ein.

Hmmmmm ... in der aktuellen Version ist F3xx schon eingebaut - das kann 
ich mir also sparen :)

Vor 2-3 Jahren meine ich, hab ich auch mal Änderungen für zB den 
STM32L151 gemacht.

Ich kuck mal, ob ich da noch was rausziehen kann.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hmmmm ... Für einen 8051er (128Byte RAM):
1
Internal RAM layout:
2
      0 1 2 3 4 5 6 7 8 9 A B C D E F
3
0x00:|0|0|0|0|0|0|0|0|a|a|a|a|a|a|b|b|
4
0x10:|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b|
5
0x20:|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b|b|
6
0x30:|b|b|b|b|b|b|b|b|b|Q|Q|Q|Q|Q|Q|Q|
7
0x40:|Q|Q|Q|Q|S|S|S|S|S|S|S|S|S|S|S|S|
8
0x50:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
9
0x60:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
10
0x70:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
11
0x80:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
12
0x90:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
13
0xa0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
14
0xb0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
15
0xc0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
16
0xd0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
17
0xe0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
18
0xf0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
19
0-3:Reg Banks, T:Bit regs, a-z:Data, B:Bits, Q:Overlay, I:iData, S:Stack, A:Absolute
20
21
Stack starts at: 0x44 (sp set to 0x43) with 188 bytes available.
22
No spare internal RAM space left.
23
24
Other memory:
25
   Name             Start    End      Size     Max     
26
   ---------------- -------- -------- -------- --------
27
   PAGED EXT. RAM                         0      256   
28
   EXTERNAL RAM                           0    65536   
29
   ROM/EPROM/FLASH  0x0000   0x0505    1286    65536

Fast 1.3kB mit IRMP alleine. Der Register-Verbrauch sieht sehr gut aus.

Leider fehlt mir noch die Hardware, das auch wirklich auszuprobieren - 
aber es sieht vielversprechend aus :)

Falls ich es hinbekomme, gibts ein diff von mir :)

*edit*: Gerade gesehen - der SDCC hat jetzt hier 256Byte RAM angenommen. 
Mal kucken, wie man das umstellt. Ist ja kein 8052er^^

: Bearbeitet durch User
von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ja, das ist kompliziert. Aber es ist konsistent ;)

Danke für die Aufklärung!
Kann man das ganze irgendwo in den Sourcen kommentieren, damit Du in 4 
Jahren nicht dieselbe Frage nochmal gestellt bekommst?
Z.B. ab Line 1100 von irmp.c
Das wäre super.

von Jörg R. (jrie)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Daraus folgt, dass nur gerade Kommando-Werte erlaubt sind.

Danke für die Info. Damit funktioniert Denon.
Eine Doku für die ganzen Spezialfälle wäre echt gut :)

Der Scan von A1TVBOX über IRSND sieht ganz anders aus als der 
Referenzscan. Ich vermute, da stimmt was bei IRSND nicht?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Eine Doku für die ganzen Spezialfälle wäre echt gut :)

Normalerweise bildet man mit IRSND existente Original-Fernbedienungen 
nach. Da die Adressen und Kommandos, die man mit IRMP erhält, 1:1 dem 
IRSND zum Fraß vorgeworfen werden können, passen die realen Werte immer. 
Ich sehe jetzt eigentlich keinen Anwendungsfall, wo man sich Adressen + 
Kommandos einfach mal so ausdenkt und dann auf die Nase fliegt, weil 
diese dann nicht passen.

Klar könnte man trotzdem diese Spezialfälle dokumentieren, aber das ist 
Knochenarbeit.

> Der Scan von A1TVBOX über IRSND sieht ganz anders aus als der
> Referenzscan

Sehr merkwürdig, bei Deinen Ausgaben stimmen weder Timings noch Anzahl 
der Bits.

Ich habe gerade mit irsnd-20kHz einen Frame unter Linux ausgeben lassen:
1
000001111110000011100000111000001110000000000111111000001110000011100000111000001110000011100000111000000000011111100000111000001110000011100000111111111111111111111

Dieser wird von irmp-20kHz auch wieder einwandfrei erkannt.

: Bearbeitet durch Moderator
von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Mein Scan deines Codes (gesendet 2000d0001000):
1
000001111110000000000000000000111110000000000011111000000000000000000000000000000000000000000000000000000000011111100000000000000000000000000000011111111111111111111
Da fehlt Einiges. Aber warum?

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Ich wollte Mitsubishi-Heavy testen:
./irsnd-20kHz 49 0x00d0 0x0010 > 49
./irmp-20kHz < 49
Das wird nicht erkannt.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
IRSND sendet FDC nur, wenn die flags 0x00 sind. Mit 0x01 geht es nicht.
Soll das so sein?

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Manchmal hängt es von der Reihenfolge, in der gesendet wird, ab, ob 
richtig erkannt wird.
Beispiel:
Wenn ich RC5, dann NEC16, dann NEC42 sende, wird es auch so erkannt.
Wenn ich aber IR-60, dann NEC16, dann NEC42 sende, wird NEC16 und NEC42 
als Siemens erkannt.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Wenn ich RC5, dann NEC16, dann NEC42 sende, wird es auch so erkannt.
> Wenn ich aber IR-60, dann NEC16, dann NEC42 sende, wird NEC16 und NEC42
> als Siemens erkannt.

Soweit ich mich erinnere, kommt irsnd_send(&irmp_data, TRUE) zurück, 
wenn der Frame komplett rausgeschickt ist. Eigentlich ist das nicht ganz 
korrekt, denn zu jedem IR-Protokoll gehört auch eine gewisse Pause nach 
Aussenden des Frames. Ich habe darauf verzichtet, damit der µC auch noch 
was anderes machen kann, also die Pause abzuwarten. Eventuell erweitere 
ich irsnd_send() noch um einen weiteren Parameter.

Baue da bitte mal nach dem irsnd_send() ein Delay von 50msec ein und 
schaue, ob sich das Problem damit erledigt.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Ich hatte zwischen den  irsnd_send_data() ein delay von 300ms drin und 
ich hatte mit irsnd_send_data(irmp_data_p, 1) gesendet.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> IRSND sendet FDC nur, wenn die flags 0x00 sind. Mit 0x01 geht es
> nicht.

IRSND sendet nicht oder IRMP empfängt/dekodiert nicht?

Mein Test unter Linux:
1
$ ./irsnd-20kHz 18 0 40 2 | ./irmp-20kHz
2
0000000000000000000000000010000011011111 p=18 (FDC), a=0x0000, c=0x0004, f=0x00, asc=0x33, key='3'
3
0000000000000000000011110010000011011111 p=18 (FDC), a=0x0000, c=0x0084, f=0x00
4
0000000000000000000011110010000011011111 p=18 (FDC), a=0x0000, c=0x0084, f=0x01

Wiederholungen werden also durchaus übertragen und empfangen...

Schalte mal im IRMP alle anderen Protokolle bis auf die Standards ab. 
Vielleicht ist es ein Empfangsproblem, weil FDC mit irgendwas anderem 
kollidiert. Gerade mit RC5 zusammen ist da eine Sonderbehandlung im 
IRMP-Code, siehe auch Kommentar in irmpconfig.h:
1
 * If you want to use FDC or RCCAR simultaneous with RC5 protocol, additional program space is required.
2
 * If you don't need RC5 when using FDC/RCCAR, you should disable RC5.

: Bearbeitet durch Moderator
von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> IRSND sendet FDC nur, wenn die flags 0x00 sind. Mit 0x01 geht es nicht.

Das habe ich falsch interpretiert.
Tatsächlich geht bei mir FDC nur manchmal. (Und als ich auf 0x00 
umgestellt hatte ging es, aber das war nur Zufall.)

Frank M. schrieb:
> If you don't need RC5 when using FDC/RCCAR, you should disable RC5.

RC5 hat bei mir höhere Priorität. Falls FDC und RC5 nicht zusammen 
gehen, lasse ich lieber FDC weg.

Hier 
https://github.com/M-Reimer/irmp2keyboard/blob/master/irmp2keyboard/src/irmp/irmpconfig.h 
scheint aber beides zusammen zu gehen.

von Jörg R. (jrie)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Lego wird auch nur manchmal erkannt. Die Scans sind dann aber OK und 
werden korrekt erkannt.

Und noch was interessantes zu FDC, ein Scan von 5 einzelnen Sendungen 
per IRSND. Alle 5 sehen sehr ähnlich aus. Der Erste wird aber als 
A1TVBOX erkannt und der letzte gar nicht. Die mittleren drei werden 
korrekt erkannt.
Kannst du daraus sehen, was falsch läuft?

Edit: Beim Ersten und beim Letzten Scan sind ähnlich wie beim 
A1TVBOX-Scan ein paar 1111 verschluckt worden, aber so wenige, dass man 
genau hingucken muss, um das zu sehen. Wieso werden die verschluckt?

Es wäre schön, wenn jemand das mal gegentesten würde, ob das nur bei mir 
so ist oder reproduzierbar. Also Scans von per IRSND gesendetem A1TVBOX 
und FDC.

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Und noch was interessantes zu FDC, ein Scan von 5 einzelnen Sendungen
> per IRSND. Alle 5 sehen sehr ähnlich aus. Der Erste wird aber als
> A1TVBOX erkannt

Der erste ist kaputt:
1
0000000000000000000000000000000000000000000011111111111111111100000111110000001111000000111100000111110000001111000000111100000011110000001111000000111100000000000000001111000001111100000111110000001111000000111100000011110000000111000001111100000111110000001111000000111100000000000000001111000000111100000011111111111111000000011111111111110000000111000001111100000011110000001111000000111100000011110000001111000001111100000011111111111111000000011111111111110000011111111111111100000011111111111111000000111111111111110000011111111111111100000011111111111111111111

Die Pulse (Nullen) dürfen nur 3-10 Stellen lang sein. Die elfte Gruppe 
von Nullen ist aber 16 Stellen lang. Dadurch wird FDC verworfen und der 
Rest dann fälschlicherweise als A1TVBOX erkannt. Kannst Du diese 
Fehlstelle mit IRSND reproduzieren? Ich kann es nicht.

Du kannst das auch gut sehen, wenn Du irmp-20KHz mit Option -v aufrufst:
1
./irmp-20kHz -v <fdc-20kHz.log | less

Output ist dann:
1
   0.050ms [starting pulse]
2
   3.150ms [start-bit: pulse = 44, pause = 18]
3
protocol = FDC, start bit timings: pulse:  39 -  44, pause:  17 -  20
4
pulse_1:   3 -  10
5
pause_1:  10 -  18
6
pulse_0:   3 -  10
7
pause_0:   1 -   6
8
command_offset: 20
9
command_len:     12
10
complete_len:    40
11
stop_bit:         1
12
   3.650ms [bit  0: pulse =   5, pause =   5] 0
13
   4.150ms [bit  1: pulse =   6, pause =   4] 0
14
   4.650ms [bit  2: pulse =   6, pause =   4] 0
15
   5.150ms [bit  3: pulse =   5, pause =   5] 0
16
   5.650ms [bit  4: pulse =   6, pause =   4] 0
17
   6.150ms [bit  5: pulse =   6, pause =   4] 0
18
   6.650ms [bit  6: pulse =   6, pause =   4] 0
19
   7.150ms [bit  7: pulse =   6, pause =   4] 0
20
   7.650ms [bit  8: pulse =   6, pause =   4] 0
21
   8.650ms [bit  9: pulse =  16, pause =   4] error 3: timing not correct: data bit 9,  pulse: 16, pause: 4
22
   9.150ms [start-bit: pulse =  5, pause =  5]
23
protocol = A1TVBOX, start bit timings: pulse:   4 -   8, pause:   5 -   8

> und der letzte gar nicht.

Hier dasselbe: Wieder ein Puls, der 16 Stellen lang ist. Es wird dann 
auch wieder (später im Frame bei Bit 26) auf A1TVBOX umgestellt, 
allerdings reichen die nachfolgenden Bits nicht mehr komplett aus, um 
einen A1TVBOX-Frame vollständig zu empfangen. Daher wird der komplette 
Frame verworfen.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
IR Empfänger sind für verschiedene Burst/Gap Längen ausgelegt.
Beim TSOP1738 mindestens 10/14 laut Datenblatt. Das sind 263 bzw. 368 
us.
Beim TSOP 4838 mindestens 10/12 macht 263 bzw. 316 us.
Beim TSOP 32138 mindestens 6/10 macht 158 bzw. 263 us.
Beim TSOP 93138 mindestens 6/6 macht 158 bzw. 158 us.

Das könnte erklären, warum bei Armin der TSOP31238 besser als der VS1738 
funktioniert, und warum A1TVBOX mit 250 us Puls und 150 us Pause nicht 
erkannt wird und warum bei mir mit dem TSOP4838 FDC mit 300 us Puls und 
220us Pause beim 0-Bit grenzwertig ist.

Mit einem Oszi könnte man messen, was bei der Sendediode rein geht und 
was am TSOP raus kommt. Ich habe leider keines.

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe TSOP 312xx und TSOP 321xx durcheinander gebracht.
Der TSOP31238 ist mit 10/10 noch etwas schlechter.
Wenn ich Zeit habe, versuche ich es mit Soundkarten-Oszi.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Statt zu testen, was welcher TSOP raus filtert, habe ich lieber mit 
direkter Verbindung (also ohne Modulation) getestet:
1
gesendet       empfangen      Protokoll, Fehler
2
01081f003f01   01081f003f00
3
               01081f003f01
4
02001f003f01   02001f003f00
5
               02001f003f01
6
03001f003f01   03001f003f00
7
               03001f003f01
8
04001f003f01   04001f003f00
9
               04001f003f01
10
05001f003f01   200055007a00   Kaseikyo Protokoll
11
               05001f003f00
12
06001f003f01   060007003f00
13
               060007003f01
14
07001f003f01   07001f003f00
15
               07001f003f01
16
08001f003e01   08001f003e00
17
               08001f003e01
18
09001f003f01   09001f003f00
19
               09001f003f01
20
0a001f003f01   0a001f003f00
21
               0a001f003f01
22
0b001f003f01   0b001f003f00
23
               0b001f003f01
24
0c001f003f01   0c000f003f00
25
               0c000f003f01
26
0d001f003f01   0d0000003f00
27
               0d0000003f01
28
0e001f003f01                  Bang & Olufsen geht nicht               
29
0f001f003f01   0f0000000000   Grundig Kommando
30
               0f0000000001
31
10001f003f01   10001f003f00
32
               10001f003f01
33
11001f003e01   20005500aa00   Siemens Protokoll
34
               20005500aa01
35
12001f003f01   120000000300   FDC Adresse, Kommando
36
               120000008300
37
13001f003f01   130003003f00   RC Car (Adresse)
38
               130003003f01
39
14001f003f01   14000f003f00   JVC (Adresse)
40
               14000f003f01
41
15001f003f01   15001f003f00
42
               15001f003f01
43
16001f003f01   160000000300
44
               160000000301
45
18001f003f01   180000003f00   IR60 Wiederholung
46
1b001f003f01   1b001f003f00
47
               1b001f003f01
48
1c001f003f01   1c001f003f00
49
               1c001f003f01
50
1d001f003f01   1d0000003f00
51
               1d0000003f01
52
1e001f003f01   1e000f003f00   Thomson (Adresse)
53
               1e000f003f01
54
1f001f003f01   1f0000003f00
55
               1f0000003f01
56
20001f003f01   2000df003f00   A1 TV Box Adresse
57
               2000df003f01
58
22001f003f01   220000003f00
59
               220000003f01
60
27001f003f01   270000003f00
61
               270000003f01
62
28001f003f01   28001f003f00
63
               28001f003f01
64
29001f003f01   29001f003f00
65
               29001f003f01
66
               29001f003f01
67
               29001f003f01
68
31001f003f01                  Mitsubishi-Heavy geht nicht

: Bearbeitet durch User
von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Bang & Olufsen:
irsnd-20kHz 14 0 1 > 0e
irmp-20kHz < 0e
Das wird nicht erkannt.

Edit:
Ich habe ein Skript für alle Protokolle:
 ./irsnd-20kHz ${irdata} | ./irmp-20kHz
Da wird kaum was erkannt. Wieso?

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Bang & Olufsen:
> irsnd-20kHz 14 0 1 > 0e
> irmp-20kHz < 0e
> Das wird nicht erkannt.

Bei mir schon:
1
$ ./irsnd-20kHz 14 0 1 | ./irmp-20kHz
2
000000000000000001 p=14 (BANG OLU), a=0x0000, c=0x0001, f=0x00
Allerdings habe ich zusätzlich zu den Standard-Protokollen nur Bang & 
Olufsen aktiviert. Ich vermute mal, dass Du alles eingeschaltet hast und 
nach der Startbit-Erkennung ein anderes Protokoll von IRMP den Vorzug 
bekommt. Sehen kannst Du das mit der Option -v.

Also probiere mal:
1
$ ./irmp-20kHz -v < 0e

und berichte, in welches Protokoll IRMP sich verrennt. Dann kann ich 
prüfen, ob und wie ich die beiden auseinanderhalten kann.

> Edit:
> Ich habe ein Skript für alle Protokolle:
>  ./irsnd-20kHz ${irdata} | ./irmp-20kHz
> Da wird kaum was erkannt. Wieso?

Kannst Du das Script mal anhängen? Am besten auch irmpconfig.h und 
irsndconfig.h.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich vermute mal, dass Du alles eingeschaltet hast

Ja.

Frank M. schrieb:
> Kannst Du das Script mal anhängen?

Erst in ein paar Tagen, wenn ich wieder zu hause bin.
Ich habe da einfach dieselben IR-Daten wie in 
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder" 
vom  16.12.2020 19:10 genommen.
Wieso das mit direkter Verbindung ohne Modulation von uC zu uC  besser 
ging als per
1
./irsnd-20kHz ${irdata} | ./irmp-20kHz
 auf einem PC ist mir rätselhaft.
Am 16.12. konnte ich das gute Ergebnis mehrmals hintereinander 
reproduzieren, am nächste Tag dann allerdings gab es schlechtere 
Ergebnisse und das gute nur noch einmal. Gibt es da einen 
Zufalls-Faktor?

Sobald es ein neues Release gibt, werde ich Alles noch mal sorgfältig 
neu bauen und testen.

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Mal so nebenbei - wieso unterstützt IRMP keine externen Interrupts als 
alternative zur Sampling-Methode? 🙈

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Mal so nebenbei - wieso unterstützt IRMP keine externen Interrupts als
> alternative zur Sampling-Methode? 🙈
Schon mal in die Arduino Version geschaut?
https://github.com/ukw100/IRMP/tree/master/examples/Interrupt

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Mal so nebenbei - wieso unterstützt IRMP keine externen Interrupts
> als alternative zur Sampling-Methode? 🙈

IRMP sollte auf möglich vielen µCs laufen. Die externen Interrupts 
erfordern dann eine Abstraktionsebene mehr. Das ist eine Menge Arbeit, 
das für alle µCs und alle unterstützten Protokolle umzusetzen. Zudem 
schränken Interrupts auf vielen µCs die Anzahl der möglichen Pins ein.

Außerdem ist es mit externen Interrupts allein nicht getan. Bei vielen 
Protokollen arbeitet IRMP mit Timeouts.

Hier ein einfaches Beispiel:

NEC16 hat 16 Bits
NEC hat 32 Bits
NEC42 hat 42 Bits

Die Timingwerte sind aber identisch, hier kommt es nur auf die Länge des 
Frames an. Kommt nach 16 Bits kein Timeout, schwenkt IRMP auf NEC32 um, 
kommt dann nach 32 Bit immer noch kein Timeout, schwenkt IRMP auf NEC42 
um.

Auch Sony hat eine variable Anzahl von Bits im Frame. Da gibt es auch 
noch jede Menge anderer (weitaus komplizierterer) Beispiele, wo ein 
zusätzlicher Timer auch bei Verwendung von externen Interrupts dringend 
vonnöten ist.

Da die Timer-ISR eine Statemaschine ist, wo immer nur kurze Abschnitte 
des Codes durchlaufen wird, ist die Verweildauer in der ISR immer recht 
kurz, so dass die CPU-Auslastung weitaus geringer ist als angenommen. 
Falk hatte damit im Zusammenhang mit AVR & WS2812 einige Messungen 
gemacht und belegt, dass IRMP das Verhalten bei der zeitkritischen 
Ansteuerung der WS2812-LEDs überhaupt nicht stört.

Du kannst das gern auf Interrupts umstellen, dann mach das bitte auch 
für alle unterstützten µCs. Eine halbherzige Lösung (z.B. exklusiv für 
AVRs) ist hier nicht zielführend. Hier wäre dann auch eine entsprechende 
Konfiguration der Interrupt-Pins in der irmpconfig.h nötig.

Armin J. schrieb:
> Schon mal in die Arduino Version geschaut?
> https://github.com/ukw100/IRMP/tree/master/examples/Interrupt

Läuft das für alle µCs, die Du mit der Arduino-Version unterstützt? Hast 
Du dort auch schon die oben beschriebenen nötigen Timeout-Behandlungen 
implementiert, oder fallen da dann einfach einige der Protokolle hinten 
runter?

P.S.

Ich überlege schon seit längerem, die ISR auf das reine Speichern von 
Puls- und Pausenlängen zu kürzen, so dass die Ermittlung und Dekodierung 
des empfangenen Frames außerhalb der ISR erfolgen kann.

Vorteil wäre, dass IRMP mehrere Stränge von möglichen Protokollen bei 
gleichen Startbits nacheinander verfolgen kann, er damit innerhalb des 
Frames "zurückspulen" kann, wenn er merkt, dass er sich 
irrtümlicherweise in einen falschen Strang "verheddert" hat. IRMP könnte 
also viel mehr konkurrierender Protokolle abhandeln und damit wäre die 
Trefferquote wesentlich höher.

Nachteil wäre jedoch ein größerer Ram-Verbrauch.

Wenn man aber mal darüber nachdenkt, wofür man IRMP eigentlich einsetzt, 
dann geht es meist um eine Fernbedienung und damit auch um ein 
Protokoll, das man nutzt. Da gibt es dann überhaupt keine Konkurrenz zu 
anderen ähnlichen exotischen Protokollen. Hier ist die IRMP-Trefferquote 
dann 100%. Der Fall, dass jemand alle Protokolle einschaltet, weil er 60 
IR-FBs, Keyboards usw. in einem Anwendungsfall einlesen will, ist 
überhaupt nicht praxisrelevant.

: Bearbeitet durch Moderator
von Armin J. (arminj)


Bewertung
1 lesenswert
nicht lesenswert
Frank M. schrieb:
> Läuft das für alle µCs, die Du mit der Arduino-Version unterstützt? Hast
> Du dort auch schon die oben beschriebenen nötigen Timeout-Behandlungen
> implementiert, oder fallen da dann einfach einige der Protokolle hinten
> runter?

Es läuft auf allen Plattformen, und natürlich fallen einige Protokolle 
raus, wie Du sehr gut erklärt hast.

> Ich überlege schon seit längerem, die ISR auf das reine Speichern von
> Puls- und Pausenlängen zu kürzen, so dass die Ermittlung und Dekodierung
> des empfangenen Frames außerhalb der ISR erfolgen kann.

Bitte nicht, das machen schon alle anderen IR Libraries, gerade das on 
the Fly dekodieren ist ein Alleinstellungsmerkmal von IRMP!!!

von Mampf F. (mampf) Benutzerseite


Bewertung
-1 lesenswert
nicht lesenswert
Armin J. schrieb:
> Bitte nicht, das machen schon alle anderen IR Libraries, gerade das on
> the Fly dekodieren ist ein Alleinstellungsmerkmal von IRMP!!!

Ehrlich gesagt, sehe ich auch nicht den Vorteil darin.

Alleinstellungsmerkmale müssen nicht zwangsläufig optimal sein^^

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Armin J. schrieb:
> Es läuft auf allen Plattformen, und natürlich fallen einige Protokolle
> raus, wie Du sehr gut erklärt hast.

Läuft das deshalb, weil die Arduino-Runtime-Lib Pin-Interrupts 
abstrahiert oder hast Du das für jeden µC hardwarespezifisch umgesetzt?

Das mit dem Rausfallen von Protokollen könnte man vermeiden, wenn man 
zusätzlich noch einen Timer für Timeouts verwendet. Ich denke mal drüber 
nach.

> Bitte nicht, das machen schon alle anderen IR Libraries, gerade das on
> the Fly dekodieren ist ein Alleinstellungsmerkmal von IRMP!!!

Es würde auch nur das gleichzeitige Erkennen aller Protokolle auf einmal 
garantieren, was - wie ich oben schrieb, eigentlich nicht praxisrelevant 
ist.

Aber ich habe da eine andere Idee: Ich könnte online ein Formular 
bereitstellen, wo der User seine Scans reinkopiert und das Formular dem 
User mitteilt, welches Protokoll er dafür in irmpconfig.h freischalten 
muss. Das würde das Trial-and-Error-Verfahren für irmpconfig.h erheblich 
reduzieren.

Übrigens habe ich seit ein paar Tagen einen Intel NUC mit eingebautem 
IR-Emfänger. Ich habe darafhin die Linux-Version von IRMP dahingehend 
erweitert, dass IRMP die Raw-Werte aus /dev/lirc0 liest und dann die 
empfangenen Frames entweder protokollieren und/oder dekodieren kann. 
Kommt im nächsten Release.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Am 16.12. konnte ich das gute Ergebnis mehrmals hintereinander
> reproduzieren, am nächste Tag dann allerdings gab es schlechtere
> Ergebnisse und das gute nur noch einmal. Gibt es da einen
> Zufalls-Faktor?

Ich vermute, es hat damit zu tun, was alles an Protokollen eingeschaltet 
ist und was nicht. Wenn Du alles einschaltest, werden automatisch einige 
Protokolle abgeschaltet, weil sie in Konflikt mit anderen Protokollen 
stehen.

Du siehst dann so etwas als Compiler-Warnung:
1
 #  warning KASEIKYO protocol conflicts wih PANASONIC, please enable only one of both protocols
2
 #  warning PANASONIC protocol disabled

Das automatische Abschalten ist auch noch teilweise abhängig von der 
Abtastfrequenz.

Gib mal unter Linux
1
make -f makefile.lnx test
ein. Da werden insgesamt 82 Sample-Files mit der aktuellen IRMP-version 
getestet. Dabei müssen die Werte in den Kommentaren übereinstimmen mit 
den Werten, die IRMP ermittelt.

Am Ende muss da stehen:
1
all tests successful

Diesen Test mach ich hier regelmäßig nach jeder Änderung im IRMP, um 
sicherzustellen, dass alle Protokolle weiterhin erkannt werden.

: Bearbeitet durch Moderator
von Jörg R. (jrie)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch mal neu gebaut und es sieht jetzt ziemlich gut aus:
1
gesendet          empfangen                                     Fehler
2
01 081f 003f 01   p= 1 (SIRCS), a=0x081f, c=0x003f, f=0x00
3
                  p= 1 (SIRCS), a=0x081f, c=0x003f, f=0x01
4
02 001f 003f 01   p= 2 (NEC), a=0x001f, c=0x003f, f=0x00
5
                  p= 2 (NEC), a=0x001f, c=0x003f, f=0x01
6
03 001f 003f 01   p= 3 (SAMSUNG), a=0x001f, c=0x003f, f=0x00
7
                  p= 3 (SAMSUNG), a=0x001f, c=0x003f, f=0x01
8
04 001f 003f 01   p= 4 (MATSUSH), a=0x001f, c=0x003f, f=0x00
9
                  p= 4 (MATSUSH), a=0x001f, c=0x003f, f=0x01
10
05 001f 003f 01   p= 5 (KASEIKYO), a=0x001f, c=0x003f, f=0x00
11
                  p= 5 (KASEIKYO), a=0x001f, c=0x003f, f=0x01
12
06 001f 003f 01   p= 6 (RECS80), a=0x0007, c=0x003f, f=0x00
13
                  p= 6 (RECS80), a=0x0007, c=0x003f, f=0x01
14
07 001f 003f 01   p= 7 (RC5), a=0x001f, c=0x003f, f=0x00
15
                  p= 7 (RC5), a=0x001f, c=0x003f, f=0x01
16
08 001f 003e 01   p= 8 (DENON), a=0x001f, c=0x003e, f=0x00
17
                  p= 8 (DENON), a=0x001f, c=0x003e, f=0x01
18
09 001f 003f 01   p= 9 (RC6), a=0x001f, c=0x003f, f=0x00
19
                  p= 9 (RC6), a=0x001f, c=0x003f, f=0x01
20
10 001f 003f 01   p=10 (SAMSG32), a=0x001f, c=0x003f, f=0x00
21
                  p=10 (SAMSG32), a=0x001f, c=0x003f, f=0x01
22
11 001f 003f 01   p=11 (APPLE), a=0x001f, c=0x003f, f=0x00
23
                  p=11 (APPLE), a=0x001f, c=0x003f, f=0x01
24
12 001f 003f 01   p=12 (RECS80EX), a=0x000f, c=0x003f, f=0x00
25
                  p=12 (RECS80EX), a=0x000f, c=0x003f, f=0x01
26
13 001f 003f 01   p=13 (NUBERT), a=0x0000, c=0x003f, f=0x00
27
                  p=13 (NUBERT), a=0x0000, c=0x003f, f=0x01
28
14 001f 003f 01   p=14 (BANG OLU), a=0x0000, c=0x003f, f=0x00
29
                  p=14 (BANG OLU), a=0x0000, c=0x003f, f=0x01
30
15 001f 003f 01   p=15 (GRUNDIG), a=0x0000, c=0x003f, f=0x00
31
                  p=15 (GRUNDIG), a=0x0000, c=0x003f, f=0x01
32
16 001f 003f 01   p=16 (NOKIA), a=0x001f, c=0x003f, f=0x00
33
                  p=16 (NOKIA), a=0x001f, c=0x003f, f=0x01
34
17 001f 003e 01   p=32 (A1TVBOX), a=0x0055, c=0x00aa, f=0x00   Siemens, Protokoll
35
                  p=32 (A1TVBOX), a=0x0055, c=0x00aa, f=0x01
36
18 001f 003f 01   p=18 (FDC), a=0x0000, c=0x0003, f=0x00       Adresse, Kommando
37
                  p=18 (FDC), a=0x0000, c=0x0083, f=0x00
38
19 001f 003f 01   p=19 (RCCAR), a=0x0003, c=0x003f, f=0x00     (Adresse)
39
                  p=19 (RCCAR), a=0x0003, c=0x003f, f=0x01
40
20 001f 003f 01   p=20 (JVC), a=0x000f, c=0x003f, f=0x00
41
                  p=20 (JVC), a=0x000f, c=0x003f, f=0x01       (Adresse)
42
21 001f 003f 01   p=21 (RC6A), a=0x001f, c=0x003f, f=0x00
43
                  p=21 (RC6A), a=0x001f, c=0x003f, f=0x01
44
22 001f 003f 01   p=22 (NIKON), a=0x0000, c=0x0003, f=0x00
45
                  p=22 (NIKON), a=0x0000, c=0x0003, f=0x01
46
24 001f 003f 01   p=24 (IR60), a=0x0000, c=0x003f, f=0x00      Wiederholung fehlt
47
27 001f 003f 01   p=27 (NEC16), a=0x001f, c=0x003f, f=0x00
48
                  p=27 (NEC16), a=0x001f, c=0x003f, f=0x01
49
28 001f 003f 01   p=28 (NEC42), a=0x001f, c=0x003f, f=0x00
50
                  p=28 (NEC42), a=0x001f, c=0x003f, f=0x01
51
29 001f 003f 01   p=29 (LEGO), a=0x0000, c=0x003f, f=0x00
52
                  p=29 (LEGO), a=0x0000, c=0x003f, f=0x01
53
30 001f 003f 01   p=30 (THOMSON), a=0x000f, c=0x003f, f=0x00   (Adresse)
54
                  p=30 (THOMSON), a=0x000f, c=0x003f, f=0x01
55
31 001f 003f 01   p=31 (BOSE), a=0x0000, c=0x003f, f=0x00
56
                  p=31 (BOSE), a=0x0000, c=0x003f, f=0x01
57
32 001f 003f 01   p=32 (A1TVBOX), a=0x00df, c=0x003f, f=0x00    Adresse
58
                  p=32 (A1TVBOX), a=0x00df, c=0x003f, f=0x01
59
34 001f 003f 01   p=34 (TELEFUNKEN), a=0x0000, c=0x003f, f=0x00
60
                  p=34 (TELEFUNKEN), a=0x0000, c=0x003f, f=0x01
61
39 001f 003f 01   p=39 (SPEAKER), a=0x0000, c=0x003f, f=0x00
62
                  p=39 (SPEAKER), a=0x0000, c=0x003f, f=0x01
63
40 001f 003f 01   p=40 (LGAIR), a=0x001f, c=0x003f, f=0x00
64
                  p=40 (LGAIR), a=0x001f, c=0x003f, f=0x01
65
41 001f 003f 01   p=41 (SAMSG48), a=0x001f, c=0x003f, f=0x00
66
                  p=41 (SAMSG48), a=0x001f, c=0x003f, f=0x01
67
                  p=41 (SAMSG48), a=0x001f, c=0x003f, f=0x01
68
                  p=41 (SAMSG48), a=0x001f, c=0x003f, f=0x01
69
49 001f 003f 01                                                 Mitsubishi-Heavy geht nicht
Die vielen Protokolle gehen gut zusammen. (Abgesehen von ein paar 
Schönheitsfehlern.)

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Ich habe noch mal neu gebaut und es sieht jetzt ziemlich gut aus:

Danke, ich schaue mir die verbliebenen Fehler im Laufe der Woche an.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Mitsubishi-Heavy steht laut
1
./irsnd-20kHz 49 1f 3f 01 | ./irmp-20kHz -v
vermutlich in Konflikt mit Kaseikyo.

von Jörg R. (jrie)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Am 16.12. konnte ich das gute Ergebnis mehrmals hintereinander
> reproduzieren, am nächste Tag dann allerdings gab es schlechtere
> Ergebnisse und das gute nur noch einmal. Gibt es da einen
> Zufalls-Faktor?

Das lag vermutlich daran, dass am nächsten Tag Logging an war und am Tag 
zuvor nicht. Mit Logging wird die Erkenung jedenfalls deutlich 
schlechter.

Zu den mit Draht von uC zu uC zusätzlich auftretenden Problemen:

gesendet: 0x0e001f003f01 erkannt: nichts Log: cutecom.log.0e
 ./irmp-20kHz < cutecom.log.0e geht aber.
Merkwürdig. Gibt es dafür eine Erklärung?

gesendet: 05001f003f05 erkannt: 200055007a00 05001f003f00 05001f003f01
Log: cutecom.log.05
./irmp-20kHz < cutecom.log.05 erkennt dasselbe
./irmp-20kHz -v < cutecom.log.05 erkennt erst Speaker und schaltet dann 
um auf  A1TVBOX, erst später wird Kaseikyo korrekt erkannt. Wieso?

Diese beiden gehen ja mit ./irsnd-20kHz ${irdata} | ./irmp-20kHz

: Bearbeitet durch User
von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank, mir fällt gerade auf, dass ein Protokoll wohl Kasiekyo und 
nicht Kaseikyo heisst.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Das lag vermutlich daran, dass am nächsten Tag Logging an war und am Tag
> zuvor nicht. Mit Logging wird die Erkenung jedenfalls deutlich
> schlechter.

Bei Logging ist die Intention, ein unbekanntes Protokoll einzulesen und 
nicht ein IR-Protokoll zu dekodieren. Der Output über die serielle 
Schnittstelle geschieht innerhalb der Timer-ISR. Da hier nicht mit 
UART-Interrupts und einem Output-FIFO gearbeitet wird, wird innerhalb 
der ISR das Busy-Flag des UARTs gepollt. Das verfälscht das 
Zeitverhalten.

Okay, man könnte das Logging besser machen, zumindest sollte dann der 
serielle Output außerhalb der Timer-ISR erzeugt werden. Aber das ist 
nicht ist nicht sooo wichtig, denn:

Man sollte einfach, wenn man IR-Protokolle dekodieren möchte, auch das 
Logging abschalten.

Ich schaue mal, wie einfach es ist, das Decoding komplett zu 
deaktivieren, wenn IRMP_LOGGING gesetzt ist.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Armin J. schrieb:
> Hi Frank, mir fällt gerade auf, dass ein Protokoll wohl Kasiekyo
> und nicht Kaseikyo heisst.

Es wird wohl lediglich vereinzelt Kasiekyo geschrieben. Das scheint 
abhängig von der jeweiligen japanischen Übersetzung zu sein. Google 
zeigt jedenfalls wesentlich mehr Treffer, wenn man nach Kaseikyo sucht 
und nicht nach Kasiekyo.

Von daher sehe ich Kaseikyo als die treffendere Bezeichnung.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Zur Frage wie viele Protokolle gleichzeitig an sein sollen:
Die Nutzer von meinem Projekt wünschen sich natürlich, dass wenn sie 
eine andere Fernbedienung benutzen wollen, nicht die Firmware neu 
kompiliert und geflasht werden muss, sondern dass es so geht, wie es 
ist. Je mehr Protokolle gleichzeitig desto besser, zumindest jedoch die 
halbwegs gebräuchlichen. Für optimalen Empfang muss dann eventuell der 
TSOP gewechselt werden.
Und wie meine Tests zeigen, geht das ja auch :-)  (vorausgesetzt die 
benannten Fehler können behoben werden und falls nicht, weiß man dann 
zumindest welche Protokolle bei „möglichst viele“ zusammen gehen).

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Es wird wohl lediglich vereinzelt Kasiekyo geschrieben. Das scheint
> abhängig von der jeweiligen japanischen Übersetzung zu sein. Google
> zeigt jedenfalls wesentlich mehr Treffer, wenn man nach Kaseikyo sucht
> und nicht nach Kasiekyo.
>
> Von daher sehe ich Kaseikyo als die treffendere Bezeichnung.
Du hast Recht, da bin ich wohl auf einen Tippfehler (an prominenter 
Stelle) reingefallen.

Ich hab da noch eine Frage zu Bose:
1
#if IRMP_SUPPORT_BOSE_PROTOCOL == 1
2
            case IRMP_BOSE_PROTOCOL:
3
                if ((irmp_command >> 8) == (~irmp_command & 0x00FF))
4
                {
5
                    irmp_command &= 0xff;
6
                    rtc = TRUE;
7
                }
8
                break;
9
#endif
Mir scheint -aber vielleicht blick ich es auch nur nicht- hier wird das 
invertierte Kommando als Resultat gespeichert.

Frohes neues Jahr
Armin

von Christian S. (roehrenvorheizer)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mal die Codes einer LEGO-Fernbedienung eingescannt mittels 
IRMP. Den Fotos nach gehört sie wohl zu einer Lego-Modellbahn. Die Taste 
oben rechts hupt. Scan ist in der beigefügten Datei. Vielleicht kann 
dies jemandem nützlich sein. Das bereits eingepflegte Lego-Protokoll 
reagiert darauf jedenfalls nicht.

mit freundlichem Gruß

von Christian S. (roehrenvorheizer)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Datei vergesen, war klar.

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Bilder, sie sind für mich sehr interessant, da ich gerade 
das Lego Protokoll in IRremote überarbeite. Sie zeigen, dass das mit der 
von Lego dokumentierten Parity leider nicht immer stimmt.
Ist das Signal am Sender oder am Empänger abgegriffen?

Die Scans sind leider so gar nicht zu gebrauchen, wenn man die in ein 
Bild rückübersetzt kommt was raus, was keinem Lego IR Code entspechen 
kann siehe z.B. die Passagen
00000001111111111111111
und die noch längeren 111... Passagen

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Falls da ein TSOP im Spiel war, hat er möglicherweise die kurzen Pulse 
raus gefiltert (wie bei mir weiter oben).

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Christian S. schrieb:
> ich habe mal die Codes einer LEGO-Fernbedienung eingescannt mittels
> IRMP.

Mit einem 38kHz-TSOP?

Die Pausen sehen verdächtig kurz aus gegenüber den Pulsen. Das ist 
ziemlich unüblich bei IR.

von Christian S. (roehrenvorheizer)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Zur Anwendung als Empfänger kam ein integrierter IR-Empfänger, wie er 
auf allen meinen Schaltungen mit IR drauf ist. Den genauen Typen kann 
ich vielleicht nicht einmal zurückverfolgen, wenn er nicht direkt drauf 
steht, da ich mehrere Tütchen habe, aus denen er stammen könnte. 
Zumindest RC5 und NEC kommen damit immer perfekt an, auch wenn man gegen 
die Zimmerdecke fernbedient. Das Oszilloskopsignal stammt von genau 
diesem integrierten Empfänger direkt vom Ausgang. Den Sender habe ich 
nicht weiter zerlegt.

Wegen der Mittenfrequenz müßte ich nochmal die bei mir bevorrateten 
Typen durchgehen, ich habe 36 kHz in Erinnerung.

Was den Scan anbetrifft, ist es die Terminalausgabe nach den 
entsprechenden Tastendrücken. Version ist diese von 2020. Ich habe mir 
über die Ausgabe keine weiteren Gedanken gemacht.


mit freundlichem Gruß

von Christian S. (roehrenvorheizer)


Bewertung
0 lesenswert
nicht lesenswert
Die Datei sollte nicht nochmals erscheinen...

von Derek, Chen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

I used "AllProtols.ino" on arduino, test remote controller of sony 
projector.
The sony ir-code address and command are incorrect.

I refer the website 
"http://picprojects.org.uk/projects/sirc/sonysirc.pdf";.

Turn some values in "irmpprotocols.h"

#define SIRCS_AUTO_REPETITION_PAUSE_TIME          45.0e-3
#define SIRCS_FRAME_REPEAT_PAUSE_TIME             45.0e-3
#define SIRCS_ADDRESS_OFFSET                      7
#define SIRCS_ADDRESS_LEN                         13
#define SIRCS_COMMAND_LEN                         7

Then, address and command  are decoded well.

I hope. can add bits-info for "SIRCS". Because sony ir-code have three 
version of the protocol; sony12, sony15 and sony20.

Derek

von Armin J. (arminj)


Bewertung
0 lesenswert
nicht lesenswert
Hi Derek,
you know that the minimal command duration is 17 ms?
Plus the original 25 ms we get 42 ms which is not so far from the 45 in 
the specification!
So your new values are wrong, since they are gap/pause values and not 
period values.
And why
1
#define SIRCS_COMMAND_LEN                         7
 ???
For sony they are 5!
And your other values are specifically for Sony20!
But if you succeed with your values, be happy, but please do not claim 
that others are wrong.

Armin

: Bearbeitet durch User
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Derek, Chen schrieb:
> I hope. can add bits-info for "SIRCS". Because sony ir-code have three
> version of the protocol; sony12, sony15 and sony20.

SIRCS is even more general, it provides for:

7 command bits + 5 address bits + up to 8 additional bits

Thus, the command can be between 7 and 15 bits long. So there is not 
only Sony-12, Sony-15 and Sony-20, but everything between 12 and 20 
bits. To map this variable format in general, IRMP stores the 
information on how many additional bits are needed in the upper half of 
the address when decoding.

So it is not surprising that you get different values - at least for the 
address.

> #define SIRCS_ADDRESS_LEN 13
> #define SIRCS_COMMAND_LEN 7

This saves the additional bits in the address, but the information about 
the length of the frame is lost. Without this, IRSND can no longer 
reproduce the frame correctly.

IRMP stores the up to 8 additional bits in the command code. It is 
therefore not surprising that you also determine something different 
with regard to the command code.

Thus, the general data structure in IRMP for SIRCS is:

address: higher byte = additional length, lower byte = SIRCS address
command: 7 bits + optional up to 8 bits

: Bearbeitet durch Moderator
von Jörg R. (jrie)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mit einem TSOP 34338 (der nichts herausfiltern sollte) gibt es ein paar 
neue Fehler:
1
gesendet       empfangen      empfangen      empfangen      neue Fehler
2
01081f003f01   01081f003f00   01081f003f00   01081f003f00
3
               01081f003f01   01081f003f01   01081f003f01
4
02001f003f01   02001f003f00   02001f003f00   02001f003f00
5
               02001f003f01   02001f003f01   02001f003f01
6
03001f003f01   03001f003f00   03001f003f00   03001f003f00
7
               03001f003f01   03001f003f01   03001f003f01
8
04001f003f01   04001f003f00   04001f003f00   04001f003f00
9
               04001f003f01   04001f003f01   04001f003f01
10
05001f003f01   05001f003f00   05001f003f00   05001f003f00
11
               05001f003f01   05001f003f01   05001f003f01
12
06001f003f01   060007003f00   060007003f0    060007003f00
13
               060007003f01   060007003f0    060007003f01
14
07001f003f01   07001f003f00   07001f003f00   07001f003f00
15
               07001f003f01   07001f003f01   07001f003f01
16
08001f003e01   08001f003e00   08001f003e0    08001f003e00
17
               08001f003e01   08001f003e0    08001f003e01
18
09001f003f01   09001f003f00   09001f003f00   09001f003f00
19
               09001f003f01   09001f003f01   09001f003f01
20
0a001f003f01   0a001f003f00   0a001f003f00   0a001f003f00
21
               0a001f003f01   0a001f003f01   0a001f003f01
22
0b001f003f01   0b001f003f00   0b001f003f00   0b001f003f00
23
               0b001f003f01   0b001f003f01   0b001f003f01
24
0c001f003f01   0c000f003f00   0c000f003f00   0c000f003f00
25
               0c000f003f01   0c000f003f01   0c000f003f01
26
0d001f003f01   0d0000003f00   0d0000003f0    0d0000003f00
27
               0d0000003f01   0d0000003f0    0d0000003f01
28
0e001f003f01                                               
29
0f001f003f01   0f0000003f00   0f0000003f00   0f0000003f00   
30
               0f0000003f01   0f0000003f01   0f0000003f01
31
10001f003f01   10001f003f00   10001f003f00   10001f003f00
32
               10001f003f01   10001f003f01   10001f003f01
33
11001f003e01   20005500ca00   20005400290    20009a004b00  
34
               20005500aa00                  200054004900
35
12001f003f01   120000000300   12000000030    120000008300   FDC Wiederholung nur
36
               120000008300   12000000830                   manchmal
37
13001f003f01   130003003f00   130003003f0    130003003f00   
38
               130003003f01   130003003f0    130003003f01   
39
14001f003f01   14000f003f00   14000f003f00   14000f003f00
40
               14000f003f01   14000f003f01   14000f003f01
41
15001f003f01   15001f003f00   15001f003f00   15001f003f00
42
               15001f003f01   15001f003f01   15001f003f01
43
16001f003f01   160000000300   16000000030    160000000300
44
               160000000301   16000000030    160000000301
45
18001f003f01                  170095002a0                   IR60 Protokoll
46
1b001f003f01   1b001f003f00   1102aa015a0    1102aa015a00   NEC16 Protokoll nur
47
               1b001f003f01   1102aa015a0    1102aa015a01   manchmal
48
                              1102aa015a0    1102aa015a01   
49
1c001f003f01   1c001f003f00   1c001f003f00   1c001f003f00   NEC42 Wiederholung
50
               1c001f003f01                                 nur manchmal
51
1d001f003f01                                                Lego Protokoll
52
1e001f003f01   1e000f003f00   1e000f003f00   1e000f003f00   Thomson Wiederholung
53
                              1e000f003f01   1e000f003f01   nur manchmal
54
1f001f003f01   1f0000003f00   1f0000003f00   1f0000003f00   
55
               1f0000003f01   1f0000003f01   1f0000003f01
56
20001f003f01   2000df00bf00   2000df00bf00   2000df00af00   A1TV Kommando,
57
               2000df003f00   2000df003f00                  Wiederholung nur  
58
22001f003f01   220000003f00   220000003f0    220000003f00   manchmal
59
               220000003f01   220000003f0    220000003f01   
60
27001f003f01   270000003f00   270000003f0    270000003f00
61
               270000003f01   270000003f0    270000003f01
62
28001f003f01   28001f003f00   28001f003f00   28001f003f00
63
               28001f003f01   28001f003f01   28001f003f01
64
29001f003f01   29001f003f00   29001f003f00   29001f003f00
65
               29001f003f01   29001f003f01   29001f003f01
66
               29001f003f01   29001f003f01   29001f003f01
67
               29001f003f01   29001f003f01   29001f003f01
Anbei der Scan von Lego und IR60. Da A1TV geht und geringfügig kürzere 
Timings hat als Lego, kann es nicht am Filtern liegen, dass Lego nicht 
geht, sondern vermutlich an schlechteren Timings.

Der Nutzen der Tests mit irsnd ${irdata} | irmp besteht in der Erkennung 
vorher unbekannter Fehler (hauptsächlich Kommando und Adresse) und 
zusätzlicher Verifizierung.
Mit  µC-Draht-µC werden weitere Fehler herausgefunden (vermutlich weil 
ein µC langsamer ist als eine CPU und dadurch kritische Timings 
deutlicher sichtbar werden, betrifft eigentlich nur B&O).
Mit nicht filterndem TSOP werden noch mehr Fehler sichtbar (vermutlich 
weil die Timings weiter verschlechtert werden, manche Protokolle gehen 
nicht mehr, andere nur noch manchmal).
Deswegen glaube ich, es wäre nützlich, zu deinem Test noch die drei 
weiteren Tests hinzuzufügen, um mehr Fehler zu erkennen und 
praxisgerecht zu testen.

Wenn man sich die Verschlechterung in diesen Schritten:
Scans → IRMP
Irsnd → IRMP
µC → Draht → µC
µC → IR_Diode → TSOP → µC
anschaut, fällt auf, dass es vor allem durch den TSOP schlechter wird. 
Vielleicht muss man da wie schon von Armin vorgeschlagen etwas 
kompensieren:
"When received, marks tend to be too long and spaces tend to be too 
short. To compensate for this, MARK_EXCESS_MICROS is subtracted from all 
marks, and added to all spaces."
https://www.analysir.com/blog/2014/03/27/infrared-receivers-signal-lag/
https://github.com/Arduino-IRremote/Arduino-IRremote/issues/266
Was bringt es, wenn die Scans gehen, aber der TSOP die Timings so 
verändert, dass dadurch weniger geht?
(Die bisherige Theorie, dass das an zuviel gleichzeitigen Protokollen 
liegt, ist ja durch meine Versuche widerlegt.)

Insgesamt ist das Jammern auf hohem Niveau, denn das meiste geht ja sehr 
gut :)

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Zum Vergleich Lego (nur der Anfang) gesendet mit irsnd (obere Zeile) und 
nach dem TSOP gescannt (untere zwei Zeilen):
1
000111111111111111111111000111110001111100011111000111110001111100011111000111111111110001111111
2
000011111111111111111111000011110000011100001111000011110000111100001111000011111111110000111111
3
000011111111111111111111000111110000111100001111000011110000111100001111000011111111110000111111
Man sieht, dass meistens um eine Null verlängert wird und dafür eine 
Eins fehlt (manchmal sind es zwei oder keine).
Das erklärt aber noch nicht, warum nicht erkannt wurde. Denn irmp-20kHz 
erkennt den Scan.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Zum Vergleich Lego (nur der Anfang) gesendet mit irsnd (obere Zeile) und
> nach dem TSOP gescannt

Danke für das anschauliche Beispiel. Mich würden ja mal die 
Größenordnungen interessieren. Hast Du einen Logic-Analyzer oder ein 
Oszi, um mal genauer zu messen?

> Denn irmp-20kHz erkennt den Scan.

LEGO habe ich nach Dokumentation implementiert, also nicht empirirsch 
mittels IRMP-Scans. Das heisst, die Lego-Timings in irmpprotocols.h sind 
die, welche am Sender entstehen.

Dass IRMP das Lego-Protokoll am TSOP trotzdem erkennt, liegt wohl an den 
Toleranzen, mit denen IRMP arbeitet. Diese sind auch unbedingt 
notwendig.

Ich habe schon viele FBs in der Hand gehabt. Dass welche mit demselben 
Protokoll arbeiten, sagt überhaupt nichts über das abweichende 
Timingverhalten der einen oder anderen Fernbedienung aus. Jede FB hat 
Timing-Abeweichungen nach oben oder unten. Ich habe da schon 
Abweichungen im zweistelligen Prozentbereich gesehen. Aus diesem Grund 
sind auch für alle Protokolle Toleranzen in irmp.c angegeben - bis zu 30 
Prozent (oder mehr) für einige Protokolle.

: Bearbeitet durch Moderator
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Kleiner Exkurs über die Toleranzen:

IRMP zeigt in der Linux-Version beim Scannen eines Protokolls die 
erkannten Timings inkl. Toleranzen an, wenn man die Option "-v" 
verwendet.

Beispiel für NEC:
1
$ ./irmp-10kHz -v < IR-Data/nec.txt
2
  13.800ms [start-bit: pulse = 97, pause = 44]
3
protocol = NEC, start bit timings: pulse:  62 - 118, pause:  30 -  60
4
pulse_1:   3 -   8
5
pause_1:  11 -  23
6
pulse_0:   3 -   8
7
pause_0:   3 -   8
8
command_offset: 16
9
command_len:     16
10
complete_len:    32

Das heisst:
1
- NEC erkannt
2
- Für das Start-Bit werden folgende Längen akzeptiert:
3
     62 - 118  Nullen
4
     30 - 60   Einsen
5
- Für die Daten werden folgende Längen akzeptiert:
6
     3 -  8    Nullen
7
     3 -  8    Einsen oder
8
    11 - 23    Einsen

Wie man hier schön sieht, sind die von IRMP verwendeten Toleranzen schon 
enorm. Diese sind aber auch notwendig, wie man aus der Praxis bzw. aus 
den an mich eingeschickten Scans (liegen im Unterverzeichnis IR-Data) 
sehr gut nachvollziehen kann.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Hast Du einen Logic-Analyzer oder ein
> Oszi, um mal genauer zu messen?
Nein. Ich könnte es mit einem Soundkarten-Oszi probieren. Dazu müsste 
ich aber erst einen Adapter löten, das kann dauern.
Wäre es eigentlich möglich, die Scan-Funktion und IRMP mit z.B. 38kHz 
(oder noch mehr) laufen zu lassen (auf STM32F103 mit 72MHz) für genauere 
Scans?

.
Frank M. schrieb:
> Dass IRMP das Lego-Protokoll am TSOP trotzdem erkennt,
Falls das ein Mißverständnis ist, ich meinte  ./irmp-20kHz < 
cutecom.log.lego am PC funktioniert. Aber der µC erkennt nichts.

.
Wie debuggt man die Fehler am besten? printf's vom µC? Genauere Scans 
nach dem TSOP am PC auswerten?

Wie weit kommst du eigentlich damit hinterher, die Fehler, mit denen ich 
dich überschütte, zu beheben? Ist ja viel auf einmal.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jörg R. schrieb:
> Wie debuggt man die Fehler am besten? printf's vom µC? Genauere Scans
> nach dem TSOP am PC auswerten?

Ich machs am PC mit der Option -v. Da sieht man eigentlich ganz genau, 
wo der IRMP sich entweder in ein anderes Protokoll verrennt oder sich 
über Timing-Fehler beklagt.

> Wie weit kommst du eigentlich damit hinterher, die Fehler, mit denen ich
> dich überschütte, zu beheben? Ist ja viel auf einmal.

Auf jeden Fall verschiebt jede Fehlermeldung das nächste Release um 
weitere 2 Wochen nach hinten ;-)

Ich habe bereits zweimal angesetzt, ein neues Release rauszugeben und 
das beide Male dann doch wieder verschoben.

von Jörg R. (jrie)


Bewertung
0 lesenswert
nicht lesenswert
Dann mal zur Beschleunigung des nächsten Releases ein gutes Ergebnis ;-)
Alle mit 38kHz gesendet, mit 38 kHz über den TSOP 34338 empfangen die 
nächsten 5 Spalten, mit 19kHz über den TSOP 34338 empfangen die letzte 
Spalte (dabei geht Lego nicht).
Außer einmal Sony umgekippt in Siemens (habe ich schon öfter gesehen) 
und einmal keine Wiederholung bei Denon keine neuen Fehler (im Vergleich 
zu  28.12.2020 11:13).
1
gesendet      empfangen     empfangen     empfangen     empfangen     empfangen     empfangen   
2
01081f003f01  1102aa015a00  01081f003f00  01081f003f00  01081f003f00  01081f003f00  01081f003f00
3
              01081f003f00  01081f003f01  01081f003f01  01081f003f01  01081f003f01  01081f003f01
4
02001f003f01  02001f003f00  02001f003f00  02001f003f00  02001f003f00  02001f003f00  02001f003f00
5
              02001f003f01  02001f003f01  02001f003f01  02001f003f01  02001f003f01  02001f003f01
6
03001f003f01  03001f003f00  03001f003f00  03001f003f00  03001f003f00  03001f003f00  03001f003f00
7
              03001f003f01  03001f003f01  03001f003f01  03001f003f01  03001f003f01  03001f003f01
8
04001f003f01  04001f003f00  04001f003f00  04001f003f00  04001f003f00  04001f003f00  04001f003f00
9
              04001f003f01  04001f003f01  04001f003f01  04001f003f01  04001f003f01  04001f003f01
10
05001f003f01  05001f003f00  05001f003f00  05001f003f00  05001f003f00  05001f003f00  05001f003f00
11
              05001f003f01  05001f003f01  05001f003f01  05001f003f01  05001f003f01  05001f003f01
12
06001f003f01  060007003f00  060007003f00  060007003f00  060007003f00  060007003f00  060007003f00
13
              060007003f01  060007003f01  060007003f01  060007003f01  060007003f01  060007003f01
14
07001f003f01  07001f003f00  07001f003f00  07001f003f00  07001f003f00  07001f003f00  07001f003f00
15
              07001f003f01  07001f003f01  07001f003f01  07001f003f01  07001f003f01  07001f003f01
16
08001f003e01  08001f003e00  08001f003e00  08001f003e00  08001f003e00  08001f003e00  08001f003e00
17
              08001f003e01  08001f003e01                08001f003e01  08001f003e01  08001f003e01
18
09001f003f01  09001f003f00  09001f003f00  09001f003f00  09001f003f00  09001f003f00  09001f003f00
19
              09001f003f01  09001f003f01  09001f003f01  09001f003f01  09001f003f01  09001f003f01
20
0a001f003f01  0a001f003f00  0a001f003f00  0a001f003f00  0a001f003f00  0a001f003f00  0a001f003f00
21
              0a001f003f01  0a001f003f01  0a001f003f01  0a001f003f01  0a001f003f01  0a001f003f01
22
0b001f003f01  0b001f003f00  0b001f003f00  0b001f003f00  0b001f003f00  0b001f003f00  0b001f003f00
23
              0b001f003f01  0b001f003f01  0b001f003f01  0b001f003f01  0b001f003f01  0b001f003f01
24
0c001f003f01  0c000f003f00  0c000f003f00  0c000f003f00  0c000f003f00  0c000f003f00  0c000f003f00
25
              0c000f003f01  0c000f003f01  0c000f003f01  0c000f003f01  0c000f003f01  0c000f003f01
26
0d001f003f01  0d0000003f00  0d0000003f00  0d0000003f00  0d0000003f00  0d0000003f00  0d0000003f00
27
              0d0000003f01  0d0000003f01  0d0000003f01  0d0000003f01  0d0000003f01  0d0000003f01
28
0e001f003f01                                                                                    
29
0f001f003f01  0f0000003f00  0f0000003f00  0f0000003f00  0f0000003f00  0f0000003f00  0f0000003f00
30
              0f0000003f01  0f0000003f01  0f0000003f01  0f0000003f01  0f0000003f01  0f0000003f01
31
10001f003f01  10001f003f00  10001f003f00  10001f003f00  10001f003f00  10001f003f00  10001f003f00
32
              10001f003f01  10001f003f01  10001f003f01  10001f003f01  10001f003f01  10001f003f01
33
11001f003e01  11001f003e00  11001f003e00  11001f003e00  11001f003e00  11001f003e00  11001f003e00
34
                                          11001f003e01                              11001f003e01
35
12001f003f01  120000000300  120000000300  120000000300  120000000300  120000000300  120000000300
36
              120000008300  120000008300  120000008300  120000008300  120000008300  120000008300
37
13001f003f01  130003003f00  130003003f00  130003003f00  130003003f00  130003003f00  130003003f00
38
              130003003f01  130003003f01  130003003f01  130003003f01  130003003f01  130003003f01
39
14001f003f01  14000f003f00  14000f003f00  14000f003f00  14000f003f00  14000f003f00  14000f003f00
40
              14000f003f01  14000f003f01  14000f003f01  14000f003f01  14000f003f01  14000f003f01
41
15001f003f01  15001f003f00  15001f003f00  15001f003f00  15001f003f00  15001f003f00  15001f003f00
42
              15001f003f01  15001f003f01  15001f003f01  15001f003f01  15001f003f01  15001f003f01
43
16001f003f01  160000000300  160000000300  160000000300  160000000300  160000000300  160000000300
44
              160000000301  160000000301  160000000301  160000000301  160000000301  160000000301
45
18001f003f01  180000003f00  180000003f00  180000003f00  180000003f00  180000003f00  180000003f00
46
1b001f003f01  1b001f003f00  1b001f003f00  1b001f003f00  1b001f003f00  1b001f003f00  1b001f003f00
47
              1b001f003f01  1b001f003f01  1b001f003f01  1b001f003f01  1b001f003f01  1b001f003f01
48
1c001f003f01  1c001f003f00  1c001f003f00  1c001f003f00  1c001f003f00  1c001f003f00  1c001f003f00
49
              1c001f003f01  1c001f003f01  1c001f003f01  1c001f003f01  1c001f003f01  1c001f003f01
50
1d001f003f01  1d0000003f00  1d0000003f00  1d0000003f00  1d0000003f00  1d0000003f00              
51
              1d0000003f01  1d0000003f01  1d0000003f01  1d0000003f01  1d0000003f01              
52
1e001f003f01  1e000f003f00  1e000f003f00  1e000f003f00  1e000f003f00  1e000f003f00  1e000f003f00
53
              1e000f003f01  1e000f003f01  1e000f003f01  1e000f003f01  1e000f003f01  1e000f003f01
54
1f001f003f01  1f0000003f00  1f0000003f00  1f0000003f00  1f0000003f00  1f0000003f00  1f0000003f00
55
              1f0000003f01  1f0000003f01  1f0000003f01  1f0000003f01  1f0000003f01  1f0000003f01
56
20001f003f01  2000df003f00  2000df003f00  2000df003f00  2000df003f00  2000df003f00  2000df00bf00
57
              2000df003f01  2000df003f01  2000df003f01  2000df003f01  2000df003f01  2000df00bf01
58
22001f003f01  220000003f00  220000003f00  220000003f00  220000003f00  220000003f00  220000003f00
59
              220000003f01  220000003f01  220000003f01  220000003f01  220000003f01  220000003f01
60
27001f003f01  270000003f00  270000003f00  270000003f00  270000003f00  270000003f00  270000003f00
61
              270000003f01  270000003f01  270000003f01  270000003f01  270000003f01  270000003f01
62
28001f003f01  28001f003f00  28001f003f00  28001f003f00  28001f003f00  28001f003f00  28001f003f00
63
              28001f003f01  28001f003f01  28001f003f01  28001f003f01  28001f003f01  28001f003f01
64
29001f003f01  29001f003f00  29001f003f00  29001f003f00  29001f003f00  29001f003f00  29001f003f00
65
              29001f003f01  29001f003f01  29001f003f01  29001f003f01  29001f003f01  29001f003f01
66
              29001f003f01  29001f003f01  29001f003f01  29001f003f01  29001f003f01  29001f003f01
67
              29001f003f01  29001f003f01  29001f003f01  29001f003f01  29001f003f01  29001f003f01

von Derek, Chen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,
Thank you for your reply, I have benefited a lot.
Derek

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.