Proper Repeater System Etiquette as Relates to Simplex Nodes

NR9V · March 13, 2026, 11:42pm

I’ve been a long-time advocate of full-duplex nodes, and more specifically cross-band full-duplex nodes, for a variety of reasons described here. There are subtle details about full-duplex that are overlooked by most, or entirely misunderstood outside the case of the use case of a repeater itself - with the resulting frequent misconception that a full-duplex node is a repeater which is not at all a valid assumption.

AllStarLink is used primarily for linking to repeater systems. This is useful because it allows you to talk on repeaters that you are not close enough to access directly via RF. Repeater systems have a long history, and are usually well-designed professional-grade systems that operate in a consistent way and are very easy to use. If you had an HT in the 1980’s and used to talk on repeaters then, you can turn on that same HT today and use it exactly the same way you did 40 years ago.

There are many websites that talk about how repeaters work and Repeater System Etiquette. AllStar users should of course be familiar with these concepts, but in reality I think a lot of new users don’t really understand all the subtle details of how AllStar links a repeater through the internet to a personal node, and how that can affect communications on the repeater.

What I would define as a “properly designed node” provides a transparent interface to whatever system you connect to, such that if you for example connect to a repeater system in Chicago, you can then talk on that repeater system from an HT in your back yard no differently than if you were at the top of the Sears Tower. Audio from the repeater coming though your node will sound exactly like it does to the repeater’s local RF users, and those users will not be able to tell any difference between your audio and the audio of other local RF users.

https://www.n3kz.com/repeater-etiquette-guide has a good summary of repeater etiquette. Quoting one specific section:

Most repeaters have a courtesy tone which sounds between user's transmissions. During the normal course of communications on a repeater, each time a user unkeys (stops transmitting), several sequential events occur First, there is a period of time, typically on the order of one second, during which the repeater transmits silence. This is referred to as the courtesy tone delay. After the courtesy tone delay, the courtesy tone is sent out the repeater transmitter. The courtesy tone serves several purposes. First, it notifies all listening stations that the previous station has finished making a transmission, and that the next station to transmit should proceed. Second, it provides an opportunity for a station not currently participating in the discussion to break in, either to join the conversation or to make a call. Finally, once the courtesy tone sounds, the time-out timer is reset. It is imperative that when a user unkeys that the next station to transmit waits for the courtesy tone before making the next transmission, otherwise others will not have an opportunity to break in, and the time-out timer will not be reset. Not waiting for the courtesy tone to sound before transmitting is referred to as "quick keying"; it is poor operating practice, and typically a violation of the rules of the repeater.

After the courtesy tone sounds, unless another station transmits, there is again a period of silence, typically on the order of several seconds, before the repeater transmitter unkeys or "drops". This is referred to as the "hang time". During the hang time is when the next station to transmit should begin his or her transmission. The purpose of the hang time is to prevent the repeater transmitter from unkeying and rekeying repeatedly during the course of a conversation. Each time the repeater transmitter keys and unkeys there is additional wear and tear on electromechanical devices such as relays and cooling fans, additional stress to components due to thermal cycling and inrush current, delays that result in the start of the next transmission potentially being "cut off" due to the time it takes for the squelch to open, PL decoder to recognize the signal, and in the case of linked repeater systems, for all of the repeater transmitters to also come back up, etc.. Purposefully waiting until the repeater transmitter drops out before making a transmission defeats the purpose of the hang time and is extremely poor practice.

A repeater linking application has a certain set of features that must be present if that product can in fact act as a transparent link. This base feature set is easy to define.

Half-duplex nodes often fail to meet these requirements as they cannot be keyed up until after the Tx carrier drops. This can be mitigated somewhat if everything is set up properly with tone squelch and hang times on the repeater and on the node, but I have seen many repeaters that don’t have that set up optimally, other issues with SA818 types of nodes can make things worse, and these details aren’t mentioned anywhere that most new users are going to notice it. Repeaters have courtesy tones and hang times in part so that the carrier doesn't need to drop and thus conversations and nets can proceed smoothly without squelch crashes after every unkey. This has worked very well for a long time, and it would be irresponsible to promote products or apps that fail to support these features and require other repeater users to change how they do things to accommodate those limitations.

Anyone can make a node out of a $15 RPi and a SA818 and use it on AllStar-linked repeater systems, but good etiquette should require that you’ve checked the audio quality and confirmed it doesn’t have the whines and buzzes typical of many nodes and that the hang times etc. are properly set up on both sides. It is important within ham radio to ensure that we are always fully respectful and fully supportive of the work that others have done before us, and to educate others on how they can best use AllStar in such a way that they will be maintaining the standards of the repeater systems they connect to. Thanks & 73, NR9V

W0QG · March 14, 2026, 3:21pm

Wow I was not aware about the “hang time” feature and I’ve just been waiting for the repeater to drop before transmitting. Will give that repeater etiquette link a read to see what else I’ve been doing wrong

csylvain · March 14, 2026, 3:47pm

letting the repeater drop isn't always "bad", isn't it?

in my 50-some years of listening to repeater users, there is the "getting another nickel" (allow the timeout timer (TOT) to reset) in order to complete the thought/transmission without the TOT cutting the speaker off mid-sentence

or have i missed something?

ps: Raspberry Pi prices start at about 50 USD for the most useful models lately

N8EI · March 14, 2026, 4:30pm

I would put that recommendation on when to key up firmly in the realm of "ham lore" that isn't necessarily based on real technical aspects of modern systems. There are a variety of hardware and software reasons why keying up before a unkey may or may not reset any timeout timers. Many systems count when "transmit stops" differently. And when you link them together, the problem only compounds itself. It's always wise to leave a gap between transmissions. Not only does it prevent timing out parts of an ad-hoc system, it's also courteous in case someone else wants to break into a conversation, emergency or otherwise.

csylvain · March 14, 2026, 5:34pm

MIND THE GAP

excellent advice. can't tell you how many times in the last couple of years there were opportunities for someone monitoring (like me) to add to a back-and-forth or even a roundtable, but the operators were so quick on the PTT there was no room for it at all.

Don't treat linked systems like your local repeater - take it slooow

NR9V · March 14, 2026, 9:33pm

To add a little more detail, repeaters can go through the following states after each repeated transmission:

Repeated Transmission (ie. user audio that was received on local RF, from ASL, or from other linked systems / networks)
Courtesy Tone Delay. A short (~1 second) period of silence allowing for breaks or quick comments.
Courtesy Tone. Indicates the last Tx is complete and it’s OK to key up after the tone. Whether you then want to wait 1/2 a second or a couple seconds to key up is up to you and depends on the particular context.
Hang Time. This keeps the repeater keyed for anywhere from 2 or 3 seconds or sometimes significantly longer depending on the repeater admins’ preferences. There is an RF-linked system here in the SoCal and West AZ deserts area that has something like a 30 second hang time. Presumably they really don’t like to hear squelch crashes or maybe it’s because it prevents the delays associated with the various RF links turning on and off. It does work very nicely - not only are squelch crashes almost never heard but it gives people plenty of time to key up with zero perceived rush to need to key up within only a few seconds before the carrier drop, which gives the system a sort of relaxed, down-to-Earth vibe if that can be said of a repeater system.
IDs or other system announcements may be played during or after the hang time.
Carrier Drop

I’m not an expert on a wide variety of repeater systems, but from what I know, in a repeater system that is properly linked to AllStar, generally only repeated local RF audio is sent out to AllStar. None of the audio or delays associated with (2.) - (5.) above will be sent to AllStar and you will not hear or see any of that. Not all systems are set up that way however. Some repeaters have very constrained sites eg. they get free space at a repeater site that is run by a municipality but they cannot bring their own internet service or put up additional antennas for an RF link. Thus they may use in-band linking in which case one or more of the other (2.) - (5.) may be propagated to AllStar.

There is thus no clear way to know what a repeater system’s timing is for these states and it may not always be clear on your node when it’s keyed up if hang time is from the repeater itself or from your node. As you use various systems you will get a feel for what kind of delays people use before keying up and naturally over time you’ll adapt to that, no differently than on a local RF repeater.

If you have a half-duplex node and notice sometimes that you’re not able to key up certain systems at certain times ie. if other people aren’t waiting long enough before keying up, keep in mind that is not necessarily a limitation of AllStar. If you have a full-duplex node you will most likely have much better luck getting in, because your ability to key up your node is then no longer dependent on any hang time and Tx/Rx switching delays associated with your own node.

Ideally, for AllStar to provide a truly transparent interface to a repeater system, all the repeated local RF audio and delays. courtesy tone, hang time, IDs and announcements would be propagated to other connected nodes, and those other nodes would then not need to implement their own courtesy tone and hang times. If everyone had full-duplex nodes then this would be easy to do and would work perfectly ie. there would be no difference in what you hear through your node vs. what the repeater is transmitting on RF. But to accommodate simplex nodes it’s better to not propagate any delays to AllStar, which should enable simplex nodes to drop their carrier and to then be keyed up. There is then however a disconnect between how a repeater handles its timing in the above steps which you then have no visibility of. It’s generally not an issue, as we will generally pick up on the timing just from listening to how other users do things on a particular system over time, but it does require some awareness of these details and some extra attention to these timing details.

In a modern software implementation this state information would be explicit, ie. a repeater system would forward IAX metadata to connected nodes as each state change occurs. The node could then optimally handle that information based on its own configuration. If it was configured in half-duplex it could drop carrier right away, thereby giving you a better chance of being able to key up the system or break in or make a quick comment before the courtesy tone. Or if configured in full-duplex it could then propagate the remote system’s delays, courtesy tone, IDs and announcements, thereby providing a fully transparent link with zero ambiguity.

Software generally starts out with imperfections, approximations and various tradeoffs to accommodate various system limitations, but over time evolves to be more transparent ie. able to quantify and optimally handle the potentially different states, timing, and events that can occur. I have no doubt that AllStar and ASL will continue to evolve in these regards, and at the same time full-duplex nodes are becoming more widely used and more cost-effective. Cell phones for example have been full-duplex since Day 1, which enables a wide variety of real-time optimizations to how signals are routed between cells, how Tx power levels and battery efficiency are optimized, how data is transferred and acknowledged in real-time, and these things together result in things being much more efficient, reliable and user-friendly than if they had tried to use half-duplex RF links. These sorts of approaches have similar benefits in ham radio and ultimately ham radio is about innovation and experimentation. Stay tuned for more on that…