J-Log.eu - Forum

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-12-10T00:14:13+01:00

10.12.2013 Update

- Offenbar legt Robbe zwischenzeitlich seit geraumer Zeit dem Empfänger einen Pulldown mit Kabel/Stecker bei(?)

- Uli gefragt: Der äußerst schwache Pullup in den Vstabi-ZEs ist zwar tatsächlich der Auslöser, der den Bug im Hardware Design des Rx zur Wirkung bringt, der Pullup kann auch durch Firmwareänderung entfernt werden (hatten wir im Ergebnis positiv getestet, s.o.), - aber Uli sagt, er hielte es für den falschen Weg, weil es keine generelle Heilung wäre, - und damit hat er Recht. Ergo bleibt der Pullup drin in VS, Futaba ist am Zug.

- Inzwischen hatte man (Robbe[/Futaba?]) ein Modell des 7003 mit integriertem Pulldown getestet. Das Ergebnis kenne ich nicht, wahrscheinlich positiv.

Was ich nicht weiß: Ist dieser Mod nun serienmäßig im 7003? Wie erkennt man so eine Version?

(Falls nun jemand vorsichthalber immer 5,6kOhm Pulldown (Signal->Masse) auf die S.Busse des 7003 hängt, muss er eigentlich nichts befürchten, wenn er unbemerkt sich damit einem bereits vorhandenen internen Pulldown parallel schaltet.)

---------
16.12.13: Olaf meldete sich, es liegt doch kein Pulldown bei. Auch, wenn nur VS durch einen schwachen Pullup das Problem zur Erscheinung bringen kann: Ich würde diesen Rx NICHT ohne Pulldown verwenden, die Gefahr ist sonst latent vorhanden.

3.3.2014:
----------
Da gerade auf rc-heli.de so aus dem Zusammenhang zitiert wird:
Es gibt keine High-Schwäche auf S.Bus[2] Ports des 7003, nur für Low, daher ja der Pulldown.

Dieser Thread ist quasi das Protokoll einer "schöpferischen Untersuchung", Annahmen, Irrtümer, Erkenntnisse, - am Ende das Resultat. Im wesentlichen zwei Leute waren es, unter gelegentlicher Beteiligung anderer. Das einzig Besondere ist: Jeder konnte es mitlesen, jeder kann es von A bis Z immer wieder nachlesen.

Am Schluß zählt nur das Ergebnis, vorangegangene Irrungen und Wirrungen haben keinen Wert mehr.

Soll ich jetzt den Thread verschwinden lassen, nur das Ergebnis stehen lassen?
Also bitte, nicht aus dem Gekröse der Historie und ohne Zusammenhang zitieren. Allein zählende Aussagen sind die am Schluß, wie das nun mal immer so ist. Und da steht nun mal, die Erde ist rund, - das wir zwischendurch auch mal annahmen, sie sei eine Scheibe, da kräht kein Hahn mehr nach.

Und außerdem: Würde ich einen Pulldown empfehlen, wenn es eine High-Schwäche gäbe? Da muss man doch mal mitdenken.

Die Sache mit dem Pulldown ist bestimmt nicht elegant, ich glaube aber, dass sie hinreichend ist.

Statistik: Verfasst von dl7uae — 10. Dez 2013, 00:14

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-19T18:34:08+01:00

Das oben wurden ja doch recht viele Worte, ich habe mich als Karl Marx betätigt, der soll bis zu 127 Wiederholungen zur selben Sache in seinem 3-bändigen "Das Kapital" gehabt haben.

Also hier die Nutzungsanleitung bzgl. des R7003 für die Lesefaulen.
Ihr müsst den Empfänger nicht beiseite legen, wenn Ihr Folgendes beherzigt:

1. Habt Ihr VStabi auf dem S.BUS, dann packt einen Pulldown-Widerstand von 5,6kOhm irgendwo auf den Bus, zwischen "Signal" und "Masse". Und ehe jemand fragt: Nein, nicht das 0,5Watt-Monster, der muss worst case 5mW aushalten, also was Kleines, was man ohne Gynäkologenfinger gerade noch handhaben kann.

2. Habt Ihr ein S.BUS-Device, bei dem Ihr Euch nicht sicher seid, dann packt auch hier einen 5,6kOhm-Widerstand drauf. Ein Device, was hier Pullup-Wirkung einschleppt, stört keine steuerungsrelevanten S.BUS-Devices, wohl aber die Lesefähigkeit von Teilnehmern auf dem S.BUS2, einschließlich des Empfängers, und damit die Telemetrie, - sowie Steuersignale auf dem S.BUS2, z.B. Gyro direkt an Heckservo.

3. Um sicher zu sein, ist es einfach die beste Lösung, generell den Widerstand auf den S.BUS zu tun.

Alles klaro?
Guten Flug!

-----------------------------
VStabi:
Uli hat tatsächlich einen schwachen Pullup auf dem Interface, was den S.BUS bedient. Der war gut für Busse anderer Hersteller, und er fraß ja kein Brot auf dem S.BUS. Das Thema war nicht Bestandteil der S.BUS-Spezifikation, ergo, dass das ein Futaba-Empfänger mal anders handhaben könnte, - und nach dem bisherigen Verhalten der Empfänger konnte ein Designer eines S.BUS-Devices, konnte Uli davon ausgehen, dass der Empfänger als Busmaster so einen schwachen Pullup per Aktiv-LOW einfach platt macht hinsichtlich des Ruhepegels des Busses. Nun, beim R7003SB ist das nicht so, Futaba hat sich sozusagen selbst ein Bein gestellt.
Wie weiter, wenn VStabi reagiert? Es wird wahrscheinlich so laufen, dass Uli eine Test-Firmware ohne Pullup erzeugen wird, und zwar zum Test durch Dirk auf die Seriennummer eines Silverline von Dirk. Das wird vermutlich mindestens 3 Wochen brauchen, weil Dirk jetzt erst mal in 2 Wochen Urlaub entschwindet. Das gönnen wir ihm doch?
Wir können davon ausgehen, dass das auf Anhieb funktionieren wird, also dass VStabi dann nicht mehr den Design Bug des 7003 zur Wirkung bringen wird.
Allerdings wird dann das Rollout in offizielle Firmwares der verschiedenen VStabi-Devices etwas Zeit beanspruchen.
Insofern kann man Ungeduldigen als sofortige Lösung nur nochmals den Pulldown an's Herz legen.

Ihr seht, die 3rd-Parties sind wie immer willig. Auch Robbe hat Anteil daran, kontaktierte Uli umgehend, nachdem klar war, was hier schief läuft im 7003. Das nur mal in das Ohr Ungehaltener. Was immer man Futaba aus der Historie glaubt, vorhalten zu müssen, - es ist nun mal so in der Technik, dass ein gewisser "Murphy" schon mal um die Ecke linsen könnte, also: Shit happens.
Alles wird gut.

Nachtrag: Diesen software-definierten Pullup gibt es in allen noch gepflegten VStabi Base Units, also nicht nur Silverline und Mini.
Noch einen: Dirk hat eine VStabi-Firmware ohne den software-definierten Pullup von Uli getestet: Alles ist schick dann.

-------------------------------------------------------------------------------------------------------------------
English Summary and Conclusion

The R7003SB has a design bug (confirmed by Futaba) which can be brought into effect at least by the S.BUS devices Vbar Silverline and Mini.

Futaba has changed the behavior of the receiver as busmaster on the S.BUS. Between transmissions (by the receiver) it does not keep active as a serial transmitter (as with other comparable Futaba receiver models) to force the bus idle level to LOW, than goes into the tristate. The problem is that there is no sufficient pulldown resistor in the R7003. Vbar is using a weak pullup on the bus and so the idle level goes up direction HIGH easily. That may avoid that a device can recognize the starting edge LOW-HIGH (S.BUS and S.BUS2 are inverted) of a data packet.

So Vbar cannot only disturb itself and other S.BUS devices than also the S.BUS2 on which the 7003 cannot read anymore. Due to the design of the receiver S.BUS and S.BUS2 use shared components inside the receiver. Vice versa a pullup-prone device on the S.BUS2 can disturb the bus and other S.BUS2 devices but not the S.BUS because the receiver is only transmitting on that bus.

Vbar (Uli) is NOT responsible for that, Futaba is, because their bus specification does not address the use of pullups and because they have changed the busmaster's behavior without notice (no more brachial forcing the bus to LOW between transmissions).

Existing R7003SB cannot be changed by Futaba. Guess a successor will come.
Uli (Vbar) provided a tester (Dirk, the guy with whom I did the investigation) already with a test firmware without that pullup (software-defined), but the rollout of such a change by official Vbar firmware releases will need some time then.

Meanwhile the best and simple solution is to use an external pulldown resistor of 5.6 kOhm (3.3 to 8.2k) on the S.BUS (between "signal" and "ground"), and also on the S.BUS2 if you fear to have a S.BUS2 device with an internal pullup which could raise the idle bus too much direction HIGH (>0.9V).
Btw: Futaba sensors act as weak pulldown resistors.

---------------
5.9.13: http://www.rc-heli.de/board/showpost.php?p=2560884&postcount=13
- Wir hatten es getestet mit einer geänderten VStabi-Firmware, die uns Uli z.V. stellte, und der Empfänger-Bug wirkte nicht mehr.
Keine Ahnung, ob Uli diese Änderung inzwischen in neuen Firmwares ausgerollt hat. Fragt ihn einfach im Mikado-Forum. Vielleicht steht's ja auch in den Release Notes von einem der letzten Updates.
- Robbe/Futaba hat inzwischen einen 7003 mit einer Hardwareänderung im Test.
- Inzwischen könnt Ihr völlig beruhigt Eure 7003 verwenden, sofern Ihr besagten Pulldown-Widerstand auf die Signalleitung des Busses packt. Die Aussage zur Belastbarkeit des Widerstandes (Leistung) wurde nicht verstanden: Das heißt ganz einfach, Ihr müsst Euch nicht darum scheren, könnt den kleinsten nehmen, den Eure Augen, Griffel und Euer Lötkolben noch handhaben können.

Statistik: Verfasst von dl7uae — 19. Apr 2013, 18:34

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-18T18:12:06+01:00

Abschluss

Es 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.

Ursache

Der 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.

Statistik: Verfasst von dl7uae — 18. Apr 2013, 18:12

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-14T18:09:25+01:00

Hallo Egon,

mit dem von Tom genannten Widerstand wird es wohl funktionieren, aber die "richtige" Lösung ist es sicher nicht.
Bei mir sind die Platzverhältnisse zum Glück nicht so eng, so dass ich einfach auf den 7008 umsteigen konnte.

Grüße,
Dirk

Statistik: Verfasst von Blademaster — 14. Apr 2013, 18:09

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-14T10:58:52+01:00

dl7uae hat geschrieben:

Quote:

Nimm 'nen Pulldown 4,7..10k

Tom, ist das an mich gerichtet?

Ich denk nicht dran eine event. Fehlfunktion (sollte es eine sein) eines original robbe/Futaba Empfängers durch eine Modifikation oder externe Korrekturbeschaltung zu bekämpfen.

Sollte es sich tatsächlich (wonach es nach den Analysen leider aussieht) um eine Fehlfunktion handeln, dann wäre dringend robbe/Futaba am Zug.

Gruß,
Egon

Statistik: Verfasst von Egon — 14. Apr 2013, 10:58

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-14T10:38:43+01:00

Quote:

Nimm 'nen Pulldown 4,7..10k

Statistik: Verfasst von dl7uae — 14. Apr 2013, 10:38

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-14T09:53:34+01:00

Blademaster hat geschrieben:

Warten wir mal ab wie nun Robbe/Futaba reagiert und wie mit den bereits
ausgelieferten R7003SB verfahren wird.

Dirk, genau das interessiert mich auch. Da ich zwei Stk. R7003SB in hochwertige neue Flieger verbaut habe (und leider der 7008 aus Platzgründen keine Alterative ist), habe ich robbe um Stellungnahme ersucht.

Einstweilen bleiben die beiden Flieger im Hangar. Leider, wo jetzt endich gutes Wetter ist, und die Erstflüge anstehen.

Gruß,
Egon

Statistik: Verfasst von Egon — 14. Apr 2013, 09:53

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-13T13:29:55+01:00

Hi Tom,

hatte zu 100% die selben Gedanken, die Du im vorigen Post schilderst.

Zu Deiner Frage, warum der 7008 stärker nach Low zieht in den Pausen als der 7003:

Vielleicht sollte der Bestücker mal schauen, was er da auf die Platine gelötet hat ?

Statistik: Verfasst von sepp62 — 13. Apr 2013, 13:29

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-13T12:58:58+01:00

Nimm 'nen Pulldown 4,7..10k, und alles is gut (vielleicht).

-----
Na ja.., und: Ganz unabhängig von dem NoGo eines Floating Bus im Tri-State, was der 7003 ganz offenbar macht..

...Ich glaube, Uli sollte mal gucken, was da bei ihm als Pullup wirken kann im VS. Bisher war das offenbar nicht bemerkbar, weil der S.BUS aktiv auf LOW gehalten wird in den Sendepausen (durch den seriellen Tx des Empfängers, der im 7008 und 6308 vermutlich immer aktiv ist auf dem S.BUS), beim 7003 ist es aber nun mal anders, der serielle Tx wird vermutlich inaktiv zwischen den Servodatenpaketen. Dadurch gibt es keinen starken Mann mehr, der so einen Pullup, - fälschlich, versehentlich oder parasitär, - ganz lässig kompensieren kann, brachial auf LOW zieht.

Allerdings, und das hat dann mit VS rein gar nix zu tun: Der S.BUS2 muss zwischendurch in den Tri-State gehen. Nur, warum ist das ruhende LOW von 7008 und 6308 soviel stärker als das des 7003 auf dem S.BUS2? Letzteres sollte eigentlich nicht interessieren, genauso wenig wie JSend/JLog2 auf dem S.BUS2 sich für VS auf dem S.BUS interessieren müsste. Nur gibt es eben die innere (im R7003) Rückwirkung zwischen beiden Bussen.

Statistik: Verfasst von dl7uae — 13. Apr 2013, 12:58

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-13T11:00:32+01:00

Hi Tom,

vielen Dank für Deine weiteren, alles bestätigenden Tests.

Warten wir mal ab wie nun Robbe/Futaba reagiert und wie mit den bereits
ausgelieferten R7003SB verfahren wird.

Grüße,
Dirk

Statistik: Verfasst von Blademaster — 13. Apr 2013, 11:00

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-13T01:09:10+01:00

Also, meine These ist ja schlußendlich, s.o.:

Das Problem ist, dass der R7003SB den offenen Bus, - im Tri-State, sprich, alle Busteilnehmer sind auf seriellem Empfang, - wie einen floating Bus behandelt. Das darf er aber nicht, denn wir sind hier auf einem Asynchron-Seriellen-Bus. Hier braucht es einen Startpegel, der ist normalerweise HIGH, da S.BUS und S.BUS2 aus ebenso unerfindlichen wie hinderlichen Gründen aber invertiert betrieben werden, LOW.

Nun muss es etwas auf dem Bus geben, wenn niemand aktiv LOW treibt, was den Bus hinreichend auf LOW hält, "hinreichend" dahingehend, dass nicht eben irgendwas hochohmiges gegen Plus bereits den Ruhe==Startpegel signifikant gegen HIGH ziehen kann.
Was passiert, wenn Busteilnehmer HIGH als Ruhepegel des offenen Busses (alle lauschen) sehen? Sie werden die startende LOW-HIGH-Flanke nicht mehr bekommen, ergo den Bus nicht mehr oder falsch lesen.

Was ist "irgendwas"? Na einfacherweise etwas passives, ein Widerstand, zwischen Bus-Leitung und Masse, ein Pulldown. Der sollte möglichst niederohmig sein, aber vom Wert noch so hoch, dass alle Busteilnehmer gegen ihn einwandfrei HIGH treiben können. Er hätte also mehrere KiloOhm, irgendwas zwischen 4,7 und 10k.

-----
Man muss anmerken, dass ein Pullup eigentlich nichts auf dem Bus zu suchen hat. Keiner der Busteilnehmer, auch auf dem S.BUS nicht, sollte so etwas einschleppen. Wenn wir hier mit Pullups messen, dann nur zu dem Zweck, "effektive Pullups", die, völlig normal, durch Busteilnehmer "parasitär" eingebracht werden könnten, abzubilden.
Warum auch auf dem S.BUS nicht? Normalerweise könnte man annehmen, dass auf dem unidirektionalen S.BUS der serielle Senderausgang des Empfängers immer aktiv ist, also in den Sendepausen aktiv LOW treibt, den Ruhepegel. Allerdings scheint es zumindest beim R7003SB so zu sein, dass der Port des Empfängers in den Sendepausen auch auf Empfang geht, in den Tri-State. Warum auch immer, auf dem S.BUS gibt's nichts zu empfangen für ihn. Das scheint dieser Multiportfunktionalität des R7003 geschuldet zu sein.

Nun, auf dem S.BUS2 muss es auf jeden Fall diese Instanz, vermutlich Widerstand, geben, die den Buspegel auf LOW hält, wenn alle als serieller Sender inaktiv sind, niemand aktiv LOW treibt. Im R7008 und R6308SBT scheint es sie zu geben, im R7003SB fehlt sie. Also vermutlich doch Design Bug.

-----
Okay, probieren wir's einfach aus. Was macht der Elektroniker? Er testet alles Worst Case, ist ein Extremist.
Also den besagten Pulldown absichtlich etwas zu groß gewählt, 8,2k.
Dafür den Pullup zu klein gewählt, 33k. -- Wenn ein Programmierer eines ATmega Prozzis z.B. versehentlich den Pullup auf einem GPIO (Pin) aktiviert, dann sind das so 35..50k gegen plus Betriebsspannung der MCU, die wäre aber geringer, irgendwas um 3V. Die 33k sind also schon böser als ein doofer ATmega-Programmierer einbringen könnte auf diese Weise, eigentlich noch viel böser, wenn man berücksichtigt, dass unsere höher sind als 3V, nämlich hier 4,7V. Die 33k gegen 4,7V sind also schon eine schwer boshafte Variante, am Leben vorbei, bzw. "Leben" in der Hölle.

Hier das Ergebnis:
OK, toll ist das nicht, geht teilweise schon über 0,6V, reicht aber noch aus, dass niemand Bahnhof versteht.
Zum Vergleich: Dirk hatte zwar noch höhere 5,6V (wirksamerer Pullup), aber: Bei 147k ging es noch, mit 100k schon nicht mehr.

S.BUS:

S.BUS2:

Sprich: Gäbe es irgendwas Sinnvolles als Pulldown im R7003SB auf den Ports für S.BUS/S.BUS2, so 5,6k oder 6,2k oder 6,8k oder so, - gleichzeitig sind die parasitären Pullups von Busteilnehmern viel größer im wahren Leben, - hätten wir nie einen Anlass gehabt, unsere Zeit damit zu vergeuden.

--------------
Das soll's jetzt wirklich gewesen sein.
Sinn macht es natürlich erst dann, wenn der Robbe-Tekki es auch sah und eine identische Position dazu für sich finden kann.
Falls das wirklich eintreten sollte, muss er noch den Entwickler in Nippon überzeugen.
Es bleibt spannend..

Statistik: Verfasst von dl7uae — 13. Apr 2013, 01:09

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-12T23:49:04+01:00

Nach nochmaligen Nachdenken ist mMn der letzte Abschnitt oben, der nach dem -->, der springende Punkt.

Das habe ich eben an Robbe geschrieben unter Anderem:

Quote:

MMn ist das was ganz Profanes. Zumindest auf dem S.BUS2, wo der Empfänger nicht immer serieller Sender ist, - auch auf dem S.BUS, weil zumindest beim 7003 der Rx offenbar zwischendurch auch in den Tristate geht, - muss irgendwer für hinreichend geringe Impedanz gegen LOW sorgen bei offenem Bus, denn LOW ist ja der Ruhepegel hier, weil, warum auch immer..., invertiert.

Für mich sieht das so aus, dass die Busteilnehmer, R7003 eingeschlossen, irgendwann beginnen, Bahnhof zu verstehen, weil der Ruhepegel über 0,8V rutscht, also == HIGH, und das darf nicht sein! Der Störabstand wird eh sehr schnell gefährlich klein.

"Irgendwann" kann schon ein beschissen hochohmiger Pullup bewirken.
Hätte man einfach einen Pulldown auf den Port genagelt im Rx, so 10k, z.B., wäre alles schick soweit. Und diesen Widerstand wird es geben im R7008 und R6308.

Jedenfalls, "floating bus" darf es hier nicht geben, denn die seriellen Empfänger verlangen ihren Ruhepegel (Startpegel), und der ist LOW wg. der Invertierung.

Der allerletzte Satz ist es.

Statistik: Verfasst von dl7uae — 12. Apr 2013, 23:49

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-12T20:45:04+01:00

So, hier die Details, die die bisher dargestellten bestätigen.

Robbe ist stark daran interessiert, ein evtl. Problem aufzuklären und sodann ausmerzen zu lassen.
Am Dienstag nach Ostern hatte man gleich mit dem Entwickler in Japan telefoniert und mich sodann angerufen. Details gingen etwas verloren, auf dem kommunikativen bzw. Sprachwege, evtl. auch auf dem Verständniswege. Jedenfalls bestätigte sich prinzipiell meine Vermutung, dass S.BUS und S.BUS2 beim R7003 keine elektrisch vollkommen getrennten Schnittstellen sind, in irgendeiner Form schaltungstechnisch und/oder per Firmware in Verbindung stehen. Grund ist wohl der, dass man per Setup des R7003 auch ermöglichen kann, 2x S.BUS2 bzw. 2x S.BUS auf die Ports zu legen.

Robbe schickte mir sodann eine T14SG (die T18MZ, die SM und ich seit einem Jahr von Robbe haben, hatte ich zu SM geschickt, weil Stephan ja gerade bzgl. S.BUS2 zugange ist und neben seiner T14SG auch mit der T18MZ testen will). Dazu ein R7003 und zwei Sensoren, Vario-F1712 und TEMP125-F1713 (diese Sensoren hatte ich zwar mal, gab sie aber zurück an Linus).

Kleine OT-Bemerkung an dieser Stelle: Ralf (Helbing), hey Du, ich muss schon wieder mal Congrats sagen. HoTT muss ja eine massive Wirkung auf den Mitbewerb gehabt haben.. Warum sonst hat man an der T14SG Eure beschissenen Touch Keys nachgemacht? Ich jedenfalls, I hate it!

---------

So, 2x R7003, der von Dirk, ein nagelneuer von Robbe. Beide zeigen dasselbe Verhalten, wobei es pegelmäßig leichte Varationen gibt, was mir ein Zeichen für "ungewollter Effekt" sein will, für Bug, - hoffentlich kein Design-Bug..

Das Setup beider R7003 war das

also Default. S.BUS2 auf Port S.BUS2, S.BUS auf Port Port1.

Wir fangen ganz klein an: Auf dem S.BUS2: JLog2 hinter JSend. - Auf dem S.BUS: Nix.
Wie sieht's aus? Alles schick. HIGH geht so an die 3V (MCU-Ausgangspegel), LOW ist quasi Null Volt,

auf dem S.BUS,

auf dem S.BUS2

(Übrigens, in dem Bild vom S.BUS2: Links das Servodatenpaket vom 7003, HIGH==3V, gefolgt von Sensordaten Slot 1, das sendet der 7003 (interne und externe Spannung im Wechsel), also auch HIGH==3V, - rechts daneben Sensordaten in weiteren Slots von JLog2: Der HIGH-Pegel geht etwas höher, weil JSend mit einer Betriebsspannung von 3,2..3,3V arbeitet, der stabilisierten Spannung von JLog2 intern.)

Nun gehen wir mal ganz moderat ran, und vor allem geräteunabhängig, damit nicht die VStabi-Ist-Schuld-Diskussion aufkommen kann: Ein verdammt hochohmiger Widerstand für die Busverhältnisse, ein Pullup-Widerstand von 68 KiloOhm. "Pullup" heißt, was der Name sagt, ein "Hochzieher", - zwischen Bussignalleitung und Plus, hier Plus des Busses selbst, S.BUS.
Dirk hatte von 47k bis 147k operiert, ich habe einfach 68k genommen, fiel mir zuerst in die Hände.
(Meine R/C-Spannung betrug 4,7V.)

S.BUS

Ja hola! Der LOW-Pegel hebt sich um 1V an! Das ist große Scheiße für einen Bus, auf dem LOW/HIGH nach dem TTL-Pegelschema unterschieden wird.
Telemetrie in der T14: Friert ein.

S.BUS2

Sieht alles gut aus, LOW immer noch == Null Volt.
Trotzdem friert die Telemetrie ein, - entweder versteht JLog via JSend nicht mehr die Servodatenpakete des 7003 , oder umgekehrt versteht der 7003 den JLog+JSend nicht mehr (nehme ich an).

Es gibt also eine Rückwirkung der durch den Pipifax-Pullup drastisch verschobenen Pegelverhältnisse auf dem S.BUS zurück auf den S.BUS2. Diese Wirkung ist offenbar intern im R7003.

Um sicherzugehen, dass Dirk nicht einen Montagsempfänger erwischt hat, hier Item #2, der nagelneue R7003 von Robbe:

Dasselbe in Grün, der LOW-Pegel auf dem S.BUS rutscht dramatisch nach oben, obwohl der Pullup ein Witz ist.

------
Okay... Drehen wir das Spiel um, setzen wir einen Kinder-Pullup auf den S.BUS2 und schauen uns an, wie das auf den S.BUS2 selbst und auf den S.BUS2 wirkt. Ich habe dabei gleich mit dem R7003 von Robbe weitergemacht.

S.BUS2, 68 KiloOhm gegen Plus des S.BUS2:

Hey, die Telemetrie läuft noch! Ist das jetzt gut? Nö, reiner Zufall, der S.BUS2 ist geringfügig weniger weicheiig. LOW wird von Null auf 0,6 Volt hochgezogen. Das geht gerade noch. Wen wundert's, TTL-Pegelschema, bis 0,8V isses noch LOW.

Okay, 34 KiloOhm, ist ja immer noch witzhaft hoch, - S.BUS2:

Na bingo! Telemetrie steht, LOW auf dem S.BUS2 wird hochgezogen von Null auf ca. 1 Volt.
Was sieht man noch? JLog+JSend sendet keine Sensordaten mehr in die Time Slots, weil er nicht mehr die Servodatenpakete des Empfängers lesen kann (sieht nur noch HIGH), und diese Pakete sind die Synchronisationspunkte und adressieren die vier Frame-Typen. Der einzige Sensor, der noch sendet, ist der Empfänger selbst (in Slot 1). Kein Wunder, er muss ja auch nichts vom Bus lesen dafür.

Und was passiert dabei auf dem S.BUS?
34k Pullup auf dem S.BUS2, S.BUS:

Dasselbe wie S.BUS2 und Pullup auf dem S.BUS, kein Effekt auf LOW.

Nun hatte ich leider kein S.BUS-Device mehr da (S.BUS-Servo im Koffer der T18 bei SM). Vermutlich würde das nicht mehr funktionieren.

-----
Also noch mal das Fazit:

DAS DARF NICHT SEIN! Die Source-Impedanz beider Bus-Ports ist zumindest für LOW viel zu hoch! Mit solchen Watte-Ports kann kein durchgängig hinreichender Signal/Störabstand gewährleistet werden.

Das kann nur ein Bug sein! Es könnte sich um einen profanen Firmwarebug handeln, - ich fürchte aber inzwischen, es ist ein Design-Bug.

Wer die beiden Busse benutzen will, darüber Steuersignale schickt, der tut das auf eigene Gefahr.
Es kann gehen, es wird dann vermutlich auch immer gehen in diesem Setup, - möge es so sein, gebe es der große Modellbaugott.
Aber, wie man am Anlaß für die ganze Investigation sieht, es kann auch ganz einfach nicht gehen: VStabi auf den S.BUS gesteckt, VStabi geht noch (gerade noch...), S.BUS2 geht nicht mehr, nix Telemetrie von Sensoren auf dem Bus.
Nur..., die Show kann sich auch ganz einfach umdrehen, wie man oben sehen konnte.

(Und ehe jemand noch mal fragt, schnell überprüft: Die Quellimpedanz für HIGH ist okay, der Ausgangspegel bricht bei Belastung mit 1,1k Pulldown-Widerstand (gegen Masse) um ca. 0,5V ein, also auf 2,5V, auf beiden Bussen so. -- Ich weiß..., das ruft die Experimentierfreudigen auf den Plan, die das Ganze durch einen Pulldown-Widerstand heilen wollen. Okay, das ginge wahrscheinlich. )

-----
Wie weiter?
Nun.., Robbe muss es nachvollziehen können, - und sie werden es können, wenn sie Obigem folgen.
Dann werden wir sehen.

Danke an Robbe für die prompte Reaktion und Unterstützung. Sorry, Leute, dass ich Euch das Ergebnis zum Dank in's Kreuz schmeißen muss.

-----
P.S. Klar, ich hatte auch Futaba-Sensoren parallel auf dem S.BUS2. Fakt ist, die verhalten sich im Sinne einer marginalen Pullup-Funktion (mit so unsinnig dramatischer Wirkung) völlig neutral, im Gegenteil, sind eher ein virtueller Pulldown, aber relativ hochohmig.
Wie man's auch dreht, die hochohmige LOW-Quellimpedanz der Bus-Ports des R7003 ist auf keinen Fall akzeptabel.

-----
-->
Wenn man ganz genau hinguckt, könnte man sagen:
Wieso denn, der LOW-Pegel stimmt doch in den Aussendungen, nur der Tristate-Pegel, wenn der Bus seitens des Rx (R7003) (beim S.BUS eigentlich unnötigerweise) auf Empfang ist, geht gegen logisch HIGH, sollte eigentlich LOW sein.

Okay.., nur muss man dabei berücksichtigen, dass LOW hier der Ruhepegel sein muss, weil S.BUS und S.BUS2, aus welchen Gründen auch immer, invertiert sind.

Dann hätte man das entweder in der Bus-Spezifikation berücksichten müssen, die vorgeschriebene Anschlußschaltung für den S.BUS2, z.B. (R-C-Glied), gibt das nicht her, oder man hätte es so wie beim R7008 und R6308 machen müssen. Wie hat man's denn da gemacht?

Nach dem Prüfen der Quellimpedanz für HIGH kann ich nur sagen: Ein einfacher doofer Pulldown-Widerstand am Port hätte es geheilt, denn man kann nicht verlangen, dass nichts den Bus in diesem hochohmigen Zwischenzustand hochziehen können darf. So aber könnte es, bildlich gesprochen, selbst ein feucht gewordener Fliegenschiß. Und das stört den Empfang der anderen Busteilnehmer und ganz offenbar und witzigerweise den des R7003 selbst auch.

(Ach.., was wäre es einfach, könnte man mal das Schaltbild sehen..)

Statistik: Verfasst von dl7uae — 12. Apr 2013, 20:45

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-12T19:17:57+01:00

So, jetzt habe ich selbst auch noch mal gemessen..
Mein Ergebnis vorweg:

Es stimmt alles, was Dirk gemessen hat, leider.
Der S.BUS des R7003 ist als hochgradig unsicher zu bezeichnen.
Beide Busse, S.BUS und S.BUS2, haben außerdem eine wie immer geartete Rückwirkung aufeinander.
Diese ist nicht meßbar, wirkt aber im Inneren des R7003, zeigt äußere Effekte auf die Funktionsfähigkeit.
Ergo sollten weder S.BUS noch S.BUS2 wirklich benutzt werden.

Nun muss noch Robbe in die Lage versetzt werden, das selbst auch nachvollziehen zu können. Ich glaube, hier lag ein Mißverständnis vor.

Bin gerade zu faul, meine Bildchen nebst Kommentaren folgen.

Statistik: Verfasst von dl7uae — 12. Apr 2013, 19:17

Re: Jive + JLog2 + JSend + T18MZ + R7003SB

2013-04-10T17:48:11+01:00

Weil Dirk auch fragte:

Bisher is nix Dolles passiert. Robbe hat eine T14SG + R7008 + zwei Sensoren geschickt. Beim R7003 war gerade Engpaß, der kam dann aber vorhin. Dirk's R7003 ist schon 'ne Weile da.

Jetzt liegt's nur noch an mir, muss ein Zeitloch finden..

Wenn alle Stränge reißen, wird's erst am Samstag was.

Statistik: Verfasst von dl7uae — 10. Apr 2013, 17:48