1.Juli 2017: Neue Firmware 4.1. OOB erweitert auf bis zu 10% in 0,5% Schritten. Wie 4.0 zuvor, schreibt CVS von JLog erhaltene Parameter nicht mehr als neue Defaults in seinen Serial EEPROM. Das ist a) unnötig, weil JLog alle 100ms einen Parametersatz übermittelt, b) ist es gefährlich für den EEPROM Inhalt bei “Crazy Voltage” durch den BEC eines KOSMIK oder JIVE Pro.
———————
Überblick und Alarme
“CVS16″ heißt “Cell Voltage Sensor 16S”, Zellenspannungssensor, – er ist aber nicht einfach nur das, was man sich landläufig darunter vorstellt. CVS ist ein eigenständiger Analysator. Man gewinnt dadurch die Chance, tatsächlich rechtzeitig gewarnt zu werden, bevor eine Zelle, und damit der ganze Zellenverband (Pack), “plötzlich” den Geist aufgibt.
CVS misst hochauflösender wegen eines dedizierten 16bit ADC und viel häufiger durch einen eigenen ARM Prozessor.
Eigener Prozessor ==> eigene Software: Das Verhalten der Spannung jeder Zelle im Vergleich zum Zellenverband wird analysiert, – mindestens 33 mal pro Sekunde. Dabei geht es nicht nur um Out-of-Balance (OOB) sondern auch um die “Dynamik” jeder Zellenspannung: Out-of-Inner-Resistance-Dynamics (OOIRD): Eine “Weichei-Zelle” erkennen. Gerade aus OOIRD kommt das erfolgreiche “Hellsehen” von CVS. Oft “kippt” eine Zelle innerhalb von nur Sekunden oder Bruchteilen einer Sekunde. Sie wird “plötzlich” so hochohmig, dass die Spannung des Packs unter Last böse einbricht, – deutlich tiefer als um die Spannung dieser Zelle, weil die (ehemalige) Zelle zum “tödlichen” Serienwiderstand wird. Durch das statistische Beobachten des OOIRD kann CVS hinreichend früher erkennen, was bald passieren wird.
Andere Alarme sind nur “ein Goodie on Top” . CVS generiert selbst 3 Alarme:
UC Alarm (UnderCharge) beim Anstecken des Packs. Das geschieht anhand des Parameters TMV (Takeoff-Min-Voltage). Der Alarm, wenn ausgelöst, verschwindet, sobald JLog an CVS das erste Mal Motorstromfluß meldet.
OOB Alarm (Out-of-Balance). Dabei werden auch die Nummern von bis zu 4 Zellen von CVS an JLog übermittelt, die das Kriterium erfüllen. Basis ist der Parameter OOB in Prozent.
OOIRD Alarm (s.o.). Es werden auch die Nummern von bis zu 4 Zellen übermittelt, die OOIRD sind. Grundlage ist der Parameter OOIRD in Prozent.
Neben den bis zu 16 Zellen- oder Pin-Spannungen überträgt CVS auch folgende Werte an JLog:
LCV (Lowest Cell Voltage) und LCN (Nummer der Zelle mit LCV)
TPV (Total Pack Voltage)
MPV (Maximum Pin Voltage)
T (innere Temperatur des CVS)
…und natürlich die Alarme und Zellennummern (s.o.): UCA, OOBA, OOBN1..4, OOIRDA, OOIRDN1..4
JLog bildet zwei weitere Alarme, und zwar auf LCV und auf Ubat, wobei Ubat nicht mehr vom ESC stammt, sondern TPV ist (weil genauer). Insgesamt haben wir also 5 Alarmtypen, – die ALLE auf den Ubat Alarm mapped werden durch JLog.
Alles wird auch geloggt durch JLog, in zwei Records durch JLog2.x (Channel 2, 3), in einem durch JLog3 (Channel 4). Logging ist wichtig für spätere Forensik, wie es dem Pack erging während eines Fluges. Man wird eventuell auch bereits Zellen sehen, die das OOIRD von CVS erst später, aber rechtzeitig erkennen wird.
………..> Items>> rot: Alarme von CVS (via JLog), orange: Alarme von JLog auf CVS-Daten, blau: Daten von CVS, grün: Parameter von JLog an CVS. <………..
———————
Funktion
CVS befindet sich zunächst ständig im “Scan”. Er scannt seine Pins. Dann erkennt er selbst, ob ein Pack angeschlossen wurde, und wechselt in den “Pack Mode”. Egal, an welchem Pin eine Zelle landet, CVS sortiert sie in eine geschlossene Abfolge. Wichtig bleibt aber, dass die Balancerstecker eines Split-Packs in spannungsmäßig aufsteigender Reihenfolge an CVS angesteckt werden, beginnend bei “GND”! Tut man das nicht, kann ein Pack eventuell nicht erkannt werden, oder/und es kommen negative Spannungen zustande. CVS misst aber nur positive Spannungen, wodurch negative Werte wie gigantisch große positive erscheinen werden.
Findet der Scan kein Pack, ist CVS im “Pin Mode”. In diesem Mode (kein Pack angeschlossen/erkannt) ist CVS einfach ein 16-kanaliger Spannungssensor, je Pin 0..73,2V. (JLog: In JETI EX Displays ändert sich auch die Bezeichnung entsprechend.)
Ein weiterer Parameter beeinflusst die Pack-Erkennung durch CVS und beeinflusst dessen Analysen: CMV (Cell Maximum Voltage). Schließlich kann die Ladeschlußspannung eines LiPo’s heute auch 4,3 oder 4,35V betragen.
Befindet sich CVS im “Pack Mode” und JLog meldet CVS, dass Motorstrom fließt, dann verriegelt CVS sich im Pack Mode und scannt erst dann wieder für die Modus-Wahl, wenn kein Motorstromfluß mehr gemeldet wird durch JLog. Durch das Verriegeln kann CVS einen Mess-Durchgang noch beschleunigen, indem er einfach an allen Pins nicht mehr misst, an denen keine Zelle angeschlossen ist. Man sieht das an schnellerem Blinken der grünen LED von CVS. Am “langsamsten” ist CVS im Pack Mode somit mit einem 16S Pack, “nur” 33 Analysen pro Sekunde.
———————
Data Interface
Interface zwischen CVS und JLog ist I²C. An JLog3 und JLog2.6 ist dies der “Data Bus” (JLog3(S32): Port 7), an JLog2.5 und 2 wird CVS offiziell nicht unterstützt, weil es keinen “Data Bus” gibt. Die Firmwares von JLog2.5 und JLog2 (und JLC) unterstützen es aber trotzdem, dem Anwender gedeiht nur ein initialer Löt-Job für das Anschlußkabel. – Außerdem ist CVS an JLog2 und 2.5 nicht verwendbar, wenn die Telemetrie selbst I²C braucht (SPEKTRUM TM1000/ARnnnnT, HiTec).
Alle 100ms kontaktiert JLog als Busmaster den CVS. JLog übermittelt ihm zunächst die mit JLC bzw. S32terminal eingestellten Parameter, CMV, TMV, OOB%, OOIRD% und, ob Motorstrom fließt, – dann sendet CVS einen Datensatz von ca. 100 Bytes (Alarme: UCA, OOBA/OOBN1..4, OOIRDA/OOIRDN1..4; Zellen- bzw. Pin-Spannungen; LCV, LCN, TPV, MPV, Temperatur) und, ob er im “Pack Mode” ist..
CVS startete mit Default Parametern, bevor ihm JLog den ersten Parametersatz sendete. In der alternativen CVS Firmware, die diesen zu einem reinen SPEKTRUM Sensor macht (ohne JLog dazwischen), speichert CVS auch immer die erhaltenen Parameter, wenn sie vom Default abweichen. Damit kann man die Default Parameter an einem JLog ändern, um CVS sodann standalone an einem TM1000 oder Empfänger mit X-Bus (ARnnnnT) zu verwenden, – mit zuvor geänderten Parametern.
Mit JLog3(S32) kam der BID Chip wieder als “Perso” eines Packs. JLog verwendet einen eigenen Bereich auf dem BID für seine Daten. Er kann aber auch die Daten des Chargers auf dem BID einbeziehen, ohne diese zu beeinflussen. (Im Gegenteil, S32 kann die Datenkonsistenz eines BID reparieren.) Da ein “PowerPeak” keinen Time Stamp schreibt beim Laden (hat keine RTC, – Echtzeituhr), S32 aber eine RTC hat, kann S32 anhand vor allem seines Datensatzes mit ziemlicher Sicherheit feststellen, ob man versehentlich mit einem nicht geladenen Pack starten will. — Die Daten auf dem BID dienen außerdem dem automatischen Einstellen von Alarmschwellen, zumindest für Ubat und mAh. — Optional können aber auch die Parameter für CVS auf dem BID gehalten werden, also individuell pro Pack, sobald ein BID gefunden wird durch S32, und dieser CVS-Parameter enthält. Ist das nicht der Fall, nimmt S32 die in seinem Setup gespeicherten Parameter für CVS. ==> Achtung! Momentan können BID und CVS NICHT gleichzeitig auf dem “Data Bus” verwendet werden. Grund ist, dass CVS für seine Datenspeicherung denselben “Serial EEPROM” (I²C) verwendet, der in einem BID (oder der Alternative von uns (R2)) enthalten ist. CVS muss einen EEPROM mit anderer Bus-Adresse oder ein alternatives Speichermedium erhalten, bevor das machbar ist. Beachtet man das nicht, werden die Kalibrierungsdaten von CVS zerstört, und er muss nach Hause zum Rekalibrieren!
———————
CVS Hardware
Basis ist ein schneller 16Bit A/D-Wandler, ein 32Bit Microcontroller angemessener Leistungsklasse (ARM Cortex-M3), zusätzlicher nichtflüchtiger Datenspeicher, Elektronik zur galvanischen Isolation, USB 2.0 Interface und diverse Spannungsstabilisatoren. Das Gerät ist selbstkalibrierend, die Kalibrierungsprozedur wird beim Hersteller nach Fertigung und Tests einmal getriggert, wobei eine hochgenaue Referenzspannungsquelle von 65,0000V an alle Pins von CVS angeschlossen wird. Das Gerät verfügt über eine 2-stufige, in thermischen Zonen gestaffelte Temperaturkompensation, um verlässliche Messungen zu ermöglichen. Vier LEDs, grün, orange, rot und blau, visualisieren Status- und Alarminformationen.
Es werden nur 15 der 16 Bits Auflösung des ADC verwendet, das 16. Bit ist der Fähigkeit des ADC geschuldet, dass dieser auch negative Spannungen messen kann. Die Meßauflösung beträgt somit 2,3mV bei max. ca. 73,2V pro Pin. Hohe Auflösung und Genauigkeit wird für die Online Analyse benötigt. In der Datenübertragung an JLog beträgt die Auflösung 5mV für Zellenspannungen und 10mV für Pin-Spannungen (“Pin Mode”). (Mittels einer speziellen CVS-Firmware für Testzwecke kann auch mit 1mV Auflösung übertragen werden.)
Anschlüsse der R/C Seite: 2x Datenbus, Micro-USB für CVS-Firmwareupdates.
Neben den Eingangspins zur Spannungsmessung hat CVS nur ein Interface, einen Busanschluss in Form einer 4-poligen Buchse, I²C *). Diese Buchse gibt es zweimal, beide sind parallel geschaltet. Dadurch können mehrere Geräte desselben Bus-Typs in Form einer “Daisy Chain” hintereinander gesteckt werden, z.B. CVS16 und HV²BEC. Welche Buchse man zum Anschluss welches Gerätes verwendet, ist egal. Auch die Betriebsspannungsversorgung von CVS16 erfolgt über den Busanschluss, und zwar nominal durch JLog. Es handelt sich dabei um die R/C-Rohspannung, 1:1, aber entkoppelt, durchgeschleift von allen Betriebsspannungseingängen von JLog, egal, ob “HV” oder nicht.
Momentan wird das Anschließen von nur jeweils einem CVS16 je JLog unterstützt.
Außerdem verfügt CVS16 noch über eine USB 2.0 Buchse vom Typ Micro-B. Diese Buchse spielt im Setup und im operativen Betrieb des Gerätes keine Rolle. Sie wird lediglich zum Softwareupdate des CVS benötigt, wobei dabei auch die Stromversorgung des CVS via USB geschieht.
*) Diesen Bustyp haben bereits JLog2 und JLog2.5, - den Busanschluss haben aber nur JLog2.6, JLog3(S32), a) als exklusives JLog-Interface, unabhängig von allen anderen Anwendungen, b) mit diesem Steckertyp und c) mit dieser Belegung, wobei auch Betriebsspannung aufgelegt ist. Umgekehrt formuliert: JLog2.6 hat den Bustyp (TWI) im Vergleich zu JLog2.5 und 2 zweimal als Interface (JLog3 hat noch mehr solche Interfaces).
JLog2.x: Offiziell unterstützt ist CVS16 nur an JLog2.6 und 3, die Firmwares von JLo2 und 2.5 unterstützen aber CVS ebenso. JLog2.5, 2 haben keinen Anschluss “Data Bus”, müssten “OPT” (JLog.5) bzw. “Sensor/Alarm” (JLog2) dafür nutzen. Das ist gewissermaßen “Databus1“, auch JLog2.6 hat ihn, während allein JLog2.6 einen vollständig unabhängigen weiteren “Databus2” hat:
SPEKTRUM und HiTec Telemetrie als Primärnutzer von “OPT” bzw. “Sensor/Alarm” und JLog-eigene Sensoren als Sekundärnutzer konkurrieren mit HV²BEC und CVS16 um den Port bei JLog2.5, 2. Sie schließen sich gegenseitig aus.
Der Anwender müsste das notwendige Kabel selbst herstellen. Da “OPT” nur 3 Pins hat, Masse und 2x Signalpin, müsste er auch dafür sorgen, dass CVS16 seine Betriebsspannung via die vierte Leitung des “Databus(2)” bekommt.
JLog2 benötigt, wie auch für den Anschluss an SPEKTRUM oder HiTec Telemetrie, zwei externe Pullups, Widerstände von je 1..10kOhm gegen +3,3V, an den beiden Signalpins von “OPT”. Das geschieht auf einem vom Anwender gewählten Wege oder durch Verwenden von JSend.
JLog3(S32) bringt keine der o.g. Einschränkungen ein! Er hat etliche I²C, sodass alle diesbezüglichen Anwendungen komplett unabhängig voneinander sind.
———————
Daten und Strom “durch die Luft”
Ein wesentliches Merkmal ist die galvanische Isolation. Der HV-Teil mit den Pins zur Spannungsmessung ist vollständig galvanisch isoliert von der restlichen elektrischen R/C-Welt des Modells, also von den Bus-Anschlüssen des CVS. Somit besteht in einem fiktiven Ernstfall nicht die Gefahr, dass hohe Spannungen von den Probanden (Cell Packs oder zu messende Einzelspannungen) auf der elektrischen R/C-Seite erscheinen können, was immensen Schaden bis hin zu Brand verursachen könnte. Um das zu erreichen, ist einfach alles voneinander galvanisch isoliert, auch Masse und die Betriebsspannungsversorgung des CVS. Dessen Strom fließt hier sozusagen durch die Luft. Praktisch erfolgt das mittels entsprechender Chips durch Energie- und Signalübertragung per hochfrequenter Minifelder. Die Isolation ist bis 4kV durchschlagsfest, – das sollte evtl. noch ein bis zwei Jahre reichen für im Modellbau übliche Antriebsspannungen.
Entsprechend separiert das Layout der Platine von CVS16 zwei galvanisch getrennte Zonen. Dabei müssen natürlich auch durchschlagsfeste Abstände eingehalten werden. Auch die Chips der elektronischen Isolation haben adäquat große Pinabstände. Trotzdem werden die Abmessungen des CVS nur von den üblichen 2.54mm Pinabständen der Balancerstecker diktiert. Pins statt spezieller Buchsen werden verwendet, um universell sein zu können im Hinblick auf die verschiedenen Typen Balancerstecker an den Packs. Da Falschanstecken mit CVS16 keinerlei Möglichkeit für Kurzschluss involviert, sind offen liegend verbleibende Pins hier auch kein Problem:
Die Eingangspins stehen in keinerlei galvanisch nennenswerten Beziehung zueinander. Sie haben überhaupt keine galvanische Beziehung zu den Busanschlüssen des Gerätes.
Auch der Masse-Pin “1==GND” hat nichts mit der elektronischen Masse bus-seitig zu tun.
Pin 10 ist keine Masse, er hängt einfach nur in der Luft. Die Konfiguration mit 2x 9 Pins ermöglicht, auch volle 16S anschliessen zu können, wenn der Pack aus 2x 8S besteht. Der Low End Anschluss eines Balancersteckers benötigt ja an einem herkömmlichen Sensor immer einen Pin zur galvanischen Verbindung, – hier nicht. Er blockiert aber rein mechanisch einen Eingangspin, wenn er nicht auf Pin 10 landet oder es sich um den Low Side Stecker handelt.
Daher: Die Balancerstecker können in beliebiger Position an CVS16 gesteckt werden. Dabei ist zwar die Orientierung einzuhalten, tut man es aber versehentlich nicht, kommt es zu keinerlei Schaden. CVS16 kann dadurch nicht beschädigt werden. In keiner Konstellation des Ansteckens kann man einen Kurzschluss provozieren.
Die Balancerstecker können also mit “Lücken” dazwischen angesteckt werden. CVS16 erkennt selbst, ob Packs angeschlossen sind, geht entsprechend in seinen “Pack Mode” mit den Funktionen für Health Check von Zellen, – doch zuvor identifiziert er die Zellen, sequentialisiert sie so, als hätte man die Stecker in geschlossener Reihe angesteckt. Die Daten der Zellen werden in dieser Abfolge auch an JLog gemeldet, erscheinen so im Log, sowie auch die Zellenummern in der Telemetrie (“LCN”). – Mit CVS ist es daher Geschichte, dass man die Balancerstecker galvanisch in dieselbe Reihenschaltung bringen muss, die die Lastanschlüsse der Packs haben. Das schafft nur mechanische NoGo’s beim Anschluss und Verpolungsrisiken.
Das heisst dann auch: Abgebrannte Balancerkabel durch versehentliche Querverbindung, adé. Das überlassen wir noch den Chargern.
Um all das zu ermöglichen, wurde auch auf das sonst übliche Verfahren verzichtet, den Sensor aus Pin2 (->2S) des Probanden mit Spannung zu versorgen. Außerdem ermöglicht das, auf ALLEN Pins hochohmig erscheinen zu können, was für das Messen von Einzelspannungen mit CVS16 von Interesse sein könnte.
Sie benötigen einen anderen Device Definition File für LogView als der für einen Standard JLog. Die entsprechenden .lov Dateien finden sich im Download, z.B. JLog26CVS.lov oder JLog26CC-CVS.lov, wenn der ESC ein Castle ICE/Edge ist, – beide für km/h, Celsius, – und diese für mph, Fahrenheit: JLog26CVS-Fahrenheit-mph.lov, JLog26CC-CVS-Fahrenheit.lov. (Wer trotzdem einen JLog2.5 oder 2 an CVS betreibt, verwendet eine “konsolidierte Firmware”, und kann daher auch obige .lov benutzen.)
Das Logformat hat 3 Kanäle statt sonst einem, Kanal 2 und 3 sind für CVS.
JLog3(S32)
S32′s Device Definition File enthält bereits alles. S32 loggt alle CVS Daten in Channel 4.
———————
Stromversorgung
Die meisten Cell Voltage Sensoren haben eine vom Probanden unabhängige Betriebsspannungsversorgung. Lediglich einfache LiPo Checker versorgen sich aus der Reihenschaltung der ersten beiden Zellen des Probanden. CVS ist nicht nur einfach ein “Sensor”, enthält daher mehr Elektronik, u.a. einen 32Bit Microcontroller und Komponenten zur drahtlosen Energieversorgung (vollständige galvanische Entkopplung). Sein Strombedarf ist entsprechend höher, im Mittel ca. 80mA.
Während JLog3(S32) seine Betriebsspannung grundsätzlich nur von einem seiner Ports für Telemetrie bezieht, tun das JLog2.x von einem angeschlossenen ESC. Das ist dann meist dessen BEC-Ausgangsspannung auf diesem Port. Alter JIVE: Alle JLog2.x beziehen die Betriebsspannung vom Daten-(Jumper)Anschluss des JIVE. JLog 2.5 und 2.6 beziehen deren Betriebsspannung vom Datenanschluss zu einem KOSMIK oder JIVE Pro. Kontronik liefert hier auch die BEC-Spannung, beim KOSMIK 5V aus einem Spannungsregler. Kontronik hat aber gründsätzlich einen Kaltleiter in der Plus- und (leider auch) Minus-Leitung, der für max. 100mA dimensioniert ist. — S32 verwendet, wie gesagt, diese Spannung nicht:
Es könnte somit passieren, dass ein CVS via und plus JLog, der nur aus dem Diag(Jumper) Port eines non-Pro JIVE oder dem Option Port eines KOSMIK oder JIVE Pro versorgt wird, betriebsbedingt in Unterspannungssituationen gerät, was vor allem die SD, genauer, das Dateisystem auf ihr, übel nehmen könnte.
Daher ist vom Grundsatz her anzuraten, JLog2.x, und damit CVS, parallel via einen der jeweils 2 verbleibenden Alternativeingänge mit Betriebsspannung zu versorgen, – siehe unten und auch hier.
———————
CVS und “Crazy Voltage” von KOSMIK, JIVEpro
Die BEC-Spannung eines solchen ESC kann aufgrund eines Design Flaws insbesondere in der Startup-Phase verrückt spielen. Exemplar- und lastabhängig könnte es sogar zu einem dauerhaften Schwingen in Form eines Sägezahns kommen, vom Anwender meist nicht bemerkt, höchstens als “zu geringe Ausgangsspannung”, integriert mit einem Multimeter gemessen. Wenn jetzt CVS auf seinen EEPROM schreibt, was er seit Version 4.0 nicht mehr tut (aber mit der Standalone-Firmware für CVS als SPEKTRUM Sensor wieder ab Version 4.1), dann kann der Inhalt des EEPROM zerstört werden, und damit CVS’s Kalibrierungsdaten! Es könnte sogar passieren, wenn nur gelesen wird vom EEPROM via I²C (demselben wie “Data Bus”), – multible, schnell durchlaufene Unterspannungssituationen können einfach jedes “Irrenhaus” bewirken. Auch CVS an der von einem JLog3(S32) durchgeleiteten RC Spannung kann es betreffen, wenn S32 aus Ubec dieses Typs ESC versorgt wird.
Man sollte daher grundsätzlich für einen “Helfer” sorgen. Das kann ein Optipower UltraGuard sein oder ein BEC Guard. Der UG agiert in den ersten 5 Sekunden wie eine Stützbatterie. Der BG hat eine Nebenfunktion, die den BEC in den besonders kritischen ersten 10ms lastfrei bleiben lässt nach Powerup.
Bezüglich eines R2 Buffers mit SuperCaps ist zu beachten: Der Puffer könnte das Wirken des Design Flaws direkt provozieren ohne BEC Guard zwischen ihm und dem BEC. Grund: 1) Er “belastet” etwas bereits kurz nach dem Powerup, nämlich durch den eingestellten Ladestrom (Bereits 300mA können so einem BEC zu viel sein in den ersten 10ms des Startup des ESC!), – 2) Bei Unterspannung ist dessen Elektronik ebenso tangiert. Niemand kann garantieren, dass die Ladestrombegrenzung noch funktioniert in dieser Situation. — Daher erscheint nun bald (geschrieben 4.Juli 2017) Bufferv4 in den Shops. Dieser hat einen ARM Microcontroller (wie auch der UltraGuard), der den Puffer verzögert und adaptiv anhand der BEC-Spannung seinen Ladestrom einstellen lässt. Mit V4 stellt der R2Buffer dann gar keinen Lastfaktor mehr dar in der “Weichei-Phase” des BEC.
.
———————
CVS an JLog 2, 2.5: Eigenbaukabel
JLog2.6/JLog3 Dataport und Kabel JLog2.6/JLog3–CVS16:
.
X-Bus-Buchse an JLog2.5, “OPT” an JLog2:
(JLog2 hat nicht die benötigten zwei Pullup-Widerstände an SDA, SCL (gegen +3V3). Will man nicht basteln, nimmt man einen JSend.)
