William Reading

Travel: Water Filtering

Wed, 05 Aug 2026 00:00:00 +0000

Introduction

Despite the introduction of filtered water fill stations, it’s still annoying to get filtered water in a lot of hotels or at an airport. There’s existing solutions for outdoors use, but they often don’t have carbon filtration. There’s also existing solutions for travel use, but they’re usually only carbon, and don’t have ion-exchange resin for improved taste. You can buy pitcher filters that do this, but packing a water pitcher takes up a lot of space and you can’t as easily have it in a backpack. Hotels usually do have bottled water, but even if it’s free, it’s hard to get as much as you might want, and there’s a lot of waste.

Before we get started, note that this is only for filtering biologically safe water. If the water is unsafe, then I’d suggest a SteriPen to sanitize it. If the water is cloudy, this isn’t going to work so well, so you’ll need to add a flocculant such as P&G Purifier of Water first before further treating it.

Experimenting with ZeroWater

I’d originally started off with a ZeroWater because it deionizes water and you get to pick what minerals you want to add to it. And for places that might have questionable water treatment, it’s hard to beat it for removing heavy metals from the water. For this, I 3D printed a Zero Water Travel Filter. But there’s a few problems. One, it’s huge, and has gotten my bag sidelined for extra screening. Second, if you want the water to taste better, you’ll need to add your own minerals to it, so that’s more to carry. It works great for things like humidifiers to avoid mineral deposits, but I think for daily drinking water, it’s kind of overkill and annoying. Plus, the filters are expensive and there aren’t generic ones you can easily buy.

Trying other filters

I went to a Target and looked to see what they carried, since it’s easier to get more supplies at a big national store than it is to order them online. That doesn’t help me when I’m traveling abroad, but that’s not the majority of my trips. I’d wanted the ion-exchange resin in there because it tends to improve flavor. I landed on the Brita Filter Elite and the Pur Plus. I think on paper the Pur Plus filter does a better job, but in practice, the flow rate is so slow that it’s annoying. Tasting the water out of my faucet, the Brita Filter Elite tasted a little bit better too, so it won on flow rate and flavor. It’s true that it filters less, but I don’t need it to filter everything. Plus, there’s multiple brands of compatible filters. So I decided to build a design around that one.

Designing Around the Brita Filter Elite

I got this idea the day before going out of town and I didn’t have a lot of time to do a design. I’d started by taking the dimensions of the bottom of a brita filter funnel and making it just a tube with the filter on the bottom. That design was really compact and worked fine for wider bottles, but didn’t do the trick for the ~500mL Nalgene bottles that I like to bring with me. So I needed something a bit different. For the ZeroWater, I’d just balanced the filter on top of the water bottle and the drip out of the bottom of it didn’t really make a mess. For this one, I needed to redirect the water downward into the bottle.

I tried designing this one using gpt-5.6-sol in OpenSCAD with a source sketch, a bunch of dimensions with my calipers and some test models. I got a lot of the way very quickly, including the tapered design, bottle adapter, and rough filter snap, but I ended up having to do a lot of test prints to get the fit just right. I wanted to print it from the top on the build plate up, and the more complex parts were a little tricky.

But I did finally get it to work. The result is over here on MakerWorld: 16oz Nalgene Brita Filter Cup, and the corresponding caps for it Caps for 16oz Nalgene Brita Filter Cup. It holds around 175mL on the top, and travels pretty well. The tapered base means that you can stick it on the top of a lot of different wider bottles, and it can sit nicely on my Nalgene bottle.

A Note on Safety

I used transparent PETG for this design because PET is generally safe and used in a lot of things. Transparent PETG doesn’t have non-food-safe colors. There’s going to be microplastics, but it’s not much different than bottled water in many cases. That all said, now that I’ve found that this design works, I’d like to cast it in food-safe silicone. That will prevent bacteria from getting stuck in the inner parts of not perfectly watertight prints, and while silicone can suck up some smells, it’s easy to fix by baking in the oven, which also helps sanitize it.

Website and Traveling Party Housekeeping

Tue, 04 Aug 2026 00:00:00 +0000

Back in 2016, I started a traveling blog. I got a good deal on a .party domain, due to a funny mismatch between domain squatters using a British dictionary and not reserving the American spelling. The thing is that it never really made sense to do just the travel stuff on a separate domain, so I’ve merged the articles over to my primary williamreading.com domain, 301 redirected the stuff from the old site to the new site, and let archive.org know for folks that have old links. The content has mostly been updated to have correct titles, but there’s probably something that’s wrong somewhere.

The photo gallery has also gotten some TLC. It was completely broken before and now it’s been migrated over to build on Jekyll. The photos are still pretty old, but maybe one day more stuff will go up there.

I’ve also fixed a lot of stale links and provided a few in-line updates for stuff that’s pretty old. Let me know if something is broken there too.

Travel: Coffee, Part 3

Mon, 22 Jun 2026 00:00:00 +0000

Introduction

It’s been about seven years since I first wrote about traveling with coffee, and five years since the second update. I’ve also written about improving US hotel room coffee in the meantime.

After all that experimenting, I’ve mostly converged on a setup that works for me, so this post is less of a survey and more of a summary of where I’ve landed.

The Kit

My current setup (pun intended) boils down to a few things: A UL-listed immersion heater, an OXO mini-squeeze measuring cup, a Nanopresso, a few Nespresso pods in a carrying case, a small espresso cup, and a small scale.

OXO Mini Squeeze Measuring Cup

The biggest change is that I’ve replaced the dedicated travel kettle with an Norpro immersion heater and an OXO mini squeeze measuring cup. It’s made of silicone and plastic that can handle boiling water, the squeeze design makes it easy to pour precisely, and it doubles as a measuring cup, which I’d been carrying separately anyway for pour-over ratios. The immersion heater fits inside the measuring cup and looks sketchy but is safe in practice because it has a non-replaceable fuse that will render it inoperable before it starts a fire.

The big advantage is that both pieces pack down smaller than any dedicated travel kettle I’ve used. I just boil water with the immersion heater dropped into the measuring cup, then use the cup to pour.

In-room Pour-over

When I don’t feel like dealing with pods, I’ll do a pour-over using whatever coffee is in the room. I covered the specifics of this in my post on improving room coffee, but the short version is that I use a 1:15 ratio of coffee to water by weight, and the results are usually better than what the in-room machine produces on its own.

If you don’t travel with a scale, a reasonable rule of thumb is that a lot of the hotel packs are around 8g of coffee, and so that’s around 120mL (4 fl oz) of water to extract them at a 1:15 ratio, and since usually the cups are around 240mL (8 fl oz), about half the cup will get you in the right ballpark. This usually means you’ll need to use two of the packs in the room to get to a full cup, but it’s so much better that way.

Nanopresso

In the last update, I was lukewarm on the Nanopresso. After using it more, I’ve come around on it.

I think something I didn’t initially appreciate is that while both the Nanopresso and Nespresso rely upon pressurized extraction, the Nespresso machine seems to mostly rely upon small holes in the brew group, while the Nanopresso uses larger holes and a spring to achieve the right level of pressurization. I think the spring-based approach results in a better extraction than the Nespresso, despite it being third party.

On Your Own Pods

The other thing that is interesting about nespresso is that it looks like there are modifications that were made to Nespresso machines at some point to make it less likely that they will seal with the capsule properly, meaning that everything without those changes (the Nanopresso included) will work better with third party pods, including those that you’ve filled yourselves. I’ve done a little bit of experimenting here, and I’ve found that around 6-8g of coffee seems to work pretty well (though you’ll need to play with the grind to get it just right), and the little papers are really important to put at the bottom of the capsule so that it stays together when it’s been punctured.

Travel: Toll Tags in the US

Mon, 13 Oct 2025 00:00:00 +0000

Depending on where you’re visiting in the US, toll tags might be an unavoidable part of driving. Furthermore, it can be tricky to know which toll tag you need for what part of the country.

Back in 2012, Congress passed the MAP-21 Act, which required that by the end of October 2016, it be possible to have a single toll tag and account for all federally-funded toll roads in the US. There was no penalty for non-compliance, and no funding was provided, so it’s been slow moving.

Technically, this mostly happened in the form of NATIONALPASS for CA, DE, FL, IL, IN, KS, KY, MA, ME, MD, NH, NJ, NC, NY, OH, PA, RI, TX, VA, and WV. Unfortunately, NATIONALPASS has a monthly fee starting at $16/mo, with $3.50/tag. Note that this crazy thing doesn’t even work on all the toll roads. Washington and Oregon aren’t covered, for example.

Practically speaking, you can get a lot of the country with a couple of toll tags: E-Z Pass, and the North Texas Tollway Authority hub.

For the E-ZPass network on the East coast, you can get one from any of the states or authorities that issue them and they all work together. Someone has helpfully built a comparison matrix here: E-Z Pass System Comparison.

I’d suggest the Massachusetts E-ZPass because the tag doesn’t require a deposit and there are no annual fees or non-usage fees. You’ll need a holder to be able to be able to move this tag between vehicles, so I suggest the JL Safety one, which lasts around five years for me.

If you happen to live somewhere near NYC, I’d suggest getting the NY Thruway tag. Unlike the Port Authority and New Jersey passes, you don’t get charged a monthly fee, but you still get some local discounts. The tricky part is getting one. By default, if you don’t live in the Thruway area, you’ll get assigned to the PANYNJ pass, which might not be the one you want. You can have them manually make you an account, or buy one in person and activate that one. I used the AAA in Nanuet, but I’m sure there are other places that sell them.

For the North Texas system, I recommend the K-Tag that comes with suction cups. There is a sticker version, but it’s difficult to move between vehicles. Like the Massachusetts E-ZPass, you don’t pay anything for it when you’re not using it, though you’ll have to pay $25 for them to send you the movable one.

If you’re looking to get a toll tag for one of these areas that aren’t in one of the big networks, hopefully it’ll become easier soon. I’d suggest going for a movable transponder if you can get one versus the sticker. While NationalPass used to run only $8/mo, it’s now up to $12.50/mo per account, plus $3.50/mo per transponder. This maybe isn’t the worst pricing if you have a fleet, but it’s still free to just get individual tags.

Travel: Finding Wired Ethernet

Mon, 13 Oct 2025 00:00:00 +0000

In 2018, I talked a bit about travel routers in general. I still use a newish version of the gl.inet brand, since they just work as a client for most wifi, can plug into ethernet, and run just fine off a battery for hours.

Where to find wired ethernet in hotels?

It used to be more common to find wired ethernet on the wall itself, but many hotels have stopped explicitly offering it as a service.

That said, there sometimes are ethernet ports hiding in the room, but they’re not necessarily marked. And even when there is something on the other side, they might not give out IP addresses to random mac addresses.

Weird places I’ve found ethernet ports:

On the phone, in the back
On a wireless bridge on the wall (often two ports)
On a media converter for the tv’s network on the back of a TV

Often if I can get one of these ports to work, it’s usually several times faster than what I’d get from wifi bridging, so it’s usually worth a look. Most of the time they’re dead though.

Making a Neopixel on an Adafruit ESP32-C6 work with ESPHome

Fri, 10 Oct 2025 00:00:00 +0000

Introduction

I’m using ESPHome as my preferred choice for a lot of work on sensor microcontrollers around the house because it works really well with Home Assistant, and it’s more or less config and wireless OTA for updating, which is really convenient.

I recently picked up the Adafruit ESP32-C6 Feather at the local microcenter so that I could use the Neopixel to display a color tied to my calendar, and hang it off a door handle powered off the battery. Out of the box, it took enough finagling that I figured I’d write it up because I couldn’t find what I needed online.

So a few things about this board:

It uses the WS2812 LED, which can be driven from the esp32_rmt_led_strip light platform.
The RGB order is GRB on this LED, which I’ve found to be the same for my Adafruit metro boards as well
The LED is sitting on what adafruit says is pin IO9, or GPIO9 in ESPHome
It’s off by default, and needs GPIO20 (what adafruit calls NEOPIXEL_I2C_POWER on this board) to be pulled high in order to turn it on, assuming you’re using the esp-idf anyway, which is all that seems supported on this board

Putting that all together, you need some configuration blocks like this:

esphome:
  name: status-light
  friendly_name: status-list

  # Enable neopixel on boot
  on_boot:
    - priority: 90
      then:
        output.turn_on: neopixel_i2c_power

esp32:
  board: esp32-c6-devkitc-1
  framework:
    type: esp-idf

light:
  - platform: esp32_rmt_led_strip
    id: neopixel
    rgb_order: GRB
    pin: GPIO9
    num_leds: 1
    chipset: ws2812
    name: "neopixel"
    effects:
      - pulse:
          transition_length: 550ms
          update_interval: 550ms

Hopefully if you’re stuck getting this board to work, this will get you started.

Weather Station MK2

Thu, 02 Jan 2025 00:00:00 +0000

Introduction

Back in 2021, I put together a weather station using WeeWX and weewx-sdr. This worked pretty well, but it meant dedicated hardware for just weather and also meant that the driver needed to know about every piece of hardware that you want to use in order to map it into WeeWX.

When I moved, I wanted to take a different approach, where I have one SDR with rtl_433 and have that send messages over MQTT. I don’t love MQTT, but it works well enough as a message bus, and with a little bit of configuration, I can have both Home Assistant and WeeWX consume the data without having to build bridges from things like InfluxDB.

The listener

While I could have run this on the same host that I run home assistant, it’s located near the networking hardware, and this isn’t a great place to listen for transmissions. For that, the attic makes a lot more sense. I reused the same Raspberry Pi that I had used for the weather station, but now it publishes anything it can decode over MQTT. I’m also still using an RTL-SDR.com dongle because they are high quality.

For ease of moving stuff around as well as having to worry less about the OS software, I’m doing all of this stuff with docker this time around, and that includes rtl_433.

After plugging it in, I looked for the USB device to map it into the docker container:

$ lsusb
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 005: ID 0424:7800 Microchip Technology, Inc. (formerly SMSC) 
Bus 001 Device 003: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Microchip Technology, Inc. (formerly SMSC) USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

On my Raspberry Pi 3B, it showed up on Bus 001 as Device 004.

I use this docker-compose.yml file to set it up:

services:
  rtl433:
    image: hertzg/rtl_433:latest
    devices:
      - "/dev/bus/usb/001/004"
    restart: unless-stopped
    command:
      - "-Mutc"
      - "-Fmqtt://<broker-hostname>:1883,retain=0,events=rtl_433[/model][/id]"

A quick docker compose up -d later and I was getting messages such as these in mosquitto:

rtl_433/Acurite-Atlas/905 {"time":"2025-01-02 16:56:29","model":"Acurite-Atlas","id":905,"channel":"C","sequence_num":0,"battery_ok":1,"message_type":39,"wind_avg_mi_h":4.0,"uv":1,"lux":10250,"strike_count":0,"strike_distance":31,"exception":0,"raw_msg":"0389e782818881009f1e"}
rtl_433/Acurite-Atlas/905 {"time":"2025-01-02 16:56:29","model":"Acurite-Atlas","id":905,"channel":"C","sequence_num":1,"battery_ok":1,"message_type":39,"wind_avg_mi_h":4.0,"uv":1,"lux":10250,"strike_count":0,"strike_distance":31,"exception":0,"raw_msg":"0789e782818881009f22"}
rtl_433/Acurite-Atlas/905 {"time":"2025-01-02 16:56:29","model":"Acurite-Atlas","id":905,"channel":"C","sequence_num":2,"battery_ok":1,"message_type":39,"wind_avg_mi_h":4.0,"uv":1,"lux":10250,"strike_count":0,"strike_distance":31,"exception":0,"raw_msg":"0b89e782818881009f26"}

Mosquitto was straightforward to set up on the host that I had running home assistant with this docker compose file:

services:
  mosquitto:
    image: eclipse-mosquitto
    container_name: mosquitto
    restart: unless-stopped
    volumes:
      - /home/<user>/docker/mosquitto/config:/mosquitto
    ports:
      - 1883:1883
      - 9001:9001

Home Assistant Aside

I found that setting up the listener to emit messages in that format works well with home assistant, since you can set up entities like this:

    - name: "Weather Station Temperature"
      state_topic: rtl_433/Acurite-Atlas/905/msg37
      unit_of_measurement: '°F'
      device_class: temperature
      value_template: '{{ value_json.temperature_F }}'
    - name: "Weather Station Humidity"
      state_topic: rtl_433/Acurite-Atlas/905/msg37
      device_class: humidity
      unit_of_measurement: '%'
      value_template: '{{ value_json.humidity }}'
    - name: "Weather Station Wind Speed Average"
      state_topic: rtl_433/Acurite-Atlas/905/msg38
      device_class: wind_speed
      unit_of_measurement: 'mph'
      value_template: '{{ value_json.wind_avg_mi_h }}'
    - name: "Weather Station Wind Direction"
      state_topic: rtl_433/Acurite-Atlas/905/msg38
      unit_of_measurement: '°'
      value_template: '{{ value_json.wind_dir_deg}}'
    - name: "Weather Station Cumulative Rain"
      state_topic: rtl_433/Acurite-Atlas/905/msg38
      device_class: precipitation
      unit_of_measurement: 'in'
      value_template: '{{ value_json.rain_in }}'
    - name: "Weather Station UV Index"
      state_topic: rtl_433/Acurite-Atlas/905/msg39
      value_template: '{{ value_json.uv }}'
    - name: "Weather Station Illuminance"
      state_topic: rtl_433/Acurite-Atlas/905/msg39
      device_class: illuminance
      unit_of_measurement: 'lx'
      value_template: '{{ value_json.lux }}'
    - name: "Weather Station Cumulative Lightning Strikes"
      state_topic: rtl_433/Acurite-Atlas/905/msg39
      value_template: '{{ value_json.strike_count }}'
      # See https://www.wxforum.net/index.php?topic=34293.0
    - name: "Weather Station Last Lightning Raw Strike Distance"
      state_topic: rtl_433/Acurite-Atlas/905/msg39
      value_template: '{{ value_json.strike_distance }}'
    - name: "Weather Station Pressure"
      device_class: atmospheric_pressure
      state_topic: rtl_433/Oregon-BTHR918/206
      unit_of_measurement: 'hPa'

Note that there are those messages split out there. For home assistant, since the Atlas weather station sends messages in three chunks, home assistant will do weird things if they aren’t broken out by message type. If this isn’t needed, such as for my pressure sensor listed, then there is no need to refer to it by message type.

An automation such as this one will break it out into message topics for home assistant to use, but we won’t use these messages with WeeWX:

- id: '1730688156106'
  alias: RTL433 MQTT message_type Demuxer
  description: Split rtl_433/# signals into msg topics, if message_type exists
  trigger:
  - platform: mqtt
    topic: rtl_433/+/+
  condition:
  - condition: template
    value_template: '{{ trigger.payload_json.message_type != null }}'
  action:
  - data:
      payload: '{{trigger.payload}}'
      topic: rtl_433/{{trigger.payload_json.model or "UnknownModel"}}/{{trigger.payload_json.id
        or "UnknownId"}}/msg{{trigger.payload_json.message_type}}
    action: mqtt.publish
  mode: single

This ends up looking something like this:

rtl_433/Acurite-Atlas/905/msg39 {"time":"2025-01-02 16:56:29","model":"Acurite-Atlas","id":905,"channel":"C","sequence_num":0,"battery_ok":1,"message_type":39,"wind_avg_mi_h":4.0,"uv":1,"lux":10250,"strike_count":0,"strike_distance":31,"exception":0,"raw_msg":"0389e782818881009f1e"}

WeeWX Setup

For this, I used the weewx-docker and WeeWX-MQTTSubscribe. I’m running this as a driver instead of just to supplement readings from another weather station, so I’m using it in that configuration.

I’m using this docker compose file for it here:

services:
  weewx:
    image: felddy/weewx:latest
    volumes:
      - type: bind
        source: ./data
        target: /data
    restart: unless-stopped

You’ll need to install paho-mqtt, like so:

docker compose run --rm --entrypoint pip weewx install paho-mqtt

And you’ll also need to install the extension, like so:

docker compose run --rm weewx \
  extension install --yes \
  https://github.com/bellrichm/WeeWX-MQTTSubscribe/archive/refs/tags/v3.0.0.zip

With that out of the way, I then configured it. Some relevant portions of the weewx.conf configuration:

[Station]

    # Description of the station location, such as your town.
    location = WeeWX station

    # Drop a pin in a location and use the URL in google maps to get this
    # Latitude in decimal degrees. Negative for southern hemisphere.
    latitude = 0.0
    # Longitude in decimal degrees. Negative for western hemisphere.
    longitude = 0.0

    # Altitude of the station, with the unit it is in. This is used only
    # if the hardware cannot supply a value.
    altitude = 0, meter    # Choose 'foot' or 'meter' for unit

    # Set to type of station hardware. There must be a corresponding stanza
    # in this file, which includes a value for the 'driver' option.
    station_type = MQTTSubscribeDriver

    # If you have a website, you may specify an URL. The URL is required if you
    # intend to register your station. The URL must include the scheme, for
    # example, "http://" or "https://"
    #station_url = https://www.example.com

    # The start of the rain year (1=January; 10=October, etc.). This is
    # downloaded from the station if the hardware supports it.
    rain_year_start = 1

    # Start of week (0=Monday, 6=Sunday)
    week_start = 6

[MQTTSubscribeDriver]
    # This section is for the MQTTSubscribe driver.

    # The driver to use.
    # Only used by the driver.
    driver = user.MQTTSubscribe

    # Controls if validation errors raise an exception (stopping WeeWX from starting) or only logged.
    # Default is false
    stop_on_validation_errors = true

    host = mqtt.example.com

    # Controls the MQTT logging.
    # Default is false.
    log = true

    [[topics]]
        # The WeeWX unit_system of the incoming data.
        unit_system = METRIC

        # Adjust this to account for the window that the multiple payloads get received
        adjust_start_time = 30

        # Barometer
        [[[rtl_433/Oregon-BTHR918/206]]]
            ignore = True
            [[[[message]]]]
                type = json

            [[[[pressure_hPa]]]]
                ignore = False
                name = pressure
                units = hPa

            [[[[temperature_C]]]]
                ignore = False
                name = inTemp
                units = degree_C

            [[[[humidity]]]]
                ignore = False
                name = inHumidity

        # Weather station
        [[[rtl_433/Acurite-Atlas/905]]]
            # Explicitly select fields
            ignore = True

            # We're doing json
            [[[[message]]]]
                type = json

            # See https://www.weewx.com/docs/latest/reference/units/?h=measurement
            [[[[temperature_F]]]]
                ignore = False
                name = outTemp
                units = degree_F

            [[[[humidity]]]]
                ignore = False
                name = outHumidity

            [[[[lux]]]]
                ignore = False
                name = illuminance

            [[[[rain_in]]]]
                ignore = False
                name = rain
                units = inch
                contains_total = true

            [[[[wind_avg_mi_h]]]]
                ignore = False
                name = windSpeed
                units = mile_per_hour

            [[[[wind_dir_deg]]]]
                ignore = False
                name = windDir

            [[[[uv]]]]
                ignore = False
                name = UV

You should validate that the data services section does not have the service version of the MQTT subscriber because then it will have weird behavior if you don’t configure it twice.

You might also find that changing the log level to DEBUG at the bottom of the file from INFO is helpful while debugging. Note that there are a couple of things going on above, but essentially you have to say that you’re ignoring all the fields and only cherry picking some of them.

And with that, everything seems to work.

Using Amateur Radios for Public Service

Tue, 02 May 2023 00:00:00 +0000

Introduction

I recently volunteered doing Amateur Radio support at the Boston Marathon, and was trying to figure out what gear I should bring given that it was going to be my first time and I wanted it to work well. My considerations before the race were mostly around water resistance (or low enough cost where I can take the risk), battery life (ideally charging via USB-C), and fatigue from loud audio in my ear. I also bought a radio harness that was helpful for carrying stuff around all day.

Radio Harnesses

I was a bit skeptical about this one. There’s a survival guide that recommended the “abcGoodefg” one on Amazon, but it was too small. I ultimately ended up getting a used True North Dual Universal Radio Hardness, which was comfortable and had plenty of space.

If I wanted something less expensive and more lightweight I think that a fire radio strap, such as the one made by X-FIRE would work just fine, and I saw a few folks sporting fancier versions of these.

Headsets, Microphones, and Earpieces

I originally thought that I’d probably end up spending most of the time using a Heil Handie Talkie Headset (HTH), but the microphone stopped working about an hour into volunteering. My BTech QHM22 speaker mic saved the day as a microphone, and I used a cheap RLN4941A-type earpiece to be able to hear. It did get loud at times as advertised.

Powering Radios

It was mentioned at the symposium a few weeks before the race that it’s a good idea to make sure you have plenty of battery power on hand. These days, you can get a cheap Baofeng radio and an inexpensive 28Wh battery that you can power via USB-C. That alone is a nice reason to bring one as a backup radio.

Baofeng GT-5R squelch & pop

Next I focused a bit on loud audio. The cheapest radios, such as the Baofeng GT-5R (the compliant version of the UV-5R) don’t protect against surge current when their power amplifiers turn on and off (See Baofeng UV-5: Squelch Pop Suppression), which is annoying at the end of a transmission with a headset, particularly a loud one. I built a cable with some inexpensive diodes to suppress the pop, but it still had an open squelch at the end that was loud.

Squelch Tail Elimination

There are a number of standard ways that you can eliminate squelch tail on an analog transition, with common ones being to use DCS (possibly the best option), CTCSS (PL tone) with reverse burst, and the Chinese radio 55 Hz (or less commonly, such as Anytone, 259.1 Hz) tone. Some amateur radios will turn off the PL tones before they end the transmission as well. There’s some history of CTCSS and some other methods over at Repeater Builder.

I noticed that the repeater for my radio assignment emitted a -180° reverse-burst tone, and this seemed like a good place to start.

Unfortunately, working with reverse burst CTCSS tones isn’t exactly a standard amateur radio feature. My Wouxun radio apparently does honor one at 120°, but doesn’t document this, and I needed -180°. This does seem to be a feature in some DMR radios, including my COTRE CO01D, but I certainly wasn’t going to use a $10 2W toy radio with a fixed antenna and 5.5W battery. My BTech 6X2 and Baofeng GT-5R only work with the fixed tones at the end.

Lucky for me, my TYT MD-390 does work with the right reverse burst, and I was also able to get a large 23Wh battery that charged via USB-C. I used perhaps a third of that battery on race day, and was told I had clear transmissions. But I still had an issue where some transmissions were much louder than others, and I was fiddling with the volume potentiometer a lot of the time. I think what I really wanted was automatic gain control for the audio.

Maybe I should have just bought a Motorola?

Something I did notice was that pretty much every radio in use that wasn’t used by an Amateur, including those that the B.A.A. rented, and the one used by the segment coordinator were made by Motorola. Looking on eBay, the older MotoTRBO radios such as the XPR6550 can be found for pretty reasonable prices, some of them less than $100. I’ve never used Motorola radios before, but figured it would be worth a try for the next time around.

I’ve since bought some, but the process is kind of involved compared to any other radio I’ve had in the past. I talk about it over at Using Motorola TRBO Radios for Amateur Radio.

Using Motorola TRBO Radios for Amateur Radio

Tue, 02 May 2023 00:00:00 +0000

Introduction

Over in Using Amateur Radios for Public Service, I mentioned that I got some Motorola radios and programmed them, but that it was a bit of a task. I talk a bit more about why I picked the XPR6550 and what I had to do to program it.

Why the XPR6550?

It looks like the main options for handhelds are the XPR6550 and the XPR7550, at least for DMR. You can buy other Motorola radios that will happily do analog, but one of the benefits to buying a DMR radio vs say, an P25 radio, is that they typically cost less than the latter and there’s more ham adoption of them.

I opted for the XPR6550 over the XPR7550 because it takes standard antenna connectors and costs less online, particularly for a VHF Model. I went with the VHF model (AAH55JDH9LA1AN), because I have enough dedicated UHF radios, and I can use this model with some of the analog repeaters in my area.

Gotchas

Something to note about buying these inexpensively (mine was ~$100) on eBay is that most of the folks selling them are likely going to send you a radio that has not been factory reset, even if they have some basic validation of it. I think in part this is because the software is such a pain to obtain and you can’t factory reset it from the front panel. And this means that you’ll have to jump through some hoops if the codeplug cannot be downloaded to reset and change it because that is password protected. More on that below. I spent a bit of time writing this up because the information for this is strewn a number of places online.

They also probably will come with zero accessories, so if you’re getting started, you’ll probably want to order at least a programming cable, battery, and charging cradle. At the time of this writing, I went with the Aimtobest programming cable sold by “Aimtobest Radio Partner” on Amazon for around $29. For the battery, I got a cheap $23 one that stated it was compatibile with the radio, but doesn’t have any of the features that an official battery would have. I found a charging cradle on Aliexpress for around $10, and I can reuse antennas I already have for Baofeng radios.

Getting radio software and firmware

While Motorola used to charge for the software and firmware updates, they no longer do so for the TRBO line. This is nice if you’re buying one radio as an amateur radio operator, but because it’s Motorola, they don’t simply post it on their website, you have to jump through a bunch of hoops.

Quick Aside

If for some reason, you already happen to have “MOTOTRBO CPS 16.0 Build 828 (Standalone)”, you can open this sample codeplug and clone it over to your radio to get started: XPR6550 VHF Default Codeplug. There’s a sample codeplug that comes with CPS 16, but you’ll find that it is UHF and not compatible with the VHF version of the XPR6550. Conversely, if you have the UHF version of this radio, you should use the sample codeplug versus this one.

In a pinch, if you don’t have the 25 KHz entitlement, per this reddit comment, you can hex edit the sfccomb.dll file, and at memory address 0000200E, change the hex value of 06 to 17. This is equivalent to just having old firmware and an old CPS.

You should still jump through the hoops if you can, particularly if you ever end up with a newer radio and want to be able to easily get the software for it, or if you need to run recovery, because that requires the firmware. The firmware packages tend to be pretty big, so it’s less likely that you’ll find a friend that happens to have them.

The Hoops

If you’d prefer to watch a 37 minute video on how to do this (particularly if you’re new to codeplug programming), VA3HDL has a YouTube tutorial here.

Otherwise, you’ll want to follow the steps documented on Motorola’s website under the How to Download CPS Software for Astro and MOTOTRBO support article. (Yes, that URL 100% is going to break at some point)

Otherwise, here’s the steps in summary:

Sign up for a consumer account here.
Call the phone number on the website and explain that you’re an amateur radio operator and trying to get to convert it to a business account so that you can get programming software and firmware.
Wait up to 72 hours or possibly more
After you get a customer number, you can now access https://myview.motorolasolutions.com.
Go to Software, Subscribe, and then tick the box for “MOTOTRBO NA Professional Devices (Legacy)” to request firmware (it will take a while to show up)
See if you can get to https://shop-business.motorolasolutions.com. If not, you might have to wait another day.
Buy the part number of “HKVN4362A” to get the CPS Software (free).
(optional) Buy the wideband entitlement if you want to use it with amateur radio, part number “HKVN4046A”. ($5)
Wait a while for the orders to be fulfilled.
You can now download “MOTOTRBO Legacy XPR 6000 portable series Release R01.12.17” firmware and “MOTOTRBO CPS 16.0 Build 828 (Standalone)”.
You can also get the CPS 2.0 software, but my understanding is that you can’t use older software once you’ve programmed the radio with the newer one.

Now at this point, you should have everything you need to run a “recovery” from the CPS. Doing a recovery will reset it to factory settings. Note the warning message that says it might need to be retuned. It looks like Motorola has some other software that dealers have access to use called “Tuner”, but this isn’t something available to customers. So in theory you should find a (dealer) friend that has this software and save the tuning parameters before running a recovery.

Also note that if you did a “clone” and for some reason the radio still doesn’t want to transmit properly, you may end up having to still do the recovery anyway.

But now you can program your radio, just like any other radio that requires a codeplug. I’d recommend enabling “expert mode” if you’re using CPS 16 to see all the settings. CPS 2.0 seems to show all the settings by default.

Making Jitsi Meet work with TURN on Docker

Fri, 13 Jan 2023 00:00:00 +0000

If you’ve ever set up your own self-hosted instance of Jitsi Meet, you might find that some of the folks using it aren’t able to connect. The root issue for this tends to be because one or more people are behind NAT and despite using STUN to try to figure out their public addresses and do NAT traversal, there’s not a path to pass media between everyone.

So how do you get this magic on your own version of Jitsi Meet? After all, this doesn’t seem to be a problem on the instance at meet.jit.si.

Let’s start by setting up your own Coturn server. Coturn is an open-source implementation of STUN and TURN and it’s conveniently dockerized. While you probably do want to set it up with TLS, for the sake of just getting it started, you can run it with some configuration like this:

docker run --network=host coturn/coturn \
           -n --log-file=stdout \
           --min-port=49160 --max-port=49200 \
           --lt-cred-mech --fingerprint \
           --no-multicast-peers --no-cli \
           --no-tlsv1 --no-tlsv1_1 \
           --external-ip=192.0.2.1 \
           --static-auth-secret=changeme \
           --realm=meet.example.org

In the above example, a static auth secret of changeme is set up for use with Jitsi. The external IP (the example one where this server is running) is set to 192.0.2.1, though this can vary based upon the host. The coturn documentation does provide a way to get this dynamically by specifying it as '$(detect-external-ip)'.

Ideally you should have this on a host that allows you to have port 443 exposed over TLS, since this will work around most restrictive firewall rules as well versus just NAT (it’s using UDP port 3478 without TLS).

With this configured, you can set it up in Jitsi Meet. For the dockerized version, you’ll need this .env configuration:

# Specify Coturn for use in getting the external IP
JVB_STUN_SERVERS=meet.example.org:3478

# Use a turn server running locally
TURN_CREDENTIALS=changeme
TURN_HOST=meet.example.org
TURN_PORT=3478

# Specify the external IP
JVB_ADVERTISE_IPS=192.0.2.1

If you do set up coturn up with TLS, just note that all the above is the same, but replace TURN with TURNS, and the port to 443. This does mean you’ll need a reverse proxy to ship requests to the right hostname for a single IP address or multiple IP addresses.

And that’s it. Not all of this configuration and how to use it is well documented, so here’s how I got it to work.