Gibt es einen Grund, warum der struct Name "IRMP_PACKED_STRUCT" in der 32 bit Version fehlt (irmpsystem.h Zeile 227ff.)? Und wo ist der Unterschied zwischen beiden?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
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 | |
2 | |
3 | |
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 | |
2 | |
3 | |
4 | |
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: > Die Links sind für mich leer Sorry, mein Fehler, ich hatte sie zu stark gekürzt. Ich habe das jetzt im Beitrag korrigiert. Hier nochmal: IRMP: IRMP unter Linux und Windows IRSND: IRSND unter Linux und Windows
Armin J. schrieb: > gestrichelt ->gestreichelt
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.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
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:
1 | |
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 | |
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 | |
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 mit1 | |
analysiert, dann das Protokoll implementiert, mit
1 | |
debuggt und letztendlich mit
1 | |
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 | |
Der an 560 nächstgelegene ganzzahlige Wert als Multiplikator ist 11:
1 | |
Ebenso kann man auch den Fehler für 15kHz berechnen:
1 | |
Der an 560 nächstgelegene ganzzahlige Wert als Multiplikator ist 9:
1 | |
Obwohl eigentlich
1 | |
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?
Hier die Tabelle mit einem STM32 BluePill als Empfänger, der Sender ist immer noch ein AVR. Es gibt merkwürdigerweise einige Unterschiede.
Das mit den Scans geht nicht. Die ANALYZE_PRINTF5 etc schreiben auf stdout und den gibts ohne Runtime nicht.
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.
Jörg R. schrieb: > Dabei waren alle mit 20kHz möglichen Protokolle an. > So wie bei Armin geht A1TVBOX und MITSU_HEAVY nicht, SIEMENS wird als > A1TVBOX erkannt, SAMSUNG48 wird verdoppelt/wiederholt erkannt, bei DENON > und FDC keine Wiederholung. > Im Gegensatz zu Armin geht TELEFUNKEN, aber FDC nicht. > BANG_OLUFSEN, Lego gehen auch nicht. > RECS80 und RECS80EX gehen selten. Danke, werde ich mir bei Gelegenheit anschauen. > Was ganz anderes: Es gibt von mir auch einen Tastatur-IR-Empfänger: > https://www.vdr-portal.de/forum/index.php?thread/132289-irmp-auf-stm32-ein-usb-hid-keyboard-ir-empf%C3%A4nger-einschalter-mit-wakeup-timer/ > https://github.com/j1rie/IRMP_STM32_KBD > Das wäre vielleicht was für die Link-Sammlung. Sicher, nehme ich auf :) Gruß und Dank, Frank
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.
Nachtrag zu den nicht-exotischen Protokollen: Bei SIRCS, DENON und IR60 geht die Wiederholung nicht.
Meine Ergebnisse der nicht-exotischen Protokolle:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
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 nicht Jörg R. schrieb: > Ich habe meine Universal Fernbedienung auf Siemens gestellt. Erkannt > wird mal Siemens, mal Grundig, mal Ruwido. Für Siemens hatte ich mal vor langer Zeit eine testweise Änderung gemacht. Warum, weiß ich nicht mehr, ist zu lange her. Jedenfalls hatte damals diese Änderung den Weg ins Release gefunden - wohl eher versehentlich. Das war für 15kHz auch kein Problem, erst bei 20kHz machen sich dann die Unterschiede bemerkbar. Am besten macht man meine Änderung in *irmpprotocols.h* wieder rückgängig. Alt:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Neu:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Also einfach aus "if 0" ein "if 1" machen. Ich werde das so fürs nächste Release ebenso anpassen. Klaus, kannst Du das mal mit Deiner Siemens-FB testen?
Frank M. schrieb: > Klaus, kannst Du das mal mit Deiner Siemens-FB testen? ...ich habe nur B&O MCP5500, aber der ist gerade eingemottet. Klaus.
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?
Gast
#6490730
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.
Angehängte Dateien:
-
outside.jpg
(110 KB)
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).
Und noch ein Scan von Sony per IRSND, auch bei 15kHz verschwindet die Adresse. Denon per IRSND geht mit 15kHz (mit 20kHz ging es nur manchmal).
Noch ein Scan mit allen Protokollen von 1 bis 49.
Super, vielen Dank! Damit habe ich nun genügend Hausaufgaben zu tun ;-)
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
Unterstützt IRMP auch 8051er Derivate (SDCC compiler)? :)
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.
Hmmmm ... Für einen 8051er (128Byte RAM):
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
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:
1 | |
Dieser wird von irmp-20kHz auch wieder einwandfrei erkannt.
Mein Scan deines Codes (gesendet 2000d0001000):
1 | |
Da fehlt Einiges. Aber warum?
Ich wollte Mitsubishi-Heavy testen: ./irsnd-20kHz 49 0x00d0 0x0010 > 49 ./irmp-20kHz < 49 Das wird nicht erkannt.
IRSND sendet FDC nur, wenn die flags 0x00 sind. Mit 0x01 geht es nicht. Soll das so sein?
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.
Ich hatte zwischen den irsnd_send_data() ein delay von 300ms drin und ich hatte mit irsnd_send_data(irmp_data_p, 1) gesendet.
Jörg R. schrieb: > IRSND sendet FDC nur, wenn die flags 0x00 sind. Mit 0x01 geht es > nicht. IRSND sendet nicht oder IRMP empfängt/dekodiert nicht? Mein Test unter Linux:
1 | |
2 | |
3 | |
4 | |
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 | |
2 | |
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:
1 | |
Die Pulse (Nullen) dürfen nur 3-10 Stellen lang sein. Die elfte Gruppe von Nullen ist aber 16 Stellen lang. Dadurch wird FDC verworfen und der Rest dann fälschlicherweise als A1TVBOX erkannt. Kannst Du diese Fehlstelle mit IRSND reproduzieren? Ich kann es nicht. Du kannst das auch gut sehen, wenn Du irmp-20KHz mit Option -v aufrufst:
1 | |
Output ist dann:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
> 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.
Jörg R. schrieb: > Ich habe leider keines. Bau Dir eines https://github.com/ArminJo/Arduino-BlueDisplay/tree/master/examples/SimpleTouchScreenDSO.
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.
Statt zu testen, was welcher TSOP raus filtert, habe ich lieber mit direkter Verbindung (also ohne Modulation) getestet:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
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?
Jörg R. schrieb: > Bang & Olufsen: > irsnd-20kHz 14 0 1 > 0e > irmp-20kHz < 0e > Das wird nicht erkannt. Bei mir schon:
1 | |
2 | |
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 | |
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 | |
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.
Mal so nebenbei - wieso unterstützt IRMP keine externen Interrupts als alternative zur Sampling-Methode? 🙈
Mampf F. schrieb: > Mal so nebenbei - wieso unterstützt IRMP keine externen Interrupts als > alternative zur Sampling-Methode? 🙈 Schon mal in die Arduino Version geschaut? https://github.com/ukw100/IRMP/tree/master/examples/Interrupt
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 | |
2 | |
Das automatische Abschalten ist auch noch teilweise abhängig von der Abtastfrequenz. Gib mal unter Linux
1 | |
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 | |
Diesen Test mach ich hier regelmäßig nach jeder Änderung im IRMP, um sicherzustellen, dass alle Protokolle weiterhin erkannt werden.
Ich habe noch mal neu gebaut und es sieht jetzt ziemlich gut aus:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
Die vielen Protokolle gehen gut zusammen. (Abgesehen von ein paar Schönheitsfehlern.)
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.
Mitsubishi-Heavy steht laut
1 | |
vermutlich in Konflikt mit Kaseikyo.
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
Hi Frank, mir fällt gerade auf, dass ein Protokoll wohl Kasiekyo und nicht Kaseikyo heisst.
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 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
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ß
Angehängte Dateien:
-
Lego-Fernbedienung.jpg
(55 KB)
-
NewFile2.png
(15 KB)
-
NewFile5.png
(15 KB)
-
NewFile4.png
(15 KB)
-
NewFile3.png
(15 KB)
Datei vergesen, war klar.
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
Falls da ein TSOP im Spiel war, hat er möglicherweise die kurzen Pulse raus gefiltert (wie bei mir weiter oben).
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ß
Die Datei sollte nicht nochmals erscheinen...
Gast
#6541557
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 | |
??? 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
Mit einem TSOP 34338 (der nichts herausfiltern sollte) gibt es ein paar neue Fehler:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
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 :)
Zum Vergleich Lego (nur der Anfang) gesendet mit irsnd (obere Zeile) und nach dem TSOP gescannt (untere zwei Zeilen):
1 | |
2 | |
3 | |
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:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
Das heisst:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
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).
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
Gast
#6557214
Hi Frank, Thank you for your reply, I have benefited a lot. Derek
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.
Angehängte Dateien:
-
Lego.jpg
(200 KB)
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):
1 | |
2 | |
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
Jörg R. schrieb: > * Denon hat selten keine Wiederholung Bei mir (AVR) tuts das einwandfrei! Du weisst schon, dass Denon 1*Autorepeat hat?
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:
1 | |
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.
Bei Denon ist (bei mir) der Wurm drin.
1 | |
1 | |
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 A1TV werden mit folgender Änderung die Adressen und Kommandos richtig erkannt. Vorher wurde manchmal eine lange Pause als kurze Pause erkannt.
1 | |
(Toleranz von 30% auf 20% gesenkt.)
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.
Mit dem angehängtem Patch gibt es bei 200 Mal die 33 Protokolle senden keine Fehler mehr :)
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.
Angehängte Dateien:
-
1.Frame.jpg
(360 KB)
-
2.Frame.jpg
(360 KB)
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.
applaus Klaus.
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.
Ich habe meinen Patch noch etwas erweitert und in mein github gelegt: https://github.com/j1rie/IRMP/commits/master
Gast
#6604513
Gehe ich recht in der Annahme, dass ich mit IRSND gesendete Kommandos mit IRMP testen kann indem ich die ISR so schreibe?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Gast
#6604613
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
Gast
#6642430
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.
Gast
#6642824
GCC meckert, dass nec_param in irmp.c unbenutzt ist wenn (nur) die folgenden Protokolle aktiviert sind:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
Gast
#6642838
Wo ist der letzte Stand zu finden, jetzt wo es das SVN repo nicht mehr gibt?
In Github, oben müsste der Link irgendwo sein.
Gast
#6642956
D.h. den letzten Stand gibt es derzeit nur für Arduino. Schade.
Nein, im Artikel ist auch ein Download https://www.mikrocontroller.net/articles/IRMP#Download
Bis es von Frank was Neues gibt, empfehle ich https://github.com/j1rie/IRMP, da sind etliche Verbesserungen eingebaut.
Gast
#6643393
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?
Micha schrieb: > Das weiß ich Entschuldige bitte dass ich mir die Mühe machte im Artikel nach einem Download zu schauen.
Gast
#6643619
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: > Wenn Du nicht solange warten kannst kein Problem, kann warten!
Gast
#6928831
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.
Gast
#6929119
ok, Danke.
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
IRMP kann jetzt auch opencm3 (https://github.com/j1rie/IRMP).
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).
Gast
#7109947
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.
Rossi benutzt meine Firmware, und da ist RC6 aktiviert. https://github.com/j1rie/IRMP_STM32_KBD/blob/master/STM32F103/patches/irmp.patch#L34 und https://www.vdr-portal.de/forum/index.php?thread/123572-irmp-auf-stm32-ein-usb-ir-empf%C3%A4nger-sender-einschalter-mit-wakeup-timer/&postID=1351559#post1351559 RC6 geht auch, aber seine Fernbedienung mit Sky-Protokoll geht nicht. In https://www.mikrocontroller.net/articles/IRMP#RC6_und_RC6A-Protokoll unterscheidest du RC6, RC6A und RC6A Pace (Sky). Sollten alle drei gehen, wenn RC6 aktiviert ist? Falls ja, bleibt noch die Frage warum seine Fernbedienung mit Sky-Protokoll nicht erkannt wird.
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. :-)
Hallo Frank und alle anderen!
wie ist der Stand der Dinge? Welches Git-Repo ist das "richtige" Repo? Kommt ein IRMP2? Oder gibt es einen Merge zwischen Jörgs und Armins Repo? Wer ist überhaupt noch aktiv dabei?
Viele Grüße,
Sven
Ich hätte mal eine kurze Frage:
Ich habe einen Fernseher von LG mit einer Fernbedienung AKB73655802, letztere geht jetzt so ihrem Ende entgegen, aufmachen und reinigen hilft nur noch für 1 Woche oder so.
Jetzt möchte ich die mit Hilfe von IRMP nachbauen, anbei mal die Sequenz der Power-Taste mit Pulseview, das sieht mir nach NEC-Protokoll aus: konstante Pulslänge, variable Pause, die Bitlängen passen auch.
Seht Ihr das auch so?
Kaufen ginge natürlich auch, macht aber weniger Spass.
Angehängte Dateien:
-
fernbedieung.png
(96 KB)
Seht Ihr das auch so?
Auf den ersten Blick passt NEC. Mit IRMP köntest Du alle Tasten aufnehmen, mit IRSND dann diese auf einem neuen µC per Tastendruck wieder "abspielen".
Viel Spaß!
Noch ne Frage: läuft das aktuelle IRMP/IRSND auch noch auf PIC12F1840, das ist eher meine Welt als die Atmels.
Vorab schon mal danke für diese tolle Arbeit!
Kaufen ginge natürlich auch, macht aber weniger Spass.
ich will Dir ja nicht den Spass verderben aber die "L336 learning remote" https://www.ebay.de/sch/i.html?_nkw=L336+learning+remote&_sacat=0&_from=R40&_trksid=p4432023.m570.l1313
gibt es vom Chinesen ab 5,50 €. Ich habe 2 Stück davon uA auch als Reserve für meinen LG-TV.
...kann aber keine 455kHz für den Beomaster 🤪
Klaus.
Noch ne Frage: läuft das aktuelle IRMP/IRSND auch noch auf PIC12F1840,
Laut dem Artikel IRMP (1. Kapitel: Unterstützte µCs) wird dieser µC auch unterstützt. Die Portierung auf PIC ist aber nicht von mir, deshalb kann ich da nicht mehr dazu sagen.
Hallo,
Könnte jemand helfen dieses alte exotische Protokoll hinzuzufügen: https://web.archive.org/web/20120708002907/http://tech.groups.yahoo.com/group/chameleon_64/messages/627?threaded=1&m=e&var=1&tidx=1
Ich habe kein passendes im irmp gefunden.
Hier noch ein Link mit Infos https://github.com/Korinel/Amiga-CDTV-IR-Keyboard
Hier noch ein Link mit Infos https://github.com/Korinel/Amiga-CDTV-IR-Keyboard
Da steht: "The CDTV wireless keyboard uses an IR protocol related to an NEC IR standard".
Wenn ich mir das Start-Bit anschaue, passt NEC mit 9000/4500 µsec perfekt.
Also hast Du es mit NEC probiert? Deaktiviere beim Test alle anderen IR-Protokolle.
Wenn es nicht klappt, dann kann die Tastatur leicht abweichende Werte haben. Die GitHub-Dokumentation gibt da relativ breite Bereiche für die Timings an. In diesem Fall hilft nur das Kapitel https://www.mikrocontroller.net/articles/IRMP#Scannen_von_unbekannten_IR-Protokollen . Die Scans kannst Du dann hier hochladen. Ich sage Dir dann, was Du anpassen musst.
:
Bearbeitet durch Moderator
Hallo,
NEC passt leider nicht. Da muss ich mit erstmal meine Scan Firmware zusammenbauen ;-) Wenn ich die Scans habe, komme ich auf dein Angebot zurück
Für NEC brauchts noch die Geräteadresse, z.B. sowas:
1 |
|
2 |
|
3 |
|
:
Bearbeitet durch User
Anbei einmal die gesamte FB durchprobiert. IRQ 10500 Hab noch ein Fehler in loggingext gefunden. Werde ich auch noch posten.
@ukw Konntest du was mit den IR Debug anfangen oder waren sie nicht vollständig ?
Anbei einmal die gesamte FB durchprobiert. IRQ 10500
sicher?
ich nutze minimal IRQ 15000 reicht dann auch für IR Empfang
einfach in zählen und reicht für delays 10ms Tastenauswertung
die allermeisten Protokolle haben ja 38kHz.
aber 36kHz liegen mittiger für mehr Erkennung, der TSOP muß natürlich passend ausgewählt werden. Ich nehme gerne den TSOP 31236 weil er mit 3,3V (ESP) und 5V zurecht kommt
:
Bearbeitet durch User
Ich nutze IRQ 10500 ohne Probleme seit Jahren mit zig FB mit einem 36kHz TSOP. Bisher nie ein Problem.
@ukw Konntest du was mit den IR Debug anfangen oder waren sie nicht vollständig ?
Ich hatte Deine Scans mal durch den IRMP gejagt und konnte kein adäquates Protokoll finden. Das scheint was gänzlich anderes zu sein. Leider haben mich auch die 10500 Interrupts pro Sekunde verwirrt. Das sah für mich erstmal nach einem Zahlendreher aus: 10500 vs. 15000, was IRMP-Standard ist. Also sind es tatsächlich 10500?
Ich könnte das als neues Protokoll in IRMP einbauen, wenn Du möchtest. Dazu komme ich aber frühestens in ca. 2 Wochen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.