Kiwi V/UHF noise

This discussion was created from comments split from: KiwiSDR 2.


  • I almost got rid of the internal noise of the Kiwi SDR on VHF by connecting the SMA connector housings to the aluminum housing. And you want to isolate them from the masses! I think it's a bad idea. However, my setup is specific. All the antennas are located a couple of meters from the KiwiSDR and I am good at receiving interference on UHF from the FPGA switching power stabilizer. Have you ever thought of replacing the PWM with a linear stabilizer? FPGA consumes not so much power. The linear stabilizer will easily cope with the thermal load.

  • It was observed way back in 2016, and verified by me, that the noise floor at HF was raised slightly by having two points of grounding to the enclosure: at the SMAs and from the Beagle via the standoffs. So that's why the Kiwi extruded aluminum enclosure had a large cutout for the SMAs. Probably due to the small ground loop this formed.

    KiwiSDR 2 of course requires an isolated antenna SMA. So really we're doing nothing different than what KiwiSDR 1 had using the original enclosure.

  • If possible I'd be interested if you could run an experiment. This is to determine if the noise you're getting is really from the FPGA 1V SMPS or the SPI interface.

    Connect to Linux on the Beagle using ssh or PuTTY. Disable the normal background operation of the server and run it in "debug" mode to disable the GPS:




    Now without making a user connection check for your noise. Now make a user connection (to get audio and waterfall) and check again. Was it quiet at first and then bad? Or bad both times?

    When run in debug mode, and no user connections, there should be no activity on the SPI interface between the Beagle and Kiwi board. The FPGA 1V SMPS will still be working fairly hard because all the clocks are running and the full audio and waterfall DDCs are operating. So a lot of FPAGA gates are switching.

    When I place a small EMI pickup loop from my spectrum analyzer directly over the SMPS I see all the harmonics of the 2.8 MHz switching frequency up to about 150 MHz. Then the amplitude drops significantly. But if the loop is moved more than 1cm away it all disappears into the noise.

    If I place the loop over the shield can of the antenna input circuit everything is quiet. But as soon as a user connection is made there are these large, wide harmonics from the SPI serial clock (48 MHz). One of them unfortunately falls at 144.010 MHz (48*3). That's why there is the the admin page setting to reduce the SPI clock to 24 MHz. To get the harmonic out of 2m.

  • edited September 6

    Hi, jks. I don't have admin access to my KiwiSDR yet (I rented it). Later I will ask the host to grant me full access. As for the SPI and PWM noises, they have different shapes and are easily distinguishable on the waterfall. SPI noises have a pronounced periodic structure. PWM noise is "warm analog". Here is a short video showing the SPI noise when connecting and disconnecting the user.

    Here in this video you can see the noise from PWM when restarting KiwiSDR. You can see how the generation frequency changes depending on the load on the FPGA.

    Oddly enough, the noise from PWM does not manifest itself on short waves and becomes noticeable on VHF. I use the original aluminum housing. Perhaps he is the reason. Connecting the ground of the SMA connectors to the housing with a nut significantly reduces these noises.

  • Every SMA on the antenna end of the rx probably should be isolated and not just for consistency. This is because attaching any of them to the enclosure creates a CM path through the groundplane at that end of the PCB and an attendant IZ drop which can then be coupled into the input of the preamp even with an isolation transformer. Whether or not there is I injected by something, e.g. PS, LAN, ext clock CM current, if that path is not left isolated it can't later be removed. If they are left isolated then the user has the option.

    The resulting problem varies by installation but "there ain't no such thing as ground". While the R of the Z=R+jX is probably under 10 milliohms ( I measured 4 on Kiwi1, the X is bounded by the u0 of space-time itself at about 32 nH/inch.

    I support the isolation sleeve idea, I think the added SMA shield-to ground capacitance will be inconsequential at HF.

  • edited September 6

    I don't understand high-frequency currents at all and how they propagate. I had the lowest grade in this subject at the institute. But by an experimental method, I found out that SMA connectors that do not have physical contact with the aluminum housing are a strong source of interference radiation from the PWM controller. I think I've already shown this video of mine.

  • edited September 6

    You can test this yourself by driving across the ends of the PCB from a 50 ohm swept HF source at a known power level. Calculate the current through the ground planes and compare that to the Kiwi's response, which should have a noise floor around -155 dBm/Hz to give coupling factor in a 50 ohm environment. I've measured values on the order of 80 dB below the 50 ohm source power.

    If your unwanted CM current through the planes, terminated at the SMA end is more than this coupling above the noise floor, there will be unwanted response in the Kiwi. Grounding rather than isolating this end of the PCB increases that current. Even relatively small capacitance, e.g. the inter-winding capacitance of an isolation transformer can be of significant in some situations.

    It doesn't require very much CM current to damage performance with many typical installations, which is often available even though the CM source and load impedances may be higher than 50 ohms.

  • Glenn, I didn't understand what you wrote at all ))) But I think it's fascinating. Perhaps I should study high-frequency currents in more detail. Thanks!

  • edited September 6

    If I understand studentkra's issue corretly, the problem is radiated interference from the kiwi to a different receiver?

    I can measure the SMPS harmonic at 65 MHz from the kiwi with a H-field probe about 5-6 meter along the antenna coax.

    But that should improve with the input transformer of the Kiwi V2. Unless it is radiating from the power cable. I can't measure that since i have 2-stage filters right at the kiwis DC input.

    This is the spectrum 30-80 MHz 2m from the Kiwi on its antenna cable with a H-field probe.

  • We're still working out the details. But I will specify a right angle SMA that uses a continuously threaded barrel, as opposed to the ones that have a straight section followed by a short threaded section.

    That way you could remove the insulating washer from the ext clk and/or GPS SMAs and add appropriate hardware to get an electrical connection to the case (e.g. oversized 1/4" washer, star washer, nut on both sides of case). The outer case might be powder coated steel (insulated). But the inner part will be uncoated. You might have to buff it up with a little steel wool or something to get better contact.

  • HB9TMC, yes, you're right. There was interference from KiwiSDR on the nearby antennas of other receivers that work on VHF. And it's definitely not from the power cable. As I already wrote, connecting the SMA connectors to the aluminum housing reduced the level of interference. And yes, the separation transformer at the SMA input will give a good attenuation on VHF. So now it seems to me that this is the right decision! As far as I understand from your spectrum analysis, there is interference on the VHF. Right?

  • jksjks
    edited September 7

    Today I found that adding a 66R series "termination" resistor to the SPI clock trace on the Kiwi board seems to reduce the relative strength of the 144 MHz harmonic by around 6 dB. Termination in quotes because I have no way of calculating the impedance of the full "trace" length. And 66R is simply a resistor that is already in the BOM. The ADC 66 MHz clock and data lines use series termination resistors.

    The SPI traces are ugly because they go through the header connector without any surrounding ground pin(s). The clock signal is also driven on both ends (Kiwi FPGA and Beagle CPU) which complicates matters. I'm sure this contributes to the source of the problem. The Beagle header setup was really never intended for high-speed digital signals.

    Anyway, maybe the thing to do is add series resistors to all the SPI signals. They can be populated with 0R jumpers if there are any problems.

    NB: the following images are 5 dB/div rather than the usual 10.

    No series termination:

    With 66R series termination:

  • Although the SPI bus specification does not involve the use of blocking capacitors to ground, I think it's worth a try. Capacitors need to be installed on both sides. Near the GPIO connector and near the FPGA. The capacity should be tens of picofarads. And you can also solder them to the Beaglebone board near GPIO. But these are just my thoughts.

  • jksjks
    edited September 7

    I tried that actually. The smallest caps I had were 22 pF. The FPGA would not program with those in place (the SPI bus is used to program the FPGA as well as communicate with the FPGA afterwards).

    The buffers on the Beagle and FPGA are not meant to drive highly capacitive loads like that. Especially not at 48 MHz.

  • edited September 7

    I see. This was to be expected. And here, most likely, it's not about the load. The capacitor makes the pulse fronts flat. And at a frequency of 48 MHz, these pulses can no longer be recognized.

    As far as I understand, there is a parallel data bus trace on the KiwiSDR board, which is not used. Are there any plans to use it in the future?

    And by the way, some beaglebones have a QSPI or SPI quad hardware interface. You didn't plan to use it?

  • @studentkra

    Yes there is harmonics from the SMPS radiated on VHF. They only start to show up above about 40 MHz. I think it is radiated from the kiwis antenna cable. I do receive them too on my 6m antenna very weak, which is about 10 meters away.

    I don't know if the capacitance of the new input transformer is low enough to decouple. Maybe Glenn can judge that.

  • Hi John,

    WRT "Anyway, maybe the thing to do is add series resistors to all the SPI signals. They can be populated with 0R jumpers if there are any problems."

    Good idea, and it would also allow you to try some in-line SMD ferrites.

    I note that in addition to reducing the level of the carrier, it also dropped the noise sidebands by a similar amount, which is also beneficial.



  • HB9TMC

    Most likely, SMPS interference is emitted by the antenna cable connected to the SMA. Most likely, from its shielding. I tried connecting either the main antenna or just the GPS antenna. When only the GPS antenna is connected, I also observe these interferences.

  • Another interesting point. I also have a KiwiSDR clone that works with the Radpberry Pi 3B board. The frequency of the SPI bus is the same there, 48 MHz. However, the main source of interference is at 120 MHz, unlike KiwiSDR, where the SPI bus makes noise at 144 MHz. And it's unclear.

  • jksjks
    edited September 7

    It would also allow you to try some in-line SMD ferrites.

    Good idea. I hadn't thought about that. The reason there are sidebands is because the SPI clock is not constantly enabled. It is only active per serial packet transmitted. So for short transfers it appears as a short 48 MHz burst. The SA images above were in peak hold mode to capture the worst case amplitudes.

    There is a parallel data bus trace on the KiwiSDR board, which is not used. Are there any plans to use it in the future? Some beaglebones have a QSPI or SPI quad hardware interface. You didn't plan to use it?

    We're covering old ground now. The original Kiwi philosophy was to keep the hardware as simple as possible and spend all the time working on the software. Hardware is difficult and expensive to fix. Software is relatively easy.

    It was known that the SPI worked for programming the FPGA and quickly discovered that it would be sufficient for the rx4/wf4 configuration (and later it happened to work for the other configurations as well). Extra wiring was added on the P8 port. But the intent was for GPIO use (the FPGA JTAG is also brought out to P8 so in theory you could bit-bang JTAG control of the FPGA from the Beagle).

    The problem with trying to create a true parallel interface between the Beagle and FPGA is this: What are you going to do on the Beagle side to make it fast enough to be worthwhile? Using the PRUs are a possibility, but at the time I didn't know much about them (and they don't exist on later Beagle models such as the BBAI-64). If you're going to try and use the TI CPUs DMA hardware then that requires a Linux device driver. And that's a whole level of complexity I didn't want to get into because of the time and effort required. Look at the Kiwi RPi port. It was done with essentially no trouble because it only required a little bit of code to configure the SPI port.

    So you can say "what about this, what about that". But without carefully considering the entire ecosystem, which includes how you spend your time, you can easily get bogged down on a path that has limited value.

    Now, in spite of the above, there is definitely a case for future Kiwi products where some of these ideas are implemented in a more general way. Such products depend on KiwiSDR 2 being a success and are certainly years away. But you can easily imagine getting rid of the Beagle by integrating the host function onto the Kiwi PCB. This allows many more choices in the host-to-FPGA interface and almost certainly a better RFI/EMI situation.

    But again, these are all very much in the future and depend on KiwiSDR 2 getting back into production ASAP and being a financial success (and other things, like you guys not causing me a stress-induced heart attack etc, lol).

  • jksjks
    edited September 8

    I think maybe the thing to do is add two 0402 pads. One near the Beagle header pin and one as close to the FPGA as possible. The distance between the two is roughly 13 mm (the trace distance is somewhat longer). And use ferrite beads at those locations. And then not bother with series resistors. The Kiwi already uses these TDK FBs for power supply filtering.

    Five KiwiSDR 2 prototypes are already in production and can't be changed. But I have plans to make five more with a different vendor. So the most recent changes can be tested before any sort of production run.

    Given the response curves in the FB data sheet does anyone have an opinion on which parts should be tried? For power supply filtering the MMZ1005B601C is used which has the greatest attenuation at HF. For the 48 MHz SPI interface it seem a part from the MMZ1005 Y, D or F series is most appropriate.

  • @jks, you don't have to worry about noise in the power circuits. They are almost invisible and do not interfere. At the expense of the SPI bus, chip breads is a good barrier to a digital bus interference source. But you need to take into account that the wires from the CPU Beagle Bone to the KiwiSDR board also have a length. In any case, it is difficult to mathematically calculate such a situation. You need to try it on layouts.

  • By "power supplies" I meant the Vcc into sensitive components like the ADC preamp, ADC clock XO etc (see Kiwi schematic). This is standard practice and every SDR does this kind of filtering.

    There is nothing I can do about the traces on the BBG/BBB or in the header. That is a problem to be solved when the host migrates onto the Kiwi board in the future.

    I realize trial-and-error is required to find the optimal part. What I was hoping for is people's opinion on which of those parts would be best to try first. From those response curves it's obviously a trade-off between some impedance at 48 MHz in exchange for better attenuation at, say, 144 MHz.

  • I'd say the D series looks like a possibility, especially the part with the sharp impedance peak at around 200MHz, but that's just my opinion.

    In addition to the impedance it presents, it will also alter the rise time of the data and clock signals, so some real life tests will be required to validate any changes in performance.



  • @G8JNJ That's what I was thinking too. I'll have the prototypes built with those and see how it goes.

Sign In or Register to comment.