AbschlussEs gab heute eine Telco mit Robbe. Robbe kommuniziert mit Futaba zum R7003 seit das Thema hochkam.
Somit kann jetzt hier der finale Status festgestellt werden.
Es gibt eine
Ursache und einen
Anlass. Der Anlass brachte die Ursache zur
Wirkung.
Ursache ist das Design des Empfängers R7003, Anlass war VStabi.
UrsacheDer Empfänger R7003 betreibt im Gegensatz zu allen anderen bisherigen FASSTest Empfängern gewissermaßen ein Teil-Sharing der schaltungstechnischen Ressourcen für S.BUS(v1) und S.BUS2. Der Grund dafür ist offenbar, dass man ermöglichen wollte, mehrere Ports per Setup als S.BUS oder S.BUS2 definieren zu können, was ja geht.
Die Folge davon ist, dass der R7003 auch auf einem S.BUS-Port ein anderes Verhalten zeigt als andere Empfänger.
Der S.BUS ist ja unidirektional (one-way), der Empfänger sendet Servodaten in Paketen, die Servos lauschen und fischen sich ihre Daten aus dem zugewiesenen Slot im Paket. (nicht zu verwechseln mit Time Slots für Sensordaten auf dem S.BUS2)
Sprich, der Empfänger kann zwischen den Datenpaketen auf dem S.BUS serieller Sender bleiben, heißt, er zieht den Bus zwischen den Aussendungen aktiv auf LOW, mit geringer Impedanz (mit Schmackes).
Wegen der teilweisen Verheiratung des S.BUS mit dem S.BUS2 im Design beteiligter Komponenten im R7003 verhält sich ein als "S.BUS" definierter Port des R7003 so, als wäre auch der S.BUS bidirektional wie der S.BUS2. Natürlich sendet auch hier nur Einer, der Empfänger, aber zwischen seinen Aussendungen bringt der R7003 einen S.BUS-Port auch in den Tristate (Bus ist offen), so, wie man es auf dem S.BUS2 tun MUSS, denn man erwartet ja Aussendungen anderer Busteilnehmer, Sensoren usw.
Nun muss man, bevor sich der Kreis schließt, noch wissen, dass wir bei beiden Bussen im "physischen" Sinne von einem asynchron-seriellen Protokoll sprechen. Dieses Protokoll erfordert einen definierten Ruhepegel, den ein serieller Empfänger, also ALLE Teilnehmer, sehen muss, damit er den Start der nächsten Aussendung, von wem auch immer, verstehen kann. Dieser Ruhepegel ist eigentlich HIGH, - aber dadurch, dass S.BUS und S.BUS2 invertiert sind, hier LOW.
Im Klartext heißt das, es muss auf dem Bus jemanden geben (dieser Jemand ist der Empfänger, der Urknall), der auch im Tristate (offener Bus, keiner sendet) dafür sorgt, dass der Buspegel LOW ist.
Der R7003 tut das lt. Futaba nicht, er hat keinen Pulldown-Widerstand (gegen Masse), um den Bus am Floaten zu hindern.
Das ist schon mal ein Design Bug.
Hier muss auch erwähnt werden, dass BEIDE Bus-Typen auf Ports des R7003 keine Antifloatingmaßnahmen haben, - wen wundert's, die sind ja schaltungstechnisch im R7003 verheiratet. (Zumindest Futaba-Sensoren haben aber eine gewisse Pulldown-Wirkung, man muss nur einen Sackvoll davon dran haben.
)
Das heißt somit auch, egal, wo's schief geht mit dem Ruhepegel im Tristate, ob auf dem S.BUS oder auch auf dem S.BUS2, es wirkt auf den jeweils anderen Bustyp zurück, - aber nur seitens des R7003, innerlich bzgl. Verstehenkönnen auf dem S.BUS2, auf dem S.BUS gibt's nichts zu verstehen durch den Empfänger!
Damit sind wir beim
Anlass:
Unabhängig davon, dass der Empfänger irgendeine auf LOW ziehende Instanz haben MUSS für den Tristate-Fall, und der R7003 sie nicht oder in ungenügender Form hat, --> Jeder Busteilnehmer sollte sich tunlichst enthalten, irgendetwas in seinem Tristate (er ist auf Empfang) auf den Bus zu bringen, was dessen Pegel gegen HIGH ziehen kann. Also keinen Pullup-Widerstand gegen irgendeine positive Spannung (je höher, je schlimmer) und möglichst keine parasitären Pullups, die schaltungstechnisch im Teilnehmer irgendwie zustande kommen könnten.
Nun, wie gesagt, der Anlass war VStabi (Silverline, aber Futaba in Japan stellte dasselbe mit einem Mini fest), hier wirkt in irgendeiner Form ein Pullup, vermutlich irgendwas zwischen 50 und 100 kOhm gegen vermutlich 3V, - was den Ruhepegel auf dem S.BUS von LOW nach HIGH zieht, weshalb der R7003 beginnt, Bahnhof zu verstehen auf dem S.BUS2. - Auf dem S.BUS kann es aber auch dazu kommen unter ungünstigen Umständen! Hier entscheidet VStabi, ab wann es nichts mehr versteht, - aber nicht, wann andere S.BUS-Devices nicht mehr verstehen!
Nun.., siehe oben: Dass das überhaupt wirkt, von einem S.BUS-Device "VStabi" ausgehend, liegt daran, dass der R7003, und bisher nur der, den S.BUS in den Tristate bringt zwischen seinen eigenen Aussendungen, und dass das Ganze auf den S.BUS2 im Inneren des R7003 rückwirkt. Es gibt gar keine S.BUS-Spezifikation bzgl. der Anschaltung, die Uli beim Design des VStabi hätte verletzen können. Dass sein Pulläppchen plötzlich wirkt, liegt auch nur daran, das der R7003 eben nicht wie die anderen Empfänger den Ruhepegel des S.BUS aktiv (brachial) auf LOW zieht, sondern den Bus nun mal in die Luft hängt. Und dann noch, wie gesagt, ohne etwas gegen das Floaten des Busses zu tun (kein Pulldown). Ulis VStabi hat ergo leichtes Spiel. Na ja, und dass das dann auch noch auf den S.BUS2 rückwirkt, daran hat VStabi als S.BUS-Device natürlich im Design gar keine Aktie.
Was ist hier eigentlich passiert?Eigentlich nicht viel, aber, kleine Ursache, große Wirkung.
Der Designer des R7003 bei Futaba kam auf die dankenswerte Idee, den S.BUS oder S.BUS2 per Setup auf mehrere Ports des Empfänger legen zu können. Dafür machte es sich erforderlich, Komponenten im Rx zu sharen (k.A., wie/was konkret), und vor allem, den R7003 als seriellen Sender auf dem S.BUS nicht dauerhaft aktiv zu lassen, ihn zwischendurch den Bus freigeben zu lassen.
Es ist völlig üblich, weil vom Protokoll her häufig erforderlich, einen Bus, der neben LOW und HIGH auch Tristate kennt, nicht floaten zu lassen im Tristate, sondern sanft in eine Pegelecke zu ziehen, hier auf LOW, also durch einen Pulldown-Widerstand. Dann gilt: Andere Busteilnehmer müssen, wenn gerade aktiv (sendend) dann mit ihrem HIGH gegen diesen Widerstand noch lässig anstinken können. Dieser Widerstand soll zwar so klein als möglich, aber eben nicht zu klein sein. Außerdem: Gerade passive Busteilnehmer dürfen nur mit der und der "maximalen Force" HIGH auf den Bus einschleppen, damit der Pulldown noch seinen Zweck erfüllen kann.
Die S.BUS2-Spezifikation sagt bisher nichts zu diesem "parasitären HIGH" durch lauschende Busteilnehmer, sollte sie aber jetzt tun.
Eine S.BUS-Spezifikation gibt es in diesem Sinne erst gar nicht. S.BUS-Teilnehmer, wie VStabi, mussten sich nicht auf einen Tristate auf dem Bus einrichten. Sie konnten damit rechnen, dass es ziemlich schnuppe ist, ob sie ein versehentliches oder parasitäres HIGH auf den Bus schleppen als passive Teilnehmer, denn das erfolgt ja ziemlich hochohmig, - während sie davon ausgehen konnten, dass der Empfänger als ständig aktiver Busmaster des S.BUS das sowieso brachial mit seinem LOW platt macht.
Bingo! Und genau davon können sie beim R7003 nicht mehr ausgehen, - und genau damit hat der Designer des R7003 nicht gerechnet, als er sich ganz lässig entschloß, den S.BUS zwischendurch in den Tristate zu nehmen.
Dass er dann noch generell den Pulldown weggelassen hat, für S.BUS UND S.BUS2, hat seinen Irrtum sichtbar werden lassen, und zwar dadurch, dass sich die Ruhepegelverschiebung durch besagtes Component Sharing dann negativ auf die Lesefähigkeit auf dem S.BUS2 auswirkt, durch den Empfänger selbst. Trotzdem besteht die potentielle Gefahr, dass andere S.BUS-Teilnehmer dadurch auch nicht mehr den Empfänger lesen können, weil sie als Ruhepegel zwischen den Servodatenpaketen plötzlich HIGH sehen statt LOW.
Status, Wie weiter mit dem R7003?Der R7003 kann nicht modifiziert werden durch Futaba, im Layout der Platine ist offenbar auch gar kein Platz für einen Pulldown, also im Austausch gegen einen niederohmigeren. Die Entwickler werden noch mal drüber brüten, die Frage ist dann, ob es einen modifizierten R7003 geben wird oder gleich einen anderen Empfänger, - Letzteres, höchstwahrscheinlich. Die ausgelieferten R7003 können Futaba/Robbe NICHT modifizieren.
(Die S.BUS2-Spezifikation sollte erweitert werden, eine entsprechende Hardwarespezifikation für den S.BUS durch Futaba herausgegeben werden: ..Nämlich, dass ein Busteilnehmer keinen positiven Pegel in seinem Tristate (er auf Empfang) einzubringen hat. Die Limits (minimal akzeptable Impedanz im Verhältnis zur Quellspannung eines parasitären Pullups) sind in den Specs zu definieren.)
Nun, wie schlimm ist das?Es gibt bisher nur ein bekanntes S.BUS-Device, was den Effekt hervorrufen kann, die Ursache zur Wirkung bringt, VStabi, zumindest Silverline und Mini.
Die Wirkung ist zunächst nur, dass dann der S.BUS2 nicht mehr gelesen werden kann durch den R7003, ergo fällt die Telemetrie von Sensoren auf dem S.BUS2 aus, der ganze Bus fällt aus.
Auf VStabi auf dem S.BUS macht das bisher keinen Eindruck (kann den Empfänger noch einwandfrei seriell empfangen), und wird möglicherweise auch gar keinen machen können. Das kann nur Uli beurteilen (Pegelschema am Pin der MCU in VStabi).
Was allerdings absolut nicht auszuschließen ist, - dass andere S.BUS-Teilnehmer dann genauso Bahnhof verstehen wie der R7003 auf dem S.BUS2. Das hängt auch davon ab, ob solche S-BUS-Devices - unbewusst heilend, - effektiv, möglicherweise parasitär, Pulldown-Widerstände einbringen, wie es die Futaba-Sensoren auf dem S.BUS2 tun, wengleich vermutlich unbeabsichtigt.
Manche Threadtitel da draußen stressen das Wort "Bug" irgendwie im Sinne von "geht ja überhaupt nich".
Nun.., "Bug" ist ein hartes Wort, so abschließend. Das trifft es nicht ganz, man muss relativieren:
Solange kein Device auf dem S.BUS einen effektiven Pullup einschleppt, ist alles goldgelb.
Okay, man kann nicht riechen, welches Gerät das evtl. tut, bisher ist nur VStabi dafür bekannt, zumindest Silverline und Mini.
Man kann nun nicht von jedem Anwender verlangen, dass er das in seinem Setup vermittels eines Oszillographen überprüft, es ginge nur, als reine Gut-/Schlecht-Prüfung einen einzelnen Sensor auf den S.BUS2 zu packen und zu schauen, ob dessen Telemetriedaten noch kommen. Wie hart am Limit das ist, sieht man aber nicht ohne Oszi.
Daher der Tipp: Packt den besagten verträumten Widerstand auf den S.BUS, und Ihr könnt so gut wie sicher sein.
VStabi allein auf dem S.BUS mag überhaupt keine Unsicherheit involvieren, nur, dass der S.BUS2 eben dann versagen kann. Um die Sicherheitsfrage, VStabi allein auf dem S.BUS (Kevin allein zuhaus' 
) zu klären, reicht eine Anfrage bei Uli im VStabi-Forum. Nur Uli kann wissen, ob das VStabi selbst tangieren kann bzgl. seiner Lesefähigkeit auf dem S.BUS. Allerdings, auch die MCU im VStabi wird dem TTL-Pegelschema gehorchen, - geht der Ruhepegel des Busses hoch, kann sie sich sozusagen selbst das einwandfreie Lesen des Rx verbauen.
"Unsicherheit" kann auch entstehen, wenn ich Steuersignale auf dem S.BUS2 übertrage, Gyro an Heckservo, z.B. Vstabi auf dem S.BUS ohne Pulldown wird das unmöglich machen, aber das merke ich bereits vor dem Start.
Weitere Devices auf dem S.BUS sind natürlich genauso potentiell mit Blindheit bedroht durch so eine Pullup-Wirkung.
Will sagen: "Bug" und "geht nich" ist eigentlich nicht der Status, - "unsicher" schon, aber "Unsicherheit" beruht, abgesehen von VStabi, nur auf dem Nichtwissen um das Verhalten anderer S.BUS-Devices, ist also im Ausgangspunkt die "Unsicherheit" der "Möglichkeit, dass". Daher ja der eindringliche Hinweis, dass dieser lächerliche Widerstand das Ganze im Prinzip komplett aus der Welt schaffen kann. Es verbleibt nur noch eine sehr geringe Restwahrscheinlichkeit, dass ein S.BUS-Device dann immer noch zu brutal einen Pullup einschleppen könnte, also auch nicht kompensierbar durch einen hinreichend dimensionierten Pulldown. Dann kann man von "Bug" in aller Bestimmheit des Wortes sprechen, denn man kann so einem "ungünstig designten" S.BUS-Device das leider nicht vollständig anlasten. Man hat seitens Futaba bisher gar nichts zu dem Thema gesagt (effektive Pullup-Wirkung auf dem S.BUS), und dieses Versäumnis gestaltet sich eben über das Design eines S.BUS-Ports im R7003 dann ggf. tatsächlich zu einem Bug.
Viele Worte.., in der Hoffnung, das Relative in der Situation um den R7003 rüberbringen zu können. Heilung durch externe Mittel?Ja, ganz einfach!
Geht das Problem von einem S.BUS-Device aus (als Anlass, siehe VStabi), dann bringt man einen Pulldown-Widerstand ein, sagen wir mal, 5,6 kOhm (3,3 .. 8,2 kOhm). Also diesen Widerstand zwischen "Signal" und "Masse" an einem JR-Steckerverbinder auf dem S.BUS, and that's it.
(Ich werde mal mit Linus reden, ob er so einen Pulldown noch nachträglich in JSend reinferkeln kann.)
VStabi?Na ja, obwohl eigentlich nicht ursächlich schuld, sollte Uli doch mal gucken, woher sein effektiver Pullup rührt, und den möglichst in VStabi eliminieren.
Das hier final Dargestellte entspricht einem gemeinsamen Stand zur Sachlage, also synchron mit Robbe und Futaba.
Robbe will, hat möglicherweise inzwischen schon, auch mit Uli/Mikado dazu Kontakt aufnehmen.
So, Ende.
Ich schließe jetzt diesen Thread hier. Wer noch darüber diskutieren will, mache bitte dafür einen neuen Thread auf, der einen entsprechend passenden Titel hat.
Anmelden
Registrieren
FAQ
Suche
