-
Hallo Leute!
Ich habe einen Samsung Galaxy Tab A7 Lite mit Android 14. Auf dem Gerät läuft meine VFR-App (SimpleVFR, das ist aber aktuell nicht das Problem).
Das Gerät ist während des Fluges mit einem Stratux verbunden.Und nun die Probleme: oft verliert das Gerät die Verbindung zum Stratux. Manchmal kriege ich das wieder verbunden, sehr sehr oft muss ich den Stratux mehrmals ausschalten und wieder einschalten und/oder das WLAN am Tablet aus- und wieder einschalten, damit die Verbindung wieder steht.
Das ist natürlich im Flug extrem nervig. Und während des Fluges habe ich natürlich auch keine Möglichkeit das Problem zu suchen.
Jetzt bin ich zu Hause, die Flugplätze sind zu und ich kann das Problem suchen.
Und was ich gerade gemerkt habe ist, dass wenn ich vom Stratux das Tablet anpinge kommen oft duplizierte ICMP-Antworten:64 bytes from 192.168.100.41: icmp_seq=184 ttl=64 time=2.32 ms
64 bytes from 192.168.100.41: icmp_seq=185 ttl=64 time=18.4 ms
64 bytes from 192.168.100.41: icmp_seq=185 ttl=64 time=19.0 ms (DUP!)
64 bytes from 192.168.100.41: icmp_seq=186 ttl=64 time=28.0 ms
64 bytes from 192.168.100.41: icmp_seq=187 ttl=64 time=7.01 ms
64 bytes from 192.168.100.41: icmp_seq=188 ttl=64 time=69.2 ms
64 bytes from 192.168.100.41: icmp_seq=189 ttl=64 time=4.39 ms
64 bytes from 192.168.100.41: icmp_seq=189 ttl=64 time=4.87 ms (DUP!)
64 bytes from 192.168.100.41: icmp_seq=190 ttl=64 time=13.5 msIch habe noch ein altes Tablet (Lenovo TAB S8 mit Android 5). Ich habe es auch mit dem Stratux verbunden und der ping läuft deutlich besser. Kleinere Zeiten und keine duplizierte Pakete.
Auch die App scheint stabiler zu laufen, aber das Tablet ist sowieso am Ende seines Lebens und kann auch nicht wirklich im Flug nutzen, auch wegen des Akkus.
Nun, es kann sein, das ich das Problem gefunden habe, also das Netzwerk zwischen Stratux und Samsung-Tablet ist nicht ganz in Ordnung.
Die Frage ist nun, wie kann ich das lösen? Ich habe bereits alle Optionen in den WLAN-Einstellungen geprüft und konnte nichts finden, was nicht in Ordnung ist.Hat jemand vielleicht ein Vorschlag?
Tausend Dank und euch alle eine schöne Landung ins neuen Jahr!
Luca -
-
Hmm.
Erstm zur Hause die gleiche Stromversorgung wie im Flugzeug?
Und Ping (ICMP) ist immer ein schlechter test für Netzwerk (ausser ICMP ist erlaubt und man will gucken ob das Gegenüber da ist) , es gehört zwar zum tcp/ip Protokoll. Ist aber etwas anders als eine TCP bzw udp Verbindung.
Weil wenn das WLAN weg ist, hat es ja weniger mit dem Netzwerk Protokoll auf Layer 2 und 3 zu tun, sondern auf Layer 1
Interessant wären die raspi logs zum Zeit Punkt beim verlieren der Verbindung (also mal permanent logging im stratux aktivieren)
Dann was für ein Pi ist das? Welches Netzteil,und ist Bluetooth am pi aktiv (gibt da wohl auch gerne mal probs, erst recht bei 2,4 WLAN)
-
HansOtto schrieb:
Erstm zur Hause die gleiche Stromversorgung wie im Flugzeug?
Also, zu Hause habe ich natürlich ein normales USB-Netzteil. Im Flugzeug nutze ich die USB-Anschlüsse am Cockpit, bzw. ein "Zigarettenanzünder-USB-Ladegerät". Das Kabel ist aber gleich
Und Ping (ICMP) ist immer ein schlechter test für Netzwerk (ausser ICMP ist erlaubt und man will gucken ob das Gegenüber da ist) , es gehört zwar zum tcp/ip Protokoll. Ist aber etwas anders als eine TCP bzw udp Verbindung.
Das weiß ich ganz genau... Ich bin ja schließlich IT-ler...
Bloß mit Tablet bin ich nicht so fit...Weil wenn das WLAN weg ist, hat es ja weniger mit dem Netzwerk Protokoll auf Layer 2 und 3 zu tun, sondern auf Layer 1
Das WLAN war zu dem Zeitpunkt nicht weg.
Nur die Antwortzeiten waren relativ lang und kamen die duplizierte Pakete.Interessant wären die raspi logs zum Zeit Punkt beim verlieren der Verbindung (also mal permanent logging im stratux aktivieren)
Das habe ich auch gedacht, allerdings erst nachdem ich alles ausgeschaltet habe und ins Bett gegangen bin...
Ich werde heute nochmal experimentieren.
Das ist ein Raspi 3B. Über Netzteil habe ich oben schon alles geschrieben. Unterspannung gibt es nicht (das habe ich schon geprüft).Dann was für ein Pi ist das? Welches Netzteil,und ist Bluetooth am pi aktiv (gibt da wohl auch gerne mal probs, erst recht bei 2,4 WLAN)
Das mit dem Bluetooth ist interessant. Kannst du mir sagen, wie man das ausschaltet?Vielen Dank
Luca -
Moin nochmal!
Also, gerade geschaut, ich würde sagen, dass auf dem Stratux ist Bluetooth als Default deaktiviert:
root@stratux:~# cat /boot/firmware/config.txt
# RPi /boot/firmware/config.txt
dtparam=audio=on
max_usb_current=1
usb_max_current_enable=1
dtparam=i2c_arm=on
dtparam=i2c1=on
dtparam=i2c1_baudrate=400000
dtparam=i2c_arm_baudrate=400000
dtparam=spi=on
# move RPi3 Bluetooth off of hardware UART to free up connection for GPS
dtoverlay=disable-bt
# i2c serial support
dtoverlay=sc16is752-i2c,int_pin=4,addr=0x4d,xtal=1843900
# Otherwise TTGO T-Motion will cause kernel panic on bookworm
dtoverlay=dwc2,dr_mode=host
# disable default (mmc0) behavior on the ACT LED.
dtparam=act_led_trigger=none
dtparam=act_led_activelow=off
# The below has been added as a proposed EMI reduction measure. Issue #573.
sdram_freq=450
core_freq=450
arm_freq=900
arm_64bit=1Außerdem ist das Modul bluetooth gar nicht geladen... Also, daran liegt es nicht...
Ich habe außerdem den "Ping-Test" laufen gelassen, und gleichzeitig geschaut, was der Journal sagt.
DUP-Antwort kommt, journalctl sagt nichts... :(Andere Ideen?
Danke
Luca -
HansOtto schrieb:
Das stimmt schon, aber doppelte Pakete weisen doch schon auf arge Probleme im Netzwerkstack des Tablets hin. Da kann ich den Raspi schon verstehen, wenn er irgendwann die ganze Verbindung verwirft.Und Ping (ICMP) ist immer ein schlechter test für Netzwerk (ausser ICMP ist erlaubt und man will gucken ob das Gegenüber da ist) , es gehört zwar zum tcp/ip Protokoll. Ist aber etwas anders als eine TCP bzw udp Verbindung.
-
-
HSV schrieb:
Eben!
Das stimmt schon, aber doppelte Pakete weisen doch schon auf arge Probleme im Netzwerkstack des Tablets hin. Da kann ich den Raps schon verstehen, wenn er irgendwann die ganze Verbindung verwirft.Aber ich weiß nicht, wie ich auf dem Tablet das Problem suchen (und lösen) kann...
Ideen?
Luca -
Das mit dem Bluetooth ist richtig ist aus im stratux, ausser man nutz noch was anderes mit zb, die neue Funktion daten per bt zu übertragen, oder Bluetooth Audio bei der Radar Bildschirm Erweiterung.
Das dup bei den pings, ist erstmal ein Symptom, muss aber nix mit dem Problem zu tun habe, die frage ist, setzt zur gleichen Zeit auch in der app die Verbindung zum stratux aus?
Und es sollte auch die gleiche Stromversorgung sein, da du ja (wenn ich richtig vertanden habe) jetzt erst das logging aktiviert hast, weißt du ja nicht ob als im Flug die Probleme auftraten nicht evtl doch etwas geloggt wurde. Und gerne auch in die anderen logs in /var/log schauen.
Noch eine andere Frage, wie erhält deine App die Daten? Via Broadcast und udp? Fragt den stratux via TCP an? Welcher Port? Gibt ja da mehrerer Möglichkeiten.
Wie sind die enrgieoptionen für die app? Alle abgeschaltet?
Wie sieht es aus mit den WLAN Einstellung, gibt bei einigen Geräten glaube auch ne Funktion wenn wlan nicht genutzt wird, schalte es ab zum stromsparen. Und evtl sind die Daten die empfangen werden vom stratux dafur zu wenig
-
HansOtto schrieb:
Das mit dem Bluetooth ist richtig ist aus im stratux, ausser man nutz noch was anderes mit zb, die neue Funktion daten per bt zu übertragen, oder Bluetooth Audio bei der Radar Bildschirm Erweiterung.
Das ist nicht mein Fall
Das dup bei den pings, ist erstmal ein Symptom, muss aber nix mit dem Problem zu tun habe, die frage ist, setzt zur gleichen Zeit auch in der app die Verbindung zum stratux aus?
In den letzten zwei Versuche nicht... Gestern, beim ersten Versuch, schon.
Aber dann konnte ich das nicht mehr reproduzieren...
Heute war das Gerät 1,5 Stunden in Betrieb und nicht mal das kleinste Problem, außer die DUP-Pakete...Und es sollte auch die gleiche Stromversorgung sein, da du ja (wenn ich richtig vertanden habe) jetzt erst das logging aktiviert hast, weißt du ja nicht ob als im Flug die Probleme auftraten nicht evtl doch etwas geloggt wurde. Und gerne auch in die anderen logs in /var/log schauen.
Debian 12 (was aktuell bei Stratux benutzt wird) nutzt journald, also in /var/log findet man kaum was...
Ich habe aber auch die stratux.log heruntergeladen und nichts verdächtiges gefunden.
Noch eine andere Frage, wie erhält deine App die Daten? Via Broadcast und udp? Fragt den stratux via TCP an? Welcher Port? Gibt ja da mehrerer Möglichkeiten.
TCP auf Port 2000
Wie sind die enrgieoptionen für die app? Alle abgeschaltet?
Jup!
Wenn du mir sagen kannst, wo diese Option ist, werde ich das auch prüfen... Sonst habe ich nichts gefunden, auch nicht bei den "Entwickleroptionen"...Wie sieht es aus mit den WLAN Einstellung, gibt bei einigen Geräten glaube auch ne Funktion wenn wlan nicht genutzt wird, schalte es ab zum stromsparen. Und evtl sind die Daten die empfangen werden vom stratux dafur zu wenig
Danke
Luca -
Hallo Luca,
ich bin mir ziemlich sicher, dass dein A7 das Problem ist. Und dass der Stratux die Verbindung kappt, wenn er keine gültiges Pakete erhält. Doppelte Pakete können auch in "normalen" TCP-Verbindungen auftauchen. Das kann für die empfangende Seite ein Problem sein, so dass die ganze Session verworfen wird. Das sieht man ggf. in den Logs erst, wenn der LogLevel erhöht wird.
Ich würde das A7 neu aufsetzen und schauen, ob das Problem bleibt (auch beim ICMP-Test). Wenn ja, sieht das stark nach Hardwareschaden aus...
VG
Hartmut
-
HSV schrieb:
ich bin mir ziemlich sicher, dass dein A7 das Problem ist. Und dass der Stratux die Verbindung kappt, wenn er keine gültiges
Inzwischen bin ich auch derselben Meinung...
Bei einem Test heute konnte ich sehen, dass die Verbindung weg war und sich etwas eine Minute lang nicht wieder verbinden konnte, obwohl das WLAN noch da war (zumindest gab das "WLAN-Zeichen" auf der Leiste oben).In derselben Zeit ein anderes Tablet hat kein Problem gehabt und konnte mit dem Stratux weiter sprechen...
Gghhh... Hardreset ist immer ′ne Sache, ich muss das erstmal planen und die Sicherung nochmal prüfen...Pakete erhält. Doppelte Pakete können auch in "normalen" TCP-Verbindungen auftauchen. Das kann für die empfangende Seite ein Problem sein, so dass die ganze Session verworfen wird. Das sieht man ggf. in den Logs erst, wenn der LogLevel erhöht wird.
Ich würde das A7 neu aufsetzen und schauen, ob das Problem bleibt (auch beim ICMP-Test). Wenn ja, sieht das stark nach Hardwareschaden aus...
Grüße
Luca -
Aktuell sind 8 Besucher online.
Neue Mitglieder:
janafliegtGestern
ClausCordesGestern
DirkHorstam 03.04.25
RainerEDPZam 01.04.25
Fabian Harderam 01.04.25
