[time-nuts] Phase modulation detection/NIST plan

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


HI

My assumption is that for what we would be doing, one lock is all it's going to take. The local clock will be good enough to allow you to never need to re-aquire. You will indeed steer to maintain phase, but you already have and know what's coming in on the modulation. 

Bob

On Jul 8, 2012, at 9:16 PM, J. Forster wrote:

> If you have a deep fade every few hours or minutes, as is common, relock
> time becomes an issue.
> 
> -John
> 
> ==============
> 
> 
>> 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.
>> 
>> 
>> _______________________________________________
>> 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