[App_rpt-users] recent upgragdes to chan_voter

Jim Duuuude telesistant at hotmail.com
Sat Jan 7 23:31:54 EST 2012

actually "disable" and "off" are both equivalent to -2.

to make site ineligible for voting you have to use -1.


From: tim.sawyer at me.com
Date: Sat, 7 Jan 2012 20:18:47 -0800
To: app_rpt-users at ohnosec.org
Subject: Re: [App_rpt-users] recent upgragdes to chan_voter

Here are a few examples of the new voter priority CLI. 
voter prio instance site disable  ; (or -1) Makes site ineligible for voting
voter prio instance site off        ; (or -2) Remove any priority, make eligiblevoter prio instance site 5          ; vote this site if there is any signal and no higher priority voter prio instance                   ; show priority of all sites
instance is the node number of the voter instancesite is the name (not case sensitive) as defined in voter.conf


On Jan 4, 2012, at 2:21 PM, Jim Duuuude wrote:The chan_voter channel driver that goes along with app_rpt has a couple of new
features (current in SVN).

The 'voter test' CLI command now takes an instance id and no longer supports
modes < 0 (force vote for testing purposes). It still supports the 'torture' tests
that have always existed.

A config file parameter (on a client-by-client basis, in the client string specification)
called 'prio=XXX' has been added. This allow specification of a default 'prio level'
for the specified client.

There is a new 'voter prio' CLI command. This specifies (or allows query of)
a value to override the config-file specified 'priority level' for the specified
voter client. 

An effective priority level is calculated for each client, based upon the level specified
in the config file, and the override level if specified from a CLI command.

For a 'voting' (GPS-timing based) client, this allows 'groups' of clients with higher
priority levels to be 'favored' over 'groups' of clients with lower priority levels
when making the 'voting' decision. 

For a 'non-voting' (non-GPS-timing based) client, it provides a means whereby
if a signal is received from a 'non-voting' client with a priority > 1, the one with
the highest priority 'takes over' the channel's audio (does not include the voted
audio or other 'non-voting' clients not at this priority level). This could potentially
be useful for implementing some sort of control station hierarchy or something of
that nature.

For either type of client, setting its priority to -1 make it ineligible for consideration
(locks its out entirely).


App_rpt-users mailing list
App_rpt-users at ohnosec.org

App_rpt-users mailing list
App_rpt-users at ohnosec.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.allstarlink.org/pipermail/app_rpt-users/attachments/20120107/a248ffb2/attachment.html>

More information about the App_rpt-users mailing list