jks

Here's an example of all sats being available on all channels on a Kiwi in Iceland. As a bonus QZSS is being received (!) The signal is weak and only 9 degrees above the horizon. It only participated in this one GPS solution before sync was lost. But it was there!

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

Wait unit after today's v1.213 update. There is a significant bug fixed.

Well, there was definitely a bug. Bjarne your Kiwi has the fix. Everyone else will get it in the update tomorrow.

The bug was timing sensitive which explains why it didn't occur consistently. Still, I'm very surprised this was only noticed recently by you and by Martin yesterday. The bug has been there for like a year now or something.

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.