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?
#if IRMP_32_BIT == 1

typedef struct
{
    uint8_t                             protocol;                                   // protocol, e.g. NEC_PROTOCOL
    uint16_t                            address;                                    // address
    uint32_t                            command;                                    // command
    uint8_t                             flags;                                      // flags, e.g. repetition
} IRMP_DATA;

#else // not IRMP_32_BIT == 1

#if defined(PIC_C18)
#  define IRMP_PACKED_STRUCT
#else
#  ifndef IRMP_PACKED_STRUCT
#    define IRMP_PACKED_STRUCT          __attribute__ ((__packed__))
#  endif
#endif

typedef struct IRMP_PACKED_STRUCT
{
    uint8_t                             protocol;                                   // protocol, e.g. NEC_PROTOCOL
    uint16_t                            address;                                    // address
    uint16_t                            command;                                    // command
    uint8_t                             flags;                                      // flags, e.g. repetition
} IRMP_DATA;

#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:
Nun kann man direkt mit IRMP anschließend testen, ob das erzeugte Telegramm auch korrekt ist:

           ./irmp-15kHz < nec.txt

bzw. unter Windows:

           irmp.exe < nec.txt

Das Ganze geht auch ohne Zwischendatei, nämlich:

           ./irsnd-15kHz 2 00FF 0001 | ./irmp-15kHz

bzw. unter Windows:

           irsnd.exe 2 00FF 0001 | irmp.exe

IRMP gibt dann als Ergebnis folgendes aus:

           11111111000000001000000001111111 p =  2, a = 0x00ff, c = 0x0001, f = 0x00

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:
cc -Wall -DF_INTERRUPTS=10000 irmp.c -o irmp-10kHz
In file included from irmp.c:23:0:
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 :-(
IRMP unter Linux und Windows
Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener Autoren (siehe Versionsgeschichte)

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.
make -f makefile.lnx
cc -Wall -DF_INTERRUPTS=10000 irmp.c -o irmp-10kHz
In file included from irmp.c:23:0:
irmp.h:212:4: warning: #warning F_INTERRUPTS too low, SIEMENS protocol disabled (should be at least 15000) [-Wcpp]
cc -Wall -DF_INTERRUPTS=15000 irmp.c -o irmp-15kHz
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:
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
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:
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
     irmp-15kHz -a < scan.txt
analysiert, dann das Protokoll implementiert, mit
     irmp-15kHz -v < scan.txt
debuggt und letztendlich mit
     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:
Raster ist: 1 / 19000 = 52,6315 us
Der an 560 nächstgelegene ganzzahlige Wert als Multiplikator ist 11:
11 * 52,6315 us = 579 us

Ebenso kann man auch den Fehler für 15kHz berechnen:
Raster ist: 1 / 15000 = 66,6667 us
Der an 560 nächstgelegene ganzzahlige Wert als Multiplikator ist 9:
9 * 66,6667 us = 600 us
Obwohl eigentlich
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:
gesendet      empfangen    Fehler
01001f003f00  010000003f00 SIRCS keine Adresse
02001f003f00  02001f003f00 OK
03001f003f00  03001f003f00 OK
04001f003f00  04001f003f00 OK
05001f003f00  05001f003f00 OK
07001f003f00  07001f003f00 OK
08001f003f00               DENON geht nur manchmal
09001f003f00  09001f003f00 OK
0f001f003f00  0f0000003f00 OK
10001f003f00  10001f003f00 OK
11001f003f00               SIEMENS geht nicht
14001f003f00  14000f003f00 OK
15001f003f00  15001f003f00 OK
18001f003f00  180000003f00 OK
1b001f003f00  1b001f003f00 OK
1c001f003f00  1c001f003f00 OK
gesendet     empfangen                  Fehler
01001f003f01 010000003f00 010000003f01  SIRCS keine Adresse
02001f003f01 02001f003f00 02001f003f01  OK
03001f003f01 03001f003f00 03001f003f01  OK
04001f003f01 04001f003f00 04001f003f01  OK
05001f003f01 05001f003f00 05001f003f01  OK
07001f003f01 07001f003f00 07001f003f01  OK
08001f003f01 08001f03c000               DENON geht nur manchmal, Kommando falsch
09001f003f01 09001f003f00 09001f003f01  OK
0f001f003f01 0f0000003f00 0f0000003f01  OK
10001f003f01 10001f003f00 10001f003f01  OK
11001f003f01                            SIEMENS geht nicht
14001f003f01 14000f003f00 14000f003f01  OK
15001f003f01 15001f003f00 15001f003f01  OK
18001f003f01 180000003f00               OK
1b001f003f01 1b001f003f00 1b001f003f01  OK
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.

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.