VK5HW AR musings

Tuesday, January 21, 2025

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

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.

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

Commit the change

lbu ci

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

Reboot the system:

web-888:~# sync;reboot

After the reboot check that your syslog configuration is as expected.

web-888:~# cat /etc/conf.d/syslog
SYSLOGD_OPTS="-s 100 -b 7"

Friday, September 13, 2024

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.

Tuesday, July 30, 2024

Excessive Single Side Band Transmission, also know as ESSB or eSSB.

There seems to be an increase in the transmit bandwidth range for SSB communications, which traditionally operates within a narrow-band of approximately 3 kHz. Now if we go with a 3 khz “Voice channel” for Single Side Band (SSB) then the Transmitted Bandwidth, let's call it the TxBW, should fit into the range 0-3000 kHz.

However, I’ve noticed more and more operators use a TxBW of 4 kHz or more. This is often referred to as Extended Single Side Band (ESSB) which I have seen to extend in some instances even to 5 kHz and more. The claim to fame is HiFi Audio.

Now Amateur Radio is an experimental hobby, so this, on the surface, shouldn’t irk anyone, shouldn’t it? However, I frequently encounter ESSB operators on 20 and 40m talking to operators who have not modified their station for ESSB communications, i.e. a station with a TxBW 5 kHz to a station with a 3 kHz Receiver Bandwidth, lets call that RxBW.

So what seems to be the issue?

Let's say a QSO is conducted on 14.229 MHz, one operator uses a TxBW of 2.9 khz and the other uses a TxBW of 2.4 kHz. Signal are good with about S7 both ways. Since this is conducted using the Upper Side Band and, if we apply a Voice Channel spectrum of 3 kHz the used frequency spectrum for that QSO is from 14.229 – 14.231 MHz (not quite but let's stick with 3 kHz). Stations operating on 14.232 MHz should not have any issues operating. However, let's assume one of the operators is operating at a TxBW of 5 kHz. This situation would infringe stations operating on 14.232 MHz quite badly. Another example would be if a DX station is calling on 14.232 MHz and I would like to work that station. However, I will be unable to do so due to the excessive TxBW of the ESSB operator (14.229 - 14.234 MHz).

Anyone see an issue here? Well, I do! However, the question is does the ESSB operator see the issue? From my experience most ESSB operators do not.

So why use 5 kHz TxBW whilst conducting DX contacts. Aren't we trying to share the limited frequency spectrum between all Amateurs? There is certainly NO benefit to the station receiving the ESSB station.

Frequency spectrum during “openings” are crowded and transmitting with a 5 kHz TxBW during these opening does not show any courteousey towards other spectrum users.

The above shows an Australian Operators transmission with a TxBW of 5 kHz and the DX station using a less than 3 kHz “Voice Channel”. I will assume that the DX stations RxBW would not be more than it's TxBW.

NOTE: I’m referring to the TxBW and not the Intermodulation Products (IM) or “splatter”, e.g. the light blue “hair or whiskers” on either side of the signal, which are obvious related but are not discussed here.

This is even more frustrating on the 40m Band, as there are more an more local stations operating with a TxBW of greater than 4 kHz.

Now Amateur Radio is an experimental hobby and experimenting with a TxBW > 3 kHz does fall under this category. So, yes I believe in experimenting but this is not experimenting, this is not understanding the implication of excessive TxBW. And believe me I’m all for experimenting. However, I am quite happy with a 2.4 kHz well balanced audio TxBW which would influence the use of an appropriate RxBW.

Additionally I believe that these operator would not know how much "real" power they are transmitting. If we talk about 400W PEP, then the average output power would be rather LOW.

NOTE: I also observed that these type of operators seem to drop their TxBW to 3 kHz during Contests!?! Yet they seem to believe that during crowded DX sessions it is OK to use 5 kHz or more TxBW. Isn't that a bit hypocritical?

Since Amateur Radio is a self regulating hobby it might be about time to add a frequency spectrum for those inclined to use ESSB. I believe this has been done for certain other modulation schemes (AM/FM/DIGITAL).

Saturday, July 13, 2024

ICOM IC-7610 S-Meter Tracking

Having been checking the S-Meter for my prefered software solutions (SDR) I thought it might be a good time to also (re)check the S-Meter in my ICOM IC-7610. The setup is the same as for the previous two checks. Below is the result of my checks for my IC-7610. A quick graph of how well my ICOM IC-7610 S-Meter is tracking using the proverbial 6dB steps (6dB/S-Unit).

Setup:

Signal generator: XG3
Level: -34.8dBm @ 13.8V
Att: HP-355C & HP-355D (38dB for approx. -73dBm level)
Frequency: 14.175MHz

Result:

CLICK on the GRAPH for a better view.

The graph shows a pretty linear S-Meter for the IC-7610 up to S5 however, it is at 3dB steps. It is not following the 6dB/S-Value IRAU Standard. The above graph has been produce with the PreAmp off.

It is interesting though, that the Attenuator (ATT) values are in 6 dB (6/12/18 dB) steps, which would indicate that ICOM is familiar with the 6 dB scaling value for S-Meters.

Not only would it be nice to have a 6dB per S-Point scale it would also be nice to have S-Value compensation when using the additional Pre-amplifiers.

Maybe a firmware/software update? It is afterall a Software Defined Radio. I would hesitate a guess that it would not be that difficult to implement this kind of behaviour. It has been shown that Amatuer coders can make this possible, even accommodating different receiver gain settings, i.e. compensating for attenuation or amplification.

Here is a note from ICOM's S-Meter blurb for the IC-R8600!

Absolute Value of RSSI (Received Signal Strength Indicator)

The IC-R8600 shows S-meter, dBμ, dBμ (emf) and dBm meter types in the RSSI. The dBμ, dBμ (emf) and dBm meter has a high ±3dB accuracy* (between 0.5–1100MHz) that can be used for measuring signal strength level.

Why can't we have 6dB S-meter steps and have the same display functionality as the IC-R8600 in our IC-7610, why ICOM?

Adjusting the S-Meter for HDSDR

Since ICOM has released Firmware v.1.42 for the IC-7610 the I&Q port is working again. This opened up the possibility to use HDSDR (Sampling rate of 1.92MHz with an effective Bandwidth of 1.66MHz) again. Since I still had the S-Meter check setup "set up" from the "Adjusting the S-Meter in Thetis" I decided to check and adjust, if need be, the HDSDR/IC-7610 combo.

The setup is basically the same as for Thetis, except the SDR in this case is an IC-7610.

Setup:

Signal generator: XG3
Level: -34.8dBm @ 13.8V
Att: HP-355C & HP-355D (38dB for approx. -73dBm level)

In HDSDR under Options [F7] we find Calibration Setting. This opens the HDSDR Calibration Panel.

Selecting the S-Meter Calibration tab:

The current configuration seems to correspond to an S-Meter reading of S9 +10dB on HDSDR:

and an S9 on the ICOM without the Pre-Amp engaged.

So next we add -73dBm to the Correct Level [dBm] field and press the [Calculate] button.

And the result is:

reducing attenuation by 6dB we get:

and, as expected, adding 6dB we see:

So in a Software Defined Radio (SDR) application written by Amateur's we do get the proverbial 6dB per S-Unit.

Friday, July 12, 2024

Adjusting the S-Meter in Thetis

After about five (5) years I resurrected my ANAN 100D again. Trying a few versions, including a development version, I settled on Thetis v2.10.3.5 x64 u2. Seems to be running fine on my Windows 11 system. Quite a few improvements over the last five years. Going through the Setup/Configuration of the system I stumbled over a Level Cal inside the [Calibration] tab which can be found under the [General] tab. This allows one the ability to "automagically" set the S-Meter to a user provided level, .... sweet ....

I've decided to use my trusty old Elecraft XG3 RF Signal Source which I have checked against a calibrated RF Powermeter. At 20m the output at the -33dBm level measured -34.8dBm @ 13.8V. So using an attenuator with 38dB attenuation will give me a -72.8dBm level into the ANAN. A short RG58 cable into a MFJ-1700B switch and another 50cm of RG58 should compensate for the missing 0.2dB to make it -73dBm.

Setup:

Signal generator: XG3
Level: -34.8dBm @ 13.8V
Att: HP-355C & HP-355D (38dB)

And this is how it look in real live.

Here is the Thetis setup:

After pressing the Level Cal [Start] button, the system goes and runs an internal calibration routine. A window pops up to inform us about the progress status of the calibration.

Well, the result is quite pleasing.

And if we add 6dB attenuation we get:

And not to forget if we do subtract 6dB attenuation the result is:

Struth, 6dB steps who would have thought that is a possibility.

Oh and this is at every SSB Bandwidth we choose. My default is 2K1, however if I choose 2K9 the S-Meter still shows -73dBm. Yikes, it is possible! It is software defined after all.

It would be nice if my IC-7610 would not change the S-Meter reading with the engagement of the Pre-Amp(s).

References:

Friday, June 28, 2024

IM improvements using DPD with a SSPA

The question that a lot of users seem to have on their mind is "What benefits, if any do I get by using ICOMS DPD in conjunction with a Solid State Power Amplifier (SSPA)"

Well, I measured a 6dB improvement.

Measurement setup:

DPD off

Two tone test:

Result:

1st Value -31.311dB

2nd Value -31.455dB

3rd Value -52.398dB

4th Value -53.545dB

IM Max -22.2dB

IM Avg -21.6dB

NOTE: 1st and 2nd are the two tones and 3rd and 4th are IM3.

Look at IM3 and IM5, they are nearly the same in strength.

And the below using my Voice Caller calling CQ:

Result:

1st Value -23.996dB

2nd Value -31.168dB

3rd Value -49.526dB

4th Value -53.689dB

IM Max -29.7dB

IM Avg -24.0dB

DPD ON

Two tone test:

Result:

1st Value -31.168dB

2nd Value -31.311dB

3rd Value -58.996dB

4th Value -59.139dB

IM Max -28.0dB

IM Avg -27.8dB

Well, we do see about a 6dB improvement on the two tone test which is better than a Mosquito fart. But I believe the below is quite a good example on how well it improves your VOICE signal!

And below, using my Voice Caller calling CQ:

Result:

1st Value -20.840dB

2nd Value -27.582dB

3rd Value -57.750dB

4th Value -60.143dB

IM Max -39.3dB

IM Avg -34.7dB

On average we see an improvement of 7dB again better then a Mossi fart.

So I'd say any improvement, be it only 6dB is an improvement. As such I would recommend to upgrade the IC-7610 firmware and enable DPD however, YMMV ....

Monday, June 10, 2024

ICOM IC-7610 Firmware Ver. 1.42 DPD IM measurements

A quick update on my IM measurements for the ICOM IC-7610 with the new Version (V1.42). This Version is the third installment for the '7610 and this one has the I&Q output fixed. I've not tested this but I believe that quite a few forum members have done so and are over the moon.

Here are a few IM measurements I made after the Firmware upgrade.

TRX: ICOM IC-7610

SPECAN: SDR-IQ

SOFTWARE: SpectraVue 3.44 Beta 0

TRX Power: 35W

The above shows the output without DPD. About 23dB

NOTE: This is 6db below PEP.

Here we see the same two tone signal with DPD enabled, a nice 54dB down on IM3 and all other IM products are below -140dB. Again, this is 6dB below PEP. So pretty darn good if you'll ask me.

And so the question remains, is it worth to enabled DPD even if we would use an amplifier? I'd say definitely. Using an Amplifier with a much cleaner exciter would give you a cleaner signal (yes yes it depends on a few other things but hope prevails ....)!

Remember GIGO (Garbage in = Garbage out)! This is also true for RF amplifiers not only for Computer Systems.

Nice going ICOM.

See the below pictures how my signal looks over the air. Solid state Amp and DPD enabled.