OXSENS OpenXsensor - Erste Schritte und Problem

Der GY-63 hat keinen Beschleunigungs-(Lage-)sensor. Du brauchst einen GY-86, bei dem musst du noch "INT" zusätzlich verdrahten. Das GPS muss einen Fix haben, geh mal ins Freie und warte dort ein paar Minuten, dann sollte das GPS gefunden werden, wenn sonst alles passt.

Edit: Der Sketch muss auch geändert werden. Das können wir per PM machen, oder du machst es mit Udos Methode.

Dank Dir Carbonator ich hab das falsch geschrieben. Es ist ein GY 86! Wegen der Änderung am Sketch Mail ich Doch separat an. Bin grad in Musdbsch

So, habe jetzt auch noch ein Mysterium aufzuklären.
Mein Stromsensor läuft ja nun schon super über den Eingang A7.

Jetzt möchte ich noch die Flugakku-Spannung messen. Dafür habe ich Eingang A6 ausgewählt.

Die Eingänge A4 und A5 sind ja für das Vario (kommt noch) reserviert und die Eingänge A0-A3 möchte ich für eine zukünftige Einzelzellen-Messung reservieren (max.4S).

Leider bekomme ich es nicht hin, das der Eingang A6 von der DS14 angezeigt/erkannt wird.
Was könnte da faul sein? Hänge mal die Screenshots mit den maßgeblichen Konfigurationen hier an.

In einem erstem Modul habe ich ein Vario und eine Empfängerspannungsmesseung an Eingang A0 (Volt_1) erfolgreich hinbekommen.

Ich habe daher hier mal testweise anstatt A6(Volt_5) mal A0(Volt_1) versucht und damit geht es.
Für mich sieht das erst mal so aus als wenn bei Jeti ausschließlich Volt_1 verwendet werden kann um abseits von Einzelzellenüberwachung eine zusätzliche Spannung zu messen.
Das beißt sich natürlich dann, wenn die Einselzellenmessung auf A0-A3 kommt.

Eigentlich sollte ja laut Beschreibung jeder Eingang (Volt_1.....Volt_6) konfigurierbar sein.

Wäre nett wenn sich mal ein Wissender dazu äußern kann.








Gruß Volker

Hallo,

vielleicht liegt das Missverständnis darin, dass man völlig beliebig Eingänge den 6 "Volt" zuordnen kann. Das wäre z.B. eine gültige Konfiguration für das, was du vorhast (4 Zellen + 1 Spannung):

Volt1 wird an A3 gemessen, Volt2 an A2, ......Volt5 an A6 Volt6 gibt es hier nicht. Könnte natürlich auch so aussehen:

Dann werden die Pins A0 bis A3 verwendet und Volt6 wird in diesem Fall an A6 gemessen, Volt5 gibt es hier nicht. Funktioniert beides.

Im ersten Beispiel müsste es dann natürlich heißen:

// ***** 2.4 - Jeti data *****
#define VOLTAGE_SOURCE VOLT_5

und im zweiten:

// ***** 2.4 - Jeti data *****
#define VOLTAGE_SOURCE VOLT_6

Häng doch deine beiden config gezipt an, das wird übersichtlicher.

Hallo Carbonator,
die freie Zuordnenbarkeit ist schon klar.

hier noch die beiden Config-Dateien.

Anhang anzeigen oXs_config_advanced.txt
Anhang anzeigen oXs_config_basic.txt

Wie du siehst habe ich ja Volt_5 verwendet und will die Spannung über den Eingang A6 einspeisen.

Gruß Volker

RESISTOR_TO_VOLTAGE in der falschen Spalte? Sonst sieht alles gut aus.

Danke für den Hinweis, habs grad noch geändert. Ändert aber nichts daran das es nicht funktioniert.
Hast du denn deine Beispiele mit Jeti realisiert?

Ich habe nämlich den Verdacht das nur das Jeti-Protokoll betroffen ist.
Sonst wäre das sicher längst mal irgendwo hochgekommen. Für Jeti gibt es wohl nur eine geringe Zahl von Nutzern für OXS.


Gruß Volker

Ich kann nur FrSky. Vermutlich hast du Recht, ich schicks mal an den Chef.

Das wäre sehr nett von dir.

Moin, ich schicke dir mstrens Antwort und den Kontakt per PM.

Danke dir.
Wäre doch schön wenn das ans laufen käme.

Taranis X9D + openXsensor + GPS -> Modellverlust ?

Hallo,

habe am 31.10.2017 mein 1000,- € Modell verloren

Ausgestattet war es ursprünglich mit einem FrSky X8R Empfänger, YEP-Regler mit BEC und 6 Digital-Servos. Das funktionierten bisher über Jahre ohne Probleme.

Vor einigen Wochen habe ich dann das Modell mit einem openXsensor Nachbau mit GPS-Modul erweitert. Leider hatte das Teil einen "Wackler" so dass ich mal Telemetriedaten bekam - meistens aber nicht. Also habe ich es mit einem Neubau des openXsensors und dem gleichen GPS-Modul ersetzt (eingehend getestest ).

Nun startete ich an besagtem Tag das Modell mit Motor, wobei ich alle Telemetriedaten (außer "curr" - war kein Stromsensor dran) bis auf die GPS-Daten (dauert immer ein bisschen) hatte. Der Steigflug verlief ganz normal und das anschließende Segeln gestaltete sich ebenfalls wie gewohnt.

Es befand sich mit weiteren Modellen relativ nahe am Hang in ausreichender Höhe so dass ich eigentlich - wie gewohnt - ganz locker dem Modell nachschaute. Dann plötzlich merkte ich, dass das Modell nicht mehr reagierte. Ich versuchte noch etwas zur Hangkante hinzugehen und hob die Senderantenne noch in Richtung Modell, allerdings waren alle Rettungsversuche vergeblich. In großen Kreisen steuerte das Modell gegen NULL

ich verlor natürlich die Verbindung zum Modell (Telemetrie), bekam sie allerdings wieder, als ich mich der Absturzstelle näherte. An den Überresten angekommen stelle ich fest, dass alles noch funktionierte, selbst die GPS-Daten waren mittlerweile eingetroffen ...

Meine Frage an die Experten: Könnte es sein, dass der Telemetriesensor (openXsensor) den Empfänger "verstopft" hat, so dass er den Kontakt zum Sender über einen längeren Zeitraum verloren hat?

Anbei einige Bilder meiner Konfiguration und der Logdatei (.txt entfernen), die allerdings sehr kurz ist und m. E. keinerlei Hinweise auf die Absturz-Ursache liefert.

Danke für eure Unterstützung.

Gruß Udo







Anhang anzeigen Graphite-2017-10-31.csv.txt

Schade, das ist schlimm, wenn man einen so schönen Segler verliert.

Da der Segler ohne oXs jahrelang funktioniert hat, gibt es eine gewisse Wahrscheinlichkeit, dass der Absturz mit dem Nachrüsten des oXs zusammenhängt. Die Tatsache, dass die Übertragung einen "Wackler" hat(te), weist auch in diese Richtung. Ich würde jetzt die Ursache des "Wacklers" suchen, eventuell findest du so direkt die Absturzursache.

Ein oXs kann den Empfänger nicht "verstopfen" oder durch falsche Daten o.ä. abschießen. Aber ein Kurzschluss zwischen VCC und GND im/am oXs kann natürlich das BEC lahmlegen. Die Kontakte des Arduino scheinen laut Bild freizuliegen, dort kann z.B. ein leitendes Teil schon einen Kurzschluss verursachen (glaube aber eher nicht, dass das die Ursache ist).



Kurzschlüsse können auch durch überstehende Drahtspitzen am Vario oder Arduino verursacht werden, die die gegenüberliegende Platine berühren. Da im Kurzschlussfall ein paar Ampere fließen, kann man unter Umständen an den entsprechenden Stellen noch Spuren davon entdecken. Das sieht aus, wie winzige Schweisspunkte.

Fazit: wenn der oXs den Absturz verursacht hat, dann nur durch einen Kurzschluss. Wenn du einen Kurzschluss ausschließen kannst, liegt die Ursache nicht beim oXs sondern woanders.

Ich hoffe, du findest den Absturzgrund heraus!
Gruß Bernd

Edit: Du schreibst zwar, dass nur der erste oXs den Wackler hatte, aber wenn man in den Log schaut, sieht man, dass kaum Daten übertragen wurden.

Hi,

1. evtl. wäre es Hilfreich wenn du sagen kannst wann du den Log gestartet hast (direkt nach einschalten oder erst im Flug oder Motor an)

2. wenn ich mir dein geloggten Schalter ansehe frage ich mich was du da alles geschaltet hast in kurzen Abständen ???

hier der Log von den Schaltern:



3. in deinem Log ist mir aufgefallen das Höhe und VSPD deckungsgleich verlaufen, das kann eigentlich nicht sein????

Auch einige andere Sensoren werfen fragen auf, das habe ich so noch nie gesehen.
Auch der Current Sensor liefert keine Werte ???
Bring mal bitte etwas Licht ins Dunkel.

Hier der Log dazu:


Deine Idee mit dem Verstopfen, kannst du getrost verwerfen, ich nutze auch OXS und Frsky Sensoren gleichzeitig so das alle 32 Telemetrie Felder voll sind und das schon seit längerem und auch ohne Probleme, ich habe sogar angefragt ob die Entwickler nicht noch ein paar mehr Felder zur Verfügung stellen können, da ich nicht alles in 32 Felder rein bekomme.

Erst mal herzliches Beileid
So etwas braucht niemand.

Ich vermute auch einen Brown-out des BEC aufgrund außergewöhnlicher Stromaufnahme.
Kannst du ggf die Strom vom oXs im oben gezeigten Szenario durchmessen ?
Evtl ist da ja noch der Wurm drin ..

Hallo an alle,

vielen Dank für die Anteilnahme und die guten Lösungsansätze

Bezüglich Log-Datei habe ich gestern herausgefunden, dass ich es durch einen falschen programmierten logischen Schalter kurz nach dem Motorstart ausgeschaltet habe. Deshalb auch die unsinnigen Daten.

Bei dem openXsensor habe ich mich wohl ein wenig unklar ausgedrückt: Ich hatte eine Vorgängerversion am Empfänger, die irgendwo einen Wackler hatte. Diese habe ich durch einen neu gebauten und ausgiebig getesteten Sensor ersetzt. Deshalb schließe ich mittlerweile dort die Ursache aus.

Ich neige eher zu den Ausführungen von @strgaltdel, dass die Ursache im BEC vom Regler zu suchen ist.

Eine weitere Ungereimtheit konnte ich bei meinen Untersuchungen feststellen und zwar verglich ich die Empfindlichkeit des verwendeten X8R-Empfängers mit 2 anderen. Dabei habe ich festgestellt, dass bei diesem die getestete Reichweite geringer war als die der beiden anderen. Nach einem Firmware-Update war dann die Reichweite bei allen Empfängern gleich.

Um einem Stromversorgungsausfall zukünftig vorzubeugen, habe ich mir von Optiboard einen Ultra-Guard 430 besorgt. Damit sollte eigentlich eine hohe Ausfallsicherheit erreichbar sein.

Gruß Udo

Sorry, ich verstehe es immer noch nicht was du abgeschaltet hast was diese wirren Werte erzeugen soll???


Ich stimme nicht zu, schließe es aber auch nicht aus, wenn ich mich recht erinnere hast du einen YEP Regler ?
Die YEP haben soweit ich weis alle 6A und 12A BEC zumindest ab 80A aufwärts diese verwende selbst und nur diese, aus eigener Erfahrung weis ich das das BEC echt brauchbar ist, auch bei Quälereien, was natürlich einen Defekt oder Fertigungsfehler nicht ausschließt.
Das kann man aber testen.



Das schließe ich als Ursache aus, nach der Zeit die das Modell in der Luft war kannst du "unmöglich" so weit weg gewesen sein das dass eine Rolle spielt.

Hab so ein ähnliches Teil von Scorpion in einem Modell mitgekauft und ausgebaut Warum ?
Sag ich Dir... das Teil ist klein, leicht und funktionier auch gut, hält die Spannung bei 5V ziemlich exakt und ist sogar belastbar.
Alles vorteile, richtig und jetzt kommt ein nachteil Der Backup Guard wird aus zwei Lipo Zellen versorgt dann ist ein Spannungsregler eingebaut der die 5V liefert und das tut das Teil so lange bis die LIpos soweit entaden sind das die Spannung schlagartig zusammenbricht ohne Vorwarnung. Das bedeutet ich bekomme es durch meine Telemetrie nicht mit wenn die Spannung fällt, bei meinen Eneloop überwache ich die Spannung und lasse mir ansagen wenn meine Grenze von 5,2V unterschritten wird, wenn das passiert weis ich das etwas nicht stimmt und sehe zu das ich Lande um den Fehler zu suchen und zu beheben, mit dem Backup Guard passiert nur noch eins, Spannung bricht ein und die Komplette Empfangsanlage ist Tot = Absturz und das ohne Vorwarnung. Hoffe man kann so einigermaßen verstehen was ich meine.

Eine zweite RX Stromversorgung ist nie verkehrt, habe ich auch in allen meinen Seglern, allerdings verwende ich ganz normale 800mAh Eneloop Zellen und lasse diese sogar vom BEC "nachladen" besser bei Laune halten... Die Zellen werden einmal pro Jahr mit Externem Lader geladen und Entladen um zu sehen was diese noch können.
Die YEP Regler ab 80-120A können das alle, selbst mehrfach so im Einsatz bewusst ohne Schottky Diode.


Ich komme einfach nicht von deinem seltsamen Log weg und finde dafür keine Erklärung.
Versuche du mal etwas Licht in mein dunkel zu bringen.

Wir und einige Kollegen verwenden den Ultra-Guard von Optiboard als Rettungsanker bei F3A Modellen.
Nach dem Anschließen lernt er die angelegte Spannung und reduziert diese im Störungsfall um 0,5 Volt nach unten.
Das heist, wenn wir den 10s Flugakku abklemmen und das BEC nicht mehr versorgt wir, springt der Ultra-Guard sofort mit reduzierter Spannung ein. Dieser muss extra ausgeschaltet werden, während in der zwischenzeit die Taranis die eingestellte Warnmeldung der Unterspannung wiederholt. Wer will kann diesen Zustand zusätzlich durch LED`s anzeigen, machen aber vermutlich die wenigsten.

Hallo devil,

ich versuche mal das mit dem LOG-Schalter zu erklären:

Ich habe Segler mit und ohne Motor. Bei den Motorseglern ist es ganz einfach. Ich definierte einen "Motor-Ein-Schalter" (SF), dann einen 2-Stufen-Schalter (SE) mit dem ich den Motor starte. L04 wird aktiv, wenn der Motorschalter auf "EIN" steht und der "Gasschalter" nicht "AUS" ist. Diesen Schalter nutze ich zum Starten der "Log-Aufzeichnung" (alle 10,0s ein Datensatz). Das funktioniert auch ganz gut.

Dann kamen die ersten "motorlosen" Flieger dazu. Da ich dort nicht mit dem "Motor-Ein-" und "Motor-Gas-Schalter" herumhantierten wollte, musste eine andere Lösung her. Ich definierte einen Schalter (L10), der bei einem RSSI-Wert größer 10dB aktiv wurde und einen, der den Höhenruderknüppel abfragte. Wenn der über ein gewisses Maß bewegt wurde, wurde auch dieser Schalter (L11) aktiv. Dei beiden Schalter legte ich mit einer "XOR"-Logik auf einen weiteren Schalter (L12).

Nun sollte es durch einen Trigger-Schalter (L13) so funktionierten, dass entweder der Motorschalter (L04) oder aber das Ereignis aus RSSI > 10 und/oder Höhenruderbewegung (L12) das LOG aktivieren sollte. Wie eine Untersuchung der Log-Datei nach dem Absturz aber ergab, wurde die Log-Aufzeichnung nach Ausschalten des Motors beendet.

Deshalb die komischen Werte

Zum Rumspielen noch die Modelldatei

Anhang anzeigen document1.otx.txt (die Erweiterung ".txt" entfernen)

Gruß Udo

Übrigens... wenn ich nerve mit dem genau wissen wollen, kannste das ruhig sagen... Ich möchte es immer verstehen sonst bin ich nicht glücklich und gebe auch keine Ruhe... aber ich kann damit auch gut anderen auf den Zeiger gehen... Bin halt so

Soweit Klar,
ABER ein abschalten des Logs ergibt nicht solche wirren Werte.

Hier mal ein Log von meinem letzten Flug, habe einfach, mal ein paar Werte genommen.



Was mir jetzt auch überhaupt nicht klar ist, was wurde den alles hin und her geschaltet kurz vor dem Einschlag?

Ich hänge noch mal dein LOG mit den Schaltern hier rein: