|
Cellular forums Home > Archive > Garmin GPS > October 2005 > GPS Satellite Searching in Connecticut
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
GPS Satellite Searching in Connecticut
|
|
| TLoewenberg 2005-10-16, 5:48 pm |
| I have a Garmin 3+ and a NavTeq bluetootch gps that I use with an Axim x30
or Dell 8600. My problem is that both take forever to find enough
satellites to track. Usually, the only way either will find enough to track
is if I pull over and stop. Sometimes, more often than not, it doesn't seem
to make any difference. At first, I thought it a problem with the many
trees in this state. Now, I'm starting to wonder if it's the Ct sky or tree
density or lousey State coverage. If you've had similar experience I'd be
interested. The Garmin is about 6 years old; could that be a contributor?
Thanks,
TL
| |
| Steve Calvin 2005-10-16, 5:48 pm |
| TLoewenberg wrote:
> I have a Garmin 3+ and a NavTeq bluetootch gps that I use with an Axim x30
> or Dell 8600. My problem is that both take forever to find enough
> satellites to track. Usually, the only way either will find enough to track
> is if I pull over and stop. Sometimes, more often than not, it doesn't seem
> to make any difference. At first, I thought it a problem with the many
> trees in this state. Now, I'm starting to wonder if it's the Ct sky or tree
> density or lousey State coverage. If you've had similar experience I'd be
> interested. The Garmin is about 6 years old; could that be a contributor?
> Thanks,
> TL
>
>
hm... interesting... I can't really think of what would cause that.
Windshield maybe? (dunno, just a wag) I travel through Ct. on my way to
Rhode Island for tuna fishing and also sometimes when I head up to Maine
for whitetail and have never had that problem with my 76CS.
Maybe try an externally mounted antenae?
--
Steve
Never read the fine print. There ain't no way you're going to like it.
| |
| Pete LaFlamme 2005-10-16, 5:48 pm |
| Just drove from Dallas Texas to Manchester Connecticut. While in
Connecticut (4 days) I never had a problem finding satellites.
I have a Garmin 2620 with the latest software (not that should make a
difference) North America City Navigator, version 7.
"TLoewenberg" <termarl@msn.com> wrote in message
news:gaedneH5doPgNM_
eRVn-pA@myeastern.com...
>I have a Garmin 3+ and a NavTeq bluetootch gps that I use with an Axim x30
>or Dell 8600. My problem is that both take forever to find enough
>satellites to track. Usually, the only way either will find enough to
>track is if I pull over and stop. Sometimes, more often than not, it
>doesn't seem to make any difference. At first, I thought it a problem with
>the many trees in this state. Now, I'm starting to wonder if it's the Ct
>sky or tree density or lousey State coverage. If you've had similar
>experience I'd be interested. The Garmin is about 6 years old; could that
>be a contributor?
> Thanks,
> TL
>
| |
| Wayne R. 2005-10-16, 5:48 pm |
| On Sun, 16 Oct 2005 15:26:53 -0400, "TLoewenberg" <termarl@msn.com>
wrote (with clarity & insight):
>I have a Garmin 3+ and a NavTeq bluetootch gps that I use with an Axim x30
>or Dell 8600. My problem is that both take forever to find enough
>satellites to track. Usually, the only way either will find enough to track
>is if I pull over and stop.
To initialize the unit, it needs uninterrupted signal from several
satellites to get the thing initialized. I'm not sure it's a fixed
period or period that's model specific, but moving through trees
during this period constantly resets the buffer (whatever) and
restarts the acquisition process.
Once the initialization is complete, brief interruptions are taken in
stride. (That's one reason why cold start times are longer than warm
start.)
>Sometimes, more often than not, it doesn't seem
>to make any difference. At first, I thought it a problem with the many
>trees in this state. Now, I'm starting to wonder if it's the Ct sky or tree
>density or lousey State coverage.
If you're keeping the unit on the dashboard, as you twist around under
the tree cover, you're limiting sky view even more, and just
complicating the initialization period with more resets. Consider a
rooftop antenna, and don't move for a couple of minutes when you start
it up - you'll get a stable lock quickly.
> If you've had similar experience I'd be
>interested. The Garmin is about 6 years old; could that be a contributor?
Like most digital equipment, they either work fine or they're
obviously malfuncitioning. Time spent out of the the box only matters
if it's getting a beating too.
| |
| Stan Gosnell 2005-10-16, 11:48 pm |
| "TLoewenberg" <termarl@msn.com> wrote in
news:gaedneH5doPgNM_
eRVn-pA@myeastern.com:
> I have a Garmin 3+ and a NavTeq bluetootch gps that I use with an Axim
> x30 or Dell 8600. My problem is that both take forever to find enough
> satellites to track. Usually, the only way either will find enough to
> track is if I pull over and stop. Sometimes, more often than not, it
> doesn't seem to make any difference. At first, I thought it a problem
> with the many trees in this state. Now, I'm starting to wonder if
> it's the Ct sky or tree density or lousey State coverage. If you've
> had similar experience I'd be interested. The Garmin is about 6 years
> old; could that be a contributor? Thanks,
> TL
Where are the receivers? They have to have a good view of the sky. You
need to make sure they're well into the windshield, and that the
windshield doesn't have metallic tinting in it. Some windshields will
completely block GPS signals, as well as those used by toll roads to
detect the quick-pay thingies. Usually there is a bare spot right behind
the rearview mirror, though.
--
Regards,
Stan
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." B. Franklin
| |
| Jack Yeazel 2005-10-16, 11:48 pm |
|
"Wayne R." wrote:
> To initialize the unit, it needs uninterrupted signal from several
> satellites to get the thing initialized. I'm not sure it's a fixed
> period or period that's model specific, but moving through trees
> during this period constantly resets the buffer (whatever) and
> restarts the acquisition process.
>
> Once the initialization is complete, brief interruptions are taken in
> stride. (That's one reason why cold start times are longer than warm
> start.)
This is the correct answer... In order to lock on to each individual
satellite, the receiver must receive 30 Seconds of PERFECT navigation
data from each satellite... Motion of the receiver is most often the
cause of the long lock times...
The navigation data is repeated every 30 seconds, so with a perfect view
of the sky (depending where you turn the unit on during the 30-second
cycle) it could take 31 to 61 seconds to get a 2D or 3D lock... That's
why Garmin states it as "45 seconds, typical"...
--
Jack
Get general GPS information at: http://www.gpsinformation.net/
| |
| Sam Wormley 2005-10-16, 11:48 pm |
| Jack Yeazel wrote:
>
> "Wayne R." wrote:
>
>
>
>
> This is the correct answer... In order to lock on to each individual
> satellite, the receiver must receive 30 Seconds of PERFECT navigation
> data from each satellite... Motion of the receiver is most often the
> cause of the long lock times...
>
> The navigation data is repeated every 30 seconds, so with a perfect view
> of the sky (depending where you turn the unit on during the 30-second
> cycle) it could take 31 to 61 seconds to get a 2D or 3D lock... That's
> why Garmin states it as "45 seconds, typical"...
Welcome back! :-)
| |
| peter 2005-10-16, 11:48 pm |
| Jack wrote:
> The navigation data is repeated every 30 seconds, so with a perfect view
> of the sky (depending where you turn the unit on during the 30-second
> cycle) it could take 31 to 61 seconds to get a 2D or 3D lock... That's
> why Garmin states it as "45 seconds, typical"...
What am I missing? Once the receiver locks onto the signal from a
satellite by correlating with the correct spreading code it can start
reading the data link which, as you state, repeats with a 30 second
frame period. So the receiver can store the incoming data until it can
identify the frame structure and therefore properly interpret the data.
Since a frame of the message takes only 30 seconds that amount of data
should be sufficient for the receiver to start its processing and
determine a position fix. I don't see why it would ever take the 61
seconds stated above in the absence of data errors.
Actually only 18 seconds (3 subframes) of the 30 second data message
are required to be received for the unit to use that satellite for a
position fix since the other two subframes have almanac data on the
other satellites (with a superframe of 24 frames providing complete
almanac data every 12.5 minutes). So if we're lucky in our timing of
turning on the receiver we might be able to make do with less than 30
seconds of error-free data, but I don't see why we should ever need
more than the 30 second frame length plus the processing time.
| |
| Jack Yeazel 2005-10-16, 11:48 pm |
| I'm gonna' get into trouble answering this question without Sam
Wormley's help!
-But as I understand it, all navigation messages start at the same time
(world wide)... Thus if you turn on a receiver one second after the
navigation messages start, the first 30 seconds will be rejected but the
second 30 seconds can be received error free which equals 61 seconds to
lockon...
peter wrote:
>
> Jack wrote:
>
> What am I missing? Once the receiver locks onto the signal from a
> satellite by correlating with the correct spreading code it can start
> reading the data link which, as you state, repeats with a 30 second
> frame period. So the receiver can store the incoming data until it can
> identify the frame structure and therefore properly interpret the data.
> Since a frame of the message takes only 30 seconds that amount of data
> should be sufficient for the receiver to start its processing and
> determine a position fix. I don't see why it would ever take the 61
> seconds stated above in the absence of data errors.
>
> Actually only 18 seconds (3 subframes) of the 30 second data message
> are required to be received for the unit to use that satellite for a
> position fix since the other two subframes have almanac data on the
> other satellites (with a superframe of 24 frames providing complete
> almanac data every 12.5 minutes). So if we're lucky in our timing of
> turning on the receiver we might be able to make do with less than 30
> seconds of error-free data, but I don't see why we should ever need
> more than the 30 second frame length plus the processing time.
--
Jack
Get general GPS information at: http://www.gpsinformation.net/
| |
| matt weber 2005-10-16, 11:48 pm |
| On Sun, 16 Oct 2005 15:26:53 -0400, "TLoewenberg" <termarl@msn.com>
wrote:
>I have a Garmin 3+ and a NavTeq bluetootch gps that I use with an Axim x30
>or Dell 8600. My problem is that both take forever to find enough
>satellites to track. Usually, the only way either will find enough to track
>is if I pull over and stop. Sometimes, more often than not, it doesn't seem
>to make any difference. At first, I thought it a problem with the many
>trees in this state. Now, I'm starting to wonder if it's the Ct sky or tree
>density or lousey State coverage. If you've had similar experience I'd be
>interested. The Garmin is about 6 years old; could that be a contributor?
>Thanks,
>TL
>
Where do you put the GPS when you drive? It is important they have
good view of the sky, and are able to watch the same, good sized
portion until they get a lock. Unless you put the GPS all the way
forward up against the windshield, you usually cannot get an initial
lock. I don't think a GPS 3+ supports an external antenna, but on the
models that do, well I have a velcro strip all the way at the front
where the dashboard meets the windshield, and that's where I put
external antennae. Provides a veiw of about 70% of the sky, anything
more than about 65 degrees above the horizon can be seen, regardless
of change of direction.
In addition, the internal battery (on the PCB, not the AA cells that
power the GPS III) may have failed. This causes the unit to fail to
retain current almanac information, and that slows down initial
acquisition not a little, a lot.....
| |
| Dale DePriest 2005-10-16, 11:48 pm |
|
peter wrote:
> Jack wrote:
>
>
>
> What am I missing? Once the receiver locks onto the signal from a
> satellite by correlating with the correct spreading code it can start
> reading the data link which, as you state, repeats with a 30 second
> frame period. So the receiver can store the incoming data until it can
> identify the frame structure and therefore properly interpret the data.
> Since a frame of the message takes only 30 seconds that amount of data
> should be sufficient for the receiver to start its processing and
> determine a position fix. I don't see why it would ever take the 61
> seconds stated above in the absence of data errors.
>
> Actually only 18 seconds (3 subframes) of the 30 second data message
> are required to be received for the unit to use that satellite for a
> position fix since the other two subframes have almanac data on the
> other satellites (with a superframe of 24 frames providing complete
> almanac data every 12.5 minutes). So if we're lucky in our timing of
> turning on the receiver we might be able to make do with less than 30
> seconds of error-free data, but I don't see why we should ever need
> more than the 30 second frame length plus the processing time.
>
You are correct. There are 3 6 second packets and it must receive all
three to be ok. It is easy to corrupt the data however, since driving
under a wire while receiving the data will interrupt the flow resulting
in a 30 second delay. In the worst case with no interruptions it can
take 5.99 seonds of throwaway data since it didn't start exactly on the
correct interval, 12 second of data, 12 seconds of nothing (the good
data is repeated only every 30 seconds(, and 6 seconds more. Thus it can
take 36 seconds to get the data if it all comes the first time.
Dale
--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/PDAs
| |
| TLoewenberg 2005-10-16, 11:48 pm |
| Hmmm, on placement, I try to position the gps as far forward on the dash as
possible. I also have a ram mount that positions the gps further back but
with the antenna still under the windshield. How would I know (or find out)
if the pcb battery has failed? Is it user replaceable? If the battery is
okay, how long does the III+ retain the almanac data? As for the small
bluetooth gps, I place it all the way forward in the center of the
windshield. The bluetooth gps is a Dell, who has agreed to replace it under
warranty. If the new one, acts the same way, I can only assume too many
trees and/or a gps unfriendly windshield.
Thx
TL
"matt weber" <mattheww50@cox.net> wrote in message
news:42s5l1l2t7vdjs0
p1b0hbs940d4ckpuidm@
4ax.com...
> On Sun, 16 Oct 2005 15:26:53 -0400, "TLoewenberg" <termarl@msn.com>
> wrote:
>
> Where do you put the GPS when you drive? It is important they have
> good view of the sky, and are able to watch the same, good sized
> portion until they get a lock. Unless you put the GPS all the way
> forward up against the windshield, you usually cannot get an initial
> lock. I don't think a GPS 3+ supports an external antenna, but on the
> models that do, well I have a velcro strip all the way at the front
> where the dashboard meets the windshield, and that's where I put
> external antennae. Provides a veiw of about 70% of the sky, anything
> more than about 65 degrees above the horizon can be seen, regardless
> of change of direction.
>
> In addition, the internal battery (on the PCB, not the AA cells that
> power the GPS III) may have failed. This causes the unit to fail to
> retain current almanac information, and that slows down initial
> acquisition not a little, a lot.....
| |
| Steve Calvin 2005-10-16, 11:48 pm |
| TLoewenberg wrote:
> Hmmm, on placement, I try to position the gps as far forward on the dash as
> possible. I also have a ram mount that positions the gps further back but
> with the antenna still under the windshield. How would I know (or find out)
> if the pcb battery has failed? Is it user replaceable? If the battery is
> okay, how long does the III+ retain the almanac data? As for the small
> bluetooth gps, I place it all the way forward in the center of the
> windshield. The bluetooth gps is a Dell, who has agreed to replace it under
> warranty. If the new one, acts the same way, I can only assume too many
> trees and/or a gps unfriendly windshield.
> Thx
> TL
>
Gawd, top postint sux
--
Steve
Never read the fine print. There ain't no way you're going to like it.
| |
| Sam Wormley 2005-10-17, 2:48 am |
| peter wrote:
>
> What am I missing? Once the receiver locks onto the signal from a
> satellite by correlating with the correct spreading code it can start
> reading the data link which, as you state, repeats with a 30 second
> frame period. So the receiver can store the incoming data until it can
> identify the frame structure and therefore properly interpret the data.
> Since a frame of the message takes only 30 seconds that amount of data
> should be sufficient for the receiver to start its processing and
> determine a position fix. I don't see why it would ever take the 61
> seconds stated above in the absence of data errors.
>
> Actually only 18 seconds (3 subframes) of the 30 second data message
> are required to be received for the unit to use that satellite for a
> position fix since the other two subframes have almanac data on the
> other satellites (with a superframe of 24 frames providing complete
> almanac data every 12.5 minutes). So if we're lucky in our timing of
> turning on the receiver we might be able to make do with less than 30
> seconds of error-free data, but I don't see why we should ever need
> more than the 30 second frame length plus the processing time.
>
Before a receiver can use a satellite as part of the position,
velocity, time (PVT) solution, it must verify that it has current
ephemeris data for that satellite. The ephemeris data is transmitted
every 30 second.
Each satellite transmits only its own ephemeris data, not to be
confused with every satellite transmitting the almanac data for the
whole constellation every 12.5 minutes.
A correlator is assigned a PRN code based on almanac information,
and may "latch onto" the appropriate satellite signal immediately,
but need to make sure it has the current ephemeris data to be of
much help.
All correlators my not grab their respective satellites at the
same time and my have to wait for the next 30 second interval.
Worse yet, you may drive under a tree or otherwise encounter
an obstruction when the ephemeris data was being grabbed... and
may have to try again.... and again.... and...
See GPS User Equipment Introduction - Sept 1996 (PDF Format)
http://www.navcen.uscg.gov/pubs/gps/gpsuser/gpsuser.pdf
| |
|
| Sam wrote:
> All correlators my not grab their respective satellites at the
> same time and my have to wait for the next 30 second interval.
Why would it have to wait for the full 30 seconds? Once the correlator
has locked onto the satellite signal the unit can start receiving and
storing the bits in the data channel. Then it looks for the frame
information (synch code in the Telemetry word) to determine where it is
in the message so it can interpret the various bits. The message in
subframes 1 - 3 repeats so once it has 30 seconds worth of data it
should have all the clock and ephemeris data necessary from that
satellite. In the unlikely event that there's an update to the subframe
1 - 3 data (only happens every hour or two) right at the time the unit
starts getting that data then I could see the need to repeat a 6-second
subframe, but I still don't see why you'd ever need to wait an entire
extra 30 seconds beyond the 30 seconds required to read one entire
frame's worth of data.
> Worse yet, you may drive under a tree or otherwise encounter
> an obstruction when the ephemeris data was being grabbed... and
> may have to try again.... and again.... and...
Sure, but the conditions that Jack and I were postulating were for
error-free reception. With enough errors the time to get a fix could
well be infinite.
> See GPS User Equipment Introduction - Sept 1996 (PDF Format)
> http://www.navcen.uscg.gov/pubs/gps/gpsuser/gpsuser.pdf
This gives only a cursory overview of the navigation message format
(page 1-7) and refers to "Technical Characteristics of the Navstar GPS"
for more details. Do you have a link to that?
| |
| Sam Wormley 2005-10-17, 5:48 am |
| peter wrote:
> Sam wrote:
>
>
>
> Why would it have to wait for the full 30 seconds? Once the correlator
> has locked onto the satellite signal the unit can start receiving and
> storing the bits in the data channel. Then it looks for the frame
> information (synch code in the Telemetry word) to determine where it is
> in the message so it can interpret the various bits. The message in
> subframes 1 - 3 repeats so once it has 30 seconds worth of data it
> should have all the clock and ephemeris data necessary from that
> satellite. In the unlikely event that there's an update to the subframe
> 1 - 3 data (only happens every hour or two) right at the time the unit
> starts getting that data then I could see the need to repeat a 6-second
> subframe, but I still don't see why you'd ever need to wait an entire
> extra 30 seconds beyond the 30 seconds required to read one entire
> frame's worth of data.
You are certainly correct--The manufacturers algorithm could
certainly put together the data in the right order to save
time.... the questions is do they? Probably some do and some don't.
>
>
>
>
> Sure, but the conditions that Jack and I were postulating were for
> error-free reception. With enough errors the time to get a fix could
> well be infinite.
>
>
>
>
> This gives only a cursory overview of the navigation message format
> (page 1-7) and refers to "Technical Characteristics of the Navstar GPS"
> for more details. Do you have a link to that?
>
Try: http://www.navcen.uscg.gov/pubs/gps/icd200/default.htm
http://www.navcen.uscg.gov/pubs/gps/sigspec/default.htm
-Sam Wormley
http://edu-observatory.org/gps/gps_books.html
| |
|
|
| kashe@sonic.net 2005-10-17, 5:48 pm |
|
Whining about it sux more. You're never going to persuade
anyone not to do so by whining, so live with it.
On Sun, 16 Oct 2005 22:42:20 -0400, Steve Calvin
<calvins@optonline.net> wrote:
>TLoewenberg wrote:
>Gawd, top postint sux
| |
| Dale DePriest 2005-10-17, 5:48 pm |
|
Sam Wormley wrote:
> peter wrote:
>
>
>
> You are certainly correct--The manufacturers algorithm could
> certainly put together the data in the right order to save
> time.... the questions is do they? Probably some do and some don't.
>
However you still have to wait 30 seconds for that particular subframe
to be repeated. So it is not a full minute but could be very close.
Dale
--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/PDAs
| |
| Jack Yeazel 2005-10-21, 11:48 pm |
|
Dale DePriest wrote:
>
> However you still have to wait 30 seconds for that particular subframe
> to be repeated. So it is not a full minute but could be very close.
-Would you buy, then, 59 seconds?? (-8
--
Jack
Get general GPS information at: http://www.gpsinformation.net/
| |
| peter 2005-10-21, 11:48 pm |
| Jack wrote:
> -Would you buy, then, 59 seconds??
Assuming a reasonably designed receiver that doesn't throw away data
already received the most I can see buying is 36 seconds in very rare
circumstances and generally a maximum of 30 seconds plus processing
time. Also assuming error-free reception of course.
| |
| Sam Wormley 2005-10-21, 11:48 pm |
| peter wrote:
> Jack wrote:
>
>
>
> Assuming a reasonably designed receiver that doesn't throw away data
> already received the most I can see buying is 36 seconds in very rare
> circumstances and generally a maximum of 30 seconds plus processing
> time. Also assuming error-free reception of course.
>
Or even 31 seconds!
| |
| Jack Yeazel 2005-10-23, 5:48 pm |
|
Sam Wormley wrote:
>
> Or even 31 seconds!
Yes, 31 seconds is the practical minimum time... 59 seconds is the
maximum cold-start time under ideal conditions -as I understand it...
JY
--
Jack
Get general GPS information at: http://www.gpsinformation.net/
| |
|
| Jack wrote:
[color=darkred]
[color=darkred]
> Yes, 31 seconds is the practical minimum time... 59 seconds is the
> maximum cold-start time under ideal conditions -as I understand it...
No, as explained previously, under normal conditions with error-free
reception the *maximum* time should be 30.02 seconds (one frame plus
one bit position, rounded off to 30 seconds) plus the processing time.
This is for what I consider a 'warm start' i.e. the unit has a valid
almanac but not a sufficiently current ephemeris.
| |
| Jack Yeazel 2005-10-24, 11:48 pm |
|
peter wrote:
>
>
> No, as explained previously, under normal conditions with error-free
> reception the *maximum* time should be 30.02 seconds (one frame plus
> one bit position, rounded off to 30 seconds) plus the processing time.
> This is for what I consider a 'warm start' i.e. the unit has a valid
> almanac but not a sufficiently current ephemeris.
-I give up... We're talking about cold starts... Warm starts can start
within just a few seconds...
Incidentally, I've been e-mailing Garmin asking if they will tell me
what constitutes a cold start and a warm start, but nothing yet... I'll
let the group know when they 'divulge' it...
--
Jack
Get general GPS information at: http://www.gpsinformation.net/
| |
| Bob Greschke 2005-10-24, 11:48 pm |
|
"Jack Yeazel" <jack@finalapproach.net> wrote in message
news:435D6033. 204DCA8E@finalapproa
ch.net...
>
> Incidentally, I've been e-mailing Garmin asking if they will tell me
> what constitutes a cold start and a warm start, but nothing yet... I'll
> let the group know when they 'divulge' it...
A "cold start" on the internal GPS on one of our seismic recorders (don't
know who makes the GPS engine) is defined as dumping the almanac and
ephemeris data and any sense of what time the GPS thinks it is and searching
from scratch.
Bob
| |
| Jack Yeazel 2005-10-25, 5:48 pm |
|
Bob Greschke wrote:
>
> "Jack Yeazel" <jack@finalapproach.net> wrote in message
> news:435D6033. 204DCA8E@finalapproa
ch.net...
>
> A "cold start" on the internal GPS on one of our seismic recorders (don't
> know who makes the GPS engine) is defined as dumping the almanac and
> ephemeris data and any sense of what time the GPS thinks it is and searching
> from scratch.
Well, here's Garmin's reply:
"Thank You for contacting Garmin International. I will be happy to help
you.
Anywhere between 30 minutes to an hour is considered a "warm start."
The
longer the unit remains powered off the more the satellites will change
overhead. This will take the unit longer to re-acquire the signal thus
indicating a "cold start.""
-As I remember it, they used to have a hard and fast time limit for
warm starts, but maybe they now they 'examin the situation' before
doing a cold start...??? The satellites themselves will indicate when
their last valid ephemeris was obtained and if different from that
stored in the unit will cause a cold start (at least for that
satellite)...
--
Jack
Get general GPS information at: http://www.gpsinformation.net/
| |
| Dale DePriest 2005-10-26, 5:48 pm |
|
peter wrote:
> Jack wrote:
>
>
>
>
>
>
>
> No, as explained previously, under normal conditions with error-free
> reception the *maximum* time should be 30.02 seconds (one frame plus
> one bit position, rounded off to 30 seconds) plus the processing time.
> This is for what I consider a 'warm start' i.e. the unit has a valid
> almanac but not a sufficiently current ephemeris.
The maximum time is closer to 36 seconds while the minimum time is 18
seconds to collect the data. The 36 seconds comes about if the gps
starts at exactly the top of a minute plus just enough time to miss the
hand over word that is at the start of each message. Thus it will miss
that full 6 second interval. It will pick up the next 12 seconds of data
and then clock through the 12 seconds of not ephemeris data, finally it
will read the first 6 seconds of data that it missed. Thus 6 + 12 + 12 +
6 equals 36 seconds in the maximum condition. To this should be added
the time the unit needs to compute the fix data from the information it
just received. This is why Garmin typically says 45 seconds.
Dale
>
--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/PDAs
| |
| Dale DePriest 2005-10-26, 5:48 pm |
|
Jack Yeazel wrote:
>
> peter wrote:
>
>
>
> -I give up... We're talking about cold starts... Warm starts can start
> within just a few seconds...
>
> Incidentally, I've been e-mailing Garmin asking if they will tell me
> what constitutes a cold start and a warm start, but nothing yet... I'll
> let the group know when they 'divulge' it...
>
Garmin and the rest of the industry have different definitions of warm
and cold. It is best not to use these terms. I wish Garmin hadn't
redefined what Navstar said but we are stuck with it now. The discussion
is about the time it takes to get a fix when the almanac is known, the
current possition is known approximately, the time is known
approximately, the ephemeris is not known. That time ranges from 18
seconds to 36 seconds to download the emphemeris data plus the initial
find time for the satellite (usually a second or so) plus the time to
compute the fix (on the order of 5-8 seconds or so).
Dale
--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/PDAs
| |
| Phil Wheeler 2005-10-26, 5:48 pm |
| I sure hope it locates Connecticut soon :-)
| |
| Dale DePriest 2005-10-26, 5:48 pm |
|
Jack Yeazel wrote:
>
> Bob Greschke wrote:
>
>
>
> Well, here's Garmin's reply:
> "Thank You for contacting Garmin International. I will be happy to help
> you.
> Anywhere between 30 minutes to an hour is considered a "warm start."
> The
> longer the unit remains powered off the more the satellites will change
> overhead. This will take the unit longer to re-acquire the signal thus
> indicating a "cold start.""
>
> -As I remember it, they used to have a hard and fast time limit for
> warm starts, but maybe they now they 'examin the situation' before
> doing a cold start...??? The satellites themselves will indicate when
> their last valid ephemeris was obtained and if different from that
> stored in the unit will cause a cold start (at least for that
> satellite)...
>
As I said in my earlier post, Garmin defines things differently.
Ephemeris data is guaranteed valid for 2 hours and can often be used for
another 2 hours so as long as the currect visible satellites remain in
the sky the emphemeris data that was collected once is usually ok. There
should be no timeout done by the receiver based on the age of the data.
The satellite sends a update every 2 hours saying if it is ok for the
next period or updates it. So long as 3 satellites still exist in that
transit that the unit has ephemeris data for it can compute a 2D fix
without regathering data. Most people except Garmin call this condition
a hot fix. Since this condition does not require downloading new data it
can be done in a few seconds, typically 10 or less.
There is no cold start for a particular satellite. The term is not
defined since a fix is not based on any particular satellite. A new fix
can use entirely different satellites than were used for the original
fix so long as the data is available. If sufficient satellites are
available with ephemeris data these will be used for the fix. Other
satellite data will be gathered in the background. If not then the it
will be a warm (everyone except Garmin /cold (Garmin) start.
Dale
--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/PDAs
|
|
|
|
|