iFly GPS Forum

Hi Tim, thanks for the defense.  But in short, we want iFly to generally "just work", especially under the circumstances described by Jim here.  Apparently his GPS signal is strong enough to work with other apps, so why does it appear so faulty inside iFly?  That's a valid concern, and one which we'd like to deal with.  This bug makes iFly appear defective.

Most users don't come to the forums; they just download the app to "see if it works", and if it fails, they uninstall and forget out us.  So for every user like Jim who reports this bug, there could be 100 others who were silent, and simply moved on to a different EFB app which does work with their GPS.

So please assume that nearly all user complaints and bug reports are welcomed and appreciated, no matter the tone.  We want to almost always encourage this type of bug reporting, and prefer this, rather than having these users simply find a "workaround".  In short, we want iFly to "just work" in as many cases as possible, with no workarounds required.

Tim, we love your support as well.  I just wanted to make sure you were clear about Adventure Pilot's perspective on these types of bug reports.  We love them, and want to see more of them, and show appreciation to users for taking the time to make these detailed reports, and to work with us on validating our fixes.  When we fix the bug for them, we are likely fixing the same bug to be experienced by 100+ other users who won't bother to issue a bug report.

Cheers!

Heads up for Brian...I sent verbose GPS bug report data for the Motorola and Huawei tablets collected simultaneously on a 45 min car ride.  I'd be curious to hear if the Huawei data looks good and is just reporting weak, or if there are signs that is was actually sketchy.  Huawei reported weak GPS the whole time.  Thanks again, Jim.

SUCCESS and THANK YOU!  ISSUE HAS BEEN FIXED!

I'll bet we just fixed an issue that'll help at least 100 other users in the future.

It seems the HUAWEI is sending us a defective, but easy to remedy, GSA message. Perhaps there’s a new spec for GSA that I’m not aware of.

Here’s a site that explains the specs for the NMEA messages that we are parsing; search for the section on GSA:

http://www.gpsinformation.org/dale/nmea.htm#GSA


Which reads:

$GPGSA,A,3,04,05,,09,12,,,24,,,,,2.5,1.3,2.1*39

Where:
GSA Satellite status
A Auto selection of 2D or 3D fix (M = manual)
3 3D fix - values include: 1 = no fix
2 = 2D fix
3 = 3D fix
04,05... PRNs of satellites used for fix (space for 12)   <=== HERE'S THE ISSUE
2.5 PDOP (dilution of precision)
1.3 Horizontal dilution of precision (HDOP)
2.1 Vertical dilution of precision (VDOP)
*39 the checksum data, always begins with *

The issue with the HUAWEI is that they are sending us “20” spaces for satellites, instead of only 12, per the spec.

The values we’re trying to read are the final two items, HDOP and VDOP.

Our current code is trying to parse these by fixed index of 16 and 17. For the HUAWEI, of course, we’re getting null values, as it’s the wrong index.

I’ve changed the code to index them from the end instead, and so now I take the list size and just subtract 1 and 2, to get the desired index. So the new code works great on both devices that match the spec, and those that might want to insert more satellites, like the HUAWEI.

This fix will be released into the next beta, this coming week.