Monday, March 22, 2021

40 ft Vertical Doublet 40m - 10m

Vertical doublet / dipole - on 10m an EDZ (2x 5/8) with 4.5 dBi gain, 30m its just under a 1/2 wave dipole, and 40m a little on the short side but will work ok.

Started off with the idea of building an elevated vertical with radials to cover the upper HF bands, using an Icom AH-4 ATU at the feed-point to match it.

A 5/8 wave vertical for 10m is around 20 ft long, a 1/4 wave on 30m is around .. 23 ft. This would cover the upper HF bands. I like to model antennas before I build them for the experience and to get an idea of what to expect.

Modeling an elevated vertical trying different length radials didn't look so good, high angle lobes would form on some bands and the gain was mediocre at best. Running radials everywhere was not entirely convenient either.

I searched around for other possibilities, ZS6AAA designed a Compact Quad Multi Band HF Antenna which fits on a 40 ft Spiderbeam fiberglass pole that covers 40m through 10m. In my case easier said than done, needs to be guyed at several points.

Back to verticals, I thought delete the radials and center feed it? How long can I make it before the lobes go silly on 10m - the highest band? 40 ft. I was quite amazed at what I had discovered - only to find it was in-fact nothing new. However..

On 10m it's a vertical EDZ (Extended Double Zepp) or a 2 x 5/8 with 4.5 dBi gain at 10 degrees, and on 30 m it's just shy of a 1/2 wave dipole and 0.82 dBi with lowest point 10 ft above average ground.

40 ft vertical doublet AH-4 diagram

40 ft vertical doublet elevation plot

40 ft vertical doublet elevation plot

These patterns are much nicer than an elevated 1/4 or 5/8 wave ground plane antennas.


I have a 40ft Spiderbeam pole which I mounted on the 2nd level rear deck placing the bottom 10ft above ground. A surplus ZS6BKW I shortened the legs down to 20ft and keept the 40ft 450 ohm window line section as is, window line leads away at around 45 degree angle across to a roof eave where I mounted a short piece of PVC pipe with small section removed for the window line to fit over and rest on keeping it above the roof.

The first version (based on https://www.hamoperator.com/HF/AH-4_Design_and_Operation.pdf) I had the window line split between the output and ground terminal of the AH-4 tuner. CM chokes are placed on the coax and control cable. I used 3/4" mix 31 snap ons with enough turns of cable for a snug fit.

I later found using a 1:1 ATU balun between the AH-4 and balanced line worked a lot better. The AH-4 got better matches, and an RFI problem on 17m went away. The ATU balun was from Balun Designs. The CM chokes on the coax and control cable are still a good idea and were left in place in as well.

Made a 50ft control cable extension using quality CAT5e joining the pairs to make a 4 wire cable. I put a CAT5e tail with the RJ-45 left on (cut a patch cable in half) the tuner end and the end of the supplied control cable, lets me change the length by using CAT5 couplers and different length cable in-between.

I put a 3 Meg Ω 5W metal film resistor across the window line to bleed off static charge buildup via ground lug which is common to the coax shield in the tuner, coax shield is grounded where feed lines enter the house - make sure you meet NEC / electrical code (Grounding and Bonding - ARRL is a good book for North America and in general / and where applicable - consult professionals as needed).


AH-4 photo40 ft vertical doublet photo


Pictures, taken before I added the 1:1 balun.

The AH-4 tunes all bands 80m to 6m no problem, but I would question the efficiency of this system below 40m.

Comparing it with my 80m OCFD at 55ft from my location near Seattle WA, the vertical does surprisingly well.

SSB: On 40m the OCFD is always better which is expected. On 20m and up the OCFD will pull out the weak signals a little better. Local nets on 10m where the vertical up-to 9 S-units better in some cases, I'm assuming others are using verticals on 10m.

On 6m the vertical has high angle lobes but works ok on local 6m FM repeaters, for better performance we could add 6m traps 5/8 wavelength (on 6m) down each leg which would make it a vertical EDZ on this band. Keeping in mind to account for the loading the traps add on HF, it may need to be shortened a little to keep 10m in check.

FT8: Running two instances of WSJT-X with two radios (IC-7100 on vertical, IC-7300 on OCFD) with one reporting my callsign with /P to make it easy to tell them apart on pskreporter and watching FT8 signals on 20m through 15m the OCFD hears around 20% more stations. There are a few cases both on SSB and FT8 where the vertical does better, likely in directions where the OCFD has a null. I should probably repeat the tests with the antennas swapped to see how much of that 20% is attributed to the IC-7300's SDR receiver..

Horizontal antennas 1/2 wavelength or more high are hard to beat due to the gain from ground reflections, this vertical is a close 2nd to the OCFD on the upper bands.

A permanent install would need to by guyed (using non conductive line) at the feed point with the window line supported / suspended from one - when the wind catches the window line things things start swinging and wobbling around more than I'd like.

Overall I'm quite pleased with this vertical, it's simple, light weight, no radials, and the results have surprised. Down sides are you need a good remote tuner, and a means to lead the window line away at 45 degree angle or higher if possible. In my case neither of these were an issue.

I can now also see why feeding balanced antennas with 450 ohm line to a good tuner is popular, it works well! Personally I've had little experience with this way of doing things.

A shorter version could also be used covering 17m to 6m, at 24 ft, it would be an EDZ on 6m, and just under 1/2 wave on 17m.

Related info:



Sunday, January 10, 2021

Forwarding Ports over OpenVPN

How to configure OpenVPN server to forward ports through to VPN clients.

I recently tested this setup with my Oracle Cloud free tier VM running Ubuntu 20.04 and OpenVPN server (setup using this script https://github.com/angristan/openvpn-install) to forward the ports used by my IRLP node (running on Debian 8) connected to the VPN. This would work with any type of service, it's just a matter forwarding the right tcp/udp ports, and configuring the VPN client to auto connect on startup.

ISPs are increasingly using CGNAT to deal with IPv4 address exhaustion, this is a problem for those of us that like to run systems or services that need to have ports forwarded into them from a publicly routable IP address to work. An example in ham radio circles are IRLP (Internet Radio Linking Project), EchoLink and AllStarLink which need ports forwarded in order to work. A number of the ham radio VoIP systems offer varying levels of support for VPNs from full service (IRLP - they send you a config and away you go with a publicly routed 44 address I believe) to supporting different providers to make the setup easy.

If you want to do it all your self using a free tier (no cost) Oracle cloud VM for the fun/experience/control (mwahaha) then this is how I did it. To setup an ad blocking VPN check out Setup free Cloud VPN with Ad Blocking (this is the primary purpose of my VPN setup).

There are four pieces to getting this working:

  1. OpenVPN client auto connect on startup.
  2. OpenVPN server assigns the same static VPN IP address to the client.
  3. Cloud networking config to allow the ports in to OpenVPN server host.
  4. Update iptables rules on the OpenVPN server host to forward the ports to the VPN client.

In this example I created a VPN client config (using the install script) with the CommonName IRLP1, and configured OpenVPN server to always assign it 10.8.0.10.

1. Configuring the client to auto connect VPN on startup


Created a passwordless client config and copied into /etc/openvpn on the client (not sure if this varies between Linux distros), the file needs to be renamed from .ovpn extension to .conf extension, or in my case I made a symlink: ln -s IRLP1.ovpn client.conf

Test that it connects from command line:
openvpn --client --config /etc/openvpn/client.conf
Ctrl C to disconnect.

To get OpenVPN client to connect on boot, I had to use information from several sources to get it working on Debian 8.

Edit /etc/default/openvpn uncomment AUTOSTART="all" 

Ran these commands:
systemctl daemon-reload
systemctl enable openvpn

Connect OpenVPN client/check status/disconnect:
systemctl start openvpn
systemctl status openvpn
systemctl stop openvpn

All things being equal, reboot the system and the OpenVPN client auto connects on system boot up.

Debian 8 had OpenVPN 2.3 installed, had to upgrade it to 2.4 to get it to work, this guide covers the steps.

2. Configuring OpenVPN server to assign a unique 10.8.0.x address to each unique client


Because we're going to create iptables rules to forward ports to specific IP addresses, the VPN client needs to receive the same VPN IP address every time, otherwise the port forwarding wont work if it gets a different address.

The OpenVPN server script I used includes the ifconfig-pool-persist ipp.txt option in /etc/openvpn/server.conf. OpenVPN server adds an entry to /etc/openvpn/ipp.txt the first time a new client connects in the format CommonName,10.8.0.x, this is used to maintain long term association between clients and IP addresses.

According to the OpenVPN reference manual, maintaining a long-term association is good for clients because it allows them to effectively use the persist-tun option. Note that the entries in this file are treated by OpenVPN as suggestions only based on past associations between a common name and IP address. They do not guarantee that the given common name will always receive the given IP address. If you want guaranteed assignment, use ifconfig-push.

For the clients we always want to have the same address assigned, added this line to /etc/openvpn/server.conf:

client-config-dir /etc/openvpn/ccd

Create a file in /etc/openvpn/ccd with common name of the client - in my case that's /etc/openvpn/ccd/IRLP1, and add this one line (the VPN IP address to assign and the netmask):

ifconfig-push 10.8.0.10 255.255.255.0

Edit ipp.txt to also match, e.g. IRLP1,10.8.0.10

What's not clear is if we need to keep ifconfig-pool-persist?


3. Updating the cloud networking config


Each cloud provider will be different. This is how to do it in Oracle Cloud.

Oracle Cloud Console > Networking > Virtual Cloud Networks > [network name you created] > Public Subnet > Default Security List:

Stateless

Source Type

Source CIDR

IP Protocol

Src Port Range

Dest Port Range

Type and Code

Description

No

CIDR

0.0.0.0/0

ICMP



Type 8

Allow PING

No

CIDR

0.0.0.0/0

TCP


15425


IRLP Control

No

CIDR

0.0.0.0/0

UDP


2074-2093


IRLP Audio



This opens the ports from the public internet to the cloud VM which is the first half. Allow ping isn't needed, but sometimes it's nice to be-able to ping the cloud VM.


4. Update iptables on OpenVPN server to forward the ports through to the VPN client


Different OpenVPN setup scripts can setup the iptables rules in different files/places. You'll need to read the script to see how it's being setup. In the case of the one I use linked above, it sets up a systemd script to call these two scripts:

/etc/iptables/add-openvpn-rules.sh
/etc/iptables/rm-openvpn-rules.sh

First one adds the OpenVPN related iptables rules when the OpenVPN server starts, the second removes them when OpenVPN server stops.

Examples that forward external port 22000 through to port 22 for SSH (not recommend to open SSH to the world any more than needed, but maybe useful to have in some cases), and the IRLP TCP control port, and UDP audio port ranges. ens3 is the VM's network interface name (change to suit where needed).

These commands add rules into iptables, these go in the add-openvpn-rules.sh script:

# SSH
iptables -t nat -A PREROUTING -p tcp -i ens3 --dport 22000 -j DNAT --to-destination 10.8.0.10:22
iptables -A FORWARD -p tcp -d 10.8.0.10 --dport 22 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# IRLP TCP Control Port
iptables -t nat -A PREROUTING -p tcp -i ens3 --dport 15425 -j DNAT --to-destination 10.8.0.10:15425
iptables -A FORWARD -p tcp -d 10.8.0.10 --dport 15425 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# IRLP UDP Audio Port Range
iptables -t nat -A PREROUTING -p udp -i ens3 --dport 2074:2093 -j DNAT --to-destination 10.8.0.10:2074-2093
iptables -A FORWARD -p udp -d 10.8.0.10 --dport 2074:2093 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

To put the added rules into effect, run the script.


These commands remove rules from iptables, these go in the rm-openvpn-rules.sh script:

# SSH
iptables -t nat -D PREROUTING -p tcp -i ens3 --dport 22000 -j DNAT --to-destination 10.8.0.10:22
iptables -D FORWARD -p tcp -d 10.8.0.10 --dport 22 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# IRLP TCP Control Port
iptables -t nat -D PREROUTING -p tcp -i ens3 --dport 15425 -j DNAT --to-destination 10.8.0.10:15425
iptables -D FORWARD -p tcp -d 10.8.0.10 --dport 15425 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

# IRLP UDP Audio Port Range
iptables -t nat -D PREROUTING -p udp -i ens3 --dport 2074:2093 -j DNAT --to-destination 10.8.0.10:2074-2093
iptables -D FORWARD -p udp -d 10.8.0.10 --dport 2074:2093 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Reboot the system to make sure the rules are applied on startup.

The above 3 sets of rules would cover most examples, such as mapping ports through on different port numbers, sometimes this is useful (SSH), a TCP rule for a single port (IRLP Control), and a UDP rule for a range of ports (IRLP Audio). Creating rules for the other amateur radio VoIP should be easy with those as examples.

iptables -L -v or iptables -S will show the rules.

Netcat is good for testing ports from Linux/macOS systems (-u is for UDP):
nc -z hostname_or_ip port_number
nc -zu hostname_or_ip port_number

Connecting to reflectors 9050, 9100, and 9109 which are quite busy for hours at times, and node to node connections have worked with out issue.

Thats it!


Bonus item, a script that'll reconnect the OpenVPN client if the tunnel is no longer up and the client for whatever reason failed to restart the tunnel.

Script looks at the exit code of the ping command, if it's anything other than 0 then the ping failed, and a reconnect is attempted.
Outputs one line to the IRLP log/messages file if it reconnects.

#!/bin/bash
# Test VPN tunnel by pinging remote endpoint, if down restart OpenVPN client.

IP='10.8.0.1'
LOGFILE='/home/irlp/log/messages'
LOGDATETIME=`date +"%b %d %Y %T %z"`

ping -W 1 -c 3 $IP 2>/dev/null 1>/dev/null
if [ ! "$?" = 0 ]; then
 echo "$LOGDATETIME VPN tunnel down reconnecting.." >> $LOGFILE
 systemctl restart openvpn
fi

Put that into a file say called /home/irlp/custom/vpn-check.sh

Make it executable: chmod +x vpn-check.sh

As root edit the crontab: crontab -e

Add this line:

*/5 * * * * /home/irlp/custom/vpn-check.sh >/dev/null 2>&1

That'll run the script every 5 minutes.

Tuesday, January 5, 2021

Receive Antenna RDF Metric

Receiving Directivity Factor (RDF) helps determine the performance of antennas on receive, this is useful with lower HF bands under 10 MHz where noise becomes an increasing problem. RDF is the difference between the peak forward gain and averaged gain in all directions.

RDF value can be calculated using an EZNEC model:

  • Set plot type to 3D, click FF Plot, average gain displayed at the bottom of EZNEC window.
  • In the 3D Plot window click View > Show 2D Plot, the peak forward gain is displayed.
  • Subtract peak gain from average gain, this is the RDF figure.

Here's an example using a LoG (Loop on Ground) phased array I modeled:

EZNEC antenna RDF metric
Click for lager image

Average gain -37.06 dB minus peak gain -28 dBi = RDF of 9.06 dB, which in the world of RDF and receive antennas is respectable.

Reason I post this, is it's easy to find pages discussing RDF and figures of various antennas, but only two places I found mention how to calculate it - Receiving Basics and The Challenge: Receiving Antennas.

More about The RDF Metric.




More can be found by searching for Antenna RDF or Receiving Directivity Factor.

Thursday, December 24, 2020

Phased Arrays - 40m Verticals no Radials

40m phased vertical array using a pair of verticals based on W6NBC's design from http://www.w6nbc.com/articles/2014-QST40mvertical.pdf. These are essentially a vertical dipole with loading in the bottom leg at the feed-point. In the model I created the total height is around 50ft with the bottom end 5ft above ground level. Not needing radials makes this an attractive design if the space available isn't suitable for radials. 

Phasing a pair of them spaced 1/4 wavelength apart using OVF results in good performance with 3.2 dBi gain at 22.5 degrees elevation with over 20 dB F/B, and 10 dB F/B at 7.0 and 7.2 MHz. Matched SWR is 1.5:1 at the edges. I had tried closer spacings but the F/B and SWR bandwidth is significantly narrower

Opposite Voltage Fed (OVF) arrays were developed by Pekka Ketonen OH1TV. His site contains several examples in different configurations, including details on direction switching and matching networks. OVF uses 1/2 wavelength lines, at a common point where they meet a loading inductor is put in series with one line which makes the array directional, and with a relay electrically reversible. An L match network matches to 50 ohms. The system is simple and can offer much broader F/B and SWR performance compared to coax delay lines or current forcing.

A previous post Phased Arrays - Opposite Voltage Fed (OVF) using a pair of elevated 1/4 wave verticals attempts to explain how the transmission lines, loading and matching networks are "wired up" in the model with virtual connections.

Model file W6NBC_40m_Vert_2El_OVF.ez.

Plots:





What's often remarkable about OVF is how well the F/B and pattern is controlled either side of the design frequency.

In the model the first L network is the loading inductor for the "rear" element - no shunt is needed so a 1M ohm resistor represents an open circuit.

The direction of the array is switched by changing which side of the loading inductor is fed. The OVF array articles on OH1TV's site show examples. To reverse the direction in the model change V1 to V2 in the second L network. The second L network is for matching, by chance it only needs a 200 pF shunt.

Current chokes are needed where the feed-lines connect to each element in the array, and the polarity is reversed on one of the 1/2 wave lines.

Other phasing systems? Calculating coax delay lines resulted in line lengths too short to reach a common point to enable direction switching. A model using current forcing works but the F/B and pattern shape degrade quicker either side of the design frequency. An example of the difference between current forcing and OVF is shown in Phased Arrays - 40m Twin Half Square.

The Phased Arrays link at the bottom will show other examples using different systems and antenna types, and how they can compare.

Incidentally it was the idea and a QRZ post about phasing a pair of these verticals several months ago that got me started on the path to modeling and better understanding phased arrays and how the different feed systems work.

-----

Models are good starting point, and a way to investigate and better understand antenna systems. These tools can also help guide us to and validate the final result, if a good correlation is observed in the real world then we can have confidence the patterns and other information are accurate.

The models I have created and made available may contain errors, or overlook something someone more experienced can see. I don't claim to be an expert or authority on the subject of antenna modeling or phased arrays. I simply want to further my own knowledge and understanding of antennas which I find fascinating. Comments, suggestions, discussion are welcome - lonney@gmail.com.

This post is one of several on Phased Arrays.

Monday, December 21, 2020

Phased Arrays - 40m Twin Half Square

Phasing up a pair of half square arrays on 40m. 5 dBi at 23 degrees elevation, 10 - 20 dB F/B, beam-width of 70 degrees, and electrically reversible from an antenna needing less than 40ft height, and no radials.

What is a half square? A pair of 1/4 verticals spaced 1/2 wavelength apart with a wire connecting the tops. They produce a low angle (~20 degrees) bi-directional pattern. They can be corner fed directly with coax or voltage fed at the bottom of one leg, and don't need radials. The current nodes are at the tops which makes them quieter on receive compared to conventional verticals. I built one in early 2020 - see 40m half square which also contains links to more information about them.

One downside with half squares is their narrow(er) bandwidth, and as a result when combined with a parasitic reflector or a pair phased together the F/B doesn't stretch as far compared to dipoles, loops or even verticals before it's half of the peak.

Due to the low angle pattern, and narrower bandwidth, they are perhaps better suited to the bottom half of the 40m band where the DX lurks.


Parasitic Array

While not a phased twin half square array, these have been built and used by at least one ham I know.

A cheap 40m DX machine: the twin half square array by VA7ST uses a parasitic reflector based on info by Cebik which can be found at https://antenna2.github.io/cebik/content/ao/ao11.html.

The simplicity of direct coax feeding is retained when using the second half square array as a reflector. The array is made reversible by having two equal length transmission lines meet at a common point, one is connected to the main feed-line, the other is shorted which resonates the other half square as a reflector. The lengths are critical, by using a model and the transmission lines function its easy to discover which length works best, the coax VF and loss figures in the model use the RG-8X spec as an example. In practice VF of coax being used needs to be measured with an analyzer.

Model file 40m_THS_Parasitic.ez using VA7ST's dimensions.

Plots (7.06, 7.10, 7.20 MHz):




Resonance and min SWR are at about 7.1 MHz with a 1.5:1 bandwidth of 70 kHz. F/B figures:

  • 7.06 MHz - F/B 6.9 dB.
  • 7.11 MHz - F/B 15 dB.
  • 7.20 MHz - F/B 9.48 dB.
F/B and SWR range are narrow, the band segment would need to be chosen for performance. SWR would flatten out a bit with feed-line losses etc as I found with the (single) 40m half square I previously built.


Phasing

Advantages of phased arrays include better F/B over wider bandwidths, broader SWR response, and like the parasitic array also electrically reversible.

Phasing adds complexity which will require test equipment, time and effort, possibly a helper to adjust and validate its working as expected.

With the help of tools like EZNEC and Arrayfeed1 or Feed2EL it's possible to create fairly accurate models of the complete system as it would be built. This enables the ability to see how the array performance behaves over its usable bandwidth, and know what to expect.


Coax Delay Lines

These can be calculated using a model with two sources where one has the desired phase shift, in EZNEC Source Data displays the driving impedance for each element, which can be input into Arrayfeed1 to calculate the line lengths.

In the case with this antenna, the driving impedances presented by the half squares result in "No Solution".



More about this feed system at Phased Arrays - Christman Feed System.

The other feed system type that can be calculated with Arrayfeed1 is L Network, which is known as current forcing..


Current Forcing

Current forcing uses 1/4 wave (or odd multiples of) coax lines and an L network to produce the phase shift. An additional L network can be used to match the system to 50 ohms. Since the coax lines meet the L network at a common point the array can be made electrically reversible.

A Half-Sqaure Array for 40 Meters by N2PD uses the current forcing feed-system, and includes info and diagrams for the L networks, and tuning the array.

I was curious to build a model of it and see how it might compare.

There is a process to work through in order to calculate the L network values which involves a few steps and is fairly easy to do:

  • Start with two source (one source has the desired phase shift) EZNEC model to know the driving impedance at each feed-point via Source Data.
  • Input Source Data into Arrayfeed1, calculates the L network values for the phase shift network.
  • Model (or a copy of it) updated using transmission lines and calculated L network values connected via virtual connections.
  • See if it works as expected, how the array behaves over a given bandwidth, and see the resulting current magnitudes and phase-shifts.
  • Include L match matching network for how matched SWR response looks.

I created a model per N2PD's dimensions which were for the 40m CW sub-band. First thing to note is the F/B quoted in the article is optimistic :-) It may be possible to find a deep 30 dB null at a specific elevation angle but the rest of whats going on back there should be considered too, like maintaining an average across a given bandwidth below a given elevation angle.. This is where the fun starts, adjusting the values of things to find the compromise.

Model file 40m_THS_CF.ez.

Plots (7.00, 7.05, 7.12 MHz):






Current forcing offers better F/B compared to a parasitic array, and with a matching network broad SWR. 50 kHz from design frequency F/B falls to half. The phase shift L network has two values to adjust which could mean trial and error to find the best combination in practice.


Opposite Voltage Fed

Opposite Voltage Fed (OVF) arrays were developed by Pekka Ketonen OH1TV. His site contains several examples in different configurations, including details on direction switching and matching networks. OVF uses 1/2 wavelength lines, at a common point where they meet a loading inductor is put in series with one line which makes the array directional, and with a relay electrically reversible. An L match network matches to 50 ohms. The system is simple and can offer broader F/B and SWR performance.

A previous post Phased Arrays - Opposite Voltage Fed (OVF) using a pair of elevated 1/4 wave verticals attempts to explain how the transmission lines, loading and matching networks are "wired up" in the model with virtual connections.

Model file 40m_THS_OVF.ez.

Plots (7.00, 7.10, 7.20 MHz):




OVF appears to improve further, F/B peaks around 20 dB, and at 100 kHz either side of the design frequency the pattern is neat and F/B is around 13 dB at worst. This array would provide good performance between 7.0 and 7.2 MHz with low SWR when matched.

-----

Models are good starting point, and a way to investigate and better understand antenna systems. These tools can also help guide us to and validate the final result, if a good correlation is observed in the real world then we can have confidence the patterns and other information are accurate.

The models I have created and made available may contain errors, or overlook something someone more experienced can see. I don't claim to be an expert or authority on the subject of antenna modeling or phased arrays. I simply want to further my own knowledge and understanding of antennas which I find fascinating. Comments, suggestions, discussion are welcome - lonney@gmail.com.

This post is one of several on Phased Arrays.