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 -- [email protected] >>> To unsubscribe, go to >>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >>> and follow the instructions there. >> >> >> >> _______________________________________________ >> time-nuts mailing list -- [email protected] >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
