The KiwiSDR 2 online store is open for orders! Please visit kiwisdr.nz
Fried my Kiwi/BB
Hi,
I unfortunately fried my Kiwisdr due to a polarity issue on the injector for the new antenna. I had the polarity reversed and did not see it until I powered it on and the kiwi (or at least the BB green) let the magic smoke out.
Now the question part, how likely is it that the kiwi board is impacted and also fried? If there is a chance that the kiwi board is still functional I would buy the BBAI-64 and give that a try.
I know the BB is fried as that won't even turn on without the kiwi board attached and powering through USB.. As the kiwi board is not available anymore I would hate that the board is fried (am still kicking myself for not checking polarity before fitting the powerpoles!)
Signed: a very sad KiwiSDR lover
ON3RVH
Comments
We've had several cases of reverse polarity causing the power management IC on the Beagle to blow up. But the damage is stopped before it propagated back to the Kiwi board. So personally I'd spend the money on another Beagle.
And if you had a BBAI previously definitely spend the extra money for the AI-64. Much better platform. The giant heatsink alone is worth the money.
The issue is that the reverse polarity entered the Kiwi board via the RF-IN port as the polarity was reversed on a Bias-T and that either sent current back to the Kiwi board which then propagated to the beagle, or in best case just shorted the beagle (and buck converter) because of the GND shared between the power source for the Bias-T and Kiwi entered on the RF-IN pin and VCC was applied to the GND part of the RF-IN.
I'll spend the money on an AI-64 (as I cannot find a BB Green anywhere) and test it.
The Kiwi antenna port is AC coupled. And the caps (see schematic, C405,406) are rated for 100V. I can't imagine there was a DC path unless the TVS diode(s) shorted. But even then that would just put a short across the antenna port. Even if it was with reverse polarity. I don't see how this would develop a negative potential on the Kiwi/Beagle 5V with respect to the Kiwi/Beagle ground reference. Maybe I'm missing something..
allright no worries then, I'll order the AI-64 and reinstall and keep my fingers crossed.
I love the kiwi. It's a very nice and all-inclusive webSDR and I would love to get it back online.
Thanks for answering and the response time was way below what I had expected!
Have a nice day (I'll keep the thread updated once I have the AI-64 and have tested everything again)
Ok, followed the instructions for the BB-AI64, updated the BB, cloned kiwi repo, compiled, installed board, ..
Main config part is done via the admin if, but trying to access the radio side of kiwisdr hangs. This also results in the admin webpage not responding anymore untill I restart kiwid
Thinking the kiwi board might have gotten fried too, or at least parts of it.
Very odd that you were initially able to connect to the admin page though. Because the first thing the Kiwi software does when it starts is program the FPGA (via the SPI) and then download a program into the little firmware cpu that runs on the FPGA and communicate with it (also via the SPI). So that much must have worked.
Check that there is an ~66 MHz clock on the "65M" test point (see troubleshooting guide). Although when that clock is missing you're just supposed to get a dark waterfall and no audio, not a hang.
Also check that the GPS clock (~16 MHz) is still running (GCLK test point).
Yeah the admin page works fine until I try to access the radio part
I can see the GPS and it even gets a lock with the correct coordinates and I think it syncs the ADC clock too
Tried changing the nr of radio’s, but that had no effect.
will attach a scope tomorrow evening, (Belgian time) will have to learn how to work the scope, but I got it for a reason and it’s time to learn how to use it. HI.
The GPS clock is used for the FPGA cpu. So that makes sense. I suppose if the ADC clock was way out-of-spec (e.g. too fast, bad waveform, undervoltage or something) that could cause issues. But that is unlikely. Yes, the scope will tell you..
In that case, the coax shield was positive. If the bias-T's power supply has negative connected to mains earth, there could have been current running through the kiwis GND.
I would check the voltages too. (Also since the AI-64 might draw more power than the BBG)
That is indeed what I will be inspecting this evening.
Currently the GPS works and it locks and updates the ADC from what I can see in the admin page.
But anything connecting to the HF radio part locks up the kiwi daemon, wspr from the kiwi itself, anyone connecting to the radio websdr, ..
Seems like the kiwi daemon has troubles accessing that part and then just locks up. Will recheck everything this evening and follow the troubleshooting guide and check with the scope what the signals do at each of the HF test points
I'd suggest checking R136 on the BB board. It is near the Ethernet connector and provides a very low ohm link between the digital and RF grounds.
When I have accidentally connected +5v to the KiWi Ground in the past, by accidentally touching the +5v centre point of the DC connector to the chassis, this resistor has blown open.
Replacing the resistor fixed the problem.
Regards,
Martin
can check the BBG too this evening, that one does not power on anymore.
Migrated the kiwi board to a BB-AI64 now, but the HF part of the board is not working for some reason, GPS works fine, but whenever I try to access the HF radio in any way the kiwi daemon locks up as it seems it cannot reach it (although the auto SNR readings appear to be working)
OK, so I checked voltage levels & signals and here are my findings
T301 shows 5V on input side, 0V on output side when measuring between the 2 pins of the T301, but 5V on each pin between the barrel ground .
But if I'm reading correctly then the T301 should not be needed with the BB-AI64 since it only powers the 5VE going to the BB and with the BB-AI64 it has to be powered via the BB board.
Signals and frequencies match with the TS guide with the only difference being that GCLK measures 0.73V instead of 0.9/0.8 . ADC clock is at 66.7Mhz, GCLK between 16.1 & 16.7Mhz,
GMAG measures 0.765 so that should be in range as well as GSGN measuring 1.34V
GND from the 5V in barrel of the kiwi board does not go through to the rest of the board (no path between the barrel GND and GPS GND for example)
So it sounds like T301 is fried, which is not a surprise since you had it running with a BBG at the time and 5V connected to the Kiwi DC jack.
But even though you're now using an AI-64, and powering via the AI-64 DC jack and not the Kiwi DC jack, I wonder if a T301 fault is loading down the 5V when more current is drawn during active user connections (e.g. waterfall DDC transfers active). Seems very unlikely though.
Maybe try disabling T301 as Glenn described in the recent "lightning strike" thread.
How is the voltage of the ADC clock? Is it over 3V pk-to-pk? (measured with scope)
Here's the diagram of the clock domains. So you can see why the SPI and GPS/eCPU could be working even if the portions clocked by the ADC clock have trouble.
Maybe the logs give a clue why kiwid crashed
/var/log/messages and the "dmesg" command.
kiwid does not crash, it just hangs and nothing in the log. Even when you add wspr listeners and then restart kiwid the kiwi daemon just hangs just after it starts the wspr listeners and interrupts everything else (even stops loading iptables firewall rules for the blacklisters)
I'll measure the voltage across the ADC this evening, did not think of that yesterday..
I'll also remove the T301 choke and see if that solves anything, fingers crossed :)
Choke removed, but have not jumpered across the pads yet, should I because the barrel in the kiwi is not
in use as everything should be powered by the BB-AI64 now if I'm not mistaken?
After 10 or so minutes the frequency stays stable around 65.8Mhz and with a Vpp of 3.24V
Yes, you are correct. You don't need to jumper over the T301 pads since everything is powered from the AI-64.
Well the ADC clock looks fine. The Rigol isn't the best frequency counter, but it basically says the oscillator and buffer chip are okay.
Just to double check, on my AI-64 setup, on the admin page config tab I enabled "external adc clock" mode but with no clock signal actually being applied. It works as before: No hang, just waterfall dark and audio silent.
So I don't know what the conclusion is here. About the only thing that could be wrong is that the FPGA is somehow damaged. But so much of it does work though. Quite a lot has to be okay for the GPS to work. So that conclusion doesn't quite make sense.
Anything else related, like the FPGA power supplies, can't be bad otherwise the GPS wouldn't work.
It is a wierd issue indeed..
Just set the "External ADC clock" to yes on the config page and disabled the updating of the ADC from GPS too but issue stays the same unfortunately. As soon as I go the openwebrx it hangs and after a few minutes the admin page comes back with "Server has closed connection. Will retry."
Don't know if the kernal has anything to do with it, but I'm running Debian 11.7, kernel 5.10.168-ti-arm64-r108
everything compiled as it should and no errors thrown during compilation or installation
output of kiwid starting up (if this is any help at all, I certainly can't find any error in it)
--
Aug 10 08:15:20 kiwisdr systemd[1]: Starting kiwi daemon...
Aug 10 08:15:20 kiwisdr kiwid[2810]: BBAI-64 Debian 11.7 USE_SPIDEV
Aug 10 08:15:20 kiwisdr kiwid[2810]: Starting kiwid
Aug 10 08:15:20 kiwisdr kiwid[2810]: BBAI-64 uses custom Kiwi device tree loaded via U-boot
Aug 10 08:15:21 kiwisdr kiwid[2810]: Start kiwid: OK
Aug 10 08:15:21 kiwisdr kiwid[2832]: Thu Aug 10 08:15:21 CEST 2023
Aug 10 08:15:21 kiwisdr systemd[1]: Started kiwi daemon.
Aug 10 08:15:21 kiwisdr kiwid: 00:00:00.905 KiwiSDR v1.621 --------------------------------------------------------------------
Aug 10 08:15:21 kiwisdr kiwid: 00:00:00.906 compiled: Aug 8 2023 09:28:54 on kiwisdr.on3rvh.be
Aug 10 08:15:21 kiwisdr kiwid: 00:00:00.906 /etc/debian_version 11.7
Aug 10 08:15:21 kiwisdr kiwid: 00:00:00.928 reading configuration from file /root/kiwi.config/kiwi.json: 603 tokens (7.7k bytes)
Aug 10 08:15:21 kiwisdr kiwid: 00:00:00.929 reading configuration from file /root/kiwi.config/admin.json: 133 tokens (3.3k bytes)
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.312 serial number from EEPROM: 1350
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.312 reading configuration from file /root/kiwi.config/dx_config.json
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.312 reading configuration from file /root/kiwi.config/dx.json
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.316 DX: 872 label entries
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.316 DX: file = 872,db6868b3,52120
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.316 reading configuration from file /root/kiwi.config/dx_community_config.json
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.316 reading configuration from file /root/kiwi.config/dx_community.json
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.320 DX: 872 label entries
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.320 DX: file = 872,db6868b3,52120
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.320 .... firmware: SDR_RX4_WF4
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.320 .... firmware: rx_chans=4 wf_chans=4
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.320 .... firmware: RX rx_decim=5555 RX1_STD_DECIM=505 RX2_STD_DECIM=11 USE_RX_CICF=0
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.320 .... firmware: RX srate=12001.062(12000) bufs=4 samps=170 loop=85 rem=0 intr_usec=14166
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.320 .... firmware: WF xfer=9 samps=911 rpt=50 loop=18 rem=11
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.321 .... webserver: listening on port 8073/8073 for HTTP connections
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.321 .... webserver: OK, port [::]:8073
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.551 .... ### open SPI_DEV /dev/spidev0.0
Aug 10 08:15:21 kiwisdr kiwid: 00:00:01.551 .... ### open SPI_DEV /dev/spidev9.0
Aug 10 08:15:23 kiwisdr kiwid: 00:00:02.715 .... FPGA version 1
Aug 10 08:15:23 kiwisdr kiwid: 00:00:03.145 .... using DC_offsets: I -0.020000 Q -0.020000
Aug 10 08:15:23 kiwisdr kiwid: 00:00:03.458 .... UPDATE: check scheduled (startup)
Aug 10 08:15:23 kiwisdr kiwid: 00:00:03.458 .... UPDATE: checking for updates
Aug 10 08:15:23 kiwisdr kiwid: 00:00:03.460 .... file_GET: running, download/diff/update-or-use-previous..
Aug 10 08:15:23 kiwisdr kiwid: 00:00:03.486 .... PROXY: NO dom_sel_menu=0
Aug 10 08:15:23 kiwisdr kiwid: 00:00:03.693 .... NET(0): private IPv4 <x.x.x..20> 0x2c1f4414 /24 0xffffff00 eth0
Aug 10 08:15:23 kiwisdr kiwid: 00:00:03.693 .... NET(0): private IPv6 #0 <y:y:y::20> y:y:y:y:y:y:00:00:00:00:00:00:00:00:00:20: /64 ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00: eth0
Aug 10 08:15:23 kiwisdr kiwid: 00:00:03.694 .... NET(0): private IPv6 LINK-LOCAL <fe80::2676:25ff:fea2:2098%eth0> /64 ff:ff:ff:ff:ff:ff:ff:ff:00:00:00:00:00:00:00:00: eth0
Aug 10 08:15:23 kiwisdr kiwid: 00:00:03.694 .... auto NAT: is set false
Aug 10 08:15:27 kiwisdr kiwid: 00:00:07.215 .... UPDATE: version 1.621 is current
Aug 10 08:15:28 kiwisdr kiwid: 00:00:08.487 .... TIMEZONE: lat/lon from admin public config: (51.249893, 2.998087)
Aug 10 08:15:29 kiwisdr kiwid: 00:00:09.106 .... IPINFO: public ip x.x.x..20 from ipapi.co
Aug 10 08:15:29 kiwisdr kiwid: 00:00:09.106 .... IPINFO: lat/lon = (51.242599, 3.025000) from ipapi.co
Aug 10 08:15:29 kiwisdr kiwid: 00:00:09.406 .... TIMEZONE: from timezonedb.com for (51.249893, 2.998087): utc_offset=7200/2.0 dst_offset=0/0.0
Aug 10 08:15:29 kiwisdr kiwid: 00:00:09.406 .... TIMEZONE: "CEST", "Europe\/Brussels"
Aug 10 08:15:30 kiwisdr kiwid: 00:00:10.214 .... ip_blacklist_get: ip_blacklist_hash = 05a4342b
Aug 10 08:15:30 kiwisdr kiwid: 00:00:10.215 .... ip_blacklist_get: stored=1595 downloaded=1595 diff=NO download_diff_restart=0
Aug 10 08:15:30 kiwisdr kiwid: 00:00:10.215 .... ip_blacklist_get: using STORED blacklist
Aug 10 08:15:30 kiwisdr kiwid: 00:00:10.215 .... ip_blacklist_get: using previously stored blacklist
Aug 10 08:15:30 kiwisdr kiwid: 00:00:10.226 .... ip_blacklist_init_list: 107 entries: ip_blacklist
Aug 10 08:15:30 kiwisdr kiwid: 00:00:10.427 .... ip_blacklist_add_iptables: "iptables -I KIWI -s 1.124.107.0/24 -j DROP" rv=0
...
Aug 10 08:15:43 kiwisdr kiwid: 00:00:23.300 .... ip_blacklist_add_iptables: "iptables -I KIWI -s 139.180.128.0/18 -j DROP" rv=0
Aug 10 08:15:43 kiwisdr kiwid: 00:00:23.470 0... 0 15000.00 kHz WF z0 "SNR-measure" 127.0.0.1 internal task (ARRIVED)
Aug 10 08:15:43 kiwisdr kiwid: 00:00:23.501 0... ip_blacklist_add_iptables: "iptables -I KIWI -s 139.198.0.0/16 -j DROP" rv=0
...
Aug 10 08:15:45 kiwisdr kiwid: 00:00:24.713 0... ip_blacklist_add_iptables: "iptables -I KIWI -s 149.28.8.0/21 -j DROP" rv=0
Aug 10 08:15:45 kiwisdr kiwid: 00:00:24.895 .... 0 15000.00 kHz WF z0 "SNR-measure" 127.0.0.1 internal task (LEAVING after 0:00:01)
Aug 10 08:15:45 kiwisdr kiwid: 00:00:24.914 .... ip_blacklist_add_iptables: "iptables -I KIWI -s 149.28.16.0/20 -j DROP" rv=0
...
Aug 10 08:15:52 kiwisdr kiwid: 00:00:31.767 .... ip_blacklist_init_list: 0 entries: ip_blacklist_local
Aug 10 08:15:52 kiwisdr kiwid: 00:00:31.772 .... DX: checking /root/kiwi.config/dx_community_config.json against kiwisdr.com/dx/dx_community_config.json
Aug 10 08:15:52 kiwisdr kiwid: 00:00:32.534 .... DX: CURRENT /root/kiwi.config/dx_community_config.json
Aug 10 08:15:52 kiwisdr kiwid: 00:00:32.537 .... DX: checking /root/kiwi.config/dx_community.json against kiwisdr.com/dx/dx_community.json
Aug 10 08:15:53 kiwisdr kiwid: 00:00:33.489 .... DX: CURRENT /root/kiwi.config/dx_community.json
Aug 10 08:15:59 kiwisdr kiwid: 00:00:38.883 .... [00] PWD isLocal_if_ip: TRUE IPv4/4_6 remote_ip x.x.x..1/x.x.x..1 ip_client x.x.x..1/0x2c1f4401 ip_server[IPv4] x.x.x..20/0x2c1f4414 nm /24 0xffffff00
Aug 10 08:15:59 kiwisdr kiwid: 00:00:38.884 .... [00] PWD admin config pwd set TRUE, auto-login FALSE
Aug 10 08:16:01 kiwisdr kiwid: 00:00:41.634 .... [00] PWD isLocal_if_ip: TRUE IPv4/4_6 remote_ip x.x.x..1/x.x.x..1 ip_client x.x.x..1/0x2c1f4401 ip_server[IPv4] x.x.x..20/0x2c1f4414 nm /24 0xffffff00
Aug 10 08:16:01 kiwisdr kiwid: 00:00:41.634 .... [00] PWD admin config pwd set TRUE, auto-login FALSE
Aug 10 08:16:02 kiwisdr kiwid: 00:00:41.885 .... [00] browser: <Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0>
--
kiwid keeps running though, even after it closes the webserver:
--
# ps auxw|grep kiwid
root 2831 99.0 2.7 171928 103748 ? RL 08:15 9:09 /usr/local/bin/kiwid -use_spidev 1 -bg -v 1.621
# netstat -aneput|grep kiw
tcp6 413 0 :::8073 :::* LISTEN 0 25244 2831/kiwid
udp 0 0 127.0.0.1:34850 127.0.0.1:36009 ESTABLISHED 0 25243 2831/kiwid
udp 0 0 127.0.0.1:36009 127.0.0.1:34850 ESTABLISHED 0 25242 2831/kiwid
--
I missed that last comment until now for some reason.
Yes, kiwid runs all the time flat out at 100%. This is so it can meet the realtime response requirements and keep Linux from (most of the time) arbitrarily breaking things like the audio continuity.
I think you might have posted that comment in the wrong thread :)
kiwid keeps running though, even after it closes the webserver:
I was responding to this comment above.
That makes sense :)
tried the latest update but still no joy, so thinking something has gone wrong with the board unfortunately..
am trying to find another board (or complete kiwi) but it's been difficult which was to be expected..
Anyway, thank you for the support and trying to get it back online with me, I'm going to call this board a loss unfortunately
It's probably a lot of work, but you could try to debug, using strace -p to see what kiwid does when you access the web interface.