Garmin Pilot 10.6 Stratus-3-Emulation

[neckmann]

1. Stratux version: Stratux Europe Edition 1.6r1-eu027

2. Stratux config:

   SDR

   • [ ] single
   • [x] dual

   GPS

   • [x] yes
   • [ ] no type: U-Boxx

   AHRS

   • [x] yes
   • [ ] no

   power source:

   usb cable:

3. EFB app and version: Garmin Pilot 10.6.0.

   EFB platform: iOS 15.2

   EFB hardware: iPad Pro 11 Zoll 2021 Modell

4. Description of your issue:

Garmin Pilot offers in version 10.6 a way to connect with a Stratus 3 receiver. The data is exchanged in GDL90. Has anyone an idea how Stratux can be connected to this interface

If possible, enable "Replay Logs", reproduce the problem, and provide a copy of the logs in http://192.168.10.1/logs/stratux/ and http://192.168.10.1/logs/stratux.log.

[VirusPilot]

Just reactivated my Garmin Pilot App (30 day trial) and connected my Stratux with the iPad. Unfortunately when selecting Stratus 3 under "Devices", the App shows "not connected". Even tried various Stratux SSIDS as they are typically printed on the back side of the Stratus, no success. The Stratus AP runs in infrastructure mode, not sure if this helps. Also not sure about the subnet that Stratus creates, maybe someone knows. From another document it seems that Stratus sends UDP messages from 5 different ports signifying the message type: device status, GPS, UAT, AHRS, or 1090ES. So to summarize, we need more information about:

• Stratus WiFi subnet and SSID
• Stratus UDP ports

so that Stratux could be sending this particular Stratus configuration.

[neckmann]

In the meantime, I have gained access to a confidential document that contains the specification for the GDL90 protocol of the Stratus 3.

With the described IP address (10.29.39.1), Garmin Pilot recognizes the Stratux:

Unfortunately, Garmin Pilot loses the connection immediately, apparently more data is expected as a native GDL90.

The aforementioned document describes this specification.

How can we get in contact @VirusPilot, I can send you the document confidentially.

[neckmann]

The native GDL90 traffic data seems to be displayed correctly, but the connection ist not stable:

[wa9als]

Unsubscribing

[VirusPilot]

@neckmann Just sent you an email, sounds promising.

[hobiseven]

Hi folks, I expected garmin pilot to only accept garmin connext data, but from what I do read it seems that there is now a gdl90 input possible right? Connext is a ciphered based thing that so far nobody managed to understand.

[neckmann]

With the new Garmin Pilot version 10.6 is a GDL90 input possible, but not 100% stable with the current Stratux version. For example, GPS is currently not processed correctly and jumps back to the internal GPS.

It seems that Garmin has also implemented GDL90 in addition to GDL39 (Connect).

[hobiseven]

Ok clear. Gdl39 is different from connext. Gdl39 is for wired serial links and is a bit messy. Connext is more advanced and cleaner and for Bluetooth

[jeffdamp-wave]

I posted this in the slack channel but figured I would post here too: Per some info Adrian provided, I messed with the timings in gen_gdl90.go I was able to get it running pretty good in Garmin Pilot. You need to use the specific IP address. I'm still messing with AHRS as I'm not happy with the results there but if you want to try out what I have

You can modify gen_gld90.go starting at line 772:

func sendAllOwnshipInfo() {
    //log.Printf("Sending ownship info")
    sendGDL90(makeHeartbeat(), time.Second, -20) // Highest priority, always needs to be send because we use it to detect when a client becomes available
    sendGDL90(makeStratuxHeartbeat(), time.Second, 0)
    sendGDL90(makeStratuxStatus(), time.Second, 0)
    sendGDL90(makeFFIDMessage(), time.Second, 0)
    makeOwnshipGeometricAltitudeReport()
}

func heartBeatSender() {
    timer := time.NewTicker(20 * time.Millisecond) // reduced from 1 second down to 20ms
    timerMessageStats := time.NewTicker(2 * time.Second)
    ledBlinking := false
    ownershipTimer := time.NewTicker(500 * time.Millisecond) //added timer to fire the makeOwnershipReport

    for {
        select {
        case <-ownershipTimer.C:
            makeOwnshipReport() // moved from sendAllOwnershipInfo()
        case <-timer.C:

For AHRS I found it to have intermittent freezing in the "Navigation" screen. This screen is smooth using the Flight Simulator link (FS link has other issues). And with both GLD90 and Sim link Synthetic vision is laggy.
I noticed that sensors.go line 241 has this in it time.Sleep(950 * time.Millisecond) I'm not sure what this is for and why there is a big sleep here. I reduced this down to 20 and set the timer also to 20 and Navigation seems to be a lot smoother for me. I made this change while doing some other tweaks so could be something else. Synthetic vision still lags behind input but I think this is an issue with GP and not the data coming in. I don't have a Stratus 3 to test with. I didn't see any impact to Foreflight with these changes but YMMV.

[b3nn0]

That's roughly what @VirusPilot and me found out yesterday as well, but still with a few rough edges that we would like to figure out first ("GPS Data is Stale" warning, occasionally disappearing and reappearing traffic if traffic frequency is not increased a lot - 300ms seems to be enough). Note that you are now sending all traffic info every 20 milliseconds. That's quite a lot.. I don't think all EFBs would be able to keep up with that if there is a lot of traffic around and would just crash or something, at least on slower CPUs.

[jeffdamp-wave]

That's roughly what we @VirusPilot and me found

cool I'm glad you are actively working on it. I did add the test traffic and didn't see any issues. I'll move the traffic sender to the slower update interval. Could be what is causing the AHRS updates to be iffy.

[VirusPilot]

The strange warning "GPS data is stale" only goes completely away if both ownship & traffic report is increased beyond 10Hz but on the other hand that warning seems to have no negative impact on the traffic display. Therefore as @b3nn0 said, 5Hz works fine. For smaller update rates every few seconds some or even all targets disappear and come back again. Seems that the GP GDL90 implementation still need some improvement.

[neckmann]

Does anyone have a GDL90 decoder to check the output of the Stratux's data?

I can not imagine that a Stratus 3 sends data with more than 5Hz or 1Hz. This would contradict the Data Interface Specification.

Maybe it makes sense to make other protocols (xPlane, Flarm) deactivable (in UI), to improve the performance of the queue or data output.

[b3nn0]

Flarm doesn't cause anything as it's a TCP server, as long as nobody conencts to it, nothing happens. xplane is sent as very low data rate as long as ICMP Unreachable packets are received, i.e. always. The output frequency of Stratux seems fine. I think there is other stuff at play.. but don't have a Stratus to analyze what they are doing.

[VirusPilot]

Just to summarize where we are:

• the Stratux IP has to be set to 10.29.39.1
• GDL90 Ownship and Traffic report had to be increased to 10Hz (instead of 1Hz according to the spec) to get stable traffic display (see https://github.com/VirusPilot/stratux/commit/68bf9e09db5ef727d30f892f9d4de50633dca803) so it seems that Garmin's GDL90 implementation still has some issues

[jeffdamp-wave]

I spent a little time messing around with this today. I reviewed all of the specs available and compared to the code. I too couldn't get the "GPS data is stale" message to stay cleared. I put everything on separate timers and then removed all non-Stratus required messages. I then tweaked all the timer values but still no luck. I even implemented the Stratus status message 0x69 (battery, firmware info, etc.).

After making a bunch of timing tweaks, I got my code into a pretty good state other than the GPS stale message. GP connects to the Stratux fairly quickly. AHRS is pretty responsive (running at 20Hz) even synthetic vision seems reasonably responsive. Synthetic vision has really high latency when using the XPlane link.

One bummer is that for AHRS, GP is using the Foreflight message (0x65) and not the GDL90 message (0x4c). This means no advanced data like Yaw, Slip, VS, etc. :( Maybe some complaints to the GP support email might help.

For smaller update rates every few seconds some or even all targets disappear and come back again. Seems that the GP GDL90 implementation still need some improvement.

I've seen the vanishing ADS-B targets in GP when using the XPlane Link, for both simulator and with Stratux. In testing I found that the traffic looks good until your aircraft starts moving (GPS changes) and then all or some of the traffic targets will just vanish for a few seconds. I haven't seen this yet with the GDL90 (traffic updating at 2Hz) but it could be that I'm just not moving enough.

With the poor weather around here not sure when I'll be able to test out my changes for real. Maybe I'll code up a GDL90/Stratus version of fs2ff to test out more changes.

Do we have any reports from people using a real Stratus 3 with GP? This could just be GP issues we are fighting and nothing to do with missing any sort of secrete protocol message.

Perhaps if we can get multiple people sending mail to GPFeedback@garmin.com they might be more likely to fix things.

[b3nn0]

Please keep in mind that these are all "non-standard" changes that will make our GDL90 implementation non-conforming, potentially breaking compatibility with anything BUT GP. I will therefore not include these changes for the next version for now, and at least wait if they improve their implementation in the next version of GP, before jumping into action.

[jeffdamp-wave]

Please keep in mind that these are all "non-standard" changes that will make our GDL90 implementation non-conforming, potentially breaking compatibility with anything BUT GP. I will therefore not include these changes for the next version for now, and at least wait if they improve their implementation in the next version of GP, before jumping into action.

Totally agree. Worst case we could add a switch in the UI that allows to turn on Stratus 3 emulation.

[jeffdamp-wave]

So I made a fork of @b3nn0 \stratux and created a dev mode switch that allows for turning on emulation of said GLD90 device. Flipping the switch, changes the packet rates, updates the AP IP address, and sends additional GDL90 messages. Because it is WIP, when in emulation mode, I don't send any other message types to eliminate noise. If the switch isn't set, then the Stratux acts just like it did before. Would this be worth created a PR for the changes? Seems to work reasonably well for me once connected I'm not seeing the stale GPS messages. I probably won't be testing it in a plane until after the first of the year. I also don't want to cause any problems with the device manufacturer that I emulated ;)

[b3nn0]

For now, I'd rather wait for the next version of GP and see if they improve their stuff. I'm not planning to do a release any time soon anyway, so merging that now just to roll back later if they fix their stuff doesn't feel practical.

[neckmann]

GarminPilot 10.6.1 is out; no improvement on the „GPS data is stale“ Message with my setup.

[jeffdamp-wave]

GarminPilot 10.6.1 is out; no improvement on the „GPS data is stale“ Message with my setup.

@neckmann if you want to give my build a try, have at it: https://github.com/jeffdamp-wave/stratux.git (master branch) You will need enable dev mode (8 fast clicks on version) then find the switch for Stratus 3 emulation. I don't get the stale message, after it is fully connected but YMMV. I'm doing my testing on an iPad Mini (5th gen). I haven't tested the traffic rate with the new GP build but will do that tomorrow.

[VirusPilot]

Jeff, all, I reached out to Garmin Germany - no response, so let's reach out to GPFeedback@garmin.com.

[neckmann]

@jeffdamp-wave thank you, it works

At the same time I have very good news, I found (to 99% save) the bug in Garminpilot. It seems that GarminPilot does not properly dissolve two GDL90 messages in a UDP data packet.

As an an example: UDP-Data: 7e 0a ... (Ownship Report) ... 7e 7e 14 ... (Traffic Report) ... 7e triggers the "GPS data is Stale" error.

Every GDL90 message in its own UDP package solves the problem, here would be a switch for a „GarminPilotMode“ useful. Other changes from the GDL standard are not necessary (Ownship and AHRS with 5Hz are necessary)

[b3nn0]

That's an interesting observation - seems to be the first EFB to implement it like that..

I don't have an iOS device, so I can't really test myself, but my suggestion would be:

If the IP Address == "10.29.39.1":
- Send ownship report at 5Hz
- in clientconnection.go, return 1 from networkConnection.GetDesiredPacketSize()

The latter will make sure that only one GDL90 packet will be sent per datagram.

We can then document the "Legacy/Stratus Compatibility for Garmin Pilot ity by setting the IP Address accordingly" in the Wiki. Would someone want to test this and make a PR for it?

[cyoung]

Every GDL90 message in its own UDP package solves the problem

Just for some context, we originally sent GDL90 messages this way but started combining them to deal with areas with a large number of traffic targets. Either ForeFlight or the EDIMAX WiFi controller that we used at the time was unable to cope with the high packet rate and this would cause disconnects. There is a traffic simulator in the code which we used to debug it. If you chose to send single packets for each GDL90 message, make sure you smoke test it with a high packet rate.

[hobiseven]

Hi Makes me think to garmin695 which has a target limitation set to 30. Gdl39 protocol has a low bandwidth with 56k serial, and each traffic entry being about 150 bytes before zcompress.

would garmin pilot have also such low target tracking capabilities, meaning that stratux might send way too many targets? do you sort targets based on distance and only send the X ones closest ?

[b3nn0]

@cyoung That's why I'd only do it like that if we know we are targeting GP (=IP is set to 10.29.39.1) @hobiseven There is priorization in the latest version, sorting transmitted datagrams by importance (including nearby traffic before far away traffic). However, this is only really relevant if the network stack can't keep up (which probably won't happen very often), or for slow serial connections/low baud rates. I wouldn't expect this to be an issue with GP though. But let's solve that if the issue comes up, not beforehand.

[VirusPilot]

With this simple change it appears to be rock solid, even with both traffic and ownship @ 1Hz. I have it running now for 20min without a single GPS stale message. It seems that GP can handle 1Hz although under "Devices" it still shows "GPS and AHRS Update Frequency 5Hz" so I assume this not based on a measured frequency rather then based on the Stratus 3 capability.

[VirusPilot]

@jeffdamp-wave thank you, it works

At the same time I have very good news, I found (to 99% save) the bug in Garminpilot. It seems that GarminPilot does not properly dissolve two GDL90 messages in a UDP data packet.

As an an example: UDP-Data: 7e 0a ... (Ownship Report) ... 7e 7e 14 ... (Traffic Report) ... 7e triggers the "GPS data is Stale" error.

Every GDL90 message in its own UDP package solves the problem, here would be a switch for a „GarminPilotMode“ useful. Other changes from the GDL standard are not necessary (Ownship and AHRS with 5Hz are necessary)

Shouldn't we better ask Garmin to fix it instead of sending every GDL90 message in its own UDP package?

[hobiseven]

@b3nn0 Fair point… stepping back a bit 30 targets is quite a lot for adsb, to get a practical use in flight If you have flarm activated you might actually get there fast … ( if gliders competitions are like paraglider ones, you get to 100 instantly!) You might need to implement a 30 targets limit soon… ;-)

[kdknigga]

You want to ask Garmin to fix something unsupported?

On Tue, Dec 28, 2021 at 10:34 AM VirusPilot @.***> wrote:

@jeffdamp-wave https://github.com/jeffdamp-wave thank you, it works

At the same time I have very good news, I found (to 99% save) the bug in Garminpilot. It seems that GarminPilot does not properly dissolve two GDL90 messages in a UDP data packet.

As an an example: UDP-Data: 7e 0a ... (Ownship Report) ... 7e 7e 14 ... (Traffic Report) ... 7e triggers the "GPS data is Stale" error.

Every GDL90 message in its own UDP package solves the problem, here would be a switch for a „GarminPilotMode“ useful. Other changes from the GDL standard are not necessary (Ownship and AHRS with 5Hz are necessary)

Shouldn't we better ask Garmin to fix it instead of sending every GDL90 message in its own UDP package?

— Reply to this email directly, view it on GitHub https://github.com/cyoung/stratux/issues/846#issuecomment-1002187209, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADJX7QASDEDZQJTGQC2PL5DUTHRHZANCNFSM5KDBGSOA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[jeffdamp-wave]

AAHHHHH so much makes sense now, like why changing the priority on some of the sends made it more stable. I had no idea that the network stack was combining the sends, I thought it was just a queue order. I guess I should have looked closer. it would have been one of the first things I tried. I do like some of the other changes I made so I think I'll switch on the single package flag and then start tweaking the timings. Due to higher network load I think it might still be worth shutting off all other traffic sends while in the Stratus mode. I guess I just continue with my own branch ;)

What about the vanishing traffic when below 5Hz? Has this been tested yet? I've been out all day but might play with that setting a bit too.

I think we should come up with some sort of messaging to Garmin and all send mail to gpfeedback.

1. allow for GDL90 packet combining.
2. Listen for the standard GDL90 AHRS message in addition to the foreflight AHRS message.
3. Ideally they would just support GDL90 spec and just have a generic GDL90 device to select from.

[VirusPilot]

So here is my summary since yesterday:

1. one GDL90 message per UDP package solves most of the issues, @b3nn0 has already pushed a commit
2. with ownship@5Hz and traffic@1Hz GP connects fine (almost) every time
3. @cyoung: I activated the traffic simulator - no issues in my setup

wrt. (2) it might make sense to also send the Appareo Status Message, @jeffdamp-wave, can you point me to your code which adds this message so that I can further test this? If this resolves those rare cases where my GP does not connect, then we might have a good solution, @b3nn0 could introduce all those Stratus 3 related modifications in the same way he already did (if globalSettings.WiFiIPAddress == "10.29.39.1").

[VirusPilot]

Couldn't resolve those (rare) cases where GP won't connect, even with adding the Appareo Status Message. So for now I give up and just use 2Hz for traffic and 5Hz for ownship, this is 100% stable (even with 100 artificial targets enabled). For my own entertainment I am using the Status message now for some GPS data.

[jeffdamp-wave]

@VirusPilot, I was mucking with timing values yesterday and found that setting a latency on the stratus status message at 800ms and having its priority at -20 seems to address connectivity issues. It can still take up to 30 seconds for the AHRS and GPS to lock in but with that setup I don't get into a state where the GP doesn't connect.

As far as traffic I found that Garmin Pilot will crash when using synthetic vision with more than 70 fake traffic targets. Did you test with synthetic vision? Up until GP crashes SV seems to preform very well even a little more responsive than foreflight. There are a few changes you might want to look at too.

1. I wrapped the demo traffic code around an if statement (instead of needing to comment it in/out) and added an input box in the dev settings section.
2. I use a toggle switch for enabling the stratus mode instead of trying to remember the IP address and set that.
3. Oh and I made the multi-click dev mode a toggle and not a one-way trip ;)

[VirusPilot]

@jeffdamp-wave I actually did not test synthetic vision, will do early next week.

[VirusPilot]

A few days ago I reached out to GPFeedback@garmin.com, now they responded. They are very interested in expanding the GDL 90 integration with GP to include Stratux and they have recently purchased a device for development and testing purposes. So far good news, we can stop guessing and wait for their findings.

[jeffdamp-wave]

@VirusPilot, Did you ever here anything more for GP support on them supporting Stratux?

Started back flying again. Did a X-Country using my changes a couple of days ago, had no issues. Today I was doing simulated instrument flying in a very busy airspace. Any time I fired up synthetic vision, Garmin Pilot would crash like it did with the simulated traffic. Didn't seem to matter if I turned on limit traffic in the GP UI. I did send a bug report to GP support. What I might need to do is have a setting on the Stratux That limits the traffic targets down to a max number using the weighting system. Hopefully GP will fix the bug on their end.

[VirusPilot]

@jeffdamp-wave Garmin promised another build which has not been released yet.

[jeffdamp-wave]

Hopefully they are going to use the GDL90 AHRS protocol and not FF implementation

[jeffdamp-wave]

The Statux version just dropped for Ipad. I haven't done much testing. Synthetic Vision is way to laggy to be usable. GP seems to be using the FF AHRS message instead of the GDL90 message. Will need to turn off the FF AHRS message to verify. I'm using a Stratux build that I modified so maybe I'll got back to a clean build and see if that makes any difference.

[jeffdamp-wave]

Spent a little time playing with the new GP 10.7.1 Works OK but needs some tweaking:

Stratux side - Ownership rate of 1Hz is making Synthetic vision very laggy. 5hz should be minimum. 10hz felt good and not much difference than 20hz. Set at 10hz though GP doesn't display 10hz instead it bounces between 5hz and 20hz (odd). I'm running a ublox8 GPS which has a best rate of 18hz not sure if the Stratux is getting max throughput on it.

GP side - GP is using the GDL90 AHRS message and not the FF AHRS but they don't use the skid/slip (and other info) from the GDL90 message seems like a miss on their part. I might contact them about it. They could also get more data from the StratuxStatus message like temperature but not a big deal.

On the upside - no need to do any sort of IP trickery just connect to the Stratux and your good to go. I verified they are handling multiple messages per packet correctly. They have also fixed the more than 70 ADS-B targets causing a crash while using SV. I still need to test if traffic updates need to be set <= 900ms to prevent blinking traffic.