jks

Endlessly amusing that every time HF is declared dead some new application emerges.

I think the answer here is that when "user preferences" are finally working the very first parameter needs to be "what would you like the tuning point to be?" (carrier or passband center or even something else).

User preferences is like the admin configuration but for Kiwi users. Any user. Not just users who also own a Kiwi. The idea is that you should be able to set a preference once and then have it apply to any Kiwi you visit in the future. This is unlike the "last remembered" values (frequency, mode etc.) saved in cookies that are specific to the current Kiwi you're using. I don't want to keep having to set the carrier point preference the first time I visit a new Kiwi.

User preferences is taking so long because it's tricky to implement. You have to side-step some browser security problems that upset getting the behavior you want (single storage applied to multiple domains).

It is instructive to look at the "dt" result plots to try and understand the quality of the correlations. Also in "old map" mode the individual station-pair maps show in the top legend the RMS dt value of the timings. A good value is < 15 us and that will be reflected by a dt plot that is all red with a dark red vertical line in the center indicating a correlation coefficient close to one (also the 'x's will be lined up nicely). Your maps will have the contours and red/green heat map overlays packed closely together and not spread out over large areas.

Often you will see RMS dt values > 100 us and dt plots with blue through green colors and the 'x's all over the place. And I think this means multi-path is having an effect.

No. Read the design document re the "acquisition time" problem: https://www.dropbox.com/s/dl/i1bjyp1acghnc16/KiwiSDR.design.review.pdf

Most people don't seem to realize that what the Kiwi implements is pretty close to what a spectrum analyzer does. The large buffers of each "waterfall" DDC channel can fill in a few microseconds or hundreds of milliseconds depending on what zoom level each connected user has chosen. That can change in an instant. So any sort of multiplexing becomes very difficult, if not impossible, to schedule. Things might be different if the FFT was done on the FPGA, but it isn't currently. It probably would have taken me an extra year to figure that out (fixed-point FFTs are tricky) and the FFT may not even have fit into the FPGA.

That's why Twente WebSDR is such a beautiful thing. A US $1000 GPU card just blasting away doing a 2 million point FFT in realtime supporting >400 simultaneous users. But you wouldn't be very happy if the Kiwi cost that much..

Nils, DK8OK, has an absolutely wonderful writeup about practical issues in using the TDoA service on his blog. A 22-page PDF full of optimized HFDF results. https://dk8ok.org/2018/07/25/direction-finding-first-experiences

Obligatory: https://en.wikipedia.org/wiki/No_good_deed_goes_unpunished

Today's v1.213 update has a "no_wf" URL param, e.g. "my_kiwi:8073/?ext=wspr,40m&mute&no_wf". On an empty RX8WF2 mode Kiwi this would give you rx2 instead of rx0.

This might be improved somewhat once the audio FFT for channels rx2-rx7 is working.

No.

Yeah, see that annoys me greatly. I don't want all the Kiwis on the planet to get bricked someday because I'm dead and the certificate has expired. I don't want Kiwis to have some dependency on an external site that keeps them from working. It's bad enough we depend on Google for timezone lookup and various sites for geolocation lookup. There's the proxy and TDoA service issues, but at least they're optional.

So this is only an issue when TDoA is done using sampling Kiwis running a mix of v1.212 and earlier versions (e.g. v1.211) That means this problem will get better over the next 24 hours as more Kiwis update to v1.212

I could add a URL option that implements your second idea. Giving you one of the channels normally handed out to a non-Kiwi UI connection.

A few notes:

• It seems to work, but this is a big change. So it is likely there will be some problems. Consider it a beta test.
  
• The first time you switch to the 8 channel configuration the TDoA channel limit will still be set at 4 (or less). So re-adjust it accordingly.
  
• Having eight simultaneous connections has been tested and seems to work fine. This includes connections via the external kiwirecorder software.
  
• It is not clear how well running 8 WSPR extension sessions would fare. There would likely be a serious shortage of Beagle CPU cycles causing the decoding process to run out of time on busy bands. Rob, AI6VN, has already demonstrated a superior solution using a script to connect multiple Kiwi channels via kiwirecorder to separate instances of WSPR-X running on better hardware. The RX8WF2 configuration was developed primarily to make the Kiwi more efficient for Rob's WSPR projects as well as helping to increase the pool of TDoA channels.
  
• Speaking of TDoA, we'll probably have to get buy-in from individual Kiwi owner/admins to have them change from RX4WF4 to RX8WF2 mode. Not everyone will want to do this and it probably makes sense to have a mix of configurations available publicly.
  
• The audio FFT replacing the waterfall/spectrum will be similar to the existing "audio integration" extension. Essentially a 1024-point FFT on the fixed 12 kHz audio passband.