Ausgangspunkt (Fehlererscheinungsbild):
Die Telemetrie von JLog2 als Multisensor auf dem S.BUS2 fällt aus im Terminal, hier T18MZ, sobald sich VStabi (Silverline) auf dem S.BUS-Anschluss des 7003 befindet.
Dasselbe Setup mit einem 7008 funktioniert.
So etwas wird nicht beobachtet, wenn sich statt VStabi ein CGY750 auf dem S.BUS befindet.
Ist VStabi schuld oder der 7003?
VStabi und 7008 geht. CGY750 und 7003 geht aber auch.
Es wurde festgestellt:
Der S.BUS-Ausgang des 7003 ist aus Watte, sehr hochimpedant, sprich, dessen Treiberleistung für Low (und vermutlich auch High) ist viel zu gering.
Wird der Signaleingang des VStabi-S.BUS-Anschlusses mit dem S.BUS-Ausgang des 7003 verbunden, kommt es zu einem Spannungsoffset. Der Impulspegel (positive Impulse) erreicht nicht mehr nahe Null Volt für Low, sondern nur noch minimal ca. 1,5V. Ist VStabi böse oder der 7003 ein Weichei?
Zum Beweis, dass die marginale Treiberleistung des 7003-Ausganges die Ursache ist, hat Dirk mit Pullup-Widerständen anstelle des VStabi experimentiert, also von Signalausgang S.BUS-7003 gegen Plus.
46kOhm: Offset == +1,5V (Telemetrie geht nicht)
68kOhm: Offset == +1,2V (Telemetrie geht nicht)
100kOhm: Offset == +1V (Telemetrie geht nicht)
147kOhm: Offset == +0,7V (Telemetrie geht!)
Na ja, also echt mal, ein TTL-Ausgang kann keine 147k auf Null ziehen?! So ein GPIO treibt immer 20..40mA! Da ist was oberfaul!
Der 7003 kann Sensoren auf dem S.BUS2 nicht mehr lesen, wenn der Offset auf dem S.BUS größer als 0,7V ist.
Nun fragt sich nur: Wie kann es zu einer Rückwirkung des S.BUS-Ausganges auf den S.BUS2-Port kommen?!
Sprächen wir nur über den S.BUS-Port, wäre meine glasklare Vermutung, dass es sich um einen Firmwarebug handelt, nämlich, dass der GPIO Pin des Microcontrollers im 7003 versehentlich als Input statt als Output betrieben wird. In diesem Falle bekommt man mit den meisten Prozessoren trotzdem noch Output vom Driver des Pins, während die Endstufe OFF ist. Nur kann so eine Konstellation nur sehr hochohmige Lasten treiben und dabei noch in den TTL-Schaltgrenzen bleiben.
Bloß: Wie kann das denn auf ein anderes GPIO-Pin, das für S.BUS2, rückwirken?
Bin ich mal ganz ketzerisch:
Fakt ist, dass alle relevanten Empfänger, 7008, 6308 und 7003, auf dem S.BUS die Servodatenpakete mit S.BUS2-Frame-Markierungen senden. Hey, wieso denn das?!
Tatsache ist auch, dass S.BUS und S.BUS2 gar nicht so inkompatibel zueinander sind, wie gerne Glauben gemacht wird:
Würden die Servodaten auf einem S.BUS nicht mit S.BUS2-Frame-Markierungen gesendet werden, würde ein S.BUS2-Sensor nicht mal senden, wenn er sauber implementiert wurde. Sendet man unverständlicherweise doch mit S.BUS2-Markierungen (s.o.), dann würde ein Sensor zwar senden und vermutlich auch mit dem als dauerhafter Sender betriebenen S.BUS-Empfängeranschluss pegelmäßig kollidieren, doch würde weder etwas dadurch kaputt gehen, noch würde es passive Busteilnehmer, Servos, Gyros auf dem S.BUS, irgendwie tangieren, wenn die wiederum sauber implementiert sind. Die würden die Aussendungen des S.BUS2-Devices einfach ignorieren, wenn sie sie überhaupt verstehen, weil Sender (Rx) auf Sender (S.BUS2-Device) arbeitet. Der Sensor würde in den Framepausen senden, wenn der Rx nicht sendet, in einem Format, was kein Servo verstünde.
Nun das Ketzerische: Was nun, wenn der Designer des 7003 den Hattrick wagte? Sprich, der sendende Pin des Microcontrollers für die beiden Anschlüsse S.BUS und S.BUS2 ist derselbe. Es könnte sogar komplett galvanisch intern derselbe Anschluss sein. Das ginge und hätte eigentlich keine Nachteile. Oder warum sendet man die Servodaten in S.BUS2-Frames auf dem S.BUS?
Vermutlich ist es aber eher eine "trickhafte passive Schaltung" im Inneren des 7003, die zu dieser eigentlich unmöglichen Verkopplung führt.
Der Softwarebug um den S.BUS-Ausgang wird aber on top bestehen und der eigentliche Auslöser sein.
Dirk, Du müsstest vielleicht noch mal den "Lasttest" mit dem S.BUS2-Anschluss des 7003 machen.
---------------
Ich halte es für gefährlich, den S.BUS des 7003 in diesem Zustand zu benutzen!
Dirk könnte nun Heilung durch 7003-externe Mittel suchen:
- Unseriös und auch haarig: Mit einem Serienwiderstand in der S.BUS-Signalleitung zwischen 7003 und VStabi, vermutlich so 50..100kOhm.
- Alternativ ein Versuch mit einem Pulldownwiderstand würde wahrscheinlich dieselbe Treiberschwäche des 7003, nur eben für High, offenbaren.
- Durch einen externen Driver, z.B. zwei NOR-Gatter eines C4001 in Reihe. Das wäre seriös.
Robbe hatte ich ja vorab informiert. Erste Antwort: Man gibt sich ungläubig..
Anbei ein paar Bilder, vergleiche auch die Bilder im Post oben. Man sieht, wie schwachmatisch-hochohmige Pullups bereits bewirken, dass der Ausgang des 7003 nicht mehr auf sauberen Low-Pegel kommt. -- Eines bitte beachten: Es gibt eine vorgeschriebene Schaltung seitens Futaba zur impedanzrichtigen Anschaltung, für S.BUS2, ob auch für S.BUS, weiß ich nicht. Danach kann die Ausgangsimpedanz im galvanischen Sinne nicht geringer als 220 Ohm sein. Na ja, 220 Ohm gegen 147 Kiloohm und immer noch +0,7V...
Diese Nadel gegen Null Volt scheint mir ein Indiz für einen Firmwarebug zu sein. Sprich: Na bitte, es geht doch, wenn man will.
Zum Vergleich auch der S.BUS-Ausgang des 7008, niederimpedant und unbeeindruckt.
Die Telemetrie von JLog2 als Multisensor auf dem S.BUS2 fällt aus im Terminal, hier T18MZ, sobald sich VStabi (Silverline) auf dem S.BUS-Anschluss des 7003 befindet.
Dasselbe Setup mit einem 7008 funktioniert.
So etwas wird nicht beobachtet, wenn sich statt VStabi ein CGY750 auf dem S.BUS befindet.
Ist VStabi schuld oder der 7003?
VStabi und 7008 geht. CGY750 und 7003 geht aber auch.
Es wurde festgestellt:
Der S.BUS-Ausgang des 7003 ist aus Watte, sehr hochimpedant, sprich, dessen Treiberleistung für Low (und vermutlich auch High) ist viel zu gering.
Wird der Signaleingang des VStabi-S.BUS-Anschlusses mit dem S.BUS-Ausgang des 7003 verbunden, kommt es zu einem Spannungsoffset. Der Impulspegel (positive Impulse) erreicht nicht mehr nahe Null Volt für Low, sondern nur noch minimal ca. 1,5V. Ist VStabi böse oder der 7003 ein Weichei?
Zum Beweis, dass die marginale Treiberleistung des 7003-Ausganges die Ursache ist, hat Dirk mit Pullup-Widerständen anstelle des VStabi experimentiert, also von Signalausgang S.BUS-7003 gegen Plus.
46kOhm: Offset == +1,5V (Telemetrie geht nicht)
68kOhm: Offset == +1,2V (Telemetrie geht nicht)
100kOhm: Offset == +1V (Telemetrie geht nicht)
147kOhm: Offset == +0,7V (Telemetrie geht!)
Na ja, also echt mal, ein TTL-Ausgang kann keine 147k auf Null ziehen?! So ein GPIO treibt immer 20..40mA! Da ist was oberfaul!
Der 7003 kann Sensoren auf dem S.BUS2 nicht mehr lesen, wenn der Offset auf dem S.BUS größer als 0,7V ist.
Nun fragt sich nur: Wie kann es zu einer Rückwirkung des S.BUS-Ausganges auf den S.BUS2-Port kommen?!
Sprächen wir nur über den S.BUS-Port, wäre meine glasklare Vermutung, dass es sich um einen Firmwarebug handelt, nämlich, dass der GPIO Pin des Microcontrollers im 7003 versehentlich als Input statt als Output betrieben wird. In diesem Falle bekommt man mit den meisten Prozessoren trotzdem noch Output vom Driver des Pins, während die Endstufe OFF ist. Nur kann so eine Konstellation nur sehr hochohmige Lasten treiben und dabei noch in den TTL-Schaltgrenzen bleiben.
Bloß: Wie kann das denn auf ein anderes GPIO-Pin, das für S.BUS2, rückwirken?
Bin ich mal ganz ketzerisch:
Fakt ist, dass alle relevanten Empfänger, 7008, 6308 und 7003, auf dem S.BUS die Servodatenpakete mit S.BUS2-Frame-Markierungen senden. Hey, wieso denn das?!
Tatsache ist auch, dass S.BUS und S.BUS2 gar nicht so inkompatibel zueinander sind, wie gerne Glauben gemacht wird:
Würden die Servodaten auf einem S.BUS nicht mit S.BUS2-Frame-Markierungen gesendet werden, würde ein S.BUS2-Sensor nicht mal senden, wenn er sauber implementiert wurde. Sendet man unverständlicherweise doch mit S.BUS2-Markierungen (s.o.), dann würde ein Sensor zwar senden und vermutlich auch mit dem als dauerhafter Sender betriebenen S.BUS-Empfängeranschluss pegelmäßig kollidieren, doch würde weder etwas dadurch kaputt gehen, noch würde es passive Busteilnehmer, Servos, Gyros auf dem S.BUS, irgendwie tangieren, wenn die wiederum sauber implementiert sind. Die würden die Aussendungen des S.BUS2-Devices einfach ignorieren, wenn sie sie überhaupt verstehen, weil Sender (Rx) auf Sender (S.BUS2-Device) arbeitet. Der Sensor würde in den Framepausen senden, wenn der Rx nicht sendet, in einem Format, was kein Servo verstünde.
Nun das Ketzerische: Was nun, wenn der Designer des 7003 den Hattrick wagte? Sprich, der sendende Pin des Microcontrollers für die beiden Anschlüsse S.BUS und S.BUS2 ist derselbe. Es könnte sogar komplett galvanisch intern derselbe Anschluss sein. Das ginge und hätte eigentlich keine Nachteile. Oder warum sendet man die Servodaten in S.BUS2-Frames auf dem S.BUS?
Vermutlich ist es aber eher eine "trickhafte passive Schaltung" im Inneren des 7003, die zu dieser eigentlich unmöglichen Verkopplung führt.
Der Softwarebug um den S.BUS-Ausgang wird aber on top bestehen und der eigentliche Auslöser sein.
Dirk, Du müsstest vielleicht noch mal den "Lasttest" mit dem S.BUS2-Anschluss des 7003 machen.
---------------
Ich halte es für gefährlich, den S.BUS des 7003 in diesem Zustand zu benutzen!
Dirk könnte nun Heilung durch 7003-externe Mittel suchen:
- Unseriös und auch haarig: Mit einem Serienwiderstand in der S.BUS-Signalleitung zwischen 7003 und VStabi, vermutlich so 50..100kOhm.
- Alternativ ein Versuch mit einem Pulldownwiderstand würde wahrscheinlich dieselbe Treiberschwäche des 7003, nur eben für High, offenbaren.
- Durch einen externen Driver, z.B. zwei NOR-Gatter eines C4001 in Reihe. Das wäre seriös.
Robbe hatte ich ja vorab informiert. Erste Antwort: Man gibt sich ungläubig..
Anbei ein paar Bilder, vergleiche auch die Bilder im Post oben. Man sieht, wie schwachmatisch-hochohmige Pullups bereits bewirken, dass der Ausgang des 7003 nicht mehr auf sauberen Low-Pegel kommt. -- Eines bitte beachten: Es gibt eine vorgeschriebene Schaltung seitens Futaba zur impedanzrichtigen Anschaltung, für S.BUS2, ob auch für S.BUS, weiß ich nicht. Danach kann die Ausgangsimpedanz im galvanischen Sinne nicht geringer als 220 Ohm sein. Na ja, 220 Ohm gegen 147 Kiloohm und immer noch +0,7V...
Diese Nadel gegen Null Volt scheint mir ein Indiz für einen Firmwarebug zu sein. Sprich: Na bitte, es geht doch, wenn man will.
Zum Vergleich auch der S.BUS-Ausgang des 7008, niederimpedant und unbeeindruckt.
Zuletzt bearbeitet von einem Moderator:
