Hi It *may* turn out to be easier to receive and demodulate the new signal, then use it to de-bpsk the signal to an older box than to try to strip the bpsk. I agree that they may not change anything, but I'd hate to get it all running and have them make a change.
Bob On Jul 7, 2012, at 11:30 AM, paul wrote: > > Pretty sure NIST will not do anything. Just to set expectations. > We are fortunate that to some extent John Lowe is responding to questions. > But we are on our own. > I think the big lesson I have already learned is that there are lots of > standard approaches to solving the problem Micros FPGAs dpll pll..... > But the fun comes in when you account for the 17 db amplitude variation for > modulation. With propagation, with BPSK and sprinkle in noise thats higher in > level then the signal that contains impulse and random crud. > > Now that starts to become really a lot of fun. > I already built a much larger antenna 10 ft by 10 ft loop 25 turns... Lot of > gain added. > Regards > Paul > > > On 7/6/2012 11:28 AM, Bob Camp wrote: >> Hi >> >> My *guess* is that $50 is in the ball park for parts cost of a pretty good >> receiver for the new format. That does not include things like the external >> standard, antenna, frequency comparison stuff, power or case. I'd bound the >> range of the guess as $25 to $100. >> >> Bob >> >> On Jul 5, 2012, at 11:56 PM, J. Forster wrote: >> >>>> On Thu, Jul 05, 2012 at 04:19:25PM -0700, J. Forster wrote: >>>>> If propagation goes south, you loose track of the carrier phase, the >>>>> basis >>>>> of the system. If your local standard is stable and close to right, >>>>> that's >>>>> not a big deal. If not, you can easily go down the garden path. >>>> If I read this correctly, you mean you have a 180 degree >>>> ambiguity due to the BPSK - obviously losing track of the carrier phase >>>> in general with a significantly wrong local standard loses... >>> David, >>> >>> Most of what has been tried is an analog squareing, then a divide by two. >>> No additional PLLs in the system, beyond what is already in the Rx. >>> >>>> I have not devoted enough time to this to be absolutely sure but >>>> it sure sounds like from what I read that if you know the accurate time >>>> to one second it should be possible to unambiguously predict the carrier >>>> phase sequences simply because you know the message format exactly, AND >>>> you know the exact time of day message that is being transmitted or most >>>> of it. >>> The BPSK rate is 1 bit per second, There are 120,000 half cycles in that >>> time. Fades can last seconds, minutes, or hours. It comes down to how long >>> does it take your local standard take to drift roughly 4 uS. >>> >>> At the moment we are not looking at the message at all. >>> >>> Certainly a correlating receiver that uses the message as well as the >>> carrier could be built. But, IMO, that'd be a whole lot easier done from >>> scratch with a micro. The object here is a small, fairly simple, retrofit >>> for the existing receivers. The message format may not be fully defined as >>> yet. The squareing approach is message independant. >>> >>>> There are of course two forms of encoding in PSK modulations - >>>> absolute, and differential (or transition) ... naively to me it would >>>> seem that if absolute encoding is used for this and you know most of the >>>> bits of the message most of the time you could predict which phase will >>>> be used a lot of the time, and also know when you don't know (message >>>> bits you might be uncertain about)... >>> If you used the signal to set your local clock, and knew the format, it >>> should be easy to predict at least a good part, if not all, of the >>> message. >>> >>>> Differential encoding has the down side for this that UNLESS you >>>> know all previous message bits accurately starting from some phase >>>> reference datum you cannot predict what phase is in use at a particular >>>> moment. Absolute encoding (eg 0 phase for a 0, 180 for a one) doesn't >>>> have that liability and if the time of day message is aligned to, well, >>>> the time of day if you know that with reasonable accuracy (and you do >>>> since you are being sent it in the first place) you should be able to >>>> predict a very large percentage of phases used accurately. >>>> >>>> Again, deferring to those who have done the experiments (which I >>>> have clearly not), it would seem that the ability to predict the phase >>>> most of the time would allow creation of a reliable local 60 KHz >>>> reference which could be used to disambiguate those bits you don't know >>>> apriori >>>> >>>> My naive scheme would be to drive a balanced modulator on the >>>> output of the 60 KHz loop antenna with either two or maybe three values >>>> (1 and -1 or 1, 0 and -1) using some cheapie micro (Arduino, PIC etc) >>>> with a software PLL to keep the bit timing in sync with the signal. >>> This is what Equatorial did, in TTL, 30+ years ago. >>> >>>> For bits that one could not predict, one could either output 0 >>>> to the balanced modulator for the entire bit interval which would >>>> produce a drop in the 60 KHz carrier, or do a fast timed fraction of a >>>> bit look at the output of a synchronous detector and choose the most >>>> likely value for the bit and use that, maybe after a brief 0 no carrier >>>> interval to avoid a detectable phase glitch. >>>> >>>> Of course the other approach is to start with the assumption you >>>> have a pretty good stable source of clock or you would not be doing this >>>> to begin with, and simply A/D the 60 KHz with the stable clock (say at >>>> 10 MHz), delay it by storing samples in RAM for one bit time of the low >>>> speed code and use that entire interval to decide which phase you were >>>> seeing and suitably adjust the output phase accordingly when you spit >>>> out the samples delayed by one bit time. >>>> >>>> This later approach would certainly be doable with modern >>>> processors mostly in software, certainly so if you could live with say 1-2 >>>> MHz sampling of the 60 KHz or so... and quite possibly also pretty >>>> nicely with a modest FPGA complete with the sample storage in the chip. >>>> >>>> Both approaches would be helped a lot if the architecture of the >>>> system allows prediction of absolute phase (eg not differential encoding >>>> of unpredictable messages)... and AFAIK that is not yet set in stone and >>>> could be changed to allow this. >>>> >>>> The intent of both of these schemes would be to ultimately >>>> output a De-psk'd signal that older equipment could process using its >>>> antique analog circuitry without serious issues. Thus the output >>>> would be an attempt at a phase stable corrected version of the original >>>> signal... >>> This is what NIST is planning, I think. Make a new receiver, then >>> synthesizing 60 kHz from the internal locked clock. It's kinda like a TV >>> 'Converter Box'. It will continue to provide the functionallity, but at >>> what price? At $50 it would be a good deal; at $5000 not so much, IMO. >>> >>> -John >>> >>> ================= >>> >>> >>> >>>> Certainly using a lab reference stable 10 MHz derived 960 Khz >>>> or whatever sampling clock to delay the signal one time code bit time >>>> should not produce significant 60 KHz phase wanderings at all... >>>> >>>> -- >>>> Dave Emery N1PRE/AE, d...@dieconsulting.com DIE Consulting, Weston, Mass >>>> 02493 >>>> "An empty zombie mind with a forlorn barely readable weatherbeaten >>>> 'For Rent' sign still vainly flapping outside on the weed encrusted pole - >>>> in >>>> celebration of what could have been, but wasn't and is not to be now >>>> either." >>>> >>>> >>> >>> >>> _______________________________________________ >>> 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.
