|
|
|
|
I'll make this an official wish list entry: Per my "bug" report in the Beta-Android Discussion, I had a disruption in the GPS altitude data stream on a recent flight. Nevertheless, despite not having altitude info, iFly continued to report Altitude on the GPS Altitude instrument; the VP calculated that, since my altitude wasn't changing, I was flying perfectly level; and terrain flashed all around me, all as if everything was working as it should. Therefore, I suggest there be some kind of "activity checker" (or other protocol) to test that altitude data is coming through correctly.
For example, per my previous video (https://vid.me/F6rA (case sensitive)), we know that GPS altitude dithers quite a lot in flight, even by one foot. (I don't have WAAS, but I expect, at altitude, GPS altitude would dither the same.) Admittedly it was bumpy the day I took this video. But I presume that GPS attitude dithers by a foot or two even on a smooth winter day even with a good altitude holding AP?
If true, then perhaps some kind of "activity checker" to check that GPS altitude has changed by a foot in, say, the past minute or two? And if a "freeze" in altitude is detected, then the GPS attitude should blank, the VP should X out or blank, and what should Terrain do? All red? As a minimum, I suggest that Terrain stop acting as tho it's working.
Perhaps an override or "Okay" if indeed everything is okay.
Since taxing or being parked on the ground could trigger a "loss of altitude info" warning (more like parking - my field has a 40 foot delta from end to end as we taxi), the checker should only arm after forward flight is detected.
|
|
|
|
| |
|
|
|
Mike, thanks for the suggestions. We'll need to look into this further. However, I'm certain that detecting a lack of altitude "movement" will not give an accurate result. Most of the time your "locked" satellites will be at a low angle of attack, there is very little vertical deviation with which to calculate an altitude. This is why GPS altitude is not as accurate as the horizontal position. And also for this reason most modern GPS receivers will "pin" the altitude until there is a high confidence a change was detected. With a strong lock, you might see 1ft movement (but this isn't common). A weak lock you might only see 50' increment changes. And it's common to see the altitude unchanged for long periods of time.
Walter Boyd
President, Adventure Pilot
|
|
|
|
| |
|
|
|
Regarding your statement that most GPS receivers pin the altitude until there is a high confidence a change is detected, a few comments for brainstorming:
So, except for the iFly boxes themselves, some of this problem might be out of your hands? That is, for us tablet users, iFly doesn't control whether the GPS receiver is pinning altitude? Or even know if the altitude information is being pinned?
Now, in my case, with the TomTom GPS to Bluetooth thing, my TomTom is dumb. I've taken it apart. It's just a GPS receiver that sends NMEA (presumably) data out via BT. It doesn't appear to pin anything, as evidenced in the screen shot of my GPS BT Android app. (Where there were dashes in the altitude field when altitude data was lost.) I wonder what my Samsung Galaxy Tab 2 does with altitude? I would be surprised if the Samsung engineers pinned altitude info in the receiver. (Unless that function is built in to the ASIC.)
So, as a first matter, as I think Brian has already acknowledged, the iFly app should react when there is no altitude data coming thru on the data stream. That is, since my Android app can show dashes when altitude data is lost, iFly should also.
I've never used the fancy new ADS-B/GPS receivers. Are you saying that they're smart in that analyze the GPS data and massage it? (I guess the WAAS enabled receivers must?) That they pin altitude until they're confident there was a change in altitude?
If that's the case, then loss of altitude information might be impossible for iFly to detect with "smart" receivers. (Do these receivers send RAIM info in the data stream? Does RAIM flag loss or questionable altitude data?)
It seems to me that, for flight critical applications, altitude data should never be pinned (except perhaps for a few seconds to throw out anomalous data). It should always be determined in real time. (1000 ft/min downdrafts over mountainous terrain.) If the calculation is crummy, it's crummy. I would rather have bad raw data than artificially massaged "good" data. At least that way I can know that my data is crummy and I can know to disregard it. Whereas massaged "good" data lulls me into a false sense of security.
But, as I said above, except for iFly's own boxes (with their own receivers), pinning might be out of your control.
Last, my TomTom sends satellite info in the data stream. Could iFly use that info to set say, two levels of confidence regarding accuracy of altitude info? That is, if iFly knew that there were a lot of satellites in view and enough where high angle of attack to give very accurate altitude info, and if the altitude wasn't changing at all over a minute, then Warn about possible altitude data loss?
No response expected. Just kicking some ideas around.
|
|
|
|
| |
|
|
|
Another thought: Given my discovery that I got a positive VST Instrument when I lost GPS altitude data, perhaps that serendipitous discovery could be used to notify the user of loss of altitude information in the GPS data stream? (That is, when VST wants to go positive, don't display it, but raise a Warning Flag to the user instead.)
If the reason for the positive VST on GPS altitude data loss was fully understood from the code, then perhaps this is the way to warn the user?
Also, regarding GPS altitude and low angle satellites: could iFly display a "+" symbol after altitude in the Altitude Instrument when it detects altitude info is low confidence/poorish?
|
|
|
|
| |
|
|
|
Hi Mike,
Just spitballing here, but here's a suggestion that might shed light on the accuracy of your TomTom altitude output. When on a bike trip, I use the DigiHUD Pro app on my Android to track my route. I can then import the GPS data into Excel and graph my speed, elevation, etc. for the entire trip. Perhaps you can use a similar app while driving (or flying) to see if your altitude info jumps around, or seems accurate. Additionally, you can extract the altitude info from iFly's flight logs and chart the altitude, and see just what was being recorded during the portion of flight where you saw the anomaly. Or you can upload the flight log to gpsvisualizer.com and play with the import settings to see your 3D track in Google Earth. This exercise might help determine if iFly has an issue processing the data, or if the GPS data is jumping around.
Jeff Nokomis Clark,
Mooney M20G,
iFly app on ASUS ZenPad Z8s,
ASUS ZenFone AR,
ASUS Windows 10 tablet,
Stratux ADS-B w AHRS
|
|
|
|
| |