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


http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html

dranch at trinnet dot net
KI6ZHD

03/04/2024.0


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.                                                                            |
   +-------------------------------------------------------------------------------------------------+

Index




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
    details.

http://creativecommons.org/licenses/by-nc-nd/3.0/



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!

IMPORTANT:
----------
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:

      https://fedoraproject.org/wiki/SIGs/AmateurRadio/Packages

    +----------------------------------------------------------------------+
    | 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)
       and
   http://packages.debian.org/unstable/hamradio/
     (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:

   http://download.opensuse.org/repositories/hamradio/openSUSE_Factory/src/
      and
   http://download.opensuse.org/repositories/hamradio/openSUSE_Tumbleweed/


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

   http://radio.linux.org.au/


   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



   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 
versions.


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:

    http://wiki.centos.org/HowTos/SetupRpmBuildEnvironment

         or

    http://www.g-loaded.eu/2009/04/24/manually-prepare-the-rpm-building-environment/


  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?

    /usr/src/redhat/BUILD 
        - 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.

    /usr/src/redhat/BUILDROOT 
        - used by some other spec files.. same definition as the BUILD 
          directory above

    /usr/src/redhat/SOURCES 
        - this is where you download the new version of Fldigi but don't 
          uncompress it

    /usr/src/redhat/SPECS 
        - this is where you put the spec files like fldigi.spec

    /usr/src/redhat/SRPMS 
        - 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



Compiling:
----------
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:

   %_RPM_BUILD_NCPUS 4


   
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:

      http://www.rpmfind.net/linux/rpm2html/search.php


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..)

             /etc/yum.repos.d/CentOS-Base.repo
             --
             [base]
             . . .
             priority=1
             protect=1
             
             [updates]
             . . .
             priority=1
             protect=1

             [extras]
             . . .
             priority=2
             protect=0

             [centosplus]
             . . .
             priority=2
             protect=0

             [contrib]
             . . .
             priority=3
             protect=0



          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

             priority=4


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

               http://repoforge.org/use/

               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.

             /etc/yum.repos.d/rpmforge.repo
             --
             [rpmforge]
             . . .
             enabled = 1
             priority=12
             protect = 0

             [rpmforge-extras]
             . . .
             enabled = 1
             priority=14
             protect = 0

             [rpmforge-testing]
             . . .
             enabled = 1
             priority=15
             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
                  file.

          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
                        or
                      Centos5 - http://elrepo.org/elrepo-release-5-3.el5.elrepo.noarch.rpm
                   # Edit /etc/yum.repos.d/epel.repo and add to each stanza

                     [elrepo]
                     . . .
                     priority=7
                     protect = 0

                     [elrepo-testing]
                     . . .
                     priority=15
                     protect = 0

                     [elrepo-kernel]
                     . . .
                     priority=10
                     protect = 0

                     [elrepo-extras]
                     . . .
                     priority=11
                     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:

                   http://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F

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

                   # Edit /etc/yum.repos.d/epel-testing.repo and add to each stanza
                   [epel-testing]
                   . . .
                   priority=15
                   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 
                            replacement.

                            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
            exclude=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) 
                         http://www.amazon.com/FT4232HL-Professional-Retention-Certified-Microsoft/dp/B004ETDC8K

                 4port - DigiKey - USB-COM232-PLUS4 (no enclosure)
                         http://www.digikey.com/product-detail/en/USB-COM232-PLUS4/768-1034-ND/2139296 

                 -----

                 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:
                         https://twitter.com/marcan42/status/695292366639378433

              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 
     obvious!

     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 
     below:
 
     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:

              /dev/serial/by-id/usb-FTDI_usb_serial_converter_FTCAWZIA-if00-port0

          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 and/or brltty taking over your Serial ports

      IMPORTANT!!!

           modemmanager and/or brltty 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 
          playback

     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
                                                           type


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 
device!

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

   /etc/modprobe.d/alsa.conf
   --
   #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 that helps you but if you have multiple devices that don't have unique 
USB VID:PIDs or product names or serial numbers, things will get difficult.  The below
URL can give you more ideas to create consistent enumeration say if different
devices are connected to different USB controller ports on your computer:

   - Linux sound devices are a mess
     https://blog.habets.se/2021/12/Linux-Sound-devices-are-a-mess.html

   - ALSA enumeration docs
     http://alsa.opensrc.org/MultipleCards 


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
   http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/packetrig.sh
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 
           /etc/tune-profiles 

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:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Power_Management_Guide/index.html


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:

        SELINUX=disabled


  - 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
line:

   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

to

   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
                     or
               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:

         http://repos.lax-noc.com/elrepo/kernel/el6/SRPMS/

      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:
  
         https://www.kernel.org/

   +-----------------------------------------------------------------------+
   | 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
      ---------------------------------------
      http://www.centos.org/modules/newbb/viewtopic.php?topic_id=20016
   
      Centos 5.x specific:  Issues with building custom kernels for Centos 5.4
      ------------------------------------------------------------------------
      http://wiki.centos.org/HowTos/Custom_Kernel#head-566abc4208fceb902d41ee82633f509dbf386a4d
   

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:
     ---------------
     Centos6 
         - 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
                       elsewhere
    
           - 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

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

     Centos5 
         - 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.
   

      Centos6: 
              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`

      Centos5: 
              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"

         Centos5:
         --------
         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

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

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

           (these changes can also be found at 
           http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/linux/

              CONFIG_HAMRADIO=y
              CONFIG_AX25=m
              CONFIG_AX25_DAMA_SLAVE=y
              CONFIG_NETROM=m
              CONFIG_ROSE=m
              CONFIG_MKISS=m
              CONFIG_6PACK=m
              CONFIG_BPQETHER=m
              CONFIG_BAYCOM_SER_FDX=m
              CONFIG_BAYCOM_SER_HDX=m
              CONFIG_BAYCOM_PAR=m
              CONFIG_BAYCOM_EPP=m
              CONFIG_YAM=m 
              CONFIG_LEGACY_PTYS=y
              CONFIG_LEGACY_PTY_COUNT=256

          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:

              Centos6:
                 cp usr/src/redhat/SOURCES/config-local \
                    usr/src/redhat/SOURCES/config-local-ax25

              Centos5:
                 cp /usr/src/redhat/SOURCES/config-rhel-generic \
                    /usr/src/redhat/SOURCES/config-rhel-generic-ax25

         - 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 .

               IMPORTANT: 
               ----------
               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 


           Future
           ------
           - 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

                     CONFIG_HAVE_CC_STACKPROTECTOR=n
                     CONFIG_CC_STACKPROTECTOR=n
                     CONFIG_CC_STACKPROTECTOR_STRONG=N

              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 
     document
   -----------------------------------------------------------------

   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 
                       AND 
               - 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


             NOTE:  
             -----
               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:

           /etc/udev/rules.d/10-us-interfaces-navigator.rules
           --
           #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
           --
           #!/bin/bash

           #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.                                             |
      +--------------------------------------------------------------+

      Debugging:
      ----------
         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
             --
             udev_log="err"
             --


           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

           ttyUSB0
           ttyUSB1
           ttyUSB2
           ttyUSB3
           ttyUSB4
           ttyUSB5
           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:
            http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/linux/  
                   or 
            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

           CONFIG_EMBEDDED=y

       # 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

           ttyUSB0
           ttyUSB1
           ttyUSB2
           ttyUSB3
           ttyUSB4
           ttyUSB5
           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
                  etc


       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  \
x86_64/kernel-headers-2.6.32-220.7.1.el6.ax25.x86_64.rpm



            
       NOTE:
       -----
       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:

     http://www.trinityos.com/LINUX/TrinityOS-security/usr/src/kernel/build-it.trinityos

         - 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

           ttyUSB0
           ttyUSB1
           ttyUSB2
           ttyUSB3
           ttyUSB4
           ttyUSB5
           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

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

               for example, for a 4.8.11 Elrepo ML kernel
               --
               baycom_ser_hdx.ko
               baycom_ser_fdx.ko
               mkiss.ko
               yam.ko
               hdlcdrv.ko
               6pack.ko
               bpqether.ko
               baycom_par.ko
               --

            NEWKERNELVER=4.8.11
            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:
     --
     CONFIG_AX25=m
     CONFIG_AX25_DAMA_SLAVE=y
     --


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:

              https://github.com/ve7fet/linuxax25

          You can see an update list of patch descriptions here:

              https://github.com/ve7fet/linuxax25/commits/master/ax25apps
              https://github.com/ve7fet/linuxax25/commits/master/ax25tools
              https://github.com/ve7fet/linuxax25/commits/master/libax25


          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):

              https://code.google.com/p/linuxax25/source/browse/#svn%2Fdownloads


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


          NEW: website managed by Thomas Osterried DL9SAU  
                  https://linux-ax25.in-berlin.de/wiki/Main_Page

               Actual Git repo itself:
                  git://linux-ax25.in-berlin.de/pub/scm/libax25

          LEGACY website managed by Ralf Baechle DL5RB -  Was: http://www.linux-ax25.org/pub/


     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 
          (6/21/12)



     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 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.

            http://f6bvp.free.fr/logiciels/ax25/


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:
      --
      https://fedoraproject.org/wiki/SIGs/AmateurRadio/Packages

      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
          ./autogen.sh
          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
          ./autogen.sh
          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
          ./autogen.sh
          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: 

          http://www.spinics.net/lists/linux-hams/msg03195.html

  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 \
           /usr/src/redhat/RPMS/x86_64/libax25-devel-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 \
   ax25-apps-0.0.8-rc2.1.patched_f6bvp.tar.bz2

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

      wget -O libax25-0.0.12-rc2.patched_f6bvp.tar.bz2 \
   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:

      http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/

      #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

      libax25
      -------
      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/ 
   
      ax25-apps
      ---------
      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/

      ax25-tools
      ----------
      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:

      libax25.f6bvp.spec
      ------------------
         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

      ----------------------------------------------------------------------------
      
      ax25-apps.f6bvp.spec
      --------------------
         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


      ax25-tools.f6bvp.spec
      ---------------------
         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
         ax25-tools-0.0.8-3.fc9.src.rpm

       - 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 git://linux-ax25.in-berlin.de/pub/scm/libax25 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;
              #endif

         - and DELETE the lines:

              #ifdef  notdef
              #endif

       - 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:
                    Patch1:
                    %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
        #

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

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

        73c73,75
        <                               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 --->

     http://rpm.pbone.net/index.php3/stat/4/idpl/14102996/dir//com/alsa-kmdl-2.6.18-194.3.1.el5.centos.plus-1.0.20-80.el5.i686.rpm.html

   - 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?


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:

Example:

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


Digipeated:
-----------
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.


You can learn more from some of these highly rated tutorials here:

   - Theory and Practical tutorials for VHF and HF Packet:
     +---------------------------------------------------------------------------+
     | I recommend you read up on the concepts of packet, it's terminology,      |
     | etc. as it will really help you understand what this document is helping  |
     | you configure.  Ultimately, the TrinityOS packetrig.sh script has much of |
     | these lessons integrated into it but it's not written to teach you WHY!   |
     +---------------------------------------------------------------------------+

        http://www.choisser.com/hamradio/packet.html

        https://www.qsl.net/w6fff/packet.htm


   - Getting started with Packet radio
      https://www.qbjnet.com/packet.html

   - My intro to packet radio at:

       http://www.trinityos.com/HAM/getting-started-with-packet-radio.txt


   - 4/18/22: URL might be dead: Detailed breakdowns of all TNC details
       http://www.rain.org/~jkrigbam/packet.htm


   - Setting proper AFSK and audio levels for packet TNCs and other digital 
     modes
      http://www.febo.com/packet/layer-one/transmit.html


   - Lots of various packet details, tools, and other technical tidbits
       http://www.vectorbd.com/bfd/packet/index.html


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 44.191.255.255 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:

   http://en.wikipedia.org/wiki/AMPRNet

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

   ftp://hamradio.ucsd.edu/pub/amprhosts


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
              today.


  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
    (amprgw.ucsd.edu).

    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:

        https://portal.ampr.org/networks.php

     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:

        44.4.10.40 - ki6zhd-net.ampr.org
        44.4.10.41 - 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:

         http://hamradio.ucsd.edu/mailman/listinfo/44net


   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


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

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

            - 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:

                  44.4.10.40/29

              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
                      IP:       44.4.10.41

              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
   http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/manual-ampr-start.sh

   #Shut down
   http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/manual-ampr-stop.sh


Other setup examples:
---------------------

   #Startampr script
   http://wiki.ampr.org/wiki/Startampr#Script

   #iproute2 munge script that processes the encaps file
   http://www.wa7v.com/index.php?name=News&file=article&sid=20&theme=Printer

   #Setup scripts for old Linux 2.2 kernels
   http://www.mail-archive.com/linux-hams@vger.rutgers.edu/msg06336.html

   #Setup scripts For very old Linux 2.0 kernels
   modprobe ipip
   http://rob0.nodns4.us/Linux-ipip-tunnels


+-------------------------------------------------------------------------------+
| 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 192.168.0.20 4

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

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

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


   #Users may need a way to clear MASQ table
   http://www.gossamer-threads.com/lists/lvs/users/3515

   #Impliment even better security
   http://www.linuxvirtualserver.org/docs/defense.html

   --
   http://www.fis.unipr.it/doc/piranha-0.8.4/docs/LVS-HOWTO/LVS-HOWTO-7.html
    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:
   --
   http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.operation.html

   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 
             - 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
               KPC3+

         - QtSoundmodem for Linux, Windows, and Mac - https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html
           ---------------------------------------------------------------------
             - This is a port of UZ7HO's Soundmodem for Windows only that is written 
               in Delphi into the C language.  The original UZ7HO project has not received 
               any updates since 2020 
             - Runs on Linux (x86 and ARM), Windows (x86), and Mac OSX
             - Supports multiple transceiver "slices" within the same radio passband
                   eg. HF radio is tuned to 14.1023MHZ USB and you can have TWO entierly
                       different AX.25 interfaces where one only RX/TX on the lower part
                       of the passband and the other operates in the upper part of the 
                       passband
             - Highly configurable audio passband filtering
             - Originally designed to support 1200 baud packet but now supports many modes
             - Supports TCP-KISS over IP for APRX, UI-Chat, and other program compatibility
             - AGW/PE support for connected and non-connected frames (APRS, etc)
             - Supports off frequency decodes via running multiple decoders (higher CPU load)
               similar to Direwolf
             - Supports 1bit and multi-bit recovery options for excellent weak signal decodes
             - PTT support includes serial ports, parallel ports, CAT, CM108 GPIO, Windows DLL, 
               VOX, etc.
             - Now supports FX.25 error correction for AX.25 similar to Direwolf
             - Now supports IL2P protocol support (new, non-AX.25 compatible protocol)
               similar to Direwolf
             - Has simplistic APRS Digipeater support but nothing beyond that
             - Supports GUI with a dedicated waterfall for those who like to see that but now
               offers non-GUI operation for lower system requirements as well
             - Supports open-squelch operation
             - Native ALSA application (no support for PortAudio) though compatible with
               PulseAudio's "default" device


         - 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 
               channel
             - 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 -         
               http://wa8lmf.net/TNCtest/index.htm                             
             - See the QEX article on JavAX25 at                               
                     www.tau.ac.il/~stoledo/Bib/Pubs/QEX-JulAug-2012.pdf       

                                                                               
         - 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
                 or there is also a fork with some minor bitrot fixes / GUI modernizations 
                                   https://gitlab.com/packetradio/soundmodem

             - Different URL since original GNU page for hosting Soundmodem seems to be gone
                  http://gna.org/projects/soundmodem

             - 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 -                                 
               http://wa8lmf.net/TNCtest/index.htm                             


         --------------------------------------
         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:                                           
                   http://www.sv2agw.com/downloads/LoopbackInstaller.zip       
             - Better than 990 decoded packets from WA8LMF's Track 2 -         
               http://wa8lmf.net/TNCtest/index.htm                             
             - 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:                                     
               http://wa8lmf.net/TNCtest/index.htm                             
                                                                               
         - 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                                                      
               http://wa8lmf.net/TNCtest/index.htm                             
             - 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


         ---------------------------------------
         Other hardware-based TNCs worth noting
         ---------------------------------------
         There are a lot of hardware TNC options out there as well but it should be noted that
         most if not ALL of these will not be able to decode weak signals as well as say Direwolf
         or UZ7HO software-TNC options:

            - TNC-Pi9k6 Teensy-based TNC (sucessor to the TNC-X / TNC-Pi)
              Has multiple firmware options to include support for both AX.25 packet and ARDOP
                 HW: https://www.wvcarc.com/p/tnc-96k-resources.html
                 SW: https://www.cantab.net/users/john.wiseman/Documents/ARDOPTeensy.html

            - Nino TNC
              Also supports the alternative IL2P packet-like protocol (not AX.25 compatible) 
              with built-in FEC
                 http://tarpn.net/t/nino-tnc/n9600a/n9600a_info.html

            - NucecloTNC (clone of mobilink TNC)
              https://github.com/mobilinkd/NucleoTNC

            - Mobilinkd OSS firmware  (hardware designs are seemingly not shared)
              https://github.com/mobilinkd/tnc3-firmware

            - ESP32 KISS TNC over Wifi
              https://github.com/danak6jq/ESP-TNC

            - OpenModem
              Supports built-in encryption into the TNC (note: encryption over RF is not legal 
              to use in most countries)
                https://github.com/markqvist/openmodem/

            - TNC-Pi and TNC-X (EOLed)
              - I'm pretty sure the TNC-X / TNC-Pi firmware design and firmware is also open source
              


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:


   https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2380057.m570.l1313.TR5.TRC1.A0.H0.Xeasydigi.TRS0&_nkw=easydigi&_sacat=0

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 9.2.12.1 - Page 73
   https://github.com/wb2osz/direwolf/blob/master/doc/User-Guide.pdf

   
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 :
       http://www.frenning.dk/OZ1PIF_HOMEPAGE/SignaLinkUSB-mods.html
     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 

   https://github.com/wb2osz/direwolf 


specifically download it at:

   https://github.com/wb2osz/direwolf/archive/1.6.tar.gz

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

       http://www.trinityos.com/HAM/CentosDigitalModes/RPi/rpi2-setup.html
          and
       https://github.com/wb2osz/direwolf/tree/master/doc


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!

  OPTIONAL: 
  ---------
  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
   /usr/share/doc/direwolf/User-Guide.pdf

      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:
      https://github.com/dh1tw/remoteAudio/wiki/Persistent-USB-Mapping-of-Audio-devices-(Linux)

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

      --
      change the line:
              MYCALL N0CALL
      to
              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
      to
             MODEM 1200 E+ /3

      --
      change the line for your chosen method of PTT (direct serial port, hamlib support, etc)
             #/dev/ttyUSB0 RTS
      to
             /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:  

                    http://www.febo.com/packet/layer-one/transmit.htm

            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.

                 IMPORTANT:
                 ----------
                 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
      to
             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:

   http://xastir.org/index.php/HowTo:Set_Deviation_via_RTL


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
            Xwindows

        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
            difficult.


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

      - 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:

   Why-is-9600-only-twice-as-fast-as-1200.pdf
      and
   Going-beyond-9600-baud.pdf

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

   http://www.wattystuff.net/amateur/packet/introhispeed.htm

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 \
http://soundmodem.vk4msl.id.au/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 \
http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/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 \
http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/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 \
http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/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 \
http://kojipkgs.fedoraproject.org/packages/soundmodem/0.12/1.fc9/src/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:

       http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/


     +-----------------------------------------------------------------------+
     | 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 \
/usr/src/redhat/RPMS/x86_64/soundmodem-devel-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: 10.0.0.1 <------- change with your allocated AMPR IP
            +-- Network Mask                  Can be anything really but please
            +-- Broadcast 10.0.0.255          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
            anywhere.

        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
            difficult.

            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!                *
      **********************************************************************

        Kmix
            Running the following should restore the Mixer settings:

                   /sbin/alsactl restore

            Just to confirm your settings:

            output
            ---------------------------------------------------------
                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

            switches:
            ---------------------------------------------------------
          ----> 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
                    .........l..@@l,..........,...
                    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

       -----
       NOTE:
       -----
             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 -->
                 SoundSystem. 

                   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 10.0.0.1 netmask
   255.255.255.0 broadcast 10.0.0.255
   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:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:256  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: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
like: 

    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
   /usr/bin/soundmodemconfig

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

       #You should see:
       #
       #  sm[11301]: mkiss: ifname sm0 mtu 256 hwaddr KI6ZHD-0 ipaddr 10.0.0.1
       #  netmask 255.255.255.0 broadcast 10.0.0.255
       #  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 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255
   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:

     soundmodem-0.16-use-a-minimum-samplerate-for-afsk-v5.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 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255
   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
packets!

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 
 
      or

   - 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,
                      etc
                    
    - 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:  

  http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-up.new
  --

  #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:  

   http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-up.new

  --

  #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


Once you have your base AX.25 station working, now you have a lot of other application options available 
to you be it for terminal programs, mapping programs, you name it.  Here is a list of other things you
might consider.

Do look below for some of the already included packet programs that came with the ax25-apps and ax25-tools
packages for some basic but useful functionality:



   AX.25 soft TNC programs:
   ------------------------
      Direwolf   - An excellent softTNC offering built-in stacks for APRS, AX.25 v2.2, FX.25, serial kiss,
                   TCP-KISS, and AGW connectors for use with FM radios, SDRs, etc.

      Soundmodem - UZ7HO's soundmodem software TNC for Windows (runs under WINE)
                   Wine for X86-computers) : http://uz7.ho.ua/packetradio.htm

      Soundmodem - legacy / obsolete software soundcard AX.25 packet TNC that really started it all for Linux
                   https://gitlab.com/tsailer/soundmodem


   AX.25 packet programs:
   ----------------------
      Linpac      - Nice Linux NCURSES-based packet terminal and simple BBS software using the Linux AX.25 stack.
                    Offers mailbox forwarding, macro language, and great customization support
                    https://sourceforge.net/projects/linpac/

      QtTermTCP   - A graphical Qt-based packet terminal program that can use either AGW or BPQ-TCP
                    based connections.  Should work well with Direwolf - from the BPQ32 developer
                    https://www.cantab.net/users/john.wiseman/Documents/QtTermTCP.html

      EasyTerm    - A Windows graphical packet terminal with mailbox services that uses AGW (runs fine under WINE)
                    http://uz7.ho.ua/packetradio.htm

      Agwpe-tools - Both a Windows (binary) and Linux (Node.JS) packet terminal program to make 
                    connected mode sessions - supports AGW connections
                    https://github.com/jmkristian/agwpe-tools

      BPQ32 /     - packet Bulletin board system and a lot more with it's own AX.25 stack or using the Linux AX.25 stack
        LinBPQ      Offers other connectors like TNC2 emulator, PACTOR and VARA connectors, etc
                    https://www.cantab.net/users/john.wiseman/Documents/index.html

      Jnos        - packet Bulletin board system with it's own AX.25 stack or using the Linux AX.25 stack
                    Offers other connectors like PACTOR and VARA connectors, etc
                    https://www.langelaar.net/jnos2/

      FBB + FPAC  - packet Bulletin board system using the Linux AX.25 stack
                    https://www.f6fbb.org/

      Uronode     - Linux Packet node software using the Linux AX.25 stack
                    Was on sf.net - but modern packages are available for Debian-based distros

      OpenBCM     - Packet radio terminal and light weight messaging with a web interface
                    https://github.com/oe5hpm/openBCM

      Agwterm     - Windows terminal packet program via AGW (runs under WINE)
                    https://www.sv2agw.com/downloads/
         
      IpSerial    - Included with Outpost Package manager for Windows (runs under WINE)
                    Older versions had some AGW issues which have been reported
                    https://www.outpostpm.org/index.php?content=downloads
      xr32 /      - a full packet NOS system port from the original XR32 Window program.  This includes a full AX.25 
       xrpi /       stack, chat server, AX.25 and APRS digipeaters, PMS message board, integrated HTTP, FTP, TELNET, 
       xrlin        finger, and ping servers, NETROM, IP over AX25/Netrom, IPIP tunneling, KISS, SLIP, PPP, and DHCP 
                    services, NAT services, TNC2, WA8DED, AGWTCP and KISS TNC emulation written by Paula G8PZT
                    https://ohiopacket.org/xrpi/  or http://vk2dot.dyndns.org/xrpi/index.htm
                    -- Binaries only.. source code is not provided

      LinKT       - LinKT is a KDE Packet Radio (AX25) Terminal with the Linux AX.25 terminal - no longer maintained
                    https://sourceforge.net/projects/linkt/

      LinGT       - GNOME2 port of LinKT. LinKT is a KDE Packet Radio (AX25) Terminal with the Linux AX.25 terminal
                    https://sourceforge.net/projects/lingt/ - No longer maintained
               
      TnT         - WA8DED Hostmode or KISS TNC packet terminal program for Linux
                    http://home.snafu.de/wahlm/dptnt.html

      Dpbox       - BBS for Linux - no longer supported
                    http://home.snafu.de/wahlm/download.html

      xconvers    - IRC like client using the Internet or packet radio
                    https://sourceforge.net/projects/xconvers/

      converse    - A command line AGW terminal program for Windows and Linux (written in Node.JS)
                    https://github.com/jmkristian/agwpe-tools



As mentioned at the top of this section, the ax25-apps package includes several basic but useful 
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


For an example of how to use the tools, say you're in Silicon Valley trying to connect to the packet
station "K6SNY-1".  To make the connection, 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 |
    +----------------------------------------------------------------------------------------------+


An example good "listen" log showing (with annotations) a good/working connection to K6SNY-1 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 above, the "call" program lets you make basic, outgoing connections but the 
Linux AX.25 can do SO much more using tools from the ax25-suite as well as 3rd party tools.  
For other 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
    http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/unproto-transmit.sh

    # Sending out APRS formatted packets
    http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/beacon.py


   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

         /usr/bin/mheardd

   #After a while, run the client program to see what stations were heard:

         mheard


   #ax25d daemon - similar to inetd which will start services based on incoming requests
   /usr/sbin/ax25d
   
      #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..


   NOTE:
   -----
   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
   apply



    axmail-utils:
    -------------
    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
       ./configure
       make
       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:

        /etc/ax25/axgetlist.conf
        /etc/ax25/axgetmail.conf
        /etc/ax25/bulletins.OK0PAB
        /etc/ax25/logins
        /etc/ax25/ulistd.conf

    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!


    ---------------------------------------------------------------------------

    PMS:
    ---
    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.  
         
    Axmail:
    -------
    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.

    Inbox
    -----
    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.

       http://www.kingsqueak.org/2011/10/a-linux-packet-radio-personal-message-inbox/

    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

     NOTE:
     -----
     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
       workflow:
      -------------------------------------------------------------------
      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
      ./configure
      make

         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


Info:
-----
   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 
routes.  

   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 
                 route

  - 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 
                 traffic

--
# /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 44.4.10.40 netrom

  
  --------------------
  VERY IMPORTANT NOTE:
  --------------------
  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
with:

     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
                http://www.f6fbb.org/fpac/fpac.html
                - 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.
here:

   http://www.proaxis.com/~wagnerj/ka7ehk/map/noderef.html



Uronode 
-------
   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
   ZTelnet


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
   Users



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

                         ki6zhd.ampr.org

                      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:
                          44.4.10.40/32
                      
      - 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:

                        SCLARA:KI6ZHD-5

      - 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

uronode.users
-------------
    - 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


uronode.routes
--------------
    - 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



ax25d.conf
----------
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.

   IMPORTANT NOTE:
   ---------------
   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:

/etc/ax25/ax25d.conf
--
#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
<netrom>
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 
                           name.  
        --
        uronode         3694/tcp                        # AX.25 Uronode
        --

   To get everything recognized, you need to restart xinetd:

       /etc/rc.d/init.d/xinetd restart



AXPARMS:
--------
    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
            "Unode".  

         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: 
                        SCLARA:KI6ZHD-5

      - 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:
                      SCLARA

      - 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 
      following.  

        # 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


ax25d.conf
----------
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:


ax25d.conf
--
#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
[SCLARA VIA d710]
NOCALL * * * * * * L
default * * * * * * - root /usr/sbin/node node

#To allow connections to SCLARA from a Netrom connection
<netrom>
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 
          http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/

    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.
    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.
    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.
    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.
    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.
    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:
https://fedoraproject.org/wiki/SIGs/AmateurRadio/Packages

Find and click on "node and download the node-0.3.2-1.src.rpm file to 
/usr/src/redhat/SRPMS

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 44.4.10.40
   - In this example, /dev/pts/7 camesfrom the output of the kissnetd
     command above.  44.4.10.40 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
              work

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 
configurations.

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
          API.

     #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:

   https://github.com/ampledata/ldsped

I recommend to get the official sources to honor the main developer's wishes so follow 
the prompts at: 

   http://www.on7lds.net/42/node/12

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 

    /usr/sbin/ldsped

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:

http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/filter-packet-listen-logs.sh

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.

         http://supercat.nosredna.net/


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!


Connect/Disconnect:
        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:44.4.10.40  Bcast:44.127.255.255  Mask:255.128.0.0
             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:44.4.10.40  Mask:255.128.0.0
             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:44.4.10.40  Mask:255.128.0.0
             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:44.4.10.40  Mask:255.128.0.0
             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 
     Linpac:

   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

     or 

   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 44.2.14.100 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 
         or
   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
                  https://github.com/sq5t/tnc-proxy


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
     frequency
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 \
https://downloads.sourceforge.net/project/linpac/LinPac/0.25/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 \
http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/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:

              [K6FB-1]
              NAME=K6FB PBBS
              TYPE=FBB



    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.              |
           +--------------------------------------------------------------+
      


           $HOME/LinPac/macro/init.mac
           --
           ;;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
           swapedit
           redraw
           
           ;;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:
           ;;
           undest "David WOODY KBERR KTUO KMOC KBETH KLIVE KPAC"

           ;; 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
           set DEF_RCMD@0 "AB D E VER L RP B MH N RT YPUT W R WB RB A COMP CONV I H Q U CS SP SB"

           ;;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:

         macro/commands 
         --
         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

   
Extensibility:
--------------
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:

       http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/linpac-check-msgs.sh

    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):

  http://www.zs6mrk.org/pakket_met_linux.htm

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 \
http://download.fedoraproject.org/pub/fedora/linux/releases/16/Everything/source/SRPMS/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-1.3.4.2
        tar czvf fltk-1.3.4.2-source.tar.gz fltk-1.3.4.2

        #Now lets' clean up the old directory and move the new archive to the SOURCES dir
        mv fltk-1.3.4.2-source.tar.gz ../SOURCES/
        rm -Rf fltk-1.3.4.2/


        #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

           #to
           Version:        1.3.4.2
           --
        
           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 1.3.4.2, 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-1.3.4.2-1.el6.x86_64.rpm \
/usr/src/redhat/RPMS/x86_64/fltk-devel-1.3.4.2-1.el6.x86_64.rpm \
/usr/src/redhat/RPMS/x86_64/fltk-fluid-1.3.4.2-1.el6.x86_64.rpm \




        [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

        XMLRPC
        ------
           # 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 \
ftp://ftp.pbone.net/mirror/centos.karan.org/el5/extras/testing/i386/RPMS/xmlrpc-c-apps-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        \
     # <       -DMUST_BUILD_LIBWWW_CLIENT:BOOL=OFF     \
     # <         -DCMAKE_INSTALL_PREFIX:PATH=%_prefix  \
     # <         -DBUILD_SHARED_LIBS:BOOL=ON
     # ---
     # > #cmake .. \
     # > #     -D_lib:STRING=%_lib                     \
     # > #     -DMUST_BUILD_CURL_CLIENT:BOOL=ON        \
     # > #     -DMUST_BUILD_LIBWWW_CLIENT:BOOL=OFF     \
     # > #        -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 \
xmlrpc-c-devel-1.06.18-1.i686.rpm

        NOTE:
        -----
        - 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
   --

     Perl-RPC-XML
     -------------
       # 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
Flrig INSTEAD.


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:
        
   https://github.com/Hamlib/Hamlib/releases


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 1.2.13.1

   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 1.2.13.1
                - 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 \
http://elrepo.org/linux/elrepo/el5/i686/RPMS/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:

       NOTE: 
       -----
         *   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 \
http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/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 \
/usr/src/redhat/RPMS/x86_64/portaudio-devel-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
        definitions

      - 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 \
http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/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 \
      to
        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: 127.0.0.1
          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


   Issues:

     - 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"



          NOTE
          ----
          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 
          Timeout

       4. Full setup, level optimization, and much more can be found here:

          http://www.trinityos.com/HAM/US-Interface/us-interface-navigator-and-linux.html

    ----------------------------------------------------------------------------
    **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:

            http://www.w1hkj.com/FldigiHelp-3.20/DigiWWV.html

      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:

            http://www.trinityos.com/HAM/FieldDay-2010/


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
         with

        desktop-file-install --vendor="" \
          --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
          $RPM_BUILD_ROOT%{_datadir}/applications/flmsg.desktop

        # --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
            with

           desktop-file-install --vendor="" \
             --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
             $RPM_BUILD_ROOT%{_datadir}/applications/flmsg.desktop

           # --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

            with

           desktop-file-install --vendor="" \
             --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
             $RPM_BUILD_ROOT%{_datadir}/applications/flamp.desktop

           # --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:

   http://www.w1hkj.com/flamp-help/index.html


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
            with

           desktop-file-install --vendor="" \
             --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \
             $RPM_BUILD_ROOT%{_datadir}/applications/flwkey.desktop

           # --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: 

             /usr/local/bin/usinterface-ident.sh

       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:

         http://www.trinityos.com/HAM/US-Interface/us-interface-navigator-and-linux.html#navigator-config

     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 
     tone.  

     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
   http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Fl-suite/update-fl-suite.sh

   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:

         http://tecadmin.net/install-java-8-on-centos-rhel-and-fedora/

         for more details for now



Dependencies:
-------------


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
            http://javadl.oracle.com/webapps/download/AutoDL?BundleId=225344_090f390dda5b47b9b721c7dfaa008135

            #32bit RPM version - 59MB
            http://javadl.oracle.com/webapps/download/AutoDL?BundleId=225342_090f390dda5b47b9b721c7dfaa008135


      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
            system:

              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:
     http://pkgs.org/fedora-13/fedora-i386/rxtx-2.2-0.1.20100211.fc13.i686.rpm.html


Prep your Centos to support lock files for the user who will be running
PskMail:

    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,
       etc.

     - 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)

          Beacon:     

        Rig:
            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 3.23.10.10 (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 3.23.10.08 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 1.7.2.4 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:

   http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/fldigi-socat-packet.sh

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
NETSTAT="/bin/netstat"
KISSATTACH="/usr/sbin/kissattach"
MHEARDD="/usr/sbin/mheardd"
LISTEN="/usr/bin/listen"
KISSPARMS="/usr/sbin/kissparms"
IFCONFIG="/sbin/ifconfig"
SOCAT="/usr/bin/socat"

# This will need to be updated depending on how many ax0 interfaces
# are already present in ifconfig
AX25HFINT="ax0"
AX25HFPORT="fld"
LOCALIPPORT="127.0.0.1:7342"
FLDIGIPTYFILE="/var/tmp/fldigi-dev"
AX25PTY="/tmp/ax25-config.tmp"
AX25PTYFINAL="/tmp/ax25-config2.tmp"


#Fldigi mode: TCP or UDP
SOCATMODE="TCP"

#User specific settings - change these to match your callsign and AMPR IP address
AMPRIP="44.4.0.1"
AMPRNM="255.255.255.128"
CALLSIGN="N0CALL-8"


Important:
----------
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       : 127.0.0.1
          - 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) - 

        http://www.iaru-r2.org/band-plan/

   - 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 127.0.0.1:7342              0.0.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 127.0.0.1:7342
     Fixing pty permissions
     Actual PTY is: /dev/pts/3
     Confirm two 'ESTABLISHED' Fldigi connections:
     tcp        0      0 127.0.0.1:7342              127.0.0.1:46927             ESTABLISHED
     tcp        0      0 127.0.0.1:46927             127.0.0.1:7342              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

     Completed
     --


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 
HF!


BTW, you might consider downloading my axctl shortcut script at:

   http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/ax25-kill-packet-connection.sh

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: 

    http://www.arrl.org/logbook-of-the-world

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:

        trustedqsl-2.3-1.el6.x86_64
        tqsllib-2.5-4.el6.x86_6
        tqsllib-devel-2.5-4.el6.x86_64


  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:

         http://sourceforge.net/projects/trustedqsl/files/TrustedQSL/
         --
         TrustedQSL : 2.1.2  (was 2.0)
         tqsllib    : 2.4

   NOTE: Alternatively, you can look at:

            http://www.arrl.org/tqsl-download

         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
         mismatch
         --

       #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
/usr/src/redhat/RPMS/i686/tqsllib-devel-2.0-5.i686.rpm


       #now compile and install:
       #
       #  note:  must use the FC9 version 
       #
       Download a sample SPEC file from:
       http://koji.fedoraproject.org/koji/packageinfo?packageID=72670

       Download the newest sources from:
          http://sourceforge.net/projects/trustedqsl/files/TrustedQSL/
            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):

   /usr/bin/tqsl

 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
          $HOME/.tqslapp
          $HOME/.tqslcert

       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.

         http://www.arrl.org/renew-certificate


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 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.

   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:
  https://lotw.arrl.org/lotw-help/certaccept/
  =======================================================
  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.


Bureaus:
--------
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:

   http://www.qslbureau.org/cgi-bin/w6burosearch.cgi?query=ki6zhd

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
                      include:
                               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

   NOTE:
   -----
   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
   CQRLog.


  +------------------------------------------------+
  | 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:

    http://mirror.its.uidaho.edu/pub/savannah/xlog/

    Assuming you put it in /tmp
    mv /tmp/xlog-*.tgz /usr/src/redhat/SOURCES



Next, you can use my RPM from

         http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/


   or you can build you're own SPEC file by doing the following:

     Get a SPEC file for it at:
     

    http://kojipkgs.fedoraproject.org/packages/xlog/2.0/1.fc9/src/xlog-2.0-1.fc9.src.rpm

        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
    downloaded:

         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:

       https://bugzilla.redhat.com/show_bug.cgi?id=558788


    #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
http://www.whabbit.demon.co.uk/xlog-uploader-0.2.tgz

   Uploader requirements:
   http://trac.dbzteam.org/pyinotify


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:

   - Linux or Unix Compatible

      APRS 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 client supporting mapping, APRS messaging, beaconing, etc. for 
                  Linux/Unix 

        - YACC: graphical client written in Java (multi-platform)
                https://www.ka2ddo.org/ka2ddo/YAAC.html

        - JavAPRS: graphical client written in Java. Newest version seems to be 2.9.2b06
                   from 02/03/2019 : http://www.aprs-is.net/javaprs/

        - Polaric: graphical client written in Java (multi-platform).  Currently at v2.9 
                   (released 01/29/22) : http://aprs.no/dokuwiki/doku.php?id=polaricserver


      APRS 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
                http://thelifeofkenneth.com/aprx/

        - 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  that evidently runs under WINE
                    Most current version is 2020/05/01
        
        - PinPointAPRS: APRS client for Windows only started in 03/2018.  It is reported
                        v2.0 (March 24, 2021) runs ok under WINE but there might be issues 
                        with serial-connected GPSes : http://www.pinpointaprs.com/

        - UIView32: Considered one of the more 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 : http://www.ui-view.net/


You can find a more complete list of APRS programs here:

   http://info.aprs.net/index.php?title=Software



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:

        http://download-mirror.savannah.gnu.org/releases/gpsd/

  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 \
/usr/src/redhat/SPECS/

    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
          to:
              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}
         to:
           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:

`/var/tmp/gpsd-2.95-3-root-root/usr/lib/python2.4/site-packages/gps/gps.py':
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
         matter



  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 \
/usr/src/redhat/RPMS/x86_64/gpsd-devel-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
   cgps


   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:
   http://www.murga-linux.com/puppy/viewtopic.php?t=51957&sid=631d6464d6717657c4a1990797ccb6a0


   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:
   http://www.rjsystems.nl/en/2100-ntpd-garmin-gps-18-lvc-gpsd.php
   

   INCOMPLETE: Delorme EarthMate PN-40 GPS to work with Centos5

   ***********************************************
   This section is INCOMPLETE - many deadends here
   ***********************************************

    http://sourceforge.net/project/downloading.php?group_id=1674&filename=libusb-1.0.1.tar.bz2&a=97130440

    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

        Centos6: 
            yum install tk tkimg

        Centos5:
        wget \
ftp://fr.rpmfind.net/linux/EPEL/5Server/i386/tkimg-1.3-0.9.20080505svn.el5.i386.rpm
        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 \
http://downloads.sourceforge.net/project/gpsman/distrib/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}

        Centos6:
        --------
           #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


        Centos5:
        --------
           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

        Centos6:
        --------
          # 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


        Centos5:
        --------
          wget \
ftp://rpmfind.net/linux/fedora/updates/9/i386.newkey/lesstif-devel-0.95.0-26.fc9.i386.rpm
          wget \
ftp://rpmfind.net/linux/fedora/updates/9/i386.newkey/lesstif-0.95.0-26.fc9.i386.rpm
        
          #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 \
db4-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
              installed:

                   #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:

      https://github.com/Xastir/Xastir/releases


   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

          or
 
          #You've previously downloaded a previous version of the repo
          cd xastir-git
          git pull
 
          
      or 
          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

                and

             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
       ./bootstrap.sh


       # 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
             %{_prefix}/lib/xastir

             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 \
                to
             desktop-file-install --vendor="" \
          

          # Edit the following line:

               %{_prefix}/%{lib}/xastir

            to be:

               %{_prefix}/lib/xastir


          # And below the line:      

               %config %{_prefix}/share/xastir/sounds

            add

               %config %{_prefix}/share/xastir/scripts


          # Finally, delete the line

               %{_prefix}/lib/xastir


                
      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

            RECOMMENDED OPTIONS:
              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)    

            FOR THE ADVENTUROUS:
              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 
later.

  - 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
&aq=0&oq=3739+benton&sll=37.269174,-119.306607&sspn=13.014202,18.303223&vpsrc=6&t=h&ie=UTF8&hq=
&hnear=3739+Benton+St,+Santa+Clara,+California+95051&ll=37.343535,-121.999908&spn=0.000399,0.000559&z=21
     |       |
     |       |                  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
     |
     +-- 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
     |
     +-- 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:

            Map
             |
             +--> 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
    https://xastir.org/index.php/Main_Page
       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
    https://github.com/PhirePhly/aprx
       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
    https://www.ka2ddo.org/ka2ddo/YAAC.html
       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).  
    https://github.com/wb2osz/direwolf
    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:
    http://pe1mew.nl/digi_ned/
       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 
    https://github.com/n7nix/nixtracker
       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" 
    https://github.com/kk7ds/dantracker
       - 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
           improvements

   Applications:
       - 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:

              https://github.com/n7nix/dantracker



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
   MAJVER="`cat VERSION`"
   #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

                   http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/aprx.spec


      (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, 
         etc.  
   
         - Edit the aprx.spec file and delete both the following 
           lines and everything between them:
   
           %if 0%{?rhel} >= 7 || 0%{?fedora} >= 16
           .
           . thru
           .
           %endif

       - Next, there are some options you might think about enabling
         in the "%configure --with-erlangstorage" line:  

            - pthreads support : To enable this, add the text
   
                --with-pthread

          
            - agwpe support : to enable this, add the text:

                --enable-agwpe

               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 
     communications

   +----------------------------------------------------------------------------+
   | 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

      ----------
      Interfaces
      ----------

      - 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

      ------
      Beacon
      ------
      - 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"

      ----------
      Digipeater
      ----------
      - 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. If I run a program like Xaster for a while, I eventually see various icons show up on the map around me that provide various details if I look at each one. For this example, I learned: 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:

   http://www.aprs-is.net/email.aspx

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
understand.  

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
       bby7yy@yahoo.com.

          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, 
    etc).  


       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,
       setup:

              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
         Send!

         [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
                                    like:
                                            joe
                                            xx
                                            aax0xx


            - 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 
              message

            - 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!

        http://aprs.fi/?c=message&call=EMAIL-2&limit=1000


  - 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 
worlds!

Let's get started with the intent to use it with Fldigi on HF: 

  - You need to have Fldigi 3.23.10.10 or newer installed and working on your
    machine.  Please see the Fldigi section for full details on how to get that
    going

  - 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

       https://plus.google.com/u/0/communities/110418910579764092090

    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 3.23.10.10 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:

   https://www.winlink.org/content/ardop_overview

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:

   https://ardop.groups.io 


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:

   http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Ardop/update-ardop-code.sh


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 1.0.4.1e:

   +--------------------------------------------------------------------------------------+
   | NOTE:  11/10/23                                                                      |
   |                                                                                      |
   |    There have been many long standing performance issues with ARDOP since the 4.19   |
   |    kernel series.  It seems that as of 6.1.x kernel series (Debian Bookworm), these  |
   |    issues are mostly gone now.  To support this and other "premature TX end" issues, |
   |    G8BPQ has posted this new code into a Git repo at:                                |
   |                                                                                      |
   |       https://github.com/g8bpq/ardop.git                                             |
   |                                                                                      |
   |    I have not tested this code yet but hopefully these turn of events will get       |
   |    ARDOP usage and adoption back on track!                                           |
   |                                                                                      |
   +--------------------------------------------------------------------------------------+

   +--------------------------------------------------------------------------------------+
   | NOTE #2:  11/08/22                                                                   |
   |                                                                                      |
   |    It has been observed that kernel versions 5.17.7 have introduced a PTT issue with |
   |    older versions of the ARDOP program.  If you are seeing PTT hanging, please make  |
   |    sure you are running the newest ARDOP code which addresses this issue.            |
   |                                                                                      |
   +--------------------------------------------------------------------------------------+

   cd /usr/src/redhat/SOURCES/

   # The ARDOP source code has moved around quite a lot:
   #   - It used to be ARDOPC.zip file but this archive was deprecated as of 3/27/18.
   #   - The next location for the modem code was buried in the TeensyProjects.zip file
   #   - As of 05/10/22, the new location is in the ARDOPProjects.zip file
   #
   wget https://www.cantab.net/users/john.wiseman/Downloads/Beta/ARDOPProjects.zip

   #Now rename the unversioned TeensyProjects file to something more trackable
   mv ARDOPProjects.zip ARDOPProjects-`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/ARDOPProjects-`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 ARDOPProjects/ARDOPC/ARDOPC.c | awk -F\" '{print $2}' | awk -F\- '{print $1}'`

   #This should look like: 1.0.4.1mBPQ
   echo $VER

   #Now pull out the ARDOP code, rename the archive name, archive, and delete the old zip file
   mv ARDOPProjects/ARDOPC ardopc-$VER
   tar czvf /usr/src/redhat/SOURCES/ardopc-$VER.tgz ardopc-$VER/*
   rm -Rf ardopc-$VER
   rm -f /usr/src/redhat/SOURCES/ARDOPProjects.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
   --
   Version: 1.0.4.1mBPQ
   --


Now build it:

   rpmbuild -bb --target=x86_64 ardopc.spec


and install it

   sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/ardopc-1.0.4.1mBPQ-1.x86_64.rpm


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


IMPORTANT:
----------
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:  

   http://www.cantab.net/users/john.wiseman/Documents/ARDOPC.html



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:

   ardop-gui

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:

        http://www.whitemesa.net/arim/arim.html


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 1.0.2.5 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 
command:

   arim

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:
      or 
   vim $HOME/garim/garim.ini for the GUI Arim version:
   --
   [tnc]
   #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 
   #precision
   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

   [arim]
   #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:

   http://www.whitemesa.net/arim/arim.html#inst


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)
        14.066
        10.135*
         7.101
         7.060
         7.045* (EU)
         3.590


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:

   /usr/local/bin/start-ardopc.sh

In another terminal window, start Arim or gArim with:

   arim
    or
   garim


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:

   <space>tncset<enter>

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:


   <space>arqset<enter>

Hit ENTER to close the window.  Next, try sending a beacon over RF with the command:

   <space>btest<enter>

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:

   http://www.whitemesa.net/arim/arim.html


When your done with ARIM, enter in the following in the ARIM window:

   <space>q<enter>

  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:

   freedv



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
     setting

   - 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:

        http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjt-dev-guide.html#_package_matrix


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"
 
                and
 
             %{_datadir}/pixmaps/wspr.png
             %{_datadir}/applications/wspr.desktop

        
    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
/usr/lib/python2.4/site-packages/numpy/distutils/fcompiler/gnu.py-orig 

       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 
     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 (217.160.254.116) 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

              Centos6:
              --------
              Audio In:  9 pulse
              Audio Out: 9 pulse  (I had to scroll down to see this)

              Centos5:
              --------
              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!

                     and

                  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
                frequency
             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:



    Dependencies:
       Requires Fortran (similar to JT65)

    WSPR 2.00 r1714 tarball
    
    ./configure    (notice that it says it's building 1.11)
    make
      gave error on 
Could not locate executable g77
Could not locate executable f77
	/usr/bin/f95
        /usr/bin/gfortran

       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/
     ./configure
     --
     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
    --ftp://anonymous%40g95%2Eorg:none@ftp.g95.org/v0.91/g95_source.tgz

     
     NOTE:  The SPEC file found at
           ftp://anonymous%40g95%2Eorg:none@ftp.g95.org/g95.spec
            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
      
        http://www.geekymedia.com/tech-articles/rhel5-centos5-rpms-for-python-2-5-and-2-6/ 
             --> 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:

        http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjt-dev-guide.html#_package_matrix


  +---------------------------+
  | To be updated for Centos6 |
  +---------------------------+

    http://physics.princeton.edu/pulsar/K1JT/devel.html

   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

     Centos6: 
     --------
        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:

     http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/wsjt.spec


  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:

  Centos6:
  -------
  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
    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.  


       IMPORTANT:
       ----------
           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:
           ----------------
            http://list-serv.davidv.net/pipermail/moon-net_list-serv.davidv.net/2008-August/013751.html

            ~USER/.asoundrc
            --
            pcm.radio {
                    type hw
                    card 2
                    device 0
            }
            pcm_slave.radioslave {
                    pcm radio
                    rate 48000
            }
            pcm.radioconv {
                    type rate
                    slave radioslave
            }


         Legacy solution: 
         ----------------
         http://www.nitehawk.com/w3sz/wsjt596hints.html
         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


Download the sources:
   http://www.langelaar.net/projects/jnos2/downloads/linux/installerv2.tar.gz

tar xzvf 
./jnosinstaller 

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



ax25@x-berg.in-berlin.de

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:

            http://www.w1hkj.com/LinuxApps/pskscope.3.0.tar.gz

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
     ./configure
     make
     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:
   
        MIXER="/dev/mixer"

       - 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: Seems to have newest code: https://github.com/ON4QZ/QSSTV Has main release tar files: https://www.qsl.net/o/on4qz//qsstv/index.html Obsolete: 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.

      IMPORTANT:
      ----------
      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)!  


28a. - QSSTV - Compiling it


  +---------------------------------------------------------------------------------+
  | IMPORTANT: The new Qsstv 9.4.2 release is now using C++ v11 compiler constructs |
  |    #1      that are NOT 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


      # ----------------------------------------
      # (NOT RECOMMENDED)
      #
      # 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

               and

                 %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:

                  %{_docdir}/%{name}/


   # -------------------------------------------------
   # Back to all users (For all SPEC file approaches):
   # -------------------------------------------------

   # Next, let's get the new version of QSSTV as of 10/15/22 
   #  all older versions of QSSTV seem to be gone since ON4QZ's move from 
   #  the old telenet.be domain to this one
   #
   cd /usr/src/redhat/SOURCES
   wget https://www.qsl.net/o/on4qz//qsstv/downloads/qsstv_9.5.8.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:

   http://users.telenet.be/on4qz/history/index.html

  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
                recommended)

  QSSTV 6.0a (alpha) - Unusable - has *major* slant issues and others have 
                       complained as well.  It was never fixed
                       http://users.telenet.be/on4qz/snapshots/

  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
  -----------------------------------------------------
       http://ubuntuforums.org/showthread.php?t=935732

       other qsstv users
        http://forums.fedoraforum.org/showthread.php?p=1357105

    --gt; Seems the solution is to turn off "Auto Slant Adj."

  Ubuntu bug tracking slant problems - no assignment
   https://bugs.launchpad.net/ubuntu/+source/qsstv/+bug/581407


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)


      General:  
           - set the paths to match the ones we created above

      Interfaces: 
           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:

     http://users.telenet.be/on4qz/qsstv/documentation/gettingstarted.html#calib



  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:

       http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/resize-jpg-jp2-640-variqual.sh


  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
  make
  cp geoid /usr/local/bin/
  
  #Log as the user you plan on being when running fl_geoid
  cd /usr/src/redhat/SOURCES/fl_geoid
  ./install_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 
     either:

      - 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:

        http://drm.sourceforge.net/installationrpm.html#linux


  Some Linux specific DRM building instructions beyond these instructions can be 
  found at:

       http://drm.sourceforge.net/installationrpm.html

          and

       http://www.fineware-swl.com/drm.html


  NOTE:  I also found an older Binary RPM for Dream:

       http://www.sp5pbe.waw.pl/~sp5smk/drm.html


 
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 
         fftw-devel-2.1.5-4.el5.rf.i386.rpm


        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 \
ftp://ftp.pbone.net/mirror/ftp.centos.org/5.4/os/i386/CentOS/qt4-devel-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 \
/usr/src/redhat/RPMS/i686/

    
-------------
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 *

    cd 


    sh bootstrap
    ./configure
    

Legacy info -- old dream 1.12b


Legacy info -- incompatible newer versions of qwt

ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/9/Everything/i386.newkey/os/Packages/qwt-devel-5.0.2-6.fc9.i386.rpm

     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 \ 
ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/9/Everything/i386.newkey/os/Packages/qwt-devel-5.0.2-6.fc9.i386.rpm


http://qwt.sourceforge.net/
     rpm -ivh \
http://www.gtlib.gatech.edu/pub/fedora-epel/5/i386/qwt-5.1.2-0.el5.i386.rpm \
http://www.gtlib.gatech.edu/pub/fedora-epel/5/i386/qwt-devel-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 \
faad2-devel-2.0.1cvs2006124-1.i686.rpm
         


32. - Tuning Dream -DRM


  +---------------------------+
  | To be updated for Centos6 |
  +---------------------------+

http://www.tima.com/~djones/DRM_power.htm


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:
   http://www.pa0mbo.nl/ties/public_html/hamradio/rxamadrm/rxamadrm.pdf

  +--------------------------------------------------------------------------+
  | 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:

                   DEPRECATED:
                   -----------
                   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

          make

     - Next, since things are still not in a RPM, let's make sure we can write in this directory

          chown -R $USER .


Running RXAMADRM:
-----------------
     - Go ahead and run the new program by running:

          ./rxamadrm.tcl

     - 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
        blue.

      - 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
          path!

          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 \
ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/9/i386.newkey/tcl-devel-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)
python-imaging-tk-1.1.6-4.el5.kb.i386
        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)
tk-devel-8.4.13-5.el5_1.1.i386


    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 \
ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/9/x86_64.newkey/tk-devel-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)
python-imaging-tk-1.1.6-4.el5.kb.i386


    # 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
program.

  http://pa0mbo.nl/ties/public_html/hamradio/txamadrm/index.html


  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:

       http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/resize-jpg-jp2-640-variqual.sh


Prerequisites:
--------------
  - 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


Compiling:
----------
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

  make

  #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
     ./startdrmtx

       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
          ./startdrmtrx.sh


  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:

              CAT

           or

              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:

                 /dev/USI_PTT

      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 
         transfer

      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-6.5.4.7-5.el6.x86_64 (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.

      #Dependencies:
      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 \
ImageMagick-doc-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 \
http://imagemagick.mirrorcatalogs.com/linux/CentOS/x86_64/ImageMagick-doc-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 
  here:
     http://downloads.sourceforge.net/project/linkt/linkt/0.8rc3/linkt-0.8rc3.tar.bz2

  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
  ./configure

  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:

   http://www.outpostpm.org/

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
         https://www.scc-ares-races.org/data/packet/client-software.html

         #Regular Outpost version
         https://www.outpostpm.org/index.php?content=downloads


      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
            fixme:ole:OleLoadPictureEx
            (0x96e674,2246,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x33fa80),
            partially implemented.
            fixme:ole:OLEPictureImpl_SaveAsFile (0x125960)->(0x12cb98, 0, (nil)), hacked
            stub.
            fixme:ole:OLEPictureImpl_FindConnectionPoint no connection point for
            {33ad4ed2-6699-11cf-b70c-00aa0060d393}
            --


     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/
              packet-it-forms\msgs


  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:
      
     Legal:
         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"
 
           Setup:
               TNC:
                   "Interface type" tab
                        Device Name:   SCCO_AGW
 
                      Device Type: AGW Packet Engine
 
                   "AGWPE" tab
                        Remote Host: 127.0.0.1
                        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:
                  TNC:
                      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:
             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
     -----------------------------------------------------------
         TNC:
             Interface type tab
                  Device Name:   TELNET

             TELNET server:
                Remote Host: 127.0.0.1
                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
      destination.


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

       ================================================================
       "REVERSE" ROUTINE TO READ ASCII FILES FROM PacFORMS Forms.
          - - - - - - - - - - - - - - - - - - - - - - - - - - - (11/07/12, Ver. 4.4.5)
       ===================================================================

       Result from Pac-Read.ini file:
         BROWSER = DEFAULT
         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

       THE FOLLOWING ARE OUTPOST HEADER LINES:
       :!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):

    Centos6: 
       python-2.6.6
       gtk2-2.18.9
       pygtk2-2.16.0
       
    Centos5:
       python-2.4.3
       gtk2-2.10.4
       pygtk2-2.10.1


Chirp also needs the following other packages and manual installs:

   Centos6:
      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

         #Centos6
            #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

         #Centos5
            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:

  http://chirp.danplanet.com/

To get the newest bleeding edge code out of the SVN depot, goto:

  http://d-rats.com/hg/hgwebdir.cgi/chirp.hg/archive/tip.tar.gz
       or
  http://trac.chirp.danplanet.com/chirp_daily/


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: 
  ./chirpw


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:

   http://www.wxtoimg.com/downloads/

rpm -Uvh /tmp/wxtoimg-2.10.11.i386.rpm


To run it:

    /usr/local/bin/wxtoimg

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
   USA

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!

        https://github.com/nwdigitalradio/paclink-unix

    - 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)
          http://download.prgm.org/dl5di-soft/rms-gateway/
         which replaced "Telpac-node Linux" 
          http://www.prgm.org/projekte/telpac-node/index.html
           
         This is a Linux solution to run your own RMS gateway on Packet 
         radio that interfaces to Winlink CMS messaging servers on the 
         Internet


There are a few new offerings that focus on using a smart phone or tablet as the main
UI interface interacting with a nearby computer via say Wifi.  Some of these solutions
are VERY slick:

   - Winlink on Android Device (WoAD) : https://woad.sumusltd.com/home
        This is a VERY sophisticated app for Android that natively supports:
           - CMS and P2P connections
           - AX.25 packet radio
              - native stack in the app itself via
                 - wired audio (includes FX.25 support)
                 - Bluetooth audio (includes FX.25 support)
              - KISS support via
                 - TCP-KISS over a TCP/IP connection to a serving TCP-KISS device
                 - USB serial connection to a KISS TNC
                 - Bluetooth serial connection to a KISS TNC)
           - VARA FM and VARA HF over a TCP/IP connection to a serving VARA device
           - ARDOPv1 over a TCP/IP connection to a serving ARDOP device
           - an Internet connection

   - PiGate : http://www.pigate.net
        This is a sophisticated solution that provides a web interface to devices like
        computers, smartphones, tablets, etc. on the same network connection.  Running
        on a Raspberry Pi, this Pi OS image runs web services, email services, AX.25
        packet radio services, ARDOP services, 

        NOTE: Pigate is primarily designed to work with a TNC-PI or other serial based
              TNCs connected to a Raspberry Pi but version 2.2 added native Direwolf 
              supportA


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:

   http://bazaudi.com/plu/doku.php?id=plu:before_you_start



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
        connection:
        ----------------------------------------------------------------

           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>


       ALIASes:
       --------
       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:

  http://www.josephoregonweather.com/HAM/KB7DZR%20APRS%20COMMANDS.pdf


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:

   http://getpat.io/


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:

   http://go-repo.io/

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:

   $GOPATH/bin/hello

   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...
   Enjoy!
   --


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 
   password:  
   --
      "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 52.54.153.253:8772 (tcp)
   [WL2K-5.0-B2FWIHJM$]
   ;PQ: 40312364
   CMS>
   >FF
   ;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%
   >FF
   FQ
   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
   ========================================
   MID:  UMIDPSMT62YL
   Date: 2018-04-20 21:14:00 -0700 PDT
   From: KI6ZHD
   To: KI6ZHD
   Subject: Test #2

   This is test #2

   Attachments:

  ========================================
  --

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
   Cc:
   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]:
   MID:  KXKTW2HJKVYA
   Date: 2018-04-21 10:30:00 -0700 PDT
   From: KI6ZHD
   To: KI6ZHD
   Subject: Test #3

   this is test #3

   Attachments:

   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)
   [WL2K-5.0-B2FWIHJM$]
   ;PQ: 96625531
   CMS via K2RDX >
   >FF
   FQ
   2018/04/21 10:56:58 Disconnected.
   --

Cool.. it just works and now you can read your messages offline as previously shown in this
section.


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
first.

To get started, make sure the ARDOP modem is running per the previous program using:

   /usr/local/bin/start-ardopc.sh

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 1.3.19.0
   KI6ZHD has 112 minutes remaining with K2RDX
   {SFI = 073 on 2018-04-21 16:00 UTC}
   [WL2K-5.0-B2FWIHJM$]
   ;PQ: 47077525
   CMS via K2RDX >
   >FF
   ;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%
   >FF
   FQ
   2018/04/21 10:53:31 Disconnected.
   --

Cool.. it just works and now you can read your messages offline as previously shown in this
section.


Btw, PAT can do a lot of other things.  To get a hint of what else the CLI offers, simply run:

   ./pat
   --
   Pat is a client for the Winlink 2000 Network.

   Usage:
     ./pat [options] command [arguments]

   Commands:
     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.

   Options:
         --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:
   
      https://www.winlink.org/userPositions
         


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:

   http://127.0.0.1:8080



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 - Quisk 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
              GnuRadio


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:

   http://superkuh.com/rtlsdr.html

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:

   http://blog.kf7lze.net/2012/09/14/round-up-of-rtlsdr-upconverter-choices/

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:

   Low-End

      - 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:


Software: 
---------
There are MANY Linux-based SDR programs out there:

  Quisk  - What we are going to install in this section  (shown above)

  Gqrx   - A pretty SDR program that is both easy to use but powerful

  sdrglut - A light weight, stripped down GUI program that is still very useful

  LinRad  - A very powerful yet complex SDR program more suitable for scientific use

  etc.


Hardware:
---------
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):
   make

  - 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
        id:

            #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":"
        to

         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

     7. 


  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


Cmake
-----
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 
Centos6.  


  # 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/2.8.12.1/1.fc19/src/cmake-2.8.12.1-1.fc19.src.rpm
  rpm -ivh cmake-2.8.12.1-1.fc19.src.rpm


  #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-2.8.12.1-1.el6.x86_64.rpm

--

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 \
      /usr/src/redhat/RPMS/x86_64/libusbx-devel-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
       http://downloads.sourceforge.net/project/qwt/qwt/5.2.3/qwt-5.2.3.tar.bz2

  
       # Next, get an example SPEC file
       #
       cd /usr/src/redhat/SRPMS
       http://vault.centos.org/6.5/os/Source/SPackages/qwt-5.1.1-4.1.el6.src.rpm
       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

               and

         #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 \
noarch/pygtk2-doc-2.24.0-1.el6.noarch.rpm


42c2. - Compiling GnuRadio Dependencies

GnuRadio
--------
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 3.7.9.2
  

 
   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 3.7.4.1
      #
      #
      #  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 3.7.9.2
   #
   cd /usr/src/redhat/SOURCES
   wget http://gnuradio.org/releases/gnuradio/gnuradio-3.7.9.2.tar.gz


   # 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/3.6.4.1/1.fc19/src/gnuradio-3.6.4.1-1.fc19.src.rpm
      rpm -ivh gnuradio-3.6.4.1-1.fc19.src.rpm


   # 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 

              Version: 3.7.9.2


          Next, we need to fix a Doxygen issue found starting in 3.7.2.2.  Find the line that says:

                  Source0:

               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:

               %cmake -DENABLE_GR_CORE=ON -DENABLE_PYTHON=ON -DENABLE_DOXYGEN=ON -DENABLE_VOLK=ON \
               -DENABLE_GRUEL=ON -DENABLE_GR_AUDIO=ON -DENABLE_GR_ATSC=ON -DENABLE_GR_VOCODER=ON \
               -DENABLE_GR_UHD=ON -DENABLE_GR_NOAA=ON -DENABLE_GR_PAGER=ON -DENABLE_GR_TRELLIS=ON \
               -DENABLE_GR_VIDEO_SDL=ON -DENABLE_GR_WXGUI=ON -DENABLE_GR_UTILS=ON -DENABLE_GRC=ON \
               -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:

           %{_includedir}/*

              and under that, add:

           %{_libdir}/cmake/gnuradio/*
           %{_libdir}/cmake/volk/*



        # Next, as of the 3.7.2.1 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 3.7.9.2 : 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   


     IMPORTANT NOTE #1:
     ------------------
         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


     IMPORTANT NOTE #2:
     ------------------
     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-3.7.9.2/build/gr-filter/swig && /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-3.7.9.2/build/gr-filter/swig \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-filter/swig -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-filter/lib \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-filter/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-filter/lib \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-filter/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fft/lib \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fft/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gnuradio-runtime/include \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gnuradio-runtime/include \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gnuradio-runtime/swig \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gnuradio-runtime/swig -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-3.7.9.2/build/gr-filter/swig/filter_swigPYTHON_wrap.cxx

       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-3.7.9.2/build'
       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-3.7.9.2/build/gr-atsc/lib && /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-3.7.9.2/gr-atsc/lib -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-atsc/lib \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-atsc/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-filter/lib \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-filter/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-filter/lib \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-filter/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fft/lib \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fft/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-analog/include \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-analog/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fec/lib \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fec/lib/viterbi -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fec/lib/reed-solomon \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fec/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gnuradio-runtime/include \
-I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gnuradio-runtime/include    -o CMakeFiles/gnuradio-atsc.dir/atsc_depad.cc.o \
-c /home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-atsc/lib/atsc_depad.cc 
      Linking CXX shared library libgnuradio-digital-3.7.9.2.so
      cd /home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-digital/lib && \
/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-3.7.9.2.so.0.0.0 -o libgnuradio-digital-3.7.9.2.so.0.0.0 
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-3.7.9.2.so.0.0.0 \
../../gr-filter/lib/libgnuradio-filter-3.7.9.2.so.0.0.0 ../../gr-blocks/lib/libgnuradio-blocks-3.7.9.2.so.0.0.0 \
../../gr-analog/lib/libgnuradio-analog-3.7.9.2.so.0.0.0 ../../volk/lib/libvolk.so.1.2.2 -lboost_date_time -lboost_program_options \
-lboost_filesystem -lboost_system -lboost_thread ../../gr-filter/lib/libgnuradio-filter-3.7.9.2.so.0.0.0 \
../../gr-fft/lib/libgnuradio-fft-3.7.9.2.so.0.0.0 -lfftw3f -lfftw3f_threads ../../gr-blocks/lib/libgnuradio-blocks-3.7.9.2.so.0.0.0 \
../../gnuradio-runtime/lib/libgnuradio-runtime-3.7.9.2.so.0.0.0 ../../gnuradio-runtime/lib/pmt/libgnuradio-pmt-3.7.9.2.so.0.0.0 \
-lrt ../../volk/lib/libvolk.so.1.2.2 -ldl -lorc-0.4 -lboost_date_time -lboost_program_options -lboost_filesystem -lboost_system \
-lboost_thread
       /usr/bin/ld: libgnuradio-digital-3.7.9.2.so.0.0.0: 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-3.7.9.2.so.0.0.0] Error 1
       make[2]: Leaving directory `/usr/src/redhat/BUILD/gnuradio-3.7.9.2/build'
       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 \
gqrx-2.5.3-1.20160307git8bbe051d.el6.x86_64

   #old
   #    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-3.7.9.2-1.el6.x86_64.rpm \
x86_64/gnuradio-examples-3.7.9.2-1.el6.x86_64.rpm \
x86_64/gnuradio-devel-3.7.9.2-1.el6.x86_64.rpm \
noarch/gnuradio-doc-3.7.9.2-1.el6.noarch.rpm


   #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.

NOTE:
* 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 \
noarch/gr-iqbal-doc-0.37.2-3.el6.noarch.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
               and
            %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 \
/usr/src/redhat/RPMS/x86_64/rtl-sdr-devel-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:

   rtl_test


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:

       https://github.com/airspy/firmware/releases

     If there is a newer version of code, consider following these instructions
     to upgrade your firmware:

       https://github.com/airspy/firmware/wiki/Linux-how-to-flash-airspy-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
       done
       --

     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
     bandwidth).

     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
       done
       --

     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: 

          http://www.sdrplay.com/docs/Mirics_SDR_API_Linux_install_technote_r2p0.pdf



   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:

        SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1df7",ATTRS{idProduct}=="2500",MODE:="0666"

      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...                                         
       Finished.
       --

      . 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...

  CRITICAL 
   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

          to

        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} ..

    to

      %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
     %doc AUTHORS COPYING

   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
     #%doc AUTHORS COPYING

   Next, go down to the "%files doc" section and add the following as the FIRST
   line under that section:

     %doc AUTHORS COPYING
  --


  # 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 \
noarch/gr-osmosdr-doc-0.1.5-4.20160704git164a09fc.el6.noarch.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 3.7.9.2) 

  - 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 
         versions.

         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 \
gstreamer-plugins-base-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

         or

    # 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
    
    # RECOMMENDED:
    #   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: 
               79560565d9f36b17bc01130c49b2f69350ede2ee
   
       2. Update the GIT date:            
               20161006

       3. Update the Version:             
               2.6

       4. Update the Release to:          
               1.%{git_suffix}%{?dist}

       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
     make
     -----------------------------------------------------
     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):
    ./gqrx


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)

               airspy=0,bias=0

                 - 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
                   frequency

          - 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:

                  10000000
 
              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):
               
                  ,pack=1

                - 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
                       -120.0Mhz



      - 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 
             frequency

  - 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
         BW.

  - 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):

            http://www.nws.noaa.gov/nwr/nwrbro.htm 

      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
       Airspy



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:
--

   WELCOME TO 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

   =>N

   Percentage of screen width to use(25 to 100):
   =>75

   Percentage of screen height to use (25 to 100):
   =>75
 
   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 
     passband
   - 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 
started:

   #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

..WIP..

   STOP:  Currently seeing the following compile error which might require FFTW v3.3.x but Centos6
          only has v3.2.1


  build requires:
    git

  apply makefile diff


https://github.com/szpajder/RTLSDR-Airband/wiki

https://github.com/khaytsus/direwolf-init

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:


    SDRAngel - https://www.sdrangel.org/
    --
    SDR RX/TX transceiver:

       Native HW support for: Airspy, Airspy HF, Airspy Discovery, BladeRF, Fun Cube, HackRF, 
                              Kiwi SDR, LimeSDR, LimeSDR Mini, Lime RFE, Perseus, PlutoSDR, 
                              RTL SDR, SDRplay RSP1, RSP2, RSPduo, RSPdx, USRP B210, XTRX
                              Additional devices via Soapy and audio interface

       Analog decode: AM, APT, Broadcast FM, DSB, FM, NTSC, PAL, SSB, VOR

       Digital decode: 802.15.4, AIS, ADS-B, APRS, DAB, DAB+, DCF77, DMR, dPMR, D-Star, DVB-S, 
                       DVB-S2, FreeDV, LoRa, M17, MSF, Packet (AX.25), Pager (POCSAG), RS41 
                       Radiosonde, TDF, WWVB
    --


    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
    GUI.  

      ---> 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.
              #
              https://bugreports.qt-project.org/browse/QTBUG-29089

    http://napan.ca/ghpsdr3/index.php/QtRadio_Installation#Installing_compiler_and_autotool
    --


    SDR-J - A Java based SDR program
    --
    http://www.sdr-j.tk/index.html


    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:

       http://sdrsharp.com/
    --


    sodiraSDR - Software Radio
    --
    Windows program under WINE:

       - Decodes AM envelope, AM synchronous, AM stereo, LSB, USB, FM, FM Broadcast, DRM30, DRM+
         decoding of AMSS, DCF77, RDS, RF sensors
       - ExtIO receiver support
       - SpyServer receiver support
    --


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
                       features.

   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
   http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/svxlink-git-maint.spec
   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 
    now:

    # 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

 --or--

    #   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

   next, 

            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:

    #libasync
    Epoch: 1
    Version: 1.3.1

    #libasync-devel
    Epoch: 1
    Version: 1.3.1
    Requires: libasync = %{epoch}:1.3.1
    Obsoletes:      svxlink-server-devel < 1.4.0-1

    #echolib
    Epoch: 1
    Version: 1.3.1

    #echolib-devel
    Version: 1.3.1
    Requires: echolib = %{epoch}:1.3.1
    Obsoletes:      svxlink-server-devel < 1.4.0-1

    #qtel
    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

    #svxlink-server
    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 \
    svxlink-server-1.4.1-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 \
    svxlink-debuginfo-14.08.05-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:
          http://www.ebay.com/itm/EASY-DIGI-Sound-Card-Interface-PSK-RTTY-SSTV-NBEMS-JT-65-PCB-KIT-/221082800840?pt=LH_DefaultDomain_0&hash=item33798fd2c8

  - Sound card isolation, COS detection, DTMF decode, requires a serial port for PTT:
          https://www.foxdelta.com/products/foxecho.htm

  - Sound card isolation only, no-serial port PTT:
          http://www.vk2zay.net/article/161

  - 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:

           MODULE_PATH=/usr/lib/svxlink

        to

           MODULE_PATH=/usr/lib64/svxlink


      - 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 
        changing:
 
             #CARD_SAMPLE_RATE=16000

        to

             CARD_SAMPLE_RATE=48000


      - If you plan on posting your location information into the Echolink and/or
        APRS systems, uncomment out the line:

           #LOCATION_INFO=LocationInfo

        to

           LOCATION_INFO=LocationInfo

      ----------

      - 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:

             MODULES=ModuleHelp,ModuleParrot,ModuleEchoLink,ModuleTclVoiceMail

          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:

           CALLSIGN=MYCALL

        - 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:

                SHORT_IDENT_INTERVAL=10

           - 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.

                LONG_IDENT_INTERVAL=0

           - 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:

                #IDENT_ONLY_AFTER_TX=4

             to

                IDENT_ONLY_AFTER_TX=4



        - (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:


                QSO_RECORDER=8:QsoRecorder

           - 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:

           CALLSIGN=MYCALL

        - Svxlink offers a lot of functionality via the MODULES feature.  By default,
          it enables:

             MODULES=ModuleHelp,ModuleParrot,ModuleEchoLink,ModuleTclVoiceMail

          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:

           2=EchoLink:767882#

      ----------

      - 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
        order:

           [QsoRecorder]
           ENCODER_CMD=/usr/bin/oggenc -Q \"%f\" && rm \"%f\"

      ---------

      - Under the [Rx1] section, change the following to reflect your audio 
        setup:

           AUDIO_DEV=alsa:plughw:0

        For my setup, I'm using ALSA device #3 and thus needed:

           AUDIO_DEV=alsa:plughw:3,0


        - 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:

            SQL_DET=VOX

          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:

              #SQL_DET=VOX
              SQL_DET=SERIAL
              # for my specific setup, I use a custom Udev-named serial port
              SERIAL_PORT=/dev/d710-vfo
              SERIAL_PIN=CTS


        - (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:

              DTMF_DEC_TYPE=INTERNAL

          and I commented out the line 

              DTMF_SERIAL=/dev/ttyS0

           to

              #DTMF_SERIAL=/dev/ttyS0
           

      ----------

      - Under the [Tx1] section, change the following to reflect your 
        setup:

           AUDIO_DEV=alsa:plughw:0

        for me using ALSA device #3, I needed:

           AUDIO_DEV=alsa:plughw:3,0


        - 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:

            PTT_TYPE=SerialPin
            PTT_PORT=/dev/d710-vfo
            PTT_PIN=RTS

          +------------------------------------------------------------------------------+
          | ** 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

              APRS_SERVER_LIST=noam.aprs2.net:14580


          - Enable the Echolink status server by removing the #

              STATUS_SERVER_LIST=aprs.echolink.org:5199

          - 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
              LON_POSITION=121.59.59W
              LAT_POSITION=37.20.36N

            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:

              CALLSIGN=EL-KI6ZHD

          - 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: |
              +-------------------------------------------+
                NOTE1:
                     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 
                     here.

                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,
            etc
              --
              FREQUENCY=146.595
              TX_POWER=50
              ANTENNA_GAIN=9
              ANTENNA_HEIGHT=6m
              ANTENNA_DIR=-1
              PATH=WIDE1-1
              BEACON_INTERVAL=10
              TONE=136
              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:

              CALLSIGN=MYCALL-L


         - Change the line to reflect your unique Echolink Sysop password:

              PASSWORD=MyPass


         - 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:

               http://www.pgo.sytes.net/SvxLink/?SvxLink%20User%20List%20all%20over%20the%20world.

           
         - Go ahead and update the other Echolink fields as well.  For my setup, I used the
           following:

            SYSOPNAME=David

            DEFAULT_LANG=en_US
            DESCRIPTION="You have connected to a SvxLink node,\n"
                        "a voice services system for Linux with EchoLink\n"
                        "support.\n"
                        "Check out http://svxlink.sf.net/ for more info\n"
                        "\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:

                       audio:x:63:svxlink
         
       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 192.168.0.50.  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
              hardware

           2) Only configure one type of port forwarding mechanism at a time.  Do
              not configure say Port Forwarding and Port Triggering at the same
              time
                
       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 192.168.0.50.  From the Internet, you'd 
       portforward INCOMING:

                    5198/udp
                    5199/udp
                    5200/tcp
 
       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.

       NOT REQUIRED:
       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
   will:

     - 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
       ----------
         IMPORTANT:
         - 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:

           http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/d710-qsy.sh

         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 
             knob) 

                   /-------------------------------------------------------\
                  |     +--------------------------------------------+     |
                  |     |                                            |     |
                  | 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/ |
                  \ \    /                                 |               /
                   \---------------------------------------|--------------/
                                                           |
                                                          PF2

             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

                   ************************************************
                   Mandatory:

                   - 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 207.182.41.4 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
             in.                         
             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:

        http://sourceforge.net/apps/trac/svxlink/wiki/InstallationInstructions#Postinstallstuff

     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 
         frequency.  

           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
                  there.

       - 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 68.178.200.136
       Incoming EchoLink connection from KI6ZHD (David) at 68.178.200.136
       Spurious audio packet received from 68.178.200.136                
       Incoming EchoLink connection from KI6ZHD (David) at 68.178.200.136
       --- EchoLink directory server message: ---                        
       EchoLink Server v2.5.9997

       ECHOEC2-3: Herndon, VA USA

       Incoming EchoLink connection from KI6ZHD (David) at 68.178.200.136
       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 
    powerful!
    
       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:

            2#

          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
          tones:

            2# 

          and the svxlink program should announce your Echolink node number.
  
          NOTE: 
            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:

            1#
         
          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:

            9999#

          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
          voice.

          NOTE: 
            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
          such.


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:

     [Rx1]
     #default is 0
     sql_start_delay=50
     #default is 2000
     vox_hangtime=2500
     #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:

   http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/start-svxlink.sh

   This script also requires the following other scripts:
   --
   http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/modemtest-reset-serialport.pl
   http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/enable-disable-sleep.sh


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:

            http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/start-svxlink.sh

    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:

             /usr/local/sbin/start-svxlink.sh


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:

            81#

         The svxlink program will announce that the QSO_RECORDER feature 
         has been enabled.  

         NOTE:
               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:

            tmp_121010090933.wav

         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:

           80#

         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:

         from:
               tmp_121010090933.wav 

         renamed to:
               qsorec_121010090933_121010093615.wav

      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 \
           /usr/share/svxlink/sounds/en_US/EchoLink/greeting.wav.orig

           mv /tmp/greeting.wav \
           /usr/share/svxlink/sounds/en_US/EchoLink/greeting.wav


    To Add to the doc:
    ------------------
    - Svxlinkwrapper - A python wrapper script that improves on svxlink
      system logging, etc.  
      http://guysoft.wordpress.com/2012/05/17/svxlinkwrapper/


    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,
    etc

  - 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 
    occur

  - 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
----
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
computer:

   - 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 
           details.

           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:

                    http://www.echolink.org/validation 

                 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): 
      --
      http://www.echolink.org/links.jsp


      IRLP enabled repeaters: 
      --
      http://status.irlp.net/index.php?PSTART=7


   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 
   page:

             http://status.irlp.net/?nodeid=3246

   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 
                             stations

        ---

        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
                             node

   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 
   account.



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:  

       P25
       MotoTRBO/DMR
       NXDN
       Yaesu's new 4FSK
       Dstar

    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:

   http://www.k6mdd.org/k6mdd/register.html

   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:

        https://k6mdd.dstargateway.org/Dstar.do

  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:

   http://www.k6mdd.org/k6mdd/register.html 

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 
       suffixes?
     - 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:
         http://www.bay-net.org/articles.html

     - Additional points are well covered here: 
         http://www.dstarinfo.com/Data/Sites/1/SharedFiles/presentations/dayton2012/%284%29-basic-programming.pdf


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:

     http://www.dstarinfo.com/dstar-web-calculator.aspx


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: 
        http://groups.yahoo.com/group/dstar_digital/message/9943
 
       But here is a clear read on why Source Routing can be very bad: 
          http://groups.yahoo.com/group/dstar_digital/message/9947


  - 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:

         http://napasars.net/2010/dstar-tutorial/

  - 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:  

         http://napasars.net/2011/dstar-blog-2/

  - Some additional points that might be helpful as well:

    - How to get consistent radio memories across radios both digital and
      analog: 

       http://chirp.danplanet.com/

   - Build your data own cable for both radio memories and accessing the
     DV-DD data.. and save yourself from a pointless $40 Icom cable:

       http://www.d-rats.com/documentation/frequently-asked-questions/1-general-operation/12-what-cable-do-i-need


Additional reading:

   - Dstar Voice linking Etiquette: 
     http://www.dstarinfo.com/Data/Sites/1/SharedFiles/presentations/dayton2012/%286%29-best-practices.pdf

   - 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 
       details!



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:

       http://www.d-rats.com/download/doc/D-RATS-TCARC-2010.pdf


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:

   # A major stabilization and bug fixes of the original code but still based on Python2
   #
   https://github.com/maurizioandreotti/D-Rats


   # An effort to port to Python3 and GTK3 (forked from maurizioandreotti)
   #
   https://github.com/wb8tyw/D-Rats/wiki


   # DEPRECTATED: 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
   https://github.com/DigitalHERMES/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:

     ./d-rats


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 
decode: 

    * 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 
                optional
    * D-STAR - Voice frames recognized, vocoder not supported by mbelib. May 
               be possible to pass voice bits to DVDongle. 

http://wiki.radioreference.com/index.php/DSD

   ---------------------------------

   - 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
       make install

       #Make sure the LDPATH was updated
       /sbin/ldconfig -p | grep mbe

       cd ../dsd-1.4.1
       make
       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 
decode


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:

   http://www.windytan.com/2012/11/the-sound-of-dialup-pictured.html


Other interesting tools include:

   https://github.com/tresacton/dspectrumgui


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

      and

         AC_INIT([liquid-dsp],[1.3.1],[support@liquidsdr.org])


   Ok, lets prepare to create the Liquid-DSP archive
   -------------------------------------------------
   This creates the configure script
   ./bootstrap.sh


   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 \
/usr/src/redhat/RPMS/x86_64/liquid-dsp-devel-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
      warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
      --

   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
      warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
      --
      exit

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
   --
   #!/usr/bin/python

   # 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')

   y1.tofile(str(fs1)+'.'+filename)
   --

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


48e. - SigDigger - digital signal analyzer


SigDigger seems like another really powerful tool:

   https://batchdrake.github.io/SigDigger/


   - This multi-platform tool is NOT GnuRadio based so it has the potential to be simpler 
     and also more performant

   - Supports any SDR devices that support the SOAPY API

   - It offers multiple functions:
      - analog signal demodulatioon and playback
      - digital mode and symbol inspection on AFSK, FSK, PSK 
      - Different visualizations like FFT, time domain, etc via OpenGL accelleration
      - passband and baseband recording


This will be written up later but they offer an AppImage so this should be compatible with
most modern Linux distributions (64bit)


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


statserial 
    - Shows the state of the various serial pins and what not. Very helpful.

      #from the EPEL repo:
      yum install statserial
      statserial /dev/ttyUSB0


setserial 
    - 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.
     

stty 
    - A tool to send lower level commands with controlled formatting to tty 
      ports


modemtest
    - 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!!

serlook 
      -----------
      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 (*NIX only)
    - 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 Linux, Mac, and Windows 
     - 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 Linux 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
    - https://sourceforge.net/projects/syncterm/files/syncterm/
    - 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, 

  - Coolterm 
    - https://freeware.the-meiers.org/
    - Supports Mac, Win, Linux (minimal support) - displays serial port pin status, 
    - Supports receiving / sending ASCII / HEX

  - Gtkterm
    - Simple but modern terminal client written in GTK
    - Supports scrolling, copy/paste, serial line status, HW/SW flow control, etc
    https://fedorahosted.org/gtkterm/

  - picocom
    - https://github.com/npat-efault/picocom
    Light weight terminal program

  - Screen
    - The classic multi-terminal CLI tool also supports detachable terminals controlling 
      serial ports - can also show serial port status with Control-A + i

  - YAT (Yet another Terminal) - Looks to be very powerful - current as of 08/2023
    https://sourceforge.net/projects/y-a-terminal/files/
    - Windows only
    - Looks to be very powerful: Supports RS-232/422/423/485 as well as TCP/IP 
      Client/Server/AutoSocket, UDP/IP Client/Server/PairSocket and USB Ser/HID.

  - RealTerm (old - 2014)
    https://sourceforge.net/projects/realterm/files/Realterm/

  - Zterm for Mac (Old - 2011)
    http://www.dalverson.com/zterm/

  - TT-Term (was TeraTerm) for Windows - very old - 1999
    http://hp.vector.co.jp/authors/VA002416/teraterm.html

  - EmTec ZOC (commercial) for Windows and Mac (also runs on Linux under Wine)
    https://www.emtec.com/zoc/

  - Honorable mentions (would work on Linux under DOSBox):
     - Qmodem : Excellent DOS terminal / BBS program
     - Telix, Terminate, ProComm (DOS) ProComm Plus (Windows), Crosstalk, RIPTERM, etc
     - Kermit : Classic serial terminal program

  - Many others listed here:
    https://en.wikipedia.org/wiki/List_of_terminal_emulators
     
Serial port signal tester
-------------------------
manual-set-rs232-signals.c 
    - This simple program can help set pins high/low which is very helpful for 
      troubleshooting, etc.
      http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/misc/manual-set-rs232-signals.c


50.c - Serial port KISS tools

tmd710_tncsetup.c
    - 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
   ./autogen.sh

   #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"

   ./configure

   $ 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.

     http://sourceforge.net/projects/hfterm/





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
  su

  #  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 \
qt-x11-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 |
  +---------------------------------------------------------------------+

144.910Mhz
----------
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
WR6ABD/R LPRC2/D WR6ABD-1/B LPRC2/N

Packet: fm WR6ABD-0 to BEACON-0 UI  pid=F0
Loma Pioneer Repeater Club www.LPRC.net
--



223.660Mhz
----------
Nothing as of 10:29am 5/29/09 (Friday)


441.500Mhz
----------




Good packet sessions :
----------------------

broadcast K6KP-6 is a BBS run by KN6PE
--

vhfdrop: fm K6KP to MAIL ctl UI^ pid=F0(Text) len 67
0000  Mail for: GIL KN3PE LGREDC LGTEOC MSOEOC SAREOC SNCEOC SNYEOC W6
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:
--
PORTS

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:

MHEARD 3

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


USERS

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 >
B(ye)         PBBS WILL DISCONNECT
J(heard)      CALLSIGNS WITH DAYSTAMP
J S(hort)     HEARD CALLSIGNS ONLY
J L(ong)      CALLSIGNS WITH DAYSTAMP AND VIAS
L [x [y]] [;] LIST MESSAGES x THRU y YOU CAN READ
L <|> call    LIST MESSAGES FROM OR TO CALL
LB            LIST BULLETINS
LC [cat]      LIST CATEGORIES
LL n          LIST LAST n MESSAGES
LM(ine)       LIST UNREAD MESSAGES ADDRESSED TO YOU
LO [+|-]      LISTING ORDER
LT            LIST TRAFFIC
LTn           DISPLAY LOCATION TEXT n=1-4
K(ill) n      DELETE MESSAGE NUMBER n
KM(ine)       DELETE ALL READ MESSAGES ADDRESSED TO YOU
R(ead) n      DISPLAY MESSAGE NUMBER n
RH n          DISPLAY MESSAGE n WITH HEADERS
RM(ine)       READ ALL MESSAGES ADDRESSED TO YOU
S(end) call   SEND MESSAGE TO callsign
S[B|P|T] call SEND BULLETIN, PRIVATE, or TRAFFIC
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
 VIA *WD0DNM,WB6EOC,LPRC2
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
 VIA *MAR5,SARA
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
 VIA LPRC2
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
------------------------------


k6sny-1
--------------------------------------
ENTER COMMAND:  B,J,K,L,R,S, or Help >
B(ye)         PBBS WILL DISCONNECT
J(heard)      CALLSIGNS WITH DAYSTAMP
J S(hort)     HEARD CALLSIGNS ONLY
J L(ong)      CALLSIGNS WITH DAYSTAMP AND VIAS
L [x [y]] [;] LIST MESSAGES x THRU y YOU CAN READ
L <|> call    LIST MESSAGES FROM OR TO CALL
LB            LIST BULLETINS
LC [cat]      LIST CATEGORIES
LL n [;]      LIST LAST n MESSAGES
LM(ine)       LIST UNREAD MESSAGES ADDRESSED TO YOU
LO [+|-]      LISTING ORDER
LT            LIST TRAFFIC
LTn           DISPLAY LOCATION TEXT n=1-4
NL n          SET PAGE SIZE WHEN READING MESSAGES
K(ill) n      DELETE MESSAGE NUMBER n
KM(ine)       DELETE ALL READ MESSAGES ADDRESSED TO YOU
R(ead) n      DISPLAY MESSAGE NUMBER n
RH n          DISPLAY MESSAGE n WITH HEADERS
RM(ine)       READ ALL MESSAGES ADDRESSED TO YOU
S(end) call   SEND MESSAGE TO callsign
S[B|P|T] call SEND BULLETIN, PRIVATE, or TRAFFIC
U(sers)       DISPLAYS EVERYONE CONNECTED TO BBS
ENTER COMMAND:  B,J,K,L,R,S, or Help >
--------------------------------------

> Looking from the output of axlisten, things look ok but it's probably an
> issue with outpost.  Watching it run, it's very chatty and creates a lot 
> of unnecessary checks.

Is outpost in active development?  Sure looks like it could use
some optimizations and add some latencies to let other people into
both the band and a given BBS.  It really seems to dominate.


>I see retransmits from you (however my antenna is very low and has a lot
>of local noise near it).

Does your TNC show full decodes of traffic on the air?  Is that how
you're seeing the retransmits?  I'm on a Kenwood TH-F6A HT using 
soundmodem (TNC emulation) on Linux.  The whole rid isn't very ideal 
right now.  I plan on getting a good antenna this weekend (comments on 
Comet vs. Diamond, vs. ???).  I have an email I've been working over
if you'd be willing to look it over.


>I have an older KPC3 hardware TNC.

It seems like the hardware TNCs do better than soundmodem but this
soundmodem tool is free, it's not very actively developed, etc. but
it does work.

>Look on the NCPA web site for BBS frequencies:
>http://www.n0ary.org/ncpa/ncpabandplan.html
i
Bandplans are one thing but does anyone USE them around here?
4.910 seems busy.  There was also a question on tonight's
City of Santa Clara RACES NET about any cross band digipeaters.
I want to say w6XSC can but I don't know if it's configured.
Thoughts?

--David; KI6ZHD

-andreas de K6OTT


Appendix C - Misc other topics: Baycom TNCs, etc


Baycom serial-attached TNCs:
----------------------------
I've recently been helping Janusz, SP1LOP, to migrate from a Centos3 to a 
Centos5 based machine using external Baycom TNCs which look similar to this:
http://www.baycom.org/bayweb/cat/standard.htm .  These are interesting TNCs 
because:

  1) Though RS232 attached, they don't use the usual TX/RX serial lines as
     these modems are SYNCRONOUS. They use the DTR and CTS lines to do all
     communications.  Check out the following URL to see how they are wired:
     http://www.baycom.org/bayweb/tech/rs-232.htm 

  2) One important point about this is that cheap, incomplete serial devices 
     (ISA, PCI, USB, etc.) *must* support full RS232 flow control or these 
     devices will not work! 
     http://www.tigertronics.com/bptsing.htm#BayCom%20and%2016550%20USART%20problems

  2) Linux natively supports this hardware

Anyway, SP1LOP is uses two of these devices but one of them was attached to a 
PCI-based serial card and it wouldn't get recognized with I/O 0x3400 / irq = 177,
The other Baycom TNC connected to an on-motherboard serial port with I/O 0x3f8 / 
IRQ=4 would work.  As it turns out, the 2.6.18 kernel in Centos5 is missing two 
CRITICAL fixes to support these modems.  Once I patched these into the kernel via 
SPEC patches, all started to work!

I'm adding in these URLs just in case other HAMs find it helpful and the following
URL is very handy to see what other changes have made it into the kernel over the
years:  

http://dev-eole.ac-dijon.fr/projects/eole-kernel/repository/revisions/539ac10c49dd6b813de2920586b0604c3ffab407/changes/drivers/net/hamradio/baycom_ser_fdx.c

Anyway, it took me a LONG time to figure out what was happening for SP1LOP's setup:

    #1 - Support I/O ports higher than 0x1000 and IRQs higher than 15
    http://forum.soft32.com/linux/PATCH-baycom_ser_fdx-ports-0x1000-enhanced-failure-logging-ftopict340811.html 

    #2 - payload corrupt due to CRC being put in the preamble
    http://www.spinics.net/lists/linux-hams/msg01888.html
    
If anyone needs help on how to integrate these patches into the kernel.spec file,
just send me an email.


Appendix D - Radio Quirks : Using my specific radios


This is a work in progress but here are notes I plan on adding for my specific 
radios:

   Kenwood D710
       - Turning on CrossBand Repeat 
            Enable Cross band repeat mode: - menu item 403
            Configure your callsign for the CW IDer - menu item 405
            Enable CW IDer - menu item 406

       - Wiring your own "Echolink" cables so you don't have to run the radio
         in Echolink and LOSE rig control support

   Kenwood TH-F6A to Kenwood D710 
       - Enabling DMTF remote control (poor-man's Kenwood SkyCommand)


99. - To Do - Things that I need to still do


It's never done... EVER.  Needing to add support for newer Centos releases since
Centos6 should be proof to that!  Sheesh!

 a. Doc Fldigi WWV calibration

 b. Add SDR-Angle which a new SDR application that can decode many different AMBE vocoded signals

 c. Figure out what ax25spyd isn't reliable in compiling!


100. - Errata

Page Views since 02/17/14:

Flag Counter

03/04/24 - New doc release - last doc update was 10/28/23

02/05/24 - Minor spelling fixes

12/06/23 - Added more hardware TNC examples

11/10/23 - New URL for ARDOP 

10/14/23 - Added the mention of the agwpe-tools packet terminal program

09/25/23 - Added mention of sdrglut

09/20/23 - Minor cleanups

08/14/23 - Significantly expanded the list of serial terminal programs and added URLs

07/27/23 - Added a web URL for the not recommended Official AX.25 repo

05/16/23 - Added mention of the QtSoundmodem soft-TNC for Linux, Windows, and Mac 

04/10/23 - Minor improvements to Qsstv URLs

04/08/23 - Added the converse windows/linux command line terminal program

01/15/23 - new publish

12/21/22 - Added a referecen to the SigDigger digital signal analyzer tool

12/16/22 - Added another great URL for a Packet tutorial

11/25/22 - Minor updates to the APRS services section

11/10/22 - Added another URL about consistent sound device enumeration

11/08/22 - Added mention about PTT issues with ARDOP on newer kernel versions

10/15/22 - Updated the URLs for Qsstv

10/13/22 - Added mention of the brltty process taking over serial ports like modemmanager

09/30/22 - Updated the dead linux-ax25.org GIT repo URL to the new
           git://linux-ax25.in-berlin.de/pub/scm/libax25 repo though I am still recommending
           to still use the VE7FET repo as of now.  I have started discussions with the various
           owners if we can get a code merge done and deprecate one of the repos

09/13/22 - Added mention of SDRAngel and sodiraSDR SDR programs

08/21/22 - Added XRPi / XRlin to the other packet program list

08/07/22 - New publish 

06/25/22 - Update the list of available APRS server and client programs with current versions, etc

05/11/22 - Added a list of hardware TNCs

05/10/22 - Updated the src URL for the ARDOPC modem

05/01/22 - Added a mention of the WoAD (Winlink on Android app) and the Pigate Raspberry Pi image
           in the Winlink section

04/18/22 - Updated the pkttutor section a bit; nothing big

04/11/22 - New publish

01/01/22 - New URL for a fork of Thomas Sailer's soundmodem

11/11/21 - Minor improvements

10/04/21 - Reorganized the additional AX.25 packet software from Section 0 to Section 9 to be more
           intuitive

06/10/21 - Updated some packet tutorial and Drats URLs

05/11/21 - Added updates about newer Signalink revisions that have better isolation transformers for
           wide data modes

05/10/21 - Updated the deprecation notice a little
         - Added some non-caching HTML tags

04/19/21 - Added another recommended RS232 FTDI-based serial to USB adapter that has diagnostic LEDs

03/28/21 - Added a new link talking about FTDI silicon and it's issues with bit bangging for
           those who need to use it (rare)

03/02/21 - Added a URL on how to improve Signalink sound devices

02/22/21 - Added links to the Other APRS clients section

02/15/21 - Updated the FT950 menu settings for CAT control
         - Updated the update-fldigi-code.sh script to be more intelligent, added deb support
           
02/08/21 - Reorganzied the Preface section a little to group different applications

01/21/21 - Updated URL on Drats Python3 port URL

01/10/21 - Updated the URL for the alsa-capabilities tool

01/06/21 - Added top level note this document is going to be deprecated in favor of the
           new "HamDigify" doc which will now use Ubuntu as a base operating system

12/31/20 - Updated the /dev/serial/by-id kissattach warning details
         - Misc formatting fixes

11/22/20 - Added a critical note about predicable /dev/serial/by-id serial device names and 
           kissattach segmentation faults

11/17/20 - Fixed broken URL for D710 tool and how to compile it

11/04/20 - Updated the soundcards section and added the DINAH device

11/01/20 - Mentioned a new D-rats repo that has Python3 and GTK3 support

10/28/20 - Updated Direwolf to 1.6

10/13/20 - Added a section on enabling debugging programs at compile time

10/11/20 - Added more granular index for Serial tools and utilities
         - Added a few new serial terminal program options

09/10/20 - Added recommendations when setting output audio levels on your soundcard to ONLY
           turn up the audio for the audio channel connected to your radio and MUTE the other
           channel.  This can help avoid audio bleed through and other interference issues

09/07/20 - Minor updates

08/16/20 - Added the "future" dependency to get Chirp working

07/27/20 - Added a few new terminal program recommendations

07/19/20 - Updated the tmd710_tncsetup source code URL to a new and improved version
         - Made mention that the linux "node" program is also known as "axnode" in 
           Debian circles

07/13/20 - Minor updates

05/29/20 - Added other packet tools

05/27/20 - Added Section "42.m - RTL_433 : ISM band protocol decoder utility"

04/30/20 - Added a TBD note for packaging Pat GoLang packages

04/27/20 - Fixed some broken HTML tags

04/25/20 - Added mention of QtTermTCP and EasyTerm (windows via Wine) GUI packet terminals

04/18/20 - Updated Xastir to 2.1.7git

04/13/20 - New publish

04/08/20 - Added a note in the ax25spyd section 
            - how people can make the listen program SUID root 
            - mentioned that the ax25spyd patches are no longer available; email me
              to get a copy of them
         - Updated the Fldigi section to include the master Fl-suite.sh package script
         - Updated Fldigi and other Fl-suite packages
         - Updated the packetrig.sh script to include deeper debugging details
         - Recommemdomg TRXAMADRM users to move to Qsstv
         - Various formatting cleanup

12/29/19 - Added mention of the Linpac develop branch being at 0.27

12/16/19 - Minor spell checking fixes

10/28/19 - Fixed the broken link for 145.050-netrom-and-tcpip-connects.txt

10/24/19 - Removed all references to GDAL from the building of Xastir since it was deprecated

07/29/19 - Updated the URL for soundmodem

07/21/19 - Updated all AMPR details to reflect new/reduced AMPR address space including
           the /usr/local/sbin/manual-ampr-start.sh script
         - Updated the index for PSKMail

07/13/19 - Updated the Outpost for Packet messaging section to reflect a new version
           and other general cleanups

06/23/19 - Some cleanups around AX.25 paclen or MTU
         - Added clarification of max netrom paclen
         - improvements to the packetrig.sh startup script

06/12/19 - Updated the AX25 package section to use the 2/10/19 VE7FET Git repo version
         - Added a recommendation to shutdown the AX.25 stack before installing the new
           AX.25 packages as my reliable, long running system didn't like having it's
           packages changed while the stack was up (it kernel paniced)
         - Some minor typo fixes on setting up the developer environment

05/23/19 - Updated Xastir section to newest pre-release version

05/20/19 - Updated Qsstv to 9.4.2 which includes some bug fixes
         - Added a new "higher speed packet" section
         - Demoted the soundmodem section to be sub-chapters of the Direwolf section to
           low it's visability since all users should use Direwolf instead
         - Fixed some index issues

05/04/19 - Updated the Xastir version to 2.1.1git to test pre-release

04/27/19 - Added Baudline for signal analysis

04/24/19 - Added Inspectrum and LiquidDSP

04/19/19 - Added a note about Qsstv 9.3.3 seemingly not being compatible with Centos 6.x old
           compiler.  Still waiting to hear back from the author.

04/13/19 - Updated the Xastir version to 2.1.1git to gain the faster map download support

03/23/19 - Updated the AX.25 troubleshooting section a bit

02/25/19 - Cleanups to the update-glibc-ax25-workaround.sh script

02/18/19 - Updated the AMPR section a bit and removed old details

02/09/19 - Updated the URL to an alterntive path to the old soundmodem program

12/29/18 - Added a URL on soundcard enumeration

12/09/18 - Minor updates in the RTL-SDR section but this needs a major refresh to update to the 
           newest OSMOSDR, GNuRadio, Gqrx, etc codebases

12/03/18 - Split up the Fldigi setup section into some smaller sections for easier navigation
         - Added the building and usage of the ardop-gui program
         - Renamed the start-arim-ardop.sh script to start-ardopc.sh script and updated it 
           to put ARDOP debuglogs in the expected place

12/01/18 - Updated the ARDOPC version to 1.0.4.1e from 1.0.4.1b to be compatible with the
           new ardop-gui display program
         - Added the update-ardop.sh script to simplify building and updating ARDOP
         - Updated ARIM to v2.4 from 1.8
         - Added a new subsection to include gArim 0.5
         - Updated the ARDOP operating section with some more commonly used frequencies.  
           Also noted heard FSQ stations 

11/30/18 - Added a Linpac Operating section to call out some of the less known 
           abilities of Linpac

11/23/18 - Updated the section on picking a radio soundcard solution

10/21/18 - Added a note that the VE7FET repos have receive major improvements and
           changes which will impact the RPM spec files.  I haven't had a chance to 
           update the doc fully yet

10/18/18 - Updated Direwolf to 1.5 Release

09/28/18 - More details on APRS clients and servers

09/21/18 - Added a list of various APRS clients and servers to the APRS section
         - Updated the ARDOP v1 version from 1.0.2.5l to 1.0.4.1b
         - Added a new section on renewing expiring LOTW certificates using tqsl

09/09/18 - Noted that I'm going to start supporting IPv6 in the future

08/17/18 - Noted that the current Qsstv is 9.2.6.  Updated the startup script as well
           to include supporting the unique config for the Kenwood D710

08/03/18 - Updated the version of Outpost

05/29/18 - Added a new section for RTLSDR-Airband

04/25/18 - Updated the version of ARIM to v1.8 and also updated the configuration of ARIM
           a little bit

04/21/18 - Completed the PAT section that works via it's CLI and GUI interfaces with 
           protocols including TELNET (Internet), AX.25 packet, and ARDOP

04/05/18 - Updated the D-Rats section about a different fork that might revitalize D-rats
         - Updated the Direwolf spec file to support Direwolf-1.5Beta2

03/31/18 - Upgraded Hamlib to 3.2
         - Upgraded ARIM to 1.7.0

03/30/18 - Fixed HTML tag issue for the building ARIM section

03/29/18 - Added a quick noted on users looking to build hamlib 3.2
         - Updated the ARDOP section to reflect the new source code archive name

03/28/18 - Updated the Qsstv section to reflect a new version (9.2.6) and the requirement for Qt5

03/26/18 - Properly added sections for installing, configuraing and operating 
           ARDOP and ARIM
         - Some more formatting fixes

03/17/18 - Noted a PTT hang workaround for the CP210x based USB to serial adapters

03/10/18 - Updated the fltk section to 1.3.4.2

03/09/18 - Some few changes to the ax25spyd section

03/08/18 - Added notes about the Logicneed CH340/341 USB to serial adapters

02/15/18 - Added an example Svxilnk test connection in the Svxlink CheatSheet

02/03/18 - Added a note to install pulseaudio-utils to use pacmd configure PulseAudio 
           sound device routing and audio levels as an alternative to the GUI 
           pavucontrol tool
         - Updated the Chirp section to now include the Python-Serial module for 
           newer versions of Chirp 

01/29/18 - Fixed the broken link for yum-ax25-upgrade-workaround.sh to point to 
           update-glibc-ax25-workaround.sh

01/17/18 - Fixed the index a bit

01/05/18 - Updated URL for the ax25spyd patch

12/16/17 - Updated the Linpac section to reflect version 0.25
         - Noted issues heard about DTR on CP2102 based serial adapers
         - Added SDR-Angle to the todo list

11/28/17 - Updated the version of Outpost

11/06/17 - Updated the SoftTNC intro and added a link on the real performance of AFSK1200 modem over
           FM

11/05/17 - New publish

10/10/17 - Minor cleanups and updates to the DRM section

09/26/17 - Updated the Serial port Troubleshooting section

09/23/17 - Updated Java JRE to v8 Update 144

09/05/17 - New publish 

08/27/17 - Updated the Kernel update section to mention that the ElRepo kernels support
           the AX.25 and other amateur radio kernel modules which means most people no
           longer need to recompile the kernel from sources
         - Updated the FreeDV section to reflect that this package is now in the EPEL repo
           and no longer in the Fedora COPR
         - Updated the TrustedQSL section to reflect that binary RPMs are now available via EPEL

08/16/17 - Added some clarifying points on SUID for Xastir

06/27/17 - Updated the mheardd section

05/28/17 - Updated the AMPR section, added new examples, updated the AMPR GW IP, and made all
           this it's own section

05/22/17 - Added a few other programs that support Winlink for VHF packet and HF Pactor
         - New repo home for paclink-unix

05/09/17 - Added Direwolf section to reflect v1.4 as well as updated the doc to reflect
           that AX.25 connected sessions are now supported as well

04/27/17 - Update to Fldigi 4.0.2 and Flrig 1.3.30

04/23/17 - Fixes for changes in restoring soundcard mixer levels alsactl 
           as things have changed due to recent Centos6 fixes

03/14/17 - Added another URL for finding quality FTDI-based serial cables 

02/21/17 - Added a specific note that Svxlink's Echolink module's location is in ARC seconds

01/25/17 - Updated SDRPlay driver section slightly to mentioned the SDRPlay's closed source
           Mirics driver will never see Centos6 support.  Also added there is a 3rd party
           OSS driver in the works as well that might open this support up

12/04/16 - Noted that Gpredict 1.4git is not compatible with Centos6 due to needing a newer
           version of glib

12/03/16 - Linpac init.mac: noted that newer 4.8.x kernels require the "Loopback Mixing" option 
           enabled to hear the PC speaker output 

12/02/16 - Updated the kernel section for the ElRepo 4.8.11 ML kernel

10/23/16 - Updated the kernel section to support newer ElRepo-ML kernels
           as well as mention failed steps on compiling Centos7 kernels on 
           Centos6 machines

10/20/16 - Updated the ax25spyd section a bit
         - Update the GPS coordinate subsection in the Xastir section

10/19/16 - Minor intro section changes

10/07/16 - Updated Gqrx to 2.6.0 and Qt to 5.6.1

09/21/17 - Updated some of the D-rats download URLs

09/13/16 - Added a new URL for newer versions Golang 

09/08/16 - Updated the Direwolf section to include URLs for tuning packet levels as well as 
           TXDELAY parameters
         - Index fixes

08/26/16 - Added more thoughts on packet radio audio tuning

08/22/16 - Added details and images on the LimeSDR, BladeRF, Ettus B200, and mentioned more SDR HW
         - Reorganized the SDR section a bit

08/18/16 - Updated the Xastir Git version which has proper steps for creating the archive

08/13/16 - Updated Gqrx to build either mainline releases and also TIP bleeding edge
           Git code where all the newest features are

08/09/16 - Updated the Xastir Git version which has new online map sources 

08/07/16 - Updated the QSL Service section a bit

08/06/16 - New publish mostly for Rpi APRS doc

07/30/16 - Fixed some formatting issues in the Index and elsewhere
         - Fixed a LOT of spelling mistakes using Aspell (ugg.. sorry about all that)

07/24/16 - Added the Xastir-sounds package for local Xastir sounds
         - Added an Xastir tuning section to improve the map view, APRS icons, etc
         - Updated the Xastir GIT version

07/17/16 - Added an alternative way to find the soundcard's native sampling rates

07/16/16 - Added a link to Valley Enterprises for USB cables

07/08/16 - Updated Xastir to use new Git repository and updated the spec file

07/07/16 - Major update to the building of libax25/ax25apps/ax25tools as that section
           was still using the old GoogleCode URLS and didn't support Git versioning.

07/05/16 - Mentioned in the Airspy section that the packing feature DOES require
           more CPU processing

07/04/16 - Updated Gnuradio to 2.7.9.2 and gr-osmosdr to the Feb 28, 2016 1.5.0GIT
           - Added more details on how to validate that the build is going to have
             want you need it it, etc
         - Added a 10MSPS Gqrx screen capture
         - Added firmware upgrade notes for the Airspy r2
         - Updated the airspy-host section to 1.0.8 and included the tuning for the
           USB packing feature
         - moved around the RTL-SDR rtltesting section to be closer to building the
           drivers
         - Updates to the Gqrx + Airspy configuration stage for optional parameters
         - Added a Gqrx performance troubleshooting section

07/01/16 - Updated Qsstv to 9.1.7
         - Updated Xastir to 2.0.8
         - Formatted the section a little bit better, broke it up into a few more sections

06/28/16 - Updated Qsstv to 9.1.6

05/13/16 - Mentioned what specific Fldigi modems are 8bit clean

05/07/16 - Added a new section: UI-Chat
         - renamed the Fldigi TCP-KISS section to
           "NextGen HF packet - Using Fldigi's modern modes with Linux's native AX.25 stack via TCP-KISS"
         - Updated the PSKmail section to recommend a newer version of Java

05/06/16 - Updated the Direwolf section on compiling version 1.3 as well as how to 
           configure and tune it
         - Significantly enhanced the "Initial AX.25 setup system settings" section
           for new users
         - More enhancements for first-time manual packet setups including URLs
           for KISS ON/OFF for Kenwood D710 and Kantronics KPC3s

04/27/16 - Additional work on UroNode
         - Added a note on flexd and how the only solution here is to run pc/FlexNet in
           DOSEmu emulator today
         - Added note on the need for unique SSIDs / differences in how say a KPC3 TNC
           uses SSIDs for Netrom vs AX.25 connections

04/17/16 - Updated the Fldigi KISS section to include the new, far more reliable TCP-KISS
           method

04/16/16 - Forgot to include the installation of the built gpsd-devel-3.5-1.el6.x86_64.rpm
           for other programs to build and include gps support

04/10/16 - Updated the Uronode section to 2.5.1

04/09/16 - Updated the Qsstv section to reflect 9.1.1 and also cleaned up and updated 
           the overall chapter a bit (added sections, moved things around, etc).  I
           also updated the associated image resizing script to use GraphicsMagic vs. 
           ImageMagick since I find GraphicsMagick to work better on Centos as well as
           ImageMagick does NOT work well with Xastir

04/01/16 - Noted that Pat needs a newer version of Git to work - section still incomplete
           
03/08/16 - Moved the DSD section to be section 46
         - Created a new section for Pat, the mult-platform Winlink client program
           written in Go.  This is NOT complete yet

03/07/16 - Updated Gqrx to 2.5.3
         - Updated the Gqrx section a bit on how to configure various hardware

02/11/16 - Updated the SDR section a bit more with more details
         - Major updates to the Airspy section

02/08/16 - The libusbx package was been merged back into libusb back in 2014.  
           I've made a note of this and will update the docs shortly to install
           the superset libusb package install instead of libusbx
         - Fixed an SDR index issue

02/06/16 - Added a note on an updated 300baud Soundmodem patch for those who
           still use Soundmodem.  I personally recommend Direwolf now
         - Updated the update-glibc-ax25-workaround.sh script
         - Packaged the Mirics sdrplay API into an RPM
         - Working with SDRPlay to get a Centos6 compatible binary API package
         - Updated the fact that the current Airspy r2 unit is 12bit

01/31/16 - Added the gr-iqbal and libosmo-dsp GnuRadio modules
         - Started the SDR-Play support including updates the Udev and GR-OSOMO
           sections

12/23/15 - Added the recommendation to run volk_profile at the end of the GnuRadio
           section

12/14/15 - Updated the Gqrx section 2.4.0 (updated SPEC file, etc)
         - Updated the gr-osmodr from 0.1.1 to 0.1.5 to support Gqrx 2.3.0

11/20/15 - Updated the Linpac section to reflect new version
         - New posted version to the Internet

11/04/15 - Added new packet modems: dxlAPRS and other options under say JavaScript, Go, etc

10/30/15 - Updated the Xastir section to use GraphicsMagick over ImageMagick
           (have fixed this a long time ago but didn't update the doc)
         - Updated to use the tip of tree CVS (currently at 2.0.7)

10/14/15 - Updated the linpac-check-msgs.sh and packetrig.sh scripts to use /var/lock
           instead of /var/tmp for state flags as some cronjabs would clean out these
           directories

10/12/15 - Started work to update Tqsl to 2.1.2

10/10/15 - Updated the Qsstv screen captures

10/01/15 - New Qsstv version
         - Deprecated the atrpms repo as it's gone silent
         - Uploaded a new release of this doc

09/27/15 - Detail in the Svxlink network section that Port Forwarding
           and Port Triggering are NOT the same thing

09/25/15 - Added a portforwarding section to the Svxlink chapter

09/02/15 - New URL for VE7FET's AX.25 repository but the AX.25 section
           still needs work to support the new Git workflow

08/31/15 - Updated Direwolf URL

07/25/15 - Fixed some index issues

07/24/15 - new URL and version of Tom Sailer's Soundmodem posted

07/22/15 - Added Tom Sailer soundmodem mirror URL

07/12/15 - Minor formatting changes in Linpac section
         - Updated Qsstv to 8.2.12

06/26/15 - Chirp on Centos6 now requires the python-argparse package

06/21/15 - Updated the Linpac index and section
         - Added missing Soundmodem screen captures

06/16/15 - Fixed an index formatting issue

06/06/15 - Added xorg-x11-apps to get xfontsel for Xastir font resizing
         - Shortened some long sourceforge URLs

06/03/15 - Updated the Winlink APRS section a little

06/02/15 - Updated the Fltk section a little

05/24/15 - Updated the Linpac init.mac section to mention that the order of 
           screen look commands MATTERS

05/23/15 - Changed the Xastir system to stop using SUID root and instead use the 
           dialout group

05/10/15 - New release

05/06/15 - Fixed Pskmail startup command

05/04/15 - Updated Svxlink Git Maint repo to get new Echolink IP address conflict 
           fix

04/22/15 - Spelling corrections

04/19/15 - Updated the Svxlink soundcard test section a bit to use 16k samples
         - Other svxlink section updates as well as some serious improvements
           to the svxlink spec file

04/11/15 - Updated the Svxlink section to reflect the newer Git based Svxlink
           code that has various fixes for things like hearing periodic beeping
           from remote Apple IOS based clients, etc
             - New settings 
                   [Rx1] Change SERIAL_PIN=CTS:SET to SERIAL_PIN=CTS
                   [Tx1] Add PTT_TYPE=SerialPin

03/30/15 - Updated the APRX section to use the W6KWF version via Git which has
           some major big fixes
         - Added passcode support to the aprx configuration section

03/07/15 - Updated the TRXAMADRM and Qsstv sections to refer to my new
           resize-jpg-jp2-640-variqual.sh script that now converts jpg files to
           jp2 (jpeg2000), resize to 640x480, and upsizes files to have the maximum
           quality possible.  It's cleanup routines are improved as well

02/15/15 - Updated the external /usr/local/sbin/usinterface-commands.sh script to work
           properly and support better troubleshooting
         - Updated the Qsstv section for FT950 users where their radios stay keyed up
           and they hear a constant CW tone
         - Added a picture of the US Interface Navigator

02/01/15 - Added more details to the Fldigi KISS script which enables using Fldigi's digital
           modes with Linux's native AX.25 stack

12/26/14 - Added a new section on enabling coredumps and ABRT on non-packaged files

12/22/14 - Added an advanced APRS command section
         - minor fix in HTML coding for 6a.soundcards

12/20/14 - Updated the Qsstv section to the newest version; updated it's spec file,
           and added some additional screen captures

12/15/14 - Moved up the Adobe Yum repo priorities as critical flash fixes were being over
           shadowed by older RPM Forge RPMs

12/07/14 - Updated the VE7FET ax.25 packages
         - Updated the kernel to Elrepo 3.17.5
         - Added the /usr/local/sbin/start-fldigi-socat-packet.sh script

12/06/14 - Added a new Advanced Fldigi section on interfacing Fldigi to Linux's AX25 stack
           for HF packet

11/16/14 - Added a Soundcard selection section touching on various cheap to 
           expensive USB soundcards 
         - Updated the Software TNC description area a bit (Direwolf, etc)

11/08/14 - Added a new section: FreeDV 

10/26/14 - Published a new version of the doc to the web

09/06/14 - Updated GnuRadio section a little bit to talk about needing to use a pre-release
           3.7.6 version to fix several issues I've found

09/01/14 - Updated Gnuradio to 3.7.4 to include required fixes for GnuRadio Companion
           - This requires some additional heavy lifting with upgrades to pygtk2 and pygobject
         - stripped out the legacy GnuRadio 3.6.3 material
         - updated the gr-osmosdr section
         - updated the other sections to reflect that when upgrading GnuRadio, you will also
           have to rebuild other gnuradio dependent applications as well

08/31/14 - Updated the Fedora foundation library section a little
         - Updated the Persistent Device documentation to also include the newer
           /dev/serial/by-id UDEV method

08/20/14 - Updated the Linpac section to now use 0.20

08/16/14 - Updated the PSK Mail section to show the newest steps for installing Oracle Java 1.7

08/09/14 - Updated the APRS EMAIL-2 section a bit to make it clearer

08/03/14 - Updated the Linpac section to reflect that 0.20 is about to be released as well
           as specifically call out the older versions of Linpac and their unique use

06/07/14 - Updated the APRX section a little bit to mention that newer APRX code requires
           a valid APRS passcode to be able to inject data into APRS-IS

05/17/14 - Updated the WSPR and WSJT sections to specifically call out that the newer
           versions called WSPR-X and WSJT-X have significantly newer package requirements

         - Update the Gqrx section to specifically call out that it's almost always required
           to upgrade GnuRadio if the user wants to upgrade to a newer version of Gqrx

05/02/14 - Updated the Qsstv section to 8.2.7

04/15/14 - Fixed the APRSLink section for multi-line messages.  You cannot use multiple
           SP (send private) commands
         
04/04/14 - Updated the Svxlink section about configuring the correct GPS coordinate 
           system
         - Updated the Qsstv section to 8.2.6 and did some minor cleanups

03/22/14 - Updated the RTL dongle test and blacklist section a bit

03/18/14 - Added a new APRSlink section - Receive a Winlink message via APRS messages
         - expanded the Send a Winlink message via Internet email section

03/15/14 - Updated QSSTV to 3.2.4 with caveats that 3.1.17 is the only stable version for
           me running Centos 6.5 right now

03/13/14 - Cleaned up the Build Environment section a bit
03/10/14 - Fixed the index to make Direwolf first
03/08/14 - Changed the Appendix A section to be about Centos RPM quirks
           and how to recover from various broken "yum update" situations

02/27/14 - Index formatting improvements
         - Reordered the Packet Tutorial and Soundcard Packet sections

02/18/14 - Added FlagCounter counter just to get an idea how many people are 
           viewing the doc
         - Renamed the document title from "Hampacketizing Centos-6 and Centos-5"
           to "Ham Radio Software on Centos Linux"

02/14/14 - Fixed some broken links for ax25mail-utils

02/05/14 - Updated the QSSTV section to reflect version 8.1.14 which is
           considerably cleaner to build.  Still need to update to update
           the configuration section

01/06/14 - Added an additional kernel build step to include the kernel
           firmware

01/05/14 - Added a Using Gqrx section while includes setting the frequency
           offset

12/21/13 - Updated the Svxlink section to require opus-devel >1.0.0 and
           to also include vorbis-tools

12/16/13 - Added a blacklist entry for the dvb_usb_rtl28xxu so that the SDR
           functionality will work
         - Added Qsstv 8.1.3 that now has HamDRM digital SSTV support

12/15/13 - Added a note in the tqsl section about different broken versions
           of cmake
         - added a custom cmake build section
         - updated the uhd section
         - updated the gr-osmosdr section
         - Updated the Gqrx section

12/09/13 - Updated the RTL SDR section with more updated packages, broke it
           up into more sections, etc.

12/07/13 - Updated qwt which took some work
         - starting to compile all RPMs as non-root and I will re-work the whole
           document to reflect this proper best-practice
          - Updated GnuRadio section to 3.7.2.1 

12/02/13 - Starting to think about upgrading GnuRadio to v3.7, QT to 5, etc.
           to support new versions of Gqrx

12/01/13 - Updated the Svxlink section to the new Dec 2013 release which has 
           major improvements since Aug 2011 when I first wrote this section.
           This required some significant updates to the spec file, etc

11/28/13 - Updated to support TrustedQSL (LOTW) v2.0
         - New version of ldsped-1.17
         - Updated packetrig.sh script to support new ldsped startup syntax

11/21/13 - Fixed some formatting issues in the Index

10/29/13 - Added more terminal communication programs to the Serial troubleshooting
           section
         - Updated the Xastir section a bit, improved the RPM spec file quite
           a bit too

10/20/13 - Make a new Logging section and added CQRLog

10/18/13 - Fixed some broken formatting in the Flrig section

10/01/13 - Updated the Outpost for Wine section to a new version
         - Updated the Outpost section to use LDSPED / AGW connections

09/27/13 - Made APRS an entire section and put the previous sections under it
         - Added a new section on Other APRS clients, specifically breaking
           down various clients including the N7NIX DanTracker
         - Also added a section of my efforts running a Raspberry Pi with 
           a TNC-Pi, WIFI, DanTracker, etc

09/12/13 - Added the missing "mv" in disabling Modem Manager

09/08/13 - Replaced the Unode node software with the new UroNode code
         - Fixed a very important Netrom configuration error in /etc/ax25/ax25d.conf

09/05/13 - Minor update on the qt.spec file BuildRequires

08/30/13 - Completed the LDSPED section

08/29/13 - Added a new soft-TNC, extmodem

08/28/13 - Updated the Ldsped section to include compiling patches, etc though incomplete
         - Consolidated the two Ldsped sections as well

08/25/13 - Updated the WSPR section to support Centos6 as well as create bleeding edge
           versions from SVN.

08/13/13 - Renamed the Soundmodem section to Soft-TNCs
           - Added updated details on DireWolf that it works better on HF packet than
             soundmodem
           - Made soundmodem a subsection
           - Added the beginnings of a Direwolf section

08/11/13 - Cleared up a key point in the soundmodem section that you do NOT use
           kissattach with soundmodem based soft-tncs
         - Cleared up a key point that the device created by soundmodem (usually sm0)
           is correlated to a userspace device such as "f6a" in the /etc/ax25/axports
           file.  Users will *never* use the sm0 device directly.
         - Added a soundmodem troubleshooting section
           - Added mention of a needed DCD patch to not key up the radio upon RX
             for US Interface Navigator and other soundcard setup

08/10/13 - Updated the kernel compiling section to mention modern ElRepo ML and LT
           kernels
         - Added a cleanup stage for the VE7FET SVN AX.25 sources

08/07/13 - Updated the Winlink messaging section to cover more ways to send messages
         - Added a link to a short and concise cheat sheet to advanced Winlink messaging 
           features

08/05/13 - Minor formatting changes for the picking a AX.25 stack section

08/04/13 - Updated the AX25 packages section 
           - Added a few sub-sections where the new sections cover how to get the 
             newest VE7FET code from the SVN trunk and added an additional Netrom 
             patch to be more compatible with KPC3 quality calculations

         - Moved the Xlog section up a few to make space for a new APRS messaging 
           section

         - Added a new section on how to send/receive emails to APRS stations

07/04/13 - Added a new LDSPED section

07/02/13 - Updated the packet node section a bit
         - Added a new section for Uronode 2.x
         - Made the Unode documentation it's own section and deprecated it 

06/28/13 - Fixed a minor issue in the Linpac building section

06/27/13 - Added an example HELP section for Linpac
         - Updated the AMPR section a bit

06/24/13 - Added the "COMP" command to the allowed Linpac commands init.mac file
           as well as recommending users to support lowercase commands and
           adding them to the help.cmd file

06/16/13 - Updated the Wine and Outpost sections 
              - Outpost now works fine with Wine 1.4+
         - Updated the screen capture for TRXAMADRM
         - Updated Section 1's indexing a bit

06/02/13 - Updated the linpac-check-msgs.sh to check for files being activity
           written to avoid sending empty notifications

05/26/13 - Added screen captures for the Gqrx SDR section
         - Updated the Gpredict section to support Centos6 and added screen
           captures
         - Improved the Linpac email notification tool to better track the sending
           callsign+SSID

05/21/13 - Added rtl_test -t for offset identification

05/12/13 - Change the SDR section around to support compiling GnuRadio, 
           rtl_sdr, and gqrx
         - Added a recommendation to support SMP RPM builds by default
         - Dropped the enabling of -g debugging objects for RPM builds
         - Added another link for non-root RPM compiling

05/07/13 - Added a link to my other netrom connection doc

05/04/13 - Added the date-listen-log.sh script to date the packet listen log
         - Added the linpac-check-msgs.sh script to send an email when you 
           receive a new Linpac message

03/29/13 - Added a list of currently known Linux and Windows soundcard packet
           modems, their qualities, etc.

03/21/13 - Added an update to the Soundmodem section that there are two 
           alternative SoftTNC programs out there that should significantly
           out-perform the classic soundmodem.  More research coming on this
           topic

03/20/13 - Broke up the PreSetup section to more clearly break out some of the
           more common issues that need to be fixed on Linux (regardless of
           distro)

03/05/13 - Added a new section following Chirp on some programming ideas to 
           have consistent programming across many different radios

03/02/13 - Updated the Svxlink section to better show the PF2 button on the
           D710 for Echolink mode

02/16/13 - Added a new section for APRX to support sending APRS objects into
           APRSIS as well as support UI unproto digipeating for packet

02/09/13 - Added an important note and reference to a Yum script to work around
           Glibc conflicts with the VE7FET libax25 libraries

02/03/13 - Added the modem-manager section to the deterministic Udev serial port
           section

01/27/13 - Added some additional details on mixer programs in the Soundmodem section
         - Added some recommended saving and restoring sound levels in the Svxlink
           section and the start-svxlink.sh script

01/18/13 - Moved some of the RPM build environment setup from the custom kernel
           section to the PreSetup section
         - Added a Centos link on how to setup a non-root based build environment

01/11/13 - Added a new URL on how to reprogram the USB VID/PID values
           for FTDI devices

12/16/12 - Added some minor cleanups to the Udev sections

12/10/12 - Updated Xastir from 2.0.1CVS to 2.0.5CVS
           - Fixed some missing steps in renaming the CVS directory
           - Added a new dependency for Xastir

12/08/12 - Updated one of the URLs for the isolation boards

12/01/12 - Updated the TRXAMADRM section to reflect the common unification, more details
           on rig control, RX image file uploads via FTP, etc

11/11/12 - Added Flamp
         - Added a new section on how to easily upgrade the various Fl-suite of programs
         - Rearranged the Fldigi and logging related sections to be together 

11/06/12 - Updated the Linpac section with a fix for macro/commands

11/05/12 - Start writing up on AMPR tunneling over the Internet.

10/31/12 - Started updating the Soundmodem section to better reflect Centos6
           settings

10/30/12 - Added a reference to a 2 port FTDI-based USB to serial port adapter

10/26/12 - Major update to the Svxlink section
            - Added a new details on a dangerous issue with the D710 using the
              RTS serial line to control the radio's PTT.  
            - Added a startup script to work around this issue
            - noted that the QSO recorder feature only works from the top level
              and not when other modules are loaded
            - Added a section on how to edit the default voice prompts
         - Removed serlook as it's not compatible with Centos5 or Centos6

10/22/12 - Significant update to the Dstar section
         - Added local audio and SMS notifications to Svxlink echolink connections

10/18/12 - Minor svxlink section updates

10/17/12 - Updated the LOTW section for Centos6 as well as added notes
           on details on renewing your certificates (wow.. it's been 3yrs!)
         - Updated a broken URL for how to submit logs via LOTW and EQSL
         - Noted that the compiling of ax25spyd is still unreliable the first time
         - Added a new section for ldsped but it's just getting started

10/15/12 - Added a Qtel client section
         - More svxlink updates

10/08/12 - Finished the ALSA enumeration section -- man.. very complicated
         - Greatly expanded the Svxlink section to include it's configuration,
           configuring the Kenwood D710 for Echolink mode, etc.
         - Added some Dstar tutorial links

10/04/12 - Added a new Svxlink+Qtel echolink section.  It's not complete yet
         - Updated the Echolink section a bit, refining it, added more details in
           setting up a new account, etc.
         - Added a quick section on paper QSL managers for bureaus
         - Updated the RXAMADRM and TXAMADRM versions

09/25/12 - Added the start of how to create consistent ALSA device enumeration

09/16/12 - Added a link to another 4port FTDI based device for serial connections

09/15/12 - Fixed an important issue where you MUST use the Fedora SRPM
           to get critical patches regardless of which SPEC file you download
         - Broke up the Fldigi section a bit 
         - Broke out Hamlib into it's own compiling section
         - More comments on Qsstv 7.1 and it's serial keying

09/14/12 - Updated RXAMADRM version
         - Major update to the TXAMADRM section

09/13/12 - Updated the QSSTV section to support Qsstv 7.1.7
         - Removed all references to QSSTV 6.0 Alpha (was broken)

09/07/12 - Changed the Linpac section as the SP/SB commands have to be upper case
09/02/12 - Updated the Linpac configuration section 

08/31/12 - Updated the RXAMADRM section with new text, new version, etc
         - Split out the TXAMADRM into it's own section - a work in progress

08/25/12 - Updated the third-party RPM repo section a bit

08/24/12 - Some changes for kernel compiling, more comments in there, etc

08/22/12 - Some additional cleanups on the Fldigi compiling section 
         - Updated the EPEL repo section a little
         - Added some more details on USB to serial adapters

08/20/12 - Fixed a typo on checking the installed RPMs for creating a build
           environment.  Thanks WA6MBZ
         - Cleaned up the Fldigi section a little

08/19/12 - Added some missing lines for downloading patch files needed for 
           various SPEC files and other programs
         - Added a patch for fixing Unode coredumps when locally executed
         - Added a fix in the packetrig.sh script to assign callsigns to 
           various daemons (needed by Unode)
08/18/12 - Updated the legacy node section to be complete -- for troubleshooting
           node servers via netrom
         - Added some key troubleshooting notes in troubleshooting Netrom node
           services
         - Added a key update to the ax25d.conf file for Netrom based 
           connections
         - Added a note about the core problems I was seeing with Unode
           where a workaround and a fix have been identified

08/17/12 - Added a new Dstar and D-RATS section - pretty cool program
           that doesn't require D*star.. who knew?
         - Added screen captures of some of the programs

08/11/12 - Added the start of an Echolink / IRLP :: EchoIRLP section.
           Intro is there, installation and setup needs to be written
         - Change the default Netrom route update to be 60 min
         - Added some descriptions on what the various RPM build directories
           are for, etc.

08/03/12 - Added a note about not setting VERBOSE on Netrom broadcasts
         - Updates to the AX.25 messaging tools section but still no solution

06/28/12 - Cleaned up a bit of the Udev USB enumeration sections, improved the
           debugging details, etc.

06/21/12 - Changed the recommended base AX.25 packages to VE7FET's which
           integrated all of F6BVP's changes.  There is one issue with the
           ax25tools package but it's been resolved via a patch

06/11/12 - Added a new section on filtering packet logs

06/10/12 - Got Unode running on centos 6.2 though there is an outstanding issue 
           where if I connect to the node via localhost, the process will coredump.

06/02/12 - More Unode troubleshooting

06/01/12 - Updated the netrom settings as they were inconsistent (and wrong)
         - Broke out the Netrom and Node services into different chapters
         - Updated the ax25mail-utils section to include that we need to 
           configure four other files to properly relay messages to/from
           the local BBS
         - Trying to build Unode but the program is coredumping

05/29/12 - Working with N6ACK to fix some screwy linpac compile issues
           using non-standard paths

05/26/12 - Updated the Packet radio section talking about trying to find a simple
           PBBS style messaging solution.  Covered pms, axmail so far
         - Added a new, overly simplified section for ax25ipd for tunneling
           AX.25 packets over the Internet
         - Added initial ax25spyd support
         - Adding better Linpac support via adding new sections for 
           ax25mail-utils and ax25spyd support
         - Updated the Linpac section talking about editing the help, info
           and init.mac files
          

05/16/12 - Updated the gpsd and Xastir sections to support Centos6 as well
           as newer versions of GPSd

04/07/12 - Added an additional appendix section to document my findings in
           patching the Centos5 2.6.18 kernel to properly support RS232 
           based Baycom TNCs
         - Added a URL in Appendix-C to easily browse kernel commits by file
           and not by date.  Helpful to see if anything has changed for specific
           drivers, etc
         - Added a link to the Radio.Linux.org.au site
           
04/04/12 - Added some additional AX25 troubleshooting. 
         - More improvements have been made to the packetrig script
         - Had to add the CONFIG_BAYCOM_EPP parameter to custom kernel compiling
           for Centos5

03/31/12 - Updated the soundmodem section a bit and made significant updates
           to the packetrig.sh script to support 300baud HF soundmodem
         - Updated the soundmodem.spec file to support patching in these fixes

03/24/12 - Newer Centos kernels broke the initial udev setup when recognizing the 
           first two serial ports on the US Interface Navigator.  Fixed with
           adding ENV{ID_MM_DEVICE_IGNORE}="1", to the udev rule
         - Updated the RXAMADRM section to reflect the new 0_4 version that's 
           coming that has lots of fixes, etc.
         - Redhat no longer hosts Fedora SRPMs so I updated the impacted URLS
         - Updated Hamlib to 1.2.15

03/18/12 - Updated the kernel compiling section a bit
         - Update the power management section a bit, moved it to PreSetup section
         - the updated the packetrig.sh script to include another attempt to be
           able to disable suspend

03/12/12 - More updates on the RXAMADRM chapter

03/03/12 - Added a fix for missing mheard dir path and added a check in the
           packetrig.sh script

03/02/12 - Updated the rxamadrm program to properly compile and run on Centos6

02/18/12 - Updated the user permissions in /usr/src/redhat to allow for
           non-root RPM building
         - Started working on RXAMADRM for Centos6 but roadblocked for now

02/14/12 - Changed the background to a light grey
         - significantly cleaned up the index, renamed a few sections to be 
           much clearer on their actual content, identified more sections that 
           need Centos6 updates by the beginning of their respective sections

02/12/12 - First public version of the new Centos6 materials pushed out to
           the website

01/29/12 - Added PC speaker patch to the Linpac 0.17pre3 section
         - Added a recommendation to backup the config-x86_64-generic-rhel
           for future uses
         - Updated the pskmeter.py section for Centos6

01/22/12 - Moved away from adding US Interface Navigator support via kernel
           source code changes and I'm not using UDEV tricks
         - Updated the 3rd party repo section a bit

01/15/12 - Stripped out significant sections of legacy, confusing kernel 
           configuration sections
         - Changed the AX25 tools from the Official sources to the F6BVP 
           repo
         - consolidated and removed older ax25 details, related bug reports, 
           etc.
         - Added in some important rpmbuild optimizations to make sure
           the created RPMs are optimized for your hardware.  This is
           very important for x86_64 systems
         - moved the configuration of 3rd party repos to the top of the
           document and not an appendix

12/28/11 - Updating the documentation to now include Centos6 support

11/29/11 - Will be replacing the Linuxnode section for the Unode software as has
           more features, has security fixes, etc.
         - Broke up the AX.25 packet section into a few sections to be more
           modular
11/23/11 - Added missing AX.25 and US Navigator kernel patches to archives
           and better documented them here

11/20/11 - Updated the nrbroadcast file to lower the default weight
           of learned routes

11/13/11 - Added a Soundmodem level tuning URL in the soundmodem section

11/06/11 - Added a Creative Commons license to the doc

10/30/11 - Changed the nrports file to only advertise the node as it seems to
           be bad form to send out multiple routes to the same station

10/22/11 - still tweaking the nrports file to get it right

10/20/11 - added URLs to specific AX25 apps/libs/tools bugs
         - added an additional repo as it might be better than the official
           ax.25 CVS

10/17/11 - some fixes and clarifications for Netrom interfaces
         - updates to the packetrig.sh script to enable ADVAX25 depending 
           on the picked BEACON path
10/15/11 - Added Linuxnode : full Netrom proto system that offers a lot more 
           features
         - Enabled ax25d to support other programs as well
         - revamped the ax25-tools section to work around buggy code in the nrattach.c
           file

09/17/11 - Added my LoTW / eqsl.cc notes to the LoTW section
         - Changed the LOTW chapter name to ARRL Logbook (and Eqsl.cc) logging with Fldigi and other tools

09/04/11 - updated sources for the ax25 tools

08/23/11 - Added Gpredict 0.90 though supporting Centos5 is becoming harder and
           harder

07/04/11 - Added a Serial troubleshooting section, fixed overlapping chapter
           numbers

06/27/11 - Updated the Winlink2k section, better phrasing, formatting, 
           some typos

06/19/11 - Updated soundmodem to 0.16

06/11/11 - Added some recommendations for tuning the Signal browser in Fldigi

06/10/11 - Updated Flrig to 1.1.3CY

06/09/11 - Updated the Fldigi section to reflect a new update to Hamlib 1.2.13.1

05/19/11 - Added Flwrap and configuring Flarq

05/18/11 - Added Flmsg 

05/15/11 - Added an additional URL for SRPMs
         - Update the Flrig section to reflect building Alpha versions

05/14/11 - Updated the Outpost install on Wine

05/01/11 - Added flwkey

04/30/11 - Added flrig
         - Added fixes to other sections for the legacy --vendor
           SPEC attribute

04/24/11 - Added missing setup and configuration info for Linpac

04/20/11 - Updated the 3rd party RPM repo appendix to work around
           an issue with conflicts that priorities doesn't fix

03/27/11 - Added initial DSD docs

03/15/11 - Added a new start to a Winlink2000 section

03/14/11 - Added some URLs in the beginning touching on Packet
           tutorials for both VHF and HF

03/09/11 - Added wxtoimg for APT and WeFAX satellite decoding
         - Added links to 
             - NAVTEX decoding
             - PACTOR-1 / AMTOR decoding

03/06/11 - Updated LOTW tqsllib to 2.2 and TrustedQSL to 1.13

02/12/11 - Added Chirp
         - HTMLized the document - 1st phase
         - Added a patch to Linpac to support many UNPROTO digipeaters

01/24/11 - Added Wine for eventual Outpost 

12/26/10 - Added PskMail

10/30/10 - minor updates

09/29/10 - start to undo the Tk-8.5 damage required by RXADM
         - Added notes to Fldigi to recommend tuning the soundcard with 
           WWV calibration and to also tune the IMD settings
         - Added a TODO section

09/23/10 - Working with W1HJK, upgraded portaudio from the ElRepo 0.19-8 to
           tip of tree 2010-09-23 to try in resolve various FLdigi TX timeout
           errors.  So far, Contestia seems to be working now, etc.

08/30/10 - simplifying the kernel compiling steps using more patches
              all through the kernel-2.6.spec file and patch-99000

08/28/10 - added the removal of the setroubleshoot RPM as it causes issues
           when the daemon isn't running
         - disabled busted gpsd udev rules

08/14/10 - new version of soundmodem that fixes all the spectrum analysis
           hangs.  woohoo!  Cleaned up the soundmodem section a little too

08/01/10 - Added a new gpsd section for support with Xastir and Ambicom 
           GPSes.  Moved the incomplete Delorme section to it.  Updated
           the Xastir section

07/25/10 - added Xlog

07/09/10 - updated all ECST URLs

07/04/10 - cleaned the doc up a little, added QSSTV

06/20/10 - updated the kernel section; 

         - added mention of the US navigator kernel changes

05/08/10 - added comments about fldigi contesting, upgraded to fldigi 3.20.11

02/17/10 - added WSPR support

12/27/09 - added JT65 support`

11/28/09 - added new kernel steps

11/15/09 - added new Latitude aumix / kmix numbers; pskmeter numbers

10/23/09 - added TQSL

09/05/09 - updated to fldigi 3.12.4 from 3.11.5; updated SPEC file to include
           new files and --enable-optimizations flag

08/02/09 - added jnos

07/03/09 - added fldigi
         - Start of this document