Hallo,
gerade versuche ich via IRSND Bibliothek meinen Roomba Staubsauger per
Infrarot LED zu starten. Die Hardware ist zum Testen bisher ein RUMPUS
Entwicklerboard mit ATMega168.
Scheint alles soweit zu funktionieren, denn die LED flackert, aber ich
habe keine original Fernbedienung, mit der ich über IRMP die richtigen
Daten auslesen könnte.
Ich brauche die folgenden Angaben:
irmp_data.protocol = IRMP_ROOMBA_PROTOCOL;
irmp_data.address = 0x????;
irmp_data.command = 0x0088;
irmp_data.flags = ?;
Aus anderen Projekten konnte ich zummindest den richtigen Wert für das
Kommando "Clean" herausfinden.
Vielleicht weiß ja jemand wie ich alternativ an die Daten kommen kann.
Ich habe schon mit allen möglichen Schlagworten gegoogled. Leider
erfolglos.
Ich hoffe ich stelle mich nicht zu blöd an, bin nämlich leider noch
ziemlich unerfahren mit sowas.
Vielen Dank im Voraus.
Christian
> irmp_data.command = 0x0088;>> Aus anderen Projekten konnte ich zummindest den richtigen Wert für das> Kommando "Clean" herausfinden.
Der richtige Wert ist also 0x0088? Wo hast Du den her? Kannst Du da eine
Quelle angeben?
Auch hier hilft der obige IRMP-Link weiter. Dort steht:
1
Frame 1 Start-Bit + 7 Daten-Bits + 0 Stop-Bit
Das Roomba-Kommando hat also nur 7 Bits, Dein Wert 0x88 ist also auf
jeden Fall zu groß. Vermutlich hat da jemand das Start-Bit irrtümlich
als Kommando-Bit interpretiert und deshalb 0x0088 geschrieben.
Richtig wäre eher:
1
irmp_data.command=0x0078;
vorausgesetzt, die unteren 7 Bit aus Deiner "Quelle" stimmen wenigstens.
Aber ich glaube nicht, dass der Code korrekt ist. Grund: Siehe weiter
unten.
> irmp_data.flags = ?;
Das gibt die Anzahl der Wiederholungen des Frames an. In der Regel muss
ein IR-Frame nicht wiederholt werden.
Daher:
1
irmp_data.flags=0;
Im IRMP-Paket gibt es auch das Verzeichnis IR-Data. Dort findest Du die
gescannten Daten der Roomba-Fernbedienung.
Mal kurz mit IRMP unter Linux eingelesen:
Also: Die Kommando-Codes haben den Wertebereich 0x0000 bis 0x000F - aber
nicht 0x0088.
Probiere die obigen aus.
Viel Glück!
P.S.
Noch etwas aus obigem Link:
1
Wiederholung dreimalig nach jeweils 18ms?
Es kann also sein, dass Du flag tatsächlich auf 3 setzen musst. In den
Scans sehe ich aber nur 2 Wiederholungen. Daher würde ich erstmal
1
irmp_data.flags=2;
ausprobieren, wenn 0 nicht funktioniert.
Wenn 2 auch nicht geht, dann:
1
irmp_data.flags=3;
Mehr kann ich dazu nicht sagen, ich habe keinen ROOMBA-Staubsauger. Das
Protokoll hatte ich damals lediglich anhand der Scans implementiert.
Vielen Dank für die Hinweise. Habe das leider überlesen.
Dennoch muckt sich der Roomba auch mit den Werten noch nicht. Habe jetzt
alle Möglichkeiten mal eingegeben, glaube ich.
Ich habe ja keine Erfahrung...ist mein Entwicklerboard vielleicht zu
schwach auf der Brust?
Siehe:
http://www.lochraster.org/rumpus/data/rumpus-v2-schematic.pdf
Das flackernde Licht der LED ist mit der Kamera ziemlich schwach zu
sehen.
Beste Grüße
Christian
Christian S. schrieb:> Ich habe ja keine Erfahrung...ist mein Entwicklerboard vielleicht zu> schwach auf der Brust?
Die Schaltung für die IR-LED sieht eigentlich gut aus.
Läuft der µC tatsächlich auch mit 16 MHz?
Sprich:
- Sind die Fuses für den 16MHz-Quarz korrekt eingestellt?
- Ist CKDIV8 deaktiviert, damit der Takt nicht noch durch
8 geteilt wird?
Am besten schreibst Du hier mal die Fuse-Konfiguration rein und hängst
die irsndconfig.h an.
Hast Du mal versucht, ein anderes Gerät erfolgreich anzusprechen, wie
zum Beispiel Deinen TV? Die Codes kannst Du ja vorher mit IRMP
ermitteln. Dann wüsste man zumindest, dass IRSND im allgemeinen schon
mal korrekt läuft.
Vielen Dank für die Tipps. Werde ich heute abend nach der Arbeit mal
posten. Ich habe bisher geglaubt, dass der Takt ok ist, weil die Pausen
(delay) ziemlich gut stimmen. Auch als ich mal zur Probe andere
Pausenzeiten eingestellt hatte.
Die Idee mit dem Fernseher finde ich auch gut, aber ich habe bisher IRMP
selbst noch gar nicht probiert. Falls es später weiter nicht klappt,
werde ich das aber auch angehen.
Beste Grüße
Christian
Hier also die Infos. Der Quarz hat allerdings 20Mhz. Habe ich auch so
angegeben.
BOOTSZ = 1024W_1C00
BOOTRST = [X]
RSTDISBL = [ ]
DWEN = [ ]
SPIEN = [X]
WDTON = [ ]
EESAVE = [ ]
BODLEVEL = DISABLED
CKDIV8 = [ ]
CKOUT = [ ]
SUT_CKSEL = EXTFSXTAL_16KCK_14CK_4MS1
EXTENDED = 0xF8 (valid)
HIGH = 0xDF (valid)
LOW = 0xE7 (valid)
Angehängt gibt es auch noch die cfg.
Zur Sicherheit noch die main.c
Mein Fernseher wäre von Philips. Modell 40PFL5605H.
Vielleicht kennst Du Dich zufällig damit aus und kannst mir
Einstellungen dazu nennen.
Vielen Dank.
Christian S. schrieb:> Hier also die Infos. Der Quarz hat allerdings 20Mhz. Habe ich auch> so angegeben.
Okay.
> CKDIV8 = [ ]> SUT_CKSEL = EXTFSXTAL_16KCK_14CK_4MS1
Sieht korrekt aus.
> Angehängt gibt es auch noch die cfg.
Auch okay.
Christian S. schrieb:> Zur Sicherheit noch die main.c
Sieht auch korrekt aus.
> Mein Fernseher wäre von Philips. Modell 40PFL5605H.> Vielleicht kennst Du Dich zufällig damit aus und kannst mir> Einstellungen dazu nennen.
Leider nicht. Du solltest RC5 und RC6 einschalten, wenn Du mit IRMP die
Fernbedienung auslesen willst. Das sind hauseigene Protokolle von
Philips. Könnte aber auch sein, dass das Ding aus Asien kommt und von
Philips nur umgelabelt wird.
Wo hast Du denn den Roomba ohne Fernbedienung her? Vielleicht ein
gebrauchtes Teil von eBay? Vielleicht ist der Empfänger im Roomba
kaputt?
Christian S. schrieb:> Zur Sicherheit noch die main.c
Ich habe gerade nochmal in den Source geschaut:
Du kannst beim Senden die flags doch auf 0 setzen. Damit werden bereits
8 Frames ausgesandt. Wenn Du die flags auf 1 setzt, sind es 16 Frames,
bei flags = 2 sind es sogar schon 24 Frames - also zuviel des Guten.
Ich erinnere mich auch dunkel an den Mailaustausch mit demjenigen, der
mir damals die Roomba-Scans zugeschickt hat. Er hatte auch IRSND damit
getestet und sagte mir, bei 8 Frames wäre das Steuern des Roombas am
zuverlässigsten.
Deshalb hatte ich damals in irmpprotocols.h gesetzt:
1
#define ROOMBA_FRAMES 8 // ROOMBA sends 8 frames (this is a lie, but more comfortable)
Erstmal lieben Dank für die Prüfung der Dateien.
Der Roomba 605 ist eher im günstigen Bereich angesiedelt. Da hat man an
der Fernbedienung gespart. Er ist aber laut Internet aber geeignet um
damit gesteuert zu werden.
Ich möchte ja keine Fernbedienung bauen. Die könnte ich einfach
nachkaufen. Ich löte parallel an einer kleinen batteriebetriebenen
Kiste, die einfach regelmäßig alle 24h den Sauger startet wenn ich
gerade nicht daheim bin. Die teureren können das ja per scheduler
selbst. Ob man das braucht, darüber kann man streiten. Hätte ich halt
gern.
Die Schaltung ist also in Ordnung.
LED leuchtet/ flackert.
Taktfrequenz stimmt.
Konfig und mein Code sind richtig.
Die Codes von Dir können nicht falsch sein, weil ausgelesen.
flags hatte ich schon auf 0,1,2,3
Also kann es noch der Empfänger sein!? Vielleicht beiße ich doch noch
mal in den sauren Apfel und kaufe eine originale Fernbedienung. :(
Haben wir alles sonst ausgeschlossen?
VG Christian
Christian S. schrieb:> LED leuchtet/ flackert.
Du hast aber kein Scope, um das Signal zu prüfen, oder?
Es sieht eigentlich alles gut aus, wahrscheinlich ist es nur eine
Kleinigkeit, woran es hapert.
> Konfig und mein Code sind richtig.
Ich werde da nochmal drüberschauen, aber auf den ersten Blick habe ich
nichts gefunden, was das Problem erklären könnte.
> Die Codes von Dir können nicht falsch sein, weil ausgelesen.
Ja. Derjenige, von dem ich die Scans hatte, hat IRSND anschließend auch
an seinem Roomba getestet, denn er wollte - genau wie Du - den Sauger
automatisiert steuern. Details kenne ich allerdings nicht.
Ich kann auch keinen Fehler im IRSND selbst erkennen, denn wenn ich den
Output von IRSND wieder in den IRMP reinschicke, erkennt er einwandfrei
die Kommandos.
> Also kann es noch der Empfänger sein!? Vielleicht beiße ich doch noch> mal in den sauren Apfel und kaufe eine originale Fernbedienung. :(
Vielleicht haben die bei Roomba auch irgendwann das Protokoll geändert.
Mich wundert auch, dass Du da den Code 88 angeführt hast.
> Haben wir alles sonst ausgeschlossen?
Gute Frage. Ich prüfe nochmal alle Infos, die ich von Dir habe.
Das liegt glaub ich daran, dass mein board älter ist. Ich bin mir
sicher, dass ich über deren vorbereiteten Warenkorb gekauft habe.
Ich hatte aber auch schon mal zwischendurch auf intern umgefused.
Die Codes stammen aus einem Dokument von der Staubsaugerfirma selbst.
Kann man überall im Netz finden. Meistens Dezimal. Ich habe das wohl
einfach falsch interpretiert.
Das erste Bit ist das Start-Bit, daher kommt die erste 8 im Hex Code.
Wenn man also 0x80 abzieht, kommt genau der IRMP-Code raus, also 0x01
bis 0x0F.
1
Dec Hex Binary Meaning
2
129 0x01 1000 0001 Left
3
130 0x02 1000 0010 Forward
4
131 0x03 1000 0011 Right
5
132 0x04 1000 0100 Spot
6
133 0x05 1000 0101 Max / Dock
7
134 0x06 1000 0110 Small
8
135 0x07 1000 0111 Medium
9
136 0x08 1000 1000 Large / Clean
10
137 0x09 1000 1001 Pause
11
138 0x0A 1000 1010 Power
12
139 0x0B 1000 1011 Arc-forward-left
13
140 0x0C 1000 1100 Arc-forward-right
14
141 0x0D 1000 1101 Drive-stop
Das sieht also ganz gut aus und passt zu den IRMP-Scan-Codes.
In Deinem main.c habe ich gesehen, dass Du 0x05 (Dock) ausprobiert hast.
Hast Du auch mal andere Codes probiert, nämlich 0x08 (Clean)?
Super cool...er läuft schon mal an. Mit dem Code 0x05 und flags =0
Allerdings schaltet die nächste Sendung ihn wieder aus. Hast du dazu
noch eine Lösung? Leider brauchts nämlich ein paar durchläufe, bis er
wirklich anspringt.
Die beiden nullen waren eben zu viel.
0x05 wollte er. Nicht 0x005
Die Zuverlässigkeit scheint vom Status des Saugers abzuhängen. Zeitweise
klappte es bei jedem Versuch. Vielleicht muss ich erst "Power" 0x0A
senden.
Ich versuche später noch ein bisschen was. Wenn es zuverlässig läuft
brauche ich ja sowieso irgendwie 24h zwischen den Auslösungen.
Aber erstmal meinen herzlichen Dank für Deine Hilfe und Deine Geduld! Es
ist sehr beeindruckend, was Du da auf die Beine gestellt hast!
Christian S. schrieb:> Allerdings schaltet die nächste Sendung ihn wieder aus.
Die nächste Sendung? Nach ein paar Sekunden? Oder Millisekunden?
Vielleicht solltest Du ihn nicht in einer Endlosschleife die ganze Zeit
mit Befehlen zuballern.
Christian S. schrieb:> Die beiden nullen waren eben zu viel.>> 0x05 wollte er. Nicht 0x005
Kann nicht sein 0x05 und 0x005 ist identisch. Auch 0x0005 oder 0x5. Ist
alles (dezimal) 5.
> Die Zuverlässigkeit scheint vom Status des Saugers abzuhängen. Zeitweise> klappte es bei jedem Versuch. Vielleicht muss ich erst "Power" 0x0A> senden.
Ja, kann durchaus sein. Bleib bei flags = 0. Wie gesagt: Schon hier
werden 8 Frames rausgeschickt.
> Aber erstmal meinen herzlichen Dank für Deine Hilfe und Deine Geduld! Es> ist sehr beeindruckend, was Du da auf die Beine gestellt hast!
Danke. Ich drücke Dir die Daumen.