Das sah für mich erstmal nach einem Zahlendreher aus: 10500 vs. 15000, was IRMP-Standard ist. Also sind es tatsächlich 10500?
darüber stolperte ich auch!
Hallo,
Ja sind 10500 :-) Ich habe gemerkt, mein µC läuft stabiler mit etwas weniger IRQ, aber hat keine Probleme bisher mit dem Empfang. Aber ich kann es gerne hochsetzen und dann nochmal probieren. Zeit ist kein Problem, bin eh jetzt im Familienurlaub ;-) Vielen Dank für deine Mühen. Die angepasste external logging sende ich noch. Oder gibt es ein Github wo ich das posten kann ?
:
Bearbeitet durch User
Hallo Frank, hallo Gemeinde,
meine Neuerwerbung, ein Switchbot Standventilator, kommt mit einer IR-Fernbedienung. Da ich IRMP bereits seit den Anfängen des Projektes auf einem Atmega168 zum Senden und Empfangen nutze, gleich mal alle Protokolle nacheinander durchprobiert. Leider Fehlanzeige.
Das Internet schweigt sich bezüglich der IR-Code des Gerätes auch aus.
Die letzte Version von IRMP ist 5 Jahre alt. Besteht berechtigte Hoffnung, dass neue Protokolle implementiert werden? Welche Informationen werden benötigt?
Protokoll mit 15 kHz Abtastrate anbei. Die KI meint dazu
1 |
|
2 |
|
3 |
|
4 |
|
Nur leider erkennt IRMP es nicht als NEC.
VG eku
:
Bearbeitet durch User
Hallo Frank, hallo Gemeinde, meine Neuerwerbung, ein Switchbot Standventilator, kommt mit einer IR-Fernbedienung. Da ich IRMP bereits seit den Anfängen des Projektes auf einem Atmega168 zum Senden und Empfangen nutze, gleich mal alle Protokolle nacheinander durchprobiert. Leider Fehlanzeige. Das Internet schweigt sich bezüglich der IR-Code des Gerätes auch aus. Die letzte Version von IRMP ist 5 Jahre alt. Besteht berechtigte Hoffnung, dass neue Protokolle implementiert werden? Welche Informationen werden benötigt? Protokoll mit 15 kHz Abtastrate anbei. Die KI meint dazu
Analyse: switchbot_fan.log (IRMP-Mitschnitt, 8 Tasten)
Format & Abtastrate: Je Taste eine 0/1-Abtastspur. 0 = Träger/Burst (TSOP-invertiert), 1 = Pause. Deine 15 kHz stimmen exakt: Der Header misst 135 Samples = 9,0 ms – das ist auf ±1 Sample das NEC-Normmaß. Alle 8 Spuren sind sauber demodulierte Hüllkurven (kein 38-kHz-Aliasing sichtbar).
Protokoll: NEC, Adresse 0xAA, alle Komplement-Checks OK. Bitmaß: Mark ~0,6 ms, 0 = 0,5 ms Pause, 1 = 1,6 ms Pause, LSB-first. Jede Spur: 9 ms
- 4,5 ms Header, 32 Bit (Adr + ~Adr + Cmd + ~Cmd), alle Inverter-Proben (a^~a, c^~c = 0xFF) bestanden.
Nur leider erkennt IRMP es nicht als NEC. VG eku
Zusatzinformation der KI:
Kurzfassung: Der Frame ist lehrbuchmäßiges NEC – aber der Stop-Bit-Check in irmp.c verwirft ihn wegen des unüblichen 4,1-ms-Trailer-Bursts. Alle 32 korrekt empfangenen Bits landen im Müll.
Geprüft und als Ursache ausgeschlossen:
Abtastrate: F_INTERRUPTS = 15000 (irmpconfig.h:51) passt exakt zur Messung (135 Samples = 9,0 ms). NEC freigeschaltet: IRMP_SUPPORT_NEC_PROTOCOL = 1 (irmpconfig.h:77). Polarität: Log 0 = Burst entspricht IRMP-Konvention (irmp.c:3196, IRMP_HIGH_ACTIVE = 0, irmpconfig.h:253). Toleranzen: Start (135 ∈ [93,176], 66 ∈ [46,88]), Bit-Marks (9–10 ∈ [5,11]), Pausen 0 (7–8) und 1 (24–25 ∈ [17,34]) – alles ±30 %-konform. Die Fehlerstelle (irmp.c:4176–4200): Nach 32 Bits (NEC_COMPLETE_DATA_LEN = 32, NEC_STOP_BIT = 1) verlangt IRMP als Stop-Bit einen Puls im 0,56-ms-Fenster (~5–11 Samples). Die Spur liefert dort aber den 61-Sample-Burst (4,1 ms) → Zweig error: stop bit timing wrong → irmp_start_bit_detected = 0, alles resettet. Der 15,5-ms-Timeout (irmpprotocols.h:95) greift nicht mehr, weil der Stop-Check bei wenigen ms Pause zuerst feuert. Das passiert bei allen 8 Tasten identisch – deshalb nie eine Erkennung.
Behebung (nur zur Info): Stop-Check für NEC patchen (überlangen Stop-Puls bei irmp_bit == 32 akzeptieren) – oder IRMP ganz umgehen: Die Codes sind bereits verlässlich dekodiert (Adr 0xAA, Cmds 0xA5/0x0A/0x55/…), Standard-NEC-Replay genügt. Auch die NEC-Repeat-Erkennung (9 ms + 2,25 ms) wird den 4,1-ms-Trailer nie matchen – zweitrangig, solange schon der erste Frame verworfen wird.