Last Active
  • Remote Battery Voltage Monitoring

    Although intended for monitoring mains voltage, I did a somewhat similar thing using the ESP8266, described here:

    The source code is linked, and making it read supply voltage rather than mains voltage would be trivial. The '8266 has only a single A/D input, but the addition of a simple analog MUX chip like the 4051 would easily expand this to 8 inputs - although one would probably want to level-convert the MUX drive to 5 volt logic (e.g. an NPN and two diodes).

    * * *

    If a network connection isn't in the cards (the ESP8266 has 2.4 GHz WiFi only) this also includes a Morse beacon that telemeters the information - in this case, on 10 meters: This was added so that telemetry could be seen by anyone interested, but also so that we could still receive it should the WiFi connection drop for some reason.

    * * *

    Finally, the same, basic low-power TX could be driven by a PIC or Arduino, of course to produce Morse telemetry.

    To get back to an aspect of your question: I suppose that a BBG GPIO pin with an A/D input would be available, but I chose to leave the KiwiSDR unit unmodified - both for practical reasons (a spare could be swapped out) and also to avoid the possibility of conducting undesired signals in/out of the chassis (e.g. static, RFI, lightning, etc.)


    Clint, KA7OEI

  • Problem with massive RFI after changing router

    I have seen several situations where the "old" router/switch was replaced with one that happened to support POE (Power Over Ethernet) - and the world of MW/HF/SW reception ended at that point.

    In all cases where I was involved, that new, noisy device had to be (for all practical purposes) scrapped as no amount of CM filtering seemed to be able to return the noise floor to its previous level - although placing a cheap, name-brand, non-POE switch immediately after it and running all cables through it, instead, may be able to break things up sufficiently: This was used as a stop-gap/diagnostic measure rather than a permanent solution. For those instances where a POE device had to be used (a wireless access point, a camera, etc.) a bit of flailing around had to be done to either find a "quieter" POE switch or to simply apply the POE supply at the far end, near as possible to the device being powered to avoid the LAN cable being an antenna.

    It may be that the (rather expensive) DX Engineering Ethernet isolators may do the trick - but they are damn expensive (about $50 each) for a pair of bog-standard Ethernet PHY magnetics simply wired back-to-back: An example of "What the market will bear", I guess...

    * * *

    While standard Ethernet is, by definition, a balanced transmission system with a good CM ratio, in most cases the "P" part of POE is not balanced at all - often connected to the butt-end of a noisy-@$$ switch-mode power supply via filtering that may, if the device is reputable, just barely meet Part 15 conducted noise standards on each individual cable. As we all know, however, Part 15 (even the more strict "Subpart B" for home devices) is nowhere clean enough to preserve the LF/HF or even VHF bands if a fairly low noise floor is to be maintained - and this is even less-so when multiple conductors emerge from the switch, acting as several, independent antennas, running around the house, spreading the joys of QRM far and wide.

    In the cases where the router/switch was involved, I have generally found that the use of a cheap, no-name Chinese device, in terms of HF reception - at least without taking extraordinary measures to quash noise - means that you will be doomed: I have seen "20 over" noise from these devices on multiple bands which, assuming a standard 6 dB/S unit calibration factor, implies that 40-50 dB increase from the original noise floor - and I only wish that this were an exaggeration.

    If you are *really* lucky, it may be the unit's power supply that is the main culprit - but it's often the case that most people aren't able to swap such things out to determine if it's the cause. The good news is that such a power supply will probably fail after 12-24 months, anyway!

    A better-known name (Belkin, SMC, D-Link, etc.) that does *NOT* support POE is more likely not to be a spread-spectrum transmitter in its own right.

    Good luck!
  • Kiwi BBAI software Alpha test instructions

    I have one of the Newark fan capes and at nominal room temperature (70F) it is barely capable of keeping the CPU at an acceptable temperature when it's running at 1.5 Gig.

    The main problem with it - like many similar fans - is that it just can't push the warm air away from the vicinity of the heat producing devices. Adding some additional headers (Adafruit) to add more spacing between the fan and the Kiwi helped a bit, but more help is needed in the form of even a modest fan pulling in "outside" air and pushing it past, between the boards.

  • first fan died... how long do these things last- what other cooling alternatives ?

    I have four KiwiSDRs that I maintain and I had a 100% failure rate after 9-12 months of the fans supplied with the case: Three of these Kiwis were operating in a harsh environment (below freezing to >130F/54C) and one was not: The one in the temperature-controlled room did not last any longer than the other three - but beware statistics with n=1!

    In a posting about this same issue here a year or so ago I specified a cost-effective, good quality, known-brand ball-bearing alternate from a surplus source that I and others have used - in this case, the forum's search will probably be your friend.

  • Kiwi BBAI software Alpha test instructions

    I have one of the Newark fan capes and at nominal room temperature (70F) it is barely capable of keeping the CPU at an acceptable temperature when it's running at 1.5 Gig.

    The main problem with it - like many similar fans - is that it just can't push the warm air away from the vicinity of the heat producing devices. Adding some additional headers (Adafruit) to add more spacing between the fan and the Kiwi helped a bit, but more help is needed in the form of even a modest fan pulling in "outside" air and pushing it past, between the boards.

  • Suggestion for minor UI tweaks

    Hi JKS,

    While I could likely use GitHub for this, I would like to suggest some minor UI tweaks for the KiwiSDR - these, based on my experience coding for the mcHF transceiver - and posting it here may be instructive to others who are using similar code - and to explain the "why" of the following aspects of the KiwiSDR UI.

    Volume control.

    It seems that the current implementation of the volume control on the UI is linear whereas we (humans) are not. This means that almost all of the useful volume range occurs in the first several steps while the majority of the adjustment range does nothing. - I suggest logarithmic scaling of the amplitude multiplier value, as in this pseudocode example:

    // Volume slider input range 0-20

    if(volume == 0) audio_mult = 0;
    audio_mult = Math.pow(10, (volume-20) / 10); // "audio_mult" ranges from 0.012589 to 1 corresponding to 38dB to 0dB attenuation

    // "audio_mult" is the value that is used to scale the amplitude of the audio stream via multiplication.

    * * *

    Similarly, several of the LMS parameters are particularly ill-suited for straight-line linear adjustment making it impossible to produce generally-usable filters - specifically, the beta and decay parameters:

    beta: The useful range is likely from about 0.00001 to 0.2
    decay: The useful range is probably about 0.9-0.999999

    - Pseudocode example for the LMS beta value using a slider that has a range of 0-100:

    beta_val = Math.pow(10, (beta_slider/23.25))/100000; // Resulting range is approx. 0.00001 to 0.2

    - Pseudocode example for the LMS decay value, using a slider that has a range of 0-100:

    decay_val = 1 - Math.pow(10, ((-1) - (decay_slider/20))); // Resulting range is 0.9-0.999999

    * * *

    Thanks for everything that you do.

  • DRM Heard

    Phil, isn't it really weird that no-one is using Mr. Walker's wonderful VMSK modulation on the shortwave or other bands these days? I wonder why that is? :)
  • Add an iframe to the KiwiSDR page?

    Another version that will do a similar thing is here:


    Unlike KA7U's version, this will fill the entire screen, no matter the users' browser/computer capabilities, and the vast majority of users will not be aware that there is a frame. As suggested, this cannot readily run on the Kiwi itself without some modification.

    At the Northern Utah WebSDR we have set up a common "landing page" at a web hosting service (Dreamhost) to which all users are initially directed. Because we may have to change the IP address/hostname in the future, users would use one, common URL to get to the servers - no matter what the actual URL of the server in question might be in the future (e.g. we'd need only change it on the directing page and users would probably not ever notice the change).

  • wsprdaemon noise graphs

    In the past I have checked the calibration of the noise graphs by placing a CW carrier of known amplitude within the WSPR passband. It's been a while, so I don't recall the details, but I do know that a persisting CW carrier can have a similar effect.

  • Advice on sharing RX antennas with 3 SDRs in the most effective way

    It's worth mentioning that at a quiet location, even a KiwiSDR connected directly to a (nominally) unity-gain antenna is not quite sensitive enough to hear the IRU-defined noise floor - much less if it is split several ways. What this means is that unless some rather rugged amplification is included in the signal path, the KiwiSDR will not be able to hear signals near the thermal noise floor on the higher bands - say, >=20 MHz or so.

    If your location is rather noisy to begin with, then there is no need to do through this trouble: This can be determined by tuning in a "blank" spot on 10 meters and observing the S-meter reading with and without (preferably substituting the antenna with a 50 ohm load) and seeing if there is an obvious difference - at least a couple dB, consistently higher with the antenna connected. If there is no obvious difference, your receive system is "gain starved".

    I have found that with the Kiwis at the Northern Utah WebSDR - with an antenna that is essentially "flat" from 3-30 MHz (around 6dBi peak across this range), split four ways, around 20-ish dB cumulative signal gain is required to assure that the KiwiSDR can reliably "see" the thermal noise floor on 12-10 meters at this fairly quiet site - but there's a caveat to this: If you put this much gain in front of the KiwiSDR "naked", you will overload it on lower-frequency signals - that is, those below 12 MHz or so - when the bands open at night - and the receiver will overload badly, much of the "A/D" capacity being spent on a couple dozen strong signals at the expense of everything else.

    For this reason, several in this group have devised "limited attenuation high-pass filters" where those lower-frequency signals are attenuated by a certain amount - something in the 10-20dB range: Enough to knock those very strong signals down significantly, but not enough to put the receiver below the (increasing inversely with frequency) natural noise floor.

    You may peruse that thread here: http://forum.kiwisdr.com/discussion/comment/4490#Comment_4490

    This allows amplification of the signals across the HF spectrum of a sufficient degree while considering the dynamics of those signals - and the dynamics of the KiwiSDR's A/D as well.

    In the current configuration at the Northern Utah WebSDR, the signal path is along the lines of:

    HF Antenna -> Lightning Protection -> 2-way splitter (the KiwiSDRs are on one of these branches) -> Adjustable AM-reject filter network -> High-dynamic range 14dB RF amplifier -> 2-way splitter -> Limited attenuation high-pass filter for Kiwis -> High-dyanamic range 14dB RF amplifier -> HF+LF Combiner -> 4-way splitter -> KiwiSDRs

    A (slightly outdated) block diagram and more information about that signal path may be found here: http://utahsdr.org/info/rx_rf_distribution.html

    The amplifier is described on this page: http://utahsdr.org/info/rx_softrock.html (See Figure 3 on this page and the other, similar amplifiers embedded in the diagrams of the other receivers.)

    Note that the system at this WebSDR has been designed to use both narrowband "softrock" and wideband direct-sampling receivers, hence the two complete signal paths. The rationale for this was to "future-proof" the system: The narrow-band "softrock" receivers are still the best way to inexpensively get high performance, but the "wideband" receivers (KiwiSDRs) are still not suitable for many dozens of users - and the combination of affordable, very high performance hardware and the software for sharing many users on wideband receiver hardware is still a little ways off - but we expect it to be available in the next couple of years.