Reducing FM Broadcast Interference on 70 MHz with the IC-7300

Following up on the previous post, I compared the receive performance of the IC-7300 and the I0XGR transverter in real-world conditions, alternating them on the same antenna (a 7-element LFA Yagi).
I have to say, I didn’t notice any significant difference between the two, so I decided to keep the Icom radio as my primary setup for the 4m band.

However, I noticed something strange that made me question again the IC-7300’s actual RX performance. Around my building, there are several other buildings, and one of them has an elevator with a noisy inverter motor. Every time the elevator moves, there’s a noticeable increase in noise from the speaker both on the 50 MHz and 144 MHz bands, but not on 4m. Very suspicious!

What’s more, when I point the beam in certain directions, the OVF (overflow warning) starts blinking on the IC-7300 display, and I have to reduce the RF gain 😐.

My antennas have direct line of sight to the two main broadcast sites that cover the Rome area, TV and FM transmitters with hundreds of kilowatts in the 88–108 MHz range, which is very close to the 70 MHz band.
So, I looked at the service manual to understand what kind of filtering the IC-7300 uses on 4m.

The first filter in the RX path is a 76 MHz low pass filter located on the PA UNIT, then a coaxial jumper with TMP male connectors routes the signal to the RF UNIT where it passes through two more filters before reaching the gate of the preamp MOSFET, and then the ADC.

The second filter is a 1.6 MHz high-pass filter, but this can be ignored as it’s practically transparent at 70 MHz.

The final 70-74.8 MHz passband filter is selected when the transceiver is tuned to the 4m band.

I simulated the combined frequency response of these three filters to see how well they suppress the 88–108 MHz broadcast band.

The result: attenuation at the beginning of the FM band is only about 6 dB, increasing to around 25 dB at the upper end.
This level of attenuation may be insufficient to prevent ADC overload, which could cause significant desensitization of the receiver.

To address this, I added a low-cost FM broadcast filter between the first and second filter, using the coax jumper that connects the two boards. The bc filter has a transmission loss of about 2 dB at 70.200 MHz.

I had a few TMP male connectors available, but only one female, and couldn’t find more online, so I had to reuse the one I originally installed for the IC-7300 RX antenna mod, described in a 2017 blog post.

Since the TMP female connector was already soldered to an SMA male, it was ready to be connected to the filter. The filter’s output was then connected back to the IC-7300 board using a coax pigtail salvaged from a non-working transceiver.

Finally, the additional filter was secured in place with strong double-sided tape onto the metal enclosure.

Initial tests were promising!
The OVF warning disappeared completely, even across the nearly unfiltered range of 30–49.999 MHz. Most importantly, I can now hear the elevator noise on 70 MHz too when it moves…hurrah!

On the same day as the first test, I even worked a new country on 4m: UN3M in LO61, 3200 km away in Kazakistan. I don’t know if the decode was possible because of this modification, maybe not, but who knows? Either way, it’s a good sign that the system is working well.

Instructions

1. Remove the top cover of the transceiver
2. Disconnect from the RF Unit the RX TMP jumper cable, the label on the pcb should be J1071
3. Add in series the broadcast band stop filter
4. Secure the filter inside the transceiver
5. Reattach the top cover

If you happen to know a reliable source for female TMP connectors, please leave a comment or send me a message.

73s!

Back on 70 MHz 2025!

This year also we’re authorized to transmit on 4m band! We can use three frequencies 70.100 (CW), 70.200 (SSB/CW/DIGI) and 70.300 FM, all frequencies are +/- 12.5 kHz. The FT8 QRG is 70.190.

The 4m band was first authorized in Italy back in 2007. At that time, there were no commercial transceivers ready to transmit on that band, so Italian VHF ham radio enthusiasts focused on designing or modifying 50 MHz transverters to cover the new band.The only exception was the Yaesu FT-847, which unofficially allowed 4m operation, but deep modifications were needed, without them it was stone deaf. Even after the mods, 4m was definitely not its best band (and that says it all).

The 2007 authorization arrived like a lightning bolt in July, just when the Sporadic-E season was ending.
My transverter wasn’t ready yet, the RX was fine, but the TX section was still missing the final amplifier and the driver transistor was delivering only about 100 milliwatts.
However, that was enough to work CT1HZE in CW the same day, using a Hentenna made from electric wire and built in just 30 minutes. Amazing.

Now, after 18 years, things have changed. Several transceivers come factory-equipped with 70 MHz, and almost no one uses transverters anymore.
Today I found my old transverter in the basement. I brought it to the radio station to do some basic tests and compare it with the IC-7300 I now use for dedicated 70 MHz operations.

Well, at first glance, it doesn’t look good: no LEDs, no meter movement, no illuminated buttons or knobs, nothing at all. But it worked immediately, just like the last time I used it, about 15 years ago.

Before starting the tests, I want to be clear: today’s measurements are far from accurate. My instruments are all uncalibrated, so I can’t provide absolute numbers, but I can still make comparisons.

The first test was a sensitivity comparison:
I connected several attenuators to the output of the TinySA Ultra, configured as a signal generator at 70.200 MHz.

The output power was set to the minimum (-115 dBm, according to the TinySA display). The RF was then connected to the antenna port of the device under test.
Receivers were set with a 2400 Hz bandwidth and preamplifier enabled.
The audio output was sent to a PC running Spectran by I2PHD.
The audio level was adjusted to sit around 50% of the scale in the absence of a signal.
Then, I gradually increased the signal generator output until the PC showed a 10 dB increase over the noise floor.
The receiver requiring the least signal power wins.

Icom 7300

I0XGR 1990 6m transverter (mod)

It seems the ugly duckling wins by 6-7 dB :-))

Unfortunately, the rainy Sunday has come to an end, and I couldn’t run as many tests as I wanted.
However, this first session made one thing clear: this requires further analysis.

I’ve decided to keep the old transverter at the station for a while, and perform not only instrumental comparisons, but also on-air tests.

2m TEP QSO & 6m noon LP JA opening: solar cycle 25!

I am writing this post as a summary of the events on the 2m and 6m bands over the past 18 months.

We are now roughly halfway through the 25th solar cycle, and it is well known that sporadic-E reflections are significantly diminished by increased solar activity. This is reflected in my observations, as I’ve noticed fewer multi-hop openings on the 50 MHz band during the spring and summer towards Central and North America, as well as Asia, compared to the periods of lower solar activity.

On 144 MHz, during the equinox period, I was fortunate to make a contact with V51WW in Namibia using Trans-Equatorial Propagation (TEP), a specialized form of F2 propagation. There is a WhatsApp group to coordinate the tests, I was able to complete the QSO after about 15 days of daily attempts in Q65 mode. FT8 can’t be used because it fails to decode distorted signals.

V51WW Namibia #72 2m ODX

On 50 MHz following a previous post about working Japan via long path at night, around 1 AM local time I recently witnessed another long path opening to Japan. However, this time (2023-11-5) it occurred during the day, around 2 PM, which was a first not just for me, but for everyone I know!
I only managed to complete three QSOs since I was having lunch at a restaurant near my workplace, remotely controlling my home station via smartphone. Despite that, the band was packed with JA signals!

It’s also worth mentioning the openings to Tuvalu, Glorioso, and New Zealand.

2023-06-03 VP2MKP Montserrat FT4/FT8 #203 CW + 27 FT8
2023-06-24 ET3AA Ethiopia FT8 #203 CW + 28 FT8
2023-10-15 KH6WI Hawaii CW/FT8 #204 CW + 28 FT8
2023-10-15 T2C Tuvalu FT8 #204 CW + 29 FT8
2023-11-05 HP2AT Panama FT8 #204 CW + 30 FT8
2024-02-17 CB0ZA Juan Fernandez Island FT8 #204 CW + 31 FT8
2024-04-21 ZL1AKW New Zealand FT8 #204 CW + 32 FT8
2024-06-06 FT4GL Glorioso Island FT8 #204 CW + 33 FT8
2024-06-10 EZ/DL7ZM Turkmenistan CW #205 CW + 33 FT8
2024-06-22 XU7GNY Cambodia FT8 #205 CW + 34 FT8
2024-09-13 ZD9GJ Tristan Da Cunha FT8 #205 CW + 35 FT8
2024-09-18 FK8KA New Caledonia FT8 #205 CW + 36 FT8
2024-09-20 S79VU Seychelles FT8 #205 CW + 37 FT8
2024-10-06 PX0FF Fernando de Noronha FT8 #205 CW + 38 FT8
2024-10-18 XW4KV Laos FT8 #205 CW + 39 FT8
2024-10-30 YS1MAE Salvador FT8 #205 CW + 40 FT8
2024-11-03 9V1XX Singapore FT8 #205 CW + 41 FT8
2024-11-07 KH0/KC0W Mariana Isl. FT8 #205 CW + 42 FT8
2025-04-13 DP0GVN Antarctica SSB #206 CW/SSB + 42 FT8
2025-04-06 VK9DX Norfolk Isl. FT8 #206 CW + 43 FT8

Total 50 MHz band: 206 CW + 43 FT8 = 249 DXCC entities/ 21 years

Minimizing Signal Loss on 6m Band for SPE Amplifiers

I’ve recently bought an SPE MOSFET amplifier from a friend. My intent is to use it when not at home by accessing the shack remotely via smartphone, laptop, etc.

The SPE amplifiers come with a user-friendly console software that replicates the display and controls on the PC screen. Since the SPE software runs only on Windows, I developed an equivalent console application in Python that can be executed on Linux, macOS, and Windows, based on the “Application Programmer’s Guide” provided by SPE.

Since it’s a solid-state amplifier, like all SPE models, there’s no high voltage involved, making it ideal for remote use.

I noticed that when the amplifier is placed between the antenna and receiver on 6m, there’s a slight signal loss.
Although it’s not significant, the signal drop is greater than with the SSPA I’ve been using on 6m band since 2014. This is likely because SPE amplifiers are primarily designed for HF, so they don’t have the coaxial relays typically found in VHF-dedicated amplifiers.
This difference causes impedance changes in the RF path within the PA, resulting in some loss.
While the loss is minimal, I want to avoid it, as on 6m, DX signals are often very weak. Every dB (or even a fraction of a dB) worsens the receiver’s noise figure and could make the difference in decoding a weak FT8 message.

I decided to add a transfer coax relay that completely bypasses the amplifier during RX (also when the PA is powered off), then switches to it during TX.
The transfer coax relay consists of two coaxial relays in a single box, so it’s also possible to use two common coaxial relays with their NC ports connected together.

The coax relays can be activated by the PTT closure, making everything work easily and cleanly. However, there is a problem if you want to use a second transceiver (RTX2) connected to PA IN2. In this case, the second transceiver cannot use the 6m band because the 6m antenna is always connected to RTX1.

The solution is to disable the PA bypass (energize the relays) in two situations:

• When RTX1 closes the PTT on any band
• When RTX2 is tuned to the 6m band

To do this I realized a simple circuit that permits to use both transceivers on any HF and 50 MHz bands simultaneously.

• RTX1 for RX and TX on 6m and HF (6m RX bypass)
• RTX2 for RX and TX on 6m and HF (no 6m RX bypass)

Of course, the transceivers must be tuned to different bands at all times to avoid potential damage to the RX frontend.
The amplifier is connected to the transceivers via CAT, so it knows the frequency of the inputs. This information can be accessed through one of the PA’s communication ports. SPE provides a wealth of data through these ports, including the selected input, bands, antenna output, PTT1 or PTT2 closure, and more.

The PA port of interest is named AUX and contains all the necessary information: band in use, selected input, and PTT status. The band is coded in BCD as follows:

DCBA = 0001 = 160m
DCBA = 0010 = 80m
DCBA = 0011 = 40m
DCBA = 0100 = 30m
DCBA = 0101 = 20m
DCBA = 0110 = 17m
DCBA = 0111 = 15m
DCBA = 1000 = 12m
DCBA = 1001 = 10m
DCBA = 1010 = 6m

The PA AUX port uses open-collector outputs, which means there is no voltage present on these pins to indicate “high” or “low” like on microcontroller ports. Instead, these ports provide a “closure to GND” to represent a logic zero and a “high impedance” state to represent a logic one. To obtain high/low voltages, simply add a pull-up resistor connected to the port.

The circuit needed to connect to the AUX port to energize the relays in the situations described above is:

If the relay coil current exceeds the optocoupler’s limit, an adequate PNP transistor must be added.

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 my remote station located in Ostia Antica, about 15 km from the 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 the links are 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 <linked_file> <original_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 - TS590\wsjtx_log.adi C:\Users\username\AppData\Local\WSJTX\wsjtx_log.adi

mklink /H C:\Users\username\AppData\Local\WSJTX - TS590\wsjtx.log C:\Users\username\AppData\Local\WSJTX\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.

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 #70 2m

ZA/IW2JOP Albania #71 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