naja, wie man es dreht und wendet, es gibt für verschiedene Ideen bestimmte Vor- aber auch Nachteile.
Eine weitere Idee wäre, wenn der Sender sowie der Empfänger ein Array mit den letzten Werten vorhalten würden. Bei einer Änderung im Array wird genau dieser Teil übertragen. Sprich, wenn sich zehn Kanäle nie ändern, würden diese initial einmal übertragen werden, danach eigentlich nicht mehr (oder alle paar Sekunden zur Sicherheit).
Der Vorteil hierbei wäre, dass sofort Änderungen an einem Kanal weitergereicht werden. Der Nachteil ist die Datenmenge, denn es muss jetzt auch die Adresse übermittelt werden. Allerdings könnte dieses System unabhängig arbeiten und schneller auf Änderungen reagieren. Auch die Geschwindigkeit könnte man hier durchaus erhöhen.
Eine weitere Idee wäre, mit zwei LEDs und zwei Empfänger-Dioden zu arbeiten, die mit unterschiedlichen Frequenzen arbeiten. Kostet aber mehr Platz, es müssen parallel Daten übertragen und ausgewertet werden. Das würde ich eigentlich eher vermeiden wollen.
Ansonsten bliebe noch Funk (z.B. Bluetooth LE oder etwas ähnliches), hierbei müsste man halt das Binden beim Ankuppeln / Abkuppeln planen und programmieren. Das wäre bei der Übertragung evtl. besser, da kein Sichtkontakt notwendig ist. Aber die beiden Geräte müssen sich halt zuverlässig erkennen.
zunächst mal danke für diese tolle Tabelle :) Ich habe komischerweise seit zwei Tagen massive Probleme bei der Servoübertragung bzw. Auswertung der eingehenden Signale vom Empfänger. Übertrage ich für Kanal 1 einen konstanten Wert, spielen die Servos mit. Sobald ich aber Kanal 1 mit dem eingelesenen Signal füttere, spielen alle Servos verrückt. Keine Ahnung was da los ist. Ich habe bemerkt, dass bei drei langen Pulsen das Phänomen am größten ist, also wird es höchstwahrescheinlich an der Protokollzeit liegen (3x 2ms Einlesen und dann innerhalb 14ms das Protokoll senden wird knapp).
Zu deinem Entwurf: Was meinst du mit PPM-Impuls? Wenn ich dich richtig verstanden habe: -Normal werden nur die Servos übertragen -Ändert sich der Status einer Licht-/Schaltfunktion, wird nur das Lichtprotokoll geschickt?
Wenn ja: dann sehe ich ein Problem: Ich kann ja nicht wissen, ob der Empfänger das Protokoll richtig aufgenommen hat. Würde nur einmal das Lichtprotokoll geschickt werden, und genau das liest der Empfänger fehlerhaft ein, dann werden die Funktionen nicht übernommen.
Ich habe auch schon Tests mit schnellerer Übertragung durchgeführt. Bei der schnelleren Rate hatte ich immense Probleme. Hier muss ich nochmal genauer auf das Protokoll schauen, an welcher Stelle der Empfänger aussteigt. Mehr kann ich dazu leider noch nicht sagen.
Weiterhin ist die Latenzzeit für den Blinker schon allein dadurch minimal geworden, dass der Sender den Blinker erst unmittelbar vor dem Senden des Protokolls setzt. Das hat augenscheinlich einiges ausgemacht.
Zur Flexibilität des Protokolls: Da ich den Empfänger mit einer Fehlererkennung ausgestattet habe, meckert er noch rum, wenn vor Erhalt aller geforderten Datenbytes ein EOF kommt. Bis jetzt will er pro Übertragung 5 Bytes haben. Prüfe ich das nicht, habe ich die Befürchtung, dass er bei einer kleinen Übertragungsschwierigkeit komplett durcheinander kommt.
Das ganze ist gerade schwer in Worte zu fassen, vielleicht bekomm ich das auch mal als Bild hin.
Vielen Dank aber für die Hinweise, ich mach mich mal weitere Tests.
EDIT Der nächste Test wird mal sein, nur 2 Servokanäle pulsgenau zu übertragen. Vielleicht schafft das Abhilfe.
Viele Grüße
Steffen
EDIT: @Nils
Die partielle Übertragung benötigt aber doch vor allem mal eine Erkennung, was ich gerade übertrage. Klar weiß der Empfänger, was der letzte Stand war. Aber wenn dann der Sender irgendein Byte überträgt, woher soll dann der Empfänger wissen, wo er die Daten einordnen soll?
Funk scheidet definitiv aus. Das Problem dabei ist die Kopplung zwischen Sender und Empfänger, die bei RF definitiv eine ID benötigt, bei IR ist das schlicht und ergreifend durch die Reichweite gegeben. So kann man dann ganz einfach mit einem Zugfahrzeug zwischen mehreren Anhängern wechseln, ohne erst auf einen gegenseitigen ID-Austausch warten zu müssen.
Und zwei Transmissionsstrecken denke ich sind zu störanfällig, besonders bei Kurvenfahrten und Kuppen
naja, Du müsstest im Protokoll pro Paket oder Block die Adresse angeben. Also: {Startsignal}{Adresse 1-18}{Wert}[{Adresse 1-18}{Wert}]...[Endesignal] Wenn Du für die Adresse fünf Bit verwendest, hättest Du noch ein paar Werte für Sonderaufgaben übrig, so wäre z.B. abschließend immer die Adresse 31 für eine Prüfsumme hilfreich.
Steffen tuts auch ;) Spaß beiseite. Das löst leider nicht die Problematik mit dem Zeitgefüge und der Sender-Empfänger-Kompatibilität. Außerdem benötige ich alleine für das Senden deutlich mehr Zeit. Bei der LED sag ich an/aus. Beim RF-/Bluetooth-System muss ich da unter Umständen Umwege gehen, was dann wieder auf Kosten der Zeit geht.
Der letzte Beitrag bezog sich auf LED-Übertragung, wobei das System ja mit jeder Übertragung verwendet werden könnte. Die Frage ist doch, ob sich die Aufteilung der Daten in Adresse und Wert lohnt. Wieviele geänderte Signale würdest Du gleichzeitig übertragen? Wenn es viele sind, schätze ich mal drei, mit Blinker und Warnlichter fünf... wie gesagt, geschätzte Änderungen zu einem Übertragungszeitpunkt...
Evtl. könnte man hier auch mit x festen Adressen und y variablen arbeiten? Das ist halt alles ein wenig aufwendig mit der Analyse, aber ich denke, es lohnt sich. Un wenn später rauskommt, dass Dein System stabiler und schneller ist, weiß man wenigstens, dass ein anderes Protokoll aus bestimmten Gründen nichts bringt.
so wie es aussieht kann ich hier nicht wirklich weiter helfen solange mir kein Testaufbau zur Verfügung steht. Da werde ich wohl doch etwas aktiver werden müssen und die Software für meine Elektronikbausteine parallel zu Deiner Entwicklung erstellen, so dass ich Deine Probleme live vor Ort nachvollziehen kann. Dennoch, hier ein paar Dinge die mir beim Lesen Deines Posts so einfielen:
- Probleme bei schnellerer Übertragung? Das muss nicht unbedingt an Deiner Software liegen. Auf der Suche nach einem Fototransistor fiel mir auf, dass einige Fototransistoren eine recht hohe Rise / Fall-Time (>40µs) haben. Je nach dem von Dir verwendeten Fototransistor kann hier die Ursache liegen.
- 14ms + 3 x 2ms werden nur dann zum Problem, wenn das Programm alle Phasen sequenziell arbeitet. An Deiner Stelle würde ich die Servo-PWM über eine Interrupt-Serviceroutine abhandeln, und im Hauptprogramm den IR-Datenempfang abwickeln. Denn 10µs Längenabweichung machen bei der IR-Erfassung wenig aus, und da der Interruptaufruf immer gleich lange dauert kannst Du diese Zeit beim Start des Servo-Pulses entsprechend subtrahieren. Einfach den 16bit Timer mit
65535 – ServoZeit – InterruptAufrufZyklen
laden und den ServoPIN = 1 setzen. In der ISR werden dann nur alle ServoPINs rückgesetzt und ein Flag-Bit gesetzt, über das das Hauptprogramm dann den nächsten Servoimpuls starten kann. Eventuell solltest Du dem C-Compiler noch für die ISR das automatische Speichern der CPU-Register verbieten und den Befehl selbst programmieren, denn ich musste schon Mal mit Entsetzten feststellen, dass der C-Compiler vorsorglich nicht nur die paar CPU-Register in die Shadow-Register sicherte, sondern auch noch alle anderen 12 Special-Function-Register manuell gesichert wurden. Ganz toll… 2 x 24 Taktzyklen verheizt.
Ach ja: PPM-Impuls… Falsche Seite des Empfängers, das war Mal bei Prä-2.4GHz Sendern zum Trennen der Kanaldaten. Gemeint war die Servo-PWM.
@Nils:
Die Idee mit dem Array und nur bei Änderung neu Übertragen ist nicht schlecht. Wenn gar keine Daten zu übertragen sind wäre hier ein Heartbeat erforderlich, z.B. SoF +EoF ohne Datenbyte, weil sonst der Empfänger nicht weiß ob noch ein Sender da ist und auf Stand By gehen sollte. Werde ich bei Gelegenheit antesten.
Den anderen Vorschlägen – zwei LEDs und Funk – stehe auch ich weniger begeistert gegenüber. Einzig die Verwendung einer einzigen IR-LED in Verbindung mit einem 56kHz IR-Empfänger (vgl. TSOP75256 / TSOP37256) würde mich reizen, um Probleme durch die Sonne / Fremdlicht zu vermeiden. Schade, dass die 455kHz Empfänger nicht mehr angeboten werden.
Was ich mir noch überlegt hatte war eine Elektro-Magnetische Übertragung per SMD-Spule und Hall-Sensor. Da wäre die Umsetzung halt aufwendiger als bei IR, aber dafür spielt das Sonnenlicht keine Rolle. Nur: E-Motor = Magnetfeld.
So, genug getippt. Hier wartet ein PKW-Chassis (jetzt mit Anhängerkupplung) auf sein Gehäuse mit vielen LEDs und einer IR-LED.
nachdem ich ja schon in meinem Beitrag zum Actros-Goldhofer-Gespann berichtet habe, dass die IR-Übertragung nun soweit praxistauglich ist, möchte ich hier nochmal genauer darauf eingehen.
Die Übertragung läuft nun so ab, dass die Information in der Pulsweite steckt. Ich habe einen Aufbau gewählt, der mit Start-/Restart-/Stop-Bits arbeitet, sodass die Übertragung eine gewisse Datensicherung enthält. Gleichzeitig könenn auch Frames mit mehreren Bytes geschickt werden. Die einzelnen Bit-Positionen sind determiniert. So kann ich gewährleisten, dass eine Zugmaschine mehrere verschiedene Anhänger ankuppeln kann und die Lichtfunktionen auch bei unterschiedlichen Funktionen des Anhängers funktionieren. Ich habe nun folgende Funktionen fest eingebaut:
Blinker rechts/links/warn (Bit gesetzt = LED an) Fahrlicht (Bit gesetzt = Fahrlicht aktiviert) Bremslicht (Über den Licht-Ausgang des ZM-Fahrreglers) (Bit gesetzt = LED an) Rückfahrscheinwerfer (Über den Licht-Ausgang des ZM-Fahrreglers) (Bit gesetzt = LED an) Blinklicht (Bit gesetzt = Blinklicht aktiviert: So kann das zugfahrzeug auch ein anderes Blinkmuster als der Anhänger haben)
RC-Ausgang 1 (2 Bits --> 4 Funktionen/Positionen) Dabei kann der Anhänger individuell konfiguriert werden. So sind zum Beispiel mehrere Servopositionen möglich (z.B. links/Mitte/rechts), die entweder fließend ineinander übergehen (je nach gesetzten Bits) oder direkt umschalten (Gut für Motorregler geeignet). Die Bits werden vom Empfängerbaustein geprüft und je nach Konfiguration ein Servo-Impuls variabler Dauer erzeugt.
Ein Beispiel: Anhänger mit Stützen Über Tastauswahl werden die Bits so konfiguriert, dass zwei Positionen möglich sind (Stützen hoch fahren/runter fahren/Halt). Beim Bitmuster für "Stützen hoch fahren" erzeugt der Empfängerbaustein ein Signal, dass das Servo langsam von der momentanen Position in die Endposition der Stützen fährt. Sind die Bits für "Stützen halt" gesetzt, wird die Bewegung sofort angehalten.
Weiteres Beispiel: Motor für Kippanhänger mit Seilzug Wie oben gibt es drei "Symbole": Kipper auf, Kipper ab, Kipper halt. Hier werden die Servosignale so erzeugt, dass 3 feste Servoimpulse erzeugt werden, die je nach gesetzten Bits den Servopositionen Linksausschlag, Rechtsausschlag und Mitte entsprechen. So kann der Motorregler die Zustände Motor rechtsdrehend, Motor halt und Motor linksdrehend erzeugen.
Theoretisch gibt es auch die Möglichkeit, das Signal eines RC-Kanals vollständiog zu übertragen. Momentan tüftel ich noch am Auslesen der Pulsweite, mache aber große Fortschritte.
Ein weiterer Punkt, den ich in den letzten Wochen angepackt habe, ist eine neue Hardware. Ich habe einen Controller für die Core-Version verwendet, der acht (Zugmaschinen-Version) bzw. elf (Anhänger-Version) Ausgänge für Licht-/Schalt-/RC-funktionen besitzt. Davon müssen die grundsätzlichen Lichtaus-/eingänge abgezogen werden (Blinker, Fahrlicht, Bremslicht und Rückfahrscheinwerfer abgezogen werden.
Die Platine selbst ist ca. 8 x 8 mm groß. Hier drei Bilder von den ersten Lötansätzen und fertigen Platinen:
Das Löten gestaltete sich anfangs etwas kompliziert, jetzt habe ich aber den Dreh raus und die Ergebnisse überzeugen. Die größere Version ist in meinem TU3 verbaut. Da habe ich einfach besser die Möglichkeit, die Programmierschnittstelle anzulöten.
Ich habe schon neue Pläne für eine erweiterte Platine, die den Vorwiderstand für die IR-LED und einen Verstärker für den Phototransistor schon onboard hat. Bis diese dann gefertigt ist, dauert es aber zeitbedingt noch etwas...
Bis dahin bin ich gespannt, was die Beta-Tests ergeben und tüftel weiter an den zahlreichen Ideen.
vielen Dank. Durch meine Heißluftlötstation konnte ich das Löten nun deutlich erleichtern. Das macht schon richtig Spaß mit der Schablone und Lötpaste :)
Ich hoffe, dass ich bis Sinsheim (zweites Wochenende) ein paar Kombis fertig habe, damit auch zeitnah Testergebnisse kommen.
ja ich bin dabei =) Leider hat das Getriebe vom Actros einen Schaden, den ich nicht ohne weiteres beheben kann (irgendwie hat sich das Zahnrad von der Welle gelöst und dreht durch... Aber ohne Reifen fährt er, sodass Tests möglich sind.
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Mikromodell-Chat
4
Offline
Falsche Seite des Empfängers, das war Mal bei Prä-2.4GHz Sendern zum Trennen der Kanaldaten. Gemeint war die Servo-PWM.
) würde mich reizen, um Probleme durch die Sonne / Fremdlicht zu vermeiden.
