❌

Normal view

There are new articles available, click to refresh the page.
Before yesterdayDK1MI.radio

Zero Retries

By: dk1mi
11 August 2024 at 17:31

"Zero Retries is an independent newsletter promoting technological innovation in Amateur Radio, and Amateur Radio as (literally) a license to experiment with and learn about radio technology." This is how Steve Stroh (N8GNJ), the editor of Zero Retries, describes his weekly newsletter.

But to call it just a newsletter does not do justice to his work. I have been reading and following this site for a long time and am always fascinated by how many high-quality articles he publishes every week. Steve doesn't just limit himself to writing news but is obviously very interested in promoting the hobby of amateur radio and conveying its fascination. Important projects such as the M17 project are regularly pushed by him in order to help drag this valuable project out of its niche.

In the meantime, the newsletter has reached a size that would justify publishing the content as an ePub (hint hint). I would actually love to read it on an eBook reader.

My recommendation? Click here, subscribe and have a nice weekly read on inspiring amateur radio related topics.

QDX and Fldigi on Debian Linux

By: dk1mi
9 August 2024 at 16:07

The following instructions describe how to configure Fldigi for operation with the QRP Labs QDX transceiver on Debian Linux 12 / Raspberry Pi OS (64bit).

In the configuration menu, click on Soundcard -> Devices and select PulseAudio:

Afterwards, click on Rig Control -> Hamlib and configure it as follows:

With these few settings it almost worked for me - but only almost. The QDX switched to transmit mode, but no signal was emitted and the red LED flashed twice continuously. This indicated that the audio signal was too low.

To fix this, open the PulseAudio Volume Control tool and set the volume under Output Devices to 11dB:

If PulseAudio Volume Control is not installed on the system, this can be done using the following command:

# sudo apt install pavucontrol

Notes on the QRP Labs QDX

By: dk1mi
8 August 2024 at 15:41

On this page I am continuously recording all the findings that I have been able to collect in connection with the QDX Transceiver Rev 6 from QRP Labs. What I am writing here might seem negative since it's mostly about issues and how to fix them but I am actually a big fan of this device and have already ordered a second kit.

A post on my QDX build can be found here.

Low output power on 15m

After I've finished building my QDX (high bands version), I measured the output power of all bands and got these results:

  • 20m: 4.6W
  • 17m: 4.9W
  • 15m: 2.4W
  • 12m: 3.5W
  • 10m: 3.5W

After reading https://qrp-labs.com/qdx/qdxtrouble.html I was confused why there is significantly less power on 15m than on 17m as they share an LPF. VA3RR gave me the excellent hint to check if the power output on 15m decreases when I compress the windings on L3 - which actually was the case. I followed his advice and reduced the windings of L3 from 12 to 11 and furthermore prettified the spacing between the windings of L2, L3 and L4 which resulted in the following:

  • 20m: 4.7W
  • 17m: 4.6W
  • 15m: 3.4W
  • 12m: 3.9W
  • 10m: 3.9W

No High SWR Protection

As the QDX does not have an SWR measuring bridge, it does not have a protective circuit to protect the device from high SWR. I was warned against using the QDX together with an automatic tuner, as even the short spikes during the tuning process can lead to the destruction of the four BS170 transistors.

As an alternative to not using an ATU, I was given the following options:

Reducing the Output Power

One recommendation is to temporarily or permanently reduce the supply voltage to reduce the output power. This should help to protect the PA transistors, especially during the tuning process. I have carried out experiments on this, to determine which voltage is needed for a specific level of output power.

The following table shows the output power in Watt per band in dependency of the supply voltage. This refers to a 9V build of the QDX Rev 6.

9.0V 8.5V 8.0V 7.5V 7.0V 6.5V
20m 4.7 4.3 3.9 3.4 3.0 2.5
17m 4.6 4.2 3.9 3.4 2.9 2.4
15m 3.4 3.0 2.8 2.5 2.2 1.8
12m 3.9 3.5 3.3 2.9 2.7 2.1
10m 3.9 3.5 3.1 2.8 2.5 2.0

At 6.0V the QDX would only boot into its flash drive mode.

I've decided to settle with a supply voltage of 7.5V.

Replacing the Transistors

On groups.io/g/QRPLabs I have so far been able to find the following attempts to replace the BS170 transistors, which are installed as standard and are considered to be quite sensitive:

Replacement with TN0110 transistors. These are supposed to be more robust, but have the disadvantage that their polarity is reversed. As a result, the round and not the flat side of the transistors rest on the circuit board. As I operate the QDX without a housing, this would even be an advantage if I use a heat sink instead of the washer.

(Note: This picture shows the heat sink with the four BS170)

Exchange for two FDT86256 mosfets. This procedure developed by WB2CBA is described in more detail here: https://github.com/WB2CBA/QDX-PA-MODIFICATION. The whole thing is now even available as a kit: https://www.tindie.com/products/jasonkits_qrp/qdx-mosfet-pa-mod-kit/. However, it is recommended to drive it with 6V instead of the original 5V. More information here: https://groups.io/g/QRPLabs/topic/qdx_pa_upgrade/103093403

Attenuated RX on 20m

Problem

The RF filter sweep for the 20m band resulted in the following graph:

This is the result of the image rejection sweep for the 20m band:

(Partial) Solution

I fixed this issue by rearranging the windings on L12 and resoldering all solder joints of L12. Turned out I didn't burn all of the wire's coating the first time:

This looks much better but not really fixed - until you read this thread on groups.io.

Looks like 20m is a compromise band of the high band version as the 80m band is on the low band version. The issue is that I primarily work on 20m but there seems no better solution that to build a low band or even a mid band QDX.

The QubeDX - a modular CubeSat style QRP Transceiver

By: dk1mi
7 August 2024 at 09:44

(the frame is actually dead straight, the distortion comes from the camera)

This article is about the implementation of the idea of building a (decorative) QRP radio for digi mode operation that can be operated remotely via Wi-Fi. One possible use would be to place the device together with a simple vertical antenna and a small battery, e.g. temporarily in the garden, so that it can then be operated from the computer from inside the house. The basic idea is to be able to conveniently control the device remotely via VNC.

I had set myself the following conditions:

  • The transceiver should be inexpensive and easy to set up
  • The setup should include an automatic antenna tuner that does not require any manual interaction
  • A Wi-Fi-capable single-board computer should be integrated, on which the required software (WSJT-X, JS8Call, Fldigi) can be executed
  • The entire system should be able to be operated with 13.8V and only require one power supply line
  • The costs should not exceed 250€, ideally around 200€
  • It should be cool looking / decorative (from a techie's perspective)

I then decided in favor of the following components

Before the implementation began, I first had to come up with an idea for a suitable enclosure. After seeing a CubeSat at Hamradio 2024 in Friedrichshafen, I had the idea of making the entire setup look like a CubeSat and building it on a modular, skeleton-like structure. I finally found inspiration in the following design on Thingiverse: https://www.thingiverse.com/thing:4096437

Unfortunately, I had to realize that a 10x10x10cm cube didn't offer enough space for my project, so I created a 14x14x14cm version based on the previously linked project. I enlarged the side panel and the base plate accordingly and designed 3 new modules for the following components (from bottom to top):

  • ATU, OLED display and Powerpole connector
  • QDX transceiver and buck converter (7V, please see my notes on the QDX)
  • Raspberry Pi 5 and buck converter (5V)

All 3D printable parts used in this project can be found on Printables.

First of all, the individual components had to be assembled:

Antenna Tuner Module

The kit for an ATU-100 to N7DDC can now be obtained for just 35€ including shipping. Apart from the binocular transformer, I built it according to the instructions. The transformer only needs 5 instead of 10 windings on both sides to be able to use it for QRP operation. After the kit was finished, I downloaded the original firmware and flashed it to the micro controller with a PICKit3 programmer. I made the following two modifications:

  • QRP operation by setting cell 05 to the value 01
  • Fully automatic tuning based on the measured SWR by setting cell 02 to the value 01

You can find more details in the ATU-100 manual on Github

For more information on the QDX in combination with an ATU, please see my notes on the QDX.

The tuner was then installed together with the display and a Powerpole connector on the specially designed and printed module carrier:

Transceiver Module

Now it was time to set up the QDX transceiver. The unprecedentedly good assembly instructions from QRPLabs left no questions unanswered, which is why the assembly turned out to be quite simple.

The finished QDX was then inserted into its module carrier. In addition to the QDX, a buck converter was installed on the carrier, which regulates the 13.8V for the QDX down to 9V.

Raspberry Pi Module

The Raspberry Pi was mounted together with the NVMe module in sandwich construction on the corresponding module carrier. There was still space next to it to accommodate a buck converter, which regulates the 13.8V down to 5V for the single board computer.

Assembly

Now the CubeSat frame was printed and screwed together with M3x10 stainless steel screws and the corresponding nuts. The three pre-assembled module supports were then installed in the frame one above the other using M3 nylon spacers so that they were screwed to the frame with four screws each at the top and bottom.

The cabling was then installed:

  • A 30cm SMA to SMA coaxial cable with angled connectors to connect the ATU to the QDX
  • A short USB cable to connect the QDX to the Raspberry Pi (CAT and audio)
  • Three two-core cables for the power supply, each running from the Powerpole connector to the ATU and the buck converters
  • Two two-wire cables from the buck converters to the QDX (hollow plug) and the Raspberry Pi (USB-C)

The Result

The following pictures show the finished setup:

Updates and Modifications

I am documenting all updates and modifications here in this separate post.

Playing Doom in 2024 (on Linux)

By: dk1mi
27 July 2024 at 11:43

Besides amateur radio, I have another passion: Doom. Not the modern Doom variants, however, but the classic Doom or Doom II from the 90s (when I write about Doom in general in the rest of this article, I mean Doom and Doom II). There is hardly any other game that has such an incredibly persistent and active community as Doom. It delivers a continuous stream of total conversions, WADs, megawads and further developments of the numerous source ports.

The terms just mentioned may need some explanation:

  • Source Port: A Doom source port is a modernized version of the original Doom engine, modified to run on modern operating systems offering enhancements and new features. They are based on the original Doom source code, which was released by id Software in 1997.
  • Total Conversion: An expansion of Doom in the form of a WAD or PK3, which is effectively a new game based on the Doom engine: New weapons, enemies, levels, textures, items, etc.
  • WAD: This file name extension stands for β€˜Where's All the Data?’. These files contain the Doom game files and are divided into IWADs and PWADs:
    • IWAD (Internal WAD): the WAD on which the game is based (e.g. DOOM.WAD or DOOM2.WAD), which is required for the game to run
    • PWAD (Patch WAD): optional WAD that is applied like a patch and overwrites parts of the IWAD, e.g. levels, monsters etc.
  • Megawad: like a WAD but includes 15 or more new levels, some of them aim to deliver 32 maps like the original game
  • PK3: Not the PK3 you might expect if you are a Quake player. It's actually just a renamed zip file containing Doom game content.

Choosing a Source Port

There are many source ports to chose from:

  • GZDoom: One of the most popular source ports, known for its advanced rendering capabilities, including OpenGL support, dynamic lighting, and scripting enhancements with ZScript.
  • Zandronum: Focuses on multiplayer gameplay, providing extensive online play features, and is based on GZDoom.
  • Chocolate Doom: Strives to closely replicate the original Doom experience, maintaining the look, feel, and behavior of the original game.
  • DSDA: Offers a balance between compatibility with the original game and enhancements, often used for speedrunning due to its demo recording and playback capabilities. PrBoom+ based.

I would recommend to start with the zDoom based source port GZDoom. Later on you might want to try other source ports, e.g. because a specific megawad you want to play requires a prboom based port instead of a zDoom based one. GZDoom is nice and easy to use but also has its downsides. It eats quite an amount of resources and can actually be laggy even on modest modern systems when there are many monsters nearby.

Download GZDoom here and install it. Before we execute it, we need the original Doom WADs.

Obtaining the Doom IWADs

There are many ways to obtain the required IWADs. One legal option is to buy them from Steam or GOG. As GOG sells only DRM free games, I consider them being the good guys so I recommend buying the games from them:

The downloaded games are Windows installer files which we first need to install with wine in order to obtain the IWADs:

micha@debian:~$ wine Downloads/downloaded_installer_file.exe

You will find the needed files here (with Doom II as an example):

micha@debian:~/.wine/drive_c/GOG Games/DOOM 2/doom2$ ls
DEFAULT.CFG  DM.CFG  dm.dat  DM.EXE  DOOM2.EXE  DOOM2.WAD  IPXSETUP.EXE  MODEM.CFG  MODEM.NUM  MODEM.STR  MOUSE.CFG  SERSETUP.EXE  SETUP.EXE

I've created a directory named wads in my home directory and copied the required WADs there:

micha@debian:~/.wine/drive_c/GOG Games/DOOM 2/doom2$ cp *.WAD ~/wads/

Repeat these steps for any GZDoom supported game.

Playing Doom

To play Doom, cd into the wads directory and execute GZdoom:

micha@debian:~$ cd wads
micha@debian:~/wads$ gzdoom 
GZDoom g4.12.2 - 2024-04-26 15:12:47 -0400 - SDL version
Compiled on Apr 30 2024

OS: Debian GNU/Linux 12 (bookworm), Linux 6.1.0-23-amd64 on x86_64
GZDoom version g4.12.2

You will now be greeted with the GZDoom launcher. The "Game" tab should list all Doom games you have copied to your wads directory. GZDoom (and most other ports) are not limited to Doom. They are also capable of playing other Doom engine based games like Heretic or Hexen.

Select the game you want and switch to the "Options" tab. You might want to disable "Lights" and "Brightmaps" under "Extra Graphics" as even modern low-spec systems might become laggy with these options enabled.

Finally, click "Play Game".

Configuration

In the start screen press "Esc", select options, then "Full Options". Now you might want to configure the following:

  • "Set video mode" to pick a video resolution and to enable full screen
  • "Customize Controls" to set everything to your liking. I prefer "WASD" mode and the default key binding
  • "Mouse Options" to set the sensitivity to your liking

Now it's time to play!

Recommended Playing Order

Here is my recommended playing order for someone playing Doom the first time since the 90s or at all:

  • Doom Engine
  • Doom II Engine
    • Doom II Hell on Earth (DOOM2.WAD)
    • Final Doom: TNT - Evilution (TNT.WAD)
    • Final Doom: Plutonia Experiment (PLUTONIA.WAD)

What's next?

Welcome to the endless rabbit hole of Doom! You most likely won't live long enough to play all available maps and total conversions. The following megawads are a good place to start:

To play Doom with such a (mega)wad, simply add the name of the wad as an option when starting GZDoom:

micha@debian:~$ cd wads
micha@debian:~/wads$ gzdoom SIGIL_v1_21.wad 
GZDoom g4.12.2 - 2024-04-26 15:12:47 -0400 - SDL version
Compiled on Apr 30 2024

OS: Debian GNU/Linux 12 (bookworm), Linux 6.1.0-23-amd64 on x86_64
GZDoom version g4.12.2
W_Init: Init WADfiles.
adding /opt/gzdoom/gzdoom.pk3, 679 lumps
adding /opt/gzdoom/game_support.pk3, 3308 lumps
adding ./DOOM.WAD, 2306 lumps
adding /opt/gzdoom/game_widescreen_gfx.pk3, 214 lumps
adding SIGIL_v1_21.wad, 146 lumps

Another alternative, which is a standalone game that unfortunately only runs on Windows, is Doom 64, which is a Doom game first released on the Nintendo 64 offering completely new, exclusive levels and is definitely worth playing. It can also be purchased from GOG.

Where to find WADs

A very good start to find some selected WADS is this forum thread on doomworld.com: The ULTIMATE Master WAD Guide.

Then there are the yearly Cacowards, where each year's top releases get an award. You can propably not go wrong with these.

General info on Doom (actually ALL info you want) can be found in the Doomwiki.

Multiplayer

I have only recently started playing Doom multiplayer, so I have little experience to share. I will expand this part of the article in the future. But here are a few helpful links:

Retro Console Color Schemes for Quisk

By: dk1mi
25 July 2024 at 19:25

I'm a big fan of Quisk, the SDR software I use for my Hermes Lite 2 SDR transceiver, but I am not the biggest fan of the available color schemes. The following screenshot shows the default theme:

!

I prefer dark color schemes, which is why I created the two new themes below. However, there is currently the restriction that the color settings for the following elements are hard-coded and therefore cannot be adjusted as described:

  • Sliders
  • Power Button

Please be also aware that it's generally not the best idea to alter the configuration file described below as it might be overwritten when updating the application. It might be a good idea to backup the original file before altering it and the modified file before performing an update.

Amber Monochrome CRT

The following screenshot shows the "Amber Monochrome CRT" color scheme:

!

To achieve the above, find the code block beginning with color_scheme_B in the file quisk_conf_defaults.py and change it to

color_scheme_B = {
    'color_bg'            : '#0F0F0F', # Lower screen background
    'color_bg_txt'        : '#FFBF00', # Lower screen text color
    'color_graph'         : '#0F0F0F', # Graph background
    'color_config2'       : '#FF8000', # Color in tab row of config screen
    'color_gl'            : '#2F4F4F', # Lines on the graph
    'color_graphticks'    : '#CCCCCC', # Graph ticks
    'color_graphline'     : '#FFBF00', # Graph data line color
    'color_graphlabels'   : '#FFBF00', # Graph label color
    'color_btn'           : '#141414', # Button color
    'color_check_btn'     : '#865E2E', # Color of a check button when it is checked
    'color_cycle_btn'     : '#865E2E', # Color of a cycle button when it is checked
    'color_adjust_btn'    : '#865E2E', # Color of an adjustable button when it is checked
    'color_test'          : '#865E2E', # Color of a button used for test (turn off for tx)
    'color_freq'          : '#FF9933', # Background color of frequency and s-meter
    'color_freq_txt'      : '#000000', # Text color of frequency display
    'color_entry'         : '#2E2E2E', # Frequency entry box
    'color_entry_txt'     : '#FFBF00', # Text color of entry box
    'color_enable'        : '#FFBF00', # Text color for an enabled button
    'color_disable'       : '#FF0000', # Text color for a disabled button
    'color_popchoice'     : '#555555', # Text color for button that pops up a row of buttons
    'color_bandwidth'     : '#4B2E0F', # Color for bandwidth display
    'color_txline'        : '#FFBF00', # Vertical line color for tx in graph
    'color_rxline'        : '#FF8000', # Vertical line color for rx in graph
    'color_graph_msg_fg'  : '#FF8000', # Text messages on the graph screen
    'color_graph_msg_bg'  : '#1E1E1E', # Background of text messages on the graph screen
}

In the application itself, set the option Config -> Radio -> Fonts -> Color to the value "B". To obtain an amber-colored waterfall, the code block starting with waterfallPaletteB must be found and modified as follows:

waterfallPaletteB = (
    (0, 0, 0, 0),
    (32, 25, 20, 0),
    (64, 58, 40, 6),
    (96, 78, 50, 16),
    (128, 120, 85, 29),
    (160, 144, 100, 51),
    (192, 195, 140, 43),
    (224, 198, 150, 35),
    (255, 255, 191, 0)
)

Finally, set the option Config -> Radio -> Fonts -> Waterfall to the value "B".

Green Monochrome CRT

The following screenshot shows the "Green Monochrome CRT" color scheme:

!

To achieve the above, find the code block beginning with color_scheme_C in the file quisk_conf_defaults.py and change it to

color_scheme_C = {
    'color_bg'            : '#0F0F0F', # Lower screen background
    'color_bg_txt'        : '#00CC00', # Lower screen text color
    'color_graph'         : '#0F0F0F', # Graph background
    'color_config2'       : '#008000', # color in tab row of config screen
    'color_gl'            : '#2F4F4F', # Lines on the graph
    'color_graphticks'    : '#CCCCCC', # Graph ticks
    'color_graphline'     : '#00FF00', # graph data line color
    'color_graphlabels'   : '#00FF00', # graph label color
    'color_btn'           : '#141414', # button color
    'color_check_btn'     : '#005500', # color of a check button when it is checked
    'color_cycle_btn'     : '#005500', # color of a cycle button when it is checked
    'color_adjust_btn'    : '#005500', # color of an adjustable button when it is checked
    'color_test'          : '#005500', # color of a button used for test (turn off for tx)
    'color_freq'          : '#208B57', # background color of frequency and s-meter
    'color_freq_txt'      : '#00FF00', # text color of frequency display
    'color_entry'         : '#2E2E2E', # frequency entry box
    'color_entry_txt'     : '#00FF00', # text color of entry box
    'color_enable'        : '#00CC00', # text color for an enabled button
    'color_disable'       : '#FF0000', # text color for a disabled button
    'color_popchoice'     : '#555555', # text color for button that pops up a row of buttons
    'color_bandwidth'     : '#003300', # color for bandwidth display; thanks to WB4JFI
    'color_txline'        : '#00CC00', # vertical line color for tx in graph
    'color_rxline'        : '#00FF00', # vertical line color for rx in graph
    'color_graph_msg_fg'  : '#008800', # text messages on the graph screen
    'color_graph_msg_bg'  : '#1E1E1E', # background of text messages on the graph screen
}

In the application itself, configure set the option Config -> Radio -> Fonts -> Color to the value "C". This color scheme works nicely together with the existing waterfall palette "C":

waterfallPaletteC = (
(0, 0, 0, 0),
(32, 0, 25, 25),
(64, 6, 58, 41),
(96, 16, 78, 43),
(128, 29, 120, 41),
(160, 51, 144, 35),
(192, 116, 141, 43),
(224, 195, 198, 35),
(255, 245, 99, 3)
)

Finally, set the option Config -> Radio -> Fonts -> Waterfall to the value "C".

The Beauty of Keyboard to Keyboard Digi Modes

By: dk1mi
6 July 2024 at 10:35

Diesen Artikel in deutscher Sprache lesen

When I started amateur radio in 2019, I initially only considered FT8 and FT4, as it is a very simple and straightforward way to get into the hobby - also because I still was very mic shy. I was already experimenting with other digi modes like PSK31 and RTTY, but my main goal was to work as many countries on as many bands as possible and as quickly as possible. To achieve this, FT8 and FT4 are very suitable and have been instrumental in achieving first the DXCC and later the WAS award.

However, for various reasons, I have recently decided to distance myself from working new DXCC entities and focus on the person behind the station I am working. FT8 is therefore of not much use and I now mainly use it for general tests or QRP experiments. Since I don't know CW, the only thing left is SSB or the (for me) forgotten keyboard to keyboard digi modes.

One of the biggest hurdles for me was to get Fldigi (a very popular open source for Digital Modes in Amateur Radio) working together with Quisk (Python based SDR software for the Hermes Lite 2 transceiver amongst others). Now that I have managed to do this, I have finally been able to try out various alternative digi modes again.

I was actually mainly interested in newer modes like Olivia, Contestia or Thor, but unfortunately there seems to be less activity here. However, I was able to make many nice QSOs in PSK31 in the last few days. Most of them were rather macro-based and comparable to the mouse to mouse FT8 experience, but a few were actually real keyboard to keyboard conversations. Interestingly, these 30-40 minute ragchews were all DX QSOs.

I find it absolutely fascinating to be able to make longer intercontinental conversations with just a little power and even in less than ideal conditions. You have a lot more time to think during the conversation as it would be in SSB, which is very helpful if you're not talking/typing in your native language. I used a mixture of macros and manual keystrokes to automate, for example, the beginning of each pass or the transitions to the other station, but also longer blocks of text such as the station description.

But even with macro-based QSOs you learn much more about the person on the other side than in any FT8 or in most SSB QSOs. It was the latter in particular that I realized with regret. SSB remains my main mode, but I have now found a functioning alternative mode that meets my requirements.

I would like others to give the many different keyboard to keyboard modes available a chance. I keep reading about younger radio amateurs who don't dare to try SSB and prefer to communicate via the computer and then use FT8.

The main message of this post: Modes like Olivia, JS8call and PSK31 offer a great opportunity to communicate non-verbally but still personally. It could be the perfect way to enjoy ham radio as an introvert or as a ham with a sub-optimal antenna situation in a way that it's still a personal communication between humans.

Quisk and Fldigi on Debian Linux

By: dk1mi
2 July 2024 at 09:00

Diesen Artikel in deutscher Sprache lesen

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.

What you should know before buying a Motorola Radio

By: dk1mi
1 July 2024 at 11:55

Diesen Artikel in deutscher Sprache lesen

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.

Open Sourcing the Content of OpenSource.radio

By: dk1mi
30 June 2024 at 09:13

Diesen Artikel in deutscher Sprache lesen

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

The HOOOOOLAAA-Ex 3000

By: dk1mi
23 June 2024 at 12:44

Diesen Artikel in deutscher Sprache lesen

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:

image

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

image

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

image

uBitx Linear Amplifier PTT Control

By: dk1mi
20 June 2024 at 11:27

Diesen Artikel in deutscher Sprache lesen

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:

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:

image

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

image

image

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.

image

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

image

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 now has an AllStarLink Node

By: dk1mi
10 June 2024 at 08:00

Diesen Artikel in deutscher Sprache lesen

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:

All the information on how to participate is summarized below:

Looking for a 600W HF Amplifier Kit

By: dk1mi
4 June 2024 at 09:08

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!

On QSLing

By: dk1mi
29 May 2024 at 00:00

Diesen Artikel in deutscher Sprache lesen

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...

OpenSource.radio - a Wiki for Open Source in Amateur Radio

By: dk1mi
18 May 2024 at 20:05

Diesen Artikel in deutscher Sprache lesen

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.

APRS TX i-Gate with APRX and the Universal Radio Controller

By: dk1mi
4 May 2024 at 00:00

Diesen Artikel in deutscher Sprache lesen

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:

aprs-tx-igate-with-aprx

The device in all its glory:

aprs-tx-igate-with-aprx

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.

I can send myself a QSL card now

By: dk1mi
30 April 2024 at 07:20

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:

WSJT-X Screenshot

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.

Why I write

By: dk1mi
20 April 2024 at 11:26

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.

❌
❌