J-Log.eu - Forum

Status-Update:

Beim R7003 kann man wohl auch 2x S.BUS2 konfigurieren. Es ist tatsächlich so (sagt der Entwickler in Japan), dass hier ein gewisser hardwaremäßiger Mix besteht zwischen den Ports, offenbar so, wie vermutet, der serielle Receiver lauscht auf beiden Enden, die Sender müssen eigentlich separiert sein, weil im Gegensatz zum R7008 die Pakete auf dem S.BUS(1) eine Null in Byte 25 haben, also keine S.BUS2-Markierung (CH18).

Allerdings kann Robbe die hohe Impedanz selbst meßtechnisch nicht nachvollziehen, selbst mit 10k Pullup ist das Hochziehen des Low-Pegels im Rahmen dessen, was die vom Protokoll vorgeschriebene Ankopplung verursachen mag, sprich, marginal.

Dirk hat das Eine gemessen, SM konnte das eigentlich bestätigen. Nun, wir haben hier nun quasi "eine verklemmte Patt-Situation", aber Robbe selbst ermöglicht, den Knoten zu lösen, indem sie mich jetzt mit einem Sender (T14SG) und einem R7003 ausstatten werden.

Bis dahin, bis ich selbst auch messen konnte, müssen wir wohl einfach die Füße stillhalten.

Okay?

-------
Dirk, um allen Zweifeln vorzubeugen: Ich glaube, es wäre schlau, wenn Du mir Deinen R7003 noch mal zuschickst.

_________________
Tom

und man kann auch 2x S.BUS konfigurieren. Wäre vielleicht sinnvoll, zur Sicherheit die neuerlichen Messungen in allen (S.BUS-) Modi des R7003SB zu machen.

Nur nebenbei, die S.BUS2 fähigen Servos (z.B. S3172SV) kann man wahlweise am S.BUS oder S.BUS2 betreiben - so verschieden sind die S.BUSse dann auch wieder nicht. Aber das gehört eher nicht zum Thema, sorry ...


Gruß,
Egon

Hi Tom,

wie auf dem Konfigurationsbild auf Seite 1 dieses Freds zu ersehen, kann man beim 7003
"alles mögliche (Modes)" konfigurieren.

Alle Messungen habe ich im Mode A gemacht, Port1 -> SBUS, SBUS2 -> SBUS2

Ich werde Dir morgen den Empfänger zusenden an dem ich alle Messungen vorgenommen habe...


Grüße,
Dirk

Ja, stimmt, Egon, hatte ich ja schon mehrfach dargestellt. Es gibt zwei Unterschiede:

a) Die Servodatenpakete haben in Byte 25 (das letzte Byte) eigentlich eine Null auf dem S.BUS, während sie auf dem S.BUS2 eine CH18-Markierung haben und eine Frameadresse 1..4. Aber das scheint den S.BUS-Geräten egal zu sein, jedenfalls VStabi, z.B., denn sie funktionieren auch am S.BUS des 7008, und hier sehen die Servodatenpakete wie auf dem S.BUS2 aus, eigentlich nicht protokollkonform. Jedenfalls hat dadurch ein S.BUS2-Device keine Chance, festzustellen, dass es versehentlich auf einen S.BUS gesteckt wurde.

b) Der S.BUS2 ist bidirektional. Der Rx geht nach dem Aussenden des Servodatenpakets auf Empfang, es gibt eine vorgeschriebene Anschlußschaltung (Tiefpass).

Von daher wird ein S.BUS-Device auf dem S.BUS2 eigentlich keine Probleme haben, die Aussendungen von Sensoren ignorieren, die Servodatenpakete des Rx fressen wie auf dem S.BUS.
Es könnte eben nur sein, dass Rx-Port (wenn der Tx bleibt nach Aussendung) und S.BUS2-Device kollidieren, Sender auf Sender, was aber nix kaputt macht und auch nicht zu Mißverstehen Anderer führen kann, obwohl das Aussendungen eines S.BUS2-Devices für diese verstümmeln könnte.

--------
Okay, Dirk. Mal sehen..

_________________
Tom

Noch mal zum Status:

VStabi-Forum:

Nun.. Nach dem, was Dirk (Blademaster) gemessen hat, müsste die Anwort sein: Nein, nicht mit S.BUS benutzen, wäre zu unsicher.

Nun sagt Robbe, man hätte Dirks Messungen nicht nachvollziehen können.
Ich weiß nicht, ob SM gemessen hat, zumindest konnte er den Effekt auf den S.BUS2, auf JLog, nachvollziehen.

Nun heißt es also: Robbe: Tom, wir statten Dich aus, dass Du auch selbst messen kannst. Vorsichtshalber sendet mir Dirk auch den R7003, an dem er seine Messungen durchführte.
Es kommen also einfach Messungen in dritter bzw. vierter Instanz hinzu. Egal, was dabei herauskommt, müssen wir uns am Ende zusammenraufen, Dirk, Robbe, ich, und eine Schlußfolgerung bzgl. des Status des R7003 finden.

Es braucht also einfach noch ein bisschen Zeit.

_________________
Tom

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.

_________________
Tom

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.

_________________
Tom

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

_________________
Tom

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

Das habe ich eben an Robbe geschrieben unter Anderem:

Der allerletzte Satz ist es.

_________________
Tom

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

_________________
Tom