J-Log.eu - Forum

1.April (aber leider kein Scherz ): Mal Zurück in die Zukunft, - Vorgriff:
Da Dirk vom Vstabi-Forum und von RCH hierher verlinkte, und die Meisten natürlich kaum die Nerven haben werden, das alles zu lesen..
(Der Punkt ist hier weder VStabi noch JLog, wie es ein verwendeter Thread-Titel suggerieren mag, der Punkt ist allgemeinerer Natur bzgl. des R7003. )
Was ist also die Quintessenz?
Die Quintessenz ist, dass davon abzuraten ist, den R7003 in seinem gegenwärtigen Zustand (Firmware) einzusetzen, jedenfalls, wenn man den S.BUS verwenden will, wofür ja dieser Rx im Wesentlichen gebaut wurde.
Grund ist, dass die Ausgangsimpedanz beider Bus-Ports, S.BUS und S.BUS2, viel zu hoch ist, daher kann kein vernüftiger Signal/Störabstand und somit keine Betriebssicherheit garantiert werden.
Die Tatsache, dass ein R7003 mit Eurem VStabi gehen mag, ist kein Indiz, schließlich ist das digital, - es geht solange, bis es plötzlich nicht mehr geht.
Eine vorbeifliegende Libelle mit Heuschnupfen könnte schon ausreichen.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Um mal über den Zwischenstand zu informieren:

Es ist keine Erdschleife. Sobald Signalverbindung S.BUS (v1) zwischen VStabi Silverline und 7003 besteht, setzt die Telemetrie aus. Irgendein Effekt zwischen 7003 und VStabi, denn mit einem CGY750 auf dem S.BUS gibt es diesen Effekt nicht, wie Rudi sagt.

Eigentlich ist das unmöglich..
- Der Rx kann gar nicht bemerken, ob jemand seinen S.BUS-Signalen lauscht oder nicht
- VStabi kann sich gar nicht bemerkbar machen, der Bus ist unidirektional Rx-->Device.

Dirk wird noch etwas mit seinen Möglichkeiten weitertesten..
- mal einen Serienwiderstand 1..3,3k in die S.BUS-Signalleitung zw. Rx und VStabi
- mal mit seinem Speicheroszi gucken, ob
a) der Pegel auf dem S.BUS durch das Anschließen des VStabi beeinflusst wird, ob mit angeschlossenem VStabi noch mehr zu sehen ist als nur die Frames des Rx
b) wie sich der S.BUS2 dabei verhält

Alles in allem sehr mystisch...

Anschlußweise:

- JLog2 steckt auf dem JSend
- JSend's JIVE-Anschluß am Diag-Anschluß des JIVE (Motorseite). Hier bekommen JSend und JLog ihre Betriebsspg. her, JLog empfängt die Daten des JIVE
- JSend's S.BUS2-Anschluß am Rx, nur Masse und Signal
- JIVE's Master am VStabi, JIVE bekommt Gasimpuls, VStabi bekommt Betriebsspg.
- VStabi am S.BUS des Rx. Hier bekommt auch der 7003 seine Betriebsspannung

Wie gesagt, alles ist schick auf dem S.BUS2, solange VStabi keine S.BUS-Signale sieht, man die gelbe Strippe der S.BUS-Verbindung 7003--VStabi rauszieht. Sobald raus, kommt die Telemetrie, sobald wieder drin (die Signalleitung, Masseverbindung stört nicht), fällt die Telemetrie aus. Es spielt dabei keine Rolle, ob der JIVE-Master im 7003 steckt (Port 3, --> Rx versorgt VStabi, Gas vom Rx) oder am VStabi (--> VStabi versorgt Rx, Gas von VStabi).

Irgendetwas lässt den S.BUS2 ausfallen (Dirk wird das noch oszillographieren, wie der S.BUS2 reagiert), sobald VStabi S.BUS-Signale sieht.
-> Da es mit einem CGY750 am S.BUS nicht solche Effekte gibt, muss mit VStabi etwas anders sein.
-> Da es mit einem 7008 und VStabi nicht diesen Effekt gibt, muss etwas mit dem 7003 anders sein.

Und eigentlich ist das protokollmäßig unmöglich...

......

----------------------------------------------------
Ich setze einfach hier fort:

Zunächst, was der Mitschnitt mit dem Logic Analyzer bereits zeigte, den SM machte (habe ja gerade keinen Sender, ohne einen Sender zu sehen, bleiben die Ports eines Empfängers statisch):
Auch der 7003 sendet wie der 7008 Datenpakete (Servokanaldaten) auf seinem S.BUS-Anschluss, die S.BUS2-Markierungen enthalten. Nun, das ist mMn zwar unschön, aber nicht störend für die S.BUS-Funktion.

Dirk hat nun teilweise oszillographiert, und zwar erst mal nur auf dem S.BUS:

Was man sehen kann, ist, dass der Ausgang des 7003 offenbar und erstaunlicherweise hochimpedant ist. Das VStabi-Silverline hat offenbar einen Pullup-Widerstand auf seinem Eingang (Wozu, die Impulse sind positiv?!), 2,4V unbelastet, aufgrund der hohen Impedanz des S.BUS-Ausganges des 7003 verschiebt sich die Nullage des Busses um ca. 1,5V in positiver Richtung.
Das muss nicht schlimm sein, VStabi versteht den 7003 ja immer noch, es verringert nur den Signalstörabstand in gefährlicher Weise.
Was man auch noch sieht: 7003 oder VStabi (muss noch ermittelt werden) reagiert auf die S.BUS2-Markierung der Datenpakete. Nach jedem vierten Paket gibt es einen Nadelimpuls gegen Null Volt. Das sieht man nur durch das Wirken des Pullups im VStabi, es könnte auch der 7003 selbst sein. Dirk wird das testen, indem er mal einen Pullup statt des VStabi anhängt. --> Ist es der 7003 selbst, kommt mir der Verdacht eines Bugs hoch: Wenn ich vergesse, einen GPIO-Pin eines Microcontrollers als Ausgang zu deklarieren, also den Pin als Ausgang benutze, obwohl er versehentlich als Eingang definiert ist, dann funktioniert der oft trotzdem als hochohmiger Ausgang über den Driver der Endstufe des GPIO-Pins.
Damit könnte es auch sein, dass VStabi gar keinen Pullup auf seinem S.BUS-Eingang hat, sondern nur dessen Leckstrom hier nullagenverschiebend wirkt. (Dirk, nimm also erst mal einen sehr hochohmigen Pullup, so was wie 100k oder mehr!). Dieser Nadelimpuls gegen Null Volt nach jedem vierten Paket (ein Zyklus eines S.BUS2 ist durch), wäre dann ein kurzes Definieren des Pins im 7003 als Output (Status ist Low), wonach er wieder per Bug zum Input deklariert wird.

Um's mal ganz klar zu sagen: Die Wirkung des VStabi-Einganges ist eindeutig sehr hochohmig, also nix Pullup. Der Ausgang des 7003 ist eindeutig auch sehr hochohmig, was nicht sein darf. Der Nadelimpuls nach jedem vierten Datenpaket wird mit 99%iger Wahrscheinlichkeit vom 7003 stammen (Dirk wird das feststellen per Pullup statt VStabi.), nämlich, wenn der Prozzi-Pin (GPIO == General Purpose Input Output) mal wirklich als Output deklariert ist, aber eben nicht lange.
Die Tatsache, dass S.BUS-Servodatenpakete S.BUS2-Markierungen enthalten, zusammen mit dem jetzt hier, spricht Bände: Der gute Entwickler tat das, was jeder Andere auch tun würde: Er nutzt die Source Sequence für den S.BUS2 und empfängt einfach nur nicht. Doch dabei hat er sich wohl einen Bug eingebaut: Einmal bzgl. der Markierungen (kann auch Absicht gewesen sein,bricht er aber seine eigene Protokolldefinition), zum Zweiten bzgl. der Sende-/Empfangsumschaltung, die er beim S.BUS2 braucht, beim S.BUS nicht, da ist er immer Sender. -- Teil 2 des vermutlichen Bugs gibt es offenbar nicht mit dem R7008.

Screenshots vom Oszi (von Dirk) attached.

Okay, wir hätten hier evtl. einen Bug in der Firmware des 7003 gefunden, relativ gefährlich für Anwender des S.BUS. Nun fragt sich noch, wie und vor allem warum sich das auf den S.BUS2 auswirkt.

Wird fortgesetzt...

Es hat sich bestätigt, der S.BUS-Ausgang des 7003 ist aus Watte, vermutlich ein Firmwarebug.
Ich fasse mal im nächsten Thread zusammen.

_________________
Tom

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.

_________________
Tom

Hier ist der Rest vom Schützenfest: http://www.futaba-forum.net/showthread.php?6295-T18MZ-Jive-JLog2-JSend-R7003SB-Telemetrie

Sehr unterhaltsam, zumindest, wenn man nicht weiß, wie man seine Zeit totschlagen soll.

_________________
Tom

So, hier nun die Fortsetzung:

Der andere Dirk, dvcam99, hatte ja die Idee, mal zu versuchen, JSend+JLog und VStabi beide an den S.BUS2 zu hängen. Das sollte dann gehen, wenn der S.BUS2-Anschluss nicht so hochohmig ist wie der S.BUS-Anschluss des R7003. Sicher, ist eigentlich nicht Sinn der Sache, ein S.BUS-Device (VStabi) auf den S.BUS2 zu hängen, sollte aber gehen, denn, wie von mir bereits mehrfach dargestellt, soo unterschiedlich sind die Busse ja gar nicht. Und die Aussendungen des JLog als Sensor sollte VStabi als S.BUS-Device ignorieren, wenn Uli sauber implementiert hat.

Es hätte theoretisch einen Grund geben können, weshalb VStabi nicht auf dem S.BUS2 hätte gehen könnte:
Die Servodatenpakete auf beiden Bussen sind zunächst identisch. Doch eigentlich haben die Pakete auf dem S.BUS keine CH18-Typ-Markierung und keine Adressmarkierung für Frames 1..4, in Byte 25 immer Null. Allerdings sendet zumindest der 7008 auf dem S.BUS auch mit CH18-Markierungen (Warum auch immer? Nicht protokollkonform.), und am R7008 funktioniert ja VStabi auch.
Inzwischen stellte sich heraus, dass ich SM mißverstanden hatte, er hatte ja den LA am Bus, nicht ich, weil gerade senderlos: Der R7003 sendet die Servodatenpakete auf dem S.BUS NICHT mit CH18-Markierungen, Byte 25 ist 0.
Also sollte VStabi auf dem S.BUS2 des R7003 zusammen mit JSend+JLog gehen, wenn dieser Anschluss nicht so eine ungewöhnlich hohe Impedanz als Signal-Source aufweist wie der S.BUS.

Und es geht.

Dirk (Blademaster) hat noch mal akribisch-systematisch gemessen, hier seine Ergebnisse.
Ich zitiere Dirk (Blademaster):

- Oben in gelb das Signal am SBUS1
- Unten in blau das Signal am SBUS2
- Das Massepotential wird durch den kleinen gelben/blauen Pfeil links am Rand des Rasters markiert, Y-Ablenkung 1V/Div.
(Der testweise Pullup geht von Signal des R7003 gegen +5,6V, die R/C-Spannung, hier der BEC-Output eines JIVE.)

Screenshots: VStabi-am-SBUS2
SBUS1: offen
SBUS2: Nur VStabi
VStabi funktioniert

Screenshots: VStabi+JSend-am-SBUS2
SBUS1: offen
SBUS2: VStabi + JSend
VStabi und JLog(Telemetrie) funktionieren

Screenshots: VStabi+JSend-am-SBUS2-147k-PullUp-SBUS1
SBUS1: 147 kOhm PullUp
SBUS2: VStabi + JSend
VStabi und JLog(Telemetrie) funktionieren

Screenshots: VStabi+JSend-am-SBUS2-47k-PullUp-SBUS1
SBUS1: 46,4 kOhm PullUp
SBUS2: VStabi + JSend
VStabi funktioniert
JLog(Telemetrie) funktioniert nicht

Der lastabhängige Offset am SBUS1 ist ja schon bekannt, interessant auch der Offset am SBUS2. Nur mit VStabi bei etwa 1,5V mit VStabi + JSend bei etwa 1,0V
Die „Last“ am SBUS1 verursacht dabei scheinbar keine Offsetänderung am SBUS2.

Was man sieht:

Der S.BUS2-Anschluss weist ebenfalls eine hohe Source-Impedanz auf, zumindest für Low, daher die Offsets durch vergleichsweise Pipifax-Pullups.
Die Schwelle "geht/geht nicht" ist aber etwas moderater, es geht noch mit JSend+JLog2 und VStabi auf dem S.BUS2, es geht auch noch mit 147k gegen +5,6V, es geht nicht mehr mit den bereits am S.BUS1 getesteten 47k. Die 68k und 100k hatte Dirk wohl am S.BUS2 hier nicht getestet.

Nun muss man, um es abzurunden, noch Folgendes wissen:

JSend ist in gewisser Weise "eine trickhafte Schaltung".
Die besteht absichtlich aus bipolaren Transistoren, sie ist damit stromgesteuert, kann spannungsgesteuert nicht funktionieren. Will sagen: Die Signal-Source, der Rx, darf eine bestimmte maximale Ausgangsimpedanz nicht überschreiten. Dieser Wert ist eigentlich völlig unkritisch, wenn man von üblichen TTL-Sourcen ausgeht, auch mit schlimmst-denkbaren Ausreißern Richtung hoher Ausgangsimpedanz. Auch die 220 Ohm in Serie zu beiden Teilnehmern, also 440 Ohm in Summe, sind dabei absolut vernachlässigbar. Erst dadurch, dass es in der Ersatzschaltung des R7003 als Signal-Source offenbar einen Serienwiderstand gibt, der multible 10k darstellt (siehe den Effekt beim Test mit den Pullups), könnte es dazu kommen, dass JSend nicht mehr funktionieren kann. Am 7003, - nicht am 7008 oder 6308.
Siehe Schaltung anbei.

Warum war die so erforderlich, warum geht es nicht hochohmig durch JLog und rein spannungsgesteuert?

Der S.BUS[2] ist invertiert, high-aktiv. Normalerweise ist eine asynchron-serielle Leitung low-aktiv. Eigentlich völlig unsinnig im Sinne von Störfestigkeit und Handhabbarkeit, dass Futaba das high-aktiv machte. Der Prozessor in JLog2 ist ein ATmega, dessen UARTs können nicht auf inversen Betrieb umgestellt werden. Man muss also extern invertieren, für den Rx-Pin und den Tx-Pin. (Ein Software-UART scheidet wg. der 100kBd aus.) Damit entfällt die sonst genutzte Möglichkeit, einfach beide Pins parallel zu schalten und einen Tristate (JLog ist passiv) dadurch zu erreichen, dass man den Tx abschaltet. Sprich, der externe Inverter am Tx-Pin muss einen Z-State kennen und dafür einen Steuereingang haben. Okay, es sollte aber kein Pin geopfert werden (wird gebraucht für einen Castle Creations ESC oder JLog-eigene Sensoren), um den Z-State des TX-Inverters per Software einzusteuern.

Daher die "trickhafte", absichtlich stromgesteuerte Schaltung, explizit stromgesteuert aber nur an der Seite zum JLog2 hin, nicht wirklich auf der S.BUS2-Seite. Die Schaltung macht einen "Auto-Z-State", - wenn der TX-Pin des Prozzis in JLog OFF ist, wird der Ausgang des JSend zum S.BUS2 hin eine "Kartoffel". Auf der S.BUS2-Seite ist es rein theoretisch natürlich doch stromgesteuert, sind ja bipolare Transis in JSend und keine FETs. Das ist aber vernachlässigbar, nur eben nicht, wenn die Signal-Source dramatisch hochohmig wird! (Natürlich hätte der Rx-Inverter auch mit einem FET gemacht werden können, also spannungsgesteuert, hielt ich aber nicht für erforderlich, ist es normalerweise auch nicht.)

-----

SM konnte es inzwischen auch nachvollziehen. Er sagt auch, dass der R7003 zurückgerufen werden sollte, bis die Ursache für die hohe Ausgangsimpedanz der beiden Bus-Anschlüsse gefunden und beseitigt ist.
Natürlich, wenn sich niemand auf den S.BUS hängt, allgemeiner formuliert, wenn niemand Steuersignale über einen der beiden Busse überträgt (also nur per Servoimpulse direkt aus dem Rx), kann das kein Anwendungsrisiko darstellen. Allerdings ist der R7003 dafür gemacht, dass man per S.BUS steuert..

-----

Ich denke, wir setzen hier jetzt erst mal einen Punkt.
Weiteres wäre zwar interessant, würde aber nichts an dem matschigen Zustand der Bus-Anschlüsse und damit an der praktischen Anwendbarkeit des R7003 ändern.
Außerdem, was mich betrifft, es gibt andere Sachen, mit denen ich meine Zeit verbrennen kann.

Falls das nicht klar rüberkam:
Ich jedenfalls würde davon abraten, den R7003 in diesem Zustand zu verwenden!
Ein S.BUS-Device könnte eigentlich jederzeit, unter gewissen ungünstigen Umständen, plötzlich nicht mehr verstehen. Und das sind ja Steuersignale, die dann flöten gehen...

_________________
Tom

Hier noch kurz mein Fazit,

da der R7003SB insbesondere am SBUS leistungsmäßig so gut wie gar nichts "treiben" kann und dazu eine nicht unerhebliche Rückwirkung auf den SBUS 2 besteht -wie kann das überhaupt sein, ist das so gedacht -, ist der R7003 für meine Anwendung schlicht weg unbrauchbar oder anders ausgedrückt, meine Helis sind mir für diesen Empfänger zu schade.

Lösung: R7008SB und fertig.

An dieser Stelle auch nochmal danke an Tom für die Bemühungen trotz der Feiertage.


Gruss,
Dirk

Es sieht doch so aus, als ob der Ausgangstreiber in den Übertragunsgpausen fälschlicherweise (bei SBus1) hochohmig wird. Beim 7008 ist der Bus sauber "abgeschlossen" und wird in den Sendepausen nach low gezogen. Beim 7003 hat man dies versäumt oder es passiert mit einem sehr hochohmigen Pull-down.

Der Logik-Pegel während der Übertragunsgphasen sieht dagegen doch ganz ordentlich aus.

D.h. das vStabi besitzt vermutlich einen Pull-up, der nun gegen den (übel hochohmigen) Pull-down des 7003 arbeitet. Der Pegel liegt in den Pausen dann irgendwo "in der Mitte". Das vStabi erkennt dann die Signalpausen nicht mehr und arbeitet nicht richtig.

Lange Rede kurzer Sinn: Vielleicht bekommt man das Verhalten in den Griff, wenn man den Bus mit einem "niederohmigen" Pull-Down (ca. 4k7 bis 10 kOhm) nach Masse zieht. Der Ausgangstreiber des 7003 sollte das locker ziehen.

Richtig elegant ist das nicht, könnte aber klappen. Oder habe ich da was nicht richtig erfasst ?

Grüße
Bernd

_________________
Grüße
Bernd

Ja, Bernd, man könnte so einige Schweinereien machen, um den Pegel zu ziehen, hatte ich ja auch bereits dargestellt. Ein Pulldown wäre natürlich ziemlich haarig, die Vermutung liegt auch nahe, dass die Driverleistung für High ebenso gering ist. Es wäre jedenfalls nicht wirklich betriebssicher, nicht seriös, nicht vervielfältigungsfähig.

Was ginge, wäre ein externer Driver am S.BUS, zwei NOR-Gatter eines 4001 in Serie, z.B., - aber, wer will das schon?

Ehrlich gesagt, mir ist das viel zu viel Brimbamborium um eine einfache Sache, Bugs kann es immer und bei jedem geben, kein Grund zur Aufregung, wenn dann beim Beheben nicht gemauert wird.. Ich gehe jedenfalls davon aus, dass es sich um einen billigen Softwarebug handelt.

Etwas Brisanz kommt nur dadurch in's Spiel, dass man sich genötigt fühlt, zu warnen, denn schließlich gehen hier die Steuersignale drüber, wenn man den S.BUS verwendet.

Natürlich kommen jetzt die Argumente: "Wieso denn, bei mir geht's doch?" Bei Rudi z.B. mit einem Futaba Speed Sensor auf dem S.BUS2 und einem CGY750 auf dem S.BUS. Die falsche Schlußfolgerung liegt dann nicht fern: "Mit Futaba-Komponenten gibt es keine Probleme."
Das wäre falsch! Das Potential für einen gefährlich miesen Signal/Störabstand ist grundsätzlich vorhanden. Nur ist das eben digital, bis hierher und bis eben ging's noch, und plötzlich nicht mehr. Das Plötzliche, unkalkulierbare weitere Faktoren der Leitungsführung, von Störsignalen auf der Masse, Einkopplung, etc.pp., lauert immer.

_________________
Tom

Ich gebe Dir recht Tom: Zum Rumbasteln ist die Sache zu haarig und letzten Endes ist es das Risiko nicht wert.

Dennoch: Gibt es denn wirklich einen Hinweis darauf, dass die Treiberleistung nicht passt ?

Die Oszi-Bilder sehen für mich so aus, als ob wir über einen fehlenden definierten Pegel innerhalb der Zeit sprechen, in der der Bus "tri-state" geschaltet wird also in der Zeit in der jemand anderes senden darf (was beim S-Bus1 prinzipiell Quatsch ist, weil da immer nur der Empfänger sendet. Wie Du schreibst, scheint da aber wohl was von der SBus2-Implementierung "rübergeschwappt" zu sein).

Ich bin wirklich gespannt, was robbe/Futaba dazu sagt (und ich fange auch nicht an zu unken, bis es so weit ist).

_________________
Grüße
Bernd

Robbe signalisierte, dass man sich der Sache annahm.

_________________
Tom

Chris11/Chrisii, ich wäre Dir dankbar, wenn Du nicht mit ungeschickten Zitaten meiner Aussagen, die im zeitlichen Verlauf einer Untersuchung mit sich allmählich verdichtenden Ergebnissen gemacht wurden, unterwegs wärest.

Bemühe Dich lieber, den Grundgehalt zu verstehen, und beschränke Dich auch in Zitaten auf die Grundfeststellungen.

Ein Grund ist u.A., dass Du sonst von diesen eher ablenkst. Ulis Antwort auf Dein Zitat im VStabi-Forum zeigt mir z.B., dass Uli nicht mitbekam, dass DIESER Empfänger eine wesentlich hochohmigere Quellimpedanz hat als die anderen, und es eben nicht so ist, dass alle Empfänger denselben Schutzmechanismus haben. Dieses "alle" beläuft sich nämlich auf ein paar hundert Ohm (ganz genau 220 Ohm), beim R7003 reden wir von Vielfachen von 10 Kiloohm, und das ist DER Unterschied.

Okay?

Danke.

_________________
Tom