J-Log.eu - Forum

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

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!".

_________________
Tom

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

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

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..

_________________
Tom

_________________
Tom

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).

_________________
Tom

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.

_________________
Tom

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

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).

_________________
Tom