Ja. Der T-Beam weiß nichts vom BMP am PI.

So ist es wohl tatsächlich am sinnvollsten, den BMP auf dem T-beam zu belassen, da nur so gewährleistet erscheint, dass die relevanten Daten von allen Komponenten aus nur einer Quelle erfasst, ausgewertet und korrekt abgestrahlt werden.

Danke für die ausführliche Erklärung auf github!

Das hat einiges erhellt.

Eine Frage bezüglich des Barosensors habe ich dennoch:

Wenn im Stratuxgehäuse ein Lüfter verbaut ist, ist es sinnvoll den Baroensor vom übrigen Gehäuse zu kapseln, um Luftdruckunterschiede durch den Lüfter zu vermeiden?

Ich habe es zumindest in meinem Gehäuse versucht.

Also ich konnte wenn überhaupt nur marginale Unterschiede zwischen Lüfter an/aus erkennen. Wenn dein Ziel ist, Verkehr mit einem Abstand von 3ft zu dodgen, dann empfehle ich dir ein Präzisionsmessinstrument welches von jeglichem Luftstrom getrennt ist. Falls deine Toleranz >3ft ist, ist die Ungenauigkeit irrelevant.

Übrigens noch ergänzend zu meiner Github Aussage: Wenn du das Flarm-NMEA Protokoll zur Kommunikation mit der App deiner Wahl verwendest, weiß die App nicht mal die Baro höhe. Da ist alles GPS only. Wenn du GDL90 verwendest, weiß die app beide Höhen. Die Apps arbeiten aber i.d.R. mit der MSL(=Geoid) höhe, also GNSS.

Falls dich das Thema interessiert, siehe meinen Artikel hier: https://github.com/b3nn0/stratux/wiki/Altitudes-in-Stratux-EU

Klasse, Danke!

Welche Software für den T-Beam wird denn derzeit von Euch empfohlen:

GXAirCom oder OGNTracker?

Der OGNTracker überträgt zwar "ADS-L, OGNTP, FANET and PilotAware in parallel", aber ich vermute, daß Flarm und Fanet derzeit noch häufiger genutzt wird, oder?

Läuft GXAirCom weitgehend stabil, obwohl noch experimentell?

NB: Ich nutze kein AHRS, nur den Barosensor.

Moinsen,

habe mal ein bischen mit GXAirCom herumgespielt:

Mein Setup war so, daß der Barosensor auf den T-Beam gelötet war.

Heute kamen dann drei neue Barosensoren, von denen ich einen an an die Pins des Raspi verbinden wollte. So habe ich auch getan:

Also: zwei Barosensoren im Stratux -> einer am T-Beam, einer am Raspi.

Dabei ist aufgefallen, daß mit der GXAirCom-Software eine falsche Barohöhe angezeigt wird, obwohl sie im "AHRS"-Fenster korrekt ist:

Interessanterweise "springt" die Höhe auch mal auf den korrekten Wert, bleibt aber im "AHRS"-Fenster immer gleich:

Zwischendurch wurde der neue Barosensor auf dem Raspi auch nicht erkannt und im "AHRS"-Fenster die "ALT" gelb gezeichnet.

Ich vermutete, daß der neue Sensor evtl. defekt war, die Kabel einen Wackelkontakt hatten oder die beiden Sensoren doch interferiert haben.

Daraufhin habe ich einen Fehler nach dem anderen ausgeschlossen (Kabeltausch, durchgemessen, Sensor gegen anderen getauscht) ohne ein anderes Ergebnis zu bekommen. Auch wurde die T-Beamsoftware in diesem Zuge mehrmals hin und her geflasht (ODN-Tracker <-> GXAirCom), um das Problem einzugrenzen.

Der OGN-Tracker zeigt, egal, welche Konfiguration ich hatte, immer die korrekte Höhe an.

Zuletzt habe ich den Sensor am T-Beam abgeknipst, da er am Raspi ohnehin besser aufhoben sei:

Das Ergebnis war jedoch das Gleiche.

Zusammenfassung:

es liegt Softwareproblem vor

-> GXAirCom:  Höhe im "AHRS"-Fenster korrekt, aber sonst falsch und "springt" auch gelegentlich auf den korrekten Wert.

-> OGN-Tracker: alle Höhen korrekt, ob mit zwei oder nur einem Barosensor, egal wo die angeschlossen sind

Ich hoffe, b3nn0 damit hilfreiche Hinweise zu geben, um das Problem zu beheben, falls es an der GXAirCom-Software liegt, was ich allerdings nicht vorstellen kann, da diese ja keine Barodaten an den Raspi/Stratux übermittelt. Denn im Fall des an den T-Beam gelöteten Sensors, war dieser an die Pins, die der OGN-Tracker benötigt gelegt. Während GXAirCom den Barosensor an ganz anderen Pins braucht, um ihn auslesen zu können.

b3nn0 und rvt haben das sehr gut bei den "Issues" im Github erklärt:

https://github.com/gereic/GXAirCom/issues/145

Kleiner Nachtrag zu b3nn0s Post auf Github:

"If you still want to force it to use the T-Beam one, feel free to disable Baro i2c in the settings. T-Beam pressure altitude will still be used."

Ich habe das mal ausprobiert und soweit ich das erinnere, war bei  in den Einstellungen ausgeschaltetem Baro im AHRS-Fenster "Baro" gelb. Also eigentlich kein Barosignal vorhanden, sondern nur hergeleitet/berechnet. Oder habe ich das falsch verstanden?

Vermutlich mit GxAirCom ja. Das übermittelt bisher ja kein Baro an den Stratux.

Ich hätte mal ne Frage zu Stratux, bzw. wie die meisten das hier Nutzen. 
Aktuell habe ich die Safesky APP im Einsatz, diese hat natürlich den Nachteil das sie ständig Internet braucht. In der Schweiz klappt das zwar ganz gut, im nahen Ausland vermutlich nicht mehr. Wie ergänzt sich ein Stratux mit Safesky. Ergibt es Sinn beides zu nutzen oder nutzt ihr nur Stratux und nichts anderes? Ich überlege mir eins zu bauen jedoch ist die Komponentenverfügbarkeit aktuell ziemlich beschränkt.