[TangerineSDR] ka9q-web success

[Phil Karn]

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