Uli-Light schrieb:
Auf der Seite steht außerdem etwas von ADS-L. Ich

https://www.uavdach.org/easa-legt-ads-l-standard-fest/

Da haben sie aber eine doofe Abkürzung genommen, die es schon seit über 20 Jahren gibt.

im Verlinkten Artikel von OkeP wurde auch die falsche Bedeutung der Abkürzung genutzt in der dort Verlinkten PDF steht es dann richtig Automatic Dependent Surveillance – Light.

Asymetric Digital Subscribe Line, das ist der "HighSpeed" (in Deutschland zählt das schon dazu) Internetzugang nach ISDN.

So klingt das wie FLARM, wurde wohl auch von Leuten von FLARM und OGN (OpenGliderNet "!Flarm im Internet) mit entworfen.

Moinsen,

erstmal allerherzlichsten Dank für Eure Mühe!

ich habe die GXAirCom Software mal aufgespielt.

Allerdings habe ich auf de TTGO 1262 den Barosensor gelötet, der nun aber wohl nicht von der GX-Software erkannt wird.

Soll ich den nun entlöten und auf den Raspi knödeln oder warten, ob die GxAirCom die Daten irgendwann auch auswirft?

Desweiteren habe ich trotz eifrigem und wiederholten Lesen noch immer nicht verstanden, was ich bei OGN-Tracker Config eintragen soll, wenn ich mit einem Mode-S-Transponder unterwegs bin:

"Tracker Adress Type" OGN oder ICAO?

-> habe mal ICAO eingestellt und bei "Tracker Adress": die HEX-Adresse des Mode-S-Transponders.

Bei "Ownship Mode S/OGN Codes" habe ich den HEX-Codes des Mode-S-Transponders eingetragen.

-> ist das so korrekt? Wenn ich bei "Tracker Adress Type" OGN einstelle, ändert sich das Icon auf der Traffic-Seite: Das Flugzeug-symbol wird dann von Kreisen umrandet und unten erkennt mal einen kleinen Pinüppel.

Ist hingegen "ICAO" eingegeben, sehe ich auf der "Traffic"-Seite meinen Flieger zweimal.

Wobei ich das "trocken" getestet habe: bin zuhause und der Transponder des Fliegers daher nicht eingeschaltet...

VG,

Markus

Peuqui schrieb:
habe mal ICAO eingestellt und bei "Tracker Adress": die HEX-Adresse des Mode-S-Transponders.

Ist korrekt.

Peuqui schrieb:
von Kreisen umrandet und unten erkennt mal einen kleinen Pinüppel.

Das ist das Stratux Logo. Das siehst du immer nach einer Weile wenn erkannt wird, dass es sich beim empfangenen Gerät um einen Stratux handelt.

Hallo b3nn0,

vielen Dank für Deine rasche Rückmeldung!

Ich habe mal im Github einen Issue bzgl. meiner Frage eingestellt und eine entsprechende Rückmeldung erhalten.

Dort meinte rvt, daß ich einfach einen neuen BMP280 auf den Raspi löten/stecken und den auf dem TTGO belassen solle. GXAirCom würde den aufgrund anderer Pinbelegung ohnehin nicht nutzen.

Nun sind wir uns aber nicht sicher, wenn ich anstatt der GXAirCom nun wieder den OGN Tracker auf den TTGO aufspiele und einen zusätzlichen BMP280 auf den Raspi gesteckt habe (löten wäre mir lieber, da im Tragschrauber eher die Gefahr eines Steckerabfalls aufgrund der Vibrationen besteht, oder?) sich nicht beide gegenseitig stören könnten?

Was denkst Du darüber?

BTW: Wie ist die Unterstützung von präziseren BMPs, z.B. BMP390? Ginge so einer auch und bringt er überhaupt einen Mehrwert (außer den Kosten)?

VG,

Peuqui

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

Sollte eigentlich kein Problem sein. Du solltest dann aber - wenn du OGN Tracker installierst - den Baro in den Stratux settings deaktivieren. Sonst wirst du ggf. leicht springende Höhen bekommen, da mal der Wert des einen und mal der des anderen kommt, und diese eben gewisse, Toleranzen haben.

Es wird nur den BMP280 unterstützt, sonst keiner.

EDIT: Oh, stimmt nicht. Gerade nochmal im code geguckt. Sollten 2 BMPs im Stratux sein wird der, der am PI hängt bevorzugt und der am T-Beam ignoriert.

Das hatte ich auch befürchtet!

Aber wenn man den Baro in den Settings deaktiviert, wird doch gar kein Barosignal mehr ausgewertet, gleich von welcher Quelle, oder?

Ah, da hat sich mein EDIT mit deiner Antwort überschnitten, sorry.

Nein, BMP in den Settings betrifft nur den i2c BMP. $PGRMZ vom T-Beam wird trotzdem ausgewertet.

und siehe EDIT oben:

EDIT: Oh, stimmt nicht. Gerade nochmal im code geguckt. Sollten 2 BMPs im Stratux sein wird der, der am PI hängt bevorzugt und der am T-Beam ignoriert.
Siehe https://github.com/b3nn0/stratux/blob/7903eb48781a53f5a70d9d90e4965386d3eeb002/main/gps.go#L1823

und https://github.com/b3nn0/stratux/blob/7903eb48781a53f5a70d9d90e4965386d3eeb002/main/gps.go#L1691

Cool, habe gerade Deine Antwort im Github gelesen!

Danke!

Bin gespannt, ob rvt das im Code gemäß Deiner Anregung ändert, dann könnte hardwaremäßig alles so bleiben, wie es ist...

b3nn0 schrieb:
Sollten 2 BMPs im Stratux sein wird der, der am PI hängt bevorzugt und der am T-Beam ignoriert.

Das betrifft aber doch nur den Stratux und beeinflußt den T-Beam nicht? Also strahlt der T-Beam trotzdem die korrekte Höhe "seines" BMP280 weiterhin ab? Sonst wäre das schon doof, wenn der Pi-BMP den im T-Beam lahm legen würde? Ich fände es eigentlich sinnvoller, wenn der BMP im T-Beam den Vorrang bekäme, damit der Stratux mit der Höhe arbeitet die auch low-Power Antikollision abgestrahlt wird.