[gelöst] Einfache IR-Kommunikation für den RP6

[radbruch]

Hallo

Nicht nur der Widerstand, auch die restliche Elektronik könnte beschädigt werden. Allerdings hat es mein RP6 schadlos überlebt (auch die ersten Tests ohne Trägerfrequenz) und solange die 36kHz anliegen wird vermutlich auch nichts zerstört werden. Weil ich, wie eigentlich immer, zuviele gleichzeitige Baustellen offen habe, wurde dieses Projekt von mir bisher nicht weitergeführt. Nachbau ist zwar erwünscht, geschied aber (wie immer!) auf eigene Gefahr.

Mein ThinkPad (ein T23) hat nur eine IRDA-Schnittstelle, damit funktioniert es NICHT! Man benötigt einen IR-Transceiver wie er z.B. beim asuro verwendet wird.

btw ist das "Verfallsdatum" dieses Threads inzwischen wohl deutlich überschritten ;)

Gruß

mic

[SlyD]

Das hab ich irgendwo in irgendeinem anderen Thread auch schon ausführlich erläutert... find ich aber grad nicht mehr

Wenn mit 36kHz moduliert wird kann das natürlich beliebig lange laufen.
Die RP6Lib macht ja genau das - die könnte man auch dementsprechend abändern das statt RC5 zu senden am UART Pin gelauscht wird (s. ISR (TIMER2_COMP_vect) alles in der if(ircomm_pulse) Bedingung und den beiden else zweigen muss geändert werden)...
Das hätte auch den Vorteil das das ACS weiterhin verwendbar bleibt, da hier auch direkt die synchronisation damit erledigt wird und der Timer2 ja sowieso auf jeden Fall für das ACS benötigt wird.


Wenn Du also sicherstellen kannst, dass die IR LEDs stets nur ein moduliertes Signal erhalten ists kein Problem.
Die IR Dioden sind für den IMPULS Betrieb gedacht. Man kann die für eine gewisse Zeit mit sehr hohem Strom betreiben um die Reichweite zu steigern.

Wenn Du aber den IRCOMM Pin dauerhaft anschaltest dann nehmen die IR Dioden nach kurzer Zeit Schaden. Der Widerstand ist auch auf Pulsbetrieb ausgelegt weil die IR Dioden das auf Dauer sowieso nicht anders überstehen würden.

MfG,
SlyD

[TigerWolf]

Hallo,

ist das eigentlich hier der aktuellste Thread zum Thema "IR Kommunikation? In anderen Threads wird oft auf diesen hier verlinkt ...

Ich versuche gerade herauszufinden, wie der Code funktioniert. Wenn ich das richtig sehe, wird beim Lesen das Timing durch aktives Warten mit "sleep(4);" erledigt. Dazu 2 Fragen:

(1) Wenn man mit anderen Baudraten arbeiten will, muss man hier den Wert ändern (z.B. "sleep(;" für 1200 Baud), richtig?

(2) Mich wundert, das hier die Interrupts nicht ausgeschaltet werden. "sleep(4);" könnte doch von einem Interrupt unterbrochen werden, und dann stimmt das Timing nicht mehr oder?!? Andererseits lassen ja die folgenden Antworten darauf schließen, dass die Methode funktioniert.

Kann mich hier wer mal schlau machen?

mfg
TigerWolf

[RolfD]

Hallo Tigerwolf,
guck dir mal das hier an : http://www.rn-wissen.de/index.php/RP6_-_Morse-Code
da ist wohl einiges an Wissen um die IR Kommunikation mit eingeflossen.
Gruß Rolf

[radbruch]

Hallo

Es ist der aktuellste Thread, weil es der einzige ist.

Vielleicht die Antwort auf die zweite Frage zuerst: Wenn man die Interrupts ausschaltet, wird die ISR für sleep() nicht mehr aufgerufen.

In der Lib für die Base findet man folgende ISR: Externer INT0 und INT1 für die Encoder, INT2 fürs ACS, Timer1_comp als Zeitgeber für sleep() und die Stopwatches, Power-on-Warnung und die Motorregelung. Letztlich noch die Timer2_comp für die ACS-Impulse. Da die IR-Kommunikation blockierend ist, können wir das ACS als Störquelle ausschließen. Wenn dann noch die Antrieb stören sollten, könnte man die auch kurz anhalten. Eine kleine Verzögerung bei den sleep()s stört aber nicht wirklich:

Zu 1: Die Bitdauer bei 2400 Baud ist 417µs, sleep(1) dauert 100ms. Ähnlich wie bei Himmel und Hölle haben wir zehn Felder hintereinander (Start-, 8 Daten und Stopbit) mit je 417 Länge und wir müssen so durchspringen, dass wir jedes Feld genau einmal treffen. Einzige Einschränkung: Wir haben nur 100er als Sprungweite. Beim ersten Sprung mit 300 trifft man das dritte Viertel (im Abstand von 300 von der Vorderkante) des Startbits und alle weiteren mit 400 treffen dann die einzelnen Datenbits. Da die Feldlänge aber nicht unseren Sprungweiten entspricht, landen wir mit jedem Sprung um den Unterschied (hier 17) kürzer. Das summiert sich dann auf 11*17 und ist weniger als die 300 die wir zu Beginn noch Abstand zum Feldanfang hatten. Verwirrt? Ich auch.

Bei 1200 Baud beträgt die Bitdauer 834µs. Durch einfaches Verdoppeln der Werte würde sich dann sleep(6) als Startverzögerung anbieten und sleep(8) zum Weiterspringen. Da man mit sleep(8) aber auch noch mit 34µs reserve auf das Startbit treffen würde, wäre sleep(7) als Startverzögerung wohl optimal.

Um nun nochmals auf die Interrupts zurückzukommen: Da die sleep()s eh nicht genau in die Feldlänge passen, stört eine kurze Verlängerung der Verzögerung durch die Ausführung einer ISR nicht.

Gruß

mic

Der Trick mit Sleep() ist schon alt:
https://www.roboternetz.de/community...597#post444597