RTCM Client
Introduction
The Radio Thin Client Module (RTCM) is commercially available hardware for interfacing radios to an AllStarLink computer.
The Micro-Node RTCM (and VOTER) interfaces are typically used with AllStar in voting/simulcast applications. They MAY be used for ANY repeater interface application, through the chan_voter channel driver, as they are primarily a Radio over IP (ROIP) adapter.
The VOTER is the original through-hole board designed by Jim Dixon (SK) for this application. It is open-source, and the relevant Gerber files and BoM to build it are available.
The Micro-Node Radio Thin Client Module (RTCM) is the commercial version of the VOTER. It uses surface mount parts (SMT), but is functionally equivalent to the original VOTER. In general, the two terms (RTCM/VOTER) are used interchangeably, as they operate the same, and use the same firmware (mostly, see below).
Firmware
See the firmware upgrade page for information on upgrading the firmware.
Board Layout
Connectors and Switches
J1 - ICSP Programming Header P1 - Radio P2 - Console/GPS SW1 - Reset (Momentary) SW2-1 - Init EEPROM SW2-2 - Calibrate Squelch SW2-3 - Calibrate Diode SW2-4 - RX Level LEDs
J1 - ICSP Programming Header (6 pin MTA-100)
1 - MCLR 2 - +3.3Vdc 3 - GND 4 - PGD (Program Data) 5 - PGC (Program Clock) 6 – NU
P1 - Radio Connector Pinout (DB9 Male)
1 - + VIn (7-24 Volts DC). 2 - Transmit Audio Out 3 - Receive (discriminator) Audio In 4 - External CTCSS Input (optional) 5 - Gnd 6 - Gnd 7 - /PTT Out (open-collector, active-low) 8 - Gnd 9 – Gnd
P2 - Console/GPS Connector Pinout (DB15 Female)
1 - NC 2 - Console Transmit Data 3 - Console Receive Data 4 - NC 5 - Gnd 6 - GPS Receive Data 7 - PTT Out 8 - Gnd 9 - NC 10 - Console Request To Send (RTS) 11 - Console Clear To Send (CTS) 12 - NC 13 - GPS Power Output (5Vdc @ 800ma MAX) 14 - GPS Transmit Data 15 – External Reset
SW1 - Reset
Depress SW1 momentarily to reset the RTCM.
SW2 - DIP Switch
SW2-1 - Init EEPROM SW2-2 - Calibrate Squelch SW2-3 - Calibrate Diode SW2-4 - RX Level LEDs
SW2-1 "Initialize configuration parameters in EEPROM" (factory reset). If ON when firmware starts, the operating parameters in the EEPROM will be set to default values. The system activity LED (LD1, green) will stay off for aproximately 4 seconds, then stay on steady to indicate that the initialization process is complete. Afterwards, the switch may be TURNED OFF and the system will continue running normally. Note, if SW2-3 is ON during this procedure, the “Diode Calibration” process will also occur.
SW2-2 On to calibrate squelch. With the receiver connected and its antenna removed, switch on SW2-2. In the next few seconds the "Receive Signal Indicator" (LD3, Green) will flash on and off, then (hopefully) on steady. This indicates that the squelch calibration has occurred successfully. If unsuccessful, the LED will flash either fast to indicate that the discriminator noise level is too high, or slowly to indicate that the discriminator noise level is too low. Note, if SW2-3 is ON during this procedure, the "Diode Calibration" process will also occur.
SW2-3 On to perform "Diode Calibration". This may only be done in conjunction with a configuration parameter initialization (see SW2-1, above), or a "Squelch Calibration" (see SW2-2, above).
SW2-4 On to temporarily re-purpose LD4 and LD5 to allow for visual indication of RX input level. With SW2-4 on, LD5 will indicate (by brightness) if the RX level is too low, and LD4 will indicate (by brightness) if the RX level is too high. So the idea is to tune R36 so that there is minimal brightness on both LD4 and LD5 (like a null, more or less). Alternatively, Menu 97 on the console gives a more graphical method of setting the Rx input level.
LED Designations
LD1 - Heartbeat LD2 - PTT LD3 - COS On solid is valid Rx signal, flashing is without CTCSS LD4 - GPS On solid is GPS received and locked, flashing is GPS received, lock in progress LD5 - HOST
Jumpers
JP1 - Discriminator Level Boost JP2 - 20dB Pad JP3 - Output Amp Power Source JP4 - GPS TX RS-232/TTL Select JP5 - GPS RX RS-232/TTL Select JP6 - Not Used JP7 - Bootloader Programming
JP1 - Discriminator Level Boost
Insert if low discriminator level. If squelch cannot self-calibrate with JP1 removed (too low), try with JP1 inserted.
Note: this jumper affects the squelch calibration circuit only. Not to be confused with JP2, which is the pad for the receive audio.
JP2 - 20dB Pad
Insert to attenuate discriminator input level by 20db. This pad affects the receive audio level. See the Receive Level Input Calibration section.
JP3 - Output Amp Power Source
Selects power source for output audio amplifier. 1-2 is to power it from the 5VDC power supply. 2-3 is to power it directly from Vin.
JP4 - GPS TX RS-232/TTL Select
Selects GPS Serial transmit level. 1-2 RS232 Level, 2-3 TTL (5V) Level.
JP5 - GPS RX RS-232/TTL Select
Selects GPS Serial receive level. 1-2 RS232 Level, 2-3 TTL (5V) Level.
JP6 – Not used
JP7 - Bootloader Programming
This jumper only needs to be removed when programming the bootloader in the dsPIC using the ICSP header.
Potentiometers
R22 - Squelch adjustment R36 - Rx Input Level R10 - Tx Output Level
Motorola Quantar
Some things to consider:
- Install JP1 on the Quantar's RTCM. The squelch should calibrate at around 4 blinks rather than the 12 blinks or so without JP1.
- Be sure you've done the diode and squelch calibration with the actual attached radio (no antenna).
- The Quantar firmware should be 20.14.48 as later versions have better noise output.
- Try the "Chuck Squelch" RTCM version.
- Each RTCM should have 3 to 5 turns past threshold to prevent the squelch form being too loose. Somewhere around the 350 level seems about right. Chuck Squelch seems to need fewer turns but YMMV.
- Don't "and" CTCSS with squelch. That may override the RTCM's squelch detection. Compare with CTCSS on and off to see effect if any.
Also check the Quantar RTCM page for detailed interfacing and configuration information.
RTCM/VOTER LED's
RX LED on the RTCM/VOTER will flash (same rate as ACT LED) if you have External CTCSS enabled, and the received signal has the wrong (or no) valid PL.
Network Information
RTCM/VOTER Bandwidth
Assuming ulaw... The RTCM will require approximately 80kbps of bandwidth for continual usage.
Network Quality
Your IP Network quality is important. You may wish to add a rule in your routers to prioritize traffic on UDP port 667 so that RTCM audio is given priority over other traffic. Also see the #Debug Options below for notes on how to tag your packets with ToS.
RX/TX Buffers are NOT Both Millisecond Values
You might assume an RX buffer (in voter.conf) of 120ms would be equivalent of a TX buffer (in the RTCM) of 120ms. That is not the case.
The TX buffer is a number of 125 microsecond intervals, where the RX buffer is in milliseconds.
If you follow the buffer setting instructions, you should be fine, in most cases.
No GPS/Mixed Mode
You do not need a timing source to use an RTCM if you don’t want to vote. That’s called Mix Mode.
Having the PPS Polarity set to 2 tells the RTCM you do not have a GPS. That forces the RTCM to become a mix (non-voting) client. Turn it on, save it, and restart. A simple voter.conf would look like this:
[general] port = 667 password = BLAH [1000] Site1 = pswrd1,master,transmit Site2 = pswrd2,transmit
Mixed Client Error
"I am getting this error in Asterisk":
WARNING[2368]: chan_voter.c:4511 voter_reader: Voter client master timing source mobile1 attempting to authenticate as mix client!!
A mixed client error means the voter.conf file is expecting an RTCM to try and connect with a GPS IP packet (ie. has master in it in voter.conf), but the RTCM isn't
sending a GPS IP packet. So its a mismatch between voter.conf and Option 10 in the RTCM.
If you want to use a mix client (non-voted), make sure that receiver's configuration line in voter.conf does not have the master option set.
Mix Clients with Voted Client Issues
Situation... "I have a private node with 6 voted receivers using RTCMs. I'd like to add a 7th RTCM to this node that is always mixed in rather than voted. I'm able to make this RTCM work as a 7th voted receiver with no problem. Everything I've read seems to indicate that if I change GPS PPS polarity to "none" this will achieve my desired results, however I am unable to get audio out of my transmit RTCM from this 7th site. It does change color to cyan in Allmon indicating it is non voted input but I do not get any indication or audio when that units COR goes active."
"Setting voter debug level 3 in Asterisk and I'm seeing the following message repeatedly scrolling by in a blur when the mix client detects COR (COR is active). Sequence numbers are continually incrementing by 1. I'm running software version 1.47 on all my clients:"
mix client (Mulaw) my_client index:0 their seq:629 our seq:629 mix client my_client outa bounds, resetting!!
If you have a similar situation to the above... check your buflen in voter.conf. Make sure it is at >=160 and see if that fixes it.
Ubiquity ToS
So, if we set ToS/DSCP in the header to C0, then Ubiquity (and other gear watching ToS) should prioritize the packets. This sets the DSCP to 110 000 aka 48. UBNT shows this as 802.1p Class 6 (Voice <10mS latency). Other sources show this as a Network Control TOS.
There is an option in voter.conf to turn this on (utos=y). However, this only controls packets being sent from Asterisk TO the RTCM.
If you want to tag packets from the RTCM TO Asterisk, you need to set the RTCM debug option level to 16 (see #Debug Options for how this works).
At some point we should probably change the default behaviour of the RTCM firmware to mark the packets and use the debug setting to disable ToS. That change (if you wanted to compile your own firmware) would be:
Change line 90 in IP.c From: #define IP_SERVICE ((AppConfig.DebugLevel & 16) ? 0xc0 : (IP_SERVICE_ROUTINE | IP_SERVICE_N_DELAY)) To: #define IP_SERVICE ((AppConfig.DebugLevel & 16) ? (IP_SERVICE_ROUTINE | IP_SERVICE_N_DELAY) : 0xc0)
This changes the conditional expression from if the debug level is 16 to mark the packets with DSCP 48 to if the debug level is 16, mark the packets routine (DSCP 0).
Duplex Mode 3
Does delayed repeat audio bug you? Tired of hearing a bit of yourself after you unkey? Wish you could talk full duplex? Hate the echo chamber effect? Then we have the answer for you.
Duplex Mode 3 in app_rpt allows for "in-cabinet repeat" (where the radio hardware provides repeat audio) and app_rpt adds the hang time, courtesy tones, linking - all the
things apt_rpt does sans repeat audio. Therefore no repeat audio delay. Cool, eh? This duplex mode has been in app_rpt for a while. Problem has been how to implement it in the RTCM environment.
Duplex Mode 3 support in the RTCM provides in-cabinet repeat functionality. Repeat audio loops through the RTCM and has almost zero delay because it does not have to traverse the network. The delay is not quite zero but it's plenty short enough to eliminate all of the above mentioned annoyances.
Of course Duplex Mode 3 support can't be used with voting or simulcast. You also loose Touch Tone muting, Time Out Timer and Repeater Disable functions because the repeat path is not through app_rpt.
Setting Voter Buffers
Voter ping is useful for end-to-end network evaluation when ICMP ping is turned off and/or the RTCM is behind a firewall and is not ICMP reachable. It can also help with finding the correct RTCM and voter.conf buffer settings.
Voter Ping Usage
The voter ping asterisk CLI syntax is:
*CLI>voter ping nameOfClient [packetCount]
If packetCount is not specified 8 pings will be sent. Use packetCount of 0 to stop an in progress voter ping. Set packetCount to at least 100 when evaluating link quality.
The result will be similar to:
... PING (nameOfClient): Packets tx: 100, rx: 100, oos: 0, Avg.: 26.710 ms PING (nameOfClient): Worst: 38 ms, Best: 22 ms, 100.0% Packets successfully received (0.0% loss)
The output above is self evident except for oos which is a count of out of sequence packets. Voter ping requires RTCM firmware 1.23 or newer and chan_voter 2013-08-04 or newer.
RX Buffer Size
Ping all the receiver sites and look for the worst response of the worst client. As a rough rule of thumb the buflen setting in voter.conf should be set to the worst response + 40ms or 120 whichever is greater. Using the above case the buflen should be set to 120 (38+40
TX Buffer Size
Ping all the transmitter sites and look for the worst response of the worst client. The RTCM TX Buffer Length should be set to (worst response + 40ms) * 8 or 480 whichever is greater. Using the above case the RTCM TX Buffer Length should be set to 624 ((38+40)*8).
Assumptions
- The minimum TX buffer size is 480 (60ms) and the minimum RX buffer is 120ms. These were derived by testing on a LAN segment with chan_voter 2013-08-04 and RTCM 1.26.
- The ping times are not round trip times but they are in fact round trip times. Therefore the worst response could (should?) be divided by 2. Ie RX buffer = 38/2+40=59 and TX buffer = (38/2 + 40) * 8 = 472. Minimums still apply.
- The internet path to and from the RTCM under test is symmetrical.
- The added 40ms pad is an estimate of buffer ingress and egress.
As always your milage may vary. Some trial and error may be required to find the optimum settings.
Setup
The RX buffer is set with buflen=120 in /etc/asterisk/voter.conf. The value is in milliseconds. The TX buffer is set in the RTCM with menu item 7. The value is in 125 microsecond increments. To match the size of the TX to the RX buffer, use the RX buffer * 8 to get the TX buffer size.