Zitat von SteffKe im Beitrag #120Zum Bleistift: Statt drei Kanäle pulsgenau zu übertragen soll ein Übertragungskanal still gelegt werden, dafür ein Knüppel als 3-Pos-Schalter ausgewertet werden. Ist dieser in Neutralstellung, wird im LED-/Schalter-Byte 0-0 übertragen, bei Linksausschlag 1-0 und bei Rechtsausschlag 0-1. Im Empfänger kann das dann zum Beispiel für ein Servo-Output verwendet werden, der dann den Regler einer Rampensteuerung versorgt.
Hierzu ein Tipp: Prüfe nicht auf Vollausschlag, das kann evtl. bei manchen Funken ein Problem sein. Ich würde hier Bereiche für die drei Positionen festlegen, z.B. Links < 1250 us Rechts > 1750 us Mitte >= 1250 und <=1750 us, also der Rest.
Somit braucht man zum einen nicht den Vollausschlag des Knüppels / Schalters, zum anderen auch keine exakte Nullpunkterkennung
Mein altes Rennboot aus den 80ern hatte einen mechanischen Fahrtregler mit drei Positionen: Stopp, halbes Gas, volles Gas. :-) Also, keine Spannung, 14,4V und 28,8V
Sorry, das war mein Fehler, ich meinte nicht den Regler, sondern den Warnlicht Tiny Da ist es auch so. Das funktioniert prima. Ich kann es leider nur in Bascom zeigen. Hier ein kleiner Auszug aus dem Warnlicht Tiny ( Rundumlicht oder Blitzer ). Je nach Schalter Stellung.
1 2 3 4 5 6 7 8 9
Do Pulsein A , Pinb , 2 , 1 If A < 140 Then Gosub Blitz End If If A > 160 And A < 250 Then Gosub Rundumlicht End If Loop
nachdem Sinsheim einige neue Ideen und Tipps gebracht hat, habe ich heute endlich das Finale gewonnen. Nun können drei Servokanäle nahezu verzögerungsfrei und auf die Mikrosekunde genau übertragen werden.
plus 5 freie Bits, die individuell zugeordnet werden können.
Beispielsweise habe ich im Senderbaustein ein "Bagger-Tiny" (Je nach Anwendung auch "Kran-Tiny" oä) implementiert, dessen Zustand auch übertragen werden könnte.
Die Licht-Verzögerung, die sich nach der alten neuen Software von der Modelltech gezeigt hat, habe ich durch umstrukturieren des Protokolls auf ein Minimum beschränkt. Natürlich fällt es auf, wenn man im Abstand unter einem halben Meter 20 Zyklen beobachtet, aber ich denke, dass der momentane Stand einen Praxiseinsatz erlaubt.
Ich werde demnächst mal wieder Videomaterial aufnehmen, dann kann man es auch bewegt sehen.
Als nächster Punkt kommen noch eine Sicherheitsschaltung für Signalverlust, dass die angeschlossenen Servos im Empfänger trotzdem noch ihre Signale bekommen.
Sind die.Lichtfunktionen fix belegt, oder nur beispielhaft? Du könntest in den Sendebaustein auch eine Verzögerung (in der Größe der Signallaufzeit bis zum Empfängerausgang) dort angeschlossener Schaltfunktionen implementieren. Dann wäre kein Unterschied mehr vorhanden.
die Standard-Lichtfunktionen sind fix. Ich denke, jeder bzw. die meisten normalen Anhänger hat diese Lichtfunktionen eingebaut.
Für weitere Funktionen stehen ja noch die 5 freien Bits zur Verfügung, mit denen dann Sonderfunktionen (Ob Licht oder andere Funktionen ist dann wiederum frei wählbar) schaltbar sind.
Die Verzögerung kommt durch die Art und Weise, wie die Blinker angesteuert werden. Da ich von vorn herein bei den Blinker auf einen Quarzabhängigen Zähler verzichtet habe, da es dadurch zu noch größeren Unterschieden kommen würde, habe ich den Blinker direkt aufs Protokoll gelegt:
Blinker-Li-Bit 1 macht direkt den linken Blinker an Blinker-Li-Bit 0 macht direkt den linken Blinker aus
Blinker-Re-Bit 1 macht direkt den linken Blinker an Blinker-Re-Bit 0 macht direkt den linken Blinker aus
Daraus resultiert die Verzögerung, die durch das Protokoll vorgegeben ist (also ca. 20ms). Wenn du eine andere Idee für die Blinker-Übertragung hast, gerne äußern. Wenn ich aber sagen würde: Blinker auf Position links, dann würde der Sender deutlich früher anschalten, als der Empfänger (der ja nur links gesagt bekommt. Dann muss er sagen: Ok, rechte LED aus und linke LED an, aber nur wenn man in der richtigen Halbsekunden-Phase bin). Dann kann es aber sein, dass Zugfahrzeug und Anhänger "gegeneinander" blinken, oder vollkommen aus dem Rhythmus.
Bin gespannt, vielleicht habt ihr ja noch einen Lösungsvorschlag.
nachdem ich mich in Sinsheim ausgiebig mit Michael über alle möglichen technischen Aspekte des Systems unterhalten konnte, habe ich mich entschlossen, eine seiner Ideen aufzugreifen und anzupacken.
Die Idee ist ein Handsender. Eventuell wird später in der Software implementiert, dass einzelne Funktionen des Anhänger-Moduls konfigurierbar sein werden. Dazu sollte es die Möglichkeit geben, ohne Zugfahrzeug zu arbeiten.
Desweiteren würde ein Handsender die Möglichkeit bringen, den Anhänger gewissermaßen stand-alone zu betreiben. Zum Beispiel wenn die Rampen eines Tiefladers (z.B. Goldhofer TU3/4) ohne LKW zu senken (klar, in der Realität nicht ganz möglich, aber hier eventuell nützlich). Bei komplizierteren Modellen wie Anhäger mit Kranaufbauten könnten diese Sonderfunktionen auch separat gesteuert werden, sodass der LKW anderweitig einsetzbar ist.
Würde mich über Pro/Contra freuen. War bis jetzt nur so eine Idee, vielleicht aber auch vollkommener Humbuk ;)
wenn man die Latenzzeit in der Übertragung reduzieren will fallen mir eigentlich nur zwei Ansätze ein, die Du sicher auch schon in Erwägung gezogen hast: 1. 50% weniger Daten übertragen 2. Höhere (200%) Datenrate Beide Optionen würden erstmal dazu führen, dass man in den 22ms zwei Datenpakete übertragen bekommt, also die Latenzzeit auf 10ms sinkt. Dadurch steigt natürlich auch der Programmieraufwand, weil das Programm im Empfänger nun mehrere Dinge parallel erledigen muss. Nur welchen Weg sollte man nehmen? zu 1.: Weniger Daten = weniger Servos! Ist meiner Meinung nach nicht sinnvoll. zu 2.: Schon eher brauchbar.
Selbst würde ich keinen der beiden Wege gehen, sondern beide kombinieren. Und das in der Form, dass ich zwei verschiedene Telegramme vorsehen würde: - Ein Telegramm wäre das bereits von Dir in der Excel-Tabelle gezeigte mit allen 5 Datenbytes, das immer dann übertragen wird, wenn ein PPM-Impuls vom Empfänger erfasst wurde. - Telegramm Nummero zwo besteht nur aus dem ersten Datenbyte mit den Licht / Blinker- Informationen und wird immer dann übertragen, wenn KEIN PPM-Impuls anliegt UND sich einer der Eingänge geändert hat.
Das Ganze habe ich Mal eben in Excel eingetippt. Bitte nicht hauen, wenn ich einige Bits vertauscht haben sollte… IR-Datenübertragung.jpg - Bild entfernt (keine Rechte)
Für den Empfänger bedeutet dies in Kombination erstmal, dass die Empfangsroutine flexibler werden muss und nun auch mit kurzen Telegrammen klar kommen muss. Das sollte aber nicht allzu aufwendig sein, denn wenn der Empfänger nach den ersten Datenbyte ein End of Frame empfängt, dann wird die Nachricht halt als Kurznachricht interpretiert und nur die Lichtausgänge angesteuert. Damit bekommst Du die Möglichkeit in 50% der Fälle innerhalb von 1,8ms aktualisierte Blinkerdaten zu schalten. Und für den Fall, dass eine Zugmaschine (wie evtl. Sebastians Trabbi) gar keine Servodaten übertragen möchte, dann wird einfach kein Empfängerkanal angeschlossen und die Daten stehen immer innerhalb von 1,8ms am Empfänger zur Verfügung.
Schwieriger wird es für den Sender, denn mit den geänderten Timings kann man jetzt nicht mehr sofort nach dem Detektieren eines PPM-Impulses mit der Datenübertragung starten. Der Grund? Die Übertragung eines Bytes dauert mit 1,5ms jetzt weniger lange als ein solcher PPM-Impuls mit maximal 2ms dauern darf. Und wenn der Impuls noch nicht beendet ist, aber schon die Information übertragen werden soll...
Nun werden sicher ein paar Leute hier auf die Idee kommen, auch noch weitere Telegramme z.B. für nur einen PPM-Kanal haben zu wollen. Davon würde ich aber abraten, denn dazu müsste man den Sender auf die Anzahl der Kanäle programmieren. Ob sich dies lohnt scheint mir aber sehr fraglich.
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Mikromodell-Chat
0
Offline
Freue mich, das Ganze mal live zu sehen. Was du in Sinsheim dabei hattest war ja schon echt genial!
