Why bother? If you have to build/buy a new receiver to make your old receiver work, why not just use the new receiver?
YMMV, -John =============== > 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. > > _______________________________________________ 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.