n6gn

About

Username
n6gn
Joined
Visits
5,424
Last Active
Roles
Member
Points
31
  • v1.437 From Marco, IS0KYB: AGC threshold bar, Passband overload mute

    I too like it, even if only as a reminder.

    Glenn n6gn

    KA7U
  • 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
  • first fan died... how long do these things last- what other cooling alternatives ?

    @la6lu that made me smile...
    I too had problems with the factory fan and replaced several with Clint's suggestion https://www.alltronics.com//cgi-bin/item/28F082/search/Sunon-5V-Fan-Size--30mm-x-30mm-x-6mm-

    I've now replaced four fans with this alternative but have just recently had to replace one of the alternatives when it too started to get noisy at the remote, poorly climate-conditioned site. It gets both hot and cold at that remote site so maybe this is to be expected. If someone finds an even better substitute or can identify a good maintenance plan for these (change oil every 20k km?) I'd be interested. Maybe this is just going to be part of the cost of keeping a Kiwi running continuously...
    johnk5mo
  • KPH Kiwis down?

    Actually, I think the power has been on the whole time. The issue seems to be a poor quality router that loses its way and no one having access to help it out. There may be plans for a replacement but there is perhaps a little politics in that one. Perhaps Rob may be able to elaborate.
    johnk5mo
  • Running more than one instance ----audio management?

    I just run multiple tabs in a single browser, one tab/kiwi-receiver. That allows separate audio, squelch ... for each of the receivers.

    It's sometimes useful to do this on kiwis that differently located and experience varying and different propagation. One can pick the best, even run squelch and let the best one win. There can be a differential delay problem but that can be dealt with.

    Paul_dbnut
  • Rounded Frequency Set

    I'm finding that "it works sometimes". I managed to get it not work, QSYed to a ham band where it worked, fussed around after which it quit. Maybe someone else can figure out the conditions for (non)working.
    Zyg
  • 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
  • Kiwi phase/frequency stability & Ebnaut decoding

    @HB9TMC
    I haven't documented the kiwiSDR onboard GPS performance but I have examined it, particularly in comparison to use of the Kiwi with an external clock. You can do the same by comparing two of my kiwis, one with a Bodnar GPSDO which generally appears to be better than 1 ppb and to not limit the phase noise performance of the kiwi with another using the on-board GPS reference.
    Bodnar referenced Kiwi
    and
    on-board kiwi GPS
    are both looking at US NIST LOS/"groundwave" signals transmitted from less than 20 km distant.
    This may not be entirely satisfactory since the on-board kiwi's GPS antenna is outdoors but not very well located.
    HB9TMC
  • Suggestion, a change to the auto scaling in waterfall, to add 5 to the min result

    I think many of us find the low end not dark enough and routinely adjust it to dark blue. jks has mentioned this too, I think.
    WA2ZKD
  • W/F and SND Bad Params

    In a kiwi itself rather than my router, after trying it with FORWARD, I ran:
    iptables -I INPUT -s 47.88.219.24/24 -j DROP
    iptables -I INPUT -s 184.22.160.13/24 -j DROP
    since I'm trying to stop packets from two different offenders at the kiwi rather than from being forwarded by the router. This I followed with:

    iptables-save

    so that it will (I hope) get restored upon reboot. Examining the results I get:

    root@kiwisdr:~# iptables -L
    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    DROP all -- 184-22-160-0.24.nat.tls1a-cgn02.myaisfibre.com/24 anywhere
    DROP all -- 47.88.219.0/24 anywhere

    Chain FORWARD (policy ACCEPT)
    target prot opt source destination
    DROP all -- 184-22-160-0.24.nat.tls1a-cgn02.myaisfibre.com/24 anywhere
    DROP all -- 47.88.219.0/24 anywhere

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination

    I'm not familiar enough with iptables yet to know if this will be sufficient, perhaps only the INPUT rule is needed. Maybe someone who knows can suggest whether this is correct or whether there's a better way.
    VK3KHZ