Ich dachte ja lange ich bin der einzige mit solchen Problemen.. Schön zu wissen dass dem nicht so ist. Zu den workarounds: gerne mal ausprobieren (und Rückmeldung geben!). Perfekt sind sie beide nicht. Dachte erst der andere Wifi stick ist die beste Lösung. Hatte aber auf einem längeren Flug heute doch wieder einige Aussetzer. Den Workaround in den Einstellungen einfach mal testen - kost ja nix. Bin gespannt auf mehr Testergebnisse.

Werde auch die Tage mal einen Raspi 3 b+ Stratux bauen - bin mal gespannt ob der sich anders verhält (hat nen anderen Wifi Chip, aber leider auch wieder Broadcom).

@b3nn0

Der „SkyDemon Android disconnect bug workaround-button“ hat sich auch für uns iOS- Jünger als absolut nützlich erwiesen. Gab es vor dessen Einsatz bei mir noch 20-30 disconnects pro Flugstunde, war es gestern bei 3 Flügen mit einer Gesamtdauer von einer guten Stunde gerade mal 1 (in Worten ein!) disconnect.

Super Sache! Vielen Dank dafür und weiter so!

Gruß

Eric

Das freut mich sehr zu hören, danke für die Rückmeldung!

thank you b3nno for your work on the Europe edition.  I am currently testing v4 on a RPi Zw.  I had earlier attempted to compile from source for the Rpi3+ but found the available descriptions around the net far too obscure and basically in error.  I pretty much gave up when the make error regarding the statically linked wiring pi code came up, as this has been a problem for about a year I think.  So I was relieved to find your fork!  So, v4 seems to be working in the workshop today,  and, as I live close by Farnborough airport in the UK, there are plenty of contacts to see (no flarm though).  I am testing with skydemon on several devices, an android tablet, a smartphone, a PC and an I-pad mini.  Oddly,  of these,  the device I use when flying (a Samsung galaxy tab S2) is the only one which does not work with SD (no connection) even though the stratux  webpages work fine.  I tried changing the ip address to 192.168.1.1 which seems to be favoured by SD according to some forums, but this made no difference. Find it hard to understand how the can be different to the others.  Any ideas?

Kind Regards,

Robert

@viseng

Hi,

First of all, I think the better mode of communication is the github page, rather than a german ultralight forum. Feel free to open an issue there next time, makes it simpler to track things.

Anyway, about using the b+: I had no issues with the b+ in my testing. However, you are right about the wiringPi linking.
To overcome that, you can simply link dynamically. To do so, in the Makefile, ind the "fancontrol:" section, and in the go build command of that, change BUILDINFO_STATIC to BUILDINFO.
Some more resources about that:
https://github.com/b3nn0/stratux/issues/10
https://github.com/b3nn0/stratux/blob/master/image/mk_europe_edition_device_setup_stretch.sh
https://github.com/b3nn0/stratux/wiki/RaspberryPI-3-b---Testing

(ignore the "/root/fake" part of the script, that′s just for setup in a virtual machine)

Now about your Galaxy Tab 2:
That is really hard to say. I tested with a Galaxy Tab S2 aswell, without issues. The 192.168.1.1 IP should only be needed for the FLARM protocol. For GDL90/Stratux, SkyDemon should not care.
Things I would check to debug the issue further:
a) Maybe install some UDP sniffer on your tab, like this: https://play.google.com/store/apps/details?id=com.sandersoft.udpmonitor

Enter port 4000 in the "Local Port" field and hit Start receiving. Check if you receive any output, at least after a couple of seconds

b) Once connected and Skydemon is in Flying mode (important!), check http://192.168.10.1/getClients
Is your tablet listed there? I would think not. Is the SleepFlag true or false?

c) Especially if the tab is not listed in b), for testing, try to enter your tab′s IP address in the settings as a static host (maybe some DHCP issues).

Hi b3nno

thanks for the prompt reply, as you suggest, I will use the normal issue reporting system in future if necessary .  As I plan to use flarm as well with SD,  will stick with 192.168.1.1.  for stratux,  and monitor udp transactions on the S2.

cheers,

Robert.

viseng schrieb:
As I plan to use flarm as well with SD,  will stick with 192.168.1.1

Sorry, I think I said that in a confusing way:
For the Stratux, the IP does not matter, no matter if the Stratux receives Flarm, UAT or ES targets.

Skydemon is a passive device in that chain. It waits for UDP connections on port 4000 and when it receives one, it accepts the traffic.

When SD DOES care about the IP address, is when using the Flarm NMEA protocol between SD and the traffic device. This is mainly the case when using an official flarm device.

Stratux = GDL90  => IP does not matter
Flarm device = Flarm NMEA => IP has to be .1.1.

But anyway, yes, you can of course leave it at 1.1, as it doesn′t matter. At least as long as your tablet will get a DHCP assigned IP address from that range

Guten Abend,

ersteinmal herzlichen Dank für Euer Engagement. Klasse!!

Jetzt habe natürlich gleich die V4 geladen, aber da spielt bei mir SD auf dem iPad mini nicht mehr mit: „Waiting for device “ 

Auf der Browser Seite ist aber alles gut, GPS 0,4m und auch jede Menge Traffic. (Vorteil Dachterrasse). Den neuen Schalter hatte ich auf SkyDemon an/aus probiert. 

Alte V3 wieder drauf, alles gut. 

SD zeigte dann noch einen Fehler: 

Can not access an disposed object  

Object name: system.net.socket.sockets

Ich bin mir aber nicht mehr sicher, ob das nach dem Ausschalten vom Raspi kam  

Grüße, Manfred

@ b3nno

Ah, I now understand the reason for 1.1 instead of 10.1, thank you. Tried the UDP sniffer as you suggested. This confirmed that there is NO incoming traffic on 4000. Also tried the following

going to static ip address of 192.168.1.5 when connecting to Stratux. This address certainly worked ok on other device.

adding wifi security to stratux connection.

checked the file /network/UDP which showed that SD was definitely opening and closing port 4000, and that with SD closed down, no other apps were trying to use 4000.

used NoRoot Firewall to try to see if any services were blocking 4000 but this was not successful.

I have to conclude that the android system on this device is somehow blocking 4000 for UDP, but i am no expert on this by any means. Its a pity that all the data needed for SD gets to the device over port 80 via the webgui but the same data appears to be blocked on 4000. If there was an app running in background to relay the data on 80 up to 4000, that would solve it?

@ Manfred

Have seen the same system.socket.sockets error on the Samsung Tablet at the moment of pressing the "stop navigating" button after trying to get a connection.

Robert

@viseng

That is very strange to hear.
Forwarding port 80 to 4000 will not help you, since Skydemon will not understand what is arriving, since the protocol is different.
However, I can still not believe that the tablet is blocking all traffic on 4000. It seems more likely to me, that the Stratux is not sending any traffic to that particular device for some reason. The only way to make sure that Stratux actually detected the client device is, if you go to http://192.168.10.1/getClients (1.1?) while SkyDemon is in flying mode and verify that a) your tablet′s IP is listed there and b) SleepFlag is false.

I am pretty sure that either of those two is the case.
If your tablet is not listed there at all, it is a DHCP / IP issue and we can work on that. If SleepFlag is true, the Stratux has detected that the target device is not accepting any packets (i.e. SkyDemon not in flying mode / your UDP sniffer is not in receiving mode, ...).

What I meant by static IP address is, go to 192.168.10.1 with your browser, then Settings, and find the "Static IPs" setting. Put your tablet′s IP address in there.

@manne_fr

Der Fehler kommt by Skydemon manchmal wenn man den Flugmodus beendet. Ist eine Macke von SD - einfach ignorieren.
Ansonsten hat sich in V4 eigentlich nichts bezüglich der Kommunikation zwischen Stratux und EFB geändert.
Hast du per webinterface / update file aktualisiert oder das neue Image mit Etcher geschrieben?
Ggf. einfach nochmal probieren, geändert hat sich diesbezüglich wie gesagt eigentlich nichts.