ASLCorporate:Thru-hole Voter Board
This is the first published documentation of the VOTER board and is out of date. It is posted here for historical reasons. The VOTER board is now sold commercially as the RTCM.
AllStar Link Network -- VOTER Project (Voice Observing Time Extension (for) Radio)
By: Jim Dixon, WB6NIL (SK)
The Official Documentation Package (NO LONGER CURRENT) for the original VOTER system is still available. For current documentation, see the VOTER page or the documentation of the commercially-available RTCM product.
For a number years, I have been asked about, and have been considering the possibility of the implementation of a multiple site remote receiver voting system that runs with VOIP on app_rpt/Asterisk. The more I looked into it, the more I realized that it was a FAR from a trivial task.
The main problem to overcome is that when you have multiple streams of audio information from multiple receivers, you need a concise and accurate way of synchronizing all of the audio, so that if switching of streams occurs, there will be no inconsistencies in the audio. This is far more easily done on conventional, RF-linked voting systems, being that the delay between the receiver and the transmitter site is very minimal (basically the speed of light) and is painfully consistent. Not so on the Internet. The packet delays can be extremely long and varied, and it makes the task of synchronization far more difficult.
The first challenge is to obtain and convey ultra-accurate time information along with the audio data, so that the transmitter site will know what time the signal was received (which may not have much to do with the time it was received at the transmitter site from the Internet). In order to accomplish this, ultra-accurate time information must be made available, and it must be processed in reasonable and consistent time for it to be meaningful.
GPS is the simplest and most cost-effective solution to obtain ultra-accurate time information. For little money (approx. $60US), a Garmin GPS LVC18 module (there are many others, too) may be purchased. It provides an accurate 1 pulse-per-second signal that can be used to synchronize a timing device.
A "host" type computer running Linux (or UNIX, etc.) is not appropriate to be used as such a device, since it has absolutely no way of processing external inputs (or anything else, for that matter) in a consistent and predictable time. For applications that need to be accurate to hundreds of milliseconds, its fine, but for this purpose, where timing down to individual 125 microsecond audio samples is necessary, it just wont do.
The only reasonable solution is to design hardware to accomplish this. Since hardware design is necessary, I figured that I might as well design a stand-alone board that does all the necessary functions to interface a receiver and a GPS device to an Ethernet with Internet connectivity. Certainly, a peripheral device that attaches to a "host" type computer would also be a reasonable solution, but for the same or less cost, it seems reasonable to eliminate the need for a "host" computer at receiver sites all together.
The second challenge is determining signal strength (RSSI) information from an attached receiver. Thanks to wonderful technology designed by Steve Rodgers, WA6ZFT, which is a small board that implements a VERY high-quality squelch processor, I was able to take the code and front-end design, include it in my design, and not only is it very good squelch processor, but it also is able to provide information from which the signal strength of the received signal may be calculated.
The third challenge is at the transmitter site end (where the app_rpt system is located) taking all of the streams of audio from the various receivers and synchronizing them via included time information, and making a reasonable decision on which stream to "use", based upon signal strength and quality. The synchronization is done with basically a "multi-dimensional jitter buffer" and is implemented in the Asterisk channel driver that I wrote for this application, chan_voter.
The fourth challenge is to facilitate a method of testing the protocol and its implementation within app_rpt. Obviously, there is no way to have a "real" environment available, where there are multiple receivers, mobiles, etc., so a simulator has to be created.
I'm VERY sorry and embarrassed to say so, but I wrote it in Java (yuck!). It seemed the most reasonable way to accomplish what was necessary. It simulates up to 10 channels of audio, and has "sliders" so that you have full control of "RSSI" and "TIME DELAY" for each channel, in addition to selecting which, if any channels are being sent to the host. You can run it, if you desire. This is the VoterSim tool.
I made a new UDP-based protocol for this technology, (called "VOTER"), which may be viewed here, if desired.
I have successfully written firmware for this device that fully implements the VOTER protocol, converts and encodes the audio stream from the receiver, processes squelch, determines signal strength, and interfaces and quite accurately synchronizes to the GPS receiver.
I have designed and built the stand alone board that is the hardware for the receive sites. It's based on a dsPIC33FJ128GP802 processor, and an ENC28J60 Ethernet controller, along with some analog stuff. It is constructed with all thru-hole parts, allowing it to be user-assemblable. The Rev. A boards are have been fabricated, built, and tested. They work very well. The documentation package for them is available, if you wish to build your own.
The firmware for this board has been developed and tested, and is available for browsing from the AllStarLink Github.
VOTER Board Images
Photos with Maxtrac
Schematic, Bill of Materials and CAD Files
- The Schematic or Updated 2022 KiCAD Version.
- The entire CAD package (including BOM/Gerbers).
There is a seemingly functional implementation of chan_voter which speaks the VOTER protocol, and allows interface to a node running app_rpt. It includes a "multi-dimensional jitter buffer", which allows all associated streams to be synchronized, analyzed for signal quality, and presented to app_rpt/Asterisk for use in its associated node. It is included as part of the AllStarLink package.
A test system has been deployed locally (in Madera County, CA, US) and has 5 (may 6 sometime??) receive sites and is being most helpful for testing and verification of the technology and process.
There is also a GUI (Java, yuck!!) based program (VoterPal (deprecated) which allows simulation and experimentation with VOTER streams recorded by the channel driver live on the air (using the voter record command in Asterisk). You can download it here.
There is also a live VOTER stream monitor JAVA applet available called VoterMon (deprecated). This applet, along with a distribution server (votemond) (deprecated) that chan_voter sends a stream to, and allows users of the JAVA applet to connect. It lets you make the received VOTER stream directly available to all that want to listen, and see its actions.
The overview of how this is all fits together:
A surface-mount version of the VOTER board has been produced, it is marketed by Micro-Node International as their AllStar RTCM.
We have had some great success with transmit simulcast. Every VOTER board is capable (if provisioned) to generate time-synchronous audio for the purpose of transmit simulcast (in addition to receiver-site voting). To accomplish simulcast, a GPSDO (GPS-disciplined Oscillator), such as Trimble Thunderbolt, must be used which produces a VERY (supposedly up to 1.5 PPT (yes, TRILLION)) accurate signal at 10 MHz (along with the normal 1PPS and serial GPS location info).
Many readily-available good quality transmitters, such as a Motorola Maxtrac/Radius/MSF5000 can be TRIVIALLY modified to take an external reference clock in lieu of its normal internally-generated clock. These radios typically require either a 14.4 MHz or 16.8 MHz reference frequency, so there is a prototype PLL clock generator board, which takes the 10MHz clock from the GPSDO and turns it into whatever frequency the transmitter requires for normal operation.
Currently in Coarsegold, CA, we have a 2 system voting/simulcast system comprised of Motorola Desktrac repeaters (each a pair of Maxtrac 300 radios) operating very nicely. When you drive through town, its just one working, normal-sounding simulcast repeater system. It's pretty amazing, considering that each Desktrac cost approx $100, each Trimble Thunderbolt cost approx. $100, and there is maybe $200 into each VOTER board/clock generator board at each site.