Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden Impressum 
Sie können sich hier anmelden
Dieses Thema hat 145 Antworten
und wurde 9.243 mal aufgerufen
 Projekte
Seiten 1 | ... 4 | 5 | 6 | 7 | 8 | 9 | 10
derniwi Offline



Beiträge: 432

14.03.2016 12:24
#121 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Zitat von SteffKe im Beitrag #120
Zum 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

SteffKe Offline




Beiträge: 202

14.03.2016 12:25
#122 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Hallo Nils,

genau so habe ich das implementiert ;) Klar, ich kann nicht auf Gleichheit von 1ms /2ms überprüfen ;)

Gruß Steffen

Sven Löffler Offline

Admin


Beiträge: 3.502

14.03.2016 16:59
#123 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Genau so habe ich das auch bei meinem Fahrtregler gemacht.

SteffKe Offline




Beiträge: 202

14.03.2016 17:09
#124 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Hallo Sven,

das heißt der Regler hat dann nur 3 Fahrstufen (vor, zurück, stop)?

Gruß Steffen

Selbstfeiermeister Offline




Beiträge: 940

14.03.2016 17:46
#125 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Er meint wohl die Unterteilung in kleine Bereiche von vielleicht je 3 bis 5 Werte und um den 0-Punkt etwas mehr.

Gruß
Sebastian

SteffKe Offline




Beiträge: 202

14.03.2016 17:52
#126 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Ahhh, das macht natürlich Sinn =)

derniwi Offline



Beiträge: 432

14.03.2016 20:03
#127 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

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

Ging auch - irgendwie...

Sven Löffler Offline

Admin


Beiträge: 3.502

14.03.2016 21:05
#128 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

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
 

SteffKe Offline




Beiträge: 202

24.03.2016 14:51
#129 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Hallo miteinander,

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.

Dabei habe ich nun folgenden Funktionsumfang:

Servo 1
Servo 2
Servo 3

Fahrlicht
Bremslicht
Rückfahrlicht
Blinklicht
Blinker re/li

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.

Viele Grüße

Steffen

Selbstfeiermeister Offline




Beiträge: 940

24.03.2016 16:30
#130 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

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.

Gruß
Sebastian

SteffKe Offline




Beiträge: 202

24.03.2016 17:49
#131 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Hallo Sebastian

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.

Gruß Steffen

Sven Löffler Offline

Admin


Beiträge: 3.502

24.03.2016 18:23
#132 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Hallo Steffen,

da kann man dir ja nur gratulieren. Freue mich, das Ganze mal live zu sehen. Was du in Sinsheim dabei hattest war ja schon echt genial!

SteffKe Offline




Beiträge: 202

24.03.2016 19:13
#133 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Hallo Sven,

vielen Dank :) ich bin auch echt gespannt, ob es praxistauglich ist, aber das wird sich zeigen

Viele Grüße

Steffen

SteffKe Offline




Beiträge: 202

26.03.2016 16:36
#134 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Hallo miteinander,

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 ;)

Viele Grüße

Steffen

m-brilisauer Offline




Beiträge: 69

28.03.2016 15:28
#135 RE: IR-/Bus-Übertragung Sattelzug Zitat · Antworten

Hallo Steffen,

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…


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.

Viele Grüße
Michael

Seiten 1 | ... 4 | 5 | 6 | 7 | 8 | 9 | 10
 Sprung  

Xobor Forum Software von Xobor
Einfach ein eigenes Forum erstellen
Datenschutz