Duplicate a RS232 serial port to use ARCP and WSJTX/JTDX at the same time

In the last few months, I have been quite active in the early morning on the 160 and 80m bands. I use a remote station located in Ostia Antica, about 15 km from my home QTH. In this rural site, there are no limitations on antenna size, unlike in urban environments.
The transceiver I use is a Kenwood TS-480HX connected via serial port to a PC running the still very good Kenwood software ARCP.

Everything works fine for CW, but for FT8, the JTDX software cannot be connected via CAT to the transceiver because its serial port is already occupied by ARCP.

Until now, JTDX was set to “Transceiver None,” and band changes were made manually on ARCP (RTX) first, then on JTDX. If I forgot to change the band on JTDX, the QSOs were automatically logged on the wrong band, and I spent a lot of time fixing them.

Another annoying problem when using JTDX without CAT control is the frequent need for TX audio level adjustment to maintain a constant output power while the TX tone frequency is close to the edges of the SSB filter. With working CAT control, on the contrary, it is possible to set the “Split Operation” parameter to RIG or FAKE IT and keep the tone at the center of the TX filter all the time.

So, I researched how to split the serial port to allow two programs to work together and stay synchronized with the rig. I thought it would be easy with socat for Linux and com0com for Windows. The issue arose when ARCP connected to the transceiver. The Kenwood software sets the AI2 mode, and when the AI2 command is sent, the transceiver outputs any parameter variation on the serial port without being prompted (no polls). This results in a large amount of data being sent over the port. JTDX doesn’t handle this type of traffic and fails to connect to the radio.
The idea was to filter the traffic directed to JTDX so that it only receives the responses to its commands without the extra data generated for ARCP.

It worked!

Below tools and commands I used, they can be helpful for someone trying to manage multiple programs interacting with a single transceiver over a serial port.

• the transceiver is connected via RS232 to a physical port on the PC /dev/ttyS0
  
• the program ser2net opens the serial port /dev/ttyS0 and creates a TCP socket server on port 10000
  
• the first virtual serial port is created to feed the ARCP control software which runs in wine.
  wine looks for the serial ports in the folder /home/user/.wine/dosdevices/ therefore the command
  /usr/bin/socat PTY,link=/home/user/.wine/dosdevices/com4,raw,echo=0 TCP:localhost:10000
  creates the virtual port com4 in that folder linked to the actual port /dev/ttyS0
  
• the second virtual serial port for WSJTX/JTDX needs to be filtered, so the command is a bit more complicated.
  
  1- Create a FIFO special file with the command mkfifo jtdxfifo
  
  2- create a text file filter.sh in /home/user/ with the following content
  /usr/bin/stdbuf -i0 -o0 tr ';' '\n' | /usr/bin/grep --line-buffered -e IF -e FA -e FB -e MD -e FW -e AI | /usr/bin/stdbuf -i0 -o0 tr '\n' ';'
  then make it executable with chmod 775 filter.sh
  
  3- execute this long command to create the virtual filtered port ttyTS480 for WSJTX/JTDX
  /usr/bin/socat - "TCP:localhost:10000" 0<jtdxfifo | /usr/bin/socat - "exec:/home/user/filter.sh" | /usr/bin/socat - PTY,link=/home/user/ttyTS480,raw,echo=0 1>jtdxfifo
  
• launch ARCP480 and connect it to the port com4
  
• launch JTDX and configure the filtered radio port
  
  
  
• You’re done!
  

Just a few words about the data filter…
The preamble /usr/bin/stdbuf -i0 -o0 instructs the system to disable the input and output buffer in order to obtain data output for each line input without waiting the filling of the whole buffer.

The CAT Kenwood commands and replies are all terminated with semicolon. The command tr ';' '\n' replaces the semicolons with a carriage return because the next command grep works with lines.

The grep command /usr/bin/grep --line-buffered -e IF -e FA -e FB -e MD -e FW -e AI simply outputs only the lines that start with IF, FA, FB, MD, FW and AI. Those are the only CAT keywords that WSJTX/JTDX wants to receive.
The last command tr '\n' ';' puts back the semicolon in its place to restore the CAT Kenwood syntax.

Probably all this can be done in different and better ways. However, this works for me.

WSJTX/JTDX: how to share the log between different sessions

Most of us use K1JT’s digital modes on different bands and often different bands means different transceivers running at the same time. Each transceiver needs an instance of WSJTX/JTDX configured with CAT (optional) and audio sink/source (mandatory).
Start multiple WSJTX/JTDX sessions is quite easy, you just need to copy and paste the existing desktop link, edit the new link and add “--rig-name=TS590” at the end of the command line. Replace TS590 with the model of your rig.
This will create a new folder with config data and the new instance is completely independent from the original one, log file included.

So we will have two or more different logs. If the logs are related to different bands e.g. 50 MHz and 144 MHz this is still acceptable but if the logs refer to QSOs on the same band this can lead to confusion because WSJTX/JTDX could warn us for a new DXCC while we have already worked it with the other transceiver :-S Not to mention the risk of annoying dupes…

The problem can be solved by using the same log file for both instances in read/write.

In Linux it’s easier because a symbolic link to the original log created in the new instance folder does the job. In Debian based distributions the folders are located as example in /home/username/.local/share/JTDX and /home/username/.local/share/JTDX - TS590

In order to have the logs synchronized between the sessions the commands are:

$ ln -s <original_file> <linked_file>

Assuming the actual log is in /home/username/.local/share/JTDX folder the commands will be

$ ln -s  /home/username/.local/share/JTDX/wsjtx_log.adi  "/home/username/.local/share/JTDX - TS590/"

$ ln -s  /home/username/.local/share/JTDX/wsjtx.log  "/home/username/.local/share/JTDX - TS590/"

To confirm that the links is correctly created, list the new folder:

$ ls -la "/home/username/.local/share/JTDX - TS590" | grep "\->"

feb 12  2022 wsjtx.log -> /home/username/.local/share/JTDX/wsjtx.log
feb 12  2022 wsjtx_log.adi -> /home/username/.local/share/JTDX/wsjtx_log.adi

You may link files also if they are shared via ethernet, example I have a main server at home that keeps the original wsjtx_log that it’s linked to the WSJTX folders of different PCs connected to different rigs.
When I add to the log a QSO from any PC, also outside the local network (e.g. field day), the QSO is saved in my main server at home.

Windows is limited in file linking but the trick to share the same log between the WSJTX instances can be still used with some restrictions.

In Windows we have to use the Hard Links instead of the Soft Links that doesn’t work for WSJTX.
The Soft Links are those created with the right mouse key -> Create Shortcut.

In order to create a Hard Link in Windows command prompt, the syntax is

mklink /H original_file linked_file

Assuming the actual log is in the c:\users\username\appdata\local\wsjtx folder, the commands are:

mklink /H C:\Users\username\AppData\Local\WSJTX\wsjtx_log.adi C:\Users\username\AppData\Local\WSJTX - TS590\wsjtx_log.adi

mklink /H C:\Users\username\AppData\Local\WSJTX\wsjtx.log C:\Users\username\AppData\Local\WSJTX - TS590\wsjtx.log

The Windows restriction, or better the NTFS restriction, is that the hard link works only if the original file and the link are both on the same volume, C: D: etc. so, in that way, no share via lan to other PCs.

FT8 on VHF and grid squares…

After a 6m intercontinental opening with USA East Coast, that happens quite often in June/July, I received an email message from one of the OM I had FT8 QSO with.
He said “Hello, our QSO is complete but I can’t add the QSO in my log because you never sent your gridsquare.”

Sometime the people make their own rules based on nothing, fortunately there are common rules discussed and approved by international organisations like IARU and applied for decades by several generations of radio amateurs.

The most recent document I found about this topic is VHF Handbook (V 9.01), Part4 Chapter 2.1 “Minimum requirements for a valid QSO”. The same concept is reported in many other publications and they all say the same thing:

A valid contact on VHF and higher bands is one where both operators during the contact have:

– mutually identified each other, and
– received a report, and
– received a confirmation of the successful identification and the reception of the report.

The QTH-Locator is not even mentioned, it’s a completely optional info that is sent to help the correspondents in turning the antenna in your direction.

It cannot be otherwise because on VHF+ usually the propagation conditions change fast and may happen that a S9 signal suddenly disappears at the next “over” so there is no time to wast in sending unnecessary data.

If interested the gridsquare can be recovered in several ways, databases, qrz.com or email message…

In the light of this I never send my grid for VHF DX QSO and in particular for FT8 QSO because FT8 is much slower than other modes. Without the gridsquare message, a FT8 QSO is reduced of 30 seconds, and can be completed in 45 seconds giving more chances to other operators to make the same contact.

If you decode me in FT8 and you’re a DX, call me with the report!
I’ll give priority to the callers with report over the callers with grid.
If you are not a 6m DX, e.g. you transmit from EU, don’t call me at all because we could easily have a CW/SSB QSO instead.

The funny part of this history is that I went to qrz.com to search who is this genius of the no-grid-so-not-in-log nonsense and I found in his online log that he logged a QSO without grid!!!
A master of coherence, LOL!

The simplest TXRX sequencer for LNA in the world!

From 50 MHz to 10 GHz I use LNA for any band because there is a certain distance between shack and antennas and the cable loss makes me almost deaf without.

I tried any sort of sequencer over the years and burned a lot of LNA devices during my HAM activity. Most of the time it was my fault during tests and preliminary setup. With this sequencer it will no happen anymore (hopefully!)

The diagram is simple: when the sequencer is supplied with +12V the voltage passes through the Normally Closed relay contact and, if the manual switch “PRE” is turned on, goes to the preamplifier on the roof. At the same time the negative voltage generator is turned on and sends to the transceiver ALC input a negative voltage set by the trimmer R4. This negative voltage completely chokes the RF even if the transceiver is keyed.
When the transceiver goes to TX, the relay switches and removes the supply voltage to preamplifier and negative voltage generator and closes to GND the amplifier’s PTT.
After some time, when the 2.2 uF electrolytic capacitor discharges, the transceiver outputs RF.

The negative voltage generator is a fully insulated ultra-cheap DCDC converter B1212S.

It can be purchased for about 1 euro on the usual Chinese websites.

This DCDC converter can deliver up to about 80 mA, there is lot of headroom for this use.

I realized a prototype that is currently in use on 2m band connected to my IC-910H.

In the picture above the block diagram of my station. With the power supply powered off, the preamplifier is off too and the antenna is connected to an SDR dongle in RX on the FT8 QRG 24/7. When the 12V power supply is turned on, the transceiver starts and it’s ready to be used with or without PRE and PA depending on the manual switches status of the sequencer box.

After some use I can write the pros and cons of this approach.

PROS

• It’s made using a few components of general use: 1 DPDT relay, 1 optocoupler, some diodes, resistances and capacitors.
• No microcontrollers/Arduino needed.
• Failsafe-foolproof: if the relay fails or if the LNA is supplied in some other way, the transceiver does not outputs RF.

CONS

• The transceiver needs a certain time to emits RF after the microphone/key closure. This time can be varied by choosing the value of the electrolytic capacitor on the ALC line (or removing it), but most is due to the ALC decay time of the transceiver and can’t be modified easily. Tested on Icom IC-910H it’s less than 0.5 s that’s ok for FT8 but can be too slow for CW/SSB without training (close PTT, wait, send the message).

Spring Equinox 2023 6m in Rome

The night of March 12th on 6m band there was an impressive opening that I will remember for long time.

It all started in the early afternoon with Hong Kong (VR) worked trough a skewed path beaming the antenna to 120 degrees, Indian Ocean. Then the path rotated gradually to South America but, a detail to note, almost no African stations received.
Several countries worked/heard for many hours: PY, LU, ZP, CX, CE and, with a sort of backscatter, some Center America stations like J79 (new DXCC!) and KP4.

Around 22.30z the signals strength was reducing but still some Brazilian were decoded. At a certain time I noticed that many PYs and some LUs were calling E51WL in BI01, North Cook Island. I followed them for a while but none I saw was sending reports, they just calling him. The PY signals faded away and I thought the big opening was definitively over when E51WL appeared on my screen. Jump on the chair. I Immediately called him and completed the QSO in a few periods. Other Italian 6m stations started to call Cook Island but no more valid QSOs, although some of them has received the QSL later because “heard with big signal”…

Moral: it’s when the band become silent that the magic things happen.

The updated DXXC status (including 2022 ES) on 6m is:

2022-06-12 JD1BLY Ogasawara FT8

2022-06-30 7O/DL7ZM Yemen CW (!!!) (video recorded by IW0HEX)

2022-07-06 FP/KV1J St. Pierre e Miquelon FT8

2022-10-23 3C3CA Equatorial Guinea FT8

2022-09-12 TO7GJ Mayotte FT8

2023-03-12 J79WTA Dominica FT8

2023-03-12 E51WL North Cook Island FT8

2023-03-18 TG9AJR Guatemala FT8

2023-05-06 8Q7KB Maldives FT8

Total 203 CW + 26 FT8 = 229 DXCC entities/ 19 years

LOTW unconfirmed FT8 QSOs [SOLVED]

LOTW is the well known ARRL log online useful to match and confirm contacts between the radio operators without the need to exchange paper cards.

JTDX is one of the most used weak signal decoder/encoder software in use by the HAM radio community. JTDX saves QSO in ADIF format to the wsjtx_log.adi file. This file or a part of it, is periodically sent to LOTW, automatically or manually.

JTDX records, for each QSO, the start and ending GMT hours formatted as example

<time_on:6>120802 <time_off:6>120944

It may happen, during the normal activity, that you start calling a station and keep calling for a long time or stop calling him and continue after a pause. This often happens with OM of rare countries, rare squares or DXpeditions.
When finally the rare DX answers, 73, QSO logged and time_on differs from time_off of several minutes (hours?).

The rare DX station, on the contrary, saves your QSO in his log with time_on reasonably very close to time_off.

When both upload the log on LOTW, the QSO will be validated only if the two time_on values differ of maximum 30 minutes.

Kudos to Sergio IK0FTA who discovered the flaw.

I don’t know why LOTW use time_on instead the more logical time_off to match the QSO, there will be a reason for sure, I hope. However the solution is simple: edit the file wsjtx_log.adi and modify the time_on of QSOs that last more than 30 minutes to make them shorter.
Too many QSO to check ? There is a script :-)

#!/usr/bin/env python2
# coding=utf-8

import time
import sys
import os
reload(sys)
sys.setdefaultencoding('utf8')

def printfound(line):
    print "\nLong QSO detected!"
    print "##################"
    print line
    print "##################\n"

with open("./wsjtx_log.adi", "r") as myfile:
    with open("./fixed_qso.adi", "w") as outfile:
        outfile.write("Time_on fix for LOTW - IW0FFK 2022\n<EOH>\n")
        print "> Log found"
        for line in myfile:
            if "<time_on:6>" in line:
                rawtimeon = line[line.index('<time_on:6>')+11:line.index('<time_on:6>')+18]
                rawtimeoff = line[line.index('<time_off:6>')+12:line.index('<time_off:6>')+19]
                hh_on = int(rawtimeon[:2])
                hh_off = int(rawtimeoff[:2])
                mm_on = int(rawtimeon[2:4])
                mm_off = int(rawtimeoff[2:4])
                ss_on = int(rawtimeon[4:])
                ss_off = int(rawtimeoff[4:])

                if hh_on == hh_off:
                    if (mm_off - mm_on) > 25:
                        printfound(line)
                        outfile.write(line[:line.index('<time_on:6>')+11] + str(hh_off).zfill(2) + str(mm_off-1).zfill(2) + \
                        str(ss_off).zfill(2) + line[line.index('<time_on:6>')+17:] + '\n')
                elif (hh_off - hh_on) == 1:
                    if ((mm_off + 60) - mm_on) > 25:
                        printfound(line)
                        outfile.write(line[:line.index('<time_on:6>')+11] + str(hh_off).zfill(2) + str(mm_off-1).zfill(2) + \
                        str(ss_off).zfill(2) + line[line.index('<time_on:6>')+17:] + '\n')

                else:
                    print "Very long QSO or data inconsistencies"
                    print line
                    print "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
                    outfile.write(line[:line.index('<time_on:6>')+11] + str(hh_off).zfill(2) + str(mm_off-1).zfill(2) + \
                    str(ss_off).zfill(2) + line[line.index('<time_on:6>')+17:] + '\n')
                                                                            

Copy and paste the code above into an empty text file and save as adif4lotw.py.

Copy adif4lotw.py file into the JTDX log folder and run the command

python2 adif4lotw.py

A new file named fixed_qso.adi is created containing the suspicious QSO with the time_on value corrected and set close to time_off.

This file can be uploaded to LOTW.

If you use Python3 instead of Python2, it should be easy to modify the script to make it work.

I tested this script in Linux and works fine, probably it works also in Windows or OSX with Python installed.

Using the script I recovered about 15 QSO confirmation and three new squares ^_^

I don’t know if also WSJT-X has this problem, worth to check.

Magic night on the magic band

Rome 8 March 2023

I am writing this post just to fix this date for future reading.

In these days with the solar activity growing in its cycle, we are experiencing strong TEP/F2 openings on 50 MHz.

Almost everyday there are paths to 3B8, 3B9, FR, ZS, V5 and the afternoon/evening with PY/LU.

Some lucky italian station worked also FK, 3D2, VK. Here in Rome just three decodes of FK8CP, not enough to complete a QSO.

Last night around 23z I was sleeping, and my 24/7 QRV SDR receiver started sending messages to my Telegram account.
The phone was ringing loud and finally I woke up. What I witnessed was a JTDX screen full of Japanese stations calling and my beam was directed to South America! The possibility of contacts with the Japan Long Path is well known, in Rome it was already happened before for three days in October 2000, October 2001 and March 2002.

During about 1 hour long opening with QSB signals I completed about 10 JA QSOs plus PY6BK and PY6ZL in new field HH.

The JA lines in the screenshot below have been wrongly traced short path, the Pskreporter software don’t know how magic the six meters band is.

ES Season 2021

It’s a bit late to write about the last VHF ES season, but it was the best of the last 30 years and over and it is not possible not to write about it on my blog.

On 6m we had several openings with North and South America, not only the usual countries facing the Atlantic.

We (me and some other lucky OM in Rome) worked a miracle QSO with KL7HBK (Alaska) that worth the whole season…
KL7HBK was monitoring 50.313 while suddenly has received some decode from a station in Rome working EU stations.
Immediately he started to call him, but no QSO. Everyone on the KST chat got their feelers out and the first in JN61 who completed the QSO was Tony I0JX….thanks Tony for the wake-up call!!!
This is a screenshot of the KL7HBK landing zone in South Europe.

A big surprise was Nepal, I was drinking my coffee in the early morning and looking the tablet with the FT8 screen when I’ve seen a decoded text in the “new country” color, so I clicked without reading the callsign…

Other remarkable QSOs are with Australia, in three days worked VK4MA – VK2EFM – VK3BD – VK3DUT – VK3WE and the new ODX 16320 km VK2WJ

To complete this amazing 6m season must to mention the great openings with the US West Coast with about 15 contacts in DN DM and CM fields.

To sum up the new countries worked on ES 2021:

AP2HA Pakistan #202 CW + 11 FT8

9N1DX Nepal #202 CW + 12 FT8

HC2DR Ecuador #202 CW + 13 FT8

KL7HBK Alaska #202 CW + 14 FT8

TI5CDA Costa Rica #202 CW + 15 FT8

V31MA Belize #202 CW + 16 FT8

YI1SAL Iraq #202 CW + 17 FT8

On 144 MHz great fun too with frequent and long openings to the Middle East. Israel worked several times and finally a new country: OD Lebanon.

To the West, after several years Madeira finally arrived in Rome on 144 MHz. I’ve already worked that country in 2006 SSB and it was a pleasure to do it again in FT8.

Another new country worked on 2m band has been Albania. It’s not so far from Rome but it’s covered by the mountains. Worked during a very strong and short ES opening.

OD5KU Lebanon #71 2m

ZA/IW2JOP Albania #72 2m

That’s all for now

Almost universal panadapter with Malachite SDR

I bought a Malachite SDR with the main purpose to find the noise sources all around my antenna like faulty led bulbs, neon lamps, battery chargers etc. but I discovered that it can have a more valuable use.

When the little receiver is connected via its USB port to a personal computer, a new serial port appears.
In Linux/Raspberry it’s mapped to /dev/ttyACM0
Sending Kenwood CAT commands through this port permits, among other things, to set the tuned frequency so it was an easy task to write a minimal Python script that reads the transceiver’s frequency and writes it to the Malachite periodically. The effect is that the Malachite follows the transceiver’s QRG, like a real panadapter.

The RF is sampled in the transceiver’s RX path just after the preamplifier and before the first mixer, usually there is a ready-to-use connector on the pcb designed for the alignment procedure.

Instead to use the serial port where the transceiver is connected to, I choose to interface it with the Hamlib rigtctld utility.
Rigctld permits to control via CAT almost any transceiver with a socket connection over the network instead of the serial port. This is a big advantage because the serial port can be opened only by one application at time. With rigctld there is no the single app limit and, as example, the python script can run simultaneously to WSJTX and/or a log program that need the CAT connection to the rig.

This is the command line I use to start the rigctl daemon:
rigctld -v -m 214 -r /dev/ttyKNW2000 -s 9600 –C serial_handshake=None -t 4532

• -v means “be verbose”
• -m 214 is the rig model, Kenwood TS-2000 in this case (see the rigctl man page)
• -r /dev/ttyKNW2000 is the serial port physically connected to the rig
• -s 9600 is the baudrate
• -C no handshake needed
• – t 4532 is the TCP port where the daemon listens for connections

In order to test if the rigctl daemon is running, just connect it via telnet and send the command “f” (lowercase and without quotes), if the reply will be the tuned frequency in Hertz, the daemon is working.

The following videos show how it works

Below the Python2 script code, probably it works in Python3 too but I haven’t tested. Copy and paste it to a text file and save to panadapter.py then run python panadapter.py

import socket
import serial
import sys
import time

TCP_IP_RIG = "127.0.0.1"
RIG_PORT = 4532
MALACHITE_PORT = "/dev/ttyACM0"

MESSAGE = "f\n"

rig_freq = 0
old_rig_freq = 0

serMAL = serial.Serial()
serMAL.port = MALACHITE_PORT
serMAL.baudrate = 19200
serMAL.timeout  = 0.1

try:
    serMAL.open()
except serial.SerialException, e:
    print("Can't open serial port %s: %s" % (serMAL.portstr, e))
    sys.exit(1)    

def getfreq(TCP,PORT):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 
    server_address = (TCP, PORT)
    sock.connect(server_address)
    sock.sendall(MESSAGE)
    amount_received = 0
    amount_expected = 8 #len(message)
    while amount_received < amount_expected:
        data = sock.recv(16)
        amount_received += len(data)
    sock.close()
    return data

def setfreq(freq):
    serMAL.write("FA" + freq.zfill(10) + ";\n")

while True:
    time.sleep(0.25)
    rig_freq = getfreq(TCP_IP_RIG, RIG_PORT) 
    #print "TS2000 freq:" + rig_freq

    if int(rig_freq) != int(old_rig_freq):
        #print "MALACHITE freq set to: " + str(rig_freq)
        setfreq(rig_freq)
        old_rig_freq = rig_freq
   

Antenna rotator voice control with Alexa

This is a simple Node-Red application to use Amazon Alexa as a voice interface to set and get the beam direction.

The same thing could be made without the use of Node-Red, but thanks to the node-red-contrib-alexa-remote2 the implementation is a whole lot easier.

The rotator controller, described in a previous post, is connected to the same WLAN of the echo device.

It’s worth to say that there is no a special Alexa skill activated. Node-Red catches the voice commands, take decisions and sends to the echo device the appropriate text to be pronounced.
Alexa doesn’t know the command “Antenna”, indeed the first Alexa reply is the error sound (dong…) and this can’t be avoided.

Here a short video (in Italian language) to show how it works:

2020 VHF Es season in JN61

I’m writing in the first week of September 2020 and I can say that the ES season just ended, was the best one since I started to follow the ES openings on 144 MHz and multihop ES openings on 50 MHz.
Here in Rome, and probably in the whole northern emisphere, we had strong and sometime unexpected openings never seen also by OMs older than me in over 30 years of constant activity on air.

Probably half of the credit is of the FT8 digital mode that was extensively used by the whole VHF DX Enthousiast community on both the bands.
As said before, the fact of being all tuned on the same frequency, 50313 and 144174 kHz and the real time map offered by PSKREPORTER.INFO permits to detect and sometime to predict the ES openings.The system works even if no one is answering to our CQ because the “spot” to Pskreporter is automatic.
In light of the above, the old way to check the various beacons to know the opening landing zone, is today obsolete. The VHF beacons themselves become obsolete, but they are still useful for local tests.

The season started early this year, on 6m the first logged European was the last week of March, the first multihop the mid-April. In End-April, during the Italian Covid19 lockdown,  the middle East was seen almost every day with a new country worked on 6m 7Z1SJ (Saudi Arabia) in FT8 and CW  #202 CW + 8 FT8
Early ES also on 144 MHz on May the 1st CT1BYM in IM68 then the same day in the late afternoon, HK4SAN (Colombia) on 50 MHz #202 CW + 9 FT8
With a crescendo on 50 MHz worked before the May end:  Puerto Rico, Guadeloupe, Cayman Island, Barbados, Brazil, Trinidad & Tobago, Kazakhstan, Bahrain, Japan, Taiwan, Hong Kong, Oman, West Malaysia, Western Sahara, USA, Canada, Vietnam, China, Dominican Republic, Anguilla, Haiti, Aruba and Mexico.
Just a note, K0GU in Colorado was the first US contact worked on 17 May and he was also the latest US contact on 16 August when everyone thought the season were already over, and Colorado is not the easiest State of the US to work from Europe!

The greater surprise of May was an exceptional QSO (ES + Sea duct I think) with D4VHF (Cape Verde) on 144 MHz >4500km ODX and DXCC #70
I was driving home from work and I received the alert via Telegram: my transceiver at home was receiving Cape Verde on 144 MHz !!!

I tried to be faster than ever and reached the shack after 15 minutes with the feeling to have lost the chance for the QSO. Fortunately after about 1 hour I received again the D4VHF CQ and this time I was ready to answer and complete the contact :-)

The day after this event, the 29 May 2020, will be remembered as the biggest and largest and longer 2m ES opening in Europe of last 30 years. It lasted more than three hours and every “single hop country” was heard or worked. I have deliberately avoided to answer stations already worked in the past, to avoid QRM and permit the newcomers to work them. It seemed to be tuned on the shortwaves. Amazing.
Here the report on MMMonVHF website .

50 MHz on June was full of JA openings in the morning, hundreds of Japanese stations in the log, over 40 JA stations decoded in a single receiving period!!!

Unfortunately the first days of June I damaged my 400 Watts solid state PA that I use when I work remotely. So I transmitted with 100 Watts for the rest of the season. On 7 June worked Indonesia, YB0IR was the first of five Indonesian OM worked in the following days #202 CW + 10 FT8
Indonesia was never heard in Rome for 30+ years and it was a new country also for some BIG nearby.
The same day I have in the log Australia VK8AW in JT65 mode, 13200 km.
On 15/06 worked Arizona, DM32 DM42 DM33 and DM43 squares then finally the long awaited California opening on 22/06, CM95, CM98, DM03, DM04, DM15 with about ten different stations worked during a two hours opening.

To complete the report, must mention Sergio IK0FTA that discovered an important and useful correlation: when we receive the French station F8DBF in IN78, North-West of France, Brittany, there is a very high probability to cross the Atlantic and have QSO with USA from Rome. The curious thing is that if F8DBF works Europe only and has no contacts with USA stations, we have good chances to work USA, BUT if we receive F8DBF working USA, there is no way for us to work USA too.
This event has been noted a number of times on 2019 and 2020 and we consider it as a fact.

Improved WiFi rotator & actuator controller

During the recent lockdown for the COVID19 pandemic, I had the time to learn the HTML5-CSS3-JavaScript basics with the purpose to enhance the interfaces look of the various Internet of things around.

I’ve played with the vectorial graphic that permits to draw and animate objects in a web page. The great advantage is that there is no need to have a dedicated client program to control the things, just a modern browser and everything works indifferently on PCs and mobile devices.

As training I’ve tried to replicate the YAESU G400/G650 graphic because I feel it very confortable and easy to read, after years on the desk.

With this approach the WiFi microcontroller ESP8266 hosts a simple web server and a websock server for telemetries and commands.
To control the rotator, it’s possible to use the web interface with the browser or the websock only, one can write a command translator to make it compatible with the common rotator protocols e.g. GS232A, GS232B etc. An example is the Telegram bot I use for mobile operations.

The following video shows the Telegram Bot functioning:

The microcontroller is the D1 mini version board, the one with the  “external antenna” option.

Make sure the 0 Ohm resistor is connected to the right path to the external antenna instead of the internal one, as specified in a previous post

On the same line I’ve updated also the WiFi controller for the dish linear actuator “Superjack HARL” or similar. The controller counts the reed pulses during the movement and reads the absolute tilt degree from an AD345XL module

Microcap 12 is free

The Spectrum Software, a company that produce the well-known electrical simulator “Microcap” since the 1980s, is shutting down and now their product became free. Thanks!

The latest release can be downloaded on their website: https://www.spectrum-soft.com/download/download.shtm

Microcap 12 is written for Windows but works fine also in Linux and macOS (wine)

The small Polish 10GHz transverter

In 2018 with Pino IK0SMG, Emilio IK0OKY, Andrea IW0EAC, Giuseppe IK8XFR and other local microwave enthousiasts, we bought a set of 11 GHz transceivers from a Polish surplus seller on Ebay for about 50 eu each. The objective was to use them in the 3cm HAM band, 10368 MHz.

We didn’t found much infos about it on internet, so we started to draw a schematic in order to know what the values of the various supply voltage were needed and the remaining parts to buy, in order to complete the transverter. This task was pretty easy because many precious infos are written on the pcb serigrafy or on the single components datasheet. A bit more complicated was the mapping of the supply connector. At first sight many different voltages are needed but after some test (and staying whitin the specs), +5V, -5V, 10.5V and -1.5V are effectively required. Only +5V and +10.5V have to been designed to delivery a continuous current of 2-3 amps.
I decided to do not use DCDC converters for the high current voltages, I had bad experience with them for a final stage supply…
Below the PSU schematic that includes the power-on and the TX-RX sequencers.
The signal TX INHIBIT is intended to be connected to the Yaesu FT817 pin with the same name, but also to any other transceiver equipped with the new type of sequencer, object of a previous post.

I had to add an extra board to drive the latching coaxial relays I had available.
Finally this summer everything has been assembled, I used an old graphic board heatsink that fits perfectly with the device.

The input LNA and the mixers of LO +13dBm, bodes well for a good receiver perfomances, the output is something over 2 Watts, enough to have fun in RS and TR field day operations.

Some other detail and measurement in this PDF document: xverter_polacco

Yesterday the whole portable station has been assembled and completed the first QSO from the balcony (Fabio I0NLK in SSB).

UPDATE 29/09/2019:
Added a simple power monitor and a temperature meter that use the sensors already made inside the transverter.
Below the power monitor schematic and a short video.

HAM AC rotator on a dish

A dish has a much bigger gain compared to a Yagi consequently the beam width is very narrow, only few degrees. This can be a problem if one wants to use a classic terrestrial antenna rotator for Tropo/Rain Scatter activity because the rotation speed is too fast and the fine tracking becomes imprecise and annoying.
In my case the procedure is further hampered by the use of a three keys rotator: CDE HAM II.

With this type of rotators, one has to press and keep pressed the central key (brake release) before and during the pressing of the left or the right key. In case of a dish fine tracking, the central key must be kept pressed while tapping fast on the direction key….it’s not comfortable but I must say that in these two years I acquired a some degree of skill and an onset of tendinitis.
So the objective was to have an electronic circuit to slow down the speed rotation or at least that does the same effect of my finger tapping on the key.

A DC motor speed can be easily slowed down reducing the average voltage on the windings, a PWM on the supply is perfect.  The AC motor works in a different way and a simple supply voltage reduction maintans the same speed but with less torque.
The solution foundt was to do the same action of the finger, I used three Omron solid state relays of 50 cents each and three transient suppressors to protect the relays against the overvoltage that is generated when the windings current is chopped.

Any microcontroller with three output and input ports can do the job. The three keys are connected at the input ports of the microcontroller, the outputs are connected to optoisolators that drive the relay connected to the wires previously soldered on the keys.
The firmware is basic:

if left key is pressed:
  release brake
  pause 10ms
  turn left

if left AND center keys are pressed:
  release brake
  pause 10ms
  turn left
  pause 50ms
  stop rotation
  pause 500ms

There is no need anymore to press the brake key, just hit the direction and the rotator starts at full speed, but if the brake key is pressed the global speed is reduced and the dish turns with pulses of 50 milliseconds every half second.
The speed reduction example starts at the second 0:16 of the video below.