J-Log.eu - Forum

Genau das tue ich.
12CH geht und 18CH nicht. Da scheint noch was ergänzt worden zu sein bei den neuen Empfängern.

Ach, so rum, 18CH geht nicht. Hmm..

Dann sind wohl meine Rx zu alt, um das zu bemerken.

_________________
Tom

Original Sbus hat aber keine 18 Kanäle, oder? Vielleicht liegt es daran. Ist jedenfalls auffällig.

Mhh, hier steht was interessantes: http://thediveo.blogspot.de/2013/07/fut ... b.html?m=1

Das ist alles 18CH, das Protokoll auf dem S.BUSn, egal, wieviel HF-mäßig geht.

Eigentlich sind das 16CH +2 Schaltkanäle.

Jedenfalls sind es immer 25 Bytes, auf S.BUS1 und 2 identisch, die ein Rx sendet.

Solange ein Sensor keine Daten sendet, sieht S.BUS2 wie 1 aus.

Es gibt allerdings, zumindest theoretisch, eine Unterscheidungsmöglichkeit, ob man auf einem S.BUS1 oder 2 ist. Das ist ja auch sinnvoll, dass ein Gerät (Sensor) es festelllen kann, - damit es nicht sendet, wenn es versehentlich auf S.BUS1 gesteckt wurde.

Leider hat Futaba das bereits in der Vergangenheit nicht genau genommen, - überhaupt ist Futaba selbst derjenige, der am dreistesten die eigenen Specs bricht:

Das 25ste Byte der Aussendung eines Empfängers auf dem S.BUS (1 oder 2, egal, wie gesagt) ist ein Trailer, der in 2 von 8 Bits (6 genutzt) den Mode beschreibt: S.BUS kompatibel oder 12CH oder 18CH primary/secondary Rx.

Wenn jetzt ein Implementator so gutgläubig war, sich daran zu halten, in den betreffenden zwei Bits seinen Mode (S.BUS1, beide Bits Null) zu erwarten, dann wird er nicht erst seit gestern durch einige Rx in den A gekniffen, - weil mein Spezialfreund in Nippon (und seine angeblich nicht vorhandenen Kollegen) so frei war, einfach 18CH Mode Belegung der Bits auch auf dem S.BUS1 anzuwenden.

Warum tut er das?
a) Er raucht das Falsche.
b) Futaba fährt die Sparnummer, siehe auch den daraus damals resultiert habenden Scheiß mit dem 7003, - indem sie im Rx dieselbe Hardware nehmen, um S.BUS1 und S.BUS2 aufzuspannen.

Das geht, wenn man keinen Hardware Design Flaw baut wie im 7003.
Es gibt nur ein "Hindernis": Futaba's eigene Spezifikation, die sagt, dass die beiden Mode Bits Null sind im 25sten Byte des Rx auf dem S.BUS1. Es würde wahrscheinlich Futabas eigene Sensoren abhalten, würde man 00 (S.BUS1 Mode) auch auf dem S.BUS2 senden. Also ist man sich selbst der nächste, scheiß auf die anderen, und sendet lieber 10 bzw. 11 auch auf dem S.BUS1. Sollen doch die doofen 3rd Parties, siehe z.B. DJI, nachbessern.

Ich habe das schon vor >2J getan, nachdem ich merkte, wes Geistes Kind man dort drüben ist. Mir (JLog) ist es schnuppe (muss es sein), was bzgl. Mode im Trailer Byte steht.

Es ist also ganz einfach, und es ist typisch, -- nicht nur für Futaba, für den R/C-Bereich allgemein:
JETI's EX Spec sagt seit Jahren, dass Daten im Cleartext gesendet werden. Tja, und warum senden JETI's Sensoren dann nach der seit 3J veralteten Spec verschlüssselt? (Mir auch egal, hab's geknackt, damit ich die MEZON's auslesen kann.)

_________________
Tom

Verstanden?

Wenn nicht, können wir das gern mal per Tel machen. Ich kann hier nicht illustriert darüber sprechen, habe schließlich mal ein NDA dazu gezeichnet.

_________________
Tom

Passt soweit. Erklärt aber nach meinem Verständnis nicht warum im 12CH Mode vieles funktioniert hat. Hatte auch gelesen, dass dem Bus der Modi egal ist, aber irgendwas stimmt da nicht. Oder der Empfänger kommt plötzlich auf die Idee Sbus1 Flag zu senden, weil er keine Telemetrie mehr braucht.