I purchased the Flydata_io unit expecting it to mirror exactly what is on my mobile phone Safesky (which itself shows Safesky + Skyecho ADS-B data).
It seems to only show Safesky data from the network and not any locally received ADS-B track data.
Is this a bug or a design feature? If so, how do we request that all data shown in Safesky is shown on Flydata_io? Without this, once the mobile network drops which is frequent in the UK, Flydata_io is useless as it doesn’t show up any local Skyecho data.
TIA!
I will need to test this, I have a SkyEcho but never tried to have it connected to SafeSky, only used it “directly”, since my phone is android is quite tricky (sometimes it works, other times it does not) to have Wifi connected to SkyEcho and be able to access the internet via 4G/5G for the SafeSky App and not that much local air traffic in this region.
Just some remarks:
Check what is the Vertical Decluttering setting on the Display, if it’s set to “Show All” otherwise it filter based on relative altitude.
Is the “local” traffic you are seeing in the “radar” view or “map” view of SafeSky App? The views have different rule set… particularly the vertical decluttering setting on the SafeSky App, the one that should mirror the Display is the “Radar” view.
One other note, SafeSky App itself filters the traffic being sent to Display via BLE Connection, namely it filters aircraft by distance (up to a max of 47nm) and also by the Vertical Decluttering setting on the App (max of +/-5000ft).
I have seen an instance where “all” traffic shows up in radar view temporarily, if no internet connection is active, and we switch to “map” view and then switch to “radar” view all traffic (no matter the vertical decluttering set on the App) will show for around 30s before disappearing…
Hi, thanks for that. I think I managed to get it working….
Disable Bluetooth on the phone running the SafeSky app
Enable Wifi on the Flydata and connect to the Skyecho Wifi network
Connect the phone to the Wifi network, and use Speedify to allow SafeSky to also access mobile data
Ensure filtering is set correctly to avoid picking up airliners etc.
Observations:
This seems to work and I see ADS-B and SafeSky traffic on the Flydata
The selected track frequently changes, possibly when a track is lost from ADS-B, which makes the display kind of flash (see video for what I mean)
Even when I have Bluetooth enabled on the phone and Flydata is receiving data from it over BLE, the BLE config screen shows no connections…..this meant that the only way to stop Flydata getting BLE data was to disable Bluetooth on the phone, I couldn’t do it from Flydata itself.
If I connect to Wifi on Flydata but also leave Bluetooth on, I get flashing of the display, presumably because the device is receiving data from Safesky app over both BLE and Wifi at the same time.
In that “setup”, and if SafeSky app is configured to share traffic to third-party apps, the Display will receive traffic from two sources, from the SkyEcho (via Wi-Fi and GDL90 protocol) and also via SafeSky (Wi-Fi and GDL90 protocol). This can create some issues that the same aircraft (based on ICAO ID) can receive data from SkyEcho (updated, let’s say with position updated in last second) and will also receive information for that aircraft via Safesky that is also transmitting data via Wi-Fi and GDL90 protocol. This may lead to some data incoherencies since the Display will update the radar screen every second based on the last information it has received.
I don’t see any video attached. But one possible issue with this, is that depending on the Software configured on SafeSky App to share traffic, SafeSky may be sending the GPS message (on GDL90 protocol), and it may have different data (for example heading) than the one from SkyEcho, specially at low speeds / Stop.
Yes, the Bluetooth menu on the Display, is only for when the Display is the one that connects to a third-party device, like for example Aero-Tracker. When it’s connected to the smartphone (SafeSky App), it’s the Smartphone that connected to the Display and it will not show there.
If using Wi-Fi, you can go on SafeSky App to “External traffic device” and remove the FLYData display, that way the phone will not connect to the Display.
Yes, most likely. Not sure if the “effect” you are talking, is something similar to this one:
If it is this one, it can “more or less” be minimized by going to Display Settings → Config → Traffic/Alerts Data Source and select “others”. This will minimize that effect when in very low speeds / Stop since the “heading” is not updated is speed is considered too low, it assumes heading is 0º (North), in higher speed booth should have heading relatively equal since is supposed to be GPS based. Either way, this option should be enabled if not connected via BLE to SafeSky App in order for the Display process the alerts internally instead of relying on them be generated by SafeSky App (this only works via BLE).
In this scenario, where more than one “data source” may be connected to the Display, need to think in a way to avoid these situations, specifically a way to config/indicate the GPS source since this is probably the one with more oscillation between sources.
Here’s a video of what I see…look at VT, it jumps from left to right of the screen.
For clarity, I have
SafeSky sending data to SkyDemon.
FlyData on Wifi
SafeSky connected to SkyEcho
It’s a problem for an EC device as I can’t trust whether the track is ahead or behind me, or left or right of me.
The user story I’d like is this:
“As a pilot, in order to have an in-line-of-sight EC display, I want the FlyData to replicate exactly what is on the SafeSky app”.
The FlyData does not replicate what’s on the SakeSky app - the app doesn’t have this problem.
What I think we would really like is that SafeSky aggregates its network & SkyEcho tracks and sends them together to the FlyData over BLE. That would mean we don’t need to put the FlyData on the SkyEcho network and there would be a single source of truth for tracks (SafeSky).
At the moment it does seem that SkyEcho tracks are fighting with SafeSky tracks…but I’m unclear how they can be jumping around by as much as 8 miles…that suggests a fundemental issue rather than a slight mismatch in ownship position between SkyEcho and SafeSky.
Any thoughts?
Thanks, Dave
P.S I have upgraded to firmware 1.0.8 from 1.0.7 since this video was taken. Are there releases notes for the firmware releases?
I can’t attach a video for some reason as I’m a new user…here’s 2 screen grabs literally a few seconds second apart, you can see VT moves from about 5 miles west to 5 miles south (for around 3 seconds) and then flicks back to west.
From the screenshots, it seems that one of the sources is sending information regarding one of the targets in a non-coherent way (or some issue from Display side when decoding the data), the strange thing is only happening with GCMVT and not with GCMMY target.
Yes, i have to check this with Tristan on weather will do this when sending data to the Display via “BLE”
Yes, this is what i am imagining that is happening, the strange part is that was only happening to one of the targets and not to booth of them.
One question, when this “happened” you where on “ground” or “flying”? if on “Ground” does this happen when flying?
Regarding release notes, yes on the documentation website there is a page dedicated to release notes information: Release Notes | FlyData Products Page
Normally, for official “customers” only version ended with 0 are released, the other versions are normally for internal testing / Beta testers.
Was able to reproduce this (i am almost certain that I had tried this same setup a couple of weeks ago when I replied for the first time)…
In this case the setup was:
Safesky app on mobile phone connected to the same Wifi Network as the Display
Safesky App configured to send data to SkyDemon
Safesky App connected to Display via BLE
No SkyEcho (No battery… charging…)
In this case, the Display is receiving information (traffic and GPS Information) from two data sources (Wifi using GDL90 and BLE using NMEA), and again it is strange that it only happens to the “gliders” and not the “nearest” target.
By disabling the BLE connection between SafeSky and the Display (removing the Display from the external devices list), the behaviour stops happening and the position of the aircrafts on the Display matches the position on SafeSky App Radar view.
Will need to see in more detail what is being “transmitted” at the low level protocols that originates this sudden issue.
But wouldn’t disabling the BLE connection from SafeSky (i.e. removing FlyData from SafeSky devices list) mean that no “SafeSky” traffic would be displayed on the FlyData, and only ADS-B data from SkyEcho would be shown?
I was under the impression that GDL90 data was unicast from SafeSky to SkyDemon and wasn’t multicast out.
I just tried this…once I remove the FlyData device from the devices list in SafeSky I receive zero traffic on Flydata…the FlyData and SkyEcho are
Ok, I just tried this, and it’s working fine.
Phone:
Running Speedify to allow connection to mobile and Wifi at the same time
On SkyEcho Wifi network
SafeSky:
Sending tracks to SkyDemon
Not configured to send data to FlyData (i.e. FlyData not in devices list)
FlyData:
Connected to SkyEcho Wifi
This is great, thanks. Would suggest that the user guide is updated with this information - when I read the user guide the other week, it advises against using Wifi and recommends BLE. But where you want the totality of SkyEcho + SafeSky tracks on FlyData, Wifi seems essential!
Thanks for your help on this, I’ll see how it goes on my next flight and report any findings here.
If the Display is connected to the same Wifi Network than SkyEcho / Safesky / Skydemon, it should receive the information, unless GDL90 is not selected on the Wifi protocols:
But it should be enabled, otherwise the “issue” i saw at the moment would not make much sense.
From SkyEcho is multicast, from what i see/know it directly sends GDL90 data to any device that is connected to it’s access point.
From SafeSky APP (to other apps) it’s in Broadcast mode (at least is what i see on Wireshark on the PC connected to the same Wifi network as SafeSky phone).
In this scenario the Display should be receiving data from SkyEcho and Safesky, but since they are using the same protocol “GDL90” maybe things are correctly aligned.
This seems to be a common use case, have to check with SafeSky if all the traffic is or not sent via bluetooth and/or what filters are implemented. I know that at least a “vertical clearance” filter exists, not sure if others…
I will try and check what is the issue when receiving GDL90 and NMEA (via BLE) for the same targets, if it’s some incorrect interpretation on the Display side when decoding the data or some “bad” data that is being sent by possible SafeSky App.
I think i have found the issue on my side, it was an incorrect calculation when data was coming from GDL90 and NMEA at the same time, depending on the message arrival order between GDL90 and NMEA data.
At least in the scenario I was able to reproduce here, it’s no longer happening (Display connected via BLE to SafeSky App, and connected via WIFI to the same network as SafeSky app phone to receive data via WIFI GDL90).
Also tested having Display and phone connected to SkyEcho Wifi Network and the phone having 5G access, and it seems to be working ok, in this scenario there is a small issue with radar orientation when in ground mode that i need to think how to solve it.
If you want to try this new version, give me your Display serial number / WIFI MAC address (System - Device Information page) and I can push this version to the update server for your device.
