JETI Duplex EX

Nun verfügbar für JLog2, Firmware der “Series 4″ im Download, dazu JLC5.
Je mehr Dateneinheiten (“Parameter”) man liefert, desto größer wird die Latenz beim Update, vor allem wird es leider problematisch, wenn sich JLog2 zusammen mit einem oder gar weiteren Sensoren hinter einem JETI Expander E4 EX befindet. Daher wurde letztendlich reduziert auf 15 Werte, gesendet in 3 Paketen.
Basis
1 “U battery” …….. nn.n V (Akkuspannung)
2 “I motor” ………. nnn.n A (Motorstrom)
3 “RPM uni” …….. nnnn rpm (Rotordrehzahl)
4 “mAh” …………. nnnnn mAh (verbrauchte Kapazität)
5 “U bec” ………… n.n V (BEC-Ausgangsspannung)
6 “I bec” ………….. nn.n A (BEC-Ausgangsstrom)
7 “Throttle” .……… nnn % (Gas 0..100%)
8 “PWM” ………….. nnn % (Stelleraussteuerung 0..100%)
9 “Temp FET” …… nnn °C (Temperatur der Leistungs-FETs (Endstufe), bisher “TempPA” genannt)

+

Konfiguration 0 (Standard)
10 “extTemp1″ ……. [-]nn.n °C (JLog-eigener (Steller-externer) Temperatursensor 1 (1/5))
11 “extTemp2″ ……. [-]nn.n °C (JLog-eigener (Steller-externer) Temperatursensor 2 (2/5))
12 “extRPM” ………. nnnnn rpm (JLog-eigener (Steller-externer) Drehzahlsensor)
13 “Speed” ……….. nnn km/h (JLog-eigener Sensor, Prandtl-Sonde (Staurohr) SM#2560)
14 “MaxSpd” ……… nnn km/h (Maximalgeschwindigkeit)
15 “RPM mot” …….. nnnnn rpm (Motordrehzahl)

oder

Konfiguration 1 (Min/Max-Werte)
10 “RPM mot” .……. nnnnn rpm (Motordrehzahl)
11 “Ubat Min” …….. nn.n V (Akkuminimalspannung)
12 “Ubec Min” …….. n.n V (BEC-Minimalspannung)
13 “Imot Max” …….. nnn.n A (Motormaximalstrom)
14 “Ibec Max” .…….. nn.n A (BEC-Maximalstrom)
15 “Power Max” ….. nnnnn W (Maximalleistung)

oder

Konfiguration 2 (alle JLog-eigenen Standardsensoren, ohne Speed)
10 “extTemp1″ ……. [-]nn.n °C (JLog-eigener (Steller-externer) Temperatursensor 1 (1/5))
11 “extTemp2″ ……. [-]nn.n °C (JLog-eigener (Steller-externer) Temperatursensor 2 (2/5))
12 “extTemp3″ ……. [-]nn.n °C (JLog-eigener (Steller-externer) Temperatursensor 3 (3/5))
13 “extTemp4″ ……. [-]nn.n °C (JLog-eigener (Steller-externer) Temperatursensor 4 (4/5))
14 “extTemp5″ ……. [-]nn.n °C (JLog-eigener (Steller-externer) Temperatursensor 5 (5/5))
15 “extRPM” ………. nnnnn rpm (JLog-eigener (Steller-externer) Drehzahlsensor)

oder

Konfiguration 3 (nur 9 Basisdaten+3, die 3 weiteren Sensoren entfallen)
10 “extTemp1″ ……. [-]nn.n °C (JLog-eigener (Steller-externer) Temperatursensor 1 (1/5))
11 “RPM mot” …….. nnnnn rpm (Motordrehzahl)
12 “extRPM” ………. nnnnn rpm (JLog-eigener (Steller-externer) Drehzahlsensor)
Diese Konfiguration wird i.Allg. benötigt, wenn sich JLog mit mehr als einem Sensor hinter einem JETI Expander befindet, also bei 3 bis 4 Sensoren am Expander.  Der Grund ist, dass 2..4 x 1 nun mal ungleich 1, die Baudrate der 4 Sensorinterfaces des Expanders ist dieselbe wie an dessen Ausgang zum Empfänger hin. Jeder Sensor sendet alle 100ms ein Datenpaket teilweise variabler Länge, die Aussendungen der Sensoren erfolgen unkordiniert zueinander. Es können also nicht mehr alle Pakete eines Sensors in die Re-Transmission am Expander-Ausgang kommen. Der Expander dünnt das Datenaufkommen eines Sensors aus im Verhältnis 1:1 bis 1:4, entsprechend 1 bis 4 Sensoren hinter ihm.
Auch ein Expander E4 EX arbeitet dabei nicht sensitiv für enthaltene Daten (Sensor- und Display-Adressen), sondern er sendet immer nur das letzte vollständig empfangene Paket eines Sensors. Je mehr Pakete ein Sensors benötigt, um alle seine Daten einmal auszusenden, je mehr Sensoren sich hinter dem Expander befinden, um so wahrscheinlicher wird es, dass bestimmte Pakete eines Sensors selten oder so gut wie gar nicht in die Re-Transmission gelangen. Die Folge ist dann, dass einzelne EX-Displays dieses Sensors sporadisch bis nahezu dauerhaft im Terminal (Sender, Profibox) auf Timeout laufen (“——”).
Mit Konfiguration 3 und nur 9 (jetzt 12) EX-Displays braucht JLog2 nur 2 Pakete, um alle seine Daten loszuwerden. Dadurch ist es möglich, dass er auch mit 2..3 weiteren Sensoren ohne Timeout-Effekte im Terminal koexistieren kann.
Konfiguration 0 und 2: Min/Maxwerte (UbatMin, UbecMin, ImotMax, IbecMax, PowerMax) kann man auch auf Seite 5 der alten JETI-Telemetrie (v1.0) lesen, macht man eh erst nach dem Fliegen.
Die gewünschte Sensor-Konfiguration (+6) wird im JLC5 eingestellt:

.

Zwischenzeitlich fand sich auch die Ursache, warum eine DC-16 keine JLog2-Sensoralarme wiedergab, und die JLog-Firmware für JETI EX wurde entsprechend angepasst: Es liegt nicht, wie angenommen, daran, dass ein JETI-Sensor nur noch selbst Alarme auf EX-Daten bilden kann, dagegen aber Alarme von Sensoren ignoriert. (Im Sender auf EX-Daten gebildete Alarme sind komfortabler, weil die Sprachausgabe auch den Momentanwert spricht.)  Die Profibox kann schließlich auch beides, Morsezeichen (jeder Alarmtyp ist ein Buchstabe) auf Voice Files mappen und selbst Alarme auf EX-Werte bilden. Es lag ganz schlicht daran, dass alle Geräte vor der DC-16 diese Alarm-Buchstaben nicht case-sensitive auswerten, es ist egal, ob es sich um einen kleinen oder einen Großbuchstaben handelt, z.B. “a” == “A”. JLog2 sendete kleine Buchstaben. Die Firmware der DC-16 arbeitet dagegen case-sensitive, “a” ignoriert sie, “A” wertet sie aus.
Hier mein Mapping der Voice Files für die Profibox, nur vorschlagsweise:
Morse C -.-. : acoustic capacity alarm “Warnung! Akkukapazität
Morse U ..- : acoustic voltage (Ubat) alarm –> “Warnung! Niedrige Akkuspannung
Morse T - : acoustic temperature (tempPA) alarm –> “Warnung! Hohe Temperatur A
Morse M – : acoustic BEC (Ubec dip) alarm –> “Warnung! Niedrige Spannung MaxBEC
Morse N -. : acoustic eXternal temperature alarm –> “Warnung! Hohe Temperatur B

.

Parameter-Auswahl und Seitengestaltung sind natürlich frei mit EX Displays, Profibox, DC/DS-16.
JETI v.1 Box (nicht-EX), Seite 5: Min/Max-Werte.
.

Adressierungsproblem in JETI EX (ein Bug IMHO)
Obwohl jedes JETI-Terminal (die Sender und die Profibox) suggeriert (und es scheinbar auch tut), dass gelernte Sensoren (->Profil) gelöscht werden können,  -  scheint es sich die einmal unter einer Sensoradresse gesehene Datenstruktur (die Displays der einzelnen Sensordaten) für immer zu merken. Das führt dann zu Problemen, wenn ein Multisensor wie JLog2 mit unterschiedlicher Anzahl Daten arbeiten MUSS (wg. der Expander-Problematik). Entweder verbleiben “Zombie-Displays”, wenn mit verringerter Anzahl Daten betrieben wird, aber das Terminal zuvor schon mal mehr sah (also von JLog config #0..2 auf #3), oder zusätzliche Daten verweigern ihr Display (von #3 auf #0..2). Das kann aber nur zu hinderlicher Wirkung kommen, wenn jemand Pre-Releases der JETI EX Firmware auf seinen JLog2 flashte, die dieselbe Adresse verwendeten. Ergo ist das ziemlich selten.
Als Workaround zu diesem JETI Bug verwendet Config #3 (9, nun 12 Daten) eine andere Sensoradresse als die Configs #0..2 (15 Daten).  -  (FYI: Entscheidend für ein Terminal ist nur die Sensoradresse und die relativen Display-Adressen (0..8 / 0..14), die Namen der Displays und die der Units sind dabei völlig egal, während die Dateninterpretation (Kommastellung etc.) eh immer zusammen mit den Livedaten gesendet wird.)
Um nun Leuten, die unter o.g. Problem leiden (Anwender der ersten Stunde, JLog-Forumteilnehmer), zu helfen, gibt es nun auch die Minor Releases .77.  Die Standard-Releases verwenden als Sensoradresse A402 0202 (config #0..2) und A402 0203 (config #3), während die .77 A402 0206 und A402 0207 verwendet.  —  Aber bitte die .77 nur flashen, wenn Ihr das oben beschriebene Problem habt (bisher ist mir nur Marcus bekannt dafür). Ansonsten wäre das eher kontraproduktiv, in etwa so, wie wenn man Antibiotika schluckt, ohne sie zu brauchen. Die Viren werden langsam resistent dadurch, so ähnlich verhält es sich hier um jemals mit einem Terminal benutzte Adressen. :)

Die Kommentarfunktion ist geschlossen.