Best Helpful Content

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

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

  • 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 :)
  • Problem with massive RFI after changing router

    Changing the external SMPS is fine. But there is another issue that is more difficult to deal with. The use of internal DC-to-DC converters (that are also SMPS) directly on the PCB of the device.

    These days it seems a lot more devices, including PC motherboards, are powered with higher voltage from the primary supply. Then high-efficiency "point of load" DC-to-DC converters are used right at the consuming load. In the case of your router the external SMPS is now 12V instead of 5V and there is almost certainly a 12V-to-3.3V (or even less) converter internally (chips don't run on 5V these days and in many cases don't run on 3.3V either except maybe for I/O).