On Friday, July 13, 2018 at 9:23:09 PM UTC-4, Jeff Liebermann wrote:
> On Fri, 13 Jul 2018 17:26:21 -0700 (PDT), Lasse Langwadt Christensen
> <langwadt@fonz.dk> wrote:
> 
> On Fri, 13 Jul 2018 17:21:38 -0700 (PDT),
> gnuarm.deletethisbit@gmail.com wrote:
> 
> >> I'm trying to understand this.  Are you saying the normal 
> >> operation of a cell handset does not require DGPS,
> >> but the location requirements for emergency services does.
> 
> Correct.  However, I'm mostly talking about a basic bottom of the line
> "feature phone", not a smartphone.  The smartphone has a better
> chipset capable of computing the location directly from the satellite
> delays and feeding the location to a mapping program.  The "feature
> phone" does not.  However, E911 has to work with both types of phones,
> as well as phablets and maybe some data only IoT (internet of things)
> devices.  In other words, the lowest form of cell phone that you can
> find, which could easily be 15 years old.  I use an LG VX8300 which
> qualifies.
> <https://www.google.com/search?q=lg+vx8300&tbm=isch>
> 
> One might think that having a smartphone makes things easier by simply
> sending the lat-long-altitude to the PSAP directly.  Nope.  In order
> to do DGPS and AGPS corrections, one needs the individual satellite
> delays.  That would mean that the smartphone would need to process the
> WAAS, DGPS, AGPS, etc data instead of the location services server.
> That's totally impractical and much easier to send the raw delays to
> the location server instead.

I was with you until now.  I have a 15 year old hand held GPS which does WAAS processing on an ancient Motorola processor running at something like 33 MHz I believe.  I don't think the processing is so hard really.  The full data for WAAS is sent by the WAAS sats.  I'm not so familiar with DGPS or AGPS.  The one real advantage of using the location services server is that the server has all the info all the time while the cell phone may have been turned off until the moment the emergency call is made and so not have a full lock or data update. 

I don't know the accuracy rating for WAAS functionality, but my experience is the GPS claims roughly 10 feet.  But that may be with averaging over many seconds.  I know the unit will do that, but I don't remember if the 10 foot number was after considerable averaging or not. 


> >> So rather than add DGPS to cell phones for this purpose 
> >> they punt the heavy lifting to the cell towers by providing them 
> > with the raw timing data from the handsets rather than processed 
> > location data?  
> 
> Exactly.  In the distant future, there may be nuclear powered
> smartphones with the battery capacity, horsepower, and bandwidth to do
> it all in the handset, but not at this time.
> 
> >I don't know, but it wouldn't surprise me if it was a leftover from
> >phones not having enough horse power to but do call a and calculate 
> >position
> 
> Battery life and cell phone horsepower were big parts of the decision
> to do the location processing offsite.  If you scribble the various
> possible topologies on paper, where the processing can be done in the
> handset, at the cell site, at the wireless provider, on a central
> server, or in the cloud, I think you'll find the simplest, cheapest,
> fastest, and most versatile implementation is the current method.  

I'm a bit surprised at this.  GPS processing in general is relatively light duty.  I suppose the DGPS and AGPS might be more math intensive. 


> The accuracy problem is rather interesting.  When the FCC held
> qualification trials for the various proposed methods of improving
> location accuracy, AT&T decided to use a short cut.  Since a huge
> percentage of 911 calls came from callers in vehicles, AT&T simply
> snapped (rounded off) the indicated location to the nearest roadway on
> the map database.  That was sufficient to meet the original specs. The
> only problem is when someone calls sufficiently far away from a road,
> or from a location that doesn't have an address.  
> 
> I think these are the current specs:
> <https://www.fcc.gov/document/fcc-adopts-new-wireless-indoor-e911-location-accuracy-requirements>
> 
> A good question to ask is why anyone needs such extreme levels of
> accuracy?  If there's a fire, or incident, it's easy enough for the
> calling party to describe the location.  I can contrive some unusual
> situations where that's not possible, but that's unusual and hardly
> justifies burdening the entire population of cell phone users with the
> cost of the hardware, software, and services.  So, why the extreme
> accuracy?  My guess(tm) is that only the various police and spy
> agencies can benefit from that level of detail as they track someone
> or something around the country.

People are very bad at explaining where they are or how to get there.  A friend has several times castigated me for not having my house number at the end of the 900 foot driveway.  Emergency services would not have a way to tell which driveway to come down to find me as well as the USP and FedEx guys.  Even a single minute can make a huge difference in reaching a fire.  I really need to do that tomorrow.  DGPS won't help this issue at all.  The house might be well located, but the driveway isn't even shown on Google maps very well. 

Rick C.

On Fri, 13 Jul 2018 17:26:21 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

On Fri, 13 Jul 2018 17:21:38 -0700 (PDT),
gnuarm.deletethisbit@gmail.com wrote:

>> I'm trying to understand this.  Are you saying the normal 
>> operation of a cell handset does not require DGPS,
>> but the location requirements for emergency services does.

Correct.  However, I'm mostly talking about a basic bottom of the line
"feature phone", not a smartphone.  The smartphone has a better
chipset capable of computing the location directly from the satellite
delays and feeding the location to a mapping program.  The "feature
phone" does not.  However, E911 has to work with both types of phones,
as well as phablets and maybe some data only IoT (internet of things)
devices.  In other words, the lowest form of cell phone that you can
find, which could easily be 15 years old.  I use an LG VX8300 which
qualifies.
<https://www.google.com/search?q=lg+vx8300&tbm=isch>

One might think that having a smartphone makes things easier by simply
sending the lat-long-altitude to the PSAP directly.  Nope.  In order
to do DGPS and AGPS corrections, one needs the individual satellite
delays.  That would mean that the smartphone would need to process the
WAAS, DGPS, AGPS, etc data instead of the location services server.
That's totally impractical and much easier to send the raw delays to
the location server instead.

>> So rather than add DGPS to cell phones for this purpose 
>> they punt the heavy lifting to the cell towers by providing them 
> with the raw timing data from the handsets rather than processed 
> location data?  

Exactly.  In the distant future, there may be nuclear powered
smartphones with the battery capacity, horsepower, and bandwidth to do
it all in the handset, but not at this time.

>I don't know, but it wouldn't surprise me if it was a leftover from
>phones not having enough horse power to but do call a and calculate 
>position

Battery life and cell phone horsepower were big parts of the decision
to do the location processing offsite.  If you scribble the various
possible topologies on paper, where the processing can be done in the
handset, at the cell site, at the wireless provider, on a central
server, or in the cloud, I think you'll find the simplest, cheapest,
fastest, and most versatile implementation is the current method.  

The accuracy problem is rather interesting.  When the FCC held
qualification trials for the various proposed methods of improving
location accuracy, AT&T decided to use a short cut.  Since a huge
percentage of 911 calls came from callers in vehicles, AT&T simply
snapped (rounded off) the indicated location to the nearest roadway on
the map database.  That was sufficient to meet the original specs. The
only problem is when someone calls sufficiently far away from a road,
or from a location that doesn't have an address.  

I think these are the current specs:
<https://www.fcc.gov/document/fcc-adopts-new-wireless-indoor-e911-location-accuracy-requirements>

A good question to ask is why anyone needs such extreme levels of
accuracy?  If there's a fire, or incident, it's easy enough for the
calling party to describe the location.  I can contrive some unusual
situations where that's not possible, but that's unusual and hardly
justifies burdening the entire population of cell phone users with the
cost of the hardware, software, and services.  So, why the extreme
accuracy?  My guess(tm) is that only the various police and spy
agencies can benefit from that level of detail as they track someone
or something around the country.




-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

lørdag den 14. juli 2018 kl. 02.21.42 UTC+2 skrev gnuarm.del...@gmail.com:
> On Friday, July 13, 2018 at 7:09:46 PM UTC-4, Jeff Liebermann wrote:
> > On Fri, 13 Jul 2018 11:45:47 -0700 (PDT), Lasse Langwadt Christensen
> > <langwadt@fonz.dk> wrote:
> > >afaik every cell phone basestation has a gps reciever for timing and 
> > >phones already download info from them to get a quicker GPS fix (A-GPS)  
> > >
> > >I don't know if they also use it for D-GPS, but it seems like all the bits 
> > >and pieces are there
> > 
> > DGPS is sometimes used, but not in all systems.  Someone had the
> > bright idea of time synchronizing all the GSM and CDMA2000 cell sites
> > to make handoffs between sites much easier and seamless.  That's a
> > good idea, but requires that all the sites in the system synchronize
> > their clocks to a common source such as GPS.  I don't recall the
> > timing accuracy required, but I'm fairly sure it doesn't require DGPS.
> > 
> > AGPS (assisted GPS) is a different nightmare.  
> > <https://en.wikipedia.org/wiki/Assisted_GPS>
> > Basically, the GPS receiver in the typical handset does not provide a
> > sufficiently accurate location fix to satisfy the FCC and the alphabet
> > soup of served agencies.  So, some providers use TDOA (time difference
> > of arrival) information from cell sites near the user to improve the
> > location accuracy, and to shorten lock time.  
> > 
> > The data from the cell site is sent over the internet to a location
> > services server.  The data from the handset it sent to the cellular
> > service provider and then forwarded to the location services provider.
> > The two (or more) data sets are conglomerated into lat-long-altitude
> > fix, which is then forwarded to the PSAP (public safety answering
> > point).  Note that the data sent by the handset is NOT it's
> > lat-long-altitude, but rather the raw time delays from each satellite.
> > That allows for applying DGPS corrections at the location services
> > provider.  The only parts of the system that requires a GPS receiver
> > is the handset, and the location services server for applying DGPS
> > corrections.
> > 
> > Again, I'm far behind on the location technology in use today because
> > I haven't been involved in GPS for a long time.
> 
> I'm trying to understand this.  Are you saying the normal operation of a cell handset does not require DGPS, but the location requirements for emergency services does.  So rather than add DGPS to cell phones for this purpose they punt the heavy lifting to the cell towers by providing them with the raw timing data from the handsets rather than processed location data?  
> 
> Rick C.

I don't know, but it wouldn't surprise me if it was a leftover from phones not having enough horse power to but do call a and calculate position

On Friday, July 13, 2018 at 7:09:46 PM UTC-4, Jeff Liebermann wrote:
> On Fri, 13 Jul 2018 11:45:47 -0700 (PDT), Lasse Langwadt Christensen
> <langwadt@fonz.dk> wrote:
> >afaik every cell phone basestation has a gps reciever for timing and 
> >phones already download info from them to get a quicker GPS fix (A-GPS)  
> >
> >I don't know if they also use it for D-GPS, but it seems like all the bits 
> >and pieces are there
> 
> DGPS is sometimes used, but not in all systems.  Someone had the
> bright idea of time synchronizing all the GSM and CDMA2000 cell sites
> to make handoffs between sites much easier and seamless.  That's a
> good idea, but requires that all the sites in the system synchronize
> their clocks to a common source such as GPS.  I don't recall the
> timing accuracy required, but I'm fairly sure it doesn't require DGPS.
> 
> AGPS (assisted GPS) is a different nightmare.  
> <https://en.wikipedia.org/wiki/Assisted_GPS>
> Basically, the GPS receiver in the typical handset does not provide a
> sufficiently accurate location fix to satisfy the FCC and the alphabet
> soup of served agencies.  So, some providers use TDOA (time difference
> of arrival) information from cell sites near the user to improve the
> location accuracy, and to shorten lock time.  
> 
> The data from the cell site is sent over the internet to a location
> services server.  The data from the handset it sent to the cellular
> service provider and then forwarded to the location services provider.
> The two (or more) data sets are conglomerated into lat-long-altitude
> fix, which is then forwarded to the PSAP (public safety answering
> point).  Note that the data sent by the handset is NOT it's
> lat-long-altitude, but rather the raw time delays from each satellite.
> That allows for applying DGPS corrections at the location services
> provider.  The only parts of the system that requires a GPS receiver
> is the handset, and the location services server for applying DGPS
> corrections.
> 
> Again, I'm far behind on the location technology in use today because
> I haven't been involved in GPS for a long time.

I'm trying to understand this.  Are you saying the normal operation of a cell handset does not require DGPS, but the location requirements for emergency services does.  So rather than add DGPS to cell phones for this purpose they punt the heavy lifting to the cell towers by providing them with the raw timing data from the handsets rather than processed location data?  

Rick C.

lørdag den 14. juli 2018 kl. 01.09.46 UTC+2 skrev Jeff Liebermann:
> On Fri, 13 Jul 2018 11:45:47 -0700 (PDT), Lasse Langwadt Christensen
> <langwadt@fonz.dk> wrote:
> >afaik every cell phone basestation has a gps reciever for timing and 
> >phones already download info from them to get a quicker GPS fix (A-GPS)  
> >
> >I don't know if they also use it for D-GPS, but it seems like all the bits 
> >and pieces are there
> 
> DGPS is sometimes used, but not in all systems.  Someone had the
> bright idea of time synchronizing all the GSM and CDMA2000 cell sites
> to make handoffs between sites much easier and seamless.  That's a
> good idea, but requires that all the sites in the system synchronize
> their clocks to a common source such as GPS.  I don't recall the
> timing accuracy required, but I'm fairly sure it doesn't require DGPS.
> 
> AGPS (assisted GPS) is a different nightmare.  
> <https://en.wikipedia.org/wiki/Assisted_GPS>
> Basically, the GPS receiver in the typical handset does not provide a
> sufficiently accurate location fix to satisfy the FCC and the alphabet
> soup of served agencies.  So, some providers use TDOA (time difference
> of arrival) information from cell sites near the user to improve the
> location accuracy, and to shorten lock time.  

I'd would have thought it was mostly a matter of not wasting time and battery 
on searching for satellites and downloading almanac at 50bps when you have a megabit data connection to a cell tower that has all the info 

On Fri, 13 Jul 2018 11:45:47 -0700 (PDT), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:
>afaik every cell phone basestation has a gps reciever for timing and 
>phones already download info from them to get a quicker GPS fix (A-GPS)  
>
>I don't know if they also use it for D-GPS, but it seems like all the bits 
>and pieces are there

DGPS is sometimes used, but not in all systems.  Someone had the
bright idea of time synchronizing all the GSM and CDMA2000 cell sites
to make handoffs between sites much easier and seamless.  That's a
good idea, but requires that all the sites in the system synchronize
their clocks to a common source such as GPS.  I don't recall the
timing accuracy required, but I'm fairly sure it doesn't require DGPS.

AGPS (assisted GPS) is a different nightmare.  
<https://en.wikipedia.org/wiki/Assisted_GPS>
Basically, the GPS receiver in the typical handset does not provide a
sufficiently accurate location fix to satisfy the FCC and the alphabet
soup of served agencies.  So, some providers use TDOA (time difference
of arrival) information from cell sites near the user to improve the
location accuracy, and to shorten lock time.  

The data from the cell site is sent over the internet to a location
services server.  The data from the handset it sent to the cellular
service provider and then forwarded to the location services provider.
The two (or more) data sets are conglomerated into lat-long-altitude
fix, which is then forwarded to the PSAP (public safety answering
point).  Note that the data sent by the handset is NOT it's
lat-long-altitude, but rather the raw time delays from each satellite.
That allows for applying DGPS corrections at the location services
provider.  The only parts of the system that requires a GPS receiver
is the handset, and the location services server for applying DGPS
corrections.

Again, I'm far behind on the location technology in use today because
I haven't been involved in GPS for a long time.



-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

fredag den 13. juli 2018 kl. 18.38.56 UTC+2 skrev Jeff Liebermann:
> On Fri, 13 Jul 2018 08:16:47 +0300, upsidedown@downunder.com wrote:
> 
> >On Wed, 11 Jul 2018 15:19:37 -0700, Jeff Liebermann <jeffl@cruzio.com>
> >wrote:
> >
> >>>>It jitters and wanders
> >>>>around a lot, as satellites come and go and the atmosphere changes.
> >>>
> >>>As long a the receiving station remains in a fixed position, this
> >>>should not really be an issue.
> >>
> >>Ummm... The satellites are moving.  However, even if both the
> >>satellites and receiver are stationary, atmospheric delays are quite
> >>erratic, unpredictable, and noisy.  From my experience living in a
> >>forest, where foliage blockage by trees is a problem, when the data
> >>source moves from one satellite to a different satellite, there's a
> >>small but noticeable phase glitch.  If my GPSDO loses lock, the OCXO
> >>clock oscillator drifts off frequency for the duration of the outage
> >>and then takes about the same amount of time as the outage to return
> >>to a stable lock condition.  However, when I played with a Cesium
> >>secondary clock GPSDO, where I could theoretically get to 1 part in
> >>10^14 accuracy (about 4 nsec/day), it did take days for things to
> >>settle down.  I never got close to this level of accuracy because 60Hz
> >>power line and 120Hz power supply noise was wrecking my measurements.
> >>If it had works, it probably would have taken several days to
> >>stabilize.
> 
> >At least when correcting some of the atmospheric errors in position
> >fixing, differential-GPS is used. In this, the DGPS station calculates
> >a pseudo code distance correction from the DGPS station to each
> >visible satellite individually. A distance correction of 3-30 m
> >corresponds to a 10-100 ns time variation.
> 
> DGPS can produce postion accuracies down to the centimeter level as
> long as the distance between the DGPS receiver is fairly small.  The
> local station is at Pigeon Point, about 30 miles away from Santa Cruz.
> I was getting about 5 meters accuracy without DGPS, and 2 or 3 meter
> accuracy using DGPS from Pigeon Pt.  I think I could have done better.
> <http://www.gpsinformation.org/dale/dgps.htm>
> 
> However, the USCG is turning off their beacon band DGPS system, which
> has been replaced by WAAS:
> <https://www.navcen.uscg.gov/?pageName=dgpsMain>
> 
> >Now that the atmospheric error is similar to other nearby GPS
> >receivers, the other stations measures the pseudo code distances then
> >apply the DGPS correction to each measurement individually, before
> >calculating the position fix.
> 
> That's the way it's done.  Back in the stone age of DGPS, it was just
> a log file of positions from a terrestrial DGPS receiver.  The
> assumption was that the errors for the users GPS receiver and the
> static DGPS receiver were the same at any given instant of time.  So,
> we logged the RTCM SC-104 position records from the GPS receiver, and
> compared it with data from a DGPS receiver.  The difference produced a
> much more accurate position fix.  With a good view of the sky,
> accuracy down to the width of the antenna were fairly easy.
> 
> >Couldn't these DGPS corrections be used for accurate timekeeping ?
> 
> I don't think so.  Since the differential correction system required
> time syncing each recorded position report, this would create a
> circular reference, where the uncorrected time would be used to
> correct itself.  I don't think that will work.
> 
> >Of course, if the clock receiver is in a fixed well known location, it
> >can generate its own GPS correction.
> 
> Same problem as before.  You can't use the current time to correct the
> current time.  
> 
> Incidentally, before WAAS, I was looking into building a DGPS station
> and transmitter.  For a time, I had all the necessary equipment and
> associated licenses.  It was suppose to eventually be a free service
> to police and fire to improve their GPS location accuracy to the where
> they could quickly and reliably locate their officers and vehicles
> down to about 1 meter or better.  The idea was to broadcast the DGPS
> corrections on a commercial VHF or UHF frequency, similar to what
> MBARI is doing to accurately locate its vessel and buoys in Monterey
> Bay.  The stumbling block was when I discovered that the site and
> antenna needed to be surveyed to an accuracy of at least 1 order of
> magnitude better than the accuracy we expected, and that it needed to
> re-surveyed regularly to deal with tectonic movements.  Using the GPS
> constellation to do the survey was not good enough.  I don't recall
> the price, but it was more than I wanted to pay.  End of project.
> 
> Today, GPS correction services are quite common and the data is easily
> obtained on the internet.  However, that is only useful for doing
> post-processing of the data and not for real time.
> <http://gpsworld.com/sources-of-public-real-time-high-precision-corrections/>
> 
> For some application, DGPS ground stations have been replaced by
> pseudolytes, which are essentially GPS satellites on the ground.
> <https://en.wikipedia.org/wiki/Pseudolite>
> 
> My apologies for my fumbled around.  I haven't done anything with GPS
> for about 15 years.

afaik every cell phone basestation has a gps reciever for timing and 
phones already download info from them to get a quicker GPS fix (A-GPS)  

I don't know if they also use it for D-GPS, but it seems like all the bits 
and pieces are there

On Fri, 13 Jul 2018 08:16:47 +0300, upsidedown@downunder.com wrote:

>On Wed, 11 Jul 2018 15:19:37 -0700, Jeff Liebermann <jeffl@cruzio.com>
>wrote:
>
>>>>It jitters and wanders
>>>>around a lot, as satellites come and go and the atmosphere changes.
>>>
>>>As long a the receiving station remains in a fixed position, this
>>>should not really be an issue.
>>
>>Ummm... The satellites are moving.  However, even if both the
>>satellites and receiver are stationary, atmospheric delays are quite
>>erratic, unpredictable, and noisy.  From my experience living in a
>>forest, where foliage blockage by trees is a problem, when the data
>>source moves from one satellite to a different satellite, there's a
>>small but noticeable phase glitch.  If my GPSDO loses lock, the OCXO
>>clock oscillator drifts off frequency for the duration of the outage
>>and then takes about the same amount of time as the outage to return
>>to a stable lock condition.  However, when I played with a Cesium
>>secondary clock GPSDO, where I could theoretically get to 1 part in
>>10^14 accuracy (about 4 nsec/day), it did take days for things to
>>settle down.  I never got close to this level of accuracy because 60Hz
>>power line and 120Hz power supply noise was wrecking my measurements.
>>If it had works, it probably would have taken several days to
>>stabilize.

>At least when correcting some of the atmospheric errors in position
>fixing, differential-GPS is used. In this, the DGPS station calculates
>a pseudo code distance correction from the DGPS station to each
>visible satellite individually. A distance correction of 3-30 m
>corresponds to a 10-100 ns time variation.

DGPS can produce postion accuracies down to the centimeter level as
long as the distance between the DGPS receiver is fairly small.  The
local station is at Pigeon Point, about 30 miles away from Santa Cruz.
I was getting about 5 meters accuracy without DGPS, and 2 or 3 meter
accuracy using DGPS from Pigeon Pt.  I think I could have done better.
<http://www.gpsinformation.org/dale/dgps.htm>

However, the USCG is turning off their beacon band DGPS system, which
has been replaced by WAAS:
<https://www.navcen.uscg.gov/?pageName=dgpsMain>

>Now that the atmospheric error is similar to other nearby GPS
>receivers, the other stations measures the pseudo code distances then
>apply the DGPS correction to each measurement individually, before
>calculating the position fix.

That's the way it's done.  Back in the stone age of DGPS, it was just
a log file of positions from a terrestrial DGPS receiver.  The
assumption was that the errors for the users GPS receiver and the
static DGPS receiver were the same at any given instant of time.  So,
we logged the RTCM SC-104 position records from the GPS receiver, and
compared it with data from a DGPS receiver.  The difference produced a
much more accurate position fix.  With a good view of the sky,
accuracy down to the width of the antenna were fairly easy.

>Couldn't these DGPS corrections be used for accurate timekeeping ?

I don't think so.  Since the differential correction system required
time syncing each recorded position report, this would create a
circular reference, where the uncorrected time would be used to
correct itself.  I don't think that will work.

>Of course, if the clock receiver is in a fixed well known location, it
>can generate its own GPS correction.

Same problem as before.  You can't use the current time to correct the
current time.  

Incidentally, before WAAS, I was looking into building a DGPS station
and transmitter.  For a time, I had all the necessary equipment and
associated licenses.  It was suppose to eventually be a free service
to police and fire to improve their GPS location accuracy to the where
they could quickly and reliably locate their officers and vehicles
down to about 1 meter or better.  The idea was to broadcast the DGPS
corrections on a commercial VHF or UHF frequency, similar to what
MBARI is doing to accurately locate its vessel and buoys in Monterey
Bay.  The stumbling block was when I discovered that the site and
antenna needed to be surveyed to an accuracy of at least 1 order of
magnitude better than the accuracy we expected, and that it needed to
re-surveyed regularly to deal with tectonic movements.  Using the GPS
constellation to do the survey was not good enough.  I don't recall
the price, but it was more than I wanted to pay.  End of project.

Today, GPS correction services are quite common and the data is easily
obtained on the internet.  However, that is only useful for doing
post-processing of the data and not for real time.
<http://gpsworld.com/sources-of-public-real-time-high-precision-corrections/>

For some application, DGPS ground stations have been replaced by
pseudolytes, which are essentially GPS satellites on the ground.
<https://en.wikipedia.org/wiki/Pseudolite>

My apologies for my fumbled around.  I haven't done anything with GPS
for about 15 years.

-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

On Friday, July 13, 2018 at 1:16:47 AM UTC-4, upsid...@downunder.com wrote:
> On Wed, 11 Jul 2018 15:19:37 -0700, Jeff Liebermann <jeffl@cruzio.com>
> wrote:
> 
> >>>It jitters and wanders
> >>>around a lot, as satellites come and go and the atmosphere changes.
> >>
> >>As long a the receiving station remains in a fixed position, this
> >>should not really be an issue.
> >
> >Ummm... The satellites are moving.  However, even if both the
> >satellites and receiver are stationary, atmospheric delays are quite
> >erratic, unpredictable, and noisy.  From my experience living in a
> >forest, where foliage blockage by trees is a problem, when the data
> >source moves from one satellite to a different satellite, there's a
> >small but noticeable phase glitch.  If my GPSDO loses lock, the OCXO
> >clock oscillator drifts off frequency for the duration of the outage
> >and then takes about the same amount of time as the outage to return
> >to a stable lock condition.  However, when I played with a Cesium
> >secondary clock GPSDO, where I could theoretically get to 1 part in
> >10^14 accuracy (about 4 nsec/day), it did take days for things to
> >settle down.  I never got close to this level of accuracy because 60Hz
> >power line and 120Hz power supply noise was wrecking my measurements.
> >If it had works, it probably would have taken several days to
> >stabilize.
> 
> At least when correcting some of the atmospheric errors in position
> fixing, differential-GPS is used. In this, the DGPS station calculates
> a pseudo code distance correction from the DGPS station to each
> visible satellite individually. A distance correction of 3-30 m
> corresponds to a 10-100 ns time variation.
> 
> Now that the atmospheric error is similar to other nearby GPS
> receivers, the other stations measures the pseudo code distances then
> apply the DGPS correction to each measurement individually, before
> calculating the position fix.
> 
> Couldn't these DGPS corrections be used for accurate timekeeping ?
> 
> Of course, if the clock receiver is in a fixed well known location, it
> can generate its own GPS correction.

This is a bit of a cyclic analysis.  The position can only be found by getting the corrected time from all the sats factoring in the path delay.  So time and location are all solved together.  

GPS is used for surveying where time averages are used to get very accurate locations which in turn requires much more accurate time keeping. 

Rick C. 

On Wed, 11 Jul 2018 15:19:37 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:

>>>It jitters and wanders
>>>around a lot, as satellites come and go and the atmosphere changes.
>>
>>As long a the receiving station remains in a fixed position, this
>>should not really be an issue.
>
>Ummm... The satellites are moving.  However, even if both the
>satellites and receiver are stationary, atmospheric delays are quite
>erratic, unpredictable, and noisy.  From my experience living in a
>forest, where foliage blockage by trees is a problem, when the data
>source moves from one satellite to a different satellite, there's a
>small but noticeable phase glitch.  If my GPSDO loses lock, the OCXO
>clock oscillator drifts off frequency for the duration of the outage
>and then takes about the same amount of time as the outage to return
>to a stable lock condition.  However, when I played with a Cesium
>secondary clock GPSDO, where I could theoretically get to 1 part in
>10^14 accuracy (about 4 nsec/day), it did take days for things to
>settle down.  I never got close to this level of accuracy because 60Hz
>power line and 120Hz power supply noise was wrecking my measurements.
>If it had works, it probably would have taken several days to
>stabilize.

At least when correcting some of the atmospheric errors in position
fixing, differential-GPS is used. In this, the DGPS station calculates
a pseudo code distance correction from the DGPS station to each
visible satellite individually. A distance correction of 3-30 m
corresponds to a 10-100 ns time variation.

Now that the atmospheric error is similar to other nearby GPS
receivers, the other stations measures the pseudo code distances then
apply the DGPS correction to each measurement individually, before
calculating the position fix.

Couldn't these DGPS corrections be used for accurate timekeeping ?

Of course, if the clock receiver is in a fixed well known location, it
can generate its own GPS correction.