J-Log.eu - Forum

JLF ------ SPAM Bots! Bitte nach Registrierung eine Email an mich zur Freischaltung! / After registration drop me an email please for clearing! ===Nenne/name the NICK you used to register with!=== Email address: -> http://j-log.eu/impressum
Aktuelle Zeit: 13. Mär 2020, 04:03

Alle Zeiten sind UTC + 1 Stunde




   [ 80 Beiträge ]  Gehe zu Seite Vorherige  1 ... 4, 5, 6, 7, 8
Autor Nachricht
Verfasst: 13. Apr 2013, 11:00 

Registriert: 5. Mär 2013, 15:00
Beiträge: 93
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


Nach oben
   
 
Verfasst: 13. Apr 2013, 12:58 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
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.

_________________
Tom


Nach oben
   
 
Verfasst: 13. Apr 2013, 13:29 

Registriert: 25. Nov 2012, 16:12
Beiträge: 24
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 ?

_________________
Grüße
Bernd


Nach oben
   
 
Verfasst: 14. Apr 2013, 09:53 

Registriert: 3. Apr 2013, 14:08
Beiträge: 3
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


Nach oben
   
 
Verfasst: 14. Apr 2013, 10:38 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
Zitat:
Nimm 'nen Pulldown 4,7..10k

_________________
Tom


Nach oben
   
 
Verfasst: 14. Apr 2013, 10:58 

Registriert: 3. Apr 2013, 14:08
Beiträge: 3
dl7uae hat geschrieben:
Zitat:
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


Nach oben
   
 
Verfasst: 14. Apr 2013, 18:09 

Registriert: 5. Mär 2013, 15:00
Beiträge: 93
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


Nach oben
   
 
Verfasst: 18. Apr 2013, 18:12 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
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.

_________________
Tom


Nach oben
   
 
Verfasst: 19. Apr 2013, 18:34 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
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.

_________________
Tom


Nach oben
   
 
Verfasst: 10. Dez 2013, 00:14 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
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.

_________________
Tom


Nach oben
   
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
   [ 80 Beiträge ]  Gehe zu Seite Vorherige  1 ... 4, 5, 6, 7, 8

Alle Zeiten sind UTC + 1 Stunde


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de