Garmin Pilot for Android -- Tech Support, Tips, Tricks

[mkosmo]

Not sure if they are monitoring this thread (they should). I haven't reported it myself (only noticed it after you mentioned it here), so please go ahead and let us know what they say.

I went ahead and submitted it via Garmin support. How responsive are they typically?

 

[Marauder]

I went ahead and submitted it via Garmin support. How responsive are they typically?

Depends on the complaint level I noted an issue with an error coming up when flights are planned with less than 30 minutes in duration. When I went to the weather briefing page I would get an error message saying the ETE needs to be more than "0".

I reported this several months ago and again last week. It happens when I use a stored flight plan.

And also if I enter the flight manually:

Sent from my iPad using Tapatalk

 

[Matthew]

I went ahead and submitted it via Garmin support. How responsive are they typically?

In my experience:

You'll get an email, sometimes automated, usually within a day. Sometimes, you'll get a personal response by the next day. Once you get a response back, I think there is an incident number attached and you can use that for followup questions and get a real person to answer you. As far as when a bug fix shows up, that depends on the severity and how many they are saving up before they come out with a new release.

Typically, the way it seems to go: They release a version with bug fixes or new features. They get a lot of responses back where people have uncovered or discovered new problems. Within a week (sometimes next day), there is another release that fixes those problems.

 

[mkosmo]

So, I emailed them direct late last night as well. I had an initial response by 9am and they've already fixed it for the next point release.

First reply:

We were able to duplicate this problem and the developers are working on an update to fix this issue. It is a map layering issue that is affected by the terrain database download for some reason.

Second reply:

I just got confirmation that this will be fixed in the next point release for Garmin Pilot.


“We can reproduce now.”



“This fix will go out in our next point release:”

I think it's fair to say that I'm incredibly impressed with their support.

Sent from my SAMSUNG-SGH-I337 using Tapatalk

 

[RotorDude]

So, I emailed them direct late last night as well. I had an initial response by 9am and they've already fixed it for the next point release.

First reply:



Second reply:



I think it's fair to say that I'm incredibly impressed with their support.

Sent from my SAMSUNG-SGH-I337 using Tapatalk

Good job!
Thanks from all of us.

 

[Jay Honeck]

Good job!
Thanks from all of us.

+1!

 

[Mistake Not...]

The briefing bug, where if the estimated trip time was < 30 minutes, it would cause a problem, that was fixed, is now broken again.

I swear it was working for me after the update to 4.3.3, but now I can't brief KHSV->8A1. Can anyone else?

 

[Marauder]

The briefing bug, where if the estimated trip time was < 30 minutes, it would cause a problem, that was fixed, is now broken again.

I swear it was working for me after the update to 4.3.3, but now I can't brief KHSV->8A1. Can anyone else?

On the iOS version it has been broken a while.


Sent from my iPad using Tapatalk

 

[RotorDude]

The briefing bug, where if the estimated trip time was < 30 minutes, it would cause a problem, that was fixed, is now broken again.

I swear it was working for me after the update to 4.3.3, but now I can't brief KHSV->8A1. Can anyone else?

Just tried KHSV -> 8A1 per your post #1881, and "Brief" fails on 4.3.3 as it did previously. So definitely still broken.

 

[Mistake Not...]

Thanks. When I got the 4.3.3 update, I tried it and I'm 99% certain it worked. Then I tried it yesterday and no luck. Makes me think the DUAT provider tweaked an interface rather than Garmin being the problem.

 

[Jay Honeck]

Anyone find that the ADS-B radar is now unreliable hyper-sensitive?

Now that it's working for me again, I'm finding it less than useful, thanks to swaths of green and yellow being displayed under simple clouds on an otherwise clear day.

 

[Marauder]

Thanks. When I got the 4.3.3 update, I tried it and I'm 99% certain it worked. Then I tried it yesterday and no luck. Makes me think the DUAT provider tweaked an interface rather than Garmin being the problem.

I think you may be onto something. I'm not sure why 30 minutes is something magical but anything less then I get the pop up error. I did log directly into CSC and did not get an error.


Sent from my iPad using Tapatalk

 

[Mistake Not...]

Anyone find that the ADS-B radar is now unreliable hyper-sensitive?

Now that it's working for me again, I'm finding it less than useful, thanks to swaths of green and yellow being displayed under simple clouds on an otherwise clear day.

I just got a GDL-39. I can't get the weather on the ground and haven't tried it in the air yet, I'll definitely look.

 

[RotorDude]

Anyone find that the ADS-B radar is now unreliable hyper-sensitive?

Now that it's working for me again, I'm finding it less than useful, thanks to swaths of green and yellow being displayed under simple clouds on an otherwise clear day.

I have noticed a few cases lately of the green/yellow being a bit "oversensitive" to my taste, though I can't swear it's any different from before.
But I am assuming that the Nexrad data, including the color classification, comes from NOAA and is common to all the different providers, including XM and ADSB. Am I wrong?

 

[Paul Hamilton]

On my first flight after the update (August 22) there was a persistent area of green and yellow precipitation over the Calverton (CCC) VOR at 12:25 PM, EDT. When I flew through the area, there was no precipitation, and nothing appears for that time on historical NEXRAD data. Subsequently, the radar depiction has been fine on all flights, with only real echoes appearing. I've not yet applied the GDL-39 firmware update.

 

[Jay Honeck]

I have noticed a few cases lately of the green/yellow being a bit "oversensitive" to my taste, though I can't swear it's any different from before.
But I am assuming that the Nexrad data, including the color classification, comes from NOAA and is common to all the different providers, including XM and ADSB. Am I wrong?

I think you are correct.

I've noticed ADS-B radar over-sensitivity before (and posted on POA about it), but that was WRT actual rain. What I've been seeing these last few flights is light green and a bit of yellow depicted where there are only puffy clouds on a clear day.

Just interested in hearing if anyone else is seeing this? I live on the gulf coast, where humidity is high. I wonder if that jacks with Nexrad?

 

[Mistake Not...]

I think you are correct.

I've noticed ADS-B radar over-sensitivity before (and posted on POA about it), but that was WRT actual rain. What I've been seeing these last few flights is light green and a bit of yellow depicted where there are only puffy clouds on a clear day.

Just interested in hearing if anyone else is seeing this? I live on the gulf coast, where humidity is high. I wonder if that jacks with Nexrad?

You'd think there'd be a (public) website somewhere that would show the FIS-B products currently being broadcast. If we could find that site, comparing would be interesting.

Anyone know?

 

[Jay Honeck]

You'd think there'd be a (public) website somewhere that would show the FIS-B products currently being broadcast. If we could find that site, comparing would be interesting.

Anyone know?

That's a great idea, but... without internet in the plane, how would we do a side-by-side comparison?

I do a side by side comparo using my EFIS (with ADS-B radar) and Garmin Pilot. Both have been showing precipitation where none exists.

 

[Paul Hamilton]

I just did a side by side comparison with Garmin NEXRAD via ADS-B, Garmin NEXRAD via Internet, and NEXRAD via NOAA. Scattered green an boxed appear only in Garmin NEXRAD via ADS-B. The NOAA source shows lots of clutter, which appears to be filtered out in the other presentations. I believe that the ADS-B source is filtering less of the clutter.

One possibility this time of year is migrating birds causing clutter.

 

[RotorDude]

I just did a side by side comparison with Garmin NEXRAD via ADS-B, Garmin NEXRAD via Internet, and NEXRAD via NOAA. Scattered green an boxed appear only in Garmin NEXRAD via ADS-B. The NOAA source shows lots of clutter, which appears to be filtered out in the other presentations. I believe that the ADS-B source is filtering less of the clutter.

One possibility this time of year is migrating birds causing clutter.

I tend to doubt that theory, because I think most people don't just see "clutter", but a well defined area moving in a reasonable (common for the geographical area) direction and speed. I think most users view the ADSB radar returns in loop mode, which should eliminate bird migrations unless they happen to mimic typical storm movements.

 

[Mistake Not...]

That's a great idea, but... without internet in the plane, how would we do a side-by-side comparison?

If we can find the site, it'd be trivial to write a little script to save the imagery off periodically. Go fly, take screen shots, land, compare.

 

[stevenclin]

For others who may have been having problems with reliable display of Baron/XM MobileLink weather in Garmin Pilot, I just received an email announcing a firmware update for the MobileLink box that allows one to view all the XM products independent from any 3rd party app (like Garmin Pilot). I think I will try this, so that if I have additional problems with XM on GP in the future, I'll have a backup mechanism to view weather. Here's a link to the update description:

http://www.baronweather.com/mobile-link-firmware-update/

 

[Chip Sylverne]

I know this is a little wide of the plate, but my friend and I just did an x/c from MD to NW OH through some scattered building cu and iso/scattered tsra. He had his stratus/ ff combo, I had Dual xgps 170 / Avare on my N7. The displays of NEXRAD were considerably different. The stratus seemed far more detailed, and seemed to show more areas of precip than did the dual. The locations were the same, but the stratus showed a wider area. Not sure if it's the software or the hardware responsible for the difference, but it was considerable.

Between the NEXRAD and my stormscope, we were able to get a pretty good picture of where the airplane eaters were, and make a trip I probably otherwise would not have made.

 

[mkosmo]

The locations were the same, but the stratus showed a wider area. Not sure if it's the software or the hardware responsible for the difference, but it was considerable.

That'd be software. They're both receiving the same data if you're in the same place. One may show a smaller radius, one may do some smoothing, hard to say. I've never played with either configuration, personally.

 

[Mistake Not...]

Screenshots would be really helpful and aren't hard to take. Please... if anyone does this in the future, get screenshots at the same time on both platforms.

I spent some time digging into the FIS-B product binary formats. Bumped my nose against a registration-required FAA site that contains the actual NEXRAD dataset format (as broadcast). From what I could see, however, it didn't look like a final georeferenced image that is simply composited with a particular vendors map. Instead, it looks like each pixel value is a "level" and can probably be interpreted / rendered / filtered by a vendor according to their own algorithms. That' s just a guess until I get the nexrad format, but it appears to be what we're seeing.

 

[Jay Honeck]

Screenshots would be really helpful and aren't hard to take. Please... if anyone does this in the future, get screenshots at the same time on both platforms.

I spent some time digging into the FIS-B product binary formats. Bumped my nose against a registration-required FAA site that contains the actual NEXRAD dataset format (as broadcast). From what I could see, however, it didn't look like a final georeferenced image that is simply composited with a particular vendors map. Instead, it looks like each pixel value is a "level" and can probably be interpreted / rendered / filtered by a vendor according to their own algorithms. That' s just a guess until I get the nexrad format, but it appears to be what we're seeing.

Fascinating. So, in layman's terms, the Garmins of the world can set it to show more, or less, precip at will.

Which means that liability has probably entered the decision making process.

Which, in turn, may explain why GP often shows precip where none exists. They've got it set to maximum sensitivity, possibly for CYA purposes?

 

[Mistake Not...]

Got it. See attached, first page (section 2.10.3.2)

"The Global Block Representation geo references individual "bins" of the NEXRAD image to latitude and longitude rather than on a projection requiring a point of tangency. The encoded intensity levels for the individual "bins" map into "dBz" reflectivity levels as shown in the table below".

 

[Mistake Not...]

Fascinating. So, in layman's terms, the Garmins of the world can set it to show more, or less, precip at will.

Which means that liability has probably entered the decision making process.

Which, in turn, may explain why GP often shows precip where none exists. They've got it set to maximum sensitivity, possibly for CYA purposes?

Possibly. If I'm reading this right, page 2 of the attached shows the table of possible bin values and their "dBz" level, along with guidelines for rendering according to DO-267A (which is $135, so screw that...)

 

[mkosmo]

Got it. See attached, first page (section 2.10.3.2)

"The Global Block Representation geo references individual "bins" of the NEXRAD image to latitude and longitude rather than on a projection requiring a point of tangency. The encoded intensity levels for the individual "bins" map into "dBz" reflectivity levels as shown in the table below".

Go figure it looks like a summarized version of native Nexrad L2

 

[Mistake Not...]

This may (or may not) be of interest...

"Surveillance and Broadcast Services Description Document" http://adsbforgeneralaviation.com/w...SBS-Description-Doc_SRT_47_rev01_20111024.pdf

A fairly readable (somewhat technical) 132 page description of ADS-B and component services, including product descriptions and some formatting. Stops short of actual binary format (at least where I was looking) instead references the appropriate standard (DO-267A for nexrad).

Not claiming to be any sort of expert here... just bored and found some stuff on google. Clarification / corrections welcome.

 

[Mistake Not...]

Last comment, then off to a bbq, but...

Note two on the table on intensity values says:

The Intensity Encoded Values 0 (zero) and 1 (one) are considered Background and should be color rendered accordingly

But in the table at least, 0 and 1 correspond to bins that appear to be able to contain non-zero reflectivity values. So... maybe Garmin has a rendering bug. They should be rendering as transparent, but are assigning a color instead. Or, it could be as Jay suggests, a butt-covering "feature".

 

[RotorDude]

Last comment, then off to a bbq, but...

Note two on the table on intensity values says:



But in the table at least, 0 and 1 correspond to bins that appear to be able to contain non-zero reflectivity values. So... maybe Garmin has a rendering bug. They should be rendering as transparent, but are assigning a color instead. Or, it could be as Jay suggests, a butt-covering "feature".

Could be, although I would think that "background" (as in ground clutter) would be pretty stable over time, whereas the "oversensitive" areas that I've encountered so far with GP Android are actual clouds, though not moist enough (i.e. no precip or virga or even very dark) to be worthy of rendering or concern from a pilot's perspective.
So I think the issue is perhaps the next level up in the reflectivity scale, which is not background but is the lowest level where there is real moisture which has reflectivity above the threshold. Some vendors may color this level green, and others may completely ignore it. Just guessing, however.
From my own perspective as a user, I'd like access to the reflectivity mapping table (currently hard-wired) which colors the 8 levels which Nexrad provides so that I'd be able to map it into different color schemes with different sensitivities (e.g. high/medium/low sensitivity). Alternatively, just allow me to increase the minimal threshold for painting anything.

 

[Chip Sylverne]

Fascinating. So, in layman's terms, the Garmins of the world can set it to show more, or less, precip at will.

Which means that liability has probably entered the decision making process.

Which, in turn, may explain why GP often shows precip where none exists. They've got it set to maximum sensitivity, possibly for CYA purposes?

This issue of pixelated ads-b NEXRAD presentation was posed over at the Avare support message board. The engineers there stated that the data as broadcast by the ads-b NEXRAD is indeed rather coarse. They are opting not to "smooth" the rendering for just the liability issues you mention. So Garmin, FF and others may look nice, but are made so by software smoothing and not by actual data granularity sent by the system.

 

[RotorDude]

This issue was posed over at the Avare support message board. The engineers there stated that the data as broadcast by the ads-b NEXRAD was indeed rather coarse and pixelated. They are opting not to "smooth" the rendering for just the liability issues you mention. So Garmin, FF and others may look nice, but are made so by software smoothing and not by actual data granularity sent by the system.

Don't know about the others, but AFAIK Garmin (in GP Android) does not smooth the ADS-B radar reflectivity data. I actually consider this a deficiency, since done properly you'd lose nothing information-wise while reducing eye strain.

 

[Chip Sylverne]

Don't know about the others, but AFAIK Garmin (in GP Android) does not smooth the ADS-B radar reflectivity data. I actually consider this a deficiency, since done properly you'd lose nothing information-wise while reducing eye strain.

Well, the other thing pointed out over there was that the smoothing does use more system resources. But I agree with you in that the smoothed rendering was much easier to see at a glance. I preferred it.

 

[Jay Honeck]

Today was a perfect example of this problem. We flew from the island to Lake Jackson (LBX), which is just Southwest of Houston. Garmin Pilot displayed widespread light precipitation along the route of flight.

Knowing what I know about this "system", I checked the actual METARs, and noted nothing but CAVU conditions, so, we launched.

Not a drop of rain. Nothing but a few scattered clouds. Interestingly, my GRT Avionics Horizon HXR EFIS was also depicting the ADS-B precip, none of which existed. This is not usual.

IMHO, this is a serious issue. Like the boy who cries wolf one too many times, this false precip data will soon be ignored by everyone, leading us down the potentially primrose path to complacency.

 

[Mistake Not...]

Agreed, but as a developer I can see both sides. Possible solutions:

* Hide lowest levels. Hopefully eliminates false positives but might also hide important info (and yes, I admit these are unlikely, but: smoke? insects? birds? volcanic ash? Snow?) This follows an exisiting standard's recommendation (DO-267A), so liability may not be a concern.

* Have configuration menu for advanced users - Just adds to an already confusing interface, most will never use it, those that do may not use it correctly (I personally favor this one, with the default setting to hide lowest levels. That follows the recommended display and would still enable rendering of the raw data for expert users. Could also add a data smoothing option here.)

* Always show all levels, catch hell for phantom precip. But, you're showing everything, it's totally on the user to decide what it means, you were just a conduit for the information. No liability, and no additional software features to implement / test.


* (Outside of Garmin's control) Improve data filtering on the ground before the product is sent out. If those levels are "background" (as defined in the standard), they should be zero'd before being broadcast. I'm not sure why this isn't done anyway, making more uplink bandwidth available for higher spatial resolution.

If I had side by side screenshots showing the problem, I'd file a bug report. But I just got my GLD39 and don't have another nexrad source in the plane so it won't be me. Anyone else?

 

[Jay Honeck]

Agreed, but as a developer I can see both sides. Possible solutions:

* Hide lowest levels. Hopefully eliminates false positives but might also hide important info (and yes, I admit these are unlikely, but: smoke? insects? birds? volcanic ash? Snow?) This follows an exisiting standard's recommendation (DO-267A), so liability may not be a concern.

* Have configuration menu for advanced users - Just adds to an already confusing interface, most will never use it, those that do may not use it correctly (I personally favor this one, with the default setting to hide lowest levels. That follows the recommended display and would still enable rendering of the raw data for expert users. Could also add a data smoothing option here.)

* Always show all levels, catch hell for phantom precip. But, you're showing everything, it's totally on the user to decide what it means, you were just a conduit for the information. No liability, and no additional software features to implement / test.


* (Outside of Garmin's control) Improve data filtering on the ground before the product is sent out. If those levels are "background" (as defined in the standard), they should be zero'd before being broadcast. I'm not sure why this isn't done anyway, making more uplink bandwidth available for higher spatial resolution.

If I had side by side screenshots showing the problem, I'd file a bug report. But I just got my GLD39 and don't have another nexrad source in the plane so it won't be me. Anyone else?

Well, we know which option Garmin and GRT have chosen. They show everything. And I can't filter it out.

As for side by side screen shots, who should we send this bug report to? The FAA? I've now seen these false returns on two separate ADS-B displays, made by different manufacturers, so it's clearly garbage coming into the system at the source.

 

[Mistake Not...]

Well, we know which option Garmin and GRT have chosen.

Do the ios and android versions of GP show exactly the same thing? Maybe the android devel team is smaller, has fewer pilots and doesn't realize this is an issue. My bug report would be to call their attention to it... if it's "CLOSED-WONTFIX" then it's on purpose. But we're assuming they're aware of the problem.

 

[Van Johnston]

I'm an iOS GP user but check in here from time to time to see how things are going on the Android side. This was my experience going to west Texas a few weeks ago: About 90 min from AMA all of a sudden a big blob of green, pretty circular, blossomed over the northern panhandle. I knew there was nothing in the forecast, and cross-checked with ceilings and visibility to confirm everyplace was still reporting unlimited. I also know precip usually goes with a frontal boundary and shows in lines at an approx 45 degree angle, and moves. Stationary circular blobs are rare. I've also noticed GP often shows green over my house when I can look out the window and see there is none. So I pressed ahead and as forecast, CAVU the whole way.

I guess my point is don't rely on a single instrument/reading/measurement. Use your experience and training to interpret all the info you have and then make appropriate decisions. And 'training' now includes what we've learned in the last couple of posts about the data that is actually transmitted and what the SW does with it.