jks

About

Username
jks
Joined
Visits
29,756
Last Active
Roles
Member, Administrator, Moderator
Points
203

Reactions

508Helpful462Awesome

  • static ip does not change

    jksjks
    Yeah, those fancy "state-full" deep packet inspection routers must be a headache. Especially when they do the wrong thing on traffic you want to get through. Fortunately I've never had to deal with them.

    WA2ZKD

  • release v1.45: improvements to WSPR and no more upload to wsprnet.org?

    jksjks
    That's probably more of a question for the official WSPR group: http://wsprnet.org/drupal/
    My impression is that they take all loggings seriously and some people even do analysis on the database (which goes back to 2008!)

    There is an open feature request to allow the WSPR extension to be started automatically and run unattended (no browser connection necessary) which is in the spirit of collecting lots of spots.

    WA2ZKD

  • Blue Light Flash [power cable voltage drop]

    jksjks
    Okay, but if you put more than 5v into it the outcome is uncertain. If the Beagle alone comes up using a 5v supply then you probably didn't fry it. Did you mean 6 and 12 WATT 5 volt supplies? The 5v input on the Kiwi goes though the headers into the Beagle for power management before coming back to the Kiwi. So hopefully the worst that can happen from any over-voltage is you have a dead Beagle.

    I can tell you what's probably wrong because this identical issue happened to me recently: the cable between your power supply and Kiwi has too much voltage drop because the wire gauge isn't large enough (or it's something besides decent copper). I sent a BBG + Kiwi to a guy here in NZ recently. He asked if I could include a USB/A-to-2.1mm adapter cable. I didn't have any, but I found some on the web and had one drop shipped to him and some sent to me.

    He had the same problem as you. Except that the Beagle power LED didn't even flash when the Kiwi board was installed. But with the Kiwi removed, and the BBG powered through its micro-USB input, the Beagle alone worked fine. So dead Kiwi board, right? He sent the whole thing back to me. I plugged it in to my standard 5v supplies and everything worked fine! I tried the adapter cable and NADA. Even though power at the Kiwi measured 5 volts!

    Using a BBB (not BBG) which has a 2.1mm input connector like the Kiwi I noticed this: With a multimeter at the BBB input connector it would briefly drop from 5v to 4v when power was applied and the Beagle's power management IC (PMIC) tried to startup. Then it would jump back to 5v because the PMIC rejected the 4v input and stopped drawing current.

    So this probably explains your situation. With the Beagle alone drawing 300 - 400 mA your cable must not drop below 4.75v which is about the PMIC lower limit. But with the Kiwi board the 1000+ mA draw is too much and the PMIC refuses to startup. But it's enough that the power LED still manages to flash.

    paulj

  • USB Max BW

    jksjks
    I need to add this question to the FAQ. But basically the current bandwidth (9.6 kHz) times the number of channels maxes out a number of different resources (FPGA memory, SPI bandwidth, Beagle processing power, audio lag etc.) You could increase it to 50 kHz but then you'd probably only get one channel instead of 4. The Kiwi is a very careful balance between cost, performance and capability.

    Now it's always possible that more clever programming and FPGA firmware could do a better job. Just yesterday I was experimenting with a change to reduce the FPGA memory used by the waterfall(s) by 25% since that is the biggest consumer of FPGA memory blocks. It worked, but raised the noise floor to an unacceptable degree. It took me a while to understand why.


    WA2ZKD

  • KiwiSDR boot-up - problems?

    jksjks
    It's very difficult to tell, but my first guess is a power supply that isn't supplying sufficient current. If the voltage sags below about 4.7V the power controller on the Beagle will shutdown. That's why the single power LED on the opposite side of the Ethernet connector from the 4 status LEDs goes dark.

    The other thing to try is a re-install of the software from the supplied micro-SD card as discussed above.

    Harri

  • Warning: possible Forum malware

    jksjks
    We've had several reports of people seeing this pop-up appear asking you to download software. Please don't click on anything in this image. Try reloading the Forum using a different URL until the popup goes away. We'll try and get this sorted out as soon as possible.

    Thank you.

    image

    image
    swlaero

  • Help diagnosing interference issues

    jksjks
    Okay, first of all my apologies for not understanding the sophistication of your setup. It is absolutely excellent. Hopefully my long-winded explanation above will help someone else because you clearly understand the issues.

    Now the problem: You've got the worst case of a bad switching power supply I have ever seen. The first clear carrier is on 167.9 kHz @ -66 dBm and appears about every 30.5 kHz up to 30 MHz. The carrier is narrow and stable but has "static" mixed in. This is a classic trait I've seen many times. The UVic beta site had a horrible signal like this around 14 kHz. Fortunately the harmonics died out in the LF spectrum. After almost a year it was traced to a bad power supply in an Ethernet switch.

    The fact that the harmonics go to 30 MHz and are so loud makes me wonder if it's a problem with one of the switchers on the Beagle. Like a bad filtering cap or something. The overall 0-30 MHz spectrum looks similar to the high noise problems we had with an early Element 14 manufactured Beagle. I assume this is a BeagleBone Green? I'd be happy to send you a replacement.

    There is also another huge signal (-56 dBm) at 86.5 kHz that is about 2 kHz wide and has the classic look of a "spread spectrum" (flattop) clock. It has harmonics in the NDB band every 9.5 kHz but dies out at MF.

    KM4YRI

  • Help! display partly dead.

    jksjks
    v1.28, and a few releases afterwards, were completely FUBAR unfortunately.

    g1tvl

  • kiwi.bin fails on PMUX check

    jksjks
    In case anyone is interested I'll explain: For various reasons a user program (one with privileges) cannot directly change the pin mux (PMUX) that determines which device functions and attributes are assigned to the I/O pins of the Sitara processor used on the Beagle. This is specified by device (cape) overlay files used by the kernel and by some other mechanisms. So there is some checking code to make sure the pins are in the state the Kiwi server expects. The panic you saw occurred when one of the unused expansion pins on the P8 connector was detected to have been set as an input with a pull-up rather than a plain input with no pull-up or pull-down. More pins were in unexpected states as shown in the file you attached.

    Now this by itself is not a problem. But the real question is why is this different all of a sudden when there are hundreds of other units out there running without an issue? This is one of the reasons why the Kiwi is shipped with a fixed, known-working Debian distribution. To try and eliminate the side-effects of dependancies like these.


    KA7U

  • Do you want a Facebook Page for KiwiSDR?

    jksjks
    "A" on 2097 is one of HF pirate beacons. Some of the best info is on HF Underground: https://www.hfunderground.com/board/index.php/topic,9478.0.html

    For a discussion of military "letter/marker beacons", some of which are in the Kiwi dx list, see here: https://en.wikipedia.org/wiki/Letter_beacon

    I personally boycott Facebook, but you guys can obviously do what you want. But I won't be contributing there if you do.
    At some point we'll need subcategories for the Kiwi discussions here.

    PA0PJE