Foreflight Alternatives? Which EFB should I switch to?

[0TreeLemur]

7 minutes ago, PT20J said:

What are measured winds?

From sondes?

I know the models ingest sonde data when they spin them up.

[PeteMc]

4 hours ago, takair said:

but you can see that the winds and the plan winds are essentially opposite of each other.

And what happened after you Packed and updated the Winds?

 

[takair]

4 hours ago, PeteMc said:

And what happened after you Packed and updated the Winds?

 

Same…didn’t change.  The artifact with the departure time is odd too and may have played into the problem.  My subscription had just auto renewed….I wonder if that does anything…resets some clock?   It was working fine last night though….so I must have tripped some corner case bug in the morning.  I think the real winds were headwinds.  I didn’t actually do the flight, my partner in the C140 was flying and I was trying to get some speed numbers.  The Foreflight bug tripped that up….

[takair]

I just re-entered the same flight again.  Same issue.  The ETD changes to 10:50pm.  I can’t change the time, except to NOW.  Also, the winds are doing the same thing…no matter what I do.  I have never seen this issue before yesterday.

[dzeleski]

9 hours ago, PT20J said:

What are measured winds?

It’s done via balloons every handful of hours.

https://www.weather.gov/rah/virtualtourballoon

https://en.m.wikipedia.org/wiki/Weather_balloon

Edited February 8 by dzeleski

[EricJ]

2 hours ago, dzeleski said:

It’s done via balloons every handful of hours.

https://www.weather.gov/rah/virtualtourballoon

https://en.m.wikipedia.org/wiki/Weather_balloon

There's also air data collected from airliners and other aircraft via ACARS that gets put into the system.

https://en.wikipedia.org/wiki/Aircraft_Meteorological_Data_Relay

 

[0TreeLemur]

Another follow-up:

In my deep dive into this problem I learned something about why the GDL90 standard is not universally supported.   Garmin developed this standard and it includes lots of information latitude, longitude, ground speed, heading, VSI, and pressure altitude, true altitude, gps altitude, etc., but there is no assurance that all outputs will be provided.  Some ADS-B "in" boxes don't output the true (msl) altitude or the information needed to calculate it.   Some manufactures of ADS-B "in" boxes chose to report altitude relative the the WGS84 ellipsoid, but not relative to msl.  This explains why some manufacturers of displays or EFB's are unwilling to adopt it as an open standard.

The problem arises if the app/device processing/displaying an incomplete GDL90 data stream doesn't know either the barometer setting or the pressure altitude, it cannot show the correct elevation difference between ownship and ADS-B targets.   It can be off by as much as the difference between true and pressure altitude on any given day.

The Garmin GDL90 standard is really complete.  Too bad it isn't fully implemented by some manufacturers.  If you are interested, here's an example of what is included in the standard if fully implemented, including AHRS outputs (source: https://github.com/cyoung/stratux/blob/master/notes/app-vendor-integration.md)

{
  "GPSLastFixSinceMidnightUTC": 67337.6,
  "GPSLatitude": 39.108533,
  "GPSLongitude": -76.770862,
  "GPSFixQuality": 2,
  "GPSHeightAboveEllipsoid": 115.51,
  "GPSGeoidSep": -17.523,
  "GPSSatellites": 5,
  "GPSSatellitesTracked": 11,
  "GPSSatellitesSeen": 8,
  "GPSHorizontalAccuracy": 10.2,
  "GPSNACp": 9,
  "GPSAltitudeMSL": 170.10767,
  "GPSVerticalAccuracy": 8,
  "GPSVerticalSpeed": -0.6135171,
  "GPSLastFixLocalTime": "0001-01-01T00:06:44.24Z",
  "GPSTrueCourse": 0,
  "GPSTurnRate": 0,
  "GPSGroundSpeed": 0.77598433056951,
  "GPSLastGroundTrackTime": "0001-01-01T00:06:44.24Z",
  "GPSTime": "2017-09-26T18:42:17Z",
  "GPSLastGPSTimeStratuxTime": "0001-01-01T00:06:43.65Z",
  "GPSLastValidNMEAMessageTime": "0001-01-01T00:06:44.24Z",
  "GPSLastValidNMEAMessage": "$PUBX,04,184426.00,260917,240266.00,1968,18,-177618,-952.368,21*1A",
  "GPSPositionSampleRate": 0,
  "BaroTemperature": 37.02,
  "BaroPressureAltitude": 153.32,
  "BaroVerticalSpeed": 1.3123479,
  "BaroLastMeasurementTime": "0001-01-01T00:06:44.23Z",
  "AHRSPitch": -0.97934145732801,                     // Degrees. 3276.7 = Invalid.
  "AHRSRoll": -2.2013729217108,                       // Degrees. 3276.7 = Invalid.
  "AHRSGyroHeading": 187741.08073052,                 // Degrees. Process mod 360. 3276.7 = Invalid.
  "AHRSMagHeading": 3276.7,                           // Degrees. Process mod 360. 3276.7 = Invalid.
  "AHRSSlipSkid": 0.52267604604907,                   // Degrees. 3276.7 = Invalid.
  "AHRSTurnRate": 3276.7,                             // Degrees per second. 3276.7 = Invalid.
  "AHRSGLoad": 0.99847599584255,                      // Current G load, in G's. Reads 1 G at rest.
  "AHRSGLoadMin": 0.99815989027411,                   // Minimum recorded G load, in G's.
  "AHRSGLoadMax": 1.0043409597397,                    // Maximum recorded G load, in G's.
  "AHRSLastAttitudeTime": "0001-01-01T00:06:44.28Z",  // Stratux clock ticks since last attitude update. Reference against /getStatus -> UptimeClock.
  "AHRSStatus": 7                                     // Status bitmask. See main/sensors.go -> updateAHRSStatus().
}

 

Edited February 8 by 0TreeLemur
detail (lots of it)

[PT20J]

Had that problem years ago when everyone copied Dennis Hayes’ smart modem. Every modem we tried to interface with used a different subset of the command set and widely different timing from command to response. 

[PeteMc]

7 hours ago, takair said:

I just re-entered the same flight again.  Same issue.

Give us the specifics of the Route, Altitude, times, etc.  And EXACTLY how you did you enter it?   Did you start in Flights or on the Map?  If the Map did you send it to Flights for the Briefing and then back to the Map?  Let's see if we can duplicate it on another iPad/Account.  And a screen shot of the anomalies if they are still there.

 

[PeteMc]

7 hours ago, dzeleski said:

It’s done via balloons every handful of hours.

Skew-T Log-P Diagrams use the balloon data as well as some other observations.

 

[Fly Boomer]

16 hours ago, PT20J said:

Once a bug gets logged, engineering has the ball for determining the severity, and when it will get resolved and what release it goes in to. It may be months and it’s just not feasible to keep the user that reported the bug updated.

And typically no customer-facing communication function within Engineering.

[EricJ]

4 hours ago, 0TreeLemur said:

Another follow-up:

In my deep dive into this problem I learned something about why the GDL90 standard is not universally supported.   Garmin developed this standard and it includes lots of information latitude, longitude, ground speed, heading, VSI, and pressure altitude, true altitude, gps altitude, etc., but there is no assurance that all outputs will be provided.  Some ADS-B "in" boxes don't output the true (msl) altitude or the information needed to calculate it.   Some manufactures of ADS-B "in" boxes chose to report altitude relative the the WGS84 ellipsoid, but not relative to msl.  This explains why some manufacturers of displays or EFB's are unwilling to adopt it as an open standard.

The problem arises if the app/device processing/displaying an incomplete GDL90 data stream doesn't know either the barometer setting or the pressure altitude, it cannot show the correct elevation difference between ownship and ADS-B targets.   It can be off by as much as the difference between true and pressure altitude on any given day.

The Garmin GDL90 standard is really complete.  Too bad it isn't fully implemented by some manufacturers.  If you are interested, here's an example of what is included in the standard if fully implemented, including AHRS outputs (source: https://github.com/cyoung/stratux/blob/master/notes/app-vendor-integration.md)

{
  "GPSLastFixSinceMidnightUTC": 67337.6,
  "GPSLatitude": 39.108533,
  "GPSLongitude": -76.770862,
  "GPSFixQuality": 2,
  "GPSHeightAboveEllipsoid": 115.51,
  "GPSGeoidSep": -17.523,
  "GPSSatellites": 5,
  "GPSSatellitesTracked": 11,
  "GPSSatellitesSeen": 8,
  "GPSHorizontalAccuracy": 10.2,
  "GPSNACp": 9,
  "GPSAltitudeMSL": 170.10767,
  "GPSVerticalAccuracy": 8,
  "GPSVerticalSpeed": -0.6135171,
  "GPSLastFixLocalTime": "0001-01-01T00:06:44.24Z",
  "GPSTrueCourse": 0,
  "GPSTurnRate": 0,
  "GPSGroundSpeed": 0.77598433056951,
  "GPSLastGroundTrackTime": "0001-01-01T00:06:44.24Z",
  "GPSTime": "2017-09-26T18:42:17Z",
  "GPSLastGPSTimeStratuxTime": "0001-01-01T00:06:43.65Z",
  "GPSLastValidNMEAMessageTime": "0001-01-01T00:06:44.24Z",
  "GPSLastValidNMEAMessage": "$PUBX,04,184426.00,260917,240266.00,1968,18,-177618,-952.368,21*1A",
  "GPSPositionSampleRate": 0,
  "BaroTemperature": 37.02,
  "BaroPressureAltitude": 153.32,
  "BaroVerticalSpeed": 1.3123479,
  "BaroLastMeasurementTime": "0001-01-01T00:06:44.23Z",
  "AHRSPitch": -0.97934145732801,                     // Degrees. 3276.7 = Invalid.
  "AHRSRoll": -2.2013729217108,                       // Degrees. 3276.7 = Invalid.
  "AHRSGyroHeading": 187741.08073052,                 // Degrees. Process mod 360. 3276.7 = Invalid.
  "AHRSMagHeading": 3276.7,                           // Degrees. Process mod 360. 3276.7 = Invalid.
  "AHRSSlipSkid": 0.52267604604907,                   // Degrees. 3276.7 = Invalid.
  "AHRSTurnRate": 3276.7,                             // Degrees per second. 3276.7 = Invalid.
  "AHRSGLoad": 0.99847599584255,                      // Current G load, in G's. Reads 1 G at rest.
  "AHRSGLoadMin": 0.99815989027411,                   // Minimum recorded G load, in G's.
  "AHRSGLoadMax": 1.0043409597397,                    // Maximum recorded G load, in G's.
  "AHRSLastAttitudeTime": "0001-01-01T00:06:44.28Z",  // Stratux clock ticks since last attitude update. Reference against /getStatus -> UptimeClock.
  "AHRSStatus": 7                                     // Status bitmask. See main/sensors.go -> updateAHRSStatus().
}

 

I just lived through some of this as part of the development of a gadget for a search and rescue application, where I had to interface with a GPS receiver in order to determine the location, bearing, etc., of the search vehicle and make an estimate of the relative search target location based on other inputs.   There are various GPS interface libraries (e.g., gpsd) that are there to help do this, but I got warned off by other developers that pain lies down that path.   I was nevertheless tempted by the promises of flexibility, interoperability, and data enhancement and foolishly attempted that route in the hopes of shortened development time and glorious performance results.   The warnings of the previous developers unheeded, I ultimately succumbed to the reality that pain was, in fact, my fate for yielding to temptation.   I ultimately took the advice of the battered veterans and reverted to simply parsing the NMEA sentences that nearly all GPS receivers generate natively in compliance to relevant standards.

However, even the standardized NMEA sentences can be subject to differences in different implementations, which includes how they report the various estimated altitudes.   The NMEA GGA frames include two different altitude metrics:   height above geoid (often referred to as GPS MSL), and, as you mention, Height Above Ellipsoid, using the WGS84 ellipsoid model.   The sum of the two provides what is arguably the best estimate of MSL comparable to what one would see on an altimeter.   There is also some confusion on what ellipsoid model is used in particular implementations, and what might ultimately provide the "best" (whatever that means) reported altitude for a particular application.   Fortunately I didn't need to dive too deep as altitude wasn't a key metric in our application.

There is also some variability in implementation of reporting of magnetic variation in GPS NMEA outputs, and in our testing we found that most implementations just don't report it.   I found a particular model of a relatively inexpensive Garmin USB GPS receiver that does, but it was the only one I found that did.   Since that was important to our application it meant either having to only use that receiver (or particular receivers known to report magnetic variation) or do something else.   We elected to implement the NOAA World Magnetic Model computation of variation from raw GPS lat/lon/alt, so that any GPS receiver could be used.   In doing so we found that the magnetic variation reported by the Garmin device didn't match with the NOAA WMM models, so using the WMM model was probably a good move, anyway.

So, yeah, this stuff is frought with minefields where you would not expect them to be, and I am sympathetic to anybody who has to develop with this stuff.   Reconciling pressure altitude, GPS MSL, and GPS MSL+HAE with "true altitude" is difficult when all of them are estimates.   Altitude is the least accurate GPS estimate, and the barometric Kollsman window setting to adjust from pressure altitude is not automated anywhere that I know of, so is subject to however recent and accurate the last setting was.   Some ADS-B devices may not report data if it isn't available to them (e.g., not all GPS devices report Height Above Ellipsoid, so they can't forward it if they don't get it).   Also, GPS receivers that normally report HAE or other altitude metrics won't if there aren't enough satellites available for the computation.   You need one more satellite to compute altitude than you do to compute lat/lon, so even if the receiver is reporting lat/lon, it may not report altitude.  An ADS-B unit can't forward it if doesn't get it.   It may not be an issue of whether everybody is fully implementing GDL-90, but whether the data is just always available or not or available with particular equipment.

Long-winded response, but I only just went through this in the last few weeks, so it's still fresh on my mind.

[takair]

1 hour ago, PeteMc said:

Give us the specifics of the Route, Altitude, times, etc.  And EXACTLY how you did you enter it?   Did you start in Flights or on the Map?  If the Map did you send it to Flights for the Briefing and then back to the Map?  Let's see if we can duplicate it on another iPad/Account.  And a screen shot of the anomalies if they are still there.

 

I had two screen shots in an earlier post.  On the map page, I cleared the flight plan in the Edit tab and entered KOXC KMHT.  I looked at the time to destination and winds on the page and then simply clicked on the altitude tab to adjust the altitude.  I do this to look at winds aloft and optimize. This is when I noticed the disparity.  Been using ForeFlight for years and never had this happen.

[Ragsf15e]

17 hours ago, PT20J said:

What are measured winds?

You should fly over Spokane sometime when they launch them.  Maybe every 8-12 hours or so?  ATC issues a warning,

“Be advised, uncontrolled balloon launch approximately 5 miles north of Spokane airport, surface and above.”  

Then they proceed to vector you right near there.  I’ve never see the actual balloon, but I think it would be very exciting to find it in a cloud someday!  There doesn’t seem to be any kind of deconfliction, especially if you were vfr over top of the class C minding your own business.

[PeteMc]

3 hours ago, Ragsf15e said:

You should fly over Spokane sometime when they launch them.

I believe they launch at 1100z and 2300z every day.  There is some sort of permanent NOTAM, but it is not published with the regular ones, so we don't see it. 

Also supposed to be an arrangement with Spokane ATC to keep people out of the area, which is not really very big.  No clue if they enlarge or elongate the area if there are really strong winds. 

Actually wonder if they can see it on their Primary Radar so they know where they can and can't send you?

 

Edited February 9 by PeteMc

[FlyingDude]

For what it’s worth, i don’t always use a tablet but when I do, I use Fltplan which is completely free. I discontinued Garmin Pilot subscription after I couldn’t justify another 150$/y on top of the ~450$ (oshkosh deals, mind you!) spent on 430w and 696…

[0TreeLemur]

On 2/8/2024 at 3:42 PM, EricJ said:

I just lived through some of this as part of the development of a gadget for a search and rescue application, where I had to interface with a GPS receiver in order to determine the location, bearing, etc., of the search vehicle and make an estimate of the relative search target location based on other inputs.   There are various GPS interface libraries (e.g., gpsd) that are there to help do this, but I got warned off by other developers that pain lies down that path.   I was nevertheless tempted by the promises of flexibility, interoperability, and data enhancement and foolishly attempted that route in the hopes of shortened development time and glorious performance results.   The warnings of the previous developers unheeded, I ultimately succumbed to the reality that pain was, in fact, my fate for yielding to temptation.   I ultimately took the advice of the battered veterans and reverted to simply parsing the NMEA sentences that nearly all GPS receivers generate natively in compliance to relevant standards.

However, even the standardized NMEA sentences can be subject to differences in different implementations, which includes how they report the various estimated altitudes.   The NMEA GGA frames include two different altitude metrics:   height above geoid (often referred to as GPS MSL), and, as you mention, Height Above Ellipsoid, using the WGS84 ellipsoid model.   The sum of the two provides what is arguably the best estimate of MSL comparable to what one would see on an altimeter.   There is also some confusion on what ellipsoid model is used in particular implementations, and what might ultimately provide the "best" (whatever that means) reported altitude for a particular application.   Fortunately I didn't need to dive too deep as altitude wasn't a key metric in our application.

There is also some variability in implementation of reporting of magnetic variation in GPS NMEA outputs, and in our testing we found that most implementations just don't report it.   I found a particular model of a relatively inexpensive Garmin USB GPS receiver that does, but it was the only one I found that did.   Since that was important to our application it meant either having to only use that receiver (or particular receivers known to report magnetic variation) or do something else.   We elected to implement the NOAA World Magnetic Model computation of variation from raw GPS lat/lon/alt, so that any GPS receiver could be used.   In doing so we found that the magnetic variation reported by the Garmin device didn't match with the NOAA WMM models, so using the WMM model was probably a good move, anyway.

So, yeah, this stuff is frought with minefields where you would not expect them to be, and I am sympathetic to anybody who has to develop with this stuff.   Reconciling pressure altitude, GPS MSL, and GPS MSL+HAE with "true altitude" is difficult when all of them are estimates.   Altitude is the least accurate GPS estimate, and the barometric Kollsman window setting to adjust from pressure altitude is not automated anywhere that I know of, so is subject to however recent and accurate the last setting was.   Some ADS-B devices may not report data if it isn't available to them (e.g., not all GPS devices report Height Above Ellipsoid, so they can't forward it if they don't get it).   Also, GPS receivers that normally report HAE or other altitude metrics won't if there aren't enough satellites available for the computation.   You need one more satellite to compute altitude than you do to compute lat/lon, so even if the receiver is reporting lat/lon, it may not report altitude.  An ADS-B unit can't forward it if doesn't get it.   It may not be an issue of whether everybody is fully implementing GDL-90, but whether the data is just always available or not or available with particular equipment.

Long-winded response, but I only just went through this in the last few weeks, so it's still fresh on my mind.

Thanks Eric.  I know well the disappointment involved in taking the theoretically sensible path only to find that is a slippery mud pit.  I tested the iPad/Stratus GDL90 combination again this Friday evening after pulling the plane out of the hangar and powering everything up.  There were lots of planes flying around the airport so I got a good test in.  Oddly enough, traffic display was more reliable on the IFD-540 than on FF! 

I've read that receivers re-broadcasting ADS-B data using the GDL-90 standard do so using UDP on port 4000.  This makes me think that somehow my iPad is dropping more UDP packets than the IFD.  Aside from FF trying to get me to switch to ForeFlight mode for the connection to the stratus, my iPad required several restarts of FF to get a reliable connection while hitting "cancel" at each restart to keep the stratus in Open ADS-B mode.  Something fishy going on here it seems with either FF or the iPad itself.

My problem seems to be solved.  I just really want the traffic to appear of the IFD because it is in my scan, and I use the iPad exclusively to view maps/charts.  That seems to be working for now.  Fingers crossed.

[PeteMc]

3 hours ago, 0TreeLemur said:

Oddly enough, traffic display was more reliable on the IFD-540 than on FF! 

Did you have Hide Distant Traffic turned ON in both FF and your IDF?  

FF hides traffic more than 15 nautical miles or 3,500’ (above or below) your current GPS position while Garmin has a few different settings.  So you might check your IDF manual and the settings and see what it is currently showing.  It is possible (probable) that you'll never see the exact same traffic displayed on both FF and the IDF.

 

[0TreeLemur]

On 2/10/2024 at 7:47 PM, PeteMc said:

Did you have Hide Distant Traffic turned ON in both FF and your IDF?  

FF hides traffic more than 15 nautical miles or 3,500’ (above or below) your current GPS position while Garmin has a few different settings.  So you might check your IDF manual and the settings and see what it is currently showing.  It is possible (probable) that you'll never see the exact same traffic displayed on both FF and the IDF.

 

I was testing when there was a fair bit of traffic at TCL.  Lot's of nearby targets, so that setting doesn't influence what I was seeing, which was no traffic on the iPad at times.