Auf allgemeinen Wunsch wurde mit der Version 2.7 der JLog-Firmware eine Alarmfunktion hinzugefügt. Da die JLog-Platine keine anderen Anschlüsse als “Rx” (serieller Empfang des JIVE-Datenstroms) und “Tx” hat (serieller Output für den OpenFormat-Livestream: Daten live mit LogView anschauen, Input via USB-Interface “JUI”), – wird “Tx” hier als Generalalarmausgang verwendet, und zwar als low-aktiver Schaltausgang, TTL-Pegel (ungefähr max. +2V).
Es können 4 logische Alarme konfiguriert werden:
CapaMax……………Alarm, wenn eingestellte verbrauchte Akkukapazität (mAh) erreicht ist.
UbatMin…………….Alarm, wenn die eingestellte Akkuspannung unterschritten wird. Die Auslösung erfolgt verzögert, weil die Spannung nach einem Software-Integrator (Tiefpass, Verzögerungsglied) gemessen wird.
tempPA……………..Alarm, wenn die eingestellte Temperatur der Endstufen erreicht ist. Dazu ist zu beachten, dass der JIVE mit
Erreichen von 101°C innerhalb ca. 15s voll abregelt.
UbecDip…………….Alarm zum Signalisieren eines BEC-Ausfalls, inbesondere bei Verwendung von Stützspannungsmaßnahmen., Akku oder Green Caps.
Auslösung erfolgt, wenn die BEC-Spannung in mehr als 4 aufeinander folgenden Messungen einen negativen Dip von >0,5V gegenüber der eingestellten Nominalspannung zeigt.
Die Theorie sagt, dass es alsbald zu so einem Dip kommen wird, wenn die R/C-Spannung nach Ausfall des BECs nur noch aus der Stützspannungsquelle kommt. Zweck ist, so frühzeitig wie möglich zu erkennen, dass man auf “Notstrombetrieb” ist, bevor das Modell mit leerer Stützspannungsquelle herunter fällt.
Die 4 logischen Alarme sind ver-odert bzgl. des Generalarms im Ausgang. Bis auf “CapaAlarm” können sich alle Alarme selbst wieder zurücksetzen, wenn die Auslösungsbedingung wieder verschwand. Der Generalalarm hält sich aber mindestens 3 Sekunden. Ist der JIVE noch nicht initialisiert (Peepshow mit dem Motor), weil er noch keinen gültigen Null-Gasimpuls sah, gibt es keine Zeitbasis (Uhr) für JLog. Daher kann der Alarm mit nicht initialisiertem JIVE ohne die 3-Sekunden-Verzögerung gelöscht werden.
Bevor der JIVE nicht initialisiert hat, gibt es keine Alarme “UbatAlarm” und “UbecDipAlarm”, auch “CapaAlarm” wird nicht auslösen können, weil das Berechnen der verbrauchten mAh die Timestamps des JIVE braucht.
Alle Alarme gelten als deaktiviert, wenn die Werte der Limits “CapaMax”, “UbatMin” und “tempPA” per Konfigurator auf Null gesetzt wurden und “UbecDip” in der Konfiguration ausgeschaltet worden ist.
Ab JLog 2.7 muss der JLog-Konfigurator JLC-II verwendet werden, Ausnahme ist die “S”-Version)!
“Tx” des JLog ist ein low-aktiver Schaltausgang, solange einer der obigen Alarme eingeschaltet ist, er wird wieder zum seriellen Ausgang (für den OpenFormat-Livestream), wenn alle Alarme ausgeschaltet sind.
Hier zwei Beispielschaltungen für Alarmgeber, einmal mit einem 120dB-Piezopiepheini, einmal via 433MHz-LPD-Sender, frecherweise in meinem 70cm-Amateurfunkband!:) Der Alarmgeber muss so ausgelegt sein, dass er auch dann alarmiert, wenn sein low-aktiver Eingang offen ist, um auch einen ausgefallenen JIVE/JLog oder eine unterbrochene Alarmleitung signalisieren zu können!
Hier mein Alarmmonitor als Zwischenstecker zwischen JLog und JUI, wie ich ihn während der Entwicklung benutzte.
Die Spannungsversorgung des Alarmgebers sollte NICHT aus dem JLog und damit dem Jumper-Anschluss des JIVE erfolgen! Sicherlich, hier werden ca. 5V bei bis zu 100mA geliefert, abgesichert durch einen PTC-Widerstand im Inneren des JIVE. Aber: Fällt die BEC-Spannung aus, ist auch die Versorgungsspannung des JLog weg! Ergo haben wir entweder eine gepufferte R/C-Spannung, mit Stützakku oder Green Caps, oder wir verwenden für den Alarmgeber eine eigene Spannungsquelle. Nicht vergessen! Es wäre doch ein bisschen Männerulk, den Ausfall einer Spannung unter Verwendung dieser Spannung signalisieren zu wollen, oder? 
Bitte auch beachten, dass ohne Sperrdiode zwischen BEC-Ausgang und Stützspannungsquelle (Anode am BEC) oder andere Entkopplungsmaßnahmen die Stützspannung via BEC in den JIVE eingespeist wird. Die Dip-Erkennung sollte hier trotzdem den Übergang auf “Notstrom” signalisieren können. Allerdings bekommen auch die beiden Prozessoren via die interne Versorgungsspannungserzeugung dabei weiterhin Saft, der JIVE kommutiert weiter. Offenbar sehen auch die Driver und sogar die Endstufen diese Spannung, mit abgeklemmtem oder totem Antriebsakku ist beobachtet worden, wie der JIVE damit den Motor weiterhin kommutierte – und natürlich die Stützspgs.quelle in Nullkommanix leer saugte. Entkoppelt man BEC-Ausgang und Stütze nicht voneinander, ist es eigentlich erforderlich, dafür zu sorgen, dass das Kommutieren eingestellt wird, also durch Kappen des Gasimpulses oder dessen Reduzieren auf eine Länge für “Null”. Dazu muss man aber trotz parallel geschalteter Spannungsquellen, BEC und Stütze, erkennen können, wenn der BEC ausfiel. Das geht eigentlich nur via diesen zu erwartenden Spannungsdip, den JLog2.7 melden kann. Sprich, die hohe Schule wäre, mit dem Alarmsignal in der Auswertung am Boden (oder im Modell) eine Gasreduktion zu bewirken. Allerdings sollten dann hier nicht die weiteren 3 logischen Alarme freigeschaltet sein. (Mir wäre es ja am liebsten gewesen, alle 4 Alarme einzeln in einem seriellen Datenstrom zu melden, nur hätte das eine größere Hürde für die “Alarmbastler” geschaffen. – Evtl. kann man ja diesen Alarmsender CX-12T anzapfen und in den Modulatoreingang seines HF-Moduls direkt das passende serielle Protokoll geben. Sender CX-12T und Empfänger CX-12R kommunizieren ja auch seriell miteinander. Am Empfänger hätte man dann für die 4 Alarme die 4 Schaltausgänge zur Verfügung.)
Anbei auf Wunsch zwei Beispiele, ein LED-Blitzer und ein Piezo-Buzzer mit 1Hz on/off.
Hinweise dazu:
Der Blitzer nimmt mehrere superhelle LEDs. Die LEDs werden mit impulsartigem Überstrom nur geblitzt, heißt, die bekommen voll ein’s vor den Latz, überleben das aber, belief me. Dieser bifilare Ringkern muss nicht sein, empfiehlt sich aber bei 35MHz-FS, dann auch unbedingt eine von der R/C-Spannung getrennte Stromversorgung benutzen.
Dieser Piezo-Buzzer (gibt’s auch magnetisch in der gleichen Lautstärke), schwingt zw. 1kHz und 2,6KHz, meist so um die 2kHz rum, wird mit rund 5V und in einer akzeptablen Größe kaum 120dB machen, eher so 85..90, wenn man Glück hat, 100..105dB. Die Dinger gibt’s an jeder Ecke, z.B. auch bei Digikey. Einfach mal Google bemühen und auf die nominale Betriebsspannung achten.
Beide Schaltungen verhalten sich bzgl. des Alarmeinganges identisch:
- High am Eingang (ca. +2V vom Logger): Alarm OFF
- Low am Eingang: Alarm ON
- Eingang floating (offen): Alarm ON
Bitte beachten, dass zur 2.7 der passende INI-File für Logview verwendet wird, bzw. man lässt LogView via JLog2.7_example.lov das neue Gerät lernen.
Die 2.7 hat außerdem eine “Anti-Glitch-Funktion” gegen Mondwerte, die der JIVE in der ersten Sekunde nach seiner Initialisierung gelegentlich liefert. Das empfängt dann JLog i.Allg. nur, wenn LogStop ausgeschaltet ist. Es betrifft die Messwerte “U-BAT”, “U-BEC” und “I-BEC”. JLog dekodiert durchaus weiterhin alle relevanten Messwerte auch vor Initialisieren des JIVE und schickt sie in den OpenFormat-Livestream. Auf der SD-Karte geloggt wird eh nicht, solange die Timestamps des uninitialisierten JIVE auf Null stehen. JLog erkennt nun die Initialisierungsphase des JIVE und stanzt in das Logging für die ersten 2 Sekunden ein “Loch” für die o.g. Werte, setzt diese auf Null. So wird verhindert, dass die automatische Wertebereichswahl von Logview durch anfängliche Mondwerte reagieren könnte.
Zusätzlich ist jetzt die Darstellung auf der Zeitachse von LV berichtigt worden, in den Vorversionen startete ein mit LogStop aufgezeichnetes Log bei 0, wenn die Aufzeichnung wegen des LogStop erst bei z.B. 44 Sekunden JIVE-Zeit begann.
Tom
