OpenLRS mit 434Mhz Long Range System
- Themenstarter Rangarid
- Beginndatum
- Status
na dann viel Glück ^^
bin mal sehr gespannt
ich hab jedenfalls mein Geld zurück verlangt und kann auch keinem empfehlen damit ein Flugobjekt zu steuern, das System ist meiner Meinung nach nicht zuende gedacht und zu unsicher, es kann einfach nicht sein, dass ein Empfänger mit 2 dicken Servos und etwas geknüppel, einfach dicht macht, was zwangsläufig zum Absturz führen würde, nicht mal Failsafe mit anschliessendem RTH (sofern vorhanden) hätte da einen Sinn, da der RX ja nix mehr vom Sender wissen will...
zurecht :dodgy: wenn es unsicher ist, hat es nix im Flugbetrieb zu suchen, ganz einfach...
und wir haben ja echt viel rumgetestet, aber willkürliche Zuckungen und RX-Abdankung durch Spannungseinbrüche sprechen eigendlich für sich, oder?
bin mal sehr gespannt
ich hab jedenfalls mein Geld zurück verlangt und kann auch keinem empfehlen damit ein Flugobjekt zu steuern, das System ist meiner Meinung nach nicht zuende gedacht und zu unsicher, es kann einfach nicht sein, dass ein Empfänger mit 2 dicken Servos und etwas geknüppel, einfach dicht macht, was zwangsläufig zum Absturz führen würde, nicht mal Failsafe mit anschliessendem RTH (sofern vorhanden) hätte da einen Sinn, da der RX ja nix mehr vom Sender wissen will...
zurecht :dodgy: wenn es unsicher ist, hat es nix im Flugbetrieb zu suchen, ganz einfach...
und wir haben ja echt viel rumgetestet, aber willkürliche Zuckungen und RX-Abdankung durch Spannungseinbrüche sprechen eigendlich für sich, oder?
Wohl leider nicht die passende 
Jedenfalls kommt standardmässig leider kein Signal an. Habe das Signal von Kanal 1 und 3 überbrückt für Summensignal, was er auch beim Start mit 2maligem Blinken bestätigt. Aber leider kommt das Empfängersignal nicht an. Dann muss ich wohl doch zuerst mal in den Code schauen...
Jedenfalls kommt standardmässig leider kein Signal an. Habe das Signal von Kanal 1 und 3 überbrückt für Summensignal, was er auch beim Start mit 2maligem Blinken bestätigt. Aber leider kommt das Empfängersignal nicht an. Dann muss ich wohl doch zuerst mal in den Code schauen...Hi,
wollte mal was zum Servozucken sagen:
Für das Zucken gibt es ja generell nur 4 mögliche Ursachen:
Da mir die Sourcen noch nicht komplett angesehen habe (bisher nur die des TX), kann ich noch nichts wirklich ausschließen...
1. beim Einlesen des PPM Summensignals am Empfänger gibt es ab und an Störungen oder der µC im Sender hat intern in der Software ein Timingproblem, so dass falsche Kanalwerte angenommen/ermittelt werden. Diese gehen dann folglich in den restlichen Datenweg ein. Zum Prüfen könnte man am Sender die ermittelten Kanalwerte seriell ausgeben, am PC mitloggen und hinterher die Daten auf Unregelmäßigkeiten untersuchen.
2. es gibt eine Verfälschung des Datenpaketes auf dem Übertragungskanal. Das sollte erkannt werden, wenn die CRC Prüfsumme aktiviert ist.
3. der Empfänger "verschluckt" sich bei der Ausgabe der Einzelkanäle, weil 2 Interrupts gleichzeitig kommen oder irgendetwas am Timing nicht stimmt.
4. der Empfänger schaltet bei Übertragungsproblemen einzelne Kanäle ganz kurz auf Failsave (k.A. ob das von der Empfängersorfware her überhaupt möglich ist).
Da das Zucken ja wohl weg ist, wenn der Empfänger ohne Sender rumliegt - er also immer Failsave macht, kann es doch eigentlich nur Punkt 1 oder 4 sein, oder interne Timingprobleme im Empfänger, die von der Betriebsart(Normal/Failsave) abhängig sind.
Da ich mir in den nächsten Tagen aus völlig anderen Gründen den Code komplett anschauen werde, halte ich mal die Augen offen...
Gruß, StompSC
wollte mal was zum Servozucken sagen:
Für das Zucken gibt es ja generell nur 4 mögliche Ursachen:
Da mir die Sourcen noch nicht komplett angesehen habe (bisher nur die des TX), kann ich noch nichts wirklich ausschließen...
1. beim Einlesen des PPM Summensignals am Empfänger gibt es ab und an Störungen oder der µC im Sender hat intern in der Software ein Timingproblem, so dass falsche Kanalwerte angenommen/ermittelt werden. Diese gehen dann folglich in den restlichen Datenweg ein. Zum Prüfen könnte man am Sender die ermittelten Kanalwerte seriell ausgeben, am PC mitloggen und hinterher die Daten auf Unregelmäßigkeiten untersuchen.
2. es gibt eine Verfälschung des Datenpaketes auf dem Übertragungskanal. Das sollte erkannt werden, wenn die CRC Prüfsumme aktiviert ist.
3. der Empfänger "verschluckt" sich bei der Ausgabe der Einzelkanäle, weil 2 Interrupts gleichzeitig kommen oder irgendetwas am Timing nicht stimmt.
4. der Empfänger schaltet bei Übertragungsproblemen einzelne Kanäle ganz kurz auf Failsave (k.A. ob das von der Empfängersorfware her überhaupt möglich ist).
Da das Zucken ja wohl weg ist, wenn der Empfänger ohne Sender rumliegt - er also immer Failsave macht, kann es doch eigentlich nur Punkt 1 oder 4 sein, oder interne Timingprobleme im Empfänger, die von der Betriebsart(Normal/Failsave) abhängig sind.
Da ich mir in den nächsten Tagen aus völlig anderen Gründen den Code komplett anschauen werde, halte ich mal die Augen offen...
Gruß, StompSC
So, ich konnte den Sender jetzt dazu bringen, mit dem Empfänger zu sprechen Allerdings ist mir beim ersten Funktionstest mit dem Summensignal gleich aufgefallen, dass beim Gas geben der Gaswert schwankt. Dann hab ich das Ganze an den PC angeschlossen und im Plejad PC-Tool anzeigen lassen. Das Ergebnis:
http://www.youtube.com/watch?v=o3f-3a29Ds4
Das scheint mir auch die Ursache von Eurem Problem mit dem Servozucken zu sein, oder nicht?
Allerdings ist mir beim ersten Funktionstest mit dem Summensignal gleich aufgefallen, dass beim Gas geben der Gaswert schwankt. Dann hab ich das Ganze an den PC angeschlossen und im Plejad PC-Tool anzeigen lassen. Das Ergebnis:http://www.youtube.com/watch?v=o3f-3a29Ds4
Das scheint mir auch die Ursache von Eurem Problem mit dem Servozucken zu sein, oder nicht?
Ich kenne weder den uP noch seine Registerbehandlung. Üblicherweise gibt es einen Outputpuffer. Dorthin lege ich meinen neuen Wert. Dann wird dieser in das Register geschoben. Dabei macht man eine fortlaufende Abfrage, ob der Wert dort angekommen ist. Dann erst darf der nächste Wert in den Puffer, usw.
Häufiger Fehler ist, der Wert der Outputregister wird ausgelesen und mit dem neuen Wert verrechnet. War der alter Wert aber noch nicht vollständig ins Register übertragen, wurde dort nur Mist gefunden und weiterverrechnet.
Häufiger Fehler ist, der Wert der Outputregister wird ausgelesen und mit dem neuen Wert verrechnet. War der alter Wert aber noch nicht vollständig ins Register übertragen, wurde dort nur Mist gefunden und weiterverrechnet.
Ich habe ein Vermutung warum einige Servos zittern. Keine Ahnung ob das mittlerweile behoben wurde und ich die Merkwürdigkeit im Code einfach nur falsch interpretiere. Aber so wie ich den Code(ver. 1.10) verstehe, kommen die Pulse zwar mit 50Hz, sind aber nicht immer gleichmäßig verteilt. D.h. die Abstände zwischen den High-Flanken der Pulse sind nicht immer 20ms. Bei den hinteren Kanälen sollte sich dieses Problem noch stärker bemerkbar machen, besonders wenn man einen der vorderen Kanäle ändert. Kann das jemand mal versuchen? Also was an Kanal 8 anschliessen, Kanal 1 und 2 verändern und beobachten ob das Servo an Kanal 8 dann zittert.
Das Problem ist folgendes. In der Interrupt Routine wird pro Aufruf immer nur ein Kanal behandelt. Die Zeit bis diese Routine erneut aufgerufen wird entspricht dann dem Timing des Servos und wird jedes mal für das entsprechende Servo gesetzt. Das heisst aber auch, das sich die relative Position des Pulses, vom z.B. 5 Kanal, ändert wenn sich die Kanäle davor ändern. Das ist auf jeden Fall so, die Frage ist halt ob das die Ursache für das Servozucken ist. Deshalb wärs auch cool wenn das mal einer, wie oben beschrieben, Testen könnte.
Als Beispiel:
Kanal 1,2,3,4,5,6,7,8
Timing 1.5ms, 1ms, 1ms, 1ms, 1ms, 2ms, 1ms, 2ms
Der Code geht jetzt hin und ruft die ISR auf. Diese schaltet den Ausgang von 1 auf HIGH und setzt die Aufrufzeit für die ISR auf 1.5ms. Nach 1.5ms wird die ISR aufgerufen und 1 geht auf LOW. 2 geht auf HIGH und setzt die Zeit für den Aufruf auf 1ms. Das geht dann so weiter bis die Sache durchgelaufen ist. Nach dem letzten Durchlauf wird noch 9.5ms(20ms-10.5ms) gewartet bis wieder bei Kanal 1 angefangen wird. Angenommen wir ändern Kanal 1,2,3 und 4 auf 2ms, 1.5ms, 1.5ms und 2ms. Dann gehen wir wieder durch und erreichen Kanal 5 jetzt ganze 2.5ms später als vorher.
Wie gesagt, es kann sein das den Servos das egal ist, sicher bin ich mir da aber nicht.
EDIT:
Ich habe mal ein Programm geschrieben was dieses Verhalten simuliert. Das war dem Servo was ich verwendet habe selbst bei einer Abweichung von bis zu 7.5ms vollkommen egal.
Als Beispiel:
Kanal 1,2,3,4,5,6,7,8
Timing 1.5ms, 1ms, 1ms, 1ms, 1ms, 2ms, 1ms, 2ms
Der Code geht jetzt hin und ruft die ISR auf. Diese schaltet den Ausgang von 1 auf HIGH und setzt die Aufrufzeit für die ISR auf 1.5ms. Nach 1.5ms wird die ISR aufgerufen und 1 geht auf LOW. 2 geht auf HIGH und setzt die Zeit für den Aufruf auf 1ms. Das geht dann so weiter bis die Sache durchgelaufen ist. Nach dem letzten Durchlauf wird noch 9.5ms(20ms-10.5ms) gewartet bis wieder bei Kanal 1 angefangen wird. Angenommen wir ändern Kanal 1,2,3 und 4 auf 2ms, 1.5ms, 1.5ms und 2ms. Dann gehen wir wieder durch und erreichen Kanal 5 jetzt ganze 2.5ms später als vorher.
Wie gesagt, es kann sein das den Servos das egal ist, sicher bin ich mir da aber nicht.
EDIT:
Ich habe mal ein Programm geschrieben was dieses Verhalten simuliert. Das war dem Servo was ich verwendet habe selbst bei einer Abweichung von bis zu 7.5ms vollkommen egal.
Ich glaube auch nicht, dass das eine Rolle spielt.
Da das Servo nicht weiß, welche Impulse die Anderen bekommen und wann sein eigener Impuls kommt müsste es schon syncronisiert sein und selbst ein Timing durchführen um sich davon gestört zu fühlen.
Das machen vielleicht Servos die selber eingebaute Failsaves haben aber ich glaube dem größten Teil der Servos dürfte das völlig wurscht sein.
Da das Servo nicht weiß, welche Impulse die Anderen bekommen und wann sein eigener Impuls kommt müsste es schon syncronisiert sein und selbst ein Timing durchführen um sich davon gestört zu fühlen.
Das machen vielleicht Servos die selber eingebaute Failsaves haben aber ich glaube dem größten Teil der Servos dürfte das völlig wurscht sein.
- Status
