[time-nuts] HP 117/10509a...

Bob Camp lists at rtty.us
Sat Jul 7 16:14:05 UTC 2012


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, die at 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 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_lists.febo.com mailing list