Second build sold out. Message will appear here when store is ready for third build ordering.

QRSS and the Kiwi

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.....

Comments

  • The waterfall has no relationship to the audio.... as John recently explained, the WF and Audio are seperate receivers.
  • Maybe I misunderstood, but that's not how I understood k5mo's question. What I heard him asking is whether in decoding QRSS in an a communications channel (not the wide Kiwi waterfall) whether additional processing was done by the 'standard' QRSS tools in order to enhance detection by the human eye. This seems to me to be part of a greater question about the utility of human cognition via graphic representations, e.g. how far below the noise (normal definition) can a human eye 'detect' the Morse characters of a QRSS message/call sign compared to say WSPR or FT8?
    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.
  • There is nothing currently that integrates long-period signals like QRSS. The integrate extension does it for short period signals like time stations (~1 sec). It has been suggested that the waterfall have a mode where when running in slow update mode it integrates samples taken at full-rate.
  • Thanks everyone, and Glenn, you did interpret my poorly formed question correctly.

    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
  • I know very little about QRSS except that like many of the other narrowband modes it comes in several flavors. I believe it is a fairly simple system in which one can effectively set varying bandwidths by selecting different 'dit' times. I think this is essentially a speed/averaging/bandwidth trade-off. With that done is it not the case that Argo or similar simply allow setting waterfall colors and bounds to allow the eye to effectively process the graphic and recover the call/information?

    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.
  • A simplistic but useful way of thinking about this issue is this: Suppose the waterfall is slowed to draw one line every ten minutes. During those ten minutes it could be sampling at ~21 Hz (full rate) and integrating those samples so the coherent QRSS signal is gaining a huge SNR advantage over the random noise. But the waterfall doesn't do that currently. It would just sit idle for ten minutes then take one sample.

    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.
    k5mo
  • Thanks for that explanation John, and while it's not the QRSS-friendly answer I wanted to hear, it does explain what I'm seeing (or in this case NOT seeing).

    Let me know if you ever need a beta tester on that extension you describe :-)

    John
  • I hope it's OK to revive a dead thread.

    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?
Sign In or Register to comment.