
- We-have-an-unexpected-problem
- 10-17-2006
![]() Re: We have an unexpected problem....
| quandong nut | 10-18-2006 |
![]() ![]() Re: We have an unexpected problem....
| Sam Wormley | 10-18-2006 |
![]() ![]() ![]() ![]() Re: We have an unexpected problem....
| Sam Wormley | 10-18-2006 |
![]() ![]() ![]() ![]() ![]() Re: We have an unexpected problem....
| NightStalker | 10-19-2006 |
![]() ![]() ![]() ![]() ![]() ![]() Re: We have an unexpected problem....
| Sam Wormley | 10-19-2006 |
![]() ![]() ![]() ![]() ![]() ![]() ![]() Re: We have an unexpected problem....
| Sam Wormley | 10-20-2006 |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Re: We have an unexpected problem....
| NightStalker | 10-20-2006 |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Re: We have an unexpected problem....
| Sam Wormley | 10-20-2006 |
![]() ![]() Re: We have an unexpected problem....
| Sam Wormley | 10-19-2006 |
![]() ![]() ![]() ![]() Re: We have an unexpected problem....
| Richard Owlett | 10-19-2006 |
![]() ![]() ![]() ![]() Re: We have an unexpected problem....
| Frosted Flake | 10-20-2006 |
![]() Re: We have an unexpected problem....
| Reinhard Zwirne... | 10-19-2006 |
![]() Re: We have an unexpected problem....
| Chuck Tribolet | 10-22-2006 |
![]() Re: We have an unexpected problem....
| Sam Wormley | 10-23-2006 |
![]() ![]() Re: We have an unexpected problem....
| Sam Wormley | 10-23-2006 |
![]() ![]() Re: We have an unexpected problem....
| Reinhard Zwirne... | 10-23-2006 |
![]() ![]() Re: We have an unexpected problem....
| Sam Wormley | 10-23-2006 |
![]() ![]() ![]() Re: We have an unexpected problem....
| Dominic Sexton | 10-24-2006 |
![]() ![]() ![]() ![]() Re: We have an unexpected problem....
| Sam Wormley | 10-24-2006 |
![]() ![]() ![]() ![]() Re: We have an unexpected problem....
| Dave Martindale | 10-24-2006 |
![]() ![]() Re: We have an unexpected problem....
| Chuck Tribolet | 10-23-2006 |
If you were Registered and logged in, you could reply and use other advanced thread options
We have an unexpected problem...
Think back to 21 August 1999 at 0 UTC, the world experienced
its first GPS Week Number Rollover... at the time Trimble was
recommending for the Scoutmaster...
"Trimble recommends that users who wish to navigate during the GPS
week rollover period reset the receiver prior to operation, and plan
on waiting at least 30 minutes before using the system for
navigation. This will give the system time to collect a full, new
almanac and will minimize navigation problems thereafter.
A reset can be accomplished by performing the following actions:
Place the unit on a flat surface.
Turn the unit off.
Press the following 3 keys:
Down Arrow
Up Arrow
Return
Turn the unit on while holding down these 3 keys.
The display should show this message after the copyright message:
Memory wiped
Turn the unit off.
The ScoutMaster may now be used for normal navigation. Allow 30
minutes for almanac collection and satellite acquisition before use."
I found on that fateful night that, by just turning the unit on without
erasing the memory, the Scoutmaster GPS receiver at first tried to search
for the wrong SVs, and eventually started checking for all of them. Once
it found one... it started loading a new almanac which takes a minimum
of 12.5 minutes. I've never has a problem until a few days ago... the
date is reading March of 1987. And I'm not the only one noticing this
problem!
Suggestions and comments are welcome.
-Sam Wormley
>I found on that fateful night that, by just turning the unit on without
>erasing the memory, the Scoutmaster GPS receiver at first tried to search
>for the wrong SVs, and eventually started checking for all of them. Once
>it found one... it started loading a new almanac which takes a minimum
>of 12.5 minutes. I've never has a problem until a few days ago... the
>date is reading March of 1987. And I'm not the only one noticing this
>problem!
>Suggestions and comments are welcome.
>erasing the memory, the Scoutmaster GPS receiver at first tried to search
>for the wrong SVs, and eventually started checking for all of them. Once
>it found one... it started loading a new almanac which takes a minimum
>of 12.5 minutes. I've never has a problem until a few days ago... the
>date is reading March of 1987. And I'm not the only one noticing this
>problem!
>Suggestions and comments are welcome.
Some sort of rollover in the GPSr itself? Or an internal software issue?
Sam Wormley wrote:
> I found on that fateful night that, by just turning the unit on without
> erasing the memory, the Scoutmaster GPS receiver at first tried to search
> for the wrong SVs, and eventually started checking for all of them. Once
> it found one... it started loading a new almanac which takes a minimum
> of 12.5 minutes. I've never has a problem until a few days ago... the
> date is reading March of 1987. And I'm not the only one noticing this
> problem!
>
> Suggestions and comments are welcome.
>
> erasing the memory, the Scoutmaster GPS receiver at first tried to search
> for the wrong SVs, and eventually started checking for all of them. Once
> it found one... it started loading a new almanac which takes a minimum
> of 12.5 minutes. I've never has a problem until a few days ago... the
> date is reading March of 1987. And I'm not the only one noticing this
> problem!
>
> Suggestions and comments are welcome.
>
Sam,
I have a Quest II in the car and it is showing the correct date & time.
Very quick acquisition also.
nitespark wrote:
>
>
> Sam Wormley wrote:
>
>
> Sam Wormley wrote:
>
>> I found on that fateful night that, by just turning the unit on without
>> erasing the memory, the Scoutmaster GPS receiver at first tried to search
>> for the wrong SVs, and eventually started checking for all of them. Once
>> it found one... it started loading a new almanac which takes a minimum
>> of 12.5 minutes. I've never has a problem until a few days ago... the
>> date is reading March of 1987. And I'm not the only one noticing this
>> problem!
>> Suggestions and comments are welcome.
>> erasing the memory, the Scoutmaster GPS receiver at first tried to search
>> for the wrong SVs, and eventually started checking for all of them. Once
>> it found one... it started loading a new almanac which takes a minimum
>> of 12.5 minutes. I've never has a problem until a few days ago... the
>> date is reading March of 1987. And I'm not the only one noticing this
>> problem!
>> Suggestions and comments are welcome.
>
> Sam,
> I have a Quest II in the car and it is showing the correct date & time.
> Very quick acquisition also.
>
> Sam,
> I have a Quest II in the car and it is showing the correct date & time.
> Very quick acquisition also.
>
I don't doubt that most GPSRs have the correct date and time... All
my other Trimble receivers do... I'm trying to thing what event in the
last month might have confused the Trimble Scoutmaster's algorithm...
at what might be a solution.
Sam Wormley wrote:
> nitespark wrote:
>
>
>> Sam Wormley wrote:
>>> I found on that fateful night that, by just turning the unit on without
>>> erasing the memory, the Scoutmaster GPS receiver at first tried to
>>> search
>>> for the wrong SVs, and eventually started checking for all of them. Once
>>> it found one... it started loading a new almanac which takes a minimum
>>> of 12.5 minutes. I've never has a problem until a few days ago... the
>>> date is reading March of 1987. And I'm not the only one noticing this
>>> problem!
>>> Suggestions and comments are welcome.
>>> erasing the memory, the Scoutmaster GPS receiver at first tried to
>>> search
>>> for the wrong SVs, and eventually started checking for all of them. Once
>>> it found one... it started loading a new almanac which takes a minimum
>>> of 12.5 minutes. I've never has a problem until a few days ago... the
>>> date is reading March of 1987. And I'm not the only one noticing this
>>> problem!
>>> Suggestions and comments are welcome.
>> Sam,
>> I have a Quest II in the car and it is showing the correct date &
>> time. Very quick acquisition also.
>> I have a Quest II in the car and it is showing the correct date &
>> time. Very quick acquisition also.
>
> I don't doubt that most GPSRs have the correct date and time... All
> my other Trimble receivers do... I'm trying to thing what event in the
> last month might have confused the Trimble Scoutmaster's algorithm...
> at what might be a solution.
>
> I don't doubt that most GPSRs have the correct date and time... All
> my other Trimble receivers do... I'm trying to thing what event in the
> last month might have confused the Trimble Scoutmaster's algorithm...
> at what might be a solution.
>
FWIW, I got my trusty Garmin GPS V out and dusted it off. Been awhile
since I turned it on and it seem as through it took a bit longer to
acquire, once it did, the clock and date were right on. Your message
piqued my curiosity. It would seem there is some anomaly specific to
your Trimble.
- TomTom Start 20 Series Reference Guide "What's in the box" - I don't have a USB socket in the car!
- Tomtom GPS
- 2011-11-11
- Problem with new 60csx
- Garmin GPS
- 2010-07-12
- Display problem on Tomtom One
- Tomtom GPS
- 2009-07-15
- more on 660 problem
- Garmin GPS
- 2009-02-11
- 60CSX problem
- Garmin GPS
- 2008-06-19









>Think back to 21 August 1999 at 0 UTC, the world experienced
>its first GPS Week Number Rollover... at the time Trimble was
>recommending for the Scoutmaster...