Ham Radio Software on Centos Linux
- Configuring multitudes of Amateur / HAM Radio software for Centos6 / Centos5 Linux


dranch at trinnet dot net


Enabling everything HAM radio on Centos Linux! This document is my journey into Linux-assisted HAM radio with Centos. This covers many different topics along my personal discovery which started with AX.25 packet radio, then into HF digital modes, and most recently SDR and D*star technologies! This doc will be constantly evolving (mostly focused on Centos6 today, used to be focused on Centos5) but here is the index to give you an idea of what it covers today:

   | Notice OF Upcomming Deprecation: Feb 2021                                                       |
   |                                                                                                 |
   |    I have come to the difficult decision to move away from the Centos distrubution for Amateur  |
   |    related uses.  Why?  The EOL of Centos6 in November 2021 forced my hand to start looking at  |
   |    Centos 7 or Centos 8 with the focus seemingly on Centos 8 as it's the newest release.  Now   |
   |    consider the news from IBM/Redhat to make Centos 8 and future versions to be a test platform |
   |    instead of a production quality OS.  Then there is the final and probably the most important |
   |    fact that Centos is generally a VERY difficult Linux distribution for HAM applications.  As  |
   |    such, I have decided to move over to Ubuntu 20.04 and start a new document for that OS and   |
   |    STOP MAINTAINING this document.                                                              |
   |                                                                                                 |
   |    05/10/21 Update                                                                              |
   |    I have already started this new Ubuntu centric document yet nothing has been published yet.  |
   |    It's going to be using much of the same HamPacket and Raspberry Pi documentation formate as  |
   |    it's foundation.  It will take  time to get this new document as feature complete ias the    |
   |    HamPacket document but it will happen over time.                                                                            |


A. License - Here come the lawyers

This documentation and scripting set under the umbrella name of "Hampacketizing Centos" 
is copyrighted to David Ranch and licensed under a Creative Commons 
Attribution-Noncommercial-NoDerivs 3.0 Unported License.  Basically, this means:

  - The licensor permits others to copy, distribute and transmit only unaltered 
    copies of the work — not derivative works based on it.

     - If you distribute this document but would like to see additions changes
       made to it, you need to have those changes made by the author.  I'm 
       flexible and happy to help so don't be worried.

  - The licensor permits others to copy, distribute, display, and perform the work 
    for non-commercial purposes only.  If you're looking to use this document 
    or it's scripts in a commercial environment, contact the author (me) for


0. - Preface - How, What, Why, and other good software repos

This documentation notes my ongoing journey to get a fully featured 
HAMshack running on the Centos Linux distribution.  This document originally
started out for Centos5 on i386 but I'm actively moving over to Centos6 x86_64.
I will be adding in Centos6 specific requirements as I find them.  

Please understand that some of these notes can be messy at times and
some maybe downright confusing.  This was because I was keeping detailed 
notes of compile failures, etc. and some of those notes were helpful or 
might be helpful to other HAMs.  I'll clean them up as I go but if you
have any questions, need clarifications, etc., just email me!

Following the chapter order of this document can be very important at times
as each section of this document filled in the various dependencies needed 
by the follow-on installed software.

There are many other packages you might like to try out as highlighted
  on the Fedora Project HAM radio section:


    | Fedora is Centos..                                                   |
    |                                                                      |
    | If you didn't already know it, Centos 6 uses the same base libraries |
    | as Fedora 16.   Centos 5 uses the same libraries as  Fedora 9        |
    |                                                                      |

Debian also has a list of packages that have been patched and brought
under modern Linux kernels especially for AX.25 kernel facing stuff:

   http://packages.debian.org/squeeze/hamradio/   (stable)
     (has new packages like Chirp, SDR programs, 

OpenSuse also has a list of packages as well which can be helpful
to get .spec files, etc:


For other packages, one of the best HAM radio software for Linux directory
pages out there is:


   Other interesting Linux HAM software - some is covered in this document
     and is shown with a '*', other software is really old, etc.
   Digital modes:
      Fldigi    * GUI app to support CW, PSK31, RTTY, 

      Older tools:
        linpsk    - PSK31/RTTY app
        gMFSK     - GUI app to support CW, PSK31, RTTY, etc
        gpsk      - Gnome app for PSK
        kpsk      - KDE app for PSK
        lpsk      - PSK31/RTTY (ncurses and GTK+) - part of xpsk
        xpsk31    - PSK31/RTTY (ncurses and GTK+) - part of lpsk
        xfhell    - "fuzzy" digital communication mode known as Hellschreiber

   Rig control:
      Flrig     - Rig control with XML APIs 
      Hamlib    * master library to control various radios
      Grig      - radio controller via Hamlib

   AX.25 packet programs:
      Linpac     * Nice Linux NCURSES-based packet terminal and simple BBS software using the Linux AX.25 stack
      QtTermTCP  - A graphical Qt-based packet terminal program that can use either AGW or BPQ-TCP 
                   based connections.  Should work well with Direwolf
      EasyTerm   - A Windows graphical packet terminal and mailbox program that uses AGW (runs fine under 
      agwterm    - Windows terminal packet program via AGW (runs under WINE)
      IpSerial   - Included with Outpost Package manager for Windows (runs under WINE but has known bugs)
                   which have been reported
      LinKT      - LinKT is a KDE Packet Radio (AX25) Terminal with the Linux AX.25 terminal
      LinGT      - GNOME2 port of LinKT. LinKT is a KDE Packet Radio (AX25) Terminal with the Linux AX.25 terminal
      TnT        - WA8DED Hostmode or KISS TNC packet terminal program for Linux : http://home.snafu.de/wahlm/dptnt.html

      Direwolf   - software soundcard AX.25 packet TNC
      Soundmodem - UZ7HO's soundmodem software TNC for Windows under WINE
                   Wine for X86-computers) : http://uz7.ho.ua/packetradio.htm
      soundmodem - legacy software soundcard AX.25 packet TNC that really started it all

      Uronode    * Linux Packet node software using the Linux AX.25 stack
      BPQ32      * packet Bulletin board system and a lot more with it's own AX.25 stack or using the Linux AX.25 stack
      Jnos       * packet Bulletin board system with it's own AX.25 stack or using the Linux AX.25 stack
      FBB        - packet Bulletin board system using the Linux AX.25 stack
      Dpbox      - BBS for Linux : http://home.snafu.de/wahlm/dptnt.html

      xconvers   - IRC like client using the Internet or packet radio

   Digital / Analog SSTV
      Qsstv     * receive analog SSTV and FAXes

   Beacons / Propogation
      voacap    - The popular propagation software for Linux : https://www.voacap.com
      splat     - coverage analysis tool (web versions already active)
      hamcap    - graphical DX propagation prediction tool (cool!)
      ibp       * find HF beacons on the right bands at the right time

   RoIP / VoIP programs
      Svxlink   * voice synthesizer for supporting repeaters, etc for Echolink
      Qtel      - GUI client used with Svxlink
      thebridge - used for Echolink

   Logging and Cluster programs
      tqsl      * digital signatures for ARRL LOTW QSLs
      Xlog      - logging tool with hamlib support
      xwota     - similar to a dx cluster lookup system
      xdx       - DX cluster communications for DX notification
                  (there is also native TELNET access as well via the Internet)
      dxatlas   - check this software out:  http://www.dxatlas.com/
      dxcc      - CLI based callSign lookup

   Satellite decoding
      wxapt     - console app to decode and save NOAA and METEOR satellites
      xwxapt    - GTK+ app to decode and save NOAA and METEOR satellites

   CW / Morse programs
      cwskimmer - graphical wide-band decoder of CW across MANY frequencies
      aldo      - CW trainer
      demorse   - CW decoder from the soundcard (xdemorse)
      qrq       - CW trainer
      unixcw    - CLI CW training tools
      xdemorse  - console based CW decoding app

Ok, on with the show...

1. - PreSetup: Build Environment, 3rd party Yum repos, USB Serial ports, Compiler tuning, etc

Before we start compiling programs, we need a basic Build environment but different
programs will have additional requirements.  For example, here are some tables 
of what RPMs are required to build a custom Linux kernel for different Centos 

1.a - PreSetup: The Build Environment

     Centos5 (some rpms will be newer)  |  Centos6 (some rpms may be newer)
     gcc                                | gcc-4.4.6-3.el6.i686
     nasm                               | nasm-2.07-7.el6.i686
     rpm-build                          | rpm-build-4.8.0-19.el6.i686
                                        | asciidoc.noarch 0:8.4.5-4.1.el6
                                        | newt-devel.x86_64 0:0.52.11-3.el6 
     elinks                             | elinks-0.12-0.20.pre5.el6.i686
     unifdef                            | 

This document will detail those additional requirements in each of the different 
sections in this doc but for now, lets get the basics going:

   #Tools for the compiling environment
   #  Additional RPMs might be installed as well as required
   yum install gcc

   #Next, we need tools create RPMs and download code
   yum install rpm-build
   yum install elinks

Next, there is the build area.  It's recommended that to build code, you
shouldn't do it as the root user anymore (old school).  To support this new
approach, please see:




  NOTE:  There are additional optimizations contained below that I recommend 
         to put into this newer Build environment setup

  | Important Note:                                                        |
  |                                                                        |
  |    This document currently uses the older ROOT based /usr/src/redhat   |
  |    build environment.  Over time, I plan on converting to the new      |
  |    style but until then, please be aware of the potential differences. |

If you wish to follow this document as close as possible, please follow the 
below configuration to enable a "root" setup:

   Centos 6
   Create the RPM build environment as this is no longer created in Centos6 
   default and when created, it puts it under the builder's homedir 
   (say /home/dranch/rpmbuild).  This new layout is considered a newer best 
   practice to avoid malicious Make files, etc. but I fail to see the end to
   end security as you still have to install the resulting RPM as root.  
   Please see the above URL on how to create a build environment the new way.

   Anyway, for now, I'm doing it the old way:

      mkdir -p /usr/src/redhat/BUILD
      mkdir -p /usr/src/redhat/BUILDROOT
      mkdir -p /usr/src/redhat/RPMS
      mkdir -p /usr/src/redhat/SOURCES
      mkdir -p /usr/src/redhat/SPECS/Old
      mkdir -p /usr/src/redhat/SRPMS

   What do all those directories do?

        - this is the scratch area for the RPM builder.. you don't need to 
          anything for this area except maybe delete stuff out of it when 
          things are built, installed, etc.

        - used by some other spec files.. same definition as the BUILD 
          directory above

        - this is where you download the new version of Fldigi but don't 
          uncompress it

        - this is where you put the spec files like fldigi.spec

        - you most likely won't need this as it's a holding area ONLY if you 
          create SRPMS (program source archive + spec file)

    /usr/src/redhat/RPMS - this is where the resulting RPMs will be put

   To allow you to compile things NOT as root, do the following and change
   USERNAME to your login id:

      #Don't be root when you run this
      sudo chown -R $USER /usr/src/redhat

   To keep things simple, I recommend to do the following for Centos6 users:

        ln -s /usr/src/redhat /root/rpmbuild

        # The following allow you to centralize all your builds in one place
        # but this might not work well for a true multi-user system.  Your
        # preference
        ln -s /usr/src/redhat /USERNAME/rpmbuild

Debugging: When compiling code for Linux (regardless of the distribution), most code is 
created to run on the lowest common denominator of hardware.  Very few optimizations
are taken to take advantage of your local CPU, etc. which is unfortunate and wasteful.
Even worse, older flags like "--enable-mmx" are NOT legal on 64bit CPUs but changing 
the platform optimizations will fix that!

In Centos (5 or 6), create or edit the file /etc/rpmrc and add the following line:

   optflags: x86_64 -O3 -march=native -m64 -g

   NOTE:  If you don't want to include debugging objects in all your RPMs, you can
          remove the -g option such as:

          optflags: x86_64 -O3 -march=native -m64

Parallel Compiles: To natively support SMP compiling in your system globally (recommended), 
edit the /etc/rpm/macros.dist file and add the following line.  Change the number to 
reflect the number of threads (number of "processor" lines) shown in the output from
"cat /proc/cpuinfo/".  On my machine, I have 2 physical cores and 2 hyperthreading cores
so I'm going to start with 4 parallel threads.  Increasing this number above real / virtual
threads *can* but not always improve compiling performance.  You have to experiment to 
see what your system can support:


Signing: Some packages that want to cryptographically sign the package require 
an email address (example packages include say Xastir):

  # Create the file /etc/rpm/macros.gpg and add your name and email address
  # in this specific format.  For my setup, I configured it to be:

      David Ranch dranch@trinnet.net

  # You can also enable this on a per user basis.  For example, if you're
  # compiling code while logged in as root, change the following  to be 
  # your name and email:

       vim /root/.rpmmacros
       David Ranch dranch@trinnet.net

Verification: To check your new RPM build settings, run the command 
"rpmbuild --showrc" and look for terms like "gpg" and "optflags".  Make 
sure your changes are seen before proceeding!

1.b - PreSetup: Enabling Third Party RPM repositories

Yum and third-party repositories:
When I initially started upgrading Centos5 for the HamShack, I was doing the 
package search and installation MANUALLY.  Though this is fine on small 
projects as you learn exactly what's required.  To do this, I recommend the 
use of the rpmfind site:


Now, after a while, manually doing things gets VERY tedious.  Fortunately, 
yum supports 3rd party repos which will do the search, dependency checks,
and installations all for you.  To enabled third-party sites to download 
prebuilt RPMs:

   Install the Yum-Priorities plugin and enable priorities:

          1) Install the Yum priorities system so any new 3rd party RPMs
             don't override the primary Centos repositories

               yum install yum-priorities

          2) Edit the various stock Centos repos as defined in /etc/yum.repos.d
             to have correct priorities (THEY WILL VARY..)

             . . .
             . . .

             . . .

             . . .

             . . .

          3) Install the Adobe and RPMforge repo files

             adobe-linux (for Acrobat and Flash updates)
             cd /tmp
             wget https://get.adobe.com/flashplayer/download/?installer=Flash_Player_11.2_for_other_Linux_(YUM)_64-bit&standalone=1
             rpm -ivh adobe-release-x86_64-1.0-1.noarch.rpm

             Edit the Yum repo file at /etc/yum.repos.d/adobe-linux-x86_64.repo


          4)   Download the proper RPM for your distribution version and computer architecture:


               NOTE: It seems that RPMForge is dropping RHEL6 and Centos6 
                     support as there aren't many RPMs available.  See the
                     ATrpm repo below as a possible good replacement

             For Centos6 on a x86_64 machine:

               rpm -ivh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

          5) Enable "priorities" for the RPMforge repository so they don't override
             the primary Centos repositories.  You will also want to enable the Extra 
             and Testing repositories.  The Testing repository is needed to install 
             bleeding edge versions of Wine, etc.

             . . .
             enabled = 1
             protect = 0

             . . .
             enabled = 1
             protect = 0

             . . .
             enabled = 1
             protect = 0

             5.a) I've found one situation where bleeding edge packages from the 
                  "rpmforge-extra" repo would override packages from the main 
                  Centos5 updates repo.  Regardless of what I would do with the
                  priorities, enabling the "protect" knob, etc., nothing would 
                  fix this.   Ultimately, the fix I found was to add:
                  'check_obsoletes=1' to the /etc/yum/pluginconf.d/priorities.conf

          6) In addition to rpmforge, I also have additional REPOs enabled:

                 - ELREPO (for more up to date kernel modules like ALSA)
                      Centos6 - rpm -Uvh http://elrepo.org/elrepo-release-6-4.el6.elrepo.noarch.rpm
                      Centos5 - http://elrepo.org/elrepo-release-5-3.el5.elrepo.noarch.rpm
                   # Edit /etc/yum.repos.d/epel.repo and add to each stanza

                     . . .
                     protect = 0

                     . . .
                     protect = 0

                     . . .
                     protect = 0

                     . . .
                     protect = 0

                 - EPEL - Fedora community based repos

                   Go to the following URL and install the proper URL for your 
                   specific Centos distro.  

                      NOTE: It seems they change the URLs from time to time so I'm
                            going to only site the more generic URL:


                   # Edit /etc/yum.repos.d/epel.repo and add to each stanza
                   . . .
                   protect = 0

                   # Edit /etc/yum.repos.d/epel-testing.repo and add to each stanza
                   . . .
                   protect = 0

                 - ATrpms - Fedora community based repos
                     NOTE:  The atrpms repo has silently died off, leaving a gap in the 
                            availability of newer RPMs.  I'm actively looking for a 

                            was needed for legacy TRXAMADRM v2.x

   | Important!!                                                          |
   | -----------                                                          |
   | - To make sure that when you have multiple Yum repos installed, you  |
   |   only use the proper RPMs, add the following line to /etc/yum.conf: |
   |                                                                      |
   |   #New check - 032211                                                |
   |   check_obsoletes=1                                                  |

   - Check all your Yum priorities with this handy command:

       sed -n -e "/^\[/h; /priority *=/{ G; s/\n/ /; s/ity=/ity = /; p }" /etc/yum.repos.d/*.repo | sort -k3n

   - In addition to the check_obsoletes feature, you might want to consider
     the following:

        - By default, Yum will try to upgrade your kernel when new versions
          are available.  We don't want to automatically install new kernels 
          as they don't have AX25, etc. installed.  To disable this kernel
          auto-upgrade behavior, add the following line to /etc/yum.conf:

            #comment this out when you want to upgrade the kernel

          When you DO want to upgrade the kernel, simply edit that file,
          comment out the exclude line, and run yum again.

   - Yum will allow you to install many older RPM versions on your system.
     Kinda silly as you only need one or maybe a few backups just in case
     you want to revert.  This also wastes disk space.  To only allow 5 
     versions, add the following
     to /etc/yum.conf:

       installonly_limit = 5

1c. - Buying reliable USB to Serial adapters for Linux

   - Unless you're running very old hardware, your computer no longer has
     a native RS232 port built into it.  This is a major bummer if you ask 
     me but now people are forced to use USB-based serial ports which
     brings up two primary issues:

        1. Poor USB adapters - Do yourself a favor and ONLY use FTDI-based 
           serial converters!  There have been uncountable emails, threads, 
           etc on the Internet about lousy Prolific units (real or counterfeit) 
           that just aren't reliable but *real* FTDI units always work.  I personally
           have a few Prolific units and for the ones that work, they start to
           exhibit issues when using flow control, heavy data transfers, etc.
           Here are a few USB cable products that use FTDI chips:


                 1port - www.cablesunlimited.com - USB-2920 (I have this one)

                 1port - Keyspan (now TrippLite) - USA19HS

                 1port - http://www.usconverters.com/index.php?main_page=product_info&cPath=67&products_id=325

                 1port - https://www.valley-ent.com/store/two-way-radio/programming-cables
                 1port - 9pin adapter with 9 diagnostic LEDs - https://www.gearmo.com/shop/usb2-0-rs-232-serial-adapter-led-indicators/

                 other 1 port FTDI - https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=ftdi+usb+to+serial


                 2port - www.USBGear.com - USBG-2X232FTDI for $27

                 2port - www.serialstuff.Com - USA-2P-232 for $42

                 4port - GearMo - FT4232HL (I haven't tested this one yet) 

                 4port - DigiKey - USB-COM232-PLUS4 (no enclosure)


                 other multi-ports - https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=ftdi+usb+to+serial


              NOTE:  FTDI-based serial adapters are more expensive than 
                     Prolific ones but they work every time.  I can't say
                     the same thing about Prolific units.

              NOTE#2: It sounds like there are corner cases (bit banging) where the real FTDI silicon might actually
                      be inferior to the clone silicon:

              NOTE#3: If your setup is anything like mine, you need multiple
                      serial ports for the following.  If so, you really might
                      want to consider a multi-port cable.

                          - HF rig control
                          - VHF rig control
                          - packet TNC
                          - accessories like PSK meter

             Other USB to serial based adapters using alternative silcon beyond Prolific or FTDI:

                 - Silicon Labs CP210x based adapters: People have been reporting success 

                    NOTE: I have heard that the this chip, by default, always assert DTR when initially plugged in 
                          (not initialized).  This can be a significant problem which can key up and leave your radio
                          transmitting the whole time until the port is fully initiallized.  Not good!  
                          One HAM reported that quickly initializing it with the following works around the issue:

                             stty -F /dev/ttyUSB0 -ixon crtscts -hupcl

                    Since I don't have one of these to test, I would generally NOT recommend to uses these
                    if this is all accurate

                 - Logicneed CH340DS1 and CH341: People have been reporting good success with these 
                   I don't have one to test

1d. - Deterministic serial port assignments for USB adapters

   - Upon reboots, USB glitches, etc., there is the very real potential that your 
     serial device that was on /dev/ttyUSB0 is now on say USB1 or USB2!  These 
     assignments can be all over the place and changing your various program's 
     configuration files is a huge pain!

     To fix this, forget that a given serial device uses the name like /dev/ttyUSB0 
     every time. Remember, this is UNIX and a device (let alone a serial port) can be 
     named ANYTHING.  Why not call a serial adapter "ft857-prog-cable" which is REALLY 

     Over the years, the solution for creating deterministic USB enumeration has 
     evolved.  The first way was via manually created UDEV rules which is very powerful 
     but is rather complicated. In more modern Linux distributions, this has been 
     refined with the /dev/serial/by-id mechanism.  Both approaches are covered 
     Ok, let's get started.  Use "dmesg" to see what's in the buffer.  Now plug in
     your serial device, and run "dmesg" again.  The serial device and it's serial 
     number should show up.  

         usb 2-1.1: new full speed USB device using ehci_hcd and address 5
         usb 2-1.1: New USB device found, idVendor=0403, idProduct=6001
         usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
         usb 2-1.1: Product: usb serial converter
         usb 2-1.1: Manufacturer: FTDI
         usb 2-1.1: SerialNumber: FTCAWZIA
         usb 2-1.1: configuration #1 chosen from 1 choice
         USB Serial support registered for FTDI USB Serial Device
         ftdi_sio 2-1.1:1.0: FTDI USB Serial Device converter detected
         usb 2-1.1: Detected FT232BM
         usb 2-1.1: Number of endpoints 2
         usb 2-1.1: Endpoint 1 MaxPacketSize 64
         usb 2-1.1: Endpoint 2 MaxPacketSize 64
         usb 2-1.1: Setting MaxPacketSize 64
         usb 2-1.1: FTDI USB Serial Device converter now attached to ttyUSB0
         usbcore: registered new interface driver ftdi_sio
         ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver

    The /dev/serial/by-id method:
      | CRITICAL: Using the long device names found by the predictable serial interface system via  |  
      | 11/22/20 /dev/serial/by-id gives segmentation faults when running the required kissattach   |
      |          program used for packet radio.  If you aren't going to use packet radio, don't     |
      |          worry about it.  If you ARE setting up packet radio, this issue has been reported  |
      |          and confirmed as an issue in the libax25 and ax25-tools packages from the VE7FET   |
      |          or official AX.25 repos                                                            |
      |                                                                                             |
      |         For now, DO *NOT* use the /dev/serial/by-id style name at this time with used with  |
      |         the Linux AX.25 kissattach program at this time                                     |

        - Once your serial device is plugged in, try running "ls /dev/serial/by-id".
          On my machine, I see:

          $ ls -la /dev/serial/by-id
          total 0
          drwxr-xr-x 2 root root 200 Aug 31 17:22 .
          drwxr-xr-x 4 root root  80 Aug  7 18:50 ..
          lrwxrwxrwx 1 root root  13 Aug  7 18:50 usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if00-port0 -> ../../ttyUSB2
          lrwxrwxrwx 1 root root  13 Aug  7 18:50 usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if01-port0 -> ../../ttyUSB3
          lrwxrwxrwx 1 root root  13 Aug  7 18:50 usb-FTDI_Navigator__RS232___Config__00000002-if00-port0 -> ../../ttyUSB6
          lrwxrwxrwx 1 root root  13 Aug  7 18:50 usb-FTDI_Navigator__RS232___Config__00000002-if01-port0 -> ../../ttyUSB7
          lrwxrwxrwx 1 root root  13 Aug  7 18:50 usb-FTDI_Navigator__WKey___FSK__00000001-if00-port0 -> ../../ttyUSB4
          lrwxrwxrwx 1 root root  13 Aug  7 18:50 usb-FTDI_Navigator__WKey___FSK__00000001-if01-port0 -> ../../ttyUSB5
          lrwxrwxrwx 1 root root  13 Aug 31 17:22 usb-FTDI_usb_serial_converter_FTCAWZIA-if00-port0 -> ../../ttyUSB8
          lrwxrwxrwx 1 root root  13 Aug  7 18:50 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB1

          As you can see above, I have a BUNCH of serial ports but the one I care
          about is that second from the bottom one.  No need for writing UDEV rules, 
          etc.  In whatever program you want to use that specific adapter, regardless
          of USB enumeration, just specify the serial port as the very long string:


          Simple!  Now, if your specific application cannot support such long serial
          port names or if you really want a specific device to ALWAYS show up say as
          /dev/ttyUSB0, you need to use the manual UDEV rule approach.

    The manual UDEV rule method:
    Alternatively, you could have used the following command to get details:

        udevadm info -a -n /dev/ttyUSB0

     If your adapter's Vendor and Product IDs are matched in the Linux kernel 
     code, the USB port should be automatically be mapped to the next freely 
     available ttyUSB* port such as USB0, USB1, etc.  Now if the USB device
     WASN'T recognized, the output of "dmesg" will show the details of the USB 
     device but it won't map it to a ttyUSB serial device or anything else 
     because it doesn't know what it is.  

        Unrecognized device:  You can either see read the "Enabling US Interface 
                              Navigator USB support via UDEV (optional)" section
                              below to resolve this via UDEV if the device is
                              supported but just not properly detected.  

                              Alternatively, see the kernel building section to 
                              learn how to deal with unrecognized USB devices
                              by modifying the kernel, recompiling it, and 
                              then running that kernel!

     Simple, persistent USB enumeration:

        Here are three different examples of getting some of my USB serial devices 
        to ALWAYS get persistent /dev names.  Edit the file 
        /etc/udev/rules.d/99-usb-serial.rule and add the lines:

         #Device #1 - cablesunlimited.com USB-2920 - 1-port USB to serial adapter (FTDI-based)
         SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTCAWZIA", NAME="ftdi-serial-cable"

         #Device #2 - Generic 1-port USB to serial adapter (Prolific-based) for a Kenwood THF6A cable
         SUBSYSTEM=="tty", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2302", SYMLINK+="thf6a-cbl"

         #Device #3 - RT Systems CT-62B 1-port USB to serial adapter for FT817/857/897 (FTDI-based)
         #NOTE: This adapter is NOT recognized by the Linux kernel as a valid
         #      serial device.  RT System does this ON PURPOSE so their programming
         #      software will only work with their cables!  You can change these IDs
         #      if you wish with http://www.ftdichip.com/Support/Utilities.htm#FT_Prog
         #      Alternatively, the following will run a script to poke the RT Systems
         #      USB IDs into the kernel FTDI driver so it can recognize the new 
         #      device as a serial port. 
         BUS=="usb", SYSFS{idVendor}=="2100", SYSFS{idProduct}=="9e56", ENV{ID_MM_DEVICE_IGNORE}="1", RUN+="/usr/local/sbin/RTSystems-addports.sh &"
         SUBSYSTEM=="tty", ATTRS{idVendor}=="2100", ATTRS{idProduct}=="9e56", SYMLINK+="ft857_prog"

     Much more of this USB device enumeration topic is discussed in the 
     "Enabling US Interface Navigator USB support via UDEV (optional)" section below

1e. - Fixing serial port device permissions for non-root users

      | NOTE on Serial port permissions:                             |
      | --------------------------------                             |
      | With the use of UDEV, all serial ports require users to have |
      | the "dialout" group permission.  To enable this for your     |
      | login (don't use root):                                      |
      |                                                              |
      |    - edit the /etc/groups file as root                       |
      |    - scroll down and find the "dialout" group name           |
      |    - append at the end of the line the needed username like  |
      |      dranch                                                  |
      |                                                              |
      |    * You will have to LOGOUT and log back in with this       |
      |      username for the changes to go into effect              |
      |                                                              |
      |      * Once logged back in, open a terminal window and run   |
      |        the command "groups".  Make sure "dialout" shows up.  |
      |        If it doesn't you'll need to log out of your current  |
      |        Gnome/KDE/whatever session and back in to get the new |
      |        settings.                                             |

1f. - Working around the ModemManager taking over your Serial ports


           Modem-Manager and Centos 6
           As part of Centos 6's fully automatic NetworkManager system, 
           a sub-program called modem-manager tries to initialize serial 
           port based analog modems.  The problem with this is that when 
           UDEV initializes the US Interface Navigator's FSK port, modem-manager 
           thinks it's a modem and will try to send some Hayes AT commands 
           to it.  Modem-manager is generally recognized as BAD code and makes
           way too many assumptions and there is an Ubuntu bug filed to change 
           this assumption behavior.  Unfortunately, the current Centos state 
           makes the Navigator assert PTT on the rig and starts 
           transmitting those Hayes AT commands via RTTY!  

           #  Disable the modem-manager binary but this will 
           #  get undone if the program gets updated via a Yum update
           mv /usr/sbin/modem-manager /usr/sbin/modem-manager.disabled
           killall modem-manager

If you're still having UDEV issues, please see section: 

   "2.c - Enabling US Interface Navigator USB support via UDEV" 

for points on how to do debugging, etc.

1.g. - Deterministic sound cards

One issue that Linux faces due to it's flexible everything is consistent 
enumeration of multiple sound cards just like it's serial ports.  What does that 
mean?   When you reboot your Linux machine, your ALSA device ID's might change around 
and never be consistent / deterministic!  At that point, you'll have to manually 
re-configure your various programs to use the right ALSA ID every single time.  
What a pain!  The following section fixes that issue!

In my specific situation, I have four sounds cards in my system:

   cat /proc/asound/cards
    0 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xc0600000 irq 42
    1 [CODEC          ]: USB-Audio - USB Audio CODEC
                      Burr-Brown from TI USB Audio CODEC at usb-0000:00:1d.0-1.1.1, full speed
    2 [Pro            ]: USB-Audio - SB X-Fi Surround 5.1 Pro
                         Creative Technology Ltd SB X-Fi Surround 5.1 Pro at usb-0000:00:1d.0-1.2, full
    3 [Device         ]: USB-Audio - Generic USB Audio Device
                         Generic USB Audio Device at usb-0000:00:1d.0-1.2, full speed

   Breaking it down:

     ID#0 is the laptop's computer's built-in sound card - Used for general audio 

     ID#1 is the US Interface Navigator USB sound card - used for HF/VHF digital 
          modes (PSK, SSTV, etc.)

     ID#2 is a Creative Labs Soundblaster X-Fi USB sound card - used with a 
          SoftRock SDR

     ID#3 is a cheap CM109 USB sound card FOB - used for Svxlink for Echolink

If you issue the command "aplay -l", you can see all the various PLAYBACK interfaces
offered by each sound device.  If you use "arecord -l", you can see all of the 
recording interfaces.  To find the proper technical "name of a specific ALSA 
sound card, run "aplay -L" and you'll see something like:

   aplay -l
   **** List of PLAYBACK Hardware Devices ****
   card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog]
     Subdevices: 1/1
     Subdevice #0: subdevice #0
   card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
     Subdevices: 1/1
     Subdevice #0: subdevice #0
   card 1: CODEC [USB Audio CODEC], device 0: USB Audio [USB Audio]
     Subdevices: 1/1
     Subdevice #0: subdevice #0
   card 2: Pro [SB X-Fi Surround 5.1 Pro], device 0: USB Audio [USB Audio]
     Subdevices: 1/1
     Subdevice #0: subdevice #0
   card 2: Pro [SB X-Fi Surround 5.1 Pro], device 1: USB Audio [USB Audio #1]
     Subdevices: 1/1
     Subdevice #0: subdevice #0
   card 3: Device [Generic USB Audio Device], device 0: USB Audio [USB Audio]
     Subdevices: 1/1
     Subdevice #0: subdevice #0

Breaking that output down, here is how to read each line is like the following:

   card 3: Device [Generic USB Audio Device], device 0: USB Audio [USB Audio]
   ^^^^^^  ^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^   ^^^^^^^^  ^^^^^^^^^  ^^^^^^^^^
     |       |               |                   |          |          |
     |      #2 the           |                 #4 the       |        #6 the
   #1 the   ALSA           #3 the              sub-device  #5 the   sub-device
   ALSA     device         device              number       sub-    description
   device   name           description                     device

In the above example, I want this el-cheapo USB sound card currently shown as
device #3 to ALWAYS become ID#3.  The reason why I described each field is 
because the USB device naming from the USB device itself can be completely 
and utter generic and thus totally confusing.  In this example, this cheapy 
sound card name here is "device" (item #2 above).  How useless is that!!  I 
could argue that the US Interface Navigator's name of "CODEC" is equally 
useless.  Don't blame ALSA, that's the name the manufacturer gave their USB 

The other things to pay attention to is field #3 which is the description of
the device and field #6 which is the device TYPE.

In my example, I have *three* USB sound cards using the same TYPE.  That's bad 
because they all use the same driver.  Since it's the same driver, I now have 
to narrow things down by USB device ID.  To do this, I need to use then use 
the device description in field #3 as the starting point.  Following the 
text from above, I'm going to get the device IDs for all my USB devices including
the US Interface Navigator, my SoundBlaster X-Fi, and the cheapy USB sound card:

    #For the US Interface Navigator
    lsusb -v | grep -B4 "USB Audio CODEC"

      idVendor           0x08bb Texas Instruments Japan
      idProduct          0x2906
      bcdDevice            1.00
      iManufacturer           1 Burr-Brown from TI
      iProduct                2 USB Audio CODEC


    #For the Creative Labs Soundblaster X-Fi
    lsusb -v | grep -B4 "SB X-Fi Surround 5.1 Pro"

      idVendor           0x041e Creative Technology, Ltd
      idProduct          0x30df
      bcdDevice            1.00
      iManufacturer           1 Creative Technology Ltd
      iProduct                2 SB X-Fi Surround 5.1 Pro


    #Syba USB soundcard 
    lsusb -v | grep -B4 "Generic USB Audio Device"

      idVendor           0x0d8c C-Media Electronics, Inc.
      idProduct          0x0008 C-Media USB Audio Device
      bcdDevice            1.00
      iManufacturer           0
      iProduct                1 Generic USB Audio Device

We now have the dirty details we need, specifically the USB idVendor
and idProduct.  Ok, so create the following file with the following text for 
the C-Media device:

       NOTE:  ALSA starts it's numbering with 0 so with this example, 
              I'm not defining what's slot#0 since it doesn't use the
              USB audio driver

   #1- US Navigator, 2- Soundblaster Xfi, 3- Syba USB soundcard dongle
   options snd-usb-audio index=1,2,3 vid=0x08bb,0x041e,0x0d8c pid=0x2906,0x30df,0x0008

Hopefully you got all that.  If your setup isn't covered here, please see the
ALSA docs at http://alsa.opensrc.org/MultipleCards for full details on how to 
get consistent enumeration.

1h. - PreSetup: Power Management and Other Misc Things

Linux Power Management
This is an ugly topic for me as it seems that entire power management systems are
different from distro to distro and they completely change out their solution every 
year!  Classic Linux!  It's maddening and the GUIs be it Gnome, KDE, etc. seem to 
override the lower level systems like acpitool, devkit-power, etc.  Which 
to use?  Depends!  Gaaaahhh!

The packetrig.sh script as covered in this this document at
distills all of this into something that should work to enable power savings
but also disabling suspending when not wanted, etc.

A few options:

# If you're using KDE4 as I am, you can send a DBUS signal
#  Please note you CANNOT run this as root when logged in as a regular user so
#  You have to use sudo to work around it
sudo -u YOURUSERNAME qdbus org.kde.powerdevil /modules/powerdevil setProfile Performance

#klunky but ABSOLUTE way to disable the system from suspending
mv /usr/sbin/pm-suspend /usr/sbin/pm-suspend.disabled

#Devkit policy - Very powerful system to change all kinds of parameters but to 
# disable the possibility of suspending, edit this file and change ALL options 
# to NO
vim /usr/share/polkit-1/actions/org.freedesktop.devicekit.power.policy

A few power management tools to start your search:

powertop - A fantastic tool to help tune your system for power management
           It interactively identifies system tuning recommendations and
           activates them for the current runtime.  If you want these 
           settings to be permanent, either set them the devkit 

tuned-adm - Centos 6 mechanism to control power management.  Check out
            the "list" option but notice these parameter have no obvious 
            bearing on Gnome or KDE settings.  See /etc/tune-profiles/*
            for specific details but it's not clearly spelled out

devkit-power - Check out "-d" to see what your system shows for managed
               devices, etc.

acpitool - Control the power management of your machine so it doesn't
           turn off when you least expect it.

An excellent document for everything power management in Centos 6 and how to
audit and optimize your system:

Disabling SecureLinux
  - Disable SE Linux (unless you know how to create all the detailed
    SELinux enforcement policies for the various HAM applications):

     edit the /etc/sysconfig/selinux file and set it to:


  - remove the setroubleshoot RPM (if installed)

      setroubleshoot automatically runs client-side code whenever a denial
      occurs even if the setroubleshootd daemon isn't running! 
      Removed it entirely unless it is needed:

         yum erase setroubleshoot

Other Misc Things:
  - Adobe Acrobat Acroread is a 32bit application and requires a multitude
    of 32bit libraries to be installed to work.  Forget it.  Install "evince"
    and be done with it.

1i. - Enabling core dumps and tuning the ABRT system

In the event that things crash on your system, you need to be able to allow the
machine to record a "coredump" or backtrace.  With a coredump in hand, you'll at 
least have a clue to what died on your machine and why.

To enable coredumps, edit the /etc/sysctl.conf file, find and edit/add the following

   kernel.core_uses_pid = 1

Next, edit the file /etc/security/limits.conf and append the line

  * - core unlimited

Next, the Centos ABRT system is a system to capture additional details about the 
machine at the time of a coredump.  These details are very helpful as well.  ABRT
will record all this state for programs running as installed packages but if you
are running anything that was NOT installed as an RPM, ABRT will automatically 
delete the coredump and all the additional details!  Let's change that!

Edit the file /etc/abrt/abrt-action-save-package-data.conf and change the lines
that say:

   OpenGPGCheck = yes

   ProcessUnpackaged = no


   OpenGPGCheck = no

   ProcessUnpackaged = yes

2. - AX.25 Preparation - Preparing various changes to the stock kernel for AX25 and other HAM hardware

   | IMPORTANT:                                                            |
   |            This documentation now uses the El Repo ML kernel sources  |
   |            because I need newer kernels to support specific hardware  |
   |            and I wanted the included AX.25 kernel modules             |
   |                                                                       |

By default, the stock Centos and RHEL kernels for Centos v6, v5, etc do NOT include the 
support for the AX.25 protocol stack or the various packet radio interfaces like KISS 
and 6PACK.  Fortunately, there are some options now and at least the Timewave (was US 
Interface ) Navigator is now supported in the 2.6.35+ kernels by yours truly :-).

What does this all mean?  You have a choice:

   1) Instead of using RHEL/Centos kernels, you can use ELRepo kernels which package
      the mainstream Linus kernels and now include the amateur radio kernel modules
      per request from your's truely:  http://lists.elrepo.org/pipermail/elrepo/2017-May/003566.html
      Read more below of how to enable the Elrepo kernel repo and install one of 
      the two versions of the kernels

   2) If you want to stick with RHEL/Centos kernels, you will have to either patch and
      recompile the kernel to add the amateur radio kernel modules.  Navigator support
      is already included and making the UDEV config changes as mentioned above will work
      just fine

      NOTE:  If you are going to be compiling a kernel, this doc assume you are modifying 
             one of the following kernels:

               Centos6 - 2.6.32-x.el6.x86_64
               Centos5 - 2.6.18-x.el5 kernel

Before you get the SRPMs and sources for the new kernel, consider this:

   Official Centos/Redhat kernels:
   There are the stock Centos kernel sources that are directly based
   from Redhat's kernels.  These are very stable but also VERY OLD 
   kernels.  As such, they might not support all the new hardware that
   you or others might have!  It's also worth noting that they do NOT
   include support for the AX.25 protocol stack (ElRepo kernels DO).

   El Repo kernels:
   The ELRepo Yum Repo group (documented above) in this document
   packages new Linux kernels but are specifically made to be compatible 
   with Centos/Redhat kernels.  These newer kernels get you newer hardware
   support, newer ALSA sound drivers, include AX.25 kernel support, etc.  
   They have TWO versions of kernels:

      ML:  Main-Line Stable:
           These kernels are newest kernels available and are always MUCH
           newer than the Centos / Redhat kernels. They are considered their 
           feature supported kernels and are a good option for 
           people that need the newest kernel (kernel 4.8.x vs. 
           2.6.32) but want the highest stability.

      LT : Long term supported:
           These kernels use the kernels that's considered *stable*
           by the Linux developers (aka OLDER).  These kernels will get
           you support for a lot more new hardware, new fixes (and
           potentially new bugs).  

      It's also worth mentioning that you can usually take a an ML
      kernel from say EL7 and use it on EL6 (if you needed say a 4.4.x
      kernel) but more work might be required to get it to compile

      If you choose to use the El Repo kernels and recompile them, you need 
      to first download the newest Elrepo SRPMs which aren't everything
      you need.  They are just the patches to be applied to the stock kernel 
      sources.  Download them here:


      Separately, download the matching stock kernel sources from 
      here and place in the /usr/src/redhat/SOURCES dir.  Be sure
      to get the tar.xz version:

   | IMPORTANT:                                                            |
   |            This documentation now uses the El Repo ML kernel sources  |
   |            because I need newer kernels to support specific hardware  |
   |            and I wanted the included AX.25 kernel modules             |
   |                                                                       |

   Reference material for properly building custom kernels for Centos RPMs

      Proper custom kernel compiling approach
      Centos 5.x specific:  Issues with building custom kernels for Centos 5.4

You first need to install the following RPMs to be able to compile a custom kernel:

   yum install nasm
   yum install asciidoc
   yum install newt-devel

Next, you need to install the Centos kernel-headers, kernel-devel, and kernel source RPM

   #get the misc kernel parts first
   yum install kernel-headers kernel-devel

   #Let's get started using the El Repo LT kernel.  Enter in the SRPM directory:
   cd /usr/src/redhat/SRPMS

   # Use up the "links" text web browser to go to an ElRepo website mirror, 
   # locate the newest LT kernel source RPM (highest version number given), 
   # use the cursor keys to go to the desired file (it will highlight it) and 
   # hit the "d" key to download it (it will be fast because it's only patches).  
   # Once downloaded, hit the "q" key to exit links

     ElRepo Kernel Pathces:
         - links http://elrepo.org/linux/kernel/el6/

      NOTE: This section assumes the following kernel version is used:

          Centos6 - kernel-ml-4.8.11-1.el6.elrepo.nosrc.rpm - 12/01/2016

           - Scroll down to kernel-ml-4.8.11-1.el6.elrepo.nosrc.rpm file with the
             cursor keys, hit enter to select, and then select SAVE using the tab
             and enter key

                NOTE:  This file is very small as it's only an overlay for
                       the vanilla Linus kernels which need to be downloaded
           - Once downloaded, hit the "q" key to exit links

    Stock Linux kernel source code
    Now you need to download the matching vanilla Linus kernel code.  For this
    documentation, it's assuming the 4.8.11 version

       cd /usr/src/redhat/SOURCES

    Use up the "links" text web browser to go to https://www.kernel.org/pub/linux/kernel/v4.x/
      - locate the matching kernel source .tar.xz file (again.. get the XZ file ] to the 
        matching ElRepo SRPM version
      - Use the cursor keys to go to the desired file (it will highlight it) and hit the 
        "d" key to download it

       NOTE:  This is a very big file and will take some time to download

    Once downloaded, hit the "q" key to exit links

     If you're going to used the stock Centos provided kernels (NOT RECOMMENDED):

     cd /usr/src/redhat/SRPMS

     Next, you need to download the correct version of the SRPMS

         - links http://vault.centos.org/6.2/updates/Source/SPackages/

         - links http://vault.centos.org/5.8/updates/Source/SRPMS/

      #If you choose to still go this route, this doc assumes the following:

          Centos6 - kernel-2.6.32-220.7.1.el6.src.rpm  - 03/18/2012
          Centos5 - kernel-2.6.18-274.18.1.el5.src.rpm - 04/04/2012

    #Hit "q" to quit Links once downloaded

2.a - Unpacking the kernel sources and applying some configuration change patches

   Make a backup of any older SPEC files:

     One key point to make here is to MOVE the old SPEC file so it 
     minimizes any risks to new patches not being applied, etc.

              cd /usr/src/redhat/SPECS
              mkdir Old
              #If a previous kernel source was installed
              mv kernel.spec Old/kernel.spec.`date +%m%d%y`
              mv kernel-ml-4.8.spec Old/kernel.spec.`date +%m%d%y`
              mv kernel-ax25-el6.spec Old/kernel-ax25-el6.spec.`date +%m%d%y`

              cd /usr/src/redhat/SPECS
              mkdir Old
              #If a previous kernel source was installed
              mv kernel-2.6.spec Old/kernel-2.6.spec.`date +%m%d%y`
              mv kernel.spec Old/kernel.spec.`date +%m%d%y`
              mv kernel-ax25-el5.spec Old/kernel-ax25-el5.spec.`date +%m%d%y`

   If you've previously created a custom kernel, make a backup of it's varous config
   files just in case:

           cd /usr/src/redhat/SOURCES/
           mkdir Old

           #the config-local is the key file to enable local settings; especially for AX.25
           cp config-local Old/config-local.`date +%m%d%y`

           cp config-generic Old/config-generic.`date +%m%d%y`
           cp config-x86_64-generic Old/config-x86_64-generic.`date +%m%d%y`

           #this file will only be present if you've already upgraded your kernel once following this doc
           cp config-x86_64-generic-ax25-rhel Old/config-x86_64-generic-ax25-rhel.`date +%m%d%y`

   Now install the ElRepo or stock Centos SRPM (NOT RECOMMNEDED) with the following commands.  

      NOTE: Ignore any errors or warnings about "user mockbuild" or "user ajb" in the final stages 
            of the RPM install.  This is just an artifact of who created the source package

      ElRepo LT kernel:
         cd /usr/src/redhat/SRPMS/
         sudo rpm -ivh kernel-ml-4.8.11-1.el6.elrepo.nosrc.rpm

         #If you're curious to see what files were installed, run the command:

            rpm -qipl ../SRPMS/kernel-ml-4.8.11-1.el6.elrepo.nosrc.rpm

      Stock Centos kernel (NOT recommended):
         Centos 6
         cd /usr/src/redhat/SRPMS/
         rpm -ivh kernel-2.6.32-.el6.src.rpm

         For example:  rpm -ivh kernel-2.6.32-220.7.1.el6.src.rpm

            Ignore any errors about "user mockbuild"

         rpm -ivh kernel-2.6.18-.el5.src.rpm

2.b - Enabling AX.25 support in the kernel in one of two ways

   Ok, now regardless of using the Elrepo or stock Centos kernel approach, we need
   to modify the kernel configuration to add support for the AX.25 protocol, 
   Packet TNC interfaces, and optionally (no longer needed in modern kernels) 
   Timewave / US Interface Navigator USB device in any Centos kernel:

         - Create and add the following lines into the appropreate file

               #This file configured CPU agnostic features
               vim /usr/src/redhat/SOURCES/config-local

               #This file configured CPU agnostic features
               vim /usr/src/redhat/SOURCES/config-rhel-generic

           (these changes can also be found at 


          NOTE:  You SHOULD NOT modify the original kernel-*.config files as 
                 user specific items ONLY go in the "generic" files instead
          NOTE#2  If you need to configure CPU arch specific features (X86_64) such as
                  disable the CONFIG_CC_STACKPROTECTOR_STRONG=Y feature from a 
                  Centos7 ml-4.4.26 kernel, these changes and overrides would need to
                  go in the config-4.4.26-x86_64 file

          NOTE#3:  Please note that if you're updating to a new kernel and have 
                   already followed these instructions, you might not be able 
                   to simply restore you last config-local or config-x86_64-generic-rhel 
                   file.  The new kernel "options might have been enabled in the 
                   new kernel that weren't present in the previous one

          NOTE#4:  I have not enabled "CONFIG_EMBEDDED=y" just yet as I want to 
                   see if this is still required to get BSD-style PTY functionality 
                   working properly.  If your PTYs aren't working, you will need to 
                   enable CONFIG_EMBEDDED=y and and then also configure about 15 other
                   non-related things that the new 2.6.x kernels now seem to require.

                      Update:  I've found that EMBEDDED is *not* required

          - Make a backup of this file so you can use it again with other 
            kernel upgrades:

                 cp usr/src/redhat/SOURCES/config-local \

                 cp /usr/src/redhat/SOURCES/config-rhel-generic \

         - Next, edit the kernel.spec file to update the kernel's name to reflect 
           something more unique:

             cd /usr/src/redhat/SPECS

             #If using the ML series Elrepo kernels, you'll need to match the 
             # kernel family version to what you downloaded
             sudo vi kernel-ml-4.8.spec

             - For an ElRepo kernel, find and update the line:

                %define LKAver 4.8.11

             - Next, find the line:

                   # % define buildid .

               Notice the "#" at the front of the line AND the space between 
               the "%" and "define" word. Change this to the following (notice 
               the removed #, REMOVED the EXTRA space, and added the ".ax25":
                  %define buildid .ax25

           Centos6 using ML kernel
           - Copy the altered spec file just in case
             mv kernel-ml-4.8.spec kernel-ml-4.8-ax25.spec 

           - Optionally add in any specific kernel patches needed for your installation

           HEADS-UP: Failed attempt on using Centos7 kernels on Centos6:
           Trying to use a Centos7 kernel on Centos6 will NOT work as the Centos7 kernel
           requires various SystemD programs to be installed and configured.  Unless you
           want to retrofit in SystemD into your system, this won't work

              # These steps are kept here for posterity reasons

              1.  Must disable CONFIG_CC_STACKPROTECTOR_STRONG as Centos6's version
                  of GCC doesn't support it.  Add into /usr/src/redhat/SPECS/config-4.4.26-x86_64


              2.  Centos7 kernel uses a differe path for modinfo

                     ln -s /sbin/modinfo /usr/sbin/modinfo

              3.  It's not possible to build a Centos7 4.4.26-ml kernel on Centos6 machine
                  due to requiring SystemD.  The error seen is:

                     error: File must begin with "/": %{_unitdir}/cpupower.service

2.c - Enabling US Interface Navigator USB support via UDEV (optional)

   - If you aren't using a modern kernel or DON'T have a US Interfaces 
     Navigator, please skip down to the COMPILING step later in this 

   In the above "PreSetup: UDEV based deterministic Serial ports" section, 
   I covered how to create deterministic enumeration for USB based serial ports

   US Interface Navigator support:
      In the previous version of this document, I covered how to add support
      for this USB soundcard device directly via kernel patches.  This is still 
      the most complete way to get things done but it requires a lot of work 
      in compiling the kernel, etc. which scares off most users.

      I've retained that older documentation at the bottom of this section but 
      there is simpler, non-invasive way to add US Interface Navigator 
      (and other USB-based serial devices) support:  UDEV.   
      In addition to not requiring source code changes, compiling and installing 
      a new kernel, the following UDEV changes make the port naming PERSISTENT 
      so the serial devices will always use expected names in /dev.  For example,
      my setup now has the following persistent:

             USI_CAT  -> ttyUSB0
             USI_CFG  -> ttyUSB6
             USI_FSK  -> ttyUSB4
             USI_PTT  -> ttyUSB1
             USI_SER  -> ttyUSB5
             USI_WKEY -> ttyUSB3

      - US Interface Navigator with UDEV and kernel module options: 
        The US Interface Navigator is a USB soundcard which includes 6 FTDI 
        based serial ports for CAT-based RIG control, secondary PTT, Winkeyer
        interfacing, setting of other configurations, and FSK data. As mentioned 
        above, not all of these ports are natively supported until 2.6.35.  

        Some Linux experts might be thinking: "Hey,  Linux allows you to specify 
        an additional USB vendor and product IDs when you first install the USB 
        kernel module via the following":

            modprobe ftdi_sio vendor=0x0403 product=0xb810 

           So you'd naturally think you could just add additional vendor and 
           product IDs like the following.. right?  

               modprobe ftdi_sio vendor=0x0403 product=0xb810 vendor=0x0403 \
product=0xb811 vendor=0x0403 product=0xb812

           Wrong.  That doesn't work as the kernel doesn't recognize the additional 
           USB devices what so ever and doesn't realize it's a serial device let 
           alone a FTDI-based serial device.  What you CAN do is do a combination:

               - use the kernel module mechanism 
               - use the newer "new-id" feature:

           #1. Load the FTDI module and treat this vendor/product ID as a 
           #   FTDI device - you can only specify ONE device at a time
           modprobe ftdi_sio vendor=0x0403 product=0xb810 

           #2. After the kernel module is loaded, dynamically signal the driver 
           #   to support ADDITIONAL vendor/product IDs as FTDI devices
           echo "0403 b811" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
           echo "0403 b812" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

               I spent a LOT of time trying to figure out why the first USB
               serial device, "b010" device will be properly recognized AND 
               acted upon in the UDEV configuration yet the other two devices, 
               "b811" and "b812" devices wouldn't be recognized AND acted upon.

               My best guess is that there is a race condition in the FTDI 
               driver where only one device is being allowed to be evaluated and
               acted upon at a time.  I stumbled upon this timing issue when I 
               was using a sleep statement.  I also found that you CANNOT use 
               bash-line redirects like the following directly in a UDEV rule:

                 echo "0403 b811" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

               It seems that if there is a ">" character in the UDEV rule, 
               you would see something like the following when running the UDEV 
               daemon in DEBUG mode:

                 /bin/echo 0403 b811 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id' returned with exitcode 0
                 /sbin/modprobe -b usb:v0403pB811d0500dc00dsc00dp00icFFiscFFipFF' started

        With all that, you now get full US Interface Navigator serial port support 
        without kernel changes.  to make these changes permanent across reboots, 
        create the following files:

           #US Interface Navigator
           # NOTE: UDEV is very specific to the hierarchy where the strings 
           #       are located.  I recommend to use the following command to
           #       show the proper hierarchy when one US Navigator port is
           #       loaded:
           #       udevadm info --attribute-walk --name=/dev/ttyUSB0
           BUS=="usb", SYSFS{idVendor}=="0403", SYSFS{idProduct}=="b810", ENV{ID_MM_DEVICE_IGNORE}="1", RUN+="/sbin/modprobe ftdi_sio vendor=0x0403 product=0xb810"
           SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (CAT & 2nd PTT)", ATTRS{bInterfaceNumber}=="00", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_CAT"
           SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (CAT & 2nd PTT)", ATTRS{bInterfaceNumber}=="01", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_PTT"

           BUS=="usb", SYSFS{idVendor}=="0403", SYSFS{idProduct}=="b811", ENV{ID_MM_DEVICE_IGNORE}="1", RUN+="/usr/local/sbin/USI-addports.sh &"
           SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (WKey & FSK)", ATTRS{bInterfaceNumber}=="00", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_WKEY"
           SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (WKey & FSK)", ATTRS{bInterfaceNumber}=="01", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_FSK"
           SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (RS232 & Config)", ATTRS{bInterfaceNumber}=="00", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_SER"
           SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (RS232 & Config)", ATTRS{bInterfaceNumber}=="01", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_CFG"

           To support the above UDEV rules, we need to create the USI-addports.sh 
           shell script:

           vim /usr/local/sbin/USI-addports.sh

           #Sleep 2 to avoid a seeming race condition
           sleep 2

           #tell the FTDI driver about the WKey and FSK serial ports
           /bin/echo "0403 b811" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id
           #tell the FTDI driver about the RS232 and Config serial ports
           /bin/echo "0403 b812" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

           Once that file is created, UDEV will automatically detect the 
           presence of this new 10-us-interfaces-navigator.rules rule file.  
           There is no need to reload the UDEV daemon, etc!

      | NOTE on Serial port permissions:                             |
      | --------------------------------                             |
      | With the use of UDEV, all serial ports require users to have |
      | the "dialout" group permission.  To enable this for your     |
      | login (don't use root):                                      |
      |                                                              |
      |    - edit the /etc/groups file as root  u                    |
      |    - scroll down and find the "dialout" group name           |
      |    - append at the end of the line the needed username like  |
      |      dranch                                                  |
      |                                                              |
      |    * You will have to LOGOUT and log back in with this       |
      |      username for the changes to go into effect              |
      |                                                              |
      |      * Once logged back in, open a terminal window and run   |
      |        the command "groups".  Make sure "dialout" shows up.  |
      |        If it doesn't you'll need to log out of your current  |
      |        Gnome/KDE/whatever session and back in to get the new |
      |        settings.                                             |

         If the UDEV rules aren't seeming doing anything (or what you expect)
         them to do, enable debugging!   You can either do it dynamically
         or upon every boot:

             #Dynamically change from ERR to DEBUG level output in syslog
             #  all outputs should show up in /var/log/messages
             udevadm control --log-priority=debug

             #Once done with UDEV debugging, dynamically turn it off with
             udevadm control --log-priority=err

             # For permanent debugging, edit the /etc/udev/udev.conf file
             # and either add or change the following line from ERR to DEBUG

           Modem-Manager and Centos 6
           As part of Centos 6's fully automatic NetworkManager system, 
           a sub-program called modem-manager tries to initialize serial 
           port based analog modems.  The problem with this is that when 
           UDEV initializes the US Interface Navigator's FSK port, modem-manager 
           thinks it's a modem and will try to send some Hayes AT commands 
           to it.  Modem-manager is generally recognized as BAD code and makes
           way too many assumptions and there is an Ubuntu bug filed to change 
           this assumption behavior.  Unfortunately, the current Centos state 
           makes the Navigator assert PTT on the rig and starts 
           transmitting those Hayes AT commands via RTTY!  

           #  Disable the modem-manager binary but this will 
           #  get undone if the program gets updated via a Yum update
           /usr/sbin/modem-manager /usr/sbin/modem-manager.disabled
           killall modem-manager

   Verify the USB serial ports:
   To check that the Navigator ports are recognized and installed properly, run
   the following command to see all the devices:

        ls -la /dev | grep USB

           USI_CAT  -> ttyUSB0
           USI_CFG  -> ttyUSB5
           USI_FSK  -> ttyUSB3
           USI_PTT  -> ttyUSB1
           USI_SER  -> ttyUSB4
           USI_WKEY -> ttyUSB2

      It's the USI* /dev device names that you'll want to use to configure 
      Flrig and other devices

2.d - Enabling US Interface Navigator USB support via kernel code patches (optional)

      | Skip this section if you're going to use the Udev method (RECOMMENDED) |

      | NOTE:                                                                     |
      |       I submitted the kernel patch to have Linux kernels natively support |
      |       the US Navigator back in July, 2010.  This support is now available |
      |       in the following kernels and all follow on versions:                |
      |                                                                           |
      |          2.5.35                                                           |
      |                                                                           |
      |       All newer kernels have this support now so this section is mostly   |
      |       kept around for historical reasons                                  |

      - US Interface Navigator with kernel patches:
        Until the Navigator is natively supported in the kernel, you can add 
        that support via minor customization of the kernel source code.  Since 
        I like to do things via RPMs to keep things very clean, this does require 
        a little work.

        Get the following patches individually from:
            in http://www.trinityos.com/HAM/hampacket-CentosDigitalModes-.tgz 

       - cd /usr/src/redhat/SOURCES
       - cp /tmp/kernel-2.6.spec-add-usnavigator-and-ax25.patch .

         # Apply the SPEC patch to add in the additional scripts to enable
         # the additional serial ports on the US Interface Navigator
         patch -p0 < kernel-2.6.spec-add-usnavigator-and-ax25.patch

         #Apply the kernel configuration changes to enable various HAM radio
         # features for packet radio, etc.
         cp /tmp/config-rhel-generic-ax25.patch .
         patch -p0 < config-rhel-generic-ax25.patch

       - Centos5 only (it's unclear if this is required for Centos6):
         To get BSD-style PTYs to work, you have to also add the following to
         the config-rhel-generic file.  This is ONLY required for legacy 
         configurations using tools like JNOS, etc


       # Copy over the FTDI code patches
       - cp /tmp/linux-2.6-usb-usinterface-add-support-for-navigator.patch .

    Persistent USB Device Naming
    If you'd like to have the serial ports retain a persistent naming
    across newly added devices, reboots, etc., take a look and review 
    the "Determinisitic Serial ports" portion of the "PreSetup: Centos 
    Optimizations" section and the UDEV rules in the Kernel RPM compiling 
    section above and in that 10-us-interfaces-navigator.rules file, 
    only add the lines that contain "bInterfaceNumber".  After that, 
    you should be good to go!

   Verify the USB serial ports:
   To check that the Navigator ports are recognized and installed properly, run
   the following command to see all the devices:

        ls -la /dev | grep USB

           USI_CAT  -> ttyUSB0
           USI_CFG  -> ttyUSB5
           USI_FSK  -> ttyUSB3
           USI_PTT  -> ttyUSB1
           USI_SER  -> ttyUSB4
           USI_WKEY -> ttyUSB2

      It's the USI* /dev device names that you'll want to use to configure 
      Flrig and other devices

2.e - Compile and create the new kernel RPM

    | NOTE:  This section is only required if you want to compile either a   |
    |       RHEL/Centos or ElRepo kernel from scratch.  This is NOT required |
           if you choose to install a prebuilt Centos or ElRepo kernel       |

    Ok, time to compile the kernel and create the RPM.  All of the 
    following will make the primary kernel packages that a user would need:

       cd /usr/src/redhat/SPECS
       Centos 6:
       NOTE: The KABICHK option allows users to compile add-on kernel modules
             like disk drivers, etc. without having to recompile the entire
             kernel.   It's a nice technology but it's not always 100% and
             to support it, you can see it takes a significant amount of 
             compile time to support.  Because of that, I'm DISABLING
             it below to make things compile faster:

       Important NOTE #2 
             Compiling a linux kernel is one of the most demanding things you can do
             on a computer.  It WILL tax the machine to it's limits and sometimes 
             you might expose flaky computer hardware.  I've seen it several times
             where a seemingly stable computer will crash, malfunction, or fail
             to complete only when trying to compile a kernel.
             Before you begin compiling, I encourage you to shutdown any non-essential
             programs that are memory hogs.  This will give the compilers as much
             memory as possibe to avoid going into swap, etc:

                  killall firefox
                  killall thunderbird

       Compile an ElRepo kernel
       It's finally time build the kernel:

       Step #1
       date; time rpmbuild -bb --target=x86_64 --with firmware --without kabichk \
--without PAE --without debuginfo --without debug --without perf --without \
perf-debuginfo kernel-ml-4.8.spec; date

         This will first build the main kernel (fairly fast):
            You will see a line like "Kernel: arch/x86/boot/bzImage is ready"

         Then the kernel modules will be built (the majority of the build time)

              | Total Build time:                                         |
              |                                                           |
              |   Intel i5-2430 CPU based Laptop                          |
              |     2.4Ghz, 3MB cache, 4G of DDR3 RAM   :                 |
              |     Samsung Evo SSD:                                      |
              |                                                           |
              |   ElRepo 4.8.11 ml kernel w/o ABI chk: 50min 56sec (real) |
              |                                                           |

       Next, you now need to also build the kernel firmware package as well:

       Just for reference, here is the older build time for say the 3.17.5 ML kernel:

              | Total Build time:                                     |
              |                                                       |
              |   Intel i5-2430 CPU based Laptop                      |
              |     2.4Ghz, 3MB cache, 4G of DDR3 RAM   :             |
              |     Samsung Evo SSD:                                  |
              |                                                       |
              |   ElRepo 3.17.5 ml kernel w/o ABI chk: 32m 30s (real) |
              |                                                       |

       Stock Centos kernel (NOT Recommended):
       date; time rpmbuild -bb --target=x86_64 --with firmware --without kabichk \
--without PAE --without debuginfo --without debug --without perf --without \
perf-debuginfo kernel-ax25-el6.spec; date

       You should also build the kernel firmware package as well:

        date; time rpmbuild -bb --target=noarch --without doc kernel-ax25-el6.spec

              | Total Build time:                                    |
              |                                                      |
              |   Intel i5-2430 CPU based Laptop                     |
              |     2.4Ghz, 3MB cache, 4G of DDR3 RAM   :            |
              |     WDC 500GB 5400RPM 8MB HD:                        |
              |                                                      |
              |   Centos6 2.6.x kernel w/o ABI chk:   41m 21s        |
              |              or        w/  ABI chk:   71m 52s        |
              +                                                      +
              | Older laptop                                         |
              |                                                      |
              |     Dell laptop (1.7Ghz Pentium-M 512MB RAM)         |
              |        Seagate 80GB 7200ROM HD:    good build: 124m  |
              |                             ABI check failure:  93m  |

       - Once the kernel compiling is done, time to install the new RPMs

            | IMPORTANT NOTE:                                                  |
            |                                                                  |
            |    ABSOLUTELY Do **NOT** use the Upgrade or "-Uvh" RPM command   |
            |    when installing your new kernel. That will DELETE your        |
            |    previous stock centos kernel.  You don't want to get rid of   |
            |    the old one until you are sure this new kernel boots, its     |
            |    stable, etc.                                                  |
            |                                                                  |
            |   Again, be sure to ONLY use the Install or "rpm -ivh" command.  |

            # IMPORTANT
            # Make a backup of your grub.conf just in case something goes wrong
            cp /boot/grub/grub.conf /boot/grub/Old/grub.conf.`date +%m%d%y`

            # Elrepo Kernel code:  
            #  Update the kernel version numbers to reflect your new kernel
            cd /usr/src/redhat/RPMS/
            #Consider removing the older kernel header files only if you never intend to run those
            # older kernels.  If you don't do this, you will get errors like:
            #  error: Failed dependencies:
            #     kernel-headers 4.8.11-1.ax25.el6 conflicts with kernel-ml-headers-4.8.11-1.ax25.el6.x86_64
            #     kernel-headers 3.17.5-1.ax25.el6 conflicts with kernel-ml-headers-3.17.5-1.ax25.el6.x86_64
            #     kernel-headers 4.8.4-1.ax25.el6 conflicts with kernel-ml-headers-4.8.4-1.ax25.el6.x86_64
            sudo rpm -e kernel-ml-headers

            #Now install the new kernel
            rpm -ivh x86_64/kernel-ml-4.8.11-1.ax25.el6.x86_64.rpm 

            #Next, install the new kernel-headers
            rpm -ivh x86_64/kernel-ml-headers-4.8.11-1.ax25.el6.x86_64.rpm \

            #If you build lots of programs that might link into the kernel, you should
            #also install the kernel-devel package:
            rpm -ivh x86_64/kernel-ml-devel-4.8.11-1.ax25.el6.x86_64.rpm

            #Centos Stock code:  
            #  Update the kernel version numbers to reflect your new kernel
            cd /usr/src/redhat/RPMS/
            rpm -ivh noarch/kernel-firmware-2.6.32-220.7.1.el6.ax25.noarch.rpm \
x86_64/kernel-2.6.32-220.7.1.el6.ax25.x86_64.rpm \
x86_64/kernel-firmware-2.6.32-220.7.1.el6.ax25.x86_64.rpm \
x86_64/kernel-devel-2.6.32-220.7.1.el6.ax25.x86_64.rpm  \

       I also recommend to re-install the AX.25 libraries after upgrading the kernel
       to make sure that the proper AX.25 libs are in place as the kernel libraries
       are usually old:

          # 10/21/18:  This issue has now been fixed in the Aug 2018 version of the
          #            VE7FET repo but I need to clean up my doc completely to reflect
          #            the fixes.  TBD
          #This version reflects the VE7FET SVN repo built as of 12/07/14.  Please see the
          # compiling AX.25 section of this doc on how to get that going
          cd /usr/src/redhat/RPMS
          rpm -ivh --force x86_64/libax25-1.0.5-168.x86_64.rpm

   Centos 5:

   # NOTE#1:  I had to add the "--without kabichk" as the compile would
   #          always fail out otherwise.  The resulting kernel works fine.
   # NOTE#2: ?no longer needed? 
   #         had to add --without fips

         date; time rpmbuild -bb --target=i686 --without kabichk --with baseonly \
     --without PAE --without debuginfo --without xenonly kernel-2.6.spec

   Ok, time to install the new kernel:

     #Make a backup of your grub.conf just in case
     cp /boot/grub/grub.conf /boot/grub/grub.conf.bak

     cd /usr/src/redhat/RPMS/i686

     | IMPORTANT NOTE:                                                  |
     |    Do NOT use the Upgrade or "rpm -Uvh" command as that will     |
     |    DELETE your stock centos kernel which you shouldn't do until  |
     |    you are sure this new kernel boots, is stable, etc.   Be sure |
     |    to only use the Install or "rpm -ivh" command.                |

     rpm -ivh kernel-2.6.18-164.6.1.el5.ax25.i386.rpm 

All Versions of Centos
Since you created the kernel via an RPM method, go ahead and skip ahead to
the "Final checks and booting into the new kernel for AX.25" section
below before rebooting!

2.f - Building a kernel from source (no RPM)

If you don't want to install the kernel via an RPM, you can make the kernel manually 
without an RPM, you can do the following method.   Please note this section is
written for the older Centos 5 stock kernels:

   cd /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.i386

   make menuconfig

   Make the following changes (make sure it has either a "*" [enabled in kernel]
   or a [M] kernel module next to each item:

      +-- general setup
      |   |
      |   +--local version
      |      |
      |      +--add the text: ax25
      +-- Processor Type
      |   |
      |   +-- Processor Family: set it to what CPU this machine has (default is
      |   |   Pentium Pro
      |   |
      |   +-- Preemption Model: I change this to Low-Latency desktop but this is
      |       optional
      +-- Networking
      |   |
      |   +--Amateur Radio support
      |   |  |
      |   |  +-- Amateur Radio AX.25 Level 2 protocol   (use the space bar to
      |   |      make it a M or Module
      |   |      |
      |   |      +--  AX.25 DAMA Slave support
      |   |      +--  Amateur Radio NET/ROM protocol
      |   |      +--  Amateur Radio X.25 PLP (Rose)
      |   |      |
      |   |      +-- AX.25 network device drivers
      |   |      |      +--  Serial port KISS driver
      |   |      |      +--  Serial port 6PACK driver (NEW)
      |   |      |      +--  BPQ Ethernet driver (NEW)
      |   |      |      +--  BAYCOM ser12 fullduplex driver for AX.25 (NEW)
      |   |      |      +--  BAYCOM ser12 halfduplex driver for AX.25 (NEW)
      |   |      |      +--  BAYCOM picpar and par96 driver for AX.25 (NEW)
      |   |      |      +--  BAYCOM epp driver for AX.25 (NEW)
      |   |      |      +--  YAM driver for AX.25 (NEW) 

   From here, select Exit, Exit, Exit, Exit, "YES - save the configuration"

   Save a copy of the new kernel config:

      cp .config /tmp/config-ax25

   Ok, now in the main source directory, compile the kernel as you normally
   would or use the TrinityOS build-it script to help automate the stages:


         - make the kernel  
         - make the kernel modules
         - make the initrd file
         - move the files to the proper places
         - update grub
         - reboot

    Persistent USB Device Naming
    If you'd like to have the serial ports retain a persistent naming
    across newly added devices, reboots, etc., take a look and review 
    the "Deterministic Serial ports" portion of the "PreSetup: Centos 
    Optimizations" section and the UDEV rules above in the Kernel RPM 
    compiling section and in that 10-us-interfaces-navigator.rules file, 
    only add the lines that contain "bInterfaceNumber".  After that, 
    you should be good to go!

   Verify the USB serial ports:
   To check that the Navigator ports are recognized and installed properly, run
   the following command to see all the devices:

        ls -la /dev | grep USB

           USI_CAT -> ttyUSB0
           USI_CFG -> ttyUSB5
           USI_FSK -> ttyUSB3
           USI_PTT -> ttyUSB1
           USI_SER -> ttyUSB4
           USI_WKEY -> ttyUSB2

      It's the USI* /dev device names that you'll want to use to configure 
      Flrig and other devices

2.g - Final checks and booting into the new kernel for AX.25

Regardless of using the ElRepo or Stock Centos kernels or which version of
Centos this is for (6 and 5): 

  - Before you reboot: 

       - look at /boot/grub/grub.conf and make sure the new kernel is there at
         the top of the listing and it's expected to boot by default.  You can
         use the grub.conf backup you made to make this easy:
            diff -u /boot/grub/Old/grub.conf.`date +%m%d%y` /boot/grub/grub.conf

         Make sure your new kernel is:

            a) listed

            b) the top of the list (default to be booted) or the "default=" parameter points
               to your new kernel (remember it starts with a 0 not a 1)

       - Next, make sure the new kernel modules are present

            find /lib/modules/$NEWKERNELVER*/kernel/drivers/net/hamradio/

               for example, for a 4.8.11 Elrepo ML kernel

            find /lib/modules/$NEWKERNELVER*/kernel/net/rose/rose.ko                                         
            find /lib/modules/$NEWKERNELVER*/kernel/net/ax25/ax25.ko

            ALL of those files MUST be present or that means your kernel recompile did
            NOT include the AX.25 configuration change!

   If you're happy with what you see in the kernel install, grub, etc., go ahead 
   and reboot to start up the new kernel!

   Once rebooted, make sure that the AX25 kernel module is available by
   running the command and making sure the kernel module is present:

            ls /lib/modules/`uname -r`/kernel/net/ax25

   You can also check by looking at:

     grep AX25 /boot/config-`uname -r`.el5ax25

     that should come back with something like:

3. Compiling / Installing the various AX25 apps and tools for HF/VHF/UHF packet

The AX.25 code that's built into the kernel from the above stages creates the
foundation but now you need the toolkit to create the solution.  That solution
comes in three main packages: ax25apps, ax25tools, and libax25.  None of these 
packages are available for stock Centos so we need to either find pre-built 
RPMs or build them ourselves.  

With that said, there has been a bit of fragmentation in this area for some time.
It's always been recommended for people to use the "Official AX.25" sources found
on sourceforge.net but it has been:

    1) OLD and aren't current (have known bugs)
    2) Don't have the required .SPEC files to build clean RPMs

Here is a breakdown of the primary versions out there and what I recommend:

     Un-Official AX.25 Tools maintained by VE7FET:
     ** Recommended **

     # 10/21/18:  The Aug 2018 version of the VE7FET repo has major fixes but 
     #            I need to clean up my doc completely to reflect the fixes.  TBD
     This repository is a third fork of the AX.25 tools with many fixes 
     applied and as of Dec, 2014.  It has also become the recommended AX.25 
     version for FBB and FPAC as well.  The same risk remains if it has all 
     the fixes that are in the official CVS repo (mentioned below) but it seems 
     this version of the libraries are the best ones to use today:


          You can see an update list of patch descriptions here:


          Pre-build RPMs, Debs, etc used to be posted on the legacy Goggle site
          but they haven't been moved to the new site just yet (link given for
          historical reasons):


     Official release AX.25 Tools:
     NOT Recommended
     This "official" AX.25 repository can be found at:


     The currently "released" ax25-tools at version 0.10rc4 from June, 2013, has 
     several known problems.  For example:

        - If you try to run the netromd program and specifically the nrattach 
          command for each unique NR device, the ax25 tool will keep re-issuing 
          the name nr0 device and not issue a unique device name like nr0, nr1, 
          nr2, etc.

          Bug report: http://blog.gmane.org/gmane.linux.hams/page=22
          (Fixed in the F6BVP variant):

        - When using ax25ipd for UDP wormhole connections, no connections
          will work and in the system logs, you'll see errors of:

              control byte non-zero

          Bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606338
          (NOT Fixed in F6BVP code).  To be addressed soon per Lee VE7FET 

     Official unreleased AX.25 Tools (SVN):
     NOT Recommended
     As part of the "Official" sources, there is a GIT (was CVS) version of the tools
     available at:


     which is newer than the officially released code.  It still significantly lags 
     behind the fixes available from the VE7FET versions mentioned above.  A few notes:

         1. This repo was moved over to GIT and it does have newer fixes but still
            not the superset like VE7FET's.

         2. As of 10/20/11, this CVS version contains some fixes over the "stable" 
            release but this CVS tree is still very old

         WARNING:  When you install the CVS code, it may DELETE any existing
                   configuration files in /etc/ax25.  Make sure you backup that 
                   directory before installing this new code

     Un-Official AX.25 Tools for FPAC:
     NOT Recommended

     ** I learned via an email dialog with F6BVP on 6/16/2012 that VE7FET merged
        in all of Bernard's changes as of September 2011 and the VE7FET version 
        has now superseded F6BVP's version.

     There is a version of the AX.25 tools from the maintainer of the FPAC packet 
     suite.  This version is also considered to be much better than the official 
     AX25 Tools CVS tree but it suffers the same risk as the VE7FET project 
     mentioned in #2 above.


Ok, got all that?  If your head is spinning, just pick the VE7FET code!

3.a - Fetching and preparing the AX25 packages for RPM packaging

Creating RPMs from SRPMs for the AX.25 tools:
For creating RPMs, the VE7FET versions of AX.25 tools source code have SPEC 
file included.

Next, You can get the SPEC files from either my file server or from the VE7FET 
archives following this section's steps.  

      Using KI6ZHD's spec and patch files (RECOMMENDED)

      cd /usr/src/redhat/SPECS
      wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/libax25.spec
      wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ax25apps.spec
      wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ax25tools.spec

      #Patches required for Centos7/6 for the 2/10/19 Git pull of the VE7FET sources
      cd /usr/src/redhat/SOURCES
      wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ve7fet-call.patch

      Now please skip to the next section

      (NOT-RECOMMENDED) : Updating the older Fedora SPEC files
      If you want to put the spec files together yourself with the with the 
      older source code:

      On the Fedora site, this page is a little funky on how to use it.  In 
      the table, find the "Koji" column.  Following list of apps, click on 
      the Koji number for the respective app.

         NOTE: It seems that Centos 5.x's RPM program claims that the FedoraCore11 
               packages are corrupt and thus, it seems the F11 packages are 
               incompatible but the FC9 versions seem ok.

               BTW, if you didn't already know it, RHEL 5/CENTOS 5 uses the same 
               libraries, etc as FedoraCore 9!

      (please skip to the next section)

      Downloading pre-built sources (NOT RECOMMENDED)
      If you want to try installing the pre-built sources, go ahead and give it a try from:

         #Download a snapshot of the current Master tree:
         wget https://github.com/ve7fet/linuxax25/archive/master.zip

         #or download things via Git clone
         cd /usr/src/redhat/SOURCES
         git clone git://github.com/ve7fet/linuxax25.git

      (please skip to the next section)


  (RECOMMENDED): Building up the recommended VE7FET sources:
  First, get the newest versions from Git

    #Get and put the sources in the right place
    cd /usr/src/redhat/BUILD

    #Let's get the newest code
    git clone https://github.com/ve7fet/linuxax25.git

    # When I did that above command, it creates a directory named "linuxax25" and in there, there
    # are three sub-directories:
    #   ax25apps
    #   ax25tools
    #   libax25

    #Next, we need to get the package version details of the sub-packages
    cd linuxax25
    echo "Git hash: `git log | head -n3 | grep -i -e commit -e date`"
    echo "LIB_VER: `grep AC_INIT libax25/configure.ac | awk -F', ' '{print $2}'`"
    echo "APPS_VER: `grep AC_INIT ax25apps/configure.ac | awk -F', ' '{print $2}'`"
    echo "TOOLS_VER: `grep AC_INIT ax25tools/configure.ac | awk -F', ' '{print $2}'`"
       #I just got the following after a download on 06/11/19
       Git hash: commit 498589469c52178b300f8b2aa2abff3c78657416
       Date:   Sun Feb 10 02:32:18 2019 -0800
       LIBVER:   1.1.3
       APPSVER:  2.0.1
       TOOLSVER: 1.0.5

       #Let's start with libax25 package
          cd libax25
          cd ..

          #Update this mv command and the tar command below to reflect the correct version name
          mv libax25 libax25-1.1.3

          # create the archive name with the correct version, Git commit date and  GIT hash 
          # using the first 8 characters (most significant bits) of the Git hash
          tar czvf /usr/src/redhat/SOURCES/libax25-1.1.3-20190210git49858946.tgz libax25-1.1.3/*

          # You now need to update the ax25apps.spec "Release:" and "BuildRoot:" variables
          # to reflect or include the Git revision.  
          vim /usr/src/redhat/SPECS/libax25.spec

          # As of 06/11/19, that would be:
          #    %global git_commit 498589469c52178b300f8b2aa2abff3c78657416
          #    %global git_date 20190210

          #    Version:        1.1.3
          #    Release:        1.%{git_suffix}%{?dist}
          #    BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
          #    BuildRequires:  libax25-devel >= 1.1.3, libncurses-devel
          #    BuildRequires:  libax25-devel >= 1.1.3, ncurses-devel
          #    Requires:       libax25 >= 1.1.3

          # Ok, you're done with this package for now.  

       #Next up, Let's start with ax25apps package
          cd ax25apps
          cd ..

          #Update this mv command and the tar command below to reflect the correct version name
          mv ax25apps ax25apps-2.0.1
          # create the archive name with the correct version, Git commit date and  GIT hash 
          # using the first 8 characters (most significant bits) of the Git hash
          tar czvf /usr/src/redhat/SOURCES/ax25apps-2.0.1-20190210git49858946.tgz ax25apps-2.0.1/*

          # You now need to update the ax25apps.spec "Release:" and "BuildRoot:" variables
          # to reflect or include the Git revision.  

          vim /usr/src/redhat/SPECS/ax25apps.spec

          # As of 06/11/19, that would be:
          #    %global git_commit 498589469c52178b300f8b2aa2abff3c78657416
          #    %global git_date 20190210

          #    Version:        2.0.1
          #    Release:        1.%{git_suffix}%{?dist}
          #    BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
          #    BuildRequires:  libax25-devel >= 1.1.3, libncurses-devel
          #    BuildRequires:  libax25-devel >= 1.1.3, ncurses-devel
          #    Requires:       libax25 >= 1.1.3

          # Ok, you're done with this package for now.  

       #Finally, let's finish with the ax25tools package
          cd ax25tools
          cd ..
          mv ax25tools ax25tools-1.0.5
          #Update this mv command and the tar command below to reflect the correct version name
          tar czvf /usr/src/redhat/SOURCES/ax25tools-1.0.5-20190210git49858946.tgz ax25tools-1.0.5/*

          # You now need to update the ax25apps.spec "Release:" and "BuildRoot:" variables
          # to reflect or include the Git revision.  

          vim /usr/src/redhat/SPECS/ax25tools.spec

          # As of 07/07/16, that would be:
          #    %global git_commit 498589469c52178b300f8b2aa2abff3c78657416
          #    %global git_date 20190210
          #    Version:        1.0.5
          #    Release:        1.%{git_suffix}%{?dist}
          #    Source0:        %{name}-1.0.5-%{release}.tar.gz
          #    BuildRequires:  libax25-devel >= 1.1.3, zlib1-devel
          #    BuildRequires:  libax25-devel >= 1.1.3, zlib-devel
          #    Requires:       libax25 >= 1.1.3

   #Now clean up the unneeded Git repo
   cd /usr/src/redhat/BUILD
   rm -Rf ax25

   #Now skip to the next section

   |  NOT RECOMMENDED: Follow this section if you really want to use the Official |
   |                   AX.25 Repo which doesn't have all of the fixes that the    |
   |                   VE7FET repo does.  Please skip to the next section to      |
   |                   follow the recommended VE7FET based instructions.          | 
   |                                                                              |
   |     NOTE:  These non-recommended instructions are *Out of Date*              |

      #Get and put the sources in the right place
      cd /usr/src/redhat/SOURCES

      wget -O ax25apps-1.0.2.tar.gz http://linuxax25.googlecode.com/files/ax25apps-1.0.2.tar.gz
      wget -O ax25tools-1.0.2.tar.gz http://linuxax25.googlecode.com/files/ax25tools-1.0.2.tar.gz
      wget -O libax25-1.0.3.tar.gz  http://linuxax25.googlecode.com/files/libax25-1.0.3.tar.gz

     Extract the spec files (only realistically needed once and then you have the SPEC files)

     cd /usr/src/redhat/SPECS

     tar xzvf /usr/src/redhat/SOURCES/ax25apps-1.0.2.tar.gz ax25apps-1.0.2/ax25apps.spec
     mv ax25apps-1.0.2/ax25apps.spec .
     rmdir ax25apps-1.0.2

     tar xzvf /usr/src/redhat/SOURCES/ax25tools-1.0.2.tar.gz ax25tools-1.0.2/ax25tools.spec
     mv ax25tools-1.0.2/ax25tomls.spec .
     rmdir ax25tools-1.0.2
     tar xzvf /usr/src/redhat/SOURCES/libax25-1.0.3.tar.gz libax25-1.0.3/libax25.spec
     mv libax25-1.0.3/libax25.spec .
     rmdir libax25-1.0.3

3.b - Patching the AX25 code with additional fixes

  | NOTE:                                                                       |
  |      If you are installing the VE7FET AX.25 libraries as of 12/1/2014, you  |
  |      will NOT need these patches.  This is kept here for people choosing to |
  |      use older versions                                                     |
  |                                                                             |
  |  10/21/18:  The Aug 2018 version of the VE7FET repo has major fixes but     |
  |             I need to clean up my doc completely to reflect the fixes.  TBD |
  |                                                                             |

In the older VE7FET versions of code, there are a few more changes to make.  These
manual patches should no longer be required (read above) but are kept here for 
historical reasons:

  As of ax25tools-1.0.2-109, there is a bug in the hdlcutil Makefile that makes
  the compile fail.  There is also a new netrom patch that changes the way that
  Linux accepts Netrom routes based on their quality metrics to be more compatible
  with Kantronics KPC3s.  This is described here: 


  To fix these issues, either use my updated SPEC file or edit 
  yours and include these simple patches:

         cd /usr/src/redhat/SPECS
         wget -O ax25tools.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/Old/ax25tools.spec

      Alternatively, you can add the following lines to your own SPEC file:

        - Under the "Source0" line, add the lines:
             Patch0:         ax25tools-1.0.2.diff
             Patch1:         ax25tools-netrom-kpc3-qual.diff

        - Under the "%setup -q -n %{name}-1.0." line, add the line:
             %patch0 -p1
             %patch1 -p1
      You can find the patch here:
        cd /usr/src/redhat/SOURCES
        wget -O ax25tools-1.0.2.diff ihttp://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ax25tools-1.0.2.diff
        wget -O ax25tools-netrom-kpc3-qual.diff ihttp://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ax25tools-netrom-kpc3-qual.diff

3.c - Compiling and Installing the new AX25 RPM with GLIBC conflict consideration

   - Before you start building things, you need a few more packages:

        sudo rpm -Uvh zlib-devel ncurses-devel

   | NOTE: These commands assume a 64bit kernel.  If you don't have a 64bit |
   |       kernel, use "--target=i686" instead                              |

Now compile and install the RPMS in this ***SPECIFIC order*** (Yes, this order matters):

   - libax25 first
        #The libax25 library compiles without any other RPMs
        #Compile it:

        cd /usr/src/redhat/SPECS
        # Do NOT run this as the root user
        #  10/21/18:  The Aug 2018 version of the VE7FET repo has major fixes but     
        #              I need to clean up my doc completely to reflect the fixes.  TBD 
        rpmbuild -bb --target=x86_64 libax25.spec

        | Important:                                                                                                      |
        |            Next, you *must* now install the libax25 RPM right now before you can build the other packages       |
        |                                                                                                                 |
        |            When you install this newer set of libs via RPM, it *WILL* conflict                                  |
        |            with Centos's stock AX.25 libraries found in GLIBC.  This                                            |
        |            is a known issue and cannot be avoided until the kernel sources are updated.                         |
        |                                                                                                                 |
        |            It's important to understand that:                                                                   |
        |                                                                                                                 |
        |             1. To install this new RPM, you will have to force it to                                            |
        |                overwrite the stock libs.  If you don't FORCE the RPM installation,                              |
        |                you will see errors like:                                                                        |
        |                                                                                                                 |
        |                   Preparing...                ########################################### [100%]                |
        |                   package libax25-devel-1.0.3-1.x86_64 is already installed                                     |
        |                   file /usr/include/netax25/ax25.h from install of libax25-devel-1.0.3-1.x86_64 \               |
        |                     conflicts with file from package glibc-headers-2.12-1.80.el6_3.7.x86_64                     |
        |                                                                                                                 |
        |             2. Once overwritten, future GLIBC Yum upgrades will give also give                                  |
        |                fatal errors and you won't be able to properly update                                            |
        |                your system.  To work around this issue, download                                                |
        |                and run the following script *before* running the usual                                          |
        |                "yum update" command which includes any GLIBC updates.                                           |
        |                                                                                                                 |
        |                  http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/update-glibc-ax25-workaround.sh |
        |                                                                                                                 |
        |                Once this script run, it will automatically RE-INSTALL the conflict                              |
        |                libax25-devel package.  Your system will then be up to date.                                     |

        | WARNING:                                                              |
        |           I had been happliy running the 2016 version of the VE7FET   |
        |           code for years but after installing these new 2019 version, |
        |           my machine kernel paniced.  I beleive the issue was due to  |
        |           installing these packages while the AX.25 system was still  |
        |           operational.  I HIGHLY recommend to shutdown your AX.25     |
        |           stack before installing all these new RPMs.                 |
        |                                                                       |
        |           If you use my packetrig.sh script, you would simply run:    |
        |                                                                       |
        |                sudo /usr/local/sbin/packetrig.sh stop                 |

        #Forcing due to conflicts with the stock GLIBC ax.25 libs

           #Install the newest VE7FET code built from Git
           sudo rpm -Uvh --force /usr/src/redhat/RPMS/x86_64/libax25-1.1.3-1.20190210git49858946.el6.x86_64.rpm \

              --- or ---

              #(NOT RECOMMENDED) The last VE7FET binary release (quite old)
              cd /usr/src/redhat/RPMS/x86_64
              sudo rpm -ivh --force libax25-1.0.3-1.el6.x86_64.rpm libax25-devel-1.0.3-1.el6.x86_64.rpm

   Next up, now we need to compile and install the other AX.25 packages based upon these 
   newly installed libax25 libraries:

   - ax25-apps
        #compiles without any other RPMs dependencies except those listed above
        # Compile it:
        cd /usr/src/redhat/SPECS
        #  Do not run this as the root user
        rpmbuild -bb --target=x86_64 ax25apps.spec
        #Install the newest VE7FET code built from Git
        sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/ax25apps-2.0.1-1.20190210git49858946.el6.x86_64.rpm

          --- or ---

          #(NOT RECOMMENDED): The last VE7FET binary release (quite old)
          sudo rpm -Uvh ax25apps-1.0.2-1.x86_64.rpm

   - ax25-tools
        #compiles without any other RPMs dependencies
        #Compile it:
        cd /usr/src/redhat/SPECS
        #  Do not run this as the root user
        rpmbuild -bb --target=x86_64 ax25tools.spec

        #Install the newest VE7FET code built from Git
        sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/ax25tools-1.0.5-1.20190210git49858946.el6.x86_64.rpm   

          --- or ---

          #(NOT RECOMMENDED): The last VE7FET binary release (quite old)
          rpm -Uvh ax25tools-1.0.2-1.x86_64.rpm

     | Important:                                          |
     |            One final step for the ax25tools package |

        There seems to be a minor error with this RPM as it doesn't create the 
        required dir structure for mheard.  If you don't run the below command, 
        you'll see:
           mheard: cannot open mheard data file

        To fix that issue, run this command (only needed one time):

           sudo mkdir -p /var/ax25/mheard

Ok.. you're DONE!  Congrats!   Go ahead and skip to the next major section for
configuration the AX.25 stack, building/installing applications, etc!   

You can now restart the AX.25 stack if you previously shut down your functioning 
sytstem for an upgrade.  If this is your first time working up the AX.25 system, please 
continue reading the next sections on how to get things configured and operational.

| LEGACY Section :  -- DO NOT USE --                                           |
|                                                                              |
| Below is the legacy details in using other AX.25 repositories such as the    |
| old F6BVP sources or the official AX.25 repositories.  This is saved for     |
| posterity as it might help some specific HAMS but I do NOT recommend to use  |
| these old, buggy versions of code!                                           |

     #Get and put the sources in the right place
     cd /usr/src/redhat/SOURCES

      wget -O ax25-apps-0.0.8-rc2.1.patched_f6bvp.tar.bz2 \

      wget -O ax25-tools-0.0.10-rc2.patched_f6bvp.tar.bz2 \ 

      wget -O libax25-0.0.12-rc2.patched_f6bvp.tar.bz2 \

   As mentioned above, this repo doesn't include any SPEC files to build RPMs 
   either but you can get the SPEC files from my site or get and modify the
   ones from the Fedora group:


      #Get the baseline SPEC files (using my TrinityOS versions):

      cd /usr/src/redhat/SPECS
      wget -O ax25-apps.f6bvp.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/Old/ax25-apps.f6bvp.spec
      wget -O ax25-tools.f6bvp.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/Old/ax25-tools.f6bvp.spec
      wget -O libax25.f6bvp.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/Old/libax25.f6bvp.spec

   De-compress the archives and we have to rename them to make things match up 
   for a clean RPM build:

      cd /usr/src/redhat/BUILD

      tar xjvf ../SOURCES/libax25-0.0.12-rc2.patched_f6bvp.tar.bz2
      mv libax25-0.0.12-rc2.patched_f6bvp libax25-0.0.12
      tar cjvf ../SOURCES/libax25-0.0.12-rc2.patched_f6bvp.tar.bz2 libax25-0.0.12/ 
      tar xjvf ../SOURCES/ax25-apps-0.0.8-rc2.1.patched_f6bvp.tar.bz2
      mv ax25-apps-0.0.8-rc2.patched_f6bvp ax25-apps-0.0.8-rc2.1
      tar civf ../SOURCES/ax25-apps-0.0.8-rc2.1.patched_f6bvp.tar.bz2 ax25-apps-0.0.8-rc2.1/

      tar xjvf ../SOURCES/ax25-tools-0.0.10-rc2.patched_f6bvp.tar.bz2
      mv ax25-tools-0.0.10-rc2.patched_f6bvp ax25-tools-0.0.10
      tar civf ../SOURCES/ax25-tools-0.0.10-rc2.patched_f6bvp.tar.bz2 ax25-tools-0.0.10

   If you choose to modify the Fedora SPEC files and not use mine, you'll need to 
   edit each one of those SPEC files to reflect the correct f6bvp archive 
   name, versioning, and changelog:

         Version:        0.0.12
         Release:        rc2.patched_f6bvp%{?dist}

         Source0:        http://f6bvp.free.fr/logiciels/ax25/%{name}-%{version}-rc2.patched_f6bvp.tar.bz2

         * Fri Sep 17 2010  0.0.12rc2-patched_f6bvp
         - Patched libax25 for fixes unavailable in the official AX25-tools sources
         - SPEC file created by dranch@trinnet.net

         Version:        0.0.8
         Release:        rc2.1%{?dist}
         Source0:        http://f6bvp.free.fr/logiciels/ax25/%{name}-%{version}-rc2.1.patched_f6bvp.tar.bz2

         BuildRequires:  autoconf, automake, libtool
         * Sun May 09 2010  0.0.8rc2-patched_f6bvp
         - Patched ax25-apps for fixes unavailable in the official AX25-tools sources
         - SPEC file created by dranch@trinnet.net

         Version:        0.0.10
         Release:        rc2%{?dist}
         Source0:        http://f6bvp.free.fr/logiciels/ax25/%{name}-%{version}-rc2.patched_f6bvp.tar.bz2

      remove any BuildRequires reference to fltk-devel
         * Mon May 19 2010  0.0.10rc2-patched_f6bvp
         - Patched ax25-tools for fixes unavailable in the official AX25-tools sources
         - SPEC file created by dranch@trinnet.net

   Now compile and install the RPMS in this SPECIFIC order (it matters):

     | NOTE: These commands assume a 64bit kernel.  If you don't have a 64bit |
     |       kernel, use "--target=i686" instead                              |

      - libax25

           #compiles without any other RPMs
           #Compile it:
           rpmbuild -bb --target=x86_64 libax25.f6bvp.spec
           #Install it:
           cd /usr/src/redhat/RPMS/x86_64
           rpm -ivh libax25-0.0.12-rc2.patched_f6bvp.el6.x86_64.rpm libax25-devel-0.0.12-rc2.patched_f6bvp.el6.x86_64.rpm

      - ax25-apps
           #compiles without any other RPMs dependencies
           #Compile it:
           rpmbuild -bb --target=x86_64 ax25-apps.f6bvp.spec
           #Install it:
           cd /usr/src/redhat/RPMS/x86_64
           rpm -ivh ax25-apps-0.0.8-rc2.1.el6.x86_64.rpm

      - ax25-tools
           #compiles without any other RPMs dependencies
           #Compile it:
           rpmbuild -bb --target=x86_64 ax25-tools.f6bvp.spec
           #Install it:
           cd /usr/src/redhat/RPMS/x86_64
           rpm -ivh ax25-tools-0.0.10-rc2.el6.x86_64.rpm

           #There seems to be a minor error with this RPM as
           #it doesn't create the required dir structure
           #for mheard.  Let's fix that
           mkdir -p /var/ax25/mheard

| LEGACY:  -- DO NOT USE --                                             |
|                                                                       |
| NOTE:                                                                 |
|       If you used the Official AX25 repository source code, there are |
|       some significant bugs you should be aware of and fix them       |

     To fix the above mentioned Netrom issue, do the following as both 
     the Fedora Project AX25 tools and the official AX25 tools are very 
     VERY old (the F6BVP code has this already fixed):

       - go to the FedoraProject URL and find the current ax25-tools
         and click on the NUMBER for that table row

       - Click on the FedoraCore8 builds as it's the only SPEC file that
         will work for the baseline

       - Scroll down and search for the row that says "RPMS SRC"
         and click on "download" into /tmp

       - mv /tmp/ax25-tools-0.0.8-3.fc9.src.rpm /usr/src/redhat/SRPMS/

       - rpm -Uvh /usr/src/redhat/SRPMS/ax25-tools-0.0.8-3.fc9.src.rpm

       - Next, we need to download the current released version of 
         ax25-tools from http://www.linux-ax25.org/wiki/CVS which 
         should be the ancient 0.10RC2 into /tmp/

       - cd /tmp; tar xzvf ax25-tools-0.0.10-rc2.tar.gz

       - vim ax25-tools-0.0.10-rc2/netrom/nrattach.c
         - find the lines:

              #ifdef  notdef
                      if (!startiface(dev, hp))
                              return 1;

         - and DELETE the lines:

              #ifdef  notdef

       - Now re-create the archive:

            rm ax25-tools-0.0.10-rc2.tar.gz
            tar czvf ax25-tools-0.0.10-rc2.tar.gz ax25-tools-0.0.10-rc2
            cp ax25-tools-0.0.10-rc2.tar.gz /usr/src/redhat/SOURCES/

       - Now to fix the spec file

            vim /usr/src/redhat/SPECS/ax25-tools.spec
              - # out the lines starting with:
                    %patch0 -p1
                    %patch1 -p0

              - change the version from 0.0.8 to 0.0.10rc2
              - change the release from 3 to 2
              - under the %changelog%, add:
                   Sat Oct 15 2011 David Ranch  0.0.10rc2-2
                   - Fix nrattach for duped nr0

       - Compile it:
          rpmbuild -bb --target=i686 ax25-tools.spec
        #Install it:
          rpm -Uvh /usr/src/redhat/RPMS/i686/ax25-tools-0.0.10rc2-1.i686.rpm

   - ax25-apps
        #compiles without any other RPMs

        #   control byte non-zero
        #   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606338

        diff ax25-apps-0.0.6/ax25ipd/kiss.c

        <                               if (*iframe == '\0' || *iframe == 0x10) {
        >                                 if ((*iframe & 0xf) == 0) {
        >                                 /* dranch: changed due to for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606338 */
        >                               /* if (*iframe == '\0' || *iframe == 0x10) { */

        #Compile it:
        rpmbuild -bb --target=i686 ax25-apps-0.0.6-2.i686.rpm
        #Install it:
        rpm -ivh /usr/src/redhat/RPMS/i686/ax25-apps-0.0.6-2.i686.rpm

4. - Updating Centos's ALSA sound system

Centos kernels (both Centos6 and Centos5) have VERY OLD sets of ALSA libraries.  
Update those via the ElRepo repository.  

  Why the update?
      I was working with the primary Fldigi developer, W1HKJ Dave to track down
      troublesome TX-based ALSA timeouts on specific modes like Contestia, 
      FeldHell, etc. on Centos5.  He recommended to use the tip-of-tree ALSA and
      PortAudio code vs. the ElRepo portaudio-0.19-8 RPMs:

         NOTE: make sure you have the updated ElRepo ALSA RPMs installed first

   links http://fedoraproject.org/wiki/EPEL --->


   - Install the newest ALSA RPMs and either reload the required kernel modules for 
     sound OR just reboot the computer

    - Make sure your soundcard is being recognized once ALSA starts, run:
       cat /proc/asound/cards

      Also make sure it's running the expected version of ALSA:
       cat /proc/asound/version

5. - Packet Tutorial - Learning about AX.25 packet radio

  There is a lot more to packet radio that just connecting to BBSes:  

     - There is the entire world of APRS (messaging, location, beacons, etc)
     - Winlink email messaging
     - There are DX clusters
     - Did you know there are Packet NETs out there?  Even as of January 2014?

  Read more here:

   - My intro to packet radio at:


   - Theory and Practical packet tutorials for VHF and HF:
     I recommend you read much of these up front over lots
     of coffee.  Maybe play as you go but there are a tips
     and tricks in those URLs that really help make packet
     work MUCH MUCH better.  The TrinityOS packetrig.sh
     script has much of these lessons integrated into it

   #Getting started with Packet radio

   #Detailed breakdowns of all TNC details

   #Setting proper AFSK and audio levels for packet TNCs and other digital 

   #More good details on Packet

What is a "digipeater" vs. a  "node"
Beyond reading the excellent links in the "Packet Tutorial" section
above, packet users can reach a remote station in one of four ways: 
direct, digipeated, node, or NetRom/ROSE/KNet:


      o ------ o ------ o ------ o ------ o
     My      first   second    third    destination
    station   hop      hop      hop

A packet that is digipeated is sent with an explicit routing path
from the originating packet machine.  With that digipeated path, every 
follow-on packet will also follow that path.  When traversing that say 
three hops path, the packet is copied from one hop to the next but if 
there is a decode failure mid-path, the packet is lost and the 
originator's system will have to wait until it's AX.25 stack times out 
and re-transmits the original packet.  A VERY slow process.  It's generally 
accepted that digipeating more than THREE hops will be unreliable as you 
significantly increase a packet's chances of getting corrupt, be collided 
with, etc. with each additional hop.

Node / KaNet:
Using intermediate nodes to send relay packets is different in the sense 
in two main ways:

   Manual connection
   The packet originator has to manually *connect* to each hop in the path.
   Putting it another way, the originator would create a connection to the
   first hop, then create a connection from that machine to the second hop, 
   etc. until he or she reaches the desired destination.  This is a somewhat
   tedious process.

   Automatic in-path re-transmission
   The major benefit of using nodes is that if there is a packet loss in the
   middle of the path, the two intermediate nodes will automatically 
   re-transmit the lost packet and continue on.  This is FAR more reliable, 
   faster, etc.

NetROM / KNet / FlexNet / ROSE 
These technologies are very similar to each other in the sense that they
ALL send out periodic "route" updates advertising what local services your
machine offers (a PBBS, a full BBS, a Node, a digipeater, etc).  Other machines
that understand these protocols then build a table of these nodes and how they
are interconnected.  Once the "routing" table is built, this system allows to
simply connect to the DESTINATION machine without having to know the path. Once
the connection request is made, each packet is "NODED" along the path.  Putting 
that another way, you get the benefit of not having to manual create connections 
along the way like a classic node or KaNet connection yet if there is a packet 
failure mid-path, you don't have the performance and delay issues that are 
experienced with a digipeater.

5a. - What is AMPR and step1-: how to get your own AMPR-based IP address

The AMPR network is an overlay TCP/IP network that runs over the Internet using the 
Internet address space 44.x.y.z to IPv4 address range to interconnect other 
amateur radio systems.  Amateur operators can request static subnets from a usful /29 
(6 usable addresses all the way up to /24s and even /22s for full BGP Internet announcements... 
all just for amateur radio ops and for free!  

Common AMPR address space uses today are to support sending amateur-radio centric traffic
like RoIP systems like EchoLink, IRLP, AllStar, and DMR.  You could use it for messaging 
traffic (SMTP email), linking HSMM-HAM (10Mb/s+ WIFI based systems), Internet based access 
to BBSes like JNOS & FBB, and AX.25 packet switches like Xnet & BPQ, etc.  AMPR can 
be used for anything as permitted over the airwaves per your amateur radio license.  You can 
learn more about what AMPR can be used for by starting here:


You can find a list of who's on the AMPR network today here:


A little technical background first:

  Encapsulation Protocols
    - The AMPR overlay network works with one of two different protocols:

       IPIP - This "IP in IP" or AXIP tunneling protocol is recognized as 
              protocol 94 by the IANA and is still the primary protocol used to 
              connect to other AMPR hosts.  Not every ISP forwards these packets 
              so it's wise to test for it first.

       UDP  - This is the very common User Datagram Protocol used over the 
              Internet today and the AMPR system calls it AXUDP.  Though it's
              much easier to get working, not all AMPR systems support it

  Overlay network Topology

    Remote AMPR Station reachability
    As mentioned before, the AMPR network is an overlay network that runs on top 
    of the Internet.   All remote endpoints are supposed to be directly reachable 
    via a full mesh (meaning every station has a tunnel to EVERY other remote AMPR
    station).  Though heavily frowned upon, you can sometimes reach remote AMPR 
    stations that are otherwise unreachable via the AMPR gateway machine

    Internet access:
    The AMPR system is completely available TO and FROM the Internet via the 
    above mentioned AMPRGW.UCSD.EDU machine.  

        NOTE:  It used to be understood that this AMPR gateway machine (once called
               "mirrorshades") would *ONLY* allow outbound connections to the Internet 
               and the related REPLY traffic from the Internet.  This has not been
               the case for some time now and it supports full bi-directional traffic.

               IMPORTANT:   As such, once an AMPR tunnel is up between your 
               !!!!!!!!!    machine and the gateway, it's CRITICAL to run a firewall 
                            to block any network attacks coming in from the
                            Internet via this new tunnel.  It's worth noting
                            that the AMPR IPIP tunneling only forwards IPv4
                            traffic and not IPv6.
  Remote Endpoint Advertisements
    - The learning of remote stations to connect to is done via two mechanisms today:

       encap.txt - This is a text file that contains all AMPR IP addresses of  
                   AMPR enabled remote stations and their respective public IP address 
                   to tunnel to.  This file is downloadable from the Internet via an FTP 
                   server and also automatically emailed to all AMPR members who request 
                   it via the AMPR portal.

       rip44 - This dynamic routing protocol is based upon the classic distance-vector 
               routing protocol from years past.  The use of this dynamic routing protocol 
               is gaining popularity over the static encaps file approach since the route
               update lag of the encap.txt file doesn't work fast enough with AMPR stations
               who have dynamic Internet IP addresses.

Testing Home Network / AMPR IPIP Network Compatibility:
Before we go much further, I would recommend you FIRST test to see if you can receive 
IPIP encapsulation packets sent via your ISP.  To do this, it's easiest to coordinate 
with a HAM who already has an AMPR system running (list me).  Your local AMPR IP coordinator 
should also be able to do this for you using a temporary IP address out of the 44.128.x.x 
testing block.  If your AMPR coordinator can't help you, feel free to contact me and 
I can send some test traffic to you.  

Once you have contacted someone who can send your external Internet IP address some Protocol 4
/ IPIP traffic, you'll need a packet sniffer on your desired AMPR system.  This can include 
systems running operating systems like Linux and FreeBSD and router vendors like Mikrotik.  
Using a tool like "tcpdump" or "wireshark", you need to capture packet traffic ideally before 
any specific network "routers" that do firewalling, NAT, etc.

Let's get started:

  | Assumptions:                                                    |
  |                                                                 |
  |    - You tested your ISP connection and you have confirmed you  |
  |      *CAN* receive  protocol 4 / IPIP tunnel packets to your    |
  |      AMPR machine                .                              |
  |                                                                 |
  |    - We are only configuring IPIP tunnels for now, AXUDP base   |
  |      tunnels might be added at a later date but it's less       |
  |      commonly used                                              |

   3) The first thing you need to do is setup an AMPR Portal account.  This is the primary 
      website to find out who your AMPR coordinator is, request for AMPR IP allocations, etc
      Log into the following site and apply for an account:

        https://portal.ampr.org --> Register

      Once you submit the form, you'll be emailed with a confirmation URL
      that you click on, pass a challenge, and you'll again be emailed now
      with a temporary password.  Be sure to log into the system ASAP and 
      change your password to something more secure.

  2) Next, you need to do is request an AMPR IP allocation.  Go to the following URL and 
     click on your specific country and then region:


     From this interface, you can directly request a new allocation or find your Coordinator's
     email address to email them for an allocation.  In this email, you would specify 
     how many IP addresses you want (you can ask for just one, a few or with a compelling 
     reason.. even full subnets), and what you'd like those IPs to resolbve to via DNS entries.
     In my setup, I have: - ki6zhd-net.ampr.org - ki6zhd.ampr.org

   3) It's important to subscribe to the AMPR "44Net" email list to keep up on what's going
      on in the network as well as have a venue to ask questions, etc.  It's not a very high
      message volume email list:


   4) Once you have your AMPR IP allocation, it's time to setup your new AMPR IPs.  This can 
      be done via the portal.ampr.org website:

        Web method: 
          - Log into the https://portal.ampr.org/ site with your username
            and password

          - Goto Gateways --> Manage --> Add new gateway

            - Title: Enter in a description of the tunnel (I called it "sclara 

            - Gateway Hostname: The DNS hostname of the public/external Internet 
                                IP address (really should be an optional field 
                                here for Dynamic IP users)

            - Gateway IP: This is the public/external Internet IP address on
                          your network.  Dynamic IP address users will have to
                          update this from time to time as your IP changes

            - Update Password Checkbox: Leave this unchecked

            - Gateway Password:  The password for this specific AMPR gateway entry.
                                 This password should be UNIQUE from your primary
                                 portal.ampr.org password as this password will be
                                 required to be sent as CLEAR TEXT in an email if
                                 you wish to use the email robot method

            - Click on "Add" to create the initial gateway

            - You will then be prompted to enter in the AMPR IP address(s) given 
              to you by your AMPR IP Coordinator.  For me, I entered in:


              and clicked on "Add Subnet"

            - Again, click on "Add" in the middle of the page to create the final 
              gateway entry (little confusing eh?)

            - If you'd like to get an email when the gateways get updated (encap.txt)
              file, goto Gateways --> Options and enter in a password that you'd like
              the encap.txt file to be sent to.

              - To get a copy of the encap.txt file to get started with, go to 
                Gateways --> List and click on the "Download encap File" link

           DNS Entries:
            - Once upon a time, AMPR users could set their own DNS entries but this feature
              had issues and was removed.  To get DNS configured, you need to ask your AMPR 
              coordinator to do this for you.

            - Log into the portal and go to --> Networks and click on the links to drill
              down to your Country and Region.  

            - You should now see a list of all the other AMPR allocations in your region.
              At the very bottom of that listing should be a link for "requesting an allocation 
              from the parent network". 

            - In this new page, fill out the form for something like:

                 - Parent Network:   [leave this alone.. you can't edit it anyway]
                 - Netmask Requested: [ change this to the subnet size of your original network ]
                 - Description:       [ Put in "DNS change" ] here
                 - In the Accompanying notes, put in the details of what you want your DNS record 
                   to be.  For example:

                      Hostname: ki6zhd
                      Type:     A

              Click on "Send" to complete the request.  At that point, the request 
              will go to your AMPR IP Coordinator for approval.  Once approved, 
              you should be able edit these records yourself in the future.

5b. - Running an AMPR IPIP setup : How to get things running

Setting up an AMPR tunnel isn't too hard but it can be difficult to understand all
the routing policies it needs to create it's overlay network.  Here is my stripped 
down AMPR script that loads all the required kernel modules, installs initial routes, 
as well as turn on listener for the RIP44 protocol (similar to RIPv2 but different).  
This script can auto-started in your AMPR Linux system to bring up your AMPR tunnel 
every time:

   #Start up

   #Shut down

Other setup examples:

   #Startampr script

   #iproute2 munge script that processes the encaps file

   #Setup scripts for old Linux 2.2 kernels

   #Setup scripts For very old Linux 2.0 kernels
   modprobe ipip

| Legacy example:                                                               |
|                                                                               |
| Most people can ignore this old experimental test method to bring up an AMPR  |
| link with forwarding through an upstream firewall                             |

   #upstream Linux 2.0 firewall:
      - must apply ip_masq_vpn patch to 2.2.26 kernels
      - enable generic masq support as a MODULE (monolithic won't work)
      - configure monolithic kernel support for protocol 4

   #Forward IPIP traffic to internal host accepting AMPR traffic on protocol 4
   ./ipfwd --syslog --masq 4

   #AMPR station to reach to AMPRGW.UCSD.EDU for Internet access
   #  reflects new AMPR address range
   /sbin/ifconfig tunl0 netmask mtu 512 up
   /sbin/route add -net netmask tunl0 gw
   /sbin/route add -net netmask tunl0 gw

   #IPIP and AXIP VPN sync for AMPRGW.UCSD.EDU (new address)
   -A INPUT -p 4 -s -j ACCEPT
   -A INPUT -p 44 -s -j ACCEPT

   #Test route to known working AMPR station KG6BAJ
   /sbin/ip route replace via dev tunl0 proto static onlink table 1

   #Users may need a way to clear MASQ table

   #Impliment even better security

    Can we alter the /proc/net/ip_masquerade table directly?
    -->No, it is not feasible, because directly modifying masq entries will
          break the established connection table

   Other notes:

   With the later versions of ip_vs (2.4.x), the director has its own copies of the 
   tcpip timeout values, and you can change them. 

   Without a timeout values specific for each LVS virtual service and another timer 
   for the masqueraded connections, it is difficult to play such games. It seems only 
   one timeout needs to be separated, the TCP EST (established) timeout. The reason 
   that such support is not in 2.2 is because nobody wants to touch the user 
   space structures.  IMO, it can be added for 2.4 if there are enough free options 
   in ipvsadm but it also depends on some implementation details. 

6. - Software based TNCs for AX.25 packet on HF/VHF/UHF

   Back in the 1980s and 90s, amateur radio developers adapted the BELL 202 1200bps
   modem design for radio use.  To support this, external hardware TNCs where created
   such as TAPR TNC1/2, Kantronics KPC line, AEA PK232, etc.  These devices created an interface 
   to a radio to support the AX.25 packet protocol.  This was similar to the need for supporting 
   HF modes like RTTY, Amtor, etc) though these HF modes were actually simipler since they
   didn't have the AX.25 stack.  The great advancements in computer CPU performance has allowed the 
   ability to use an inexpensive soundcard to connect direct to a radio and use software to do 
   *all* TNC functionality internally.  In many respects, a lot of technology has come into
   amateur technology but not for packet radio.  This might be changing though with new modem
   designs that avoid using FM as a base modulation.  Check out David Rowetel's write up 
   on advancing past AFSK1200 at http://www.rowetel.com/?p=3799 .  It's a great read!
   Anyway, back on topic!

   One of the first software-TNCs for Linux was Thomas Sailer's "soundmodem" which 
   can support multiple simultaneous radios running at 300 / 1200 / 2400 / and 
   even 9600 baud.  Up until *very* recently, it was the only Linux option 
   around and though it worked pretty well for VHF, it didn't work well for
   HF.  Fortunately, things have changed and now there are options.

      HF Packet
      It's generally understood that Tom Sailer's stock soundmodem 300baud performance 
      on HF rather is POOR.   Some patches have been submitted to the linuxhams Vger 
      list to improve it but I personally didn't notice any real improvement.  Soundmodem does 
      work decently well on 1200bps VHF but it it's known to have limitations on decoding weaker 
      signals, doesn't decode mistuned remote TNCs very well, etc.  

      VHF Packet
      I've been doing various research on SoftTNC decoding for VHF packet and it 
      seems that Tom Sailer's soundmodem packet doesn't perform nearly as well as 
      some of these other solutions.  Some reasons include:

           - Single and multi-bit error correction
           - per-packet multi-pass flat and 6db/octave filtering
           - multiple off-frequency decoders
      There are several other soft-TNC solutions out there.  Here is a list of the ones
      I'm aware of:

         - DireWolf for Linux - RECOMMENDED - https://github.com/wb2osz/direwolf
             - Native ALSA application (no support for PortAudio) though compatible with
               PulseAudio's "default" device
             - Written in C and runs on Linux (x86 and ARM), Windows (x86), and Mac OSX
             - Originally designed to support 1200 baud packet but now supports 
               300BAUD AFSK for HF, 2400baud (PSK), 4800baud (QPSK), 9600 and 19200baud 
               (H3RUH) packet too
             - Supports open-squelch operation
             - Supports off frequency decodes via running multiple decoders (higher CPU load)
             - Supports 1bit and multi-bit recovery options for excellent weak signal decodes
             - Has an interesting design where it supports it's own fully featured AX.25 stack
               to natively support UI packets for APRS (RX/TX) while simultaneously supporting 
               AGW/PE API connections for full AX.25 connected sessions, low level KISS interfacing 
               say to the Linux kernel's AX.25 stack via a serial emulated connection and also 
             - TCP-KISS over TCP/IP support APRX, UI-Chat, and other program support
             - AGW/PE support for non-connected frames (APRS, etc)
             - Native IGATE support for relaying APRS packets to the Internet
             - Directly supports digipeating and beaconing directly, intended  
               for APRS use                                                    
             - Directly supports APRStt for sending APRS objects from any
               DTMF enabled radio
             - STDOUT display shows very helpful, color-coded live APRS decodes 
               including showing RX audio levels (great for tuning), 1bit/multi-bit
               recovery details, etc.
             - Supports GPS location via the gpsd packages

             * See in the back of the DireWolf UserGuide.pdf 
               where it has a benchmark table of various decode rates from different 
               software TNCs.  This includes showing Linux's Soundmodem poorer decode 
               rate.  Direwolf approaches 990 decoded packets from WA8LMF's Track 2 -
               http://wa8lmf.net/TNCtest/index.htm which is better than a Kantronics

         - dxlAPRS for Linux from OE5DXL - https://github.com/oe5hpm/dxlAPRS
             - A soundcard based TNC for operating 300bd up to 19200bd FSK and AFSK
             - decodes RS92 wx-sonde units
             - Stereo support and can run multiple baudrates parallel on the same sound/rf 
             - Includes APRS client and server elements with OpenStreetMap maps 
               more complex client/server arrangements
             - Supports an intelligent digipeater including iGating
             - Serial RMNC/KISS to UDP support
             - supports flexible UDP networks via AXUDP and other interfaces for 
             - native support for GPS
             - Originally Written in Modula-2 and posted code is translated to C

         - JavAX25 for all OSes - https://github.com/sivantoledo/javAX25      
             - Written in Java                                                 
             - Supports KISS and the AGW/PE API                                 
             - Supports double pass flat and 6db/octave filtering for high     
               percentage decodes                                              
             - Unclear on what DSP, off frequency decodes, etc. it supports.   
               I emailed the author but no response so far                     
             - Check out this QEX article about it:                            
               http://www.tau.ac.il/~stoledo/Bib/Pubs/QEX-JulAug-2012.pdf and  
               it's decode comparisons too                                     
             - Approaching 960 decoded packets from WA8LMF's Track 2 -         
             - See the QEX article on JavAX25 at                               

         - extmodem for Linux - http://extradio.sourceforge.net/extmodem.html
             - New entry as of 8/29/13
             - Based on JavAx25 (described above) and Multimon (from Thomas Sailer)
             - 1200 AFSK packet only
             - Directly supports AGW API so no need for AGW middleware like LDSPED                 
             - KISS over TCP for APRX support
             - more details coming

         - Soundmodem for Linux: - https://gitlab.com/tsailer/soundmodem
             - Different URL since GNU page seems to be gone
             - New version as of 5/4/15!  (seems to be compiler fixes only)
             - Mirror of old legacy site: http://soundmodem.vk4msl.yi.org/
                - Original site was at http://www.baycom.org/~tom/ham/soundmodem/   
             - Written in C and natively supports the ALSA sound system        
             - Supports KISS and supports connectivity into Linux's native     
               in-kernel ax.25 stack                                           
             - Supports multiple radios at the same time per soundcard
             - Supports two alternative modems including the Q15X25 mode (15   
               QPSK carriers)                                                  
             - Supports open-squelch operation
             - Been around a long time, works but generally recognized to      
               have poor decodes on 300BAUD packet and lower decode rates for    
               weak 1200BAUD signals
             - Other reports show decode rates approaching  450 decoded        
               packets from WA8LMF's Track 2 -                                 

         Windows Programs - some run under Wine
         - UZ7HO for Windows - http://uz7ho.org.ua/packetradio.htm             
             - Written in Delphi; no plans for a Linux port                    
             - Originally designed for 300BAUD HF packet to support frequency     
               hunting and multiple simultaneous off-frequency decoders -      
               later adapted to support VHF (FM) packet                        
             - Reported to run under WINE on Linux                             
             - Only supports the AGW/PE API in both Raw (layer2) and normal    
               API modes                                                       
             - No KISS support though there is the KB9VQF Serial LoopBack      
               Interface adapter at:                                           
             - Better than 990 decoded packets from WA8LMF's Track 2 -         
             - Well regarded in the Windows Winlink RMS Express crowd
         - AGW/PE for Windows - http://www.sv2agw.com/ham/agwpe.htm            
             - Not sure what it's written in, Windows only                     
             - Commercial and free versions available though the commercial    
               version is understood to be vastly more reliable, better        
               decodes, etc                                                    
             - Supports a full suite of diagnostic, user-land tools, etc       
             - Unknown numbers for the free and commercial packet decode       
               rates for WA8LMF's Track 2:                                     
         - Oscar Delta for AX.25 - http://ipoverax25.wordpress.com/            
             - Not sure what it's written in : Seems to be for Windows only    
             - Supports alternative modems like GMSK, QPSK, etc                
             - Unknown numbers for the packet decode rates for WA8LMF's        
               Track 2 at                                                      
             - Don't know much more about it right now, looks impressive    

         Other Alternatives for say Mac OSX, etc

         - There are several other modems that I've recently become aware of that 
           might help say Mac users or other systems that don't natively support AX.25, 
           Java (OSX), etc.  I have no experience with these projects but I'd love
           to hear from you about any comments

             - Direwolf for Mac (OSX support added in 1.3) - https://github.com/wb2osz/direwolf/releases

             - AX.25 in JavaScript - https://github.com/echicken/node-ax25

             - APRS / AX.25 in GO - https://godoc.org/github.com/dustin/go-aprs

             - More APRS / balloon - https://github.com/chrissnell/GoBalloon

             - TNC Mux - https://github.com/chrissnell/tnc-server

             - Various Libraries - https://libraries.io/go/github.com%2Fsamuel%2Fgo-dsp%2Fdsp

6.a - Soundcards for use with Software-tncs and HF Digital modes

Generally, any soundcard will work with Software-TNC programs (even your computer's built-in 
soundcard) but not all are equal.  Here are my thoughts on the topic:

C-Media based USB soundcard devices
Starting on the lowend, I've had decent luck with these generic $3 USB based soundcards using the 
C-Media CM108/CM109 chip on my Intel i5 laptop:

I've seen them come in transparent green, blue, grey (shown above) and black plastic enclosures.  
Some have buttons and others don't.  These show up as the following in the output from "dmesg" 
when you connect them to your computer's USB port:

   usb 2-1.1: new full-speed USB device number 14 using ehci-pci
   usb 2-1.1: New USB device found, idVendor=0d8c, idProduct=000e
   usb 2-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
   usb 2-1.1: Product: Generic USB Audio Device
   input: CM109 USB driver as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.3/input/input20

The ones with buttons are leveraging the GPIO pins built into the CM108 chip.  If you're looking to
use this the GPIO functionality vs. say a dedicated serial port now available, in Direwolf or Hamlib,
buy one of these for easier access.

The the price of these various units are fantastic but I've seen a few significant issues with some of
them.  Namely:

  - Some of these cheap units pour out a TON of RF on 144.0Mhz!!  Why?  Their native sampling 
    rate is 48k and if you take the 3rd harmonic (48Khz * 3 = 144.000Mhz)!!  Those the emissions 
    roll off pretty quickly as you back away from the device but that's NOT a great idea if you 
    want to use these units for 2m packet!  The better made units like the Syba ones include filter 
    networks consisting of some capacitors, etc. that greatly reduce this noise.
  - The various sound card audio levels for speaker, microphone, etc. are all generally supported 
    by Linux's soundcard mixering tools but the levels for some of these cheap cards have to be set 
    to extremely low settings like 1 or 2 out of 10 for proper audio levels.  That doesn't leave 
    much adjustment room for different radios and sometimes this can become very frustrating.

  - These inexepnsive unit are NOT already well supported on a Raspberry Pi while they work better
    on x86-based Linux computers.  This behavior can be seen when trying to use them with programs 
    like Direwolf.  The 1200baud packet tones can sound like a mess, etc.  It seems to be some sort
    of compatibility issue with the Rpi HW.  I beleive this situation has been improving as the 
    Raspbian OS (debian for Raspberry Pi) has matured from the Wheezy to Jessie, to now the Stretch 
    versions. I don't know if this problem also exists on other low-end hardware say like the 
    BeagleBoneBlack, CubieBoard, etc.

One inexpensive USB soundcard that I have had good luck with (reliable, minimal noise on 144.0Mhz, etc)
which is also recommended by programs like Direwolf on the Raspberry Pi is the Syba SD-CM-UAUD units 
using the C-Media CM119 chipset:

These units show up as the following in the output from "dmesg": usb 2-1.3.3: new full-speed USB device number 13 using ehci-pci usb 2-1.3.3: New USB device found, idVendor=0d8c, idProduct=0008 usb 2-1.3.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 2-1.3.3: Product: C-Media USB Audio Device input: C-Media USB Audio Device as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3.3/2-1.3.3:1.3/input/input19 These units also don't have the very low level mixer issues seen by the cheap CM-109 units. Complete pre-made solutions: ---------------------------- Without Isolation Transformers: ------------------------------- Moving up the quality on sound devices is using something like one of the Syba souncards connected to audio and PTT isolation circuits. These kind of devices include everything needed to get your system working but they don't offer other fancy things like isolation transformers, lots of LED indicators, etc. They are usually marketed towards Echolink or Allstar users RoIP users, are quite simple and small yet are very effective. They are usually ideal for VHF/UHF communications where you DON'T want isolation transformers. With Isolation Transformers: ---------------------------- Solutions like these are more commonly found on more expensive units like Signalinks, Timewave Navigators, etc. The addition of these transformers can improve the audio, remove hum, RFI induced issues, etc. One good example is the inexpensive EasyDigi kit:


Available as both kits ($10), fully built units ($20), and ones with cables for your specifc
radio ($30).

NOTE:  It's *very* important to to know that if you are looking to run higher speed data modes
       like Direwolf 4800bps or 9600bps packet, many of these isoloation transformers with the
       classic metal core with visable windings will *block* the full signal.  This means digital
       modes like G3RUH 9600bps FSK packet, VARA WIDE, etc won't work.  If you replace the older
       transforms with much higher quality ones once found in 56k dialup modems or other modern
       offerings, they should work fine.


Moving up, then there are inexpensive solutions that include the sound chip built into the 
solution for a more complete product.  In some respects, I recommend these type devices MORE
than a Signalink or other Auto-PTT solutions as you can better control the delays between the 
rig key up (PTT) and the audio signal playing.  You can read more about those problems and 
solutions here:

   Section - Page 73

There are many examples such as:

   $60 - Digimode 3 - http:/www.xggcomms.com
          - No isolation transformers
          - Includes extension cables

   $45 - DINAH - https://hamprojects.info/dinah/
          - No isolation transformers
          - very small and compact, metal case


Now moving into the more commercial solutions are sound devices that are typically better built.
These devices typically use better soundcard DAC chips (Burr-Brown) and also have full audio 
isolation built-in as well as have directly accessible knobs for audio adjustments.  The other 
key benefit of devices like the Signalink is that they have a direct PTT or Auto-PTT circuit 
that gets activated when the soundcard begins to play anything.  This avoids the need for a 
dedicated serial port or GPIO pin to key up your radio.  These units are usually not too 
expensive at ~$100 but for 1200baud packet/APRS use,

It's worth noting that some of these Auto-PTT like solutions create timing issues (read the
Direwolf URL above why).  Many people love these very universal units but I generally recommend
to stay away from them and buy the next level up if you can afford them:

   MFJ 1204MD6 w/ cable: $100

   Signalink w/ isolation transformers and cable: $105
   - Signalinks are very popular with a lot of HAMs as they are flexiable and relatively 
     plug-and-play.  With that said, they aren't great performers and cheaper solutions
     often out perform them.  For users looking for running higher speed modes like ODFM
     3Khz+ or wider data modes, older Signalink hardware have known passband limitations
     with their isolation transformers but the newest revision being sold DO have newer
     transformers that do pass wide modes like G3RUG 9600bps FSK and VARA Wide.  Check
     out pages like :
     to see how to improve various generations of Signalink units if you already have one.

   $105 - Hamstir DX - https://www.ebay.com/itm/Ham-Radio-Interface-for-FT8-JT65-PSK31-Echolink-RTTY-SSTV-HAMSTIR-ST/153236520171

RigBlaster Advantage, AEA, Navigator, MicroHAM, etc
Finally on the highend, there are USB soundcards like the RigBlaster 
Advantage, Timewave Navigator (was US Interface Navigator) and the MicroHAM II 
units.  They include better DACs such as the RigBlaster Advantage using the ADI 
AD1882 DAC and the Navigator and uses a Brown-Burr DAC.  Other benefits include:

   - DUAL radio inputs (dual receivers)
   - Native FSK data transmission for classive RTTY, Packet and CW
   - built-in CW Winkeyer support
   - Dedicated PTT circuit
   - Additional serial ports and/or CI-V interfaces for CAT rig control
   - Built-in speaker for monitoring your output signal

Examples include:

   Yaesu SCU-17 - $180

   Rigexpert WTI-1 - $180

   Rigblaster Advantage w/ cables - $230

   RigExpert TI-8 - $220

   RigExpert TI-5000 w/ cables - $250

   MicroHam III w/ cables - $260

   MicroHam MicroKeyer II - $429

   Timewave Navigator w/ cable - $450

I personally have a Timewave / US Interface Navigator for my HF setup and both really like 
and recommend it.  These units aren't cheap but I did notice a RX quality improvement 
with the better design, DAC selection, etc.  but I personally don't use it's dual
receive support, etc.

It's up to you.

6.b - Compiling Direwolf

[ Recommended SoftTNC ]

Read the above "Software based TNCs for AX.25 packet on HF/VHF/UHF" section to 
understand what Direwolf supports and how it's superior to most other softtnc
programs out there.

As of 10/28/20, Direwolf is at version 1.6 (final release version) and is available at 


specifically download it at:


For those of you interested in the Raspberry Pi version, check out the following
URL for specific Raspberry Pi documentation for Direwolf:


For those of you looking to possibly run bleeding edge Direwolf code, it's worth
mentioning WB2OSZ's release methodology:

   - Whenever you pull code from the Git MASTER branch, it will always be the 
     current "production" version of Direwolf.  Today, that's version 1.6DEV

   - BETA releases will also be posted in the MASTER branch but you will need to 
     use GIT tags to get the specific version of Beta

   - The DEV branch is where the bleeding edge version of Direwolf code can be found

Ok.. understand the different areas of source?  Good!

  If you want Direwolf to support native GPS location for tracker support.  If 
  you want this, please jump to that section to build and install gpsd and it's 
  libraries FIRST and then continue on here.

Let's get started in installing Direwolf 1.6:

  # Download the source and the required patch
  cd /usr/src/redhat/SOURCES
  wget -O direwolf-1.6.tar.gz https://github.com/wb2osz/direwolf/archive/1.6.tar.gz
  wget -O direwolf-1.6release-makefile.patch http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/direwolf-1.6release-makefile.patch

  cd /usr/src/redhat/SPECS
  wget -O direwolf-1.6Rel.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/direwolf-1.6Rel.spec

  #Now build and install it
  rpmbuild -bb --target=x86_64 direwolf-1.6Rel.spec
  sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/direwolf-1.6-1.el6.x86_64.rpm

Ok, your set!  Now to configure Direwolf.

6.c - Configuring and Tuning Direwolf

If you used my DireWolf SPEC file, your direwolf.conf file is in /etc/ax25/direwolf.conf.
The default location is to go into the directory of the user running direwolf but since 
I plan to run this as a system process, I want it in a central location.

[from my Rpi v2 documentation]

 - To configure Direwolf, edit the /etc/ax25/direwolf.conf file and set the
   following parameters for your specific needs.  For additional parameters,
   please read the Direwolf User-Guide.PDF for more details found in

      change the sound card line to match your correct sound card as shown in "aplay -l" and
      if looking to deal with multiple devices, see:

              # ADEVICE  plughw:1,0
              ADEVICE  plughw:1,0

      change the line:
              MYCALL N0CALL
              MYCALL [enter in your callsign here with SSID - I'm using KI6ZHD-6]

      change the line to match your desired RF baud radio, modem mode, and sampling divisor
             MODEM 1200
             MODEM 1200 E+ /3

      change the line for your chosen method of PTT (direct serial port, hamlib support, etc)
             #/dev/ttyUSB0 RTS
             /dev/ttyUSB0 RTS
      Under the "PTT" or "DCD" GPIO line, add the following parameters.  These
      settings depend on the key-up and key-down speed of your radio.  A setting
      of 30 means 300ms which is pretty conservative.  You ideally want these to
      be as fast as possible.

        NOTE: If the TXTAIL setting is too short, I've seen where an AX.25
              connection cannot gracefully disconnect via issuing the "b" command.
              I had to change the TXTAIL variable from 10 to 50 to get things
              to work properly

             TXDELAY 30
             TXTAIL 50

        NOTE #2: The tuning of TXDELAY is a complicated subject and is better
                 explained here:  


            This excellent "Setting Your TNC's Audio Drive Level Why it's important, and how to do it..." 
            by John Ackermann N8UR helps you understand WHATS going on and WHY 
            and it applies to all TNCs be it softtncs or hardware TNCs.

                 Please also consider to NOT make your timing overly conservative like say 500ms 
                 just to be safe.  It's terribly slow and that long turnaround delays both hurts
                 your packet throughput but also impacts the performance of the entire packet
                 network on that shared frequency.  

                 For example, on a perfectly timed packet system (all nodes in your receivable range), 
                 you need to adjust your AX25 stack to never transmit before your radio is ready to 
                 send the audio (not chop off any of the preamble bits) and is also transmitting at 
                 full power. Most quality HAM grade radios seem to do this around 150-250ms and cheaper 
                 radios do it around 250-450ms.  HAM grade *data* radios like the TEKK or even the MFJ 
                 5 watt data radios offered performance like 5-20ms.  That's a BIG difference in TXDELAY
                 latency!  The next problem is you also have to tailor your TXDELAY to accommodate the 
                 slowest nearby radio on it's TX->RX delay to be ready to receive your packet.  This is 
                 harder to do as you don't know what those remote radio's performance parameters are.  
                 I've found 200ms of total TXDELAY is pretty safe when using a quality HAM grade radio 
                 but you have to test it against your nearby upstream NODES to ensure they aren't slower 
                 than that (seen as lots of retries from your transmitting station)..  As you can imagine, 
                 200ms is FAR slower than a a fancy 20ms data grade radio and thus it's a WASTE to use these
                 fast radios if your nearby packet nodes are using long delay radios.  This is very common
                 on most 1200BAUD AFSK networks today but less of a problem on the limited 9600BAUD FSK 
                 networks (if you can find them).

                 Just a FYI, back in the early 1990s, many packet radio networks used "LANs" which were 
                 essentially dual networks per TNC/BBS installation.  This is where fast data radios were 
                 used to backhaul system traffic on one frequency and slow HAM grade radios on a different 
                 frequency was used for user access.  Few systems like this exist anymore so you have to 
                 find this compromised timing to support everything on one frequency.

      Unless you plan on using the TCP KISS (not the same as "serial KISS")
      feature or the AGW/PE API support for connected AX.25 sessions for things like Outpost, etc 
      (added in Direwolf 1.4)), plan on disabling both of these:

      change the line (for my specifically chosen GPIO pin):
             AGWPORT 8000
             KISSPORT 8001
             AGWPORT 0
             KISSPORT 0
      Depending on your use of your packet station, you might want to tune the
      FIX_BITS section to be either APRS centric or standard packet centric.

      FIX_BITS 1 AX25

9. Test out Direwolf in it's stand alone more and enable all it's settings to better
   tune it's levels

      #Other options you might be interested in
      #-q d : suppress APRS decodes
      #-q h : suppress heard levels
      #-t 0 : disable colors
      #-d o : show output for asserting DCD and PTT lines
      #-a n : print out number of samples for N sections
      direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf

    HINT:  If you started Direwolf with it's coloring enabled and now all your
           console text is blinking, you can use the command "tput reset" to
           clear things out.

  When Direwolf is running, there are two key things to monitor

    1. The sampling rate matches the configured rate.  If it deviates beyond the
       expected rate too much, things won't work at all.

          ADEVICE0: Sample rate approx. 44.1 k, 0 errors, receive audio level CH0 92

    2. Direwolf reported audio levels is roughly around a level of 50 on average
       for various heard remote stations

         K6FB-1 audio level = 57(26/14)   [NONE]   ___||||||

6.d - Tuning Direwolf Audio levels

The setting of the soundcard audio levels (deviation level) are critical for proper
operation.   The jist of all this is to get the audio levels IN from the radio to the 
soundcard to show up in Direwolf at an average level of 50.  The audio OUT of the 
soundcard into the radio needs to be set that it doesn't overdrive (over-deviate) 
on RF side but also not be too low.

There is an excellent write up at http://www.febo.com/packet/layer-one/transmit.html

   " Setting Your TNC's Audio Drive Level Why it's important, and how to do it..." by
   John Ackermann N8UR but below are notes are specific to Direwolf setup.   This
   approach also applies to classic hardware TNC setups as well!  If you're not 
   interested in the background details, jump to the "no-Test-Equipment packet adjustment 
   system" section to learn how to tune your radio's levels to be pretty close to perfect.

If you want a more precise tuning, there is a more scientific way of doing this if you have 
another computer and an inexpensive RTL SDR dongle.  I haven't tried this method out yet 
but it might be a great excuse to try out Andy's HAM Radio ISO on a bootable pen-drive:


Please also remember that the adjusting these audio levels is a a combination of the levels 
coming in/out of your radio as well as the soundcard levels so you need to adjust for both 
sides if they are adjustable.

As an example, here is an example tuning using a Kenwood TH-F6A hand held radio:

Turn ON your radio

     - On this radio, the bottom most Volume knob has one notch that's bigger than the others

Different sound Card mixer tools:
  There are several sound card mixer programs for Linux you can use to set both
  the RX and TX levels of your soundcard.  Each of the programs have their
  own merits:

        alsamixer (RECOMMENDED - ncurses tool) 
          - Alsamixer is a NCURSES CLI-based tool that works every time
            and gives numbers to note down what the difference levels are.
            It's installed as part of the alsa-utils RPM and can run
            anywhere (no Xwindows required).

        aumix (kmix doesn't give any level numbers)
          - aumix is a very nice Xwindows based mixer application but
            it's somewhat old, not very common anymore, and requires

        kmixer (kmix doesn't give any numbers)
          - Me being a KDE guy, this mixer is installed by default and
            works very well.  The problem with it is that it doesn't
            show numbers for the level settings but just sliders shown
            against very fine hash marks.  This makes re-setting levels

   - Here are the settings used on my Kenwood TH-F6A levels using the "alsamixer" NCURSES-based 

      - NOTE: Only use the soundcard channel required to drive your radio
              99% of all amateur radios use a MONO output from your sound device to
              the radio.  As such, it's recommended to set the correct "TX" level 
              on only the required output channel and configure the ALSA mixer to make 
              the OTHER channel muted (set to 0).  This helps avoid interference issues 
              where the system can actually hear itself
            Playback: (this is the soundcard OUTPUT going to the Radio for TX) 
                - Use TAB to get to the proper sound device
                - use "M" to mute or un-mute

            --- alsamixer -------- aumix------------------------------------
                Master            : 00       -- green 00 (allow output)
                Master Mono       : 74       -- green 00
                headphone         : 45       -- green 00 (pskmeter likes 59)
                3D control center : 0        -- 0
                3D control depth  : 0        -- 0
                3D control        : MM       -- (monitor muted)
                PCM               : 71       -- green 00
                PCM Out           : pre 3D
                Line              : MM       -- (monitor muted)
                CD                : MM       -- (monitor muted)
                Mic               : MM       -- (monitor muted)
                Mic Boost         : MM       -- (monitor muted)
                Mic Sel           : Mic1     -- 
                Video             : MM       -- 0
                Phone             : MM       -- 0
                IEC958            : MM       -- 
                IEC958 playback   :          -- 0
                AUX               : MM       -- 0 - NOT green
                Mono Out          : Mix      -- i
                Beep              : MM       -- 0 - NOT green
                External Amp      : MM       -- 
                balance           : Vol Bal  -- 50

            Capture: (this is the soundcard INPUT coming into the computer for RX)
                (RED means input is enabled) 
                - Use TAB to get to it
                - use "M" to mute or un-mute

            ---- alsamixer ------- aumix------------------------------------
                3D Control center : 0        --  0 - RED
                3D Control depth  : none     --  0 - RED
                line              : line     --  0 - not RED : not green
                CD                : CD       --  0 - not RED : not green
                Mic               : Capture  --  0 - RED : not GREEN
                                                 *(yes, you want a level of 0)
                Video             : Video    --  0 - not RED : not green
                Phone             : PhoneIn  --  0 - not RED : not green
                EC958 playback    : none     --  0 - RED
                Aux               : Line1    --  0 - not RED : not green
                Capture           : Capture  --  0 - RED : not green
                Mix               : none     --  0 - 
                Mix Mono          : none     --  0 - 


   Saving and restoring your levels:
   Once you have the sound levels where you want them, the way to SAVE these settings
   for all your various soundcard settings is to use the command:
        /sbin/alsactl save

   If at any time you want to revert to your previous saved levels, run the command:

        /sbin/alsactl restore

Anyway, now you need to configure up the Linux AX.25 stack.  Go ahead and skip to section 8
to get started.

6.e. - Thoughts on running higher speed packet than say 9600bps

Running AX.25 packet radio faster than 1200bps speeds starts to make things difficult.  Part 
of the reason why packet radio seems "stuck" on the 1200bps speed is because the 1200bps AFSK 
based modems are simple, compatible with any FM radio, generally work with any antenna 
configuration, and their operation is pretty robust.  Faster TNCs supporting the 2400bps PSK
modems are/were fairly rare from the likes of MFJ and AEA's TNC2 addon boards but they were still 
generally simple to setup.  Both Direwolf and UZ7HO's Soundmodem have recently added 2400bps 
modems to be both V.26 4-phase PSK compatible (0, 90, 180, 270 phase shifts) and Direwolf has added 
MFJ/AEA TNC compatibility (45, 135, 225, 315 phase shifts). 

Faster speeds than than 1200bps generally need non-preemphasized audio and require a wider 
"audio" passband.  To get this, the need for "9600bps-ready" radio is generally required.  These 
radios generally remove the pre/post audio emphasis processing and also directly communicate to 
the radio's discriminator for transmission of signals.  Direwolf's 8-phase V.27 4800bps modem is a 
fairly robust modem but it starts to experience drop packets when the received signal isn't full 
quieting.  You can read more about the 2400 and 4800bps modems in Direwolf's 
2400-4800-PSK-for-APRS-Packet-Radio.pdf document.

The next major jump in speed is to use the classic G3RUH 9600bps FSK modem.  This modem sounds like 
"pronounced static/ digital hash" and really requires a full quieting signal to be reliable.  Unless 
your station has a clear line of sight path to the remote station, 9600bps G3RUH packet might be 
frustrating to operate.  When it works, this modem is night and day faster than a 1200bps AFSK 
packet.  Direwolf's 9600bps support with it's multi-bit CRC correction can make this mode a lot more
reliable but it's generally *REQUIRED* that you use a directional antennas to maximized the signal 
to noise ratio (SNR) as high as possible.

To go faster than 9600bps, things start becoming a lot more complicated.  Not only do you need a 
wider RF passband than say 25Khz but FM or PM-only radios start to limit the performance of the setup.  
Specifically, most FM-only radios have a TXDELAY or "delay from PTT until stable" time of about 120ms.  
This kind of delay isn't too bad for say the 1200bps mode but it's terrible for 9600.  You can read 
more about these issues in Direwolf's two documents:


Another interesting document to read is the following URL that talks to other specific limitations
of FM-only radios:


That URL states that if you use a multi-mode radio that supports SSB in addition to FM, you should
be able to get much better TXDELAY times.  It would be ideal if everyone used "data grade" radios
which can bring this time down to say 20ms but those are pretty rare these days from amateur radio
vendors.  The only radios I'm aware of are say the TEKK KS-900 and the MFJ-8621 (still available).

6.f. - Soundmodem - Compiling, Configuring, and tuning (LEGACY)

  | NOT recommended: I now recommend to use Direwolf for all software based TNC uses |
  |                                                                                  |
  |     This section is here for posterity reasons only as it was a great program in |
  |     it's day.  Seriously, don't use soundmodem anymore.  It has many known       |
  |     issues and it's performance isn't very good compared to direwolf             |

Thomas Sailer's Soundmodem has been a long standing offering that brought packet radio to
soundcards on Linux.  Unfortunately, it has not been modernized in years and recent 
alternatives have surpassed it in terms of decoding performance, flexibility, etc.
Please see the top of this section for better alternatives such as Direwolf.

| If you still want to use Soundmodem vs. the alternatives, read on |
|                                                                   |
|  NOTE:  The last version of soundmodem is actually v0.20          |

The soundmodem version in the Fedora SRPM is very old and the sources must be 
replaced!  Unfortunately, the SPEC file included in the main sources at 
http://www.baycom.org/~tom/ham/soundmodem/ is also broken so we're going to
need to stitch the two SPEC files together.  

   Get the soundmodem sources here:

      cd /usr/src/redhat/SOURCES
      wget -O soundmodem-0.18.tar.gz \

      # was http://gnu.org/projects/soundmodem was http://www.baycom.org/~tom/ham/soundmodem/soundmodem-0.18.tar.gz

   Next, you'll want two specific patch files:

      #A fix to improve packet operation on modern machines with PulseAudio, ALSA, etc
      wget -O soundmodem-0.16-use-a-minimum-samplerate-for-afsk-v5.diff \

      # A fix to disable DCD from asserting the DTR line on some soundcard systems 
      # as mentioned on the linux-hams list on Aug 15, 2005
      # subject:  Re: soundmodem activates PTT on DCD
      #    http://www.spinics.net/lists/linux-hams/msg00389.html
      wget -O soundmodem-disable-dcd.diff \

   Get the SPEC file:

      I *highly* recommend you save yourself the work of merging the two SPEC files 
      and enabling all the various patch files by using my TrinityOS SRPM here and 
      everything is ready to go:

      cd /usr/src/redhat/SPECS
      wget -O soundmodem.spec \

      Skip all the manual work and go to the next section to compile the RPM
     If you want to do all the work manually, get the SRPM here:

      cd /usr/src/redhat/SRPMS
      wget -O soundmodem-0.12-1.fc9.src.rpm \

   Now install the SRPM with

      rpm -ivh /usr/src/redhat/SRPMS/soundmodem-0.12-1.fc9.src.rpm

   You can download the updated SPEC here:


     | For 32bit systems only - see section 1 for compile time optimizations |
     |                          for optimizations on 64bit systems           |

        edit the soundmodem spec file yourself and update the version to 0.16

       - In the %configure section, add:
                      ./configure --enable-mmx 

       | NOTE: 64bit systems                                               |
       |                                                                   |
       |     The use of --enable-mmx is NOT valid on x86_64 systems and    |
       |        if you try to use it, you'll get compile errors including: |
       |                                                                   |
       |        simd.c:64: Error: suffix or operands invalid for `pushf'   |
       |        simd.c:65: Error: suffix or operands invalid for `pop'     |
       |        simd.c:68: Error: suffix or operands invalid for `push'    |
       |        simd.c:69: Error: suffix or operands invalid for `popf'    |
       |        simd.c:70: Error: suffix or operands invalid for `pushf'   |
       |        simd.c:71: Error: suffix or operands invalid for `pop      |
       |                                                                   |
       |    from what I can tell, should no longer give you any            |
       |    major performance improvements as the newest compilers should  |
       |    make the best choice of optimizations                          |

       - In the changelog section, add a note on the new version

   | HEADS Up:  If you plan on using Soundmodem on 300Baud HF, there was |
   |            an initial patch posted from IZ6RDB to the               |
   |            linux-hams@vger.kernel.org list on 3/2/2012 and later on |
   |            2/5/16 which supposedly significantly improves 300 BAUD  |
   |            operations.  Please see http://iz6rdb.trentalancia.net/  |
   |            or my above soundmodem.spec file and where to download   |
   |            the patch from.                                          |

Compiling Soundmodem: 
   Soundmodem requires the following RPMs to be installed first before you
   can compile it up.

        #yum install gtk2-devel
            NOTE: will install 14 other RPMs if not already installed

        #yum install alsa-lib-devel 
            NOTE: will install without any other RPMS

        #yum install audiofile-devel 
            NOTE: will install without any other RPMS

   Now compile it:
        cd /usr/src/redhat/SPECS

        #for 64bit systems
        rpmbuild -bb --target=x86_64 soundmodem.spec

        #For 32bit systems
        rpmbuild -bb --target=i686 soundmodem.spec
     and install it:

        #For 64bit systems
        rpm -ivh /usr/src/redhat/RPMS/x86_64/soundmodem-0.18-1.el6.x86_64.rpm \

        #For 32bit systems
        rpm -ivh /usr/src/redhat/RPMS/i686/soundmodem-0.18-1.i686.rpm

To test your kernel for AX25 support, you have to install the ax25 
kernel module.  Follow the "Getting Basic Packet up and running"
section above on how to do that

6.g. - Soundmodem - Configuring the soundcard based TNC

  | NOT recommended: Use Direwolf                       |
  |                                                     |
  |     This section is here for posterity reasons only |
  |     and reflects the older Centos5 setup            |

  - Start up the radio
    In this example, I'm using the laptop's built-in soundcard with Linux's
    "soundmodem" soft-TNC to a Kenwood TH-F6A HT.  To control PTT, I wired up 
    a PTT circuit as recommended from one of my elmers:

        http://www.dunmire.org/projects/DigitalCommCenter/index.html -->lTT

      - Additional serial troubleshooting tools can be found in the Serial
        troubleshooting chapter

  - Tune the radio to a known active packet frequency.  For
     example, 144.910

  - Make sure you set the squelch properly so an idle frequency isn't 
    "busy".  Unless this is properly set, you'll never transmit!

  - edit the /etc/ax25/axports

      #device-name callsign speed paclen window description
      f6a KI6ZHD 9600 128 2 Kenwood D710 TNC

    | Three Very Important Notes:                                                  |
    | ---------------------------                                                  |
    | 1. Every callsign+SSID in the axports file MUST be unique and refer to a     |
    |    unique userspace device like "f6a", "d710" , etc.                         |
    |                                                                              |
    | 2. Though very subtle, the specific "KI6ZHD" callsign and SSID (no SSID      |
    |    specified means -0) used here does the correlation of connecting the      |
    |    soundmodem "sm0" ax.25 device to the userspace axports device "f6a".      |
    |    You as a user will NEVER use the "sm0" device directly.. you use "f6a"    |
    |                                                                              |
    | 3. In an older version of this doc, I set the device name in the axports     |
    |    file as "sm0" which was identical to the device name in the               |
    |    soundmodemconfig setup.  Though this technically works, it's very         |
    |    confusing to the operator and shouldn't be done.  The userspace device    |
    |    name in axports should be UNIQUE.                                         |

  - #Load the AX25 kernel module
    modprobe -a ax25

- Next, run the command "aplay -l" to list all of your soundcard devices.  Make 
  a mental note of "card" number for the soundcard connected to the radio that
  you want soundmodem to control

- run the program "soundmodemconfig" and follow the prompting but making changes 
  when required for your specific setup (sound card device, PTT serial port, etc):

  - File --> New Config --> name it something.. I called mine "1200 packet"

  - Now do File --> New Channel

    "1200 packet"
     |   |
  -  |   +--IO tab
     |   |  |
     |   |  +-- Mode: Soundcard           (I needed "alsa")
     |   |  +-- Audio Driver: /dev/dsp    (I needed plughw:0,0)
     |   |  +-- Half Duplex: NOT set      (set this unless you have TWO antennas)
     |   |  |                              or are running SPLIT
     |   |  +-- Capture channel: Mono                             
     |   |  +-- PTTY driver: /dev/ttyS0
     |   |  +-- Hamlib model: <empty>   (used for CAT-based rig control)
     |   |  +-- rig configuration params: <empty> (hamlib specific parameters)
     |   |
     |   +--Channel Access tab
     |      |
     |      +-- Tx delay:  400        (qbjnet has 300)
     |      +-- Slot time: 100        (qbjnet has 100)
     |      +-- P-Persistence: 40     (qbjnet has 64)
     |      +-- P-Persistence: 40     (qbjnet has 64)
     |      +-- Full Duplex: disabled (qbjnet has disabled)
     |      +-- TX Tail: 10           (qbjnet has 40)
     +--Channel 0
        +-- Modulator: off [default]  (qbjnet has afsk)
        |   |
        |   +-- bits/s: 1200                 <----- For 1200 baud packet : for 300baud set to 300 and
        |   +-- frequency 0: 1200                                                   900
        |   +-- frequency 1: 2200                                                  1100
        |   +-- Differential encoding: ENABLED
        +-- Demodulator: off
        |   |
        |   +-- bits/s: 1200                 <----- For 1200 baud packet : for 300baud set to 300 and
        |   +-- frequency 0: 1200                                                   900 
        |   +-- frequency 1: 2200                                                  1100
        |   +-- Differential encoding: ENABLED
        +-- Packet IO
            +-- Mode: MKISS          <------- If I set this to KISS, the CPU
            |                                 load for soundmodem would go to
            |                                 100%
            +-- Interface Name: sm0
            +-- Callsign: N0CALL-8   <------- replace with your callsign
            +-- IP address: <------- change with your allocated AMPR IP
            +-- Network Mask                  Can be anything really but please
            +-- Broadcast          see the AMPR section in this doc
                                              for more details
   Be sure to goto File --> Quit  you you'll loose your settings.

  | 300 BAUD Operation:                                                             |
  | -------------------                                                             |
  |   As mentioned in the SPEC file for 300 baud patch, there is another limitation |
  |   with soundmodem and HF packet.  Specifically, at low bit rates, soundmodem    |
  |   has a limitation of lower tone pairs:                                         |
  |                                                                                 |
  |           http://www.spinics.net/lists/linux-hams/msg02615.html                 |
  |                                                                                 |
  |   As such, it's recommended to set the f0 and f1 tones to 900hz and 1100hz      |
  |   in soundmodem's config.  Please see the following excellent read for more     |
  |   details:   http://wiki.complete.org/LinuxPacketRadio#soundmodem               |

6.h - Soundmodem - Setting the right audio levels

  | NOT recommended: Use Direwolf                       |
  |                                                     |
  |     This section is here for posterity reasons only |
   | To be updated for Centos6 with PulseAudio |
   Deviation Level tuning for Centos5 using ALSA
   There is an excellent write up at http://www.febo.com/packet/layer-one/transmit.html
   " Setting Your TNC's Audio Drive Level Why it's important, and how to do it..." by
   John Ackermann N8UR but below are notes for my specific Soundmodem setup but this
   also applies to classic hardware TNC setups as well:

     NOTE: In this section, "New Setting" settings reflects a newer Dell laptop 
           vs.  "Old Setting" settings reflects an different, older Dell laptop.  
           These two different configurations have been kept to show users how both
           different levels, pre-amp options, etc. can be depending on the computer 
           / soundcard being used!

     NOTE2: See the above Direwolf section for more audio level tuning recommendations

   Turn ON the radio (in this example, a Kenwood TH-F6A HT):
     - On this radio, the bottom most Volume knob has one notch that's bigger than the others

        New setting: Move it to point at the icon between the words
                     ENC and VOL (for my specific setup)

        Old setting: Move it to the 10 O'clock mark (pointing right at 
                     the apex of the bend for the battery clip)

   Different sound Card mixer tools:
     There are several Sound card mixer programs you can use to set the RX and
     TX levels on your various soundcards and each of the programs have their
     own merits:

        alsamixer (ncurses tool)              -- 07/01/11
          - Alsamixer is a NCURSES CLI-based tool that works every time
            and gives numbers to note down what the difference levels are.
            It's installed as part of the alsa-utils RPM and can run

        aumix (kmix doesn't give any numbers) -- 11/15/09
          - aumix is a very nice Xwindows based mixer application but
            since it's somewhat old, it's not very common anymore

        kmixer (kmix doesn't give any numbers)
          - Being a KDE guy, this mixer is installed by default and
            works very well.  The problem with it is that it doesn't
            show numbers for the level settings but just sliders shown
            against very fine hash marks.  This makes re-setting levels

            Running the following should restore the Mixer settings:

                   /sbin/alsactl restore

            Just to confirm your settings:

   Settings used on my personal (New) Dell Latitude using the "alsamixer"
   NCURSES-based interface
            Playback: (new) 
                - Use TAB to get to the proper sound device
                - use "M" to mute or un-mute
            --- alsamixer -------- aumix------------------------------------
                Master            : 00       -- green 00 (allow output)
                Master Mono       : 74       -- green 00
                headphone         : 45       -- green 00 (pskmeter likes 59)
                3D control center : 0        -- 0
                3D control depth  : 0        -- 0
                3D control        : MM       -- (monitor muted)
                PCM               : 71       -- green 00
                PCM Out           : pre 3D
                Line              : MM       -- (monitor muted)
                CD                : MM       -- (monitor muted)
                Mic               : MM       -- (monitor muted)
                Mic Boost         : MM       -- (monitor muted)
                Mic Sel           : Mic1     -- 
                Video             : MM       -- 0
                Phone             : MM       -- 0
                IEC958            : MM       -- 
                IEC958 playback   :          -- 0
                AUX               : MM       -- 0 - NOT green
                Mono Out          : Mix      -- i
                Beep              : MM       -- 0 - NOT green
                External Amp      : MM       -- 
                balance           : Vol Bal  --  50

            Capture: (new) (RED means input is enabled) 
                - Use TAB to get to it
                - use "M" to mute or un-mute
            ---- alsamixer ------- aumix------------------------------------
                3D Control center : 0        --  0 - RED
                3D Control depth  : none     --  0 - RED
                line              : line     --  0 - not RED : not green
                CD                : CD       --  0 - not RED : not green
                Mic               : Capture  --  0 - RED : not GREEN
                                                 *(yes, you want a level of 0)
                Video             : Video    --  0 - not RED : not green
                Phone             : PhoneIn  --  0 - not RED : not green
                EC958 playback    : none     --  0 - RED
                Aux               : Line1    --  0 - not RED : not green
                Capture           : Capture  --  0 - RED : not green
                Mix               : none     --  0 - 
                Mix Mono          : none     --  0 - 


            output (older)
            ----Kmix ------------- aumix------------------------------------
                Master            : vol      -- 68 - green (allow output)
                Master Mono       : phoneOut -- 74 - green
                headphone         : PCM2     -- 45 - green (pskmeter likes 59)
                3D control center : none     --  0
                3D control depth  : none     --  0
                PCM               : PCM      -- 71 - green
                IEC958 playback   : none     --  0
                PC speaker        : none     --  0 - NOT green
                balance           : Vol Bal  --  50

            input: (old) (RED means input is enabled)
            ----Kmix ------------- aumix------------------------------------
                3D Control center : none     --  0 - RED
                3D Control depth  : none     --  0 - RED
                line              : line     --  0 - not RED : not green
                CD                : CD       --  0 - not RED : not green
                Mic               : MIC      --  0 - RED : not GREEN
                Video             : Video    --  0 - not RED : not green
                Phone             : PhoneIn  --  0 - not RED : not green
                EC958 playback    : none     --  0 - RED
                Aux               : Line1    --  0 - not RED : not green

            Kmix switches:
                3D Control - switch                - not yellow
                Mic Boost (+20db)                  - not yellow
                IEC958                             - not yellow
                Mix                                - not red
                Mix Mono                           - not red
                External Amplifier                  - not red
                PCM out path and mute              - pre 3D
                MIC select:                        - Mic1 (built-in mic)
                Mono Output Select:                - Mix
   OLD original -- Dell Latitude

      * NOTE:                                                              *
      *       Some mixer functions disable other configured features.  One *
      *       such feature is the "Switches: Mix Mono".  It's critical     *
      *       that this is RED for this specific soundcard!                *

            Running the following should restore the Mixer settings:

                   /sbin/alsactl restore

            Just to confirm your settings:

                master: 55%       green: (allow output)
                master mono: 1% - green
                3D control sigmatel depth: 0%   <-- critical
                PCM:  100% - green
                PC speaker: 0% - NOT green
                balance: -0- (middler)

            input: (RED means input is enabled)
                RED             ) - 3D Control sigmadel - Depth: 100%
                not red           - line    - 100% - GREEN
                not red           - CD      - 50% - not GREEN
                not red           - Mic     - 50% - not GREEN
                not red           - Video   - 50% - not GREEN
                not red           - Phone   - 50% - not GREEN
                not red           - Aux     - 50% - not GREEN
                RED               - Capture - 100% - not GREEN

          ----> 3D Control - switch                - YELLOW - if off, greatly lowers output
                                                             also makes output STEREO
                Mic Boost (+20db)                  - not yellow
                Mix                                - not red
  critical ---> Mix Mono                           - RED
                External Amplifier                  - not red (also activates Mix Mono)
                Sigmatel 4spkr stereo              - not red (also activates Mix Mono)
                Sigmatel surround phase inversion  - not red (also activates Mix Mono)

                      MIC select: Mic1 (built-in mic)
                      Mono Output Select: Mix

   Saving and restoring your levels:
   Once you have the sound levels where you want them, the way to SAVE these settings
   for all your various soundcard settings is to use the command:
        /sbin/alsactl save

   If at any time you want to revert to your previous saved levels, run the command:
        /sbin/alsactl restore

   Soundmodemconfig - Confirming you levels

   Time to tune soundmodem's input levels

   | NOTE#1:                                                                    |
   |          the soundmodemconfig tool is very prone to crashing and you might |
   |          need to restart it multiple times to get the seeings you need.    |
   |          I've also seen where it will NEVER successfully start on some     |
   |          Linux machines for unknown ALSA, video, whatever issues.          |

   NOTE#2: You CANNOT use soundmodemconfig's diagnostic program while the 
           soundmodem process is running.   Make sure soundmodem is NOT running
           when trying to use this tool

   run soundmodemconfig as root:

         - Soundmodem's graphics don't have any ticks or level outputs to
           confirm the input levels.  To work around this, get a ruler and
           some tape ready

         - highlight "channel 0" and in the menu bar, you'll now see diagnostics.

         - Select Spectrum Display, you should see a scope view with an X and Y axis.
           Move and tape the ruler to where the X axis is.  

           NOTE:  This process is VERY CPU intensive.  On my P3-500, it chokes but
                  me and another user are coming to the conclusion that these
                  diagnostic hangs might be due to ALSA issues and not a video 
                  card or CPU power limitation.  Still researching this one..

           NOTE2: When receiving a good enough packet and your radio keys up,
                  you are probably hitting a known DCD issue with some interface
                  cables.  See the Soundmodem troubleshooting section for ideas
                  on how to fix
           NOTE3: if soundmodemconfig updates for about 5 seconds and then stops 
                  on you, you are probably running an old version of soundmodem.
                  Upgrade your version of soundmodem or just don't worry about it.  
                  When finished with this stage, soundmodem will probably run fine 
                  for you.

           - So now that you have a ruler showing a level of 0, shutdown 
             soundmodemconfig, load it again and choose scope:

              --gt; the majority of the waveform peaks should not exceed
                  ~1/2" to 5/8" inches over the zero baseline.  Some peaks will
                  go over but that's ok

         - NOTE4: Now goto Soundmodem --> Diagnostics --> Modem. 
                  In this view, I have to click on and off "PTT" to get the
                  decoding to begin.  It's also unclear why the sounds from
                  the soundcard do NOT sound like the right 300B packet tones.
                  It's important here that when you hear strong enough packets
                  and the DCD indicator lights up, the radio doesn't start
                  to transmit right on top of it.  If so, please make sure
                  you applied the DCD disable patch as instructed above.
         - NOTE5:   look in the terminal window that's running the 
                    soundmodemconfig,  you should see decodes like:
                    Packet: fm K6KP-6 to QST-0 UI^ pid=CD
                    Packet: fm K6SNY-0 to BEACON-0 UI  pid=F0
                    K6SNY / K6SNY-1 at the Sunnyvale EOC

         - NOTE6:   It seems that soundmodemconfig's decodes seem to show
                    MORE decodes than what axlisten shows.  It could be 
                    that axlisten doesn't do all the same CRC checking.

                    This spectrum view is interesting to view and can 
                    be helpful in spotting remote TNCs that are improperly
                    configured to have higher deviated low frequency tone than 
                    than the higher frequency tone.

6.i - Soundmodem - Running the daemon with other AX.25 services for a functional system

  | NOT recommended: Use Direwolf                       |
  |                                                     |
  |     This section is here for posterity reasons only |

   Once Soundmodem is configured, let's manually start up the soundmodem process:

     #-R is for realtime scheduling, -M to not let it get swapped out
     #-v 5 is for extended logging
     /usr/sbin/soundmodem -RM -v5

             Now, I'm a KDE guy but if you ask anyone who's used KDE for a long 
             time, they will probably tell you about KDE's sound system "arts" 
             and how it's crap.  Well, being crap, it bit me here again.    So to 
             avoid my issue:

               - In the KDE control panel, goto Sound & MultiMedia -->

                   In here, there are two settings:

                   - Enable the network sound (maybe not)?
                   - set the autosuspend to 1 second

             If that doesn't help, you'll have to make sure you disable 
             ARTS from ever starting/running.

   If soundmodem starts, you'll see something like this:
   sm[6853]: mkiss: ifname sm0 mtu 256 hwaddr KI6ZHD-0 ipaddr netmask broadcast
   ALSA: Using sample rate 9600, sample format 2, significant bits 16, buffer
   size 4800, period size 144
   ALSA: Using sample rate 9600, sample format 2, significant bits 16, buffer
   size 4800, period size 144
   sm[6853]: audio: starting "plughw:0,0"
   sm[6853]: audio: forcing half duplex mode

   There are some key items to observe from the above output:

     - Soundmodem is using "mkiss" which is important

     - the ax.25 interface being created it "sm0"

     - the default AX.25 paclen or MTU here is 256 (max size).  This will be 
       overridden in the /etc/ax25/axports file

     - The callsign used for this sm0 ax.25 device will be "KI6ZHD".
       This is a critical detail that correlates your settings to a
       userspace device given in /etc/ax25/axports

     - The ipaddr will be set to whatever you configured.  This
       usually should be an AMPR address.  Please see the AMPR 
       section in this document on how to get one or more addresses
       for free

     * If you see some strange values in here, read the Soundmodem
       Troubleshooting section below

   You'll also see the interface in /sbin/ifconfig
   sm0       Link encap:AMPR AX.25  HWaddr KI6ZHD
          inet addr:  Bcast:  Mask:
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Ok, things are getting close but a few things to know:

  1. the diagnostic views in soundmodem usually seem to freeze on most
machines.  Newer versions of soundmodem have fixed this but also make
sure you're running newer versions of the ALSA sound system.

  2. You MUST make sure that soundmodem, kissattach, and ax25d are NOT
running before you start everything up.  If you don't, you'll see errors

    tty_speed: tcgetattr: Invalid argument

    use this set of commands to make sure things are clean:
    killall ax25d
    killall kissattach
    killall soundmodem

So you have the basics for an AX.25 setup now so lets let get things to come up
reliably though on a manual fashion:

   [ Here is a quick hint but see below...]

   #Connect the cables, turn on the radio, set it to 144.390 (APRS)

   /sbin/modprobe mkiss

   #open soundmodemconfig and check the levels
   # as root

   #bring up soundmodem (as root)
   /usr/sbin/soundmodem -v5

       #You should see:
       #  sm[11301]: mkiss: ifname sm0 mtu 256 hwaddr KI6ZHD-0 ipaddr
       #  netmask broadcast
       #  ALSA: Using sample rate 9600, sample format 2, significant bits 16, buffer
       #  size 4800, period size 144
       #  ALSA: Using sample rate 9600, sample format 2, significant bits 16, buffer
       #  size 4800, period size 144
       #  sm[11301]: audio: starting "plughw:0,0"
       #  sm[11301]: audio: forcing half duplex mode

       # NOTE:  errors like the following seem to not hurt operation:
       #     snd_pcm_start in iotxstart: Broken pipe

   | NOTE:                                                                          |
   |       At this point, your soundcard TNC should be operational.  It's important |
   |       to note that unlike a hardware TNC, you *DO NOT* use "kissattach" to     |
   |       associate the TNC to a serial port.  Soundmodem does all of this for you |

Instead of running all those manual commands above, I've consolidated much of 
this startup and shutdown details into one powerful startup script:

   |  This "packrig.sh" script documents a FAR more detailed and extensive       |
   |  breakdown of how to configure, tune and operate a packet station for       |
   |  multiple configurations.  It includes the ability to:                      |
   |                                                                             |
   |            - switch between Hardware and software TNC configs               |
   |               for VHF/UHF and HF packet                                     |
   |            - depending on the frequency:                                    |
   |               - switch the beacon strings                                   |
   |               - switch linpac configs depending                             |
   |               - switch between different UNPROTO paths                      |
   |               - change the packet paclen (MTU), TXDELAY, etc.               |
   |               - disables all suspend/hibernation ACPI                       |
   |                                                                             |
   | http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/packetrig.sh |
   |                                                                             |
   | To integrate into the doc:                                                  |
   | --------------------------                                                  |
   | dependencies:                                                               |
   |    /etc/ax25/                                                               |
   |      VHF and HF axports and soundmodem configs                              |
   |    /usr/local/sbin/                                                         |
   |      disable-acpi-suspend.sh                                                |
   |      no-sleep-machine.sh                                                    |
   |      sleep-machine.sh                                                       |
   |      tmd710_tncsetup                                                        |

6.j - Soundmodem Troubleshooting - Fixing issues in running Soundmodem

  | NOT recommended: Use Direwolf                       |
  |                                                     |
  |     This section is here for posterity reasons only |

Incorrect Sampling rates:
In setting up Soundmodem on Centos6 for 300baud HF operations, the soundcard tones 
sounded nothing like what is expected.  Hmmm.. what to do?  First, look at the output 
when starting soundmodem.  I had:

   sm[21533]: mkiss: ifname sm0 mtu 256 hwaddr KI6ZHD ipaddr netmask broadcast
   sm[21533]: Opening PTT device "/dev/ttyS0"
   ALSA: Using sample rate 5000, sample format 2, significant bits 16, buffer size 2500, period size 75
   ALSA: Using sample rate 5000, sample format 2, significant bits 16, buffer size 2500, period size 75
   sm[21533]: audio: starting "plughw:1,0"
   sm[21533]: audio: forcing half duplex mode

Notice the very strange sampling rate above using the ALSA device "plughw:1,0"!  It turns out I was
running soundmodem-0.16 which was too old.  I need to upgrade to soundmodem-0.18 but also apply the 
additional patch:


as mentioned above in the compiling section.  Once that was installed, I then saw the following output and 
heard the proper 300BAUD packet tones:

   sm[25731]: mkiss: ifname sm0 mtu 256 hwaddr KI6ZHD ipaddr netmask broadcast
   sm[25731]: Opening PTT device "/dev/ttyS0"
   ALSA: Using sample rate 11025, sample format 2, significant bits 16, buffer size 5513, period size 165
   ALSA: Using sample rate 11025, sample format 2, significant bits 16, buffer size 5513, period size 165
   sm[25731]: audio: starting "plughw:1,0"
   sm[25731]: audio: forcing half duplex mode

Radio keying up when receiving good packets
Soundmodem asserts the DTR serial line when detecting valid packets (DCD).  Unfortunately,
some soundcard interface cables accept DTR or RTS as a signal to key up the radio!  In
my case, DTR was keying up the CW side of the radio and would start transmitting on received

To fix this, see the compiling section that recommends my soundmodem.spec file and
related patches.

8. - First time AX.25 setup and bringup

The configuration of the Linux AX25 system isn't very difficult once you
understand all the different pieces and how they fit together.  Unfortunately, 
there is a LOT of old information out on the Internet showing different config 
file syntax, etc.  and it gets frustrating in a hurry!

In this example, I'm going to setup my system to connect either:

   - A Kenwood TH-F6A radio to the Direwolf softtnc program using the /dev/ttyUSB0 
     USB based serial port for keying PTT 

   - A hardware based TNC (Kenwood D710, KPC3 TNC, etc) connected to a radio on 
     serial device /dev/ttyUSB0

   | NOTE:  My "packetrig.sh" script's comments has a FAR more detailed and       |
   |        extensive breakdown of how to configure, tune and operate a packet    |
   |        station for multiple configurations.  It includes the ability to:     |
   |                                                                              |
   |            - switch between Hardware and software TNC configs                |
   |               for VHF/UHF and HF packet                                      |
   |            - depending on the frequency:                                     |
   |               - switch the beacon strings                                    |
   |               - switch linpac configs depending                              |
   |               - switch between different UNPROTO paths                       |
   |               - change the packet paclen (MTU), TXDELAY, etc.                |
   |               - disables all suspend/hibernation ACPI                        |
   |                                                                              |
   | http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/packetrig.sh  |
   |                                                                              |
   |                                                                              |
   | A lighter take of of a startup script for Direwolf and TNC-PI (hardware      |
   |  TNC) can be found at:                                                       |
   |                                                                              |
   |    http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-up.new  |
   |       and                                                                    |
   |    http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-up.new2 |
   |       and                                                                    |
   |    http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-down    |
   |                                                                              |
   | To integrate into this doc:                                                  |
   | ---------------------------                                                  |
   | dependencies:                                                                |
   |    /etc/ax25/                                                                |
   |      VHF and HF axports and soundmodem configs                               |
   |                                                                              |
   |    /usr/local/sbin/                                                          |
   |      disable-acpi-suspend.sh                                                 |
   |      no-sleep-machine.sh                                                     |
   |      sleep-machine.sh                                                        |
   |      tmd710_tncsetup                                                         |

   | Three Very Important Notes:                                                  |
   | ---------------------------                                                  |
   | 1. Every callsign+SSID in the axports file MUST be unique and refer to a     |
   |    unique userspace device like "vhfdrop", "d710", "f6a", etc.               |
   |                                                                              |
   | 2. Though very subtle, the specific "KI6ZHD" callsign and SSID (no SSID      |
   |    specified means -0) used here does the correlation of connecting the      |
   |    Linux AX25 device "ax0" to the userspace axports device "vhfdrop".        |
   |    You, as a user, will NEVER use the "ax0" device directly. you use         |
   |    "vhfdrop"                                                                 |
   |                                                                              |
   | 3. In an older version of this doc, I set the device name in the axports     |
   |    file as "ax0" which was identical to the device name in the               |
   |    soundcard config.  Though this technically works and is even recommended  |
   |    by some, it's not recommended by most Linux ax.25 documentation and can   |
   |    become very confusing to the packet operator.  This userspace device      |
   |    name in the /etc/axports file should be UNIQUE.                           |

Ok, I hope the above didn't scare you.  There is a lot to AX.25 but it's actually
pretty simple to get something started.  Let's try that.

- First, assuming you installed all the various AX25 packages from the above sections,
  edit or create the /etc/ax25/axports file.  You'll need to edit it to match your 
  specific setup (callsign, interface name, etc).  The format of this file is as follows:

    - name : the interface name for this port.  It can be ANYTHING but it's probably
             helpful to name it something informative like "d710" or "vhfdrop".

    - callsign+ssid : this parameter sets up your station to use your callsign and your
                      desired SSID.  Each SSID *must* be unique on your station regardless
                      if being used for AX.25 or NETROM connections.  A setting of say
                      "KI6ZHD" is the equivalent of "KI6ZHD-0".  I encourage you to 
                      read out to some of your local packet experts to learn what the
                      SSID use guidelines are for your chosen packet frequency.  They
                      really can vary from area to area and frequency to frequency.

                      See the "#pkttutor" section above on learning more about packet,
    - speed : this is the speed used between the computer and a physical TNC.  If your
              TNC is running an RF speed of 1200BAUD packet, setting this to 9600 is
              fine.  If using direwolf, this field will be essentially ignored so I
              would leave it at 9600

    - paclen : This packet length or MTU is the maximum size of each packet in bytes that 
               will be sent on RF.  For 1200bps VHF or UHF frequency packet, 128 or 250 
               bytes is common (256 is the max) as long as you have very clean signals.  
               For HF packet running at 300bps, it's generally recommended to set this to 
               64 because of the high packet corruption rates observed.  Other HF centric
               writeups recommend setting this to 128.  That's possible but *only* if you 
               have lots of strong, very clean packet signals at your station.  I would
               recommend to start at 64 and work your way up.
               NOTE:  Every time you get a packet collision or packet corruption
                      due to QRN/QRM, your station will have to send the entire
                      packet over.  This is why sometimes setting paclen to the maximum
                      is NOT the optimal setting.  This needs to be tuned for your
                      very specific environment to the specific remote station

               NOTE #2: If you set the paclen to be less than 68 bytes, the Linux IP stack
                        will fail and give errors such as:

                           SIOCSIFADDR: No buffer space available
                           SIOCSIFNETMASK: Cannot assign requested address
                           SIOCGIFADDR: Cannot assign requested address
                           SIOCSIFBROADCAST: Cannot assign requested address

                       because RFC 791 states "Every internet module must be able to forward a 
                       datagram of 68 octets without further fragmentation

   - window : This is the number of outstanding packets that can be sent by your station
              before it will require an ACK packet back.  Related to the paclen or MTU, the 
              larger the window, the higher packet performance you'll observe.  The challenge
              is if one packet is lost, the entire window worth of packets have to be resent 
              (in AX.20 v2.0 spec).  I would recommend to start at a window of 2 and maybe 
              move up to 4 and tune from there (much like MTU).  The maximum is 7 for AX25 
              v2.0 and with AX.25 v2.2 (not common), this goes up to 127.

   - Description: This is just a helpful text string and is not used anywhere else

   So, here is an example axports file:
   #name callsign speed paclen window description
   #change "N0CALL-8" to your callsign
   vhfdrop KI6ZHD 9600 128 2 Kenwood F6A at 1200baud

Ok, example #1:  manual start things up for direwolf.  The following steps are taking from
the lightweight Rpi startup script at:  


  #Load the AX25 kernel module
  modprobe -a ax25

  #Start direwolf
  direwolf -t 0 -c /etc/ax25/direwolf.conf -p

  #Connect Direwolf's emulated serial port (-p) to Linux's kernel interface
  mkiss -s 19200 -x 1 /tmp/kisstnc > /tmp/unix98
  export PTS0=`more /tmp/unix98 | grep -w /dev | cut -b -11`

  #Attach the serial port Linux's ax25 stack
  kissattach $PTS0 vhfdrop

  #Set the AX.25 parameters - these are all very important bu the TXDELAY is a CRITICAL
  # setting for your radio.  300ms is safe but slow, 150 is too aggressive for some radios
  #  Half duplex, TXDELAY of 200ms, SLOTTIME of 100ms, PERSIST of 63 (out of 256), TXtail of 0ms
  /usr/local/sbin/kissparms -p vhfdrop -f n -t 200 -s 100 -r 63 -l 0


Now for example #2:  manual start things up for a Kenwood D710 hardware TNC but this 
will equally apply for say a radio with a Kantronics KPC3 connected as well.  The following 
steps are taking from the lightweight Rpi startup script (uses a TNC-Pi which is a version 
of a TNC-X) at:  



  #Become root to run these commands
  sudo su

  #Load the MKISS kernel module
  modprobe -a mkiss

  #Load the AX25 kernel module
  modprobe -a ax25

  #Put the Kenwood D710, KPC3, or other HW TNC into kiss mode
  #   You can find the D710 KISS tool at: 
  #          newer version: https://github.com/fmarier/tmd710_tncsetup
  #          older version: http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/misc/D710/tmd710_tncsetup.c
  #   Alternatively, you can find a similar tool for Kantronics KPC3 TNCs at:
  #          http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/kiss-on-kpc3.pl
  #          http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/kiss-off.pl
  # -B0 is VFO-A (left side), -S is the connected serial port, -b is the RF speed, and -h is hardware flow control
  tmd710_tncsetup -B 0 -S /dev/ttyUSB0 -b 1200 -h

  #Connect the hardware TNC via the /dev/ttyS0 serial port to Linux's kernel interface
  mkiss -s 9600 -x 1 /dev/ttyUSB0 > /tmp/unix98
  export PTS0=`more /tmp/unix98 | grep -w /dev | cut -b -11`

  #Attach the serial port Linux's ax25 stack
  kissattach $PTS0 vhfdrop

  #Set the AX.25 parameters - these are all very important bu the TXDELAY is a CRITICAL
  # setting for your radio.  300ms is safe but slow, 150 is too aggressive for some radios
  #  Half duplex, TXDELAY of 200ms, SLOTTIME of 100ms, PERSIST of 63 (out of 256), TXtail of 0ms
  /usr/local/sbin/kissparms -p vhfdrop -f n -t 200 -s 100 -r 63 -l 0


Assuming all went well, you can use various programs addressed in the next section to
make outgoing connections, etc.   For example, check out the "call" or "axcall" program.

At this point, you'll want to automate the setup AND tear down of your packet system.  Read 
the above box at the top of this section to see URLS for either my:
  - ax25-up.new (base script), ax25-up.new2 (advanced daemons) and ax25-down (shutdown) scripts
  - hampacket.sh script containing more detail on how to tune your AX.25 setup (read the comments)

Both scripts do a lot but if you have any questions, feel free to email me (or find me on Echolink 
at KI6ZHD-L).

9. - AX.25 Packet programs - Bringing up the other useful packet applications and daemons

As part of the ax25-apps package, there are several basic programs to make outbound
connections.  Let's talk about two of them in particular:

   - ax25_call :: a simple connection tool similar to TELNET that
                  can connect to remote AX.25, NetROM, ROSE, etc.
                  hosts from the ax25-tools RPM

                  - this tools has aliases to be netrom_call, rose_call
                    and even tcp_call

   - call :: a better AX25 connection tool similar to TELNET for
             TCP/IP.  Supports a basic interface as well as a
             'talk' style split screen.  Comes from the ax25-apps
             RPM.  Works well though Linpac is even nicer

Say you're in Silicon Valley trying to connect to K6SNY-1.  To do so, you you 
would enter:

    call vhfdrop K6SNY-1

      - axcall is the program

      - vhfdrop is the AX.25 device
           - in my examples, vhfdrop would be for a Direwolf-based softtnc connected 
             to my Kenwood TH-F6A HT
           - Alternatively, I could have d710 for a Kenwood D710 based HW-TNC
      - K6SNY-1 is the remote destination

    Other examples:

         - To connect to a directly reachable AX.25 machine, I would do:
               call d710 woody

         - To connect to a indirectly reachable AX.25 machine via a digipeater, 
           (not recommended for over 3 hops away), I would do:
               call d710 berry via woody 

         - To connect to a indirectly reachable AX.25 machine via a node, 
           I would do:
               call d710 woody
               #wait for the connection to establish
               #Using the Kantronics "c" command, connect to the remote host "berry"
               c berry

         - To connect to a remote machine via NetROM, I would do:
             # This assume your have a) Netrom configured on your system 
             # (covered below) and b) the remote destination is loaded
             # in the Netrom route table.  Shown with "route -A netrom"
               call netrom berry        

    | You can learn more about making direct Netrom connections, etc via this separate doc:        |
    |                                                                                              |
    |   http://www.trinityos.com/HAM/CentosDigitalModes/misc/145.050-netrom-and-tcpip-connects.txt |

A GOOD connection to K6SNY-1 according to axlisten would show:

   #This is a connection request
   fm KI6ZHD-8 to K6SNY-1 ctl SABM+

   #This is a completed connection
   fm K6SNY-1 to KI6ZHD-8 ctl UA-   

   #This is a transmit of the "?" character  (the trailing . is a terminator)
   fm KI6ZHD-8 to K6SNY-1 ctl I00^ pid=F0(Text) len 2 0000  ?.   

   #This is a connection keepalive
   fm KI6ZHD-8 to K6SNY-1 ctl RR0+

   #This is a disconnect request
   fm KI6ZHD-8 to K6SNY-1 ctl DISC+

   #This is a disconnect confirmation
   fm K6SNY-1 to KI6ZHD-8 ctl DM-

See the "Appendix B - KI6ZHD Running Packet notes for QTH" section for more hints
and tips on basic packet operation

As you've seen, you can make basic, outgoing connections but Linux AX.25 can do SO much 
more using tools from the ax25-suite as well as 3rd party tools.  For example:

   #beacon - Announce your presence on a given frequency
   beacon -d BEACON -t 10 vhfdrop "Welcome the new HAM to AX.25.. still working on it"

    # There are interesting ways to use beacon.  Try some of these scripts:
    # Sending out UI packets for chats

    # Sending out APRS formatted packets

   To monitor all of the received packets LIVE including the packets your station
   sends, there are two useful programs you should be aware of:

   listen :: listens to ALL packets sent and received
             This is already running in the packetrig.sh script
             and you can just tail the log file

             /usr/bin/listen -8artp vhfdrop 

      Make sure it DOESN'T say "axconfig: port vhfdrop not active"

   mheard :: shows last heard stations with optional things like
               via what digipeater, etc.  "man mheard"

             Doesn't show the frequency but it's very similar
             to the "last" command in Unix
   #First start the mheard server


   #After a while, run the client program to see what stations were heard:


   #ax25d daemon - similar to inetd which will start services based on incoming requests
      #You should see:
      #  axconfig: port APRS not active
      #  nrconfig: unable to open nrports file /etc/ax25/nrports (No such file or directory)
      #  rsconfig: unable to open rsports file /etc/ax25/rsports (No such file or directory)

9a. - ax25mail-utils - AX.25 messaging tools for used with Linpac

One thing I've been missing on my system is a simple way for users to leave messages
and for me to reply to them.  Below I describe what I've found and the integration 
of axmail-utils with Linpac gets close but ultimately, Linpac wants to forward those
messages on to a remote FBB BBS.   I don't want that.. I want it all local and 
without using a Mail Transfer Agent (MTA) which won't let me reply to the user's
message without them having a Unix account on my box!   Gahhh!!

Read on to see what I've found so far..

   I am now the maintainer of ax25mail-utils and I plan on releasing 0.12 shortly
   which integrates all of the Ubuntu patches.  Until then, the below notes still

    This suite is used by say Linpac to transfer messages to/from a FBB
    BBS.  Most of the versions on the internet are stale and cannot compile
    due to it looking for the pre-2.4 head files such as netax25/kernel_ax25.h
    and netax25/kernel_rose.h. Fortunately, Debian has an updated patch set
    that gets things working ok:

    cd /usr/src/redhat/SOURCES
    #no, the Debian sourced one is no different
    wget http://iweb.dl.sourceforge.net/project/ax25mail/ax25mail-utils/0.11/ax25mail-utils-0.11.tar.gz

    #get the Debian patches
    wget http://ftp.ubuntu.com/ubuntu/pool/universe/a/ax25mail-utils/ax25mail-utils_0.11-6.1.diff.gz

    #Optionally, you can find them on my site as well:
    #   wget -r -l1 --no-parent -nd -A ax25mail* www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/

    gunzip ax25mail-utils_0.11-6.1.diff.gz

    #Next, download my patch and ax25mail-apps.spec file from:
    cd /usr/src/redhat/SOURCES
    wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ax25mail-utils_0.11-ulistd.diff
    cd /usr/src/redhat/SPECS
    wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ax25mail-utils.spec

    #Ok, time to build it:
     #for 64bit systems
     rpmbuild -bb --target=x86_64 ax25mail-utils.spec
     rpm -ivh /usr/src/redhat/RPMS/x86_64/ax25mail-utils-0.11-7.1.el6.x86_64.rpm

     #for 32bit systems
     rpmbuild -bb --target=i686 ax25mail-utils.spec
     rpm -ivh /usr/src/redhat/RPMS/i686/ax25mail-utils-0.11-7.1.el6.i686.rpm

    Once you install the RPM, you'll need to manually create the following 
    directory (I couldn't get the %dir macro to work properly in the .spec file):

         mkdir /var/ax25/ulistd

    If you are manually doing things without the .spec file
       cd /usr/src/redhat/BUILD
       tar xzvf ../SOURCES/ax25mail-utils_0.11.orig.tar.gz
       cd ax25mail-utils-0.11.orig/
       vi ulistd/ulistd.c and delete the two lines:
         #include >netax25/kernel_ax25.h<       // new for libax25
         #include >netax25/kernel_rose.h<       // required by axlib.h

       patch -p0 < ../SOURCES/ax25mail-utils_0.11-6.1.diff
       make install

    Incomplete - To do:
    Once installed, the ax25mail-utils prgram needs the following configuration
    files to be configured to relay mail to/from Linpac:


    Out of the box, this program can forward/relay messages from FBB, JNOS, and
    a few other BBSes and it seems extensible to support other BBSes as well.

       NOTE: I have tried configuring these files but regardless of what
             I do (I've tried all kinds of callsign permutations, etc), when 
             I run ulistd, I always get:

                no BBS specified in configuration file /etc/ax25/ulistd.conf

             If you know the solution to this error, I'd love to hear from you
             on what I'm doing wrong!


    There is an old program called "pms" which was apart of the deprecated 
    ax25-utils package.  This program only receives messages and it forwards 
    the resulting message to email via Sendmail (no simple / local PBBS mail) 
    and it also doesn't support sending messages to other hams using your PBBS 
    as their mailbox.  This program also does not support reading any messages.  
    This program was abandoned a long time ago when the ax25-utils package was 
    broken into the ax25-apps and ax25-tools packages.  
    I found this Axmail program (0.0.5) at http://benghi.wz.cz/vyvoj.html but 
    this program also uses Sendmail to send/receive emails and it also uses the
    axspawn mechanism to dynically create Unix accounts to support new users
    on  demand.

    A HAM has posted his Perl version of what is similar functionality to 
    what the PMS program does.  Unfortunately for me, it still uses a local
    MTA to deliver messages and doesn't provide any way for me to respond 
    to the user's message like one could on a classic TNC PBBS.


    Still researching this for a viable PBBS canidate on Linux as of 08/03/12
    but it still looks like Linpac is your best bet

10. - Advanced AX.25 configuration, Netrom, Node services, and Troubleshooting

10a. - ax25spyd - Next generation packet monitoring daemon

Ax25spyd is very much like the AX.25 "listen" program (or axlisten for you Debian users) 
that comes with ax25-apps package.  It acts like a sniffer on your AX.25 interfaces but it 
has a few key differences to the classic AX.25 "listen" program:

   - The AX.25 listen program must be run by root to connect to the required kernel 
     sockets.  This usually requires the program that calls "listen" to run as the 
     root user.  One workaround here is you can make the "listen' binary SUID root
     but that's not a great security practice.  A better way is to break up the 
     root and non-root access.  See AX25spyd

   - ax25spyd is now split into two pieces (client and server):

        ax25spyd - The daemon runs as the root user and provides all network socket 
                   connections to ax25spy clients.  This design allows other programs 
                   that previously required to be run as ROOT to now run as a 
                   regular user (this is a more secure design)

                 - The daemon can detect transit packet messages and send them 
                   to a SMTP host

                 - The daemon can capture all traffic on a per-callsign basis (not just
                   all traffic on a given frequency) and put this filtered view 
                   it in a SRC to DST callsign named file: /var/lib/ax25/ax25spyd/call1->call2

        ax25spy  - The ax25spy client which communicates to the ax25spyd daemon

                 - displays decoded AX.25 packets much like the ax25apps "listen" does

                 - Can display packets similar to a DX-cluster display

                 - Can change it's view to just show various AX.25 packet types like
                   I, UI, IP, show unique QSOs, etc

Debian has a patched version of the ax25spyd code that's more modern than the official version 
posted at http://linkt.de/ax25spyd/ .  This updated version works with modern Linux kernels 
and libraries.  Let's use that version with Centos:

   cd /usr/src/redhat/SOURCES
   wget http://linkt.de/ax25spyd/ax25spyd-0.23.tar.gz

   #Get the patch files from the Debian sources
   #   I beleive these sources have been REMOVED.  If you would like a copy of these patches,
   #   please email me
   wget https://cloudfront.debian.net/debian-archive/debian/pool/main/a/ax25spyd/ax25spyd_0.23-8.diff.gz

     #Alternatively, you can find the patches from my site too
     wget -r -l1 --no-parent -nd -A ax25spy* www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/

   #Next, download my ax25spyd.spec file from:
   cd /usr/src/redhat/SPECS
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ax25spyd.spec

   #Ok, time to build it:
     #for 64bit systems
     rpmbuild -bb --target=x86_64 ax25spyd.spec

     #or for 32bit systems
     rpmbuild -bb --target=i686 ax25spyd.spec

     I have seen a strange transient error where the compile will FAIL with errors like:
       cd . && automake --gnu Makefile                                                                                                                                              
       configure.in:4: your implementation of AM_INIT_AUTOMAKE comes from an 
       configure.in:4: old Automake version.  You should recreate aclocal.m4
       configure.in:4: with aclocal and run automake again. 
       make: *** [Makefile.in] Error 63
       error: Bad exit status from /var/tmp/rpm-tmp.sbVtCD (%build)

    I found if you try building the RPM several times times back to back, the compile 
    will eventually succeed anyway.  Dunno why and it's still happening as of 10/16/12!  
    Maybe this is an issue with the older Automake shipped with Centos6??  

    Anyway, let's move on:

    # Now go ahead and install it
    #for 64bit systems
    rpm -ivh /usr/src/redhat/RPMS/x86_64/ax25spyd-0.23-8.1.el6.x86_64.rpm

    #for 32bit systems
    rpm -ivh /usr/src/redhat/RPMS/i686/ax25spyd-0.23-8.1.el6.i686.rpm

       If you AREN'T going to build things via the SPEC file, follow this
      cd /usr/usr/redhat/BUILD
      tar xzvf ../SOURCES/ax25spyd_0.23.orig.tar.gz
      gunzip ../SOURCES/ax25spyd_0.23-8.diff.gz
      patch -p0 < ax25spyd_0.23-8.diff

         NOTE:  I've seen strange transient build error (shown above)):
         To work around this, I ran "aclocal" which didn't give any output, 
         I then deleted the ax25spyd sources in /usr/src/redhat/BUILD, 
         re-untared the archive, and patched them and then re-did the 
         configure and make and things worked fine

Ok, now with ax25spyd installed, try running src/ax25spyd as the root user
for a moment:

  NOTE: You can invoke "ax25spyd -s" which will create unique files in 
        /var/lib/ax25/ax25spyd\ for per-callsign detail

   Linpac: The Ncurses Linpac terminal program will automatically connect
           to the ax25spyd daemon as an alternative to trying to use the
           ax25 listen daemon (which requires ROOT access)
   LinKT:  The KDE-based LinKT terminal program has a packet monitoring
           program called MonKT that uses the ax25spyd daemon

10b. - AX.25 NetROM Routing and connections

Netrom - Netrom is a protocol that rides over AX.25 and has two main purposes

         1. advertise known local neighbors with an associated link quality
            in periodic "netrom" route updates

         2. connect to remote stations found in the netrom route table without
            requiring the user to know each of the hops to get to that
            final destination

To configure Netrom on Linux, first you need to configure the /etc/ax25/nrports
file.  In this example, the sole line configures SSID -5 which will announce 
the "SCLARA" node alias using the netrom interface called "netrom" which will 
resolve back to KI6ZHD-7 for netrom connections.

The first configured item in that file is the netrom DEVICE which nothing can 
connect (this is similar to the "ax0" interface that's configured but never 
directly used.  The next parameter is the callsign that is used when both 
advertising netrom routes (both locally generated and optionally re-advertised 
routes) and is the source callsign used when making Netrom connections.  In this 
example, I'm using an SSID of -5 for my outbound connections which is common for
Northern California Netrom nodes.

  NOTE: The man pages speak of putting a # in front of the NetROM alias of "SCLARA" 
        to mean it won't ever be announced by the NetRom system.  I'm not sure if 
        the # trick is working as I still see SCLARA / KI6ZHD-5 getting announced

  NOTE2:  All of these "aliases" listed here must be UNIQUE to the netrom
          table in your area.  Please make sure you MONITOR your chosen
          frequencies and netrom systems before choosing these names.  Here in 
          Norcal, the general recommendation is to have a netrom alias that
          calls out your general location.

  NOTE3: blank lines in this file are NOT legal!! 

  NOTE4: The max peclen or MTU for a netrom packet is 236 bytes due to netrom overhead

# /etc/ax25/nrports
# The format of this file is:
# name callsign alias paclen description
netrom	KI6ZHD-7	SCLARA	236 	node

Finally, we need to edit the /etc/ax25/nrbroadcast file.  This file controls
which AX.25 ports we will send NetROM broadcasts over and how it learns 

   NOTE:  Please consider setting the VERBOSE setting to 0 unless your system
          offers high level coverage!!  If you have a low level machine like
          most of us, the routes you'll be advertising are probably going to be 
          inferior to those other high level routes.  You'll also be sending 
          these poorer routes all the time, polluting the airwaves!

For me, I use the following:

  - d710       - matches up with the radio port definition in /etc/ax25/axports 

  - min_obs    - minimum obsolescence count - when learning remote routes, a 
                 heard route must have a OBS value HIGHER than this value to be 
                 considered valid and entered into the local table and possibly
                 be re-advertised

  - def_qual   - this "default quality" is the initial value we first set to the 

  - worst_qual - minimum quality of a received route to be added to the local
                 netrom table

  - verbose    - A setting of verbose=0 will NOT advertise learned routes and
                 only advertise locally generated routes (ourself).  A setting 
                 of "0" is a GOOD default until you a) have a good handle on 
                 NetROM routing and b) you're machine has good reachability to 
                 other nodes and your system can handle the potential transit 

# /etc/ax25/nrbroadcast
# The format of this file is:
# ax25_name min_obs def_qual worst_qual verbose
d710		5	190	100	  0

Next, bring up the netrom interfaces by issuing:

   /sbin/modprobe netrom
   /usr/sbin/nrattach -i netrom

  After running each one of those nrattach lines (if you have multiple), you 
  should get a new "nr" device like nr0, nr1, nr2.  If you don't a unique 
  device and instead each line reuses nr0, you're running a buggy version of 
  the ax25-tools package!  The solution to this is to either add a patch
  (discussed in the section where this document covered the installation of 
  the ax25-tools package OR (probably the more recommended way if you're 
  starting from scratch), use newer versions of the AX tools (be it the 
  CVS version "official AXTools" (last updated June 2011), the FPAC / F6BVP 
  version, or the VE7FET version posted on Github.  

Finally, to get the netrom service running, issue the commands where:

 -i    : will send a netrom route update immediately
 -l    : turns on logging for both programs
 -t 30 : send updates every 60 minutes

   /usr/sbin/ax25d -l
   /usr/sbin/netromd -i -l -t 60

# NOTE: These commands are fully integrated into the master packetrig.sh script

Make Netrom connections locally:
As part of the ax25-apps package, the "call" program can make direct Netrom
connections.  The man page eludes to this but what if fails to mention that
for the "port", you need to use the netrom device as defined in 
/etc/ax25/nrports!   As an example, if I make a regular AX.25 connection

     call d710 woody

I would make a netrom call by doing the following:

     call netrom wbay

I bet you might be able to create Netrom connections via Linpac but
you need to be able to change the port from say "d710" to "netrom".
You might be able to do this on a per-F-key basis but I haven't looked.

Two other useful programs:

   - nrparms  :: manually create NetROM routes

   - nodesave :: Store (and optionally reload) learned netrom routes 
                 If you have a machine running a long time on a frequency
                 and it's stored up a long list of NetROM routes, you can
                 SAVE them from the /proc/net/nr_routes file with this 
                 tool which creates a shell script that you can simply
                 run to restore these routes if you had to reboot, etc.
                 Do be careful about this and try not to use very old
                 saved tables as nodes come and go all the time!
                 For example, I use:

                 /usr/sbin/nodesave /var/ax25/nr-routes-145050.sh

    | You can learn more about making direct Netrom connections, etc via this separate doc:        |
    |                                                                                              |
    |   http://www.trinityos.com/HAM/CentosDigitalModes/misc/145.050-netrom-and-tcpip-connects.txt |

Important note:
To help make all of this easy and reliable, ALL of these configurations are 
already present in my TrinityOS packetrig.sh master shell script!

10c. - AX.25 Node Services - UroNode

An AX.25 node program allows remote users to connect to your machine, run various
local programs as well as initiate connections from your machine on to remote machines.  
This connect and initial approach is superior to digipeating as each hop can do 
per-link retries.  This is compared to digipeating where the source station has to send
complete end to end retries all the way through the path.  This method is quite 
error-prone and rarely works over paths with more than THREE digis.  It's also more 
common to connect to a node via Netrom connections vs. say a standard AX.25 connection
but both approaches are supported.

There are at least five Node programs out there for Linux that I am aware of.  These
are listed in general order from recommended to not recommended:

  - Uronode   - [ Recommended ]
                A heavily modified version of Awznode that has additional features 
                such as Flexd for Flexnet routing code beyond all the features 
                available in Linuxnode.  A very powerful node program.
                - Actively maintained

  - FPAC      - Part node, part ROSE protocol daemon, part packet switch.  I haven't
                used this program much but it's heavily used in Europe.  
                Well supported and cross supported with the FBB BBS software
                - Actively maintained

  - FlexNet   - A very powerful packet switch / routing system that is heavily 
                deployed in the Eastern United States and Europe.  It has several common
                attributes to the ROSE protocol specifically being more efficient, 
                more intelligent than Netrom, etc.  Supported via the Linux's flexd
                daemon, Xnet, and other packages.

  - Linuxnode - [ Not Recommended ]
                Also named 'axnode' in Debiab-based distros or 'node' on all other
                distros, this is the original node version that comes with the standard 
                Linux AX.25 tools.  Think of it as a simple portal interface like any 
                other packet node (Kantronics Kanode, etc) but it also allows running
                preconfigured Linux commands, etc.  Quite powerful really.  It works 
                but previously had/has KNOWN security issues.  It's unclear if those 
                security issues have been resolved.
                - Generally not updated anymore 

  - Awznode   - [ Not Recommended ]
                A fork of the original Linuxnode that added several major 
                features but was abandoned.  See below for supported commands.
                - Abandoned code

  -  Unode    - [ Not Recommended ]
                A fork of the previous available version of UroNode 1.x software 
                available at: https://github.com/kd1zd/Unode/tarball/master
                - Was created because active development and availability of UroNode
                  had ceased.  This is no longer the case.
                - Was never actively maintained and now abandoned

You can read about other nodes, what made them unique, their prompts, etc.


   The Uronode software offers not only a NODE interface for remote users
   to hop packets off your system but also offers many other features.  For 
   example, here is the main prompt given to a remote user:
      ?, Bye, Connect, Desti, Escape, Finger, Help, HOst, Info, INTerfaces
      Links, MHeard, MSg, Nodes, Ping, Quit, Routes, SEssions, Status
      Telnet, Users, Version, Who, WInlink

   Unode is also extensible and you can add additional node commands by 
   calling other local Unix commands.  For example, I've also seen machines
   setup to allow for the following:
      ?, Bye, CAllbook, CLuster, Connect, CONVers, Escape, Finger, Help, HOst
      Info, Links, Mheard, NLinks, Nodes, PIng, Ports, Routes, Status, TAlk
      Telnet, Users, ZConnect, ZTelnet

LinuxNode - Comes as part of ax25-tools (for historical comparison)
   Supported commands are:

   ?, Bye, Connect, Escape, Finger, Help, HOst, Info, Links, Mheard
   NLinks, Nodes, PIng, Ports, Routes, Status, TAlk, Telnet, Users, ZConnect

Awznode (for historical comparison)
   Supported commands are:

   !, ?, Bye, Connect, Dest, Escape, Finger, Help, HOst, Info
   Links, MHeard, MSessions, Nodes, PIng, Ports, Routes, Send, TAlk, Telnet

Setting up UroNode

Anyway, for this document, we're going to setup Uronode.  To get the software, 
you can either get it directly from SourceForge.net or from N1uro.net but then 
it needs to be cleaned up a bit:

  # Get the newest sources and patches - Using 2.5.1 as of this writing
  cd /usr/src/redhat/SOURCES
  wget http://downloads.sourceforge.net/project/uronode/uronode-2.5.1.tgz

  # Next, get the SPEC file for this:
  wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/uronode.spec

  # Now that you have the SPEC file, modify it to make sure it matches with
  # your downloaded version of UroNode, etc.

      Version: 2.5.1

  So what's in the patches?  

         a) the configure script is an interactive ncurses script and not a configure 
            script that an automated system would expect.  One patch changes this to
            make it automation friendly

   #Ok, time to build it:

     #for 64bit systems
     sudo rpmbuild -bb --target=x86_64 uronode.spec
     sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/uronode-2.5.1-1.x86_64.rpm
    #for 32bit systems
    sudo rpmbuild -bb --target=x86_64 uronode.spec
    sudo rpm -Uvh /usr/src/redhat/RPMS/i686/uronode-2.5.1-1.i686.rpm

If you previously had an older UroNode installation you may receive warnings like:
   warning: /etc/ax25/uronode.perms created as /etc/ax25/uronode.perms.rpmnew
   warning: /etc/xinetd.d/uronode created as /etc/xinetd.d/uronode.rpmnew

   If you receive any of these warnings, please review the differences in the config 
   files.  I would recommend to review it by using commands like:

      diff -u /etc/xinetd.d/uronode /etc/xinetd.d/uronode.rpmnew

It's worth noting that UroNode includes several other utilities that might be useful
but aren't covered in this document:

   axdigi    - a simple packet digipeater 

   calibrate - tool to properly set your levels for proper FM deviation 

   flexd     - a FlexNet routing client (does NOT include the routing server; 
               it's recommended by N1URO to run the pc/FlexNet program
               in the DOSEmu application.  The alternative Xnet program that 
               does have a Linux port has only been released in binary form 
               and those binaries are too old to use on modern operating
               systems.  It's understood that the developer's consider this
               code as private and will not release the sources.  As such,
               Linux doesn't have many other options to support Flexnet.

Configuring UroNode

The UroNode RPM installs several configuration files in /etc/ax25:

  - Make sure the nrports and nrbroadcast files are configured as 
    mentioned in the previous section

   /etc/ax25/uronode.conf  - the main configuration file

   - In this file, you need to change the following:

      - IdleTimeout : leave this value at 900 (15min)

      - ConnTimeout : leave this value at 600 (10min)

      - HostName    : to reflect your callsign - in my case, it's set to


                      Ideally, you have already
                      requested an AMPR IP address through your local AMPR
                      coordinator.  If you don't know how, email me and I'll
                      help you out with this very simple process

      - Email       : Address to reach you over the internet.  Change
                      this to use whatever email address you use

      - LocalNet    : If you have an AMPR address, put it in here with the
                      right subnet mask.  if not, give it a unique IP that is 
                      in the RFC1918 range with a /32 mask.  In my case, it's
                      set to:
      - Alias       : This section contains all the command aliases to run 
                      Linux programs over Telnet.  This is where the power of
                      Uronode comes in.  Most of the pre-defined entries are ok
                      assuming you're ok to allow users to use your internet
                      connection to check on callsigns, connect to a remote
                      Converse server (like IRC), etc.  You might need to 
                      disable the following two lines:

                         #Alias          DXCluster "connect dxnet"
                         connect dxnet

                      unless you have a DX packet cluster configured on your
                      system.  Removing the second line is to remove a duplicate
                      "quit" entry in the "help" output (it's redundant).  
                      Any aliases added here will automatically show up in 
                      the Uronode "help" when a user requests help

      - HiddenPorts : Allows Sysops to disable the showing of ports.  Disabled
                      by default

      - ExtCmd      : Similar to aliases, you can invoke Linux commands from 
                      packet connections.  Any aliases added here will automatically 
                      show up in the Uronode "help" when a user requests help. I *do* 
                      recommend to disable the default example by adding a # in front:

                      #ExtCmd         NEstat  1       nobody  /bin/netstat netstat --inet

                      Why?  Remote HAMs don't need to see what remote Internet connections
                      you have on this computer.

      - NodeId      : replace XXXXXX:XX#XX-# to your desired node alias, callsign with 
                      SSID. For me, the ALIAS to my node (as setup in the 
                      /etc/ax25/nrports fle is:


      - FlexId      : This is the CALLSIGN and SSID for both proper station identification
                      and Flexnet routing.  This must be configured and align to your
                      Netrom CALLSIGN+SSID.  For me, I'm using:

                        FlexId         KI6ZHD-5

      - NrPort      : Outgoing interface name used for NetROM connections.
                      This should reflect the netrom interface name defined in
                      /etc/ax25/nrports. In my setup, it's called "netrom" but 
                      make it match whatever you have in the /etc/ax25/nrports
                      file.  It should NOT be low level devicename, "nr0"

      - LogLevel    : once your comfortable with the setup, you should drop
                      the logging level from 3 to say 2

      If you have specific questions, do a "man uronode.conf" and "man uronode"

    Other important files:
    uronode.motd  - the message displayed when users connect to it
       - Update it to reflect your setup

    uronode.info  - the message displayed when users issue the "info" command
       - Update it to reflect the technical setup of your setup.  Your specific
         radio, antenna, etc.

    uronode.perms - permissions

    - When a remote user connects to Uronode, it can present the user with a slew 
      of commands to run depending on the default or explicit per-callsign permissions.
      The permission number is a binary value assuming a bitfield reading from right
      to left.  You set the bits you want and then add them all up and that is your
      value.  For example:

                               bit  bit  bit  bit  bit  bit  bit  bit  bit  bit
                               512  256  128   64   32   16   8    4    2    1
                               ---  ---  ---  ---  ---  ---  ---  ---  ---  ---  
         Uronode default:       no   no   no   no   no  yes  yes  yes  yes  yes  == 31
         My recommendation:     no   no   no   no   no  yes   no  yes  yes  yes  == 23

      I recommend to # out all lines for any pre-defined users and CHANGE the default 
      permission items to the following.  

        # user  type    port    passwd  perms
           *    ax25    *       *       23
           *    netrom  *       *       23
           *    rose    *       *       0
           *    local   *       *       23
           *    ampr    *       *       23
           *    inet    *       *       23
           *    host    *       *       23

     You can have PER callsign permissions if you want but for now, my defaults
     are the following as callsigns are easily spoofed.  See the uronode.perms man
     file for full details but the following "perms" value of "7" will setup:

       bit#  1 - permits logging in even if no other more-specific permissions are given
       bit#  2 - permits outgoing AX.25  / Flexnet connects
       bit#  4 - permits outgoing NET/ROM connects
       bit#  8 - DOES NOT permit telneting to hosts in the "local" network as defined in uronode.conf(5).
       bit# 16 - permits telneting to other hosts out in amprnet (only enable 
                 if you have a working AMPR.ORG connection running)
       bit# 32 - DOES NOT permit telneting to other Internet hosts neither in the "local" 
                 network nor in amprnet (aka, general hosts on the Internet, etc)
       bit# 64 - DOES NOT permit using hidden ports in outgoing AX.25 and Flexnet connections
       bit#128 - DOES NOT allow outgoing ROSE connects (not configured yet)
       bit#256 - Leave the escape mechanism (disconnect from the remote service and reconnect 
                 to the master uronode command prompt still functional
       bit#512 - ANSI colors - Leave unset to DISABLE this as it's always unclear if the remote
                 station can display ANSI colors.  You can enable this on a per callsign basis
                 Linpac supports colors but it's unclear if Putty, Hyperterminal, Outpost's 
                 ip serial, UISS, etc can

    - If you want to allow specific remote Sysop access to your machine, you can configure
      per callsign logins with passwords to allow those user's Linux shell access.  Please
      remember that their password will be shown in CLEARTEXT over the airwaves.  As such,
      any lurkers could later log in as their callsign, use the password, and then have
      shell access to your Linux machine.  NOT a great idea and NOT recommended

    - This file allows to configure pre-defined AX.25 or Flexnet destinations so 
      users don't have to specify a specific interface to make the connection on

Next, when an incoming Netrom connection session connects, we need to configure the 
/etc/ax25/ax25d.conf file to tell Linux what to do with it.  This file is very similar 
to the /etc/xinetd.d or /etc/inetd.conf systems that associates incoming TCP connections 
to the correct daemons.  This file is for controlling AX25/Netrom/Rose/Flex RF links.  
When a given RF connection packet comes in with the matching destination callsign and 
SSID, this file will match the CALL+SSID to the configured program and start it up.

   Every SSID in use on Linux must be unique and this can get confusing for some
   people coming from a hardware TNC background.  Specifically, the SSID used in
   the nrports file to broadcast Netrom routes can only be used for Netrom 
   connections.  This chosen SSID CANNOT be also used to connect to via an AX.25 
   connection. This behavior is different from say a KPC3 hardware TNC which does
   allow for this double use.

For my specific configuration, I want the SCLARA Netrom node to be associated with 
KI6ZHD-5 yet allow AX.25 connections to my "d710" AX.25 connection on KI6ZHD-7
SSID.   /etc/ax25/axports file. See the packetrig.sh script's comments for full 
technical details.  To support running the Uronode software, the second stanza is required:

#To allow connections to KI6ZHD-5 from a AX.25 connection
[KI6ZHD-7 VIA d710]
NOCALL * * * * * * L
default * * * * * * - root /usr/sbin/urnode uronode

#To allow connections to SCLARA from a AX.25 connection
NOCALL * * * * * * L
default * * * * * * - root /usr/sbin/uronode uronode

NOTE #1: Previously, I had an entry in the ax25d.conf file for "[SCLARA VIA d710]".
         This was wrong as SCLARA is a NETROM device but it was surrounded by [ ]
         brackets which means AX.25.  It also seems that when specifying 
         netrom devices with < >, you cannot use the "VIA d710" syntax.
         With those errors, I was seeing the following error when trying to make
         outbound connections from Uronode:

           ERROR: connect_to: bind: Cannot assign requested address

         It's key that the NETROM device (for me, it's "netrom") as defined in 
         /etc/ax25/nrports be enclosed in the < > characters

NOTE #2:  Unless you've previously started the ROSE daemon for Rose routing,
          starting up ax25d will error out complaining about the "rsports" file 
          missing.  Simply run "touch /etc/ax25/rsports" and that will no longer 
          be a blocking error.

Local connections via TELNET:
If you want to enable the ability to connect to Uronode from a local telnet
connection, you need to edit two files:

   /etc/xinetd.d/uronode - Edit this file and change disable to "no"
                           Please note this file is created by my RPM spec file
                           but it's not included by default with the stock 
                           Uronode sources.  

   /etc/services         - This file correlates the TCP socket to an application 
        uronode         3694/tcp                        # AX.25 Uronode

   To get everything recognized, you need to restart xinetd:

       /etc/rc.d/init.d/xinetd restart

    If you plan on connecting to Uronode locally from the shell and your
    Linux username is NOT your callsign, you're going to have a problem.
    To work around this issue you can use something like the following
    command to associate your Linux username ("dranch" in this example)
    to a callsign (KI6ZHD):

              axparms -assoc KI6ZHD dranch

    This is already setup in the packetrig.sh script so it's recommended
    to enable that command via that script

Starting it all up:
That's it!  The last key thing is to have the "ax25d" daemon running to listen
to connections.  You can manually start it as the root user with:

      /usr/sbin/ax25d -l

If you reboot your computer, that daemon will not restart automatically.  I 
recommend you use the hampacket.sh script that will do this all for you
upon every reboot.

Using local connections:
  - If you try to use "telnet localhost 3694", you might get the response:
    Trying ::1...
    Connected to localhost.
    Escape character is '^]'.
    Connection closed by foreign host.

    What's happening here is that Centos is defaulting to IPv6 which URONode
    doesn't support as of this writing.  Use your IPv4 address found in the 
    output of "ifconfig".

NOTE:   If you had configured Linpac (previous section) to use the -5 SSID, 
        you should unconfigure that to avoid any conflicts in the
        ~/Linpac/macro/init.mac file

Unode - [ Abandoned ] - Configuring the legacy Node fork

[ Abandoned ] - This section is kept in for historical reasons:

  cd /usr/src/redhat/SOURCES
  wget https://github.com/kd1zd/Unode/tarball/master

  #Next, lets rename it and update it to reflect a new version
  mv master kd1zd-Unode-f685a9a.tar.gz   #This is v1.0.0-1
  cd /usr/src/redhat/BUILD
  tar xzvf ../SOURCES/kd1zd-Unode-f685a9a.tar.gz
  mv kd1zd-Unode-f685a9a Unode-1.0.1
  tar czvf ../SOURCES/Unode-1.0.1.tgz Unode-1.0.1/*

  NOTE:  The "configure" script in the Unode package is:

         a) a Shell script and not the normal configure script
            that you would expect.  It's interactive and thus
            can't be automated

         b) If run, will call everything UroNode where as the
            pre-configured Makefile will call everything

         c) It seems this package includes a previously compiled
            version of axdigi from the original FlexNode package
            but I have no idea if this will run.  I would recommend
            to later DELETE this file and compile up your own 
            from this "Flexnode" package

   NOTE#2: To fix many of those issues (and several others), I've posted
           several patch files at the following URL and they are REQUIRED
           if your going to use my spec file shown below:

           cd /usr/src/redhat/SOURCES
           wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/Unode*

  #Get the spec file from my directory
  cd /usr/src/redhat/SPECS
  wget -o unode.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/Unode.spec

  #Get all the patches too..
  cd /usr/src/redhat/SOURCES
  wget -r -l1 --no-parent -nd -A Unode* www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/

   #Ok, time to build it:

     #for 64bit systems
     rpmbuild -bb --target=x86_64 Unode.spec
     rpm -Uvh /usr/src/redhat/RPMS/x86_64/Unode-1.0.0-1.x86_64.rpm
    #for 32bit systems
    rpmbuild -bb --target=x86_64 Unode.spec
    rpm -ivh /usr/src/redhat/RPMS/i686/Unode-1.0.0-1.i686.rpm

Once installed, the RPM installs several files in /etc/ax25:

  - Make sure the nrports and nrbroadcast files are configured as 
    mentioned in the previous section

| [ Abandoned ] - This section is kept in for historical reasons: |

  Configuring Unode

   unode.conf  - the main configuration file

   - In this file, you need to change the following:

      - IdleTimeout : leave this value at 900 (15min)

      - ConnTimeout : leave this value at 600 (10min)

      - HostName    : to reflect your callsign - Ideally, you have already
                      requested an AMPR IP address through your local AMPR
                      coordinator.  If you don't know how, email me and I'll
                      help you out with this very simple process

      - ReConnect   : This is optional but I personally like to set this to ON.
                      With this, when the user disconnects from a remote 
                      station, they will drop back to your node

      - LocalNet    : If you have an AMPR address, put it in here with the
                      right subnet mask.  if not, give it a unique IP that is 
                      in the RFC1918 range with a /32 mask

      - NodeId      : replace OH2BNS-10 to your callsign. For me, I set it
                      to the following where the first parameter is an
                      ALIAS to this node (if you set one in 
                      /etc/ax25/nrports and the next one is your 
                      callsign+SSID for the node.  For me: 

      - Alias       : I recommend you DISABLE any pre-defined Aliases with a #
                      until you a) know what commands you want b) have an 
                      operational AMPR connection (for some of these examples)
                      and c) and understand the security
                      implications.  Any aliases added here will show up in
                      the "node" interface when people are connected to it

      - ExtCmd      : I recommend to disable any pre-defined Aliases with a #
                      until you know what you want and understand the security
                      implications.  Any aliases added here will show up in
                      the "node" interface when people are connected to it

      - NrPort      : Outgoing interface name used for NetROM connections.
                      The default is "netrom" but if not defined here, 
                      it will either use the FIRST entry in /etc/ax25/nrports
                      or you can make it match something ELSE in the 
                      /etc/ax25/nrports.  I'm using my configured alias of:

      - LogLevel    : once your comfortable with the setup, you should drop
                      the logging level to say 2

      - NodePrompt  : DEPRECATED - not sure if this is honored anymore
                      I recommend to # out the top \n example and re-enable the 
                      bottom one for now with the full string but change the 
                      callsign to reflect your own:
                      "\nSCLARA:KI6ZHD-5} "

      If you have specific questions, do a "man node.conf" and "man node"

    unode.motd  - the message displayed when users connect to it
    - There isn't much to change in this one

    unode.perms - permissions

    - When a user connects to Unode, it presents the user with a slew of options 
      as shown at the beginning of this section.  I recommend to # out all lines 
      for any pre-defined users and CHANGE the default permission items to the 

        # user  type    port    passwd  perms
           *    ax25    *       *       7
           *    netrom  *       *       7
           *    rose    *       *       7
           *    local   *       *       7
           *    ampr    *       *       7
           *    inet    *       *       7
           *    host    *       *       7

     You can have PER callsign permissions if you want but for now, my defaults
     are the following as callsigns are easily spoofed.  See unode.perms for 
     details but the following "perms" values is for:

            - permits logging in even if no other permissions are given
            - permits outgoing AX.25  / Flexnet connects
            - permits outgoing NET/ROM connects
            - permits outgoing ROSE connects.
            - DOES NOT permit telneting to hosts in the "local" network as 
              defined in node.conf(5).
            - permits telneting to hosts in amprnet (only enable 
              if you have a working AMPR.ORG connection running)
            - DOES NOT permit telneting to hosts neither in the "local" 
              network nor in amprnet (aka, hosts on the Internet, etc)
            - DOES NOT permit using hidden ports in outgoing AX.25 connections
            - Escape mechanism for this user is still enabled
            - No ANSI colors - who knows what the remote users are using.
              Linpac can deal with it but can Outpost, ipserial, UISS, etc?

        The defaults are the following (which I think are WAY too open)
        # user  type    port    passwd  perms
        *       ax25    *       *       31
        *       netrom  *       *       31
        *       local   *       *       31
        *       ampr    *       *       31
        *       inet    *       *       0
        *       host    *       *       31

node.info - details on your station
    - Edit this file to give some info on your station

The final file we need to configure is the /etc/ax25/ax25d.conf file.  This file
is very similar to the /etc/inetd.conf file but for AX25/Netrom/Rose/Flex RF links.  
When a given RF connection packet comes in with the correct destination callsign 
and SSID, this file will match the CALL+SSID to the configured program and start 
it up.

For my specific configuration, I want the node to be associated with KI6ZHD-5
to my "d710" AX.25 connection (see the packetrig.sh script for full details).
To support running the Linuxnode software, the second stanza is required:

#To allow connections to KI6ZHD-5 from a AX.25 connection
[KI6ZHD-5 VIA d710]
NOCALL * * * * * * L
default * * * * * * - root /usr/sbin/node node

#To allow connections to SCLARA from a AX.25 connection
NOCALL * * * * * * L
default * * * * * * - root /usr/sbin/node node

#To allow connections to SCLARA from a Netrom connection
parameters 1  10  *  *  *   *   *
NOCALL     *  *  *  *  *   *   L
default    *  *  *  *  *   *   -        root /usr/sbin/unode unode

That's it!

NOTE:   If you had configured Linpac (previous section) to use the -5 SSID, 
        you should unconfigure that to avoid any conflicts in the
        ~/Linpac/macro/init.mac file

NOTE#2  When you eventually start up ax25d and it complains about the rsports
        file for the Rose protocol, simply run "touch /etc/ax25/rsports" and 
        that will no 
        longer be a blocking error

09/09/11 - New issue with Unode 

   If I netrom OUT of my machine to WBAY, come back into it via SCLARA, and then
   try to netrom BACK out to another machine, I get:

       c WSTGAT
       ERROR: connect_to: bind: Cannot assign requested address


Previous Issue with Unode (resolved in an above patch and the packetrig.sh script:
  - If you try to run /usr/sbin/unode locally on the machine and you get:

      $ /usr/sbin/unode
      Segmentation fault (core dumped)

    This means two things.  One, you didn't apply the Unode-local-execution-coredump-fix.diff
    patch from Steven, K6SPI as found in 

    Alternatively, you can work around this issue 
    with putting the following command in your packet startup script.  For 
    this setup, I put the following in the packetrig.sh script for my callsign 
    to username correlation:

              axparms -assoc KI6ZHD dranch

  - The symptoms:

    I have determined that if you run Unode from localhost, the program
    will coredump but it works *fine* via external RF links.  I'm researching
    this but it's not a fatal issue as ax25d will dynamically spawn new
    connections as needed.

    Here is my ongoing troubleshooting for this issue and this will be
    removed once I resolve the issue:


    1. I had to modify the spec files for unode and libax25 to add the 
    following line to be line #1:

       %define debug_packages %{nil}

    and then recompile those RPMs and install them.  Additionally, 
    install the following debug RPMS:
    yum --nogpgcheck --enablerepo=debug install glibc-debuginfo
    yum --nogpgcheck --enablerepo=debug install zlib-debuginfo

    [root@hampacket2 ~]# unode
    Segmentation fault (core dumped)

    [root@hampacket2 ~]# gdb unode core.10482

    GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6)
    Copyright (C) 2010 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later 
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
    and "show warranty" for details.
    This GDB was configured as "x86_64-redhat-linux-gnu".
    For bug reporting instructions, please see:
    Reading symbols from /usr/sbin/unode...(no debugging symbols found)...done.
    [New Thread 10482]
    Missing separate debuginfo for
    Try: yum --disablerepo='*' --enablerepo='*-debuginfo' install /usr/lib/debug/.build-id/ab/f8175ad6ad30041961679c2734a5e38494a951
    Reading symbols from /usr/lib64/libax25.so.0.0.0...Reading symbols from /usr/lib/debug/usr/lib64/libax25.so.0.0.0.debug...done.
    Loaded symbols for /usr/lib64/libax25.so.0.0.0
    Reading symbols from /usr/lib64/libax25io.so.0.0.0...Reading symbols from /usr/lib/debug/usr/lib64/libax25io.so.0.0.0.debug...done.
    Loaded symbols for /usr/lib64/libax25io.so.0.0.0
    Reading symbols from /lib64/libz.so.1.2.3...Reading symbols from /usr/lib/debug/lib64/libz.so.1.2.3.debug...done.
    Loaded symbols for /lib64/libz.so.1.2.3
    Reading symbols from /lib64/libc-2.12.so...Reading symbols from /usr/lib/debug/lib64/libc-2.12.so.debug...done.
    Loaded symbols for /lib64/libc-2.12.so
    Reading symbols from /lib64/ld-2.12.so...Reading symbols from /usr/lib/debug/lib64/ld-2.12.so.debug...done.
    Loaded symbols for /lib64/ld-2.12.so
    Core was generated by `unode'.
    Program terminated with signal 11, Segmentation fault.
    #0  axio_flush (p=0x0) at ax25io.c:168
    168             if (p->zptr) {

    From libax25-0.0.12/ax25io.c available at http://f6bvp.free.fr/logiciels/ax25/libax25-0.0.12-rc2.patched_f6bvp.tar.bz2
    #ifdef HAVE_ZLIB_H
            if (p->zptr) {
                    struct compr_s *z = (struct compr_s *) p->zptr;
                    int ret;
                     * Fail immediately if there has been an error in
                     * compression or decompression.
                    if (z->z_error) {
                            errno = z->z_error;
                            return -1;
    . . . 

To learn more on these node commands, install the software and then issue
the command "man node" once you have it all installed:

LinuxNode - [ legacy ] - Kept for historical reasons:

     The current stock Linuxnode program is called "node" or "axnode" in Ubuntu 
     speak.  This code supposedly has known exploitable security issues - This 
     section is set to be deleted once Unode is proven to work, be superior, etc.

The following are LEGACY nodes for the original "node" package:

Find and click on "node and download the node-0.3.2-1.src.rpm file to 

Now lets install and compile it:
#For Centos6, we need a pretty new version of this package so it won't complain about a 
#  missing kernel_rose.h header file
wget http://kojipkgs.fedoraproject.org//packages/node/0.3.2/10.fc18/src/node-0.3.2-10.fc18.src.rpm

rpm -Uvh /usr/src/redhat/SRPMS/node-0.3.2-4.fc9.src.rpm
cd /usr/src/redhat/SPECS

#For x64 machines
rpmbuild -bb --target=x86_64 node.spec

#For i686 machines
rpmbuild -bb --target=i686 node.spec

And now let's install it

#For x64 machines
rpm -Uvh /usr/src/redhat/RPMS/x86_64/node-0.3.2-10.el6.x86_64.rpm

After that, the /etc/ax25/node.perms file needs to be updated to reflect the
right security settings for your setup.  Next, the /etc/ax25/node.conf file 
needs to be edited to match the /etc/ax25/nrports file.  These files are almost
IDENTICAL to the Unode file settings in the previous section.

10d. - AX.25 Tunneling over the Internet via AXIP or AXUDP

This is a placeholder to get me started but it has NOT been integrated
into the packetrig.sh script as of yet. 

  NOTE:  Depending on your selection of the ax25-apps that you installed,
         you might need to apply a patch or you will get fatal tunneling 
         errors.  This is discussed above in the AX.25 installation section

1. Update /etc/ax25/axports and define the ipct port
   This is currently another filename as /etc/ax25/axports-udp

2. /usr/sbin/kissnetd -p2 &
   - Please record the FIRST port and SECOND port out of that list
     for follow-on commands

3. /usr/sbin/kissattach -l /dev/pts/7 ipct
   - In this example, /dev/pts/7 camesfrom the output of the kissnetd
     command above. is my AMPR IP address and you need
     to put in your OWN IP address that you can get free from your
     local AMPR IP coordinator.

       NOTE: Your kernel MUST have legacy /dev/pty support for this

4. From the output of command in step 2, take the SECOND port given (not the
   first port) and put that into /etc/ax25/ax25ipd.conf for the "device" line

   NOTE: socket ip  - means proto 93
         socked udp - mean UDP defaulting on port 10093

5. run /usr/sbin/ax25ipd

6. Per db0fhn security, you MUST log into Echolink via the same egress IP
   address (easily done via NAT) as this AXUDP connection.

7. Connect to the remote station:

   call ipct db0fhn

Scripting the PTY values:
   1. See the JNOS section of the packetrig.sh script
   2. http://wiki.complete.org/LinuxPacketRadio#ax25ipd-1
   3. Other HAMs have used the "socat" program to script this PTY setup

10e. - LDSPED access to AGW/PE packet API support

As mentioned in the previous SoftTNC section, AGW/PE is a suite of software
that is usually used for it's soundcard based TNC functionality for Windows.
In addition to it's soft-tnc (and hardware based TNC) support, it also comes 
with a suite of programs to interact and troubleshoot with packet.  One of these
tools allows interacting with remote TNCs using the AGW API over TCP/IP network
sockets which many other applications have adopted.  These APIs use a TCP based 
protocol which can be run over various networks, this allows for very flexible 

Most of the Linux packet applications described in this document ONLY work
with Linux's AX.25 stack but one non-Linux application does not: Outpost for 
Windows.  The Outpost application which is described in a different section 
either runs the TNC from "command mode" or directly in t KISS mode.  Either
mode doesn't use Linux's AX.25 stack approach.  Fortunately, Outpost supports 
the AGW API so this section documents how to get this working with LDSPED as
the middle-ware.

  NOTE:   There are two ways to get AGW API support on to Linux:

     #1 - Use a soft-TNC program.  The Direwolf soft-tnc natively supports the AGW

     #2 - Use the LDSPED middleware.  This requires you log into the author's 
          website at http://www.on7lds.net/42/user and register.  Once your account 
          gets authorized, you can goto the Download link and download either
          the pre-compiled binaries or email the developer to get the sources

  Current LDSPED Functionality and compatibility:
  - AX.25 CONNECTED packets INBOUND only (no outbound support yet)

  - supports sending AX.25 UNPROTO packets in and out

  - Remote programs using the AGW API that are confirmed to work include:
    Outpost, UI-View, Xastir, UISS, Paclink, digi_ned.  Please see 
    http://on7lds.net/42/node/10 for a complete list

Getting the LDSPED program is only officially available from the developer's website 
and requires that you setup an account on his website first.  Alternatively, there
seems to be a copy of the code on Github:


I recommend to get the official sources to honor the main developer's wishes so follow 
the prompts at: 


to request and account, an hopefully it will be authorized pretty quickly.  Once
your account is created, go and download the code:

  - ldsped-1.16.tgz    : 32bit pre-compiled program
  - ldsped64-1.16.tgz  : 64bit pre-compiled program

You'll notice there aren't any sources provided.  ON7LDS did this on purpose but 
if you contact him, he was willing to provide the sources.  Until then, try using 
the downloadable 64bit binaries for use with say Centos 6.  If you'd like, I can 
email you my RPMs packages as well.

Compiling LDSPED:

Assuming you have the sources, do the following:

  - Place the source .tgz into /tmp

  - Run the following commands to create a proper .tgz file

       cd /tmp
       mkdir ldsped-1.16
       cd ldsped-1.16
       tar xzvf ../ldsped-sources-1.16.tgz
       cd ..
       tar czvf /usr/src/redhat/SOURCES/ldsped-1.16.tgz ldsped-1.16
       rm -Rf /tmp/ldsped-1.16

  - Next, there are several patches required to make these sources compile on 
    Centos / Fedora systems.  There are enough changes needed for the autoconf
    system that it's just easier for you to just get them from below vs with:

        cd /usr/src/redhat/SOURCES
        wget -r --no-parent -nd -Aldsped* http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES

  - Next, there isn't a .spec file included in the current version of Ldsped 
    (I did send the author my .spec file if he was interested in including it). 
    Go ahead and get my spec file:

        cd /usr/src/redhat/SPECS
        wget -o ldsped.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ldsped.spec

  - Ok, time to compile it up and install it:

        rpmbuild -bb --target=x86_64 ldsped.spec
        rpm -Uvh --force /usr/src/redhat/RPMS/x86_64/ldsped-1.16-1.x86_64.rpm

Configuring Ldsped:
Ok, now lets configure it.  Open up your favorite editor and edit /etc/ax25/ldsped.conf 
but keep in mind that I intend to use LDSPED as AGW API gateway **ONLY**.  I don't 
intend to use any of it's APRS functionality so I disable all of it.  If you do intend 
to use the APRS functions, make the required changes to suit your needs:

   - Ldsped's default R/W port is on port 8001 which doesn't follow norm so lets
     change that.  Find the line "# define packet engine ports" and change the ports
     around to read:

         rw *:8000
         ro *:8001

   - Disable the station status line by putting a # in front of:

         #stationtext $V (check www.on7lds.net)

   - Disable ldsped from sending the "heard traffic" object

         traffic 0

   - Under the "probesendport -1" line, add the following line to disable ldsped from 
     replying from APRS probe packets.  

     NOTE: this following line must show up as the LAST line 

         probe 0

   - Finally, there are a few scripts at the bottom that can be run by sending an
     APRSG query containing the command like "up" or "datum".  If you don't want
     this, go ahead and # those lines out

That's it!  To run it, simply run:

  NOTE: ldsped *must* be run as root today 


The program will instantly run the background and send all logs to /var/log/messages.
If there are issues, kill the running instance of ldsped and re-run it with:

    /usr/sbin/ldsped -dlllll     (that's 5 slower case Ls)

If you are using my packetrig.sh script, any of the profiles that use the ADVAX25
parameters as enabled via which beacon you choose to run will look and run ldsped if 
present and configured.

10f. - AX.25 Packet traffic monitoring

Like any amateur radio transmission, all signals are broadcasted for all to hear
and it's sometimes useful to monitor the packet traffic on a given frequency.
In my packetrig.sh script discussed elsewhere in this document, it starts a 
promiscuous "listen" process in the background that decodes all heard packets 
and logs them to a file named /var/log/listen->date<.log.  At any time, 
you can view, tail, etc. this file to see what's been going on.  One minor issue
is that the listen log doesn't give a full datestamp with it's entries.  I've
added the date-listen-log.sh script which will add a daily stamp which can
help you track things.  To use this script, copy that script into 
/usr/local/sbin and then issue the commands:

      chmod 744 /usr/local/sbin/date-listen-log.sh
      ln -s /usr/local/sbin/date-listen-log.sh /etc/cron.daily/

Pretty useful!

The issue with monitoring this traffic is is that there is a LOT of redundant 
traffic on a channel with beacons, NETROM route updates, etc.  With all that 
"noise", viewing logs can get very tedious.  My solution is the 
filter-packet-listen-logs.sh  that can be found at:


This script needs to be modified by the reader to match your specific local 
stations but it does greatly reduces the amount of repetitive text that you 
probably don't want.  It's structured to filter out individual beacons in one 
section and netrom updates in another section but also supports command line
options to reverse this behavior as well.

FUTURE:  The "listen" process has the ability to color the text to make things
         far more readable but saving this color information into a log file
         makes parsing the data very difficult.  As such, the packetrig.sh
         script disables this coloring.

         I hope to update the filter-packet-listen-logs.sh script to include
         the use of supercat to re-color the output to make the resulting
         filtered text more readable.


10g. - AX.25 Packet troubleshooting

If you ever see output like the following from listen or captured in /var/log/listen* when
various incoming packet signals come into your system:

   EAX25: fm [invalid] to [invalid] via [invalid]* [invalid]* [invalid]* [invalid]* [invalid]* [invalid]* [invalid]* [invalid]* [invalid]* [invalid]* ctl I51115 pid=30 [DAMA] len 1S

I saw this when there was a mismatch of the serial port speed configured in 
/etc/ax25/axports via the serial speed of the TNC.  In this specific scenario, I 
was also seeing that when I would try to make an outgoing AX.25 connected session, 
the "STA" indicator on my Kenwood D710 would stay lit up.  In Kenwood terms, this 
means that data was in the TNC's buffer but it wasn't being sent.  The indicator would
say on on until I cancelled the connection attept.  Fixing the serial port speed in axports 
file to match up with the speed the TNC was expecting fixed the issue.

AX.25 CHOKE messages:
       When a remote station tries to connect to your machine yet they "busy" messages
       and the AX.25 packet decodes saying things like "CHOKE", this means your 
       /etc/ax25/ax25d.conf file doesn't know what to do with this request
       for the specific PROTOCOL.  To be clear, AX.25 connections use 
       the square brackets [], Netrom uses >< signs, and ROSE uses
       {}.  This problem was messing with me for the LONGEST time!

        When a remote station tries to connect to your machine yet the session
        connects and then immediately disconnects, this most likely means
        that the binary program (node, unode, etc.) as specified in the 
        /etc/ax25/ax25d.conf file is improperly configured or isn't there.

To confirm the network is listening, try the following commands:

   /sbin/ifconfig :: Shows all interfaces (I've removed my internal
                     Ethernet ones
   ax0       Link encap:AMPR AX.25  HWaddr KI6ZHD
             inet addr:  Bcast:  Mask:
             UP BROADCAST RUNNING  MTU:128  Metric:1
             RX packets:16 errors:0 dropped:0 overruns:0 frame:0
             TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:10
             RX bytes:1273 (1.2 KiB)  TX bytes:246 (246.0 b)

   nr0       Link encap:AMPR NET/ROM  HWaddr KI6ZHD-14
             inet addr:  Mask:
             UP RUNNING NOARP  MTU:236  Metric:1
             RX packets:0 errors:0 dropped:0 overruns:0 frame:0
             TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0
             RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

   nr1       Link encap:AMPR NET/ROM  HWaddr KI6ZHD-1
             inet addr:  Mask:
             UP RUNNING NOARP  MTU:236  Metric:1
             RX packets:0 errors:0 dropped:0 overruns:0 frame:0
             TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0
             RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

   nr2       Link encap:AMPR NET/ROM  HWaddr KI6ZHD-5
             inet addr:  Mask:
             UP RUNNING NOARP  MTU:236  Metric:1
             RX packets:0 errors:0 dropped:0 overruns:0 frame:0
             TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0
             RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

   To confirm that everything in /etc/ax25/axports is bound, the best I've been
   able to find is:

       ps aux | grep kissattach

     NOTE:  If anyone is aware of a way to find this via /proc or /sys, I'd
            love to hear from you

   Show all active AX.25 interfaces if everything is running including 

   netstat -A ax25 -an
   Active AX.25 sockets
   Dest       Source     Device  State        Vr/Vs    Send-Q  Recv-Q
   *          KI6ZHD-4   ax0     LISTENING    000/000  0       0
   *          KI6ZHD-3   ax0     LISTENING    000/000  0       0
   *          KI6ZHD-2   ax0     LISTENING    000/000  0       0
   *          KI6ZHD-1   ax0     LISTENING    000/000  0       0
   *          KI6ZHD-0   ax0     LISTENING    000/000  0       0
   *          ZHDNOD-0   ax0     LISTENING    000/000  0       0
   *          KI6ZHD-5   ax0     LISTENING    000/000  0       0

   Show all active NetROM connections (if any):
     netstat -A netrom -an :: Shows all active NetROM connections
   Active NET/ROM sockets
   User       Dest       Source     Device  State        Vr/Vs    Send-Q  Recv-Q

   How to see the heard netrom table:

    netstat -A netrom -rn
   Kernel NET/ROM routing table
   Destination  Mnemonic  Quality  Neighbour  Iface


   route -A netrom
   Kernel NET/ROM routing table
   Destination  Mnemonic  Quality  Neighbour  Iface
   WA7DG-4      ROSE      108      N6ZX-5     ax0
   WA6YNG-1     RDG       108      N6ZX-5     ax0
   KI6NCU-5     PONDER    107      N6ZX-5     ax0
   KG6WOO-5     PLUMAS    134      N6ZX-5     ax0
   WA6TOW-1     PAC       107      N6ZX-5     ax0
   WW8L-3       OVALE      90      N6ZX-5     ax0
   WB6YNM-11    MOC       143      N6ZX-5     ax0
   KF6FPU-5     LIVER     143      N6ZX-5     ax0
   KI6UDZ-7     FCITY     143      N6ZX-5     ax0
   W6PJD-3      ELDOR     107      N6ZX-5     ax0
   W6JEX-5      CORN      108      N6ZX-5     ax0
   WG6D-6       CAM91     108      N6ZX-5     ax0
   WG6D-8       CAM05     108      N6ZX-5     ax0
   K7WWA-8      CAHTO     107      N6ZX-5     ax0
   K6IXA-5      BULN      143      N6ZX-5     ax0
   N6KRV-5      BRKNRG    107      N6ZX-5     ax0
   K6JAC-4      BERRY     144      N6ZX-5     ax0
   KF6DQU-9     BANNER    119      N6ZX-5     ax0
   N6ZX-5       WBAY      190      N6ZX-5     ax0

   Creating new netrom routes:
   nrparms -routes

   Creating remote IP routes via netrom:
   route add nr0

To view the remotely learned NetROM routes, do:

   cat /proc/net/nr :: Show all established netrom connections
   user_addr dest_node src_node  dev    my  your  st  vs  vr  va    t1     t2     t4      idle   n2  wnd Snd-Q Rcv-Q inode

   show locally heard NetROM neighbors
      cat /proc/net/nr_neigh
   addr  callsign  dev  qual lock count failed digipeaters
   00003 WA6TOW-1  ax0   250    0     1      0
   00002 N6ZX-5    ax0   250    0    26      0
   00001 K6JAC-4   ax0   250    0    40      0

   Shows all **learned**** NetROM routes from distant nodes:

   netstat -A netrom an 
   cat /proc/net/nr_nodes

       Quality >192 is exceptionally good. Good quality is 192. Poor quality is <120.
       Zero quality means that the node can be heard but cannot be connected to reliably.
       The obs number of additional nodes that can be connected from that destination node.
   callsign  mnemonic w n qual obs neigh qual obs neigh qual obs neigh
   WA7DG-4   ROSE     1 1  143   6 00002
   WA6YNG-1  RDG      1 1  143   6 00002
   KG6WOO-5  PLUMAS   1 1  176   6 00002
   WD6EZC-5  PINOLE   1 1  188   6 00002
   WA6TOW-1  PAC      1 2  250   6 00003  141   6 00002
   K7URY-1   BLKMND   1 1  140   6 00001
   K6LRC-2   ALM      1 1  132   6 00001
   W6HMT-7   AUKUM    1 2  176   6 00002  176   6 00001
   W7TA-4    RNO      1 1  141   6 00001
   WX7RNO-2  NWSCHT   1 1  140   6 00001
   W7DED-4   YRGTN    1 2  156   6 00001  118   6 00002
   KE7CRZ-7  FERNLY   1 1  141   6 00001
   N6ZX-5    WBAY     1 2  250   6 00002  188   6 00001
   K6TUO-5   TUO      1 2  188   6 00002  188   6 00001
   WX7RNO-3  NWSBBS   1 1  140   6 00001
   KF6DQU-4  ROUGH    1 2  188   6 00002  188   6 00001
   N6KRV-5   BRKNRG   1 2  142   6 00001  141   6 00002
   WX7RNO-4  NWSRNO   1 1  141   6 00001
   WB6YNM-11 MOC      1 2  188   6 00002  188   6 00001
   KF6FPU-5  LIVER    1 2  188   6 00002  156   6 00001
   K6LRC-1   LASSEN   1 1  141   6 00001
   KJ6IX-10  IXRMS    1 1  140   6 00001
   KJ6IX-2   IXCHT    1 1  140   6 00001
   KJ6IX-3   IXBBS    1 1  140   6 00001
   KJ6IX-4   KMEV     1 1  141   6 00001
   KG6BAJ-2  GVCITY   1 2  188   6 00001  186   6 00002
   N6SGR-1   FST      1 2  188   6 00001  143   6 00002
   KE7CRZ-10 CRZRMS   1 1  140   6 00001
   W6TUK-4   TUCK     1 2  143   6 00002  142   6 00001
   W6PJD-3   ELDOR    1 2  142   6 00001  141   6 00002
   W7DEM-10  DEMRMS   1 1  140   6 00001
   W7DEM-2   DEMCHT   1 1  140   6 00001
   W7DEM-3   DEMBBS   1 1  140   6 00001
   W7DEM-4   CSN      1 1  141   6 00001
   KE7CRZ-2  CRZCHA   1 1  140   6 00001
   KE7CRZ-1  CRZBBS   1 1  140   6 00001
   W6JEX-5   CORN     1 2  188   6 00001  143   6 00002
   WG6D-6    CAM91    1 2  187   6 00001  142   6 00002
   WG6D-8    CAM05    1 2  188   6 00001  143   6 00002
   K7WWA-8   CAHTO    1 2  186   6 00001  141   6 00002
   K6IXA-5   BULN     1 2  188   6 00002  188   6 00001
   KF6DQU-9  BANNER   1 2  188   6 00001  156   6 00002
   W6SV-6    WKRBSN   1 2  142   6 00001  141   6 00002
   KI6UDZ-7  FCITY    1 2  188   6 00002  141   6 00001
   K6JAC-4   BERRY    1 2  250   6 00001  189   6 00002

10h. - Other AX.25 tools

Other interesting AX.25 tools:

   - KISS proxy : enable different TCP-KISS applications to hear eachother's KSS packets

11. - Linpac - Advanced HF/VHF/UHF AX.25 packet terminal and PBBS

The main window where you can switch between SSIDs using the F-keys, see live decodes, etc:

Linpac is a great command-line packet terminal program using Linux's native AX.25
stack using an AX.25 TNCS in KISS mode.  It seems to both emulate and surpass older 
premium DOS programs like the KaGold program, etc.  

   Older Ka-Gold review:  http://www.interflex.com/private/review1.htm

Though you can use Linux's basic AX25 "call" program to connect to remote packet 
nodes, etc., Linpac offers quite a bit more:

  - It gives you a keyboard to keyboard interface for MULTIPLE people 
    connecting to your station at the same time from one user interface

  - allows for 8 simultaneous inbound or outbound connections 

  - notifies you when people connect to you

  - Supports a very easy to use UNPROTO mode

  - Offers a configurable three views to show received, sent, and promiscuous AX.25 decodes
In the above screen capture:

   - The placement and color of each screen area is configurable 

   - The main typing INPUT area is at the top (black text on a green background)

   - The blue line is the status of the current connection - showing my callsign, 
     # of ACKed and NON-ACKed packets, etc

   - The main window color codes status messages (light blue), TX text (red), and 
     RX text (green)

   - The next line is the connection line - the "1:" corresponds to the QSO or 
     "stream" running on the F1 key.  There aren't any current QSOs on F2, F3, 
     F4, F5, F6, F7, or F8 but yes, you can have up to eight simultaneous QSOs!  

   - There is also the F10 screen which is used for sending UNPROTO or UI packets

   - The bottom screen is the AX.25 monitor showing all TX packets (red), RX's 
     packet frame data (green), and the RX payload (light blue) for the current
Able to view your inbox of incoming packet messages:
In the above screen capture:

   - Here on my LOCAL machine (UI is not currently available for remote users), 
     you can see the INBOX and all of the received messages
Able to READ but not reply to messages (this will be fixed..):
In the above screen capture:

   - Here you can read the various messages and if configured, send a reply

11a. - Linpac - Compiling and installing the program

Ok, let's get down to downloading and compiling Linpac:

  | There are THREE versions of Linpac available today:                     |
  |                                                                         |
  | Develop Branch                                                          |
  | 0.27     - Up to date, development branch that has all fixes - should   |
  |            stable                                                       |
  |                                                                         |
  | Master Branch                                                           |
  | 0.25     - Up to date, stable Ncurses UI - Current Recommended release  |
  |                                                                         |
  | Alpha Branch; not Active                                                |
  | 1.0pre4  - a split client/server system with the Ncurses style UI       |
  |            from the previous Linpac but also a Java-based client UI     |
  |            This version is currently Broken but is being repaired.      |
  |            It's not currently covered in this document yet              |

  12/10/17 - Linpac 0.25 has been posted
     First wave of lowered the CPU load caused by Linpac's original design but
     more work is needed.  Includes fixes to resolve Segfault issues found in 
     very new versions of Fedora and Debian.  Includes other code-related
     clean ups

  11/19/15: Linpac 0.24 has been posted
     The new release is out has many compile fixes, some bug fixes, etc.
     and is the new version being added into the Debian repos

    cd /usr/src/redhat/SOURCES
    wget -O linpac-0.25.tar.gz \

  | NOTE: Supporting local messaging                                           |
  |                                                                            |
  |       Linpac can integrate with the axmail-utils package that can be found |
  |       at https://sourceforge.net/projects/ax25mail/ .  Linpac does NOT     |
  |       look / emulate a classic TNC's prompting or PBBS simple messaging.   |
  |       This program currently is designed to forward (proxy) messages       |
  |       to/from a FBB style BBS but it is able to receive local messages and |
  |       display them for the local operator.  It does NOT support letting    |
  |       remote HAMs pick up their messages at the moment.                    |
  |                                                                            |
  |       See the "AX.25 Packet Programs" section for more messaging tool      |
  |       options                                                              |

  Next, download the RPM SPEC file at:

    cd /usr/src/redhat/SPECS
    wget -O linpac-0.25.spec \

  | NOTE #1:  Issue with the ./configure script                          |
  |                                                                      |
  |         It seems linpac is hard coded to "listen" and not say        |
  |         finding Debian/Ubuntu's naming convention of "axlisten".  n  |
  |         You can fix this in Linpac's src/constants.h file or more    |
  |         simply create a symlink pointing to the ax listen binary to  |
  |         listen:                                                      |
  |                 sudo ln -s /usr/bin/axlisten /usr/bin/listen         | 

  | NOTE #2 - TBD: Probably obsolete with 0.21 - researching             |
  |                                                                      |
  | NOTE #1:  Issue with the ./configure script                          |
  |                                                                      |
  |         In the user's Linpac directory, the bin/ directory creates   |
  |         possibly wrong symlinks to /usr/local/share/linpac/bin       |
  |         You can fix this with the following command:                 |
  |                                                                      |
  |           ln -s /usr/local/share/linpac /usr/share/linpac            |

  Ok, now compile up the RPM:

     #for 64bit systems
     rpmbuild -bb --target=x86_64 linpac-0.25.spec

     #for 32bit systems
     rpmbuild -bb --target=i686 linpac-0.25.spec

  And now install it!

     #for 64bit systems
     rpm -ivh /usr/src/redhat/RPMS/x86_64/LinPac-0.25-1.x86_64.rpm

  A few more required steps:

   #To properly support local messaging, do the following as root 
   #  This will be eventually done via the RPM installer)
   mkdir /var/ax25/mail
   chmod 777 /var/ax25/mail

   #Future sections to expand on
     To support full FBB mail forwarding as well as support the :mail feature, 
     you must compile and install ax25mail-utils first

11b. - Linpac - Configuring the packet terminal program

Before running Linpac for the first time, there are a few things to consider:

    Fixups before running
       -  Fixme:  Before starting Linpac as a normal user (not root), you need 
                  to allow for users to create Lock files.  To do this, run as root:

                  touch /var/lock/LinPac.0
                  chmod 666 /var/lock/LinPac.0

   Choosing what user to run Linpac as / Traffic Monitoring
       -  Linpac has the ability to show all real-time traffic on a given
          packet frequency in a section of the window.  To show this real time
          traffic, you either need to:

             - Run the ax25spyd daemon as root as described in a previous 
               section.  If ax25spyd is running when Linpac is started, all Linpac
               configuration files are put into that user's home directory and this
               non-root users can see the traffic data.

               | NOTE: For general Linux security reasons, it's recommended to |
               |       use the ax25spyd method and NOT run Linpac as the root  |
               |       user.                                                   |

             -  Alternative #1: you can make the "listen" binary program SUID root 
                so that it can run while leaving the calling program like Linpac 
                running as a non-root user.  To do this, you would do:

                   sudo chmod 4755 /usr/bin/listen

             -  Alternative #2: you can run Linpac from the "root" user, this will 
                put all Linpac configuration files in the /root directory and 
                then spawn a "listen" process as the root user process to monitor 
                the traffic.  This listen process would then talk to the SOCK_PACKET 
                socket to get the traffic.

                NOTE: If you don't have ax25spyd running as the root user OR you 
                      don't make the "listen" process SUID root, *or* start linpac 
                      NOT as the root user, you:

                      -  Won't see the real-time packet traffic.  Instead, you'll 
                         see the error:

                                  socket: Operation not permitted

                      - You will not hear the connection and disconnection 
                        PC beeps

    Starting up Linpac for the first time

       - As above, you need to choose if you're going to run Linpac as a regular
         user as root.  Once decided, become that user and prepare to run Linpac
         for the first time.  

       -  When you first run Linpac on the local machine, it creates a directory in 
          the process owner (root or regular user's) home directory called 
          "LinPac".  In this directory, Linpac copies over all kinds of default 
          files, etc. into their $HOME/Linpac directory.

       - Now that the various skeleton files have all be copied over, issue 
         the command :sys to exit Linpac and return to the system.  Now you 
         will need to edit the config files

    Mail Forwarding
       *  NOTE:  This section is NOT complete and there might be some missing steps.
                 If you need help, please contact me

       -  Linpac has a mail forwarding system built into it where it can do bulk
          uploads and downloads of messages from a different BBS.  Once fetched,
          you can read and reply to messages all offline while not connected to
          any station.  Once done, you and tell Linpac to send the messages and
          get any new ones.  

             NOTE: This is NOT like a simple PBBS as found on TNC2/KPC3/etc TNCs  

          If you want to use this feature, you need to have followed the previous
          section's instructions to get ax25mail-utils and ulistd installed.  Once 
          installed, need to do the following to get Linpac forwarding working.

          NOTE:  It's good to know about the purpose of the following dirs:

                 $HOME/LinPac/mail : where local messages are stored
                 /var/ax25/ulistd  : where ?message lists? are stored
                 /var/ax25/mail    : where message bulletins are stored

          1. Choose a remote BBS that's on the same frequency as your packet 
             station.  Today, it seems Linpac supports FBB and TNOS as valid
             remote BBS types but there might be more.  I hope to add simple
             KPC3 PBBS forwarding support into Linpac in the future.

          2. Configure this station in the homeuser's Linpac/station.data file.
             For example, I'm using the K6FB-1 BBS:

              NAME=K6FB PBBS

    Linpac main configuration

       - Linpac is configured by the $HOME/LinPac/macro/init.mac file.  In this file, 
         you need to make several changes to fit your specific environment.  You
         need to put in your proper:

            - AX.25 port name
            - callsigns and SSID to F-key mapping
            - unproto callsign and optional path
            - optional BBS forwarding call and ssid

           | NOTE:  The Hampacket "packetrig.sh" script automatically     |
           |        switches Linpac configs based upon how it's started   |
           |        to select the correct ax.25 device, etc.              |

           ;;the default AX25 device name.  For my packetrig.sh script with
           ;; VHF/UHF, it's named "d710"
           port d710

           ;;Set the default terminal type to ANSI
           term ansi

           ;; Linpac's primary display view
           ;; I prefer the following look where the type-in area is at the TOP
           ;; The status bar of the connection, AX.25 stats, etc SECOND
           ;; The area where you read the incoming text from the remote station THIRD
           ;; The connection bar that shows the different connected stations via F-key FOURTH
           ;; A large AX25 monitoring window at the bottom
           ;; NOTE: The order that these lines are enter in MATTERS.  If you 
           ;;       want a different layout, reorder the lines and restart
           ;;       linpac
           statline 5
           chnline 30
           infoline 5
           ;;With LinPac, each F-key in a Linux terminal can be a different
           ;; connection and each on can have their unique SSID if you'd like.
           ;; Notice here that I have KI6ZHD (that's SSID -0) listed twice.  Linpac
           ;; allows to have two DIFFERENT remote callsigns connected to the same 
           ;; local -0 SSID
           ;; Note : the F10 key is a dedicated screen where ALL UNPROTO can be sent
           ;;        using the configured digi path
           ;; Here in Northern California, I do NOT configure the -5 SSID as that's 
           ;; used for the UrnoNetrom NODE as described in the NetRom section
           mycall@1 KI6ZHD
           mycall@2 KI6ZHD
           mycall@3 KI6ZHD-1
           mycall@4 KI6ZHD-1

           ;;For unproto traffic, address it to the proper source and 
           ;;destination -- Be sure to change this to your callsign
           unsrc KI6ZHD

           ;;For basic one-hop UNPROTO communications, don't use any digipeated paths
           ;; undest INFO

           ;;For multi-hop UNPROTO communications, you need to use digipeated paths.
           ;;Assuming you enabled the digipeat patch from above AND you live in the 
           ;; South BayArea, California, I use the following path:

           ;; Other settings - Allow the system to make a bell sound when remote users connect
           ;;                  Most modern PCs now have this PC speaker output wired to the soundcard
           ;;                  speakers but it requires your soundcard mixer settings to have the 
           ;;                  "Speaker" and "Beep" outputs both unmuted and at a high audio level.
           ;;                  It seems the volume setting for Speaker doesn't change the levels but 
           ;;                  the "Beep" levels do work.  In very new kernels, they seem to need a new 
           ;;                  "Loopback mixing" feature ENABLED to hear the sounds (it's off by default).
           ;;                  To test these PC speaker or Beep sounds, run: sudo /usr/local/share/linpac/bin/bell
           ;;                  Yes, root level permissions are required to play sounds though 
           ;;                  the PC speaker on modern kernels
           cbell on
           knax on
           ;; Required to be on or linpac won't accept any // commands from the remote user
           remote on
           infolevel 1

           ;; Default QRG - A comment for remote stations - set whatever is your primary packet frequency
           set QRG@0 "145.050 MHz"

           ;; Default set of commands to let users run - EVERY command must be in ALLCAPS 
           ;; and if you want to allow lowercase commands, they also need to be present or
           ;; aliased in the macros/commands file

           ;;Optional mail forwarding
           ;; Path to home BBS - the port name is REQUIRED
           ;;The syntax is:
           ;; The ax25 port name as shown above, the @0 is Linpac's reserved F-key connection number, the 
           ;; BBS name and it's proper SSID, and any additional digis required to reach the destination
           ;; to get to said BBS
           set HOME_BBS@0 "d710:K6FB-2"

           ;; HOME_ADDR must be assigned or you won't be prompted for a subject
           ;; This example reflects using K6FB found in Northern California, CA, USA
           set HOME_ADDR "K6FB.#NCA.CA.USA.NOAM"

    Final Tweaks
       - It's important to recognize that ANY commands that you want remote users to
         run must be defined in ALL CAPS the init.mac "DEF_RCMD" file.   For HamPacket
         packetrig.sh script users, please be sure to update all your macro/init.mac* files to
         contain the required changes.
       - By default, Linpac supports commands in UPPER case commands ONLY.  To support the 
         lowercase version of the same commands, they can be aliased to the UPPER-CASE 
         commands in the [linpac user]/LinPac/macro/commands file.  If the lowercase command
         is not aliased but the specific .mac file exists in the macro/ directory, those
         macros will run but ONLY if the command's "case" matches the filename's CASE.  
         Putting it another way, the "sp.mac" macro would work for "//sp" but won't 
         work for "//SP".  For a base system that you want to accept messages on, I 
         recommend to edit the following file and add these two lines to accept "Send 
         Private" and "Send Bulletin" in upper or lower case:

         sb      SB
         sp      SP

         My complete file is:
         activity       Activity
         comp           COMP
         connect        Connect
         conv           CONVers
         help           Help
         info           Info
         init           INIT
         quit           Quit
         users          Users
         users          CStatus
         pw             PW
         sb             SB
         sp             SP

    Site-Wide Configuration changes

      Menu Prompts
       -  I recommend you edit the $HOME/LinPac/macro/info.mac
          file as root and populate it with all the interesting info about
          your specific packet setup.

       -  Linpac has the ability to do simple messaging but the default help
          file doesn't clearly mention this!  To make sure users can know about 
          this, edit the /usr/local/share/linpac/macro/help.mac as root and insert
          the lines:

             //SP <address> [<subject>] - write a Private message to user [optional subject]
             //SB <address> [<subject>] - write a Bulletin message to everyone [optional subject]

       - Any other commands you enabled via the macro/init.mac "DEF_RCMD" variable 
         should also be added to the macro/help.mac file as well for good ease of
         use.  Here is my help.mac file:

                  LinPac - available commands

           //Activity                 - print the time since last operator response
           //Bell                     - call operator by acoustic signal
           //COMPress <on,off>        - Turn on Huffman compression - your client must
                                        support this to work
           //Connect [port:]call [digi [digi...]] - connect to remote stations :
                                        try connecting and using node: KI6ZHD-5
           //CStatus                  - list of connected stations
           //DELMSG <message_number>  - Mark the message for delete
           //Disconnect               - end the QSO immediately
           //Echo <text>              - send the text back
           //GETMsg <numbers>         - Reads the messages from BBS
           //Help                     - this help
           //Info                     - print station info
           //MHeard                   - list of heard stations
           //Name <name>              - store your name
           //Quit                     - normal end of QSO
           //Read <filename>          - send text file
           //RBin <filename>          - send binary file
           //RPrg <filename>          - send the file using autobin protocol
           //RTt                      - determine round trip time
           //SENDFile [p|b] <file> <address> [<num_messages>] -
                        This command takes a binary file, splits the file to num_messages
                        parts using 7plus and creates a separate message for each part.
           //SP <address> [<subject>] - write a Private message to user [optional subject]
           //SB <address> [<subject>] - write a Bulletin message to everyone [optional subject]
           //Users                    - list of connected stations
           //VERsion                  - print the version of LinPac
           //Write <filename>         - Start writing to the text file (stop with "//W off")
           //WBin <filename>          - Start writing to the binary file
                                        (stop with "//WBin off")
           //YPUT <filename>          - send the file using YAPP protocol

11c. - Linpac - Using the program

The generatal operation of Linpac is well covered in the included Linpac manual.html found 
in /usr/share/doc/linpac/manual.html .  I encourage you to read it and probably read it a 
few times as there is a lot to absorb there.  There are also a lot of capabilities in 
Linpac that are either not detailed very well or not mentioned at all manual:

   1. The same SSID assigned to different F-keys to allow simultaneous chats as long
      as those connections are to DIFFERENT remote callsigns

   2. Different axport define ports assigned to different F-keys

   3. Turning on COMP or Huffman compression to another Linpac station GREATLY speeds
      up I/O.  This is the same basic compression that is used in Winlink connections.

   4. Adding in the optional TELNET module let's you remotely access Linpac via a 
      network TELNET session.  This is an alternative to using Screen.

   5. You can make remote connections via digipeaters with syntax like:

         :c KJ6NKR-1 V KLPRC3 KBETH TAH0E

Since Linpac is all in Linux, everything is hackable to do other useful things.  For example,
here is a way to send email or SMS notifications when someone leaves you a Linpac message:

    Email notification of packet messages
    I've added the linpac-check-msgs.sh script to the Compressed archive of 
    hampacket-CentosDigitalModes document as well as directly here:


    This will send you an email or it can send you an SMS text message when you 
    get a new packet message.  You will need the "mutt" email program installed 
    to use this script and you will need to edit this file to reflect your own 
    personal email address (or email to SMS gateway email address).  

    To activate this notification say every hour, do the following as ROOT:

       chmod 700 /usr/local/sbin/linpac-check-msgs.sh
       ln -s /usr/local/sbin/linpac-check-msgs.sh /etc/cron.hourly

Other Linpac Guides:
You can find another short Linpac setup doc here (very rare to find Linpac docs on
the Internet):


If you know of any or if you're a Linpac user, please send me an email to tell me
as such!

12. - Fldigi - Fldigi - Compiling the program for HF digital modes

FLdigi is a free HF Digital mode program that supports most of the digital 
modes including BPSK31, RTTY, Olivia, CW, and many many other modes.  It runs 
on Linux, Windows, and Apple OSX and even supports being used as a TNC for using
it's modems with Linux's AX.25 stack.  Very cool!  

Please understand that this is a BIG section and requires lots of dependencies
to get everything in place before building.   Be patient, follow these steps 
and not only will it work, but it's very worth it!

This is the main window for making QSOs, seeing decodes of other signals, running macros, etc:

NOTE on Logging: ---------------- Fldigi supports exporting it's QSO logs to both EQSL and LOTW. In addition to this native support, you can use external logging programs such as Xlog to automatically upload your logs to LOTW, EQSL, etc. If you want to use Xlog, you must be running Fldigi 3.20.21 or newer Notes about Fldigi on centos5 ----------------------------- Performance ----------- I have seen where fldigi running on slower machines (1.7Ghz Pentium-M) can have the annoying problem where if Firefox or Chrome is open and is specifically running a web page loaded with JavaScript. A big offender ironically seems to be QRZ.com: a. Fldigi can get stuck when you try to transmit. The program becomes very slow and it eventually asserts PTT but it won't start transmitting any digital tones, etc. You can hit the ESC to abort the TX but it can take 5-10 seconds to release PTT. The ONLY solution to solve this after it starts happening is to first shutdown FF/Chrome and then completely restart Fldigi. Fldigi 3.20.x does NOT fix this. Contesting ---------- If you ever want to try contesting with Fldigi, make sure you have Configure --> Contest --> Duplicate Check : ON with at least the MODE box checked. New FLdigi compile time features ------------------------------- New behind-the-scenes compile-time features are added into fldigi all the time so I recommend you manually run it's configure script via "./configure" and not just install the newest binaries to see what new options have been added. If you want something that might be disabled by default, you'll need to modify the SPEC file or manually compile it to reflect the change. Ok, let's get down to it! +-----------------------------------------------------------------------+ | NOTE: | | The following example assumes Fldigi 3.21.36 and Centos6 but Centos5 | | is specifically called out as well | +-----------------------------------------------------------------------+ Download the sources -------------------- # NOTE: # As of 3.21.35, Fldigi now supports more modern Fltk tool kits. I do # NOT recommend you install older versions of the Fltk toolkits cd /usr/src/redhat/SOURCES # In this example, I show getting version 4.0.2. I recommend you change the # version number to match the newest release version of Fldigi available # As of 4/8/20, Fldigi is at version 4.1.11: # wget -O fldigi-4.0.2.tar.gz https://downloads.sourceforge.net/project/fldigi/fldigi/fldigi-4.0.2.tar.gz It's recommended to download and use my TrinityOS SPEC file (which enables the kitchen sink for Fldigi). cd /usr/src/redhat/SPECS wget -O fldigi.spec \ http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/fldigi.spec +----------------------------------------------------------------------------+ | If you choose use my rpm SPEC file (recommended), you will *STILL NEED* to | | follow all the below dependency steps to ensure your machine has the | | additional required packages to both compile and install Fldigi. | +----------------------------------------------------------------------------+ Alternatively, you can follow the below steps to manually build your own without doing the final compile/install via RPMs. You'll still need to fill in the various requirements at "configure" time and compile, install, and configure Fldigi itself at the end of this section. ------------------------------------------------ Building up your own SPEC file (not recommended) ------------------------------------------------ ** This section is only useful to understand how I started to build my Fldigi ** SPEC file. There is little value in this section otherwise than maybe ** comparing what I'm doing to your build creation file (SPEC, deb, etc) - The last fedora package I saw was using Fldigi 3.10 which very very old as 3.12.5 was current at that time. Grabbing the Fedora SPEC file still helped a lot to start things off - Using the Fedora fldigi.spec file has non-identified errors and will die with errors like: -- error: Installed (but unpackaged) file(s) found: /usr/share/man/man1/fldigi.1.gz to fix this, find the line -- %{_datadir}/pixmaps/* -- and add the following under it (flarq is new to 3.12.4) -- %{_datadir}/applications/flarq.desktop %{_mandir}/man1/fldigi.1.gz %{_mandir}/man1/flarq.1.gz -- to improve the build, replace the configure line with: -- %configure --enable-optimizations=native make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" -- NOTE: Changes between my older Fldigi 3.12.5 for Centos 5 and the and the newer Fldigi 3.20.11 for Centos 6 notes: 1. In the 3.12.5 build notes, I used %configure --enable-optimizations=native which seems to throw warnings that the resulting code would be using legacy i80387 FPU instructions. It turns out this was an issue with the older Centos5 compilers and using "native" is both recommended and enabled at the beginning of this document and via the /etc/rpmrc file. 2. Starting in the 3.20.11 notes, I've added support for the xmlrpc system which is used by the excellent Flrig rig control program but Hamlib works as well. 3. LEGACY (no longer needed): The old Fldigi 3.20.11 now REQUIRES the obsolete and deprecated fltk 1.1.9 toolkit though the Fldigi docs say it should work with 1.1.7. It's not true. ------------------------------------------------------------------------ NOTE: If you're upgrading from an older version of Fldigi, make sure to : 1. make a copy of the old SPEC file, for me I do: cp /usr/src/redhat/SPECS/fldigi.spec \ /usr/src/redhat/SPECS/Old/fldigi.spec 2. update the SPEC file to: a. use the newer source tarball version b. update the changelog section to reflect your changes Next, regardless of using my SPEC file your you building your own, make sure the version number reflects the current version of Fldigi

12a. - Fldigi - Dependencies step #1

Fldigi Dependencies : All versions of Centos - 6 and 5

Regardless of building Fldigi via RPM spec files or doing everything
from source, the Fldigi build requires many other programs and libraries 
(RPMs) to allow proper compiling and enabling all features installed:

   #Installing libXt-devel is recommended and needed before building Fltk
      yum install libXt-devel   
         # NOTE: Installing this may require 7+ other RPMs

   #Installing libasound2 is recommended and needed before building Fltk
   #  I don't know why this isn't called libasound2 on Centos but Centos uses this different name
      yum install alsa-lib alsa-lib-devel

   #A few others to make sure you have installed
      yum install libX11-devel
      yum install autoconf
      yum install mesa-libGLU-devel

   #fltk - Fast Light Toolkit
      Fldigi (on Centos6 or Centos5) requires a *newer* version of fltk 
      than what EPEL and Rpmforge offers.  To fix this, you have to 
      compile a new version yourself.

       | NOTE: this might change over time so it's recommended to try Yum   |
       |       to see if they now offer fltk-1.3.0 or newer.  If not,       |
       |       follow this next section.                                    |

        Centos6 specific:
        # We'll download Fedora16's old package as a starting point
        cd /usr/src/redhat/SRPMS
        wget -O fltk-1.3.0-1.fc16.src.rpm \

        # Next, let's get the current code version: 1.3.4
        cd /usr/src/redhat/SOURCES
        wget http://fltk.org/pub/fltk/1.3.4/fltk-1.3.4-2-source.tar.gz

        # Next, you noticed the version name of 1.3.4-2.  RPM reserves the use of dashes in the filenames
        # for it's own use so this means we need to change it first
        cd /usr/src/redhat/BUILD
        tar xzvf /usr/src/redhat/SOURCES/fltk-1.3.4-2-source.tar.gz
        mv fltk-1.3.4-2 fltk-
        tar czvf fltk- fltk-

        #Now lets' clean up the old directory and move the new archive to the SOURCES dir
        mv fltk- ../SOURCES/
        rm -Rf fltk-

        #Ok, now let's install the older source SRPM to get it's SPEC file
        rpm -ivh fltk-1.3.0-1.fc16.src.rpm

        #Next, we need to install build dependency RPMs:
        yum install libjpeg-devel

        #Now we need to update the SPEC file to reflect the new name and any other changes:
        cd /usr/src/redhat/SPECS
        vim fltk.spec

           First change:
           #change the line
           Version:        1.3.0

           Second change:
           #find lines reflecting the definition of an old patches needed for fktk-1.3.0 which 
           # are now fixed in this newer version:
           Patch1:        fltk-1.1.9-fltk_config.patch
           Patch3:        fltk-1.1.x-r5750-undefined.patch
           Patch5:         fltk-1.1.8-fluid_desktop.patch

           #and comment them out so it looks like
           #Patch1:        fltk-1.1.9-fltk_config.patch
           #Patch3:        fltk-1.1.x-r5750-undefined.patch
           #Patch5:         fltk-1.1.8-fluid_desktop.patch

           Third change
           # In fltk, there seems to be a missing reference to a file that's of a different 
           #name, to resolve this, find the line:
           make install install-desktop DESTDIR=$RPM_BUILD_ROOT

           # replace it with the following lines
           make install DESTDIR=$RPM_BUILD_ROOT

           #dranch: hack to work around missing x-fluid.desktop file issue
           cp fluid/fluid.desktop fluid/x-fluid.desktop

           make install-desktop DESTDIR=$RPM_BUILD_ROOT

           #Fourth change
           # scroll down and find the line that activates that patch and also comment that out
           %patch1 -p1 -b .fltk_config
           %patch3 -p1 -b .undefined
           %patch5 -p1 -b .fluid_desktop

           #and comment it out so it looks like
           #%patch1 -p1 -b .fltk_config
           #%patch3 -p1 -b .undefined
           #%patch5 -p1 -b .fluid_desktop
           #Fifth h change
           # scroll down to the bottom of the file and add a new update line

           * Sat Mar 10 2018 David Ranch  1.3.4-2
           - New release

        Save your changes to the new fltk.spec file

        #Ok... almost done!  Now it's time to compile it
        cd /usr/src/redhat/SPECS
        rpmbuild -bb --target=x86_64 fltk.spec

        #When you run the rpmbuild command above, make sure all the other required libs
        #are seen.  For example:
        # Configuration Summary
        # -------------------------------------------------------------------------
        #  Directories: prefix=/usr                                             
        #           bindir=/usr/bin                                         
        #           datadir=/usr/share                                      
        #           datarootdir=${prefix}/share                             
        #           exec_prefix=/usr                                        
        #           includedir=/usr/include                                 
        #           libdir=/usr/lib64                                       
        #           mandir=/usr/share/man                                   
        # Graphics: X11 + Xft + Xdbe + Xfixes + Xinerama + Xcursor + Xrender
        # Image Libraries: JPEG=System                                             
        #                  PNG=System                                              
        #                  ZLIB=System                                             
        #     Large Files: YES                                                     
        #          OpenGL: YES                                                     
        #         Threads: YES 

        #Install the compiled binaries
        rpm -ivh /usr/src/redhat/RPMS/x86_64/fltk- \
/usr/src/redhat/RPMS/x86_64/fltk-devel- \
/usr/src/redhat/RPMS/x86_64/fltk-fluid- \

        [DEPRECATED] - Centos5 specific for older builds:
           yum install ftp://fr2.rpmfind.net/linux/epel/5/i386/fltk-1.1.9-4.el5.i386.rpm
           yum install ftp://fr2.rpmfind.net/linux/epel/5/i386/fltk-devel-1.1.9-4.el5.i386.rpm

   Ok, moving on with more Fldigi dependencies for both Centos6 and Centos5
        # libsndfile-devel
        yum install libsndfile-devel

        # libsamplerate-devel
        yum install libsamplerate-devel

           # If you want the Fldigi's XMLRPC system for Flrig to work, you need 
           # to enable the xmlrpc code:
           # Centos6:
           # -------
           yum install xmlrpc-c-c++ xmlrpc-c-client xmlrpc-c-client++ \
xmlrpc-c-devel xmlrpc-c xmlrpc-c-apps

   # Centos 5
   # -------
   # Try installing from these pre-build versions:

     yum install ftp://ftp.pbone.net/mirror/centos.karan.org/el5/extras/testing/i386/RPMS/xmlrpc-c-1.06.18-1.el5.kb.i386.rpm \
ftp://ftp.pbone.net/mirror/centos.karan.org/el5/extras/testing/i386/RPMS/xmlrpc-c-devel-1.06.18-1.el5.kb.i386.rpm \

     # If the above RPMs won't work for some reason, you'll need to build the XMLRPC
     # code from source:

     # Not sure if cmake is required as we disable it later
     #  Please note that in the SDR section, we will update the Cmake to 
     #  a much more modern version.  Go ahead and follow those instructions
     #  if you want to get ahead now:
     yum install cmake                  

     #Get the code
     wget -O xmlrpc-c-1.06.18-1.el5.kb.src.rpm \
yum install http://centos.karan.org/el5/extras/testing/SRPMS/xmlrpc-c-1.06.18-1.el5.kb.src.rpm

     #Install the code
     rpm -ivh xmlrpc-c-1.06.18-1.el5.kb.src.rpm

     # NOTE:
     # 1 -  this xmlrpc RPM uses cmake and not the usual configure system 
     #      which seems to break the abyss-server subsystem:
     #      -- this following command should give a 0 but it doesn't
     #            xmlrpc-c-config c++2 abyss-server
     #            echo $?
     #         - to fix this, you have to redo the SPEC file a
     #         bit as shown below
     # --
     # 62,63c62,63
     # < mkdir fedora
     # < cd fedora
     # ---
     # > #mkdir fedora
     # > #cd fedora
     # 66,71c66,72
     #  cmake .. \
     # <       -D_lib:STRING=%_lib                     \
     # <       -DMUST_BUILD_CURL_CLIENT:BOOL=ON        \
     # <         -DCMAKE_INSTALL_PREFIX:PATH=%_prefix  \
     # <         -DBUILD_SHARED_LIBS:BOOL=ON
     # ---
     # > #cmake .. \
     # > #     -D_lib:STRING=%_lib                     \
     # > #     -DMUST_BUILD_CURL_CLIENT:BOOL=ON        \
     # > #        -DCMAKE_INSTALL_PREFIX:PATH=%_prefix \
     # > #        -DBUILD_SHARED_LIBS:BOOL=ON
     # > ./configure  --prefix=%_prefix
     # 77c78
     # < cd fedora
     # ---
     # > #cd fedora
     # 102d102
     # < %_libdir/pkgconfig/*.pc
     # 103a104,108
     # > %_libdir/libxmlrpc++.a
     # > %_libdir/libxmlrpc.a
     # > %_libdir/libxmlrpc.la
     # > %_libdir/libxmlrpc_*.*
     # >
     # 110d114
     # < %_mandir/man1/*
     # 113d116
     # < %_bindir/xml-rpc-api2cpp
     # 116a120,122
     # > * Sat May 08 2010 David Ranch  - 1.06.18-2
     # > - stopped using CMAKE, use ./configure to get xmlrpc-c-config C++2
     # > abysss-server passing, added missing /usr/lib files into SPEC file

     # Ok, time to build it
     rpmbuild -bb --target i686 /usr/src/redhat/SPECS/xmlrpc-c.spec

     #Time to install it
     cd /usr/src/redhat/RPMS/i686
     rpm -Uvh xmlrpc-c-1.06.18-1.i686.rpm xmlrpc-c-apps-1.06.18-1.i686.rpm \

        - Using the above RPMs fails to work with Fldigi's configure system  
          -- the following test should give a result of "0" but it doesn't

                xmlrpc-c-config c++2 abyss-server; echo $?

   Back on track, lets move on for both Centos6 and Centos5

       # If the xml-rpc system is installed, the Fldigi system also needs the 
       # Perl RPC::XML CPAN module from RPMforge:

       # NOTE: the old perl-XML-RPC package has been replaced by perl-RPC-XML
       #       package.  Why they did this naming change boggles the mind

            yum install perl-RPC-XML

     # More packages to install
     # ------------------------
     #The following are required by HamLib which is required by Fldigi
       yum install gd gd-devel tcl-devel libusb-devel doxygen libtool-ltdl-devel libXpm-devel

Ok, before we go much farther, we should get Hamlib running just in case you 
don't want to use Flrig.

12b. - Hamlib for Fldigi (and other apps) - Rig control for your radio

Hamlib is a suite of programs and radio definitions to remote control a huge amount of 
different radios.  The amount of control depends on several factors such as:

   - What does the radio offer for control (older radios are very simple, 
        new radios let you control almost every single thing about them)

   - How mature is the Hamlib definition (some definitions are incomplete though
        the radio supports additional rig control function)

Hamlib is an excellent choice to do rig control from shell scripts and what not.
For interactive control with say Fldigi and other GUI tools, I recommend to use

Anyway, if you want to install Hamlib, let's get going:

   # First, you need to install some build dependencies (if you don't 
   # already have them):
   yum install libtool

Next, you can either use my SPEC file (recommended) or modify the Fedora 
one yourself your own:
   # Getting and using my spec file:
   cd /usr/src/redhat/SPECS
   wget -O hamlib.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/hamlib.spec

      If you want to create your own SPEC file

      # Download the Fedora 16 SRPM to get the a baseline SPEC file, the
      # patches for Hamlib to be compatible with Centos, and then later we'll 
      # download the newer Hamlib source code

           #First, let's get the older SRPM and install it
           cd /usr/src/redhat/SRPMS
           wget -O hamlib-1.2.14-1.fc16.src.rpm http://download.fedoraproject.org/pub/fedora/linux/releases/16/Everything/source/SRPMS/hamlib-1.2.14-1.fc16.src.rpm
           rpm -ivh hamlib-1.2.14-1.fc16.src.rpm

Next, regardless of which SPEC file you use (my modified one or the stock Fedora one, it's 
recommend to download the NEWER production version of Hamlib sources.  If there is even a 
newer version than 3.2.0, I recommend to get that version and make the required changes to 
build/install this newer version.  You can browse and download from here:

So, at the time of this writing (3/31/18), the newest version of Hamlib is v3.2.0.  Lets
build that:

   cd /usr/src/redhat/SOURCES/
   wget -O hamlib-3.2.tar.gz https://github.com/Hamlib/Hamlib/releases/download/3.2/hamlib-3.2.tar.gz

Now make sure the SPEC file you downloaded (or created):

   # Fixing your own SPEC file (not needed if you use my above spec file):
   # The sources in hamlib 3.2 are newer and thus the Fedora16 RPM is 
   # a little out of date so we need to fix it and we should disable 
   # GnuRadio and USRP while we're at it as they have HUGE dependencies
   # that we don't use right now.  If you want GnuRadio support, please
   # see the GnuRadio section and get that installed first

   | NOTE:                                                                       |
   |       This section has been updated for Hamlib v3.2+ but one known gotcha   |
   |       is that hamlib gets confused by the presence of both the libusb and   |
   |       libusbx libraries.  As such, to successfully compile this new         |
   |       version, you must build Hamlib with:                                  |
   |                                                                             |
   |          ./configure --without-libusb                                       |

   # NOTE2: there are some HamLib options that you might want to enable 
   #        such as USRP or GnuRadio but both of these options require 
   #        SIGNIFICANTLY more work and packages to resolve.  For example:
   #          --with-rigmatrix	      :: Generate rigmatrix tool (requires libgd)
   #          --without-winradio     :: do not build winradio backend
   #          --with-gnuradio        :: build gnuradio backend
   #          --with-usrp            :: build USRP backend
   #          --without-rpc-backends :: do not build rpcrig and rpcrot backends

   # NOTE3:  Centos5
   #         With Hamlib the 1.2.9n version and to get the perl and python 
   #         options to work, you NEED to use the Fedora patch to set 
   #         the proper destinations.  The 1.2.8 patch applies cleanly 
   #         on 1.2.9 but it does NOT apply to

   cd /usr/src/redhat/SPECS
   vim hamlib.spec
      # In the top "BuildRequires:" lines, make the following changes:
      # Update the version to reflect the new sources
      Version:        3.2

      # Remove "gnuradio-devel, usrp-devel"
      # In the "%configure" section (don't forget that front "\"):
      #   remove "\
      #      --with-usrp"

      # Find the following line and either DELETE it or comment it out with a # character
      Patch2:         hamlib-1.2.11-python2.7.configure.patch

      # Find the following line and either DELETE it or comment it out with a character #
      %patch2 -p1 -b .python-version

   Ok, let's compile hamlib and then install it:
   # For Centos6:
   rpmbuild -bb --target=x86_64 hamlib.spec

      # For Centos5:
      rpmbuild -bb --target i686 hamlib.spec

   During the configure stage, you should see something like the following.  Make sure that
   all the features you expect are present:
    Hamlib Version 3.2 configuration:

    Prefix         /usr
    Preprocessor   gcc -E 
    C Compiler     gcc -O3 -march=native -m64 
    C++ Compiler   g++ -O3 -march=native -m64 

    Package features:
       With C++ binding                yes
       With Perl binding               yes
       With Python binding             yes
       With TCL binding                no 
       With Lua binding                no 
       With rigmem XML support         no 
       With Readline support           yes

       Enable HTML rig feature matrix  yes
       Enable WinRadio                 yes
       Enable USRP                     no 
       Enable USB backends             no 
       Enable shared libs              yes
       Enable static libs              no 

Now hopefully that things built and packaged up ok, time to install them:

   #For Centos6
   cd /usr/src/redhat/RPMS/x86_64
   sudo rpm -Uvh hamlib-3.2-1.el6.x86_64.rpm hamlib-devel-3.2-1.el6.x86_64.rpm hamlib-doc-3.2-1.el6.x86_64.rpm \
hamlib-c++-3.2-1.el6.x86_64.rpm hamlib-c++-devel-3.2-1.el6.x86_64.rpm hamlib-perl-3.2-1.el6.x86_64.rpm \
hamlib-python-3.2-1.el6.x86_64.rpm hamlib-tcl-3.2-1.el6.x86_64.rpm hamlib-debuginfo-3.2-1.el6.x86_64.rpm

   #For Centos5
   cd /usr/src/redhat/RPMS/i686
   rpm -Uvh hamlib*

    ?LEGACY - probably safe to ignore? -- confirm what Fldigi is
        - Fldigi required hamlib-devel 
                - current available is
                - last working version installed 1.2.9 
                - fedora repo is at 1.2.8 
                - not in rpmforge

12c. - Fldigi - Dependencies step #2

Ok, back to more dependencies for Fldigi before we can compile it

   ALSA & PortAudio specific

     - As mentioned above in the ALSA section towards the top of this document,
       both Centos6 and Centos5 ships with very old ALSA kernels and PortAudio 
       code.  You need to upgrade BOTH for proper operation:

       ElRepo ALSA (Centos6):
       # NOTE: this will only upgrade the ALSA kernel soundcard drivers 
       #       which remains compatible with the older ALSA libraries, 
       #       tools, etc.  This is very easy and works well
       yum install http://elrepo.org/linux/elrepo/el6/x86_64/RPMS/kmod-alsa-1.0.24-1.el6.elrepo.x86_64.rpm

       ElRepo ALSA (Centos5):
       # NOTE: this will only upgrade the ALSA kernel soundcard drivers 
       #       which remains compatible with the older ALSA libraries, 
       #       tools, etc.  This is very easy and works well
       cd /usr/src/redhat/RPMS/i686
       wget -O kmod-alsa-1.0.24-1.el5.elrepo.i686.rpm \
       rpm -ivh /usr/src/redhat/RPMS/i686/kmod-alsa-1.0.24-1.el5.elrepo.i686.rpm

       PortAudio Snapshot:
       PortAudio is becoming legacy to Linux much like OSS was some time ago.
       With that said, it's still good to have the support in the system
       and other programs like WSJT still use it:

         *   The EPEL portaudio-19-9.el6 for Centos6 and portaudio-19-8.el5 *
         *   for Centos5 is **NOT** new enough and you must use the newest  *
         *   Tip-Of-Tree version                                            *

          cd /usr/src/redhat/SOURCES
          wget -O pa_snapshot.tgz http://www.portaudio.com/archives/pa_snapshot.tgz

          #Get dranch's portaudio-tot.spec file:
          cd /usr/src/redhat/SPECS
          wget -O portaudio-tot.spec \

          #Look at the following page: http://www.portaudio.com/download.html
          #   Find the date specified for pa_snapshot.tgz

          #Edit the portaudio-tot.spec file and change the date to reflect
          # this newest TOT - for example:
          #  Version: 19
          #  Release: Release: 20120117%{?dist}

          #Centos6 specific
            rpmbuild -bb --target x86_64 portaudio-tot-el6.spec
            rpm -ivh /usr/src/redhat/RPMS/x86_64/portaudio-19-20120117.el6.x86_64.rpm \

          #Centos5 specific
            rpmbuild -bb --target i686 portaudio-tot.spec
            rpm -ivh /usr/src/redhat/RPMS/i686/portaudio-20100923.el5.i686.rpm

   Additional Soundcard and Sound sub-system specific dependencies:
      # Also install 
      yum install jack-audio-connection-kit-devel jack-audio-connection-kit

      # This comes from ATrpms - GUI tool needed for setting proper audio device
      #  routing and audio levels from the Pulse system into say Fldigi, Direwolf, etc
      yum install pavucontrol

      # If you prefer to set your PulseAudio settings via the command line, you
      # can use the "pacmd" tool (warning:  This is a VERY complicated tool to use
      # compared to the pavucontrol tool
      yum install pulseaudio-utils


12d. - Fldigi - Final Compiling

Finally, time to compile Fldigi..

          cd /usr/src/redhat/SPECS/

          Centos6 on a x64 system:
          rpmbuild -bb --target x86_64 fldigi.spec

          Centos5 on a i686 system:
          rpmbuild -bb --target i686 fldigi.spec

          Regardless of which Centos version you're building for, look back
          in the RPM building process and make SURE it looks some thing like 
          the following.  Make sure all the options are "yes", etc:

             Version ..................... 4.0.2

             Static linking .............. no
             CPU optimizations ........... sse2
             Debugging ................... no  

             fldigi ...................... yes
             flarq ....................... yes

             i18n ........................ yes

            fldigi build options:

             sndfile ..................... yes
             oss ......................... yes
             portaudio ................... yes
             pulseaudio .................. yes

             hamlib ...................... yes
             xmlrpc ...................... yes

          and now install it:

          #Centos6 specific:
          rpm -ivh /usr/src/redhat/RPMS/x86_64/fldigi-4.0.2-1.el6.x86_64.rpm

          #Centos5 specific:
          rpm -Uvh /usr/src/redhat/RPMS/i686/fldigi-4.0.2-1.i686.rpm

13. - Flrig - Rig control with or without Fldigi

Flrig is a rig control program that can either be stand-alone or a companion 
program to Fldigi.  Fldigi by itself can use Hamlib but it doesn't always 
give all the desired information.  Flrig gives you:

      - It's completely independent of Hamlib and has it's own radio

      - S-meter readouts as shown by the rig itself

      - Full control of the rig's VFO-A, VFO-B, Split control

      - Full control of the rig's speaker volume, RF power, IF shift, Notch 
        filter, MIC gain ATT, PreAmp1/2, NoiseBlanker, etc.

   NOTE:  this program is OPTIONAL to use with Fldigi but is highly recommended
This is the main window for controlling everything on the rig from RF power, using the tuner, etc:

  Please note that Flrig does NOT provide any QSO logging support what so 
  ever.  If you want that, either use Fldigi's built-in logger, use Fllog,
  or even use Xlog

Ok, let's get to it.  Flrig is a very new program so you might want to try the Alpha 
version if the posted version doesn't work for you.  The primary version didn't for 
me with my FT-950.  It's new so we have to piece things together a bit:

   cd /usr/src/redhat/SOURCES

   #Getting the version 1.3.30 - change the version number to match the newest 
   # release version available
   wget -O flrig-1.3.30.bin.tgz https://downloads.sourceforge.net/project/fldigi/flrig/flrig-1.3.30.tar.gz

   Get the TrinityOS spec file (not recommended):
     cd /usr/src/redhat/SPECS
     wget -O flrig.spec \

     # Update the spec file to reflect the current version of Flrig chosen
     vim flrig.spec

   [NOT Recommended] - Alternatively, you can create your own SPEC file 

   #These notes reflect an older ALPHA build

   cd /usr/src/redhat/SPECS
   wget http://dp67.fedorapeople.org/pkgs/SPECS/flrig.spec

   vim flrig.spec
    * update the version to "1.1.3CY"

    * Change the release string to "1%{?dist}"

    * Change the source0 to "http://www.w1hkj.com/beta/flrig/%{name}-%{version}.tar.gz"

    * Change the %prep0 to "%setup -q -n %{name}-%{version}"

    * Change the %build section, make the "configure" and "make" lines read:

        %configure --enable-optimizations=native
        make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS"

    * Change the %install line from:
        desktop-file-install \
        desktop-file-install --vendor="" \

      also append the commend below the command to say:

        # --vendor obsolete per new guidelines but leaving it in because
        # this is an existing package with vendor previously installed
Next, regardless of using my SPEC file your you building your own, make sure
the version number reflects the current version of Flrig

Now let's build and install it:

   cd /usr/src/redhat/SPECS/

   NOTE: In the Flrig build notes, I used to use

            %configure --enable-optimizations=native

         which seemed to throw warnings that the resulting code would
         be using legacy i80387 FPU instructions.  It turns out this
         was an issue with the older Centos5 compilers and using "native"
         is both RECOMMENDED and enabled

         NOTE #2:  at the beginning of this document, the "native" optimizations
                   was enabled via the /etc/rpmrc file but the Fldigi 
                   configuration script does NOT honor those settings

   #Centos6 specific
      rpmbuild -bb --target=x86_64 flrig.spec
      rpm -ivh /usr/src/redhat/RPMS/x86_64/flrig-1.3.30-1.el6.x86_64.rpm

   #Centos5 specific
     rpmbuild -bb --target=i686 flrig.spec
     rpm -Uvh /usr/src/redhat/RPMS/i686/flrig-1.3.30-1.i686.rpm

13a. - Flrig - Configure rig control

Now it's about time to configure Flrig.  To start off, cable up your radio to a 
serial port (I'm using a USI Navigator in this example) and turn the radio
on but DON'T start Flrig just yet.

    The serial ports I'm using are:

           USI_CAT -> ttyUSB0  :: the CAT serial control

           USI_PTT -> ttyUSB1  :: for asserting PTT (FT950's CAT-based PTT
                                  only listens to the MIC port when in SSB mode

      | NOTE on Serial port permissions:                             |
      | --------------------------------                             |
      | With the use of UDEV, all serial ports require users to have |
      | the "dialout" group permission.  To enable this for your     |
      | login (don't use root):                                      |
      |                                                              |
      |    - edit the /etc/groups file as root  u                    |
      |    - scroll down and find the "dialout" group name           |
      |    - append at the end of the line the needed username like  |
      |      dranch                                                  |
      |                                                              |
      |    * You will have to LOGOUT and log back in with this       |
      |      username for the changes to go into effect              |
      |                                                              |
      |      * Once logged back in, open a terminal window and run   |
      |        the command "groups".  Make sure "dialout" shows up.  |
      |        If it doesn't you'll need to log out of your current  |
      |        Gnome/KDE/whatever session and back in to get the new |
      |        settings.                                             |

Next, as a regular user (NOT root), start up flrig from the command line with:

     /usr/bin/flrig &

     Config --> Xcvr Select

        For my Yaesu FT-950 with a US Interface Navigator, I have:

        Primary tab:

          Rig: FT-950            Fldigi address:
          retries:       3       Fldigi port: 7362
          retry intvl:  50       Ser. port: /dev/ttyUSB0
          cmd intvl:     5       Baud: 38400
          qry intvl:   100       1 stop bits

          No-dial PTT via CAT - Uncheck RTS/CTS
          No-dial PTT via RTS - Uncheck RTS +12v
          No-dial PTT via DTR - Uncheck DTR +12v

        "Hardware PTT" tab:
          PTT port: /dev/ttyUSI_PTT
            - PTT via RTS  (do NOT checkmark "RTS = +V")
            - UnCHECK RTS +12v 

      - Click on "Initialize"

      - Polling

         - Checkmark everything


     - The 1.1.3CY Alpha version is approaching 100% perfect but the
       current 1.1.3 release barely works.  

14. - Fldigi - Configuring the digital mode software for HF radios

14a. - Setup your Yaesu FT950 to work with Fldigi

The following example covers configuring FLdigi with a Yaesu FT-950 and a 
US Interface Navigator USB sound device / serial port interface:

       1. Set the FT-950 to the fastest serial speed and highest DATA sound level out:

             Menu #026 - GENE CAT BPS (radio serial speed) 38400bps: 384H
             Menu #027 - GENE CAT TOT (radio CAT timeout)  1000ms  : 1000
             Menu #028 - GENE CAT RTS (enable RTS HW flow control) : ON

             Menu #050 - DATA(afsk) [soundcard to radio]           : 50
             Menu #051 - DATA(afsk) [radio to soundcard]           : 100
             Menu #061 - RTTY (fsk) [radio to soundcard]           : 100

       2. Serial ports - As described above, here are the serial ports I'm 
          using if you choose to use Hamlib instead of Flrig (see more below)

           USI_CAT -> ttyUSB0  :: the CAT serial control

           USI_PTT -> ttyUSB1  :: for asserting PTT (FT950's CAT-based PTT
                                  only listens to the MIC port when in SSB mode

         | NOTE on Linux serial port permissions:                        |
         | --------------------------------------                        |
         | With the use of Linux's UDEV system, all serial ports require | 
         | users to be in the "dialout" Unix group.  To enable this for  |
         | your specific login id (don't use root), do the following:    |
         |                                                               |
         |    - edit the /etc/groups file as root: sudo vim /etc/groups  |
         |    - scroll down and find the "dialout" group name            |
         |    - append at the end of the line your username, for me, I   |
         |      would add the username "dranch"                          |
         |    * You will have to LOGOUT and log back in with your        |
         |      username for the changes to go into effect               |
         |                                                               |
         |      * Once logged back in, open a terminal window and run    |
         |        the command "groups".  Make sure "dialout" shows up.   |
         |        If it doesn't you'll need to log out of your current   |
         |        Gnome/KDE/whatever session and back in to get the new  |
         |        settings.                                              |

14b. - Initial Fldigi setup for audio, rig control, and audio levels

       3. Initial Fldigi setup:

          As logged in as a regular user (NOT root), start up Fldigi and
          follow the wizard to setup things.  Enter in:

                 - Your callsign
                 - Name (first name only)
                 - QTH where you're transmitting from
                 - Locator
                 - Antenna type

              Next ->

              - Audio:
                - Devices:
                  - Pulse audio (leave the server string blank)
                - Settings:
                  - Sample rate: grey'ed out when using PulseAudio
                  - Converter: Medium Sinc Interpolator
                  - Corrections: all zeros for now (come back to this later)
                - Mixer
                  - OSS mixer: Manage mixer - UNCHECKed
                - Right channel
                  - All checkboxes disabled for a US Interfaces Navigator
                    to a FT950

              Next -->

              - Transceiver control

                For RIG control, you have two primary options:

             - Flrig (recommended): 
                  Fldigi has excellent integration with Flrig via the XML-RPC option 
                  for use with Flrig

             - HamLib: 
                  This extensive radio library will most likely support more radios, 
                       rotators, etc. than say Flrig but it won't give you the same 
                       level of rig feedback for things like S-meters, GUIs for
                       controlling various volumes, etc. that Flrig can

             - If you're going to be using Flrig, do NOT configure the "Hardware 
               PTT", "RigCAT", "Hamlib", or "Memmap" options but under Fldigi.  
               Instead, under Fldigi's XML-RPC option, checkmark the "Use XML-RPC 
               program" and that's it.  Flrig will do the rest

             - Hamlib: If your radio isn't supported in Flrig or you just want
               to use Hamlib, click on Configure --> Rig Control --> Hamlib 
               and checkmark the "Use HamLib".  Next, for a FT950 using the
               previously mentioned UDEV names:

                                Device: /dev/USI_CAT
                                BAUD:   38400
                                Stop bits: 1

                retries: 3      retry: 60
                write delay: 5  post write delay: 5

                  UNCHECK: "PTT via Hamlib command"
                  CHECKBOX: RTS +12

               Click on "Initialize"

               Next, click on the "HW PTT" tab
                  Checked: use separate serial port PTT
                     - use RTS
                     - dev/ttyUSI_PTT

              Finish -->

       4. The main Fldigi screen

          At this point, the primary Fldigi interface should come up and the 
          waterfall should start flowing.

           NOTE on Pulse Audio
                 When I first started up Fldigi on this Centos6 machine with
                 the radio listening to PSK31 on 14.070, I could only see faint
                 PSK31 signals and all the audio was squished to the far-left.
                 I would turn up the radio's speaker volume and the signals
                 got stronger.  Huh?  What's going on here.  Then I sneezed
                 and saw the sneeze on the waterfall!  HA!  Seems that the
                 PulseAudio system was listening to the computer's microphone
                 and not the USB soundcard source!  Check your PulseAudio mixer 
                 settings and:

                     1. Deselect any Capture checkboxes on built-in microphones

                     2. Run the "pavucontrol" in another window

                        a. On the Playback tab, you should see "Fldigi" listed.
                           Click on the box next to the MUTE button that 
                           probably says "Internal Audio Analog Stereo" and
                           for a US Interface Navigator, select "USB Audio Codec"

                        b. On the Recording tab, you should see "Fldigi" listed.
                           Click on the box next to the MUTE button that 
                           probably says "Internal Audio Analog Stereo" and
                           for a US Interface Navigator, select "USB Audio Codec"

          For a FT-950 into a US Interface Navigator sound card and a RS232
          cable to the radio, I have the following setup:

          NOTE:  You can do rig control via Hamlib or Flrig.  Hamlib works
                 very nicely but you can do a LOT more things if you run 
                 the associated Flrig program at the same time as Fldigi.
                 Up to you.  For now, the docs cover Hamlib:

       3. One thing I've learned is if you use the "Signal Browser" that decodes
          many simultaneous PSK31 QSOs, you need to be careful of the settings
          for "Signal Browser's" squelch setting (try -1.5) and the Inactivity 
          Timeout (try 10 seconds in Configure --> UI --> Browser --> Inactivity 

       4. Full setup, level optimization, and much more can be found here:


    **Critical** things that you should do next to get things dialed in (need to 
                 be added to this doc) before operating on the airwaves:

      1. Calibrate your soundcard's timing using Fldigi's WWV mode:


      2. Tune your audio levels for good IMD levels (the more NEGATIVE
         numbers the better.  I -highly- recommend building and using
         a PSKmeter for this (covered in this doc already) as well as 
         in my Digital Field Day docs:


15. - Other Fldigi Related Programs: Flwrap, Flmsg, FLamp, etc.

Fldigi can do far more than just interactive communications.  It can be integrated 
with other programs to send full binary attachments both on an interactive and 
fully automated fashion.  This section details many other programs in the Fl universe!

15a. - Flarq - Error corrected CONNECTED mode communications with Fldigi

Flarq is a utility is built when you compiled/installed Fldigi in the previous 
section.  To use it, follow these guidelines:

  - Have Fldigi already running

  - As a non-root user in a different window, run "flarq &"

  - For the first time user, the "Configure Flarq" dialog to configure the program
    will automatically open

  - Enter in your callsign and whatever beacon you want.  For me, it's following
    borrowing from my master 
packetrig.sh system setup script.

        Mycall: KI6ZHD
        Beacon text: KI6ZHD :: All Linux in CM97ai :: Santa Clara,CA

    - Be sure to change those settings to match your specific settings

15b. - Flmsg - FLdigi plugin for NBEMS forms

Flmsg is a companion program to Fldigi to send NBEMS messages
or ICS forms for emergency communicates over HF.  To use this,
you will also need Flwrap shown in the next section.

   NOTE:  this program is OPTIONAL and doesn't require 
          Fldigi to run or vice versa

Ok, let's get it.  It's new so we have to piece things together a bit:

   cd /usr/src/redhat/SOURCES
   wget -O flmsg-1.1.13.tar.gz http://www.w1hkj.com/downloads/flmsg/flmsg-1.1.13.tar.gz

To get a SPEC file, you can either use my .spec file (recommended) or 
create your own:

     # My recommended SPEC file:
     cd /usr/src/redhat/SPECS
     wget -O flmsg.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/flmsg.spec

       # Skip to the next part since you're not making your own SPEC file

     # If you want to create you own SPEC file, first get an example SPEC file

     cd /usr/src/redhat/SPECS
     wget https://api.opensuse.org/public/source/hamradio/flmsg/flmsg.spec?rev=fc86d1d4334124509642871a9aedffed&

     #Lets rename the crazy file name
     mv flmsg.spec?rev=fc86d1d4334124509642871a9aedffed& flmsg.spec

     vim flmsg.spec
      * Under the BuildRequires: line, remove the entries: 
          xorg-x11-devel and update-desktop-files
      * Change the release reflect the right version
      * Change the Source: line to alter the file suffix from .bz2 to .gz
      * delete the line that reads:  %debug_package
      * Make the %configure line read:

        %configure --enable-optimizations=native

      *Change the make line to read:

        make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS"

      * Replace the line that says: %suse_update_desktop_file -i flmsg

        desktop-file-install --vendor="" \
          --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \

        # --vendor obsolete per new guidelines but leaving it in because
        # this is an existing package with vendor previously installed

      * Add your own revision entry at the bottom

Next, regardless of using my SPEC file your you building your own, make sure
the version number reflects the current version of Flmsg

Now let's build and install it:

   cd /usr/src/redhat/SPECS/

   #For Centos6 users with x86_64
   rpmbuild -bb --target=x86_64 flmsg.spec
   rpm -ivh /usr/src/redhat/RPMS/x86_64/flmsg-1.1.13-1.x86_64.rpm

   #For Centos6 users with i686
   rpmbuild -bb --target=i686 flmsg.spec
   rpm -ivh /usr/src/redhat/RPMS/i686/flmsg-1.1.13-1.i686.rpm

Let's run and configure it:

     /usr/bin/flmsg &

     Config --> Radiogram:
         - Call:      -- for me, KI6ZHD
         - Optionally set your phone #
         - Optionally set your street address
         - Enter your city and state
         - # of words per line
     Config --> Date & Time: 
         - Set your preference for date and time

15c. - Flwrap - FLdigi plugin for sending binary files

Flwrap is a add-on to Fldigi which, in tandem with Flmsg, is used to 
send NBEMS forms and binary files (pictures, etc.)

   NOTE:  this program is OPTIONAL and doesn't require 
          Fldigi to run or vice versa

Ok, let's get on with it.  It's new so we have to piece a SPEC file together 
a bit:

   cd /usr/src/redhat/SOURCES
   wget -O flwrap-1.3.2.tar.gz http://www.w1hkj.com/downloads/flwrap/flwrap-1.3.2.tar.gz

   # To get a SPEC file, you can either use my .spec file (recommended) or 
   # create your own:

     # My recommended SPEC file:
     cd /usr/src/redhat/SPECS
     wget -O flwrap.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/flwrap.spec

       # Skip to the next part since you're not making your own SPEC file

   # If you want to create you own SPEC file, first get an example SPEC file

     Next, lets get an example SPEC file

        cd /usr/src/redhat/SPECS
        wget https://api.opensuse.org/public/source/hamradio/flwrap/flwrap.spec?rev=33da1ba3e8d70b7215b6b10835026cf2&

        #Lets rename the crazy file name
        mv flwrap.spec?rev=33da1ba3e8d70b7215b6b10835026cf2& flwrap.spec

        vim flwrap.spec
         * Under the BuildRequires: line, remove the entries: 
             xorg-x11-devel and update-desktop-files
         * Change the release reflect the right version
         * Change the Source: line to alter the file suffix from .bz2 to .gz
         * delete the line that reads:  %debug_package
         * Make the %configure line read:
             %configure --enable-optimizations=native

         *Change the make line to read:

             make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS"

         * Replace the line that says: %suse_update_desktop_file -i flmsg

           desktop-file-install --vendor="" \
             --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \

           # --vendor obsolete per new guidelines but leaving it in because
           # this is an existing package with vendor previously installed

         * Add your own revision entry at the bottom

Next, regardless of using my SPEC file your you building your own, make sure
the version number reflects the current version of Flwrap

Now let's build and install it:

   cd /usr/src/redhat/SPECS/

   #For Centos6 users with x86_64
   rpmbuild -bb --target=x86_64 flwrap.spec
   rpm -ivh /usr/src/redhat/RPMS/x86_64/flwrap-1.3.2-1.x86_64.rpm

   #For Centos5 users with i686
   rpmbuild -bb --target=i686 flwrap.spec
   rpm -Uvh /usr/src/redhat/RPMS/i686/flwrap-1.3.2-1.i686.rpm

After it's installed, you really don't need to run Flwrap directly
as Flmsg will call it when needed.  But there is a benefit of 
running it directly: drag and drop!  You can drop files into it
and it will do the equivalent of UUencode and UUdecode and send
it over the air with CRC checks to make sure it gets there ok
Let's run it:

     /usr/bin/flwrap &

15d. - Flamp - FLdigi program for broadcasting messages to multiple parties

Flamp is an associated Fldigi program that reliably sends binary files to a list 
of remote stations in a classic HF "broadcast" fashion.  To do this reliably, Flamp
breaks the files up into small blocks and then broadcasts them.  If a given block is 
lost to a specific station (or all stations), the stations can request a resend of 
that specific block until the file is properly received.

   NOTE:  this program is OPTIONAL and doesn't require 
          Fldigi to run or vice versa

Ok, let's get on with it.  It's new so we have to piece a SPEC file together 
a bit:

   cd /usr/src/redhat/SOURCES
   wget -O flamp-1.0.0.tar.gz http://www.w1hkj.com/downloads/flamp/flamp-1.0.0.tar.gz

   # To get a SPEC file, you can either use my .spec file (recommended) or 
   # create your own:

     # My recommended SPEC file:
     cd /usr/src/redhat/SPECS
     wget -O flamp.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/flamp.spec

       # Skip to the next part since you're not making your own SPEC file

   # If you want to create you own SPEC file, first get an example SPEC file

     Next, lets get an example SPEC file

        cd /usr/src/redhat/SPECS
        wget https://api.opensuse.org/public/source/hamradio/flamp/flamp.spec?rev=89eaf05c45d00f17b3318769033c4f0b&

        #Lets rename the crazy file name
        mv flamp.spec\?rev\=89eaf05c45d00f17b3318769033c4f0b flamp.spec

        vim flamp.spec
         * Under the BuildRequires: line, remove the entries: 
             xorg-x11-devel and update-desktop-files
         * Change the release reflect the right version
         * Change the Source: line to alter the file suffix from .bz2 to .gz
         * Make the %configure line read:
             %configure --enable-optimizations=native

         *Change the make line to read:

             make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS"

         * Replace the line that says: %suse_update_desktop_file -i flamp


           desktop-file-install --vendor="" \
             --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \

           # --vendor obsolete per new guidelines but leaving it in because
           # this is an existing package with vendor previously installed

         * Add your own revision entry at the bottom

Next, regardless of using my SPEC file your you building your own, make sure
the version number reflects the current version of Flamp

Now let's build and install it:

   cd /usr/src/redhat/SPECS/

   #For Centos6 users with x86_64
   rpmbuild -bb --target=x86_64 flamp.spec
   rpm -ivh /usr/src/redhat/RPMS/x86_64/flamp-1.0.0-1.x86_64.rpm

   #For Centos5 users with i686
   rpmbuild -bb --target=i686 flamp.spec
   rpm -Uvh /usr/src/redhat/RPMS/i686/flamp-1.0.0-1.i686.rpm

Once installed, start up Flamp with:

     /usr/bin/flamp &

Once the program starts, click on the "Configure" tab.  In there, fill in your
callsign and your your station's QTH / details in the "Info section.  Beyond
that, the use of Flamp is well documented at:


15e. - Flwkey - Winkeyer CW keyer software support

Flwkey is a program that can control K1EL Win-keyer enabled kits, specifically
for me, the W1EL WinKeyer that's built into a US Interface Navigator.  

   NOTE:  this program is OPTIONAL and doesn't require 
          Fldigi to run or vice versa

Ok, let's get on with it.  It's new so we have to piece a SPEC file together 
a bit:

   cd /usr/src/redhat/SOURCES
   wget -O flwkey-1.1.2.tar.gz http://www.w1hkj.com/downloads/flwkey/flwkey-1.1.2.tar.gz

   # To get a SPEC file, you can either use my .spec file (recommended) or 
   # create your own:

     # My recommended SPEC file:
     cd /usr/src/redhat/SPECS
     wget -O flwkey.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/flwkey.spec

       # Skip to the next part since you're not making your own SPEC file

     # If you want to build your own SPEC file, do the following:

       - First, lets get an existing SRPM file

         cd /usr/src/redhat/SRPMS
         wget -O flwkey-1.0.0-1.1.src.rpm http://ftp.w1nr.net/opensuse/repositories/hamradio/openSUSE_11.1/src/flwkey-1.0.0-1.1.src.rpm

        cd /usr/src/redhat/SPECS

        vim flwkey.spec
         * Under the BuildRequires: line, remove the entries: 
             xorg-x11-devel and update-desktop-files
         * Change the release from 1.1 to 1.0
         * Change the Source: line to alter the file suffix from .bz2 to .gz
         * delete the line that reads:  %debug_package
         * Make the %configure line read:

             %configure --enable-optimizations=native

         *Change the make line to read:

             make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS"

         * Replace the line that says: %suse_update_desktop_file -i flwkey

           desktop-file-install --vendor="" \
             --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \

           # --vendor obsolete per new guidelines but leaving it in because
           # this is an existing package with vendor previously installed
         * Add your own revision entry at the bottom

Next, regardless of using my SPEC file your you building your own, make sure
the version number reflects the current version of Flwkey

Ok, now let's build and install it:

   cd /usr/src/redhat/SPECS/

   #For Centos6 users with x86_64
   rpmbuild -bb --target=x86_64 flwkey.spec
   rpm -ivh /usr/src/redhat/RPMS/x86_64/flwkey-1.1.2-1.x86_64.rpm

   #For Centos5 users with i686
   rpmbuild -bb --target=i686 flwkey.spec
   rpm -Uvh /usr/src/redhat/RPMS/i686/flwkey-1.0.0-1.i686.rpm

Let's run and configure it:

     /usr/bin/flwkey &

     Goto Configure --> Select Ports

       Enter in the proper /dev/ name for your W1EL WinKeyer.  If you are
       using udev as configured in the first Fldigi section it would be
       /dev/USI_WKEY.  Else, if you're using a US Interface Navigator and 
       have the HamPacket script, run: 


       to see and choose the right address.  Usually for my non-UDEV machine, 
       it's /dev/ttyUSB2

     Once properly selected and if Flwkey can communicate to the Winkeyer,
     it should show the versions, such as:

        Flwkey version: 1.1.2
        Wkeyer version 22

     Next, goto Configure --> Operator

        CLL:              - for me, KI6ZHD
        OPR:            - David
        QTH:           - Santa Clara, CA
        LOC:   - CM97ai

     Next, goto Configure --> Parameters

        ModReg: Tone ON - Enabled
                PTT  ON - Disabled
        Output Pins: Key 1   (for an FT950

     Next, as of Flwkey 1.1.2, it cannot directly configure how to key up 
     (PTT) the rig but per the following URL:


     You can get the WinKeyer in a US Interface Navigator to assert PTT using 
     the secondary PTT line, do the following (assuming the US Interface Navigator 
     config line is on /dev/USI_CFG using a UDEV enabled setup:

         #Set the serial port to 1200 baud
         stty -F /dev/USI_CFG speed 1200

         #initialize the CONFIG port - do it twice
         echo -e "KT/r" > /dev/USI_CFG
         echo -e "KT/r" > /dev/USI_CFG

         #Enable Winkeyer PTT - this is a bit pattern with the LSB or Lowest 
         # significant bit on the left
         echo -e "KL11111111111/r" > /dev/USI_CFG

         #If you'd like to save these settings as the default
         echo -e "KS/r" > /dev/USI_CFG

     Ok, time to give it a try.  Assuming the Winkeyer is powered up, the radio 
     is on, the antenna is tuned up, and the selected frequency is clear, click 
     on the "TUNE" button in the lower right hand corner.  If things are setup 
     working properly, you could see your radio get keyed up and hear a SOLID 

     Next, in the "STA" field, type in your callsign, click on the "Send" button 
     so it's light stays lit, and then click on the "call button".  At that 
     point, you should start calling yourself over the airwaves!

15f. - An easy way to update your various Fl-suite of programs

Fldigi and it's supporting suite of programs gets updated all the time and as such,
it can be a pain to do all of this various updates by hand.  To keep up here, I've 
automated the building all this, do the following:

   cd /usr/src/archive

   #This is the master script that calls all the other sub-scripts:
   mkdir Fl-suite

   mkdir Flamp
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Flamp/update-flamp-code.sh

   mkdir Flcluster
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Flcluster/update-flcluster-code.sh

   mkdir Fldigi
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Flamp/update-fldigi-code.sh

   mkdir Fllog
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Fllog/update-fllog-code.sh

   mkdir Flmsg
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Flamp/update-flmsg-code.sh

   mkdir Flnet
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Flnet/update-flnet-code.sh

   mkdir Flrig
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Flamp/update-flrig-code.sh

   mkdir Flwkey
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Flamp/update-flwkey-code.sh

   mkdir Flwrap
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Flamp/update-flwrap-code.sh

Ok, with all those in place, it's just a matter of running the Fl-suite.sh script which will then go
into each directory and run the package specific shell script which then:

    - Download the newest version of the specific program
    - Prompt you as required to update the spec file's version
    - Compile the code
    - Give you the command line to install the new RPM

16. - Advanced Configurations with Fldigi - HF AX.25 packet, email and APRS with Fldigi

Fldigi can be a lot more than just making QSOs and contacts with digital modes. It has an extensive API set to communicate with other programs for both higher level and now, lower level systems. This section calls out some of the different integration possibilities with Fldigi and other programs.

16a. - PskMail and Fldigi - HF email and APRS system used with Fldigi

  | To be updated for Centos6 |

PSKmail is an interesting fusion of a system where emails are coded into 
CRC checked binary blobs and sent via automatically selected PSK 250/500,
Olivia, etc. via FLdigi.  The program is all Java based and uses Fldigi
as the backend.  These instructions assume you have Fldigi fully working
with the XMLRPC backends compiled in.

Assuming  the following:
   PSKmail 0.5.4
   Oracle/Sun Java 7 v67

  NOTE:  This section needs to be updated.  It's recommended to use
         Oracle Java 8 or newer. See:


         for more details for now


16b. - Install Java JRE for PskMail

   Java JRE (Java Runtime Environment)

      # Get the JRE 
      # -----------
      #  NOTE #1: Oracle does not offer a Yum repository for Java so you have
      #           to keep it up to date yourself
      #  NOTE #2: Get the 64bit version if you have 64bit browser installed 
      #           check with 'rpm qa | grep firefox' and look for x86_64 

      Go to https://www.java.com --> Download

         As of 9/23/17, the current version of Java JRE is v8 Update 144

         Download the required 32/64bit version via your web browser or use the links below

            #Via the CLI
            cd /tmp
            #64bit RPM version - 56MB

            #32bit RPM version - 59MB

      Now look at the text of the above command to decipher the actual version being downloaded:

         mv "AutoDL?BundleId=225344_090f390dda5b47b9b721c7dfaa008135" jre-8u144-linux-x64.rpm

      - As root, run:

          sudo rpm -Uvh jre-8u144-linux-x64.rpm

          - make sure that /etc/alternatives/java is pointing to the newest
            location.  The Sun installer does NOT update the Centos alternatives

              ls -la /etc/alternatives/java

              #Make sure that latest points to the /usr/java/jre1.8.0_144 path
              ls -la /usr/java/ | grep latest

              If it doesn't then do:
              sudo rm /etc/alternatives/java
              sudo ln -s /usr/java/jre1.8.0_144/bin/java /etc/alternatives/java

          - Make sure the other Java links are in place

              ls -la /usr/java/

              # Make sure that both "default" and "latest" point to the new version of the JRE

       - Make sure Java is working.  In a new shell as a regular user, run:

           java -version

         The response out of that should be the expected version, etc

       - If you want Java to work within your web browser, you need to create a symlink for the
         java plugin

            #for 64bit browsers
            cd /usr/lib64/mozilla/plugins/
            ln -s /usr/java/latest/lib/amd64/libnpjp2.so .

            #for 32bit browsers
            cd /usr/lib/mozilla/plugins/
            ln -s /usr/java/latest/lib/i386/libnpjp2.so .

            #restart firefox for it to load the new settings.  Then go to Tools --> 
               Add-ons --> Plugins   and look for "Java (tm) Plug-in" which must
               be present for things to work

16c. - Install and Configure PskMail and Fldigi

Download the pskmail code:

   cd /usr/src/archive

   mkdir Pskmail

   NOTE:  It seems the "released" version of code for Pskmail is usually rather old.
          It's recommended you always download the newest Alpha version of code.
          See http://www.pskmail.org/PSKMaildownloads.html to find out the newest 
          release version

          #For example, downloading the current newest version
          wget http://pskmail.org/downloads/jPSKmail-2.0.19.jar

   Install RXRX libraries - (optional) 
      Used only if you plan on connecting a GPS to your PSKmail system

          - cd /usr/src/archive/PskMail/jpskmail
          - cp librxtxSerial.so /usr/java/latest/lib/i386/
          - cp lib/RXTXcomm.jar /usr/java/latest/lib/ext/

     #For Centos5 machines:

Prep your Centos to support lock files for the user who will be running

    usermod -G lock 

  NOTE:  Once I added myself to the "lock" group, no matter what I did, the
         output of 'groups' and 'groups dranch' would not match.  I had to 
         restart Xwindows to get things to sync up.  Beware!

First, start up Fldigi as you would normally.  Then, do:

Setting up Fldigi:

     - On the Radio (mine is a Yaesu FT-950, set the VFO to 10.147.00 and make
       sure the antenna is all tuned up, power is set to a max of 45watts,

     - In Fldigi:
        --> Configure 
              --> Waterfall --> Display
                  UNCHECK: Monitor transmitted signal

              --> Misc --> PskMail
                   - Mail Server Attributes
                       - Carrier Frequency: 1000 Hz
                       - Search Range: 10Hz
                       - Acquisition SN: 6db
                       - AFC range: 10hz
                       - Reset to Carrier: Enabled

                       - General: 
                          turn on Report ARQ frames average S/N

                      --> ID

                        - Under "Reed-Solomon ID (Rx), uncheck all items

             - Click on save

Run jPskMail

       cd /usr/src/archive/PskMail/jpskmail
       java -jar javapskmail.jar

    Go to Edit --> Preferences

        User Data
          Callsign:    -SSID   (I'm using KI6ZHD-7)
          Link to:     ki6zhd
          Server mode: 
          Latitude:      (37.2061)
          Longitude:    (-121.5999)


            Checkmark "Rigcontrol" assuming you have this
            working under Fldigi

To read the manual, open up another shell and do:

    acroread jpskmail_manual.pdf

16d. - NextGen HF packet - Using Fldigi's modern modes with Linux's native AX.25 stack via TCP-KISS

Starting with Fldigi 3.22.03 (GIT version or newer) or (Alpha), it now 
supports both a TCP and UDP-based "KISS" interface.  A KISS interface is commonly 
found with classic 300 / 1200 / 9600 HF and VHF packet TNCs but this combination 
will allow AX.25 enabled Linux machines to leverage all the modern digital modems in 
Fldigi.  You'll be able to tie them into Linux's AX.25 stack for say keyboard to keyboard 
chat, BBS, Winlink, whatever.  Quite cool!   This interface can also be used by other 
programs like UI-Chat or any client program that supports TCP-KISS.  I personally think 
this new found flexibility will provide a massive improvement to HF packet communications
compared to the classic 300BAUD AFSK mode in terms of reliability and less retries.  It's
worth noting that only the widest of Fldigi modes will approach classic 300BAUD HF Packet's 
"speed".  I put "speed" in quotes as that would only be true if it was reliable on HF (which 
IMHO, it isn't).  If there are way too many retries, the payload speed goes to ZERO!

In Fldigi Alpha, this network based KISS support was further enhanced to add 
TCP-KISS.  The UDP method was quite fragile but this TCP version already seems to be 
substantially more simplified and reliable.

To get started, you need to follow the previous Linux AX.25 sections of this 
document and get your Linux AX.25 stack ready.  You'll also need  to install and configure 
Fldigi v3.23.10.08 or newer.  If you don't have both of those working, please go to 
those sections and do that now.

Ok, now that you have both Linux AX.25 and Fldigi working, the next thing to consider 
is that Fldigi does NOT support KISS via serial PTYs like what how Linux's kissattach 
expects.  Fldigi instead uses the Linux machine's TCP/IP stack to communicate the KISS 
frames.  To link the two systems together, a tool called "socat" will be used.  Socat 
can do an amazing amount of different things.. from it's readme, it says:
   socat can be used, e.g., as TCP port forwarder (one-shot or daemon), as an
   external socksifier, for attacking weak firewalls, as a shell interface to UNIX
   sockets, IP6 relay, for redirecting TCP oriented programs to a serial line, to
   logically connect serial lines on different computers, or to establish a
   relatively secure environment (su and  chroot) for running client or server
   shell scripts with network connections.

Socat's amazing flexibility provides the necessary communication link between the two
programs.  Let's install it:

   #Install socat - this installs on Centos6 from RPM-Forge 
   #   - NOTE: EPEL's has an older version of socat which has known bugs
   sudo yum --disablerepo=epel install socat

Next, we need to configure the AX.25 system for your new SSID.  All SSIDs on your
system need to be UNIQUE system, regardless of AX interface and/or radio frequency.  
To figure out what SSIDs are in use on your machine, use the following command
while your regular packet system is running:

   #On my station, I have KI6ZHD (that's -0), -1, and -2 for Linpac and -5 for UroNode
   # in use

   $ netstat -A ax25 -an
   Active AX.25 sockets
   Dest       Source     Device  State        Vr/Vs    Send-Q  Recv-Q
   *          KI6ZHD-2   ax0     LISTENING    000/000  0       0
   *          KI6ZHD-1   ax0     LISTENING    000/000  0       0
   *          KI6ZHD-0   ax0     LISTENING    000/000  0       0
   *          KI6ZHD-5   ax0     LISTENING    000/000  0       0

So I'll add -8 for my Fldigi based HF station.  First, edit the /etc/ax25/axports 
file and add an interface identifier for your HF link.  Here, I'm calling it "fld"
but you can name it anything you want:

   # name | callsign | speed | paclen/mtu | window | description
   fld KI6ZHD-8 0 64 2 7.073MHz (300baud)

Please note that the 0 BAUD is really a "serial port thing" and really won't be 
used here.  What *is* important is the 64byte paclen (MTU) and the 2 packet window.  
In classic HF packet, 64byte packets and a two total outstanding frame window is a 
good way to reduce having too much data being sent (and lost) and thus creating too 
many retransmit requests.  Now that you'll be potentially be using more modern Fldigi 
digital modes that possibly have built-in FEC, you can consider increasing this paclen
side depending on propagation conditions, etc.  The maximum value allowed paclen/MTU 
setting is 256 but please note that you *must* also adjust the AX.25 T1/T2/T3 timers 
to account for the transmission time *and* reception time of the remote ACK on a PER
mode basis (some Fldigi modes are quite slow due to their heavy use of FEC).  The stock 
Linux AX.25 maximum value for the T1 timer is 30 seconds so keep that in mind.

Next, download the following Socat shell script:


This is the script that interconnects Fldigi to Linux's AX.25 stack via the socat
program.  You now need to edit this script and put in all your specific distro's 
execution paths for certain programs, enter in your specific CALLSIGN-SSID, etc:

   | NOTE:                                                                     |
   |       It's important you edit and update at least the following           |
   |       variables for system's use                                          |

#System binaries location

# This will need to be updated depending on how many ax0 interfaces
# are already present in ifconfig

#Fldigi mode: TCP or UDP

#User specific settings - change these to match your callsign and AMPR IP address

The other important issue here is to READ the various comments at the top of this 
script as specific MANUAL initialization is *REQUIRED* if you use Fldigi's UDP-KISS 
mode and want you your system to work.  This manual initialization approach seems
to be a limitation of SOCAT but I'm not 100% sure.  This is NOT an issue with the 
TCP-KISS approach.

Ok, next, start up Fldigi and goto:

    - Configure --> IO  (that's Input/Output)

       - Uncheck  : LOCK
       - Check    : Enable KISS
       - Check    : AX25 decode
       - Optional : Enable CSMA

       - Under the KISS section:

          Checkmark: TCP
          Checkmark: Listen / Bind

          - IP Address       :
          - I/O port         : 7342
          - Check            : Enable Busy Channel
          - Continue After   : 3 sec
          - KPSQL Attenuation: 2

          - Click on the "CONNECT" button to start the network socket

    - Save

Now back in the main Fldigi window:

   - Pick an HF digital mode you want to use (I would recommend something like PSK250R)
     to start off with (some decent speed, not too wide, not too slow):

       NOTE: Not all modes in Fldigi are capable to send binary data.  Specifically
             modes like CW, RTTY, etc will refuse to get enabled either because they 
             aren't 8-bit clean or they are too slow).  If you try and select an 
             incompatible mode, an error will be shown in the Help --> Event Log
             window but the current general selection includes  BPSK, 8PSK, MFSK, THOR, 
             Contestia, Olivia and MT63 at various baud rates.

   - Turn OFF Fldigi's TxID for mode identification as this takes too long to transmit
     and thus, it impacts the overall AX.25 T1 timer settings

   - QSY your HF radio to an available, desired  digital frequency (please review the various
     automatic-mode HF spectrum band plans) - 


   - lower the radio RF power to the right level (usually < 50w on a 100w radio)
     as to not damage your radio's RF finals as well as ensure minimal ALC distortion 
     effects, etc

   - Tune/Match the antenna to your radio's frequency

   - Ok, now run the script you just edited:

        sudo /usr/local/sbin/fldigi-socat-packet.sh start

     The output should look similar to below:
     Clean out any old stale fldigi-socat-packet.sh setups first

     Clearing any previous listen for device: fld
     Clearing any previous mheard for device: fld
     Clearing any previous kissattach for device: fld
     Clearing any previous socats for device: fld
     Wait for 3 seconds
     Confirm Fldigi connection is set to 'LISTENING'
     tcp        0      0    *                   LISTEN
     Removing any stale Fldigi PTY file
     Loading required kernel modules: mkiss ax25
     Starting SoCAT in TCP mode from /var/tmp/fldigi-dev to
     Fixing pty permissions
     Actual PTY is: /dev/pts/3
     Confirm two 'ESTABLISHED' Fldigi connections:
     tcp        0      0                 ESTABLISHED
     tcp        0      0                 ESTABLISHED
     Updating ax0 for Persistence, slot, TX-Delay
     Updating ax0 for AX.25 timing parameters
     Setting Generic AX25 settings
     Setting HF packet centric settings (compared to say VHF packet)
     Setting Mode specific settings - PSK250R
     Starting mheardd
     Starting listen and sending to /var/log/packet.log
     MANUAL step:  Consider running the following command:
        beacon -c KI6ZHD-8 -d beacon -t 10 fld KI6ZHD Fldigi TCP-KISS from Santa Clara, CA


At this point, everything enabled for AX.25 packet will now work just like it
would over AFSK 300/1200 or FSK 9600 baud packet!  Programs like "linpac", 
"call / axcall", etc will just work but now over HF with your chosen selection 
various Fldigi fast/less-FEC vs. slower/more-FEC (aka robust) modes!  Only time 
will tell to see what mode might emerge to become the new digital packet mode for 

BTW, you might consider downloading my axctl shortcut script at:


This script makes the early termination of existing AX.25 and Netrom connections 
*must* easier.  That can save your radio from making a lot of useless retries to a 
previous station that's no longer reachable due to the HF band changing.

17. - TrustedQSL for Logbook of the World (LOTW) - online and offline logging with Fldigi and other tools

TrustedQSL is the logging system for Logbook of the World (LOTW) which is a X.509 
certificate based Authentication and Authenticity system.  This is the Linux tool to 
submit QSO logs for official credit with the ARRL.   This LOTW system allows HAMs to 
start working towards various HAM radio operation awards via a fully electronic 
logging system (vs. using paper logs), authenticate your HAM radio license to use other 
services like Echolink, etc.  You can learn more about this system at: 


This is the main window for creating and renewing LOTW certificates

There are two ways to install TrustedQSL today:

  1. (EASIEST):  Add the EPEL repo per the "Third Party RPM repositories" section above
     and at that point, simply run:

        sudo yum install trustedqsl

     As of 8/26/17, this will install versions:


  2. Installing from source : This approach always gets you thew newest version
     of code but is always a bit of work.

     | Work in Progress to upgrade to 2.1.2 on Centos6 |

If you're going to install via souce, lets get started.  As of Oct 11, 2015, the current 
versions of code were:

         TrustedQSL : 2.1.2  (was 2.0)
         tqsllib    : 2.4

   NOTE: Alternatively, you can look at:


         It might be good to check the following URL to confirm that this code 
         is the newest available

   - Get the required sources (this example is using TQSL v2.0):

       cd /usr/src/redhat/SOURCES
       wget http://downloads.sourceforge.net/project/trustedqsl/TrustedQSL/v2.1.2/tqsl-2.1.2.tar.gz

   - Next, we need to install some dependencies:

       #From EPEL - this archive will also install "bakefile" and "python-empy" on Centos6 machines
       #  openssl 1.0.1j or better - BAD - Centos6.7 comes with 1.0.1e
       #  expat 2.1.0 or better    - BAD - Centos6.7 comes with 2.0.1
       #  zlib 1.2.8               - BAD - Centos6.7 comes with 1.2.3
       #  wxWidgets 2.8.12         - OK  - Centos6.7 comes with 2.8.12
       #  curl 7.39.0              - BAD - Centos6.7 comes with 7.19.7
       #  BDB 6.1.19               - BAD - Centos6.7 does not support Berkeley DB 6 and worse, has a 
       #                                   changed and bad OpenSource license
       #                              Fyi, 3rd party RPM requires ftp://rpmfind.net/linux/sourceforge/r/ra/ramonelinux/Rel_0.99/releases/x86_64/packages/db-6.1.19-1.ram0.99.x86_64.rpm requires Glibc 
       #                              2.14 but Centos6 comes with 2.12 
       #                              from Source- http://download.oracle.com/berkeley-db/db-6.1.26.tar.gz

       yum install curl libcurl-devel openssl openssl-devel expat expat-devel wxGTK-devel zlib zlib-devel

          Tqsl v2.0.1 / tqsl-lib 2.4 compiled successfully with:
          #  openssl 1.0.1e
          #  expat 2.0.1
          #  zlib 1.2.3
          #  wxWidgets 2.8.12
          #  curl 7.19.7
          #  db 4.7.25

       #Need to build Berkeley DB 6.x from scratch
       cd /usr/src/redhat/SOURCES
       wget http://download.oracle.com/berkeley-db/db-6.1.26.tar.gz

       #Prepare the archive to work with an RPM spec file
       cd /usr/src/redhat/BUILD
       tar xzvf ../SOURCES/db-6.1.26.tar.gz
       mv db-6.1.26 db6-6.1.26
       tar czvf ../SOURCES/db6-6.1.26.tar.gz db6-6.1.26/*
       rm ../SOURCES/db-6.1.26.tar.gz

       #get an example db4 spec file
       cd /tmp
       wget https://kojipkgs.fedoraproject.org//packages/db4/4.8.30/4.fc17/src/db4-4.8.30-4.fc17.src.rpm
       rpm -ivh db4-4.8.30-4.fc17.src.rpm

       #TrustedSQL 2.x+ requires a more modern version of Cmake (at least 2.8.0) or newer
       #    or the build will send the error: 
       #         "CMake 2.8 or higher is required.  You are running version 2.6.4"
       # NOTE #1: Per the following URL, Cmake versions later than Cmake 2.8.3 are 
       #          available but evidently have bugs when building things like boost.  
       #          As such, installing Cmake 2.8.8 will work now but will create 
       #          frustrating problems later if you want to install gnuradio, etc
       #          More details at:
       #          http://stackoverflow.com/questions/9948375/cmake-find-package-succeeds-but-returns-wrong-path
       #          http://ros-users.122217.n3.nabble.com/ROS-Installation-on-Red-Hat-No-rule-to-make-target-lib64-lib64-libboost-thread-mt-quot-td4018527.html
       #          In the GnuRadio section, I detail how to build a modern, fixed version
       #          of cmake if you want to get ahead of things.  If not, this cmake-2.8.8
       #          RPM will work fine for TrustedQSL for now
       # NOTE #2:  You can also install this from the EPEL repository by installing 
       #           "cmake28" which as of 12/14/13, will install cmake 2.8.11 but I 
       #           personally think this is a bad idea to mix build programs like 
       #           this.  I personally recommend to either build a modern version
       #           as mentioned above or do the following:
       yum install http://pkgs.repoforge.org/cmake/cmake-2.8.8-1.el6.rfx.x86_64.rpm

   - For this example, we will build for 

              TrustedQSL: 2.0
              tqsllib   : 2.4

     Ok, now we need to get the RPM spec files for the archive.  The tqsl-2.0.tgz 
     file does come with two spec files but they are:

         - Broken, they don't work right
         - is not 64bit aware for proper lib64 library paths
         - Reflect the old TrustedQSL v1.x program which broke things into two different RPMs
           using the same sources

     A new RPM spec file from Richard Shaw resolves all of these things via a near rewrite.
     This archive will be soon available in the Fedora EPEL repository but until then, you can
     get the spec file from my site:

        wget -O flwkey.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/trustedqsl.spec

     Please note that I've altered a few things in the spec file to not assume that people are 
     using different RPM naming, etc.  I'm working with Richard to see if he will make his RPM
     a bit more flexible

   - Ok, time to compile and install it:

       cd /usr/src/redhat/SPECS/
       rpmbuild -bb --target=x86_64 trustedqsl.spec
       #  We must install it before going to the next step
       cd cd /usr/src/redhat/RPMS/x86_64
       rpm -Uvh trustedqsl-2.0-1.el6.x86_64.rpm tqsllib-2.4-1.el6.x86_64.rpm tqsllib-devel-2.4-1.el6.x86_64.rpm

  Centos 5 Users: 

      DEPRECATED: The below text reflects the previous version of TrustedQSL 
                  and needs to be updated for v2.0.  Try using the above Centos6
                  steps and if it doesn't work / and you need help with it, 
                  please let me know.

       # NOTE: For Centos5 users, several steps might still be required.  Here are the
       #       legacy notes 

       Take the SPEC file from the FedoraProject and:
          - update it for version 2.2-1
          - remove the SSL patch

       #Edit the 
       rpmbuild -bb --target=i686 tqsllib.spec
         -7, -8, and -9 fails with error: unpacking of archive failed on file
         /usr/src/redhat/SOURCES/tqsllib-2.0-openssl.patch;4ae25fe5: cpio: MD5 sum

       #You must install the devel libs before being able to compile
       #  trustedqsl
       rpm -Uvh /usr/src/redhat/RPMS/i686/tqsllib-2.0-5.i686.rpm

       #now compile and install:
       #  note:  must use the FC9 version 
       Download a sample SPEC file from:

       Download the newest sources from:
            and put them in /usr/src/redhat/SOURCES/

       rpmbuild -bb --target=i686 trustedqsl.spec

       fails with: 
          + desktop-file-install
          --dir=/var/tmp/trustedqsl-1.11-2-root-root/usr/share/applications tqsl.desktop
          Must specify the vendor namespace for these files with --vendor
          error: Bad exit status from /var/tmp/rpm-tmp.29990 (%install)

       Take the SPEC file from the FedoraProject trustedqsl-1.11 SRPM and:

          #This is from the terminator tool which is a multi-window terminal app:
          #    http://www.tenshu.net/terminator/terminator-screenshots/
            desktop-file-install --dir=%{buildroot}%{_datadir}/applications tqsl.desktop --vendor=""
            desktop-file-install --dir=%{buildroot}%{_datadir}/applications tqslcert.desktop --vendor=""

          # Update the versions in the SPEC from 1.11 to 1.13

          # Remove all references to Patch0 (icon patch)
          # Go into /usr/src/redhat/SOURCES and
             cp TrustedQSL-1.11-icon.patch TrustedQSL-1.13-icon.patch
             cp TrustedQSL-1.11-gcc43.patch TrustedQSL-1.13-gcc43.patch
             cp TrustedQSL-1.11-lib64.patch TrustedQSL-1.13-lib64.patch

       #Recreate the RPM file:
       rpmbuild -bb --target=i686 trustedqsl.spec

       #With the new 1.13 version, having issues with:

         tqslwiz.cpp: In member function 'void TQSLWizCertPage::UpdateFields(int)':
         tqslwiz.cpp:118: error: 'tqsl_getLocationFieldFlags' was not declared in this scope
         tqslwiz.cpp: In constructor 'TQSLWizCertPage::TQSLWizCertPage(TQSLWizard*, void*)':
         tqslwiz.cpp:258: error: 'tqsl_getLocationFieldFlags' was not declared in this scope
         ### Sent email on 03/06/2011 to get help but was NEVER able to get 
         ### any answers from ANY of the SourceForge developers. Had to stick
         ### with the 1.11 version

         rpm -Uvh /usr/src/redhat/RPMS/i686/trustedqsl-1.11-2.i686.rpm

17a. - Using TQSL - How to install TrustedQSL certificates and use the application

  | Needs to be updated to TQSL 2.0 |

You now  have TQSL is installed!  To run the program, run the following 
as your usual username login (NOT ROOT):


 Please note that previous version of Tqsl had a program called "tqslcert" which
 has now been merged into the main "tqsl" program

Once loaded, you can read the online documentation or follow the documentation on the LOTW website 
on how to set it up!   A few key points:

   - Once fully configured, the program will create the following:

       tqsl - the primary program to sign and optionally submit Cabrillio and 
              ADIF logs for LOTW credit.  This program also creates and renews 
              TQSL callsign x.509 certificates 

       and the following files and directories:

          $HOME/.tqsl  - the config directory

       In the .qsl directory, there are two main files:

          your-callsign.tq5 - is a certificate request / renewal file you created
          your-callsign.tq6 - is a ARRL LOTW signed file to finalize your certificate

   - TQSL Certs used in LOTW are valid for three years.  I received an email notification
     from the LoTW team ONE MONTH before my original certificate expired.  I highly 
     recommend to add a calendar reminder onto your Smartphone, calendar, etc. 2yrs and 11
     months (35 months) from now to remind you to renew your certificate again.  Why?  

        It will make your life a lot easier if you renew (actually create a new 
        certificate via signing it with your ABOUT-TO-EXPIRE certificate) *before* 
        the old one expires.  Why (sheesh.. you ask a lot of questions... :-)

        ** LOTW certificates are only used to validate QSLs. They are NOT specifically 
        ** tied to your or anyone's callsign.  As such, if a certificate expires, gets 
        ** lost due to a drive crash, etc., the cert will have NO bearing on 
        ** previous/future QSL credit for your callsign, etc.


BTW, all of ARRL's documentation might be nice and dandy but it might not be all 
that clear how to SUBMIT LOGS to say LoTW and Eqsl.cc!  Two sections below is my 
quick LOTW/Eqsl FAQ that I use every time using the "tqsl" program.  This will get 
an update as the tqsl program now supports direct log uploads to the LOTW website.

BTW, some programs like Xlog or some macros on Fldigi try to automate this log 
submission even after every single QSO.  I hadn't gotten to that point due to 
previous issues with Centos 5 and old libraries but now that I'm on Centos 6,
I hope to work on that soon:

17b. - Renewing TrustedQSL certificates

LoTW certificates last exactly three years and they MUST be renewed before the old one 
expires.  As mentioned in the previous section, the LoTW system should email you a notice
of it expiring.  If you don't renew this BEFORE your old cert expires, the process gets 
a *LOT* more tedious.  So, let's say you got an email from the LoTW people that your
cert is going to expire OR you loaded up LoTW and you saw the above screen shot.

   1. Load up /usr/bin/tqsl

   2. Click on YES to renew your certificate

   3. You should be prompted to fill in two dates:

      - When you made your first QSO (this should be pre-populated but put in the date when
        you first received any form of an Amateur radio license.  For me, I put in the date
        when I received my technician class license.

      - When you made your last QSO (leave this all blank)

      - Click "next"

   4. Fill out your address that is reflected in your license and click "Next"

   5. Put in a valid email address for you

   6. You will be prompted if you want to add a passphrase to your certificate.   I generally 
      recommend to do this to secure your certificate as it's sent through the untrusted SMTP
      email system, etc.  It's critical to NOT loose this password or you'll have to request a 
      new certificate which takes longer than to request a new certificate.

   7. You'll be asked if you want to submit your application for a new certificate, click
      on Next

   8. If you added a passphrase to your expiring certificate, enter that in now.

At this point, you should see something like the following:

   Attempting to upload Certificate Request
   Certificate Request uploaded with result:

   Started processing your Renewal Certificate Request.
   For call sign: KI6ZHD
   For QSOs not before: 20xx-xx-xx 00:00:00
   For QSOs not after: 
   Your renewal certificate request is accepted and awaiting further processing.
   You will receive the certificate after it has been created.
   Your certificate request processing is completed.

   These results have been emailed to --email-address--

After the submission, you should soon receive an automated email from the LOTW system 
that says something like:
  To: <your email address>
  From: <lotw-admin@arrl.org>
  Subject: Automated response to your LoTW request
  Date: Fri, 21 Sep 2018 02:21:36 +0000

  Started processing your Renewal Certificate Request.
          For call sign: KI6ZHD
        For DXCC Entity: UNITED STATES OF AMERICA (291)
    For QSOs not before: 20xx-xx-xx 00:00:00
     For QSOs not after: 
  Your renewal certificate request is accepted and awaiting further processing.
  You will receive the certificate after it has been created.
    Your certificate request processing is completed.

Now you wait until you get your new cerificate from the LOTW to the email address
you specified.  This email will look something like:

  Subject: LoTW Certificate
  To: <your email addr>
  From: <lotw-admin@arrl.org>
  Date: Fri, 21 Sep 2018 12:45:18 +0000

  IMPORTANT NOTE: This certificate requires
  TrustedQSL Version 2.0 or later. Attempting to install
  it using an earlier version of the TrustedQSL software
  will result in errors. The latest TrustedQSL software can
  be obtained at:
  Here is your LoTW certificate for KI6ZHD
  You should be able to install this certificate by double-
  clicking on the attachment icon. If that isn't possible or
  doesn't work, save the attached file to disk and then
  use the TQSL program's "Load Certificate File" menu
  command to install this certificate into your system.

  NOTE: If the attachment failed to arrive with this message,
  you can just log on to the Web site noted below using the
  provided username and password and download the certificate
  file directly.

  Records submitted using this certificate can be accessed on
  the LoTW web site using the credentials:
  username: ki6zhd
  password: <some-DIFFERENT-clear-text-password-that-lotw-thinks-is-ok-to-send>
  by logging in at 
  NOTE! This is NOT the same password the TQSL program may ask for when 
  you're signing a log file!"

At this point, you want to do two things:

  1. Save the <your-callsign>.tq6 attachment as a file on your computer

  2. Save the email to a safe place just in case (or you can delete it if you really wish)

Now do the following:

  1. start up the /usr/bin/tqsl program with your usual username (not root).  

  2. Select Callsign Certificate --> Load Callsign Certificate from File

  3. Find and select the <your-callsign>.tq6 file you previously saved and click
     on Open

  4. You should receive a message saying:

       Callsign Certificate Loaded:   Your-callsign (your name)  DXCC = number-of-signed-qsos

  5. Click on finish to complete the renewal

That's it!  You're good to go and your new certificate is valid for three years.  WHen 
this certificate eventually approaches it's expiration, you shoudl again receive an email 
notification from the LoTW team about it.  I I highly recommend to add a calendar reminder 
onto your Smartphone, calendar, etc. 2yrs and 11 months (35 months) from now to remind you 
to renew your certificate again as well. 

17c. - QSL Service - Tips on dealing with paper QSL cards send via bureaus

Most modern HAMs log their QSL contacts via on-line services like ARRL's LOTW and QRZ's 
eQSL.  You'll see that once you get on the air and start making some QSOs (phone or digital 
modes), those HAMs are going to log the contact.  It's best to get setup to honor their
request (LoTW covered above)!  What you'll also probably start to get is also some paper 
QSO cards coming in the postal mail directly from these HAMs!  Some people consider this 
form of QSL confirmation as old school but I think it's still pretty cool to receive 
these.  It's always best to reciprocate on sending a paper QSL cards back as well 
(not cheap) but the creation of QSL cards and how to best return those QSL cards still 
needs to be written.

What this section is about is getting paper QSL cards through the Bureaus.  What is
a Bureau?  Think of them as a country to country BULK mail system.  Remote HAMs send their
outbound QSL cards to their local country bureau inexpensively.  From there, the country
bureau sends aggregately batches of QSL cards to remote countries.  The receiving country
bureau will then send it to local bureaus.  At that point, if you have an active account
with that bureau, they will send you your bureau-based QSL cards usually when you accumulate
one OUNCE worth of QSL cards.  This is NOT a fast process as it can take many months (even 
YEARS as I've read) for QSL cards to get to you but they WILL get there.

One thing that WAS VERY surprising to me was that after about 1.5 YEARS after I 
became active in amateur radio, I received a postcard stating that I have QSL cards 
from the local bureau and I needed to supply self-addressed envelopes and stamps.  
Say what?  What's all this about?!

It's best to read about this volunteer FREE service (no ARRL membership required) 
first:  http://www.arrl.org/incoming-qsl-service

There is a specific protocol to get an active account into your local bureau.  Some 
bureaus want you to send in a batch of self addressed stamped envelopes (SASE) where as
others prefer you to supply a certain amount of money to pay them to provide the envelopes 
and postage to get those QSL cards to you.  Read the above URL to learn more on how to 
get started but I highly recommend you get that setup.  

For me, since I'm a 6-call in California, I have to look at the "Sixth Call Area Service" on 
the above website to get those details.  They prefer our in-state HAMs to provide money
to buy their envelops and stamps but I have to provide self-sticking labels with my 
address on them.  Some bureaus also have websites that let you query the status of your 
incoming QSL cards so that's pretty cool too.  According to my 6-based bureau:


I have 5 available envelopes, $2.60 in available postage, one QSL card and my last Bureau delivery
was 12/14/2014.  That's over 20 months ago.  See what I said about NOT fast?  That's just how it 
goes but then again, I haven't been doing a lot of QSOs so my incoming paper QSL card rate is 
probably VERY low.

Btw, don't forget that if you move from place to place, to update the bureau with your
new address!

18. - Logging - Compiling and configuration of Contact loggers

As part of any good amateur radio setup, people want a reliable contact logger.
In general, I've found that there are a few specific categories of logger needs 
depending on the interest of the operator:

   - Casual logging : gathers all the usual contact information, optionally can
                      upload contacts in ADIF or Cabrillo formats.  No need for
                      integrated spot clusters, support for prefill checks 
                      (a list of common contester callsigns to speed up data
                      entry) or tracking different contest awards points.  Examples
                               Fldigi's internal logging 
                               Fllog - compatible with Fldigi's logging.  Supports
                                       networked logging but doesn't track per 
                                       contest awards, bonus points, etc.

   - Contester logging: Detailed programs that are very aware of different contest
                        rules, their specific points and bonuses, with support
                        for prefill checks and distributed networking to coordinate
                        multiple HAMs at different stations.  Some of the more elaborate
                        programs have native support for some digital modes like 
                        CW, RTTY, PSK, Spot/Packet clusters, etc.  Most popular 
                        contesting programs are only available for Windows such as 
                        N1MM, WriteLog, etc.

18a. - Fldigi / Fllog - Good full featured logging for the Casual user

FLdigi comes with a useful, built-in logging program which supports fetching 
details of remote stations from multiple services.  It also supports a Contest 
mode which supports duplicate checking and a few other light weight contest features.  
It also supports export these contacts into the common Cabrillo format for submission 
into various contests.  Some more specific features include:

  - Rig control for accurate contact details like frequency and mode
  - Flexible contact "serial number" management
  - Macros for repeated tasks like calling CQ, incrementing serial numbers, etc

In addition to the built-in logger feature, Fldigi also supports external 
logging systems such as Fllog for multi-station operation.  No addition functionality
is given other than to coordinate all contacts to a central place to avoid 
duplicate contacts, avoid the need to merge different log files into one file for
export, etc.

Please see the Fldigi section for a Fl-suite.sh sub-script to build this
package.  It should also be mention that Fldigi itself has it's own basic
logging solution as well.

18b. - CQRlog - Powerful / full featured logging

CQRLog is one of the few logging programs out there that is both geared towards
the serious DXer looking for automatic lookup of remote stations and contesters 
which is under ACTIVE development.  Some of it's key features are:

  - Powerful QSL management including printing of QSL cards, labels, etc
  - Native LOTW / EQSL contact uploading
  - Integration with Xearth for plotting remote contacts on an Earth display
  - Built-in GreyLine map
  - Integration with Fldigi for digital contact logging
  - Rig control via Hamlib

   One thing to note is that CQRLog is a heavier program than most and it uses
   MySQL as it's database backend.  This makes it very flexible and for those
   who understand SQL, you can do VERY powerful lookups.  For those operators
   running very old computers with limited resources might not want to run

  | TBD: Add in CQRLog compiling and configuration |

18c. - Xlog - Alternative QSO Logged with automatic log uploads to LOTW/EQSL for FLdigi

  | To be updated for Centos6 |

Xlog is a fully self-contained logger program that even some contesting features.  
The reason why I'm using it as it can integrate with FLdigi 3.20.21 (must be 3.20.21 
or newer) and with another developer's tools, it can support automatic LOTW/EQSL 
log uploads.

   | ABORT!!!                                                           |
   |                                                                    |
   | Xlog 2.0.3 requires gtk2.12 which is not supported in Centos5 and  |
   |   it will be very difficult to install it.  Must upgrade to Centos |
   |   6 or a more modern distro to get Xlog 2.0.3 working              |

   Requirements (it's recommended that you already built Fldigi):

        - hamlib for rig control

So download Xlog at:


    Assuming you put it in /tmp
    mv /tmp/xlog-*.tgz /usr/src/redhat/SOURCES

Next, you can use my RPM from


   or you can build you're own SPEC file by doing the following:

     Get a SPEC file for it at:


        mv /tmp/xlog-2.0-1.fc9.src.rpm /usr/src/redhat/SRPMS
        rpm -Uvh xlog-2.0-1.fc9.src.rpm

    Now update the SPEC file to reflect the new version of Xlog you just

         change the line:
              Version:        2.0

         to look like:
              Version:        2.0.3

    #Now, Xlog since version 1.6 (very old) requires gtk+ 2.12 or newer but 
    #Centos 5.5 only comes with 2.10.4.  Gah... another reason not to run 
    #such an old distro!!  And they ignore the upgrade requests too:


    #Hack around this by doing the following:

        cd /usr/src/redhat/BUILD
        tar xzvf /usr/src/redhat/SOURCES/xlog-2.0.3.tar.gz
        cd xlog-2.0.3
        cat configure | sed "s/2.12/2.10/" > configure.new
        mv -f configure.new configure
        chmod 755 configure
        cd ..
        #edit the file configure.in and change the line:
            PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.12.0)

        #to the following
            PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.10.0)

        #Roll up the changes into a new tar.gz file
        tar czvf xlog-2.0.3.tar.gz xlog-2.0.3/*
        mv -f xlog-2.0.3.tar.gz ../SOURCES/

    #Build Dependencies:
       #This installs 5 other packages for me.. yay
       yum install libgnomeprint22-devel

    #Now build up the RPM
    rpmbuild -bb --target i686 xlog.spec

    It still fails.  Looking farther, upgrading Centos5.5 to gtk2.12+ 
    would require total brain surgery.  Not worth it.

      BUMMER!  Up to Centos 6.x I suppose


Automatic Xlog to LOTW/ESQL middleware

   Uploader requirements:

19. - APRS -Automatic Packet Reporting System

APRS or Automatic Packet Reporting System is a system built upon the classic 
AX.25 packet system to support a very flexible system for communication.
Most people think of APRS as packet radio + a GPS for creating simple one-way
tracking system but APRS is far more than that.  APRS supports:

   - send two way APRS text messages to specific hams
   - send out one way bulletins to ALL HAMs in a specific region
   - send and receive two way email
   - create objects notifying other HAMs what's in the area like events, radio
       nets, and other things at specific times or places
   - Send out weather reports and emergency information
   - Interrogate remote APRS stations for additional information they might
      offer in an interactive fashion
   - Send out telemetry such as voltage, current, and anything else you can 
       think of
   - sending out tracking coordinates
   - and more and more uses are being created every day

Within APRS, there are a few primary containers of technology that do things:

  - APRS client : these are devices that at least send out APRS packets

       Trackers - usually TX-only devices sending GPS coordinates (posits) and 
                  maybe some other text

       APRS radios - Like the Kenwood D700/D710/D72/etc, they support both sending
                     posits, TX/TX messages, etc

       Computer programs like Xastir that can display remote stations, WX warnings,
           etc, on a dynamic MAP say like OpenStreetMaps, etc.

  - APRS Server : these are programs that usually support digipeating APRS packets
           as a low-level (WIDE1) or high level (WIDE2) systems.  Many of them also
           support being an IGATE or Internet Gateway that can local APRS packets
           into the Internet for display, messaging, etc.

There are lots of APRS programs out there and here are a few of them:

   - Unix or Unix Compatible

      Clients - programs that typically have a GUI interface, show maps, show positions
                of remote stations, support messaging to remote stations, support IGATE
                functionality, etc

        - Xastir: graphical Unix client only supporting mapping, APRS messaging, etc.

        - YACC: graphical client written in Java

        - JavAPRS: graphical client written in Java

        - Polaric: graphical client written in Java

      Servers - programs that typically do NOT have a GUI interface.  They are usually
                used to run as an APRS digipeater, announce positions, telemetry, etc.
                but do not show maps, don't always support messaging, etc.

        - APRX: A powerful APRS server supporting complex digipeating and other 
                functionality though it does NOT support APRS messaging.  Covered
                in this HamPacket documentation in a later chapter

        - Direwolf: A complete soundcard based TNC with full APRS server functionality
                    though it doesn't support APRS messaging.  Covered
                    in this HamPacket documentation in a later chapter

   - Windows only

        - APRSISCE: Full featured Windows APRS client 
        - PinPointAPRS: APRS client for Windows only started in 03/2018

        - YACC: graphical client written in Java

        - UIView32: Considered one of the mode featureful Windows clients but development
          stopped once the primary developed became an SK back in 2004.  It still works on
          modern Windows OSes like Win10.

        - JavAPRS: graphical client written in Java

You can find a more complete list of APRS programs here:


19a. - GPSd - GPS enabled location for Xastir, GPS time, etc

If you have an external GPS receiver and want to use it with Xastir (not needed
with DanTracker), this is the way to go.  Though Xastir directly supports NMEA-0183 
serial GPS units like the Ambicom GPS-USB (uses the Prolific pl2303 usb to serial chip), 
there are limitations to it. Like...
   - TBD: Add me!

External daemons like "gpsd" fixes many of those limitations and enables far 
more flexible GPS operation.  With that said, lets move forward!  If 
you don't have an external GPS, it might to do this NOW so that Xastir
will be able to support one in the future!

  NOTE: when I tried to use an Ambicom GPS-USB device in Xastir, it
        didn't work through minicom but running at 4800 baud worked fine.

  Download the code here:


  This doc assumes we're downloading 3.5

    cd /usr/src/redhat/SOURCES
    wget -O gpsd/gpsd-3.5.tar.gz http://download-mirror.savannah.gnu.org/releases/gpsd/gpsd-3.5.tar.gz

  gpsd has a few dependencies:

    yum install dbus-glib-devel

    yum install xmlto
      # this installs 9 other packages

    yum install libXaw-devel
      # this installs 2 other packages

    yum install PyQt PyQt-devel
      # this gets you QtNetwork - Also installs two other packages

    Newer generations of GPSd now support bluetooth receivers, so...
    yum install bluez-libs-devel 

    And.. it also replaces Make with newer Python methods so,
    yum install chrpath scons

  Now let's create a SPEC file
    cd /usr/src/redhat/BUILD
    tar xzvf /usr/src/redhat/SOURCES/gpsd-3.5.tar.gz
    cp /usr/src/redhat/BUILD/gpsd-3.5/packaging/rpm/gpsd.spec \

    NOTE: In version 3.5, the spec file has two bugs:
      a) A bogus version name.  To fix, change the line:
              Version: 3.5~DEV
              Version: 3.5

      b) find the section with line "%package clients"
         and change the lines:
           Requires: clients-x11 = %{version}-%{release}
           Requires: clients-cli = %{version}-%{release}
           Requires: gpsd-clients-x11 = %{version}-%{release}
           Requires: gpsd-clients-cli = %{version}-%{release}

    NOTE#2: If your system doesn't have the Python developer packages
            installed, the above SPEC file will fail in enabling 
            Python support

    NOTE#3:  My system had two problems in building the RPM

       a. Centos5 only: 
          My default /usr/bin/python setup was pointing to 
          Python 2.4 but I also had 2.5 installed.  The gpsd 
          SPEC file finds 2.4 but the Make system found
          2.5 and created an error like the following:

No such file or directory

          The actual file was in the 2.5 directory:

ls /var/tmp/gpsd-2.95-3-root-root/usr/lib/python2.5/site-packages/gps/gps.py

          the solution to this was:
           rm /usr/bin/python
           ln -s /usr/bin/python2.5 /usr/bin/python

          Unfortunately, after running that, Yum will no longer
          work so undo that change once the RPM is built

      b. My system doesn't have Qt4 installed but that doesn't really

  Now let's create the RPM

    cd /usr/src/redhat/SPECS

   #For Centos6 users with x86_64
   rpmbuild -bb --target=x86_64 gpsd.spec

   #For Centos5 users with i686
   rpmbuild -bb --target=i686 gpsd.spec

  Now install them
  #There are other packages that are created but we don't need them for Xastir
   rpm -ivh /usr/src/redhat/RPMS/x86_64/gpsd-3.5-1.el6.x86_64.rpm
   rpm -ivh /usr/src/redhat/RPMS/x86_64/gpsd-clients-3.5-1.el6.x86_64.rpm \
/usr/src/redhat/RPMS/x86_64/gpsd-clients-cli-3.5-1.el6.x86_64.rpm \
/usr/src/redhat/RPMS/x86_64/gpsd-clients-x11-3.5-1.el6.x86_64.rpm \

   Ok, so it's all installed and it's time to try it out!  Assuming your GPS unit 
is on /dev/ttyUSB0 (USB based), try this:

   #Set the speed of the serial port to 4800 BAUD
   stty -F /dev/ttyUSB0 ispeed 4800

   #This is a test where the daemon will stay in the foreground
   #  but it won't start doing anything until a client connects
   #   using -n changes that behavior
   /usr/sbin/gpsd -N -D 5 /dev/ttyUSB0

   #so now start a client

   NOTE:  I noticed that gpsd installed a bunch of stuff in 
          /etc/udev/rules.d/99-gpsd.rules to recognize various USB
          -based GPSes which throw errors like:

          udevd[452]: add_to_rules: unknown key 'ATTRS{idVendor}'

          I recommend to disable them with:

            mkdir /etc/udev/rules.d.disabled
            mv /etc/udev/rules.d/99-gpsd.rules /etc/udev/rules.d.disabled

   This is also a good read:

   Tip:  You can also get atomic accurate date and time via:

   #UTC date
   DATE=`gpspipe -w -n 1 | awk -F \" '{print $12}' | awk -F T '{print $1}'`
   TIME=`gpspipe -w -n 1 | awk -F \" '{print $12}' | awk -F T '{print $2}'`

   You can also tie in to ntpd directly:

   INCOMPLETE: Delorme EarthMate PN-40 GPS to work with Centos5

   This section is INCOMPLETE - many deadends here


    wget http://mirror.stanford.edu/yum/pub/centos/5.3/os/SRPMS/libusb-0.1.12-5.1.src.rpm
    rpm -ivh libusb-0.1.12-5.1.src.rpm


19b. - Xastir - The APRS mapping and digipeating tool

Xastir is a self-contained APRS Mapping / Digipeating client program that
can either use multiple TNCs in CONVERSE mode, KISS mode, Linux's native
AX.25 stack, APRS-IS, or any combination above!  It can display all of the remote
posits via an integrated OpenStreetMaps display for online or offline display
as well as allows users to create their own maps.  Think of it as a self 
contained GUI like www.aprs.fi or www.openaprs.com without the Internet!
This is the main window for tracking objects in the map, setting new objects, etc:
  NOTE #1: There seems to be a APRS message ACK bug in the July 16
           version of 1.9.9.  I experienced this in a lengthy QSO
           with a HAM with a Yaesu VX8-DR.  Specifically, this 
           Xastir would not accept digipeated ACKs from him unless
           I turned on "Enable Satellite ACKs".  Unfortunately, when
           I enabled that, Xastir would no longer send it's own 
           ACKs!   Stay tuned on this one and if you see it as well,
           please let me or the Xastir email list know!

19b1. - Xastir - Building the Dependencies

 - Requirements for Xastir: A huge laundry list of items unfortunately..

    - tkimg :: image manipulation for the TCL language

            yum install tk tkimg

        wget \
        yum install tk 
        rpm -ivh /tmp/tkimg-1.3-0.9.20080505svn.el5.i386.rpm

   - gpsman  (this section assumes you have built gpsd from the section above)

        Centos6 and Centos5
           cd /usr/src/redhat/SRPMS/
           wget  gpsman-6.4.1-2.fc15.src.rpm http://kojipkgs.fedoraproject.org/packages/gpsman/6.4.1/2.fc15/src/gpsman-6.4.1-2.fc15.src.rpm
           cd /usr/src/redhat/SRPMS/
           rpm -ivh gpsman-6.4-1.fc9.src.rpm
           #Let's remove the OLD version
           rm /usr/src/redhat/SOURCES/gpsman-6.4.1.tgz

           cd /usr/src/redhat/SOURCES/
           wget -O gpsman-6.4.3.tgz \
           cd ../SPECS

           Edit the gpsman.spec file and update the "Version" line to be:
              Version:        6.4.3
              Release:        1%{?dist}

           #For Centos6 users with x86_64
           rpmbuild -bb --target=x86_64 gpsman.spec
           rpm -ivh /usr/src/redhat/RPMS/noarch/gpsman-6.4.3-1.el6.noarch.rpm

           rpmbuild -bb --target=i686 gpsman.spec
           rpm -ivh /usr/src/redhat/RPMS/noarch/gpsman-6.4.3-1.noarch.rpm

    NOTE:  Of all the Linux packages to install for HAM on Centos, 
           Xastir is one of the HARDEST to get installed but it does eventually 
           install!  It requires over ~40 other RPMs to be installed first before 
           you can even start to compile it!  Sheesh but it's worth it!

   - More things to install

          # Lesstif - A legacy Xwindows window toolkit - Comes from EPEL
          yum install lesstif

          # No longer Required pacakges (kept here to only keep the reader informed) : Xastir works fine without these packages
          #  - GDAL is no longer supported by Xastir thus no reason to install those packages: gdal gdal-devel
          #  - lesstif-devel package conflicts with openmotif-devel
          #     - ISSUE #2 - For some reason, yum couldn't find this but the manual URL works
          #    yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/lesstif-devel-0.95.2-1.el6.x86_64.rpm

          yum install libXp libXp-devel

          #NOTE:  This geos package might have been needed for previous GDAL support - need to investigate if it's needed anymore
          yum install geos
          yum install giflib unixODBC netcdf 
          yum install libgeotiff libgeotiff-devel

          #Note that ImageMakick has seen various problems with Xastir; it's recommended to use
          # the more stable GraphicsMagick toolset instead
          #I would recommend to uninstall ImageMagik just in case though it complains on two
          # dependencies: kipi-plugins and perl-Image-Size
          rpm -e --nodeps ImageMagick ImageMagick-devel ImageMagick-perl ImageMagick-doc

          yum install GraphicsMagick GraphicsMagick-devel
          yum install festival pcre-devel proj-devel shapelib-devel db4-devel

          #If you want to have resizable fonts, you need xfontsel
          yum install xorg-x11-apps

          wget \
          wget \
          #Since the lesstif* tools are from the rpmfind.net repository and I
          #can't find their GnuPG keys, you will not be able load those RPMs via 
          #yum directly
          rpm -ivh /tmp/lesstif-0.95.0-26.fc9.i386.rpm
          rpm -ivh /tmp/lesstif-devel-0.95.0-26.fc9.i386.rpm

          - LibXp
             #Keep going.. we're getting closer
             yum install libXp libXp-devel

          - Lesstif-devel
             rpm -ivh /tmp/lesstif-devel-0.95.0-26.fc9.i386.rpm
             #  This will install 1 other RPM
          - Geos
             #There seems to be a issue with the gdal RPM and it
             #requires this later symlink
             yum install geos
             ln -s /usr/lib/libgeos.so /usr/lib/libgeos.so.2

          - giflib, unixODBC, netcdf, gdal
             yum install giflib unixODBC netcdf

          - NOTE, no longer need with modern Xastir versions as GDAL support was removed
              # Because the geos RPM above is broken but we fixed it with the
              # symlink, we need to FORCE this install
              wget http://packages.sw.be/gdal/gdal-1.4.4-1.el5.rf.i386.rpm 
              rpm -ivh --nodeps /tmp/gdal-1.4.4-1.el5.rf.i386.rpm

          - Even more dependencies - from rpmforge
            #OLD, install GraphicsMagick instead
            rpm -e  ImageMagick ImageMagick-devel
            yum install GraphicsMagick GraphicsMagick-devel
            yum install festival pcre-devel proj-devel shapelib-devel gdal-devel \

     - Centos 6 and 5
       Xastir is not quite ready to run just yet. Now we have to install some Perl modules.. guh

        UPDATE:  Use the cpan2rpm tool to install Perl modules in an RPM
                 trackable fashion:

            yum install perl-HTTP-Lite
            yum install perl-Device-SerialPort
            yum install perl-Test-Simple
            yum install perl-Module-Build
            yum install perl-Image-Size
            yum install perl-XML-Simple

            #NOTE:  The official version of cpan2rpm 2.028 has issues with the Pod:Text module in newer
            #       Perl versions, specifically: 
            #           Can't locate object method "interpolate" via package "Pod::Text"
            #       so use this fixed version
            yum install ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/10/x86_64/cpan2rpm-2.028-6.fc10.noarch.rpm

            #For me, I then had to do the following hacks to get things to work

              #Had to put my name and email in the RPM building macro -- change
              #this to be your name and email

              vim /root/.rpmmacros
              David Ranch dranch@trinnet.net
            #the following command will create the SPEC but it will fail to build due
            #to not having a right GPG passphrase.  We can fix that in a minute
            #  NOTE: all URLs found via http://search.cpan.org
            cd /tmp
            cpan2rpm --no-sign -i http://search.cpan.org/CPAN/authors/id/S/SR/SREZIC/perl-GPS-0.17.tar.gz

            Centos 5 only
               #Ok, now that the SPEC file was created, lets work around it
               rpmbuild -bb /usr/src/redhat/SPECS/perl-GPS.spec

               #Ok, do the original command again and now it will create and
               #install ok
               cpan2rpm --no-sign -i http://search.cpan.org/CPAN/authors/id/S/SR/SREZIC/perl-GPS-0.17.tar.gz


           Whew!  Now we have five more packages to go:

            #NOTE: This is NOT the same thing as perl-Tree-RedBlack
            cpan2rpm --no-sign -i http://search.cpan.org/CPAN/authors/id/A/AJ/AJOLMA/Tree-R-0.06.tar.gz

            Centos 5 only
              rpmbuild -bb /usr/src/redhat/SPECS/Tree-R.spec
              cpan2rpm -i http://search.cpan.org/CPAN/authors/id/A/AJ/AJOLMA/Tree-R-0.06.tar.gz

            cpan2rpm --no-sign -i http://search.cpan.org/CPAN/authors/id/A/AJ/AJOLMA/Geo-Shapelib-0.20.tar.gz

            Centos 5 only
               rpmbuild -bb /usr/src/redhat/SPECS/Geo-Shapelib.spec
               cpan2rpm -i http://search.cpan.org/CPAN/authors/id/A/AJ/AJOLMA/Geo-Shapelib-0.20.tar.gz

            Centos 5 only
               cpan2rpm --no-sign -i http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/Test-Simple-0.96.tar.gz
               rpmbuild -bb /usr/src/redhat/SPECS/Test-Simple.spec

               cpan2rpm --version=0.3607 -i http://search.cpan.org/CPAN/authors/id/D/DA/DAGOLDEN/Module-Build-0.3607.tar.gz
               rpmbuild -bb /usr/src/redhat/SPECS/Module-Build.spec
               cpan2rpm --version=0.3607 -i http://search.cpan.org/CPAN/authors/id/D/DA/DAGOLDEN/Module-Build-0.3607.tar.gz

              DEPRECATED - Skip this section for now and see the next section down
              Below is the Legacy method to install Perl modules but creates issues with 
                the final Xastir RPM and requiring to ignore dependencies

              the below section will be removed later

              #The other perl modules aren't part of Centos so we do it the Perl way
              perl -MCPAN -e shell

              #If this is the first time running CPAN, just accept all the default
              #answers  (there's a lot of them) and then select your geolocation
              #for faster downloads, etc.

              #Once at the CPAN> prompt, do:

                 install GPS::Garmin
                   #Accept the installation of any dependencies

                 install Geo::Shapelib
                   #Accept the installation of any dependencies

              enter "quit" to leave CPAN

              Run the following command to make sure the two CPAN modules were

                   #This command will take a bit to finish
                   perl -MCPAN -e autobundle > /tmp/perl-module.lst

                   #Search the new list for the two modules
                   grep -i -e garmin -e shapelib /tmp/perl-module.lst
              #If the two perl modules are installed but the below RPM won't
               install, then it's ok for force the #installation

              end legacy info (to be removed)

19b2. - Xastir - Compile the APRS mapping and digipeating tool

You still with me?  Ready to download and install Xastir?!  

Now let's finally get started on compiling Xastir

   Xastir comes in two forms:  

       - Official Releases code : usually very stable but can be very old at times
                                  I'm talking like multiple-years old 

       - Cutting edge Git code : up to date but has a small chance of having bugs

   To get the Older RELEASE code (not always recommended as it's important for you 
   to check the date the last release version was actually published:


   In this document, I'm generally recommending people to get the newest GIT version of 
   the code (not the official releases).  The reason for this is that the Xastir team rarely 
   pushes new official versions yet the git version of the code is almost always stable and 
   any needed fixes go into Git branch.  The slow cadence of new official releases does hurt 
   getting those fixes to Xastir users but I can't do much about that.  So let's get started
   using the Git version:

      #Xastir's native SRPM from the source code almost works!
      cd /usr/src/redhat/BUILD

          Getting the code the Git way (recommended):
          #If this is your first time doing this
          git clone https://github.com/Xastir/Xastir.git
          mv Xastir xastir-git

          #You've previously downloaded a previous version of the repo
          cd xastir-git
          git pull
          Getting the code the static download (not recommended):
          wget https://github.com/Xastir/Xastir/archive/master.zip

      Assuming you're following the recommended Git method, let's now get some details about the 
      version of the Git code.  Run the following commands:

             echo "Git hash: `git log | head -n3 | grep -i -e commit -e date`"
             grep "AC_INIT(\[xastir\]" configure.ac

       Here, I see the following and you'll need that hex string in a moment:

             Git hash: commit f02777ecb3deac5cf35927cf37927809fc7ad55d
             Date:   Fri Apr 17 16:42:56 2020 -0600


             AC_INIT([xastir], [2.1.7], [xastir@xastir.org])

       # Assuming you downloaded the Git repo, lets prepare to create the Xastir archive
       #This creates the configure script

       # Next, create a valid symlink to ultimately give the tar archive a version number
       #  change this 2.0.9 number to whatever is shown from the above commands
       cd ..
       ln -s xastir-git xastir-2.1.7git

       # Next, we need to create the archive with the correct version, Git commit date and GIT hash.
       # This is done using the date from the last commit AND the first 8 characters (MSB - most 
       # significant bits or the LEFT most 8 charachters) of the Git hash:
       #   NOTE:  This is done in a few steps to include a key Git file so Xastirs Help --> About box can
       #          show the Git commit version your actually running without having to include the 
       #          entire Git repo in the archive
       tar cvf /usr/src/redhat/SOURCES/xastir-2.1.7git-20200417gitf02777ec.tar.gz xastir-2.1.7git/* --exclude xastir-2.1.7git/.git
       mv /usr/src/redhat/SOURCES/xastir-2.1.7git-20200417gitf02777ec.tar.gz /usr/src/redhat/SOURCES/xastir-2.1.7git-20200417gitf02777ec.tgz

       # OPTIONAL:  You can now optionally delete the Git repo (I'd recommend to keep this directory it if you plan on 
       #            updating your Xastir code from Git often)
       rm -f /usr/src/redhat/BUILD/xastir-2.1.7git

          # If you also want delete the Git repo too (if you don't plan on ever updating it)
          rm -Rf /usr/src/redhat/BUILD/xastir-git

       Now let's either get a SPEC file to be used to package things into an RPM (if you don't already have it)
       or Update the one you already have
       #   NOTE:  the current xastir.spec file included in the Xastir sources
       #          is quite old and non-optimal.  It's recommended to us this one
       cd /usr/src/redhat/SPECS
       wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/xastir.spec

          Or now you need to update the spec file:

             #I recommend to make a backup of the spec file first
             cd /usr/src/redhat/SPECS
             mkdir Old
             cp xastir.spec Old/xastir.spec

             #Edit the spec file
             vim xastir.spec
                # If using the TrinityOS xastir.spec file, you need to update the git_commit, git_date,
                # version, and Release variables to reflect or the right revisions found above.  As of 04/13/19, 
                # that would be:
                    %global git_commit f02777ecb3deac5cf35927cf37927809fc7ad55d
                    %global git_date 20200417

                    Version:        2.1.7git
                    Release:        1.%{git_suffix}%{?dist}
                    BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

             and near the bottom of of the file, add:

                    * Sat Apr 14 2020 David Ranch <dranch@trinnet.net>
                    - Newest pre-release

             Now skip ahead to building the RPM

   Alternatively, if you used the stock Xastir spec file (NOT recommended), you'll need to edit the 
   /usr/src/redhat/SPECS/xastir.spec file to have the following lines:

             Name      : xastir
             Version   : 2.1.7git
             # Icon    : src/xastir.xpm
             Source    : http://prdownloads.sourceforge.net/xastir/xastir-2.1.7git.tgz

             BuildRequires : tk, tkimg, lesstif, libXp, libXp-devel
             BuildRequires : geos, giflib, unixODBC, netcdf
             BuildRequires : GraphicsMagick, GraphicsMagick-devel, pcre-devel, proj-devel, shapelib-devel
             BuildRequires : db4-devel, perl-HTTP-Lite, perl-Device-SerialPort, perl-Test-Simple
             BuildRequires : perl-Module-Build, perl-Image-Size, perl-perl-GPS, perl-Tree-R,
             BuildRequires : perl-Geo-Shapelib, perl-Test-Simple, perl-Module-B

          # Later down, in the description section, add:

             CVS ver: 7/1/16 - same as 2.0.8 Official

          # Later down, you need to modify the %configure line to read:

             %configure CPPFLAGS="-I/usr/include/libgeotiff"

          # Even farther down, Change the %install line from:

             desktop-file-install \
             desktop-file-install --vendor="" \

          # Edit the following line:


            to be:


          # And below the line:      

               %config %{_prefix}/share/xastir/sounds


               %config %{_prefix}/share/xastir/scripts

          # Finally, delete the line


      OK!  You're ready to build it!  Let's go:

             Centos 6
             #For Centos6 users with x86_64
             #  build took 1min 1s on an i5-2430 2.40GHz laptop w/ 4GB RAM and a SSD drive
             # Do NOT run this rpmbuild command as the root user
             time rpmbuild -bb --target=x86_64 xastir.spec

             Centos 5
             #For Centos5 users with i686
             # Do NOT run this as the root user
             rpmbuild -bb --target=i686 xastir.spec

      Now, it's hugely important to look back in the rpmbuild logs and review how the 
      configure stage went.  Make sure that the features you expect to be enabled in 
      Xastir are there.  In my setup, I see:

            xastir 2.0.9 has been configured to use the following
            options and external libraries:                      

            MINIMUM OPTIONS:
              ShapeLib (Vector maps) ................. : yes

              GraphicsMagick/ImageMagick (Raster maps) : yes (GraphicsMagick)
              pcre (Shapefile customization) ......... : yes              
              dbfawk (Shapefile customization) ....... : yes              
              rtree indexing (Shapefile speedups) .... : yes              
              map caching (Raster map speedups) ...... : yes              
              internet map retrieval ................. : yes (libcurl)    

              AX25 (Linux Kernel I/O Drivers) ........ : yes
              libproj (USGS Topos & Aerial Photos) ... : yes
              GeoTiff (USGS Topos & Aerial Photos) ... : yes
              Festival (Text-to-speech) .............. : yes
              GPSMan/gpsmanshp (GPS downloads) ....... : yes

      Assuming the features are there and the RPM package was created, time to install it!
          # Centos6
          sudo rpm -Uvh /home/dranch/rpmbuild/RPMS/x86_64/xastir-2.1.7git-1.20200417gitf02777ec.el6.x86_64.rpm

       ** Critically IMPORTANT:                                              **
       **                                                                    **
       **   One last but CRITICAL step for first time or updated installs    **
       **                                                                    **
       **   Xastir requires root privs to access specific parts of the       **
       **   system.  Specifically.. accessing the Linux AX.25 stack if you   **
       **   intend to use that setup (what this document specifically        **
       **   details) or optinally setting the system time directly from a    **
       **   connected GPS. To support either option, you need to issue this  **
       **   command to enable "suid root":                                   **
       **                                                                    **
       **                sudo chmod 4755 /usr/bin/xastir                     **
       **                                                                    **
       **   It's worth noting that the Xastir program does NOT run with      **
       **   SUID root permissions all the time.  Special care was given to   **
       **   keep the root access to a minimum and drop all elevated          **
       **   privledges whenever possible.  If you're not using the Linux     **
       **   AX.25 stack, are using a GPS but don't want to enable SUID root  **
       **   access, you can alternatively install the gpsd daemon (as this   **
       **   document recommands) and get the GPS data that way.              **
       **                                                                    **
       **   --                                                               **
       **                                                                    **
       **   A previous reason to give SUID root to the Xastir program  was   **
       **   to access the serial port connected to the TNC but that approach **
       **   is now obsolete as the modern solution for this is to use        **
       **   the "dialout" UNIX group to allow this access. To use this       **
       **   approach, issue the following command:                           **
       **                                                                    **
       **                sudo adduser  dialout                     **
       **                                                                    **
       **   Replace  with your Linux username.  Once complete,     **
       **   completely log out of the XWindows system (not just exiting a    **
       **   specific terminal window) or reboot the system to make the OS    **
       **   recognize your new unix group addition                           **

19b3. - Xastir Sounds - Create the associated sound package

Now that you have the core Xastir program installed, you need to create and install 
the separate Xastir sound file package.  Fortunately, this is easy to do!

   #Xastir's native SRPM from the source code almost works!
   cd /usr/src/redhat/BUILD
   mkdir xastir-sounds-git
   cd xastir-sounds-git

   #Get the WAV files
   git clone https://github.com/Xastir/xastir-sounds.git

   #Let's get some details about the Git code.  Run the following commands:

      cd xastir-sounds
      git tag

      #Here, you'll see there is one tagged version called "v1.0" so lets use that with:
      git checkout tags/v1.0

   # Next, update this mv command and the tar command below to reflect the correct version name
   # from above:
   cd ..
   ln -s xastir-sounds xastir-sounds-1.0
   # Next, clean up a few things and create the archive name with the correct version, Git tag version 
   mv xastir-sounds-1.0/README.md xastir-sounds-1.0/sounds
   tar czvf /usr/src/redhat/SOURCES/xastir-sounds-1.0.tgz xastir-sounds-1.0/* --exclude xastir-sounds-1.0/.git

   #You can now optionally delete the Git repo
   cd ..
   rm -Rf /usr/src/redhat/BUILD/xastir

   Now let's get a SPEC file to be used to package things into an RPM
   cd /usr/src/redhat/SPECS
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/xastir-sounds.spec

   OK!  You're ready to build it!  Let's go:

          Centos 6
          #For Centos6 users with x86_64
          #  build took 1m1s on an i5-2430 2.40GHz laptop w/ 4GB RAM and a SSD drive
          # Do NOT run this as the root user
          time rpmbuild -bb --target=noarch xastir-sounds.spec

          Centos 5
          #For Centos5 users with i686
          # Do NOT run this as the root user
          time rpmbuild -bb --target=noarch xastir-sounds.spec

19b4. - Xastir - Configuring and running the APRS tool

I've used Xastir with both Linux soundmodem and the Kenwood D710.  For
this example, I'll configure it with the D710 and I'll add soundmodem 

  - Start up the D710 in 1200 baud packet mode on channel A

  - Tune the radio to 144.390

  - Make sure you set the squelch properly so an idle frequency isn't 
    "busy".  Unless this it set, you'll never transmit!

  - Start up your TNC into KISS mode.  Ideally, use my "packetrig.sh" script 
    to start up the D710 TNC in KISS mode

        /usr/local/sbin/packetrig.sh vhf-d710-xastir

  - Start up xastir on the command line

  - Set up your system to something like the following:

    File --> Configure --> Station
     +-- Configure
     |       |
     |       +-- Station
     |       |       |
     |       |       +-- - put in your callsign
     |       |                no "-#" if this is a stationary home, no digipeat
     |       |                  if a stationary home that digipeats
     |       |                  digipeater on 70cm
     |       |                  additional station 
     |       |                  HF to VHF gateway
     |       |                  Igate/dstar/ system (not at home QTH)
     |       |                  special activity:satellite Ops:camping
     |       |                  Human portable like HT APRS
     |       |                  Marine (boat, ship, etc.)
     |       |                  Mobile
     |       |                 Internet-access only (no RF used)
     |       |                 Balloons / aircraft, etc
     |       |                 APRS-touchtone / one-way trackers
     |       |                 WX stations
     |       |                 Truckers
     |       |                 additional station like HF users
     |       |
     |       |            - if you know your location in GPS coordinates, put them in
     |       |
     |       |              KI6ZHD's QTH GPS coordinates (according to a Delorme PN40)
     |       |
     |       |                       Lat:   37 degrees 20.613N 
     |       |                       Long: 121 degrees 59.986W
     |       |
     |       |              NOTE #1: These static values will be overridden
     |       |                       if you enable a GPS unit
     |       |
     |       |              NOTE #2: if your APRS system is going to be stationary (say a house), 
     |       |                       then you should NOT use a GPS.  GPS receivers have positioning
     |       |                       errors / noise especially if the receiver doesn't have a clear
     |       |                       of the sky.  This positioning errors will show your house 
     |       |                       MOVING around!  Worse.. if smart beaconing is enabled, each incorrect
     |       |                       change in position mean a radio transmission which will reduce the
     |       |                       life of your radio, fill up the radio spectrum with worthless beacons, 
     |       |                       etc.
     |       |
     |       |              Coodinates: The easiest way I've found to find out your GPS coordinates is:
     |       |              
     |       |                - Goto GoogleMaps and type in your address
     |       |                - turn off the 45 degree mode and center the
     |       |                  view to where your antenna is
     |       |                - On the left hand NAV, you'll see the chain-link
     |       |                  icon.  Right-click that and "Copy link
     |       |                  location.  For me, the link would be:
     |       |                  
     |       |                  http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=3739+Benton+Street,+Santa+Clara,+CA
     |       |
     |       |                  see at the end of that mess of a URL the value:
     |       |                  "37.343535,-121.999908"  That's the WGS84 Decimal 
     |       |                  degrees value.  Now go to the following URL to translate 
     |       |                  that WGS84 Dec.Degree position to GPS coordinates:
     |       |
     |       |                      http://boulter.com/gps/?c=
     |       |
     |       |                  To confirm the location, click on CALC and
     |       |                  then Calculate to make sure it's in the right 
     |       |                  grid square.  You will want to use the "GPS"
     |       |                  values for use in Xastir (not Degrees, Minutes, Seconds)
     |       |
     |       |            - click on SELECT in the station symbol section
     |       |              and select your desired icon
     |       |            - select the proper output power
     |       |            - select the proper height above average terrain.
     |       |              Do NOT use average height above sea level or 
     |       |              height above ground. 
     |       |            - antenna gain on 2m
     |       |            - antenna type on 2m
     |       |            - enable ambiguity if you don't want show your
     |       |              exact location
     |       |
     |       +-- Defaults
     |       |       |
     |       |       +----- Transmit station type: [select the right one]
     |       |            - ENABLE: Transmit compressed objects/items
     |       |            - ENABLE:  POPUP new bulletins
     |       |
     |       +-- Audio Alarms
     |       |       |
     |       |       +----- Audio Play Command: play -q
     |       |       |
     |       |       +----- The audio files that come as part of the xastir-sounds package are VERY basic
     |       |              and I don't use them.  I personally use the following sounds from other
     |       |              packages and I only enable notifications for new messages as getting new station
     |       |              notifications in a busy APRS area becomes annoying very quickly:
     |       |        
     |       |                  - New Station: KDE-Im-User-Auth.ogg     from the kdebase-runtime RPM
     |       |                  - New Message: KDE-Im-Sms.ogg           from the kdebase-runtime RPM

   Now, go to:

    File --> Configure --> Station
     +-- Configure
     |     |
     |   Message
     |     |
     |     +-- Enable "Satellite ACK mode"  - this makes sure that digipeated
                                              ACKs are accepted (screwy you have
                                              to enable this!!)

   Next, go to:

     +-- Interface Control
           +-- Add: AX25 TNC
                 +--- - UNCHECK: activate on startup
                      - CHECK: Allow transmitting
                      - UNCHECK: Digipeat?
                      - AX25 device name: d710
                        The above assumes the same /etc/ax25/axports file
                        as set by dranch's HamPacket documentation
                      - CHECK: Allow RF to Inet traffic ONLY
                      - For a high density Metro area like the Bay
                        Area, make it "Path 1: WIDE1-1" and nothing else
                        If you live farther out, make it:
                           Path 1: WIDE 1-1
                           Path 2: WIDE 2-2

    Finally, go to Interface, interface control, click on 
        "AX25 TNC d710" to have it highlighted and click on "Start"

    Now let's setup the the maps!  It's worth specifically mentioning that Xastir
    allows to overlay multiple maps ON TOP of each other.  This is done by having 
    multiple maps highlighted in BLACK.  For now, I don't recommend to do that.
    To get started with some Online maps, try the following (requires your machine
    is connected to the Internet).  Goto:

     +-- Map Chooser
             +-- click on "Online / OSM_tiled_fosm.geo"
                 +-- In the upper right, click on Properties
                     +-- Click on the top line and in the lower section, enable:
                           Filled:   YES
                           AutoMAPS: YES
                           USGS DRG: YES

                           Click on Close
                           Click on OK

    In the lower left window of Xastir, you'll see the status line read something like:

       Downloading tile 1 of XX where the "XX" is the number of tiles for your given "zoom" 
       level. The speed of the download and rendering depends on your Internet speed and
       your computer's speed.  One good thing here is that once downloaded, the given 
       area and zoom level tiles will be locally saved so it will be faster next time.

Now go to View --> Incoming data and watch the incoming objects start to appear on 
the maps!

    - I would recommend to let things come in and let you get an idea of how things
      look.  Use a combination of the UP/DOWN/LEFT/RIGHT and zoom IN/OUT buttons to
      explore around.  Remember, every time you change your position or zoom, your 
      computer will have to download new tiles so it can take some time

19b4. - Xastir - Tuning for better look and feel

    - Personal preference: I find that Xastir's default map "brightness" as too 
      low and too much data about each station is too detailed (gets VERY cluttered) 
      in busy APRS areas.  To improve this, goto:

             +--> Configure
                     +-->  Blackground Color:  White
                     +-->  Map Intensity:      80%
                     +-->  Station Text Style: Black shadow
                     +-->  Icon Outline Style: No outline
                     +-->  Icon Outline Style: No outline

    - BTW, if you have a serial GPS to use for Xastir, connect
      it FIRST and then start Xastir.  At that point, you can 
      add either a "serial GPS" or "networked GPS (gpsd).

      NOTE on serial GPS: Once added and started, it took 2-3 minutes 
                          before Xastir considered the GPS input as good 
                          and functional

19c. - Other APRS Clients for Linux

On of my most recent projects was looking to create an APRS client for the Raspberry 
Pi.  I was looking for an APRS client (not server) for Linux that can support listening 
to a serial or UPS GPS, transmit said GPS coordinates with Smart-beaconing, all while
using Linux's native AX.25 stack  but run from the command line. All of those requirements
were very difficult to find anything but here is what I found:

  - Xastir: Very nice (covered above) GUI client
       a) A very large install and a quite heavy weight program
       b) Requires Xwindows to run (Xwindows is heavy weight in itself)
       e) supports creating APRS objects, APRS messaging, etc

  - APRX - A very powerful APRS server, digipeater and Igate server
       a) under active maintenance
       b) natively supports GPSes
       c) doesn't support smart-beaconing
       d) doesn't have any graphical display / maps
       e) supports creating APRS objects, ec
       f) doesn't support APRS messaging

  - YACC: Runs under Java and I *think* this is also GUI
       a) very there is very little information out there
       b) I don't want to run a memory hungry JVM on my Rpi
       c) supports creating APRS objects, APRS messaging, etc

  - Direwolf:  The soft-TNC program is a pretty competent APRS client (no GUI display).  
    It includes:
       a) under active maintenance
       b) APRS object, position, and smartbeaconing with GPS support
       c) Telemetry and WX reports
       d) Intelligent digipeating Igating 
       e) DTMF Touch-Tone support
       f) Direwolf REQUIRES to have a soundcard be associated with it or it won't start
       g) doesn't support APRS messaging

  - DIGI_NED - Extremely powerful APRS digipeater and APRS server:
       a) Not actively maintained - hasn't been updated since 2009
       b) natively supports GPSes
       c) doesn't support smart-beaconing
       d) it's a port from DOS and it's configuration is very complex (too many features)
       e) doesn't have any graphical display / maps
       f) doesn't support APRS messaging

  - N7NIX's NIXTracker - a port of KK7DDS's Dantracker 
       a) adds Linux AX.25 stack support
       b) runs it's own web server to display the detail via any remote JavaScript web page, 
       c) adds IGATE support
       d) APRS messaging, and more

  - KK7DDS - Dan Smith's Original "Dan tracker" 
       - very light weight system that supports GPSes, Smart-Beaconing, and runs from the command line but 
       a) Not actively maintained - See N7NIX tracker above as a possible replacement
       a) only supports KISS TNCs (no native Linux AX.25)
       b) the optional display is via a GTK+ window via Xwindows

I have all of this running with my Raspberry Pi using Linux's AX.25 stack with a TNC-Pi 
today but adding all of that into this document is probably not going to work.  The
highlights on that setup is:

   HW:  512MB Raspberry Pi with USB GPS
        TNC-Pi add-on board for a complete TNC-X TNC
        USB WIFI for remote control, monitoring and full login from smartphones, 
            tablets, etc
        USB-based GPS

   OS:  F6BVP's Raspbian OS for Raspberry Pi which includes:
         - LXDE Xwindows environment with Pidora web browser, etc.
         - full VE7FET AX.25 lib/apps/tools support
         - Raspbian optimizations from KI6ZHD for RAM drive logging, compiling toolchain

       - FBB BBS
       - FPAC Node
       - aprslist digipeating
       - ax25ipd Internet / AMPR tunneling
       - DX Spider packet cluster
       - Rose, Flexnet, and Netrom routing

If you have any questions about the Raspberry Pi setup, feel free to email me until
I start writing up my docs

19d. - APRX - APRS iGate + digipeater software

APRX is a powerful APRS Digipeater and Internet Igate server that can be used to
tightly control with:

  - Used as a generic digipeater for APRS or even AX.25 UI unproto traffic

  - gateway APRS traffic to/from the RF domain into the APRS-IS Internet gateways
    with various complex filtering options

  - Inject one or more APRS objects into the RF / APRS-IS domains 

  NOTE:  APRX does not directly support sending APRS position posits as
         learned from GPS.  If you want something like this (an APRS 
         client), I recommend to check out N7NIX's version of 
         DanTracker found at:


Ok, to get started, it should be noted that APRX is getting new code support from 
W6KWF.  Though it's not official yet, the new temporary source code repo has
some badly needed fixes:

   W6KWF patched sources (RECOMMENDED):
   cd /tmp
   git clone https://github.com/PhirePhly/aprx.git
   cd aprx
   #last GIT commit
   GITVER="`git log --date=short | grep -m1 commit | awk '{print $2}'`"
   GITMAJVER="`git log | grep -m1 -e commit | awk '{print $2}' | cut -c -8`"
   GITDATE="`git log --date=short | grep -m1 Date: | awk -F: '{print $2}' | awk -F- '{gsub(/ /, "", $0); print $2$3$1}'`"
   git archive --format=tar --prefix=aprx-$MAJVER/ $GITVER | bzip2 > /usr/src/redhat/SOURCES/aprx-$MAJVER-$GITDATE\git$GITMAJVER.tar.bz2
   rm -Rf aprx
   #Now skip to the next portion of this section

      (NOT RECOMMENDED): Using the original OH2MQK APRX sources (has known issues)
      cd /usr/src/redhat/SOURCES
      wget http://ham.zmailer.org/oh2mqk/aprx/aprx-2.06.svn514.tar.gz

   Get an RPM Spec file:

      RECOMMENDED: Next, we need an RPM spec file.  You can get the pre-configured SPEC file at


      (NOT RECOMMENDED) - Roll your own RPM spec file
      cd /usr/src/redhat/BUILD
      tar xzvf ../SOURCES/aprx-2.06.svn514.tar.gz 
      mv aprx-2.06.svn514/aprx.spec /usr/src/redhat/SPECS/

         At this point, we have to edit the SPEC file as this file
         has broken logic to deal with SystemD based distros like Centos7, Fedora18, 
         - Edit the aprx.spec file and delete both the following 
           lines and everything between them:
           %if 0%{?rhel} >= 7 || 0%{?fedora} >= 16
           . thru

       - Next, there are some options you might think about enabling
         in the "%configure --with-erlangstorage" line:  

            - pthreads support : To enable this, add the text

            - agwpe support : to enable this, add the text:


               When I tried to compile AGWPE support, the compile failed with the following.
               Maybe in future versions, this issue will be resolved.
               agwpesocket.c:461:2: warning: #warning "WRITEME: AGWPE Raw AX.25 reception"
               agwpesocket.c: In function ‘agwpe_prepoll’:
               agwpesocket.c:663: error: invalid operands to binary & (have ‘time_t’ and ‘struct timeval’)
               make: *** [agwpesocket.o] Error 1

           - Save your changes to the spec file

Now let's compile it up:

          Centos 6
          #For Centos6 users with x86_64
          cd /usr/src/redhat/SPECS
          rpmbuild -bb --target=x86_64 aprx.spec

          And install it:
          rpm -ivh /usr/src/redhat/RPMS/x86_64/aprx-2.06.svn514-1.el6.x86_64.rpm

Time to configure it.  In this example, I'm going to do two things:

  1. Install a APRS-IS object for the local packet station
     that can be displayed on say http://www.aprs.fi

  2. be a UNPROTO digipeater for my packet system on 145.050 for KB2KB 

   | NOTE: Newer versions of APRX requires an APRS-IS passcode to be configured |
   |     to support sending APRS data to APRS-IS.  Without it, your system      |
   |     sending in APRS-IS data will be silently ignored.  No APRS-IS          |
   |     connection, packet injection, etc. errors will be reported!            |

  - Edit the /etc/aprx.conf file:

      - Change the "mycall" variables to used your specific callsign.  

        I'm using "KI6ZHD" which will allow also support digipeating on the 
        "KI6ZHD" or KI6ZHD-0 SSID.

      - Change the "-1" in "passcode -1" to reflect your APRS-IS passcode.  
        If you don't know what this is, please email me and I'll help you out

      - In the <aprsis> section, # out the line:
            server    rotate.aprs2.net

        to stop using the global pool and instead, uncomment out a better server 
        pool that reflects your location on the planet.  For me, I'm un-#ing out:

            server   noam.aprs2.net


      - Find the #ed out "<interface>"stanza, un # it out out
      - Un # out the "ax25-device $mycall" line 

        NOTE: APRX does *not* read the /etc/ax25/axports file to get a valid
              ax.25 device name.  This aprx software simply matches the callsign 
              that the Linux AX.25 system puts together as configured by the 
              axports file.  To confirm which callsign is being used, bring up 
              your packet system and look at the "HW ADDR" for the "ax0" interface
              according to /sbin/ifconfig

      - Un # out the "tx-ok" line and change the "false" to "true"

      - If you want other SSIDS to support digipeating, then
        use the ALIAS line.  I'm using:

           alias KI6ZHD-5,SCLARA

        NOTE:  I've found that when a remote station digipeats to an
               alias, the output from the digipeater becomes the contents
               of $mycall and NOT the expected alias

      - Un # out the concluding "</interface>"stanza

      - Next, find the line "#beaconmode" and under it, add:

          beaconmode { aprsis }

      - Find the "beacon symbol" line, make a copy of it below, un-# it out
        and for my QTH.  APRX uses the "GPS style of coordinates and I set it 
        to the following per how I recommended to find coordinates in 
        "xastir-running" section of this document.  Notice that I:

            - Force the beacons to only go out a specific interface
            - Added the object name (8 characters max)
            - change the symbol
            - set the lat/long
            - set the comment

          beacon object "Packet N" symbol "/n" lat "3720.62N" lon "12159.99W" comment "145.050 Packet full service digi/pbbs/node"

      - Finally, un # out the "<digipeater>" line 

      - Un # out the line "transmitter     $mycall"

      - Find the example section of "source         RXPORT-1" and

        - Un # out the double #s for "<source>"

        - Un 3 out the double #s for "source         RXPORT-1" and change the 
          "RXPORT-1" to "$mycall" for my specific setup

        - Un # out the concluding # for "</source>"

      - un # out the concluding "</digipeater>" line 

Ok, your done!   To start it up to test, run the program in foreground mode.
You can put in upwards of four d's where each one adds more debugging:

   /usr/sbin/aprx -d

If it starts up with out any specific errors, go look for your configured
callsign+SSID on www.aprs.fi.  You should see it!  You can also test 
the digipeater side of things as well.  Assuming you have a local digipeater
you can bounce packets off, try using the F10 view of Linpac and

  - Change the UNDEST path - for me, I would use
       :undest "David WOODY KI6ZHD WOODY"

  - Using the F10 unproto menu, simply send "test" and you should
    see the packet be transmitted, get digi'ed from Woody, then 
    digi'ed by KI6ZHD, and then get digi'ed by Woody again

Once things are running to your liking, you can either start aprx from 
the /etc/rc.d/init.d/aprx init method or what I do, start it from the 
packetrig.sh script. 

If you want to do it the init.d route, you need to 
  - edit the /etc/sysconfig/aprx file and change the "STARTAPRX" variable to yes
  - run: /sbin/chkconfig --level=345 aprx on
  - and then start it up with: /etc/rc.d/init.d/aprx start

20. - Advanced APRS Usage

20a. - APRS functionality - Commands you can use with APRS to get information about the area around you

There are all kinds of interesting things you can learn about your local area via APRS. It all depends on what the local APRS HAMs are advertising. For example in my area: You can send/receive short email and SMS texts via APRS:

Finally, there are lots other things you can too (just a few examples):

The key thing to remember about APRS is that it's flexible and extensible. From where it started to where it is now is impressive. With the addition of the APRS-IS system, it now allows APRS radios to essentially do anything (with limitations of course). Email, small web pages, etc. were just the start and the community is just waiting for someone to contribute the next cool idea.

20b. - APRS-IS Email - How HAMs can send short Internet SMTP emails back and forth to an APRS station

There is a very slick feature of the JavAPRServer software that can relay messages 
between two HAMs where one is using Internet and the other is using an messaging 
capable APRS station.  It's described here:


but page is a bit terse and it was a bit confusing for me the first time I used
it.  Hopefully this section will help explain things a bit to make it easier to

To get started, there are a few key key concepts to consider:

  1. The Internet based email sender MUST be a HAM and follows all FCC Part.97
     rules (that includes various CEPT agreements, etc).  The Internet 
     based person WILL be sending APRS packets onto the RF!

  2. To remove SPAM, the APRS user has to do two things:

      a. white-list every single email address he or she ever expects to get
         a message from.  This can be tedious but it's important - See below

      b. Has to convey the very specific "shortcut" to that remote HAM and
         they must use that shortcut in every message or the delivery will
         be blocked

  This example's details

     - Let's say your name is Mark who is is a licensed HAM with a properly 
       working messaging capable APRS RF radio (Kenwood D710, Yaesu FT350, 
       homebrew setup, etc) with the call 'BBY7YY-7' (yes, this is an 
       invalid callsign..  this is just an example).  Your email address is

          Notice that I'm using the example SSID of -7 here.  There are 
          recommended SSID guidelines at http://aprs.org/aprs11/SSIDs.txt 
          but it technical doesn't matter which SSID is chosen ***but*** 
          the remote Internet based HAMs must know which SSID you are using!

     - You have a friend named Joe, who is a licensed HAM with the callsign 
       'AAX0XX' and has the email address 'aax0xx@example.com'

     - You have another friend, Paul, who is another licensed HAM with the 
       callsign 'QQN4NN' and has the email address 'qqn4nn@gmail.com'

  - To get started, Mark 'BBY7YY' will need to configure "shortcuts" which map 
    to the allowed *incoming* email addresses from remote HAMs out on the Internet.
    This *must* be done via a an APRS terminal (RF based setup like a Kenwood D710, 
    Yaesu FT-350, etc) or via an APRS-IS enabled computer/client like 
    Xastir, web sites like www.openaprs.net, and even APRSDroid on a smartphone/tablet, 

       Now Mark (that's you) will create a new shortcut for yourself to do some testing
       via an APRS message:

         APRS source callsign: BBY7YY-7                 (the SSID used to create shortcuts doesn't matter)
         Destination Callsign: EMAIL-2                  (note: the source callsign **MUST** be all CAPITALs)
         APRS message        : me bby7yy@yahoo.com      (you can substitute 'me' for any 'alias' you'd like)

         Send it!

       Ok, check to see if it was set properly.  To do that, you can use the "l" or "list" command:

         APRS source callsign: BBY7YY-7                 (the SSID used to create shortcuts doesn't matter)
         Destination Callsign: EMAIL-2                  (note: the callsign **MUST** be all capital letters)
         APRS message        : me l                     

         Send it!

         At this point, the bby7yy@yahoo.com email address should receive an email that looks like:

            From   : <write down this email address, you'll need it later>
            Subject: BBY7YY: Shortcut list
            Body   : me=bby7yy@yahoo.com

       If you got that message, that means it working!  If you didn't, review and 
       try again until things work.  BTW, I'm working on a universal scheme here but
       if you have multiple email addresses that you might send/receive messages 
       from, you probably want to setup multiple aliases for yourself.  For example,

              shortcut : email address
              me         bby7yy@yahoo.com
              yy         bby7yy@yahoo.com
              yyyahoo    bby7yy@yahoo.com
              yygmail    bby7yy@gmail.com

       Ok now lets create shortcuts for other friends / remote callsign you 
       might want to send messages to.  This will be done via one APRS message per
       remote callsign.  Let's start by adding Joe:

         APRS source callsign: BBY7YY-7                 (the SSID used to create shortcuts doesn't matter)
         Destination Callsign: EMAIL-2                  (note: the callsign **MUST** be all capital letters)
         APRS message        : joe aax0xx@example.com   (you can substitute 'joe' for any 'alias' you'd like)

       That's it.  Mark (you) sends the APRS message and would   get a 
       nearly immediate response saying the shortcut was added.  Ok, let's 
       repeat that last step to add Paul:

         APRS source callsign: BBY7YY-7
         Destination Callsign: EMAIL-2                  (note: the callsign **MUST** be all capital letters)
         APRS message        : paul qqn4nn@gmail.com    (you can substitute 'paul' for any 'alias' you'd like)

       Done!  To confirm them, send a "list" request from your APRS radio:

         APRS source callsign: BBY7YY-7
         Destination Callsign: EMAIL-2                  (note: the callsign **MUST** be all capital letters)
         APRS message        : joe l
         Send it!

         [You should receive an email addressed to bby7yy@yahoo.com about this new "Joe" shortcut

         APRS source callsign: BBY7YY-7
         Destination Callsign: EMAIL-2                  (note: the callsign **MUST** be all capital letters)
         APRS message        : paul l

         [You should receive an email addressed to bby7yy@yahoo.com about this new "Paul" shortcut

  - Next, here are a few critical details to remember:  
      Once the shortcuts are configured, Mark (you) would need to communicate the 
      following details to Joe, Paul, and any other remote HAMs you just setup 
      aliases for:

         a) what Internet email addresses you will accept messages from for the 
            shortcut(s) you configured - you would tell:
                 Joe is enabled for "aax0xx@example.com"
                 Paul is enabled for "qqn4nn@gmail.com"

         b) what SSID you will be using on on your APRS RF station (-7 is used
            in this example)

         c) what their associated "shortcut" name is for this specific email address
            This would be "joe" and "paul"

  - Send a message from APRS to ***Joe's*** email:
    - Ok, so we're going to send a message to Joe's email account.  
      Create a new APRS message that is a max message size of 67 characters

         APRS Source Callsign: BBY7YY-7
         Destination Callsign: EMAIL-2 
         APRS message        : joe Hey this is Mark sending from my APRS station!

      - The key points here are:

            - The space between the shortcut text and the actual message is MANDATORY

            - The text "joe" starting the APRS message actually looks up the 
              proper email address as configured by Mark.  The rest of the text 
              on that string will become the actual email message!

      - Send this new APRS message and you should get a nearly immediate response 
        saying it was sent

  - Joe to send a reply message from Joe's email address back to Mark's APRS station:

    - Joe creates a email:

         Email source address:      aax0xx@example.com      <--- must be the same email address 
                                                                    configured in the shortcut

         Email destination address: [the one I told you to remember above, also see below for details]

         Email subject:             BBY7YY-7:Mark, good to hear from you.. cool APRS tool eh?

                                    (The callsign and the SSID number MUST be the same SSID that Mark's
                                     remote APRS device is configured to listen to
         Email body:                userid:joe:

                                    This above string is the secret-sauce that makes this work,
                                    specifically using the configured "shortcut" that MARK configured
                                    to allow Joe's email address of aax0xx@example.com to send 
                                    jim APRS messages.  If Joe doesn't know what Mark named his
                                    shortcut for his email address, it's not going to work!  You
                                    *must* know this.  If you can't remember, try some guesses

            - If the message is accepted, it will be immediately sent out on APRS.  If 
              the remote station doesn't acknowledge the message within the timeout period,
              Joe will receive a reply email saying:
                    Subject:  APRS Message Delayed

              At this point, Mark has 24hrs to remotely fetch all his messages before they
              are deleted


      - Again, there are several KEY points here that are critical for this reverse 
        communication path:

            - Joe has to make sure he sends the email from the specific 
              AAX0XX@example.com email account that Mark previously configured

            - You need to know that special email destination to get to the gateway.
              (the email address received above in your test message, also see below)

            - In the subject line of the email: 

                - the remote APRS HAM's callsign **must** be in all capitals
                - you're using the correct SSID for the remote APRS callsign
                - after the SSID, it's followed by a ":"

            - After that trailing colon, you have 67 characters to write your APRS 

            - In the email body itself, you MUST:
                - enter in the "userid:" text, then 
                - enter in the shortcut name that was previous configured to accept 
                  messages from that email address, then
                - the trailing ":"

              NOTE about forgetting / listing all shortcuts:
              - If you don't remember the shortcuts you created for Joe, Paul, 
                or anyone else, there is ***NO WAY*** to list all previously 
                configured shortcuts!  Bummer!  This also means that of your
                friends that are sending you messages via APRS, you won't be
                able to message them back until you both configure NEW 
                shortcuts AND tell your friends what the new shortcuts are!

              - If you forgot that trailing colon characters, sending messages
                won't work though the EMAIL-2 system won't give you a clear 
                error report on why.  Bummer!

  - Other nice features!
    - From an APRS station: 

         - [fetching old messages]: Let's say your APRS radio has been off for a 
           while and you might have missed some messages.  Simply send a message 
           to EMAIL-2 with the word "get".  You will be sent any messages you missed
           for the last 24hr period

         - If you send a message to EMAIL-2 to a configured shortcut (email address) with
           an "l", they will be emailed a LIST of all their shortcuts

         - if you send a message to EMAIL-2 to a a configured shortcut (email address) with
           an "r", that  shortcut will be REMOVED


    Remote APRS-IS destination email address:
      Remember that email address I told you to write down during your first tests?
      Here is why it was so critical to save it:

      The internet email destination you use to send APRS users messages to your
      shortcuts  is *intentionally* missing from this document. This is to make sure that 
      YOU (the reader) makes sure you're following Part.97 and/or consider your specific 
      country's Amateur Radio regulations.  Withholding this address is also a strong 
      mechanism to to avoid abuse (spam, use by non-HAMs, etc) being sent to that system.  
      If you forgot to write this email address down, just send yourself another test
      message (shown above) or alternatively, send me an email and we'll take it from there.

  - Troubleshooting:
    When I was first figuring out this system from the original web page, I was stumped
    a few times.  I found the "messages" area of APRS.FI looking at this EMAIL-2 
    callsign was VERY helpful!


  - Alternatives to the EMAIL-2 System:
    Thought the EMAIL-2 system works, it's really not very intuitive to me and requires
    communicating the specific configured shortcuts to the remote HAM *beforehand*.  That's
    sometimes difficult and impossible to use if not setup first.  Fortunately, the Winlink 
    2000 system has the APRSLink system which is a lot easier to use and will keep old pending
    messages around for a LOT longer

    Check out the Winlink section later in this document on how to use that system.

20c. - APRS-IS Email via Winlink

Jump to the Winlink Messaging Section for full details.

21. - UI-Chat

UI-Chat is a program from Mitch Winkle (AB4MW) which is a fusion of the mixed chat and
automated response system of FSQ (available in the FSQCall and Fldigi program).  What
makes UI-Chat different is that sends it's packets in AX.25 UI frames any interface that 
supports KISS.  Putting it another way, this program can work with classic 1200 AFSK
TNCs, Direwolf SoftTNC programs, but also programs like Fldigi with it's new TCP-KISS
interface.  But Fldigi already supports FSQ you say?  Well, FSQ in the above programs only
support it via the Incremental Shift Keying (IFK) mode which is designed for NVIS 
communications.  While this mode has it's strengths, it can't match some of the other
modes that Fldigi can support like Olivia, etc.  UI-Chat offers the best of both 

Let's get started with the intent to use it with Fldigi on HF: 

  - You need to have Fldigi or newer installed and working on your
    machine.  Please see the Fldigi section for full details on how to get that

  - You need to configure Fldigi for TCP-KISS mode.  This is fully covered in the 
    "Advanced Configurations with Fldigi" section

  - You need to install Java as UI-Chat is a Java application.  Please read the 
    above "Advanced Configurations with Fldigi" section on PSK Mail on how to 
    get Java installed.

  - Next, if you want to use UI-Chat with a hardware TNC via serial port, you need 
    to install the rxtx-java library.  This is simply a matter of running:

       sudo yum install rxtx

  - Now download UI-Chat.  

       # To be packaged later - unlike most programs, this doesn't need to be 
       # compiled nor installed to work

       mkdir -p /usr/src/archive/Uichat
       wget http://downloads.sourceforge.net/project/uichat/2.0/UIChat20160507.zip
       unzip UIChat20160507.zip
       mv UIChat UIChat20160507

21.a. - Configuring and Running UI-Chat

  - Turn on your radio, make sure it's on a available frequency, the antenna is
    all tuned up.  Per the UI-Chat Google+ community at


    the common frequencies are:

      VFO Dial Frequencies + 1500 Hz Audio

         3.586 Mhz USB
         7.101 Mhz USB
        10.141 Mhz USB
        14.101 Mhz USB
        18.106 Mhz USB
        21.091 Mhz USB
        24.926 Mhz USB
        28.101 Mhz USB

  -  Start up Fldigi as you normally would and put Fldigi into TCP-KISS mode per 
     the "Advanced Configurations with Fldigi" section.  Be sure to have the 
     "Listen/Bind" checkbox marked and then click on "Connect" to have Fldigi 
     ready to be used by UI-Chat

  - Now start UIChat with:

      java -jar UIChat.jar

  - You will now be presented with a configuration screen.  On the "Network" tab:

     - Select "KISS TCP modem"

     - In the bottom selection, change the TCP port from 8001 (what Direwolf uses) 
       to 7342 (what Fldigi uses)

     - On the "Station" tab:

        - Change the "station callsign" to your callsign without any SSIDs
        - Update your name
        - QTH (location)
        - Station info message (something like): UIchat on Fldigi w Centos Linux 6.7
        - Current Status message: leave me a message
        - Sounding (beacon) text: UIChat running with Fldigi / Centos Linux from Santa Clara, CA
        - Grid square (6 digit): CM97ai

  - Click on Save

  - Back in the main UI-Chat window, click on "Sounding is OFF" to turn on soundings 
    aka beacons

22. - Compiling and Configuring ARDOP and ARIM

This is ARDOP-gui, a pretty GUI representing the performance of ARDOP

ARDOP is a relatively new HF modem suite developed by Rick Muething KN6KB which intended 
to be an open (aka free), multi-platform HF data modem.  It's original intention was to be
a replacement for the Winlink team's original Windows-only "Winmor" TNC with various 
improvements.  John Wiseman G8BPQ has created a port of this modem which works both on 
Linux and the Teensy / ARM Cortex-M0+ microcontroller processor.  The ARDOP modem
is just that, just a modem and it needs another application to drive it.  Examples
include ARIM (described below), the Winlink "Pat" client, etc.

The ARDOP modem can operate either locally or over a LAN network to support reliable 
high performance data transfers over RF.  This modem is actually a SUITE of several 
DIFFERENT digital modes underneath offering settings for various speeds, FEC (foreard 
error correction) levels, ARQ (Automatic Request), and a mixture of both FEC and ARQ.  
What's unique to this modem is that it's a system that switches modes and speeds as the 
RF band conditions change.  This dynamic selection is something that both PACTOR and 
WINMOR have done for years but either those solutions required very expensive hardware 
TNCs or only worked on Windows.  

There are two versions of ARDOP today v1 and v2.  The v1 version is stable and is the 
commonly found version on RF today.  v2 has been a work in progress and has been recently
found to have some serious performance issues with slightly off-frequency stations.  It 
sounds like v2 might be REVOKED from use until a newer version is released.  As such, 
developers are NOT recommending users to use it today.

This section is going to detail getting ARDOP v1 working via the Linux version.  You can 
learn more at:


More details about ARIM are mentioned in a following section.

22.a. - Compile and Install ARDOP

Let's get started with the ARDOP TNC first.  The ARDOP modem is mostly stable now and works
quite well.  I'd recommended to join the ARDOP email list at the below addresses to keep 
tabs on what's going on but things are generally ready to use:


You can find pre-built ARDOP binaries for some Linux systems available here:

   Linux x86   - http://www.cantab.net/users/john.wiseman/Downloads/Beta/ardopc
   Linux ARM   - http://www.cantab.net/users/john.wiseman/Downloads/Beta/piardopc
   Windows x86 - http://www.cantab.net/users/john.wiseman/Downloads/Beta/ARDOPC.exe

but it's never 100% reliable to use pre-built binaries on different Linux distros.  To 
get 100% operating support, I only recommend to build the modem from the source code.  
As such, let's do that though I have created a Linux shell script which automates all 
of the below steps if you want to give it a try:


If you wish to do things manually the first time (always a good idea in my book), download 
the newest ARDOPC sources. These are now embedded in John's larger project archive which
includes many other projects as well.  As of this writing, ARDOP is at version

   cd /usr/src/redhat/SOURCES/

   # The ARDOP code used to be ARDOPC.zip file but this archive was deprecated as of 3/27/18.
   # The new location for the modem code is now buried in the TeensyProjects.zip file
   wget http://www.cantab.net/users/john.wiseman/Downloads/Beta/TeensyProjects.zip

   #Now rename the unversioned TeensyProjects file to something more trackable
   mv TeensyProjects.zip TeensyProjects-`date +%m%d%y`.zip

Now let's massage the code it to get it into a targeted archive:

   cd /usr/src/redhat/BUILD
   unzip ../SOURCES/TeensyProjects-`date +%m%d%y`.zip

   # Determine the version of ARDOP and make the naming convention compatible with 
   # RPMs (the previous suffix of "-BPQ" isn't allowed in RPM packaging, etc)
   VER=`grep ProductVersion TeensyProjects/ARDOPC/ARDOPC.h | awk -F\" '{print $2}' | awk -F\- '{print $1}'`

   #This should look like:
   echo $VER

   #Now pull out the ARDOP code, rename the archive name, archive, and delete the old zip file
   mv TeensyProjects/ARDOPC ardopc-$VER
   tar czvf /usr/src/redhat/SOURCES/ardopc-$VER.tgz ardopc-$VER/*
   rm -Rf ardopc-$VER
   rm -f /usr/src/redhat/SOURCES/TeensyProjects.zip

Next, download an example RPM SPEC file for it:

   cd /usr/src/redhat/SPECS
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ardopc.spec

Next, edit the ardop SPEC file to make sure the version number from the downloaded TeensyProjects
file matches:

   vim /usr/src/redhat/SPECS/ardopc.spec

Now build it:

   rpmbuild -bb --target=x86_64 ardopc.spec

and install it

   sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/ardopc-

22.b. - Configure ARDOP

The ARDOP modem requires a special 12Khz sampling rate instead of the standard 44.1 
or 48Khz sampling rate that most Linux soundcards offer.  To enable this this resampling, 
create the following file in your home directory (yes, the '." in the front of the name 
is REQUIRED).  You also must change the "card" and "device" names to match the ALSA 
soundcard that's connected to your desired radio as shown in the output from the Linux 
Alsa command ..  "aplay -l":

   vim $HOME/.asoundrc
   pcm.radio {
        type hw
        card 1
        device 0
   pcm_slave.radioslave {
        pcm radio
        rate 48000
   pcm.radioconv {
        type rate
        slave radioslave

Next, there are several parameters that the ARDOP modem needs to know:

   - What network port to use to communicate with the ARDOP-enabled applications.
     The default is 8515

   - The ALSA device to listen(record) and transmit (play) to

   - The PTT device to key up your radio (supports asserting the RTS pin on 
     serial ports, GPIO pins, CAT commands, etc)

   One example of manually starting up ARDOP could be:

      ardopc 8515 hw:1,0 hw:1,0 -p /dev/ttyUSB0

Two important things around audio level setting on your system:

   1. Turn OFF AGC on your radio and  roll back the RF gain on your radio to say 50%
      to start with

   2. Start up the ARDOP program and watch the level output going to either STDOUT if
      your running it manually or the ARDOP log if you're running the start-ardopc.sh
      script.  It's important to note that different frequencies can have higher/lower 
      signal levels depending on your antenna's performance.  Change the "RF GAIN" on your 
      radio until you see ARDOP levels reporting around 20000.  For example:

         >> INPUTPEAKS -18371 17687

      These levels should be when the channel is IDLE and they do seem to jump around in
      very NON-consitent ways.  Be patient between changing the RF Gaim setting on your 
      radio and waiting for a few sample reports coming in from ARDOP.  When the frequency 
      is busy with say ARDOP or other amateur radio traffic, you want to see the 
      reported ARDOP levels approach 32768 but ideally NOT reach 32768 (saturation).  This 
      can be very difficult with both weak and strong stations on the same frequency without 
      using AGC but disabling AGC is what's recommended from the author of ARDOP.

Finally, I recommend to use my startup script to make starting up ARDOP easier:

      cd /tmp
      wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/start-ardopc.sh
      chmod 755 start-ardopc.sh

   Now edit this script to reflect your PTT serial port and then move it into place:

      mv /tmp/start-ardopc.sh /usr/local/bin/

Additional ARDOP information can be found on the developer's website:  


22.c. - Compile and Install ARDOP-GUI

This is ARDOP-gui, a pretty GUI representing the performance of ARDOP

ARDOP is a command line digital mode modem program which *only* offers textual data from
it.  Humans can read that output but there is a lot of low level details in there that most
of us will care less about.  In early Dec 2018, John Wiseman published the ARDOP-GUI
program that grapically visualizes the ARDOP TNC operation, shows it's state, which gives 
a waterfall view of the radio's passband, etc.  It's very nice and operates along side 
ARDOP and say ARIM w/o any issues.

To use the new ARDOP-GUI visualization tool, you *must* be using the newest version of 
ARDOPC as described above.  To to get started, let's get and clean up the code:

   cd /usr/src/redhat/SOURCES
   wget http://www.cantab.net/users/john.wiseman/Downloads/Beta/ARDOP_GUI.zip
   cd /usr/src/redhat/BUILD
   unzip ../SOURCES/ARDOP_GUI.zip

   #Let's update the name of the archive to be more friendly
   mv ARDOP_GUI ardop-gui-1.0
   tar czvf ../SOURCES/ardop-gui-1.0.tgz ardop-gui-1.0

   #Now get the SPEC file
   cd /usr/src/redhat/SPECS
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ardop-gui.spec

Ok, let's build and install it:

   cd /usr/src/redhat/SPECS
   rpmbuild -bb --target=x86_64 ardop-gui.spec

   Now install it:

      sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/ardop-gui-1.0-1.x86_64.rpm

Finally, let's configure the ardop-gui program.  Go ahead and start ARDOP TNC per 
the instructions in the previous section.  Once the ARDOP TNC is running now run:


You should now be prompted for setting up the TNC if it hasn't been configured before:

   #Assumiung your going to run ARDOP on the local machine and not some other machine on your network
   Hostname:  localhost

   Port:  8515

Once you click on "OK", you should instantly see the "Rcv Level" bar jump around with the signal level,
see the waterfall running, etc.  You can see an example screen capture of ardop-gui in operation at
the top of this section.

If you use my start-ardopc.sh script mentioned above, the ardop-gui program will be started by
default when you start ARDOP.

22.d. - Compile and Install ARIM

This is ARIM, the Ncurses-style application that uses the ARDOP modem and TNC protocol

The ARIM program as described in this section and the gARIM version the next section are 
user application that use the ARDOP modem for powerful HF chat, file transfer, and automated
response systems.  The ARIM program is TUI (textual GUI) version uses Ncurses and can be run 
over SSH.  The gARIM program is a full Qt GUI program written in Fltk (similar to Fldigi) that 
can run under Xwindows (potenially can be remote controlled via VNC, etc).  Both versions have 
a similar user interface and function to D-RATS and the FSQ mode found in Fldigi or FSQCall 
(if you're familar with those programs).  Both ARIM versions provide several main features:

   - An intuitive interface to have connectionless flood-style and CONNECTED chats to 
     remote ARIM clients

   - CONNNECTED sessions work with remote Winlink (Winlink Express or PAT) stations running 
     ARDOP.  Much like you can manually work Winlink stations over AX.25 or TELNET, you 
     can now do the same over ARDOP

   - ARIM offers a semi-automated system similar to FSQ or D-RATS where you (or remote HAMs) 
     can send perodic beacons, pings, run remote commands like "heard" on remote stations and
     see what statiosn they can hear, do relays where you can chat to a distant station VIA
     another station to get very far distances, conduct file transfers, etc.

   - Many other features are available as well so read more at:


It should be mentioned that since ARDOP modem is a moving target, the ARIM and gARIM programs 
have to keep up with it.  For example:

   ARIM v2.4 it not compatible with any versions LESS than ARDOP2 v2.0.4

   ARIM v2.4 is not compatible with ARIM v1.9 or older

   ARIM v2.4 is compatible with gARIM 0.1 or newer

   ARIM v1.8 or newer is required for any ARDOP setups that use serial PTT to have successful 
   long running QSOs or they will timeout.

   ARIM v1.3 or newer requires ARDOPc version or newer.  

So Let's download the most recent code

   cd /usr/src/redhat/SOURCES/
   wget https://www.whitemesa.net/arim/src/arim-2.4.tar.gz

Next, download a RPM SPEC file for it:

   cd /usr/src/redhat/SPECS
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/arim.spec

If you downloaded a newer version of ARIM, please update the spec file to match the 
new version of code and now build it:

   rpmbuild -bb --target=x86_64 arim.spec

Now install it:

   sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/arim-2.4-1.x86_64.rpm

22.e. - Compile and Install gARIM

This is gARIM, the full QT / GUI-style application that uses the ARDOP modem and TNC protocol

gARIM and the above TUI-version of ARIM are basically the same program.  The main 
difference is that gARIM uses the FLtk GUI toolkit for a full GUI experience.  This
generally makes using ARIM more user friendly as many of it's keyboard controls 
can be difficult to remember at times.

Let's download the most recent code which is v0.5 as of 12/01/18:

   cd /usr/src/redhat/SOURCES/
   wget https://www.whitemesa.net/garim/src/garim-0.5.tar.gz

Next, you need to install some package dependencies.  If you've already installed Fldigi,
you probably already have most if not all of these packages:

   sudo yum install fltk-devel
   sudo yum install zlib-devel

To make things easy, I recommend to download and use a RPM SPEC file for it:

   cd /usr/src/redhat/SPECS
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/garim.spec

If you downloaded a newer version of ARIM, please update the spec file to match the 
new version of code and now build it:

   rpmbuild -bb --target=x86_64 garim.spec

Now install it:

   sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/garim-0.5-1.x86_64.rpm

22.f. - Configure ARIM

Ok, the final stages for either Arim or gArim!  For now, I'll discuss Arim but these notes
should work equally well for either program.  So go ahead and start ARIM by running the 


At this point, the program should start up, copy a bunch of stuff into a new "arim" 
directory out of your home directory and then tell you to edit the file manually.  
Go ahead and type in "q" for Quite and then "y" say yes to exit ARIM.

Now let's configure Arim by configuring it's ini file:

   vim $HOME/arim/arim.ini for the TUI Arim version:
   vim $HOME/garim/garim.ini for the GUI Arim version:
   #Update mycall to use your callsign : you can use SSIDs here if you wish
   #  such as -0 through -15 as well as ALPHA suffixed -A through -Z
   mycall = KI6ZHD

   #Update the maidenhead grid square - I'm in CM97ai but you can give 4, 6, or 8 place 
   gridsq = CM97ai02

   #Update the name variable to reflect your version of ARIM - seems to be the thing to do
   #in the ARIM community so that when you beacon, you include your version of code
   name = v1.8

   #Update the info line to be about your station
   info = Info: [FT950 @ 50w into a fan-dipole]
   # In the example arim.ini ile, it include a second [tnc] section. I recommend to
   # delete ALL of it up until the [arim] section header

   #Update mycall to use your callsign : Setting this a second time is required
   # Do NOT use an SSID suffix here
   mycall = KI6ZHD

   #To make the system more robust in poor conditions, try these settings
   send-repeats = 2
   fecmode-downshift = TRUE
   pilot-ping = 2

Ok, that should be a good starting configuration file.  Lots of addition ARIM configuration 
details are available at:


22.g. - Pick a frequency and operate ARIM

Whew, that's generally it to get ARIM going and now it's time to give it an official try.  
Get your radio ready with:

   - QSY your radio to an ARDOP frequency (see below)
   - Match to your antenna (attenna tuner, etc) for low SWR operation
   - Turn OFF AGC and lower the RF gain so the signal isn't distorted (mentioned above)

Per http://www.obriensweb.com/sked/index.php?board=digitalradio (now seems defunct), try
using the frequency:

  ARDOP:    14066 10135 7045 3590

Bob Cunnings (ARIM developer) also recommends: 
   7.101 and 14.101 USB

      7.101 USB seems to have a mix of ARDOP, PACTOR, and I think VARA Winlink stations

      14.101 USB (14.1015 actuall) has HF packet traffic on it (the 105 network)

For me, I've compiled the following frequencies (this is mentioned in the start-ardopc.sh script:

   - All are "dial" frequencies (1500hz offset from audio) and I have spotted the following
     callsigns on these frequencies:

        7.110 USB - Heard ARDOP stations: WB6VAC, NW8L, KI7ECE

                    Also heard FSQ stations on this freq: 
                      KI7ECE, AA0DY, KS0EGL, K7IFG, W4WAC, KD9DSS, KF7VIB

     Other ARDOP frequencies (DIAL - USB) :

        14.1089 DIAL - (unconfirmed: N9LYA and W7EES)
         7.045* (EU)

I'm seeing some ARDOP on 7.101 USB so I'm using that for now.

Next, in one terminal window, run the ARDOP startup script:


In another terminal window, start Arim or gArim with:


The ARIM GUI should start up but basically do nothing.  At this point, instruct ARIM 
to connect to the ARDOP TNC by typing in:

   <space>att 1<enter>

The space key is critical to tell ARIM to pay attention that a command is being requested.
At this point, ARIM should connect to ARDOP and you should see a bunch of commands in the TUI
interface initializing it.  In the other ARDOP terminal window, you should see the application 
connection get started:

   Host Control Session Connected                                                                        
   Host Data Session Connected

Ok, so let's see if ARDOP is configured right. To do so, you need to get used to ARIM's command
mechanism.  This is where you type in a SPACE, then the command, and then ENTER.  So, try:


A TUI box should open up showing the key parameters.  Hit ENTER to close the window.  You can do 
the same to see the ARQ settings:


Hit ENTER to close the window.  Next, try sending a beacon over RF with the command:


You radio should get keyed up and send a beacon packet TWICE.  If your radio doesn't key up or
you don't hear digital mode tones from your radio's monitor feature, you need to troubleshoot
things until you do.  If things did seem to work.. GOOD!  Few more things to do:

   - Make sure your SWR level is low and you're not running too much power when transmitting.
     For example, my Yaesu FT950 is rated only at 50w at full duty cycle modes

   - Do the best command again but look at the ALC on your radio when it's transmitting
     and make sure there is little to NO ALC

Ok, on to real operating steps!  I recommend Have your system listen for a while and hopefully you'll 
hear some ARDOP traffic and you'll see specific remote stations show up in the upper right column.  
Once you do see some stations, try to do a few things:

   #I heard WA7ODN so I will use that station for my example:
   <space>ping WA7ODN 3<enter>

      #I received a ping back showing:
      [21:38:58] >> [p] WA7ODN>KI6ZHD S/N: -7dB, Quality: 60

Ok, we're getting responses!  So now let's try making a connection:

   <space>conn K2RDX 3<enter>

   In this example, K2RDX is actually a Winlink station running ARDOP
   so you can use ARIM to interact witho both ARIM stations but also 
   Winlink stations too!

My more common commands (when NOT connected) are:

   #this sends out an unconnected message for all to see
   <space>:this is a test<enter>

   #This changes the beacon time to every 30min 
   #  You can see this value chaned in the far-lower-right corner of the TUI
   <space>btime 30<enter>

My more common commands (when CONNECTED) are:

   /info    - learn about the remote station
   /version - what version of ARDOP and ARIM is running there
   /gridsq  - where is this remote station located
   /heard   - what remote station can that remote station hear
   /sm -z this is a test  - sends a compressed, one-liner message to the remote station's ARIM program
   /mlist                 - get a list of remote messages for you from this remote ARIM station
There is a ton of othther functionality to ARIM so it's best you read up on all it's 
features here:


When your done with ARIM, enter in the following in the ARIM window:


  and in the ARDOP window, hit control-c

23. - FreeDV - Digital voice mode using CODEC2

FreeDV is the combination of several tools to bring a robust, truly open digital 
mode to amateur radio.  At the highest levels: 

   - Codec2 is the vocoder that translates your voice into bits

   - FDMDV encodes those bits into a robust digital mode that usually resembles 
     15 concurrent PSK31 signals

   - FreeDV is the GUI that makes everything easy to use

Since everything is digital here, you need TWO sound cards to run FreeDV.  One for 
interfacing to the radio to the computer and another interfacing to a 
microphone/speaker to your computer.  At minimum, your existing HF digital modes 
sound card will let you receive and decode FreeDV signals.

Ok, let's get started

23a. - Getting FreeDV and it's required components

Fortunately for all of us, the EPEL repos have pre-compiled RPMs for FreeDV 
(used to be Hobbies COPR repo)!  To enable this the EPEL repo, please read
the "Enabling Third Party RPM repositories" section eariler in this document.

   # NOTE:
   #  This package requires wxGTK 2.9 which is not available in the standard repos like 
   #  EPEL.  Fortunately, this FreeDV has this package but it's misnamed as WxGTK3 so
   #  yum falls apart here (you'll get errors like):
   #    Error: Package: freedv-0.96.5-1.el6.x86_64 (freedv) Requires: libwx_gtk2u_html-2.9.so.5(WXU_2.9)(64bit)
   #  In addition, these packages are requiring the presence of the libgnomeprint and libgnomeprintui
   #  libraries but this dependency is NOT captured in the misnamed wxGTK3 RPMs.  
   #  I have reported both of these issues but until then, you can work around 
   #  this with the following commands:
   sudo yum install libgnomeprint22 libgnomeprintui22
   sudo yum install libmspack
   sudo yum --disablerepo="*" --enablerepo="freedv" install wxGTK3-devel

   # Now let's install it
      sudo yum install freedv

   As of 08/26/17, this will install freedv-1.2.2-1.el6.x86_64

# NOTE: 
#       Depending on what other applications you've already installed on your Centos
#       machine, your system might also need to install additional packages such as:
#       gtk2-devel libsamplerate libsamplerate-devel libsndfile libsndfile-devel 
#       alsa-lib alsa-lib-devel portaudio portaudio-devel 

23b. - Configuring FreeDV

Ok, so FreeFV is installed.  Let's get it configured!   

Start FreeDV from the command line from your usual non-root username:


Goto Tools --> Audio Config

   Click on the "Receive" tab at the bottom of the screen:

      -  In the "From Radio" section: 

         - select the soundcard that you usually use for your HF digital modes.  
           For me, I'm using "USB Audio CODEC: USB Audio (HW: 1,0) which is my
           US Interface Navigator

             - for my soundcard, I change the sampling rate to 48000

         - If your HF radio is turned on and things are properly working, click
           on the "Rec 2s" button on the far right and see if you eventually see
           a recorded waveform

      - In the "To Speaker/Headphones" section: 

         - I've selected "HDA Intel PCH: ALC271X analog (hw:0,0) which is my 
           laptop's built in soundcard 

   Click on the "Transmit" tab at the bottom of the screen:

      - In the "From Microphone" section: 

         - I've selected "HDA Intel PCH: ALC271X analog (hw:0,0) which is my 
           laptop's built in soundcard 

      -  In the "From Radio" section: 

         - select the soundcard that you usually use for your HF digital modes.  
           For me, I'm using "USB Audio CODEC: USB Audio (HW: 1,0) which is my
           US Interface Navigator

             - for my soundcard, I change the sampling rate to 48000

         - If your HF radio is turned on and things are properly working, click
           on the "Rec 2s" button on the far right and see if you eventually see
           a recorded waveform

   To confirm you've created a valid configuration, click on the "Apply" button.
   If it's not valid, you'll need to continue playing with the settings until it
   accepts it.

Goto Tools --> PTT Config

   - Under the "VOX PTT Settings", make sure the "Half Duplex" box is checkmarked

   - For my setup, I normally use the US Navigator's dedicated PTT serial port as it's
     100% reliable.  Unfortunately, it seems FreeDV asserts the DTR line in addition to 
     the other signals which keys my radio through it's FSK port.  This is a bug and
     I will report it.  Until then, I will use Hamlib

   - Before you click on "OK", turn on your HF radio, QSY the radio to a clear
     frequency that has a good SWR match and turn it's RF power to it's lowest

   - When you click on "OK and if your HF radio is turn on, you should hear
     the radio briefly assert PTT and then let it go.  If the radio stays
     keyed up, find your correct settings to resolve this.

Goto Tools --> Options

   - Enter in your callsign

   - For now, checkmark "Test Frames: Enable"

*** Do NOT goto Tools --> Filter as the program crashes as of 11/08/14 with
   Program terminated with signal 11, Segmentation fault.
   #0  0x000000000046b7b8 in lsx_biquad_flow (effp=0x2936d30, ibuf=, obuf=, isamp=, osamp=) at biquad.c:154
   154         *obuf++ = SOX_ROUND_CLIP_COUNT(o0, effp->clips);

24. - WSPR - HF weak signal beacon

WSPR is what's called a "reverse beacon" program which essentially transmits or 
receives a modulated carrier (sounds like a slightly changing CW tone) that 
changes very slowly over a duration of about 120 seconds.  It doesn't support two
way QSOs like what you can find in JT9, JT65, JT144, etc.  This WSPR carrier contains 
the callsign and top-level MaidenHead grid for the transmitter.  These beacons can 
be decoded WELL under the noise floor and are self identifying.  Very nice!

This is the main window for decoding remote beacons, etc:

NOTE:  There are two generations of WSPR now:

        WSPR-X:  This is the bleeding edge version of the program that has added WSPR-15
                 for the new 472Khz band as well as switched away from a pure Python GUI 
                 to a Qt GUI.  This new version requires recent versions of Qt5, Cmake, but 
                 is mostly stable and isn't as bleeding edge as WSJT-X (mentioned in a 
                 different section).

                   NOTE: WSPR-X has not carried forward rig control nor SDR support at 
                         this time.  If you want these features, use WSPR instead

        WSPR:   This is the legacy version that uses Python for it's GUI but still works
                well.  This code still works well but isn't getting much development 
                anymore but it's the only version that natively supports SDRs.

     You can see more about all these requirements here:


Dependency Notes:

     Both WSJT and WSPR require some dependencies that Centos5 does NOT support out of the 
     box but are well supported with Centos6.  Specifically, Centos5 is missing:

     - Many common dependencies that also Fldigi requires such as Jack, PortAudio, 
       etc.) so be sure to get FLdigi working first

     - G95 Fortran

     NOTE: Please note that the WSPR documentation says it requires Python 2.5 
           but I have it working with Centos5's Python 2.4

     - Both WSJT and WSPR can either use Gfortran or G95 

        - Gfortran is generally available via: yum install gfortran

         - [Optional] If you really want G95 (unclear if it's any better), download 
           and install G95 Fortran via:
              wget ftp://anonymous%40g95%2Eorg:none@ftp.g95.org/v0.91/g95-x86-linux.tgz
              tar xvf g95-x86-linux.tgz
              mv g95-install /usr/local
              ln -s /usr/local/g95-install/bin/*g95* /usr/bin/g95

Centos 6 Specific
  - Please skip down to the Centos5 section if you are running that version

      Let's install the required dependencies:

         yum install gcc-gfortran
         yum install numpy             (Centos6 drops the "python-" prefix name)
         yum install python-imaging
         yum install python-imaging-tk
         yum install python-pmw        (from EPEL repo)

      If not already installed, also install:

         yum install portaudio-19
         yum install portaudio-19-devel
         yum install fftw              (this installs v3 on Centos6)
         yum install libsamplerate-devel
         yum install subversion

      If you wish to have Rig control support (very nice), you need to install Hamlib.
      This is described in detail in the Fldigi compilation section

      - Let's now get a starter RPM spec file:

        #Get the SRPM and install it
        cd /tmp
        wget ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/hamradio/openSUSE_11.4/src/wspr-4.0.r3015-1.1.src.rpm
        rpm -ivh wspr-4.0.r3015-1.1.src.rpm

           IF you'd like to get the newest version of code, do the following

             cd /tmp/
             mkdir wspr
             cd wspr
             svn co svn://svn.berlios.de/wsjt/branches/wspr
             WSPRMAJVER=`grep Version= wspr/wspr.py | awk -F\" '{print $2}' | awk '{print $1}'`
             WSPRMINVER=`grep Version= wspr/wspr.py | awk '{print $5}'`
             mv wspr wspr-$WSPRMAJVER.r$WSPRMINVER
             tar civf /usr/src/redhat/SOURCES/wspr-$WSPRMAJVER.r$WSPRMINVER.tar.bz2 wspr-$WSPRMAJVER.r$WSPRMINVER

             You will also need to update the major and subversion minor versions in the spec file to match

        #Next, edit the spec file to match Centos6 requirements

        Change the BuildRequires to the following:

           alsa-devel      to alsa-lib-devel
           f2c             to compat-libf2c-34
           fftw3-devel     to fftw-devel
           gcc-fortran     to gcc-gfortran
           libpulse-devel  to pulseaudio-libs-devel
           portaudio-devel to portaudio-devel
           python-numpy    to numpy

          Delete the lines:

             BuildRequires:  python-numpy-devel
             BuildRequires:  update-desktop-files

          Add a new line:

             BuildRequires:  python-imaging-tk

          Update the line:

             python-numpy to numpy

          If you don't want to use Hamlib, DELETE the lines:

             Requires:       hamlib

          Add the following line just below the "Requires" section:

             %{!?py_sitedir: %define py_sitedir %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}

          Delete the following SuSE specific lines:

             %suse_update_desktop_file -c wspr Wspr "Weak-signal communications" wspr wspr "Network;HamRadio"

    So now compile it up and install it:

        rpmbuild -bb --target=x86_64 wspr.spec
        rpm -ivh /usr/src/redhat/RPMS/x86_64/wspr-4.0.r3015-1.1.x86_64.rpm

Centos 5 Specific
      Not sure if we need this but I think we do
      from http://lists.macosforge.org/pipermail/macports-users/2007-April/002574.html

       This hack HELPS but it still barfs out
       cp /usr/lib/python2.4/site-packages/numpy/distutils/fcompiler/gnu.py

       edit gnu.py and do
          -    version_match = simple_version_match(start=r'GNU Fortran (?!95)')
          +    version_match = simple_version_match(start=r'GNU Fortran')

          -    version_match = simple_version_match(start='GNU Fortran 95')
          +    version_match = simple_version_match(start='GNU Fortran')

   - Stock Centos5 only supports FFTW v2.x but WSPR needs the newer, non-
     compatible FFTW v3 libs.  

   #It seems the older fftw 3.1.1 doesn't satisfy wspr and will give errors like:
   #     ld: cannot find -lfftw3f
   #  To fix this, install a newer version of fftw
   rpm -e fftw3-3.1.1-1.el5.rf fftw3-devel-3.1.1-1.el5.rf

   #Download and install the 3.2.2 version which fixes it
   wget ftp://ftp.pbone.net/mirror/download.fedora.redhat.com/pub/fedora/epel/5/i386/fftw3-3.2.2-3.el5.i386.rpm
   wget ftp://ftp.pbone.net/mirror/download.fedora.redhat.com/pub/fedora/epel/5/i386/fftw3-devel-3.2.2-3.el5.i386.rpm
   rpm -ivh fftw3-3.2.2-3.el5.i386.rpm  fftw3-devel-3.2.2-3.el5.i386.rpm

   yum install python-numpy

   #Old - also installed Gfortran to let configure pick which one it prefers
   yum install gcc-gfortran 

   wget ftp://ftp.pbone.net/mirror/centos.karan.org/el5/extras/testing/i386/RPMS/python-imaging-1.1.6-4.el5.kb.i386.rpm
   #Can't use Yum as package isn't signed
   rpm -ivh python-imaging-1.1.6-4.el5.kb.i386.rpm
   wget ftp://ftp.pbone.net/mirror/centos.karan.org/el5/extras/testing/i386/RPMS/python-imaging-tk-1.1.6-4.el5.kb.i386.rpm
   #Can't use Yum as package isn't signed
   rpm -ivh python-imaging-tk-1.1.6-4.el5.kb.i386.rpm

   wget ftp://ftp.pbone.net/mirror/download.fedora.redhat.com/pub/fedora/epel/5/i386/python-pmw-1.3.2-5.el5.noarch.rpm
   rpm -ivh python-pmw-1.3.2-5.el5.noarch.rpm

   # WSPR's make system broke complaining about a missing fftw3f library.  To fix this,
   #  there are three parts to the solution

     NOTE: I need to review this, as it conflicts with what I said above.  Sorry.. 

        #1. Remove the too up to date version of fftw3
        rpm -e fftw3-3.1.2-5.el5.1
        yum install fftw3-devel fftw3

        #2. Centos5 has a broken package library for qt-mt.pc which is required by avahi-qt3.  You could see the error
            by running 
          pkg-config --list-all

          To fix, you need to install the qt-4.4 libraries:
            yum install qt-devel

        #3 make sure "pkg-config --list-all" runs cleanly

     ./configure --enable-g95 
     make install

24.a - Configuring WSPR and time management

     Time management:  It's CRITICAL to WSPR and other WSJT modes that you have
     ---------------   very accurate time on your PC.  I'm talking atomic accurate
                       time within sub-second accuracy.  A clock off by +/- 1 second
                       will result in ZERO decodes!!!  You've been warned.

      Make sure you have a good working NTPd setup so that when you run /usr/bin/ntpstat , you see
      something like:
      synchronized to NTP server ( at stratum 11
      time correct to within 951 ms
      polling server every 64 s

     Ok, assuming you have an excellent time source, let's start and configure WSPR :

        run "/usr/local/bin/wspr"

         Configure WSPR
           NOTE:  This assumes my setup using a US Interface Navigator
           NOTE#2:  Though WSPR can change the radio frequency, it 
                    doesn't change USB/LSB or change the power.  
                    You need to set your rig to USB and the proper
                    power level (see below) yourself!
           NOTE#3:  The configuration window always open up BEHIND the
                    main WSPR window so you never know if it opened up
                    or not.  Move the main WSPR window to the right
                    to see it.

         Change the following settings to suit your setup
              Call: KI6ZHD
              Grid: CM97ai

              Audio In:  9 pulse
              Audio Out: 9 pulse  (I had to scroll down to see this)

              Audio In: 8 USB Audio CODEC : USB Audio (HW:1,0)
              Audio Out: 8 USB Audio CODEC : USB Audio (HW:1,0)

              Power (dbM): 37    -- this means 5watts but the power must be
                                    manually set on the rig itself.  40 dbM
                                    is 10w.  See the appendix in the WSPR
                                    documentation for a lookup table

              PTT Method: RTS        - Specific to the US Interface Navigator
              PTT port: /dev/USI_PTT  - UDEV alias configure per a previous section

              Enable CAT: check
              CAT port: /dev/USI_CAT  - UDEV alias configure per a previous section
              RIG number: 128         - Yaesu FT950
              serial rate: 38400      - Specific to a change FT950 config
              data bits: 8
              stop bits: 1
              handshake: hardware

          - Simply click on the upper corner window "close box" to close the
            window and then under the main window, do:

            - Save --> and make sure that "Save All" is NOT selected.  If not,
              your computer will save every 2minute period as a 2.8MB .wav file!


                  File --> Save User Parameters

         Once loaded: 
             1. Set the Tx fraction to 0% from a default of 20%
             2. Check the "Upload Spots" box
             3. Goto Band and select and band.  Make sure your rig changes
             4. uncheck the IDLE radial button
             5. In the lower, left side of the screen, change the vertical slider
                until the lower left field says: "RX Noise: 0db".  If this value 
                already says 0 or never changes, change your sound card settings
             6. Now WAIT until WSPR says "Receiving" in the lower right corner.  
                When I say wait, I'm talking minutes.  It takes some time before 
                WSPR decides is a receive vs. transmit period.  It will take TWO
                more minutes to decodes them, etc.  Nothing will show in the horizontal 
                receive water fall until WSPR says "Receiving" and does a 2 minute
                receive cycle.
             7. Eventually, you'll see decodes
             8. Make sure the radio is match to the desired frequency (tuner, etc)
             9. Change the Tx fraction to 20%


OLD Centos5 notes:
   -- Ignore this section for now as it will be deleted:

       Requires Fortran (similar to JT65)

    WSPR 2.00 r1714 tarball
    ./configure    (notice that it says it's building 1.11)
      gave error on 
Could not locate executable g77
Could not locate executable f77

       error in configure script
checking whether gfortran accepts -g... yes
./configure: line 3074: test: =: unary operator expected
checking uname -s... n

     installed compat-gcc-34-g77 -- didn't help

   from http://www.g95.org/downloads.shtml

     wget ftp://anonymous%40g95%2Eorg:none@ftp.g95.org/v0.91/g95_source.tgz
     tar xzvf g95_source.tgz
     cd g95-0.91/
     NOTE:  don't worry about the error shown below:
          You've configured g95 in a special test mode where it will not be
able to generate object files. If this is not what you want, use the
--with-gcc-dir= option to compile against an appropriate gcc build.

[root@hampacket g95-0.91]# make
make  all-am

     NOTE:  The SPEC file found at
            is not clean and will not work without significant work.  You've 
            been warned.  Compile from source and make install for now

     NOTE#2: make install puts binary in the following dir but the
installation fails to totally complete.  Workaround:

       configure it --> Setup --> Options
              My Call: KI6ZHD
              Grid: CM97ai

              ID Interval: 10m	

              PTTY port: /dev/ttyUSB1

              Audio In: 14
              Audio Out:14

              Rate In : 1.0
              Rate Out: 1.0

              Power (dbM): 40    -- this means 10watts but must be
                                    manually set on the rig itself

              PTT Method: RTS
              Enable CAT: check
              CAT port: /dev/ttyUSB0

  ---> BROKEN information when I was trying to compile WSPR
   To Get Python 2.5, you have to download a hacked version.  I looked into hacking things up with using
        Python 2.5.5 and a SPEC file stolen from below but the SPEC file is for Python 2.5.1 and requires
        specific 2.5.1 Patches which break against 2.5.5

      To build Python 2.5.1, you first need to install the following
        yum install tk-devel tix-devel
             --> python25-2.5.1-bashton1.src.rpm

      Now, lets build the hacked up Python 2.5.1
           cd /usr/src/redhat/SPECS
           rpmbuild -bb --target=i686 python.spec

          Notice that I'm installing not upgrading Python here:

            cd /usr/src/redhat/RPMS/i686
            rpm -ivh python25-2.5.1-bashton1.i686.rpm python25-libs-2.5.1-bashton1.i686.rpm

            #Installing the developer libs is a good idea too
            rpm -ivh /usr/src/redhat/RPMS/i686/python25-devel-2.5.1-bashton1.i686.rpm

      Newest code: http://www.python.org/download/releases/2.5.5/
         mv Python-2.5.5.tar.bz2 /usr/src/redhat/SOURCES/

END Legacy BROKEN information

25. - WSJT - JT65 and other HF / EME weak signal digital modes

| NOTE:  WSJT has been deprecated in favor of WSJT-X.    |
|        This section covers the legacy WSJT application | 
|        ONLY.                                           |

WSJT is a suite of weak signal modes including JT9, JT65, etc. from W1JT.  What's 
unique about these modes is that they are extremely timing sensitive that requires 
ALL stations to have the same time withing +/- 5 seconds.  With this requirement 
satisfied, many of these modes like JT65 can decode signals well into the noise that
cannot be heard or seen on the waterfall.

This is the main window for decoding remote stations, sending CQ:

This is the waterfall window showing 1-minute decodes:

NOTE:  There are two generations of WSJT now:

        WSJT-X:  This is the bleeding edge version of the program that has the 
                 new JT9 mode has switched away from a pure Python GUI to a Qt 
                 GUI.  It requires a very modern versions of Qt5, Python3, Cmake,
                 and is constantly changing.   Keeping up with WSJT-X is rather
                 difficult for stable OSes like Centos.

        WSJT:   This is the legacy version that does NOT support JT9 but works
                well for JT65.  This code still works well but isn't getting much
                development anymore.

     You can see more about all these requirements here:


  | To be updated for Centos6 |


   NOTE: No RPM SPEC available at the Fedora site

   [ requires all above dependencies to get this to compile]

   Centos5 Note: I was unable to get WSJT 7.x to work properly with Centos 5.4
                 and it's default version of Python.  The very old WSJT 5.98
                 works fine but lacks the now deprecated WSPR QSO mode.

     NOTE#2:  Unlike WSPR, WSJT doesn't support RIG control though it seems
              it does by selecting the band.

  Let's get down to it. First off, WSJT has very similar dependencies to
  WSPR (discussed in a previous section) as well as Fldigi.  As of this
  writing, you **MUST** complete Fldigi's dependencies per that section
  to have any luck compiling WSJT here.

  Step 1: Fortran

        yum install gcc-gfortran

  Step 2: Installing fftw (version 3)

     Centos6: (with no version specified infers FFTW v3)
        yum install fftw.x86_64 fftw-devel.x86_64

  Step 3: Python libs

     yum install numpy numpy-f2py python-imaging python-imaging-tk

  Step 3: PortAudio v19 (newer)

     * This is covered in the Fldigi section


  Ok, that's it but there aren't any SPEC files included with WSJT so it's 
  recommended you get a copy of mine found here:


  Next, since all the code is in Subversion, we need to get the code and put it
  into an archive the SPEC file can deal with:

  cd /usr/src/redhat/SOURCES
  mkdir wsjt
  cd wsjt

  #The new WSJT code is only available in the Subversion repository
  svn co svn://svn.berlios.de/wsjt/trunk

  #When the subversion checkout completed, you should have seen something like:
  #   Checked out revision 2501
  #   This seems to then translate to be version "9.2 - r2472" per the wsjt.py file
  #Rename the directory to reflect the version, checkout and then compress it up:
  mv trunk wsjt-9.2.r2472
  tar civf ../SOURCES/wsjt-9.2.r2472.tar.bz2 wsjt-9.2.r2472/*
  cd ..
  rm -Rf wsjt

  Ok, time to build up the RPM:

  rpmbuild -bb --target=x86_64 wsjt.spec

  If you'd like to compile things manually for Centos6
  ./configure --with-portaudio-include-dir=/usr/include --with-portaudio-lib-dir=/usr/lib64/

  Centos5 (or if you want to manually compile things w/o an RPM):
    tar xzvvf ../SOURCES/wsjt-5.98-r558.tgz 
    cd /usr/src/redhat/BUILD/wsjt-5.98-r558/trunk
    ./configure --enable-g95
    make install

  Configuring and Running WSJT:

  - Start WSJT from the command-line by purely running:  wsjt and ignore all 
    the errors that show up on the command line for now.

  - You'll see output of all detected portaudio devices in the terminal 
    window that you started it from:

       For Centos6 machines running 9.2
       WSJT Version 9.2 r2472 , by K1JT
       Revision date: 2012-06-21 07:00:38 -0700 (Thu, 21 Jun 2012)
       Run date:   Wed Jul 11 01:26:54 2012 UTC
       ALSA lib pcm.c:2209:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
       ALSA lib pcm.c:2209:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
       ALSA lib pcm.c:2209:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side

       Audio     Input    Output     Device Name
       Device  Channels  Channels
          0        2         2       HDA Intel PCH: ALC271X Analog (hw:0,0)
          1        0         8       HDA Intel PCH: HDMI 0 (hw:0,3)
          2        2         2       USB Audio CODEC: USB Audio (hw:1,0)
          3        0         2       front
          4        0         2       surround40
          5        0         2       surround51
          6        0         2       surround71
          7        0         8       hdmi
          8       32        32       pulse
          9        0         2       dmix
         10       32        32       default

       User requested devices:   Input =  0   Output =  0
       Default devices:          Input = 10   Output = 10
       Will open devices:        Input = 10   Output = 10


       For Centos5 machines running v5.9.8
       WSJT Version 5.9.8 r558 , by K1JT
       Revision date: 2007-10-08 09:47:34 -0400 (Mon, 08 Oct 2007)
       Run date:   Sat Apr 10 23:28:23 2010 UTC
       Using PortAudio.

       Audio     Input    Output     Device Name
       Device  Channels  Channels
          0       16        16       /dev/dsp
          1       16        16       /dev/dsp1
          2       16        16       /dev/dsp2
          3        2         2       Intel 82801DB-ICH4: Intel 82801DB-ICH4 (hw:0,0)
          4        2         0       Intel 82801DB-ICH4: Intel 82801DB-ICH4 - MIC ADC (hw:0,1)
          5        2         0       Intel 82801DB-ICH4: Intel 82801DB-ICH4 - MIC2 ADC (hw:0,2)
          6        2         0       Intel 82801DB-ICH4: Intel 82801DB-ICH4 - ADC2 (hw:0,3)
          7        0         2       Intel 82801DB-ICH4: Intel 82801DB-ICH4 - IEC958 (hw:0,4)
          8        1         1       Intel 82801DB-ICH4 Modem: Intel 82801DB-ICH4 Modem - Modem (hw:1,0)
          9        2         2       USB Audio CODEC : USB Audio (hw:2,0)
         10        2         2       front
         11        0         2       iec958
         12        0         2       spdif


       Notice the device number on the USB Audio codec of "2".  Remember that
       now and shut WSJT back down.  

           The WSJT application is written with rather old methods and needs ALL incoming 
           audio to be sampled at 11,025/sec.  Some devices can support those low rates but
           the US Interface Navigator USB device, the Signalink USB device, and others require
           us to downsample per the following URL:

           Modern solution:

            pcm.radio {
                    type hw
                    card 2
                    device 0
            pcm_slave.radioslave {
                    pcm radio
                    rate 48000
            pcm.radioconv {
                    type rate
                    slave radioslave

         Legacy solution: 
         his solution -->
            ./configure --enable-portaudio --with-portaudio-include-dir=/usr/portaudio/v19-devel/include \
--with-portaudio-lib-dir=/usr/portaudio/v19-devel/lib/.libs/ --with-jack=no

    Start WSJT back up and notice the updated sound card list:

       WSJT Version 5.9.8 r558 , by K1JT
       Revision date: 2007-10-08 09:47:34 -0400 (Mon, 08 Oct 2007)
       Run date:   Sat Apr 10 23:28:23 2010 UTC
       Using PortAudio.

       Audio     Input    Output     Device Name
       Device  Channels  Channels
          0       16        16       /dev/dsp
          1       16        16       /dev/dsp1
          2       16        16       /dev/dsp2
          3        2         2       Intel 82801DB-ICH4: Intel 82801DB-ICH4 (hw:0,0)
          4        2         0       Intel 82801DB-ICH4: Intel 82801DB-ICH4 - MIC ADC (hw:0,1)
          5        2         0       Intel 82801DB-ICH4: Intel 82801DB-ICH4 - MIC2 ADC (hw:0,2)
          6        2         0       Intel 82801DB-ICH4: Intel 82801DB-ICH4 - ADC2 (hw:0,3)
          7        0         2       Intel 82801DB-ICH4: Intel 82801DB-ICH4 - IEC958 (hw:0,4)
          8        1         1       Intel 82801DB-ICH4 Modem: Intel 82801DB-ICH4 Modem - Modem (hw:1,0)
          9        2         2       USB Audio CODEC : USB Audio (hw:2,0)
         10        2         2       front
         11        0         2       iec958
         12        0         2       spdif
         13        2         2       radio
         14        2         2       radioconv

   Configure WSJT to use appropriate Audio Device number for device called "radioconv".

       Setup --> Options

         NOTE: I've found that this "options" window will NOT always come up 
               in the foreground so you might have to go find it first. Lame.

         NOTE #2: Change the following to represent your specific details

              My Call: KI6ZHD
              Grid: CM97ai

              ID Interval: 10m	

              #This reflects the use of custom Udev device enumeration
              PTTY port: /dev/USI_PTT

              Audio In: 2
              Audio Out:2

              Rate In : 1.0
              Rate Out: 1.0

Other good build doc:
   http://foxgulch.com/WordPress/?p=557 	:1

26. - JNOS - Full AX25 and TCP/IP enabled packet BBS

  | To be updated for Centos6 |

2.0g - Fedora repository doesn't have it


tar xzvf 

JNOS root dir:  /usr/local/jnos
AXIP wormhole: no
AXUDP wormhole: no
Add a TNC: yes
serial port: vhfdrop
baud rate: 1200
Enable TNC beacon: yes
password: root passwd

in a different window, 
  - disable any gettys running on tty5
  - add
        c5:1235:respawn:/usr/local/jnos/startnos /dev/tty5
  - run 
        telinit q


axlisten removed for "listen"
listen -8acrp vhfdrop

call -bl -me -r vhfdrop k6sny-1

added an alias for:  
alias call='call -bl -me -r'

27. - PSKMeter - BPSK31 signal quality diagnostic meter and software

Download the ported pskmeter.py app and the currently stable version pyserial 
module at http://aa6e.net/wiki/Pskmeter.py .  PySerial is also installed via the 
Chirp section of this document.

  NOTE:  The author of FLdigi also has his own pskmeter program that also supports
         PSK63 but I haven't tried it out yet:


As root, 

  - install the pyserial module (for version 2.4) - See the Chirp section for
    how to create the RPM for Centos6 or Centos5.  Alternatively, you can do
    it as a source via (not recommended):

      python setup.py install

  - Next, install Tkinter

     yum install tkinter

  - Centos5:
    install aumix (no Yum package available)
     download from http://freshmeat.net/projects/aumix/
     tar xivf aumix-2.8.tar.bz2
     cd aumix-2.8
     sudo make install
     ln -s /usr/local/bin/aumix /usr/bin/aumix

Note:  I re-used the USB to serial interface I had connected to my Yaesu
FT-950's CAT interface.  To make sure that fldigi wasn't going to conflict, I
disabled the HAMLIB interface.

Installing and Configuring pskmeter.py:

  - Download the code

    mkdir /usr/src/archive/PSKMeter

    wget -O http://aa6e.net/wiki/Pskmeter.py

  - Serial ports:

     - the pskmeter.py program defaults to looking for it's controlling serial
       interface at /dev/ham.pskmtr.  To make it work for my setup, I did
       the following as root:

          Centos 6:
          ln -s /dev/ftdi-serial-cbl /dev/ham.pskmtr
          Centos 5:
          ln -s /dev/ttyUSB0 /dev/ham.pskmtr

     - Make sure your username is in the "dialout" group as discussed in the
       Fldigi section of this doc.  Alternatively, you run the command:
          Centos 5:  "chmod 666 /dev/ttyUSB0" 

       so that the pskmeter.py program can access the serial port

  - Soundcard Mixer devices:

     - The pskmeter.py program defaults to an alternate mixer that what's usually
       installed with Centos6 or Centos5.  Edit the pskmeter.py program and change 
       the MIXER setting to the following:

       - Centos6: 
             With version 6, OSS is no longer natively supporting the legacy OSS 
             devices such as /dev/dsp and /dev/mixer.  Now, it does things via
             ALSA emulation.  To get /dev/mixer, run the following to get
             pskmeter25.py to work:

                modprobe snd-mixer-oss

  - Software mixing controls

       pskmeter.py program assumes it can run the mixing program "aumixer" which 
       isn't installed with Centos.  Edit the pskmeter.py program, search for the
       text "aumixer" and put in

     - Centos 6:
       You need to change the getLeve () routine to be something like:

           command = "amixer --c 1 cget iface=MIXER,name='PCM Playback Volume',numid=2" | grep ' : values'"

          BTW, the proper way to control volumes with Centos6 is with 
          PulseAudio and the best way to do that is via pavucontrol as 
          installed in the Fldigi section

     - Centos 5:
       aumix (GUI):
           command = "/usr/bin/aumix -d "+MIXER+" -wq"

           #The following command gives the output like:
           # pcm 71, 71

       , alsamixer or amixer

  - There is also a patch file that you can apply that will set some of these items
    for you:

      wget -r -l1 -nd --no-parent -A pskmeter* www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/

  - Ok, follow the PSKmeter instructions in how to setup and run it.  To 
    troubleshoot it, you can run something like the minicom terminal program
    at 19200-8N1.  Now turn on or plug in the pskmeter and you should see a 
    plain English initialization string when it starts up

Now, fire up fldigi (or whatever app your using to do PSK31):

  - find a clear, open frequency
  - set your rig to low power
  - tune up to a low SWR
  - now insert the pskmeter between the rig and the antenna tuner to protect
    it from reflected power
  - On fldigi, hit the QSY button to put the PSK31 signal in the sweet spot
  - Start up the meter with:
       python pskmeter025.py

  - In Fldigi, there is the TUNE button in the upper right but that's a SINGLE
    tone, you want to run a PSK-31 note test by hitting the key sequence 
    Control-t in the blue window of Fldigi

       Using Kmix:
          - setting the PCM output too low looses resolution
          - Master and Master mono output do NOTHING
          - Original headphones setting was 45 which resulted in under-driving
            levels.  PSKmeter for windows seemed to be happy at 59

28. - QSSTV - Digital and Analog Slow Scan TV (SSTV)

QSSTV is a SSTV (Slow Scan TV) that sends still images either via Digital or Analog signals available at: http://users.telenet.be/on4qz/ This a very nice KDE application uses the Qt framework which is very easy to use and supports several advanced features like live QSO Image editing, etc. In addition to now supporting the DRM digital mode, it also supports all the major analog SSTV formats like Scottie, HamDRM, etc.

This is the main window for Qsstv 9.x Digital SSTV program:

This is the main RX gallery for Qsstv 9.x Digital SSTV program:

Click here to see screen captures for previous versions of QSSTV:

Here is a little detail on the different generations of Qsstv:

   Qsstv v9.x has changed the UI a bit where it has now separated the analog vs. 
   digital modes a bit.  It has also improved the DRM support, added some modern 
   analog modes, and in 9.1.1, it's moved from the aging Jasper JPEG library to
   the newer OpenJPEG libraries.

   Qsstv (v8.x) added HamDRM digital SSTV support which is compatible with the 
   Windows EasyPal and Linux RXTXAMADRM digital SSTV programs.  This new version
   includes BSR fix support, Hybrid mode, and more.  This new code requires at least
   Qt 4.8.x framework (or newer) which that installation of newer Qt versions is 
   covered in the Gqrx chapter of this document.

      These new Qt4.8 libraries are NOT compatible with Centos5.  As such, if 
      you're running Centos5, you're at a dead end.  Time to upgrade to a newer 
      version Centos.

   QSSTV (v7.1.x) supported Analog SSTV modes only but all of it's dependencies are
   natively available in Centos6. Centos5 users can upgrade the core Qt libraries 
   with third party libs to make it work.  With that said,  it starts getting 
   pretty sketchy and you can break your OS if you're not careful.  It's great news 
   that it's technically possible but doing this is NOT for the faint of heart 
   (Centos 5)!  Please see:


   for more details.

28a. - QSSTV - Compiling it

  | IMPORTANT: The new Qsstv 9.4.2 release is now using C++ v11 compiler constructs |
  |    #1      that are N)T supported by the native Centos 6.10 compiler GCC 4.8.x. |
  |            Newer GCC-C++ versions are required but fortunately the Centos SCL   |
  |            system solves this.  See below for more information.                 |

  | IMPORTANT: The top section of this chapter covers QSSTV 9.4.2 for Centos6.     |
  |    #2      If anything else, I've had good luck with v8.2.12 which has a few   |
  |            less features but might be more stable.                             |
  |                                                                                |
  |            Older versions of Qsstv like 8.1.x, 7.x, and 5.3c are still         |
  |            covered in the bottom of this section but they should be considered |
  |            DEPRECATED.                                                         |

   Build prerequisites Centos6 users
   To properly build QSSTV 9, you need to install following libraries before hand:

      - devtoolset-8-gcc-c++   - SCL offered newer SCL compiler Covered in the inspectrum section
      - fftw-devel (version 3) - Covered in the WSJT and TXAMADRM section
      - qt5-devel              - Qt-5.x libraries which is Covered in the Gqrx section
                                 (new as of 9.2.6)
      - hamlib-devel           - Covered in the Fldigi section
      - alsa-lib-devel         - Covered in the Soundmodem and Fldigi section
      - openjpeg2              - covered in this section
      - openjpeg2-devel        - covered in this section
      - libv4l-devel           - covered in this section and new to Qsstv 9.x
      - libpulse-dev           - Pulse Audio libraries

      | Important:                                                                           |
      |                                                                                      |
      | Per the C++ v11 requirement, please review the "48b. - Install newer GCCc++ via SCL" |
      | section on how to install SCL.                                                       |
      |                                                                                      |
      | Per the above Qt5 requirement, please review the "42.j1 - Gqrx - Installing final    |
      | Gqrx dependencies" section in this document to install Qt5                           |

   # Ok, lets get a SRPM to start our work with
   cd /usr/src/redhat/SRPMS
   # Centos 6 - You can use my SPEC file (recommended) or build your own using the Fedora16 package 
   #            (same GLIBC version as Centos6)

   # ---------------------------------------
   #  Using my SPEC file:
   #  (Recommended)
   # ---------------------------------------
   cd /usr/src/redhat/SPECS
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/qsstv-9.4-scl.spec
   cd /usr/src/redhat/SOURCES
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/qsstv-9.4.2-fallthrough.patch

      # NOT RECOMMENDED: If you want to build an older version, you can find legacy SPEC files:
      cd /usr/src/redhat/SPECS
      wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/qsstv-9.3.spec
      wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/qsstv-9.spec
      wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/qsstv-8.spec
      wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/qsstv-7.spec

   #Now skip ahead to the next section

      # ----------------------------------------
      # If you want to create your own spec file
      # ----------------------------------------

          # Get a starting spec file from http://koji.fedoraproject.org/koji/packageinfo?packageID=6659  
          wget http://kojipkgs.fedoraproject.org//packages/qsstv/7.1.7/1.fc16/src/qsstv-7.1.7-1.fc16.src.rpm

          #Rename any old spec files if present
          cd /usr/src/redhat/SPECS
          mv qsstv.spec qsstv-7.1.7.spec
          rpm -ivh qsstv-7.1.7-1.fc16.src.rpm
          mv qsstv.spec qsstv-9.spec

          # Now let's update the spec file to reflect the new code and requirements
          cd /usr/src/redhat/SPECS
          vim qsstv-9.spec
            1. Update the Version to: 9.1.7
            2. Update the License to: GPLv3
            3. Update the Source0 line to:  http://users.telenet.be/on4qz/qsstv_9/downloads/qsstv_%{version}.tar.gz
            4. Delete the previous version's patches by removing the following lines

                 Patch0:         qsstv-fix-html-doc-path.patch
                 Patch1:         qsstv-fix-target-path.patch
                 Patch2:         qsstv-gcc47_unistd.patch


                 %patch0 -p1 -b .docpath
                 %patch1 -p1 -b .targetpath
                 %patch2 -p1 -b .gcc47

            5. Update and add the following BuildRequires lines:

                   BuildRequires:  fftw-devel >= 3.0
                   BuildRequires:  qt-devel >= 5.0
                   BuildRequires:  openjpeg2
                   BuildRequires:  openjpeg2-devel
                   BuildRequires:  libv4l-devel

            6. Disable the sed command: 
                 #sed -i 's| strip $(TARGET);||g' src/src.pro

            7. IN the %files section, delete the line:


   # -------------------------------------------------
   # Back to all users (For all SPEC file approaches):
   # -------------------------------------------------

   # Next, let's get the new version of QSSTV as of 05/06/19:
   cd /usr/src/redhat/SOURCES
   wget http://users.telenet.be/on4qz/qsstv/downloads/qsstv_9.4.2.tar.gz

Next, let's install the new OpenJPEG libraries from the EPEL Repo
(New to replace the obsolete Jasper JPEG libraries):

   sudo yum install openjpeg2 openjpeg2-devel

Ok!  Time to build and install Qsstv

   cd /usr/src/redhat/SPECS

   #Centos6 with x86_64
   #  Takes 4m7sec on a i5-2430-2.4Ghz laptop with 4GB RAM and a SSD HD
   time rpmbuild -bb --target=x86_64 qsstv-9.4-scl.spec

   #Now install it with
   sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/qsstv-9.4.2-1.el6.x86_64.rpm

Skip to the next section on how to configure QSSTV 9.x and use it

28b. - QSSTV - Building older versions

This section covers the building of the OLDER version of QSSTV - NOT RECOMMENDED

Qsstv 5.3c (which works very well) for Centos5 users as well as v7.1.7 for 
Centos6 users but neither version supports HamDRM digital SSTV - only analog SSTV

You can download this new version and older versions at:


  Notes on the different versions of QSSTV:
  QSSTV 7.1.7 - Requires a more modern distribution like Centos 6
                or MAJOR low-level changes to Centos5 to get working (not

  QSSTV 6.0a (alpha) - Unusable - has *major* slant issues and others have 
                       complained as well.  It was never fixed

  QSSTV 5.3c - works fine with Centos5 but it's image editor is very difficult 
               to use

As usual, there are two ways to get things installed.  RPMs or Sources.  Using the SRPM
from Fedora works very well and already includes the required patches to get things
working without any fuss.

SRPMS: Downloading them which includes the Sources and Patches
    cd /usr/src/redhat/SRPMS
   # Centos 6 - Use the Fedora16 package (same GLIBC version as Centos6)
   #   from http://koji.fedoraproject.org/koji/packageinfo?packageID=6659  
   wget http://kojipkgs.fedoraproject.org//packages/qsstv/7.1.7/1.fc16/src/qsstv-7.1.7-1.fc16.src.rpm
   rpm -ivh qsstv-7.1.7-1.fc16.src.rpm

   #For Centos5 - Used the Fedora Core 9 (same GLIBC version as Centos5)
from http://koji.fedoraproject.org/koji/packageinfo?packageID=6659  -->
    wget http://kojipkgs.fedoraproject.org/packages/qsstv/5.3c/3.fc9/src/qsstv-5.3c-3.fc9.src.rpm
    rpm -ivh qsstv-5.3c-3.fc9.src.rpm

Build prerequisites (skip this for Centos6 users):
To properly build QSSTV 7.1, you need to install following libraries before hand:

   - fftw-devel (this is version 3) - Covered in the WSJT and TXAMADRM section)
   - qt-devel       - Qt-4.4 libraries which is Covered in the WSJT section
   - hamlib-devel   - Covered in the Fldigi section
   - alsa-lib-devel - Covered in the Soundmodem and Fldigi section

Centos5 ONLY SPEC changes (skip this for Centos6 users):
   The provided 5.3c SPEC file for Centos5 needs two modifications.  One is to 
   require Qt-4 (qt-4.4 actually) and another to resolve an RPM building issue):

   vim qsstv.spec

   #  Change the line:
          BuildRequires:  qt3-devel
   # to
          BuildRequires:  qt-devel

   # and

   #  Change the line:
        desktop-file-install \
         --dir=${RPM_BUILD_ROOT}%{_datadir}/applications %{SOURCE1} 
   #   to
        desktop-file-install \
         --dir=${RPM_BUILD_ROOT}%{_datadir}/applications %{SOURCE1} --vendor=""

Ok!  Time to build it!

   #Centos6 with x86_64
   rpmbuild -bb --target=x86_64 qsstv.spec
   rpm -Uvh /usr/src/redhat/RPMS/x86_64/qsstv-7.1.7-1.el6.x86_64.rpm

   #Centos5 with i686
   rpmbuild -bb --target=i686 qsstv.spec
   rpm -Uvh /usr/src/redhat/RPMS/i686/qsstv-5.3c-3.i686.rpm

  INCOMPLETE:  Legacy issues related to Qsstv 6.0 Alpha

       other qsstv users

    --gt; Seems the solution is to turn off "Auto Slant Adj."

  Ubuntu bug tracking slant problems - no assignment

28c. - QSSTV - Configuring and Using Qsstv

Before you start qsstv for the first time, make the following directories:

         mkdir -p $HOME/Qsstv/Receive
         mkdir $HOME/Qsstv/Templates
         mkdir $HOME/Qsstv/Transmit
         mkdir $HOME/Qsstv/Audio

   Centos Users running Qsstv 9.x, 8.x and 7.x:

      NOTE on upgrades from 8.x to 9.x
      If you have been using Qsstv 8.x and are now upgrading to 9.x, please note 
      that your previous configuration files will NOT load.  You will need to 
      reconfigure the application for file paths, rig control, etc.

   Ok, next step.. Get the Qsstv example QSO templates:

         cd $HOME/Qsstv/Templates
         wget -r -l 1 -np -nd http://users.telenet.be/on4qz/qsstv/templates

    Next, let's figure out what soundcard you need to use for Qsstv.  Qsstv 
    both supports PulseAudio and native Alsa.  Run the command 
    "cat /proc/asound/cards" and note the correct Soundcard that is connected
    to your radio.  For me, it's device "2":

       [dranch@hampacket Qsstv]$ cat /proc/asound/cards

       0 [I82801DBICH4   ]: ICH4 - Intel 82801DB-ICH4
                            Intel 82801DB-ICH4 with STAC9750,51 at irq 7
       1 [Modem          ]: ICH-MODEM - Intel 82801DB-ICH4 Modem
                            Intel 82801DB-ICH4 Modem at irq 7
       2 [default        ]: USB-Audio - USB Audio CODEC
                            Burr-Brown from TI USB Audio CODEC  at usb-0

   Now start up QSSTV
   Configure it in Options --> Configure

      Personal Settings:
           - Callsign: <your callsign>
           - First name
           - Last Name
           - QTH
           - Locator (Grid square)

           - set the paths to match the ones we created above

           Leave the RX/TX clock frequency alone for now

           Input / Output Audio device:

                Qsstv 9.x on Centos6: I set it to "pulse" to use the Pulse
                                      Audio system but I could have also hard 
                                      coded it to "hw2,0"

                   NOTE:  Qsstv 9.1.1: I've tried the native ALSA mode but I've 
                          seen where the waterfall display will STOP updating and 
                          the interface won't respond properly.  Sometimes toggling
                          between SSTV (analog) and DRM (digital) will get
                          the waterfall going again

                Qsstv 5.3: set the Audio device (for me) to: /dev/dsp2
           Qsstv 5.3: Serial port for PTT (for me): /dev/ttyUSB1

      CAT and PTT (Qsstv 9.x):

          This section is a bit confusing.  The use of Hamlib within Qsstv is ONLY 
          to key up the radio (PTT) and nothing more.  There isn't any VFO control, 
          filter control, etc.  In addition to that, you can only configure *either* 
          CAT services to key up the rig *or* enable the "special serial port" to 
          key up the rig.   If you try to enable both, and click on ok, you'll get a 
          non-helpful error.  

          For me, I use the "special serial port" PTT method

           NOT checked: Enable Hamlib Cat interface

              NOTE#2: On the FT950, if you use CAT-based PTT while the radio is 
                      in SSB mode, the radio will only listen to the front facing 
                      MIC port!  Either you need to put the radio in PKT mode 
                      (not SSB mode) or you need to use the special serial port 
                      serial approach to key the rig.

           Checked: Enable PTT serial interface
                          Serial port: /dev/USI_PTT

             NOTE: Investigating: It seems that the QSSTV system needs to be
                   !!!!!!!!!!!!!  configurable of which RS232 signal to assert to
                                  key up various radios.  It needs to be similar to 
                                  say how Flrig does things since:

                                  - FT950: If the FT950 is used with a US Interface 
                                    Navigator (now Timewave) soundcard *and* the 
                                    radio is in SSB mode and I use Qsstv's "Serial 
                                    PTT" option, the rig will key up.  You will hear 
                                    the analog SSTV signal BUT unfortunately also hear 
                                    a solid CW tone on top of that signal. Once Qsstv 
                                    stops sending it's signal, the FT950 radio will 
                                    remain keyed up and sending that CW tone until 
                                    QSSTV is shutdown!  

                                    This behavior is due to Qsstv asserting the 
                                    DTR RS232 signal high *and* the FT950's Menu 
                                    #41 option (Allow to send CW while being in 
                                    SSB mode) being set to "ON".  The DTR line 
                                    on the Navigator means "CW system, key up and
                                    transmit your tone"!   

                                    Workaround:  You need to either change the 
                                                 FT950 menu option #41 to OFF or 
                                                 Qsstv needs to be changed to NOT 
                                                 use the DTR serial line.  The 
                                                 FT950 option #41 OFF setting 
                                                 works but until Qsstv is shutdown, 
                                                 you will still see the "CW" LED 
                                                 lit up.  The downside here is if 
                                                 you accidentally change the FT950 
                                                 to CW mode, the radio will instantly 
                                                 key up and won't stop transmitting 
                                                 until you either shut down Qsstv!
                                                 Even if you turn off your radio and
                                                 turn it back on, it will again key up
                                                 and send a constant CW tone.

                                    I've already requested the developer to add a 
                                    "!DTR" (do NOT assert DTR ever) feature as of 02/14/15 
                                    but this might take some time.

                                  - If the rig is in PKT mode and you use QSSTV's 
                                    "Serial PTT" option, the rig does properly key 
                                    up, the SSTV signal is there but now there isn't 
                                    the incorrect solid CW tone.  Yay!

      CW : Text to send to: "(callsign) - qsstv"

   Now click on OK and then close and restart the program

   Configure PulseAudio with Centos6

      - Make sure your radio is powered up and is configure for low power or 
        transmitting into a dummy load

      - Start the PulseAudio Volume Control "pavucontrol") program

      - Go to the Recording tab, find the "QSSTV" application and change the 
        Capture source to your proper sound device (don't select the "monitor" 
        version of a given device)

      - Next, while leaving the PAVC program running, switch back to Qsstv
        and go to the Transmit tab

           - Click on the middle-ish folder icon and select a picture file,
             (any picture file for now).  That picture should show up in the
             right hand preview window

           - Now click on the upper right "Play" button and QSSTV should start
             transmitting.   For me, it started playing to the laptop's built-
             in soundcard (not what I wanted).  To fix that, 

           - Go back to PAVC, select the playback tab and you should now see
             "ALSA plug-in [qsstv]: Alsa Playback on:" and for me, I want to 
             switch it to "USB Audio CODEC analog stereo"

           - At this point, your radio should key up and start transmitting!

   Upon restart, you will now see a FFT display in the lower left corner (5.3),
   lower right (7.1), or all of the right side on 9.x.  You can click on the FFT 
   box and change the view to be a water fall display instead.

  Calibrate the Soundcard with WWV and the calibrate feature

   * Full Duty Cycle modes and you radio's transmit power:                     *
   *                                                                           *
   * QSSTV is a high duty cycle mode and unless your radio supports full       *
   * power on high duty cycle modes (rare except on some Icom, Elecraft, etc), *
   * you MUST set the radio to a lower output level.  Read the Fldigi section  *
   * for more details about tuning power levels, controlling ALC, etc.          *

   Follow the Qsstv documentation on how to calibrate your Slant / time skew:


  Resizing pictures:
  It's important to remember that Qsstv isn't fast in transferring pictures 
  due to the limited RF bandwidth HAMs are allowed to transmit with.  As such,
  images shouldn't be too big or they will take FOREVER to transfer!  To reduce 
  the image size, you need to do image pre-processing.  This is best done with 
  either the ImageMagick or GraphicMagick programs.  For now, I'm 
  using use GraphicsMagick:

    To aid in finding a small enough size picture to transmit, I wrote the 
    following extra script to simplify the converting to JPEG2000, resizing, 
    and changing of the quality metrics to get files to fit a chosen 
    do-not-exceed size:


  One final note:
    - All Qsstv configuration settings are stored in $HOME/.config/ON4QZ and
      all picture files are stored in $HOME/Qsstv

Ok, after all that, you're now  ready to transmit and receive SSTV pictures!

29. - GeoID - MaidenHead distance calculator

  | To be updated for Centos6 |

GeoID is a simple MaidenHead to Distance / heading tool from the makers
of Fldigi.  It's not great but it's not terrible either:

  Dependencies:  If you've built FLdigi, you're good to go

  Download it at http://www.w1hkj.com/#Geoid and into /usr/src/redhat/SOURCES

  cd /usr/src/redhat/BUILD
  tar xzvf /usr/src/redhat/SOURCES/fl_geoid.src.tar.gz
  cd fl_geoid
  cp geoid /usr/local/bin/
  #Log as the user you plan on being when running fl_geoid
  cd /usr/src/redhat/SOURCES/fl_geoid

  Run "geoid"

  On first run, select the QTH tab and put your location in.  Goto Files -->
    Save QTH

  Now try it out, go to the "Grid/Lan-Lon" tab, put in a location and then
    click on > Lat Lon and then COMPUTE

30. - IBP - International Beacon Project beacon tracker

  need to write it up, easy to install, simple NCURSES interface

This is the main window following the beacons in their specific geography:

31. - Dream - Digital Radio Mondiale (DRM) - Digital Phone - transmit/receive

DRM or Digital Radio Mondale is a next generation digital broadcast system for use for
domestic radio, shortwave radio (ultra long distance), and HD digital voice/data, etc.   
Generally speaking, DRM is a commercial broadcast technology so it's not used in amateur
radio but the most common use of DRM *like* technology in amateur radio uses is EasyPal 
which uses the lower bandwidth HAM-DRM for digital SSTV transmissions.

This section also briefly touches on Linux software to decode DRM broadcasts

  | To be updated for Centos6 |

  Ultra Important full-stop notes:

  1) The Dream software that decodes DRM broadcast signals ***requires*** a radio 
     which passes a 20Khz pass-band (most amateur radio's only pass 3.5Kkz).  This 

      - requires hardware modifications of modern Amateur radio HF rigs  
      - use an SDR or a pan-adapter (Flex, RTL, SoftRock, etc)

     |Putting it another way, unless you have a radio that supports a 20Khz|
     | passband, this program will NOT work for you!  Don't bother         |
     | installing unless you have the required hardware!                   |

  2) Centos 5 specific: 
     This software is NOT compatible with WSPR without extensive chrooting.  
     Installing this WILL break your WSPR install.  Ask me how I know!

  Other DRM-compatible software (all OSes):

     - SoDiRa : Windows : http://www.dsp4swls.de/sodira/sodiraeng.html
               Decodes AM envelope, AM synchronous, AM stereo, LSB, USB, FM, FM Broacast, DRM30, 
               DRM +, AMSS, DCF77, RDS, RF sensors

  | To the reader:  This DReAM section is generally incomplete as it didn't work on Centos 5 |
  |               and I haven't tried to apply to Centos 6.  For general Ham-DRM SSTV,       |
  |               skip this section and skip down to the Qsstv section                       |

The DReaM program requires a few specific packages.  Please see the DRM build pages for 
full details:


  Some Linux specific DRM building instructions beyond these instructions can be 
  found at:




  NOTE:  I also found an older Binary RPM for Dream:


Older notes: 

   - legacy FFTW libs (The FFTW v3 library installed for WSPR are too new):

     yum install fftw fftw-devel
     #  Will install fftw-2.1.5-4.el5.rf.i386.rpm and 

        NOTE: Not sure if this will be a conflict with WSPR that needs FFTW3
              both libs are installed at the same time

   - QT4
     rpm -ivh ftp://ftp.pbone.net/mirror/ftp.centos.org/5.5/os/x86_64/CentOS/qt4-4.2.1-1.i386.rpm \

   - FAAD2 for MP4
        #Note:  the faad2 available in Yum is not compatible as it won't
                support encoding (only decoding)

         yum install faad2 faad2-devel

   - FAAC for MP4 encoding  (the documentation does NOT mention this 
        requirement anywhere!  Grrr..

         yum install faac faac-devel

   - Ccache to help install QWT

       yum install ccache 
          installs ccache.i386 0:2.4-1.2.el5.rf

   - QWT : NOTE the current version of qwt is 5.1.2 which is TOO new for DRM 
           (sheesh!)  They recommend to use their SRPM

     cd /usr/src/redhat/SRPMS
     wget http://drm.sourceforge.net/download/qwt-4.2.0-1.src.rpm
     rpm -ivh qwt-4.2.0-1.src.rpm
     cd /usr/src/redhat/SPECS

     #There is a bug in their SPEC file.  Find the following line:

        (cd examples; make"CXX=`which ccache` g++")

      and make it look like the following (added a space)

        (cd examples; make "CXX=`which ccache` g++")

     rpmbuild -bb --target=i686 qwt.spec

     rpm -ivh /usr/src/redhat/RPMS/i686/qwt-4.2.0-1.i686.rpm \

Unstable release is incomplete -- missing bootstrap files
Download DRM unstable  (this is MUCH newer than the posted 1.12b release)

    Get the unstable version

    mkdir /usr/src/redhat/SOURCES/drm-unstable
    cd /usr/src/redhat/SOURCES/drm-unstable
    svn co https://drm.svn.sourceforge.net/svnroot/drm drm

    #now clean it up to be compiled into a RPM
    cd /usr/src/redhat/SOURCES/drm-unstable/drm
    rm -Rf aqua rsci theseus
    cd dream
    mv * ..
    cd ..
    rm -Rf dream
    cd ..
    tar czvf /usr/src/redhat/SOURCES/drm-1.5.tar.gz *


    sh bootstrap

Legacy info -- old dream 1.12b

Legacy info -- incompatible newer versions of qwt


     rpm -ivh ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/9/Everything/i386.newkey/os/Packages/qwt-5.0.2-6.fc9.i386.rpm \ 

     rpm -ivh \
http://www.gtlib.gatech.edu/pub/fedora-epel/5/i386/qwt-5.1.2-0.el5.i386.rpm \

     Legacy DRM provided FAAD code
     Using the DRM team's version of FAAD
         cd /usr/src/redhat/SRPMS
         wget http://drm.sourceforge.net/download/faad2_2.0.1cvs2006124_1.src.rpm
         rpm -ivh faad2_2.0.1cvs2006124_1.src.rpm

         cd /usr/src/redhat/SPECS
         rpmbuild -bb --target=i686 --define without_xmms=1 faad2.spec

         rpm -ivh /usr/src/redhat/RPMS/i686/faad2-2.0.1cvs2006124-1.i686.rpm \

32. - Tuning Dream -DRM

  | To be updated for Centos6 |


33. - RXAMADRM - Receiving Digital SSTV

This is the main window for receiving HamDRM SSTV images:

  | NOTE:                                                                    |
  |       I generally recommend all Ham-DRM SSTV users to use Qsstv now as   |
  |       it's more stable, has better features, and receives more updates.  |
  |       Please skip to that section for all the details.  I've left these  |
  |       chapters in this doc just for historial reasons.                   |

RXAMADRM is a program that comes as part of the TRXAMADRM packet that receives 
digital SSTV images that's compatible with the popular EasyPal SSTV program 
for Windows.  This program uses a version of Digital Radio Mondiale called HamDRM 
which has a narrower passband version of DRM.  There is a sister program called 
TXAMADRM which is the transmitter companion program and is described in the next 
section.  Today, these two programs come in a common archive but are run separately.
There are plans to unify the two programs into one interface but that's going to
take a while.  It's worth noting that the TRXAMADRM suite of digital SSTV programs 
is different than say the QSSTV application which supports *analog* SSTV images.

  | NOTE #2:                                                                 |
  |       RXAMADRM is NOT recommended for use on Centos5.  It's dependencies |
  |       break too many things on Centos5 and the older versions of the     |
  |       application wasn't stable, reliable, or very useful in it's        |
  |       previous versions.  More notes are below but I recommend to ONLY   |
  |       use TRXAMADRM with Centos6.                                        |

For more information on the history of TRXAMADRM and DRM in general, please read:

  | NOTE #3:                                                                 |
  |                                                                          |
  |   I have been working extensively with Ties Bos, the developer on the    |
  |   TRXAMADRM suite.  He's very responsive to comments, bug reports, and   |
  |   feature requests.  The newest versions work MUCH better, they now      |
  |   support RS1, RS2, and RS3 file formats, have faster DRM, 4-stage       |
  |   syncing, and now have BSR support!                                     |

     NOTES missing from the sparse TRXAMADRM documentation:

      - For B/16 QAM, the S/N should be well above 10 dB to produce results
      - The radio offset should be 350 
      - The range of D_FS signal should be no more than about 5 ppm (I've seen 
        -50 to 81!)

  Compiling TRXAMADRM for Centos6:
     - Download the current version of the receiver code

         cd /usr/src/redhat/SOURCES
         wget http://www.pa0mbo.nl/ties/public_html/hamradio/rxamadrm/trxamadrmv10_16Ubuntu.tgz

     - Next, you need to install some dependencies (if not already installed):

         yum install fftw
         yum install fftw-devel
         yum install tkimg
         yum install expect
         yum install jasper jasper-libs   #required for rs2 to JPEG conversion

         NOTE:  Old TRXAMADRM Versions used the old fftw v2 libraries but they are no longer needed.  I'm
                leaving this in here just in case some people cannot use the new fftw v3 versions:

                   yum install http://dl.atrpms.net/el6-x86_64/atrpms/stable/fftw2-double-2.1.5-14.el6.x86_64.rpm
                   yum install http://dl.atrpms.net/el6-x86_64/atrpms/stable/fftw2-double-devel-2.1.5-14.el6.x86_64.rpm

     - Next, you need to know which sound device number you need to listen to.  
       Run the following command and not down your proper sound card.  For me,
       need to listen to the USB-Audio device (#1):

          cat /proc/asound/cards
           0 [PCH            ]: HDA-Intel - HDA Intel PCH
                                HDA Intel PCH at 0xc0600000 irq 31
           1 [default        ]: USB-Audio - USB Audio CODEC
                                Burr-Brown from TI    USB Audio CODEC  at usb-0000:00:1d.0-1.1.1, full

     - Now expand the source code to make these changes:

          cd /usr/src/redhat/BUILD/
          tar xzvf ../../SOURCES/trxamadrmv10_16Ubuntu.tgz

     - Now make the new RXAMADRM code:

          cd trxamadrmv10_16/rxamadrmv1_6/

          #Ignore any errors here
          make clean


     - Next, since things are still not in a RPM, let's make sure we can write in this directory

          chown -R $USER .

     - Go ahead and run the new program by running:


     - When this program opens up, you should see two windows.  One is the main program
       window and the other is the receive waterfall window

Configuring RXAMADRM:
     - Once running, change the "Set Sound Device" in the lower right corner to 
       the proper sound card as found above

       NOTE: If you receive errors about "wish", the rxamadrm.tcl program might have 
             an incorrectly defined "wish" path. To fix it, do the following:
            - Run the command:

                whereis wish
                wish: /usr/bin/wish /usr/bin/wish8.5 /usr/share/man/man1/wish.1.gz

            - Edit the rxamadrm.tcl file to reflect the result from the previous command:

                Change the top line to reflect /usr/bin/wish8.5

      - After that, there really isn't anything to configure other than getting
        the sound levels right.  This is now pretty simple with the waterfall window.
        You want the DRM signal to be a light yellow with much of the background being

      - Optional:

          RXAMADRM now has the ability to automatically upload any good images to 
          an FTP site on the Internet.  If you want to use this feature, you need to
          edit the ftp.ini file to reflect a valid FTP server, username, password, and

          You can see the status of your FTP transfers via the lastftp.txt file

  | DEPRECATED:  Trying to use TRXAMADRM on Centos-5:                      |
  |                                                                        |
  | If you REALLY want to move forward with running this program on        |
  | Centos5, here are my previous notes and, BTW, good luck.  You *are*    |
  | going to break MANY aspects of your Centos 5 install including, Yum,   |
  | etc.                                                                   |

  Broken: Legacy Centos5 notes:
    * As mentioned before, trying to install RXAMADRM / TXAMADRM on Centos5 
      is *not* recommended as these programs require a newer version of 
      TCL/TK than what ships in Centos5 (tk-8.4.13-5.el5_1.1).  Installing 
      this newer version of TK/TCL *breaks* the WSJT weak-signal program among 
      others as the two versions of TCL cannot coexist.

      If you still want to try on Centos5, read on:

      To backup the below changes (that did NOT work out well.. made a
      mess of things, do:

        rpm -e --nodeps tcl tcl-devel tk tk-devel expect tkimg
        yum install tcl tcl-devel tk tk-devel expect tkimg

    rpm -ivh --nodeps ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/9/x86_64.newkey/tcl-8.5.2-2.fc9.i386.rpm \

   complains about
        libtcl8.4.so is needed by (installed) expect-5.43.0-5.1.i386
        libtcl8.4.so is needed by (installed) tk-8.4.13-5.el5_1.1.i386
        libtcl8.4.so is needed by (installed) tkinter-2.4.3-27.el5.i386
        libtcl8.4.so is needed by (installed)
        libtcl8.4.so is needed by (installed) alpine-2.00-2.el5.rf.i386
        tcl = 8.4.13 is needed by (installed) tk-8.4.13-5.el5_1.1.i386
        tcl-devel = 8.4.13 is needed by (installed)

    rpm -Uvh --nodeps ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/9/x86_64.newkey/tk-8.5.2-1.fc9.i386.rpm \

   complains about:
        libtk8.4.so is needed by (installed) tkinter-2.4.3-27.el5.i386
        libtk8.4.so is needed by (installed)

    # Tkimg was already installed for Xastir but since we've changed the
    # Tcl/Tk system, we have to align other packages to consistent

    rpm -Uvh ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/9/Everything/i386.newkey/os/Packages/expect-5.43.0-13.fc9.i386.rpm

    rpm -Uvh --force ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/9/Everything/i386.newkey/os/Packages/tkimg-1.3-0.9.20071018svn.fc9.i386.rpm

  - After all that, go ahead and follow the original setup configuration
    as described at the top of this chapter.

33. - TXAMADRM - Digital SSTV using HamDRM

This is the main window for transmitting HamDRM SSTV images:

   | NOTE:  I recommend users to switch to the Qsstv program    |
   |        which is under active development and also supports |
   |        analog SSTV as well.  Trxamadrm stopped receiving   |
   |        updates around November 2014                        |

The TXAMADRM program is the transmitter companion program to the RXAMADRM
Digital SSTV program.  Read the RXAMADRM section for more background on the


  Resizing pictures:
  It's important to remember that HamDRM isn't fast in transferring pictures so
  images shouldn't be too big or they will take FOREVER to transfer!  To reduce 
  the image size, you need to do some JPG image pre-processing.  This is best 
  done with either the ImageMagick or GraphicMagick programs.  For now, I'm 
  using use ImageMagick.

    To aid in finding a small enough size picture to transmit, I wrote the 
    following extra script to simplify the converting to JPEG2000, resizing, 
    and changing of the quality metrics to get files to fit a chosen 
    do-not-exceed size:


  - As of TXAMADRM 0.6S, the package now requires FFTWv3 and that is described 
    in the RXAMADRM section above as well as in the WSJT, WSPR, and Quisk sections

  - v0.6S now optionally supports Hamlib for PTT control.  If you don't have
    hamlib installed, you will have to enable VOX on you radio to key 
    up the radio

You already compiled the RXAMADRM program in the previous section so lets
finish the job with the TXAMADRM side of things:

  NOTE:  I have *not* RPMed this package yet

  cd /usr/src/redhat/BUILD/trxamadrmv10_16
  cd txamadrmv10

  ./configure --enable-alsa --enable-hamlib --disable-jack --disable-portaudio --disable-faad2 --disable-faac

  #Now run Make  (the -j4 makes it compile on four cores thus, compiles faster)
  make -j4


  #Since things are still not in a RPM, let's make sure we can write in this directory
  cd ../..
  chown -R $USER .

Running it:

  Before you start the program, we need to figure out what ALSA device to use 
  and optionally, what Hamlib rig you want to use.  To find these out,
  issue the command:

      cat /proc/asound/cards
      0 [PCH            ]: HDA-Intel - HDA Intel PCH
                           HDA Intel PCH at 0xc0600000 irq 42
      1 [Pro            ]: USB-Audio - SB X-Fi Surround 5.1 Pro
                           Creative Technology Ltd SB X-Fi Surround 5.1 Pro at usb-0000:00:1d.0-1.2, full
      2 [CODEC          ]: USB-Audio - USB Audio CODEC
                           Burr-Brown from TI USB Audio CODEC at usb-0000:00:1d.0-1.1.1, full speed

     If you plan on using Hamlib to key up your radio, you need to figure out what is the "number" of your 
     radio (assuming Hamlib is installed and your is supported by it).  To get that, do the following.  
     For example, to find the id of a Yaesu FT857, I would do:

       rigctl -l 2>&1 | grep 857
       122     Yaesu                  FT-857                  0.4         Beta

  Next, let's start the program.  Since I haven't RPMed this binary, you need to 
  run it from where we built the program so:

     cd /usr/src/redhat/BUILD/trxamadrmv10_16/txamadrmv10/linux

       or better yet, since we have the RX program installed too, you can use the 
       included startup script:
          cd /usr/src/redhat/BUILD/trxamadrmv10_16

  Using the combined startup script, the main menu for RXAMADRM should pop up with it's
  associated waterfall window.  An additional window should open up for the TXAMADRM
  transmit program as well.

Configuring TXAMADRM:

      1. Sound Card: 

         In the bottom bar of the window, find the "Set snd dev" and select 
         proper sound card as found in the above steps to properly transmit the 
         picture.  For me, I'm selecting "set dev=2"

      2. (Optional): PTT Control via a dedicated serial port or CAT commands:

         New versions of TRXAMADRM support keying up the radio via a dedicated serial
         line.  In the PTT box in the lower right, you need to select either:



              RTS / DTR for dedicated serial port mode

         Since I'm personally using a dedicated serial port via the US Interface
         Navigator, I selected "RTS".

            NOTE:  If you incorrectly set this to CAT but enter in PTT serial port
                   name in the "PTT Dev" field and your radio keys up and never un-keys,
                   you need to set this field to RTS or DTS and click on the "Save CFG"
                   button a few times to tell it to unkey.

      3. (Optional): PTT Control via a dedicated serial port:

         If you're keying the radio with a dedicated serial port (I am via the US Interface
         Navigator), type in the full serial path here.  For my Udev aliased serial port 
         (described in a previous section), I put in:


      4. (Optional): PTT Control via Hamlib:

           If you want to use CAT control to key the radio (can be an issue with some radios
           like the FT950) and assuming you're using a FT857,  and you have the Hamlib ID 
           number from above, go to the lower right corner of the window and select:

              Set Baud: 4800
              Hamlib model # TRX: 122
               NOTE: Different radios support different serial port speeds.  The FT857 only
                     supports 4800 but the FT950 supports 38400.  

      5. DRM modes:  Different DRM parameters are set depending on the band,
         the band conditions, etc.  For me, I usually use TXAMADRM in an unusual 
         fashion.  Specifically, we have a somewhat distant 2m repeater that
         we have a SSTV net every Friday!  For me, I need to set it to the following
         but you might have to enable much more error correction, etc. if you're 
         using HF:

             Mode     : B
             QAM      : 16
             Prot     : Norm
             Intlv    : Long
             Bandwidth: 2.5

      6. User information:

         In the upper left column, type in:

           Callsign: <Put in your callsign>
           Instances: Not sure what this is for

      7. Next, skip down a bit to the "None, RS1, RS2, etc. section and set the 
         RS setting that's proper for you.  Higher the RS, the higher the 
         error correction as needed with poorer HF conditions but slower the image 

      8. Next, you can optionally send text in the waterfall that's viewable by
         RXAMADRM, EasyPal, etc.  Click on the lower left box labeled WFALTXT
         and  type in your callsign in the pop-up box

Sound Card levels: 

    - I also using my FT857 with my US Navigator and the levels were 
      WAY too high.  I had to change the KDE mixer level for the output
      of the Navigator to 6 (out of 11 ticks) and roll back the Navigator's
      "RF output" knob to 85%.  At that point, everyone was very happy
      with the signal.


Old notes about upgrading Centos6's ImageMagik- to be deleted
Unfortunately it seems the stock version of ImageMagick that comes with Centos6 
is very old:

   - ImageMagick- (surprise, surprise.. current versions is 6.7.6)

  So, I recommend you get a more modern version but:

    NOTE: The "Centos" binaries posted on the official ImageMagick mirrors are for
          some reason NOT COMPATIBLE with Centos6.  They don't state a Centos 
          version but it can't be for Centos6.  So, you need to compile your
          own version.

      yum install OpenEXR OpenEXR-devel giflib-devel djvulibre-devel libwmf-devel

      cd /usr/src/redhat/SRPMS/
      wget -O ImageMagick.src.rpm http://imagemagick.mirrorcatalogs.com/linux/SRPMS/ImageMagick.src.rpm
      rpm -ivh ImageMagick.src.rpm
      cd ../SPECS/
      rpmbuild -bb --target=x86_64 ImageMagick.spec
      cd /usr/src/redhat/RPMS/x86_64/
      rpm -ivh ImageMagick-6.7.6-8.x86_64.rpm ImageMagick-devel-6.7.6-8.x86_64.rpm \

      kipi-plugins kipi-plugins-libs

      yum install http://imagemagick.mirrorcatalogs.com/linux/CentOS/x86_64/ImageMagick-6.7.6-9.x86_64.rpm \
http://imagemagick.mirrorcatalogs.com/linux/CentOS/x86_64/ImageMagick-devel-6.7.6-9.x86_64.rpm \

34. LinKT - HF/VHF/UHF packet terminal for Qt

  | To be updated for Centos6 |

  This is a KDE3 based AX25 terminal program which also supports ax25spy 
  decoding of packets.  In comparison, Linpac might be an older Ncurses 
  based program but Ncurses-based interfaces can get cumbersome after a 
  while.  I ultimately gave up on LinKT and went back to Linpac because 
  LinKT's interface is pretty rough and I really missed Linpac's features.

  If you want to push on with LinKT, download the newest version of LinKT 

  and put it into /usr/src/redhat/SOURCES

  cd /usr/src/redhat/BUILD

  #tar xivf /usr/src/redhat/SOURCES/monktd-0.3.1.tar.bz2
  tar xivf /usr/src/redhat/SOURCES/linkt-0.8rc3.tar.bz2
  cd linkt-0.8rc3

  Run it!

    No .SPEC setup here as I generally don't recommend this app as it
    currently stands

35. - Wine - Running Windows programs within linux (used for Outpost)

To run Windows programs under Linux, you have one of two options:

   - WINE: Run the Windows Compatibility Layer 

   - Emulation: Load a real copy of Windows under a virtual machine and run
                the program there

Wine has come a LONG way since it first started many years ago and it's both FAST
and it's compatibility is very good.  It's not perfect though so sometimes you
need to be patient with it.   So why do I want to run Windows programs on my 
Linux box?   The Outpost Packet Radio messaging program.  More about that
in the next section.

Installing Wine:
To install Wine on Centos, you need to enable the RPM Forge repositories to get the 
newest version of Wine.  This is covered in Chapter 1 of this document under the
Third Party Repos section.

To start off, let's install the newest version of wine.  

  Note to Centos 5 Users:
    - It seems v1.2.2 of Wine doesn't work well in controlling
      serials ports.  It's recommend to install v1.4 or newer

  Centos v6 and v5 users:
     yum install wine

     Centos-6: this will also install the following:
           wine.x86_64                     - 1.4.1-1.el6        - epel
           alsa-plugins-pulseaudio.i686    - 1.0.21-3.el6       - base
           cyrus-sasl-lib.i686             - 2.1.23-13.el6_3.1  - base
           flac.i686                       - 1.2.1-6.1.el6      - base
           libasyncns.i686                 - 0.8-1.1.el6        - base
           libexif.i686                    - 0.6.21-5.el6_3     - base
           libgphoto2.i686                 - 2.4.7-4.el6        - base
           libsndfile.i686                 - 1.0.20-5.el6       - base
           libtool-ltdl.i686               - 2.2.6-15.5.el6     - base
           libusb.i686                     - 0.1.12-23.el6      - base
           nss-mdns.i686                   - 0.10-8.el6         - epel
           nss-mdns.x86_64                 - 0.10-8.el6         - epel
           openal-soft.i686                - 1.12.854-1.el6     - epel
           openal-soft.x86_64              - 1.12.854-1.el6     - epel
           openldap.i686                   - 2.4.23-32.el6_4.1  - updates
           pulseaudio-libs.i686            - 0.9.21-14.el6_3    - base
           tcp_wrappers-libs.i686          - 7.6-57.el6         - base
           wine-alsa.i686                  - 1.4.1-1.el6        - epel
           wine-alsa.x86_64                - 1.4.1-1.el6        - epel
           wine-capi.i686                  - 1.4.1-1.el6        - epel
           wine-capi.x86_64                - 1.4.1-1.el6        - epel
           wine-cms.i686                   - 1.4.1-1.el6        - epel
           wine-cms.x86_64                 - 1.4.1-1.el6        - epel
           wine-common.noarch              - 1.4.1-1.el6        - epel
           wine-core.i686                  - 1.4.1-1.el6        - epel
           wine-core.x86_64                - 1.4.1-1.el6        - epel
           wine-courier-fonts.noarch       - 1.4.1-1.el6        - epel
           wine-desktop.noarch             - 1.4.1-1.el6        - epel
           wine-fonts.noarch               - 1.4.1-1.el6        - epel
           wine-ldap.i686                  - 1.4.1-1.el6        - epel
           wine-ldap.x86_64                - 1.4.1-1.el6        - epel
           wine-marlett-fonts.noarch       - 1.4.1-1.el6        - epel
           wine-ms-sans-serif-fonts.noarch - 1.4.1-1.el6        - epel
           wine-openal.i686                - 1.4.1-1.el6        - epel
           wine-openal.x86_64              - 1.4.1-1.el6        - epel
           wine-pulseaudio.i686            - 1.4.1-1.el6        - epel
           wine-pulseaudio.x86_64          - 1.4.1-1.el6        - epel
           wine-small-fonts.noarch         - 1.4.1-1.el6        - epel
           wine-symbol-fonts.noarch        - 1.4.1-1.el6        - epel
           wine-system-fonts.noarch        - 1.4.1-1.el6        - epel
           wine-tahoma-fonts.noarch        - 1.4.1-1.el6        - epel
           wine-twain.i686                 - 1.4.1-1.el6        - epel
           wine-twain.x86_64               - 1.4.1-1.el6        - epel
           wine-wow.x86_64                 - 1.4.1-1.el6        - epel

     Centos-5: this will also install the following:
             wine         - 1.3.12-1.el5.rft   - rpmforge-testing
             libtool-ltdl - 1.5.22-7.el5_4     - base
             mpg123       - 1.12.5-2.el5.rf    - rpmforge
             wine-capi    - 1.3.12-1.el5.rft   - rpmforge-testing
             wine-cms     - 1.3.12-1.el5.rft   - rpmforge-testing
             wine-core    - 1.3.12-1.el5.rft   - rpmforge-testing
             wine-esd     - 1.3.12-1.el5.rft   - rpmforge-testing
             wine-gecko   - 1.1.0-1.nodist.rft - rpmforge-testing
             wine-jack    - 1.3.12-1.el5.rft   - rpmforge-testing
             wine-ldap    - 1.3.12-1.el5.rft   - rpmforge-testing
             wine-nas     - 1.3.12-1.el5.rft   - rpmforge-testing
             wine-twain   - 1.3.12-1.el5.rft   - rpmforge-testing 

36. - Outpost - Graphical Packet messaging program via Wine

In my local ARES/RACES City affiliated and the county group both use the graphical Packet Radio 
messaging application for Microsoft Windows called "Outpost" written by Jim Oberhofer, KN6PE.  
This program looks similar to older versions of the Microsoft Outlook email program which gives 
an easy way for users to poll many different types of mailboxes across a lot of different local 
and remote hardware.  It also centralizes a lot of the common EmComm forms into one easy to use
portal.  You can find it's homepage available at:


Here is an example of the main Outpost window with various messages in the inbox

In addition to Outpost working phyical TNCs in KISS mode, it's also unique in that it
can alternatively use TNCs while running in command mode.  This is very nice for people
who want to leave their TNC's PBBS running while still doing other package messaging.
Outpost also supports working with remote TNCs via the AGW API so you can have Outpost
installed on a completely different computer in your home and use the network to connect
back to your packet-enabled system.  For this document, I will document how things work 
using a Kenwood D710 connected to a Linux system running it's native AX.25 protocol stack
teamed up with LDSPED to connect everything together with AGW support.  Readers can easily
change this to use Direwolf's AGW support as well.

   NOTE: I'd recommend to use Outpost with AGW support compared to say depending on Wine's
         serial port emulations as it's more reliable that way.  I do cover the serial port
         approach just in case you need that as well.

Before we install Outpost, we will configure Wine's serial ports though I again recommend
to use AGW instead (see above).  Direwolf users can skip this part of the section. 

Specifically, you first need to determine WHICH Linux serial port is connected to your TNC.  
In this example, I'm going to configure Outpost to use the FIRST serial port which is usually 
/dev/ttyS0 for built-in serial ports or /dev/ttyUSB0 for USB-based serial ports.  I'm using 
"aliased" UDEV naming so my serial port will always come up as USI_SER:

   mkdir -p ~/.wine/dosdevices/
   ln -s /dev/USI_SER ~/.wine/dosdevices/com1

  Centos 5 only - Older Wine Serial port issue workaround:
  With older versions of Wine such as v1.2, you needed to use a work-around 
  to fix a long-standing Wine serial port bug.  Do the following:

     cd /usr/src/archive/Outpost
     wget http://static.danplanet.com/preserve/serproxy.c
     gcc -o serproxy serproxy.c
     cp serproxy /usr/local/sbin

  Now go ahead and run the proxy:

     /usr/local/sbin/serproxy /dev/ttyS0

Ok, let's download and install Outpost:
Download the newest version of Outpost.   For my specific ARES/RACES group, we use a special 
version that comes with a set of forms included.  Few points to remember when installing Outpost 
with Wine:

   1. Don't run the "wine" command as the root user.  Run it as a regular user's permissions

   2. The Santa Clara County (SCC) customized version is here or you can download the main Outpost 
      release as well:

         #SCC Outpost version

         #Regular Outpost version

      In this example, I will install Outpost v145C (aka v330c065 with SCCoPIFO v2.17 Packit forms 
      and PacRelease v47 PacForms) which is intended for Santa Clara County ARES/RACES members but it
      will also work for all other supported AX.25 packet BBSes out there, etc.  Previously, I 
      installed Outpost v320c118 (aka version 139) with PacRelease v43.

   3. Get the code:

          cd /tmp
          wget https://www.scc-ares-races.org/data/packet/installer/sccsetup145Cpub.exe

   ** NOTE:   It's important that when you run Wine,    **
   **         you do NOT run it while being root!       **

     #Install or Upgrade an existing older version the Outpost program

        wine sccsetup145Cpub.exe

          - Follow all the prompts as instructed

          - All files will be installed into $USER/.wine/Application Data/SCCo Packet

          - Accept ALL of the installer's defaults 

     #Notes on the installation:

        Outpost 145C under Wine v1.8.6 notes:
          - Everything seems to work fine with LDsped's AGWPE interface.  It's worth noting that
            in the terminal window that you started the Outpost installation, you'll see various 
            warnings like the following.  Those are benign warnings and errors and things should
            work just fine
            #Messages seen at initial startup

            fixme:process:SetProcessDEPPolicy (1): stub
            fixme:process:SetProcessDEPPolicy (1): stub
            fixme:win:DisableProcessWindowsGhosting : stub
            fixme:graphics:ShutdownBlockReasonDestroy (0x1007e): stub
            fixme:graphics:ShutdownBlockReasonCreate (0x1007e, L"Installing"): stub
            fixme:graphics:ShutdownBlockReasonDestroy (0x1007e): stub
            fixme:graphics:ShutdownBlockReasonCreate (0x1007e, L"Installing SCCo Packet (PUBLIC EDITION)."): stub
            fixme:msg:ChangeWindowMessageFilterEx 0x1008c c045 1 (nil)
            fixme:msg:ChangeWindowMessageFilterEx 0x10094 c045 1 (nil)
            fixme:msg:ChangeWindowMessageFilterEx 0x20094 c045 1 (nil)
            fixme:shell:SHAutoComplete stub
            err:richedit:ReadStyleSheet skipping optional destination
            err:richedit:ReadStyleSheet skipping optional destination
            err:richedit:ReadStyleSheet skipping optional destination
            err:richedit:ReadStyleSheet skipping optional destination
            err:richedit:ReadColorTbl malformed entry
            err:richedit:ReadColorTbl malformed entry
            err:richedit:ReadColorTbl malformed entry
            err:richedit:ReadStyleSheet skipping optional destination
            err:richedit:ReadStyleSheet skipping optional destination
            err:richedit:ReadStyleSheet skipping optional destination
            err:richedit:ReadStyleSheet skipping optional destination
            fixme:shell:SHAutoComplete stub

            #Messages seen when the installer is copying in files, etc
            fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\SCCo Packet\\unins000.exe") stub
            fixme:ole:DllRegisterServer stub
            fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
            fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
            fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
            fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
            fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
            fixme:winsock:WS_EnterSingleProtocolW unknown Protocol <0x00000000>
            fixme:winsock:WS_EnterSingleProtocolW unknown Protocol <0x00000000>
            fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
            fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
            fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
            fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)
            fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
            fixme:toolhelp:Heap32ListFirst : stub
            fixme:advapi:EventRegister {77754e9b-264b-4d8d-b981-e4135c1ecb0c}, 0x4a09b0, (nil), 0xc1d050
            fixme:ntdll:NtQueryInformationFile Unsupported class (8)
            fixme:olepicture:OleLoadPictureEx (0x92e674,2246,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x33fa40), partially implemented.
            fixme:olepicture:OLEPictureImpl_SaveAsFile (0x12a538)-&(0x1387a8, 0, (nil)), hacked stub.
            fixme:olepicture:OLEPictureImpl_FindConnectionPoint no connection point for {33ad4ed2-6699-11cf-b70c-00aa0060d393}
            fixme:graphics:ShutdownBlockReasonDestroy (0x1007e): stub

     #Previous Outpost installation notes:

        Outpost 3.2 under Wine v1.8.6 notes:
          - Everything seems to work fine with LDsped's AGWPE interface and without the serproxy 
            work around

       Centos5 - I did see the following errors but nothing was fatal:
         1. The new v3.1 version requires a Wine tool called Gecko but 
            Wine will offer to download and install it automatically for you
         2. I saw several warnings during the install but none were fatal
            [libmpg123.c:79] error: Stack variable is not aligned! Your
            combination of compiler/library is dangerous!
            [libmpg123.c:79] error: Stack variable is not aligned! Your combination of
            compiler/library is dangerous!
            fixme:system:SetProcessDPIAware stub!
            fixme:iphlpapi:NotifyAddrChange (Handle 0x18ee954, overlapped 0x18ee958): stub
            wine: configuration in '/home/dranch/.wine' has been updated.
            fixme:win:DisableProcessWindowsGhosting : stub
            fixme:msg:ChangeWindowMessageFilter c058 00000001
            fixme:msg:ChangeWindowMessageFilter c058 00000001
            fixme:msg:ChangeWindowMessageFilter c058 00000001
            err:richedit:ReadStyleSheet skipping optional destination
            err:richedit:ReadStyleSheet skipping optional destination
            err:richedit:ReadStyleSheet skipping optional destination
            fixme:ole:CoCreateInstance no instance created for interface
            {ea1afb91-9e28-4b86-90e9-9e9f8a5eefaf} of class
            {56fdf344-fd6d-11d0-958a-006097c9a090}, hres is 0x80004002
            fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\SCCo
            Packet\\unins000.exe") stub
            fixme:ole:DllRegisterServer stub
            partially implemented.
            fixme:ole:OLEPictureImpl_SaveAsFile (0x125960)->(0x12cb98, 0, (nil)), hacked
            fixme:ole:OLEPictureImpl_FindConnectionPoint no connection point for

     Wine v1.2 Notes:
       Outpost under Wine v1.2 would work but it would send serial commands to the 
       TNC really REALLY slowly.  It eventually threw an error on the CLI of:

           fixme:comm:set_queue_size insize 1024 outsize 512 unimplemented stub

Everything should have installed for you into ~$USER/.wine/drive_c/Program Files/SCCo Packet 
and the installer would exit.  If that's not what you experienced, you'll need to troubleshoot 
those issues first.  

If this is your first time installing Outpost on your system, we now need
to make a few Wine config changes:

   Step #1 (optional:
     ** Users wanting to use Wine's serial port emulation over AGW access   **
     **                                                                     **
     **  Deprecated - I'm only including this if people want to try this    ** 
     **               with newer versions of Wine and it starts to work.    **
     **               If it does, please email me with the good news!       **
     **                                                                     **
     **              ***************************************************    **
     **              Native serial ports do not fully work in Wine v1.2.    **
     **              You must use the the proxy support described above     **
     **              ***************************************************    **
     **                                                                     **
     **  # My machine has a physical serial port that I need to use         **
     **  cd $USER/.wine/dosdevices                                          **
     **  ln -s /dev/ttyS0 com1                                              **

  Step #2: When I installed the new Outpost 145C under Wine v1.8.6 which uses the
           new "Packit" form system, it seemingly didn't create all the correct
           directories.  To resolve that, do the following:

              cd ~/.wine/drive_c/Program\ Files/SCCo\ Packet/

  Step #2: To run Outpost once installed, do the following:

     NOTE: When Wine is running, it does NOT register an icon with KDE in the
           bottom task list or when you look to use keystrokes like ALT-TAB! 

     cd ~/.wine/drive_c/Program\ Files/SCCo\ Packet/

     #OPTIONAL (legacy):
     #   NOTE to Wine 1.2 users: 
     #      Run the serproxy program as shown above

   Step #3:  Start up Outpost

     # Note #1: Make sure you are NOT the root user
     # Note #2: If you're using my packetrig.sh script to start up your station's
     #          AX.25 stack and other supporting processed like LDSPED, run that FIRST
     #          if you're going to use the AGW communication approach.  If you intend to
     #          use the serial emulation approach, you must first run the "packetrig.sh stop"
     #          command first to free up the serial port

     wine Outpost.exe

  Hopefully the Outpost program started successfuly for you and now you're prompted to either
  configure it for first time users or validate it's configuration for users that just upgraded
  Outpost.  The following steps assume the usage of MY amteur callsign, specific setup parameters, 
  etc.  Please make the required changes to reflect your own setup:
         User Call sign: KI6ZHD
         User name:      David Ranch

         Tactical:       --UNCHECKED--

         Message ID (quick set):

           Tactical ID: ZHD

  The main Outpost window should now open up.  You now have a choice of how you want to have Outpost 
  interact with your TNC be it via the AGW API, Command mode over the emulated serial port, or KISS over 
  emulated serial port.

     - RECOMMENDED: "AGW API mode" is where Outpost will communicate to a middleware API program that 
       controls your TNC be it a hardware TNC or software-TNC (Direwolf, etc).  In a previous section of
       this document, I detailed how to setup LDSPED to offer this interface.  Other soft-TNC programs like 
       Direwolf natively offer this interface though not when configured to be in KISS mode

       - The Linux AX.25 system and LDSPED system should already be running say 
         via the packetrig.sh script.  On the D710, the TNC is enabled via the lower 
         right corner button and the top left of the LCD display shows "PACKET12"
                   "Interface type" tab
                        Device Name:   SCCO_AGW
                      Device Type: AGW Packet Engine
                   "AGWPE" tab
                        Remote Host:
                        Remote port: 8000
                        Network Timeout: 5000
                     Radio Port:
                        TNC RadioPort: 1

     - NOT RECOMMENDED: "Command mode" is where Outpost will issue commands to your serial port connected 
       TNC much like you would do via a terminal program like Minicom, Hyperterminal, etc.  Everything is 
       in clear text.  The supported TNCs include: 

          - Kenwood D710
          - Kantronics KPC3+/KPC3
          - MFJ 127x, 
          - Timewave PK96, 
          - classic TAPR TNC2
          - others

         # Kenwood D710 users using "Command mode"
          - Make sure the Linux AX25 system is not running and not using your serial port 
            (no kiss mode) but you manually put the TNC into command mode.  On the D710, 
            pressing the lower right corner button and making sure the the top left of 
            the LCD display shows "PACKET12"

              Outpost Setup:
                      Interface type tab
                           Device Name:   SCCO_KENWOOD_710
                         Device Type: TNC

                      TNC Comm Port:
                           Comm port: Com1
                           Max Speed: 9600
                           Connection Preferences:
                              Data Bits:    8
                              Parity:       None
                              Stop bits:    1
                              Flow Control: RTS/CTS

  After configuring the TNC, clck on OK and now you should have a choice of what you want 
  Outpost to connect to.  These instructions are specific to the Santa Clara County BBS network.
  You'll need to change this to suit your desired remote Packet BBS system's details:

        Click on OK to goto the next screen
             BBS Name: [You need to change this to reflect your proper BBS for your area]
                       I'm using:
                                  SCC BBS 2 - Crystal Peak

             Connect Name: W2XSC-1
             BBS Type:     Let Outpost determine the BBS and set up the prompts

     For Wine 1.2 users using the now obsolete SerProxy approach
             Interface type tab
                  Device Name:   TELNET

             TELNET server:
                Remote Host:
                Remote Port: 2000
                  Max speed: 9600

             LOGON values:
                - UNcheck "Use station identifier"
                - Logon: W6XSC-1          (for my home QTH only)

36.a. - Outpost - Running Outpost

  * Reminder: If you're using the packetrig.sh script to run various packet stuff
    on your machine, you must shut it down first

  - QSY your radio to the correct packet frequency that the remote packet BBS is on.
    For me, it's 145.750Mhz - 1200bps AFSK, simplex, no PL

  - Start up Outpost (as shown above)

  - If you had previously used Outpost on another machine and want to use those
    previous message serial numbers, you can update Outpost to start from a 
    new number by doing the following:

      Tools --> Message Settings --> Edit Subject Line Identifier Values

          Next Message Number:  xxx
          City:                 City of Santa Clara
          State:                CA
          Tactical ID (3 char): ZHD

  - Goto Forms --> [pick a form]

  - A new PacForms window should automatically open up such as:

Here is an example of the main PacFORMS window

  - Fill out the form as instructed

  - Once done, click on the bottom center "SUBMIT the form to Outpost".
    You should then see a new web page stating:
      Your PacFORMS submission was successful!

      Press the BACK button to return to your FORM.

    - Back in Outpostm you should see the ASCII representation of that form
      waiting to be sent.  Click on the "To" field to send it to the proper

NOTE:  As of 7/13/19 with Outpost v145C, if I try to full out a form, I see the following error:

       7/13/2019 10:39:16am -- (NO) Outpost|Message directory "{{INSTDIR}}\pack-it-forms\msgs" does not exist

       I have connfirmed that the directory exists under .wine/drive_c/PackItForms/Outpost/SCCo/pack-it-forms/msgs
       but I beleive Outpost is looking for it in .wine/drive_c/Program Files/SCCo Packet .  I'm researching
       this issue right now.

NOTE #2:  On Reading PacForm messages with, the web browser will NOT open up
       and I see the following output in STDOUT.  I have emailed the 
       PacFORMS author to see if he has an idea how to fix this.
       fixme:msvcrt:MSVCRT__sopen_s : pmode 0x01ff ignored
       fixme:msvcrt:MSVCRT__sopen_s : pmode 0x01ff ignored
       fixme:msvcrt:MSVCRT__sopen_s : pmode 0x01ff ignored
       fixme:msvcrt:MSVCRT__sopen_s : pmode 0x01ff ignored
       fixme:msvcrt:MSVCRT__sopen_s : pmode 0x01ff ignored

          - - - - - - - - - - - - - - - - - - - - - - - - - - - (11/07/12, Ver. 4.4.5)

       Result from Pac-Read.ini file:
         READER = C:\PacFORMS\Exec
         DATAIN = C:\PacFORMS\Data\received
         DATAOUT = C:\PacFORMS\Data\sent
         DATADIR = C:\PacFORMS\Data
       fixme:msvcrt:MSVCRT__sopen_s : pmode 0x01b6 ignored

       :!PACF! ZHD148P_/_EOC Logistics Req_Santa Clara
       Invalid parameter.

       >>ERROR: File Name c:\pacforms\data\ZHD148P_~_EOC Logistics Req_Santa Clara.txt
        May not have been changed to ZHD148P_~_EOC Logistics Req_Santa Clara.read-txt
       ERROR STATUS: 256

37. - Chirp - Multi-Radio memory programming tool program

Chirp is is a graphical Python-based HAM radio memory programming tool that 
supports a multitude of Icom, Yaesu, and Kenwood radios HTs, mobiles, and 
now HF radios.  To be clear, this tool copies a source radio's memory
presents and stores them in a platform agnostic way that then allows the
user to uploaded these settings to other, non-similar radios thus allowing
you to synchronize all the memories for repeaters, ec.  Chirp does NOT record 
specific radio settings like DSP settings, CW key modes, APRS settings, etc.  

This is the main window that shows what was downloaded which you can directly edit, etc:

For my specific shack, Chirp supports my Kenwood TH-F6A HT and D710 mobile as well as 
my Yaesu VX5 HT and FT857 HF/VHF/UHF rig.  It even supports my Icom IC-80AD Dstar HT!

The RPM requirements for this application is Python, GTK, and PyGTK.  Centos
already comes with most of the dependencies by default (but not everything):


Chirp also needs the following other packages and manual installs:

      yum install libxml2-python 
      yum install python-argparse.noarch

      #We also need to install one more package manually:
      cd /tmp
      wget wget ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home:/uibmz:/unmaintained/CentOS_CentOS-6/noarch/python-serial-2.4-6.1.noarch.rpm
      sudo rpm -ivh python-serial-2.4-6.1.noarch.rpm

Ok.. You should be good now

   | Legacy:                                                                        |
   |                                                                                |
   |   Older versions of Chirp (say Nov 2017 and older) used PySerial system but    |
   |   Chirp now uses the Python-Serial module instead.  I'm leaving this older     |
   |   details in here for historical reasons only.  Most readers should ignore     |
   |   this section and use the above Python-serial instead.                        |

      More RPMs that we have to build ourselves:

         cd /usr/src/archive/Chirp

            #For 64bit systems
               rpmbuild -bb --target=x86_64 pyserial.spec
               rpm -ivh /usr/src/redhat/RPMS/noarch/pyserial-2.2-6.el6.noarch.rpm
            #For 32bit systems
               rpmbuild -bb --target=i686 pyserial.spec
               rpm -ivh /usr/src/redhat/RPMS/noarch/pyserial-2.2-6.el6.noarch.rpm

            wget -O pyserial-2.2-6.el5.test.src.rpm ftp://ftp.pbone.net/mirror/rpms.arrfab.net/centos/testing/i386/pyserial/pyserial-2.2-6.el5.test.src.rpm
            rpm -ivh pyserial-2.2-6.el5.test.src.rpm
            cd /usr/src/redhat/SPECS

      Newer Chirp radio drivers have added an additional dependency to work more 
      Python3 like.  This dependency is required to be installed even if you don't 
      intend on using those types of radios:

         pip install future

Ok... now that all the dependencies are install, the current released and beta versions 
of Chirp code can be found at:


To get the newest bleeding edge code out of the SVN depot, goto:


Though this tool runs via Python (non-compiled code) and thus doesn't need 
to be installed, an RPM is available to make things clean:

   yum install http://d-rats.com/yum/f11/d-rats-repo-0.1.2-1.fc11.noarch.rpm
   yum install chirp

Once the code is installed, simply run: 

37a. - Thoughts on Chirp and radio memory synchronization

As a new HAM, most people just start loading up various frequencies into their
single radio and don't think more about it.  As the bug spreads and they buy 
more radios, a problem starts to occur:

   - Different radios offer different numbers of memories.  For example, here are
     examples of different radios out there and the number of memories they support:

                   Kenwood  Kenwood  Yaesu   Yaesu  Icom    baofeng  baofeng  Wouxun
                   D710     TH-F6A   FT857D  VX5R   IC80AD  uv3r     uv5r     UV6D
                   -------  ------   ------  -----  ------  -----    -----    ------
        memories : 999      400      200     220    1000    100      128      199

     For my HW, the lowest common denominator is 200 memories

   - Different radios offer different frequency bands: 6m, 2m, 1.25cm, 70cm, 23cm, etc

To accommodate various radios, I came up with the follow plan and maybe this 
would be helpful to you so that the same memory number on ANY of your radios 
will be consistent:

     Memory 1-75 : reserved for 2m     (common to all radios)
       - 75 down is where I put the simplex frequencies

     Memory 75-89: reserved for 1.25cm (F6A)
       - 89 down is where I put the simplex frequencies

     Memory 90-99: reserved for 6m     (VX5R)
       - 99 down is where I put the simplex frequencies

     Memory 100-175: reserved for 70cm (common to all radios)
       - 175 down is where I put the simplex frequencies

     Memory 176-200: reserved for Police/Fire/etc monitoring (for radios that support wide-band receive)

38. - WXTOIMG - Decoding APT and WeFAX satellite images

  | To be updated for Centos6 |

WXtoIMG is a Multi-platform APT and WeFAX satellite decoder.  Grab the binary at:


rpm -Uvh /tmp/wxtoimg-2.10.11.i386.rpm

To run it:


Once the Xwindows box comes up, you have populate in the Lat/Long.
It has a course look up engine and I was able to put in:
   San Jose

but it didn't find my smaller, near-by city.

Set the radio to 137.10, 137.40, 137.50, 137.62, or 137.9125 FM (50kHz or NFM) 

39. - Winlink 2000 - Sending messages to / from Winlink Email, APRS, and Packet

Winlink 2000 is a distributed email system sponsored by the ARRL that is fundamentally
tied to the Internet and offers multiple methods of RF-based access for Amateur Radio 
operators.  Some of the access methods include:

      - HF data via WINMORE software-based TNC (Windows .net only as of March, 2011)
      - HF data via Pactor 2/3 (SCS proprietary TNCs)
      - AX.25 packet (mostly 1200b)
      - packet-based APRS messaging
      - TELNET over the Internet
      - Webmail over the Internet

There are several programs out there to create an easy to used interface to Winlink:

    - Paclink-Unix - a translational system that runs on Linux and provides any POP3 email 
      client running on your network to to interface to Winlink2k.  This supports both 
      VHF packet and HF Pactor links.  Very powerful!


    - Airmail is a Windows-only program that's similar to Outpost that 
      is it's own email reader and supports Winlink2k

    - Outpost for Windows also supports Winlink 2000 interfacing and it works
      under WINE for Linux

    - JNOS2 BBS system has B2F message compatibility with Winlink2k. It's not 
      a client per se but a relaying system

    - BPQ32 BBS system for Windows and Linux has support for VHF packet and
      HF Pactor Winlink support

    - Linux-RMS-Gateway - Older package (might not be maintained anymore)
         which replaced "Telpac-node Linux" 
         This is a Linux solution to run your own RMS gateway on Packet 
         radio that interfaces to Winlink CMS messaging servers on the 

Specific setup details might be added at a later time but until then, please
see the following URL for setting up Paclink-Unix on Linux with Postfix:


39a. - Quick notes on how to get started with Winlink and Winlink APRS messaging

Quick and dirty notes on getting started with Winlink:

  1. To create a Winlink account, you *MUST* interface to an existing RMS 
     station on the amateur bands (HF based WINMORE, Pactor, or a VHF/UHF
     packet connection to an RMS station.

        NOTE: APRS does not count and cannot create or renew an existing account

     Once you connect to a RMS Packet station, you are automatically 
     registered for 400 days. Just login once every 90 days to keep your 
     account active. 

       * If your account goes inactive after 400 days, any Winlink email to 
       * you will bounce. Just login again via RF as mentioned above to 
       * reactivate it.
       *  NOTE:  the use of the webmail system does NOT reset this timer.  Only 
       *         the use of an RF connection or Internet-based TELNET to a 
       *         CMS system will work

     For me, I connect to KE6AFE-10 via LPRC2 on 144.910 1200 BAUD packet.  
     You can find local stations to you via: 

        VHF : http://www.winlink.org/RMSPacketPositions
        HF  : http://www.winlink.org/RMSHFStatus
        APRS: see below

     Locating Winlink systems via APRS
     If you have an APRS setup, you can find the closest Winlink RMS server 
     to your current QTH, read your Winlink email via APRS messages, etc!

        Full details: http://www.winlink.org/aprslink

        To find the closest Winlink RMS stations:

            a. Send a standard APRS beacon to let the APRS world know
               your location

            b.  APRS TO : WLNK-1
                APRS MSG: G#

                Where # is the number of machines you want returned

  2. Connect to an active Winlink system:

      - To send an email to an Internet address from a RF-based Winlink

           sp smtp:<standard internet email address>

           Subject: <//wl2k [subject]>

           - The //wl2k prefix in the subject line is an anti-spam setting, 
             make sure it stays in there or incoming response email from the 
             Internet will be dropped

           - Mail to other Winlink users only needs a callsign - You 
             don't need to enter the smtp: or the @winlink.org 

39b. - Send a Winlink message via Internet email

      - Emailing a Winlink user from the Internet:
         All E-mail coming from the Internet to your Winlink account is 
         automatically blocklisted with a notice to you. To allow mail 
         to come through, first send a message from your Winlink account 
         to the address you wish to put on an allowlist. You can also sign up for 
         Webmail access by clicking the Webmail tab on http://www.winlink.org. 
         You can also control your allowlist from there. 

           - To: callsign@Winlink.org
             Subject: //wl2k <subject>

     - APRS:  To send messages via APRS
        - To send an email to an Internet from APRS Winlink

         Method #1 - Send a short message in a single APRS message to another Winlink user
            APRS TO: WLNK-1
            APRS MSG: SMS XX6YYY put your oneline mess here (replace XX6YYY with the callsign of the other user)
            <Send the msg>                            (maximum of 67 characters allowed)

         Method #2 - Send a short 1-liner message to an email address
            APRS TO: WLNK-1
            APRS MSG: SMS remoteaddr@someemail.org <here is a one line message>  (maximum of 67 characters allowed)

         Method #3 - Second an email via a multiple APRS messages
            APRS TO: WLNK-1
            APRS MSG: SP callsign@winlink.org <subject text is here>
            <Send the msg>

               write a second APRS message:
            APRS TO: WLNK-1
            APRS MSG: put the first line of email body here (maximum of 67 characters per msg)
            <Send the msg>

               write a second APRS message:
            APRS TO: WLNK-1
            APRS MSG: put the second line of message here (maximum of 67 characters per msg)
            <Send the msg>

            NOTE: you can get a "replay" of the current message in progress using the "playback" command:

               APRS TO : WLNK-1
               APRS MSG: P
               <Send the msg>

            Ok, write a third APRS message to finish it up:
            APRS TO: WLNK-1
            APRS MSG: put the last line here /EX           (maximum of 67 characters including /EX)
            <Send the msg>

       It's worth mentioning that like EMAIL-2, Winlink's APRSlink supports aliases or "shortcuts"
       for commonly used email addresses.  

            Add an alias:
              APRS TO: WLNK-1
              APRS MSG: A dude=remoteaddr@someemail.org
              <Send the msg>

            Use an alias:
            To send a message to that user, simply use the APRS body command: "SP dude"
            to use that alias instead of having to enter in the entire email address

              APRS TO: WLNK-1
              APRS MSG: SP dude <your message - one or more lines terminated with an /EX>
              <Send the msg>

            List all aliases:
            To list all aliases, simply do:

              APRS TO: WLNK-1
              APRS MSG: AL
              <Send the msg>

            Delete an alias:
            To delete an alias, simply do:

              APRS TO: WLNK-1
              APRS MSG: A dude=        <---- Notice nothing after the =
              <Send the msg>

39c. - Receive a Winlink message via APRS messages

     - APRS:  To get Winlink messages via APRS 

        1. you need to have sent at least one beacon packet out that includes your APRS rig type
           and location

        2. APRS destination: WLNK-1
           APRS Message    :

                             L - lists available messages
                             R# - read's a specific message ID
                             Y# - reply to a specific message
                             K# - kill a specific message
                             F# <remote email address>- forward a specific message

39d. - Advanced Winlink commands via APRS

Winlink supports other advanced commands via APRS.  Please see the following 
documentation for now:


40. - PAT - A Multi-protocol / Multi-platform Winlink client

Pat is both a GUI (presented as a web page as shown above) or CLI based Winlink 
messaging client.  It supports multiple ways to connect to remote Winlink systems be 
it native Linux AX.25, ARDOP, Winmor (via WINE), external hardware TNCs supporting 
Pactor or AX.25, and Internet based connections.   The program is multi-platform as 
it's written in the Go language (golang) which also supports Radio CAT control via 
Hamlib to QSY the radio to the ideal HAM band for the time of day.  You can learn 
more about PAT here:


40.a - Install Google Go

To get started, we first need to install the Go language.  Some versions are currently 
available for Centos6 or newer distros (Centos5 is specifically NOT supported) via the 
EPEL repo which was already enabled via a previous section in this document.  The version 
of "golang" for Centos6 in EPEL is currently at v1.9.4 as of 4/19/18 which is pretty up 
to date version.  This has not always been the case as just a few months ago, it was only 
at v1.6 which was already EOL!  If you want a bleeding edge version of Go (currently at
v1.10 as of 4/21/18), you can consider getting packages from:


This is not required for running PAT on Centos6 so let's get started!  Let's install Go 
from EPEL by running the command:

   sudo yum install golang golang-bin golang-src

Now in an unusual step for this doc, I recommend you TEST your Go installation via the official 
Go method because Go is a different kind of system:

   Run these commands in a shell window as a non-root user:

      #Create a download and build area in your current home directory
      export GOPATH=$HOME/work
      mkdir -p $GOPATH/src/github.com/user/hello

   Create the following simple "Hello World" Go program:
      vim $GOPATH/src/github.com/user/hello/hello.go
      package main

      import "fmt"

      func main() {
          fmt.Printf("hello, world\n")

   Ok, now compile your Go program:

      go install github.com/user/hello

   If all goes well, you'll just be dropped back to the command line without any
   output what so ever.  That resulting "hello, world" program is 2.35MB file.

Finally, run your new Go program:


   You should see:

      hello, world

40.b - Install Pat

   | WIP:  Not fully packaged yet but fully operational |

Ok, now to download the PAT source code and install Pat:

 Interm-testing (not packaged):

   #create the base environment - resulting directory will consume about 105MB
     export GOPATH=$HOME/work
     git clone https://github.com/la5nta/pat $GOPATH/src/github.com/la5nta/pat
     cd $GOPATH/src/github.com/la5nta/pat

   #Prepare the code and enable AX.25 support
     git submodule update --init --recursive
     go get -tags 'libax25 libhamlib' 

   #Finally, compile PAT
     TAGS="libax25 libhamlib" ./make.bash

   #That should have worked though it throws some warnings that are OK to ignore:
   WARNING: No static libax25 library available.
     Linking against shared library instead. To fix
     this issue, set CGO_LDFLAGS to the full path of
     libax25.a, or run 'make.bash libax25' to download
     and compile libax25-0.0.12-rc4 in .build/
   Updating git submodules...
   Running tests...
   ?       github.com/la5nta/pat   [no test files]
   ?       github.com/la5nta/pat/cfg       [no test files]
   ?       github.com/la5nta/pat/internal/cmsapi   [no test files]
   ?       github.com/la5nta/pat/internal/gpsd     [no test files]

   Building Pat v0.6.1...

WIP to package into an RPM:

   cd /usr/src/redhat/SOURCES
   # As of 4/21/18, Pat is at version 0.6.1
   wget https://github.com/la5nta/pat/archive/v0.6.1.tar.gz

   #Let's align the archive filename to be RPM packaging friendly
   mv v0.6.1.tar.gz pat-0.6.1.tar.gz

   #Now let's get a spec file to package Pat
   cd /usr/src/redhat/SPECS
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/pat.spec

TBD: Consider using https://github.com/seletskiy/go-makepkg in the future:

40.c - Configure Pat

Now we need to configure PAT with your specific details.  Run the following command:

   ./pat configure

   There are a few assumptions here in configuring PAT:

      1. You already have a Winlink account and password.  If you don't, please read 
         the intro to Winlink section in this doc of how to get started

      2. OPTIONAL: You already have AX.25 configured on your Linux system per this 
                   document.  You'll need to configure it to match your AX25 device
                   name as configured in /etc/ax25/axports

      3. OPTIONAL: You have ARDOP installed and running per the previous ARDOP section

   Edit the following entries to match your specific information ESPECIALLY your Winlink 
      "mycall": "KI6ZHD",
      "secure_login_password": "yourwinlinkpassword",

      "locator": "CM97ai",

      "ax25": {
        "port": "d710",

      "ardop": {
        "arq_bandwidth": {
          "Max": 2000
        "cwid_enabled": false

Thoughts on radio CAT control:
You can also configure PAT to support radio CAT control but I haven't documented here.  If
you want to enable this, you need to be VERY careful using automation with HF radios:

   - Unless you can completely automate the monitoring of incoming and outgoing sound card 
     levels AND radio RF levels, you can saturate the incoming signals to the point they
     cannot be decoded.  Worse, you can create a high ALC situation on transmit which would
     make your signal distorted and splatter all over the band

   - Unless you have low SWR on your antenna for any intended frequencies, you could damage 
     your radio

   - Unless your antenna tuner can match all intended frequencies, you can create a high 
     SWR situation and possibly damage your radio

   - Unless you're careful with your radio's RF power, overly long transmissions can overheat 
     and damage your radio (an FT950 should not use more than 50% of it's max power - 50 watts)

   - With PAT v0.6.1, it only supports frequency control.  It doesn't support changing other
     key parameters to ensure you're 100% ready to go such as mode (USB), antenna tune, etc

40.d - Operate PAT via CLI using the Internet

Once you save the file, that's it and you should be ready to run PAT. To get started, 
let's give it a test over the Internet.  To do so, run the following command and you
should see something like the following

   ./pat connect telnet
   2018/04/21 10:07:47 Connecting to WL2K (telnet)...
   2018/04/21 10:07:47 Connected to (tcp)
   ;PQ: 40312364
   ;PM: KI6ZHD UMIDPSMT62YL 111 KI6ZHD@winlink.org Test #2
   FC EM UMIDPSMT62YL 129 111 0
   F> 59
   1 proposal(s) received
   Accepting UMIDPSMT62YL
   Receiving [Test #2] [offset 0]
   Test #2: 100%
   2018/04/21 10:07:48 Disconnected.

Success!  You just made a successful connection to the Internet-facing Winlink system.  To
read a message, you would do:

   ./pat read
   0:in    1:out   2:sent  3:archive
   Choose mailbox [n]: 0

Here you have a choice of what folder to enter.  I'm typing in "0" to vierw the INbox.  I
then see:
   -----  -------  -----------------------------------------------------------  --------  -------------------------------  -------------
     i     Flags     Subject                                                      From      Date                             To
   -----  -------  -----------------------------------------------------------  --------  -------------------------------  -------------
     0               //WL2K Thank you for checking in to the NORCAL_WINLINKnet    KF6OBI    2018-04-18 17:48:00 -0700 PDT    KI6ZHD
     1               //WL2K NORCAL_WINLINKnet Weekly report                       KF6OBI    2018-04-20 07:18:00 -0700 PDT    KE6AFE, ...
     2      N        Test #2                                                      KI6ZHD    2018-04-20 21:14:00 -0700 PDT    KI6ZHD
   -----  -------  -----------------------------------------------------------  --------  -------------------------------  -------------

I then want to read message #2 as it's the new message mentioned above:
   Choose message [n]: 2
   Date: 2018-04-20 21:14:00 -0700 PDT
   From: KI6ZHD
   To: KI6ZHD
   Subject: Test #2

   This is test #2



At this point, you've read the message and PAT will prompt you want to do next.  This could be
to  mark the message as READ or reply to it:

   Mark as read? [Y/n]:
   Reply (ctrl+c to quit) [y/N]:

   | NOTE:  As of PAT v0.6.1, there is no way to delete messages via the simple CLI but you    |
   |        can delete them via the HTTP/web interface (more on that in a moment).  Until      |
   |       then, you can manually delete messages like this (make the required substitutions): |
   |                                                                                           |
   |       ls -la $HOME/.wl2k/mailbox/KI6ZHD/in/                                               |
   |       --                                                                                  |
   |       total 24                                                                            |
   |       drwxrwxr-x 2 dranch dranch 4096 Apr 21 10:07 .                                      |
   |       drwxrwxr-x 6 dranch dranch 4096 Apr 19 22:01 ..                                     |
   |       -rw-rw-r-- 1 dranch dranch 5516 Apr 20 15:47 74OCM2JGFDEC.b2f                       |
   |       -rw-rw-r-- 1 dranch dranch  427 Apr 20 15:42 S8376TPX0OWJ.b2f                       |
   |       -rw-rw-r-- 1 dranch dranch  196 Apr 21 10:10 UMIDPSMT62YL.b2f                       |
   |       --                                                                                  |
   |                                                                                           |
   |       As you can see in the original reading of message #2, it had an identifier of       |
   |       "UMIDPSMT62YL" and it's right there in this directly listing.  To remove the        |
   |       message, I would simply do:                                                         |
   |                                                                                           |
   |          rm $HOME/.wl2k/mailbox/KI6ZHD/in/UMIDPSMT62YL.b2f                                | 

   To exit PAT, you would just keep hitting enter to accept the default prompts:
   Choose message [n]:
   0:in    1:out   2:sent  3:archive
   Choose mailbox [n]:

Sending messages is basically the same thing as reading them.  Here, I'm sending another message 
to myself:

   ./pat compose
   From [KI6ZHD]:
   To: KI6ZHD
   P2P only [y/N]: N
   Subject: Test #3
   Press ENTER to start composing the message body.
      [default editor opens up (vim in my case)] to let you write your message.  Edit the editor when done]

   Attachment [empty when done]:
   Date: 2018-04-21 10:30:00 -0700 PDT
   From: KI6ZHD
   To: KI6ZHD
   Subject: Test #3

   this is test #3


   Message posted

Ok, all done.. but it didn't send it.  That's because PAT is a bulk transfer tool.  You can write a whole
bunch of messages offline and then send them all at once.  To send you message, you'd do another CONNECT
just like what you did at the beginning of this section:

   ./pat connect telnet

40.e - Operate Pat CLI with AX25 Packet

We now have a working PAT setup using the Internet but that's probably NOT what you really
intended to to do.  I bet you want to use it over the radio be it AX.25 packet, ARDOP, etc.  
Let's try via Linux's native AX25 support.  

   NOTE: This section assumes you have a fully operational AX25 setup per the previous
         sections in this document

Ok, assuming your packet setup is ready and working, let's see what packet stations are around 
you.  A slick way to find out is to use grid squares.  Per my configuration, I'm in the CM97 grid square.   
I can use PAT to show me who is near me.  This is NOT a perfect way to do it considering the various elements 
such as local digipeaters, topography, propagation, time of day, etc but you can make things as loose or
tight as you wish.  I'm matching on packet stations only near "CM97":

   ./pat rmslist | grep -i "\[CM97" | grep -i packet
   K2RDX-10  [CM97AH] 5      180 Packet 1200     145.630.00 MHz 145.630.00 MHz packet:///K2RDX-10?freq=145630
   K6IXA-10  [CM97QI] 118     90 Packet 1200     144.910.00 MHz 144.910.00 MHz packet:///K6IXA-10?freq=144910
   K6IXA-10  [CM97QI] 118     90 Packet 9600     433.510.00 MHz 433.510.00 MHz packet:///K6IXA-10?freq=433510
   KE6AFE-10 [CM97CC] 31     152 Packet 1200     145.630.00 MHz 145.630.00 MHz packet:///KE6AFE-10?freq=145630
   KF6IDK-10 [CM97SH] 133     92 Packet 1200     144.910.00 MHz 144.910.00 MHz packet:///KF6IDK-10?freq=144910
   W6TUW-10  [CM97AA] 37     180 Packet 1200     144.910.00 MHz 144.910.00 MHz packet:///W6TUW-10?freq=144910

K2RDX-10 is right near me so I QSY my FM radio to 145.630Mhz and issue the following command using my "d710" 
interface as defined in /etc/ax25/axports:

   ./pat connect ax25://d710/K2RDX-10
   2018/04/21 10:56:53 Connecting to K2RDX-10 (ax25)...
   2018/04/21 10:56:54 Connected to K2RDX-10 (AX.25)
   ;PQ: 96625531
   CMS via K2RDX >
   2018/04/21 10:56:58 Disconnected.

Cool.. it just works and now you can read your messages offline as previously shown in this

40.f - Operate Pat CLI with ARDOP

We now have a working PAT setup using the Internet but that's probably NOT what you want to do.
You probably want to use it over the radio be it AX.25 packet, ARDOP, etc.  Let's try ARDOP

To get started, make sure the ARDOP modem is running per the previous program using:


Assuming your HF radio is on, tuned to the right frequency, matched for your antenna, has
the right soundcard and RF power levels for zero ALC, you should be ready!  The next question
is WHO do you try connecting to.  A slick way to find out is to use grid squares.  Per my
configuration, I'm in the CM97 grid square.   I can use PAT to show me who is near me.  This
is NOT a perfect way to do it considering the various elements of propagation, time of day, etc
so I intentionally keep the search to be a little broad.  I'm matching only on "CM9":

   ./pat rmslist | grep -i "\[CM9" | grep ardop
   K2RDX     [CM97AH] 5      180 ARDOP 500         7.095.00 MHz   7.096.50 MHz ardop:///K2RDX?freq=7095
   K2RDX     [CM97AH] 5      180 ARDOP 2000        7.101.00 MHz   7.102.50 MHz ardop:///K2RDX?freq=7101
   K2RDX     [CM97AH] 5      180 ARDOP 2000       10.145.50 MHz  10.147.00 MHz ardop:///K2RDX?freq=10145.5
   K2RDX     [CM97AH] 5      180 ARDOP 2000       14.106.00 MHz  14.107.50 MHz ardop:///K2RDX?freq=14106

Cool!  There is a station right next to me.. John K2RDX's station.  I'm going to connect 
to one of his 40m stations so I QSY my radio to 7.101Mhz USB DIAL which is effectively 7.1025Mhz in RF
spectrum and give it a try:

   | NOTE:  The use of PAT can work while ARIM is running but not |
   |        connected or beaconing                                |

Ok, let's give it a try.  Looking above, PAT has shown us the syntax how to connect to the listed
stations so I would simply do:

   ./pat connect ardop:///K2RDX
   2018/04/21 10:51:18 ARDOP TNC (ARDOP TNC_1.0.2.5l-BPQ) initialized
   2018/04/21 10:51:18 Connecting to K2RDX (ardop)...
   2018/04/21 10:51:26 Connected to K2RDX (ardop)
   RMS Trimode
   KI6ZHD has 112 minutes remaining with K2RDX
   {SFI = 073 on 2018-04-21 16:00 UTC}
   ;PQ: 47077525
   CMS via K2RDX >
   ;PM: KI6ZHD KXKTW2HJKVYA 112 KI6ZHD@winlink.org Test #3
   FC EM KXKTW2HJKVYA 129 112 0
   F> 40
   1 proposal(s) received
   Accepting KXKTW2HJKVYA
   Receiving [Test #3] [offset 0]
   Test #3: 100%
   2018/04/21 10:53:31 Disconnected.

Cool.. it just works and now you can read your messages offline as previously shown in this

Btw, PAT can do a lot of other things.  To get a hint of what else the CLI offers, simply run:

   Pat is a client for the Winlink 2000 Network.

     ./pat [options] command [arguments]

     connect         Connect to a remote station.
     interactive     Run interactive mode.
     http            Run http server for web UI.
     compose         Compose a new message.
     read            Read messages.
     position        Post a position report (GPSd or manual entry).
     extract         Extract attachments from a message file.
     rmslist         Print/search in list of RMS nodes.
     riglist         Print/search a list of rigcontrol supported transceivers.
     configure       Open configuration file for editing.
     version         Print the application version
     help            Print detailed help for a given command.

         --config string      Path to config file (default "/home/dranch/.wl2k/config.json")
         --event-log string   Path to event log file. (default "/home/dranch/.wl2k/eventlog.json")
         --ignore-busy        Don't wait for clear channel before connecting to a node.
     -l, --listen string      Comma-separated list of methods to listen on (e.g. winmor,ardop,telnet,ax25).
         --log string         Path to log file. The file is truncated on each startup. (default "/home/dranch/.wl2k/pat.log")
         --mbox string        Path to mailbox directory (default "/home/dranch/.wl2k/mailbox")
         --mycall string      Your callsign (winlink user).
         --radio-only         Radio Only mode (Winlink Hybrid RMS only).
     -r, --robust             Use robust modes only. (Useful to improve s/n-ratio at remote winmor station)
    -s, --send-only          Download inbound messages later, send only.

This is kinda fun to post my position in Decimal degrees:

   ./pat position --latlon 37.3435,-121.9999
   Message posted
   #Now send the position report via say ARDOP:
   ./pat connect ardop:///K2RDX

   # You can view your position reports via an Internet web browser at:

40.g - Operate Pat via the web based GUI

Some people prefer CLIs (like me) but many people prefer GUIs and this is where PAT shines.
It supports BOTH.  To use PAT's gui, you simply start it's web interface at a terminal prompt:

   ./pat http
   2018/04/21 11:12:40 Starting HTTP service (localhost:8080)..

Now, now on the same computer, open up a web browser and point it to the URL:

Go ahead and play with the web interface but basically everything you've done here
in the CLI is applied to the GUI.  Enjoy!

41. - Gpredict - Satellite tracking, prediction and graphical mapping tools

Gpredict is a very modern, pretty, and easy to use satellite orbit prediction tool 
for Linux.  It even supports AzEl rotator control and Doppler shift controls for Yaesu 
FT817-857/897 radios.

To install it, download the RPM from the FedoraCore repo: NOTE: ----- Centos6: The only version of Gpredict that is compatible with Centos6 is version 1.3. Later version of Gpredict 1.4git require glib 2.32 for g_mutex support but Centos6 only has glib2.28. I've confirmed this is a REQUIREMENT for all newer versions of Gpredict TBD: Centos6 I'm going to try bulding a 1.4Git version from the last version that didn't require the g_mutex call: commit ce3651e029e5f481f51bc1864ceae1bad427e5a6 Author: Alexandru Csete Date: Thu Jul 4 13:58:29 2013 +0200 Replace obsolete GStaticMutex with static GMutex. I'll report later on my findings Centos5: the only version of Gpredict that is compatible with Centos5 is version 0.9. The much more modern Gpredict 1.3 and 1.2 are *not* compatible with Centos5 due to wanting much newer versions of various libraries such as: -- wants 'gtk+-2.18.0' but Centos5 will only have 2.10 wants 'glib-2.22.0' but Centos5 only has GLib 2.12.3 wants 'gthread-2.22.0' but Centos5 only has GThread 2.12.3 wants 'libcurl >= 7.19.0' but Centos5 only has libcurl 7.15.5 goocanvas requires gtk2-devel-2.12 but Centos5 only supports 2.10 -- If you want to install Gpredict v0.9 for Centos5, skip down to that section below TBD: Centos6 I'm going to try bulding a 1.4Git version from the last version that -------- Centos6: -------- #First, some dependencies: yum install goocanvas goocanvas-devel #Ok, lets get Gpredict and install it cd /usr/src/redhat/SOURCES # For reference to get newer versions # http://koji.fedoraproject.org/koji/packageinfo?packageID=1958 wget http://kojipkgs.fedoraproject.org//packages/gpredict/1.3/7.fc19/src/gpredict-1.3-7.fc19.src.rpm #Ok, let's compile it: cd /usr/src/redhat/SPECS #For 64bit systems rpmbuild -bb --target=x86_64 gpredict.spec rpm -Uvh /usr/src/redhat/RPMS/x86_64/gpredict-1.3-7.el6.x86_64.rpm # Skip past, the Centos5 compile section on how to get started -------- Centos5: -------- cd /usr/src/redhat/SOURCES # For reference to get newer versions # http://koji.fedoraproject.org/koji/packageinfo?packageID=1958 wget http://kojipkgs.fedoraproject.org/packages/gpredict/0.9.0/5.el6/src/gpredict-0.9.0-5.el6.src.rpm One thing I've been noticing with various new RPMs is that if you try to install the SRPM, you'll get errors like: error: unpacking of archive failed on file /usr/src/redhat/SOURCES/gpredict-0.9.tar.gz;4e5483f3: cpio: MD5 sum mismatch It seems this is a specific issue to RPM but we can still fix this: rpm2cpio gpredict-0.9.0-5.el6.src.rpm | cpio -imud *.spec mv gpredict.spec /usr/src/redhat/SPECS rpm2cpio gpredict-0.9.0-5.el6.src.rpm | cpio -imud *.gz mv gpredict-0.9.tar.gz /usr/src/redhat/SOURCES cd /usr/src/redhat/SPECS vim gpredict.spec -- Change the line "%configure" to "%configure --enable-coverage" -- One more prerequsite: yum install intltool Ok, let's compile it: cd /usr/src/redhat/SPECS rpmbuild -bb --target=i686 gpredict.spec rpm -Uvh /usr/src/redhat/RPMS/i686/gpredict-0.9.0-5.i686.rpm Getting Started --------------- Ok, so you've installed Gpredict and now let's use it a bit: - Start up gpredict by simply running the following command at the command line: gpredict - When the main window opens up, do the following to get the newest satellite data: Edit -> Update TLE -> From Network - Enter in your home QTH by doing: yy Edit -> Preferences -> General -> Ground Stations -> Add New For me, I added in: Name: Home Description: KI6ZHD Home QTH Location: [Select the city of the closet airport to your QTH] For me, I picked San Jose, CA Lat / Long: If you wish, enter in your exact location 37.3435 North / 121.9999 West as discussed and found in the Xastir section above Click on OK Click on Default to make this new entry your default location - Change some of the views to be more easy for the newbies: Edit -> Preferences -> Modules -> List Views Check-mark: Visibility Next AOS - Ok, now what you really need now is a way to find out what satellites are active but this doesn't seem to be very easy or reliable. From what I can tell, http://oscar.dcarr.org/ is a good start. From that listing, goto File -> New Module and create a new module. module name: home Ground Station: home Now using the Group "All Satellites", do searches for all of the sats shown in the above URL and click on the right arrow button to add them. Click on OK when done.

42. - Software Defined Radio (SDR)

Software Define Radios or SDRs are the newest major innovation to come to 
radio (analog and all types of radios) in a very long time.  Classic radios that 
use analog circuits to create super heterodyne radios (local oscillators, mixers, 
filters, detectors, etc.) to de/modulate the signals have inherent imperfections,
variance, etc that hurt their performance.  An SDR is a completely different 
type of radio where it uses direct conversion to take the DIRECT antenna input signal, 
pre-amplify the broadband signal and then digitize it with very fast, broad 
banded analog to digital converters (DACs).  At this point, all filtering, 
processing, and demodulation is done using complex math in the computer itself.
The result is a far more powerful radio system with almost none of the limitations 
and variances found in real analog hardware.

This section is broken into a few pieces:

  Section A - A quick intro to various SDR hardware (many are just receivers)
              and how they compare

  Section B - Quick is a simpler but powerful python based program for IQ-based 
              SDRs like SoftRock, etc.

  Section C - GnuRadio is more of a framework for many other SDR programs out
              there.  This suite of software allows you to easily write 
              new modulation schemes, etc. all without a soldering iron!

  Section D - LinRad is a very powerful SDR applications for Linux based on

If you're looking for some hardware recommendations, skip down to the 
"SDR Receivers - Supporting applications for the RTL2838, Airspy, and SDR-Play SDR devices"
section for a lot of details

42a. - Picking SDR Hardware - Quick overview of RTL, Airspy, SDRPlay, BladeRF, LimeSDR, etc

Ok, GnuRadio is installed (finally) but now lets talk about hardware.  For my uses, 
I initially wanted to use it with one of these inexpensive RTL for $18 just to try 
them out as I've heard so much about them.  A few notes on some of these units:

This is the NooElec NESDR SDR dongle with the R820T2 + TXCO tuner
  RTL2832 + R820T2: The third generation USB-tuner devices now available have the
                    newest Raphael Micro R820T2 chip and some of the better designs 
                    from say NooElec use highly stable TCXO oscillators.  The combination
                    of these two offer even better sensitivity and improved 
                    25MHz-1750MHz frequency coverage.

  RTL2832 + R820T : The second generation USB-tuner devices have the Raphael Micro 
                    R820T chip is evidently a bit more sensitive, and support an
                    effective lower frequency spectrum of 24-1700 Mhz.  The 
                    official range is 42 to 1002 Mhz with a 3.5 dB noise figure. 
                    One nice aspect of these new tuners is that they don't have 
                    the traditional DC "carrier" at the center of the FFT like 
                    the E4000 units but they have more image aliasing (faint 
                    mirror images of strong signals on either side of the 0hz 
                    center point.  These devices are also a bit cheaper too.

This is the Terratec Tstick+ RTL dongle with the E4000 tuner
  RTL2832 + E4000 : The first generation units used the Elonics E4000 tuner.  
                    They could receive a slightly higher frequency range between 
                    54-2200 MHz with a coverage gap between 1100-1250 MHz.  Like 
                    most classic I/Q devices (non-direct sampling) like the SoftRock 
                    units, there is a DC "carrier" at the center of the FFT due 
                    to common I/Q imbalances.  The Elonics company is no more 
                    so these specific E4000 enabled units are getting harder to find 
                    on say Ebay, etc. but they are still available.

There is a very nice intro write-up here about the older generation RTL units:


If some of you might be looking to use an RTL device for HF frequencies (0-54Mhz), 
you might want to check out this comparison page:


You might also want to consider some of the higher end devices mentioned below
which include HF natively.

One note about Centos and RTL devices:
The specific E4000 based unit I bought is "newer" and they are only recognized in 
3.7.0 or newer kernels.  Putting that another way, the stock Centos6/5 kernels
will not recognize it.  I'm running the modified ElRepo "ml" kernel as described 
in the kernel section of this document DOES support it so upgrading your kernel
is required.  It's possible to get the card to be recognized with a stock kernel 
but I don't think it would be worth the effort and as such, I recommend all users 
to use the ElRepo kernels.  Beyond the kernel driver support, there is still more 
base software that's needed to get things operational.

Beyond the VHF/UHF RTL dongles:
One of the challenges with the RTL dongles is that they don't have any front-end 
or "pre-selector" filters.  What this means is that if you have very strong signals
nearby on almost any frequency, they will seriously desense the RTL's receiver.
This greatly impacts what the RTL dongles can hear, creates spurs/birdies in 
the frequencies you want to hear, etc.  The proper fix for this is filters 
on the front end.  

I've recently been recently been researching this topic and there are three 
Linux friendly devices that take things up a notch:

This is the Airspy v2 dongle supporting a full 10Mhz / 10MSPS bandwidth at 12bits
   - AirSpy r2 - $199 or $249 with upconverter option 
               - 10Mhz wide passband 
                 (requires a fast computer and solid USB performance, also supports 2.4Mhz wide)
                 - Stock ElRepo 3.17.5 kernel kernel on an Intel i5-2340 @ 2.4Ghz cannot keep up @ 10Msps
               - native 24Mhz to 1.7Ghz 
                 DC to 24Mhz frequencies supported via tightly integrated Spyverter upconverter option
               - Has RX pass band filters to protect the frontend (important)
               - 12bit resolution 
               - Direct Sampling receiver so the center DC spike is gone
                 I didn't realize how nice it is to have that gone!
               - Uses the R820T2 tuner receiver
               - Receive only
               - Encased in quality metal enclosure to shield out hearing near-field birdies, etc
               - OpenSource drivers easily compiled and supported by GnuRadio
               - USB2 based
               - Preferred SDR program is SDR# but supports many others (including Gqrx)
               - USB2.0

   - AirSpy r1 - No longer made
               - 10Mhz bandwidth
               - Supports 24Mhz to 1.8Ghz 
               - 8bit resolution
               - Uses the R820T2 tuner receiver
               - USB2 based

This is the SDR Play dongle supporting a full 8Mhz / 8MSPS bandwidth at 12bits
   - SDR-Play - $150 as of 1/2016
              - 8Mhz bandwidth 
	        (requires a fast computer and solid USB performance)
              - Supports 100Khz to 2Ghz (recently added via new drivers)
                (original APIs blocked reception of 380-420Mhz)
              - Has 8 different RX pre-selector filters that can be enabled/disabled
              - 12bit resolution 
              - Direct Sampling receiver so the center DC spike is gone
                (I realize how nice it is to have that gone!)
              - Receive only
              - Encased in plastic enclosure 
                (unclear if this not enough to shield out hearing near-field birdies, etc)
                One local user installed copper tape on the inside of his unit to help 
                here but I don't know how effective that is
              ! CLOSED source Mirics drivers which limits support - currently has drivers 
                for Windows, some Linux, some OSX 
                 | SHOW-STOPPER: 2/6/16                                             |
                 | Current binary APIs are compiled against Glibc 2.14 but Centos6  |
                 | ships with Glibc 2.12.  I've reached out to SDRPlay to see if    |
                 | they will release a new binary API version but they politely     |
                 | declined saying there wasn't enough market to support a Centos6  |
                 | driver effort.  I have since purchased an AirSpy v2 unit where   |
                 | everything is open source and it's been working very well.       |
                 |                                                                  |
                 | Update: 01/25/17                                                 |
                 | There is hope via the 3rd party library effort but it's unclear  |
                 | how well it works or matches the closed source Mirics library    |
                 | https://github.com/f4exb/libmirisdr-4                            |
              - Preferred SDR program is CubicSDR but supports many others (including Gqrx)
              - USB 2.0
This is the Funcube Dongle+ supporting 192Khz
   - Funcube Pro+ - $186
                  - 192Khz passband bandwidth
                  - 64Mhz to 1.7Ghz
                  - Has RX filters that can be enabled/disabled
                  - 16bit resolution
                  - Uses the previous Mirics chipset and closed source middleware API
                  - USB1.1 based
                  - Though considered one of the first quality SDRs, it's specs are now quite low
                    in comparison to it's newer competitors

This is the LimeSDR 61MSPS bandwidth at 12bits

   - LimeSDR   - $289
               - 100 kHz - 3.8 GHz
               - 61.44 MHz maximum bandwidth at 12bit
               - 6 RX antenna jacks, 4 TX antenna jacks (2x2 MIMO)
               - full duplex @ 0 to 10dBm power
               - Altera Cyclone IV EP4CE40F23 FPGA
               - USB 3.0
               - Scroll down on the above LimeSDR page to see a comparison table against
                 the HackRF, Ettus B200, B210, BladeRF x40, and an RTL dongle
               - Very comparable to the Ettus B210 but over 50% cheaper

This is the HackRF device supporting a full 20Mhz / 20MSPS bandwidth at 8bits

   - HackRF    - $300
               - 20Mhz wide passband 
                 (requires an extremely fast computer and very fast USB performance)
               - 10Mhz to 6Ghz support
               - NO RX pass band filters to protect the frontend (this is important)
               - 8bit sampling 
                 (sampling rates really matter depending if you just want a panadapter vs. a proper receiver)
               - I/Q Sampling receiver so it has the center DC spike
               - Receive and 10mw Transmit section 
                 (half duplex; no duplexer included; dedicated TX connector)
                 Seems like TX support isn't supported by many programs today; few amplification stages exist
               - Encased in plastic enclosure - unclear if this not enough to shield out hearing near-field birdies, etc
               - OpenSource drivers easily compiled and supported by GnuRadio
               - No real preferred SDR program but is supported many others (including Gqrx)
               - USB2.0

   - HackRF Blue - A lower cost version of the original HackRF but currently no 
                   longer in stock

This is the BladeRF x40 40MSPS bandwidth at 12bits

   - BladeRF   - $420 (x40 model) or $650 (x115 model)
               - Very wide performance (can display 124Mhz wide waterfall in Gqrx)
               - 300MHz - 3.8GHz support
               - Independent 12-bit 40MSPS RX and TX using LimeMicro LMS6002D transceiver
               - Receive and 10mw Transmit section 
                 full duplex up to 28Mhz BW; no duplexer included; 
               - 2x2 MIMO Wifi configurable with SMB cable, expandable up to 4x4
                 Seems like TX support isn't supported by many programs today; few amplification stages exist
               - All sources are open source and easily compiled
               - On-board Altera Cyclone 40KLE or 115KLE (upgraded model) FPGA
               - On-board Cypress FX3 200MHz ARM9 with 512KB embedded SRAM for USB3 control
               - USB3.0 (5Gbps) based interface with USB2.0 compatibility
               - Optional XB200 transverter board for passband filtering at HF, 50MHz, 144MHz, and 222MHz
               - Optional XB300 Diversity RX + LNA + 33dBm (2.0watt) amplifier + TRX switch @ 2.4ghz
                   - NO TX filtering is offered in this board - BEWARE
               - Various add on boards, cases, antennas, etc available

This is the Ettus Research B200 bandwidth at 12bits

   - Ettus B200 / B210 - $675 single transceiver SDR unit
                - 70 MHz to 6 GHz
                - 56 MHz bandwidth
                - Has 10mw half-duplex transmit support on a dedicated transmit connector
                - Onboard Xilinx Spartan-6 XC6SLX75 FPGA
                - Many different add-on boards are available
                - All sources are open source and easily compiled
                - USB3 based
                - Considered one of the best SDRs out there for the cost; early contributor to GnuRadio

There are so many other SDR boards out there now that it's becoming a bit crazy:


      - rtl-sdr.com's R820T2 + RTL2832U with TXCO and BiasT support - $25

      - Outernet E4000 based SDR with TCXO : $39 - https://outernet.is/

      - FlightAware Pro Stick w/ 20db LNA specialized for 1090Mhz using R820T2 and RTL2832U chips : $17

        [ Many others in this field too - email me if you have a favorite not listed here ]

   Medium End:

      - FreeSRP : $350 - http://electronics.kitchen/freesrp

      - Red Pitaya : 199 Euro - http://redpitaya.com/

        [ Many others in this field too - email me if you have a favorite not listed here ]

Each of these units have their pros and cons.  Depending on your requirements, the edge currently 
goes with the SDR-Play unit for price vs. performance.  Unfortunately, the closed source drivers
in the SDR-Play unit block it's use with Centos6.  As such, I'm moving forward with the AirSpy R2.

42b. - Quisk - Software Defined Radio (SDR) receiver

| This section is a work in progress  |
|   - It works as described but isn't |
|     packaged just yet               |

Quisk is a Python based application that fully supports classic soundcard based IQ 
SDRs like the SoftRock series.  IQ based SDRs split a given signal into two 
mirror pieces: one signal at a 0 degree phase angle and another at 180 degree 
phase angle.   This is called I-Q signals.  At that point, the waveforms go 
into a wide sampling sound card using the left and right microphone channels 
and all de/modulation, etc. occurs PURELY in computer software!

Though inexpensive, I/Q based SDR's bandwidth are limited to the sampling rate
of the used soundcard.  Most soundcards support either 44.1 or 48Khz.  Some
better cards support 96Khz and and a fewer number of cards support 192Khz.
In comparison, some of the inexpensive RTL dongles can support 2.5MHZ (that's
52x more than a soundcard SDR running at 48Khz)!  The nicer SDRs like the
Airspy unit can do a full 10Mhz of simultaneous spectrum!

Regardless, soundcard SDRs are still very powerful, inexpensive, and make
great hobby kits.

This is the main window that shows the maximum bandwidth being captured:

There are several Linux-based SDR programs out there:

  Quisk  - What we are going to install in this section  (shown above)

  LinRad, Gqrx, etc.

Though minimal, there is still some hardware.  There are simple kits
like the WB5RVZ "SoftRock" units that use a common soundcard all the way up to
full complete units like a SDR-IQ, Persius, Flex Radio, etc.

For this section, I'm using the SoftRock Lite II receive-only module.  Building
up that board is well out of the scope of this document but it's not a overly
complicated board to build though there is some surface-mount devices (three 
chips, ~8 caps) and you have to wire two toroids.

Back on topics, let's get started:

  - Dependencies: 
    Here are the code dependencies to get Quisk compiled and going though I'm omitting
    other programs that were previously installed with other programs as described in
    this doc.  Please see the Quisk documentation for learning
    more of the dependencies if you're installing this out of order from the rest
    of the Hampacket documentation.

      #Graphical UI modules (these will come from EPEL)
      yum install wxPython wxGTK wxBase wxGTK-gl wxGTK-media

         # Other known dependencies that are needed but are filled in previous 
         # sections include:
         #    python-devel fftw fftw-devel alsa-lib-devel portaudio portaudio-devel
         #          ^       ^       ^            ^            ^             ^
         #        base     base    base         base        epel           epel

  - Next, download Quisk
    cd /usr/local/redhat/SOURCES
    wget -O quisk-3.6.12.tar.gz http://james.ahlstrom.name/quisk/quisk-3.6.12.tar.gz

Test stages (will wrap into an RPM later):

  - SoftRock specific : Copy over a configuration file for the SoftRock board
    cp quisk_hardware_fixed.py $HOME/.quisk_conf.py

  - Copy in the defaults as well
    cat quisk_conf_defaults.py >> $HOME/.quisk_conf.py

  # Show which devices are available to do recording
  #  This stage isn't 100% reliable for me so you'll have to play with it but..
     1. Run the python script that comes with Quisk to help identify the card

            #Important: run as root
            "python portaudio.py"

     2. Alternatively, you can do it manually using the following commands:

         cat /proc/asound/cards
         cat /proc/asound/devices

     Here, match up the card to the text "digital audio capture".  

     3. Set the recording sampling rate to match your soundcard.  Most basic sound
        cards will either support 44100 and usually 48000.  More advanced cards might
        offer 96000 or 192000.  To see what your card can support, run:

           #this program comes from the alsa-utils package
           alsa-info --stdout | grep -A 12 "Audio Input"

        Alternatively, if you cannot find alsa-info, you can try this approach:

           #Originally from From https://lacocina.nl/detect-alsa-output-capabilities
           bash <(wget -q -O - "https://raw.githubusercontent.com/ronalde/mpd-configure/master/alsa-capabilities") -l usb -s 

           0) USB Audio Class Digital alsa audio output interface `hw:1,0'
           - device name       = C-Media USB Audio Device
           - interface name    = USB Audio
           - usb audio class   = 1 - isochronous adaptive
           - character device  = /dev/snd/pcmC1D0p
           - rates per format  = S16_LE:              48000Hz 44100Hz  <--------------------------------------
           - monitor file      = /proc/asound/card1/pcm0p/sub0/hw_params
           - stream file       = /proc/asound/card1/stream0

        In the $HOME/.quisk_conf.py, set the proper value but start LOW to begin with:

         sample_rate = 48000
     4. Set the sound card capture:  For me, I edited the "else" stanza of the
        $HOME/.quisk_conf.py file under the line "if sys.platform == "win32":"

         name_of_sound_capt = "portaudio#0"

     5. Unset the sound card playback:  Since I have a softrock, I disabled
        this feature by finding the file and put a # in front:

        #name_of_sound_play = name_of_sound_capt

     6. For a 20m softrock, change the fixed center VFO frequency

        fixed_vfo_freq = 14046000


  Other Recommended changes to the quisk_conf.py file

  default_screen = 'WFall'

More to come here...

42c. - GnuRadio - The gold standard for Software Defined Radio software

GnuRadio is considered the primary foundation for many of the SDR applications out 
there for Linux and other platforms.  It's intended to be a framework to allow users
to develop their own modulations, etc.  GnuRadio is required by many other SDR applications
as well a strong foundation piece for HAMs to create their own modulation types.  As such,
we need to get it installed first.

  NOTE:  This is a fairly complex set of steps to get all the required dependencies
         in place.  Even with them in place, compiling GnuRadio takes a long time
         even on the fastest machines so patience is required.

42c1. - GnuRadio Dependencies: installing the required sub-applications

Ok, lets' start with the various dependencies:

  #Note: Being a late addition to this documentation, many of these RPMs were already
  #      installed from other sections.  If you've jumped to this section and are 
  #      having difficultly installing RPMs, make sure that you followed the "3rd 
  #      party REPO" section and possibly searched this entire document on how I
  #      built some of these RPMs if they aren't available in those REPOs
  yum install fftw-devel cppunit-devel wxPython-devel libusb-devel \
  guile guile-devel alsa-lib-devel numpy gsl-devel python-devel \
  python-cheetah python-lxml 

  # Next, we need a newer version of Boost than what's available in the standard Yum
  #  Repos to compile gr-osmosdr and it seems the stock available version is 
  #  is broken boost-devel-1.41.0-18.el6.x86_64 for older versions of Cmake.  Sheesh!
  #  According to this URL: 
  #  http://gnuradio.4.n7.nabble.com/Fwd-Building-rtl-sdr-gr-osmosdr-build-apparently-failed-Ubuntu-11-10-td40631.html
  #  versions 1.46, 1.46.1, 1.47 and 1.52 are bad!
  #  Let's replace it with something modern:
  #    From http://koji.fedoraproject.org/koji/packageinfo?packageID=1074
  #   Download a more modern version of the code (yes, 1.55 is available but I'm not too concerned)
  cd /usr/src/redhat/SRPMS
  wget http://kojipkgs.fedoraproject.org//packages/boost/1.54.0/8.fc21/src/boost-1.54.0-8.fc21.src.rpm
  rpm -Uvh boost-1.54.0-8.fc21.src.rpm

  # Now lets build it but we need to disable a few things to make sure it builds
  #   NOTE: this takes 34min to build on my dual core i5 2430M @ 2.4GHz with
  #         4GB of RAM and a 5400RPM HD.  
  #  Do NOT run this build command as root
  time rpmbuild -bb --target=x86_64 boost.spec --without python3 --without mpich --without openmpi

  #Finally, let's install them
  #  Do this as ROOT
  #    NOTE: There were conflicts installing these new packages with:
  #              libboost_filesystem.so.5()(64bit) is needed by (installed) qpid-cpp-client-0.14-22.el6_3.x86_64
  #              libboost_filesystem.so.5()(64bit) is needed by (installed) qpid-cpp-server-0.14-22.el6_3.x86_64 
  #              libboost_filesystem.so.5()(64bit) is needed by (installed) qpid-qmf-0.14-14.el6_3.x86_64 
  #              libboost_filesystem.so.5()(64bit) is needed by (installed) python-qpid-qmf-0.14-14.el6_3.x86_64
  #              libboost_filesystem.so.5()(64bit) is needed by (installed) qpid-cpp-server-ssl-0.14-22.el6_3.x86_64
  #              libboost_program_options.so.5()(64bit) is needed by (installed) qpid-cpp-client-ssl-0.14-22.el6_3.x86_64
  #         To deal with this, I forced the install with a "--nodeps"
  cd /usr/src/redhat/RPMS
  rpm -Uvh --nodeps x86_64/boost-1.54.0-8.el6.x86_64.rpm x86_64/boost-atomic-1.54.0-8.el6.x86_64.rpm \
x86_64/boost-chrono-1.54.0-8.el6.x86_64.rpm x86_64/boost-context-1.54.0-8.el6.x86_64.rpm \
x86_64/boost-date-time-1.54.0-8.el6.x86_64.rpm x86_64/boost-filesystem-1.54.0-8.el6.x86_64.rpm 
x86_64/boost-graph-1.54.0-8.el6.x86_64.rpm x86_64/boost-iostreams-1.54.0-8.el6.x86_64.rpm 
x86_64/boost-locale-1.54.0-8.el6.x86_64.rpm x86_64/boost-log-1.54.0-8.el6.x86_64.rpm \
x86_64/boost-math-1.54.0-8.el6.x86_64.rpm x86_64/boost-program-options-1.54.0-8.el6.x86_64.rpm \
x86_64/boost-python-1.54.0-8.el6.x86_64.rpm x86_64/boost-random-1.54.0-8.el6.x86_64.rpm \
x86_64/boost-regex-1.54.0-8.el6.x86_64.rpm x86_64/boost-serialization-1.54.0-8.el6.x86_64.rpm \
x86_64/boost-signals-1.54.0-8.el6.x86_64.rpm x86_64/boost-system-1.54.0-8.el6.x86_64.rpm \
x86_64/boost-test-1.54.0-8.el6.x86_64.rpm x86_64/boost-thread-1.54.0-8.el6.x86_64.rpm \
x86_64/boost-timer-1.54.0-8.el6.x86_64.rpm x86_64/boost-wave-1.54.0-8.el6.x86_64.rpm \
x86_64/boost-devel-1.54.0-8.el6.x86_64.rpm x86_64/boost-static-1.54.0-8.el6.x86_64.rpm \
noarch/boost-doc-1.54.0-8.el6.noarch.rpm noarch/boost-examples-1.54.0-8.el6.noarch.rpm \
noarch/boost-build-1.54.0-8.el6.noarch.rpm x86_64/boost-jam-1.54.0-8.el6.x86_64.rpm

  #Note #2 - PyOpenGL used to be required but it has been replaced with a Qt-based interface
  $ yum install PyQt4-devel qwt-devel qwtplot3d-qt4-devel

Some RPMs weren't available via the Repos so we have to build them ourselves:

   # pygsl
   cd /usr/src/redhat/SRPMS
   wget http://kojipkgs.fedoraproject.org//packages/pygsl/0.9.5/9.fc19/src/pygsl-0.9.5-9.fc19.src.rpm
   rpm -ivh pygsl-0.9.5-9.fc19.src.rpm

   cd /usr/src/redhat/SPECS
   rpmbuild -bb --target=x86_64 pygsl.spec
   rpm -ivh /usr/src/redhat/RPMS/x86_64/pygsl-0.9.5-9.el6.x86_64.rpm

Next, it seems there are some issues with building the gr-osmosdr package below 
with versions of cmake less that 2.8.11 in combination with boost and gnuradio.  
I beat my head on this several times so we have to bit the bullet and make our
own modern version of Cmake since nothing current and fixed is available for 

  # Get the new version of Cmake from http://koji.fedoraproject.org/koji/packageinfo?packageID=1485

  cd /usr/src/redhat/SRPMS
  wget http://kojipkgs.fedoraproject.org//packages/cmake/
  rpm -ivh cmake-

  #Next, install a required dependency:
  yum install libarchive-devel

  cd /usr/src/redhat/SPECS

  # Next, it's worth noting that the new versions of Cmake is bloated up with requiring Emacs 
  #  other garbage.  It was not very strait forward to disable the need for libarchive-devel and
  #  Emacs so I just recommend to install them including one hidden dependency NOT included 
  #   in the Emacs RPM
  yum install libarchive-devel emacs libotf

  # One more thing, it seems I discovered a bug in one of Cmake's post-build tests
  # which doesn't like the real build environment in /usr/src/redhat vs. a symlink
  # of ~/rpmbuild .  The errors shows itself in the cmake tests after compiling ok:
  #    The following tests FAILED:
  #         287 - CTestTestMemcheckDummyValgrindInvalidSupFile (Failed)
  #    Errors while running CTest  
  #  A fix has been create ngladitz and will be available in a future cmake release. 
  #  Until then, disable this specific test.  

  # Edit the cmake.spec file and find the following line:
  vim cmake.spec
  bin/ctest -V -E ModuleNotices -E CMake.HTML -E CTestTestUpload  %{?_smp_mflags}
     and replace it with:

  #DummyValgrindInvalidSupFile does not work on symlinked build environments - bug will be reported via ngladitz
  bin/ctest -V -E ModuleNotices -E CMake.HTML -E CTestTestUpload -E DummyValgrindInvalidSupFile %{?_smp_mflags}

  # Ok, time to compile and install it:
  #   Note: this takes a while to build
  # Do NOT run this command as root:
  rpmbuild -bb --target=x86_64 cmake.spec

  #Ok, now as the Root user, install it:
  rpm -Uvh /usr/src/redhat/RPMS/x86_64/cmake-


Next, there are more RPMs required:

   # TO create the documentation
   rpm install xmlto graphviz

   # The new GUI
   yum install qt4-devel PyQwt-devel

   #To build GnuRadio, we need some more RPMs - Texlive will require 14 other RPMs
   yum install cmake SDL-devel texlive-latex orc-devel python-docutils uhd-devel

   #To complete the final RPM install, we also need this rpm
   yum install scipy

Now, we have to build a few more RPMs from scratch as there aren't new enough ones available
for Centos:

   | NOTE:  As of 01/2014, libusbx was merged back into libusb and then libusbx was |
   |        deprecated.  As such, I need to update this section to use the newest   |
   |        libusb though I'll admit it might be better to just start over with     |
   |        Centos7                                                                 |

   #libusbx - This is a newer version (fork) from libusb1.  As such, the rpm command here is
   #          using UPGRADE versus install
   cd /usr/src/redhat/SRPMS
   wget http://kojipkgs.fedoraproject.org//packages/libusbx/1.0.15/2.fc19/src/libusbx-1.0.15-2.fc19.src.rpm
   rpm -ivh libusbx-1.0.15-2.fc19.src.rpm
   cd /usr/src/redhat/SPECS
   rpmbuild -bb --target=x86_64 libxusb.spec
   rpm -Uvh /usr/src/redhat/RPMS/x86_64/libusbx-1.0.15-2.el6.x86_64.rpm \

   #uhd - the base driver for USB, Ettus, and other devices 
   #   http://koji.fedoraproject.org/koji/packageinfo?packageID=12939
   cd /usr/src/redhat/SRPMS
   wget http://kojipkgs.fedoraproject.org//packages/uhd/3.5.3/3.fc20/src/uhd-3.5.3-3.fc20.src.rpm
   rpm -ivh uhd-3.5.3-3.fc20.src.rpm

      # Now let's compile the UHD stuff
      #   DO NOT do this as ROOT
      #   NOTE: this takes 19min to build on my dual core i5 2430M @ 2.4GHz with
      #         4GB of RAM and a 5400RPM HD.  

      cd /usr/src/redhat/SPECS
      rpmbuild -bb --target=x86_64 uhd.spec

      # Let's now install it:
      #   Run this as root
      rpm -Uvh x86_64/uhd-3.5.3-3.el6.x86_64.rpm noarch/uhd-firmware-3.5.3-3.el6.noarch.rpm \
       x86_64/uhd-devel-3.5.3-3.el6.x86_64.rpm noarch/uhd-doc-3.5.3-3.el6.noarch.rpm

   # Qwt: Next, we need to build a modern version of Qwt-5.2.3 as it's required 
   #      by GnuRadio >= 3.7.0
       # Get the new Qwt code
       cd /usr/src/redhat/SOURCES

       # Next, get an example SPEC file
       cd /usr/src/redhat/SRPMS
       rpm -ivh qwt-5.1.1-4.1.el6.src.rpm

       #Next, download and replace the old patch file with one from my directory
       cd /usr/src/redhat/SOURCES
       rm qwt-path.patch
       wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/qwt-5.2.3-path.patch

       #Now edit the spec file to use the newer code
       cd /usr/src/redhat/SPECS
       vim qwt.spec
         # Find the following lines and update them to reflect the new version
         Version:        5.2.3

         Release:        1.1%{?dist}

         # Update the patch reference as it had to be updated for this new version
             Patch0:                qwt-5.2.3-path.patch


         #Also update the patch command to use a level-0 patching
             %patch0 -p0

         # Enable parallel compiling by adding the following to the "make" line:
            make %{?_smp_mflags}

       # Compile the new version
       #   Do **NOT** run this "rpmbuild" command as the root user
       rpmbuild -bb --target=x86_64 qwt.spec

       # Let's install the RPM but you need to be root
       cd /usr/src/redhat/RPMS/x86_64/
       sudo rpm -Uvh qwt-5.2.3-1.1.el6.x86_64.rpm qwt-devel-5.2.3-1.1.el6.x86_64.rpm

   # PyGtk: gnuradio-companion as of 3.7.2 now requires PyGTK 2.17 or newer to resolve
   #        errors like: 
   #              AttributeError: type object 'gtk.Entry' has no attribute 'has_focus'
   #        Unfortunately to install that newer code, we also have to upgrade pygobject2

   # Before we get started on pygobject2, we have to fix a low level issue on Centos per
   #     https://www.marshut.net/nvups/problems-rebuilding-pygtk2-2-16.html
   cd /usr/src/redhat/SOURCES
   wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/python2.6-modsupport.diff
   sudo cp /usr/include/python2.6/modsupport.h /usr/include/python2.6/modsupport.h.orig
   sudo patch -p1 < python2.6-modsupport.diff
   # NOTE: You cannot load any versions NEWER than 2.28.2 or other dependencies come in
   cd /usr/src/redhat/SRPMS
   wget https://kojipkgs.fedoraproject.org//packages/pygobject2/2.28.6/2.fc16/src/pygobject2-2.28.6-2.fc16.src.rpm
   sudo rpm -ivh pygobject2-2.28.6-2.fc16.src.rpm
   cd /usr/src/redhat/SPECS
   rpmbuild -bb --target=x86_64 pygobject2.spec
   cd /usr/src/redhat/RPMS/x86_64
   sudo rpm -Uvh pygobject2-2.28.6-2.el6.x86_64.rpm pygobject2-codegen-2.28.6-2.el6.x86_64.rpm \
pygobject2-devel-2.28.6-2.el6.x86_64.rpm pygobject2-doc-2.28.6-2.el6.x86_64.rpm

   #Ok, now finally to pygtk2
   cd /usr/src/redhat/SRPMS
   wget https://kojipkgs.fedoraproject.org//packages/pygtk2/2.24.0/1.fc15/src/pygtk2-2.24.0-1.fc15.src.rpm
   sudo rpm -ivh pygtk2-2.24.0-1.fc15.src.rpm
   cd /usr/src/redhat/SPECS
   rpmbuild -bb --target=x86_64 pygtk2.spec
   cd /usr/src/redhat/RPMS
   sudo rpm -Uvh x86_64/pygtk2-2.24.0-1.el6.x86_64.rpm x86_64/pygtk2-codegen-2.24.0-1.el6.x86_64.rpm \
x86_64/pygtk2-libglade-2.24.0-1.el6.x86_64.rpm x86_64/pygtk2-devel-2.24.0-1.el6.x86_64.rpm \

42c2. - Compiling GnuRadio Dependencies

Ok!  Let's get down to getting and building GnuRadio.  It should be noted that 
the GnuRadio package is HUGE and I've found that only compiling the Linux kernel 
is as long, complex, etc.

   #Get the STABLE source code - There are three versions of GnuRadio that you can download:
   #   Stable - that's what I would recommend
   #   Development - stuff should be expected to be broken
   #   Katana-edge - Specific developer dailies
   # At the time of this writing, the newest stable is

   NOTE: If your trying to use an older version of GnuRadio such as 3.7.5, this is
   #     note recommended for the following reasons which have been addressed in the
   #     newer releases:
      #  1 - when running gnuradio-companion (grc), it doesn't allow you to save files and 
      #      throws errors like:
      #         Traceback (most recent call last):
      #         File "/usr/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py", line 457, in _handle_action
      #         ParseXML.to_file(self.get_flow_graph().export_data(), self.get_page().get_file_path())
      #         File "/usr/lib64/python2.6/site-packages/gnuradio/grc/base/ParseXML.py", line 124, in to_file
      #         'grc', ' '.join("{}='{}'".format(*item) for item in instructions.iteritems())
      #         File "/usr/lib64/python2.6/site-packages/gnuradio/grc/base/ParseXML.py", line 124, in 
      #         'grc', ' '.join("{}='{}'".format(*item) for item in instructions.iteritems())
      #         ValueError: zero length field name in format
      #      I reported this and this was due to a commit between 3.7.4 and
      #  2 - In GRC, module tree on the right side of the screen won't display properly after 3.7.2
      #      I reported this and this is supposedly fixed in 3.7.6
      #  3 - There are issues with gnuradio-companion until 3.7.4 per:
      #         http://gnuradio.4.n7.nabble.com/GRC-issues-with-GNU-Radio-3-7-td46935.html
      # For now, I'm working with Sebastian Koslowski (GRC developer) using the GRC Working Group's GIT 
      # repository at https://github.com/gnuradio/gnuradio-wg-grc (3.7.6git) to get things fully functional.  
      # This doc currently covers 3.7.4 which is the best stable version for Centos at the moment

   # Ok, let's build with
   cd /usr/src/redhat/SOURCES
   wget http://gnuradio.org/releases/gnuradio/gnuradio-

   # RECOMMENDED: Now let's get a spec file for gnuradio:
   # You can use my GnuRadio spec file and patch:
   cd /usr/src/redhat/SPECS
   wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/gnuradio.spec
   cd /usr/src/redhat/SOURCES
   wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/doxygen-fix-3.7.9.patch

   #  ---- OR alternatively you can create your own SPEC file (NOT RECOMMENDED) ----

      # Get a spec from a stable Fedora package and modify accordingly
      cd /usr/src/redhat/SRPMS
      wget http://kojipkgs.fedoraproject.org//packages/gnuradio/
      rpm -ivh gnuradio-

   # If using my SPEC file or the Fedora SPEC file, there are several items you need to 
   # either verify in the file or modify to make things work here:

     -  This GnuRadio spec file overrides the "-j" option for building to -j1 and I 
        emailed the author to understand why but I never received a response.  I found
        that if I set this to "-j8", it would take my Intel i5 2-core + 2-HypeThread
        machine with 4GB RAM, 500G/5400RPM laptop computer to it's knees with a load of 
        10+ and started to swap to death!  I found that a setting of "-j2" worked ok.  

        # First, for 3.7.4+, we need to download a minor Doxygen patch
        cd /usr/src/redhat/SOURCES
        wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/doxygen-fix-3.7.9.patch

        #Here is an older patch if you're trying to use an older version of GnuRadio
        wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/doxygen-fix.patch

        # Now let's edit the spec file to support the new version of GnuRadio as well as include one fix

        cd /usr/src/redhat/SPECS
        vim gnuradio.spec

            Make changes to the parallel build system to run a little faster:

              %{?_smp_mflags: %global my_smp_mflags %(echo "%{_smp_mflags}" | sed 's/-j[0-9]\\+/-j1/g')}

            and change it to:

              %{?_smp_mflags: %global my_smp_mflags %(echo "%{_smp_mflags}" | sed 's/-j[0-9]\\+/-j2/g')}

          Next, find the version line and update it to reflect the version of GnuRadio 


          Next, we need to fix a Doxygen issue found starting in  Find the line that says:


               and just below it, add the line:

                  Patch0: 	doxygen-fix-3.7.9.patch

               Also, find the line that says:

                    %setup -q

                 and add a line under that says:

                    %patch0 -p0

        Next, GnuRadio 3.7.2+ requires a new version of qwt so let's update the spec file to reflect that:

            Find the lines that say:

                BuildRequires:  qwt-devel, qwtplot3d-qt4-devel, python-cheetah

            And replace them with:
                BuildRequires:  qwt-devel >= 5.2
                BuildRequires:  qwtplot3d-qt4-devel, python-cheetah

        Next, GnuRadio Companion is shifting to OpenGL centric displays so if you want all the functionality,
           let's make sure the package requires it:

            Find the line that says:

                Requires:  pygtk2, python-cheetah, PyQt4, PyQwt

            And replace them with:

                Requires:  pygtk2, python-cheetah, PyQt4, PyQwt, PyOpenGL

          Next, in the %build section, find the "cmake" line and change *all* of the 
          "FORCE" options to "ON".  Also, change the "-DENABLE_GR_UHD" option to be "OFF".
          For example:

               -DENABLE-GR_COMEDI=FORCE -DENABLE_GR_FCD=ON -DSYSCONFDIR=/etc %{?mfpu_neon} ..

        # Next, 3.7.2 adds some Cmake files that's required for gr-osmosdr package so we need to
        #  make sure they are recognized.  Under the "%files devel" section, find the line:


              and under that, add:


        # Next, as of the version, they dropped the AUTHORS file so you need to remove that
        #  from the SPEC file.  Find the following line:
            install -m 644 -t %{buildroot}%{_docdir}/%{name}-%{version} COPYING AUTHORS

              and replace it with

            install -m 644 -t %{buildroot}%{_docdir}/%{name}-%{version} COPYING


   # Ok, that should be it!  All this to just GnuRadio to compile..  crazy huh?  
   # Anyway, let's compile it 
   #   NOTE: This build takes:
   #            45min       for 3.7.4   : on dual core Intel i5 2430M @ 2.4ghz : 4GB of RAM : 5400RPM HD
   #            54min 50sec for : on dual core Intel i5 2430M @ 2.4ghz : 4GB of RAM : Samsung Evo SSD
   #   Building GnuRadio is a very disk intensive process which is I/O bound so a faster 
   #   storage device like an SSD or hard drive (7200rpm) might help A LOT!  
   #   +++ See below if this compile starts to run and then later FAILS +++
   #   Do **NOT** run this "rpmbuild" command as the root user
   time rpmbuild -bb --target=x86_64 gnuradio.spec   

         It's critically important that you review the start of this compiling stage
         to confirm all the GnuRadio systems and hardware support you expect to be
         enabled IS going to be present in the final build.  My output shows:

          -- ######################################################
          -- # Gnuradio enabled components
          -- ######################################################
          --   * python-support
          --   * testing-support
          --   * volk
          --   * doxygen
          --   * gnuradio-runtime
          --   * gr-blocks
          --   * gnuradio-companion
          --   * gr-fec
          --   * gr-fft
          --   * gr-filter
          --   * gr-analog
          --   * gr-digital
          --   * gr-dtv
          --   * gr-atsc
          --   * gr-audio
          --   * * alsa
          --   * * oss
          --   * * jack
          --   * * portaudio
          --   * gr-channels
          --   * gr-noaa
          --   * gr-pager
          --   * gr-qtgui
          --   * gr-trellis
          --   * gr-uhd
          --   * gr-utils
          --   * gr-video-sdl
          --   * gr-vocoder
          --   * gr-fcd
          --   * gr-wavelet
          --   * gr-wxgui
          -- ######################################################
          -- # Gnuradio disabled components
          -- ######################################################
          --   * sphinx
          --   * gr-ctrlport
          --   * gr-comedi
          --   * gr-zeromq

     If your compile begins and runs for quite some time to only fail, you might be 
     running out of RAM.  I've been working with Linux and have compiled a LOT of code 
     in my day but I've never seen a build require so many resources.  That even includes
     compiling a Linux kernel!   If you're hit by this failing builds, I would just 
     recommend to reboot your Linux machine, don't start up any web browsers, etc and
     try to get past this build and then go back to business as usual.  

     The two example failures I saw were:

       Failure #1 at 80% through the compile:
       [ 80%] Building CXX object gr-filter/swig/CMakeFiles/_filter_swig.dir/filter_swigPYTHON_wrap.cxx.o
       cd /home/dranch/rpmbuild/BUILD/gnuradio- && /usr/bin/c++  -DENABLE_GR_LOG \
-DGR_PERFORMANCE_COUNTERS -D_filter_swig_EXPORTS -O3 -march=native -m64  -fvisibility=hidden -Wsign-compare \
-Wall -Wno-uninitialized -O3 -DNDEBUG -fPIC -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/usr/include/python2.6    \
-Wno-unused-but-set-variable -o CMakeFiles/_filter_swig.dir/filter_swigPYTHON_wrap.cxx.o \
-c /home/dranch/rpmbuild/BUILD/gnuradio-

       The bug is not reproducible, so it is likely a hardware or OS problem.
       make[2]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig5.dir/blocks_swig5PYTHON_wrap.cxx.o] Error 1
       make[2]: Leaving directory `/usr/src/redhat/BUILD/gnuradio-'
       make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig5.dir/all] Error 2

       Failure #1 at 80% through the compile:
       [ 90%] Building CXX object gr-atsc/lib/CMakeFiles/gnuradio-atsc.dir/atsc_depad.cc.o

       cd /home/dranch/rpmbuild/BUILD/gnuradio- && /usr/bin/c++   \
-DENABLE_GR_LOG -DGR_PERFORMANCE_COUNTERS -Dgnuradio_atsc_EXPORTS -O3 -march=native -m64  \
-fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -O3 -DNDEBUG -fPIC \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- -I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio- \
-I/home/dranch/rpmbuild/BUILD/gnuradio-    -o CMakeFiles/gnuradio-atsc.dir/atsc_depad.cc.o \
-c /home/dranch/rpmbuild/BUILD/gnuradio- 
      Linking CXX shared library libgnuradio-digital-
      cd /home/dranch/rpmbuild/BUILD/gnuradio- && \
/usr/bin/cmake -E cmake_link_script CMakeFiles/gnuradio-digital.dir/link.txt --verbose=1   
      /usr/bin/c++  -fPIC -O3 -march=native -m64  -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -O3 -DNDEBUG   \
-shared -Wl,-soname,libgnuradio-digital- -o libgnuradio-digital- 
CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_bf_impl.cc.o CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_bc_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_sf_impl.cc.o CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_sc_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_if_impl.cc.o CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_ic_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/burst_shaper_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/burst_shaper_ff_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/additive_scrambler_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/binary_slicer_fb_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/clock_recovery_mm_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/clock_recovery_mm_ff_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/cma_equalizer_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/constellation.cc.o \
CMakeFiles/gnuradio-digital.dir/constellation_decoder_cb_impl.cc.o CMakeFiles/gnuradio-digital.dir/constellation_receiver_cb_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/constellation_soft_decoder_cf_impl.cc.o CMakeFiles/gnuradio-digital.dir/corr_est_cc_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/correlate_access_code_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/correlate_access_code_tag_bb_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/correlate_access_code_bb_ts_impl.cc.o CMakeFiles/gnuradio-digital.dir/correlate_access_code_ff_ts_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/correlate_and_sync_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/costas_loop_cc_impl.cc.\
o CMakeFiles/gnuradio-digital.dir/cpmmod_bc_impl.cc.o CMakeFiles/gnuradio-digital.dir/crc32.cc.o CMakeFiles/gnuradio-digital.dir/crc32_bb_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/crc32_async_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/descrambler_bb_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/diff_decoder_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/diff_encoder_bb_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/diff_phasor_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/fll_band_edge_cc_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/framer_sink_1_impl.cc.o CMakeFiles/gnuradio-digital.dir/glfsr.cc.o CMakeFiles/gnuradio-digital.dir/glfsr_source_b_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/glfsr_source_f_impl.cc.o CMakeFiles/gnuradio-digital.dir/hdlc_deframer_bp_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/hdlc_framer_pb_impl.cc.o CMakeFiles/gnuradio-digital.dir/header_payload_demux_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/kurtotic_equalizer_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/lms_dd_equalizer_cc_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/map_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/modulate_vector.cc.o \
CMakeFiles/gnuradio-digital.dir/mpsk_receiver_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/mpsk_snr_est.cc.o \
CMakeFiles/gnuradio-digital.dir/mpsk_snr_est_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/msk_timing_recovery_cc_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/ofdm_carrier_allocator_cvc_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_chanest_vcvc_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/ofdm_cyclic_prefixer_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_base.cc.o \
CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_simpledfe.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_static.cc.o \
CMakeFiles/gnuradio-digital.dir/ofdm_frame_acquisition_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_frame_equalizer_vcvc_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/ofdm_frame_sink_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_insert_preamble_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/ofdm_mapper_bcv_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_sampler_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/ofdm_serializer_vcc_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_sync_sc_cfb_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o CMakeFiles/gnuradio-digital.dir/packet_header_ofdm.cc.o \
CMakeFiles/gnuradio-digital.dir/packet_headergenerator_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/packet_headerparser_b_impl.cc.o 
CMakeFiles/gnuradio-digital.dir/packet_sink_impl.cc.o CMakeFiles/gnuradio-digital.dir/pfb_clock_sync_ccf_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/pfb_clock_sync_fff_impl.cc.o CMakeFiles/gnuradio-digital.dir/pn_correlator_cc_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/probe_density_b_impl.cc.o CMakeFiles/gnuradio-digital.dir/probe_mpsk_snr_est_c_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/scrambler_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/simple_correlator_impl.cc.o \
CMakeFiles/gnuradio-digital.dir/simple_framer_impl.cc.o ../../gnuradio-runtime/lib/libgnuradio-runtime- \
../../gr-filter/lib/libgnuradio-filter- ../../gr-blocks/lib/libgnuradio-blocks- \
../../gr-analog/lib/libgnuradio-analog- ../../volk/lib/libvolk.so.1.2.2 -lboost_date_time -lboost_program_options \
-lboost_filesystem -lboost_system -lboost_thread ../../gr-filter/lib/libgnuradio-filter- \
../../gr-fft/lib/libgnuradio-fft- -lfftw3f -lfftw3f_threads ../../gr-blocks/lib/libgnuradio-blocks- \
../../gnuradio-runtime/lib/libgnuradio-runtime- ../../gnuradio-runtime/lib/pmt/libgnuradio-pmt- \
-lrt ../../volk/lib/libvolk.so.1.2.2 -ldl -lorc-0.4 -lboost_date_time -lboost_program_options -lboost_filesystem -lboost_system \
       /usr/bin/ld: libgnuradio-digital- hidden symbol \
`_ZN5boost6detail18sp_counted_impl_pdIPNS_2io18basic_altstringbufIcSt11char_traitsIcESaIcEEENR2_22basic_oaltstringstreamIcS5_S6_E5No_OpEE11get_deleterERKSt9type_info' isn't defined 
       /usr/bin/ld: final link failed: Nonrepresentable section on output
       collect2: ld returned 1 exit status
       make[2]: *** [gr-digital/lib/libgnuradio-digital-] Error 1
       make[2]: Leaving directory `/usr/src/redhat/BUILD/gnuradio-'
       make[1]: *** [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/all] Error 2   

42c3. - Installing GnuRadio

Now it's time to finally install GnuRadio!

   #  NOTE: If you're upgrading from a previous version of GnuRadio, you'll need to uninstall
   #        any previous version of gr-osmosdr first and then you'll need to update it in a bit.
   #        To uninstall it, do it with:
   #           sudo rpm -e gr-osmosdr gr-osmosdr-devel
   #  NOTE #2: If you're trying to upgrade GnuRadio after you've already built other programs like
   #           gr-osmosdr, and Gqrx.. you MUST UNINSTALL those older programs FIRST:
      sudo rpm -e gr-osmosdr-doc-0.1.5-3.20151214git7cec4c0f.el6.noarch \
gr-osmosdr-devel-0.1.5-3.20151214git7cec4c0f.el6.x86_64 \
gr-osmosdr-0.1.5-3.20151214git7cec4c0f.el6.x86_64 \
gr-iqbal-0.37.2-3.el6.x86_64 \
gr-iqbal-devel-0.37.2-3.el6.x86_64 \

   #    sudo rpm -e gr-osmosdr-devel-0.1.1-1.20131208git05d51b53.el6.x86_64 \
   #    gr-osmosdr-0.1.1-1.20131208git05d51b53.el6.x86_64 gr-osmosdr-doc-0.1.1-1.20131208git05d51b53.el6.noarch \
   #    gqrx-2.3.0-1.20131215git57356c50.el6.x86_64
   #       Now install your newly build gnuradio RPMs and then rebuild / install any other updated 
   #       RPMs like gr-osmosdr, Gqrx, etc. afterward

   cd /usr/src/redhat/RPMS
   sudo rpm -Uvh x86_64/gnuradio- \
x86_64/gnuradio-examples- \
x86_64/gnuradio-devel- \

   #old install
   sudo rpm -Uvh x86_64/gnuradio-3.7.4-1.el6.x86_64.rpm x86_64/gnuradio-devel-3.7.4-1.el6.x86_64.rpm \
noarch/gnuradio-doc-3.7.4-1.el6.noarch.rpm x86_64/gnuradio-examples-3.7.4-1.el6.x86_64.rpm

Excellent work and it' installed!  It's now HIGHLY recommended to optimize your GnuRadio 
software for your specific computer.  From the command line run this command while 
NOT using your computer for anything:

   #Do not run this as the root user

   # takes 18min 22sec on a i5-2430M running 2.4Ghz w/ 4GB RAM - only uses a single core
   time volk_profile

This command will allow GnuRadio to best utilize your specific hardware.  This is a 
VERY time consuming process so let it complete.  The output of the command will write 
it's settings to $HOME/.volk/volk_config .  If multiple users are going to use 
GnuRadio / Gqrx / etc on this machine, they will need to either copy this file in their 
home directory or run the "volk_profile" themselves.

42.c4 - GR-IQBAL - Supporting the IQ-Balance GnuRadio module

An optional module of GnuRadio is the IQ-Balance module where it attempts to
to suppress the symmetrical images caused by IQ imbalance in the RX path of 
quadrature receivers.   This will help minimize the spike right in the middle
of the waterfall when using I/Q devices like RTL dongles, SoftRocks, etc.

* If your reading this as you just upgraded your version GnuRadio, YES, you're 
* going to need to rebuild gr-ipbal module (no need to rebuild/re-install
* libosmo-dsp

Ok, let's get started.  First, we actually have to build the libosmo-dsp package

  # Download and install the newest libosmo-dsp SPEC file found at:
  #   SRPM baseline can be found at:
  #      http://koji.fedoraproject.org/koji/packageinfo?packageID=19272
  cd /usr/src/redhat/SRPMS
  wget https://kojipkgs.fedoraproject.org//packages/libosmo-dsp/0.3/1.fc20/src/libosmo-dsp-0.3-1.fc20.src.rpm
  rpm -ivh libosmo-dsp-0.3-1.fc20.src.rpm

  #Now let's build and install it
  cd /usr/src/redhat/SPECS

  #   Do NOT be root when running this
  #    build time: 18 seconds
  rpmbuild -bb --target=x86_64 libosmo-dsp.spec
  sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/libosmo-dsp-0.3-1.el6.x86_64.rpm
  sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/libosmo-dsp-devel-0.3-1.el6.x86_64.rpm

Now let's get going with gr-iqbal:

  # Download and install the newest IQBal SPEC file found at:
  #   SRPM baseline can be found at:
  #      http://koji.fedoraproject.org/koji/buildinfo?buildID=589945886
  cd /usr/src/redhat/SRPMS
  wget https://kojipkgs.fedoraproject.org//packages/gr-iqbal/0.37.2/3.fc20/src/gr-iqbal-0.37.2-3.fc20.src.rpm
  rpm -ivh gr-iqbal-0.37.2-3.fc20.src.rpm

  # It's worth noting that this module hasn't been updated 11/20/2015 with it's 0.37.2 release.
  # Ok, time to build it:
  #   Do NOT be root when running this
  #    build time: 18 seconds
  cd /usr/src/redhat/SPECS
  rpmbuild -bb --target=x86_64 gr-iqbal.spec

  # Now let's install it
  cd /usr/src/redhat/RPMS/
  sudo rpm -Uvh x86_64/gr-iqbal-0.37.2-3.el6.x86_64.rpm x86_64/gr-iqbal-devel-0.37.2-3.el6.x86_64.rpm \

42e. - RTL Support - Adding the supporting software for the RTL2838 devices

If you have chosen to use an RTL Dongle device, you'll want to follow this section:

   NOTE on software compiling order: 
     The RTL-SDR Application package must be installed FIRST and then
     you can compile and install the GR-OSMOSDR software.  If you don't 
     do things in this order, the required GR-OSMO plugin will not be built

The RTL-SDR package has various required support applications to get it 
properly programmed, tested, etc.

  # Download and install the newest RTL-SDR software found at:
  #   SRPM baseline can be found at:
  #      http://koji.fedoraproject.org/koji/packageinfo?packageID=15886
  cd /usr/src/redhat/SRPMS
  wget http://kojipkgs.fedoraproject.org//packages/rtl-sdr/0/0.2.20130403git4a068f56.fc19/src/rtl-sdr-0-0.2.20130403git4a068f56.fc19.src.rpm
  rpm -ivh rtl-sdr-0-0.2.20130403git4a068f56.fc19.src.rpm

  # Now lets finally download the current version of the RTL-SDR software.  You can 
  # quickly see what the current version is by looking here:
  #    https://git.osmocom.org/rtl-sdr/
  #Ok, get's get going 
  cd /usr/src/redhat/SOURCES

  mkdir rtl-sdr-git
  cd rtl-sdr-git
  git clone git://git.osmocom.org/rtl-sdr.git

  # Now figure out the version - current version as of this writing is 0.5.2
  grep -r VERSION_INFO *

  # Write down the GIT commit code with - current version as of this writing is 2d0eaa898d2d4e271aed87ae3849a80ac12cf76c
  cat rtl-sdr/.git/logs/HEAD

  # Ok, time to make the archive.  To do this, we need to change the directory name and then
  #  come up with the datecode and the GIT short commit string.  This "short commit" is the 
  #  first 8 characters of the full git commit string so in my case, doing this on 
  #  December 13, 2013, I would need to do:
  mv rtl-sdr rtl-sdr-0.5.2
  tar civf ../rtl-sdr-0.5.2-20131213git2d0eaa89.tar.bz2 rtl-sdr-0.5.2/*
  cd ..
  rm -Rf rtl-sdr-git

  #Now you have to change a few things in this Spec file and update the blanks for 
  # your specific GIT checkout version.  For me, I have:
  cd /usr/src/redhat/SPECS
  vim rtl-sdr.spec
    1. Update the top git_commit line: 2d0eaa898d2d4e271aed87ae3849a80ac12cf76c

    2. Update the GIT date:            20131213

    3. Update the Version:             0.5.2

    4. Update the Release to:          1.%{git_suffix}%{?dist}

    Now, you need to disable the patches in the old SPEC file as those changes 
    have already been integrated into the RTL-SDR sources:

      Delete or comment out the lines:

            Patch0:           rtl-sdr-0-lib64-fix.patch
            %patch0 -p1 -b .lib64-fix

  # Ok, time to build it:
  #  This takes about
  #   Do NOT be root when running this
  #    build time: 18 seconds
  rpmbuild -bb --target=x86_64 rtl-sdr.spec

  # Be root to install it
  sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/rtl-sdr-0.5.2-1.20131213git2d0eaa89.el6.x86_64.rpm \

  # Dongle Usage Unix Group 
  Ok.. one last thing:  You need to add your username (and any other users that will be 
  using the RTL USB dongle to the "rtlsdr" Unix group.  In this example, I'm adding myself 
  (user: dranch) to this new Unix group.  You'll need to change the username to reflect 
  YOUR username (and any additional username):

      sudo groupadd rtlsdr
      sudo usermod -G rtlsdr dranch

  # Normally, you now would need to completely log out of the machine (Xwindows 
  # and all) and then log back in to see this new group ownership.  To confirm,
  # be that new user (dranch in this example), and run the command:

       $ groups
       dranch dialout lock wireshark

  # Notice the "rtlsdr" group isn't listed in the above output.  To get this
  # command to take effect NOW, without logging out and back in,  use the 
  # following command:

      newgrp rtlsdr

  # You'll have to use this command in every login using this specific username 
  # you have until you completely log out and back in on each of those logins.

42.e1 - SDR Testing - Making sure the RTL hardware works and doing UDEV blocklists

Whew!  Now we're set with the basics so let's try it out.   Connect the USB device 
into a free USB port and then run "dmesg" command to confirm it's seen.  Below is 
what I saw when I connected my Terratec Cinergy T Stick+:
  usb 2-1.3.3: new high-speed USB device number 13 using ehci-pci
  usb 2-1.3.3: New USB device found, idVendor=0ccd, idProduct=00d7
  usb 2-1.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
  usb 2-1.3.3: Product: RTL2838UHIDIR
  usb 2-1.3.3: Manufacturer: Realtek
  usb 2-1.3.3: SerialNumber: 00000001
  usbcore: registered new interface driver dvb_usb_rtl28xxu
  usb 2-1.3.3: dvb_usb_v2: found a 'TerraTec Cinergy T Stick+' in warm state
  usb 2-1.3.3: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
  DVB: registering new adapter (TerraTec Cinergy T Stick+)
  usb 2-1.3.3: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
  i2c i2c-7: e4000: Elonics E4000 successfully identified
  Registered IR keymap rc-empty
  input: TerraTec Cinergy T Stick+ as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3.3/rc/rc0/input19
  rc0: TerraTec Cinergy T Stick+ as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3.3/rc/rc0
  usb 2-1.3.3: dvb_usb_v2: schedule remote query interval to 400 msecs
  usb 2-1.3.3: dvb_usb_v2: 'TerraTec Cinergy T Stick+' successfully initialized and connected

The output might be a bit different depending on the RTL dongle you have, which tuner it
uses, etc.  Ok, assuming you saw something like all that.. let's make sure the basics work.  

As a non-root user that is part of the 'rtlsdr" unix group, run the command:


You should see something like the following:
   Found 1 device(s):
     0:  Terratec T Stick PLUS

   Using device 0: Terratec T Stick PLUS
   Detached kernel driver
   Found Elonics E4000 tuner
   Supported gain values (14): -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0 21.5 24.0 29.0 34.0 42.0

   Info: This tool will continuously read from the device, and report if
   samples get lost. If you observe no further output, everything is fine.

   Reading samples in async mode...

Type in control-C to exit the program

Did you see all that which represents a PASSED test?  Maybe you saw the following that
represents a FAILURE:
   $ rtl_test
   Found 1 device(s):
     0:  Terratec T Stick PLUS

   Using device 0: Terratec T Stick PLUS

   Kernel driver is active, or device is claimed by second instance of librtlsdr.
   In the first case, please either detach or blocklist the kernel module
   (dvb_usb_rtl28xxu), or enable automatic detaching at compile time.

   usb_claim_interface error -6
   Failed to open rtlsdr device #0.

   That "usb_claim_interface" error means that something else is already loaded to
   support the RTL device.  Specifically, Linux supports this device as a TV receiver
   and it's already loaded the required TV receiver drivers.  Since you DON'T want 
   to use this as a TV receiver but as a hacked up SDR receiver, we need to prohibit
   the TV drivers from being automatically loaded.  To do this, you need to blocklist 
   the "dvb_usb_rtl28xxu" kernel module.  You can temporarily unload that module from 
   kernel memory with:

      sudo /sbin/rmmod dvb_usb_rtl28xxu

   To make this change permanent, edit the /etc/modprobe.d/blocklist.conf file and add
   the following to the end of the file
   #RTL dongles for broadband SDR reception
   blacklist dvb_usb_rtl28xxu

Ok, with those changes made and you're always getting a PASS on the above test, 
things are working well.  Next, try the command:

    rtl_test -t

Which will also attempt to identify the frequency offset of your specific dongle.  
This can take some time and this offset can sometimes be SUBSTANTIAL so record the 
results for later use.  For my device, I saw:
  rtl_test -t
  Found 1 device(s):
    0:  Terratec T Stick PLUS

  Using device 0: Terratec T Stick PLUS
  Found Elonics E4000 tuner
  Supported gain values (14): -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0 21.5 24.0 29.0 34.0 42.0
  Benchmarking E4000 PLL...
  [E4K] PLL not locked for 52000000 Hz!
  [E4K] PLL not locked for 2226000000 Hz!
  [E4K] PLL not locked for 1114000000 Hz!
  [E4K] PLL not locked for 1247000000 Hz!
  E4K range: 53 to 2225 MHz
  E4K L-band gap: 1114 to 1247 MHz

At this point, there are a few command-line only applications that you can try 
to use.  For example, to listen to a local STRONG stereo broadcast station at 
97.7Mhz FM and play it back with two channels (-c 2) to the "default" sound 
device (run "aplay -L" to get a list of soundcards on your computer), I use:

     rtl_fm -f 97.7M -W - | aplay -r 16k -f S16_LE -t raw -c 2 -D default

     NOTE:  If the volume is very low, load up pavucontrol and increase the level for 
            Output --> Alsa Plug-in [playb]

42g. - Airspy Support - Adding the supporting software for the AirSpy devices

This is the main window that shows the maximum bandwidth being captured: 10Mhz or 10MSPS

If you have an AirSpy SDR device, you need to install the UserMode drivers first 
to then update the gr-osmosdr package.  

NOTE:  libusb might need to be upgraded to 1.0.19 - things work ok with me w/o 
       upgrading it

#Next, let's get the Airspy "Host" sources, align them, and fix them for Centos6 from
#  https://github.com/airspy/host/releases
cd /usr/src/redhat/SOURCES
wget https://github.com/airspy/host/archive/v1.0.8.tar.gz
cd ../BUILD
tar ../SOURCS/xzvf v1.0.8.tar.gz

#Now create a properly named archive to match RPM naming conventions
mv host-1.0.8 airspy-host-1.0.8

# For 1.0.7:
# Next, there is an issue with the Airspy's cmake file which assumes a version of 
# GCC newer than 4.4 which doesn't support the ANSI C version 90 (GCC v4.4 only 
# supports version 89).  I have reported this error to the Github repo but the 
# specific error is:
#  CMake Error at /usr/share/cmake/Modules/TestBigEndian.cmake
# To fix this issue, edit the following files:
#    airspy-host-1.0.8/libairspy/CMakeLists.txt
#    airspy-host-1.0.8/airspy-tools/CMakeLists.txt
#   In those files, find the following line and DELETE it:
#     set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu90")

#Now create the new archive
tar czvf ../SOURCES/airspy-host-1.0.8.tar.gz airspy-host-1.0.8/*
rm -Rf airspy-host-1.0.8

#Next, download the required SPEC file and make sure it reflects the right version
#  of your Airspy host tools
cd /usr/src/redhat/SPECS
wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/airspy-host.spec

vim airspy-host.spec

   URL:              https://github.com/airspy/host/archive/v1.0.8.tar.gz
   Version:          1.0.8

# Ok, time to build it:
#  This takes about
#   Do NOT be root when running this
#    build time: 4 seconds
cd /usr/src/redhat/SPECS
time rpmbuild -bb --target=x86_64 airspy-host.spec

#Now install it with:
sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/airspy-host-1.0.8-1.el6.x86_64.rpm

#Ok, you now have the AirSpy software installed.  Few other things are required
 to be done

  1. If you're running kernel version 3.17.x or newer, you need to blocklist the 
     stock "airspy" kernel driver that is intended for DAB video display.  Do
     the following:

        a. vim /etc/modprobe.d/airspy-blacklist.conf
        blacklist airspy

  2. Dongle Unix Group 
     You now need to add your username (and any other users that will be using the 
     Airspy device to the "plugdev" Unix group.  This specific usergroup was defined in 
     the Udev rule when you installed the AirSpy userspace driver.  In this specific 
     example, I'm created the group AND adding myself (user: dranch) to this Unix group.  
     You'll need to change the username to reflect YOUR username (and any 
     additional username):

       sudo groupadd plugdev
       sudo usermod -G plugdev dranch

     Now normally you would need to completely log out of the machine (Xwindows 
     and all) and then log back in to see your username being in this new group.  
     To confirm, be that new user (dranch in this example), and run the command:

       $ groups
       dranch dialout lock wireshark rtlsdr

     Notice the "plugdev" group isn't listed in the above output.  To get this
     group setting to take effect NOW (without logging out and back in)  use the 
     following command:

        newgrp plugdev

     You'll have to use this command in every login using this specific username 
     you have until you completely log out and back in on each of those logins.

  3. Now lets get down to using the AirSpy with doing some initial testing.  
     Run the following command to verify that the device is seen, check it's 
     serial number, firmware, etc:

      # Do not run as the ROOT user

      $ /usr/bin/airspy_info
      airspy_lib_version: 1.0.8

      Found AirSpy board 1
      Board ID Number: 0 (AIRSPY)
      Firmware Version: AirSpy NOS v1.0.0-rc9-0-ga56adfd 2016-06-12
      Part ID Number: 0x6906002B 0x00000030
      Serial Number: 0x644064xxxxxxxxxx
      Supported sample rates:
              10.000000 MSPS
              2.500000 MSPS
      Close board 1

      If the above command doesn't run properly, you need to resolve the issue

  4. In the above command, you can see that my unit is running firmware 
     AirSpy NOS 1.0.0-rc9-0-ga56adfd 2016-06-12.  The Airspy team updates
     their firmware time to time so I recommend you create a Github account and 
     "watch" the firmware announce page at:


     If there is a newer version of code, consider following these instructions
     to upgrade your firmware:


  5. Next step is to confirm the end to end performance to the Airspy unit.  Run
     the following command for at LEAST 30 seconds

       /usr/bin/airspy_rx -r /dev/null -t 0

       /usr/bin/airspy_rx -r /dev/null -t 0
       Device Serial Number: 0x644064xxxxxxxxxx
       Stop with Ctrl-C
       Streaming at 10.001 MSPS
       Streaming at 10.000 MSPS
       Streaming at 10.000 MSPS
       Streaming at 10.001 MSPS
       . . .
       Streaming at 10.000 MSPS
       Streaming at 10.000 MSPS
       Streaming at 10.000 MSPS
       Streaming at 10.000 MSPS
       ^CCaught signal 2

       User cancel, exiting...
       Total time: 18.4944 s
       Average speed 10.0001 MSPS IQ

     It's critical that this average report OVER 10.0000 MSPS.  If it doesn't, your
     computer hardware + OS + USB sub-system aren't performing fast enough for the 
     AirSpy.   As you can see above on my Intel i5-2430 @ 2.4Ghz dual core laptop 
     running the Epel 3.17.5 kernel, things are just fast enough for 10MSPS (10Mhz wide

     If you're not getting enough samples through, you can try the "packing" feature
     using the "-p 1" option:

       /usr/bin/airspy_rx -p 1 -r /dev/null -t 0
       Device Serial Number: 0x644064DC307C94CD
       Stop with Ctrl-C
       Streaming at 10.006 MSPS
       Streaming at 9.999 MSPS
       Streaming at 9.998 MSPS
       Streaming at 10.006 MSPS
       Streaming at 10.003 MSPS
       Streaming at 10.001 MSPS
       Streaming at 10.004 MSPS
       Streaming at 10.002 MSPS
       Streaming at 10.000 MSPS
       Streaming at 9.993 MSPS
       Streaming at 10.002 MSPS
       Streaming at 9.999 MSPS
       Streaming at 9.995 MSPS
       Streaming at 10.000 MSPS
       ^CCaught signal 2

       User cancel, exiting...
       Total time: 16.7699 s
       Average speed 10.0021 MSPS IQ

     It should be noted that if you enable packing, though you'll be using less USB 
     bandwidth, you WILL be using more CPU to do the unpacking on the CPU side.  For
     example, if my Intel i5-2430 @ 2.4Ghz dual core laptop runs at a load about 4.25
     but with packing enabled, I see a load of about 6.16 to 6.40!

       TBD:   How to improve the performance even more:

              - No USB hubs between the PC and the Airspy

              - Try different USB ports on your computer (ports on the front vs. on 
                the back can be on different / less-loaded USB controllers

              - Try upgrading libusbx to newest libusb libraries

              - Try a newer Linux kernel

              - Try specific USB performance tuning

              - Try using a computer with a better USB chipset

Next up, you'll need to compile GR-OSMOSDR to create the required plugins for GnuRadio.  Go
ahead and skip to that section now unless you want to install support for other hardware.

42h. - SDR-Play Support - Adding the supporting software for the SDR-Play devices

              | SHOW-STOPPER: 2/6/16                                             |
              | Current binary APIs are compiled against Glibc 2.14 but Centos6  |
              | ships with Glibc 2.12.  I've reached out to SDRPlay to see if    |
              | they will release a new binary API version but they politely     |
              | declined saying there wasn't enough market to support a Centos6  |
              | driver effort.  I have since purchased an AirSpy v2 unit where   |
              | everything is open source and it's been working very well.       |
              |                                                                  |
              | Update: 01/25/17                                                 |
              | There is hope via the 3rd party library effort but it's unclear  |
              | how well it works or matches the closed source Mirics library    |
              | https://github.com/f4exb/libmirisdr-4                            |

If you have an SDR-Play device, you MUST install the closed source Mirics APIs as 
provided from the SDR Play folks for it to function.

  NOTE:  The SDRPlay Mirics API download is currently a self-executable file which 
         REQUIRES that the installing user have sudo rights to the machine.  The 
         only other package I've seen like this is Oracle Java but it uses this to
         make the user agree to a license agreement.  There isn't any license display
         nor acceptance prompt here so I don't know why they are doing this.  I cannot 
         disable this sudo behavior.  As such, you MUST give your current username to 
         have root sudo rights before continuing on.

  NOTE2: The following steps took help from the following reference document: 


   1. NOTE: This is now redundant and is not required anymore

      You need to update the Udev system to load the correct base-layer USB driver.  
      To do this, create the /etc/udev/rules.d/66-mirics.rules file and in it, add 
      the following text:


      Now restart Udev with:

        /etc/rc.d/init.d/udev-post restart

   2. You need to download the newest Mirics closed-source API.  As of 1/31/16, 
      the current version is 1.9.4

        a. cd /usr/src/redhat/SOURCES

        b. mkdir SDRplay_RSP_MiricsAPI-1.9.4

        c. cd SDRplay_RSP_MiricsAPI-1.9.4

        d. Goto http://sdrplay.com/linuxdl.php and download the SDRplay_RSP_MiricsAPI-1.9.4.run file

        e. Make it runable with the command:   

             chmod 755 SDRplay_RSP_MiricsAPI-1.9.4.run

        f. Create an archive with

           cd ..
           tar czvf SDRplay_RSP_MiricsAPI-1.9.4.tar.gz SDRplay_RSP_MiricsAPI-1.9.4/*
        g. Remove the source directory

           rm -Rf SDRplay_RSP_MiricsAPI-1.9.4

   4. Download my SDRPlay Spec file

        a. cd /usr/src/redhat/SPECS

        b. wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/sdrplay_rsp_miricsapi.spec

   5. Build the RPM

        a. It's worth mentioning that this source package is a self-installer that 
           requires that you give your sudo password before it runs.  Anyway, now run:

             rpmbuild -bb --target=x86_64 sdrplay_rsp_miricsapi.spec

   6. Install the RPM

        #I am working with SDR-Play to see if a Glibc 2.14 issue can be resolved for the SoapyAPI file
        #The error seen is:
        #  error: Failed dependencies:
        #  libc.so.6(GLIBC_2.14)(64bit) is needed by SDRplay_RSP_MiricsAPI-1.9.4-1.x86_64

        sudo rpm -ivh --nodeps /usr/src/redhat/RPMS/x86_64/SDRplay_RSP_MiricsAPI-1.9.4-1.x86_64.rpm

      Direct install method - to be deleted
      Install the API with:

       sudo /tmp/SDRplay_RSP_MiricsAPI-1.9.4.run
       Verifying archive integrity... All good.           
       Uncompressing SDRplay Mirics API Install Package V1.9.4  100%  
       Installing SDRplay RSP Mirics API library...                   
       Architecture: x86_64                                           
       API Version: 1.8.1                                             
       Remove old libraries...                                        
       Install /usr/local/lib/libmirsdrapi-rsp.so                     
       Remove old header files...                                     
       Install /usr/local/include/mirsdrapi-rsp.h                     
       Udev rules directory found, adding rules...                    
       Libusb found, continuing...                                    
       Installing SoapySDRPlay...                                     
       Installing SoapySDR...                                         

      . There seems to be a bug with the SDR-Play library package which needs 
        a minor fix:

          #The installer is putting 64bit libraries in the 32bit lib pasth
          mv /usr/local/lib/libmirsdrapi-rsp-x86_64-1.8.1.so /usr/local/lib64/
          sudo ln -s /usr/local/lib64/libmirsdrapi-rsp-x86_64-1.8.1.so  /usr/local/lib64/libmirsdrapi-rsp.so

      . To complete the installation, you need to update the lib paths with:
          sudo ldconfig

              | SHOW-STOPPER: 2/6/16                                             |
              | Current binary APIs are compiled against Glibc 2.14 but Centos6  |
              | ships with Glibc 2.12.  I've reached out to SDRPlay to see if    |
              | they will release a new binary API version but they politely     |
              | declined saying there wasn't enough market to support a Centos6  |
              | driver effort.  I have since purchased an AirSpy v2 unit where   |
              | everything is open source and it's been working very well.       |
              |                                                                  |
              | Update: 01/25/17                                                 |
              | There is hope via the 3rd party library effort but it's unclear  |
              | how well it works or matches the closed source Mirics library    |
              | https://github.com/f4exb/libmirisdr-4                            |

42.i - GR-OSMOSDR - Supporting the RTL dongle and SDR-Play SDR devices

The OSMO-SDR software is the middleware package that supports the low level RTL SDR 
and SDR-Play hardware.  Since we need this for either device, let's get started.  
A few notes first...

   NOTE:   1. Please note that the newest versions of the OSMO-SDR software *requires* 
              GnuRadio 3.7.0+ to build.  You must have an updated GnuRadio before you try 
              this stage.

           2. Any Userspace drivers such as the RTL-SDR, AirSpy, or SDRPlay packages 
              *must* be compiled AND be installed before this package can be compiled

           3. There is an optional package called gr-iqbalance that, if installed 
              before gr-osmosdr is built (as detailed above), it will help reduce the 
              mirror signal on either side of the center DC spike seen from  I/Q based 
              devices like the RTL dongles, SoftRock, etc modules.  

  Important Note:
   gr-osmosdr exposes a bug in older versions of Cmake and the Boost libraries so 
   you need to be running valid versions of those programs

  # Download and install a working version of GR-OSMO SDR drivers 
  #   found at http://koji.fedoraproject.org/koji/buildinfo?buildID=482242
  cd /usr/src/redhat/SRPMS
  wget http://kojipkgs.fedoraproject.org//packages/gr-osmosdr/0.1.1/6.20130729git9dfe3a63.fc20/src/gr-osmosdr-0.1.1-6.20130729git9dfe3a63.fc20.src.rpm
  rpm -ivh gr-osmosdr-0.1.1-6.20130729git9dfe3a63.fc20.src.rpm

  # Now we need to get the newest 1.5.0GIT sources as there are important fixes in Git but 
  # a new major version of code hasn't been published since Nov 4, 2014!  That and gqrx 2.4.0
  # requires 0.1.5)
  cd /usr/src/redhat/SOURCES
  mkdir gr-osmosdr-git
  cd gr-osmosdr-git
  git clone git://git.osmocom.org/gr-osmosdr

  # Now check out the version - current version as of this writing is 0.1.5  (shown on three different lines)
  grep -r VERSION_INFO *   

    You should see something like:
    gr-osmosdr/CMakeLists.txt:set(VERSION_INFO_MAJOR_VERSION 0)
    gr-osmosdr/CMakeLists.txt:set(VERSION_INFO_API_COMPAT    1)
    gr-osmosdr/CMakeLists.txt:set(VERSION_INFO_MINOR_VERSION 5)
    gr-osmosdr/CMakeLists.txt:set(VERSION_INFO_MAINT_VERSION git)

  # Next, write down the current GIT commit serial number with the command:
     cat gr-osmosdr/.git/logs/HEAD
  #  as of 07/04/16, it's 164a09fc11cec2d8b15b38e8b512fa542d6cecc7  (never mind if it has your
  #  name or other comments in it, etc.. that's just how Git does things

  # Ok, time to make the archive where the name consists of the package name, version, date and 
  #  the GIT short commit which is the FIRST 8 characters ( Most significant Bit - MSB) of the 
  #  git commit serial number.  In my case, I would need to do:
  mv gr-osmosdr gr-osmosdr-0.1.5
  tar civf tar civf ../../BUILD/gr-osmosdr-0.1.5-20160704git164a09fc.tar.bz2 gr-osmosdr-0.1.5/*
  cd ..
  rm -Rf gr-osmosdr-git

  #Now you have to update a few things in this Spec file:
  cd /usr/src/redhat/SPECS
  vim gr-osmosdr.spec
   Next, edit the gr-osmosdr.spec file and fill in the blanks for your checkout.  For me, I have:
    1. Update the top git_commit line: 164a09fc11cec2d8b15b38e8b512fa542d6cecc7

    2. Update the GIT date:            20160704

    3. Update the Version:             0.1.5

    4. Update the Release to:          4.%{git_suffix}%{?dist}

  Next, we need to update the BuildRequires line.  Change and add the line from:

        BuildRequires:    cmake, python2-devel, gnuradio-devel, boost-devel, doxygen


        BuildRequires:  cmake, python2-devel, gnuradio-devel, doxygen
        BuildRequires:  boost-devel >= 1.53, gr-iqbal-devel

  Next, You need to disable the two patch files if they are present in your version of gr-osmosdr.
  Put a "#" in front of the lines:

      #Patch0:           gr-osmosdr-0.0.1-doxygen-fix.patch
      #Patch1:           gr-osmosdr-0.0.1-docdir-override.patch

  and under the %prep section

      #%patch0 -p1 -b .doxygen-fix
      #%patch1 -p1 -b .docdir-override

  Next, modify the build section to allow for SDR-Play's API connector.  Change the following line:

      %cmake -DENABLE_DOXYGEN=on -DGR_PKG_DOC_DIR=%{_docdir}/%{name} ..


      %cmake -DENABLE_NONFREE=TRUE -DCMAKE_PREFIX_PATH=/usr/local/lib/SoapySDR/ -DENABLE_DOXYGEN=on -DGR_PKG_DOC_DIR=%{_docdir}/%{name} ..

  Next, find the "%files" section and find the FOUR following lines:

     %exclude %{_docdir}/%{name}-%{version}/html
     %exclude %{_docdir}/%{name}-%{version}/xml
     %exclude %{_docdir}/%{name}-%{version}/examples

   You need to disable them by putting a # in front of them like:

     #%exclude %{_docdir}/%{name}-%{version}/html
     #%exclude %{_docdir}/%{name}-%{version}/xml
     #%exclude %{_docdir}/%{name}-%{version}/examples

   Next, go down to the "%files doc" section and add the following as the FIRST
   line under that section:


  # Ok, time to build and install it:
  #   Do NOT be root when running this
  #  NOTE: 
  #   If you see an error similar to:
  #      make[2]: *** No rule to make target `/usr/lib64/lib64/libboost_thread-mt.so.5', needed by `lib/libgnuradio-osmosdr-0.1.1git.so.0.0.0'
  #   This is due to a conflict with an old version of cmake and boost.  The *only* 
  #   way to resolve it is to build modern versions of cmake, boost, and gnuradio 
  #   from scratch as shown in the above sections
  #Build time: 1min 46sec on a dual core i5-2420 laptop at 2.4Ghz with 4GB RAM and a SSD drive
  time rpmbuild -bb --target=x86_64 gr-osmosdr.spec

  # It's now very important that you scroll back and review how the configuration stage 
  # went to verify that you see the expected devices you want supported to be
  # in the "SUPPORTED" list.  If your specific hardware isn't listed under the supported 
  # section, things will NOT work.  You'll need to figure out why they weren't at configuration
  # time, resolve it, and then build again.  An example output would be:
     # -- ######################################################
     # -- # Gnuradio enabled components
     # -- ######################################################
     # --   * Python support
     # --   * Osmocom IQ Imbalance Correction
     # --   * FUNcube Dongle
     # --   * IQ File Source
     # --   * Osmocom RTLSDR
     # --   * RTLSDR TCP Client
     # --   * Ettus USRP Devices
     # --   * RFSPACE Receivers
     # --   * SDRplay RSP (NONFREE)
     # --   * AIRSPY Receiver
     # --
     # -- ######################################################
     # -- # Gnuradio disabled components
     # -- ######################################################
     # --   * sysmocom OsmoSDR
     # --   * FUNcube Dongle Pro+
     # --   * Osmocom MiriSDR
     # --   * HackRF Jawbreaker
     # --   * nuand bladeRF
     # --   * SoapySDR support

  # The above output shows the proprietary SDRPlay RSP drivers being
  # enabled.  This won't be seen unless you follow the SDR-Play section
  # above

  # Now install the RPMs
  #  NOTE:   If you are upgrading from say gr-osmodr-0.1.1 to 0.1.5 to support Gqrx 2.4.0, 
  #          you might have to un-install the older gqrx 2.3.0 first
  cd /usr/src/redhat/RPMS
  sudo rpm -Uvh x86_64/gr-osmosdr-0.1.5-4.20160704git164a09fc.el6.x86_64.rpm \
x86_64/gr-osmosdr-devel-0.1.5-4.20160704git164a09fc.el6.x86_64.rpm \

42.j - Gqrx - An easy to use RTL compatible SDR application

Gqrx is an excellent, easy to use SDR program using GnuRadio on the backend, supports
various SDR hardware including RTL and FunCube dongles, AirSpy, SDRPlay, Ettus Research 
USRP and other OSMO SDR supported hardware devices.  Gqrx supports several demodulators 
including SSB, AM, narrow and wideband amateur FM, broadcast FM, CW, and also has various 
configurable filters.  It also has a built-in AFSK-1200 packet decoder but also supports
sending decoded signals over a TCP connection for superior tools like Direwolf and Fldigi!  
Gqrx supports zooming in on both the IQ waterfall and the decoded audio waterfall, bookmarks, 
recording the IQ and demodulated signals, etc!
This is the main window that shows the maximum bandwidth being captured:

This is the same main window that shows a zoomed in view of the FFT waterfall:

This is the AFSK1200 packet decode window when listening to the US APRS channel:

A few important notes:
   1. If you jumped to this section hoping to install Gqrx without much fuss..
      sorry, it's not that simple.  You *MUST* go back to the "42b.gnuradio"
      section above and install **all** of the other required dependencies including:

           boost, cmake (newest version), gr-osmosdr, and the support section for 
           say a AirSpy or SDRplay or rtl-sdr hardware device first

   2. The underlying GnuRadio code changes a LOT which requires Gqrx to update it's 
      code as well.  The way the code is written, Gqrx will only support the newest 
      GnuRadio code and it WON'T work with any older code.  What this means is that 
      if you want to load a newer version of Gqrx, it typically means you'll have 
      to also upgrade *all of GnuRadio*, all of gr-osmosdr, etc.  It's a real pain 
      but I promise you it's worth it!

Current versions of Gqrx require the following:

  - GnuRadio 3.7 (this documentation set will install 

  - Gqrx 2.6 require at least Qt 5.0 (this documentation set will install Qt 5.6.1 onto Centos6)
     - Gqrx 2.53 required at least Qt 4.7 (this documentation set will install Qt 4.8 onto Centos6

  - cmake 3.2.0 or newer (seems to work ok with Cmake 2.8.x as installed with this doc set)

  - If you want to fully leverage the Airspy R2 HW, you need gr-osmosdr 1.5.0GIT 
    built as of feb 28, 2016

Legacy GQRX code
   GQRX v2.1 - gqrx v2.1.148 will compile and run on the stock Centos6 qt-4.4 
         libraries which are available from the main Centos6 repos.  Unfortunately 
         there are several big bugs in this version of Gqrx that are fixed in newer 

         The GIT repository for Gqrx 2.5.3 also has several fixes and improvements but 
         it requires qt4.7+ (or optionally Qt5) to compile.  The GQRX documentation 
         will take you though both options depending on what you want to do.  
         I recommend to go the Qt 4.8 route as the newer features in Gqrx 
         are worth it.  The newest Gqrx versions also have minimum versions
         on gnuradio and gr-osmosdr as well.

42.j1 - Gqrx - Installing final Gqrx dependencies

Ok, as usually, time to fill some dependencies:

    # Some specific build tools required
    yum install cmake cppunit-devel

Qt-5.x GUI framework
As of Gqrx 2.6, it now *requires* the Qt 5.x framework.  In the past, this wasn't available
on Centos6 in any of the binary RPM repos but it now is.  Fortunately, you can install Qt5.x 
along side any other versions of Qt so there shouldn't be any conflicts.  So let's install it:

   sudo yum install qt5

   #Potential install
   #Qt5.6.1 comes from EPEL - 46MB installed
   sudo yum install qt5-qtbase.x86_64 qt5-qtbase-common.noarch qt5-qtbase-devel.x86_64 qt5-qtbase-gui.x86_64 qt5-qtx11extras.x86_64 qt5-qtx11extras-devel.x86_64 qt5-qtsvg.x86_64

Please skip to the next sub-section to keep going...

DEPRECATED - Building Qt-4.8 for Centos6

   | NOTE:                                                                                |
   | -----                                                                                |
   | This section shouldn't be required now as Qt5 is now available from Binary repos and |
   | Gqrx now requires Qt5.  This section is being kept around for now for any users      |
   | looking to only use Gqrx 2.5.3 or older                                              |

    Ok, let's install qt-4.8 - current as of May, 2013
    #To build Qt, we first need the following:
    yum install unixODBC-devel libicu-devel NetworkManager-devel libXv-devel \

    cd /usr/src/redhat/SRPMS

    #NOTE: the Qt 4.8 SRPM is a 236MB download
    wget http://download.fedoraproject.org/pub/fedora/linux/updates/17/SRPMS/qt-4.8.4-14.fc17.src.rpm
    rpm -ivh qt-4.8.4-17.fc17.src.rpm

    Edit the qt.spec file
    Find the line:

       BuildRequires: libtiff-devel

         and after it, add the line:
       BuildRequires: libicu-devel

    Next, find the line:

       BuildRequires: pkgconfig(icu-i18n)

         and replace with

       BuildRequires: pkgconfig(icu)

    # Ok, time to build it:
    #    This will take a while!
    #  Do NOT build this as root
    rpmbuild -bb --target=x86_64 qt.spec

    # Ok, time to install it 
    #   To be clear.. we are NOT upgrading our Centos6 Qt4 install. Qt allow multiple 
    #   versions to be installed simultaneously so we are installing along side the stock
    #   qt-4.6.2 version
    #  Do this as ROOT
    sudo rpm -ivh --force qt-4.8.4-14.el6.x86_64.rpm qt-x11-4.8.4-14.el6.x86_64.rpm qt-devel-4.8.4-14.el6.x86_64.rpm

42.j2 - Gqrx - Compiling Gqrx

On to Compiling Gqrx

    It should be noted that the releases on the SourceForge site are rather old compared to the Git 
    repository.  As such, I recommend to use the GIT repository even if you want to download the 
    stable releases.  

    #  First, let's get a template Gqrx spec file (if you don't already have one)
    #    http://rpm.pbone.net/index.php3
    cd /usr/src/redhat/SRPMS
    wget ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/sotrudnik%3A/branches%3A/home%3A/dl8fcl/Fedora_18/src/gqrx-2.1_git20130708-5.2.src.rpm
    rpm ivh gqrx-2.1_git20130708-5.2.src.rpm

    #Next, let's setup Git to get the sources
    cd /usr/src/redhat/BUILD
    mkdir gqrx-git
    cd gqrx-git
    #Get the sour code:
    #   1. If this is the first time running this, use:

           git clone https://github.com/csete/gqrx.git gqrx.git
    #   or
    #   2. If you are refreshing an existing download of the Git repo

          git pull

    cd gqrx.git

    #See what tags are available and decide on which version you want to use
    git tag

    | Which version to use?                                                |
    |                                                                      |
    | Now you need to decide if you want to run the last stable release as |
    | shown above in the tags or run the newest code available in Git.     |
    | The velosity of new Gqrx releases has slowed down quite a bit in     |
    | recent times so I would recommend to go with NEWEST CODE if you're   |
    | willing to get newer features.  If you want stable, use a tagged     |
    | version.                                                             |
    # Want the newest code available (tip of tree)?
    git checkout master


    # the newest stable is v2.6 so let's check it out
    git checkout tags/v2.6

    #If using a release version, you should show see something like:
    # --
    #    Note: checking out 'tags/v2.6'.
    #    You are in 'detached HEAD' state. You can look around, make experimental
    #    changes and commit them, and you can discard any commits you make in this
    #    state without impacting any branches by performing another checkout.
    #    If you want to create a new branch to retain commits you create, you may
    #    do so (now or later) by using -b with the checkout command again. Example:
    #      git checkout -b new_branch_name
    #    HEAD is now at 7956056... Update version strings to 2.6
    # --

    # Determine and write down the GIT commit serial number with the command
       cat .git/logs/HEAD | grep checkout
    #   For v2.6, it's the second large "checkout" number from the left: 
    #         79560565d9f36b17bc01130c49b2f69350ede2ee

    #   For the tip of tree, you want the second large git hash number from the left:
    #         31a2289f5775e5b09d7f954ee1ece3f581050c2c

    #   For 2.5.3, it's the second large "checkout" number from the left: 
    #         8bbe051d7983187fe8958c63e1e2cc6f483427e7

    # Ok, time to make the archive where the name consists of the package name, version, date and 
    #  the GIT short commit which is the first 8 characters (MSB) of the git commit code.  
    #  To build the 2.6 code, you would need to do:
    cd ..
    ln -s gqrx.git gqrx-2.6
    # Change the version, year, month, date, and 8 left-most digital of the Git checkout (MSB)
    tar civf /usr/src/redhat/SOURCES/gqrx-2.6-20160811git79560565.tar.bz2 gqrx-2.6/*  --exclude gqrx-2.6/.git
    #Optionally , delete this temp directory unless you want to keep it around to do quicker upgrades in the future
    cd ..
    rm -Rf gqrx-git

    Please skip to the next sub-section to keep going...

       #  ALTERNATIVELY:  To build the older stable tagged release, I would need to do:
       cd ..
       ln -s gqrx.git gqrx-2.5.3
       # Change the version, year, month, date, and 8 left-most digital of the Git checkout (MSB)
       tar civf /usr/src/redhat/SOURCES/gqrx-2.5.3-20160307git8bbe051d.tar.bz2 gqrx-2.5.3/*  --exclude gqrx-2.5.3/.git
       #Optionally , delete this temp directory unless you want to keep it around to do quicker upgrades in the future
       cd ..
       rm -Rf gqrx-git

    #Now you have to change a few things in the GQRX spec file:
    cd /usr/src/redhat/SPECS
    vim gqrx.spec
    Add the following lines to the TOP of the spec file, updating the various fields as needed regardless of using the 
    TIP of tree code in Git vs a tagged stable release - I'm showing the 2.6 stable release):

         %global git_commit 79560565d9f36b17bc01130c49b2f69350ede2ee
         %global git_date 20161006

         %global git_short_commit %(echo %{git_commit} | cut -c -8)
         %global git_suffix %{git_date}git%{git_short_commit}

         # git clone https://github.com/csete/gqrx.git gqrx.git
         # cd %%{name}
         # git archive --format=tar --prefix=%%{name}-%%{version}/ %%{git_commit} | \
         # bzip2 > ../%%{name}-%%{version}-%%{git_suffix}.tar.bz2

      Next, edit the gqrx.spec file and fill in the blanks for your checkout.  For me, I have:
       1. Update the top git_commit line: 
       2. Update the GIT date:            

       3. Update the Version:             

       4. Update the Release to:          

       5. Update the Source line to:
               Source0:        %{name}-%{version}-%{git_suffix}.tar.bz2

       6. Update the BuildRequires lines:
               BuildRequires:  gnuradio-devel >= 3.7.0
               BuildRequires:  gr-osmosdr >= 0.1.5
               BuildRequires:  qt5-qtbase-devel >= 5.0.0

       6. In the %build section, add a new first line that has:
               export QTDIR="/usr/lib64/qt5"
               qmake-qt5 gqrx.pro

    | NOTE:                                                                                     |
    | -----                                                                                     |
    |   There are various compile time options available in Gqrx via the gqrx.pro file such as  |
    |   the following.  To enable the item, it will require the line to be un-#ed out           |
    |                                                                                           |
    |      - AUDIO_BACKEND=portaudio     Use portaudio backend                                  |
    |      - CONFIG+=debug               Enable debug mode                                      |
    |      - PREFIX=/some/prefix         Installation prefix                                    |
    |      - BOOST_SUFFIX=-mt       To link against libboost-xyz-mt (needed for pybombs)        |
    |                                                                                           |
    |   To enable any of these options, I recommend to use a patch in the RPM Spec file.        |
    |   If you have any issues with this, email me and I can give you a hand.                   |

    # Ok, time to build it
    #   NOTE: this takes 2min to build on my dual core i5 2430M @ 2.4ghz laptop with 
    #         4GB of RAM and a Samsung SSD  
    #  Do NOT run this as root
    cd /usr/src/redhat/SPECS

    #  Gqrx 2.6   with Qt-5.6.1 build time: 5 min 08 seconds on a dual core i5-2420 2.4Ghz laptop with 4GB RAM and a SSD
    #  Gqrx 2.5.3 with Qt-4.8.4 build time: 1 min 49 seconds on a dual core i5-2420 2.4Ghz laptop with 4GB RAM and a SSD
    time rpmbuild -bb --target=x86_64 gqrx.spec

    # Finally, install it
    #  DO this as root
    sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/gqrx-2.6-1.20161006git79560565.el6.x86_64.rpm

Skip to the next section on some thoughts on HOW to use Gqrx.

Legacy / Deprecated Gqrx 2.1.x Section: 

   | NOTE:                                                                                 |
   | -----                                                                                 |
   | I'm keeping this these older Gqrx 2.1 x notes here for any users that might find it   |
   | valuable when running on a stock Centos6 install (no EPEL repo, no local compiling of |
   | of Qt-4.8.x, etc.                                                                     |

   Older Gqrx 2.1.x version that works with Centos 6.4's stock qt-4.6 libraries:

     #   NOTE: You *must* use this older version of Gqrx (which has many known bugs)
     cd /usr/src/redhat/SOURCES
     wget http://downloads.sourceforge.net/project/gqrx/2.1.148/gqrx-2.1.148-src.tar.xz
     cd /usr/src/redhat/BUILD
     tar xvf ../SOURCES/gqrx-2.1.148-src.tar.xz

     #Apply gqrx-2.1.148-midbutton.patch 

     export QTDIR="/usr/lib64/qt4"
     cd gqrx-master
     /usr/lib64/qt4/bin/qmake gqrx.pro
     End Deprecated Section: 

42.j3 - Using Gqrx

Gqrx is one of the easiest to use SDR receiver programs out there for any operating 
system.  It does have a few quirks on how to use it so lets try to address some of
those issues here.  When you first load the Gqrx program, you'll need to configure it 
for your specific hardware.  

This section will try to address the following hardware:

   - AirSpy v2 (with and without the HF upconverter)
   - RTL dongle (Terratec Tstick+) or equivalent

    # Ok, it's installed!  To run gqrx, run it as a regular user (don't be root):

Let's start with the Airspy r2 and Airspy Mini:
This is the Configure I/O window that shows the various settings:

  NOTE:  About 70% of the time when I first start Gqrx (not as root user) and look
         at the Gqrx configuration area, I don't see the "AirSpy AIRSPY" device
         (displayed exactly like that) device name in the pulldown.  You may also 
         see this after you initially start Gqrx and select the HW device to use. 
         If you go back into the menus to see the HW device, you'll no longer see it.   
         I discussed this with Alex OZ9AEC and it seems Gqrx depends on the underlying 
         GnuRadio system to discover the various devices.  Sometimes it's discovery 
         process isn't very reliable after it runs once.  it doesn't mean the hardware 
         isn't found or not working.  It's more of a display bug.  If you start 
         Gqrx with the "-r" (restart configuration) knob, the Airspy should always
         show up.

          - Be sure you ran the Airspy tests from the previous Airspy section to 
            make sure the unit is properly detected, your system handle the full
            sampling rates, etc.

          - The Airspy SDR when used under say SDR# has several Gain modes to choose 
            from.  Evidently these are shortcuts to set the three existing gains 
            (LNA/MIX/IF) according to a predefined table in the Airspy GROSMOSDR driver 
            depending on your use case.

               Sensitivity  : airspy_set_sensitivity_gain
               Linearity    : airspy_set_linearity_gain
               Free (Custom):  


            If you do want to change the gain mode, you need change this with

          - Device String:  Type in this specific string to use the first airspy 
                            and DISABLE the Spyverter (Spyverter MUST be disconnected
                            and removed to allow VHF+ signals to reach the Airspy)


                 - You would change the above "bias=0" to "bias=1" to enable the Airspy
                   sdr device to internally power the external SpyVerter upconverter

                 - If you do connect and enable the Spyverter, you must also change 
                   the "LNB LO" setting on the Gqrx to -120.000000 MHz  (yes, that's 
                   negative 120Mhz) to get the display to show the correct HF

          - Input rate: This is the sampling rate of the AirSpy hardware.  The R2 natives
                        supports 2.5Mhz or 10.0Mhz.   To set it to 10MHz set the value to:

              If you find your system stutters at 10Mhz, you can either try running at
              2.5Mhz or on the above Device string field, you can add the following
              (don't forget the comma):

                - As of Feb 28, 2016, the gr-osmosdr program now supports the Airspy
                  "pack" USB data stream packing feature.  Per the notes for this feature:

                      25% less data is transferred across the bus and this is good for some 
                      computers with cheap USB chipsets

                  Once you add this configuration parameter, I've found you will have to 
                  SHUTDOWN Gqrx and restart it for it to activate.

                  This packing feature is valuable on some computers where their USB chipset 
                  cannot keep up with the 10MSPS rate without it.  As mentioned in the above 
                  Airspy section, this packing feature WILL create substantially more CPU
                  load which can create other issues (without packing, I see a load of 4.15
                  but with it, I see a load of 6.00).  This packing feature is ONLY available 
                  if you have gr-osmosdr 1.5.0GIT version dated 2/28/16 or newer.
          - Decimation: Think of decimation as a form of signal ZOOM.  If you set it to
                        2, you'll see half the signal as you did before but the processing
                        on the remaining signals will significantly improve

          - Bandwidth: Leave this at the default of 2.5Mhz

          - LNB LO:    Leave this at the default of 0.0Mhz unless you're going to use
                       an HF upconverter.  If you have the airspy SpyVerter, you 
                       would want to enable the "bias" parameter in the device string
                       as described above and then put in a NEGATIVE 120Mhz or

      - RTL Dongle

            - No specific options added as of yet -- it just works

  - Once Gqrx is configured, click on the "power button" icon in Gqrx's upper left hand 
    window corner to have it start the sampling and decoding:

  - To change frequencies: 

       - You can either move the mouse pointer over the upper left corner VFO 
         frequencies and use the mouse wheel

       - You can click on any signal in the upper FFT or lower waterfall areas

       - If you move the mouse cursor over the RED decoder line in the main FFT 
         window, you'll see it will change to a LEFT-RIGHT cursor

           - If you move the mouse wheel here, it will slowly change the decode 

  - To zoom in on a frequency

       - Move the mouse to the bottom of the FFT area where all the frequencies
         are listed and the mouse pointer will change into a "hand".  Now use
         the mouse wheel to zoom in/out

  - To change filter bandwidths:

       - If you move the mouse cursor over the RED decoder line in the main FFT 
         window, you'll see it will change to a LEFT-RIGHT cursor and if you hold 
         down the Control key and move the mouse wheel, it will slowly change the 
         decode filter bandwidth.  

         You can also move the mouse to the transition from light grey / dark grey 
         where the cursor will change to a diagonal window.  If you hold down on 
         the LEFT mouse button and move left/right, it will also change the filter

  - To zoom into a set of spectrum:
       - In the top water fall, you need to move the mouse icon to the LEFT or RIGHT
         of the master decoder line in RED to and then use the center mouse wheel

  - It's important to calibrate your SDR dongle for proper reception.  The easiest 
    way I've seen to get started is to:

      1. power up our dongle for at LEAST 2hrs.  If you want maximum stability, 
         it must be completely warmed up.  Temperature variations can really impact
         SDR's oscillators (even units that have TXCOs)

      2. Tune your SDR (assuming an RTL dongle) to one of your local NOAA weather 
         stations (see below for a local frequency):


      3. Zoom in on the spectrum in the main waterfall until you can see the strait lines
         when the automated voice isn't talking

      4. In the upper right window, click on the "Input Control" tab and increase/decrease
         the "freq. correction" until the receiver is right on the expected frequency

42.j4 - Troubleshooting Gqrx Performance issues

   Troubleshooting performance issues with Gqrx:

     - Did you run the volk_profile command as yourself while the machine isn't used?

     - In the upper right corner's GUI section, click the "FFT Settings" tab and
       reduce the "AFFT size" to say 131072 or lower.  

     - Consider lowering the frame rate to say "15" frames per second or lower to
       start off with

     - Are you sure your machine is fast enough?  It's one thing to support a narrow
       bandwidth from a SoftRock for say 48, 96, or even 192Khz but it's entirely
       something else to support 2.5Mhz from an RTL dongle or say 10Mhz from an

42.k - LinRad - a powerful rtl compatible sdr application

Linrad is considered to be one of the strongest SDR applications out there for 
weak signal uses which is supported on both Linux and Windows.  Though originally 
developed with weak-signal modes in mind, it also focuses on the highest sensitivity,
supports full calibration, etc.  

  Caveat:  Linrad's user interface was originally designed via the legacy SVGA graphics
           library and follows NO modern UI conventions.  It's probably one of the most 
           cumbersome UIs I've ever used but once you learn it's UI, I can see how it could
           be very efficient and powerful.

  Ok, some dependencies:
  yum install libudev-devel
  yum install svgalib-devel

  # Ok, time to get the sources and compile it
  cd /usr/src/redhat/SOURCES
  wget http://www.sm5bsz.com/linuxdsp/archive/lir03-48.tbz

  wget http://dg7gt.osth.de/openSUSE_10.3/src/linrad-02.47-4.1.src.rpm
  wget http://download.opensuse.org/repositories/hamradio/openSUSE_Tumbleweed/src/linrad-03.48-1.1.src.rpm

  make xlinrad64

   TODO: Make this into an RPM:

Ok, you've compiled it up.  Here is a quick intro on how to get it working with 
an RTL dongle:
Go ahead and start the program:
sudo pasuspender -- ./xlinrad64

The following are prompts captured from the setup of Linrad:

   This message is not an error, but an indication that setup
   has not yet been done.

   Setup file par_userint missing.
   Use W to create a new par_userint file after setup.

   Note that the following keys have a special meaning in Linrad:
   ESC = terminate Linrad
    X  = Skip whatever process you are in and get one level
         upwards in Linrads menu three.
    G  = Make a .gif file with a screen dump of your current screen.

    -----------  GLOBAL PARAMETERS SETUP -------------
        (You might want to edit par_userint instead)
   Press N for NEWCOMER mode.
   Press S for normal mode.
   Press E for expert mode.
   Then press enter


   Percentage of screen width to use(25 to 100):

   Percentage of screen height to use (25 to 100):
   Option A - Input card
     Option H - RTL 2832
     device 0 - Terratec
     Sampling Speed: 2400000  
     Gain mode: 0 - Auto

   Option B - Output card
     Use PortAudio (recommended) - Y
     Device: 000 (my built-in computers soundcard)

   Option X - Exit to Main Menu
   Option W - Save configuration

42.l - RTLSDR-Airband: Multi-slice SDR demodulator for up to 8 simultaneous audio streams

RTLSDR-Airband is a command line receive-only SDR program similar to say the common "rtl_fm" program which 
will only decode one frequency at any one time.  This program can demodulate FM or AM signals for a maximum 
of EIGHT frequencies simultaneously!  It also offers:

   - Supports per-slice squelch on each of the listening frequencies
   - Supports a scanner mode so it can listen to more frequencies then are available in the SDR's 
   - Can send the demodulated audio to a PulseAudio server for various routing (on or offbox)
   - Can record squelched or non-squelched audio to MP3 files
   - Can mix different channels into other channels
   - On the Raspberry Pi, it can offload the FFT processing to the GPU to minimize CPU load
   - Uses the SoapySDR API to support a large variety of hardware beyond just RTL SDR dongles

That's all well and good but what's the purpose here?  

Imagine with one $20 RTL dongle and one antenna, you can pair it up with one copy of the Direwolf
soft-tnc program and monitor SIX packet frequencies at the same time!  My plan here is to monitor:

   144.390 - common APRS frequency
   144.910 - common EmComm packet frequency
   145.050 - common keyboard to keyboard packet frequency
   145.630 - common Winlink frequency

To get started, we need to install some dependencies:

   #This section already assumes you've installed all the previous build tools from previous
   #sections including GCC, make, etc, 

     #Lame is the MP3 encoder software
     #Libshout is to support Shoutcast - Centos6 seems to only support libshout2
     sudo yum install lame-libs lame-devel libshout libshout-devel libvorbis libvorbis-devel libconfig fftw-devel

For the moment, let's get things working with an inexpensive RTL dongle using the previously built 
"rtl-sdr" and "rtl-sdr-devel".  This was all done in a previous section of this doc.  Let's get 

   #Get the sources
   cd /usr/src/redhat/SOURCES
   wget -O RTLSDR-Airband-3.0.1.tar.gz https://github.com/szpajder/RTLSDR-Airband/archive/v3.0.1.tar.gz

   #Get the SPEC file
   cd /usr/src/redhat/SPECS


   STOP:  Currently seeing the following compile error which might require FFTW v3.3.x but Centos6
          only has v3.2.1

  build requires:

  apply makefile diff



nc -lup XXXX | direwolf

42.m - RTL_433 : ISM band protocol decoder utility

   | This section is a Work in Progress |

The rtl_433 is a tool that either natively uses an RTL SDR dongle or Soapy APIs to support higher
quality SDRs to listen to various ISM RF spectrums.  Once listening it offers over 153 protocol decoders
as well as tooling to reverse engineer other signals.

To get started, lets download the current code in the "master" branch:

   Make sure you have the required dependency packages installed (installation covered in other chapters
   in this document:

      rpm -qa | grep -e "libtool" -e "libusbx-devel" -e "rtl-sdr-devel" -e "rtl-sdr" -e "cmake"

      if you wish to include Soapy support, it must be version 0.6 or newer

   cd /usr/src/redhat/SOURCES
   wget https://github.com/merbanan/rtl_433/archive/master.zip

   cd /usr/src/redhat/BUILD
   unzip /usr/src/redhat/SOURCES/master.zip
   cd rtl_433-master

   # patch it
        patch -p0 < /usr/src/redhat/SOURCES/rtl_433-centos6.patch

   - Build things the Cmake way:

      mkdir build
      cd build
      cmake ..
      make -j4

      #Package it and install it

42.z - Noting other SDR Applications for Linux (GHPSDR, SDR-J, SDR#)

Here are a few other SDR programs I"m aware of for Linux:

    Ghpsdr or ghpsdr-alex aka "qt-radio"
    A three-module approach to SDRs where there is a receiver module (supports both local 
    hardware or remote hardware via the Internet/TCPIP, a demodulator module, and a local

      ---> NOTE: ghpsdr requires QT5 which doesn't exist on Centos6 and compiling might
              be difficult and it's unclear if it can co-exist with Qt-4.


    SDR-J - A Java based SDR program

    SDR# - Windows based SDR that can be run under Mono
    This SDR program is considered one of the best both in terms of UI, configurability, etc.
    It also supports plugins which includes support for the following as of May 2013:
           - analog/digital trunking systems
           - satellite Doppler correction
           - frequency memories / scanner mode
           - ADSB aircraft information decoding

    Unfortunately C# is written in C# for Windows but it evidently can run under the 
    Mono framework but it can require some serious CPU cycles:


43. - SVXlink and Qtel - Echolink client and server - Ham Radio and VoIP over the Internet

Echolink, IRLP, and Allstar are Voice over IP (VoIP) technologies which let 
you link and send amateur radio audio over the Internet to remote stations.  These
remote stations can be other individual stations (just a computer), a repeater, or 
be an entire collection of repeaters grouped together (called a reflectors).  

Please see the next section on "Using Echolink and IRLP via radio and Svxlink/Qtel" 
for more details.

Back to the topic at hand, SVXLink is a suite of tools that provides:

   - An Echolink server to turn your station into an Echolink "link" or 
     "repeater" depending on the configuration.  This is a background daemon
   - Qtel: An Echolink GUI client that has similar functionality to the Windows
     Echolink client
   - The Svxlink server also has a lot of expandable features such as:
      - Local voice playback for voice quality testing
      - Local voicemail recording and playback
      - Announcements of Weather reports, etc
      - Full blown repeater controller functionality including multiple RF and
        Internet-linked receivers and transmitters if you really want to

With all that functionality, you can have your system act as:

  - A pure software-only Echolink client :: No radio required

  - A Echolink simplex repeater          :: 1 radio required

  - A Echolink full repeater             :: 1 ore more full duplex radios required
                                            but additional radios are supported 
                                            for full linking, etc

A note on real radio connections:
     - When connecting the computer to a radio, you're going to need:

            - A dedicated sound card to support the audio in/out with your radio.
              Those cheap $5 USB soundcard on Ebay seem to work quite nice but you can 
              also use HAM radio targeted soundcards like US Interface Navigators, 
              Signalinks, but that overkill for this use

            - Depending on the sound interface you pick, you will need a PTT 
              circuit that connects to a serial port or GPIO pin to key up the 
              radio.  An example simple circuit was previously described in the 
              "Soundmodem - Sound-card based AX.25 packet TNC" chapter.  

            - More sophisticated and reliable Echolink setups use the COS or Carrier 
              Operated Squelch feature.  This signal tells the software that the 
              radio's squelch is open, possibly with the proper CTCSS/DCS tones and 
              to start sending to the remote stations even when there might not be 
              any audio present.  This feature can be a LOT nicer and offer more natural
              operation than using Svxlink's VOX feature.   To support COS, you might 
              need to hack this into your legacy radio or use radios like the Kenwood
              v71 or D710 which has COS built in (Echolink mode).  To support COS, 
              you will need another serial line or GPIO pin to track this status.

     - If you are going to have multiple sound cards in your computer, you'll want 
       to configure your system to have consistent ALSA device enumeration upon
       reboot.  Please see the "PreSetup: ALSA deterministic sound cards" section 
       for more details.

43.a - SVXlink and Qtel - Compiling and packaging the application

It's worth mentioning that a lot has changed with Svxlink since my last revision 
of this section.  The Svxlink project:

   -  Moved from SourceForge to Github (the email lists remain on sf.net)
   -  Moved from SVN to GIT
   -  Moved from Autoconf to Cmake

As such, this section is quite a bit different than the old version.  Anyway, let's 
get started.   First, let's get and compile the code but let's talk about the different
repo versions real quick:

   "Maint" GIT branch: Similar to Releases, this code is considered stable but
      RECOMMENDED      it DOES include some additional fixes and well understood

   Releases: The main releases found at https://github.com/sm0svx/svxlink/tags
             are stable releases.  They are considered reliable but might not 
             have all of the most recent fixes or bleeding edge features.

   "Master" GIT branch: This is the bleeding edge repository that is where all
                        active development occurs.  There is no guarantee that
                        this version of Svxlink compiles or runs properly

So with that in mind, we are going to use the "Maint" GIT branch here to get 
the best of both worlds.  What we need next is an RPM spec file:

RECOMMENDED:  You can simply get my Svxlink SPEC file from here and skip to the
------------  next section:

   cd /usr/src/redhat/SPECS
   cd /usr/src/redhat/SOURCES
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/svxlink-14.08-sms-patch.diff

NOT RECOMMENDED:  To manually re-create this above SPEC file, I used the following 
----------------  steps.  You can redo all of this work if you wish

    Fedora has a modern enough package that creates a reasonable foundation for an RPM
    spec file but it needs fixes.  Let's get started on getting and making those changes 

    # Get, install the Fedora SRPM dated from November 2011, and delete the 
    # old sources as we'll get newer ones
    cd /usr/src/redhat/SRPMS
    wget http://kojipkgs.fedoraproject.org//packages/svxlink/11.11.1/4.fc16/src/svxlink-11.11.1-4.fc16.src.rpm
    rpm -ivh /usr/src/redhat/SRPMS/svxlink-11.11.1-4.fc16.src.rpm
    rm -f /usr/src/redhat/SOURCES/svxlink-11.11.1.tar.gz

Regardless of which SPEC approach you chose above, we need to get a copy of the
Svxlink source code.  You can download either an official stable release, the 
"maint" GIT release, or the bleeding edge "master" code from the GIT repository.  

    #   GIT "maint" release (RECOMMENDED)
    #        In this example, I'm downloading the newest code as of 5/4/15:
    cd /usr/src/redhat/SOURCES
    wget https://github.com/sm0svx/svxlink/archive/maint.zip


    #   Main Release (NOT RECOMMENDED):
    #        Check out https://github.com/sm0svx/svxlink/tags to see what is the
    #        current release.  In this example, this will get the August 2014 
    #        (14.08) release which is good but is missing several important fixes
    #        that are only available in the GIT branch
    cd /usr/src/redhat/SOURCES
    wget https://github.com/sm0svx/svxlink/archive/14.08.tar.gz

Ok, next, we need the Svxlink "Heather?" audio prompt files as they aren't t 
included in the default archive.  Lets get those now:

    cd /usr/src/redhat/SOURCES
    wget https://github.com/sm0svx/svxlink-sounds-en_US-heather/releases/download/14.08/svxlink-sounds-en_US-heather-16k-13.12.tar.bz2

Now we need to clean things up a bit to make it fit into an expected RPM. 
    #  NOTE: For GIT users, I'm making up a new version number of 14.08.01 
    #        to reflect it's GIT based
    cd /usr/src/redhat/SOURCES
    unzip maint.zip
    #the 05 used here is to reflect the month of may
    mv svxlink-maint svxlink-14.08.05
    tar czvf svxlink-14.08.05.tar.gz svxlink-14.08.05/
    rm maint.zip 
    # Do not delete the temporary svxlink-14.08.01 directory just yet

Next, if you're using the recommended GIT approach mentioned above OR if you're 
using the STOCK Fedora based SPEC file, the newest Svxlink code contains version 
numbers that might need to be updated in your SPEC file.   As such, you'll need 
to update the SPEC file:

  If you're using the original Fedora SPEC file, that Fedora spec uses some package 
  names that are either incompatible with Centos6 or reference older version of 
  libraries that need to be updated and changed.  As such, you will need to update 
  those packages, the version of the code in the RPM, and fix a some specific spec 
  file issues. 

To properly update the spec file, first look at the various svxlink module versions 
specified in the src/versions file.  Write down the version numbers so you can 
update the svxlink-git-maint.spec file.  Please do NOT use the various ChangeLog 
files for version numbers as those version numbers are used for development ONLY 
and can change very quickly (and in incompatible ways).  If you are modifying the 
original Fedora SPEC file, you need to make the other changes mentioned below:


        - Run the command: less /usr/src/redhat/SOURCES/svxlink-14.08.05/src/versions
          and note down the newest version of the various modules.  For what I see, 
          on 5/4/15:

              libasync - 1.3.1
              echolib  - 1.3.1
              qtel     - 1.2.1
              svxlink  - 1.4.1  (this is svxlink-server)

        - Find the line that starts with this example:
            %define main_version 11.11.1

       and replace it with the date and month of the currently available Main 
       release.  In this example, I'm using 14.08 and I'm adding a ".01" at the
       end to represent it contains MORE than just he primary release:

            %define main_version 14.08.05


            Release:        4%{?dist}

       and replace it with

            Release:        1%{?dist}

   Next, update the Source0 line to read:

       Source1:        http://downloads.sourceforge.net/%{name}/svxlink-sounds-en_US-heather-16k-%{version}.tar.bz2

   # IGNORE this experimental patch for now - might not be required anymore
   #Next, under the Source0 line, add the line to include the optional SMS notification path:
   #Patch0:         svxlink-14.08-sms-patch.diff

Next, update the following line

         BuildRequires:  libsigc++-devel

    and replace it with:

         BuildRequires:  libsigc++20-devel

Next, add a new BuildRequires line to read:

    BuildRequires:  opus-devel >= 1.0.0

And also add a new Requires line:

    Requires:  vorbis-tools

# IGNORE this experimental patch for now - might not be required anymore
#Next, under the %prep section, add:
#    %setup
#    %patch0 -p0

Next, under the various sub-packages sections, update the version number
per the effort above:

    Epoch: 1
    Version: 1.3.1

    Epoch: 1
    Version: 1.3.1
    Requires: libasync = %{epoch}:1.3.1
    Obsoletes:      svxlink-server-devel < 1.4.0-1

    Epoch: 1
    Version: 1.3.1

    Version: 1.3.1
    Requires: echolib = %{epoch}:1.3.1
    Obsoletes:      svxlink-server-devel < 1.4.0-1

    Epoch: 1
    Version: 1.2.1

    %package -n svxlink-sounds
    Summary: Audio clips for Svxlink announcements
    Group: Applications/Communications
    Epoch: 1
    Version: 13.08

    %description -n svxlink-sounds
    This package contains the en_US-heather-16k generated sound clips for Svxlink
    server announcements, prompting, etc

    Epoch: 1
    Version: 1.4.1

Now save all those changes to the /usr/src/redhat/SPECS/svxlink-maint.spec file.  

Beyond these main items in the stock Fedora svxlink.spec, there are a LOT of 
other items that needs to be changed.  That's why I recommend to NOT use the
Fedora SPEC file and use mine.  Please refer to my svxlink-git-maint.spec file 
for the other details if you want to still update the Fedora SPEC file.


Now that you're done with the original svxlink-14.08.05 directory, let's remove it:

cd ..
rm -Rf /usr/src/redhat/SOURCES/svxlink-14.04.05

Now we need to install some dependencies before we can compile Svxlink:

    yum install libsigc++20-devel gsm-devel speex-devel opus opus-devel

# -----------------------------------------------------------------------------

Ok!  Finally, let's build Svxlink this for a Centos6 machine and install it:

    #Assuming you're using a 64bit machine:
    rpmbuild -bb --target=x86_64 svxlink-git-maint.spec

It's time to install all the resulting RPMs:

    cd /usr/src/redhat/RPMS/x86_64
    sudo rpm -Uvh libasync-1.3.1-1.el6.x86_64.rpm \
    echolib-1.3.1-1.el6.x86_64.rpm \
    qtel-1.2.1-1.el6.x86_64.rpm \
    svxlink-sounds-13.08-1.el6.x86_64.rpm \

(Optional) You can also install the developer and debug packages if you wish:
    rpm -Uvh libasync-devel-1.3.1-1.el6.x86_64.rpm \
    echolib-devel-1.3.1-1.el6.x86_64.rpm \

Upgrading from an older version of Svxlink to a newer version:
If you are upgrading from an older version of Svxlink, existing Svxlink configuration
files were already present.  You would then see messages like:

   warning: /etc/svxlink/svxlink.d/ModuleEchoLink.conf created as /etc/svxlink/svxlink.d/ModuleEchoLink.conf.rpmnew

When you see this, you should compare what's in the NEW configuration file vs. 
the old one to make sure you aren't missing any of the new functionality.  To
do this, use the command:

  diff -u /etc/svxlink/svxlink.d/ModuleEchoLink.conf /etc/svxlink/svxlink.d/ModuleEchoLink.conf.rpmnew | less

     - Any lines that start with a "-" are present in your original configuration file
     - Any lines that start with a "+" were added in the NEW configuration file
        It's these + lines you need to pay attention to

If you use my /usr/local/sbin/start-svxlink.sh script (mentioned below), 
you should compare the previous Svxlink config file vs. the new one that
was just installed:

    diff -u /etc/svxlink/svxlink-std.conf /etc/svxlink/svxlink.conf | less

     - Any lines that start with a "-" are present in your original configuration file
     - Any lines that start with a "+" were added in the NEW configuration file
        It's these + lines you need to pay attention to

43.b - Configuring the Svxlink server

Audio connections between the radio and the computer soundcard
This topic deserves some up front mention and I will also mention 
it before.  Specifically, it's recommended to provide electrical isolation 
between the radio and the computer but it's not strictly required.  
This "isolation" can come in several forms such as using audio transformers 
(one on input, the other on output), opto-couplers for the PTT line.  In addition 
to this, Echolink operation can benefit from an additional circuits tracking COS 
(Carrier Operated Squelch) for better operation compared to using VOX.  More 
feature packed isolation boards offer on-board dedicated DTMF decoders for better 
decoding under fader, flutter, etc.  

Here are some sound card interfaces to give you an idea of what's out there:

  - Inexpensive isolation only, requires a serial port for PTT:

  - Sound card isolation, COS detection, DTMF decode, requires a serial port for PTT:

  - Sound card isolation only, no-serial port PTT:

  - Additional options: http://www.echolink.org/interfaces.htm

For my specific setup, I'm using a Kenwood D710 that has specific support for Echolink
though it doesn't seem to have any audio isolation built in.  

Getting the required system details in place to start configuring Svxlink:

  - Be sure you configure the soundcard to be used by svxlink to always get the 
    same ALSA ID.  This is detailed in great detail in the previous 
    "PreSetup: ALSA deterministic sound cards" section.

  - Determine which ALSA device ID you're going to use (that previous section 
    will help you get that information)

  - Test that the soundcard that's going to be used for EL is working.  In
    my setup:

         # Play a sound:  connect up headphones to the output of the soundcard
         #                and make sure you can hear it
         #   NOTE:  When I first tried to use this sound device, it kept 
         #          giving me the error:  
         #               Channels count non available
         #          It seems this soundcard is a MONO *only* playback device so 
         #          I have to use the ALSA "plug" module to convert the
         #          stereo audio to a mono output that the soundcard would
         #          accept
         #   NOTE2: This example assumes ALSA ID #3.  You will need to change
         #          this ID to fit your environment
         aplay -D"plug:'hw:3,0'" /usr/share/sounds/alsa/Front_Right.wav

         # Record a sound (assumes you have a working microphone connected) 
         #   in 16bit mono 16Khz for 10 seconds:
         #   NOTE: This example assumes ALSA ID #3.  You will need to change
         #         this ID to fit your environment
         arecord -D"plug:'hw:3,0'" -c 1 -d 10 -r 16000 -f S16_LE /tmp/test.wav

         # play back the recorded audio to make sure it a) worked, b) you 
         # can hear it and the audio sounds reasonable:
         #   NOTE: This example assumes ALSA ID #3.  You will need to change
         #         this ID to fit your environment
         aplay -D"plug:'hw:3,0'" /tmp/test.wav

Svxlink Configuration:

  - Edit the /etc/svxlink/svxlink.conf file that comes with the RPM

      - For 64bit systems like mine, I needed to edit in the [Global] section,nd
        change the line from/to the following:




      - NOTE: This Hampacket Centos documentation doesn't touch on repeater use.
              As such, the "LOGICS" section defaults to "LOGICS=SimplexLogic" which 
              assumes your putting this system on a simplex frequency.  

      - (ONLY CHANGE if Required)
        As noted in the svxlink.conf manual page, Svxlink always internally works 
        with 8k samples from your soundcard and some older cards can natively 
        support 8k sampling but *very poorly*.  With modern soundcards, most of them 
        ONLY support 48k sampling.  To confirm what your sound card supports, run the 
        following commands:

             cat /proc/asound/cards

        Next, find your card from the output above and note the ALSA ID.  For my 
        card, it's ID #3.  Next, issue the command:

             cat /proc/asound/card3/stream0 | grep -i rates

        Here, you should see the available sampling rates for your card.  My CM109
        USB card *only* supports: 44100 and 48000.  This means that Svxlink will 
        always default to 44100 unless asked to support.

        To start off, leave this sampling setting alone and see if the audio quality
        is ok.  If the audio quality you hear or the remote site hears is poor, try 



      - If you plan on posting your location information into the Echolink and/or
        APRS systems, uncomment out the line:





      - Under the [SimplexLogic] section, change the lines from/to for the following:

        - Svxlink offers a lot of functionality via the MODULES feature.  Some of the
          other modules include:
              - local weather report from the local airport code
              - HF propagation reports
              - Selective call

          By default, Svxlink enables the following modules:


          If you don't want some of these features to be available, say the VoiceMail
          feature, remote them from this list

        - Change the CALLSIGN line to use your callsign but **do NOT include** say the 
          -L suffix for simplex operation:


        - You might want to change the callsign ID timers

           - SHORT: The default setting is 60min for the short ID (IDs every 60 minutes 
             when the link is active and there is a live QSO).  In the US, you
             need to have the machine ID every 10 minutes:


           - LONG: 60min for the long ID when the system is idle.  It's also used to 
             announce any waiting svxlink voicemails, etc.  If you want your system 
             to run "low and silent, setting this to 0 disables this feature.


           - If you only want your machine to ID if there has been activity on 
            the system, change the following line.  Please note that per the 
            svxlink.conf man page, the SHORT_IDENT_INTERVAL variable has to be
            greater than 0:




        - (OPTIONAL but recommended) - If you'd like to be able to RECORD any 
          signals on the radio frequency, you need to uncomment out (remove the 
          #s) from the line:


           - If you do enable this recorder feature, you have to make this 
             directory writable by the owner of svxlink process (shouldn't
             be root).  To fix that, do the following

                mkdir -p /var/spool/svxlink/qso_recorder
                chown svxlink /var/spool/svxlink/qso_recorder

           - This feature can only be enabled/disabled from the top menu
             and not when say the Echolink module is loaded


      - The editing of the [RepeaterLogic] section is not necessary as we aren't
        using it in this section but I feel it's best to make some minimal changes
        to stay consistent.  Please change the line from/to the following:

        - Change the CALLSIGN line to use your callsign but do NOT include the -L suffix:


        - Svxlink offers a lot of functionality via the MODULES feature.  By default,
          it enables:


          If you don't want some of these features to be available, say the 
          VoiceMail feature, remote them from this list


      - Under the [Macros] section, you can setup shortcuts to connect to do all
        kinds of common things.  For example, if you wanted to create a quick method
        to connect to my echolink node, you could enter in:



      - If you enabled the QsoRecorder function above, I recommend you enable
        the Ogg compression feature.  If you don't do this, all recordings will
        be saved in the WAV format which can create very large files in short

           ENCODER_CMD=/usr/bin/oggenc -Q \"%f\" && rm \"%f\"


      - Under the [Rx1] section, change the following to reflect your audio 


        For my setup, I'm using ALSA device #3 and thus needed:


        - VOX vs COS: 
          The current default for svxlink is to detect that SQL is open
          purely by hearing loud enough signals from the radio (VOX) via the setting:


          When the audio is loud enough, for long enough, the svxlink program 
          should show lines like:

            Rx1: The squelch is OPEN (1.56161)
            Rx1: The squelch is CLOSED (3.77363)

          Getting the VOX settings just right so it allows for natural human
          speak audio level, pauses, etc. can be pretty tricky.  

          If you are using an device that supports COS like the Kenwood D710, 
          your radio can actually signal when the Squelch opens with your 
          desired PL TONE.  This is a LOT more reliable and this is how most
          IRLP systems are setup too.  To support this, you would want to change 
          these settings to the following under the [Rx1] section:

              # for my specific setup, I use a custom Udev-named serial port

        - (optional) Support for external DTMF decoding available on some of the 
          above mentioned Isolation boards to improve DTMF decoding
          with weak signals, mobile flutter, etc..  I'm personally not using one 
          of these enabled DTMF-decoding boards so I set the following:


          and I commented out the line 





      - Under the [Tx1] section, change the following to reflect your 


        for me using ALSA device #3, I needed:


        - Next, you need to set Svxlink how to key your radio.  Solutions here
          can range from configuring VOX on your radio itself (NOT recommended even
          if your radio supports it) to the recommended approach of using an external 
          PTT circuit via one of above isolation boards.

          The D710 natively supports PTT via the RTS serial line (non-inverted).  
          So for my setup that I created a unique UDEV name for the D710's 
          serial port, use the following under the [Tx1] section:


          | ** Critical Issue:   Improper serial port shutdown with the D710 **          |
          |                                                                              |
          |      Please see below about a critical issue with the D710 and the RTS       |
          |      serial line when not properly shutdown!                                 |

        - (OPTIONAL) - Under the [LocationInfo] section, the system can locate
          your echolink station in the APRS system when it's running.  To
          enable this, make the following changes:

          - Being in the US, I should use the North America APRS server


          - Enable the Echolink status server by removing the #


          - Enter in your GPS coordinates.  It's CRITICAL that you enter in your
            GPS coordinates in Degrees, Minutes, Seconds (DMS) and *not* Decimal 
            format.  To help you remember, the DMS format cannot be greater than 
            "59.99".  If you don't use the right format, Svxlink will error out 
            and refuse to run.  

            To figure out your GPS location, see the "Xastir - Configuring" section 
            in this document in how to use GoogleMaps and then use another website 
            to convert to DMS.   For my setup, I configured: 

              # degrees.arcminutes.arcseconds where arc values cannot be greater than 
              # 59Degrees, Minutes, Seconds - like Delorme GPS - less accurate

            NOTE:  Negative LAT or LON numbers are not needed

          - Put in a callsign to be found as.  The example callsign uses
            something like EL-CALLSIGN which I've never seen before but
            Svxlink ONLY supports this syntax today.  If you try to use
            something like KI6ZHD-EL, it gives an error.  So, I'm using:


          - The following values will need to be updated to match your
            desired simplex frequency, radio power, antenna used, 
            it's installation height above average ground (HAAT), 
            if it's omni-directional, and if you're using TONE
            to key up your Echolink system.  

              | IMPORTANT NOTE on choosing the FREQUENCY: |
                     Here in the Bay Area, there can be a a lot of people who 
                     listen and hang out on simplex.  When picking a frequency 
                     to put your machine on, it's recommended to use the 
                     QSO_RECORDER feature (discussed below in a following section) 
                     with the your radio's tone-squelch (CT) turned OFF for a full 
                     *day or two* first.  Once you have confirmed, that your chosen 
                     simplex frequency isn't used much, then go ahead and set it 

                NOTE2: The use of CTCSS/DCS TONEs:  
                     If there are a LOT of echolink systems sitting on simplex
                     frequencies and if just one other machine in my RX area 
                     was using Svxlink with the same CTCSS/DCS tones, the 
                     remote person might actually start controlling both Svxlink 
                     nodes without realizing it!  The only way to better control 
                     this is via the use of CTCSS/PL TONEs or DCS codes on RX of
                     your radio.

                NOTE3: If you're using an ancient radio w/o CTCSS support,
                       Svxlink can actually support them in software.  That isn't
                       covered in this document but it's worth mentioning

            For me, I'm using the following details for frequency, noted power,
              COMMENT=KI6ZHD Echolink running svxlink.sourceforge.net

    - Change the /etc/svxlink/svxlink.conf file's permissions to 660 and it's
      ownership to a non-root user:

        chown -R $USER /etc/svxlink/

        chmod 660 /etc/svxlink/svxlink.conf

  - Edit the /etc/svxlink/svxlink.d/ModuleEchoLink.conf file

      Echolink Validation:
        At this point, this document assumes you have a validated Echolink 
        callsign for either a -L or -R node type.  The whole validation process
        for Echolink is covered in the next section so please skip ahead and
        then come back to here when you're ready.

      - This configuration file logs your system into the Internet facing
        Echolink system to accept and optionally originate VoIP sessions.  Make
        the following changes:

         - Change the following to reflect your callsign including the -L for
           simplex operation or -R for repeater operation:


         - Change the line to reflect your unique Echolink Sysop password:


         - One special note on the LOCATION field:  
           This line has specific formatting and can ONLY be **27 characters** 
           long.  The default setting is:

              LOCATION=[Svx] Fq, MyTown

           Below is what I set for my system to fit:

              #        123456789012345678901234567
              LOCATION=[Svx]146.595 pl~136.5 S.Bay

           BTW, keeping the "[Svx]" prefix text will allow other tools on the 
           Internet more easily detect your station in addition to enabling 
           Echolink and APRS geolocation.  For example, check out this URL to 
           see all the Svxlink-enabled systems on the Internet:


         - Go ahead and update the other Echolink fields as well.  For my setup, I used the


            DESCRIPTION="You have connected to a SvxLink node,\n"
                        "a voice services system for Linux with EchoLink\n"
                        "Check out http://svxlink.sf.net/ for more info\n"
                        "QTH:     Santa Clara, CA  USA\n"
                        "QRG:     Simplex link on 146.595 MHz\n"
                        "CTCSS:   136.5 Hz\n"
                        "Trx:     Kenwood D710\n"
                        "Antenna: Comet CX-333 triband omni at 25ft HAAT\n"

    Security Permissions

      | One CRITICAL, one Important permission fixes! | 

       CRITICAL:  As described below in the "Improper serial port shutdown with 
                  the D710" section, it's key that Svxlink program be able
                  to properly initialize the ALSA subsystem as a non-root user.
                  To allow for this in Centos6, edit the /etc/group file as the
                  root account and alter the "audio" group to look like:

       IMPORTANT:  It's important that your change the 
                   /etc/svxlink/svxlink.d/ModuleEchoLink.conf file's permissions 
                   to 660 so that people can't see your Echolink password:

                       chmod 660 /etc/svxlink/svxlink.d/ModuleEchoLink.conf

                       chown -R svxlink.daemon /etc/svxlink/
                       chown svxlink.daemon  /var/spool/svxlink/qso_recorder

43.c - Svxlink and enabling the Network / Port Forwarding

  Once you have Svxlink compiled, installed, and configured, it's required that
  the network be able to send packets to it.  It's really a large topic to cover
  as people's networks can be so different.  The highlights are:

    1. Most people have one, if not two or more "Internet routers" at home.
       The first will be a cablemodem / DSL router.  On that device, you need
       to get into it's configuration menus and look for "Port Forwarding".

         Important Note:  
         Some home routers offer both "Port Forwarding" and "Port Triggering" but:

           1) These aren't the same thing and it's critical that you pick the feature
              where you can specify the destination INTERNAL IP address to forward the
              ports to like to  If the feature doesn't have that destination
              option, it's not the right one.  Keep looking.

              Check out http://screenshots.portforward.com/ for a very comprehensive
              screen shot database of how to configure Port Forwarding on your specific

           2) Only configure one type of port forwarding mechanism at a time.  Do
              not configure say Port Forwarding and Port Triggering at the same
       In the configuration web menu / cli on the router device, you need to 
       configure the following INCOMING ports to be directed to the IP address 
       of your internal Svxlink server.  In this example, say this Internal 
       Svxlink machine would be  From the Internet, you'd 
       portforward INCOMING:

       As mentioned above, if your Svxlink machine is behind TWO network devices
       like a DSL router and a wireless router, you'll need to do this port forward
       TWICE (once on the ISP's modem and a second time on your Wireless router) to 
       successfully get the traffic to your Svxlink station.  

The official Echolink documentation has a
section on portforwarding that might be helpful to you. Give it a read.

       For completeness (but shouldn't be required except for the most strict 
       firewalls), Svxlink makes OUTGOING 5200/tcp connections to the Echolink 
       server.   Svxlink can also need INCOMING 5210/tcp if you're linking 
       multiple Svxlink systems using it's "remotetrx" feature.  If you're only
       using the Echolink support within Svxlink, this port 5210 is not needed. 

       Svxlink vs. Windows Echolink:
       It might be worth mentioning that Echolink 2.x for Windows and newer versions
       no longer require specific port forwarding but if you try to work remote 
       Echolink stations that ARE running Echolink 1.x, you will STILL NEED to 
       enable the port forwards.

43.d - Getting Svxlink to send SMS text messages upon connection/disconnection

Getting notifications when someone connects or makes a connection out of your Echolink node:
   By default, Svxlink does not have the ability to play any notification 
   sounds when someone connects to your Echolink node.  This is a bummer as 
   I was missing potential QSOs.  Svxlink is very extensible and I was
   able to modify it that when:

   When someone connects INTO or OUT OF my Echolink node, Svxlink

     - Play a sound file to the computer's local speakers

     - Send a SMS TXT message to my Verizon cell phone

   To support all this, do the following:

     - As the root user, make a copy of the key Echolink TCL file:

          mkdir /usr/share/svxlink/events.d/local
          cp /usr/share/svxlink/events.d/EchoLink.tcl /usr/share/svxlink/events.d/local
     - Edit the /usr/share/svxlink/events.d/local/Echolink.tcl file and in this 
       example, I'll add a notification to the "2#" Node Status command:

        - Below the line "variable num_connected_stations 0;", Add the following
          lines but substitute in the sound file and cellphone number you want:
          # These variable are for setting the external notification
          #   Assumes you have Mutt installed
          variable my_cell_number 4081111234;
          variable external_notif_sound /usr/share/sounds/kapman/life.ogg;

        - Now it's time to instrument the "2#" local ID feature section.
          Find the comment line that says:

             proc play_node_id {my_node_id} {

          Just under it, add the lines:

               variable external_notif_sound;
               variable my_cell_number;

          Finally, find he following lines:

                   playMsg "unknown";

          and append below them, the following lines:

                 exec /usr/bin/play -q $external_notif_sound &
                 exec echo "Svxlink: local ID status requested" | /usr/bin/mutt $my_cell_number@vtext.com &

   That's it.  Now go ahead and stop and then restart Svxlink.  From your second
   radio (HT, etc), load up the Svxlink Echolink module with a "2#" and then
   issue a local node ID command with "2#".  At this point, you should IMMEDIATELY
   hear the notification sound on your local computer and fairly quickly get an 
   SMS message!

43.e - Interfacing Svxlink with a Kenwood D710

Getting a radio setup with Svxlink:

    - Since I'm using a D710, I needed to do the following on the radio but
      if you're using a different radio, find and enable the similar settings:

       D710 Menus
         - Set the Transmit Timeout (TOT) to say 5min - Menu 109
           - If there is a system failure that leaves your radio keyed up
             for long periods of time (read below on the critical D710 
             serial port issue, you don't want to:

                A) burn out your radio's final TX amp!  
                B) break the FCC Part97 rules 

             You can set this to 3, 5, or 10minutes.  I recommend 5. 

             NOTE: I confirmed that the D710 does indeed stop transmitting
                   after say 5 minutes but it does NOT indicate that the
                   TOT timer is inhibiting TX!  Bummer.  You have to 
                   first stop whatever program from asserting the RTS serial
                   line and then the radio will start transmitting again.

         - Turn off Automatic Power Off (APO) - Menu 516
           - If the radio is idle for a long time, you don't want it to turn
             itself off

         - Set the External DATA band (external audio) to Band-B - Menu 517
           - Set so the packet/APRS TNC is on the left narrow receive VFO, 
             voice on the wider receive right VFO.

         - Set the detection of modulation to "SQL" from the default of 
           "BUSY or TX" - Menu 520 as recommended by the manual

         - Set the External DATA band to 1200 - menu 518
           - The DATA jack has separate pins for audio with the pre-emphasis 
             enabled on the 1200baud line and no emphasis on the 9600 baud
             line.  The Kenwood D710 "Echolink cables" only uses the
             1200baud lines.  Svxlink DOES have audio processing abilities to 
             re-create the pre-emphasis / de-emphasis effect if you want to 
             use the 9600baud line on other radios

       RX Frequency and Tone
         * As mentioned before, it's key to use a free frequency and a unique
           CTCSS/PL tone or DCS code to keep your system unique:

         - Set VFO-B to the desired frequency - I'm using 146.595

             IMPORTANT: Please read below on using the QSO_RECORDER feature
                        to make sure you're using a generally free frequency

         - Cycle the TONE button to display CT  (Tone Squelch)

         - Cycle the T.SEL button to use your desired tone. I'm using 136.5

         - Set the power level to the lowest setting available if you 
           plan on using Echolink locally (say in your home, etc)

         - RECOMMENDED: you should save all this into a unique memory to be
                        able recall all these settings quickly and accurately.  

         NOTE on D710 Rig Control in Echolink mode
         As previously mentioned, I have the D710 supporting Hamlib rig control 
         with the d710-qsy.sh script posted at:


         Unfortunately, this script will not function when the D710 is in Echolink 
         mode.  LAME!  Even out of Echolink mode, if the svxlink program is 
         running, it's takes over use of the "PC" serial port thus Hamlib cannot
         gain access to the serial port.  Bummer.  I will be researching if the use
         of the D710 *not* in Echolink mode is good enough but I'm pretty sure you
         loose the COS line which is rather helpful.

       Adjust internals of the radio for proper operation:

           D710 specific
           - The D710 is a very powerful dual band radio and one of it's unique 
             features is a specific Echolink mode changes some of it's settings.  
             To enable Echolink mode, you need to turn off the radio, hold down 
             the PF2 button (the last button on the right, closest to the VFO-A 

                  |     +--------------------------------------------+     |
                  |     |                                            |     |
                  | b.1 |          D   i   s   p   l   a  y          | pwr |
                  | b.2 |                                            | b.12|
                  | b.3 |                                            | b.11|
                  |     +--------------------------------------------+     |
                  |  /--\   btn  btn  btn  btn  btn  PF1  PF2      /-\ /-\ |
                  | /VFO \   4    5    6    7    8         ^       \A/ \B/ |
                  \ \    /                                 |               /

             and then turn on the radio back on.  You can confirm if the D710
             is in EL mode if there is a little icon in between the PM and TNC 
             display items on the far right side of the display.  Once in EL mode
             *and* when a remote station is heard, the audio will be send to 
             the computer but only if the matching CTCSS/DCS codes match will
             the COS line also open up and the Echolink icon will blink.

             - What else is Echolink mode?   Per the "TM-D710-CDROM-English.pdf"
               file (Echolink section page 23) and from what I have determined,
               EL mode only does two things:

                   a. It uses alternative audio levels for the audio "DATA"
                      jack on the rear of the radio unit as programed in via 
                      Kenwood MCP-2A Windows program compared to the 
                      default "external TNC" levels

                   b. It changes the behavior of the RTS/CTS lines on 
                      the PC port on the back of the radio unit from
                      standard RS232 signals to:

                         CTS line : TTL level : changes upon SQL and CTCSS open/close
                         RTS line : TTL level : changes used to key up the radio

          | ** Critical Issue:   Improper serial port shutdown with the D710 **          |
          |                                                                              |
          |     I consider it a major flaw that Kenwood connected the PTT                |
          |     line to the RTS line.  Why?                                              |
          |                                                                              |
          |     Almost all programs that use serial port (including Svxlink) will        |
          |     first initialize the serial port and assert the RTS line as part         |
          |     of standard hardware flow control.  It's the right thing to do per the   |
          |     standard.  Unfortunately since Kenwood chose to use this specific        |
          |     serial line for PTT when in Echolink mode, that means the D710 will key  |
          |     up the PTT and start transmitting!  What's worse is that when these      |
          |     serial programs exit, almost all will leave the serial port              |
          |     initialized (RTS will still be high and PTT is still asserted on the     |
          |     D710 and will continue transmitting **FOREVER**.                         |
          |                                                                              |
          |     This EXACT issue happens with Svxlink if Svxlink doesn't have the right  |
          |     ALSA audio subsystem /dev/snd/* permissions!  Svxlink will initialize    |
          |     the serial port, fail to initialize the ALSA system because in Centos6,  |
          |     the "audio" group in /etc/group doesn't have the "svxlink" user defined  |
          |     as being allowed and then svxlink will abort leaving the serial port     |
          |     initialized.  That means the D710 is stuck transmitting!   This is       |
          |     horrible and *can* destroy your radio's  transmitter as it wasn't        |
          |     designed for 24/7 full duty FM transmission!                             |  
          |                                                                              |
          |     NOTE: The Kenwood D710 does have a Transmission Timeout option that      |
          |           can save your radio in this specific situation.  See above for     |
          |           setting the D710's "TOT" feature!                                  |
          |                                                                              |
          |     Please see the modemtest perl script in the "Serial port troubleshooting |
          |     and tools" section on how to un-initialize the RTS line upon a serial    |
          |     port not being being completely shutdown properly.                       |

           - GRIPE:  I don't understand why Kenwood put the SQL status signal 
                     line on the "PC" port when they clearly had available pins 
                     already on the "DATA" jack!  Because of these missing lines, 
                     you cannot use something like Echolink in non-EL D710 mode 
                     with the stock Kenwood PG-5H cables.  You might be able to 
                     make your own Echolink cables to gain access to this cable 
                     though but it's unclear what the behavior of CTCSS squelch 
                     line would be.  Read below on the "Echolink RX monitor" 
                     feature below for more details.

           - NOTE2: The manual says that that the internal D710 cannot use
             !!!!!  the internal AX.25 TNC when in Echolink mode per the 
                    "TM-D710-CDROM-English.pdf" file (Echolink section page 23).  
                    Yet the "E_TM-D710AE.book.pdf" manual, page 39 says it's
                    should work fine.  I personally am using both at the same 
                    time and don't have any problem when running the D710's 
                    internal TNC in KISS mode with use with standard packet 
                    operation (not APRS mode).  If it doesn't work for you, 
                    maybe your running an old version of the D710 firmware.

           Internal D710 specific settings via Windows software
           These settings are specific to the Kenwood D710.  If you *aren't using*
           a D710, you can skip this section.

           - There are *three* settings on the D710 for Echolink mode that
             can ONLY be configured via the free Kenwood MCP-2A Windows program:

                       - Echolink RX monitor
                       - Echolink RX audio level
                       - Echolink TX audio level

             These settings CANNOT be set via any menu item on the radio 
             itself nor or a Linux program that I'm aware of.  It's also
             worth noting that these Echolink settings only activated when 
             you restart the radio into Echolink mode.

              NOTE:  I don't know if this MCP-2A software can operate from
                     WINE but if you know if it does / doesn't work, I'd 
                     love to get an email about it from you!

             See the D710 Echolink manual for more details on how to install
             and operate this software but the only item you absolutely need 
             to change is:

                Echolink RX monitor
                What this feature does is that enables the monitoring any 
                received signal that breaks squelch with the D710's volume.
                What's unique is that ONLY if the signal also includes the 
                configured CTCSS/DCS tones while the radio is in CT (tone
                squelch) mode, will that audio be sent out of the "DATA" 
                jack on the back of the radio unit towards the connected 
                computer for sending into the Echolink network


                   - Before trying to use the MCP-2A software, you 
                     MUST Take the D710 out of Echolink mode via 
                     a power cycle and the PF2 key

                   - If the D710 is in packet KISS mode, shut down your
                     packet programs and daemons as well

                   - Connect the D710's COM port to an available serial
                     port on your Windows computer (for USB users, it's
                     highly recommended to use an FTDI-based serial adapter
                     as many problems are seen with Prolific-based units)

                   - Configure the MCP-2A program to use:

                      - The proper Windows-detected serial port under Setup 
                        --> COM port setting (I have to set this to COM16) 

                      - I personally must use the AUTO setting for the 
                        COM port speed.  Manually setting it to say the 9600
                        baud speed does NOT work for me.  
                   - Have the MCP-2A connect to the D710 by clicking on
                     Program --> "Read data from transceiver" to download
                     it's settings from the radio to the computer.  Once read,
                     the D710 will do a soft reset but all your various settings
                     are left intact.

                   - Now set the radio to properly send the heard audio from
                     the RF side to the svxlink connected computer when CTCSS/DCS
                     is present by:

                       Edit --> Menu --> Transmit/Receive -->
                       Echolink RX monitor :: Set it to "Busy Only" from
                       the default of "CTCSS/DCS"

                * You also might need to change the the D710's Echolink RX/TX 
                  audio levels via the MCP-2A program but you won't know if 
                  you do until start doing final audio level testing.

                   - Edit --> Data Terminal --> PR1 Output level -->
                     For Echolink Sysop mode :: Set it from the stock setting
                     of 3 to either to 6 to 7 (this level really depends on your
                     echolink-attached sound card and you settings might vary)

                   - Edit --> Data Terminal --> PKD Input Sensitivity -->
                     For Echolink Sysop mode :: Set it from the stock setting 
                     of 2 to 5 (this level really depends on your echolink-attached 
                     sound card and you settings might vary)

                   - Click on ok

                   - Have the MCP-2A write these changes to the D710 by clicking on
                     Program --> "Write data to transceiver" to upload the
                     settings from the computer to the radio.  Once complete, the
                     radio will do a soft reset to activate the changes.

                   - Since you're already here, you might as well goto File -->
                     "Save As" and save a copy of all your radio's settings to 
                     a backup file on the computer just in case!

                   - Disconnect the serial connection from the radio and re-connect
                     it to the Linux machine

                   - Turn off the radio and put it back into Echolink mode via the
                     PF2 button

43.f - Setting the Svxlink audio levels

Ok, go ahead and start up the svxlink program ONLY AS A TEST
in non-background mode:

        sudo svxlink /usr/bin/svxlink

   NOTE:  It's HIGHLY recommended that once full configured, you start
          svxlink via the start-svxlink.sh script mentioned in a later
          section if you use a Kenwood D710!

   - At that point, you should see something like the following:
       SvxLink v1.4.0 (Apr 18 2015) Copyright (C) 2003-2014 Tobias Blomberg / SM0SVX

       SvxLink comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
       welcome to redistribute it in accordance with the terms and conditions in the
       GNU GPL (General Public License) version 2 or later.

       Using configuration file: /etc/svxlink/svxlink-std.conf
       --- Using sample rate 48000Hz

       Starting logic: SimplexLogic
       Loading RX: Rx1
       Loading TX: Tx1
       Loading module "ModuleHelp" into logic "SimplexLogic"
               Module Help v1.0.0 starting...
       Loading module "ModuleParrot" into logic "SimplexLogic"
               Module Parrot v1.1.0 starting...
       Loading module "ModuleEchoLink" into logic "SimplexLogic"
               Module EchoLink v1.3.0 starting...
       Loading module "ModuleTclVoiceMail" into logic "SimplexLogic"
               Module Tcl v1.0.1 starting...
       SimplexLogic: Event handler script successfully loaded.
       EchoLink directory status changed to ON
       Connected to APRS server on port 14580
       --- EchoLink directory server message: ---
       EchoLink Server v2.5.9997

       ECHOEC2-3: Herndon, VA USA

     NOTE:   Notice that svxlink only loaded the ModuleHelp, Parrot, EchoLink, 
             and VoiceMail modules.  These modules can be disabled and many other 
             modules enabled per "MODULES" line the the "[SimplexLogic]" section
             of the svxlink.conf configuration file.

     NOTE2:  If you didn't see any messages about APRS, you have an invalid GPS
             configuration (check your coordinates being in DMS vs. Decimal)
             Unfortunately, Svxlink doesn't throw an error about this.

     NOTE3:  You might see errors from svxlink about NOT being able to log into 
             the Echolink servers.  For example:
             EchoLink directory status changed to ON                      
             --- EchoLink directory server message: ---                   
             NOT LOGGED IN                                                

             Because of a system problem,
             you are not currently logged
             Please wait several minutes 
             for the server to reset.   

             This is either a problem with Svxlink or the Echolink system.
             Svxlink will automatically retry to log in a few minutes later but
             alternatively, you can simply shutdown the Svxlink program with 
             control-C and then restart it.  It will almost always log you into
             the Echolink servers just fine the second time.

   Settings the radio link audio levels
   - Svxlink has some configuration settings to help speed this along:


     But the quick and dirty of it is:

       Setting the Soundcard INPUT or Microphone level

       - If you're already using other soundcard levels for HF (Fldigi), Packet radio 
         (soundmodem), etc., you should restore those levels FIRST, then tune these 
         Svxlink levels, and then save all the new levels together.  

         To start off, restore all your old levels you might have had with:

           /sbin/alsactl restore

           If you receive any errors like:
           /sbin/alsactl: state_lock:125: file /etc/asound.state lock error: Permission denied
           /sbin/alsactl: load_state:1683: Cannot open /etc/asound.state for reading: Permission denied

           This is due to changes that have been coming in via what seems to be PulseAudio.  The crux
           of the issue is the user running the command being unable to create the
           /var/lock/asound.state.lock file.  Either the above "/sbin/alsactl restore" command must
           be run with "sudo" or the user you're running this command must be in the "lock" unix 
           group defined in /etc/groups.  If you go this latter route, you must log out of Xwindows
           (yes the whole thing) to pick up the new changes.

        - Next, open up the Linux soundcard mixer controls.  On my system, I use Kmix 
          from KDE 

        - Find the tab for the specific sound card connected to your radio

        - Back in the window running svxlink, change the radio to NOT
          use PL/DCS tone squelch and then open up squelch level on the 
          radio.  You should see something like the following (assuming you 
          configured Svxlink for "VOX" and not "SERIAL" (aka COS mode):
           Rx1: The squelch is OPEN (0.161287)
           Rx1: The squelch is CLOSED (5.85425)

     NOTE:  I had originally tried doing this step with my D710 in 
            NON-Echolink mode and saw the following:
            Rx1: The squelch is OPEN (2.93365)
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: The squelch is CLOSED (5.85425)
            Rx1: The squelch is OPEN (0.774545)
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: Distorsion detected! Please lower the input volume!
            Rx1: The squelch is CLOSED (5.89493)

            These "Distorsion detected" warning errors are due to the fact 
            that my D710 radio was using the higher audio levels 
            associated with the non-Echolink mode (external packet mode).  
            When the D710 was put into in Echolink mode, the audio levels 
            were OVERLY lowered which required me to change the hidden 
            Echolink levels via the MCP-2A Windows program.

        - While those messages are still scrolling across the window, go to 
          your preferred soundcard mixer application.  I've described some
          of the options in the Soundmodem section.  On my setup, I did used
          KDE's "kmixer" application for the following:

              - Un-check the MUTE button for Auto Gain Control 

              - On the Microphone setting

                - Make sure the Capture checkbox is checked

                - There are two sliders on my setup

                  - The RIGHT SLIDER is the "Mic (capture)" slider that works on this 
                    cheapy USB soundcard fob.  This slider has 17 level lines on it 
                    for some strange reason!  The left slider has a mouse over label of
                    "Mic" and doesn't seem to do anything.

                       - With the D710 in Echolink mode with the stock Echolink 
                         levels, I needed to slide that up to 100% level but I never 
                         could increase the levels to show the "distortion detected" 
                         as recommended by the svxlink documentation. Once I
                         altered the Echolink levels as described earlier in 
                         a previous section, I COULD get the "Distorsion" warnings
                         and then tune the system as recommended.  For me, I needed to
                         move the Kmix slider level setting to 5 of 17 (four keyboard
                         up-arrows to get to that level).

                  - The left "Mic" slider with much courser level markings didn't have 
                    any bearing on the Echolink volume setting.  This is probably due to
                    being a left channel of a stereo mic and that side isn't wired to 
                    the D710.

       Setting the Soundcard OUTPUT or "Speaker" level
       - Have your second radio (HT) turned on, set to the correct Svxlink frequency 
         and is generally ready to receive

       - Open up the Sound card mixer control, select the Echolink sound card,
         and be prepared to change the "Speaker" level

       - Go to the running Svxlink program running in the foreground (not in 
         daemon mode) and type in the key sequence: *#  (that's asterisk and then pound)

       - Svxlink should mention it's enabling TX and then start transmitting on 

           NOTE: If you start seeing various errors, see the next section for 
                 some examples and resolutions.

         Listen to the quality of the audio on the second radio (HT) and 
         adjust the "Speaker" mixer level to have full volume without any distortion.  

            - NOTE: Only use the soundcard channel required to drive your radio
                    99% of all amateur radios use a MONO output from your sound device to
                    the radio.  As such, it's recommended to set the correct "TX" level 
                    on only the required output channel and configure the ALSA mixer to make 
                    the OTHER channel muted (set to 0).  This helps avoid interference issues 
                    where the system can actually hear itself

         I recommend you move the volume slider all the way down and slowly work it 
         back up until a) the volume stops getting louder and b) the audio doesn't 
         start to distort.

           NOTE:  When I initially tried out Echolink mode on the D710,
                  a volume level of 100% (11/11) was pretty good.  Once I 
                  changed the internal D710 Echolink Receive sensitivity 
                  level to a 5, I needed to adjust the volume to about 
                  5% (2/11).  That is 16 keyboard up-arrow presses to get

       - Once you're happy with the levels, save them with:

           /sbin/alsactl store

           NOTE:  If you see any errors with this command, please see the above
                  "alsactl restore" section

Ok, you should be all setup now!  You now might consider using my start-svxlink.sh 
script to start/stop Svxlink.  It's mentioned in the next section.

43.g - Testing the Svxlink system

Testing remote connectivity from an Internet-connected Echolink system
   - From a properly configured remote Echolink computer or Smartphone, look up your 
     callsign with the -L suffix and see if it can log in.  In this example, I'm 
     connecting as KI6ZHD (no suffix) from my Echolink app on my Android phone 
     into KI6ZHD-L and then I disconnect:

       Spurious audio packet received from
       Incoming EchoLink connection from KI6ZHD (David) at
       Spurious audio packet received from                
       Incoming EchoLink connection from KI6ZHD (David) at
       --- EchoLink directory server message: ---                        
       EchoLink Server v2.5.9997

       ECHOEC2-3: Herndon, VA USA

       Incoming EchoLink connection from KI6ZHD (David) at
       Activating module EchoLink...

       KI6ZHD: Accepting connection. EchoLink ID is 485085...
       KI6ZHD: EchoLink QSO state changed to CONNECTED
       --- EchoLink info message received from KI6ZHD ---
       Station KI6ZHD
       David - Santa Clara, CA
       Santa Clara, CA

       KI6ZHD is running EchoLink for Android on a Motorola DROID2, with Android version 2.3.4.
       Tx1: Turning the transmitter ON
       Tx1: Turning the transmitter OFF

       KI6ZHD: EchoLink QSO state changed to BYE_RECEIVED
       KI6ZHD: EchoLink QSO state changed to DISCONNECTED

     Notice above that the Svxlink program gets the remote client's detail from the
     Echolink server and then it keys up the radio and then plays back audio giving 
     the remote station status details (see below what it would send).   

     NOTE:  If your radio doesn't start transmitting, make sure you have configured
            the svxlink.conf file correctly and/or the PTT circuit is wired correctly.

              For D710 users, you must put the radio into EchoLink mode for PTT on the
              PC port to function using the Kenwood Echolink cables (documented above)

     NOTE2: When you first installed the svxlink RPM package and did NOT
            create the required directory and symbolic link for the audio
            files, you'll see the following error messages:
            *** WARNING: Could not find audio clip "activating" in context "Default"
            *** WARNING: Could not find audio clip "name" in context "EchoLink"
            *** WARNING: Could not find audio clip "connected" in context "EchoLink"
            *** WARNING: Could not find audio clip "phonetic_k" in context "Default"
            *** WARNING: Could not find audio clip "phonetic_i" in context "Default"
            *** WARNING: Could not find audio clip "phonetic_6" in context "Default"
            *** WARNING: Could not find audio clip "phonetic_z" in context "Default"
            *** WARNING: Could not find audio clip "phonetic_h" in context "Default"
            *** WARNING: Could not find audio clip "phonetic_d" in context "Default"
            *** WARNING: Could not find audio clip "greeting" in context "EchoLink"

            Please read back in the above Svxlink installation section on how to create 
            the mandatory symlink (this has also changed for newer versions of Svxlink
            that uses 16k samples)

   - Echolink testing via a local radio link (a second HT radio)
     - Setup another radio (say an HT with DTMF buttons on it) to use the same 
       frequency, and tone as your svxlink radio setup)

     - Listen to the frequency for some time and ensure that it's not in use.  

     - Key up the HT, verbally call out your callsign to ID and say something
       like "KI6ZHD, controlling".

     - Check the svxlink STDOUT messages and confirm the svxlink program should 
       output lines like:
         Rx1: The squelch is OPEN (0.774545)
         Rx1: The squelch is CLOSED (5.85425)

     - Good!  Ok, lets do some more TX tests:

       - Key up the HT radio, verbally call out your callsign to ID and state
         your intentions.  For me, I would do a "This is KI6ZHD, controlling
         an echolink LINK node".  Then then press:

         "*" and then "#" (or "*#") --> The svxlink system should make an 
                              announcement about the configured callsign, system's 
                              time, the configured PL tone, and a mention of
                              the help system.  The audio should be very clear, 
                              understandable, and not distorted in any way.  If 
                              you don't have all of those data points, re-check 
                              the audio levels on the sound card and possible the 
                              radio too.

       - Next, lets try some longer audio:

         "0#" --> HELP: To get more audio out of the system for better tuning,
                  try the svxlink help.  The system should play back the help 
                  audio for the specific svxlink module enabled (0 modulehelp, 
                  1 parrot, or 2 echolink).  Enter in "#" to exit help.

     - Now lets do some combo RX/TX tests.  Key up the second radio, and issue 
       the following DTMF command and then release the PTT:

         "1#" --> PARROT mode: The svxlink system will hear and then playback
                  the heard audio from you.  This is very helpful for tuning the
                  audio levels.  

                - At this point, key up the second radio again and talk into it's 
                  microphone with a normal voice level and talk for a little bit.  
                  Once done, release the PTT.  At that point, the Svxlink program 
                  will playback the recorded audio.  While your listening to this, 
                  you might want to make additional soundcard mixer adjustments 
                  to get the audio just right.

                - Once you're done with the Parrot mode, again key up the second 
                  radio and simply issue the "#" DTMF tone to end the Parrot mode.

Testing with the Echolink Test Server:

  - Ok, last step!  Let's check your end-to-end VoIP connectivity to the Echolink 
    Test server.  Please note that the Svxlink DTMF commands are a little different 
    than the standard Echolink DTMF commands.  That's ok and it's also a LOT more 
       1. Key up the second HT radio, verbally call out your callsign to ID and 
          state your intentions.  For me, I would do a "This is KI6ZHD, 
          controlling an echolink LINK node"

       2. Activate the Echolink module by keying up the radio and while keyed,
          enter in the following DTMF tones:


          and then let go of the PTT.  The Svxlink program should tell you that 
          the Echolink module has been loaded.  

       3. To confirm your configured Echolink node number, again issue the DTMF


          and the svxlink program should announce your Echolink node number.
            If you also enabled my Svxlink patches, you should have heard a audio
            sound on the default sound system (my laptop speakers in this example)
            AND you should have received an SMS text message on your configured
            cellphone number

       4. To confirm if any remote stations just happen to be already connected 
          to your station, key up the radio and issue the DTMF tones:

          and the svxlink program should announce how many stations are connected
          to your system.

       5. So let's connect the station to the official Echolink TEST server and 
          see how we sound.  Key up the radio and enter the following DTMF tones:


          and then let go of the PTT.  The Svxlink program should link up to 
          the Echolink server and then the remote Echolink system should announce
          you that you're connected in a very clear, crisp, and non-distorted

            If you also enabled my Svxlink patches, you should have heard a audio
            sound on the default sound system (my laptop speakers in this example)
            AND you should have received an SMS text message on your configured
            cellphone number

            - At this point, key up the radio and speak into the microphone just
              like you did before for the local test.  Once done, unkey the radio
              and the Echolink system should play back what you said.  Confirm 
              that the audio sounds good.   

            - The audio levels should be good as we already tested it locally.
              If the levels are wrong (too low, too high, etc), re-do your testing
              of the local levels as described earlier in this doc

            - If the audio is garbled, it's most likely an Internet upload/
              download issue.  We can't cover that in this document but feel
              free to email me if you need some help

       7. Once complete with your Echolink "ECHO" testing, key up the second
          radio and while keyed, enter in the "#" DTMF key.  This will log you 
          out from the remote Echolink TEST server.  If you're done with 
          Echolink all together, again, go ahead and key up the second radio 
          and issue the DTMF "#" command.

          At this point, the Svxlink echolink module will be unloaded.  If you 
          don't use the system for a while, the Echolink module will automatically
          get unloaded and the svxlink system will make an announcement as of

Saving your new Soundcard audio levels
As mentioned in great detail in the "Soundmodem - Setting the right audio levels"
section above for packet radio stuff, you can use the command:

   /sbin/alsactl save

           NOTE:  If you see any errors with this command, please see the above
                  "alsactl restore" section

to save all of these soundcard levels for both your svxlink soundcard levels but
also for all your other soundcards as well.

Fine tuning the Svxlink Configuration for VOX users:

  - If you are using VOX in your setup, you're probably going to need to do some
    fine tuning to get it working just right.  The parameters in the 
    /etc/svxlink/svxlink.conf file will really depend on your specific radio,
    your soundcard, etc. but here are some of the values I played with:

     #default is 0
     #default is 2000
     #Minimum input voice volume factor to trip VOX - default is 20
     vox_Filter depth = 15
     #default is 1000
     vox threshhold = 800

43.h - Svxlink Startup: Safely Start/Stop Svxlink for local control and logging

As mentioned in the "Critical Issue: Improper serial port shutdown with the D710"
note above (go read it if you haven't already), the design of the Kenwood D710 
in Echolink lends itself to leaving the radio always keyed!!

I've submitted a bug report about this issue to the Svxlink folk but until then, 
please consider using the "start-svxlink.sh" and recovery script located at:


   This script also requires the following other scripts:

This start-svxlink.sh script does the following:

    - ** Ensures that if Svxlink crashes when it's transmitting, it resets the
      ** PTT signal so the radio isn't left transmitting.  This uses a modified
      version of the modemtest-reset-serialport.pl script as part of the 
      "perl-Device-SerialPort" package which is not included 
      with Svxlink.  

    - Restores saved soundcard volume levels for consistent audio levels

    - Verifies that the ALSA audio system has the right permissions for the svxlink 
      user to initialize it

    - Disables your computer from going to sleep for 24/7 operation when starting
      and re-enables sleep when Svxlink is shutdown

    - Runs Svxlink in the foreground under a screen session so you can monitor
      the logs, see what users are sending in the Echolink chat, etc

    - Selects different svxlink config files to be loaded at start to send 
      different descriptions to the Echolink servers and APRS-IS objects

    You can get it here:


    To use the script, you have to do the following:

       1. Put the script into /usr/local/sbin

       2. Edit the script to use your specific system settings (executing username, etc)

       3. Rename the stock Svxlink executable so there is NO confusion of how to start svxlink

             mv /usr/bin/svxlink /usr/bin/svxlink.bin

       4. Move your svxlink.conf file to point to a new file

             mv /etc/svxlink/svxlink.conf /etc/svxlink/svxlink-std.conf

       5. Give things a manual test with running:

             sudo -u svxlink /usr/bin/svxlink.bin --config /etc/svxlink/svxlink-std.conf

       6. If things work fine here, you'll just want to run Svxlink in the future with:


43.i - Svxlink Cheatsheet, Using QSO Monitor to pick a free link frequency, bugs, and future features

It might be worth showing a quick cheat-sheet of other Svxlink commands that are available:

    Enabling various modules
    0# - Help
    1# - Parrot

    2# - Echolink

    3# - Svxlink voicemail

    QSO Recorder (if enabled in the svxlink.conf file
    81# - Enables the svxlink QSO recorder.  When the system detects that SQL
          is open, it will record a WAV file to the /var/spool/svxlink/qso_recorder/
          directory.  Read below for more details on this feature and how to 
          play the files.

    80# - Disables the svxlink QSO recorder

    User Defined Macros
    D1# - Executes the MACRO section in the svxlink.conf file.  
          Automatically loads the Echolink module and connects to the
          Echolink Test server

    D2# - Per the example above, load the echolink module and connect
          to KI6ZHD-L's node if logged in

    Example steps to connect to the EchoTest system (assuming it's fully running)
    Step #1 - tune your second radio (HT, etc) to your Svxlink station's chosen frequency 
              (see the next section for recommendations on how to pick a frequency and PL)

    Step #2 - Listen to the frequency for a period of time to make sure the frequency is free.
              If it is, now key up your radio (PTT) and announce that your using this frequency 
              the system.  For example, I would say:
                  "Is this frequency in use? <pause>KI6ZHD controlling"

    Step #3 - (optional) key up your HT's radio (PTT) and punch in * and then # and then 
              release PTT.  You should hear the Svxlink station announce itself

    Step #4 - Enable the Echolink mode by entering PTT + 2 + # + ReleasePTT

    Step #5 - Connect to the EchoTest node by using PTT + 9999 + # + ReleasePTT.  At that point, 
              the Svxlink station will try to connect over the Internet to the EchoTest station.  
              Assuming that works, the Svxilnk system will announce the connection was successful
              and then the remote station will most likely announce itself as well

    Step #6 - Key up your HT (PTT), talk into the radio as usual, and then release PTT.  At that point,
              your voice will be played back to you from the remote EchoTest server.  Talk as much as
              you want

    Step #7 - To disconnect from the EchoTest node, you would use PTT + # + ReleasePTT

    Step #8 - key up your radio (PTT) and announce that your done using the frequency.  For example, 
              I would say "KI6ZHD clear in using this frequency"

Picking a Simplex frequency to operate Svxlink on QSO_RECORDER:
As previously mentioned, a lot of HAMs in your area might camp out on a
particular simplex frequency and "claim it as their own".  Yes, we all
know that they don't own the frequency but if they have been using that
frequency for their own nets, etc for a long time, it's probably NOT 
good to put your Svxlink system on that frequency.  

    To avoid any conflicts, the svxlink QSO_RECORDER feature can really 
    help you here.  What you should do is the following:

      1. Disable tone squelch on your radio ("CT" on the D710) so that
         all signals will be recorded

      2. Either via a second radio or on the svxlink STDIN window, issue the 
         DTMF command:


         The svxlink program will announce that the QSO_RECORDER feature 
         has been enabled.  

               Please note that the QSO recorder can ONLY be enabled or
               disabled from the top level.  It cannot be enabled or
               disabled if say the Echolink module is loaded.

      3. The first time the squelch is broken, svxlink will create 
         a timestamped file in the /var/spool/svxlink/qso_recorder
         directory such as:


         Each additional time the squelch is broken, the audio will
         be recorded and appended to the file.  All svxlink announcements
         will NOT be recorded.   

      4. Once you're done with the recordings, issue the DTMF command:


         Which will disable the QSO recording.  At that point the 
         temporary file will be renamed to reflect a final name
         with start and stop timestamps.  For my example:


         renamed to:

      5. Don't forget to re-enable Tone Squelch (CT) on your radio to avoid
         false squelch openings for normal operation

      6. To listen to these recordings, I had to use a a similar elaborate command
         when used to test the Svxlink sound card.  To play my specific QSO 
         file back to the built-in sound-card, I used the following command:

            aplay -D"plug:'hw:0,0'" -c 1 -f S16_LE /var/spool/svxlink/qso_recorder/qsorec_121010090933_121010093615.wav

         NOTE:  WAV files get big FAST so watch them.  If you want to keep 
                recordings around for a long time, consider compressing them
                with say an MP3 encoder such as "lame".  Feel free to email
                me if you need help with Lame.

Notes about Svxlink that might interest you, possible bugs found, etc.

    Changing the automated voice prompts
    - If you ever want to edit the Svxlink audio prompts (I didn't like
      the length of the Echolink connected prompt), I used Audacity for
      Linux to change the file as I deemed fit (email me if you want
      a copy).  To save the file, it's a little complicated since
      Svxlink only uses 8Khz files.  Once edited, select 

        - File --> Export
        - Name the file   (say /tmp/greeting16.wav )
        - Change the file format to "Other uncompressed files"
        - Click on Options
          - Header: WAV (microsoft)
          - Encoding: Signed 16bit PCM

        - Open a shell and goto /tmp
        - Convert the 16bit WAV file to an 8bit WAV file

          sox -c 1 -b 16 -e signed-integer greeting16.wav -r 8000 greeting.wav

        - Backup the old file and put in the new one:
           mv /usr/share/svxlink/sounds/en_US/EchoLink/greeting.wav \

           mv /tmp/greeting.wav \

    To Add to the doc:
    - Svxlinkwrapper - A python wrapper script that improves on svxlink
      system logging, etc.  

    Linux Power management
    - One additional thing you will need to consider is if you have power management
      enabled on your computer.  If the computer is set to suspend due to inactivity,
      this will interrupt Echolink operation.  Consider looking at the power 
      management management function in the packetrig.sh script for ideas.

  Possible Svxlink Bugs:
    - If the ALSA sound card ID as configured in svxlink.conf is wrong and "serial" RX 
      detection is enabled, when you start up the svxlink program, it will key up the 
      D710's radio transmitter, exit with an error.  What's worse is that it leaves 
      the radio keyed up with no way to stop it from transmitting other than turning 
      it off or running a special program!
      Starting logic: SimplexLogic
      ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card
      ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card
      *** ERROR: Open capture audio device failed: No such file or directory
      *** Error: Could not open audio device for receiver "Rx1"             
      *** ERROR: Could not initialize RX "Rx1"                              
      *** ERROR: Could not initialize Logic object "SimplexLogic". Skipping...
      *** ERROR: No logics available. Bailing out...  
      Please see the note on the start-svxlink.sh script to work around 
      this issue.

    - The Fedora svxlink.spec file doesn't set secure file permissions on the 
      configuration file:

        chmod 660 /etc/svxlink/svxlink.d/ModuleEchoLink.conf
        chown -R svxlink.daemon /etc/svxlink/
        chown svxlink.daemon  /var/spool/svxlink/qso_recorder

  - The Fedora  /etc/rc.d/init.d/svxlink init script seems to be broken and svxlink
    won't start -- [fix me]

  - If there is an error in the APRS GPS coordinates (user configured Decimal vs. 
    DMS coordinates), it won't throw an error or warning though it should

  Future Feature requests for Svxlink:
  - Support security prefix DTMF tones for all svxlink commands

  - Ability to remap svxlink DTMF buttons to letters to emulate the official 
    Echolink key layout (Kenwood D710 mic)

  - Be able to play svxlink announcements out an additional soundcard to 
    monitor what's being said instead of having to need a second radio.
    Maybe if PulseAudio was supported, we could use it's "monitor" feature.
    It sounds like this might already be possible by modifying some
    specific svxlink shell scripts

  - Have Qtel be able to directly interact with Svxlink to allow for browsing 
    of other stations, connect the svxlink system to the chosen remote stations,

  - Have QSO monitor annotate in the wav file what's going on, squelch
    open, DTMF x, etc.

  - Support a simple way to redefine all DTMF codes to say be identical with
    the official Echolink program (73s to disconnect vs. using #, etc.)

  - possibly solved with svxlink_wrapper? - Time stamp svxlink STDOUT lines when events 

  - Be able to change the APRS symbol via the config file

  - Support HUPing the svxlink process to reload the config w/o disconnecting
    from the Echolink server, etc.

  - The 8# command should not give an error, it should get better help about 
    using 80# and 81# instead

  - Have the system be able to announce the use of DCS codes and not just
    CTCSS PL tones

  - Have a "TX inhibit" command on the STDOUT console so that the system will
    never transmit until turned off.  Good to have when say I do a 80# and
    then 81# to create a new qso monitor wav file, etc.

  - 10/26/12 - Enabling QSO_RECORDER is not logged in STDOUT

  - 10/26/12 - When connecting from an Android Echolink client

  - 10/26/12 - If svxlink is run under the svxlink user but that user doesn't
               have a home directory, you will see errors like the following.
               The solution is to create a proper home directory for the svxlink
               user.  My spec file has been updated to reflect that

         *** ERROR: Unable to handle event: EchoLink::remote_greeting KI6ZHD (Could not send the message.
         /sent: Permission denied (errno = 13))
         No protocol specified
         XOpenDisplay() failed
         Home directory / not ours.
         W: core-util.c: Failed to open configuration file '//.pulse//daemon.conf': Permission denied
         W: daemon-conf.c: Failed to open configuration file: Permission denied
         ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused

         /usr/bin/play formats: can't open output file `default': cannot open audio device

43.j - Configuring and using Qtel for Echolink

Qtel is a fully featured Echolink compatible client that's very similar to the official Windows client. It has NO interface to the RF world and as such, it will need it's own microphone. Most people recommend that you get yourself a quality headset that has both headphones and a boom microphone for the best results. The other benefit of a client like this is that it allows you to easily browse around and find other Echolink nodes by type, location, etc.

   IMPORTANT:   Qtel cannot run at the same time as Svxlink on your computer.
                This is due to the fact that the Echolink network ports 
                are in use by Svxlink.

This is the main window that shows the main Qtel menu:

This is an example of the main QSO window Qtel menu:

Qtel is automatically compiled and installed as part of the Svxlink package so
to get going with it, start "qtel" from the command line.  Once started, you
should see the main window.  To start configuring it, select Settings -->
Qtel Settings.

  - In this main window, you need to enter in your non-L, non-R validated 
    Echolink callsign, your first name, and your Echolink password as created 
    in the previous section

  - The directory setting defaults should be ok but check out the Qtel documentation
    for other options

  - Under the "Sound" tab, you need to select the correct ALSA device.  In my 
    setup, I would use "alsa:plughw:3"

That's it and you're Qtel setup is configured!  The client should now log you
in and you should be able to browse around to connect to various conferences, 
links, repeaters, or stations.  

Once connected, you can either click on the the big PTT button on the right-hand
side OR you can fine-tune and enable the VOX feature.

That's it!

44. - Echolink and IRLP Internet Linking

44.a - Overview of Using Echolink and IRLP

Introduction to Echolink and IRLP:
Echolink is a Amateur Radio / VoIP software solution originally written for Windows 
to support multiple types of connections:

     a. A Echolink enabled repeater to a remote Echolink enabled repeater
     b. A computer with a headset to a remote Echolink enabled repeater
     c. A computer with a headset to a remote computer or smartphone
        (not really HAM radio if you ask me!)
     d. A smartphone to a remote Echolink enabled repeater
     e. A smartphone to a remote computer or smartphone
        (not really HAM radio if you ask me!)

The Echolink group later wrote client-only apps for the Apple iPhone and Google 
Android platforms but those versions are only clients and don't have all of the
validation and server side features.  There are other non-official Echolink 
programs out there like:

  - Svxlink/Qtel for Linux as described in the previous sections
  - EchoMac for the Apple OSX platform

IRLP is somewhat similar to Echolink in the sense that it uses VoIP but instead of
connecting clients to a repeater, IRLP is intended to ONLY link repeaters to 
other repeaters or IRLP reflectors.  Unlike Echolink that doesn't require any unique
hardware, IRLP *does* require a proprietary board that gets connected to your

   - The IRLP computer can ONLY run Linux today
   - This IRLP hardware can only be connected to the system via a parallel port.  
     There isn't any USB hardware version of this board as of 2012.

44.b - Echolink Validation

Echolink account Validation 
  Since you're using the Internet, the Echolink people need to confirm that you're 
  an actual HAM since there is the real potential that the remote side of the 
  connection will be transmitting on a RF radio!  The Echolink admins do this 
  validation in one of three ways ( http://www.echolink.org/faq_validation.htm ):

        1. Send a copy of your FCC license to them (scan it in and upload or fax it).
           Update: I personally had an issue with this as I considered it to be
                   a personal security breach.  I later learned  that ANYONE can 
                   get an exact duplicate of your FCC license  document in a PDF 
                   from the FCC website?  Since the FCC is essentially gives away 
                   this document, it doesn't seem like it's very risky for you to 
                   give it away to the Echolink folks.

        2. Use your configured ARRL LOTW (always a good idea to signup to 
           exchange logs) to confirm you're a HAM.  LOTW does the validation 
           things differently.. see the LOTW section in this document for full 

           NOTE: As mentioned above, I didn't previously like the idea of sending 
                 a copy of my license to the Echolink people so I went the LOTW 
                 approach.  Setting up a LOTW account does take a little more time 
                 as the LOTW people have their own procedures rules but once enabled 
                 there, you can then official QSO logging of your HF contacts, use 
                 the LOTW to guarantee yourself on other HAM systems, etc!
          NOTE2:  Remember, LOTW is open to all global HAMs in any country.. not 
                  just United States base HAMs!

Echolink Registration for your new LINK:

  - When people first register with Echolink, they will most likely register their 
    plain callsign.  In my case, I registered KI6ZHD.  This is good for calling out 
    from say your Windows or Android Echolink app but it essentially means this 
    login is *only* a non-RF based Echolink client.   There isn't any RF connections 
    in use nor any other people other than KI6ZHD using it.  

    For the Svxlink section above, we plan on putting up a Echolink system in Sysop 
    mode, specifically a LINK setup on a simplex frequency.  As such, you'll need to 
    register the "-L" or "link" suffix.  With that, my svxlink system could then log 
    into the Echolink system in Sysop mode as say "KI6ZHD-L" and the -L suffix means 
    I have a real RF link connected to my system.   BTW, if you were actually working 
    on adding Echolink service to a full blown repeater, you'd want to register the 
    -R suffix.  

       NOTE: In Echolink's eyes, the new -L suffix is a new callsign so even if you
             have a non-L validated account, you'll need to sign up as if you were a 
             new user.  Fortunately, you will NOT have to re-validate your Amateur Radio 
             license like you did originally.  Because of that, this step is pretty 
             quick and simple.  To do so,
              1. MANDATORY: Install and run the Windows Echolink program, Tools 
                 --> Setup --> My Station and select Mode: Sysop --
                 This can only be done via the official Windows program

              2. If need be, click on "Change Callsign" and add the -L suffix to
                 your callsign

              3. There other information previously configured such as your 
                 password for your non-Sysop password, name, and location.
              4. Once you click on ok, the Windows program side is done and
                 now you need to validate the new -L callsign.  To do that, 
                 go to:


                 to finish the validation.  In that web interface, you'll
                 be sent an email to then go to the next validation step.

              5. Once you receive the validation email and click on the web
                 link, assuming you already had a validated Echolink account
                 with the *same* callsign, click on the "password" option to
                 use that previous account's password.  If all goes well,
                 you should get a "Validated" update message on your web browser
                 within a few seconds!

44.c - Using Echolink and IRLP

Using Echolink and IRLP:

1. Using just a radio to interact with a remote Echolink node:

   Once your radio is configured to use the proper local repeater (or Svxlink)
   frequency, offset, tone, etc., you just need to find out what remote 
   nodes you want to connect to and what are the various DTMF codes to control 
   the local Echolink/IRLP system:

   To see what Echolink, IRLP, or EchoIRLP nodes are operating out there, look 
   them up:

      Echolink enabled repeaters and links (links are people who are using 
      computers or smartphones): 

      IRLP enabled repeaters: 

   The local EchoIRLP codes for other open repeaters are usually publicly posted 
   on the Echolink/IRLP website.  For example, see the bottom of this IRLP status 


   Alternatively, those codes might be posted on the repeater/ham club's website.  
   If not posted, the codes might be reserved for members only.  Once you have 
   the controlling EchoIRLP codes, give it a try!  

     NOTE:  Though most Echolink enabled nodes and links usually uses the same 
            standardized DTMF codes, IRLP doesn't have as much standardization.  
            As such for IRLP, you need to look at the bottom of the IRLP status 
            web page for a given IRLP node to see what the codes are (if they are
            given).  If nothing is shown, you need to look at the repeater's 
            website and see if it's there (very common for open repeaters).  If 
            not, you need to contact the repeater's trustee to get the codes.

     | NOTE#2:  Below is the *generic* commands for Echolink and IRLP.  These don't nessisarily |
     |           match up with the commands required by Svxlink.  It's also important to note   |
     |           that some Echolink and IRLP stations change their commands, access codes, etc  |
     |           to be "unique".  You'll need to contact that trustee of that station to        |
     |           understand what those different commands, access codes, etc are                |

     Some common Echolink codes include the following and you can find more 
     examples at http://www.echolink.org/Help/dtmf_functions.htm :

        2+#                - SVXlink specific command to enable Echolink Mode

        node-number+#      - connects to the remote Echolink node number

                              one example is the 9999 node number which is the Echolink "Echotest"
                              node that will replay anything you say at it (similar to Svxlink's
                              local "parrot" mode)
        C+callsign+#       - connects to the remote Echolink station by callsign.

                             To enter a callsign from the DTMF keypad, you have to
                             press two digits for each letter and a number which
                             assumes your DTMF buttons on your radio conform to:

                               button 1 - Q,Z     button 6 - M,N,O
                               button 2 - A,B,C   button 7 - P,R,S
                               button 3 - D,E,F   button 8 - T,U,V
                               button 4 - G,H,I   button 9 - W,X,Y
                               button 5 - J,K,L   

                            NOTE: Svxlink uses a different key to letter layout

                             - The first digit is the button on which the letter 
                               appears (using 1 for Q and Z - see letter to button
                               layout above)

                             - the second digit is 1, 2, or 3, to indicate which 
                               letter is being entered.  To enter a digit, press 
                               the digit followed by 0.  When finished, end with 
                               the pound key (#).

                             - For example to connect to my station by CALLSIGN,
                               you would enter:

                                C     K  I  6  Z  H  D     #
                               -- +  -- -- -- -- -- --  + --   
                               23    52 43 60 12 42 31     #

        #                  - Disconnects the last connected Internet-facing 
                             Echolink station.  If there are other stations 
                             connected to your Echolink station, their connection
                             won't be affected

        ##                 - Disconnects ALL connected Internet-facing Echolink 


        00                 - Connect to any random node regardless of type

        01                 - Connect to any random -L LINK or -R REPEATER node type

        02                 - Connect to any random conference 

        03                 - Connect to any random single user (non-L or -R) node type


        001                - Connect to a random FAVORITE-configured node regardless 
                             of type.  Favorites are selected either on official Windows
                             Echolink or Android/Ipod clients.

        011                - Connect to a random FAVORITE-configured random -L LINK or -R 
                             REPEATER node type

        021                - Connect to a random FAVORITE-configured conference 

        031                - Connect to a random FAVORITE single user (non-L or -R) node type


        08                 - Announces the currently connected Internet-facing
                             Echolink station

        09                 - Reconnects to the last Echolink node that connected
                             to this station

        *                  - Plays the Echolink information message

        07+callsign+#      - Fetches the status of the remote Echolink station 
                             by callsign

        06+node-number     - Fetches the status of the remote Echolink station 
                             by Echolink node number

        73                 - Disconnect the local system from the remote EchoIRLP

   Don't forget that once you're done with the QSO, unlink from the remote destination
   with the "73" code.

2. Using Echolink computer software only:  
   Installing the free Echolink is simple (available on Windows, iPhone, Android).
   Other non-official solutions are available as well like EchoMac for Apple 
   computers, Svxlink+Qtel for and Linux, etc.  The only other things you need is 
   an Internet connection, a headset (for better TX audio), and valid Echolink 

3. Echolink Smartphones: 

   A free Echolink application is available on the iPhone and Android platforms.  
   All you have to do is enter the respective phone's App Store and install it.  
   Once installed, you need to enter your validated callsign and password (as 
   mentioned above).   Once configured, there isn't any need for a headset as 
   your phone was specifically designed to work with microphones.  BTW, the 
   speakerphone function on Smartphones works well and makes using Echolink very 
   VERY simple to use this way.

45. - D*Star - Digital Voice, Data and other related technologies

So what is Dstar?  Is it voice?  Is it Data?   The answer is it's both.  I always
describe D*star to people as:

  D*star is a technology first created by the JARL (Japanese Amateur Radio League)
  that sends digital voice and data at the same time is D*star frames.  The voice
  can work for local simplex or repeater communications or it can be linked to the
  Internet to cluster repeaters or connect to reflectors just like what you can
  do with Echolink or IRLP.  D*star can do a lot more than just this though and
  I'll touch on some of it's other abilities in a moment.

I bet the next point in your mind is.. "yeah.. but I've heard it's proprietary".
This was a huge concern of mine as well as I don't like like the proprietary aspects 
of it's closed, patented voice vocoder AMBE chip from the DVSI corporation.  What 
I did love is the concept of it's mixed voice/data format which is completely free 
and open from the JARL.  The points that pushed me over the edge to get over my 
issues and try D*star was the following:

  1. Yes, the AMBE2020 vocoder from DVSI is proprietary and patented but did 
     you know once upon a time Single Side Band (SSB) was also patented?
     In the day, radio companies had to license those patents too to offer SSB
     radios until they expired.  Seems amateur radio technology has been this 
     way for some time.

  2. AMBE-based radios are everywhere.  P25 Phase1 (uses the older IMBE chip  
     actually), P25 Phase2, MotoTRBO/DMR, NXDN, Yaesu's new C4FM (4FSK) digital 
     mode, etc.  All of these solutions use the AMBE chip for voice.

  3. The voice quality isn't bad.  No, it's not as good as a strong, full 
     quieting analog FM signal but it's a LOT better than a marginal FM signal 
     when D*star still sounds 100%.

  4. The DVSI company makes these chips available to HAM radio for $20 ea and
     there a lot of homebrew kits coming out to create your own D*star compatible
     system for pretty cheap!

KJ6VU, a local linked analog repeater owner (and D*star repeater owner for that 
matter) recently put it very plainly (paraphrasing here..):

   "Suppose all these various radio technologies were widely deployed in the 
    area so there wasn't any issue of availability of local repeaters.  Next 
    suppose if I were to go to the local HRO where they were selling all of 
    these radios right there in the store:  

       Yaesu's new 4FSK

    Which would I pick?  D*star.  Why? None of the other systems support the 
    mixed voice and data that Dstar does.  None of those systems support the 
    feature rich callsign routing and flexible messaging.  Though some of 
    those new radios might have newer modulation types than Dstar's GMSK but
    none of them have the very flexible and robust Dstar framing standard!"

45.a - Learning D*Star - Setting up a US Trust account and learning about how it all works

  Here are some links for learning more about D*star:

Ok, so let's say you're sold and want to give it a try.  You have a Dstar
radio but now what?  To get on the "current" Dstar (US Trust-based system), 
you first need to setup an account into that system.  That process usually 
only takes an hour or so to do but it can take several hours before the 
local admin can get to approve it.  

Before you continue reading anything else in this section, follow these 
instructions in using one of the local D*star systems that support US 
Trust registration:


   NOTE:  Your Dstar account *will not* be tied in any fashion to this 
          or any other repeater.  The machine above is just one of the 
          many "true Icom stack" machines that you could use.

Once you fill in that above URL's forms and submit your request, then 
read on while you wait:

  NOTE on US Trust registration:  
  It's important to know that you WILL NOT get an automatic email saying 
  you were approved to the US Trust system.  Some admins might manually 
  email you about the approval but that's to their own accord.  I complained 
  about this to the K6MDD folks stating that if the software can't notify 
  the new user, they should ALWAYS send a quick "approved" message.  They 
  didn't want to be bothered by it so the work around for this lack of 
  notification is to *try* to log into that's system:


  If you were approved, you'll be able to log in.  If you haven't been 
  approved yet, you won't be able to login.  Lame but that's reality at 
  the moment.

Once you ARE able to log into that D8star registration URL, again follow 
the detailed steps on the 1st URL shown above:


to finalize your US Trust account.  It's key to follow those steps TO 
THE LETTER or bad things can happen.  Don't worry about any of the IP addresses, 
etc. You don't need those (I don't even know why they expose those).   

So, while you wait for approval, you should start asking yourself "How do I use 
it"?  Here is an outline of key concepts to learn and other links to bring you 
up to speed with Dstar:

  - How to program your Dstar radio (such as an IC-80AD HT)
     - What is the difference between Dstar MY, UR, RPT1, and RPT2 fields?
     - What is the difference between Dstar A, B, C, G "RPT" suffixes?
     - What is the difference between I, E, G, L, U remote callsign / reflector 
     - Using Dstar on simplex vs. intra-repeater vs. inter-repeater (global)

  Here are some good URLs to come up to speed with the high level points:

     - Introduction to Dstar, building your own non-Icom repeater, etc:

     - Additional points are well covered here: 

As you look to program your radio, you might want to look at the "Dstar calculator". 
It can really help guide you to how you would program your radio step by step with 
lists of real repeaters that is updated every day.  Very slick:


Once you mastered all that, now you start getting into some advanced D*star concepts:

  - Broadcast CQCQCQ vs. 
    source-routing (think of it as callsign squelch) vs. 
    repeater linking (everyone on each repeater hears you) vs. 
    callsign routing (find the remote ham anywhere in the world)

  - Here is some good details on the source-routing concept: 
       But here is a clear read on why Source Routing can be very bad: 

  - The "DR mode" on newer Dstar radios as designed by Icom in Japan have a 
    ---REAL--- "difference" of opinion of how to use the CQCQCQ mode vs.
    how it's commonly used in the United States (and possibly elsewhere)
    More about this in a moment.

  - Understanding the differences between the Icom G2 / US Trust vs. 
    DExtra/Xref and Dextra/DCS systems  (Dstar politics) -- I might explain 
    what I know in detail in the future but email me if you wish to hear about
    some of it sooner.  It's all an ugly, sad story it seems.  I can only 
    hope we'll have some convergence some day.

  - Understanding the differences in incompatible D*Star Callsign Servers: 
    US Trust server (K5TIT), Robin Cutshaw (AA4RC), Dutch*star server, etc.
    The repeater owner chooses.. you don't.

  - An excellent tutorial tying together everything you've read from above 
    with specific details on how to use DR enabled radios like the IC-80AD:


  - Along the lines of the excellent write up from the author above, here is
    his D*star blog.  This chronological blog also illuminates how Dstar has 
    fundamentally changed over the years from when it first debuted from 
    Japan to where the Amateur community is taking it:  


  - Some additional points that might be helpful as well:

    - How to get consistent radio memories across radios both digital and


   - Build your data own cable for both radio memories and accessing the
     DV-DD data.. and save yourself from a pointless $40 Icom cable:


Additional reading:

   - Dstar Voice linking Etiquette: 

   - Data over Dstar - One application of the slow-speed data over D*star's 
     slow speed DV-DD (2m/70cm) or high-speed DD (23cm) network: D-RATS
     This powerful programs does integrated offline mapping, Internet email, 
     Winlink 2000 messaging, small file transfers, instant messaging, etc) 

     - D-RATS can also do all that over Dstar but it can ALSO do it purely 
       using the Internet or packet radio too!  See the next section for full 

45b. - D-rats - Email, IM messaging, and more via Internet, D-Star, packet radio, and more

I had heard about D-RATS some time ago as a form of a digital messaging system 
for the slow data side of the D*Star DV mode.  What I've come to realize the 
following and they are NOT what I expected:

  - D-RATS can work *strictly* over the Internet (no radio required) if you want
  - D-RATS can use packet radio (custom KISS traffic or true AX.25 formatted) 
     --> Seems it cannot use Linux's native AX.25 stack today
  - D-RATS can also use the Dstar DV data network
  - D-RATS offers a POP email client (Internet based)
  - D-RATS offers a Winlink internet and VHF / AX.25 packet email client
  - D-RATS offers a file server for serving files
  - D-RATS can create Internet to RF relay systems
  - D-RATS is multi-platform and runs on Linux, Max, Windows, etc

It's truly a very slick software package that the creator of CHIRP has created 
and all this comes in just v0.3.3!   Check out the following presentation for
more details:


Here are some screen captures of it in action:
The chat view where you can see who's on, chat with them, etc:

Able to send/receive POP/SMTP email (TLS-supported), Winlink, ICS213/NTS forms, etc:

Send and receive files:

Before we get started, it's worth mentioning that D-RATS developement stopped on 
4/17/2014 by the primary developer Dan Smith.  The program continued to function
fine with some known bugs but things continued to break for say Winlink, etc.  
The major issue is that both Python2 and GTK2 which D-rats is written in have been
deprecated that means D-rats won't run on those systems. There have been two significant 
glimers of hope as a new fork seems to be starting up that might get things going again:

   # An effort to port to Python3 and GTK3 (forked from maurizioandreotti)

   # A major stabilization and bug fixes of the original code

   # An earlier attemp at bug fixes and move D-rats to a Git repo
   #   the above URL is the same as https://github.com/rafael2k/d-rats

Assuming you're ok with that, let's get it installed!  As usual, we have some dependencies 
that need to be installed first but if you've installed CHIRP from the previous chapter, 
you should be good to go:

       yum install pygtk2 libxml2-python libxslt-python 

    Two unique packages to D-Rats is libxslt-python and python-feedparser but both 
    are easily installed:

       - From the Centos Repo: yum install libxslt-python
       - From the EPEL repo:   yum install python-feedparser

| NOTE (11/1/20):  I have successfully tested the maurizioandreotti fork and cleaned |
|        up D-rats and have found it to be a considerable improvement over the last  |
|        version of the original D-rats.  I need to update this guide to reflect     |
|        using this new repo.                                                        |

Next, I'd recommend to install the last development version of D-rats dated 4/17/14 as 
found at http://d-rats.com/hg/ .  This was http://dev.d-rats.com/drats_daily/ but this 
doesn't seem to be working as of 9/21/16).  This daily versions of code is reliable
and has the full feature set.  

   NOTE:  I have not made this an RPM of this package just yet but it's 
          in the plan

   cd /usr/src/redhat/SOURCES
   #This is broken
   #  wget http://dev.d-rats.com/drats_daily/daily-02232012/d-rats-daily-02232012.tar.gz
   #This works
   wget http://d-rats.com/hg/hgwebdir.cgi/d-rats.hg/archive/tip.tar.gz
   mv d-rats-hg-aa9e84e65b2a.tar.gz d-rats-daily-04172014.tar.gz
   cd /usr/src/redhat/BUILD/
   tar xzvf ../SOURCES/d-rats-daily-04172014.tar.gz
   mv d-rats-hg-aa9e84e65b2a d-rats-daily-04172014
   ln -s d-rats-daily-04172014 d-rats-daily

Ok, that's IT!  Since it's a python program, there isn't anything to compile, etc.
Let's start it up and configure it:

   cd /usr/src/BUILD/D-rats/d-rats-daily
   #As a NON-root user, run the following on a Xwindows'ed environment:


At this point, you should be prompted that since you're a new user, you need
to configure the application.  Fill out the following prompts as follows which
includes some recommendations from Paul, N3TSZ:

     +--> Preferences 
     |          |
     |          +--> Callsign        (don't use any SSIDs here, just your call like KI6ZHD)
     |          +--> Name            (your full name)
     |          +--> Sign-on/off msg (customize it a bit if you like)
     |          |
     |          +--> Paths
     |          |       +--> File Transfer path: /var/ftp/pub   (this can be any path you wish)
     |          |                                              (make sure that directory is writable)
     |          |                                              (with say a chmod 777)
     |          |
     |          +--> GPS
     |          |       +--> (Change your Lat/Long/Alt and comment if you so wish)
     |          |       +--> APRS symbol   (See http://db.aprsworld.net/datamart/symbol-count.php)
     |          |
     |          +--> Appearance
     |          |       +--> Notice RegEx:        (put in your callsign here so you'll get 
     |          |       |                            a notice when your callsign is used)
     |          |       |
     |          |       +--> Ignore RegEx: [QST]  (put reoccurring QSTs in a unique tab)
     |          |
     |          +--> Chat
     |          |       +--> Scrollback lines: 9999
     |          |
     |          +--> Messages
     |                  +--> Enable: Automatically Forward Messages
     |                  +--> Queue flush interval: 30
     |                  +--> Station TTL: 600
     |                  +--> My Winlink SSID: 10
     +--> Radio
     |      +--> Port: net:ref-d-rats.com:9000   NOTE: By default, only Internet based 
     |      |                                          connections are allowed on port
     |      |                                          9000.  For RF connections, use
     |      |                                          port 9001.
     |      |
     |      +--> For Dstar radio connections, use the SERIAL connection (more to come
     |      |       here -- add udev serial device :: IC80AD runs at 9600 baud
     |      |
     |      +--> For packet radio stuff, it's not clear how it works since it's AX.25
     |              support asks for a serial port which it shouldn't :: researching
     |              but I suspect D-Rats cannot use Linux's AX.25 stack
 Click on OK

Now, once everything is configured for D-Rats, do the following:

    1. Click on the Chat tab
    2. Goto File --> Ping Station
    3. Type in the Station: CQCQCQ
    4. Select the port RAT
    5. Hit OK

That above step sends out broadcast ping which will populate your callsign list 
with everyone that's currently logged into the the default "RAT:9000" ratflector.

Next, get some key files:

    1. Click on the Files tab
    2. In the far-right column, make sure that K2TJW is shown
    3. In the middle-right column in the "Station" field, type in K2TJW and click on
       the connect icon
    4. Highlight the "ratflector-list-03022012.txt" and download it

       NOTE:  D-rats does not download files anything faster than what a standard
              Dstar radio's DV-Voice data can support: 999Bytes/sec

    5. Download the Ratflector list 03022012.txt file

That's it for now.  I plan on setting up a D-Rats Internet to RF gateway and 
ratflector in the future!

  PS.  If you have a local Winlink system available to you, try sending a 
       "email" form message to yourself with one KEY point:

           Destination Callsign : Add the prefix "WL2K: 

       to send a Winlink message.  You'll soon notice in the "Messages" tab 
       that the message just showed up.  Fast, nothing to configure, etc.  Wow.. 
       its that's simple!

46. - DSD - Decoding MotoTrbo, P25, ProVoice, NXDN, etc

  | To be updated for Centos6 |

I'm still working on this one but the DSD toolset seems very robust to 

    * P25 Phase 1
    * ProVoice EDACS Digital voice
    * X2-TDMA - Motorola public safety TDMA system with P25 style signaling 
                (mostly based on DMR)
    * DMR/MOTOTRBO - Digital Mobile Radio standard
    * NXDN - 9600 baud (12.5 kHz) NEXEDGE and 4800 baud (6.25 kHz) NEXEDGE/IDAS 

    * C4FM modulation
    * GMSK modulation (including GMSK and other filtered 2/4 level FSK)
    * QPSK modulation (sometimes marketed as "LSM") 

    The following formats are currently under investigation or development:
    * P25 Phase 2 - standard not finalized yet, vocoder is supported by mbelib
    * OpenSky - four slot format vocoder may be supported by mbelib. Will not be 
                supportable if it is determined that voice encryption is not 
    * D-STAR - Voice frames recognized, vocoder not supported by mbelib. May 
               be possible to pass voice bits to DVDongle. 



   - Download the newest code (you have to wait 45 seconds per file to download it)

   - The files are double-wrapped so you'll have to un-tar and then un-tgz the files:

     #I will make an RPM for this shortly

       mkdir /usr/src/archive/DSD
       cd /usr/src/archive/DSD
       tar xvf mbelib-1.2.3-src.tar
       tar xzvf mbelib-1.2.3.tar.gz
       tar xvf dsd-1.4.1-src.tar 
       tar xzvf dsd-1.4.1.tar.gz

       cd mbelib-1.2.3
       make install

       #Make sure the LDPATH was updated
       /sbin/ldconfig -p | grep mbe

       cd ../dsd-1.4.1
       make install

    To test this system, I did a few things:

       - Installed audacity (a great sound editing and viewing tool):

           yum install audacity

       - Connected the output of the Kenwood D710 VFO-B (external TNC) to the 
         Mic Input of the laptop (AC97)

       - D710:
           - Tuned the VFO-B to a known MotoTRBO frequency 
           - Set EXT. Data speed to 9600 (discriminator tap)

       - NOTE:  do NOT try to use Fldigi's "RX audio capture" feature
                as it only samples at 8000.  DSD wants 48k

       - Find the audio input device you want to record with:

            arecord -l

         #16bit, little endian, 1 channel (mono), 48k samples, no end duration
         # output is wav
         arecord -vv -f S16_LE -c1 -r48000 -d 0 -t wav --device=hw:1,0  /tmp/capture.wav

  | To be updated for Centos6 |

I'm still working on this one but the DSD toolset seems very robust to 

47. - Baudline - Audio and file spectral analysis and visualization tool

Baudline is a powerful audio and waveform analysis tool that can either listen from soundcard
inputs or WAV files.  The tool is somewhat older and hasn't received any updates in a while
but it still works very well.  

To get started, you'll want to use the posted binaries as the source code is an older version:
   mkdir /usr/src/archive/Baudline
   cd /usr/src/archive/Baudline
   wget http://www.baudline.com/baudline_1.08_linux_x86_64.tar.gz

Uncompress it

   tar xzvf baudline_1.08_linux_x86_64.tar.gz

Now run it.  For example, I'm doing analysis on this Exar 2400bps PSK waveform file saved into
a WAV file.  This comes from an MFJ1270C AX.25 TNC with the 2400baud addon modem board.  If
you have a WAV file that you're not sure of it's file parameters, try using the "file" command
to get details:

   file 2k4_short.wav
   2k4_short.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz

So let's run it.  Baudline 1.08 only works with the OSS sound system which is very old.  I 
also couldn't get it to work right with the ALSA/OSS "aoss" wrapper but this works decently enough:
   ./baudline -stdout /usr/src/archive/Inspectrum/2k4_short.wav | aplay -c 1 -f S16_LE -r 44100

48. - Inspectrum - Offline radio signal analyser

Inspectrum is a signal processing program that allows the user to analyse signals typically 
used in RF communications.   
A zoomed out view of a signal from MFJ-1270C TNC with a 2400baud Exar modem board

A zoomed in view of a signal from MFJ-1270C TNC with a 2400baud Exar modem board

A great example of using this program is the following article 
about decoding dial up modems and understanding all their training sequences.  The author 
completely decoded things using Inspectrum and a few other tools:


Other interesting tools include:


48a. - Installing Liquid-DSP first

Ok, to get started, we first need to install Liquid-DSP which is a DSP library for all
the complex DSP processing.

It seems that Liquid-DSP is still under heavy development but it's last official release
was in October 2017.  As such, it seems it would be best to go with the Git repo code.
So let's get started.

   cd /usr/src/redhat/BUILD
   mkdir liquid-dsp-git
   cd liquid-dsp-git

   Getting the code the Git way (recommended):
   #If this is your first time doing this
   git clone https://github.com/jgaeddert/liquid-dsp.git

      #You've previously downloaded a previous version of the repo, refresh it
      git pull

   Let's get some details about the downloaded Git code.  Run the following commands:

      cd liquid-dsp
      echo "Git hash: `git log | head -n3 | grep -i -e commit -e date`"
      grep "AC_INIT" configure.ac

   I see the following output from these commands and you'll need to copy that hex string 
   in a moment:

         Git hash: commit b1f8da417960198af87b244337f0dc06a2df65db
         Date:   Tue Apr 16 13:07:32 2019 -0400



   Ok, lets prepare to create the Liquid-DSP archive
   This creates the configure script

   Now go back on directory:
      cd ..

   Next, update this "ln" command and the tar command below to reflect the correct version name
   from above.  Change this 1.3.1 number to whatever is shown from the above commands:
      ln -s liquid-dsp liquid-dsp-1.3.1git

   Now we need to create the archive with the correct version, Git commit date and GIT hash.
   This is done using the first 8 characters (MSB - most significant bits) of the Git hash 
   found above:
      tar czvf /usr/src/redhat/SOURCES/liquid-dsp-1.3.1git-20181201gitb1f8da41.tgz liquid-dsp-1.3.1git/* --exclude liquid-dsp-1.3.1git/.git

   (Optional): You can now optionally delete the Git repo (I'd recommend to keep this directory it if you plan on 
   updating your liquid-dsp code from Git often):
      rm -Rf /usr/src/redhat/BUILD/liquid-dsp-git

   Now let's get a SPEC file to be used to package things into an RPM
   cd /usr/src/redhat/SPECS
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/liquid-dsp-git.spec

      #This SPEC file was originally sourced from https://domsch.com/fedora/sdr/liquid-dsp.spec

   Now you need to update the spec file:

      # I recommend to make a backup of the spec file first
      mkdir Old
      cp liquid-dsp-git.spec Old/liquid-dsp-git.spec

      vim liquid-dsp-git.spec

      # You need to update the git_commit, git_date, version, and Release variables to 
      # reflect or the right revisions of the code found above.  As of 04/25/19, that would be:
         %global git_commit b1f8da417960198af87b244337f0dc06a2df65db
         %global git_date 20190425

         Version:        1.3.1git

       and near the bottom of of the file, add:

          * Sat Apr 25 2019 David Ranch <dranch@trinnet.net>
          - New version for Centos

   OK!  You're ready to build it!  Let's go:

      Centos 6
      #For Centos6 users with x86_64
      #  build took 0min 50s on an i5-2430 2.40GHz laptop w/ 4GB RAM and a SSD drive
      # Do NOT run this rpmbuild command as the root user
      time rpmbuild -bb --target=x86_64 liquid-dsp-git.spec

   Assuming the build went well, install it:

     sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/liquid-dsp-1.3.1git-1.20190425gitb1f8da41.el6.x86_64.rpm \

48b. - Install newer GCC C++ via SCL

Inspectrum requires C++11 support which came in GCC v4.8.1 but Centos6 doesn't have since it comes with 
GCC 4.4.7.  Fortunately, there is a workaround here: SCL.  SCL is a method to install alternative
versions of key packages without changing the default version.

Following the example at https://edwards.sdsu.edu/research/c11-on-centos-6/ , do the following:

   # Make sure your system is fully updated
   sudo yum update

   # Now install the SCL system
   sudo yum install centos-release-scl
   sudo yum update

   # See what version of the DevToolset is available.  As of 4/27/19, it was at devtoolset-8 which
   #  includes GCC 8.2.1
   yum list all | grep devtoolset

   # Install the newest DevToolSet (update the line if there is a newer version)
   sudo yum install devtoolset-8-gcc devtoolset-8-gcc-c++ devtoolset-8-make

So now test things out.  First, see what the default GCC version is showing:

      gcc --version
      gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
      Copyright (C) 2010 Free Software Foundation, Inc.
      This is free software; see the source for copying conditions.  There is NO

   Now enable the SCL version and try it again:

      scl enable devtoolset-8 bash
      gcc --version
      gcc (GCC) 8.2.1 20180905 (Red Hat 8.2.1-3)
      Copyright (C) 2018 Free Software Foundation, Inc.
      This is free software; see the source for copying conditions.  There is NO

Cool.  It works!

48c. - Compiling Inspectrum

Last up is to build Inspectrum.   Looking at the newest Git commits vs. the lastest 0.2.2 version 
released on June 6, 2018, it seems like it would be good to to go with the Git version.  Follow
these steps to do that:

   cd /usr/src/redhat/BUILD
   mkdir inspectrum-git
   cd inspectrum-git

   Getting the code the Git way (recommended):
   #If this is your first time doing this
   git clone https://github.com/miek/inspectrum.git

      #You've previously downloaded a previous version of the repo, refresh it
      git pull

   Let's get some details about the downloaded Git code.  Run the following commands:

      cd inspectrum
      echo "Git hash: `git log | head -n3 | grep -i -e commit -e date`"

   I see the following output from these commands and you'll need to copy that hex string 
   in a moment:

         Git hash: commit cd115c22cf4d8d7d3ed18e549d6569abf71fa32c
         Date:   Sat Dec 1 17:06:45 2018 +0000

   Ok, lets create the Inspectrum archive
   Now go back on directory:
      cd ..

   Next, update this "ln" command and the tar command below to reflect the correct version name
   from above.  Change this 0.2.2 number to whatever is shown from the above commands:
      ln -s inspectrum inspectrum-0.2.2git

   Now we need to create the archive with the correct version, Git commit date and GIT hash.
   This is done using the first 8 characters (MSB - most significant bits) of the Git hash 
   found above:
      tar czvf /usr/src/redhat/SOURCES/inspectrum-0.2.2git-20190427gitcd115c22.tgz inspectrum-0.2.2git/* --exclude inspectrum-0.2.2git/.git

   (Optional): You can now optionally delete the Git repo (I'd recommend to keep this directory it if you plan on 
   updating your inspectrum code from Git often):
      rm -Rf /usr/src/redhat/BUILD/inspectrum-git

   Now let's get a SPEC file to be used to package things into an RPM
   cd /usr/src/redhat/SPECS
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/inspectrum-git.spec

   Now you need to update the spec file if Inspectrum has been updated since I wrote this:

      # I recommend to make a backup of the spec file first
      mkdir Old
      cp inspectrum-git.spec Old/inspectrum-git.spec

      vim inspectrum-git.spec

      # You need to update the git_commit, git_date, version, and Release variables to 
      # reflect or the right revisions of the code found above.  As of 04/25/19, that would be:
         %global git_commit cd115c22cf4d8d7d3ed18e549d6569abf71fa32c
         %global git_date 20181201

         Version:        0.2.2git

       and near the bottom of of the file, add:

          * Sat Apr 27 2019 David Ranch <dranch@trinnet.net>
          - New version for Centos

   OK!  You're ready to build it!  Let's go:

      Centos 6
      #For Centos6 users with x86_64
      #  build took 0min 42s on an i5-2430 2.40GHz laptop w/ 4GB RAM and a SSD drive
      # Do NOT run this rpmbuild command as the root user
      time rpmbuild -bb --target=x86_64 inspectrum-git.spec

   Assuming the build went well, install it:

     sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/inspectrum-0.2.2git-1.20181201gitcd115c22.el6.x86_64.rpm

48d. - Installing Inspectrum Tools (convert WAV files)

Inspectrum cannot read WAV files directly so here is a tool to convert files.  To get
started, we need to install a python library first:

   sudo yum install scipy

Next, create the following script per https://github.com/miek/inspectrum/issues/113

   vim /usr/local/bin/wavtocp32.py

   # This script requires the scipy python RPM to be installed
   import scipy.io.wavfile
   import sys

   filename = sys.argv[1]

   fs1, y1 = scipy.io.wavfile.read(filename)

   assert y1.dtype.name == 'int16'

   stereo_to_complex = lambda a: a[0] + a[1]*1j
   y1 = y1/65536.

   y1 = stereo_to_complex(y1.T).astype('complex64')

   filename = filename.replace('wav', 'cf32')


Assuming you have a WAV file to convert, give it a try:

   /usr/local/bin/wavtocf32.py 2k4_short.wav

Now try loading in the cf32 file with Inspectrum:

   inspectrum -r 44100 -f LE16 2k4_short.wav

50. - Troubleshooting and Tools

50.a - Serial port troubleshooting

Serial port Troubleshooting
When troubleshooting PTT circuits say for my first setup with a Kenwood
TH-F6A ( http://www.dunmire.org/projects/DigitalCommCenter/index.html --> PTT), 
I needed tools to make sure the serial ports were working properly.  Finding 
useful serial tools wasn't as easy as I thought it would be.  As such, I've
put together a few tools that I like to use:

Classic Linux tools:

      #finding a process that's using the serial port and thus initializing it
      sudo ls -l /proc/[0-9]*/fd/* |grep /dev/ttyUSB0

      #Alternative approach of finding a process that's using the serial port and thus initializing it
      sudo yum install lsof
      sudo lsof /dev/ttyUSB0

      #Confirm the OS thinks the DTR line should be high on the port
      # If you're using real serial ports like ttyS0, use this command
      sudo cat /proc/tty/driver/serial

      #If you're using USB serial ports, use this command:
      sudo cat /proc/tty/driver/usbserial

      #See what else might be set on the serial port
      stty -F /dev/ttyUSB0

    - Shows the state of the various serial pins and what not. Very helpful.

      #from the EPEL repo:
      yum install statserial
      statserial /dev/ttyUSB0

    - Allows for setting speeds, flow controls, etc.  much of this program is 
      no longer needed as all programs that use a serial port will already 
      initialize the serial port again

       NOTE: Though setserial can display the current stat of a serial port's
             data lines, I've found that it's initialization routine will SET
             or ALTER the state of the port's hardware flow control lines 
             especially on USB-based serial ports.  Once these programs 
             exit, it does not bring things lines down and thus a Kenwood 
             D710 in Echolink mode will key up and NEVER unkey!  Very bad!
             See "statserial" above which avoids this issue.

    - A tool to send lower level commands with controlled formatting to tty 

    - This program comes as part of the perl-Device-SerialPort package and has
      the ability to display the current state of the serial lines (buggy?) and
      then reset those lines to a sane state when done.  This is critical if a 
      serial port is keying up say a Kenwood D710 radio via the RTS line (stupid
      design) and you can't unkey the radio!!

      DEAD END:
    - In troubleshooting serial port issues, statserial and setserial only
      do so much.  serlook can show you a LOT more information if needed.
      Unfortunately, it requires a version of lib-qt-2.12+ but 
      Centos5 only comes with 2.10 and much has changed between
      those two versions.  Centos6 is a even worse situation.

50.b - Serial port Terminal programs

Serial Terminal Programs:
  - Minicom 
    - Solid but older ncurses-based terminal program which interfaces to anything 
      serial.  Includes support for phonebooks, X/Y/Zmodem, scroll back buffering and 
      logging, HW/SW flow control, etc.  

            NOTE: When changing serial ports, BAUD rates, etc., you have to save the 
                  settings, exit the program, and restart minicom for the changes to 
                  take effect

  - Putty
     - Runs on Windows and Linux
     - Supports SSH, TELNET, RLogin, RAW, and Serial 
     - Very feature packed program

  - Moserial
    - A Cutecom replacement intended to be more modern 
    - https://wiki.gnome.org/action/show/Apps/Moserial?action=show&redirect=moserial

  - Cutecom
    - A simple QT4 based terminal program that supports controllable CR vs CRLF for
      newline, setting of different character delay, logging, HW/SW flow control,
      display of HEX output, etc.

  - SyncTERM - tailored for classic BBS systems - active as of Aug 2013
    - Windows, Linux, OSX support using SDL, X11, or NCURSES with hybrid mouse support
      and scrollback support
    - TELNET, Rlogin, SSH, RAW, and serial communications, X/Y/Zmodem support, also 
      supports Rlogin, Atari ATASCII, Commodore PETSCII, ANSI card symbols, ANSI Music, 
      ANSI character pacing, Door support, dialup phone books, 

  - Gtkterm
    - Simple but modern terminal client written in GTK
    - Supports scrolling, copy/paste, serial line status, HW/SW flow control, etc

  - picocom
    Light weight terminal program

  - Screen
    - The classic multi-terminal tool also supports detachable terminals controlling 
      serial ports - can also show serial port status with Control-A + i

  - Coolterm 
    - Supports Mac, Win, Linux (minimal support) - displays serial port pin status, 
    - Supports receiving / sending ASCII / HEX

  - Kermit
      - Classic Unix serial terminal program

  - EmTec ZOC (commercial) running under Wine

    - This simple program can help set pins high/low which is very helpful for 
      troubleshooting, etc.

50.c - Serial port KISS tools

    - This program can properly control a Kenwood D710 TNC and set it's various 
      TNC speeds, commands, etc.  I tried doing all of this using stty commands 
      before but it wasn't reliable.  This tool makes it reliable!  Used in my
      packetrig.sh script:

         Newer version: https://github.com/fmarier/tmd710_tncsetup
            Older version: http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/misc/tmd710_tncsetup.c

      To build this tool, do the following:

         #These steps assume you already have GCC and the other required toolchains installed
         cd /tmp
         wget https://raw.githubusercontent.com/fmarier/tmd710_tncsetup/master/tmd710_tncsetup.c
         gcc -o tmd710_tncsetup tmd710_tncsetup.c
         chmod 755 tmd710_tncsetup
         mv tmd710_tncsetup /usr/local/bin/

50.d - Enabling debugging in programs via coredumps

To enable debugging objects for troubleshooting, you need to recompile the program.  In this example, 
we rebuild the "axspawn" tool from the ax25tools package.  The main task is to enable the makefile to 
include the "-g" debugging as well as disable of any compiler optimizations:

   #The following steps all assumes you followed the previous section to build the AX.25 stack

   cd /usr/src/BUILD
   wget https://github.com/ve7fet/linuxax25/archive/master.zip
   mv master.zip linuxax25.zip
   cd linuxax25-master/ax25tools

   #Create the configure script - only needed for direct git pulls

   #For C based code, enable debugging objects and disable any compiler optimizations which break debugging"
   export CFLAGS="-g -O0"

   #For C++ based code, enable debugging objects and disable any compiler optimizations which break debugging"
   export CXXFLAGS="-g -O0"


   $ make
   make  all-recursive                                  
   make[1]: Entering directory `/usr/src/redhat/BUILD/ax25tools-1.0.5'
   Making all in ax25                                                
   make[2]: Entering directory `/usr/src/redhat/BUILD/ax25tools-1.0.5/ax25'
   Making all in axgetput                                                 
   make[3]: Entering directory `/usr/src/redhat/BUILD/ax25tools-1.0.5/ax25/axgetput'
   gcc -DHAVE_CONFIG_H -I. -I../..  -D_GNU_SOURCE   -g -O0 -MT axgetput.o -MD -MP -MF .deps/axgetput.Tpo -c -o axgetput.o axgetput.c
                                           these items must be present

  # Once the build completes, you can package it up per the previous AX.25 build section.

  Still needed:
     - how to enable coredumps on your OS: https://www.thegeekdiary.com/how-to-enable-core-dump-for-applications-on-centos-rhel/

     - how to run a backtrace against a coredump: http://www.brendangregg.com/blog/2016-08-09/gdb-example-ncurses.html

51. - Other useful tools for the Linux HamShack

  | to be updated for centos6 |

Navtex java decoder - http://www.frisnit.com/navtex/?id=decoder

     unzip JavaNAVTEX_0.2.zip
     cd JavaNAVTEX
     java -jar ./JavaNAVTEX.jar

         sound card selection doesn't seem to work

PACTOR-1, AMTOR, GTOR, RTTY soundcard program
Out of date and unmaintained (unfortunately) Based on hfkernel by Tom Sailer, 
with graphic interface (gtk+), spectrum display, logbook, textmacros, 
English and German help.


Appendix A - Centos updating quirks

Appendix A - Centos updating quirks

As you might suspect, adding in all these third party repositories, overriding
stock RPMs with newer ones, etc. can break things.  You won't usually see this
until you try to update your machine with:

   yum update

When things break, what should you do?  Well, this section addresses the issues 
I've seen so far and their solutions.  If you bump into a new problem and you
don't know what to do, email me and I'll give you a hand:

Situation #1 - Glibc conflicts with ax.25 objects
  This is covered above in section:  3c.ax25installing

Situation #2 - Qt conflicts
Let's say you run "yum update" and then see the following:

--> Finished Dependency Resolution
Error: Package: 1:qt-sqlite-4.6.2-28.el6_5.x86_64 (updates)
           Requires: qt(x86-64) = 1:4.6.2-28.el6_5
           Installed: 1:qt-4.6.2-26.el6_4.x86_64 (@updates)
               qt(x86-64) = 1:4.6.2-26.el6_4
           Installed: 1:qt-4.8.4-14.el6.x86_64 (installed)
               qt(x86-64) = 1:4.8.4-14.el6
           Available: 1:qt-4.6.2-28.el6_5.x86_64 (updates)
               qt(x86-64) = 1:4.6.2-28.el6_5
Error: Package: 1:qt-x11-4.6.2-26.el6_4.x86_64 (@updates)
           Requires: qt-sqlite(x86-64) = 1:4.6.2-26.el6_4
           Installed: 1:qt-4.8.4-14.el6.x86_64 (installed)
               qt-sqlite(x86-64) = 1:4.8.4-14.el6
           Removing: 1:qt-sqlite-4.6.2-26.el6_4.x86_64 (@updates)
               qt-sqlite(x86-64) = 1:4.6.2-26.el6_4
           Updated By: 1:qt-sqlite-4.6.2-28.el6_5.x86_64 (updates)
               qt-sqlite(x86-64) = 1:4.6.2-28.el6_5
 You could try using --skip-broken to work around the problem

It's strange that Yum is getting confused but it's not hard to fix.  
To solve this, you need to install the new packages manually:

  # Your version numbers and / or packages might be different so find the
  # closest Centos mirror at http://www.centos.org/download/mirrors/ and
  # substitute as required
  cd /tmp
  wget http://mirror.stanford.edu/yum/pub/centos/6/updates/x86_64/Packages/qt-4.6.2-28.el6_5.x86_64.rpm
  wget http://mirror.stanford.edu/yum/pub/centos/6/updates/x86_64/Packages/qt-devel-4.6.2-28.el6_5.x86_64.rpm
  wget http://mirror.stanford.edu/yum/pub/centos/6/updates/x86_64/Packages/qt-sqlite-4.6.2-28.el6_5.x86_64.rpm
  wget http://mirror.stanford.edu/yum/pub/centos/6/updates/x86_64/Packages/qt-x11-4.6.2-28.el6_5.x86_64.rpm

  # NOTE: you also might need to download and install the i686 packages too depending
  #       if your setup requires it

# For the curious: If you just try to install these packages right now, Yum shows it's confusion:
# Of course the 4.8 package is newer than the 4.6 package but I'm trying to upgrade the 4.8 packages!  Duh...
  Preparing...                ########################################### [100%]
  package qt-1:4.8.4-14.el6.x86_64 (which is newer than qt-1:4.6.2-28.el6_5.x86_64) is already installed
  package qt-x11-1:4.8.4-14.el6.x86_64 (which is newer than qt-x11-1:4.6.2-28.el6_5.x86_64) is already installed
  package qt-devel-1:4.8.4-14.el6.x86_64 (which is newer than qt-devel-1:4.6.2-28.el6_5.x86_64) is already installed

  # Anyway, let's fix it:

  #become root

  #  Note: it's VERY VERY important that you do a Yum INSTALL and NOT and a yum *upgrade*.  If you do
  #        and upgrade, it will DELETE your qt 4.8 packages.  If you did that by accident, it's not hard
  #        to fix it as you probably still have those packages in /usr/src/redhat/RPMS/X86_64
  rpm -ivh --force qt-4.6.2-28.el6_5.x86_64.rpm qt-devel-4.6.2-28.el6_5.x86_64.rpm qt-sqlite-4.6.2-28.el6_5.x86_64.rpm \

Situation #3 - Other RPM spec fixes
rpmbuild will exit if all files in the $RPM_BUILD_ROOT directory are not found in 
the %files section (or in a file that lists file names used with the -f option) of
an RPM .spec file.  I experienced this problem before when building other packages. 
To fix this, try this:

   echo "%_unpackaged_files_terminate_build 0" >> /etc/rpm/macros

then re-try the build from your spec file

Appendix B - KI6ZHD Running Packet notes for QTH

  | NOTE:                                                               |
  |       This is probably not useful information to you but it might   |
  |       be.  Up to you.. this is legacy notes that need to be removed |

10:29am 5/29/09 (Friday)

Callsign  Port Packets   Last Heard
W6XSC-6    vhfdrop       2   Fri May 29 11:58:33 -- BEACON: Santa Clara County Digi Milpitas.
K6KP-6     vhfdrop      12   Fri May 29 11:58:09
W6XSC-2    vhfdrop       2   Fri May 29 11:56:06
K6SNY      vhfdrop       5   Fri May 29 11:55:36
W6XSC-5    vhfdrop      84   Fri May 29 11:43:31
KE6AFE-10  vhfdrop       1   Fri May 29 11:01:12
KI6ZHD-8   vhfdrop     146   Fri May 29 10:22:06  -- me

With soundmodemconfig, I *also* see the following that axlisten doesn't:
Packet: fm WR6ABD-0 to ID-0 UI  pid=F0

Packet: fm WR6ABD-0 to BEACON-0 UI  pid=F0
Loma Pioneer Repeater Club www.LPRC.net

Nothing as of 10:29am 5/29/09 (Friday)


Good packet sessions :

broadcast K6KP-6 is a BBS run by KN6PE

vhfdrop: fm K6KP to MAIL ctl UI^ pid=F0(Text) len 67
0040  TDM

   fm K6KP-6 to KI6ZHD-8 ctl I10+ pid=F0(Text) len 104
   0000  [JNOS-1.10m-IHM$]..Welcome ki6zhd,.to the K6KP-5 TCP/IP Mailbox
   0040  (JNOS 1.10m (8088))..Currently 1 user...
   fm K6KP-6 to KI6ZHD-8 ctl RR1-
   fm K6KP-6 to KI6ZHD-8 ctl I11+ pid=F0(Text) len 110
   0000  '?' or 'h command` for help. Please send local messages to 'user
   0040  s'..Questions to sysop..Enjoy! -- jim kn6pe...
   vhfdrop: fm K6KP-6 to KI6ZHD-8 ctl I12+ pid=F0(Text) len 112
   0000  You have 0 messages..Area: ki6zhd Current msg# 0..?,A,B,C,D,E,F,
   0040  H,I,IH,IP,J,K,L,M,N,NR,O,P,PI,R,S,T,U,V,W,X,Z >.

W6XSC-2 on 144.910 doesn't work
W6XSC-5 on 144.910 is controller node

a few things:

XSCNOD:W6XSC-5} Ports:
  1 144.910 Mhz 1200 Baud
  2 223.660 Mhz 1200 Baud
  3 441.500 Mhz 1200 Baud
  4 Bridge to County

#Seems the PORTS command there is mis-configured as I'm connected on 144.910
#but when I list port#3 (441.500), I get:


XSCNOD:W6XSC-5} Heard List for Port 3
KI6ZHD-8   09:59:11
W6XSC-6    09:57:30
K6KP-6     09:57:07
WR6ABD     09:57:00
W6MOL      09:56:23
W6XSC-2    09:54:55
K6SNY      09:54:33
WD0DNM     09:48:13
KE6AFE-10* 09:36:11
K6KP       09:34:55
KB6YNO-10* 09:19:45
K6SNY-1    08:59:43
KA3L-2     07:55:20
AD6TL-3    06:26:28
WB6EOC     01:50:46
WB6TMS     23:22:33
WB6TMS-15  22:42:33
K6OTT      22:09:21
SNYEOC     21:51:43
K3OES-10   19:36:56


XSCNOD:W6XSC-5} G8BPQ Network System V4.08a (133)
Uplink 3(KI6ZHD-8)

call vhfdrop WR6ABD  --- also known as LPRC2 (with less commands)

ENTER COMMAND:  B,J,K,L,R,S, or Help >
LT            LIST TRAFFIC
S(end) call   SEND MESSAGE TO callsign
ENTER COMMAND:  B,J,K,L,R,S, or Help >

ENTER COMMAND:  B,J,K,L,R,S, or Help > J L
K6ACS-10   > BEACON    05/29/2009 16:05:38
KB6YNO-10* > BEACON    05/29/2009 16:18:53
K6SNY-1    > KI6RLD    05/29/2009 16:23:28
KI6RLD     > K6SNY-1   05/29/2009 16:23:29
W6MOL      > BEACON    05/29/2009 16:25:33
AD6TL-3    > BEACON    05/29/2009 16:25:36
N6FRG-5    > ID        05/29/2009 16:27:34
WD0DNM     > ID        05/29/2009 16:28:22
WA6PIC*    > BEACON    05/29/2009 16:28:52
WB6TMS     > ID        05/29/2009 16:31:32
K6KP       > MAIL      05/29/2009 16:34:06
W6XSC-2    > CQ        05/29/2009 16:34:32
KE6AFE-10  > BEACON    05/29/2009 16:35:19
K3OES-10   > ID        05/29/2009 16:35:58
W6XSC-5    > ID        05/29/2009 16:38:15
W5OES-10   > ID        05/29/2009 16:38:21
K6SNY      > BEACON    05/29/2009 16:38:44
KI6ZHD-8   > WR6ABD    05/29/2009 16:38:59

ENTER COMMAND:  B,J,K,L,R,S, or Help >