[TangerineSDR] ka9q-web success

[John Melton]

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