|
A long-term trend involves merging regional radio stations into larger broadcast networks where a significant portion of the programming is shared, while regional differentiation is achieved through temporary opt-outs from the central feed. Disappointment sometimes arises — particularly when listening in a car — because the receiver might retune to a frequency carrying completely different content at that moment, or conversely, fail to retune at all, forcing the user to do so manually. Both scenarios are obviously undesirable, yet both can be simply resolved.
As numerous questions and points of confusion regarding this topic persist even after many years, I am publishing the following summary of information.
1 Solution approach
1.1 Correct RDS PI – the foundation of everything
Program Identification (PI) is arguably the most important RDS function, even though the average user never hears about it and many receivers do not even display it. It consists of four hexadecimal digits.
It is transmitted at least 11 times per second, ensuring rapid availability. The program identification code holds no meaning for the average listener;
it serves only to enable the receiver to distinguish between individual programs
and is crucial when the receiver retunes.
The first digit of the PI code indicates the country where the transmitter is located.
The second digit of the PI code indicates the nature of the station and the region
for which the broadcast is intended:
| 0 |
local |
the program is broadcast on a single frequency only |
| 1 |
international |
the program is also broadcast in other countries |
| 2 |
national |
the program is broadcast nationwide within the given country |
| 3 |
supra-regional |
the program is broadcast across a large part of the territory |
| 4 to F |
regional |
the program is broadcast in only one region via one or more transmitters |
The last two digits of the PI code represent the program number, with 256
possible options (hexadecimal values 00–FF). Reception of different stations
with the same program number must not occur within the same area;
otherwise, receivers would identify the two stations as a single one.
The PI code is stored in the receiver's presets alongside the frequency. The assignment and
management of PI codes is typically the responsibility of the relevant national regulatory authority.
1.1.1 PI configuration in broadcast networks with regional programming
Stations
that split their broadcast network into separate regional variants for part of the day
must, first and foremost, distinguish these variants using
the second digit of the PI code, within the range of 4 to F (see Fig. 2). It is simply impossible
to proceed without this measure. Once this requirement is met,
all subsequent steps can be considered merely supplementary.
The differentiation described above can be static — meaning the relevant PI does not change throughout the day — or the PI can be switched dynamically based on the current program: during shared broadcasts, the second digit of the PI is set identically across the entire network to 1, 2, or 3 (depending on the station's nature), whereas during regional segments, each regional variant carries its own PI, with the second digit ranging from 4 to F.
Let us illustrate this with an example:

Fig. 1 – The entire network broadcasts the same program.

Fig. 2 – Temporary splitting of the network into individual regions.

Fig. 3 – Temporary separation of only a portion of the network for a regional segment.
It is worth noting that the aforementioned differentiation of regional channels is not linked to the geographical division of the territory but is based purely on the needs of each specific station. Ideally, when assigning PIs to individual stations, the national regulatory authority should not assign the second PI digit at all, as its assignment is determined by a standard that takes precedence over the discretion of an official, and a fixed assignment could conflict with that standard.
1.1.2 Receiver-side settings
Back when the RDS system was first being developed, a user setting for the receiver — specifically a "Regional Off/On" switch — was already envisaged. The purpose of this setting is to either allow or disable retuning between different regional variants. Surprisingly, this switch can still be found in some form on the latest receivers. Its function is simple: in the "Off" position, the receiver ignores the second digit of the PI code and will retune to a different regional variant; in the "On" position, the receiver strictly requires a completely identical PI code.
Since listeners are generally unaware of this function — despite its significant impact on the listening experience — it is well worth providing relevant information, for instance on the radio station's website.
Receivers that do not implement this switch usually operate in "Regional On" mode. Consequently, these receivers never retune to a different regional variant — not even when a shared program is being broadcast. And that brings us to the crux of the matter. This is why dynamically switching the PI code (see 1.1.1) is useful. It ensures that during the broadcast of a shared program, all receivers can retune to any transmitter, regardless of their settings or brand. There is a vast array of options for implementing automatic PI switching at the transmitter,
and explaining them is beyond the scope of this article.
1.2 Alternative Frequency Lists
Alternative Frequency (AF) lists transmitted via RDS inform the receiver
where to retune in the event of poor reception on the current frequency.
AF lists should be kept as short as possible — containing only those frequencies
to which the receiver can directly retune, given the network layout and propagation conditions.
Alternative frequencies can be transmitted using Method A or Method B.
Method A allows a single AF list to be transmitted from each transmitter. This
list may be shared by multiple transmitters, or a unique list may be created
for each transmitter. This usually depends on the signal distribution method;
generally, the number of lists in the network corresponds to the number of available RDS encoders.
The maximum number of alternative frequencies per list is 25 (though
this limit may be lower for some old RDS encoders).
AF encoding using Method A is simple: the first byte indicates the number of frequencies in the list, and each subsequent byte represents a single frequency (channel number). The order of the frequencies is not fixed.
Method B is used when
- there are more than 25 alternative frequencies available for tuning to a
given transmitter (including any repeaters)
- or when there is a requirement to distinguish alternative frequencies based on
regional affiliation — which is the case we are concerned with here.
When entering frequencies using Method B, the following differences from Method
A apply:
- Each transmitter can transmit more than one AF list.
- Additionally, each list is preceded by the frequency (Tuning Frequency) to which
that list applies.
- The maximum number of AFs in each list is 12. If a larger number of AFs is
required, a new list is used, following immediately after.
- If a Tuning Frequency is used multiple times within the network, a separate
list is created for each instance. These lists must be separated by another list.
- For each AF, it is possible to define whether it belongs to the current (same)
region or to other program variants.
AF encoding for Method B is similar to that of Method A; however, the first frequency in the list is the Tuning Frequency, followed by pairs of bytes (F1 and F2), where each pair consists of the Tuning Frequency and one AF from the list. The byte order within the pair follows a specific rule:
- F1 < F2: the alternative frequency always relates to the same region
- F1 > F2: the alternative frequency may relate to other program variants
1.2.1 AF settings in broadcast networks with regional splits
For
stations that split their broadcast network into separate regional variants for part of the day, it is recommended to transmit AFs using Method B across all transmitters.
The advantage of this method over the more commonly used Method A is that
individual alternative frequencies can be categorized into two groups: frequencies
belonging to the current regional variant (which maintain an identical PI code at all times)
and frequencies belonging to other program variants (where the PI code differs—temporarily
or permanently — in the second digit). This approach enables faster retuning to the correct
alternative frequency, particularly in larger networks.
However, I see no reason why Method A could not work just as well for smaller networks,
since the PI — rather than the AF list — is ultimately the decisive factor for retuning.
This claim can easily be illustrated by a theoretical scenario in which two
transmitters share the same frequency but belong to different
regional variants. In this case, the advantage of Method B regarding references to these transmitters
disappears entirely; only by checking the PI can the receiver determine which regional
variant it is actually attempting to tune into.
In any case, AF lists are always static; there are no
changes to the AF lists based on the current program.
2 Flawed solutions
To illustrate the point, let us look at some incorrect approaches — that is, how not to do things.
All the following cases are drawn from real-world practice.
2.1 Mistake 1 – Not addressing the issue at all
Unfortunately, this is often the most common way of dealing with the
issue of retuning. The entire network permanently uses a single PI code.
Only after some time — and a barrage of complaints — does the operator
decide to look for a solution. Fortunately, it is never too late.
There is, however, one case where "doing nothing" makes sense. It is
the situation we already touched upon: if it is technically impossible to
switch the second digit of the PI code, yet we want to ensure that retuning
works reliably on every receiver across the entire network during the
broadcast of the central program. In that case, there is truly no other
option but to leave it as is and accept haphazard retuning during
regional opt-outs. However, this is an approach that should be rare
and only makes sense in isolated situations.
2.2 Mistake 2 – Changing the last two digits of the PI code
The broadcaster based their solution on
the (correct!) observation that no receiver will retune between
transmitters that have different last two digits in their PI code. To prevent unwanted retuning during regional broadcasts, the operator temporarily changed the last two digits of the PI code on part of their network. However, the result was the exact opposite of the intended effect — or even made listening impossible.
What is the problem? A receiver can interpret a change in the last two digits of the PI code for the currently tuned station in only one way: it assumes it has moved outside the coverage area of the original broadcast. How the receiver behaves next depends on the specific model and settings, but it will always attempt to find another transmitter broadcasting the original PI code (the one used before the change).
Broadcasters are usually not even authorized to make changes of this type. Changing the PI code in this manner is arguably the worst thing one can do to a listener. The station can no longer even be selected from the receiver's presets, as the device will keep trying to locate the original PI code. The only solution is to consistently set the permanent PI code before the transmitter goes live and to avoid experiments of this kind altogether.
2.3 Mistake 3 – Broadcasting a different set of AF frequencies
This error is a milder (non-destructive) variation of the previous one. It is based on the assumption that if a different (limited) set of alternative frequencies is broadcast temporarily during regional segments, unwanted retuning will be avoided. The assumption is flawed; ultimately, retuning
occurs regardless.
Why is this the case? As previously established, the PI code — not the AF list —
is the deciding factor in whether and where to retune. This may come as a surprise
to many, but it is a fact. The only real purpose of AF is to speed up the
retuning process. A receiver can retune to a frequency that is not even listed
in the AF list, and this behavior does not conflict with any standards. In an
extreme case, the receiver can retune even if no AF list is being broadcast
or if the list cannot be retrieved due to poor reception conditions. Restricting
the broadcast AF list usually does not even cause the original AF list to be
cleared from the receiver's memory. Therefore, a solution based on this
assumption is ineffective. There is no point in dynamically changing the
broadcast AF lists.
3 AF configuration example
Here is an example of configuring AF using Method B in the Magic RDS 4 control software:

For each RDS encoder, AF settings are accessible via RDS Content - Alternative Frequencies. Select Method B from the drop-down list.
An overview of all entered AF lists follows. Selecting a list allows you to edit it in the lower section. Create a new list by clicking the New List button.
Tuning Frequency (TF) is the frequency for which the list is being created — i.e.,
the frequency from which the receiver will tune away.
Same Programme AF - select alternative frequencies belonging
to the same region as the TF.
Regional Variant AF - select alternative frequencies that may
broadcast a different program during part of the day.
After finishing the list edit, click the Update List button. Finally, use the Test and Apply buttons to send the data to the encoder and save it permanently to memory.
4 Diagnostics
To verify the transmitted AFs, you can use the RDS Spy program:

The PI code is displayed directly in the program's main window.
Alternative frequencies are accessible in the Basic RDS Decoder plugin (included in the standard installation) on the AF tab. When transmitting using AF Method B, the specific frequency pairs for each list are displayed on the right, in accordance with Section 1.2. The letters (RV) designate alternative frequencies that may carry a different program during part of the day.
In conclusion, I would add that no receiver is entirely free of flaws, and there is always a certain degree of latitude in the development of a receiver's internal software — the RDS standard is far from covering every possible situation that might arise during reception. Consequently, under certain circumstances, some receivers may behave in a slightly unpredictable manner or in a way that deviates from the described behavior.
Author: Ing. Jan Kolar
|