36
edits
Changes
Jump to navigation
Jump to search
Line 5:
Line 5: − + Line 35:
Line 35: + + + + + + + + + + + + + + + + + + + + + + + + + + + +
no edit summary
=Basic Information On chan/voter Works=
=Basic Information On How chan/voter Works=
Each node has a number of potential "clients" associated with it. In the voter.conf file, each stanza (category) is named by the node number that the clients specified within the stanza are to be associated with. Each entry consists of an arbitrary (relatively meaningless, just included for easy identification purposes within this channel driver, and has nothing to do with its operation) identifier equated to a unique password. This password is programmed into the client. '''All clients must have unique passwords, as that is what is used by this channel driver to identify them.'''
Each node has a number of potential "clients" associated with it. In the voter.conf file, each stanza (category) is named by the node number that the clients specified within the stanza are to be associated with. Each entry consists of an arbitrary (relatively meaningless, just included for easy identification purposes within this channel driver, and has nothing to do with its operation) identifier equated to a unique password. This password is programmed into the client. '''All clients must have unique passwords, as that is what is used by this channel driver to identify them.'''
'''DON'T USE IT!!'''. It is intentionally '''NOT''' documented to encourage non-use of this feature. It is for demo purposes '''ONLY'''. The chan/voter driver will '''NOT''' properly
'''DON'T USE IT!!'''. It is intentionally '''NOT''' documented to encourage non-use of this feature. It is for demo purposes '''ONLY'''. The chan/voter driver will '''NOT''' properly
perform reliably in a production environment if this option is used.
perform reliably in a production environment if this option is used.
==Duplex Mode 3/Hostdeemp==
As of VOTER board firmware 1.19 (7/19/2013), there is a set of options in both the firmware ("Offline Menu Item 12, "DUPLEX3 support"), and the "hostdeemp" option (instance-wide) in the voter.conf file on the host.
Duplex Mode 3 in app_rpt allows for "in-cabinet" repeat audio (where the actual radio hardware supplies the repeated audio directly itself, and app_rpt simply "adds" all of the other audio as appropriate.
The RTCM/VOTER board now has an option to do the same functionality itself, for a case where local repeat audio is desired without the "network audio delay" normally associated with RTCM/VOTER board operation, and for a radio that doesn't have the option of providing "in cabinet" repeat audio (along with externally provided audio) itself.
Because of limitations with the RTCM/VOTER board hardware (being that there is only 1 audio path into the processor, and it either has de-emphasis in its "hardware path" or not), it is necessary if you:
#Wish to have the "duplex=3" functionality in app_rpt
#Have the "DUPLEX3" support enabled in the RTCM/VOTER board
#Have a transmitter that you are "modulating directly" (with flat audio)
If all of the above is true, then you need to use the "hostdeemp" option in chan/voter (voter.conf), which basically "forces" the RTCM '''NOT''' to do de-emphasis in hardware (it will send the non-de-emphasized audio to the host), and have the host "do" the de-emphasis (in software) instead.
This will allow the RTCM/VOTER board to be able to "pass" the non-de-emphaszed audio back into the "direct modulation audio" stream, since that is what will be "presented" to the processor in the RTCM/VOTER board, as the hardware de-emphasis is disabled in this mode.
If you have a transmitter that you are "feeding" line-level (mic) audio, then this mode is not necessary, as the RTCM/VOTER board is fully capable of providing the functionality all by itself.
Obviously, it is not valid to use '''ANY''' of the duplex=3 modes in a voted and/or simulcasted system.