VOTER

VOTER Voice Observing Time Extension for Radio

Introduction

The VOTER (Voice Observing Time Extension for Radio) system was originally created by Jim Dixon, W6BIL (SK).

In many two-way radio applications, both for repeater systems and simplex base-stations, it is often difficult to have reliable reception when there is signal impairment due to terrain or other obstacles.

One common way to solve this problem is by use of a voting multi-receiver system. Such a system is comprised of a number of receivers, located at diverse locations. The location of these receivers is chosen so that the combined coverage of all the receivers more or less fill-in the entire desired coverage area, even though it may take a number of receivers to accomplish this. All such receivers are connected ("linked") to a central location (generally the transmitter site), and a device compares each receiver's signal strength and selects the one with the best signal. This is called voting.

Often in such a system, there is one single high-powered transmitter located at a central site that all mobile/portable stations would be able to receive. Sometimes, one single transmitter can not be located where coverage of the entire desired area is possible. In such cases, multiple transmitters are deployed in several locations. Since all these transmitters are on the same frequency, they must be very precisely locked to the same frequency and be transmitting the exact same audio at the exact same time. Not doing so would severely degrade their reception. This is called simulcast (transmitters).

Traditionally, receivers that comprise a voting system are each connected to the central site via either a UHF or microwave link. Since this requires a receiver, link transmitter and link receiver for every receive site, implementation and continued cost of such a system typically becomes quite significant and in most cases prohibitive, and requires a high complexity of implementation.

There are, however, many advantages of implementation of such a system that warrant the cost and effort required.

With the advent of VOIP-based interconnections for radio systems, it is now possible to implement a voting system using VOIP to link the receivers to the central site, and therefore reduce the system requirements and complexity and cost by eliminating the radio links between the receivers and the central site.

There are a few commercial vendors of VOIP-based voting systems that offer a functional and reliable, yet proprietary and extremely high-cost solution.

Although using VOIP-based technology significantly reduces the cost and complexity of implementation of a voting system, the cost of the commercial VOIP-based devices is still quite prohibitive for all but large commercial and/or government applications. Therefore, it seemed appropriate to offer a completely open-source, open-hardware solution that makes the cost and complexity of a VOIP-based voting system nearly trivial and gives almost anyone the ability to implement this type of a system that wises to do so.

You can see some of Jim's other musings about the development of the VOTER here.

Description

In order to successfully implement a VOIP-based solution for this purpose, it is necessary to have a precise time reference in order to be able to re-assemble (time-wise) the audio streams at the central site, since VOIP has inherent inconsistencies in time delay (jitter and such). Clearly, the best and most reasonable and economic source of such precise timing data is GPS. Therefore, a GPS receiver (with a 1 pulse per second output) must be made available at each receiver location (along with the central site).

Since precise timing is necessary, it precludes the use of any implementation which relies on a traditionally host-based operating system, such as Linux or UNIX, because of limitations of timing and scheduling precision and latency.

Therefore, a dedicated hardware device with a simple embedded micro-controller was necessary to accomplish the necessary precise timing requirements. In addition, low cost (in comparison with a host-based solution) makes placing such a simple dedicated hardware device at each receiver location a great advantage.

• 
• 

Such a dedicated hardware solution significantly increases reliability, has a far lower power consumption, and is physically smaller (in comparison with a host-based solution).

The "central site" functionality (the device which receives all of the VOIP-based audio streams from the receivers and selects which receiver's audio to use) is implemented as a channel driver (chan_voter) along with app_rpt under Asterisk PBX. The host-based system on which this runs, along with a dedicated hardware device (which gives access to the precise GPS-derived time data) is typically located with the system's transmitter (or at least one of them).

Each dedicated hardware device is also capable of simultaneously generating time-synchronized audio out to drive a transmitter (or multiple transmitters in a simulcast system). The audio out of all the dedicated hardware devices at all locations will be identical at the same time.

There are facilities available for on line monitoring of the voting system (audio and signal strengths), in addition to recording (logging) facilities.

Why a 9.6MHz Clock?

A question that often gets asked (in relation to doing simulcast) is, "why not just clock the dsPIC at 10MHz, instead of 9.6MHz". Well, there is a very good reason that Jim picked that oscillator frequency, and a very good reason why you cannot use 10MHz.

It comes down to timers and interrupts.

In particular, the ADC servicing subroutine. With the way the dsPIC is configured with the 9.6Mhz oscillator, this subroutine is automatically called every 62.5uSec, as it is controlled by Timer 3 (TMR3).

This subroutine is responsible for encoding the RX Audio Packets, and doing all the AtoD on the other analog inputs, RX Noise (for RSSI), Squelch Pot position, and Diode Voltage (temperature compensation).

Every ODD time this subroutine is run, it encodes a RX Audio packet. Since this happens every OTHER time the ISR runs, that means it runs every 125uSec. Well, the reciprocal of 125uSec is 8kHz, so this is how we encode 8000 samples/sec of RX Audio! ***By default, encoding is ulaw, unless you SPECIFICALLY configure this client for adpcm in voter.conf***

Every EVEN time this ISR runs, it alternates measuring RX Noise, Squelch Pot Position, and Diode Voltage. So, each of those is measured every sixth time in, or every 375uSec.

EVERY time this ISR runs, we bump some counters.

Every time TMR3 expires, we service this routine and do an ADC conversion.

We alternate between reading the RX Audio, and one of the other three channels (Squelch Noise, Squelch Pot position, and Diode (temp comp) voltage).

So, as you can see, in order to encode ADPCM audio at 8kHz, we need precise timing to take the ADC samples of the audio and encode them. Because of this precise timing, and the restrictions in the clock dividers in the dsPIC, it works out that 9.6MHz is the most suitable (common) crystal/clock to use.

That said, some investigation has been done to see if there are any other suitable clocks. As it turns out, there may indeed be. Old CDMA wireless systems had GPSDO's that had a 9.8304MHz (CDMA 8x Chip) output that was locked to GPS (and there are lots of those still surplus). It would appear that there is a valid clock configuration for the dsPIC that would allow this clock signal to be used, and still maintain the 62.5uSec timer for the ISR.

However, there is another problem presented with this approach, the bootloader. The bootloader is expecting a 9.6MHz clock to run, so it isn't going to like it if you feed it 9.8304MHz. We don't have the source code for the bootloader, so that is a more difficult change to implement. However, peeking in to the .cof file with a hex editor one can find what seems to be the opcodes to set up the clock on the dsPIC when it boots. It may be possible to hack the bootloader to run at 9.8304Mhz. Further testing is required.

Of course, this is only really of consequence if you are wanting to do simulcast, where everything needs to be precisely timed. For normal voting use, the standard 9.6MHz clock works just fine.

Implementation

A UDP-based VOIP protocol was created specifically for this technology. See the VOTER Protocol page for further details on the underlying communication protocol between client devices and the host.

VOTER

The dedicated hardware device (the VOTER) was initially implemented as an approximately 160 by 100mm circuit board utilizing thru-hole mounted components allowing user-assemble-able blank boards to be made available quite inexpensively. It uses a dsPIC33FJ128GP802 processor and a few other integrated circuits, including some operational amplifiers (which implement filters, amps, etc). The schematics, board design, artwork, and PIC firmware are available on a completely free open-source basis, the original project information is available in the AllStarLink Github Repository.

• 
• 

In addition, the schematics of the original VOTER have been redrawn in KiCAD, and are available here.

Firmware on Github is produced to support both devices.

Documentation to support the VOTER is available on the VOTER Hardware page.

For specific information about the console menus and options available in the firmware, see the VOTER Menus page.

RTCM

The VOTER was then implemented commercially by Micro-Node International and marketed as their Radio Thin Client Module (RTCM). The RTCM is effectively a VOTER, but built with SMT components. It runs the same (similar) firmware as the VOTER, with differences being in the dsPIC that it uses, as well as some of the peripheral mapping.

• 
• 
• 

Firmware on Github is produced to support both devices.

As it runs the same (similar) firmware as the VOTER, for specific information about the console menus and options available, see the VOTER Menus page.

Unless specifically noted, references to the VOTER hardware apply equally to the RTCM, and both terms may be used interchangeably.

There is a User Manual available for the RTCM, but it has not been updated in a long time. You may wish to supplement with information from our online VOTER documentation (for the through-hole board) or the RTCM Client pages.

Firmware Upgrading

See the firmware upgrading page on the procedure to upgrade the firmware.

Provisioning and Configuration

General System Provisioning

There needs to be:

• Some number (> 1) of receiver sites that contain 1 of identical model receivers (or at least ones with identical characteristics), 1 VOTER (embedded hardware) card, 1 GPS receiver and some sort of Internet connection (can be a private LAN).

• Some number of transmitter sites (typically 1, but not necessarily) that contain a transmitter, 1 VOTER (embedded hardware) card, 1 GPS receiver, and some sort of Internet connection (can be a private LAN). A site may have both a receiver and transmitter sharing the same VOTER card, GPS receiver, and Internet connection.

• A Linux host running Asterisk (AllstarLink or variants) with app_rpt and chan_voter, along with a VOTER (embedded hardware) card, a GPS receiver, and an Internet connection (may be a private LAN in some cases) with sufficient bandwidth to accommodate all the packet traffic from/to all the receiver and/or transmitter sites. This location may also have a receiver and/or transmitter connected to the VOTER card.

• Optionally, system monitoring access (both audio and signal strength at all receive sites) may be made available through the use of a JAVA applet (deprecated) and a process running on a server at a location with high availability and high bandwidth Typically, this is not at the same location as the above system, but may be, if appropriate. Note: currently this is accomplished using Allmon/Supermon for most monitoring situations (votemond/votermon are deprecated).

The system layout is envisioned as:

IP (Internet) Network Planning and Provisioning

The receiver/transmitter sites may be connected to the "master" site (the one containing the Linux system running chan_voter/app_rpt/Asterisk) via either a LAN (either physical or extended Local Area Network), or via a public Internet connection, or some combination thereof.

See the VOTER Protocol page for further details on the underlying communication protocol between client devices and the host.

Regardless of the interconnection method, the following criteria must be met:

• Sufficient bandwidth must be available at all times between each receiver/transmitter site and the "master" site. The latency of such connections must be within reasonable limits, and certainly must be within the limits configured in both the VOTER board devices and chan_voter.

• The "master site" really should be on a static IP address. Although not 100% necessary, it could really make for an unreliable installation.

• Any of the devices (including the "master" site) may be behind NAT and/or a firewall. There is no specific requirement for the VOTER board to have any sort of non-NATed access, since the actual IP address and UDP port that is public really makes no difference. All authentication is based upon CHAP-type tokens, and not upon IP address in any way. The "master" site may be behind NAT and/or a firewall, as long as its listening UDP port (generally 667) is exposed to the public (unless entire system is on an entirely private network). If the implementer wishes, TELNET access may be configured for the VOTER board, and in that case, the port selected for TELNET must be made publicly accessible (since the VOTER firmware supports dynamic DNS, it certainly may be on a dynamically-assigned public IP address when the TELNET option is used, and its actual IP address really doesn't matter if TELNET is not configured). Be warned however, it is a VERY BAD idea to expose TELNET to the public Internet, you accept all responsibility if you choose not to heed this warning!

Bandwidth Considerations

Typically, the IP bandwidth usage in each direction, when a signal is present is approximately 100kbps (including UDP/IP overhead, 1 direction only if just a receive or just a transmitter site, or both directions if a receive/transmit site).

On a public Internet connection, its a good rule-of-thumb to get a connection capable of 3 to 4 times the required bandwidth in the slowest direction (often, such connections are asymmetrical as far as their speeds are concerned).

If possible, avoid wireless connections (ie "cellular", "MiFi", etc.). DSL/Fiber/Cable is your friend. It tends to be more reliable and consistent (less latency and jitter) then other forms of broadband connections.

If a wireless connection is really required (ie mountain-top microwave link), use a high reliability solution, such as the devices from Ubiquiti or Microtik. The VOTER hardware DOES support ToS marking of packets, but your link shouldn't be congested to the point where that would be required anyways!

Receiver (and/or Transmitter) Site

A receiver and/or transmitter site consists of a receiver capable of providing direct access to the output of the FM discriminator (and output of CTCSS/CDCSS tone decoder, if applicable) and/or a transmitter, a VOTER (embedded hardware) board, a GPS receiver capable of providing a precise 1 pulse per second signal (such as the Garmin LVC18) and NMEA or TSIP information packets, and an Ethernet-based Internet connection.

Since there may very well be several versions of the VOTER board hardware available, this document will not cover specific details of the shown hardware device here. The full details for each hardware device, including construction (if applicable), programming, and specific configuration options are available from the vendor of the particular device. Only generic configuration concepts and options will be covered here.

VOTER Hardware Configuration Settings

There are several categories of configuration parameters that apply to all version of the VOTER hardware.

• IP SETTINGS – Standard IP setup parameters (IP Address, Netmask, Gateway, DHCP, etc.).
• VOTER SERVER – VOTER server address, specified as a Fully-Qualified Domain Name (FQDN), UDP port on VOTER server, and (optionally) local UDP port (generally left at default), and client and server passwords. The firmware in the VOTER board does a DNS resolution once per minute and resolves the IP address for the VOTER server, based upon the FQDN specified in this configuration. Therefore, the actual IP address of the VOTER server may be changed (and the its associated DNS entry), and the VOTER board firmware will continue to be aware of its current IP address (thus not requiring re-configuration of the VOTER board firmware if the IP address of the VOTER server changes).
• The “client password” is the password, as configured in the server, that identifies the VOTER hardware (client), and the “server password” is the common server password as configured in the server (which allows verification of the server's identity by the VOTER hardware firmware).
• TX BUFFER PARAMETER – Transmit buffer length. This allows for simultaneous time-consistent audio output at all VOTER clients in a system. Buffer length is set to allow for maximum network latency between “master (host) site” and receive/transmit sites.
• GPS RECEIVER PARAMETERS – Data Protocol (NMEA or TSIP), Baud Rate, Data Polarity and PPS Signal Polarity (and time offset, don't ask, just leave it at 0, hopefully) for GPS receiver.
• TELNET PARAMETERS – Port Number, User name, and Password for console TELNET access.
• DYNDNS PARAMETERS – Setup parameters necessary to make dynamic DNS work (if desired).
• EXTERNAL TONE DECODE – Sets mode for external tone decode (CTCSS) input (enable/polarity).

The console gives access to a menu allowing setting of the above-mentioned parameters in addition to various system-related functions, reboot, save parameters, status, etc. In addition, the console displays important system status messages as various events occur (such as changes in GPS status, changes in DNS resolution, etc.). More information on all the menus and options is available on the VOTER Menus page.

VOTER Hardware Setup and Installation

For more information on the VOTER Hardware connections, see the VOTER Hardware page. For the RTCM, see the user manual and/or the RTCM Client pages.

Appropriate connections need to be made between the receiver's discriminator and optionally its tone decode output and/or the transmitter and its line level (or MIC input, attenuated) and PTT signals. Note: in most applications, transmit audio must be routed through the mic input so that it gets pre-emphasized, limited, and splatter filtered. DO NOT connect to a modulator input/data input or other direct transmitter connection (unless you are generating CTCSS with the VOTER, then see below). Discriminator audio is required to do noise (RSSI) and squelch analysis on the incoming audio, prior to the actual voice audio (baseband) being de-emphasized and sent to the host (unless it is specifically overridden, then it is a custom application). As such, the audio sent from the host to the transmitter(s) needs to be pre-emphasized before being sent over the air.

The GPS receiver needs to be connected (see notes on the VOTER GPS page), and the VOTER hardware needs to be connected via Ethernet to an Internet connection, and, of course, power needs to be applied to the board.

With no antenna connected to the receiver, the boards needs to have its “squelch calibration” procedure performed (see the documentation for the specific hardware).

Then the receive level needs to be set, either by putting the board in “level setting” mode, or with use of the console (see the documentation for the specific hardware). The transmit level also needs to be set at transmitter site(s). See the VOTER Audio page for further instructions on configuring audio and setting levels.

Once the above procedures are performed, the board is ready to have its operating parameters configured and then it will be ready for use. Configuration is done via serial console or TELNET. Serial console may be required for initial configuration, if you cannot determine the IP address given to the VOTER hardware via DHCP when first connected to your network.

Set the IP Setting, TX Buffer Parameters, GPS Parameters (if necessary), TELNET Parameters, DYNDNS Parameters, and External Tone Decode appropriately for the installation.

The VOTER/RTCM hardware device needs to be on an Ethernet network (typically a router or switch or wireless bridging device of some sort) that has connectivity to the “master/host” site, either via public Internet or via private LAN (extended, perhaps).

It may be on a network that allocates IP addresses (LAN and/or public IP address) dynamically. The VOTER protocol and the VOTER hardware firmware are designed specifically to allow for not needing the IP address of any VOTER board to be long-term consistent, or even important, for that matter. All authentication and identification is based upon tokens, not IP address or port.

If TELNET access is desired, the VOTER hardware needs to at least have its TELNET port accessible (through a NAT/Firewall if used), otherwise it is not necessary. Even if TELNET access is used, a dynamically-assigned public IP address will work, because dynamic DNS (dyndns.org) is supported in the VOTER hardware firmware.

This document assumes sufficient familiarity with IP and general networking concepts, and therefore will not go into specific details of network provisioning.

The VOTER Server Settings on the VOTER hardware will be covered in the next section.

Overall System / Main Site Configuration

app_rpt (Asterisk) uses a channel driver chan_voter, which implements the “master site” or "host" functionality, providing an Asterisk channel which app_rpt may open as a radio interface (like a usbradio or pseudo channel in a non-voting AllstarLink system). This driver receives (and/or sends) UDP packets (typically on UDP port 667) from/to all associated VOTER clients at receive and/or transmit sites.

For each VOTER channel instance, both voting (GPS-based) and “general-purpose” (non-GPS-based) clients may be used. The channel driver essentially “mixes” the resultant audio from the voting subsystem along with the audio from all of the “general-purpose” clients (if any).

In addition, the channel driver (optionally) may be configured to send a stream of UDP packets to a predetermined IP address and UDP port. This stream is meant to be redistributed by the votmond program (deprecated) running on a high-availability, high-bandwidth Linux Server, and give users access to monitoring of the VOTER audio and signal strength information in real time.

chan_voter uses a configuration file, /etc/asterisk/voter.conf, which contains typically several stanzas.

Here is an example of a voter.conf file:

[general]
port = 667
buflen = 500
password = BLAH
utos = y                        ; Turn on IP TOS for Ubiquiti ***this only marks packets from Asterisk to the VOTER
                                ; if you want to mark packets from the VOTER to Asterisk, you may need to set the
                                ; debug level to 16 on the VOTER (depending on firmware version).
[1234]
MAD6 = madcow6
MAD5 = madcow5
MAD4 = madcow4
MAD3 = madcow3
MAD2 = madcow2
MAD1 = madcow1,master
streams = 67.215.233.178:1667
plfilter = y
txctcss = 100.0
txctcsslevel = 100
txtoctype = none
thresholds = 255,110=5
linger=6

The [general] stanza specifies the UDP port that the VOTER clients are expected to send packets to (the port parameter must match the VOTER Server Port on the client), the receive buffer size in milliseconds (the buflen parameter), and the server password (the password parameter must match the Host Password parameter on the client). The utos setting will mark packets FROM the host to the client with the TOS flag in the IP packet header. Depending on the firmware version of the client, you may need to enable debug level 16 to mark packets from the client to the host (newer versions mark packets by default and do not require debug level 16 to be enabled).

Each additional stanza is named in an appropriate manner (generally matching the associated node number in the rpt.conf file) using an [INSTANCE_NAME] ([1234] in this example). There can be more than one [INSTANCE] stanza, depending on how many voter systems are being managed by the server (one instance stanza for each node/repeater that has it's own VOTER clients that are being managed on the server). In rpt.conf, this stanza name references the channel driver name (in this case it would be rxchannel=voter/1234). In the Asterisk console, this is also known as the instance name (1234 in this example) when using the Asterisk voter console commands.

Within each named stanza (not the [general] stanza), the VOTER clients are defined:

• by specifying DISPLAY_NAME = password[,options] for each client. The DISPLAY_NAME is shown on Allmon/Supermon and is used as the client name in the Asterisk console. The password here must match the Client Password in the individual VOTER hardware at the client site

and operating parameters (that apply to the whole instance), such as:

• streams, which specifies a list of `IP_ADDR:UDP_PORT` values indicating where to send the votmond (deprecated) redistribution stream associated with the specified system
• plfilter, which if set to true, enables a 300Hz low pass filter in the VOTER hardware, used when a CTCSS/CDCSS tone is higher in frequency than 120Hz
• txctcss, txctcsslevel, and txtoctype (if transmit CTCSS generation is desired in the VOTER hardware, see below)
• thresholds and linger which define the behavior of the voting selection algorithm

The options for each specified DISPLAY_NAME are as follows:

• master – This specifies that this client is the Master Timing source (the VOTER hardware that is on the same LAN as the AllstarLink Asterisk server. There can only be one Master Timing source per entire Asterisk server.
• transmit – This specifies that this client is intended to have transmit audio sent to it and will have a transmitter connected to it.
• adpcm – This specifies that this client is to be sent audio in ADPCM format, rather than Mu law.

If no options are specified for a client, then none of the options specified above are enabled for the particular client, and will be treated as a standard (non-master), receive-only, Mu law audio client. There are other (advanced) options that may be set, they will be covered elsewhere.

On each VOTER hardware client, the Client Password must be set to the associated value for the desired client as specified in the stanza of the voter.conf file. Using the above example, the “MAD1” VOTER client would be configured to have a Client Password of “madcow1”. The “MAD1” designation is only used and referenced by chan_voter, and is not specified or known in any way by the VOTER client.

On each VOTER hardware client, the “Server Password” must be set to the value specified in the password parameter in the [general] stanza of the voter.conf file.

Buffer Settings

The buflen parameter in the [general] stanza specifies the receiver buffer length in milliseconds'. This parameter should be set to the maximum expected network latency, plus a little padding (100mS of padding is a good amount). The default is 500 milliseconds, and is what the value will be set to if not specified.

The Asterisk server at the “main site” (in addition to all the ports that are canonically made public to operate a standard app_rpt installation) must have the port specified in the port parameter in the [general] stanza in the voter.conf file made publicly available, or at least available to all possible IP addresses from which its associated VOTER clients could possibly be operating.

The Tx Buffer Length parameter on each VOTER client, is similar to the buflen parameter for the receive (host) side. It's set the transmit buffer length in samples (8000 samples per second, so 8 samples = 1 millisecond). Like the buflen parameter, this should be set to the maximum expected network latency plus a little padding (800 samples is a good amount of padding, so setting the parameter to 3000 is probably a good place to start).

In both the receive and transmit cases, the buffer length is a fixed value. This will hard-set the delay time between actual reception and presentation time to the Asterisk channel (in the case of receive), and presentation from the Asterisk channel and actual transmission (in the case of transmit).

Since the overall system time delay (the amount of time between reception and re-transmission of the signal) is determined as the sum of the receiver buffer length, the (very minimal) latency within app_rpt/Asterisk and the Transmit buffer length, it is very necessary to keep these settings to a reasonable minimum (without sacrificing packet consistency/integrity by making it too short based upon network latency/jitter).

Port Forwarding

Since token-based authentication and identification is utilized, having the UDP port open to the public should not be a significant security risk. There must be a VOTER board on the same physical LAN (ie switch) (very low latency) as the Asterisk server implementing the “master site”, which acts as the Master Timing source. This allows chan_voter to have a consistent, reliable, accurate timing source with which the timing information from all other inbound packets are compared and appropriately processed, and from which to generate accurate timing information for time-consistent transmission purposes.

Voting Selection Algorithm and Associated Parameters

Voting selection (the choice of client from which to take the audio stream) is based upon the RSSI (relative signal strength/quality) value associated with each particular client's received signal.

The parameters associated with voting selection are the thresholds and linger parameters specified for each VOTER instance.

If neither of these parameters are specified, the voting selection algorithm will default to choosing the client with the highest RSSI number (and the last-most one listed in the voter.conf file, if a tie exists) each and every received audio frame (every 20 milliseconds).

Although this is a functional option, this is probably NOT what you really want. Doing so will cause the received signal to have an audible “squelch-tail” at the end of a transmission if there is a receiver receiving the signal strongly in addition to a receiver receiving the signal at a low, noisy level.

This, however might be appropriate in very rare instances where receivers are placed in locations that require very agile following of the strongest signal. It is very unlikely, however, that this is the case.

It is far more likely that it is appropriate to set up a set of “thresholds” and optionally a “linger” time that is different then the default (which is 6 frame periods of 20 milliseconds).

The linger parameter allows specification of a default linger value (in multiples of 20 millisecond frames) of other then the system default value (6).

The thresholds parameter is a comma-separated list of RSSI threshold values each specified as follows:

MIN_RSSI[=REASSESS_FRAMES[:LINGER_FRAMES]]

• MIN_RSSI is the minimum RSSI value for this threshold (1-255)
• REASSESS_FRAMES is the number of 20ms frames for the client to remain selected at this threshold level before being re-assessed (may be specified as 0, meaning “re-assess at next frame”)
• LINGER_FRAMES is the number of 20ms frames for the client to remain selected after no longer being at this threshold (or any other) (may be specified as 0, meaning “do not linger”)

If MIN_RSSI is specified without the other values, its REASSESS_FRAMES is considered to be infinite (it will not get re-assessed if its RSSI value remains at this threshold), and LINGER_FRAMES will be its default value (6).

If MIN_RSSI and REASSESS_FRAMES are specified, LINGER_FRAMES will be at its default value(6).

A specification for REASSESS_FRAMES must be present if there is a specification for LINGER_FRAMES.

For example:

thresholds = 255,110=5

Meaning:

If the RSSI level is 255, stay selected on that client as long as it still has an RSSI of 255, else if the RSSI level is at least 110, stay selected there for no more then 5 frames. If the RSSI drops below 110, re-assess every frame (since no value below 110 was specified).

Also, since there were threshold values specified and the linger value remained default, any client that meets any specified threshold, stays selected for 6 frames when no clients meet any thresholds any longer.

If, instead the example was:

thresholds = 255,110=5:10

Then:

The same would be true except that if a client meets the “110” threshold (and not the “255” threshold), and then no more clients meet any more thresholds, the client that met the “110” threshold would stay selected for 10 frames rather then the default 6.

This whole methodology is rather strange, but it seems to be appropriate and effective. In the future, it may be improved or modified in some way, but for now it is more than sufficient.

Simulcasting

The RTCM/VOTER boards do support simulcasting, however, there are a bunch of quirks that one needs to be aware of.

See the VOTER Simulcasting page for further information.

Summary

This technology/project is a great asset to the two-way radio community in general, particularly Amateur Radio and other pubic-service related radio services, allowing inexpensive, general, and open access to what previously would have been impossible or otherwise unattainable.

Systems of this type can greatly improve ability to provide efficient and reliable communications, not to mention promoting usage of frequencies and modes that otherwise may have been underutilized or ignored.