Measuring oblique ionograms using KiwiSDRs (1)

Oblique ionogram obtained from a KiwiSDR using GNSS timestamps

How it is done

The receive bandwidth of KiwiSDRs is limited to 12 kHz (20.25 kHz in 3 user channel configuration). In order to synchronously tune to a chirp sounder GNSS-based timestamps are used:

• For the current GNSS timestamp T0 tune the KiwiSDR to the frequency on which the chirp is expected at a time T0+DT.
• Record 10240 IQ samples, corresponding to 20 512-sample long buffers
• Repeat

Timing diagram

In this way, the chirp is always seen at a specific offset. Note that the tuning frequencies are different for each different complete chirp sweep because the KiwiSDR sampling rate is not GNSS-disciplined (the GNSS timestamps are exact).

abs(IQ) vs. frequency

For a chirp rate of 100 kHz/s and sampling rate 12 kHz, the frequency steps are ~85.33 kHz and the group delay resolution is 25 km.

The time offset DT, which depends on the delay between issuing a frequency change command and its effect, is measured at the beginning. It depends on internal KiwiSDR delays and on the network delay. If the KiwiSDR is on a local network this delay is about 2 buffers long, for KiwiSDRs on the internet delays between 8 and 10 buffers were seen.  

Chirp sounder measurements with KiwiSDRs (2)

Using the recent work on KiwiSDR waterfall recording (see kiwiclient/kiwiwfrecorder.py) it becomes possible to search for chirp sounder signals in KiwiSDR waterfall data, continuing the topic from this post.

kiwiwfrecorder.py connects both to the 'SND' and the 'W/F' websocket streams. The 'W/F' stream contains sequence numbers for each waterfall line which are used to synchronize the waterfall to the audio data. These sequence numbers can also be used to attach to each waterfall line a corresponding GNSS time tag obtained from the 'SND' stream. As the waterfall data can arrive before or after the audio data, both are combined in a third thread using python Queues for thread-safe communication.

About half an hour of waterfall data was recorded on the AB1LD KiwiSDR using the highest KiwiSDR waterfall speed which turns out to provide waterfall data about for each SND frame, i.e, each 512/12000 seconds. Thanks to the owner for setting up this KiwiSDR and allowing unrestricted access!.

Then the recorded waterfall data (saved in a .npy formatted file) was rebinned in time to 1024/12000 second bins and exported as a .png file. Switching from python to octave, a search for chirp sounders was performed for chirp rates from 80  kHz/s to 130 kHz/sec in steps of 1 kHz/sec: for each chirp rate and for each start time the content of the waterfall bins was summed up along the corresponding line (Hough transform).

Two chirp sounders were found, each having a repetition rate of 720 seconds (12 minutes) with chirp rates of 82 kHz/sec and 100 kHz/sec, respectively. It might be interesting that this list of chirp sounders contains entries for three chirps sounders with 720 second periods located in Norfolk, VA, Kingsville, TX, and in Puerto Rico.

The plots below show zoomed waterfall diagrams around the chirps and on the bottom panel the result of the chirp search, i.e, the sums of waterfall bins along lines with a given slope.

1^st chirp sounder detected using the AB1LD KiwiSDR

2^nd chirp sounder detected using the AB1LD KiwiSDD

Talk on KiwiSDR TDoA is available on YouTube

This is just a short note that my recent talk on KiwiSDR TDoA at the Software Defined Radio Academy 2019, which took place during the German Ham Convention in Friedrichshafen, Germany, is now available on YouTube.

For other talks from this meeting see http://youtube.sdra.io/.

KiwiSDR IQ data streams with >20.25 kHz bandwidth (5)

By now, gr-kiwisdr can coherently combine between 2 and 6 IQ data streams recorded from the same KiwiSDR.

Following an idea by WA2ZKD, the following test was made with DRM signals: three data streams were recorded, one centered on the DRM signal on 15120 kHz and two more centered on 15112.5 kHz and on 15127.5 kHz which were then coherently combined into a signal data stream. The GNURadio display is shown below:

Coherent combination of two IQ data streams using gr-kiwisdr.

Both, the WAV file centered on 15120 kHz, and the combined WAV file were successfully decoded by DREAM:

DREAM display

The SNR is comparable for both files, taking into account that it fluctuates by about ±0.5 dB:

DREAM waterfall display for the combined WAV file.

DREAM waterfall display for the WAV file recorded on the center frequency.

Only one slight difference was found in the SNR per carrier display: although the SNR per carrier is fluctuating quite a lot, for the combined WAV file there is a dip around the center which is not there for the WAV file recorded on the center frequency:

DREAM SNR per carrier display display for the combined WAV file.

DREAM SNR per carrier display for the WAV file recorded on the center frequency.

KiwiSDR IQ data streams with >20.25 kHz bandwidth (2)

This is a follow-up on the last blog post. Since then a compensation for the roll-off of the CIC filters in the KiwiSDR FPGA has been implemented in v2.162.

The plot below shows the correction w.r.t. normalized frequency for the 12kHz (20.25kHz) modes in blue (magenta). It is interesting that the main component is in both cases sinc(f)^-5 and that the softening of the correction near f=0.5 can be modeled by an exponential function.

KiwiSDR CIC filter compensation

Another improvement w.r.t. before is to use ±4kHz out of the ±6kHz IQ bandwidth in order to avoid alias images from frequencies below and from above, so the GNURadio flow graph looks now like this:

GNURadio flow graph

This flow graph and the code for the KiwiSDR IQ wav file sources and for the stream align block can be found on GitHub (gr-kiwisdr).

In order to verify that the combination of three IQ data streams@8kHz each to an IQ datastream @32kHz does indeed work, two signals were recorded and processed with the above flow graph:

1.  OTHR signal from Cyprus
   
   

   

   Cyprus OTHR on 14370 kHz @IS0KYB

   As is well-known this signal has a bandwidth of 20kHz and uses a FMCW waveform repeating each 0.02 seconds. When plotting the instantaneous frequency vs. time the FMCW sweeps can be see to be perfectly continuous, i.e., both the alignment of the IQ data streams and the PFB synchronizer work as expected.

   

   Cyprus OTHR on 14370 kHz @IS0KYB

   
   
2. CODAR WCNA
   
   The two plots below show a local CODAR signal recorded on a KiwiSDR in Newport, OR. Also in this case the frequency sweeps can be nicely seen. However it is not clear if the second component in the instantaneous frequency having negative slope is due to interference or due to aliasing in the KiwiSDR downconversion processing.
   
   

   

   Local CODAR signal on 4875 kHz @Newport, OR

   

   Local CODAR signal on 4875 kHz @Newport, OR

The IQ streams used above were recorded using kiwirecorder.py with commands similar to the  following:

./kiwirecorder.py -s sibamanna.duckdns.org,sibamanna.duckdns.org,sibamanna.duckdns.org -p 8073 -f 14362,14370,14378 -m iq -g 55 -w -L -4000 -H +4000 --log-level=info --dt-sec=60 --station=IS0KYB