The FAA wants to be notified if loss of GPS guidance affects flight
safety.Â* I have heard reports from airliners over New Mexico that have
lost GPS.Â* The FAA can issue an order to the military to stop the
jamming if flight safety is an issue.Â* I've also lost my IFR certified
WAAS GPS/ADS-B in the C-180.Â* I reported it to ABQ Center and they asked
if I needed assistance.Â* Flying between mountain ranges with 100+ mile
visibility, I could pretty much see my destination.Â* It's the same in
gliding with the only problem being corrupt igc files.

On 5/26/2019 8:07 PM, kinsell wrote:
Sure would be nice if the gps engines could filter out the worst of
this.Â* 16K to 0 or 160K in a second seems ratherÂ* umm implausible.

If it is jamming, as it sounds like, expect it to get nothing but worse.


On 5/26/19 9:56 AM, Dan Marotta wrote:
I tried to change either the logging interval or just the interval
that is downloaded after the flight but it was not intuitive after
the flight.Â* I guess a little ground study is in order.

As to the published interference testing times, I didn't check, but
the only dropouts I had were up around Las Vegas (the northeast part
of the flight).Â* Once moving south again, I did not see them again.
As stated before, I lost GPS on everything in the cockpit - all of my
stuff and my copilot's iPad, as well.Â* I'd bet on jamming.Â* I'll try
to do better on what and when next time.

On 5/26/2019 4:04 AM, Tim Newport-Peace wrote:
At 02:38 26 May 2019, kinsell wrote:
On 5/25/19 6:58 PM, Dan Marotta wrote:
I turned on my CN2 and CNvXC 20 minutes before engine start today.
Then
it was another 15 minutes to warm up the engine before take off.ÂÂ*
Even
though I had several GPS drop outs during the flight, it scored
perfectly.ÂÂ* BTW, all other devices in the cockpit, including my
buddy's
iPad also lost GPS for those times.ÂÂ* Looks like the work around
is to
let the GPSs get time synchronized before take off.

Basically, the Time in the IGC file originates in the GPS Engine. At
power-up it comes from the RTC, but once 'Satellite Time' has been
received
and the correct number of Leap Seconds applied, the source switches to
that.

The difference can be in the order of 2 seconds, and this causes the
out-of-sequence times that OLC seems objects to.

There are two workarounds and you can use either or both.

1. Set the logging interval to 4 seconds or more, which will conceal
the
2-second jump.

2. As you said, Switch on well in advance. 15 minutes is about right
IMHO.
10 minutes is the time it takes to be assured that the time is
correct, and
5 more to be sure that the FR has not back-logged the jump.






--
Dan, 5J