[time-nuts] Phase modulation detection/NIST plan

Bob Camp lists at rtty.us
Mon Jul 9 01:01:25 UTC 2012


Hi

The clocks we would be using are *much* better than what most military systems use….

I also *assume* that an initial lock up that takes a hour is perfectly acceptable in this application. You will still need a lot of hours / days / what ever of data to get useful stability off of WWVB, spending an hour or more to acquire from a cold start will have little net impact.

Bob
 
On Jul 8, 2012, at 7:29 PM, J. Forster wrote:

> A risky assumption, and a cold start could be tricky.
> 
> Equatorial took many minutes to lock up, with a much higher data rate, and
> it did it by slowly sweeping the local clock.
> 
> Aside: That's why military spread spectrum systems like good local clocks.
> They lock up a whole lot faster that way.
> 
> -John
> 
> ================
> 
> 
> 
>> Hi
>> 
>> In this case the data format and it's contents are highly "computable". If
>> you have a good local clock *and* an initial lock, the rest of what
>> follows is predictable. That of course assumes we know the real format ….
>> 
>> Bob
>> 
>> On Jul 8, 2012, at 6:58 PM, J. Forster wrote:
>> 
>>> Hi Peter,
>>> 
>>> That's be the hard way, but yes, if the message BPSK coded is computable
>>> and of a known format. If the message contained more than time, like
>>> solar
>>> flux, it gets more complicated very rapidly.
>>> 
>>> A similar thing was done with the Equatorial system 30+ years ago. In
>>> that
>>> case, each data bit was broken into something like 32 or 64 chips (I
>>> don't
>>> remember). There were two maximally distant, orthogonal chip patterns,
>>> representing 1 and 0. The incoming BPSK message went through a 0 or 180
>>> degree switch, then the IF stages. The switch was driven from a local
>>> (known pattern) chip generator, so that if everything was synced up the
>>> narrow band IF would put out the 0 or 1 that had been encoded. BTW, this
>>> trick vastly improved the system S/N becaust it narrowed the receiver IF
>>> bandwidth many times.
>>> 
>>> If the chip pattern is not known (fixed) or computable (like a correct
>>> TOD) things go to pot quickly.
>>> 
>>> Rather than building such a kludge, it would be easier to use the locked
>>> clock in a newly designed receiver and phase compare that to your local
>>> standard directly.
>>> 
>>> -John
>>> 
>>> ==================
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> Any possibility of using the decoded signal to un-do the modulation and
>>>> feed the reconstituted signal to the older receiver?
>>>> 
>>>> 
>>>> 
>>>> On 7/8/2012 12:56 PM, paul wrote:
>>>>> Ei
>>>>> Sorry if I have your name reversed. By taking this approach it
>>>>> eliminates the ability to use wwvb as a frequency reference because it
>>>>> destroys that traceability.
>>>>> Thats what we are trying to preserve. Or at least re-establish for the
>>>>> older phase measuring receivers.
>>>>> Regards
>>>>> Paul
>>>>> 
>>>>> On 7/8/2012 12:10 PM, Tofurk Ei wrote:
>>>>>> If the changeover you are talking about is this one:
>>>>>> http://www.nist.gov/pml/newsletter/radio.cfm as a proof of concept a
>>>>>> DVB-T
>>>>>> dongle/upconverter combo could almost certainly handle PM easily to
>>>>>> output
>>>>>> whatever it encodes, when paired with gnuradio..
>>>>>> 
>>>>>> The RTL2832U chip might also be able to handle some low band signals
>>>>>> directly, using direct sampling. No upconverter.
>>>>>> 
>>>>>> Regardless, then the data would be fed into gnuradio - the gnuradio
>>>>>> developers GUI is called "gnuradio companion" It has a nifty way of
>>>>>> doing
>>>>>> this kind of thing, one builds a "flow graph" where the actual
>>>>>> demodulation
>>>>>> is simply laid out graphically and tested.
>>>>>> 
>>>>>> When everything works to one's satisfaction the file is saved and it
>>>>>> gets
>>>>>> compiled - then it can run - its basically a python script.
>>>>>> 
>>>>>> If the modulation scheme is public, I think you can be almost certain
>>>>>> that
>>>>>> gnuradio might be quite useful to rapidly design a tool to demodulate
>>>>>> it.
>>>>>> Perhaps very quickly.
>>>>>> 
>>>>>> For the money, one really couldn't hope to beat the flexibility of
>>>>>> this
>>>>>> combination in any other manner. If I were interested in trying this
>>>>>> I
>>>>>> would join the gnuradio mailing list and ask there. Perhaps the
>>>>>> answer is
>>>>>> surprisingly simple.
>>>>>> _______________________________________________
>>>>>> time-nuts mailing list -- time-nuts at febo.com
>>>>>> To unsubscribe, go to
>>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>>> and follow the instructions there.
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> time-nuts mailing list -- time-nuts at febo.com
>>>>> To unsubscribe, go to
>>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>>> and follow the instructions there.
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts at febo.com
>>>> To unsubscribe, go to
>>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>>> and follow the instructions there.
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>> 
>> 
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
>> 
> 
> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.




More information about the time-nuts mailing list