KongSDR with no net connection after power outage [scan tool has been fixed]

edited October 2018 in Problems Now Fixed
After a power outage I use to have problems getting my Kiwi “on the air” again. I am used to having 2-3 attempts to power on before it will start. In these instances, it will flash a single led “dit-dit”. And nothing more happens. Then after a few tries it does boot properly from the looks of the leds.
However today, when it finally booted, the ethernet port did not seem to be willing to respond, with only the green led lit. Ethernet cables replaced etc., no cigar. I then started the scan, but nothing found.
I’m at loss now. I need to get it up today, or it will be offline for the next week, which is a loss for many listeners.


  • Is it connected to a router? Does the router show its existance?
  • It is connected to a router/modem. The system log of the past couple of hours show no requests from the Kiwi. And as I mentioned, no ethernet lights activity either. I flashed the Kiwi an hour ago, if it was a good or a bad thing I don't know.
  • edited September 2018
    It sounds more like a BBG problem. If it were I, I would find a debian image and burn it onto another flash, remove the Kiwi cape, and see if the BBG works as a Unix system.

  • We'll see what John says. Every time it now boots, it goes into "dit-dit" flashing leds and nothing else
  • I have found mine may not bring the network up if the 5V does not come up quick enough (original switcher), do you have anything loading the supply? on the USB port? is the DC lead long enough to allow it to sag?
  • I have a Bel Power Solution 3A, 5V PSU, which I have had for over a year. It's been feeding the Kiwi and a NetSDR. I have increased the diameter of the leads, just to be sure John's recommendation of minimum 22AWG leads be met (and with a margin). The DC lead is perhaps 60 cm long.
  • Power supplies do age, you are running two devices that require at least half of the supply, my guess is that 1. the Supply is no longer able to provide the current required,
    2. that the devices (either) are asking for more current than they used to due to increased load or aging capacitors etc.
    If you can try the Kiwi on that supply alone see if the issue goes away, if it does either have two supplies capable of at least 1.5A continuous or one 5V good for 4/5A to give a little headroom.
  • Do you have a voltmeter?
  • Bel is a lab grade, 1 year old PSU. The two would draw around 2.3 - 2.4 A, but even with the Kiwi alone, there is nothing for it. Output voltage is 5.03V. So while I appreciate your suggestion, I don't think the problem is within the PSU.
  • I agree and didn't think it was the PSU but asked about the meter to put that thought to bed.
  • So is that a lab grade "variable current limited" PSU? (what actual model).
    Have you checked the DC at boot up on a scope in case it is momentarily limiting?

    I'm only talking from experience, it might be that I am seeing a similar issue to you but have hidden it with power supply behavior.
    If mine won't boot cleanly I make sure nothing else is on the 5V then put the plug in at the PCB.
    have you tried seeing if it boots with the other SDR running and being literally plugged in right at the SDR?
  • You ask questions I can't answer, nor have I the equipment to ... but the datasheet is on this link (the actual model is HB5) https://www.mouser.com/datasheet/2/643/ds-BPS-linear-series-1314581.pdf
    I have booted the Kiwi both with and without additional load - today mostly without since I wanted to remove any uncertainty. The NetSDR boots and runs with SDR Console without problems. Previous to today, there were no problems with this co-existence. However, the power outage today did change the game, or was maybe the catalyst.
  • OK, It says that one has remote sense so you could run some extra sense wires to the Kiwi DC plug so that it can compensate for any voltage loss in the leads (up to 250mv).
    Right now I'd just power the Kiwi down and move the Kiwi to BB pin header coupling in and out a few mm to ensure the pins are clean (take static precautions just in case).
    I assume the PSU and Kiwi are adequately cooled?

    I didn't understand whether it successfully booted today or not (with just the Kiwi)?

  • From what I understand by the led lights, it did boot correctly a couple of times. However, there was never any contact with the modem/router. Several ethernet cables were used. And now it just sits "dit-dit"...

    Yes, no heat problems. I have even taken the box off the Kiwi.
  • edited September 2018
    In that situation I'd personally fire up a Linux box (just because they are quicker to change network settings), use a cross over cable to the Kiwi and packet sniff it with Wireshark.
    You are looking to see what traffic if anything comes out of the interface.
    I suppose it is possible that between the two SDR's you've had some induced voltage that has cooked something, is there long wire somewhere in the mix and are you grounding out any static?

    Did you try disturbing the Kiwi-BB coupling, faultfinding is easier if we exclude stuff, there are fair number of signals and obviously power going across that interface.

    The fact it does not get any further than the dit-dit is probably an indicator of greater problems so if you are sure the PSU is good and the interface is clean I'll butt out and wait for the cavalry.

    I suppose you could re-flash it with the SD card but I won't be going there as I've not done that myself.
    It may have got corrupted by many partial boots, also elsewhere I read that the momentary voltage drop due to power-on surge on current limited supplies can corrupt the flash.
  • Sometimes if the power supply doesn't immediately provide the required output volts but rises from a low voltage up to full output, the KiWi won't start.

    I've only ever had one case with the symptoms you describe, and in the end UI had to reflash it from an SD card.

    Because I've been caught out in the past (usually due to my own mistakes when fiddling with some aspect of the KiWi code) I now try to keep an reasonably up to date backup on an SD card at all times (and certainly make a backup before trying anything risky) so that I can quickly get out of trouble if required.

    It's also particularly important if you have the antenna switching option installed or any other specific config or DX.json files.


    Martin - G8JNJ
  • The following requires that you have a means of putting 5V on a microUSB connector. I would try removing the Kiwi board from the BBG and seeing if the Ethernet lights behave any better. It will also allow you to put your finger on the tiny Ethernet PHY chip near the BBG RJ45 and see if it's gone into the well-known meltdown failure mode.

    The BBG is annoying in that is takes 5V over a microUSB as opposed to the 2.1mm barrel jack of the Kiwi and BBB. If you use a cellphone USB-to-microUSB cable you are back to the problem of possible voltage drop from the cable using too small diameter wires. So don't use a long cable. This situation is improved because the BBG alone will only require around 500 mA at 5V.

    Don't bother putting a stock Debian image on another sd card. If you're getting the normal Kiwi LED pattern then the software is fine. But the "couple of LED flashes then nothing" you describe is also a symptom of the BBG PHY failure, or power supply under-voltage, problem.
  • Thanks John, I removed the Kiwi board and inserted a short micro-usb cable. There is life! Green ethernet led is clearly working. To be fair, I'm a bit at loss as to what next...
  • jksjks
    edited September 2018
    Can you ssh/PuTTY/ping/TeamView into the Beagle okay?

    Your Bel supply does have a little trimpot someplace to adjust the 5V output. You could take it up to, say, 5.15V and see if it makes any difference. There is some drop through the little common mode choke and PCB traces on the Kiwi board before the 5V is routed to the BBG 5V input. The BBG should start with up to 5.25V on its input and shouldn't blow-up if the voltage exceeds that value somewhat (but it won't startup). But why this has changed after a year makes no sense.

    Be extremely careful when re-attaching the Kiwi board that the header pins line up properly. See here: http://kiwisdr.com/quickstart/quickstart.pdf
  • John, I did flash as a "last resort", so if it boots properly, it will boot with the 2016 software. Anyway, I am totally illiterate when it comes to Linux commands, so please don't ask me to... I adjusted the Bel power output to 5.19V and put back the kiwi board. When I applied power, it seemed to boot - however it came to rest with the dit-dit led but this time the ethernet green light was lit. And there is a fixed led on all the time on the other side of the ethernet connection which has been on all the time. I don't know if that might be related to the meltdown you mentioned earlier.
    So! Nothing's really changed, but I have an ethernet light!
  • The single blue LED on the other side of the RJ45 from the 4 software-status LEDs indicates that the Beagle power controller is on.

    The "dit-dit" of the leftmost of the 4 LEDs is the Linux "heartbeat" pattern. After a power on does this just happen once and then never again or does it happen every second or so? (the normal sequence is dit-dit, pause for 1 second, dit-dit, ...) Do any of the other 3 LEDs flash ever after a power up? They indicate access to the sd card, eMMC filesystem and if Linux is idle or not.
  • Immediately after power-up there is lots of activity on all leds. Then the leftmost mostly dit-dits until a couple more rushes of activity after perhaps 60 seconds or more (I didn't take the time). Then the dit-dit settles in the normal sequence you mentioned. The green ethernet led is fixed on, no blinking indicating data transfer.
  • Ah, okay. So that sounds to me like Linux is running but the Kiwi code is not (but see below). After it starts the Kiwi code "takes over" the 4 LEDs and displays the Ethernet ip address using the scheme described here: http://kiwisdr.com/quickstart/index.html#id-leds

    But if you re-flashed to v1.2 and an update to v1.235+ over the network has not happened then the LED take over doesn't apply.

    Do you get the yellow/orange LED on the RJ45 as well? I think that indicates a 100 mbps connection (vs only 10). The green LED should flash when there is traffic on the network and it is odd that it isn't. Even if the router is isolating you from other network traffic usually some broadcast packets get through and the greed LED will flash occasionally.
  • edited September 2018
    Would the IP address not be set back to default - that may affect traffic.
    Scrub that just checking quickstart its DHCP, can't remember why I fixed mine, might have been to narrow down connectivity issues back in the day.
  • If I remember correctly he uses DHCP for the ip but the proxy for outside access (Internet is on a 3/4G connection).
  • I did have the Kiwi code this morning (when it was still not being seen), but then I flashed from the original card...
    I do not get the orange led. I am connected to a 4G modem/router TP-Link. but I have an Intel NUC which is connected to the same modem, and its orange led does light on it.

    You remember correctly ;-)

    The auto-discovery scanner doesn't see anything, but it is painstakingly slow compared to when it was new. One port is 20 seconds.
  • 20 seconds? That's not right. It's supposed to launch the scan probes at a fixed rate. Is it sill that slow if run on a freshly launched browser? On other browsers?

    One of the Ethernet PHY failure modes I saw here was only one LED (orange or green) in addition to no LEDs. So maybe this is still a PHY problem given that the green LED is not flashing. It would be very helpful to do a ping to the Beagle. But then you must know the ip address..
  • wouldn't the IP address be in the router as seen by its admin access?
  • Can't get into the router as I recall.
  • Scanner still takes 20 seconds/port after closing and restarting Chrome. Might be faster to enter addresses manually
Sign In or Register to comment.