IQ Display of VLF stations no longer stable? [fixed in v1.344]

edited November 2019 in Problems Now Fixed
Maybe this is cockpit error of some kind but it certainly seems to me like I used to be able to see an extremely stable IQ pattern when looking at the ~25 kHz VLF stations from a GPS or GPSDO referenced Kiwi in IQ extension mode. But tonight, all though things are fine looking at groundwave NIST on 25 MHz, indicating that the Kiwi's clock is OK, the QPSK IQ display of VLF stations is rotating. This appears to be the case with every one of the signals I've looked at. Since I *think* these are very accurate stations, perhaps cesium based even, I can't see how this can even happen. Yet it seems to be the case.
Does anyone else see this and is there an easy explanation?

Glenn n6gn


  • Yeah, something is broken. I tried building older releases and discovered v1.296 (July 5) works. So now I'm going to have to painfully bisect all the versions in-between and figure out what's happened.

    Pretty much all those mil VLF stations use cesium (or better) frequency standards.
  • jksjks
    edited November 2019
    Wow, I see what's going on. This has been broken since the new (more correct) FPGA register synchronization primitive was added back in August. Basically that change caused the software that sets the 48-bits of the receiver channel NCOs (SDR reception frequency) to fail as follows:

    1) The new primitive takes a few more clock cycles to correctly do its synchronization thing compared to the old method.
    2) The phase width of the receiver NCOs (i.e. not waterfall) was increased from 32 to 48-bits back in 2018 when it was realized this could be done at little cost and result in much more accurate frequency setting resolution of the SDR. E.g. you could now tune to the precise frequency of a VLF station in the presence of GPS clock-correction such that there was never any residual IQ display rotation (ionospheric conditions notwithstanding). There could possibly be some rotation with only a 32-bit NCO phase word. See:
    3) Setting the 48-bit value is done in two parts by the software. The most significant 32-bits is transmitted first followed by the least significant 16-bits. Of course there is an intervening register to make sure all 48-bits are updated at the same time as seen by the NCO.
    4) The NOC phase word setting operation needs a synchronizer because a clock domain crossing occurs between the 16 MHz clock of the FPGA e_cpu and the 66 MHz clock of the NCO.
    5) The two phase word writes in e_cpu code occurred too close together such that the second 16-bits lsb write sometimes sent the wrong data if the synchronizer was still busy from the 32-bit write.

    So the fix is to simply increase the delay between the two synchronized writes in software. This exactly accounts for the observed jittery behavior in the IQ display.
  • jksjks
    edited November 2019
    Okay, this change is in today's v1.344 update and seems to work. Thanks Glenn for spotting this.
  • Thanks John for the repair and also for the explanation. That fixed it. I remember the precision change that got us rock-solid displays but I couldn't see how the clock could be good with the receiver slipping.I didn't know about the two-part setting and synch.
    I don't know how you find and fix these things so fast. I guess it's just a heck of a lot of hours in the whole thing!
Sign In or Register to comment.