VOTER

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

VOTER

Voice Observing Time Extension for Radio (VOTER)

Introduction

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.

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.

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/PTTLink Github Repository.

Firmware on Github is produced to support both devices.

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.

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 is deprecated).


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.

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 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.).

VOTER Hardware Setup and Installation

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, 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).

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.

A example of the console display is shown below:

1  - Serial # (1695) (which is MAC ADDR 00:04:A3:00:06:9F)
2  - VOTER Server Address (FQDN) (n0call.dyndns.net)
3  - VOTER Server Port (667),  4  - Local Port (Override) (0)
5  - Client Password (madcow1),  6  - Host Password (BLAH)
7  - Tx Buffer Length (480)
8  - GPS Data Protocol (0=NMEA, 1=TSIP) (1)
81 - GPS Type (0=Normal TSIP, 1=Trimble Thunderbolt) (0)
82 - GPS Time Offset (seconds to add for correction) (0)
9  - GPS Serial Polarity (0=Non-Inverted, 1=Inverted) (1)
10 - GPS PPS Polarity (0=Non-Inverted, 1=Inverted, 2=NONE) (0)
11 - GPS Baud Rate (9600)
12 - External CTCSS (0=Ignore, 1=Non-Inverted, 2=Inverted) (0)
13 - COR Type (0=Normal, 1=IGNORE COR, 2=No Receiver) (0)
14 - Debug Level (0)
15  - Alt. VOTER Server Address (FQDN) ()
16  - Alt. VOTER Server Port (Override) (0)
17  - DSP/BEW Mode NOT SUPPORTED
18 - "Duplex Mode 3" (0=DISABLED, 1-255 Hang Time) (1/10 secs) (0)
19 - Simulcast Launch Delay (0) (approx 200 ns, 5 = 1us, > 0 to ENA SC)
97 - RX Level,  98 - Status,  99 - Save Values to EEPROM
i - IP Parameters menu, o - Offline Mode Parameters menu, s - Squelch menu
q - Disconnect Remote Console Session, r - reboot system, d - diagnostics

The VOTER hardware needs to be on an Ethernet segment (typically a router or switch or wireless bridging device of some sort) that has connectivity to the “master” 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” 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).

Transmit CTCSS

If transmit CTCSS is desired, the txctcss and txctcsslevel (and optionally the txtoctype) parameters must be specified. In order to facilitate generation and transmission of CTCSS along with the normal system audio, the VOTER client (and host) generate “flat” (pre-emphasized/limited) audio, which is intended to directly modulate a transmitter (to be applied at a direct modulation point, NOT a line level or microphone input, as in most VOTER applications).

The txctcss parameter specifies the transmit CTCSS frequency in Hertz. The txctcsslevel specifies the level of the CTCSS tone (0-250). Optionally, the txtoctype parameter may be specified, which determines the “turn-off” (when transmitter un-keys) style for the CTCSS. Setting this parameter to:

• none (default) - means that the transmitter immediately stops transmitting when the system “un-keys”.

• phase - means that the CTCSS tone will briefly be transmitted 120 degrees out of phase when the system “un-keys” (also known as “reverse-burst”, etc).

• notone - means the transmitter will continue transmitting for a brief period with no CTCSS after the system “un-keys” (also known as “chickenburst”).

If transmit CTCSS is not desired, DO NOT specify ANY of the txctcss ,txctcsslevel or txtoctype parameters. The audio that is produced by the VOTER hardware (and the host) will therefore be normal line-level (intended for a line or microphone input) and will NOT be pre-emphasized (as this would be done in the RADIO). MAKE SURE YOU UNDERSTAND THIS BECAUSE IT AFFECTS HOW YOU HOOK UP TRANSMIT AUDIO TO YOUR TRANSMITTER!!

NOTE: It is a valid configuration to hook up the VOTER hardware directly to your transmitter modulator and specify a txctcsslevel = 0 (or some other very small value), and specify any valid txctcss tone frequency. This will have the effect of NOT actually transmitting a CTCSS tone, but leaving you the option to do so down the road, without having to change the wiring to the radio and re-align the levels. In this application, pre-emphasis is done by the VOTER system, as noted above. You MAY want to consider this if you are using the "offline repeat" function of the VOTER hardware to keep your repeater on the air, in the event of a loss of connection between the VOTER client connected to the transmitter (with associated receiver, of course) and the Asterisk VOTER host.

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.

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.