jks

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: http://forum.kiwisdr.com/discussion/comment/5069
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.

Today's v1.337 update adds waterfall filtering (averaging). The filtering methods and adjustments parallel those used for the spectrum filtering, although the range of slider values is slightly different based on practical experience. The waterfall and spectrum filtering are independently adjustable.

Below shows progress with an experiment to get a 14-channel configuration working using a BeagleBone AI. The challenge is to move as much processing to the second cpu core of the AI as possible so as not to impact the realtime requirements of serving the 14 audio channels (plus the usual 12-channel GPS etc.) It seems to work. A 14 audio DDC + 1 waterfall DDC configuration (rx14_wf1) was made to fit in the FPGA (LUTs now 97% full) by reducing the amount of CIC filtering logic slightly.

Note below that the processor temperature and clock speed are displayed. The cores are currently running at rate automatically adjusted based on temperature between 1.0 - 1.5 GHz due to the reduced cooling configuration I'm testing.



The Kiwi's internal WSPR extension is running on all 14 channels as a worst-case test since WSPR decoding is so cpu intensive. The fact that this works does not change the fact that Rob's wsprdaemon is the superior solution for anything but casual WSPR monitoring. In fact 14 channels was chosen in support of getting a single Kiwi to work in an all-band wsprdaemon setup.

Below is output from the Linux "ht" command. It shows how certain components of the software have been moved to new Linux processes separate from the main Kiwi process and "locked" to the second core of the processor. "kiwid" is the main process and is locked to cpu0 as seen in the "cpu" column. The other "kiwi.xxx" processes are locked to cpu1. Of interest here is the "kiwi.wsp" process which runs the collective WSPR decoding of all 14 channels.



This is just a progress report. There is a long list of work to do.

The Kiwi repo "dev" and "master" branches are now closely synchronized again after dev having held the AI stuff exclusively for a long time. I think it will automatically revert to the usual update scheme because the current version number on the master branch (v1.338) is greater than what was in the last dev branch you manually pulled (335 or 336). So you shouldn't have to do anything I think.

Today's v1.337 update adds waterfall filtering (averaging). The filtering methods and adjustments parallel those used for the spectrum filtering, although the range of slider values is slightly different based on practical experience. The waterfall and spectrum filtering are independently adjustable.