Best Content of All Time

  • 30 min disconnection!?!?


    Thank you for illustrating the whole generational stereotype.
    Very funny, made my morning.

    OK here is the real answer:
    These radios are things people have bought themselves, a few hundred dollars of investment initially, then add, buying and putting up antennas, sorting out noise issues even changing what we do around the house to help the radio perform well. Then we share them for people who are interested, want to listen to radio in another location, or who themselves cannot set up such a radio, we don’t get anything back for that other than thinking that perhaps someone has benefited a little.

    If the location is good, and the radio set up well then the limited number of slots is soon used up, it’s not like a streaming radio where numbers are almost unlimited it’s just a few users at any one time and each one takes up a chunk of our internet bandwidth. The way to allow everyone to get a little for testing is to limit connection time, 30 minutes is pretty extreme but you must be looking at a very popular Kiwi (mine is set at eight hours).

    If you come to KiwiSDR with the wrong assumptions it does seem strange, if you realise these are real people trying to help each other for “good will” alone it may make sense, these are not streaming radio services. You may be able to find a less popular Kiwi that also picks up what you are looking to record they may have no time limit or a much longer one than 30 minutes.
  • Early demonstration of "channel nulling"

    Here is a very early demonstration of using the Kiwi's synchronous AM detector (SAM) to subtract one sideband from the other. So a strong on-channel signal that is covering up a weaker one (either on-channel or close by) can be attenuated. This is something I'm tentatively calling "channel nulling". There is much work to be done, but this is at least an existence proof.

    In the first image there is a local powerhouse on 882 kHz and a much weaker carrier on 880 kHz can just be seen in the RF waterfall (green arrow).

    In the second image "null LSB" has been selected from the new menu on the SAM line of the audio tab (bottom right). This puts the SAM detector in "SAL" (synchronous AM LSB) mode such that the USB component is not passed through to the audio. However, just prior to that the USB component is subtracted from the LSB, and, given the sideband symmetry of AM signals, the LSB is effectively nulled (to a varying degree). In the spectrum display above the waterfall you'll note the weak station carrier 2 kHz away now appears above the noise and, sure enough, a Spanish language station can be heard which was impossible previously.

    The "spectrum display" in this case is not the usual spectrum data from the RF waterfall but rather a single-sided spectrum of the audio channel (hence symmetry either side of center). Note that an extension called "FFT" has been selected. This is going to be an expansion of the existing "integrate" extension to include more general audio FFT and spectrum capabilities.

    The RF waterfall doesn't change between these two images because it is from the RF/IF path and not the demodulated/nulled audio.

    This technique is not perfect. Due to the subtraction involved It depends on excellent USB/LSB signal symmetry which can be easily upset by frequency selective fading. A very common problem on shortwave and medium wave at night (at a time when you're most likely to want to use such a feature). But in the presence of fading the nulling effectiveness will vary and it just might give you the chance to "bag a new one" on MW if conditions are right.

    As usual, many thanks to Youssef of AirSpy who recently pioneered this idea. A superior implementation is found in SDR# (the "Co-Channel Canceller" Maybe someday I'll understand how he does it (but probably not, lol).

  • 30 min disconnection!?!?

    Every KiwiSDR owner decides for him/herself how the server is used by visitors like yourself. If you don't like the setup, find a different KiwiSDR. Stop ranting, and move on.
  • v1.352: new time station extension (timecode decoder)

    v1.433 February 12, 2021

      Timecode extension improvements:

        Support for JJY(Japan), RBU(Moscow), RTZ(Irkutsk), BPC(China) added.

        While running AGC delay is temporarily increased to improve noise immunity.

  • Windows KiwiClient & Co

    Hi Paul,

    I am assuming that you have Python installed correctly and already unzipped the kiwiclient package.Depending on how far you got with trying to run kiwirecorder and using Python on your windows machine you can try the following steps.

    1. With explorer go to the directory where you unzipped the kiwiclient repository into.

    2. Check Python is properly installed by opening CMD and typing python or perhaps python3 in your installation. To exit python type in exit()

    3. For the remote kiwi(s) you want to use, have the ip adresses and port numbers ready. 

    4. As example here Shannon Volmet parallel transmission is used on 5505 and 8957 and a kiwi receiver in Finland. Provided the remote Kiwi has 2 slots available it will record both transmissions which then show up in your above mentioned kiwiclient directory. In the CMD window type:

    python -k 30 -s, -p 8073,8073 -f 5505,8957 -m usb -L 200 -H 2700

    Stop the recording after a minute with the CTRL + C keys combination.

    5. Once you got this working, have a look at --help to see what else you want to add, like limiting the recording time, add squelch parameters, append a station name or adding a directory where you want to save those wav files.

    Best regards, Ben

  • KiwiSDR unintentionally shutting down (caused by SW update???)

    Problem Solved!

    last night, I pulled out my multi-meter and oscilloscope to make measurements on the Kiwi.

    The Kiwi is mounted in an aluminium cabinet with no external access to the 5V Kiwi barrel connector, since the cabinet also contains a LM-350 adjustable voltage regulator module, with 5.3V output soldered directly to the 5V barrel connector pins on the Kiwi PCB.

    Using the digital multi-meter, the power input to the Kiwi looked fine, 5.3V and stable.

    Then I connected the the oscilloscope to the 5V input, and noticed that the input voltage to the Kiwi contained very deep voltage drops when vibrating the cabinet and/or touching the power wiring inside the cabinet. Finally I located the problem to a imperfect connection in a PCB screw terminal connector on the voltage regulator board. Fixing the connection and re-checking with the scope to verify solved the problem.

    Lesson learned: Never trust a digital multi-meter alone when investigating problems with power supplies!

    Case closed...

    73 Knut😀

  • External GNSS-disciplined rubidium input?

    I know very little about the TDoA algorithm but I suspect both @jks and @Christoph are correct. Between the limited bandwidth and especially ionospheric propagation, typical Kiwi clock imperfection probably does not become an issue.

    For an appreciation of this, you are welcome to examine the phase of one of NIST's transmitters received via a visual line-of-sight 20km path and displayed on a Kiwi having a ~.1 ppb (1e-10) GPS-disciplined external clock:

    (1) N6GN External Clock WWV15

    and by a different 'stock' GPS-corrected Kiwi at the same distance and also not receiving via the ionosphere:

    (2) N0EMP Kiwi GPS WWV15

    Then have a look at a time/frequency signal via the ionosphere, CHU on 14670 kHz

    (3) N6GN CHU 14670

    or if conditions don't permit, perhaps 7850 kHz

    N6GN CHU 7850

    Whether or not the the phase wander from the standard Kiwi in (2) causes significantly extra error compared to the bandwidth and sample-length restrictions and ionospheric variations would need to be examined more closely but I rather doubt it. Thus, improving the Kiwi's local clock probably wouldn't make much difference in the TDoA accuracy or resolution.

    I think this is the primary reason that long-distance HF standard frequency transmissions tend to be only useful to .1 ppm. 1e-7, or so. Even though as-transmitted error may be 1e-12 the ionospheric path length is varying too much, particularly near the MUF for better accuracy.

  • External GNSS-disciplined rubidium input?

    I agree with @jks. The dominant source of error is ionospheric propagation. In addition, not all KiwiSDRs report their position accurately, i.e., their positions are either put manually by the owners or get rounded in order not to reveal the exact location of a given KiwiSDR.

    Also consider the fact that one sample at 12000 samples/sec corresponds to 25 km, and the bandwidth of most signals on shortwave is less than 12 kHz. So if the bandwidth of a signal is 3 kHz the corresponding pseudo-range resolution is 100 km.

    Having said that, it would be interesting to compare the stability of the KiwiSDR GNSS-derived timestamps w.r.t. ones from a GNSS-disciplined rubidium standard.

  • KiwiSDR production status and availability


    For the record:

    I finally received my 2 units from R&S today.

    Delivered by DHL.

    Ordered July 2020 - Delivered January 2021.

    I am looking forward to getting these up and online soon.


  • Problem with massive RFI after changing router

    A few suggestions, you may have already tried some of them, but here goes... (I assume you have one of those integrated routers/modems)

    Disconnect the coax cable and ethernet cables from the cable company router/modem, unplug the power supply from the AC, make sure the RFI completely goes away, this may sound redundant, but double checking this is really the problem.

    Plug the AC power supply into the wall, but leave it disconnected from the router/modem. Does the RFI re-appear? Is it the same as before? This checks just the PSU for RFI issues.

    Plug the PSU into the router/modem, leave other cables disconnected. What's the RFI like?

    Plug in the coax cable for the router/modem. Again... what's the RFI like?

    Start plugging in ethernet cables (not sure how many computers you have connected). Maybe plug in just one end at a time, first the router end, then the computer end. Note RFI levels. Repeat for any additional cables.

    The point of all this step by step stuff is to figure out what is producing the RFI and (maybe) how it is radiating.

    It is quite possible there is not one step that produces the RFI problems you see, but it is the summation of multiple sources/problems, this lets you figure out what is what.

    At some point in these steps, you may even want to try something as silly as wrapping the PSU and/or modem in a giant sheet of aluminum foil (possibly connected to ground say via a piece of wire with alligator clips). Not permanently of course, but as a test. If that solves the issue, the you can think of a creative way to do that permanently while still providing enough ventilation, etc.

    You can also try grounding various parts of the equipment, such as the router. And also try using shielded ethernet cables, but that only works if the stuff you're plugging the cables into actually has metallic ports. Lots of cheap stuff is all plastic, so there's nothing for the shield to connect to, it just floats, and is useless. If it's at least grounded on one end, that may help.

    Another suggestion... you (generally) do not need to use the cable company's garbage (there are lots of reasons why you SHOULD NOT, beyond RFI). I use my own modem and my own routers. You may want to do the same. It's probably cheaper to buy them yourself than trying to fix an RFI issue with lots of expensive ferrite and other stuff. Plus you won't be paying a monthly rental fee for their junky equipment that is full of security risks :)