WSPR internal kiwi decoder

F1HDI

Hi,
I would like to know if the the wsprd version onboarded on the kiwi software is the latest one ?. If this is not the case, how is it possible to upgrade it ?. The question is because I am making some tests on 144 WSPR with a downconverter 144->28 feeding a kiwi and another sdr (throught a splitter) and the performances are far better on the alternative chain sdr-> vav -> wsjt-x 2.2.1. BR Jean-Marc F1HDI

Powernumpty

Use wsprdaemon.
That uses external processing like your alternative chain.

jks

The Kiwi's internal WSPR already doesn't even use some of the advanced decoding options of the existing, older code. Like the 2nd pass spectral subtraction phase. This is because the Beagle doesn't have enough processing power to run the full algorithm within the 2 minute decoding window.

Stu is right: use wsprdaemon.

WA2ZKD

I would advise anyone that is serious about wspr receiving to run wsprdaemon. Depending on what platform you run it on, it can decode and process many channels. I have a headless Odroid XU4 and 2 Kiwi-BBAI and it does 28 channels, all 14 wspr HF bands on 2 antennas. KD2OM runs the same and is generally ranked #1 or 2 in the US/VE for wspr reporters. A lesser RPi can handle quite a few channels/decodes.

jks

I didn't have time yesterday to elaborate. The answer is no because to work at all in the real-time Kiwi environment the FFT's in the WSPR algorithm had to be spread across the two minute sampling interval so as not to load the Beagle cpu too much. But this means the required data is not available at the right time to perform the two-pass algorithm where the entire result must spectrally subtracted and the decode performed again. One possibility is to recode the algorithm again from being the standard WSPR 2 minute pipeline delay to a 4 minute pipeline. It could be done but you'd have to rewrite everything completely. There would be an extra delay in reporting results to wsprnet.org but that shouldn't matter.

Another possibility is for multicore architectures to use the original WSPR algorithm, 2nd pass and all, but force it to run on cores other than zero so as not to disturb Kiwi realtime. This is probably easier, but still a lot of work.

The devil is always in the details. Particularly with this project.

rrobinet

I could imagine installing WD on a BBAI machine and dedicate a core to run it.
But synchronizing Kiwi and WD code upgrades would be a mess.
For example, just this week I was able to upgrade 20+ WD sites to use the wsprd in WSJT-x 2.2.1 which produces up to 6% more spots from the same antenna+Kiwi.
Also, many installations use 2 or more antenna+Kiwis, and embedding WD in one Kiwi would result in an asymmetric set of Kiwis.

So it is far better to run WD on a $35 Pi 3b (or better yet a 2/4Gb Pi 4) which can support 30+ channels of Kiwi bands.

jks

@Rob: I agree 100%