erste Fakten zu den REX Rx

brother-tom wrote: Hallo Uli!
Hatte gerade die gleiche Herausforderung .
Am REX Empfänger kannst Du einen beliebigen Servoanschluss auf Serial UDI 12 Kanal (bzw. die notwendige Anzahl) einstellen.
Somit steht der RSAT2 und der Senderanschluss auf UDI.
Anschluss E1 oder E2 gehen auch für den Anschluss des RSAT2.
Hoffe das hilft Dir!
Schöne Grüße,
Tom

Sorry... Korrektur:
E1 und/oder E2 können auf "PPM Eingang" eingestellt werden.
Daran kann dann der RSAT2 angeschlossen werden.
Bei normale Servoanschlüssen geht das leider nicht.
Grüße,
Tom

uwe neesen wrote: hallo Piotre

Das die daten deines R5L so selten (bis 10Sek ???) erneuert werden ist nicht normal.der expander fünftelt den datenstrom, also die vier sensorenanschlüsse und ein datensatz des e4.

Doch ist aber so.

Die 10 Sekunden sind natürlich ein Extremwert. Aber es ist gestern mehrfach vorgekommen.
Der SM GPS Logger hat nämlich unter den 11 Telemetriewerten die "Atomuhrzeit" die die Satelitten aussenden mit dabei. Wenn man dann noch seine Uhrzeit vom Sender einstellt und die Uhrzeit im Display oben rechts angezeigt hat, hat man zwei Uhrzeiten auf dem Display. Da kann man perfekt sehen wie oft die Werte aktualisiert werden

Das liegt aber nicht am R5L sondern am Expander.
Das ist auch öfters dokumentiert, dass der Expander keine gute Performance hat.

Von der Programmiertechnik habe ich nicht so viel Ahnung, aber ich kann dir sagen, dass Dr. Thomas Wankowski der Jlog Entwickler (in der Foren Welt als "dl7uae" unterwegs) die Jeti Sachen selber genau analysiert hat, da er ja das Jeti Telemetrieprotokoll in den Jlog implementiert hat. Der hat damals schon gesagt dass der Expander wohl recht unintelligent ist und hat auch irgendwo gesagt wie man es besser machen müsste.
Der nun in den REX Empfängern vorhandene Expander funktioniert jedenfalls anders als der normale Hardware Expander.

Ich zitiere mal dazu:

Eine Aussage über den bisher erhältlichen Expander:

dl7uae wrote: [...]
Der Expander multiplext einfach seine Ports auf eine Leitg. (Das ist ja leider kein "Bus"!), dabei wird es dadurch dem Zufall überlassen, ob er alle Aussendungen eines Sensors erwischt. Besonders betroffen sind die Anmeldungen eines Sensors (pro Display eine), weil die sehr selten gesendet werden MÜSSEN, im Gegensatz zu Daten.
Background: Weil es kein Bus ist, sendet ein Sensor einfach stumpfheil in die Gegend, und zwar unsynchronisiert jeder für sich, egal, ob jemand signalisiert, dass er was davon hörte. "Jemand" ist das Terminal via den Rx. Wenn es signalisierte, dann interessiert davon nur das eine Zeichen (mehr kommt nicht vom Terminal), das die 4 Bits für die Tasten enthält. Der Sensor hat dadurch die Möglichkeit, anhand der Tastencodes Interaktion herzustellen, indem er den Inhalt des Textdisplays ändert.
Jede Aussendung enthält das Textdisplay aus 2x16 Zeichen und einen EX Message Block für n Displays (und evtl. einen Alarm), der größenbeschränkt ist (binär-typabhängig (Displaydatentyp)). Alle 100 Millisekunden ein Datenblock, und zwar mit nur 9600 Baud. Das ist nicht gerade Rakete. Daher kommt die Typ-Definition je Display (Name, Binärtyp, Nummer) vergleichsweise nur "alle Jubeljahre". Außerdem: Ist der Zeitabstand des Updatens (Daten, Displayerkennung durch Terminal erfolgte) eines EX Displays zu lang, rennt das auf Timeout ("

---

"), also verballert man nur angemessen wenig Zeit mit Definitionsmessages (Display dem Terminal bekannt machen), die ja immer gesendet werden müssen, weil der Sensor nicht erfährt, ob sie das Terminal (Sender/JETIbox hinter dem Rx) bereits gefressen hat.
Nun kommt dieses (leider dumm gemachte) Multiplexen on top. Der Mux (Expander) legt die Aussendung eines Sensors nur noch zu einem Viertel der Zeit (Expander E4 EX) auf die Leitung. Er ist dabei aber völlig zeitlich unsynchronisiert zu jedem der Sensoren, und die Sensoren zeitlich untereinander auch (ist ja kein Bus). Die Chance, dass bestimmte Datenpakete (für bestimmte Displays) dabei zu selten bis nie auf die Leitung geschaltet werden, ist hoch, - je mehr Sensoren angeschlossen, um so höher (er berücksichtigt nur Kanäle hinter ihm, auf denen ein Sensor sendet). Es spielt nun natürlich eine Rolle, wie viele verschiedene Datenpakete ein Sensor benötigt, um alle seine Displays einmal zu updaten. Je mehr, desto höher die Chance, dass der dumme Expander eines nie auf die Leitung ließ. Das ist der Grund, weshalb JLog für diesen Fall eine reduzierte Datenzusammenstellung anbietet, - die benötigt einen Typ Datenpaket weniger.

Es ist nicht alles Gold, was glänzt, und hier liegt die Archillesferse der JETI Telemetrie. Mit dem Timeout-Verhalten des Terminals für ein Display stolpern sie absichtlich über den Stein, den sie selbst auf den Weg legten mit Terminalleitg. statt Bus, 9600 Baud und zwangsläufig Multiplexer (Expander), weil kein Bus.
Es würde sehr viel helfen:
- das Timeout zu entfernen oder zu verlängern,
- vor allem aber, den Expander intelligent zu machen, was wirklich easy wäre: Er muss die Leitung zu einem Sensor hinter sich nach Datenpakettyp durchschalten. Heißt, er liest immer alle Sensoren und bewertet und queued die Datenpakete, entscheidet selbst, was er aussendet zum Rx. Dadurch hat jeder Typ Aussendung eines Sensors eine gleichberechtigte Chance im Rahmen der Kapazität der 9k6 Klingelstrippe.

[...]

Das ist halt genau das was ich bei mir beobachten kann. Bei der Jeti Box Profi gibt es manchmal "- - - - - " im Display, beim Jeti Sender scheint einfach der letzte Wert so lange dargestellt zu werden bis ein neuer kommt.
Das ist völlig unabhängig vom Empfänger. Sobald ein Expander da rein kommt sieht das so aus.


Quelle für diese Zitate: j-log.eu/forum/viewtopic.php?f=21&t=788


Es kam zu dieser aktuellen Diskussion weil Jeti bei den Rex Empfängern die Baud Rate der Telemetrie leicht verändert hat und daher wie hier ja schon diskutiert wurde jede Menge Fremd-Telemtriesensoren nicht mehr funktioniert haben mit den REX Empfängern. Daher musste auch für den Jlog eine neue Firmware veröffentlicht werden.



Hier auch noch eine interessante Sache zum Expander:

dl7uae wrote: Der Expander in JETI EX ist nicht mehr nur eine Vermittlungstelle mit Konzentratorfunktion für gelegentliche kurze Hidden Alarm Messages, er metamorphiert seine Natur dahin, dass er nun vornehmlich Konzentrator für die Komplettpakete (inkl. 34B Display) zu sein hat, weil diese EX-Daten enthalten.

Allerdings, 4*1 ungleich 1
Habe ich 4 EX-Sensoren hinter einem Expander, dann steht mir nur ein Viertel der Leitungs- bzw. Zeitkapazität zur Verfügung, um diese Daten in der Re-Transmission an den Empfänger los werden zu können.
Der Expander muss also die Daten eines Sensors ausdünnen im Verhältnis zur Anzahl der Sensoren hinter ihm, 1:1 bis 1:4.

Der Witz ist nur, dass nun nicht einfach nur die Latenz der Daten eines Sensors im gleichen Verhältnis steigt..
Damit sind wir bei dem eingangs genannten Problem:

Ich weiß nicht, was an einem "Expander E4 EX" nun "EX" ist im Vergleich zum "Expander E4"..
Was er nicht macht: Er lernt nicht die Datenstruktur eines Sensors hinter ihm, wie es ein "Terminal" tut. Damit ist er nicht in der Lage, Daten eines Sensors Display-ID-sensitiv zu puffern und somit dafür sorgen zu können, dass trotz des ausdünnenden Multiplexing an seinem Ausgang jedes Datum eines Sensors auch zur Re-Transmission kommt.
Er scheint stattdessen nur Folgendes zu tun: Er sendet reihum die gepufferten Daten angeschlossener Sensoren, und zwar jeweils die letzte empfangene Aussendung eines Sensors.

Tja..., und da liegt das Problem:

Die Sensoren senden natürlich nicht phasensynchron, und außerdem sendet natürlich auch nicht jeder Sensor absolut genau alle 100ms. On top kommt, dass die Dauer einer Aussendung (Paket) variiert mit der Länge der Hidden EX Message (bis zu 29B) und durch eine evtl. stattdessen mal gesendete Hidden Alarm Message. Der Zeitpunkt, zu dem der Expander eine Aussendung als gepuffert betrachten kann, variiert entsprechend.

Je mehr Pakete ein Sensor benötigt, um alle seine Daten einmal zur Aussendung zu bringen, je größer wird die Wahrscheinlichkeit von "schwarzen Zeitflecken", einige Daten können u.U. nur selten oder fast nie in die Re-Transmission durch den Expander kommen. Die Wirkung auf der "Terminal"-Seite ist dann, dass ein EX-Datendisplay sporadisch Ausfall ("

---

") zeigt bzw. u.U. fast nur noch. (Mit anderen Worten: Der Expander "übersieht" bestimmte Pakete zu häufig, und schließlich ist es ihm leider egal, welche Daten ein Paket enthält.)
Das Ganze ist eine Funktion von zwei Variablen:
1. Wie viele Sensoren befinden sich hinter dem Expander?
2. Wie viele Pakete benötigt ein jeweiliger Sensor, um seine Daten komplett einmal los zu werden?

Wie gesagt, ein Problem der Asynchronität des Timings zwischen Expander (Re-Transmission) und den Sensoren dahinter, keine Überlastung der Leitungskapazität durch den einzelnen Sensor. Das Problem bestünde nicht, würde der Expander EX-Daten per Sensor-ID und Display-ID puffern.
Allerdings ist die Leitungskapazität RX--Expander zu 4x Sensor bei gleicher Baudrate der Auslöser der ganzen Misere.

(Ich schlage JETI vor, der Sache durch eine relativ einfache Firmwareänderung im Empfänger und im Expander zu begegnen:
Der Expander teilt dem Empfänger durch eine weitere Hidden Message, "Feature ID", mit, dass er eine höhere Baudrate unterstützt.
Ersatzweise (einfacher) ginge das auch per Setup des Rx, nur muss der Expander dann auch das passende Feature in seiner Firmware haben.
Der Rx erhöht die Baudrate, vorzugsweise auf mindestens 38k4, der Expander folgt, z.B. per Autobaud.
Und schon wäre alles geritzt. Die Kapazität des Downlinks sollte mMn kein Hemmnis sein.
Hoffentlich sind das nicht alles Software-USARTs und der Prozzi etwas schwach auf der Brust..)

Quelle für diesen Post: jlog.hacknet.eu/forum/viewtopic.php?p=3381#p3381

Mit den neuen REX Empfängern ist das nun eben nicht mehr so.

hier eine Aussage zu den im REX implementiertem Expander:

dl7uae wrote: Moin Piotre!

[...]
dieser Expander scheint jetzt mal richtig implementiert zu sein, nämlich EX-spezifisch, heißt, er multiplext nicht dumm nach Zeit, sondern nach EX Sensor und Message IDs. Sollte man mich etwa erhört haben, sollte JETI meine Meckereien und Vorschläge gelesen haben?

Schade nur, dass die Jungs beim Implementieren des Software UARTs diese Baudrate-Beschränkung einbrachten. Es ist nur eine Annahme, aber eine naheliegende, dass deren neuer Microcontroller auch keine 9 Datenbits kann, wenn das Paritätsbit verwendet wird. Schade auch, dass dann auch noch der Bug um das Lower Half-Byte im Acknowledge Character (Tasten Codes) dazu kam. -- Naja, jetzt schon wieder fast egal: Gefahr erkannt, Gefahr gebannt.

Ich verstehe selber nur einen Bruchteil davon, aber das Prinzip erklärt er ganz gut.
Er könnte sich jedenfalls auf Augenhöhe mit den Jeti Programmierern unterhalten.


Mit Jeti Sensoren gibt es die Expander Problematik wahrscheinlich auch nicht so stark, weil die meist nur 4 Telemetriewerte senden. Wenn da aber ein Jlog, Unisens, oder GPS Logger mit JEWEILS 10-15 Telemetriewerten ankommen sieht die Sache halt anders aus...


Grüße,
Piotre

P.s.:
Könnte es vielleicht sein, dass die Jeti Telemetrie in Zukunft nicht mehr das bisherige Protokoll nutzt sondern auf den EX BUS verlagert wird?

Hallo Piotre

Danke für deine ausführlichen Infos. Mir kommt halt die genante Zeitspanne sehr lang vor.

Neuere Sensoren laufen ja bereits auf dem EX Bus (MVario2, MBar, MAlti), daher liegst du mit deiner Einschätzung sicherlich richtig. Die Einstellmöglichkeiten über die Geräteübersicht sind ja auch viel besser und bequemer als mit der JETI Box Funktion.

Hallo Uwe,

danke auch dir für die Infos, das war mir so noch gar nicht bewusst, dass es schon EX-Bus Sensoren gibt.
Ich habe mal die komplette Anleitung vom MVario2 und auch die Threads dazu durchgelesen.

Gibt es denn neben dem Gerätemanger (was ja durchaus eine sehr gute Verbesserung ist) weitere technische Vorteile durch die EX-Bus Übertragung?
Ändert sich durch die EX-Bus Übertragung etwas von der Datenrate oder der Übertragungsgeschwindigkeit "Latenz" vom Empfänger zum Modell gegenüber dem bisherigen EX Protokoll?
(Ich weiß dass das Mvario2 schneller und besser ist als das alte Mvario, das scheint aber ja am Sensor zu liegen und nicht unbedingt am Ex-Bus, oder? Oder ist der EX-Bus der Grund für die verringerte Latenz?)

Und um vielleicht wieder mehr auf das Thema dieses Threads hier zurück zu kommen:
Haben die REX Empfänger in Verbindung mit EX-Bus Sensoren wie dem MVario2 irgendwelche Vorteile gegenüber den bisherigen EX Empfängern im EX-Bus Betrieb?

Hat z.B. das in Zukunft kommende Datenlogging der REX Empfänger was damit zu tun, ob man einen EX-Bus Telemetriesensor hat oder "nur" einen EX Sensor?


Grüße,
Piotre

Das MVarios 2 ist am EX Bus schneller in der reaktion (soweit meine Info). Man muss aber bedenken, dass eine super schnelle Reaktion bei einem Vario nicht immer von Vorteil ist. Dazu kann Wolgang (WS Tech) eine Menge beitragen.

Und um vielleicht wieder mehr auf das Thema dieses Threads hier zurück zu kommen:
Haben die REX Empfänger in Verbindung mit EX-Bus Sensoren wie dem MVario2 irgendwelche Vorteile gegenüber den bisherigen EX Empfängern im EX-Bus Betrieb?

Ja, weil Sie können EX Bus ausgeben und zusätzliche EX Telemetrie-Sensoren können angesteckt werden. Z.B. EX Bus an eine Weiche und MUI zusätzlich. Das ging mit den "alten"Rx nicht, da die "Ext." Steckung ja mit EX Bus belegt war.

Hallo
hab da auch mal eine Frage zu den Rex Empfängern. Da sind ja meherer Anschlüsse für Sensoren dran.
z.B. kanal 8/E2 geht da jeweils nur ein Servo oder ein Sensor ,oder kann beides gleichzeitig betrieb werden ?
Die Beschreibung von Jeti ist da mal wieder sehr zurückhaltent.