Wenn dies Ihr erster Besuch hier ist,
lesen Sie bitte zuerst die Hilfe - Häufig gestellte Fragen
durch. Sie müssen sich vermutlich registrieren,
bevor Sie Beiträge verfassen können. Klicken Sie oben auf 'Registrieren', um den Registrierungsprozess zu
starten. Sie können auch jetzt schon Beiträge lesen. Suchen Sie sich einfach das Forum aus, das Sie am meisten
interessiert.
Ja, Danke! Wirklich spannend. Ich hoffe Futaba schiebt das nicht auf Mikado, da Futabas Stabi ja geht... (Btw. was ist den ein Zero Time Alert bei Robbe?) So mega wichtig???
Naja, Robbe als Reseller hat von der Technik ja wenig Ahnung ausser Wartung und Hardware. In der Software stecken diese ja gar nicht drinnen...warum also an Fehler glauben. Btw. wurde das Fehlverhalten eigentlich von anderen unabhängig bestätigt?
Nein, hat entweder niemand vor Dirk bemerkt oder eben nichts gesagt.
Es gibt einen zweiten 7003, der ist gerade auf dem Weg von SM zu Dirk zurück, der wird sich aber genauso verhalten, weil er ja denselben Effekt mit VStabi am S.BUS zeigte.
Ich würde ja gerne mal in einen 7003 reinäugen, was man da hardwaremäßig treibt, dass es zu so einer komischen Rückwirkung zwischen S.BUS und S.BUS2 kommen kann. Wie gesagt, ich vermute, dass man vereinheitlichte, zumindest bzgl. des Senders, warum sonst ballert man S.BUS2-markierte Frames auf den S.BUS?
Kann man ja alles machen, geht mich nichts an, es wird vermutlich ein ganz profaner Firmwarebug sein.
Jedenfalls haben mich die ganzen Ungereimtheiten bisher schon viel Zeit gekostet, was mich langsam ärgert, weil der Effekt im Sinne einer Telemetrie ziemlich schlecht ist im Vergleich zum Aufwand.
Was Robbe betrifft: Ist mir schon klar, verlange ja auch nichts unmögliches, nur etwas Verantwortungsgefühl. Wenn das stimmen sollte, was ich da behaupte aufgrund der Tests von Dirk, dann muss man reagieren, die Behauptung überprüfen. Es könnte sonst sehr schnell mal ein vermeintlich zuverlässig funktionierendes S.BUS-Device plötzlich nur noch Bahnhof verstehen, mit den entsprechenden Folgen, wenn ein Modell in der Luft außer Kontrolle gerät.
Aber bisher ist ja gar nichts passiert, hätte ich auch nicht erwartet, schließlich ist Ostern. Außerdem kann doch nicht einfach jeder die Pferde scheu machen.
Alles nichts Dramatisches, einfach nur ein Gucken nach Ursachen, was mir mal wieder aufgezwungen wurde, weil mein Device mit Device XY nicht konnte. Wenn's nach mir ginge, hätte ich mit so was nichts zu tun.
Das klingt ja ziemlich beunruhigend. Bitte haltet uns zum Thema am Laufenden, unzensuriert bitte ... Es geht (mir) nicht darum irgendwen zu beschuldigen, ich möchte nur meine Modelle nicht riskieren.
Habe zwei Modelle mit dem R7003SB ausgestattet.
1. R7003SB mit 4 x PWM Servos am S-Bus über SBE-4 Adapter, 2 PWM Servos direkt am R7003SB, Vario am S-Bus2 / Betrieb an 5,0V geregelt
2. R7003SB mit 6x S3172SV am S-Bus2, Motorregler direkt am R7003SB, Vario am S-Bus2 / Betrieb an 8,2V geregelt
Beide Konfigurationen funktionieren (in der Werkstatt) einwandfrei, ich gehe (oder ging) natürlich davon aus, dass das in der Luft auch so ist. Muß ich an der einwandfreien Funktion nun Zweifel haben? Oder kann ich davon ausgehen, dass die reinen robbe/Futaba Konfigurationen ohne Fremdgeräte einwandfrei ticken?
Gruß,
Egon
Zuletzt geändert von Egon; 31.03.2013, 10:08.
Grund: Betriebsspannung hinzugefügt
Kennt man von Futaba irgendwie gar nicht, dass die so schludern...aber das am Sbus 1 was Neues ankommt ist schon grundsätzlich 'komisch'. Das muss jeder anerkennen. Und nun sowas...****, dass man noch immer nicht selber die Firmware updaten kann.
Wie schon von Tom geschrieben ist ein weiterer 7003 auf dem Weg zu mir.
Sobald er angekommen ist, werde ich auch an diesem nochmal testen.
Infos gehen dann umgehend an Tom und der wird sicher wie gewohnt berichten.
Gibt es eigentlich eine Anleitung für die verschiedenen Blinkcodes, die der Empfänger ausgibt wenn der Empfänger
bei ausgeschalteter Funke mit Spannung versorgt wird?
die den Mode betreffenden Blinksequenzen sind in der deutschen und englischen Anleitung des 7003 beschrieben, dass die Codes 5 Sekunden nach dem Einschalten angezeigt werden steht denke ich nur in der englischen Anleitung.
Paar Sachen sind schon komisch, aber nicht funktionsbeeinträchtigend.
Warum sendet ein R6308 zwischen den Servodatenpaketen mit S.BUS2-Markierung (4 Frames) auch noch unmarkierte im S.BUS(1)-Kompatibilitätsmodus? F1-SB1-F2-SB1-F3-SB1-F4-SB1-F1-...
a) Andere Empfänger mit S.BUS2 tun das nicht.
b) Wer soll das nutzen?
c) Es sind 100% Redundanz, verdoppelt die Latenz für Sensordaten.
Umgekehrt: Warum senden alle S.BUS2-Empfänger auf dem S.BUS(1) die Servodatenpakete mit S.BUS2-Markierungen, also für Frame 1..4?
a) ist das für S.BUS(1)-Devices sinnlos,
b) nimmt es einem S.BUS2-Device die Möglichkeit, feststellen zu können, dass es versehentlich auf den S.BUS(1) gesteckt wurde, also sendemäßig die Klappe halten sollte.
Das ist alles nicht wirklich schlimm, die beiden Busse sind eben gar nicht so grundverschieden, wie immer suggeriert wird, nur ist eben der eine unidirektional (S.BUS), der andere bidirektional. Wenn ein S.BUS2-Device auf den S.BUS sendet, soll das natürlich nicht sein, es kann aber nicht zum Gau führen, wenn sich alle wirklich an den Buchstaben der Protokolldefinitionen halten. Allerdings kollidieren die Ausgangspegel beider Sender, Empfänger und S.BUS2-Device, die Message des S.BUS2-Devices kann dadurch verstümmelt werden. Aufgrund der unterschiedlichen Längen der Datagramme von Rx und Sensor und grundverschiedener Strukturen ist es trotzdem sehr unwahrscheinlich, dass ein Servo eine Sensor-Aussendung als an sich gerichtet verstehen könnte. Soweit, so gut.., beruhigend.
Nur: Warum mischt man seitens Futaba?
Die Theorie könnte sein, dass man sich mit der konkreten Implementierung genau an der Tatsache orientiert, dass Framemarkierungen von S.BUS-Servodatenpaketen eben nicht schädlich sind, und ergo man den Empfänger als Sender auf beiden Bussen aus EINER Source bedienen lassen kann. Nun muss man nur noch einen Receiver zusätzlich auf dem S.BUS2 haben (serielles Rx-Pin), und den Sender (serielles Tx-Pin), also für S.BUS2 UND S.BUS, nach Aussendung eines Servodatenpakets in den Tristate schalten, damit er den Empfang auf dem S.BUS2 nicht stört (Sensordaten, Gyros an Servos, evtl. auch Responses von Devices im Setup).
Warum diese Theorie, könnte mir doch egal sein, wie es ein Entwickler in Japan machte? Nun.., dass die Treiberleistung auf dem S.BUS-Anschluss des R7003 so gering ist (viel zu gering), kann und wird vermutlich einem profanen kleinen Softwarebug geschuldet sein, so was kann immer mal passieren. Ich nehme, wie gesagt, an, dass der Pin versehentlich als Input konfiguriert ist (bleibt). Zwischendurch scheint er mal kurz Output zu sein, siehe diese Nadel gegen Null Volt im Oszillogramm.
Die Theorie deshalb, weil a) die Frage ist, wie eine Null-Verschiebung auf dem S.BUS den Lesepegel auf dem S.BUS2 beeinflussen kann (Rx kann offenbar Sensor nicht mehr lesen), und b) kommt dann eben das Verwundern über Servodatenpakete mit S.BUS2-Framemarkierungen in ein neues Licht, ein Licht, was den Sinn dessen erkennbar zu machen scheint.
Für die S.BUS(1)-Servodatenpakete, die ein R6308 untermischt, und die anderen Empfänger eben nicht(!), habe ich deshalb noch keine Erklärung. Ist mir aber auch egal, die Bandbreite des S.Busses ist hoch genug, um das ohne praktische Defizite ab zu können.
die den Mode betreffenden Blinksequenzen sind in der deutschen und englischen Anleitung des 7003 beschrieben, dass die Codes 5 Sekunden nach dem Einschalten angezeigt werden steht denke ich nur in der englischen Anleitung.
Egon
Hallo Egon,
wie der Mode gewechselt wird ist klar, aber nochmal zu den Blinkcodes zur
Kontrolle des eingestellten Modes.
In der Englischen Anleitung findet man zur "Programmtabelle" folgenden Satz:
"*5 seconds after the receiver ON, LED shows CH Mode."
Das stimmt aber so nicht ganz, mein R7003SB ist in Mode A.
Ich habe ihn vorsorglich mehrmals in Mode A versetzt ABER der Blinkcode sieht immer wie folgt aus:
- Funke aus
- Empfänger ein
- ca. 5sec. Dauerlicht rot
- 2x blinken rot (was sagt diese Blinksequenz aus ???)
- ca. 5sec. Dauerlicht rot
- 1x blinken rot (das soll dann wohl der eingestellte Mode A sein)
- Dauerlicht rot
Um sicher zu gehen, dass ich nicht doch, warum auch immer, in Mode B (2x blinken rot) bin, habe
ich mal zu Spaß Mode K programmiert -> 3x rot/grün blinken.
Der Mode-Test sieht dann wie folgt aus:
- Funke aus
- Empfänger ein
- ca. 5sec. Dauerlicht rot
- 2x blinken rot (was das auch immer bedeuten mag)
- ca. 5sec. Dauerlicht rot
- 3x blinken rot/grün (entspricht Mode K)
- Dauerlicht rot
Somit gibt wohl die Blinkfolge nach dem zweiten "5sec. rot" den programmierten Mode an.
Grüße,
Dirk
Zuletzt geändert von Blademaster; 31.03.2013, 17:56.
Kommentar