VOTER-Audio

Introduction

Audio is critical component of proper VOTER/RTCM operation, as well as node operation in general. This is an extensive topic, with lots of caveats. So, we will lay it all out here.

Before we get in to the different ways audio is routed, there is an important consideration you need to make if you are using the RTCM/VOTER for voting.

The way the voting process works, it needs discriminator audio to determine the signal to noise level from each satellite receiver. As such, you will need to be feeding discriminator audio in to the RX audio pin, so that the hardware/software can vote properly. That means you also need to let the hardware/software (VOTER/RTCM) do the squelch action.

If you need RX CTCSS, you'll need to feed logic from an external CTCSS decoder in to the External CTCSS input pin.

Also, don't disable COR in the RTCM/VOTER... it will cause it to disable the squelch and it will report an RSSI of 255 (full quieting) for all received signals. This is only used in "General-purpose" mode, and allows you to feed processed audio in (instead of discriminator audio), as long as you are sending COR (and/or) CTCSS in to the External CTCSS input to control the squelch (externally).

The RTCM/VOTER is totally flexible regarding emphasis. Although the way it is set is completely obscure. It tries to automatically do the right thing for you, which is great, most of the time. But when it’s not, it's hard to know what is going on.

If you are changing the COR Type settings, or nodeemp in voter.conf, make sure you save/reboot the RTCM/VOTER every time you make a change... changes are not effective until the RTCM/VOTER reboots!

Chuck Squelch

Early versions of firmware had flavors that included "Chuck Squelch". That is no longer a option, as "Chuck Squelch" is now the standard.

"Chuck Squelch" is firmware changes made by Chuck Henderson, WB9UUS.

One of the changes fixes an issue with weak signals producing RSSI readings all over the place. It is caused by a 16 bit value that was overflowing (it is the RSSI change in the firmware). It results in rock-solid RSSI values being reported, even on barely or non-readable signals.

The other firmware change changes how the squelch responds (looks at the noise in the last two audio samples) and makes the "Micor squelch" action work better.

Since the original squelch code was buggy, it has been removed.

DSP/BEW Firmware Version

If you look in the firmware repository, you will see there are BEW versions of the firmware.

DSP BEW Firmware is mutually exclusive with the diagnostic menu. There is not enough space for both, if you load the DSP/BEW firmware, you will NOT have a diag menu.

BEW stands for Baseband Examination Window.

Typically, the discriminator of an FM communications receiver produces results containing audio spectrum from the "sub-audible" range (typically < 100 Hz) to well above frequencies able to be produced by modulating audio. These higher frequencies can be utilized to determine signal quality, since they can only contain noise (or no noise, if a sufficiently strong signal is present).

For receivers (such as the Motorola Quantar, etc) that do not provide sufficient spectral content at these "noise" frequencies (for various reasons), The "DSP/BEW (Digital Signal Processor / Baseband Examination Window)" feature of the firmware may be utilized.

These receivers are perfectly capable of providing valid "noise" signal with no modulation on the input of the receiver, but with strong modulation (high frequency audio and high deviation), it severely interferes with proper analysis of signal strength.

This feature provides a means by which a "window" of baseband (normal audio range) signal is examined by a DSP, and a determination of whether or not sufficient audio is present to cause interference of proper signal strength is made. During the VERY brief periods of time when it is determined that sufficient audio is present to cause interference, the signal strength value is "held" (the last valid value previous to the time of interference) until such time that the interfering audio is no longer present.

The DSP/BEW feature is selectable, and should not normally be used for a receiver that does not need it (squelch will perform better on a normal receiver that has lots of frequency response).

A note on the Motorola SLR5700 per VE7FET. DSP/BEW definitely makes a difference on what AllMon reports for the signal strength of received signals. It is less reactive when DSP/BEW = 1 than with it set to 0. The SLR5700 can be generally categorized with the Quantar in how it processes audio.

Squelch Issues

Troubleshooting squelch issues:

• If anyone is off frequency a little bit, that will make the voice talk off worse. Double check that the repeater and the users are all on frequency.

• Don't use narrow bandwidth on the repeater receiver.

• Make sure that the discriminator audio is not rolled off even a little bit at the high end. There should not be resistors in series or capacitors to ground between the discriminator chip output pin and the voter board input, for best results.

Transmitter Pre-emphasis

On the TX side, the RTCM/VOTER expects the repeater to accept mic audio. In other words, the repeater is providing the pre-emphasis, not the RTCM/VOTER (you are not directly modulating the TX). This can be overridden by setting CTCSS tone in voter.conf. If a CTCSS tone is defined, the RTCM will provide pre-emphasis to the audio, and expects that you will be connecting to your repeater's flat audio input (direct modulation).

If you don’t want TX CTCSS tone but do need pre-emphasis, set an arbitrary (any) CTCSS tone in voter.conf, and set the level to 0. This will force the RTCM/VOTER to pre-emphasize the audio it generates on the TX pin, but it won't actually mix in a CTCSS tone.

Level Setting

Setting the audio levels for the RTCM/VOTER is pretty straight forward. Just follow these steps:

• Ensure you have a connection to your host Asterisk server/chan_voter instance
• Send a 1kHz@3kHz on-channel, full-quieting signal in to the repeater's RX
• Set the RX up so it reads 3kHz deviation on the RTCM's built in console meter
• Now set the TX level pot to get 3kHz out of the transmitter (No PL)

Now change the modulation from 1kHz tone to 800Hz followed by 1.8kHz and verify that the deviation level doesn't change as the tone frequency changes. Changing levels indicates a pre/de-emphasis issue. You will want to read the above sections on how audio is handled, and figure out where your issue is.

If using PL you have to account for that deviation, unless you filter it out with your IFR (test set).

That's it!

Optionally, if you are using the built-in "offline repeat" functions, fail the connection to the host Asterisk server, and make sure your repeat audio performs the same as above.

Resolution issues when setting levels using built VOTER boards

Sometimes, depending on what radio is being used getting a good enough resolution with R61 when setting levels is a problem. You move a small amount on the pot and it jumps several hundred KHz of deviation. Inserting a 4:1 voltage divider between the VOTER board and transmitter helps with this. Something such as a 1K and 330 ohm resistor will work. This allows for much finer adjustment on the transmit audio (R61).

Crappy Transmit Audio

Does your repeated audio sounded really bassy, muffled, and not very understandable?

There was a situation where, compared to a typical simplex radio-to-radio transmission, the audio through the repeater (RTCM and Asterisk) was unacceptable. What was discovered was that the RTCM has an internal pre-emphasis function that was disabled. The user had intentionally disabled "txctcss" and "txctcsslevel" in voter.conf because he didn't want the RTCM transmitting CTCSS (the Quantar was doing that already). He ultimately found a post on the mail list explaining the settings above that said enabling txctcss = some valid tone (114.8 in his case) and setting txctcsslevel = 0 would turn on the pre-emphasis function in the RTCM without transmitting CTCSS tones.

He did, and it worked like a charm! Audio now had more treble and was less bassy/muffled. So, future RTCM users, be sure not to comment out txctcss and txctcsslevel in voter.conf!

Just enable and set the level to 0. You'll thank me later.

Pulse Noise on Transmit Audio

It has been noticed sometimes on built VOTER boards that it has low level DAC noise which sometimes is apparent as a pulsing noise on the audio output. Adding a 4:1 voltage divider inline between the transmitter and VOTER board helps reduce or eliminate this as described above in Level setting.

Receiver De-emphasis

On the RX side the COR Type setting in the RTCM/VOTER determines whether the de-emphasis filter is used for RX audio. 0=Normal means the RTCM/VOTER squelch circuit is in use and it is expecting discriminator audio on the RX pin (to be able to do the squelch action), and therefore it will provide de-emphasis (audio is routed THROUGH the de-emphasis RC filter circuit) to the receiver audio. COR Type 1=IGNORE COR uses the CTCSS input pin for COR or CTCSS logic and it then expects de-emphasized receive (line) audio on the RX pin, and therefore will not provide de-emphasis to the received audio (the RC filter is switched out and audio passes straight through).

Most of the time, you do NOT need to override the automatic filter selection. However, if you do, and you are sure you have a good reason to, you CAN switch the de-emphasis filter out of the circuit so that audio passes straight through to the encoder. You would do this by setting the nodeemp=1 option in voter.conf. When you set nodeemp=1, the VOTER Protocol tells the RTCM/VOTER to switch the filter out, so audio is passed straight through.