Problem with GarminPilot upgrade

Shepherd

Final Approach
Joined
Nov 24, 2012
Messages
5,423
Location
Hopewell Jct, NY
Display Name

Display name:
Shepherd
I'm running Garmin Pilot on my Nexus 7 with 4.3. Until yesterday's upgrade it's been fine.
Today while planning a flight from DXR (Danbury) to MTP (Montauk) I noticed that when I expand the resolution on the screen, the map "breaks". It splits the Falkner Island Wildlife Refuge and puts the right half of the island above the flight path with a magnified scale and the left half of the island below the flight path with the smaller scale. Everything along that horizontal plane is also whacked.

Anyone else seeing this?

Thanks
Glenn
 
I'm running Garmin Pilot on my Nexus 7 with 4.3. Until yesterday's upgrade it's been fine.
Today while planning a flight from DXR (Danbury) to MTP (Montauk) I noticed that when I expand the resolution on the screen, the map "breaks". It splits the Falkner Island Wildlife Refuge and puts the right half of the island above the flight path with a magnified scale and the left half of the island below the flight path with the smaller scale. Everything along that horizontal plane is also whacked.

Anyone else seeing this?

Thanks
Glenn

Glenn -- something is a little funky with this revision. My Pilot on the Nexus 7 was rock solid until this download. On a flight on Friday, I started the app right before start-up and it started up okay and then crashed as I was doing my run up. I tried a reboot and it said it was unable to restart Pilot at this time! On the next try it restarted and worked fine for the rest of the flight. I fly with an iPad 2 as a backup and that worked fine throughout the whole flight.

I have a few more flights scheduled this week. I will be keeping an eye on it.
 
I'm running Garmin Pilot on my Nexus 7 with 4.3. Until yesterday's upgrade it's been fine.
Today while planning a flight from DXR (Danbury) to MTP (Montauk) I noticed that when I expand the resolution on the screen, the map "breaks". It splits the Falkner Island Wildlife Refuge and puts the right half of the island above the flight path with a magnified scale and the left half of the island below the flight path with the smaller scale. Everything along that horizontal plane is also whacked.

Anyone else seeing this?

Thanks
Glenn



Maybe it's showing the breakpoint between a sectional and a terminal area chart - they have different resolutions.



Edit- looks like the upper right corner of a NY terminal area chart is right in the spot you are looking at. When you zoom in enough, Garmin switches to the highest resolution chart it has. The problem is when you are right on an edge of two chart resolutions. I've seen this a lot because I'm right on the edge of a class B.
 
Last edited:
Anyone else seeing this?
I haven't loaded the latest patch but I think I see what you are seeing.

I think Matthew is right. It looks like there is a magnification threshold where they switch from a 100% spliced sectional view to a view that splices in the NY TAC chart. I don't think it's a bug, more of a feature. Since the projections of the two charts are different, a splice cannot be perfect, plus the details between the two are different -- the whole point of a TAC.

If you go down to Calverton and zoom, you'll see the compass rose around CCC change scale when you zoom and the TAC is spliced in.
 
I sent a note off to Garmin. I'll keep you posted on any response I get from them.
 
Haven't seen that one...but the last two rapid-fire updates seem to make the app S L O W. And the new "SIG WX" button unresponsive....
 
It's 24 hours and no response from Garmin.

Hmm, either in "oh s**t" mode, or "hey that guy's a wacko" mode. I rather strongly suspect the former....having two updates in as many days suggests something went wrong and it's real ugly over there right now.
 
Hmm, either in "oh s**t" mode, or "hey that guy's a wacko" mode. I rather strongly suspect the former....having two updates in as many days suggests something went wrong and it's real ugly over there right now.

I agree. Same thing happened to me again last night. Going for a flight, attempt to start up Pilot on my nexus 7, the app crashes with a request to send an error report. The app was rock solid prior to this update.

Sumtin is wrong... :yikes:
 
Hmm, either in "oh s**t" mode, or "hey that guy's a wacko" mode.
Or maybe they are shorthanded because part of the team is in Oshkosh. I think that's the most likely explanation.

With due respect, I also don't think the what OP/Shepherd reported is a bug. The most you could say about it is that it was a poor design decision to splice in the TACs but I'm not sure I'd even agree with that.

Re crashing, that's a bug. :)

Re frequency of updates I think it's good -- they are willing to find and fix. Re the need for updates, I still think they released based on the OSH calendar and probably didn't do as much testing as they would have done prior to a release that wasn't driven by marketing necessity.
 
In what sense is not drawing graphics correctly not a bug?

If it doesn't meet specs, it's a bug. Full stop. That's the way it is.

Releasing based on OSH would be stupid without a huge new feature set to show off. They do have some new enhancements, but it's not groundbreaking. That's where stupid decisions come in. Another would be sending a big hunk of the team to OSH, if they did indeed do that. You only need one or two guys -- generally the leads -- to show off a product.

Speaking as a product lead in a different organization, multiple bugfix releases, especially one day apart, are not at all a good thing. They mean the software was released before it was ready.
 
The TAC/Sectional resolution graphics deal has been around for many versions. Create a route from KOWI to KLWC and you'll see what I see almost every time I start the app. Zoom in and out and you'll see the break between the two different charts.

Ideally, they would add a check box to enable/disable that action.

I've never had to wait more than 48 hrs for a response. Usually I get an auto-email within a few minutes that lets me know they have gotten my message. They probably are short handed this week.
 
I talked with one of the people at Garmin regarding a separate bug, which is that XM weather is broken with the new release. He remarked that Garmin was very shorthanded due to Oshkosh. Bug reports are being sent to the programming people at Digital Cyclone. I've talked to one of the people there, and they are working on a fix. I assume your report is also being acted upon.
 
In what sense is not drawing graphics correctly not a bug?
IMO the graphics are being drawn correctly. There are two aspects to the issue that Shepherd reported, both due to the fact that at some threshold magnification the TAC is being rendered as part of the image.

First, any planar map of the surface of a sphere necessarily has distortions. You can pick your distortions by picking the projection, but you can't have no distortions. The result here is that the edges of the TAC will not match exactly when it is overlaid on the sectional. (This could be fixed with some fancy mathematics to re-render the TAC using the same projection numbers used to create the sectional, but that's a lot of crunching for little resulting value. It may not even be feasible with these little computers. I don't know.)

Second, the TAC has different features and represents features differently than a sectional. The easiest example is the one I already mentioned: The compass rose around a VOR has a 10 mile radius on a sectional and a 5 mile radius on a TAC. So when you splice the two, the roses on the TAC portion are half the size of the roses on the sectional portion. On Shepherd's example if you zoom to get the TAC/Sectional splice you will actually see a full rose around CCC because a 5 mile radius is 100% within the TAC boundary plus you will see a segment of the (10 mile radius) CCC rose depicted on the sectional portion of the image.

Sorry if I was not clear in post #4.
 
Actually, deprojecting map data is not terribly expensive and can be done in the graphics hardware rather often. It's mathematically equivalent to texture mapping, though the textures can get very large. The mapping is onto a cone in the case at hand.

There was a time when this would have been cost prohibitive. But these days, I can convolve a defocused image against an arbitrary star map at 1024x1024 in less than 10 ms, counting buffers for free boundary conditions and antialiasing, on ten-year-old hardware.

Now, there are a huge number of people who work with maps and don't understand projections. I've no idea if the Garmin folks fall in that category or not.
 
Look at 1K1-3AU-KEQA.

That's the dividing line between the Wichita and Kansas City sectionals.

There are pieces of info on one sectional in the overlap area that don't appear on the overlap area of the other. There's only so much that Garmin can do when they try to lace multiple charts together at the seams.
 
... deprojecting map data is not terribly expensive ....
Yes. Actually my typing was getting ahead of my thinking there. The TACs could be reprojected prior to distributing them. There's no reason at all that it would have to be done in the tablets. But that wouldn't eliminate the major visual discontinuities between the TACs and the sectionals, like the compass roses. So I still wonder whether any real benefit would come from reprojecting. I dunno. Maybe you do.
 
I heard from Garmin. It's a bug. The map is not rendering properly when the scale is increased across "stitched" areas.
There may be a couple of other things going on, also.
A fix may take a little bit of time, due to OSH.
 
I talked with one of the people at Garmin regarding a separate bug, which is that XM weather is broken with the new release. He remarked that Garmin was very shorthanded due to Oshkosh. Bug reports are being sent to the programming people at Digital Cyclone. I've talked to one of the people there, and they are working on a fix. I assume your report is also being acted upon.

Why in the world would they push out an update when they are short staffed? Some manager was not thinking on this one.
 
I heard from Garmin. It's a bug. The map is not rendering properly when the scale is increased across "stitched" areas.
There may be a couple of other things going on, also.
A fix may take a little bit of time, due to OSH.

Seems like this was reported in a previous version on google play. If this is the case it is a shame Garmin isn't being more proactive on some of their known issues. Sounds like they also need to get better with their testing prior to a doing a release as this isn't the first issue like this I've seen using the app.

https://play.google.com/store/apps/...EdnlUdnBlMG5EUmNUNHpVYVlYdHNTZE9GM3RCVXg1MVVx
 
Seems like this was reported in a previous version on google play. If this is the case it is a shame Garmin isn't being more proactive on some of their known issues. Sounds like they also need to get better with their testing prior to a doing a release as this isn't the first issue like this I've seen using the app.

https://play.google.com/store/apps/...EdnlUdnBlMG5EUmNUNHpVYVlYdHNTZE9GM3RCVXg1MVVx

This sort of recurring bug is quite common in all software shops. There seems to be no "institutional" memory for products anymore. The one person who knows about the problem, and fixes the problem, gets promoted or transferred to a new project, and the next release, or the release after that the bug comes back.
Saw it ALL the time at IBM.
 
Sounds like they also need to get better with their testing prior to a doing a release as this isn't the first issue like this I've seen using the app.

That's what the world is like in the consumer world. EVERY software project that doesn't have regulatory or customer requirements to do otherwise suffers that. Why? Exhaustive testing is impossible, due to the geometric complexity implied by the now-common feature bloat. Even rudimentary testing is prohibitively expensive.

You can do a lot better, but in the consumer world, retail price drives everything. Better testing can easily raise costs by an order of magnitude or more.

There are techniques to manage this problem, but they are not cheap. Largely, you need a design team that takes the time to really think about the dataflow, and makes a modular design with truly minimal interconnections, which can be tested. That takes time and money. A lot of it for a complex system.

And people wonder why I cringe at "situational awareness" from uncertified consumer toys....I don't trust my tablet to do anything at all in the air. It's a preflight tool, and even then, it needs a crosscheck.

Have you tried to compare the locations of intersections with the supposedly georeferenced charts? They differ by a mile in some cases. Yes, I know the IFR error is up to 4 miles, but I'd hate to use that up on just sloppiness.
 
Back
Top