The KiwiSDR 2 online store is open for orders! Please visit kiwisdr.nz

n6gn

About

Username
n6gn
Joined
Visits
4,511
Last Active
Roles
Member
Points
18
  • Flatness of KiwiSDR response < 500 kHz?

    Phil,

    Addressing your noise issues and not the spectral display, I would encourage you not to immediately jump to whack-a-mole in seeking to improve Kiwi Performance. Rather, I have found it very productive to examine the coupling mechanism rather than simply trying to stay on top of suppressing interference sources.

    For electrically small structures, which almost everything at LF and below is, the radiation resistance is minuscule. For virtually all situations we encounter actual inverse-square radiation from any sources/antennas is far below the interference levels the Kiwi reports. Thus I think it worthwhile to look at near-field and, particularly common mode (CM) coupling mechanisms.

    In my experience, the dominant undesired coupling mechanism into the Kiwi is CM current over the path between wired LAN connection and the SMA-end of the Kiwi PCB. This includes the BB ground plane, cape connections and ground plane current paths on the Kiwi PCB. If one uses an isolated source having low self-capacitance (and then perhaps further reduces the potential for CM with a low inter-turn capacitance 1:1 transformer to create a test current source), -10 dBm on 15 MHz injected between the BB RJ45 shell and the Kiwi Antenna SMA results in about -85 dBm displayed on the Kiwi. This is more than 70 dB above the Kiwi noise floor in 1 Hz. At 100 kHz it's only down another 22 dB or so, still far above what the Kiwi can easily detect. It's for this reason that for each of my four Kiwis at the home QTH I have gone to WiFi interface, BBG/Kiwi's as described elsewhere on this forum and BBAIs with their native WiFi interface.

    At LF, the noise floor of interest will depend upon the antenna system. Broadband electrically small antennas (they all are at LF and below) have antenna factors rising at 20 dB/decade while the ITU propagated noise, though all over the map with diurnal and seasonal variations, generally falls at about 25 dB/decade of frequency. Thus the noise limit of interest may be quite a bit above the Kiwi's native floor of ~ -157 dB/1-Hz but it still may be well below the kinds of levels that CM current injected via the LAN, PS or even GPS lines might be able to produce within the Kiwi.

    For the Kiwi, and really every receive system we use "ground isn't ground" except by definition. But care in examining coupling mechanisms, reducing current in CM paths and symmetry (passive and active baluns) can really pay off and gains made here tend to apply no matter what new SMPS or other noise source pops up in the environs.

    As a proof-of-performance it's also very useful to use symmetric antenna structures rather than single ended ones, e.g. monopoles, because the intended antenna, e.g. dipole, can be shorted to observe and confirm that the residue CM is not significantly limiting system performance. Considering the many-10s of dB of symmetry/CM_rejection we may need broadband RF baluns really are insufficient over the 3-4 decades the Kiwi covers.

    When CM has been removed, there can still be the issue of near-field coupling to deal with, but I digress...


    Glenn n6gn

    dl7awlHB9TMCka9q
  • Power-over-USB modifications for a KiwiSDR

    I'm attaching a write-up of what has worked well for me to improve Kiwi noise performance by reducing common-mode current paths through the Kiwi.

    For a stock, wired-LAN Kiwi it is very common for noise and coherent signal current on the LAN cable to find a path through the Kiwi PCB ground and out either the Power Supply return or, more often, via common mode current on the antenna feed attached to the SMA input. This kind of QRM/QRN is insidious because it may mostly show up when an antenna is attached causing the user to believe the problem is elsewhere.

    By operating the Kiwi with an inexpensive WiFi router, powered from the Kiwi and connected by only a single micro_USB <==> USB-A cable, the common mode current paths which can cause this degradation can be eliminated.

    Because of the success of this scheme in both improving performance of previously wired-LAN installations and also the possibility of building a completely isolated, portable Kiwi system to use as adiagnostic tool for improving Kiwi and general site performance, I'm offering this description.

    Write me for more information or for the 3D printable file for the USB clamp described.


    Glenn n6gn


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

    Avamandercathalferris
  • Power line noise ?

    The family of lines in 6.5-7 MHz you suggest seem to me to be power line related, though this is true of many SMPS noise sources. When I detect in 10 kHz AM and analyze with Audacity I see astrong 50 Hz family/component

    This is as expected from an imperfectly filtered SMPS input. Furthermore, the spectral width of the lines is consistent with jitter/phase noise of a switcher's rate and it appears to have stronger even harmonic components, as is common from full-wave rectification.

    But as to the actual source and coupling mechanism - that's harder to say. There are so many uses for SMPS supplies these days, some of them for lighting related power that an after-dark correlation is not unlikely.

    To put things in perspective, while your noise floor is no doubt raised considerably by this, you are in pretty good company and a lot kiwiSDRs reveal similar and worse results. If you are using a well matched antenna, your noise is about 30 dB above kTB which isn't so dreadful at that frequency. OTOH, it may be higher than that if your system is not well matched to the radiation resistance. You could be seeing CM currents, current in the earth below or other coupling mechanisms. I suggest not first considering it to be inverse-square radiation. That is actually much rarer, in my experience.

    Glenn n6gn

    o00scorpion00o
  • KiwiSDR unable to login with SDR.HU [caused by new Comcast/Xfinity "advanced security" feature]

    FWIW, I had very similar symptoms when Comcast/Xfinity (US cable ISP) changed to a new on-line administration tool for my router. They 'kindly' added something that must be akin to an iptables entry at their gateway which flagged all the kiwi traffic as 'malicious' or a threat and blocked it. I got the same error as you. This seemed to come and go, per some algorithm that I couldn't discern. After several hours on the phone (with someone in the Phillipines) I found the sub-menu on the web site which let me revert the security settings to avoid them shutting down access.

    I don't know if this is related to your cause or not, but I thought it might be helpful.

    Glenn n6gn
    Brendan_W