FrSky Taranis und Variometer openxvario bzw. openxsensor
- Themenstarter Tempo
- Beginndatum
- Status
Hi,
Du hast recht, ich stolpere auch immer über die verschiedenen Begriffe. Heute abend kann ich das Wesentliche hier mal in deutsch formulieren. Vorab: die "Sensitivity" funktioniert schon, hat aber weniger Auswirkungen als beschrieben. Bei geringer Sensitivity verlängert sich die Reaktionszeit auf Steigen/Sinken und das Variosignal wird ruhiger, also höhere Dämpfung. In der OXSconfig ist die Rede von mehreren Sekunden Reaktionszeit bei einem Wert von 20, das ist Quatsch, die ist immer kleiner als 1 Sekunde. Ich hab etliche Messreihen mit einer Druckkammer gemacht, wo man das schön sehen kann. Laut Beschreibung scheint eine Sensitivity von 150 unfliegbar zu sein, wegen zu vielen Falschinformationen, aber auch das ist so nicht richtig. Mit 50 liegt man in der Regel aber ganz gut, im Allgemeinen gilt: kleiner Flieger --> hohe Sensitivity, träges Schiff --> kleine Sensitivity. Irgendwann werde ich die Messungen mal auswerten und einstellen, damit man sich das Ganze besser vorstellen kann.
Um zu sehen, ob die PPM-Sensitivity Geschichte funktioniert, kann man sich im Feld "Fuel" die aktuelle Sensitivity von OXS zurücksenden lassen.
Gruß Bernd
Du hast recht, ich stolpere auch immer über die verschiedenen Begriffe. Heute abend kann ich das Wesentliche hier mal in deutsch formulieren. Vorab: die "Sensitivity" funktioniert schon, hat aber weniger Auswirkungen als beschrieben. Bei geringer Sensitivity verlängert sich die Reaktionszeit auf Steigen/Sinken und das Variosignal wird ruhiger, also höhere Dämpfung. In der OXSconfig ist die Rede von mehreren Sekunden Reaktionszeit bei einem Wert von 20, das ist Quatsch, die ist immer kleiner als 1 Sekunde. Ich hab etliche Messreihen mit einer Druckkammer gemacht, wo man das schön sehen kann. Laut Beschreibung scheint eine Sensitivity von 150 unfliegbar zu sein, wegen zu vielen Falschinformationen, aber auch das ist so nicht richtig. Mit 50 liegt man in der Regel aber ganz gut, im Allgemeinen gilt: kleiner Flieger --> hohe Sensitivity, träges Schiff --> kleine Sensitivity. Irgendwann werde ich die Messungen mal auswerten und einstellen, damit man sich das Ganze besser vorstellen kann.
Um zu sehen, ob die PPM-Sensitivity Geschichte funktioniert, kann man sich im Feld "Fuel" die aktuelle Sensitivity von OXS zurücksenden lassen.
Gruß Bernd
Sensitivity fest im Arduino eingestellt, automatische Anpassung durch oXs
Im Gegensatz zu den meisten "Kauf"-Varios muss ich bei oXs nicht die Vorgaben des Herstellers akzeptieren, oXs lässt sich beim Varioverhalten beeinflussen, ich kann einige Parameter auf meine Bedürfnisse anpassen. Hier versuche ich, diese Parameter zu beschreiben. Erst mal die Sensitivity = Empfindlichkeit.
Jedes Vario muss unglaublich geringe Druckschwankungen schnell erfassen und übermitteln, das ist immer ein Kompromiss zwischen Rauschen und Reaktionszeit. Mit Rauschen sind gemeldete Druckschwankungen gemeint, die nicht real existieren, sondern durch unerwünschte Effekte im Sensor oder bei der Auswertung entstehen. Wenn ich lange genug einen Durchschnitt des Druckes bilde, kann ich das Rauschen minimieren, merke aber erst viel später, wenn sich was tut (ich bin schon durch die Thermik durchgeflogen, wenn das Vario Steigen anzeigt).
Um diesen Kompromiss zu optimieren, auf das Flugzeug und meine Gewohnheiten, kann ich einige Parameter ändern. Die Nummerierung bezieht sich auf die oXs_config_description.h, hier Version 3.0.
4.2 Sensitivity vordefiniert im Arduino-Sketch (im Gegensatz zur Sensitivity die ich per PPM ändern kann):
SENSITIVITY_MIN: Das ist der Standard-Parameter, der die meiste Zeit angewendet wird
SENSITIVITY_MAX: Dieser Parameter wird bei sehr starken Änderungen benutzt
Wann wird SENSITIVITY_MIN und _MAX verwendet? Das legen die folgenden Parameter fest:
SENSITIVITY_MIN_AT: Bis zu diesem Steigen/Sinken in cm/s wird SENSITIVITY_MIN verwendet, üblich 100, also 1m/s
SENSITIVITY_MAX_AT: Ab diesem Steigen/Sinken in cm/s wird SENSITIVITY_MAX verwendet, üblich 1000, also 10m/s!!
Liegt das Steigen/Sinken zwischen diesen beiden Werten, nimmt oXs einen entsprechenden Sensitivity Wert zwischen SENSITIVITY_MIN und SENSITIVITY_MAX.
Wörtlich heißt es: Diese Parameter erlauben oXs eine schnellere Reaktionszeit bei schnellen Vertikalgeschwindigkeitsänderungen, obwohl das Vario in ruhigen Bedingungen nicht "rauscht" = still bleibt.
Es sollte klar sein, dass man fast immer mit SENSITIVITY_MIN unterwegs ist und nur in extremen Situationen die Sensitivity automatisch erhöht wird, um Änderungen noch schneller zu realisieren. Wenn man allerdings SENSITIVITY_MIN und _MAX auf den gleichen Wert setzt, erfolgt keine automatische Anpassung der Sensitivity mehr.
Unser Wert, mit dem wir spielen sollten, ist demnach SENSITIVITY_MIN. Erprobte Werte für SENSITIVITY_MIN gehen von 20-150, Standardwert ist 50.
Bei SENSITIVITY_MAX habe ich noch nie Änderungen vorgenommen, die blieb immer bei 300.
Im Gegensatz zu den meisten "Kauf"-Varios muss ich bei oXs nicht die Vorgaben des Herstellers akzeptieren, oXs lässt sich beim Varioverhalten beeinflussen, ich kann einige Parameter auf meine Bedürfnisse anpassen. Hier versuche ich, diese Parameter zu beschreiben. Erst mal die Sensitivity = Empfindlichkeit.
Jedes Vario muss unglaublich geringe Druckschwankungen schnell erfassen und übermitteln, das ist immer ein Kompromiss zwischen Rauschen und Reaktionszeit. Mit Rauschen sind gemeldete Druckschwankungen gemeint, die nicht real existieren, sondern durch unerwünschte Effekte im Sensor oder bei der Auswertung entstehen. Wenn ich lange genug einen Durchschnitt des Druckes bilde, kann ich das Rauschen minimieren, merke aber erst viel später, wenn sich was tut (ich bin schon durch die Thermik durchgeflogen, wenn das Vario Steigen anzeigt).
Um diesen Kompromiss zu optimieren, auf das Flugzeug und meine Gewohnheiten, kann ich einige Parameter ändern. Die Nummerierung bezieht sich auf die oXs_config_description.h, hier Version 3.0.
4.2 Sensitivity vordefiniert im Arduino-Sketch (im Gegensatz zur Sensitivity die ich per PPM ändern kann):
SENSITIVITY_MIN: Das ist der Standard-Parameter, der die meiste Zeit angewendet wird
SENSITIVITY_MAX: Dieser Parameter wird bei sehr starken Änderungen benutzt
Wann wird SENSITIVITY_MIN und _MAX verwendet? Das legen die folgenden Parameter fest:
SENSITIVITY_MIN_AT: Bis zu diesem Steigen/Sinken in cm/s wird SENSITIVITY_MIN verwendet, üblich 100, also 1m/s
SENSITIVITY_MAX_AT: Ab diesem Steigen/Sinken in cm/s wird SENSITIVITY_MAX verwendet, üblich 1000, also 10m/s!!
Liegt das Steigen/Sinken zwischen diesen beiden Werten, nimmt oXs einen entsprechenden Sensitivity Wert zwischen SENSITIVITY_MIN und SENSITIVITY_MAX.
Wörtlich heißt es: Diese Parameter erlauben oXs eine schnellere Reaktionszeit bei schnellen Vertikalgeschwindigkeitsänderungen, obwohl das Vario in ruhigen Bedingungen nicht "rauscht" = still bleibt.
Es sollte klar sein, dass man fast immer mit SENSITIVITY_MIN unterwegs ist und nur in extremen Situationen die Sensitivity automatisch erhöht wird, um Änderungen noch schneller zu realisieren. Wenn man allerdings SENSITIVITY_MIN und _MAX auf den gleichen Wert setzt, erfolgt keine automatische Anpassung der Sensitivity mehr.
Unser Wert, mit dem wir spielen sollten, ist demnach SENSITIVITY_MIN. Erprobte Werte für SENSITIVITY_MIN gehen von 20-150, Standardwert ist 50.
Bei SENSITIVITY_MAX habe ich noch nie Änderungen vorgenommen, die blieb immer bei 300.
Sensitivity im Flug ändern über einen Kanalimpuls
Erstmal müssen wir PPM definieren:
Wir verbinden den Impuls eines Kanals des Empfängers mit Pin 2 des Arduino (3 geht auch). und sagen dem Arduino dies:
3 - PPM settings
#define PIN_PPM 2 (oder 3)
Wenn wir auf dem Sender auf den Kanal-Monitor schauen, sehen wir, dass die Kanalwerte von -100 über 0 bis + 100 gehen. Dies wird durch eine entsprechende Impulsdauer übermittelt. Der Arduino muss jetzt wissen, welche Impulsdauer in Mikrosekunden -100 und welche +100 entspricht. Laut Definition ist dies 1500 (= Mitte = 0) -512, also 988 und 1500 + 512 = 2012. Allerdings weicht jeder Sender, Empfänger und der Arduino minimal vom Standard ab. Wer es genau wissen will, kann sich von oXs den Wert zurücksenden lassen und die Werte auf seine Geräte anpassen. Das vergessen wir aber erstmal und verwenden die Vorgaben aus oXs oder die obenstehenden, theoretisch exakten Werte, beides wird funktionieren, da die Verstellung der Sensitivity mit 5% Toleranz erfolgt, wie wir gleich sehen. Hier sagen wir dem Arduino die beiden Werte:
#define PPM_MIN_100 980
#define PPM_PLUS_100 1990
Arduino hate jetzt einen Parameter, nämlich PPM, den wir von -100 bis +100 über den Sender ändern können.
4.3 - Sensitivity einstellen über den Sender:
Hier kommen noch ein paar weitere Sensitivity Parameter, die erstmal verwirrend sind:
#define SENSITIVITY_MIN_AT_PPM 10 // Die Sensitivity wird nur dann verändert, wenn der PPM-Wert größer als 10 (+-5)
#define SENSITIVITY_MAX_AT_PPM 40 // und kleiner als 40 (+-5) ist
Diese beiden Zeilen bedeuten: senden wir einen Kanalwert zwischen 5 und 45, ändert oXs seine Sensitivity, und zwar die SENSITIVITY_MIN. Senden wir irgendeinen anderen Wert, passiert der Sensitivity nix. Jetzt definieren wir die beiden Werte für die Sensitivity bei PPM = 10 und bei PPM = 40 ((+-5) aber das ignorieren wir ab jetzt). Hierzu geben wir die gewünschten Werte in folgende Zeilen ein:
#define SENSITIVITY_PPM_MIN 20
#define SENSITIVITY_PPM_MAX 150
Wir ahnen: senden wir einen Kanalwert von 10, dann haben wir jetzt eine SENSITIVITY_MIN von 20, senden wir einen Kanalwert von 40, haben wir eine SENSITIVITY_MIN von 150.
Das schöne ist, dass wir oXs anweisen können, uns die aktuelle Sensitivity im Feld "Fuel" zu übermitteln, so können wir kontrollieren, ob unsere Änderung auch tatsächlich im oXs ankommt. Wir ergänzen folgende Zeile (fett) bei den zu sendenden Daten:
9.1
#define SETUP_FRSKY_DATA_TO_SEND \
DEFAULTFIELD , ALTIMETER , 1 , 1 , 0 ,\
VSpd , PPM_VSPEED , 1 , 1 ,0 , \
Fuel , SENSITIVITY , 1, 1, 0
Erstmal müssen wir PPM definieren:
Wir verbinden den Impuls eines Kanals des Empfängers mit Pin 2 des Arduino (3 geht auch). und sagen dem Arduino dies:
3 - PPM settings
#define PIN_PPM 2 (oder 3)
Wenn wir auf dem Sender auf den Kanal-Monitor schauen, sehen wir, dass die Kanalwerte von -100 über 0 bis + 100 gehen. Dies wird durch eine entsprechende Impulsdauer übermittelt. Der Arduino muss jetzt wissen, welche Impulsdauer in Mikrosekunden -100 und welche +100 entspricht. Laut Definition ist dies 1500 (= Mitte = 0) -512, also 988 und 1500 + 512 = 2012. Allerdings weicht jeder Sender, Empfänger und der Arduino minimal vom Standard ab. Wer es genau wissen will, kann sich von oXs den Wert zurücksenden lassen und die Werte auf seine Geräte anpassen. Das vergessen wir aber erstmal und verwenden die Vorgaben aus oXs oder die obenstehenden, theoretisch exakten Werte, beides wird funktionieren, da die Verstellung der Sensitivity mit 5% Toleranz erfolgt, wie wir gleich sehen. Hier sagen wir dem Arduino die beiden Werte:
#define PPM_MIN_100 980
#define PPM_PLUS_100 1990
Arduino hate jetzt einen Parameter, nämlich PPM, den wir von -100 bis +100 über den Sender ändern können.
4.3 - Sensitivity einstellen über den Sender:
Hier kommen noch ein paar weitere Sensitivity Parameter, die erstmal verwirrend sind:
#define SENSITIVITY_MIN_AT_PPM 10 // Die Sensitivity wird nur dann verändert, wenn der PPM-Wert größer als 10 (+-5)
#define SENSITIVITY_MAX_AT_PPM 40 // und kleiner als 40 (+-5) ist
Diese beiden Zeilen bedeuten: senden wir einen Kanalwert zwischen 5 und 45, ändert oXs seine Sensitivity, und zwar die SENSITIVITY_MIN. Senden wir irgendeinen anderen Wert, passiert der Sensitivity nix. Jetzt definieren wir die beiden Werte für die Sensitivity bei PPM = 10 und bei PPM = 40 ((+-5) aber das ignorieren wir ab jetzt). Hierzu geben wir die gewünschten Werte in folgende Zeilen ein:
#define SENSITIVITY_PPM_MIN 20
#define SENSITIVITY_PPM_MAX 150
Wir ahnen: senden wir einen Kanalwert von 10, dann haben wir jetzt eine SENSITIVITY_MIN von 20, senden wir einen Kanalwert von 40, haben wir eine SENSITIVITY_MIN von 150.
Das schöne ist, dass wir oXs anweisen können, uns die aktuelle Sensitivity im Feld "Fuel" zu übermitteln, so können wir kontrollieren, ob unsere Änderung auch tatsächlich im oXs ankommt. Wir ergänzen folgende Zeile (fett) bei den zu sendenden Daten:
9.1
#define SETUP_FRSKY_DATA_TO_SEND \
DEFAULTFIELD , ALTIMETER , 1 , 1 , 0 ,\
VSpd , PPM_VSPEED , 1 , 1 ,0 , \
Fuel , SENSITIVITY , 1, 1, 0
Umschalten zwischen 2 Varios über PPM
Haben wir PPM am Laufen, können wir eine weitere Funktion nutzen: Wir können zwischen mehreren Versionen der Variofunktion umschalten. Wir definieren die beiden "Varios":
4.5 - Vertical speeds calculations
#define VARIO_PRIMARY 0
hier können wir folgende Werte eingeben:
0 = der erste MS5611
1 = der zweite MS5611 (z.B. mit einer speziellen Düse zur Kompensation)
2 = der erste MS5611 aber mit einer Kompensation über einen Speedsensor
3 = ein Mittelwert aus dem ersten und zweiten MS5611 zur Verringerung des Rauschens (experimentell)
#define VARIO_SECONDARY 1
Werte wie oben.
Jetzt sagen wir dem Arduino, wann er schalten soll:
#define SWITCH_VARIO_MIN_AT_PPM 10
#define SWITCH_VARIO_MAX_AT_PPM 90
bedeutet: Liegt PPM zwischen 10 und 90 ist das VARIO_PRIMARY aktiv
liegt PPM zwischen - 10 und - 90 ist das VARIO_SECONDARY aktiv. Bei beiden Varios kann ich die Sensivity wie gewohnt ändern, logischerweise ist immer nur eines aktiv, mit dem PPM Vorzeichen wird umgeschaltet.
Beispiel: Mit einem kompensierten Vario blende ich die "Knüppelthermik" aus, will ich jetzt aber wissen, ob ich sauber kreise, oder ob mein Segler "Wellenflug" macht, nützt mir das kompensierte Vario nix, dann schalte ich um auf das nichtkompensierte (Standard-) Vario.
Jetzt erklärt sich auch die Zeile aus dem vorigen Beispiel:
VSpd , PPM_VSPEED , 1 , 1 ,0 , \
Hier wird von oXs das per PPM ausgewählte VSPEED Datum gesendet.
Wer mitgelesen hat, fragt sich jetzt, was zwischen PPM 40 und 90 passiert. Hier wird der Kompensationsgrad des per Speedsensor kompensierten Vario geregelt. Hier habe ich sogar die Möglichkeit die Kompensation eines Varios per Speedsensor nachzuregeln, was meines Wissens noch nie vorher realisiert wurde.
5 - Airspeed settings ---------
#define AIRSPEED MS4525
#define AIRSPEED_RESET_AT_PPM 100
#define COMPENSATION_MIN_AT_PPM 60
#define COMPENSATION_MAX_AT_PPM 90
#define COMPENSATION_PPM_MIN 80
#define COMPENSATION_PPM_MAX 140
zwischen PPM 60 und 90 wird die Kompensation zwischen 80% und 140% geregelt. Außerdem sehen wir in Zeile 2 oben, dass beim Senden vom PPM 100 der Airspeedsensor resettet wird. Das wird benötigt, falls der Airspeedsensor am Boden ohne Wind trotzdem eine Geschwindigkeit anzeigt. In der Praxis ist dies aber selten erforderlich.
Das waren alle Funktionen, die im Variobereich per PPM geregelt werden können.
Gruß Bernd
Haben wir PPM am Laufen, können wir eine weitere Funktion nutzen: Wir können zwischen mehreren Versionen der Variofunktion umschalten. Wir definieren die beiden "Varios":
4.5 - Vertical speeds calculations
#define VARIO_PRIMARY 0
hier können wir folgende Werte eingeben:
0 = der erste MS5611
1 = der zweite MS5611 (z.B. mit einer speziellen Düse zur Kompensation)
2 = der erste MS5611 aber mit einer Kompensation über einen Speedsensor
3 = ein Mittelwert aus dem ersten und zweiten MS5611 zur Verringerung des Rauschens (experimentell)
#define VARIO_SECONDARY 1
Werte wie oben.
Jetzt sagen wir dem Arduino, wann er schalten soll:
#define SWITCH_VARIO_MIN_AT_PPM 10
#define SWITCH_VARIO_MAX_AT_PPM 90
bedeutet: Liegt PPM zwischen 10 und 90 ist das VARIO_PRIMARY aktiv
liegt PPM zwischen - 10 und - 90 ist das VARIO_SECONDARY aktiv. Bei beiden Varios kann ich die Sensivity wie gewohnt ändern, logischerweise ist immer nur eines aktiv, mit dem PPM Vorzeichen wird umgeschaltet.
Beispiel: Mit einem kompensierten Vario blende ich die "Knüppelthermik" aus, will ich jetzt aber wissen, ob ich sauber kreise, oder ob mein Segler "Wellenflug" macht, nützt mir das kompensierte Vario nix, dann schalte ich um auf das nichtkompensierte (Standard-) Vario.
Jetzt erklärt sich auch die Zeile aus dem vorigen Beispiel:
VSpd , PPM_VSPEED , 1 , 1 ,0 , \
Hier wird von oXs das per PPM ausgewählte VSPEED Datum gesendet.
Wer mitgelesen hat, fragt sich jetzt, was zwischen PPM 40 und 90 passiert. Hier wird der Kompensationsgrad des per Speedsensor kompensierten Vario geregelt. Hier habe ich sogar die Möglichkeit die Kompensation eines Varios per Speedsensor nachzuregeln, was meines Wissens noch nie vorher realisiert wurde.
5 - Airspeed settings ---------
#define AIRSPEED MS4525
#define AIRSPEED_RESET_AT_PPM 100
#define COMPENSATION_MIN_AT_PPM 60
#define COMPENSATION_MAX_AT_PPM 90
#define COMPENSATION_PPM_MIN 80
#define COMPENSATION_PPM_MAX 140
zwischen PPM 60 und 90 wird die Kompensation zwischen 80% und 140% geregelt. Außerdem sehen wir in Zeile 2 oben, dass beim Senden vom PPM 100 der Airspeedsensor resettet wird. Das wird benötigt, falls der Airspeedsensor am Boden ohne Wind trotzdem eine Geschwindigkeit anzeigt. In der Praxis ist dies aber selten erforderlich.
Das waren alle Funktionen, die im Variobereich per PPM geregelt werden können.
Gruß Bernd
Hallo,
habe die letzten Tage hier etwas mitgelesen und bin begeistert. Verwende bis jetzt etliche ( 7 oder 8 ) FrSky Varios und eins von SM mit dem GPS.
Die Teile habe ich bereits für das Selbstbauvario bestellt. Werde es mir mal aufbauen. Die Varioempfindlichkeit vom Sender aus einstellbar zu machen ist super - bei schwacher, ruhiger Thermik längere Rundung und langsamere Reaktion, aber höhere Auflösung und weniger Rauschen.
Genau das habe ich FrSky bei der Entwicklung der neuen Fw vorgeschlagen, aber leider haben sie das letztes Jahr nicht berücksichtigt - mit der Begründung, dass das mit SPort nicht möglich sei ???
Wo kann ich denn den grundsätzlichen Aufbau und Bedienung der SW zur Einstellung der Parameter und weiterer Möglichkeiten ( Spannungsmessung )nachlesen? Des weiteren vermute ich, das ich es auch als Speedsensor mit passendem Rohr nutzen kann?
mfG
Norbert
habe die letzten Tage hier etwas mitgelesen und bin begeistert. Verwende bis jetzt etliche ( 7 oder 8 ) FrSky Varios und eins von SM mit dem GPS.
Die Teile habe ich bereits für das Selbstbauvario bestellt. Werde es mir mal aufbauen. Die Varioempfindlichkeit vom Sender aus einstellbar zu machen ist super - bei schwacher, ruhiger Thermik längere Rundung und langsamere Reaktion, aber höhere Auflösung und weniger Rauschen.
Genau das habe ich FrSky bei der Entwicklung der neuen Fw vorgeschlagen, aber leider haben sie das letztes Jahr nicht berücksichtigt - mit der Begründung, dass das mit SPort nicht möglich sei ???
Wo kann ich denn den grundsätzlichen Aufbau und Bedienung der SW zur Einstellung der Parameter und weiterer Möglichkeiten ( Spannungsmessung )nachlesen? Des weiteren vermute ich, das ich es auch als Speedsensor mit passendem Rohr nutzen kann?
mfG
Norbert
Hallo Norbert.
Projektseite ist die hier
https://code.google.com/p/openxsensor/
Dann diverse threads auch hier bei fpv-community
Gruß KH
Projektseite ist die hier
https://code.google.com/p/openxsensor/
Dann diverse threads auch hier bei fpv-community
Gruß KH
Hallo,
ich hoffe mal dies ist der richtige Thread für mein oxs-Problemchen...
Mein oxs besteht aus einem Arduino Mini Pro (China Clone) und dem GY63-Modul, angeschlossen an einem Frsky X8R-Sport. Wenn ich den Empfänger einschalte, werden keine Daten (z.B. Höhe) an den Sender übertragen. Dies funktioniert erst, wenn der Reset-Button am Arduino gedrückt wird oder das Kabel vom am S-Port kurz ausgesteckt und wieder eingesteckt wird.
Ist dieses Verhalten (Reset muss gedrückt werden) in oxs so „normal“ oder läuft da bei mir etwas schief?
ich hoffe mal dies ist der richtige Thread für mein oxs-Problemchen...
Mein oxs besteht aus einem Arduino Mini Pro (China Clone) und dem GY63-Modul, angeschlossen an einem Frsky X8R-Sport. Wenn ich den Empfänger einschalte, werden keine Daten (z.B. Höhe) an den Sender übertragen. Dies funktioniert erst, wenn der Reset-Button am Arduino gedrückt wird oder das Kabel vom am S-Port kurz ausgesteckt und wieder eingesteckt wird.
Ist dieses Verhalten (Reset muss gedrückt werden) in oxs so „normal“ oder läuft da bei mir etwas schief?
Hallo,
der oXs muss ohne Reset funktionieren, welche Version verwendest du? Neuere Versionen erkennen, ob sie am SPort oder am seriellen Port der älteren Empfänger hängen. Unter Umständen läuft da was schief. Häng doch mal deine oxsconfig an.
Außerdem kannst du dir mal die debug-Meldungen anzeigen lassen, hier ist beschrieben, wie das geht: http://fpv-community.de/showthread....zw-openxsensor&p=766132&viewfull=1#post766132
Hier kann man sehen, dass das SPort-Protokoll beim Initialisieren gewählt wird, vielleicht bleibt dein oXs an dieser Stelle hängen.
Gruß Bernd
der oXs muss ohne Reset funktionieren, welche Version verwendest du? Neuere Versionen erkennen, ob sie am SPort oder am seriellen Port der älteren Empfänger hängen. Unter Umständen läuft da was schief. Häng doch mal deine oxsconfig an.
Außerdem kannst du dir mal die debug-Meldungen anzeigen lassen, hier ist beschrieben, wie das geht: http://fpv-community.de/showthread....zw-openxsensor&p=766132&viewfull=1#post766132
Hier kann man sehen, dass das SPort-Protokoll beim Initialisieren gewählt wird, vielleicht bleibt dein oXs an dieser Stelle hängen.
Gruß Bernd
Zuletzt bearbeitet:
Kann das wie von Nyctalus beschriebene Verhalten erst mal bestätigen. Hab gestern noch ein simples Vario zusammen gesetzt und dabei diese Verhalten (Reset, sonst tut sich nix) gefunden. Bin noch dabei, verschiedene Versuche zur Ursachenfindung zu machen und wollte erst dann posten. Nur wie ich das hier lese ....
Gruß KH
Gruß KH
Hallo,
Danke für die Hinweise.
OXS ist die aktuelle 2.5. Die oxs_config wurde mit dem aktuellen 2.1 Confiurator eingestellt. Funktionsfähig ist es ja, aber eben nur nach einem Reset oder Ein-/Ausstecken des S-Port. Die serielle Konsole zeigt bei mir leider nichts (leer); Ich verwende einen AVRISP MkII. Vielleicht liefert ja der S-Port meines X8R beim Hochfahren Werte, die der oxs nicht verträgt und deshalb stehenbleibt. Ein zweiter von mir gebauter oxs zeigt die gleichen Symtome. Versuche mit veränderten Fuses beim Arduino (Startzeiten ändern) haben auch nichts gebracht, ebenso wie verschiedene Firmwares beim X8R.
Danke für die Hinweise.
OXS ist die aktuelle 2.5. Die oxs_config wurde mit dem aktuellen 2.1 Confiurator eingestellt. Funktionsfähig ist es ja, aber eben nur nach einem Reset oder Ein-/Ausstecken des S-Port. Die serielle Konsole zeigt bei mir leider nichts (leer); Ich verwende einen AVRISP MkII. Vielleicht liefert ja der S-Port meines X8R beim Hochfahren Werte, die der oxs nicht verträgt und deshalb stehenbleibt. Ein zweiter von mir gebauter oxs zeigt die gleichen Symtome. Versuche mit veränderten Fuses beim Arduino (Startzeiten ändern) haben auch nichts gebracht, ebenso wie verschiedene Firmwares beim X8R.
Code:
// Configuration file generated by OpenXsensor Configurator v2.1 the: 08-03-2015
// !! This file is only compatible with version v2.x of OpenXsensor !!
// OpenXsensor https://code.google.com/p/openxsensor/
// started by Rainer Schloßhan
//***********************************************************************************************************************
// Another file in this project (see oXs_config_description.h) provides detailed explanations on how to set up this file.
//***********************************************************************************************************************
#ifndef OXS_CONFIG_h
#define OXS_CONFIG_h
// --------- 1 - FrSky device ID when Sport protocol is used ---------
#define SENSOR_ID 0x1B
// --------- 2 - Serial data pin choice ---------
#define PIN_SERIALTX 4 // The pin which transmits the serial data to the FrSky telemetry enabled receiver
// --------- 3 - PPM settings ---------
//#define PIN_PPM // Arduino can read a PPM Signal coming from Tx. This allows to change the vario sensitivity using a pot or a switch on TX.
#define PPM_MIN_100 988 // 1500 - 512 ; pulse width (usec) when TX sends a channel = -100
#define PPM_PLUS_100 2012 // 1500 + 512 ; pulse width (usec) when TX sends a channel = +100
// --------- 4 - Vario settings ---------
// ***** 4.1 - Connecting 1 or 2 MS5611 barometric sensor *****
#define VARIO // set as comment if there is no vario
//#define VARIO2 // set as comment if there is no second vario
// ***** 4.2 - Sensitivity predefined by program *****
#define SENSITIVITY_MIN 50
#define SENSITIVITY_MAX 50
#define SENSITIVITY_MIN_AT 20
#define SENSITIVITY_MAX_AT 100
// ***** 4.3 - Sensitivity adjusted from the TX *****
#define SENSITIVITY_MIN_AT_PPM 10 // sensitivity will be changed by OXS only when PPM signal is between the specified range enlarged by -5/+5
#define SENSITIVITY_MAX_AT_PPM 40
#define SENSITIVITY_PPM_MIN 20 // common value for vario is 20
#define SENSITIVITY_PPM_MAX 100 // common value for vario is 100
// ***** 4.4 - Hysteresis parameter *****
#define VARIOHYSTERESIS 5
// ***** 4.5 - Vertical speeds calculations *****
#define VARIO_PRIMARY 0 // 0 means first ms5611, 1 means second ms5611 , 2 means vario based on vario 1 + compensation from airspeed
#define VARIO_SECONDARY 1 // 0 means first ms5611, 1 means second ms5611 , 2 means vario based on vario 1 + compensation from airspeed
#define SWITCH_VARIO_MIN_AT_PPM 10
#define SWITCH_VARIO_MAX_AT_PPM 90
// ***** 4.6 - Analog vertical speed *****
//#define PIN_ANALOG_VSPEED // the pin used to write the vertical speed to the Rx A1 or A2 pin (can be 3 or 11 because it has to use timer 2)
#define ANALOG_VSPEED_MIN -3
#define ANALOG_VSPEED_MAX 3
// --------- 5 - Airspeed settings ---------
//#define AIRSPEED MS4525
#define AIRSPEED_RESET_AT_PPM 100
#define COMPENSATION_MIN_AT_PPM 60
#define COMPENSATION_MAX_AT_PPM 90
#define COMPENSATION_PPM_MIN 80
#define COMPENSATION_PPM_MAX 120
// --------- 6 - Voltages & Current sensor settings ---------
// ***** 6.1 - Voltage Reference selection (VCC or 1.1V internal) *****
#define USE_INTERNAL_REFERENCE // Select the voltage reference, comment the line to activate the VCC voltage reference
// ***** 6.2 - Voltages analog pins *****
//#define PIN_VOLTAGE_1
//#define PIN_VOLTAGE_2
//#define PIN_VOLTAGE_3
//#define PIN_VOLTAGE_4
//#define PIN_VOLTAGE_5
//#define PIN_VOLTAGE_6
// ***** 6.3 - Voltage measurements calibration parameters *****
#define OFFSET_1 0
#define MVOLT_PER_STEP_1 1
#define OFFSET_2 0
#define MVOLT_PER_STEP_2 1
#define OFFSET_3 0
#define MVOLT_PER_STEP_3 1
#define OFFSET_4 0
#define MVOLT_PER_STEP_4 1
#define OFFSET_5 0
#define MVOLT_PER_STEP_5 1
#define OFFSET_6 0
#define MVOLT_PER_STEP_6 1
// ***** 6.4 - Number of lipo cells to measure (and transmit to Tx) *****
//#define NUMBEROFCELLS
// ***** 6.5 - Current sensor analog pin *****
//#define PIN_CURRENTSENSOR
// ***** 6.6 - Current sensor calibration parameters *****
#define OFFSET_CURRENT_STEPS 0
#define MAMP_PER_STEP 0.0 // INA282 with 0.1 ohm shunt gives 5000mv/A
// --------- 7 - RPM (rotations per minute) settings ---------
//#define MEASURE_RPM
// --------- 8 - Persistent memory settings ---------
//#define SAVE_TO_EEPROM
//#define PIN_PUSHBUTTON
// --------- 9 - Data to transmit ---------
// General set up to define which measurements are transmitted and how
#define SETUP_DATA_TO_SEND \
DEFAULTFIELD , ALTIMETER , 1 , 1 , 0
// --------- 10 - Reserved for developer. DEBUG must be activated here when we want to debug one or several functions in some other files. ---------
//#define DEBUG
#ifdef DEBUG
#include "HardwareSerial.h"
#endif
#endif// End define OXS_CONFIG_hIst ja seltsam. Habt ihr beide die neue EU ETSI V1.8.1 Firmware installiert? @ Abendsegler: Hast du sowohl 1.7 wie die neue 1.8.1 Firmware getestet? Beim Serial Monitor Baudrate 115 200 eingestellt?
Ich spiel mir mal die 2.5 drauf und teste das Verhalten mit der 1.7er Firmware auf einem X4R, meine X8R sind leider alle verbaut.
-- So schnell mal getestet, bei mir funktioniert es ohne Reset - exakt mit der oXs_config.h von oben. D.h. entweder Firmware- oder X8R-Problem?
Ich spiel mir mal die 2.5 drauf und teste das Verhalten mit der 1.7er Firmware auf einem X4R, meine X8R sind leider alle verbaut.
-- So schnell mal getestet, bei mir funktioniert es ohne Reset - exakt mit der oXs_config.h von oben. D.h. entweder Firmware- oder X8R-Problem?
Zuletzt bearbeitet:
Ich hatte gestern Abend noch mal ein reines Vario (arduino pro mini + GY-63) zusammen gelötet, konfiguriert mit oXs conf 2.1, die oXs 2.5 drauf gefahren und hatte den Effekt. Hab da ziemlich blöd geguckt.
Hab das Vario dann wieder zerlegt und das GY-63 separat am arduino uno mit nem anderen sketch gefahren. Soweit OK.
Dann in der Kombination (uno + GY-63) wieder oXs 2.5 drauf. An nen X6R und nix tut sich. Erst ein Druck auf reset und die Werte bewegen sich ...
Hab jetzt noch mal das GY-63 weg gelassen und ein shield von Drotek mit nem MS5611 drauf am uno. Selbes Bild.
Ist schon äußerst seltsam
Hier noch als Anlage debug und config.h
Ich glaube, ich poste jetzt mal parallel in openrcforums. Inzwischen gemacht, -> http://openrcforums.com/forum/viewtopic.php?f=86&t=6794
Wenn heute morgen nicht der post von Nyctalus hier gewesen wäre, hätte ich das jetzt erst mal zur Seite gelegt (shit happens ...), aber da scheint ja mehr dran zu sein.
Ach so, alles noch auf 1.7 ...
Gruß KH
Hab das Vario dann wieder zerlegt und das GY-63 separat am arduino uno mit nem anderen sketch gefahren. Soweit OK.
Dann in der Kombination (uno + GY-63) wieder oXs 2.5 drauf. An nen X6R und nix tut sich. Erst ein Druck auf reset und die Werte bewegen sich ...
Hab jetzt noch mal das GY-63 weg gelassen und ein shield von Drotek mit nem MS5611 drauf am uno. Selbes Bild.
Ist schon äußerst seltsam
Hier noch als Anlage debug und config.h
Ich glaube, ich poste jetzt mal parallel in openrcforums. Inzwischen gemacht, -> http://openrcforums.com/forum/viewtopic.php?f=86&t=6794
Wenn heute morgen nicht der post von Nyctalus hier gewesen wäre, hätte ich das jetzt erst mal zur Seite gelegt (shit happens ...), aber da scheint ja mehr dran zu sein.
Ach so, alles noch auf 1.7 ...
Gruß KH
Anhänge
Zuletzt bearbeitet:
Im Debug sieht man, dass das SPort-Protokoll nicht aktiviert wird, der oXs läuft dann im Hub-Mode, sonst ist alles OK. Ein Reset ist ja eigentlich nix anderes, als ein Arduino-Neustart - nur warum gehts dann auf einmal?
Ich hab mittlerweile fast den Verdacht, dass das die alte Geschichte mit dem Abstand Sender - Empfänger ist. Sind die sich zu nahe, funktioniert die Telemetrie nicht mehr. 3 Meter sollten immer reichen. Versuchts mal jemand?
Ich hab mittlerweile fast den Verdacht, dass das die alte Geschichte mit dem Abstand Sender - Empfänger ist. Sind die sich zu nahe, funktioniert die Telemetrie nicht mehr. 3 Meter sollten immer reichen. Versuchts mal jemand?
Ja Bernd, das SPORT PROTOCOL = 0 ist mir auch aufgefallen.
Hab meiner "besseren Hälfte" eine Etage tiefer mal die Taranis in die Hand gedrückt. (Betondecke dazwischen). Nix.
Könnte jetzt noch mal oXs 3.0 mit MPX drauf packen und das versuchen. NUR, an meinem PC (Baujahr 2009) spinnt seit neustem USB2. Und das sowohl unter Linux als auch unter WIN 7. Also mobo. Naja, noch ne Baustelle socket 775 gibt nicht mehr so viel und DDR2 ist auch nicht mehr sooo aktuell.
Gruß KH
Hab meiner "besseren Hälfte" eine Etage tiefer mal die Taranis in die Hand gedrückt. (Betondecke dazwischen). Nix.
Könnte jetzt noch mal oXs 3.0 mit MPX drauf packen und das versuchen. NUR, an meinem PC (Baujahr 2009) spinnt seit neustem USB2. Und das sowohl unter Linux als auch unter WIN 7. Also mobo. Naja, noch ne Baustelle
socket 775 gibt nicht mehr so viel und DDR2 ist auch nicht mehr sooo aktuell. Gruß KH
- Status
