Changes

[[Category:How to]]

[[Category:How to]]

{{Infobox PTTLink

{{Infobox PTTLink

| category = Hardware

| category = Hardware

}}

}}

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

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

== Introduction ==

 

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

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.

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.

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

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

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

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

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

== Implementation ==

= Implementation =

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

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

=== VOTER ===

== 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 [https://github.com/PTTlink/voter AllStarLink/PTTLink Github Repository].

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 [https://github.com/PTTlink/voter AllStarLink/PTTLink Github Repository].

Firmware on [https://github.com/PTTlink/voter/tree/develop/VOTER_RTCM-firmware Github] is produced to support both devices.

Firmware on [https://github.com/PTTlink/voter/tree/develop/VOTER_RTCM-firmware Github] is produced to support both devices.

=== RTCM ===

== RTCM ==

The VOTER was then implemented commercially by [http://micro-node.com/thin-m1.shtml 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.  

The VOTER was then implemented commercially by [http://micro-node.com/thin-m1.shtml 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 [https://github.com/PTTLink/voter/tree/develop/VOTER_RTCM-firmware Github] is produced to support both devices.

Firmware on [https://github.com/PTTLink/voter/tree/develop/VOTER_RTCM-firmware Github] is produced to support both devices.

== Provisioning and Configuration ==

= Provisioning and Configuration =

=== General System Provisioning ===

== General System Provisioning ==

There needs to be:

There needs to be:



=== IP (Internet) Network Planning and Provisioning ===

== IP (Internet) Network Planning and Provisioning ==

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

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

* 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!'''''

* 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 ====

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

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

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!

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

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

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.

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

== VOTER Hardware Configuration Settings ==

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

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

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

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

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

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 VOTER Server Settings on the VOTER hardware will be covered in the next section.

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

== Overall System / Main Site Configuration ==

= Overall System / Main Site Configuration =

<code>app_rpt</code> (Asterisk) uses a channel driver <code>chan_voter</code>, which implements the “master site” functionality, providing an Asterisk channel which <code>app_rpt</code> may open as a radio interface (like a <code>usbradio</code> or <code>pseudo</code> 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.

<code>app_rpt</code> (Asterisk) uses a channel driver <code>chan_voter</code>, which implements the “master site” functionality, providing an Asterisk channel which <code>app_rpt</code> may open as a radio interface (like a <code>usbradio</code> or <code>pseudo</code> 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.

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

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

=== Buffer Settings ===

== Buffer Settings ==

The ''buflen'' parameter in the <code>[general]</code> 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 ''buflen'' parameter in the <code>[general]</code> 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.

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 <code>app_rpt/Asterisk</code> 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).

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 <code>app_rpt/Asterisk</code> 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 ===

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

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

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

'''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 ===

== 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 <code>chan_voter</code> 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.

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 <code>chan_voter</code> 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 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.

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.

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.

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

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

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.

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.