Keine akustischen Alarme mit JLOG2

Grandiose Nachrichten !!!
Dann kann ich mir den Kabelsalat mit UniLog und seinem kleinen Bruder bald auch noch sparen !
Ich bin geradezu entzückt über die Entscheidung auf DC-16 umgesattelt zu haben.

Grad das neue Firmware-Upgrade von Dr. Tom aufgespielt !

Was kann man da noch sagen - genialer geht es garnicht !!!

Der JLog2 war ja eh schon immer super, aber jetzt wo es Jeti EX spricht ist dass Ding einfach nur noch genial !
Man bekommt 24! Parameter zur Verfügung gestellt und kann frei wählen.

Geil, geil, geil !!!

Banjoko wrote: Man bekommt 24! Parameter zur Verfügung gestellt und kann frei wählen.

Ich hoffe, die Sensor-Hersteller denken mal bei Gelegenheit daran, direkt im Sensor eine Möglichkeit einzubauen, welche Parameter tatsächlich über die Telemetrie übertragen werden sollen, sonst gibts bald mal einen gewaltigen Stau am Rückkanal und wichtige Werte kommen zu spät oder gar nicht bis zum Sender durch...

Moin !

Heute bin ich zum ersten Mal überhaupt mit der DC-16 und JLog2 im T-Rex 600 geflogen.
Bin einfach nur geflasht - das Steuergefühl des Jeti Senders ist ja mal echt geil und die Kapazitätsalarme aus dem JLog mit Sprachansage funktioniert auch wirklich perfekt !

Beides sowhl die DC-16 als auch den JLog2 gebe ich nicht mehr her - genial !!!

vG

Matthias

Ich hoffe, die Sensor-Hersteller denken mal bei Gelegenheit daran, direkt im Sensor eine Möglichkeit einzubauen, welche Parameter tatsächlich über die Telemetrie übertragen werden sollen, sonst gibts bald mal einen gewaltigen Stau am Rückkanal und wichtige Werte kommen zu spät oder gar nicht bis zum Sender durch...

Darauf möchte ich mal eingehen:

Zunächst: Weil die Userwünsche eh immer individuell sind und jeder Anwender seine Vorstellungen für primär erachtet, - ich aber andererseits auf möglichst geringe Latenz beim Update der EX-Daten zu achten habe, - bin ich dann doch von der in der Protokollbeschreibung eh etwas "versteckt beschriebenen" erweiterten Adressierung ab gegangen und sende nur noch 15 Parameter. Stattdessen kann es der Anwender konfigurieren am Sensor (JLog), - es gibt ein Base Set von 9 Parametern plus ein aus drei wählbaren Option Sets mit weiteren 6 Parametern, einen Mix, den ich als "Standard" bezeichne, eines für Liebhaber von Min/Max-Werten online, ein's für alle JLog-eigenen Sensoren des Standards, ohne Speed und solche Spezialsachen. Nachzulesen hier .

Nun zu dem von Dir befürchteten Stau im Rückkanal, hierzu gibt es zwei Betrachtungswinkel, den Bus und die HF-Strecke/Protokoll.
Bus: Zunächst, okay, das ist eigentlich kein Bus, sondern eine Punkt-zu-Punkt-Verbindung, Terminal eben, aber via einen EX Expander kommt ein bus-ähnliches Verhalten für EX-Daten zustande, natürlich nur unidirektional.
Im Allgemeinen sendet jeder Sensor ca. alle 100ms. Er sendet "stumpfheil in die Gegend", weil es ja kein Bus ist, es gibt keine Arbitration.

Die Daten, worst case (Maximum):
- Hidden Message v1.0, alarm: 4B
- Hidden Message v1.1, EX: max. 29B
- Hidden Message v1.0, Expander Navigation: 3B
- Simple Text, Terminal v1.0: 34B
Das sind 70 Bytes.

Einzelner Sensor:
Baudrate ist 9600Bd, 9 Bits, 2 Stop Bits, also 12 Bits per Zeichen. Die 70 Zeichen werden in 87,5ms ausgesendet. On top kommen die 1..3 Gaps zwischen den Teilpaketen.
Der "Bus" hat einen max. Duty Cyle von 87,5/(87,5+100)=46,7%, also rund fifty-fifty.

4 Sensoren via EX Expander:
Der Expander muss worst case 4(Alarm) + 29(maximales EX-Paket) an den Empfänger weiter geben.
Dazu kommen 34 Zeichen für einen Sensor, mit dem wir uns gerade in einer JETIv1.0-Terminalsitzung befinden.
Das sind in Summe 166 Zeichen, zu deren Aussendung 207,5ms benötigt werden.
Mit einer nominalen Update Rate von 100ms je Sensor geht das schon mal gar nicht, selbst mit nur 4 EX-Messages 'a maximal 29 Bytes ginge das nicht, denn die brauchen 145ms zum Aussenden, das Datenaufkommen der Sensoren über die integrierte Zeit ist höher als die Buskapazität.
Vermutlich wird ein Expander hier roundrobin die gepufferten Daten nach den Möglichkeiten senden, vielleicht sogar mit Priorität für eine JETIv1.0-Message (Terminalsitzung). Es muss jedenfalls angenommen werden, dass ein EX-Expander zusätzliche Latenz bzgl. des Updates binärer EX-Daten einbringt, indem er Übertragungen auslässt.

Nun kommt die HF-Strecke und ihr Protokoll hinzu, diese hat Limits bzgl. des Duty Cycles, - allerdings muss man berücksichtigen, dass die Übertragung sehr viel schneller als mit effektiv 9k6 erfolgt. Im Allg. gibt es hier Frame Size Limits, soundsoviel Zeichen können mit einer Message im Rückkanal übertragen werden. Das Limit bei JETI Duplex ist mir nicht bekannt, aber nicht umsonst limitiert das Protokoll den einzig variablen Teil, die Hidden Message v1.1 (EX), auf max. 29 Bytes.

Ich glaube jedenfalls, dass höchstens der DC des Busses hier limitierend sein kann, nicht aber die Übertragungsstrecke, und der Bus ist noch weit entfernt von Overrun mit einem einzelnen Sensor, und eh potentiell überfordert hinter einem Expander.

---

Ein ganz anderes Thema ist die Latenz von Updates. Nun, vom Visuellen her sollte das eigentlich schnuppe sein, wer starrt schon ständig auf's Display beim Fliegen. Rein theoretisch wäre es interessant für Alarme, ob nun vom Sensor via die entsprechende Hidden Message v1.0 gemeldet, oder im Terminal gebildet. Allerdings reden wir dabei von akustischen Alarmen, und state-of-the-art von Voice Alarm. Tja, dieses Gequassel impliziert eine Crux, es ist grundsätzlich sequentiell, - soll ja nicht wie beim Geburtstag zugehen. Die kürzeste Voice Message braucht 2 Sekunden, das klingt schon lustig genug, unabhängig von dem "bemerkenswerten" Deutsch der Sprecherin on top, deren Englisch ist noch lustiger.
Heisst also, solange ich keinen Virbrationsalarm habe, kann ich Latenzen von bis zu 2 Sekunden und mehr bzgl. der Alarmgabe systembedingt gar nicht bemerken, - ich kann sie nicht verhindern. Somit sind andere Systeme da immer noch fein raus, HoTTv4, z.B., wo es ziemliche Latenzen geben kann, wenn sich viele Sensoren (unterschiedliche Adressen) auf dem Bus befinden, genauer gesagt, wenn diese zur Abfrage konfiguriert sind.

Ein Thema könnte es für Logging im Terminal sein. Nun, ehrlich gesagt, davon halte ich eh nicht so viel. Grund ist, dass bestimmte Daten eines zeitnahen und teilweise auch zeitgenauen Recording bedürfen, und das kann man über die Strecke nicht garantieren.

Wie schon oben bemerkt, trotzdem war es mir wichtig, die Latenz im Update von EX-Daten zu drücken:
Übertragen werden immer zwei Werte in einem EX-Paket, protokollbedingt. Es braucht also zunächst mal 8 Runden, um 16 "Parameter" auszusenden. Wir senden effektiv nur 15, weil nicht (mehr) im "Enhanced Address Mode", Adresse 0 ist in einem EX-Paket vom Typ "Text" reserviert für den Text, der das Gerät bezeichnet, hier "JLog2". Der 15te Wert wird zweimal gesendet in einem binären EX-Paket, wie gesagt, protokollbedingt müssen es immer zwei sein.
Somit sind es letztendlich 9 Runden, 8x binär, 1x text, die die Latenz bzgl. der binären EX-Daten ausmachen.
Rechnerisch: 81,92ms(Wiederholzeit v.JLog2) x 9 = 737,28ms

Bleiben noch die Texte, wir haben 15+1, 15 als Parametername, der 16te ist der Gerätename.
Ein Text kommt immer in der 9. Runde, s.o. Es braucht also 9x15 Runden, um alle Parameternamen auszusenden. Alle 9x15 Runden kommt eine zusätzliche Textrunde mit dem 16. Text.
Somit dauert es ((9 x 15) +1) x 81,92ms = 11,14s, bis alle Texte einmal überschrieben wurden, was dicke ausreicht.
(Zumindest mit der Profibox ist es wohl so, dass dabei nicht die Parameternamen im Display überschrieben werden, sondern nur in der Auswahl. Die Box kopiert einen Namen aus der Auswahl in ein Display, also einmalig und manuell getriggert.)
Wg. des 16ten Textes schliesst sich alle 9x15 Runden eine zusätzliche Textrunde an, das Update der binären EX-Daten erfährt hier eine Latenz von 819,2ms.

So, dat war's.

Jedenfalls hat die Anzahl gesendeter "Parameter" nichts mit der Kapazität des Rückkanals zu tun, - soviel zu "Rückstau"; - aber alles mit der Updatelatenz. Dein Zeigefinger wackelte zwar, Sabine, nur in die falsche Richtung.

Gruß. Tom

P.S. Es tut mir leid, Leute, dass es so lange gedauert hat mit dem EX Upgrade, - ich hatte einfach keine Profibox z.V., und einen DC-16 schon gar nicht. Mir wurde auch erst jetzt die Schärfe des Problems klar um die fehlenden akustischen Alarme mit der DC-16. JETI ist hier offensichtlich sich selbst untreu geworden, indem sie nicht, wie mit der Profibox, Alarme (Morsezeichen) auf Voice Files mappen, stattdessen die Hidden Message "Alarm" komplett ignorieren. Der "Schwenk" mit dem ersten JETI-Sender scheint darin zu bestehen, dass Alarme nur noch im Terminal gebildet werden.