Last Active
Member, Administrator, Moderator
  • V1.57 lost link to sdr.hu

    Will be fixed in v1.58 going out at 0200Z.

  • received signals delay between "analog"_RX vs KIWI_SDR vs SDR_IQ_RFSpace

    The audio delay (lag) is a consequence of delivering buffered web audio over the Internet. WebSDR is better in this regard due to the advanced techniques they use. It is possible we might match them sometime in the future but it would take a lot of work. Their current method is proprietary.

    The KiwiSDR is not designed to be a ham radio QSO receiver with associated performance. It is a "shortwave receiver" class device with limited specifications from use of a 14-bit ADC, relatively low ADC clock frequency, lack of a better RF front-end, no direct IQ output etc. But it is designed to be self-contained, Internet enabled, multi-user and relatively inexpensive given its capabilities. A lot of this is explained in our design document, which is now somewhat out-of-date: https://dl.dropboxusercontent.com/u/68809050/KiwiSDR/KiwiSDR.design.review.pdf

  • static ip does not change

    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.

  • Blue Light Flash [power cable voltage drop]

    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.

  • USB Max BW

    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.