v1.352: new time station extension (timecode decoder)

After sitting on the "back burner" for almost 3 years the timecode extension is now available. It's useable but incomplete, has missing features and many known bugs.

It's also more of a curiosity than anything really useful. But that can be said to a varying degree about the entire project I suppose. I did it because it was fun. Something that has been in short supply lately.
PowernumptySWLJO43HB9TMCrz3dvp

Comments

  • Upvoted for the fun side, the world has got very serious, like we are all to blame for something and should feel bad all the time.
    I've just spent the last few minutes pointlessly staring at time signals like a cat watching birds, it was great.
  • I saw your post on Twitter and yes, sort of wondered "why?" But, having fun makes a lot of sense in itself, and your entire project is exceptionally useful to a lot of people! I have tested and to a part used, SDR servers like the Perseus, SDR-Server, Spyserver and SDRAnywhere. Each may have maybe 0-20 users at any given time, while the Kiwis on sdr.hu alone have several hundred users. I personally know several DX-ers who parted with the hobby decades ago, but are now back in business and having great fun.
  • Would be cool if you could plot the delay between GPS time and the time station time.
  • I like this extension.

    I had been attempting to manually decode the amplitude encoding from both, the MSF60, and the DCF77 signals for a while now out of sheer curiosity.

    The timecode extension works very well for me on the MSF60 signal on my own kiwi (about 30dB difference between carrier /no-carrier), and is a little flakey on the DCF77 at about 10-15dB difference carrier/no-carrier. Ah, the disadvantages of a rather crappy antenna and a slightly noisy suburban location for the SDR.

    Looking at KiwiSDRs around the net, the WWVB-phase appears to work really well once the signal is available, but the WWVB-Amplitude can only see "1"s for the decoding on the SDRs I've looked at anyway in the Continental US.
  • all 1's from the amplitude decode here in Fort Collins. Phase works great.
  • I'll look at WWVB-ampl again. I first started with WWVB-phase and added the others from there. But later I noticed it didn't work as well as I had remembered. So maybe I've inadvertently changed something.

    There are many improvements that could be made. I'm sure the PLL operation is not optimal since I don't understand PLLs very well (the one I use is Christoph's from his additions to the IQ display extension). There is no checking of the various parity bits in the timecode(s) or decoding of anything other than the time.

    WWVB-phase has additional features that are currently ignored (e.g. the 6-minute extended symbols). And of course DCF77-phase would be extremely interesting to add. JJY should be easy to add. BPC's timecode format is supposedly "closed-source" (any help appreciated). WWV/WWVH 100 Hz sub-carrier needs PLL damping changes due to its lower duty cycle (I think). I have not considered the Russian sources at all.

    Delay comparisons with GPS is not currently possible as high-resolution timing (e.g. IF/audio zero-crossings) is not done. Just the gross amplitude/phase information is measured at a single point to get the timecode. This same issue is why the Loran-C extension can't do any navigation calculations. There is not enough time resolution at the audio sampling frequency. You'd have to do it in the FPGA at a higher IF, like in an intermediate stage of the audio CIC filtering perhaps.
    HB9TMC
  • Checked out the WWVB decoder and the FSK CHU decoder. Both work well





    Ron
    KA7U
  • v1.433 February 12, 2021

      Timecode extension improvements:

        Support for JJY(Japan), RBU(Moscow), RTZ(Irkutsk), BPC(China) added.

        While running AGC delay is temporarily increased to improve noise immunity.


    rz3dvpcathalferrisKA7U
Sign In or Register to comment.