Hallo Es gibt wohl 5 verschiedene Pausen die jeweils von einem Puls von ca 156µ Sec getrennt werden. Die ca 61 ms Pause trennt wohl die Frames. Das letzte Frame ist merkwürdeg. Die Zeiten 1 - 4 bilden vermutlich Adresse und Tastencode.
Angehängte Dateien:
-
IR.jpg
89 KB
Beitrag #6515084 wurde vom Autor gelöscht.
Ja klar, seh ich sofort. Wer kann mir sagen welches Öl in den Motor meines Autos eingefüllt wurde?
Angehängte Dateien:
-
Nec.jpg
51 KB
Hallo au weia Ich hatte, die Hoffnung dass jemand der sich mit IR Codes auseinandergesetzt hat, evtl so was schon mal gesehen hat. Ich habe mal einen Nec Code eingelesen (Im Anhang) . Ich denke, dass der ein oder andere schnell sieht, dass es sich um einen Nec Code handelt.
Ist wirklich doof dargestellt. Wir sind ja schon nerds unter sich. Aber da steig ich auch erst nach mehrmals iterieren hinter, wie das zu interpretieren ist. Hätt man ja irgendwie flanken darstellen können. meinetwegen in ASCII, wie früher
Hallo Axel R. Die Darstellung ist zwar anders als auf einem Speicheroszi, hat aber riesen Vorteile.(linke Zahl entspricht der Pause, rechte Zahl dem Puls). Das Programm habe ich geschrieben um Treiber für IR Protokolle zu programieren. Ich habe einen Tn2313 mit IR Sensor an der seriellen Schnittstelle und muss einfach mit irgendeiner Fernbedienung senden. Das Ergebnis ist zum Einen das was Du auf dem Bild siehst, zum Zweiten erhalte ich eine asm Datei mit den Zeiten zwischen den Flanken und den Vergleichswerten ( + Toleranz), die ermittelt wurden. Damit lässt sich das Ganze wunderbar programieren und debugen.
also ich kapier's nicht, kannst Du nicht eine übliche LA-Ausgabe anzeigen
Den einzigen Code, den ich kenne, der mehrere verschiedene Pausenzeiten verwendet, ist der RCMM. Da gibt es 4 Pausen die jeweils 00, 01, 10 und 11 entsprechen. Deine 0-Zeit passt auch etwa dazu, aber die 1 bis 4 sind bei dir viel zu lang. Außerdem hat der keine 14 wie deiner sondern 12 bzw. 24 Bits. Aber so etwas ähnliches wird es sein.
Günter S. schrieb: > Damit lässt sich das Ganze wunderbar programieren und debugen. Du bist ein genialer Entwickler! Deswegen hast du es auch nicht nötig deine Protokoll-Aufzeichnungen zu erklären, denn alles was du weisst wissen die Leute hier um dich herum auch da sie ja alle so genial und hellseherisch sind. Dies zu deinem Eröffnungs-Beitrag. Erst die Salamischeibe zwei lässt noch mehr Licht in die Geschichte kommen, kaum auszuhalten, diese Helligkeit.
Auf Rätselspiele "Raten nach Zahlen" hab ich irgendwie keine Lust.
Also im oberen Teil sind die Zeiten zwichen den Flanken farblich mit einer Nummer (Token) dargestellt. Der Tiny ist mit 8 MHZ getaktet, der Counter zählt mit Vorteiler /64. Die Zahlen, die Du unter Zähler siehst sind die Zählerstände bei einem Flanken Wechsel. Im unteren Teil siehst Du die Token (bunt dargestellt). Die weißen Zahlen, zeigen an, wie viele Flankenwechsel seit dem Timeout stattgefunden haben. Also, beim zweiten Bild (Nec) besteht der Haeder aus einem Puls von ~280 ms, eine pause von ~4,4 ms danach kommt ein Puls von ~572 µs . eine 0 entspricht bei Nec einer Pause von 572 µS und einem Puls von 572 µS (entspricht in meiner Darstellung den 2 gelben Nullen. Eine 1 hat eine Pause von 1,6 mS und einem Puls von 572 µS. (asso gelbe "0" , rosa "1") Die allereste Zahl sagt im Grunde nichts aus. Sie representiert die Pause die vor der Übertragung stattgefunden hat.
Sorry, aber sowas hier statt Oszillogramm / Timingdiagramm ist so ungefähr das Gleiche, als wenn jemand, der Hilfe zu einer Schaltung sucht, diese wortreich in Prosatext beschreibt, anstatt einfach einen Schaltplan anzuhängen.
:
Bearbeitet durch User
Günter S. schrieb: > Also Aha ... Salamischeibe 3! Günter S. schrieb: > Sie representiert .... --> repräsentiert
Hast du das schon mal in die full-featured IRMP-Kommamdozeilenapplikation rein geschoben? Kannst du eine in festem Raster abgetastete Signaldarstellung posten? (dann wäre vielleicht auch jemand anders in der Lage das zu probieren) mfg mf
Günter S. schrieb: > Danke von meiner Seite. Immer gerne auch die Rächdschraip-Understüdzunk. Günter S. schrieb: > Sorry ich gibs auf. ---> ich gebe es auf oder: ---> ich geb's auf
Leider hast Du Deinen Frame nicht in Textform hier reingeschrieben, sonst hätte ich das mal eben in den IRMP geschickt. Aber Fotos abtippen mache ich nicht ;-) Hier kannst Du selber schauen: IRMP: Die IR-Protokolle im Detail
Ehrlich gesagt: Nicht so doll. Hat großes Verbesserungspotential! Woraus so ein Code besteht: - Initial-Sequenz (falls vorhanden) - Pulsdauer-Modulation, oder - Pulspausen-Modulation, oder - Puls-Positions-Modulation, - Code-Länge, ... kann (m)eine primitive Software (Tiny84) von allein herauspfriemeln. Auch die charakteristischen Zeiten im Burst und beim Code. Dann gibt's noch Tricks mit abwechselnder Invertierung von Adress- und/oder Befehlscode, oder einem Toggle-Bit. Das stellt deine Methode auch nicht dar. Hat/hätte man diese Daten, kann man schnell den Code als altbekannt, oder neu einordnen, ohne umständlich das Zahlenwirrwarr zu durchforsten.
Kleiner Tipp: Die üblichen IR-RC-Empfänger liefern bei passender Burstfrequenz den Code mit halbwegs ausreichender zeitlicher Genauigkeit für die gerätespezifische Decodierung. Will man den IR-Code erfassen, um ihn "nachzuempfinden", ist das nicht genau genug. Wahrscheinlich ist das auch der Grund für deine 5 verschiedenen Pausen... Hab keine Lust, das in dem Zahlenwirrwarr rauszupfriemeln. - Wenn gewünscht, schick mal die Zahlengruppen im TXT-Format. Mit IR-Empfangsdiode (aus der Nähe bestrahlt), Comparator und µC mit angemessener Auswerte-Software sollte es schon eher was werden. Bei mir klappt es jedenfalls.
Hallo Jacko Ich habe es eigentlich schon aufgegeben, aber nachdem Du mir netterweise so eine ausführliche Antwort geschrieben hast, habe ich mal eine meiner IR Routinen im Anhang. Die IR_View.exe ist mit dabei. Um die zu benutzen, bedarf es eines Tiny2023 mit 8 MHZ Quarz und dem IR Empfänger an INT0 (mit Pullup ca 10 kOhm). Über TX (38400 Boud) werden die Zeitaten ausgegeben. Die Firmware ist im Ordner IR_2023. Kannst aber auch ohne Hardware im AVR Studio simulieren. Ich weiss natürlich nicht, ob Du asm programmierst?. Direkt vor den IRQs schalte ich mit .equ debug: =0 die simulation ein oder aus. Ich möchte Dir damit nur beweisen, dass weder in der Hardware noch in der Software Fehler sind. Gruß Günter
Hallo, was sagt eigentlich LIRC / WinLIRC dazu? Erkennt das den Code? Gruß aus Berlin Michael
Hallo Michael Lirc habe ich versucht, bringt aber kein sinnvolles Ergebnis. Mit den gängigen Protokollen RC5 Sony Nek ... klappt das ja perfekt. Ich interressiere mich übrigens deswegen für dieses Protokoll, weil es genial und sehr Stromsparen ist. Gruß Günter
Ich habe nicht behauptet, dass Fehler in deinem Programm drin sind. Aber das Konzept und die Auswertung sind nicht ideal. Wie gesagt: Mit den Zeiten im Textformat könnte ich mal schauen - aber das rar zu entpacken und im Code zu wühlen, mag ich nicht. In allen mir bekannten (!) IR-RC-Codes sind maximal je 3 verschiedene Zeiten für Pulsdauer und Pausendauer zu messen. Das wären 6, meist ist aber bei 4 Schluss. Die Zeitverhältnisse sind auch gut auseinanderzuhalten: 2:3, also nur 50% Unterschied ist schon selten. Logisch: Das soll auch mit einem Keramik-Resonator als Zeitreferenz, oder noch billiger zu machen sein... Beispiel NEC-Code, 38 kHz, Pausen-Dauer-Modulation Startsequenz: 9,0 ms On 4,5 ms Off Bit = 0: 0,6 ms On 0,6 ms Off Bit = 1: 0,6 ms On 1,6 ms Off ... das sind 4 (leicht!) zu unterscheidende Zeiten, wobei die 0,6 ms z.B. 22 Zyklen von 38 kHz sind... Mit IR-Empfangsdiode und Komparator erfasst man schon die die Burstfrequenz (z.B. 38 kHz), wobei dann die Puls- und Pausenzeiten ganzzahlige Vielfache von (in diesem Falle) 1/38 kHz = 26,3 µs sein müssen. Das habe ich in asm auf einem Tiny 84 gemacht, da geht noch eine LCD-Anzeige. Nur mit IR-Schnittstelle und RS232- Ausgabe (SW-RS232) sollte das auch ein Tiny 85 erledigen. ver
Hallo Jacko Das Besondere an dem Protokol ist, dass es eine Startsequenz mit 188 µs on hat. danach werden wohl mit jedem off/on Paar zwei Bit übertragen : 1,3 ms off 188 µs on ergibt z.B. 00 2,8 ms off 188 µs on ergibt z.B. 01 4,4 ms off 188 µs on ergibt z.B. 10 5,9 ms off 188 µs on ergibt z.B. 11 nach 14 off/on Paaren hätte man dann 28 Bit nach einer Pause von ~60 ms und der Startsequenz mit 188 µs geht das Ganze von vorne los (bei gehaltener Taste) Zum Abschluss wird noch 188 µs off 188 µs on übertragen. somit gibt es nur sehr kurze on Phasen, was sich natürlich gut auf den Stromverbrauch auswirkt. Und die Übertragungszeit ist relativ kurz. Auf diese Art die Daten zu übertragen war mir neu, und ich finde sie interresant. Gruß Günter
Ja, der Energiespar-Ansatz ist interessant: Pausenmodulation mit 4 Zuständen, also 2 Bit pro kurzem (stromverbrauchenden) ON-Burst von 188 µs. Bisher erschien mir DENONs Pausenmodulation mit 350 µs ON-Burst pro Bit (+ 1 Trennbit / pro Code) am sparsamsten. Also 101 µs ON-Signal pro Bit DENON: 375 µs ON-Signal pro Bit Sony: > 1 ms ON-Signal pro Bit Da heutzutage alles über eine stromverschwendende Handy-App gesteuert werden muss, wundert es mich, dass da noch jemand Gehirnschmalz drauf verschwendet, wo sogar mein Sony-TV mit relativ verschwenderischer Pulsdauermodulation auf eine Lebenszeit von über 3 Jahren für die AAA-Zellen kommt. Allerdings bist du weiterhin großer Geheimniskrämer: - Wie sieht die zeitliche Abfolge in nachvollziehbarer Text-Form aus. - Was für ein Gerät wird damit gesteuert? - Ansonsten hast du es dir doch selbst beantwortet...
Hallo Jacko Ich bin dabei eine möglichst kurze asm Routine zu schreiben, die fast alle IR Protokolle empfängt. Vor einiger Zeit habe ich die IR_View. exe geschrieben um mir beim anpassen der Protokolle die Arbeit zu erleichtern. Die Idee, die dahinter steckt, ist es, eine einfache Möglichkeit zu schaffen, absolut realistisch den Ablauf im AVR Studio zu simulieren: Ein Attiny 2023 sendet die on und off Zeiten über die RS232 an den PC. (Dieses Programm findest Du im Ordner IR_2023.) Die Zeiten werden in die Datei IR_Dump.asm geschrieben (in den Ordner in dem sich die IR_View exe befindet.) Diese Datei binde ich für die Simulation mit ein. In dieser Datei befindet sich auch die Tabelle der Vergleichswerte. Beim RC5 z.B. sind es 3 Zeiten: 27, 54 und 2779 Die kommen zu Stande indem ich den alten Zählerstand vom neuen subtrahiere.(der Zähler zählt mit 8 MHZ und Vorteiler /256) Für die Vergleichswerte wird die Toleranz dazu addiert. (bei meinem Sensor reicht 6 aus). Das Ergebnis vergleiche ich so lange mit den Vergleichswerten bis es kleiner ist. dabei erhöhe ich nach jedem Vergleich ein Register (bei mir r20). Dieser Wert bildet das Token: Ich fasse das off Token und das on Token nach jedem 2 Flankenwechsel zusammen (high Nibble off, Kow Nibble on) bei mir in R18. In meiner Text Darstellung ist das jeweils ein Zahlenpaar. Um die Haeder, Repeat, oder Kontrollbits ins Register 18 zu bringen muß ich ein Token auslassen. Das passiert immer wenn das Token größer ist als das größte, welches die Bit Zeiten representiert. Z.B. 0 und 1 bilden eine 1, 0 und 0 die 0, dann wird ab einer 2 ein Token ausgelassen. Ab dieser Stelle (bei mir das Lable Auswerten) kann ich mit ein paar wenigen Befehlen die Adress und Daten Bits und die Repeats von fast jedem Protokoll erzeugen. Ich habe Dir mal das vereinfachte Programm angefügt. Bitte schau es Dir mal im Simulator an. Gruß Günter
Sich in fremden asm-Code einzulesen ist anstrengend.
Einmal erzählst du, dass du beliebige IR-Codes mit dem µC erfassen
willst, um die ON-OFF-Zeiten (nach Übermittlung per RS232) dann
mit einem PC auszuwerten.
Dann sind im .asm schon diverse Protokolltypen mit .EQU festgelegt.
Genau da verging mir die Lust weiterzulesen:
--------------------------------------------
Was willst du?
Willst du Codes allgemein erfassen, oder willst du einen
IR-Empfänger für besimmte Protokolle bauen?
Wenn du selbst kein Konzept hast, wer sollte dann "kein Konzept"
"Korrektur"-Lesen.
Meine Erfassung von IR-Codes habe ich so ausgelegt, dass es nur
wenige allgemeingültige Vorgaben gibt.
Eine willkürliche Maßgabe ist der Erfassungstakt: 6,4 MHz / 256
= 25 kHz, also 40 µs. In einem Byte (!) lassen sich dann Zeiten
bis 10,2 ms mit 40 µs Auflösung festhalten.
Ende - Anfang = Dauer.
Zur Erfassung ist aber ein 16-Bit-Zähler von Vorteil.
Für aufeinanderfolgende Code-Sequenzen lassen sich dann Anfang
und Ende festhalten, somit auch der Abstand. (> 10 ms: 16-Bit!)
Abwandlungen zwischen 2 Sequenzen (DENON) sind auch manchmal
wichtig...
Nächster Gedankenschritt: 10 ms OFF-Potential sind eine PAUSE.
1) Wartezustand
Im Wartezustand für die Erfassung bedeutet PAUSE, dass ich
den Zeiger und alle Hilfsvariablen für das Erfassungs-Array
auf Null / Anfang setze.
2) Erfassung
Kommt der IR-Code, werden nacheinander ON-Dauer (gerade
Speicherstelle) und OFF-Dauer (ungerade Speicherstelle) im
Erfassungs-Array gespeichert. Dazu werden ein paar statische
Hilfsvariablen (asm: Register) zur Erfassung der Zeitdifferenz
benötigt.
3) Code-Ende
Verbleibt das IR-Signal wiederum für >10 ms im OFF-Potential
= PAUSE, ist der Code erfasst, der letzten Pausenzeit im
Erfassungs-Array wird der Wert 255 (> 10 ms) zugewiesen.
4) Das erfasste Signal kann nun ausgewertet werden.
Du würdest jetzt die Tabelle der ON- und OFF-Zeiten per RS232
an den PC schicken.
Mein µC betrachtet noch die Code-Sequenz und stellt schon mal
das Codierungsverfahren (mit/ohne Start-Sequenz, ON-variabel,
OFF-variabel, Bit-Shift) fest.
Und noch etliches mehr, worüber du dir noch keine Gedanken
gemacht hast...
ALSO:
1) Suche kein NEC-Protokoll, wo es auch kein Sony-Protokoll ist.
2) Mach dir ein Konzept, das IR-Signal möglichst genau unter
Berücksichtigung und Ausnutzung der HW-Kapazitäten des µC
und des Empfängers zu erfassen und für die Weitergabe bereit
zu stellen.
3) Dann schaun wir mal weiter.
Das Ziel des Ganzen ist eine Routine (unter berücksichitgung der fcpu), bei der ich das Protokoll(Name), die Adresse der Fernbedienung und die Repeat Tasten definiere, und mit einem "rcall Key_get" die Daten in r16 übermittelt bekomme (carry gesetzt = key ist gültig) Ich wollte nicht,dass Du den ASM Code analysierst. Du solltest dir nur beim Brakepoint Auswerten die Register 18 (off on Paar) und 19 (Zähler) anschauen und mit meiner Tabelle vergleichen, um die Darstellung meiner Tabelle zu verdeutlichen. Die RS232 hat damit nichts zu tun. Was vermutlich neu ist, ist meine Betrachtungsweise der Protokolle: -Start und Stop Bit kann ich ignorieren -Die Bits liegen in einem off/on Paar und nicht in einem on/off -Haeder, Repeat Signatur, "Abwandlungen" liegen in einem on/off -Die langen Pausen vor Repeats dienen oft nur der Verzögerung und können ignoriert werden. -bei bekannter Bitbreite ist die Übertragungsdauer nicht von Relevanz Genau das wollte ich Dir mit in der Simulation verdeutlichen. Ich habe mittlerweile viele Protokolle getestet und festgestellt, dass meine Betrachtungsweise wohl nicht falsch ist. wahrscheinlich erklärst Du mich jetzt für komplett verrückt.
Hallo Jacko Ich muss mich korrigieren: Bitte beobachte das IR_Paar nicht das r18. Gruß Günter
Günter S. schrieb: > Ich habe mal einen Nec Code eingelesen (Im Anhang) . Ich denke, dass > der ein oder andere schnell sieht, dass es sich um einen Nec Code > handelt. Alleine die Angabe von Größen in der Einheit einer Leitfähigkeit (Einheitenzeichen S für Siemens) in Zusammenhang mit einem Datenübertragungsprotokoll wirkt nicht gerade erhellend. ;-) https://de.wikipedia.org/wiki/Siemens_(Einheit)
@ my2ct (Gast) Meinst du jetzt das 'S' von Günter S. ? Ich glaube auch langsam, dass ich dem Günter mit seiner Sturheit nicht helfen kann - er reagiert ja auf keine Nach-/Rückfrage. Aber dein Beitrag war keinen Tastendruck wert....
Hallo Jacko Meine Frage war doch "Wer kennt dieses IR Protokoll?". Der for_ro schrieb dass es ich möglicherweise um RCMM handelt. Das kommt der Sache auch sehr nahe. Die Diskusion hier ging dann aber vorwiegend um meine Darstellung. Ich habe versucht, Dir zu veranschaulichen, was ich hier mache, weil Du Dich offensichtlich gut mit dem Thema befasst hast und Dich dafür interresierst. Gruß Günter
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.