T18MZ + Jive + JLog2 + JSend + R7003SB Telemetrie

[rudi1025]

Ich habe auch den CGY750 am S-Bus und JSend und Seedsensor am S-Bus2.
Funktioniert einwandfrei.
LG
RUDI

[dl7uae]

Info

Tom

[dl7uae]

Es gab eine Fortsetzung in obigem Link.

Habe vorsichtshalber Robbe per "Zero Time Alert" informiert.

Tom

[thomas1130]

Danke Tom für deine unermüdlichen Bemühungen - alles wirklich hochinteressant!
Bin schon gespannt wie es weitergeht..
LG
Thomas

[augur]

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???

[dl7uae]

Es gibt ein Update im folgenden Post, siehe Link oben.

"Zero Time Alert" ist meine Formulierung, komme aus der Network Security.

Ich halte es tatsächlich für gefährlich, momentan den S.BUS-Ausgang des R7003 zu benutzen.

Robbe zeigte sich eher unbeeindruckt bzw. ungläubig in erster Reaktion.

Tom

[augur]

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?

Vg Nils

[dl7uae]

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.

Tom

[Egon]

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

[augur]

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.

[Blademaster]

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?


Frohe Ostern und Grüsse,
Dirk

[Egon]

Hallo Dirk,

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

[dl7uae]

Moin!

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.

Tom

[Blademaster]

Hallo Dirk,

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

[Egon]

Hallo Dirk,

bei meinem 7003 kommt ziemlich exakt 5 Sekunden nach dem Einschalten der Code.

Ablauf:
Einschalten
2 Sekunden Dauerlicht rot
2x Blinken rot, 1 Sekunde (hat offenbar nichts mit dem eingestellten Mode zu tun)
2 Sekunden Dauerlicht rot
Blinksequenz entsprechend eingestelltem Mode

Ich komm also nur auf 1x 5 Sekunden bis zum Beginn der Blinksequenz.

Egon