Ham Radio

Von: <spammer>
Betreff: TELEGRAFISCHE ÜBERTRAGUNGSMITTEILUNG

Sehr geehrter Begünstigter,

TELEGRAFISCHE ÜBERTRAGUNGSMITTEILUNG.

Wir benachrichtigen Sie hiermit offiziell über Ihre telegrafische Überweisung durch unsere Zahlbank, die ING Bank N.V. Vereinigtes Königreich, auf Ihr Bankkonto [...]

Die wissen genau, wie sie mich ködern können!

He who does radio communication has stories to tell: During the time as an active a ham, memorable stories are accumulating. I want to document these for me before I forget the details. I’m licensed since four years now, and during the last three years I was using CW almost exclusively on the air. In this short time I was collecting (only) a few special moments which I want to share here.

Under the radar

The count and variety of HF band intruders has risen since the Russian invasion in Ukraine this year. One really annoying case are over-the-horizon radars sending in ham radio bands, as these transmissions always consume a remarkable frequency range. These radars can be recognized clearly due to their buzzing sound and tremendous signal strength, so it is pointless to attempt anything over these blockades. (Some hams however try to deliberately disturb these transmissions, but that’s comparable to a bird yelling at a bulldozer.) This April I was in the middle of a QSO with a Briton on the 30 m band, when suddenly a radar burst in, with us being exactly surrounded by noise. It kicked in during my transmission. I was puzzled when I heard it (I use full break-in to receive between my characters), but I had no choice other than continuing my message. It would be hopeless, I thought, to catch any response from my fellow. But, alas, his CW beeps could be clearly distinguished from the buzzing radar noise! I quickly launched Audacity and recorded the rest of our QSO. Try to hear for yourself: (Warning: Noisy!)

G4GUA_OE3SPR_under_radar.mp3

(I tried to enhance the audio later by filtering around 700 Hz, but every attempt made it worse. CW can be distinguished best from the full radar spectrum, interestingly.) I also made a picture of my SDR receiver’s waterfall diagram after one of my transmissions. You cannot make out my friend’s signal visually, though:

So, despite this heavy QRM, we could continue and finalize our conversation, thanks to the powers of morse telegraphy.

QSL via e-mail

I really enjoy exchanging paper QSL cards, especially receiving them from DXpeditions or DX stations. I decorate my shack’s wall with the most picturesque of them. While it makes past QSOs special by having them materialized in paper form, these processes are mostly automated: The prints are generated out of the log program and a common greeting is added. One kind of extra mile and appreciation of a recent contact, however, is an almost immediate personal e-mail after the QSO. For example, I answered two Brits which appeared to be beginners and to have one of their first HF sessions in each other’s company. I had a nice QRS QSO with each of them, and both of them thanked me kindly via e-mail soon after. I also received an e-mail from a young Indonesian after our QSO on 10 m this April.

One very thankful e-mail was again from England. Usually, the weaker signals are most interesting: Is it from far away? Is the station using low power and might thus not get plenty of answers? Will they be able to hear me at all? Well, it turned out, he was QRPP, sending with only 1 W, but easily bridged the 1200 km between us. He later sent me a picture of his setup on the kitchen table, where his TRX was powered by a 9 V battery. I was almost embarassed by me blowing out 100 W. It might have been interesting if I could have turned my output down to 5 W and still have this QSO.

Easy DX

We are three years into the current solar cycle with DX conditions having clearly improved this year’s summer term. Previously, I operated from a garage where I could use my hex beam in a portable-like setup. Since the pandemic I mostly operate from home, using home-made full-size wire loops for 20 m and 30 m and a home-made end-fed for the lower bands. These aren’t directional antennas, though, but I can use them more often, and they are good enough—good enough to have remarkable DX stations reply to my CQ calls: This May I did an unexpectant CQ call on 20 m, and then someone replied with a crystal clear signal... from Indonesia! We had a very nice QSO with hardly any fading. Sadly, I don’t have a recording. I should systematically record my sessions from now on.

Return at first attempt

This is actually just a side note what difference a directional antenna makes compared to a long wire. What positively surprised me during my first hours with my hex beam continued to be awesome whenever I used it: Often, when I joined the pile-up for a DXpedition or DX station with my 100 W rig, only one or a few calls were necessary on my side to already hear the DX station repeat my call! This was already the case when I did SSB. But also my wire loops enabled me to experience these first-attempt successes, since the solar condx are improving.

Getting licensed close to a solar minimum has the advantage of positive surprises for years to come.

Meine automatisierten Blogposts über die aktuellsten Änderungen im Bestand der österreichischen Amateurfunk-Rufzeichen haben das SNR gegenüber meinen eigentlichen Amateurfunk-Postings dezimiert. Daher sind diese Änderungen nur mehr über den Hauptfeed dieses Blogs bzw. über die eigene Kategorie OE Ham Calls auffindbar, nicht mehr über die allgemeinere Ham Radio Kategorie.

Das ist mir dann hoffentlich ein Antrieb, wieder mehr zu diesen Themen aktiv zu sein.

I managed to use APRSDroid (v1.6.2b) on a BlackView BV9900pro (Android 10) with a Kenwood TH-D72E TRX. It works, with a few caveats.

The HT itself needs to be set to the same APRS settings as the TM-D710, which are:

• Com Port
  • Baud Rate (screen 330): 9600 bps
  • Input (331): Off
  • Output (332): Waypoint
• Waypoint
  • Format (340): KENWOOD
  • Length (341): 9-Char
  • Output (342): All

One difference to the TM-D710 is that the TH-D72 has got native USB. Therefore, I also set PC Port Output (screen 350) to On.

I connected the HT with a Mini-USB cable to a USB-OTG adapter which had a Micro-USB plug. Using a USB-C adapter, I connected it to the BV9900pro. A simple USB OTG app didn’t list any USB devices connected, though. I noticed I had to switch on “OTG data exchange” in Settings > System. Now APRSDroid showed a USB device connected, and I could start tracking.

I noticed two caveats, which might be completely the smartphone’s fault. (It performs aggressive internal task killing which can’t even be entirely neutralized by rooting and modding.) Note that the “OTG data exchange” setting shows a description that it would be switched off when unused for 15 minutes. In my case, it switches off anyway, even if the phone’s screen is on and APRSDroid is tracking. The second issue is that when I switch to map mode while the USB connection is on, the app freezes and is cumbersome to stop and restart. I always have to switch off OTG first, then study the map, switch back to list view, activate OTG and start tracking again.

Additional thoughts: The TH-D72 is an aging device. It was introduced in 2010, I bought it new when I got licensed in 2018, and it was discontinued soon after. It is still the only device available [besides the TH-D74] that offers an all-in-one solution for Packet/APRS/GPS that also works perfectly from Linux and Android. Although I’m a ham for a little time now, it always puzzles me how information can be so inaccessible to newbies: Only recently I managed to use Packet Radio at 1200 baud to

• send WinLink messages directly from the HT (called APRSLink),
• send ordinary e-mails directly from the HT,
• receive(!) ordinary e-mails directly on the HT, via APRS radio (what is endgame-awesome), and
• use AX.25 on a Linux machine to connect to WinLink via a Packet node,

all of which are actually old-school meanwhile. It also took me four years to figure out APRS works directly between the HT and a smartphone or tablet. At least I established these options for me now.

The TM-D710 disappeared from the market last year, and I was caught by surprise. After months of searching I could finally buy one used. This mobile TRX also offers APRS on-board which can be directly accessed from Linux.

Currently, in CQRLOG 2.5.1 of Ubuntu 21.04, QSL export for label printing is broken due to a FreePascal bug:

TRegExpr exec: empty input string.

Version 2.5.2 contains a fix, though. Now I had the choice between these unpleasent options:

• Go through dependency hell by using the CQRLOG PPA for Ubuntu. This repo however has got some unresolvable dependencies. Attempts to work around these moved my system from MariaDB back to MySQL, resulting in a migration of the system database directory, what made a “downgrade” back to MariaDB another huge stumbling block. Luckily, I could switch back to 2.5.1 on MariaDB again.
• Go through dependency hell by trying to compile CQRLOG from source. Either I’d have to mess with several odd development packages on my system directly, or by using a Docker container. This was a path I didn’t really want to take.
• Delay printing QSL cards for several months until Ubuntu 21.10 is out (which hopefully contains that fix).

Couldn’t I somehow work around that bug? After all, I just wanted to dump certain log entries to a CSV. This could be done using an ordinary MySQL client! And this is the procedure to do so:

Start CQRLOG, this launches a MySQL (MariaDB) server instance in the CQRLOG data directory, which is ~/.config/cqrlog/database by default, listening on port 64000. Now, simply connect to it:

Use the desired database:

Query, using the columns you usually export:

The resulting CSV is already almost in the usual format, except for the date. In Vim, I did these transformations:

As soon as I was satisfied with the result (in gLabels), I marked these QSL as sent:

Querying around in that table is also a good opportunity for one’s own statistics.

... on ham radio TRX like Yaesu or Kenwood

The Begali HST III morse key is a single-lever paddle that also has a sideswiper mode built in: By flipping a switch on the key’s base, one can operate it as a sideswiper. But why actually is that switch needed? Well, a single-lever creates electric contact on either of two sides, which have to be distinguished, because one side tells the keyer to emit dots (dits) and the other to emit dashes (dahs). That’s why a stereo jack is used to connect to a TRX, because that jack can carry those two channels. When using the single-lever as a sideswiper, though, both sides are equivalent and should simply trigger a key-down. Straight keys can be modeled using a mono jack only. So, for using the Begali HST III in sideswiper mode, both contacts have to be routed the same way, while in paddle mode, they have to stay separate. That’s what that built-in switch is for.

On my Kenwood TRX though, I was disappointed to notice that sideswiper mode of that key doesn’t work: When I plug it into the straight-key socket of my Kenwood TRX, a continuous key-down is emitted! It looks like Begali decided to make both contacts equivalent by shorting them. But thinking of the design of mono jacks, where most of the jack consists of common ground while only the tip carries the channel, that means that if that stereo jack is plugged into a mono socket, a part of the body and the tip are short-circuit, which simply means: key-down!

So, after wrapping my head around this and getting in touch with my CW Elmer, Heinz OE3LHB, he told me he’d gone through that before, with his first-generation Begali HST and his Yaesu TRX. He sent me this sketch of the original wiring and the sketch of the wiring that is needed for sideswiper mode to work on those TRX that expect a mono jack on straight keys:

So, instead of shorting upper and lower contact, both contacts should be routed to the tip. If you look closely, you notice that the 2-pin on/off switch has to be replaced by a 3-pin on/on switch. The 1st-gen HST came without wiring, the YL/OM had to do the wiring themselves, so, this mod wasn’t overly complicated to do. But the HST III comes with the wiring realized on a PCB:

The procedure to implement the desired wiring is:

1. Find a 3-pin on/on switch with the exact same size specs of the original switch. I soldered the original switch out and made measurements with a caliper, it should resemble a 5×8 mm rectangle when viewed from the top. I found a matching switch here.
2. Make a third hole to be able to fit the third pin of the switch through the PCB.

   

3. Place the new switch on the PCB and screw the PCB back in. Only then start soldering the outer pins of the switch to the respective conductor paths. Take care to leave the middle pin isolated from those. (Maybe you should do #5 before this.)
4. Disconnect the switch from the bottom contact (BOT) by scratching through the conductor path. That is, only keep contact with the RING.
5. Connect the middle pin of the switch to the bottom contact (BOT) using isolated wire and a soldering eyelet. (You could also paint a conductor path at the left border of the PCB, if you can do this.)

By this, sideswiper mode finally works. I sent this mod to Bruna Begali and explained why we needed to do that, but I didn’t receive a reply. Maybe they use TRX that work with the original wiring, or that key is rarely used in sideswiper mode. I never use it as a sideswiper anyway, but at least I restored that option for me.

In June last year, when I talked to Hans, G0UPL, ordering his QCX kit at his booth at the Ham Radio fair in Friedrichshafen, he mentioned that there would be a 50 W PA kit coming out soon, and that stuck with me. Meanwhile, I noticed indeed that QRP is just no fun when no one is answering your calls—sorry for having to say this. I like to think of this as a kind of “Law of the Conservation of Effort”: If a DX contact is established, and one of the stations is QRP, then the other one is doing all the work and effort (in terms of operating a respectable receiving antenna and/or “having to crawl into the speaker”). Well, thinking of my main goals that led me to the QCX, which were

• assembling a TRX completely on my own,
• getting a lightweight TRX, no matter its power,
• having it only support CW,

wouldn’t there be a better follow-up step than

• assembling a PA kit,
• a lightweight PA such that QRP is no longer an option (hi),
• having it only support CW (not sure about this, though, but at least it’s marketed as “the QCX PA”).

So, I kept close eyes on the QRP Labs site in the recent months for signs about that PA, and finally, at the beginning of December, Hans announced that PA on the mailing list, and only about one hour later my order was through. I was one of the lucky ones that could include his enclosure kit before it went out of stock.

QCX mods

While I waited for the kit to arrive, I had time for preparation: The QCX needed a PTT mod to be able to provide a PTT signal to the PA; this is achieved by patching a stereo jack into the circuits (plus creating an outlet in the QCX’s enclosure) and adding a pull-up resistor. I also flashed the latest firmware release using an Arduino Uno as programming device, which might be a topic for a different blog post. The harder question to answer was how to get a cheap but still qualitative 20 V 5 A power supply for the PA. Luckily, I already possessed the Lenovo UltraSlim 90 W (20 V 4.5 A) notebook travel power adapter, which even included the option to use a wall socket or a standard automobile 12 V plug. Therefore, I could even go from a standard 12 V lead-acid battery. I only needed a non-standard DC barrel adapter, which took some extra time to arrive. While I was at it, I purchased a 3S LiPo battery pack with nominal 11.1 V to power the QCX itself with something lightweight; note that I measured up to 13.1 V fully charged, so using a fresh 4S pack might fry the QCX.

The PA kit arrived after Christmas, and I was again looking forward to the assembly process, which promised to be not as lengthy as that for the QCX. It took me about ten hours nonetheless, mainly due to assuming errors where there had been none. I will now go over some specialties that I had encountered during the assembly.

(This time in English, as there isn’t that much mechanical vocabulary involved that I was too lazy to look up in the dictionary, as was the case with my report about building the folding hex-beam. )

Considering my root motivations that made me involved with ham radio, there were three main points I wanted to fulfill:

• Build (but not necessarily design) a TRX completely by myself to gain some making skills, and understand at least the main part of how that HF circuits work,
• Get a small and lightweight TRX for portable operations, no matter if that meant QRP or not,
• Have it only support CW to force myself using CW exclusively on the air, which is a requirement that became relevant to me when I started learning CW. (In addition, CW would help compensate for the QRP constraint.)

So, walking down the aisles of the HAM RADIO fair in Friedrichshafen this June, besides fetching my shiny new Begali morse key, I was looking around for the CW TRX kits, designed to be soldered and assembled by their new owners themselves. The first one I saw (model name skipped here deliberately) was already promising, but it lost against the QCX: The QCX is younger, it has less SMD components (only two, and they are already soldered onto the PCB), and it was way(!) cheaper, despite comparable features. The only advantage of the expensive kit was that one could change the band by replacing a small band-specific module. On the other hand, although the QCX is a one-bander only, with a price tag of only EUR 44.00, one could simply build another QCX for that other desired band. I decided to go for the 40 m variant, having the coming winter season in mind.

As a beginner, it was also important for me to be able to tune the finalized TRX without any troubleshooting that requires advanced electronics know-how, involving signal generators and oscilloscopes. The QCX fulfills this by offering a built-in signal generator and an initial tuning routine that YL/OM follows by adjusting some trimmers while watching an amplitude bar on the display.

Assembly

When the kit arrived with all its component parts, I was really looking forward to the assembly process. And indeed, it was a lot of fun, boosting my soldering skills with each installed component and checking each step with a jeweller’s loupe. The whole assembly took me about 20 hours, spread accross several tinkering sessions: