Digital Pre-Distortion (Puresignal)

Linearity

The linearity of an amplifier states that the output of such amplifier increases linearly with the increase of the input signal.  Which means that if we have an amplifier which has a gain of 10 dB and if we put 1W into the amplifier we should see an output of 10W. Unfortunately, our linear-amplifiers are not that perfect.  Almost all amplifiers behave as depicted below. E.g., they do not follow the ideal.

Due to this nonlinearity our so called linear-amplifiers do create some unsavoury side effects known as Intermodulation Distortion (IMD). Most of us know this as "splatter" ! 

We can see this phenomenon on strong signals where either the poor linear-amplifier is being abused, the exciter is faulty or mis-aligned/configured and/or the IMD products are less than 30 dB down on the fundamental.

If we are fortunate enough to have a panadapter/spectrum display we are able to see and not only hear the IMD, which I might add does contribute to the pollution of our bands. It not only raises the noise level but it also interferes with other amateurs who are trying to use the band.

NOTE: Some IMD is less visible on a standard panadapter display because the IMD is hidden IN‐BAND, e.g., it falls within the bandwidth of the stations transmitted signal. Unfortunately this does add unwanted distortion to the transmitted signal !

Pre-Distortion

IMD is an unwelcome and an undesired by-product of any amplifier. But fortunately there is this method called Pre-Distortion (PD). And it basically works by making our amplifiers more linear by pre-distorting the input signal. Pre-distorting the input signal in such a way as to offset the distortion at the output of the amplifier. Which basically means that we are able to correct the output to behave very much like the Ideal.

no PD applied

PD applied

Please note, that in addition to the amplitude distortion (Pre-Distortion) shown in the above picture, there is also a phase distortion (the amplifier phase shift varies as a function of signal amplitude) which also must be corrected to achieve significant reductions in IMD.

Todays computing power of our Software Defined Radios (SDR) can easily be used to calculate the required corrections required for PD. These corrections are then applied to the digital transmit samples to create a near perfect output signal. 

Because ICOMs DPD implementation in the IC-7610 is one of the set and forget, I will talk about Pre-Distortion as it is implemented in Open Source Software. Please note that the Digital Pre-Distortion is also known as "Puresignal" (PS), as implemented by Dr. Warren Platt in the WDSP library. PS continuously monitors and corrects the output signal of the radio or the linear-amplifier. To be able to do so, the Software implementation requires a second digital receiver and, if a linear-amplifier is going to be used in the PS loop a suitable sensor/sampler (TAP). Which will feed a low power signal into the second digital receiver. This method is called Adaptive Pre-Distortion, as it adapts continuously to the changes in the output signal. 

The above is a simplification of what is going on in the PS loop. The correction is actually performed in the Software (WDSP) and the loop is run in the digital domain of the SDR. 

Do's and Don'ts 

As mentioned above if we use an external amplifier and want to use PS we need a sample of the signal after the amplifier e.g., the signal which is going out towards the antenna. Depending on the sampler/tap used, additional attenuation might be needed to be inserted into the feedback to make sure that the receiver is not going to add additional distortion products to the signal and, of course to protect the sensitive front end of that receiver.

50dB Sampler/Tap

NOTE: MAKE SURE THAT YOUR FEEDBACK IS ALWAYS SUFFICIENTLY LOW (ATTENUATED) SO IT DOES NOT DAMAGE YOUR HARDWARE.

• It is very important that the feedback level does NOT create an ADC Overload situation.
• However, to achieve the best PS results, the feedback level must be as CLOSE as practical to ADC Overload.
• On my ANAN 100D ADC overload occurs at approximately ‐11dBm (at about 180 mVpp). So for best results I make sure that my feedback level stays just above ‐17dBm. 
• Again I can't stress it enough DO NOT CREATE an ADC overload condition.

Memory Effects

There is this phenomena called Memory Effects. I try to explain this as best as I possible can. What this means is that the amplifier gain and phase are not only a function of the current input signal but also a function of past input signal(s), e.g. the amplifier remembers the past. These effects can be temperature and/or bias (PWRS) related. This is most prominent using SSB. The signal into the amplifier changes with speech pattern of the operator and so we have strong signals and weak signals into the amplifier. Suppose that a strong signal send the active device(s) in the amplifier into a hot situation thereby briefly changing its gain and other characteristics. The amplifier will remember this state/characteristics until it cools sufficiently down again. However, in the meantime a number of weaker signals arrive at the amplifier however, they have been predistored for a different state of the amplifier. The end result is PS issues. This is also true for bias and the supply voltages. Which can also change the gain and other characteristics of the amplifier. 

As far as I know, the current implementation of PS does NOT compensate for Memory Effects.

I've not used PS with any Valve type amplifier, but I'm told that it seems to work quite well. Having used PS with a 13.8V 400W - 8dB gain linear-amplifier with voltage supplied from a 60A PWRS, I've detected some memory effects running the amplifier at about 380W output. Dropping the input by 25% solved that issue. There was no issue with the supply voltage, so I assume the issue was more related to heating of the amplifier. However, using amplifiers which use high voltage power FET(s) or LDMOS devices, I have not detected any memory effects.

So a few points to take away from this to minimise memory effects:

• Amplifiers with High-voltage FETs/LDMOS designs seem to either have no or a very low tendency to the memory effect.
• It goes without saying that enough headroom in the PWRS in required to avoid voltage sag.
• Sufficient heat dissipation of all parts, that is for the PWRS and the Amplifier.

Puresignal Correction Bandwidth

Another point to consider when operating PS is, PS correction bandwidth. For PS to be able to correctly compute correction, all IMD products need to be within the bandwidth of the receiver used to receive the feedback of the amplifier. PS can only correct what it can "see" within the bandwidth of the channel. The sample rate dictates the bandwidth of the receiver and since this is set in the firmware to be 48ks, the correction bandwidth would be 48kHz. However, we would need to consider a bit of filter roll‐off and the correction bandwidth would be more like 40 kHz. 

Eg., +/-20kHz from the center frequency.

For most of us that is not an issue however, for some this could become an issue. What it means is that IMD products need to fall within this 40 kHz bandwidth. PS will NOT work well with very dirty signals e.g., signals which are dirty by overdriving the available hardware.

APPENDIX

• The current fav is to use a Hermes Lite, which has about 5W pep output, then add a low voltage intermediate amplifier, before finally driving a tube or a low gain high-power solid state amplifier. If you managed to read all of the above you would have garnered a good understanding now of why that might be fraught with problems. An easier solution would be to forget about the intermediate amplifier and to use a high gain solid state amplifier.

• The effects of Digital Pre-Distortion (Puresignal) (no external amplifier)

2 tone signal without DPD

2 tone signal with DPD

Voice signal without DPD

Voice signal with DPD

• Digital Pre-Distortion as implemented in Direct Sampling SDR.

• Digital Pre-Distortion as implemented in WDSP (Puresignal)

• What is Digital Pre-Distortion
• What is new in WSPR
• To Pre-Distort or Not to Pre-Distort, that ....

A very quiet 5V SM-PWRS

My 5V rail supply, a home build job using a 5V step-down regulator which is being fed of one of my 12V rails is starting to hit its limit at about 40W. If I start up an additional Raspberry Pi the thermal protection activates and the regulator shuts down. Bugger.

Time for a new supply. I have an old (>25 years) AT switch mode power supply (SMPS) which had at one stage been put into service as a bench supply to supply +-5V and +-12V for projects. Since I have upgraded my bench supply this unit was sitting in a box ready to be ....

Anyway cutting a long story short I decided to use this SMPS as the unit to supply the shack with 5V. Now this unit is not the best when it comes to EMI and so I rummaged through my store and found a few items to make the supply as noise free as possible.

Below is the design of the whole supply. This AT-SMPS is a 200W unit. With a rating of 20A for the 5V rail (100W), about 60W more then the current supply. I'm now able to run a few more Raspberry Pi churning away in the shack.

The AT-SMPS has been stripped down to its bare bones and only the 5V rail is being used. Since I already have enough 12V power available in the shack I did not bother with the 12V rail.

All parts fitted nicely into the original case. Here are a couple of photos of the modification.

Here we see the filtering for the fan, a 220µF and a 0.1µF capacitor and a 10Ω resistor to slow the fan down a bit.

And the 5V output stage with the 135µH choke, the 2200µF capacitor and the 0.1µF capacitor to frame/chassis ground.

This is the little Schaffner FN610, a 10A single stage line filter. 10A is a bit overkill but is was the best size to fit into the case. Since the SMPS already had a single stage input filter I hope that an additional single stage would be enough.

Next I started to setup the test bench to see if I managed to quieten the unit down. 

This is a picture of the noise the SpecAn is picking up with only the mag-probe attached. Note the big spike in the middle at 148.7MHz is one of the local pagers. This pager is causing me endless grief. Working on a solution currently, though. 

Note, the Power supply is switched off.

The above picture shows the probe attached to the power cord of the SMPS.

The next picture is with the power supply switched on and the probe attached to the 5V rail.

Note: No load attached to the 5V rail.

The below shows the noise voltage as measure on the 5V rail with the mag-probe.

The next picture is with the probe attached to the 5V rail, SMPS switched on and a load (LED globe) attached. 

We can see that we have a bit of noise from about 13 MHz on wards. However, it is still less than 85 dB down. But we also can see that below 1 MHz  noise has increased, so let's zoom in, to have a better look.

So from about 200 kHz we see a steady increase of noise to about -18dBm at 10kHz. So the VLF spectrum will be still a bit noisy. However, from 200 kHz to 1 kHz the noise is less than -80 dBm and from 1 kHz the noise is below -90 dBm. So I'm happy with the result.

And the noise voltage between the negative rail and the frame ground measure with a 10x probe.

Conclusion

The VLF/ELF noise might be reduced further if a FN610-3 would be use as this unit has 4.5 time more induction than the FN610-10. Reducing the FAN speed has quieten the wind noises so the power supply is also acoustically quiet. The next few days will show if it is as good as the old 5V regulator (or better).

And yes, "Hot Glue" keeps everything in place.

NOTE: This can also easily be applied to a 12V SMPS or the 12V rail in any of the AT-SMPS. Make sure that you use appropriate electrolytic capacitors though (min 16V better 25V).

Appendix

Schaffner FN610

Differential and Common Mode Noise

SNLR, a better way to give a signal report

Or why a 59 report is really meaningless!

A NOTE first: I've labeled this SNLR (Signal to Noise-Level Ratio)  so as not to step on our purists feet. We could just call it SNR as it really a basic form, in an Amateur Way, of Signal to Noise Ratio.

Receiving an S9 signal doesn't automatically mean that the signal is clear and intelligible. The S-meter (or signal strength meter) gives us a snapshot of the signal strength, but it doesn't tell us anything about the Noise Level (NL) or the Signal to Noise-Level Ratio (SNLR), which are crucial in understanding the overall quality of the received signal. A signal might be strong in terms of the S-meter, but if the noise level is similarly high, then the actual communication may be difficult or unclear. Most of today's operators will add an Audio quality report of 5, to make the report 59 which in amateur jargon means that the received transmission supposed to be of excellent quality e.g., an excellent signal. However, to often we hear stations giving a report of 59 or even 59+ only to go on to request a retransmission. Audio quality reports have a scale from 1 to 5 and are given by the operator. With 5 being excellent and 1 being very poor. This relies heavily on the operators HSP, and as we all have experienced, those "Audio reports are ...." well let's say that those reports are not very reliable.

For instance, if the noise level at the receiving station is S8, and the received signal is S9, the SNLR would only be 6 dB. Which would mean that the signal is just slightly stronger than the noise. This could make understanding the transmission challenging, even if it shows up as S9 on the meter. On the other hand, if the noise level is low (say S3) then an S9 signal would be much clearer.

The Importance of SNLR

SNLR (Signal to Noise-Level Ratio) gives us a much better sense of how usable a signal is as it compares the strength of the desired signal to the current background noise. A high SNLR means that the signal is much stronger than the noise, making it easier to decode and work with. On the other hand, a low SNLR means the noise is almost as strong or stronger than the signal, which can lead to poor communication quality or to a completely unreadable signal.

To calculate the SNLR we need two signals, the noise level  and the signal strength of the received transmission, both numbers need to be a power level (dB). And since the levels will be rather small we'll use the Decibel in milli Watts e.g, in dBm.

Determining the Noise Level

Determining the Noise Level (NL) of our receiving system is rather easy, all we have to do is tune to a channel where no signal is present and record the S-Value (for instance, S4 as in my case). 

Next we tune to a channel with a transmission and from the below we can see I've tune to a station which has an S9+10 average signal level.

Converting S-Values to Power

From the IARU Technical Recommendation R.1:

S1 corresponds to -121 dBm

S9 corresponds to -73 dBm

 And the steps between S-Units are in 6 dB increments. This means:

S1 to S2 = -121 dBm to -115 dBm (6 dB increase)

Above S9 we tend to add a dB value to the S9 value, i.e. 

S9 to S9+10 = -73 dBm to -63 dBm (10 dB increase) 

 

click to view larger file

So, to calculate the SNLR:

1. Convert both the received signal strength and the noise level into power levels (dBm).
2. Calculate the difference between the received signal and the noise level (e.g., SNLR = Signal Power - Noise Level).

Using the above values:

Using the above graph we convert the received noise level of S4 to a power level of -103dBm and the received signal level of S9+10 to -63dBm. 

Using the below formula:

 

SNLRdB = (Signal-LeveldBm) - (Noise-LeveldBm) 

  

SNLR = (-63) - (-103)

 

SNLR = 40 dB

This would mean that the signal is 40 dB above the noise level, which is a strong signal and would be very clear.

Conversely, if the received signal would be S9 (-73 dBm) and the noise level would be S6 (-91 dBm), the SNLR would only be 18 dB.

While still a reasonable SNLR, it would be somewhat noisier than the 9+10 example, and we might find that we would need to ask for a repeat transmission occasionally.

Potential Benefits of Using SNLR instead of S-Meter Values

• More Accurate Representation of Signal Quality: 

SNLR considers both the signal strength and the noise level, which gives a much clearer idea of the actual quality of the communication link.

• Increased Context: 

By reporting SNLR, operators would have more information about whether the signal is being received clearly or if noise is impacting communication.

• Noise Awareness: 

Instead of just reporting an S9 signal, one could be aware of how much noise is present at the receiving station. This could help with adjusting the transmitting stations output power, e.g. increasing the output from 100W to 400W, a power level increase of 6dB should in principal add 6dB to the SNLR. Remember bigger SNLR = better signal quality.

Challenges

• SNLR requires additional measurements: 

To report SNLR, operators would need to be able to measure or estimate the Noise Level  (NL) at their location. This can be challenging if the equipment doesn't provide this information directly. Most modern SDR systems do have the ability to read signal strength as a power or voltage level.

• S-meter and SNLR are still subjective: 

While SNLR is definitely more meaningful than just reporting an S-value, it still depends on the equipment's ability to measure signal strength and noise level accurately. Again, most SDR systems are very accurate.

Conclusion

Reporting 59 without any context of the noise level or SNLR doesn't provide the full picture. Shifting to SNLR as a primary metric would give operators a much better understanding of the quality of the received signal. It would not only account for the signal strength but also how well the signal stands out from the noise in the environment, leading to clearer communication and fewer misunderstandings.

Incorporating SNLR reports into amateur radio communication could definitely improve clarity and signal quality perception. Perhaps this is something more operators could adopt in their day-to-day operations.

Most SDR (Software Defined Radio) already have the ability to report the signal strength as a power or voltage level. A few lines of code and the SNLR could additionally be displayed.

Appendix

• HSP  = Human Signal Processor (normally found between the ears)

• IARU Technical Recommendation R.1
• Signal Level Strength Meter Calibration and IARU Standards
• Understand SINAD, ENOB, SNR, THD, THD + N, and SFDR so You Don't Get Lost in the Noise Floor 
• Signal strength and readability report
• Noise Counter-measures
• What is your S-Meter actually indicating
• S-Values are they useful
• A little history about S-Points

How to log FT8 and WSPR to a system log on the WEB-888

The new Version (v2025.0119) has the ability to write to the system log (Thanks Howard).

NOTE: Depending on the storage size of the used SD-Card, the log file could fill up all usable space. This could impact on system performance and might lead to a stale system.

To enable FT*/WSPR logging to the system go to the Admin interface (http://<your web-888 IP-address>:8073/admin) and select the Extensions Tab.

• Select either WSPR or FT8 (left grey area),
• Then set the “Log decodes to syslog” [Yes|No] field to Yes.

As soon as this has been set to yes the system will log to the system log (/var/log/messages).

To check, we can either use the Web-console (Admin interface) or ssh to the web-888 via our favoured ssh-client (I use MobaXterm).

To check if the data is written to the log file.

web-888:~# grep "user.info" /var/log/messages

Jan 21 08:23:31 web-888 user.info : 00:56:31.207 0123456789AB 8 FT8 DECODE: 10137.728 DK9FE JO40 -10 15695km Tue Jan 21 08:23:15 2025
Jan 21 08:23:31 web-888 user.info : 00:56:31.312 0123456789AB 8 FT8 DECODE: 10137.984 IW1CKR JN45 -13 15692km Tue Jan 21 08:23:15 2025
Jan 21 08:23:32 web-888 user.info : 00:56:31.780 0123456789AB 6 FT8 DECODE: 18100.725 JE2GEG PM85 -8 7904km Tue Jan 21 08:23:15 2025
Jan 21 08:23:34 web-888 user.info : 00:56:33.975 0123456789AB 7 FT8 DECODE: 14075.550 BD4VOJ PM01 -11 7681km Tue Jan 21 08:23:15 2025
Jan 21 08:23:46 web-888 user.info : 00:56:46.075 0123456789AB 5 FT8 DECODE: 21075.144 JK4WKO PM54 -6 7831km Tue Jan 21 08:23:30 2025
Jan 21 08:23:46 web-888 user.info : 00:56:46.079 0123456789AB 5 FT8 DECODE: 21075.638 JI1ILB PM96 -10 8014km Tue Jan 21 08:23:30 2025
Jan 21 08:23:59 web-888 user.info : 00:56:59.277 0123456789AB 1 WSPR DECODE: 0822 4 0.2 14.097102 0 VK4TMT QG62 1629 23 (200 mW)
Jan 21 08:23:59 web-888 user.info : 00:56:59.396 0123456789AB 1 WSPR DECODE: 0822 3 0.2 14.097134 0 VK4NE QG62 1629 23 (200 mW)
Jan 21 08:23:59 web-888 user.info : 00:56:59.599 0123456789AB 1 WSPR DECODE: 0822 -14 0.2 14.097073 0 MW0KST IO81 16507 37 (5.0 W)
Jan 21 08:24:00 web-888 user.info : 00:56:59.753 0123456789AB 1 WSPR DECODE: 0822 -15 0.2 14.097018 0 G8MCD IO91 16373 23 (200 mW)

Since we are now writing to the log file constantly it is best to make sure that the log file is being kept at a manageable size. To do so we set up syslogd to roll the log file every so often. For demonstration I’ve setup the syslog configuration file to roll after it reaches 100 kB in size. This size depends on your environment and size of the SD-Card. This is a requirement for your system and as such the roll over size needs to be determined accordingly. 

There are approximately 150 Bytes per line so that should help compute your daily log growth. If the system writes 10 messages per second at an average of 150 Bytes we get about 13 MB a day. 

On my system I have set the log size to 10 MB (10240). This however, can be tailored to individual requirements with up to 99 log files (-b 99)  YMMV!

To set this up follow these steps:

• ssh to the web-888
• and change into the config directory
• cd /etc/conf.d

• create a backup of the original syslog configuration file

• cp syslog syslog.orig

• create a new config file based on log size requirements (-s x) and how many logs we like to keep before overwriting the first (/var/log/messages.0) file (-b z). In the below example I use 100 kB size and rotate up to 7 logs.

• echo "SYSLOGD_OPTS=\"-s 100 -b 7\"" > syslog

• check if we got it right

• cat syslog

SYSLOGD_OPTS="-s 100 -b 7"

• restart syslog

• rc-service syslog restart

• and check if we are logging to the log file

• grep "user.info" /var/log/messages

And as we can see from the below, the log file rolls over at 100 kB.

web-888:~# ls -l /var/log/messages*

-rw-r-----    1 root     wheel        41316 Jan 21 12:02 /var/log/messages

-rw-r-----    1 root     wheel       102543 Jan 21 11:51 /var/log/messages.0

-rw-r-----    1 root     wheel       102542 Jan 21 11:10 /var/log/messages.1

If you like to see a constant flow of messages use the following command. However, do not use this command in the WEB-Console window. [CTRL]+C doesn’t seem to work and as such the console becomes unusable and you need to restart the web server.

web-888:~# tail -f /var/log/messages

Jan 21 08:23:31 web-888 user.info : 00:56:31.207 0123456789AB 8 FT8 DECODE: 10137.728 DK9FE JO40 -10 15695km Tue Jan 21 08:23:15 2025
Jan 21 08:23:31 web-888 user.info : 00:56:31.312 0123456789AB 8 FT8 DECODE: 10137.984 IW1CKR JN45 -13 15692km Tue Jan 21 08:23:15 2025
Jan 21 08:23:32 web-888 user.info : 00:56:31.780 0123456789AB 6 FT8 DECODE: 18100.725 JE2GEG PM85 -8 7904km Tue Jan 21 08:23:15 2025
Jan 21 08:23:34 web-888 user.info : 00:56:33.975 0123456789AB 7 FT8 DECODE: 14075.550 BD4VOJ PM01 -11 7681km Tue Jan 21 08:23:15 2025
Jan 21 08:23:46 web-888 user.info : 00:56:46.075 0123456789AB 5 FT8 DECODE: 21075.144 JK4WKO PM54 -6 7831km Tue Jan 21 08:23:30 2025
Jan 21 08:23:46 web-888 user.info : 00:56:46.079 0123456789AB 5 FT8 DECODE: 21075.638 JI1ILB PM96 -10 8014km Tue Jan 21 08:23:30 2025
Jan 21 08:23:59 web-888 user.info : 00:56:59.277 0123456789AB 1 WSPR DECODE: 0822 4 0.2 14.097102 0 VK4TMT QG62 1629 23 (200 mW)
Jan 21 08:23:59 web-888 user.info : 00:56:59.396 0123456789AB 1 WSPR DECODE: 0822 3 0.2 14.097134 0 VK4NE QG62 1629 23 (200 mW)
Jan 21 08:23:59 web-888 user.info : 00:56:59.599 0123456789AB 1 WSPR DECODE: 0822 -14 0.2 14.097073 0 MW0KST IO81 16507 37 (5.0 W)
Jan 21 08:24:00 web-888 user.info : 00:56:59.753 0123456789AB 1 WSPR DECODE: 0822 -15 0.2 14.097018 0 G8MCD IO91 16373 23 (200 mW)

The following commands can be used to extract data from the log for further processing:

web-888:~# grep "user.info" /var/log/messages > /dev/shm/user.info

web-888:~# grep "FT8 DECODE" /var/log/messages | sed -e 's/.*FT8 DECODE: \(.*\)2025.*/\1/' > /dev/shm/ft8

web-888:~# grep "FT4 DECODE" /var/log/messages | sed -e 's/.*FT4 DECODE: \(.*\)2025.*/\1/' > /dev/shm/ft4

web-888:~# grep "WSPR DECODE" /var/log/messages | grep -v " WSPR DECODE:  UTC" | sed -e 's/.*WSPR DECODE: \(.*\))*/\1/' > /dev/shm/WSPR

These commands will write all WSPR/FT8/4 messages into shared memory, from which we can now copy the data to other systems for further processing.

NOTE: The system log files WILL be removed when a system reboot is being initiated, that includes a power failure! You will need to make sure to backup your data!

UPDATE: 20250226

To make the changes stick, i.e. survive a reboot etc. we need to commit the changes to the boot config file. See the Alpine Wiki for more info.

The lbu command allows us to make changes to the boot configuration. 

1. Check the status: 
• web-888:~# lbu st
• U etc/conf.d/syslog
• web-888:~# ls -l /media/mmcblk0p1/web-888.apkovl.tar.gz
• -rwxr-xr-x    1 root     root         13527 Feb 26 15:04 /media/mmcblk0p1/web-888.apkovl.tar.gz
2. Commit the change
• lbu ci
3. Check to see if the backup worked
• web-888:~# ls -l /media/mmcblk0p1/web-888.apkovl.tar.gz
• -rwxr-xr-x    1 root     root         13529 Feb 26 15:08 /media/mmcblk0p1/web-888.apkovl.tar.gz
4. Reboot the system:
• web-888:~# sync;reboot 
5. After the reboot check that your syslog configuration is as expected.
• web-888:~# cat /etc/conf.d/syslog
• SYSLOGD_OPTS="-s 100 -b 7"

A model of my 40m Delta Loop

At my QTH it is rather difficult to have dipoles strung up at a decent height. As I have had quite good success with horizontal loops (see my old Lazy-D) I decided to install a slopping Delta Loop at this QTH. From what I can tell the antenna is working quite nicely and I am able to make the radio happy with the internal tuner on the following bands, 40, 20,17,15,12,10 and 6m. Now it is not a WONDER antenna however, it does the job for me (YMMV).

Installation details:

• Feed point is 14m above ground (1.5m hockey stick above roof).
• The end corners are about 5m above the ground.
• Feedline, the first 3m are a commercial Ladderline (labeled 450Ω but it might be closer to 390/400Ω), then 20m of LMR-400, 3m of RG213 and 0.8m of RG8 from the ATU.
• The antenna is strung to face towards the East, at approx 110°.

As I also use this antenna as a RX-antenna for ELF/VLF I have removed the BALUN and only use a few chokes on the coax-feedline. Below is a drawing of the antenna.

40m radiation pattern:

As we can see, nothing really to talk about it. Pretty good for NVIS and with a bit of luck, e.g. very good to excellent propagation I might work a little bit of DX.

20m radiation pattern:

On 20m we can see two lobes. One to the East with a nice bit of low angle gain into the East which would help to work short path into the Americas and long path into Europe. However, the high angle lobe seems to be also quite good.

17m radiation pattern:

Even though the VSWR on 17m is not that great, the inbuilt Auto Transmatch (ATM) manages to get the SWR down enough for the Radio and Amplifier to be happy. Losses due to SWR are low enough and don't cause any issue. Looking at the pattern we can see that we have very similar coverage as for 20m. And, as it is for 20m, there is still a high angle lobe.

15m radiation pattern:

Now on 15m we can see that the high angle lobe has disappeared and that there are quite a few usable lobes. There are East and West lobes, with the East lobe quite low and strong, but also quite narrow. Additionally the North and South ones are quite broad with a nice bit of gain.

12m radiation pattern:

As for 17m, the VSWR on 12m is not that great. However, the ATM is able to keep the Radio or Amplifier happy. SWR losses are nothing to worry about. The radiation pattern is very similar to the 15m pattern with noticeable nulls in the North and South lobes. Again, lots of good gain into the East and reasonable gain into the other hemispheres.

10m radiation pattern:

Unfortunately on 10m the pattern starts to create lots of lobes with good low angle gain lobes into the East and West. However, the coverage for North and South is not that great. Lobes are high and not much gain in them.

6m radiation pattern:

Well 6m, what can I say. We can see quite a lot of narrow lobes albeit with good gain.

And yes, I can use the antenna on 6m and have made contacts into Western Australia (VK6), Northern Territory (VK8), Queensland (VK4), New South Wales (VK2) and Japan (JA) however, they have been far and few.

The antenna has been modeled with real ground (poor) to give me an indication of what I can expect at my QTH. However, it is not a true indication of the actual radiation pattern, there is a House behind the antenna (to the west) which will change the characteristics of the antenna performance especially into the westerly direction.

As with every antenna the impedance (Z) changes with height, soil conductivity and of course surroundings. This will dictate what type of Feedline and or BALUN one would/should/could use, there is no silver bullet. I do use an Antenna Analyser (VNA) to learn what the actual Antenna System (Antenna + Feedline) Z at my installation is, e.g. what my ATM would be presented with. This does help me to use what feedline and/or BALUN etc. I would use to configure the antenna-system to my requirements e.g. adjusting the antenna at a frequency of 7.2MHz to create easier matchable impedances for the additional Bands/Frequencies I would like to operate on.

According to my previous model of a Delta Loop used as a Horizontal Loop (LAZY-D) the Z was approx. 100 +j10Ω at resonance, which would mean that a 2:1 BALUN would be the right choice to get a good 50Ω match. 

Compared against the previous installation, this model tells me that I could except the Z to be > 200Ω which would indicate that a 4:1 BALUN would be needed to get a good 50Ω match. 

If you'd like a bit more information on Delta Loop antennas, a good educational read is the work of W4RNL (SK). His notes on Delta Loops can be found here. 

So to wrap it up, the block does not lend itself for the installation of a multiband dipole type of antenna (G5RV or ZS6BKW) so the next best thing for me was to grab something out of my box of tricks and go back to an old, but proven concept.

I didn't really wanted to add an VSWR prediction chart but due to multiple requests, here is a quick SWR plot of the modeled antenna:

Here are some SWR plots whilst I was still using a 1:1 BALUN. And a view of how the antenna performs can be found here.