Leistungsermittlung von Modellseglern mit openXsensor OpenTX und Taranis

Status
Nicht offen für weitere Antworten.
Hier zwei aktuelle Messflüge in der Morgendämmerung mit einem Balsa- (XL3200) und einem Voll-CFK-Segler (Stratos). Die Leistungsparameter sind erstaunlich ähnlich (außer Vmax ;) ). Ist noch jemand am Messen zur Zeit? Erfahrungsaustauch gerne auch per Mail.

Gruß Bernd

Anhang anzeigen Stratos_E-2016-07-28_1.zip
Anhang anzeigen XL_3200-2016-07-22.zip

AvSi = mittleres Sinken
GlRt = Gleitzahl (x10)
Sst0 = Seconds since T0
 
Hallo Carbo

keine Sorge, da gibts schon noch welche, die mit oXs am werkeln sind. Mein Projekt ist ein Programm, dass je nach speed und accel eine
Anpassung des Profils und Höhenruders vornimmt. Testflieger ist ein Hacker Vagabond.

Entwicklungsstand : board Teensy 3.2, an den Empfänger über SBUS angeschlossen, Output PWM und/oder SBUS (da haben sich dank Futaba schon einige die Zähne abgewetzt). Das funktioniert im 24h-Betrieb schon recht zuverlässig.
Ein MMA8452 ist auch schon implementiert und kann PWM/SBUS-output mit seine Daten überlagern.

Ich finde es schade, dass sich mstrens auf die AVR-Prozessorlinie festgelegt hat. Die Dinger sind zwar billig, aber mit dem heutigen oXs
schon oderdentlich am beissen. Sich wegen ein paar popeligen Euros den Weg in die Zukunft zu verbauen - sorry.
Genug gelästert, oXs ist eine tolle Basis, um eigene Projekte aufzugleisen. Ein Danke an mstrens an dieser Stelle.

Nächsten Winter nehme ich die IMU 6050 oder was ähnliches auf die to-do-Liste. Ich konnte das Teil zwar schon auslesen, aber begreife den Code
noch nicht und ich möchte nun mal eine wenig fliegen mit dem was ich bisher programmiert habe. Das Teil ist doch schon recht komplex. Deshalb die Zwischenlösung mit dem MMA8452.

Ausserdem soll noch eine SD-Card implementiert werden, um Profilpolaren für die Berechnung abzuspeichern oder Daten zu loggen.

Und übrigens - für den teensy 3.2 steht schon ein Nachfolger in den Startlöchern - mit einem K65/66. Der hat dann nochmals einiges mehr
an power, um bessere Filter zu implementieren

Apropos Filter ist ja besonders das Vario ein Thema. Da treffen zwei Anforderungen aufeinander, die sich nicht besonders gut vertragen - starke Filterung und kurze Latenz. Ich habe mit einem Filter und dazugehöriger Statistik experimentiert, um die Reaktionszeit
zu verbessern. Idee - die Varianz der Daten steuert die Empfindlichkeit des Filters. Am PC mit Testroutinen funktioniert es ersteunlich gut.

Hast Du Kenntnis, wie mstrens die IMU zwecks Verbesserung der Reaktionszeit implementiert hat ? Nimmt er einfach die beschleunigung
ohne Berücksichtigung der Querlage ?

grüessli hw

PS die Braunschweiger Düse nachgebaut nach Deinen Angaben hat nach wie vor den Ehrenplatz auf meinem
Lieblingsmodell - danke für Deine Bauanleitung.
 
Zuletzt bearbeitet:

kalle123

Jugend forscht ....
@hw.

Warum fragst du mstrens nicht direkt?

M.W. sitzt Michel nicht auf seinem Wissen und ist gerne bereit, Informationen weiter zu geben.

Du findest ihn im openrcforums.

Gruß KH
 
Hallo Carbo
keine Sorge, da gibts schon noch welche, die mit oXs am werkeln sind.
Das stimmt, aber mir geht es hier eher um einen Meinungsaustausch zur Praxis der Leistungsermittlung. Es gibt weltweit nur eine Handvoll Leute, die tatsächlich messen können (und wollen).

Ich finde es schade, dass sich mstrens auf die AVR-Prozessorlinie festgelegt hat. Die Dinger sind zwar billig, aber mit dem heutigen oXs schon ordentlich am beissen. Sich wegen ein paar popeligen Euros den Weg in die Zukunft zu verbauen - sorry.
Das stimmt ebenfalls, aber er hat gute Gründe dafür. Zum Einen ist es ein großer Aufwand, die Routinen zu portieren, zum Anderen ist es tatsächlich auch ein finanzieller Aspekt, wenn du in jedem Modell einen oXs fliegst. Wie du im XL3200 Log sehen kannst, schafft der oXs Vario, Airspeed, 5Hz GPS, Akkuspannung, PPM, Varioempfindlichkeit locker ohne zu husten. Die Standardapplikation vieler User ist sogar nur Vario und 1-2 Spannungen.

Zum Thema IMU gibt es in openrc schon einige Infos Link. Mstrens hält sich zur Zeit etwas zurück, ich hoffe, es liegt nicht daran, dass unser Charmebolzen auch dort für schlechtes Karma sorgt ;)

Eher ist er aber aktuell mit seiner Jeti Integration ausgelastet.

Gruß Bernd
 
Leider war es heute morgen nicht ganz windstill, der eine oder andere Buckel im Log könnte darauf zurückzuführen sein.

Anhang anzeigen Stratos_E-2016-07-31.zip
Messflug.png

Wie sich immer stärker zeigt, ist die Ausgabe der Leistungsparameter zu wenig gemittelt, die Phugoide, Piloteneinfluss, lokale Einflüsse bewirken eine zu große Streuung bei der hohen Auflösung die der oXs liefert. Man kann sich zwar im Flug aus den Ansagen einen Mittelwert im Kopf "berechnen", aber um genaue Werte zu bekommen, muss zur Zeit noch der Log zu Hilfe genommen werden. Hier mal die drei Flugphasen Thermik, Strecke und Speed mit den errechneten Durchschnittswerten:

HC_2016_07_31_4.png
32:20 bis 35:30, 35 km/h, Sinken 37,2 cm/s, Gleitzahl 26,12

HC_2016_07_31_5.png
25:50 bis 26:50, 44 km/h, Sinken 49,3 cm/s, Gleitzahl 25,02

HC_2016_07_31_6.png
20:30 bis 22:00, 53 km/h, Sinken 98,4 cm/s, Gleitzahl 14,95


Es wird wohl zukünftig eher in die Richtung gehen, die Leistungsparameter im Sender mit einem LUA-Script auszuwerten. Diese Lösung ist flexibler, auch weil man nicht jedes Mal an den oXs muss, wenn die Berechnung geändert werden soll. Der Ablauf könnte z.B. so sein: Ist ein konstanter Flug erreicht, triggert der Pilot die Messung (Momenttaster) und das Script errechnet per Durchschnittsbildung die Parameter und sagt sie an, bis der Pilot die Messung wieder beendet. Das ist im Prinzip das Geiche, wie ich es "händisch" auch mache, mit dem Vorteil, dass die Daten schon im Flug zur Verfügung stehen und man sich so leichter und schneller an das Optimum herantasten kann.

Gruß Bernd
 

strgaltdel

Erfahrener Benutzer
Hallo

nach längerer Zeit bin ich ENDLICH dazu gekommen den ersten Speedsensor in Betrieb zu nehmen.
Da das ganze Meßsystem erst 2 Tage vor dem (Modellflug) Urlaub fertig wurde, konnte ich noch nicht alle Funktionen implementieren (Kompensation etc..), aber zumindesten die reine Airspeedmessung, das Vario & GPS in Betrieb nehmen.


Die "Besonderheit" dabei war das Selbstbau Prandtl-Rohr.
Aus Gründen der Transportabilität ("Aneck-Gefahr") wollte ich eine abnehmbare Variante einsetzen.
Als Probant musste ein Topmodell-Ventus herhalten.
Da die Schlauchlängen zwischen Sonde und Differenzdrucksensor mehr als 1Meter betrugen, und ich auch nicht ganz sicher war, ob das "System" wirklich dicht ist, war ich etwas skeptisch, ob das alles so überhaupt funktionierte.
Schliesslich war es mein erster Versuch.

Sonde.jpg
Einbau.jpg

Die Sonde habe ich beim "scale" Segler erst einmal vorbildgetreu in die Dämpfungsflosse integriert.
Für Zwecksegler mit schlanken Flossen bzw. V-Leitwerk steht eine gebogene Variante in den Startlöchern, die in etwa auf Höhe der Flächen bzw kurz dahinter aus dem Rumpf herausragen soll, siehe Bilder.
Funktionsweise des Stecksystems ist hoffentlich auch den Bildern zu entnehmen.

Prandtl2.jpg

Das Rohr hat 4,5mm Aussendurchmesser, auf dem Foto habe ich das schlankere Jeti Rohr zum Vergleich beigelegt.
statischer Druck wird aus 8 Bohrungen a 0,5mm entnommen,
Öffnungsdurchmesser für den dynamischer Druck beträgt 1,5 mm.

Der Statische Druck für Vario/Höhenmessung wird auf der Platine über einen "Bypass" entnommen.
Wie Bernd bereits mal beschrieben hat, "forme" ich mir einen Schrumpfschlauch auf einem Holzvierkant, allerdings durchbohre ich ihn um ein Ms-Rohr hindurchzustechen.
Das MS-Rohr hat im Inneren des Schlauchs eine kleine Öffnung ausgefräst & übergibt dadurch den static Druck an den Sensor.
Der Schrumpfschlauch wird dann mit dem MS-Röhrchen zusammen oben mit einem 0,3mm GFK Plättchen gedeckelt (Sekundenkleber) und auf das Gehäuse des Drucksensors fixiert (ebenfalls Sek.Kleber).
Danach dichte ich dieses "Schrumpfschlauch-Gehäuse" komplett mit Flüssig-Gummi (Plasti-Dip) ab.
Auf der einen Seite des Röhrchens kommt dann der Anschluß-Schlauch des static Ports, das andere Ende wird an den Diffdrucksensor angeschlossen..

Für die Druckübertragung habe ich mich auf Silikonschläuche mit möglichst kleinem Durchmesser geeinigt (ID 1mm).
Schliesslich soll lediglich die Druckänderung schnell übertragen werden, Volumen muss da nicht durch, soweit jedenfalls meine newbee-logik.
Ich war mir nicht sicher ob das wirklich so funtzen würde.
btw:
Viele Anbieter (meist aus dem Anglerzubehör) bieten Schläuche an, die innen noch Talkumreste besitzen.
Um den Drucksensor nicht zu pudern habe ich länger suchen müssen, um saubere Schläuche zu finden.

openxsens.jpg

Als Proof of Concept hatte ich mir überlegt, die GPS-Höhenmessung mit der barometrischen Messung zu vergleichen.
meine Annahme ist, dass, wenn die Barometrische Messung keine grossen Abweichungen zeigt, das System mit den langen Schläuchen die Druckänderung korrekt weiterleitet und das System trotz abnehmbarer Sonde dicht ist.
Hier nun die Gegenüberstellung der beiden Messungen:

openxlog.jpg

Dass ist ERHEBLICH besser als ich gehofft hatte,
Unter nomalen Umständen liegt die Abweichung unterhalb von einem Meter !!!

"Unnormale" Umstände sind z.B. Loops.
Das bekommt das GPS System gar nicht wirklich mit, vergleicht man dann aber Airspeed & Baro-Höhe zeigt sich, dass diese (baro-) Messung wohl tatsächlich die zuverlässigere ist !
Auf dem GPS System wurde die Höhenänderung während eines Loops gar nicht mitaufgezeichnet.
Erst einige Sekunden nach dem Loop waren die Messungen wieder deckungsgleich.
Evtl bekommt das GPS durch die plötzliche Fluglageänderung in den Rückenflug kein sauberes Empfangssignal.


Unter dem Strich gilt:

Hallo Bernd !
Danke für deine Unterstützung, und für die Präsentation dieses Messystems hier,
wird bestimmt noch eine Menge Spass bereiten !
Jetzt kann's in die nächste Runde gehen....
 
Hallo Udo,

da hast Du Dir sehr schöne Hardware gebaut! Dein Log kann eigentlich nur mit dem openXsensor GPS gemacht worden sein, das FrSky GPS hätte deutlich mehr Abweichung - richtig getippt?

Einen kleinen Dämpfer habe ich leider: das elektronisch Airspeed-kompensierte Vario hat im aktuellen Master Artefakte und ist schlecht fliegbar. Mstrens ist am Ball. Die 5.0 sollte aber hier sauber funktionieren. Die config.h sieht dort ein bißchen anders aus, wenn Du die 5.0 mal testen willst, mach ich dir gerne die config. Da noch Zeit in die Einarbeitung zu investieren macht wenig Sinn.

Aktuell hat mir Mstrens eine Version geschickt, bei der, wenn PPM -100 anliegt, eine manuelle Leistungmessung erfolgt. Mit einem sticky LS schalte ich über SH die Messung ein und wieder aus. Parallel funktioniert die "automatische" Messung aber weiter wie bisher. Der Ansatz fühlt sich sehr vielversprechend an.

So kann man auch die Steigrate des Antriebs, die Wirkung von Butterfly, u.s.w. messen und ansagen lassen, ohne die Geschwindigkeitstoleranz einhalten zu müssen. Eine Überprüfung auf konstanten Flug findet nur bei der "automatischen" Messung statt. Bisher war es so, dass die automatische Messung selbst durch eine Kurve, wenn sie sauber geflogen war, nicht unterbrochen wurde. Es kam aber dadurch natürlich zu Abweichungen bei den Leistungswerten. Mit der neuen, zusätzlichen Methode bestimmt der Pilot, wann und wie lange gemessen wird. Man kann auch mit Motor und/oder Bremse u.s.w. die Messung automatisch triggern - es bleibt spannend!

Gruß Bernd
 

strgaltdel

Erfahrener Benutzer
Hallo Bernd,

richrtig vermutet, GPS lief NATÜRLICH über den openXsenor (-;
War ein Ublox Neo-7m, ist zwar größer als das 7mini, aber scheint schneller seinen Fix zu bekommen & arbeitet auch sehr akkurat.
Wo Größe & Gewicht keine Rolle spielen werde ich den wohl bevorzugen.
In kleinen Zweckmodellen dann den mini.
Ein Neo 8 ist auch noch zum Testen hier.

Zur ganzen "Messerei":
Echtzeit Auswertung hat halt im Modellflug leider auch seine Grenzen.
Sicherlich kann man über scripting & Mittelung statistisch relevanter Messungen schon sehr viel machen, du merkst allerdings ja selbst wieviel Aufwand dahinter steckt.
Imho könnte uns da z.B. der Stabi (S6R) sehr viel weiterbringen um Messungen im "ruhigen Flug" zu erhalten.
Werde mich damit mal befassen.

Kennst du logview?
Ist für Auswertungen von Telemetrie-Messungen ein sehr sehr mächtiges tool, nur leider nicht mehr "gepflegt" und damit auch kein FrSky Log Import.
CSV/TXT Import war mal angekündigt aber nie realisiert.
Evtl könnte man ein FrSky Log in ein "SM-Unilog" Format konvertieren, das könnte logview dann lesen.
(Wenn ich mal viel Zeit habe)

Auch sehr interessante Idee:
Vermessung der Antriebsdaten direkt aus dem ESC.
Es gibt ein sehr schönes OpenSource ESC Projekt: VESC
http://vedder.se/2015/01/vesc-open-source-esc/
Der Regler hat Strom / Spannungs / Drehzahl Messung bereits integriert und könnte ggf die Werte über I2C ausgeben.
Waere eigentlich ideal um direkt & ohne Sensoren die Werte in den openXsensor einzuspeisen.
Evtl müsste man die beiden Entwickler mal zusammenbringen.
Ist aber eine ganz andere Baustelle


Gruß
Udo
 
Mittlerweile bin ich vom stabilisierten Messen weggekommen. Ein Vergleich wäre natürlich interessant, aber ich denke, nach meinen bisherigen Erfahrungen messe ich besser ohne Stabilisierung. So erhalte ich die realistisch zu erwartenden Leistungswerte. Ich hab gerade nochmal einen sundowner mit der neuen Version geflogen. Man sieht schön, wie sich nach Aktivierung der Messung die Messwerte stabilisieren und sich, sagt man asymptotisch?, dem Endwert nähern. Mal abwarten, bis sich die Euphorie gelegt hat, aber das könnte so funktionieren, wie ich es mir vorgestellt habe.

Für die Auswertungen reicht mir eigentlich Companion und Open Office calc, damit konnte ich bisher alles darstellen.

PPM-100.png

Gruß Bernd
 

strgaltdel

Erfahrener Benutzer
Hallo Bernd,

erklärst du mir bitte die genaue Bedeutung des logs ?

Meine Vermutung:

- PPM/ R2 ist der "Schalter" um eine Mittelwertbildung zu generieren.
- Sobald R2 < -90 wird gemessen / der Mittelwerte gebildet
- gemittelt wird Sinken über die Zeit (AvSi)

- was aber ist GlRt ????



Was ich demnächst vorhabe geht in eine ähnliche Richtung:

meine Annahme ist, dass
a) je mehr Mess-Samples vorliegen, umso belastbarer ist die Messung
b) durchschnittliches Sinken & durchschnittliche Geschwindigkeit stehen in direkter Abhängigkeit zueinander

daraus lässt sich eine statistische Arbeitsweise ableiten.


Zur Umsetzung:

- per Schalter soll in einer ruhigen Flugphase eine Aufzeichnung gestartet und angehalten werden können
- Die Messung soll innerhalb des Fluges per Schalter fortgesetzt werden können um mehr Samples zu erhalten
- gemessen werden soll adhoc-Sinken & adhoc-airspeed

- ein lua script hält zwei "arrays" bereit
- jedes array hat zwei "spalten"
- in einer Zeile eines arrays wird zu einer bestimmten Sinkgeschwindigkeit oder speed jeweils die Anzahl der zutreffenden Samples mitgeschrieben
(in einer "Vormessung" ermittel ich den zu erwartenden Bereich für sinken & speed und lege diesen im script modellabhängig fest

das array könnte z.B. für Sinken so aussehen:
10 Zeilen mit Sinkgeschwindigkeiten & dazugehöriger Anzahl entsprechender Messungen

Sinken n

-0,45 0220
-0,46 0481
-0,47 1425
-0,48 2678
-0,49 4218
-0,50 1955
-0,51 0853
-0,52 0215
-0,53 0121
-0,54 0045


heisst im obigen Fall auf gut deutsch:

- Werte unter -0,54 bzw Werte über -0,45 werden von vornherein ausgeblendet, ebenso die Datenpaare ausserhalb des "gültigen" Speedbereiches (also eine Fensterung von Fehlmessungen)
- speed Werte und dazugehörige Anzahl von samples werden in einem 2. Array abgelegt
- Die Messung kann beliebig ergänzt/erweitert werden (je mehr samples, desto belastbarer / zuverlässiger die Messung)
- zu den jeweils aufgenommen Werten kann in Echtzeit per script ein gewichteter Mittelwert gebildet werden

Aus dem Paar "Mittelwert-Sinken" & "Mittelwert-Speed" wird die Gleitzahl errrechnet
Da Gleitzahl, Sinken und speed in Abhängigkeiten stehen sollte das mit der Methode "passen"

Wie das in einer Tabellenkalkulation aussehen würde habe ich im screenshot beispielhaft einmal dargestellt.
Das ganze entspricht zweier arrays (sinken & speed)
pro array zwei Spalten (Wertebereich & Anzahl samples)
Die drei Werte (Mittelwert sinken, speed und calc. Gleitzahl) können daraus einfach berechnet werden.

messen.jpg


Das ganze soll dann aber in einem script erfolgen.
Diese Vorgehensweise ist momentan natürlich theoretisch, erst die praktische Umsetzung wird zeigen inwieweit sie auch wirklich reproduzierbare Ergebnisse liefert.
Bandbreite und "Auflösung" von Sinken und speed muss auch erst evaluiert werden.


Ich sehe die Vorteile jedenfalls darin:

- Die Messung kann in einem Flug beliebig erweitert / ergänzt werden und gewinnt dadurch an Zuverlässigkeit
- keine nachträgliche Auswertung von logs notwendig
- es reicht die adhoc Messung des Varios & des airspeed Sensors
- keine zusätzliche OpenXsensor/ Arduino Programmierung notwendig
- Ergebnis im Flug / nach dem Flug sofort auf dem Display ablesbar
- spätere Ergänzung des Arrays rel. simpel möglich, um z.B. per Kippschalter Messungen für verschiedene Flugzustände / Klappenstellungen in einem Flug zu ermitteln

Einziger Nachteil:
der Messbereich muss zuvor in etwa ermittelt und grob im script hinterlegt werden.
In einer späteren Version könnte man das auch noch automatisieren.

ob das ganze so funzt wie gedacht wird sich also noch erweisen.
Erst mal muss ich Zeit für die Umsetzung finden, aber der erste Schritt ist mit dem Messsystem ja jetzt getan.

Gruß
Udo
 

Bussard

Erfahrener Benutzer
Hallo Bernd,

erklärst du mir bitte die genaue Bedeutung des logs ?
Meine Vermutung:
- PPM/ R2 ist der "Schalter" um eine Mittelwertbildung zu generieren.
- Sobald R2 < -90 wird gemessen / der Mittelwerte gebildet
- gemittelt wird Sinken über die Zeit (AvSi)

- was aber ist GlRt ????
Carbonator schrieb:
AvSi = mittleres Sinken
GlRt = Gleitzahl (x10)
Sst0 = Seconds since T0


Interessantes Thema,

Gruß
 
Hallo Udo,

der oXs reagiert auf PPM-100 (+-5) und startet dann die Auswertung nach einer Zeit x, hier eine Sekunde. Dabei wird die Zeit, die Höhe und der Airspeed verrechnet. Alle 0,5 s wird die zurückgelegte Strecke und die Höhenänderung berechnet und daraus dann AvSi, also das durchschnittliche Sinken und GlRt für Glideratio, also die Gleitzahl (Skala x 10). Solange PPM-100 anliegt, wird weiter gerechnet, so dass sich der Wert immer mehr stabilisiert. Für das Sinken wird einfach die neue Höhe genommen, die Strecken werden addiert. Man sieht im Log, wie empfindlich die Gleitzahlberechnung am Anfang ist, und wie sie sich dann immer mehr beruhigt. Das Sinken ist unkritischer in der Berechnung. Der Wert ist schneller stabil.

Diese LUA-Script von "Fig Newton", bzw. die im Thread erwähnte Aktualisierung von "Fabflight" ist vielleicht eine Anregung für Dein Vorhaben. Hier wird mit GPS-Speed gerechnet, was aber nach meiner Erfahrung nicht zur Gleitzahlberechnung taugt. Ich habe angefangen, das Script auf Airspeed umzubauen und erstmal die Hälfte löschen können, weil es nicht mehr benötigt wird. Dort ist auch eine Routine enthalten, um ein LUA-Log mit den Ergebnissen auf die SD-Karte schreiben zu können.

Dies ist bei der oXs Variante nicht nötig, deswegen bin ich froh, dass Mstrens meinen Vorschlag aufgegriffen hat, eine manuelle Messung hinzuzufügen. So habe ich Alles in einem Log. oXs ist ja auch für andere Systeme geeignet, die meistens keine Möglichkeit des Scriptens bieten, Mstrens ist gerade am nächsten dran. Insofern ist die Integration in oXs sinnvoll, um so ein vollwertiges Messsystem zu erhalten.

Die Möglichkeit, die oXs Ergebnisse mit deinen Ergebnissen zu vergleichen, habe ich natürlich schon im Auge. Da müsste man mal prüfen, ob man einen Log nachträglich als Telemetriedaten einem LUA-Script unterjubeln kann.

Eine schöne Prüfung des Messsystem ist mir kürzlich zufällig gelungen. Bei einem senkrechten Sturzflug ist Airspeed gleich VSpeed, oXs macht das tatsächlich bis 200 km/h (mindestens) mit. Keine Ahnung, wann es meinen Stratos zerlegt, deswegen belasse ich es dabei.

Der Bussard war schneller ;)

Gruß Bernd
 
Eine schöne Prüfung des Messsystem ist mir kürzlich zufällig gelungen. Bei einem senkrechten Sturzflug ist Airspeed gleich VSpeed, oXs macht das tatsächlich bis 200 km/h (mindestens) mit.
Hier der Versuch, den Test möglichst senkrecht auszuführen, dann VSpd in km/h umgerechnet. Das Ergebnis spricht für sich.
VSpdASpd.png
 
Einen kleinen Dämpfer habe ich leider: das elektronisch Airspeed-kompensierte Vario hat im aktuellen Master Artefakte und ist schlecht fliegbar. Mstrens ist am Ball.
Thema geklärt: der aktuelle Master funktioniert mit airspeed kompensiertem Vario, wenn man die Standardempfindlichkeit für das Vario eingestellt hat. Ich fliege mittlerweile sensitivity 200 und mit diesen geänderten Filtereigenschaften des Vario stimmt die Berechnung dann nicht mehr.

Workaround: Erst die Variosensitivity auf Standard einstellen, dann auf das kompensierte Vario umschalten. Mit OpenTX ist das natürlich ein Klacks und geht nach dem Einrichten automatisch mit dem Umschalten der Varios.

Hier übrigens meine Texte für die Varios, vielleicht kanns noch jemand brauchen:

Anhang anzeigen comp_not.zip
 
D

Deleted member 51580

Gast
Hallo,


Habe mir die teile für den OpenX Sensor besorgt und möchte damit ein Vario und GPS Modul am Sport betreiben.
Jetzt habe ich zum testen das ganze mit eine Arduion Leonardo auf einem Breadboard zusammen gesteckt um erst mal zu testen bevor es dann auf einen Nano oder Mini um zieht.
Allerdings habe ich ein Problem mit der Ino Datei auf den Leonardo zu bekommen, beim Sketch kompilieren bleibt es mit dieser Fehlermeldung stehen.
Ganz ehrlich gesagt habe ich keinen schimmer was da nicht passt, das ist auch noch mein erst Kontakt mit den Arduinos.

Das ist die Ino die ich versuche auf den Leonardo zu bekommen.
ino.JPG

und das der Fehler

Leonardo.JPG

Kann mir da mal jemand weiter helfen bin etwas ratlos und gleich zu anfang des Projektes hängen geblieben.
 
Kann mir da mal jemand weiter helfen bin etwas ratlos und gleich zu anfang des Projektes hängen geblieben.
Hier sind Einige unterwegs (wie ich auch) die gerne helfen, aber mach bitte einen neuen Thread auf. In Richtung openXsensor - Erste Schritte oder so ähnlich. Hier in der Leistungsermittlung ist das nicht sinnvoll.
 
Hallo,

ich habe gerade meinen ersten openXsensor aufgebaut (Arduino Pro Mini 5V mit ublox GPS NEO-M8N).
Soweit ich das sehe (ich kenne mich mit der Telemetrie bisher noch nicht so gut aus) wird er in der Taranis aber nicht gefunden. Eine Sensorsuche habe ich gemacht.
Jetzt weiß ich nicht so genau, wie ich das am Besten debugge....
Was mich beim Aufbau schon stutzig gemacht hat, ist dass der Arduino Pro Mini über den Raw Eingang mit 5V (VCC des Empfängers) versorgt wird. Da bleiben dann noch 4,6V beim Arduino al VCC. Ist das so richtig?

Wie gehe ich am Besten vor?
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten