[TangerineSDR] ka9q-web success

[Phil Karn]

I'm in favor of doing this to extend the existing demodulator functions, 
e.g., supporting narrower IF filters than I can do right now. I'd 
already been thinking of doing this to better support narrow CW 
reception. But when the functionality becomes qualitatively different it 
probably should remain in a separate module. I think identifying WWV vs 
WWVH is in that latter class. Even if you do it by just noncoherently 
summing the audio tone energies, you'll want to get both sidebands and 
probably gate the integrators with their scheduled transmission times. 
That's pretty specific.

This extension could also eliminate a current artifact. It's pretty 
subtle so I don't know if anyone else has noticed it. If you select a 
very narrow bandwidth and slowly tune across CW signals, the passband 
will seem to "wiggle" as you tune. That's because the filtering is done 
in integral FFT bins 40 Hz wide while the fine tuning is done with a +/- 
20 Hz local oscillator and mixer after the filter. This makes the 
passband seem to wiggle +/- 20 Hz as you slowly tune in one direction. 
This happens despite the edges of the filter passband being tapered with 
a Kaiser window, i.e., the filter is never exactly 1 bin wide but tapers 
over a few. You can exaggerate the effect by setting the Kaiser 
parameter to zero, which then becomes a narrow rectangular window.

In effect, this additional FFT/IFFT would use the existing filter as a 
roofing filter and then add a narrower one. It will necessarily add 
delay, and because my filters are linear phase (as opposed to minimum 
phase) this extra delay may become more noticeable.

Hmm, it just occurred to me that this structure might also let me 
re-implement ISB (independent sideband), something I broke a while ago 
when I went to my current shared-FFT multichannel scheme. The second 
FFT/IFFT could separate the sidebands.

Phil

On 2/28/24 05:50, Franco VENTURI via TangerineSDR wrote:
> Phil, John,
> welcome to the mailing list and kudos and many thanks for ka9q-radio and ka9q-web!
>
> I really like the idea of combining several 20ms frames not just for the purpose of zooming in on the spectrum display but also because I think it would be very useful for using the RX888 and ka9q-radio for scientific and propagation research where in many cases the researcher is interested in very low sample rates (like 10sps) over very long durations (hours, and days), like the data provided by the the GRAPE receivers.
>
> If this were implemented in ka9q-radio it would be possible to use it directly to create those 10sps datasets for the GRAPE network (instead of having to postprocess them with sox, like Rob does now in WSPRdaemon). It would probably also be very useful in the detection of WWV vs WWVH, since one could obtain directly from ka9q-radio the energy bins around 1000Hz and 1200Hz (if I remember correctly), and then run something similar to Michael Hauan's application to evaluate the relative strength of the two stations.
>
> Franco
>
>
>> On 02/28/2024 6:53 AM EST John Melton via TangerineSDR <tangerinesdr at lists.tapr.org> wrote:
>>
>>   
>> I am also now on this list as well.
>>
>> -- John G0ORX
>>
>> On 2/28/24 11:30, Phil Karn via TangerineSDR wrote:
>>> Hi John,
>>>
>>> I just realized I wasn't subscribed to the TangerineSDR list, mainly
>>> because people usually cross-post to it and HamSCI and/or to me
>>> personally. I'm on it now.
>>>
>>> I'm glad you like G0ORX's ka9q-web; wish I could take credit for it
>>> but it's John's.
>>>
>>> Well, I guess I can take credit for part of it, namely designing
>>> ka9q-radio's multicast interfaces to make it easy to add on programs
>>> like ka9q-web as independent modules. You've already seen how you can
>>> run it on any machine on the same LAN as the ka9q-radio system(s) you
>>> want to control, not necessarily the same system(s) as those running
>>> ka9q-radio itself. I'm really happy John did this.
>>>
>>> This modularity should come in handy when you have a lot of small
>>> standalone boxes (eg., Raspberry Pis) each running ka9q-radio with a
>>> single SDR front end. I personally avoid running more than one copy of
>>> ka9q-radio on a computer because SDR front ends produce a lot of data
>>> that hits the USB subsystem pretty hard. We already have enough USB
>>> problems even with single SDR front ends. Also, I don't like to run
>>> much more than the one copy of ka9q-radio on each system, especially
>>> if the Linux kernel doesn't support real time scheduling.
>>>
>>> Monday night I pushed over some patches to fventuri/ka9q-web that
>>> enable IPv6 on the web service side. This should make it even easier
>>> to access the server remotely through a firewall, without all that
>>> port-forwarding klugery. Assuming of course that both ISPs and all
>>> routers in the path also support IPv6. It can be a pain to set up, but
>>> it's a good investment.
>>>
>>> Re your suggestion to zoom in further, I'm already thinking about
>>> this. It'll take some work, though. Right now, the spectral display is
>>> supported by the "spectrum" pseudo-demodulator inside ka9q-radio. It's
>>> one of 4 demodulator types in ka9q-radio, the others are linear
>>> (CW/SSB/IQ/AM); FM; and WFM (broadcast FM stereo.
>>>
>>> The ka9q-radio demodulators are fed frequency domain signals from a
>>> shared forward FFT. All of them perform an inverse FFT *except* for
>>> "spectrum"; it noncoherently sums up groups of FFT bin energies into
>>> the larger bins passed to the user. The FFT bins are by default 40 Hz
>>> wide, so the user can only request output bins in integer multiples of
>>> 40 Hz. So the closest you can now zoom into a spectrum using ka9q-web
>>> is 40 Hz per horizontal pixel.
>>>
>>> So I'm thinking of implementing another time domain/frequency domain
>>> conversion within the "spectrum" demodulator: convert a segment of the
>>> frequency domain data back to the time domain and then forward again
>>> to the frequency domain with narrower bins. This would require
>>> combining several 20 ms frames and increase latency, but this would
>>> also give me the chance to apply a time domain sampling window to
>>> reduce spectral leakage.
>>>
>>> Right now, while the A/D data fed to the forward FFT is partly
>>> overlapped in time to allow fast convolution, no windowing is applied
>>> in the time domain to keep the sin(f)/f spectral response of each 40
>>> Hz bin from smearing across adjacent bins. (I currently use Kaiser
>>> windowing only in the small IFFTs for the regular demodulators, not
>>> the big forward FFT.)
>>>
>>> This is no problem with a wide spectrum (e.g, 0-32 MHz) since those
>>> sidelobes are small compared to each pixel on your screen, but as you
>>> get down toward 1 bin/pixel you do start to see the sidelobes from the
>>> implicit rectangular (ie., missing) forward time window. This is
>>> obvious in ka9q-web when you zoom in on a strong AM signal with
>>> maximum resolution -- the carrier is noticeably spread out. It's also
>>> hard to see the 100 Hz subcarrier on WWV.
>>>
>>> I can make all this transparent to ka9q-web; the "spectrum" demod will
>>> allow smaller noncoherent bins, and give more accurate results for
>>> bins that are small multiples of 40 Hz.
>>>
>>> Since I'd only do this when zoomed in, the IFFT/second FFT operation
>>> will cover only a fraction of the input spectrum so it shouldn't cost
>>> much CPU. In fact, I have a bigger performance problem now just
>>> rendering a wideband spectrum (eg., 0-32 MHz) in ka9q-web because that
>>> requires summing every 40 Hz FFT bin into a small set of noncoherent
>>> bins for display. That's currently taking about 21% of a single i7
>>> core, almost half as much (50%) as the big forward FFT. Since I can't
>>> avoid that summing operation, I'm going to look into vectorizing it.
>>>
>>> Phil
>>>
>>>
>>>
>> -- 
>> TangerineSDR mailing list
>> TangerineSDR at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org