FrSky Taranis und Variometer openxvario bzw. openxsensor

Status
Nicht offen für weitere Antworten.
Die Idee mit dem Speedsensor finde ich aber auch sehr interessant und werde die wohl auch verwirklichen. Ist denn die elektronische Kompensation vom OXS genau so gut wie eine Kompensation per gut abgeglichener TEK-Düse?
Moin, als eher misstrauischer Typ habe ich lange (>100 Flüge) getestet, ob man der elektronischen Kompensation wirklich trauen kann. In meinem Stratos sind unkompensiertes Vario, TEK-Vario und der Speed-Sensor und damit das elektronisch kompensierte Vario (dTE) gleichzeitig aktiv, im Flug kann ich einfach umschalten.
OXS_test.jpg
Oft war es so, dass sich das dTE "seltsam" anhörte, dann schaltete ich auf TEK um, das sich aber genauso "seltsam" anhörte. Tatsächlich war die Luft "seltsam", meist dann, wenn Wind und Thermik zusammenkommen. In meinem Log oben sind alle drei Varios enthalten, und zwar in AccelX, AccelY und AccelZ - unkompensiert, TEK und dTE. Man sieht zwar im Log ab und zu einen kleinen Unterschied zwischen TEK und dTE, im Flug ist es aber unmöglich, zu sagen, welches aktiv ist. Für das Finden und Zentrieren ist der Unterschied völlig egal. Grundsätzlich muss man akzeptieren, dass ein kompensiertes, nicht überdämpftes Vario unruhiger ist, als ein nicht kompensiertes Vario. Man hört sofort, wenn sich der Airspeed ändert, während beim unkompensierten Vario erstmal der Flieger steigen oder sinken muss, dann höre ich erst den geänderten Luftdruck als Variosignal. Diese Massenträgheit habe ich beim Airspeed nicht, der wirkt sich sofort aus, entweder pneumatisch bei der TEK, oder über den Airspeedsensor elektronisch. Dies kann natürlich bedämpft werden, aber ich mag eher hören, was tatsächlich da oben los ist und lasse meinen Zentralrechner die Analyse machen.

Und nochmal zum Verständnis deines T-Stücks: du zweigst auf der einen Seite den Schlauch ab, der den statischen Druck von der Prandtl-Düse liefert (ich nehme an du hast an diesem Schlauch auch ein T-Stück) und auf der anderen Seite schließt du einen Schlauch an, der den Druck im Rumpf an anderer Stelle misst? So ganz komme ich noch nicht ganz dahinter...
Dies ist das verwendete Prandtl-Rohr von Hacker/Jeti (~ 20,--), es gibt auch eine halb so teure Sonde von einem anderen Hersteller, die aber nicht so hochwertig wirkt.
DUPLEX-Pitot-Rohr-2x1m-Silikonschlauch-80001415_b_0.JPG
Der rote Schlauch überträgt den Staudruck von der vorderen Öffnung, der Weiße den Umgebungsdruck, den die seitlichen Bohrungen aufnehmen. Beide werden an den Speedsensor angeschlossen und aus der Differenz wird der Speed errechnet. Für dem MS5611 nimmt man üblicherweise den Druch aus dem Rumpfinneren und hofft, dass bei allen Geschwindigkeiten dieser dem Umgebungsdruck entspricht, das heißt, dass sich im Rumpf weder Über- noch Unterdruck bilden. Beim Stratos stimmt das zufällig einigermaßen. Da aber der reale Umgebungsdruck sowieso über die Prandtl-Sonde zur Verfügung steht, kann man sicher gehen und diesen auch für den MS5611 verwenden. D.h. der weiße Schlauch geht zum MS5611 und dann weiter zum Speedsensor, das ist alles, ein weiteres T-Stück ist nicht nötig. Auf meinem Bild ist ein klarer Schlauch auf dem Speedsensor zu sehen, der ist aber nur drauf, um Verunreinigungen zu verhindern, solange er nicht angeschlossen ist, bitte ignorieren, das ist missverständlich.

Viel Erfolg beim Bauen und vor allem beim Fliegen und berichte unbedingt von Deinen Erfahrungen!
 
Zuletzt bearbeitet:
Ok, dann bleibt' erstmal beim kompensierten Vario über die TEK-Düse und eventuell später setze ich den Speedsensor bei meinem Hangsegler ein, weil dort die Geschwindigkeit auch mal interessant wird.

Tatsächlich habe ich die Erfahrung mit der seltsamen Luft auch schon gemacht, nur habe ich bisher gedacht, dass das zum Teil am Vario (bisher nur das Frsky Vario) oder an der selbstgebastelten Nick-Düse liegt, die sicherlich nicht perfekt kompensiert. Trotzdem geht es mir wie dir, dass ich lieber trotzdem höre, was draußen passiert und nicht erst, wenn sich der Druck im Rumpf ändert. Dadurch kann man einfach doch ein Tick besser zentrieren (jedenfalls geht es mir so).

Vielen Dank nochmal für die Erklärung des T-Stücks. Das heißt anstatt beide Schläuche am Speedsensor anzuschließen, schließt du den Schlauch mit dem statischen Druck am MS5611 an. Ich nehmen an die Geschwindigkeit wird dann vom OXS berechnet, weil der Speedsensor ja dann nur noch den Staudruck messen kann.
 
Zuletzt bearbeitet:
Vielen Dank nochmal für die Erklärung des T-Stücks. Das heißt anstatt beide Schläuche am Speedsensor anzuschließen, schließt du den Schlauch mit dem statischen Druck am MS5611 an. Ich nehmen an die Geschwindigkeit wird dann vom OXS berechnet, weil der Speedsensor ja dann nur noch den Staudruck messen kann.
Der statische Anschluss geht gleichzeitig an den MS5611 und an den Speedsensor, also bekommen beide den (hoffentlich) realen Umgebungsdruck. Zusätzlich kommt noch der Staudruck an den Speedsensor, derdie Differenz zwischen beiden zur Errechnung der Geschwindigkeit benötigt. Das ist aber nur nötig, wenn man nicht sicher ist, einen neutralen Druck im Rumpf zu haben.
Eventuell ist es möglich, nur ein Staudruckröhrchen zu verwenden, ein 2 mm Messingrohr in Flugrichtung, und den statischen Druck für beide Sensoren aus dem Rumpf zu holen, also ohne Anschluss. Das wäre dann die einfachste Ausführung mit lediglich einem Schlauchanschluss. Nächste Woche ist langes WE, dann klappt vielleicht der Umbau und Test, werde berichten.
 
Der Arduino ist OK, kannst Du noch den Programmertyp angeben?

Du brauchst was in der Art:

http://www.ebay.de/itm/FT232RL-FTDI.../331278145200?pt=Bauteile&hash=item4d21b756b0
Hallo Leute,

openXsensor fertig zum Programmieren, config Datei angepasst, es kann also los gehen... Aber nein, es gibt offensichtlich ein unüberwindbares Problem mit dem Programmer :mad:

Was bisher geschah: :D
Den oben im Link genannten Programmer geholt und an den PC angesteckt. Mein PC erkennt eine neue Hardware und sucht nach Treibern. Er findet die Treiber auch und installiert sie erfolgreich, so dass das Gerät als USB Seriell Converter erkannt wird und nutzbar ist. Funktioniert auch alles soweit.Nach dem Abstecken und erneuten Anschließen (gleicher USB-Port, gleiches Kabel) erkennt der PC komischerweise wieder eine neue Hardware nur diesmal findet er keinen Treiber und das Gerät ist nicht nutzbar. Manuelles Installieren der Treiber funktioniert auch nicht, der PC erkennt einfach keinen Treiber für den Programmer. Nachdem alles probiert wurde bis hin zum Bereinigen der Registry und alles nichts brachte, wurde der Programmer an einen anderen PC angeschlossen (der mit dem gesamten Vorgang nichts zu tun hatte und kurz nach der Formatierung noch im jungfräulichen Zustand ist) und auch da wird kein Treiber gefunden und auch kein manuelles Installieren ist möglich.
So, ich habe das Gerät dann für hardwaretechnisch defekt erklärt, weggeschmissen und mir ein neues geholt (kosten ja nicht so viel, ist halt nur die Wartezeit :mad:).

Und jetzt der Witz: Heute kam das Gerät an und ich habe das exakt selbe Problem, das heißt beim ersten mal geht der Programmer wieder, Windows findet und installiert die Treiber automatisch. Nachdem das Gerät ab- und wieder angesteckt wird, geht auch bei dem neuen Gerät nichts mehr :confused: :confused: :confused:

Hat zufällig jemand einen brauchbaren Vorschlag? Ich schließe mittlerweile ein "PC-Treiber-Problem" aus, weil der Programmer nach dem zweiten Anstecken auf keinen PC mehr brauchbar ist. als würde der PC beim ersten erfolgreichen Programmieren etwas auf dem Gerät schreiben, die ID verändern oder was weiß ich und danach ist das Ding einfach hinüber. Oder aber der Programmer hängt sich beim ersten Benutzen bzw Abziehen auf und startet dann nicht mehr neu, so dass der PC nichts mehr damit anfangen kann.

Gruß Martin
 
Ich hatte mal auf einem XP-Notebook ein ähnliches Problem, als ich dann den FTDI mit angestecktem Arduino eingesteckt habe, hats funktioniert.
Ansonsten kann ich noch anbieten, mir den defekten zuzuschicken, dann teste ich den bei mir nochmal.

Gruß Bernd
 
Naja, nochmal, ich glaube es handelt sich hier nicht um ein Treiber Problem. Ein Treiber ist eine Software, die auf einem PC läuft damit dieser mit dem gerät arbeiten kann. Bei mir scheint es aber so zu sein, dass bei der ersten Treiberinstallation, die ja erfolgreich durchlief, der PC etwas in den EEPROM des Programmers zu schreibt und vielleiucht etwas an der ID verändert mit der Folge, dass das Gerät nunmehr an keinem anderen PC mehr zu gebrauchen ist. ich hatte jetzt schon ca 4 PC probiert (wobei alle WIN 7 hatten) aber es ist immer das gleiche, das Gerät wird nicht erkannt.
Wenn es so wie beim ersten mal wäre, dass beim erste Anstecken an den jeweiligen PCs das Gerät erkannt wird und der Treiber installiert wird, bei den folgenden malen aber nicht mehr, dann würde ich auch an ein Treiberproblem glauben. Aber hier ist dieses Verhalten nur einmal beim erstmailigen Anstecken des Gerätes überhaupt zu beobachten unc danach war's das.
Ich habe schon alle möglichen Treiber versucht, auch ältere abgelaufene Version, habe auch mit dem Cleaner Tool von FTDI gearbeitet, aber nichts bringt was. Das Gerät ist wie defekt...
 

kalle123

Jugend forscht ....
Problem ist gelöst :D

Hatte den entscheidenden Tipp im Arduino Forum bekommen. Aber auch mit Kalles Hinweis wäre ich wohl schon einen Schritt weiter gekommen. Das Problem besteht nämlich darin, dass, warum auch immer, der FTDI Chip auf dem Programmer seine Geräte-ID vergisst (die ist dann nicht mehr 6001 sondern 0000). Da die Hersteller ID unverändert bleibt, erkennt zwar Windows dass ein entsprechendes Gerät angesteckt wird, aber es kann dem Gerät nicht mehr den richtigen Treiber zuweisen, auch wenn dieser fehlerfrei auf dem PC installiert ist.

Unter Windows hat man dann die Möglichkeit aus einer Liste von Gerätetreibern irgendeinen zuzuweisen. Das macht man normalerweise nicht, weil Windows immer den richtig wählt (entweder ganz automatisch oder man gibt den Pfad an, wo Windows suchen soll). In dem Fall weist man aber dem Gerät den richtigen Treiber manuell zu, der ja aufgrund der fehlerhaften ID aus Sicht von Windows falsch ist, aber sei's drum, es funktioniert wieder. Tatsächlich muss man das auch zweimal machen, um dem Programmer sowohl den USB Serial Converter Treiber als auch den USB Serial Port Treiber zuzuweisen. Danach klappt das alles.

Im Arduino Forum gab's dann noch den Hinweis, dass das unter Linux nicht funktioniert, weil Linux eben nicht so wie Windows über die falsche Geräte ID hinwegsehen kann. Die Lösung unter Linux ist dann ein Utility von FTDI, mit dem man den EEPROM des Programmer auslesen kann und wieder mit der richtigen Geräte ID beschreiben kann.

Vielen Dank für eure Hilfe!

Gruß Martin
 

kalle123

Jugend forscht ....
So, ich habe das Gerät dann für hardwaretechnisch defekt erklärt, weggeschmissen und mir ein neues geholt (kosten ja nicht so viel, ist halt nur die Wartezeit :mad:).
Schön, das es funktioniert, Martin.

Dann kram mal im Müll und hol dir den "defekten" da raus. :D

Die Adapter braucht man immer mal. Alternativ gehen auch Adapter mit CP2102, die sind nicht so "sophisticated" wie die FTDIs.

Gruß KH
 
Hallo super Projekt, funktioniert super, nur kann ich ja den Sensor nur als letzten anschließen, da dieser keinen 2 s port hat oder wie kann ich einen 2anschluss am Sensor bewerkstelligen ? Danke
 

kalle123

Jugend forscht ....
Problem ist gelöst :D

Hatte den entscheidenden Tipp im Arduino Forum bekommen. Aber auch mit Kalles Hinweis wäre ich wohl schon einen Schritt weiter gekommen. Das Problem besteht nämlich darin, dass, warum auch immer, der FTDI Chip auf dem Programmer seine Geräte-ID vergisst (die ist dann nicht mehr 6001 sondern 0000). Da die Hersteller ID unverändert bleibt, erkennt zwar Windows dass ein entsprechendes Gerät angesteckt wird, aber es kann dem Gerät nicht mehr den richtigen Treiber zuweisen, auch wenn dieser fehlerfrei auf dem PC installiert ist.
....
Ich will dieses Thema noch mal aufgreifen.

Anscheinend hat die Firma Future Technology Devices International, kurz FTDI ein kleines gimmick in die neusten Treiber eingebaut, um user von nachgemachten FTDI chip etwas zu verunsichern ;)

Quelle hier http://www.aardvark.co.nz/daily/2014/1023.shtml#continue

Vielleicht rührte Martins Problem daher ...

Gruß KH
 

Bussard

Erfahrener Benutzer
Ich will dieses Thema noch mal aufgreifen.

Anscheinend hat die Firma Future Technology Devices International, kurz FTDI ein kleines gimmick in die neusten Treiber eingebaut, um user von nachgemachten FTDI chip etwas zu verunsichern ;)
Das scheint tatsächlich die Lösung der allerorten zu hörenden Probleme zu sein:
http://www.heise.de/hardware-hacks/meldung/FTDI-Proaktive-Fake-Chip-Abwehr-2430780.html
http://www.mikrocontroller.net/topic/347724#new

Nun ja, wenn man es weiß, kann man ja auch damit umgehen, zunächst sucht man ja sonstwo.
Gruß
 
@kl_Haribo: bist du dir sicher. Funktionieren die Geräte unter Linux ganz ohne Treiber? In dem arduino Thread, wo ich die Lösung für mein Problem gefunden habe, gab es auch Leute, die unter Linux das gleiche Problem hatten.

Gruß Martin
 

kalle123

Jugend forscht ....
Hallo Martin.

Ich bin mir da nicht so sicher. Der FTDI support ist doch schon lange im Linux kernel mit drin.

Und probieren kann ich nicht, meine beiden Adapter * mit FTDI sind sauber, der Rest ist mit CP2102 ...

* Die haben aber auch mehr als 3 Euro gekostet :D

Aber anyway, so schön Linux als BS ist und das ist es bei mir schon über Jahre (SuSE, Red Hat, Halloween von Lehmanns Berlin, Kubuntu und seit ca. 3 Jahren PCLinuxOS) , ich komme ohne ein windoof im dual boot bzw. einem windoof in einer vbox auch nicht aus.

Gruß KH
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten