Number Juan and not two or three
On Aug 12, 2015 12:07 PM, "Bill Prince" <[email protected]> wrote:

> Which Juan?
>
> bp
> <part15sbs{at}gmail{dot}com>
>
>
> On 8/12/2015 11:05 AM, Jaime Solorza wrote:
>
> maybe he should switch to Number Juan Tequila
> http://numberjuantequila.com/
>
> Jaime Solorza
> Wireless Systems Architect
> 915-861-1390
>
> On Wed, Aug 12, 2015 at 11:54 AM, Bill Prince <[email protected]> wrote:
>
>> It's all that vodka.
>>
>> bp
>> <part15sbs{at}gmail{dot}com>
>>
>>
>> On 8/12/2015 10:52 AM, Vlad Sedov wrote:
>>
>> Having lived around Soviet RFs for many years, I can tell you first hand
>> that they are the laziest RFs with the worst work ethic.
>>
>>
>> Vlad
>>
>> On 8/12/2015 12:42 PM, Mathew Howard wrote:
>>
>> We don't need any stinkin' commie RF!
>>
>> Добрий День товарищ!
>>
>> On Wed, Aug 12, 2015 at 12:36 PM, Shayne Lebrun <[email protected]>
>> wrote:
>>
>>> Nyet, Tovarich.  Superior SOVIET RF works four times as hard as any lazy
>>> capitalist RF, and without exploiting the proletariat photons.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Af [mailto:[email protected]] *On Behalf Of *Jaime Solorza
>>> *Sent:* Wednesday, August 12, 2015 1:22 PM
>>> *To:* Animal Farm
>>> *Subject:* Re: [AFMUG] GPS Timing
>>>
>>>
>>>
>>> not to worry Comrade   RF is universal
>>>
>>>
>>> Jaime Solorza
>>>
>>> Wireless Systems Architect
>>>
>>> 915-861-1390
>>>
>>>
>>>
>>> On Wed, Aug 12, 2015 at 9:52 AM, George Skorup <[email protected]>
>>> wrote:
>>>
>>> Cambium is using a new receiver on the 450APs that does GPS+GLONASS. I
>>> assume it's from Global-Top, but I haven't opened up a new AP to look. I'm
>>> not real excited about using the Russian signals, but with so many
>>> satellites available, it does acquire lock very fast. Have you thought
>>> about doing the same for your 'Pipes? I think it would be beneficial.
>>>
>>>
>>>
>>> On 8/12/2015 5:34 AM, Forrest Christian (List Account) wrote:
>>>
>>> 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