jks

It does this already (if I'm understanding your question correctly -- morning coffee hasn't taken hold yet).

Before you start the process single-click on a reference station so its information is copied into the field at the lower left of the TDoA control panel. Or optionally type your own reference info, format: lat lon id description. Then the result maps will show that info in a marker in addition to the "most likely" position computed. Also, if you're specifying everything from the URL, you can just list the reference station id to have it pre-selected. Just like the Kiwis to use are specified. See below. Using the Google map ruler we can see the difference in computed to actual location is a bit over 20 km.

I'm a couple days into getting each GPS channel to allow all satellite types. Very difficult (for me at least) as expected. The old inefficient way would have required 12 memory blocks and we only have 5 available (4RX4WF config). The new scheme requires only 3. But I had to learn some new Verilog and employ some tricky sequential/producer, parallel/consumer logic with pipelining issues thrown in. It isn't working yet..

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