Wednesday, November 14, 2018

Tesla Powerwall RF sensitivity to RF transmissions - and how to deal with it.

This article is about my experience in causing RF interference to a powerwall, but I have written on two other articles about amateur radio operation along with having a Tesla Powerwall - these articles may be found here:
Figure 1:
Left to right:  Back-up Gateway (BUG), disconnect, two Powerwalls.
The cable raceway is just out of view, below the BUG.
 The BUG controls everything and was likely being bothered by RF
energy conducted to it via the Ethernet cable.  While it is possible to
connect a Powerwall via wireless, the reported experiences of other
Powerwall owners is that this method is less reliable in
the long term than a hard-wired cable.
Click on the image for a larger version.
In the first article above ("Reducing RFI from the Tesla Powerwall 2) I mentioned that I may have had an experience with RF interference to the Powerwall - but that the circumstances were inconclusive:  There was another problem that may have caused the symptoms (e.g. one of the mains connections' clamps had not been tightened at the time of installation).

This time, I do have a tale to tell about radio frequency interference (RFI) to my Powerwall 2 system.

The history:

Years ago, because it was convenient, I placed my DSL modem in my ham shack. Other than low-level spurs from the modem's plug-in power supply (wall wart) which were easily solved, it never caused any problems - nor would my HF operation seem to bother my DSL modem - except on 160 meters when I ran more than about 50 watts.  I found this remarkable because the wire from the DSLAM (the distant interface from the phone company) came through the window only about a foot away from the windowed transmission line that carried the transmit RF power to the antenna.  At some point I dropped the POTS (Plain Old Telephone Service) dial-up in lieu of VOIP and at the network interface (the box outside the house) I disconnected the internal house wiring as it was no longer needed, back-feeding this internal wiring from the VOIP box to allow the continued use of the phones.

Several years ago I got a linear amplifier capable of full-legal power (1500 watts in the U.S.) to use on the HF bands to assist when conditions were poor and on some frequencies this high-power operation would cause intermittent drop-outs in Internet connectivity when I transmitted.  It seemed that the longer I operated, the fewer these drop-outs were, possibly due to the modem "re-training" itself to deal with the (apparently) degraded connections.

When I got the Powerwall its Ethernet connection came through the outside wall and into the house near the DSL modem as it was a convenient place to make the connection - and a UPS was nearby.  I recently decided to relocate the DSL modem to another room, one farther away from the ham shack and closer to where the underground wire from the telephone company came into the house and this involved a bit of additional wiring of Ethernet cable, and since my entire house is effectively on a UPS (via the Powerwall) it didn't matter where I plugged it in now.

Without the DSL modem in the shack I installed another Ethernet switch to manage the multiple connections that were made at that point:  One to the shack computer, another to the garage's Ethernet (to provide Internet connectivity of the solar inverters), another to a KiwiSDR and yet another to another switch where even more things were connected.  Also on this switch is the Ethernet connection to the Powerwall.

On the blink:

I'd done the relocating of the networking gear earlier in the afternoon about a week and a half ago and it wasn't until that evening when I got around to tidying things up slightly and putting a transmitter on the air - in this case, my 630 meter (472-479 kHz) station - to make a few contacts.  When I keyed the transmitter - which produces about 75 watts of RF - the lights in the house dimmed, a UPS beeped and the lights went bright again - so I quickly un-keyed.

After swearing to myself and hoping that this was a coincidence I waited for a minute or two and tried again - with the same result:  The power flickered, the UPS beeped and the lights went back to normal.  Bringing up the Tesla app I looked at the Powerwall's back-up history and saw that I now had two outages, each less than 30 seconds:  That in itself was unusual because the Powerwall typically stays off the grid for a couple minutes even after utility power returns to make sure that the it is stable.

"$#!+", I thought to myself again!

I then powered up the HF station.  Things were OK on 75 meters at 100 and 1500 watts and things were also OK on 40 meters at 100 watts - but I triggered the same "blink" response at any power level above about 600 watts.

Now began the methodical investigation.  The first thing that I did was to disconnect the Ethernet connection to the Powerwall from the switch that I had just installed:  No problems at all on any frequency or power level.

This was getting interesting:  Why would connecting the Ethernet cause a problem?

Ethernet connections are supposed to have galvanic isolation via a transformer!  To be sure, there is a small amount of capacitive coupling between the two windings, but this was on the order of a few 10s of picofarads - not nearly enough to cause a problem at 630 meters - or so one would think!

I then grabbed another Ethernet switch - a small, in expensive Linksys 5-port switch and connected everything to it:  No problems.
Figure 2:
Inside the raceway where several cables - including the Class-2 Ethernet
RS-485 cables for the Neurio run.  This picture shows the bonding of the
CAT-5's shields to the raceway (yellow tape and the blue wire that connects
to a mounting screw of the raceway using a spade lug and star washer). 
Also visible are some snap-on RF chokes (round gray, square black).
As mentioned, simply grounding the shield did nothing to solve the RF
ingress issue since the energy was being conducted on the cable's internal
wires already:  It took the addition of the chokes here and elsewhere (see
the other photos) to reduce the level being conducted on the Ethernet cable.
There are no exposed conductors in this raceway so it is "safe" to work in.
Click on the image for a larger version.

At this point I may have been able to get away with using that small, cheap switch, but it was very old and it was "only" a 100 Mbps-capable switch which meant that it would be a bottleneck for traffic between computers.  I was also determined to make it such that I it would not matter to what I connected the Powerwall's Ethernet cable as I wished to avoid a future problems should I forget why it was there!

When shielded cable doesn't help:

A bit of investigation revealed that the CAT-5e cable to the Powerwall was shielded.  One might first think that this should have solved the problem - but you'd be wrong

Shielding is useful for containing energy within the cable and prevent it from radiating, but if the cable in question is, itself, longitudinally conducting RF energy from one place to another, this shielding has absolutely no useful effect on its own!  In other words, if a piece of equipment at one end is somehow allowing RF to be induced onto the Ethernet cable, shielding will do nothing at all to prevent the conduction of RF to the far end - and it may well make it worse!

Still, the shield might prove useful to allow shunting some of the RF current on the shield so out of due diligence I went outside to the electrical raceway below the Powerwall where the conduit - which is all metallic and bonded to everything else, including the Powerwall - that conveyed the Ethernet cable from the house.  There, I carefully opened the outer jacket of the cables and made a connection to the shields which I then bonded to the metal raceway as depicted in figure 2.

Figure 3:
Inside, showing both the cable that goes between the Powerwall and the
Neurio in the garage (the left-hand cable with the two white snap-on chokes
in a loop) and the Ethernet cable that connects between my switch and
the Powerwall.  The Ethernet not only has two of the white snap-on chokes,
but it several turns are also wound through a Mix 75 toroidal core, seen
near the upper-right corner of the picture.
While this was enough to stop RF susceptibility issues on the HF bands,
these devices did not offer enough choking inductance on the Ethernet
cable to prevent problems at 630 meters.  Another Ethernet choke was
wound on another Mix 75 toroidal core - See Figure 4.
Click on the image for a larger version.
Because I had previously installed some Ferrites on the Ethernet cable and the other (shielded) CAT-5 cable that made the RS-485 connection to the Neurio in my garage I was hoping that this bonding - and the self-capacitance of these cable, both of which were now bonded - would shunt the RF energy to it and solve the problem.

It didn't.

No surprise there.

I decided to get serious about the problem and started checking the ferrite devices that I'd previously installed.  Winding a few turns on each I measured the inductance and found that they did provide a reasonable amount of reactance at 40 meters - typically 5-10 microHenries which provides between 200 and 400 ohms of impedance at 7 MHz - but clearly, this was not enough as I was still having problems at 7 MHz.  This would be especially true at 630 meters where the reactance would be only a few 10s of ohms - hardly enough to significantly impede RF energy at that frequency.  I then began to rummage about through my collection of ferrites, running a few turns of wire through each.

It became clear that the devices that I had previously used were typically of "Mix 43" or similar, best-used for the higher HF frequencies (and into VHF):  A few turns through one of these will give 10-ish microHenries of inductance, but I needed far more than this so I switched my attention to finding "Mix 75" and "Mix 77" devices - ferrite material that had an order of magnitude or so more permeability and would also yield much higher impedance:  A few turns on these would yield the hundreds of microHenries and offer several kilo-ohms of reactance to better-block RF - especially at 630 and 2200 meters.

What finally worked:
Figure 4:
A high-inductance choke wound on a Mix 75 toroidal core using flat "Cat 6"
Ethernet cable.  This device offers a common-mode choking inductance of
several millihenries at LF, MF and lower HF frequencies and was required
to solve the problem of conducted RF on the Ethernet cable causing issues
with the Powerwall's back-up gateway.  This cable was inserted into the
Ethernet cable between the indoor switch and the Powerwall using a CAT-6
rated double-female joiner.  A combination of a very high
inductance choke like this and several snap-on chokes over several turns
like those seen in Figure 2 and 3 are recommended for broad-band attenuation
of conducted currents.
Flat Ethernet cable is preferred for this as it will better-retain its internal
geometry when wound as tightly as this while similarly-winding round
Ethernet cable in such a manner may impact its signal integrity and
reduce its maximum speed.
Click on the image for a larger version.

What I settled on was a combination of several things:
  • Several turns of the Ethernet cable through some Mix 75 snap-on chokes.  The use of several chokes and several turns maximizes the added inductance.  (see figures 2 and 3.)
  • Some more of the same snap-on chokes were placed over the RS-485 connection to the Neurio in the garage.  There wasn't evidence that RF energy was affecting this line, but I didn't want to take the chance.
  • As depicted in Figure 4 I wound a 6 foot length of flat CAT-6 Ethernet cable over a toroidal (ring) core of Mix 75 ferrite to provide a choking inductance of several milliHenries - several orders of magnitude higher inductance than the other ferrite devices.  This "bulk" inductance would be responsible for blocking RF energy at the 630 and 2200 meter bands at which I often operate.
  • Inside the raceway I placed some additional Mix 75 snap-on devices over both the Ethernet and RS-485 cables, each passing through the cores several times for maximum inductance.

By adding all of this ferrite I increased the impedance (at RF) of the common-mode current to hundreds (if not thousands) of ohms at all of the frequencies on which I am likely to operate.  It is to this effort that one must go to minimize conducted RF energy on such conductors.

Why did it matter which Ethernet switch I was using?  I'm not sure, but I suspect that the Gig-E switch is lacking complete galvanic isolation on at least some of its Ethernet ports.  This issue could occur not only if there is a shielded Ethernet cable with attached shielded connectors on each end - which would be a liability in this particular case - but also if there is some sort of balanced connection to the pairs themselves - such as would be present if the switch had POE (Power Over Ethernet) capability.  The manual for the switch indicates no POE capability, but there is definitely something different about it and the way it connects the cables!  Perhaps a similar model of this switch does have POE and there is, in fact some connection inside - but unless/until I tear it down to find out, I won't really know.

Afterward:
Figure 5:
The "pin" on the BUG (Back-Up Gateway) that I was
requested by Tesla to photograph and forward to them.
This is pin is normally hidden by a sticker, hence the
"void" residue on the metal. This pin moves left/right
to go on/off grid, respectively.
Click on the image for a larger version.

Several days after this event I got a telephone call from Tesla Powerwall support asking me to remove the sticker from my back-up gateway and see if the "pin" was visible.  When queried, the representative noted that they had recorded several "incidents" with my system - and time and dates of these correlated exactly with my RF interference issues:  I told her that as far as I was concerned, the issue was resolved - but they still insisted that I take a picture of the pin and forward it to them - See Figure 5.

Update:  I was contacted again by Tesla - and this time they asked "if I was able to move the pin".  Not having been asked to do this before, I did so when I was at home again and it did move:  To the right, the house was isolated from the grid and to the left, the house is tied to the grid.

Having forwarded this information, I have yet to hear back.


Parts sources for ferrite devices: 

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, but he does have ferrite rings of both ferrite mixes.
  • 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, including toroids (rings).

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

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

This page stolen from blogspot.ka7oei.com

[End]


Thursday, October 18, 2018

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]


Friday, October 5, 2018

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:

Other solar power related posts at ka7oei.blogspot.com:
This page stolen from blogspot.ka7oei.com

[End]

Wednesday, September 26, 2018

A simple 8-channel receiver voting controller for enhanced repeater coverage and usability


One of the often-overlooked means of improving the coverage of an amateur radio repeater is the use of multiple receivers in a voting configuration.  It's often the case that a user can hear the repeater fine, but for whatever reason cannot get back into it - particularly if they are using a portable radio (a handie-talkie) and a compromised antenna, such as a rubber duck antenna.  By extending the reach of the receive portion of the system with several geographically disparate receivers on the same frequency the effective, usable coverage can be increased without the need to have a linked repeater system - which may require additional frequencies - and it reduces the necessity of the user to switch between linked repeaters to maintain coverage.

While this article describes a specific 8-channel voting system, it should contain enough information to be able to implement a similar voting controller using other hardware.

Why a voter?

Figure 1:
As-built voting controller board.
The small board contains 8 LEDs to indicate which receiver(s)
are active and being voted.  This voting controller
has been in service for about 15 years - and this picture,
from a very early digital camera, is lower resolution than
one might like.
Click on the image for a slightly larger version.
Why improve the receiver coverage without a commensurate improvement in transmitter coverage?  This makes sense if the repeater is an "alligator" - that is, "big mouth, small ears" where it can be heard over a wider area than it is often possible to get into it - something that is particularly true for users of handie-talkies - especially when the repeater itself may be located at a "busy" RF site with a high noise floor that limits the sensitivity of co-located receivers.

The use of "extra" receivers also takes into account an important property related to how hams actually use repeaters:  When the signal from the repeater is weak, the user will jockey about to find a "hot spot", but when transmitting to the repeater there is no obvious means of feedback to help that same user find reciprocal hot spot - which may or may not be in the same place as for the receive.

A more subtle  problem with transmitting is that user naturally places the radio very close to their face which may not be conducive to the best transmitted signal to the repeater and it is the tendency for many people to "drop" their radios a bit, holding the antenna in a way other than vertical - something that often goes unnoticed because, while transmitting, they cannot know the quality of the signal making it to the repeater and adjust their position accordingly.

How it works:

When an FM signal gets weak, it doesn't get quieter - it gets noisier - and we can use this property to determine which, among several receivers, is getting the worst signal(s) - but how do we do this?

Figure 2, below, shows what happens.
Figure 2:
A graph representing the relative amplitude of noise with strong weak FM signals.  It is the upward tilt of the noise energy to which "Triangle" noise refers - the angle getting "steeper" as the signal degrades.  Also represented is a high-pass filter that removes the modulated audio, leaving only the noise to be detected.
From this diagram one can begin to see why pre-emphasizing audio along a curve similar to the "weak signal noise" line can improve weak-signal intelligibility by boosting the high-frequency audio on transmit (and doing the inverse on receive) to compensate for the noise that encroaches on weak signals.

When the signal is strong, the noise in the background is at quite a low level - often inaudible but as the signal gets weaker, the noise increases in amplitude with the noise at the highest frequencies getting stronger more quickly.  Because the audio (e.g. voice) occupies the lower frequencies, if we look only at the higher frequencies, we can detect this noise, more or less independently of the audio.

With amateur radio, however, we don't really us "FM" (Frequency Modulation) per se, but rather "PM" (Phase Modulation) or its equivalent.  Saving a complicated explanation and some math, the reason for doing this can be divined by taking another look at Figure 2, above.  What one notices is for a given signal - strong or weak - that the amplitude (loudness) of the noise increases with frequency.  What this means is that if we were to use "true" FM (whatever that is) on a weaker signal we would hear sharp-timbered noise at higher frequencies creep in to the signal.

In an effort to reduce the effects of this noise, in Amateur Radio the "highs" of the transmitted audio are pre-boosted (called "pre-emphasis") to counteract this effect and on the receive side, they are then "un-boosted" (called "de-emphasis") to restore them to their original frequency response.  Because of this "un-boosting" the high-pitched hiss is also reduced and the end result is that when one hears hiss on a weak signal on, say, 2 meters, the noise doesn't have that high-pitched timbre, but it sounds rather like white noise.  This has the overall effect of reducing the amount of noise that is perceived on a weak signal, allowing such signals to sound better than they would were it not for this combination of "pre" and "de" emphasis.
Figure 3:
A typical squelch circuit found in FM receivers.


An analog representation of a squelch circuit may be seen in Figure 3 with the audio typical taken from the discriminator of the receiver, before the de-emphasis as we actually want to preserve this high-pitched (ultrasonic) noise.  What all of this means is that if we have several identical receivers listening to the same frequency, we can tell something about how "good" the signal is simply by comparing the amount of this high-pitched noise is coming out of them:  The one with the highest amount of noise represents the weakest signal.

Comparing remote receivers:

The comparison of this noise is easily done if all of the receivers are located in the same place, but what about the typical situation where the receivers may be scattered about, being "connected" to the common point via radio links?  The problem with doing this is that the high-pitched noise due to weak signals received via the remote receiver can't easily be transmitted via the link owing to bandwidth concerns - and if we were to try to do this, the squelch on the link receiver itself may be fooled into thinking that the retransmitted noise was actually on the link.

For practical concerns, audio transmitted by an amateur FM transmitter is typically low-pass filtered around 3 kHz so that much of the audio above this would be just  noise in the case of a weaker signal, but in a link from a remote receiver we would take this receiver's audio - and its noise - and cut it off, causing us to lose that ultrasonic energy that we'd use to determine the signal quality.

While we would normally use this ultrasonic noise for squelch threshold determination, we can still use what is left to compare two signals.  When we listen to an FM signal with our ears, we can tell if it is weak because we hear noise in the background - and the level of this noise is constant, whether the signal is being modulated by the user's speech or not.  What this means is that if we simply look at the audio coming from two receivers - and compare them - the one that is weaker will have audio plus noise and will, overall, be a bit louder.  If we filter this audio a bit, keeping only the higher-pitched audio - say, that above about 2 kHz - we can more easily make this comparison as most of the audio power of speech is located below 2 kHz, so what we get is a greater percentage of noise and less voice, making the determination easier with simple circuitry.

In the case of the voting controller described, the method of "the lowest noise above 2 kHz is the best signal" is used.  This makes it fairly easy to use several signals from disparate receivers to achieve a comparison.

Comment:
There are other methods of determining "which is the weakest signal" - but they all rely on determining which signal is noisiest.
Another method that is used by some voting systems - one that does not rely on high-pass filtering - is an "inverse peak" detector that measures the maximum "quiet-ness" of the signal being received.  By determining how quiet the "quiet parts" are (between words, etc.) the best signal may be determined because a noisy signal will have more noise in the quiet parts than a "full quieting" signal.  This method typically employs a logarithmic detector to permit useful measurement of the wide dynamics between audio peaks and dead silence.   

A simple voting controller:

Figure 4, below, shows the schematic of the voting controller.


To simplify things, this voting controller sits in "front" of an ordinary repeater controller, taking the audio and COS inputs from the various receivers and outputting a single audio and COS signal.

If the repeater system in question uses subaudible tones, it is recommended that "discriminator" audio (e.g. that which has not been de-emphasized) that has not been subject to a squelch or tone detector audio gate be applied to the voting controller from the link receivers as well as any "local" receivers as this will assure that the voted audio will contain the subaudible tone.

By having audio that is not gated by the squelch or tone detector the response of the voting receiver system will be much faster and less-subject to drop-outs as it moves between receivers.  Having the subaudible tone detector following the voter will assure faster, more consistent operation, provided that one is careful to make sure that the received phase of the subaudible tones being received by all receivers (e.g. from a single transmitter being heard by all receivers) is as close to the same as possible.

Figure 4:
 The schematic of the as-built voting controller.
An alternate notch filter is depicted in Figure 6, below.
Click on the image for a larger version.
How it works:

Microcontroller:

The heart of the voting controller is U8, a PIC microcontroller.  Originally, a PIC16C84 was used with an R/C clock oscillator - but this device has long been discontinued, but a minor firmware change was made several years after it was put into service and was replaced with a somewhat more modern, pin-compatible device like a PIC16F628 or PIC16F819.  Even a more modern device like a PIC16F88 or a PIC16F1847 could be used with no wiring changes. Because there are no critical timing requirements, the on-board oscillator is used.

The job of the microcontroller is simply to look for active COS inputs and then select the audio sources and do a "noise comparison" to see which one is best and select it.

Audio source selector:

There are really two identical audio source selectors:  For the moment we'll talk only about "MUX A" using U2.

U2, a CD4051 CMOS 8-channel MUX is used to select the audio inputs:  This device is a genuine 4000-series device and is run from the 12 volt supply to minimize its internal resistance as well as allow the widest-possible swing of the input analog voltages.  To interface it with the 5 volt logic of the PIC, Q1-Q3 are used for logic level conversion, the "inverting" of the bits taken care of in software.

For U2 (MUX A) the selected audio also gets buffered by U4D which is passed to the repeater controller as the "voted" audio.

High-pass filter/noise detector:

Each of the MUX's inputs are capacitively coupled and biased at mid-supply (approx. 6 volts) and the selected output is buffered by U5A, a unity-gain follower and then applied to a 3 kHz high-pass filter.  This high-pass filter - which doesn't really gain its true effectiveness until below around 2 kHz - removes most of the lower-frequency energy related to the speech, leaving mostly any background noise (hiss) from weak signals.

Following the high-pass filter is a rather high-gain non-inverting amplifier that boosts the filtered audio significantly.  Because most of the audio energy of a "clean" signal is below the 2-3 kHz range, the total amount of energy that remains is quite low, but by amplifying it, even low amounts of "hiss" can be detected.  During normal use, this noise amplifier will often be driven into clipping, but that's OK as a poorer-quality signal (e.g. noisier) will still have, overall more total audio energy.

The energy from this amplifier is rectified and smoothed by diodes D1 and D2 - with a small amount of DC bias for the diodes provided by R25, a 1 Megohm resistor which slightly improves low-signal sensitivity - particularly when several signals being received via the receiver(s) are at or near full-quieting.

Signal quality comparator:

At this point it's worth mentioning again that there are two audio paths - the "MUX A" path input via U2 mentioned above, and an identical audio path that uses U3 and the same amplifier and noise detector arrangement:  The only difference is that it is only the audio being selected by "MUX A" path (via U2) that is passed to the repeater controller, so that is always going to be the "best" signal if more than one is present.

Having two separate "noise" voltages, a simple analog comparator, U6, is used to see which one is the "noisiest".  In this case, an LM311 comparator is used, relying on microcontroller's internal pull-up resistor to provide a logical "high" signal - and this handily does the logic level conversion as well.  An LM339 would have worked fine, but since we need only a single comparator - and the '339 has four - I just used an LM311.  In a pinch it's possible that an op-amp could have been used as a detector, but care must be taken to assure that the chosen op amp will work properly with signals that are very near ground and can go up near the positive supply rail.

Comment: 
The originally-used PIC16C84 did not have a built-in A/D converter or comparator, but many more modern PICs do - and either one could be used in this case to compare the two signal paths' noise voltages.  Because the more modern processor was a retrofit for the original 'C84, there was no reason to get rid of the comparator.
If an internal A/D converter or comparator is used, be aware that the analog voltages from the noise detectors could easily exceed the maximum 5 volt rail of the processor so appropriate clipping/scaling should be applied.


COS Mux:

For each of the (up to) eight receivers, there is a corresponding "COS" input - that is, a line that is pulled to ground (typically by an open collector or drain) when that receiver picks up a signal that opens its squelch.  To convey these eight signals to the microcontroller, U1, a 74HC168 8-input shift register is used.  During normal operation the controller will strobe the current states into the register via the "/PL" line and then, using the clock and data lines, read them serially - all using just 3 processor pins instead of 8.

Note that there are two resistors on each input of U1:  R16(a-h) being used to pull the input up to 5 volts and series resistors R17(a-h) used to protect the input of U1 in the event that the COS input happens to go above 5 volts.

PTT Output:

If any COS input is active, the PTT signal from pin 2 of U8, the microcontroller goes high.  This signal then enables Q7 an NPN transistor that is used to pull the repeater controller's PTT line low.

Active channel indicator:

To indicate which receiver's audio is currently being passed to the repeater controller, U9, a 3-8 decoder - is used, monitoring the address lines for MUX A.  If no COS signals are active, U9's "E3" input, which is tied to the same microcontroller pin that asserts the PTT to the repeater controller, goes low, turning off all of the LEDs.

Comparing signals:


At this point it's worth talking about how the signals are compared and voted on.

MUX A is always used by the best receiver after voting so that it will be passed to the repeater controller.  MUX A is therefore always used as the basis of comparison to any other channels that might be active.
  • If there is one receiver active as indicated by its COS line, MUX A is used to select it, which pipes the audio to the output, to the repeater controller.
  • If there are two receivers active, the first one to have been detected active is set to MUX A and the second one is set to MUX B.
    • If the receiver on MUX B is "quieter" than the one on MUX A, the output of U6 will be generally low because of higher noise coming from the MUX A channel.  In this case, the microcontroller will swap the two signals, putting the "better" one on MUX A where it can be passed to the repeater controller.
  • If there are more than two receivers active, MUX B is used to switch between these other active receivers, comparing them to that "active" receiver on MUX A:  If another of these others suddenly has a better signal, it's immediately moved to MUX A where it can be output to the repeater controller.
  • If the COS for the receiver on MUX A suddenly disappears but there is at least one other signal present, the lowest-number signal is immediately switched to MUX A and the voting process resumes.
  • If there are suddenly no active COS signals, the output PTT signal from the microcontroller is dropped immediately.
How it works in Software:

(Note that the source code, in "C", is included below if you wish to "play along".)


In the "main()" loop of the software, the "update_sr()" function is called every time it executes, making certain that the COS inputs are updated very frequently. 
When the microcontroller is in it's "idle" state (no active COS input) both the "A" and "B" audio MUXes are set to receiver 1.  Besides being a convenient starting point, this allows easier adjustment of the noise detector circuits as they would be fed with the same signal, making it very easy to set them identically.


If, after being idle, a COS input goes active, the first one that the it runs across is assigned to MUX A and the PTT output is set active.  After assigning the first signal to MUX A - which causes that receiver's audio to be passed to the repeater controller - another portion of the code is then executed that looks for other active COS inputs.

If one or more active COS inputs are detected, it assigns the first one to MUX B.  Allowing time to for the readings to settle, the controller then does a bit of simple averaging over the next 25 loop cycles (which takes about 25 milliseconds) to see if the signal on MUX B seems to be "better" than the one on MUX A.

If the signal currently on MUX B is better, MUX A is switched to this input.  If the signal on MUX B is not better, the controller sequentially switches MUX B to other currently-active COS inputs and makes the same comparison.

In this same loop, an eye is kept on the COS status of the channel to which MUX A is currently set:  If this COS goes inactive, the code immediately re-scans to find another active COS input, assigning it to MUX A to make sure that audio from an active receiver is being passed to the repeater controller.  If it is determined that there are no active COS inputs, the PTT line is immediately dropped so that the repeater controller may do its normal "hang time" operations.


Other means of implementation:

For the original implementation I used a PIC microcontroller because I've long been familiar with them and have had the appropriate development tools, but it could be done using something like an Arduino if they'd existed when I first built this:  Even the cheapest, low-end UNO would even be overqualified for the task!

To do this, one would simply substitute the Arduino and its I/O pins for U8:  While the Arduino has available comparators and A/D converters, it would be almost as easy to use an outboard comparator rather than trying to get rid of it unless, as noted above, you are prepared to scale voltage appropriately.

It is possible for the entire device to run from a single 5 volt source, but if this is done rail-to-rail input and output op amps are strongly recommended and very close attention should be paid to the peak-to-peak voltage swings of all the analog signals:  Worst-case is typically the "no signal" condition where the radio is outputting noise and if an analog voltage goes above the supply voltage or "below" ground (as can happen with capacitive coupling) many analog MUXes will spuriously conduct this noise into other, de-selected channels, causing very annoying "popping" in the audio.

Using a "voting" tone:

Many voting systems include a tone that is sent along the circuit when no signal is present - and for best performance, such is recommended here.

For example, each remote receiver is configured with a 3.5kHz oscillator that is activated when the squelch closes and the audio being receive and then transmitted along the link to the voting site is muted - followed by a short (half-second or so) "hang time" with the remote receiver/link transmitter transmitting only this tone.

The reason for this is to minimize the number of "noise bursts" that one might hear as a user popped in and out of more than one receiver.  For example, if the user was "weak but solid" into receiver "B" but was popping in and out of "A" - often with a good signal - then the voter would select receiver "A" when the user was solid into it, but reverting back to "B" when the signal dropped out.

If the link transmitter were to key on and off every time the user dropped in and out of "A", the link receiver at the voting site would get a burst of squelch noise every time - and this would inevitably come across the link in the instant before it was detected, making the signal sound more "multipathy" and noisy than it really was.

If, instead, a strong 3.5kHz tone was sent down the link as soon as receiver "A" dropped out, the voter would detect this tone as if it were noise - but much more strongly so - and the voter would immediately switch away from it, to receiver "B", handily avoiding that burst of noise that would otherwise be transmitted from both the receiver "A" and its link transmitter dropping out at the same time.

This typically works because, in a voter system, one rarely drops instantly out of one receiver, but in the case of multipath this fade can happen very quickly:  Having the tone switch on helps make the voter switch more quickly with the squelch on the receiver "A" closing before the signal is completely gone.

Having this tone does mean that to those listening, a brief burst of that tone will come through - particularly if only one receiver is in use:  In that case, there is no "better" receiver to switch away from which means that the 3.5 kHz tone will blast out during the link transmitter's brief hang time.

To prevent this ear-piercing tone from being obnoxious, the schematic in Figure 4 includes a notch filter to reduce this 3.5 kHz tone.  As mentioned in the notes below this small diagram, it is strongly recommended that the pairs of capacitors and resistors be carefully matched to obtain the best notch depth (which should be well over 25dB).  It is suggested that this filter - or one of similar function - be placed on the audio output before it is passed along to the repeater controller.

Block diagram of an example system:

In Figure 5, below, is a block diagram of an example system.

Figure 5:
Block diagram of an example voting repeater system with two remote receivers and one receiver co-located with the transmitter.  An example of a "tone decoder module" is given in Figure 6, below.
Click on the image for a larger version.

Remote RX site:

The remote receiver (one of several, perhaps) is located at a site that offers complementary coverage - or perhaps to fill in a particularly badly-covered area where users may be able to hear the repeater well (perhaps noisily) or in an area where it may be advantageous to have a "local" receivers to allow good coverage via low-power handie-talkies (say, an area where public service events are commonly held.)  This remote site should include a rudimentary repeater controller capable of producing hang-time, legal identification and time-out should a signal get "stuck" on the receiver's input.

If the system is to be used with a subaudible tone it is recommended that the tone decoder not be located at the remote receiver, but rather that it be normal "COS squelch" and that the tone be able to be passed directly from the receiver to the transmitter:  Many receivers and transmitters have high-pass filters to prevent exactly this so it may be necessary to select the gear carefully and/or make some modifications to allow this.  The reason for this is that subaudible tones are quite slow to be decoded meaning that if a signal is weak or choppy, a lot of content can be lost during these portions of a transmission as the already-slow tone decoder will be even slower to respond if the signal is noisy.  If a subaudible tone is decoded at the link transmitter, expect there to be more "holes" in the audio as users transition between the two receiver sites than otherwise!

When the COS of the received signal drops, a 3.5 kHz tone is switched in instantly to "un-vote" the signal from that receiver:  This "loud" tone will instantly be detected by the voting controller as one that is "bad" (e.g. lots of high-frequency content - a stand-in for the noise of a poor signal) and it will vote "away" from this receiver - assuming that another receiver is still active.  If no other receiver is active, the notch filter (in the voting controller) will remove this tone so that users can't hear it during the remote site's transmitter's hang time.

The reason for the hang time (where the remote site is transmitting only a tone) is to reduce the amount of audible "chop" that might be heard when a signal is dropping in and out of a receiver.  By having a bit of hang time (with tone) the voter will be given a chance to "switch away" from it when a signal drops without there being the burst of squelch noise when the link transmitter drops, before the receiver at the voter site's squelch closes.

Repeater transmitter site:

At the repeater's transmitter site there may be one or more "link" receivers - but there may also be a "local" receiver.  As seen, the voting controller sits between the receivers and the repeater controller, the idea being that the voting controller will make the multiple receivers look like a single receiver.

In the simplest case, all receivers simply connect to the voting controller via their (unsquelched!) audio and their COS lines:  As with the remote receivers, the link receiver should be COS-only with no subaudible tone for the same reasons as mentioned above.  The subaudibletone decoder should only be present in the signal after the voting controller to provide the best response to rapidly-changing signals.

"Voting tone":

To prevent the shrill 3.5 kHz tone from blasting through the repeater during the hang time of a link receiver, the 3.5 kHz notch filter is depicted in the audio path between the output of the voting controller and the repeater controller.  At 3.5 kHz, this notch will have little or no effect in the quality or timbre of the received signals.

Figure 6:
 An example of a tone detector that can be adjusted to 3.5 kHz
along with another example of a notch filter for the tone.
This diagram also includes a de-emphasis circuit in the event
that were needed.  Note that all capacitors NOT used
for power supply bypassing (e.g. those in the de-emphasis,
notch filter and tone decoder) must be temperature-
stable plastic capacitors and not disk ceramic.
Click on the image for a larger version.
Also included in the diagram is a "voting tone" decoder designed to respond to the 3.5 kHz tone sent from the remote site and this is useful if it's desired that the hang time of the remote link transmitter (while the tone is active to "un-vote") be removed from the equation.  Its purpose is simply to detect that 3.5 kHz tone and de-assert the COS signal, causing that receiver to be not only "un-voted", but also to allow the COS from the voting controller to un-key immediately even if the receiver in question is one of the remote receivers with its own hang time.  This also has the effect of eliminating a "double kerchunk" caused when the user unkeys, and then again when link transmitter unkeys and its receiver's squelch closes.

It should be noted that if there is a direct wire connection between the receiver and the voting controller - as would be the case for a local receiver - none of this 3.5 kHz nonsense is required as there is, by definition, no extra "squelch noise" burst on that receiver as would happen on the remote receiver when its link transmitter un-keyed.

Final comments:

If you do plan to have an analog voter of any kind, also note that you must use a purely-analog receiver:  While tempting, radios that use "all in one" chips (such as Baofengs and other imported brands) are probably not usable as they tend to have a bit of delay, they may have no easy way to defeat the filtering of subaudible tones, and they also tend to automatically switch in a low pass filter on noisy signals - something that would mess up any comparison that you would hope to do - and this assumes that they actually have a "COS" output that is actually fast enough to be useful!

What about voting for a digital system?

While implementing a voting repeater system for an analog repeater is straightforward, the same cannot be said for digital signals.  To an extent, a radio could "know" of several different linked systems in a given coverage area, but having several systems not only requires a lot of resources (gear, frequencies) but it is arguably less convenient and less effective than having a voting system to increase the "grasp" of a receive system.  In theory, one could have very carefully designed receive systems that "seamlessly" switch between two receivers without corrupting bits (very careful attention to phase and timing would be required!) but the noise-like nature of digital signals makes their direct quality comparison a bit more difficult.

If some sort of voting system is used, it might also have individual digital demodulators at each site and then convey that digital signal to a more complex voting system that performs re-timing of the received signals and then monitors the apparent error rate, feeding the "best" result to the original repeater:  Such a system is beyond the scope of this article.



Addendum:

* * *
Source code:

What follows is source code, in "C", targeted for a now-ancient version of the CCS compiler.  This version of code assumes the use of a PIC16C84 microcontroller that used external R/C oscillator components.  (I couldn't find the version updated for the newer processor - but the changes required were very minor.)

It is not expected that one would use this code as-is, but rather use it as an example as to how the logic worked so that it could be applied to other platforms.

This code is supplied as-is with no expressed or implied warranty regarding usefulness or fit for any purpose.

* * *

/*
This code is for an 8-input voting controller.  There are two noise-detect channels on 8-input
MUXes:  Channel A is the "primary" channel:  This channel, when selected, outputs the selected
channel's audio.  Channel B is used to compare against channel A and if it is *better* than
channel A, then THIS channel gets transferred to A (thereby selecting it as the audio source.)
Note that ONLY those channels with active COS are compared.

Revision History:

0.01  20000610    Started work
0.02  20000611    First operational version (I think...)

Notes:
   - It is highly recommended that the audio inputs from the various
      receivers be UNMUTED by the COS.
   - When an input signal is active, the respective input COS signal goes
      LOW.  This is usually accomplished with an open collector at the
      receiver.
   - Unless ALL of the receivers are local, the audio inputs MUST
      be de-emphasized.
   - All audio inputs are to be adjusted identically at their
      respective receivers.  The more closely matched, the less difference
      will be heard when the voting occurs.
   - This voting controller does NOT affect the audio passed through it in
      any way (assuming that the amplifiers aren't clipping) other than by
      selection of the audio source.  Once the receivers are adjusted for
      EQUAL output levels, THEY SHOULD NOT BE READJUSTED!  Doing so will
      require complete realignment of the system/voting controller.  If
      additional transmit deviation is needed, this should be done by
      adjusting the CONTROLLER and *NOT* the the receivers!

Adjustment procedure:

   - This procedure assumes that the highest audio input level will occur
      with squelch noise.
   - The following test points are used:
      TP1 - Noise detector Channel A output voltage
      TP2 - Noise detector Channel B output voltage
      TP3 - Noise Channel A output level (highpass audio)
      TP4 - Noise Channel B output level (highpass audio)

   This procedure is to set the noise channel outputs (TP3 and TP4) to the
      highest level possible (without excessive clipping) so that, for the
      same signal, the detector voltages (on TP1 and TP2) are as close to
      identical as possible.

   1) MAKE SURE THAT ALL RECEIVER OUTPUTS ARE MATCHED IDENTICALLY WITH THE
      SAME AMOUNT OF DEVIATION!  That is, with 3 KHz of deviation, all
      receivers should be set to output the SAME audio level.
      Additionally, the audio equalization should be matched as closely as
      possible for all receivers.
   2) With *no* COS signals active and with (unsquelched) audio going into
      RX audio 1, connect an oscilloscope to TP3 (noise Channel A Highpass
      output) and adjust potentiometer RA for the maximum audio level that
      results no or only a slight amount of clipping.
   3) Move the oscilloscope to TP4 and adjust potentiometer RB for the same
      level as on TP3.
   3) Connect a voltmeter to TP1 (MUX Channel A noise detector output) and
      note the voltage.  It will bounce a bit as the noise, so note the
      "average" voltage reading.
   4) Move the voltmeter to TP2 and adjust it to the same average voltage
      as read on TP1.
   5) Using the oscilloscope, compare the outputs at TP3 and TP4.  If one
      is much higher than the other, reduce the highest one somewhat and
      set the other channel to the same using a similar procedure to the
      above.
   6) When done, make sure that TP1 and TP2 are approximately equal
      voltages (i.e. closer than 0.1 volts of each other.)

*/

#OPT 9

#include    <16c84.h>    // define use of 16c84a

#define        PORT_A_ADDR    0x05    // port A address
#define        PORT_A_TRIS    0b00001    // port A I/O mask (LSB in, RA1-RA4 out)
#define        PORT_B_ADDR    0x06    // port B address
#define        PORT_B_TRIS    0b10000000    // port A I/O mask (LSB and MSB in, others out)

#define     WAIT_TIME   7     // time, in milliseconds, that we should
                              // wait before starting to make any decision
#define     VOTE_TIME   25    // The number of "cycles" through the quality
                           // decision loop.  Each cycle takes about 1
                           // millisecond
#define     QUAL_THRESH 15    // this is the number "good hits" that are
                              // required during the "VOTE_TIME" to decide
                              // if "this" one is really better

#byte        PORT_A = 5
#byte        PORT_B = 6
#fuses        RC, WDT, NOPROTECT, PUT
// RC Oscillator, watchdog, no code protect, Power Up Timer, no
//brownout protect


#use delay(clock=225000, RESTART_WDT)  // 225 KHz = 33k & 82pf

#use    fast_io(a)        // set port A for fixed-mode of I/O direction
#use    fast_io(b)        // set port B for fixed-mode of I/O direction

// System definitions:


#bit SR_INDAT = PORT_A_ADDR.0 // Serial data from parallel-input shift register
#bit SR_CLK = PORT_A_ADDR.1   // Shift register clocking
#bit SR_PLOAD = PORT_A_ADDR.2 // Shift register parallel load
#bit COS_OUT = PORT_A_ADDR.3  // "voted" COS output (1 = active)
// PA4 is reserved
//
#bit MUXA_A = PORT_B_ADDR.0   // audio mux A LSB
#bit MUXA_B = PORT_B_ADDR.1   // audio mux A
#bit MUXA_C = PORT_B_ADDR.2   // audio mux A MSB
#bit MUXB_A = PORT_B_ADDR.3   // audio mux B LSB
#bit MUXB_B = PORT_B_ADDR.4   // audio mux B
#bit MUXB_C = PORT_B_ADDR.5   // audio mux B MSB
// PB6 is reserved
#bit COMP_IN = PORT_B_ADDR.7  // signal quality comparator (0 = "B" is *BETTER* than "A")

byte  cos_data;


#ZERO_RAM        // This macro causes code to wipe all memory locations

// This function gets data from the input shift register

update_sr(void)
{
   char x;

   SR_CLK = 0;             // initialize sr clock
   SR_PLOAD = 0;           // load data into shift register
   SR_PLOAD = 1;           // 'freeze' data in input shift register

   cos_data = 0;           // clear Carrier Operated Squelch input shift register

   for(x = 0; x <=7; x++)  {
      SR_CLK = 0;
      cos_data <<= 1;         // shift next bit of input data into position

      if(SR_INDAT)   {
         bit_set(cos_data, 0);   // Set the LSB of "cos_data" (this is a one-instruction PIC operation) if SR output is high
      }
      SR_CLK = 1;           // shift the data in
   }
}

void  setmux_a(byte b)     // this function sets MUX channel A
{
byte  temp;

   temp = PORT_B;             // read port B output register
   temp &= 0b11111000;     // clear 3 LSBs for MUX A
   b ^= 0xff;              // invert contents to account for inversion of level converter
   b &= 0b00000111;        // make sure nothing is in anything but bottom LSBs
   temp |= b;              // overlay MUX A data
   PORT_B = temp;          // send it out
}

void  setmux_b(byte b)     // this function sets MUX channel B
{
byte  temp;

   temp = PORT_B;             // read port B output register
   temp &= 0b11000111;     // clear the 3 bits for MUX B
   b <<= 3;                // shift the current MUX data to match bit positions
   b ^= 0xff;              // invert to compensate for level conversion
   b &= 0b00111000;        // make sure nothing is in this but the correct bits...
   temp |= b;              // overlay MUX A data
   PORT_B = temp;          // send it out
}


void main(void)
{
byte  x;                      // multipurpose counter
byte  qualcnt;                // "quality" counter
byte  mux_a;                  // holder/counter for mux_a
byte  mux_b;                  // holder/counter for mux_b

short cos_scanflag;           // flag bit used in scanning for COS activity
short recheck_flag;

   setup_counters(RTCC_INTERNAL, WDT_144MS);

    SET_TRIS_A(PORT_A_TRIS);    // set I/O direction for ports
    SET_TRIS_B(PORT_B_TRIS);
//
   PORT_B_PULLUPS(TRUE);

   COS_OUT = 0;               // clear output COS line...
   mux_a = 0;                 // initialize MUX selectors
   mux_b = 0;
   recheck_flag = 0;

   update_sr();               // grab data (to initialize shift register)

   while(TRUE) {
      update_sr();               // get current COS status
      restart_wdt();
         if(cos_data == 0xff) {  // is there *NO* COS activity? (bits go low when COS is active)
            COS_OUT = 0;         // yep - indicate such.
            mux_a = 0;           // always put both mux channels on 0
            setmux_a(mux_a);     // when no COS inputs are active...
            mux_b = 0;
            setmux_b(mux_b);
         }
         else  {              // there *is* COS activity.  Find out which one it is...
            if(!COS_OUT || recheck_flag)   {    // the output COS is not yet active *or* ONE
                                                //  became inactive, we need to find one that
                                                // is active is hearing the signal
               recheck_flag = 0;
               mux_a = 0;        // always make sure it we are starting out at zero...
               mux_b = 0;        // init mux B count
               cos_scanflag = 1; // init flag used for scanning COS bits
               while(cos_scanflag)  {     // this keeps happening while the flag is set
                  if(!bit_test(cos_data, mux_a)) {    // is it *THIS* bit that is active?
                     setmux_a(mux_a);                 // yes - set MUX to this address
                     COS_OUT = 1;                     // set COS activity
                     cos_scanflag = 0;                // clear flag so we don't go thru this again
                  }
                  else  {
                     mux_a++;       // bump count to next input
                     if(mux_a > 7)  {        // did we exceed our maximum count?
                        cos_scanflag = 0;    // yes - we bail out...
                        COS_OUT = 0;
                     }
                  }
               }
            }
            else  {     // COS *IS* active - lets look at other inputs to see if they are active
               if(!bit_test(cos_data, mux_b)) {    // is *this* COS bit active?
                  setmux_b(mux_b);     // change MUX to new channel...
                  delay_ms(WAIT_TIME);             // wait for comparator to settle
                  qualcnt = 0;
                  for(x = 0; x < VOTE_TIME; x++)  {
                     delay_ms(1);
                        if(!COMP_IN)    { // is this NEW a better signal?
                           qualcnt++;
                        }
                  }
                  if(qualcnt >= QUAL_THRESH)  {   // has the signal been better for enough samples?
                     mux_a = mux_b;                // yes - set both MUXes to the same place...
                     setmux_a(mux_a);              // set output to new signal put it there...
                  }
                  COS_OUT = 1;                     // make SURE we have COS output enabled
               }
               mux_b++;    // bump to next mux count
               mux_b &= 0b00000111;       // mask mux address
               if(mux_b == mux_a)   {     // are we attempting to look at the same input?
                  if(bit_test (cos_data, mux_b))  {   // is *this* COS bit INactive now?
                     recheck_flag = 1;                // yes - this signal went away - get new COS
                  }
                  mux_b++;                // yes - go to the *next* address
                  mux_b &= 0b00000111;    // mask mux address
               }
            }
         }
      }
}




This page stolen from ka7oei.blogspot.com

[End]