Hallo, ich bin seit einigen Tagen dabei mir einen Decoder für eine meiner rumliegenden Panasonic-Fernbedienungen zu basteln. Leider finde ich im Internet zum Panasonic IR-Protokoll keine einheitlichen Informationen über das aktuelle Protokoll. Hier finde ich einige Beiträge von 2005 die mit "Panasonic-Old" gekennzeichnet sind, diese scheinen mir aber nicht mehr aktuell. (Die Fernbedienung ist bestimmt von 2016). Nun habe ich keine Ahnung welche Zeiteinheiten die jeweiligen Bits haben, oder ob beim Panasonic Protokoll auch mit Inversen der Daten gearbeitet wird wie beim "alten". Mein Aktueller Stand: Start: zwischen 4700 und 5700us "0": 960us "1": >960us Ich bin hier um jedes bisschen Hilfe dankbar. LG Simon
Simon M. schrieb: > Ich bin hier um jedes bisschen Hilfe dankbar. Ich bin mir nicht sicher ob Dir diese Seite weiterhilft, aber einen Versuch ist es wert: http://lirc.sourceforge.net/remotes/ http://lirc.sourceforge.net/remotes/panasonic/
> Leider finde ich im Internet zum Panasonic IR-Protokoll keine > einheitlichen Informationen über das aktuelle Protokoll. Ach immer Internet. Selbst ist der kleine Entwickler. :) Hier mal zwei Kommentarzeilen aus meinem eigenen Empfaenger: //Ab jetzt kommen 48Datenbits die immer aus einem Lowpegel von //423us und einem Highpegel von 423us=0 oder 1269us=1 bestehen Damit empfange ich erfolgreich Befehle von modernen Pansaonic-FBs. Olaf
Simon M. schrieb: > Leider finde ich im Internet zum Panasonic IR-Protokoll keine > einheitlichen Informationen über das aktuelle Protokoll. In dem Datenblatt vom LC7465M (Sanyo) ist das Protokoll ganz gut beschrieben. Für Panasonic ab 2016 passt es. Hier kann es heruntergeladen werden: https://www.digchip.com/datasheets/497676-lc7465m.html Andy
Jörg R. schrieb: > Simon M. schrieb: >> Ich bin hier um jedes bisschen Hilfe dankbar. > > Ich bin mir nicht sicher ob Dir diese Seite weiterhilft, aber einen > Versuch ist es wert: > > http://lirc.sourceforge.net/remotes/ > > http://lirc.sourceforge.net/remotes/panasonic/ Vielen Dank für den Link! Nur noch eine Frage hier zu dem beschriebenen N2QAYB000329. Hier kommt ja zuerst das Start-Signal mit 3437 high und 1641 low Sind dann gleich die Pre-Data Bits dran oder kommt dazwischen noch was anderes? Auch "ptrail" und "gap" kann ich leider nicht ganz einordnen. Andy schrieb: > Simon M. schrieb: >> Leider finde ich im Internet zum Panasonic IR-Protokoll keine >> einheitlichen Informationen über das aktuelle Protokoll. > > In dem Datenblatt vom LC7465M (Sanyo) ist das Protokoll ganz gut > beschrieben. Für Panasonic ab 2016 passt es. > > Hier kann es heruntergeladen werden: > https://www.digchip.com/datasheets/497676-lc7465m.html > > Andy Auch dir Danke für das Datenblatt :) Nur hier kurz die Frage, weil im Datenblatt bei "normal transmission mode" ms stehen für die einzelnen Bits. Stimmt das so? Weil soweit ich das bisher gesehen habe, ist es doch eher so im us Bereich?
> Sind dann gleich die Pre-Data Bits dran oder kommt dazwischen noch was > anderes? Kuck dir doch einfach mal einen Datensatz auf deinem Oszi an. Dann wird das alles viel klarer und die weisst vor allem ob deine FB dem entspricht. > Nur hier kurz die Frage, weil im Datenblatt bei "normal transmission > mode" ms stehen für die einzelnen Bits. Ich hab das ganze ja vor ein paar Jahren erfolgreich programmiert. Hab also den Beweiss geliefert es verstanden zu haben, trotzdem fand ich aber gerade die Timingbeschreibung in dem hier zitierten Datenblatt verwirrend! Sie zu das du irgendwie die 48Bit dekodiert bekommst. Die Zuordnung der Bit laut dem Datenblatt sieht dann wieder sinnvoll aus. Ich haenge dir mal die Notizen an die ich mir damals gemacht habe. Damit kann ich die FB eines TV von 2017 und eines Blurayplayer von 2019 dekodieren. Umgesetzt hab ich das dann mit einem TimerIRQ auf 105.75us. Das funktioniert sehr zuverlaessig. Olaf
Hier noch mein Headerfile. Dann brauchst du nicht selber die ganzen Tasten auszuprobieren. .-) Olaf
Hast Du es mal mit IRMP hier aus dem Forum probiert? Das kann einen Großteil der IR-Protokolle decodieren.
Gerd E. schrieb: > Das kann einen > Großteil der IR-Protokolle decodieren Und falls noch nicht, kann man damit ein Protokoll aufzeichnen und Frank baut es wahrscheinlich wenn man ihn nett bittet.
Olaf schrieb: >> Sind dann gleich die Pre-Data Bits dran oder kommt dazwischen noch was >> anderes? > > Kuck dir doch einfach mal einen Datensatz auf deinem Oszi an. Dann wird > das alles viel klarer und die weisst vor allem ob deine FB dem > entspricht. > >> Nur hier kurz die Frage, weil im Datenblatt bei "normal transmission >> mode" ms stehen für die einzelnen Bits. > > Ich hab das ganze ja vor ein paar Jahren erfolgreich programmiert. Hab > also den Beweiss geliefert es verstanden zu haben, trotzdem fand ich > aber gerade die Timingbeschreibung in dem hier zitierten Datenblatt > verwirrend! Sie zu das du irgendwie die 48Bit dekodiert bekommst. Die > Zuordnung der Bit laut dem Datenblatt sieht dann wieder sinnvoll aus. > > Ich haenge dir mal die Notizen an die ich mir damals gemacht habe. Damit > kann ich die FB eines TV von 2017 und eines Blurayplayer von 2019 > dekodieren. > > Umgesetzt hab ich das dann mit einem TimerIRQ auf 105.75us. Das > funktioniert sehr zuverlaessig. > > Olaf Ahhh ja danke das hilft auf jeden Fall. Mein Problem ist leider, dass sich bei mir bis jetzt noch kein Oszi rentiert hätte :D also fühlt sich das ganze hier an wie geziehltes raten :D Wenn ich die 0 und 1 richtig auslesen kann, hätte ich die gelesenen Daten im EEPROM des Atmega gespeichert, den kann ich mir in ein hex-file schreiben. Meine Aktuelle Vorgehensweise ist, dass ich die jeweils auf die Steigenden Flanken und die Zeit nehme, die seit der letzten vergangen ist. Und nochmal Danke für die Codes.
Gerd E. schrieb: > Hast Du es mal mit IRMP hier aus dem Forum probiert? Das kann einen > Großteil der IR-Protokolle decodieren. Gerd E. schrieb: > Hast Du es mal mit IRMP hier aus dem Forum probiert? Das kann einen > Großteil der IR-Protokolle decodieren. Das hab ich tatsächlich auch schon gesehen, trotzdem danke. Ich wollte aber zunächst mich selbst etwas dran versuchen :) Habe aber auch da nur das Panasonic-Protokoll für Beamer gesehen.
> Mein Problem ist leider, dass sich bei mir bis jetzt noch kein Oszi > rentiert hätte :D also fühlt sich das ganze hier an wie geziehltes raten > :D Ganz ohne Oszi ist das natuerlich schon haerter. Du kannst dir aber ein Sound-Karten-Osziprogramm installieren und den Ausgang von so einem IR-Empfaenger an deine Soundkarte anschliessen. ICh hab es zwar jetzt nicht ausprobiert, aber das sollte eigentlich machbar sein. Die Grundfrequenz eines Bits liegt ja so bei 1khz, das muesste eine Soundkarte noch gut darstellen koennten. Die Traegerfrequenz war IMHO 36 oder 38khz. Fuer erste Tests ist das aber egal. Ein falscher Reciever kostet da nur etwas Reichweite. > Hast Du es mal mit IRMP hier aus dem Forum probiert? Das kann einen > Großteil der IR-Protokolle decodieren. Sowas ist keine gute Loesung weil fremder Source immer schlecht in die eigenen Anwendungen passt. Ausserdem will man ja nicht alle Protokolle dekodieren sondern nur das eine das man gerade braucht. Olaf
Noch was. Ich bin eigentlich nicht der Meinung das man mit einem Logicanalyzer einen Oszi ersetzen kann. Aber in diesem Falle bekommst ja aus dem Reciever bereits einen digitalen Datenstrom. https://www.amazon.de/AZDelivery-⭐⭐⭐⭐⭐-Logic-Analyzer-gratis/dp/B01MUFRHQ2/ Das Teil wird dir dann dein Leben erheblich leichter machen. .-) Olaf
Oh das ist mal ne super Idee!!
Das sollte mir definitiv helfen können und mir jetzt unnötig
verschwendete Zeit sparen.
Nur noch die Frage, da ich mit meinem Atmega328P etwas an den Prescaler
bei der Zeit gebunden bin.
Ich habe den Timer so eingestellt dass er alle 120us einen Interrupt
auslöst und eine Zähler um 1 erhöht.
Wenn nun von meinem TSOP312 ein High-Pegel kommt, schaue ich nach ob nun
5160us (start-bit) oder mehr als 960 und weniger als 1800("1") vergangen
sind.
Ist das ein vertretbarer Ansatz?
Sollte es nicht verständlich beschrieben sein habe ich im Anhang meinen
Code.
Nichtsdestotrotz vielen Dank für den Tipp mit dem Logic Analyzer! :)
> Ist das ein vertretbarer Ansatz?
Ich hab es Timingmaessig nicht nachgerechnet, aber ja so im groben geht
das.
Ich mach das so:
Im TimerIRQ schauen ob am Eingang etwas anderes wie Ruhepegel anliegt,
wenn ja dann zaehler erhoehen. Wenn nein zaehler auf 0, Statemachine auf
Anfang.
Wenn Zaehler erhoeht wurde Statemaschine auf Startbit-Kommando.
Wenn Statemachine auf Startbit-Kommand und Eingang auf Ruhepegel,
pruefen ob Startbit groesser x und kleiner y. ---> Statemachine auf
Datenbit. Wenn aussehalb Wertebereit --->statemachine auf Anfang.
Wenn Statemachine auf Datenbit dann pruefen ob zaehler >x also 1 oder
kleiner also 0 empfangen. Bei allen abweichungen Statemachine immer auf
Anfang!
So syncronisiert sich der Controller immer auf reinkommende Daten auf
und haengt nie fest! Das ist ganz wichtig weil du immer mal auch was
falsches empfaengst.
Olaf
Olaf schrieb: > kaseikyo.h Das kann IRMP auf jeden Fall. Ich habe damit eine Zappe einer Technics-Stereoanlage (auch Matsushita) dekodiert bekommen. Olaf schrieb: > Aber in diesem Falle bekommst ja aus dem Reciever > bereits einen digitalen Datenstrom. Habe zuerst einen ollen TSOP1136 am Steckbrett mit dem Logikanalysator eingelesen. Die Daten konnten dann, mit etwas Kommandozeilen-Magie, in die Kommandozeilenversion von IRMP eingelesen werden. Damit wusste ich, dass es Kasekyo ist und IRMP was damit anfangen kann. Die Konfiguration von IRMP für den μC war dann super-einfach. Alternativ kannst du auch gleich auf dem μC mit IRMP loslegen, dazu eine einfache Applikation, die per UART die Empfangenen Kommandos in Rohdaten ausgibt (Protokoll, Adresse, Kommando, Toggle-Bit). mfg mf
:
Bearbeitet durch User
Simon M. schrieb: > Mein Problem ist leider, dass sich bei mir bis jetzt noch kein Oszi > rentiert hätte :D also fühlt sich das ganze hier an wie geziehltes raten Ein Logikanalysator, der für die Auswertung der Telegramme voll ausreicht, hat sich nach ein paar Minuten rentiert. Das erspart umständlichen Umwege und viel Raterei. https://www.ebay.com/itm/172169652368
Olaf schrieb: > Sowas ist keine gute Loesung weil fremder Source immer schlecht in die > eigenen Anwendungen passt Das so zu verallgemeinern zeigt einfach nur Inkompetenz. Und es zeigt auch dass du IRMP nicht kennst. Bei IRMP trifft das überhaupt nicht zu, es lässt sich sehr gut einbinden weil die Schnittstelle sehr schlank ist. Eben gutes Design. Und funktionieren tut es auch noch ausgesprochen gut. Wenn man es aber gerne selber machen möchte, spricht da ja nichts gegen.
:
Bearbeitet durch User
Simon M. schrieb: > ich bin seit einigen Tagen dabei mir einen Decoder für eine meiner > rumliegenden Panasonic-Fernbedienungen zu basteln. > > Leider finde ich im Internet zum Panasonic IR-Protokoll keine > einheitlichen Informationen... Alles ganz einfach: Schreib dir ein Testprogramm für den µC deiner Wahl, an den du einen üblichen IR-Empfänger sowie ein Display anschließt. Alternativ geht auch USB-Anschluß. Damit testest du dann deine FB durch und schon weißt du es. Im Prinzip brauchst du 2 Stufen im Programm: 1. Messen der Zeiten (Einleitung, ggf. Pause, kleine Bitzeit, große Bitzeit) 2. Darstellen des IR-Telegramms als Zahl (am ehesten zunächst hex) Du kennst doch wohl den alten Spruch: "Hilf dir selbst, so hilft dir..." W.S.
Vielen Dank für die schnelle Hilfe und die Tipps. Ich habs nun dank Logic-Analyser hinbekommen die Codes richtig auszulesen. War dann doch ein dümmerer Fehler als gedacht. Hab das Datenblatt meiner TSOP falsch gelesen und auf die falsche Flanke reagiert^^. Olaf schrieb: > Hier noch mein Headerfile. Dann brauchst du nicht selber die ganzen > Tasten auszuprobieren. .-) > > Olaf Hier waren die Codes der einzelnen Tasten meiner Fernbedienung anders. Trotzdem danke :)
> Hier waren die Codes der einzelnen Tasten meiner Fernbedienung anders. > Trotzdem danke :) Interessant. Wie denn anders? Alle Bits invertiert? Oder um 1Bit geschiftet? Oder nur die Geraete-ID anders? Ich hab hier naemlich drei FBs die ich sinnvoll dekodieren konnte und zwei der Geräte sind definitiv relativ neu. Olaf
Olaf schrieb: > Ganz ohne Oszi ist das natuerlich schon haerter. Man kann IRMP als "Logikanalysator" nutzen. Mit gesetzter Konstante IRMP_LOGGING wird das Protokoll "raw" mit 0 und 1 auf dem UART ausgegeben. >> Hast Du es mal mit IRMP hier aus dem Forum probiert? Das kann einen >> Großteil der IR-Protokolle decodieren. > > Sowas ist keine gute Loesung weil fremder Source immer schlecht in die > eigenen Anwendungen passt. Naja, da sprechen aber hunderte von Anwendungen draussen dagegen. IRMP hat eine API, die man lediglich aufrufen muss. Zurück bekommt Protokoll, Adresse und Code. Einfacher gehts kaum. > Ausserdem will man ja nicht alle Protokolle > dekodieren sondern nur das eine das man gerade braucht. Beim Übersetzen von IRMP kann man bestimmen, wieviele und welche Protokolle dekodiert werden sollen. Das darf auch nur eines sein - nämlich dasjenige, das man braucht. Dann wird der Source-Code per Preprocessor auf das Notwendige eingedampft. Übrig bleibt der Minimal-Code, denn man für das gewünschte Protokoll braucht. @TO: Das Kaseikyo-Protokoll wird hier beschrieben: https://www.mikrocontroller.net/articles/IRMP#KASEIKYO
Olaf schrieb: >> Hier waren die Codes der einzelnen Tasten meiner Fernbedienung anders. >> Trotzdem danke :) > > Interessant. Wie denn anders? Alle Bits invertiert? Oder um 1Bit > geschiftet? Oder nur die Geraete-ID anders? > > Ich hab hier naemlich drei FBs die ich sinnvoll dekodieren konnte und > zwei der Geräte sind definitiv relativ neu. > > Olaf Also meine Fernbedienung gibt mir als Adresse 0x4004 aus, was noch übereinstimmt wenn ich mich nicht vertue. Taste 1: 0x01000809 Taste 2: 0x01008889
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.