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?
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.
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.
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.
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.
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.
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.
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.
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!
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!!!
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.
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.
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.
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. ;-)
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.
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.
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:
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
IRMP16Address=0x27Command=0x27P=ONKYOA=0x27C=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.
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?
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.
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.
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.
...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.
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.
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.
Jörg R. schrieb:> 11001f003f00 SIEMENS geht nichtJö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:
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?
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.
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).
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?
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.
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?
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.
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.
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?
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.
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
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.
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
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.
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.
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.
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.
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).
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 ;)
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?
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.
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
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.
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
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.
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.
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^^
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.
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?
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:
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.
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.
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:
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.
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.
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.
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:
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:
> 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.
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.
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.
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?
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.
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.
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.
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!!!
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^^
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.
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.
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.
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
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.
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.
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).
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
caseIRMP_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
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ß
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
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.
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ß
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
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
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
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 :)
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.
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.
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:
- 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.
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.
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.
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).
Frank M. schrieb:> Hast Du einen Logic-Analyzer oder ein> Oszi, um mal genauer zu messen?
Mit einem buck50 (https://github.com/thanks4opensource/buck50) habe ich
Lego gescannt (lego.vcd). Man sieht die verlängerten Pulse und die
verkürzten Pausen. Die verlängerten Pulse und die verkürzten Pausen
hängen auch vom Protokoll ab, bei RC5 sind sie nur im Bereich 14-18µs,
bei Lego 34-40µs.
Fix für Lego (LEGO_1_PAUSE_LEN_MIN darf nur 25%, entsprechend auch
LEGO_0_PAUSE_LEN_MAX nur 30%, sonst kippt so manche Null in Eins, da die
sich vorher überlappt haben):
Zu den verlängerten Pulsen und den verkürzten Pausen:
Ich finde es nicht erstrebenswert, eine Kompensation für den
IR-Empfänger (TSOP) einzuführen, denn dann bräuchte man für jeden
IR-Empfänger und für jedes Protokoll eine andere Firmware. Der
vorhandene Ansatz mit großzügigen Toleranzen gefällt mir besser und
funktioniert ja auch gut.
Ich habe auch einen Scan von Recs80 analysiert, weil da auch 158µs Pulse
sind. Die Pausen sind aber viel länger, und das "beruhigt" den TSOP, die
Abweichungen der empfangenen Längen untereinander sind jedenfalls viel
kleiner als bei Lego.
Jörg R. schrieb:> Die verlängerten Pulse und die verkürzten Pausen> hängen auch vom Protokoll ab, bei RC5 sind sie nur im Bereich 14-18µs,> bei Lego 34-40µs.
Danke für die Info. Die Protokollabhängigkeit kann ich mir nur mit den
unterschiedlichen Modulationsfrequenzen erklären. RC5: 36kHz, Lego:
38Khz (meines Wissens nach). Kann es sein, dass das ein 36kHz-TSOP war,
so nach dem Motto: Je unpassender die Modulationsfrequenz, desto größer
die Verkürzungen/Verlängerungen?
Da bei INTERRUPTS=15000 die Auflösung gerad mal 67µs beträgt, ist das
unterhalb des Radars. Bei INTERRUPTS=20000 sind es 50µs - auch nicht
viel besser.
Jörg R. schrieb:> Fix für Lego (LEGO_1_PAUSE_LEN_MIN darf nur 25%, entsprechend auch> LEGO_0_PAUSE_LEN_MAX nur 30%, sonst kippt so manche Null in Eins, da die> sich vorher überlappt haben):
Danke für den Tipp, werde ich so übernehmen.
Jörg R. schrieb:> Zu den verlängerten Pulsen und den verkürzten Pausen:> Ich finde es nicht erstrebenswert, eine Kompensation für den> IR-Empfänger (TSOP) einzuführen,
Es wird auch kaum eine höhere Genauigkeit bringen. Ich sehe in den Scans
oft auch Timing-Abweichungen von ein und derselben Fernbedienung. Von
daher liegen die Verlängerungen/Verkürzungen eigentlich unterhalb der
Wahrnehmungsgrenze und beeinflussen den Zählvorgang von Pulsen/Pausen
höchstens um den Wert 1. Das liegt dann immer innerhalb der Toleranzen.
Die Kunst besteht eindeutig in der richtigen Einstellung der Toleranzen.
Sie dürfen nicht zu groß sein, dass Konflikte entstehen, sie dürfen aber
auch nicht zu klein sein, dass Ungenauigkeiten das Decoding unmöglich
machen.
Frank M. schrieb:> Die Protokollabhängigkeit kann ich mir nur mit den> unterschiedlichen Modulationsfrequenzen erklären. RC5: 36kHz, Lego:> 38Khz (meines Wissens nach). Kann es sein, dass das ein 36kHz-TSOP war,> so nach dem Motto: Je unpassender die Modulationsfrequenz, desto größer> die Verkürzungen/Verlängerungen?
Es war ein TSOP34338 mit 38kHz, also genau umgekehrt.
Aber meine Versuche zeigen, dass bei mit 19kHz senden und empfangen mehr
Protokolle erkennt werden als bei mit 20 kHz senden und enpfangen. Und
die allermeisten Protokolle haben ja 38kHz.
Deswegen sollten die Abfragen für RCMM und Lego von 20000 auf 19000
gesenkt werden.
Bleibt noch die Frage, wieso die Erkennung bei mit 38kHz gesendet
deutlich besser ist als bei mit 19kHz gesendet, bzw. ob man bei mit
19kHz senden noch was verbessern kann.
An welchen Baustellen sitzt du eigentlich noch (damit ich nicht an
Sachen ran gehe, die du schon gemacht hast)?
Jörg R. schrieb:> Es war ein TSOP34338 mit 38kHz, also genau umgekehrt.
Ich habs befürchtet.
> Aber meine Versuche zeigen, dass bei mit 19kHz senden und empfangen mehr> Protokolle erkennt werden als bei mit 20 kHz senden und enpfangen. Und> die allermeisten Protokolle haben ja 38kHz.
2 x 19 = 38. Vermutlich ist ein Verhältnis mit ganzem Teiler besser,
weils dann weniger solcher "Kipper" gibt: Mal ein Puls eine Zeiteinheit
länger, mal kürzer.
> Deswegen sollten die Abfragen für RCMM und Lego von 20000 auf 19000> gesenkt werden.
Das ist eine gute Idee.
> Bleibt noch die Frage, wieso die Erkennung bei mit 38kHz gesendet> deutlich besser ist als bei mit 19kHz gesendet, bzw. ob man bei mit> 19kHz senden noch was verbessern kann.
Du hast tatsächlich IRSND mit INTERRUPTS=38000 betrieben? Hm, habe ich
das oben irgendwo überlesen?
> An welchen Baustellen sitzt du eigentlich noch (damit ich nicht an> Sachen ran gehe, die du schon gemacht hast)?
Die Baustellen, an denen ich werkele, haben nichts mit IRMP zu tun ;-)
Du kannst also gern fröhlich weitere Verbesserungen einbauen. Vielleicht
sollte ich den aktuellen Stand mal einchecken?
Jörg R. schrieb:> Alle mit 38kHz gesendet,Frank M. schrieb:> Du hast tatsächlich IRSND mit INTERRUPTS=38000 betrieben?
Ja.
.
Frank M. schrieb:> Vielleicht> sollte ich den aktuellen Stand mal einchecken?
Ja, bitte :)
Spricht eigentlich irgendwas dagegen, 38 kHz zu benutzen, wenn der µC
das schafft? Ich habe sogar mal 76 kHz getestet, dann gehen manche
Protokolle noch gut, andere nicht mehr. Ich werde durch Verbessern der
Timings versuchen, ob auch alles 19 kHz Gesendete optimal dekodiert
werden kann. Bei einigen Protokollen ist 10% vielleicht zu eng.
Jörg R. schrieb:> Spricht eigentlich irgendwas dagegen, 38 kHz zu benutzen, wenn der µC> das schafft?
Von mener Seite aus nicht. Ein STM32 sollte das locker schaffen. Bei
AVRs wirds dann wohl eng...
Es gibt sowohl für IRMP als auch für IRSND eine neue Version
3.2.6:
Änderungen:
- Neues IR-Protokoll: MELINERA
- Protokoll LEGO: Timing verbessert
- Protokoll RUWIDO: Timing verbessert
- Protokoll NEC: Senden von Repetition-Frames ermöglicht
Zum letzten Punkt:
Dies ist eine spezielle Erweiterung für IR-Repeater. Hier kann es in
Einzelfällen sinnvoll sein, dass IRSND nicht automatisch
Wiederholungsframes erzeugt, sondern dass die Applikation gezielt
Wiederholungsframes senden kann. Dies ist speziell für das NEC-Protoll
sinnvoll.
Erklärt wird die Anwendung hier:
https://www.mikrocontroller.net/articles/IRSND#Wiederholungsframes_f.C3.BCr_NEC
Viel Spaß,
Frank
Danke für das neue Release :)
Angehängter Patch ermöglicht Logging mit STM32F30x.
Auf meiner TODO Liste sind Protokolle betreffend:
* Sony kippt manchmal in Siemens um
* Logi kippt öfter in Ruwido um
* Thomson hat öfter keine Wiederholung
* IR60 hat nie Wiederholung
* Denon hat selten keine Wiederholung
Wenn Sony als Siemens erkannt wird, liegt das daran, dass am Anfang ca.
18 Nullen fehlen. cutecom.log.x_sony wird als Siemens (und die zwei
Wiederholungen als Sony) erkannt. Wenn man vorne 18 Nullen einfügt, wird
es korrekt nur als Sony erkannt.
Woran kann das liegen, dass da beinahe 1 ms an Nullen "verschluckt"
wird?
Gescannt und gesendet mit 19kHz.
Dass Lego manchmal als Ruwido oder Siemens oder gar nicht erkannt wird,
liegt daran, dass im Erkennungsfall das Startbit als 3 Nullen + 19
Einsen geloggt wird, im Fehlerfall aber als 4 Nullen + 18 Einsen geloggt
wird. Letzteres wird als Ruwido erkannt.
Mit folgender Änderung wird sowohl Lego als auch Siemens korrekt nach
dem TSOP erkannt:
Jetzt kann ich auch verstehen, warum es anderen Siemens Code mit
längerem SIEMENS_OR_RUWIDO_START_BIT_PULSE_TIME gab.
Und warum sollte 4,5 bis 5,49 auf 4 gerundet werden?
Bei 19kHz ist F_INTERRUPTS * SIEMENS_OR_RUWIDO_START_BIT_PULSE_TIME
nämlich 5,225 und da passt 5 besser als 4.
Erkannt wird nur das mit Wiederholung gesendete, aber das nur als
einfach.
Auch alles mit 19 kHz.
.
Armin J. schrieb:> Bei mir (AVR) tuts das einwandfrei!
Auch mit deinem STM32 BluePill? Dann wäre ein Scan zum Vergleich
interessant.
Bei IR60 geht mit der Wiederholung etwas total schief. Zum Vergleich ein
Scan mit (cutecom.log.ir60_01) und ohne ( cutecom.log.ir60_00)
Wiederholung. Das bei mit Wiederholung zusätzlich Gesendete ergibt bei
der Erkennung Müll.
Dass Thomson öfter keine Wiederholung hat, kann ich gerade nicht
reproduzieren. Allerdings habe ich zwecks besserem Scannen alle
Protokolle abgeschaltet, denn mir scheint, dann funktioniert das Scannen
besser.
Bei allen Scans von heute lief also keine Erkennung parallel.
Bei Denon hatte ich vergessen, dass das Kommando gerade sein muss.
Mit geradem Kommando kann ich die selten fehlende Wiederholung auch
nicht reproduzieren.
Bei IR60 wird der Start-Frame verdoppelt statt der Daten-Frame, und
deswegen geht die Wiederholung nicht. Denn der Daten-Frame wird zuerst
gesendet und dann der Start-Frame. Der Fix steht aber schon im Code und
muss nur aktiviert werden.
Wenn in Zeile 1533 if 0 durch if 1 ersetzt wird, geht die Wiederholung.
Gesehen habe ich das mit dem buck50 (i2.vcd).
Das Loggen funktioniert selbst ohne aktive Protokolle nicht zuverlässig,
da fehlte Einiges (cutecom.log.ir60_01, weiter oben).
Bei 12 Versuchen mit 19 kHz gingen alle 33 Protokolle (ausser einmal
keine Wiederholung bei RCCAR). Ich habe noch folgendes drin:
irmp.c.diff, bessere Timings für Thomson (deshalb ging es jetzt) und für
Siemens (bin nicht sicher ob die nötig sind, aber damit geht es).
Bei 200 Mal die 33 Protokolle senden (das dauert eine Stunde) gab es nur
noch einige Male Probleme mit Siemens und A1TVBox. Alle anderen waren
tadellos. Getestet mit
https://github.com/j1rie/IRMP_STM32/tree/master/test-suite
Siemens kippt manchmal in A1TVBox, und A1TVBox hat manchmal falsche Bits
oder wird nicht erkannt.
An den Stelllen, an denen ich mit festen Werten korrigiert habe, muss
noch in Prozent umgerechnet werden, damit es auch mit anderer Interrupt
Frequenz geht. An einer Stelle ist das nicht möglich, da weiß ich noch
nicht.
Ich werde dann auch mit 20, 15 und 10 kHz testen.
Edit: Hab's ausgerechnet und angehängt.
Wieso bei aufrunden noch 1 addiert wird bzw. bei abrunden noch 1
subtrahiert wird, verstehe ich aber nicht.
Jörg R. schrieb:> Woran kann das liegen, dass da beinahe 1 ms an Nullen "verschluckt"> wird?
Das passiert immer beim ersten Mal Senden nach Firmware Start. Mit einem
Logic Analyzer sehe ich, dass dann an der Sendediode der erste Puls 0,9
ms zu kurz ist.
Jörg R. schrieb:> Ich werde dann auch mit 20, 15 und 10 kHz testen.
irsnd-20kHz | irmp-20kHz funktioniert tadellos, aber beim gründlichen
Test 200x33 gibt es viele Fehler.
Mit irsnd-15kHz | irmp-15kHz fallen mehr Protokolle aus, als von den
Kommentaren im Code erwartet, und mit irsnd-10kHz | irmp-10kHz nochmals
mehr. Darum habe ich keinen gründlichen Test mit 15kHz oder mit
10kHz gemacht.
Erstmal danke für Deine unermüdliche Arbeit, Jörg. Ich werde Deinen diff
fürs nächste Release vorsehen. Das kann allerdings etwas dauern, weil
Andreas das SVN hier nicht mehr weiter anbieten wird. IRMP wird daher
endgültig auf github umziehen.
Da die Arduino-Version, welche Armin immer aus den IRMP-Releases
generiert, schon seit längerem auf github ist, wird dort dann demnächt
eine gemeinsame Version weitergeplegt. Dazu werde ich Deinen diff-Output
in die Arduino-Verion einarbeiten, damit Armin nicht immer wieder aufs
neue IRMP auf Arduino portieren muss. Um sowohl die Arduino- als auch
die Non-Arduino-Version aus einem Repository anzubieten, bedarf es noch
ein paar Gedanken über die zukünftige Organisation des Source-Codes. In
der Arduino-Version heißt irmp.c nämlich irmp.c.h, welches als Include
genutzt wird. Dies gilt auch noch für weitere IRMP-/IRSND-Quelldateien.
Diesen eklatanten Unterschied gilt es für eine gemeinsame Version
abzustellen.
Frank M. schrieb:> nämlich irmp.c.h
Ist das jetzt eine C Datei mit C Source oder eine Headerdatei?
Was für ein Graus in diesem Arduino-Zeugs.
Sorry aber mir rollen sich die Fußnägel auf. Schade um das schöne
Produkt IRMP.
Halte es in einem getrennten Repo. Wer das gerne in Arduino nutzen
möchte, kann das auch ohne dass es eine Arduino konforme Einbindung hat.
Der, der das nicht beherrscht, wird auch nicht IRMP benutzen da mehr als
LED-Blinky eh nicht drin ist.
900ss D. schrieb:> Ist das jetzt eine C Datei mit C Source oder eine Headerdatei?
Armin hat daraus eine Header-Datei gemacht. Das war ein technischer
Kunstgriff.
> Halte es in einem getrennten Repo.
Du kannst Dir sicher sein, dass es auch zukünftig ein irmp.c geben wird.
Ich werde mit Armin darüber diskutieren, wie wir sowohl Arduino als auch
Non-Arduino unter einen Hut bekommen.
Micha schrieb:> Gehe ich recht in der Annahme, dass ich mit IRSND gesendete Kommandos> mit IRMP testen kann indem ich die ISR so schreibe?
Mir geht es hauptsächlich um einen Test des Hardware-Sendepfads. Dass
der Empfang funktioniert sehe ich durch Tests mit verschiedenen
Fernbedienungen.
Jörg R. schrieb:> Das passiert immer beim ersten Mal Senden nach Firmware Start. Mit einem> Logic Analyzer sehe ich, dass dann an der Sendediode der erste Puls 0,9> ms zu kurz ist.
Die schlechte Nachricht: Es ist noch schlimmer, bei kurzen Pulsen wird
gar nichts gesendet. Da geht der Timer einfach nicht an. Also z.B.
beliebig oft Recs80 senden und nichts wird gesendet. Ich hatte schon
Zweifel, ob mein Board bzw. der Timer defekt wäre.
Der Timer wird erst durch Senden eines hinreichend langen Pulses
"geheilt". Da ich in meinen Tests mit Sony angefangen habe, hat bereits
der erste Frame genügt und das Problem ist nur beim ersten Mal
aufgetreten.
Die gute Nachricht: Ich habe den Fehler gefunden und behoben. Das war
eine harte Nuss. Code analysiert, Manual gelesen und Versuch und Irrtum.
Es steht zwar alles irgendwo bei STM, aber leicht verständlich ist was
anderes.
https://github.com/j1rie/IRMP/commit/8db0981aa544a6bc2ef098b72839dcc169513a50
Frank M. schrieb:> In der Arduino-Version heißt irmp.c nämlich irmp.c.h, welches als Include> genutzt wird.
In diesem Fall könnte man wohl in der irmp.c.h ein #include "irmp.c"
platzieren. Ob das in allen Fällen geht, kann ich nicht einschätzen. Und
schön ist es auch nicht.
900ss D. schrieb:> Nein, im Artikel ist auch ein Download> https://www.mikrocontroller.net/articles/IRMP#Download
Das weiß ich. Das ist Version 3.2.6 und in ukws github ist Version
3.4.1. Daher die Annahme, dass es die neuste Version nur für Arduino
gibt.
Jörg R. schrieb:> Bis es von Frank was Neues gibt, empfehle ich> https://github.com/j1rie/IRMP, da sind etliche Verbesserungen eingebaut.
Schaue ich mir mal an, danke. Funktioniert IRSND da mit der HAL Lib ohne
das Cube-Gedöns?
So war das nicht gemeint, bitte entschuldige! Vielen Dank für deine
Mühe!
Aktuell scheint Frank nicht viel Zeit für das Projekt zu haben, was zwar
schade, aber natürlich auch verständlich ist. Ich hoffe, dass sich das
wieder ändert oder er zumindest noch etwas Zeit findet um bspw. die
Sache mit dem Repo geradezuziehen.
Micha schrieb:> So war das nicht gemeint
Schon gut, alles ok. Im Artikel scheint es aber die letzte offizielle
Version von Frank zu sein. Was da im Arduinoableger passiert, ist mir
persönlich herzlich egal. Was ich davon halte schrieb ich dort schon:
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
Es wird noch in diesem Monat ein neues Release geben, welches auch die
Non-Arduino-Umgebungen umfasst. Bis dahin empfehle ich, wenn es denn
unbedingt die allerneueste Version sein soll, auf das Repository von
Jörg (jrie) zurückzugreifen.
P.S.
Die Versionsnummmerierung in der Arduino-Variante weicht von der
Originalversion ab und ist daher nicht vergleichbar.
Frage was wäre denn die optimale Kombi für einen IRMP universal Scanner?
Der ESP32 hat schon mal mehr flash und mehr SRAM als ein nano328p
Einige Codes beissen sich ja und auch nicht jede IRQ Rate ist optimal.
Ich möchte gerne die Daten einer Fernsteuerung vom Proscenic m8pro
Staubsauger Roboter lernen, müsste dazu noch mal aufbauen.
LG
Joachim B. schrieb:
Ich beantworte mal die Fragen in umgekehrter Reihenfolge:
> Ich möchte gerne die Daten einer Fernsteuerung vom Proscenic m8pro> Staubsauger Roboter lernen, müsste dazu noch mal aufbauen.
Das macht man am besten mit einem AVR, z.B. ATmega328 oder STM32 mit
eingeschaltetem Logging, also IRMP_LOGGING. Suche nach diesem
Schlüsselwort im IRMP-Artikel. IRMP spuckt dann auf der seriellen
Schnittstelle die Signale aus, die man als nächstes dann analysieren
kann. Oder Du schickst mir den Output und ich baue das Protokoll in IRMP
ein.
> Frage was wäre denn die optimale Kombi für einen IRMP universal> Scanner?> Der ESP32 hat schon mal mehr flash und mehr SRAM als ein nano328p
Ein 328er reicht dafür vollkommen aus. Die Arduino-Version von IRMP kann
kein IRMP_LOGGING, sodass der ESP32 sowieso zum "Lernen" nicht verwendet
werden kann.
> Einige Codes beissen sich ja und auch nicht jede IRQ Rate ist optimal.
Ja, da muss man Kompromisse eingehen. Jörg hatte in der Vergangenheit da
einige Tests in der Richtung unternommen und dabei die Zeitkonstanten
für viele Protokolle optimiert, so dass möglichst wenig Konflikte der
Protokolle entstehen. Blättere einfach mal ein paar Beiträge hoch. Diese
überarbeiteten Zeitkonstanten habe ich aus diversen Gründen (u.a. wegen
Wegfall des SVNs auf µc.net) noch nicht übernommen, werde das aber in
den nächsten Tagen nachholen. Wenn Du nicht solange warten kannst: Jörg
hat oben seinen github-Link gepostet.
Frank M. schrieb:> P.S.> Die Versionsnummmerierung in der Arduino-Variante weicht von der> Originalversion ab und ist daher nicht vergleichbar.
ich habe auch mal wieder IRMP rausgekramt um eine FB zu bauen. Eine
ältere Version von 2016 hat auch ad hoc auf einem H743 mit Mbed
funktioniert, jetzt wollte ich mal sehen was es da Neues gibt. In dem
IRMP Artikel sind die Codebeispiele tote Links, da hatte ich in deinem
github Repo nachgesehen. Jetzt sehe ich das die Versionsnummern da sehr
unterschiedlich sind, ist die Arduino Version tatsächlich eine eigene?
Ist etwas verwirrend, der Download der irmp.zip über den Artikel
funktioniert aber noch.
Johannes S. schrieb:> Jetzt sehe ich das die Versionsnummern da sehr> unterschiedlich sind, ist die Arduino Version tatsächlich eine eigene?
Ja, ist so. Ich habe noch keine Zeit dafür gefunden, die Arduino-Version
mit dem Original-IRMP wieder zu vereinigen.
> Ist etwas verwirrend, der Download der irmp.zip über den Artikel> funktioniert aber noch.
Ja, das ist auch der maßgebliche Download für Non-Arduino. Andreas hatte
das SVN-Repository vor einiger Zeit geschloassen. Im wesentlichen sind
in der Arduino-Version lediglich Arduino-spezifische Verbesserungen und
Erweiterungen.
Ich werde das irgendwann wieder vereinheitlichen. Einen
Qualitätsnachteil gibt es mit der Zip-Datei aus dem IRMP-Artikel
jedoch nicht.
Hallo Frank,
bislang nutzte ich die "normale" IRMP. Da ich ein KONNEKTING-Gerät mit
IRMP ausstatten möchte, habe ich die Arduino-Version installiert und die
Anwendung (noch ohne KONNEKTING) programmiert. Bei den Tests fiel mir
auf, dass der Prozessor ab und zu scheinbar hing. Wie ich dann
herausfand, schickt IRMP, nachdem es wegen schlechten Empfangs Müll
dekodiert hatte, nur noch einen Siemens-Datensatz (ich nutze NEC), trotz
ausreichendem Empfang. Das geht so lange weiter, bis der Empfang wieder
zu schlecht war und ein paar Müll-Datensätze ankommen. Dann wird, bei
ausreichendem Empfang, wieder ordnungsgemäß NEC geliefert. Ich habe
Siemens deaktiviert und es kommt weder Müll noch permanent ein falscher
Siemens-Code.
Meine Testplatine arbeitet mit 8MHz bei 3,3V und internem RC-Oszillator.
Vielleicht spielt das ja eine Rolle. Die eigentliche Applikationsplatine
bekommt aber einen Quarz.
Ich wollte das nur zurück melden. Ich kann ohne Siemens-Protokoll leben.
Übrigens, super Arbeit.
Gruß
Frank
Frank K. schrieb:> Wie ich dann> herausfand, schickt IRMP, nachdem es wegen schlechten Empfangs Müll> dekodiert hatte, nur noch einen Siemens-Datensatz (ich nutze NEC), trotz> ausreichendem Empfang. Das geht so lange weiter, bis der Empfang wieder> zu schlecht war und ein paar Müll-Datensätze ankommen. Dann wird, bei> ausreichendem Empfang, wieder ordnungsgemäß NEC geliefert.
Hallo Frank M.,
das Problem habe ich auch!
Kannst Du mal danach schauen?
Gruß
Armin
Frank K. schrieb:> Meine Testplatine arbeitet mit 8MHz bei 3,3V und internem RC-Oszillator.> Vielleicht spielt das ja eine Rolle. Die eigentliche Applikationsplatine> bekommt aber einen Quarz.
Inzwischen ist die Applikation fertig und läuft mit einem 8MHz-Quarz.
Geändert hat das nichts, so dass ich Siemens deaktiviert habe. Dadurch
läuft die Applikation einwandfrei.
Gruß
Frank
Armin J. schrieb:> das Problem habe ich auch!> Kannst Du mal danach schauen?
Ich hab gerade mal die Timing Änderungen von Jörg R. übernommen, jetzt
läufts besser :-)
Ist in der Arduino Version 3.6.0 drin.
Armin J. schrieb:> das Problem habe ich auch!
Ein Scan wäre hilfreich.
Was für einen IR Empfänger verwendest du?
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"
Edit: Wir haben uns überschnitten.
Edit2: Tipp: Wenn du in die Commit-Message ein @j1rie einbaust,
verwandelt es github automatisch in einen Link auf mein Repo.
Ich verwende den TSOP 31238. Allerdings ist nicht das Problem, dass das
IR-Signal nicht oder schlecht erkannt wird. Würde einfach ein schwaches
NEC-Signal als Siemens erkannt, dann passiert nichts und man probiert es
als Anwender noch einmal. Wenn dann aber trotz ausreichendem Signal
weiterhin Siemens dekodiert wird, dann sieht es für den Anwender so aus,
als hätte sich die Applikation aufgehängt. Irgendwie ist IRMP quasi
blockiert, wobei die Blockade durch weitere schwache (NEC-)Signale
wieder aufgehoben wird.
Meine Platine liegt übrigens zum Testen auf dem Fußboden mit Blick nach
oben. Wenn ich mit der Fernbedienung zur Decke "ziele", empfängt er
problemlos (Siemens deaktiviert).
Hallo,
bin begeistert von dem Projekt. Lob für die Umsetzung.
Wird meine "Lieblingsfernbedienung" (Sky) mit eigenwillige Bitanordnung
unterstützt?
Laut dieser Quelle:
https://www.mikrocontroller.net/articles/IRMP#RC6_+_RC6A
kommen:
Daten RC6A Pace (Sky): "1" + 3 Mode-Bits ("110") + 1 Toggle-Bit(UNUSED
"0") + 16 Bit + 1 Toggle(!) + 15 Kommando-Bits
Danke
Rossi
Rossi schrieb:> Wird meine "Lieblingsfernbedienung" (Sky) mit eigenwillige Bitanordnung> unterstützt?
Alle im Artikel aufgeführten Protokolle werden unterstützt - auch RC6
bzw. RC6A. Du musst jedoch in irmpconfig.h das Protokoll erst
aktivieren. Wie das geht, ist im IRMP-Artikel beschrieben.
Jörg R. schrieb:> In https://www.mikrocontroller.net/articles/IRMP#RC6_und_RC6A-Protokoll> unterscheidest du RC6, RC6A und RC6A Pace (Sky).
Das sind lediglich Literaturhinweise zu dem RC6(A)-Protokoll.
Jörg R. schrieb:> Sollten alle drei gehen, wenn RC6 aktiviert ist?
RC6A Pace (Sky) kenne ich nicht. IRMP unterstützt lediglich RC6 und das
"normale" RC6A. Da müsste ich mir erstmal die Unterschiede zu RC6A Pace
anschauen. Außerdem wäre zum Test eine mit IRMP_LOGGING=1 erstellte
Scan-Datei sinnvoll. Diese könnte Rossi erstellen.
Rossi hat mir eine seiner URC-1635 geschickt, anbei ein Scan mit 19 kHz.
Der Unterschied zu RC6A: nur 28 Daten-Bits, kürze Pause am Ende (ca.
1053 µs), falls das letzte Daten-Bit eine 1 ist, verschluckt die Pause
am Ende die Pause der 1.
Pausen am Ende müssten eigentlich irrelevant sein.
Insofern reicht es, wenn man in RC6A ist und nach dem 28. Daten-Bit
nichts mehr kommt, dies als "RC6A Sky Q" (englisch) oder "RC6A Sky+ Pro"
(deutsch) auszugeben.
Jörg R. schrieb:> Insofern reicht es, wenn man in RC6A ist und nach dem 28. Daten-Bit> nichts mehr kommt, dies als "RC6A Sky Q" (englisch) oder "RC6A Sky+ Pro"> (deutsch) auszugeben.
Danke, werde ich mir anschauen. Wenns wirklich so einfach ist, werde ich
es "RC6A28" nennen.
Ich habe RC6A20 und RC6A28 eingebaut
(https://github.com/j1rie/IRMP/commit/b3dd18760c80ed40da17c52321a498f2fdb56b81).
Falls RC6A wird nur über die Endpause das Ende erkannt und über die
Länge welches Protokoll.
Dadurch kann man ganz leicht weitere RC6A-Längen einbauen (habe ich aber
mangels Fernbedienung zum Testen nicht gemacht).
Die Testsuite in IR-Data läuft erfolgreich durch und die RC6A28 Codes
der Fernbedienung werden erkannt.
Frank, ist das gut so oder kann man das noch verbessern?
Jörg R. schrieb:> Ich habe RC6A20 und RC6A28 eingebaut
Prima.
> Die Testsuite in IR-Data läuft erfolgreich durch und die RC6A28 Codes> der Fernbedienung werden erkannt.
Sehr gut!
> Frank, ist das gut so oder kann man das noch verbessern?
Ich wüsste nicht, wie man das verbessern sollte. Genauso wäre ich auch
vorgegangen. Du bist mir aber zuvorgekommen. :-)
Thread beobachten
Seitenaufteilung abschalten