FrSky Taranis und Variometer openxvario bzw. openxsensor
- Themenstarter Tempo
- Beginndatum
- Status
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.
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.
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.
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!
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.
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.
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.
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:
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.
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.
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
Was bisher geschah:
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).
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
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
openXsensor fertig zum Programmieren, config Datei angepasst, es kann also los gehen... Aber nein, es gibt offensichtlich ein unüberwindbares Problem mit dem Programmer
Was bisher geschah:
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
).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
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
also unter windows habe ich für arduino-boards immer diesen treiber installiert: http://www.ftdichip.com/Drivers/VCP.htm
Aber inzwischen nutze ich fast nurnoch linux, da funktioniert das ganze ganz ohne treiber. Also falls alles nichts hilft, linux installieren, oder eine live-CD.
Aber inzwischen nutze ich fast nurnoch linux, da funktioniert das ganze ganz ohne treiber. Also falls alles nichts hilft, linux installieren, oder eine live-CD.
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...
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...
Problem ist gelöst
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
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
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 ).
).
Dann kram mal im Müll und hol dir den "defekten" da raus.
Die Adapter braucht man immer mal. Alternativ gehen auch Adapter mit CP2102, die sind nicht so "sophisticated" wie die FTDIs.
Gruß KH
Problem ist gelöst
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.
....
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.
....
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
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
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
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ß
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
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
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
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
