Re: [time-nuts] WWVB PM Time Questions
Hi Or … you can cheat. If the objective is a lab reference of some sort (and not a stand alone clock), cheating may be an acceptable solution. Add a real time clock into the mix and you know the month / day / hour / minute before you ever see the first cycle from the antenna. Indeed, you likely have a pretty good guess at the second as well. Cost wise, it’s the price of the battery you wire to your MCU …… No this isn’t the most exciting way to do it. I’d suggest that it might well be a very reliable way to get it done. Redundancy is a good thing :) Bob > On Aug 1, 2020, at 3:27 PM, Poul-Henning Kamp wrote: > > > paul swed writes: > >> Decoding the actual timecode is a serious pain. > > Not really if you approach it from the right side. > > A lot of people try to decode these timecodes by looking for a perfect > timegram. That works badly in low SN. > > First Tune your discriminator to have three output states: High, > Low and Dont_Know. It must only output High or Low if it is very > certain, any doubt and it outputs Dont_Know. > > Next: Find the Hour+Minute combination. > > There are 86400 possible seconds in the day we can be right now, > our job is to eliminate the 1439 impossible time-grams and align > the last one. > > Imagine for a moment, that we brute force all 86400 combinations > every time we receive another High or Low bit. > > If the Day comes out to 31, the month has to be one of J,M,M,J,A,O,D, > anything else can be eliminated. > > The LSB of the minutes must, by definition, change every minute, if > it had same state last minute, we can rule this one out. > > The Day/month/year fields, can only change from one minute to the > next, if Hour bits we have are compatible with 23 before and 00 > after. > > It may sound like a lot of computing, but it does not take many > good bits before almost all the 86400 possibilities have been ruled > out and even in horrible S/N we will have found the Hour, Minute and Day > in a matter of minutes. > > Once we're there, we can collect the date bits we still miss. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] WWVB PM Time Questions
paul swed writes: > Decoding the actual timecode is a serious pain. Not really if you approach it from the right side. A lot of people try to decode these timecodes by looking for a perfect timegram. That works badly in low SN. First Tune your discriminator to have three output states: High, Low and Dont_Know. It must only output High or Low if it is very certain, any doubt and it outputs Dont_Know. Next: Find the Hour+Minute combination. There are 86400 possible seconds in the day we can be right now, our job is to eliminate the 1439 impossible time-grams and align the last one. Imagine for a moment, that we brute force all 86400 combinations every time we receive another High or Low bit. If the Day comes out to 31, the month has to be one of J,M,M,J,A,O,D, anything else can be eliminated. The LSB of the minutes must, by definition, change every minute, if it had same state last minute, we can rule this one out. The Day/month/year fields, can only change from one minute to the next, if Hour bits we have are compatible with 23 before and 00 after. It may sound like a lot of computing, but it does not take many good bits before almost all the 86400 possibilities have been ruled out and even in horrible S/N we will have found the Hour, Minute and Day in a matter of minutes. Once we're there, we can collect the date bits we still miss. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] time-nuts Digest, Vol 193, Issue 1
Hi The gotcha these days is that MCU hardware just keeps getting cheaper and cheaper. You can get a quite adequate MCU to do all this for less than the price of your 1496 …. Yes, that’s nutty, but it’s the way pricing works these days. Worse yet, you can get a Chinese assembly house to supply that CPU on a board for you (along with various small parts) and still not have spent very much at all for the parts plus the board. The ~$25 shipping likely will cost almost as much or more than a handful of assembled boards. Again, it’s a nutty world. Bob > On Aug 1, 2020, at 1:45 PM, Tim S wrote: > > I would also suggest that a simple frequency doubling if using a > differential output op-amp is too hard would get one there. Something like > a balanced lm/mc1496 mixer will double the input frequency if the inputs > are the same. > > IMHO it's tempting to use software where simple (cheap! LM1496 is about > $0.80/each on Digikey) analog hardware will do the trick. But it's the > same math whether an analog circuit is doing it by design or if software is > doing it. > > -T > > On Sat, Aug 1, 2020, 09:00 wrote: > >> Date: Fri, 31 Jul 2020 21:00:13 + >> From: "Poul-Henning Kamp" >> To: Discussion of precise time and frequency measurement >>, Bob kb8tq >> Subject: Re: [time-nuts] WWVB PM Time Questions >> Message-ID: <85171.1596229...@critter.freebsd.dk> >> Content-Type: text/plain; charset="us-ascii" >> >> >> Bob kb8tq writes: >> >>> The WWVB modulation is *very* predictable. Once you have lock, >>> you can guess just about every phase reversal you will see. >>> [...] >>> The point of this being that you *could* pre-flip the data before it >>> went into a buffer. That way the buffer integration time constant >>> could be quite long. >> >> I would just use two buffers and decide which one based on the >> prediction, that way DC-offsets will not cause trouble. >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> p...@freebsd.org | TCP/IP since RFC 956 >> FreeBSD committer | BSD since 4.3-tahoe >> Never attribute to malice what can adequately be explained by incompetence. >> > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] time-nuts Digest, Vol 193, Issue 1
I would also suggest that a simple frequency doubling if using a differential output op-amp is too hard would get one there. Something like a balanced lm/mc1496 mixer will double the input frequency if the inputs are the same. IMHO it's tempting to use software where simple (cheap! LM1496 is about $0.80/each on Digikey) analog hardware will do the trick. But it's the same math whether an analog circuit is doing it by design or if software is doing it. -T On Sat, Aug 1, 2020, 09:00 wrote: > Date: Fri, 31 Jul 2020 21:00:13 + > From: "Poul-Henning Kamp" > To: Discussion of precise time and frequency measurement > , Bob kb8tq > Subject: Re: [time-nuts] WWVB PM Time Questions > Message-ID: <85171.1596229...@critter.freebsd.dk> > Content-Type: text/plain; charset="us-ascii" > > > Bob kb8tq writes: > > >The WWVB modulation is *very* predictable. Once you have lock, > >you can guess just about every phase reversal you will see. > >[...] > >The point of this being that you *could* pre-flip the data before it > >went into a buffer. That way the buffer integration time constant > >could be quite long. > > I would just use two buffers and decide which one based on the > prediction, that way DC-offsets will not cause trouble. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] WWVB PM Time Questions
What may be helpful to the wwvb projects is what is always fixed. This comes out of the NIST document. Assume you have a fairly good oscillator. If it can hold within 1/2 cycle of 60 KHz (10 us) for 47 seconds you can simply sample the top minute sync word. Thats from 59-11 seconds. Always fixed. But thats a bit too easy. NIST gave us a bit more of a challenge. At 10 and 40 past the hour the slow code runs and its format is different. But has a 106 second sync word thats always fixed and always at the same location. If you have a locked oscillator then the timecode recovery is reasonable. Decoding the actual timecode is a serious pain. Good luck Paul WB8TSL On Fri, Jul 31, 2020 at 6:07 PM Poul-Henning Kamp wrote: > > Bob kb8tq writes: > > > It also *very* much depends on the stability of your local reference and > the > > stability of the ionosphere. Unless both are 'pretty darn good' a > hundred second > > integration is utter nonsense > > This is why Loran-C was so superior to any and all CW based modulations. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > ___ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] New GPS Antennas From Molex
Time Nuts, These are interesting: https://www.molex.com/molex/products/family/gnssgps_antennas 73's, John AJ6BC ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] sub harmonic VCO locking
Hi Attila thanks for your input. and thanks for the links ! I'll meet my low-spec option using ADF4356 integer mode, and a 394 MHz off the self $2 SAW filter on the output. That is what I'll do for the moment. I have the ADF4356 here on a eval board ADI lent me. It is not bad for an internal VCO chip. makes 126/ 10k @ 400 megs. Actually the Hittite HMC1033 is slightly better but 26 weeks. Discrete VCO using a TriTech TEM resonator (Q=400 400 MHz) was good also, with integer PLL chip. Maybe use a ceramic resonator up at 1.6 GHz where there is more Q and the chips are designed for the 1-4 GHz VCO input (LTC6945 etc) When I need to get the 5kHz to 100kHz noise down, I'l probably go for direct multiplication. 73 On 8/1/2020 2:06 PM, Attila Kinali wrote: On Thu, 30 Jul 2020 21:56:42 +1000 glen english LIST wrote: - a double-double-double could work, but my experience is for x2 x2 x2 I really need to filter well at each stage to avoid sum and difference products.. which might be OK for this application , especially if I filter really well after the first x2 . but avoid if I can. filters at 908 MHz need space, and shield cans where it is going. Frequency multiplying would be probably the easiest to get low noise, followed by a well designed PLL system. Though -115dBc spurs is tough, - and I dont know too much about phase noise and SRD or varactor multipliers. but maybe that's an option. SDR are prety low noise. From NLTLs we know that varactor systems can exhibit increased flicker noise levels (probably due to bias point instability). - onboard VCO chip/PLLs have all sorts of unrelated spurs in the output. - sure I can use a good PLL and a external VCO, but if my N value is fixed, and I can use injection locking, why bother with the PLL chip that is likely to introduce PD related spurs anyway. The generic way in this case is to build a PLL using frequency multiplier for the reference and a narrow loop filter after the phase detector. Placing zeros at the multiples of the (unmultiplied) reference frequency in the loop filter will reduce the spurs quite considerably. Injection locking is finicky. To injection lock, the resonator has to be pretty much on frequency to begin with, and kept that way. But unlike with other systems, you have no feedback system where get information how far off you are to control the frequency. Unless you build a hybrid system of an oscialltor with a Pound lock[5,6] (e.g. like cryogenic sapphire oscillators use[7]) You want to read Adler's paper[1] at the very least before you start. A look at the work byHuntoon/Weiss[2] and Kurokawa[3,4] is probably also beneficial. Attila Kinali [1] "A Study of Locking Phenomena in oscillators", by Robert Adler, 1946 (reprinted 1973) [2] "Synchornization of Ocillators", By Huntoon and Weiss, 1947 [3] "Injection Locking of Microwave Solid-State Oscillators", by Kurokawa, 1973 [4] "Noise in Synchronized Oscillators", by Kurokawa, 1968 [5] "Electronic Frequency Stabilization of Microwave Oscillators", by Pound, 1946 http://dx.doi.org/10.1063/1.1770414 [6] "Frequency-Stabilized Oscillator Unit Notes and Instructions", by Lawrance, 1946 https://dspace.mit.edu/bitstream/handle/1721.1/5024/1/RLE-TR-022-14254857.pdf [7] "An Ultra-Low Noise Microwave Oscillator Based on a High-Q Liquid Nitrogen Cooled Sapphire Resonator", by Woode, Tobar, Ivanov, 1995 ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
