Hugo content Markdown files cannot use Hugo variables directly.
The way to access variables (including
site parameters,
data sources,
and front matter) from content Markdown files is to use Hugo
shortcodes
or to use a custom template for those content pages.
However, areas inside
code fences
cannot use shortcodes.
What I wanted to do was make examples of code inside code fences used on several pages on my site update with a version number.
However, I don’t currently see a feasible way to do this with Hugo that wouldn’t be overly specific to the particular set of examples.
It’s OK, I wanted to note this limitation I ran into.
An alternative is to use find/replace across files like “sed” or the VSCode GUI.
Zello allows prompt voice push-to-talk group communications worldwide.
Zello provides
free access
for personal use.
The push-to-talk audio is shared simultaneously in a “channel” using internet-connected phones, tablets, computers and Zello WiFi walkie-talkies.
For those accessing Zello from a computer, the Zello Windows program works from Linux using WINE.
Zello requires an internet connection to work.
To use Zello from Linux:
Download
Zello
for Windows PC.
Install Zello with WINE:
wine ZelloDispatchSetup.exe
This creates a Zello icon to launch the Zello app in Linux.
Optionally, start Zello from the Terminal by making a script “zello.sh” like:
To run Linux programs on a Windows computer, normally Windows Subsystem from Linux (built into Windows by Microsoft) is generally the best / most performant way to run most Linux programs, especially programs relevant to data processing and geospace science in general.
The macOS network interface priority order determines which network interface (like WiFi, Ethernet, etc.) the system uses first when multiple interfaces are available.
Set this priority order through the
System Preferences
or via the
command line:
The
setup-wsl GitHub Action
configures WSLv2 environment in Windows GitHub Actions runners.
This allows testing certain quirks and corner cases one might encounter when running software on Windows Subsystem for Linux.
For scientific computing Windows users, WSL is often the best way to run computational software on Windows, including software using performance code for GPU and MPI.
An example WSL workflow that is more
advanced
illustrates how to use the wSL filesystem and that $GITHUB_ENV is not available, but env: parameters are.
Native
virtualization
has a “guest” OS with the same CPU architecture as the “host” physical CPU.
Non-native emulation generally runs slower than native virtualization.
Non-native virtualization means a host computer (such as Apple Silicon) can emulate any supported CPU architecture.
Apple Silicon is ARM64, but with virtualization such as UTM / QEMU the Apple Silicon CPU can emulate ARM32, x86_64, MIPS, RISC-V, PowerPC, and more within the container.
QEMU emulator is available on
Homebrew for Apple Silicon
and can (slowly) emulate a different CPU architecture or run native architecture at nearly full performance.
UTM
is a containerized emulation based off of QEMU for iOS and macOS–like QEMU, the same CPU architecture is virtualized at near full performance, while non-native virtualization is emulated with slower performance.
When creating a new virtual machine in UTM, the first questions include whether the VM will be virtualized (native) or emulated (non-native) and the CPU architecture.
UTM works with native virtualized Windows for ARM, Linux, and emulates many architectures, even old PowerPC macOS guest images.
VirtualBox is an open-source native virtualization application that generally targets x86_64 CPUs.
VirtualBox for Apple Silicon is
available.
Commercial paid Apple Silicon virtualization: these native virtualization applications are not open-source.
They run native virtual machines on Apple Silicon including Windows for ARM.
Parallels is paid-only software
VMWare Fusion is paid software, but has a no-cost personal-use license for home users.
The USA and Canada permitted FM frequency modulation, optionally with CTCSS and DCS, on 27 MHz CB radio in September 2021.
This allows FM operation on the same 40 channels as AM CB radio at 4 watts maximum transmit power.
Observations by USA users including the author is that FM is heard mostly in the range of CB radio channels 23 to 31.
Any CB radio channel can be used with FM mode, the same as AM or SSB modes.
A rise in FM activity over time is also expected on the
President P channels
that are preprogrammed FM standard CB radio channels with
CTCSS / DCS squelch.
Several countries have created an 8 meter ham band near 40 MHz.
The USA FCC has a proposed rulemaking
RM-11843
to create an 8 meter ham band in the USA.
A key conflicting user SNOTEL, which used meteorburst communications to connect very remote sites, has
ceased use
of the 40 MHz band.
As
commenters
indicate, a rich surplus equipment market exists of military surplus radios and commercial equipment that can be used on the 8 meter ham band.
Proposed bandplans allocate FM, CW, and digital modes.
This 8 meter band proposal stands in contrast to the 2014 proposal to make a 4m 70 MHz allocation as exists in numerous other countries around the world.
The FCC
summarily dismissed
the 4m proposal due to incumbent TV channel 4 users.
Use
this link
to query the FCC TV database for channel 4 users.
For example, in 2025 there were about 10 full-power DTV licensees (including newly coming on air) across the USA on TV channel 4, an increase from 2014 licensees.
Since other countries have
allocations
close to 70 MHz, the best option for USA ham in the 4m band may be to co-exist in the 72-76 MHz
band,
perhaps in-between the existing 20 kHz spaced channels.
Since typical 4m radios cover 66 MHz - 88 MHz, for international DX, USA hams could receive on 70 MHz and transmit on 72-76 MHz channels.
This would be akin to operations for international DX for USA hams in the 60 meter channelized band.
While Ethernet itself is subject to interference from ham radio transmission at high transmit power (noted by packet loss or dropped connections during radio transmission), the more common problem is that Ethernet cables can act as antennas and emit signals that interfere with ham radio or CB radio reception, from HF to VHF frequencies.
The usual culprit is common mode emissions from the Ethernet cable, which can be mitigated by using the appropriate type “mix” of ferrite beads or chokes on the Ethernet cable close to each end of the Ethernet cable.
If the devices have shielded Ethernet ports, using shielded CAT6a Ethernet cables can also help reduce interference.
Note that shielded cables might also make interference worse if the shield is not grounded at both device ends - experimentation is necessary - try with one cable first, with other interfering devices unplugged from the network.
Most IoT hubs and VoIP hubs have non-metallic cases, unshielded Ethernet ports and connect by default at 100 Mbps.
A tell-tale sign of 100 Mbps Ethernet interference is that the interference is present when the hub is powered on and connected to the network, but disappears when the Ethernet cable is unplugged from the hub, even if the hub is still powered on.
The RF interference characteristic of 100 Mbps Ethernet is approximately
61 kHz spaced
tones across the HF bands that are constantly present regardless of data traffic.
To save costs, the devices may often omit internal ferrite chokes on the Ethernet port, so adding external ferrite chokes on the Ethernet cable can help reduce interference.
An AM receiver tuned to the RF frequency of interest is the minimum requirement, but an SSB receiver is usually more sensitive for detection.
Due to the AGC action of the receiver, making small improvements to the interference may not be detectable by ear.
In general, a more effective measurement is a spectrum analyzer view typical to a software defined radio (SDR) receiver, which can show the interference power level in dB and the improvement from mitigation efforts with “peak hold” to detect the overall change before / after mitigation.
Broadband hash from power supplies - whether USB or other “wall wart” or inline power supplies (unrelated to Ethernet) is often not detectable by ear, and is better seen by signal strength meter or spectrum analyzer view.
A cost-free solution can be to force the Ethernet ports the hubs are connected to to operate at 10 Mbps instead of 100 Mbps.
This may focus the unwanted common-mode RF emissions to lower frequencies.
Where switch and endpoint support it, test fixed 10 Mbps full-duplex on both ends of the link.
If forcing hubs to 10 Mbps is not suitable, whether due to failed link negotiation, insufficient bandwidth, or persistent interference, add ferrite chokes to the Ethernet cables as the next step.
The ferrite mix is frequency range dependent.
If a wide range of frequency bands experience interference, use multiple chokes with the appropriate distinct mixes to cover the different frequency ranges.
An off-the-shelf solution is the DX Engineering ISO-PLUS Ethernet RF Filters DXE-ISO-PLUS-2, which are designed for 10/100/1000 Mbps Ethernet and cover a wide frequency range with 20 - 30 dB of interference suppression across the HF radio bands.
For frequencies below about 25 MHz, a common mix is the Type 31 mix.
For frequencies above about 25 MHz, a common mix is the Type 43 mix.
Seek a size like FT240-31 or FT240-43, which can accommodate multiple loops of multiple Ethernet cables for increased suppression.
Consider kits like from
Palomar Engineers
which include multiple chokes with different mixes for a range of frequencies.