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


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

dranch at trinnet dot net
KI6ZHD

10/26/2014


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 but here is the index to give you an idea of what it covers today:

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 distrubution.  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 FedoraProject 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/


   aldo    - CW trainer
   demorse - CW decoder from the soundcard (xdemorse)
   dxcc    - CLI based callSign lookup
   qrq     - CW trainer
   unixcw  - dir listing of various CW training tools


   Other interesting Linux HAM software - some is covered in this document
     and is shown with a '*', other software is really old, etc.
   -----------------------------------------------------------------------
   fldigi * GUI app to support CW, PSK31, RTTY, 
   gMFSK -  GUI app to support CW, PSK31, RTTY, etc
   gpsk   - Gnome app for PSK
   kpsk   - KDE app for PSK
   grig   - radio controller via hamlib
   hamlib * master library to control various radios
   ibp    * find HF beacons on the right bands at the right time
   linpsk - PSK31/RTTY app
   linpac * Nice Linux NCURSES-based packet terminal and simple BBS software
   lpsk   - PSK31/RTTY (ncurses and GTK+) - part of xpsk
   node   * Linux Packet node software
   unode  * Linux Packet node software
   qle    - 404
   qsstv  * receive analog SSTV and FAXes
   splat  - coverage analysis tool (web versions already active)
   ssbd   - audio capture and network transmission support
   svxlink - voice synthesizer for suporting repeaters, etc for echolink
   thebridge - used for echolink
   tqslib    - digital signatures for ARRL LOTW QSLs
   tunak2    - 

   wxapt     - console app to decode and save NOAA and METEOR satellites
   xconvers  - IRC like client using the Internet or packet radio
   xdemorse  - console based CW decoding app
   xdx       - DX cluster communications for DX notification
               (there is also native TELNET access as well via the Internet)
   xfhell    - "fuzzy" digital communication mode known as Hellschreiber
   xlog      - logging tool with hamlib support
   xpsk31    - PSK31/RTTY (ncurses and GTK+) - part of lpsk
   xwota     - similar to a dx cluster lookup system
   xwxapt    - GTK+ app to decode and save NOAA and METEOR satellites
   
   fbb       - packet Bulletin board system - xd704j-src.tgz

   Wow.. check this software out:  http://www.dxatlas.com/

   hamcap    - graphical DX propogation prediction tool (cool!)
   cwskimmer - graphical wide-band decoder of CW across MANY frequencies
   
   LinGT     - a GNOME2 port of LinKT. LinKT is a KDE Packet Radio (AX25) 
               Terminal written by Jochen, DG6VJ 



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:

      chown -R USERNAME 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 done'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, maually 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 RPMforge RPM to enable the repository:

          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 RPMforge repo file

               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


             Download the proper RPM for your distribution version and computer architechure:

               http://repoforge.org/use/

             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


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

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

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

                     rpm --import http://packages.atrpms.net/RPM-GPG-KEY.atrpms

                     
                     Centos6 - Create the file /etc/yum.repos.d/atrpms.repo
                     --
                     [atrpms]
                     name=Fedora Core $releasever - $basearch - ATrpms
                     baseurl=http://dl.atrpms.net/el$releasever-$basearch/atrpms/stable
                     gpgkey=http://ATrpms.net/RPM-GPG-KEY.atrpms
                     gpgcheck=1
                     enabled=1
                     priority=9
                     protect = 0
                     --


                 - adobe-linux (for Acrobat and Flash updates)
                   -------------------------------------------
                     http://get.adobe.com/flashplayer/completion/?installer=Flash_Player_11_for_other_Linux_%28YUM%29_64-bit

                     priority=15

   +----------------------------------------------------------------------+
   | 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 updgrade 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 counterfit) 
           that just aren't reliable but FTDI units always work.  I personally
           have a few Prolific units and for the ones that work, they start to
           exibit 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

                 -----

                 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 

                 -----

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


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

        - 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 thast 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 devie 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  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 termina 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 ModermManager taking over your Serial ports

      IMPORTANT!!!

           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 Hayse 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 consisent / 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 you got all that.  If your setup isn't covered here, please see the
ALSA docs at http://alsa.opensrc.org/MultipleCards for full details on how to 
get consistent enumeration.


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


Linux Power Management
----------------------
This is an ugly topic for me as it seems that entire power management systems are
different from distro to distro and they completely change out their solution every 
year!  Classic Linux!  It's madening and the GUIs be it Gnome, KDE, etc. seem to 
override the lower level systems like acpitook, 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
distiles 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 sytem 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 enformcement 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.


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

Default CENTOS kernels for Centos v6, v5, etc do NOT support the AX.25 protocol, 
packet radio interfaces like KISS nor does Centos5/6 support the US Interface 
Navigator USB soundmodem device yet.  They are now supported in the 2.6.35+ 
kernels by yours truely :-) but until then, we still have to either patch the 
kernel to support more than two of the 6 on-board serial ports or do the Udev
config changes as mentioned above.  Since you're reading this section, you
rather recompile the kernel!

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



   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
   
      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 parts first
   yum install kernel-headers kernel-devel



Lets get the SRPMs for the new kernel:
--------------------------------------

   Consider this:
   --------------
      It's worth noting that there are TWO different kernel sources you might 
      choose.  

         Centos/Redhat:
         --------------
         There are the stock Centos kernel sources that are directly based
         from Redhat's kernels.  These are very stable but OLD kernels and
         they might not support all the new hardware out there in the market.

         El Repo:
         --------
         The ELRepo group which is documented elsewhere in this document
         to get newer ALSA sound drivers, etc. also has TWO versions of
         kernels:

            LT : These kernels are significantly newer than the Centos /
                 Redhat kernels but don't use the bleeding edge kernel
                 code that might be available.  They are considered their 
                 "Long Term" supported kernels and are a good option for 
                 people that need a newer kernel (kernel 3.0.88 vs. 
                 2.6.32) but want the highest stability.

            ML:  These kernels use the newest kernel code that's considered
                 stable by the Linux developers.  These kernels will get
                 you support for a lot more new hardware, new fixes (and
                 potentially new bugs).  I personally run these kernels
                 on my new laptop for some USB fixes

            If you choose to use the El Repo kernels, you need to download
            the kernel SRPMs (that don't include the kernel sources) here:

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

              and seperately, download the matching 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/


   # For now, this documentation uses the stock Centos kernel sources.  If
   # you need help with the ElRepo kernels, send me an email



   #Let's get started.  Enter in the SRPM directory:
   cd /usr/src/redhat/SRPMS

   # Start up the "links" text web browser, locate the newest kernel source
   # RPM (highest version number given), highlight it, and hit "d" to download it.
   # Once downloaded, hit the "q" key to quit: 

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

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


      #for this example, we're going to assume 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-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'ved previously created a custom kernel, make a backup of it's config
   just in case:

           cp /usr/src/redhat/SOURCES/config-x86_64-generic-rhel \
           /usr/src/redhat/SOURCES/config-x86_64-generic-ax25-rhel.`date +%m%d%y`


   Now install the SRPM with the following but ignore any errors or warnings about 
     "user mockbuild" in the final stages of the RPM install

      cd /usr/src/redhat/SRPMS/

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


   Let's modify the kernel configuration to add support for the AX.25 protocol, 
   Packet TNC interfaces, and the US Interface Navigator USB device in any Centos 
   kernel:

         - Add the followow lines into 

               Centos6: /usr/src/redhat/SOURCES/config-local

               Centos5: /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 file as 
                 User Specific files go in the generic files instead

          NOTE#2:  Please note that if you're updating to a new kernel and have alreally followed 
                   these instructions, you might not be able to simply restore you last 
                   config-x86_64-generic-rhel as new kernel options might have been enabled
                   in the new kernel that weren't present in the previous one

          NOTE#3:  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.

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

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

         - Next, edit the kernel.spec file:

           - cd /usr/src/redhat/SPECS


           - vi kernel.spec

             - find the line:
                # % define buildid 

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


           Centos6
           -------
           - Move the altered spec file
             mv kernel.spec kernel-ax25-el6.spec





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

   -----------------------------------------------------------------
   - If you DON'T have a US Interfaces Navigator, please skip to the 
     COMPILING step later in this section 
   -----------------------------------------------------------------

   In the above "PreSetup: UDEV based deterministic Serial ports" section, 
   I covered how to create determinstic 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 simplier, 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 configrations, and FSK data. As mentioned 
        above, not all of theser 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 natually 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 termina 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 Hayse 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                                                           |
      +---------------------------------------------------------------------------+

      - 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


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

       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:

         rpmbuild -bb --target noarch --without doc kernel-ax25-el6.spec

              +------------------------------------------------------+
              | Total Build time:                                    |
              |                                                      |
              |   Gateway NV57 laptop - Intel i5-2430 CPU            |
              |     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        |
              |           -                                          |
              |   ElRepo 3.10.2 ml kernel w/o ABI chk: 28m 5s (real) |
              |     or    3.5.2 ml kernel w/o ABI chk: 25m27s (real) |
              +                                                      +
              | 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:                                                  |
            |                                                                  |
            |    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, its stable, etc.  Again,  |
            |    be sure to ONLY use the Install or "rpm -ivh" command.        |
            +------------------------------------------------------------------+

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

            cd /usr/src/redhat/RPMS/

            #Centos kernel code:  Update the kernel version numbers to reflect your new kernel
            #
            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

            

            #Just as an example, here is what I installed using an ElRepo ML kernel
            # as of 8/10/13:
            #
            rpm -ivh kernel-ml-3.10.5-1.ax25.el6.x86_64.rpm kernel-ml-devel-3.10.5-1.ax25.el6.x86_64.rpm
            rpm -Uvh --nodeps --force kernel-ml-headers-3.10.5-1.ax25.el6.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:

               #This version reflects the VE7FET SVN repo as of 8/10/13.  Please see the
               # compiling AX.25 section of this doc on how to get that going
               #
               rpm -ivh --force libax25-1.0.3-109.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 this 
next, source only kernel compiling chapter and get to the last chapter
on installing new kernels


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:

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


Both Centos 6 and Centos 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

       - Make sure the new kernel modules are present

            find /lib/modules//kernel/drivers/net/hamradio/

            for example:
               find /lib/modules/2.6.32-220.7.1.el6.ax25.x86_64/kernel/drivers/net/hamradio/
               --
               baycom_ser_hdx.ko
               baycom_ser_fdx.ko
               mkiss.ko
               yam.ko
               hdlcdrv.ko
               6pack.ko
               bpqether.ko
               baycom_par.ko
               --

   If you're happy with 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:

            /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 build them ourselves but
it's not too hard.  

With that said, there was a bit of fragmentation in this area for some time.
The source packages from the official AX25 tools site on sourceforge.net are:

    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 **
     ---------------------------------------------
     This repository is a third fork of the AX.25 tools with many fixes 
     applied and as of Aug, 2013.  It has also become the recommended version for
     FPAC support 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:

              http://code.google.com/p/linuxax25/

          You can see an update list of patch descriptions here:

              https://code.google.com/p/linuxax25/source/list


     Official release AX.25 Tools:
     -----------------------------
     NOT Recommended
     -----------------------------
     The currently "released" ax25-tools at version 0.10rc2 has many 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 varient):


        - 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 (CVS):
     --------------------------------------
     NOT Recommended
     --------------------------------------
     As part of the "Official" sources, there is a CVS version of the tools
     available at http://www.linux-ax25.org/wiki/CVS which is newer than the 
     officially released code.  It still significantly lags behind the fixes 
     available from the VE7FET and F6BVP versions mentioned below.  A few notes:

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

You can get the SPEC files from the VE7FET archives following the next section's
steps.  If you're going to use VE7FET's spec files, go ahead and skip this next 
section:


      Making your own SPEC files:
      ---------------------------

      If you want to put the spec files together youself with the with the 
      older source code:
      --
      https://fedoraproject.org/wiki/SIGs/AmateurRadio/Packages


      Additional great places to download RPMs and SRPMs if you can't find them
      from the Fedora repo:

         http://www.rpmfind.net/linux/rpm2html/search.php?query=portaudio

         http://ftp.w1nr.net/opensuse/repositories/hamradio/openSUSE_11.1/src/


      Back to the Fedora site, this page is a little funky on how to use it.  In 
      the table, find the "Koji" colum.  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!


  Building up the recommended VE7FET sources:
  -------------------------------------------

  +--------------------------------------------------------------------------+
  | VE7FET has not updated the main download versions of his tar.gz files in |
  | a long time but the SVN repository is up to date but might have less     |
  | testing - Up to you which version you want - I recommend the SVN version |
  +--------------------------------------------------------------------------+

  Getting the SVN version:

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

   svn checkout http://linuxax25.googlecode.com/svn/trunk/ linuxax25-read-only

   #Let's get the package details
   SVNVER="`grep -m 1 -A 1 dir linuxax25-read-only/.svn/entries | grep -v dir`"
   APPSVER="`grep AC_INIT linuxax25-read-only/ax25apps/configure.ac | awk -F', ' '{print $2}'`"
   TOOLSVER="`grep AC_INIT linuxax25-read-only/ax25tools/configure.ac | awk -F', ' '{print $2}'`"
   LIBVER="`grep AC_INIT linuxax25-read-only/libax25/configure.ac | awk -F', ' '{print $2}'`"

   #Let's package things up nicely
   cd linuxax25-read-only

   #ax25apps
   #---------
   cd ax25apps
   ./autogen.sh
   ./configure

   # You now need to update the ax25apps.spec "Release:" and "BuildRoot:" variables
   # to reflect or include the SVN revision.  As of 8/4/2013, that would be "109".  
   #For example:
   #
   #    Release:        109
   #    BuildRoot:      %{_tmppath}/%{name}-1.0.2-%{release}-root-%(%{__id_u} -n)

   if [ ! -f /usr/src/redhat/SPECS/ax25apps.spec ]; then
      cp ax25apps.spec /usr/src/redhat/SPECS
   fi

   cd ..
   mv ax25apps ax25apps-$APPSVER
   tar czvf ../ax25apps-$APPSVER-$SVNVER.tar.gz ax25apps-$APPSVER/*



   #ax25tools
   #---------
   cd ax25tools
   ./autogen.sh
   ./configure

   # You now need to update the ax25apps.spec "Release:" and "BuildRoot:" variables
   # to reflect or include the SVN revision.  As of 8/4/2013, that would be "109".  
   #For example:
   #
   #    Release:        109
   #    BuildRoot:      %{_tmppath}/%{name}-1.0.2-%{release}-root-%(%{__id_u} -n)

   if [ ! -f /usr/src/redhat/SPECS/ax25tools.spec ]; then
      cp ax25tools.spec /usr/src/redhat/SPECS
   fi

   cd ..
   mv ax25tools ax25tools-$TOOLSVER
   tar czvf ../ax25tools-$TOOLSVER-$SVNVER.tar.gz ax25tools-$TOOLSVER/*


   #libax25
   #---------
   cd libax25
   ./autogen.sh
   ./configure

   # You now need to update the ax25apps.spec "Release:" and "BuildRoot:" variables
   # to reflect or include the SVN revision.  As of 8/4/2013, that would be "109".  
   #For example:
   #
   #    Release:        109
   #    BuildRoot:      %{_tmppath}/%{name}-1.0.2-%{release}-root-%(%{__id_u} -n)

   if [ ! -f /usr/src/redhat/SPECS/libax25.spec ]; then
      cp libax25ax25.spec /usr/src/redhat/SPECS
   fi

   cd ..
   mv libax25 libax25-$LIBVER
   tar czvf ../libax25-$LIBVER-$SVNVER.tar.gz libax25-$LIBVER/*

   #Now clean up after ourselves
   #---------
   cd ..
   rm -Rf linuxax25-read-only

   #Now skip to the next section

  #-------------------------------------------------------------------------------
  #-------------------------------------------------------------------------------

  Alternatively, you can get and use the older, mainline AX25 code (NOT recommended)

   #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


Regardless of which VE7FET version of code you get, next, there are a few more changes to make:

  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 thiese 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 RPMe with glibc conflict consideration



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:
        cd /usr/src/redhat/SPECS
        rpmbuild -bb --target=x86_64 libax25.spec
        #
        #Install it:
        cd /usr/src/redhat/RPMS/x86_64

        +-----------------------------------------------------------------------------------------------------------------+
        | Important:                                                                                                      |
        |            When you install this newer set of libs, they WILL conflict                                          |
        |            with Centos's stock AX.25 libraries found in Glibc.  This                                            |
        |            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 install                                        |
        |                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                                            |
        |                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.                                                                            |
        |                                                                                                                 |
        |                   http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/yum-ax25-upgrade-workaround.sh |
        |                                                                                                                 |
        |                Once run, the script will then RE-INSTALL the conflict                                           |
        |                libax25-devel package.  Your system will then be up to                                           |
        |                date.                                                                                            |
        +-----------------------------------------------------------------------------------------------------------------+


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

        #The SVN version of the VE7FET  - for example, the 109 version
        rpm -ivh --force libax25-1.0.3-109.x86_64.rpm libax25-devel-1.0.3-109.x86_64.rpm

          --- or ---

        #The standard VE7FET verion
        rpm -ivh --force libax25-1.0.3-1.el6.x86_64.rpm libax25-devel-1.0.3-1.el6.x86_64.rpm


   - ax25-apps
     ---------
        #compiles without any other RPMs dependencies
        #
        #Compile it:
        cd /usr/src/redhat/SPECS
        rpmbuild -bb --target=x86_64 ax25apps.spec
        #
        #Install it:
        cd /usr/src/redhat/RPMS/x86_64

        #The SVN version of the VE7FET  - for example, the 109 version
        rpm -Uvh ax25apps-1.0.2-109.x86_64.rpm

          --- or ---

        #The standard VE7FET verion
        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
        rpmbuild -bb --target=x86_64 ax25tools.spec
        #
        #Install it:
        cd /usr/src/redhat/RPMS/x86_64

        #The SVN version of the VE7FET  - for example, the 109 version
        rpm -Uvh ax25tools-1.0.2-109.x86_64.rpm

          --- or ---

        #The standard VE7FET verion
        rpm -Uvh ax25tools-1.0.2-1.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 --                                                    |
|                                                                              |
| 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.                               |
+------------------------------------------------------------------------------+

  #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


+-----------------------------------------------------------------------+
| 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 offical AX25 tools are very 
     VERY old (the F6BVP code has this already fixed):

       - goto 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 http://www.linux-ax25.org/wiki/CVS which 
         should be the ancient 0.10RC2 into /tmp/

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

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

              #ifdef  notdef
                      if (!startiface(dev, hp))
                              return 1;
              #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 soundsystem


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?


  Read more here:

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


   #Getting started with Packet radio
      http://www.qbjnet.com/packet.html

   #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

   #More good details on Packet
      http://www.vectorbd.com/bfd/packet/index.html



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


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

The AMPR network is an overlay TCP/IP network that runs over the Internet using the 
Class-A 44.xx.xx.xx address range to interconnect other amateur radio systems.  
Though initially used with packet radio system using TCP/IP to rarely interconnect
computers, it's now uses your exising Internet connection to link both link systems
to the Internet and remote HAM stations.  Common AMPR uses today are to support
sending amateur-radio centric SMTP (email) traffic, linking HSMM-HAM (10Mb/s+ wifi 
based systems), access to BBSes like JNOS & FBB, access to 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 reachabilty
    --
    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.sysnet.ucsd.edu).

    Internet access:
    --
    The AMPR system is completely available TO and FROM the Internet via the 
    above mentioned amprgw.sysnet.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

               !!!!!!!!!
               IMPORTANT:   As such, once an AMPR tunnel is up between your 
               !!!!!!!!!    machine and the gateway, you MUST run a firewall 
                            to block any network attacks coming in from the
                            Internet via this new tunnel.
   
  Remote Endpoint Advertisements
  ------------------------------
    - The learning of remote stations to connect to is done via two mechanisms today:

       encap.txt - This is a flat file that contains the AMPR IP address of a 
                   given remote station and the public IP address to tunnel to 
                   it.  This file is downloadable from the Internet via an FTP 
                   server and is automatically broadcasted to a specified email 
                   address every day.  It's via this file that people create a
                   full mesh of AMPR IPIP tunnels

       rip44 - Based upon the classic distance-vector routing protocol from years
               past, the use of this dynamic routing protocol is gaining popularity
               since the update lag of the encap.txt file doesn't work well with
               people who have dynamic Internet IP addresses.


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

Once you have someone who can send you traffic, you'll need a packet sniffer on your 
linux machine like "tcpdump" or wireshark to capture traffic off your Internet 
connetion ideally before any specific network firewalls you might have installed.
                  

  
Let's get started:
------------------

  +-----------------------------------------------------------------+
  | Assumptions:                                                    |
  |                                                                 |
  |    - You tested your ISP connection and you can get IPIP tunnel |
  |      packets to your AMPR Linux machine.                        |
  |                                                                 |
  |    - We are only configuring IPIP tunnels for now, AXUDP base   |
  |      tunnels might be added at a later date                     |
  |                                                                 |
  |    -                                                            |
  +----------------------------------------------------------------+

  1) The first thing you need to do is get ahold of your local AMPR IP Coordinatator 
     for your country and region.  Go to the following URL and click on your specific 
     country and then region:

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

     Alternatively, you can also view the list at http://www.ampr.org/oldsite/amprnets.txt
     Send an email address off to your coordinator giving your CALLSIGN, how many
     IP addresses you want (you can ask for just one, a few or with a compelling 
     reason.. even a subnet), and what you'd like for the DNS hostname(s) to resolve 
     to.  In my setup, I have:

        44.4.10.39 - ki6zhd-5.ampr.org
        44.4.10.40 - ki6zhd.ampr.org
        44.4.10.41 - ki6zhd-dgw.ampr.org


   2) It's important to sign up for the AMPR "44Net" email list to understand 
      what's going on in the network, ask questions, etc.  It's very low volume:

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

       
   3) Once you have AMPR IP addresses, it's time to sign up to get access to 
      the encap.txt file.  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.

   4) Setup your new AMPR IPs - This can be done one of two ways.. via the
      brand new portal.ampr.org website or the original email-based "robot".

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

              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:
           ----
            - Goto DNS --> Manage to create a new DNS entry for your AMPR IP subnet(s)

            - Click on "Add new Record" and using my setup as an example:

                Hostname: ki6zhd
                Type:     A
                Extra:    <leave blank>
                TTL:      24

              Click on "Add" 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.


        Email "robot" method: 
        ---------------------
          If you'd like to use the email robot method of setting up / changing
          your AMPR gateway and subnets, read this for now until I get a chance
          to document this:

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

          NOTE:  Using the robots method is probably the best way to automate any
                 required changes for Dynamic IP address users




Work in progress
----------------

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

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

   modprobe ipip
http://rob0.nodns4.us/Linux-ipip-tunnels





Split this section into TWO peices

trinity3:
must apply ip_masq_vpn patch to 2.2.26 kernels
   - enable generic masq support as a MODULE (monilithic won't work)
   - configure monolitic kernel support for protocol 4

./ipfwd --syslog --masq 192.168.0.20 4


hampacket2:
/sbin/ifconfig tunl0 44.4.10.40 netmask 255.255.255.255 mtu 512 up
/sbin/route add -net 44.0.0.0 netmask 255.0.0.0 tunl0 gw 169.228.66.251

#IPIP and AXIP VPN sync for amprgw.sysnet.ucsd.edu
-A INPUT -p 4 -s 169.228.66.251/32 -j ACCEPT
-A INPUT -p 44 -s 169.228.66.251/32 -j ACCEPT

#KG6BAJ
/sbin/ip route replace 44.2.14.1 via 50.79.156.221 dev tunl0 proto static onlink table 1



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

#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 directly /proc/net/ip_masquerade ?
 
 No, it is not feasible, because directly modifying masq entries will
 break the established connection.
--

--
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 for 
the masqueraded connections it is difficult to play such games. It seems only 
one timeout needs to be separated, the TCP EST timeout. The reason that such 
support is not in 2.2 is because nobody wants to touch the user 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, hardware TNCs like Kantronics KPC, AEA PK232, etc. 
   were required to interface a radio to a computer to support the AX.25 packet 
   protocol (and other protcols like RTTY, Amtor, etc).  Advancements in computer
   CPUs allowed the ability to use an inexpensive soundard to connect to the radio
   and use software to do all TNC-like functionality.

   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 at all.  Fortunately, things have changed and now there are options.

      HF Packet
      ---------
      It's generally understood that soundmodem's 300baud HF performance is POOR 
      and though some patches have been submitted to the linuxhams Vger list, I 
      personally didn't notice any real improvement.  It does work rather well
      on VHF but it it's known to have limitations on decoding weaker signals,
      mistuned TNCs, etc.  One of strongest emerging programs to replace it is
      Direwolf.  Its been commented that Direwolf's HF 300baud performance is
      significantly better and it's VHF performance is excellent.

      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/octive filtering
           - multiple off-frequency decoders
                                                                             
      I'm actively researching these and will add one of them to this   
      documentation set.  Until then, here is what I know:

         - DireWolf for Linux - http://home.comcast.net/~wb2osz/site/          
             - Written in C and runs on Linux (x86 and ARM) and on Windows
             - Originally designed to support VHF packet for APRS but also     
               has been reported to support 300baud HF packet too              
             - Directly supports APRStt for sending APRS objects from any
               DTMF enabled radio
             - Native IGATE support for relaying APRS packets to the Internet
             - Directly supports digipeating and beaconing directly, intended  
               for APRS use                                                    
             - Directly supports AGW API so no need for Ldsped                 
             - Supports 1bit and multi-bit recovery options                    
             - Does not support off frequency decodes - designed for VHF       
               packet but properly tuned HF works ok today                     
             - In the back of the UserGuide.pdf (included in the archive),     
               it has a table of various decode rates from diff. software      
               TNCs and it shows Linux's Soundmodem decode rate being POOR.    
             - Approaches 990 decoded packets from WA8LMF's Track 2 -          
               http://wa8lmf.net/TNCtest/index.htm                             
             - See the User-Guide.pdf included in the DireWolf archive         
                                                                               
         - JavAX25 for all OSes - https://github.com/sivantoledo/javAX25      
             - Written in Java                                                 
             - Supports KISS and the AGWPE API                                 
             - Supports double pass flat and 6db/octive 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 Ldsped                 
             - KISS over TCP for APRX support
             - more details coming

         - Soundmodem for Linux - 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 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 low decode rates for    
               1200BAUD                                                        
             - 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 300B HF packet to support frequency     
               hunting and multiple simultaneous off-frequency decoders -      
               later adapted to support VHF (FM) packet                        
             - Reported to run under WINE                                      
             - 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                             
                                                                               
         - 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    


6.a - Compiling Direwolf


[ Recommended! ]

   +------------------------------------------------------------------+
   | Work in progress:                                                |
   |                                                                  |
   |   - Direwolf now supports PulseAudio via the "default" ALSA      |
   |     device.  It's important to assign the PulseAudio sink        |
   |     via the pavucontrol program                                  |
   |                                                                  |
   |   - The direwolf.conf is not stored in /etc                      |
   |                                                                  |
   +------------------------------------------------------------------+
   
As of 2/27/13, Direwolf is at version 1.0-Beta1 and is available at 

   http://home.comcast.net/~wb2osz/site/ 

and specifically:

   http://home.comcast.net/~wb2osz/Version%201.0/direwolf-1.0-src.zip

     and for those of you interested in the Raspberry Pi version, check out:

       http://home.comcast.net/~wb2osz/Version%201.0/Raspberry-Pi-APRS.pdf


So let's get started:

  # Download the source
  cd /usr/src/redhat/SOURCES
  wget -O direwolf-0.8-src.zip http://home.comcast.net/~wb2osz/Version%200.8/direwolf-0.8-src.zip 

  # Need to create a SPEC file for this

  cd /usr/src/redhat/BUILD
  unzip ../SOURCES/direwolf-0.8-src.zip

  make -f Makefile.linux


6.b - Compiling Soundmodem


[ NOT Recommended ]

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

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 stich the two SPEC files together.  

   
   Get the soundmodem sources here:

      cd /usr/src/redhat/SOURCES
      wget -O soundmodem-0.18.tar.gz \
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 |
   |            a patch posted from IZ6RDB to the                        |
   |            linux-hams@vger.kernel.org list on 3/2/2012 which        |
   |            supposedly significantly improves 300 BAUD operations.   |
   |            See 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


7. - Initial AX.25 setup system settings

The configuration of the Linux system's AX25 isn't very difficult once you
understand all the different peices but 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 to a Kenwood
D710 radio that has a built-in KISS TNC on serial device /dev/ttyUSB0

   +-----------------------------------------------------------------------------+
   | NOTE:  my TrinityOS "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 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                                                        |
   +-----------------------------------------------------------------------------+

- edit or create the file: /etc/ax25/axports

   #name callsign speed paclen window description
   #change "N0CALL-8" to your callsign
   d710 KI6ZHD 9600 128 2 Kenwood D710 TNC at 1200baud

This above file does the following:

   - create a destination packet device called "d710"

   - uses the callsign KI6ZHD for all identifying packets - you MUST
     change this to use your own callsign

   - It opens the serial port at 9600 baud

   - this creates an MTU of 128 bytes which is smaller than usual 
     but will reduce retries if you have marginal links

   - The value of 2 allows two unACKed packets to be outstanding at any
     one time - this is similar to the TCP sliding window concept

   - The remaining text is only a comment
         

    +------------------------------------------------------------------------------+
    | 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 subtile, the specific "KI6ZHD" callsign and SSID (no SSID     |
    |    specified means -0) used here does the corrilation 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.
    +------------------------------------------------------------------------------+


8. - Soundmodem - Configuring the soundcard based TNC


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


  - 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 freqency 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 subtile, the specific "KI6ZHD" callsign and SSID (no SSID     |
    |    specified means -0) used here does the corrilation 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               |
  +---------------------------------------------------------------------------------+


8a. - Soundmodem - Setting the right audio levels


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


   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 Lattitude 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 Amplifer                  - 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 Amplifer                  - 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:
   ----
   Next, this part is stupid but you CANNOT use soundmodemconfig's
   diagnostics while soundmodem is running so make sure soundmodem is
   NOT running


   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:

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


8b. - Soundmodem - Running the daemon with other AX.25 services for a functional system


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

   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 MTU user here is 256.  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 coorilates 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 beloe


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


8c. - Soundmodem Troubleshooting - Fixing issues in running Soundmodem


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.


9. - AX.25 Packet programs - Bringing up the other useful packet applications and daemons


As part of the ax25-apps package, there are several basic programs to make 
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 conenction tool similar to TELNET for
             TCP/IP.  Supports a basic interface as well as a
             'talk' style split screen.  Comes from the ax25-apps
             RPM.  Works well though Linpac is even nicer

Say you're in Silicon Valley trying to connect to K6SNY-1.  To do so, you you 
would enter:


    call f6a K6SNY-1

      - axcall is the program

      - f6a is the AX.25 device
           - in my examples, f6a would be for a Soundmodem-based TNC connected 
             to my Kenwood TH-F6A HT or 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 seperate doc:        |
    |                                                                                              |
    |   http://www.trinityos.com/HAM/CentosDigitalModes/misc/145.050-netrom-and-tcpip-connects.txt |
    +----------------------------------------------------------------------------------------------+


A GOOD connection to K6SNY-1 according to axlisten would show:

   #This is a connection request
   fm KI6ZHD-8 to K6SNY-1 ctl SABM+

   #This is a completed connection
   fm K6SNY-1 to KI6ZHD-8 ctl UA-   

   #This is a transmit of the "?" character  (the trailing . is a terminator)
   fm KI6ZHD-8 to K6SNY-1 ctl I00^ pid=F0(Text) len 2 0000  ?.   

   #This is a connection keepalive
   fm KI6ZHD-8 to K6SNY-1 ctl RR0+

   #This is a disconnect request
   fm KI6ZHD-8 to K6SNY-1 ctl DISC+

   #This is a disconnect confirmation
   fm K6SNY-1 to KI6ZHD-8 ctl DM-



A BAD connection according to axlisten would show:


[root@hampacket sbin]# axlisten
axconfig: port APRS not active
sm[29369]: snd_pcm_start in iotxstart: Broken pipe f6a: fm KI6ZHD-8 to W6XSC-2
ctl DISC+

    Broken pipes like this one for "f6a" reflect OLD versions of soundmodem
    and you need to upgrade it



As you've seen, you can make basic, outgoing connections but Linux AX.25 can do SO much 
more using tools from the ax25-suite as well as 3rd party tools.  For example:

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


   #Log and track users you system hears
   /usr/bin/mheardd

   #beacon - Announce your presence on a given frequency
   beacon -d BEACON -t 10 f6a "Welcome the new HAM to AX.25.. still working on it"



   To monitor all of the received packets as well as ones you sent, 
   there are two KEY 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 

      Make sure it DOESN'T say "axconfig: port f6a 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
   ------------------------------------------------------------
             mheard


  ---------------
  AX.25 Messaging
  ---------------



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


10. - Advanced AX.25 configuration, Netrom, Node services, and Troubleshooting


10a. - ax25spyd - Next generation packet monitoring daemon


Ax25spyd is very much like the "listen" program that comes with ax25-apps where it 
acts like a sniffer on your AX.25 interfaces but it has two key differences:

   - It's broken into two pieces:

        ax25spyd - Runs as root and provides network socket connections to 
                   other clients.  This allows other programs that required
                   being run as ROOT to now run as individual users (more 
                   secure)
                 - It also can detect transit packet messages and send them 
                   to a SMTP host.  
                 - Can capture all traffic on a per-callsign basis and
                   put it in /var/lib/ax25/ax25spyd/call1->call

        ax25spy  - A client to ax25spyd that can
                 - display the decoded AX.25 packets much like "listen" can
                 - Can display packets similar to a DX-cluster display
                 - Just show I, UI, IP, show unique QSOs, 


Debian has a patched for the ax25spyd code that's more modern than
the official version ( http://linkt.de/ax25spyd/ ) and it works with modern 
Linux kernels and libraries!

   cd /usr/src/redhat/SOURCES
   wget http://linkt.de/ax25spyd/ax25spyd-0.23.tar.gz

   #Get the patch files from the Debian sources
   wget http://ftp.de.debian.org/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

     NOTE:
     -----
     I have seen a strange transient error where the build will FAIL with:
     --
       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)
    --

    * If you try building the RPM several times back to back, it will eventually
    * succeed.  Dunno why and it's still happening as of 10/16/12!  Maybe an 
    * issue with Automake??


    # Now go ahead and install it
    rpm -ivh /usr/src/redhat/RPMS/x86_64/ax25spyd-0.23-8.1.el6.x86_64.rpm

    #for 32bit systems
    rpmbuild -bb --target=i686 ax25spyd.spec
    rpm -ivh /usr/src/redhat/RPMS/i686/ax25spyd-0.23-8.1.el6.i686.rpm



   If you aren't going to build things via the SPEC file, follow this:
   -------------------------------------------------------------------
   cd /usr/usr/redhat/BUILD
   tar xzvf ../SOURCES/ax25spyd_0.23.orig.tar.gz
   gunzip ../SOURCES/ax25spyd_0.23-8.diff.gz
   patch -p0 < ax25spyd_0.23-8.diff
   ./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 
       comfigure and make and things worked fine



Ok, now with things installed, just run src/ax25spyd as root for now:

  NOTE: You can invoke "ax25spyd -s" which will create unique files in 
        /var/lib/ax25/ax25spyd\ for per-callsign detail


Please note that 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 puposes

         1. advertize 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-5.

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

--
# /etc/ax25/nrports
#
# The format of this file is:
#
# name callsign alias paclen description
#
netrom	KI6ZHD-5	SCLARA	235 	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-advertized

  - 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
  (disscused 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 immeadiately
 -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 seperate 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


A node program allows remote users to connect to your machine and then 
initiate connections from your machine on to other machines.  This is
superior to digipeating as each hop can do per-link retries vs. with
digipeating, the souce has to do retries all the way through the path.
This specific issue is very error-prone.

There are at least five Node programs out there for Linux that I know of.  These
are listed in general order of simple to more complex:


  - 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.  
                Recently Resurrected and now getting active updates

  - Linuxnode - [ Not Recommended ]
                Also called 'node', this 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 but it also allow running
                of preconfigured Linux commands, etc.  Very powerful.  It works 
                but previously had KNOWN security issues.  It's unclear if those 
                security issues have been resolved.

  - Awznode   - [ Not Recommended ]
                A fork of the original Linuxnode that added several major 
                features but was abandoned.  See below for supported commands.

  -  Unode    - [ Not Recommended ]
                A fork of the previous last available version of UroNode 1.x software 
                available at: https://github.com/kd1zd/Unode/tarball/master
                - Never actively maintained and now abandoned

  - FPAC      - Part node, part ROSE protocol daemon, part packet switch.  I haven't
                used this program yet but I plan on trying it in the future!
                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 thatn Netrom, etc.  Supported via the Linux's flexd
                daemon, Xnet, and other packages.
                 
                
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 like 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 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



Anyway, for this document, we're going to setup Uronode.  To get the software, 
get it directly from Freecode but then it needs to be cleaned up a bit:

  # Get the newest sources and patches
  #
  cd /usr/src/redhat/SOURCES
  wget ftp://ftp.n1uro.net/packet/uronode-2.1.tar.gz
  wget -r -l1 --no-parent -nd -A uronode* www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/


  # Let's get the SPEC file for this:
  #
  wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/uronode.spec


  So what's in the patches?  

         a) the configure script is an interactive ncurses script and not a configure 
            script that an automated sysmte would expect.  One patch changes that

         b) The sources assume an older AX.25 library name so another patch resolves
            that


   #Ok, time to build it:

     #for 64bit systems
     rpmbuild -bb --target=x86_64 uronode.spec
     rpm -Uvh /usr/src/redhat/RPMS/x86_64/uronode-2.1-1.x86_64.rpm
  
    #for 32bit systems
    rpmbuild -bb --target=x86_64 uronode.specc
    rpm -ivh /usr/src/redhat/RPMS/i686/uronode-2.1-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


Configuring UroNode
-----------------

   /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 aliass 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-callsing 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 recommentation:     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-specfic 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 funtional
       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 
                 ipserial, 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/inetd.conf that associates TCP connections to daemons but this file is 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 SCLARA node to be associated with KI6ZHD-5
to my "d710" AX.25 connection as defined in the /etc/ax25/axports file. See the 
packetrig.sh script for full details.  To support running the Uronode software, 
the second stanza is required:

--
#To allow connections to KI6ZHD-5 from a AX.25 connection
[KI6ZHD-5 VIA d710]
NOCALL * * * * * * L
default * * * * * * - root /usr/sbin/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 corrilates 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.  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 ] - Kept 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 followowing 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.specc
    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

+-------------------------------------------------------------------------------

  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 paramater is an
                      ALIAS to this node (if you set one in 
                      /etc/ax25/nrports and the next one is your 
                      callsigni+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 somthing ELSE in the 
                      /etc/ax25/nrports.  I'm using my configured alisa 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 coorilation:

              axparms -assoc KI6ZHD dranch


  - The symptoms:

    I have determined thast 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 dicussed 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 direcly 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.  The Direwolf soft-tnc natively supports this API 
          though not in KISS mode.

     #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 this program is only available from the developer's website and requires that 
you setup an account on his website first.  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 should be willing to provide the sources to you.  Until then, 
try using the 64bit binaries for use say Centos 6.  If you'd like, I can email
you an RPM 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 .sped file included in the current version of Ldsped 
    (I did send him my .spec file), 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 statuis 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 repetive 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 readible 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 readible.

         http://supercat.nosredna.net/


10g. - AX.25 Packet troubleshooting


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

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 immeadiately 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.255.255.255  Mask:255.0.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.0.0.0
             UP RUNNING NOARP  MTU:235  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.0.0.0
             UP RUNNING NOARP  MTU:235  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.0.0.0
             UP RUNNING NOARP  MTU:235  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


11. - Linpac - Advanced HF/VHF/UHF AX.25 packet terminal and PBBS

Linpac is a great command-line packet termial program using Linux's natice 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 simultaenous 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
The main window where you can switch between SSIDs using the F-keys, see live decodes, etc:
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


  +---------------------------------------------------------------------+
  | There are TWO versions of Linpac available today:                   |
  |                                                                     |
  | Active Branch                                                       |
  | 0.20     - Modern, stable Ncurses UI - Current Recommended release  |
  |                                                                     |
  | Previous Branch                                                     |
  | 0.17pre3 - Old, Ncurses based UI - requires patches to compile,run  |
  |                                                                     |
  | Legacy                                                              |
  | 0.16     - the ncurses based UI - does not compile well on Centos   |
  |                                                                     |
  |                        --------                                     |
  |                                                                     |
  | 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          |
  +---------------------------------------------------------------------+


  --
  08/01/14: Linpac is back in active development and has release a new version

     The following instructions are for the Ncurses based Linpac 0.20 for now
     and in the future, I hope to release a fixed v1.0 version that will allow
     users the choice of the Ncurses UI or a Java UI.  

  --

    cd /usr/src/redhat/SOURCES
    wget -O LinPac-0.20.tar.gz \
https://downloads.sourceforge.net/project/linpac/LinPac/0.20/linpac-0.20.tar.gz


  +------------------------------------------------------------------------------------------------------------+
  | NOTE: Supporting local messaging                                                                           |
  |                                                                                                            |
  |       Linpac can integrate with the axmail-utils package that can be found                                 |
  |       at https://downloads.sourceforge.net/project/ax25mail/ax25mail-utils/0.11/ax25mail-utils-0.11.tar.gz |
  |       axmail-utils package.  Linpac today does does NOT emulate a classic                                  | 
  |       TNC's PBBS simple messaging system.  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.                                                                                            |
  |                                                                                                            |
  |       See the "AX.25 Packet Programs" section for more mailing tool options                                |
  +------------------------------------------------------------------------------------------------------------+


  Next, download the RPM SPEC file at:

    cd /usr/src/redhat/SPECS
    wget -O linpac-0.20.spec \
http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/linpac-0.20.spec


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

  +----------------------------------------------------------------------+
  | NOTE #2:  Issue with the ./configure script                          |
  |                                                                      |
  |         It seems linpac is hardcoded to "listen" and not say         |
  |         finding Debian/Ubuntu's broken naming of axlisten.  You can  |
  |         fix this in src/constants.h or create a symlink              |
  |         pointing the listen binary to axlisten                       |
  |                                                                      |
  +----------------------------------------------------------------------+


  Ok, now compile up the RPM

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

     #for 32bit systems
     rpmbuild -bb --target=i686 linpac-0.20.spec

  And now install it!

     #for 64bit systems
     rpm -ivh /usr/src/redhat/RPMS/x86_64/LinPac-0.20-1.x86_64.rpm


  A few more required steps:

   #To properly suport 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, install ax25mail-utils first




11a. - 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 root      |
               +---------------------------------------------------------------+

             -  Alternatively, you can run Linpac as the "root" user which will 
                put all Linpac configuration files in the /root directory and 
                then spawn a "listen" process can monitor the traffic.  
                This process can 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 
                      start linpac NOT as root, you won't see real-time packet
                      traffic.  Instead, you'll see the error:

                        socket: Operation not permitted


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

          Please 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 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 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 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 right  ax.25 device, etc.               |
           +--------------------------------------------------------------+
      

    Master Configuration
    --------------------

           $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

           ;;I prefer the following look
           ;; type-in window at type, what you send second, and a large 
           ;; monitoring window at the bottom
           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
           ;; To have unique SSIDs for say F1 through F8, try the following.
           ;; Note: F9 is a reserved screen where ALL traffic is UNPROTO:
           mycall@1 KI6ZHD
           mycall@2 KI6ZHD
           mycall@3 KI6ZHD-1
           mycall@4 KI6ZHD-1

           ;DO NOT use the **#***-5 SSID as that's used for the Netrom NODE 
           ; SSID as described in the NetRom section

           ;;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
           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 - 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 need to be 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 reserved port number, the 
           ;; BBS name and it's proper SSID, and additional digi callsigns required 
           ;; 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 
         packetrig.sh 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 and to support for 
         lowercase for the same commands, they must be  aliased to the UPPER-CASE 
         commands in the [linpac user]/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 wouldn'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
         --

    Site-Wide Configuration changes
    -------------------------------

      Menu Prompts
      ------------
       -  I recommend you edit the /usr/local/share/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 
[] - write a Private message to user [optional subject] //SB
[] - 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 - 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 - Mark the message for delete //Disconnect - end the QSO immediately //Echo - send the text back //GETMsg - Reads the messages from BBS //Help - this help //Info - print station info //MHeard - list of heard stations //Name - store your name //Quit - normal end of QSO //Read - send text file //RBin - send binary file //RPrg - send the file using autobin protocol //RTt - determine round trip time //SENDFile [p|b]
[] - This command takes a binary file, splits the file to num_messages parts using 7plus and creates a separate message for each part. //SP
[] - write a Private message to user [optional subject] //SB
[] - write a Bulletin message to everyone [optional subject] //Users - list of connected stations //VERsion - print the version of LinPac //Write - Start writing to the text file (stop with "//W off") //WBin - Start writing to the binary file (stop with "//WBin off") //YPUT - send the file using YAPP protoco -- Email notification of packet messages ------------------------------------- I've added the linpac-check-msgs.sh script to the Compressed archive of hampacket-CentosDigitalModes document set at: http://www.trinityos.com/HAM/hampacket-CentosDigitalModes-032813.tgz [change the date to reflect the newer version] which will send you an email 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. 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 You can find another short Linpac setup doc here (very rare to find Linpac docs). 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 an HF Digital mode program that supports most of the digital 
modes including BPSK31, RTTY, Olivia, CW, etc.  It runs on Linux, Windows,
and Apple OSX.  

Please understand that this is a BIG section and requires lots of dependencies
to get everything in place.   Be patient, follow these steps and it will work!


This is the main window for making QSOs, seeing decodes of other signals, running macros, etc:


NOTE on Logging: ---------------- Though Fldigi supports exporting it's logs to say EQSL directly, it doesn't directly support LOTW yet. Alternatively, 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 webpage 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 Fldig 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 #Getting the version 3.21.25 - change the version number to match the newest # release version available wget -O fldigi-3.21.35.tar.gz http://www.w1hkj.com/downloads/fldigi-3.21.35.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 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 oldeer 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 warnins 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: The old Fldigi 3.20.11 now REQUIRES the obsolete and deprecated fltk 1.1.9 toollike 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 - Depdendencies 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 but this is NORMAL for Centos
      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: things change over time so give Yum a try and maybe they now |
       |     offer fltk-1.3.0 or newer.  If not, follow this next section.  |
       +--------------------------------------------------------------------+

        Centos6 specific:
        -----------------
        #We'll use Fedora16 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

        #install the source SRPM
        rpm -ivh fltk-1.3.0-1.fc16.src.rpm

        #Next, we need to install build dependency RPMs:
        yum install libjpeg-devel


        #Ok... time to compile it
        #

        cd /usr/src/redhat/SPECS
        rpmbuild -bb --target=x86_64 fltk.spec

        #When you run the build 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+Xinerama                                   
        # 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.0-1.el6.x86_64.rpm \
/usr/src/redhat/RPMS/x86_64/fltk-devel-1.3.0-1.el6.x86_64.rpm


        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


   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 Flwifi
  
       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 control a huge amount of 
different radios.  The amount of control depends on several factors suchs 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)


Anyway, lets get going on building Hamlib:

        # First, you need to install some build dependendies (if you don't 
        # already have them):
        #
        yum install libtool


        # Next, we 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, 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



        # 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 1.2.15, get that 
        # version instead and make the specific changes to allow for the newer 
        # version.  You can browse the newest download URLs here:
        #
        #    http://sourceforge.net/projects/hamlib/files/hamlib/

        cd /usr/src/redhat/SOURCES/
        wget -O hamlib-1.2.15.tar.gz http://downloads.sourceforge.net/project/hamlib/hamlib/1.2.15/hamlib-1.2.15.tar.gz 

        # Fixing your own SPEC file (not needed if you use my above spec file):
        #
        # The sources in hamlib 1.2.15 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: 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

        # NOTE2:  Centos5
        #         with 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:        1.2.15

          # 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 pre-#
          Patch2:         hamlib-1.2.11-python2.7.configure.patch

          # Find the following line and either DELETE it or comment it out with a pre-#
          %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


   #Now that they're compiled, time to install them:

   #For Centos6
   #
   cd /usr/src/redhat/RPMS/x86_64
   rpm -Uvh hamlib-1.2.15-1.el6.x86_64.rpm hamlib-c++-1.2.15-1.el6.x86_64.rpm \
hamlib-c++-devel-1.2.15-1.el6.x86_64.rpm hamlib-debuginfo-1.2.15-1.el6.x86_64.rpm \
hamlib-devel-1.2.15-1.el6.x86_64.rpm hamlib-doc-1.2.15-1.el6.x86_64.rpm \
hamlib-perl-1.2.15-1.el6.x86_64.rpm hamlib-python-1.2.15-1.el6.x86_64.rpm \
hamlib-tcl-1.2.15-1.el6.x86_64.rpm


   #For Centos5
   cd /usr/src/redhat/RPMS/i686
   rpm -Uvh hamlib*


    ?LEGACY - problably safe to ignore? -- confirm what Flwifi is
    -------------------------------------------------------------
        - Flwifi 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 - Depdendencies 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 - needed for proper audio routing and levels 
      # from Pulse to Fldigi
      yum install pavucontrol



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

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

          #Centos5 specific:
          rpm -Uvh /usr/src/redhat/RPMS/i686/fldigi-3.20.21-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 Flrigit 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 does'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.08 - change the version number to match the newest 
   # release version available
   wget http://www.w1hkj.com/downloads/flrig/flrig-1.3.08.bin.tgz


   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



   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 guidlines 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 3.12.5 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.2.6-1.el6.x86_64.rpm

   #Centos5 specific
     rpmbuild -bb --target=i686 flrig.spec
     rpm -Uvh /usr/src/redhat/RPMS/i686/flrig-1.1.3CY-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 termina 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


The following example covers configuring FLdigi with a Yaesu FT-950 and a 
US Interface Navigator USB soundmodem / serial port box:

       1. Set the FT-950 to it's highest DATA sound out:

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

       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 integreation with Flrig 
               via the XML-RPC option for use with Flrig

             - HAMlib: This extensive library will most likely support more radios, 
                       rotators, etc. thatn Flrig but it won't give you the same 
                       level of rig feedback for things like S-meters, GUIs for
                       controling various volumes, etc.


             - If you're going to be using Flrig, do NOT configure the "Hardware 
               PTT", "RigCAT", "Hamlib", or "Memmap" options but under XML-RPC,
               checkmark the "Use XML-RPC program" and that's it.


             - Hamlib: If your radio isn't supported in Flrig or you just want
               to use Hamlib, click on Configiure --> 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 sperate serial port PTT
                     - use RTS
                     - dev/ttyUSI_PTT

              Finish -->

         
       4. The main 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 shold 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 shold 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 FieldDay docs:

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


15. - Other Fldigi Releated 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 yout 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 guidlines 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 yout 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 guidlines 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 equivelent 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 yout 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 guidlines 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
callsing 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 yout 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 guidlines 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 automate all this,
do the following:

   cd /usr/src/archive
   mkdir Flamp
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Flamp/update-flamp-code.sh

   mkdir Fldigi
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Flamp/update-fldigi-code.sh

   mkdir Flmsg
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/archive/Flamp/update-flmsg-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 going into each directory, running the 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. - 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 
   PSKmail 0.5.4
   Oracle/Sun Java 7 v67



Dependencies:
-------------
   Java (JRE or Java Runtime Envinronment)

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

      cd /tmp

      #64bit version
      wget http://javadl.sun.com/webapps/download/AutoDL?BundleId=95115

      #32bit version
      wget http://javadl.sun.com/webapps/download/AutoDL?BundleId=95113



      #Now look at the text of the above command to decipher the actual version being downloaded
      mv "AutoDL?BundleId=95115" jre-7u67-linux-x64.rpm

      - As root, run
          - rpm -i jre-7u67-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
              rm /etc/alternatives/java
              ln -s /usr/java/jre1.7.0_67/bin/java /etc/alternatives/java

          - Make sure the other Java links are in place

              ls -la /usr/java/

              # Make sure that both "default" and "lastest" 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
            
 


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


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


So, lets get started.  As of November 2013, the current versions of code were:

         http://sourceforge.net/projects/trustedqsl/files/TrustedQSL/
         --
         TrustedQSL : 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.0/tqsl-2.0.tgz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Ftrustedqsl%2Ffiles%2FTrustedQSL%2Fv2.0%2F&ts=1385574296&use_mirror=softlayer-ams
       

   - Next, we need to install some dependencies:

       #From EPEL - this archive will also install "bakefile" and "python-empy" on Centos6 machines
       #
       yum install curl libcurl-devel openssl openssl-devel expat expat-devel wxGTK-devel zlib zlib-devel


       #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 diffierent 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
                  guide 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 from the 
     ARRL ONE MONTH before my original certificate expired.  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.  To be clear:

      ** LOTW certificates are only used to validate QSLs. They are not specifically 
      ** tied to any callsign.  As such, if a certificate expires, gets lost, etc.,
      ** it will have NO bearing on previous/future QSL credit for your callsign, etc.

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

      

Btw, all of ARRL's documention might be nice and dandy but it might not be all 
that clear how to SUBMIT LOGS to say LoTW and Eqsl.cc!  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 
submittion 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. - QSL Service - Tips on dealing with paper QSL cards send via bureaus


After having various QSOs on the radio be it digitla contacts like PSK, RTTY, or 
phone contacts, you might start getting some QSO cards in the mail!  Though 
considered as old school, it's still pretty cool to receive these.  It's always
best to reciprocate on sending a QSL card back but that's another discussion.

The other thing that you might not be aware of is the incoming QSL requests on 
LOTW and even eQSL.  It's best to get that setup as soon as you get on HF to honor their 
requests.

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

Obviously, you have some time to get your envelopes to your local bureau so you can
eventually receive those QSL cards but you probably will want to start working on
it!  


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

  +-----------------------------------------------+
  | TBD: Add in Fllog compiling and configuration |
  |                                               |
  |      Fldigi's logging support is built in and |
  |      is already available when you install    |
  |      Fldigi                                   |
  +-----------------------------------------------+



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
   - Interogate 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 highlevel (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.


19a. - GPSd - GPS enabled location for Xastir, GPS time, etc


If you have an external GPS receiver and want to use it with Xaster (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


   Ok, so it's all intalled 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 - Compile 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'a 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: One of the long standing MAP subsystems that was provided by 
           the USGS was recently shutdown, effectively rendering Xastir 
           without any maps!  Fortunately, one of my Elmers, Jerry 
           Dunmire, KA6HLD submitted patches to support OpenStreetMaps 
           into Xastir.  This means any releast after v1.9.8 should work.

  NOTE #2: 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".  Unforunately, when
           I enabled that, Xastir would no longer send it's own 
           ACKs!   Stay tuned on this one!


 - Requirements for Xaster: A huge laundry list of items unforunately..

    - tkimg :: image manipulation for the TCL lanuage

        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

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

          # NOT Required - Xastir works fine without this package
          #  ISSUE - 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
          yum install geos
          yum install giflib unixODBC netcdf gdal gdal-devel
          yum install libgeotiff libgeotiff-devel

          yum install ImageMagick ImageMagick-devel
          yum install festival pcre-devel proj-devel shapelib-devel db4-devel



        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


          - #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
            yum install ImageMagick ImageMagick-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 fasion:

            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
            #       perls, 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)
       ------------------------------------------------------------------
       ------------------------------------------------------------------
   
   ---------------------------------------------------
   - Now let's finally get started on compiling Xastir
   ---------------------------------------------------

   You still with me?  Ready to download and install Xastir?!  

   Xastir comes in two forms:  

       - Released code : usually very stable but can be old

       - CVS code: up to date but has a small chance of having bugs


   To get the released code, goto:

      http://sourceforge.net/projects/xastir/files/latest/download?source=files


   For this documentation, we're going to get the newest CVS code:

          #xastir's native SRPM from the source code almost works!
          cd /usr/src/redhat/SOURCES

          #When prompted for a password, just hit the ENTER key
          cvs -d:pserver:anonymous@xastir.cvs.sourceforge.net:/cvsroot/xastir login 
 
          cvs -d:pserver:anonymous@xastir.cvs.sourceforge.net:/cvsroot/xastir co xastir

            # If you've downloaded the Xastir CVS code before, it will only download
            # whatever has changed


          #Now let's prep it to be like a SRPM
          #
          cp /usr/src/redhat/SOURCES/xastir/xastir.spec.in /usr/src/redhat/SPECS/xastir.spec

          #Please update the directory version to best closely match the last main release
          #  shown at http://sourceforge.net/project/showfiles.php?group_id=45562
          #
          #   In this example, the last offifial release was 2.0.4 so I'm naming this one 2.0.5CVS
          #   and at the bottom of the descripion field, I add the following line to show WHAT
          #   date the CVS code was pulled:
          #
          #        CVS ver: 10/27/13


          # Next, let's prepare an archive file to be used with the SPEC file
          #
          mv /usr/src/redhat/SOURCES/xastir /usr/src/redhat/SOURCES/xastir-2.0.5CVS
          tar czvf /usr/src/redhat/SOURCES/xastir-2.0.5CVS.tgz xastir-2.0.5CVS/*
          rm -Rf /usr/src/redhat/SOURCES/xastir-2.0.5CVS

          # Next, edit the /usr/src/redhat/SPECS/xastir.spec file to have the 
          # following lines or just download the updated SPEC file from here:
          #
          # http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/xastir.spec

             Name      : xastir
             Version   : 2.0.5CVS
             # Icon    : src/xastir.xpm
             Source    : http://prdownloads.sourceforge.net/xastir/xastir-2.0.5CVS.tgz
             %{_prefix}/lib/xastir

             BuildRequires : tk, tkimg, lesstif, libXp, libXp-devel
             BuildRequires : geos, giflib, unixODBC, netcdf, gdal, gdal-devel
             BuildRequires : ImageMagick, ImageMagick-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, 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


                
          Now build it:

          Centos 6
          --------
          #For Centos6 users with x86_64
          rpmbuild -bb --target=x86_64 xastir.spec


          Centos 5
          --------
          #For Centos5 users with i686
          rpmbuild -bb --target=i686 xastir.spec



          Here is what I see on my system:

            -------------------------------
            xastir 2.0.5 has been configured to use the following
            options and external libraries:                      

            MINIMUM OPTIONS:
              ShapeLib (Vector maps) ................. : yes

            RECOMMENDED OPTIONS:
              GraphicsMagick/ImageMagick (Raster maps) : yes (ImageMagick)
              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
              GDAL/OGR (Obtuse map formats) .......... : yes
              GPSMan/gpsmanshp (GPS downloads) ....... : yes


          #And install it!



          #For everyone... install it!
          #
          # Centos6
          rpm -ivh /usr/src/redhat/RPMS/x86_64/xastir-2.0.5CVS-1.x86_64.rpm

          # Centos5
          rpm -Uvh /usr/src/redhat/RPMS/i686/xastir-2.0.5CVS-1.i686.rpm


       ************************************************************************
       ** Critically IMPORTANT:                                              **
       **                                                                    **
       **   One more step as xastir requires root privs to run which is      **
       **   unfortunate for security reasons but it's a well known issue.    **
       **   This will be automatically done if you compile Xastir as the     **
       **   "root" user, but if you do this as a non-root user, you need     **
       **   to issue the following command after installing the RPM:         **
       **                                                                    **
       **                chmod 4755 `which xastir`                           **
       **                                                                    **
       ************************************************************************


19b1. - Xastir - Configuring and running the APRS tool


I've used Xasir 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 freqency 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 GPS location, put it in
     |       |
     |       |              KI6ZHD's QTH GPS coordinates (Delorme PN40)
     |       |
     |       |                              Lat:   37 degrees 20.613N 
     |       |                              Long: 121 degrees 59.986W
     |       |
     |       |              These values will be overwritten if you later
     |       |              enable a GPS unit.  It is worth mentionin that
     |       |              if your unit is going to be stationary (a house), 
     |       |              the common GPS error information will show your
     |       |              house MOVING!  Ha.. so static settings might be
     |       |              better!  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
     |       |                - I the left hand NAV, you'll see the chain-
     |       |                  link icon.  Right-click that and "Copy link
     |       |                  location.  For me it shows:
     |       |                  
     |       |                  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 the value:
     |       |                    "37.343535,-121.999908"  That's the WGS84 Decimal 
     |       |                    degrees value.  Use the following URL to translate 
     |       |                    it to other formats:
     |       |                      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
     |       |
     |       |            - 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
     |       |            - 

   Now, go to
     |
   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 for the maps!   Goto:

    Map
     |
     +--> Map Chooser
             |
             +--> Online / OSM_tiled_osmarender.geo


Now go to View --> Incoming data and watch the incoming messages as
things start to map out on the maps!

    - 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


On of my most recent projects was looking to create an APRS client for the Rasbberry 
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 Smartbeaconing, 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) but it's 
       a) A very large install and too heavy weight
       b) Requires Xwindows (too heavy weight)

  - DIGI_NED - Extremely powerful APRS digipeater that natively supports GPSes but:
       a) hasn't been updated since 2009
       a) it's a port from DOS and it's configuration is very complex (too many features)
       c) doesn't support smarkbeaconing
       d) doesn't have any graphical displays

  - YACC: Runs under Java and I *think* this is also GUI but
       a) very there is very little information out there
       b) I don't want to run a memory hungry JVM on my Rpi

  - KK7DDS - Dan Smith's Original "Dan tracker" - very light weight system that 
             supports GPSes, SmartBeaconing, and runs from the command line but 
       a) only supports KISS TNCs (no native Linux AX.25)
       b) the optional display is via a GTK+ window via Xwindows

  - N7NIX's port of KK7DDS's Dantracker 
       a) adds Linux AX.25 stack support
       b) runs it's own web server to display the detail via any remote JavaScript web page, 
       c) adds IGATE support
       d) APRS messaging, and more


N7NIX's version of dantrack was perfect for my needs and you can see videos of 
the N7NIX and KK7DDS dantrackers in action:

   http://dantracker.tk/tracker.html


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 optimixations 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, download the source:

  cd /usr/src/redhat/SOURCES
  wget http://ham.zmailer.org/oh2mqk/aprx/aprx-2.06.svn514.tar.gz

Now lets extract the 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.

      - 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 stle 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 forground 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


19e. - 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
undertand.  

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 choosen ***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 youself.  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 whould get a 
       nearly immeadiate 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 shoudld 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 shoudld 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 MANATORY

            - 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 immeadiate 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 immeadiately 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 yourt
      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.  Witholding 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 webpage, 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.
    


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 chaning 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 Maindenhead 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.  Specificially, 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 decribed 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:
      --
      synchronised 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: hardwareA

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


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


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 senstitive 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 dependecies 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, it infers 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 forground 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

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

call -bl -me -r f6a 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 controling 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 underdriving
            levels.  PSKmeter for windows seemed to be happy at 59


28. - QSSTV - Digital and Analog Slow Scan TV (SSTV)

This is the main window for the Qsstv Analog SSTV program:



QSSTV is a SSTV (Slow Scan TV) that sends still images either via Digital or
Analog signals.  This is a very nice KDE application using 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 ditial mode, 
it also supports all the major analog SSTV formats like Scottie, HamDRM, etc.


NOTE on different generations of Qsstv with Centos:

   QSSTV (v8.x) has been released that now adds HamDRM digital SSTV support which 
   is compatible with the Windows EasyPal digital SSTV program.  This new version
   includes BSR fix support, HyBrid mode, and more.  This new code requires the 
   Qt 4.8.x framework which it's installation is covered in the Gqrx section.
   These new Qt libraries are NOT compatible with Centos5.

   The previous generation QSSTV (v7.1.x) supports Analog SSTV modes only
   requires is natively supported with Centos6. Centos5 users can upgrade fundamental 
   Qt libraries with third party libs to make it work but it starts getting sketchy 
   and can break your OS if you're not careful.  It's great news that it's technically 
   possible but doing this is NOT for the faint of heart (Centos 5)!  Please see:

            http://users.telenet.be/on4qz/faq.html#Centos57 

   for more details.

==================================================================================


  +-------------------------------------------------------------------------------+
  | IMPORTANT: The top section of this chapter covers QSSTV 8.2.7 for Centos6     |
  |            though this version might have some minor issues for some, give it |
  |            a try.  If anything else, I've had good luck with v8.1.17 which    |
  |            has a few less features.                                           |
  +-------------------------------------------------------------------------------+


  Qsstv 8.1.x, 7.x, and 5.3c are covered later in this section for Centos6 and 
  Centos5.


   Build prerequisites Centos6 users
   ---------------------------------
   To properly build QSSTV 8, you need to install following libraries before hand:

      - fftw-devel (version 3) - Covered in the WSJT and TXAMADRM section)
      - qt-devel               - Qt-4.8 libraries which is Covered in the Gqrx section
      - hamlib-devel           - Covered in the Fldigi section
      - alsa-lib-devel         - Covered in the Soundmodem and Fldigi section
      - jasper and jasper-libs - covered in the TRXAMADRM section



   # 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)
   #
   wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/qsstv-8.spec

   #Now skip ahead to the next section


   # ---------------------------------------
   # If you want to build your own spec file
   # (Not recommended)
   # ---------------------------------------

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



       # Now let's update the spec file to reflect the new code and requirements
       #
       cd /usr/src/redhat/SPECS
       vim qsstv-8.spec
       --
         1. Update the Version to: 8.2.7

         2. Update the License to: GPLv3

         3. Update the Source0 line to:  http://users.telenet.be/on4qz/qsstv_8/downloads/qsstv_%{version}.tar.gz

         4. Delete the previous version's patches

              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 >= 4.8
                BuildRequires:  jasper-devel
                BuildRequires:  jasper-libs

         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 01/30/14
   #
   cd /usr/src/redhat/SOURCES
   wget http://users.telenet.be/on4qz/qsstv/downloads/qsstv_8.2.6.tar.gz

   
Ok!  Time to build and Install it!
----------------------------------

   #Centos6 with x86_64
   cd /usr/src/redhat/SPECS
   rpmbuild -bb --target=x86_64 qsstv-8.spec
   rpm -Uvh /usr/src/redhat/RPMS/x86_64/qsstv-8.2.6-1.el6.x86_64.rpm


# Skip to the next section on how to configure QSSTV 8.x and use it


==================================================================================
This section covers the building of the two generation old QSSTV 5.3c program
(which works very well) for Centos5 users as well as v7.1.7 for Centos6 users
==================================================================================

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 significant low-level changes to Centos5

  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




--------------------------------------------------
Legacy notes - To be removed
--------------------------------------------------

To do once I get Centos6 installed - QSSTV 7.1.2
--
   cd /usr/src/redhat/SPECS
   vim qsstv.spec

   The above provided SPEC file needs two modifications for QSSTV 7.1.2:
    1. Change the "Version:" string to 7.1.2

    2. Change the "Release:" string to 1%

    3. Change the "Source0:" string to qsstv_%{version}.tgz (notice the _ and the .tgz

    4. Change the line:
         BuildRequires:  qt3-devel
           to
         BuildRequires:  gcc-c++ fftw3-devel qt4-devel hamlib-devel alsa-lib

    5. Under the %prep section, change the line to use the "_" char
         %setup -q -n %{name}_%{version}

    6. Under the %build section, comment out the "%configure" line and replace it 
       with "qmake"

        #%configure
        qmake

    7. Also under the %prep section, change the path and file extensions 
       for the icons file
         chmod 0644 src/icons/*.png

    8. Under the changelog section, add the lines:
       * Sun Dec 25 2011 David Ranch  - 7.1.2-1
       - new version


28a. - QSSTV - Configuring it


     Before you start qsstv, 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 8.x and 7.x:
   ---------------------------------------
   Get the Qsstv 7.1 example templates

         cd $HOME/Qsstv/Templates
         wget -r -l 1 -np -nd http://users.telenet.be/on4qz/qsstv/templates

    Next, run the command "cat /proc/asound/cards" and get the device number
    of your HF soundcard.  For me, it's card "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 onces we created above

      Interfaces: 
           Leave the RX/TX clock frequency alone for now

           Input / Output Audio device:

                Qsstv 7.1 on Centos6: I set it to "pulse" to use the Pulse
                                      Audio system but I could have also hard 
                                      coded it to "hw2,0"

                Qsstv 5.3: set the Audio device (for me) to: /dev/dsp2
      
           Qsstv 5.3: Serial port for PTT (for me): /dev/ttyUSB1


      CAT (for Qsstv 7.1):

          NOTE:  This section is confusing.  The use of Hamlib is only to 
                 key up the radio and nothing more.  No VFO contro, etc.  In
                 addition to that, you can only configure *either* CAT services 
                 to key up the rig *or* enable the PTT serial line to key up the 
                 rig.   If you try to enable both, and click on ok, you'll get a 
                 non-helpful error.  

          NOTE#2: On the FT950, if you use CAT-based PTT while in SSB
                  mode, the rig will only listen to the front facing MIC port!
                  Either you need to leave the rig in PKT mode (not SSB mode) 
                  or you need to use the PTT serial approach to key the rig.  I 
                  do the latter with the US Interface Navigator.

           NOT checked: Enable Hamlib Cat interface

               CAT setup for my radio:  Radio model: FT950
                                        Parity: none
                                        Databits: 8
                                        Baudrate: 38400
                                        Handshake: NONE
                                        Stop bits: 1
                                        Serial Post/Host: /dev/USI_CAT
                                        Handshake: Hardware

           Checked: Enable PTT serial interface
                          Serial port: /dev/USI_PTT

                   !!!!!!!!!!!!!
             NOTE: Investigating: It seems that the QSSTV system needs to be
                   !!!!!!!!!!!!!  configurable of which signal to assert to
                                  bring up PTT.  Similar to say Flrig since:

                                  - If the rig is in SSB mode and I use 
                                    Qsstv's "Serial PTT" option, the rig does
                                    key up and I hear the analog SSTV signal 
                                    but I also hear a solid CW tone on top of
                                    it.  I think this is Qsstv using the 
                                    Navigator's CW winkeyer.

                                  - If the rig is in PKT mode and I use
                                    QSSTV's "Serial PTT" option, the rig does
                                    key up, the analog SSTV signal is there
                                    but there isn't the solid CW tone.

      CW : Text to send to: "(callsign) - qsstv"

   Now click on OK and then close and restart the program


   Centos6 users with Pulse Audio:
   -------------------------------

      - Make sure your antenna is powered up and the radio is running either
        low power or transmitting into a dummy load

      - Start the "PulseAudio Volume Control" (PAVC) 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)
   or lower right (7.1).  You can click on the FFT box and change the view to
   be a water fall display instead.



  - Calibrate the setup on WWV and use the calibrate feature

   ***** Transmit power:
   *****
   ***** QSSTV is a high duty cycle and unless your radio supports full power at
   ***** full duty cycle (rare except on some Icom, Elecraft, etc), you MUST
   ***** set the radio to 85w for a total ~45w output

   After that, follow the Qsstv documentation on how to calibrate your
   Slant / time skew:

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


  Final notes:
  ------------
    - All Qsstv configuration settings are stored in $HOME/.config/ON4QZ and
      all picture files are stored in $HOME/Qsstv



 +--------------------------------------------------------------------------+
 | The rest of this documentation needs to be re-validated with Centos6 and |
 | QSSTV 7.1.x                                                              |
 +--------------------------------------------------------------------------+


  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


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 Mondiael (DRM) - Digital Phone - transmit/receive


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

  --------------------------------
  Ultra Important full-stop notes:
  --------------------------------

  1) Dream ***requires*** a radio with a 20Khz pass-band which either 
      - requires hardware modifications of modern Amateur radio HF rigs  
      - use a panadapter or SDR (Flex, RTL, Softrock, etc)

      --------------------------------------------------------------------------
      * If you can't get a FULL 20Khz passband, you can't decode broadcast DRM *
      --------------------------------------------------------------------------

  2) This software is NOT compatible with WSPR without extensive chrooting.  
     Installing this WILL break your WSPR install.  Ask me how I know!

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



DRM or Digital Radio Mondale is a new digital broadcast system for use for
SWR, HD digital voice/data, etc.   The most common use of DRM like 
technology in HAM radio is EzPal which uses HAM-DRM for it's digital SSTV.


  NOTE: some Linux specific DRM building instructions

       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


  

DRM requires a few specific packages:

   Please see the DRM build pages for full details:

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



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



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 Mondiael 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 seperately.
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:                                                                    |
  |       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 #2:                                                                 |
  |                                                                          |
  |   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 jpg 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 dound 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 backgroun 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 amoung 
      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 consistant

    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:



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

       http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/resize-jpg-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 ou 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 unkeys,
                   you need to set this field to RTS or DTS and click on the "Save CFG"
                   button a few times to ket 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 unsual 
         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 popup 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 upgradig 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 Windwos 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 - Outlook like Packet messaging program via Wine


In my local ARES/RACES group, the county uses the graphical Packet Radio application 
for Microsoft Windows called Outpost.  It looks similar to older versions of Microsoft 
Outlook and gives a very easy way for users to poll many different types of mailboxes
across a lot of different local and remote hardware.  

   http://www.outpostpm.org/
Here is an example of the main Outpost window with various messages in the inbox



In addition to supporting TNCs in command mode, it also supports KISS mode, and even 
AGW/PE socket access.  For now, I will document how things work using a Kenwood 
D710 TNC in COMMAND mode.
  

  Before we install Outpost, we need to configure Wine's serial ports.  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 "aliaed" 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 - Older Wine Serial port issue workaround:
  ---------------------------------------------------
  With older Wine 1.2, you needed to use a work around to fix 
  a long-standing issue with wine:


     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 
  has a unique version that comes with a set of PACFORMS HTML forms built in.  
  You can find this specific version here:

     1. don't be the root user

     2. cd /tmp

     2. Goto the following URL and get the newest software

           http://www.scc-ares-races.org/packet.html#Software


        #Previously, it was v48/Pacfordm 3.8, and version v21 before that
        
        In this example, I downloaded Outpost version v280c042 and PacRelease 3.9.0
        this this developer calls "Install 62":

          wget http://www.scc-ares-races.org/packet/installer/sccsetup62pub.exe 


   *******************************************************
   ** NOTE:   It's important that when you run Wine,    **
   **         you do NOT run it while being root!       **
   *******************************************************

     #Install the Outpost program via:

        #being logged in as yourself and NOT root..
        #
        wine sccsetup62pub.exe

          - All files will be installed into $USER/.wine/

          - Accept ALL of the installer's defaults 


     #Notes on the installation:

       Centos6 - I did see the following errors but nothing was fatal:
         --
         wine: cannot find L"C:\\windows\\system32\\wineboot.exe"
         err:process:start_wineboot failed to start wineboot, err 2
         fixme:process:SetProcessDEPPolicy (1): stub
         fixme:process:SetProcessDEPPolicy (1): stub
         fixme:win:DisableProcessWindowsGhosting : stub
         fixme:msg:ChangeWindowMessageFilter c046 00000001
         fixme:msg:ChangeWindowMessageFilter c046 00000001
         fixme:msg:ChangeWindowMessageFilter c046 00000001
         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:ReadStyleSheet skipping optional destination
         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,0x33fa50), partially implemented.
         fixme:ole:OLEPictureImpl_SaveAsFile (0x126a28)->(0x1315e0, 0, (nil)), hacked stub.
         fixme:ole:OLEPictureImpl_FindConnectionPoint no connection point for {33ad4ed2-6699-11cf-b70c-00aa0060d393}
         --

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

  Outpost 2.7.0 under Wine v1.4 Notes:
  ------------------------------------
    - Everything seems to work fine without the serproxy feature
    - The only strange display issue is that the "OpDirect" and "OpDirect MCS" 
      windows don't render properly


  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.  
  If not, troubleshoot that issue first.  Now, we have to make a few Wine config changes:

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


  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/

     #NOTE to Wine 1.2 users: 
     #   Run the serproxy program as shown above



     Start up Outpost
     ----------------
     # Note #1: Make sure you are NOT the root user
     #
     # Note #2: If you're using the packetrig.sh script to run various packet stuff
     #          on your machine, you must shut it down first

     wine Outpost.exe



  Hopefully Outpost started for you and now you need to configure it.  The
  following assumes MY callsign, setup, etc. so please make the required changes 
  to reflect your 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.  Now you have a choice of how you want to
  have Outpost interact with your TNC: Command mode or AGW/PE.   

     - "Command mode" is where Outpost will issue commands to your TNC much like you would
       do via a terminal program like Minicom, Hyperterminal, etc.  Everything is in clear
       text.  The supported TNCs are: D710, KPC3, KPC3+, MFJ127x. TNC2, and Timewave

     - "AGW/PE mode" is where Outpost will communicate to a middleware API program that controls
       your hardware or software-TNC.  In a previous section, I documented how to setup LDSPED
       to offer this interface.  Other programs like Direwolf also offer this interface though
       not when configured to be in KISS mode



     # Kenwood D710 users using "Command mode"
     ----------------------------------------
      - Make sure the Linux AX25 system is not running (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"

          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


     # AGW/PE API users using LDSPED or DireWolf
     ------------------------------------------
      - 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


        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)



Using Outpost and PacForms:

  * If you're using the packetrig.sh script to run various packet stuff
    on your machine, you must shut it down first

  - Start up Outpost 

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

      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:  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 uploaed these settings to other, non-similar radios thus allowing
you to syncronize 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:

    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

It also needs the following:

   yum install libxml2-python 


And one more RPM that we have to build ourselves:

   cd /usr/src/archive/Chirp

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

   #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


Now, 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 syncronization


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 numbres 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 accomodate 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 satelitte images


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

WXtoIMG is a Multi-platform APT and WeFAX satelitte 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 WinMOR 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 allows any POP3 email client
      to interface to Winlink2k
        http://paclink-unix.sourceforge.net/

    - Airmail is a Windows-only program that's similar to Outpost that 
      is it's own email reader and supports Winlink 2k

    - Outpost for Windows also supports Winlink 2000 interfacing

    - JNOS2 now has B2F message compatibility with Winlink2k. It's not 
      a client per se but a relaying system

    - Linux-RMS-Gateway 
          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


39a. - Quick notes on how to get started with Winlink


Quick and dirty notes on using Winlink until I truely complete this section:

  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:

     NOTE: connected via TELNET over the Internet is no longer supported

      - 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 blacklisted 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 whitelist. You can also sign up for 
         Webmail access by clicking the Webmail tab on 
         http://www.winlink.org. You can also control your whitelist 
         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. - 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
    * GFSK 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 (descriminator 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


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: ----- 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 -------- 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: Visability 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 Satelittes", 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 (all types of radios) in a very long time.  Classic radios that use analog 
circuits to create super hetrodyne radios (local oscilators, mixers, filters, 
detectors, etc.), to de/modulate the signals.  An SDR is a completely different 
device where it uses direct conversion to takes the DIRECT antenna input, 
pre-amplify the broadband signal and then digitize it with very fast, broad 
banded analog to digital converters (DAC).  At this point, all demodulation
is done using complex math in the computer itself and it then can be played
via the computer's audio system, etc.  

This section is broken into a few peices:

  Section A - Quick is a simplier but powerful python based program for IQ-based 
              SDRs like Softrock, etc.

  Section B - 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 C - LinRad is a very powerful SDR applications for Linux based on
              GnuRadio


42a. - Quisk - Software Defined Radio (SDR) receiver


+------------------------------------+
| This section is a work in progress |
|   - It works fine but isn't        |
|     packaged just yet              |
+------------------------------------+

Guisk is a Python based application that fully supports 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!

This is the main window that shows the maximum bandwidth being captured:


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

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

  LinRad, GqRx, etc.


Hardware:
---------
Though minimial, 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 omiting
    other programs that were previously installed with other programs as described in
    this doc.  Please see the Quisk documentation for learning
    more of the dependies 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:

         alsa-info --stdout | grep -A 12 "Audio Input"

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


42b. - 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. Since GnuRadio is required by many other SDR 
applications, we need to get it installed first.

  NOTE:  This is a fairly complex process to get all the required dependencies
         in place.  Even with them in place, compiling GnuRadio takes a long time
         even on very fast machines


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

   #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 UBS, 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?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fqwt%2Ffiles%2Fqwt%2F5.2.3%2F&ts=1386176576&use_mirror=softlayer-dal

  
       # 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'
   #
   #        Unforunately 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 versionos 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


GnuRadio
--------
Ok!  Let's get down to getting and building GnuRadio.  It should be noted that 
the GnuRadio package is HUGE and I've founf 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 was 3.7.5 but there are issues with 
   # it and old packages that are found in Centos 6.5:
   #
   #  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
   #
   cd /usr/src/redhat/SOURCES
   wget http://gnuradio.org/releases/gnuradio/gnuradio-3.7.4.tar.gz


   # Now let's get a spec file for gnuradio:
   #
   # You can either use my GnuRadio spec file (recommended):
   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.patch


    #  ---- OR ----

      # 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


      Using the Fedora SPEC file:   If you go this approach, there are several items you need to do:

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


          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.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 funcionality,
           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 *** on my dual core Intel i5 2430M @ 2.4ghz 
   #         laptop with 4GB of RAM and a 5400RPM HD.  Seems this build is very hard
   #         disk I/O bound so a faster hard drive (7200rpm) or a SSD might help A LOT!  
   #
   #   Do **NOT** run this "rpmbuild" command as the root user
   #   
   rpmbuild -bb --target=x86_64 gnuradio.spec   


   #And now install it as root
   #
   #  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're going to have to uninstall those other programs FIRST:
   #
   #    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
   #
   # Then install your new gnuradio RPMs and then rebuild and install the rebuilt RPMs second!

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


42c. - RTL-SDR - Supporting applications for RTL2838 USB SDR dongle


Ok, GnuRadio is installed (finally)!  For my uses, I want 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:

  RTL2832 + E4000 : The first units found to work very well used the Elonics E4000 
                    tuner.  They can range between 54-2200 MHz with a gap over 1100-1250 MHz.
                    Like most I/Q devices say 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 units are 
                    getting harder to find on say Ebay, etc. but they are still 
                    available.

  RTL2832 + R820T : The next 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.

There is a very nice intro write-up here:

   http://superkuh.com/rtlsdr.html


If some of you are 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/


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 
elsewhere in this document so there isn't any issue here.  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.


   NOTE on software compiling order: 
   ---------------------------------
     The RTL-SDR Application packge must be installed FIRST and then
     you can compile/install the GR-OSMOSDR hardware software.  If you don't 
     do this, the GR-OSMO software will not build


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

  #Next, download the newest version of the RTL-SDR software
  #
  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}

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


42d. - GR-OSMOSDR - Supporting the RTL2838+E4000 USB SDR dongle


The OSMO-SDR software is the package that supports the lowlevel RTL SDR hardware.
Since we need that, let's get started.  A few notes first...

   NOTE:   1. Please note that the newest versions of the OSMO-SDR software *requires* 
              GNuRadio 3.7.0+ to build.  You must have updated GnuRadio before you try 
              this stage.

           2. The RTL-SDR application package *must* be installed and/or first before 
              this package can be installed

           3. There is an optional package called gr-iqbalance that, if installed
              BEFORE you build gr-osmosdr, will always be included in the gr-osmosdr
              modules.  I haven't installed this a of yet but you might consider it


  Important Note:
  ---------------
   gr-osmosdr exposes a bug in older versions of Cmake and the Boost libraries.
             

  # Download and install the newest GR-OSMO SDR software
  #   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 newer sources
  #
  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.1
  grep -r VERSION_INFO *

  # Write down the GIT commit code with
  cat gr-osmosdr/.git/logs/HEAD

  
  # 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 of the git commit code.  
  #  In my case, I would need to do:
  #
  mv gr-osmosdr gr-osmosdr-0.1.1
  tar civf ../gr-osmosdr-0.1.1-20131208git05d51b53.tar.bz2 gr-osmosdr-0.1.1/*
  cd ..
  rm -Rf gr-osmosdr-git


  
  #Now you have to change 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: 05d51b5340496036b69ef4fbbce6a1983a4b81ba

    2. Update the GIT date:            20131208

    3. Update the Version:             0.1.1

    4. Update the Release to:          1.%{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



  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, 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 above!
  #
  #   Build time: 1min 24 seconds
  #
  rpmbuild -bb --target=x86_64 gr-osmosdr.spec



  # Now install the RPMs
  #
  cd /usr/src/redhat/RPMS
  sudo rpm -Uvh x86_64/gr-osmosdr-0.1.1-1.20131208git05d51b53.el6.x86_64.rpm \
x86_64/gr-osmosdr-devel-0.1.1-1.20131208git05d51b53.el6.x86_64.rpm \
noarch/gr-osmosdr-doc-0.1.1-1.20131208git05d51b53.el6.noarch.rpm



Ok.. one last thing.. and this is strange.  You now need to add your username (and any other
users that will be using the RTL USB dongle to the "rtlsdr" group.  In this example, I'm 
adding myself to this new group.  You'll have to change the username to reflect YOUR
username (and any additional):

   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:

       groups

   # Notice the "rtlsdr" group isn't listed!  To get it working for now, 
   # Use the following command.  You'll have to use this command in every login 
   # for each username you have until you completely log out and back in:

      newgrp rtlsdr


42.e - RTL SDR Testing - Making sure the hardware works and doing UDEV blacklists


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 blacklist 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 blacklist 
   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/blacklist.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]


42.f - Gqrx - An easy to use RTL compatible SDR application


Gqrx is an excellent, easy to use SDR program that can control various SDR hardware
including RTL and FunCube dongles, Ettus Rearch USRP and Osmo SDR hw devices.  It
supports several demodulators for SSB, AM, narrow and wideband FM, CW, various 
configurable filters and it even has a AFSK-1200 packet decoder!  It also supports 
zooming in on both the IQ waterfall and the decoded audio waterfall!
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:


Two important Notes:
--------------------
   1. If you jumped to this section hoping to install Gqrx without much fuss,
      sorry, it's not that simple.  You need to go back to the "42b.gnuradio"
      section above and install **all** of the other required dependencies including:

           boost, cmake (newest version), gr-osmosdr, and rtl-sdr 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!

          You've been warned!


Legacy GQRX code
----------------
   GQRX v2.1 - gqrx v2.1.148 will compile and run on the stock Centos6 qt-4.4 
         libraries available from the main Centos6 repos but there are
         several big bugs in Gqrx 2.1.148 that are fixed in newer versions.

         The GIT repository for Gqrx also has several fixes and improvments 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 minimim versions
         on gnuradio and gr-osmosdr as well.


   Ok, as usually, time to fill some dependencies:

    # Some specific build tools required
    #
    yum install cmake cppunit-devel


Qt-4.8
------

    Ok, let's isntall 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 simultaenouly 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


Gqrx
----

    Ok, on to the Gqrx software!  It should be noted that the releases on the SourceForce
    site are rather old compared to the Git repository.  As such, I recommend to use the
    GIT sources.  

    #  First, let's get a template Gqrx spec file from
    #
    #    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 get the newest sources
    #
    cd /usr/src/redhat/SOURCES
    mkdir gqrx-git
    cd gqrx-git
    git clone https://github.com/csete/gqrx.git gqrx.git

    # Now check out the version - current version as of this writing is 2.3.0
    less grqx.git/news.txt

    # Write down the GIT commit code - For me, it's: 57356c50cc0989c641f83ca3d861d8e7b4671aec
    cat gqrx.git/.git/logs/HEAD

    # 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 of the git commit code.  
    #  In my case, I would need to do:
    mv gqrx.git gqrx-2.3.0
    tar civf /usr/src/redhat/SOURCES/gqrx-2.3.0-20131215git57356c50.tar.bz2 gqrx-2.3.0/*
    cd ..
    rm -Rf gqrx-git


    #Now you have to change a few things in this 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:

         %global git_commit 57356c50cc0989c641f83ca3d861d8e7b4671aec
         %global git_date 20131215

         %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: 
               57356c50cc0989c641f83ca3d861d8e7b4671aec
   
       2. Update the GIT date:            
               20131215

       3. Update the Version:             
               2.3.0

       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:  qt-devel >= 4.7.0

       6. In the %build section, add a new first line that has:
               export QTDIR="/usr/lib64/qt4"
    --


    # Ok, time to build it
    #
    #   NOTE: this takes 2min to build on my dual core i5 2430M @ 2.4ghz with 
    #         4GB of RAM and a 5400RPM HD.  
    #
    #  Do NOT run this as root
    #
    #  Build time: 1 min 49 seconds
    #
    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.3.0-1.20131215git57356c50.el6.x86_64.rpm


    # Ok, it's installed!  To run it, run as a regular user (not root):
    ./gqrx


Skip to the next section on some thoughts on HOW to use Gqrx.


-----------------------------------------------------
Deprecated Section: 
-----------------------------------------------------

   I'm keeping this these notes here for any users that might find it valuable

Older Gqrx version that works with Centos 6.4's 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.g - Using Gqrx


Though Gqrx is one of the easiest SDR receiver programs to use out there for 
any operating system, it does have a few quirks on how to use it.

  - When you first load the program, you need to click on the "power button" icon
    in the upper left hand corner to have it start 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

  - Finally, it's important to calibrate your SDR dongle for proper reception.  The 
    easiest way I've seen to get started is to tune your SDR (assuming an RTL dongle) to
    one of your local NOAA weather stations.  

      - Goto http://www.nws.noaa.gov/nwr/nwrbro.htm and find a local frequency

      - Zoom in on the spectrum in the main waterfall until you can see the strait lines
        when the speaker isn't talking.

      - In the upper right window, click on the "Input Control" tab and increase/decrease
        the "freq. correction" until the receiver is right on frequency


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

  Caveot:  Linrad's user interface was originalally designed via the legacy SVGA graphics
           library and follows NO mondern 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 dependendies:
  #
  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.i - Other SDR Applications for Linux


Here are a few other SDR programs I"m aware of for Linux:

    Ghpsdr or ghpsdr-alex aka "qt-radio"
    --
    A three-module approach to SDRs where there is a receiver module (supports both local 
    hardware or remote hardware via the Internet/TCPIP, a demodulator module, and a local
    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
           - satelitte 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/
    --


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
stations can be other indivual stations, full repeaters, or entire collections of 
repeaters called reflectors!  Please see the next follow on "Using Echolink and 
IRLP via radio and Svxlink/Qtel" section for more details.

The SVXLink is a suite of tools that provides:

   - Echolink (EL) GUI client (GUI)
   - Echolink command line client (Svxlink non-daemon mode)
   - Local voice playback for voice quality testing
   - Local voicemail recording and playback
   - 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 units on Ebay seem to work quite nice but you can 
              also use HAM radio targeted soundcards like US Interface Navigators, 
              Signalinks, but that's generally overkill.

            - Depending on the sound interface you pick, you will need a PTT 
              circuit that connects to a serial port to key up the radio.   This 
              circuit was previously described in the "Soundmodem - Sound-card based 
              AX.25 packet TNC" chapter.  

            - A serial port on your machine to connect to the PTT circuit on 
              the radio

            - More Echolink setups use COS or Carrier Operated Squelch that 
              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
              can be a LOT nicer than using VOX.   To support COS, you might need
              to hack this into your legacy radio (D710 has it built in) and
              you need another serial line 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.  Please
       see the "PreSetup: ALSA determinisitic sound cards" section for more details.



43.a - SVXlink and Qtel - Compiling and packaging the application

Ok, let's get started.   First, let's get and compile the code.   Fortunately for us,
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 2011, November, 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


    # Next, you can download either an official release or the bleeding edge code
    # from the SVN repository.  
    #
    #   Main Releases:
    #        Overall, Svxlink development has ramped back up # and improved to 
    #        the point that I would just recommend the main releases now:
    #
              wget http://downloads.sourceforge.net/project/svxlink/svxlink/13.12/svxlink-13.12.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fsvxlink%2F%3Fsource%3Ddlp&ts=1385918891&use_mirror=softlayer-dal
 
    # or
    #
    #   SVN Trunk releases 
    #
    #  In this example, I'm using the trunk as of 09/27/12 
    #   *********************
    #   * SVN revision 2249 *
    #   *********************
    #
    #  NOTE: I'm naming this new SVN code version 13.12.1.  This roughly follows
    #        the developer's numbering scheme of year.month.release
    #
              wget -O svxlink-13.12.1.tar.gz http://svxlink.svn.sourceforge.net/viewvc/svxlink/trunk/src/?view=tar


    Ok, next, we need the audio prompt files for Svxlink as they aren't t included 
    in the default archive.  Lets get those now:
    #
    cd /usr/src/redhat/SOURCES
    wget http://downloads.sourceforge.net/project/svxlink/sounds/13.12/svxlink-sounds-en_US-heather-16k-13.12.tar.bz2?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fsvxlink%2Ffiles%2Fsounds%2F13.12%2F&ts=1385919162&use_mirror=superb-dca2


    #Now we need to clean things up a bit to make it fit into an expected RPM. 
    #
    #  NOTE: For SVN trunk users, I'm making up a new version number of 13.12.1 
    #        to reflect it's SVN based
    #
    cd /usr/src/redhat/BUILD
    tar xzvf /usr/src/redhat/SOURCES/svxlink-11.11.2-1.tar.gz
    mkdir svxlink-11.11.2
    mv src/* svxlink-13.12.1/
    rmdir src
    rm -f /usr/src/redhat/SOURCES/svxlink-11.11.2*
    tar czvf /usr/src/redhat/SOURCES/svxlink-13.12.1.tar.gz svxlink-13.12.1/
    

The above Fedora based SPEC file uses some package names that's either incompatible 
with Centos6 or reference older version of libraries that need to be updated.  As
such, we will need to update those packages, the version of the code in the RPM, and 
fix a some specific spec file issues.  I recommend you either use my svxlink.spec and 
patch files found here:

    wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/svxlink.spec
    wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/svxlink-sms-patch.diff

  If you use that Spec file, skip the rest of this .spec file editing to then build
  the RPM.

  If you want to manually edit the svxlink.spec file, do the following:

     - To determine the proper library versions, we need to open up the Svxlink 
       archive:

           cd /usr/src/redhat/BUILD
           tar xzvf ../SOURCES/svxlink-13.12.tar.gz
           
           Look at the following files and note down the newest version of the 
           libraries:

                 async/ChangeLog      
                 echolib/ChangeLog    
                 qtel/ChangeLog
                 svxlink/ChangeLog


     - Find the line that starts with:

         %define main_version 11.11.1

    and replace it with

         %define main_version 13.12

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


Next, under the Source0 line, add the line:

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


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

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

    #echolib
    Epoch: 1
    Version: 1.2.0

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

    #qtel
    Epoch: 1
    Version: 1.2.0

    #svxlink-server
    Epoch: 1
    Version: 1.3.0



Next, svxlink does NOT compile properly with parallel compiling so we have to disable that:

        make %{?_smp_mflags}

    and replace it with:

        make 


Next, under the %install section, change the line:

    cp -a en_US-heather %{buildroot}%{_datadir}/svxlink/

      to

    cp -a en_US-heather-16k %{buildroot}%{_datadir}/svxlink/


Next, Svxlink doesn't create the proper user directory for full functionality 
as PulseAUdio needs to write temp files, etc.  Find the line that looks like:

        useradd -r -g daemon -d / -s /sbin/nologin \
        -c "SvxLink Daemon " svxlink

    and change it to:

        adduser -r -g daemon -G audio -m  -s /sbin/nologin -c "SvxLink Daemon" svxlink


Finally, under the "%files -n libasync" and "libasync-devel" sections, delete the lines:

   %{_includedir}/svxlink/SigCAudio*.h


Save all those changes to the svxlink.spec file.  



Now we need to install some dependencies to compike things:

    yum install libsigc++20-devel gsm-devel speex-devel opus opus-devel


Finally, let's build this for a Centos6 machine and install it:

    #Assuming a 64bit build
    rpmbuild -bb --target=x86_64 svxlink.spec


Finally it's time to install all the resulting RPMs:

    cd /usr/src/redhat/RPMS/x86_64
    rpm -Uvh libasync-1.2.0-1.el6.x86_64.rpm echolib-1.2.0-1.el6.x86_64.rpm \
qtel-1.2.0-1.el6.x86_64.rpm svxlink-server-1.3.0-1.el6.x86_64.rpm


    #(OPTIONAL) You can also install the developer libs and debugging packages 
    #           if you'd like too
    #
    rpm -Uvh libasync-devel-1.2.0-1.el6.x86_64.rpm echolib-devel-1.2.0-1.el6.x86_64.rpm \
svxlink-debuginfo-13.12-1.el6.x86_64.rpm


A few other things:

   - There seems to be a bug in the Fedora SPEC file when creating the proper 
     media files for Svxlink.  Lets fix that now:

     mkdir /usr/share/svxlink/sounds
     ln -s /usr/share/svxlink/en_US-heather-16k /usr/share/svxlink/sounds/en_US


43.b - Configuring and testing 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 linec.  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 isoloation 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 determinisitic 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):
         #
         #   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 -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 
        chaning:
 
             #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 propogation 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 uncommend 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 nessisary 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 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 natual 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.  To support that, you would want to change this value 
          to:

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


        - (optional) Support for external DTMF decoding available on some of the 
          above mentioned Isoloation 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 isoliation 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, I use:

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


      NOTE: This should be considered a BUG in the svxlink.spec file
            as this file contains user's Echolink password



  - IMPORTANT: It's beyond the scope of this document to cover the
               Internet networking aspects of getting Echolink traffic
               into your computer.  It might be worth mentioning
               that Echolink 2.x and newer no longer require specific 
               port forwarding but if you try to work remote stations
               that are running 1.x, you will STILL NEED to enable the 
               following port forwards:

                In from the Internet:
                    5198/udp
                    5199/udp
                    5200/tcp


43.c - 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 IMMEADIATLY
   hear the notification sound on your local computer and fairly quickly get an 
   SMS message!
  


43.d - 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 criticial 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 seperate 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 suporting 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 betweem 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              |
          |     initiaized (RTS will still be high ths 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     |
          |     initialzied.  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 Transmittion 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 uninitialize 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 manul 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 recoomended 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.e - 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 v0.13.99.15 (Oct  2 2012) Copyright (C) 2011 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.conf

       Starting logic: SimplexLogic
       Loading module "ModuleHelp" into logic "SimplexLogic"
               Module Help v0.7.0.99.0 starting...          
       Loading module "ModuleParrot" into logic "SimplexLogic"
               Module Parrot v0.7.0.99.0 starting...          
       Loading module "ModuleEchoLink" into logic "SimplexLogic"
               Module EchoLink v0.10.99.1 starting...           
       Loading module "ModuleTclVoiceMail" into logic "SimplexLogic"
               Module Tcl v0.3.0.99.0 starting...                   
       Event handler script successfully loaded.                    
       Connected to APRS server 69.36.224.181 on port 14580
       EchoLink directory status changed to ON                      
       --- EchoLink directory server message: ---                   
       EchoLink Server v2.5.9996                                    
  
       ECHO3: Scottsdale, AZ 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

        - Next, open up the Linux souncard 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 D7109 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 
                    cheapie 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 eariler 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.  
         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

         With that setting, the start-svxlink.sh script

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

         or packetrig.sh script 

            http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/packetrig.sh

         which will restore the right audio when started (along with other things).



43.f - 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 does'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 frequeny 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 
                              annoucement 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 eariler 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 annoucement 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

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.g - 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
   http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/modemtest-reset-serialport.pl


This start-svxlink.sh script will:

   - Verify that the ALSA audio system has the right permissions for the svxlink 
     user to initialize it

   - Start svxlink in a named "screen" session so you can always view the STDOUT
     logging and view remotely

    - If Svxlink exits with an error code, it will run the "modemtest-reset-serialport.pl"
      program to deassert the RTS serial line so the D710 radio won't be constantly 
      be transmitting!  Please note that that this is a slightly modified version of
      the script as provided from the "perl-Device-SerialPort" package to just
      NOT send Hayes "AT" commands to the serial port.
 


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



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 annouce 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 elaborite 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 annouce 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 clin

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




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 publically 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:  Svxlink has slightly different DTMF tones as previously mentioned.
            The following example illustrates systems using the stock Echolink
            DTMF codes:

     NOTE2:  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 
             webpage 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.


     Some common Echolink codes include the following and you can find more 
     examples at http://www.echolink.org/Help/dtmf_functions.htm :

        node-number        - connects to the remote Echolink node number
 
        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 most recently connected Internet-facing 
                             Echolink station.  If there are multiple stations 
                             connected, they 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 confereence 

        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-configred 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 informaiton 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 onlt 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 technolgies

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 lisked 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 chronologic 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 truely 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:


So.. let's get it installed!  As usual, we have some depencendies 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


Next, I'd recommend to install the development version of D-rats as found
in http://dev.d-rats.com/drats_daily/ .  This code is almost always reliable
and has the most features.  For me, I did the following to install this most 
recent release:

   NOTE:  I have not made this an RPM of this package just yet but it's 
          in the plan

   cd /usr/src/redhat/SOURCES
   wget http://dev.d-rats.com/drats_daily/daily-02232012/d-rats-daily-02232012.tar.gz
   cd /usr/src/redhat/BUILD/
   tar xzvf ../SOURCES/d-rats-daily-02232012.tar.gz
   ln -s d-rats-daily-02232012 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 reoccuring 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 colum 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!


50. - Serial port troubleshooting and tools



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:

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

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

      #TO install from the EPEL repo:
      yum install statserial


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


Serial Terminal Programs:
-------------------------

  - Minicom 
    - Solid but older ncurses-based terminal program which interfaces to anything 
      serial.  Includes support for phonebooks, X/Y/Zmodem, scroll back buffering and 
      logging, HW/SW flow control, etc.  

            NOTE: When changing serial ports, BAUD rates, etc., you have to save the 
                  settings, exit the program, and restart minicom for the changes to 
                  take effect

  - Putty
     - Runs on Windows and Linux
     - Supports SSH, TELNET, RLogin, RAW, and Serial 
     - Very feature packed program

  - Cutecom
    - A simple QT4 based terminal program that supports controllable CR vs CRLF for
      newline, setting of different character delay, logging, HW/SW flow control,
      display of HEX output, etc.

  - SyncTERM - tailored for classic BBS systems - active as of Aug 2013
    - Windows, Linux, OSX support using SDL, X11, or NCURSES with hybrid mouse support
      and scrollback support
    - TELNET, Rlogin, SSH, RAW, and serial communications, X/Y/Zmodem support, also 
      supports Rlogin, Atari ATASCII, Commodore PETSCII, ANSI card symbols, ANSI Music, 
      ANSI character pacing, Door support, dialup phone books, 

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

  - picocom
    Light weight terminal program
    http://code.google.com/p/picocom/

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

  - Coolterm 
    - Supports Mac, Win, Linux (minimal support) - displays serial port pin status, 
    - Supports receiving / sending ASCII / HEX

  - EmTec ZOC (commercial) running under Wine

     
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

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:
http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/misc/tmd710_tncsetup.c


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.


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    f6a       2   Fri May 29 11:58:33 -- BEACON: Santa Clara County Digi Milpitas.
K6KP-6     f6a      12   Fri May 29 11:58:09
W6XSC-2    f6a       2   Fri May 29 11:56:06
K6SNY      f6a       5   Fri May 29 11:55:36
W6XSC-5    f6a      84   Fri May 29 11:43:31
KE6AFE-10  f6a       1   Fri May 29 11:01:12
KI6ZHD-8   f6a     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
--

f6a: 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...
   f6a: 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 misconfigured 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 f6a 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 unnessasary 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 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 tonights
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.  Adding support for Centos6 should be proof to
that!  Sheesh!

 - Figure out what ax25spyd isn't reliable in compiling!

 a. Doc Fldigi WWV calibration

 DONE - update packetrig.sh to support per system MTUs
       128 for 144.990
       250 for 145.050


100. - Errata

Page Views since 02/17/14:
Flag Counter
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 signifiacantly 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 multple
           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 caveots 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, specificially 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
         - Consolodated 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 collilated 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 Naviator 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 consise 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 consitent 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 beginngin 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
         - consolodated 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 compiliung 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 supprot 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