After far too long, I've finally managed to get Fldigi and Quisk to work together to finally do digi modes like Olivia. The problems I had before were the following:

• When I used hamlib to set the frequency from Fldigi and switch Quisk from RX to TX via PTT, it seemed like Quisk and Fldigi were fighting each other. The frequency then jumped back and forth for so long that Fldigi became so unusable that I had to terminate the process .
• I did not see the sound devices within Fldigi

The guide by James Ahlstrom helped a lot, which unfortunately I initially hadn't understood in as much detail as I should have.

I have implemented the following instructions with the following software versions:

• Debian 12 stable with Cinnamon as DE
• Fldigi 4.1.23
• Quisk 4.2.35

Quisk: Sound Settings

The following screenshot shows how I've set up the audio settings in Quisk:

The two important settings are:

• Digital Tx0 Input: "pulse: Use name QuiskDigitalInput"
• Digital Rx0 Output: "pulse: Use name QuiskDigitalOutput.monitor"

Fldigi: Rig Control

I've switched from hamlib to flrig / xmlrpc with the following settings:

• Enable flrig xcvr with Fldigi as client
• Shutdown flrig with fldigi
• Addr: 127.0.0.1
• Port: 12345
• Flrig PTT keys modem

FlDigi: Soundcard - Devices

Check the option "PulseAudio":

Gluing the Sound Stuff together

Now comes the interesting part!

First, start both, Quisk and Fldigi. It is very important that the applications are running.

Now start the Pulse Audio Volume Control application with the command pavucontrol. You might need to install it first from the package repository.

Click on the tab "Recording". There should be a line visible with the Fldigi icon and the text "capture (some number)". Select "Monitor of QuiskDigitalOutput" in the drop down box next to it:

Click on the tab "Playback". You will notice that there is no such line with the Fldigi icon visible. This is because it is only there when you transmit from inside Fldigi. Pick a clear frequency and e.g. send a longer CQ message in Olivia. As soon as Fldigi switches to TX, a new line with the Fldigi icon and the text "playback (some number)" will be shown in pavucontrol. Select "QuiskDigitalInput" in the drop down box next to it:

That's it!

Now you are good to go: It should now be possible to change the frequency in both Quisk and Fldigi for both applications at the same time, PTT from Fldigi should work without any problems and you should be able to see the signals received by Quisk in the Fldigi waterfall and also be able to make transmissions.

This post is not a detailed guide to buying a Motorola radio but rather a list of things that I think you as a ham should know about before buying a used device. I am also not a Motorola expert. My experience is based solely on the purchase of two Motorola SL1600 (SL300 in the US). The following are my observations and comments:

If you buy a used Motorola, you will need a commercial Customer Programming Software (CPS) to be able to program it. Especially with a device like the SL1600, which has neither a proper display nor a keypad, nothing can be done without a CPS (I am sure that there are Motorolas that you can program on the radio itself but I have no experience with them). This program is either expensive to purchase or can be downloaded illegally from shady web sites. The Motorola CPS is Windows software, so there is no way around a Windows system for programming. It furthermore is annoyingly bad and has limitations depending on the version as described further down.

I would strongly recommend buying such radios only from radio amateurs. Here you can be relatively sure that it is not a device that comes directly from the commercial sector. Sometimes devices are sold that have been used in supermarkets, for example, and then find their way onto classified ad portals via more or less legal channels. The people who then sell them usually know nothing about the programming or the general condition of the device and cannot be sure whether the device is password-protected. If the latter is the case, the buyer is faced with a problem (more details on this later). The seller is furthermore most likely not aware of which licenses have been bought for this particular device. The features activated via licenses are not only important for operation, but also a decisive factor for the price. In my opinion, the "5-Tone Signalling" and "RX Audio Leveling" are useful licenses. The former is needed, for example, to open a relay with a 1750Hz tone, the latter is particularly useful in DMR operation, as not every ham is able to set a decent audio level.

I had initially thought that I could simply buy a second SL1600 and then conveniently write the same code plug on both devices. Unfortunately, this is not possible if the devices have different licenses installed. This is also the transition to the next, much more serious problem: If a device is password-protected and you don't have the password, you can't read out the code plug. If you now think that you can simply create a code plug in the CPS and write it to the device, you are mistaken. You must either have a suitable code plug or read it out of the device. The password-protected device thus initially becomes a paperweight. The options known to me are as follows:

• Buying a code plug: You buy a suitable code plug from a web shop that exploits an over-commercialized system even more commercially

• Reading out the password: If you connect the device to the computer via the programming cable, the CPS communicates with the radio via a virtual network interface. If the device has a very old firmware, it is easy to read out the password using Wireshark, as the radio sends the password in clear text to the CPS for verification. Newer firmware versions have fixed this "issue".

• Patching the CPS: If you have the CPS version 16 and a radio with a slightly older firmware than the latest one (which is therefore still supported by CPS 16), you can use a hex editor to modify a DLL in the software so that the CPS still asks you for the password, but accepts any password you enter. You can then read the code plug, remove the password and write it back. The older CPS 16 is the better, faster and less space consuming software in comparison to CPS 20 but might not be compatible anymore with radios that have the most recent firmware.

For legal reasons, I cannot provide links to all of these programs, information, etc.

If I notice anything else, I will update this post.

The content created by the community in OpenSource.radio is of course also open source. However, the content in the form of raw data in DokuWiki format could previously only be viewed and downloaded in a roundabout way. The latest article in the Zero Retries newsletter gave me food for thought with the following section:

"While this article is within the semi-authoritative easy to find Wikipedia… the OpenSource.radio Wiki seems to be the better project for contributing one’s efforts to document the many open source projects within Amateur Radio that have been developed over the decades. We’re just going to have to figure out how to insure its survival as an information database - at a minimum, regularly “snapshotted” by Internet Archive’s Wayback Machine and perhaps regular mirroring to other sites."

I then came up with the following solution to the problem: A script is automatically executed once a day, which then writes all changes or new content of the wiki to a public Git repository. Normally I would use my own Git server for this, but it runs on the same server as OpenSource.radio. Therefore I decided to use a repository on Github, which can be found here: https://github.com/DK1MI/opensource.radio

If your transceiver has no tune button, you will end up HOOOOOLAAA-ing or whistling to tune your antenna. The HOOOOOLAAA-Ex 3000 solves this problem easily.

Take a 3.5mm stereo plug and solder a PCB mountable switch to ground and the tip pin. The whole thing is then professionally moulded into a single unit using hot glue:

The final touch is given to the product with heat-shrink tubing:

It plugs into the key jack of your transceiver and does beeeep instead of HOOOOOLAAA to tune your antenna!

It was time for me to get out my HF Signals uBitx v6 again and use it for stationary shortwave radio operation. In the past I have already extended the uBitx with an analogue S-meter and an AGC board as well as adapting the firmware to my needs. Now I wanted to connect the little transceiver to my power amplifier, but unfortunately it has no external PTT output. Since the power amplifier has an active low input, i.e. it simply wants to be short-circuited at the PTT input, I immediately thought of installing a relay and controlling it somehow. An internet search led me to a forum post in which the K1 relay was mentioned. This TX relay is ideal for tapping a 12V signal in order to subsequently switch another relay.

The following image shows the location of the K1 relay:

I decided to solder a cable to the relay from below. To do this, the device must first be completely dismantled and the main circuit board removed.

The following picture shows the soldered two-wire cable:

Now I could reassemble everything, but it made sense to drill a hole in the rear panel for the RCA socket before doing so:

Now that everything was back in place and assembled, I connected a simple 5V (yes, I know...) relay module for a test. When the PTT button is pressed, the relay closes as desired and triggers the amplifier to its TX state.

The display still shows my old call sign, as I was too lazy to reprogram the microcontroller:

The temporary relay will be swapped with a 12V module that has a opto isolator integrated as soon as it is delivered.

The Matrix HAM Radio Space, which which is hosted and administered by M0AWS, is a slowly but steadily growing community of radio amateurs who are actively exchanging ideas and information via the Matrix chat network. Hosted on M0AWS's Matrix server, the Ham Radio Space now includes several rooms on satellite radio, antenna construction, Meshtastic and many other topics. There are of course also rooms for the exchange of information on general topics. The opensource.radio project that I recently launched also has a room there, where not only the content of the wiki can be discussed, but also changes to the wiki can be notified via a bot.

A weekly Matrix QO-100 Roundtable Net at 16:30 UK Time (UTC+1) on Freq: 10489.873+/- has been taking place via the QO-100 satellite for some time, but now there was also a desire to be able to exchange ideas via another voice mode. AllStarLink with additional Echolink access was chosen due to its outstanding audio quality. The dedicated ASL node 57881 has now been installed and is available for use.

Interested radio amateurs, SWLs or those who want to become one of the two are invited to join the Matrix Space and thus an experimental, friendly and competent community as well as to join the new AllStarLink node either via ASL or Echolink.

There is also a dedicated Digital Voice Matrix room for discussing everything AllStarLink and beyond. This room also has a bot that notifies any connecting or disconnecting nodes to the Matrix Ham Community AllStarLink node.

If you don't own a personal RF enabled AllStarLink node yet, I can recommend to take a look at the following links:

• Building a SHARI AllStarLink Node
• Building an AllStarLink Node

All the information on how to participate is summarized below:

• Matrix HAM Radio Space: https://matrix.to/#/#ham-radio-space:matrix.m0aws.co.uk
• Digital Voice Matrix room: https://matrix.to/#/#digitalvoice:matrix.m0aws.co.uk
• Matrix AllStarLink Node: 57881
• Echolink node: DK1MI-L (963110)
• Node Info: https://stats.allstarlink.org/stats/57881
• Node Network Map: https://stats.allstarlink.org/stats/57881/networkMap

I currently operate my stationary HF station with 50W output power, but I wonder what life would be like with more power. During my rather fruitless research on the subject of open source or home-brew HF power amplifiers, I realised that there are either few reasonably inexpensive options for building such a power amplifier with approx. 600W or that I am too incapable of finding them. I would prefer a kit or alternatively a building suggestion with freely available circuit board layouts.

Do you know of any HF amplifier designs or kits that are reasonably easy to build? If so, I would be grateful if you would either contact me directly by e-mail or create an account on opensource.radio and add your findings to the HF amplifier wiki page.

Many thanks in advance for your efforts!

The current drama with the Logbook of the World (LoTW) and its prolonged outage has made me think about the topic of QSLing and why it is or seems to be important to me.

What kind of QSL?

I am also concerned with the question of what type of QSL is really for me: electronic or paper?

Electronic QSL is fast and mostly free of charge. On the other hand, the current platforms are outdated, complex, not fraud-proof or only free of charge with limited functionality.

Paper cards are slow, often expensive and very time-consuming but are a nice memory (especially of special QSOs) and thus materialise immaterial events. You can also show them to non-hams to make the experience more tangible for them. Furthermore, they add a personal touch to the personal experience of a QSO, e.g. with a picture or handwritten greetings.

Why QSLing?

Apart from the positive aspects of a paper card: Why is the confirmation itself so important to some or why do I believe it is? I can think of the following reasons:

Confirmation is required for awards. Here it is important that you can trust the confirmation, i.e. that you cannot cheat. However, this raises the question of why an award has to have such a highly official character? Who is interested in such an award? Actually, only the person who has it or would like to have it. Isn't it enough to analyse your own logbook? Isn't it enough to know that you have worked 100 different DXCCs or all Japanese prefectures? Why do you pay money to have the printed diploma sent to you (Disclaimer: I've done all that too)? In the end, it's only for yourself anyway and you have all the data, can analyse it and be happy that you've done it. It's not about documents that give you new band privileges or a better job. Why do you need the document? So that you believe in yourself? To make it more tangible? Maybe it's the same as with the paper cards: To materialise something immaterial.

You do it for the sake of others, i.e. to help your communication partner to get their awards. In the end, the same applies to me here as I have already written about awards. But if you are realistic, hardly any award hunter is interested in a QSL card from a German radio amateur.

You feel a QSO is only half done if it is unconfirmed. Perhaps you are not sure whether you are actually in the logbook of the communication partner or, even worse, you are unsure whether you have correctly copied the other person's callsign. Reasons for this could be a confusing pile-up or very poor conditions. The question is, however, whether the QSO is not generally incomplete. All you would really need in this case is a simple feedback, a kind of ping from their logbook to your logbook. But that's another thing.

Why thinking about this?

Why all the thought? With a modern logging software, electronic QSLs via LoTW, eQSL, QRZ etc. are no real effort. The uploads and downloads happen automatically in the background, so you don't have to worry about them. Practical, but on the other hand it feels very impersonal. However, the lacking willingness to participate in these QSL mechanisms also leads to exclusion. It is not uncommon to read that an interesting station is QRV, but that there is no interest in a QSO because it does not do LoTW. I have to admit that I also practiced this when I tried to work specific entities in the past.

What now?

I could just leave everything as it is: simply automatically transmit each QSL electronically to the various services (if available at the time) and exchange paper cards in special cases. But what happens if I limit myself to the latter? Am I taking the fun out of it or am I taking the pressure out of a hobby that shouldn't be stressful but should be fun? And by pressure I don't mean the process of confirming the QSO, but the pressure of wanting to achieve this and that. Or just upload everything but ignore the results? That wouldn't work in my case.

Sounds like I'll have to find out through an experiment...

For many people, ham radio consists mainly of experimenting and building their own devices, often based on other people's projects. Sharing experiences, circuit diagrams, PCB layouts and source code is therefore an essential part of the hobby. And that's also what the open source movement is all about. As a supporter of both movements, I find it very satisfying to build my station largely on the basis of open source hardware and software or to extend the functionality of a commercial handheld radio with a community made free firmware. Another point is that this makes it cheaper to get into the hobby of amateur radio.

I therefore recently had the idea of creating a public Wiki that lists and describes available open source projects in more detail, as well as providing ready-made recipes for setting up a free amateur radio station. It should serve as a first port of call to find out what alternatives there are to commercial products or simply to get inspiration for new projects.

As I have already had good experiences with DokuWiki, I quickly decided in favour of this Wiki platform. A domain name was also quickly found, reserved and taken online. The very young and not yet very lively wiki platform can be found here:

opensource.radio

However, I can't set up something like this on my own and therefore hope that I can find and inspire people to contribute to this wiki and create content. I have created a "How to Contribute" page on opensource.radio, which gives interested parties all the information they need on how to get involved.

In the meantime, there is also a matrix room, which is intended for communication between contributors and general discussions on this topic. Anyone interested in the project can join the room via the following link: #opensource:matrix.m0aws.co.uk

Thanks to M0AWS for providing this room on his instance.

In this room we already have a bot that informs about changes within the wiki and displays them.

I would be very happy if opensource.radio will provide added value for amateur radio in the future and if people would join me on this mission.

After I recently discovered APRS for myself, I realized that I could not establish radio contact with the surrounding APRS digipeaters in and around the house with the HT. Connected to the X200 on the roof of the house, however, there were no problems. This immediately gave me the idea of operating my own digipeater. For a first test, I then connected my picoAPRS v4 to the X200 and configured the device as a fill-in digipeater. The transmissions from my handheld radio were picked up and retransmitted by the picoAPRS without any problems to the next public I-Gate, but APRS messages sent to me never reached me.

So I went straight to the next experiment and ordered a G1LRO Universal Radio Controller (URC) including the corresponding APRS board, assembled it and put it into operation together with a Quansheng UV-K5. With the VP-Digi software included with the URC, this was quick and easy, but the result was exactly the same as with the picoAPRS. In the case of the URC, thanks to the monitor functionality, which allows me to observe the received/transmitted packets via the serial interface, I was able to see that the APRS messages sent to me did not even reach the digipeater. So it was not picoAPRS or the Universal Radio Controller failing.

The new idea was to build a TX I-Gate. Out of the box, however, this is not possible with the URC as it has no network connectivity. I found a disused Raspberry Pi Zero in the basement, on which I first installed Debian and then the APRX-2.9 package, which is fortunately in the Debian repository.

The Universal Radio Controller had to be reconfigured beforehand. To do this, I connected to it via the serial interface and deactivated both the beaconing and the digipeater functionality. The final configuration of the URC looks like this:

Modem: AFSK Bell 202 1200 Bd 1200/2200 Hz
Callsign: N0CALL-1
Destination: APNV01
TXDelay (ms): 300
TXTail (ms): 30
Quiet time (ms): 300
USB: default mode: KISS
UART1: 9600 baud, default mode: KISS
UART2: 9600 baud, default mode: KISS
DAC type: PWM
Flat audio input: no
Beacon 0: Off, Iv: 10, Dl: 0, WIDE2-2, =<REDACTED>N/<REDACTED>E#Digipeater
Beacon 1: Off, Iv: 0, Dl: 0, no path,
Beacon 2: Off, Iv: 0, Dl: 0, no path,
Beacon 3: Off, Iv: 0, Dl: 0, no path,
Beacon 4: Off, Iv: 0, Dl: 0, no path,
Beacon 5: Off, Iv: 0, Dl: 0, no path,
Beacon 6: Off, Iv: 0, Dl: 0, no path,
Beacon 7: Off, Iv: 0, Dl: 0, no path,
Digipeater: Off
Alias WIDE: On, max: 2, rep: 3, traced, viscous-delay, unfiltered
Alias : Off, max: 0, rep: 0, untraced, unfiltered
Alias : Off, max: 0, rep: 0, untraced, unfiltered
Alias : Off, max: 0, rep: 0, untraced, unfiltered
Alias -0: Off, untraced, unfiltered
Alias -0: Off, untraced, unfiltered
Alias -0: Off, untraced, unfiltered
Alias -0: Off, untraced, unfiltered
Anti-duplicate buffer hold time (s): 30
Callsign filter type: blacklist
Callsign filter list: 0 entries
KISS monitor: Off
Allow non-APRS frames: Off
FX.25 protocol: Off
FX.25 TX: Off

Admittedly, it took me far too long to understand the configuration of a TX I-Gate with APRX and I finally found the following configuration that worked for me by trial and error:

mycall  <N0CALL-1>
myloc lat <REDACTED>N lon <REDACTED>E

<aprsis>
  login              $mycall
  passcode           <REDACTED>
  server             rotate.aprs2.net
  heartbeat-timeout  0         # Disabler of heartbeat timeout
  filter             "m/100"   # positions within 100 km from my location
</aprsis>

<logging>
  pidfile            /var/run/aprx.pid
  rflog              /var/log/aprx/aprx-rf.log
  aprxlog            /var/log/aprx/aprx.log
</logging>

<interface>
  serial-device      /dev/ttyACM0 9600 8n1 KISS
  callsign           $mycall
  alias	             RELAY,WIDE,TRACE
  tx-ok              true    # transmitter enable defaults to false
  telem-to-is        true # set to 'false' to disable
</interface>

<beacon>
  beaconmode         radio
  cycle-size         20m
  beacon             symbol "I#" $myloc comment "Tx iGate + Digipeater"
</beacon>

<digipeater>
  transmitter        $mycall
  <source>
    source           $mycall
    relay-type       digipeated # default mode is "digipeated"
  </source>
  <source>
    source           APRSIS
    relay-type       third-party  # Must define this for APRSIS source!
    viscous-delay    5
    ratelimit        60 120  
    filter           t/m
    via-path         WIDE1-1
    msg-path         WIDE1-1
  </source>
</digipeater>

Here's an overview of all components used in this setup:

• Raspberry Pi Zero 1.1 with Debian and APRX installed
• Universal Radio Controller with APRS board directly connected to the left micro USB port of the Raspberry Pi Zero
• Quansheng UV-K5 HT set to the local APRS frequency 144.800 connected to the HT 2.5 and HT3.5 ports with 2 audio cables

I've modified the HT by replacing the battery with a 5V to 8V converter directly soldered to the battery pins:

The device in all its glory:

I'm aware that the whole setup doesn't look very professional, but it works.

With this configuration, the I-Gate works in such a way that I can send and receive APRS messages as well as positions with my handheld radio. I assume that it is not optimal and would be happy to receive suggestions for improvement via email.

Now that I also have a US call, I'm wondering what I can do with it. One legal use is Echolink on the smartphone, for example, as no transmissions are made on German soil - at least not on amateur radio bands.

One possibility, which is also a bit more Ham Radio than Echolink, is the operation of a shortwave remote station on US soil. I have therefore decided to open an account with a provider of such remote stations (which I will not name here, as I always try not to advertise), which will then give me access to a large number of Flex Radio transceivers in the USA. Operation is very simple thanks to a web interface that allows both SSB and digimode operation. All you need is a browser and (for SSB operation) ideally a headset. A first SSB contact between Connecticut and Massachusetts on 40m was made quickly and worked smoothly. I then wanted to try out FT8 or FT4 and chose a special QSO partner for this: me. After familiarising myself with the FT4/8 implementation within the web interface, I was able to work myself on 17m in FT4:

The working conditions on the US side were a Flex 6400 with a maximum of 100W and an OCF wire antenna. On the German side, a Hermes Lite 2 with 50W and an M0PLK Delta Loop Antenna was used.

While it was fun, it was quite expensive. The main problem with this type of remote operation is that every minute costs money - and not too little. Radio operation, which should actually be relaxing, turns into stress for me. But it's still good to have this option for experiments or special skeds. Unfortunately, I can't imagine regular operation via the commercial hire of remote stations. The cost of a single QSO is just too high for me.

Today I was thinking about why I actually write content for my website. There really aren't many readers, so you might wonder what the point is. I realised that I can think of a few points, but somehow not as a complete answer. But all the individual aspects written down together actually give the complete answer. And that's already the first reason why I'm doing this and why, for example, posts like my declaration of love for amateur radio have come about. The following points are further reasons for writing:

Documenting personal projects has the decisive advantage that even failed projects become sort of a success. So a failed project still has the added value of becoming a blog article. This can either mean that others do not make the same mistake or that tips from readers can help to save the project after all.

Public documentation helps me to be less sloppy. Before I upload a picture with horrible solder joints, I'd rather do it again and then do it better. Or, when writing about how to do something, I realize that there is a better solution for it which I then try to apply.

Furthermore, I constantly have new projects. As soon as one is finished, I'm looking for the next one. My brain then seems to throw everything old overboard. So if I document my current project, I don't lose anything.

If I say in a conversation that I once did a certain project, I can provide a URL to the complete documentation instead of trying to remember details. I think this is much more effective than listing the individual steps from memory.

To be honest, I also enjoy receiving positive and/or constructive feedback. Since my website doesn't have a comment function, but writing emails is an effort, I receive much less feedback, but I consider it to be of higher quality. This keeps trolls away and feedback private.

I sometimes like to look back at what I've done and written just to feel good about it. This is especially helpful in times when you doubt yourself.

Overall, I see this website as a kind of personal CV or résumé. I think that the reader will get a good basic idea of what makes me tick and what interests me.

In the end, every personal website with useful, entertaining, interesting etc. content helps to preserve the good old internet, which we are currently losing more and more.

I was completely unexpectedly awarded the Gordon Bennett Trophy 2023 by the GQRP Club. This trophy, which is awarded annually for the best practical article, was given to me for my Sprat Magazine article about the PowerPole Lid for the Miady 7.2Ah LiFePO4 Battery. I now also have the honor of being listed on the Honor Roll.

Many thanks to the GQRP Club for this great honor and the great trophy!

Sometime in mid-February 2024, in a conversation with Steve W8HF, the idea came up that I could remotely operate his shortwave station in Ohio via VPN. I liked the idea of getting a different perspective and being able to work Europe from the US. At first I assumed that as a holder of a German class A license I could work remotely in the USA according to the CEPT agreement and simply use the W8/DK1MI call. However, it quickly became clear that this is not possible. The CEPT agreement only applies if you are there in person. This gave me the idea to get the US license. Of course, it's not worth it for one or two remote operations, but I was suddenly fascinated by the idea of being able to carry a US call in addition to my DL call.

Preparation

The COVID period has also brought some good news: Since the pandemic, online exams for the US license are also available. There is also a dedicated group of VEs in Northern Germany called "ARRL VE Gruppe DL Nord" who offer such online exams. To see how difficult it would be for me, I registered with the excellent exam preparation site hamstudy.org and took the Amateur Technician and General tests first. As an active radio amateur, I managed to pass the Technician exam with only a few mistakes, and just missed the General exam. With this motivation I registered for the next possible Technician and General exam at the ARRL VE Group DL Nord. From then on I studied every day for the exam with the help of hamstudy.org and their excellent Android app. On March 16, 2024, the time had come and I was finally able to take the exam.

Amateur Technician and General Exam

Both the registration process and the organization of the exam can be described as very professional. Prior to the exam, I was informed several times by e-mail about the preparations that had been made and those that were still necessary. The ARRL VE Group DL Nord website also left no questions unanswered, so there were no surprises at any time. For the test, I chose a room in my house that contained the least amount of technical stuff that could be a distraction - the bedroom. I placed a table and chair in the room and set up a small tripod for the cell phone. During the test, which takes place via Zoom, you not only share your screen and have the laptop's camera activated, but you also dial into the same Zoom session with your smartphone and position it so that you can be observed from diagonally behind. There are clear rules to follow during the exam: Keep your eyes on the screen at all times, use the keyboard on your laptop only, no talking to yourself, no smartwatch, no external mouse, etc. The examiners were friendly, direct, professional and strictly followed the established procedure. Despite some nervousness, I was able to pass both exams in this first online exam with one mistake each and received the CSCE (Certificate of Successful Completion of Examination) by email shortly after the exam and thus had the General in my pocket.

The FCC

Preparation for the exam included registering with the FCC, including obtaining an FRN. This meant that once you had successfully completed the exam, all you had to do was wait for the FCC's email requests. This included paying the $35feeforasequentiallyassignedcallsign.Shortlyafterpaying,Ireceivedmycallsign,whichwasKF8AOI.AlthoughtheFCChandleseverythingbye-mail,aUSmailingaddressisstillrequired.FortunatelyIwasabletouseStev{e}^{\prime }sP.O.Box.Asfortheexams,theycost$15 per session.

Vanity Call

Since I wasn't really happy with the call I was assigned, I decided to invest another $35 and apply for a vanity call. I was told by several US hams that it would be fair not to apply for one of the rare 1x2 or other short calls. The choice fell on a 1x3 call, which has been available since 2000. Being an OpenBSD fan and liking the pronunciation, I applied for N1BSD.

Amateur Extra Exam

After the exam is before the exam, so I immediately started preparing for the Extra exam and registered for the next available date for the second online exam. The date was conveniently close (about 3 weeks after I registered), but a business trip was scheduled for exactly that time. Since the exam was scheduled for 19:00 on a Tuesday, I could easily take it from my hotel room after work. I packed a slightly larger tripod in my suitcase, which turned out to be essential. A hotel room is actually a pretty good place for an online test like this, if you ignore the incalculable risk of the hotel's WiFi. Fortunately, it was fast and reliable. As every hotel room is equipped with a TV, it had to be covered with towels before the test could take place. I was able to pass it quickly and without incident with one error. I received my CSCE for passing the Amateur Extra exam that same evening, April 9, 2024. The vanity call sign N1BSD was assigned to me on April 16, 2024.

Conclusion

In the end, it took about 8 weeks from the idea to getting the Amateur Extra license. Then it took a few days for the FCC database to be updated and a week later I received the vanity call N1BSD. But the latter was only because I had applied for it 2 weeks before the second exam, as it takes about 3 weeks for the FCC to issue such a vanity call.

I am proud to have these new privileges and have learned a lot while preparing for the exam. I think it is worth going this route because you can do it at your own pace and it is quite affordable.

Further Reading / Links

The following links helped me to understand the process or are valuable tools for the exam preparation as well as for finding a nice call sign:

• ARRL VE Group DL North Knowledge Base
• AE7Q's Amateur Radio Database Query Tools
• RadioQTH.net - Available Call Signs
• ExamTools: Amateur Radio License Exam Tools

In order to reduce my travelling luggage, to be able to charge my Retevis RT3S even in the event of a power failure and basically to standardise the charging of devices, I have been looking around for a suitable solution. I came across the following design on Thingiverse: TYT MD380 , UV380 , Retevis RT3 RT3S USB charger. As the description is a bit sparse, I'll try to document my build here.

First I downloaded and printed the three STL files "Charger", "Insert" and "Cover". Then I took two relatively thick cables, stripped about 10mm of insulation and pushed them from behind into the printed part "Insert" through the two holes up to the insulation.

I then fixed the cables in place with hot glue:

The prepared component was then glued into the printed part "Charger" with superglue. Once the glue had hardened, I cut the wires to length and soldered them to the 2S 2A USB-C charger PCB:

The board fitted into the "Charger" component with just a little filing and held firmly without glue.

I then drilled a small hole in the last of the parts, the "Cover", at the level of the two LEDs on the board and glued it to the "Charger". The result looks like this:

Some time ago I bought a second-hand Xiegu X5105, which is 100% functional, but had a small flaw. It was a rather unsightly but hardly annoying dark line in the bottom right-hand corner of the LCD:

I ordered a replacement display directly from the UK, which wasn't exactly cheap. As the display error didn't really bother me, I put off replacing it for a long time. But now the time had come.

To replace the display, the X5105 has to be practically completely dismantled. Firstly, the two side panels with the fold-out feet have to be removed. These are attached with 4 screws each.

The side covers underneath are also fastened with 4 screws each and must also be removed. Now it is immediately clear how cramped the Xiegu is:

The base cover, to the inside of which the battery is attached, is then removed first by loosening the 4 screws on the underside and then with 2 screws each on the front and back:

After loosening the heat sink on the back using the 3 screws, you can lift the PCB sandwich out of the housing and turn it over:

The rubber button mat is simply lifted upwards:

The next two pictures show the inner workings of the transceiver:

The following picture shows the PCB sandwich from the rear. I have already removed the old display. To do this, the ribbon cable must first be pulled out of a socket between the top board and the board below. Furthermore, the two connections for the LED illumination of the display must be desoldered. The display is glued to the PCB and in my case broke when I removed it.

To install the new display, the ribbon cable must first be plugged into the socket with a great deal of patience and locked in place with a screwdriver. Then solder the two contacts of the lighting and glue the display to the PCB.

An initial test shows that the new display works, but has a dead line. Yay.

After a moment of total self-control, it's back to the assembly. Firstly, I removed the old heat-conducting paste with Isoprobynol and then applied fresh paste.

In the end, I was able to reassemble the transceiver without any further problems and marvel at the new display error:

Earlier this month I published a blog post about the Hardrock-50 Widget for Quisk written by Harald, OE6HKE. Since I wanted to add some functionality, I've now forked his project, which can be found here on git.dk1mi.radio.

The first improvement is the error handling, so that the widget doesn't freeze Quisk when the backend script isn't running.

Also, the enhanced version now reads the selected band from Quisk, sends it to the backend script, which then switches the band filters inside the Hardrock-50 to match the active band of the Hermes Lite 2. This allows me to get rid of the serial cable between the Hermes Lite 2 and the Hardrock-50, which caused me a lot of problems in the past.

This article tries to document the essential steps to achieve the following on a fresh OpenBSD 7.4 install:

• Serve static files via HTTP(S)
• Host a Gitea instance via HTTPS
• Host a PHP based FreshRSS instance via HTTP(S)
• Install and maintain Let's Encrypt certificates
• Serve all above via IPv4 and IPv6
• Protect SSH via sshguard
• Implement a reasonable secure packet filtering ruleset

The aim is to use built-in services such as httpd, relayd and acme instead of third party packages. You will not find any installation/configuration of database systems here, as I use SQLite for both Gitea and FreshRSS. The focus is on the server components, not the hosted applications, so I will not go into detail on how to configure them.

Packet Filter: pf and sshguard

Install sshguard:

$ pkg_add sshguard

Edit /etc/pf.conf, paste the following and adapt to your needs:

table <martians> {
  0.0.0.0/8 10.0.0.0/8 100.64.0.0/10            \
  127.0.0.0/8 169.254.0.0/16 172.16.0.0/12      \
  192.0.0.0/24 192.0.2.0/24 192.88.99.0/24      \
  192.168.0.0/16 198.18.0.0/15 198.51.100.0/24  \
  203.0.113.0/24 224.0.0.0/3 255.255.255.255/32 \
  ::/128 ::/96 ::1/128 ::ffff:0:0/96 100::/64   \
  2001:10::/28 2001:2::/48 2001:db8::/32        \
  3ffe::/16 fec0::/10 fc00::/7 }
 
## Set http(80)/https (443) port here ##
webports = "{http, https}"
 
## enable these services ##
int_tcp_services = "{domain, ntp, smtp, www, https, ftp, ssh, 31415}"
int_udp_services = "{domain, ntp}"

set block-policy drop
set loginterface egress
 
## Skip loop back interface - Skip all PF processing on interface ##
set skip on lo

match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from !(egress:network) to any nat-to (egress:0)
 
## Blocking spoofed packets
antispoof quick for egress

# Drop all Non-Routable Addresses 
block in quick on egress from <martians> to any
block return out quick on egress from any to <martians>
 
## Set default policy ##
block all

table <sshguard> persist
block in quick proto tcp from <sshguard>
 
pass out quick
 
# Allow SSH
pass in inet proto tcp to egress port ssh
pass in inet6 proto tcp to egress port ssh

# Allow ICMP
pass in on egress inet proto icmp all icmp-type echoreq
pass in on egress inet6 proto icmp6 all icmp6-type echoreq

# Allow access to httpd and relayd
pass in inet proto { tcp udp } to egress port $webports
pass in inet6 proto { tcp udp } to egress port $webports
 
# Allow essential outgoing traffic 
pass out quick proto tcp to any port $int_tcp_services
pass out quick proto udp to any port $int_udp_services
pass out quick inet6 proto tcp to any port $int_tcp_services
pass out quick inet6 proto udp to any port $int_udp_services

Open a screen session and execute the following inside a dedicated screen:

$ sleep 120; pfctl -d

This allows us to reload the pf configuration without locking us out permanently. If make a mistake, pf will be disabled latest afer 2 minutes allowing us to ssh back in and fix the error.

$ pfctl -n -f /etc/pf.conf
$ pfctl -f /etc/pf.conf

Try to ssh in after reloading the config to make sure that at least this still works. If all is fine, don't forget to kill the "sleep 120; pfctl -d" process.

Web Server: httpd and PHP

In this step we will configure httpd to serve static HTML as well as PHP files. It furthermore is needed for retrieving SSL certificates from Let's Encrypt via ACME client.

Edit /etc/httpd, paste the following and adapt to your needs:

server "static.dk1mi.radio" {
   listen on * port 80
   root "/htdocs/static.dk1mi.radio"
   log style combined

   location "/.well-known/acme-challenge/*" {
      root "/acme"
      request strip 2
    }
}

server "blogs.radio" {
   listen on * port 80
   location "/*.php*" { fastcgi socket "/run/php-fpm.sock" }
   root "/freshrss/p/"
   directory index index.php
   log style combined

   location "/.well-known/acme-challenge/*" {
      root "/acme"
      request strip 2
   }
}

server "git.dk1mi.radio" {
   listen on * port 80
   log style combined

   location "/.well-known/acme-challenge/*" {
      root "/acme"
      request strip 2
   }

   location * {
       block return 301 "https://$HTTP_HOST$REQUEST_URI"
   }
}

Enable and start PHP:

$ rcctl enable php81_fpm
$ rcctl start php81_fpm

Enable and start httpd:

$ rcctl enable httpd
$ rcctl start httpd

Now it's time to configure ACME to retrieve our SSL certificates:

Edit /etc/acme-client.conf, paste the following and adapt to your needs:

authority letsencrypt {
        api url "https://acme-v02.api.letsencrypt.org/directory"
        account key "/etc/acme/letsencrypt-privkey.pem"
}

authority letsencrypt-staging {
        api url "https://acme-staging.api.letsencrypt.org/directory"
        account key "/etc/acme/letsencrypt-staging-privkey.pem"
}

domain blogs.radio {
       domain key "/etc/ssl/private/blogs.radio.key"
       domain full chain certificate "/etc/ssl/blogs.radio.crt"
       sign with letsencrypt
}

domain git.dk1mi.radio {
       domain key "/etc/ssl/private/git.dk1mi.radio.key"
       domain full chain certificate "/etc/ssl/git.dk1mi.radio.crt"
       sign with letsencrypt
}

domain static.dk1mi.radio {
       domain key "/etc/ssl/private/static.dk1mi.radio.key"
       domain full chain certificate "/etc/ssl/static.dk1mi.radio.crt"
       sign with letsencrypt
}

We can now get our new certificates:

$ /usr/sbin/acme-client -v blogs.radio
$ /usr/sbin/acme-client -v git.dk1mi.radio
$ /usr/sbin/acme-client -v static.dk1mi.radio

In order to make sure that they will be updated regularly, we add the following lines to our crontab:

$ crontab -e

0 2 * * * /usr/sbin/acme-client -v beta.blogs.radio >> /tmp/acme.log 2>&1
5 2 * * * /usr/sbin/acme-client -v git.dk1mi.radio >> /tmp/acme.log 2>&1
10 2 * * * /usr/sbin/acme-client -v static.dk1mi.radio >> /tmp/acme.log 2>&1

After this has been done, we can now configure and start relayd.

Relay Daemon: relayd

We will make use of relayd to terminate SSL connections and forward HTTP requests internally to either httpd or the gitea daemon.

To do so, edit /etc/relayd, paste the following and adapt to your needs:

# Macros -----------------------------------
ext_ipv4="46.23.93.217"
ext_ipv6="2a03:6000:93f4:614::217"
webhost="127.0.0.1"
webhost6="::1"

table <webserver>  { $webhost }
table <gitea> { $webhost }
table <webserver6> { $webhost6 }

http protocol https {
  tls keypair git.dk1mi.radio
  tls keypair static.dk1mi.radio
  tls keypair blogs.radio

  block
  pass request header "Host" value "git.dk1mi.radio" \
    forward to <gitea>
  pass request header "Host" value "static.dk1mi.radio" \
    forward to <webserver>
  pass request header "Host" value "blogs.radio" \
    forward to <webserver>
}

relay https {
  listen on $ext_ipv4 port 443 tls
  protocol https
  forward to <webserver> port 80 mode roundrobin \
    check http "/" code 200
  forward to <gitea> port 3000
}

relay https6 {
  listen on $ext_ipv6 port 443 tls
  protocol https
  forward to <webserver6> port 80 mode roundrobin \
    check http "/" code 200
  forward to <gitea> port 3000
}

Enable and start relayd:

$ rcctl enable relayd
$ rcctl start relayd

FreshRSS

Install FreshRSS and some dependencies:

$ pkg_add freshrss php-zip php-curl

FreshRSS should now be accessible and configurable via your browser.

Add the following line to your crontab to automatically update all RSS feeds every 5th minute:

*/5 * * * * doas -u www /usr/local/bin/php -f /var/www/freshrss/app/actualize_script.php > /tmp/FreshRSS.log 2>&1

Gitea

$ pkg_add gitea

Enable and start gitea and gitdaemon:

$ rcctl enable gitea gitdaemon 
$ rcctl enable gitea gitdaemon 
$ rcctl start gitdaemon
$ rcctl start gitdaemon

Gitea should now be accessible and configurable via your browser.

My shortwave station consists of a Hermes Lite 2 SDR transceiver, a Hardrock-50 power amplifier and the marvellous SDR software Quisk by James Ahlstrom. Everything works perfectly, but unfortunately the Hardrock-50 is operated relatively blindly. A lot of important information, such as the output power, the VSWR, the selected band and the operating temperature are not available remotely. The only option you have is to read out the parameters via the Hardrock-50's USB interface. I have already tried to find a solution myself to do this remotely, but I wasn't really satisfied with it.

By chance I found the project hrctl by Harald Klein on Github. This essentially consists of the following Python scripts:

hrctl.py

This Python script can be executed on a single-board computer such as the Raspberry Pi, for example. It acts as a small web server that provides an API via which the above-mentioned parameters can be queried. It is also possible to use this API to send a command via USB to the Hardrock-50 to tell it to re-tune during the next transmit.

Under Debian Bookworm I had to install the following packages before running the script:

# apt install python3-serial python3-gevent-websocket python3-tinyrpc python3-werkzeug

The script can then be executed - ideally within a Tmux session - as follows:

# python3 ./hrctl.py

hermes_widgets.py

The hermes_widgets.py script is a Quisk widget that displays both the "Tune" button and the information collected by the Hardrock-50 at the bottom left of the user interface.

To install it, place it anywhere in the file system on the system on which Quisk is to be executed. Afterwards, the following steps must then be carried out within Quisk:

• Click on "Config
• Select Hermes Lite next to "Radios" at the top
• Click on Change to the right of "Widget File Path"
• Select the script
• Restart Quisk

It may also be necessary to install Python libraries here. These are roughly the same as for the web server script.

Conclusion

I find this solution not only elegant but also brilliant. Now all the important information about the Hardrock-50 is integrated into the Quisk GUI and I can also initiate a re-tune directly from here with a simple click.