Eliminating the need for repeater analog MCWID on NXDN?
Overview: To comply with FCC regulations, Part 97.119, all amateur repeaters need to identify themselves. In
a nutshell, the rules state that they must identify at least every 10 minutes during a QSO, and within 10
minutes after the last transmission. Kenwood and Icom repeaters switch to analog (FM) mode for the
duration of the ID when their internal MCW ID is activated. When that occurs, the repeater spends a lot of
precious time sending the ID in a mode that’s not being used in the QSO.
But more importantly, the analog ID, when running, ‘steals’ the repeater’s use from digital users. The real
crucial part here to that happening is that the users don’t usually know that’s happening, and many times talk
while the ID is being transmitted unless they are using busy channel lockout (BCL). This is a more prevalent
issue on the network as each repeater’s internal timer is not synchronized with the others on the network. If a
user continues to talk during and after the ID, the repeater will not revert to its digital state until the ID is done
AND there is no receive signal on the input. This scenario can randomly create dropped sections of QSO’s.
Depending on your hardware and configuration, there are a couple of ways of mitigating the need for using
analog ID. Take a look at both and choose which on fits your particular configuration best.
Courtesy N1XDN Aug 2015
For a Kenwood repeater, in which the repeater owner does not wish to use external circuitry, and for which
there is a KTI-3 connected, the following procedure will generate an Over The Air Alias (OTAA). A Raspberry Pi
would be the best way to send the ID, although any computer capable of running Python scripts should work,
providing that the IP address is listed in the conventional IP table.
What to do: Log into the Raspberry Pi with SSH. Type the following command:
wget https://raw.githubusercontent.com/rthoelen/NXDNtools/master/Kenwood%20ID%20Script/id.py
This will download the latest version of the python script that generates the ID. You must edit the area
labeled “Things to edit” with a text editor on the Pi. At a minimum, you must edit the line starting with R_IP
and change the IP address to the IP address of the Kenwood repeater. You also must edit the line starting
with P_IP with the address of the Raspberry Pi. Also edit the line starting with MESSAGE. The string in the
quotes on that line must have 14 characters in between the quotes. If you do not need 14 characters, just
append spaces until you have the required 14 characters.
Let’s assume your PI is at 10.0.1.100, and your Kenwood repeater is 10.0.1.101. You also want to send out
your call and a /R. Here is what that section might look like:
#################
# Things to edit
# Repeater IP
R_IP = "10.0.1.101"
# Pi IP
P_IP = "10.0.1.100"
RAN = 1
GID = 0
UID = 929
# To keep things simple, message must be 14 characters long
# If shorter than 14 chars, add spaces to get to 14
MESSAGE = "N1XDN/R
################
"
The UID is not really important, but if you have assigned your repeater a UID, use that. After editing the file,
save and then you are ready to run the program. Type:
python id.py
at the command prompt on the Raspberry Pi. You should see the repeater key up, and transmit the OTAA
message to the handheld or mobile radio.
The advantage of this approach is that the time to ID is significantly reduced. One observation is that if there
is audio on the repeater, it might get broken up a bit when the ID comes through. A future enhancement to
the script might be to monitor the UDP packet stream from the repeater, and only if there is no traffic, then
send the ID.
To automate the ID:
Become the root user or use sudo, and edit the crontab. For instance:
sudo crontab –e
At the bottom of the crontab file, insert the following line:
*/8 * * * * /usr/bin/python /home/pi/python/id.py
(but change the path “/home/pi/python/id.py” to where the script is actually located)
Questions and observations on this script can be sent to rthoelen at gmail dot com.
Courtesy K1IFF Apr 2015
Another proposed ‘fix’:
For Kenwood repeaters, utilize one of NEXEDGE’s features – Over The Air Alias (OTAA). OTAA is built into the
NXR-series repeaters and other NEXEDGE radios. When programmed properly, simply keying the repeater via
its external PTT (E PTT) line with an external timer will transmit the repeater’s “own UID” along with its
corresponding OTAA.
What to do: Disable the internal MCWID functionality altogether, and assign the repeater an OTAA with its
callsign, and key the repeater’s external PTT line with an appropriate timer that meets FCC ID timing
requirements. Details on exactly how to do this are in the pages following this text.
I have found that N0XAS’s $39 programmable works well for this application, although it may be WAY overkill
for this particular issue. It also can also be used to feed the TA (Transmit Audio) input of the NXR repeater
with voice, MCW, etc. if needed or desired in lieu of or in addition to using the OTAA.
Set the ID-O-Matic up in “beacon” mode. You will only need to use the PTT output from the ID-O-Matic. Set
the beacon interval at 600 seconds (10 minutes). I set the identifier to transmit the letter “T” at about 10
wpm. That is about 100 msec and long enough to encode the UID with the OTAA (the UID by itself is not a
legal ID for US hams. A Kenwood NXDN radio, when set up properly, will decode the repeater’s own UID AND
the OTAA.
How to do it:
1. Turn off /disable the MCW ID on the repeater on all channels that you use on the repeater. You won’t need it.
2. Make sure that your repeater’s channel(s) are set to TX on NXDN. This will ensure that either a local mic or
external PTT will key the repeater in digital mode, which will be needed to convey the OTAA.
3. Set the PTT priority to have E PTT at the top. Doing this will allow your ID to take priority over EVERYTHING –
but it only does so for ~100 msec, which should not be a major imposition on any conversation(s).And because
the E PTT line has nothing to do with the receiver, the mode that’s being used – analog or digital, at the time the
timer keys the E PTT line - will not be affected or changed.[Note: Obviously, if you’re sending data, 100 msec can be
devastating so just be aware of that. If needed and you’re using the ID-O-Matic, you can set it up in a more complex
configuration to become a “polite” ID instead of using it in the beacon mode.]
4. Turn on OTAA for the repeater, and put the repeater’s callsign in the OTTA text box. In my example below, the
‘Brstl’ is the location of the repeater (Bristol, CT) – the /R is repeater, to differentiate this call from my personal
call.
5. Connect the external timer to the Control I/ODB25 connector, pin 16 (E PTT). Grounding this pin (or using
an open collector transistor output to it), will key the repeater. If you’re using the E PTT function for
something else (which I do), be sure to install blocking diodes.
Why not use the Site Roaming and Beacon mode built into the NXR-series repeaters?. Although that
functionality’s timing would fit hams’ needs and would likely work very well, the repeater doesn’t transmit
the UID and/or the OTAA as part of Site Roaming. It only transmits a digital carrier, with no other data only used to allow a receiver to determine relative signal strength for site voting purposes.
For Icom repeaters, which do not support OTAA at this time, a similar fix using an external ID timer can be
used. That external timer would feed MCW (or voice) audio into the external audio input of the repeater.
However, you will not reduce the amount of time for the identifier as this fix would shift the MCW ID to the
digital side instead of the analog side.
Both fixes would eliminate the need for the internal analog identifier, and rely on external means, giving the
ability to move the repeater into a full digital mode. With my Kenwood repeaters, I am using the ID-O-matic
kit (N0XAS). It provides a very robust set of features that meet both Kenwood and Icom repeaters.
Is it legal?: Don’t know for sure, but this is my attempt to both comply with the ID requirements, at the very
least in spirit, and eliminate the need to consume time and spectrum. Dstar (and I suspect Fusion digital) use
this sort of method and this is an attempt to do the same without the use of MCW in FM mode. The
repeater’s ID using OTAA, again, needs a Kenwood radio that will decode the OTAA - just like one would need
to see a Dstar repeater’s ID using a Dstar radio. But this functionality is to comply with FCC requirements, not
necessarily allow users to see what repeater they’re hearing. On the NXREF network, this is a non-issue, and
users on the network will not see any repeater’s ID over the network.
Questions, issues, feel free to contact me. My call at snet dot net April 2015