Posts by bernhard gh

    Könnte ich das BEC, quasi als Sicherung verwenden und „nur“ mit 7,2 V einspeisen, und die Pioneer bedient dich bis zum Gleichstand der Spannungen aus der separaten Batterie?

    Hallo Rainer,

    ich habe in einem E-Segler ein BEC (YGE 95), eingestellt auf 7,2 V, einen kleinen Sicherungsakku 5s NiMH 800mAh (ca 60g), der vollgeladen (nicht im Peak) etwa 7,2 V hat. BEC ist die führende Stromquelle. Sollte das BEC ausfallen (bisher nicht passiert), geht der Stützakku unter Last sehr schnell auf 6,8 - 6,9 V. Mit einem Spannungsalarm von 7,1 - 7,0 V am Empfänger bekommt man sofort einen Hinweis auf eine BEC-Fehlfunktion. Die Kapazität des Akku würde nicht für lange Flüge reichen und der Spannungseinbruch eines kleinen NiMH bei höheren Strömen ist erheblich, es reicht aber für eine kontrollierte Landung allemal.

    Das BEC bei YGE Reglern ist sehr leistungsfähig und meines fällt selbst bei Manövern mit 6-7 HV Servos (5x X10, 2 X08) nicht unter 7,14 V (geloggt über Texy/Core). Beim Abstecken ziehe ich zuerst den Antriebsakku ab und kann damit die Funktion des Alarms überprüfen sowie den Ladezustand des Stützakkus. Da die BEC Spannung mit 7,2 V auch nur 0,3 V unter dem Ladeschlusspeak des NiMH (7,52-7,54 V bei diesem Akku) liegt, sind die Ströme vom BEC in den Stützakku minimal.

    Diese Konfiguration kannst Du mit anderen Stützakkutypen, z. Bsp. LiPo oder LiIon auf 8 V einstellen, wie Richard schreibt.

    Ob dann eine Pioneer an dieser Stromversorgung dranhängt oder 1-2 PBR9D ist mit den jeweiligen Pros und Cons hier ja schon diskutiert.

    Meine Motivation, überhaupt einen Stützakku zu verwenden, ist nicht die Sorge um einen Ausfall des BEC, sondern die Sorge um einen Zusammenbruch des Flugakkus - das habe ich bereits bei einem Jet-Durchstart durch Tiefentladung erlebt und war froh, einen Stützakku an Bord gehabt zu haben.

    Gruß

    Bernhard

    Man kann ja für diese eine Ansage auf einen anderen Sprecher wechseln - oder aber 'Standard' verwenden - wie klingt das dann bei Queen?

    Ich lasse mir alles in Deutsch ansagen, nur 'SnapFlap' auf English - das kriegt nur ein Brite unfallfrei und verständlich hin.


    Ich bin eher durch Zufall draufgekommen, dass ich für jede Funktionsansage unterschiedliche Stimmen auswählen kann

    Hallo Mike,

    ich verstehe Deinen Einwand nicht so recht: ich lerne Failsafe auf Butterfly einmal ein, und unabhängig von meinen FMs und unabhängig von anderen Funktionen läuft das Modell in die eingelernte Failsafeposition = Butterfly wenn der Sender aus ist.

    Probiere es mal aus!

    Gruß Bernhard

    für die Wunschliste:


    Programmierung der Failsafepositionen für jedes Servo bzw Funktion über einen Button, so dass die gewünschte Failsafeposition am Sender eingestellt wird und mit einem Button gespeichert wird.

    Das ist heute schon Standard: man kann für eine Funktion eine Failsafeposition mit nur 1 Buttonauswahl einlernen. (Failsafe habe ich noch nie auf der Servoebene eingelernt)

    z.Bsp. für Butterfly: in der Funktionsliste den FS Button bei Butterfly aktivieren. Da bis auf das SR Servo alle Servos bei Butterfly beteiligt sind, erscheint auch bei allen Funktionen, in die diese Servos eingebunden sind, der Hinweis auf Failsafe. Dann Geber (bei mir Mode 2 = Butterfly ist auf Knüppel links) in die gewünschte Position, mit OK bestätigen. Erledigt. In nicht mal 1 Minute.

    Ich programmiere Failsafe bei Seglern immer auf Butterfly, E-Segler Butterfly und Motor aus, Motormodell nur Motor aus


    Grüße, Bernhard


    Hallo Ratsche,

    das geht nur bei Sender eingeschaltet lassen. Wenn der Core herunterfährt, werden beim erneuten Einschalten alle Sensoren, Timer etc. neu gestartet.


    Gruß

    Bernhard

    Hallo Daniel,


    auf gut fränkisch: etzedla! Also den in dem aktuellen Flug bisher maximal erreichten Wert permanent anzeigen, daneben die gerade aktuelle Geschwindigkeit. Wenn ein neuer Maximalwert erreicht wird, den dann in die Permanentanzeige übernehmen ... soweit verstanden. Die Maximalwerte werden ja gespeichert und auch überschrieben bzw ständig aktualisiert, da sie nach dem Flug ja als Min und Max abgerufen werden können. Die Softwareentwickler müssten also nur diese Speicherwerte in einem zusätzlichen Widget permanent anzeigen und nicht nur auf Doppelklick-Abruf. Ist ja vielleicht machbar.

    Für mich eher nicht sinnvoll, da ich dann ständig die Lesebrille auf- und absetzen müsste ^^ Ich lass mir aktuelle Werte von meinem Bauchredner 8) vorlesen.

    Viel Spaß bei Euren Rennen!


    Gruß Bernhard

    Hi Daniel,


    was ist denn der Unterschied zwischen der zuletzt gemessenen Höchstgeschwindigkeit und der aktuellen? Ist schwer zu verstehen, sorry.

    Groß = großes Widget wählen. Während des Fluges in Ruhe ansehen? Kann man schon machen, den Einschlag hört man ja.

    Vielleicht ansagen lassen?


    Gruß

    Bernhard

    Hallo Dan0111,

    schade, dass Du so eine negative Erfahrung gemacht hast - aber das muss definitiv nicht sein, und dazu braucht es auch kein Update o.ä.. Ich programmiere bei allen Modellen erst mal die Grundfunktionen und stelle dabei bei jedem Servo nicht nur den für die jeweilige Funktion gewünschten Servoweg ein, sondern auch den maximal möglichen Servoweg, bevor das Servo mechanisch evtl auf Anschlag läuft. Dazu können wir ja die absolute Wegbegrenzung für jedes Servo eingeben. Dann kann auch bei Überlagerungen von Funktionen, wie z.Bsp. max Butterflyweg der Klappen, der theoretisch z.Bsp. über das Mitlaufen bei der der QR Funktion noch gesteigert werden könnte, das Servo nicht an eine mechanische Begrenzung anlaufen.

    Und alle Feinheiten, wie Anzahl und Wirkrichtung der FMs, Snap Flap usw., programmiere ich erst später, nach den ersten Flügen, weil ich dann sehe, was ich noch brauche / wünsche.

    Aus meiner Sicht ist die offene Programmierplattform des Core hierfür ideal. Und meine Philosophie ist, so wenig als möglich, wirklich nur das Nötige programmieren, dann bleibt die Programmstruktur übersichtlich und transparent.

    Herzliche Fliegergrüße, Bernhard

    ... kann ich für mich ebenfalls nur bestätigen; dass Modellflieger signifikant häufiger im Lotto gewinnen, ist auch nicht belegt. Leider :(:saint:


    Noch mal ernsthaft: Auslöser für die Vermutung, dass am Sender ein Fehler vorliegt, war das beginnende Ansteigen der Lost Frames beim PBR-7S bei 12:40:57 im ersten Logfile, das Werner in #1 gepostet hat. Danach fehlen ca 12 sec (hinter der Kuppe, Crash?), dann im Graph die Anzeige, dass Lost Frames maximal sind (=keine Funkstrecke).

    Könnte nicht das folgende Szenario denkbar sein: Modell liegt im Funkloch hinter der Kuppe, dann nach 12 sek bewegen (?) sich der Pilot und der Träger des Senders (siehe #42) auf das Modell zu und es kommt wieder zur Funkstrecke und Wiederaufnahme von Logfiles.

    Werner schildert in #42, dass er das Modell gestartet hat, das Modell dann auf Steuerbefehle nicht reagiert hat, mit dem zügigen Hangwind nach links abdrehte und dann hinter einer Kuppe offensichtlich ein Rad schlug.

    Dieser Flugverlauf wäre auch erklärbar durch eine zu geringe relative Fluggeschwindigkeit des Modells und damit Steuerunwirksamkeit, insbesondere angesichts des offenbar von rechts strömenden relativ starken Hangwindes (sieh #42).

    Derartige Wahrnehmungen, nämlich dass das Modell auf keine Knüppelbewegung reagiert, kenne ich zur Genüge aus Situationen kurz vor oder während eines Stall. Bei genügend Höhe 'hat man den Flieger wieder' nach ein paar Sekunden, nach Fahrtaufnahme und Wiederanliegen der Strömung. Bei 2-3m über dem Boden führt ein Stall u.U. dann zu 5-6g Negativbeschleunigung, wenn dem Modell der Boden entgegenspringt.


    Bei aller Technikaffinität und Faszination an den genialen funktechnischen Möglichkeiten, die wir heute haben: denkt bitte daran, dass Modellfliegen so ganz nebenher noch mit Aerodynamik und den (kleinräumigen) atmosphärischen Luftbewegungen zu tun hat. Und diese sind nicht 100% beherrschbar. That's life - und das ist gut so!

    Hallo Modellpiloten,

    ich habe hier gespannt mitgelesen und gestaunt über die fachkundigen Analysen zur Funktechnik und zu den gemessenen und aufgezeichneten physikalischen Werten. Ich ziehe für mich das Resümee, dass die Sende- und Empfangstechnik allem Anschein nach funktioniert hat, und meinerseits unterstreiche ich mein Vertrauen in das technische Design der Core und insbesondere das Super-Engagement von Herrn Deutsch und dem PBS Team. Und ich glaube auch dem Piloten, der das Modell schon vorher in einigen Flügen sicher steuerte, dass er keine Steuerfehler machte.

    Ich möchte zu bedenken geben, dass wir Modelle in der durchaus mal sehr heftig durchgerührten (geschüttelt wohl auch) und bewegenden unteren Atmosphäre steuern. Thermische Turbulenzen, Scherwinde, bodennahe Leewalzen und Verwirbelungen wirken sich manchmal so heftig auf Modellflugzeuge aus, dass man meint, dass ein Hammer den Flieger trifft und Gegensteuern scheinbar nichts mehr bewirkt. Insbesondere das (alpine) Hangfliegen bietet hier so manche Überraschungen, und durchaus spannende Herausforderungen.

    Für mich bleibt als Fazit: ich habe weiterhin Vertrauen in die/den Core. Und es bleibt noch eines, zumindest an Selbsterkenntnis: ich habe auch nach Einführung der 2,4 GHZ Technologie das eine oder andere Modell verloren. Technische Ausfälle waren es aber definitiv nicht - Ursachen zerebral oder atmosphärisch.

    Also: auf dem Boden des Vertrauens bleiben und die Flieger mit ungetrübtem Spaß in die Lüfte befördern.

    Herzliche Fliegergrüße, Bernhard

    Hallo Eric,

    ich konnte auch nur das jeweils erste Logfile mit der 00 Endung vom Stick auslesen. Dann kam ich durch Zufall drauf, alle Logfiles auf die Festplatte (in einen Ordner) zu kopieren. Nachdem ich mit dem 00 file starte, werden nun alle Logdateien bis zum letzten Logfile in einem fortlaufenden Graphen dargestellt, egal wie lang der Flug dauerte. Offensichtlich 'findet' das Terminal auf dem Stick nur die erste Datei, von der Festplatte dann aber automatisch alle Folgedateien.


    Probier's mal aus, mit besten Grüßen

    Bernhard

    Die PB Weiche Sensor V3 gibt über den P²Bus die Spannungen der 2 angeschlossenen Akkus vor der Weiche an den Core, der RX dann die geregelte Spannung. D.h. es liegen dann 3 Spannungswerte für die Telemetrie vor.

    Der Digiswitch gibt ebenfalls die Akkuspannung an den Core weiter, die ggf heruntergeregelte Versorgungsspannung kann man dann über RX empfangen.

    Wenn (BEC) Regler Telemetriewerte liefern, kann natürlich damit der Antriebsakku überwacht werden. Ansonsten kann man mit dem PBS V60 die Akkuspannung über das Steckersystem (einlöten) oder den Balanceranschluss via P²Bus übertragen.

    Ich wollte soeben auf 2.45 updaten. Als Rückmeldung kam, dass mein Core mit 2.35 aktuell ist.

    Habt Ihr den Download der v 2.45 erst mal gestoppt?


    Das wäre ja nicht verkehrt.

    FM issues: do I understand correctly that you want to programme a fixed / forced combination of gear and flaps? I.e.:

    standard mode: gear up + no flaps

    half flap mode. gear down + ..% flap

    full flap mode: gear down + full flap

    In this case a possible programming could be: first assign these functions as combination of functions to a 3 way switch (0% gear and 0% flaps = standard // 100% gear and 50% flaps = half flap // 100% gear and 100% flap = full flap). If you assign the respective FM's to the same switch, you then can programme and assigne individual elevator trims, fade in-fade out times etc.

    In this case you have a forced linking of gear and flaps. But I am not sure whether this is your intention.

    Core battery alarm: so far you sorted out this issue - done

    For the Core radio itself there is an inactivity alarm, which can be adjusted in time (radio settings). After a period of time without touching sticks or switches, the Core activates a tone in order to remind you to switch off, or become active again, and so you can check the Core battery status as well. Avoids deep discharging.


    I'll try to understand the FM issue and probably come back on this.

    Hi,

    sorry for my probably misleading response. I 've seen your post and mentioned that no one else did response, so I did, as I have an issue with alarm settings quite opposite to yours: my alarm settings for the model / rx power supply (single 5s NIMH eneloop 2000 with Digi Switch V2 for 5 servos in a Sebart SU 29-140) lead to repetitive alarms (noisy and chaotic) when all servos work simultaneously, as battery breaks down by 0.5-0.8 V. So I switched my alarms off. Indeed pointless, but I will not fly unless power supply is improved, and in this sense, alarms work as they should do :-)


    But this is not the answer to your question: I just set up alarms for 7.20 V, the actual voltage of my core batteries this afternoon, in order to simulate your case. Alarms worked as intended in my situation. Sorry, I have to say that I can't be of help for your particulate situation. I never let my batteries go lower than 6.8 / 6.9 V. Better address this post to Richard or more experienced guys than me.


    Best wishes

    Bernhard

    Hi,


    I just want to respond to the latter, the alarm issue: the Core radio will never switch off at a pre-defined voltage level, it would be more of a fade away .... Imagine, your model is airborne and the radio switches off - this would end up with desaster. We have better chances to land in time with a very little remaining capacity in the batteries of the radio. Your issue with the alarms is that they did not signal as clearly as expected. The advice I can give is: check the volume of the voice alarm, was it muted? Probably in your case the remaining battery capacity was to low to activate vibration? What I do for all essential alarms: set alarms (vibration and/or speech, and/or signal tone) to 'repeatedly' instead 'singularily' at a level which allows you to operate radio and / or model at least for another 10 mins, time enough to land safely. In case you set alarms to singular, you may not take notice of the alarm, and it will not be repeated, as alarm is activated only once, when the value drops the critical value.In case you set it to 'repeatedly', the alarm will be repeated, as long as the value is below the critical value.

    Attached pics: I set the alarm for core bat1 to 7.20 V (for demonstration only) and to repeatedly = wiederholend.

    The alarm will work whenever a receiver is active, independently what type of receiver you are using. Hope this helps.

    Regarding the FM issue, I am not as experienced as I should be to analyze your issue and give advice.

    Regarding lockdown: good luck, stay healthy, and let us hope for clear skies in spring and always happy landings

    Hi Shannah,

    switching the Digi V2 on is a two step process: press the button for 1-2 seconds until the LED flashes violett; then press the button a second time, the flashing stops and the Digi V2 is on. Switching off: reverse process.

    Initial settings: select the power source, you can select from 2s LiPo, 2s LiFePo, 2s LiIon and 5s NiMH.

    (I use the Digiswitch with a 4s NiMH in the same manner as you do, means as a backup power source for the leading BEC. When using a 4s NiMH instead of a 5s the Digiswitch will indicate low capacitiy for the battery, but I control the 4s NiMH voltage at the Core and have set related alarms at the radio. It works perfectly)

    Initial setting step two: select the output voltage: 6.0V, 7.0V, 7.6V and unregulated (voltage input = output).

    How to do the settings and the switching process is described in the manual.

    Ich habe gerade eben in einem anderen Chat gelesen:

    Und die Antwort von Richard Deutsch:


    Das hängt davon ab wie der Regler aufgebaut ist. Wenn der Microcontroller nur mit Antriebsakku arbeitet gibt dieser beim Scannen der Sensoren keine Antwort und fehlt dann.


    D.h., Du müsstest dann im Core nach dem Anschließen des Antriebsakkus die Sensoren neu scannen