We have this old thread for the bluetooth route.
But there is also a wifi route – a GDL90 UDP broadcast on port 4000; specifically GDL90 Stratux. That has an issue in that the track is encoded 0-255 so looks funny a lot of the time; 1 degree rounding error is very visible. Digging around, I see that ForeFlight defines a GDL90 extended protocol with custom messages containing additional device information which solves this problem. That is for FF only.
I also find that IOS now supports bluetooth BLE but still not NMEA. But FF does not work with this. So there is no point in bothering with bluetooth at all.
I am looking at a project which needs to feed both OSs, and work with EasyVFR, SD and FF.
One issue is that it needs to co-exist with the Golze ADL wifi output, which does not only position but sends out (using some proprietary stream) the weather data and the flight plan.
What are the options?
I think Dynon is someone to look out for more and more. They have this:
https://dynonavionics.com/skyview-wifi-adapter.php
Stratux outputs position and traffic also via BLE which works better than wifi, with SkyDemon, in my experience.
Peter wrote:
I am looking at a project which needs to feed both OSs, and work with EasyVFR, SD and FF.
FF can receive GPS via Connext, which would normally only work over Bluetooth. You can try it with your Aera 660. Not sure what you’re trying to achieve, though.
I am working on a little project. I am looking simply for a way to emit GPS position such that the above apps and platforms can use it.
Bluetooth would probably be better. One thinks of it as unreliable (and BT often works only every 2nd day 
) but I find wifi troublesome too with the Ipad.
I have solved the method for loading the flight plan into the Aera660 here. But it is a fair point: if my project can feed GPS position to the 660 also, that would be interesting. The 660 has an internal GPS which is very good, and the various tablets also have GPSs (of varying performance) but I am looking at providing another source.
Peter wrote:
I am working on a little project. I am looking simply for a way to emit GPS position such that the above apps and platforms can use it.
I think that if the list of apps is as it stands, you’re limited to GDL90. I’m looking at Connext since a couple of days (and independently of that, the Stratux people have been looking at it for years and apparently have now made major progress), so in the future, this might become an option.
Great – thanks.
It might be interesting to also look at the GDL90 “FF format” to eliminate the 1-2 degree track error, but my project is emitting just position, no track info. Actually I am not so sure now… does a satnav app generate the track from the progressive GPS location, or does it use the GPS track? I think it must use the latter, which is why you get that ex GDL90 track error.
Peter wrote:
It might be interesting to also look at the GDL90 “FF format” to eliminate the 1-2 degree track error, but my project is emitting just position, no track info.
Sure, a number of EFBs would be happy to integrate support for Sentry, but it’s quite an annoying thing to do.
Basically, you need to root your iPad (no big deal) and then install Frida. This way, you can debug FF and, together with some analysis using IDA, you can figure out how they parse their proprietary verbs. It’s a huge time sink if you aren’t doing it for a living (I’m not, and actually, I have no clue), and a license for IDA costs a fortune. So no wonder there hasn’t been much done on that so far…
Or you could kidnap someone from uAvionix and torture them until they reveal all their dirty secrets.
Or you could kidnap someone from uAvionix and torture them until they reveal all their dirty secrets.
Like why they didn‘t put two resistors into the Sentry so it charges on USB-C even though it has a USB-C port? 😂
It might be interesting to also look at the GDL90 “FF format” to eliminate the 1-2 degree track error
I wrote the above but actually this is nonsense 
Both variants of GDL90 (the broadcast one, or the FF/Ipad unicast one) use 0-255 for the 0-359 track angle.
So I am not at all sure what is the point of the FF unicast one, other than that FF state they prefer it in the link in this post. It cannot feed more than one device concurrently – unless the transmitter maintains a separate GDL90 UDP stream for each device to which it has allocated (using its DHCP server) a unique IP.
