J-Log.eu - Forum
http://j-log.eu/forum/

CVS16: OOB und OOIRD als Telemetriewerte
http://j-log.eu/forum/viewtopic.php?f=26&t=924		 Seite 1 von 2
Autor:  Ingmar [ 21. Jan 2017, 15:08 ]
Betreff des Beitrags:  CVS16: OOB und OOIRD als Telemetriewerte
Hallo ans Forum,
da ich mich seit Stunden vergeblich bemühe die Alarme OOB und OOIRD auf meine Jeti zu bekommen, habe ich folgenden Wunsch:
Ich hätte gerne die OOB- und OOIRD-Werte als Telemetrie Werte.
1. Kann ich die Alarmschwellen im Sender einstellen und
2. kann ich dann die Alarmmeldungen auch auseinanderhalten.

Momentan werden die ja auf den Ubat Alarm aufgelegt.
Diesen Alarm bekomme ich mit einem alten Jeti-Sender (nicht EX) als Morsecode ..- (U) auch gemeldet.
Bei der DC24 habe ich die Morse-Alarme eingeschaltet, und für U auch einen Text zugewiesen, aber es kommt kein Alarm.
die anderen Telemetrie Werte Spannung, Niedrigste Zellenspannung und Nr. kommen alle an, die von Jive natürlich auch.
Nur halt keine Alarme...

Ach ja, der CVS16 hängt an einem S32.

Vielleicht ist das Problem ja schon besprochen worden, aber bei der Suche nach "Jeti alarm" kommt, das es zu viele Treffer gibt, und sie deshalb nicht angezeigt werden können.
Eine eigene Suche brachte aber keine weiteren Erkenntnisse.
Viele Grüße
Ingmar
Autor:  dl7uae [ 21. Jan 2017, 20:23 ]
Betreff des Beitrags:  Re: CVS16: OOB und OOIRD als Telemetriewerte
Hi Ingmar!

Alle spannungsbezogenen Alarme werden auf den einen "Ur"-Spannungsalarm gemapt, "Ubat".
Es gibt nur den einen Alarm. Mit einem CVS wird der parallel gespeist von:

- Ubat Alarm: generiert per Schwelle auf Gesamtspg. durch JLog (S32). Ubat ist hier TPV (Total Pack Voltage) vom CVS, - sie ersetzt den Wert von einem ESC, wenn der so etwas liefert
- Zellspannungsalarm, generiert von JLog(S32) durch Schwelle auf LCV (Lowest Cell Voltage), vom CVS kommend
- UC (UnderCharge) Alarm, vom CVS kommend. Der kommt nicht mehr, sobald JLog(S32) einmal Stromfluss an den CVS signalisierte (Motor)
- OOB Alarm vom CVS
- OOIRD Alarm vom CVS

Es sind also 5 Alarme, die im Output zu einem Telemetriesystem als ein Spannungsalarms auf Ubat erscheinen.

Will man wissen, was triggerte, schaut man hinterher im Log nach, - dort sind alle Alarme vereinzelt, im Falle von OOB und OOIRD für jeweils bis zu 4 Zellen, die die Alarmbedingung erfüllen.

Die Telemetriesysteme sind sehr unterschiedlich.. Teilweise können sie fast nix, teilweise gäbe es Möglichkeiten für vereinzelte Alarme, - wobei oft gar keine Alarme von einem Sensor angenommen werden. Siehe z.B. ein SPEKTRUM Display, in dem man den Sender selbst solche Alarme generieren lässt:


Generell bin ich gehalten, es einheitlich zu tun, um Chancen zum Verwirren der User zu vermindern.
Generell geht es um einen Alarm, - "Hallo, da is was faul mit der Bakterie!".
Autor:  Ingmar [ 22. Jan 2017, 11:36 ]
Betreff des Beitrags:  Re: CVS16: OOB und OOIRD als Telemetriewerte
Hallo Tom,
so hatte ich mir das gedacht.
Ich habe am S32 Anschluss 1 auch das Fehlersignal als Morsecode.
Ein alter Jeti Sender morst mir das auch.
Nur der neue (DC24) will den nicht verarbeiten.
Hast Du Informationen, was da faul sein könnte?
Dem Morsecode (U) habe ich eine Meldung zugeordnet, nur kommt die nicht...

Was spricht dagegen die beiden Werte (OOB u. OOIRD) noch als Telemetrie-Werte auszugeben?
Ich würde mich jedenfalls sehr freuen!!!

Ingmar
Autor:  Ingmar [ 22. Jan 2017, 12:48 ]
Betreff des Beitrags:  Re: CVS16: OOB und OOIRD als Telemetriewerte
Hallo Tom,
noch eine Zusatzinformation:
Ich habe einen Sensor (Jeti M-Bar), der auch Morsecode Alarme ausgeben kann.
Dieser funktioniert, mit meinen momentanen Sendereinstellungen, einwandfrei.
Auch mit Code U und einigen anderen getestet.
Da scheint mit der Alarm-Übermittlung auf Deiner Seite was nicht zu stimmen.

Wenn Du jemanden zum Testen brauchst, ich stehe zur Verfügung.

Viele Grüße
Ingmar
Autor:  dl7uae [ 22. Jan 2017, 13:41 ]
Betreff des Beitrags:  Re: CVS16: OOB und OOIRD als Telemetriewerte
Wie jetzt? Du hast zusätzlich eine Alarmleitung definiert am S32, im Mode Morse?

Oder meinst Du einfach, dass die Alarme vom S32 (ein Buchstabe) nicht akzeptiert werden vom Sender?

Ich habe keinen JETI Sender, nie gehabt, nur mal pumpweise ein paar Tage, vor Ewigkeiten. Habe eine Profibox, und die bringt alle Alarme vom S32.

Weshalb ich damals (JLog2.0) den Sender leihweise bekam: Bevor JETI den ersten eigenen Sender brachte, war es egal, ob man die Alarme als große oder Kleinbuchstaben sendete. Ich nahm große. Dann, mit der DC16, war es plötzlich nicht mehr so, man wollte Kleinbuchstaben.
Nicht, dass sie es mal eben wieder umdrehten..
Autor:  dl7uae [ 22. Jan 2017, 13:46 ]
Betreff des Beitrags:  Re: CVS16: OOB und OOIRD als Telemetriewerte
Zitat:
//mapping voice file
#define aCa 'c' //JETI: acoustic capacity alarm "Warnung! Akkukapazität." <--
#define aUa 'u' //JETI: acoustic voltage (Ubat) alarm --> "Warnung! Niedrige Akkuspannung." <--
#define aTa 't' //JETI: acoustic temperature (tempPA) alarm --> "Warnung! Hohe Temperatur A." <--
#define aMa 'm' //JETI: acoustic BEC (Ubec dip) alarm --> "Warnung! Niedrige Spannung MaxBEC." <--
#define aNa 'n' //JETI: acoustic eXternal temperature alarm --> "Warnung! Hohe Temperatur B." oder "Warnung! Niedrige Spannung B." <--
#define aEa 'e' //JETI: HighTempBEC
#define aKa 'k' //JETI: acoustic eXternal temperature alarm --> "Warnung! Niedrige Temperatur B." oder "Warnung! Niedrige Spannung B." <--
#define aGa 'g' //JETI: sign weak or sign loss (GPS, to be assigned by user!)
#define aVa 'v' //JETI: acoustic LowSpeed alarm
#define aBa 'b' //JETI: acoustic HighSpeed alarm
#define aHa 'h' //JETI: high RPM
#define aLa 'l' //JETI: low RPM
#define aIa 'i' //JETI: high current
#define aWa 'w' //JETI: low voltage A
#define aXa 'w' //JETI: low voltage B
#define aZa 'z' //JETI: low cell voltage
//NAZA
#define aAa 'a' //JETI: altitude
#define aDa 'd' //JETI: distance
#define aJa 'j' //JETI: unassigned now timer alarm
Autor:  dl7uae [ 22. Jan 2017, 13:58 ]
Betreff des Beitrags:  Re: CVS16: OOB und OOIRD als Telemetriewerte
Um dieser von JETI verursachten Konfusion ein Ende zu setzen, gibt es eigentlich nur eine Möglichkeit: Ich sende abwechselnd als Klein- und Großbuchstaben.
Alle 2,5s wird Alarm wiederholt bzw. ein anderer, anstehender Alarm ausgegeben. Da das Terminal (Sender) immer nur kleine oder große Buchstaben versteht, wird dadurch der Abstand der Alarmgabe verdoppelt.
Habe es eben in die Source getan, aber noch keine 1.24 erzeugt/deployed (Binary).
Autor:  dl7uae [ 22. Jan 2017, 14:08 ]
Betreff des Beitrags:  Re: CVS16: OOB und OOIRD als Telemetriewerte
Natürlich sind noch genügend Buchstaben verfügbar, um OOB und OOIRD gesondert zu signalisieren.

Natürlich würdest DU einfach auf einen WAV File mappen, besser einen passenden selbst machen und in den Sender bringen, dafür.

Aber.. die anderen User.. Wenn ich jetzt zwei Buchstaben dafür nehme, habe ich garantiert 30 Leute an der Backe, die die Sprachausgabe der Standardzuweisung Scheiße finden, es nicht selbst ändern können.
Alternative wäre, dass ich wieder mal ein fremdes Produkt erkläre (JETI Alarm--WAVfile Mapping) in einem Manual von mir.
Was wird passieren (passierte mit JLog2.x)? "Der Tom ist ein Chaot, sein Manual versteht keine Sau, ist viel zuviel" ... besonders, wenn man es gar nicht las.
Autor:  Ingmar [ 22. Jan 2017, 14:56 ]
Betreff des Beitrags:  Re: CVS16: OOB und OOIRD als Telemetriewerte
Hallo Tom,
ja ich hatte einen Alarmausgang definiert um überhaupt zu sehen, ob der S32 den Alarm auch ausgibt.
Den werde ich, wenn möglich, später wieder entfernen.

Mal schauen, ob Uppercase / Lowercase was bringt.

Ich hatte eigentlich gedacht den OOB-Wert also z.B. 1.5%
Und den OOIRD ebenfalls als Wert, z.B. 20% als Telemetriewert zu übertragen.
Dann kann ich und alle anderen Nutzer, halbwegs intelligenter Systeme, auf die Alarme per Buchstaben / Morsecode komplett verzichten.

Vbat / TPV, LCV und LCN gibt es ja schon.
Die dazu notwendigen Alarme kann man sich ja im Sender leicht selber erzeugen.
Fehlen halt nur die beiden %-Werte, die man ja so nicht, aus anderen Werten, ableiten kann.

Ingmar
Autor:  dl7uae [ 22. Jan 2017, 16:25 ]
Betreff des Beitrags:  Re: CVS16: OOB und OOIRD als Telemetriewerte
Nein, Werte zu übertragen, ginge nicht. (Es wäre auch nicht im Sinne der Übung: Sinn der Übung ist grundsätzlich einfach nur Alarm, das Wie und Warum ist Sache des "IQ" des CVS, warum soll der User einbezogen werden? Für mehr Info zwecks Forensik gibt es einen extra Log Channel (4). Mancher hat nur "Spieltrieb", - nur.., der Spieltrieb des einen ist die Verwirrung des anderen, was ich dann auszubaden habe.)

CVS hat sein Parameter Set, bekommt es von JLog (S32). Er generiert auf Basis dessen seine Alarme, übergibt aber nicht, dass eine momentane Abweichung von soundsoviel zu einem Alarm führte.
Er sagt nur die Zellenummer von bis zu 4 Zellen, die die jeweilige Alarmbedingung erfüllen.
Diese landet auch im Log.

Ich könnte nun wie für SPEKTRUM die Nummer der jeweils ersten Zelle, die OOB oder OOIRD erfüllt, übergeben, - darauf keinen Alarm in the JETI Telemetrie geben, sondern der User sagt im Terminal: Alarm, wenn ungleich Null.

Allerdings ist der Aufwand dafür relativ hoch, im S32 und im S32terminal. Es bräuchte eine fünfte, ... Sensor Compilation, - im Augenblick haben wir 4 davon.

Außerdem: So eine Alarmbedingung bestünde u.U. nur für den Bruchteil einer Sekunde. Nur, dass jeder Alarm druch JLog auf 5 Sekunden in der Ausgabe gestretcht wird. Den Wert im Display sehen zu können..., a) kaum vorstellbar, b) kaum sinnvoll. ... c) wird der terminal-generierte Alarm zu kurz anstehen. Die Latenz im Update via Telemetrie kommt on top.

Zum Spielen gibt es btw. Text Displays durch S32 mit allen Zellespannungen (im Gegensatz zu JLog2.x).
Seite 1 von 2 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/