https://wiki.pttlink.org/api.php?action=feedcontributions&feedformat=atom&user=W3KKC"PTTLink Wiki" - User contributions [en]2026-06-05T08:38:44ZUser contributionsMediaWiki 1.35.5https://wiki.pttlink.org/index.php?title=Main_Page&diff=1445Main Page2019-08-30T01:28:16Z<p>W3KKC: Minor change.</p>
<hr />
<div>Welcome to the AllStarLink WiKi. AllStarLink is a world wide network of [https://en.wikipedia.org/wiki/Amateur_radio Amateur Radio] repeaters, remote base stations and hot spots accessible to each other via the Internet and/or private IP networks. AllStarLink runs on a dedicated Linux computer (including the Raspberry Pi) that you host at your home, radio site or computer center. It is based on the open source Asterisk PBX. The app_rpt module is a powerful radio/repeater controller. AllStarLink is open source GPL software free for anyone to use.<br />
<br />
Recently we've moved some things off of this front page. If you don't see what you are looking for look at the [[:Category:How to|How To's]] or use the search located on the top of every page. We've imported all of the content from the docs site [http://docs.allstarlink.org docs.allstarlink.org] into this Wiki. <br />
<br />
__NOTOC__<br />
==Organization==<br />
*[[The Organization - AllStarLink Inc. ]] - Who is AllStarLink?<br />
*[[The Beginning - AllStarLink Inc]] - How AllStarLink came to be. <br />
<br />
==AllStarLink Menu==<br />
*[[Features]] - List of the many AllStarLink Features <br />
*[[Beginners Guide]] - Step by step instructions to create your account and AllStarLink node. <br />
*[[ASL FAQ]] - Questions and answers about the AllStarLink software distribution.<br />
*[[:Category:How to|How To's]] - A collection of AllStarLink how to's.<br />
*[[:Category:Node Configuration|Node Configuration]] - Detailed configuration settings.<br />
*[[:Category:Development|Development]] - Information regarding development of the AllStarLink software (i.e., contributing, etc).<br />
*[[Radio Connections]] - Instructions to Connect Radios, Repeaters and Other Devices to AllStar.<br />
*[[Troubleshooting]] - Troubleshooting common problems, things to try, and hints to solve the problem.<br />
<br />
==Downloads==<br />
* [https://github.com/AllStarLink/Asterisk/releases/tag/ASL-1.01 ASL AMD] Latest AllStarLink installer for x86/AMD (main site)<br />
* [http://dvswitch.org/files/ASL_Images/Intel-AMD/Stretch/ ASL AMD] Latest AllStarLink installer for x86/AMD (alternative site)<br />
* [http://dvswitch.org/files/ASL_Images/Raspberry_Pi/Stretch/ Pi] Latest AllStarLink image for the Raspberry Pi<br />
* [http://dvswitch.org/files/ASL_Images/ ASL Repo] AllStarLink Image Repository<br />
* [[ASL FAQ]] - Install ASL on your existing Debian box or VM<br />
<br />
Note: The ASL 1.01 installer is a Network installer and still uses the dvswitch.org site to download the .deb install files.<br />
<br />
==Related Links==<br />
* [https://allstarlink.org/ AllStarLink Portal] - If you are looking to set up your own AllStarLink node.<br />
* [https://web-tpa.allstarlink.org/ AllStarLink Portal - Beta] - Our beta portal site. Check out the searchable and sortable [https://web-tpa.allstarlink.org/nodelist/ Node List].<br />
* [http://stats.allstarlink.org/ AllStarLink Stats] - shows all the existing public nodes.<br />
* [http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users AllStarLink users mailing list]- This is the app_rpt mailing list for discussion, help and helping others.<br />
* [https://github.com/AllStarLink/ Source Code] - All of the source code for the AllStarLink Asterisk and app_rpt is available on GitHub.<br />
<br />
==History==<br />
* [[History]] from the Duuude, Jim Dixon WB6NIL SK 12/16/2016.<br />
* [[Thru-hole_Voter_Board|Thru-hole Voter Board]] from Jim Dixon</div>W3KKChttps://wiki.pttlink.org/index.php?title=RTCM_Client&diff=1443RTCM Client2019-08-19T02:43:56Z<p>W3KKC: </p>
<hr />
<div>The Radio Thin Client Module (RTCM) is commercially available hardware for interfacing radios to an AllStarLink computer.<br />
<br />
The Micro-Node RTCM and VOTER interfaces are typically used with AllStar in voting/simulcast applications. They MAY be used for ANY repeater interface application, through the chan_voter channel driver. The VOTER is the original through-hole board designed by Jim Dixon for this application. It is open-source, and the relevant Gerber files and BoM to build it are available. The [http://www.micro-node.com/thin-m1.shtml Micro-Node Radio Thin Client Module (RTCM)] is the commercial version of the VOTER. It uses surface mount parts (SMT), but is functionally equivalent to the original VOTER. In general, the two terms (RTCM/VOTER) are used interchangeably, as they operate the same, and use the same firmware (mostly, see below).<br />
<br />
This page will highlight some of the operational concerns, quirks, bugs, and other items of interest that relate to these interfaces. Much of the information has been gleaned off the AllStar mail list, comes from personal experience, or comes from notes in the firmware source code.<br />
<br />
=Testing=<br />
RTCM's come preconfigured to login to [http://voter-demo-allstarlink.org voter-demo-allstarlink.org] for out of the box testing.<br />
<br />
=Factory Reset=<br />
A factory reset can be performed by setting SW 1 down and then applying power to the RTCM. Wait for the green LED to stop blinking, power off and set SW 1 back up. <br />
<br />
=Firmware=<br />
The firmware in the RTCM and VOTER is the same, except it is compiled for the specific dsPIC that is installed in each. As such, the firmware is specific to the VOTER or the RTCM, and is NOT interchangeable (it won't boot in the wrong device). Firmware for the RTCM is denoted by "smt" in the filename.<br />
<br />
<br />
The VOTER uses a dsPIC33FJ128GP802 and the RTCM uses a dsPIC33FJ128GP804.<br />
<br />
<br />
There are '''two parts''' to the firmware, a bootloader, and then the actual firmware file. The bootloader starts when power is applied, and allows you to talk to the dsPIC and load new firmware files over ethernet. If the bootloader is not intercepted by the loading tool, it will continue to boot the current firmware file.<br />
<br />
<br />
All new boards will need to have the bootloader installed first, followed by a firmware file. You '''can''' load a firmware file directly (.hex) in to the dsPIC, but then you will not have any of the bootloader remote loading features.<br />
<br />
<br />
The current bootloader (.cof file) is available here: https://github.com/AllStarLink/voter/tree/master/voter-bootloader (the -smt file is for the RTCM). It needs to be loaded with a PICKit programmer.<br />
<br />
<br />
Current firmware (.cry file) is available here: https://github.com/AllStarLink/voter/tree/master/board-firmware . They are loaded with the EBLEX C30 Programmer.<br />
<br />
<br />
There are multiple "flavors" of firmware available. See below for further explanation of what all the options mean.<br />
<br />
<br />
The DSPBEW versions have Jim's DSP/BEW feature enabled. Note that due to the size of this feature, the diagnostics menu is NOT available in this version.<br />
<br />
<br />
The CHUCK versions have Chuck Henderson's RSSI and Squelch modifications enabled. This is probably the version that most user's will want to use in production.<br />
<br />
<br />
==Compiling Environment==<br />
If you look in the [https://github.com/AllStarLink/voter/blob/master/votersystem.pdf votersystem.pdf], you will find a procedure to modify and load the bootloader in to the dsPIC of a VOTER board. <br />
<br />
<br />
Unfortunately, there is an important step '''missing''' in that procedure, which is covered below.<br />
<br />
<br />
In addition, the old links for the MPLAB software are dead, so let's update this info and get you going.<br />
<br />
<br />
Currently (Feb 2017), you can get the required software from:<br />
:http://www.microchip.com/development-tools/downloads-archive<br />
<br />
<br />
Download MPLAB IDE 32-bit Windows v8.66:<br />
:http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_IDE_v8_66.zip<br />
:http://dvswitch.org/files/AllStarLink/Voter/MPLAB_IDE_v8_66.zip<br />
<br />
<br />
Download MPLAB C Compiler for PIC24 and dsPIC DSCs v3.31 '''NOT v.3.25''':<br />
:http://ww1.microchip.com/downloads/en/DeviceDoc/mplabc30-v3_31-windows-installer.exe<br />
:http://dvswitch.org/files/AllStarLink/Voter/mplabc30-v3_31-windows-installer.exe<br />
<br />
<br />
Optionally, install Windows Virtual PC and XP Mode. This is getting to be pretty old software, so running it under XP Mode may be a good idea, so we can keep it isolated (install it in a virtual machine). It does run fine in Windows 7.<br />
<br />
<br />
To setup the compile/build environment, follow these steps:<br />
*Run the MPLAB IDE installer. You don't need to install the HI-TECH C Compiler at the end (click no)<br />
*Run the MPLAB C Compiler installer<br />
*Select Legacy Directory Name<br />
*'''Select Lite Compiler'''<br />
*Go to: https://github.com/AllStarLink<br />
*Follow the links to: voter --> Clone or Download --> Download Zip. That will get you voter-master.zip which is a download of the whole VOTER tree from GitHub.<br />
*Extract it somewhere (ie. in the XP Mode Virtual PC)<br />
*Launch the MPLAB IDE<br />
*Go to Configure --> Settings --> Projects and de-select one-to-one project mode.<br />
<br />
<br />
==Bootloader==<br />
If you need to load the bootloader in to a fresh board, you will need to follow these steps:<br />
*Go to Project --> Open --> voter-bootloader.mcp --> Open (it is in the voter-bootloader folder of the GitHub source)<br />
*Go to File --> Import --> voter-bootloader --> ENC_C30.cof --> Open '''This step is missing from the original procedure.'''<br />
*Remove JP7 on the VOTER Board. This is necessary to allow programming by the PICKit2/PICKit3 device.<br />
*Attach the PICKIT2/PICKit3 device to J1 on the VOTER board. Note that Pin 1 is closest to the power supply modules (as indicated on the board).<br />
*If you have not already selected a programming device, go to Programmer --> Select Device and choose PICKit3 (or PICKit2, depending on what you are using).<br />
*Go to Programmer --> Program. This will program the bootloader firmware into the PIC device on the board.<br />
<br />
<br />
If you want to change the default IP address from 192.168.1.11 in the bootloader:<br />
*Select View --> Program Memory (from the top menu bar)<br />
*Hit Control-F (to "find") and search for the digits "00A8C0".<br />
*These should be found at memory address "03018".<br />
<br />
<br />
The "A8C0" at 03018 represents the hex digits C0 (192) and A8 (168) which are the first two octets of the IP address. The six digits to enter are 00 then the SECOND octet of the IP address in hex then the FIRST octet of the IP address in hex.<br />
<br />
<br />
The "0B01" at 0301A represents the hex digits 0B (11) and 01 (1) which are the second two octets of the IP address. The six digits to enter are 00 then the FOURTH octet of the IP address in hex then the THIRD octet of the IP address in hex.<br />
<br />
<br />
Once you have modified the address to your desired IP, follow the programming procedure (above).<br />
<br />
<br />
==Firmware==<br />
To compile the firmware (if you want to make custom changes):<br />
*Go to Project --> Open --> navigate to board-firmware and open the .mcp file for the flavor of firmware you want to compile. They are in the board-firmware folder of the GitHub source.<br />
*'''NOTE''': the .mcp files with the "smt" suffix are for the RTCM (built with SMT parts). The non-smt files are for the ORIGINAL through-hole VOTER boards. The difference is that the VOTER uses a dsPIC33FJ128GP802 and the RTCM uses a dsPIC33FJ128GP804.<br />
*Go to Project --> Build Configuration and select "Release". This may not be necessary (I don't believe that option is used in the firmware), but it removes the compiler option of __DEBUG being passed, so theoretically it would build "normal" firmware.<br />
*Go to Configure --> Select Device and choose the appropriate device for your board from the Device list. If you don't select the right one, the board will not boot. Select dsPIC33FJ128GP802 for the VOTER, and dsPIC33FJ128GP804 for the RTCM.<br />
*Now, if you go to Project --> Build All it should compile everything and show you "Build Succeeded".<br />
<br />
<br />
A .cry file should be in the board-firmware folder. You can load this with the ENC Loader.<br />
<br />
<br />
There is also a .hex file in there that you could load with a programmer... but that would wipe the bootloader... so don't do that.<br />
<br />
<br />
==Chuck Squelch==<br />
If you want to enable "Chuck Squelch", open the HardwareProfile.h and un-comment #define CHUCK. <br />
<br />
<br />
You may also want to go down to Line 291 in Voter.c (right click on the window, go to Properties --> "C" File Types --> Line Numbers) and tack on CHUCK after 1.60 (the current version number) so that when you load this firmware, the version will be shown as 1.51CHUCK, and you'll know that Chuck Squelch is compiled in. We should probably make that more automagic in the future...<br />
<br />
<br />
==DSP/BEW==<br />
If you want to compile the DSPBEW version, open the DSPBEW project file instead.<br />
<br />
<br />
=DSP/BEW Firmware Version=<br />
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.<br />
<br />
<br />
BEW stands for Baseband Examination Window.<br />
<br />
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).<br />
<br />
<br />
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 RTCM firmware may be utilized. <br />
<br />
<br />
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.<br />
<br />
<br />
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. <br />
<br />
<br />
The DSP/BEW feature is selectable, and '''should not''' be used for a receiver that does not need it.<br />
<br />
<br />
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. We'll have to see what the real world trials show. It might be better to leave it off.<br />
<br />
<br />
=Chuck Squelch=<br />
"Chuck Squelch" are a couple firmware changes made by Chuck Henderson, WB9UUS.<br />
<br />
<br />
Pre-compiled firmware versions including this option are available on [https://github.com/AllStarLink/voter/tree/master/board-firmware GitHub]. See above on how it is enabled/compiled, if you are rolling your own firmware modifications.<br />
<br />
<br />
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. '''This change will likely be rolled in to a permanent fix in a future firmware release.'''<br />
<br />
<br />
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.<br />
<br />
<br />
You may also want to consider the following changes in [[Voter.conf|/etc/asterisk/voter.conf]]:<br />
<pre><br />
;Comment out:<br />
;thresholds =<br />
<br />
;and set:<br />
linger = 0<br />
</pre><br />
<br />
=Squelch Issues=<br />
*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.<br />
*Don't use narrow bandwidth on the repeater receiver. <br />
*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.<br />
<br />
<br />
==Motorola Quantar==<br />
Some things to consider:<br />
*Install JP1 on the Quantar's RTCM. The squelch should calibrate at around 4 blinks rather than the 12 blinks or so without JP1.<br />
*Be sure you've done the diode and squelch calibration with the actual attached radio (no antenna). <br />
*The Quantar firmware should be 20.14.48 as later versions have better noise output. <br />
*Try the "Chuck Squelch" RTCM version.<br />
*Each RTCM should have 3 to 5 turns past threshold to prevent the squelch form being too loose. Somewhere around the 350 level seems about right. Chuck Squelch seems to need fewer turns but YMMV.<br />
*Don't "and" CTCSS with squelch. That may override the RTCM's squelch detection. Compare with CTCSS on and off to see effect if any.<br />
<br />
<br />
=RTCM/VOTER LED's=<br />
RX LED on the RTCM/VOTER will flash (same rate as ACT LED) if you have External CTCSS enabled, and the received signal has the wrong (or no) valid PL.<br />
<br />
<br />
=Menus=<br />
==Main Menu==<br />
This is what a typical Main Menu looks like:<br />
<br />
<pre><br />
Select the following values to View/Modify:<br />
<br />
1 - Serial # (0000) (which is MAC ADDR 00:04:A3:00:00:00)<br />
2 - VOTER Server Address (FQDN) (44.128.1.1)<br />
3 - VOTER Server Port (667), 4 - Local Port (Override) (0)<br />
5 - Client Password (password1), 6 - Host Password (hostpass1)<br />
7 - Tx Buffer Length (800)<br />
8 - GPS Data Protocol (0=NMEA, 1=TSIP) (1)<br />
9 - GPS Serial Polarity (0=Non-Inverted, 1=Inverted) (1)<br />
10 - GPS PPS Polarity (0=Non-Inverted, 1=Inverted, 2=NONE) (0)<br />
11 - GPS Baud Rate (9600)<br />
12 - External CTCSS (0=Ignore, 1=Non-Inverted, 2=Inverted) (0)<br />
13 - COR Type (0=Normal, 1=IGNORE COR, 2=No Receiver) (0)<br />
14 - Debug Level (0)<br />
15 - Alt. VOTER Server Address (FQDN) ()<br />
16 - Alt. VOTER Server Port (Override) (0)<br />
17 - DSP/BEW Mode (0)<br />
18 - "Duplex Mode 3" (0=DISABLED, 1-255 Hang Time) (1/10 secs) (0)<br />
19 - Simulcast Launch Delay (0) (approx 200 ns, 5 = 1us, > 0 to ENA SC)<br />
97 - RX Level, 98 - Status, 99 - Save Values to EEPROM<br />
i - IP Parameters menu, o - Offline Mode Parameters menu<br />
q - Disconnect Remote Console Session, r - reboot system, d - diagnostics<br />
<br />
Enter Selection (1-27,97-99,r,q,d) :<br />
</pre><br />
<br />
==IP Parameters Menu==<br />
This is what a typical IP Parameters Menu looks like:<br />
<br />
<pre><br />
IP Parameters Menu<br />
<br />
Select the following values to View/Modify:<br />
<br />
1 - (Static) IP Address (44.128.1.2)<br />
2 - (Static) Netmask (255.255.255.0)<br />
3 - (Static) Gateway (44.128.1.254)<br />
4 - (Static) Primary DNS Server (44.128.1.254)<br />
5 - (Static) Secondary DNS Server (0.0.0.0)<br />
6 - DHCP Enable (0)<br />
7 - Telnet Port (23)<br />
8 - Telnet Username (admin)<br />
9 - Telnet Password (radios)<br />
10 - DynDNS Enable (0)<br />
11 - DynDNS Username (wb6nil)<br />
12 - DynDNS Password (radios42)<br />
13 - DynDNS Host (voter-test.dyndns.org)<br />
14 - BootLoader IP Address (192.168.1.10) (OK)<br />
15 - Ethernet Duplex (0=Half, 1=Full) (1)<br />
99 - Save Values to EEPROM<br />
x - Exit IP Parameters Menu (back to main menu)<br />
q - Disconnect Remote Console Session, r - reboot system<br />
<br />
Enter Selection (1-14,99,c,x,q,r) :<br />
</pre><br />
<br />
==Offline Parameters Menu==<br />
This is what a typical Offline Parameters Menu looks like:<br />
<br />
<pre><br />
OffLine Mode Parameters Menu<br />
<br />
Select the following values to View/Modify:<br />
<br />
1 - Offline Mode (0=NONE, 1=Simplex, 2=Simplex w/Trigger, 3=Repeater) (3)<br />
2 - CW Speed (400) (1/8000 secs)<br />
3 - Pre-CW Delay (4000) (1/8000 secs)<br />
4 - Post-CW Delay (4000) (1/8000 secs)<br />
5 - CW "Offline" (ID) String (WB6NIL)<br />
6 - CW "Online" String (OK)<br />
7 - "Offline" (CW ID) Period Time (6000) (1/10 secs)<br />
8 - Offline Repeat Hang Time (15) (1/10 secs)<br />
9 - Offline CTCSS Tone (0.0) Hz<br />
10 - Offline CTCSS Level (0-32767) (3000)<br />
11 - Offline De-Emphasis Override (0=NORMAL, 1=OVERRIDE) (0)<br />
99 - Save Values to EEPROM<br />
x - Exit OffLine Mode Parameter Menu (back to main menu)<br />
q - Disconnect Remote Console Session, r - reboot system<br />
<br />
Enter Selection (1-9,99,c,x,q,r) :<br />
</pre><br />
<br />
=Configuration Options=<br />
==Main Menu Options==<br />
===Serial #===<br />
Sets the serial number for the RTCM/VOTER.<br />
*This sets the MAC address of the unit.<br />
*Each unit must have a unique serial number on your network segment.<br />
<br />
===VOTER Server Address (FQDN)===<br />
This is the DNS name or IP address of the Asterisk server you are connecting to.<br />
<br />
===VOTER Server Port===<br />
This is the UDP port that the Asterisk server is listening on for clients.<br />
*Typically it is left at the default of port 667.<br />
*'''MUST''' match the ''port'' directive in ''voter.conf''.<br />
<br />
===Local Port (Override)===<br />
Sets the local unit UDP port to be something different.<br />
*This is typically not used and left at default (0).<br />
<br />
===Client Password===<br />
This is the '''unique''' password for this unit.<br />
*Every unit '''must''' have a '''unique''' password.<br />
*'''MUST''' match the password on the client configuration line in ''voter.conf''.<br />
<br />
===Host Password===<br />
This is the password of the Asterisk server.<br />
*Configured with the ''password'' directive in ''voter.conf''.<br />
<br />
===Tx Buffer Length===<br />
This is the size of the TX buffer from the RTCM/VOTER to the Asterisk server.<br />
*Tuned parameter, set via the tuning instructions based on network configuration.<br />
<br />
===GPS Data Protocol (0=NMEA, 1=TSIP)===<br />
Type of GPS connected.<br />
*NMEA for all non-Trimble GPS units.<br />
*TSIP to use with Trimble GPS that use Trimble Serial Interface Protocol (TSIP).<br />
<br />
===GPS Serial Polarity (0=Non-Inverted, 1=Inverted)===<br />
GPS dependent setting. <br />
*Depends on if you are sending TTL or RS-232 data, adjust as needed.<br />
<br />
===GPS PPS Polarity (0=Non-Inverted, 1=Inverted, 2=NONE)===<br />
GPS dependent setting. <br />
*Depends on if you are sending TTL or RS-232 data for the PPS signal, adjust as needed.<br />
*If not using GPS or configuring as a mixed client, set to 2 (None).<br />
<br />
===GPS Baud Rate===<br />
Communication speed for the GPS, default is 9600.<br />
<br />
===External CTCSS (0=Ignore, 1=Non-Inverted, 2=Inverted)===<br />
If you are using the CTCSS input from an external CTCSS decoder, adjust this for your logic polarity, or set to 0 (ignore) if not used.<br />
<br />
===COR Type (0=Normal, 1=IGNORE COR, 2=No Receiver)===<br />
Typically, this is left at Normal. <br />
*Set to 1 (Ignore COR), if you are using the External CTCSS input.<br />
<br />
===Debug Level===<br />
Set the Debug Level, if needed, based on the [[#Debug Options | Debug Options]] below.<br />
<br />
===Alt. VOTER Server Address (FQDN)===<br />
If you are using redundant Asterisk servers, set the IP/DNS address of the redundant server here.<br />
<br />
===Alt. VOTER Server Port (Override)===<br />
If the redundant Asterisk server UDP port is not 667, set it here.<br />
<br />
===DSP/BEW Mode===<br />
If the firmware supports DSP/BEW Mode, set this to 1 to enable it, if desired.<br />
*DSP/BEW firmware versions use extra firmware space and will make the diagnostic menu unavailable.<br />
<br />
==="Duplex Mode 3" (0=DISABLED, 1-255 Hang Time) (1/10 secs)===<br />
If you are using Duplex Mode 3, set the hang time here to enable the option. Most users leave this disabled.<br />
<br />
===Simulcast Launch Delay===<br />
If you are using Simulcast, set your launch delay here.<br />
<br />
===RX Level===<br />
This opens the RX Level tuning screen to adjust the receive audio level from the repeater.<br />
<br />
===Status===<br />
This opens the status menu, showing some of the current operating parameters.<br />
<br />
===Save Values to EEPROM===<br />
Save all the options to non-volatile EEPROM.<br />
*Make sure to save after you make any changes.<br />
<br />
===IP Parameters menu===<br />
Open the IP Parameters Menu.<br />
<br />
===Offline Mode Parameters menu===<br />
Open the Offline Mode Parameters Menu.<br />
<br />
===Disconnect Remote Console Session===<br />
If you are connected via Telnet, this will exit your session.<br />
<br />
===Reboot System===<br />
Reboot the VOTER/RTCM.<br />
*This should be done after making configuration changes.<br />
*Some setting changes require a reboot to become effective.<br />
<br />
===Diagnostics===<br />
Open the Diagnostics Menu.<br />
*Diagnostics are unavailable if you are using DSP/BEW firmware.<br />
<br />
<br />
=Network Information=<br />
==RTCM/VOTER Bandwidth==<br />
Assuming ulaw... The RTCM will require approximately 80kbps of bandwidth for continual usage.<br />
<br />
<br />
==Network Quality==<br />
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 <br />
traffic. Also see the [[#Debug Options]] below for notes on how to tag your packets with ToS.<br />
<br />
<br />
==RX/TX Buffers are NOT Both Millisecond Values== <br />
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.<br />
<br />
<br />
The TX buffer is a number of 125 '''microsecond''' intervals, where the RX buffer is in milliseconds. <br />
<br />
<br />
If you follow the buffer setting instructions, you should be fine, in most cases. <br />
<br />
<br />
=Debug Options=<br />
The VOTER/RTCM firmware supports some additional debugging information that can be turned on.<br />
<br />
<br />
From the source code, the different Debug Options are listed as:<br />
<pre><br />
1 - Alt/Main Host change notifications<br />
2 - Ignore HWlock (GGPS only)<br />
4 - GPS/PPS Failure simulation (GGPS only)<br />
8 - POCSAG H/W output disable (GGPS only)<br />
16 - IP TOS Class for Ubiquiti<br />
32 - GPS Debug<br />
64 - Fix GPS 1 second off<br />
128 - Fix GPS 1 month off (WTF,O??)<br />
</pre><br />
<br />
<br />
Not sure what they all do, but that is what they are. Here are the most common ones used:<br />
*"Alt/Main Host change notifications" <br />
**shows when the connection to the Asterisk server changes state.<br />
*"IP TOS Class for Ubiquity" <br />
**marks the IP headers from the RTCM/VOTER '''TO''' the network with ToS C0/DSCP 48 (UBNT shows this as 802.1p Class 6 (Voice <10mS latency). Other sources show this as a Network Control TOS.) If you enable this, you also will want to have "utos=y" in your voter.conf to mark the packets from the network '''TO''' the RTCM/VOTER. We will probably change this option to mark the packets by default in a future version.<br />
*"GPS Debug" <br />
**will print NMEA or TSIP debug strings from the connected GPS.<br />
*"Fix GPS 1 second off"<br />
**this is for NMEA GPS '''only'''. It will add one second to the time.<br />
*"Fix GPS 1 month off (WTF,O??)"<br />
**this is for TSIP GPS '''only'''. It will effectively add a month to the date. The mktime function normally needs one month subtracted from the raw month it converts to a time/date string. Maybe there are some GPS out there that do that automatically? <br />
<br />
<br />
The way this works is you add together the options you want to enable.<br />
<br />
<br />
Want to enable GPS Debug and IP ToS, set debug to 48.<br />
<br />
<br />
Just want to turn on GPS Debug, set debug to 32.<br />
<br />
<br />
Just want ToS turned on, set debug to 16.<br />
<br />
<br />
=Un-documented Menus/Features=<br />
*Menu 96 - If firmware compiled with DUMPENCREGS enabled, Menu 96 looks like it dumps the registers from the ENC (Ethernet) chip?<br />
<br />
*Menu 111 - show the "hidden" option values (normally they should all be 0).<br />
<br />
*Menu 11780 - set the "Elkes" value. Developed for Pete Elke WI6H, this is for solar type sites. It shuts off the Tx after a period of no Rx activity.<br />
<br />
*Menu 1103 - set the "Glaser" timer value? No idea what this does.<br />
<br />
*Menu 1170 - set "Sawyer Mode". Developed for Tim Sawyer use on Yaesu VXR5000 repeater. It modifies de-ephasis behavior when on/off line. <br />
<br />
<br />
=Audio=<br />
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. <br />
<br />
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!<br />
<br />
<br />
==Voting==<br />
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. <br />
<br />
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.<br />
<br />
If you need RX CTCSS, you'll need to feed logic from an external CTCSS decoder in to the CTCSS input pin.<br />
<br />
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.<br />
<br />
<br />
==Receiver De-emphasis==<br />
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). <br />
<br />
<br />
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.<br />
<br />
<br />
==Transmitter Pre-emhpasis==<br />
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). <br />
<br />
<br />
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. <br />
<br />
<br />
==Level Setting==<br />
Setting the audio levels for the RTCM/VOTER is pretty straight forward. Just follow these steps:<br />
*Ensure you have a connection to your host Asterisk server/chan_voter instance<br />
*Send a 1kHz@3kHz on-channel, full-quieting signal in to the repeater's RX<br />
*Set the RX up so it reads 3kHz deviation on the RTCM's built in console meter<br />
*Now set the TX level '''pot''' to get 3kHz out of the transmitter (No PL)<br />
<br />
<br />
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.<br />
<br />
<br />
If using PL you have to account for that deviation, unless you filter it out with your IFR (test set). <br />
<br />
<br />
That's it!<br />
<br />
<br />
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.<br />
<br />
==== Resolution issues when setting levels using built VOTER boards ====<br />
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).<br />
<br />
==Crappy Transmit Audio==<br />
<br />
Does your repeated audio sounded really bassy, muffled, and not very understandable? <br />
<br />
<br />
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 <br />
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. <br />
<br />
<br />
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!<br />
<br />
<br />
Just enable and set the level to 0. You'll thank me later. <br />
<br />
== Pulse Noise on Transmit Audio ==<br />
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. <br />
<br />
=GPS=<br />
The RTCM/VOTER will work with most GPS available. It requires either NMEA or Trimble TSIP binary data. It only receives data '''from''' the GPS (GPS TX), it does not send anything '''to''' the GPS.<br />
<br />
<br />
The firmware is specifically written to talk to Trimble Thunderbolt receivers using Trimble's TSIP binary data interface, however, other Trimbles GPS receivers that talk TSIP are generally compatible.<br />
<br />
<br />
==NMEA Sentences==<br />
If you are using an NMEA GPS (as opposed to a Trimble using the TSIP binary interface), the RTCM/VOTER is looking for the following NMEA sentences:<br />
<br />
<pre><br />
$GPGGA<br />
$GPGSV<br />
$GPRMC<br />
</pre><br />
<br />
<br />
==GPS Lock==<br />
The GPS led will go solid regardless of the connection LED. That '''has''' to happen or it won't connect to the Asterisk server. <br />
<br />
<br />
It is not unusual for it to take up to 20 mins to get a GPS lock LED (ie. using a Trimble Thunderbolt) after any reboot. <br />
<br />
<br />
==GPS De-sense==<br />
If you are having odd loss of lock issues, consider you may have interference to your GPS antenna from strong RF nearby. A note from Jesse Lloyd:<br />
<br />
<pre><br />
I also had crazy problems with poor signal on my GPS when I set it up sitting in a window, and once installed at site I had the GPS antenna maybe 6 ft from the VHF antenna, and after some troubleshooting found it was getting swamped with RF and loosing lock. <br />
<br />
I found the debug setting of 32 useful in the RTCM, you can see a hex output of the GPS status. <br />
</pre><br />
<br />
<br />
==GPS Issues==<br />
===Trimble Thunderbolt===<br />
You may find your Trimble Thunderbolt is showing the incorrect date at the moment. It could be showing the year as 1997. This is due to the date in the Thunderbolt being reported incorrectly.<br />
<br />
<br />
'''This can cause some of your voting receivers to not connect, if they are used with other GPS in your system.''' If you have '''ALL''' Thunderbolts, or '''NO''' Thunderbolts, you are probably fine. If you have '''ALL''' Thunderbolts, the date/time is probably wrong, but they will ALL be wrong, so they will connect.<br />
<br />
<br />
GPS Time is a continuous counting time scale beginning at the January 5, 1980 to January 6, 1980 midnight. It is split into two parts: a time of week measured in seconds from midnight Sat/Sun and a week number. The time of week is transmitted in an unambiguous manner by the satellites, but only the bottom 10 bits of the week number are transmitted. This means that a receiver will see a week number count that goes up steadily until it reaches 1023 after which it will “roll over” back to zero, before steadily going up again. Such a week rollover will occur approx. every 20 years. The last week rollover occurred in 1999 and the next one will be in 2019.<br />
<br />
<br />
The Thunderbolt manual states:<br />
<pre><br />
The ThunderBolt adjusts for this week rollover by adding 1024 to any week number reported by GPS which is less than week number 936 which began on December 14, 1997. With this technique, the ThunderBolt will provide an accurate translation of GPS week number and TOW to time and date until July 30, 2017.<br />
</pre><br />
<br />
<br />
As such, the Trimble Thunderbolt has a firmware issue with the GPS Week rollover that manifested itself on July 30, 2017, causing the date to become incorrect. The Thunderbolt thinks the week changed from 935 to 936 (actual week 1959-1024=935), so it stopped adding 1024 to the week.<br />
<br />
<br />
We have added a brute-force fix starting in RTCM/VOTER firmware >=1.51. This fix adds 619315200 seconds (1024 weeks) to the time reported by the GPS. It fixes the Thunderbolts, we have not done extensive testing to see how it affects other TSIP receivers.<br />
<br />
===Garmin===<br />
====Garmin 18x LVC Wiring Issues====<br />
If you have issues with your GPS 18x LVC not talking to the RTCM/VOTER, it may not be hooked up to the RTCM correctly. <br />
<br />
<br />
The Garmin pin labeling is backwards to what you may think. See below. You probably need to swap pins 6 and 14.<br />
<br />
<pre><br />
RTCM GPS 18x LVC <br />
6 GRX <-- Rx Data 6 Green <br />
7 GPPS <-- Pulse Output 1 Yellow <br />
8 GND Ground 3 Black <br />
8 GND Ground 5 Black <br />
13 +5V -->Vin 2 Red <br />
14 GTX --> TX Data 4 White<br />
</pre><br />
<br />
<br />
Log into the RTCM and do 98 and you should see something like this:<br />
<br />
<pre><br />
Current Time: Sun Apr 20, 2014 04:37:02.820<br />
Last Rx Pkt System time: 04/20/2014 03:55:35.580, diff: 2487260 msec<br />
Last Rx Pkt Timestamp time: 04/20/2014 03:55:32.064, diff: 3515 msec<br />
Last Rx Pkt index: 160, inbounds: 1<br />
</pre><br />
<br />
<br />
====Garmin and the RTCM====<br />
Beware when buying newer Garmin GPS's to use with the Micro-Node RTCM.<br />
<br />
<br />
The RTCM expects a 5V PPS signal.<br />
<br />
<br />
Newer Garmin's (GPS 18X, 18X LVC, etc.) MAY NOT output 5V, and can cause issues. '''Check the Garmin datasheet'''.<br />
<br />
<br />
The VOTER is designed to accept both 3.3V or 5V signals, and ''should'' work fine.<br />
<br />
* Some of the Garmin GPS's come with 4800 baud set as default. If you are getting a "Warning: GPS Data time period elapsed" error on your RTCM, change both the GPS and RTCM to use 9600 baud. To do this, interface the GPS to a DB9 connector as per page 8 of the [http://wiki.allstarlink.org/w/images/4/41/GPS_18x_Tech_Specs.pdf manual] (remembering to ONLY use 5V as the power source *facepalm*). Once done, download, extract and open [http://www8.garmin.com/support/download_details.jsp?id=4053 SNSRXCFG_330.exe] and run.<br />
# Select your GPS (in most cases GPS 18x PC/LVC). Press F10 to switch to NMEA mode (Config > Switch to NMEA Mode)<br />
# Select Config > Setup and choose the COM port your GPS is connected too. Leave baud rate as auto for now, OK.<br />
# Select Comm > Connect to connect to the GPS. <br />
# Go to Config > Get Configuration from GPS to download it's current configuration<br />
# Click File > Save to save the current configuration<br />
# In Config > Sensor Configuration change the Baud Rate to 9600. You can also check to make sure 1PPS is enabled here too. Click OK. <br />
# Hitting F7 when in the main window of the software also brings up the GPS sentences to output if that is of interest.<br />
# File > Save to a different file than step 5. <br />
# Press F9 or Config > Send Configuration to GPS. This will then send all the changes you made to the GPS unit (including baud rate so a reconnect may be needed)<br />
<br />
<br />
==No GPS/Mixed Mode==<br />
You do not need a timing source to use an RTCM if you don’t want to vote. That’s called Mix Mode.<br />
<br />
<br />
Having the PPS Polarity set to 2 tells the RTCM you do not have a GPS. That forces the RTCM to become a mix (non-voting) client. Turn it on, save it, and restart. A simple voter.conf would look like this:<br />
<br />
<pre><br />
[general]<br />
port = 667<br />
password = BLAH<br />
<br />
[1000]<br />
Site1 = pswrd1,master,transmit<br />
Site2 = pswrd2,transmit<br />
</pre><br />
<br />
<br />
==Mixed Client Error==<br />
"I am getting this error in Asterisk":<br />
<pre><br />
WARNING[2368]: chan_voter.c:4511 voter_reader: Voter client master timing source mobile1 attempting to authenticate as mix client!!<br />
</pre><br />
<br />
<br />
A mixed client error means the voter.conf file is expecting an RTCM to try and connect with a GPS IP packet (ie. has '''master''' in it in voter.conf), but the RTCM isn't <br />
sending a GPS IP packet. So its a mismatch between voter.conf and Option 10 in the RTCM. <br />
<br />
<br />
If you want to use a mix client (non-voted), make sure that receiver's configuration line in voter.conf '''does not''' have the '''master''' option set.<br />
<br />
<br />
==Mix Clients with Voted Client Issues==<br />
<br />
Situation...<br />
"I have a private node with 6 voted receivers using RTCMs. I'd like to add a 7th RTCM to this node that is always mixed in rather than voted. I'm able to make this RTCM work as a 7th voted receiver with no problem. Everything I've read seems to indicate that if I change GPS PPS polarity to "none" this will achieve my desired results, however I am unable to get audio out of my transmit RTCM from this 7th site. It does change color to cyan in Allmon indicating it is non voted input but I do not get any indication or audio when that units COR goes active."<br />
<br />
"Setting voter debug level 3 in Asterisk and I'm seeing the following message repeatedly scrolling by in a blur when the mix client detects COR (COR is active). Sequence numbers are continually incrementing by 1. I'm running software version 1.47 on all my clients:"<br />
<br />
<pre><br />
mix client (Mulaw) my_client index:0 their seq:629 our seq:629<br />
mix client my_client outa bounds, resetting!!<br />
</pre><br />
<br />
If you have a similar situation to the above... check your buflen in voter.conf. Make sure it is at >=160 and see if that fixes it.<br />
<br />
<br />
==GPS Debug==<br />
To turn on GPS Debugging, set the Debug Option Level in the RTCM/VOTER to 32.<br />
<br />
<br />
See [[#Debug Options]] levels for more information on how this works.<br />
<br />
<br />
==Trimble Debug Status Decoding==<br />
The VOTER/RTCM when in TSIP mode (Trimble), assumes it is a Trimble Thunderbolt and is looking for two packets:<br />
*0x8F-AB - Primary Timing Packet<br />
*0x8F-AC - Supplemental Timing Packet<br />
<br />
<br />
Grab a copy of the Thunderbolt User Guide: http://leapsecond.com/pages/tbolt/Thunderbolt-2012-02.pdf<br />
<br />
<br />
Pages 78-83 are the important ones.<br />
<br />
<br />
Packet 0x8F-AB is what grabs the timing information, and packet 0x8F-AC is what it looks at for everything else (including debug).<br />
<br />
<br />
The debug string that the VOTER/RTCM reports:<br />
<br />
<pre><br />
printf("GPS-DEBUG: TSIP: ok %d, 9 - 14: %02x %02x %02x %02x %02x %02x\n",<br />
happy,gps_buf[9],gps_buf[10],gps_buf[11],gps_buf[12],gps_buf[13],gps_buf[14]);<br />
</pre><br />
<br />
<br />
So, the 1 after ok is the "happy gps" flag. The other 5 bytes are supposed to be bytes 9-14 from the packet... sort of. They are bytes 9-14 of the buffer, but they are actually bytes 8-13 of the binary message.<br />
<br />
<br />
Looking at the message structure, bytes 8-13 are:<br />
*8-9 Critical Alarms<br />
*10-11 Minor Alarms<br />
*12 GPS Decoding Status<br />
*13 Disciplining Activity<br />
<br />
<br />
Therefore, the messages you are seeing break down as follows:<br />
<br />
<pre><br />
GPS-DEBUG: TSIP: ok 1, 9 - 14: 00 00 00 00 00 00 - everything is good in the 'hood, Doing Fixes, Phase Locking<br />
<br />
GPS-DEBUG: TSIP: ok 0, 9 - 14: 00 00 00 18 08 06 - not happy, Not Tracking Satellites, Not Disciplining Oscillator (0x18 --> 0b000000011000), No Usable Sats, Inactive<br />
<br />
GPS-DEBUG: TSIP: ok 0, 9 - 14: 00 00 00 08 08 05 - not happy, Not Tracking Satellites, No Useable Sats, Compensating OXCO (holdover)<br />
<br />
GPS-DEBUG: TSIP: ok 0, 9 - 14: 00 00 00 00 00 05 - not happy, Compensating OXCO (holdover)<br />
<br />
GPS-DEBUG: TSIP: ok 1, 9 - 14: 00 00 00 00 00 08 - happy, Recovery Mode<br />
<br />
GPS-DEBUG: TSIP: ok 0, 9 - 14: 00 00 00 00 00 04 - not happy, Initializing Loop Filter<br />
</pre><br />
<br />
<br />
The GPS is flagged as NOT HAPPY in TSIP mode if ANY of the following are TRUE:<br />
*If GPS Decoding Status is anything other than "Doing Fixes".<br />
*If Disciplining Activity is not Phase Locking or Recovery Mode.<br />
*Any Critical Alarms.<br />
*Any Minor Alarms.<br />
<br />
<br />
=Ubiquity ToS=<br />
See https://help.ubnt.com/hc/en-us/articles/205231750-airMAX-How-is-QoS-and-prioritization-handled-by-airMAX-<br />
<br />
<br />
So, if we set ToS/DSCP in the header to C0, then Ubiquity (and other gear watching ToS) ''should'' prioritize the packets. This sets the DSCP to 110 000 aka 48. UBNT shows this as 802.1p Class 6 (Voice <10mS latency). Other sources show this as a Network Control TOS.<br />
<br />
<br />
There is an option in voter.conf to turn this on (utos=y). However, this only controls packets being sent from Asterisk '''TO''' the RTCM. <br />
<br />
<br />
If you want to tag packets from the RTCM '''TO''' Asterisk, you need to set the RTCM debug option level to 16 (see [[#Debug Options]] for how this works).<br />
<br />
<br />
At some point we should probably change the default behaviour of the RTCM firmware to mark the packets and use the debug setting to '''disable''' ToS. That change (if you wanted to compile your own firmware) would be:<br />
<br />
<pre><br />
Change line 90 in IP.c<br />
<br />
From:<br />
#define IP_SERVICE ((AppConfig.DebugLevel & 16) ? 0xc0 : (IP_SERVICE_ROUTINE | IP_SERVICE_N_DELAY))<br />
<br />
To:<br />
#define IP_SERVICE ((AppConfig.DebugLevel & 16) ? (IP_SERVICE_ROUTINE | IP_SERVICE_N_DELAY) : 0xc0)<br />
</pre><br />
<br />
<br />
This changes the conditional expression from if the debug level is 16 to mark the packets with DSCP 48 to if the debug level is 16, mark the packets routine (DSCP 0).<br />
<br />
<br />
=RTCM Simulcasting=<br />
The RTCM/VOTER boards do support simulcasting, however, there are a bunch of quirks that one needs to be aware of.<br />
<br />
<br />
==Radio Hardware==<br />
For best results, you should use all identical RF equipment between your voting RX sites and simulcast TX sites. If you don't, you can end up with strange audio artifacts when different receivers are used, and other strange audio issues when different transmitters are used. The most important thing when setting your levels is that ALL the RX and TX levels match from radio to radio. The best way this is achieved is using a "master" radio and reference from that - all radios might be identical models, but may not have identical audio characteristics so check those levels! Also check CTCSS and audio levels separately to make sure they all match.<br />
<br />
<br />
==9.6MHz Oscillator==<br />
If you want reliable simulcast with an acceptable level of overlap warble, you MUST inject a GPS-disciplined or OXCO 9.6MHz signal to the clock of the RTCM's, in lieu of their stock internal crystal. <br />
<br />
<br />
Otherwise, the inherent internal clock jitter of the RTCM's will cause CTCSS warble, etc. in areas where your transmitters overlap. The 1 PPS feed that you normally feed the RTCM's is acceptable for voting, but naturally, a typical crystal-driven clock will slightly drift in between the pulses every second due to inherent jitter, etc., and that ain't to good for situations like simulcast which demand sample-accurate performance.<br />
<br />
<br />
Here are some comments from Joe, KC2IRV, on the subject. He has also created his own wiki, specific to simulcast issues, you can find it at: http://rtcmsimulcast.wikifoundry.com/ <br />
<br />
:I felt I needed to let those on this mailing list know my findings with simulcasting with the RTCM units since I have received a great deal of help and information from people on this list.<br />
<br />
:For the past week I have had a two (2) site simulcast system up and running on UHF using the RTCM units. I have done a great deal of testing and proving on the bench and it is so far working beautifully. <br />
<br />
:The one issue that was made apparent to me early on was that in order for the RTCM's to be suitable for simulcast, the processor inside it needed to be clocked to a more accurate source. This source is supposed to be the Programmable Clock Generator Module in order to produce a GPS locked 9.6 MHz reference for the processor. Unfortunately this unit is not currently available.<br />
<br />
:Knowing this, I started to go down the road of possibly designing my own, but stumbled upon a cheap, plentiful supply of Symmetricom 9.6 MHz sinewave OCXO's. I took a chance and ordered a few to experiment with to see if the RTCM would be able to use this in place of the supplied crystal for a clock. I found they did, with that I decided to modify the RTCM with an SMA connector just above the audio adjustment pots and use this OCXO. I trimmed the frequency on the units to match each other and used them to produce the processor clock.<br />
<br />
:After a week of testing, I have found the results in the overlap areas to be exactly as I would expect them on a public safety/commercial simulcast system. While in an overlap region where both transmitters are within 3dB of one another, to the ear you hear no audio phase wandering. Of course , this has only been a week of testing so I wouldn't call it case closed yet.<br />
<br />
:I will say that if this system remains this way after testing for 6 months to a year than using a 9.6 MHz OXCO is a viable alternative to achieve the needed precision and accuracy needed for the processor clock to make it suitable for simulcast.<br />
<br />
<br />
Comments from Jim Dixon on the issue:<br />
<br />
:You have to use '''something''' that will take the precise 10MHz (or whatever it is) from the GPSDO and PLL (phase-locked) convert it to 9.6MHz (square wave at 3.3V for the CPU clock).<br />
<br />
:We had to use 9.6MHz mainly because of the DAC in the dsPIC instead of 10MHz. The options for various divide/clock radios in the part are RATHER limited. As I recall, there wasn't even a way of getting the necessary 16kb/s sample rate on the ADC from 10MHZ, either.<br />
<br />
<br />
=Micro-Node RTCM Clock Issue=<br />
James, KI0KN, had some strange-ness with some of his RTCM's when used for voting. As soon as he changed menu item 10 on the RTCM to either a (1) or a (0) instead of (2), he '''instantly''' got this on the RTCM console:<br />
<br />
<pre><br />
04/05/2016 18:44:13.660 Lost GPS Time synchronization<br />
04/05/2016 18:44:13.660 Host Connection Lost (Pri) (10.16.1.240)<br />
</pre><br />
<br />
<br />
And it sits there forever and never re-establishes connection to the host. The issue was finally traced to a bad batch of 9.6MHz crystals that affected a small run of the RTCM's. The issue was eventually resolved by Micro-Node, but we'll document it here just for record keeping.<br />
<br />
<br />
James comments to the list:<br />
<br />
:Well, after many of you offered your time and thoughts on my voter problem, Jim, WB6NIL, graciously donated a couple of hours of his time to remotely help me and he uncovered the problem.<br />
<br />
:All 5 of my RTCMs were purchased within the last 6 months, and I suspect all 5 have the same problem (will verify that today). The problem is that the microprocessor crystal is running too fast! There is 9.6Mhz crystal that drives the MPU, on the particular unit that Jim helped me diagnose, it's running 2.5 khz too fast. <br />
<br />
:There is a sanity check in the firmware that makes sure the correct number of samples were taken in the last second (it's supposed to be 8000) and fails if the sample is incorrectly sized (mine is taking 8003 samples). Jim helped adjust the code to be more tolerant of the sampling error and my whole system instantly worked.<br />
<br />
:I have since tested it with ALL my GPSs (they all work great!). So I now have everything working, including the voting.<br />
<br />
:I haven't contact Micro-Node about it yet. Jim told me that voting should work fine but this clock error would probably not be acceptable for Simulcast (something we have no plans on doing as of now). Since mine are deployed at mountain top sites, I'll probably pursue a crystal that is running at the correct frequency and use "standard" firmware so that if the decision is ever made to play with simulcast, I won't be right back in this same boat.<br />
<br />
:Thanks to all that helped out, and a HUGE thanks to Jim for taking the time to troubleshoot this.<br />
<br />
:BTW- This clock error will NOT effect the RTCM in mix client mode, it only affects it in voting or simulcast mode!<br />
<br />
:In voter.c, the stock line is:<br />
<pre><br />
if ((samplecnt >= 7999) && (samplecnt <= 8001))<br />
<br />
it needs to be changed to something like:<br />
<br />
if ((samplecnt >= 7999) && (samplecnt <= 8003 ))<br />
</pre><br />
<br />
:That was just enough to make my first RTCM work. I've had a chance now to check a few more of my RTCMs on the bench this morning and the crystal frequencies are kind of all over. The next one I had on the bench was 5.2Khz fast. The above code was still not enough to fix it (as would be expected) so it looks like the quality control on whatever manufacturer that crystal is, isn't very good (or a low tolerance crystal is being used). I am going to pursue crystal replacement to get a highly accurate, stable, on-frequency crystal in there as my first choice. Changing the firmware 5 different times doesn't seem like the right answer.<br />
<br />
:Jim put that sanity check in there for a reason. Working around it '''may''' allow the device to work, but to me, it seems getting the hardware operating the way it was supposed to originally is the better answer. I will follow up with Micro-node and let you all know how it goes.<br />
<br />
<br />
After following up with Micro-Node:<br />
:They were all off, some were off a LOT. I talked to Mark @ Micronode. He told me there were 25 units that made it out the door with a crystal from an unapproved source and that was quite likely the reason for the problem. He gladly sent me 5 new crystals to replace (he offered to replace them himself if I sent the units in, but I am comfortable doing it myself to save the time and postage). <br />
<br />
:I haven't received them in the mail yet to show that the problem is fixed, but I will post here when that happens. He was great to work with and had no issue getting things set straight. If you are having the same issue and your RTCMs were bought about the same time, I'd suggest you contact him and have him help you resolve the issue!<br />
<br />
<br />
=Duplex Mode 3=<br />
Does delayed repeat audio bug you? Tired of hearing a bit of yourself after you unkey? Wish you could talk full duplex? Hate the echo chamber effect? Then we have the answer for you.<br />
<br />
<br />
Duplex Mode 3 in app_rpt allows for "in-cabinet repeat" (where the radio hardware provides repeat audio) and app_rpt adds the hang time, courtesy tones, linking - all the <br />
things apt_rpt does sans repeat audio. Therefore no repeat audio delay. Cool, eh? This duplex mode has been in app_rpt for a while. Problem has been how to implement it in the RTCM environment. <br />
<br />
<br />
Duplex Mode 3 support in the RTCM provides in-cabinet repeat functionality. Repeat audio loops through the RTCM and has almost zero delay because it does not have to traverse the network. The delay is not quite zero but it's plenty short enough to eliminate all of the above mentioned annoyances. <br />
<br />
<br />
Of course Duplex Mode 3 support can't be used with voting or simulcast. You also loose Touch Tone muting, Time Out Timer and Repeater Disable functions because the repeat path is not through app_rpt.<br />
<br />
= Setting Voter Buffers =<br />
Voter ping is useful for end-to-end network evaluation when ICMP ping is turned off and/or the RTCM is behind a firewall and is not ICMP reachable. It can also help with finding the correct RTCM and voter.conf buffer settings.<br />
<br />
=== Voter Ping Usage ===<br />
The voter ping asterisk CLI syntax is:<br />
*CLI>voter ping nameOfClient [packetCount]<br />
If packetCount is not specified 8 pings will be sent. Use packetCount of 0 to stop an in progress voter ping. Set packetCount to at least 100 when evaluating link quality.<br />
<br />
The result will be similar to:<br />
...<br />
PING (nameOfClient): Packets tx: 100, rx: 100, oos: 0, Avg.: 26.710 ms<br />
PING (nameOfClient): Worst: 38 ms, Best: 22 ms, 100.0% Packets successfully received (0.0% loss)<br />
The output above is self evident except for oos which is a count of out of sequence packets. Voter ping requires RTCM firmware 1.23 or newer and chan_voter 2013-08-04 or newer.<br />
<br />
=== RX Buffer Size ===<br />
Ping all the receiver sites and look for the worst response of the worst client. As a rough rule of thumb the buflen setting in voter.conf should be set to the worst response + 40ms or 120 whichever is greater. Using the above case the buflen should be set to 120 (38+40<br />
<br />
=== TX Buffer Size ===<br />
Ping all the transmitter sites and look for the worst response of the worst client. The RTCM TX Buffer Length should be set to (worst response + 40ms) * 8 or 480 whichever is greater. Using the above case the RTCM TX Buffer Length should be set to 624 ((38+40)*8).<br />
<br />
=== Assumptions ===<br />
* The minimum TX buffer size is 480 (60ms) and the minimum RX buffer is 120ms. These were derived by testing on a LAN segment with chan_voter 2013-08-04 and RTCM 1.26.<br />
* The ping times are not round trip times but they are in fact round trip times. Therefore the worst response could (should?) be divided by 2. Ie RX buffer = 38/2+40=59 and TX buffer = (38/2 + 40) * 8 = 472. Minimums still apply.<br />
* The internet path to and from the RTCM under test is symmetrical.<br />
* The added 40ms pad is an estimate of buffer ingress and egress.<br />
As always your milage may vary. Some trial and error may be required to find the optimum settings.<br />
<br />
=== Setup ===<br />
The RX buffer is set with buflen=120 in /etc/asterisk/voter.conf. The value is in milliseconds. The TX buffer is set in the RTCM with menu item 7. The value is in 125 microsecond increments. To match the size of the TX to the RX buffer, use the RX buffer * 8 to get the TX buffer size.<br />
[[Category:How to]]<br />
[[Category:Node Configuration]]</div>W3KKChttps://wiki.pttlink.org/index.php?title=ASLCorporate:The_Beginning_-_AllStarLink_Inc&diff=1442ASLCorporate:The Beginning - AllStarLink Inc2019-08-04T16:09:29Z<p>W3KKC: /* How AllStarLink, Inc got Started */</p>
<hr />
<div>==How AllStarLink, Inc got Started==<br />
By: Kevin Custer W3KKC<br />
<br />
Jim Dixon WB6NIL was one of the smartest people I've ever met. He is responsible for app_rpt and many aspects of Asterisk®, a software based Public Branch Exchange for the telephony industry. Early on, Jim realized that Asterisk could be the basis of a powerful multi-port repeater controller, and wrote code to support that functionality. Jim also invented AllStar Link, a network of publicly-accessible amateur radio repeater and remote base stations which can connect to each other via Voice Over IP (VoIP) on the Internet. Jim had help with the website, approving new members, issuing node numbers, etc., however, writing code and doing updates and bug fixes was primarily his job. All of that was lost in December of 2016 with his unexpected death.<br />
<br />
When Jim passed away, Steve Rodgers WA6ZFT, the co-inventor of AllStar, reached out to a few people who he knew contributed to the project. I am one of those people. Steve Rodgers had too much on his plate to continue AllStar as Jim did, and wanted help, and a clear path to a successor. I told Steve that I would continue to do all that I could to help. In a phone conversation, Steve asked me if I could recommend anyone for taking over AllStar Link. <br />
<br />
I recommended Steve Zingman N4IRS. He and his brother Mike N4IRI are responsible for DIAL. DIAL was the last official release of AllStar under Jim. Steve Rodgers ultimately chose Steve Zingman to be the successor, and I agreed to provide financial support. Steve Zingman's immediate task was assembling more people to support the project.<br />
<br />
He reached out to Tim Sawyer WA6AWP, as he was solely responsible for the website, vetting new members and assigning node numbers. Tim is also the developer of Allmon and Allmon2; the AllStar Monitor and Control Panel. Tim accepted Steve's invitation, and has been a large part of the project ever since. <br />
<br />
Steve also invited Bryan Fields W9CR because of his knowledge of servers and networking, among many others. Bryan has dealt with the "behind the scenes" architecture since then. <br />
<br />
These five individuals carried the project along for many months. Steve Zingman set many goals; the biggest one was - - this project will no longer be the responsibility of one person. Since then, the group has gathered together many talented people for the admin and development teams. ASL 1.01 was released with new features like selectable audio filtering, and a new menu driven setup system. AllStarLink is an Incorporated Florida non-profit entity, with 501(C)3 status. There is a stable Board of Directors, and now over a dozen people helping with the project. The AllStar Link Network is stable, growing, and will be for years to come. We will continue to move forward with our goal of preserving the product and vision of Jim Dixon.</div>W3KKChttps://wiki.pttlink.org/index.php?title=ASLCorporate:The_Organization_-_AllStarLink_Inc.&diff=1441ASLCorporate:The Organization - AllStarLink Inc.2019-08-04T16:07:02Z<p>W3KKC: Updated the status of the non-profit - and the date in which we were granted that status.</p>
<hr />
<div><br />
With the release of All Star Link 1.01, AllStarLink, Inc. is happy to announce some organizational improvements. In the time since Jim Dixon's passing we have not only made much progress on keeping the services running, but improving the availability of the ASL core services. On the organizational front we have incorporated as a 501(C)3 non-profit devoted to running the All Star network and shepherding the development of app_rpt and asterisk for amateur radio.<br />
<br />
<br />
AllStarLink, Inc. was formed as a Florida non-profit with the goals of continuing Jim's vision for enhancing communications between amateurs around the world. We obtained that status on Dec 13, 2018 enabling all donations to be tax-deductible, and to show good stewardship of our supporters funds. We've segmented operations into two parts, one of running/improving network services, and the larger group doing development.<br />
<br />
<br />
The development team is focused on improving on the codebase and updating asterisk and app_rpt. Over the next year we intend to move to a more recent version of asterisk, if not the current version. This will enable much needed updates for security and new network protocols.<br />
<br />
<br />
The dev team is always looking for skilled coders (mostly C for app_rpt) who can devote time and help out. The main codebase is on [https://github.com/AllStarLink GitHub]<ref>AllStarLink GitHub Repository [https://github.com/AllStarLink]</ref> and patches are always encouraged.<br />
<br />
<br />
Our [[Admin Committee|admin team]] is responsible for all infrastructure which keeps the network talking, such as:<br />
Distributed registration service, [http://stats.allstarlink.org stats server], [https://web-tpa.allstarlink.org user portal], DNS, [http://lists.allstarlink.org email], GitHub, and backend database and backup servers.<br />
<br />
<br />
A [https://web-tpa.allstarlink.org/ new user portal]<ref>https://web-tpa.allstarlink.org</ref> has been under development and will go live once it's ready. This is no small development, there are many moving parts to the backend of ASL, and the portal ties all that together.<br />
<br />
<br />
Everyone should notice the new look to the stats server and the enhanced maps. The maps server receives about 200 updates per second from connected nodes and it's been moved to much beefier server equipped to handle the load. Under the hood we've been moving to docker for all services.<br />
<br />
<br />
The admin team also verifies all new users and handles the day to day operations. The documentation is for most of the backend API's is in the wiki and many of the docs from [http://docs.allstarlink.org docs.allstarlink.org] have been moved to the [[Main Page|wiki]]. The eventual goal is to shut off docs.allstarlink.org and only support the wiki. Wiki's are awesome as user-base can bug-fix the docs then and there. The team is always looking for assistance with documentation; some knowledge of wiki or a desire to learn it is required.<br />
<br />
<br />
The board is seeking those who share Jim's vision and commitment to Open Source and have some managerial experience to join us on the board. AllStarLink need those with drive and commitment to run the non-profit side of things.<br />
<br />
<br />
For AllStarLink, Inc:<br />
<br />
<center><br />
{| class="wikitable" style="text-align: left; width: 85%"<br />
|+ AllStarLink, Inc Personnel<br />
! style="width: 150px;" | Chairman Emeritus<br />
| style="width: 170px" | Jim Dixon, WB6NIL (SK)<br />
| Visionary, Open Source advocate and principal developer of app_rpt, aka AllStar. <br />
|-<br />
! rowspan="4" |Directors<br />
| Kevin Custer, W3KKC<br />
| Kevin is the founder of repeater-builder.com and is active with the WAN repeater system.<br />
|-<br />
| Tim Sawyer, WD6AWP<br />
| Tim is a repeater owner and the developer of Allmon.<br />
|-<br />
| Pete Elke, WI6H<br />
| Pete brings management skills to the board.<br />
|-<br />
| Todd Lesser, KM6RPT<br />
| Todd was part of the development team on the Zapata Telephony project that created the Allstar technology.<br />
|-<br />
! Treasurer<br />
| Dave Shaw, WB6WTM<br />
| Dave has been a Director and Treasurer for NARCC (The Northern California Repeater Coordination Council). <br />
|}<br />
</center><br />
<br />
==External Links==<br />
<references /></div>W3KKChttps://wiki.pttlink.org/index.php?title=Radio_Connections&diff=1438Radio Connections2019-07-26T02:52:29Z<p>W3KKC: /* RA-40 / RA-35 */</p>
<hr />
<div>Instructions for connecting radios, repeaters and AllStarLink interfaces including the RTCM, GPS, URI/URI X and like devices. <br />
<br />
<br />
=GPS=<br />
* [[Media:RTCM 2 Trimble.pdf|Trimble RTCM Interface Cable]]<br />
* [[Media:RTCM 321 Cable.graffle.pdf|Trimble to Two RTCMs and Lady Heather Cable]]<br />
* [[Media:RTCM to BG7TBL Cable.pdf|BG7TBL GPS / RTCM Cable]]<br />
<br />
=Motorola=<br />
<br />
==CDM==<br />
CDMs make great nodes. This eBay reseller has very nice cables. Use to connect to URI or RTCM. <br />
<br />
[[Media:CDM Cable.pdf|CDM Cable from Kurt Meltzer]] ex-WB9KNX, now KC4NX - Cable 83 has only one output to use for either COS or CTCSS. Use another cable if you need both COS and CTCSS.<br />
<br />
==Maxtrac==<br />
The venerable Maxtrac is a radio that was very well built, apparently has very stable reference LO, and can take a beating. When aligned properly, and sufficient *vectored* cooling is made, this radio will last for a very long, time even under several hours with of transmitting per day.<br />
<br />
The radio will need to be aligned, and programmed to the frequenc(y/ies) you want to use. You will also need to program the Accessory Option for PL/DPL & CSQ Output.<br />
* Most URIs can accept active high or active low for valid RX signal detection, ie, open squelch. It is HIGHLY recommend in any situation COS is set to USB or active high. This will prevent issues. Too many to mention.<br />
* It is a good idea to program pin 8 on the Maxtrac/GM300 for PL/DPL & CSQ output, active high. This will cause the radio to emit a 5Vdc signal when the squelch is open, and go low when squelch is closed.<br />
<br />
===TX/RX audio, COS, and PTT connections===<br />
With the radio facing you in normal operating positing, volume knob on top left, and mic connection right below it, turn the radio over from the right side. The accessory connector is located on the rear, right top of the radio at this point. Starting from left to right, the pins on the top are / and the pins on the bottom are /. If you want to hear audio from the radios speaker, just a header jumper on the far right pins 15 and 16.<br />
<br />
<br />
This section is a work in progress. <br />
<br />
References:<br />
The GM300 section has the link for further reading; the Maxtrac and GM300, are relatively close in design.<br />
<br />
==MTR-2000==<br />
<br />
==Quantar==<br />
<br />
The Quantar can be tricky to interface as it's extremely programmable and you will need a wireline card for I/O connections. By default the I/O will not work unless the "wildcard" table is programed. This wildcard table is Boolean logic of interrupt states in the radio, is extremely flexible and frustrating to debug. It's a base station in it's own class.<br />
<br />
[[File:Front of quantar and controller.jpg|thumb|400px|right|Front of Quantar and controller]]<br />
<br />
* [[Media:QUANTAR-RTCM INTERFACE CABLE.pdf|Quantar/RTCM Interface Cable]]<br />
<br />
Note you will want to use [[RTCM_Client#DSP.2FBEW_Firmware_Version|BEW mode]] on the RTCM if using the RTCM do squelch.<br />
<br />
* [[Media:RTCM 2 Quantar.pdf|Another Quantar/RTCM Interface Cable]]<br />
* [[Media:RTCM to Astro-TAC Cable.pdf|Astro-TAC/RTCM Interface Cable]]<br />
* [http://wiki.w9cr.net/index.php/Allstar_and_P25_on_Quantar Interfacing to a Quantar with P25NX] - Bryan Fields W9CR has page on interfacing the Qunatar using simple USB into Allstar and P25NX linking at the same time. This is driven by programing on the Quantar Wildcard tables.<br />
*[[Media:Quantar URI Interface.jpg|Quantar/URI Cable]]<br />
*[[Media:QuantarMRTI2URI.jpg|Quantar MRTI/URI Cable]]<br />
<br />
==Syntor X==<br />
The Motorola Syntor X with an Xcat installed makes a great frequency agile remote base. For more information see this [http://wd6awp.net/xcat/ Syntor Xcat] page. <br />
<br />
==VRM-850==<br />
<br />
==GM300==<br />
These older radios are fairly common and easily to come by due to the narrow banding. Probably the hardest part is finding a computer and the RSS to program them. The Gm300 family has many different configurations, from low band VHF, to 800 Mhz. But the easiest variant of the GM300 is ones with the 16 pin connector.<br />
[http://www.repeater-builder.com/motorola/maxtrac/maxtrac-index.html All about GM300 Radios] <br />
<br />
Connections are fairly simple but can be hard to determine which is the correct one to use. This [http://www.repeater-builder.com/motorola/maxtrac/maxtrac-option-plug.html link] is a good place to start.<br />
<br />
=Kenwood=<br />
==TKR720/820==<br />
Connections to: PTT, COS, RX audio out and MIC audio in<br />
<br />
TX/RX board, MIC audio input, pins 4 & 5: floating ground, must not tie to any other ground! Some installations may require a 10dB, resistor L-network consisting of a 4.7k and 470 ohm resistors. The 470 ohm resistor connection across pins four and five, the 4.7k resistor is soldered to pin 5 to which your TX audio from the URI will connect to.<br />
<br />
The MIC audio gain, deviation, and balance adjustments are *very* sensitive! <br />
<br />
- RA-35 without TX adj. trimmer pots: Using a service monitor with deviation metering, start low and work your way up to 3KHz deviation with 1KHz tone, generated by simpleusb-tune-menu. If enabled, *904 turns this tone on and off by command, ie, no tone time-out as in simpleusb-tune-menu.<br />
<br />
== TKR750/850 ==<br />
[http://www.masterscommunications.com/products/radio-adapter/txt/tkr.txt Using the Masters Communications RA-35 or RA-40 radio adapters with the TKR750/850]<br />
<br />
=Repeater Controller=<br />
<br />
[[Media:RTCMwithController.pdf|An example of using RTCMs to replace 420 links]]<br />
<br />
=Spectra Engineering=<br />
* [http://wiki.w9cr.net/index.php/MX800#W9CR_alignment_procedure_and_setup_with_Allstar MX800 Base station] - Bryan Fields, W9CR has a complete setup guide for the MX800 Base station which includes fallback to the built in controller and an audio delay module.<br />
<br />
=Tait=<br />
<br />
=Beagle Board=<br />
The Beagle Board XM project.<br />
* [http://beagleboard.org/BeagleBoard-xM BeagleBoard-xM]<br />
<br />
=Lox board=<br />
The Level One eXpansion board.<br />
* [http://www.dmkeng.com/LOX_Order_Page.htm LOX Board] <br />
<br />
=URI / URI X=<br />
The URI is manufactured and sold by [http://dmkeng.com/URI_Order_Page.htm DMK Engineering]. <br />
*[[Media:URI Schematic.pdf|URI Schematic]]<br />
*[[Media:URIx Schematic.pdf|URI X Schematic]]<br />
<br />
=Masters Communications RA-Series Radio Adapters=<br />
Inexpensive but feature rich USB Radio Adapters for AllStar Link.<br />
<br />
* [http://www.masterscommunications.com/products/radio-adapter/ra25.html RA-25]<br />
* [http://www.masterscommunications.com/products/radio-adapter/ra30.html RA-30]<br />
* [http://www.masterscommunications.com/products/radio-adapter/ra35.html RA-35]<br />
<br />
*[http://www.masterscommunications.com/products/radio-adapter/ra40.html RA-40]<br />
*[http://www.masterscommunications.com/products/radio-adapter/ra42.html RA-42]<br />
*[http://www.masterscommunications.com/products/radio-adapter/radr1x.html RA-DR1X]<br />
*[http://www.masterscommunications.com/products/radio-adapter/racase.html RA-Case]<br />
<br />
=Vertex=<br />
* [[Media:RTCM 2 VRX-5000.pdf|VRX-5000 / RTCM Interface Cable]]<br />
<br />
=Quad Radio PCI card=<br />
*[[:File:Ft897 quadpci schematic.pdf|Yaesu FT-897 HF Radio(pdf)]]<br />
<br />
*[[:File:Ic706 quadpci schematic.pdf|Icom IC-706 HF Radio(pdf)]]<br />
<br />
*[[:File:Tmg707 quadpci schematic.pdf|Kenwood TMG-707 Dual Band FM mobile Radio(pdf)]]<br />
<br />
=Modified USB FOB=<br />
*[[:File:Usb2tmg707.pdf|Kenwood TMG-707 Dual Band FM mobile Radio(pdf)]]<br />
[[Category:How to]]</div>W3KKChttps://wiki.pttlink.org/index.php?title=ASLCorporate:The_Beginning_-_AllStarLink_Inc&diff=1331ASLCorporate:The Beginning - AllStarLink Inc2019-01-28T15:29:51Z<p>W3KKC: /* How AllStarLink, Inc got Started */</p>
<hr />
<div>==How AllStarLink, Inc got Started==<br />
By: Kevin Custer W3KKC<br />
<br />
Jim Dixon WB6NIL was one of the smartest people I've ever met. He is responsible for app_rpt and many aspects of Asterisk®, a software based Public Branch Exchange for the telephony industry. Early on, Jim realized that Asterisk could be the basis of a powerful multi-port repeater controller, and wrote code to support that functionality. Jim also invented AllStar Link, a network of publicly-accessible amateur radio repeater and remote base stations which can connect to each other via Voice Over IP (VoIP) on the Internet. Jim had help with the website, approving new members, issuing node numbers, etc., however, writing code and doing updates and bug fixes was primarily his job. All of that was lost in December of 2016 with his unexpected death.<br />
<br />
When Jim passed away, Steve Rodgers WA6ZFT, the co-inventor of AllStar, reached out to a few people who he knew contributed to the project. I am one of those people. Steve Rodgers had too much on his plate to continue AllStar as Jim did, and wanted help, and a clear path to a successor. I told Steve that I would continue to do all that I could to help. In a phone conversation, Steve asked me if I could recommend anyone for taking over AllStar Link. <br />
<br />
I recommended Steve Zingman N4IRS. He and his brother Mike N4IRI are responsible for DIAL. DIAL was the last official release of AllStar under Jim. Steve Rodgers ultimately chose Steve Zingman to be the successor, and I agreed to provide financial support. Steve Zingman's immediate task was assembling more people to support the project.<br />
<br />
He reached out to Tim Sawyer WA6AWP, as he was solely responsible for the website, vetting new members and assigning node numbers. Tim is also the developer of Allmon and Allmon2; the AllStar Monitor and Control Panel. Tim accepted Steve's invitation, and has been a large part of the project ever since. <br />
<br />
Steve also invited Bryan Fields W9CR because of his knowledge of servers and networking, among many others. Bryan has dealt with the "behind the scenes" architecture since then. <br />
<br />
These five individuals carried the project along for many months. Steve Zingman set many goals; the biggest one was - - this project will no longer be the responsibility of one person. Since then, the group has gathered together many talented people for the admin and development teams. ASL 1.01 was released with new features like selectable audio filtering, and a new menu driven setup system. AllStarLink is an Incorporated Florida non-profit entity, currently waiting for 501(C)3 status. There is a stable Board of Directors, and now over a dozen people helping with the project. The AllStar Link Network is stable, growing, and will be for years to come. We will continue to move forward with our goal of preserving the product and vision of Jim Dixon.</div>W3KKChttps://wiki.pttlink.org/index.php?title=ASLCorporate:The_Organization_-_AllStarLink_Inc.&diff=989ASLCorporate:The Organization - AllStarLink Inc.2018-06-03T22:29:28Z<p>W3KKC: Remove Steve - Add Pete</p>
<hr />
<div>Admin team announcement:<br />
<br />
<br />
With the release of All Star Link 1.01, AllStarLink, Inc. is happy to announce some organizational improvements. In the time since Jim Dixon's passing we have not only made much progress on keeping the services running, but improving the availability of the ASL core services. On the organizational front we have incorporated as a non-for-profit devoted to running the All Star network and shepherding the development of app_rpt and asterisk for amateur radio.<br />
<br />
<br />
AllStarLink, Inc. was formed as a Florida non-for-profit with the goals of continuing Jim's vision for enhancing communications between amateurs around the world. We're in the process of attaining 501(c)3 enabling all donations to be tax-deductible, and to show good stewardship of our supporters funds. We've segmented operations into two parts, one of running/improving network services, and the larger group doing development.<br />
<br />
<br />
The development team is focused on improving on the codebase and updating asterisk and app_rpt. Over the next year we intend to move to a more recent version of asterisk, if not the current version. This will enable much needed updates for security and new network protocols.<br />
<br />
<br />
The dev team is always looking for skilled coders (mostly C for app_rpt) who can devote time and help out. The main codebase is on github <https://github.com/AllStarLink/> and patches are always encouraged.<br />
<br />
<br />
Our admin team is responsible for all infrastructure which keeps the network talking, such as:<br />
Distributed registration service, Stats server, User portal, DNS, Email, GitHub, and Backend database and backup servers.<br />
<br />
<br />
A new user portal has been under development on <https://allstar.aargdmr.net/> and will go live once it's ready. This is no small development, there are many moving parts to the backend of ASL, and the portal ties all that together.<br />
<br />
<br />
Everyone should notice the new look to the stats server and the enhanced maps. The maps server receives about 200 updates per second from connected nodes and it's been moved to much beefier server equipped to handle the load. Under the hood we've been moving to docker for all services.<br />
<br />
<br />
The admin team also verifies all new users and handles the day to day operations. The documentation is for most of the backend API's is in the wiki and many of the docs from docs.allstarlink.org have been moved to the wiki. The eventual goal is to shut off docs.allstarlink.org and only suppor the wiki. Wiki's are awesome as userbase can bugfix the docs then and there. The team is always looking for assistance with documentation; some knowledge of wiki or a desire to learn it is required.<br />
<br />
<br />
The board is seeking those who share Jim's vision and commitment to Open Source and have some managerial experience to join us on the board. AllStarLink need those with drive and commitment to run the non-profit side of things. We're actively seeking a treasurer (US person) and would like to at least double the size of the board.<br />
<br />
<br />
For AllStarLink, Inc:<br />
<br />
Chairman Emeritus:<br />
<br />
Jim Dixon, WB6NIL<br />
<br />
<br />
Directors:<br />
<br />
Pete Elke, WI6H<br />
<br />
Tim Sawyer, WD6AWP<br />
<br />
Bryan Fields, W9CR<br />
<br />
Kevin Custer, W3KKC</div>W3KKChttps://wiki.pttlink.org/index.php?title=Audio_Filters&diff=940Audio Filters2018-04-23T00:41:47Z<p>W3KKC: Switched the images.</p>
<hr />
<div>= Audio Filters =<br />
<br />
The release of AllStarLink 1.01 software package contains a feature pioneered by Jeff DePolo, WN3A. It is a set of audio filters for amateur radio applications. <br />
<br />
The default transmit and receive filters were designed around commercial standards. However, because amateur radio operators have the resources to use wider bandwidths, especially on UHF, they may prefer other filter types in order to provide higher audio quality. Over the years there have been other fixes for the [[Usbradio.conf|usbradio]] channel driver minimizing the distortions. The results below proves the distortions are considerably lower than what a typical radio/repeater will add into the audio chain (.8% for the application vs. 3 to 5% or more for the radio). Contrary to what you may have read elsewhere, the dynamic range of this application, when properly deployed, is far beyond the capabilities of wide-band FM radio.<br />
<br />
The following settings can be optionally used in a USB radio interface context in "[[Usbradio.conf|/etc/asterisk/usbradio.conf]]". If these keyword and value pairs are not present, their values default to zero (0). These alternate filters should be used with care. Note that additional computing power and radio adjustments may be necessary depending on your application. They have been extensively tested and work fine even with the Raspberry Pi3. Unlike other distributions, we encourage the use of the usbradio channel driver (chan_usbradio), or what we commonly call "Full DSP" in AllStarLink 1.01. This feature will also work in simpleusb, if that's what you prefer. <br />
<br />
This feature is immediately available in new AllStarLink installations and updates. <br />
<br />
=== Receiver Audio Low Pass Filter Options: ===<br />
* rxlpf=0; 3.0 kHz cutoff. Default value for reduced noise and increased intelligibility.<br />
* rxlpf=1; 3.3 kHz cutoff for increased high end, sibilance, and brightness.<br />
* rxlpf=2; 3.5 kHz cutoff for even more high end, sibilance, and brightness.<br />
<br />
=== Receiver Audio High Pass Filter Options: ===<br />
* rxhpf=0; 300 Hz cutoff. Default value to reduce sub-audible signals for retransmission, and also in the receiver speaker.<br />
* rxhpf=1; 250 Hz cutoff for additional received and retransmitted bass response. We recommend using this filter with a CTCSS tone no higher than 186.2 Hz.<br />
<br />
=== Transmitter Audio Low Pass Filter Options: ===<br />
* txlpf=0; 3.0 kHz cutoff. Default value.<br />
* txlpf=1; 3.3 kHz cutoff for increased high end, sibilance and brightness.<br />
<br />
=== Transmitter Audio High Pass Filter Options: ===<br />
* txhpf=0; 300 Hz cutoff. Default value to reduce interference between voice and sub-audible signaling tones and codes.<br />
* txhpf=1; 250 Hz cutoff for increased bass response in transmitted audio.<br />
* txhpf=2; 120 Hz cutoff for special applications requiring additional bass response in transmitted audio. Not recommended due to the increased possibility of voice energy interfering with sub-audible signaling, but should work okay with very low CTCSS frequencies. <br />
<br />
== Key points and specifications == <br />
# All filter combinations yield aliasing distortion/folding at or below -40 dBr. Note that all testing was done with the usbradio channel driver using discriminator (flat) Rx audio, and with Tx audio preemphasis in software. The measurements that follow *include* the low-pass filter inside the DMK URI in the transmit audio path, which is down about 3 dB at 3.5 kHz. The frequency response is better with a modified fob or radio adapters with wider frequency response. <br />
# The variations in amplitude response within the passband as you switch filters are fairly minor. A perfectionist would re-calibrate both rx and tx levels after switching filters in the conf files, but if you're not at the site with a service monitor, but you shouldn't be afraid to switch filters without recalibrating as the variation is less than 0.3 dB @ 1 kHz worst-case among all filter combinations. Yeah, the filters were designed for unity gain, but there's a little ripple in the passband, plus the ulaw effects, so nothing's perfect, but it's close enough to perfect to not worry about.<br />
# THD did not appreciably change as filters were varied, it tends to hover around 0.8% from 300 Hz to wherever the LPF's start to kick in. At low amplitudes (either due to low audio levels or filter skirt attenuation), obviously distortion, as a ratioed value, appears to rise due to quantization noise, but that's unavoidable in our little 8 bit ulaw corner of the world. IMD was likewise acceptable across the range. <br />
<br />
== Recommended Settings ==<br />
<br />
<br />
Start off with all of the filters (rxlpf, rxhpf, txlpf, txhpf) set to 1. <br />
This will make a marked improvement in frequency response, both as far as local repeat audio goes as well as through the network. With the default (zero) filters, frequency response is pretty restricted. <br />
<br />
<br />
Here's a brief synopsis of what the frequency response from Rx to Tx is like with the DEFAULT (zero) filters that everybody is currently using <br />
<gallery heights="300px" widths="300px"><br />
AllStarLink Filter 2.png<br />
</gallery><br />
<br />
So, you can see that the low-end suffers quite a bit, as it's almost 8 dB down at 300 Hz. It also has overshoots in excess of 1 dB centered at 425 and 675 Hz. The high end falls off quite sharply as well.<br />
<br />
By switching to all 1's for the filters, the response and flatness if greatly improved <br />
<br />
<gallery heights="300px" widths="300px"><br />
AllStarLink Filter 1.png<br />
</gallery><br />
<br />
Notice the improvement at the low end and high end. <br />
<br />
The frequency response is flat to within ± 1 dB from 286 Hz to 2.77 kHz. Regardless of what low-pass filtering you have (or don't have) in your transmitter, nor what your channel spacing is (15 kHz versus 20/25), you should have no problems as far as excessive occupied bandwidth using all 1's for the filters. HOWEVER (and here's a big however), the CM108, even when not being sent data by the channel driver, has about 350 uV RMS of residual wideband noise, with energy primarily falling at harmonics of the sample rate (48 kHz). 350 uV is about 71 dB below the maximum output level of the CM108 best-case, but the ratio may be much worse than that depending on how low you have txvoice set (i.e. it may only end up being 30 or 40 dB down if your Tx has a sensitive input and you have txvoice set accordingly low). As such, we strongly DO NOT recommend feeding a CM108/119 output directly to the modulator without low-pass filtering in the exciter, or optionally in the radio adapter. The LPF doesn't need to be anywhere near as aggressive as it would be in a stock radio of course, but it should sufficiently attenuate everything in the ultrasonic range. As always, you should proof your contraptions with a spectrum analyzer before sticking them on a mountaintop! <br />
<br />
Deviations from all filters being set to 1 follow:<br />
If you are using a PL tone higher ABOVE 186.2 Hz and you do NOT have an external PL filter in the repeater receiver, then leave rxhpf at 0. Otherwise, you will start putting receive audio onto the network with insufficient PL filtering (we like to see 40 dB of PL rejection, but -37 dB at 186.2 is close enough).<br />
<br />
If you do have an external PL reject filter in the receiver, you should be able to use rxhpf=1 no matter what tone you're using.<br />
<br />
Some receiver discriminators have a little more high-end rolloff than others. At your option, and after adequate testing, going to rxlpf=2 shouldn't cause any problems either locally or on the network. But, the difference between rxlpf=1 and rxlpf=2 is pretty minor, and really only improves the response over a fairly narrow range at the very high end, which most people aren't going to notice.<br />
<br />
In summary, we believe if you switch all of the filters to 1 you'll be very happy with the improvement in quality and no further tweaking will be necessary. Our goal was to make the "1" filters - plug and play. The improvement will obviously be greatest when both the repeater you're on as well as the repeater of the user(s) you're talking to have the updated filter code, and have taken advantage of these filters.</div>W3KKChttps://wiki.pttlink.org/index.php?title=Audio_Filters&diff=932Audio Filters2018-04-21T16:43:11Z<p>W3KKC: Removed the textual response information.</p>
<hr />
<div>Hello AllStarLink Amateur Radio Operators,<br />
<br />
The release of AllStarLink 1.01 software package contains a feature pioneered by Jeff DePolo, WN3A. It is a set of audio filters for amateur radio applications. The default transmit and receive filters were designed around commercial standards. However, because amateur radio operators have the resources to use wider bandwidths, especially on UHF, they may prefer other filter types in order to provide higher audio quality. Over the years there have been other fixes for the usbradio channel driver minimizing the distortions. The results below proves the distortions are considerably lower than what a typical radio/repeater will add into the audio chain (.8% for the application vs. 3 to 5% or more for the radio). Contrary to what you may have read elsewhere, the dynamic range of this application, when properly deployed, is far beyond the capabilities of wide-band FM radio.<br />
<br />
The following settings can be optionally used in a USB radio interface context in "/etc/asterisk/usbradio.conf". If these keyword and value pairs are not present, their values default to zero (0). These alternate filters should be used with care. Note that additional computing power and radio adjustments may be necessary depending on your application. They have been extensively tested and work fine even with the Raspberry Pi3. Unlike other distributions, we encourage the use of the usbradio channel driver (chan_usbradio), or what we commonly call "Full DSP" in AllStarLink 1.01. This feature will also work in simpleusb, if that's what you prefer. <br />
<br />
This feature is immediately available in new AllStarLink installations and updates. <br />
<br />
Receiver Audio Low Pass Filter Options:<br />
* rxlpf=0; 3.0 kHz cutoff. Default value for reduced noise and increased intelligibility.<br />
* rxlpf=1; 3.3 kHz cutoff for increased high end, sibilance, and brightness.<br />
* rxlpf=2; 3.5 kHz cutoff for even more high end, sibilance, and brightness.<br />
<br />
Receiver Audio High Pass Filter Options:<br />
* rxhpf=0; 300 Hz cutoff. Default value to reduce sub-audible signals for retransmission, and also in the receiver speaker.<br />
* rxhpf=1; 250 Hz cutoff for additional received and retransmitted bass response. We recommend using this filter with a CTCSS tone no higher than 186.2 Hz.<br />
<br />
Transmitter Audio Low Pass Filter Options:<br />
* txlpf=0; 3.0 kHz cutoff. Default value.<br />
* txlpf=1; 3.3 kHz cutoff for increased high end, sibilance and brightness.<br />
<br />
Transmitter Audio High Pass Filter Options:<br />
* txhpf=0; 300 Hz cutoff. Default value to reduce interference between voice and sub-audible signaling tones and codes.<br />
* txhpf=1; 250 Hz cutoff for increased bass response in transmitted audio.<br />
* txhpf=2; 120 Hz cutoff for special applications requiring additional bass response in transmitted audio. Not recommended due to the increased possibility of voice energy interfering with sub-audible signaling, but should work okay with very low CTCSS frequencies. <br />
<br />
Key points and specifications: <br />
# All filter combinations yield aliasing distortion/folding at or below -40 dBr. Note that all testing was done with the usbradio channel driver using discriminator (flat) Rx audio, and with Tx audio preemphasis in software. The measurements that follow *include* the low-pass filter inside the DMK URI in the transmit audio path, which is down about 3 dB at 3.5 kHz. The frequency response is better with a modified fob or radio adapters with wider frequency response. <br />
# The variations in amplitude response within the passband as you switch filters are fairly minor. A perfectionist would re-calibrate both rx and tx levels after switching filters in the conf files, but if you're not at the site with a service monitor, but you shouldn't be afraid to switch filters without recalibrating as the variation is less than 0.3 dB @ 1 kHz worst-case among all filter combinations. Yeah, the filters were designed for unity gain, but there's a little ripple in the passband, plus the ulaw effects, so nothing's perfect, but it's close enough to perfect to not worry about.<br />
# THD did not appreciably change as filters were varied, it tends to hover around 0.8% from 300 Hz to wherever the LPF's start to kick in. At low amplitudes (either due to low audio levels or filter skirt attenuation), obviously distortion, as a ratioed value, appears to rise due to quantization noise, but that's unavoidable in our little 8 bit ulaw corner of the world. IMD was likewise acceptable across the range. <br />
<br />
The developers recommend the following settings: <br />
<br />
Start off with all of the filters (rxlpf, rxhpf, txlpf, txhpf) set to 1. This will make a marked improvement in frequency response, both as far as local repeat audio goes as well as through the network. With the default (zero) filters, frequency response is pretty restricted. <br />
<br />
* [http://www.repeater-builder.com/voip/pdf/filters.pdf PDF of the graphs] for setting of "1" and "0" respectively. <br />
<br />
Here's a brief synopsis of what the frequency response from Rx to Tx is like with the DEFAULT (zero) filters that everybody is currently using '''(refer to page 2 of the PDF).'''<br />
<br />
So, you can see that the low-end suffers quite a bit, as it's almost 8 dB down at 300 Hz. It also has overshoots in excess of 1 dB centered at 425 and 675 Hz. The high end falls off quite sharply as well.<br />
<br />
By switching to all 1's for the filters, the response and flatness if greatly improved '''(refer to page 1 of the PDF).'''<br />
<br />
Notice the improvement at the low end and high end. The frequency response is flat to within ± 1 dB from 286 Hz to 2.77 kHz. Regardless of what low-pass filtering you have (or don't have) in your transmitter, nor what your channel spacing is (15 kHz versus 20/25), you should have no problems as far as excessive occupied bandwidth using all 1's for the filters. HOWEVER (and here's a big however), the CM108, even when not being sent data by the channel driver, has about 350 uV RMS of residual wideband noise, with energy primarily falling at harmonics of the sample rate (48 kHz). 350 uV is about 71 dB below the maximum output level of the CM108 best-case, but the ratio may be much worse than that depending on how low you have txvoice set (i.e. it may only end up being 30 or 40 dB down if your Tx has a sensitive input and you have txvoice set accordingly low). As such, we strongly DO NOT recommend feeding a CM108/119 output directly to the modulator without low-pass filtering in the exciter, or optionally in the radio adapter. The LPF doesn't need to be anywhere near as aggressive as it would be in a stock radio of course, but it should sufficiently attenuate everything in the ultrasonic range. As always, you should proof your contraptions with a spectrum analyzer before sticking them on a mountaintop! <br />
<br />
Deviations from all filters being set to 1 follow:<br />
If you are using a PL tone higher ABOVE 186.2 Hz and you do NOT have an external PL filter in the repeater receiver, then leave rxhpf at 0. Otherwise, you will start putting receive audio onto the network with insufficient PL filtering (we like to see 40 dB of PL rejection, but -37 dB at 186.2 is close enough).<br />
<br />
If you do have an external PL reject filter in the receiver, you should be able to use rxhpf=1 no matter what tone you're using.<br />
<br />
Some receiver discriminators have a little more high-end rolloff than others. At your option, and after adequate testing, going to rxlpf=2 shouldn't cause any problems either locally or on the network. But, the difference between rxlpf=1 and rxlpf=2 is pretty minor, and really only improves the response over a fairly narrow range at the very high end, which most people aren't going to notice.<br />
<br />
In summary, we believe if you switch all of the filters to 1 you'll be very happy with the improvement in quality and no further tweaking will be necessary. Our goal was to make the "1" filters - plug and play. The improvement will obviously be greatest when both the repeater you're on as well as the repeater of the user(s) you're talking to have the updated filter code, and have taken advantage of these filters.</div>W3KKChttps://wiki.pttlink.org/index.php?title=Audio_Filters&diff=931Audio Filters2018-04-21T16:38:57Z<p>W3KKC: updated text</p>
<hr />
<div>Hello AllStarLink Amateur Radio Operators,<br />
<br />
The release of AllStarLink 1.01 software package contains a feature pioneered by Jeff DePolo, WN3A. It is a set of audio filters for amateur radio applications. The default transmit and receive filters were designed around commercial standards. However, because amateur radio operators have the resources to use wider bandwidths, especially on UHF, they may prefer other filter types in order to provide higher audio quality. Over the years there have been other fixes for the usbradio channel driver minimizing the distortions. The results below proves the distortions are considerably lower than what a typical radio/repeater will add into the audio chain (.8% for the application vs. 3 to 5% or more for the radio). Contrary to what you may have read elsewhere, the dynamic range of this application, when properly deployed, is far beyond the capabilities of wide-band FM radio.<br />
<br />
The following settings can be optionally used in a USB radio interface context in "/etc/asterisk/usbradio.conf". If these keyword and value pairs are not present, their values default to zero (0). These alternate filters should be used with care. Note that additional computing power and radio adjustments may be necessary depending on your application. They have been extensively tested and work fine even with the Raspberry Pi3. Unlike other distributions, we encourage the use of the usbradio channel driver (chan_usbradio), or what we commonly call "Full DSP" in AllStarLink 1.01. This feature will also work in simpleusb, if that's what you prefer. <br />
<br />
This feature is immediately available in new AllStarLink installations and updates. <br />
<br />
Receiver Audio Low Pass Filter Options:<br />
* rxlpf=0; 3.0 kHz cutoff. Default value for reduced noise and increased intelligibility.<br />
* rxlpf=1; 3.3 kHz cutoff for increased high end, sibilance, and brightness.<br />
* rxlpf=2; 3.5 kHz cutoff for even more high end, sibilance, and brightness.<br />
<br />
Receiver Audio High Pass Filter Options:<br />
* rxhpf=0; 300 Hz cutoff. Default value to reduce sub-audible signals for retransmission, and also in the receiver speaker.<br />
* rxhpf=1; 250 Hz cutoff for additional received and retransmitted bass response. We recommend using this filter with a CTCSS tone no higher than 186.2 Hz.<br />
<br />
Transmitter Audio Low Pass Filter Options:<br />
* txlpf=0; 3.0 kHz cutoff. Default value.<br />
* txlpf=1; 3.3 kHz cutoff for increased high end, sibilance and brightness.<br />
<br />
Transmitter Audio High Pass Filter Options:<br />
* txhpf=0; 300 Hz cutoff. Default value to reduce interference between voice and sub-audible signaling tones and codes.<br />
* txhpf=1; 250 Hz cutoff for increased bass response in transmitted audio.<br />
* txhpf=2; 120 Hz cutoff for special applications requiring additional bass response in transmitted audio. Not recommended due to the increased possibility of voice energy interfering with sub-audible signaling, but should work okay with very low CTCSS frequencies. <br />
<br />
Key points and specifications: <br />
# All filter combinations yield aliasing distortion/folding at or below -40 dBr. Note that all testing was done with the usbradio channel driver using discriminator (flat) Rx audio, and with Tx audio preemphasis in software. The measurements that follow *include* the low-pass filter inside the DMK URI in the transmit audio path, which is down about 3 dB at 3.5 kHz. The frequency response is better with a modified fob or radio adapters with wider frequency response. <br />
# The variations in amplitude response within the passband as you switch filters are fairly minor. A perfectionist would re-calibrate both rx and tx levels after switching filters in the conf files, but if you're not at the site with a service monitor, but you shouldn't be afraid to switch filters without recalibrating as the variation is less than 0.3 dB @ 1 kHz worst-case among all filter combinations. Yeah, the filters were designed for unity gain, but there's a little ripple in the passband, plus the ulaw effects, so nothing's perfect, but it's close enough to perfect to not worry about.<br />
# THD did not appreciably change as filters were varied, it tends to hover around 0.8% from 300 Hz to wherever the LPF's start to kick in. At low amplitudes (either due to low audio levels or filter skirt attenuation), obviously distortion, as a ratioed value, appears to rise due to quantization noise, but that's unavoidable in our little 8 bit ulaw corner of the world. IMD was likewise acceptable across the range. <br />
<br />
The developers recommend the following settings: <br />
<br />
Start off with all of the filters (rxlpf, rxhpf, txlpf, txhpf) set to 1. This will make a marked improvement in frequency response, both as far as local repeat audio goes as well as through the network. With the default (zero) filters, frequency response is pretty restricted. <br />
<br />
Here's a brief synopsis of what the frequency response from Rx to Tx is like with the DEFAULT (zero) filters that everybody is currently using:<br />
* < -40 dB @ 210 Hz and below <br />
* -20 dB @ 250 Hz <br />
* -13.3 dB @ 275 Hz <br />
* -7.9 dB @ 300 Hz <br />
* -1.4 dB @ 350 Hz <br />
* 1.1 dB @ 400 Hz <br />
* 0.2 dB @ 500 Hz <br />
* 0.5 dB @ 600 Hz <br />
* * +1.5 dB @ 425 Hz <br />
* * +1.0 dB @ 675 <br />
* 0.7 dB @ 700 Hz <br />
* 0.2 dB @ 800 Hz <br />
* 0.6 dB @ 900 Hz <br />
* 0 dB @ 1 kHz <br />
* -0.1 dB @ 1.2 kHz <br />
* -0.4 dB @ 1.4 kHz <br />
* -0.6 dB @ 1.6 kHz <br />
* -0.6 dB @ 1.8 kHz <br />
* -0.3 dB @ 2.0 kHz <br />
* 0.1 dB @ 2.2 kHz <br />
* -0.2 dB @ 2.4 kHz <br />
* -1.4 dB @ 2.6 kHz <br />
* -4.1 dB @ 2.8 kHz <br />
* -9.0 dB @ 3.0 kHz <br />
* -16.3 dB @ 3.2 kHz <br />
* -26 dB @ 3.4 kHz <br />
* < -40 dB @ 3.6 kHz and above<br />
<br />
So, you can see that the low-end suffers quite a bit, as it's almost 8 dB down at 300 Hz. It also has overshoots in excess of 1 dB centered at 425 and 675 Hz. The high end falls off quite sharply as well.<br />
<br />
By switching to all 1's for the filters, here's what the response is like:<br />
* < -40 dB @ 180 and below <br />
* -37 dB @ 186.2 Hz <br />
* -16.5 dB @ 220 Hz <br />
* -9.2 dB @ 240 Hz <br />
* -4.5 dB @ 260 Hz <br />
* -2.0 dB @ 275 Hz <br />
* -1.6 dB @ 280 Hz <br />
* -1.0 dB @ 286 Hz <br />
* -0.1 dB @ 300 Hz <br />
* +0.5 dB @ 330 Hz <br />
* 0 dB @ 1 kHz <br />
* -0.5 dB @ 2.4 kHz <br />
* -1.0 dB @ 2.77 kHz <br />
* -2.0 dB @ 3.0 kHz <br />
* -6.9 dB @ 3.2 kHz <br />
* -15.2 dB @ 3.4 kHz <br />
* -29 dB @ 3.6 kHz <br />
* < -40 dB @ 3.7 kHz and above<br />
<br />
[http://www.repeater-builder.com/voip/pdf/filters.pdf PDF of the graphs] for setting of "1" and "0" respectively. <br />
<br />
Notice the improvement at the low end and high end. The frequency response is flat to within ± 1 dB from 286 Hz to 2.77 kHz. Regardless of what low-pass filtering you have (or don't have) in your transmitter, nor what your channel spacing is (15 kHz versus 20/25), you should have no problems as far as excessive occupied bandwidth using all 1's for the filters. HOWEVER (and here's a big however), the CM108, even when not being sent data by the channel driver, has about 350 uV RMS of residual wideband noise, with energy primarily falling at harmonics of the sample rate (48 kHz). 350 uV is about 71 dB below the maximum output level of the CM108 best-case, but the ratio may be much worse than that depending on how low you have txvoice set (i.e. it may only end up being 30 or 40 dB down if your Tx has a sensitive input and you have txvoice set accordingly low). As such, we strongly DO NOT recommend feeding a CM108/119 output directly to the modulator without low-pass filtering in the exciter, or optionally in the radio adapter. The LPF doesn't need to be anywhere near as aggressive as it would be in a stock radio of course, but it should sufficiently attenuate everything in the ultrasonic range. As always, you should proof your contraptions with a spectrum analyzer before sticking them on a mountaintop!<br />
<br />
Deviations from all filters being set to 1 follow:<br />
If you are using a PL tone higher ABOVE 186.2 Hz and you do NOT have an external PL filter in the repeater receiver, then leave rxhpf at 0. Otherwise, you will start putting receive audio onto the network with insufficient PL filtering (we like to see 40 dB of PL rejection, but -37 dB at 186.2 is close enough).<br />
<br />
If you do have an external PL reject filter in the receiver, you should be able to use rxhpf=1 no matter what tone you're using.<br />
<br />
Some receiver discriminators have a little more high-end rolloff than others. At your option, and after adequate testing, going to rxlpf=2 shouldn't cause any problems either locally or on the network. But, the difference between rxlpf=1 and rxlpf=2 is pretty minor, and really only improves the response over a fairly narrow range at the very high end, which most people aren't going to notice.<br />
<br />
In summary, we believe if you switch all of the filters to 1 you'll be very happy with the improvement in quality and no further tweaking will be necessary. Our goal was to make the "1" filters - plug and play. The improvement will obviously be greatest when both the repeater you're on as well as the repeater of the user(s) you're talking to have the updated filter code, and have taken advantage of these filters.</div>W3KKChttps://wiki.pttlink.org/index.php?title=Audio_Filters&diff=925Audio Filters2018-04-21T16:30:50Z<p>W3KKC: PDF link added</p>
<hr />
<div>Hello AllStarLink Amateur Radio Operators,<br />
<br />
The release of AllStarLink 1.01 software package contains a feature pioneered by Jeff DePolo, WN3A. It is a set of audio filters for amateur radio applications. The default transmit and receive filters were designed around commercial standards. However, because amateur radio operators have the resources to use wider bandwidths, especially on UHF, they may prefer other filter types in order to provide higher audio quality. Over the years there have been other fixes for the usbradio channel driver minimizing the distortions. The results below proves the distortions are considerably lower than what a typical radio/repeater will add into the audio chain (.8% for the application vs. 3 to 5% or more for the radio). Contrary to what you may have read elsewhere, the dynamic range of this application, when properly deployed, is far beyond the capabilities of wide-band FM radio.<br />
<br />
The following settings can be optionally used in a USB radio interface context in "/etc/asterisk/usbradio.conf". If these keyword and value pairs are not present, their values default to zero (0). These alternate filters should be used with care. Note that additional computing power and radio adjustments may be necessary depending on your application. They have been extensively tested and work fine even with the Raspberry Pi3. Unlike other distributions, we encourage the use of the usbradio channel driver (chan_usbradio), or what we commonly call "Full DSP" in AllStarLink 1.01. This feature will also work in simpleusb, if that's what you prefer. <br />
<br />
This feature is immediately available in new AllStarLink installations and updates. <br />
<br />
Receiver Audio Low Pass Filter Options:<br />
* rxlpf=0; 3.0 kHz cutoff. Default value for reduced noise and increased intelligibility.<br />
* rxlpf=1; 3.3 kHz cutoff for increased high end, sibilance, and brightness.<br />
* rxlpf=2; 3.5 kHz cutoff for even more high end, sibilance, and brightness.<br />
<br />
Receiver Audio High Pass Filter Options:<br />
* rxhpf=0; 300 Hz cutoff. Default value to reduce sub-audible signals for retransmission, and also in the receiver speaker.<br />
* rxhpf=1; 250 Hz cutoff for additional received and retransmitted bass response. We recommend using this filter with a CTCSS tone no higher than 186.2 Hz.<br />
<br />
Transmitter Audio Low Pass Filter Options:<br />
* txlpf=0; 3.0 kHz cutoff. Default value.<br />
* txlpf=1; 3.3 kHz cutoff for increased high end, sibilance and brightness.<br />
<br />
Transmitter Audio High Pass Filter Options:<br />
* txhpf=0; 300 Hz cutoff. Default value to reduce interference between voice and sub-audible signaling tones and codes.<br />
* txhpf=1; 250 Hz cutoff for increased bass response in transmitted audio.<br />
* txhpf=2; 120 Hz cutoff for special applications requiring additional bass response in transmitted audio. Not recommended due to the increased possibility of voice energy interfering with sub-audible signaling, but should work okay with very low CTCSS frequencies. <br />
<br />
Key points and specifications: <br />
# All filter combinations yield aliasing distortion/folding at or below -40 dBr. Note that all testing was done with the usbradio channel driver using discriminator (flat) Rx audio, and with Tx audio preemphasis in software. The measurements that follow *include* the low-pass filter inside the DMK URI in the transmit audio path, which is down about 3 dB at 3.5 kHz. The frequency response is better with a modified fob or radio adapters with wider frequency response. <br />
# The variations in amplitude response within the passband as you switch filters are fairly minor. A perfectionist would re-calibrate both rx and tx levels after switching filters in the conf files, but if you're not at the site with a service monitor, but you shouldn't be afraid to switch filters without recalibrating as the variation is less than 0.3 dB @ 1 kHz worst-case among all filter combinations. Yeah, the filters were designed for unity gain, but there's a little ripple in the passband, plus the ulaw effects, so nothing's perfect, but it's close enough to perfect to not worry about.<br />
# THD did not appreciably change as filters were varied, it tends to hover around 0.8% from 300 Hz to wherever the LPF's start to kick in. At low amplitudes (either due to low audio levels or filter skirt attenuation), obviously distortion, as a ratioed value, appears to rise due to quantization noise, but that's unavoidable in our little 8 bit ulaw corner of the world. IMD was likewise acceptable across the range. <br />
<br />
The developers recommend the following settings: <br />
<br />
Start off with all of the filters (rxlpf, rxhpf, txlpf, txhpf) set to 1. This will make a marked improvement in frequency response, both as far as local repeat audio goes as well as through the network. With the default (zero) filters, frequency response is pretty restricted. <br />
<br />
Here's a brief synopsis of what the frequency response from Rx to Tx is like with the DEFAULT (zero) filters that everybody is currently using:<br />
* < -40 dB @ 210 Hz and below <br />
* -20 dB @ 250 Hz <br />
* -13.3 dB @ 275 Hz <br />
* -7.9 dB @ 300 Hz <br />
* -1.4 dB @ 350 Hz <br />
* 1.1 dB @ 400 Hz <br />
* 0.2 dB @ 500 Hz <br />
* 0.5 dB @ 600 Hz <br />
* * +1.5 dB @ 425 Hz <br />
* * +1.0 dB @ 675 <br />
* 0.7 dB @ 700 Hz <br />
* 0.2 dB @ 800 Hz <br />
* 0.6 dB @ 900 Hz <br />
* 0 dB @ 1 kHz <br />
* -0.1 dB @ 1.2 kHz <br />
* -0.4 dB @ 1.4 kHz <br />
* -0.6 dB @ 1.6 kHz <br />
* -0.6 dB @ 1.8 kHz <br />
* -0.3 dB @ 2.0 kHz <br />
* 0.1 dB @ 2.2 kHz <br />
* -0.2 dB @ 2.4 kHz <br />
* -1.4 dB @ 2.6 kHz <br />
* -4.1 dB @ 2.8 kHz <br />
* -9.0 dB @ 3.0 kHz <br />
* -16.3 dB @ 3.2 kHz <br />
* -26 dB @ 3.4 kHz <br />
* < -40 dB @ 3.6 kHz and above<br />
<br />
So, you can see that the low-end suffers quite a bit, as it's almost 8 dB down at 300 Hz. It also has overshoots in excess of 1 dB centered at 425 and 675 Hz. The high end falls off quite sharply as well.<br />
<br />
By switching to all 1's for the filters, here's what the response is like:<br />
* < -40 dB @ 180 and below <br />
* -37 dB @ 186.2 Hz <br />
* -16.5 dB @ 220 Hz <br />
* -9.2 dB @ 240 Hz <br />
* -4.5 dB @ 260 Hz <br />
* -2.0 dB @ 275 Hz <br />
* -1.6 dB @ 280 Hz <br />
* -1.0 dB @ 286 Hz <br />
* -0.1 dB @ 300 Hz <br />
* +0.5 dB @ 330 Hz <br />
* 0 dB @ 1 kHz <br />
* -0.5 dB @ 2.4 kHz <br />
* -1.0 dB @ 2.77 kHz <br />
* -2.0 dB @ 3.0 kHz <br />
* -6.9 dB @ 3.2 kHz <br />
* -15.2 dB @ 3.4 kHz <br />
* -29 dB @ 3.6 kHz <br />
* < -40 dB @ 3.7 kHz and above<br />
<br />
[http://www.repeater-builder.com/voip/pdf/filters.pdf PDF of the graphs] for setting of "0" and "1". <br />
<br />
Notice the improvement at the low end and high end. The frequency response is flat to within ± 1 dB from 286 Hz to 2.77 kHz. Regardless of what low-pass filtering you have (or don't have) in your transmitter, nor what your channel spacing is (15 kHz versus 20/25), you should have no problems as far as excessive occupied bandwidth using all 1's for the filters. HOWEVER (and here's a big however), the CM108, even when not being sent data by the channel driver, has about 350 uV RMS of residual wideband noise, with energy primarily falling at harmonics of the sample rate (48 kHz). 350 uV is about 71 dB below the maximum output level of the CM108 best-case, but the ratio may be much worse than that depending on how low you have txvoice set (i.e. it may only end up being 30 or 40 dB down if your Tx has a sensitive input and you have txvoice set accordingly low). As such, we strongly DO NOT recommend feeding a CM108/119 output directly to the modulator without low-pass filtering in the exciter, or optionally in the radio adapter. The LPF doesn't need to be anywhere near as aggressive as it would be in a stock radio of course, but it should sufficiently attenuate everything in the ultrasonic range. As always, you should proof your contraptions with a spectrum analyzer before sticking them on a mountaintop!<br />
<br />
Deviations from all filters being set to 1 follow:<br />
If you are using a PL tone higher ABOVE 186.2 Hz and you do NOT have an external PL filter in the repeater receiver, then leave rxhpf at 0. Otherwise, you will start putting receive audio onto the network with insufficient PL filtering (we like to see 40 dB of PL rejection, but -37 dB at 186.2 is close enough).<br />
<br />
If you do have an external PL reject filter in the receiver, you should be able to use rxhpf=1 no matter what tone you're using.<br />
<br />
Some receiver discriminators have a little more high-end rolloff than others. At your option, and after adequate testing, going to rxlpf=2 shouldn't cause any problems either locally or on the network. But, the difference between rxlpf=1 and rxlpf=2 is pretty minor, and really only improves the response over a fairly narrow range at the very high end, which most people aren't going to notice.<br />
<br />
In summary, we believe if you switch all of the filters to 1 you'll be very happy with the improvement in quality and no further tweaking will be necessary. Our goal was to make the "1" filters - plug and play. The improvement will obviously be greatest when both the repeater you're on as well as the repeater of the user(s) you're talking to have the updated filter code, and have taken advantage of these filters.</div>W3KKChttps://wiki.pttlink.org/index.php?title=Audio_Filters&diff=920Audio Filters2018-04-18T14:58:33Z<p>W3KKC: </p>
<hr />
<div>Hello AllStarLink Amateur Radio Operators,<br />
<br />
The release of AllStarLink 1.01 software package contains a feature pioneered by Jeff DePolo, WN3A. It is a set of audio filters for amateur radio applications. The default transmit and receive filters were designed around commercial standards. However, because amateur radio operators have the resources to use wider bandwidths, especially on UHF, they may prefer other filter types in order to provide higher audio quality. Over the years there have been other fixes for the usbradio channel driver minimizing the distortions. The results below proves the distortions are considerably lower than what a typical radio/repeater will add into the audio chain (.8% for the application vs. 3 to 5% or more for the radio). Contrary to what you may have read elsewhere, the dynamic range of this application, when properly deployed, is far beyond the capabilities of wide-band FM radio.<br />
<br />
The following settings can be optionally used in a USB radio interface context in "/etc/asterisk/usbradio.conf". If these keyword and value pairs are not present, their values default to zero (0). These alternate filters should be used with care. Note that additional computing power and radio adjustments may be necessary depending on your application. They have been extensively tested and work fine even with the Raspberry Pi3. Unlike other distributions, we encourage the use of the usbradio channel driver (chan_usbradio), or what we commonly call "Full DSP" in AllStarLink 1.01. This feature will also work in simpleusb, if that's what you prefer. <br />
<br />
This feature is immediately available in new AllStarLink installations and updates. <br />
<br />
Receiver Audio Low Pass Filter Options:<br />
* rxlpf=0; 3.0 kHz cutoff. Default value for reduced noise and increased intelligibility.<br />
* rxlpf=1; 3.3 kHz cutoff for increased high end, sibilance, and brightness.<br />
* rxlpf=2; 3.5 kHz cutoff for even more high end, sibilance, and brightness.<br />
<br />
Receiver Audio High Pass Filter Options:<br />
* rxhpf=0; 300 Hz cutoff. Default value to reduce sub-audible signals for retransmission, and also in the receiver speaker.<br />
* rxhpf=1; 250 Hz cutoff for additional received and retransmitted bass response. We recommend using this filter with a CTCSS tone no higher than 186.2 Hz.<br />
<br />
Transmitter Audio Low Pass Filter Options:<br />
* txlpf=0; 3.0 kHz cutoff. Default value.<br />
* txlpf=1; 3.3 kHz cutoff for increased high end, sibilance and brightness.<br />
<br />
Transmitter Audio High Pass Filter Options:<br />
* txhpf=0; 300 Hz cutoff. Default value to reduce interference between voice and sub-audible signaling tones and codes.<br />
* txhpf=1; 250 Hz cutoff for increased bass response in transmitted audio.<br />
* txhpf=2; 120 Hz cutoff for special applications requiring additional bass response in transmitted audio. Not recommended due to the increased possibility of voice energy interfering with sub-audible signaling, but should work okay with very low CTCSS frequencies. <br />
<br />
Key points and specifications: <br />
# All filter combinations yield aliasing distortion/folding at or below -40 dBr. Note that all testing was done with the usbradio channel driver using discriminator (flat) Rx audio, and with Tx audio preemphasis in software. The measurements that follow *include* the low-pass filter inside the DMK URI in the transmit audio path, which is down about 3 dB at 3.5 kHz. The frequency response is better with a modified fob or radio adapters with wider frequency response. <br />
# The variations in amplitude response within the passband as you switch filters are fairly minor. A perfectionist would re-calibrate both rx and tx levels after switching filters in the conf files, but if you're not at the site with a service monitor, but you shouldn't be afraid to switch filters without recalibrating as the variation is less than 0.3 dB @ 1 kHz worst-case among all filter combinations. Yeah, the filters were designed for unity gain, but there's a little ripple in the passband, plus the ulaw effects, so nothing's perfect, but it's close enough to perfect to not worry about.<br />
# THD did not appreciably change as filters were varied, it tends to hover around 0.8% from 300 Hz to wherever the LPF's start to kick in. At low amplitudes (either due to low audio levels or filter skirt attenuation), obviously distortion, as a ratioed value, appears to rise due to quantization noise, but that's unavoidable in our little 8 bit ulaw corner of the world. IMD was likewise acceptable across the range. <br />
<br />
The developers recommend the following settings: <br />
<br />
Start off with all of the filters (rxlpf, rxhpf, txlpf, txhpf) set to 1. This will make a marked improvement in frequency response, both as far as local repeat audio goes as well as through the network. With the default (zero) filters, frequency response is pretty restricted. <br />
<br />
Here's a brief synopsis of what the frequency response from Rx to Tx is like with the DEFAULT (zero) filters that everybody is currently using:<br />
* < -40 dB @ 210 Hz and below <br />
* -20 dB @ 250 Hz <br />
* -13.3 dB @ 275 Hz <br />
* -7.9 dB @ 300 Hz <br />
* -1.4 dB @ 350 Hz <br />
* 1.1 dB @ 400 Hz <br />
* 0.2 dB @ 500 Hz <br />
* 0.5 dB @ 600 Hz <br />
* * +1.5 dB @ 425 Hz <br />
* * +1.0 dB @ 675 <br />
* 0.7 dB @ 700 Hz <br />
* 0.2 dB @ 800 Hz <br />
* 0.6 dB @ 900 Hz <br />
* 0 dB @ 1 kHz <br />
* -0.1 dB @ 1.2 kHz <br />
* -0.4 dB @ 1.4 kHz <br />
* -0.6 dB @ 1.6 kHz <br />
* -0.6 dB @ 1.8 kHz <br />
* -0.3 dB @ 2.0 kHz <br />
* 0.1 dB @ 2.2 kHz <br />
* -0.2 dB @ 2.4 kHz <br />
* -1.4 dB @ 2.6 kHz <br />
* -4.1 dB @ 2.8 kHz <br />
* -9.0 dB @ 3.0 kHz <br />
* -16.3 dB @ 3.2 kHz <br />
* -26 dB @ 3.4 kHz <br />
* < -40 dB @ 3.6 kHz and above<br />
<br />
So, you can see that the low-end suffers quite a bit, as it's almost 8 dB down at 300 Hz. It also has overshoots in excess of 1 dB centered at 425 and 675 Hz. The high end falls off quite sharply as well.<br />
<br />
By switching to all 1's for the filters, here's what the response is like:<br />
* < -40 dB @ 180 and below <br />
* -37 dB @ 186.2 Hz <br />
* -16.5 dB @ 220 Hz <br />
* -9.2 dB @ 240 Hz <br />
* -4.5 dB @ 260 Hz <br />
* -2.0 dB @ 275 Hz <br />
* -1.6 dB @ 280 Hz <br />
* -1.0 dB @ 286 Hz <br />
* -0.1 dB @ 300 Hz <br />
* +0.5 dB @ 330 Hz <br />
* 0 dB @ 1 kHz <br />
* -0.5 dB @ 2.4 kHz <br />
* -1.0 dB @ 2.77 kHz <br />
* -2.0 dB @ 3.0 kHz <br />
* -6.9 dB @ 3.2 kHz <br />
* -15.2 dB @ 3.4 kHz <br />
* -29 dB @ 3.6 kHz <br />
* < -40 dB @ 3.7 kHz and above<br />
<br />
Notice the improvement at the low end and high end. The frequency response is flat to within ± 1 dB from 286 Hz to 2.77 kHz. Regardless of what low-pass filtering you have (or don't have) in your transmitter, nor what your channel spacing is (15 kHz versus 20/25), you should have no problems as far as excessive occupied bandwidth using all 1's for the filters. HOWEVER (and here's a big however), the CM108, even when not being sent data by the channel driver, has about 350 uV RMS of residual wideband noise, with energy primarily falling at harmonics of the sample rate (48 kHz). 350 uV is about 71 dB below the maximum output level of the CM108 best-case, but the ratio may be much worse than that depending on how low you have txvoice set (i.e. it may only end up being 30 or 40 dB down if your Tx has a sensitive input and you have txvoice set accordingly low). As such, we strongly DO NOT recommend feeding a CM108/119 output directly to the modulator without low-pass filtering in the exciter, or optionally in the radio adapter. The LPF doesn't need to be anywhere near as aggressive as it would be in a stock radio of course, but it should sufficiently attenuate everything in the ultrasonic range. As always, you should proof your contraptions with a spectrum analyzer before sticking them on a mountaintop!<br />
<br />
Deviations from all filters being set to 1 follow:<br />
If you are using a PL tone higher ABOVE 186.2 Hz and you do NOT have an external PL filter in the repeater receiver, then leave rxhpf at 0. Otherwise, you will start putting receive audio onto the network with insufficient PL filtering (we like to see 40 dB of PL rejection, but -37 dB at 186.2 is close enough).<br />
<br />
If you do have an external PL reject filter in the receiver, you should be able to use rxhpf=1 no matter what tone you're using.<br />
<br />
Some receiver discriminators have a little more high-end rolloff than others. At your option, and after adequate testing, going to rxlpf=2 shouldn't cause any problems either locally or on the network. But, the difference between rxlpf=1 and rxlpf=2 is pretty minor, and really only improves the response over a fairly narrow range at the very high end, which most people aren't going to notice.<br />
<br />
In summary, we believe if you switch all of the filters to 1 you'll be very happy with the improvement in quality and no further tweaking will be necessary. Our goal was to make the "1" filters - plug and play. The improvement will obviously be greatest when both the repeater you're on as well as the repeater of the user(s) you're talking to have the updated filter code, and have taken advantage of these filters.</div>W3KKChttps://wiki.pttlink.org/index.php?title=Audio_Filters&diff=919Audio Filters2018-04-18T14:43:37Z<p>W3KKC: New page on filters</p>
<hr />
<div>Hello AllStarLink Amateur Radio Operators,<br />
<br />
The release of AllStarLink 1.01 software package contains a feature pioneered by Jeff DePolo, WN3A. It is a set of audio filters for amateur radio applications. The default transmit and receive filters were designed around commercial standards. However, because amateur radio operators have the resources to use wider bandwidths, especially on UHF, they may prefer other filter types in order to provide higher audio quality. Over the years there have been other fixes for the usbradio channel driver minimizing the distortions. The results below proves the distortions are considerably lower than what a typical radio/repeater will add into the audio chain (.8% for the application vs. 3 to 5% or more for the radio). Contrary to what you may have read elsewhere, the dynamic range of this application, when properly deployed, is far beyond the capabilities of wide-band FM radio.<br />
<br />
The following settings can be optionally used in a USB radio interface context in "/etc/asterisk/usbradio.conf". If these keyword and value pairs are not present, their values default to zero (0). These alternate filters should be used with care. Note that additional computing power and radio adjustments may be necessary depending on your application. They have been extensively tested and work fine even with the Raspberry Pi3. Unlike other distributions, we encourage the use of the usbradio channel driver (chan_usbradio), or what we commonly call "Full DSP" in AllStarLink 1.01. This feature will also work in simpleusb, if that's what you prefer.<br />
<br />
This feature is immediately available in new AllStarLink installations and updates. <br />
<br />
Receiver Audio Low Pass Filter Options:<br />
rxlpf=0; 3.0 kHz cutoff. Default value for reduced noise and increased intelligibility.<br />
rxlpf=1; 3.3 kHz cutoff for increased high end, sibilance, and brightness.<br />
rxlpf=2; 3.5 kHz cutoff for even more high end, sibilance, and brightness.<br />
<br />
Receiver Audio High Pass Filter Options:<br />
rxhpf=0; 300 Hz cutoff. Default value to reduce sub-audible signals for retransmission, and also in the receiver speaker.<br />
rxhpf=1; 250 Hz cutoff for additional received and retransmitted bass response. We recommend using this filter with a CTCSS tone no higher than 186.2 Hz.<br />
<br />
Transmitter Audio Low Pass Filter Options:<br />
txlpf=0; 3.0 kHz cutoff. Default value.<br />
txlpf=1; 3.3 kHz cutoff for increased high end, sibilance and brightness.<br />
<br />
Transmitter Audio High Pass Filter Options:<br />
txhpf=0; 300 Hz cutoff. Default value to reduce interference between voice and sub-audible signaling tones and codes.<br />
txhpf=1; 250 Hz cutoff for increased bass response in transmitted audio.<br />
txhpf=2; 120 Hz cutoff for special applications requiring additional bass response in transmitted audio. Not recommended due to the increased possibility of voice energy interfering with sub-audible signaling, but should work okay with very low CTCSS frequencies.<br />
<br />
Key points and specifications:<br />
1, All filter combinations yield aliasing distortion/folding at or below -40 dBr. Note that all testing was done with the usbradio channel driver using discriminator (flat) Rx audio, and with Tx audio preemphasis in software. The measurements that follow *include* the low-pass filter inside the DMK URI in the transmit audio path, which is down about 3 dB at 3.5 kHz. The frequency response is better with a modified fob or radio adapters with wider frequency response. <br />
<br />
2. The variations in amplitude response within the passband as you switch filters are fairly minor. A perfectionist would re-calibrate both rx and tx levels after switching filters in the conf files, but if you're not at the site with a service monitor, but you shouldn't be afraid to switch filters without recalibrating as the variation is less than 0.3 dB @ 1 kHz worst-case among all filter combinations. Yeah, the filters were designed for unity gain, but there's a little ripple in the passband, plus the ulaw effects, so nothing's perfect, but it's close enough to perfect to not worry about.<br />
<br />
3. THD did not appreciably change as filters were varied, it tends to hover around 0.8% from 300 Hz to wherever the LPF's start to kick in. At low amplitudes (either due to low audio levels or filter skirt attenuation), obviously distortion, as a ratioed value, appears to rise due to quantization noise, but that's unavoidable in our little 8 bit ulaw corner of the world. IMD was likewise acceptable across the range.<br />
<br />
The developers recommend the following settings:<br />
Start off with all of the filters (rxlpf, rxhpf, txlpf, txhpf) set to 1. This will make a marked improvement in frequency response, both as far as local repeat audio goes as well as through the network. With the default (zero) filters, frequency response is pretty restricted. <br />
<br />
Here's a brief synopsis of what the frequency response from Rx to Tx is like with the DEFAULT (zero) filters that everybody is currently using:<br />
<br />
< -40 dB @ 210 Hz and below<br />
-20 dB @ 250 Hz<br />
-13.3 dB @ 275 Hz<br />
-7.9 dB @ 300 Hz<br />
-1.4 dB @ 350 Hz<br />
1.1 dB @ 400 Hz<br />
0.2 dB @ 500 Hz<br />
0.5 dB @ 600 Hz<br />
* +1.5 dB @ 425 Hz<br />
* +1.0 dB @ 675<br />
0.7 dB @ 700 Hz<br />
0.2 dB @ 800 Hz<br />
0.6 dB @ 900 Hz<br />
0 dB @ 1 kHz<br />
-0.1 dB @ 1.2 kHz<br />
-0.4 dB @ 1.4 kHz<br />
-0.6 dB @ 1.6 kHz<br />
-0.6 dB @ 1.8 kHz<br />
-0.3 dB @ 2.0 kHz<br />
0.1 dB @ 2.2 kHz<br />
-0.2 dB @ 2.4 kHz<br />
-1.4 dB @ 2.6 kHz<br />
-4.1 dB @ 2.8 kHz<br />
-9.0 dB @ 3.0 kHz<br />
-16.3 dB @ 3.2 kHz<br />
-26 dB @ 3.4 kHz<br />
< -40 dB @ 3.6 kHz and above<br />
<br />
So, you can see that the low-end suffers quite a bit, as it's almost 8 dB down at 300 Hz. It also has overshoots in excess of 1 dB centered at 425 and 675 Hz. The high end falls off quite sharply as well.<br />
<br />
By switching to all 1's for the filters, here's what the response is like:<br />
<br />
< -40 dB @ 180 and below<br />
-37 dB @ 186.2 Hz<br />
-16.5 dB @ 220 Hz<br />
-9.2 dB @ 240 Hz<br />
-4.5 dB @ 260 Hz<br />
-2.0 dB @ 275 Hz<br />
-1.6 dB @ 280 Hz<br />
-1.0 dB @ 286 Hz<br />
-0.1 dB @ 300 Hz<br />
+0.5 dB @ 330 Hz<br />
0 dB @ 1 kHz<br />
-0.5 dB @ 2.4 kHz<br />
-1.0 dB @ 2.77 kHz<br />
-2.0 dB @ 3.0 kHz<br />
-6.9 dB @ 3.2 kHz<br />
-15.2 dB @ 3.4 kHz<br />
-29 dB @ 3.6 kHz<br />
< -40 dB @ 3.7 kHz and above<br />
<br />
Notice the improvement at the low end and high end. The frequency response is flat to within ± 1 dB from 286 Hz to 2.77 kHz. Regardless of what low-pass filtering you have (or don't have) in your transmitter, nor what your channel spacing is (15 kHz versus 20/25), you should have no problems as far as excessive occupied bandwidth using all 1's for the filters. HOWEVER (and here's a big however), the CM108, even when not being sent data by the channel driver, has about 350 uV RMS of residual wideband noise, with energy primarily falling at harmonics of the sample rate (48 kHz). 350 uV is about 71 dB below the maximum output level of the CM108 best-case, but the ratio may be much worse than that depending on how low you have txvoice set (i.e. it may only end up being 30 or 40 dB down if your Tx has a sensitive input and you have txvoice set accordingly low). As such, we strongly DO NOT recommend feeding a CM108/119 output directly to the modulator without low-pass filtering in the exciter, or optionally in the radio adapter. The LPF doesn't need to be anywhere near as aggressive as it would be in a stock radio of course, but it should sufficiently attenuate everything in the ultrasonic range. As always, you should proof your contraptions with a spectrum analyzer before sticking them on a mountaintop!<br />
<br />
Deviations from all filters being set to 1 follow:<br />
If you are using a PL tone higher ABOVE 186.2 Hz and you do NOT have an external PL filter in the repeater receiver, then leave rxhpf at 0. Otherwise, you will start putting receive audio onto the network with insufficient PL filtering (we like to see 40 dB of PL rejection, but -37 dB at 186.2 is close enough).<br />
<br />
If you do have an external PL reject filter in the receiver, you should be able to use rxhpf=1 no matter what tone you're using.<br />
<br />
Some receiver discriminators have a little more high-end rolloff than others. At your option, and after adequate testing, going to rxlpf=2 shouldn't cause any problems either locally or on the network. But, the difference between rxlpf=1 and rxlpf=2 is pretty minor, and really only improves the response over a fairly narrow range at the very high end, which most people aren't going to notice.<br />
<br />
In summary, we believe if you switch all of the filters to 1 you'll be very happy with the improvement in quality and no further tweaking will be necessary. Our goal was to make the "1" filters - plug and play. The improvement will obviously be greatest when both the repeater you're on as well as the repeater of the user(s) you're talking to have the updated filter code, and have taken advantage of these filters.</div>W3KKChttps://wiki.pttlink.org/index.php?title=Main_Page&diff=918Main Page2018-04-18T14:42:01Z<p>W3KKC: </p>
<hr />
<div>Welcome to the AllStarLink WiKi. AllStarLink is a world wide network of [https://en.wikipedia.org/wiki/Amateur_radio Amateur Radio] repeaters, remote base stations and hot spots accessible to each other via the Internet and/or private IP networks. AllStarLink runs on a dedicated Linux computer (including the Rasperry Pi) that you host at your home, radio site or computer center. It is based on the open source Asterisk PBX. The app_rpt module it makes a powerful radio/repeater controller. AllStarLink is open source GPL software free for anyone to use.<br />
<br />
Recently we've moved some things off of this front page. If you don't see what you are looking for look at the [[:Category:How to|How To's]] or use search located on the top of every page. Also check our old docs site [http://docs.allstarlink.org docs.allstarlink.org]. We're gradually moving content from there to this WiKi.<br />
<br />
__NOTOC__<br />
=AllStarLink Menu=<br />
*[[The Organization - AllStarLink Inc. ]] - Who is AllStarLink?<br />
*[[ASL FAQ]] - Questions and answers about the AllStarLink software distribution.<br />
*[[Features]] - List of AllStarLink Features <br />
*[[:Category:How to|How To's]] - A collection of AllStarLink how to's.<br />
*[[:Category:Node Configuration|Node Configuration]] - Detail configuration settings.<br />
*[[Radio Connections]] - Instructions to Connect Radios, Repeaters and Other Devices to AllStar.<br />
<br />
=Downloads=<br />
* [http://dvswitch.org/files/ASL_Images/Intel-AMD/Stretch/ASL_1.01-20180228-amd64-i386-debian-stretch-netinst.zip ASL AMD] Latest AllStarLink installer for x86/AMD <br />
* [http://dvswitch.org/files/ASL_Images/Raspberry_Pi/Stretch/ASL_1.01-20180228-armhf-raspbian-stretch-image.zip ASL Pi] Latest AllStarLink image for the Raspberry Pi<br />
<br />
* [http://dvswitch.org/files/ASL_Images/ ASL Repo] AllStarLink Image Repository<br />
<br />
= Features =<br />
* [[Audio Filters]] - Optional filters for making the audio wider on both the lower and upper frequency limit.<br />
<br />
=Related Links=<br />
* [https://allstarlink.org/ AllStarLink Portal] - If you are looking to set up your own AllStarLink node.<br />
* [http://stats.allstarlink.org/ AllStarLink Stats] - shows all the existing public nodes.<br />
* [http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users AllStarLink users mailing list]- This is the app_rpt mailing list for discussion, help and helping others.<br />
* [https://allstar.aargdmr.net/ Development Portal Site] - Our Portal development site. Check out the searchable and sortable [https://allstar.aargdmr.net/nodelist/ Node List].<br />
* [https://github.com/AllStarLink/ Source Code] - All of the source code for the AllStarLink Asterisk and app_rpt is available on GitHub. <br />
<br />
=History=<br />
* [[History]] from the Duuude, Jim Dixon WB6NIL SK 12/16/2016.</div>W3KKChttps://wiki.pttlink.org/index.php?title=Main_Page&diff=917Main Page2018-04-18T14:40:23Z<p>W3KKC: Added a "Features" section</p>
<hr />
<div>Welcome to the AllStarLink WiKi. AllStarLink is a world wide network of [https://en.wikipedia.org/wiki/Amateur_radio Amateur Radio] repeaters, remote base stations and hot spots accessible to each other via the Internet and/or private IP networks. AllStarLink runs on a dedicated Linux computer (including the Rasperry Pi) that you host at your home, radio site or computer center. It is based on the open source Asterisk PBX. The app_rpt module it makes a powerful radio/repeater controller. AllStarLink is open source GPL software free for anyone to use.<br />
<br />
Recently we've moved some things off of this front page. If you don't see what you are looking for look at the [[:Category:How to|How To's]] or use search located on the top of every page. Also check our old docs site [http://docs.allstarlink.org docs.allstarlink.org]. We're gradually moving content from there to this WiKi.<br />
<br />
__NOTOC__<br />
=AllStarLink Menu=<br />
*[[The Organization - AllStarLink Inc. ]] - Who is AllStarLink?<br />
*[[ASL FAQ]] - Questions and answers about the AllStarLink software distribution.<br />
*[[Features]] - List of AllStarLink Features <br />
*[[:Category:How to|How To's]] - A collection of AllStarLink how to's.<br />
*[[:Category:Node Configuration|Node Configuration]] - Detail configuration settings.<br />
*[[Radio Connections]] - Instructions to Connect Radios, Repeaters and Other Devices to AllStar.<br />
<br />
=Downloads=<br />
* [http://dvswitch.org/files/ASL_Images/Intel-AMD/Stretch/ASL_1.01-20180228-amd64-i386-debian-stretch-netinst.zip ASL AMD] Latest AllStarLink installer for x86/AMD <br />
* [http://dvswitch.org/files/ASL_Images/Raspberry_Pi/Stretch/ASL_1.01-20180228-armhf-raspbian-stretch-image.zip ASL Pi] Latest AllStarLink image for the Raspberry Pi<br />
<br />
* [http://dvswitch.org/files/ASL_Images/ ASL Repo] AllStarLink Image Repository<br />
<br />
= Features =<br />
Audio Filters - Optional filters for making the audio wider on both the lower and upper frequency limit.<br />
<br />
=Related Links=<br />
* [https://allstarlink.org/ AllStarLink Portal] - If you are looking to set up your own AllStarLink node.<br />
* [http://stats.allstarlink.org/ AllStarLink Stats] - shows all the existing public nodes.<br />
* [http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users AllStarLink users mailing list]- This is the app_rpt mailing list for discussion, help and helping others.<br />
* [https://allstar.aargdmr.net/ Development Portal Site] - Our Portal development site. Check out the searchable and sortable [https://allstar.aargdmr.net/nodelist/ Node List].<br />
* [https://github.com/AllStarLink/ Source Code] - All of the source code for the AllStarLink Asterisk and app_rpt is available on GitHub. <br />
<br />
=History=<br />
* [[History]] from the Duuude, Jim Dixon WB6NIL SK 12/16/2016.</div>W3KKChttps://wiki.pttlink.org/index.php?title=ASLCorporate:The_Organization_-_AllStarLink_Inc.&diff=909ASLCorporate:The Organization - AllStarLink Inc.2018-04-04T00:38:02Z<p>W3KKC: </p>
<hr />
<div>Admin team announcement:<br />
<br />
<br />
With the release of All Star Link 1.01, AllStarLink, Inc. is happy to announce some organizational improvements. In the time since Jim Dixon's passing we have not only made much progress on keeping the services running, but improving the availability of the ASL core services. On the organizational front we have incorporated as a non-for-profit devoted to running the All Star network and shepherding the development of app_rpt and asterisk for amateur radio.<br />
<br />
<br />
AllStarLink, Inc. was formed as a Florida non-for-profit with the goals of continuing Jim's vision for enhancing communications between amateurs around the world. We're in the process of attaining 501(c)3 enabling all donations to be tax-deductible, and to show good stewardship of our supporters funds. We've segmented operations into two parts, one of running/improving network services, and the larger group doing development.<br />
<br />
<br />
The development team is focused on improving on the codebase and updating asterisk and app_rpt. Over the next year we intend to move to a more recent version of asterisk, if not the current version. This will enable much needed updates for security and new network protocols.<br />
<br />
<br />
The dev team is always looking for skilled coders (mostly C for app_rpt) who can devote time and help out. The main codebase is on github <https://github.com/AllStarLink/> and patches are always encouraged.<br />
<br />
<br />
Our admin team is responsible for all infrastructure which keeps the network talking, such as:<br />
Distributed registration service, Stats server, User portal, DNS, Email, GitHub, and Backend database and backup servers.<br />
<br />
<br />
A new user portal has been under development on <https://allstar.aargdmr.net/> and will go live once it's ready. This is no small development, there are many moving parts to the backend of ASL, and the portal ties all that together.<br />
<br />
<br />
Everyone should notice the new look to the stats server and the enhanced maps. The maps server receives about 200 updates per second from connected nodes and it's been moved to much beefier server equipped to handle the load. Under the hood we've been moving to docker for all services.<br />
<br />
<br />
The admin team also verifies all new users and handles the day to day operations. The documentation is for most of the backend API's is in the wiki and many of the docs from docs.allstarlink.org have been moved to the wiki. The eventual goal is to shut off docs.allstarlink.org and only suppor the wiki. Wiki's are awesome as userbase can bugfix the docs then and there. The team is always looking for assistance with documentation; some knowledge of wiki or a desire to learn it is required.<br />
<br />
<br />
The board is seeking those who share Jim's vision and commitment to Open Source and have some managerial experience to join us on the board. AllStarLink need those with drive and commitment to run the non-profit side of things. We're actively seeking a treasurer (US person) and would like to at least double the size of the board.<br />
<br />
<br />
For AllStarLink, Inc:<br />
<br />
Chairman Emeritus:<br />
<br />
Jim Dixon, WB6NIL<br />
<br />
<br />
Directors:<br />
<br />
Steve Zingman, N4IRS<br />
<br />
Kevin Custer, W3KKC<br />
<br />
Tim Sawyer, WD6AWP<br />
<br />
Bryan Fields, W9CR</div>W3KKChttps://wiki.pttlink.org/index.php?title=ASLCorporate:The_Organization_-_AllStarLink_Inc.&diff=908ASLCorporate:The Organization - AllStarLink Inc.2018-04-04T00:37:36Z<p>W3KKC: </p>
<hr />
<div>Admin team announcement:<br />
<br />
<br />
With the release of All Star Link 1.01, AllStarLink, Inc. is happy to announce some organizational improvements. In the time since Jim Dixon's passing we have not only made much progress on keeping the services running, but improving the availability of the ASL core services. On the organizational front we have incorporated as a non-for-profit devoted to running the All Star network and shepherding the development of app_rpt and asterisk for amateur radio.<br />
<br />
<br />
AllStarLink, Inc. was formed as a Florida non-for-profit with the goals of continuing Jim's vision for enhancing communications between amateurs around the world. We're in the process of attaining 501(c)3 enabling all donations to be tax-deductible, and to show good stewardship of our supporters funds. We've segmented operations into two parts, one of running/improving network services, and the larger group doing development.<br />
<br />
<br />
The development team is focused on improving on the codebase and updating asterisk and app_rpt. Over the next year we intend to move to a more recent version of asterisk, if not the current version. This will enable much needed updates for security and new network protocols.<br />
<br />
<br />
The dev team is always looking for skilled coders (mostly C for app_rpt) who can devote time and help out. The main codebase is on github <https://github.com/AllStarLink/> and patches are always encouraged.<br />
<br />
<br />
Our admin team is responsible for all infrastructure which keeps the network talking, such as:<br />
Distributed registration service, Stats server, User portal, DNS, Email, GitHub, and Backend database and backup servers.<br />
<br />
<br />
A new user portal has been under development on <https://allstar.aargdmr.net/> and will go live once it's ready. This is no small development, there are many moving parts to the backend of ASL, and the portal ties all that together.<br />
<br />
<br />
Everyone should notice the new look to the stats server and the enhanced maps. The maps server receives about 200 updates per second from connected nodes and it's been moved to much beefier server equipped to handle the load. Under the hood we've been moving to docker for all services.<br />
<br />
<br />
The admin team also verifies all new users and handles the day to day operations. The documentation is for most of the backend API's is in the wiki and many of the docs from docs.allstarlink.org have been moved to the wiki. The eventual goal is to shut off docs.allstarlink.org and only suppor the wiki. Wiki's are awesome as userbase can bugfix the docs then and there. The team is always looking for assistance with documentation; some knowledge of wiki or a desire to learn it is required.<br />
<br />
<br />
The board is seeking those who share Jim's vision and commitment to Open Source and have some managerial experience to join us on the board. AllStarLink need those with drive and commitment to run the non-profit side of things. We're actively seeking a treasurer (US person) and would like to at least double the size of the board.<br />
<br />
<br />
For AllStarLink, Inc:<br />
<br />
<br />
Chairman Emeritus:<br />
<br />
Jim Dixon, WB6NIL<br />
<br />
<br />
Directors:<br />
<br />
Steve Zingman, N4IRS<br />
<br />
Kevin Custer, W3KKC<br />
<br />
Tim Sawyer, WD6AWP<br />
<br />
Bryan Fields, W9CR</div>W3KKChttps://wiki.pttlink.org/index.php?title=ASLCorporate:The_Organization_-_AllStarLink_Inc.&diff=907ASLCorporate:The Organization - AllStarLink Inc.2018-04-04T00:36:23Z<p>W3KKC: Created page with "Admin team announcement: With the release of All Star Link 1.01, AllStarLink, Inc. is happy to announce some organizational improvements. In the time since Jim Dixon's pass..."</p>
<hr />
<div>Admin team announcement:<br />
<br />
<br />
With the release of All Star Link 1.01, AllStarLink, Inc. is happy to announce some organizational improvements. In the time since Jim Dixon's passing we have not only made much progress on keeping the services running, but improving the availability of the ASL core services. On the organizational front we have incorporated as a non-for-profit devoted to running the All Star network and shepherding the development of app_rpt and asterisk for amateur radio.<br />
<br />
<br />
AllStarLink, Inc. was formed as a Florida non-for-profit with the goals of continuing Jim's vision for enhancing communications between amateurs around the world. We're in the process of attaining 501(c)3 enabling all donations to be tax-deductible, and to show good stewardship of our supporters funds. We've segmented operations into two parts, one of running/improving network services, and the larger group doing development.<br />
<br />
<br />
The development team is focused on improving on the codebase and updating asterisk and app_rpt. Over the next year we intend to move to a more recent version of asterisk, if not the current version. This will enable much needed updates for security and new network protocols.<br />
<br />
<br />
The dev team is always looking for skilled coders (mostly C for app_rpt) who can devote time and help out. The main codebase is on github <https://github.com/AllStarLink/> and patches are always encouraged.<br />
<br />
<br />
Our admin team is responsible for all infrastructure which keeps the network talking, such as:<br />
Distributed registration service, Stats server, User portal, DNS, Email, GitHub, and Backend database and backup servers.<br />
<br />
<br />
A new user portal has been under development on <https://allstar.aargdmr.net/> and will go live once it's ready. This is no small development, there are many moving parts to the backend of ASL, and the portal ties all that together.<br />
<br />
<br />
Everyone should notice the new look to the stats server and the enhanced maps. The maps server receives about 200 updates per second from connected nodes and it's been moved to much beefier server equipped to handle the load. Under the hood we've been moving to docker for all services.<br />
<br />
<br />
The admin team also verifies all new users and handles the day to day operations. The documentation is for most of the backend API's is in the wiki and many of the docs from docs.allstarlink.org have been moved to the wiki. The eventual goal is to shut off docs.allstarlink.org and only suppor the wiki. Wiki's are awesome as userbase can bugfix the docs then and there. The team is always looking for assistance with documentation; some knowledge of wiki or a desire to learn it is required.<br />
<br />
<br />
The board is seeking those who share Jim's vision and commitment to Open Source and have some managerial experience to join us on the board. AllStarLink need those with drive and commitment to run the non-profit side of things. We're actively seeking a treasurer (US person) and would like to at least double the size of the board.<br />
<br />
<br />
For AllStarLink, Inc:<br />
<br />
<br />
Chairman Emeritus:<br />
<br />
Jim Dixon, WB6NIL<br />
<br />
Directors:<br />
<br />
Steve Zingman, N4IRS<br />
<br />
Kevin Custer, W3KKC<br />
<br />
Tim Sawyer, WD6AWP<br />
<br />
Bryan Fields, W9CR</div>W3KKChttps://wiki.pttlink.org/index.php?title=Main_Page&diff=906Main Page2018-04-04T00:21:27Z<p>W3KKC: Add organization announcement</p>
<hr />
<div>Welcome to the AllStarLink WiKi. AllStarLink is a world wide network of [https://en.wikipedia.org/wiki/Amateur_radio Amateur Radio] repeaters, remote base stations and hot spots accessible to each other via the Internet and/or private IP networks. AllStarLink runs on a dedicated Linux computer (including the Rasperry Pi) that you host at your home, radio site or computer center. It is based on the open source Asterisk PBX. The app_rpt module it makes a powerful radio/repeater controller. AllStarLink is open source GPL software free for anyone to use.<br />
<br />
Recently we've moved some things off of this front page. If you don't see what you are looking for look at the [[:Category:How to|How To's]] or use search located on the top of every page. Also check our old docs site [http://docs.allstarlink.org docs.allstarlink.org]. We're gradually moving content from there to this WiKi.<br />
<br />
__NOTOC__<br />
=AllStarLink Menu=<br />
*[[The Organization - AllStarLink Inc. ]] - Who is AllStarLink?<br />
*[[ASL FAQ]] - Questions and answers about the AllStarLink software distribution.<br />
*[[Features]] - List of AllStarLink Features <br />
*[[:Category:How to|How To's]] - A collection of AllStarLink how to's.<br />
*[[:Category:Node Configuration|Node Configuration]] - Detail configuration settings.<br />
*[[Radio Connections]] - Instructions to Connect Radios, Repeaters and Other Devices to AllStar.<br />
<br />
=Downloads=<br />
* [http://dvswitch.org/files/ASL_Images/Intel-AMD/Stretch/ASL_1.01-20180228-amd64-i386-debian-stretch-netinst.zip ASL AMD] Latest AllStarLink installer for x86/AMD <br />
* [http://dvswitch.org/files/ASL_Images/Raspberry_Pi/Stretch/ASL_1.01-20180228-armhf-raspbian-stretch-image.zip ASL Pi] Latest AllStarLink image for the Raspberry Pi<br />
<br />
* [http://dvswitch.org/files/ASL_Images/ ASL Repo] AllStarLink Image Repository<br />
<br />
=Related Links=<br />
* [https://allstarlink.org/ AllStarLink Portal] - If you are looking to set up your own AllStarLink node.<br />
* [http://stats.allstarlink.org/ AllStarLink Stats] - shows all the existing public nodes.<br />
* [http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users AllStarLink users mailing list]- This is the app_rpt mailing list for discussion, help and helping others.<br />
* [https://allstar.aargdmr.net/ Development Portal Site] - Our Portal development site. Check out the searchable and sortable [https://allstar.aargdmr.net/nodelist/ Node List].<br />
* [https://github.com/AllStarLink/ Source Code] - All of the source code for the AllStarLink Asterisk and app_rpt is available on GitHub. <br />
<br />
=History=<br />
* [[History]] from the Duuude, Jim Dixon WB6NIL SK.</div>W3KKChttps://wiki.pttlink.org/index.php?title=Radio_Connections&diff=750Radio Connections2017-11-01T01:17:05Z<p>W3KKC: </p>
<hr />
<div>Instructions for connecting radios, repeaters and AllStarLink interfaces including the RTCM, GPS, URI/URI X and like devices. <br />
=GPS=<br />
* [[Media:RTCM 2 Trimble.pdf|Trimble RTCM Interface Cable]]<br />
* [[Media:RTCM 321 Cable.graffle.pdf|Trimble to Two RTCMs and Lady Heather Cable]]<br />
* [[Media:RTCM to BG7TBL Cable.pdf|BG7TBL GPS / RTCM Cable]]<br />
<br />
=Motorola=<br />
<br />
==CDM==<br />
CDMs make great nodes. This eBay reseller has very nice cables. Use to connect to URI or RTCM. <br />
<br />
[[Media:CDM Cable.pdf|CDM Cable from Kurt Meltzer]] ex-WB9KNX, now KC4NX - Cable 83 has only one output to use for either COS or CTCSS. Use another cable if you need both COS and CTCSS.<br />
<br />
==MTR-2000==<br />
<br />
==Quantar==<br />
<br />
The Quantar can be tricky to interface as it's extremely programmable and you will need a wireline card for I/O connections. By default the I/O will not work unless the "wildcard" table is programed. This wildcard table is Boolean logic of interrupt states in the radio, is extremely flexible and frustrating to debug. It's a base station in it's own class.<br />
<br />
[[File:Front of quantar and controller.jpg|thumb|400px|right|Front of Quantar and controller]]<br />
<br />
* [[Media:QUANTAR-RTCM INTERFACE CABLE.pdf|Quantar/RTCM Interface Cable]]<br />
<br />
Note you will want to use [[RTCM_Client#DSP.2FBEW_Firmware_Version|BEW mode]] on the RTCM if using the RTCM do squelch.<br />
<br />
* [[Media:RTCM 2 Quantar.pdf|Another Quantar/RTCM Interface Cable]]<br />
* [[Media:RTCM to Astro-TAC Cable.pdf|Astro-TAC/RTCM Interface Cable]]<br />
* [http://wiki.w9cr.net/index.php/Allstar_and_P25_on_Quantar Interfacing to a Quantar with P25NX] - Bryan Fields W9CR has page on interfacing the Qunatar using simple USB into Allstar and P25NX linking at the same time. This is driven by programing on the Quantar Wildcard tables.<br />
*[[Media:Quantar URI Interface.jpg|Quantar/URI Cable]]<br />
*[[Media:QuantarMRTI2URI.jpg|Quantar MRTI/URI Cable]]<br />
<br />
==Syntor X==<br />
The Motorola Syntor X with an Xcat installed makes a great frequency agile remote base. For more information see this [http://wd6awp.net/xcat/ Syntor Xcat] page. <br />
<br />
==VRM-850==<br />
<br />
=Kenwood=<br />
==TKR720/820==<br />
Connections to: PTT, COS, RX audio out and MIC audio in<br />
<br />
TX/RX board, MIC audio input, pins 4 & 5: floating ground, must not tie to any other ground! Some installations may require a 10dB, resistor L-network consisting of a 4.7k and 470 ohm resistors. The 470 ohm resistor connection across pins four and five, the 4.7k resistor is soldered to pin 5 to which your TX audio from the URI will connect to.<br />
<br />
The MIC audio gain, deviation, and balance adjustments are *very* sensitive! <br />
<br />
- RA-35 without TX adj. trimmer pots: Using a service monitor with deviation metering, start low and work your way up to 3KHz deviation with 1KHz tone, generated by simpleusb-tune-menu. If enabled, *904 turns this tone on and off by command, ie, no tone time-out as in simpleusb-tune-menu.<br />
<br />
== TKR750/850 ==<br />
[http://www.masterscommunications.com/products/radio-adapter/txt/tkr.txt Using the Masters Communications RA-35 or RA-40 radio adapters with the TKR750/850]<br />
<br />
=Repeater Controller=<br />
<br />
[[Media:RTCMwithController.pdf|An example of using RTCMs to replace 420 links]]<br />
<br />
=Spectra Engineering=<br />
* [http://wiki.w9cr.net/index.php/MX800#W9CR_alignment_procedure_and_setup_with_Allstar MX800 Base station] - Bryan Fields, W9CR has a complete setup guide for the MX800 Base station which includes fallback to the built in controller and an audio delay module.<br />
<br />
=Tait=<br />
<br />
=URI / URI X=<br />
The URI is manufactured and sold by [http://dmkeng.com/URI_Order_Page.htm DMK Engineering]. <br />
*[[Media:URI Schematic.pdf|URI Schematic]]<br />
*[[Media:URIx Schematic.pdf|URI X Schematic]]<br />
<br />
=RA-40 / RA-35=<br />
The RA-40 is the latest version and is sold by W3KKC. The RA-40 includes audio output level control potentiometers and much more.<br />
*[http://www.masterscommunications.com/products/radio-adapter/ra40.html RA-40]<br />
*[http://www.masterscommunications.com/products/radio-adapter/ra35.html RA-35]<br />
<br />
=Vertex=<br />
* [[Media:RTCM 2 VRX-5000.pdf|VRX-5000 / RTCM Interface Cable]]<br />
<br />
[[Category:How to]]</div>W3KKChttps://wiki.pttlink.org/index.php?title=Radio_Connections&diff=749Radio Connections2017-10-30T20:14:58Z<p>W3KKC: /* Kenwood */</p>
<hr />
<div>Instructions for connecting radios, repeaters and AllStarLink interfaces including the RTCM, GPS, URI/URI X and like devices. <br />
=GPS=<br />
* [[Media:RTCM 2 Trimble.pdf|Trimble RTCM Interface Cable]]<br />
* [[Media:RTCM 321 Cable.graffle.pdf|Trimble to Two RTCMs and Lady Heather Cable]]<br />
* [[Media:RTCM to BG7TBL Cable.pdf|BG7TBL GPS / RTCM Cable]]<br />
<br />
=Motorola=<br />
<br />
==CDM==<br />
CDMs make great nodes. This eBay reseller has very nice cables. Use to connect to URI or RTCM. <br />
<br />
[[Media:CDM Cable.pdf|CDM Cable from Kurt Meltzer]] ex-WB9KNX, now KC4NX - Cable 83 has only one output to use for either COS or CTCSS. Use another cable if you need both COS and CTCSS.<br />
<br />
==MTR-2000==<br />
<br />
==Quantar==<br />
<br />
The Quantar can be tricky to interface as it's extremely programmable and you will need a wireline card for I/O connections. By default the I/O will not work unless the "wildcard" table is programed. This wildcard table is Boolean logic of interrupt states in the radio, is extremely flexible and frustrating to debug. It's a base station in it's own class.<br />
<br />
[[File:Front of quantar and controller.jpg|thumb|400px|right|Front of Quantar and controller]]<br />
<br />
* [[Media:QUANTAR-RTCM INTERFACE CABLE.pdf|Quantar/RTCM Interface Cable]]<br />
<br />
Note you will want to use [[RTCM_Client#DSP.2FBEW_Firmware_Version|BEW mode]] on the RTCM if using the RTCM do squelch.<br />
<br />
* [[Media:RTCM 2 Quantar.pdf|Another Quantar/RTCM Interface Cable]]<br />
* [[Media:RTCM to Astro-TAC Cable.pdf|Astro-TAC/RTCM Interface Cable]]<br />
* [http://wiki.w9cr.net/index.php/Allstar_and_P25_on_Quantar Interfacing to a Quantar with P25NX] - Bryan Fields W9CR has page on interfacing the Qunatar using simple USB into Allstar and P25NX linking at the same time. This is driven by programing on the Quantar Wildcard tables.<br />
*[[Media:Quantar URI Interface.jpg|Quantar/URI Cable]]<br />
*[[Media:QuantarMRTI2URI.jpg|Quantar MRTI/URI Cable]]<br />
<br />
==Syntor X==<br />
The Motorola Syntor X with an Xcat installed makes a great frequency agile remote base. For more information see this [http://wd6awp.net/xcat/ Syntor Xcat] page. <br />
<br />
==VRM-850==<br />
<br />
=Kenwood=<br />
==TKR720/820==<br />
Connections to: PTT, COS, RX audio out and MIC audio in<br />
<br />
TX/RX board, MIC audio input, pins 4 & 5: floating ground, must not tie to any other ground! Some installations may require a 10dB, resistor L-network consisting of a 4.7k and 470 ohm resistors. The 470 ohm resistor connection across pins four and five, the 4.7k resistor is soldered to pin 5 to which your TX audio from the URI will connect to.<br />
<br />
The MIC audio gain, deviation, and balance adjustments are *very* sensitive! <br />
<br />
- RA-35 without TX adj. trimmer pots: Using a service monitor with deviation metering, start low and work your way up to 3KHz deviation with 1KHz tone, generated by simpleusb-tune-menu. If enabled, *904 turns this tone on and off by command, ie, no tone time-out as in simpleusb-tune-menu.<br />
<br />
== TKR750/850 ==<br />
[http://www.masterscommunications.com/products/radio-adapter/txt/tkr.txt Using the Masters Communications RA-35 or RA-40 radio adapters with the TKR750/850]<br />
<br />
=Repeater Controller=<br />
<br />
[[Media:RTCMwithController.pdf|An example of using RTCMs to replace 420 links]]<br />
<br />
=Spectra Engineering=<br />
* [http://wiki.w9cr.net/index.php/MX800#W9CR_alignment_procedure_and_setup_with_Allstar MX800 Base station] - Bryan Fields, W9CR has a complete setup guide for the MX800 Base station which includes fallback to the built in controller and an audio delay module.<br />
<br />
=Tait=<br />
<br />
=URI / URI X=<br />
The URI is manufactured and sold by [http://dmkeng.com/URI_Order_Page.htm DMK Engineering]. <br />
*[[Media:URI Schematic.pdf|URI Schematic]]<br />
*[[Media:URIx Schematic.pdf|URI X Schematic]]<br />
<br />
=RA-40 / RA-35=<br />
The RA-40 is the latest version and is sold by W3KKC. The RA-40 includes audio output filtering and much more.<br />
*[http://www.masterscommunications.com/products/radio-adapter/ra40.html RA-40]<br />
*[http://www.masterscommunications.com/products/radio-adapter/ra35.html RA-35]<br />
<br />
=Vertex=<br />
* [[Media:RTCM 2 VRX-5000.pdf|VRX-5000 / RTCM Interface Cable]]<br />
<br />
[[Category:How to]]</div>W3KKC