J-Log.eu - Forum

dslraser,

dieses Verhalten erscheint mir aber tatsächlich sehr Expander-typisch. 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.

Sprich, wenn dort an diesem neuen Rx mehrere JETI Sensoren angeschlossen werden können, dann kann da eigentlich nur ein Expander drin sein. Ich glaube eigentlich nicht an ein plötzlich neues Geheimprotokoll, denn auch Sensoren von JETI können das nicht per Telepathie gelernt haben. Es ist einfach der oben beschriebene Expander-Effekt, und primitive Sensoren, die meist nur einen Typ Datenpaket senden, betrifft es dann eben nicht so wie Sensoren, die mehr Displays zu bedienen haben, daher 2..3 oder gar mehr Typen Datenpaket dafür benötigen. Seitens JETI wäre z.B. der MEZON ein Sensor, der etwas mehr loszuwerden hat.

------------
Was nun das (einmalige) Lernen der Displays durch das Terminal betrifft: Es würde sicherlich helfen, einmal JLog allein am Rx zu haben, ohne einen anderen Sensor (ohne Spirit), bis das Terminal alle Displays gelernt hat.
Sollten dann hinterher, wenn es um das Updaten der Displays geht (Daten), Timeout-Effekte auftreten, dann Config 3 in JLC einstellen.

_________________
Tom

Hallo und vielen Dank für Deine Ausführungen.
Irgendwas muß aber trotzdem anders sein zwischen 2.5 und 2.6.
2.5 ist schneller und die Daten sind regelmäßig da. Beim 2.6 habe ich sehr oft ein blinkendes Display, oder manchmal gar keine Daten.
Bisher allerdings alles nur auf der Werbank. Vielleicht komme ich am WE zum fliegen und kann weiter berichten.

Bein 2.6 habe ich ja das Datenpaket #3 gar nicht erst eingelesen bekommen. Habe ich mehrfach probiert, allerdings mit Spirit drann. (sonst initialisiert der Regler gar nicht erst-oder ist das egal ? ) Beim 2.5 habe ich überall das Paket#1 drauf

Bitte ohne weiteren anderen JETI Sensor die Displays lernen lassen, ohne Spirit, natürlich nur auf der Werkbank. Das Terminal lernt das einmal und merkt es sich, es muss es nicht jedes Mal lernen, daher ist es egal (auf der Werkbank), ob ein Spirit initialisierte.

Unterschied 2.5 2.6: Von der Hardware her unmöglich. Was die Firmware betrifft: Wie gesagt, bitte mal den 2.5 mit der konsolidierten Variante von dessen Firmware verwenden. Verhält er sich dann genauso wie der 2.6, gibt es tatsächlich einen Unterschied zw. 2.5 und 2.6, und zwar zw. der alten Firmware vom 2.5 und der neuen des 2.6, die sich auch in der konsolidierten des 2.5 abbildet. Es gibt Unterschiede: Seit 2.6 (und in konsolidierten Firmwares für 2.5 und 2) sind ein paar Displays adaptiv, je nach Status, siehe Online Manual, JETI Telemetrie Chapter. Das ist z.B. der Fall, wenn man einen HV²BEC verwendet oder einen CVS16. In so einem Fall fällt uns dann ein Expander auf's Bein, weil die adaptiven Display-(Um)definitionen evtl. zu langsam oder nie vom Expander an die Leitung durchgereicht werden, - das Terminal sieht sie nicht just-in-time. Config 3 verwendet das aber nicht. Das heißt aber auch, dass man mit Config 3 mit HV²BEC oder CVS16 als JLog-eigene Sensoren etwas Trauer hat in JETI Displays.

----------------
Mein Gefühl (und mein JETI-Wissen - ohne irgendeine interne, informationelle Basis zu JETI, leider) will mir übrigens sagen, dass "EX Bus" Marketing ist, - dass das die rückwärtigen Kanäle eines im Rx eingebauten Expanders sind, that's it.

_________________
Tom

Das einlernen habe ich ja schon hinter mir. Das dauerte halt bei 2.6 wesentliche länger.
Im Betrieb auf der Werkbank ist halt beim 2.6 manchmal nix im Display oder sehr oft blinkend, das war/ist bei den 2.5'ern deutlich besser.

Die neuen RX habe ich halt gekauft weil ich auf das Spirit umgestiegen bin, da dies in Jeti "integriert" wurde. Bisher habe ich den RSAT2 oder R9 benutzt. Da das Spirit am RSat2 oder R9 an Extern angeschlossen wird (wenn man die "Integration" nutzen will und dann auf Jeti EX umstellen muss hätte man halt keine möglichkeit JLog anzuschließen, was die neuen RX halt können/sollen, durch die zusätzlichen Ports. Das Spirit bietet ja auch noch andere Optionen wie Udi usw., dann kann es aber nicht über den Sender (z.B. am Flugfeld) eingestellt werden, da bliebe dann nur wieder Laptop mit nehmen, oder Bluetooth und Handyapp.
Irgendwie Schade das Ganze.....

Wenn Du es schaffst, kannst Du mir für den 2.6 ja trotzdem mal das 2.5'er Kleidchen basteln, ich würde das gerne noch probieren.

PS: bei 2.5 habe ich ja die konsolidierte Variante drauf und es gibt diese Unterschiede.

Das mit dem "Kleidchen" ist schon passé, es hätte nur evtl.(??) das "Anmelden" der Displays verkürzen können.

Es gibt keine Unterschiede zw. den Firmwares 2.6 und 2.5 consolidated.

Bitte teste mal auf der Werkbank ohne Spirit dran, meine Vermutungen sind augenblicklich rein auf den integrierten Expander abgestellt.

------
Wir haben einen REX-6 bestellt, um das mal selbst beäugen zu können und evtl. eine Lösung zu bauen.

_________________
Tom

Ich habe eben bei einem 2.5 nochmal was probiert. (die Displays waren ja schon eingelernt) Da ist Config 1 drauf gewesen und ich habe nur die SD Karte raus gemacht und auf Config 3 gewechselt, wie von Dir empfohlen und dann die SD Karte wieder rein. Das Interessante, dann findet er den Jlog 2.5 nochmal im Sender und fängt selbst an wieder einzulesen. Zum Schluß waren dann fast 30 Werte eingelesen. Es waren sozusagen zwei Jlog 2.5 (gleiches Gerät) obwohl ich nur die Config gewechselt habe.

Das passiert, weil Du vorher nicht das "Profil" (wie das in der Profibox heißt) löschtest. Vorher hattest Du den 2.6 eingelernt. Für das Terminal sind 2.6 und 2.5 unterschiedliche Sensoren, das ist so gewollt (von mir).

_________________
Tom

nein, 2.5 mit konsolidierter Firmware mit einem Jlog 2.5 mit Config 1, dann nur die Config gewechselt auf Config 3. (nix 2.6 )

Ich hab Mist erzählt, es hat einen anderen Grund. Zitat aus der Source:

#define conf3ID 1 //use different sensor ID A402 0203 (in place of A402 0202) if 9-item config #3 is used
//terminal seems to remember the number of items a sensor sends which has ever been seen under a certain ID

Ich bin schon (lange) soweit, dass ich bei mir selbst nachlesen muss.

Es handelt sich um einen Workaround, weil das Terminal offenbar ein Problem hat, wenn unter derselben ID (nicht der Name, eine binäre ID) plötzlich weniger "Displays" kommen. Sprich, Config 3 verwendet daher absichtlich eine andere ID, die ist aber bei 2.5 und 2.6 identisch.

Muss gleich mal gucken, ob ich das im Manual erwähnte.

Meine Dokumentationen werden ja verflucht. Linus erklärt mir das ganz einfach: Die meisten User wollen keine Erklärungen, sie wollen nicht wissen, warum, sie wollen nur wissen, wie.
Manchmal, wie in diesem Fall, ist das schwer zu machen.., die Ausgangsbedingungen sind zu komplex, es ohne Verstehen der Zusammenhänge machen zu wollen. Teilweise ließ ich es daher weg, um es auf Anfrage zu erklären, siehe evtl. hier.

------------
Es ist im Manual erwähnt, aber in dem Addon Teil des Chapters, vor dessen Lesen ich den "normalen Anwender" warne, ehe man mich wieder schlachtet.
Zitat:

_________________
Tom

So, ich habe gerade mal jeweils einen Akku mit zwei verschiedenen Helis probiert.
1.Heli:
Jlog 2.5/konsolidiert mit Config #3 (mit reduziertem Datenpaket) an einem Jive 100 LV.
Ergebnis: blinkende Displays und das Log im Sender ist zerstückelt. So ist es leider nicht zu gebrauchen. (auf der SD Karte habe ich noch nicht nachgesehen)

2. Heli:
UnisensE mit neuer (Betafirmware) an/mit einem Koby 40. Keine blinkenden Displays, läuft alles und macht was es soll. Logs im Sender sind vollständig.

RX ist jeweils ein REX 6. JLog/Unisens jeweils am Steckplatz Extern. Spirit FBL ist jeweils an E1, auf Ex Bus gestellt. Der Sender ist eine DS16 mit aktueller Firmware.

Ich warte jetzt erstmal bis Ihr/Du den REX mal unter die Lupe genommen habt.

Schöne Pfingsten..........