ka7oei

About

Username
ka7oei
Joined
Visits
1,308
Last Active
Roles
Member
Points
2
  • 4 of 5 Kiwis won't stay on the LAN

    Another site visit was made (not by me - it's a 120+km drive each way) - with enough time to take things apart and do a more thorough investigation:

    • Kiwi #2 was found to have low supply voltage: We found that the power cable had been crushed/stretched (but not shorted) and it had rather high resistance: With 5.05 volts at the power supply, there was only 4.35 volts measured at the PCB connector. We ended up removing about half of the power cable for the time-being as we no longer trusted it. I'm guessing that #2 went offline coincidentally a few days before the others, largely for this reason.
    • As per suggestions, we did check the power supplies. Even under start-up load, nothing seemed amiss: The supply for Kiwis 1-3 is a pair of diode-OR'd 3 amp-rated linear supplies (International IHB5-3) and couldn't find anything strange about it (about 4.95 volts at the Kiwi PCB when it's up and running): We were wondering if one of the two supplies had crowbarred - but this wasn't the case. (We have had one of the two supplies crowbar in the past due to lighting and it was still enough to run the three Kiwis as the actual fold-back current of these 3 amp supplies appears to be a bit north of 4 amps).
    • I believe that the power supply for units 4 and 5 is a 4 amp switcher (with lots of added filtering on the AC input and DC output to avoid RFI and a lot of bulk capacitance on the output for impulse loads).
    • Just to be safe - and since it had been a problem child for a long time (even before it was used on the current, dual 3-amp ORed supply) we backed up the newest KiwiSDR (#5) and put the image on KiwiSDR #2, just in case something was amiss.

    The reason for Kiwis 3-5 to do what they did all at the same instant (except for #1) when conditions could not be ascertained to be quantifiably different than in the past when updates were done is unknown - but the reason for #2 is quite clear, now.

    • * *

    On the next "official" site visit (where there are several of us with a carload of gear and parts) I'll bump up the output of at least the dual 3-amp supply to about 5.25 volts - something that has been suggested here before.

    Thanks for everyone who made comments and suggestions.

    73,

    Clint, KA7OEI

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

    73,

    Clint, KA7OEI

    KU4BY
  • 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!
    W9SPY
  • Kiwi BBAI software installation instructions [updated 4-Mar-24]

    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.

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

    73,
    Clint
    KA7OEI
    k5mo
  • Kiwi BBAI software installation instructions [updated 4-Mar-24]

    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.

    Clint
    PowernumptyWA2TP
  • 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;
    else
    {
    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.

    73,
    Clint
    KA7OEI
    benson
  • 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? :)
    ka9q
  • Add an iframe to the KiwiSDR page?

    Another version that will do a similar thing is here:

    image

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

    73,
    Clint
    KA7OEI
    KA7U
  • 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.

    Clint
    KA7OEI
    Powernumpty