Implausible Time Records

[Dan Marotta]

For my last three flights I've been getting a message from OLC warning
of implausible time records in the igc file.  Does anyone know what this
means and what I might do to correct the problem? I've asked the
question on the ClearNav forum but haven't gotten a reply yet.

Here's a link to the file if that helps:
https://www.dropbox.com/s/erm01jilimuqudd/2019-05-04-CNI-V8Q-01.IGC?dl=0
--
Dan, 5J

[JS]

Noticed it was from the vario. I'll use a vario file today and see...
Jim

[Dan Marotta]

Yes, it was from the vario which just started acting up.  The ClearNav
II display's USB stick did not have the flight.  I may have neglected to
download that.

Lately I've been getting a boatload of GPS drop outs.  Maybe that's
because I'm close to the source of the interference testing or maybe
it's because I've cut my antennae cables to length in my cockpit.  I now
seem to recall reading that one should not shorten the cables. I know
about reflections due to wavelength/transmission line length, but I was
unaware that that would affect reception.  Do I need to acquire new
antennae?  The antenna that came with my PF portable was 10 meters
long!  Who needs a big bundle of cable under the panel?

--
Dan, 5J

[Tim Newport-Peace]

Looking at the file, there is an out-of-sequence issue:

Checking File C:\Users\Public\Documents\GPS\2019-05-04-CNI-V8Q-01.IGC
---------------------------------------------------------------------
Out of Sequence Error -
B1903383458935N10559992WA0184701874001999104104113000
B1903393458935N10600013WA0184901876001999112112116000
B1903373458935N10600035WA0185101877001999115115119000
B1903383458936N10600057WA0185301878001999119119122000

Could this be the issue?

[Dan Marotta]

I don't see what you're seeing.  But how could records be out of
sequence?  Maybe because my position apparently reversed while
thermalling during a GPS outage and getting one or two hits and then
another drop out, etc.?

On 5/5/2019 10:43 AM, Tim Newport-Peace wrote:
> At 16:26 05 May 2019, Dan Marotta wrote:

>> Yes, it was from the vario which just started acting up.  The ClearNav
>> II display's USB stick did not have the flight.  I may have neglected to
>> download that.
>>
>> Lately I've been getting a boatload of GPS drop outs.  Maybe that's

>> because I'm close to the source of the interference testing or maybe

>> it's because I've cut my antennae cables to length in my cockpit.  I now

>> seem to recall reading that one should not shorten the cables. I know
>> about reflections due to wavelength/transmission line length, but I was

>> unaware that that would affect reception.  Do I need to acquire new
>> antennae?  The antenna that came with my PF portable was 10 meters
>> long!  Who needs a big bundle of cable under the panel?

>>
>> On 5/5/2019 9:49 AM, JS wrote:
>>> On Sunday, May 5, 2019 at 8:38:57 AM UTC-7, Dan Marotta wrote:
>>>> For my last three flights I've been getting a message from OLC warning

>>>> of implausible time records in the igc file.  Does anyone know what

>> this
>>>> means and what I might do to correct the problem? I've asked the
>>>> question on the ClearNav forum but haven't gotten a reply yet.
>>>>
>>>> Here's a link to the file if that helps:
>>>>
> https://www.dropbox.com/s/erm01jilimuqudd/2019-05-04-CNI-V8Q-01.IGC?dl=0
>>>> --
>>>> Dan, 5J
>>> Noticed it was from the vario. I'll use a vario file today and see...
>>> Jim
>> --
>> Dan, 5J
>>
> Looking at the file, there is an out-of-sequence issue:
>
> Checking File C:\Users\Public\Documents\GPS\2019-05-04-CNI-V8Q-01.IGC
> ---------------------------------------------------------------------
> Out of Sequence Error -
> B1903383458935N10559992WA0184701874001999104104113000
> B1903393458935N10600013WA0184901876001999112112116000
> B1903373458935N10600035WA0185101877001999115115119000
> B1903383458936N10600057WA0185301878001999119119122000
>
> Could this be the issue?
>
>
>

--
Dan, 5J

[Tim Newport-Peace]

Dan,

Open your file with a text editor and search for "B190338"
This will put you in the right area.
In each record, after the letter B, the next six bytes are the time.

After B190339 the time jumps back to B190337, which is odd, and leads to
there being two records with a time of 190338, and also 190339.

Odd, but I have seen this before. Maybe you can avoid it in future by
setting a longer fix interval, even 2 seconds might help, but no promises.

I am not seeing any GPS outage around that time. This would be shown by the
Letter "A" in the 25th byte changing to a "V".

Although it does not help a lot, the sequence error seems to happen as you
left the ground, so I guess you were not reversing turns?

I'm not saying this is what OLC are complaining about, just that it is odd
and it might be.

Tim.
--

[Dan Marotta]

Thanks Tim

I'll increase my time interval to 2 seconds and see if that helps.

Strange that the igc file does not show GPS drop outs since my ClearNav
screen went white with the caption (something like) No GPS.  Zero
satellites.  And the ClearNav vario said, "Warning no GPS".  The
PowerFlarm portable screen also went blank with a "Zero satellites" message.

On 5/5/2019 1:05 PM, Tim Newport-Peace wrote:
> Dan,
>
> Open your file with a text editor and search for "B190338"
> This will put you in the right area.
> In each record, after the letter B, the next six bytes are the time.
>
> After B190339 the time jumps back to B190337, which is odd, and leads to
> there being two records with a time of 190338, and also 190339.
>
> Odd, but I have seen this before. Maybe you can avoid it in future by
> setting a longer fix interval, even 2 seconds might help, but no promises.
>
> I am not seeing any GPS outage around that time. This would be shown by the
> Letter "A" in the 25th byte changing to a "V".
>
> Although it does not help a lot, the sequence error seems to happen as you
> left the ground, so I guess you were not reversing turns?
>
> I'm not saying this is what OLC are complaining about, just that it is odd
> and it might be.
>
> Tim.

--

Dan, 5J

[JS]

That smells of GPS jamming.
Check this page.
https://www.navcen.uscg.gov/pdf/gps/gpsnotices/GPS_Interference.pdf
I did not have a problem with the vario file today. My antenna has a shortened cable to a MECA divider, then a short SMA-SMA link cable.
Jim

[Dan Marotta]

Yes, the GPS jamming usually centers around Alamogordo and ranges out to
about 400 nm.  Moriarty is well within that area.  I've asked other
local pilots and they don't report so many drop outs.

Maybe there are just too many GPS antennae in my ship.  I'll take a look
at a divider for everything except the ADS-B WAAS GPS.  Its antenna is
mounted aft of the engine in the Stemme.  The rest are on or under the
glare shield.

--
Dan, 5J

[kinsell]

Jamming is directed skyward, they're not taking out car gps's in a 400
nm radius. If you're getting bad time stamps just at liftoff, it's not
likely caused by jamming.

I'm suspicious of your cut-down gps cables, those are tiny wires to be
working on.

[Tim Newport-Peace]

Not necessarily related, but I noticed that your Firmware is dated
10-Feb-2017. I feel sure that there have been updates since then.

[Tim Newport-Peace]

GPS signals are line-of-sight only, and as the problem ocurred at take-off,
the source would have to be very close, like visible.

[Dan Marotta]

I've also had drop outs with my Trig TN-70 and its antenna, though not as often as with my soaring GPSs.

Yes, the wires are tiny, but it was pretty simple to desolder them from the puck, clip the cable to length, strip, tin, and solder.  I did that for 3 antennae and they generally work fine, but lately have acting up.

I'm looking at THESE as replacements.  Any comments?  I wonder if that IPEX connector is a push fit on the built in SMA connectors on the devices.  I'm also considering replacing the modified antennae with factory new units and using the longer cables to mount them on opposite canopy rails in the Stemme.  Those should be about a meter apart.

--
Dan, 5J

[Dan Marotta]

You're correct, Tim.  I just checked and the latest firmware for the
vario is dated 5/10/18.  I'll download that today.  Still, I'm getting
the same error message from OLC for the ClearNav II computer with the
latest firmware installed.

On 5/6/2019 10:04 AM, Tim Newport-Peace wrote:
> Not necessarily related, but I noticed that your Firmware is dated
> 10-Feb-2017. I feel sure that there have been updates since then.
>
> At 15:08 06 May 2019, Dan Marotta wrote:
>> Yes, the GPS jamming usually centers around Alamogordo and ranges out to

>> about 400 nm.  Moriarty is well within that area.  I've asked other

>> local pilots and they don't report so many drop outs.
>>

>> Maybe there are just too many GPS antennae in my ship.  I'll take a look
>> at a divider for everything except the ADS-B WAAS GPS.  Its antenna is
>> mounted aft of the engine in the Stemme.  The rest are on or under the

>> glare shield.
>>
>> On 5/5/2019 7:42 PM, JS wrote:
>>> On Sunday, May 5, 2019 at 3:43:24 PM UTC-7, Dan Marotta wrote:
>>>> Thanks Tim
>>>>
>>>> I'll increase my time interval to 2 seconds and see if that helps.
>>>>
>>>> Strange that the igc file does not show GPS drop outs since my
> ClearNav

>>>> screen went white with the caption (something like) No GPS.  Zero
>>>> satellites.  And the ClearNav vario said, "Warning no GPS".  The

--
Dan, 5J

[kinsell]

On 5/6/19 10:32 AM, Dan Marotta wrote:
> I've also had drop outs with my Trig TN-70 and its antenna, though not
> as often as with my soaring GPSs.

Do they correlate with the engine running? If so, might be ignition noise.

>
> Yes, the wires are tiny, but it was pretty simple to desolder them from
> the puck, clip the cable to length, strip, tin, and solder.  I did that
> for 3 antennae and they generally work fine, but lately have acting up.

It's easy to overheat the dielectric in the coax, causing loss of signal
strength.

>
> I'm looking at THESE

> <https://www.amazon.com/CIROCOMM-Antenna-Ceramic-25x25x2mm-Geekstory/dp/B078Y2WNY6?ref_=Oct_TopRatedC_3248676011_1&pf_rd_p=57ac2d87-b669-53fa-a2b6-2c15e8d66f28&pf_rd_s=merchandised-search-6&pf_rd_t=101&pf_rd_i=3248676011&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=GNQVSWJ3FAVNDTDDJJDS&pf_rd_r=GNQVSWJ3FAVNDTDDJJDS&pf_rd_p=57ac2d87-b669-53fa-a2b6-2c15e8d66f28>

[Dan Marotta]

These dropouts never occur during engine run which normally only runs 10
minutes or less from engine start to shutdown after takeoff.

Heating up the dielectric is something I didn't consider.  Maybe I
should replace the antennae...

--
Dan, 5J

[Tim Newport-Peace]

Returning to the original problem, the warning from OLC is not particularly
helpful. The only problem detected was the out-of-sequence times. If these
were caused by corruption of the GPS signal, it should not affect the time
record. A failure of GPS signal will be shown in the IGC file as a zero GPS
altitude. This is not the case, therefore we can take it that it is not a
GPS problem.

As the time error occurred during take-off, when the glider was only a few
feet AGL, it was long before the start of the ‘Soaring Performance’, so
OLC is being a bit pedantic. I very much doubt if a Badge Claim would have
noticed this. SeeYou just skips over it.

I see this as a problem owned by ClearNav, although I have seen similar
time sequence errors in other recorders over the years. It will be
interesting to see if it reappears with the latest firmware.

Tim.
--

At 22:20 06 May 2019, Dan Marotta wrote:
>These dropouts never occur during engine run which normally only runs 10
>minutes or less from engine start to shutdown after takeoff.
>
>Heating up the dielectric is something I didn't consider.  Maybe I
>should replace the antennae...
>
>On 5/6/2019 11:39 AM, kinsell wrote:
>> On 5/6/19 10:32 AM, Dan Marotta wrote:
>>> I've also had drop outs with my Trig TN-70 and its antenna, though
>>> not as often as with my soaring GPSs.
>>
>> Do they correlate with the engine running?  If so, might be ignition
>> noise.
>>
>>
>>>
>>> Yes, the wires are tiny, but it was pretty simple to desolder them
>>> from the puck, clip the cable to length, strip, tin, and solder.  I
>>> did that for 3 antennae and they generally work fine, but lately have
>>> acting up.
>>
>> It's easy to overheat the dielectric in the coax, causing loss of
>> signal strength.
>>
>>

>>>

[kinsell]

Looking at your flight logs on OLC, you have the last two that didn't
validate, but others earlier this year that did.

However, most of the altitude graphs are plotted with many hours of dead
time, with the flight being compressed into the very right hand part of
the graph. A very bizarre presentation.

Perhaps your ClearNav has a hardware fault that is gradually getting worse?

[Dan Marotta]

Another thought:  Richard Kellerman advised me to snug the connectors
with a wrench.  Mine are probably only hand tight. Another small task...

[Dan Marotta]

No help from ClearNav (yet).  I've updated the CNvXC firmware but not
flown with it yet.  It's overcast here...  As stated elsewhere, I'll
snug the connectors with a wrench (spanner), and I've relocated the
antenna pucks further apart, though a local pilot tells me he has four
antennae lined up next to each other and has no problems with reception.

Elsewhere I said that I don't have drop outs with the engine running. 
That was not entirely true.  I've had drop outs during repositioning
flights over the Rocky Mountains at 18,000' MSL.  It's very annoying but
I can see where I'm going and I'm not scoring those flights.

If I lose any more flights, I'll have to buy new antennae...

On 5/7/2019 2:21 AM, Tim Newport-Peace wrote:
> Returning to the original problem, the warning from OLC is not particularly
> helpful. The only problem detected was the out-of-sequence times. If these
> were caused by corruption of the GPS signal, it should not affect the time
> record. A failure of GPS signal will be shown in the IGC file as a zero GPS
> altitude. This is not the case, therefore we can take it that it is not a
> GPS problem.
>
> As the time error occurred during take-off, when the glider was only a few

> feet AGL, it was long before the start of the ‘Soaring Performance’, so

> OLC is being a bit pedantic. I very much doubt if a Badge Claim would have
> noticed this. SeeYou just skips over it.
>
> I see this as a problem owned by ClearNav, although I have seen similar
> time sequence errors in other recorders over the years. It will be
> interesting to see if it reappears with the latest firmware.
>
> Tim.

--

Dan, 5J

[Dan Marotta]

An interesting thought, but I see the same whether I'm using the
ClearNav or the ClearNav vario.  I doubt both could be experiencing the
same fault at the same time.  It's really odd about the apparent time
compression on the OLC display.  My flights score and appear just fine
on skylines.aero.

--
Dan, 5J

[Dave Nadler]

On Tuesday, May 7, 2019 at 4:30:05 AM UTC-4, Tim Newport-Peace wrote:
> ... I have seen similar time sequence errors in other recorders over the years...

IIRC I've seen this from a number of GPS engines;
certainly I've got some Garmin engine logs like this.
The problem is naive software that doesn't filter
'obviously' wrong stuff from the GPS engine, including
time going backwards and stupendous position jumps.
Some nice example traces here momentarily detour
from Montana into the North Atlantic for example...

None of my collected examples were (to my best
understanding) related to jamming.

Its important not to trust too much the inputs ;-)

See ya, Dave

[Tom Kelley #711]

Dan, my ClearNav XC logger, when downloaded to the OLC, appears to display the same as yours(time compression to the right). I used my Flarm IGC logger and it appears normal for the OLC. Yet on Skyline aero, Cross-country aero and See you, the ClearNav logger displays and views as normal.

The last several flights I have had experience GPS dropouts, which on Sunday seemed odd, and lasted only several minutes at a time(I fly out of KALM and the loss of signal was in numerous areas on Sunday). All the updates have been done, now several times over, yet the ClearNav logger and OLC just don't get along, yet the flight is scored and shows valid. Don't get an OLC speed when using the ClearNav.

When you figure this out, let us know!

Best. Tom #711

[Dan Marotta]

Will do, Tom. Thanks.

I don't use the Flarm portable because it uses an SD card which is a
hassle and mine doesn't have an ENL license.  I'm not interested in
buying a license for such an old piece of equipment.  Besides, my
soaring income and bevy of chicks has not declined since having these
problems...

--
Dan, 5J

[kinsell]

I can't fault software for failing to filter out bad data. Having
submitted a number of logs to OLC from a cell phone, I don't see the
type of errors described here. Maybe better gps engines are in order?
Seems like producing good data is better than filtering out bad data.

[Dan Marotta]

> I can't fault software for failing to filter out bad data.  Having
> submitted a number of logs to OLC from a cell phone, I don't see the
> type of errors described here.  Maybe better gps engines are in order?
> Seems like producing good data is better than filtering out bad data.

What you say has merit, but I can't see opening up my ClearNav computer
and vario and attempting to replace the GPS engines.

Since both and my PowerFlarm portable experience the drop outs, I've got
three new antennae on order.  We'll see how that works.

Funny how this just started happening in the end of April...
--
Dan, 5J

[Martin Gregorie]

On Wed, 08 May 2019 08:58:39 -0600, Dan Marotta wrote:

> Funny how this just started happening in the end of April...
>

I thought: have you got another logger you could leave running on the
field away from the runway but where it gets a decent signal?

If that also gets the time hiccup, then you'll know the problem is
outside the Stemme.


--
Martin | martin at
Gregorie | gregorie dot org

[Dan Marotta]

I have a Dell Streak in the cockpit (right side) for my wife's use. It
also records an igc file which I can post on skylines.org.  It is not
acceptable to OLC due to no ENL recorder.  Maybe the XCSoar troops would
write a module to access the Streak's microphone and record engine
noise...  Or maybe one of the XCSoar clones already does that?

On 5/8/2019 12:16 PM, Martin Gregorie wrote:
> On Wed, 08 May 2019 08:58:39 -0600, Dan Marotta wrote:
>
>> Funny how this just started happening in the end of April...
>>
> I thought: have you got another logger you could leave running on the
> field away from the runway but where it gets a decent signal?
>
> If that also gets the time hiccup, then you'll know the problem is
> outside the Stemme.
>
>

--

Dan, 5J

[kinsell]

I see a flight on Jan 27 this year that had the same highly compressed
altitude graph, so something wasn't right well before end of April.

Sounds like you've got problems due to jamming, in addition to at least
one other issue.

Should be plenty of other gliders flying out of Moriarty to compare logs
with. Suppose you could submit one from the Dell Streak and lie about
the glider type, then delete it after seeing how OLC likes it.

-Dave

[Dan Marotta]

Good idea.  I noticed the time compression some time ago but chalked it
to OLC doing something new.  It's cloudy and rainy today but I need to
go to the airport anyway.  I'll get the Streak.

--
Dan, 5J

[kinsell]

Your May 3 flight is interesting. Hours worth of altitude data is
missing on the OLC graph, but the rest of the trace is shown. This is
different than the altitude data being compressed to the right.

Looking at the GPS altitude on SeeYou, there's one dropout of data
towards the end of the flight, apparently at the point where OLC started
showing altitude data on their graph.

So maybe one short loss of data is screwing up the OLC scoring and graphing.

[Tom Kelley #711]

On Sunday, May 5, 2019 at 9:38:57 AM UTC-6, Dan Marotta wrote:
> For my last three flights I've been getting a message from OLC warning
> of implausible time records in the igc file.  Does anyone know what this
> means and what I might do to correct the problem? I've asked the
> question on the ClearNav forum but haven't gotten a reply yet.
>
> Here's a link to the file if that helps:
> https://www.dropbox.com/s/erm01jilimuqudd/2019-05-04-CNI-V8Q-01.IGC?dl=0
> --
> Dan, 5J

I sent my CN XC IGC 5-5-19 flight to a friend which when I posted it to the OLC did the same compression as the 5-3-19 flight did. When he posted it, it showed normal....ya. Now the CN XC IGC flight on 5-15-19 did the same compression to the right. So, I used the Flarm IGC file again on the OLC.
See You shows the files are valid on the CN XC IGC loggers and when altitude is checked shows fine. OLC gives 2 green circles with all the CN XC files.

I never had this problem before until I did the last update over winter with the CN XC Vario IGC logger. Yesterday I sent T8 the IGC logger file from 5-15-19 and they will be looking into it.

On the 5-15-19 flight, I did have GPS drop out several times, but the Flarm IGC logger doesn't seem to get affected for the OLC. Also, had several F-16's fly by and a B-1B bomber come right under me. I do know where ever I fly, with my transponder, my altitude is always getting shown by certain folks playing war games. On the B-1B I couldn't see through the cockpit windows to see what color helmets they had on...........!

Best. Tom @711.

[Dan Marotta]

Is there a way to roll back to the previous versions of CN2 and CNvXC?

--
Dan, 5J

[Tango Eight]

A possible work around is to download your flight using an alternate time interval. CN flight recorders store internally at one second, can d/l at user selectable intrval up to 8 sec (iirc).

Best,

Evan Ludeman

[michae...@gmail.com]

Dan,
Just FYI, I got the same error last night on an IGC flle from an Lx9070, so it may not be a CN issue.
lx9070 was updated to latest software version on 4/8/19.

This is what I see in my file:
B1813373310143N08621921WA01030011060060011138511773067-006602030130-041003
B1813383310151N08621903WA01030011060070041135612041053-004602030130-043003
B1813393310164N08621887WA01030011070060041119612285040-003602030130-042003
LLXVCLOCKJUMP
B1813373310179N08621875WA01031011070060041108912507026-003602030120-039003
B1813383310197N08621867WA01032011070060041100212740014-004102030120-038001
B1813393310216N08621863WA01031011070060041092612992002-004102030120-034001

[kinsell]

Looks like both you and Dan show a UBLOX NEO as the GPS receiver, maybe
a problem with new firmware from the vendor?

[Dan Marotta]

Thanks Evan.  As a retired Systems Engineer, I've made a lot of work
arounds and they're not very satisfying.  The problem needs to be fixed.

If it's from the GPS engine manufacturer, they should fix it.  Do both
the vario and the CN2 computer use the same GPS?  It seems unlikely that
both CN and LX would make the same error in their code.

I'll look into a longer download interval but how about my previous
question?  Is there a way to roll back to the previous firmware versions.

--
Dan, 5J

[michae...@gmail.com]

Kinsell, You may be on the right track.
Backup recorder (portable powerflarm) with separate gps system, recorded fine during the same period.

[kinsell]

On 5/20/19 6:43 AM, michae...@gmail.com wrote:
> Kinsell, You may be on the right track.
> Backup recorder (portable powerflarm) with separate gps system, recorded fine during the same period.
>

I notice your Oct 2 2018 flight on OLC had that peculiar highly
compressed altitude graph, but without the gps altitude dropouts. Maybe
that's just some unrelated OLC display issue.

Ublox receivers are used for many other applications besides flight
recorders, wonder why nobody else seems to be having problems.

I've been submitting from a PF Core the last few years, haven't seen any
of these issues.

[michae...@gmail.com]

Ref >.

>I notice your Oct 2 2018 flight on OLC had that peculiar highly
>compressed altitude graph, but without the gps altitude dropouts. Maybe
>that's just some unrelated OLC display issue.

Good observation, I didn’t notice that.
The one on 10/4 has the same compressed altitude issue, while the one on 10/3 looks ok, as does the flight on 5/1/19.
I have been posting to OLC from that particular 9070 for about 4 years and haven’t had a problem before now.

MS

[kinsell]

Also I notice your Oct 2 log had a 2 second backwards jump in the time
stamp, nicely pointed out by a CLOCKJUMP message.


B1836063309906N08617890WA007930091400899909260106391370014102310100
B1836073309895N08617877WA007970091800899909934105261320019502310100
B1836083309885N08617862WA008010092200899909689103141260027202310100
B1836093309877N08617847WA008040092600899909738102111210032602300100
LLXVCLOCKJUMP
B1836073309869N08617831WA008090093100899909112099941150032402300110
B1836083309863N08617815WA008150093600899908750098401100029902300090
B1836093309859N08617798WA008180094000899909236098091040030802290090
B1836103309856N08617781WA008220094200899909608098751000036802290080



So these problems have been around for quite a while, maybe OLC just
started flagging them as fatal errors?

[kinsell]

Looking at your Aug 2 2017 flight, it shows the same compressed altitude
graph, and another 2 second backwards jump in a time stamp. Wow.

[Charlie M. (UH & 002 owner/pilot)]

Maybe he is exceeding VNE by a lot and going back in time? I wonder what Doc Brown would say.....LOL...

[michae...@gmail.com]

I’ve not heard back from Lxnav yet, but I had a private email from a very smart person that pointed out that both the October 2 and October 4 flights had the clock jump after takeoff but before soaring began. The flight this week had the clock jump a minute or so after soaring began, and thus is likely why OLC flagged this one and not the other two. It appears that the clock jump is 7 to 8 minutes after the unit is turned on. Since I generally do not turn the system on until just before takeoff, it is believed that the system is using an internal clock until it syncs with the gps satellites and then resets the clock which may be different by a couple of seconds. My plan is to turn the 9070 on a few minutes before launch to allow it to sync clocks to see if that helps. It is not clear to me if Dan’s issue is similar to mine or different.

MS

[Dan Marotta]

That's certainly worth a try.  My normal method is to saddle up, start
the engine, and turn on the CN2, the CN vario, and the PowerFlarm
portable (which does not have an ENL license).  Then I run checklists
and taxi out and, as soon as the temperatures are in the green, take
off.  I'll try turning on the computers first and take my time with
getting started and to the hold short line.  I'll shoot for 10 minutes
and see how that goes.

On 5/20/2019 2:42 PM, michae...@gmail.com wrote:
> I’ve not heard back from Lxnav yet, but I had a private email from a very smart person that pointed out that both the October 2 and October 4 flights had the clock jump after takeoff but before soaring began. The flight this week had the clock jump a minute or so after soaring began, and thus is likely why OLC flagged this one and not the other two. It appears that the clock jump is 7 to 8 minutes after the unit is turned on. Since I generally do not turn the system on until just before takeoff, it is believed that the system is using an internal clock until it syncs with the gps satellites and then resets the clock which may be different by a couple of seconds. My plan is to turn the 9070 on a few minutes before launch to allow it to sync clocks to see if that helps. It is not clear to me if Dan’s issue is similar to mine or different.
>
> MS

--
Dan, 5J

[moshe....@gmail.com]

On Monday, May 20, 2019 at 4:42:52 PM UTC-4, michae...@gmail.com wrote:
> I’ve not heard back from Lxnav yet, but I had a private email from a very smart person that pointed out that both the October 2 and October 4 flights had the clock jump after takeoff but before soaring began. The flight this week had the clock jump a minute or so after soaring began, and thus is likely why OLC flagged this one and not the other two. It appears that the clock jump is 7 to 8 minutes after the unit is turned on. Since I generally do not turn the system on until just before takeoff, it is believed that the system is using an internal clock until it syncs with the gps satellites and then resets the clock which may be different by a couple of seconds. My plan is to turn the 9070 on a few minutes before launch to allow it to sync clocks to see if that helps. It is not clear to me if Dan’s issue is similar to mine or different.
>
> MS

We've established in another thread some months ago that the display of altitudes of a flight within the OLC web page is all messed up if OLC thinks that the flight "started" later, at some higher logged altitude, rather than at the altitude of the declared takeoff airport. (Typically due to the flight recorder not getting a GPS fix - or not being turned on at all - until after takeoff.) I am still of the opinion that this should be considered a bug in OLC, since it can "see" that the start location (lat/lon as well as altitude) is not at the airport. The altitudes inside the flight log file, even as downloaded from OLC, are still OK. Perhaps the time jump, too, makes OLC think it's a new "takeoff", and thus has similar consequences in its display (plus its "implausible" warning).

But I don't quite understand the conjecture that "the system is using an internal clock until it syncs with the gps satellites", because prior to getting a GPS fix the flight recorder shouldn't be recording locations into the flight log either, no?

[kinsell]

On 5/20/19 2:42 PM, michae...@gmail.com wrote:
> I’ve not heard back from Lxnav yet, but I had a private email from a very smart person that pointed out that both the October 2 and October 4 flights had the clock jump after takeoff but before soaring began. The flight this week had the clock jump a minute or so after soaring began, and thus is likely why OLC flagged this one and not the other two. It appears that the clock jump is 7 to 8 minutes after the unit is turned on. Since I generally do not turn the system on until just before takeoff, it is believed that the system is using an internal clock until it syncs with the gps satellites and then resets the clock which may be different by a couple of seconds. My plan is to turn the 9070 on a few minutes before launch to allow it to sync clocks to see if that helps. It is not clear to me if Dan’s issue is similar to mine or different.
>
> MS
>

They do have clocks to help achieve lock on the satellites, but I've
seen the reported time jump immediately after lock was achieved. Don't
know why the 9070 would wait minutes after achieving lock before
correcting the time. Maybe an issue of 2D vs 3D lock. If you're
turning on the logger immediately before takeoff, you're risking losing
the early part of the flight entirely, not just having time problems.

Dan was having lots of gps altitude dropouts during flights, that might
just be jamming. He did have a time jump just at liftoff, so that fits
in with switching the clocks.

[michae...@gmail.com]

>But I don't quite understand the conjecture that "the system is using an internal clock until it syncs with the gps satellites", because prior to getting a GPS fix the >flight recorder shouldn't be recording locations into the flight log either, no?

Yes, the system seems to have a fix on the satellites and the Lat/Lon/Alt seems to be consistent from one record to another. It certainly doesn’t take several minutes for the system to get a gps fix. The question is why does it record an incremental time for a few minutes and then resets the time by a couple of seconds. It would seem the system should record the time stamp directly from the gps. If it did that, how could sequential time records change? Is it possible the gps starts with an internal clock number initially and then after a few minutes makes a comparison check with the clock from the gps? It gets back to Kensell’s point about how the gps system is handling the data and or the firmware is using the info inside the computers. These seem like good questions for vendors which I hope to get soon.

[michae...@gmail.com]

> If you're turning on the logger immediately before takeoff, you're risking losing
>the early part of the flight entirely, not just having time problems.

Good point. I’m not usually worried about the igc file much for casual flights which is what these all were. Or at least I wasn’t worried until the OLC problem.
Of course for record, badge, or contest flights; I turn the computer and backup loggers on long before takeoff since tasks have to be entered and checked.
You may be on the right track with the 2D vs 3D lock. I will try to look at the gps satellite status page before takeoff in the future.

[Tim Newport-Peace]

I've looked at Dan's trace, and the dropouts are in the latter part of the
flight,
nowhere near the time when the clock problem occurs, so probably not
jamming. Micheal's flight shows no GPs dropouts at all, but still
experienced
the problem.

[Dan Marotta]

So...  Does having a 3D fix with, say 8 satellites, constitute good GPS
time?  I would think so.

--
Dan, 5J

[kinsell]

You would think 8 satellites would be plenty. Looking at some
discussion on the Ublox site, apparently it's more complicated than time
valid vs not valid. There's flags that differentiate between low
accuracy satellite time vs high accuracy. Probably of no significance
in our application. I'll bet the FR code could be tweeked to use
satellite time when they're recording x-y-z data.

Or you could be more conservative in making sure the gps is fully locked
up before takeoff, works for me. My recorders come on with the master,
by the time I'm ready for takeoff they've had plenty of time and
checking the displays confirms that.

[Dave Leonard]

Maybe has to do with waiting to get the current almanac to know how many leap seconds to apply to received GPS time to get to UTC time used for the logs? Waiting for the whole message can take over 10 minutes.

[Dave Leonard]

Check the discussion here:
https://portal.u-blox.com/s/question/0D52p00008HKCbFCAX/what-is-time-error-if-utc-fully-resolved-flag-not-asserted

[michae...@gmail.com]

>Maybe has to do with waiting to get the current almanac to know how many leap seconds to apply to received GPS time to get to UTC time used for the logs? >Waiting for the whole message can take over 10 minutes.

Dave, thanks for the info and link. I had no idea about the gps errors, inaccuracies, atomic clock drift, leap seconds, etc; until doing a few searches.
Now I see why the clock time can change and have a greater appreciation for the difficulty GPS receiver manufacturers must deal with. It appears our real problem is that OLC does not know how to handle normal events within the log files. Other soaring analysis programs seem to know to expect such events.

I had an email from lxnav that they noticed this issue a few weeks ago. While I updated on April 8; there is a new May 7 update that should help.

[Dan Marotta]

Well then, since I rig the wings in the hangar area and then tow the
glider to the apron for final prep before take off, I'll turn on the CN
devices at that time.  Some times it's an hour or more before I take
off.  That should give the hardware plenty of time to figure out what
time it is.

Griping hat on...  We're not planning a nuclear strike here, just
getting bragging rights about a meaningless fun flight.  It's ridiculous
that OLC acts like the bully on the play ground, enforcing unnecessary
rules.  Griping hat off...

--
Dan, 5J

[kinsell]

Yes, but the number of leap seconds to apply changes so infrequently
that it's silly to wait for that information to be downloaded at each
powerup.

GPS engines are free to store almanac and ephemeris data and shorten the
initialization time considerably, many of them do. I would say that the
Ublox behavior of waiting 10 minutes plus after achieving a 3D lock to
do corrections to the time is out of the ordinary.

So we have the perfect storm of a slow gps engine, pilots who don't
think they need to wait for the gps to lock up before takeoff, and OLC
doing stringent checking on the quality of the data. Of those three, I
would say OLC is the least at fault in all this.

[kinsell]

As a side note, I've used Ublox engines for Stratux boxes, was quite
happy with them. They seemed sensitive, quick to lock up, and certainly
were dirt cheap. Maybe they do cache the almanac data, but have some
bug in them that explains the big delay in getting the time right.

[Tango Eight]

I don't have time to catch up on this thread right now but good job on the leap second issue.

CN flight recorders update the UTC offset typically around five minutes after GPS lock.

Short term work around is to power up more than five minutes before launch, use 4 second record interval (which should mask the problem if the offset change happens in flight).

This is preliminary info... but seems to fit all the observed problems so far.

Best regard,
Evan Ludeman for CNi

[Dan Marotta]

Thanks Evan.

Out of town visitors and typical spring winds at Moriarty have kept me
on the ground.  Maybe Sunday...

--
Dan, 5J

[Dan Marotta]

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.

On 5/5/2019 9:38 AM, Dan Marotta wrote:
> For my last three flights I've been getting a message from OLC warning
> of implausible time records in the igc file.  Does anyone know what
> this means and what I might do to correct the problem? I've asked the
> question on the ClearNav forum but haven't gotten a reply yet.
>
> Here's a link to the file if that helps:
> https://www.dropbox.com/s/erm01jilimuqudd/2019-05-04-CNI-V8Q-01.IGC?dl=0

--
Dan, 5J

[kinsell]

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.
>
> On 5/5/2019 9:38 AM, Dan Marotta wrote:
>> For my last three flights I've been getting a message from OLC warning
>> of implausible time records in the igc file.  Does anyone know what
>> this means and what I might do to correct the problem? I've asked the

>> question on the ClearNav forum but haven't gotten a reply yet. the

>>
>> Here's a link to the file if that helps:
>> https://www.dropbox.com/s/erm01jilimuqudd/2019-05-04-CNI-V8Q-01.IGC?dl=0
>

Do the dropouts match up with published times for GPS jamming? Your
trace shows tons of gps altitude dropouts between about 15:00 and 16:00
local time, but clean otherwise. They do correspond to the NE leg of
your flight, but that may just be coincidence.

[Tim Newport-Peace]

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 Marotta]

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

[Papa3]

Adding anecdotal evidence to the startup idea... I had my first-ever "implausible time record" failure on my ClearNav two weeks ago. It was an unusual flight, as I realized after takeoff that I didn't have the right databases loaded (turnpoints and airspace) since I was flying "off the map" from our typical task area (it was a really good day). About 45 minutes into the flight I went to load the full US Airspace file, and the ClearNav locked up. I power cycled it and it cleared everything, but a few minutes after the approximate point of the power cycle I got the implausible time record. I did get another one later in the flight as well, but all flights before and since have been fine.

P3

[Tim Newport-Peace]

At 15:56 26 May 2019, Dan Marotta wrote:

>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.
>

Interestingly, in your flight 2019-05-04-CNI-V8Q-01, not only were there
lots of loss of 3D logging (dropouts), but around 22:23:09 (UTC) the GPS
altitude rose to an amazing 163,215 feet (Eat you heart out Perlan).

[Dan Marotta]

Yaas...  My cannula was working over time!

On 5/26/2019 3:58 PM, Tim Newport-Peace wrote:
> At 15:56 26 May 2019, Dan Marotta wrote:
>
>> 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.
>>
> Interestingly, in your flight 2019-05-04-CNI-V8Q-01, not only were there
> lots of loss of 3D logging (dropouts), but around 22:23:09 (UTC) the GPS
> altitude rose to an amazing 163,215 feet (Eat you heart out Perlan).
>
>
>

--
Dan, 5J

[kinsell]

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.

[Dan Marotta]

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.

--
Dan, 5J

[Tango Eight]

How to change the igc flight log time interval on CN2:
https://youtu.be/AkJwwCbGMZQ

CN2 stores logs internally at 1 second. You can d/l to USB at 1, 2, 4 or 10 second intervals.

Please pay close attention to the voice over. There is one especially non-obvious press of the down arrow key.

We think that d/l at 4 second interval solves (really: masks) the discontinuity that occurs when the UTC - GPS time offset update is received from the GPS system.

best regards,
Evan Ludeman for CNi

[Dan Marotta]

Thanks, Evan.

I figured it out at home using the CN2 simulator.

--
Dan, 5J

[hret...@aol.com]

Well, here I am in Cordele with R5S starting on Monday and got the OLC time error message after submitting my ClearNav II log for yesterday’s flight.
So, downloaded CN vario version and got the same error message. For thrills I loaded a flight on 5/15/19 and although OLC advised late, accepted the flight into the system. I have changed nothing nor updated either unit since 5/15 so why then, not now?
I will look at and change the interval to 4 secs and try again ( as mentioned by T8 in this thread).
Questions and request...
Will I have issues with scoring during the contest (winscore)?
I would appreciate if someone would post an update summary of do and don’t and ideas in a simple to grasp way that even an airline pilot might follow.
Many thanks.
R

[kinsell]

On 5/30/19 6:01 AM, hret...@aol.com wrote:
> Well, here I am in Cordele with R5S starting on Monday and got the OLC time error message after submitting my ClearNav II log for yesterday’s flight.
> So, downloaded CN vario version and got the same error message. For thrills I loaded a flight on 5/15/19 and although OLC advised late, accepted the flight into the system. I have changed nothing nor updated either unit since 5/15 so why then, not now?

It's likely OLC just recently added the check for bad time records.

> I will look at and change the interval to 4 secs and try again ( as mentioned by T8 in this thread).

That should work. You have 48 hrs after flight ended to delete bad data
and try again.

> Questions and request...
> Will I have issues with scoring during the contest (winscore)?

It's highly unlikely a program like Winscore would have have problems,
even if you turn in a log with a glitch. No reason to turn in a log
with the glitch.

> I would appreciate if someone would post an update summary of do and don’t and ideas in a simple to grasp way that even an airline pilot might follow.

You can either download with the 4 second intervals, or you can turn on
your loggers early. I would wait until you get a 3D lock indication,
then add ten minutes before takeoff. You can do both if you want.

Dave


> Many thanks.
> R
>

[Tango Eight]

Hi Henry,

There will be no issue with Winscore.

What's going on here:

1. UTC and GPS time are not the same. The current offset is 18 seconds.

2. When the GPS starts up, it starts with an offset programmed in firmware. This offset is less than 18 seconds.

3. After GPS lock, the GPS receiver gets the current offset from the system, typically about 5 minutes after GPS lock. It applies the new offset immediately, and the jump causes one out of sequence B record if the flight recorder is recording. It doesn't start recording until you are flying.

4. OLC picks up the out of sequence B record if it exists.

Since the offset change is 2 or 3 seconds, it can be masked by setting the igc file fix interval to 4 seconds. You can avoid the jump altogether by powering up > 5 minutes before flying.

If you get a bad OLC result, you can fix it by downloading your flight again at either 4 or 10 second interval and resubmitting.

best regards,
Evan Ludeman

[hret...@aol.com]

Thanks to the brain trust for the easy to understand summary.....the sport has improved due to the smart guys.
I will save and pass on to others.
Great flights!

R

[Dan Marotta]

I've made two flights since experiencing the problem.  Since then, I've
turned on my CN devices 20 or so minutes before takeoff and have not
seen a repeat of the problem.

--
Dan, 5J

[Tom Kelley #711]

I sent T8 an update yesterday on my XC logger. I had it on 2 secs and changed to 4 secs and turned it on 12 minutes prior to launch. All problems have now gone on the OLC.
Best. #711.

[hret...@aol.com]

OK.....I would turn on, load task, turn off.....back on with sometimes less than 10 mins to launch to save battery power (bad habit from using non LiPo batteries).
This is probably the cause of my issue as it just started.
I was doing it because my CN shows 11.2 volts, but my Dittle radio shows 12.4 on LiPo bat.
Thanks for info.
R

[John Godfrey (QT)]

You might want to check the wiring to/from the CV (esp the ground). 1.2 volts is a lot of difference IMO.

[Tango Eight]

On Friday, May 31, 2019 at 7:53:14 AM UTC-4, hret...@aol.com wrote:

Sounds like a bad (high resistance) circuit breaker.

-Evan

[kinsell]

I've been using good ele SLA batteries for years, they keep the panel
voltage above 12 volts even on 7 hr flights. Never occurred to me to
try to save ten minutes of juice on the ground.

Hope you've got your LiPo's in a good steel box like the 787's do.

[SoaringXCellence]

> Hope you've got your LiPo's in a good steel box like the 787's do.

Not LiPo but LiFePo. not a fire hazard, different chemistry altogether.

[hret...@aol.com]

Ok...will check wiring,ground,CB, fuses...for possible cause of voltage drop.Thanks
LiPo, fire, 787.....greater chance dying on the highway to from contest. Plus, have not heard of any little LiPos fire issues.
Going with the 15+ mins on rule.
check

R