The issue is discussed to death on RAS in the following threads:
https://groups.google.com/forum/m/?fromgroups#!topic/rec.aviation.soaring/XbbgzGeLa34
https://groups.google.com/forum/m/?fromgroups#!topic/rec.aviation.soaring/3tHpsgoORxQ
https://groups.google.com/forum/m/?fromgroups#!topic/rec.aviation.soaring/0oGeJxn05B4
It also impacts Volkslogger, which has the best explanation of the issue from
Garrecht:
"The GPS date problem shows up since end of October. Currently only from
SouthAfrica and Namibia, where folks are flying now.
Not so many complaints currently, but enough to know that it will become more
...
This seems to be a new variant of the GPS week-rollover problem nobody has
expected.
The cause is the Firmware on the internal Garmin GPS OEM receiver board. This
board is installed in all Volksloggers, but I guess also into many other IGC
logger brands (at least one of them we know has the same problem).
A quick analysis of the IGC flight recorder approval documents shows that the
same GPS boards are built into
- all Volksloggers
- all Cambridge 302
- all Cambridge 10-20-25 models from 1997 onwards
older Cambridge models have still older 1-channel receivers, don't know the
status of these
The firmware is, against all statements from Garmin some 15 years ago (when the
issue was first discussed in the GPS community), not able to handle the week
rollover properly, although there are solutions to this (most other GPS
manufacturers know how to do it properly).
From all we could find out, Garmin have introduced a temporary solution at in
the middle of 2000, causing all GPS OEM modules not to have a problem from 1996
to End of October 2014. Exactly, they function correctly from 1.January 2005 +-
512 weeks.
Outside this date range, all GPS25 OEM receiver boards with an init time of
1.1.2005 will have the same problem, as soon as they loose their internal
time/date due to battery drain after some days/weeks (depending on the battery
health).
Starting up without knowledge of last received date, they think they are 1024
weeks ago => currently, this is April 1995.
We had the problem 5 years ago with few receivers, namely the ones with an
internal Init-Date of 1.1.2000. We've updated them to a newer (official)
firmware, which seemed to have solved the problem, but see above.
We're working on two fixes.
1st solution
Is an (inofficial) firmware update, which (the installer software) as a
"product" must not leave our house due to very possible license trouble with
the Garmin company (they most probably don't like the idea that someone makes
their products live longer than planned). Garmin does not support the GPS25
receiver boards in any way anymore, all software / documentation links on the
Garmin website are dead.
Therefore, all affected units (or at least the GPS board) must be shipped to
us, where we will fix the GPS receivers with our own firmware modification for
a nominal fee covering the costs. Due to the amount of loggers sold, and
expected return volumes, the processing time might become very long ...
Currently, we are calculating the costs and planning a solution for coping with
the high volumes.
2nd solution
To be be negotiated with IGC within the next weeks, and can most probably
postpone the problem to 2018 (first date of any Volkslogger sold + 1024 weeks),
but requires a lot of programming work on very old software for many companies.
This would require a software update of all tools used for readout of the
Volkslogger (Strepla, SeeYou, Garrecht DATA-GCS and VALI-GCS.exe files, IGC DLL
file from Garrecht, all open-source tools, all PDA software, etc.). This
software would recalculate all wrong IGC file content and names into the right,
and making them.
Alternately, allowing all tools to show the wrong date at first place (on
download from VL), we'd only publish a FIXGPS-GCS.EXE and a new VALI-GCS.EXE
and DLL.
3rd solution (not very comfortable to the user, but least cost):
All Volksloggers with healthy GPS battery, still knowing the right date (as can
be seen in the NMEA stream) should stay connected to a power source until used,
and again after usage, to avoid a GPS battery outage after some days / weeks. "
> On Dec 13, 2014, at 2:27 AM, Ronald Niederhagen
> <ronald_niederha...@freenet.de> wrote:
>
> Hi Ramy,
>
> I know about this (potential) issue:
> http://www.navcen.uscg.gov/?pageName=gpsweek
> but it's not clear to me how the 302 is affected. Can you describe it,
> or is there a description of it?
> Maybe this will trigger the developers. They may not know what is broken.
>
> Ronald
>
> Ronald
>
> Am 12.12.2014 17:54, schrieb Ramy Yanetz:
>> Not sure if my previous email to the list went through or if any XCSoar
>> developer is still monitoring this list. They were pretty quiet
>> recently. So here it is again. Can someone clarify if the 302 date issue
>> impacts XCSoar generated log files, and if it does, can a fix be done in
>> XCSoar to correct the date so we can save the hassle and cost of
>> repairing the 302? Yes I know I still need a valid log file for badge
>> and records, but for OLC I think a software fix should be fine.
>>
>> Ramy
>>
>>
>> Begin forwarded message:
>>
>>> *From:* Ramy Yanetz <ryan...@yahoo.com <mailto:ryan...@yahoo.com>>
>>> *Date:* December 4, 2014 at 6:38:55 PM PST
>>> *To:* "xcsoar-user@lists.sourceforge.net
>>> <mailto:xcsoar-user@lists.sourceforge.net>"
>>> <xcsoar-user@lists.sourceforge.net
>>> <mailto:xcsoar-user@lists.sourceforge.net>>
>>> *Subject:* *Fix for the Cambridge/Volkslogger date issue?*
>>> *Reply-To:* Ramy Yanetz <ryan...@yahoo.com <mailto:ryan...@yahoo.com>>
>>>
>>> I wonder if a modification can be made to XCSoar to recognize the year
>>> issue which many loggers now have due to the GPS week rollover issue
>>> (more info on RAS) and automatically correct the year to current year
>>> for the internally generated IGC log files?
>>> Granted this will not be a valid IGC file for badge/records but
>>> perhaps valid for OLC/Skylines etc? If this is doable it will save the
>>> hassle and cost to those who dont need igc files for badge and records.
>>>
>>> Ramy
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Xcsoar-user mailing list
>> Xcsoar-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/xcsoar-user
>>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Xcsoar-user mailing list
Xcsoar-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcsoar-user
