info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Cambridge 302 and GPS-NAV owners – IMPORTANT NEWS
4,904 views
Skip to first unread message
Paul Remde
Nov 21, 2014, 2:52:01 PM11/21/14
to
Cambridge 302 and GPS-NAV owners – IMPORTANT NEWS
Unfortunately, there has been a rash of Cambridge Model 10/20/25 and
302/302A with a fault in which the units lose track of the date and do not
record a flight log, or record a flight log with an incorrect date. The
problem is related to the internal Garmin GPS engine’s UTC date. This is a
new issue, but there have already been many reported instances – especially
from areas in which there are soaring flights this time of year. It is very
likely that many 302 and GPS-NAV owners that have their gliders put away for
the winter will, unfortunately, have the same issue during their first
flight in the spring.
If you have the optional LCD display connected to your 302 or GPS-NAV flight
recorder, you may be able to tell whether or not your unit is affected.
Connect the GPS-NAV Model 20/25 to a GPS-NAV LCD Navigation Display, or
connect the 302 to a 303 LCD Navigation display and give the unit time to
lock onto satellites before continuing. The GPS-NAV’s LED will blink when
it is locked onto satellites. The 302 will show 3 bars on the right side of
the screen when it has a good lock on satellites. Then scroll to the UTC
date/time screen. If your unit is working properly you will see the current
date. If your units is not working properly you will find an erroneous
date – such as 2005. In that case, the unit will need repair.
If your GPS-NAV or 302 does not have the optional LCD Navigation display,
then the best way to determine whether your units is affected is to take a
flight (or drive) and look at the date of the flight log that is generated.
Make sure the unit has a good lock on satellites before takeoff. If the
flight log’s date is off, or no flight log is generated, then the unit will
need repair.
The bad news is that the units will need to be sent in for repair. It is
not possible to repair the unit in the field. This issue affects the GPS
engine which is inside the logger, not the external GPS antenna.
The great news is that Gary Kammerer at ClearNav can fix them. The Garmin
receiver has a 3v rechargeable battery under its cover. The issue is not
related to the 3v logger security button battery. Gary can remove the Garmin’s
cover, replace the 3v rechargeable battery that is soldered to the Garmin
circuit board put the unit back together and then send a couple of commands
to the GPS which wake the Garmin back to reality. The new battery keeps it
working properly after the repair procedure. Without the replacement
battery the Garmin's memory cannot be kept "alive". Gary has performed this
fix to dozens of 302 and GPS-NAV units he has received from all over. They
have all been successfully repaired.
CNI Service Policy For Cambridge Equipment--
http://www.clearnav.net/main/cn-service.html
Gary’s contact information:
Gary Kammerer
ClearNav Instruments
779 Rosedale Rd
Kennett Square, PA 19348
USA
Phone: 610-388-0456
Email: ga...@clearnav.net
Please include a note explaining the reason you are sending the unit to
Gary, and also include your contact information.
Gary and I hope this information will allow you to resolve this issue with
your 302 or GPS-NAV before your next big soaring flight.
Best Regards,
Paul Remde
Cumulus Soaring, Inc.
Unfortunately, there has been a rash of Cambridge Model 10/20/25 and
302/302A with a fault in which the units lose track of the date and do not
record a flight log, or record a flight log with an incorrect date. The
problem is related to the internal Garmin GPS engine’s UTC date. This is a
new issue, but there have already been many reported instances – especially
from areas in which there are soaring flights this time of year. It is very
likely that many 302 and GPS-NAV owners that have their gliders put away for
the winter will, unfortunately, have the same issue during their first
flight in the spring.
If you have the optional LCD display connected to your 302 or GPS-NAV flight
recorder, you may be able to tell whether or not your unit is affected.
Connect the GPS-NAV Model 20/25 to a GPS-NAV LCD Navigation Display, or
connect the 302 to a 303 LCD Navigation display and give the unit time to
lock onto satellites before continuing. The GPS-NAV’s LED will blink when
it is locked onto satellites. The 302 will show 3 bars on the right side of
the screen when it has a good lock on satellites. Then scroll to the UTC
date/time screen. If your unit is working properly you will see the current
date. If your units is not working properly you will find an erroneous
date – such as 2005. In that case, the unit will need repair.
If your GPS-NAV or 302 does not have the optional LCD Navigation display,
then the best way to determine whether your units is affected is to take a
flight (or drive) and look at the date of the flight log that is generated.
Make sure the unit has a good lock on satellites before takeoff. If the
flight log’s date is off, or no flight log is generated, then the unit will
need repair.
The bad news is that the units will need to be sent in for repair. It is
not possible to repair the unit in the field. This issue affects the GPS
engine which is inside the logger, not the external GPS antenna.
The great news is that Gary Kammerer at ClearNav can fix them. The Garmin
receiver has a 3v rechargeable battery under its cover. The issue is not
related to the 3v logger security button battery. Gary can remove the Garmin’s
cover, replace the 3v rechargeable battery that is soldered to the Garmin
circuit board put the unit back together and then send a couple of commands
to the GPS which wake the Garmin back to reality. The new battery keeps it
working properly after the repair procedure. Without the replacement
battery the Garmin's memory cannot be kept "alive". Gary has performed this
fix to dozens of 302 and GPS-NAV units he has received from all over. They
have all been successfully repaired.
CNI Service Policy For Cambridge Equipment--
http://www.clearnav.net/main/cn-service.html
Gary’s contact information:
Gary Kammerer
ClearNav Instruments
779 Rosedale Rd
Kennett Square, PA 19348
USA
Phone: 610-388-0456
Email: ga...@clearnav.net
Please include a note explaining the reason you are sending the unit to
Gary, and also include your contact information.
Gary and I hope this information will allow you to resolve this issue with
your 302 or GPS-NAV before your next big soaring flight.
Best Regards,
Paul Remde
Cumulus Soaring, Inc.
radsc...@gmail.com
Nov 21, 2014, 9:36:51 PM11/21/14
to
Paul
Is there a time line for a Date of Manufacture or a Serial number batch?
Is this happening to 5, 10 or 15 year old units?
Thanks
Randy
Is there a time line for a Date of Manufacture or a Serial number batch?
Is this happening to 5, 10 or 15 year old units?
Thanks
Randy
Ramy
Nov 21, 2014, 10:27:19 PM11/21/14
to
Ramy
Paul Remde
Nov 21, 2014, 11:17:28 PM11/21/14
to
Hi Randy,
I don't think we know. It seems to affect many 302 and GPS-NAV units.
Best Regards,
Paul Remde
Cumulus Soaring, Inc.
wrote in message
news:8d7c4bfe-0966-4dbf...@googlegroups.com...
I don't think we know. It seems to affect many 302 and GPS-NAV units.
Best Regards,
Paul Remde
Cumulus Soaring, Inc.
news:8d7c4bfe-0966-4dbf...@googlegroups.com...
Paul Remde
Nov 21, 2014, 11:19:04 PM11/21/14
to
Hi Ramy,
Yes. The PDA flight log data will probably also be wrong if the 302 date is
wrong. I have received some reports of that occurring. But I suppose it
depends on the software.
Best Regards,
Paul Remde
Cumulus Soaring, Inc.
_____________________
"Ramy" wrote in message
news:98ddbbc1-1168-4b32...@googlegroups.com...
Yes. The PDA flight log data will probably also be wrong if the 302 date is
wrong. I have received some reports of that occurring. But I suppose it
depends on the software.
Best Regards,
Paul Remde
Cumulus Soaring, Inc.
"Ramy" wrote in message
news:98ddbbc1-1168-4b32...@googlegroups.com...
Message has been deleted
HGXC
Nov 22, 2014, 10:53:14 AM11/22/14
to
On Friday, November 21, 2014 2:52:01 PM UTC-5, Paul Remde wrote:
> Cambridge 302 and GPS-NAV owners - IMPORTANT NEWS
Paul,
I have a Cambridge model 20 GPS...I have hooked it up to a battery and went thru the directions I don't see any screen that says date and time. I went to your demo on your web site and it doesn't show any date and time screen either.
Any hints as to what i am doing wrong?
Dennis
> Cambridge 302 and GPS-NAV owners - IMPORTANT NEWS
>
> Unfortunately, there has been a rash of Cambridge Model 10/20/25 and
> 302/302A with a fault in which the units lose track of the date and do not
> record a flight log, or record a flight log with an incorrect date. The
> problem is related to the internal Garmin GPS engine's UTC date. This is a
> new issue, but there have already been many reported instances - especially
> Unfortunately, there has been a rash of Cambridge Model 10/20/25 and
> 302/302A with a fault in which the units lose track of the date and do not
> record a flight log, or record a flight log with an incorrect date. The
> problem is related to the internal Garmin GPS engine's UTC date. This is a
> from areas in which there are soaring flights this time of year. It is very
> likely that many 302 and GPS-NAV owners that have their gliders put away for
> the winter will, unfortunately, have the same issue during their first
> flight in the spring.
>
> If you have the optional LCD display connected to your 302 or GPS-NAV flight
> recorder, you may be able to tell whether or not your unit is affected.
> Connect the GPS-NAV Model 20/25 to a GPS-NAV LCD Navigation Display, or
> connect the 302 to a 303 LCD Navigation display and give the unit time to
> lock onto satellites before continuing. The GPS-NAV's LED will blink when
> it is locked onto satellites. The 302 will show 3 bars on the right side of
> the screen when it has a good lock on satellites. Then scroll to the UTC
> date/time screen. If your unit is working properly you will see the current
> date. If your units is not working properly you will find an erroneous
> date - such as 2005. In that case, the unit will need repair.
> likely that many 302 and GPS-NAV owners that have their gliders put away for
> the winter will, unfortunately, have the same issue during their first
> flight in the spring.
>
> If you have the optional LCD display connected to your 302 or GPS-NAV flight
> recorder, you may be able to tell whether or not your unit is affected.
> Connect the GPS-NAV Model 20/25 to a GPS-NAV LCD Navigation Display, or
> connect the 302 to a 303 LCD Navigation display and give the unit time to
> lock onto satellites before continuing. The GPS-NAV's LED will blink when
> it is locked onto satellites. The 302 will show 3 bars on the right side of
> the screen when it has a good lock on satellites. Then scroll to the UTC
> date/time screen. If your unit is working properly you will see the current
> date. If your units is not working properly you will find an erroneous
I have a Cambridge model 20 GPS...I have hooked it up to a battery and went thru the directions I don't see any screen that says date and time. I went to your demo on your web site and it doesn't show any date and time screen either.
Any hints as to what i am doing wrong?
Dennis
HGXC
Nov 22, 2014, 11:53:35 AM11/22/14
to
Dennis
Paul Remde
Nov 22, 2014, 12:25:03 PM11/22/14
to
Dennis,
I know you already have this worked-out, but I thought it was also worth
posting here.
http://www.cumulus-soaring.com/cai/demogpsnav/l47.htm
The link above is to the GPS-NAV’s date page. You get to it by going to the
GPS position page and using the up or down arrows. I can see that it is not
obvious how to get there.
Best Regards,
Paul Remde
Cumulus Soaring, Inc.
"HGXC" wrote in message
news:0d124ce8-6444-4344...@googlegroups.com...
I know you already have this worked-out, but I thought it was also worth
posting here.
http://www.cumulus-soaring.com/cai/demogpsnav/l47.htm
The link above is to the GPS-NAV’s date page. You get to it by going to the
GPS position page and using the up or down arrows. I can see that it is not
obvious how to get there.
Best Regards,
Paul Remde
Cumulus Soaring, Inc.
news:0d124ce8-6444-4344...@googlegroups.com...
Tom Kelley #711
Nov 22, 2014, 4:05:09 PM11/22/14
to
On Friday, November 21, 2014 12:52:01 PM UTC-7, Paul Remde wrote:
> Cambridge 302 and GPS-NAV owners - IMPORTANT NEWS
FWIW. I just powered my 302 up. The 303 first showed 1/2005 for the date on the 303 display. Then the 302 went to a 3 bar display and the 303 changed dates to 4/08/95 date.
I did leave it on for 30 minutes and then powered off and back on. No change in date...4/08/95. So, its new battery time.
Good job and thanks Paul for the news update.
Best, #711.
> Cambridge 302 and GPS-NAV owners - IMPORTANT NEWS
>
> Unfortunately, there has been a rash of Cambridge Model 10/20/25 and
> 302/302A with a fault in which the units lose track of the date and do not
> record a flight log, or record a flight log with an incorrect date. The
> problem is related to the internal Garmin GPS engine's UTC date. This is a
> new issue, but there have already been many reported instances - especially
> Unfortunately, there has been a rash of Cambridge Model 10/20/25 and
> 302/302A with a fault in which the units lose track of the date and do not
> record a flight log, or record a flight log with an incorrect date. The
> problem is related to the internal Garmin GPS engine's UTC date. This is a
> from areas in which there are soaring flights this time of year. It is very
> likely that many 302 and GPS-NAV owners that have their gliders put away for
> the winter will, unfortunately, have the same issue during their first
> flight in the spring.
>
> If you have the optional LCD display connected to your 302 or GPS-NAV flight
> recorder, you may be able to tell whether or not your unit is affected.
> Connect the GPS-NAV Model 20/25 to a GPS-NAV LCD Navigation Display, or
> connect the 302 to a 303 LCD Navigation display and give the unit time to
> lock onto satellites before continuing. The GPS-NAV's LED will blink when
> it is locked onto satellites. The 302 will show 3 bars on the right side of
> the screen when it has a good lock on satellites. Then scroll to the UTC
> date/time screen. If your unit is working properly you will see the current
> date. If your units is not working properly you will find an erroneous
> date - such as 2005. In that case, the unit will need repair.
> likely that many 302 and GPS-NAV owners that have their gliders put away for
> the winter will, unfortunately, have the same issue during their first
> flight in the spring.
>
> If you have the optional LCD display connected to your 302 or GPS-NAV flight
> recorder, you may be able to tell whether or not your unit is affected.
> Connect the GPS-NAV Model 20/25 to a GPS-NAV LCD Navigation Display, or
> connect the 302 to a 303 LCD Navigation display and give the unit time to
> lock onto satellites before continuing. The GPS-NAV's LED will blink when
> it is locked onto satellites. The 302 will show 3 bars on the right side of
> the screen when it has a good lock on satellites. Then scroll to the UTC
> date/time screen. If your unit is working properly you will see the current
> date. If your units is not working properly you will find an erroneous
I did leave it on for 30 minutes and then powered off and back on. No change in date...4/08/95. So, its new battery time.
Good job and thanks Paul for the news update.
Best, #711.
Paul Villinski
Nov 23, 2014, 10:11:23 PM11/23/14
to
My 302 recorded today's flight with a date of 4/9/1995. The flight log generated by the Oudie had the same date. See You interpreted the CAI file's date as 4/9/2031.
Very glad there's a fix and thanks, Paul, for spreading the word.
Very glad there's a fix and thanks, Paul, for spreading the word.
David Kinsell
Nov 24, 2014, 9:45:51 AM11/24/14
to
On Sat, 22 Nov 2014 13:05:06 -0800, Tom Kelley #711 wrote:
>
> FWIW. I just powered my 302 up. The 303 first showed 1/2005 for the
> date on the 303 display. Then the 302 went to a 3 bar display and the
> 303 changed dates to 4/08/95 date.
> I did leave it on for 30 minutes and then powered off and back on. No
> change in date...4/08/95. So, its new battery time.
>
> Good job and thanks Paul for the news update.
>
> Best, #711.
So there seems to be two lithiums in there, one for the electronic seal
>
> FWIW. I just powered my 302 up. The 303 first showed 1/2005 for the
> date on the 303 display. Then the 302 went to a 3 bar display and the
> 303 changed dates to 4/08/95 date.
> I did leave it on for 30 minutes and then powered off and back on. No
> change in date...4/08/95. So, its new battery time.
>
> Good job and thanks Paul for the news update.
>
> Best, #711.
and one for the GPS. If you're returning a 302 for the GPS issue, I'd
suggest changing both of them. The older models let a user change the
security one himself if external power was applied, but don't think
that's an option with the 302. The older models also show battery
voltage on powerup, giving plenty of warning that replacement is needed.
I sent my 302 in last winter, due to the gain on the ENL circuit somehow
getting set to 0, and asked for the lithium battery to be replaced. The
email back and forth with Gary just mentions the one battery, but I see
on the invoice he said 'batteries' replaced, so maybe he actually did
both.
Dave
Dan Marotta
Nov 24, 2014, 1:50:23 PM11/24/14
to
I just talked with Gary about sending in my 302 which is exhibiting 3
separate issues. He quoted me from their webpage that they have moved
to a fixed price schedule for repairs. $350 should repair all faults.
I think that's a lot less expensive than redoing my panel with newer
technology and, besides, I really like my 302.
--
---
Dan Marotta
separate issues. He quoted me from their webpage that they have moved
to a fixed price schedule for repairs. $350 should repair all faults.
I think that's a lot less expensive than redoing my panel with newer
technology and, besides, I really like my 302.
---
Dan Marotta
David Kinsell
Nov 24, 2014, 2:08:21 PM11/24/14
to
On Sat, 22 Nov 2014 10:48:11 +0000, Tim Newport-Peace wrote:
> X-no-archive: yes
>
>
> The effect is that the time is exactly 1024 weeks (approximately 9 years
> 8 months) adrift.
>
> The battery on the GPS25 Engine maintains the Real Time Clock. When that
> fails, the engine loses track of which 1024 week epoch is current.
>
The rollover problem is indeed 1024 weeks (10 bits used initially), but
that works out to 19.6 years, not 9.6. Last rollover was Aug 21, 1999
and next one is Apr 6, 2019, so this issue wasn't triggered by hitting a
specific date. Probably it's just been a growing problem as more and
more batteries bite the dust. Unless there's a firmware bug in the GPS
engine, then it might have been related to a specific date.
-Dave
> X-no-archive: yes
>
>
> The effect is that the time is exactly 1024 weeks (approximately 9 years
> 8 months) adrift.
>
> The battery on the GPS25 Engine maintains the Real Time Clock. When that
> fails, the engine loses track of which 1024 week epoch is current.
>
The rollover problem is indeed 1024 weeks (10 bits used initially), but
that works out to 19.6 years, not 9.6. Last rollover was Aug 21, 1999
and next one is Apr 6, 2019, so this issue wasn't triggered by hitting a
specific date. Probably it's just been a growing problem as more and
more batteries bite the dust. Unless there's a firmware bug in the GPS
engine, then it might have been related to a specific date.
-Dave
Ramy
Nov 24, 2014, 4:51:42 PM11/24/14
to
$350 just to replace to the battery?
Maybe it is time to start using the log files from my PowerFlarm then.
Ramy
Maybe it is time to start using the log files from my PowerFlarm then.
Ramy
Brian Bair
Nov 24, 2014, 5:01:38 PM11/24/14
to
September 27, 2014 - CAI 302 Repair Policy
CAI 302 Repair Policy
Effective immediately we are moving to a fixed price service policy. For $350* we will
Repair almost any 302**
Clean and test and inspect as appropriate, connectors, boards and components
Calibrate the altitude pressure transducer and provide a new calibration certificate
Issue a full one-year warranty to cover the entire instrument, not merely the repaired items
*There will be a minimum charge of $125.00 if no defects are found and the unit is determined to be functioning perfectly.
**Almost any - we reserve the right to return at no cost any instrument which we judge not repairable - for example if you drove the trailer over it or filled it with water in a water landing.
herbk...@gmail.com
Nov 24, 2014, 5:44:20 PM11/24/14
to
Dan Marotta
Nov 24, 2014, 7:19:46 PM11/24/14
to
I didn't say $350 to change a battery and, since the full text from the
website was posted by Brian, I won't repeat that.
My 302 is suffering from multiple problems, namely, the on/off switch is
faulty, I'm getting the wrong date in log files, and it's completely
losing GPS lock resulting in multiple log files being generated on a
single flight. So I think the price is probably reasonable considering
the cost of a replacement.
website was posted by Brian, I won't repeat that.
My 302 is suffering from multiple problems, namely, the on/off switch is
faulty, I'm getting the wrong date in log files, and it's completely
losing GPS lock resulting in multiple log files being generated on a
single flight. So I think the price is probably reasonable considering
the cost of a replacement.
Steve Leonard
Nov 25, 2014, 10:13:56 AM11/25/14
to
Well, poo. Checked 10 of them last night, and only 4 came up with the correct date. Several of those that failed to do so were used extensively this summer. Wonder if I can get a "group discount" rate? :-)
2 more to check and see if I can get back up to 50%
Steve Leonard
2 more to check and see if I can get back up to 50%
Steve Leonard
Dan Marotta
Nov 25, 2014, 10:52:32 AM11/25/14
to
Install them with air lock or Dzus fasteners and swap the one good one
into the ship that you're flying today!
--
---
Dan Marotta
into the ship that you're flying today!
---
Dan Marotta
Paul Remde
Nov 25, 2014, 1:19:02 PM11/25/14
to
Hi Steve,
Make sure they are locked onto satellites before checking the date. But you
probably already know that.
Best Regards,
Paul Remde
_____________________
"Steve Leonard" wrote in message
news:d618706d-162f-4e09...@googlegroups.com...
Make sure they are locked onto satellites before checking the date. But you
probably already know that.
Best Regards,
Paul Remde
_____________________
"Steve Leonard" wrote in message
news:d618706d-162f-4e09...@googlegroups.com...
Steve Leonard
Nov 25, 2014, 2:10:49 PM11/25/14
to
On Tuesday, November 25, 2014 12:19:02 PM UTC-6, Paul Remde wrote:
> Hi Steve,
>
> Make sure they are locked onto satellites before checking the date. But you
> probably already know that.
>
> Best Regards,
>
> Paul Remde
> _____________________
>
Yep. Some took a while. Others were pretty quick. Of course, before sending off, they will get a second chance to take the test. Will wait for more than just 3 showing and distance to waypoint shown. That is where some were last night when checked. Others got 8 satellites pretty quickly.
> Hi Steve,
>
> Make sure they are locked onto satellites before checking the date. But you
> probably already know that.
>
> Best Regards,
>
> Paul Remde
> _____________________
>
Steve
Tango Eight
Nov 25, 2014, 9:24:01 PM11/25/14
to
News from ClearNav Instruments...
The Garmin GPS date problem in C-302 can be repaired, if no other issues are present, for $180 + shipping/handling.
Barograph calibration, if required, would be $60 additional.
All other repairs are subject to $350 flat rate, include calibration and 1 year warranty.
See http://www.clearnav.net/main/cn-service.html
Best regards,
Evan Ludeman for CNi
The Garmin GPS date problem in C-302 can be repaired, if no other issues are present, for $180 + shipping/handling.
Barograph calibration, if required, would be $60 additional.
All other repairs are subject to $350 flat rate, include calibration and 1 year warranty.
See http://www.clearnav.net/main/cn-service.html
Best regards,
Evan Ludeman for CNi
Tango Eight
Nov 26, 2014, 9:46:27 AM11/26/14
to
I added an area for CAI 302 owners over on the ClearNav discussion board. There's a whole lot of nothing there right now, but 302 owners may feel free to sign up and utilize this area for mutual support. I have around 600 flight hours on the 302 system and still have one in my own ship (it makes a good backup :-)), so if nothing else, you've got me. Advantages vs r.a.s. may or may not be of value to anyone, the "market", as usual, can make that decision.
http://clearnav.net/simplemachinesforum/index.php
best regards,
Evan Ludeman for CNi
http://clearnav.net/simplemachinesforum/index.php
best regards,
Evan Ludeman for CNi
CLewis95
Nov 27, 2014, 12:43:20 PM11/27/14
to
For anyone keeping score ..
I powered up my (3) GPS/NAV Model 20's .. All said UTC 04/12/95.
Curt - 95
I powered up my (3) GPS/NAV Model 20's .. All said UTC 04/12/95.
Curt - 95
Paul Remde
Nov 28, 2014, 11:41:17 AM11/28/14
to
Hi Curt,
Please make sure they have a lock on satellites before checking the date.
The green light blinks when the unit has a lock on satellites.
Best Regards,
Paul Remde
Cumulus Soaring, Inc.
_______________________
"CLewis95" wrote in message
news:5ac94b5e-b03f-43d7...@googlegroups.com...
Please make sure they have a lock on satellites before checking the date.
The green light blinks when the unit has a lock on satellites.
Best Regards,
Paul Remde
Cumulus Soaring, Inc.
"CLewis95" wrote in message
news:5ac94b5e-b03f-43d7...@googlegroups.com...
Steve Leonard
Nov 28, 2014, 11:55:52 AM11/28/14
to
Correction on my group. Test 10, 7 failed.
For those keeping score, failed serial numbers from my group (Model 20 unless otherwise stated):
C0H5
C1SJ (Model 25)
C1ER
0418 (Model 25)
0205
C0ZN
C0DD
Good:
C0GZ
0327
0440
Have two more I might be able to check today.
For those keeping score, failed serial numbers from my group (Model 20 unless otherwise stated):
C0H5
C1SJ (Model 25)
C1ER
0418 (Model 25)
0205
C0ZN
C0DD
Good:
C0GZ
0327
0440
Have two more I might be able to check today.
CLewis95
Nov 28, 2014, 12:59:49 PM11/28/14
to
yep .. I waited until each had solid lock.
Peter von Tresckow
Nov 28, 2014, 2:04:18 PM11/28/14
to
Looms like I'm batting .500. The model 20 is fine but the volkslogger is
firmly in the 1990s :-(
Pete
firmly in the 1990s :-(
Pete
Tim Taylor
Nov 29, 2014, 8:36:23 PM11/29/14
to
Finally got a chance to pull my glider out and test the 302 today. I don't have a 303 anymore and use the 302 as my backup logger and vario so don't look at the files very often.
Using the Cambridge Utility on my iPAQ, I checked the files and there were files from July through September showing, but my last two flights in October and November were not listed at all.
I switched over to ConnectMe and it did not show all the flights back to July, but did show two flights from 1995, not a good sign.
If you are checking the files use ConnectMe to look for the miss dated files, you may not see them with the Cambridge utility program.
Using the Cambridge Utility on my iPAQ, I checked the files and there were files from July through September showing, but my last two flights in October and November were not listed at all.
I switched over to ConnectMe and it did not show all the flights back to July, but did show two flights from 1995, not a good sign.
If you are checking the files use ConnectMe to look for the miss dated files, you may not see them with the Cambridge utility program.
HGXC
Nov 30, 2014, 5:12:09 PM11/30/14
to
Any way I can find out its age?
Dennis
David Kinsell
Dec 3, 2014, 9:18:44 PM12/3/14
to
On Sun, 30 Nov 2014 14:12:07 -0800, HGXC wrote:
> Mine 30checks out OK for now its COJH and I don't know how old it is.
> What should I be doing...plug iy\t in every few weeks? send it out even
> if its ok?
>
I don't see much future in the recharge-frequently option. Once
> Mine 30checks out OK for now its COJH and I don't know how old it is.
> What should I be doing...plug iy\t in every few weeks? send it out even
> if its ok?
>
batteries start to fail, they go downhill rapidly.
If you intend to use it long-term, I'd say go ahead and send it in.
If anyone missed the richard@craggyaero posting recently, it has lots of
good info on any logger using the Garmin GPS25 module.
Message has been deleted
Dave Leonard
Dec 3, 2014, 11:08:57 PM12/3/14
to
The Garmin GPS-25 manual indicates the internal battery is a rechargeable Lithium with a capacity of about 180 mAh. It also says the load on the battery when the board is unpowered is 50 microamps. There is no way to see what the state of charge is on that little battery. Or how long it takes to charge it up when the board is powered. A fully charged battery is good for about 5 months. If you discharge the battery completely, the memory and real time clock will quit and you are back to 19.5 years ago again with no way to fix it other than sending it back again. So don't go too far between the new battery install and using the gps again.
My 302 went back to 1995. My GPS-NAV clock had drifted off by 3+ minutes, it did a "search the sky" when I powered it up last week and came up with the correct time.
-Dave
My 302 went back to 1995. My GPS-NAV clock had drifted off by 3+ minutes, it did a "search the sky" when I powered it up last week and came up with the correct time.
-Dave
David Kinsell
Dec 4, 2014, 1:55:08 AM12/4/14
to
On Wed, 03 Dec 2014 20:08:56 -0800, Dave Leonard wrote:
> The Garmin GPS-25 manual indicates the internal battery is a
> rechargeable Lithium with a capacity of about 180 mAh. It also says the
> load on the battery when the board is unpowered is 50 microamps. There
> is no way to see what the state of charge is on that little battery. Or
> how long it takes to charge it up when the board is powered. A fully
> charged battery is good for about 5 months. If you discharge the battery
> completely, the memory and real time clock will quit and you are back to
> 19.5 years ago again with no way to fix it other than sending it back
> again. So don't go too far between the new battery install and using the
> gps again.
>
Right, the manual says "up to six month charge" for that battery.
> The Garmin GPS-25 manual indicates the internal battery is a
> rechargeable Lithium with a capacity of about 180 mAh. It also says the
> load on the battery when the board is unpowered is 50 microamps. There
> is no way to see what the state of charge is on that little battery. Or
> how long it takes to charge it up when the board is powered. A fully
> charged battery is good for about 5 months. If you discharge the battery
> completely, the memory and real time clock will quit and you are back to
> 19.5 years ago again with no way to fix it other than sending it back
> again. So don't go too far between the new battery install and using the
> gps again.
>
Extremely marginal for the way we commonly use the units. Since the
firmware worked correctly without battery backup for roughly the period
2005 +- 10 years, it covered up bad batteries, or good batteries that
just had been discharged. Without new firmwware to kick the can down the
road again, it's going to be on an ongoing headache.
Newer systems use a 13 bit integer instead of 10 to keep track of the
week, doubt there's any chance that would ever be retrofit into the units.
-Dave
t...@serkowski.com
Dec 4, 2014, 9:08:30 PM12/4/14
to
I wonder if the affected FR manufacturers could add a mod to detect a timestamp prior to "now" and munge it to the current epoch?
Would FAI accept this solution?
-Tom
Would FAI accept this solution?
-Tom
David Kinsell
Dec 4, 2014, 9:49:54 PM12/4/14
to
On Thu, 04 Dec 2014 18:08:27 -0800, tom wrote:
> I wonder if the affected FR manufacturers could add a mod to detect a
> timestamp prior to "now" and munge it to the current epoch?
Interesting idea, but quite hypothetical when it comes to Cambridge.
> I wonder if the affected FR manufacturers could add a mod to detect a
> timestamp prior to "now" and munge it to the current epoch?
Garrecht Avioncs seems to have source code for the GPS module, and
intends to provide a fix in that code for their Volksloggers. It should
be straightforward to add another 20 years of life that way.
As the details of the problem have come out, it's become clear that the
fix being applied to Cambridge units isn't very good and won't make them
as reliable as they were prior to November. Probably makes more sense to
just go buy a Nano or something similar if you need to replace the
logging capability.
-Dave
drguya...@gmail.com
Dec 4, 2014, 10:07:50 PM12/4/14
to
Now you are trashing all C302s. The all purpose instrument.
Logger. Vario. Flight director. Navigation instrument.
Logger. Vario. Flight director. Navigation instrument.
Soaring Tech
Dec 5, 2014, 8:48:04 AM12/5/14
to
On Thursday, December 4, 2014 9:49:54 PM UTC-5, David Kinsell wrote:
> it's become clear that the
> fix being applied to Cambridge units isn't very good and won't make them
> as reliable as they were prior to November.
> -Dave
> it's become clear that the
> fix being applied to Cambridge units isn't very good and won't make them
> as reliable as they were prior to November.
Oh my!
To all Model 10/20/25,302A and 302 owners who have been following this topic, were happy with there instrument prior to this issue and want to keep using these devices(that's thousands of flight computer/recorders)you can send your recorder to a qualified equipment tech who will replace the 3v re-chargeable battery internal to the Garmin Receiver, send appropriate commands to the Garmin Receiver to reset the date and re-seal the instrument. After that, you are good to go for MANY more years.
IF you do not use the instrument for greater than 5 months, then power the instrument overnight to re-charge the Garmin battery as CHEAP insurance. With a little extra care they are as reliable as they were--no better and no worse then prior to this issue.....Gary
HGXC
Dec 5, 2014, 9:29:35 AM12/5/14
to
Dennis
Georg Garrecht
Dec 5, 2014, 2:43:04 PM12/5/14
to
'David Kinsell[_2_ Wrote:
> ;892916']On Thu, 04 Dec 2014 18:08:27 -0800, tom wrote:
> [color=blue][i]
> ...
>
> Garrecht Avioncs seems to have source code for the GPS module, and
> intends to provide a fix in that code for their Volksloggers. It should
>
> be straightforward to add another 20 years of life that way.
>
>
> -Dave
> Garrecht Avioncs seems to have source code for the GPS module, and
> intends to provide a fix in that code for their Volksloggers. It should
>
> be straightforward to add another 20 years of life that way.
>
>
Hi All,
1)
yes, we probably have a fix for the GPS25 modules, but it has to be
confirmed working under all circumstances by a GPS simulator. This will
of course take some time ...
2)
We do NOT have the sourcecode ...
3)
The only two solutions Garmin has officially suggested to us are:
a) recharge the battery for 2 days and reinitialize the module by it's
serial interface to a new date => obviously this only works for another
2-5 months.
Also, the rechargeable batteries inside the GPS25 also age with time -
Garmin should know this. We got lots of new modules at beginning of the
2000s which were not able to hold their time and date for even 2 weeks.
b) replace module by GPS15 module.
For technical reasons, both solutions are not an option for us, thus
we'll continue work on the firmware-patch, and at the same time on a
software-only solution (new VALI-GCS files, maybe new VL firmware).
Good luck with the CAI solution.
--
Georg Garrecht
David Kinsell
Dec 7, 2014, 7:30:26 PM12/7/14
to
suggested that merely replacing the battery was an adequate solution?
Yet now some people are claiming this is a "fix". It's a temporary Band-
Aid (rtm) that can fall off at any time. Probably when you're least
expecting it.
> b) replace module by GPS15 module.
>
> For technical reasons, both solutions are not an option for us, thus
> we'll continue work on the firmware-patch, and at the same time on a
> software-only solution (new VALI-GCS files, maybe new VL firmware).
>
a physical adapter, has an even tinier battery, and is no longer in
production. New firmware for the GPS25, or the VL, seems to be the right
solution. Glad you're pursuing the issue so vigorously. Perhaps Garmin
could be coerced into doing new firmware if the proper level of
complaints were directed their way. They released new firmware for GPS15
in 2009, but I can't find any info on whether it would have the same
issue pop up in 2019, or some other date.
>
>
> Good luck with the CAI solution.
navigational device like some people do. When mine dies, I'll just
replace the logging function with something better.
-Dave
David Kinsell
Dec 7, 2014, 7:31:31 PM12/7/14
to
A recent posting by Ian Macphee on the Aus-soaring list says that there
was an older aluminum color case version of the 302, and a newer black
case version. Supposedly the black units don't have the date problem
because they don't use the GPS25. It may just be age of batteries, but
I'm curious if the failures have been following this pattern.
I have a black case unit, just tested as good. Clock had drifted by 8
minutes prior to lock, then corrected itself. Unit probably built 2006
or 2007, battery might have been replaced recently, not sure.
-Dave
was an older aluminum color case version of the 302, and a newer black
case version. Supposedly the black units don't have the date problem
because they don't use the GPS25. It may just be age of batteries, but
I'm curious if the failures have been following this pattern.
I have a black case unit, just tested as good. Clock had drifted by 8
minutes prior to lock, then corrected itself. Unit probably built 2006
or 2007, battery might have been replaced recently, not sure.
-Dave
radsc...@gmail.com
Dec 7, 2014, 8:16:14 PM12/7/14
to
My 302 just tested fine and it has the Black case and was manufactured in 2010.
Randy
Randy
HGXC
Dec 7, 2014, 11:30:50 PM12/7/14
to
On Sunday, December 7, 2014 8:16:14 PM UTC-5, radsc...@gmail.com wrote:
> My 302 just tested fine and it has the Black case and was manufactured in 2010.
>
> Randy
Mine has a black case, how can I tell what year it was made?
> My 302 just tested fine and it has the Black case and was manufactured in 2010.
>
> Randy
Dennis
radsc...@gmail.com
Dec 8, 2014, 5:32:48 AM12/8/14
to
The Date on it would give you a good idea of when it was made.
Randy
Tango Eight
Dec 8, 2014, 6:47:46 AM12/8/14
to
On Sunday, December 7, 2014 11:30:50 PM UTC-5, HGXC wrote:
-Evan
HGXC
Dec 8, 2014, 9:27:44 AM12/8/14
to
Dennis
Ramy
Dec 12, 2014, 12:47:54 AM12/12/14
to
So can flight computers such as SeeYou and XCSsoar who uses 302 as GPS source correct the erroneous year when generating their IGC file, and will the file still be valid for OLC? This will save the hassle and cost of repairing units for those who only use the files generated by SeeYou/XCSoar.
Ramy
Ramy
Peter Purdie
Dec 12, 2014, 3:00:13 AM12/12/14
to
Only the record downloaded directly from the 302 is acceptable for IGC
Badges & records.
If an external program can modify one aspect of the file (date) what else
could it modify, and how would an OO check? (Rhetorical question).
At 05:47 12 December 2014, Ramy wrote:
>So can flight computers such as SeeYou and XCSsoar who uses 302 as GPS
>sour=
>g units for those who only use the files generated by SeeYou/XCSoar.=20
>
>Ramy
>
Badges & records.
If an external program can modify one aspect of the file (date) what else
could it modify, and how would an OO check? (Rhetorical question).
At 05:47 12 December 2014, Ramy wrote:
>So can flight computers such as SeeYou and XCSsoar who uses 302 as GPS
>ce correct the erroneous year when generating their IGC file, and will
the
>=
the
>file still be valid for OLC? This will save the hassle and cost of
>repairin=
>g units for those who only use the files generated by SeeYou/XCSoar.=20
>
>Ramy
>
Martin Gregorie
Dec 12, 2014, 7:22:24 AM12/12/14
to
On Fri, 12 Dec 2014 07:54:42 +0000, Peter Purdie wrote:
> Only the record downloaded directly from the 302 is acceptable for IGC
> Badges & records.
>
That should be OK: XCSoar and LK8000 would just be using the 302 as a GPS
> Only the record downloaded directly from the 302 is acceptable for IGC
> Badges & records.
>
receiver and generating the log themselves so its a fair question. In
addition, AFAIK their logs have never been acceptable for badges &
records because they run on unsealed PDAs using either the internal GPS
or, if the device doesn't have, one they'll use an external GPS receiver.
Their logs are accepted for the BGA Ladder.
> If an external program can modify one aspect of the file (date) what
> else could it modify, and how would an OO check? (Rhetorical question).
>
log, but I agree that its difficult to see how an OO could sign off that
the log was generated securely.
I use LK8000 and have done so from its first release, but I also carry an
EW MicroRecorder. As far as I'm concerned, its very much a case of horses
for courses:
- the EW is for badge claims as well as BGA Ladder submission
- The LK8000 log is for my own records and possible for backup
submission to the BGA Ladder
- my (uncertified) Red Box FLARM's log is for checking FLARM coverage.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Pierre Vav
Dec 13, 2014, 2:56:18 PM12/13/14
to
Hello,
Do you think the use of the external battery directly connectet to the 302 can help with this GPS issue?
(the 302 may be directly connected to an external 9V nimh, allowing the use of the 302 with no other power on board. Nice feature.)
Do you think the use of the external battery directly connectet to the 302 can help with this GPS issue?
(the 302 may be directly connected to an external 9V nimh, allowing the use of the 302 with no other power on board. Nice feature.)
krzysztof....@gmail.com
Jan 1, 2015, 6:22:59 AM1/1/15
to
On Friday, December 5, 2014 8:43:04 PM UTC+1, Georg Garrecht wrote:
> Hi All,
>
> 1)
> yes, we probably have a fix for the GPS25 modules, but it has to be
> confirmed working under all circumstances by a GPS simulator. This will
> of course take some time ...
>
> 2)
> We do NOT have the sourcecode ...
>
> 3)
> The only two solutions Garmin has officially suggested to us are:
>
> a) recharge the battery for 2 days and reinitialize the module by it's
> serial interface to a new date => obviously this only works for another
> 2-5 months.
>
> Also, the rechargeable batteries inside the GPS25 also age with time -
> Garmin should know this. We got lots of new modules at beginning of the
> 2000s which were not able to hold their time and date for even 2 weeks.
>
> b) replace module by GPS15 module.
>
> For technical reasons, both solutions are not an option for us, thus
> we'll continue work on the firmware-patch, and at the same time on a
> software-only solution (new VALI-GCS files, maybe new VL firmware).
>
Hi Georg,
> Hi All,
>
> 1)
> yes, we probably have a fix for the GPS25 modules, but it has to be
> confirmed working under all circumstances by a GPS simulator. This will
> of course take some time ...
>
> 2)
> We do NOT have the sourcecode ...
>
> 3)
> The only two solutions Garmin has officially suggested to us are:
>
> a) recharge the battery for 2 days and reinitialize the module by it's
> serial interface to a new date => obviously this only works for another
> 2-5 months.
>
> Also, the rechargeable batteries inside the GPS25 also age with time -
> Garmin should know this. We got lots of new modules at beginning of the
> 2000s which were not able to hold their time and date for even 2 weeks.
>
> b) replace module by GPS15 module.
>
> For technical reasons, both solutions are not an option for us, thus
> we'll continue work on the firmware-patch, and at the same time on a
> software-only solution (new VALI-GCS files, maybe new VL firmware).
>
Observing how my CAI 302 and my friend's Volkslogger work, when they are affected by the date issue, I believe that it is possible to make a simple dirty fix in the logger firmware without the necessity to change the firmware of GPS 25 module. This fix would work quite probably for about next 20 years (being more precise for about next 1024 weeks)
The affected CAI 302 & Volkslogger, which I have access to, are able to get correct position fix and correct time from GPS satellites. The only incorrect thing is date that is moved into past by 1024 weeks. To give an example, when we were flying on wave on Dec 13th 2014, IGC files produced by my CAI 302 & my friend's Volkslogger had a date of April 29th 1995. Next day the date in the IGC file was April 30th 1995.
So it looks that when power in the module backup battery runs out, the firmware initializes the RTC date and it uses a 10 bit variable where it stores number of weeks that passed from a module internal epoch date. A bug in the module firmware does not handle properly the 10 bit variable overflow and recently it started to cause moving the RTC date by 1024 weeks into past. Based on the fact that the issue recently appeared on many loggers, I estimate the internal GPS 25 module epoch date as near of beginning of 1995 year.
Good news is that the RTC time & position work correctly at least for now. Also looking at the behavior of the GPS 25 module, a next overflow on the 10 bit variable will occur about 1024 weeks from now, so the issue could be manageable for about next 20 years.
Taking my observations into account, I would like to suggest a simple 'dirty' fix to be implemented into the logger firmware that would resolve this issue for next 20 years. I would look as follows:
1) When a NMEA sentence with a date is received from the GPS module by logger, check the date inside the sentence. If the date is in past (say before Jan 1st 2015), it means that the GPS module is affected by the date issue. If no issue is detected, process the sentence in normal way. Otherwise go into step 2)
2) Add 1024 weeks to the date inside the NMEA sentence. Use the changed NMEA sentence for all further processing by the logger firmware
As you can see it is a pretty dirty fix, but should be very simple to implement. Alternatively, it should be possible to develop a 'less dirty' fix, which would move the module RTC clock by 1024 weeks when the date issue is discovered by sending to the module Sensor Initialization Information (PGRMI) with a corrected date. However, it would be more difficult to implement and quite probably not worth to spend additional effort comparing to the simple fix.
Cheers
Kris
Message has been deleted
John Ferguson
Jan 1, 2015, 10:15:07 AM1/1/15
to
If the CAI 302 follows the same technology as the GPS 25 and 20's then give
this a try.
Connect up a PC to the CAI using the serial cable, configure Hyperterm or
your favorite terminal emulator, you just need ascii capabilities.
Get to a command prompt, I think it is just hitting escape and type the
following command into the terminal window
rset gps
This should reset the gps, leave it outside connected up to a battery and
let it search the sky until it is happy. I got this fix from Cambridge at
the time of the last GPS rollover and it worked.
John
this a try.
Connect up a PC to the CAI using the serial cable, configure Hyperterm or
your favorite terminal emulator, you just need ascii capabilities.
Get to a command prompt, I think it is just hitting escape and type the
following command into the terminal window
rset gps
This should reset the gps, leave it outside connected up to a battery and
let it search the sky until it is happy. I got this fix from Cambridge at
the time of the last GPS rollover and it worked.
John
Message has been deleted
krzysztof....@gmail.com
Jan 1, 2015, 1:10:35 PM1/1/15
to
On Thursday, January 1, 2015 1:30:26 PM UTC+1, Tim Newport-Peace wrote:
> Not quite.
>
> The date is received as a 10-bit number from satellite transmission. The
> GPS engine stores the epoch number. It is the epoch number which is lost
> when the RTC battery discharges.
>
> Epoch 0 ran from 6th Jan 1980 when GPS went active.
> Epoch 1 (the current epoch) ran from 22nd Aug 1999.
> Epoch 2 will begin on 7th April 2019.
> Epoch 3 will begin on 21st November 2038
> and so on.
>
> Any fix needs to be ready for 7th April 2019 or we go back to page 1.
>
> It would seem that Garmin 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. This fix works correctly from 1.January
> 2005 +- 512 weeks, which has now expired. Hence the current rash of
> problems.
Well I hoped that GPS Epoch changes are handled better by Garmin. So the fix that I suggested would work for about next 4 years until April 2019.
Do you remember what happened with GPS 25 module when the first GPS Epoch finished in 1999 ? Was it able to get proper position and time but it had wrong date, or it was not able to get the position at all ? If the former, it may be possible to create a revised 'dirty fix' that would work after April 2019
> Not quite.
>
> The date is received as a 10-bit number from satellite transmission. The
> GPS engine stores the epoch number. It is the epoch number which is lost
> when the RTC battery discharges.
>
> Epoch 0 ran from 6th Jan 1980 when GPS went active.
> Epoch 1 (the current epoch) ran from 22nd Aug 1999.
> Epoch 2 will begin on 7th April 2019.
> Epoch 3 will begin on 21st November 2038
> and so on.
>
> Any fix needs to be ready for 7th April 2019 or we go back to page 1.
>
> It would seem that Garmin 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. This fix works correctly from 1.January
> 2005 +- 512 weeks, which has now expired. Hence the current rash of
> problems.
Well I hoped that GPS Epoch changes are handled better by Garmin. So the fix that I suggested would work for about next 4 years until April 2019.
Do you remember what happened with GPS 25 module when the first GPS Epoch finished in 1999 ? Was it able to get proper position and time but it had wrong date, or it was not able to get the position at all ? If the former, it may be possible to create a revised 'dirty fix' that would work after April 2019
Message has been deleted
Peter von Tresckow
Jan 1, 2015, 3:42:32 PM1/1/15
to
the epoch rollover. It sounds very much like the code that was implemented
for the Y2k bug.
Long term it would be good if the logger manufacturers could support some
sort of date initialization if the rtc battery dies.
Pete
John Ferguson
Jan 1, 2015, 5:00:07 PM1/1/15
to
>Do you remember what happened with GPS 25 module when the first GPS Epoch
>inished in 1999 ? Was it able to get proper position and time but it had
>wr=
>ong date, or it was not able to get the position at all ? If the former,
>it=
> may be possible to create a revised 'dirty fix' that would work after
>Apri=
>l 2019
>
Yes, the GPS wouldn't acquire position at all until it was reset, I was in
a comp at the time and left the GPS powered up while I borrowed another and
lfew. I used the reset command and after searching the sky it acquired the
position again.
Martin Gregorie
Jan 1, 2015, 6:40:14 PM1/1/15
to
On Thu, 01 Jan 2015 20:42:05 +0000, Peter von Tresckow wrote:
> Long term it would be good if the logger manufacturers could support
> some sort of date initialization if the rtc battery dies.
>
The fix is simple and obvious and has been so since the early '90s when
> Long term it would be good if the logger manufacturers could support
> some sort of date initialization if the rtc battery dies.
>
EEPROM memory became available at sensible prices: throw out the battery-
backed RAM and replace it with EEPROM/Flash memory.
Simply put, any GPS receiver built since, say, the mid-90s that used
battery-backed RAM for its epoch ID storage reflects badly on its maker.
krzysztof....@gmail.com
Jan 3, 2015, 9:14:30 AM1/3/15
to
On Thursday, January 1, 2015 11:00:07 PM UTC+1, John Ferguson wrote:
>
> Yes, the GPS wouldn't acquire position at all until it was reset, I was in
> a comp at the time and left the GPS powered up while I borrowed another and
> lfew. I used the reset command and after searching the sky it acquired the
> position again.
So we may expect the same during the 2019 rollover. There are some questions abut what is going to happen after the rollover:
>
> Yes, the GPS wouldn't acquire position at all until it was reset, I was in
> a comp at the time and left the GPS powered up while I borrowed another and
> lfew. I used the reset command and after searching the sky it acquired the
> position again.
a) will GPS 25 acquire the position after the reset ? (imho quite probably yes)
b) what UTC date will be sent by the module when RTC is reset due to depleted RTC battery. It is difficult to predict, depends how Garmin implemented the date fix for the previous rollover
David Kinsell
Jan 7, 2015, 11:00:22 PM1/7/15
to
On Thu, 01 Jan 2015 12:27:51 +0000, Tim Newport-Peace wrote:
> X-no-archive: yes In article
> <bc02cd08-dbfa-473d...@googlegroups.com>,
> krzysztof....@gmail.com writes
dates back to 1996. The easiest fix would have been just to initialize
to the second epoch, giving trouble-free operation until 2019. Almost
seems like a deliberate time-bomb of the product the way they did it.
Now that we know some 302's have GPS15 modules in them, it raises the
question of how they're going to react in spring of 2019. The manual
says they have a tiny battery, with only 21 days of capacity. Could get
interesting.
Dave
> X-no-archive: yes In article
> <bc02cd08-dbfa-473d...@googlegroups.com>,
> krzysztof....@gmail.com writes
> Not quite.
>
> The date is received as a 10-bit number from satellite transmission. The
> GPS engine stores the epoch number. It is the epoch number which is lost
> when the RTC battery discharges.
>
> Epoch 0 ran from 6th Jan 1980 when GPS went active.
> Epoch 1 (the current epoch) ran from 22nd Aug 1999.
> Epoch 2 will begin on 7th April 2019.
> Epoch 3 will begin on 21st November 2038 and so on.
>
> Any fix needs to be ready for 7th April 2019 or we go back to page 1.
>
> It would seem that Garmin 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. This fix works correctly from 1.January
> 2005 +- 512 weeks, which has now expired. Hence the current rash of
> problems.
I've wondered about that fix. In 2000, there was no need at all to cover
>
> The date is received as a 10-bit number from satellite transmission. The
> GPS engine stores the epoch number. It is the epoch number which is lost
> when the RTC battery discharges.
>
> Epoch 0 ran from 6th Jan 1980 when GPS went active.
> Epoch 1 (the current epoch) ran from 22nd Aug 1999.
> Epoch 2 will begin on 7th April 2019.
> Epoch 3 will begin on 21st November 2038 and so on.
>
> Any fix needs to be ready for 7th April 2019 or we go back to page 1.
>
> It would seem that Garmin 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. This fix works correctly from 1.January
> 2005 +- 512 weeks, which has now expired. Hence the current rash of
> problems.
dates back to 1996. The easiest fix would have been just to initialize
to the second epoch, giving trouble-free operation until 2019. Almost
seems like a deliberate time-bomb of the product the way they did it.
Now that we know some 302's have GPS15 modules in them, it raises the
question of how they're going to react in spring of 2019. The manual
says they have a tiny battery, with only 21 days of capacity. Could get
interesting.
Dave
David Kinsell
Jan 7, 2015, 11:06:59 PM1/7/15
to
On Thu, 01 Jan 2015 23:39:48 +0000, Martin Gregorie wrote:
> On Thu, 01 Jan 2015 20:42:05 +0000, Peter von Tresckow wrote:
>
>> Long term it would be good if the logger manufacturers could support
>> some sort of date initialization if the rtc battery dies.
>>
> The fix is simple and obvious and has been so since the early '90s when
> EEPROM memory became available at sensible prices: throw out the
> battery-backed RAM and replace it with EEPROM/Flash memory.
> On Thu, 01 Jan 2015 20:42:05 +0000, Peter von Tresckow wrote:
>
>> Long term it would be good if the logger manufacturers could support
>> some sort of date initialization if the rtc battery dies.
>>
> The fix is simple and obvious and has been so since the early '90s when
> EEPROM memory became available at sensible prices: throw out the
>
> Simply put, any GPS receiver built since, say, the mid-90s that used
> battery-backed RAM for its epoch ID storage reflects badly on its maker.
GPS engines acquire satellites much faster if they have a rough idea of
> Simply put, any GPS receiver built since, say, the mid-90s that used
> battery-backed RAM for its epoch ID storage reflects badly on its maker.
the time. The vendors not going to throw out the RTC with its battery-
backed RAM, but yes using a few bits of non-volatile storage to prevent
the date from going backwards would be a very good idea.
-Dave
Tim Newport-Peace
Jan 8, 2015, 5:15:04 AM1/8/15
to
At 03:59 08 January 2015, David Kinsell wrote:
>On Thu, 01 Jan 2015 12:27:51 +0000, Tim Newport-Peace wrote:
>
>> X-no-archive: yes In article
>On Thu, 01 Jan 2015 12:27:51 +0000, Tim Newport-Peace wrote:
>
>> X-no-archive: yes In article
day period.
Tim.
0 new messages