IR Empfänger für TTT(T)? Was gibt es was nicht?

[LazyZero]

Hallo,

mich quält gerade die Elektronik. Ich bin im Moment zwar noch voll mit dem MAN beschäftigt, der einen GWS Epfänger bekommen soll, aber das nächste Projekt schwirrt schon in meinem Kopf wenn die Sonne mal wieder zu heiß auf meine Balkonwerkstatt scheint.
Tja, was soll man bei über 30°C auch anderes machen als den Geist aussetzen lassen und rumspinnen?
Das Problem ist, ja wie immer der vorhandene Platz. Also liegt nichts näher als sich mal näher oder ferner mir IR Empfängern zu beschäfftigen.
Was ich bis jetzt herausgefunden hab sind Empfänger von mikroantriebe und mikromodellbau:

IR-R1 mit Fahrregler, Schaltkanal und Servoausgang à 39€

IR-E1, 3 proportional- und 1 Schaltkanal à 25€

IR-E4 mit 4 proportionale Kanäle oder 3 proportionale und Licht + Blinkerfunktionen à 38€
sowie

IR-R2L mit 2 Drehzahlsteller, 1 Standard Servo Kanal, Licht, Rücklicht, Blinker links, Blinker rechts , Warnblinker, Blaulicht à 59€

Desweiteren die IR Empfänger von Koichi Tanaka auf RC Groups, die aber für Flieger gedacht sind und deshalb keinen Rückwärtsgang haben und mit elektromagnetischer Lenkung arbeiten.

Auch hab ich hier im Forum gesehn und gelesen, daß Doc und diets an sowas arbeiten bzw. am laufen haben, aber nur ein Fahrzeug gleichzeitig fahrbar ist.

Da ich aber nur wenig Erfahrung mit Atmels gesammelt habe und Assembler nicht beherrsche. Meine Frage welche Anforderungen stellt ein IR Empfänger an den µC. Ich denke da speziel an die Anzahl der Timer, für Empfang und für das PWM Signal für Servo und Fahrtenregler.

Bescheidene Fähigkeiten im Platinenherstellen und programmieren in Bascom und C, mit den Adressen noch was überfordert, habe ich. Ein bisschen eageln kann ich auch, aber am Schaltungen entwerfen happert es.

Ich frag diesen ganzen Stuss weil die käuflichen Empfänger auf den ersten Blick nicht wirklich hohe Hardwarekosten verursachen, nur die geistige Leistung rechtfertigt die Preise. Leider sind die für meinen Geldbeutel dann doch etwas zu happig.

Versteht mich nicht falsch, ich möchte keine fertige Lösung auf dem Silbertablet.

Gruß LazyZero
_________________
GPSpeedEvaluator zum Auswerten von geloggten Fahrten.

[diets]

Die mikroantriebe und mikromodellbau Empfänger haben zwar mehrere Kanäle, jedoch ist so viel ich weiss auch immer nur ein Modell ansteuerbar.

Die verschiedenen Kanäle dienen nur dazu, dass man ein anderes Fahrzeug, welches sich auf dem gleichen Modul befindet nicht ausschalten muss.

Diese Funktion ist hauptsächlich für Fahrzeugkombinationen gedacht - Bagger und Tieflader, etc.


Meine Lösung kann (möglicherweise problemlos) auch auf mehrere (4) Kanäle ausgebaut werden. Dazu wird ein Kanalswitching, ähnlich wie bei den DigiQs verwendet.

Aktueller Status meiner Lösung:
Wie vor 3 Monaten Da ich derzeit mehr mit Messing als mit Silizium arbeite, hab ich nicht mehr weiter entwickelt. Derzeit habe ich auch noch genug Spenderplatinen, die ich für meine Steuerung missbrauchen kann. Jetzt im Sommer wird sich auch nicht viel tun. Ich denke, dass ich ab Herbst wieder in die Programmierung und Entwicklung einsteigen werde.


diets - ist eigentlich nicht faul, nur auf abwegen

[LazyZero]

Quote:

---

Die verschiedenen Kanäle dienen nur dazu, dass man ein anderes Fahrzeug, welches sich auf dem gleichen Modul befindet nicht ausschalten muss.

---

Das ist natürlich schade, wäre auch zu schön gewesen.

LazyZero
_________________
GPSpeedEvaluator zum Auswerten von geloggten Fahrten.

[ohrange]

Ich habe auch schon mal angefangen in der Richtung zu planen, angespornt vor allem von dem was technisch möglich ist (Andreas Rackels wahrscheinlich recht bekannte Sender/Empfänger), und den Preisen der komerziellen Lösungen. Die sind schon gerechtfertigt, da steckt ja auch eine Menge Entwicklungsarbeit drin, und einer ist ja auch noch OK, wenn man aber mehrere Fahrzeuge ausrüsten will (und man will ja immer MEHR), dann gehts schon ins Geld.

Ich bin eher auf die PIC Microcontroller losgegangen, da hatte ich schon einen Programmer (PIC-Kit) von meinen kläglichen ersten Programmierversuchen ohne Modellbaukontext rumliegen. Zudem gibts da schon Codes (Koichi, Darkith u.a.) die man zugrundelegen könnte.

Dachte ich.

Aber bei genauerer Betrachtung gibt es für die TTT(T) Sachen ein anderes Anforderungsprofil. Um nur mal grundsätzliche Wünsche zu äußern:
- mehrere Fahrzeuge unabhängig (scheint bei gleichzeitiger Ansteuerung mehrerer Fahrzeuge aber bei IR systembedingt schwierig, Licht lässt sich nicht so einfach auseinandersortieren wie unkwellen
- mehr als 2 proportionale Kanäle (für Sonderfunktionen)
- Schaltkanäle (viele)
- Servoelektronik und am besten ESC integriert

Da kommt man aber dann schnell drauf, dass es nicht so clever ist die auf der (eigentlich analogen) PPM-Codierung von normalen Funkfernsteuerungen aufzusetzen, wie das Koichi, Darkith aber auch komerzielle Anbieter wie Didel zum Beispiel machen. Hier ist die Zuordnung Sender-Empfänger nicht Teil des Protokolls ist sondern erfolgt über die Sendefrequenz, was bei IR so nicht funktioniert. Auch muss man bei PPM mehrere Schaltkanäle über den Umweg eines Proportionalkanales übertragen.

Alles schreit also eigentlich nach einer rein digitalen Übertragung, mit einem Protokoll, das oben genannte Anforderungen erfüllen kann. Sinnvoll wäre natürlich ein gemeinsames Protokoll zugrundezulegen, um eine gewisse kompatibilität zu erreichen.

Da ich sicher nicht der erste bin, dem diese Dinge eingefallen sind, muß zugeben, dass ich noch nicht lange beim TTT(T) Modellbau bin, und in der Szene da gar nicht drinstecke. Ich grüble eher im stillen Kämmerlein. Es gibt das alles schon (siehe Link oben), man muss das Rad nicht neu erfinden, allerdings will man ja auch nicht irgendwas abgreifen, ohne was beitragen zu können.

So erstmal genug geschrieben,
Florian

[LazyZero]

Hallo ohrange,

den Empfänger von Andreas Rackel kannte ich noch nicht. Der dort beschriebene Sender, vor allem das er auf 455kHz Funk und 38kHz IR sendet hat mich an ein Elektorprojekt von 2001 erinnert.
Also in meinem Archiv gewühlt und tatsächlich den Artikel gefunden.
Dort wird auch wunderbar das zu Grunde gelegte Protokoll beschrieben. Hier mal ein Bild vom Signalverlauf.



Zwischen Start-Bit und Kanaladresse könnte man noch eine Kennung für unterschiedliche "Frequenzen" bzw. Modelle einfügen.

Bei Interesse könnte ich dir den Artikel mailen.

Gruß LazyZero
_________________
GPSpeedEvaluator zum Auswerten von geloggten Fahrten.

[diets]

Quote:

---

455kHz Funk

---

Wie kommst du darauf? Auch die 455kHz sind natürlich Infrarot!

Quote:

---

mehrere Fahrzeuge unabhängig (scheint bei gleichzeitiger Ansteuerung mehrerer Fahrzeuge aber bei IR systembedingt schwierig,

---

Das geht (sinnvoll) nur mit zeitversetzem Senden. Bei jeder kommerziellen Lösung die ich kenne (Digi-Q, Nikko I-Racer), wird das so gemacht.

Quote:

---

mehr als 2 proportionale Kanäle (für Sonderfunktionen) - Schaltkanäle (viele)

---

Man muss abwägen, wie lange das Telegramm maximal sein darf. Bei 4 proportionalen Kanälen (8 Bit breit) und 8 Schaltkanälen hat man eine Telegrammlänge von mindestens 40 Bit (Synchronisation, ID und Fehlerkorrektur nicht mitgerechnet). Damit kommt man mit dem Protokoll aus der Elektor schon mal auf (schlimmstenfalls) über 60 ms. Bei 4 Fahrzeugen und etwas Pausenzeit für die Synchronisation liegt man etwa bei 300 ms. Das ergibt dann leider nur 3 Befehle, die in der Sekunde an das Fahrzeug übertragen werden. Bei FM haben wir 50 Befehle/Sekunde! Ok, TTTTs sind nicht ganz so schnell wie MiniZs

Quote:

---

Servoelektronik integriert

---

Lieber nicht! Bei den meisten Miniaturservos ist das Poti auf der Platine verlötet. Da ist es meiner Meinung nach sinnvoller ein PPM-Signal für das Servo zu erzeugen.

Quote:

---

und am besten ESC integriert

---

Das ist noch mit das einfachste

Quote:

---

Alles schreit also eigentlich nach einer rein digitalen Übertragung, mit einem Protokoll, das oben genannte Anforderungen erfüllen kann. Sinnvoll wäre natürlich ein gemeinsames Protokoll zugrundezulegen, um eine gewisse kompatibilität zu erreichen.

---

Weil ansonsten mit Infrarot nur (maximal) einer anständig fahren wird


diets - kann dir gerne mal den sourcecode senden

[ohrange]

Quote:

---

4 proportionalen Kanälen (8 Bit breit) und 8 Schaltkanälen

---

das würde ich sagen ist schon mal sehr viel, selbst für Modelle mit vielen Funktionen (Bagger, Kipper) brauchts ja nicht so viele Propokanäle, vieles (auch Motoren) lässt sich ja einfacher über Schaltkanäle steuern.

Quote:

---

Lieber nicht! Bei den meisten Miniaturservos ist das Poti auf der Platine verlötet

---

Ich dachte auch nicht an ein klassisches Poti, eher an einen Motor und eine separate Lageerkennung über einen Hall-Sensor oder optischen Encoder. Ich denke da an Modelle, die kleiner als LKWs sind, da passt kein normales Servo rein (Ich bastle gerade am "Innenausbau" eines HO Barkas B1000). Ein PPM (für die Servos ist es ja eigentlich nur noch ein PWM)-Signal alternativ anzubieten sollte nicht so schwierig sein.

Quote:

---

Das ist noch mit das einfachste

---

der ESC, ja, und lässt sich mit einer Ein-Chip-H-Brücke (siehe anderer Thread) auch leicht mit genügend Power versehen

Quote:

---

(maximal) einer

---

könnte bisschen langweilig sein.

Sourcecode würde mich sehr interessieren, versuche mal Dir eine PM zu schicken, habe ich noch nie gemacht,
Florian

[LazyZero]

Quote:

---

Wie kommst du darauf? Auch die 455kHz sind natürlich Infrarot!

---

Mh. Man lernt nie aus.

Quote:

---

Man muss abwägen, wie lange das Telegramm maximal sein darf. Bei 4 proportionalen Kanälen (8 Bit breit) und 8 Schaltkanälen hat man eine Telegrammlänge von mindestens 40 Bit (Synchronisation, ID und Fehlerkorrektur nicht mitgerechnet). Damit kommt man mit dem Protokoll aus der Elektor schon mal auf (schlimmstenfalls) über 60 ms. Bei 4 Fahrzeugen und etwas Pausenzeit für die Synchronisation liegt man etwa bei 300 ms. Das ergibt dann leider nur 3 Befehle, die in der Sekunde an das Fahrzeug übertragen werden. Bei FM haben wir 50 Befehle/Sekunde!

---

Das wird dann etwas träge, wenn nicht nur die Fahrzeuge, sondern auch der Empfänger im Schneckentempo arbeitet. Bei dem Elektor Protokoll, ist übrigens angedacht nur Ändereungen der A/D-Werte (propo Kanäle) und Schaltzustant zu übertragen, deshalb auch die Kanaladresse.

Quote:

---

Quote:

---

und am besten ESC integriert

---

Das ist noch mit das einfachste

---

Zählen und an PWM übergeben, das Wissen aber umzusetzten ist was anderes und mir noch nicht so ganz erschlossen.

Sourcecode ist immer interessant, höchstens er ist in Assembler, dann versteh ich nur Bahnhof. Falls Du ihn mir schicken möchtest meine eMail Adresse kennst Du ja.

Gruß LazyZero
_________________
GPSpeedEvaluator zum Auswerten von geloggten Fahrten.