Ok, if you really want to know, I finally found a (somewhat data) document
which describes this in semi-understandable terms.

And yes, the real time does fall out of the equations (see watch error -
which is how fast or slow your reference clock is).

http://www.maa.org/sites/default/files/pdf/cms_upload/Thompson07734.pdf

What I'm hearing from my GPS module vendor is effectively that since they
don't really have to do any additional work to output a 1PPS signal from a
3d lock, they feel comfortable in doing so.   Adding the complexity of
surveying an location to an useful accuracy and then using that to compute
the time is a lot of additional work with a lot of variability they don't
want to try to deal with without additional demand.   I do know that a
while back we tried some shortcuts to get there, but they were not all that
useful.

-forrest

On Tue, Aug 11, 2015 at 12:25 PM, Sean Heskett <[email protected]> wrote:

> the satellites are constantly moving tho and since they are moving faster
> in orbit than we are here on earth you need to account for relativity.
>  knowing where you are doesn't give you enough information to know where
> the satellite is and therefore you can't accurately calculate the
> relativity offset.  once you have 3D lock with 4 satellites you can
> accurately calculate the relativity offset and therefore calculate the
> accurate time for where you are on earth.
>
> shoulda taken the blue pill ;-)
>
> -Sean
>
> On Tue, Aug 11, 2015 at 12:08 PM, Bill Prince <[email protected]> wrote:
>
>> That's what I thought too. Once one of these little beggars has been
>> online for a half hour or more, the location should be "set" so to speak. I
>> would then expect them to hold time sync even with 1 satellite in view.
>> Knowing that the location is static and unmoving, I would expect that
>> maintaining time lock would be gravy.
>>
>> Sadly, this does not seem to be the case.
>>
>> bp
>> <part15sbs{at}gmail{dot}com>
>>
>>
>> On 8/11/2015 10:48 AM, Chuck McCown wrote:
>>
>> Interesting, I guess you need to know where you are to calculate the
>> delay.  Had not considered that.  But if you know where you are and have
>> ephermis data, you should be able to calculate the delay and arrive at a
>> pretty accurate timing pulse with one satellite.
>>
>> *From:* Forrest Christian (List Account) <[email protected]>
>> *Sent:* Tuesday, August 11, 2015 11:39 AM
>> *To:* af <[email protected]>
>> *Subject:* Re: [AFMUG] GPS Timing
>>
>>
>> You need an accurate  3d position to get accurate timing.   To have an
>> accurate 3d position using GPS alone, you need four satellites.  Three
>> only gets you a 2d lock, and less than that you don't get a lock at all.
>>
>> There are receivers out there which will survey a position and then use
>> that position to be able to continue to provide a timing signal if you
>> subsequently lose lock but still have sats in view.   As far as I know,
>> this type of receiver is not in use in any commercially available timing
>> product for the cambium radios.  In fact I think we've almost all ended up
>> using the exact same GPS modules, at least for any recently designed
>> product.
>>
>> Some of the earlier products would attempt to preserve the sync signal
>> across a GPS lock loss with various levels of success.   For instance the
>> cmm micro in early releases provided a wildly incorrect sync pulse even
>> without a lock.   Same with early syncpipes.  The CTM has a holdover
>> timer.  And so on.   I think most of us have moved away from this in newer
>> designs.
>> On Aug 11, 2015 8:36 AM, "Dan Petermann" <[email protected]> wrote:
>>
>>> What is the minimum amount of satellites needed for a proper GPS sync
>>> pulse?
>>>
>>> And does that differ across products (CMM, CTM, SyncPipe, etc.)?
>>>
>>
>>
>


-- 
*Forrest Christian* *CEO**, PacketFlux Technologies, Inc.*
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
[email protected] | http://www.packetflux.com
<http://www.linkedin.com/in/fwchristian>  <http://facebook.com/packetflux>
<http://twitter.com/@packetflux>

Reply via email to