QRSS and the Kiwi
in General Chat
I've recently been doing some 22M HiFer listening (and transmitting) and am really amazed at some of the reception distances with these pipsqueak signals .
I have a question that's part Kiwi and part QRSS : In a dedicated QRSS decoder (like Argo ,for example) is there additional signal processing OTHER than just a very slow waterfall? The root question is, can I effectively use the Kiwi as a QRSS receiver simply by slowing down the waterfall speed, or am I oversimplifying the process?
AFAIK (which isn't much) QRSS is merely uber-slow CW but.....
I have a question that's part Kiwi and part QRSS : In a dedicated QRSS decoder (like Argo ,for example) is there additional signal processing OTHER than just a very slow waterfall? The root question is, can I effectively use the Kiwi as a QRSS receiver simply by slowing down the waterfall speed, or am I oversimplifying the process?
AFAIK (which isn't much) QRSS is merely uber-slow CW but.....
Comments
I don't know the answer but crude estimation and trial leads me to think that QRSS ==> eye detection is at least 10 dB worse than a nearly optimum process such as WSPR. It's good and the *presence* of a signal may be recognized with less spread but to actually transfer a comparable number of bits in a given time, the K1JT modes are quite a bit better.
It's my impression, and it may be wrong, that a tool like Argo doesn't do anything fancy in the way of processing. That is, beyond setting a narrow bin size and good choice of color to aid detection of a narrow band signal, no special processing is done. I too would be interested to know if this is a correct assessment.
I have used Argo as a 22m CW signal monitor for many years. I know I can usually SEE signals that I can't hear. I just don't know if Argo has some sort of internal function that enhances its display of received signals more than setting my Kiwi to a slow waterfall rate, and adjusting the sliders on Max/min signal levels might (the integrate function you mention sounds like it would, John). I'm new to QRSS monitoring and am interested in this. I've pumped the audio from the Kiwi via Virtual Audio Cable to Argo , but for whatever reason (Kiwi, VAC, Windows 10, Argo) there's often a "freeze" where I have to reset things about once a day. That's my interest in eliminating a lot of this more complicated signal chain to create a robust long term QRSS monitor. I'd like the kiwi for this as I can have multiple instances of monitoring per kiwi, unlike other solutions.
I'll try and track down the author of Argo (an Italian gentleman, IIRC) and ask him . I know he's not touched that software very often since release so I hope he's still around. I don't know if the other software (Spectran, QRSSPiG) do either.
I'll ask around and see what I find. Again, thanks for the info.
John
If this is how it works then it would seem that a kiwiSDR might be extended to similarly recover and display like Argo does. As an example of something similar, take a look at the WSPR extension within the kiwi. The waterfall that comes with it is tailored for the bit rate/bandwidth of a WSPR transmission and displays the result in a manner not too different from what I've seen from QRSS but other than that plays no part in recovering data. Data recovery is performed with an (older version) of the wsprd decoder. But perhaps that waterfall might be approximately correct for one of the common QRSS rates? If so, you might simply try it out and compare with argo or whatever tool you normally use to see what it looks like. Since it is adapted to a ~6 Hz wide signal, it may not be correct to do the best job but OTOH it may be useful in estimating what is possible should someone want to build a QRSS decoder extension for the KiwiSDR. I'm not voting on whether or not this is desirable just noticing that when in the KiwiSDR wspr extension one can still tune to a non-WSPR frequency and use the waterfall display. Perhaps this is a useful start - or not.
No doubt simply streaming kiwi audio to an existing decoder is better and perhaps what you're looking for. I'm not sure why you are having "freezes", it is definitely possible to use a kiwi to provide an audio stream for other decoders. I have done this over extended periods for decoding WSPR, FT8 and other JT modes with no problem.
With the multiplicity of 'receivers' the kiwi is indeed an attractive platform for these kinds of uses, IMO.
The integrate extension does a little better. It does integrate every time its waterfall output wraps around top-to-bottom. If the integration period (time to draw everything top-to-bottom) is short (e.g. 1 sec for time stations) then this is useful. But it isn't designed to work any better with long periods. So it's no good for QRSS signals.
On the wish-list for a long time is a high-resolution FFT extension. One that could for example be used to resolve the millihertz differences of AM BCB stations (a technique already used very effectively by AM BCB DX'ers). Such an extension would naturally do long-period averaging in addition to high frequency resolution.
Let me know if you ever need a beta tester on that extension you describe :-)
John
What exactly does "integrate" mean in this case? I've also been wondering about QRSS lately. Are we just talking about taking a bunch of full-rate (21 Hz) FFTs and averaging them, or is there fancier math going on here?