| Anzeige | Anzeige | |
 |
 |
|
Das verstehe ich jetzt nicht ganz, Christian, denn mit dem Timing drehe ich auch maßgeblich an der Effizienz des Ganzen.
Nach meinem Verständnis wäre das dann so wie Mauerstein auf'm Gaspedal und Fuß raus zum Bremsen.
Tom
-----
Ähhm.., sorry, Ralph.Steffen war noch late night bei mir, und da saß mir der Schalk im Nacken.
(Nu ham'wa endlich die gelben Displays, gelb==gelb, und nicht gelb==grün. Halleluja, finally.)
Bevor ich nun in die Kiste krabbel, würde ich gern noch was zur heutigen Messorgie ablassen:
Gegies Tests mit programmierbarer rein Ohmscher Last haben tatsächlich bewiesen, dass wir Impulse (Strom) in nahezu genauer Amplitude loggen können. OK.
Das für 500us Impulsbreite.
Wie sieht's mit geringeren Impulsbreiten aus? Denn irgendwann spuckt uns die Conversion Time des ADC im ATmega (im JIVE) doch in die Suppe.
Wie breit sind denn die Killerimpulse der Servos? Ich weiß das nicht.
Allerdings sind unsere Monsterservos auch induktive Lasten, sprich, der Strom wird Blindanteile haben..
Zusammengefasst: Ich würde solange nicht behaupten wollen, dass wir in der Lage sind, im Log die Amplituden relevanter Impulse sehen zu können, wie da nicht ein entsprechendes Servo in ständiger Umsteuerung drauf war und wir parallel mit geeignetem Equipment äugten, mit einem Speicheroszi oder so was.
Andererseits: Selbst wenn wir die sehen könnten, halbwegs realistisch nach deren Amplitude, bliebe uns doch nur zu hoffen, dass die Speicherfähigkeit des BEC in der Lage ist, das abzufangen, - denn ausregeln kann es der Spannungsregler sowieso nicht.
Eine Schlußfolgerung davon ist auch: Ein Stützakku ist trotzdem nicht sinnlos, oder eben Green Caps. Gegen Low-ESR-Elkos am Ausgang des BEC, womöglich noch Rubycons, würde ich aber vehementes Veto einlegen.
Mit Kapazitäten am Ausgang sollte man ein's vermeiden: Dass der BEC im Einschaltmoment einen Kurzschluss sehen könnte! Die Folgen durch schnelles periodisches Reset beider oder eines der beiden Prozessoren sind etwas unabsehbar.. Siehe meinen gestrigen Lasttest mit dem kalten Glühfaden einer Kfz-Lampe.
N8. Tom
(Unterstrich von mir...)Zitat von dl7uae
Moin Tom - Du siehst ja was "echte Sensationen" bewirken ... genau - nix, kaum Reaktionen (habe ich fast erwartet)!
Dafür gibt es nur drei Ursachen.
1. die Leser wissen nicht dessen Brisanz einzuschätzen (Daran müssten ich/wir arbeiten).
2. Die Datenflut kommt zu früh ...
3. Ihnen ist es wurscht ...
Deshalb werde ich mich vorerst nicht weiter an technisch Wissenswerten beteiligen bzw. hier Posten - siehe Unterstrich auf deine Frage!
Die JLOG-Einsichten rufen natürlich, auf Grund der völlig neuen Einblicke, einen Haufen weiterer Fragen auf. Ich warte noch ab wie "verzettelt" es hier weiter geht...
Alles weitere Tom, gerne wie gewohnt!
Mit fliegerischen "DC-16" Grüßen
Gerd
"Watt ihr Volt"
www.elektromodellflug.de
Testpartner
FMC-Lübeck
Moin,
Steller-Regler wird in der Umgangssprache meist gewürfelt oder gar gleich gestellt!
>> konstante Drehzahl - für und wieder ...<<
Ist Euch eigentlich bewusst, dass der JIVE/JAZZ/KOBY zu der seltenen Spezies zählt,
die IMMER im Reglermodus arbeitet! D.H.: Er versucht lastunabhängig drehzahlkonstant
zu regeln auch im NICHT Hubi-Modus!
Meines Wissens bisher die Einzigen die das machen ...
Also ist die Frage zum Regelmodus beim K-Regler (hier trifft die Bezeichnung zu) nur schwer zu verneinen ...
(Einzig die D-I-Regelanteile mit Hochlaufzeit lassen sich noch beeinflussen ... aber ein Regler sind die K immer)
Mit fliegerischen "DC-16" Grüßen
Gerd
"Watt ihr Volt"
www.elektromodellflug.de
Testpartner
FMC-Lübeck
Hallo Gerd und Tom,(Unterstrich von mir...)
Moin Tom - Du siehst ja was "echte Sensationen" bewirken ... genau - nix, kaum Reaktionen (habe ich fast erwartet)!
Dafür gibt es nur drei Ursachen.
1. die Leser wissen nicht dessen Brisanz einzuschätzen (Daran müssten ich/wir arbeiten).
2. Die Datenflut kommt zu früh ...
3. Ihnen ist es wurscht ...
Deshalb werde ich mich vorerst nicht weiter an technisch Wissenswerten beteiligen bzw. hier Posten - siehe Unterstrich auf deine Frage!
Die JLOG-Einsichten rufen natürlich, auf Grund der völlig neuen Einblicke, einen Haufen weiterer Fragen auf. Ich warte noch ab wie "verzettelt" es hier weiter geht...
Alles weitere Tom, gerne wie gewohnt!
bitte hört nicht auf alles, was jetzt plötzlich mit dem JLog zu sehen ist, zu analysieren.
Uns Lesern ist es nicht wurscht.....
Ich denke nur, daß viele mit der neuen Flut an Infos fürs erste überfordert sind. Dauert ein bisschen, bis man als Nichtelektroniker manches schnallt. Aber mit dem Lesen Euerer Diskussionen begreift so mancher schön langsam was man da plötzlich für ein Tool nutzen kann.
FAQ, ein sinnvolles Tool, wenn da in einfachen Worten drinsteht z.B:
PWM: was sagt der Wert von z.B 100%? Was kann ich am Setup verändern und was bewirkt es dann.
A-BEC: z.B kein Durchschnittswert sondern echte Ströme. Nicht nur die Knüppelei sondern auch die Servos spielen da vehement rein......
I-Bat: z.B: ich sehe wie mein Akku einbricht. Was kann ich tun.....:ev kleineres Ritzel, neue Akkus ;-), schwächeren Motor?
Ich denke, da könnten die interessierten Nutzer schnell viel über ihre Setups und Komponenten lernen.
Daß es auch Benutzer gibt, die nur nach Glanz, Optik und Verpackungsaufdruck ihren Heli zusammenstellen muss Euch hier in keinster Weise bremsen.
Bitte weiter so!
Viele Grüße, Georg
so, jetzt habe ich in abstimmung mit tom nochmal nachgeputzt.
im sinne der erhaltung der übersichtlichkeit:
hier geht es nur um den logger und seine funktionalität!
ralph
Moin Georg!
Am Sonntag ging's ja nur darum, dass erstaunlicherweise festgestellt wurde, durch Gerd, dass das I-BEC-Log auch Stromimpulse aufzeichnet, jedenfalls noch bei 500us Breite.
Ich habe nun gar keine Erfahrungen mit Equipment, was das nicht können soll. Auch weiß ich nicht, welche Impulsbreite denn unsere Servos so i.Allg. abliefern.
Gegie als alter Mess-Freak ist aber aus dem Häuschen, sagt a), das mit den Impulsen in fast naturgetreuer Amplitude wäre outstanding, und auch b), dass die erstmal nachgewiesene 500us-Fähigkeit für unsere Servos ausreichen würde.
a) kann ich ihm nur abnehmen, bei b) bin ich der ungläubige Thomas. Sorry, da komm' ich nicht über meinen Schatten als zweckpessimistischer Tekki.
Die anderen Einblicke in die Eingeweide:
Zunächst mal ist das ja von den Messwerttypen nun auch nicht soo viel Anderes, außer den beiden Temperaturen nur noch die PWM.
Generell ist der Unterschied natürlich, dass wir es mit den Augen des Stellers zu sehen bekommen.
Was die PWM betrifft, entbrannte darüber hier der "militante Disput".
PWM ist zunächst nur interessant für das Setup der Drehzahlregelung, also Mode 4 oder 11, so, dass während eines Fluges, also über die Entladezeit des Akkus, immer noch genügend Regelreserve in PWM bestehen bleibt.
Der Disput dreht sich darum, dass das eigentlich einen gut Teil akademischen Wert hat,
1. entsprechend der Grundfrage, ob Drehzahlregelung (Heli) angesichts der erreichbaren Drehzahlsteifigkeit heutiger Motoren überhaupt noch zeitgemäß ist. Bleibt natürlich noch der Akku (sein konkreter Innenwiderstand), ist der ein Weichei, übernimmt der bei volle Pulle (PWM==100%) die Rolle des "Drehzahlstellers". - Außerdem baut natürlich die mittlere Spannung über die Flugzeit ab, die DZ verringert sich generell.
2. der generellen Frage nach, ob die Drehzahl nun unbedingt soo stabil gehalten werden muss, also stabiler, als sie heutige Wald&Wiesen-Motoren und -Akkus mit reiner Gaskurve erlauben würden. Meine Meinung: Nö, DZR ist nicht unbedingt erforderlich, sie ist rein theoretisch gut für's Heck und schön bequem beim Einstellen, einfacher, als ewig an einer passenden Gaskurve rumzuknispeln, was ja eigentlich auch zusätzlich Mischer von Zyklisch auf Gas erfordert.
Zurück zum I-BEC: Hier kommt dann das Abgleiten zur ewigen Frage, ob Stützakku/Green Caps nun erforderlich sind, - außerdem bei Kondensatoren am BEC-Ausgang die Frage, was da nun noch gesund ist, und wie man's macht. Gemeint ist eine Anlaufschaltung für Kondensatoren, um den BEC im Einschaltmoment nicht kurzzuschließen. Besondere "Experten" wie mein Spezialfreund "Satsepp" (ich taufe ihn nun auf "Capsepp") halten mir da die Specs des JIVE-BEC unter die Nase: Kurzschlussfest. Sicher ist er das, es wurden aber (zumindest von mir) auch Nebeneffekte bemerkt, wenn es zu multiblen Resets während des Power-On kommt wegen eines Kurzschlusses des BEC durch solche Sachen.
Dann hatten wir Sonntag auch insgesamt einen OT-Abrutscher bzgl. des BEC.. Mich hatte einfach interessiert, was das Ding nun wirklich kann, also nicht nur nach I-BEC, sondern auch auf U-BEC äugend, also hier unverfälscht im Inneren des JIVE betrachtet.
That's it. Was vergessen, was verzerrt?
Tom
Danke Tom,
laßt euch nicht bremsen
Viele Grüße, Georg
... zur Funktionalität und Post #499
Hi,
zur Ehrenrettung des UniLog sollte man noch ergänzen (das tat mir richtig
Leid wie negativ der plötzlich aussah), dass er im Grunde ein hervorragendes
Messmittel ist und eine Aufzeichnungsrate von guten 63ms garantiert.
Leider war er bei diesem "brutalen" Messeinsatz mit seinen 63ms (Datenerfassungszyklus)
überfordert, so das beim Erfassen der Messwerte ein Mittelwert gebildet wird.
(ob über einen Integrator oder nicht ist mir nicht bekannt - der halbe Messwert spricht dafür)
Würden die (Mess-) Stromimpulse länger - also Richtung 50ms (jetzt Faktor 100 verlängert!) - stünde
wieder Gleichstand bei den Messergebnissen. (... so vermute ich - nachgewiesen noch nicht).
So oder so, mit der Datenerfassung des JLOG am Jive steht uns ein nicht
hoch genug einzuschätzendes Messmittel zur Verfügung!
Ich werde jetzt noch testen wie hoch die Stromspitzen tatsächlich von fünf Power Digitalservos (Servo: DES 678 BB, MG) sind.
(Wunsch von Tom - dem ich selbstverst. nachkomme!).
Mit fliegerischen "DC-16" Grüßen
Gerd
"Watt ihr Volt"
www.elektromodellflug.de
Testpartner
FMC-Lübeck
Ja, Gegie, sei mein Messknecht!
Wg. des Unilog:
Ich wiederhole noch mal, dass ich annehme, dass Stephan auf der analogen Seite (OPV, also Instrumentation Amp) absichtlich per Integrator (Tiefpass) beruhigt hat. Ich werde ihn das einfach fragen.
Tom
Hallo Tom!
Gestern ist auch mein JLog angekommen. Der Zusammenbau war echt schnell erledigt.
Der anschließende Funktionstest verlief auch positiv.
Auch von mir nochmal ein großes DANKE an Dich / Euch, dass Ihr Euch nicht von allen Unwegbarkeiten und Unkenrufen abbringen habt lassen. Ist echt ein Klasse Teil...
Nur kleinstweich (Microsoft) spuckt wie üblich in die Suppe...
Die letzte Version des JLC installiert .NET 3.5 SP1...
Die SW will aber eigentlich die Version 4.0...
Habe ich mit Windows Update nicht weg bekommen... Habe dann .NET 4.0 manuell nachinstalliert... Danach hat alles geklappt!!!!
Also nochmals... DANKE & LG, HANNES
Hannes, komm' ich jetzt nicht ganz mit.. Die beiden letzten Versionen, also 1.6.5.x, wollen nur noch die 3.5SP1, kleiner ging's nicht, nicht mehr 4.0. Diese Änderung, von 4.0 weg, war eine Empfehlung von TomBa, weil Viele die 3.x bereits im OS haben, die 4.0 aber erst nachinstalliert werden muss, was automatisch während der Erstinstallation gehen sollte.
Hattest Du noch eine Vorversion des JLC rumdümpeln, die Du nicht deinstallierst hast?
Mit der Änderung auf 3.5SP1 gibt's jedoch den Effekt, dass die eigentliche Installation, also die der Applikation, in einem neuen Fenster erfolgt, was nicht hochpopt, nur unten im Taskbalken zwinkert, man muss es anklicken, um einmal cool "Yes" zu sagen.
Tom
Hi Tom!
Nein, war ein jungfreulicher Notebook mit Windows XP/SP3. KEIN JLC vorinstalliert gewesen.
Wie schon geschrieben, installiert Deine Applikation .NET 3.5xxx
Dann kam auch das von Dir erwähnte PopUp und danach die MS-Fehlermeldung: (sinngemäß wiedergegeben...)
Das System benötigt die Common Language Runtime 4.0.30319.0....
Nach einer Google Suche bin ich dann darauf gestoßen, dass der Kübel .NET 4.0 meint...
Manuell installiert & es ist gelaufen..
Ja, ja, MICROSCHROTT
LG
Hannes
Oops! Das is ja doof, ist aber letztendlich meine Schuld. Muss ich noch mal gucken bzw. meinen "Mentor" TomBa befragen. Dann war mein Herunterschalten bzgl. der .NET-Version nicht vollständig. MS ist hier unschuldig.
Die Geister, die ich rief.... Nun werde ich immer öfter nach der Firmware-Version 2.5 gefragt, die mit Verbrauchslogging (mAh).
Daher das hier mal wieder als "Early Notice", sprich, Template für die FAQ:
******************************************************************
Selber Flashen:
Der Logger hat nur EIN Anwendungsinterface, eine asynchron-serielle Schnittstelle, das sind also 3 Leitungen, Rx (serieller Empfang), Tx (serielles Senden) und Masse.
Der Pegel ist sog. "TTL-Pegel", zwischen 0 und 2V.
Daher noch mal der Hinweis: Obwohl das Protokoll des seriellen Interfaces eines Computers, PC z.B., auch asynchron-seriell ist, darf der Logger keinesfalls hier angeschlossen werden! Der Pegel ist nämlich RS-232, -3V .. +3V, die -3V würden den Microcontroller des Loggers zerstören!
Auch handelsübliche USB-Umsetzer verwenden an deren Ausgang RS-232!
An Rx des Loggers konnektiert der JIVE, der Logger lauscht also nur.
Das Flashen erfordert aber eine bidirektionale Kommunikation, der Logger sendet auch (Tx).
Der OpenFormat Livestream aus dem Logger für LogView live (LV liest von einer seriellen Schnittstelle) kommt auch aus Tx des Loggers.
Um nun selbst flashen zu können, benötigt man ein "FTDI", ein USB-Interface vom gleichnamigen Hersteller, und zwar eines, was auf der seriellen Seite (Logger) TTL-Pegel verwendet, 0..2V.
Neben der Anwendungssoftware enthält JLog einen Bootloader, das ist ein separates Stück Software, was zum Flashen des Gerätes benutzt wird. Beim Flashen kommt das Programm (die Anwendung) in den FlashROM, sowie Daten in den EEPROM.
Die Hardware des JLog wird einmalig mit einem Programmer (Hardware) geflasht, wobei der Bootloader aufgebracht wird. Der Bootloader ist hier speziell, er erwartet das Anwendungsprogramm in verschlüsselter Form, der Schlüssel ist individuell und wird von der Seriennummer referenziert.
Nach dem einmaligen Flashen mit dem Programmer (bei mir) gibt es nur noch einen Zugang zum Flashen, den "SecureBootLoader", wie der Bootloader wg. Obigem hier genannt wird.
Nun kann man mittels eines Programms, "Updater.exe", das jeweils für eine Seriennummer individuell generiert wird (bei mir), die Anwendungssoftware des JLog via das serielle Interface des Loggers (s.o.) neu flashen.
Was ich neben dem "Updater.exe" dazu brauche, ist so ein FTDI, ein USB-Interface zum Logger hin. Das FTDI erzeugt in Windows einen VCP (Virtual COM Port, COM1..256). Es konnektiert Rx, Tx und Masse des Loggers mit TTL-Pegel, besetzt zusätzlich weitere Leitungen, die es dem Updater ermöglichen, den Logger via USB zu resetten, was den kurzzeitig in den Bootloader bringt, mit dem man (der Updater) ja zum Flashen kommunizieren will.
Die Stromversorgung des Loggers erfolgt dabei aus dem USB via den FTDI-Chip.
Der Updater.exe macht aber alles allein, die Bedienung ist total easy, man muss sich nicht um die verwendete COM etc. kümmern.
---------------
Da Scholand Modellbau das USB-Interface noch nicht im Angebot hat:
Das FTDI ist von Sparkfun und gibt es als sog. "Breakout" (kleine Platine) in DE hier und hier. Das ist das sog. "Basic FTDI 5V NEW", die 6-polige Buchse zum Logger hin liegt unter dem Breakout. Es geht aber auch das etwas längere Vorgängermodell mit der Buchse an der Stirnseite des Breakout, erhältlich in DE hier, hier und hier.
Damit die 6-polige Buchse des FTDI pin-kompatibel zur 6-poligen Stiftleiste des Loggers wird, müssen an der Buchse des FTDI die beiden Anschlüsse für seriell Rx und Tx getauscht werden. Bei der NEW Version des FTDI geht das etwas bequemer. Da die Anschlüsse der Buchse aber "SMT-like" auf die Platine gelötet sind, ist Vorsicht geboten! Man sollte nicht versuchen, diese von der Platine abzulöten, stattdessen die beiden einfach durchknipsen und mit zwei kurzen Drähtchen über Kreuz verbinden.
"JUI" wiederum ist so ein umgebautes FTDI, verwendet aber zusätzlich 4 Dioden, 1 Widerstand und 1 Servokabel. JUI ermöglicht neben dem Selber-Flashen auch LogView live (s.o.). Siehe diesen Schaltplan.
---------------
Um einen Updater.exe für seinen Logger erhalten zu können, muss man im Augenblick noch mich ansprechen. Ich benötige dazu die Seriennummer (S/N) des Loggers, man findet sie in der Datei "serial+sw.txt" auf der SD, sobald der JLog einmal mit dieser SD lief.
Tom
Forenrechte
Zitieren
Lesezeichen