Moskito_Andi schrieb:Scheint also wirklich ziemlich knapp zu sein.
Hier ein relevanter Log-Auschnitt. Distanz ist ca. 200-250m entspricht einer Laufzeit von 4-5s.Kommt nur alle paar Minuten mal für ein paar Sekunden vor.
Die maximale Toleranz errechnet sich aus verschiedenen Parametern. Hier ist dann maximal erlaubt z.B. 210m, Entfernung war aber 244m. Fehlt nicht viel.. ich erhöhe ggf. einfach die Toleranz etwas für die nächste Version.
Danke, guter Plan.
Ich denke aufgrund der manchmal schlechten Mobilfunkverbindung in der Höhe kann es schon mal zu deutlichen Laufzeiten kommen,
Und wenn ein Ziel erst mal so nah ist, dann sollte auch der eigene Empfang es sicher im Range haben.
Also, wenn möglich, eine gezielte Vergrößerung des Toleranzbereichs nur für OGN-API Ziele wäre da kein Problem.
Ansonsten eine moderate Erhöhung für alle Quellen...
Gruß
Andreas
PS: Deine Änderung im Github sollte das Problem lösen. Ich werde dann testen und ggf. berichten.
Moin,
ich hatte an anderer Stelle über vermeintliche Probleme bei der Verbindung zwischen Skydemon und Stratux per Bluetooth LE unter Android berichtet.
Tim hat heute diese Probleme reproduzieren können und einen Fix gefunden. Das nächste Release von Skydemon wird diesen Fehler abstellen und läuft bei mir bereits unter Android 8 und 14 fehlerlos.
Gruß
Andreas
Servus zusammen,
ich hab mich schon länger nicht mehr mit meinen Stratuxen beschäftigt - sondern sie einfach nur genutzt.
Gestern hab ich sie erfolgreich auf die neueste Version 032 upgedatet.
Jetzt hab ich zwei Fragen und hoffe auf Antworten:
- Wie kann ich den eingebauten T-Beam updaten und konfigurieren?
- Wieso zeigt Skydemon mein OGN Target mit -03 relative Höhe an?
Ich befinde mich zuhause auf 1.450 ft Höhe.
Skydemon zeigt 1.450 ft Höhe an.
Stratux behauptet in der Traffic Tabelle das OGN Target befindet sich auf 1.150 ft Höhe.
Vielen Dank.
Grüße Kai
Hallo zusammen !
Ich habe eine Frage an Euch, die ihr euch schon besser mit Stratux auskennt.
Im dem Stratux-Menü kann ich ja meine eigene FLARM ID eintragen, die gesendet werden soll. Wenn ich einen Mode S Transponder habe, sollte ich/kann ich den HEX-Code des Transponders eintragen, damit nicht immer Doppel-Targets für die anderen sichtbar sind usw.
Frage:
Wenn ich im Verein von einem auf das andere Flugzeug wechsele, dann ändere ich ja auch stets im Menü die FLARM ID meines Stratux. Je nachdem, welches Flugzeug ich fliege.
Ist dies nur beim T-Beam möglich oder auch beim T-Motion?
Ich hatte nämlich bislang nichts finden können, habe aber mal irgendwo gelesen, daß man beim T-Motion beim Flashen zwar eine ID eingeben kann, diese dann aber fix und nicht änderbar ist, es sei denn ich flashe wieder ?
Stimmt das, oder kann ich bei beiden Varianten (T-Base und T-Motion) stets im Menü die ID vor jedem Flug ändern ?
Das würde nämlich meine Entscheidung beeinflussen, ob ich mir ein T-Base oder T-Motion besorge und einbaue.
Danke für Eure Antworten !
Aktuell ist nur der T-Beam zu empfehlen denn nur für ihn gibt es die passende SoftRF Variante (von Moshe Braner) die nun auch im Stratux Github Repository liegt. Diese SoftRF Variante hat einen besonderen Modus mit dem er gut mit dem Stratux zu kombinieren ist. Wenn du auf einen anderen Flieger wechselst dann musst du wie auch schon vorher die neue ID im Menü eintragen und an den SoftRF Tracker "schicken", darum kommt man nicht rum.
Beim T-Motion bin ich mir nicht mal sicher ob er das aktuelle FLARM Protokoll überhaupt unterstützt und Moshe hat auch keine entsprechenden Pläne diese Anpassung zu machen.
Stefan G. schrieb:Der T-Motion hat die selbe Firmware wie die anderen Geräte und muss halt über den etwas unbequemen Weg von Hex-ID festverdrahteten Firmware umgeflasht werden (Moshe braucht es dafür nicht, das macht die originale FW schon). Leider muss ich feststellen, dass die wenigsten T-Motion/SoftRF Nutzer daran denken die Firmwareupdates einzuspielen und deswegen sind schon recht viele mit den veralteten Versionen unterwegs.
Beim T-Motion bin ich mir nicht mal sicher ob er das aktuelle FLARM Protokoll überhaupt unterstützt und Moshe hat auch keine entsprechenden Pläne diese Anpassung zu machen.
T-Beam + GX-Aircom V7.0 senden auf T-Motion + Softrf V1.5.1 empfangen funktioniert bei mir
OkeP schrieb:Falsch. Nur weil alle SoftRF Firmware Varianten für die verschiedenen Plattformen die gleiche Versionsnummer haben, heist das nicht dass sie alle auch die gleichen Funktionalitäten haben. In der Datei
Der T-Motion hat die selbe Firmware wie die anderen Geräte
./SoftRF/software/firmware/source/SoftRF/src/platform/STM32.h in Zeile 237 steht #define EXCLUDE_AIR7
OGN Stationen und auch Stratux empfangen natürlich solche Tracker aber nur weil sie neben v7 auch noch weiterhin v6 decodieren. Ich konnte es leider selbst noch nicht verifizieren, insofern sollte mal jemand mit einem T-Motion nachprüfen ob der auch von einem "echten" FLARM wirklich empfangen wird - bitte um Feedback wenn dem so wäre!
mal ne dumme Frage: die Verwendeung des Macro EXCLUDE_AIR7 finde ich nur in software/firmware/source/SoftRF/src/protocol/radio/Legacy.cpp. Dort wird ein kurzer Bereich ab Zeile 352 mit den 2 Methoden legacy_encode und legacy_decode ausgenommen. In dem else Zweig ab Zeile 364 werden diese aber aufgeführt. Damit sollten die beiden Methoden doch zur Verfügung stehen?