speziallogger für den jive

[Gast_28792]

Bemerkt hatte ich bei der Installation der Vorgängerversion, dass es sehr lange dauerte und auch mit einer komischen Zwischenmeldung ( weiß nicht mehr was es war ) dann doch zum Laufen kam. Bei der neuesten Version ist die Installation innerhalb kürzester Zeit durch und nun läßt sich die Config.txt einwandfrei auslesen.

Das war aber was anderes. Wenn man auf seiner Kiste noch kein .NET hat, dann wird dieses relativ monströse Paket (>20MB) erstmal gezogen (Inet) und installiert. Ist es bereits da, wird nur die Applikation installiert, und die ist natürlich nicht gerade megagroß.

Tom

[Banjoko]

Das war aber was anderes. Wenn man auf seiner Kiste noch kein .NET hat, dann wird dieses relativ monströse Paket (>20MB) erstmal gezogen (Inet) und installiert. Ist es bereits da, wird nur die Applikation installiert, und die ist natürlich nicht gerade megagroß.

Tom

... danke für Deine Geduld, Tom - das habe ich verstanden !

Wenn`s Wetter hier hält in DK werde ich morgen die ersten Flüge mit dem JLog im Rex 500 machen - bin ganz fasziniert von dem Teil !

[Gast_28792]

In DK?! In Urlaub?

Noch was: Diese 10,10 für Ritzel,HZR, wo ich Dich "verdächtigte", Du hättest editiert: Das macht der Logger. Er sieht Ratiotype 2 (direktes Ratio in JLC benutzt), und schreibt 10,10 als "Notwert" da rein, weil unbenutzt und nicht mit dem Ratio in JLC korrelierend.

Habe eben noch ein bisschen getestet: Was ich nicht mache, ich überprüfe nicht in JLC, ob die Untersetzung nicht eine Übersetzung ist, also Zähneanzahl Ritzel größer als die vom HZR. Im Ergebnis erscheint im Ratio 1:xxx Müll, der Logger würde RPMuni falsch errechnen.

Sollte ich vielleicht noch mal nachlegen, dass ÜBERsetzung nicht toleriert wird in JLC.

Diese Ratio-Geschichte auf 3 Wegen, etwas "online" hier im Thread entstanden, hat mich offenbar "überrollt", ich habe nicht alle denkbaren Kombinationen durchgespielt. OK, Obiges ist eigentlich Schmuck am Nachthemd, trotzdem kriege ich Augenkrebs, wenn ich bei Ritzel>HZR das falsch errechnete Ratio im JLC sehe. Bin da Krümelkacker..

Tom

[Gast_28792]

Bei der Gelegenheit noch mal und als Übung für die FAQ auf der Website:

******************************************************************
Messgenauigkeit JIVE/JLog:

Ich betrachte einen Logger nicht als “Messgerät”, in diesem Vergleichsraum also auch ein günstiges Multimeter nicht. Weiterhin hat ein Logger mit eigener Sensorik (Unilog z.B.) eine bessere Plattform: Er kann sich eine eigene Zeitbasis der Abtastung definieren. Er bestimmt selbst die Messgenauigkeit, über den Shunt (z.B.), Entkopplung/Entstörung zwischen Shunt und A/D-Wandler, über die Referenzspannungsquelle, über die Auflösung des A/D-Wandlers, der in der verwendeten MCU enthalten ist, ganz allgemein über die Toleranzanforderungen am Messwert beteiligter Bauelemente.

Sonderfall ist der Motorstrom, beim Unilog eben der Gesamtstrom, hier hat man als Unilog den Vorteil, dass man auf der integrativen Seite sitzt, den Steller nebst Motor als einfache Last betrachten kann.

Der JIVE ist weder als Messgerät noch als Logger konzipiert. Seine Sensorik für Strom und Spannung dient vornehmlich der Feststellung des Überschreitens von Maximalwerten.

So scheint die (Singular oder Plural?) Referenzspannungsquelle(n) etwas zu streuen von Exemplar zu Exemplar des JIVE. Das beeinflusst jede Messung mit A/D-Wandler, Spannung UND Strom. Da man das nur bzgl. Spannungsmessungen verlässlich feststellen kann, könnte es aber auch sein, dass es nicht die Referenzspannung ist, sondern nur der Spannungsteiler der U-Messung. Das ist wahrscheinlicher, und ergo für die Strommessung positiver (optimistischer).

Die Strommessungen per Shunts beruhen auf Leiterbahnen, die Dicke so einer Leiterbahn (Dicke der Kupferschicht der Platine) kann von Charge zu Charge etwas schwanken.

Im Ergebnis gibt es eine gewisse, im Rahmen der Anwendung aber tolerierbare Streuung zw. den JIVE-Exemplaren. Ich habe einfach versucht, einen Durchschnitt zu bilden bei fixen Korrekturen, die ich im Logger vornehme, siehe Manual.

Beim BEC-Strom war ich so vermessen, einfach 0,4A zu addieren, wenn dieser über 0 geht. "0" heisst, real sind es mindestens 100..200mA plus/minus Shunt- und Referenzstreuung (Auflösung, 1 Digit, ist 100mA seitens des JIVE). Daher ist der Messwert I-BEC bei kleinen Strömen als "Messung" nicht brauchbar. Man sieht, wie I-BEC digital mit einer Amplitude von 0,4A rauscht, der Korrekturwert. Ergo ist alles bis 1..3A, aufsteigend abnehmend, besonders fehlerbehaftet.

Zu den Spannungen ist nichts weiter zu sagen, siehe Chapter im Manual. U-BAT macht natürlich einen kleinen Unterschied zur U-Messung mit einem "echten" Logger außerhalb, es ist die Spannung hinter allen Übergangswiderständen (immerhin bei teilweise brutalen Strömen) im Steller.

"Abtastung": Der JIVE sendet Datenpakete, die nicht zeitlich äquidistant kommen. Einige Messwerte, aber nicht die für die Genauigkeit im heißen Betrieb benötigten, erfahren nicht mit jedem Datagramm ein Update, denn sie werden aus virtuellen Datenpaketen gewonnen, aus Datenarrays, die aus bestimmten Werten der Live-Pakete gespeist werden. Da wir nicht wissen, wann der JIVE etwas maß, sind wir auf dessen Information darüber angewiesen. Jedes Datenpaket enthält einen Timestamp, also eine fremde Zeitbasis, die der Logger verwendet, und mit der er letztendlich auch LogView füttert. Die Zeitstempel kommen i.Allg. in 100ms-Schritten, also 10 Messwerte pro Sekunde. Da der JIVE ab und zu "Duplicates" sendet, aber nur maximal eines zwischen zwei 100ms-Ticks, also unterschiedliche Messwerte mit demselben Zeitstempel, fügt der Logger dann einen 50ms-Zwischenschritt ein, sodass LogView das unterscheiden kann.

I-Motor schiesst nun den Vogel ab. Dieser Messwert ist das reine Ergebnis eines Data Processing, das, abhängig von Motor-PWM, Gas, Polzahl (nur im untersten Quadranten, nur 2-Poler vs. n-Poler) und aktueller Höhe der Strommessung des JIVE, auf das angewendet wird, was der JIVE ausspuckt. Und das sieht, wie gesagt, zunächst im Rohwert aus wie die Lottozahlen, obwohl durchaus herleitbar. Tastverhältnis und Frequenz der PWM, Sample Time des A/D-Wandlers und Blindanteile der Ströme (Wicklung ist induktive Last) geben sich ein Stelldichein. Die Datenbearbeitung erfolgt in 7 Quadranten des Stromes, überlappend, die sich im Wesentlichen vom aktuellen Wert von Motor-PWM ableiten. Siehe dazu das Chapter im Manual und auch die Bildchen bzgl. der Ergebnisse.

Untenherum, also so im Bereich von 3..4A, eher noch etwas höher, hat das Data Processing aber kaum eine Chance, der Einfluss des geringen Tastverhältnisses der Motor-PWM ist zu stark und unberechenbar. Das kann man besonders bemerken, wenn man in einem reinen Stellermode (ohne Drehzahlregelung) und mit relativ geringen Motorströmen hantiert, explizit im Leerlauf eines Motors. Unterhalb eines Minimalwertes setzt die Strombehandlung daher auch gewollt aus, liefert Null, während übrigens der Rohstrom (Messwert vom JIVE) meist in utopische Höhen geht. Mit DZR setzt PWM i.Allg. erst bei ca. 50% ein (Motor läuft an), der teilweise unzuverlässige Bereich unten wird gar nicht tangiert.

Im Ergebnis heißt das, dass die Bandbreite verlässlicher Strommessung einer gewissen Limitierung unterliegt, und zwar nur untenherum.

Obenrum, und nur bei hohen Stromanstiegsgeschwindigkeiten, wirken die Rubycons (Low-ESR-Elkos), die aus Sicht des Stellers den Innenwiderstand der Spannungsquelle (Akku) dramatisch verringern. Infolge dessen reichen die Peaks bis zu 15% im Log höher, als sie z.B. ein Unilog draußen zeigen würde, dessen Stromsensor nur den Strom durch den Akku sieht, während drinnen auch "Saft aus den Elkos" kommt. In Wirklichkeit werden diese Peaks noch viel höher reichen, könnte man aber nur mit einem Speicheroszi sehen, das sind die wahren potentiellen Killer der FETs.

Wir (Sebastian und ich) haben die Richtigkeit der Motorstrombehandlung dadurch verifiziert, dass wir eine Gasrampe (0..100%) im Stellermode durchfuhren, Motor an einer Wirbelstrombremse, also belastet, und parallel mit Unilog außen gemessen haben. Die beiden Messungen wurden jeweils anhand der Drehzahl übereinander gebracht. Später wurde dann an einem "geeichten" Messplatz bei K verifiziert, die Ergebnisse bestätigten im Wesentlichen. Falls sich einer an "im Wesentlichen" stößt: Es gab dabei ein gewisses Hindernis hinsichtlich der Vergleichbarkeit, weil K's Messplatz seitens des Messpunktes für die Spannung anders ausgelegt war.

So, ich hoffe, ich konnte das verständlich rüberbringen, habe manchmal so meine Probleme damit... Zusammengefasst: Schmeißt Euer Unimeter NICHT weg!
******************************************************************

.....Ganz schön viel für die FAQ-Seite..(??)

[Banjoko]

... einfach nur !


P.S.: Ist jeder Steller so aufwändig gestrickt oder ist das nicht das sprichwörtliche "german engineering" - sehr spannend !?

[Gast_28792]

Steller: Weiß ich nicht. Der JIVE ist schon ziemlich aufwändig.

[Gast_28792]

Die Referenzspgs.quellen streiche ich, das kann nicht sein. Einfachere Toleranzen bei Spgs.teilern, also nur bei der U-Messg. War schon im Bett, was einem so alles noch durch den Kopp geht bzgl. irgendwelcher Sachen, die man von sich gab...

N8 denn

[Gerd Giese]

Moin Tom,

puuuuuuh - man, man, nu hab ich fast'n schlechtes Gewissen was ich angerichtet habe. Schon das FAQ-State bedarf einer gehörigen Zeit ...
Willst das hier einpflegen lassen: http://www.modellbauladen-berlin.de/index.php/jlog/faq/

Messungen folgen wie verabredet...

(per PN schreibe ich Dir: das ich zur I-BEC Abstimmung anrufen werde)

[Gast_28792]

Moin Gerd!

Nix "lassen", selber machen, habe mich längst mit Wordpress angefreundet.
Drag & Drop, bissel nachfummeln, fertsch.

"Zeitbedarf"? Weiß nicht, wie lange habe ich denn gepinselt? Sowas fließt bei mir am Stück so raus, kommt mir zeitlich nicht lang vor. Waren 20 Min. oder so. "Zeit" werde ich erst vermissen, wenn mir auf der Intensivstation Einer den Tubus reinstopft..

Moin Moin. Tom

[dynaudio79]

moin.
bitte editieren bei scholand:

Anwenderverzeichnis von LogView:
W7:
JLog.ini kommt in C:\Users\<user>\AppData\Roaming\LogView\Geraete\OpenFormat
JLog.jpg kommt in C:\Users\Steffen\AppData\Roaming\LogView\Geraete

[Gast_28792]

Oops! Thx.

Selber schuld, wer nicht Steffen heißt.

CU in Skype.

Tom

[Gast_28792]

Hab Obiges, etwas modifiziert/ergänzt, in die FAQ gedrückt.
Hoffentlich war das gut..., ich bin ja immer ein Fan technischer Transparenz, kann nur manchmal nicht einschätzen, ob ich dadurch nicht eher Verunsicherung säe, weil alles in den falschen Hals kam..

[dynaudio79]

...diesmal zu transparent meiner meinung nach.

[Gast_28792]

Ach ja.....

Immer uff det Schlimme..

War exklusiv für Gegie.

Ich penn' noch dreimal drüber und mager' es ab dann.

[Gerd Giese]

Moin Tom, moin glückliche Besitzer des Jlogs,

hier ein Test zum aufgezeichneten BEC-Strom des JIVE/Jlog.
Erst einmal nur die statischen Werte einfach händisch an meiner
kleinen DC-Last 3A ein/aus geschaltet:
http://www.rc-network.de/forum/attac...8&d=1275584346

... hier das Ergebnis - es spricht (fast) für sich:


Wer Diagramme deuten kann wird feststellen, dass der BEC-Strom perfekt angezeigt wird aber die Spannung
eben hoch konstant!

Der I-Ripple von 0,1A ist hier (vermutlich) dem Messwandler zuzuschreiben, halt die max. Auflösegenauigkeit.

Nun die BEC-Spannung: Der Jive misst natürlich intern die BEC "realtime" und entsprechend konstant
wird sie als Datensatz auszugeben. Spricht für das Jive BEC -> hoch konstant!

Als nächster Test wird sein: Was gibt er bei Überlast aus UND welche Impulsauflösung hat er
(100ms/S meines Wissens) ... bin gespannt.