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