Getting started with ham radio repeaters

Amateur radio is a fun way to mess around with technology, meet new people, and communicate off the grid. Talking directly to another radio on a single frequency (also called simplex) is the easiest way to get started. However, it can be difficult to communicate over longer distances without amplifiers, proper wiring, and antennas. This is where a radio repeater can help.

What’s in scope

This post is focused on fairly local communication on VHF/UHF bands. The most common frequencies for local communication in these bands are:

• 2 meters (~144-148MHz)*
• 70 centimeters (~420-450MHz)*

* NOTE: Always consult the band plan for your area to see which part of the frequency band you could and should use.

Of course, you can do some amazing things with weak signal VHF (which can be used to commuinicate over great distances), but we’re not talking about that here. The HAMSter Amateur Radio Group is a great place to get started with that.

We’re also not talking about radio bands longer than 2 meters (which includes high frequency (HF) bands). Some of those bands require advanced FCC licensing that takes additional studying and practice.

Keeping it simple(x)

Simplex radio involves communication where radios are tuned to a single frequency and only one radio can transmit at a time. This is like a simple walkie-talkie. If one person is transmitting, everyone else listens. If someone else tries to transmit at the same time, then the waves will be garbled and nobody will be able to hear either person. This is often called “doubling up”.

This method works well when radios are in range of each other without a bunch of objects in between. However, it’s difficult to talk via simplex over great distances or around big obstables, such as mountains or hills.

Repeaters

Repeaters are a little more complex to use, but they provide some great benefits. A repeater usually consists of one or two radios, one or two antennas, duplexers, and some other basic equipment. They receive a signel on one frequency and broadcast that same signal on another frequency. They often are mounted high on towers and this gives them a much better reach than antennas on your car or home.

I enjoy using a repeater here in San Antonio called KE5HBB. The repeater has this configuration:

• Downlink: 145.370
• Uplink: 144.770
• Offset: -0.6 MHz
• Uplink Tone: 114.8
• Downlink Tone: 114.8

Let’s make sense of this data:

• Downlink: This is the frequency that the repeater uses to transmit. In other words, when people talk on this repeater, this is the frequency you use to hear them.

• Uplink: The receiver listens on this frequency. If you want to talk to people who are listening to this repeater, you need to transmit on this frequency.

• Offset: This tells you how to calculate the uplink frequency if it is not shown. This repeater has a negative 0.6 offset, so we can calculate the uplink frequency if it was not provided:

145.370 - 0.600 = 144.770

• Uplink/Downlink Tones: Your radio must transmit this tone to open the squelch on the repeater (more on this in a moment). The repeater will use the same tone to transmit, so we can configure our radio to listen for that tone and only open our squelch when it is detected.

Opening the squelch

Transmitting radio waves uses a lot of power and it creates a lot of heat. There are parts of a radio that will wear out much more quickly if a radio is transmitting constantly. This is why receivers have a squelch. This means that a radio must transmit something strong enough on the frequency (or use a tone) to let the repeater know that it needs to repeat something.

You may come across repeaters with no tones listed (sometimes shown as PL). This means that you can just transmit on the uplin frequency and the repeater will repeat your signal. These repeaters are easy to use, but they can create problems.

Imagine if you’re traveling through an area and you’re using a frequency to talk to a friend in another car. As you’re driving, you move in range of a repeater that is listening on that frequeny. Suddenly your conversation is now being broadcasted through the repeater and everyone listening to that repeater must listen to you. This isn’t what you expected and it could be annoying to other listeners.

Also, in crowded urban areas, there’s always a chance that signals might end up on the repeater’s listening frequency unintentionally. That would cause the repeater to start transmitting and it would increase wear.

Two repeaters might be relatively close (or just out of range) and the tone helps each repeater identify its own valid radio traffic.

Tuning the tones

Most repeaters have a tone squelch. That means you can blast them with 100 watts of radio waves and they won’t repeat a thing until you transmit an inaudible tone at the beginning of your transmission.

As an example, in the case of KE5HBB, this tone is 114.8. You must configure a CTCSS tone on your radio so that the tone is transmitted as soon as you begin transmitting. That signals the repeater that it’s time to repeat. These signals aren’t audible to humans.

If you know you’re tuned to the right frequency to transmit (the uplink frequency), but the repeater won’t repeat your traffic, then you are most likely missing a tone. There’s also a chance that you programmed the uplink and downlink tones into your radio in reverse, so check that, too.

Repeater transmit tone

Some receivers will transmit a tone when they broadcast back to you, but some won’t. If you can transmit but you can’t hear anyone else when they talk, double check your radio’s settings for a tone squelch on the receiving side. Your radio can also listen for these tones and only open its squelch when it hears them.

I usually disable receiver squelch for tones on my radio since the repeater operator could disable that feature at any time and I wouldn’t be able to hear any transmissions since my radio would be waiting for the tone.

Testing a repeater

First off, please don’t test a repeater unless you have a proper amateur radio license in your jurisdiction. In the United States, that’s the FCC. Don’t skip this step.

Once you get your repeater’s frequencies programmed into your radio properly and you’ve double checked the settings for sending tones, you can try “breaking the squelch.”

Press the transmit button on your radio briefly for about half second and release. You should hear something when you do this. For some repeaters, you may hear a KERRRCHUNK noise. That’s the sound of the repeater squelch closing the transmission now that you’re done with your transmission. On other repeaters, you may hear some audible tones or beeps as soon as you release the transmit button.

Once you have it working properly, stop breakng the squelch and introduce yourself! For example, when I’m in my car, I might say: “W5WUT mobile and monitoring.” That lets people on the repeater know that I’m there and that I’m moving (so I might not be on for a very long time).

Good luck on the radio waves! 73’s from W5WUT.

Use a secret as an environment variable in OpenShift deployments

OpenShift deployments allow you to take a container image and run it within a cluster. You can easily add extra items to the deployment, such as environment variables or volumes.

The best practice for sensitive environment variables is to place them into a secret object rather than directly in the deployment configuration itself. Although this keeps the secret data out of the deployment, the environment variable is still exposed to the running application inside the container.

Creating a secret

Let’s start with a snippet of a deploymentConfig that has a sensitive environment variable in plain text:

spec:
    containers:
    - env:
        - name: MYAPP_SECRET_TOKEN
          value: vPWps5E7KO8KPlljaD3eXED3f6jmLsV5mQ
    image: "fedora:29"
    name: my_app

The first step is to create a secret object that contains our sensitive environment variable:

apiVersion: v1
kind: Secret
metadata:
  name: secret-token-for-my-app
stringData:
  SECRET_TOKEN: vPWps5E7KO8KPlljaD3eXED3f6jmLsV5mQ

Save this file as secret-token.yml and deploy it to OpenShift:

oc apply -f secret-token.yml

Query OpenShift to ensure the secret is ready to use:

$ oc get secret/secret-token-for-my-app
NAME                            TYPE      DATA      AGE
secret-token-for-my-app         Opaque    1         1h

Using the secret

We can adjust the deployment configuration to use this new secret:

spec:
    containers:
    - env:
      - name: MYAPP_SECRET_TOKEN
        valueFrom:
          secretKeyRef:
            key: SECRET_TOKEN
            name: secret-token-for-my-app
    image: "fedora:29"
    name: my_app

This configuration tells OpenShift to look inside the secret object called secret-token-for-my-app for a key matching SECRET_TOKEN. The value will be passed into the MYAPP_SECRET_TOKEN environment variable and it will be available to the application running in the container.

Security note: If someone has access to change the deployment configuration object, they could get access to the value of the secret without having direct access to the secret object itself. It would be trivial to change the startup command in the container to print all of the environment variables in the container (using the env command) and view them in the container logs.

Make alt-arrow keys work with terminator and weechat

As I make the move from the world of GNOME to i3, I found myself digging deeper into the terminator preferences to make it work more like gnome-terminal.

I kept running into an issue where I couldn’t move up and down between buffers using alt and arrow keys. My workaround was to call the buffer directly with alt-8 (for buffer #8) or alt-j 18 (buffer #18). However, that became tedious. Sometimes I just wanted to quickly hop up or down one or two buffers.

To fix this problem, right click anywhere inside the terminal and choose Preferences. Click on the Keybindings tab and look for go_up and go_down. These are almost always set to Alt-Up and Alt-Down by default. That’s the root of the problem: terminator is grabbing those keystrokes before they can make it down into weechat.

Unfortunately, it’s not possible to clear a keybinding within the preferences dialog. Close the window and open ~/.config/terminator/config in a terminal.

If you’re new to terminator, you might not have a [keybindings] section in your configuration file. If that’s the case, add the whole section below the [global_config] section. Otherwise, just ensure your [keybindings] section contains these lines:

[keybindings]
  go_down = None
  go_up = None

Close all of the terminator windows (on all of your workspaces). This is a critical step! Terminator only loads the config file when it is first started, not when additional terminals are opened.

Open a terminator terminal, start weechat, and test your alt-arrow keys! You should be moving up and down between buffers easily. If that doesn’t work, check your window manager’s settings to ensure that another application hasn’t stolen that keybinding from your terminals.

How to thrive at a technical conference

I’m at the 2018 Red Hat Summit this week in San Francisco and I am enjoying the interactions between developers, executives, vendors, and engineers. It’s my seventh Summit (but my first as a Red Hat employee!), but I regularly meet people who are attending their first technical conference.

The question inevitably comes up: “I’m so tired. How do you survive these events?”

One attendee asked me to write a blog post on my tips and tricks. This is the post that explains how to thrive, not just survive, at conferences. Beware - these tips are based on my experiences and your mileage may vary depending on your personality, the event itself, and your caffeine intake.

Discover the area

Traveling to a conference is awesome way to experience more of the world! Take time to enjoy the tourist sites but also find out where the locals like to go. Any hotel concierge should be able to give you advice on where to go to truly experience the location.

Take some time to learn the area around your hotel and the venue. Be sure you can navigate between the two and find some important spots nearby, like pharmacies and coffee shops.

Food, water, and sleep

These conferences can often feel overwhelming and you may find yourself forgetting to eat the right foods, stay hydrated, and get some rest.

Take every opportunity to eat healthier foods during the week that will give you energy without weighing you down. All the stuff that your Mom told you to eat is a good idea. My rule of thumb is to eat a heavy breakfast, a medium sized lunch, and then whatever I want for dinner. Evening events often have free food (more on those events next), and that fits my travel budget well. It also allows me to splurge a bit on foods that I might not eat back home.

Take along a water container when you travel. You can’t always depend on the conference for making water available and you’ll often need more than they offer anyway. I’m a big fan of Nalgene’s products since they take a beating and they have really good seals.

Sleeping is a real challenge. Early morning keynotes and late night events put a strain on anyone’s sleep schedule. Lots of people have trouble sleeping in hotels or in cities where the noise level remains high all night long. The best remedy is to be choosy about the events you attend and the time you spend there. Think about what is more valuable: more time listening to blasting music at a party or more time with your head on the pillow.

Consider using an application on your phone that provides various types of noises, such as white noise. I love the White Noise app on Android since it has tons of options for various sounds. In my experience, brown noise works best for sleeping. Pink noise can help in extremely noisy environments (like downtown San Francisco) but it’s often too loud for me.

Keep your devices charged

Find a way to keep your devices charged, especially your phone. I use Anker battery packs to keep my phone topped up during the day when I can’t get to a plug. A dead phone disconnects you from your friends, maps, and conference details.

Dress for success

Your clothing selection really depends on the type of conference and the company you represent. If you need to dress formally each day, then your choices are already made for you.

Pack layers of clothing so you can add or remove layers as needed. The walk to the conference center may be warm, but the keynote auditorium could feel like a freezer. This also prepares you for evening events which might be outdoors.

Wear clothing that makes you feel comfortable. You’ll find a wide range of outfits at most tech conferences and you’ll find that nobody really cares how formal or informal you are. If you’re there to listen, learn, and contribute, then dress casually. If you’re looking for a new job, doing a talk, or if you’ll be on camera, choose something a little more formal.

The hallway track

You won’t find the hallway track on any agenda, but it is often the most valuable part of any gathering. The hallway track encompasses those brief encounters you have with other people at the event. Turn those mundane events, such as waiting in line, eating lunch, or between talks, into opportunities to meet other people.

Yes, this does mean that you must do something to come out of your shell and start a conversation. This is still difficult for me. Here are some good ways to start a conversation with someone around you:

• “Hello, my name is Major” (put out your hand for a handshake)
• “Where do you work?”
• “What do you work on?”
• “Man, this line is really long.”
• “vim or emacs?” (just kidding)

The secret is to find something that makes you and the other person feel comfortable. There are situations where you might be met with a cold shoulder, and that’s okay. I’ve found that sometimes people need some space or the issue could be a language barrier. Making the attempt is what matters.

These are excellent opportunities for learning, for listening, and for sharing. These new contacts will show up again and again at the event (more on parties/networking next), and you can talk to them again when you feel the tendency to become a wallflower again.

Parties and networking events

Evening events at conferences are a great way to keep the hallway track going while taking some time to relax as well. Some of the best conversations I’ve had at conferences were during evening events or vendor parties. People are more candid since the conference demands are often reduced.

However, it’s incredibly easy to make some spectacularly bad decisions at these events. This list should help you navigate these events and get value from them:

Enjoy an open bar responsibly

Early in my career, I looked at an open bar as a magical oasis. Free drinks! As many as I want! This is heaven! (Narrator: It was not heaven. It was something else.)

I think about open bars much like I think about a trip to Las Vegas. Before I go, I think about how much money I feel like losing, and I only bet that much. Once the money is gone, I’m done.

Go into the event knowing how much or how little you want to consume. Zero is an entirely valid answer. Keep in mind that the answer to “Why aren’t you drinking anything?” does not have to be “I guess I’ll get something.” Nobody needs to know why you’re not drinking and you shouldn’t feel pressured to do something you don’t want to do.

Think about how you want to feel in the morning. Is a massive hangover worth another round of shots? Is it worth it to ruin your talk the next day? Is it worth it to get belligerent and say something that may be difficult to take back? Think about these things ahead of time and make a plan before you begin drinking.

Leave when you want

Some evening events can last much too late and this could derail your plans for the morning. If the party runs from 7-10PM, don’t feel obligated to stay until 10PM. If you’re not meeting the right people or if you’re not having a good time: leave. It’s better to abandon an event early than suffer through it and crawl through the next morning.

Turn down an uninteresting invitation

The conference may host various events or a vendor may invite you to an event. These are just invitations and your attendance is not required (unless you work for the vendor throwing the party). Feel free to do something else with your time if the event or the venue seem uninteresting or unsafe. (More on safety next.)

Get a party buddy

Remember those people you talked to in the hallway and during lunch? Find those people at the event and tell them you enjoyed the conversation from earlier. I’ve been to conferences before where I’ve been the only one from my company and after letting the other person know that, they invited me to hang out with them or their group at the event.

This is a good idea for two reasons. First, it gives you someone to talk to. More importantly, it helps you stay safe.

Dealing with harassment

This gets its own section. It has happened to me and it will likely happen to you.

Nobody ever wants it to happen, but people are often harassed in one way or another at these events. It’s inevitable: there are drinks, people are away from home, and they’re enjoying time away from work. For some people, this is a combination of factors that leads them to make bad choices at these events.

Harassment comes in many forms, but nobody should put up with it. If you see someone being treated badly, step in. If you’re being treated badly, get help. If you’re treating someone badly, apologize and remove yourself from the situation. This is where a party buddy can be extremely helpful.

Harassment is not a women-only or men-only problem. I have been touched in unwelcome ways and verbally harassed at evening events. It is not fun. In my experience, telling the other person to “Please stop” or “That is not okay” is usually enough to diffuse the situation.

This may not always work. Grab your buddy and get help from conference staffers or a security guard if a situation continues to escalate.

More ideas

These are some ideas that help me thrive at conferences and make the most of my time traveling. Feel free to leave some of your ideas below in the comments section!

Reaching the fork in the road

Walt Disney said it best:

We keep moving forward, opening new doors, and doing new things, because we’re curious and curiosity keeps leading us down new paths.

The world of technology is all about change. We tear down the old things that get in our way and we build new technology that takes us to new heights. Tearing down these old things can often be difficult and that forces us to make difficult choices.

Rackspace has been a great home for me for over 11 years. I’ve made the incredibly difficult choice to leave Rackspace on March 9th to pursue new challenges.

Humble beginnings

I came to Rackspace as an entry-level Linux administrator and was amazed by the culture generated by Rackers. The dedication to customers, technology, and quality was palpable from the first few minutes I spent with my team. Although I didn’t know it at the time, I had landed at the epicenter of a sink-or-swim technology learning experience. My team had some very demanding customers with complex infrastructures and it forced me to take plenty of notes (and hard knocks). My manager and teammates supported me through it all.

From there, I served in several different roles. I was a manager of technicians on a support team and had the opportunity to learn how to mentor. One of my favorite leaders said that “good managers know when to put their arm around to people and when to put a boot in their rear.” I reluctantly learned how to do both and I watched my people grow into senior engineers and great leaders.

Datapoint office closing in 2011

I was pulled to Mosso, Rackspace’s first cloud offering, shortly after that and discovered an entirely new world. Rackers force-fed me “Why’s (Poignant) Guide to Ruby” and I started building scripts and web front-ends for various services. Rackspace acquired Slicehost after that and I jumped at the chance to work as an operations engineer on the new infrastructure. That led to a lot of late nights diagnosing problems with Xen hypervisors and rails applications. I met some amazing people and began to realize that St. Louis has some pretty good barbecue (but Texas still has them beat).

Slicehost humor in 2009

Not long after that, I found myself managing an operations team that cared for Slicehost’s infrastructure and Rackspace’s growing Cloud Servers infrastructure. OpenStack appeared later and I jumped at the chance to do operations there. It was an extremely rough experience in the Diablo release, but it taught me a lot. My start with OpenStack involved fixing lots of broken Keystone tests that didn’t run on Python 2.6.

Working on OpenStack in 2012

If you’ve attended some of my talks on impostor syndrome, you may know what came next. We had a security issue and I sent some direct feedback to our CSO about how it was handled. I expected to be told to “pack a box” after that, but I was actually asked to lead a security architecture team in the corporate security group. It was definitely a surprise. I accepted and joined the team as Chief Security Architect. My coworkers called it “joining the dark side”, but I did my best to build bridges between security teams and the rest of the company.

Talking at Rackspace::Solve in 2015

This role really challenged me. I had never operated at the Director level before and our team had a ton of work to do. I found myself stumbling (and floundering) fairly often and I leaned on other leaders in the business for advice. This led me to take some courses on critical thinking, accounting, finance, and tough conversations. I’ve never had a role as difficult as this one.

Our cloud team came calling and asked me to come back and help with some critical projects in the public cloud. We worked on some awesome skunkworks projects that could really change the business. Although they didn’t get deployed in one piece, we found ways to take chunks of the work and optimize different areas of our work. An opportunity came up to bring public cloud experience to the private cloud team and I jumped on that one. I discovered the awesome OpenStack-Ansible project and a strong set of Rackers who were dedicated to bringing high-touch service to customers who wanted OpenStack in their own datacenter.

Impostor syndrome talk at the Boston OpenStack Summit in 2017

During this time, I had the opportunity to deliver several conference talks about OpenStack, Fedora, security, and Ansible. My favorite topic was impostor syndrome and I set out on a mission to help people understand it. My first big talk was at the Fedora Flock conference in Rochester in 2015. This led to deep conversations with technical people in conference hallways, evening events, and even airport terminals about how impostor syndrome affects them. I took those conversations and refined my message several times over.

Talking about impostor syndrome at Fedora Flock 2015 (Photo credit: Kushal Das)

Gratitude

I couldn’t even begin to name a list of Rackers who have helped me along the way. I wouldn’t be where I am now without the help of hundreds of Rackers. They’ve taught me how to build technology, how to navigate a business, and how to be a better human. They have made me who I am today and I’m eternally grateful. I’ve had an incredible amount of hugs this week at the office and I’ve tried my best not to get a face full of tears in the process.

I’d also like to thank all of the people who have allowed me to mentor them and teach them something along the way. One of the best ways to understand something is to teach it to someone else. I relish any opportunity to help someone avoid a mistake I made, or at least be able to throw something soft under them to catch their fall. These people put up with my thick Texas accent, my erratic whiteboard diagrams, and worse of all, my dad jokes.

Another big “thank you” goes out to all of the members of the open source communities who have mentored me and dealt with my patches.

The first big community I joined was the Fedora Linux community. I’ve been fortunate to serve on the board and participate in different working groups. Everyone has been helpful and accommodating, even when I pushed broken package builds. I plan to keep working in the community as long as they will have me!

The OpenStack community has been like family. Everyone - from developers to foundation leaders - has truly been a treat to work with over several years. My work on Rackspace’s public and private clouds has pushed me into various projects within the OpenStack ecosystem and I’ve found everyone to be responsive. OpenStack events are truly inspiring and it is incredible to see so many people from so many places who dedicate themselves to the software and the people that make cloud infrastructure work.

The next adventure

I plan to talk more on this later, but I will be working from home on some projects that are entirely different from what I’m working on now. That adventure starts on March 19th after a week of “funemployment.” I’m incredibly excited about the new opportunity and I’ll share more details when I can.

Top photo credit: Wikipedia