R6308SBT - Bitte um Hilfe!

[schonOK]

Mir war direkt schon klar, dass hier wieder mal nur Gerüchte in die Welt gesetzt werden. Warum das manche User machen, ist mir immer wieder ein Rätsel. Am Einfachsten ist doch zu warten, bis robbe oder futaba Werbung über Stromsensoren oder Steller bringt. Auf den geplanten Liefertermin dann einfach ein Jahr addieren - und fertig. Bisher habe ich übrigens noch nicht eine Werbung von einem Stromsensor gesehen.... ganz schlechtes Zeichen, wenn die Sensoren nun schon in 1,5 Wochen kommen sollen, oder?

Gruß Micha

[dl7uae]

Ähhmm, sorry, ich bin die Auflösung des letzten R6308-Rätsels in diesem Thread noch schuldig:

Also, der 6308 sendet im Gegensatz zum 7008 auf dem S.BUS2 als jedes zweite Paket eines im S.BUS(v1)-Kompatibilitätsmodus.

Nun.., die Specs des Protokolls erlauben das, neben CH18-Mode-Paketen (nur hiermit gibt's Telemetrie in 32 Time Slots) eben auch CH12- und S.BUS1(v1)C-Pakete. Ich wusste das, hatte es aber in der Implementierung etwas ignoriert, weil ich es für praxisfremd hielt.

Ergo: Schuld eigene.

Nu geht's.

-----
Übrigens: Obwohl diese Daten viel Redundanz auf dem Bus schaffen, latenzerhöhend (OK, der Bus ist schnell genug.), ist die Update-Rate des 6308 im Display des Terminals (T-Box) wesentlich höher als die des 7008. Das kann natürlich nichts mit dem Bus zu tun haben, das liegt irgendwo im FASSTest-Downlink.

Tom

[augur]

Was ist denn der Sinn von dem Kompatibilitätsframe? Einfach nur einen falsch angeschlossenen Servo zu behandeln? Weißt du das?

Vg Nils

[dl7uae]

Nö, absolut k.A., was das soll.

Mein Gefühl von Anfang an ist, dass sich der Designer des S.BUS2 richtig ausgetobt hat, und außerdem scheint er ein typischer Japanischer Erbsenzähler zu sein. Warum einem Device irgendeine Intelligenz zutrauen, wenn man doch alles haarklein befehlen kann, z.B.
Das Ding sollte eben die EWMS werden, koste es, was es wolle..

Ehrlich gesagt, ich überlege auch immer noch...
Der Empfänger dient dem Zweck, zwei Welten miteinander zu verbinden, die FASST-Welt im Uplink und zu den Servos und die FASSTest-Welt im Downlink, von den Sensoren und evtl. auch anderen Devices. Am Empfänger bleiben aber doch beide Welten getrennt, oder, PWM/S.BUS1 und S.BUS2? Mir fällt immer noch nix ein, was an diesem Empfänger auf dem S.BUS2 S.BUS1-kompatible Servodaten erwarten könnte..

Der S.BUS2 ist so konzipiert, dass hier auch Servodaten im CH12-Format und S.BUS1-Format fließen können. Nur, wozu, und warum macht das dieser Empfänger? Zusatzfrage: Warum ist Futaba wie ein Heftelmacher hinterher, dass man keine S.BUS1-Devices auf den S.BUS2 steckt? An einem 7008 hätten die Trauer, ja, an einem 6308 evtl. nicht? Würden die die CH18-Daten, Sensor- und Gyrodaten ignorieren können? Ich glaube eher, der S.BUS2 ist den Möglichkeiten der S.BUS1-Devices voraus, die noch gar nix davon wissen, dass es auch S.BUS2 gibt. Und wozu sollte man die das wissen lassen, sie in die Lage versetzen, S.BUS1-Daten vom S.BUS2 lutschen zu können, ohne sich durch den Rest gestört zu fühlen? Dann würde man die doch eh eher zu S.BUS2-Devices machen, oder?

Fragen über Fragen...

[augur]

Klingt für mich jetzt so, nachdem ich das habe sacken lassen, dass der Empfänger immer die Daten analog zum Empfangsprotokoll ausgibt. Erkenne nicht direkt den Sinn, aber das würde passen. T18 mit CH18 und CH12 Mode (analog auf dem SBus2) und bei dem Mischempfänger muss halt FASST auf den Sbus2 (also Sbus1 kompatibel, weil aus der alten Welt). Macht es für die Datenempfänger sicher nicht einfacher, aber ggf. Synchronisiert das den Bus mit dem Uplink für beste Latenz???

Vg Nils

[dl7uae]

aber ggf. Synchronisiert das den Bus mit dem Uplink für beste Latenz???

Nö, es verdoppelt die Latenz, - wobei das bei 100kBd und der geringen Datenmenge so ziemlich schnuppe ist.

Da wird etwas erzählt, aber niemand ist zu sehen, der zuhört. Ist wie Simultandolmetschen ohne Zuhörer.
Na ja, egal, wenn auch komisch.