J-Log.eu - Forum

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-24T14:30:21+01:00

Ja.., wenn nur ein Alarm ansteht. Sind es aber mehrere, dann muss ich die rechtzeitig rausquälen, ohne das Fräulein Quatschtante zu überfordern.

Statistik: Verfasst von dl7uae — 24. Jan 2017, 14:30

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-24T11:36:40+01:00

Hallo Tom,
ich finde die 5s eigentlich sehr angenehm.
2,5s wären mir, persönlich, zu häufig.

Ingmar

Statistik: Verfasst von Ingmar — 24. Jan 2017, 11:36

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-23T23:04:33+01:00

Der Intervall ist eigentlich 2,5s. Dise Zeit gebe ich für das Gequatsche. Kann es also nicht verringern.

Dass nun Systeme mit in dieser Sache abweichender Firmware nur alle 5s einen Alarm (bzw. einen anderen anstehenden!) bekommen, wurmt mich.

Statistik: Verfasst von dl7uae — 23. Jan 2017, 23:04

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-23T21:38:58+01:00

Hallo Tom,
aber so, wenn Du abwechselnd kleine und große sendest funktioniert es immer.
Wobei ja mein altes TU2 bei groß und klein den Alarm ausgibt. (2,5s Intervall)

Viele Grüße
Ingmar

Statistik: Verfasst von Ingmar — 23. Jan 2017, 21:38

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-23T20:08:38+01:00

Mann Mann Mann... kann man sich denn nicht mal in seiner Entwicklung darauf einigen, ob man große oder kleine Buchstaben will, oder beide akzeptiert?!

Dieser ganze RC-Pfusch geht mir voll auf'n Keks, seit 7J bereits..

Jetzt ist parallel wieder mal Horizon dran.. Die neuen Empfänger, deren X-Bus spielt Scheibe..

------
Wg. der Sender von JETI (zuvor nur TU) musste ich "damals" von großen auf kleine Buchstaben. Jetzt ist es wieder umgedreht?!

Statistik: Verfasst von dl7uae — 23. Jan 2017, 20:08

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-23T18:51:39+01:00

Hallo Tom,
ja, mit der 1.24 kommt der Alarm U ziemlich genau alle 5s.
Vielen Dank!

Gleich mal mit dem alten Sender getestet, da kommt der Alarm alle 2,5s.
Da scheint das alte TU2-Sendemodul Alarme mit groß und Kleinbuchstaben zu akzeptieren und die neuen Sender nur noch Großbuchstaben.

Damit kann ich leben.

Viele Grüße
Ingmar

Statistik: Verfasst von Ingmar — 23. Jan 2017, 18:51

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-23T11:25:40+01:00

Sorry, Ingmar, gestern musste ich dringend was anderes tun.

Hier die 1.24 mit dieser Mod auf dem alternativen Repo #1 zum Test.

Statistik: Verfasst von dl7uae — 23. Jan 2017, 11:25

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-23T07:09:52+01:00

Hallo Tom,
sagst Du mir Bescheid, wenn ich die Sache mit den Uppercase Morse-Code Buchstaben testen kann?
Ob damit der Alarm dann auch vom Sender gemeldet wird.

Viele Grüße
Ingmar

Statistik: Verfasst von Ingmar — 23. Jan 2017, 07:09

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-22T16:25:46+01:00

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

Statistik: Verfasst von dl7uae — 22. Jan 2017, 16:25

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-22T14:56:10+01:00

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

Statistik: Verfasst von Ingmar — 22. Jan 2017, 14:56

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-22T14:08:48+01:00

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.

Statistik: Verfasst von dl7uae — 22. Jan 2017, 14:08

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-22T13:58:23+01:00

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

Statistik: Verfasst von dl7uae — 22. Jan 2017, 13:58

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-22T13:46:01+01:00

Quote:

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

Statistik: Verfasst von dl7uae — 22. Jan 2017, 13:46

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-22T13:41:37+01:00

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

Statistik: Verfasst von dl7uae — 22. Jan 2017, 13:41

Re: CVS16: OOB und OOIRD als Telemetriewerte

2017-01-22T12:48:25+01:00

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

Statistik: Verfasst von Ingmar — 22. Jan 2017, 12:48