jks

Your IQ balance is almost certainly off as a result of pushing the "IQ bal" button in the IQ display extension when not tuned to a quiet part of the spectrum (or having the antenna disconnected). There is a topic explaining all this: http://forum.kiwisdr.com/discussion/699/why-a-beat-in-am-incorrect-iq-offset/p1

Easiest way to confirm this is to check the beginning messages in the log tab on the admin page. You should see numbers for the I and Q balance that are either the default (-0.02) or roughly the same. Example:

Thu Jun 18 15:46:49 00:00:32.361 ....      using DC_offsets: I -0.020000 Q -0.020000

Below shows progress with an experiment to get a 14-channel configuration working using a BeagleBone AI. The challenge is to move as much processing to the second cpu core of the AI as possible so as not to impact the realtime requirements of serving the 14 audio channels (plus the usual 12-channel GPS etc.) It seems to work. A 14 audio DDC + 1 waterfall DDC configuration (rx14_wf1) was made to fit in the FPGA (LUTs now 97% full) by reducing the amount of CIC filtering logic slightly.

Note below that the processor temperature and clock speed are displayed. The cores are currently running at rate automatically adjusted based on temperature between 1.0 - 1.5 GHz due to the reduced cooling configuration I'm testing.



The Kiwi's internal WSPR extension is running on all 14 channels as a worst-case test since WSPR decoding is so cpu intensive. The fact that this works does not change the fact that Rob's wsprdaemon is the superior solution for anything but casual WSPR monitoring. In fact 14 channels was chosen in support of getting a single Kiwi to work in an all-band wsprdaemon setup.

Below is output from the Linux "ht" command. It shows how certain components of the software have been moved to new Linux processes separate from the main Kiwi process and "locked" to the second core of the processor. "kiwid" is the main process and is locked to cpu0 as seen in the "cpu" column. The other "kiwi.xxx" processes are locked to cpu1. Of interest here is the "kiwi.wsp" process which runs the collective WSPR decoding of all 14 channels.



This is just a progress report. There is a long list of work to do.

Time remaining (if any) appears in orange in the "users" tab of the main control panel as "h:mm:ss" counting down towards zero. The suffix is "act" if the limit is on activity per connection and "24h" if the limit is per 24-hour period. The time in white preceding is how long you've been connected and counts up.

Time remaining (if any) appears in orange in the "users" tab of the main control panel as "h:mm:ss" counting down towards zero. The suffix is "act" if the limit is on activity per connection and "24h" if the limit is per 24-hour period. The time in white preceding is how long you've been connected and counts up.

The S-meter code is literally:

s_meter_power = I*I + Q*Q
s_meter_dBm = 10.0 * log10(s_meter_power / SND_MAX_VAL)
s_meter_value = an_averaging_function(s_meter_dBm)

Where I and Q are the two quadrature components (complex number) of the audio signal after passband filtering. So it contains all the data you see (and hear) within the yellow passband area on the waterfall, except that the actual data is coming from the audio path not the waterfall path. So it doesn't have anything to do with the spec plot. The spec plot is just the waterfall data plotted in a non-scrolling way (as a 2D graph).

It's easy to forget because they both typically tune together. But the audio and waterfall are two entirely independent DDC (digital down conversion) receivers. You can re-tune the waterfall to go look at a completely different part of the spectrum without effecting the currently received audio. So a "4-channel" Kiwi is actually an 8-channel DDC SDR. This is why the unbalanced FPGA configurations are possible, i.e. rx8_wf2. The lack of waterfall on the other 6 audio channels is made up for by the audio FFT computed on the browser basically for free.

The S-meter code is literally:

s_meter_power = I*I + Q*Q
s_meter_dBm = 10.0 * log10(s_meter_power / SND_MAX_VAL)
s_meter_value = an_averaging_function(s_meter_dBm)

Where I and Q are the two quadrature components (complex number) of the audio signal after passband filtering. So it contains all the data you see (and hear) within the yellow passband area on the waterfall, except that the actual data is coming from the audio path not the waterfall path. So it doesn't have anything to do with the spec plot. The spec plot is just the waterfall data plotted in a non-scrolling way (as a 2D graph).

It's easy to forget because they both typically tune together. But the audio and waterfall are two entirely independent DDC (digital down conversion) receivers. You can re-tune the waterfall to go look at a completely different part of the spectrum without effecting the currently received audio. So a "4-channel" Kiwi is actually an 8-channel DDC SDR. This is why the unbalanced FPGA configurations are possible, i.e. rx8_wf2. The lack of waterfall on the other 6 audio channels is made up for by the audio FFT computed on the browser basically for free.

I didn't have time yesterday to elaborate. The answer is no because to work at all in the real-time Kiwi environment the FFT's in the WSPR algorithm had to be spread across the two minute sampling interval so as not to load the Beagle cpu too much. But this means the required data is not available at the right time to perform the two-pass algorithm where the entire result must spectrally subtracted and the decode performed again. One possibility is to recode the algorithm again from being the standard WSPR 2 minute pipeline delay to a 4 minute pipeline. It could be done but you'd have to rewrite everything completely. There would be an extra delay in reporting results to wsprnet.org but that shouldn't matter.

Another possibility is for multicore architectures to use the original WSPR algorithm, 2nd pass and all, but force it to run on cores other than zero so as not to disturb Kiwi realtime. This is probably easier, but still a lot of work.

The devil is always in the details. Particularly with this project.

Debugging aids for me. Push "dump" and see what you get in the log. "Clear histogram" followed by "dump" is a little more subtle.

So there has been significant port scanning of kiwisdr.com recently. For example, over the last 24 hours 173 thousand scan requests were made by a single ip address from China. Also from a Digital Ocean server farm in the USA.

Some of these scans occur on the proxy ports. If the URL or packet data is particularly pathological it might trigger bugs in the proxy server code (e.g. buffer overruns). This could explain the looping and crash/restart behavior we've seen in the last several days.

Rather than try and debug the proxy code (which we didn't write), and cause significant additional proxy downtime, it was easier to strengthen our existing firewall filtering rules. Port scanning is now more reliably detected and the associated ip addresses banned.

We will closely monitor the situation and see how effective the new rules are.

The proxy service is having serious problems. There is some evidence that it is under attack, but this is not yet confirmed.