36
edits
Changes
Jump to navigation
Jump to search
Line 189:
Line 189: − + + + + + + + + + + + + + + + + + Line 245:
Line 261: + + + + + + + + + + Line 287:
Line 313: − + +
no edit summary
=RTCM/VOTER Bandwidth=
=Network Information=
==RTCM/VOTER Bandwidth==
Assuming ulaw... The RTCM will require approximately 80kbps of bandwidth for continual usage.
Assuming ulaw... The RTCM will require approximately 80kbps of bandwidth for continual usage.
==Network Quality==
Your IP Network quality is important. You may wish to add a rule in your routers to prioritize traffic on UDP port 667 so that RTCM audio is given priority over other
traffic. Also see the [[#Debug Options]] below for notes on how to tag your packets with ToS.
==RX/TX Buffers are NOT Both Millisecond Values==
You might assume an RX buffer (in voter.conf) of 120ms would be equivalent of a TX buffer (in the RTCM) of 120ms. That is not the case.
The TX buffer is a number of 125 '''microsecond''' intervals, where the RX buffer is in milliseconds.
If you follow the buffer setting instructions, you should be fine, in most cases.
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!
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!
==Voting==
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 do the squelch action.
If you need RX CTCSS, you'll need to feed logic from an external CTCSS decoder in to the 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.
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
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 that said enabling txctcss = some valid tone (114.8 in our case) and setting txctcsslevel = 0 would turn on the pre-emphasis function in the RTCM without transmitting CTCSS tones.
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!
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!