THEMA:

rkruetli schrieb:

An der AC3X habe ich auf Empfängermodus 5 (MPX SRXL) gestellt. Ich habe festgestellt, dass es dann einen Channel Shift um -1 gibt: Geberkanal 1 (DS-14) wird in der AC3X nicht ausgewerter, dafür ist dann Jeti Geberkanal 2 auf der AC3X Kanal 1, Jeti Geberkanal 2 auf der AC3X Kanal 2, etc.

Hi

Hier findet man die Erklärung dafür unter Jeti:
wiki.beastx.com/index.php/SRXL_-_Serial_...ver_Link_protocol/de

Laut Plöchi selber sollte der Kanal 1 an 8er Stelle erscheinen.

Mit einer eigenen SRXL Hersteller-ID/Versionsnummer von Jeti hätte der Decoder die Reihenfolge korrigieren können.

Gruß
Dieter

Ob das eine Beschränkung von UDI ist, kann ich leider nicht sagen - eigentlich kann ich es mir nicht vorstellen. Die ganze SRXL Protokollfamilie definiert ja nur, was in welcher Reihenfolge an Informationen übermittelt wird (wobei die "Akzente" JR XBUS Mode B oder UDI oder was auch immer diesen Regeln folgt). Die Pulsweite selber wird kaum durch das Protokoll definiert (kann mich aber auch irren). Ich glaube eher, dass die Implementation einfach nicht mehr berücksichtigt bzw. man weiss, dass eine grössere Pulsweite irgendwann mal zu Problemen führt (vor allem wenn man eine max. Windowtime für ein Datenpaket hat -> 20ms Time und man muss darüber 8 Kanäle rausgeben die mit Pulsweiten von je 2.25ms (=150%) hat man 18ms ohne noch die Pausen als Delimeter. Wenn man da Analog arbeitet gibts irgendwann mal Probleme. Bei digitalen Signalen sieht die Sache eben ganz anders aus.

Schaut euch das mal an:

www.rc-thoughts.com/2015/01/jeti-ppm-vs-udi-with-vbar/

Wie man sieht, braucht man per UDI z.B. nur 2.5 ms für die Übertragung aller 8 Kanäle. Darum habe ich mich auch schon gefragt, was die Einstellung des Timings bei UDI bringt, der sollte das eigentlich aushandeln/synchronisieren. Dazu komm noch: was nutzt mir ein 5ms (=200Hz) zwischen Empfänger und FBL-System, wenn mein Sender nur eine Abtastrate/Übertragungsrate von 50Hz zulässt (ok, könnte man bei Jeti auf 100Hz stellen.... Fragen über Fragen...

Aber eben, bin da absoluter Laie...

Gruss
raffi

...sorry, letzter Beitrag nicht gesehen.

Das mit dem Mapping von Kanal 1 auf Kanal 8 hat mir Stefan ebenfalls geschrieben. Ich habe einfach festgestell: Jeti DS-14 Kanal 2 schlägt bei der AC3X auf Kanal 1 auf, usw.. Muss ich aber nochmals prüfen. Im Moment ist bei mir in der DS-14 der Kanal 1 einfach nicht belegt, da ich eh nur 7 Kanäle (inkl. AUX) brauche. GAIN z.B. habe ich in der Jeti auf Kanal 7 ausgebend, und das Ding schlägt bei der AC3X auf dem Gain Kanal (Kanal 6) auf. AUX auf Jeti Kanal 8 brauche ich nicht, düfte per definition aber von der AC3X auf Kanal 7 gesehen werden.

Das mit der ID/Decoder: mmm, also beim Microbeast stimmen die Zuweisungen. Das müsste man im AC3X decoder machen. Ich denke mal, ein JR Empfänger wird sich an der AC3X genau gleich verhalten -> Channel Shift.

Aber eben, es tut ja

Raffi

Hallo,

Kann bestätigen, dass der Jeti-Kanal 1 dann ganz hinten in der AC-3X auftaucht, hab ich auch so verwendet.

Ob man den Unterschied zwischen Auto oder z.B. 20ms beim Fliegen merkt kann ich auch nicht sagen.

Meine Einstellung ist Sender standarmäßig auf 100Hz und RSat auf 17 oder 20ms - für mein Fliegen genügts allemal.

Beiliegend noch 2 AC-3X Logfiles von meinem Schreibtischtest, die AC-3X scheint mit 17ms und Auto zurechtzukommen.

mfg
Klaus

Hallo

Das SRXL/UDI wird mit 115200 Baud 8N1 übertragen. Also 8 Datenbits, kein Parity Bit, ein Stopbit. Das Startbit ist mandantory, gibts also immer. Also werden pro Byte übertragener Daten 10 Bit brutto übertragen mit einer Geschwindigkeit von 115200 Symbolen (in diesem Fall Bits) pro Sekunde.

Die Version 2 des SRXL Protokolls von Multiplex überträgt 16 Kanäle und ist so aufgebaut:
www.multiplex-rc.de/service/downloads/sc...nbeschreibungen.html

1 Startbyte + 32 Bytes für Känale + 2 Bytes für Checksumme macht 35 Bytes. Hinzu kommt eine Pause zwischen den Frames von mindestens 1 Byte (10 Bit) Länge. (Bei Graupner käme noch ein weiteres Byte mit der Anzahl der Kanäle vor den eigentlichen Servo Infos hinzu)

Wegen des seriellen Protokolls sind das also 360 Bits.
360 / 115200 = 3,125^-3

Ein Frame mit 16 Kanälen dauert also nur 3,125 Millisekunden. Umgekehrt ist dann die maximale Frequenz 320 Hz mit der die Daten wiederholt werden könnten.

Das ist also die Geschwindigkeit die maximal vom Empfänger zum Stabi erreicht werden kann.

Da die Bandbreite der Funkübertragung beschränkt ist (100Hz bei 16 prop. Kanälen mit der üblichen Auflösung afaik) kann man es auch auf der seriellen Schnittstelle gemächlicher zugehen lassen.

Also ist 10ms (100Hz) genau das was man will.

17ms, 20ms oder 22ms Periodendauer kommen aus der Steinzeit der analogen Pulsweiten Übertragung (PPM). Da ist ein Impuls maximal 2,150 ms oder so lang. Also muss für jeden Impuls diese Maximale Zeit reserviert sein und für jeden Kanal braucht man einen Impuls. Diese werden ja bei PPM in bestimmter Reihenfolge hintereinander als Kette übertragen plus eine Lücke zwischen den Wiederholungen der Kette.

Solche Werte machen heute nur noch Sinn, wenn man Servos an den Empfänger anschließt die keine schnellere Wiederholrate der analogen Impulse variabler Länge können oder eben bei PPM Output. Hier geht es aber doch um die digitale serielle Übertragung der Daten zu einem Stabi.

Dessen Prozessor sollte in der Lage sein die Daten im Interrupt Zyklus von 10ms aus dem in Hardware implementierten UART Teil (serielle Schnittstelle) auszulesen und zwischendurch alles andere zu machen.

Gruß
Dieter

Hallo Dieter,

ich stimme dir vom Prinzip her zu, jedoch gab es beim V-Stabi wohl Probleme, wenn die Wiederholrate unter 20ms gesetzt wurde. Ob das Problem inzwischen behoben ist, kann ich nicht beantworten, da ich keine V-Stabi fliege.

viele Grüße

Wolfgang