Dedicated page for Multi-Booting Windows 10 and OpenBSD

I've created a dedicated page with my guide for Multi-Booting Windows 10 and OpenBSD. This supersedes the earlier blog post on this topic. I've been running this setup for a few months now and I seem to have ironed out most of the gotchas, including how to, as elegantly as practicable, deal with Windows' BitLocker shenanigans as well as its tendency to override the rEFInd boot manager.


OpenBSD 6.9 Released, PHP/MySQL Page updated


The 50th release of OpenBSD hit the mirrors last night, but I had some problems installing packages -- they were out of sync a bit. Anyhow, today, all of the package repositories on all the mirrors seem to be working swimmingly (you see what I did there?) and getting OpenBSD's built-in HTTPD working with PHP 8.0.3 and MariaDB (a MySQL Fork) 10.5.9 is a breeze. I've updated the OpenBSD HTTPD/PHP/MySQL page accordingly.

I'm most excited about a number of fixes in the VMM hypervisor that mean it can once again run some of my Linux virtual machines that have newer kernels. That had been broken for quite a while. There are also some changes to video and audio subsystems that I feel like might have been driven by some of my input on the mailing lists. The world may never know. 

In news that's related only by virtue of OpenBSD tinkering, I also managed to get OBS Studio working on OpenBSD-CURRENT, which just required me to figure out how to get the excellent openbsd-wip ports tree working alongside the official OpenBSD Ports. I'm still figuring out how to tune OBS to get high-quality live streams working, and at present, directly attaching the webcam to OBS results in a Kernel Panic. So there are some bugs to iron out.


Review: OpenBSD 6.8 on 8th Gen Lenovo ThinkPad X1 Carbon 13.3"

10 days ago, I bought this X1 Carbon. I immediately installed OpenBSD on it. It took me a few days to settle in and make myself at home, but here are my impressions.

This was the smoothest experience I've had getting OpenBSD set up the way I like it. The Toshiba NB305 in 2011 was a close second, but the Acer I used between these two laptops required a lot more tweaking of both hardware and kernel to get it to feel like home.

The bad news

Let's start with what doesn't work flawlessly on the ThinkPad under OpenBSD-STABLE (6.8 with all patches to date applied), roughly in the order I noticed them. At the moment, the issues with the TrackPad and browser webcam are the only outstanding annoyances. Everything else was easily addressed with basic configuration adjustments.

The resolution is just too high. 

First world problems. While I admire cramming a full-blown 4K UHD into this diminutive portable workstation, at 3840x2160 on a 13-inch-class display, everything was too small to read. Windows and MacOS both handle the ever-growing number of pixels on a display by having a "scale" item in the display properties. While display managers designed for BSD and Linux, such as XFCE or GNOME, do have the ability to scale items, these scale settings don't work globally across all applications in a predictable way.

The high-DPI display was most problematic during installation, wherein the kernel modesetting used the native screen resolution for the text-mode installer, with each line of text being barely a millimeter tall. I literally wore a headset magnifier to install OpenBSD on this thing. After install, the console was a reasonable size. I don't know why the installer used such a high resolution, but suppose it could be related to firmware for the on-board graphics adapter that's not present in the install media but is present after a full install and fw_update.

Upon logging in to X and opening a terminal window, I had to bump up the font size just to see what's going on. I opted to just decrease the resolution of my display to solve this problem. Using xrandr to experiment with different 16x9 resolutions, I settled on 2048x1152, though plain old 1080p is also quite pleasant. I added this lovely gem to my .xinitrc file before calling the desktop environment:

xrandr --output eDP-1 --mode 2048x1152

The touchpad occasionally goes non-responsive. 

I think this may be hardware-level wrist-detection stuff at work, but backing completely off the computer and trying to use the touchpad doesn't fix it. I often have to use two or three fingers at a time and repeatedly tap the touchpad to get it to come back. Thinking about it now, I should probably see if it works after I just leave it alone for a few seconds. In the meantime, I disabled the trackpad in the BIOS and I'm trying my very best to embrace the TrackPoint "Eraser Head" pointer. If you know what's going on with the touchpad, let me know.


The TrackPoint doesn't scroll by default under X.

On Windows, you can scroll by holding the center TrackPoint button while moving the TrackPoint head. This didn't work by default -- center button is "paste" by default under X. I was able to make some more additions to the beginning of my .xinitrc file to get it right, where clicking the center button pastes the clipboard contents, and holding it allows you to scroll with the TrackPoint:

xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation" 1
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Button" 2
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Axes" 6 7 4 5


Audio quality with the default settings

The audio sounded a little tinny and not all that loud when I first played audio over them. Part of the backstory of my admiration of the ThinkPad X1 line is that I pay attention to OpenBSD developers and what they say about hardware. ThinkPads get a lot of praise from the developers I follow, and in one of jcs@'s recent-ish blog posts about the previous generation of X1 Carbon, there was some concern about the audio output. I noticed that while sound was coming out of the "bass" speakers on the bottom of the wrist rest and the "treble" speakers on top near the screen hinges, the tone of the sound coming out of all of the speakers seemed amiss -- and muting the small speakers made it sound better. It turned out to be the same problem as jcs@ noted on the 7th gen X1 Carbon, and adding this line to /etc/mixerctl.conf fixed it, while providing crystal-clear sound through all 4 speakers:


When this laptop's audio is firing on all cylinders, it sounds positively amazing given its size. I've had big old chunky gaming laptops with big old woofers inside them that didn't sound this good. What it has in audio quality, it lacks, just a little, in maximum volume, but it's more than loud enough to fill my workspace with sound, whether I'm in the back of my camper-van or hacking away in my home office.

Webcam support in the browser

YouTube, Discord and some other sites will TRY to use the webcam and microphone - and take note of the kern.audio.record (and upcoming kern.video.record) sysctl options. On Discord's web app, I briefly see my webcam video as the webcam activity LED illuminates, then the LED turns off and Discord returns an error. On YouTube, I never see my own video, but the webcam activity LED blinks briefly. Video capture tools such as ffmpeg and vlc work quite well with the webcam. Given that, I believe there's probably a simple fix to make it work flawlessly, I just haven't found it yet. I'm looking forward to a time, hopefully soon, when I can use an official package or port of OBS Studio, maybe even with working virtual camera support.


The fingerprint reader isn't supported

jcs@ also noted the same of the 7th generation X1 as of 2019. It doesn't bother me in the least. Maybe it'd be neat to log in to OpenBSD with a fingerprint, but I've been using OpenBSD for 21 years without it, so I don't miss the functionality and it's only barely worth mentioning.  

No Bluetooth

Bluetooth has been unsupported by OpenBSD for many years. I don't miss it, but if you decide to try OpenBSD, you might notice that there is no Bluetooth stack.

The good news

What works? Basically everything else. 

  • The function keys for volume, mute, brightness, and keyboard backlight worked without any hassle
  • The built-in ethernet port (which requires a dongle to use) has full support in the kernel via em(4) without requiring a firmware blob.
  • After loading firmware, the on-board Intel WiFi6 adapter is fast and functional via iwx(4). 
  • Sleep/suspend/wake works well via zzz(1) or simply closing the laptop lid. Similarly, using sysctl to disable sleep when the laptop is closed works and it will stay running while closed.
  • WebGL applications, such as some of my favorite online games, work fine now. About a year ago, none of them worked. It could just be that my old laptop didn't have enough resources for these web applications.
  •  YouTube, Social media applications, Google Drive, etc... all good.
  • Even the USB microscope that I use for small electronics work and examining small mechanical parts such as those found in locks and analog watches works great with VLC once I'd created /dev/video2 and set up device permissions.

Battery life seems good. I have been using this laptop for about 3 and a half hours before and during the writing of this review, with moderate screen brightness, several "hungry" tabs open in Firefox and with pianobar (a CLI Pandora client) blasting my "Orbital" inspired playlist. I have two OpenBSD virtual machines running in vmm, though I'm not currently doing anything intense with them. I've been on battery the whole time and I've got 43% battery remaining, with an estimated run time of about 2.5 hours remaining. I can deal with 6 hours of untethered run-time under my usual working conditions.

The system temperature has hovered in the 40-60*C range most of the time, though it got a little warmer when certain browser tasks get rolling. The cooling fan has remained off almost the entire time, but when it's running, it's still very quiet.

I was a little worried that I'd have a "never meet your heroes" moment when I bought this laptop, and that it might not live up to the expectations that I had. So far, it's everything I need and then some.


Multi-booting OpenBSD and Windows 10 on modern hardware with rEFInd

The information here has been refined and documented in a dedicated page for Multi-Booting Windows 10 and OpenBSD. That page has all up-to-date details, and this post is no longer the best available source of information on this topic.

I recently purchased a 13.3" 8th Gen Lenovo ThinkPad X1 Carbon. Frankly, the X1 series has been my dream machine for years. I like small laptops, and this one is light, powerful and is similar to what's used by many of the OpenBSD core developers, so I knew it would probably be well-supported. My previous laptop -- the Acer I upgraded to an i5 for VMM years ago -- was set up for dual-boot, but somewhere along the way, the Windows boot manager stopped booting OpenBSD so I'd been using a modified OpenBSD install image on an SD card to load the OpenBSD kernel from the internal SSD, I set the BIOS to prioritize the SD card for booting, and I just remove the SD Card from my Acer if I need to boot Windows. That laptop is growing long in the tooth, but it's served me well for the past 5 years.

I decided to try properly dual-booting Windows and OpenBSD again with my new ThinkPad. And that's where things got ugly.

The steps to get Windows and OpenBSD working together, as outlined in the OpenBSD Multibooting FAQ seem to not work at all on recent Windows 10 versions, and especially on modern PCs with EFI and GPT disks. I tried several times without any luck, and I also rendered my system unbootable a number of times in my quest. Fortunately, I had made recovery media so I could blow away my X1 Carbon to factory defaults when things went sideways. That's a 45 minute process each time.

Start with a Windows install, and have good backups, including, if possible, external recovery media from the manufacturer. Several times, the drive partition table was so screwed up that the recovery partition was missing as well, leaving me with the recovery USB stick as my only way forward. To resize the Windows partitions, you will have to completely disable BitLocker full-disk encryption if it's enabled. I am a fan of FDE, but we have to turn it off for this to work. You can re-enable it when you have your whole system back up and running, but there are come caveats at the end.

Create a Live USB of GParted.

On another USB stick, write the contents of the OpenBSD installXX.img. This link references install68.img from OpenBSD 6.8, which may be out of date or a broken link when you read this.

Boot into the gparted live distro. On modern EFI/UEF systems, you will probably need to adjust secure boot and/or legacy boot options in your system's BIOS to continue.

Shrink the main Windows partition by some amount to make room for OpenBSD. I gave myself 120GB. That's how much room I have dedicated to OpenBSD on my Acer, and it seems to be a good size. I also usually create another FAT32 or Exfat partition that I can store files on to be accessed from both OpenBSD and Windows, but that's beyond the scope of this write-up.

Create a new partition for OpenBSD in the empty space. GParted doesn't know about OpenBSD partition types, so you'll have to then close GParted and launch a terminal window from the live environment. You'll have to launch gdisk via sudo and address your drive's device. For example:

sudo gdisk /dev/nvme0n1

Use the "p" option to print a list of partition entries. Find the one you created and use the "t" option to change the partition type to "A600" which is what OpenBSD expects to use for its disklabel entries. "w" will write the GPT and exit. You may also want to use the "b" option before you exit to make a backup of your partition tables just in case you mess something up. You'll have to store it to a USB drive, but you can probably store it on the same USB stick you booted GParted from.

At this point, I decided to reboot and make sure Windows still works. Thankfully, it did. Reboot into the OpenBSD installer using the USB stick you created. I won't walk through the whole installer process, but pay very close attention to the disk partitioning options. When prompted for the disks to install OpenBSD to, you should see an "OpenBSD Area" option and that should be the default disk partition to install to. If that option doesn't exist and you choose "gpt" or "whole disk" you will destroy the GPT record on your drive and destroy the Windows installation. Your system will only boot into OpenBSD if you proceed. You can probably use gdisk and your backup of the GPT to recover the partition table if you didn't actually install OpenBSD, or you may have to reinstall Windows and start all over again, and that isn't fun. Trust me. I've done that four times this week. Don't let the system do an auto-layout. Choose "custom." Unless you know what you're doing, just make one big disklabel partition for OpenBSD's root drive.

Once OpenBSD is installed, exit to the shell. You will need to copy the EFI boot executable to some other media so you can access it from Windows. I inserted a USB stick that was formatted for FAT32. It showed up as sd1 and the first non-BSD partition typically shows up as "i"

mkdir /usb
mount /dev/sd1i /usb
cp /mnt/usr/mdec/BOOTX64.EFI /usb/bootx64_openbsd.efi
umount /usb

Go ahead and reboot. It should boot into Windows. Fingers crossed!

Now, go download rEFInd and unzip the archive. I followed the Windows manual install instructions to get rEFInd working. I rebooted again, simply because I'd become so accustomed to bricking my shiny new laptop. To my surprise, rEFInd presented me with a boot menu. Windows showed up, and an additional menu item called "Fallback boot" also appeared. This menu option booted me into OpenBSD. That could be pretty much the end of it, but I wanted an actual OpenBSD menu option.

To accomplish this, I borrowed some mojo from this somewhat dated blog entry on FunctionallyParanoid

You have to access the EFI system partition from a privileged command shell (hearkening back to the instructions to manually install rEFInd from Windows), so I copied the refind.conf file off to my Documents folder, edited it with notepad, then saved it and copied it back over to the EFI system partition.
I added this clause near the end of the refind.conf file:

menuentry “OpenBSD”
icon \EFI\refind\icons\os_openbsd.png
loader \EFI\boot\bootx64_openbsd.efi

Make sure to download the OpenBSD icon and place it in the \EFI\refind\icons folder, too. Once I did that and rebooted, rEFInd still had the "fallback" menu item, but OpenBSD showed up with its own logo alongside the Windows logo. Both operating systems boot, and my mission was finally accomplished.


Mobile Weather Balloon Chasing Rig

A few locals (mostly part of the SecKC crew) have been chasing weather balloons for the past few months. It's an interesting way to get out of the house and go do something. We are also trying to reverse engineer the guts of these weather balloon payloads, but that's a story for another post.

Weather Balloons and Radiosondes

In the US, a number of National Weather Service offices (I'm guessing about a third to half of them) deploy weather balloons every day at about 0:00 and 12:00 UTC, give or take an hour either way. They often launch at about 45 minutes ahead of time, but they can be delayed by severe weather. That's over 700 weather balloons per year from each of the dozens of stations that launch them!

The weather balloons carry something called a radiosonde into the stratosphere. This package contains a battery, radio transmitter, GPS, and weather sensors. The radio transmissions include position information, humidity, temperature and other metrics, once per second. Position information is used to determine wind speed and elevation to correlate with the other metrics. This data is shared internationally and is used for local forecasts and models, and worldwide climate trends. 

Close up of the bottom panel of a 400 MHz Lockheed-Martin Sippican LMS-6 Radiosonde.

The air gets thinner and the pressure lowers as the balloon climbs past 100,000 feet, and it eventually bursts. The package, weighing less than a pound, falls back to the ground under a small parachute so that it doesn't hurt anyone or anything when it lands. 

Here's a video I shot through a telescope, of a weather balloon bursting at about 130,000 feet. You can faintly see the radiosonde swinging beneath the balloon. When it bursts, the parachute expands as the package falls.


A recovered weather balloon, after untangling all of the rope.

The National Weather Service does not recover these devices from the field. Some of them have a mailing bag and shipping label attached so that folks who find them can return them to be refurbished. The radiosondes that we've been finding have no instructions aside from "dispose safely". That is to say, once they have fulfilled their mission and landed, these radiosondes are very much "finders keepers" and are no longer government property. They can land more than a hundred miles away from the launch site, depending on jet streams and wind conditions closer to the surface.


To facilitate the tracking of these devices, a number of software tools have been created to make use of software-defined radio receivers (such as the RTL-SDR or HackRF One) or simple audio-decoding from a computer sound card. My favorite tools are radiosonde_auto_rx and chasemapper, both part of Project Horus, an amateur radio high-altitude-ballooning project in Australia. The tools to monitor amateur balloons happens to work just fine for tracking weather balloons, and folks have added code to help decode the payload data for weather balloons. 

radiosonde_auto_rx scans a small range of frequencies you define, looking for a signal that's likely to be a radiosonde. It then tunes to that frequency and tries to decode the location data. Once it's locked on, it continuously tracks the location of the balloon. It can also upload balloon location data to websites like sondehub (radiosonde tracking) and habhub (high-altitude balloon tracking), so folks can share data about these balloons' trajectories with a world-wide audience.

Screen shot from sondehub.org showing multiple weather balloons in flight, and locations of auto_rx sites:

Chasemapper acquires the balloon location data from radiosonde_auto_rx, and your location from local GPS data, then draws a map of your location and the payload's location, in a browser session. This is a nice visual aid when you're planning on recovering a radiosonde. Here's a screen shot showing my vehicle's track and a radiosonde payload location on a recent balloon chase. The payload location doesn't have a track following it because I rebooted my setup to move it to my car. The movement was from me hiking toward my car while unplugging the battery.

Building the mobile tracker

I decided I'd like to build a semi-mobile balloon tracker that I could leave running at home most of the time, but also quickly toss into my car or even carry with me if a radiosonde was going to be landing nearby, to help me recover it from some corn field or woods or an 8-foot tall patch of thistles and prairie grass out in the middle of nowhere. These things never seem to land anywhere convenient, like in the ditch of a dirt road. 

I decided to make do with stuff I already had laying around. You may recognize some pieces from previous articles. The below links are Amazon affiliate links to the parts I used if you wish to reproduce my exact setup, and purchasing from these links supports this site).

The MiFi 8800L not only offers 4G wireless connectivity so radiosonde_auto_rx can upload location data and chasemapper can download map data, but it also has a GPSd server integrated so other devices (like the Raspberry Pi) can use the GPS location of the hotspot. You must log in to the MiFi admin page to activate the GPS Service. By default, it runs on port 11010, and it's recommended to leave that default set.

Actually getting chasemapper to use that GPS data turned out to be more trouble than I had bargained for. You may be better-off connecting a USB GPS to your Raspberry Pi. I'll cover how I managed to cobble everything together as I go through this post. 

The first order of business was installing the latest RasPiOS to a fresh 16GB SD Card. There is more than enough documentation on raspberrypi.org to get you started. The Rii keyboard works both with a nano-receiver or via Bluetooth. Pick your poison. I chose to use the nano-receiver because bluetooth seems to not like to auto-reconnect on reboot some of the time. Feel free to use whatever kind-of-portable human-interface device you like.

Next, I had to get the display working. 

I had really good luck with the fbcp-ili3941 driver on this Raspberry Pi with Kali Linux, and the instructions I wrote about setting up fbcp worked fine on the latest RasPiOS. You can follow most of the instructions in that article to get the AdaFruit TFT working, just keep in mind the touch screen won't work with the fbcp driver. The digitizer on my display actually broke a few years ago, so I don't miss it.

For my setup, I uncommented the following lines in config.h. Note that these lines need the # at the beginning of the line. I removed the // from these two lines to uncomment them:



I used the following options to build fbcp:


As per the Kali instructions, I put the call to /usr/local/bin/fbcp near the top of /etc/rc.local so that it runs on boot.

I set my display up to run in 480p mode since the display is so tiny. The entirety of my /boot/config.txt file is:






Reboot and make sure the TFT display works.

Now for Radiosonde_auto_rx. The setup instructions mostly work. You'll need to install a bunch of dependencies. They recommend installing rtl-sdr from source. I just added it via apt, and it supported the bias-tee option. Make sure you install the udev rules and module blacklist options per the instructions. 

Keep following the instructions. Maybe, if you're lucky it'll just work. For me, though, I had to do some hacky garbage to get it to compile. If build.sh fails, you can try these tricks: 

I had to tell the compiler use the c11 standard for compiling fsk_demod by adding “-std=c11” to line 50 of auto_rx/build.sh, which now looks like this:

gcc -std=c11 fsk_demod.c fsk.c modem_stats.c kiss_fftr.c kiss_fft.c -lm -o fsk_demod

I had to tell the compiler to use the built-in alloca() for some reason, and the real baffler was having to define the meaning of freaking Pi, twice.

In utils/fsk.c, I added these lines to the "includes" block near the top:

#define alloca(x)  __builtin_alloca(x)

#ifndef M_PI

    #define M_PI 3.14159265358979323846


And I added the following to utils/modem_stats.c, also near the top. 

#ifndef M_PI

    #define M_PI 3.14159265358979323846


With all that out of the way, the instructions for setting up Radiosonde_auto_rx work just fine. Make sure to edit station.cfg. You probably want to specify a name, callsign or handle for uploading to HabHub (and enable uploads), and you should specify your latitude and longitude. You could, in theory, also use gpsd for radiosonde_auto_rx as well. I didn't set up auto_rx to use gpsd, so even when I'm mobile, the reports appear to come from the hard-coded location in auto_rx. I'm fine with that.

It seems that the National Weather Service relies mostly on radiosondes made by Lockheed Martin Sippican. The LMS-6 Radiosonde comes in two "flavors", one operating between 400 and 406 MHz and the other one operating around 1680 MHz. The Vaisala RS41 is a newer radiosonde model used at some locations, and it also operates around 400 MHz. You should ensure the proper frequency range for your location is enabled. The 1680  MHz radiosondes also work best with a circular-polarized antenna, similar to those you might use for certain FPV drone video.

Setting up Chasemapper

The instructions for Chasemapper mostly work out of the box, with the exception of GPSd in my case. The version of GPSd on the MiFi 8800L doesn't support JSON output which Chasemapper requires, so I ended up running a modern version of  GPSd on RasPiOS, pointing it at the GPSd on the hot-spot. Details on that toward the end of the article. I also had some trouble running GPSd on the default port of 2947, so of course I ran it on port 1337. 

For horusmapper.cfg, I changed only the following lines:

car_source_type = gpsd 

gpsd_port = 1337

habitat_call = [my amateur radio callsign]

Tying it all together

I didn't set up systemd services for anything, but you may want to follow the instructions in the git repositories to enable systemd services if you plan on building a dedicated tracker. I run gpsd, auto_rx and chasemapper on-demand with a simple shell script that I call "loon.sh":


gpsd -S 1337 gpsd://

cd ~/radiosonde_auto_rx/auto_rx

python auto_rx.py&

cd ~/chasemapper/

python horusmapper.py&

Everything runs in the background, and the terminal will fill up with logs about both chasemapper and auto_rx status. You can fire up your Raspberry Pi's web browser and hit localhost:5001 for ChaseMapper, and localhost:5000 for the auto_rx status page. 


GMRS and You

With the availability of handheld radios that are more powerful than cheap walkie-talkies, even more powerful radios for your home and vehicles, antenna masts and a small network of repeaters, GMRS allows your family some of the benefits of amateur radio, at a marginal cost, and without every member having to pass an exam. With a decent home and mobile GMRS radio set-up, your family could likely stay in touch even if you stray several miles from home for work or errands.

With the potential of a wide-spread infrastructure outage in an emergency, and increased tracking of location data via smart phones, payment card transactions and the like, adding GMRS to your family's communications strategy can make a lot of sense.


General Mobile Radio Service (GMRS) is a UHF Land Mobile Personal Radio Service, not much unlike Citizens Band (CB) or Family Radio Service (FRS). In fact, 14 frequencies used by GMRS are shared with FRS.

Up until the rules changed in 2017, one had to obtain a GMRS license to use channels 15-22 on FRS/GMRS handheld radios that look a lot like the one on the left in the title photo above. That radio is actually a 5 watt Midland GXT-1000 GMRS radio, but with a few caveats, it can be used for FRS as well.

Recent changes were made to allow up to 2 watts on channels 1-7 and 15-22 as part of FRS without obtaining a license. Channels 8-14 are still reserved solely for FRS use in the US, with a maximum of 500mW output. A number of FRS radios are available that run close to 2W on legal channels, but today I'll be focusing on GMRS specifically. The primary differences between FRS and GMRS are:
  • GMRS handheld radios are allowed to transmit up to 5W
  • GMRS mobile and base-station radios are allowed up to 50W
  • Removable antennae are allowed
  • Repeaters can be used on GMRS
  • An FCC license is required for GMRS, but there is no exam.
  • Businesses can legally use FRS for operations, but business use of GMRS is mostly disallowed.

The Rules

A short, multi-page primer on GMRS is provided by the FCC.
The full rules for operating on GMRS are in FCC Part 95 subpart E.

The short, short version of the rules that should cover most of the highlights:
  • No "public broadcast" messages, advertising or music
  • No profanity
  • Only communicate with other GMRS or FRS users. Communication with amateur radio stations is not allowed.
  • No "Jamming" or continuous transmissions
  • Don't use GMRS to assist in any criminal activity
  • You must identify your call sign (e.g. WRBX000) in English or morse code
    • At the end of a single transmission that you do not expect a reply to
    • At the end of a conversation
    • At least once every 15 minutes while communicating
  • You can authorize any family members to use your license with your permission.
    • Your parents, children, grandparents, nieces, siblings and uncles can legally operate on GMRS under one single license, if you give them permission and ensure they know the rules.
    • If they break the GMRS rules under your license, your license is likely in jeopardy. You are ultimately responsible for the actions of those using your license.
While GMRS is provided as a convenient way for family members to stay in touch, an authorized GMRS user is allowed to talk to others outside of their family. They do not need to be physically close enough to you to communicate with you as the license holder as long as they obey the rules.


Most adult United States citizens are eligible to apply for a GMRS license. As of 2020, the license fee is $85, and it is valid for 10 years from the date of issue.

One can apply for a GMRS license online through the Universal Licensing System, or by mail. Either way, you must fill out FCC Form 605. Filing online requires you to register for an FCC Registration Numer (FRN) if you do not already have one. Amateur radio operators may use their existing FRN, for example.

Once logged in to ULS, click "Apply for a new license" and choose "ZA - General Mobile Radio Service" from the very bottom of the drop-down list.

Upon completion of FCC Form 605 for GMRS, you will be required to make an online payment. Your license will usually show up within a few hours or on the next business day. You will also likely receive an email about your license grant.



Transceivers specifically designed for amateur radio are not allowed on GMRS. Some hams use commercial radios that have been tuned to work on amateur radio frequencies, and there's a bit of a grey area there.

Until recently, hardware specifically designed to take full advantage of GMRS was pretty rare. Radios must be type-certified under FCC Part 95 to operate on GMRS and strict standards must be met with regard to channel deviation, frequency stability at a wide variety of temperatures, and spurious emissions. It just so happens that commercial land mobile UHF Radios type-certified under FCC Part 90 meet or exceed the specifications for GMRS, so long as they do not exceed 50 watts of output power. As such, many GMRS users will re-program commercial UHF radios to operate on GMRS frequencies. The FCC hasn't ever given a straight answer about if this is allowed, but most repeater operators are okay with it. The Motorola Radius in the above photo is one of these, but a variety of 15-45 watt mobile radios and 2-5 watt handhelds from the commercial lines of Motorola, Kenwood, Bendix/King and others can often be found inexpensively on the used market. Just make sure you, or the seller, can program them properly.

BTech (purveyors of the ubiquitous, cheap "Baofeng" ham radios) markets two GMRS-specific radios: the GMRS-v1 handheld and the GMRS-50X1 mobile radio. These two have been type-certified for GMRS, have the ability to use GMRS repeaters, and are legal. The GMRS-V1 is, in fact, the only GMRS-specific handheld radio I was able to find that has repeater capability.

Midland, Cobra, and Uniden have also been making a variety of type-certified GMRS radios. Most of the handheld units, like the Midland GXT-1000 I have, do not have the capability to use GMRS repeaters, but the Midland Mobile and Micro-Mobile radios, designed to be installed inside vehicles, do have repeater capability.

Most GMRS radios are interoperable with FRS radios. The GMRS-specific radios mentioned above may have more than 22 channels, but channels 1-22 are almost guaranteed to work between any GMRS and FRS radio. If your family does a lot of outdoor activity, you may find that inexpensive FRS radios work fine for kids, and your GMRS radios will let you communicate with them.

Many old-school GMRS users refer to frequencies -- and especially repeaters, by the kilohertz part of the frequency only. I suspect this persists in part because GMRS users are begrudgingly sharing practically all of their frequencies with FRS users and dislike the concept of channel numbers. At any rate, "700" refers to either 462.700 MHz, or a repeater that uses 467.700 MHz on the input and 462.700 MHz on the output.

You can see actual frequencies in this chart on Wikipedia:


Like amateur radio, GMRS operators can run repeater systems. These repeater systems listen 5MHz higher than the base frequency, and re-transmit the signal on the base frequency so that all radios listening can hear the message. Not all regions have GMRS repeaters, but here in the Kansas City area, there are several to choose from. Unlike amateur radio repeaters, most of them require permission from the repeater operator before you use them.

MyGMRS.com is probably the closest thing there is to a directory of all GMRS repeaters in the United States. You can browse the repeater listings without signing up for an account, but many repeater details (such as the CTCSS or DCS codes to use them) are hidden until you log in. Some of these details are completely unlisted, instead requiring you to ask the repeater owner for permission. You can only create a MyGMRS account once your GMRS license has been active for a day or two and the website has imported your license from the FCC.

You can also buy or build your own GMRS repeater, and it probably comes as no surprise that commercial repeater hardware is also quite common. Repeater building is a complex topic I won't cover here, but the cost is usually pretty significant.


Yaesu FTM-400XDR - Undocumented Cross-Band Repeater Mode

I was in the market for a new dual-band amateur radio. I'm a bit of a Yaesu fan, and I was torn between trying to find a used workhorse like the  FT-8900R, or trying something a bit more modern, like the FTM-400XDR. The one thing I really wanted the '8900R for was its cross-band repeater. That was the only thing missing from the new '400XDR.

Cross-band repeater mode will listen on two different bands (usually 70cm and 2m) and repeat what's being "heard" on one of the bands, transmitting it on the other. You can use this for a variety of purposes, but it's most commonly used to boost the range of a small handheld radio when you can't feasibly take a high-powered radio with you -- such as into an office building, down in your basement storm shelter, or keeping in touch with a group of spread-out friends while in an area without good repeater coverage.

Lo and behold, the FTM-400XDR does have a cross-band repeater built-in. It's just not documented officially. It's actually pretty easy to set it up.

Start by configuring your radio's tuners the way you want them to work together. Check that the frequencies, repeater offsets, squelch are all correct, and disable APRS if you had it enabled.

In this case, I configured the top tuner to communicate with a local repeater, on medium power. It might be kind of hard to see, but there are indicators "-" and  "T-TRX" in the header of the top tuner that indicate a negative repeater offset, and "Tone Squelch on Transmit and Receive" which are common radio configurations for repeater use. You could instead set the upper tuner to a simplex frequency if you want to run it as a stand-alone temporary repeater.

The bottom tuner has to be on the other band. Since the repeater I wanted to talk through is on the 2m band, I selected a simplex frequency from within the 70cm band.  Since I plan on staying pretty close to my radio for this test, I set the power level on the bottom tuner to low power, and made sure there was no auto-repeater-shift offset. You'll notice there are no indicators in the header of the lower tuner. You would not want to accidentally link two other repeaters together. Don't cross the streams.

Power the radio off. Next, hold the SETUP, F and GM buttons under the power button at the same time. Keep holding them while you power the radio on.

When it powers up, you will see an "X-Repeater" indicator in the middle of the screen.

If you're setting up a stand-alone repeater, all users will have to configure their dual-band handheld radios for "split" operation. This varies by make and model, but you'll want them to transmit on the same frequency as the bottom tuner, and receive on the same frequency as the top tuner of the '400XDR. Anything transmitted by members of your party on the lower tuner's frequency will be repeated out to everyone else listening on the upper tuner's frequency.

To use the cross-band repeater with another repeater like I did, you'll want  to set your handheld radio to use the simplex frequency, without a repeater shift, that's displayed on the bottom tuner. The cross-band will relay bi-directionally, so whatever you transmit will be sent to the repeater configured on the upper tuner, and whatever the repeater transmits will be sent back to your handheld via the simplex frequency on the lower tuner.

To disable cross-band repeater mode, power the radio off, then use the same 3-finger-salute while powering it back on.

  • When the repeater isn't being actively used, you're still responsible for ensuring it is functioning properly. Your cross-band repeater has no way to identify itself. (e.g. CW ID) and lacks the sophistication of a real repeater.
  • You or someone you trust should be close enough to your cross-band repeater to shut it off quickly should it malfunction or otherwise transmit undesired activity (such as static, intentional interference, radio pirates).
  • Turn the radio off or disable cross-band repeater mode if you are not actively using it or are unable to monitor it.
  • Use the minimum power level possible for the communications required. This is just best-practice, but also, if you end up cross-band repeating a long-running discussion, you may overheat your radio and/or drain your car battery. Mobile radios like this are designed for a relatively low duty cycle -- transmitting only for a few minutes at a time, then given a chance to cool down while others talk. Low power (5 Watts) is probably safe for extended, continuous bidirectional operation.
  • The FTM-400XDR is capable of operating on Yaesu System Fusion (C4FM) digital modes, but under cross-band repeater mode, it will only operate in analog FM mode. You cannot cross-band repeat to a digital repeater from an analog handheld radio.
    • I do wonder if another Fusion radio could communicate through a cross-band repeater to a Fusion Repeater and vice/versa... I don't have a second Fusion radio to test this with.