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@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@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@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@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@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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.