A aviation & planes forum. AviationBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » AviationBanter forum » rec.aviation newsgroups » Soaring
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Implausible Time Records



 
 
Thread Tools Display Modes
  #51  
Old May 20th 19, 11:11 PM posted to rec.aviation.soaring
[email protected]
external usenet poster
 
Posts: 42
Default Implausible Time Records

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.
Ads
  #52  
Old May 21st 19, 12:35 AM posted to rec.aviation.soaring
Dan Marotta
external usenet poster
 
Posts: 3,578
Default Implausible Time Records

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

On 5/20/2019 3:27 PM, kinsell wrote:
On 5/20/19 2:42 PM, 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.


--
Dan, 5J
  #53  
Old May 21st 19, 03:34 AM posted to rec.aviation.soaring
Dave Leonard
external usenet poster
 
Posts: 35
Default Implausible Time Records

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.


On Monday, May 20, 2019 at 6:38:44 PM UTC-6, kinsell wrote:
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.




  #54  
Old May 21st 19, 04:06 AM posted to rec.aviation.soaring
Dave Leonard
external usenet poster
 
Posts: 35
Default Implausible Time Records

Check the discussion he
https://portal.u-blox.com/s/question...g-not-asserted


On Monday, May 20, 2019 at 8:34:07 PM UTC-6, Dave Leonard wrote:
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.


  #55  
Old May 21st 19, 01:54 PM posted to rec.aviation.soaring
[email protected]
external usenet poster
 
Posts: 42
Default Implausible Time Records

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.
  #56  
Old May 21st 19, 03:23 PM posted to rec.aviation.soaring
Dan Marotta
external usenet poster
 
Posts: 3,578
Default Implausible Time Records

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

On 5/20/2019 9:06 PM, Dave Leonard wrote:
Check the discussion he
https://portal.u-blox.com/s/question...g-not-asserted


On Monday, May 20, 2019 at 8:34:07 PM UTC-6, Dave Leonard wrote:
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.



--
Dan, 5J
  #57  
Old May 21st 19, 06:42 PM posted to rec.aviation.soaring
kinsell
external usenet poster
 
Posts: 206
Default Implausible Time Records

On 5/20/19 9:06 PM, Dave Leonard wrote:
Check the discussion he
https://portal.u-blox.com/s/question...g-not-asserted


On Monday, May 20, 2019 at 8:34:07 PM UTC-6, Dave Leonard wrote:
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.



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.
  #58  
Old May 22nd 19, 03:54 PM posted to rec.aviation.soaring
kinsell
external usenet poster
 
Posts: 206
Default Implausible Time Records

On 5/21/19 11:42 AM, kinsell wrote:
On 5/20/19 9:06 PM, Dave Leonard wrote:
Check the discussion he
https://portal.u-blox.com/s/question...g-not-asserted



On Monday, May 20, 2019 at 8:34:07 PM UTC-6, Dave Leonard wrote:
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.



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.



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.
  #59  
Old May 23rd 19, 01:24 PM posted to rec.aviation.soaring
Tango Eight
external usenet poster
 
Posts: 733
Default Implausible Time Records

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


  #60  
Old May 23rd 19, 03:27 PM posted to rec.aviation.soaring
Dan Marotta
external usenet poster
 
Posts: 3,578
Default Implausible Time Records

Thanks Evan.

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

On 5/23/2019 6:24 AM, Tango Eight wrote:
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, 5J
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
All US Records are Now Motor Glider Records Tango Eight Soaring 99 March 23rd 17 12:07 PM
OT 4 airport round robin - time lapsed / real time with ATC COMS -video A Lieberma[_2_] Owning 0 August 30th 09 12:26 AM
OT 4 airport round robin - time lapsed / real time with ATC COMS -video [email protected] Instrument Flight Rules 0 August 30th 09 12:26 AM
4 airport round robin - time lapsed / real time with ATC COMS - video [email protected] Piloting 0 August 30th 09 12:25 AM
they took me back in time and the nsa or japan wired my head and now they know the idea came from me so if your back in time and wounder what happen they change tim liverance history for good. I work at rts wright industries and it a time travel trap tim liverance Military Aviation 0 August 18th 03 12:18 AM


All times are GMT +1. The time now is 10:46 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Copyright 2004-2019 AviationBanter.
The comments are property of their posters.