A quick (and probably incomplete) guide to getting kiwirecorder and kiwiwspr (now wsprdaemon) running on Linux

What follows is likely to be quite incomplete - but it contains the major steps in installing the kiwirecorder and kiwiwspr packages on a Linux machine.  I did my installation on Ubuntu, but similar may be done on other distros, such as Debian - including on the Raspberry Pi platform.

I don't claim to be an expert in such things and it is likely that I missed a few steps that may be specific to some distros/platforms - but the phrase "Google is your friend" is applicable if you run into trouble as it's likely that I can't help in your specific case.

What is "kiwirecorder"?

The kiwirecorder package works in conjunction with a "KiwiSDR" (see KiwiSDR.com for more information) - a relatively inexpensive (approx. $300) stand-alone, Linux based HF receiver capable of tuning from a few kHz to over 30 MHz.  Intended to be remotely accessed, it sports a Web-based user interface that provides both audio and a waterfall display along with the capability of demodulating various modes (SSB, CW, AM, FM) and decoding several different types of transmissions, including CW, FAX, FSK and WSPR.  Depending on configuration it is possible to have up to eight "users" connected, via the Internet, to a single KiwiSDR, each using their own frequency and mode settings.

While capable, it may be that this interface isn't quite what you need:  Perhaps you need an audio stream to feed somewhere else - maybe, to another computer that is decoding a mode that is not "built in" to the KiwiSDR or to record the goings-on on a certain frequency:  This is where the "kiwirecorder" comes in.

The kiwirecorder script makes a minimalist connection the the KiwiSDR, not requiring the user interface (display, waterfall, etc.) providing only a streaming audio connection with the frequency and mode specified in the connecting URL.  This stream may then be processed by another computer connected to it (locally and/or via the Internet) to do what it is that you wish to do.

Exactly how this works and its options are beyond the scope of this article, but the source code and documentation may be found here:

https://github.com/hcab14/kiwiclient

What is "kiwiwspr"? 

Note:  The "kiwiwspr" package has been renamed "wsprdaemon" as it is no longer specific only to the kiwirecorder package - see the addendum at the bottom of this posting.

While the KiwiSDR itself is capable of decoding WSPR transmissions, doing so takes a lot of its processing power and if there are many WSPR transmissions to be decoded within a passband - such as 20 or 30 meters during band openings - it may "miss" many opportunities if there isn't enough processing power to go through all of the latent signals.  Additionally, in a multi-user environment, having several WSPR decoders running simultaneously causes the normal user interface to slow noticeably - particularly with respect to the update rate of the waterfall display.

By "piping" audio to another, more capable computer, more effective WSPR decoding may be done by recording about 110 seconds of audio starting at the beginning of an even-numbered minute and then passing that file to the "wsprd" (wspr decoder) program which is part of the WSJT-X suite.  Using an outboard computer for this task minimizes the load on the KiwiSDR itself and with the faster, better hardware of the remote computer, more "in depth" processing may be done to allow the recover of more weak signals than may be possible with the KiwiSDR's built-in decoder - and be able to do so more quickly, with the latest version of the software.

Installing kiwirecorder and kiwiwspr 

The following assumes that you have a running Ubuntu Linux computer running on a network that has access to the KiwiSDR.  Ideally, such a computer would be placed on a local network, but this is not required.

• Be sure that the computer in question is reasonably up-to-date and has installed on it Python.  If Python is not already installed, the steps on doing so are readily found on the web. 

• The computer in question must have access to means of keeping the clock within +/- 2 seconds of UTC.  This is usually done by via NTP or similar.  If the computer's clock is not held to within a couple seconds of UTC, WSPR decoding will fail.

• It is highly recommended that the KiwiSDR's GPS antenna be placed outside in a location with a clear view of the sky and that its GPS lock is verified.  By supplying the KiwiSDR a valid GPS signal both its frequency and time may be held to good accuracy.

The steps:

• Log into the computer as the user that you wish to run the kiwirecorder and related software.  It is generally a good idea not to be logged in as a user with root access when you are running scripts.

• Install "kiwiclient" and change to its directory after install:
• git clone https://github.com/jks-prv/kiwiclient
• cd kiwiclient

•  Install Python dependencies for the scripts:
• sudo apt-get install python-pip
• sudo pip install numpy scipy
• (There are other ways to install "numpy" and "scipy", but the above works fine)

• Install wsprd (WSPR decoder for linux):
• sudo add-apt-repository -y ppk:ki7mt/wsjtx-next
• sudo apt-get update
• sudo apt-get install wsjtx
• Important: 
• If the version that you need isn't available via the repository and/or a new version of WSPR has recently released, it may not be available via the repository as an installation package.  To manually install a newer/different version, do the following:
• Download the most current binary that is appropriate for your system.  Binaries for the most common distros are typically found here:  https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
• In the example this package is called "wsjtx_2.0.0-rc3_amd64.deb", but you would choose the appropriate binary for your system.
• As of the time of this writing, only "1.9" is available via an install package and version 2.0 - which offers slightly better performance - has to be manually isntalled.
• Copy the binary to a directory on the target machine where you have access.
• In the location where you copied the file do:  sudo dpkg -i wsjtx_2.0.0-rc3_amd64.deb  (You would substitute the name of the file that you downloaded and copied to the Linux machine)
• You may get an error saying that "libgfortran3" is not installed:  This package may be installed thusly:  sudo apt-get install libgfortran3
• After you install libdfortran3, the wsjtx package may automatically complete installation, but if not (or if in doubt) try reinstalling it using the "sudo dpkg..." step, above

• Install bc:
• sudo apt-get install bc

•  Go into "tools" subdirectory (kiwiclient/tools)
• cd tools

• Find the newest "kiwiwspr" script and copy it to the "tools" director.
• While a version of the "kiwiwspr" script is included with kiwiclient, it may not be the newest.
• Go to this discussion on the ValentFX.com site and look near the end for the newest kiwiwspr script.   This same discussion also provides clues and help for troubleshooting.
• Make sure to CHMOD the new kiwiwspr script (if you updated it) to 774 so that it may be executed.

This should complete the installation.  The directory of interest will always be "kiwiclient/tools".

Let us assume for what follows that the kiwiwspr script is called (or has been renamed to) "kiwiwspr.sh"

• Execute the script once to get the "default" configuration file:
•  ./kiwiwspr.sh
• If all goes right, you will get a message stating that a "default" configuration file has been created.

• Copy the resulting file ("kiwiwspr.conf") and rename it as something else (e.g. "kiwiwspr.conf.original) so that you can refer to it later.

• Edit the file to include one's own specific KIWI information.  Each of the items below is required!
• At the top under "KIWI_LIST", enter the required information, separated by at least ONE space:
• "OurID" - Name of the KIWI (no spaces).  It is this name that will be used to refer to this particular KiwiSDR in the schedule described below.
• "IP:PORT" IP address (numerical) and the KiwiSDR's web interface port port (typically 8073)
• "Mycall" - the call by which WSPR decodes are reported:  This is the "reporter" callsign on wsprnet.org
• "MyGrid" - the 4 or 6 character Maidenhead grid location.
• "KiwiPassword" - This is the password, if any, to access the Kiwi if it is not public.  You must put the word "NULL" here if there is no password - it cannot be left blank.
• Note:  Several different KiwiSDRs may be defined in this table:  Each KiwiSDR's definition is as above, surrounded by quotes, on its own line.
• As an example, one might have entered, on its own line, the following:
• "my_kiwi 192.168.1.234:8073 w7xyz-1 cn01dc NULL"  This means that a receiver called "my_kiwi" can be reached via the IP address of 192.168.1.234, port 8073 and it will report to wsprnet using the callsign of "w7xyz-1" using the grid square of "cn01dc" and will not require a password.

• There may be a table labeled "CAPTURE_JOBS":  This is no longer used and it may be ignored.  (It's recommended that you leave it as-is for now if it is there.)

• There is a table called "WSPR_SCHEDULE" that defines on what frequencies, with which KiwiSDR instance and when the WSPR decoding "jobs" are to be scheduled in the following format, each on its own line with quotes:
• "time kiwi_name,first_band kiwi_name,second_band kiwi_name, third_band"
• Or, using the example above:
• "15:00 my_kiwi,80 my_kiwi,40 my_kiwi,30 my_kiwi,20"
• This would cause "my_kiwi" to start decoding WSPR on the 80, 40, 30 and 20 meter bands at 15:00 local time.
• You can also set the schedule relative to you sunrise and sunet time, the location of the sunrise/sunset being determined by the grid square that you entered.  This can be useful if you have only a limited number of audio instances available and you wish to favor the bands that are best in the daytime or nighttime.  Example of this are:
• "sunset-01:15 my_kiwi,80 my_kiwi,40"  - This would start WSPR decoding sessions on 80 and 40 meters at 1 hour and 15 minutes (e.g. 01:15) before local sunset as indicated by the "minus" sign after "sunset".
• "sunrise+2:30 my_kiwi,20 my_kiwi,15" - This would start the WSPR decoding sessions on 20 and 15 meters at 2 hours and 30 minutes after local sunset as indicated by the "plus" sign after "sunrise".
• If you wish, you may also specify UTC (GMT) instead of local time, in which case the you would add ",UDT" after the numerical time as in:
• "01:00,UDT my_kiwi,80 my_kiwi,40" - This would start the WSPR sessions on 80 and 40 meters at 0100 UTC.  Times relative to Sunrise/sunset would not apply here.

Options:

As of version 1-1g there is an optional variable that can be specified called "KIWIRECORDER_CLIENT_NAME".  One would include a link in the kiwiwspr.conf" file like this:

declare KIWIRECORDER_CLIENT_NAME=(
    "My_Kiwirecorder"
)

The above will cause the text "My_Kiwirecorder" to show up as the name of the use on the KiwiSDR instead of "kiwirecorder.py".  Do note that this needs to be placed at or near the top of the kiwiwspr.conf file or else it may not have an effect.

Bands/Frequencies:

Valid bands, their base RF frequencies and receive passbands are:

• BAND  DIAL FREQ  RF (carrier) Frequency range
• 2200     136.0kHz         (137.3-137.7 kHz)
• 630       474.2 kHz        (475.5-475.9 kHz)
• 160       1836.6 kHz      (1837.9-1838.3 kHz)
• 80         3568.6 kHz      (3569.9-3670.3 kHz)
• 80eu     3592.6 kHz      (3593.9-3594.3 kHz)  Deprecated - Usage to be discontinued.
• 60         5287.2 kHz      (5288.5-5288.9 kHz)  Not on a U.S. channel.
• 60eu     5364.7 kHz      (5366.0-5366.4 kHz)  Not on a U.S. channel.
• 40         7038.6 kHz      (7039.9-7040.3 kHz)
• 30         10138.7 kHz    (10140.0-10140.4 kHz)
• 20         14095.6 kHz    (14096.9-14097.3 kHz)
• 17         18104.6 kHz    (18105.9-18106.3 kHz)
• 15         21094.6 kHz    (21095.9-21096.3 kHz)
• 12         24924.6 kHz    (24925.9-24926.3 kHz)
• 10         28124.6 kHz    (28125.9-28126.3 kHz)

Notes about the bands/frequencies listed above:

•  The "80eu" band is still used in some parts of Europe and by other amateurs who have yet to change:  Use of this frequency is deprecated and will eventually cease.
• The "60" meter band reflects the available of that in much of the world while the "60eu" band is better-suited for use in many European countries.  Because 60 meter frequencies/channels differ, you should pick the frequency that reflects the geographical area of interest when it comes to receiving WSPR transmissions.  (Note that none of the listed 60 meter frequencies correlate with the channels available to U.S. amateurs.)
• The "Dial Freq" is that to which one would tune using USB while the "RF" frequency range is that which this script will use to "look" for WSPR signals.
• The audio band 1300-1700 Hz is used for decoding and offset should be applied to determine the actual transmitted/received carrier frequencies.  (e.g. for 40 meters, RF frequencies of 7039.9-7040.3 are in the passband.) 
• The detection bandwidth is 400 Hz instead of the nominal 200 Hz to accommodate "out of band" WSPR operation, frequency drift of your receiver and others' transmitters and the effects of the audio filters applied by the Kiwi.

If you get errors:

• If a package didn't install, you'll get errors indicating such.  Because there are many different possible scenarios with your operating system, I will not cover them here.  Remember:  Google is your friend when it comes to helping solve specific errors.
• If, when you run the "kiwiwspr" script, you get errors about missing elements, etc., these are typically due to data that is expected (like band) but is missing.  Re-check to make sure that:
• ALL of the required fields are entered in the "kiwiwspr.conf" file.
• That there are NO spaces within names or times.
• That there are NO spaces after commas
• That the line with the definition starts and ends with a double quote (e.g. " ) - even if the definition itself spans several lines.

Starting the script:

After installation, you should be in the "kiwiclient/tools" directory.

Assuming that the script is called, to start ALL jobs, do:

./kiwiwspr.sh -j a    - Start ALL jobs
./kiwiwspr.sh -j z    - Stop ALL jobs
./kiwiwspr.sh -j s    - Show running jobs

At this point there should be no errors and you should see "users" called "kiwirecorder.py" appearing on the KiwiSDR on the bands you specify for the most recent time before the current time.  For example, if it is 11:00 and you have two jobs - one scheduled for 09:00 and another for 17:00, the 09:00 schedule will be executed.

If all goes well, you should then start the watchdog, which will allow the schedule to be executed.  If you do not start the watchdog, jobs that were running at the time you started them will continue to run and they will not change according to the schedule.

The watchdog is started/checked/stopped with the following commands:

./kiwiwspr.sh -z a      - Start all watchdog jobs
./kiwiwspr.sh -z z      - Kill all watchdog jobs
./kiwiwspr.sh -z s      - Show watchdog jobs

Use "kiwiwspr.sh" with no arguments for more information about the above commands - and for more information.

If all goes well you will, after 5-10 minutes - assuming that your KiwiSDR is connected to a working antenna and there are signals on the (bands) that you have selected and you have Internet connectivity - start seeing WSPR reports on "wsprnet.org" using the callsign specified in the "MyCall" field in the "kiwiwspr.conf" file in the "KIWI_LIST".

Remember:  A WSPR receiving interval starts at the beginning of each even minute and runs for almost 2 minutes.  It will then take another minute or so for wsprd to decode the WSPR transmissions and forward them to wsprnet.org where they may be displayed.

Final comments:


Remember that the above steps are for an up-to-date Ubuntu Linux distro running on a PC platform and there may be differences in how to install it on other distros/hardware platforms.  If you encounter difficulties, I probably won't be able to help:  I'd just do what you could do in that situation, and that is to refer to Google for a solution to the same/similar problem.

I would like to thank Rob Robinett for his hard work in producing the kiwiwspr script along with John Seamons for his very hard work on the KiwiSDR itself and making the "kiwirecorder" package available.

Best of luck!

* * * * * * * * * * *

[8 February, 2019]

Update:  "kiwiwspr" is now "wsprdaemon"

The "kiwiwspr" package has since been renamed the "wsprdaemon" package as its usefulness has been expanded beyond simply using a KiwiSDR.  As of the time of this update (8 February) its "new" capabilities include:

• Elimination of "duplicate" reception reports from "dirty" transmitters or from modulation caused by noise blankers:  Only the strongest report is used.
• Allowing the use of multiple receivers sharing the same frequency.  This is useful if one has several antennas and wish to submit only the report of the "best" signal of the lot.
• Using audio from a receiver via a sound card.

Even more features may have been added since this page was updated.
 
The configuration of the "multi receiver" aspect is documented in the "wsprdaemon.conf" that accompanies the script while the use of an audio input is beyond the scope of this document.

The modification has required some changes to the way the wsprdaemon package is installed as compared to old "kiwiwspr":

• The "~/wsprdaemon" directory is created and the wsprdaemon .sh and .conf files are put into it
• A "/dir/tmp/wspr-captures" directory is created.  If using a Raspberry Pi, this directory should use tmpfs file system or else you will "wear out" the SD card.  If using a computer with an SSD, you may still consider doing this.
• Use CHMOD to make sure that the wsprdaemon.sh file may be executed
• The configuration from the old "kiwiwspr.conf" file may be copied to, "wsprdaemon.conf" but the array "KIWI_LIST" should be renamed "RECEIVER_LIST".
• The newer "wsprdaemon.conf" includes a the ability to define in RECEIVER_LIST a virtual receiver consisting of several receivers.  If more than one receiver decodes the same transmission, only the reception with the best report is used.  (Even if a single receiver is used, this eliminates multiple reports as noted above.)
• For example, if you have defined "RX1" and "RX2" you can define "MERGED_RX1" as using "RX1" and "RX2".  One can use that virtual receiver name (e.g. "MERGED_RX1") in the scheduling and band definition.
• If you have previously been using "kiwirecorder", copy its directory tree into the "~/wsprdaemon" directory.
• If necessary, rename it from "~/wsprdaemon/kiwirecorder" to "~/wsprdaemon/kiwirecorder-jks-v0.1"
• To start wsprdaemon, use "./wsprdaemon -a"
• To stop wsprdaemon, use  "./wsprdaemon -z"

This page stolen from ka7oei.blogspot.com

[End]

Reducing RFI from the Tesla Powerall 2

This is a follow-up of a previous article:  "Does the Tesla Powerwall 2 produce RFI (Radio Frequency Interference)?". 

There is a newer article about my experience of RF interference to a Powerwall:  Tesla Powerwall RF sensitivity to RF transmissions - and how to deal with it.

Figure 1:
A typical Powerwall 2 installation.
Left to right:  Utility meter/original load center fed from an underground
power feed, the"new" load center to which the household circuits now
connect, the Powerwall "Gateway" (with two 4G antennas on top
 - not used in my installation), AC disconnect for the
Powerwalls, sub-panel for the Powerwalls (containing
a circuit breakers for each unit) and finally, the two Powerwalls.
This type of system is typically installed outside, near the utility's
connection to the house.
Click on the image for a larger version.

This article contains a bit if information that was original in that previous article, but has been separated and updated.

The information that follows may also be useful for interference reduction of other types of power systems that have been found to generate radio frequency interference, such as grid-tie inverters and other "battery back-up" systems that function like the Tesla Powerwall.

Note that RFI that is radiating directly from solar devices such as microinverters and optimizers require different mitigation techniques - See the blog post "The solar saga - part 1: Avoiding interference (Why I did not choose microinverters!)" for links to information about reducing this type of interference.

As a follow-on to the article "Does the Tesla Powerwall 2 produce RFI (Radio Frequency Interference)?" , this post describes some of the mitigation techniques to knock down what little interference the Tesla Powerwall might produce.

A recap:  Does it produce RFI?

But first, a possible spoiler.

The answer is:  It depends - but the fact that this article exists should have been a big clue.  In short:

• When it is neither charging or discharging:  No interference at all on any band.

This means that if it is charging or discharging, you may expect the following in terms of interference: 

• On the 80 meter amateur band and higher frequencies:  Not that I can tell.
• On the 160 meter band, AM broadcast bands and lower amateur bands:  Maybe.

As the original article notes, I couldn't detect any RFI on 160 through 10 meters when I was using a wire antenna, but I did detect some minor RFI on 160 meter when using an E-field loop - but that represents almost a worst-case scenario.  In the case of the 630 and 2200 meter amateur bands - both of which are below the AM broadcast band - the interference from the Powerwall 2 (prior to mitigation) is likely to be noticed.

Although I did not explicitly in my case, in my estimation the amount of radio interference ("QRM") emitted by a Powerwall on HF is low enough that it would be undetectable at any reasonable distance in a location not directly connected to the Powerwall's circuits.  In other words:  If you have a next-door neighbor that has a Powerwall, I would be extremely surprised if it was detectable on HF at all, particularly if your HF antenna was a reasonable distance (tens of feet/meters) away from it.

Mitigating interference from the Powerwall 2:

If we were dealing with a normal switching power supply, the mitigation of interference would be quite straightforward:  Apply "brute force" L/C filters to all of the AC connections in and out of the device - a topic that has previously been discussed in great detail at this web site (see the links to related articles at the end of this blog posting.)

Applying filtering to a plug-in device that is capable of up to a kilowatt or two is one thing, but mitigating interference issues on a device that is permanently wired in to the house's electrical system and capable of tens of kilowatts is an entirely different matter!  For example, my Powerwall 2 system consists of a two battery/inverter modules that, together, are rated for 14 kW for brief periods, or over 10 kW continuously, representing over 58 and 41 amps at 240 volts, respectively.


To afford a wide safety margin any added inductive filtering would need to be capable of handling at least 100 amps with any capacitors being conservatively rated for the voltage.  Finding and installing a commercially-available AC mains filter with such ratings could be difficult, expensive and awkward, probably requiring a separate enclosure - not to mention appropriate sign-off by inspectors.  What's more is the fact that on a battery-inverter system like this, two such filters would be required:  One on the AC mains feed-in from the utility to the Powerwall and another on the AC mains feeding the house coming from it.

A more practical solution - and one that works effectively for 160 meters - is to install snap-on ferrite sleeves on these six conductors (e.g. the two "hot" phases and the neutral for each of the lines.)  It so-happens that readily-available devices that will fit over RG-8 coaxial cable will also fit nicely over power cable that is appropriately sized for 125 amp circuits.  (The dimensions of these devices is approximately 1.55" [39.4mm] long, 1.22" [31mm] diameter and are made to accommodate cables up to about 0.514" [13.05mm] - but could be modified to go over cables that are nearly 0.6" [15.24mm] diameter).

For exclusively HF, the so-called "Mix 31" ferrite material a reasonable choice, each device providing equivalent resistance as follows:

• 1 MHz:  25Ω
• 5 MHz:  71Ω
• 10 MHz:  100Ω
• 25 MHz:  156Ω
• 100 MHz:  260Ω
• 250 MHz:  260Ω

I used two of these devices on each of the leads (for a total of 12) which, at 160 meters, would provide an equivalent of about 60Ω of resistance.  Considering that there are 3 leads per feed, this parallel resistance is roughly equivalent to 20Ω per feed, so for 160 meters a bit more "help" may be required, so I also used some "Mix 75" ferrite devices of the same size - also two if each per lead.

Intended for lower-frequencies, the equivalent resistance of each of these devices is:

• 200 kHz:  20Ω
• 500 kHz:  58Ω
• 1 MHz:  102Ω
• 2 MHz:  70Ω
• 5 MHz:  50Ω

Figure 2:
Beneath many of the boxes is a raceway/channel that contains some of the
conductors, including data lines and, as depicted above, the wires coming
from the utility mains, connecting to the Powerwall's gateway.  In
my installation there are no exposed conductors in this raceway and there
is plenty of room for the installation of the ferrites.  The marked ferrite
devices are the "Mix 75" while the unmarked are the "Mix 31."  While
it probably doesn't make a difference, I placed the Mix 75 ferrites on the
end of the leads closest to the Powerwall in the unlikely event that low-level
harmonics are generated in the Mix 75 ferrites that need to be attenuated
by the Mix 31 ferrites.  Placing large ferrites over all three conductors
at once for common-mode filtering would be preferred, but doing so
is not always practical as discussed below.
Click on the image for a larger version.

As can be seen, for covering 160 meters and higher frequencies a combination of both types of devices is suggested.  At 1.8 MHz, it is estimated that total equivalent resistance on each lead of the four devices (two Mix 31 and two Mix 75) will be on the order of 220Ω, or about 73Ω for each of the three sets of wires in parallel.

Warnings:

At this point, there are a few "weasel words" that I must include:

• While it is possible to put these ferrite devices (or anything at all!) inside the Tesla Powerwall's gateway box, doing so would probably require the "official" permission of Tesla's engineering department to avoid the possibility of voiding a warranty/service agreement.  Because of this, it is better to mount them on the conductors outside the gateway.  Filtering could also be installed at the disconnect and/or circuit breaker between the Gateway and the Powerwalls, but this, too, may require appropriate approval and sign-off by Tesla engineering to avoid warranty issues.
• Placing any ferrite devices outside the Gateway box will not affect its operation and would be less intrusive than, say, installing a whole-house surge protector as no physical connections are being made.  Because of the wide difference between the mains frequencies (50/60 Hz) and the lowest RF frequencies of interest (136 kHz-1.8 MHz) for which these devices are designed, these ferrites will have no measurable effect at mains frequencies.
• The installations described below involve the exposure of high voltage, high-current circuits inside a breaker panel.  DO NOT even think of opening such a panel when it is "live", let alone installing any such devices inside it.
• DO NOT even think of installing such devices in a panel - even if it is powered down - unless you have experience working with electrical circuits.  If you do not have such experience, refer to a licensed electrician to install such devices.
• Where I live it is permitted for me (the homeowner) to make modifications to the home's electrical system, but it is up to YOU to determine the safety and legality of any sort of modification of your electrical system and determine if you are competent to work with it.  Do not presume some/any of the described modifications to be legal or in compliance of safety regulations in your (or any) jurisdiction!
• I cannot be responsible for injury or damage and no warranties as to suitability or safety should be implied related to the content of this and related pages.  You have been warned!

Installation:

First off, note that all of the units (the two Powerwalls, breaker panels, etc.) in my installation are connected together with metallic conduit and if properly installed, this conduit will quite effectively bond all of the various boxes together electrically.  This means that it is likely to be quite effective in both preventing direct radiation of RF energy from the contained conductors as well as minimizing differential RF currents between the various boxes.

What this de-facto shielding will not do is stop RF from being conducted on the wires that leave this system - notably those that go into the house or to the power utility.  In my case, mains power is fed from underground which means that the most likely source of interference from the Powerwall is likely to be conducted into it from the main breaker panel and onto the house wiring.

Visible in Figure 2 (above) is a channel that runs underneath several of the boxes and in this channel are the conductors that, in my installation, go from the utility mains panel to the Powerwall's Gateway - and I installed one set of the ferrites (a total of 12 devices) in it as depicted in Figure 2.  Because there are no exposed electrical connections in this channel, these devices can be safely installed without turning off power.

Vibration prevention:

These ferrite devices are, by their nature, quite ferromagnetic and as such the magnetic field associated with the AC current flowing through the wires over which they are slipped will cause mechanical movement.  When I installed the first of these devices I could hear them buzzing slightly, the apparent result of the two halves of the ferrite moving with respect to each other.

Figure 3:
 This is a view inside my main house's breaker panel with the "dead front"
cover removed.  In the upper-right corner is a 125 amp circuit breaker that is
the main feed-in from the Powerwall Gateway (the partially-visible box to the
right) which can carry the power from the utility and/or from the Powerwall.
The space for these ferrite devices is a bit crowded, but they do fit.
As noted in the warning, this panel has exposed, live connections and you
should not even think about working in it unless you have experience
in working on electrical systems and the power is turned completely off!
Click on the image for a larger version.

To prevent this movement - and the possible damage of the ferrite devices over time due to this constant motion - I spread an extremely thin layer of clear RTV (silicone) adhesive across the mating surfaces of the two halves to bond them gently together.  These devices have two mirrored halves of the ferrite that, when assembled, touch each other and are polished smooth, so one need only barely "wet" their surfaces with the slightest film - only the tiniest fraction of what would be used normally, an amount so small that it looks somewhat like an oil slick is sufficient for the polished surfaces.

Alternatively, a small drop of cyanoacrylate (e.g. "Super Glue") could be used, but unlike RTV, this would make removal difficult were it required in the future!  Adding anything between the two, polished halves of the ferrites will reduce their effectiveness somewhat so it is important that the two surfaces be as close to each other as is possible by using the smallest amount of RTV.

Installation in the main breaker panel:

In my installation there was another location at which these ferrites were to be installed:  On the power feed from the Powerwall to the household circuits where the majority of RF noise is likely to be conducted - but instead of being in a raceway where there are no "live", exposed connections, the only place that this wiring appears is in the main circuit-breaker panel.

It should be noted that some ferrite mixes can be slightly conductive which means that the material itself should not be allowed to touch any metal that may carry a voltage.  The "snap-on" devices have plastic covers that effectively insulate the ferrite within, but this should be noted if "bare" toroidal cores are used:  Good-quality polyester tape is likely suitable to provide good insulation and protection.

Figure 3, above, shows the installation of the ferrites on the conductors within the breaker panel.  As can be seen, there are "live" exposed connections that pose a shock hazard which means that these devices can be safely installed only if the power is turned completely off.  As was done with the other devices, an extremely thin layer of RTV was put on the mating surfaces of the ferrites' halves to prevent their buzzing.

Comments:

It would be preferable to be able to wind several turns of the large power cables together through large ferrite cores (such as toroids) to achieve much higher effective resistance at the frequencies of interest, but this is simply not possible in the available space with the existing wiring.  Because the conductors were already in place and routed, it was deemed to be too awkward to disconnect one end of the (heavy!) cable to allow ferrite devices to be slid over it, so "split" devices were used instead.

If one is starting from "scratch" - or has the ability to add it later with some rewiring - enough extra cable length added to allow the winding of multi-turn chokes through large ferrite (toroidal) "non-split" cores inside a dedicated, metal junction box would be desirable.  Doing this can greatly increase the series inductance and provide a commensurate reduction of conducted RFI.

It would also be preferable to pass all of the power cables through the center of a single ferrite (of ferrites) as a single bundle to provide a "common mode" impedance path, but this is difficult to do as I have not found a source for split ferrites of 31, 75 or 77 mix that would accommodate three cables that are about 0.5 inch (approx. 12 mm) diameter.  The obvious alternative would be to pass the conductors through a stack of adequately large ferrite beads/cylinders or toroidal cores, but doing this would require that the conductors be disconnected from one end and temporarily pulled back.  The preference would be to have this done at the time of the original installation, particularly if several turns could be passed through some large cores, but again, this is much harder to do after the fact, particularly with the limited length of wire in an already-installed system.

If you are able to put all of the wires with the ferrite cores in a single box, it is a good idea to keep the "input" and "output" wires (e.g. "before" and "after" the ferrite) away from each other - and from other conductors and ferrite devices as well.  If the "clean" and "dirty" (from an RF standpoint) wires are run together in the same conduit, it is possible that RF energy could couple from one to another and partially negate the effects of the RFI mitigation.  Note also that the wires themselves - and the ferrites - of different sets of wires should be kept apart to prevent capacitive/magnetic coupling as well - but only a few inches/cm of distance should suffice.

Finally, while there is plenty of room in the raceway to accommodate the bulk of a number of these cores, there is much less available space within the cramped confines of the breaker panel to accommodate a large stack of ferrite rings/sleeves, particularly if one were to wind several turns of wires through them.  If you are contemplating a brand new installation, or if you are willing to pull wire out and do mechanical re-work, by all means put several turns of the three wires (both "hot" and the neutral leads) through common cores to maximize common-mode impedance.

Other RF interference paths:

In addition to the power connections to/from the Powerwalls, there are two other possible egress paths for radio frequency interference.  I did not check to see if they were sources of radiated interference, but I assumed that they would be.

Figure 4:
Also contained in the raceway is the CAT 5/6 cable for the Ethernet
cable that provides the Powerwall with internet connectivity.  In my
installation there is also another data cable that goes to current/voltage
monitoring equipment (the Neurio) where the PV (solar) equipment feeds
into its sub-panel.  Multiple turns and conductors of wire were fed
through several ferrite devices to choke any RF that might egress.  The
upper device consists of three square snap-on ferrite cores while the bottom
device is the ferrite core from the yoke of a scrapped CRT computer
monitor.  Not shown are additional multi-turn chokes wound on ferrites at
the "other" end of these same cables to prevent interference to those devices.
Click on the image for a larger version.

• The Ethernet connection from the Gateway.  It is common to "hard wire" a CAT5/6 cable from the Powerwall's Gateway to an Ethernet switch (behind a firewall) to provide internet connectivity.  While an Ethernet interface is, by its nature, galvanically isolated from its support circuitry, it does have some capacitive coupling.  It is possible to wirelessly (via either WiFi or via a cellular network) connect the Powerwall to the Internet - which would avoid such cabling - so one would have to determine the nature of the specific installation.  (Note:  Some Powerwall owners report issues with connectivity when using a wireless connection so a direct, wired connection is best.
• Serial power cable to voltage/current monitoring.  A typical Powerwall 2 installation uses devices made by Neurio to monitor the voltage and current at both the connection to the power mains and at the PV (solar) electrical connection.  While a wireless connection between some of these devices is possible, there may be a (more reliable!) 2-wire (half-duplex, RS-485 serial) connection between some of these devices and RF egress could occur on this cabling as well.  (I originally had a wireless connection to the Neurio, but it was unreliable at the required distance.)

In my case I have both an Ethernet cable going to my firewall/router and a wired RS-485 connection to the Neurio monitoring the PV system.  To reduce the possibility of either of these lines conducting RF energy into a circuit that might radiate, the two cables were put together and wound through several ferrite devices as shown in Figure 4.  The upper devices are square, snap-on ferrite chokes while the lower device is the mass of ferrite from the CRT yoke of a discarded computer monitor.  The use of several devices and multiple turns greatly increases the effective inductance of this coil and its effectiveness overall.

Figure 5:
EMI capacitors in panel.  These are 4 uF at 600VAC
"pulse-rated" plastic units specifically designed for
filtering of noise in high-current AC circuits.  Each of
the wires on top go to a circuit breaker with one capacitor
for each phase of the circuit.  The bottom lead connects
to the ground bus and, eventually, the metal junction box.
Only high-current "pulse" type capacitors along with
 circuit protections should be used in this application.
Click on the image for a larger version.

While using ferrite devices on CAT5/6 cable will not normally affect the high-speed Ethernet signals within, CAT5/6 cable should not be coiled extremely tightly as doing so will distort the geometry of the twisted pairs and the integrity of the signals.  While this is unlikely to have much of an effect on 10 or 100 Megabit connections unless the cable is very tightly wound, it can degrade a "Gig-E" (1 gigabit) Ethernet connection (the Powerwall only uses a 100 Mbps connection) if the coil is smaller than 3-5 inches (about 8-12cm) in diameter or if the outer jacket of the Ethernet cable is "kinked".

Adding RF bypass capacitors:

As mentioned above, I did (later) add some RF bypass capacitors to the system:  Two capacitors (one for each phase) on the "house" panel connected to the output of the Powerwall and another pair of these same capacitors on "utility" side of the world in the original distribution panel.  These capacitors are 4uF plastic film units designed specifically for bypass and pulse service and are rated for at least 630 volts AC.  Their connection to the power bus is made by dedicated 15 amp circuit breakers and the other end of these capacitors is to the ground bus inside the panel - See figures 5 and 6.  In theory, the 4uF capacitors will present around 660 ohms at the 60 Hz mains frequency, implying a current of 180mA through each at 120VAC for a total of about 22VA, but since this is reactive-only, no heat will be generated.  This high capacitance was chosen for its ability to effectively shunt energy at 137 kHz where its reactance will be on the order of 0.3 ohms, although the overall reactance+resistance of the leads and circuit breakers will be higher than this.

Figure 6:
Added breakers to connect EMI capacitors to the panel's
power bus.  Using a separate breaker for each capacitor
is the easiest and safest way to connect the it to the
main bus bar in the panel.
Click on the image for a larger version.

Installation of these capacitors significantly reduced the amount of inverter noise present on 630 meters and "noticeably" reduced it on 2200 meters.  Eyebrows might be raised about the rather long lead lengths to connect these capacitors - both on the "ground" and the "hot" side, but this could not be helped.  At these low frequencies (e.g. <500 kHz) this isn't as critical as it might be at HF, but lead length should be minimized.

Another pair of capacitors (not shown in the attached pictures) was similarly installed in the breaker panel that is on the "unprotected" side of the isolation switch:  Whereas those in the picture are on the "house" side of the Powerwall, the others are on the "utility" side.

Comment:

In the U.S., electrical code typically requires wiring of electrical circuits inside a grounded metal enclosure with a large bus bar for carrying the current from the (usually) two phases found in residential wiring - which is likely going to be a 240 volt, center-tapped source from the utility's mains transformer.  In North America and some other places, "small" items (up to about 1800 watts) are powered from a 120 volt circuit against the common "neutral" wire (the center-tap) while larger items will operate from a 240 volt circuit in a balanced fashion.

In many other parts of the world there is a single neutral connection to the house and a 240 volt "hot" wire which means that one would need only apply interference mitigation to these two wires instead of three as depicted elsewhere on this page.  It is also possible that in some areas electrical codes may not require an enclosure that provides a convenient common power "bus" and large ground plane (e.g., metal enclosure that also acts as a shield) per se, requiring different techniques to apply the described mitigation.

The results:

While it may be a bit of overkill, the addition of the two types of snap-on ferrites (e.g. two of each type on each conductor for a total of 24 snap-on devices) has reduced the interference on 160 meters to the point of inaudibility - and pretty much the same thing on 630 meters.

On 2200 meters the interference is significantly reduced - only being "just visible" that band as the spectral display below shows.

Figure 7:
Annotated spectral display showing the harmonic (and other) energy from various devices, including the Powerwall 2 after the described RFI mitigation techniques.
Click on the above image for a larger version

This graph in Figure 7 shows the frequency range from 0 through 250 kHz, a range that is entirely below any HF or MF amateur band, but includes the 2200 meter amateur band near 137 kHz.  As can be seen from this, harmonics from the Powerwall 2 (which appears to have a fundamental frequency of 32 kHz) are pretty much gone by 250 kHz.

This spectral display also depicts the harmonics from a pair of SunnyBoy grid-tie inverters (only the first several harmonics of the 16 kHz switching frequency are even visible) plus some rather strong harmonics from a plug-in switching wall-wart that operates at a fundamental frequency of about 73 kHz:  It is this wall wart - and (potentially others like it) that is likely to cause more QRM to reception on amateur bands than the Powerwall 2!

To completely quash interference at the 2200 meter frequency (around 137 kHz) it would probably be necessary to increase the inductance in the offending leads  between each of the three conductors (ground, L1 and L2) even more than has been done with the ferrite devices.

What about RF interference to the Powerwall? 

The Powerwall itself is a computer-based system with a number of analog monitoring points and as such, it is theoretically possible for external RF to cause it to malfunction if that energy somehow "glitches" one of its computers and/or causes one or more of its many sensors to read incorrectly.  To provide protection, the Powerwall is designed very conservatively and in the event of a serious discrepancy or fault, it will shut itself down.

The question should be asked:  Is it possible for external RF to cause such a shut-down?

The answer is:  Maybe. YES

There is a newer article about my experience of RF interference to a Powerwall:  Tesla Powerwall RF sensitivity to RF transmissions - and how to deal with it.

About a week after my Powerwall was installed and running I happened to tune up on 40 meters using my 1.5kW amplifier.  While I was doing this, the power to my entire house "blinked" several times and went off with the Powerwalls indicating some sort of error condition.  Unfortunately, the isolation relay had tripped and my house was disconnected from the mains and the Powerwalls did not reset themselves even after turning them "off" for over 15 minutes.  After a bit of hassle, I was able to get the Powerwalls reset - but the question remained:  What happened?  I opened a ticket with Tesla support and they came out to investigate a few days later.

It was determined that a possible cause of this "loss of power" event wasn't due to RF, but instead due to arcing at one or more connecting clamps on the mains side of the isolation relay in the gateway that had not been properly tightened when it was installed.  The extra 2+ kW of load on the AC mains from the RF amplifier may have been enough to cause arcing in that loose connection and the Powerwall, detecting this as a potentially dangerous fault (as arcs can be!) killed all of the power for reasons of safety.

Since the clamps were tightened I have never been able to recreate this event, but being "gun shy" I immediately started installing the various ferrite devices on the power and data communications cables - not only to keep RF interference from the Powerwall from radiating, but also to prevent RF from getting in.  In other words, if it had been sensitive to external RF before, it certainly is not sensitive anymore, now that I made the above additions!

Parts sources: 

There are several sources of snap-on ferrite devices described on this page, including:

• KF7P Metalwerx - link - Supplier of a variety of Ferrite devices and many other things.  At the present time he stocks the "Mix 31" devices, but does not stock "Mix 75" snap-on cores at the time of posting.

• Mouser Electronics - link - The "Mix 31" snap-on cores - P/N:  623-0444164181  (Fair-Rite P/N:  0444164181);  "Mix 75" snap-on cores - Mouser P/N:  623-0475164181  (Fair-Rite P/N: 0475164181).  Mouser Electronics has other sizes and mixes of these various devices.  Also obtained from Mouser Electronics were the Kemet 4 uF, 600 VAC "pulse" capacitors Mouser P/N:  80-C4GAMUD4220AA1J (Kemet P/N:  C4GAMUD4220AA1J) depicted in Figure 5.

Links to other articles about power supply noise reduction found at ka7oei.blogspot.com:

• Containing RF noise from a "pure" sine wave UPS.   Even when it is not operating your sine wave UPS may be producing a lot of HF radio interference!
  
• Completely containing switching power supply RFI - link.  Sometimes it can be difficult to quiet a switching power supply, so it may be necessary to put it in a box with strong filtering on all of the conductors that enter/leave.
• Minimizing VHF (and HF) RFI from electronic ballasts and fluorescent tubes - link.  Electronic light ballasts, like many switching power supplies, operate in the LF frequency range so "cleaning them up" at VLF/LF/MF frequencies can be a challenge.
• Quieting high current switching power supplies used in the shack - link.  This page describes techniques that can be used to reduce the amount of RF energy produced by switching power supplies that you may be using to power your radios.  Again, higher-inductance chokes may be required at VLF/LF/MF frequencies.
• Reducing switching supply racket - link.  This describes techniques that can be used to beef up the filtering for switching supplies in general.
• Quieting an insanely noisy LED floodlight - link.  This describes how a constant-current LED supply that produced enough interference to quash HF reception was quieted down to the point of undetectability.

Other solar power related posts at ka7oei.blogspot.com:

• Teasing out the differences between the "AC" and "DC" Powerwalls - link.  In this post I discuss generally how "AC Battery" systems like the Powerwall and how they work as well as the general differences between the so-called "DC" Powerwall and the AC Powerwall.
•  The solar saga part 1: Avoiding Interference (Why I did not choose Microinverters) - link.  Having had first-hand experience observing a microinverter-based PV system, I discuss why I went the route of the series-string inverter. 
• The solar saga part 2: Getting the system online - link. Like most large projects something intervenes that it makes it take longer to complete - and that was the case here, but it was successfully completed... eventually!

This page stolen from blogspot.ka7oei.com

[End]