-------- 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 phk@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.

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 <phk@phk.freebsd.dk> 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 > phk@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.