After too many years to mention, a file I submitted to OLC was not excepted from my ancient version of SeeYou on a PDA? It gave a crazy error message that Oct 2, 2003 was in the log. I might be wrong but I am sure the date and time are gotten fromthe GPS signal so how can that be?? Maybe my ancient version of Seeyou is now behaving a different way or the GPS signal format has changed recently? Be curious of others have experienced something similar. It was less than a month ago all was OK.
On 3/27/23 8:08 PM, BG wrote:> I might be wrong but I am sure the date
and time are gotten from the GPS signal so how can that be??
The original GPS system only transmitted enough information to determine
the year within an 18.6 year range. Beyond that, receivers had to
determine how many rollovers had occurred since the ssytem went into operation. They usually did this by a small amount of RAM kept alive
with a tiny rechargeable battery. If the battery ever got discharged,
then the receiver had to be serviced, or sometimes software in the
receiver could be updated to patch the problem.
Since this is the beginning of the season in the top half of the world,
the most likely scenario is that your tiny battery wasn't kept
adequately charged over the winter, and the RAM lost track of how many rollovers have occurred.
The GPS system has long been upgraded to fix the problem, but old
receivers don't receive the enhanced signals that fix the date problem.
-Dave
On 3/27/2023 10:08 PM, BG wrote:
After too many years to mention, a file I submitted to OLC was not
excepted from my ancient version of SeeYou on a PDA? It gave a
crazy error message that Oct 2, 2003 was in the log. I might be
wrong but I am sure the date and time are gotten from the GPS signal
so how can that be?? Maybe my ancient version of Seeyou is now
behaving a different way or the GPS signal format has changed
recently? Be curious of others have experienced something similar.
It was less than a month ago all was OK. I submitted the same
flight captured by my Flarm box and all was OK.
Sounds like your PDA is so "ancient" that the GPS unit you use with it
has rolled over the GPS "epoch" (1024 weeks - the time from Oct. 2003
until now). It's a problem with the GPS (or one may say, the design of
the GPS system as a whole), not SeeYou. Your GPS module may or may not
be fixable or replaceable. You can manually edit the date in the header
of the flight log (it's plain text, open it in Wordpad) - but then the
log's "security" will be broken and OLC will punish you with a different color security icon.
Way back when, the system engineer decided that no electronic device
would EVER need no more than 10 bits for the date field since (he
thought) no electronic device would last longer than that. OR, the components of the time were not capable of supporting the extra bits to
make the epoch 2048 or 4096 weeks.
Kinda like the Y2K panic back in 1999. I was a systems engineer at FlightSafety back then and rolled my eyes at the stupidity of those
earlier engineers who made us replace a lot of computer code and
hardware to add one byte to the date field. My wife, a software
engineer at the time, was one of only a couple of passengers on a DC to Denver flight on 12/31/99. Everyone else thought the world would come
to an end and planes would fall from the sky at the rollover. Kinda
like "atmospheric rivers" we hear about today...
It's different today: I just saw a 1 TB USB stick on Amazon for under $35.
Date problems haven't all been fixed, some older Unix systems and
derivatives will start reporting 1910 as the date in 2038 due to some
integer hitting 2.1 billion seconds (2^31).
Ain't that (2^32)-1 or 4.3 billion? In any case, my flying then, if at
all, will probably be limited to the carnival ride... Hope not!
Dan
5J
On 3/28/23 19:50, kinsell wrote:
Date problems haven't all been fixed, some older Unix systems and
derivatives will start reporting 1910 as the date in 2038 due to some
integer hitting 2.1 billion seconds (2^31).
Ain't that (2^32)-1 or 4.3 billion? In any case, my flying then, if at
all, will probably be limited to the carnival ride... Hope not!
On Wed, 29 Mar 2023 10:17:38 -0600, Dan Marotta wrote:
Ain't that (2^32)-1 or 4.3 billion? In any case, my flying then, if atA lot of the Y2K problems (i.e. GPS as well as *NIX [and Windoze ?]) can
all, will probably be limited to the carnival ride... Hope not!
be blamed on whoever thought it would be a good idea to shoehorn both date and time of day into a single integer variable.
Back in the day, before micro- or minicomputers existed, most systems kept the current date and time in two separate variables, so for instance, in
an ICL 1900, which used 24 bit words with date zero defined as 31 December 1899, you wouldn't have hit its Y2K moment until some time in September
24865 AD. I'd guess the same applies to Big Blue's boxen too or COBOL wouldn't have defined DATE and TIME as two separate system variables.
Yep. The GPS debacle was caused by limited bits of information
transmitted by the satellite, compounded by makers of receivers who
thought storing a few more bits in static RAM, powered by a tiny
battery, was adequate to address the situation. Once the battery gets discharged, no amount of recharging fixes it. No provision is made to
let the user set the bits back to what they ought to be.
Bugs like this have been around forever, in 2004 a subsidiary of Delta
had their crew scheduling system crash at Christmas because it could
only handle 2^15 crew changes in a month.
https://www.theregister.com/2004/12/30/comair_bad_box/
Why they used a signed integer there is hard to guess.
These problems
are hard to test for, but most of them are easy to predict if only the programmers would take the time to do simple calculations. Southwest
had a similar crew scheduling meltdown this last Christmas with bad
software. The Aussies are smart, they moved Christmas to the middle of summer, so this wouldn't happen :-)
Even Great Britain is not immune, they used 1987 era software to track
Covid cases, with predictable results:
https://www.bbc.com/news/technology-54423988
On Wed, 29 Mar 2023 16:39:09 -0600, kinsell wrote:
Yep. The GPS debacle was caused by limited bits of informationYou may be amused to hear that I still have a usable pair of Garmin GPS 2+ handheld units, which I used first for Free Flight model retrieval and
transmitted by the satellite, compounded by makers of receivers who
thought storing a few more bits in static RAM, powered by a tiny
battery, was adequate to address the situation. Once the battery gets
discharged, no amount of recharging fixes it. No provision is made to
let the user set the bits back to what they ought to be.
then, when I started to fly XC in my club's Pegase 90 they got used for navigation and to drive my first logger, which was just a recorder and
needed an external GPS.
So, while they *might* possibly be useful one day, they're really just old age pensioners. When outdoors and in use, they run on a set of four AA
cells.
Mine are still viable because every few months I fire them up to see if
there is still usable life in the AA cells, replace them if they're low,
and sometimes take the GPS units outside to see if they can still get a
fix. So far, they're still working well. Used this way, a set of AA cells lasts for over a year.
The GPS 2+ units have a small, internal non-replaceable disk battery to
keep their internal RAM alive while their main batteries are replaced, so
as long as this battery is good and their AA cells are replaced before
they go flat, they remember which GPS epoch they are in and will continue
to get a valid fix and show the right time when taken outside and fired
up.
Bugs like this have been around forever, in 2004 a subsidiary of DeltaI dunno - that can depend on the language the system was written in: a lot
had their crew scheduling system crash at Christmas because it could
only handle 2^15 crew changes in a month.
https://www.theregister.com/2004/12/30/comair_bad_box/
Why they used a signed integer there is hard to guess.
of C designers and programmers would just specify an int rather than an unsigned int without thinking, but in any case, using an unsigned int only doubles the time to crash, IMO that sort of mistake would be less likely
if the system was written in COBOL, Java or PL/1 because of the syntax
used to declare numeric variables, but that fairly irrelevant because not checking for overflow on a variable that is used as a key or index value
is just plain careless.
But to my mind its even odder that they would have used such a short
integer. Given that the IBM AIX systems they were using at the time were
32 or 64 bit systems, the fact is that the flight crew scheduling software crashed due to integer overflow on a signed 15 bit integer!
That would tend to show the crash was a software error pure and simple.
These problemsCowboys live in coding shops over here too!
are hard to test for, but most of them are easy to predict if only the
programmers would take the time to do simple calculations. Southwest
had a similar crew scheduling meltdown this last Christmas with bad
software. The Aussies are smart, they moved Christmas to the middle of
summer, so this wouldn't happen :-)
Even Great Britain is not immune, they used 1987 era software to track
Covid cases, with predictable results:
https://www.bbc.com/news/technology-54423988
An interesting read. Thanks for posting.it.
The GPS 2+ units have a small, internal non-replaceable disk battery to
keep their internal RAM alive while their main batteries are replaced, so
as long as this battery is good and their AA cells are replaced before
they go flat, they remember which GPS epoch they are in and will continue
to get a valid fix and show the right time when taken outside and fired
up.
Doesn't surprise me at all. I've still got a Garmin GPS 12, one of the first units targeted at backpackers. Used it for many years for glider navigation, now it's relegated as a backup device in case ship power
fails. Which it hasn't in 40 years of flying. The date for the 12 is still correct, not that it matters for its current use.
The little rechargeable battery built in works great in that
application, since it's charged by the other batteries continuously.
However, take that same circuitry, build it into a certified logger that
is not likely to get powered up over the winter season (and which
requires correct time), and you end up with the current situation, a
slow but steady trickle of loggers going belly up as time marches on.
-Dave
On 3/29/23 6:21 PM, Martin Gregorie wrote:
On Wed, 29 Mar 2023 16:39:09 -0600, kinsell wrote:
Yep. The GPS debacle was caused by limited bits of informationYou may be amused to hear that I still have a usable pair of Garmin
transmitted by the satellite, compounded by makers of receivers who
thought storing a few more bits in static RAM, powered by a tiny
battery, was adequate to address the situation. Once the battery gets
discharged, no amount of recharging fixes it. No provision is made to
let the user set the bits back to what they ought to be.
GPS 2+
handheld units, which I used first for Free Flight model retrieval and
then, when I started to fly XC in my club's Pegase 90 they got used for
navigation and to drive my first logger, which was just a recorder and
needed an external GPS.
So, while they *might* possibly be useful one day, they're really just
old
age pensioners. When outdoors and in use, they run on a set of four AA
cells.
Mine are still viable because every few months I fire them up to see if
there is still usable life in the AA cells, replace them if they're low,
and sometimes take the GPS units outside to see if they can still get a
fix. So far, they're still working well. Used this way, a set of AA cells
lasts for over a year.
The GPS 2+ units have a small, internal non-replaceable disk battery to
keep their internal RAM alive while their main batteries are replaced, so
as long as this battery is good and their AA cells are replaced before
they go flat, they remember which GPS epoch they are in and will continue
to get a valid fix and show the right time when taken outside and fired
up.
Bugs like this have been around forever, in 2004 a subsidiary of DeltaI dunno - that can depend on the language the system was written in: a
had their crew scheduling system crash at Christmas because it could
only handle 2^15 crew changes in a month.
https://www.theregister.com/2004/12/30/comair_bad_box/
Why they used a signed integer there is hard to guess.
lot
of C designers and programmers would just specify an int rather than an
unsigned int without thinking, but in any case, using an unsigned int
only
doubles the time to crash, IMO that sort of mistake would be less likely
if the system was written in COBOL, Java or PL/1 because of the syntax
used to declare numeric variables, but that fairly irrelevant because not
checking for overflow on a variable that is used as a key or index value
is just plain careless.
But to my mind its even odder that they would have used such a short
integer. Given that the IBM AIX systems they were using at the time were
32 or 64 bit systems, the fact is that the flight crew scheduling
software
crashed due to integer overflow on a signed 15 bit integer!
That would tend to show the crash was a software error pure and simple.
These problemsCowboys live in coding shops over here too!
are hard to test for, but most of them are easy to predict if only the
programmers would take the time to do simple calculations. Southwest
had a similar crew scheduling meltdown this last Christmas with bad
software. The Aussies are smart, they moved Christmas to the middle of >>> summer, so this wouldn't happen :-)
Even Great Britain is not immune, they used 1987 era software to track
Covid cases, with predictable results:
https://www.bbc.com/news/technology-54423988
An interesting read. Thanks for posting.it.
I've got a Trimble Flight Mate Pro in the hangar. Wonder if it will
lock on with a new set of AA batteries...
Dan
5J
On 3/29/23 20:54, kinsell wrote:
Doesn't surprise me at all. I've still got a Garmin GPS 12, one of
the first units targeted at backpackers. Used it for many years for
glider navigation, now it's relegated as a backup device in case ship
power fails. Which it hasn't in 40 years of flying. The date for the
12 is still correct, not that it matters for its current use.
The little rechargeable battery built in works great in that
application, since it's charged by the other batteries continuously.
However, take that same circuitry, build it into a certified logger
that is not likely to get powered up over the winter season (and which
requires correct time), and you end up with the current situation, a
slow but steady trickle of loggers going belly up as time marches on.
-Dave
On 3/29/23 6:21 PM, Martin Gregorie wrote:
On Wed, 29 Mar 2023 16:39:09 -0600, kinsell wrote:
Yep. The GPS debacle was caused by limited bits of informationYou may be amused to hear that I still have a usable pair of Garmin
transmitted by the satellite, compounded by makers of receivers who
thought storing a few more bits in static RAM, powered by a tiny
battery, was adequate to address the situation. Once the battery gets >>>> discharged, no amount of recharging fixes it. No provision is made to >>>> let the user set the bits back to what they ought to be.
GPS 2+
handheld units, which I used first for Free Flight model retrieval and
then, when I started to fly XC in my club's Pegase 90 they got used for
navigation and to drive my first logger, which was just a recorder and
needed an external GPS.
So, while they *might* possibly be useful one day, they're really
just old
age pensioners. When outdoors and in use, they run on a set of four AA
cells.
Mine are still viable because every few months I fire them up to see if
there is still usable life in the AA cells, replace them if they're low, >>> and sometimes take the GPS units outside to see if they can still get a
fix. So far, they're still working well. Used this way, a set of AA
cells
lasts for over a year.
The GPS 2+ units have a small, internal non-replaceable disk battery to
keep their internal RAM alive while their main batteries are
replaced, so
as long as this battery is good and their AA cells are replaced before
they go flat, they remember which GPS epoch they are in and will
continue
to get a valid fix and show the right time when taken outside and fired
up.
Bugs like this have been around forever, in 2004 a subsidiary of Delta >>>> had their crew scheduling system crash at Christmas because it couldI dunno - that can depend on the language the system was written in:
only handle 2^15 crew changes in a month.
https://www.theregister.com/2004/12/30/comair_bad_box/
Why they used a signed integer there is hard to guess.
a lot
of C designers and programmers would just specify an int rather than an
unsigned int without thinking, but in any case, using an unsigned int
only
doubles the time to crash, IMO that sort of mistake would be less likely >>> if the system was written in COBOL, Java or PL/1 because of the syntax
used to declare numeric variables, but that fairly irrelevant because
not
checking for overflow on a variable that is used as a key or index value >>> is just plain careless.
But to my mind its even odder that they would have used such a short
integer. Given that the IBM AIX systems they were using at the time were >>> 32 or 64 bit systems, the fact is that the flight crew scheduling
software
crashed due to integer overflow on a signed 15 bit integer!
That would tend to show the crash was a software error pure and simple.
These problemsCowboys live in coding shops over here too!
are hard to test for, but most of them are easy to predict if only the >>>> programmers would take the time to do simple calculations. Southwest >>>> had a similar crew scheduling meltdown this last Christmas with bad
software. The Aussies are smart, they moved Christmas to the middle of >>>> summer, so this wouldn't happen :-)
Even Great Britain is not immune, they used 1987 era software to track >>>> Covid cases, with predictable results:
https://www.bbc.com/news/technology-54423988
An interesting read. Thanks for posting.it.
Will good AA batteries keep the thing alive while a soldering guru
replaces the disk battery?
If not, will it come back to life with a new "keep alive" battery
installed?
On Thu, 30 Mar 2023 09:52:51 -0600, Dan Marotta wrote:As part of the data stream, it receives a week number. When this clicks
Will good AA batteries keep the thing alive while a soldering guruMy original Garmin GPS 2+ got left a bit too long with either no or dead
replaces the disk battery?
AA cells (I forget which: it was back in the late '90s) Garmin replaced
the tiny coin cell as a freebie and said that I'd just squeaked in before support for that model was dropped.
I never found out whether the GPS 2+ was capable in recovering the epoch
and year if left running for long enough, or whether the coin cell replacement process also included setting the correct epoch and year.
I've never seen any descriptions of how GPS receivers recognise the start
of a new epoch and what internal variables they need to update when they
get it.
As above.If not, will it come back to life with a new "keep alive" battery
installed?
My guess that depends on the make and model of GPS. All I know is that any GPS receiver recent enough to use EEPROM rather than battery backed RAM to store data thats retained when its powered off is pretty much guaranteed
to work correctly unless its been physically damaged.
On 30/03/2023 18:07, Martin Gregorie wrote:
On Thu, 30 Mar 2023 09:52:51 -0600, Dan Marotta wrote:As part of the data stream, it receives a week number. When this clicks
Will good AA batteries keep the thing alive while a soldering guruMy original Garmin GPS 2+ got left a bit too long with either no or dead
replaces the disk battery?
AA cells (I forget which: it was back in the late '90s) Garmin replaced
the tiny coin cell as a freebie and said that I'd just squeaked in before
support for that model was dropped.
I never found out whether the GPS 2+ was capable in recovering the epoch
and year if left running for long enough, or whether the coin cell
replacement process also included setting the correct epoch and year.
I've never seen any descriptions of how GPS receivers recognise the start
of a new epoch and what internal variables they need to update when they
get it.
from 1023 to 0, it is a new epoch. It does not receive the epoch number, which is a problem, so success/failure depends on if the epoch number is stored in volatile or non-volatile memory.
As above.
If not, will it come back to life with a new "keep alive" battery
installed?
My guess that depends on the make and model of GPS. All I know is that
any
GPS receiver recent enough to use EEPROM rather than battery backed
RAM to
store data thats retained when its powered off is pretty much guaranteed
to work correctly unless its been physically damaged.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 489 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 40:49:53 |
| Calls: | 9,670 |
| Calls today: | 1 |
| Files: | 13,716 |
| Messages: | 6,169,727 |