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

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

dranch at trinnet dot net
KI6ZHD

11/23/2018.0

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

Index

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

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

1a. - The Build Environment
1b. - Enabling Third Party RPM repositories
1c. - Buying reliable USB to Serial adapters for Linux
1d. - UDEV based deterministic serial port assignments for USB adapters
1e. - Fixing serial port device permissions for non-root users
1f. - Working around the ModemManager taking over your Serial ports
1g. - PreSetup: Deterministic sound cards
1h. - PreSetup: Power management and other stuff etc.
1i. - Enabling core dumps and tuning the ABRT system

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

2.a - Unpacking the kernel sources and applying some configuration change patches
2.b - Enabling AX.25 support into the kernel in one of two ways
2.c - Enabling US Interface Navigator USB support via UDEV (optional)
2.d - Enabling US Interface Navigator USB support via kernel code patches (optional)
2.e - Compile and create the kernel RPM
2.f - Building a kernel from source (no RPM)
2.g - Final checks and booting into the new kernel for AX.25 support

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

3.a - Fetching and preparing the AX25 packages for RPM packaging
3.b - Patching the AX25 code with additional fixes
3.c - Compiling and Installing the new AX25 RPM with GLIBC conflict consideration

4. - Updating Centos's ALSA sound system

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

5a. - What is AMPR and step-1: how to get your own AMPR-based IP address
5b. - Running an AMPR IPIP setup : How to get things running

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

6.a - Soundcards for use with Software-tncs and HF digital modes
6.b - Compiling Direwolf
6.c - Configuring and Tuning Direwolf
6.d - Tuning Direwolf Audio levels

7 - Soundmodem - Compiling, Configuring, and tuning (LEGACY)

7.a - Soundmodem - Configuring the soundcard based TNC
7.b - Soundmodem - Setting the right audio levels
7.c - Soundmodem - Running the daemon with other AX.25 services for a functional system
7.d - Soundmodem Troubleshooting - Fixing issues in running Soundmodem

8. - First time AX.25 setup and bringup

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

9a. - ax25mail-utils- AX.25 messaging tools for used with Linpac

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

10a. - ax25spyd - Next generation packet monitoring daemon
10b. - AX.25 NetROM Routing and connections
10c. - AX.25 Node Services - UroNode
10d. - AX.25 Tunneling over the Internet via AXIP or AXUDP
10e. - LDSPED access to AGW/PE packet API support
10f. - AX.25 traffic monitoring
10g. - AX.25 Packet troubleshooting

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

11a. - Linpac - Compiling and installing the program
11b. - Linpac - Configuring the packet terminal program

12. - Fldigi - Compiling the program for HF digital modes

12a. - Fldigi - Dependencies step #1
12b. - Hamlib for Fldigi (and other apps) - Rig control for your radio
12c. - Fldigi - Dependencies step #2
12d. - Fldigi - Final Compiling

13. - Flrig - Rig control with or without Fldigi

13a. - Flrig - Configure rig control

14. - Fldigi - Configuring the digital mode software

15. - Other Fldigi Related Programs: Flwrap, Flmsg, FLamp, etc.

15a. - Flarq - Error corrected CONNECTED mode communications with Fldigi
15b. - Flmsg - FLdigi program for RX/TX NBEMS forms
15c. - Flwrap - FLdigi plugin for sending binary files
15d. - Flamp - FLdigi program for broadcasting messages to multiple parties
15e. - Flwkey - Winkeyer CW keyer software support
15f. - An easy way to update your various Fl-suite of programs

16. - Advanced Configurations with Fldigi - HF AX.25 packet, email and APRS with Fldigi

16a. - PSKMail with Fldigi - HF email and APRS system used with Fldigi
16b. - NextGen HF packet - Using Fldigi's modern modes with Linux's native AX.25 stack via TCP-KISS

17. - TrustedQSL for Logbook of the World (LOTW) - on-line and offline logging with Fldigi and other tools

17a. - Using TQSL - How to install TrustedQSL certificates and use the application
17b. - Renewing TrustedQSL certificates
17c. - QSL Service - Tips on dealing with paper QSL cards send via bureaus

18. - Logging - Compiling and configuration of Contact loggers

18a. - Fldigi / Fllog - Good full featured logging for the Casual user
18b. - CQRlog - Powerful / full featured contest logging
18c. - Xlog - Alternative QSO Logger with Automatic log uploads to LOTW/EQSL for FLdigi

19. - APRS - Automatic Packet Reporting System

20. - Advanced APRS Usage

20a. - APRS functionality - Commands you can use with APRS to get information about the area around you
20b. - APRS-IS Email - How HAMs can send short Internet SMTP emails back and forth to an APRS station
20c. - APRS-IS Email via Winlink

21. - UI-Chat

21.a. - Configuring and Running UI-Chat

22. - Compiling and Configuring ARDOP and ARIM

22.a. - Compile and Install ARDOP
22.b. - Configure ARDOP
22.c. - Compile and Install ARIM
22.d. - Configure and use ARIM
22.e. - Operate ARIM

23. - FreeDV - Digital voice mode using CODEC2

23a. - Getting FreeDV and it's required components
23b. - Configuring FreeDV

24. - WSPR - HF weak signal beacon

24a. - Configuring WSPR and time management

25. - WSJT - JT65 and other HF / EME weak signal digital modes

26. - JNOS - Full AX25 and TCP/IP enabled packet BBS

27. - PSKMeter - BPSK31 signal quality diagnostic meter and software

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

28a. - QSSTV - Compiling it
28b. - QSSTV - Building older versions
28c. - QSSTV - Configuring and Using Qsstv

29. - GeoID - MaidenHead distance calculator

30. - IBP - International Beacon Project beacon tracker

31. - Dream - Digital Radio Mondiale (DRM) - Digital Phone - transmit/receive

32. - Tuning Dream - DRM

33. - TRXAMADRM - Receiving Digital SSTV

33.a - TRXAMADRM - Transmitting Digital SSTV

34. - LinKT - HF/VHF/UHF packet terminal for Qt

35. - Wine - Running Windows programs within Linux (used for Outpost)

36. - Outpost - Outlook like Packet messaging program via Wine

37. - Chirp - Multi-Radio memory programming tool program

37.a - Thoughts on Chirp and radio memory synchronization

38. - WXTOIMG - Decoding APT and WeFAX images

39. - Winlink 2000 - Sending messages to / from Winlink Email, APRS, and Packet

39.a - Quick notes on how to get started with Winlink and Winlink APRS messaging
39.b - Send a Winlink message via email, APRS, etc
39.c - Receive a Winlink message via APRS messages
39.d - Advanced Winlink commands via APRS

40. - PAT - A Multi-protocol / Multi-platform Winlink client

40.a - Install Google Go
40.b - Install Pat
40.c - Configure Pat
40.d - Operate PAT via CLI using the Internet
40.e - Operate PAT CLI with AX25 Packet
40.f - Operate PAT CLI with ARDOP
40.f - Operate Pat via the web based GUI

41. - Gpredict - Satellite tracking, prediction and graphical mapping tools

42. - SDRs - Software Defined Radio (SDR)

42.a - Picking an SDR - Quick overview of RTL, Airspy, SDRPlay, BladeRF, LimeSDR, etc

42.b - Quisk - Software Defined Radio (SDR) receiver
42.c - GnuRadio - The gold standard for Software Defined Radio software

42.c1 - GnuRadio Dependencies: installing the required sub-applications
42.c2 - Compiling GnuRadio
42.c3 - Installing GnuRadio
42.c4 - GR-IQBAL - Supporting the IQ-Balance GnuRadio module

42.e - RTL Support - Adding the supporting software for the RTL2838 devices

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

42.g - Airspy Support - Adding the supporting software for the AirSpy devices
42.h - SDR-Play Support - Adding the supporting software for the SDR-Play devices
42.i - GR-OSMOSDR - Supporting the RTL dongle and SDR-Play SDR devices
42.j - Gqrx - An easy to use RTL compatible SDR application

42.j1 - Gqrx - Installing final Gqrx dependencies
42.j2 - Gqrx - Compiling Gqrx
42.j3 - Configuring and Using Gqrx
42.j4 - Troubleshooting Gqrx Performance issues

42.k - Linrad - A powerful RTL compatible SDR application
42.l - RTLSDR-Airband: Multi-slice SDR demodulator for up to 8 simultaneous audio streams
42.m - Noting other SDR Applications for Linux (GHPSDR, SDR-J, SDR#)

43 - SVXlink and Qtel - Echolink client and server - HAM Radio and HAM Radio and VoIP over the Internet

43.a - SVXlink and Qtel - Compiling and packaging the application
43.b - Configuring the Svxlink Server
43.c - Svxlink and enabling the Network / Port Forwarding
43.d - Getting Svxlink to send SMS text messages upon connection/disconnection
43.e - Interfacing Svxlink with a Kenwood D710
43.f - Setting the Svxlink audio levels
43.g - Testing the Svxlink system
43.h - Svxlink Startup: Safely Start/Stop Svxlink for local control and logging
43.i - Svxlink Cheatsheet, Using QSO Monitor to pick a free link frequency, bugs, and future features
43.j - Configuring and using Qtel for Echolink

44 - Echolink and IRLP Internet Linking

44.a - Overview of using Echolink and IRLP
44.b - Echolink Validation
44.c - Using Echolink and IRLP

45. - DStar - Digital Voice, Data and other related technologies

45a. - Learning DStar - Setting up a US Trust account and learning about how it all works
44b. - D-rats - Email, IM messaging, and more via Internet, D-Star, packet radio, and more

46. - DSD - Decoding MotoTrbo, P25, ProVoice, NXDN, etc

50. - Serial port troubleshooting and tools

51. - Other useful tools for the Linux HamShack

Appendix A - Centos updating quirks

Appendix B - KI6ZHD Running Packet notes for QTH

Appendix C - Misc other topics Baycom TNCs, etc

Appendix D - Radio Quirks : Using my specific radios

99. - To Do - Things that I need to still do

100. - Errata

A. License - Here come the lawyers

This documentation and scripting set under the umbrella name of "Hampacketizing Centos" is copyrighted to David Ranch and licensed under a Creative Commons Attribution-Noncommercial-NoDerivs 3.0 Unported License. Basically, this means: - The licensor permits others to copy, distribute and transmit only unaltered copies of the work — not derivative works based on it. - If you distribute this document but would like to see additions changes made to it, you need to have those changes made by the author. I'm flexible and happy to help so don't be worried. - The licensor permits others to copy, distribute, display, and perform the work for non-commercial purposes only. If you're looking to use this document or it's scripts in a commercial environment, contact the author (me) for details. http://creativecommons.org/licenses/by-nc-nd/3.0/

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

This documentation notes my ongoing journey to get a fully featured HAMshack running on the Centos Linux distribution. This document originally started out for Centos5 on i386 but I'm actively moving over to Centos6 x86_64. I will be adding in Centos6 specific requirements as I find them. Please understand that some of these notes can be messy at times and some maybe downright confusing. This was because I was keeping detailed notes of compile failures, etc. and some of those notes were helpful or might be helpful to other HAMs. I'll clean them up as I go but if you have any questions, need clarifications, etc., just email me! IMPORTANT: ---------- Following the chapter order of this document can be very important at times as each section of this document filled in the various dependencies needed by the follow-on installed software. There are many other packages you might like to try out as highlighted on the Fedora Project HAM radio section: https://fedoraproject.org/wiki/SIGs/AmateurRadio/Packages +----------------------------------------------------------------------+ | Fedora is Centos.. | | | | If you didn't already know it, Centos 6 uses the same base libraries | | as Fedora 16. Centos 5 uses the same libraries as Fedora 9 | | | +----------------------------------------------------------------------+ Debian also has a list of packages that have been patched and brought under modern Linux kernels especially for AX.25 kernel facing stuff: http://packages.debian.org/squeeze/hamradio/ (stable) and http://packages.debian.org/unstable/hamradio/ (has new packages like Chirp, SDR programs, OpenSuse also has a list of packages as well which can be helpful to get .spec files, etc: http://download.opensuse.org/repositories/hamradio/openSUSE_Factory/src/ and http://download.opensuse.org/repositories/hamradio/openSUSE_Tumbleweed/ For other packages, one of the best HAM radio software for Linux directory pages out there is: http://radio.linux.org.au/ 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 supporting 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 propagation 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 don't want to include debugging objects in all your RPMs, you can remove the -g option such as: optflags: x86_64 -O3 -march=native -m64 Parallel Compiles: To natively support SMP compiling in your system globally (recommended), edit the /etc/rpm/macros.dist file and add the following line. Change the number to reflect the number of threads (number of "processor" lines) shown in the output from "cat /proc/cpuinfo/". On my machine, I have 2 physical cores and 2 hyperthreading cores so I'm going to start with 4 parallel threads. Increasing this number above real / virtual threads can but not always improve compiling performance. You have to experiment to see what your system can support: %_RPM_BUILD_NCPUS 4 Signing: Some packages that want to cryptographically sign the package require an email address (example packages include say Xastir): # Create the file /etc/rpm/macros.gpg and add your name and email address # in this specific format. For my setup, I configured it to be: David Ranch # 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 -- Verification: To check your new RPM build settings, run the command "rpmbuild --showrc" and look for terms like "gpg" and "optflags". Make sure your changes are seen before proceeding!

1.b - PreSetup: Enabling Third Party RPM repositories

Yum and third-party repositories: --------------------------------- When I initially started upgrading Centos5 for the HamShack, I was doing the package search and installation MANUALLY. Though this is fine on small projects as you learn exactly what's required. To do this, I recommend the use of the rpmfind site: http://www.rpmfind.net/linux/rpm2html/search.php Now, after a while, manually doing things gets VERY tedious. Fortunately, yum supports 3rd party repos which will do the search, dependency checks, and installations all for you. To enabled third-party sites to download prebuilt RPMs: Install the Yum-Priorities plugin and enable priorities: 1) Install the Yum priorities system so any new 3rd party RPMs don't override the primary Centos repositories yum install yum-priorities 2) Edit the various stock Centos repos as defined in /etc/yum.repos.d to have correct priorities (THEY WILL VARY..) /etc/yum.repos.d/CentOS-Base.repo -- [base] . . . priority=1 protect=1 [updates] . . . priority=1 protect=1 [extras] . . . priority=2 protect=0 [centosplus] . . . priority=2 protect=0 [contrib] . . . priority=3 protect=0 3) Install the Adobe and RPMforge repo files adobe-linux (for Acrobat and Flash updates) ------------------------------------------- cd /tmp wget https://get.adobe.com/flashplayer/download/?installer=Flash_Player_11.2_for_other_Linux_(YUM)_64-bit&standalone=1 rpm -ivh adobe-release-x86_64-1.0-1.noarch.rpm Edit the Yum repo file at /etc/yum.repos.d/adobe-linux-x86_64.repo priority=4 4) Download the proper RPM for your distribution version and computer architecture: http://repoforge.org/use/ NOTE: It seems that RPMForge is dropping RHEL6 and Centos6 support as there aren't many RPMs available. See the ATrpm repo below as a possible good replacement For Centos6 on a x86_64 machine: -------------------------------- rpm -ivh http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm 5) Enable "priorities" for the RPMforge repository so they don't override the primary Centos repositories. You will also want to enable the Extra and Testing repositories. The Testing repository is needed to install bleeding edge versions of Wine, etc. /etc/yum.repos.d/rpmforge.repo -- [rpmforge] . . . enabled = 1 priority=12 protect = 0 [rpmforge-extras] . . . enabled = 1 priority=14 protect = 0 [rpmforge-testing] . . . enabled = 1 priority=15 protect = 0 -- 5.a) I've found one situation where bleeding edge packages from the "rpmforge-extra" repo would override packages from the main Centos5 updates repo. Regardless of what I would do with the priorities, enabling the "protect" knob, etc., nothing would fix this. Ultimately, the fix I found was to add: 'check_obsoletes=1' to the /etc/yum/pluginconf.d/priorities.conf file. 6) In addition to rpmforge, I also have additional REPOs enabled: - ELREPO (for more up to date kernel modules like ALSA) ----------------------------------------------------- Centos6 - rpm -Uvh http://elrepo.org/elrepo-release-6-4.el6.elrepo.noarch.rpm or Centos5 - http://elrepo.org/elrepo-release-5-3.el5.elrepo.noarch.rpm # Edit /etc/yum.repos.d/epel.repo and add to each stanza [elrepo] . . . priority=7 protect = 0 [elrepo-testing] . . . priority=15 protect = 0 [elrepo-kernel] . . . priority=10 protect = 0 [elrepo-extras] . . . priority=11 protect = 0 - EPEL - Fedora community based repos ----------------------------------- Go to the following URL and install the proper URL for your specific Centos distro. NOTE: It seems they change the URLs from time to time so I'm going to only site the more generic URL: http://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F # Edit /etc/yum.repos.d/epel.repo and add to each stanza [epel] . . . priority=8 protect = 0 # Edit /etc/yum.repos.d/epel-testing.repo and add to each stanza [epel-testing] . . . priority=15 protect = 0 - ATrpms - Fedora community based repos ------------------------------------------------------------------ NOTE: The atrpms repo has silently died off, leaving a gap in the availability of newer RPMs. I'm actively looking for a replacement. was needed for legacy TRXAMADRM v2.x ------------------------------------------------------------------ +----------------------------------------------------------------------+ | Important!! | | ----------- | | - To make sure that when you have multiple Yum repos installed, you | | only use the proper RPMs, add the following line to /etc/yum.conf: | | | | #New check - 032211 | | check_obsoletes=1 | +----------------------------------------------------------------------+ - Check all your Yum priorities with this handy command: sed -n -e "/^\[/h; /priority =/{ G; s/\n/ /; s/ity=/ity = /; p }" /etc/yum.repos.d/.repo | sort -k3n - In addition to the check_obsoletes feature, you might want to consider the following: - By default, Yum will try to upgrade your kernel when new versions are available. We don't want to automatically install new kernels as they don't have AX25, etc. installed. To disable this kernel auto-upgrade behavior, add the following line to /etc/yum.conf: #comment this out when you want to upgrade the kernel exclude=kernel When you DO want to upgrade the kernel, simply edit that file, comment out the exclude line, and run yum again. - Yum will allow you to install many older RPM versions on your system. Kinda silly as you only need one or maybe a few backups just in case you want to revert. This also wastes disk space. To only allow 5 versions, add the following to /etc/yum.conf: installonly_limit = 5

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

- Unless you're running very old hardware, your computer no longer has a native RS232 port built into it. This is a major bummer if you ask me but now people are forced to use USB-based serial ports which brings up two primary issues: 1. Poor USB adapters - Do yourself a favor and ONLY use FTDI-based serial converters! There have been uncountable emails, threads, etc on the Internet about lousy Prolific units (real or counterfeit) that just aren't reliable but FTDI units always work. I personally have a few Prolific units and for the ones that work, they start to exhibit issues when using flow control, heavy data transfers, etc. Here are a few USB cable products that use FTDI chips: ----- 1port - www.cablesunlimited.com - USB-2920 (I have this one) 1port - Keyspan (now TrippLite) - USA19HS 1port - http://www.usconverters.com/index.php?main_page=product_info&cPath=67&products_id=325 1port - https://www.valley-ent.com/store/two-way-radio/programming-cables other 1 port FTDI - https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=ftdi+usb+to+serial ----- 2port - www.USBGear.com - USBG-2X232FTDI for 2port - www.serialstuff.Com - USA-2P-232 for ----- 4port - GearMo - FT4232HL (I haven't tested this one yet) http://www.amazon.com/FT4232HL-Professional-Retention-Certified-Microsoft/dp/B004ETDC8K 4port - DigiKey - USB-COM232-PLUS4 (no enclosure) http://www.digikey.com/product-detail/en/USB-COM232-PLUS4/768-1034-ND/2139296 ----- other multi-ports - https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=ftdi+usb+to+serial ----- NOTE: FTDI-based serial adapters are more expensive than Prolific ones but they work every time. I can't say the same thing about Prolific units. NOTE#2: If your setup is anything like mine, you need multiple serial ports for the following. If so, you really might want to consider a multi-port cable. - HF rig control - VHF rig control - packet TNC - accessories like PSK meter Other USB to serial based adapters beyond Prolific: --------------------------------------------------- - Silicon Labs CP210x based adapters: People have been reporting success NOTE: I have heard that the this chip, by default, always assert DTR when initially plugged in (not initialized). This can be a significant problem which can key up and leave your radio transmitting the whole time until the port is fully initiallized. Not good! One HAM reported that quickly initializing it with the following works around the issue: stty -F /dev/ttyUSB0 -ixon crtscts -hupcl Since I don't have one of these to test, I would generally NOT recommend to uses these if this is all accurate - Logicneed CH340DS1 and CH341: People have been reporting good success with these I don't have one to test

1d. - Deterministic serial port assignments for USB adapters

- Upon reboots, USB glitches, etc., there is the very real potential that your serial device that was on /dev/ttyUSB0 is now on say USB1 or USB2! These assignments can be all over the place and changing your various program's configuration files is a huge pain! To fix this, forget that a given serial device uses the name like /dev/ttyUSB0 every time. Remember, this is UNIX and a device (let alone a serial port) can be named ANYTHING. Why not call a serial adapter "ft857-prog-cable" which is REALLY obvious! Over the years, the solution for creating deterministic USB enumeration has evolved. The first way was via manually created UDEV rules which is very powerful but is rather complicated. In more modern Linux distributions, this has been refined with the /dev/serial/by-id mechanism. Both approaches are covered below: Ok, let's get started. Use "dmesg" to see what's in the buffer. Now plug in your serial device, and run "dmesg" again. The serial device and it's serial number should show up. usb 2-1.1: new full speed USB device using ehci_hcd and address 5 usb 2-1.1: New USB device found, idVendor=0403, idProduct=6001 usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1.1: Product: usb serial converter usb 2-1.1: Manufacturer: FTDI usb 2-1.1: SerialNumber: FTCAWZIA usb 2-1.1: configuration #1 chosen from 1 choice USB Serial support registered for FTDI USB Serial Device ftdi_sio 2-1.1:1.0: FTDI USB Serial Device converter detected usb 2-1.1: Detected FT232BM usb 2-1.1: Number of endpoints 2 usb 2-1.1: Endpoint 1 MaxPacketSize 64 usb 2-1.1: Endpoint 2 MaxPacketSize 64 usb 2-1.1: Setting MaxPacketSize 64 usb 2-1.1: FTDI USB Serial Device converter now attached to ttyUSB0 usbcore: registered new interface driver ftdi_sio ftdi_sio: v1.5.0:USB FTDI Serial Converters Driver The /dev/serial/by-id method: ----------------------------- - Once your serial device is plugged in, try running "ls /dev/serial/by-id". On my machine, I see: -- $ ls -la /dev/serial/by-id total 0 drwxr-xr-x 2 root root 200 Aug 31 17:22 . drwxr-xr-x 4 root root 80 Aug 7 18:50 .. lrwxrwxrwx 1 root root 13 Aug 7 18:50 usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if00-port0 -> ../../ttyUSB2 lrwxrwxrwx 1 root root 13 Aug 7 18:50 usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if01-port0 -> ../../ttyUSB3 lrwxrwxrwx 1 root root 13 Aug 7 18:50 usb-FTDI_Navigator__RS232___Config__00000002-if00-port0 -> ../../ttyUSB6 lrwxrwxrwx 1 root root 13 Aug 7 18:50 usb-FTDI_Navigator__RS232___Config__00000002-if01-port0 -> ../../ttyUSB7 lrwxrwxrwx 1 root root 13 Aug 7 18:50 usb-FTDI_Navigator__WKey___FSK__00000001-if00-port0 -> ../../ttyUSB4 lrwxrwxrwx 1 root root 13 Aug 7 18:50 usb-FTDI_Navigator__WKey___FSK__00000001-if01-port0 -> ../../ttyUSB5 lrwxrwxrwx 1 root root 13 Aug 31 17:22 usb-FTDI_usb_serial_converter_FTCAWZIA-if00-port0 -> ../../ttyUSB8 lrwxrwxrwx 1 root root 13 Aug 7 18:50 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB1 -- As you can see above, I have a BUNCH of serial ports but the one I care about is that second from the bottom one. No need for writing UDEV rules, etc. In whatever program you want to use that specific adapter, regardless of USB enumeration, just specify the serial port as the very long string: /dev/serial/by-id/usb-FTDI_usb_serial_converter_FTCAWZIA-if00-port0 Simple! Now, if your specific application cannot support such long serial port names or if you really want a specific device to ALWAYS show up say as /dev/ttyUSB0, you need to use the manual UDEV rule approach. The manual UDEV rule method: ---------------------------- Alternatively, you could have used the following command to get details: udevadm info -a -n /dev/ttyUSB0 If your adapter's Vendor and Product IDs are matched in the Linux kernel code, the USB port should be automatically be mapped to the next freely available ttyUSB port such as USB0, USB1, etc. Now if the USB device WASN'T recognized, the output of "dmesg" will show the details of the USB device but it won't map it to a ttyUSB serial device or anything else because it doesn't know what it is. Unrecognized device: You can either see read the "Enabling US Interface Navigator USB support via UDEV (optional)" section below to resolve this via UDEV if the device is supported but just not properly detected. Alternatively, see the kernel building section to learn how to deal with unrecognized USB devices by modifying the kernel, recompiling it, and then running that kernel! Simple, persistent USB enumeration: Here are three different examples of getting some of my USB serial devices to ALWAYS get persistent /dev names. Edit the file /etc/udev/rules.d/99-usb-serial.rule and add the lines: #Device #1 - cablesunlimited.com USB-2920 - 1-port USB to serial adapter (FTDI-based) SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FTCAWZIA", NAME="ftdi-serial-cable" #Device #2 - Generic 1-port USB to serial adapter (Prolific-based) for a Kenwood THF6A cable SUBSYSTEM=="tty", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2302", SYMLINK+="thf6a-cbl" #Device #3 - RT Systems CT-62B 1-port USB to serial adapter for FT817/857/897 (FTDI-based) # #NOTE: This adapter is NOT recognized by the Linux kernel as a valid # serial device. RT System does this ON PURPOSE so their programming # software will only work with their cables! You can change these IDs # if you wish with http://www.ftdichip.com/Support/Utilities.htm#FT_Prog # # Alternatively, the following will run a script to poke the RT Systems # USB IDs into the kernel FTDI driver so it can recognize the new # device as a serial port. # BUS=="usb", SYSFS{idVendor}=="2100", SYSFS{idProduct}=="9e56", ENV{ID_MM_DEVICE_IGNORE}="1", RUN+="/usr/local/sbin/RTSystems-addports.sh &" SUBSYSTEM=="tty", ATTRS{idVendor}=="2100", ATTRS{idProduct}=="9e56", SYMLINK+="ft857_prog" Much more of this USB device enumeration topic is discussed in the "Enabling US Interface Navigator USB support via UDEV (optional)" section below

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

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

1f. - Working around the ModemManager 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 Hayes AT commands via RTTY! # Disable the modem-manager binary but this will # get undone if the program gets updated via a Yum update # mv /usr/sbin/modem-manager /usr/sbin/modem-manager.disabled killall modem-manager If you're still having UDEV issues, please see section: "2.c - Enabling US Interface Navigator USB support via UDEV" for points on how to do debugging, etc.

1.g. - Deterministic sound cards

One issue that Linux faces due to it's flexible everything is consistent enumeration of multiple sound cards just like it's serial ports. What does that mean? When you reboot your Linux machine, your ALSA device ID's might change around and never be consistent / deterministic! At that point, you'll have to manually re-configure your various programs to use the right ALSA ID every single time. What a pain! The following section fixes that issue! In my specific situation, I have four sounds cards in my system: cat /proc/asound/cards -- 0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc0600000 irq 42 1 [CODEC ]: USB-Audio - USB Audio CODEC Burr-Brown from TI USB Audio CODEC at usb-0000:00:1d.0-1.1.1, full speed 2 [Pro ]: USB-Audio - SB X-Fi Surround 5.1 Pro Creative Technology Ltd SB X-Fi Surround 5.1 Pro at usb-0000:00:1d.0-1.2, full 3 [Device ]: USB-Audio - Generic USB Audio Device Generic USB Audio Device at usb-0000:00:1d.0-1.2, full speed -- Breaking it down: ID#0 is the laptop's computer's built-in sound card - Used for general audio playback ID#1 is the US Interface Navigator USB sound card - used for HF/VHF digital modes (PSK, SSTV, etc.) ID#2 is a Creative Labs Soundblaster X-Fi USB sound card - used with a SoftRock SDR ID#3 is a cheap CM109 USB sound card FOB - used for Svxlink for Echolink If you issue the command "aplay -l", you can see all the various PLAYBACK interfaces offered by each sound device. If you use "arecord -l", you can see all of the recording interfaces. To find the proper technical "name of a specific ALSA sound card, run "aplay -L" and you'll see something like: aplay -l -- List of PLAYBACK Hardware Devices card 0: PCH [HDA Intel PCH], device 0: ALC269VB Analog [ALC269VB Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: CODEC [USB Audio CODEC], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Pro [SB X-Fi Surround 5.1 Pro], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: Pro [SB X-Fi Surround 5.1 Pro], device 1: USB Audio [USB Audio #1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 3: Device [Generic USB Audio Device], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 -- Breaking that output down, here is how to read each line is like the following: card 3: Device [Generic USB Audio Device], device 0: USB Audio [USB Audio] ^^^^^^ ^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^^^^ | | | | | | | #2 the | #4 the | #6 the #1 the ALSA #3 the sub-device #5 the sub-device ALSA device device number sub- description device name description device type In the above example, I want this el-cheapo USB sound card currently shown as device #3 to ALWAYS become ID#3. The reason why I described each field is because the USB device naming from the USB device itself can be completely and utter generic and thus totally confusing. In this example, this cheapy sound card name here is "device" (item #2 above). How useless is that!! I could argue that the US Interface Navigator's name of "CODEC" is equally useless. Don't blame ALSA, that's the name the manufacturer gave their USB device! The other things to pay attention to is field #3 which is the description of the device and field #6 which is the device TYPE. In my example, I have three USB sound cards using the same TYPE. That's bad because they all use the same driver. Since it's the same driver, I now have to narrow things down by USB device ID. To do this, I need to use then use the device description in field #3 as the starting point. Following the text from above, I'm going to get the device IDs for all my USB devices including the US Interface Navigator, my SoundBlaster X-Fi, and the cheapy USB sound card: #For the US Interface Navigator lsusb -v | grep -B4 "USB Audio CODEC" idVendor 0x08bb Texas Instruments Japan idProduct 0x2906 bcdDevice 1.00 iManufacturer 1 Burr-Brown from TI iProduct 2 USB Audio CODEC ---------------------------------------------------- #For the Creative Labs Soundblaster X-Fi lsusb -v | grep -B4 "SB X-Fi Surround 5.1 Pro" idVendor 0x041e Creative Technology, Ltd idProduct 0x30df bcdDevice 1.00 iManufacturer 1 Creative Technology Ltd iProduct 2 SB X-Fi Surround 5.1 Pro ---------------------------------------------------- #Syba USB soundcard lsusb -v | grep -B4 "Generic USB Audio Device" idVendor 0x0d8c C-Media Electronics, Inc. idProduct 0x0008 C-Media USB Audio Device bcdDevice 1.00 iManufacturer 0 iProduct 1 Generic USB Audio Device We now have the dirty details we need, specifically the USB idVendor and idProduct. Ok, so create the following file with the following text for the C-Media device: NOTE: ALSA starts it's numbering with 0 so with this example, I'm not defining what's slot#0 since it doesn't use the USB audio driver /etc/modprobe.d/alsa.conf -- #1- US Navigator, 2- Soundblaster Xfi, 3- Syba USB soundcard dongle options snd-usb-audio index=1,2,3 vid=0x08bb,0x041e,0x0d8c pid=0x2906,0x30df,0x0008 -- Hopefully you got all that. If your setup isn't covered here, please see the ALSA docs at http://alsa.opensrc.org/MultipleCards for full details on how to get consistent enumeration.

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

Linux Power Management ---------------------- This is an ugly topic for me as it seems that entire power management systems are different from distro to distro and they completely change out their solution every year! Classic Linux! It's maddening and the GUIs be it Gnome, KDE, etc. seem to override the lower level systems like acpitool, devkit-power, etc. Which to use? Depends! Gaaaahhh! The packetrig.sh script as covered in this this document at http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/packetrig.sh distills all of this into something that should work to enable power savings but also disabling suspending when not wanted, etc. A few options: -------------- # If you're using KDE4 as I am, you can send a DBUS signal # Please note you CANNOT run this as root when logged in as a regular user so # You have to use sudo to work around it # sudo -u YOURUSERNAME qdbus org.kde.powerdevil /modules/powerdevil setProfile Performance #klunky but ABSOLUTE way to disable the system from suspending # mv /usr/sbin/pm-suspend /usr/sbin/pm-suspend.disabled #Devkit policy - Very powerful system to change all kinds of parameters but to # disable the possibility of suspending, edit this file and change ALL options # to NO vim /usr/share/polkit-1/actions/org.freedesktop.devicekit.power.policy A few power management tools to start your search: powertop - A fantastic tool to help tune your system for power management It interactively identifies system tuning recommendations and activates them for the current runtime. If you want these settings to be permanent, either set them the devkit /etc/tune-profiles tuned-adm - Centos 6 mechanism to control power management. Check out the "list" option but notice these parameter have no obvious bearing on Gnome or KDE settings. See /etc/tune-profiles/ for specific details but it's not clearly spelled out devkit-power - Check out "-d" to see what your system shows for managed devices, etc. acpitool - Control the power management of your machine so it doesn't turn off when you least expect it. An excellent document for everything power management in Centos 6 and how to audit and optimize your system: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Power_Management_Guide/index.html Disabling SecureLinux --------------------- - Disable SE Linux (unless you know how to create all the detailed SELinux enforcement policies for the various HAM applications): edit the /etc/sysconfig/selinux file and set it to: SELINUX=disabled - remove the setroubleshoot RPM (if installed) setroubleshoot automatically runs client-side code whenever a denial occurs even if the setroubleshootd daemon isn't running! Removed it entirely unless it is needed: yum erase setroubleshoot Other Misc Things: ------------------ - Adobe Acrobat Acroread is a 32bit application and requires a multitude of 32bit libraries to be installed to work. Forget it. Install "evince" and be done with it.

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

In the event that things crash on your system, you need to be able to allow the machine to record a "coredump" or backtrace. With a coredump in hand, you'll at least have a clue to what died on your machine and why. To enable coredumps, edit the /etc/sysctl.conf file, find and edit/add the following line: kernel.core_uses_pid = 1 Next, edit the file /etc/security/limits.conf and append the line - core unlimited Next, the Centos ABRT system is a system to capture additional details about the machine at the time of a coredump. These details are very helpful as well. ABRT will record all this state for programs running as installed packages but if you are running anything that was NOT installed as an RPM, ABRT will automatically delete the coredump and all the additional details! Let's change that! Edit the file /etc/abrt/abrt-action-save-package-data.conf and change the lines that say: OpenGPGCheck = yes ProcessUnpackaged = no to OpenGPGCheck = no ProcessUnpackaged = yes

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

+-----------------------------------------------------------------------+ | IMPORTANT: | | This documentation now uses the El Repo ML kernel sources | | because I need newer kernels to support specific hardware | | and I wanted the included AX.25 kernel modules | | | +-----------------------------------------------------------------------+ By default, the stock Centos and RHEL kernels for Centos v6, v5, etc do NOT include the support for the AX.25 protocol stack or the various packet radio interfaces like KISS and 6PACK. Fortunately, there are some options now and at least the Timewave (was US Interface ) Navigator is now supported in the 2.6.35+ kernels by yours truly :-). What does this all mean? You have a choice: 1) Instead of using RHEL/Centos kernels, you can use ELRepo kernels which package the mainstream Linus kernels and now include the amateur radio kernel modules per request from your's truely: http://lists.elrepo.org/pipermail/elrepo/2017-May/003566.html Read more below of how to enable the Elrepo kernel repo and install one of the two versions of the kernels 2) If you want to stick with RHEL/Centos kernels, you will have to either patch and recompile the kernel to add the amateur radio kernel modules. Navigator support is already included and making the UDEV config changes as mentioned above will work just fine NOTE: If you are going to be compiling a kernel, this doc assume you are modifying one of the following kernels: Centos6 - 2.6.32-x.el6.x86_64 or Centos5 - 2.6.18-x.el5 kernel Before you get the SRPMs and sources for the new kernel, consider this: ----------------------------------------------------------------------- Official Centos/Redhat kernels: ------------------------------- There are the stock Centos kernel sources that are directly based from Redhat's kernels. These are very stable but also VERY OLD kernels. As such, they might not support all the new hardware that you or others might have! It's also worth noting that they do NOT include support for the AX.25 protocol stack (ElRepo kernels DO). El Repo kernels: ---------------- The ELRepo Yum Repo group (documented above) in this document packages new Linux kernels but are specifically made to be compatible with Centos/Redhat kernels. These newer kernels get you newer hardware support, newer ALSA sound drivers, include AX.25 kernel support, etc. They have TWO versions of kernels: ML: Main-Line Stable: These kernels are newest kernels available and are always MUCH newer than the Centos / Redhat kernels. They are considered their feature supported kernels and are a good option for people that need the newest kernel (kernel 4.8.x vs. 2.6.32) but want the highest stability. LT : Long term supported: These kernels use the kernels that's considered stable by the Linux developers (aka OLDER). These kernels will get you support for a lot more new hardware, new fixes (and potentially new bugs). It's also worth mentioning that you can usually take a an ML kernel from say EL7 and use it on EL6 (if you needed say a 4.4.x kernel) but more work might be required to get it to compile If you choose to use the El Repo kernels and recompile them, you need to first download the newest Elrepo SRPMs which aren't everything you need. They are just the patches to be applied to the stock kernel sources. Download them here: http://repos.lax-noc.com/elrepo/kernel/el6/SRPMS/ Separately, download the matching stock kernel sources from here and place in the /usr/src/redhat/SOURCES dir. Be sure to get the tar.xz version: https://www.kernel.org/ +-----------------------------------------------------------------------+ | IMPORTANT: | | This documentation now uses the El Repo ML kernel sources | | because I need newer kernels to support specific hardware | | and I wanted the included AX.25 kernel modules | | | +-----------------------------------------------------------------------+ Reference material for properly building custom kernels for Centos RPMs ----------------------------------------------------------------------- Proper custom kernel compiling approach --------------------------------------- http://www.centos.org/modules/newbb/viewtopic.php?topic_id=20016 Centos 5.x specific: Issues with building custom kernels for Centos 5.4 ------------------------------------------------------------------------ http://wiki.centos.org/HowTos/Custom_Kernel#head-566abc4208fceb902d41ee82633f509dbf386a4d You first need to install the following RPMs to be able to compile a custom kernel: yum install nasm yum install asciidoc yum install newt-devel Next, you need to install the Centos kernel-headers, kernel-devel, and kernel source RPM #get the misc kernel parts first yum install kernel-headers kernel-devel #Let's get started using the El Repo LT kernel. Enter in the SRPM directory: # cd /usr/src/redhat/SRPMS # Use up the "links" text web browser to go to an ElRepo website mirror, # locate the newest LT kernel source RPM (highest version number given), # use the cursor keys to go to the desired file (it will highlight it) and # hit the "d" key to download it (it will be fast because it's only patches). # Once downloaded, hit the "q" key to exit links ElRepo Kernel Pathces: --------------- Centos6 - links http://elrepo.org/linux/kernel/el6/ NOTE: This section assumes the following kernel version is used: Centos6 - kernel-ml-4.8.11-1.el6.elrepo.nosrc.rpm - 12/01/2016 - Scroll down to kernel-ml-4.8.11-1.el6.elrepo.nosrc.rpm file with the cursor keys, hit enter to select, and then select SAVE using the tab and enter key NOTE: This file is very small as it's only an overlay for the vanilla Linus kernels which need to be downloaded elsewhere - Once downloaded, hit the "q" key to exit links Stock Linux kernel source code ------------------------------ Now you need to download the matching vanilla Linus kernel code. For this documentation, it's assuming the 4.8.11 version cd /usr/src/redhat/SOURCES Use up the "links" text web browser to go to https://www.kernel.org/pub/linux/kernel/v4.x/ - locate the matching kernel source .tar.xz file (again.. get the XZ file ] to the matching ElRepo SRPM version - Use the cursor keys to go to the desired file (it will highlight it) and hit the "d" key to download it NOTE: This is a very big file and will take some time to download Once downloaded, hit the "q" key to exit links If you're going to used the stock Centos provided kernels (NOT RECOMMENDED): ---------------------------------------------------------------------------- cd /usr/src/redhat/SRPMS Next, you need to download the correct version of the SRPMS Centos6 - links http://vault.centos.org/6.2/updates/Source/SPackages/ Centos5 - links http://vault.centos.org/5.8/updates/Source/SRPMS/ #If you choose to still go this route, this doc assumes the following: Centos6 - kernel-2.6.32-220.7.1.el6.src.rpm - 03/18/2012 Centos5 - kernel-2.6.18-274.18.1.el5.src.rpm - 04/04/2012 #Hit "q" to quit Links once downloaded

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

Make a backup of any older SPEC files: One key point to make here is to MOVE the old SPEC file so it minimizes any risks to new patches not being applied, etc. Centos6: cd /usr/src/redhat/SPECS mkdir Old #If a previous kernel source was installed mv kernel.spec Old/kernel.spec.`date +%m%d%y ` mv kernel-ml-4.8.spec Old/kernel.spec.`date +%m%d%y ` mv kernel-ax25-el6.spec Old/kernel-ax25-el6.spec.`date +%m%d%y ` Centos5: cd /usr/src/redhat/SPECS mkdir Old #If a previous kernel source was installed mv kernel-2.6.spec Old/kernel-2.6.spec.`date +%m%d%y ` mv kernel.spec Old/kernel.spec.`date +%m%d%y ` mv kernel-ax25-el5.spec Old/kernel-ax25-el5.spec.`date +%m%d%y ` If you've previously created a custom kernel, make a backup of it's varous config files just in case: cd /usr/src/redhat/SOURCES/ mkdir Old #the config-local is the key file to enable local settings; especially for AX.25 cp config-local Old/config-local.`date +%m%d%y ` cp config-generic Old/config-generic.`date +%m%d%y ` cp config-x86_64-generic Old/config-x86_64-generic.`date +%m%d%y ` #this file will only be present if you've already upgraded your kernel once following this doc cp config-x86_64-generic-ax25-rhel Old/config-x86_64-generic-ax25-rhel.`date +%m%d%y ` Now install the ElRepo or stock Centos SRPM (NOT RECOMMNEDED) with the following commands. NOTE: Ignore any errors or warnings about "user mockbuild" or "user ajb" in the final stages of the RPM install. This is just an artifact of who created the source package ElRepo LT kernel: ----------------- cd /usr/src/redhat/SRPMS/ sudo rpm -ivh kernel-ml-4.8.11-1.el6.elrepo.nosrc.rpm #If you're curious to see what files were installed, run the command: rpm -qipl ../SRPMS/kernel-ml-4.8.11-1.el6.elrepo.nosrc.rpm Stock Centos kernel (NOT recommended): -------------------------------------- Centos 6 -------- cd /usr/src/redhat/SRPMS/ rpm -ivh kernel-2.6.32-.el6.src.rpm For example: rpm -ivh kernel-2.6.32-220.7.1.el6.src.rpm Ignore any errors about "user mockbuild" Centos5: -------- rpm -ivh kernel-2.6.18-.el5.src.rpm

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

Ok, now regardless of using the Elrepo or stock Centos kernel approach, we need to modify the kernel configuration to add support for the AX.25 protocol, Packet TNC interfaces, and optionally (no longer needed in modern kernels) Timewave / US Interface Navigator USB device in any Centos kernel: - Create and add the following lines into the appropreate file Centos6: -------- #This file configured CPU agnostic features vim /usr/src/redhat/SOURCES/config-local Centos5: -------- #This file configured CPU agnostic features vim /usr/src/redhat/SOURCES/config-rhel-generic (these changes can also be found at http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/linux/ CONFIG_HAMRADIO=y CONFIG_AX25=m CONFIG_AX25_DAMA_SLAVE=y CONFIG_NETROM=m CONFIG_ROSE=m CONFIG_MKISS=m CONFIG_6PACK=m CONFIG_BPQETHER=m CONFIG_BAYCOM_SER_FDX=m CONFIG_BAYCOM_SER_HDX=m CONFIG_BAYCOM_PAR=m CONFIG_BAYCOM_EPP=m CONFIG_YAM=m CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 NOTE: You SHOULD NOT modify the original kernel-.config files as user specific items ONLY go in the "generic" files instead NOTE#2 If you need to configure CPU arch specific features (X86_64) such as disable the CONFIG_CC_STACKPROTECTOR_STRONG=Y feature from a Centos7 ml-4.4.26 kernel, these changes and overrides would need to go in the config-4.4.26-x86_64 file NOTE#3: Please note that if you're updating to a new kernel and have already followed these instructions, you might not be able to simply restore you last config-local or config-x86_64-generic-rhel file. The new kernel "options might have been enabled in the new kernel that weren't present in the previous one NOTE#4: I have not enabled "CONFIG_EMBEDDED=y" just yet as I want to see if this is still required to get BSD-style PTY functionality working properly. If your PTYs aren't working, you will need to enable CONFIG_EMBEDDED=y and and then also configure about 15 other non-related things that the new 2.6.x kernels now seem to require. Update: I've found that EMBEDDED is not required - Make a backup of this file so you can use it again with other kernel upgrades: Centos6: cp usr/src/redhat/SOURCES/config-local \ usr/src/redhat/SOURCES/config-local-ax25 Centos5: cp /usr/src/redhat/SOURCES/config-rhel-generic \ /usr/src/redhat/SOURCES/config-rhel-generic-ax25 - Next, edit the kernel.spec file to update the kernel's name to reflect something more unique: cd /usr/src/redhat/SPECS #If using the ML series Elrepo kernels, you'll need to match the # kernel family version to what you downloaded # sudo vi kernel-ml-4.8.spec - For an ElRepo kernel, find and update the line: %define LKAver 4.8.11 - Next, find the line: # % define buildid . IMPORTANT: ---------- Notice the "#" at the front of the line AND the space between the "%" and "define" word. Change this to the following (notice the removed #, REMOVED the EXTRA space, and added the ".ax25": %define buildid .ax25 Centos6 using ML kernel ----------------------- - Copy the altered spec file just in case mv kernel-ml-4.8.spec kernel-ml-4.8-ax25.spec Future ------ - Optionally add in any specific kernel patches needed for your installation HEADS-UP: Failed attempt on using Centos7 kernels on Centos6: ------------------------------------------------------------- Trying to use a Centos7 kernel on Centos6 will NOT work as the Centos7 kernel requires various SystemD programs to be installed and configured. Unless you want to retrofit in SystemD into your system, this won't work # These steps are kept here for posterity reasons 1. Must disable CONFIG_CC_STACKPROTECTOR_STRONG as Centos6's version of GCC doesn't support it. Add into /usr/src/redhat/SPECS/config-4.4.26-x86_64 CONFIG_HAVE_CC_STACKPROTECTOR=n CONFIG_CC_STACKPROTECTOR=n CONFIG_CC_STACKPROTECTOR_STRONG=N 2. Centos7 kernel uses a differe path for modinfo ln -s /sbin/modinfo /usr/sbin/modinfo 3. It's not possible to build a Centos7 4.4.26-ml kernel on Centos6 machine due to requiring SystemD. The error seen is: error: File must begin with "/": %{_unitdir}/cpupower.service

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

----------------------------------------------------------------- - If you aren't using a modern kernel or DON'T have a US Interfaces Navigator, please skip down to the COMPILING step later in this document ----------------------------------------------------------------- In the above "PreSetup: UDEV based deterministic Serial ports" section, I covered how to create deterministic enumeration for USB based serial ports US Interface Navigator support: ------------------------------- In the previous version of this document, I covered how to add support for this USB soundcard device directly via kernel patches. This is still the most complete way to get things done but it requires a lot of work in compiling the kernel, etc. which scares off most users. I've retained that older documentation at the bottom of this section but there is simpler, non-invasive way to add US Interface Navigator (and other USB-based serial devices) support: UDEV. In addition to not requiring source code changes, compiling and installing a new kernel, the following UDEV changes make the port naming PERSISTENT so the serial devices will always use expected names in /dev. For example, my setup now has the following persistent: USI_CAT -> ttyUSB0 USI_CFG -> ttyUSB6 USI_FSK -> ttyUSB4 USI_PTT -> ttyUSB1 USI_SER -> ttyUSB5 USI_WKEY -> ttyUSB3 - US Interface Navigator with UDEV and kernel module options: ----------------------------------------------------------- The US Interface Navigator is a USB soundcard which includes 6 FTDI based serial ports for CAT-based RIG control, secondary PTT, Winkeyer interfacing, setting of other configurations, and FSK data. As mentioned above, not all of these ports are natively supported until 2.6.35. Some Linux experts might be thinking: "Hey, Linux allows you to specify an additional USB vendor and product IDs when you first install the USB kernel module via the following": modprobe ftdi_sio vendor=0x0403 product=0xb810 So you'd naturally think you could just add additional vendor and product IDs like the following.. right? modprobe ftdi_sio vendor=0x0403 product=0xb810 vendor=0x0403 \ product=0xb811 vendor=0x0403 product=0xb812 Wrong. That doesn't work as the kernel doesn't recognize the additional USB devices what so ever and doesn't realize it's a serial device let alone a FTDI-based serial device. What you CAN do is do a combination: - use the kernel module mechanism AND - use the newer "new-id" feature: #1. Load the FTDI module and treat this vendor/product ID as a # FTDI device - you can only specify ONE device at a time # modprobe ftdi_sio vendor=0x0403 product=0xb810 #2. After the kernel module is loaded, dynamically signal the driver # to support ADDITIONAL vendor/product IDs as FTDI devices # echo "0403 b811" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id echo "0403 b812" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id NOTE: ----- I spent a LOT of time trying to figure out why the first USB serial device, "b010" device will be properly recognized AND acted upon in the UDEV configuration yet the other two devices, "b811" and "b812" devices wouldn't be recognized AND acted upon. My best guess is that there is a race condition in the FTDI driver where only one device is being allowed to be evaluated and acted upon at a time. I stumbled upon this timing issue when I was using a sleep statement. I also found that you CANNOT use bash-line redirects like the following directly in a UDEV rule: echo "0403 b811" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id It seems that if there is a ">" character in the UDEV rule, you would see something like the following when running the UDEV daemon in DEBUG mode: /bin/echo 0403 b811 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id' returned with exitcode 0 /sbin/modprobe -b usb:v0403pB811d0500dc00dsc00dp00icFFiscFFipFF' started With all that, you now get full US Interface Navigator serial port support without kernel changes. to make these changes permanent across reboots, create the following files: /etc/udev/rules.d/10-us-interfaces-navigator.rules -- #US Interface Navigator # NOTE: UDEV is very specific to the hierarchy where the strings # are located. I recommend to use the following command to # show the proper hierarchy when one US Navigator port is # loaded: # # udevadm info --attribute-walk --name=/dev/ttyUSB0 # BUS=="usb", SYSFS{idVendor}=="0403", SYSFS{idProduct}=="b810", ENV{ID_MM_DEVICE_IGNORE}="1", RUN+="/sbin/modprobe ftdi_sio vendor=0x0403 product=0xb810" SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (CAT & 2nd PTT)", ATTRS{bInterfaceNumber}=="00", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_CAT" SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (CAT & 2nd PTT)", ATTRS{bInterfaceNumber}=="01", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_PTT" BUS=="usb", SYSFS{idVendor}=="0403", SYSFS{idProduct}=="b811", ENV{ID_MM_DEVICE_IGNORE}="1", RUN+="/usr/local/sbin/USI-addports.sh &" SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (WKey & FSK)", ATTRS{bInterfaceNumber}=="00", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_WKEY" SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (WKey & FSK)", ATTRS{bInterfaceNumber}=="01", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_FSK" SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (RS232 & Config)", ATTRS{bInterfaceNumber}=="00", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_SER" SUBSYSTEMS=="usb", DRIVERS=="ftdi_sio", ATTRS{interface}=="Navigator (RS232 & Config)", ATTRS{bInterfaceNumber}=="01", ENV{ID_MM_DEVICE_IGNORE}="1", SYMLINK+="USI_CFG" -- To support the above UDEV rules, we need to create the USI-addports.sh shell script: vim /usr/local/sbin/USI-addports.sh -- #!/bin/bash #Sleep 2 to avoid a seeming race condition sleep 2 #tell the FTDI driver about the WKey and FSK serial ports /bin/echo "0403 b811" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id #tell the FTDI driver about the RS232 and Config serial ports /bin/echo "0403 b812" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id -- Once that file is created, UDEV will automatically detect the presence of this new 10-us-interfaces-navigator.rules rule file. There is no need to reload the UDEV daemon, etc! +--------------------------------------------------------------+ | NOTE on Serial port permissions: | | -------------------------------- | | With the use of UDEV, all serial ports require users to have | | the "dialout" group permission. To enable this for your | | login (don't use root): | | | | - edit the /etc/groups file as root u | | - scroll down and find the "dialout" group name | | - append at the end of the line the needed username like | | dranch | | | | You will have to LOGOUT and log back in with this | | username for the changes to go into effect | | | | Once logged back in, open a terminal window and run | | the command "groups". Make sure "dialout" shows up. | | If it doesn't you'll need to log out of your current | | Gnome/KDE/whatever session and back in to get the new | | settings. | +--------------------------------------------------------------+ Debugging: ---------- If the UDEV rules aren't seeming doing anything (or what you expect) them to do, enable debugging! You can either do it dynamically or upon every boot: #Dynamically change from ERR to DEBUG level output in syslog # all outputs should show up in /var/log/messages # udevadm control --log-priority=debug #Once done with UDEV debugging, dynamically turn it off with # udevadm control --log-priority=err # For permanent debugging, edit the /etc/udev/udev.conf file # and either add or change the following line from ERR to DEBUG -- udev_log="err" -- Modem-Manager and Centos 6 -------------------------- As part of Centos 6's fully automatic NetworkManager system, a sub-program called modem-manager tries to initialize serial port based analog modems. The problem with this is that when UDEV initializes the US Interface Navigator's FSK port, modem-manager thinks it's a modem and will try to send some Hayes AT commands to it. Modem-manager is generally recognized as BAD code and makes way too many assumptions and there is an Ubuntu bug filed to change this assumption behavior. Unfortunately, the current Centos state makes the Navigator assert PTT on the rig and starts transmitting those Hayes AT commands via RTTY! # Disable the modem-manager binary but this will # get undone if the program gets updated via a Yum update # /usr/sbin/modem-manager /usr/sbin/modem-manager.disabled killall modem-manager Verify the USB serial ports: ---------------------------- To check that the Navigator ports are recognized and installed properly, run the following command to see all the devices: ls -la /dev | grep USB ttyUSB0 ttyUSB1 ttyUSB2 ttyUSB3 ttyUSB4 ttyUSB5 USI_CAT -> ttyUSB0 USI_CFG -> ttyUSB5 USI_FSK -> ttyUSB3 USI_PTT -> ttyUSB1 USI_SER -> ttyUSB4 USI_WKEY -> ttyUSB2 It's the USI /dev device names that you'll want to use to configure Flrig and other devices

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

+------------------------------------------------------------------------+ | Skip this section if you're going to use the Udev method (RECOMMENDED) | +------------------------------------------------------------------------+ +---------------------------------------------------------------------------+ | NOTE: | | I submitted the kernel patch to have Linux kernels natively support | | the US Navigator back in July, 2010. This support is now available | | in the following kernels and all follow on versions: | | | | 2.5.35 | | | | All newer kernels have this support now so this section is mostly | | kept around for historical reasons | +---------------------------------------------------------------------------+ - US Interface Navigator with kernel patches: ------------------------------------------- Until the Navigator is natively supported in the kernel, you can add that support via minor customization of the kernel source code. Since I like to do things via RPMs to keep things very clean, this does require a little work. Get the following patches individually from: http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/linux/ or in http://www.trinityos.com/HAM/hampacket-CentosDigitalModes-.tgz - cd /usr/src/redhat/SOURCES - cp /tmp/kernel-2.6.spec-add-usnavigator-and-ax25.patch . # Apply the SPEC patch to add in the additional scripts to enable # the additional serial ports on the US Interface Navigator patch -p0 < kernel-2.6.spec-add-usnavigator-and-ax25.patch #Apply the kernel configuration changes to enable various HAM radio # features for packet radio, etc. cp /tmp/config-rhel-generic-ax25.patch . patch -p0 < config-rhel-generic-ax25.patch - Centos5 only (it's unclear if this is required for Centos6): ------------------------------------------------------------ To get BSD-style PTYs to work, you have to also add the following to the config-rhel-generic file. This is ONLY required for legacy configurations using tools like JNOS, etc CONFIG_EMBEDDED=y # Copy over the FTDI code patches - cp /tmp/linux-2.6-usb-usinterface-add-support-for-navigator.patch . Persistent USB Device Naming ----------------------------- If you'd like to have the serial ports retain a persistent naming across newly added devices, reboots, etc., take a look and review the "Determinisitic Serial ports" portion of the "PreSetup: Centos Optimizations" section and the UDEV rules in the Kernel RPM compiling section above and in that 10-us-interfaces-navigator.rules file, only add the lines that contain "bInterfaceNumber". After that, you should be good to go! Verify the USB serial ports: ---------------------------- To check that the Navigator ports are recognized and installed properly, run the following command to see all the devices: ls -la /dev | grep USB ttyUSB0 ttyUSB1 ttyUSB2 ttyUSB3 ttyUSB4 ttyUSB5 USI_CAT -> ttyUSB0 USI_CFG -> ttyUSB5 USI_FSK -> ttyUSB3 USI_PTT -> ttyUSB1 USI_SER -> ttyUSB4 USI_WKEY -> ttyUSB2 It's the USI /dev device names that you'll want to use to configure Flrig and other devices

2.e - Compile and create the new kernel RPM

+------------------------------------------------------------------------+ | NOTE: This section is only required if you want to compile either a | | RHEL/Centos or ElRepo kernel from scratch. This is NOT required | if you choose to install a prebuilt Centos or ElRepo kernel | +------------------------------------------------------------------------+ Ok, time to compile the kernel and create the RPM. All of the following will make the primary kernel packages that a user would need: cd /usr/src/redhat/SPECS --------- Centos 6: --------- NOTE: The KABICHK option allows users to compile add-on kernel modules like disk drivers, etc. without having to recompile the entire kernel. It's a nice technology but it's not always 100% and to support it, you can see it takes a significant amount of compile time to support. Because of that, I'm DISABLING it below to make things compile faster: Important NOTE #2 ----------------- Compiling a linux kernel is one of the most demanding things you can do on a computer. It WILL tax the machine to it's limits and sometimes you might expose flaky computer hardware. I've seen it several times where a seemingly stable computer will crash, malfunction, or fail to complete only when trying to compile a kernel. Before you begin compiling, I encourage you to shutdown any non-essential programs that are memory hogs. This will give the compilers as much memory as possibe to avoid going into swap, etc: killall firefox killall thunderbird etc Compile an ElRepo kernel ------------------------ It's finally time build the kernel: Step #1 ------- date; time rpmbuild -bb --target=x86_64 --with firmware --without kabichk \ --without PAE --without debuginfo --without debug --without perf --without \ perf-debuginfo kernel-ml-4.8.spec; date This will first build the main kernel (fairly fast): You will see a line like "Kernel: arch/x86/boot/bzImage is ready" Then the kernel modules will be built (the majority of the build time) +-----------------------------------------------------------+ | Total Build time: | | | | Intel i5-2430 CPU based Laptop | | 2.4Ghz, 3MB cache, 4G of DDR3 RAM : | | Samsung Evo SSD: | | | | ElRepo 4.8.11 ml kernel w/o ABI chk: 50min 56sec (real) | | | +-----------------------------------------------------------+ Next, you now need to also build the kernel firmware package as well: Just for reference, here is the older build time for say the 3.17.5 ML kernel: +-------------------------------------------------------+ | Total Build time: | | | | Intel i5-2430 CPU based Laptop | | 2.4Ghz, 3MB cache, 4G of DDR3 RAM : | | Samsung Evo SSD: | | | | ElRepo 3.17.5 ml kernel w/o ABI chk: 32m 30s (real) | | | +-------------------------------------------------------+ Stock Centos kernel (NOT Recommended): -------------------------------------- date; time rpmbuild -bb --target=x86_64 --with firmware --without kabichk \ --without PAE --without debuginfo --without debug --without perf --without \ perf-debuginfo kernel-ax25-el6.spec; date You should also build the kernel firmware package as well: date; time rpmbuild -bb --target=noarch --without doc kernel-ax25-el6.spec +------------------------------------------------------+ | Total Build time: | | | | Intel i5-2430 CPU based Laptop | | 2.4Ghz, 3MB cache, 4G of DDR3 RAM : | | WDC 500GB 5400RPM 8MB HD: | | | | Centos6 2.6.x kernel w/o ABI chk: 41m 21s | | or w/ ABI chk: 71m 52s | + + | Older laptop | | | | Dell laptop (1.7Ghz Pentium-M 512MB RAM) | | Seagate 80GB 7200ROM HD: good build: 124m | | ABI check failure: 93m | +------------------------------------------------------+ - Once the kernel compiling is done, time to install the new RPMs +------------------------------------------------------------------+ | IMPORTANT NOTE: | | | | ABSOLUTELY Do NOT use the Upgrade or "-Uvh" RPM command | | when installing your new kernel. That will DELETE your | | previous stock centos kernel. You don't want to get rid of | | the old one until you are sure this new kernel boots, its | | stable, etc. | | | | Again, be sure to ONLY use the Install or "rpm -ivh" command. | +------------------------------------------------------------------+ # IMPORTANT #---------- # Make a backup of your grub.conf just in case something goes wrong # cp /boot/grub/grub.conf /boot/grub/Old/grub.conf.`date +%m%d%y ` # Elrepo Kernel code: #------------------- # Update the kernel version numbers to reflect your new kernel cd /usr/src/redhat/RPMS/ #Consider removing the older kernel header files only if you never intend to run those # older kernels. If you don't do this, you will get errors like: # # error: Failed dependencies: # kernel-headers 4.8.11-1.ax25.el6 conflicts with kernel-ml-headers-4.8.11-1.ax25.el6.x86_64 # kernel-headers 3.17.5-1.ax25.el6 conflicts with kernel-ml-headers-3.17.5-1.ax25.el6.x86_64 # kernel-headers 4.8.4-1.ax25.el6 conflicts with kernel-ml-headers-4.8.4-1.ax25.el6.x86_64 # sudo rpm -e kernel-ml-headers #Now install the new kernel rpm -ivh x86_64/kernel-ml-4.8.11-1.ax25.el6.x86_64.rpm #Next, install the new kernel-headers rpm -ivh x86_64/kernel-ml-headers-4.8.11-1.ax25.el6.x86_64.rpm \ #If you build lots of programs that might link into the kernel, you should #also install the kernel-devel package: rpm -ivh x86_64/kernel-ml-devel-4.8.11-1.ax25.el6.x86_64.rpm #Centos Stock code: #------------------- # Update the kernel version numbers to reflect your new kernel # cd /usr/src/redhat/RPMS/ rpm -ivh noarch/kernel-firmware-2.6.32-220.7.1.el6.ax25.noarch.rpm \ x86_64/kernel-2.6.32-220.7.1.el6.ax25.x86_64.rpm \ x86_64/kernel-firmware-2.6.32-220.7.1.el6.ax25.x86_64.rpm \ x86_64/kernel-devel-2.6.32-220.7.1.el6.ax25.x86_64.rpm \ x86_64/kernel-headers-2.6.32-220.7.1.el6.ax25.x86_64.rpm NOTE: ----- I also recommend to re-install the AX.25 libraries after upgrading the kernel to make sure that the proper AX.25 libs are in place as the kernel libraries are usually old: # 10/21/18: This issue has now been fixed in the Aug 2018 version of the # VE7FET repo but I need to clean up my doc completely to reflect # the fixes. TBD # #This version reflects the VE7FET SVN repo built as of 12/07/14. Please see the # compiling AX.25 section of this doc on how to get that going # cd /usr/src/redhat/RPMS rpm -ivh --force x86_64/libax25-1.0.5-168.x86_64.rpm --------- Centos 5: --------- # NOTE#1: I had to add the "--without kabichk" as the compile would # always fail out otherwise. The resulting kernel works fine. # # NOTE#2: ?no longer needed? # had to add --without fips date; time rpmbuild -bb --target=i686 --without kabichk --with baseonly \ --without PAE --without debuginfo --without xenonly kernel-2.6.spec Ok, time to install the new kernel: #Make a backup of your grub.conf just in case cp /boot/grub/grub.conf /boot/grub/grub.conf.bak cd /usr/src/redhat/RPMS/i686 +------------------------------------------------------------------+ | IMPORTANT NOTE: | | Do NOT use the Upgrade or "rpm -Uvh" command as that will | | DELETE your stock centos kernel which you shouldn't do until | | you are sure this new kernel boots, is stable, etc. Be sure | | to only use the Install or "rpm -ivh" command. | +------------------------------------------------------------------+ rpm -ivh kernel-2.6.18-164.6.1.el5.ax25.i386.rpm All Versions of Centos ---------------------- Since you created the kernel via an RPM method, go ahead and skip ahead to the "Final checks and booting into the new kernel for AX.25" section below before rebooting!

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

If you don't want to install the kernel via an RPM, you can make the kernel manually without an RPM, you can do the following method. Please note this section is written for the older Centos 5 stock kernels: cd /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.i386 make menuconfig Make the following changes (make sure it has either a "" [enabled in kernel] or a [M] kernel module next to each item: +-- general setup | | | +--local version | | | +--add the text: ax25 | +-- Processor Type | | | +-- Processor Family: set it to what CPU this machine has (default is | | Pentium Pro | | | +-- Preemption Model: I change this to Low-Latency desktop but this is | optional | +-- Networking | | | +--Amateur Radio support | | | | | +-- Amateur Radio AX.25 Level 2 protocol (use the space bar to | | make it a M or Module | | | | | +-- AX.25 DAMA Slave support | | +-- Amateur Radio NET/ROM protocol | | +-- Amateur Radio X.25 PLP (Rose) | | | | | +-- AX.25 network device drivers | | | +-- Serial port KISS driver | | | +-- Serial port 6PACK driver (NEW) | | | +-- BPQ Ethernet driver (NEW) | | | +-- BAYCOM ser12 fullduplex driver for AX.25 (NEW) | | | +-- BAYCOM ser12 halfduplex driver for AX.25 (NEW) | | | +-- BAYCOM picpar and par96 driver for AX.25 (NEW) | | | +-- BAYCOM epp driver for AX.25 (NEW) | | | +-- YAM driver for AX.25 (NEW) From here, select Exit, Exit, Exit, Exit, "YES - save the configuration" Save a copy of the new kernel config: cp .config /tmp/config-ax25 Ok, now in the main source directory, compile the kernel as you normally would or use the TrinityOS build-it script to help automate the stages: http://www.trinityos.com/LINUX/TrinityOS-security/usr/src/kernel/build-it.trinityos - make the kernel - make the kernel modules - make the initrd file - move the files to the proper places - update grub - reboot Persistent USB Device Naming ----------------------------- If you'd like to have the serial ports retain a persistent naming across newly added devices, reboots, etc., take a look and review the "Deterministic Serial ports" portion of the "PreSetup: Centos Optimizations" section and the UDEV rules above in the Kernel RPM compiling section and in that 10-us-interfaces-navigator.rules file, only add the lines that contain "bInterfaceNumber". After that, you should be good to go! Verify the USB serial ports: ---------------------------- To check that the Navigator ports are recognized and installed properly, run the following command to see all the devices: ls -la /dev | grep USB ttyUSB0 ttyUSB1 ttyUSB2 ttyUSB3 ttyUSB4 ttyUSB5 USI_CAT -> ttyUSB0 USI_CFG -> ttyUSB5 USI_FSK -> ttyUSB3 USI_PTT -> ttyUSB1 USI_SER -> ttyUSB4 USI_WKEY -> ttyUSB2 It's the USI /dev device names that you'll want to use to configure Flrig and other devices

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

Regardless of using the ElRepo or Stock Centos kernels or which version of Centos this is for (6 and 5): - Before you reboot: - look at /boot/grub/grub.conf and make sure the new kernel is there at the top of the listing and it's expected to boot by default. You can use the grub.conf backup you made to make this easy: diff -u /boot/grub/Old/grub.conf.`date +%m%d%y` /boot/grub/grub.conf Make sure your new kernel is: a) listed b) the top of the list (default to be booted) or the "default=" parameter points to your new kernel (remember it starts with a 0 not a 1) - Next, make sure the new kernel modules are present NEWKERNELVER=4.8.11 find /lib/modules/$NEWKERNELVER/kernel/drivers/net/hamradio/ for example, for a 4.8.11 Elrepo ML kernel -- baycom_ser_hdx.ko baycom_ser_fdx.ko mkiss.ko yam.ko hdlcdrv.ko 6pack.ko bpqether.ko baycom_par.ko -- NEWKERNELVER=4.8.11 find /lib/modules/$NEWKERNELVER/kernel/net/rose/rose.ko find /lib/modules/$NEWKERNELVER/kernel/net/ax25/ax25.ko ALL of those files MUST be present or that means your kernel recompile did NOT include the AX.25 configuration change! If you're happy with what you see in the kernel install, grub, etc., go ahead and reboot to start up the new kernel! Once rebooted, make sure that the AX25 kernel module is available by running the command and making sure the kernel module is present: ls /lib/modules/`uname -r`/kernel/net/ax25 You can also check by looking at: grep AX25 /boot/config-`uname -r`.el5ax25 that should come back with something like: -- CONFIG_AX25=m CONFIG_AX25_DAMA_SLAVE=y --

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

The AX.25 code that's built into the kernel from the above stages creates the foundation but now you need the toolkit to create the solution. That solution comes in three main packages: ax25apps, ax25tools, and libax25. None of these packages are available for stock Centos so we need to either find pre-built RPMs or build them ourselves. With that said, there has been a bit of fragmentation in this area for some time. It's always been recommended for people to use the "Official AX.25" sources found on sourceforge.net but it has been: 1) OLD and aren't current (have known bugs) 2) Don't have the required .SPEC files to build clean RPMs Here is a breakdown of the primary versions out there and what I recommend: Un-Official AX.25 Tools maintained by VE7FET: --------------------------------------------- Recommended --------------------------------------------- # 10/21/18: The Aug 2018 version of the VE7FET repo has major fixes but # I need to clean up my doc completely to reflect the fixes. TBD # This repository is a third fork of the AX.25 tools with many fixes applied and as of Dec, 2014. It has also become the recommended AX.25 version for FBB and FPAC as well. The same risk remains if it has all the fixes that are in the official CVS repo (mentioned below) but it seems this version of the libraries are the best ones to use today: https://github.com/ve7fet/linuxax25 You can see an update list of patch descriptions here: https://github.com/ve7fet/linuxax25/commits/master/ax25apps https://github.com/ve7fet/linuxax25/commits/master/ax25tools https://github.com/ve7fet/linuxax25/commits/master/libax25 Pre-build RPMs, Debs, etc used to be posted on the legacy Goggle site but they haven't been moved to the new site just yet (link given for historical reasons): https://code.google.com/p/linuxax25/source/browse/#svn%2Fdownloads Official release AX.25 Tools: ----------------------------- NOT Recommended ----------------------------- This "official" AX.25 repository can be found at: http://www.linux-ax25.org/pub/ The currently "released" ax25-tools at version 0.10rc4 from June, 2013, has several known problems. For example: - If you try to run the netromd program and specifically the nrattach command for each unique NR device, the ax25 tool will keep re-issuing the name nr0 device and not issue a unique device name like nr0, nr1, nr2, etc. Bug report: http://blog.gmane.org/gmane.linux.hams/page=22 (Fixed in the F6BVP variant): - When using ax25ipd for UDP wormhole connections, no connections will work and in the system logs, you'll see errors of: control byte non-zero Bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606338 (NOT Fixed in F6BVP code). To be addressed soon per Lee VE7FET (6/21/12) Official unreleased AX.25 Tools (SVN): -------------------------------------- NOT Recommended -------------------------------------- As part of the "Official" sources, there is a GIT (was CVS) version of the tools available at: git://git.linux-ax25.org/pub/scm/libax25 which is newer than the officially released code. It still significantly lags behind the fixes available from the VE7FET versions mentioned above. A few notes: 1. This repo was moved over to GIT and it does have newer fixes but still not the superset like VE7FET's. 2. As of 10/20/11, this CVS version contains some fixes over the "stable" release but this CVS tree is still very old WARNING: When you install the CVS code, it may DELETE any existing configuration files in /etc/ax25. Make sure you backup that directory before installing this new code Un-Official AX.25 Tools for FPAC: --------------------------------- NOT Recommended --------------------------------- I learned via an email dialog with F6BVP on 6/16/2012 that VE7FET merged in all of Bernard's changes as of September 2011 and the VE7FET version has now superseded F6BVP's version. There is a version of the AX.25 tools from the maintainer of the FPAC packet suite. This version is also considered to be much better than the official AX25 Tools CVS tree but it suffers the same risk as the VE7FET project mentioned in #2 above. http://f6bvp.free.fr/logiciels/ax25/ Ok, got all that? If your head is spinning, just pick the VE7FET code!

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

Creating RPMs from SRPMs for the AX.25 tools: --------------------------------------------- For creating RPMs, the VE7FET versions of AX.25 tools source code have SPEC file included. Next, You can get the SPEC files from either my file server or from the VE7FET archives following this section's steps. Using KI6ZHD's spec files (RECOMMENDED) # 10/21/18: The Aug 2018 version of the VE7FET repo has major fixes but # I need to clean up my doc completely to reflect the fixes. # I expect the .spec files will need to be updated. TBD # --------------------------------------- cd /usr/src/redhat/SPECS wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ax25apps.spec wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ax25tools.spec wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/libax25.spec (please skip to the next section) Updating the older Fedora SPEC files (NOT-RECOMMENDED) ------------------------------------------------------ If you want to put the spec files together yourself with the with the older source code: -- https://fedoraproject.org/wiki/SIGs/AmateurRadio/Packages On the Fedora site, this page is a little funky on how to use it. In the table, find the "Koji" column. Following list of apps, click on the Koji number for the respective app. NOTE: It seems that Centos 5.x's RPM program claims that the FedoraCore11 packages are corrupt and thus, it seems the F11 packages are incompatible but the FC9 versions seem ok. BTW, if you didn't already know it, RHEL 5/CENTOS 5 uses the same libraries, etc as FedoraCore 9! (please skip to the next section) Downloading pre-built sources (NOT RECOMMENDED) ----------------------------------------------- If you want to try installing the pre-built sources, go ahead and give it a try from: #Download a snapshot of the current Master tree: wget https://github.com/ve7fet/linuxax25/archive/master.zip #or download things via Git clone cd /usr/src/redhat/SOURCES git clone git://github.com/ve7fet/linuxax25.git (please skip to the next section) ----------------------------------------------------------------------------------------- Building up the recommended VE7FET sources: ------------------------------------------- First, get the newest versions from Git #Get and put the sources in the right place cd /usr/src/redhat/BUILD mkdir ax25 #Let's get the newest code git clone https://github.com/ve7fet/linuxax25.git # When I did that above command, it creates a directory named "linuxax25" and in there, there # are three sub-directories: # # ax25apps # ax25tools # libax25 #Next, we need to get the package version details of the sub-packages # cd linuxax25 echo "Git hash: `git log | head -n3 | grep -i -e commit -e date`" echo "APPS_VER: `grep AC_INIT ax25apps/configure.ac | awk -F', ' '{print }'`" echo "TOOLS_VER: `grep AC_INIT ax25tools/configure.ac | awk -F', ' '{print }'`" echo "LIB_VER: `grep libax25/configure.ac | awk -F', ' '{print }'`" #I just got the following after a download on 07/07/16 # # 10/21/18: The Aug 2018 version of the VE7FET repo has major fixes but # I need to clean up my doc completely to reflect the fixes. TBD # Git Hash: commit 44234a30369c1d8e32d46fae2bde43db5eab9585 Date: Mon May 2 15:44:05 2016 +0200 APPSVER: 1.0.5 TOOLSVER: 1.0.3 LIBVER: 1.0.5 #Let's package the sources up nicely for packaging cd linuxax25 #Let's start with libax25 package #-------------------------------- cd libax25 ./autogen.sh cd .. #Update this mv command and the tar command below to reflect the correct version name # mv libax25 libax25-1.0.5 # # create the archive name with the correct version, Git commit date and GIT hash # using the first 8 characters (most significant bits) of the Git hash # tar czvf /usr/src/redhat/SOURCES/libax25-1.0.5-20160502git44234a30.tgz libax25-1.0.5/ # You now need to update the ax25apps.spec "Release:" and "BuildRoot:" variables # to reflect or include the Git revision. As of 07/07/16, that would be: # # %global git_commit 44234a30369c1d8e32d46fae2bde43db5eab9585 # %global git_date 20160502 # Version: 1.0.5 # Release: 2.%{git_suffix}%{?dist} # BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) # BuildRequires: libax25-devel >= 1.0.5, libncurses-devel # BuildRequires: libax25-devel >= 1.0.5, ncurses-devel # Requires: libax25 >= 1.0.5 # Ok, you're done with this package for now. #Next up, Let's start with ax25apps package #--------------------------------- cd ax25apps ./autogen.sh cd .. #Update this mv command and the tar command below to reflect the correct version name # mv ax25apps ax25apps-1.0.5 # # create the archive name with the correct version, Git commit date and GIT hash # using the first 8 characters (most significant bits) of the Git hash # tar czvf /usr/src/redhat/SOURCES/ax25apps-1.0.5-20160502git44234a30.tgz ax25apps-1.0.5/ # You now need to update the ax25apps.spec "Release:" and "BuildRoot:" variables # to reflect or include the Git revision. As of 07/07/16, that would be: # # %global git_commit 44234a30369c1d8e32d46fae2bde43db5eab9585 # %global git_date 20160502 # Version: 1.0.5 # Release: 2.%{git_suffix}%{?dist} # BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) # BuildRequires: libax25-devel >= 1.0.5, libncurses-devel # BuildRequires: libax25-devel >= 1.0.5, ncurses-devel # Requires: libax25 >= 1.0.5 # Ok, you're done with this package for now. #Finally, let's finish with the ax25tools package #------------------------------------------------ cd ax25tools ./autogen.sh cd .. mv ax25tools ax25tools-1.0.3 # #Update this mv command and the tar command below to reflect the correct version name # tar czvf /usr/src/redhat/SOURCES/ax25tools-1.0.3-20160502git44234a30.tgz ax25tools-1.0.3/ # You now need to update the ax25apps.spec "Release:" and "BuildRoot:" variables # to reflect or include the Git revision. As of 07/07/16, that would be: # # Version: 1.0.3 # Release: 2.%{git_suffix}%{?dist} # # Source0: %{name}-1.0.3-%{release}.tar.gz # BuildRequires: libax25-devel >= 1.0.5, zlib1-devel # BuildRequires: libax25-devel >= 1.0.5, zlib-devel # Requires: libax25 >= 1.0.5 #Now clean up the unneeded Git repo #--------- cd /usr/src/redhat/BUILD rm -Rf ax25 #Now skip to the next section #------------------------------------------------------------------------------+ # NOT RECOMMENDED: Follow this section if you really want to use the Official | # AX.25 Repo which doesn't have all of the fixes that the | # VE7FET repo does | # | # These instructions are Out of Date | #------------------------------------------------------------------------------+ #Get and put the sources in the right place cd /usr/src/redhat/SOURCES wget -O ax25apps-1.0.2.tar.gz http://linuxax25.googlecode.com/files/ax25apps-1.0.2.tar.gz wget -O ax25tools-1.0.2.tar.gz http://linuxax25.googlecode.com/files/ax25tools-1.0.2.tar.gz wget -O libax25-1.0.3.tar.gz http://linuxax25.googlecode.com/files/libax25-1.0.3.tar.gz Extract the spec files (only realistically needed once and then you have the SPEC files) cd /usr/src/redhat/SPECS tar xzvf /usr/src/redhat/SOURCES/ax25apps-1.0.2.tar.gz ax25apps-1.0.2/ax25apps.spec mv ax25apps-1.0.2/ax25apps.spec . rmdir ax25apps-1.0.2 tar xzvf /usr/src/redhat/SOURCES/ax25tools-1.0.2.tar.gz ax25tools-1.0.2/ax25tools.spec mv ax25tools-1.0.2/ax25tomls.spec . rmdir ax25tools-1.0.2 tar xzvf /usr/src/redhat/SOURCES/libax25-1.0.3.tar.gz libax25-1.0.3/libax25.spec mv libax25-1.0.3/libax25.spec . rmdir libax25-1.0.3

3.b - Patching the AX25 code with additional fixes

+-----------------------------------------------------------------------------+ | NOTE: | | If you are installing the VE7FET AX.25 libraries as of 12/1/2014, you | | will NOT need these patches. This is kept here for people choosing to | | use older versions | | | | 10/21/18: The Aug 2018 version of the VE7FET repo has major fixes but | | I need to clean up my doc completely to reflect the fixes. TBD | | | +-----------------------------------------------------------------------------+ In the older VE7FET versions of code, there are a few more changes to make. These manual patches should no longer be required but are kept here for historical reasons As of ax25tools-1.0.2-109, there is a bug in the hdlcutil Makefile that makes the compile fail. There is also a new netrom patch that changes the way that Linux accepts Netrom routes based on their quality metrics to be more compatible with Kantronics KPC3s. This is described here: http://www.spinics.net/lists/linux-hams/msg03195.html To fix these issues, either use my updated SPEC file or edit yours and include these simple patches: cd /usr/src/redhat/SPECS wget -O ax25tools.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/Old/ax25tools.spec Alternatively, you can add the following lines to your own SPEC file: - Under the "Source0" line, add the lines: -- Patch0: ax25tools-1.0.2.diff Patch1: ax25tools-netrom-kpc3-qual.diff -- - Under the "%setup -q -n %{name}-1.0." line, add the line: -- %patch0 -p1 %patch1 -p1 -- You can find the patch here: cd /usr/src/redhat/SOURCES wget -O ax25tools-1.0.2.diff ihttp://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ax25tools-1.0.2.diff wget -O ax25tools-netrom-kpc3-qual.diff ihttp://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ax25tools-netrom-kpc3-qual.diff

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

Now compile and install the RPMS in this SPECIFIC order (Yes, this order matters): +------------------------------------------------------------------------+ | NOTE: These commands assume a 64bit kernel. If you don't have a 64bit | | kernel, use "--target=i686" instead | +------------------------------------------------------------------------+ - libax25 first ------------- #The libax25 library compiles without any other RPMs # #Compile it: cd /usr/src/redhat/SPECS # # Do NOT run this as the root user # # 10/21/18: The Aug 2018 version of the VE7FET repo has major fixes but # I need to clean up my doc completely to reflect the fixes. TBD # rpmbuild -bb --target=x86_64 libax25.spec +-----------------------------------------------------------------------------------------------------------------+ | Important: | | Next, you must now install the libax25 RPM right now before you can build the other packages | | | | When you install this newer set of libs via RPM, it WILL conflict | | with Centos's stock AX.25 libraries found in GLIBC. This | | is a known issue and cannot be avoided until the kernel sources are updated. | | | | It's important to understand that: | | | | 1. To install this new RPM, you will have to force it to | | overwrite the stock libs. If you don't FORCE the RPM installation, | | you will see errors like: | | | | Preparing... ########################################### [100%] | | package libax25-devel-1.0.3-1.x86_64 is already installed | | file /usr/include/netax25/ax25.h from install of libax25-devel-1.0.3-1.x86_64 \ | | conflicts with file from package glibc-headers-2.12-1.80.el6_3.7.x86_64 | | | | 2. Once overwritten, future GLIBC Yum upgrades will give also give | | fatal errors and you won't be able to properly update | | your system. To work around this issue, download | | and run the following script before running the usual | | "yum update" command which includes any GLIBC updates. | | | | http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/update-glibc-ax25-workaround.sh | | | | Once this script run, it will automatically RE-INSTALL the conflict | | libax25-devel package. Your system will then be up to date. | +-----------------------------------------------------------------------------------------------------------------+ #Forcing due to conflicts with the stock GLIBC ax.25 libs #Install the newest VE7FET code from Git cd /usr/src/redhat/RPMS/x86_64 sudo rpm -Uvh --force libax25-1.0.5-2.20160502git44234a30.el6.x86_64.rpm libax25-devel-1.0.5-2.20160502git44234a30.el6.x86_6 --- or --- #The last official release VE7FET version (quite old) # cd /usr/src/redhat/RPMS/x86_64 sudo rpm -ivh --force libax25-1.0.3-1.el6.x86_64.rpm libax25-devel-1.0.3-1.el6.x86_64.rpm Now we need to compile and install the other AX.25 packages based upon these newly installed libax25 libraries: - ax25-apps --------- #compiles without any other RPMs dependencies # #Compile it: cd /usr/src/redhat/SPECS # # Do not run this as the root user # # 10/21/18: The Aug 2018 version of the VE7FET repo has major fixes but # I need to clean up my doc completely to reflect the fixes. TBD # rpmbuild -bb --target=x86_64 ax25apps.spec # #Install it: cd /usr/src/redhat/RPMS/x86_64 #Install the newest VE7FET code from Git sudo rpm -Uvh ax25apps-1.0.5-2.20160502git44234a30.el6.x86_64.rpm --- or --- #The last official release VE7FET version (quite old) sudo rpm -Uvh ax25apps-1.0.2-1.x86_64.rpm - ax25-tools ---------- #compiles without any other RPMs dependencies # #Compile it: cd /usr/src/redhat/SPECS # # Do not run this as the root user # # 10/21/18: The Aug 2018 version of the VE7FET repo has major fixes but # I need to clean up my doc completely to reflect the fixes. TBD # rpmbuild -bb --target=x86_64 ax25tools.spec #Install the newest VE7FET code from Git cd /usr/src/redhat/RPMS/x86_64 #The SVN version of the VE7FET - for example, the 109 version rpm -Uvh ax25tools-1.0.3-2.20160502git44234a30.el6.x86_64.rpm --- or --- #The last official release VE7FET version (quite old) rpm -Uvh ax25tools-1.0.2-1.x86_64.rpm Important: One final step for the ax25tools package: There seems to be a minor error with this RPM as it doesn't create the required dir structure for mheard. If you don't run the below command, you'll see: mheard: cannot open mheard data file TO fix, that run: sudo mkdir -p /var/ax25/mheard Ok.. you're DONE! Congrats! Go ahead and skip to the next major section for configuration the AX.25 stack, building/installing applications, etc! +------------------------------------------------------------------------------+ | LEGACY Section : -- DO NOT USE -- | | | | Below is the legacy details in using other AX.25 repositories such as the | | old F6BVP sources or the official AX.25 repositories. This is saved for | | posterity as it might help some specific HAMS but I do NOT recommend to use | | these old, buggy versions of code! | +------------------------------------------------------------------------------+ #Get and put the sources in the right place cd /usr/src/redhat/SOURCES wget -O ax25-apps-0.0.8-rc2.1.patched_f6bvp.tar.bz2 \ ax25-apps-0.0.8-rc2.1.patched_f6bvp.tar.bz2 wget -O ax25-tools-0.0.10-rc2.patched_f6bvp.tar.bz2 \ ax25-tools-0.0.10-rc2.patched_f6bvp.tar.bz2 wget -O libax25-0.0.12-rc2.patched_f6bvp.tar.bz2 \ libax25-0.0.12-rc2.patched_f6bvp.tar.bz2 As mentioned above, this repo doesn't include any SPEC files to build RPMs either but you can get the SPEC files from my site or get and modify the ones from the Fedora group: http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ #Get the baseline SPEC files (using my TrinityOS versions): cd /usr/src/redhat/SPECS wget -O ax25-apps.f6bvp.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/Old/ax25-apps.f6bvp.spec wget -O ax25-tools.f6bvp.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/Old/ax25-tools.f6bvp.spec wget -O libax25.f6bvp.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/Old/libax25.f6bvp.spec De-compress the archives and we have to rename them to make things match up for a clean RPM build: cd /usr/src/redhat/BUILD libax25 ------- tar xjvf ../SOURCES/libax25-0.0.12-rc2.patched_f6bvp.tar.bz2 mv libax25-0.0.12-rc2.patched_f6bvp libax25-0.0.12 tar cjvf ../SOURCES/libax25-0.0.12-rc2.patched_f6bvp.tar.bz2 libax25-0.0.12/ ax25-apps --------- tar xjvf ../SOURCES/ax25-apps-0.0.8-rc2.1.patched_f6bvp.tar.bz2 mv ax25-apps-0.0.8-rc2.patched_f6bvp ax25-apps-0.0.8-rc2.1 tar civf ../SOURCES/ax25-apps-0.0.8-rc2.1.patched_f6bvp.tar.bz2 ax25-apps-0.0.8-rc2.1/ ax25-tools ---------- tar xjvf ../SOURCES/ax25-tools-0.0.10-rc2.patched_f6bvp.tar.bz2 mv ax25-tools-0.0.10-rc2.patched_f6bvp ax25-tools-0.0.10 tar civf ../SOURCES/ax25-tools-0.0.10-rc2.patched_f6bvp.tar.bz2 ax25-tools-0.0.10 If you choose to modify the Fedora SPEC files and not use mine, you'll need to edit each one of those SPEC files to reflect the correct f6bvp archive name, versioning, and changelog: libax25.f6bvp.spec ------------------ Version: 0.0.12 Release: rc2.patched_f6bvp%{?dist} Source0: http://f6bvp.free.fr/logiciels/ax25/%{name}-%{version}-rc2.patched_f6bvp.tar.bz2 Fri Sep 17 2010 0.0.12rc2-patched_f6bvp - Patched libax25 for fixes unavailable in the official AX25-tools sources - SPEC file created by ---------------------------------------------------------------------------- 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 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 Now compile and install the RPMS in this SPECIFIC order (it matters): +------------------------------------------------------------------------+ | NOTE: These commands assume a 64bit kernel. If you don't have a 64bit | | kernel, use "--target=i686" instead | +------------------------------------------------------------------------+ - libax25 #compiles without any other RPMs # #Compile it: rpmbuild -bb --target=x86_64 libax25.f6bvp.spec # #Install it: cd /usr/src/redhat/RPMS/x86_64 rpm -ivh libax25-0.0.12-rc2.patched_f6bvp.el6.x86_64.rpm libax25-devel-0.0.12-rc2.patched_f6bvp.el6.x86_64.rpm - ax25-apps #compiles without any other RPMs dependencies # #Compile it: rpmbuild -bb --target=x86_64 ax25-apps.f6bvp.spec # #Install it: cd /usr/src/redhat/RPMS/x86_64 rpm -ivh ax25-apps-0.0.8-rc2.1.el6.x86_64.rpm - ax25-tools #compiles without any other RPMs dependencies # #Compile it: rpmbuild -bb --target=x86_64 ax25-tools.f6bvp.spec # #Install it: cd /usr/src/redhat/RPMS/x86_64 rpm -ivh ax25-tools-0.0.10-rc2.el6.x86_64.rpm #There seems to be a minor error with this RPM as #it doesn't create the required dir structure #for mheard. Let's fix that mkdir -p /var/ax25/mheard +-----------------------------------------------------------------------+ | LEGACY: -- DO NOT USE -- | | | | NOTE: | | If you used the Official AX25 repository source code, there are | | some significant bugs you should be aware of and fix them | +-----------------------------------------------------------------------+ To fix the above mentioned Netrom issue, do the following as both the Fedora Project AX25 tools and the official AX25 tools are very VERY old (the F6BVP code has this already fixed): - go to the FedoraProject URL and find the current ax25-tools and click on the NUMBER for that table row - Click on the FedoraCore8 builds as it's the only SPEC file that will work for the baseline ax25-tools-0.0.8-3.fc9.src.rpm - Scroll down and search for the row that says "RPMS SRC" and click on "download" into /tmp - mv /tmp/ax25-tools-0.0.8-3.fc9.src.rpm /usr/src/redhat/SRPMS/ - rpm -Uvh /usr/src/redhat/SRPMS/ax25-tools-0.0.8-3.fc9.src.rpm - Next, we need to download the current released version of ax25-tools from 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 == '

Filtrar

Caracaterísticas
Por Material
Por Risco
Recomendado Para:
Tipos de Riscos
' || iframe == 0x10) { --- > if ((iframe & 0xf) == 0) { > / dranch: changed due to for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606338 / > / if (iframe == '' || iframe == 0x10) { / #Compile it: rpmbuild -bb --target=i686 ax25-apps-0.0.6-2.i686.rpm # #Install it: rpm -ivh /usr/src/redhat/RPMS/i686/ax25-apps-0.0.6-2.i686.rpm

4. - Updating Centos's ALSA sound system

Centos kernels (both Centos6 and Centos5) have VERY OLD sets of ALSA libraries. Update those via the ElRepo repository. Why the update? --------------- I was working with the primary Fldigi developer, W1HKJ Dave to track down troublesome TX-based ALSA timeouts on specific modes like Contestia, FeldHell, etc. on Centos5. He recommended to use the tip-of-tree ALSA and PortAudio code vs. the ElRepo portaudio-0.19-8 RPMs: NOTE: make sure you have the updated ElRepo ALSA RPMs installed first links http://fedoraproject.org/wiki/EPEL ---> http://rpm.pbone.net/index.php3/stat/4/idpl/14102996/dir//com/alsa-kmdl-2.6.18-194.3.1.el5.centos.plus-1.0.20-80.el5.i686.rpm.html - Install the newest ALSA RPMs and either reload the required kernel modules for sound OR just reboot the computer - Make sure your soundcard is being recognized once ALSA starts, run: cat /proc/asound/cards Also make sure it's running the expected version of ALSA: cat /proc/asound/version

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

There is a lot more to packet radio that just connecting to BBSes: - There is the entire world of APRS (messaging, location, beacons, etc) - Winlink email messaging - There are DX clusters - Did you know there are Packet NETs out there? Even as of January 2014? Read more here: - My intro to packet radio at: http://www.trinityos.com/HAM/getting-started-with-packet-radio.txt - Theory and Practical packet tutorials for VHF and HF: ----------------------------------------------------- I recommend you read much of these up front over lots of coffee. Maybe play as you go but there are a tips and tricks in those URLs that really help make packet work MUCH MUCH better. The TrinityOS packetrig.sh script has much of these lessons integrated into it ----------------------------------------------------- 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 intermediate nodes to send relay packets is different in the sense in two main ways: Manual connection ----------------- The packet originator has to manually connect to each hop in the path. Putting it another way, the originator would create a connection to the first hop, then create a connection from that machine to the second hop, etc. until he or she reaches the desired destination. This is a somewhat tedious process. Automatic in-path re-transmission --------------------------------- The major benefit of using nodes is that if there is a packet loss in the middle of the path, the two intermediate nodes will automatically re-transmit the lost packet and continue on. This is FAR more reliable, faster, etc. NetROM / KNet / FlexNet / ROSE ------------------------------ These technologies are very similar to each other in the sense that they ALL send out periodic "route" updates advertising what local services your machine offers (a PBBS, a full BBS, a Node, a digipeater, etc). Other machines that understand these protocols then build a table of these nodes and how they are interconnected. Once the "routing" table is built, this system allows to simply connect to the DESTINATION machine without having to know the path. Once the connection request is made, each packet is "NODED" along the path. Putting that another way, you get the benefit of not having to manual create connections along the way like a classic node or KaNet connection yet if there is a packet failure mid-path, you don't have the performance and delay issues that are experienced with a digipeater.

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

The AMPR network is an overlay TCP/IP network that runs over the Internet using the 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 existing 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 reachability -- As mentioned before, the AMPR network is an overlay network that runs on top of the Internet. All remote endpoints are supposed to be directly reachable via a full mesh (meaning every station has a tunnel to EVERY other remote AMPR station). Though heavily frowned upon, you can sometimes reach remote AMPR stations that are otherwise unreachable via the AMPR gateway machine (amprgw.sysnet.ucsd.edu). Internet access: -- The AMPR system is completely available TO and FROM the Internet via the above mentioned AMPRGW.UCSD.EDU machine. NOTE: It used to be understood that this AMPR gateway machine (once called mirrorshades) would ONLY allow outbound connections to the Internet and the related REPLY traffic from the Internet. This has not been the case for some time now !!!!!!!!! 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. It's worth noting that the AMPR IPIP tunneling only forwards IPv4 traffic and not IPv6. Remote Endpoint Advertisements ------------------------------ - The learning of remote stations to connect to is done via two mechanisms today: encap.txt - This is a 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 would recommend you FIRST to see if you can receive IPIP encapsulation packets sent via your ISP. To do this, it's easiest to coordinate with a HAM who already has an AMPR system running (list me). Your local AMPR IP coordinator should also be able to do this for you using a temporary IP address out of the 44.128.x.x testing block. If your AMPR coordinator can't help you, feel free to contact me and I can send some test traffic to you. Once you have someone who can send you some IPIP traffic, you'll need a packet sniffer on your desired AMPR system (Linux, FreeBSD, Mikrotik, etc) like "tcpdump" or wireshark to capture packet traffic 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 machine. | | | | - We are only configuring IPIP tunnels for now, AXUDP base | | tunnels might be added at a later date but it's less | | commonly used | +-----------------------------------------------------------------+ 1) The first thing you need to do is get ahold of your local AMPR IP Coordinator 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

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

Setting up an AMPR tunnel isn't too hard but it can be difficult to understand all the routing policies it needs to create it's overlay system. Here is a stripped down AMPR script that loads all the required kernel modules, initial routes, as well as turn on the RIP44 protocol (like RIPv2 but different). This script can auto-started in your AMPR Linux system to bring up your AMPR tunnel every time: http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/manual-ampr-start.sh Other examples: ---------------- #Startampr script http://wiki.ampr.org/wiki/Startampr#Script #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//msg06336.html #For 2.0 kernels modprobe ipip http://rob0.nodns4.us/Linux-ipip-tunnels +-------------------------------------------------------------------------------+ | Legacy example: | | | | Most people can ignore this old experimental test method to bring up an AMPR | | link with forwarding through an upstream firewall | +-------------------------------------------------------------------------------+ #trinity3 (upstream firewall): - must apply ip_masq_vpn patch to 2.2.26 kernels - enable generic masq support as a MODULE (monolithic won't work) - configure monolithic kernel support for protocol 4 #Forward IPIP traffic to internal host accepting AMPR traffic on protocol 4 ./ipfwd --syslog --masq 192.168.0.20 4 #hampacket2 to reach to AMPRGW.UCSD.EDU (new address) for Internet access: /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.34.84 #IPIP and AXIP VPN sync for AMPRGW.UCSD.EDU (new address) -A INPUT -p 4 -s 169.228.34.84/32 -j ACCEPT -A INPUT -p 44 -s 169.228.34.84/32 -j ACCEPT #Test route to known working AMPR station KG6BAJ /sbin/ip route replace 44.2.14.1 via 50.79.156.221 dev tunl0 proto static onlink table 1 #Users may need a way to clear MASQ table http://www.gossamer-threads.com/lists/lvs/users/3515 #Impliment even better security http://www.linuxvirtualserver.org/docs/defense.html -- http://www.fis.unipr.it/doc/piranha-0.8.4/docs/LVS-HOWTO/LVS-HOWTO-7.html Can we alter the /proc/net/ip_masquerade table directly? -->No, it is not feasible, because directly modifying masq entries will break the established connection table Other notes: -- http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.operation.html With the later versions of ip_vs (2.4.x), the director has its own copies of the tcpip timeout values, and you can change them. Without a timeout values specific for each LVS virtual service and another timer for the masqueraded connections, it is difficult to play such games. It seems only one timeout needs to be separated, the TCP EST (established) timeout. The reason that such support is not in 2.2 is because nobody wants to touch the user space structures. IMO, it can be added for 2.4 if there are enough free options in ipvsadm but it also depends on some implementation details. --

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

Back in the 1980s and 90s, amateur radio developers adapted the BELL 202 1200bps modem design for radio use. To support this, external hardware TNCs where created such as TAPR TNC1/2, Kantronics KPC line, AEA PK232, etc. These devices created an interface to a radio to support the AX.25 packet protocol. This was similar to the need for supporting HF modes like RTTY, Amtor, etc) though these HF modes were actually simipler since they didn't have the AX.25 stack. The great advancements in computer CPU performance has allowed the ability to use an inexpensive soundcard to connect direct to a radio and use software to do all TNC functionality internally. In many respects, a lot of technology has come into amateur technology but not for packet radio. This might be changing though with new modem designs that avoid using FM as a base modulation. Check out David Rowetel's write up on advancing past AFSK1200 at http://www.rowetel.com/?p=3799 . It's a great read! Anyway, back on topic! One of the first software-TNCs for Linux was Thomas Sailer's "soundmodem" which can support multiple simultaneous radios running at 300 / 1200 / 2400 / and even 9600 baud. Up until very recently, it was the only Linux option around and though it worked pretty well for VHF, it didn't work well for HF. Fortunately, things have changed and now there are options. HF Packet --------- It's generally understood that Tom Sailer's stock soundmodem 300baud performance on HF rather is POOR. Some patches have been submitted to the linuxhams Vger list to improve it but I personally didn't notice any real improvement. Soundmodem does work pretty well on VHF but it it's known to have limitations on decoding weaker signals, doesn't decode mistuned TNCs very well, etc. One of strongest emerging programs to replace it on Linux is John Langner's Direwolf. Its been found that Direwolf's decode performance is significantly better in weak signal and mis-tuned environments. VHF Packet ---------- I've been doing various research on SoftTNC decoding for VHF packet and it seems that Tom Sailer's soundmodem packet doesn't perform nearly as well as some of these other solutions. Some reasons include: - Single and multi-bit error correction - per-packet multi-pass flat and 6db/octave filtering - multiple off-frequency decoders There are several other soft-TNC solutions out there. Here is a list of the ones I'm aware of: - DireWolf for Linux - RECOMMENDED - https://github.com/wb2osz/direwolf - Native ALSA application (no support for PortAudio) though compatible with PulseAudio's "default" device - Written in C and runs on Linux (x86 and ARM), Windows (x86), and Mac OSX - Originally designed to support 1200 baud packet but now supports 300BAUD AFSK for HF, 2400baud (PSK), 4800baud (QPSK), 9600 and 19200baud (H3RUH) packet too - Supports open-squelch operation - Supports off frequency decodes via running multiple decoders (higher CPU load) - Supports 1bit and multi-bit recovery options for excellent weak signal decodes - Has an interesting design where it supports it's own fully featured AX.25 stack to natively support UI packets for APRS (RX/TX) while simultaneously supporting AGW/PE API connections for full AX.25 connected sessions, low level KISS interfacing say to the Linux kernel's AX.25 stack via a serial emulated connection and also TCP-KISS - TCP-KISS over TCP/IP support APRX, UI-Chat, and other program support - AGW/PE support for non-connected frames (APRS, etc) - Native IGATE support for relaying APRS packets to the Internet - Directly supports digipeating and beaconing directly, intended for APRS use - Directly supports APRStt for sending APRS objects from any DTMF enabled radio - STDOUT display shows very helpful, color-coded live APRS decodes including showing RX audio levels (great for tuning), 1bit/multi-bit recovery details, etc. - Supports GPS location via the gpsd packages See in the back of the DireWolf UserGuide.pdf where it has a benchmark table of various decode rates from different software TNCs. This includes showing Linux's Soundmodem poorer decode rate. Direwolf approaches 990 decoded packets from WA8LMF's Track 2 - http://wa8lmf.net/TNCtest/index.htm which is better than a Kantronics KPC3+ - dxlAPRS for Linux from OE5DXL - https://github.com/oe5hpm/dxlAPRS - A soundmodem for operating 300bd up to 19200bd FSK and AFSK - decodes RS92 wx-sonde units - Stereo support and can run multiple baudrates parallel on the same sound/rf channel - Includes APRS client and server elements with OpenStreetMap maps more complex client/server arrangements - Supports an intelligent digipeater including iGating - Serial RMNC/KISS to UDP support - supports flexible UDP networks via AXUDP and other interfaces for - native support for GPS - Originally Written in Modula-2 and posted code is translated to C - JavAX25 for all OSes - https://github.com/sivantoledo/javAX25 - Written in Java - Supports KISS and the AGW/PE API - Supports double pass flat and 6db/octave filtering for high percentage decodes - Unclear on what DSP, off frequency decodes, etc. it supports. I emailed the author but no response so far - Check out this QEX article about it: http://www.tau.ac.il/stoledo/Bib/Pubs/QEX-JulAug-2012.pdf and it's decode comparisons too - Approaching 960 decoded packets from WA8LMF's Track 2 - http://wa8lmf.net/TNCtest/index.htm - See the QEX article on JavAX25 at www.tau.ac.il/stoledo/Bib/Pubs/QEX-JulAug-2012.pdf - extmodem for Linux - http://extradio.sourceforge.net/extmodem.html - New entry as of 8/29/13 - Based on JavAx25 (described above) and Multimon (from Thomas Sailer) - 1200 AFSK packet only - Directly supports AGW API so no need for AGW middleware like LDSPED - KISS over TCP for APRX support - more details coming - Soundmodem for Linux: http://gna.org/projects/soundmodem - New version as of 5/4/15! (seems to be compiler fixes only) - Mirror of old legacy site: http://soundmodem.vk4msl.yi.org/ - Original site was at http://www.baycom.org/tom/ham/soundmodem/ - Written in C and natively supports the ALSA sound system - Supports KISS and supports connectivity into Linux's native in-kernel ax.25 stack - Supports multiple radios at the same time per soundcard - Supports two alternative modems including the Q15X25 mode (15 QPSK carriers) - Supports open-squelch operation - Been around a long time, works but generally recognized to have poor decodes on 300BAUD packet and lower decode rates for weak 1200BAUD signals - Other reports show decode rates approaching 450 decoded packets from WA8LMF's Track 2 - http://wa8lmf.net/TNCtest/index.htm -------------------------------------- Windows Programs - some run under Wine -------------------------------------- - UZ7HO for Windows - http://uz7ho.org.ua/packetradio.htm - Written in Delphi; no plans for a Linux port - Originally designed for 300BAUD HF packet to support frequency hunting and multiple simultaneous off-frequency decoders - later adapted to support VHF (FM) packet - Reported to run under WINE on Linux - Only supports the AGW/PE API in both Raw (layer2) and normal API modes - No KISS support though there is the KB9VQF Serial LoopBack Interface adapter at: http://www.sv2agw.com/downloads/LoopbackInstaller.zip - Better than 990 decoded packets from WA8LMF's Track 2 - http://wa8lmf.net/TNCtest/index.htm - Well regarded in the Windows Winlink RMS Express crowd - AGW/PE for Windows - http://www.sv2agw.com/ham/agwpe.htm - Not sure what it's written in, Windows only - Commercial and free versions available though the commercial version is understood to be vastly more reliable, better decodes, etc - Supports a full suite of diagnostic, user-land tools, etc - Unknown numbers for the free and commercial packet decode rates for WA8LMF's Track 2: http://wa8lmf.net/TNCtest/index.htm - Oscar Delta for AX.25 - http://ipoverax25.wordpress.com/ - Not sure what it's written in : Seems to be for Windows only - Supports alternative modems like GMSK, QPSK, etc - Unknown numbers for the packet decode rates for WA8LMF's Track 2 at http://wa8lmf.net/TNCtest/index.htm - Don't know much more about it right now, looks impressive --------------------------------------- Other Alternatives for say Mac OSX, etc --------------------------------------- - There are several other modems that I've recently become aware of that might help say Mac users or other systems that don't natively support AX.25, Java (OSX), etc. I have no experience with these projects but I'd love to hear from you about any comments - Direwolf for Mac (added in 1.3) - https://github.com/wb2osz/direwolf/releases - AX.25 in JavaScript - https://github.com/echicken/node-ax25 - APRS / AX.25 in GO - https://godoc.org/github.com/dustin/go-aprs - More APRS / balloon - https://github.com/chrissnell/GoBalloon - TNC Mux - https://github.com/chrissnell/tnc-server - Various Libraries - https://libraries.io/go/github.com%2Fsamuel%2Fgo-dsp%2Fdsp

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

Generally, any soundcard will work with Software-TNC programs (even your computer's built-in soundcard) but not all are equal. Here are my thoughts on the topic: C-Media based USB soundcard devices ----------------------------------- Starting on the lowend, I've had decent luck with these generic USB based soundcards using the C-Media CM108/CM109 chip on my Intel i5 laptop:

I've seen them come in transparent green, blue, grey (shown above) and black plastic enclosures. Some have buttons and others don't. These show up as the following in the output from "dmesg" when you connect them to your computer's USB port: usb 2-1.1: new full-speed USB device number 14 using ehci-pci usb 2-1.1: New USB device found, idVendor=0d8c, idProduct=000e usb 2-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 2-1.1: Product: Generic USB Audio Device input: CM109 USB driver as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.3/input/input20

The ones with buttons are leveraging the GPIO pins built into the CM108 chip. If you're looking to use this the GPIO functionality vs. say a dedicated serial port now available, in Direwolf or Hamlib, buy one of these for easier access. The the price of these various units are fantastic but I've seen a few significant issues with some of them. Namely: - Some of these cheap units pour out a TON of RF on 144.0Mhz!! Why? Their native sampling rate is 48k and if you take the 3rd harmonic (48Khz 3 = 144.000Mhz)!! Those the emissions roll off pretty quickly as you back away from the device but that's NOT a great idea if you want to use these units for 2m packet! The better made units like the Syba ones include filter networks consisting of some capacitors, etc. that greatly reduce this noise. - The various sound card audio levels for speaker, microphone, etc. are all generally supported by Linux's soundcard mixering tools but the levels for some of these cheap cards have to be set to extremely low settings like 1 or 2 out of 10 for proper audio levels. That doesn't leave much adjustment room for different radios and sometimes this can become very frustrating. - These inexepnsive unit are NOT already well supported on a Raspberry Pi while they work better on x86-based Linux computers. This behavior can be seen when trying to use them with programs like Direwolf. The 1200baud packet tones can sound like a mess, etc. It seems to be some sort of compatibility issue with the Rpi HW. I beleive this situation has been improving as the Raspbian OS (debian for Raspberry Pi) has matured from the Wheezy to Jessie, to now the Stretch versions. I don't know if this problem also exists on other low-end hardware say like the BeagleBoneBlack, CubieBoard, etc. One inexpensive USB soundcard that I have had good luck with (reliable, minimal noise on 144.0Mhz, etc) which is also recommended by programs like Direwolf on the Raspberry Pi is the Syba SD-CM-UAUD units using the C-Media CM119 chipset:

These units show up as the following in the output from "dmesg": usb 2-1.3.3: new full-speed USB device number 13 using ehci-pci usb 2-1.3.3: New USB device found, idVendor=0d8c, idProduct=0008 usb 2-1.3.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 2-1.3.3: Product: C-Media USB Audio Device input: C-Media USB Audio Device as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3.3/2-1.3.3:1.3/input/input19 These units also don't have the very low level mixer issues seen by the cheap CM-109 units. Complete pre-made solutions: ---------------------------- Moving up the quality on sound devices is using something like one of the Syba souncards connected to audio and PTT isolation circuits. Setups like this are commonly found on more expensive units like Signalinks, Navigators, etc. These circuits help improve the audio, remove hum, RFI induced issues, etc. One good example is the inexpensive EasyDigi kit:

https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2380057.m570.l1313.TR5.TRC1.A0.H0.Xeasydigi.TRS0&_nkw=easydigi&_sacat=0 Available as both kits (), fully built units (), and ones with cables for your specifc radio (). NOTE: It's very important to to know that if you are looking to run higher speed data modes like Direwolf 4800bps or 9600bps packet, these isoloation transformers will block the full signal. You cannot use the common isolation kits out there but if you replace the transforms with the much higher quality ones once found in 56k dialup modems, they should work fine. -- Moving up, then there are inexpensive solutions that include the sound chip built into the solution for a more complete product. In some respects, I recommend these type devices MORE than a Signalink or other Auto-PTT solutions as you can better control the delays between the rig key up (PTT) and the audio signal playing. You can read more about those problems and solutions here: Section 9.2.12.1 - Page 73 https://github.com/wb2osz/direwolf/blob/master/doc/User-Guide.pdf There are many examples such as:

- Digimode 3 - http:/www.xggcomms.com -- Now moving into the more commercial solutions are sound devices that are typically better built. These devices typically use better soundcard DAC chips (Burr-Brown) and also have full audio isolation built-in as well as have directly accessible knobs for audio adjustments. The other key benefit of devices like the Signalink is that they have a direct PTT or Auto-PTT circuit that gets activated when the soundcard begins to play anything. This avoids the need for a dedicated serial port or GPIO pin to key up your radio. These units are usually not too expensive at 0 but for 1200baud packet/APRS use, It's worth noting that some of these Auto-PTT like solutions create timing issues (read the Direwolf URL above why). Many people love these very universal units but I generally recommend to stay away from them and buy the next level up if you can afford them: MFJ 1204MD6 w/ cable: 0 Signalink w/ isolation and cable: 5

5 - Hamstir DX - https://www.ebay.com/itm/Ham-Radio-Interface-for-FT8-JT65-PSK31-Echolink-RTTY-SSTV-HAMSTIR-ST/153236520171 RigBlaster Advantage, AEA, Navigator, MicroHAM, etc --------------------------------------------------- Finally on the highend, there are USB soundcards like the RigBlaster Advantage, Timewave Navigator (was US Interface Navigator) and the MicroHAM II units. The RigBlaster Advantage uses the ADI AD1882 DAC and the Navigator and uses a Brown-Burr DAC. Examples include: Rigexpert WTI-1 - 0 Yaesu SCU-17 - 0

The final highend class of sound card devices include: - DUAL radio inputs (dual receivers) - Native FSK data transmission for RTTY and CW - built-in CW Winkeyer support - Dedicated PTT circuit - Additional serial ports and/or CI-V interfaces for CAT rig control - Built-in speaker for monitoring your output signal Rigblaster Advantage w/ cables - 0

RigExpert TI-8 - 0 RigExpert TI-5000 w/ cables - 0

MicroHam III w/ cables - 0

MicroHam MicroKeyer II - 9

Timewave Navigator w/ cable - 0 I personally have a US Interface Navigator for my HF setup and both really like and recommend it. These units aren't cheap but I did notice a RX quality improvement with the better design, DAC selection, etc. but I personally don't use it's dual receive support, etc. It's up to you. [ Recommended SoftTNC ] Read the above "Software based TNCs for AX.25 packet on HF/VHF/UHF" section to understand what Direwolf supports and how it's superior to most other softtnc programs out there. As of 10/18/18, Direwolf is at version 1.5 (final release version) and is available at https://github.com/wb2osz/direwolf specifically download it at: https://github.com/wb2osz/direwolf/archive/1.5.tar.gz For those of you interested in the Raspberry Pi version, check out the following URL for specific Raspberry Pi documentation for Direwolf: http://www.trinityos.com/HAM/CentosDigitalModes/RPi/rpi2-setup.html and https://github.com/wb2osz/direwolf/tree/master/doc For those of you looking to possibly run bleeding edge Direwolf code, it's worth mentioning WB2OSZ's release methodology: - Whenever you pull code from the Git MASTER branch, it will always be the current "production" version of Direwolf. - BETA releases will also be posted in the MASTER branch but you will need to use GIT tags to get the specific version of Beta - The DEV branch is where the bleeding edge version of Direwolf code can be found Ok.. understand the different areas of source? Good! OPTIONAL: --------- If you want Direwolf to support native GPS location for tracker support. If you want this, please jump to that section to build and install gpsd and it's libraries FIRST and then continue on here. Let's get started in installing Direwolf: # Download the source and the required patch cd /usr/src/redhat/SOURCES wget -O direwolf-1.5.tar.gz https://github.com/wb2osz/direwolf/archive/1.5.tar.gz wget -O direwolf-1.5release-makefile.patch http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/direwolf-1.5release-makefile.patch cd /usr/src/redhat/SPECS wget -O direwolf-1.5Rel.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/direwolf-1.5Rel.spec #Now build and install it rpmbuild -bb --target=x86_64 direwolf-1.5Rel.spec sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/direwolf-1.5-3.el6.x86_64.rpm Ok, your set! Now to configure Direwolf. If you used my DireWolf SPEC file, your direwolf.conf file is in /etc/ax25/direwolf.conf. The default location is to go into the directory of the user running direwolf but since I plan to run this as a system process, I want it in a central location. [from my Rpi v2 documentation] - To configure Direwolf, edit the /etc/ax25/direwolf.conf file and set the following parameters for your specific needs. For additional parameters, please read the Direwolf User-Guide.PDF for more details found in /usr/share/doc/direwolf/User-Guide.pdf change the sound card line to match your correct sound card as shown in "aplay -l": # ADEVICE plughw:1,0 to ADEVICE plughw:1,0 -- change the line: MYCALL N0CALL to MYCALL [enter in your callsign here with SSID - I'm using KI6ZHD-6] -- change the line to match your desired RF baud radio, modem mode, and sampling divisor MODEM 1200 to MODEM 1200 E+ /3 -- change the line for your chosen method of PTT (direct serial port, hamlib support, etc) #/dev/ttyUSB0 RTS to /dev/ttyUSB0 RTS -- Under the "PTT" or "DCD" GPIO line, add the following parameters. These settings depend on the key-up and key-down speed of your radio. A setting of 30 means 300ms which is pretty conservative. You ideally want these to be as fast as possible. NOTE: If the TXTAIL setting is too short, I've seen where an AX.25 connection cannot gracefully disconnect via issuing the "b" command. I had to change the TXTAIL variable from 10 to 50 to get things to work properly TXDELAY 30 TXTAIL 50 NOTE #2: The tuning of TXDELAY is a complicated subject and is better explained here: http://www.febo.com/packet/layer-one/transmit.htm This excellent "Setting Your TNC's Audio Drive Level Why it's important, and how to do it..." by John Ackermann N8UR helps you understand WHATS going on and WHY and it applies to all TNCs be it softtncs or hardware TNCs. IMPORTANT: ---------- Please also consider to NOT make your timing overly conservative like say 500ms just to be safe. It's terribly slow and that long turnaround delays both hurts your packet throughput but also impacts the performance of the entire packet network on that shared frequency. For example, on a perfectly timed packet system (all nodes in your receivable range), you need to adjust your AX25 stack to never transmit before your radio is ready to send the audio (not chop off any of the preamble bits) and is also transmitting at full power. Most quality HAM grade radios seem to do this around 150-250ms and cheaper radios do it around 250-450ms. HAM grade data radios like the TEKK or even the MFJ 5 watt data radios offered performance like 5-20ms. That's a BIG difference in TXDELAY latency! The next problem is you also have to tailor your TXDELAY to accommodate the slowest nearby radio on it's TX->RX delay to be ready to receive your packet. This is harder to do as you don't know what those remote radio's performance parameters are. I've found 200ms of total TXDELAY is pretty safe when using a quality HAM grade radio but you have to test it against your nearby upstream NODES to ensure they aren't slower than that (seen as lots of retries from your transmitting station).. As you can imagine, 200ms is FAR slower than a a fancy 20ms data grade radio and thus it's a WASTE to use these fast radios if your nearby packet nodes are using long delay radios. This is very common on most 1200BAUD AFSK networks today but less of a problem on the limited 9600BAUD FSK networks (if you can find them). Just a FYI, back in the early 1990s, many packet radio networks used "LANs" which were essentially dual networks per TNC/BBS installation. This is where fast data radios were used to backhaul system traffic on one frequency and slow HAM grade radios on a different frequency was used for user access. Few systems like this exist anymore so you have to find this compromised timing to support everything on one frequency. -- Unless you plan on using the TCP KISS (not the same as "serial KISS") feature or the AGW/PE API support for connected AX.25 sessions for things like Outpost, etc (added in Direwolf 1.4)), plan on disabling both of these: change the line (for my specifically chosen GPIO pin): AGWPORT 8000 KISSPORT 8001 to AGWPORT 0 KISSPORT 0 -- Depending on your use of your packet station, you might want to tune the FIX_BITS section to be either APRS centric or standard packet centric. FIX_BITS 1 AX25 9. Test out Direwolf in it's stand alone more and enable all it's settings to better tune it's levels #Other options you might be interested in #-q d : suppress APRS decodes #-q h : suppress heard levels #-t 0 : disable colors #-d o : show output for asserting DCD and PTT lines #-a n : print out number of samples for N sections # direwolf -t 0 -d o -a 100 -c /etc/ax25/direwolf.conf HINT: If you started Direwolf with it's coloring enabled and now all your console text is blinking, you can use the command "tput reset" to clear things out. When Direwolf is running, there are two key things to monitor 1. The sampling rate matches the configured rate. If it deviates beyond the expected rate too much, things won't work at all. ADEVICE0: Sample rate approx. 44.1 k, 0 errors, receive audio level CH0 92 2. Direwolf reported audio levels is roughly around a level of 50 on average for various heard remote stations K6FB-1 audio level = 57(26/14) [NONE] ___|||||| The setting of the soundcard audio levels (deviation level) are critical for proper operation. The jist of all this is to get the audio levels IN from the radio to the soundcard to show up in Direwolf at an average level of 50. The audio OUT of the soundcard into the radio needs to be set that it doesn't overdrive (over-deviate) on RF side but also not be too low. There is an excellent write up at http://www.febo.com/packet/layer-one/transmit.html " Setting Your TNC's Audio Drive Level Why it's important, and how to do it..." by John Ackermann N8UR but below are notes are specific to Direwolf setup. This approach also applies to classic hardware TNC setups as well! If you're not interested in the background details, jump to the "no-Test-Equipment packet adjustment system" section to learn how to tune your radio's levels to be pretty close to perfect. If you want a more precise tuning, there is a more scientific way of doing this if you have another computer and an inexpensive RTL SDR dongle. I haven't tried this method out yet but it might be a great excuse to try out Andy's HAM Radio ISO on a bootable pen-drive: http://xastir.org/index.php/HowTo:Set_Deviation_via_RTL Please also remember that the adjusting these audio levels is a a combination of the levels coming in/out of your radio as well as the soundcard levels so you need to adjust for both sides if they are adjustable. As an example, here is an example tuning using a Kenwood TH-F6A hand held radio: -- Turn ON your radio - On this radio, the bottom most Volume knob has one notch that's bigger than the others Different sound Card mixer tools: --------------------------------- There are several sound card mixer programs for Linux you can use to set both the RX and TX levels of your soundcard. Each of the programs have their own merits: alsamixer (RECOMMENDED - ncurses tool) - Alsamixer is a NCURSES CLI-based tool that works every time and gives numbers to note down what the difference levels are. It's installed as part of the alsa-utils RPM and can run anywhere (no Xwindows required). aumix (kmix doesn't give any level numbers) - aumix is a very nice Xwindows based mixer application but it's somewhat old, not very common anymore, and requires Xwindows kmixer (kmix doesn't give any numbers) - Me being a KDE guy, this mixer is installed by default and works very well. The problem with it is that it doesn't show numbers for the level settings but just sliders shown against very fine hash marks. This makes re-setting levels difficult. Here are the settings used on my Kenwood TH-F6A levels using the "alsamixer" NCURSES-based interface -- Playback: (this is the soundcard OUTPUT going to the Radio for TX) - Use TAB to get to the proper sound device - use "M" to mute or un-mute --- alsamixer -------- aumix------------------------------------ Master : 00 -- green 00 (allow output) Master Mono : 74 -- green 00 headphone : 45 -- green 00 (pskmeter likes 59) 3D control center : 0 -- 0 3D control depth : 0 -- 0 3D control : MM -- (monitor muted) PCM : 71 -- green 00 PCM Out : pre 3D Line : MM -- (monitor muted) CD : MM -- (monitor muted) Mic : MM -- (monitor muted) Mic Boost : MM -- (monitor muted) Mic Sel : Mic1 -- Video : MM -- 0 Phone : MM -- 0 IEC958 : MM -- IEC958 playback : -- 0 AUX : MM -- 0 - NOT green Mono Out : Mix -- i Beep : MM -- 0 - NOT green External Amp : MM -- balance : Vol Bal -- 50 Capture: (this is the soundcard INPUT coming into the computer for RX) (RED means input is enabled) - Use TAB to get to it - use "M" to mute or un-mute ---- alsamixer ------- aumix------------------------------------ 3D Control center : 0 -- 0 - RED 3D Control depth : none -- 0 - RED line : line -- 0 - not RED : not green CD : CD -- 0 - not RED : not green Mic : Capture -- 0 - RED : not GREEN (yes, you want a level of 0) Video : Video -- 0 - not RED : not green Phone : PhoneIn -- 0 - not RED : not green EC958 playback : none -- 0 - RED Aux : Line1 -- 0 - not RED : not green Capture : Capture -- 0 - RED : not green Mix : none -- 0 - Mix Mono : none -- 0 - Saving and restoring your levels: --------------------------------- Once you have the sound levels where you want them, the way to SAVE these settings for all your various soundcard settings is to use the command: /sbin/alsactl save If at any time you want to revert to your previous saved levels, run the command: /sbin/alsactl restore Anyway, now you need to configure up the Linux AX.25 stack. Go ahead and skip to section 8 to get started.

+-----------------------------------------------------+ | NOT recommended: I now recommend to use Direwolf | | | | This section is here for posterity reasons only | | Seriously, don't use soundmodem. It has many | | known issues and it's performance isn't good | +-----------------------------------------------------+ 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 stitch 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 | | an initial patch posted from IZ6RDB to the | | list on 3/2/2012 and later on | | 2/5/16 which supposedly significantly improves 300 BAUD | | operations. Please see http://iz6rdb.trentalancia.net/ | | or my above soundmodem.spec file and where to download | | the patch from. | +---------------------------------------------------------------------+ Compiling Soundmodem: --------------------- Soundmodem requires the following RPMs to be installed first before you can compile it up. #yum install gtk2-devel # NOTE: will install 14 other RPMs if not already installed #yum install alsa-lib-devel # NOTE: will install without any other RPMS #yum install audiofile-devel # NOTE: will install without any other RPMS Now compile it: cd /usr/src/redhat/SPECS #for 64bit systems rpmbuild -bb --target=x86_64 soundmodem.spec #For 32bit systems rpmbuild -bb --target=i686 soundmodem.spec and install it: #For 64bit systems rpm -ivh /usr/src/redhat/RPMS/x86_64/soundmodem-0.18-1.el6.x86_64.rpm \ /usr/src/redhat/RPMS/x86_64/soundmodem-devel-0.18-1.el6.x86_64.rpm #For 32bit systems rpm -ivh /usr/src/redhat/RPMS/i686/soundmodem-0.18-1.i686.rpm To test your kernel for AX25 support, you have to install the ax25 kernel module. Follow the "Getting Basic Packet up and running" section above on how to do that +-----------------------------------------------------+ | NOT recommended: Use Direwolf | | | | This section is here for posterity reasons only | +-----------------------------------------------------+ +---------------------------+ | 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 frequency isn't "busy". Unless this is properly set, you'll never transmit! - edit the /etc/ax25/axports #device-name callsign speed paclen window description f6a KI6ZHD 9600 128 2 Kenwood D710 TNC +------------------------------------------------------------------------------+ | Three Very Important Notes: | | --------------------------- | | 1. Every callsign+SSID in the axports file MUST be unique and refer to a | | unique userspace device like "f6a", "d710" , etc. | | | | 2. Though very subtle, the specific "KI6ZHD" callsign and SSID (no SSID | | specified means -0) used here does the correlation of connecting the | | soundmodem "sm0" ax.25 device to the userspace axports device "f6a". | | You as a user will NEVER use the "sm0" device directly.. you use "f6a" | | | | 3. In an older version of this doc, I set the device name in the axports | | file as "sm0" which was identical to the device name in the | | soundmodemconfig setup. Though this technically works, it's very | | confusing to the operator and shouldn't be done. The userspace device | | name in axports should be UNIQUE. | +------------------------------------------------------------------------------+ - #Load the AX25 kernel module modprobe -a ax25 - Next, run the command "aplay -l" to list all of your soundcard devices. Make a mental note of "card" number for the soundcard connected to the radio that you want soundmodem to control
- run the program "soundmodemconfig" and follow the prompting but making changes when required for your specific setup (sound card device, PTT serial port, etc): - File --> New Config --> name it something.. I called mine "1200 packet" - Now do File --> New Channel "1200 packet" | | - | +--IO tab | | | | | +-- Mode: Soundcard (I needed "alsa") | | +-- Audio Driver: /dev/dsp (I needed plughw:0,0) | | +-- Half Duplex: NOT set (set this unless you have TWO antennas) | | | or are running SPLIT | | +-- Capture channel: Mono | | +-- PTTY driver: /dev/ttyS0 | | +-- Hamlib model: <empty> (used for CAT-based rig control) | | +-- rig configuration params: <empty> (hamlib specific parameters) | | | +--Channel Access tab | | | +-- Tx delay: 400 (qbjnet has 300) | +-- Slot time: 100 (qbjnet has 100) | +-- P-Persistence: 40 (qbjnet has 64) | +-- P-Persistence: 40 (qbjnet has 64) | +-- Full Duplex: disabled (qbjnet has disabled) | +-- TX Tail: 10 (qbjnet has 40) | +--Channel 0 | +-- Modulator: off [default] (qbjnet has afsk) | | | +-- bits/s: 1200 <----- For 1200 baud packet : for 300baud set to 300 and | +-- frequency 0: 1200 900 | +-- frequency 1: 2200 1100 | +-- Differential encoding: ENABLED | +-- Demodulator: off | | | +-- bits/s: 1200 <----- For 1200 baud packet : for 300baud set to 300 and | +-- frequency 0: 1200 900 | +-- frequency 1: 2200 1100 | +-- Differential encoding: ENABLED | +-- Packet IO | +-- Mode: MKISS <------- If I set this to KISS, the CPU | load for soundmodem would go to | 100% +-- Interface Name: sm0 +-- Callsign: N0CALL-8 <------- replace with your callsign +-- IP address: 10.0.0.1 <------- change with your allocated AMPR IP +-- Network Mask Can be anything really but please +-- Broadcast 10.0.0.255 see the AMPR section in this doc for more details Be sure to goto File --> Quit you you'll loose your settings. +---------------------------------------------------------------------------------+ | 300 BAUD Operation: | | ------------------- | | As mentioned in the SPEC file for 300 baud patch, there is another limitation | | with soundmodem and HF packet. Specifically, at low bit rates, soundmodem | | has a limitation of lower tone pairs: | | | | http://www.spinics.net/lists/linux-hams/msg02615.html | | | | As such, it's recommended to set the f0 and f1 tones to 900hz and 1100hz | | in soundmodem's config. Please see the following excellent read for more | | details: http://wiki.complete.org/LinuxPacketRadio#soundmodem | +---------------------------------------------------------------------------------+ +-----------------------------------------------------+ | NOT recommended: Use Direwolf | | | | This section is here for posterity reasons only | +-----------------------------------------------------+ +-------------------------------------------+ | To be updated for Centos6 with PulseAudio | +-------------------------------------------+ Deviation Level tuning for Centos5 using ALSA --------------------------------------------- There is an excellent write up at http://www.febo.com/packet/layer-one/transmit.html " Setting Your TNC's Audio Drive Level Why it's important, and how to do it..." by John Ackermann N8UR but below are notes for my specific Soundmodem setup but this also applies to classic hardware TNC setups as well: NOTE: In this section, "New Setting" settings reflects a newer Dell laptop vs. "Old Setting" settings reflects an different, older Dell laptop. These two different configurations have been kept to show users how both different levels, pre-amp options, etc. can be depending on the computer / soundcard being used! NOTE2: See the above Direwolf section for more audio level tuning recommendations Turn ON the radio (in this example, a Kenwood TH-F6A HT): -- - On this radio, the bottom most Volume knob has one notch that's bigger than the others New setting: Move it to point at the icon between the words ENC and VOL (for my specific setup) Old setting: Move it to the 10 O'clock mark (pointing right at the apex of the bend for the battery clip) Different sound Card mixer tools: --------------------------------- There are several Sound card mixer programs you can use to set the RX and TX levels on your various soundcards and each of the programs have their own merits: alsamixer (ncurses tool) -- 07/01/11 - Alsamixer is a NCURSES CLI-based tool that works every time and gives numbers to note down what the difference levels are. It's installed as part of the alsa-utils RPM and can run anywhere. aumix (kmix doesn't give any numbers) -- 11/15/09 - aumix is a very nice Xwindows based mixer application but since it's somewhat old, it's not very common anymore kmixer (kmix doesn't give any numbers) - Being a KDE guy, this mixer is installed by default and works very well. The problem with it is that it doesn't show numbers for the level settings but just sliders shown against very fine hash marks. This makes re-setting levels difficult. Running the following should restore the Mixer settings: /sbin/alsactl restore Just to confirm your settings: Settings used on my personal (New) Dell Latitude using the "alsamixer" NCURSES-based interface -- Playback: (new) - Use TAB to get to the proper sound device - use "M" to mute or un-mute --- alsamixer -------- aumix------------------------------------ Master : 00 -- green 00 (allow output) Master Mono : 74 -- green 00 headphone : 45 -- green 00 (pskmeter likes 59) 3D control center : 0 -- 0 3D control depth : 0 -- 0 3D control : MM -- (monitor muted) PCM : 71 -- green 00 PCM Out : pre 3D Line : MM -- (monitor muted) CD : MM -- (monitor muted) Mic : MM -- (monitor muted) Mic Boost : MM -- (monitor muted) Mic Sel : Mic1 -- Video : MM -- 0 Phone : MM -- 0 IEC958 : MM -- IEC958 playback : -- 0 AUX : MM -- 0 - NOT green Mono Out : Mix -- i Beep : MM -- 0 - NOT green External Amp : MM -- balance : Vol Bal -- 50 Capture: (new) (RED means input is enabled) - Use TAB to get to it - use "M" to mute or un-mute ---- alsamixer ------- aumix------------------------------------ 3D Control center : 0 -- 0 - RED 3D Control depth : none -- 0 - RED line : line -- 0 - not RED : not green CD : CD -- 0 - not RED : not green Mic : Capture -- 0 - RED : not GREEN (yes, you want a level of 0) Video : Video -- 0 - not RED : not green Phone : PhoneIn -- 0 - not RED : not green EC958 playback : none -- 0 - RED Aux : Line1 -- 0 - not RED : not green Capture : Capture -- 0 - RED : not green Mix : none -- 0 - Mix Mono : none -- 0 - ================================================================ output (older) ----Kmix ------------- aumix------------------------------------ Master : vol -- 68 - green (allow output) Master Mono : phoneOut -- 74 - green headphone : PCM2 -- 45 - green (pskmeter likes 59) 3D control center : none -- 0 3D control depth : none -- 0 PCM : PCM -- 71 - green IEC958 playback : none -- 0 PC speaker : none -- 0 - NOT green balance : Vol Bal -- 50 input: (old) (RED means input is enabled) ----Kmix ------------- aumix------------------------------------ 3D Control center : none -- 0 - RED 3D Control depth : none -- 0 - RED line : line -- 0 - not RED : not green CD : CD -- 0 - not RED : not green Mic : MIC -- 0 - RED : not GREEN Video : Video -- 0 - not RED : not green Phone : PhoneIn -- 0 - not RED : not green EC958 playback : none -- 0 - RED Aux : Line1 -- 0 - not RED : not green Kmix switches: --------------------------------------------------------- 3D Control - switch - not yellow Mic Boost (+20db) - not yellow IEC958 - not yellow Mix - not red Mix Mono - not red External Amplifier - not red PCM out path and mute - pre 3D MIC select: - Mic1 (built-in mic) Mono Output Select: - Mix OLD original -- Dell Latitude -- NOTE: Some mixer functions disable other configured features. One such feature is the "Switches: Mix Mono". It's critical that this is RED for this specific soundcard! Kmix Running the following should restore the Mixer settings: /sbin/alsactl restore Just to confirm your settings: output --------------------------------------------------------- master: 55% green: (allow output) master mono: 1% - green 3D control sigmatel depth: 0% <-- critical PCM: 100% - green PC speaker: 0% - NOT green balance: -0- (middler) input: (RED means input is enabled) --------------------------------------------------------- RED ) - 3D Control sigmadel - Depth: 100% not red - line - 100% - GREEN not red - CD - 50% - not GREEN not red - Mic - 50% - not GREEN not red - Video - 50% - not GREEN not red - Phone - 50% - not GREEN not red - Aux - 50% - not GREEN RED - Capture - 100% - not GREEN switches: --------------------------------------------------------- ----> 3D Control - switch - YELLOW - if off, greatly lowers output also makes output STEREO Mic Boost (+20db) - not yellow Mix - not red critical ---> Mix Mono - RED External Amplifier - not red (also activates Mix Mono) Sigmatel 4spkr stereo - not red (also activates Mix Mono) Sigmatel surround phase inversion - not red (also activates Mix Mono) MIC select: Mic1 (built-in mic) Mono Output Select: Mix Saving and restoring your levels: --------------------------------- Once you have the sound levels where you want them, the way to SAVE these settings for all your various soundcard settings is to use the command: /sbin/alsactl save If at any time you want to revert to your previous saved levels, run the command: /sbin/alsactl restore Soundmodemconfig - Confirming you levels ---------------------------------------- Time to tune soundmodem's input levels +----------------------------------------------------------------------------+ | NOTE#1: | | the soundmodemconfig tool is very prone to crashing and you might | | need to restart it multiple times to get the seeings you need. | | I've also seen where it will NEVER successfully start on some | | Linux machines for unknown ALSA, video, whatever issues. | +----------------------------------------------------------------------------+ NOTE#2: You CANNOT use soundmodemconfig's diagnostic program while the soundmodem process is running. Make sure soundmodem is NOT running when trying to use this tool run soundmodemconfig as root: - Soundmodem's graphics don't have any ticks or level outputs to confirm the input levels. To work around this, get a ruler and some tape ready - highlight "channel 0" and in the menu bar, you'll now see diagnostics. - Select Spectrum Display, you should see a scope view with an X and Y axis. Move and tape the ruler to where the X axis is.
NOTE: This process is VERY CPU intensive. On my P3-500, it chokes but me and another user are coming to the conclusion that these diagnostic hangs might be due to ALSA issues and not a video card or CPU power limitation. Still researching this one.. NOTE2: When receiving a good enough packet and your radio keys up, you are probably hitting a known DCD issue with some interface cables. See the Soundmodem troubleshooting section for ideas on how to fix NOTE3: if soundmodemconfig updates for about 5 seconds and then stops on you, you are probably running an old version of soundmodem. Upgrade your version of soundmodem or just don't worry about it. When finished with this stage, soundmodem will probably run fine for you. - So now that you have a ruler showing a level of 0, shutdown soundmodemconfig, load it again and choose scope: --> 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 [email protected]@l,..........,... Packet: fm K6SNY-0 to BEACON-0 UI pid=F0 K6SNY / K6SNY-1 at the Sunnyvale EOC -- - NOTE6: It seems that soundmodemconfig's decodes seem to show MORE decodes than what axlisten shows. It could be that axlisten doesn't do all the same CRC checking.
This spectrum view is interesting to view and can be helpful in spotting remote TNCs that are improperly configured to have higher deviated low frequency tone than than the higher frequency tone. +-----------------------------------------------------+ | NOT recommended: Use Direwolf | | | | This section is here for posterity reasons only | +-----------------------------------------------------+ Once Soundmodem is configured, let's manually start up the soundmodem process: #-R is for realtime scheduling, -M to not let it get swapped out #-v 5 is for extended logging # /usr/sbin/soundmodem -RM -v5 ----- NOTE: ----- Now, I'm a KDE guy but if you ask anyone who's used KDE for a long time, they will probably tell you about KDE's sound system "arts" and how it's crap. Well, being crap, it bit me here again. So to avoid my issue: - In the KDE control panel, goto Sound & MultiMedia --> SoundSystem. In here, there are two settings: - Enable the network sound (maybe not)? - set the autosuspend to 1 second If that doesn't help, you'll have to make sure you disable ARTS from ever starting/running. If soundmodem starts, you'll see something like this: -- sm[6853]: mkiss: ifname sm0 mtu 256 hwaddr KI6ZHD-0 ipaddr 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255 ALSA: Using sample rate 9600, sample format 2, significant bits 16, buffer size 4800, period size 144 ALSA: Using sample rate 9600, sample format 2, significant bits 16, buffer size 4800, period size 144 sm[6853]: audio: starting "plughw:0,0" sm[6853]: audio: forcing half duplex mode -- ---------------------------------------------------------- There are some key items to observe from the above output: ---------------------------------------------------------- - Soundmodem is using "mkiss" which is important - the ax.25 interface being created it "sm0" - the default 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 correlates your settings to a userspace device given in /etc/ax25/axports - The ipaddr will be set to whatever you configured. This usually should be an AMPR address. Please see the AMPR section in this document on how to get one or more addresses for free If you see some strange values in here, read the Soundmodem Troubleshooting section below You'll also see the interface in /sbin/ifconfig -- sm0 Link encap:AMPR AX.25 HWaddr KI6ZHD inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:256 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) -- Ok, things are getting close but a few things to know: 1. the diagnostic views in soundmodem usually seem to freeze on most machines. Newer versions of soundmodem have fixed this but also make sure you're running newer versions of the ALSA sound system. 2. You MUST make sure that soundmodem, kissattach, and ax25d are NOT running before you start everything up. If you don't, you'll see errors like: tty_speed: tcgetattr: Invalid argument use this set of commands to make sure things are clean: killall ax25d killall kissattach killall soundmodem So you have the basics for an AX.25 setup now so lets let get things to come up reliably though on a manual fashion: [ Here is a quick hint but see below...] #Connect the cables, turn on the radio, set it to 144.390 (APRS) /sbin/modprobe mkiss #open soundmodemconfig and check the levels # as root /usr/bin/soundmodemconfig #bring up soundmodem (as root) /usr/sbin/soundmodem -v5 #You should see: # # sm[11301]: mkiss: ifname sm0 mtu 256 hwaddr KI6ZHD-0 ipaddr 10.0.0.1 # netmask 255.255.255.0 broadcast 10.0.0.255 # ALSA: Using sample rate 9600, sample format 2, significant bits 16, buffer # size 4800, period size 144 # ALSA: Using sample rate 9600, sample format 2, significant bits 16, buffer # size 4800, period size 144 # sm[11301]: audio: starting "plughw:0,0" # sm[11301]: audio: forcing half duplex mode # NOTE: errors like the following seem to not hurt operation: # # snd_pcm_start in iotxstart: Broken pipe +--------------------------------------------------------------------------------+ | NOTE: | | At this point, your soundcard TNC should be operational. It's important | | to note that unlike a hardware TNC, you DO NOT use "kissattach" to | | associate the TNC to a serial port. Soundmodem does all of this for you | +--------------------------------------------------------------------------------+ Instead of running all those manual commands above, I've consolidated much of this startup and shutdown details into one powerful startup script: +-----------------------------------------------------------------------------+ | This "packrig.sh" script documents a FAR more detailed and extensive | | breakdown of how to configure, tune and operate a packet station for | | multiple configurations. It includes the ability to: | | | | - switch between Hardware and software TNC configs | | for VHF/UHF and HF packet | | - depending on the frequency: | | - switch the beacon strings | | - switch linpac configs depending | | - switch between different UNPROTO paths | | - change the packet 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 | +-----------------------------------------------------------------------------+ 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. The configuration of the Linux system's AX25 isn't very difficult once you understand all the different pieces and how they fit together. Unfortunately, there is a LOT of old information out on the Internet showing different config file syntax, etc. and it gets frustrating in a hurry! In this example, I'm going to setup my system to connect either: - A Kenwood TH-F6A radio to the Direwolf softtnc program using the /dev/ttyUSB0 USB based serial port for keying PTT or - A hardware based TNC (Kenwood D710, KPC3 TNC, etc) connected to a radio on serial device /dev/ttyUSB0 +------------------------------------------------------------------------------+ | NOTE: my 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 | | | | | | A lighter take of of a startup script for Direwolf and TNC-PI (hardware | | TNC) can be found at: | | | | http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-up.new | | and | | http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-up.new2 | | and | | http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-down | | | | To integrate into 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 | +------------------------------------------------------------------------------+ +------------------------------------------------------------------------------+ | Three Very Important Notes: | | --------------------------- | | 1. Every callsign+SSID in the axports file MUST be unique and refer to a | | unique userspace device like "vhfdrop", "d710", "f6a", etc. | | | | 2. Though very subtle, the specific "KI6ZHD" callsign and SSID (no SSID | | specified means -0) used here does the correlation of connecting the | | Linux AX25 device "ax0" to the userspace axports device "vhfdrop". | | You, as a user, will NEVER use the "ax0" device directly. you use | | "vhfdrop" | | | | 3. In an older version of this doc, I set the device name in the axports | | file as "ax0" which was identical to the device name in the | | soundcard config. Though this technically works and is even recommended | | by some, it's not recommended by most Linux ax.25 documentation and can | | become very confusing to the packet operator. This userspace device | | name in the /etc/axports file should be UNIQUE. | +------------------------------------------------------------------------------+ Ok, I hope the above didn't scare you. There is a lot to AX.25 but it's actually pretty simple to get something started. Let's try that. - First, assuming you installed all the various AX25 packages from the above sections, edit or create the /etc/ax25/axports file. You'll need to edit it to match your specific setup (callsign, interface name, etc). The format of this file is as follows: - name : the interface name for this port. It can be ANYTHING but it's probably helpful to name it something informative like "d710" or "vhfdrop". - callsign+ssid : this parameter sets up your station to use your callsign and your desired SSID. Each SSID must be unique on your station regardless if being used for AX.25 or NETROM connections. A setting of say "KI6ZHD" is the equivalent of "KI6ZHD-0". I encourage you to read out to some of your local packet experts to learn what the SSID use guidelines are for your chosen packet frequency. They really can vary from area to area and frequency to frequency. See the "#pkttutor" section above on learning more about packet, etc - speed : this is the speed used between the computer and a physical TNC. If your TNC is running an RF speed of 1200BAUD packet, setting this to 9600 is fine. If using direwolf, this field will be essentially ignored so I would leave it at 9600 - MTU : This is the size of each packet in bytes that will be sent on RF. For HF, it's recommended to set this to 64. Many stations recommend to set this to 128. If you have lots of strong, clean packet signals in your area, you can set this to 255 (the max) which will give you the best speed. NOTE: Every time you get a packet collision or packet corruption due to QRN/QRM, your station will have to send the entire packet over. This is why sometimes setting it to the maximum is NOT the best setting. This needs to be tuned for your very specific environment - Window : This is the number of outstanding packets that can be sent before your system will require an ACK packet back. Much like MTU, the larger the window, the higher performance but if one packet is lost, the entire window has to be resent (in AX.20 v2.0 spec). I would recommend to start at 2 and maybe move up to 4 and tune from there (much like MTU) - Description: This is just a helpful text string and is not used anywhere else So, here is an example axports file: -- #name callsign speed paclen window description #change "N0CALL-8" to your callsign vhfdrop KI6ZHD 9600 128 2 Kenwood F6A at 1200baud -- Ok, example #1: manual start things up for direwolf. The following steps are taking from the lightweight Rpi startup script at: http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-up.new -- #Load the AX25 kernel module modprobe -a ax25 #Start direwolf direwolf -t 0 -c /etc/ax25/direwolf.conf -p #Connect Direwolf's emulated serial port (-p) to Linux's kernel interface mkiss -s 19200 -x 1 /tmp/kisstnc > /tmp/unix98 export PTS0=`more /tmp/unix98 | grep -w /dev | cut -b -11 ` #Attach the serial port Linux's ax25 stack kissattach $PTS0 vhfdrop #Set the AX.25 parameters - these are all very important bu the TXDELAY is a CRITICAL # setting for your radio. 300ms is safe but slow, 150 is too aggressive for some radios # # Half duplex, TXDELAY of 200ms, SLOTTIME of 100ms, PERSIST of 63 (out of 256), TXtail of 0ms /usr/local/sbin/kissparms -p vhfdrop -f n -t 200 -s 100 -r 63 -l 0 -- Now for example #2: manual start things up for a Kenwood D710 hardware TNC but this will equally apply for say a radio with a Kantronics KPC3 connected as well. The following steps are taking from the lightweight Rpi startup script (uses a TNC-Pi which is a version of a TNC-X) at: http://www.trinityos.com/HAM/CentosDigitalModes/RPi/etc/ax25/ax25-up.new -- #Become root to run these commands sudo su #Load the MKISS kernel module modprobe -a mkiss #Load the AX25 kernel module modprobe -a ax25 #Put the Kenwood D710, KPC3, or other HW TNC into kiss mode # # You can find the D710 KISS tool at: # http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/misc/D710/tmd710_tncsetup # # Alternatively, you can find a similar tool for Kantronics KPC3 TNCs at: # http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/kiss-on-kpc3.pl # http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/kiss-off.pl # # -B0 is VFO-A (left side), -S is the connected serial port, -b is the RF speed, and -h is hardware flow control tmd710_tncsetup -B 0 -S /dev/ttyUSB0 -b 1200 -h #Connect the hardware TNC via the /dev/ttyS0 serial port to Linux's kernel interface mkiss -s 9600 -x 1 /dev/ttyUSB0 > /tmp/unix98 export PTS0=`more /tmp/unix98 | grep -w /dev | cut -b -11 ` #Attach the serial port Linux's ax25 stack kissattach $PTS0 vhfdrop #Set the AX.25 parameters - these are all very important bu the TXDELAY is a CRITICAL # setting for your radio. 300ms is safe but slow, 150 is too aggressive for some radios # # Half duplex, TXDELAY of 200ms, SLOTTIME of 100ms, PERSIST of 63 (out of 256), TXtail of 0ms /usr/local/sbin/kissparms -p vhfdrop -f n -t 200 -s 100 -r 63 -l 0 -- Assuming all went well, you can use various programs addressed in the next section to make outgoing connections, etc. For example, check out the "call" or "axcall" program. At this point, you'll want to automate the setup AND tear down of your packet system. Read the above box at the top of this section to see URLS for either my: - ax25-up.new (base script), ax25-up.new2 (advanced daemons) and ax25-down (shutdown) scripts - hampacket.sh script containing more detail on how to tune your AX.25 setup (read the comments) Both scripts do a lot but if you have any questions, feel free to email me (or find me on Echolink at KI6ZHD-L). As part of the ax25-apps package, there are several basic programs to make outbound connections. Let's talk about two of them in particular: - ax25_call :: a simple connection tool similar to TELNET that can connect to remote AX.25, NetROM, ROSE, etc. hosts from the ax25-tools RPM - this tools has aliases to be netrom_call, rose_call and even tcp_call - call :: a better AX25 connection tool similar to TELNET for TCP/IP. Supports a basic interface as well as a 'talk' style split screen. Comes from the ax25-apps RPM. Works well though Linpac is even nicer Say you're in Silicon Valley trying to connect to K6SNY-1. To do so, you you would enter: call vhfdrop K6SNY-1 - axcall is the program - vhfdrop is the AX.25 device - in my examples, vhfdrop would be for a Direwolf-based softtnc connected to my Kenwood TH-F6A HT - Alternatively, I could have d710 for a Kenwood D710 based HW-TNC - K6SNY-1 is the remote destination Other examples: - To connect to a directly reachable AX.25 machine, I would do: call d710 woody - To connect to a indirectly reachable AX.25 machine via a digipeater, (not recommended for over 3 hops away), I would do: call d710 berry via woody - To connect to a indirectly reachable AX.25 machine via a node, I would do: call d710 woody #wait for the connection to establish #Using the Kantronics "c" command, connect to the remote host "berry" c berry - To connect to a remote machine via NetROM, I would do: # This assume your have a) Netrom configured on your system # (covered below) and b) the remote destination is loaded # in the Netrom route table. Shown with "route -A netrom" # call netrom berry +----------------------------------------------------------------------------------------------+ | You can learn more about making direct Netrom connections, etc via this separate doc: | | | | http://www.trinityos.com/HAM/CentosDigitalModes/misc/145.050-netrom-and-tcpip-connects.txt | +----------------------------------------------------------------------------------------------+ A GOOD connection to K6SNY-1 according to axlisten would show: #This is a connection request fm KI6ZHD-8 to K6SNY-1 ctl SABM+ #This is a completed connection fm K6SNY-1 to KI6ZHD-8 ctl UA- #This is a transmit of the "?" character (the trailing . is a terminator) fm KI6ZHD-8 to K6SNY-1 ctl I00^ pid=F0(Text) len 2 0000 ?. #This is a connection keepalive fm KI6ZHD-8 to K6SNY-1 ctl RR0+ #This is a disconnect request fm KI6ZHD-8 to K6SNY-1 ctl DISC+ #This is a disconnect confirmation fm K6SNY-1 to KI6ZHD-8 ctl DM- See the "Appendix B - KI6ZHD Running Packet notes for QTH" section for more hints and tips on basic packet operation As you've seen, you can make basic, outgoing connections but Linux AX.25 can do SO much more using tools from the ax25-suite as well as 3rd party tools. For example: #beacon - Announce your presence on a given frequency beacon -d BEACON -t 10 vhfdrop "Welcome the new HAM to AX.25.. still working on it" # There are interesting ways to use beacon. Try some of these scripts: # # Sending out UI packets for chats http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/unproto-transmit.sh # Sending out APRS formatted packets http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/beacon.py To monitor all of the received packets LIVE including the packets your station sends, there are two useful programs you should be aware of: listen :: listens to ALL packets sent and received This is already running in the packetrig.sh script and you can just tail the log file /usr/bin/listen -8artp vhfdrop Make sure it DOESN'T say "axconfig: port vhfdrop not active" mheard :: shows last heard stations with optional things like via what digipeater, etc. "man mheard" Doesn't show the frequency but it's very similar to the "last" command in Unix ------------------------------------------------------------ #First start the mheard server /usr/bin/mheardd #After a while, run the client program to see what stations were heard: mheard #ax25d daemon - similar to inetd which will start services based on incoming requests /usr/sbin/ax25d #You should see: # # axconfig: port APRS not active # nrconfig: unable to open nrports file /etc/ax25/nrports (No such file or directory) # rsconfig: unable to open rsports file /etc/ax25/rsports (No such file or directory) ------------------------------------------------------------- Fldigi Dependencies : All versions of Centos - 6 and 5 ------------------------------------------------------------- Regardless of building Fldigi via RPM spec files or doing everything from source, the Fldigi build requires many other programs and libraries (RPMs) to allow proper compiling and enabling all features installed: #Installing libXt-devel is recommended and needed before building Fltk yum install libXt-devel # NOTE: Installing this may require 7+ other RPMs #Installing libasound2 is recommended and needed before building Fltk # I don't know why this isn't called libasound2 on Centos but Centos uses this different name yum install alsa-lib alsa-lib-devel #A few others to make sure you have installed yum install libX11-devel yum install autoconf yum install mesa-libGLU-devel #fltk - Fast Light Toolkit Fldigi (on Centos6 or Centos5) requires a newer version of fltk than what EPEL and Rpmforge offers. To fix this, you have to compile a new version yourself. +--------------------------------------------------------------------+ | NOTE: this might change over time so it's recommended to try Yum | | to see if they now offer fltk-1.3.0 or newer. If not, | | follow this next section. | +--------------------------------------------------------------------+ Centos6 specific: ----------------- # We'll download Fedora16's old package as a starting point # cd /usr/src/redhat/SRPMS wget -O fltk-1.3.0-1.fc16.src.rpm \ http://download.fedoraproject.org/pub/fedora/linux/releases/16/Everything/source/SRPMS/fltk-1.3.0-1.fc16.src.rpm # Next, let's get the current code version: 1.3.4 # cd /usr/src/redhat/SOURCES wget http://fltk.org/pub/fltk/1.3.4/fltk-1.3.4-2-source.tar.gz # Next, you noticed the version name of 1.3.4-2. RPM reserves the use of dashes in the filenames # for it's own use so this means we need to change it first # cd /usr/src/redhat/BUILD tar xzvf /usr/src/redhat/SOURCES/fltk-1.3.4-2-source.tar.gz mv fltk-1.3.4-2 fltk-1.3.4.2 tar czvf fltk-1.3.4.2-source.tar.gz fltk-1.3.4.2 #Now lets' clean up the old directory and move the new archive to the SOURCES dir mv fltk-1.3.4.2-source.tar.gz ../SOURCES/ rm -Rf fltk-1.3.4.2/ #Ok, now let's install the older source SRPM to get it's SPEC file rpm -ivh fltk-1.3.0-1.fc16.src.rpm #Next, we need to install build dependency RPMs: yum install libjpeg-devel #Now we need to update the SPEC file to reflect the new name and any other changes: cd /usr/src/redhat/SPECS vim fltk.spec First change: -- #change the line Version: 1.3.0 #to Version: 1.3.4.2 -- Second change: -- #find lines reflecting the definition of an old patches needed for fktk-1.3.0 which # are now fixed in this newer version: Patch1: fltk-1.1.9-fltk_config.patch Patch3: fltk-1.1.x-r5750-undefined.patch Patch5: fltk-1.1.8-fluid_desktop.patch #and comment them out so it looks like #Patch1: fltk-1.1.9-fltk_config.patch #Patch3: fltk-1.1.x-r5750-undefined.patch #Patch5: fltk-1.1.8-fluid_desktop.patch -- Third change # In fltk 1.3.4.2, there seems to be a missing reference to a file that's of a different #name, to resolve this, find the line: -- make install install-desktop DESTDIR=$RPM_BUILD_ROOT # replace it with the following lines make install DESTDIR=$RPM_BUILD_ROOT #dranch: hack to work around missing x-fluid.desktop file issue cp fluid/fluid.desktop fluid/x-fluid.desktop make install-desktop DESTDIR=$RPM_BUILD_ROOT -- #Fourth change -- # scroll down and find the line that activates that patch and also comment that out -- %patch1 -p1 -b .fltk_config %patch3 -p1 -b .undefined %patch5 -p1 -b .fluid_desktop #and comment it out so it looks like #%patch1 -p1 -b .fltk_config #%patch3 -p1 -b .undefined #%patch5 -p1 -b .fluid_desktop -- #Fifth h change -- # scroll down to the bottom of the file and add a new update line Sat Mar 10 2018 David Ranch 1.3.4-2 - New release -- Save your changes to the new fltk.spec file #Ok... almost done! Now it's time to compile it # cd /usr/src/redhat/SPECS rpmbuild -bb --target=x86_64 fltk.spec #When you run the rpmbuild command above, make sure all the other required libs #are seen. For example: # Configuration Summary # ------------------------------------------------------------------------- # Directories: prefix=/usr # bindir=/usr/bin # datadir=/usr/share # datarootdir=${prefix}/share # exec_prefix=/usr # includedir=/usr/include # libdir=/usr/lib64 # mandir=/usr/share/man # Graphics: X11 + Xft + Xdbe + Xfixes + Xinerama + Xcursor + Xrender # Image Libraries: JPEG=System # PNG=System # ZLIB=System # Large Files: YES # OpenGL: YES # Threads: YES #Install the compiled binaries rpm -ivh /usr/src/redhat/RPMS/x86_64/fltk-1.3.4.2-1.el6.x86_64.rpm \ /usr/src/redhat/RPMS/x86_64/fltk-devel-1.3.4.2-1.el6.x86_64.rpm \ /usr/src/redhat/RPMS/x86_64/fltk-fluid-1.3.4.2-1.el6.x86_64.rpm \ [DEPRECATED] - Centos5 specific for older builds: ------------------------------------------------- yum install ftp://fr2.rpmfind.net/linux/epel/5/i386/fltk-1.1.9-4.el5.i386.rpm yum install ftp://fr2.rpmfind.net/linux/epel/5/i386/fltk-devel-1.1.9-4.el5.i386.rpm Ok, moving on with more Fldigi dependencies for both Centos6 and Centos5 ------------------------------------------------------------------------ # libsndfile-devel yum install libsndfile-devel # libsamplerate-devel yum install libsamplerate-devel XMLRPC ------ # If you want the Fldigi's XMLRPC system for Flrig to work, you need # to enable the xmlrpc code: # # Centos6: # ------- yum install xmlrpc-c-c++ xmlrpc-c-client xmlrpc-c-client++ \ xmlrpc-c-devel xmlrpc-c xmlrpc-c-apps # Centos 5 # ------- # Try installing from these pre-build versions: yum install ftp://ftp.pbone.net/mirror/centos.karan.org/el5/extras/testing/i386/RPMS/xmlrpc-c-1.06.18-1.el5.kb.i386.rpm \ ftp://ftp.pbone.net/mirror/centos.karan.org/el5/extras/testing/i386/RPMS/xmlrpc-c-devel-1.06.18-1.el5.kb.i386.rpm \ ftp://ftp.pbone.net/mirror/centos.karan.org/el5/extras/testing/i386/RPMS/xmlrpc-c-apps-1.06.18-1.el5.kb.i386.rpm # If the above RPMs won't work for some reason, you'll need to build the XMLRPC # code from source: # Not sure if cmake is required as we disable it later # # Please note that in the SDR section, we will update the Cmake to # a much more modern version. Go ahead and follow those instructions # if you want to get ahead now: # yum install cmake #Get the code wget -O xmlrpc-c-1.06.18-1.el5.kb.src.rpm \ yum install http://centos.karan.org/el5/extras/testing/SRPMS/xmlrpc-c-1.06.18-1.el5.kb.src.rpm #Install the code rpm -ivh xmlrpc-c-1.06.18-1.el5.kb.src.rpm # NOTE: # 1 - this xmlrpc RPM uses cmake and not the usual configure system # which seems to break the abyss-server subsystem: # # -- this following command should give a 0 but it doesn't # # xmlrpc-c-config c++2 abyss-server # echo $? # # - to fix this, you have to redo the SPEC file a # bit as shown below # -- # 62,63c62,63 # < mkdir fedora # < cd fedora # --- # > #mkdir fedora # > #cd fedora # 66,71c66,72 # cmake .. \ # < -D_lib:STRING=%_lib \ # < -DMUST_BUILD_CURL_CLIENT:BOOL=ON \ # < -DMUST_BUILD_LIBWWW_CLIENT:BOOL=OFF \ # < -DCMAKE_INSTALL_PREFIX:PATH=%_prefix \ # < -DBUILD_SHARED_LIBS:BOOL=ON # --- # > #cmake .. \ # > # -D_lib:STRING=%_lib \ # > # -DMUST_BUILD_CURL_CLIENT:BOOL=ON \ # > # -DMUST_BUILD_LIBWWW_CLIENT:BOOL=OFF \ # > # -DCMAKE_INSTALL_PREFIX:PATH=%_prefix \ # > # -DBUILD_SHARED_LIBS:BOOL=ON # > ./configure --prefix=%_prefix # 77c78 # < cd fedora # --- # > #cd fedora # 102d102 # < %_libdir/pkgconfig/.pc # 103a104,108 # > %_libdir/libxmlrpc++.a # > %_libdir/libxmlrpc.a # > %_libdir/libxmlrpc.la # > %_libdir/libxmlrpc_. # > # 110d114 # < %_mandir/man1/ # 113d116 # < %_bindir/xml-rpc-api2cpp # 116a120,122 # > Sat May 08 2010 David Ranch - 1.06.18-2 # > - stopped using CMAKE, use ./configure to get xmlrpc-c-config C++2 # > abysss-server passing, added missing /usr/lib files into SPEC file # Ok, time to build it rpmbuild -bb --target i686 /usr/src/redhat/SPECS/xmlrpc-c.spec #Time to install it cd /usr/src/redhat/RPMS/i686 rpm -Uvh xmlrpc-c-1.06.18-1.i686.rpm xmlrpc-c-apps-1.06.18-1.i686.rpm \ xmlrpc-c-devel-1.06.18-1.i686.rpm NOTE: ----- - Using the above RPMs fails to work with Fldigi's configure system -- the following test should give a result of "0" but it doesn't xmlrpc-c-config c++2 abyss-server; echo $? Back on track, lets move on for both Centos6 and Centos5 -- Perl-RPC-XML ------------- # If the xml-rpc system is installed, the Fldigi system also needs the # Perl RPC::XML CPAN module from RPMforge: # NOTE: the old perl-XML-RPC package has been replaced by perl-RPC-XML # package. Why they did this naming change boggles the mind yum install perl-RPC-XML # More packages to install # ------------------------ #The following are required by HamLib which is required by Fldigi yum install gd gd-devel tcl-devel libusb-devel doxygen libtool-ltdl-devel libXpm-devel Ok, before we go much farther, we should get Hamlib running just in case you don't want to use Flrig. Hamlib is a suite of programs and radio definitions to remote control a huge amount of different radios. The amount of control depends on several factors such as: - What does the radio offer for control (older radios are very simple, new radios let you control almost every single thing about them) - How mature is the Hamlib definition (some definitions are incomplete though the radio supports additional rig control function) Hamlib is an excellent choice to do rig control from shell scripts and what not. For interactive control with say Fldigi and other GUI tools, I recommend to use Flrig INSTEAD. Anyway, if you want to install Hamlib, let's get going: # First, you need to install some build dependencies (if you don't # already have them): # yum install libtool Next, you can either use my SPEC file (recommended) or modify the Fedora one yourself your own: # Getting and using my spec file: # cd /usr/src/redhat/SPECS wget -O hamlib.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/hamlib.spec ---------------------------------------- If you want to create your own SPEC file ---------------------------------------- # Download the Fedora 16 SRPM to get the a baseline SPEC file, the # patches for Hamlib to be compatible with Centos, and then later we'll # download the newer Hamlib source code #First, let's get the older SRPM and install it cd /usr/src/redhat/SRPMS wget -O hamlib-1.2.14-1.fc16.src.rpm http://download.fedoraproject.org/pub/fedora/linux/releases/16/Everything/source/SRPMS/hamlib-1.2.14-1.fc16.src.rpm rpm -ivh hamlib-1.2.14-1.fc16.src.rpm Next, regardless of which SPEC file you use (my modified one or the stock Fedora one, it's recommend to download the NEWER production version of Hamlib sources. If there is even a newer version than 3.2.0, I recommend to get that version and make the required changes to build/install this newer version. You can browse and download from here: https://github.com/Hamlib/Hamlib/releases So, at the time of this writing (3/31/18), the newest version of Hamlib is v3.2.0. Lets build that: cd /usr/src/redhat/SOURCES/ wget -O hamlib-3.2.tar.gz https://github.com/Hamlib/Hamlib/releases/download/3.2/hamlib-3.2.tar.gz Now make sure the SPEC file you downloaded (or created): # Fixing your own SPEC file (not needed if you use my above spec file): # # The sources in hamlib 3.2 are newer and thus the Fedora16 RPM is # a little out of date so we need to fix it and we should disable # GnuRadio and USRP while we're at it as they have HUGE dependencies # that we don't use right now. If you want GnuRadio support, please # see the GnuRadio section and get that installed first +-----------------------------------------------------------------------------+ | NOTE: | | This section has been updated for Hamlib v3.2+ but one known gotcha | | is that hamlib gets confused by the presence of both the libusb and | | libusbx libraries. As such, to successfully compile this new | | version, you must build Hamlib with: | | | | ./configure --without-libusb | +-----------------------------------------------------------------------------+ # NOTE2: there are some HamLib options that you might want to enable # such as USRP or GnuRadio but both of these options require # SIGNIFICANTLY more work and packages to resolve. For example: # # --with-rigmatrix :: Generate rigmatrix tool (requires libgd) # --without-winradio :: do not build winradio backend # --with-gnuradio :: build gnuradio backend # --with-usrp :: build USRP backend # --without-rpc-backends :: do not build rpcrig and rpcrot backends # NOTE3: Centos5 # With Hamlib the 1.2.9n version and to get the perl and python # options to work, you NEED to use the Fedora patch to set # the proper destinations. The 1.2.8 patch applies cleanly # on 1.2.9 but it does NOT apply to 1.2.13.1 cd /usr/src/redhat/SPECS vim hamlib.spec -- # In the top "BuildRequires:" lines, make the following changes: # Update the version to reflect the new sources Version: 3.2 # Remove "gnuradio-devel, usrp-devel" # # In the "%configure" section (don't forget that front "\"): # remove "\ # --with-usrp" # Find the following line and either DELETE it or comment it out with a # character # Patch2: hamlib-1.2.11-python2.7.configure.patch # Find the following line and either DELETE it or comment it out with a character # %patch2 -p1 -b .python-version Ok, let's compile hamlib and then install it: # For Centos6: rpmbuild -bb --target=x86_64 hamlib.spec # For Centos5: rpmbuild -bb --target i686 hamlib.spec During the configure stage, you should see something like the following. Make sure that all the features you expect are present: -- Hamlib Version 3.2 configuration: Prefix /usr Preprocessor gcc -E C Compiler gcc -O3 -march=native -m64 C++ Compiler g++ -O3 -march=native -m64 Package features: With C++ binding yes With Perl binding yes With Python binding yes With TCL binding no With Lua binding no With rigmem XML support no With Readline support yes Enable HTML rig feature matrix yes Enable WinRadio yes Enable USRP no Enable USB backends no Enable shared libs yes Enable static libs no -- Now hopefully that things built and packaged up ok, time to install them: #For Centos6 # cd /usr/src/redhat/RPMS/x86_64 sudo rpm -Uvh hamlib-3.2-1.el6.x86_64.rpm hamlib-devel-3.2-1.el6.x86_64.rpm hamlib-doc-3.2-1.el6.x86_64.rpm \ hamlib-c++-3.2-1.el6.x86_64.rpm hamlib-c++-devel-3.2-1.el6.x86_64.rpm hamlib-perl-3.2-1.el6.x86_64.rpm \ hamlib-python-3.2-1.el6.x86_64.rpm hamlib-tcl-3.2-1.el6.x86_64.rpm hamlib-debuginfo-3.2-1.el6.x86_64.rpm #For Centos5 cd /usr/src/redhat/RPMS/i686 rpm -Uvh hamlib ?LEGACY - probably safe to ignore? -- confirm what Fldigi is ------------------------------------------------------------- - Fldigi required hamlib-devel - current available is 1.2.13.1 - last working version installed 1.2.9 - fedora repo is at 1.2.8 - not in rpmforge Ok, back to more dependencies for Fldigi before we can compile it ALSA & PortAudio specific ----------------------------------- - As mentioned above in the ALSA section towards the top of this document, both Centos6 and Centos5 ships with very old ALSA kernels and PortAudio code. You need to upgrade BOTH for proper operation: ElRepo ALSA (Centos6): ---------------------------- # NOTE: this will only upgrade the ALSA kernel soundcard drivers # which remains compatible with the older ALSA libraries, # tools, etc. This is very easy and works well # yum install http://elrepo.org/linux/elrepo/el6/x86_64/RPMS/kmod-alsa-1.0.24-1.el6.elrepo.x86_64.rpm ElRepo ALSA (Centos5): ---------------------------- # NOTE: this will only upgrade the ALSA kernel soundcard drivers # which remains compatible with the older ALSA libraries, # tools, etc. This is very easy and works well cd /usr/src/redhat/RPMS/i686 wget -O kmod-alsa-1.0.24-1.el5.elrepo.i686.rpm \ http://elrepo.org/linux/elrepo/el5/i686/RPMS/kmod-alsa-1.0.24-1.el5.elrepo.i686.rpm rpm -ivh /usr/src/redhat/RPMS/i686/kmod-alsa-1.0.24-1.el5.elrepo.i686.rpm PortAudio Snapshot: ------------------- PortAudio is becoming legacy to Linux much like OSS was some time ago. With that said, it's still good to have the support in the system and other programs like WSJT still use it: NOTE: ----- The EPEL portaudio-19-9.el6 for Centos6 and portaudio-19-8.el5 for Centos5 is NOT new enough and you must use the newest Tip-Of-Tree version cd /usr/src/redhat/SOURCES wget -O pa_snapshot.tgz http://www.portaudio.com/archives/pa_snapshot.tgz #Get dranch's portaudio-tot.spec file: cd /usr/src/redhat/SPECS wget -O portaudio-tot.spec \ http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/portaudio-tot.spec #Look at the following page: http://www.portaudio.com/download.html # # Find the date specified for pa_snapshot.tgz #Edit the portaudio-tot.spec file and change the date to reflect # this newest TOT - for example: # # Version: 19 # Release: Release: 20120117%{?dist} #Centos6 specific rpmbuild -bb --target x86_64 portaudio-tot-el6.spec rpm -ivh /usr/src/redhat/RPMS/x86_64/portaudio-19-20120117.el6.x86_64.rpm \ /usr/src/redhat/RPMS/x86_64/portaudio-devel-19-20120117.el6.x86_64.rpm #Centos5 specific rpmbuild -bb --target i686 portaudio-tot.spec rpm -ivh /usr/src/redhat/RPMS/i686/portaudio-20100923.el5.i686.rpm Additional Soundcard and Sound sub-system specific dependencies: ---------------------------------------------------------------- # Also install # yum install jack-audio-connection-kit-devel jack-audio-connection-kit # This comes from ATrpms - GUI tool needed for setting proper audio device # routing and audio levels from the Pulse system into say Fldigi, Direwolf, etc # yum install pavucontrol # If you prefer to set your PulseAudio settings via the command line, you # can use the "pacmd" tool (warning: This is a VERY complicated tool to use # compared to the pavucontrol tool # yum install pulseaudio-utils Finally, time to compile Fldigi.. ------------------------------------ cd /usr/src/redhat/SPECS/ Centos6 on a x64 system: ------------------------ rpmbuild -bb --target x86_64 fldigi.spec Centos5 on a i686 system: ------------------------- rpmbuild -bb --target i686 fldigi.spec Regardless of which Centos version you're building for, look back in the RPM building process and make SURE it looks some thing like the following. Make sure all the options are "yes", etc: ------------------------------------- Version ..................... 4.0.2 Static linking .............. no CPU optimizations ........... sse2 Debugging ................... no fldigi ...................... yes flarq ....................... yes i18n ........................ yes fldigi build options: sndfile ..................... yes oss ......................... yes portaudio ................... yes pulseaudio .................. yes hamlib ...................... yes xmlrpc ...................... yes ------------------------------------- and now install it: #Centos6 specific: rpm -ivh /usr/src/redhat/RPMS/x86_64/fldigi-4.0.2-1.el6.x86_64.rpm #Centos5 specific: rpm -Uvh /usr/src/redhat/RPMS/i686/fldigi-4.0.2-1.i686.rpm Flrig is a rig control program that can either be stand-alone or a companion program to Fldigi. Fldigi by itself can use Hamlib but it doesn't always give all the desired information. Flrig gives you: - It's completely independent of Hamlib and has it's own radio definitions - S-meter readouts as shown by the rig itself - Full control of the rig's VFO-A, VFO-B, Split control - Full control of the rig's speaker volume, RF power, IF shift, Notch filter, MIC gain ATT, PreAmp1/2, NoiseBlanker, etc. ---------------------------------------------------------------------------- NOTE: this program is OPTIONAL to use with Fldigi but is highly recommended ---------------------------------------------------------------------------- This is the main window for controlling everything on the rig from RF power, using the tuner, etc:

Please note that Flrig does NOT provide any QSO logging support what so ever. If you want that, either use Fldigi's built-in logger, use Fllog, or even use Xlog Ok, let's get to it. Flrig is a very new program so you might want to try the Alpha version if the posted version doesn't work for you. The primary version didn't for me with my FT-950. It's new so we have to piece things together a bit: cd /usr/src/redhat/SOURCES #Getting the version 1.3.30 - change the version number to match the newest # release version available wget -O flrig-1.3.30.bin.tgz https://downloads.sourceforge.net/project/fldigi/flrig/flrig-1.3.30.tar.gz Get the TrinityOS spec file (not recommended): cd /usr/src/redhat/SPECS wget -O flrig.spec \ http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/flrig.spec # Update the spec file to reflect the current version of Flrig chosen vim flrig.spec [NOT Recommended] - Alternatively, you can create your own SPEC file -------------------------------------------------------------------- #These notes reflect an older ALPHA build cd /usr/src/redhat/SPECS wget http://dp67.fedorapeople.org/pkgs/SPECS/flrig.spec vim flrig.spec -- update the version to "1.1.3CY" Change the release string to "1%{?dist}" Change the source0 to "http://www.w1hkj.com/beta/flrig/%{name}-%{version}.tar.gz" Change the %prep0 to "%setup -q -n %{name}-%{version}" Change the %build section, make the "configure" and "make" lines read: %configure --enable-optimizations=native make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" Change the %install line from: desktop-file-install \ to desktop-file-install --vendor="" \ also append the commend below the command to say: # --vendor obsolete per new guidelines but leaving it in because # this is an existing package with vendor previously installed -- Next, regardless of using my SPEC file your you building your own, make sure the version number reflects the current version of Flrig Now let's build and install it: cd /usr/src/redhat/SPECS/ NOTE: In the Flrig build notes, I used to use %configure --enable-optimizations=native which seemed to throw warnings that the resulting code would be using legacy i80387 FPU instructions. It turns out this was an issue with the older Centos5 compilers and using "native" is both RECOMMENDED and enabled NOTE #2: at the beginning of this document, the "native" optimizations was enabled via the /etc/rpmrc file but the Fldigi configuration script does NOT honor those settings #Centos6 specific rpmbuild -bb --target=x86_64 flrig.spec rpm -ivh /usr/src/redhat/RPMS/x86_64/flrig-1.3.30-1.el6.x86_64.rpm #Centos5 specific rpmbuild -bb --target=i686 flrig.spec rpm -Uvh /usr/src/redhat/RPMS/i686/flrig-1.3.30-1.i686.rpm Now it's about time to configure Flrig. To start off, cable up your radio to a serial port (I'm using a USI Navigator in this example) and turn the radio on but DON'T start Flrig just yet. The serial ports I'm using are: USI_CAT -> ttyUSB0 :: the CAT serial control USI_PTT -> ttyUSB1 :: for asserting PTT (FT950's CAT-based PTT only listens to the MIC port when in SSB mode +--------------------------------------------------------------+ | NOTE on Serial port permissions: | | -------------------------------- | | With the use of UDEV, all serial ports require users to have | | the "dialout" group permission. To enable this for your | | login (don't use root): | | | | - edit the /etc/groups file as root u | | - scroll down and find the "dialout" group name | | - append at the end of the line the needed username like | | dranch | | | | You will have to LOGOUT and log back in with this | | username for the changes to go into effect | | | | Once logged back in, open a terminal window and run | | the command "groups". Make sure "dialout" shows up. | | If it doesn't you'll need to log out of your current | | Gnome/KDE/whatever session and back in to get the new | | settings. | +--------------------------------------------------------------+ Next, as a regular user (NOT root), start up flrig from the command line with: /usr/bin/flrig & Config --> Xcvr Select For my Yaesu FT-950 with a US Interface Navigator, I have: Primary tab: Rig: FT-950 Fldigi address: 127.0.0.1 retries: 3 Fldigi port: 7362 retry intvl: 50 Ser. port: /dev/ttyUSB0 cmd intvl: 5 Baud: 38400 qry intvl: 100 1 stop bits No-dial PTT via CAT - Uncheck RTS/CTS No-dial PTT via RTS - Uncheck RTS +12v No-dial PTT via DTR - Uncheck DTR +12v "Hardware PTT" tab: PTT port: /dev/ttyUSI_PTT - PTT via RTS (do NOT checkmark "RTS = +V") - UnCHECK RTS +12v - Click on "Initialize" - Polling - Checkmark everything Issues: - The 1.1.3CY Alpha version is approaching 100% perfect but the current 1.1.3 release barely works. 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 terminal window and run | | the command "groups". Make sure "dialout" shows up. | | If it doesn't you'll need to log out of your current | | Gnome/KDE/whatever session and back in to get the new | | settings. | +--------------------------------------------------------------+ 3. Initial Fldigi setup: As logged in as a regular user (NOT root), start up Fldigi and follow the wizard to setup things. Enter in: - Your callsign - Name (first name only) - QTH where you're transmitting from - Locator - Antenna type Next -> - Audio: - Devices: - Pulse audio (leave the server string blank) - Settings: - Sample rate: grey'ed out when using PulseAudio - Converter: Medium Sinc Interpolator - Corrections: all zeros for now (come back to this later) - Mixer - OSS mixer: Manage mixer - UNCHECKed - Right channel - All checkboxes disabled for a US Interfaces Navigator to a FT950 Next --> - Transceiver control ---------------------------------------------- For RIG control, you have two primary options: ---------------------------------------------- - Flrig (recommended): Fldigi has excellent integration with Flrig via the XML-RPC option for use with Flrig - HamLib: This extensive library will most likely support more radios, rotators, etc. than Flrig but it won't give you the same level of rig feedback for things like S-meters, GUIs for controlling 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 Configure --> Rig Control --> Hamlib and checkmark the "Use HamLib". Next, for a FT950 using the previously mentioned UDEV names: Device: /dev/USI_CAT BAUD: 38400 Stop bits: 1 retries: 3 retry: 60 write delay: 5 post write delay: 5 UNCHECK: "PTT via Hamlib command" CHECKBOX: RTS +12 Click on "Initialize" Next, click on the "HW PTT" tab Checked: use separate serial port PTT - use RTS - dev/ttyUSI_PTT Finish --> 4. The main screen At this point, the primary Fldigi interface should come up and the waterfall should start flowing. NOTE on Pulse Audio ------------------- When I first started up Fldigi on this Centos6 machine with the radio listening to PSK31 on 14.070, I could only see faint PSK31 signals and all the audio was squished to the far-left. I would turn up the radio's speaker volume and the signals got stronger. Huh? What's going on here. Then I sneezed and saw the sneeze on the waterfall! HA! Seems that the PulseAudio system was listening to the computer's microphone and not the USB soundcard source! Check your PulseAudio mixer settings and: 1. Deselect any Capture checkboxes on built-in microphones 2. Run the "pavucontrol" in another window a. On the Playback tab, you should see "Fldigi" listed. Click on the box next to the MUTE button that probably says "Internal Audio Analog Stereo" and for a US Interface Navigator, select "USB Audio Codec" b. On the Recording tab, you should see "Fldigi" listed. Click on the box next to the MUTE button that probably says "Internal Audio Analog Stereo" and for a US Interface Navigator, select "USB Audio Codec" NOTE ---- For a FT-950 into a US Interface Navigator sound card and a RS232 cable to the radio, I have the following setup: NOTE: You can do rig control via Hamlib or Flrig. Hamlib works very nicely but you can do a LOT more things if you run the associated Flrig program at the same time as Fldigi. Up to you. For now, the docs cover Hamlib: 3. One thing I've learned is if you use the "Signal Browser" that decodes many simultaneous PSK31 QSOs, you need to be careful of the settings for "Signal Browser's" squelch setting (try -1.5) and the Inactivity Timeout (try 10 seconds in Configure --> UI --> Browser --> Inactivity Timeout 4. Full setup, level optimization, and much more can be found here: http://www.trinityos.com/HAM/US-Interface/us-interface-navigator-and-linux.html ---------------------------------------------------------------------------- Critical things that you should do next to get things dialed in (need to be added to this doc) before operating on the airwaves: ---------------------------------------------------------------------------- 1. Calibrate your soundcard's timing using Fldigi's WWV mode: http://www.w1hkj.com/FldigiHelp-3.20/DigiWWV.html 2. Tune your audio levels for good IMD levels (the more NEGATIVE numbers the better. I -highly- recommend building and using a PSKmeter for this (covered in this doc already) as well as in my Digital Field Day docs: http://www.trinityos.com/HAM/FieldDay-2010/ 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! 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 Flmsg is a companion program to Fldigi to send NBEMS messages or ICS forms for emergency communicates over HF. To use this, you will also need Flwrap shown in the next section. --------------------------------------------------- NOTE: this program is OPTIONAL and doesn't require Fldigi to run or vice versa --------------------------------------------------- Ok, let's get it. It's new so we have to piece things together a bit: cd /usr/src/redhat/SOURCES wget -O flmsg-1.1.13.tar.gz http://www.w1hkj.com/downloads/flmsg/flmsg-1.1.13.tar.gz To get a SPEC file, you can either use my .spec file (recommended) or create your own: # My recommended SPEC file: cd /usr/src/redhat/SPECS wget -O flmsg.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/flmsg.spec # Skip to the next part since you're not making your own SPEC file # If you want to create you own SPEC file, first get an example SPEC file cd /usr/src/redhat/SPECS wget https://api.opensuse.org/public/source/hamradio/flmsg/flmsg.spec?rev=fc86d1d4334124509642871a9aedffed& #Lets rename the crazy file name mv flmsg.spec?rev=fc86d1d4334124509642871a9aedffed& flmsg.spec vim flmsg.spec -- Under the BuildRequires: line, remove the entries: xorg-x11-devel and update-desktop-files Change the release reflect the right version Change the Source: line to alter the file suffix from .bz2 to .gz delete the line that reads: %debug_package Make the %configure line read: %configure --enable-optimizations=native Change the make line to read: make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" Replace the line that says: %suse_update_desktop_file -i flmsg with desktop-file-install --vendor="" \ --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \ $RPM_BUILD_ROOT%{_datadir}/applications/flmsg.desktop # --vendor obsolete per new guidelines but leaving it in because # this is an existing package with vendor previously installed Add your own revision entry at the bottom Next, regardless of using my SPEC file your you building your own, make sure the version number reflects the current version of Flmsg Now let's build and install it: cd /usr/src/redhat/SPECS/ #For Centos6 users with x86_64 rpmbuild -bb --target=x86_64 flmsg.spec rpm -ivh /usr/src/redhat/RPMS/x86_64/flmsg-1.1.13-1.x86_64.rpm #For Centos6 users with i686 rpmbuild -bb --target=i686 flmsg.spec rpm -ivh /usr/src/redhat/RPMS/i686/flmsg-1.1.13-1.i686.rpm Let's run and configure it: /usr/bin/flmsg & Config --> Radiogram: - Call: -- for me, KI6ZHD - Optionally set your phone # - Optionally set your street address - Enter your city and state - # of words per line Config --> Date & Time: - Set your preference for date and time Flwrap is a add-on to Fldigi which, in tandem with Flmsg, is used to send NBEMS forms and binary files (pictures, etc.) --------------------------------------------------- NOTE: this program is OPTIONAL and doesn't require Fldigi to run or vice versa --------------------------------------------------- Ok, let's get on with it. It's new so we have to piece a SPEC file together a bit: cd /usr/src/redhat/SOURCES wget -O flwrap-1.3.2.tar.gz http://www.w1hkj.com/downloads/flwrap/flwrap-1.3.2.tar.gz # To get a SPEC file, you can either use my .spec file (recommended) or # create your own: # My recommended SPEC file: cd /usr/src/redhat/SPECS wget -O flwrap.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/flwrap.spec # Skip to the next part since you're not making your own SPEC file # If you want to create you own SPEC file, first get an example SPEC file Next, lets get an example SPEC file cd /usr/src/redhat/SPECS wget https://api.opensuse.org/public/source/hamradio/flwrap/flwrap.spec?rev=33da1ba3e8d70b7215b6b10835026cf2& #Lets rename the crazy file name mv flwrap.spec?rev=33da1ba3e8d70b7215b6b10835026cf2& flwrap.spec vim flwrap.spec -- Under the BuildRequires: line, remove the entries: xorg-x11-devel and update-desktop-files Change the release reflect the right version Change the Source: line to alter the file suffix from .bz2 to .gz delete the line that reads: %debug_package Make the %configure line read: %configure --enable-optimizations=native Change the make line to read: make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" Replace the line that says: %suse_update_desktop_file -i flmsg with desktop-file-install --vendor="" \ --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \ $RPM_BUILD_ROOT%{_datadir}/applications/flmsg.desktop # --vendor obsolete per new guidelines but leaving it in because # this is an existing package with vendor previously installed Add your own revision entry at the bottom Next, regardless of using my SPEC file your you building your own, make sure the version number reflects the current version of Flwrap Now let's build and install it: cd /usr/src/redhat/SPECS/ #For Centos6 users with x86_64 rpmbuild -bb --target=x86_64 flwrap.spec rpm -ivh /usr/src/redhat/RPMS/x86_64/flwrap-1.3.2-1.x86_64.rpm #For Centos5 users with i686 rpmbuild -bb --target=i686 flwrap.spec rpm -Uvh /usr/src/redhat/RPMS/i686/flwrap-1.3.2-1.i686.rpm After it's installed, you really don't need to run Flwrap directly as Flmsg will call it when needed. But there is a benefit of running it directly: drag and drop! You can drop files into it and it will do the equivalent of UUencode and UUdecode and send it over the air with CRC checks to make sure it gets there ok Let's run it: /usr/bin/flwrap & Flamp is an associated Fldigi program that reliably sends binary files to a list of remote stations in a classic HF "broadcast" fashion. To do this reliably, Flamp breaks the files up into small blocks and then broadcasts them. If a given block is lost to a specific station (or all stations), the stations can request a resend of that specific block until the file is properly received. --------------------------------------------------- NOTE: this program is OPTIONAL and doesn't require Fldigi to run or vice versa --------------------------------------------------- Ok, let's get on with it. It's new so we have to piece a SPEC file together a bit: cd /usr/src/redhat/SOURCES wget -O flamp-1.0.0.tar.gz http://www.w1hkj.com/downloads/flamp/flamp-1.0.0.tar.gz # To get a SPEC file, you can either use my .spec file (recommended) or # create your own: # My recommended SPEC file: cd /usr/src/redhat/SPECS wget -O flamp.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/flamp.spec # Skip to the next part since you're not making your own SPEC file # If you want to create you own SPEC file, first get an example SPEC file Next, lets get an example SPEC file cd /usr/src/redhat/SPECS wget https://api.opensuse.org/public/source/hamradio/flamp/flamp.spec?rev=89eaf05c45d00f17b3318769033c4f0b& #Lets rename the crazy file name mv flamp.spec\?rev\=89eaf05c45d00f17b3318769033c4f0b flamp.spec vim flamp.spec -- Under the BuildRequires: line, remove the entries: xorg-x11-devel and update-desktop-files Change the release reflect the right version Change the Source: line to alter the file suffix from .bz2 to .gz Make the %configure line read: %configure --enable-optimizations=native Change the make line to read: make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" Replace the line that says: %suse_update_desktop_file -i flamp with desktop-file-install --vendor="" \ --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \ $RPM_BUILD_ROOT%{_datadir}/applications/flamp.desktop # --vendor obsolete per new guidelines but leaving it in because # this is an existing package with vendor previously installed Add your own revision entry at the bottom Next, regardless of using my SPEC file your you building your own, make sure the version number reflects the current version of Flamp Now let's build and install it: cd /usr/src/redhat/SPECS/ #For Centos6 users with x86_64 rpmbuild -bb --target=x86_64 flamp.spec rpm -ivh /usr/src/redhat/RPMS/x86_64/flamp-1.0.0-1.x86_64.rpm #For Centos5 users with i686 rpmbuild -bb --target=i686 flamp.spec rpm -Uvh /usr/src/redhat/RPMS/i686/flamp-1.0.0-1.i686.rpm Once installed, start up Flamp with: /usr/bin/flamp & Once the program starts, click on the "Configure" tab. In there, fill in your callsign and your your station's QTH / details in the "Info section. Beyond that, the use of Flamp is well documented at: http://www.w1hkj.com/flamp-help/index.html Flwkey is a program that can control K1EL Win-keyer enabled kits, specifically for me, the W1EL WinKeyer that's built into a US Interface Navigator. --------------------------------------------------- NOTE: this program is OPTIONAL and doesn't require Fldigi to run or vice versa --------------------------------------------------- Ok, let's get on with it. It's new so we have to piece a SPEC file together a bit: cd /usr/src/redhat/SOURCES wget -O flwkey-1.1.2.tar.gz http://www.w1hkj.com/downloads/flwkey/flwkey-1.1.2.tar.gz # To get a SPEC file, you can either use my .spec file (recommended) or # create your own: # My recommended SPEC file: cd /usr/src/redhat/SPECS wget -O flwkey.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/flwkey.spec # Skip to the next part since you're not making your own SPEC file # If you want to build your own SPEC file, do the following: - First, lets get an existing SRPM file cd /usr/src/redhat/SRPMS wget -O flwkey-1.0.0-1.1.src.rpm http://ftp.w1nr.net/opensuse/repositories/hamradio/openSUSE_11.1/src/flwkey-1.0.0-1.1.src.rpm cd /usr/src/redhat/SPECS vim flwkey.spec -- Under the BuildRequires: line, remove the entries: xorg-x11-devel and update-desktop-files Change the release from 1.1 to 1.0 Change the Source: line to alter the file suffix from .bz2 to .gz delete the line that reads: %debug_package Make the %configure line read: %configure --enable-optimizations=native Change the make line to read: make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" Replace the line that says: %suse_update_desktop_file -i flwkey with desktop-file-install --vendor="" \ --dir=${RPM_BUILD_ROOT}%{_datadir}/applications \ $RPM_BUILD_ROOT%{_datadir}/applications/flwkey.desktop # --vendor obsolete per new guidelines but leaving it in because # this is an existing package with vendor previously installed Add your own revision entry at the bottom Next, regardless of using my SPEC file your you building your own, make sure the version number reflects the current version of Flwkey Ok, now let's build and install it: cd /usr/src/redhat/SPECS/ #For Centos6 users with x86_64 rpmbuild -bb --target=x86_64 flwkey.spec rpm -ivh /usr/src/redhat/RPMS/x86_64/flwkey-1.1.2-1.x86_64.rpm #For Centos5 users with i686 rpmbuild -bb --target=i686 flwkey.spec rpm -Uvh /usr/src/redhat/RPMS/i686/flwkey-1.0.0-1.i686.rpm Let's run and configure it: /usr/bin/flwkey & Goto Configure --> Select Ports Enter in the proper /dev/ name for your W1EL WinKeyer. If you are using udev as configured in the first Fldigi section it would be /dev/USI_WKEY. Else, if you're using a US Interface Navigator and have the HamPacket script, run: /usr/local/bin/usinterface-ident.sh to see and choose the right address. Usually for my non-UDEV machine, it's /dev/ttyUSB2 Once properly selected and if Flwkey can communicate to the Winkeyer, it should show the versions, such as: Flwkey version: 1.1.2 Wkeyer version 22 Next, goto Configure --> Operator CLL: - for me, KI6ZHD OPR: - David QTH: - Santa Clara, CA LOC: - CM97ai Next, goto Configure --> Parameters ModReg: Tone ON - Enabled PTT ON - Disabled Output Pins: Key 1 (for an FT950 Next, as of Flwkey 1.1.2, it cannot directly configure how to key up (PTT) the rig but per the following URL: http://www.trinityos.com/HAM/US-Interface/us-interface-navigator-and-linux.html#navigator-config You can get the WinKeyer in a US Interface Navigator to assert PTT using the secondary PTT line, do the following (assuming the US Interface Navigator config line is on /dev/USI_CFG using a UDEV enabled setup: #Set the serial port to 1200 baud stty -F /dev/USI_CFG speed 1200 #initialize the CONFIG port - do it twice echo -e "KT/r" > /dev/USI_CFG echo -e "KT/r" > /dev/USI_CFG #Enable Winkeyer PTT - this is a bit pattern with the LSB or Lowest # significant bit on the left echo -e "KL11111111111/r" > /dev/USI_CFG #If you'd like to save these settings as the default echo -e "KS/r" > /dev/USI_CFG Ok, time to give it a try. Assuming the Winkeyer is powered up, the radio is on, the antenna is tuned up, and the selected frequency is clear, click on the "TUNE" button in the lower right hand corner. If things are setup working properly, you could see your radio get keyed up and hear a SOLID tone. Next, in the "STA" field, type in your callsign, click on the "Send" button so it's light stays lit, and then click on the "call button". At that point, you should start calling yourself over the airwaves! 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 Fldigi can be a lot more than just making QSOs and contacts with digital modes. It has an extensive API set to communicate with other programs for both higher level and now, lower level systems. This section calls out some of the different integration possibilities with Fldigi and other programs.
+---------------------------+ | To be updated for Centos6 | +---------------------------+ PSKmail is an interesting fusion of a system where emails are coded into CRC checked binary blobs and sent via automatically selected PSK 250/500, Olivia, etc. via FLdigi. The program is all Java based and uses Fldigi as the backend. These instructions assume you have Fldigi fully working with the XMLRPC backends compiled in. Assuming the following: PSKmail 0.5.4 Oracle/Sun Java 7 v67 NOTE: This section needs to be updated. It's recommended to use Oracle Java 8 or newer. See: http://tecadmin.net/install-java-8-on-centos-rhel-and-fedora/ for more details for now Dependencies: ------------- Java JRE (Java Runtime Environment) # Get the JRE # ----------- # NOTE #1: Oracle does not offer a Yum repository for Java so you have # to keep it up to date yourself # # NOTE #2: Get the 64bit version if you have 64bit browser installed # check with 'rpm qa | grep firefox' and look for x86_64 # Go to https://www.java.com --> Download As of 9/23/17, the current version of Java JRE is v8 Update 144 Download the required 32/64bit version via your web browser or use the links below #Via the CLI cd /tmp #64bit RPM version - 56MB http://javadl.oracle.com/webapps/download/AutoDL?BundleId=225344_090f390dda5b47b9b721c7dfaa008135 #32bit RPM version - 59MB http://javadl.oracle.com/webapps/download/AutoDL?BundleId=225342_090f390dda5b47b9b721c7dfaa008135 Now look at the text of the above command to decipher the actual version being downloaded: mv "AutoDL?BundleId=225344_090f390dda5b47b9b721c7dfaa008135" jre-8u144-linux-x64.rpm - As root, run: sudo rpm -Uvh jre-8u144-linux-x64.rpm - make sure that /etc/alternatives/java is pointing to the newest location. The Sun installer does NOT update the Centos alternatives system: ls -la /etc/alternatives/java #Make sure that latest points to the /usr/java/jre1.8.0_144 path ls -la /usr/java/ | grep latest If it doesn't then do: sudo rm /etc/alternatives/java sudo ln -s /usr/java/jre1.8.0_144/bin/java /etc/alternatives/java - Make sure the other Java links are in place ls -la /usr/java/ # Make sure that both "default" and "latest" point to the new version of the JRE - Make sure Java is working. In a new shell as a regular user, run: java -version The response out of that should be the expected version, etc - If you want Java to work within your web browser, you need to create a symlink for the java plugin #for 64bit browsers cd /usr/lib64/mozilla/plugins/ ln -s /usr/java/latest/lib/amd64/libnpjp2.so . #for 32bit browsers cd /usr/lib/mozilla/plugins/ ln -s /usr/java/latest/lib/i386/libnpjp2.so . #restart firefox for it to load the new settings. Then go to Tools --> Add-ons --> Plugins and look for "Java (tm) Plug-in" which must be present for things to work Download the pskmail code: cd /usr/src/archive mkdir Pskmail NOTE: It seems the "released" version of code for Pskmail is usually rather old. It's recommended you always download the newest Alpha version of code. See http://www.pskmail.org/PSKMaildownloads.html to find out the newest release version #For example, downloading the current newest version wget http://pskmail.org/downloads/jPSKmail-2.0.19.jar Install RXRX libraries - (optional) Used only if you plan on connecting a GPS to your PSKmail system - cd /usr/src/archive/PskMail/jpskmail - cp librxtxSerial.so /usr/java/latest/lib/i386/ - cp lib/RXTXcomm.jar /usr/java/latest/lib/ext/ #For Centos5 machines: http://pkgs.org/fedora-13/fedora-i386/rxtx-2.2-0.1.20100211.fc13.i686.rpm.html Prep your Centos to support lock files for the user who will be running PskMail: usermod -G lock NOTE: Once I added myself to the "lock" group, no matter what I did, the output of 'groups' and 'groups dranch' would not match. I had to restart Xwindows to get things to sync up. Beware! First, start up Fldigi as you would normally. Then, do: Setting up Fldigi: - On the Radio (mine is a Yaesu FT-950, set the VFO to 10.147.00 and make sure the antenna is all tuned up, power is set to a max of 45watts, etc. - In Fldigi: --> Configure --> Waterfall --> Display UNCHECK: Monitor transmitted signal --> Misc --> PskMail - Mail Server Attributes - Carrier Frequency: 1000 Hz - Search Range: 10Hz - Acquisition SN: 6db - AFC range: 10hz - Reset to Carrier: Enabled - General: turn on Report ARQ frames average S/N --> ID - Under "Reed-Solomon ID (Rx), uncheck all items - Click on save Run jPskMail cd /usr/src/archive/PskMail/jpskmail java -jar javapskmail.jar Go to Edit --> Preferences User Data Callsign: -SSID (I'm using KI6ZHD-7) Link to: ki6zhd Server mode: Latitude: (37.2061) Longitude: (-121.5999) Beacon: Rig: Checkmark "Rigcontrol" assuming you have this working under Fldigi To read the manual, open up another shell and do: acroread jpskmail_manual.pdf Starting with Fldigi 3.22.03 (GIT version or newer) or 3.23.10.10 (Alpha), it now supports both a TCP and UDP-based "KISS" interface. A KISS interface is commonly found with classic 300 / 1200 / 9600 HF and VHF packet TNCs but this combination will allow AX.25 enabled Linux machines to leverage all the modern digital modems in Fldigi. You'll be able to tie them into Linux's AX.25 stack for say keyboard to keyboard chat, BBS, Winlink, whatever. Quite cool! This interface can also be used by other programs like UI-Chat or any client program that supports TCP-KISS. I personally think this new found flexibility will provide a massive improvement to HF packet communications compared to the classic 300BAUD AFSK mode in terms of reliability and less retries. It's worth noting that only the widest of Fldigi modes will approach classic 300BAUD HF Packet's "speed". I put "speed" in quotes as that would only be true if it was reliable on HF (which IMHO, it isn't). If there are way too many retries, the payload speed goes to ZERO! In Fldigi 3.23.10.08 Alpha, this network based KISS support was further enhanced to add TCP-KISS. The UDP method was quite fragile but this TCP version already seems to be substantially more simplified and reliable. To get started, you need to follow the previous Linux AX.25 sections of this document and get your Linux AX.25 stack ready. You'll also need to install and configure Fldigi v3.23.10.08 or newer. If you don't have both of those working, please go to those sections and do that now. Ok, now that you have both Linux AX.25 and Fldigi working, the next thing to consider is that Fldigi does NOT support KISS via serial PTYs like what how Linux's kissattach expects. Fldigi instead uses the Linux machine's TCP/IP stack to communicate the KISS frames. To link the two systems together, a tool called "socat" will be used. Socat can do an amazing amount of different things.. from it's readme, it says: -- socat can be used, e.g., as TCP port forwarder (one-shot or daemon), as an external socksifier, for attacking weak firewalls, as a shell interface to UNIX sockets, IP6 relay, for redirecting TCP oriented programs to a serial line, to logically connect serial lines on different computers, or to establish a relatively secure environment (su and chroot) for running client or server shell scripts with network connections. -- Socat's amazing flexibility provides the necessary communication link between the two programs. Let's install it: #Install socat - this installs 1.7.2.4 on Centos6 from RPM-Forge # # - NOTE: EPEL's has an older version of socat which has known bugs # sudo yum --disablerepo=epel install socat Next, we need to configure the AX.25 system for your new SSID. All SSIDs on your system need to be UNIQUE system, regardless of AX interface and/or radio frequency. To figure out what SSIDs are in use on your machine, use the following command while your regular packet system is running: #On my station, I have KI6ZHD (that's -0), -1, and -2 for Linpac and -5 for UroNode # in use $ netstat -A ax25 -an Active AX.25 sockets Dest Source Device State Vr/Vs Send-Q Recv-Q KI6ZHD-2 ax0 LISTENING 000/000 0 0 KI6ZHD-1 ax0 LISTENING 000/000 0 0 KI6ZHD-0 ax0 LISTENING 000/000 0 0 KI6ZHD-5 ax0 LISTENING 000/000 0 0 So I'll add -8 for my Fldigi based HF station. First, edit the /etc/ax25/axports file and add an interface identifier for your HF link. Here, I'm calling it "fld" but you can name it anything you want: # name | callsign | speed | paclen/mtu | window | description fld KI6ZHD-8 0 64 2 7.073MHz (300baud) Please note that the 0 BAUD is really a "serial port thing" and really won't be used here. What is import is the 64byte MTU and the 2 packet window. In classic HF packet, 64byte packets and two total outstanding frames is a way to minimize too data being sent (and lost) and thus creating too many retransmit requests. Now that you'll be potentially be using Fldigi modes that have built-in FEC, you might consider increasing this depending on propagation conditions, etc. The maximum value allowed MTU setting is 256 but please note that you must also adjust the AX.25 T1/T2/T3 timers to account for the transmission time and reception time of the remote ACK. The stock AX.25 maximum value for T1 is 30 seconds so keep that in mind. Next, download the following Socat shell script: http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/fldigi-socat-packet.sh This is the script that interconnects Fldigi to Linux's AX.25 stack via the socat program. You now need to edit this script and put in all your specific distro's execution paths for certain programs, enter in your specific CALLSIGN-SSID, etc: +---------------------------------------------------------------------------+ | NOTE: | | It's important you edit and update at least the following | | variables for system's use | +---------------------------------------------------------------------------+ #System binaries location NETSTAT="/bin/netstat" KISSATTACH="/usr/sbin/kissattach" MHEARDD="/usr/sbin/mheardd" LISTEN="/usr/bin/listen" KISSPARMS="/usr/sbin/kissparms" IFCONFIG="/sbin/ifconfig" SOCAT="/usr/bin/socat" # This will need to be updated depending on how many ax0 interfaces # are already present in ifconfig AX25HFINT="ax0" AX25HFPORT="fld" LOCALIPPORT="127.0.0.1:7342" FLDIGIPTYFILE="/var/tmp/fldigi-dev" AX25PTY="/tmp/ax25-config.tmp" AX25PTYFINAL="/tmp/ax25-config2.tmp" #Fldigi mode: TCP or UDP SOCATMODE="TCP" #User specific settings - change these to match your callsign and AMPR IP address AMPRIP="44.4.00.01" AMPRNM="255.255.255.128" CALLSIGN="N0CALL-8" Important: ---------- The other important issue here is to READ the various comments at the top of this script as specific MANUAL initialization is REQUIRED if you use Fldigi's UDP-KISS mode and want you your system to work. This manual initialization approach seems to be a limitation of SOCAT but I'm not 100% sure. This is NOT an issue with the TCP-KISS approach.

Ok, next, start up Fldigi and goto: - Configure --> IO (that's Input/Output) - Uncheck : LOCK - Check : Enable KISS - Check : AX25 decode - Optional : Enable CSMA - Under the KISS section: Checkmark: TCP Checkmark: Listen / Bind - IP Address : 127.0.0.1 - I/O port : 7342 - Check : Enable Busy Channel - Continue After : 3 sec - KPSQL Attenuation: 2 - Click on the "CONNECT" button to start the network socket - Save Now back in the main Fldigi window: - Pick an HF digital mode you want to use (I would recommend something like PSK250R) to start off with (some decent speed, not too wide, not too slow): NOTE: Not all modes in Fldigi are capable to send binary data. Specifically modes like CW, RTTY, etc will refuse to get enabled either because they aren't 8-bit clean or they are too slow). If you try and select an incompatible mode, an error will be shown in the Help --> Event Log window but the current general selection includes BPSK, 8PSK, MFSK, THOR, Contestia, Olivia and MT63 at various baud rates. - Turn OFF Fldigi's TxID for mode identification as this takes too long to transmit and thus, it impacts the overall AX.25 T1 timer settings - QSY your HF radio to an available, desired digital frequency (please review the various automatic-mode HF spectrum band plans) - http://www.iaru-r2.org/band-plan/ - lower the radio RF power to the right level (usually < 50w on a 100w radio) as to not damage your radio's RF finals as well as ensure minimal ALC distortion effects, etc - Tune/Match the antenna to your radio's frequency - Ok, now run the script you just edited: sudo /usr/local/sbin/fldigi-socat-packet.sh start The output should look similar to below: -- Clean out any old stale fldigi-socat-packet.sh setups first Clearing any previous listen for device: fld Clearing any previous mheard for device: fld Clearing any previous kissattach for device: fld Clearing any previous socats for device: fld Wait for 3 seconds Confirm Fldigi connection is set to 'LISTENING' tcp 0 0 127.0.0.1:7342 0.0.0.0: LISTEN Removing any stale Fldigi PTY file Loading required kernel modules: mkiss ax25 Starting SoCAT in TCP mode from /var/tmp/fldigi-dev to 127.0.0.1:7342 Fixing pty permissions Actual PTY is: /dev/pts/3 Confirm two 'ESTABLISHED' Fldigi connections: tcp 0 0 127.0.0.1:7342 127.0.0.1:46927 ESTABLISHED tcp 0 0 127.0.0.1:46927 127.0.0.1:7342 ESTABLISHED Updating ax0 for Persistence, slot, TX-Delay Updating ax0 for AX.25 timing parameters Setting Generic AX25 settings Setting HF packet centric settings (compared to say VHF packet) Setting Mode specific settings - PSK250R Starting mheardd Starting listen and sending to /var/log/packet.log MANUAL step: Consider running the following command: beacon -c KI6ZHD-8 -d beacon -t 10 fld KI6ZHD Fldigi TCP-KISS from Santa Clara, CA Completed -- At this point, everything enabled for AX.25 packet will now work just like it would over AFSK 300/1200 or FSK 9600 baud packet! Programs like "linpac", "call / axcall", etc will just work but now over HF with your chosen selection various Fldigi fast/less-FEC vs. slower/more-FEC (aka robust) modes! Only time will tell to see what mode might emerge to become the new digital packet mode for HF! BTW, you might consider downloading my axctl shortcut script at: http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/ax25-kill-packet-connection.sh This script makes the early termination of existing AX.25 and Netrom connections must easier. That can save your radio from making a lot of useless retries to a previous station that's no longer reachable due to the HF band changing. TrustedQSL is the logging system for Logbook of the World (LOTW) which is a X.509 certificate based Authentication and Authenticity system. This is the Linux tool to submit QSO logs for official credit with the ARRL. This LOTW system allows HAMs to start working towards various HAM radio operation awards via a fully electronic logging system (vs. using paper logs), authenticate your HAM radio license to use other services like Echolink, etc. You can learn more about this system at: http://www.arrl.org/logbook-of-the-world This is the main window for creating and renewing LOTW certificates

There are two ways to install TrustedQSL today: 1. (EASIEST): Add the EPEL repo per the "Third Party RPM repositories" section above and at that point, simply run: sudo yum install trustedqsl As of 8/26/17, this will install versions: trustedqsl-2.3-1.el6.x86_64 tqsllib-2.5-4.el6.x86_6 tqsllib-devel-2.5-4.el6.x86_64 2. Installing from source : This approach always gets you thew newest version of code but is always a bit of work. +-------------------------------------------------+ | Work in Progress to upgrade to 2.1.2 on Centos6 | +-------------------------------------------------+ If you're going to install via souce, lets get started. As of Oct 11, 2015, the current versions of code were: http://sourceforge.net/projects/trustedqsl/files/TrustedQSL/ -- TrustedQSL : 2.1.2 (was 2.0) tqsllib : 2.4 NOTE: Alternatively, you can look at: http://www.arrl.org/tqsl-download It might be good to check the following URL to confirm that this code is the newest available - Get the required sources (this example is using TQSL v2.0): cd /usr/src/redhat/SOURCES wget http://downloads.sourceforge.net/project/trustedqsl/TrustedQSL/v2.1.2/tqsl-2.1.2.tar.gz - Next, we need to install some dependencies: #From EPEL - this archive will also install "bakefile" and "python-empy" on Centos6 machines # # openssl 1.0.1j or better - BAD - Centos6.7 comes with 1.0.1e # expat 2.1.0 or better - BAD - Centos6.7 comes with 2.0.1 # zlib 1.2.8 - BAD - Centos6.7 comes with 1.2.3 # wxWidgets 2.8.12 - OK - Centos6.7 comes with 2.8.12 # curl 7.39.0 - BAD - Centos6.7 comes with 7.19.7 # BDB 6.1.19 - BAD - Centos6.7 does not support Berkeley DB 6 and worse, has a # changed and bad OpenSource license # Fyi, 3rd party RPM requires ftp://rpmfind.net/linux/sourceforge/r/ra/ramonelinux/Rel_0.99/releases/x86_64/packages/db-6.1.19-1.ram0.99.x86_64.rpm requires Glibc # 2.14 but Centos6 comes with 2.12 # from Source- http://download.oracle.com/berkeley-db/db-6.1.26.tar.gz # yum install curl libcurl-devel openssl openssl-devel expat expat-devel wxGTK-devel zlib zlib-devel Tqsl v2.0.1 / tqsl-lib 2.4 compiled successfully with: # openssl 1.0.1e # expat 2.0.1 # zlib 1.2.3 # wxWidgets 2.8.12 # curl 7.19.7 # db 4.7.25 #Need to build Berkeley DB 6.x from scratch cd /usr/src/redhat/SOURCES wget http://download.oracle.com/berkeley-db/db-6.1.26.tar.gz #Prepare the archive to work with an RPM spec file cd /usr/src/redhat/BUILD tar xzvf ../SOURCES/db-6.1.26.tar.gz mv db-6.1.26 db6-6.1.26 tar czvf ../SOURCES/db6-6.1.26.tar.gz db6-6.1.26/ rm ../SOURCES/db-6.1.26.tar.gz #get an example db4 spec file cd /tmp wget https://kojipkgs.fedoraproject.org//packages/db4/4.8.30/4.fc17/src/db4-4.8.30-4.fc17.src.rpm rpm -ivh db4-4.8.30-4.fc17.src.rpm #TrustedSQL 2.x+ requires a more modern version of Cmake (at least 2.8.0) or newer # or the build will send the error: # # "CMake 2.8 or higher is required. You are running version 2.6.4" # # NOTE #1: Per the following URL, Cmake versions later than Cmake 2.8.3 are # available but evidently have bugs when building things like boost. # As such, installing Cmake 2.8.8 will work now but will create # frustrating problems later if you want to install gnuradio, etc # # More details at: # http://stackoverflow.com/questions/9948375/cmake-find-package-succeeds-but-returns-wrong-path # http://ros-users.122217.n3.nabble.com/ROS-Installation-on-Red-Hat-No-rule-to-make-target-lib64-lib64-libboost-thread-mt-quot-td4018527.html # # # In the GnuRadio section, I detail how to build a modern, fixed version # of cmake if you want to get ahead of things. If not, this cmake-2.8.8 # RPM will work fine for TrustedQSL for now # # # NOTE #2: You can also install this from the EPEL repository by installing # "cmake28" which as of 12/14/13, will install cmake 2.8.11 but I # personally think this is a bad idea to mix build programs like # this. I personally recommend to either build a modern version # as mentioned above or do the following: # yum install http://pkgs.repoforge.org/cmake/cmake-2.8.8-1.el6.rfx.x86_64.rpm - For this example, we will build for TrustedQSL: 2.0 tqsllib : 2.4 Ok, now we need to get the RPM spec files for the archive. The tqsl-2.0.tgz file does come with two spec files but they are: - Broken, they don't work right - is not 64bit aware for proper lib64 library paths - Reflect the old TrustedQSL v1.x program which broke things into two different RPMs using the same sources A new RPM spec file from Richard Shaw resolves all of these things via a near rewrite. This archive will be soon available in the Fedora EPEL repository but until then, you can get the spec file from my site: wget -O flwkey.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/trustedqsl.spec Please note that I've altered a few things in the spec file to not assume that people are using different RPM naming, etc. I'm working with Richard to see if he will make his RPM a bit more flexible - Ok, time to compile and install it: cd /usr/src/redhat/SPECS/ rpmbuild -bb --target=x86_64 trustedqsl.spec # # We must install it before going to the next step cd cd /usr/src/redhat/RPMS/x86_64 rpm -Uvh trustedqsl-2.0-1.el6.x86_64.rpm tqsllib-2.4-1.el6.x86_64.rpm tqsllib-devel-2.4-1.el6.x86_64.rpm ----------------------------------------------------------------------------- Centos 5 Users: DEPRECATED: The below text reflects the previous version of TrustedQSL and needs to be updated for v2.0. Try using the above Centos6 steps and if it doesn't work / and you need help with it, please let me know. ----------------------------------------------------------------------------- # NOTE: For Centos5 users, several steps might still be required. Here are the # legacy notes Take the SPEC file from the FedoraProject and: - update it for version 2.2-1 - remove the SSL patch #Edit the rpmbuild -bb --target=i686 tqsllib.spec -- -7, -8, and -9 fails with error: unpacking of archive failed on file /usr/src/redhat/SOURCES/tqsllib-2.0-openssl.patch;4ae25fe5: cpio: MD5 sum mismatch -- #You must install the devel libs before being able to compile # trustedqsl rpm -Uvh /usr/src/redhat/RPMS/i686/tqsllib-2.0-5.i686.rpm /usr/src/redhat/RPMS/i686/tqsllib-devel-2.0-5.i686.rpm #now compile and install: # # note: must use the FC9 version # Download a sample SPEC file from: http://koji.fedoraproject.org/koji/packageinfo?packageID=72670 Download the newest sources from: http://sourceforge.net/projects/trustedqsl/files/TrustedQSL/ and put them in /usr/src/redhat/SOURCES/ rpmbuild -bb --target=i686 trustedqsl.spec fails with: + desktop-file-install --dir=/var/tmp/trustedqsl-1.11-2-root-root/usr/share/applications tqsl.desktop Must specify the vendor namespace for these files with --vendor error: Bad exit status from /var/tmp/rpm-tmp.29990 (%install) Take the SPEC file from the FedoraProject trustedqsl-1.11 SRPM and: #This is from the terminator tool which is a multi-window terminal app: # http://www.tenshu.net/terminator/terminator-screenshots/ # desktop-file-install --dir=%{buildroot}%{_datadir}/applications tqsl.desktop --vendor="" desktop-file-install --dir=%{buildroot}%{_datadir}/applications tqslcert.desktop --vendor="" # Update the versions in the SPEC from 1.11 to 1.13 # Remove all references to Patch0 (icon patch) # Go into /usr/src/redhat/SOURCES and cp TrustedQSL-1.11-icon.patch TrustedQSL-1.13-icon.patch cp TrustedQSL-1.11-gcc43.patch TrustedQSL-1.13-gcc43.patch cp TrustedQSL-1.11-lib64.patch TrustedQSL-1.13-lib64.patch #Recreate the RPM file: rpmbuild -bb --target=i686 trustedqsl.spec #With the new 1.13 version, having issues with: tqslwiz.cpp: In member function 'void TQSLWizCertPage::UpdateFields(int)': tqslwiz.cpp:118: error: 'tqsl_getLocationFieldFlags' was not declared in this scope tqslwiz.cpp: In constructor 'TQSLWizCertPage::TQSLWizCertPage(TQSLWizard, void)': tqslwiz.cpp:258: error: 'tqsl_getLocationFieldFlags' was not declared in this scope ### ### Sent email on 03/06/2011 to get help but was NEVER able to get ### any answers from ANY of the SourceForge developers. Had to stick ### with the 1.11 version ### rpm -Uvh /usr/src/redhat/RPMS/i686/trustedqsl-1.11-2.i686.rpm +---------------------------------+ | Needs to be updated to TQSL 2.0 | +---------------------------------+ You now have TQSL is installed! To run the program, run the following as your usual username login (NOT ROOT): /usr/bin/tqsl Please note that previous version of Tqsl had a program called "tqslcert" which has now been merged into the main "tqsl" program Once loaded, you can read the online documentation or follow the documentation on the LOTW website on how to set it up! A few key points: - Once fully configured, the program will create the following: tqsl - the primary program to sign and optionally submit Cabrillio and ADIF logs for LOTW credit. This program also creates and renews TQSL callsign x.509 certificates and the following files and directories: $HOME/.tqsl - the config directory $HOME/.tqslapp $HOME/.tqslcert In the .qsl directory, there are two main files: your-callsign.tq5 - is a certificate request / renewal file you created your-callsign.tq6 - is a ARRL LOTW signed file to finalize your certificate - TQSL Certs used in LOTW are valid for three years. I received an email notification from the LoTW team ONE MONTH before my original certificate expired. I highly recommend to add a calendar reminder onto your Smartphone, calendar, etc. 2yrs and 11 months (35 months) from now to remind you to renew your certificate again. Why? It will make your life a lot easier if you renew (actually create a new certificate via signing it with your ABOUT-TO-EXPIRE certificate) before the old one expires. Why (sheesh.. you ask a lot of questions... :-) LOTW certificates are only used to validate QSLs. They are NOT specifically tied to your or anyone's callsign. As such, if a certificate expires, gets lost due to a drive crash, etc., the cert will have NO bearing on previous/future QSL credit for your callsign, etc. http://www.arrl.org/renew-certificate BTW, all of ARRL's documentation might be nice and dandy but it might not be all that clear how to SUBMIT LOGS to say LoTW and Eqsl.cc! Two sections below is my quick LOTW/Eqsl FAQ that I use every time using the "tqsl" program. This will get an update as the tqsl program now supports direct log uploads to the LOTW website. BTW, some programs like Xlog or some macros on Fldigi try to automate this log submission even after every single QSO. I hadn't gotten to that point due to previous issues with Centos 5 and old libraries but now that I'm on Centos 6, I hope to work on that soon:

HOWTO-eqsl-lotw-contest-upload.txt



LoTW certificates last exactly three years and they MUST be renewed before the old one expires. As mentioned in the previous section, the LoTW system should email you a notice of it expiring. If you don't renew this BEFORE your old cert expires, the process gets a LOT more tedious. So, let's say you got an email from the LoTW people that your cert is going to expire OR you loaded up LoTW and you saw the above screen shot. 1. Load up /usr/bin/tqsl 2. Click on YES to renew your certificate 3. You should be prompted to fill in two dates: - When you made your first QSO (this should be pre-populated but put in the date when you first received any form of an Amateur radio license. For me, I put in the date when I received my technician class license. - When you made your last QSO (leave this all blank) - Click "next" 4. Fill out your address that is reflected in your license and click "Next" 5. Put in a valid email address for you 6. You will be prompted if you want to add a passphrase to your certificate. I generally recommend to do this to secure your certificate as it's sent through the untrusted SMTP email system, etc. It's critical to NOT loose this password or you'll have to request a new certificate which takes longer than to request a new certificate. 7. You'll be asked if you want to submit your application for a new certificate, click on Next 8. If you added a passphrase to your expiring certificate, enter that in now. At this point, you should see something like the following: -- Attempting to upload Certificate Request Certificate Request uploaded with result: Started processing your Renewal Certificate Request. For call sign: KI6ZHD For DXCC Entity: UNITED STATES OF AMERICA (291) For QSOs not before: 20xx-xx-xx 00:00:00 For QSOs not after: Your renewal certificate request is accepted and awaiting further processing. You will receive the certificate after it has been created. Your certificate request processing is completed. These results have been emailed to --email-address-- -- After the submission, you should soon receive an automated email from the LOTW system that says something like: -- To: <your email address> From: <> Subject: Automated response to your LoTW request Date: Fri, 21 Sep 2018 02:21:36 +0000 Started processing your Renewal Certificate Request. For call sign: KI6ZHD For DXCC Entity: UNITED STATES OF AMERICA (291) For QSOs not before: 20xx-xx-xx 00:00:00 For QSOs not after: Your renewal certificate request is accepted and awaiting further processing. You will receive the certificate after it has been created. Your certificate request processing is completed. -- Now you wait until you get your new cerificate from the LOTW to the email address you specified. This email will look something like: -- Subject: LoTW Certificate To: <your email addr> From: <> Date: Fri, 21 Sep 2018 12:45:18 +0000 IMPORTANT NOTE: This certificate requires TrustedQSL Version 2.0 or later. Attempting to install it using an earlier version of the TrustedQSL software will result in errors. The latest TrustedQSL software can be obtained at: https://lotw.arrl.org/lotw-help/certaccept/ ======================================================= Here is your LoTW certificate for KI6ZHD You should be able to install this certificate by double- clicking on the attachment icon. If that isn't possible or doesn't work, save the attached file to disk and then use the TQSL program's "Load Certificate File" menu command to install this certificate into your system. NOTE: If the attachment failed to arrive with this message, you can just log on to the Web site noted below using the provided username and password and download the certificate file directly. Records submitted using this certificate can be accessed on the LoTW web site using the credentials: username: ki6zhd password: <some-DIFFERENT-clear-text-password-that-lotw-thinks-is-ok-to-send> by logging in at ======================================================= NOTE! This is NOT the same password the TQSL program may ask for when you're signing a log file!" -- At this point, you want to do two things: 1. Save the <your-callsign>.tq6 attachment as a file on your computer 2. Save the email to a safe place just in case (or you can delete it if you really wish) Now do the following: 1. start up the /usr/bin/tqsl program with your usual username (not root). 2. Select Callsign Certificate --> Load Callsign Certificate from File 3. Find and select the <your-callsign>.tq6 file you previously saved and click on Open 4. You should receive a message saying: Callsign Certificate Loaded: Your-callsign (your name) DXCC = number-of-signed-qsos 5. Click on finish to complete the renewal That's it! You're good to go and your new certificate is valid for three years. WHen this certificate eventually approaches it's expiration, you shoudl again receive an email notification from the LoTW team about it. I I highly recommend to add a calendar reminder onto your Smartphone, calendar, etc. 2yrs and 11 months (35 months) from now to remind you to renew your certificate again as well. Most modern HAMs log their QSL contacts via on-line services like ARRL's LOTW and QRZ's eQSL. You'll see that once you get on the air and start making some QSOs (phone or digital modes), those HAMs are going to log the contact. It's best to get setup to honor their request (LoTW covered above)! What you'll also probably start to get is also some paper QSO cards coming in the postal mail directly from these HAMs! Some people consider this form of QSL confirmation as old school but I think it's still pretty cool to receive these. It's always best to reciprocate on sending a paper QSL cards back as well (not cheap) but the creation of QSL cards and how to best return those QSL cards still needs to be written. What this section is about is getting paper QSL cards through the Bureaus. What is a Bureau? Think of them as a country to country BULK mail system. Remote HAMs send their outbound QSL cards to their local country bureau inexpensively. From there, the country bureau sends aggregately batches of QSL cards to remote countries. The receiving country bureau will then send it to local bureaus. At that point, if you have an active account with that bureau, they will send you your bureau-based QSL cards usually when you accumulate one OUNCE worth of QSL cards. This is NOT a fast process as it can take many months (even YEARS as I've read) for QSL cards to get to you but they WILL get there. Bureaus: -------- One thing that WAS VERY surprising to me was that after about 1.5 YEARS after I became active in amateur radio, I received a postcard stating that I have QSL cards from the local bureau and I needed to supply self-addressed envelopes and stamps. Say what? What's all this about?! It's best to read about this volunteer FREE service (no ARRL membership required) first: http://www.arrl.org/incoming-qsl-service There is a specific protocol to get an active account into your local bureau. Some bureaus want you to send in a batch of self addressed stamped envelopes (SASE) where as others prefer you to supply a certain amount of money to pay them to provide the envelopes and postage to get those QSL cards to you. Read the above URL to learn more on how to get started but I highly recommend you get that setup. For me, since I'm a 6-call in California, I have to look at the "Sixth Call Area Service" on the above website to get those details. They prefer our in-state HAMs to provide money to buy their envelops and stamps but I have to provide self-sticking labels with my address on them. Some bureaus also have websites that let you query the status of your incoming QSL cards so that's pretty cool too. According to my 6-based bureau: http://www.qslbureau.org/cgi-bin/w6burosearch.cgi?query=ki6zhd I have 5 available envelopes, .60 in available postage, one QSL card and my last Bureau delivery was 12/14/2014. That's over 20 months ago. See what I said about NOT fast? That's just how it goes but then again, I haven't been doing a lot of QSOs so my incoming paper QSL card rate is probably VERY low. Btw, don't forget that if you move from place to place, to update the bureau with your new address! As part of any good amateur radio setup, people want a reliable contact logger. In general, I've found that there are a few specific categories of logger needs depending on the interest of the operator: - Casual logging : gathers all the usual contact information, optionally can upload contacts in ADIF or Cabrillo formats. No need for integrated spot clusters, support for prefill checks (a list of common contester callsigns to speed up data entry) or tracking different contest awards points. Examples include: Fldigi's internal logging Fllog - compatible with Fldigi's logging. Supports networked logging but doesn't track per contest awards, bonus points, etc. - Contester logging: Detailed programs that are very aware of different contest rules, their specific points and bonuses, with support for prefill checks and distributed networking to coordinate multiple HAMs at different stations. Some of the more elaborate programs have native support for some digital modes like CW, RTTY, PSK, Spot/Packet clusters, etc. Most popular contesting programs are only available for Windows such as N1MM, WriteLog, etc. 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 | +-----------------------------------------------+ 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 | +------------------------------------------------+ +---------------------------+ | 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 APRS or Automatic Packet Reporting System is a system built upon the classic AX.25 packet system to support a very flexible system for communication. Most people think of APRS as packet radio + a GPS for creating simple one-way tracking system but APRS is far more than that. APRS supports: - send two way APRS text messages to specific hams - send out one way bulletins to ALL HAMs in a specific region - send and receive two way email - create objects notifying other HAMs what's in the area like events, radio nets, and other things at specific times or places - Send out weather reports and emergency information - Interrogate remote APRS stations for additional information they might offer in an interactive fashion - Send out telemetry such as voltage, current, and anything else you can think of - sending out tracking coordinates - and more and more uses are being created every day Within APRS, there are a few primary containers of technology that do things: - APRS client : these are devices that at least send out APRS packets Trackers - usually TX-only devices sending GPS coordinates (posits) and maybe some other text APRS radios - Like the Kenwood D700/D710/D72/etc, they support both sending posits, TX/TX messages, etc Computer programs like Xastir that can display remote stations, WX warnings, etc, on a dynamic MAP say like OpenStreetMaps, etc. - APRS Server : these are programs that usually support digipeating APRS packets as a low-level (WIDE1) or high level (WIDE2) systems. Many of them also support being an IGATE or Internet Gateway that can local APRS packets into the Internet for display, messaging, etc. There are lots of APRS programs out there and here are a few of them: - Unix or Unix Compatible Clients - programs that typically have a GUI interface, show maps, show positions of remote stations, support messaging to remote stations, support IGATE functionality, etc - Xastir: graphical Unix client only supporting mapping, APRS messaging, etc. - YACC: graphical client written in Java - JavAPRS: graphical client written in Java - Polaric: graphical client written in Java http://aprs.no/dokuwiki/doku.php?id=polaricserver Servers - programs that typically do NOT have a GUI interface. They are usually used to run as an APRS digipeater, announce positions, telemetry, etc. but do not show maps, don't always support messaging, etc. - APRX: A powerful APRS server supporting complex digipeating and other functionality though it does NOT support APRS messaging. Covered in this HamPacket documentation in a later chapter http://thelifeofkenneth.com/aprx/ - Direwolf: A complete soundcard based TNC with full APRS server functionality though it doesn't support APRS messaging. Covered in this HamPacket documentation in a later chapter - Windows only - UIView32: Considered one of the mode featureful Windows clients but development stopped once the primary developed became an SK back in 2004. It still works on modern Windows OSes like Win10. http://www.ui-view.net/ - APRSISCE: Full featured Windows APRS client - PinPointAPRS: New APRS client for Windows only started in 03/2018 http://www.pinpointaprs.com/ - YACC: graphical client written in Java - JavAPRS: graphical client written in Java You can find a more complete list of APRS programs here: http://info.aprs.net/index.php?title=Software If you have an external GPS receiver and want to use it with Xastir (not needed with DanTracker), this is the way to go. Though Xastir directly supports NMEA-0183 serial GPS units like the Ambicom GPS-USB (uses the Prolific pl2303 usb to serial chip), there are limitations to it. Like... - TBD: Add me! External daemons like "gpsd" fixes many of those limitations and enables far more flexible GPS operation. With that said, lets move forward! If you don't have an external GPS, it might to do this NOW so that Xastir will be able to support one in the future! NOTE: when I tried to use an Ambicom GPS-USB device in Xastir, it didn't work through minicom but running at 4800 baud worked fine. Download the code here: http://download-mirror.savannah.gnu.org/releases/gpsd/ This doc assumes we're downloading 3.5 cd /usr/src/redhat/SOURCES wget -O gpsd/gpsd-3.5.tar.gz http://download-mirror.savannah.gnu.org/releases/gpsd/gpsd-3.5.tar.gz gpsd has a few dependencies: yum install dbus-glib-devel yum install xmlto # this installs 9 other packages yum install libXaw-devel # this installs 2 other packages yum install PyQt PyQt-devel # this gets you QtNetwork - Also installs two other packages Newer generations of GPSd now support bluetooth receivers, so... yum install bluez-libs-devel And.. it also replaces Make with newer Python methods so, yum install chrpath scons Now let's create a SPEC file cd /usr/src/redhat/BUILD tar xzvf /usr/src/redhat/SOURCES/gpsd-3.5.tar.gz cp /usr/src/redhat/BUILD/gpsd-3.5/packaging/rpm/gpsd.spec \ /usr/src/redhat/SPECS/ NOTE: In version 3.5, the spec file has two bugs: a) A bogus version name. To fix, change the line: Version: 3.5DEV to: Version: 3.5 b) find the section with line "%package clients" and change the lines: Requires: clients-x11 = %{version}-%{release} Requires: clients-cli = %{version}-%{release} to: Requires: gpsd-clients-x11 = %{version}-%{release} Requires: gpsd-clients-cli = %{version}-%{release} NOTE#2: If your system doesn't have the Python developer packages installed, the above SPEC file will fail in enabling Python support NOTE#3: My system had two problems in building the RPM a. Centos5 only: ------------- My default /usr/bin/python setup was pointing to Python 2.4 but I also had 2.5 installed. The gpsd SPEC file finds 2.4 but the Make system found 2.5 and created an error like the following: `/var/tmp/gpsd-2.95-3-root-root/usr/lib/python2.4/site-packages/gps/gps.py': No such file or directory The actual file was in the 2.5 directory: ls /var/tmp/gpsd-2.95-3-root-root/usr/lib/python2.5/site-packages/gps/gps.py the solution to this was: rm /usr/bin/python ln -s /usr/bin/python2.5 /usr/bin/python Unfortunately, after running that, Yum will no longer work so undo that change once the RPM is built b. My system doesn't have Qt4 installed but that doesn't really matter Now let's create the RPM cd /usr/src/redhat/SPECS #For Centos6 users with x86_64 rpmbuild -bb --target=x86_64 gpsd.spec #For Centos5 users with i686 rpmbuild -bb --target=i686 gpsd.spec Now install them #There are other packages that are created but we don't need them for Xastir rpm -ivh /usr/src/redhat/RPMS/x86_64/gpsd-3.5-1.el6.x86_64.rpm rpm -ivh /usr/src/redhat/RPMS/x86_64/gpsd-clients-3.5-1.el6.x86_64.rpm \ /usr/src/redhat/RPMS/x86_64/gpsd-clients-cli-3.5-1.el6.x86_64.rpm \ /usr/src/redhat/RPMS/x86_64/gpsd-clients-x11-3.5-1.el6.x86_64.rpm \ /usr/src/redhat/RPMS/x86_64/gpsd-devel-3.5-1.el6.x86_64.rpm Ok, so it's all installed and it's time to try it out! Assuming your GPS unit is on /dev/ttyUSB0 (USB based), try this: #Set the speed of the serial port to 4800 BAUD stty -F /dev/ttyUSB0 ispeed 4800 #This is a test where the daemon will stay in the foreground # but it won't start doing anything until a client connects # using -n changes that behavior # /usr/sbin/gpsd -N -D 5 /dev/ttyUSB0 #so now start a client cgps NOTE: I noticed that gpsd installed a bunch of stuff in /etc/udev/rules.d/99-gpsd.rules to recognize various USB -based GPSes which throw errors like: udevd[452]: add_to_rules: unknown key 'ATTRS{idVendor}' I recommend to disable them with: mkdir /etc/udev/rules.d.disabled mv /etc/udev/rules.d/99-gpsd.rules /etc/udev/rules.d.disabled This is also a good read: http://www.murga-linux.com/puppy/viewtopic.php?t=51957&sid=631d6464d6717657c4a1990797ccb6a0 Tip: You can also get atomic accurate date and time via: #UTC date DATE=`gpspipe -w -n 1 | awk -F \" '{print }' | awk -F T '{print }' ` TIME=`gpspipe -w -n 1 | awk -F \" '{print }' | awk -F T '{print }' ` 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 Xastir is a self-contained APRS Mapping / Digipeating client program that can either use multiple TNCs in CONVERSE mode, KISS mode, Linux's native AX.25 stack, APRS-IS, or any combination above! It can display all of the remote posits via an integrated OpenStreetMaps display for online or offline display as well as allows users to create their own maps. Think of it as a self contained GUI like www.aprs.fi or www.openaprs.com without the Internet! This is the main window for tracking objects in the map, setting new objects, etc:
NOTE #1: 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 release 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". Unfortunately, when I enabled that, Xastir would no longer send it's own ACKs! Stay tuned on this one and if you see it as well, please let me or the Xastir email list know! - Requirements for Xastir: A huge laundry list of items unfortunately.. - tkimg :: image manipulation for the TCL language Centos6: yum install tk tkimg Centos5: wget \ ftp://fr.rpmfind.net/linux/EPEL/5Server/i386/tkimg-1.3-0.9.20080505svn.el5.i386.rpm yum install tk rpm -ivh /tmp/tkimg-1.3-0.9.20080505svn.el5.i386.rpm - gpsman (this section assumes you have built gpsd from the section above) Centos6 and Centos5 ------------------- cd /usr/src/redhat/SRPMS/ wget gpsman-6.4.1-2.fc15.src.rpm http://kojipkgs.fedoraproject.org/packages/gpsman/6.4.1/2.fc15/src/gpsman-6.4.1-2.fc15.src.rpm cd /usr/src/redhat/SRPMS/ rpm -ivh gpsman-6.4-1.fc9.src.rpm #Let's remove the OLD version rm /usr/src/redhat/SOURCES/gpsman-6.4.1.tgz cd /usr/src/redhat/SOURCES/ wget -O gpsman-6.4.3.tgz \ http://downloads.sourceforge.net/project/gpsman/distrib/gpsman-6.4.3.tgz cd ../SPECS Edit the gpsman.spec file and update the "Version" line to be: Version: 6.4.3 Release: 1%{?dist} Centos6: -------- #For Centos6 users with x86_64 rpmbuild -bb --target=x86_64 gpsman.spec rpm -ivh /usr/src/redhat/RPMS/noarch/gpsman-6.4.3-1.el6.noarch.rpm Centos5: -------- rpmbuild -bb --target=i686 gpsman.spec rpm -ivh /usr/src/redhat/RPMS/noarch/gpsman-6.4.3-1.noarch.rpm NOTE: Of all the Linux packages to install for HAM on Centos, Xastir is one of the HARDEST to get installed but it does eventually install! It requires over 40 other RPMs to be installed first before you can even start to compile it! Sheesh but it's worth it! - More things to install Centos6: -------- # Lesstif - A legacy Xwindows window toolkit - Comes from EPEL yum install lesstif # 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 #Note that ImageMakick has seen various problems with Xastir; it's recommended to use # the more stable GraphicsMagick toolset instead # #I would recommend to uninstall ImageMagik just in case though it complains on two # dependencies: kipi-plugins and perl-Image-Size rpm -e --nodeps ImageMagick ImageMagick-devel ImageMagick-perl ImageMagick-doc yum install GraphicsMagick GraphicsMagick-devel yum install festival pcre-devel proj-devel shapelib-devel db4-devel #If you want to have resizable fonts, you need xfontsel yum install xorg-x11-apps Centos5: -------- wget \ ftp://rpmfind.net/linux/fedora/updates/9/i386.newkey/lesstif-devel-0.95.0-26.fc9.i386.rpm wget \ ftp://rpmfind.net/linux/fedora/updates/9/i386.newkey/lesstif-0.95.0-26.fc9.i386.rpm #Since the lesstif tools are from the rpmfind.net repository and I #can't find their GnuPG keys, you will not be able load those RPMs via #yum directly # rpm -ivh /tmp/lesstif-0.95.0-26.fc9.i386.rpm rpm -ivh /tmp/lesstif-devel-0.95.0-26.fc9.i386.rpm - LibXp #Keep going.. we're getting closer yum install libXp libXp-devel - Lesstif-devel rpm -ivh /tmp/lesstif-devel-0.95.0-26.fc9.i386.rpm # # This will install 1 other RPM - Geos #There seems to be a issue with the gdal RPM and it #requires this later symlink yum install geos ln -s /usr/lib/libgeos.so /usr/lib/libgeos.so.2 - giflib, unixODBC, netcdf, gdal yum install giflib unixODBC netcdf - #Because the geos RPM above is broken but we fixed it with the #symlink, we need to FORCE this install # wget http://packages.sw.be/gdal/gdal-1.4.4-1.el5.rf.i386.rpm rpm -ivh --nodeps /tmp/gdal-1.4.4-1.el5.rf.i386.rpm - Even more dependencies - from rpmforge #OLD, install GraphicsMagick instead rpm -e ImageMagick ImageMagick-devel yum install GraphicsMagick GraphicsMagick-devel yum install festival pcre-devel proj-devel shapelib-devel gdal-devel \ db4-devel - Centos 6 and 5 -------------- Xastir is not quite ready to run just yet. Now we have to install some Perl modules.. guh UPDATE: Use the cpan2rpm tool to install Perl modules in an RPM trackable fashion: yum install perl-HTTP-Lite yum install perl-Device-SerialPort yum install perl-Test-Simple yum install perl-Module-Build yum install perl-Image-Size yum install perl-XML-Simple #NOTE: The official version of cpan2rpm 2.028 has issues with the Pod:Text module in newer # Perl versions, specifically: # Can't locate object method "interpolate" via package "Pod::Text" # so use this fixed version yum install ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/10/x86_64/cpan2rpm-2.028-6.fc10.noarch.rpm #For me, I then had to do the following hacks to get things to work #Had to put my name and email in the RPM building macro -- change #this to be your name and email vim /root/.rpmmacros -- David Ranch -- #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) ------------------------------------------------------------------ ------------------------------------------------------------------ You still with me? Ready to download and install Xastir?! Now let's finally get started on compiling Xastir ------------------------------------------------- Xastir comes in two forms: - Official Releases code : usually very stable but can be very old at times I'm talking like multiple-years old - Cutting edge Git code : up to date but has a small chance of having bugs To get the Older RELEASE code (not always recommended as it's important for you to check the date the last release version was actually published: https://github.com/Xastir/Xastir/releases In this document, I'm generally recommending people to get the newest Git code (not the official releases). The reason for this is that the Xastir team rarely pushes new official versions but the git code is stable and any fixes go into Git branch but the slow cadence of new official releases hurts getting those fixes to Xastir users! #Xastir's native SRPM from the source code almost works! cd /usr/src/redhat/BUILD mkdir xastir-git cd xastir-git Getting the code the Git way (recommended): ----------------------------------------------- git clone https://github.com/Xastir/Xastir.git or Getting the code the web way (not recommended): ----------------------------------------------- wget https://github.com/Xastir/Xastir/archive/master.zip Assuming you're using the recommended Git method, let's get some details about the Git code. Run the following commands: cd xastir-git echo "Git hash: `git log | head -n3 | grep -i -e commit -e date`" grep "AC_INIT(\[xastir\]" configure.ac Here, I see the following and you'll need that hex string in a moment: Git hash: commit e72841b90d7f552fb8c15dd92e6b7f2574a43d03 Date: Wed Aug 10 13:07:52 2016 -0700 AC_INIT([xastir], [2.0.9], []) #Ok, lets prepare to create the Xastir archive #--------------------------------------------------- #This creates the configure script ./bootstrap.sh #No go back on directory cd .. # Next, update this mv command and the tar command below to reflect the correct version name # from above: # # change this 2.0.9 number to whatever is shown from the above commands # ln -s xastir-git xastir-2.0.9 # Next, we need to create the archive with the correct version, Git commit date and GIT hash. # This is done using the first 8 characters (MSB - most significant bits) of the Git hash: # tar czvf /usr/src/redhat/SOURCES/xastir-2.0.9-20160810gite72841b9.tgz xastir-2.0.9/ --exclude xastir-2.0.9/.git # You can now optionally delete the Git repo (I'd recommend to keep this directory it if you plan on # updating your Xastir code from Git often) # rm -Rf /usr/src/redhat/BUILD/xastir-2.0.9 /usr/src/redhat/BUILD/xastir-git Now let's get a SPEC file to be used to package things into an RPM # # NOTE: the current xastir.spec file included in the Xastir sources # is quite old and non-optimal. It's recommended to us this one # cd /usr/src/redhat/SPECS wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/xastir.spec # If using the TrinityOS xastir.spec file, you now need to update the git_commit, git_date, # version, and Release variables to reflect or the right revisions. As of 07/24/16, that would be: # # %global git_commit b4f6124d682db8399ab4ba2b18c4044b339f2b88 # %global git_date 20160809 # Version: 2.0.9git # Release: 4.%{git_suffix}%{?dist} # BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) Please skip ahead to building the RPM. Alternatively, if you want to use the stock Xastir spec file, you'll need to edit the /usr/src/redhat/SPECS/xastir.spec file to have the following lines Name : xastir Version : 2.0.9git # Icon : src/xastir.xpm Source : http://prdownloads.sourceforge.net/xastir/xastir-2.0.9git.tgz %{_prefix}/lib/xastir BuildRequires : tk, tkimg, lesstif, libXp, libXp-devel BuildRequires : geos, giflib, unixODBC, netcdf, gdal, gdal-devel BuildRequires : GraphicsMagick, GraphicsMagick-devel, pcre-devel, proj-devel, shapelib-devel BuildRequires : db4-devel, perl-HTTP-Lite, perl-Device-SerialPort, perl-Test-Simple BuildRequires : perl-Module-Build, perl-Image-Size, perl-perl-GPS, perl-Tree-R, BuildRequires : perl-Geo-Shapelib, perl-Test-Simple, perl-Module-B # Later down, in the description section, add: CVS ver: 7/1/16 - same as 2.0.8 Official # Later down, you need to modify the %configure line to read: %configure CPPFLAGS="-I/usr/include/libgeotiff" # Even farther down, Change the %install line from: desktop-file-install \ to desktop-file-install --vendor="" \ # Edit the following line: %{_prefix}/%{lib}/xastir to be: %{_prefix}/lib/xastir # And below the line: %config %{_prefix}/share/xastir/sounds add %config %{_prefix}/share/xastir/scripts # Finally, delete the line %{_prefix}/lib/xastir OK! You're ready to build it! Let's go: ----------------------------------------- Centos 6 -------- #For Centos6 users with x86_64 # # build took 1m1s on an i5-2430 2.40GHz laptop w/ 4GB RAM and a SSD drive # # Do NOT run this rpmbuild command as the root user # time rpmbuild -bb --target=x86_64 xastir.spec Centos 5 -------- #For Centos5 users with i686 # # Do NOT run this as the root user # rpmbuild -bb --target=i686 xastir.spec Now, it's hugely important to look back in the rpmbuild logs and review how the configure stage went. Make sure that the features you expect to be enabled in Xastir are there. In my setup, I see: ------------------------------- xastir 2.0.9 has been configured to use the following options and external libraries: MINIMUM OPTIONS: ShapeLib (Vector maps) ................. : yes RECOMMENDED OPTIONS: GraphicsMagick/ImageMagick (Raster maps) : yes (GraphicsMagick) pcre (Shapefile customization) ......... : yes dbfawk (Shapefile customization) ....... : yes rtree indexing (Shapefile speedups) .... : yes map caching (Raster map speedups) ...... : yes internet map retrieval ................. : yes (libcurl) FOR THE ADVENTUROUS: AX25 (Linux Kernel I/O Drivers) ........ : yes libproj (USGS Topos & Aerial Photos) ... : yes GeoTiff (USGS Topos & Aerial Photos) ... : yes Festival (Text-to-speech) .............. : yes GDAL/OGR (Obtuse map formats) .......... : yes GPSMan/gpsmanshp (GPS downloads) ....... : yes Assuming the features are there and the RPM package was created, time to install it! # Centos6 # sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/xastir-2.0.9-3.20160809gitb4f6124d.el6.x86_64.rpm Critically IMPORTANT: One more step for first time time Xastir installs Xastir requires root privs to access specific parts of the system. Accessing the Linux AX.25 stack if you've enabled that setup on your machine (what this document specifically details) or optinally setting time directly from a connected GPS. To enable this, issue the command: sudo chmod 4755 /usr/bin/xastir It's worth noting that the Xastir program does NOT run with SUID root permissions all the time. Special care was given to keep the root access to a minimum and drop all elevated privledges whenever possible. If you're not using the Linux AX.25 stack, are using a GPS but don't want to enable SUID root access, you can alternatively install the gpsd daemon (as this document recommands) and get the GPS data that way. -- A another reason to give SUID root access to the Xastir program is to access the serial port connected to the TNC but that approach is obsolete as the modern solution for this is to use the "dialout" UNIX group to allow this access. To use this approach, issue the following command: sudo adduser dialout Replace with your Linux username. Once complete, completely log out of the XWindows system (not just exiting a specific terminal window) or reboot the system to make the OS recognize your new unix group addition Now that you have the core Xastir program installed, you need to create and install the separate Xastir sound file package. Fortunately, this is easy to do! #Xastir's native SRPM from the source code almost works! cd /usr/src/redhat/BUILD mkdir xastir cd xastir #Get the WAV files git clone https://github.com/Xastir/xastir-sounds.git #Let's get some details about the Git code. Run the following commands: cd xastir-sounds git tag #Here, you'll see there is one tagged version called "v1.0" so lets use that with: # git checkout tags/v1.0 # Next, update this mv command and the tar command below to reflect the correct version name # from above: # cd .. mv xastir-sounds xastir-sounds-1.0 # Next, clean up a few things and create the archive name with the correct version, Git tag version # mv xastir-sounds-1.0/README.md xastir-sounds-1.0/sounds tar czvf /usr/src/redhat/SOURCES/xastir-sounds-1.0.tgz xastir-sounds-1.0/ --exclude xastir-sounds-1.0/.git #You can now optionally delete the Git repo cd .. rm -Rf /usr/src/redhat/BUILD/xastir Now let's get a SPEC file to be used to package things into an RPM # # cd /usr/src/redhat/SPECS wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/xastir-sounds.spec OK! You're ready to build it! Let's go: ----------------------------------------- Centos 6 -------- #For Centos6 users with x86_64 # build took 1m1s on an i5-2430 2.40GHz laptop w/ 4GB RAM and a SSD drive # # Do NOT run this as the root user # time rpmbuild -bb --target=noarch xastir-sounds.spec Centos 5 -------- #For Centos5 users with i686 # # Do NOT run this as the root user # time rpmbuild -bb --target=noarch xastir-sounds.spec I've used Xastir with both Linux soundmodem and the Kenwood D710. For this example, I'll configure it with the D710 and I'll add soundmodem later. - Start up the D710 in 1200 baud packet mode on channel A - Tune the radio to 144.390 - Make sure you set the squelch properly so an idle frequency isn't "busy". Unless this it set, you'll never transmit! - Start up your TNC into KISS mode. Ideally, use my "packetrig.sh" script to start up the D710 TNC in KISS mode /usr/local/sbin/packetrig.sh vhf-d710-xastir - Start up xastir on the command line - Set up your system to something like the following: File --> Configure --> Station | +-- Configure | | | +-- Station | | | | | +-- - put in your callsign | | no "-#" if this is a stationary home, no digipeat | | if a stationary home that digipeats | | digipeater on 70cm | | additional station | | HF to VHF gateway | | Igate/dstar/ system (not at home QTH) | | special activity:satellite Ops:camping | | Human portable like HT APRS | | Marine (boat, ship, etc.) | | Mobile | | Internet-access only (no RF used) | | Balloons / aircraft, etc | | APRS-touchtone / one-way trackers | | WX stations | | Truckers | | additional station like HF users | | | | - if you know your location in GPS coordinates, put them in | | | | KI6ZHD's QTH GPS coordinates (according to a Delorme PN40) | | | | Lat: 37 degrees 20.613N | | Long: 121 degrees 59.986W | | | | NOTE #1: These static values will be overridden | | if you enable a GPS unit | | | | NOTE #2: if your APRS system is going to be stationary (say a house), | | then you should NOT use a GPS. GPS receivers have positioning | | errors / noise especially if the receiver doesn't have a clear | | of the sky. This positioning errors will show your house | | MOVING around! Worse.. if smart beaconing is enabled, each incorrect | | change in position mean a radio transmission which will reduce the | | life of your radio, fill up the radio spectrum with worthless beacons, | | etc. | | | | Coodinates: The easiest way I've found to find out your GPS coordinates is: | | | | - Goto GoogleMaps and type in your address | | - turn off the 45 degree mode and center the | | view to where your antenna is | | - On the left hand NAV, you'll see the chain-link | | icon. Right-click that and "Copy link | | location. For me, the link would be: | | | | http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=3739+Benton+Street,+Santa+Clara,+CA &aq=0&oq=3739+benton&sll=37.269174,-119.306607&sspn=13.014202,18.303223&vpsrc=6&t=h&ie=UTF8&hq= &hnear=3739+Benton+St,+Santa+Clara,+California+95051&ll=37.343535,-121.999908&spn=0.000399,0.000559&z=21 | | | | see at the end of that mess of a URL the value: | | "37.343535,-121.999908" That's the WGS84 Decimal | | degrees value. Now go to the following URL to translate | | that WGS84 Dec.Degree position to GPS coordinates: | | | | http://boulter.com/gps/?c= | | | | To confirm the location, click on CALC and | | then Calculate to make sure it's in the right | | grid square. You will want to use the "GPS" | | values for use in Xastir (not Degrees, Minutes, Seconds) | | | | - click on SELECT in the station symbol section | | and select your desired icon | | - select the proper output power | | - select the proper height above average terrain. | | Do NOT use average height above sea level or | | height above ground. | | - antenna gain on 2m | | - antenna type on 2m | | - enable ambiguity if you don't want show your | | exact location | | | +-- Defaults | | | | | +----- Transmit station type: [select the right one] | | - ENABLE: Transmit compressed objects/items | | - ENABLE: POPUP new bulletins | | | +-- Audio Alarms | | | | | +----- Audio Play Command: play -q | | | | | +----- The audio files that come as part of the xastir-sounds package are VERY basic | | and I don't use them. I personally use the following sounds from other | | packages and I only enable notifications for new messages as getting new station | | notifications in a busy APRS area becomes annoying very quickly: | | | | - New Station: KDE-Im-User-Auth.ogg from the kdebase-runtime RPM | | - New Message: KDE-Im-Sms.ogg from the kdebase-runtime RPM Now, go to: File --> Configure --> Station | +-- Configure | | | Message | | | +-- Enable "Satellite ACK mode" - this makes sure that digipeated ACKs are accepted (screwy you have to enable this!!) Next, go to: Interface | +-- Interface Control | +-- Add: AX25 TNC | +--- - UNCHECK: activate on startup - CHECK: Allow transmitting - UNCHECK: Digipeat? - AX25 device name: d710 The above assumes the same /etc/ax25/axports file as set by dranch's HamPacket documentation - CHECK: Allow RF to Inet traffic ONLY - For a high density Metro area like the Bay Area, make it "Path 1: WIDE1-1" and nothing else If you live farther out, make it: Path 1: WIDE 1-1 Path 2: WIDE 2-2 Finally, go to Interface, interface control, click on "AX25 TNC d710" to have it highlighted and click on "Start" Now let's setup the the maps! It's worth specifically mentioning that Xastir allows to overlay multiple maps ON TOP of each other. This is done by having multiple maps highlighted in BLACK. For now, I don't recommend to do that. To get started with some Online maps, try the following (requires your machine is connected to the Internet). Goto: Map | +-- Map Chooser | +-- click on "Online / OSM_tiled_fosm.geo" | +-- In the upper right, click on Properties | +-- Click on the top line and in the lower section, enable: Filled: YES AutoMAPS: YES USGS DRG: YES Click on Close Click on OK In the lower left window of Xastir, you'll see the status line read something like: Downloading tile 1 of XX where the "XX" is the number of tiles for your given "zoom" level. The speed of the download and rendering depends on your Internet speed and your computer's speed. One good thing here is that once downloaded, the given area and zoom level tiles will be locally saved so it will be faster next time. Now go to View --> Incoming data and watch the incoming objects start to appear on the maps! - I would recommend to let things come in and let you get an idea of how things look. Use a combination of the UP/DOWN/LEFT/RIGHT and zoom IN/OUT buttons to explore around. Remember, every time you change your position or zoom, your computer will have to download new tiles so it can take some time - Personal preference: I find that Xastir's default map "brightness" as too low and too much data about each station is too detailed (gets VERY cluttered) in busy APRS areas. To improve this, goto: Map | +--> Configure | +--> Blackground Color: White +--> Map Intensity: 80% +--> Station Text Style: Black shadow +--> Icon Outline Style: No outline +--> Icon Outline Style: No outline - BTW, if you have a serial GPS to use for Xastir, connect it FIRST and then start Xastir. At that point, you can add either a "serial GPS" or "networked GPS (gpsd). NOTE on serial GPS: Once added and started, it took 2-3 minutes before Xastir considered the GPS input as good and functional On of my most recent projects was looking to create an APRS client for the Raspberry Pi. I was looking for an APRS client (not server) for Linux that can support listening to a serial or UPS GPS, transmit said GPS coordinates with Smart-beaconing, all while using Linux's native AX.25 stack but run from the command line. All of those requirements were very difficult to find anything but here is what I found: - Xastir: Very nice (covered above) but it's a) A very large install and a quite heavy weight program b) Requires Xwindows to run (Xwindows is heavy weight in itself) - APRX - A very powerful APRS server, digipeater and Igate server a) under active maintenance b) natively supports GPSes c) doesn't support smart-beaconing d) doesn't have any graphical display / maps - DIGI_NED - Extremely powerful APRS digipeater and APRS server: a) natively supports GPSes b) doesn't support smart-beaconing c) hasn't been updated since 2009 d) it's a port from DOS and it's configuration is very complex (too many features) e) doesn't have any graphical display / maps - 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, Smart-Beaconing, 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 DanTracker was perfect for my needs and you can see videos of the N7NIX and KK7DDS DanTracker 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 optimizations from KI6ZHD for RAM drive logging, compiling toolchain improvements Applications: - FBB BBS - FPAC Node - aprslist digipeating - ax25ipd Internet / AMPR tunneling - DX Spider packet cluster - Rose, Flexnet, and Netrom routing If you have any questions about the Raspberry Pi setup, feel free to email me until I start writing up my docs APRX is a powerful APRS Digipeater and Internet Igate server that can be used to tightly control with: - Used as a generic digipeater for APRS or even AX.25 UI unproto traffic - gateway APRS traffic to/from the RF domain into the APRS-IS Internet gateways with various complex filtering options - Inject one or more APRS objects into the RF / APRS-IS domains NOTE: APRX does not directly support sending APRS position posits as learned from GPS. If you want something like this (an APRS client), I recommend to check out N7NIX's version of DanTracker found at: https://github.com/n7nix/dantracker Ok, to get started, it should be noted that APRX is getting new code support from W6KWF. Though it's not official yet, the new temporary source code repo has some badly needed fixes: W6KWF patched sources (RECOMMENDED): ------------------------------------ cd /tmp git clone https://github.com/PhirePhly/aprx.git cd aprx MAJVER="`cat VERSION`" #last GIT commit GITVER="`git log --date=short | grep -m1 commit | awk '{print }'`" GITMAJVER="`git log | grep -m1 -e commit | awk '{print }' | cut -c -8`" GITDATE="`git log --date=short | grep -m1 Date: | awk -F: '{print }' | awk -F- '{gsub(/ /, "", ); print }'`" git archive --format=tar --prefix=aprx-$MAJVER/ $GITVER | bzip2 > /usr/src/redhat/SOURCES/aprx-$MAJVER-$GITDATE\git$GITMAJVER.tar.bz2 rm -Rf aprx #Now skip to the next portion of this section (NOT RECOMMENDED): Using the original OH2MQK APRX sources (has known issues) ----------------------------------------------------------------------------- cd /usr/src/redhat/SOURCES wget http://ham.zmailer.org/oh2mqk/aprx/aprx-2.06.svn514.tar.gz Get an RPM Spec file: --------------------- RECOMMENDED: Next, we need an RPM spec file. You can get the pre-configured SPEC file at http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/aprx.spec (NOT RECOMMENDED) - Roll your own RPM spec file ----------------------------------------------- cd /usr/src/redhat/BUILD tar xzvf ../SOURCES/aprx-2.06.svn514.tar.gz mv aprx-2.06.svn514/aprx.spec /usr/src/redhat/SPECS/ At this point, we have to edit the SPEC file as this file has broken logic to deal with SystemD based distros like Centos7, Fedora18, etc. - Edit the aprx.spec file and delete both the following lines and everything between them: %if 0%{?rhel} >= 7 || 0%{?fedora} >= 16 . . thru . %endif - Next, there are some options you might think about enabling in the "%configure --with-erlangstorage" line: - pthreads support : To enable this, add the text --with-pthread - agwpe support : to enable this, add the text: --enable-agwpe When I tried to compile AGWPE support, the compile failed with the following. Maybe in future versions, this issue will be resolved. -- agwpesocket.c:461:2: warning: #warning "WRITEME: AGWPE Raw AX.25 reception" agwpesocket.c: In function ‘agwpe_prepoll’: agwpesocket.c:663: error: invalid operands to binary > (have ‘time_t’ and ‘struct timeval’) make: [agwpesocket.o] Error 1 -- - Save your changes to the spec file Now let's compile it up: Centos 6 -------- #For Centos6 users with x86_64 cd /usr/src/redhat/SPECS rpmbuild -bb --target=x86_64 aprx.spec And install it: rpm -ivh /usr/src/redhat/RPMS/x86_64/aprx-2.06.svn514-1.el6.x86_64.rpm Time to configure it. In this example, I'm going to do two things: 1. Install a APRS-IS object for the local packet station that can be displayed on say http://www.aprs.fi 2. be a UNPROTO digipeater for my packet system on 145.050 for KB2KB communications +----------------------------------------------------------------------------+ | NOTE: Newer versions of APRX requires an APRS-IS passcode to be configured | | to support sending APRS data to APRS-IS. Without it, your system | | sending in APRS-IS data will be silently ignored. No APRS-IS | | connection, packet injection, etc. errors will be reported! | +----------------------------------------------------------------------------+ - Edit the /etc/aprx.conf file: - Change the "mycall" variables to used your specific callsign. I'm using "KI6ZHD" which will allow also support digipeating on the "KI6ZHD" or KI6ZHD-0 SSID. - Change the "-1" in "passcode -1" to reflect your APRS-IS passcode. If you don't know what this is, please email me and I'll help you out - In the <aprsis> section, # out the line: server rotate.aprs2.net to stop using the global pool and instead, uncomment out a better server pool that reflects your location on the planet. For me, I'm un-#ing out: server noam.aprs2.net ---------- Interfaces ---------- - Find the #ed out "<interface>"stanza, un # it out out - Un # out the "ax25-device $mycall" line NOTE: APRX does not read the /etc/ax25/axports file to get a valid ax.25 device name. This aprx software simply matches the callsign that the Linux AX.25 system puts together as configured by the axports file. To confirm which callsign is being used, bring up your packet system and look at the "HW ADDR" for the "ax0" interface according to /sbin/ifconfig - Un # out the "tx-ok" line and change the "false" to "true" - If you want other SSIDS to support digipeating, then use the ALIAS line. I'm using: alias KI6ZHD-5,SCLARA NOTE: I've found that when a remote station digipeats to an alias, the output from the digipeater becomes the contents of $mycall and NOT the expected alias - Un # out the concluding "</interface>"stanza ------ Beacon ------ - Next, find the line "#beaconmode" and under it, add: beaconmode { aprsis } - Find the "beacon symbol" line, make a copy of it below, un-# it out and for my QTH. APRX uses the "GPS style of coordinates and I set it to the following per how I recommended to find coordinates in "xastir-running" section of this document. Notice that I: - Force the beacons to only go out a specific interface - Added the object name (8 characters max) - change the symbol - set the lat/long - set the comment beacon object "Packet N" symbol "/n" lat "3720.62N" lon "12159.99W" comment "145.050 Packet full service digi/pbbs/node" ---------- Digipeater ---------- - Finally, un # out the "<digipeater>" line - Un # out the line "transmitter $mycall" - Find the example section of "source RXPORT-1" and - Un # out the double #s for "<source>" - Un 3 out the double #s for "source RXPORT-1" and change the "RXPORT-1" to "$mycall" for my specific setup - Un # out the concluding # for "</source>" - un # out the concluding "</digipeater>" line Ok, your done! To start it up to test, run the program in foreground mode. You can put in upwards of four d's where each one adds more debugging: /usr/sbin/aprx -d If it starts up with out any specific errors, go look for your configured callsign+SSID on www.aprs.fi. You should see it! You can also test the digipeater side of things as well. Assuming you have a local digipeater you can bounce packets off, try using the F10 view of Linpac and - Change the UNDEST path - for me, I would use :undest "David WOODY KI6ZHD WOODY" - Using the F10 unproto menu, simply send "test" and you should see the packet be transmitted, get digi'ed from Woody, then digi'ed by KI6ZHD, and then get digi'ed by Woody again Once things are running to your liking, you can either start aprx from the /etc/rc.d/init.d/aprx init method or what I do, start it from the packetrig.sh script. If you want to do it the init.d route, you need to - edit the /etc/sysconfig/aprx file and change the "STARTAPRX" variable to yes - run: /sbin/chkconfig --level=345 aprx on - and then start it up with: /etc/rc.d/init.d/aprx start There are all kinds of interesting things you can learn about your local area via APRS. It all depends on what the local APRS HAMs are advertising. For example in my area:
Individual repeaters announcements wr6abd http://aprs.fi/info/a/146.64-LP
Individual echolink stations el-ki6zhd http://aprs.fi/info/?call=EL-KI6ZHD
Individual weather (WX) station data Internet based station http://aprs.fi/weather/a/DW2458
Overall APRS traffic level (packets per second) see the comment line http://aprs.fi/info/a/TFCSCRUZ
APRS received DX (furthest heard from this station)   http://aprs.fi/?c=status&call=W6PKT-5
You can send/receive short email and SMS texts via APRS:
  • via Winlink's APRSlink - http://www.winlink.org/aprslink
    - You can also find your nearest Winlink packet system, etc - See this document's Winlink APRSlink cheatsheet section for more detail
  • APRS's Email2 system (a bit more complicated) - see the next section for more details
  • You can also send APRS messages back and forth via the Internet (Internet to RF-based APRS) - http://www.openaprs.net/

Finally, there are lots other things you can too (just a few examples):
  • Sending CQ requests for a global APRS messaging QSOs - http://www.aprs.org/cqsrvr.html
  • Interrogate remote APRS stations for their various details (see the QUERIES section at the bottom of this URL) - http://www.aprs.net/vm/DOS/PROTOCOL.HTM
The key thing to remember about APRS is that it's flexible and extensible. From where it started to where it is now is impressive. With the addition of the APRS-IS system, it now allows APRS radios to essentially do anything (with limitations of course). Email, small web pages, etc. were just the start and the community is just waiting for someone to contribute the next cool idea. There is a very slick feature of the JavAPRServer software that can relay messages between two HAMs where one is using Internet and the other is using an messaging capable APRS station. It's described here: http://www.aprs-is.net/email.aspx but page is a bit terse and it was a bit confusing for me the first time I used it. Hopefully this section will help explain things a bit to make it easier to understand. To get started, there are a few key key concepts to consider: 1. The Internet based email sender MUST be a HAM and follows all FCC Part.97 rules (that includes various CEPT agreements, etc). The Internet based person WILL be sending APRS packets onto the RF! 2. To remove SPAM, the APRS user has to do two things: a. white-list every single email address he or she ever expects to get a message from. This can be tedious but it's important - See below b. Has to convey the very specific "shortcut" to that remote HAM and they must use that shortcut in every message or the delivery will be blocked ---------------------- This example's details ---------------------- - Let's say your name is Mark who is is a licensed HAM with a properly working messaging capable APRS RF radio (Kenwood D710, Yaesu FT350, homebrew setup, etc) with the call 'BBY7YY-7' (yes, this is an invalid callsign.. this is just an example). Your email address is . Notice that I'm using the example SSID of -7 here. There are recommended SSID guidelines at http://aprs.org/aprs11/SSIDs.txt but it technical doesn't matter which SSID is chosen but the remote Internet based HAMs must know which SSID you are using! - You have a friend named Joe, who is a licensed HAM with the callsign 'AAX0XX' and has the email address '' - You have another friend, Paul, who is another licensed HAM with the callsign 'QQN4NN' and has the email address '' - 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 (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 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= If you got that message, that means it working! If you didn't, review and try again until things work. BTW, I'm working on a universal scheme here but if you have multiple email addresses that you might send/receive messages from, you probably want to setup multiple aliases for yourself. For example, setup: shortcut : email address ---------:----------------- me yy yyyahoo yygmail 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 (you can substitute 'joe' for any 'alias' you'd like) That's it. Mark (you) sends the APRS message and would get a nearly immediate response saying the shortcut was added. Ok, let's repeat that last step to add Paul: APRS source callsign: BBY7YY-7 Destination Callsign: EMAIL-2 (note: the callsign MUST be all capital letters) APRS message : paul (you can substitute 'paul' for any 'alias' you'd like) Done! To confirm them, send a "list" request from your APRS radio: APRS source callsign: BBY7YY-7 Destination Callsign: EMAIL-2 (note: the callsign MUST be all capital letters) APRS message : joe l Send it! [You should receive an email addressed to about this new "Joe" shortcut APRS source callsign: BBY7YY-7 Destination Callsign: EMAIL-2 (note: the callsign MUST be all capital letters) APRS message : paul l Send! [You should receive an email addressed to 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 "" Paul is enabled for "" b) what SSID you will be using on on your APRS RF station (-7 is used in this example) c) what their associated "shortcut" name is for this specific email address This would be "joe" and "paul" - Send a message from APRS to Joe's email: ---------------------------------------------- - Ok, so we're going to send a message to Joe's email account. Create a new APRS message that is a max message size of 67 characters APRS Source Callsign: BBY7YY-7 Destination Callsign: EMAIL-2 APRS message : joe Hey this is Mark sending from my APRS station! - The key points here are: - The space between the shortcut text and the actual message is MANDATORY - The text "joe" starting the APRS message actually looks up the proper email address as configured by Mark. The rest of the text on that string will become the actual email message! - Send this new APRS message and you should get a nearly immediate response saying it was sent - Joe to send a reply message from Joe's email address back to Mark's APRS station: --------------------------------------------------------------------------------- - Joe creates a email: Email source address: <--- 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 to send jim APRS messages. If Joe doesn't know what Mark named his shortcut for his email address, it's not going to work! You must know this. If you can't remember, try some guesses like: joe xx aax0xx - If the message is accepted, it will be immediately sent out on APRS. If the remote station doesn't acknowledge the message within the timeout period, Joe will receive a reply email saying: Subject: APRS Message Delayed At this point, Mark has 24hrs to remotely fetch all his messages before they are deleted - Again, there are several KEY points here that are critical for this reverse communication path: - Joe has to make sure he sends the email from the specific email account that Mark previously configured - You need to know that special email destination to get to the gateway. (the email address received above in your test message, also see below) - In the subject line of the email: - the remote APRS HAM's callsign must be in all capitals - you're using the correct SSID for the remote APRS callsign - after the SSID, it's followed by a ":" - After that trailing colon, you have 67 characters to write your APRS message - In the email body itself, you MUST: - enter in the "userid:" text, then - enter in the shortcut name that was previous configured to accept messages from that email address, then - the trailing ":" ---------------------------------------------- NOTE about forgetting / listing all shortcuts: ---------------------------------------------- - If you don't remember the shortcuts you created for Joe, Paul, or anyone else, there is NO WAY to list all previously configured shortcuts! Bummer! This also means that of your friends that are sending you messages via APRS, you won't be able to message them back until you both configure NEW shortcuts AND tell your friends what the new shortcuts are! - If you forgot that trailing colon characters, sending messages won't work though the EMAIL-2 system won't give you a clear error report on why. Bummer! - Other nice features! -------------------- - From an APRS station: - [fetching old messages]: Let's say your APRS radio has been off for a while and you might have missed some messages. Simply send a message to EMAIL-2 with the word "get". You will be sent any messages you missed for the last 24hr period - If you send a message to EMAIL-2 to a configured shortcut (email address) with an "l", they will be emailed a LIST of all their shortcuts - if you send a message to EMAIL-2 to a a configured shortcut (email address) with an "r", that shortcut will be REMOVED Remote APRS-IS destination email address: ----- Remember that email address I told you to write down during your first tests? Here is why it was so critical to save it: The internet email destination you use to send APRS users messages to your shortcuts is intentionally missing from this document. This is to make sure that YOU (the reader) makes sure you're following Part.97 and/or consider your specific country's Amateur Radio regulations. Withholding this address is also a strong mechanism to to avoid abuse (spam, use by non-HAMs, etc) being sent to that system. If you forgot to write this email address down, just send yourself another test message (shown above) or alternatively, send me an email and we'll take it from there. - Troubleshooting: ---------------- When I was first figuring out this system from the original web page, I was stumped a few times. I found the "messages" area of APRS.FI looking at this EMAIL-2 callsign was VERY helpful! http://aprs.fi/?c=message&call=EMAIL-2&limit=1000 - Alternatives to the EMAIL-2 System: ----------------------------------- Thought the EMAIL-2 system works, it's really not very intuitive to me and requires communicating the specific configured shortcuts to the remote HAM beforehand. That's sometimes difficult and impossible to use if not setup first. Fortunately, the Winlink 2000 system has the APRSLink system which is a lot easier to use and will keep old pending messages around for a LOT longer Check out the Winlink section later in this document on how to use that system.
Jump to the Winlink Messaging Section for full details.


UI-Chat is a program from Mitch Winkle (AB4MW) which is a fusion of the mixed chat and automated response system of FSQ (available in the FSQCall and Fldigi program). What makes UI-Chat different is that sends it's packets in AX.25 UI frames any interface that supports KISS. Putting it another way, this program can work with classic 1200 AFSK TNCs, Direwolf SoftTNC programs, but also programs like Fldigi with it's new TCP-KISS interface. But Fldigi already supports FSQ you say? Well, FSQ in the above programs only support it via the Incremental Shift Keying (IFK) mode which is designed for NVIS communications. While this mode has it's strengths, it can't match some of the other modes that Fldigi can support like Olivia, etc. UI-Chat offers the best of both worlds! Let's get started with the intent to use it with Fldigi on HF: - You need to have Fldigi 3.23.10.10 or newer installed and working on your machine. Please see the Fldigi section for full details on how to get that going - You need to configure Fldigi for TCP-KISS mode. This is fully covered in the "Advanced Configurations with Fldigi" section - You need to install Java as UI-Chat is a Java application. Please read the above "Advanced Configurations with Fldigi" section on PSK Mail on how to get Java installed. - Next, if you want to use UI-Chat with a hardware TNC via serial port, you need to install the rxtx-java library. This is simply a matter of running: sudo yum install rxtx - Now download UI-Chat. # To be packaged later - unlike most programs, this doesn't need to be # compiled nor installed to work mkdir -p /usr/src/archive/Uichat wget http://downloads.sourceforge.net/project/uichat/2.0/UIChat20160507.zip unzip UIChat20160507.zip mv UIChat UIChat20160507
- Turn on your radio, make sure it's on a available frequency, the antenna is all tuned up. Per the UI-Chat Google+ community at https://plus.google.com/u/0/communities/110418910579764092090 the common frequencies are: VFO Dial Frequencies + 1500 Hz Audio 3.586 Mhz USB 7.101 Mhz USB 10.141 Mhz USB 14.101 Mhz USB 18.106 Mhz USB 21.091 Mhz USB 24.926 Mhz USB 28.101 Mhz USB - Start up Fldigi as you normally would and put Fldigi into TCP-KISS mode per the "Advanced Configurations with Fldigi" section. Be sure to have the "Listen/Bind" checkbox marked and then click on "Connect" to have Fldigi ready to be used by UI-Chat - Now start UIChat with: java -jar UIChat.jar - You will now be presented with a configuration screen. On the "Network" tab: - Select "KISS TCP modem" - In the bottom selection, change the TCP port from 8001 (what Direwolf uses) to 7342 (what Fldigi uses) - On the "Station" tab: - Change the "station callsign" to your callsign without any SSIDs - Update your name - QTH (location) - Station info message (something like): UIchat on Fldigi 3.23.10.10 w Centos Linux 6.7 - Current Status message: leave me a message - Sounding (beacon) text: UIChat running with Fldigi / Centos Linux from Santa Clara, CA - Grid square (6 digit): CM97ai - Click on Save - Back in the main UI-Chat window, click on "Sounding is OFF" to turn on soundings aka beacons

This is ARIM, an application that can use the ARDOP program and protocol
ARDOP is an HF modem suite developed by Rick Muething KN6KB which intended to be an Open (aka free), multi-platform HF modem suite. It's original intention was to be used by Winlink but it's open nature allows it to be used by other applications. The ARDOP modem can operate either locally or over a LAN network to support reliable high performance data transfers over RF. This modem is actually a SUITE of several DIFFERENT digital modes offering FEC (foreard error correction), ARQ (Automatic Request), and a mixture of both FEC and ARQ. What's unique here is that it's a system that switches modes and speeds as the RF band conditions change. This dynamic selection is something that both PACTOR and WINMOR have done for years but either those solutions required very expensive hardware TNCs or only worked on Windows. As Rick defined the ARDOP technology and implimented the Windows version, John Wiseman G8BPQ wrote a Linux version as well as an embedded version running on a Teensy microcontroller. This section is going to detail getting things working on the Linux version. You can learn more at: https://www.winlink.org/content/ardop_overview ARIM is a complex but very powerful TUI (textual GUI) HF communication application intended to interface with the ARDOP mode. It's written in Ncurses which allows for use via an SSH session and provides several main features: - An intuitive interface to have connectionless flood-style and CONNECTED chats to ARIM clients - CONNNECTED sessions work with remote Winlink (Winlink Express or PAT) stations running ARDOP. Much like you can manually work Winlink stations over AX.25 or TELNET, you can now do the same over ARDOP - Operates a semi-automated system similar to FSQ or D-RATS where you (or remote HAMs) can send perodic beacons, pings, run remote commands like "heard", and conduct file transfers - Many other things: read more at http://www.whitemesa.net/arim/arim.html The ARDOP modem is mostly stable now but it's still a work in progress. For example, discussions have just begun about ARDOP2 which will add a second FEC layer much like WINMOR. Should only make it work better in the future. I'd recommended to join the email list at the following email group to keep tabs on what's going on but things are generally ready to use: https://ardop.groups.io Pre-built ARDOP binaries for some systems are available here: Linux x86 - http://www.cantab.net/users/john.wiseman/Downloads/Beta/ardopc Linux ARM - http://www.cantab.net/users/john.wiseman/Downloads/Beta/piardopc Windows x86 - http://www.cantab.net/users/john.wiseman/Downloads/Beta/ARDOPC.exe but to do it right, I recommend to build the modem from the sources. Let's download the newest sources which are now embedded in John's larger ARDOP hardware TNC archive. As of this reading, this was for ARDOP version 1.0.4.1b-BPQ: cd /usr/src/redhat/SOURCES/ # The ARDOP code used to be ARDOPC.zip file but this archive was deprecated as of 3/27/18. # The new location is now buried in the TeensyProjects.zip file # wget http://www.cantab.net/users/john.wiseman/Downloads/Beta/TeensyProjects.zip mv TeensyProjects.zip TeensyProjects-`date +%m%d%y`.zip Now let's massage it to get it into a packagable archive: cd /usr/src/redhat/BUILD unzip ../SOURCES/TeensyProjects-`date +%m%d%y`.zip # Determine the version of ARDOP and make the naming convention compatible with # RPMs (-BPQ isn't allowed) # VER=`grep ProductVersion TeensyProjects/ARDOPC/ARDOPC.h | awk -F\" '{print }' | awk -F\- '{print }' ` #This should look like: 1.0.4.1b echo $VER #Pull out ONLY the ARDOP code, rename the archive name, archive, and delete the old zip file mv TeensyProjects/ARDOPC ardopc-$VER tar czvf /usr/src/redhat/SOURCES/ardopc-$VER.tgz ardopc-$VER/ rm -Rf ardopc-$VER rm -f /usr/src/redhat/SOURCES/TeensyProjects.zip Next, download a RPM SPEC file for it: cd /usr/src/redhat/SPECS wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ardop.spec Next, edit the ardop SPEC file to make sure the version number from the downloaded TeensyProjects file matches: vim /usr/src/redhat/SPECS/ardop.spec -- Version: 1.0.4.1b -- Now build it: rpmbuild -bb --target=x86_64 ardop.spec and install it sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/ardopc-1.0.4.1b-1.x86_64.rpm ARDOP requires a special 12Khz sampling rate instead of the standard 44.1 or 48Khz that a soundard offers. To enable this this resampling, create the following file in your home directory (yes, the '." in the front of the name is REQUIRED). You also must change the "card" and "device" names to match the ALSA soundcard that's connected to your desired radio as shown in the output from "aplay -l": vim $HOME/.asoundrc -- pcm.radio { type hw card 1 device 0 } pcm_slave.radioslave { pcm radio rate 48000 } pcm.radioconv { type rate slave radioslave } -- Next, there are several parameters that ARDOP needs to know: - The network port to communicated with the ARDOP-enabled applications The default is 8515 - The ALSA device to listen(record) and transmit (play) to - The PTT device to key up your radio (supports asserting the RTS pin on serial ports, GPIO pins, CAT commands, etc) One example of manually starting up ARDOP could be: ardopc 8515 hw:1,0 hw:1,0 -p /dev/ttyUSB0 IMPORTANT: ---------- Two important things around audio level setting: 1. Turn OFF AGC on your radio 2. Start up ARDOP and watch the level output coming from the program on a desired frequency (different frequencies can have higher/lower levels depending on your antenna's performance). Change the "RF GAIN" on your radio until you see ARDOP levels around 20000. For example: >> INPUTPEAKS -18371 17687 These levels should be when the channel is IDLE and they do seem to jump around in very NON-consitent ways. Be patient between changing the setting on your radio and waiting for a few sample reports coming in from ARDOP. When the frequency is busy with say ARDOP or other amateur radio traffic, you want to see the reported ARDOP levels approach 32768 but ideally NOT reach 32768. This can be very difficult with both weak and strong stations on the same frequency without AGC but this is what's recommended from the author of ARDOP. Finally, I recommend to use my startup script to keep this simpler: cd /tmp wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/start-arim-ardop.sh chmod 755 start-arim-ardop.sh Now edit this script to reflect your PTT serial port and then move it into place: mv /tmp/start-arim-ardop.sh /usr/local/bin/ Additional ARDOP information: http://www.cantab.net/users/john.wiseman/Documents/ARDOPC.html It should be mentioned that since ARDOP is a moving target, so is ARIM to keep up. ARIM v1.3 or newer requires ARDOPc version 1.0.2.5 or newer. In addition to this, ARIM v1.8 or newer is required for any ARDOP setups that use serial PTT to have successful long run QSOs or they will timeout. So Let's download the most recent code cd /usr/src/redhat/SOURCES/ wget https://www.whitemesa.net/arim/src/arim-1.8.tar.gz Next, download a RPM SPEC file for it: cd /usr/src/redhat/SPECS wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/arim.spec If you downloaded a newer version of ARIM, please update the spec file to match the new version of code and now build it: rpmbuild -bb --target=x86_64 arim.spec Now install it: sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/arim-1.8-1.x86_64.rpm Ok, the final stages! So go ahead and start ARIM by running the command: arim At this point, the program should start up, copy a bunch of stuff into a new "arim" directory in your home directory and then tell you to edit the file. Go ahead and type in "q" and then "y" to exit ARIM. Now let's configure Arim by configuring it's ini file: vim $HOME/arim/arim.ini -- [tnc] #Update mycall to use your callsign : you can use SSIDs here if you wish # such as -0 through -15 as well as ALPHA suffixed -A through -Z mycall = KI6ZHD #Update the maidenhead grid square - I'm in CM97ai but you can give 4, 6, or 8 place #precision gridsq = CM97ai02 #Update the name variable to reflect your version of ARIM - seems to be the thing to do #in the ARIM community so that when you beacon, you include your version of code name = v1.8 #Update the info line to be about your station info = Info: [FT950 @ 50w into a fan-dipole] # In the example arim.ini ile, it include a second [tnc] section. I recommend to # delete ALL of it up until the [arim] section header [arim] #Update mycall to use your callsign : Setting this a second time is required # Do NOT use an SSID suffix here mycall = KI6ZHD #To make the system more robust in poor conditions, try these settings send-repeats = 2 fecmode-downshift = TRUE pilot-ping = 2 -- Ok, that should be a good starting configuration file. Lots of addition ARIM configuration details are available at: http://www.whitemesa.net/arim/arim.html#inst

Whew, that's it and now it's time to give it an official try. Get your radio ready with: - QSY your radio to an ARDOP frequency and USB (see below) - Match to your antenna (attenna tuner, etc) - Turn OFF AGC and lower the RF gain so the signal isn't distorted (mentioned above) Per http://www.obriensweb.com/sked/index.php?board=digitalradio (now seems defunct), try using the frequency: ARDOP: 14066 10135 7045 3590 Bob Cunnings (ARIM developer) also recommends: -- 7.101 and 14.101 USB 7.101 USB seems to have a mix of ARDOP, PACTOR, and I think VARA Winlink stations 14.101 USB seems to have HF packet traffic on it -- I'm seeing some ARDOP on 7.101 USB so I'm using that for now. Next, in one terminal window, run the ARDOP startup script: /usr/local/bin/start-arim-ardop.sh In another terminal window, start ARIM with: arim The ARIM GUI should start up but basically do nothing. At this point, instruct ARIM to connect to the ARDOP TNC by typing in: <space>att 1<enter> The space key is critical to tell ARIM to pay attention that a command is being requested. At this point, ARIM should connect to ARDOP and you should see a bunch of commands in the TUI interface initializing it. In the other ARDOP terminal window, you should see the application connection get started: Host Control Session Connected Host Data Session Connected Ok, so let's see if ARDOP is configured right. To do so, you need to get used to ARIM's command mechanism. This is where you type in a SPACE, then the command, and then ENTER. So, try: <space>tncset<enter> A TUI box should open up showing the key parameters. Hit ENTER to close the window. You can do the same to see the ARQ settings: <space>arqset<enter> Hit ENTER to close the window. Next, try sending a beacon over RF with the command: <space>btest<enter> You radio should get keyed up and send a beacon packet TWICE. If your radio doesn't key up or you don't hear digital mode tones from your radio's monitor feature, you need to troubleshoot things until you do. If things did seem to work.. GOOD! Few more things to do: - Make sure your SWR level is low and you're not running too much power when transmitting. For example, my Yaesu FT950 is rated only at 50w at full duty cycle modes - Do the best command again but look at the ALC on your radio when it's transmitting and make sure there is little to NO ALC Ok, on to real operating steps! I recommend Have your system listen for a while and hopefully you'll hear some ARDOP traffic and you'll see specific remote stations show up in the upper right column. Once you do see some stations, try to do a few things: #I heard WA7ODN so I will use that station for my example: # <space>ping WA7ODN 3<enter> #I received a ping back showing: # [21:38:58] >> [p] WA7ODN>KI6ZHD S/N: -7dB, Quality: 60 Ok, we're getting responses! So now let's try making a connection: <space>conn K2RDX 3<enter> In this example, K2RDX is actually a Winlink station running ARDOP so you can use ARIM to interact witho both ARIM stations but also Winlink stations too! My more common commands (when NOT connected) are: #this sends out an unconnected message for all to see <space>:this is a test<enter> #This changes the beacon time to every 30min # You can see this value chaned in the far-lower-right corner of the TUI <space>btime 30<enter> My more common commands (when CONNECTED) are: /info - learn about the remote station /version - what version of ARDOP and ARIM is running there /gridsq - where is this remote station located /heard - what remote station can that remote station hear /sm -z this is a test - sends a compressed, one-liner message to the remote station's ARIM program /mlist - get a list of remote messages for you from this remote ARIM station There is a ton of othther functionality to ARIM so it's best you read up on all it's features here: http://www.whitemesa.net/arim/arim.html When your done with ARIM, enter in the following in the ARIM window: <space>q<enter> and in the ARDOP window, hit control-c FreeDV is the combination of several tools to bring a robust, truly open digital mode to amateur radio. At the highest levels: - Codec2 is the vocoder that translates your voice into bits - FDMDV encodes those bits into a robust digital mode that usually resembles 15 concurrent PSK31 signals - FreeDV is the GUI that makes everything easy to use Since everything is digital here, you need TWO sound cards to run FreeDV. One for interfacing to the radio to the computer and another interfacing to a microphone/speaker to your computer. At minimum, your existing HF digital modes sound card will let you receive and decode FreeDV signals. Ok, let's get started Fortunately for all of us, the EPEL repos have pre-compiled RPMs for FreeDV (used to be Hobbies COPR repo)! To enable this the EPEL repo, please read the "Enabling Third Party RPM repositories" section eariler in this document. # NOTE: # # This package requires wxGTK 2.9 which is not available in the standard repos like # EPEL. Fortunately, this FreeDV has this package but it's misnamed as WxGTK3 so # yum falls apart here (you'll get errors like): # # Error: Package: freedv-0.96.5-1.el6.x86_64 (freedv) Requires: libwx_gtk2u_html-2.9.so.5(WXU_2.9)(64bit) # # In addition, these packages are requiring the presence of the libgnomeprint and libgnomeprintui # libraries but this dependency is NOT captured in the misnamed wxGTK3 RPMs. # # I have reported both of these issues but until then, you can work around # this with the following commands: sudo yum install libgnomeprint22 libgnomeprintui22 sudo yum install libmspack sudo yum --disablerepo="" --enablerepo="freedv" install wxGTK3-devel # Now let's install it sudo yum install freedv As of 08/26/17, this will install freedv-1.2.2-1.el6.x86_64 # NOTE: # Depending on what other applications you've already installed on your Centos # machine, your system might also need to install additional packages such as: # # gtk2-devel libsamplerate libsamplerate-devel libsndfile libsndfile-devel # alsa-lib alsa-lib-devel portaudio portaudio-devel Ok, so FreeFV is installed. Let's get it configured! Start FreeDV from the command line from your usual non-root username: freedv Goto Tools --> Audio Config Click on the "Receive" tab at the bottom of the screen: - In the "From Radio" section: - select the soundcard that you usually use for your HF digital modes. For me, I'm using "USB Audio CODEC: USB Audio (HW: 1,0) which is my US Interface Navigator - for my soundcard, I change the sampling rate to 48000 - If your HF radio is turned on and things are properly working, click on the "Rec 2s" button on the far right and see if you eventually see a recorded waveform - In the "To Speaker/Headphones" section: - I've selected "HDA Intel PCH: ALC271X analog (hw:0,0) which is my laptop's built in soundcard Click on the "Transmit" tab at the bottom of the screen: - In the "From Microphone" section: - I've selected "HDA Intel PCH: ALC271X analog (hw:0,0) which is my laptop's built in soundcard - In the "From Radio" section: - select the soundcard that you usually use for your HF digital modes. For me, I'm using "USB Audio CODEC: USB Audio (HW: 1,0) which is my US Interface Navigator - for my soundcard, I change the sampling rate to 48000 - If your HF radio is turned on and things are properly working, click on the "Rec 2s" button on the far right and see if you eventually see a recorded waveform To confirm you've created a valid configuration, click on the "Apply" button. If it's not valid, you'll need to continue playing with the settings until it accepts it. Goto Tools --> PTT Config - Under the "VOX PTT Settings", make sure the "Half Duplex" box is checkmarked - For my setup, I normally use the US Navigator's dedicated PTT serial port as it's 100% reliable. Unfortunately, it seems FreeDV asserts the DTR line in addition to the other signals which keys my radio through it's FSK port. This is a bug and I will report it. Until then, I will use Hamlib - Before you click on "OK", turn on your HF radio, QSY the radio to a clear frequency that has a good SWR match and turn it's RF power to it's lowest setting - When you click on "OK and if your HF radio is turn on, you should hear the radio briefly assert PTT and then let it go. If the radio stays keyed up, find your correct settings to resolve this. Goto Tools --> Options - Enter in your callsign - For now, checkmark "Test Frames: Enable" Do NOT goto Tools --> Filter as the program crashes as of 11/08/14 with -- Program terminated with signal 11, Segmentation fault. #0 0x000000000046b7b8 in lsx_biquad_flow (effp=0x2936d30, ibuf=, obuf=, isamp=, osamp=) at biquad.c:154 154 obuf++ = SOX_ROUND_CLIP_COUNT(o0, effp->clips); -- WSPR is what's called a "reverse beacon" program which essentially transmits or receives a modulated carrier (sounds like a slightly changing CW tone) that changes very slowly over a duration of about 120 seconds. It doesn't support two way QSOs like what you can find in JT9, JT65, JT144, etc. This WSPR carrier contains the callsign and top-level MaidenHead grid for the transmitter. These beacons can be decoded WELL under the noise floor and are self identifying. Very nice! This is the main window for decoding remote beacons, etc:

NOTE: There are two generations of WSPR now: WSPR-X: This is the bleeding edge version of the program that has added WSPR-15 for the new 472Khz band as well as switched away from a pure Python GUI to a Qt GUI. This new version requires recent versions of Qt5, Cmake, but is mostly stable and isn't as bleeding edge as WSJT-X (mentioned in a different section). NOTE: WSPR-X has not carried forward rig control nor SDR support at this time. If you want these features, use WSPR instead WSPR: This is the legacy version that uses Python for it's GUI but still works well. This code still works well but isn't getting much development anymore but it's the only version that natively supports SDRs. You can see more about all these requirements here: http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjt-dev-guide.html#_package_matrix Dependency Notes: Both WSJT and WSPR require some dependencies that Centos5 does NOT support out of the box but are well supported with Centos6. Specifically, Centos5 is missing: - Many common dependencies that also Fldigi requires such as Jack, PortAudio, etc.) so be sure to get FLdigi working first - G95 Fortran NOTE: Please note that the WSPR documentation says it requires Python 2.5 but I have it working with Centos5's Python 2.4 - Both WSJT and WSPR can either use Gfortran or G95 - Gfortran is generally available via: yum install gfortran - [Optional] If you really want G95 (unclear if it's any better), download and install G95 Fortran via: wget ftp://anonymous%40g95%2Eorg:/v0.91/g95-x86-linux.tgz tar xvf g95-x86-linux.tgz mv g95-install /usr/local ln -s /usr/local/g95-install/bin/g95 /usr/bin/g95 --------------------------------------------------------------------------- Centos 6 Specific - Please skip down to the Centos5 section if you are running that version --------------------------------------------------------------------------- Let's install the required dependencies: yum install gcc-gfortran yum install numpy (Centos6 drops the "python-" prefix name) yum install python-imaging yum install python-imaging-tk yum install python-pmw (from EPEL repo) If not already installed, also install: yum install portaudio-19 yum install portaudio-19-devel yum install fftw (this installs v3 on Centos6) yum install libsamplerate-devel yum install subversion If you wish to have Rig control support (very nice), you need to install Hamlib. This is described in detail in the Fldigi compilation section - Let's now get a starter RPM spec file: #Get the SRPM and install it cd /tmp wget ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/hamradio/openSUSE_11.4/src/wspr-4.0.r3015-1.1.src.rpm rpm -ivh wspr-4.0.r3015-1.1.src.rpm IF you'd like to get the newest version of code, do the following cd /tmp/ mkdir wspr cd wspr svn co svn://svn.berlios.de/wsjt/branches/wspr WSPRMAJVER=`grep Version= wspr/wspr.py | awk -F\" '{print }' | awk '{print }' ` WSPRMINVER=`grep Version= wspr/wspr.py | awk '{print }' ` 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 Time management: It's CRITICAL to WSPR and other WSJT modes that you have --------------- very accurate time on your PC. I'm talking atomic accurate time within sub-second accuracy. A clock off by +/- 1 second will result in ZERO decodes!!! You've been warned. Make sure you have a good working NTPd setup so that when you run /usr/bin/ntpstat , you see something like: -- synchronized to NTP server (217.160.254.116) at stratum 11 time correct to within 951 ms polling server every 64 s -- Ok, assuming you have an excellent time source, let's start and configure WSPR : run "/usr/local/bin/wspr" Configure WSPR ------------- NOTE: This assumes my setup using a US Interface Navigator NOTE#2: Though WSPR can change the radio frequency, it doesn't change USB/LSB or change the power. You need to set your rig to USB and the proper power level (see below) yourself! NOTE#3: The configuration window always open up BEHIND the main WSPR window so you never know if it opened up or not. Move the main WSPR window to the right to see it. Change the following settings to suit your setup ------------- Call: KI6ZHD Grid: CM97ai Centos6: -------- Audio In: 9 pulse Audio Out: 9 pulse (I had to scroll down to see this) Centos5: -------- Audio In: 8 USB Audio CODEC : USB Audio (HW:1,0) Audio Out: 8 USB Audio CODEC : USB Audio (HW:1,0) Power (dbM): 37 -- this means 5watts but the power must be manually set on the rig itself. 40 dbM is 10w. See the appendix in the WSPR documentation for a lookup table PTT Method: RTS - Specific to the US Interface Navigator PTT port: /dev/USI_PTT - UDEV alias configure per a previous section Enable CAT: check CAT port: /dev/USI_CAT - UDEV alias configure per a previous section RIG number: 128 - Yaesu FT950 serial rate: 38400 - Specific to a change FT950 config data bits: 8 stop bits: 1 handshake: hardware - Simply click on the upper corner window "close box" to close the window and then under the main window, do: - Save --> and make sure that "Save All" is NOT selected. If not, your computer will save every 2minute period as a 2.8MB .wav file! and File --> Save User Parameters Once loaded: 1. Set the Tx fraction to 0% from a default of 20% 2. Check the "Upload Spots" box 3. Goto Band and select and band. Make sure your rig changes frequency 4. uncheck the IDLE radial button 5. In the lower, left side of the screen, change the vertical slider until the lower left field says: "RX Noise: 0db". If this value already says 0 or never changes, change your sound card settings 6. Now WAIT until WSPR says "Receiving" in the lower right corner. When I say wait, I'm talking minutes. It takes some time before WSPR decides is a receive vs. transmit period. It will take TWO more minutes to decodes them, etc. Nothing will show in the horizontal receive water fall until WSPR says "Receiving" and does a 2 minute receive cycle. 7. Eventually, you'll see decodes 8. Make sure the radio is match to the desired frequency (tuner, etc) 9. Change the Tx fraction to 20% ------------------------------------------------------------------------ OLD Centos5 notes: -- Ignore this section for now as it will be deleted: Dependencies: Requires Fortran (similar to JT65) WSPR 2.00 r1714 tarball ./configure (notice that it says it's building 1.11) make gave error on Could not locate executable g77 Could not locate executable f77 /usr/bin/f95 /usr/bin/gfortran error in configure script checking whether gfortran accepts -g... yes ./configure: line 3074: test: =: unary operator expected checking uname -s... n installed compat-gcc-34-g77 -- didn't help from http://www.g95.org/downloads.shtml wget ftp://anonymous%40g95%2Eorg:/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. [[email protected] g95-0.91]# make make all-am --ftp://anonymous%40g95%2Eorg:/v0.91/g95_source.tgz NOTE: The SPEC file found at ftp://anonymous%40g95%2Eorg:/g95.spec is not clean and will not work without significant work. You've been warned. Compile from source and make install for now NOTE#2: make install puts binary in the following dir but the installation fails to totally complete. Workaround: configure it --> Setup --> Options My Call: KI6ZHD Grid: CM97ai ID Interval: 10m PTTY port: /dev/ttyUSB1 Audio In: 14 Audio Out:14 Rate In : 1.0 Rate Out: 1.0 Power (dbM): 40 -- this means 10watts but must be manually set on the rig itself PTT Method: RTS Enable CAT: check CAT port: /dev/ttyUSB0 ---> BROKEN information when I was trying to compile WSPR ---------------------------------------------------- To Get Python 2.5, you have to download a hacked version. I looked into hacking things up with using Python 2.5.5 and a SPEC file stolen from below but the SPEC file is for Python 2.5.1 and requires specific 2.5.1 Patches which break against 2.5.5 To build Python 2.5.1, you first need to install the following yum install tk-devel tix-devel http://www.geekymedia.com/tech-articles/rhel5-centos5-rpms-for-python-2-5-and-2-6/ --> python25-2.5.1-bashton1.src.rpm Now, lets build the hacked up Python 2.5.1 cd /usr/src/redhat/SPECS rpmbuild -bb --target=i686 python.spec Notice that I'm installing not upgrading Python here: cd /usr/src/redhat/RPMS/i686 rpm -ivh python25-2.5.1-bashton1.i686.rpm python25-libs-2.5.1-bashton1.i686.rpm #Installing the developer libs is a good idea too rpm -ivh /usr/src/redhat/RPMS/i686/python25-devel-2.5.1-bashton1.i686.rpm Newest code: http://www.python.org/download/releases/2.5.5/ mv Python-2.5.5.tar.bz2 /usr/src/redhat/SOURCES/ END Legacy BROKEN information WSJT is a suite of weak signal modes including JT9, JT65, etc. from W1JT. What's unique about these modes is that they are extremely timing sensitive that requires ALL stations to have the same time withing +/- 5 seconds. With this requirement satisfied, many of these modes like JT65 can decode signals well into the noise that cannot be heard or seen on the waterfall. This is the main window for decoding remote stations, sending CQ:

This is the waterfall window showing 1-minute decodes:

NOTE: There are two generations of WSJT now: WSJT-X: This is the bleeding edge version of the program that has the new JT9 mode has switched away from a pure Python GUI to a Qt GUI. It requires a very modern versions of Qt5, Python3, Cmake, and is constantly changing. Keeping up with WSJT-X is rather difficult for stable OSes like Centos. WSJT: This is the legacy version that does NOT support JT9 but works well for JT65. This code still works well but isn't getting much development anymore. You can see more about all these requirements here: http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjt-dev-guide.html#_package_matrix +---------------------------+ | To be updated for Centos6 | +---------------------------+ http://physics.princeton.edu/pulsar/K1JT/devel.html NOTE: No RPM SPEC available at the Fedora site [ requires all above dependencies to get this to compile] Centos5 Note: I was unable to get WSJT 7.x to work properly with Centos 5.4 and it's default version of Python. The very old WSJT 5.98 works fine but lacks the now deprecated WSPR QSO mode. NOTE#2: Unlike WSPR, WSJT doesn't support RIG control though it seems it does by selecting the band. Let's get down to it. First off, WSJT has very similar dependencies to WSPR (discussed in a previous section) as well as Fldigi. As of this writing, you MUST complete Fldigi's dependencies per that section to have any luck compiling WSJT here. Step 1: Fortran Centos6: -------- yum install gcc-gfortran Step 2: Installing fftw (version 3) Centos6: (with no version specified infers FFTW v3) --------------------------------------------------- yum install fftw.x86_64 fftw-devel.x86_64 Step 3: Python libs yum install numpy numpy-f2py python-imaging python-imaging-tk Step 3: PortAudio v19 (newer) This is covered in the Fldigi section Ok, that's it but there aren't any SPEC files included with WSJT so it's recommended you get a copy of mine found here: http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/wsjt.spec Next, since all the code is in Subversion, we need to get the code and put it into an archive the SPEC file can deal with: cd /usr/src/redhat/SOURCES mkdir wsjt cd wsjt #The new WSJT code is only available in the Subversion repository svn co svn://svn.berlios.de/wsjt/trunk #When the subversion checkout completed, you should have seen something like: # # Checked out revision 2501 # # This seems to then translate to be version "9.2 - r2472" per the wsjt.py file # #Rename the directory to reflect the version, checkout and then compress it up: # mv trunk wsjt-9.2.r2472 tar civf ../SOURCES/wsjt-9.2.r2472.tar.bz2 wsjt-9.2.r2472/ cd .. rm -Rf wsjt Ok, time to build up the RPM: Centos6: ------- rpmbuild -bb --target=x86_64 wsjt.spec If you'd like to compile things manually for Centos6 ---------------------------------------------------- ./configure --with-portaudio-include-dir=/usr/include --with-portaudio-lib-dir=/usr/lib64/ Centos5 (or if you want to manually compile things w/o an RPM): --------------------------------------------------------------- tar xzvvf ../SOURCES/wsjt-5.98-r558.tgz cd /usr/src/redhat/BUILD/wsjt-5.98-r558/trunk ./configure --enable-g95 make make install Configuring and Running WSJT: ----------------------------- - Start WSJT from the command-line by purely running: wsjt and ignore all the errors that show up on the command line for now. - You'll see output of all detected portaudio devices in the terminal window that you started it from: For Centos6 machines running 9.2 --------------------------------------------------------------------- WSJT Version 9.2 r2472 , by K1JT Revision date: 2012-06-21 07:00:38 -0700 (Thu, 21 Jun 2012) Run date: Wed Jul 11 01:26:54 2012 UTC ALSA lib pcm.c:2209:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2209:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2209:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side Audio Input Output Device Name Device Channels Channels ------------------------------------------------------------------ 0 2 2 HDA Intel PCH: ALC271X Analog (hw:0,0) 1 0 8 HDA Intel PCH: HDMI 0 (hw:0,3) 2 2 2 USB Audio CODEC: USB Audio (hw:1,0) 3 0 2 front 4 0 2 surround40 5 0 2 surround51 6 0 2 surround71 7 0 8 hdmi 8 32 32 pulse 9 0 2 dmix 10 32 32 default User requested devices: Input = 0 Output = 0 Default devices: Input = 10 Output = 10 Will open devices: Input = 10 Output = 10 ===================================================================== ===================================================================== For Centos5 machines running v5.9.8 --------------------------------------------------------------------- WSJT Version 5.9.8 r558 , by K1JT Revision date: 2007-10-08 09:47:34 -0400 (Mon, 08 Oct 2007) Run date: Sat Apr 10 23:28:23 2010 UTC Using PortAudio. Audio Input Output Device Name Device Channels Channels ------------------------------------------------------------------ 0 16 16 /dev/dsp 1 16 16 /dev/dsp1 2 16 16 /dev/dsp2 3 2 2 Intel 82801DB-ICH4: Intel 82801DB-ICH4 (hw:0,0) 4 2 0 Intel 82801DB-ICH4: Intel 82801DB-ICH4 - MIC ADC (hw:0,1) 5 2 0 Intel 82801DB-ICH4: Intel 82801DB-ICH4 - MIC2 ADC (hw:0,2) 6 2 0 Intel 82801DB-ICH4: Intel 82801DB-ICH4 - ADC2 (hw:0,3) 7 0 2 Intel 82801DB-ICH4: Intel 82801DB-ICH4 - IEC958 (hw:0,4) 8 1 1 Intel 82801DB-ICH4 Modem: Intel 82801DB-ICH4 Modem - Modem (hw:1,0) 9 2 2 USB Audio CODEC : USB Audio (hw:2,0) 10 2 2 front 11 0 2 iec958 12 0 2 spdif --------------------------------------------------------------------- Notice the device number on the USB Audio codec of "2". Remember that now and shut WSJT back down. IMPORTANT: ---------- The WSJT application is written with rather old methods and needs ALL incoming audio to be sampled at 11,025/sec. Some devices can support those low rates but the US Interface Navigator USB device, the Signalink USB device, and others require us to downsample per the following URL: Modern solution: ---------------- http://list-serv.davidv.net/pipermail/moon-net_list-serv.davidv.net/2008-August/013751.html USER/.asoundrc -- pcm.radio { type hw card 2 device 0 } pcm_slave.radioslave { pcm radio rate 48000 } pcm.radioconv { type rate slave radioslave } Legacy solution: ---------------- http://www.nitehawk.com/w3sz/wsjt596hints.html his solution --> ./configure --enable-portaudio --with-portaudio-include-dir=/usr/portaudio/v19-devel/include \ --with-portaudio-lib-dir=/usr/portaudio/v19-devel/lib/.libs/ --with-jack=no Start WSJT back up and notice the updated sound card list: WSJT Version 5.9.8 r558 , by K1JT Revision date: 2007-10-08 09:47:34 -0400 (Mon, 08 Oct 2007) Run date: Sat Apr 10 23:28:23 2010 UTC Using PortAudio. Audio Input Output Device Name Device Channels Channels ------------------------------------------------------------------ 0 16 16 /dev/dsp 1 16 16 /dev/dsp1 2 16 16 /dev/dsp2 3 2 2 Intel 82801DB-ICH4: Intel 82801DB-ICH4 (hw:0,0) 4 2 0 Intel 82801DB-ICH4: Intel 82801DB-ICH4 - MIC ADC (hw:0,1) 5 2 0 Intel 82801DB-ICH4: Intel 82801DB-ICH4 - MIC2 ADC (hw:0,2) 6 2 0 Intel 82801DB-ICH4: Intel 82801DB-ICH4 - ADC2 (hw:0,3) 7 0 2 Intel 82801DB-ICH4: Intel 82801DB-ICH4 - IEC958 (hw:0,4) 8 1 1 Intel 82801DB-ICH4 Modem: Intel 82801DB-ICH4 Modem - Modem (hw:1,0) 9 2 2 USB Audio CODEC : USB Audio (hw:2,0) 10 2 2 front 11 0 2 iec958 12 0 2 spdif 13 2 2 radio 14 2 2 radioconv Configure WSJT to use appropriate Audio Device number for device called "radioconv". Setup --> Options NOTE: I've found that this "options" window will NOT always come up in the foreground so you might have to go find it first. Lame. NOTE #2: Change the following to represent your specific details My Call: KI6ZHD Grid: CM97ai ID Interval: 10m #This reflects the use of custom Udev device enumeration PTTY port: /dev/USI_PTT Audio In: 2 Audio Out:2 Rate In : 1.0 Rate Out: 1.0 Other good build doc: http://foxgulch.com/WordPress/?p=557 :1 +---------------------------+ | 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: vhfdrop baud rate: 1200 Enable TNC beacon: yes password: root passwd in a different window, - disable any gettys running on tty5 - add c5:1235:respawn:/usr/local/jnos/startnos /dev/tty5 - run telinit q axlisten removed for "listen" listen -8acrp vhfdrop call -bl -me -r vhfdrop k6sny-1 added an alias for: alias call='call -bl -me -r' Download the ported pskmeter.py app and the currently stable version pyserial module at http://aa6e.net/wiki/Pskmeter.py . PySerial is also installed via the Chirp section of this document. NOTE: The author of FLdigi also has his own pskmeter program that also supports PSK63 but I haven't tried it out yet: http://www.w1hkj.com/LinuxApps/pskscope.3.0.tar.gz As root, - install the pyserial module (for version 2.4) - See the Chirp section for how to create the RPM for Centos6 or Centos5. Alternatively, you can do it as a source via (not recommended): python setup.py install - Next, install Tkinter yum install tkinter - Centos5: -------- install aumix (no Yum package available) download from http://freshmeat.net/projects/aumix/ tar xivf aumix-2.8.tar.bz2 cd aumix-2.8 ./configure make sudo make install ln -s /usr/local/bin/aumix /usr/bin/aumix Note: I re-used the USB to serial interface I had connected to my Yaesu FT-950's CAT interface. To make sure that fldigi wasn't going to conflict, I disabled the HAMLIB interface. Installing and Configuring pskmeter.py: - Download the code mkdir /usr/src/archive/PSKMeter wget -O http://aa6e.net/wiki/Pskmeter.py - Serial ports: - the pskmeter.py program defaults to looking for it's controlling serial interface at /dev/ham.pskmtr. To make it work for my setup, I did the following as root: Centos 6: --------- ln -s /dev/ftdi-serial-cbl /dev/ham.pskmtr Centos 5: --------- ln -s /dev/ttyUSB0 /dev/ham.pskmtr - Make sure your username is in the "dialout" group as discussed in the Fldigi section of this doc. Alternatively, you run the command: Centos 5: "chmod 666 /dev/ttyUSB0" so that the pskmeter.py program can access the serial port - Soundcard Mixer devices: - The pskmeter.py program defaults to an alternate mixer that what's usually installed with Centos6 or Centos5. Edit the pskmeter.py program and change the MIXER setting to the following: MIXER="/dev/mixer" - Centos6: --------- With version 6, OSS is no longer natively supporting the legacy OSS devices such as /dev/dsp and /dev/mixer. Now, it does things via ALSA emulation. To get /dev/mixer, run the following to get pskmeter25.py to work: modprobe snd-mixer-oss - Software mixing controls pskmeter.py program assumes it can run the mixing program "aumixer" which isn't installed with Centos. Edit the pskmeter.py program, search for the text "aumixer" and put in - Centos 6: --------- You need to change the getLeve () routine to be something like: command = "amixer --c 1 cget iface=MIXER,name='PCM Playback Volume',numid=2" | grep ' : values'" BTW, the proper way to control volumes with Centos6 is with PulseAudio and the best way to do that is via pavucontrol as installed in the Fldigi section - Centos 5: --------- aumix (GUI): command = "/usr/bin/aumix -d "+MIXER+" -wq" #The following command gives the output like: # pcm 71, 71 , alsamixer or amixer - There is also a patch file that you can apply that will set some of these items for you: wget -r -l1 -nd --no-parent -A pskmeter www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ - Ok, follow the PSKmeter instructions in how to setup and run it. To troubleshoot it, you can run something like the minicom terminal program at 19200-8N1. Now turn on or plug in the pskmeter and you should see a plain English initialization string when it starts up Now, fire up fldigi (or whatever app your using to do PSK31): - find a clear, open frequency - set your rig to low power - tune up to a low SWR - now insert the pskmeter between the rig and the antenna tuner to protect it from reflected power - On fldigi, hit the QSY button to put the PSK31 signal in the sweet spot - Start up the meter with: python pskmeter025.py - In Fldigi, there is the TUNE button in the upper right but that's a SINGLE tone, you want to run a PSK-31 note test by hitting the key sequence Control-t in the blue window of Fldigi Using Kmix: - setting the PCM output too low looses resolution - Master and Master mono output do NOTHING - Original headphones setting was 45 which resulted in under-driving levels. PSKmeter for windows seemed to be happy at 59 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 digital mode, it also supports all the major analog SSTV formats like Scottie, HamDRM, etc.
This is the main window for Qsstv 9.x Digital SSTV program:

This is the main RX gallery for Qsstv 9.x Digital SSTV program:

Click here to see screen captures for previous versions of QSSTV: Here is a little detail on the different generations of Qsstv: Qsstv v9.x has changed the UI a bit where it has now separated the analog vs. digital modes a bit. It has also improved the DRM support, added some modern analog modes, and in 9.1.1, it's moved from the aging Jasper JPEG library to the newer OpenJPEG libraries. Qsstv (v8.x) added HamDRM digital SSTV support which is compatible with the Windows EasyPal and Linux RXTXAMADRM digital SSTV programs. This new version includes BSR fix support, Hybrid mode, and more. This new code requires the Qt 4.8.x framework which that installation is covered in the Gqrx section of this document. IMPORTANT: ---------- These new Qt4.8 libraries are NOT compatible with Centos5. As such, if you're running Centos5, you're at a dead end. Time to upgrade to a newer version Centos. QSSTV (v7.1.x) supported Analog SSTV modes only but all of it's dependencies are natively available in Centos6. Centos5 users can upgrade the core Qt libraries with third party libs to make it work. With that said, it starts getting pretty sketchy and you can break your OS if you're not careful. It's great news that it's technically possible but doing this is NOT for the faint of heart (Centos 5)! Please see: http://users.telenet.be/on4qz/faq.html#Centos57 for more details. +--------------------------------------------------------------------------------+ | IMPORTANT: The top section of this chapter covers QSSTV 9.2.6 for Centos6. | | If anything else, I've had good luck with v8.2.12 which has a few | | less features but might be more stable. | | | | Older versions of Qsstv like 8.1.x, 7.x, and 5.3c are still | | covered in the bottom of this section but they should be considered | | DEPRECATED. | +--------------------------------------------------------------------------------+ Build prerequisites Centos6 users --------------------------------- To properly build QSSTV 9, you need to install following libraries before hand: - fftw-devel (version 3) - Covered in the WSJT and TXAMADRM section) - qt5-devel - Qt-5.x libraries which is Covered in the Gqrx section (new as of 9.2.6) - hamlib-devel - Covered in the Fldigi section - alsa-lib-devel - Covered in the Soundmodem and Fldigi section - openjpeg2 - covered in this section - openjpeg2-devel - covered in this section - libv4l-devel - covered in this section and new to Qsstv 9.x +-----------------------------------------------------------------------------------+ | Important: | | | | Per the above Qt5 requirement, please review the "42.j1 - Gqrx - Installing final | | Gqrx dependencies" section in this document to install Qt5 | +-----------------------------------------------------------------------------------+ # Ok, lets get a SRPM to start our work with # cd /usr/src/redhat/SRPMS # Centos 6 - You can use my SPEC file (recommended) or build your own using the Fedora16 package # (same GLIBC version as Centos6) # # --------------------------------------- # Using my SPEC file: # (Recommended) # --------------------------------------- # wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/qsstv-9.spec # If you want to build an older version, you can find legacy SPEC files: # wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/qsstv-8.spec wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/qsstv-7.spec #Now skip ahead to the next section # ---------------------------------------- # (NOT RECOMMENDED) # # If you want to create your own spec file # ---------------------------------------- # Get a starting spec file from http://koji.fedoraproject.org/koji/packageinfo?packageID=6659 # wget http://kojipkgs.fedoraproject.org//packages/qsstv/7.1.7/1.fc16/src/qsstv-7.1.7-1.fc16.src.rpm #Rename any old spec files if present cd /usr/src/redhat/SPECS mv qsstv.spec qsstv-7.1.7.spec rpm -ivh qsstv-7.1.7-1.fc16.src.rpm mv qsstv.spec qsstv-9.spec # Now let's update the spec file to reflect the new code and requirements # cd /usr/src/redhat/SPECS vim qsstv-9.spec -- 1. Update the Version to: 9.1.7 2. Update the License to: GPLv3 3. Update the Source0 line to: http://users.telenet.be/on4qz/qsstv_9/downloads/qsstv_%{version}.tar.gz 4. Delete the previous version's patches by removing the following lines Patch0: qsstv-fix-html-doc-path.patch Patch1: qsstv-fix-target-path.patch Patch2: qsstv-gcc47_unistd.patch and %patch0 -p1 -b .docpath %patch1 -p1 -b .targetpath %patch2 -p1 -b .gcc47 5. Update and add the following BuildRequires lines: BuildRequires: fftw-devel >= 3.0 BuildRequires: qt-devel >= 5.0 BuildRequires: openjpeg2 BuildRequires: openjpeg2-devel BuildRequires: libv4l-devel 6. Disable the sed command: #sed -i 's| strip $(TARGET);||g' src/src.pro 7. IN the %files section, delete the line: %{_docdir}/%{name}/ # ------------------------------------------------- # Back to all users (For all SPEC file approaches): # ------------------------------------------------- # Next, let's get the new version of QSSTV as of 03/28/18: # cd /usr/src/redhat/SOURCES wget http://users.telenet.be/on4qz/qsstv/downloads/qsstv_9.2.6.tar.gz Next, let's install the new OpenJPEG libraries from the EPEL Repo (New to replace the obsolete Jasper JPEG libraries): sudo yum install openjpeg2 openjpeg2-devel Ok! Time to build and install Qsstv ------------------------------------ cd /usr/src/redhat/SPECS #Centos6 with x86_64 # Takes 6m28sec on a i5-2430-2.4Ghz laptop with 4GB RAM and a SSD HD # time rpmbuild -bb --target=x86_64 qsstv-9.spec #Now install it with sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/qsstv-9.1.8-1.el6.x86_64.rpm Skip to the next section on how to configure QSSTV 9.x and use it ================================================================================== This section covers the building of the OLDER version of QSSTV - NOT RECOMMENDED Qsstv 5.3c (which works very well) for Centos5 users as well as v7.1.7 for Centos6 users but neither version supports HamDRM digital SSTV - only analog SSTV ================================================================================== You can download this new version and older versions at: http://users.telenet.be/on4qz/history/index.html Notes on the different versions of QSSTV: ------------------------------------------------------------------------ QSSTV 7.1.7 - Requires a more modern distribution like Centos 6 or MAJOR low-level changes to Centos5 to get working (not recommended) QSSTV 6.0a (alpha) - Unusable - has major slant issues and others have complained as well. It was never fixed http://users.telenet.be/on4qz/snapshots/ QSSTV 5.3c - works fine with Centos5 but it's image editor is very difficult to use ------------------------------------------------------------------------ As usual, there are two ways to get things installed. RPMs or Sources. Using the SRPM from Fedora works very well and already includes the required patches to get things working without any fuss. SRPMS: Downloading them which includes the Sources and Patches -------------------------------------------------------------- cd /usr/src/redhat/SRPMS # Centos 6 - Use the Fedora16 package (same GLIBC version as Centos6) # # from http://koji.fedoraproject.org/koji/packageinfo?packageID=6659 wget http://kojipkgs.fedoraproject.org//packages/qsstv/7.1.7/1.fc16/src/qsstv-7.1.7-1.fc16.src.rpm rpm -ivh qsstv-7.1.7-1.fc16.src.rpm #For Centos5 - Used the Fedora Core 9 (same GLIBC version as Centos5) #-- from http://koji.fedoraproject.org/koji/packageinfo?packageID=6659 --> wget http://kojipkgs.fedoraproject.org/packages/qsstv/5.3c/3.fc9/src/qsstv-5.3c-3.fc9.src.rpm rpm -ivh qsstv-5.3c-3.fc9.src.rpm Build prerequisites (skip this for Centos6 users): -------------------------------------------------- To properly build QSSTV 7.1, you need to install following libraries before hand: - fftw-devel (this is version 3) - Covered in the WSJT and TXAMADRM section) - qt-devel - Qt-4.4 libraries which is Covered in the WSJT section - hamlib-devel - Covered in the Fldigi section - alsa-lib-devel - Covered in the Soundmodem and Fldigi section Centos5 ONLY SPEC changes (skip this for Centos6 users): -------------------------------------------------------- The provided 5.3c SPEC file for Centos5 needs two modifications. One is to require Qt-4 (qt-4.4 actually) and another to resolve an RPM building issue): vim qsstv.spec # Change the line: BuildRequires: qt3-devel # to BuildRequires: qt-devel # and # Change the line: desktop-file-install \ --dir=${RPM_BUILD_ROOT}%{_datadir}/applications %{SOURCE1} # to desktop-file-install \ --dir=${RPM_BUILD_ROOT}%{_datadir}/applications %{SOURCE1} --vendor="" Ok! Time to build it! ---------------------- #Centos6 with x86_64 rpmbuild -bb --target=x86_64 qsstv.spec rpm -Uvh /usr/src/redhat/RPMS/x86_64/qsstv-7.1.7-1.el6.x86_64.rpm #Centos5 with i686 rpmbuild -bb --target=i686 qsstv.spec rpm -Uvh /usr/src/redhat/RPMS/i686/qsstv-5.3c-3.i686.rpm ----------------------------------------------------- INCOMPLETE: Legacy issues related to Qsstv 6.0 Alpha ----------------------------------------------------- http://ubuntuforums.org/showthread.php?t=935732 other qsstv users http://forums.fedoraforum.org/showthread.php?p=1357105 --gt; Seems the solution is to turn off "Auto Slant Adj." Ubuntu bug tracking slant problems - no assignment https://bugs.launchpad.net/ubuntu/+source/qsstv/+bug/581407 Before you start qsstv for the first time, make the following directories: mkdir -p $HOME/Qsstv/Receive mkdir $HOME/Qsstv/Templates mkdir $HOME/Qsstv/Transmit mkdir $HOME/Qsstv/Audio Centos Users running Qsstv 9.x, 8.x and 7.x: -------------------------------------------- NOTE on upgrades from 8.x to 9.x -------------------------------- If you have been using Qsstv 8.x and are now upgrading to 9.x, please note that your previous configuration files will NOT load. You will need to reconfigure the application for file paths, rig control, etc. Ok, next step.. Get the Qsstv example QSO templates: cd $HOME/Qsstv/Templates wget -r -l 1 -np -nd http://users.telenet.be/on4qz/qsstv/templates Next, let's figure out what soundcard you need to use for Qsstv. Qsstv both supports PulseAudio and native Alsa. Run the command "cat /proc/asound/cards" and note the correct Soundcard that is connected to your radio. For me, it's device "2": [[email protected] Qsstv]$ cat /proc/asound/cards 0 [I82801DBICH4 ]: ICH4 - Intel 82801DB-ICH4 Intel 82801DB-ICH4 with STAC9750,51 at irq 7 1 [Modem ]: ICH-MODEM - Intel 82801DB-ICH4 Modem Intel 82801DB-ICH4 Modem at irq 7 2 [default ]: USB-Audio - USB Audio CODEC Burr-Brown from TI USB Audio CODEC at usb-0 Now start up QSSTV ------------------ Configure it in Options --> Configure Personal Settings: - Callsign: <your callsign> - First name - Last Name - QTH - Locator (Grid square) General: - set the paths to match the ones we created above Interfaces: Leave the RX/TX clock frequency alone for now Input / Output Audio device: Qsstv 9.x on Centos6: I set it to "pulse" to use the Pulse Audio system but I could have also hard coded it to "hw2,0" NOTE: Qsstv 9.1.1: I've tried the native ALSA mode but I've seen where the waterfall display will STOP updating and the interface won't respond properly. Sometimes toggling between SSTV (analog) and DRM (digital) will get the waterfall going again Qsstv 5.3: set the Audio device (for me) to: /dev/dsp2 Qsstv 5.3: Serial port for PTT (for me): /dev/ttyUSB1 CAT and PTT (Qsstv 9.x): This section is a bit confusing. The use of Hamlib within Qsstv is ONLY to key up the radio (PTT) and nothing more. There isn't any VFO control, filter control, etc. In addition to that, you can only configure either CAT services to key up the rig or enable the "special serial port" to key up the rig. If you try to enable both, and click on ok, you'll get a non-helpful error. For me, I use the "special serial port" PTT method NOT checked: Enable Hamlib Cat interface NOTE#2: On the FT950, if you use CAT-based PTT while the radio is in SSB mode, the radio will only listen to the front facing MIC port! Either you need to put the radio in PKT mode (not SSB mode) or you need to use the special serial port serial approach to key the rig. Checked: Enable PTT serial interface Serial port: /dev/USI_PTT !!!!!!!!!!!!! NOTE: Investigating: It seems that the QSSTV system needs to be !!!!!!!!!!!!! configurable of which RS232 signal to assert to key up various radios. It needs to be similar to say how Flrig does things since: - FT950: If the FT950 is used with a US Interface Navigator (now Timewave) soundcard and the radio is in SSB mode and I use Qsstv's "Serial PTT" option, the rig will key up. You will hear the analog SSTV signal BUT unfortunately also hear a solid CW tone on top of that signal. Once Qsstv stops sending it's signal, the FT950 radio will remain keyed up and sending that CW tone until QSSTV is shutdown! This behavior is due to Qsstv asserting the DTR RS232 signal high and the FT950's Menu #41 option (Allow to send CW while being in SSB mode) being set to "ON". The DTR line on the Navigator means "CW system, key up and transmit your tone"! Workaround: You need to either change the FT950 menu option #41 to OFF or Qsstv needs to be changed to NOT use the DTR serial line. The FT950 option #41 OFF setting works but until Qsstv is shutdown, you will still see the "CW" LED lit up. The downside here is if you accidentally change the FT950 to CW mode, the radio will instantly key up and won't stop transmitting until you either shut down Qsstv! Even if you turn off your radio and turn it back on, it will again key up and send a constant CW tone. I've already requested the developer to add a "!DTR" (do NOT assert DTR ever) feature as of 02/14/15 but this might take some time. - If the rig is in PKT mode and you use QSSTV's "Serial PTT" option, the rig does properly key up, the SSTV signal is there but now there isn't the incorrect solid CW tone. Yay! CW : Text to send to: "(callsign) - qsstv" Now click on OK and then close and restart the program Configure PulseAudio with Centos6 --------------------------------- - Make sure your radio is powered up and is configure for low power or transmitting into a dummy load - Start the PulseAudio Volume Control "pavucontrol") program - Go to the Recording tab, find the "QSSTV" application and change the Capture source to your proper sound device (don't select the "monitor" version of a given device) - Next, while leaving the PAVC program running, switch back to Qsstv and go to the Transmit tab - Click on the middle-ish folder icon and select a picture file, (any picture file for now). That picture should show up in the right hand preview window - Now click on the upper right "Play" button and QSSTV should start transmitting. For me, it started playing to the laptop's built- in soundcard (not what I wanted). To fix that, - Go back to PAVC, select the playback tab and you should now see "ALSA plug-in [qsstv]: Alsa Playback on:" and for me, I want to switch it to "USB Audio CODEC analog stereo" - At this point, your radio should key up and start transmitting! Upon restart, you will now see a FFT display in the lower left corner (5.3), lower right (7.1), or all of the right side on 9.x. You can click on the FFT box and change the view to be a water fall display instead. Calibrate the Soundcard with WWV and the calibrate feature ----------------------------------------------------------- Full Duty Cycle modes and you radio's transmit power: QSSTV is a high duty cycle mode and unless your radio supports full power on high duty cycle modes (rare except on some Icom, Elecraft, etc), you MUST set the radio to a lower output level. Read the Fldigi section for more details about tuning power levels, controlling ALC, etc. Follow the Qsstv documentation on how to calibrate your Slant / time skew: http://users.telenet.be/on4qz/qsstv/documentation/gettingstarted.html#calib Resizing pictures: ------------------ It's important to remember that Qsstv isn't fast in transferring pictures due to the limited RF bandwidth HAMs are allowed to transmit with. As such, images shouldn't be too big or they will take FOREVER to transfer! To reduce the image size, you need to do image pre-processing. This is best done with either the ImageMagick or GraphicMagick programs. For now, I'm using use GraphicsMagick: To aid in finding a small enough size picture to transmit, I wrote the following extra script to simplify the converting to JPEG2000, resizing, and changing of the quality metrics to get files to fit a chosen do-not-exceed size: http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/resize-jpg-jp2-640-variqual.sh One final note: --------------- - All Qsstv configuration settings are stored in $HOME/.config/ON4QZ and all picture files are stored in $HOME/Qsstv Ok, after all that, you're now ready to transmit and receive SSTV pictures! +---------------------------+ | 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 need to write it up, easy to install, simple NCURSES interface This is the main window following the beacons in their specific geography:

DRM or Digital Radio Mondale is a next generation digital broadcast system for use for domestic radio, shortwave radio (ultra long distance), and HD digital voice/data, etc. Generally speaking, DRM is a commercial broadcast technology so it's not used in amateur radio but the most common use of DRM like technology in amateur radio uses is EasyPal which uses the lower bandwidth HAM-DRM for digital SSTV transmissions. This section also briefly touches on Linux software to decode DRM broadcasts +---------------------------+ | To be updated for Centos6 | +---------------------------+ -------------------------------- Ultra Important full-stop notes: -------------------------------- 1) The Dream software that decodes DRM broadcast signals requires a radio which passes a 20Khz pass-band (most amateur radio's only pass 3.5Kkz). This either: - requires hardware modifications of modern Amateur radio HF rigs - use an SDR or a pan-adapter (Flex, RTL, SoftRock, etc) +---------------------------------------------------------------------+ |Putting it another way, unless you have a radio that supports a 20Khz| | passband, this program will NOT work for you! Don't bother | | installing unless you have the required hardware! | +---------------------------------------------------------------------+ 2) Centos 5 specific: This software is NOT compatible with WSPR without extensive chrooting. Installing this WILL break your WSPR install. Ask me how I know! Other DRM-compatible software (all OSes): ----------------------------------------- - SoDiRa : Windows : http://www.dsp4swls.de/sodira/sodiraeng.html Decodes AM envelope, AM synchronous, AM stereo, LSB, USB, FM, FM Broacast, DRM30, DRM +, AMSS, DCF77, RDS, RF sensors +------------------------------------------------------------------------------------------+ | To the reader: This DReAM section is generally incomplete as it didn't work on Centos 5 | | and I haven't tried to apply to Centos 6. For general Ham-DRM SSTV, | | skip this section and skip down to the Qsstv section | +------------------------------------------------------------------------------------------+ The DReaM program requires a few specific packages. Please see the DRM build pages for full details: http://drm.sourceforge.net/installationrpm.html#linux Some Linux specific DRM building instructions beyond these instructions can be found at: http://drm.sourceforge.net/installationrpm.html and http://www.fineware-swl.com/drm.html NOTE: I also found an older Binary RPM for Dream: http://www.sp5pbe.waw.pl/sp5smk/drm.html Older notes: ------------ - legacy FFTW libs (The FFTW v3 library installed for WSPR are too new): yum install fftw fftw-devel # Will install fftw-2.1.5-4.el5.rf.i386.rpm and fftw-devel-2.1.5-4.el5.rf.i386.rpm NOTE: Not sure if this will be a conflict with WSPR that needs FFTW3 both libs are installed at the same time - QT4 rpm -ivh ftp://ftp.pbone.net/mirror/ftp.centos.org/5.5/os/x86_64/CentOS/qt4-4.2.1-1.i386.rpm \ ftp://ftp.pbone.net/mirror/ftp.centos.org/5.4/os/i386/CentOS/qt4-devel-4.2.1-1.i386.rpm - FAAD2 for MP4 #Note: the faad2 available in Yum is not compatible as it won't support encoding (only decoding) yum install faad2 faad2-devel - FAAC for MP4 encoding (the documentation does NOT mention this requirement anywhere! Grrr.. yum install faac faac-devel - Ccache to help install QWT yum install ccache installs ccache.i386 0:2.4-1.2.el5.rf - QWT : NOTE the current version of qwt is 5.1.2 which is TOO new for DRM (sheesh!) They recommend to use their SRPM cd /usr/src/redhat/SRPMS wget http://drm.sourceforge.net/download/qwt-4.2.0-1.src.rpm rpm -ivh qwt-4.2.0-1.src.rpm cd /usr/src/redhat/SPECS #There is a bug in their SPEC file. Find the following line: (cd examples; make"CXX=`which ccache` g++") and make it look like the following (added a space) (cd examples; make "CXX=`which ccache` g++") rpmbuild -bb --target=i686 qwt.spec rpm -ivh /usr/src/redhat/RPMS/i686/qwt-4.2.0-1.i686.rpm \ /usr/src/redhat/RPMS/i686/ ------------- Unstable release is incomplete -- missing bootstrap files -------------- Download DRM unstable (this is MUCH newer than the posted 1.12b release) Get the unstable version mkdir /usr/src/redhat/SOURCES/drm-unstable cd /usr/src/redhat/SOURCES/drm-unstable svn co https://drm.svn.sourceforge.net/svnroot/drm drm #now clean it up to be compiled into a RPM cd /usr/src/redhat/SOURCES/drm-unstable/drm rm -Rf aqua rsci theseus cd dream mv .. cd .. rm -Rf dream cd .. tar czvf /usr/src/redhat/SOURCES/drm-1.5.tar.gz cd sh bootstrap ./configure Legacy info -- old dream 1.12b Legacy info -- incompatible newer versions of qwt ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/9/Everything/i386.newkey/os/Packages/qwt-devel-5.0.2-6.fc9.i386.rpm rpm -ivh ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/9/Everything/i386.newkey/os/Packages/qwt-5.0.2-6.fc9.i386.rpm \ ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/9/Everything/i386.newkey/os/Packages/qwt-devel-5.0.2-6.fc9.i386.rpm http://qwt.sourceforge.net/ rpm -ivh \ http://www.gtlib.gatech.edu/pub/fedora-epel/5/i386/qwt-5.1.2-0.el5.i386.rpm \ http://www.gtlib.gatech.edu/pub/fedora-epel/5/i386/qwt-devel-5.1.2-0.el5.i386.rpm ----------------------------- Legacy DRM provided FAAD code ----------------------------- Using the DRM team's version of FAAD cd /usr/src/redhat/SRPMS wget http://drm.sourceforge.net/download/faad2_2.0.1cvs2006124_1.src.rpm rpm -ivh faad2_2.0.1cvs2006124_1.src.rpm cd /usr/src/redhat/SPECS rpmbuild -bb --target=i686 --define without_xmms=1 faad2.spec rpm -ivh /usr/src/redhat/RPMS/i686/faad2-2.0.1cvs2006124-1.i686.rpm \ faad2-devel-2.0.1cvs2006124-1.i686.rpm +---------------------------+ | To be updated for Centos6 | +---------------------------+ http://www.tima.com/djones/DRM_power.htm This is the main window for receiving HamDRM SSTV images:

+--------------------------------------------------------------------------+ | NOTE: | | I generally recommend all Ham-DRM SSTV users to use Qsstv now as | | it's more stable, has better features, and receives more updates. | | Please skip to that section for all the details. I've left these | | chapters in this doc just for historial reasons. | +--------------------------------------------------------------------------+ RXAMADRM is a program that comes as part of the TRXAMADRM packet that receives digital SSTV images that's compatible with the popular EasyPal SSTV program for Windows. This program uses a version of Digital Radio Mondiale called HamDRM which has a narrower passband version of DRM. There is a sister program called TXAMADRM which is the transmitter companion program and is described in the next section. Today, these two programs come in a common archive but are run separately. There are plans to unify the two programs into one interface but that's going to take a while. It's worth noting that the TRXAMADRM suite of digital SSTV programs is different than say the QSSTV application which supports analog SSTV images. +--------------------------------------------------------------------------+ | NOTE #2: | | RXAMADRM is NOT recommended for use on Centos5. It's dependencies | | break too many things on Centos5 and the older versions of the | | application wasn't stable, reliable, or very useful in it's | | previous versions. More notes are below but I recommend to ONLY | | use TRXAMADRM with Centos6. | +--------------------------------------------------------------------------+ For more information on the history of TRXAMADRM and DRM in general, please read: http://www.pa0mbo.nl/ties/public_html/hamradio/rxamadrm/rxamadrm.pdf +--------------------------------------------------------------------------+ | NOTE #3: | | | | I have been working extensively with Ties Bos, the developer on the | | TRXAMADRM suite. He's very responsive to comments, bug reports, and | | feature requests. The newest versions work MUCH better, they now | | support RS1, RS2, and RS3 file formats, have faster DRM, 4-stage | | syncing, and now have BSR support! | +--------------------------------------------------------------------------+ NOTES missing from the sparse TRXAMADRM documentation: -- - For B/16 QAM, the S/N should be well above 10 dB to produce results - The radio offset should be 350 - The range of D_FS signal should be no more than about 5 ppm (I've seen -50 to 81!) Compiling TRXAMADRM for Centos6: ------------------------------- - Download the current version of the receiver code cd /usr/src/redhat/SOURCES wget http://www.pa0mbo.nl/ties/public_html/hamradio/rxamadrm/trxamadrmv10_16Ubuntu.tgz - Next, you need to install some dependencies (if not already installed): yum install fftw yum install fftw-devel yum install tkimg yum install expect yum install jasper jasper-libs #required for rs2 to JPEG conversion NOTE: Old TRXAMADRM Versions used the old fftw v2 libraries but they are no longer needed. I'm leaving this in here just in case some people cannot use the new fftw v3 versions: DEPRECATED: ----------- yum install http://dl.atrpms.net/el6-x86_64/atrpms/stable/fftw2-double-2.1.5-14.el6.x86_64.rpm yum install http://dl.atrpms.net/el6-x86_64/atrpms/stable/fftw2-double-devel-2.1.5-14.el6.x86_64.rpm - Next, you need to know which sound device number you need to listen to. Run the following command and not down your proper sound card. For me, need to listen to the USB-Audio device (#1): cat /proc/asound/cards -- 0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc0600000 irq 31 1 [default ]: USB-Audio - USB Audio CODEC Burr-Brown from TI USB Audio CODEC at usb-0000:00:1d.0-1.1.1, full -- - Now expand the source code to make these changes: cd /usr/src/redhat/BUILD/ tar xzvf ../../SOURCES/trxamadrmv10_16Ubuntu.tgz - Now make the new RXAMADRM code: cd trxamadrmv10_16/rxamadrmv1_6/ #Ignore any errors here make clean make - Next, since things are still not in a RPM, let's make sure we can write in this directory chown -R $USER . Running RXAMADRM: ----------------- - Go ahead and run the new program by running: ./rxamadrm.tcl - When this program opens up, you should see two windows. One is the main program window and the other is the receive waterfall window Configuring RXAMADRM: -------------------- - Once running, change the "Set Sound Device" in the lower right corner to the proper sound card as found above NOTE: If you receive errors about "wish", the rxamadrm.tcl program might have an incorrectly defined "wish" path. To fix it, do the following: - Run the command: whereis wish wish: /usr/bin/wish /usr/bin/wish8.5 /usr/share/man/man1/wish.1.gz - Edit the rxamadrm.tcl file to reflect the result from the previous command: Change the top line to reflect /usr/bin/wish8.5 - After that, there really isn't anything to configure other than getting the sound levels right. This is now pretty simple with the waterfall window. You want the DRM signal to be a light yellow with much of the background being blue. - Optional: RXAMADRM now has the ability to automatically upload any good images to an FTP site on the Internet. If you want to use this feature, you need to edit the ftp.ini file to reflect a valid FTP server, username, password, and path! You can see the status of your FTP transfers via the lastftp.txt file +------------------------------------------------------------------------+ | DEPRECATED: Trying to use TRXAMADRM on Centos-5: | | | | If you REALLY want to move forward with running this program on | | Centos5, here are my previous notes and, BTW, good luck. You are | | going to break MANY aspects of your Centos 5 install including, Yum, | | etc. | +------------------------------------------------------------------------+ Broken: Legacy Centos5 notes: ----------------------------- As mentioned before, trying to install RXAMADRM / TXAMADRM on Centos5 is not recommended as these programs require a newer version of TCL/TK than what ships in Centos5 (tk-8.4.13-5.el5_1.1). Installing this newer version of TK/TCL breaks the WSJT weak-signal program among others as the two versions of TCL cannot coexist. If you still want to try on Centos5, read on: To backup the below changes (that did NOT work out well.. made a mess of things, do: rpm -e --nodeps tcl tcl-devel tk tk-devel expect tkimg yum install tcl tcl-devel tk tk-devel expect tkimg rpm -ivh --nodeps ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/9/x86_64.newkey/tcl-8.5.2-2.fc9.i386.rpm \ ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/9/i386.newkey/tcl-devel-8.5.2-2.fc9.i386.rpm complains about libtcl8.4.so is needed by (installed) expect-5.43.0-5.1.i386 libtcl8.4.so is needed by (installed) tk-8.4.13-5.el5_1.1.i386 libtcl8.4.so is needed by (installed) tkinter-2.4.3-27.el5.i386 libtcl8.4.so is needed by (installed) python-imaging-tk-1.1.6-4.el5.kb.i386 libtcl8.4.so is needed by (installed) alpine-2.00-2.el5.rf.i386 tcl = 8.4.13 is needed by (installed) tk-8.4.13-5.el5_1.1.i386 tcl-devel = 8.4.13 is needed by (installed) tk-devel-8.4.13-5.el5_1.1.i386 rpm -Uvh --nodeps ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/9/x86_64.newkey/tk-8.5.2-1.fc9.i386.rpm \ ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/updates/9/x86_64.newkey/tk-devel-8.5.2-1.fc9.i386.rpm complains about: libtk8.4.so is needed by (installed) tkinter-2.4.3-27.el5.i386 libtk8.4.so is needed by (installed) python-imaging-tk-1.1.6-4.el5.kb.i386 # Tkimg was already installed for Xastir but since we've changed the # Tcl/Tk system, we have to align other packages to consistent rpm -Uvh ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/9/Everything/i386.newkey/os/Packages/expect-5.43.0-13.fc9.i386.rpm rpm -Uvh --force ftp://ftp.pbone.net/mirror/archive.fedoraproject.org/fedora/linux/releases/9/Everything/i386.newkey/os/Packages/tkimg-1.3-0.9.20071018svn.fc9.i386.rpm - After all that, go ahead and follow the original setup configuration as described at the top of this chapter. 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 transferring pictures so images shouldn't be too big or they will take FOREVER to transfer! To reduce the image size, you need to do some JPG image pre-processing. This is best done with either the ImageMagick or GraphicMagick programs. For now, I'm using use ImageMagick. To aid in finding a small enough size picture to transmit, I wrote the following extra script to simplify the converting to JPEG2000, resizing, and changing of the quality metrics to get files to fit a chosen do-not-exceed size: http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/resize-jpg-jp2-640-variqual.sh Prerequisites: -------------- - As of TXAMADRM 0.6S, the package now requires FFTWv3 and that is described in the RXAMADRM section above as well as in the WSJT, WSPR, and Quisk sections - v0.6S now optionally supports Hamlib for PTT control. If you don't have hamlib installed, you will have to enable VOX on you radio to key up the radio Compiling: ---------- You already compiled the RXAMADRM program in the previous section so lets finish the job with the TXAMADRM side of things: NOTE: I have not RPMed this package yet cd /usr/src/redhat/BUILD/trxamadrmv10_16 cd txamadrmv10 ./configure --enable-alsa --enable-hamlib --disable-jack --disable-portaudio --disable-faad2 --disable-faac #Now run Make (the -j4 makes it compile on four cores thus, compiles faster) make -j4 make #Since things are still not in a RPM, let's make sure we can write in this directory cd ../.. chown -R $USER . Running it: ----------- Before you start the program, we need to figure out what ALSA device to use and optionally, what Hamlib rig you want to use. To find these out, issue the command: cat /proc/asound/cards -- 0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xc0600000 irq 42 1 [Pro ]: USB-Audio - SB X-Fi Surround 5.1 Pro Creative Technology Ltd SB X-Fi Surround 5.1 Pro at usb-0000:00:1d.0-1.2, full 2 [CODEC ]: USB-Audio - USB Audio CODEC Burr-Brown from TI USB Audio CODEC at usb-0000:00:1d.0-1.1.1, full speed -- If you plan on using Hamlib to key up your radio, you need to figure out what is the "number" of your radio (assuming Hamlib is installed and your is supported by it). To get that, do the following. For example, to find the id of a Yaesu FT857, I would do: rigctl -l 2>&1 | grep 857 122 Yaesu FT-857 0.4 Beta Next, let's start the program. Since I haven't RPMed this binary, you need to run it from where we built the program so: cd /usr/src/redhat/BUILD/trxamadrmv10_16/txamadrmv10/linux ./startdrmtx or better yet, since we have the RX program installed too, you can use the included startup script: cd /usr/src/redhat/BUILD/trxamadrmv10_16 ./startdrmtrx.sh Using the combined startup script, the main menu for RXAMADRM should pop up with it's associated waterfall window. An additional window should open up for the TXAMADRM transmit program as well. Configuring TXAMADRM: -------------------- 1. Sound Card: In the bottom bar of the window, find the "Set snd dev" and select proper sound card as found in the above steps to properly transmit the picture. For me, I'm selecting "set dev=2" 2. (Optional): PTT Control via a dedicated serial port or CAT commands: New versions of TRXAMADRM support keying up the radio via a dedicated serial line. In the PTT box in the lower right, you need to select either: CAT or RTS / DTR for dedicated serial port mode Since I'm personally using a dedicated serial port via the US Interface Navigator, I selected "RTS". NOTE: If you incorrectly set this to CAT but enter in PTT serial port name in the "PTT Dev" field and your radio keys up and never un-keys, you need to set this field to RTS or DTS and click on the "Save CFG" button a few times to tell it to unkey. 3. (Optional): PTT Control via a dedicated serial port: If you're keying the radio with a dedicated serial port (I am via the US Interface Navigator), type in the full serial path here. For my Udev aliased serial port (described in a previous section), I put in: /dev/USI_PTT 4. (Optional): PTT Control via Hamlib: If you want to use CAT control to key the radio (can be an issue with some radios like the FT950) and assuming you're using a FT857, and you have the Hamlib ID number from above, go to the lower right corner of the window and select: Set Baud: 4800 Hamlib model # TRX: 122 NOTE: Different radios support different serial port speeds. The FT857 only supports 4800 but the FT950 supports 38400. 5. DRM modes: Different DRM parameters are set depending on the band, the band conditions, etc. For me, I usually use TXAMADRM in an unusual fashion. Specifically, we have a somewhat distant 2m repeater that we have a SSTV net every Friday! For me, I need to set it to the following but you might have to enable much more error correction, etc. if you're using HF: Mode : B QAM : 16 Prot : Norm Intlv : Long Bandwidth: 2.5 6. User information: In the upper left column, type in: Callsign: <Put in your callsign> Instances: Not sure what this is for 7. Next, skip down a bit to the "None, RS1, RS2, etc. section and set the RS setting that's proper for you. Higher the RS, the higher the error correction as needed with poorer HF conditions but slower the image transfer 8. Next, you can optionally send text in the waterfall that's viewable by RXAMADRM, EasyPal, etc. Click on the lower left box labeled WFALTXT and type in your callsign in the pop-up box Sound Card levels: ------------------ - I also using my FT857 with my US Navigator and the levels were WAY too high. I had to change the KDE mixer level for the output of the Navigator to 6 (out of 11 ticks) and roll back the Navigator's "RF output" knob to 85%. At that point, everyone was very happy with the signal. Old notes about upgrading Centos6's ImageMagik- to be deleted ------------------------------------------------------------- Unfortunately it seems the stock version of ImageMagick that comes with Centos6 is very old: - ImageMagick-6.5.4.7-5.el6.x86_64 (surprise, surprise.. current versions is 6.7.6) So, I recommend you get a more modern version but: NOTE: The "Centos" binaries posted on the official ImageMagick mirrors are for some reason NOT COMPATIBLE with Centos6. They don't state a Centos version but it can't be for Centos6. So, you need to compile your own version. #Dependencies: yum install OpenEXR OpenEXR-devel giflib-devel djvulibre-devel libwmf-devel cd /usr/src/redhat/SRPMS/ wget -O ImageMagick.src.rpm http://imagemagick.mirrorcatalogs.com/linux/SRPMS/ImageMagick.src.rpm rpm -ivh ImageMagick.src.rpm cd ../SPECS/ rpmbuild -bb --target=x86_64 ImageMagick.spec cd /usr/src/redhat/RPMS/x86_64/ rpm -ivh ImageMagick-6.7.6-8.x86_64.rpm ImageMagick-devel-6.7.6-8.x86_64.rpm \ ImageMagick-doc-6.7.6-8.x86_64.rpm kipi-plugins kipi-plugins-libs yum install http://imagemagick.mirrorcatalogs.com/linux/CentOS/x86_64/ImageMagick-6.7.6-9.x86_64.rpm \ http://imagemagick.mirrorcatalogs.com/linux/CentOS/x86_64/ImageMagick-devel-6.7.6-9.x86_64.rpm \ http://imagemagick.mirrorcatalogs.com/linux/CentOS/x86_64/ImageMagick-doc-6.7.6-9.x86_64.rpm +---------------------------+ | 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 To run Windows programs under Linux, you have one of two options: - WINE: Run the Windows Compatibility Layer - Emulation: Load a real copy of Windows under a virtual machine and run the program there Wine has come a LONG way since it first started many years ago and it's both FAST and it's compatibility is very good. It's not perfect though so sometimes you need to be patient with it. So why do I want to run Windows programs on my Linux box? The Outpost Packet Radio messaging program. More about that in the next section. Installing Wine: ---------------- To install Wine on Centos, you need to enable the RPM Forge repositories to get the newest version of Wine. This is covered in Chapter 1 of this document under the Third Party Repos section. To start off, let's install the newest version of wine. Note to Centos 5 Users: ----------------------- - It seems v1.2.2 of Wine doesn't work well in controlling serials ports. It's recommend to install v1.4 or newer Centos v6 and v5 users: ----------------------- yum install wine Centos-6: this will also install the following: ----------------------------------------------- wine.x86_64 - 1.4.1-1.el6 - epel alsa-plugins-pulseaudio.i686 - 1.0.21-3.el6 - base cyrus-sasl-lib.i686 - 2.1.23-13.el6_3.1 - base flac.i686 - 1.2.1-6.1.el6 - base libasyncns.i686 - 0.8-1.1.el6 - base libexif.i686 - 0.6.21-5.el6_3 - base libgphoto2.i686 - 2.4.7-4.el6 - base libsndfile.i686 - 1.0.20-5.el6 - base libtool-ltdl.i686 - 2.2.6-15.5.el6 - base libusb.i686 - 0.1.12-23.el6 - base nss-mdns.i686 - 0.10-8.el6 - epel nss-mdns.x86_64 - 0.10-8.el6 - epel openal-soft.i686 - 1.12.854-1.el6 - epel openal-soft.x86_64 - 1.12.854-1.el6 - epel openldap.i686 - 2.4.23-32.el6_4.1 - updates pulseaudio-libs.i686 - 0.9.21-14.el6_3 - base tcp_wrappers-libs.i686 - 7.6-57.el6 - base wine-alsa.i686 - 1.4.1-1.el6 - epel wine-alsa.x86_64 - 1.4.1-1.el6 - epel wine-capi.i686 - 1.4.1-1.el6 - epel wine-capi.x86_64 - 1.4.1-1.el6 - epel wine-cms.i686 - 1.4.1-1.el6 - epel wine-cms.x86_64 - 1.4.1-1.el6 - epel wine-common.noarch - 1.4.1-1.el6 - epel wine-core.i686 - 1.4.1-1.el6 - epel wine-core.x86_64 - 1.4.1-1.el6 - epel wine-courier-fonts.noarch - 1.4.1-1.el6 - epel wine-desktop.noarch - 1.4.1-1.el6 - epel wine-fonts.noarch - 1.4.1-1.el6 - epel wine-ldap.i686 - 1.4.1-1.el6 - epel wine-ldap.x86_64 - 1.4.1-1.el6 - epel wine-marlett-fonts.noarch - 1.4.1-1.el6 - epel wine-ms-sans-serif-fonts.noarch - 1.4.1-1.el6 - epel wine-openal.i686 - 1.4.1-1.el6 - epel wine-openal.x86_64 - 1.4.1-1.el6 - epel wine-pulseaudio.i686 - 1.4.1-1.el6 - epel wine-pulseaudio.x86_64 - 1.4.1-1.el6 - epel wine-small-fonts.noarch - 1.4.1-1.el6 - epel wine-symbol-fonts.noarch - 1.4.1-1.el6 - epel wine-system-fonts.noarch - 1.4.1-1.el6 - epel wine-tahoma-fonts.noarch - 1.4.1-1.el6 - epel wine-twain.i686 - 1.4.1-1.el6 - epel wine-twain.x86_64 - 1.4.1-1.el6 - epel wine-wow.x86_64 - 1.4.1-1.el6 - epel Centos-5: this will also install the following: ----------------------------------------------- wine - 1.3.12-1.el5.rft - rpmforge-testing libtool-ltdl - 1.5.22-7.el5_4 - base mpg123 - 1.12.5-2.el5.rf - rpmforge wine-capi - 1.3.12-1.el5.rft - rpmforge-testing wine-cms - 1.3.12-1.el5.rft - rpmforge-testing wine-core - 1.3.12-1.el5.rft - rpmforge-testing wine-esd - 1.3.12-1.el5.rft - rpmforge-testing wine-gecko - 1.1.0-1.nodist.rft - rpmforge-testing wine-jack - 1.3.12-1.el5.rft - rpmforge-testing wine-ldap - 1.3.12-1.el5.rft - rpmforge-testing wine-nas - 1.3.12-1.el5.rft - rpmforge-testing wine-twain - 1.3.12-1.el5.rft - rpmforge-testing In my local ARES/RACES City affiliated and the county group both use the graphical Packet Radio messaging application for Microsoft Windows called "Outpost" written by Jim Oberhofer, KN6PE. This program looks similar to older versions of the Microsoft Outlook email program which gives an easy way for users to poll many different types of mailboxes across a lot of different local and remote hardware. You can find it's homepage available at: http://www.outpostpm.org/ Here is an example of the main Outpost window with various messages in the inbox


In addition to Outpost working phyical TNCs in KISS mode, it's also unique in that it can use TNCs while in command mode. It also supports working with remote TNCs via the AGW API access. For this document, I will document how things work using a Kenwood D710 TNC in COMMAND mode but I also commonly use it with LDSPED's AGW support. NOTE: I'd recommend to use Outpost with AGW support over serial ports as it's more reliable that way. 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 "aliased" UDEV naming so my serial port will always come up as USI_SER: mkdir -p /.wine/dosdevices/ ln -s /dev/USI_SER /.wine/dosdevices/com1 Centos 5 only - Older Wine Serial port issue workaround: -------------------------------------------------------- With older versions of Wine such as v1.2, you needed to use a work-around to fix a long-standing serial port issue with wine. Do the following: cd /usr/src/archive/Outpost wget http://static.danplanet.com/preserve/serproxy.c gcc -o serproxy serproxy.c cp serproxy /usr/local/sbin Now go ahead and run the proxy: /usr/local/sbin/serproxy /dev/ttyS0 Ok, let's download and install Outpost: --------------------------------------- Download the newest version of Outpost. For my specific ARES/RACES group, we have a unique version of Outpost that comes with a set of PACFORMS HTML forms included. Few points to remember when installing Outpost with Wine: 1. Don't run the "wine" command as the root user 2. Our custom version is here or you can download the main Outpost release as well: http://www.scc-ares-races.org/packet/client-software.html In this example, I will install Outpost v320c118 with PacRelease v4.4 intended for Santa Clara County ARES/RACES members. Previously, I installed Outpost v320c103 with PacRelease v43, and previous to that v48/Pacfords 3.8, and version v21 before that. 3. Get the code: cd /tmp wget http://www.scc-ares-races.org/packet/installer/sccsetup139pub.exe NOTE: It's important that when you run Wine, you do NOT run it while being root! #Install or Upgrade an older version the Outpost program wine sccsetup139pub.exe - Follow all the prompts as instructed - All files will be installed into $USER/.wine/Application Data/SCCo Packet - Accept ALL of the installer's defaults #Notes on the installation: Outpost 3.2 under Wine v1.8.6 notes: ------------------------------------ - Everything seems to work fine with LDsped's AGWPE interface and without the serproxy work around #Previous Outpost installation notes: Centos6 - I did see various warnings and errors in the terminal window when Wine was installing Outpost 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, if this is your first time installing Outpost on your system, 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 following: Tools --> Message Settings --> Edit Subject Line Identifier Values Next Message Number: xxx City: City of Santa Clara State: CA Tactical ID (3 char): ZHD - Goto Forms --> [pick a form] - A new PacForms window should automatically open up such as: Here is an example of the main PacFORMS window

- Fill out the form as instructed - Once done, click on the bottom center "SUBMIT the form to Outpost". You should then see a new web page stating: -- Your PacFORMS submission was successful! Press the BACK button to return to your FORM. -- - Back in Outpostm you should see the ASCII representation of that form waiting to be sent. Click on the "To" field to send it to the proper destination. NOTE: 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 -- Chirp is is a graphical Python-based HAM radio memory programming tool that supports a multitude of Icom, Yaesu, and Kenwood radios HTs, mobiles, and now HF radios. To be clear, this tool copies a source radio's memory presents and stores them in a platform agnostic way that then allows the user to uploaded these settings to other, non-similar radios thus allowing you to synchronize all the memories for repeaters, ec. Chirp does NOT record specific radio settings like DSP settings, CW key modes, APRS settings, etc. This is the main window that shows what was downloaded which you can directly edit, etc:

For my specific shack, Chirp supports my Kenwood TH-F6A HT and D710 mobile as well as my Yaesu VX5 HT and FT857 HF/VHF/UHF rig. It even supports my Icom IC-80AD Dstar HT! The RPM requirements for this application is Python, GTK, and PyGTK. Centos already comes with most of the dependencies by default (but not everything): Centos6: python-2.6.6 gtk2-2.18.9 pygtk2-2.16.0 Centos5: python-2.4.3 gtk2-2.10.4 pygtk2-2.10.1 Chirp also needs the following other packages and manual installs: Centos6: yum install libxml2-python yum install python-argparse.noarch #We also need to install one more package manually: cd /tmp wget wget ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home:/uibmz:/unmaintained/CentOS_CentOS-6/noarch/python-serial-2.4-6.1.noarch.rpm sudo rpm -ivh python-serial-2.4-6.1.noarch.rpm Ok.. You should be good now +--------------------------------------------------------------------------------+ | Legacy: | | | | Older versions of Chirp (say Nov 2017 and older) used PySerial system but | | Chirp now uses the Python-Serial module instead. I'm leaving this older | | details in here for historical reasons only. Most readers should ignore | | this section and use the above Python-serial instead. | +--------------------------------------------------------------------------------+ One more RPM that we have to build ourselves: cd /usr/src/archive/Chirp #Centos6 #For 64bit systems rpmbuild -bb --target=x86_64 pyserial.spec rpm -ivh /usr/src/redhat/RPMS/noarch/pyserial-2.2-6.el6.noarch.rpm #For 32bit systems rpmbuild -bb --target=i686 pyserial.spec rpm -ivh /usr/src/redhat/RPMS/noarch/pyserial-2.2-6.el6.noarch.rpm #Centos5 wget -O pyserial-2.2-6.el5.test.src.rpm ftp://ftp.pbone.net/mirror/rpms.arrfab.net/centos/testing/i386/pyserial/pyserial-2.2-6.el5.test.src.rpm rpm -ivh pyserial-2.2-6.el5.test.src.rpm cd /usr/src/redhat/SPECS Ok... now that all the dependencies are install, the current released and beta versions of Chirp code can be found at: http://chirp.danplanet.com/ To get the newest bleeding edge code out of the SVN depot, goto: http://d-rats.com/hg/hgwebdir.cgi/chirp.hg/archive/tip.tar.gz or http://trac.chirp.danplanet.com/chirp_daily/ Though this tool runs via Python (non-compiled code) and thus doesn't need to be installed, an RPM is available to make things clean: yum install http://d-rats.com/yum/f11/d-rats-repo-0.1.2-1.fc11.noarch.rpm yum install chirp Once the code is installed, simply run: ./chirpw As a new HAM, most people just start loading up various frequencies into their single radio and don't think more about it. As the bug spreads and they buy more radios, a problem starts to occur: - Different radios offer different numbers of memories. For example, here are examples of different radios out there and the number of memories they support: Kenwood Kenwood Yaesu Yaesu Icom baofeng baofeng Wouxun D710 TH-F6A FT857D VX5R IC80AD uv3r uv5r UV6D ------- ------ ------ ----- ------ ----- ----- ------ memories : 999 400 200 220 1000 100 128 199 For my HW, the lowest common denominator is 200 memories - Different radios offer different frequency bands: 6m, 2m, 1.25cm, 70cm, 23cm, etc To accommodate various radios, I came up with the follow plan and maybe this would be helpful to you so that the same memory number on ANY of your radios will be consistent: Memory 1-75 : reserved for 2m (common to all radios) - 75 down is where I put the simplex frequencies Memory 75-89: reserved for 1.25cm (F6A) - 89 down is where I put the simplex frequencies Memory 90-99: reserved for 6m (VX5R) - 99 down is where I put the simplex frequencies Memory 100-175: reserved for 70cm (common to all radios) - 175 down is where I put the simplex frequencies Memory 176-200: reserved for Police/Fire/etc monitoring (for radios that support wide-band receive) +---------------------------+ | To be updated for Centos6 | +---------------------------+ WXtoIMG is a Multi-platform APT and WeFAX satellite decoder. Grab the binary at: http://www.wxtoimg.com/downloads/ rpm -Uvh /tmp/wxtoimg-2.10.11.i386.rpm To run it: /usr/local/bin/wxtoimg Once the Xwindows box comes up, you have populate in the Lat/Long. It has a course look up engine and I was able to put in: San Jose USA but it didn't find my smaller, near-by city. Set the radio to 137.10, 137.40, 137.50, 137.62, or 137.9125 FM (50kHz or NFM) Winlink 2000 is a distributed email system sponsored by the ARRL that is fundamentally tied to the Internet and offers multiple methods of RF-based access for Amateur Radio operators. Some of the access methods include: - HF data via WINMORE software-based TNC (Windows .net only as of March, 2011) - HF data via Pactor 2/3 (SCS proprietary TNCs) - AX.25 packet (mostly 1200b) - packet-based APRS messaging - TELNET over the Internet - Webmail over the Internet There are several programs out there to create an easy to used interface to Winlink: - Paclink-Unix - a translational system that runs on Linux and provides any POP3 email client running on your network to to interface to Winlink2k. This supports both VHF packet and HF Pactor links. Very powerful! https://github.com/nwdigitalradio/paclink-unix - Airmail is a Windows-only program that's similar to Outpost that is it's own email reader and supports Winlink2k - Outpost for Windows also supports Winlink 2000 interfacing and it works under WINE for Linux - JNOS2 BBS system has B2F message compatibility with Winlink2k. It's not a client per se but a relaying system - BPQ32 BBS system for Windows and Linux has support for VHF packet and HF Pactor Winlink support - Linux-RMS-Gateway - Older package (might not be maintained anymore) http://download.prgm.org/dl5di-soft/rms-gateway/ which replaced "Telpac-node Linux" http://www.prgm.org/projekte/telpac-node/index.html This is a Linux solution to run your own RMS gateway on Packet radio that interfaces to Winlink CMS messaging servers on the Internet Specific setup details might be added at a later time but until then, please see the following URL for setting up Paclink-Unix on Linux with Postfix: http://bazaudi.com/plu/doku.php?id=plu:before_you_start Quick and dirty notes on getting started with Winlink: 1. To create a Winlink account, you MUST interface to an existing RMS station on the amateur bands (HF based WINMORE, Pactor, or a VHF/UHF packet connection to an RMS station. NOTE: APRS does not count and cannot create or renew an existing account Once you connect to a RMS Packet station, you are automatically registered for 400 days. Just login once every 90 days to keep your account active. If your account goes inactive after 400 days, any Winlink email to you will bounce. Just login again via RF as mentioned above to reactivate it. NOTE: the use of the webmail system does NOT reset this timer. Only the use of an RF connection or Internet-based TELNET to a CMS system will work For me, I connect to KE6AFE-10 via LPRC2 on 144.910 1200 BAUD packet. You can find local stations to you via: VHF : http://www.winlink.org/RMSPacketPositions HF : http://www.winlink.org/RMSHFStatus APRS: see below Locating Winlink systems via APRS --------------------------------- If you have an APRS setup, you can find the closest Winlink RMS server to your current QTH, read your Winlink email via APRS messages, etc! Full details: http://www.winlink.org/aprslink To find the closest Winlink RMS stations: a. Send a standard APRS beacon to let the APRS world know your location b. APRS TO : WLNK-1 APRS MSG: G# Where # is the number of machines you want returned 2. Connect to an active Winlink system: 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 - 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: 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 <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 <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= <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> - 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 Winlink supports other advanced commands via APRS. Please see the following documentation for now: http://www.josephoregonweather.com/HAM/KB7DZR%20APRS%20COMMANDS.pdf
Pat is both a GUI (presented as a web page as shown above) or CLI based Winlink messaging client. It supports multiple ways to connect to remote Winlink systems be it native Linux AX.25, ARDOP, Winmor (via WINE), external hardware TNCs supporting Pactor or AX.25, and Internet based connections. The program is multi-platform as it's written in the Go language (golang) which also supports Radio CAT control via Hamlib to QSY the radio to the ideal HAM band for the time of day. You can learn more about PAT here: http://getpat.io/ To get started, we first need to install the Go language. Some versions are currently available for Centos6 or newer distros (Centos5 is specifically NOT supported) via the EPEL repo which was already enabled via a previous section in this document. The version of "golang" for Centos6 in EPEL is currently at v1.9.4 as of 4/19/18 which is pretty up to date version. This has not always been the case as just a few months ago, it was only at v1.6 which was already EOL! If you want a bleeding edge version of Go (currently at v1.10 as of 4/21/18), you can consider getting packages from: http://go-repo.io/ This is not required for running PAT on Centos6 so let's get started! Let's install Go from EPEL by running the command: sudo yum install golang golang-bin golang-src Now in an unusual step for this doc, I recommend you TEST your Go installation via the official Go method because Go is a different kind of system: Run these commands in a shell window as a non-root user: #Create a download and build area in your current home directory export GOPATH=$HOME/work mkdir -p $GOPATH/src/github.com/user/hello Create the following simple "Hello World" Go program: # vim $GOPATH/src/github.com/user/hello/hello.go -- package main import "fmt" func main() { fmt.Printf("hello, world\n") } -- Ok, now compile your Go program: go install github.com/user/hello If all goes well, you'll just be dropped back to the command line without any output what so ever. That resulting "hello, world" program is 2.35MB file. Finally, run your new Go program: $GOPATH/bin/hello You should see: hello, world +----------------------------------------------------+ | WIP: Not fully packaged yet but fully operational | +----------------------------------------------------+ Ok, now to download the PAT source code and install Pat: Interm-testing (not packaged): #create the base environment - resulting directory will consume about 105MB export GOPATH=$HOME/work git clone https://github.com/la5nta/pat $GOPATH/src/github.com/la5nta/pat cd $GOPATH/src/github.com/la5nta/pat #Prepare the code and enable AX.25 support git submodule update --init --recursive go get -tags 'libax25 libhamlib' #Finally, compile PAT TAGS="libax25 libhamlib" ./make.bash #That should have worked though it throws some warnings that are OK to ignore: -- WARNING: No static libax25 library available. Linking against shared library instead. To fix this issue, set CGO_LDFLAGS to the full path of libax25.a, or run 'make.bash libax25' to download and compile libax25-0.0.12-rc4 in .build/ Updating git submodules... Running tests... ? github.com/la5nta/pat [no test files] ? github.com/la5nta/pat/cfg [no test files] ? github.com/la5nta/pat/internal/cmsapi [no test files] ? github.com/la5nta/pat/internal/gpsd [no test files] Building Pat v0.6.1... Enjoy! -- WIP to package into an RPM: cd /usr/src/redhat/SOURCES # As of 4/21/18, Pat is at version 0.6.1 wget https://github.com/la5nta/pat/archive/v0.6.1.tar.gz #Let's align the archive filename to be RPM packaging friendly mv v0.6.1.tar.gz pat-0.6.1.tar.gz #Now let's get a spec file to package Pat cd /usr/src/redhat/SPECS wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/pat.spec Now we need to configure PAT with your specific details. Run the following command: ./pat configure There are a few assumptions here in configuring PAT: 1. You already have a Winlink account and password. If you don't, please read the intro to Winlink section in this doc of how to get started 2. OPTIONAL: You already have AX.25 configured on your Linux system per this document. You'll need to configure it to match your AX25 device name as configured in /etc/ax25/axports 3. OPTIONAL: You have ARDOP installed and running per the previous ARDOP section Edit the following entries to match your specific information ESPECIALLY your Winlink password: -- "mycall": "KI6ZHD", "secure_login_password": "yourwinlinkpassword", "locator": "CM97ai", "ax25": { "port": "d710", "ardop": { "arq_bandwidth": { "Max": 2000 "cwid_enabled": false -- Thoughts on radio CAT control: ------------------------------ You can also configure PAT to support radio CAT control but I haven't documented here. If you want to enable this, you need to be VERY careful using automation with HF radios: - Unless you can completely automate the monitoring of incoming and outgoing sound card levels AND radio RF levels, you can saturate the incoming signals to the point they cannot be decoded. Worse, you can create a high ALC situation on transmit which would make your signal distorted and splatter all over the band - Unless you have low SWR on your antenna for any intended frequencies, you could damage your radio - Unless your antenna tuner can match all intended frequencies, you can create a high SWR situation and possibly damage your radio - Unless you're careful with your radio's RF power, overly long transmissions can overheat and damage your radio (an FT950 should not use more than 50% of it's max power - 50 watts) - With PAT v0.6.1, it only supports frequency control. It doesn't support changing other key parameters to ensure you're 100% ready to go such as mode (USB), antenna tune, etc Once you save the file, that's it and you should be ready to run PAT. To get started, let's give it a test over the Internet. To do so, run the following command and you should see something like the following ./pat connect telnet -- 2018/04/21 10:07:47 Connecting to WL2K (telnet)... 2018/04/21 10:07:47 Connected to 52.54.153.253:8772 (tcp) [WL2K-5.0-B2FWIHJM$] ;PQ: 40312364 CMS> >FF ;PM: KI6ZHD UMIDPSMT62YL 111 Test #2 FC EM UMIDPSMT62YL 129 111 0 F> 59 1 proposal(s) received Accepting UMIDPSMT62YL Receiving [Test #2] [offset 0] Test #2: 100% >FF FQ 2018/04/21 10:07:48 Disconnected. -- Success! You just made a successful connection to the Internet-facing Winlink system. To read a message, you would do: ./pat read -- 0:in 1:out 2:sent 3:archive Choose mailbox [n]: 0 -- Here you have a choice of what folder to enter. I'm typing in "0" to vierw the INbox. I then see: -- ----- ------- ----------------------------------------------------------- -------- ------------------------------- ------------- i Flags Subject From Date To ----- ------- ----------------------------------------------------------- -------- ------------------------------- ------------- 0 //WL2K Thank you for checking in to the NORCAL_WINLINKnet KF6OBI 2018-04-18 17:48:00 -0700 PDT KI6ZHD 1 //WL2K NORCAL_WINLINKnet Weekly report KF6OBI 2018-04-20 07:18:00 -0700 PDT KE6AFE, ... 2 N Test #2 KI6ZHD 2018-04-20 21:14:00 -0700 PDT KI6ZHD ----- ------- ----------------------------------------------------------- -------- ------------------------------- ------------- -- I then want to read message #2 as it's the new message mentioned above: -- Choose message [n]: 2 ======================================== MID: UMIDPSMT62YL Date: 2018-04-20 21:14:00 -0700 PDT From: KI6ZHD To: KI6ZHD Subject: Test #2 This is test #2 Attachments: ======================================== -- At this point, you've read the message and PAT will prompt you want to do next. This could be to mark the message as READ or reply to it: -- Mark as read? [Y/n]: Reply (ctrl+c to quit) [y/N]: -- +-------------------------------------------------------------------------------------------+ | NOTE: As of PAT v0.6.1, there is no way to delete messages via the simple CLI but you | | can delete them via the HTTP/web interface (more on that in a moment). Until | | then, you can manually delete messages like this (make the required substitutions): | | | | ls -la $HOME/.wl2k/mailbox/KI6ZHD/in/ | | -- | | total 24 | | drwxrwxr-x 2 dranch dranch 4096 Apr 21 10:07 . | | drwxrwxr-x 6 dranch dranch 4096 Apr 19 22:01 .. | | -rw-rw-r-- 1 dranch dranch 5516 Apr 20 15:47 74OCM2JGFDEC.b2f | | -rw-rw-r-- 1 dranch dranch 427 Apr 20 15:42 S8376TPX0OWJ.b2f | | -rw-rw-r-- 1 dranch dranch 196 Apr 21 10:10 UMIDPSMT62YL.b2f | | -- | | | | As you can see in the original reading of message #2, it had an identifier of | | "UMIDPSMT62YL" and it's right there in this directly listing. To remove the | | message, I would simply do: | | | | rm $HOME/.wl2k/mailbox/KI6ZHD/in/UMIDPSMT62YL.b2f | +-------------------------------------------------------------------------------------------+ To exit PAT, you would just keep hitting enter to accept the default prompts: -- Choose message [n]: 0:in 1:out 2:sent 3:archive Choose mailbox [n]: $ -- Sending messages is basically the same thing as reading them. Here, I'm sending another message to myself: ./pat compose -- From [KI6ZHD]: To: KI6ZHD Cc: P2P only [y/N]: N Subject: Test #3 Press ENTER to start composing the message body. [default editor opens up (vim in my case)] to let you write your message. Edit the editor when done] Attachment [empty when done]: MID: KXKTW2HJKVYA Date: 2018-04-21 10:30:00 -0700 PDT From: KI6ZHD To: KI6ZHD Subject: Test #3 this is test #3 Attachments: Message posted -- Ok, all done.. but it didn't send it. That's because PAT is a bulk transfer tool. You can write a whole bunch of messages offline and then send them all at once. To send you message, you'd do another CONNECT just like what you did at the beginning of this section: ./pat connect telnet We now have a working PAT setup using the Internet but that's probably NOT what you really intended to to do. I bet you want to use it over the radio be it AX.25 packet, ARDOP, etc. Let's try via Linux's native AX25 support. NOTE: This section assumes you have a fully operational AX25 setup per the previous sections in this document Ok, assuming your packet setup is ready and working, let's see what packet stations are around you. A slick way to find out is to use grid squares. Per my configuration, I'm in the CM97 grid square. I can use PAT to show me who is near me. This is NOT a perfect way to do it considering the various elements such as local digipeaters, topography, propogration, time of day, etc but you can make things as loose or tight as you wish. I'm matching on packet stations only near "CM97": ./pat rmslist | grep -i "\[CM97" | grep -i packet -- K2RDX-10 [CM97AH] 5 180 Packet 1200 145.630.00 MHz 145.630.00 MHz packet:///K2RDX-10?freq=145630 K6IXA-10 [CM97QI] 118 90 Packet 1200 144.910.00 MHz 144.910.00 MHz packet:///K6IXA-10?freq=144910 K6IXA-10 [CM97QI] 118 90 Packet 9600 433.510.00 MHz 433.510.00 MHz packet:///K6IXA-10?freq=433510 KE6AFE-10 [CM97CC] 31 152 Packet 1200 145.630.00 MHz 145.630.00 MHz packet:///KE6AFE-10?freq=145630 KF6IDK-10 [CM97SH] 133 92 Packet 1200 144.910.00 MHz 144.910.00 MHz packet:///KF6IDK-10?freq=144910 W6TUW-10 [CM97AA] 37 180 Packet 1200 144.910.00 MHz 144.910.00 MHz packet:///W6TUW-10?freq=144910 -- K2RDX-10 is right near me so I QSY my FM radio to 145.630Mhz and issue the following command using my "d710" interface as defined in /etc/ax25/axports: ./pat connect ax25://d710/K2RDX-10 -- 2018/04/21 10:56:53 Connecting to K2RDX-10 (ax25)... 2018/04/21 10:56:54 Connected to K2RDX-10 (AX.25) [WL2K-5.0-B2FWIHJM$] ;PQ: 96625531 CMS via K2RDX > >FF FQ 2018/04/21 10:56:58 Disconnected. -- Cool.. it just works and now you can read your messages offline as previously shown in this section. We now have a working PAT setup using the Internet but that's probably NOT what you want to do. You probably want to use it over the radio be it AX.25 packet, ARDOP, etc. Let's try ARDOP first. To get started, make sure the ARDOP modem is running per the previous program using: /usr/local/bin/start-ardop.sh Assuming your HF radio is on, tuned to the right frequency, matched for your antenna, has the right soundcard and RF power levels for zero ALC, you should be ready! The next question is WHO do you try connecting to. A slick way to find out is to use grid squares. Per my configuration, I'm in the CM97 grid square. I can use PAT to show me who is near me. This is NOT a perfect way to do it considering the various elements of propogration, time of day, etc so I intentionally keep the search to be a little broad. I'm matching only on "CM9": ./pat rmslist | grep -i "\[CM9" | grep ardop -- K2RDX [CM97AH] 5 180 ARDOP 500 7.095.00 MHz 7.096.50 MHz ardop:///K2RDX?freq=7095 K2RDX [CM97AH] 5 180 ARDOP 2000 7.101.00 MHz 7.102.50 MHz ardop:///K2RDX?freq=7101 K2RDX [CM97AH] 5 180 ARDOP 2000 10.145.50 MHz 10.147.00 MHz ardop:///K2RDX?freq=10145.5 K2RDX [CM97AH] 5 180 ARDOP 2000 14.106.00 MHz 14.107.50 MHz ardop:///K2RDX?freq=14106 -- Cool! There is a station right next to me.. John K2RDX's station. I'm going to connect to one of his 40m stations so I QSY my radio to 7.101Mhz USB DIAL which is effectively 7.1025Mhz in RF spectrum and give it a try: +--------------------------------------------------------------+ | NOTE: The use of PAT can work while ARIM is running but not | | connected or beaconing | +--------------------------------------------------------------+ Ok, let's give it a try. Looking above, PAT has shown us the syntax how to connect to the listed stations so I would simply do: ./pat connect ardop:///K2RDX -- 2018/04/21 10:51:18 ARDOP TNC (ARDOP TNC_1.0.2.5l-BPQ) initialized 2018/04/21 10:51:18 Connecting to K2RDX (ardop)... 2018/04/21 10:51:26 Connected to K2RDX (ardop) RMS Trimode 1.3.19.0 KI6ZHD has 112 minutes remaining with K2RDX {SFI = 073 on 2018-04-21 16:00 UTC} [WL2K-5.0-B2FWIHJM$] ;PQ: 47077525 CMS via K2RDX > >FF ;PM: KI6ZHD KXKTW2HJKVYA 112 Test #3 FC EM KXKTW2HJKVYA 129 112 0 F> 40 1 proposal(s) received Accepting KXKTW2HJKVYA Receiving [Test #3] [offset 0] Test #3: 100% >FF FQ 2018/04/21 10:53:31 Disconnected. -- Cool.. it just works and now you can read your messages offline as previously shown in this section. Btw, PAT can do a lot of other things. To get a hint of what else the CLI offers, simply run: ./pat -- Pat is a client for the Winlink 2000 Network. Usage: ./pat [options] command [arguments] Commands: connect Connect to a remote station. interactive Run interactive mode. http Run http server for web UI. compose Compose a new message. read Read messages. position Post a position report (GPSd or manual entry). extract Extract attachments from a message file. rmslist Print/search in list of RMS nodes. riglist Print/search a list of rigcontrol supported transceivers. configure Open configuration file for editing. version Print the application version help Print detailed help for a given command. Options: --config string Path to config file (default "/home/dranch/.wl2k/config.json") --event-log string Path to event log file. (default "/home/dranch/.wl2k/eventlog.json") --ignore-busy Don't wait for clear channel before connecting to a node. -l, --listen string Comma-separated list of methods to listen on (e.g. winmor,ardop,telnet,ax25). --log string Path to log file. The file is truncated on each startup. (default "/home/dranch/.wl2k/pat.log") --mbox string Path to mailbox directory (default "/home/dranch/.wl2k/mailbox") --mycall string Your callsign (winlink user). --radio-only Radio Only mode (Winlink Hybrid RMS only). -r, --robust Use robust modes only. (Useful to improve s/n-ratio at remote winmor station) -s, --send-only Download inbound messages later, send only. -- This is kinda fun to post my position in Decimal degrees: ./pat position --latlon 37.3435,-121.9999 -- Message posted -- #Now send the position report via say ARDOP: ./pat connect ardop:///K2RDX # You can view your position reports via an Internet web browser at: https://www.winlink.org/userPositions Some people prefer CLIs (like me) but many people prefer GUIs and this is where PAT shines. It supports BOTH. To use PAT's gui, you simply start it's web interface at a terminal prompt: ./pat http -- 2018/04/21 11:12:40 Starting HTTP service (localhost:8080).. -- Now, now on the same computer, open up a web browser and point it to the URL: http://127.0.0.1:8080
Go ahead and play with the web interface but basically everything you've done here in the CLI is applied to the GUI. Enjoy! Gpredict is a very modern, pretty, and easy to use satellite orbit prediction tool for Linux. It even supports AzEl rotator control and Doppler shift controls for Yaesu FT817-857/897 radios.

To install it, download the RPM from the FedoraCore repo: NOTE: ----- Centos6: The only version of Gpredict that is compatible with Centos6 is version 1.3. Later version of Gpredict 1.4git require glib 2.32 for g_mutex support but Centos6 only has glib2.28. I've confirmed this is a REQUIREMENT for all newer versions of Gpredict TBD: Centos6 I'm going to try bulding a 1.4Git version from the last version that didn't require the g_mutex call: commit ce3651e029e5f481f51bc1864ceae1bad427e5a6 Author: Alexandru Csete Date: Thu Jul 4 13:58:29 2013 +0200 Replace obsolete GStaticMutex with static GMutex. I'll report later on my findings Centos5: the only version of Gpredict that is compatible with Centos5 is version 0.9. The much more modern Gpredict 1.3 and 1.2 are not compatible with Centos5 due to wanting much newer versions of various libraries such as: -- wants 'gtk+-2.18.0' but Centos5 will only have 2.10 wants 'glib-2.22.0' but Centos5 only has GLib 2.12.3 wants 'gthread-2.22.0' but Centos5 only has GThread 2.12.3 wants 'libcurl >= 7.19.0' but Centos5 only has libcurl 7.15.5 goocanvas requires gtk2-devel-2.12 but Centos5 only supports 2.10 -- If you want to install Gpredict v0.9 for Centos5, skip down to that section below TBD: Centos6 I'm going to try bulding a 1.4Git version from the last version that -------- Centos6: -------- #First, some dependencies: yum install goocanvas goocanvas-devel #Ok, lets get Gpredict and install it cd /usr/src/redhat/SOURCES # For reference to get newer versions # http://koji.fedoraproject.org/koji/packageinfo?packageID=1958 wget http://kojipkgs.fedoraproject.org//packages/gpredict/1.3/7.fc19/src/gpredict-1.3-7.fc19.src.rpm #Ok, let's compile it: cd /usr/src/redhat/SPECS #For 64bit systems rpmbuild -bb --target=x86_64 gpredict.spec rpm -Uvh /usr/src/redhat/RPMS/x86_64/gpredict-1.3-7.el6.x86_64.rpm # Skip past, the Centos5 compile section on how to get started -------- Centos5: -------- cd /usr/src/redhat/SOURCES # For reference to get newer versions # http://koji.fedoraproject.org/koji/packageinfo?packageID=1958 wget http://kojipkgs.fedoraproject.org/packages/gpredict/0.9.0/5.el6/src/gpredict-0.9.0-5.el6.src.rpm One thing I've been noticing with various new RPMs is that if you try to install the SRPM, you'll get errors like: error: unpacking of archive failed on file /usr/src/redhat/SOURCES/gpredict-0.9.tar.gz;4e5483f3: cpio: MD5 sum mismatch It seems this is a specific issue to RPM but we can still fix this: rpm2cpio gpredict-0.9.0-5.el6.src.rpm | cpio -imud .spec mv gpredict.spec /usr/src/redhat/SPECS rpm2cpio gpredict-0.9.0-5.el6.src.rpm | cpio -imud .gz mv gpredict-0.9.tar.gz /usr/src/redhat/SOURCES cd /usr/src/redhat/SPECS vim gpredict.spec -- Change the line "%configure" to "%configure --enable-coverage" -- One more prerequsite: yum install intltool Ok, let's compile it: cd /usr/src/redhat/SPECS rpmbuild -bb --target=i686 gpredict.spec rpm -Uvh /usr/src/redhat/RPMS/i686/gpredict-0.9.0-5.i686.rpm Getting Started --------------- Ok, so you've installed Gpredict and now let's use it a bit: - Start up gpredict by simply running the following command at the command line: gpredict - When the main window opens up, do the following to get the newest satellite data: Edit -> Update TLE -> From Network - Enter in your home QTH by doing: yy Edit -> Preferences -> General -> Ground Stations -> Add New For me, I added in: Name: Home Description: KI6ZHD Home QTH Location: [Select the city of the closet airport to your QTH] For me, I picked San Jose, CA Lat / Long: If you wish, enter in your exact location 37.3435 North / 121.9999 West as discussed and found in the Xastir section above Click on OK Click on Default to make this new entry your default location - Change some of the views to be more easy for the newbies: Edit -> Preferences -> Modules -> List Views Check-mark: Visibility Next AOS - Ok, now what you really need now is a way to find out what satellites are active but this doesn't seem to be very easy or reliable. From what I can tell, http://oscar.dcarr.org/ is a good start. From that listing, goto File -> New Module and create a new module. module name: home Ground Station: home Now using the Group "All Satellites", do searches for all of the sats shown in the above URL and click on the right arrow button to add them. Click on OK when done. Software Define Radios or SDRs are the newest major innovation to come to radio (analog and all types of radios) in a very long time. Classic radios that use analog circuits to create super heterodyne radios (local oscillators, mixers, filters, detectors, etc.) to de/modulate the signals have inherent imperfections, variance, etc that hurt their performance. An SDR is a completely different type of radio where it uses direct conversion to take the DIRECT antenna input signal, pre-amplify the broadband signal and then digitize it with very fast, broad banded analog to digital converters (DACs). At this point, all filtering, processing, and demodulation is done using complex math in the computer itself. The result is a far more powerful radio system with almost none of the limitations and variances found in real analog hardware. This section is broken into a few pieces: Section A - A quick intro to various SDR hardware (many are just receivers) and how they compare Section B - Quick is a simpler but powerful python based program for IQ-based SDRs like SoftRock, etc. Section C - GnuRadio is more of a framework for many other SDR programs out there. This suite of software allows you to easily write new modulation schemes, etc. all without a soldering iron! Section D - LinRad is a very powerful SDR applications for Linux based on GnuRadio If you're looking for some hardware recommendations, skip down to the "SDR Receivers - Supporting applications for the RTL2838, Airspy, and SDR-Play SDR devices" section for a lot of details Ok, GnuRadio is installed (finally) but now lets talk about hardware. For my uses, I initially wanted to use it with one of these inexpensive RTL for just to try them out as I've heard so much about them. A few notes on some of these units: This is the NooElec NESDR SDR dongle with the R820T2 + TXCO tuner
RTL2832 + R820T2: The third generation USB-tuner devices now available have the newest Raphael Micro R820T2 chip and some of the better designs from say NooElec use highly stable TCXO oscillators. The combination of these two offer even better sensitivity and improved 25MHz-1750MHz frequency coverage. RTL2832 + R820T : The second generation USB-tuner devices have the Raphael Micro R820T chip is evidently a bit more sensitive, and support an effective lower frequency spectrum of 24-1700 Mhz. The official range is 42 to 1002 Mhz with a 3.5 dB noise figure. One nice aspect of these new tuners is that they don't have the traditional DC "carrier" at the center of the FFT like the E4000 units but they have more image aliasing (faint mirror images of strong signals on either side of the 0hz center point. These devices are also a bit cheaper too. This is the Terratec Tstick+ RTL dongle with the E4000 tuner
RTL2832 + E4000 : The first generation units used the Elonics E4000 tuner. They could receive a slightly higher frequency range between 54-2200 MHz with a coverage gap between 1100-1250 MHz. Like most classic I/Q devices (non-direct sampling) like the SoftRock units, there is a DC "carrier" at the center of the FFT due to common I/Q imbalances. The Elonics company is no more so these specific E4000 enabled units are getting harder to find on say Ebay, etc. but they are still available. There is a very nice intro write-up here about the older generation RTL units: http://superkuh.com/rtlsdr.html If some of you might be looking to use an RTL device for HF frequencies (0-54Mhz), you might want to check out this comparison page: http://blog.kf7lze.net/2012/09/14/round-up-of-rtlsdr-upconverter-choices/ You might also want to consider some of the higher end devices mentioned below which include HF natively. One note about Centos and RTL devices: -------------------------------------- The specific E4000 based unit I bought is "newer" and they are only recognized in 3.7.0 or newer kernels. Putting that another way, the stock Centos6/5 kernels will not recognize it. I'm running the modified ElRepo "ml" kernel as described in the kernel section of this document DOES support it so upgrading your kernel is required. It's possible to get the card to be recognized with a stock kernel but I don't think it would be worth the effort and as such, I recommend all users to use the ElRepo kernels. Beyond the kernel driver support, there is still more base software that's needed to get things operational. Beyond the VHF/UHF RTL dongles: ------------------------------- One of the challenges with the RTL dongles is that they don't have any front-end or "pre-selector" filters. What this means is that if you have very strong signals nearby on almost any frequency, they will seriously desense the RTL's receiver. This greatly impacts what the RTL dongles can hear, creates spurs/birdies in the frequencies you want to hear, etc. The proper fix for this is filters on the front end. I've recently been recently been researching this topic and there are three Linux friendly devices that take things up a notch: This is the Airspy v2 dongle supporting a full 10Mhz / 10MSPS bandwidth at 12bits
- AirSpy r2 - 9 or 9 with upconverter option - 10Mhz wide passband (requires a fast computer and solid USB performance, also supports 2.4Mhz wide) - Stock ElRepo 3.17.5 kernel kernel on an Intel i5-2340 @ 2.4Ghz cannot keep up @ 10Msps - native 24Mhz to 1.7Ghz DC to 24Mhz frequencies supported via tightly integrated Spyverter upconverter option - Has RX pass band filters to protect the frontend (important) - 12bit resolution - Direct Sampling receiver so the center DC spike is gone I didn't realize how nice it is to have that gone! - Uses the R820T2 tuner receiver - Receive only - Encased in quality metal enclosure to shield out hearing near-field birdies, etc - OpenSource drivers easily compiled and supported by GnuRadio - USB2 based - Preferred SDR program is SDR# but supports many others (including Gqrx) - USB2.0 - AirSpy r1 - No longer made - 10Mhz bandwidth - Supports 24Mhz to 1.8Ghz - 8bit resolution - Uses the R820T2 tuner receiver - USB2 based This is the SDR Play dongle supporting a full 8Mhz / 8MSPS bandwidth at 12bits
- SDR-Play - 0 as of 1/2016 - 8Mhz bandwidth (requires a fast computer and solid USB performance) - Supports 100Khz to 2Ghz (recently added via new drivers) (original APIs blocked reception of 380-420Mhz) - Has 8 different RX pre-selector filters that can be enabled/disabled - 12bit resolution - Direct Sampling receiver so the center DC spike is gone (I realize how nice it is to have that gone!) - Receive only - Encased in plastic enclosure (unclear if this not enough to shield out hearing near-field birdies, etc) One local user installed copper tape on the inside of his unit to help here but I don't know how effective that is ! CLOSED source Mirics drivers which limits support - currently has drivers for Windows, some Linux, some OSX +------------------------------------------------------------------+ | SHOW-STOPPER: 2/6/16 | | Current binary APIs are compiled against Glibc 2.14 but Centos6 | | ships with Glibc 2.12. I've reached out to SDRPlay to see if | | they will release a new binary API version but they politely | | declined saying there wasn't enough market to support a Centos6 | | driver effort. I have since purchased an AirSpy v2 unit where | | everything is open source and it's been working very well. | | | | Update: 01/25/17 | | There is hope via the 3rd party library effort but it's unclear | | how well it works or matches the closed source Mirics library | | https://github.com/f4exb/libmirisdr-4 | +------------------------------------------------------------------+ - Preferred SDR program is CubicSDR but supports many others (including Gqrx) - USB 2.0 This is the Funcube Dongle+ supporting 192Khz
- Funcube Pro+ - 6 - 192Khz passband bandwidth - 64Mhz to 1.7Ghz - Has RX filters that can be enabled/disabled - 16bit resolution - Uses the previous Mirics chipset and closed source middleware API - USB1.1 based - Though considered one of the first quality SDRs, it's specs are now quite low in comparison to it's newer competitors
This is the LimeSDR 61MSPS bandwidth at 12bits
- LimeSDR - 9 - 100 kHz - 3.8 GHz - 61.44 MHz maximum bandwidth at 12bit - 6 RX antenna jacks, 4 TX antenna jacks (2x2 MIMO) - full duplex @ 0 to 10dBm power - Altera Cyclone IV EP4CE40F23 FPGA - USB 3.0 - Scroll down on the above LimeSDR page to see a comparison table against the HackRF, Ettus B200, B210, BladeRF x40, and an RTL dongle - Very comparable to the Ettus B210 but over 50% cheaper
This is the HackRF device supporting a full 20Mhz / 20MSPS bandwidth at 8bits
- HackRF - 0 - 20Mhz wide passband (requires an extremely fast computer and very fast USB performance) - 10Mhz to 6Ghz support - NO RX pass band filters to protect the frontend (this is important) - 8bit sampling (sampling rates really matter depending if you just want a panadapter vs. a proper receiver) - I/Q Sampling receiver so it has the center DC spike - Receive and 10mw Transmit section (half duplex; no duplexer included; dedicated TX connector) Seems like TX support isn't supported by many programs today; few amplification stages exist - Encased in plastic enclosure - unclear if this not enough to shield out hearing near-field birdies, etc - OpenSource drivers easily compiled and supported by GnuRadio - No real preferred SDR program but is supported many others (including Gqrx) - USB2.0 - HackRF Blue - A lower cost version of the original HackRF but currently no longer in stock
This is the BladeRF x40 40MSPS bandwidth at 12bits
- BladeRF - 0 (x40 model) or 0 (x115 model) - Very wide performance (can display 124Mhz wide waterfall in Gqrx) - 300MHz - 3.8GHz support - Independent 12-bit 40MSPS RX and TX using LimeMicro LMS6002D transceiver - Receive and 10mw Transmit section full duplex up to 28Mhz BW; no duplexer included; - 2x2 MIMO Wifi configurable with SMB cable, expandable up to 4x4 Seems like TX support isn't supported by many programs today; few amplification stages exist - All sources are open source and easily compiled - On-board Altera Cyclone 40KLE or 115KLE (upgraded model) FPGA - On-board Cypress FX3 200MHz ARM9 with 512KB embedded SRAM for USB3 control - USB3.0 (5Gbps) based interface with USB2.0 compatibility - Optional XB200 transverter board for passband filtering at HF, 50MHz, 144MHz, and 222MHz - Optional XB300 Diversity RX + LNA + 33dBm (2.0watt) amplifier + TRX switch @ 2.4ghz - NO TX filtering is offered in this board - BEWARE - Various add on boards, cases, antennas, etc available
This is the Ettus Research B200 bandwidth at 12bits
- Ettus B200 / B210 - 5 single transceiver SDR unit - 70 MHz to 6 GHz - 56 MHz bandwidth - Has 10mw half-duplex transmit support on a dedicated transmit connector - Onboard Xilinx Spartan-6 XC6SLX75 FPGA - Many different add-on boards are available - All sources are open source and easily compiled - USB3 based - Considered one of the best SDRs out there for the cost; early contributor to GnuRadio There are so many other SDR boards out there now that it's becoming a bit crazy: Low-End - rtl-sdr.com's R820T2 + RTL2832U with TXCO and BiasT support - - Outernet E4000 based SDR with TCXO : - https://outernet.is/ - FlightAware Pro Stick w/ 20db LNA specialized for 1090Mhz using R820T2 and RTL2832U chips : [ Many others in this field too - email me if you have a favorite not listed here ] Medium End: - FreeSRP : 0 - http://electronics.kitchen/freesrp - Red Pitaya : 199 Euro - http://redpitaya.com/ [ Many others in this field too - email me if you have a favorite not listed here ] Each of these units have their pros and cons. Depending on your requirements, the edge currently goes with the SDR-Play unit for price vs. performance. Unfortunately, the closed source drivers in the SDR-Play unit block it's use with Centos6. As such, I'm moving forward with the AirSpy R2. +-------------------------------------+ | This section is a work in progress | | - It works as described but isn't | | packaged just yet | +-------------------------------------+ Quisk is a Python based application that fully supports classic soundcard based IQ SDRs like the SoftRock series. IQ based SDRs split a given signal into two mirror pieces: one signal at a 0 degree phase angle and another at 180 degree phase angle. This is called I-Q signals. At that point, the waveforms go into a wide sampling sound card using the left and right microphone channels and all de/modulation, etc. occurs PURELY in computer software! Though inexpensive, I/Q based SDR's bandwidth are limited to the sampling rate of the used soundcard. Most soundcards support either 44.1 or 48Khz. Some better cards support 96Khz and and a fewer number of cards support 192Khz. In comparison, some of the inexpensive RTL dongles can support 2.5MHZ (that's 52x more than a soundcard SDR running at 48Khz)! The nicer SDRs like the Airspy unit can do a full 10Mhz of simultaneous spectrum! Regardless, soundcard SDRs are still very powerful, inexpensive, and make great hobby kits. This is the main window that shows the maximum bandwidth being captured:

Software: --------- There are several Linux-based SDR programs out there: Quisk - What we are going to install in this section (shown above) LinRad, Gqrx, etc. Hardware: --------- Though minimal, there is still some hardware. There are simple kits like the WB5RVZ "SoftRock" units that use a common soundcard all the way up to full complete units like a SDR-IQ, Persius, Flex Radio, etc. For this section, I'm using the SoftRock Lite II receive-only module. Building up that board is well out of the scope of this document but it's not a overly complicated board to build though there is some surface-mount devices (three chips, 8 caps) and you have to wire two toroids. Back on topics, let's get started: - Dependencies: ------------- Here are the code dependencies to get Quisk compiled and going though I'm omitting other programs that were previously installed with other programs as described in this doc. Please see the Quisk documentation for learning more of the dependencies if you're installing this out of order from the rest of the Hampacket documentation. #Graphical UI modules (these will come from EPEL) yum install wxPython wxGTK wxBase wxGTK-gl wxGTK-media # Other known dependencies that are needed but are filled in previous # sections include: # # python-devel fftw fftw-devel alsa-lib-devel portaudio portaudio-devel # ^ ^ ^ ^ ^ ^ # base base base base epel epel - Next, download Quisk cd /usr/local/redhat/SOURCES wget -O quisk-3.6.12.tar.gz http://james.ahlstrom.name/quisk/quisk-3.6.12.tar.gz Test stages (will wrap into an RPM later): make - SoftRock specific : Copy over a configuration file for the SoftRock board cp quisk_hardware_fixed.py $HOME/.quisk_conf.py - Copy in the defaults as well cat quisk_conf_defaults.py >> $HOME/.quisk_conf.py # Show which devices are available to do recording # # This stage isn't 100% reliable for me so you'll have to play with it but.. 1. Run the python script that comes with Quisk to help identify the card id: #Important: run as root "python portaudio.py" 2. Alternatively, you can do it manually using the following commands: cat /proc/asound/cards cat /proc/asound/devices Here, match up the card to the text "digital audio capture". 3. Set the recording sampling rate to match your soundcard. Most basic sound cards will either support 44100 and usually 48000. More advanced cards might offer 96000 or 192000. To see what your card can support, run: #this program comes from the alsa-utils package # alsa-info --stdout | grep -A 12 "Audio Input" Alternatively, if you cannot find alsa-info, you can try this approach: #From https://lacocina.nl/detect-alsa-output-capabilities bash <(wget -q -O - "http://lacocina.nl/alsa-capabilities") -l usb -s 0) USB Audio Class Digital alsa audio output interface `hw:1,0' - device name = C-Media USB Audio Device - interface name = USB Audio - usb audio class = 1 - isochronous adaptive - character device = /dev/snd/pcmC1D0p - rates per format = S16_LE: 48000Hz 44100Hz <-------------------------------------- - monitor file = /proc/asound/card1/pcm0p/sub0/hw_params - stream file = /proc/asound/card1/stream0 In the $HOME/.quisk_conf.py, set the proper value but start LOW to begin with: sample_rate = 48000 4. Set the sound card capture: For me, I edited the "else" stanza of the $HOME/.quisk_conf.py file under the line "if sys.platform == "win32":" to name_of_sound_capt = "portaudio#0" 5. Unset the sound card playback: Since I have a softrock, I disabled this feature by finding the file and put a # in front: #name_of_sound_play = name_of_sound_capt 6. For a 20m softrock, change the fixed center VFO frequency fixed_vfo_freq = 14046000 7. Other Recommended changes to the quisk_conf.py file default_screen = 'WFall' More to come here... GnuRadio is considered the primary foundation for many of the SDR applications out there for Linux and other platforms. It's intended to be a framework to allow users to develop their own modulations, etc. GnuRadio is required by many other SDR applications as well a strong foundation piece for HAMs to create their own modulation types. As such, we need to get it installed first. NOTE: This is a fairly complex set of steps to get all the required dependencies in place. Even with them in place, compiling GnuRadio takes a long time even on the fastest machines so patience is required. Ok, lets' start with the various dependencies: #Note: Being a late addition to this documentation, many of these RPMs were already # installed from other sections. If you've jumped to this section and are # having difficultly installing RPMs, make sure that you followed the "3rd # party REPO" section and possibly searched this entire document on how I # built some of these RPMs if they aren't available in those REPOs # yum install fftw-devel cppunit-devel wxPython-devel libusb-devel \ guile guile-devel alsa-lib-devel numpy gsl-devel python-devel \ python-cheetah python-lxml # Next, we need a newer version of Boost than what's available in the standard Yum # Repos to compile gr-osmosdr and it seems the stock available version is # is broken boost-devel-1.41.0-18.el6.x86_64 for older versions of Cmake. Sheesh! # # According to this URL: # http://gnuradio.4.n7.nabble.com/Fwd-Building-rtl-sdr-gr-osmosdr-build-apparently-failed-Ubuntu-11-10-td40631.html # versions 1.46, 1.46.1, 1.47 and 1.52 are bad! # # Let's replace it with something modern: # # From http://koji.fedoraproject.org/koji/packageinfo?packageID=1074 # # Download a more modern version of the code (yes, 1.55 is available but I'm not too concerned) cd /usr/src/redhat/SRPMS wget http://kojipkgs.fedoraproject.org//packages/boost/1.54.0/8.fc21/src/boost-1.54.0-8.fc21.src.rpm rpm -Uvh boost-1.54.0-8.fc21.src.rpm # Now lets build it but we need to disable a few things to make sure it builds # # NOTE: this takes 34min to build on my dual core i5 2430M @ 2.4GHz with # 4GB of RAM and a 5400RPM HD. # # Do NOT run this build command as root # time rpmbuild -bb --target=x86_64 boost.spec --without python3 --without mpich --without openmpi #Finally, let's install them # # Do this as ROOT # # NOTE: There were conflicts installing these new packages with: # # libboost_filesystem.so.5()(64bit) is needed by (installed) qpid-cpp-client-0.14-22.el6_3.x86_64 # libboost_filesystem.so.5()(64bit) is needed by (installed) qpid-cpp-server-0.14-22.el6_3.x86_64 # libboost_filesystem.so.5()(64bit) is needed by (installed) qpid-qmf-0.14-14.el6_3.x86_64 # libboost_filesystem.so.5()(64bit) is needed by (installed) python-qpid-qmf-0.14-14.el6_3.x86_64 # libboost_filesystem.so.5()(64bit) is needed by (installed) qpid-cpp-server-ssl-0.14-22.el6_3.x86_64 # libboost_program_options.so.5()(64bit) is needed by (installed) qpid-cpp-client-ssl-0.14-22.el6_3.x86_64 # # To deal with this, I forced the install with a "--nodeps" # cd /usr/src/redhat/RPMS rpm -Uvh --nodeps x86_64/boost-1.54.0-8.el6.x86_64.rpm x86_64/boost-atomic-1.54.0-8.el6.x86_64.rpm \ x86_64/boost-chrono-1.54.0-8.el6.x86_64.rpm x86_64/boost-context-1.54.0-8.el6.x86_64.rpm \ x86_64/boost-date-time-1.54.0-8.el6.x86_64.rpm x86_64/boost-filesystem-1.54.0-8.el6.x86_64.rpm x86_64/boost-graph-1.54.0-8.el6.x86_64.rpm x86_64/boost-iostreams-1.54.0-8.el6.x86_64.rpm x86_64/boost-locale-1.54.0-8.el6.x86_64.rpm x86_64/boost-log-1.54.0-8.el6.x86_64.rpm \ x86_64/boost-math-1.54.0-8.el6.x86_64.rpm x86_64/boost-program-options-1.54.0-8.el6.x86_64.rpm \ x86_64/boost-python-1.54.0-8.el6.x86_64.rpm x86_64/boost-random-1.54.0-8.el6.x86_64.rpm \ x86_64/boost-regex-1.54.0-8.el6.x86_64.rpm x86_64/boost-serialization-1.54.0-8.el6.x86_64.rpm \ x86_64/boost-signals-1.54.0-8.el6.x86_64.rpm x86_64/boost-system-1.54.0-8.el6.x86_64.rpm \ x86_64/boost-test-1.54.0-8.el6.x86_64.rpm x86_64/boost-thread-1.54.0-8.el6.x86_64.rpm \ x86_64/boost-timer-1.54.0-8.el6.x86_64.rpm x86_64/boost-wave-1.54.0-8.el6.x86_64.rpm \ x86_64/boost-devel-1.54.0-8.el6.x86_64.rpm x86_64/boost-static-1.54.0-8.el6.x86_64.rpm \ noarch/boost-doc-1.54.0-8.el6.noarch.rpm noarch/boost-examples-1.54.0-8.el6.noarch.rpm \ noarch/boost-build-1.54.0-8.el6.noarch.rpm x86_64/boost-jam-1.54.0-8.el6.x86_64.rpm #Note #2 - PyOpenGL used to be required but it has been replaced with a Qt-based interface # $ yum install PyQt4-devel qwt-devel qwtplot3d-qt4-devel Some RPMs weren't available via the Repos so we have to build them ourselves: # pygsl cd /usr/src/redhat/SRPMS wget http://kojipkgs.fedoraproject.org//packages/pygsl/0.9.5/9.fc19/src/pygsl-0.9.5-9.fc19.src.rpm rpm -ivh pygsl-0.9.5-9.fc19.src.rpm cd /usr/src/redhat/SPECS rpmbuild -bb --target=x86_64 pygsl.spec rpm -ivh /usr/src/redhat/RPMS/x86_64/pygsl-0.9.5-9.el6.x86_64.rpm Cmake ----- Next, it seems there are some issues with building the gr-osmosdr package below with versions of cmake less that 2.8.11 in combination with boost and gnuradio. I beat my head on this several times so we have to bit the bullet and make our own modern version of Cmake since nothing current and fixed is available for Centos6. # Get the new version of Cmake from http://koji.fedoraproject.org/koji/packageinfo?packageID=1485 cd /usr/src/redhat/SRPMS wget http://kojipkgs.fedoraproject.org//packages/cmake/2.8.12.1/1.fc19/src/cmake-2.8.12.1-1.fc19.src.rpm rpm -ivh cmake-2.8.12.1-1.fc19.src.rpm #Next, install a required dependency: # yum install libarchive-devel cd /usr/src/redhat/SPECS # Next, it's worth noting that the new versions of Cmake is bloated up with requiring Emacs # other garbage. It was not very strait forward to disable the need for libarchive-devel and # Emacs so I just recommend to install them including one hidden dependency NOT included # in the Emacs RPM # yum install libarchive-devel emacs libotf # One more thing, it seems I discovered a bug in one of Cmake's post-build tests # which doesn't like the real build environment in /usr/src/redhat vs. a symlink # of /rpmbuild . The errors shows itself in the cmake tests after compiling ok: # # The following tests FAILED: # 287 - CTestTestMemcheckDummyValgrindInvalidSupFile (Failed) # Errors while running CTest # # A fix has been create ngladitz and will be available in a future cmake release. # Until then, disable this specific test. # Edit the cmake.spec file and find the following line: # vim cmake.spec -- . . . bin/ctest -V -E ModuleNotices -E CMake.HTML -E CTestTestUpload %{?_smp_mflags} and replace it with: #DummyValgrindInvalidSupFile does not work on symlinked build environments - bug will be reported via ngladitz bin/ctest -V -E ModuleNotices -E CMake.HTML -E CTestTestUpload -E DummyValgrindInvalidSupFile %{?_smp_mflags} -- # Ok, time to compile and install it: # # Note: this takes a while to build # # Do NOT run this command as root: # rpmbuild -bb --target=x86_64 cmake.spec #Ok, now as the Root user, install it: # rpm -Uvh /usr/src/redhat/RPMS/x86_64/cmake-2.8.12.1-1.el6.x86_64.rpm -- Next, there are more RPMs required: # TO create the documentation rpm install xmlto graphviz # The new GUI yum install qt4-devel PyQwt-devel #To build GnuRadio, we need some more RPMs - Texlive will require 14 other RPMs yum install cmake SDL-devel texlive-latex orc-devel python-docutils uhd-devel #To complete the final RPM install, we also need this rpm yum install scipy Now, we have to build a few more RPMs from scratch as there aren't new enough ones available for Centos: +--------------------------------------------------------------------------------+ | NOTE: As of 01/2014, libusbx was merged back into libusb and then libusbx was | | deprecated. As such, I need to update this section to use the newest | | libusb though I'll admit it might be better to just start over with | | Centos7 | +--------------------------------------------------------------------------------+ #libusbx - This is a newer version (fork) from libusb1. As such, the rpm command here is # using UPGRADE versus install # cd /usr/src/redhat/SRPMS wget http://kojipkgs.fedoraproject.org//packages/libusbx/1.0.15/2.fc19/src/libusbx-1.0.15-2.fc19.src.rpm rpm -ivh libusbx-1.0.15-2.fc19.src.rpm cd /usr/src/redhat/SPECS rpmbuild -bb --target=x86_64 libxusb.spec rpm -Uvh /usr/src/redhat/RPMS/x86_64/libusbx-1.0.15-2.el6.x86_64.rpm \ /usr/src/redhat/RPMS/x86_64/libusbx-devel-1.0.15-2.el6.x86_64.rpm #uhd - the base driver for USB, Ettus, and other devices # # http://koji.fedoraproject.org/koji/packageinfo?packageID=12939 # # cd /usr/src/redhat/SRPMS wget http://kojipkgs.fedoraproject.org//packages/uhd/3.5.3/3.fc20/src/uhd-3.5.3-3.fc20.src.rpm rpm -ivh uhd-3.5.3-3.fc20.src.rpm # Now let's compile the UHD stuff # # DO NOT do this as ROOT # # NOTE: this takes 19min to build on my dual core i5 2430M @ 2.4GHz with # 4GB of RAM and a 5400RPM HD. # cd /usr/src/redhat/SPECS rpmbuild -bb --target=x86_64 uhd.spec # Let's now install it: # # Run this as root # rpm -Uvh x86_64/uhd-3.5.3-3.el6.x86_64.rpm noarch/uhd-firmware-3.5.3-3.el6.noarch.rpm \ x86_64/uhd-devel-3.5.3-3.el6.x86_64.rpm noarch/uhd-doc-3.5.3-3.el6.noarch.rpm # Qwt: Next, we need to build a modern version of Qwt-5.2.3 as it's required # by GnuRadio >= 3.7.0 # Get the new Qwt code # cd /usr/src/redhat/SOURCES http://downloads.sourceforge.net/project/qwt/qwt/5.2.3/qwt-5.2.3.tar.bz2 # Next, get an example SPEC file # cd /usr/src/redhat/SRPMS http://vault.centos.org/6.5/os/Source/SPackages/qwt-5.1.1-4.1.el6.src.rpm rpm -ivh qwt-5.1.1-4.1.el6.src.rpm #Next, download and replace the old patch file with one from my directory # cd /usr/src/redhat/SOURCES rm qwt-path.patch wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/qwt-5.2.3-path.patch #Now edit the spec file to use the newer code # cd /usr/src/redhat/SPECS vim qwt.spec -- # Find the following lines and update them to reflect the new version Version: 5.2.3 Release: 1.1%{?dist} # Update the patch reference as it had to be updated for this new version Patch0: qwt-5.2.3-path.patch and #Also update the patch command to use a level-0 patching %patch0 -p0 # Enable parallel compiling by adding the following to the "make" line: make %{?_smp_mflags} -- # Compile the new version # # Do NOT run this "rpmbuild" command as the root user # rpmbuild -bb --target=x86_64 qwt.spec # Let's install the RPM but you need to be root # cd /usr/src/redhat/RPMS/x86_64/ sudo rpm -Uvh qwt-5.2.3-1.1.el6.x86_64.rpm qwt-devel-5.2.3-1.1.el6.x86_64.rpm # PyGtk: gnuradio-companion as of 3.7.2 now requires PyGTK 2.17 or newer to resolve # errors like: # # AttributeError: type object 'gtk.Entry' has no attribute 'has_focus' # # Unfortunately to install that newer code, we also have to upgrade pygobject2 # Before we get started on pygobject2, we have to fix a low level issue on Centos per # https://www.marshut.net/nvups/problems-rebuilding-pygtk2-2-16.html # cd /usr/src/redhat/SOURCES wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/python2.6-modsupport.diff sudo cp /usr/include/python2.6/modsupport.h /usr/include/python2.6/modsupport.h.orig sudo patch -p1 < python2.6-modsupport.diff # NOTE: You cannot load any versions NEWER than 2.28.2 or other dependencies come in # cd /usr/src/redhat/SRPMS wget https://kojipkgs.fedoraproject.org//packages/pygobject2/2.28.6/2.fc16/src/pygobject2-2.28.6-2.fc16.src.rpm sudo rpm -ivh pygobject2-2.28.6-2.fc16.src.rpm cd /usr/src/redhat/SPECS rpmbuild -bb --target=x86_64 pygobject2.spec cd /usr/src/redhat/RPMS/x86_64 sudo rpm -Uvh pygobject2-2.28.6-2.el6.x86_64.rpm pygobject2-codegen-2.28.6-2.el6.x86_64.rpm \ pygobject2-devel-2.28.6-2.el6.x86_64.rpm pygobject2-doc-2.28.6-2.el6.x86_64.rpm #Ok, now finally to pygtk2 @ cd /usr/src/redhat/SRPMS wget https://kojipkgs.fedoraproject.org//packages/pygtk2/2.24.0/1.fc15/src/pygtk2-2.24.0-1.fc15.src.rpm sudo rpm -ivh pygtk2-2.24.0-1.fc15.src.rpm cd /usr/src/redhat/SPECS rpmbuild -bb --target=x86_64 pygtk2.spec cd /usr/src/redhat/RPMS sudo rpm -Uvh x86_64/pygtk2-2.24.0-1.el6.x86_64.rpm x86_64/pygtk2-codegen-2.24.0-1.el6.x86_64.rpm \ x86_64/pygtk2-libglade-2.24.0-1.el6.x86_64.rpm x86_64/pygtk2-devel-2.24.0-1.el6.x86_64.rpm \ noarch/pygtk2-doc-2.24.0-1.el6.noarch.rpm GnuRadio -------- Ok! Let's get down to getting and building GnuRadio. It should be noted that the GnuRadio package is HUGE and I've found that only compiling the Linux kernel is as long, complex, etc. #Get the STABLE source code - There are three versions of GnuRadio that you can download: # # Stable - that's what I would recommend # Development - stuff should be expected to be broken # Katana-edge - Specific developer dailies # # At the time of this writing, the newest stable is 3.7.9.2 NOTE: If your trying to use an older version of GnuRadio such as 3.7.5, this is # note recommended for the following reasons which have been addressed in the # newer releases: # 1 - when running gnuradio-companion (grc), it doesn't allow you to save files and # throws errors like: # # Traceback (most recent call last): # File "/usr/lib64/python2.6/site-packages/gnuradio/grc/gui/ActionHandler.py", line 457, in _handle_action # ParseXML.to_file(self.get_flow_graph().export_data(), self.get_page().get_file_path()) # File "/usr/lib64/python2.6/site-packages/gnuradio/grc/base/ParseXML.py", line 124, in to_file # 'grc', ' '.join("{}='{}'".format(item) for item in instructions.iteritems()) # File "/usr/lib64/python2.6/site-packages/gnuradio/grc/base/ParseXML.py", line 124, in # 'grc', ' '.join("{}='{}'".format(item) for item in instructions.iteritems()) # ValueError: zero length field name in format # # I reported this and this was due to a commit between 3.7.4 and 3.7.4.1 # # # 2 - In GRC, module tree on the right side of the screen won't display properly after 3.7.2 # # I reported this and this is supposedly fixed in 3.7.6 # # # 3 - There are issues with gnuradio-companion until 3.7.4 per: # # http://gnuradio.4.n7.nabble.com/GRC-issues-with-GNU-Radio-3-7-td46935.html # # For now, I'm working with Sebastian Koslowski (GRC developer) using the GRC Working Group's GIT # repository at https://github.com/gnuradio/gnuradio-wg-grc (3.7.6git) to get things fully functional. # This doc currently covers 3.7.4 which is the best stable version for Centos at the moment # Ok, let's build with 3.7.9.2 # cd /usr/src/redhat/SOURCES wget http://gnuradio.org/releases/gnuradio/gnuradio-3.7.9.2.tar.gz # RECOMMENDED: Now let's get a spec file for gnuradio: # # You can use my GnuRadio spec file and patch: cd /usr/src/redhat/SPECS wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/gnuradio.spec cd /usr/src/redhat/SOURCES wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/doxygen-fix-3.7.9.patch # ---- OR alternatively you can create your own SPEC file (NOT RECOMMENDED) ---- # Get a spec from a stable Fedora package and modify accordingly # cd /usr/src/redhat/SRPMS wget http://kojipkgs.fedoraproject.org//packages/gnuradio/3.6.4.1/1.fc19/src/gnuradio-3.6.4.1-1.fc19.src.rpm rpm -ivh gnuradio-3.6.4.1-1.fc19.src.rpm # If using my SPEC file or the Fedora SPEC file, there are several items you need to # either verify in the file or modify to make things work here: - This GnuRadio spec file overrides the "-j" option for building to -j1 and I emailed the author to understand why but I never received a response. I found that if I set this to "-j8", it would take my Intel i5 2-core + 2-HypeThread machine with 4GB RAM, 500G/5400RPM laptop computer to it's knees with a load of 10+ and started to swap to death! I found that a setting of "-j2" worked ok. # First, for 3.7.4+, we need to download a minor Doxygen patch cd /usr/src/redhat/SOURCES wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/doxygen-fix-3.7.9.patch #Here is an older patch if you're trying to use an older version of GnuRadio wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/doxygen-fix.patch # Now let's edit the spec file to support the new version of GnuRadio as well as include one fix # cd /usr/src/redhat/SPECS vim gnuradio.spec -- Make changes to the parallel build system to run a little faster: %{?_smp_mflags: %global my_smp_mflags %(echo "%{_smp_mflags}" | sed 's/-j[0-9]\+/-j1/g')} and change it to: %{?_smp_mflags: %global my_smp_mflags %(echo "%{_smp_mflags}" | sed 's/-j[0-9]\+/-j2/g')} Next, find the version line and update it to reflect the version of GnuRadio Version: 3.7.9.2 Next, we need to fix a Doxygen issue found starting in 3.7.2.2. Find the line that says: Source0: and just below it, add the line: Patch0: doxygen-fix-3.7.9.patch Also, find the line that says: %setup -q and add a line under that says: %patch0 -p0 Next, GnuRadio 3.7.2+ requires a new version of qwt so let's update the spec file to reflect that: Find the lines that say: BuildRequires: qwt-devel, qwtplot3d-qt4-devel, python-cheetah And replace them with: BuildRequires: qwt-devel >= 5.2 BuildRequires: qwtplot3d-qt4-devel, python-cheetah Next, GnuRadio Companion is shifting to OpenGL centric displays so if you want all the functionality, let's make sure the package requires it: Find the line that says: Requires: pygtk2, python-cheetah, PyQt4, PyQwt And replace them with: Requires: pygtk2, python-cheetah, PyQt4, PyQwt, PyOpenGL Next, in the %build section, find the "cmake" line and change all of the "FORCE" options to "ON". Also, change the "-DENABLE_GR_UHD" option to be "OFF". For example: %cmake -DENABLE_GR_CORE=ON -DENABLE_PYTHON=ON -DENABLE_DOXYGEN=ON -DENABLE_VOLK=ON \ -DENABLE_GRUEL=ON -DENABLE_GR_AUDIO=ON -DENABLE_GR_ATSC=ON -DENABLE_GR_VOCODER=ON \ -DENABLE_GR_UHD=ON -DENABLE_GR_NOAA=ON -DENABLE_GR_PAGER=ON -DENABLE_GR_TRELLIS=ON \ -DENABLE_GR_VIDEO_SDL=ON -DENABLE_GR_WXGUI=ON -DENABLE_GR_UTILS=ON -DENABLE_GRC=ON \ -DENABLE-GR_COMEDI=FORCE -DENABLE_GR_FCD=ON -DSYSCONFDIR=/etc %{?mfpu_neon} .. # Next, 3.7.2 adds some Cmake files that's required for gr-osmosdr package so we need to # make sure they are recognized. Under the "%files devel" section, find the line: %{_includedir}/ and under that, add: %{_libdir}/cmake/gnuradio/ %{_libdir}/cmake/volk/ # Next, as of the 3.7.2.1 version, they dropped the AUTHORS file so you need to remove that # from the SPEC file. Find the following line: # install -m 644 -t %{buildroot}%{_docdir}/%{name}-%{version} COPYING AUTHORS and replace it with install -m 644 -t %{buildroot}%{_docdir}/%{name}-%{version} COPYING --------------------------------------------------------------------------------------- # Ok, that should be it! All this to just GnuRadio to compile.. crazy huh? # Anyway, let's compile it # # NOTE: This build takes: # 45min for 3.7.4 : on dual core Intel i5 2430M @ 2.4ghz : 4GB of RAM : 5400RPM HD # 54min 50sec for 3.7.9.2 : on dual core Intel i5 2430M @ 2.4ghz : 4GB of RAM : Samsung Evo SSD # # Building GnuRadio is a very disk intensive process which is I/O bound so a faster # storage device like an SSD or hard drive (7200rpm) might help A LOT! # # +++ See below if this compile starts to run and then later FAILS +++ # # Do NOT run this "rpmbuild" command as the root user # time rpmbuild -bb --target=x86_64 gnuradio.spec IMPORTANT NOTE #1: ------------------ It's critically important that you review the start of this compiling stage to confirm all the GnuRadio systems and hardware support you expect to be enabled IS going to be present in the final build. My output shows: -- ###################################################### -- # Gnuradio enabled components -- ###################################################### -- python-support -- testing-support -- volk -- doxygen -- gnuradio-runtime -- gr-blocks -- gnuradio-companion -- gr-fec -- gr-fft -- gr-filter -- gr-analog -- gr-digital -- gr-dtv -- gr-atsc -- gr-audio -- alsa -- oss -- jack -- portaudio -- gr-channels -- gr-noaa -- gr-pager -- gr-qtgui -- gr-trellis -- gr-uhd -- gr-utils -- gr-video-sdl -- gr-vocoder -- gr-fcd -- gr-wavelet -- gr-wxgui -- -- ###################################################### -- # Gnuradio disabled components -- ###################################################### -- sphinx -- gr-ctrlport -- gr-comedi -- gr-zeromq IMPORTANT NOTE #2: ------------------ If your compile begins and runs for quite some time to only fail, you might be running out of RAM. I've been working with Linux and have compiled a LOT of code in my day but I've never seen a build require so many resources. That even includes compiling a Linux kernel! If you're hit by this failing builds, I would just recommend to reboot your Linux machine, don't start up any web browsers, etc and try to get past this build and then go back to business as usual. The two example failures I saw were: Failure #1 at 80% through the compile: -- [ 80%] Building CXX object gr-filter/swig/CMakeFiles/_filter_swig.dir/filter_swigPYTHON_wrap.cxx.o cd /home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-filter/swig && /usr/bin/c++ -DENABLE_GR_LOG \ -DGR_PERFORMANCE_COUNTERS -D_filter_swig_EXPORTS -O3 -march=native -m64 -fvisibility=hidden -Wsign-compare \ -Wall -Wno-uninitialized -O3 -DNDEBUG -fPIC -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-filter/swig \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-filter/swig -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-filter/lib \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-filter/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-filter/lib \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-filter/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fft/lib \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fft/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gnuradio-runtime/include \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gnuradio-runtime/include \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gnuradio-runtime/swig \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gnuradio-runtime/swig -I/usr/include/python2.6 \ -Wno-unused-but-set-variable -o CMakeFiles/_filter_swig.dir/filter_swigPYTHON_wrap.cxx.o \ -c /home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-filter/swig/filter_swigPYTHON_wrap.cxx The bug is not reproducible, so it is likely a hardware or OS problem. make[2]: [gr-blocks/swig/CMakeFiles/_blocks_swig5.dir/blocks_swig5PYTHON_wrap.cxx.o] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/gnuradio-3.7.9.2/build' make[1]: [gr-blocks/swig/CMakeFiles/_blocks_swig5.dir/all] Error 2 -- Failure #1 at 80% through the compile: -- [ 90%] Building CXX object gr-atsc/lib/CMakeFiles/gnuradio-atsc.dir/atsc_depad.cc.o cd /home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-atsc/lib && /usr/bin/c++ \ -DENABLE_GR_LOG -DGR_PERFORMANCE_COUNTERS -Dgnuradio_atsc_EXPORTS -O3 -march=native -m64 \ -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -O3 -DNDEBUG -fPIC \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-atsc/lib -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-atsc/lib \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-atsc/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-filter/lib \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-filter/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-filter/lib \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-filter/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fft/lib \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fft/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-analog/include \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-analog/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fec/lib \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fec/lib/viterbi -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fec/lib/reed-solomon \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-fec/include -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gnuradio-runtime/include \ -I/home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gnuradio-runtime/include -o CMakeFiles/gnuradio-atsc.dir/atsc_depad.cc.o \ -c /home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/gr-atsc/lib/atsc_depad.cc Linking CXX shared library libgnuradio-digital-3.7.9.2.so cd /home/dranch/rpmbuild/BUILD/gnuradio-3.7.9.2/build/gr-digital/lib && \ /usr/bin/cmake -E cmake_link_script CMakeFiles/gnuradio-digital.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -O3 -march=native -m64 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -O3 -DNDEBUG \ -shared -Wl,-soname,libgnuradio-digital-3.7.9.2.so.0.0.0 -o libgnuradio-digital-3.7.9.2.so.0.0.0 CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_bf_impl.cc.o CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_bc_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_sf_impl.cc.o CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_sc_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_if_impl.cc.o CMakeFiles/gnuradio-digital.dir/chunks_to_symbols_ic_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/burst_shaper_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/burst_shaper_ff_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/additive_scrambler_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/binary_slicer_fb_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/clock_recovery_mm_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/clock_recovery_mm_ff_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/cma_equalizer_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/constellation.cc.o \ CMakeFiles/gnuradio-digital.dir/constellation_decoder_cb_impl.cc.o CMakeFiles/gnuradio-digital.dir/constellation_receiver_cb_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/constellation_soft_decoder_cf_impl.cc.o CMakeFiles/gnuradio-digital.dir/corr_est_cc_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/correlate_access_code_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/correlate_access_code_tag_bb_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/correlate_access_code_bb_ts_impl.cc.o CMakeFiles/gnuradio-digital.dir/correlate_access_code_ff_ts_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/correlate_and_sync_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/costas_loop_cc_impl.cc.\ o CMakeFiles/gnuradio-digital.dir/cpmmod_bc_impl.cc.o CMakeFiles/gnuradio-digital.dir/crc32.cc.o CMakeFiles/gnuradio-digital.dir/crc32_bb_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/crc32_async_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/descrambler_bb_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/diff_decoder_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/diff_encoder_bb_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/diff_phasor_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/fll_band_edge_cc_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/framer_sink_1_impl.cc.o CMakeFiles/gnuradio-digital.dir/glfsr.cc.o CMakeFiles/gnuradio-digital.dir/glfsr_source_b_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/glfsr_source_f_impl.cc.o CMakeFiles/gnuradio-digital.dir/hdlc_deframer_bp_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/hdlc_framer_pb_impl.cc.o CMakeFiles/gnuradio-digital.dir/header_payload_demux_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/kurtotic_equalizer_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/lms_dd_equalizer_cc_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/map_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/modulate_vector.cc.o \ CMakeFiles/gnuradio-digital.dir/mpsk_receiver_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/mpsk_snr_est.cc.o \ CMakeFiles/gnuradio-digital.dir/mpsk_snr_est_cc_impl.cc.o CMakeFiles/gnuradio-digital.dir/msk_timing_recovery_cc_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/ofdm_carrier_allocator_cvc_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_chanest_vcvc_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/ofdm_cyclic_prefixer_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_base.cc.o \ CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_simpledfe.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_equalizer_static.cc.o \ CMakeFiles/gnuradio-digital.dir/ofdm_frame_acquisition_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_frame_equalizer_vcvc_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/ofdm_frame_sink_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_insert_preamble_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/ofdm_mapper_bcv_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_sampler_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/ofdm_serializer_vcc_impl.cc.o CMakeFiles/gnuradio-digital.dir/ofdm_sync_sc_cfb_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/packet_header_default.cc.o CMakeFiles/gnuradio-digital.dir/packet_header_ofdm.cc.o \ CMakeFiles/gnuradio-digital.dir/packet_headergenerator_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/packet_headerparser_b_impl.cc.o CMakeFiles/gnuradio-digital.dir/packet_sink_impl.cc.o CMakeFiles/gnuradio-digital.dir/pfb_clock_sync_ccf_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/pfb_clock_sync_fff_impl.cc.o CMakeFiles/gnuradio-digital.dir/pn_correlator_cc_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/probe_density_b_impl.cc.o CMakeFiles/gnuradio-digital.dir/probe_mpsk_snr_est_c_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/scrambler_bb_impl.cc.o CMakeFiles/gnuradio-digital.dir/simple_correlator_impl.cc.o \ CMakeFiles/gnuradio-digital.dir/simple_framer_impl.cc.o ../../gnuradio-runtime/lib/libgnuradio-runtime-3.7.9.2.so.0.0.0 \ ../../gr-filter/lib/libgnuradio-filter-3.7.9.2.so.0.0.0 ../../gr-blocks/lib/libgnuradio-blocks-3.7.9.2.so.0.0.0 \ ../../gr-analog/lib/libgnuradio-analog-3.7.9.2.so.0.0.0 ../../volk/lib/libvolk.so.1.2.2 -lboost_date_time -lboost_program_options \ -lboost_filesystem -lboost_system -lboost_thread ../../gr-filter/lib/libgnuradio-filter-3.7.9.2.so.0.0.0 \ ../../gr-fft/lib/libgnuradio-fft-3.7.9.2.so.0.0.0 -lfftw3f -lfftw3f_threads ../../gr-blocks/lib/libgnuradio-blocks-3.7.9.2.so.0.0.0 \ ../../gnuradio-runtime/lib/libgnuradio-runtime-3.7.9.2.so.0.0.0 ../../gnuradio-runtime/lib/pmt/libgnuradio-pmt-3.7.9.2.so.0.0.0 \ -lrt ../../volk/lib/libvolk.so.1.2.2 -ldl -lorc-0.4 -lboost_date_time -lboost_program_options -lboost_filesystem -lboost_system \ -lboost_thread /usr/bin/ld: libgnuradio-digital-3.7.9.2.so.0.0.0: hidden symbol \ `_ZN5boost6detail18sp_counted_impl_pdIPNS_2io18basic_altstringbufIcSt11char_traitsIcESaIcEEENR2_22basic_oaltstringstreamIcS5_S6_E5No_OpEE11get_deleterERKSt9type_info' isn't defined /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[2]: [gr-digital/lib/libgnuradio-digital-3.7.9.2.so.0.0.0] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/gnuradio-3.7.9.2/build' make[1]: [gr-digital/lib/CMakeFiles/gnuradio-digital.dir/all] Error 2 -- Now it's time to finally install GnuRadio! # NOTE: If you're upgrading from a previous version of GnuRadio, you'll need to uninstall # any previous version of gr-osmosdr first and then you'll need to update it in a bit. # To uninstall it, do it with: # # sudo rpm -e gr-osmosdr gr-osmosdr-devel # # # NOTE #2: If you're trying to upgrade GnuRadio after you've already built other programs like # gr-osmosdr, and Gqrx.. you MUST UNINSTALL those older programs FIRST: # sudo rpm -e gr-osmosdr-doc-0.1.5-3.20151214git7cec4c0f.el6.noarch \ gr-osmosdr-devel-0.1.5-3.20151214git7cec4c0f.el6.x86_64 \ gr-osmosdr-0.1.5-3.20151214git7cec4c0f.el6.x86_64 \ gr-iqbal-0.37.2-3.el6.x86_64 \ gr-iqbal-devel-0.37.2-3.el6.x86_64 \ gqrx-2.5.3-1.20160307git8bbe051d.el6.x86_64 #old # sudo rpm -e gr-osmosdr-devel-0.1.1-1.20131208git05d51b53.el6.x86_64 \ # gr-osmosdr-0.1.1-1.20131208git05d51b53.el6.x86_64 gr-osmosdr-doc-0.1.1-1.20131208git05d51b53.el6.noarch \ # gqrx-2.3.0-1.20131215git57356c50.el6.x86_64 # # Now install your newly build gnuradio RPMs and then rebuild / install any other updated # RPMs like gr-osmosdr, Gqrx, etc. afterward cd /usr/src/redhat/RPMS sudo rpm -Uvh x86_64/gnuradio-3.7.9.2-1.el6.x86_64.rpm \ x86_64/gnuradio-examples-3.7.9.2-1.el6.x86_64.rpm \ x86_64/gnuradio-devel-3.7.9.2-1.el6.x86_64.rpm \ noarch/gnuradio-doc-3.7.9.2-1.el6.noarch.rpm #old install sudo rpm -Uvh x86_64/gnuradio-3.7.4-1.el6.x86_64.rpm x86_64/gnuradio-devel-3.7.4-1.el6.x86_64.rpm \ noarch/gnuradio-doc-3.7.4-1.el6.noarch.rpm x86_64/gnuradio-examples-3.7.4-1.el6.x86_64.rpm --------------------------------------------------------------------------------------- Excellent work and it' installed! It's now HIGHLY recommended to optimize your GnuRadio software for your specific computer. From the command line run this command while NOT using your computer for anything: #Do not run this as the root user # takes 18min 22sec on a i5-2430M running 2.4Ghz w/ 4GB RAM - only uses a single core time volk_profile This command will allow GnuRadio to best utilize your specific hardware. This is a VERY time consuming process so let it complete. The output of the command will write it's settings to $HOME/.volk/volk_config . If multiple users are going to use GnuRadio / Gqrx / etc on this machine, they will need to either copy this file in their home directory or run the "volk_profile" themselves. An optional module of GnuRadio is the IQ-Balance module where it attempts to to suppress the symmetrical images caused by IQ imbalance in the RX path of quadrature receivers. This will help minimize the spike right in the middle of the waterfall when using I/Q devices like RTL dongles, SoftRocks, etc. NOTE: If your reading this as you just upgraded your version GnuRadio, YES, you're going to need to rebuild gr-ipbal module (no need to rebuild/re-install libosmo-dsp Ok, let's get started. First, we actually have to build the libosmo-dsp package # Download and install the newest libosmo-dsp SPEC file found at: # # SRPM baseline can be found at: # http://koji.fedoraproject.org/koji/packageinfo?packageID=19272 # cd /usr/src/redhat/SRPMS wget https://kojipkgs.fedoraproject.org//packages/libosmo-dsp/0.3/1.fc20/src/libosmo-dsp-0.3-1.fc20.src.rpm rpm -ivh libosmo-dsp-0.3-1.fc20.src.rpm #Now let's build and install it cd /usr/src/redhat/SPECS # Do NOT be root when running this # # build time: 18 seconds # rpmbuild -bb --target=x86_64 libosmo-dsp.spec sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/libosmo-dsp-0.3-1.el6.x86_64.rpm sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/libosmo-dsp-devel-0.3-1.el6.x86_64.rpm Now let's get going with gr-iqbal: # Download and install the newest IQBal SPEC file found at: # # SRPM baseline can be found at: # http://koji.fedoraproject.org/koji/buildinfo?buildID=589945886 # cd /usr/src/redhat/SRPMS wget https://kojipkgs.fedoraproject.org//packages/gr-iqbal/0.37.2/3.fc20/src/gr-iqbal-0.37.2-3.fc20.src.rpm rpm -ivh gr-iqbal-0.37.2-3.fc20.src.rpm # It's worth noting that this module hasn't been updated 11/20/2015 with it's 0.37.2 release. # Ok, time to build it: # # Do NOT be root when running this # # build time: 18 seconds # cd /usr/src/redhat/SPECS rpmbuild -bb --target=x86_64 gr-iqbal.spec # Now let's install it # cd /usr/src/redhat/RPMS/ sudo rpm -Uvh x86_64/gr-iqbal-0.37.2-3.el6.x86_64.rpm x86_64/gr-iqbal-devel-0.37.2-3.el6.x86_64.rpm \ noarch/gr-iqbal-doc-0.37.2-3.el6.noarch.rpm If you have chosen to use an RTL Dongle device, you'll want to follow this section: NOTE on software compiling order: --------------------------------- The RTL-SDR Application package must be installed FIRST and then you can compile and install the GR-OSMOSDR software. If you don't do things in this order, the required GR-OSMO plugin will not be built The RTL-SDR package has various required support applications to get it properly programmed, tested, etc. # Download and install the newest RTL-SDR software found at: # # SRPM baseline can be found at: # http://koji.fedoraproject.org/koji/packageinfo?packageID=15886 # cd /usr/src/redhat/SRPMS wget http://kojipkgs.fedoraproject.org//packages/rtl-sdr/0/0.2.20130403git4a068f56.fc19/src/rtl-sdr-0-0.2.20130403git4a068f56.fc19.src.rpm rpm -ivh rtl-sdr-0-0.2.20130403git4a068f56.fc19.src.rpm #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} Now, you need to disable the patches in the old SPEC file as those changes have already been integrated into the RTL-SDR sources: Delete or comment out the lines: Patch0: rtl-sdr-0-lib64-fix.patch and %patch0 -p1 -b .lib64-fix -- # Ok, time to build it: # # This takes about # # Do NOT be root when running this # # build time: 18 seconds # rpmbuild -bb --target=x86_64 rtl-sdr.spec # Be root to install it # sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/rtl-sdr-0.5.2-1.20131213git2d0eaa89.el6.x86_64.rpm \ /usr/src/redhat/RPMS/x86_64/rtl-sdr-devel-0.5.2-1.20131213git2d0eaa89.el6.x86_64.rpm # Dongle Usage Unix Group # Ok.. one last thing: You need to add your username (and any other users that will be using the RTL USB dongle to the "rtlsdr" Unix group. In this example, I'm adding myself (user: dranch) to this new Unix group. You'll need to change the username to reflect YOUR username (and any additional username): sudo groupadd rtlsdr sudo usermod -G rtlsdr dranch # Normally, you now would need to completely log out of the machine (Xwindows # and all) and then log back in to see this new group ownership. To confirm, # be that new user (dranch in this example), and run the command: $ groups dranch dialout lock wireshark # Notice the "rtlsdr" group isn't listed in the above output. To get this # command to take effect NOW, without logging out and back in, use the # following command: newgrp rtlsdr # You'll have to use this command in every login using this specific username # you have until you completely log out and back in on each of those logins. 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] This is the main window that shows the maximum bandwidth being captured: 10Mhz or 10MSPS
If you have an AirSpy SDR device, you need to install the UserMode drivers first to then update the gr-osmosdr package. NOTE: libusb might need to be upgraded to 1.0.19 - things work ok with me w/o upgrading it #Next, let's get the Airspy "Host" sources, align them, and fix them for Centos6 from # https://github.com/airspy/host/releases # cd /usr/src/redhat/SOURCES wget https://github.com/airspy/host/archive/v1.0.8.tar.gz cd ../BUILD tar ../SOURCS/xzvf v1.0.8.tar.gz #Now create a properly named archive to match RPM naming conventions mv host-1.0.8 airspy-host-1.0.8 # For 1.0.7: # Next, there is an issue with the Airspy's cmake file which assumes a version of # GCC newer than 4.4 which doesn't support the ANSI C version 90 (GCC v4.4 only # supports version 89). I have reported this error to the Github repo but the # specific error is: # # CMake Error at /usr/share/cmake/Modules/TestBigEndian.cmake # # # To fix this issue, edit the following files: # airspy-host-1.0.8/libairspy/CMakeLists.txt # airspy-host-1.0.8/airspy-tools/CMakeLists.txt # # In those files, find the following line and DELETE it: # # set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu90") #Now create the new archive tar czvf ../SOURCES/airspy-host-1.0.8.tar.gz airspy-host-1.0.8/ rm -Rf airspy-host-1.0.8 #Next, download the required SPEC file and make sure it reflects the right version # of your Airspy host tools # cd /usr/src/redhat/SPECS wget www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/airspy-host.spec vim airspy-host.spec URL: https://github.com/airspy/host/archive/v1.0.8.tar.gz Version: 1.0.8 # Ok, time to build it: # # This takes about # # Do NOT be root when running this # # build time: 4 seconds # cd /usr/src/redhat/SPECS time rpmbuild -bb --target=x86_64 airspy-host.spec #Now install it with: # sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/airspy-host-1.0.8-1.el6.x86_64.rpm #Ok, you now have the AirSpy software installed. Few other things are required to be done 1. If you're running kernel version 3.17.x or newer, you need to blacklist the stock "airspy" kernel driver that is intended for DAB video display. Do the following: a. vim /etc/modprobe.d/airspy-blacklist.conf -- blacklist airspy -- 2. Dongle Unix Group You now need to add your username (and any other users that will be using the Airspy device to the "plugdev" Unix group. This specific usergroup was defined in the Udev rule when you installed the AirSpy userspace driver. In this specific example, I'm created the group AND adding myself (user: dranch) to this Unix group. You'll need to change the username to reflect YOUR username (and any additional username): sudo groupadd plugdev sudo usermod -G plugdev dranch Now normally you would need to completely log out of the machine (Xwindows and all) and then log back in to see your username being in this new group. To confirm, be that new user (dranch in this example), and run the command: $ groups dranch dialout lock wireshark rtlsdr Notice the "plugdev" group isn't listed in the above output. To get this group setting to take effect NOW (without logging out and back in) use the following command: newgrp plugdev You'll have to use this command in every login using this specific username you have until you completely log out and back in on each of those logins. 3. Now lets get down to using the AirSpy with doing some initial testing. Run the following command to verify that the device is seen, check it's serial number, firmware, etc: # Do not run as the ROOT user $ /usr/bin/airspy_info -- airspy_lib_version: 1.0.8 Found AirSpy board 1 Board ID Number: 0 (AIRSPY) Firmware Version: AirSpy NOS v1.0.0-rc9-0-ga56adfd 2016-06-12 Part ID Number: 0x6906002B 0x00000030 Serial Number: 0x644064xxxxxxxxxx Supported sample rates: 10.000000 MSPS 2.500000 MSPS Close board 1 -- If the above command doesn't run properly, you need to resolve the issue 4. In the above command, you can see that my unit is running firmware AirSpy NOS 1.0.0-rc9-0-ga56adfd 2016-06-12. The Airspy team updates their firmware time to time so I recommend you create a Github account and "watch" the firmware announce page at: https://github.com/airspy/firmware/releases If there is a newer version of code, consider following these instructions to upgrade your firmware: https://github.com/airspy/firmware/wiki/Linux-how-to-flash-airspy-firmware 5. Next step is to confirm the end to end performance to the Airspy unit. Run the following command for at LEAST 30 seconds /usr/bin/airspy_rx -r /dev/null -t 0 -- /usr/bin/airspy_rx -r /dev/null -t 0 Device Serial Number: 0x644064xxxxxxxxxx Stop with Ctrl-C Streaming at 10.001 MSPS Streaming at 10.000 MSPS Streaming at 10.000 MSPS Streaming at 10.001 MSPS . . . Streaming at 10.000 MSPS Streaming at 10.000 MSPS Streaming at 10.000 MSPS Streaming at 10.000 MSPS ^CCaught signal 2 User cancel, exiting... Total time: 18.4944 s Average speed 10.0001 MSPS IQ done -- It's critical that this average report OVER 10.0000 MSPS. If it doesn't, your computer hardware + OS + USB sub-system aren't performing fast enough for the AirSpy. As you can see above on my Intel i5-2430 @ 2.4Ghz dual core laptop running the Epel 3.17.5 kernel, things are just fast enough for 10MSPS (10Mhz wide bandwidth). If you're not getting enough samples through, you can try the "packing" feature using the "-p 1" option: -- /usr/bin/airspy_rx -p 1 -r /dev/null -t 0 Device Serial Number: 0x644064DC307C94CD Stop with Ctrl-C Streaming at 10.006 MSPS Streaming at 9.999 MSPS Streaming at 9.998 MSPS Streaming at 10.006 MSPS Streaming at 10.003 MSPS Streaming at 10.001 MSPS Streaming at 10.004 MSPS Streaming at 10.002 MSPS Streaming at 10.000 MSPS Streaming at 9.993 MSPS Streaming at 10.002 MSPS Streaming at 9.999 MSPS Streaming at 9.995 MSPS Streaming at 10.000 MSPS ^CCaught signal 2 User cancel, exiting... Total time: 16.7699 s Average speed 10.0021 MSPS IQ done -- It should be noted that if you enable packing, though you'll be using less USB bandwidth, you WILL be using more CPU to do the unpacking on the CPU side. For example, if my Intel i5-2430 @ 2.4Ghz dual core laptop runs at a load about 4.25 but with packing enabled, I see a load of about 6.16 to 6.40! TBD: How to improve the performance even more: - No USB hubs between the PC and the Airspy - Try different USB ports on your computer (ports on the front vs. on the back can be on different / less-loaded USB controllers - Try upgrading libusbx to newest libusb libraries - Try a newer Linux kernel - Try specific USB performance tuning - Try using a computer with a better USB chipset Next up, you'll need to compile GR-OSMOSDR to create the required plugins for GnuRadio. Go ahead and skip to that section now unless you want to install support for other hardware. +------------------------------------------------------------------+ | SHOW-STOPPER: 2/6/16 | | Current binary APIs are compiled against Glibc 2.14 but Centos6 | | ships with Glibc 2.12. I've reached out to SDRPlay to see if | | they will release a new binary API version but they politely | | declined saying there wasn't enough market to support a Centos6 | | driver effort. I have since purchased an AirSpy v2 unit where | | everything is open source and it's been working very well. | | | | Update: 01/25/17 | | There is hope via the 3rd party library effort but it's unclear | | how well it works or matches the closed source Mirics library | | https://github.com/f4exb/libmirisdr-4 | +------------------------------------------------------------------+ If you have an SDR-Play device, you MUST install the closed source Mirics APIs as provided from the SDR Play folks for it to function. NOTE: The SDRPlay Mirics API download is currently a self-executable file which REQUIRES that the installing user have sudo rights to the machine. The only other package I've seen like this is Oracle Java but it uses this to make the user agree to a license agreement. There isn't any license display nor acceptance prompt here so I don't know why they are doing this. I cannot disable this sudo behavior. As such, you MUST give your current username to have root sudo rights before continuing on. NOTE2: The following steps took help from the following reference document: http://www.sdrplay.com/docs/Mirics_SDR_API_Linux_install_technote_r2p0.pdf 1. NOTE: This is now redundant and is not required anymore You need to update the Udev system to load the correct base-layer USB driver. To do this, create the /etc/udev/rules.d/66-mirics.rules file and in it, add the following text: SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",ATTRS{idVendor}=="1df7",ATTRS{idProduct}=="2500",MODE:="0666" Now restart Udev with: /etc/rc.d/init.d/udev-post restart 2. You need to download the newest Mirics closed-source API. As of 1/31/16, the current version is 1.9.4 a. cd /usr/src/redhat/SOURCES b. mkdir SDRplay_RSP_MiricsAPI-1.9.4 c. cd SDRplay_RSP_MiricsAPI-1.9.4 d. Goto http://sdrplay.com/linuxdl.php and download the SDRplay_RSP_MiricsAPI-1.9.4.run file e. Make it runable with the command: chmod 755 SDRplay_RSP_MiricsAPI-1.9.4.run f. Create an archive with cd .. tar czvf SDRplay_RSP_MiricsAPI-1.9.4.tar.gz SDRplay_RSP_MiricsAPI-1.9.4/ g. Remove the source directory rm -Rf SDRplay_RSP_MiricsAPI-1.9.4 4. Download my SDRPlay Spec file a. cd /usr/src/redhat/SPECS b. wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/sdrplay_rsp_miricsapi.spec 5. Build the RPM a. It's worth mentioning that this source package is a self-installer that requires that you give your sudo password before it runs. Anyway, now run: rpmbuild -bb --target=x86_64 sdrplay_rsp_miricsapi.spec 6. Install the RPM #I am working with SDR-Play to see if a Glibc 2.14 issue can be resolved for the SoapyAPI file #The error seen is: # # error: Failed dependencies: # libc.so.6(GLIBC_2.14)(64bit) is needed by SDRplay_RSP_MiricsAPI-1.9.4-1.x86_64 sudo rpm -ivh --nodeps /usr/src/redhat/RPMS/x86_64/SDRplay_RSP_MiricsAPI-1.9.4-1.x86_64.rpm -------------------------------------- Direct install method - to be deleted -------------------------------------- Install the API with: sudo /tmp/SDRplay_RSP_MiricsAPI-1.9.4.run -- Verifying archive integrity... All good. Uncompressing SDRplay Mirics API Install Package V1.9.4 100% Installing SDRplay RSP Mirics API library... Architecture: x86_64 API Version: 1.8.1 Remove old libraries... Install /usr/local/lib/libmirsdrapi-rsp.so Remove old header files... Install /usr/local/include/mirsdrapi-rsp.h Udev rules directory found, adding rules... Libusb found, continuing... Installing SoapySDRPlay... Installing SoapySDR... Finished. -- . There seems to be a bug with the SDR-Play library package which needs a minor fix: #The installer is putting 64bit libraries in the 32bit lib pasth mv /usr/local/lib/libmirsdrapi-rsp-x86_64-1.8.1.so /usr/local/lib64/ sudo ln -s /usr/local/lib64/libmirsdrapi-rsp-x86_64-1.8.1.so /usr/local/lib64/libmirsdrapi-rsp.so . To complete the installation, you need to update the lib paths with: sudo ldconfig +------------------------------------------------------------------+ | SHOW-STOPPER: 2/6/16 | | Current binary APIs are compiled against Glibc 2.14 but Centos6 | | ships with Glibc 2.12. I've reached out to SDRPlay to see if | | they will release a new binary API version but they politely | | declined saying there wasn't enough market to support a Centos6 | | driver effort. I have since purchased an AirSpy v2 unit where | | everything is open source and it's been working very well. | | | | Update: 01/25/17 | | There is hope via the 3rd party library effort but it's unclear | | how well it works or matches the closed source Mirics library | | https://github.com/f4exb/libmirisdr-4 | +------------------------------------------------------------------+ The OSMO-SDR software is the middleware package that supports the low level RTL SDR and SDR-Play hardware. Since we need this for either device, let's get started. A few notes first... CRITICAL NOTE: 1. Please note that the newest versions of the OSMO-SDR software requires GnuRadio 3.7.0+ to build. You must have an updated GnuRadio before you try this stage. 2. Any Userspace drivers such as the RTL-SDR, AirSpy, or SDRPlay packages must be compiled AND be installed before this package can be compiled 3. There is an optional package called gr-iqbalance that, if installed before gr-osmosdr is built (as detailed above), it will help reduce the mirror signal on either side of the center DC spike seen from I/Q based devices like the RTL dongles, SoftRock, etc modules. Important Note: --------------- gr-osmosdr exposes a bug in older versions of Cmake and the Boost libraries so you need to be running valid versions of those programs # Download and install a working version of GR-OSMO SDR drivers # found at http://koji.fedoraproject.org/koji/buildinfo?buildID=482242 # cd /usr/src/redhat/SRPMS wget http://kojipkgs.fedoraproject.org//packages/gr-osmosdr/0.1.1/6.20130729git9dfe3a63.fc20/src/gr-osmosdr-0.1.1-6.20130729git9dfe3a63.fc20.src.rpm rpm -ivh gr-osmosdr-0.1.1-6.20130729git9dfe3a63.fc20.src.rpm # Now we need to get the newest 1.5.0GIT sources as there are important fixes in Git but # a new major version of code hasn't been published since Nov 4, 2014! That and gqrx 2.4.0 # requires 0.1.5) # cd /usr/src/redhat/SOURCES mkdir gr-osmosdr-git cd gr-osmosdr-git git clone git://git.osmocom.org/gr-osmosdr # Now check out the version - current version as of this writing is 0.1.5 (shown on three different lines) grep -r VERSION_INFO You should see something like: -- gr-osmosdr/CMakeLists.txt:set(VERSION_INFO_MAJOR_VERSION 0) gr-osmosdr/CMakeLists.txt:set(VERSION_INFO_API_COMPAT 1) gr-osmosdr/CMakeLists.txt:set(VERSION_INFO_MINOR_VERSION 5) gr-osmosdr/CMakeLists.txt:set(VERSION_INFO_MAINT_VERSION git) -- # Next, write down the current GIT commit serial number with the command: # cat gr-osmosdr/.git/logs/HEAD # # as of 07/04/16, it's 164a09fc11cec2d8b15b38e8b512fa542d6cecc7 (never mind if it has your # name or other comments in it, etc.. that's just how Git does things # Ok, time to make the archive where the name consists of the package name, version, date and # the GIT short commit which is the FIRST 8 characters ( Most significant Bit - MSB) of the # git commit serial number. In my case, I would need to do: # mv gr-osmosdr gr-osmosdr-0.1.5 tar civf tar civf ../../BUILD/gr-osmosdr-0.1.5-20160704git164a09fc.tar.bz2 gr-osmosdr-0.1.5/ cd .. rm -Rf gr-osmosdr-git #Now you have to update a few things in this Spec file: # cd /usr/src/redhat/SPECS vim gr-osmosdr.spec -- Next, edit the gr-osmosdr.spec file and fill in the blanks for your checkout. For me, I have: 1. Update the top git_commit line: 164a09fc11cec2d8b15b38e8b512fa542d6cecc7 2. Update the GIT date: 20160704 3. Update the Version: 0.1.5 4. Update the Release to: 4.%{git_suffix}%{?dist} Next, we need to update the BuildRequires line. Change and add the line from: BuildRequires: cmake, python2-devel, gnuradio-devel, boost-devel, doxygen to BuildRequires: cmake, python2-devel, gnuradio-devel, doxygen BuildRequires: boost-devel >= 1.53, gr-iqbal-devel Next, You need to disable the two patch files if they are present in your version of gr-osmosdr. Put a "#" in front of the lines: #Patch0: gr-osmosdr-0.0.1-doxygen-fix.patch #Patch1: gr-osmosdr-0.0.1-docdir-override.patch and under the %prep section #%patch0 -p1 -b .doxygen-fix #%patch1 -p1 -b .docdir-override Next, modify the build section to allow for SDR-Play's API connector. Change the following line: %cmake -DENABLE_DOXYGEN=on -DGR_PKG_DOC_DIR=%{_docdir}/%{name} .. to %cmake -DENABLE_NONFREE=TRUE -DCMAKE_PREFIX_PATH=/usr/local/lib/SoapySDR/ -DENABLE_DOXYGEN=on -DGR_PKG_DOC_DIR=%{_docdir}/%{name} .. Next, find the "%files" section and find the FOUR following lines: %exclude %{_docdir}/%{name}-%{version}/html %exclude %{_docdir}/%{name}-%{version}/xml %exclude %{_docdir}/%{name}-%{version}/examples %doc AUTHORS COPYING You need to disable them by putting a # in front of them like: #%exclude %{_docdir}/%{name}-%{version}/html #%exclude %{_docdir}/%{name}-%{version}/xml #%exclude %{_docdir}/%{name}-%{version}/examples #%doc AUTHORS COPYING Next, go down to the "%files doc" section and add the following as the FIRST line under that section: %doc AUTHORS COPYING -- # Ok, time to build and install it: # # Do NOT be root when running this # # NOTE: # # If you see an error similar to: # # make[2]: No rule to make target `/usr/lib64/lib64/libboost_thread-mt.so.5', needed by `lib/libgnuradio-osmosdr-0.1.1git.so.0.0.0' # # This is due to a conflict with an old version of cmake and boost. The only # way to resolve it is to build modern versions of cmake, boost, and gnuradio # from scratch as shown in the above sections #Build time: 1min 46sec on a dual core i5-2420 laptop at 2.4Ghz with 4GB RAM and a SSD drive time rpmbuild -bb --target=x86_64 gr-osmosdr.spec # It's now very important that you scroll back and review how the configuration stage # went to verify that you see the expected devices you want supported to be # in the "SUPPORTED" list. If your specific hardware isn't listed under the supported # section, things will NOT work. You'll need to figure out why they weren't at configuration # time, resolve it, and then build again. An example output would be: # # -- ###################################################### # -- # Gnuradio enabled components # -- ###################################################### # -- Python support # -- Osmocom IQ Imbalance Correction # -- FUNcube Dongle # -- IQ File Source # -- Osmocom RTLSDR # -- RTLSDR TCP Client # -- Ettus USRP Devices # -- RFSPACE Receivers # -- SDRplay RSP (NONFREE) # -- AIRSPY Receiver # -- # -- ###################################################### # -- # Gnuradio disabled components # -- ###################################################### # -- sysmocom OsmoSDR # -- FUNcube Dongle Pro+ # -- Osmocom MiriSDR # -- HackRF Jawbreaker # -- nuand bladeRF # -- SoapySDR support # The above output shows the proprietary SDRPlay RSP drivers being # enabled. This won't be seen unless you follow the SDR-Play section # above # Now install the RPMs # # NOTE: If you are upgrading from say gr-osmodr-0.1.1 to 0.1.5 to support Gqrx 2.4.0, # you might have to un-install the older gqrx 2.3.0 first # cd /usr/src/redhat/RPMS sudo rpm -Uvh x86_64/gr-osmosdr-0.1.5-4.20160704git164a09fc.el6.x86_64.rpm \ x86_64/gr-osmosdr-devel-0.1.5-4.20160704git164a09fc.el6.x86_64.rpm \ noarch/gr-osmosdr-doc-0.1.5-4.20160704git164a09fc.el6.noarch.rpm Gqrx is an excellent, easy to use SDR program using GnuRadio on the backend, supports various SDR hardware including RTL and FunCube dongles, AirSpy, SDRPlay, Ettus Research USRP and other OSMO SDR supported hardware devices. Gqrx supports several demodulators including SSB, AM, narrow and wideband amateur FM, broadcast FM, CW, and also has various configurable filters. It also has a built-in AFSK-1200 packet decoder but also supports sending decoded signals over a TCP connection for superior tools like Direwolf and Fldigi! Gqrx supports zooming in on both the IQ waterfall and the decoded audio waterfall, bookmarks, recording the IQ and demodulated signals, etc! This is the main window that shows the maximum bandwidth being captured:

This is the same main window that shows a zoomed in view of the FFT waterfall:

This is the AFSK1200 packet decode window when listening to the US APRS channel:
A few important notes: -------------------- 1. If you jumped to this section hoping to install Gqrx without much fuss.. sorry, it's not that simple. You MUST go back to the "42b.gnuradio" section above and install all of the other required dependencies including: boost, cmake (newest version), gr-osmosdr, and the support section for say a AirSpy or SDRplay or rtl-sdr hardware device first 2. The underlying GnuRadio code changes a LOT which requires Gqrx to update it's code as well. The way the code is written, Gqrx will only support the newest GnuRadio code and it WON'T work with any older code. What this means is that if you want to load a newer version of Gqrx, it typically means you'll have to also upgrade all of GnuRadio, all of gr-osmosdr, etc. It's a real pain but I promise you it's worth it! Current versions of Gqrx require the following: - GnuRadio 3.7 (this documentation set will install 3.7.9.2) - Gqrx 2.6 require at least Qt 5.0 (this documentation set will install Qt 5.6.1 onto Centos6) - Gqrx 2.53 required at least Qt 4.7 (this documentation set will install Qt 4.8 onto Centos6 - cmake 3.2.0 or newer (seems to work ok with Cmake 2.8.x as installed with this doc set) - If you want to fully leverage the Airspy R2 HW, you need gr-osmosdr 1.5.0GIT built as of feb 28, 2016 Legacy GQRX code ---------------- GQRX v2.1 - gqrx v2.1.148 will compile and run on the stock Centos6 qt-4.4 libraries which are available from the main Centos6 repos. Unfortunately there are several big bugs in this version of Gqrx that are fixed in newer versions. The GIT repository for Gqrx 2.5.3 also has several fixes and improvements but it requires qt4.7+ (or optionally Qt5) to compile. The GQRX documentation will take you though both options depending on what you want to do. I recommend to go the Qt 4.8 route as the newer features in Gqrx are worth it. The newest Gqrx versions also have minimum versions on gnuradio and gr-osmosdr as well. Ok, as usually, time to fill some dependencies: # Some specific build tools required # yum install cmake cppunit-devel Qt-5.x GUI framework -------------------- As of Gqrx 2.6, it now requires the Qt 5.x framework. In the past, this wasn't available on Centos6 in any of the binary RPM repos but it now is. Fortunately, you can install Qt5.x along side any other versions of Qt so there shouldn't be any conflicts. So let's install it: sudo yum install qt5 #Potential install #Qt5.6.1 comes from EPEL - 46MB installed sudo yum install qt5-qtbase.x86_64 qt5-qtbase-common.noarch qt5-qtbase-devel.x86_64 qt5-qtbase-gui.x86_64 qt5-qtx11extras.x86_64 qt5-qtx11extras-devel.x86_64 qt5-qtsvg.x86_64 Please skip to the next sub-section to keep going... DEPRECATED - Building Qt-4.8 for Centos6 ---------------------------------------- +--------------------------------------------------------------------------------------+ | NOTE: | | ----- | | This section shouldn't be required now as Qt5 is now available from Binary repos and | | Gqrx now requires Qt5. This section is being kept around for now for any users | | looking to only use Gqrx 2.5.3 or older | +--------------------------------------------------------------------------------------+ Ok, let's install qt-4.8 - current as of May, 2013 ------ #To build Qt, we first need the following: yum install unixODBC-devel libicu-devel NetworkManager-devel libXv-devel \ gstreamer-plugins-base-devel cd /usr/src/redhat/SRPMS #NOTE: the Qt 4.8 SRPM is a 236MB download # wget http://download.fedoraproject.org/pub/fedora/linux/updates/17/SRPMS/qt-4.8.4-14.fc17.src.rpm rpm -ivh qt-4.8.4-17.fc17.src.rpm Edit the qt.spec file -- Find the line: BuildRequires: libtiff-devel and after it, add the line: BuildRequires: libicu-devel Next, find the line: BuildRequires: pkgconfig(icu-i18n) and replace with BuildRequires: pkgconfig(icu) -- # Ok, time to build it: # # This will take a while! # # Do NOT build this as root # rpmbuild -bb --target=x86_64 qt.spec # Ok, time to install it # # To be clear.. we are NOT upgrading our Centos6 Qt4 install. Qt allow multiple # versions to be installed simultaneously so we are installing along side the stock # qt-4.6.2 version # # Do this as ROOT # sudo rpm -ivh --force qt-4.8.4-14.el6.x86_64.rpm qt-x11-4.8.4-14.el6.x86_64.rpm qt-devel-4.8.4-14.el6.x86_64.rpm On to Compiling Gqrx ------------------- It should be noted that the releases on the SourceForge site are rather old compared to the Git repository. As such, I recommend to use the GIT repository even if you want to download the stable releases. # First, let's get a template Gqrx spec file (if you don't already have one) # # http://rpm.pbone.net/index.php3 # cd /usr/src/redhat/SRPMS wget ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/sotrudnik%3A/branches%3A/home%3A/dl8fcl/Fedora_18/src/gqrx-2.1_git20130708-5.2.src.rpm rpm ivh gqrx-2.1_git20130708-5.2.src.rpm #Next, let's setup Git to get the sources # cd /usr/src/redhat/BUILD mkdir gqrx-git cd gqrx-git #Get the sour code: # # 1. If this is the first time running this, use: git clone https://github.com/csete/gqrx.git gqrx.git # # or # # 2. If you are refreshing an existing download of the Git repo git pull cd gqrx.git #See what tags are available and decide on which version you want to use # git tag +----------------------------------------------------------------------+ | Which version to use? | | | | Now you need to decide if you want to run the last stable release as | | shown above in the tags or run the newest code available in Git. | | The velosity of new Gqrx releases has slowed down quite a bit in | | recent times so I would recommend to go with NEWEST CODE if you're | | willing to get newer features. If you want stable, use a tagged | | version. | +----------------------------------------------------------------------+ # Want the newest code available (tip of tree)? git checkout master or # the newest stable is v2.6 so let's check it out git checkout tags/v2.6 #If using a release version, you should show see something like: # -- # Note: checking out 'tags/v2.6'. # # You are in 'detached HEAD' state. You can look around, make experimental # changes and commit them, and you can discard any commits you make in this # state without impacting any branches by performing another checkout. # # If you want to create a new branch to retain commits you create, you may # do so (now or later) by using -b with the checkout command again. Example: # # git checkout -b new_branch_name # # HEAD is now at 7956056... Update version strings to 2.6 # -- # Determine and write down the GIT commit serial number with the command # cat .git/logs/HEAD | grep checkout # RECOMMENDED: # For v2.6, it's the second large "checkout" number from the left: # 79560565d9f36b17bc01130c49b2f69350ede2ee # For the tip of tree, you want the second large git hash number from the left: # 31a2289f5775e5b09d7f954ee1ece3f581050c2c # For 2.5.3, it's the second large "checkout" number from the left: # 8bbe051d7983187fe8958c63e1e2cc6f483427e7 # Ok, time to make the archive where the name consists of the package name, version, date and # the GIT short commit which is the first 8 characters (MSB) of the git commit code. # To build the 2.6 code, you would need to do: # cd .. ln -s gqrx.git gqrx-2.6 # Change the version, year, month, date, and 8 left-most digital of the Git checkout (MSB) tar civf /usr/src/redhat/SOURCES/gqrx-2.6-20160811git79560565.tar.bz2 gqrx-2.6/ --exclude gqrx-2.6/.git # #Optionally , delete this temp directory unless you want to keep it around to do quicker upgrades in the future cd .. rm -Rf gqrx-git Please skip to the next sub-section to keep going... # ALTERNATIVELY: To build the older stable tagged release, I would need to do: cd .. ln -s gqrx.git gqrx-2.5.3 # Change the version, year, month, date, and 8 left-most digital of the Git checkout (MSB) tar civf /usr/src/redhat/SOURCES/gqrx-2.5.3-20160307git8bbe051d.tar.bz2 gqrx-2.5.3/ --exclude gqrx-2.5.3/.git # #Optionally , delete this temp directory unless you want to keep it around to do quicker upgrades in the future cd .. rm -Rf gqrx-git #Now you have to change a few things in the GQRX spec file: # cd /usr/src/redhat/SPECS vim gqrx.spec -- Add the following lines to the TOP of the spec file, updating the various fields as needed regardless of using the TIP of tree code in Git vs a tagged stable release - I'm showing the 2.6 stable release): %global git_commit 79560565d9f36b17bc01130c49b2f69350ede2ee %global git_date 20161006 %global git_short_commit %(echo %{git_commit} | cut -c -8) %global git_suffix %{git_date}git%{git_short_commit} # git clone https://github.com/csete/gqrx.git gqrx.git # cd %%{name} # git archive --format=tar --prefix=%%{name}-%%{version}/ %%{git_commit} | \ # bzip2 > ../%%{name}-%%{version}-%%{git_suffix}.tar.bz2 Next, edit the gqrx.spec file and fill in the blanks for your checkout. For me, I have: 1. Update the top git_commit line: 79560565d9f36b17bc01130c49b2f69350ede2ee 2. Update the GIT date: 20161006 3. Update the Version: 2.6 4. Update the Release to: 1.%{git_suffix}%{?dist} 5. Update the Source line to: Source0: %{name}-%{version}-%{git_suffix}.tar.bz2 6. Update the BuildRequires lines: BuildRequires: gnuradio-devel >= 3.7.0 BuildRequires: gr-osmosdr >= 0.1.5 BuildRequires: qt5-qtbase-devel >= 5.0.0 6. In the %build section, add a new first line that has: export QTDIR="/usr/lib64/qt5" qmake-qt5 gqrx.pro -- +-------------------------------------------------------------------------------------------+ | NOTE: | | ----- | | There are various compile time options available in Gqrx via the gqrx.pro file such as | | the following. To enable the item, it will require the line to be un-#ed out | | | | - AUDIO_BACKEND=portaudio Use portaudio backend | | - CONFIG+=debug Enable debug mode | | - PREFIX=/some/prefix Installation prefix | | - BOOST_SUFFIX=-mt To link against libboost-xyz-mt (needed for pybombs) | | | | To enable any of these options, I recommend to use a patch in the RPM Spec file. | | If you have any issues with this, email me and I can give you a hand. | +-------------------------------------------------------------------------------------------+ # Ok, time to build it # # NOTE: this takes 2min to build on my dual core i5 2430M @ 2.4ghz laptop with # 4GB of RAM and a Samsung SSD # # Do NOT run this as root # # cd /usr/src/redhat/SPECS # Gqrx 2.6 with Qt-5.6.1 build time: 5 min 08 seconds on a dual core i5-2420 2.4Ghz laptop with 4GB RAM and a SSD # Gqrx 2.5.3 with Qt-4.8.4 build time: 1 min 49 seconds on a dual core i5-2420 2.4Ghz laptop with 4GB RAM and a SSD # time rpmbuild -bb --target=x86_64 gqrx.spec # Finally, install it # # DO this as root # sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/gqrx-2.6-1.20161006git79560565.el6.x86_64.rpm Skip to the next section on some thoughts on HOW to use Gqrx. ----------------------------------------------------- Legacy / Deprecated Gqrx 2.1.x Section: ----------------------------------------------------- +---------------------------------------------------------------------------------------+ | NOTE: | | ----- | | I'm keeping this these older Gqrx 2.1 x notes here for any users that might find it | | valuable when running on a stock Centos6 install (no EPEL repo, no local compiling of | | of Qt-4.8.x, etc. | +---------------------------------------------------------------------------------------+ Older Gqrx 2.1.x version that works with Centos 6.4's stock qt-4.6 libraries: # NOTE: You must use this older version of Gqrx (which has many known bugs) # cd /usr/src/redhat/SOURCES wget http://downloads.sourceforge.net/project/gqrx/2.1.148/gqrx-2.1.148-src.tar.xz cd /usr/src/redhat/BUILD tar xvf ../SOURCES/gqrx-2.1.148-src.tar.xz #Apply gqrx-2.1.148-midbutton.patch export QTDIR="/usr/lib64/qt4" cd gqrx-master /usr/lib64/qt4/bin/qmake gqrx.pro make ----------------------------------------------------- End Deprecated Section: ----------------------------------------------------- Gqrx is one of the easiest to use SDR receiver programs out there for any operating system. It does have a few quirks on how to use it so lets try to address some of those issues here. When you first load the Gqrx program, you'll need to configure it for your specific hardware. This section will try to address the following hardware: - AirSpy v2 (with and without the HF upconverter) - RTL dongle (Terratec Tstick+) or equivalent # Ok, it's installed! To run gqrx, run it as a regular user (don't be root): ./gqrx Let's start with the Airspy r2 and Airspy Mini: This is the Configure I/O window that shows the various settings:
NOTE: About 70% of the time when I first start Gqrx (not as root user) and look at the Gqrx configuration area, I don't see the "AirSpy AIRSPY" device (displayed exactly like that) device name in the pulldown. You may also see this after you initially start Gqrx and select the HW device to use. If you go back into the menus to see the HW device, you'll no longer see it. I discussed this with Alex OZ9AEC and it seems Gqrx depends on the underlying GnuRadio system to discover the various devices. Sometimes it's discovery process isn't very reliable after it runs once. it doesn't mean the hardware isn't found or not working. It's more of a display bug. If you start Gqrx with the "-r" (restart configuration) knob, the Airspy should always show up. - Be sure you ran the Airspy tests from the previous Airspy section to make sure the unit is properly detected, your system handle the full sampling rates, etc. - The Airspy SDR when used under say SDR# has several Gain modes to choose from. Evidently these are shortcuts to set the three existing gains (LNA/MIX/IF) according to a predefined table in the Airspy GROSMOSDR driver depending on your use case. Sensitivity : airspy_set_sensitivity_gain Linearity : airspy_set_linearity_gain Free (Custom): If you do want to change the gain mode, you need change this with - Device String: Type in this specific string to use the first airspy and DISABLE the Spyverter (Spyverter MUST be disconnected and removed to allow VHF+ signals to reach the Airspy) airspy=0,bias=0 - You would change the above "bias=1" to be used to power the SpyVerter from the AirSpy once it's connected inline - If you do connect and enable the Spyverter, you must also change the "LNB LO" setting on the Gqrx to -120.000000 MHz (yes, that's negative 120Mhz) to get the display to show the correct HF frequency - Input rate: This is the sampling rate of the AirSpy hardware. The R2 natives supports 2.5Mhz or 10.0Mhz. To set it to 10MHz set the value to: 10000000 If you find your system stutters at 10Mhz, you can either try running at 2.5Mhz or on the above Device string field, you can add the following (don't forget the comma): ,pack=1 - As of Feb 28, 2016, the gr-osmosdr program now supports the Airspy "pack" USB data stream packing feature. Per the notes for this feature: 25% less data is transferred across the bus and this is good for some computers with cheap USB chipsets Once you add this configuration parameter, I've found you will have to SHUTDOWN Gqrx and restart it for it to activate. This packing feature is valuable on some computers where their USB chipset cannot keep up with the 10MSPS rate without it. As mentioned in the above Airspy section, this packing feature WILL create substantially more CPU load which can create other issues (without packing, I see a load of 4.15 but with it, I see a load of 6.00). This packing feature is ONLY available if you have gr-osmosdr 1.5.0GIT version dated 2/28/16 or newer. - Decimation: Think of decimation as a form of signal ZOOM. If you set it to 2, you'll see half the signal as you did before but the processing on the remaining signals will significantly improve - Bandwidth: Leave this at the default of 2.5Mhz - LNB LO: Leave this at the default of 0.0Mhz unless you're going to use an HF upconverter. If you have the airspy SpyVerter, you would want to enable the "bias" parameter in the device string as described above and then put in a NEGATIVE 120Mhz or -120.0Mhz - RTL Dongle - No specific options added as of yet -- it just works - Once Gqrx is configured, click on the "power button" icon in Gqrx's upper left hand window corner to have it start the sampling and decoding: - To change frequencies: - You can either move the mouse pointer over the upper left corner VFO frequencies and use the mouse wheel - You can click on any signal in the upper FFT or lower waterfall areas - If you move the mouse cursor over the RED decoder line in the main FFT window, you'll see it will change to a LEFT-RIGHT cursor - If you move the mouse wheel here, it will slowly change the decode frequency - To zoom in on a frequency - Move the mouse to the bottom of the FFT area where all the frequencies are listed and the mouse pointer will change into a "hand". Now use the mouse wheel to zoom in/out - To change filter bandwidths: - If you move the mouse cursor over the RED decoder line in the main FFT window, you'll see it will change to a LEFT-RIGHT cursor and if you hold down the Control key and move the mouse wheel, it will slowly change the decode filter bandwidth. You can also move the mouse to the transition from light grey / dark grey where the cursor will change to a diagonal window. If you hold down on the LEFT mouse button and move left/right, it will also change the filter BW. - To zoom into a set of spectrum: - In the top water fall, you need to move the mouse icon to the LEFT or RIGHT of the master decoder line in RED to and then use the center mouse wheel - It's important to calibrate your SDR dongle for proper reception. The easiest way I've seen to get started is to: 1. power up our dongle for at LEAST 2hrs. If you want maximum stability, it must be completely warmed up. Temperature variations can really impact SDR's oscillators (even units that have TXCOs) 2. Tune your SDR (assuming an RTL dongle) to one of your local NOAA weather stations (see below for a local frequency): http://www.nws.noaa.gov/nwr/nwrbro.htm 3. Zoom in on the spectrum in the main waterfall until you can see the strait lines when the automated voice isn't talking 4. In the upper right window, click on the "Input Control" tab and increase/decrease the "freq. correction" until the receiver is right on the expected frequency Troubleshooting performance issues with Gqrx: - Did you run the volk_profile command as yourself while the machine isn't used? - In the upper right corner's GUI section, click the "FFT Settings" tab and reduce the "AFFT size" to say 131072 or lower. - Consider lowering the frame rate to say "15" frames per second or lower to start off with - Are you sure your machine is fast enough? It's one thing to support a narrow bandwidth from a SoftRock for say 48, 96, or even 192Khz but it's entirely something else to support 2.5Mhz from an RTL dongle or say 10Mhz from an Airspy Linrad is considered to be one of the strongest SDR applications out there for weak signal uses which is supported on both Linux and Windows. Though originally developed with weak-signal modes in mind, it also focuses on the highest sensitivity, supports full calibration, etc. Caveat: Linrad's user interface was originally designed via the legacy SVGA graphics library and follows NO modern UI conventions. It's probably one of the most cumbersome UIs I've ever used but once you learn it's UI, I can see how it could be very efficient and powerful. Ok, some dependencies: # yum install libudev-devel yum install svgalib-devel # Ok, time to get the sources and compile it cd /usr/src/redhat/SOURCES wget http://www.sm5bsz.com/linuxdsp/archive/lir03-48.tbz wget http://dg7gt.osth.de/openSUSE_10.3/src/linrad-02.47-4.1.src.rpm wget http://download.opensuse.org/repositories/hamradio/openSUSE_Tumbleweed/src/linrad-03.48-1.1.src.rpm make xlinrad64 TODO: Make this into an RPM: Ok, you've compiled it up. Here is a quick intro on how to get it working with an RTL dongle: ------------------------------------------------------------------------------- Go ahead and start the program: -- sudo pasuspender -- ./xlinrad64 The following are prompts captured from the setup of Linrad: -- WELCOME TO LINRAD This message is not an error, but an indication that setup has not yet been done. Setup file par_userint missing. Use W to create a new par_userint file after setup. Note that the following keys have a special meaning in Linrad: ESC = terminate Linrad X = Skip whatever process you are in and get one level upwards in Linrads menu three. G = Make a .gif file with a screen dump of your current screen. ----------- GLOBAL PARAMETERS SETUP ------------- (You might want to edit par_userint instead) Press N for NEWCOMER mode. Press S for normal mode. Press E for expert mode. Then press enter =>N Percentage of screen width to use(25 to 100): =>75 Percentage of screen height to use (25 to 100): =>75 Option A - Input card Option H - RTL 2832 device 0 - Terratec Sampling Speed: 2400000 Gain mode: 0 - Auto Option B - Output card Use PortAudio (recommended) - Y Device: 000 (my built-in computers soundcard) Option X - Exit to Main Menu Option W - Save configuration RTLSDR-Airband is a command line receive-only SDR program similar to say the common "rtl_fm" program which will only decode one frequency at any one time. This program can demodulate FM or AM signals for a maximum of EIGHT frequencies simultaneously! It also offers: - Supports per-slice squelch on each of the listening frequencies - Supports a scanner mode so it can listen to more frequencies then are available in the SDR's passband - Can send the demodulated audio to a PulseAudio server for various routing (on or offbox) - Can record squelched or non-squelched audio to MP3 files - Can mix different channels into other channels - On the Raspberry Pi, it can offload the FFT processing to the GPU to minimize CPU load - Uses the SoapySDR API to support a large variety of hardware beyond just RTL SDR dongles That's all well and good but what's the purpose here? Imagine with one RTL dongle and one antenna, you can pair it up with one copy of the Direwolf soft-tnc program and monitor SIX packet frequencies at the same time! My plan here is to monitor: 144.390 - common APRS frequency 144.910 - common EmComm packet frequency 145.050 - common keyboard to keyboard packet frequency 145.630 - common Winlink frequency To get started, we need to install some dependencies: #This section already assumes you've installed all the previous build tools from previous #sections including GCC, make, etc, #Lame is the MP3 encoder software #Libshout is to support Shoutcast - Centos6 seems to only support libshout2 sudo yum install lame-libs lame-devel libshout libshout-devel libvorbis libvorbis-devel libconfig fftw-devel For the moment, let's get things working with an inexpensive RTL dongle using the previously built "rtl-sdr" and "rtl-sdr-devel". This was all done in a previous section of this doc. Let's get started: #Get the sources cd /usr/src/redhat/SOURCES wget -O RTLSDR-Airband-3.0.1.tar.gz https://github.com/szpajder/RTLSDR-Airband/archive/v3.0.1.tar.gz #Get the SPEC file cd /usr/src/redhat/SPECS ..WIP.. STOP: Currently seeing the following compile error which might require FFTW v3.3.x but Centos6 only has v3.2.1 build requires: git apply makefile diff https://github.com/szpajder/RTLSDR-Airband/wiki https://github.com/khaytsus/direwolf-init nc -lup XXXX | direwolf 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 - satellite Doppler correction - frequency memories / scanner mode - ADSB aircraft information decoding Unfortunately C# is written in C# for Windows but it evidently can run under the Mono framework but it can require some serious CPU cycles: http://sdrsharp.com/ -- Echolink, IRLP, and Allstar are Voice over IP (VoIP) technologies which let you link and send amateur radio audio over the Internet to remote stations. These remote stations can be other individual stations (just a computer), a repeater, or be an entire collection of repeaters grouped together (called a reflectors). Please see the next section on "Using Echolink and IRLP via radio and Svxlink/Qtel" for more details. Back to the topic at hand, SVXLink is a suite of tools that provides: - An Echolink server to turn your station into an Echolink "link" or "repeater" depending on the configuration. This is a background daemon - Qtel: An Echolink GUI client that has similar functionality to the Windows Echolink client - The Svxlink server also has a lot of expandable features such as: - Local voice playback for voice quality testing - Local voicemail recording and playback - Announcements of Weather reports, etc - Full blown repeater controller functionality including multiple RF and Internet-linked receivers and transmitters if you really want to With all that functionality, you can have your system act as: - A pure software-only Echolink client :: No radio required - A Echolink simplex repeater :: 1 radio required - A Echolink full repeater :: 1 ore more full duplex radios required but additional radios are supported for full linking, etc A note on real radio connections: --------------------------------- - When connecting the computer to a radio, you're going to need: - A dedicated sound card to support the audio in/out with your radio. Those cheap USB soundcard on Ebay seem to work quite nice but you can also use HAM radio targeted soundcards like US Interface Navigators, Signalinks, but that overkill for this use - Depending on the sound interface you pick, you will need a PTT circuit that connects to a serial port or GPIO pin to key up the radio. An example simple circuit was previously described in the "Soundmodem - Sound-card based AX.25 packet TNC" chapter. - More sophisticated and reliable Echolink setups use the COS or Carrier Operated Squelch feature. This signal tells the software that the radio's squelch is open, possibly with the proper CTCSS/DCS tones and to start sending to the remote stations even when there might not be any audio present. This feature can be a LOT nicer and offer more natural operation than using Svxlink's VOX feature. To support COS, you might need to hack this into your legacy radio or use radios like the Kenwood v71 or D710 which has COS built in (Echolink mode). To support COS, you will need another serial line or GPIO pin to track this status. - If you are going to have multiple sound cards in your computer, you'll want to configure your system to have consistent ALSA device enumeration upon reboot. Please see the "PreSetup: ALSA deterministic sound cards" section for more details. It's worth mentioning that a lot has changed with Svxlink since my last revision of this section. The Svxlink project: - Moved from SourceForge to Github (the email lists remain on sf.net) - Moved from SVN to GIT - Moved from Autoconf to Cmake As such, this section is quite a bit different than the old version. Anyway, let's get started. First, let's get and compile the code but let's talk about the different repo versions real quick: "Maint" GIT branch: Similar to Releases, this code is considered stable but RECOMMENDED it DOES include some additional fixes and well understood features. Releases: The main releases found at https://github.com/sm0svx/svxlink/tags are stable releases. They are considered reliable but might not have all of the most recent fixes or bleeding edge features. "Master" GIT branch: This is the bleeding edge repository that is where all active development occurs. There is no guarantee that this version of Svxlink compiles or runs properly So with that in mind, we are going to use the "Maint" GIT branch here to get the best of both worlds. What we need next is an RPM spec file: ----------- RECOMMENDED: You can simply get my Svxlink SPEC file from here and skip to the ------------ next section: cd /usr/src/redhat/SPECS http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/svxlink-git-maint.spec cd /usr/src/redhat/SOURCES wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/svxlink-14.08-sms-patch.diff ---------------- NOT RECOMMENDED: To manually re-create this above SPEC file, I used the following ---------------- steps. You can redo all of this work if you wish Fedora has a modern enough package that creates a reasonable foundation for an RPM spec file but it needs fixes. Let's get started on getting and making those changes now: # Get, install the Fedora SRPM dated from November 2011, and delete the # old sources as we'll get newer ones # cd /usr/src/redhat/SRPMS wget http://kojipkgs.fedoraproject.org//packages/svxlink/11.11.1/4.fc16/src/svxlink-11.11.1-4.fc16.src.rpm rpm -ivh /usr/src/redhat/SRPMS/svxlink-11.11.1-4.fc16.src.rpm rm -f /usr/src/redhat/SOURCES/svxlink-11.11.1.tar.gz Regardless of which SPEC approach you chose above, we need to get a copy of the Svxlink source code. You can download either an official stable release, the "maint" GIT release, or the bleeding edge "master" code from the GIT repository. # GIT "maint" release (RECOMMENDED) # # In this example, I'm downloading the newest code as of 5/4/15: # cd /usr/src/redhat/SOURCES wget https://github.com/sm0svx/svxlink/archive/maint.zip --or-- # Main Release (NOT RECOMMENDED): # # Check out https://github.com/sm0svx/svxlink/tags to see what is the # current release. In this example, this will get the August 2014 # (14.08) release which is good but is missing several important fixes # that are only available in the GIT branch # cd /usr/src/redhat/SOURCES wget https://github.com/sm0svx/svxlink/archive/14.08.tar.gz Ok, next, we need the Svxlink "Heather?" audio prompt files as they aren't t included in the default archive. Lets get those now: cd /usr/src/redhat/SOURCES wget https://github.com/sm0svx/svxlink-sounds-en_US-heather/releases/download/14.08/svxlink-sounds-en_US-heather-16k-13.12.tar.bz2 Now we need to clean things up a bit to make it fit into an expected RPM. # # NOTE: For GIT users, I'm making up a new version number of 14.08.01 # to reflect it's GIT based # cd /usr/src/redhat/SOURCES unzip maint.zip #the 05 used here is to reflect the month of may mv svxlink-maint svxlink-14.08.05 tar czvf svxlink-14.08.05.tar.gz svxlink-14.08.05/ rm maint.zip # Do not delete the temporary svxlink-14.08.01 directory just yet Next, if you're using the recommended GIT approach mentioned above OR if you're using the STOCK Fedora based SPEC file, the newest Svxlink code contains version numbers that might need to be updated in your SPEC file. As such, you'll need to update the SPEC file: If you're using the original Fedora SPEC file, that Fedora spec uses some package names that are either incompatible with Centos6 or reference older version of libraries that need to be updated and changed. As such, you will need to update those packages, the version of the code in the RPM, and fix a some specific spec file issues. To properly update the spec file, first look at the various svxlink module versions specified in the src/versions file. Write down the version numbers so you can update the svxlink-git-maint.spec file. Please do NOT use the various ChangeLog files for version numbers as those version numbers are used for development ONLY and can change very quickly (and in incompatible ways). If you are modifying the original Fedora SPEC file, you need to make the other changes mentioned below: -------------------------------------------------------------------- - Run the command: less /usr/src/redhat/SOURCES/svxlink-14.08.05/src/versions and note down the newest version of the various modules. For what I see, on 5/4/15: libasync - 1.3.1 echolib - 1.3.1 qtel - 1.2.1 svxlink - 1.4.1 (this is svxlink-server) - Find the line that starts with this example: %define main_version 11.11.1 and replace it with the date and month of the currently available Main release. In this example, I'm using 14.08 and I'm adding a ".01" at the end to represent it contains MORE than just he primary release: %define main_version 14.08.05 next, Release: 4%{?dist} and replace it with Release: 1%{?dist} Next, update the Source0 line to read: Source1: http://downloads.sourceforge.net/%{name}/svxlink-sounds-en_US-heather-16k-%{version}.tar.bz2 # IGNORE this experimental patch for now - might not be required anymore # #Next, under the Source0 line, add the line to include the optional SMS notification path: # #Patch0: svxlink-14.08-sms-patch.diff Next, update the following line BuildRequires: libsigc++-devel and replace it with: BuildRequires: libsigc++20-devel Next, add a new BuildRequires line to read: BuildRequires: opus-devel >= 1.0.0 And also add a new Requires line: Requires: vorbis-tools # IGNORE this experimental patch for now - might not be required anymore #Next, under the %prep section, add: # # %setup # %patch0 -p0 Next, under the various sub-packages sections, update the version number per the effort above: #libasync Epoch: 1 Version: 1.3.1 #libasync-devel Epoch: 1 Version: 1.3.1 Requires: libasync = %{epoch}:1.3.1 Obsoletes: svxlink-server-devel < 1.4.0-1 #echolib Epoch: 1 Version: 1.3.1 #echolib-devel Version: 1.3.1 Requires: echolib = %{epoch}:1.3.1 Obsoletes: svxlink-server-devel < 1.4.0-1 #qtel Epoch: 1 Version: 1.2.1 %package -n svxlink-sounds Summary: Audio clips for Svxlink announcements Group: Applications/Communications Epoch: 1 Version: 13.08 %description -n svxlink-sounds This package contains the en_US-heather-16k generated sound clips for Svxlink server announcements, prompting, etc #svxlink-server Epoch: 1 Version: 1.4.1 Now save all those changes to the /usr/src/redhat/SPECS/svxlink-maint.spec file. Beyond these main items in the stock Fedora svxlink.spec, there are a LOT of other items that needs to be changed. That's why I recommend to NOT use the Fedora SPEC file and use mine. Please refer to my svxlink-git-maint.spec file for the other details if you want to still update the Fedora SPEC file. -- Now that you're done with the original svxlink-14.08.05 directory, let's remove it: cd .. rm -Rf /usr/src/redhat/SOURCES/svxlink-14.04.05 Now we need to install some dependencies before we can compile Svxlink: yum install libsigc++20-devel gsm-devel speex-devel opus opus-devel # ----------------------------------------------------------------------------- Ok! Finally, let's build Svxlink this for a Centos6 machine and install it: #Assuming you're using a 64bit machine: rpmbuild -bb --target=x86_64 svxlink-git-maint.spec It's time to install all the resulting RPMs: cd /usr/src/redhat/RPMS/x86_64 sudo rpm -Uvh libasync-1.3.1-1.el6.x86_64.rpm \ echolib-1.3.1-1.el6.x86_64.rpm \ qtel-1.2.1-1.el6.x86_64.rpm \ svxlink-sounds-13.08-1.el6.x86_64.rpm \ svxlink-server-1.4.1-1.el6.x86_64.rpm (Optional) You can also install the developer and debug packages if you wish: rpm -Uvh libasync-devel-1.3.1-1.el6.x86_64.rpm \ echolib-devel-1.3.1-1.el6.x86_64.rpm \ svxlink-debuginfo-14.08.05-1.el6.x86_64.rpm Upgrading from an older version of Svxlink to a newer version: -------------------------------------------------------------- If you are upgrading from an older version of Svxlink, existing Svxlink configuration files were already present. You would then see messages like: warning: /etc/svxlink/svxlink.d/ModuleEchoLink.conf created as /etc/svxlink/svxlink.d/ModuleEchoLink.conf.rpmnew When you see this, you should compare what's in the NEW configuration file vs. the old one to make sure you aren't missing any of the new functionality. To do this, use the command: diff -u /etc/svxlink/svxlink.d/ModuleEchoLink.conf /etc/svxlink/svxlink.d/ModuleEchoLink.conf.rpmnew | less - Any lines that start with a "-" are present in your original configuration file - Any lines that start with a "+" were added in the NEW configuration file It's these + lines you need to pay attention to If you use my /usr/local/sbin/start-svxlink.sh script (mentioned below), you should compare the previous Svxlink config file vs. the new one that was just installed: diff -u /etc/svxlink/svxlink-std.conf /etc/svxlink/svxlink.conf | less - Any lines that start with a "-" are present in your original configuration file - Any lines that start with a "+" were added in the NEW configuration file It's these + lines you need to pay attention to Audio connections between the radio and the computer soundcard -------------------------------------------------------------- This topic deserves some up front mention and I will also mention it before. Specifically, it's recommended to provide electrical isolation between the radio and the computer but it's not strictly required. This "isolation" can come in several forms such as using audio transformers (one on input, the other on output), opto-couplers for the PTT line. In addition to this, Echolink operation can benefit from an additional circuits tracking COS (Carrier Operated Squelch) for better operation compared to using VOX. More feature packed isolation boards offer on-board dedicated DTMF decoders for better decoding under fader, flutter, etc. Here are some sound card interfaces to give you an idea of what's out there: - Inexpensive isolation only, requires a serial port for PTT: http://www.ebay.com/itm/EASY-DIGI-Sound-Card-Interface-PSK-RTTY-SSTV-NBEMS-JT-65-PCB-KIT-/221082800840?pt=LH_DefaultDomain_0&hash=item33798fd2c8 - Sound card isolation, COS detection, DTMF decode, requires a serial port for PTT: https://www.foxdelta.com/products/foxecho.htm - Sound card isolation only, no-serial port PTT: http://www.vk2zay.net/article/161 - Additional options: http://www.echolink.org/interfaces.htm For my specific setup, I'm using a Kenwood D710 that has specific support for Echolink though it doesn't seem to have any audio isolation built in. Getting the required system details in place to start configuring Svxlink: -------------------------------------------------------------------------- - Be sure you configure the soundcard to be used by svxlink to always get the same ALSA ID. This is detailed in great detail in the previous "PreSetup: ALSA deterministic sound cards" section. - Determine which ALSA device ID you're going to use (that previous section will help you get that information) - Test that the soundcard that's going to be used for EL is working. In my setup: # Play a sound: connect up headphones to the output of the soundcard # and make sure you can hear it # # NOTE: When I first tried to use this sound device, it kept # giving me the error: # # Channels count non available # # It seems this soundcard is a MONO only playback device so # I have to use the ALSA "plug" module to convert the # stereo audio to a mono output that the soundcard would # accept # # NOTE2: This example assumes ALSA ID #3. You will need to change # this ID to fit your environment # aplay -D"plug:'hw:3,0'" /usr/share/sounds/alsa/Front_Right.wav # Record a sound (assumes you have a working microphone connected) # in 16bit mono 16Khz for 10 seconds: # # NOTE: This example assumes ALSA ID #3. You will need to change # this ID to fit your environment # arecord -D"plug:'hw:3,0'" -c 1 -d 10 -r 16000 -f S16_LE /tmp/test.wav # play back the recorded audio to make sure it a) worked, b) you # can hear it and the audio sounds reasonable: # # NOTE: This example assumes ALSA ID #3. You will need to change # this ID to fit your environment # aplay -D"plug:'hw:3,0'" /tmp/test.wav Svxlink Configuration: ---------------------- - Edit the /etc/svxlink/svxlink.conf file that comes with the RPM - For 64bit systems like mine, I needed to edit in the [Global] section,nd change the line from/to the following: MODULE_PATH=/usr/lib/svxlink to MODULE_PATH=/usr/lib64/svxlink - NOTE: This Hampacket Centos documentation doesn't touch on repeater use. As such, the "LOGICS" section defaults to "LOGICS=SimplexLogic" which assumes your putting this system on a simplex frequency. - (ONLY CHANGE if Required) As noted in the svxlink.conf manual page, Svxlink always internally works with 8k samples from your soundcard and some older cards can natively support 8k sampling but very poorly. With modern soundcards, most of them ONLY support 48k sampling. To confirm what your sound card supports, run the following commands: cat /proc/asound/cards Next, find your card from the output above and note the ALSA ID. For my card, it's ID #3. Next, issue the command: cat /proc/asound/card3/stream0 | grep -i rates Here, you should see the available sampling rates for your card. My CM109 USB card only supports: 44100 and 48000. This means that Svxlink will always default to 44100 unless asked to support. To start off, leave this sampling setting alone and see if the audio quality is ok. If the audio quality you hear or the remote site hears is poor, try changing: #CARD_SAMPLE_RATE=16000 to CARD_SAMPLE_RATE=48000 - If you plan on posting your location information into the Echolink and/or APRS systems, uncomment out the line: #LOCATION_INFO=LocationInfo to LOCATION_INFO=LocationInfo ---------- - Under the [SimplexLogic] section, change the lines from/to for the following: - Svxlink offers a lot of functionality via the MODULES feature. Some of the other modules include: - local weather report from the local airport code - HF propagation reports - Selective call By default, Svxlink enables the following modules: MODULES=ModuleHelp,ModuleParrot,ModuleEchoLink,ModuleTclVoiceMail If you don't want some of these features to be available, say the VoiceMail feature, remote them from this list - Change the CALLSIGN line to use your callsign but do NOT include say the -L suffix for simplex operation: CALLSIGN=MYCALL - You might want to change the callsign ID timers - SHORT: The default setting is 60min for the short ID (IDs every 60 minutes when the link is active and there is a live QSO). In the US, you need to have the machine ID every 10 minutes: SHORT_IDENT_INTERVAL=10 - LONG: 60min for the long ID when the system is idle. It's also used to announce any waiting svxlink voicemails, etc. If you want your system to run "low and silent, setting this to 0 disables this feature. LONG_IDENT_INTERVAL=0 - If you only want your machine to ID if there has been activity on the system, change the following line. Please note that per the svxlink.conf man page, the SHORT_IDENT_INTERVAL variable has to be greater than 0: #IDENT_ONLY_AFTER_TX=4 to IDENT_ONLY_AFTER_TX=4 - (OPTIONAL but recommended) - If you'd like to be able to RECORD any signals on the radio frequency, you need to uncomment out (remove the #s) from the line: QSO_RECORDER=8:QsoRecorder - If you do enable this recorder feature, you have to make this directory writable by the owner of svxlink process (shouldn't be root). To fix that, do the following mkdir -p /var/spool/svxlink/qso_recorder chown svxlink /var/spool/svxlink/qso_recorder - This feature can only be enabled/disabled from the top menu and not when say the Echolink module is loaded ---------- - The editing of the [RepeaterLogic] section is not necessary as we aren't using it in this section but I feel it's best to make some minimal changes to stay consistent. Please change the line from/to the following: - Change the CALLSIGN line to use your callsign but do NOT include the -L suffix: CALLSIGN=MYCALL - Svxlink offers a lot of functionality via the MODULES feature. By default, it enables: MODULES=ModuleHelp,ModuleParrot,ModuleEchoLink,ModuleTclVoiceMail If you don't want some of these features to be available, say the VoiceMail feature, remote them from this list ---------- - Under the [Macros] section, you can setup shortcuts to connect to do all kinds of common things. For example, if you wanted to create a quick method to connect to my echolink node, you could enter in: 2=EchoLink:767882# ---------- - If you enabled the QsoRecorder function above, I recommend you enable the Ogg compression feature. If you don't do this, all recordings will be saved in the WAV format which can create very large files in short order: [QsoRecorder] ENCODER_CMD=/usr/bin/oggenc -Q \"%f\" && rm \"%f\" --------- - Under the [Rx1] section, change the following to reflect your audio setup: AUDIO_DEV=alsa:plughw:0 For my setup, I'm using ALSA device #3 and thus needed: AUDIO_DEV=alsa:plughw:3,0 - VOX vs COS: ----------- The current default for svxlink is to detect that SQL is open purely by hearing loud enough signals from the radio (VOX) via the setting: SQL_DET=VOX When the audio is loud enough, for long enough, the svxlink program should show lines like: Rx1: The squelch is OPEN (1.56161) Rx1: The squelch is CLOSED (3.77363) Getting the VOX settings just right so it allows for natural human speak audio level, pauses, etc. can be pretty tricky. If you are using an device that supports COS like the Kenwood D710, your radio can actually signal when the Squelch opens with your desired PL TONE. This is a LOT more reliable and this is how most IRLP systems are setup too. To support this, you would want to change these settings to the following under the [Rx1] section: #SQL_DET=VOX SQL_DET=SERIAL # for my specific setup, I use a custom Udev-named serial port SERIAL_PORT=/dev/d710-vfo SERIAL_PIN=CTS - (optional) Support for external DTMF decoding available on some of the above mentioned Isolation boards to improve DTMF decoding with weak signals, mobile flutter, etc.. I'm personally not using one of these enabled DTMF-decoding boards so I set the following: DTMF_DEC_TYPE=INTERNAL and I commented out the line DTMF_SERIAL=/dev/ttyS0 to #DTMF_SERIAL=/dev/ttyS0 ---------- - Under the [Tx1] section, change the following to reflect your setup: AUDIO_DEV=alsa:plughw:0 for me using ALSA device #3, I needed: AUDIO_DEV=alsa:plughw:3,0 - Next, you need to set Svxlink how to key your radio. Solutions here can range from configuring VOX on your radio itself (NOT recommended even if your radio supports it) to the recommended approach of using an external PTT circuit via one of above isolation boards. The D710 natively supports PTT via the RTS serial line (non-inverted). So for my setup that I created a unique UDEV name for the D710's serial port, use the following under the [Tx1] section: PTT_TYPE=SerialPin PTT_PORT=/dev/d710-vfo PTT_PIN=RTS +------------------------------------------------------------------------------+ | Critical Issue: Improper serial port shutdown with the D710 | | | | Please see below about a critical issue with the D710 and the RTS | | serial line when not properly shutdown! | +------------------------------------------------------------------------------+ - (OPTIONAL) - Under the [LocationInfo] section, the system can locate your echolink station in the APRS system when it's running. To enable this, make the following changes: - Being in the US, I should use the North America APRS server APRS_SERVER_LIST=noam.aprs2.net:14580 - Enable the Echolink status server by removing the # STATUS_SERVER_LIST=aprs.echolink.org:5199 - Enter in your GPS coordinates. It's CRITICAL that you enter in your GPS coordinates in Degrees, Minutes, Seconds (DMS) and not Decimal format. To help you remember, the DMS format cannot be greater than "59.99". If you don't use the right format, Svxlink will error out and refuse to run. To figure out your GPS location, see the "Xastir - Configuring" section in this document in how to use GoogleMaps and then use another website to convert to DMS. For my setup, I configured: # degrees.arcminutes.arcseconds where arc values cannot be greater than # 59Degrees, Minutes, Seconds - like Delorme GPS - less accurate LON_POSITION=121.59.59W LAT_POSITION=37.20.36N NOTE: Negative LAT or LON numbers are not needed - Put in a callsign to be found as. The example callsign uses something like EL-CALLSIGN which I've never seen before but Svxlink ONLY supports this syntax today. If you try to use something like KI6ZHD-EL, it gives an error. So, I'm using: CALLSIGN=EL-KI6ZHD - The following values will need to be updated to match your desired simplex frequency, radio power, antenna used, it's installation height above average ground (HAAT), if it's omni-directional, and if you're using TONE to key up your Echolink system. +-------------------------------------------+ | IMPORTANT NOTE on choosing the FREQUENCY: | +-------------------------------------------+ NOTE1: Here in the Bay Area, there can be a a lot of people who listen and hang out on simplex. When picking a frequency to put your machine on, it's recommended to use the QSO_RECORDER feature (discussed below in a following section) with the your radio's tone-squelch (CT) turned OFF for a full day or two first. Once you have confirmed, that your chosen simplex frequency isn't used much, then go ahead and set it here. NOTE2: The use of CTCSS/DCS TONEs: If there are a LOT of echolink systems sitting on simplex frequencies and if just one other machine in my RX area was using Svxlink with the same CTCSS/DCS tones, the remote person might actually start controlling both Svxlink nodes without realizing it! The only way to better control this is via the use of CTCSS/PL TONEs or DCS codes on RX of your radio. NOTE3: If you're using an ancient radio w/o CTCSS support, Svxlink can actually support them in software. That isn't covered in this document but it's worth mentioning For me, I'm using the following details for frequency, noted power, etc -- FREQUENCY=146.595 TX_POWER=50 ANTENNA_GAIN=9 ANTENNA_HEIGHT=6m ANTENNA_DIR=-1 PATH=WIDE1-1 BEACON_INTERVAL=10 TONE=136 COMMENT=KI6ZHD Echolink running svxlink.sourceforge.net -- - Change the /etc/svxlink/svxlink.conf file's permissions to 660 and it's ownership to a non-root user: chown -R $USER /etc/svxlink/ chmod 660 /etc/svxlink/svxlink.conf - Edit the /etc/svxlink/svxlink.d/ModuleEchoLink.conf file Echolink Validation: -------------------- At this point, this document assumes you have a validated Echolink callsign for either a -L or -R node type. The whole validation process for Echolink is covered in the next section so please skip ahead and then come back to here when you're ready. - This configuration file logs your system into the Internet facing Echolink system to accept and optionally originate VoIP sessions. Make the following changes: - Change the following to reflect your callsign including the -L for simplex operation or -R for repeater operation: CALLSIGN=MYCALL-L - Change the line to reflect your unique Echolink Sysop password: PASSWORD=MyPass - One special note on the LOCATION field: -- This line has specific formatting and can ONLY be 27 characters long. The default setting is: LOCATION=[Svx] Fq, MyTown Below is what I set for my system to fit: # 123456789012345678901234567 LOCATION=[Svx]146.595 pl136.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 Once you have Svxlink compiled, installed, and configured, it's required that the network be able to send packets to it. It's really a large topic to cover as people's networks can be so different. The highlights are: 1. Most people have one, if not two or more "Internet routers" at home. The first will be a cablemodem / DSL router. On that device, you need to get into it's configuration menus and look for "Port Forwarding". Important Note: --------------- Some home routers offer both "Port Forwarding" and "Port Triggering" but: 1) These aren't the same thing and it's critical that you pick the feature where you can specify the destination INTERNAL IP address to forward the ports to like to 192.168.0.50. If the feature doesn't have that destination option, it's not the right one. Keep looking. Check out http://screenshots.portforward.com/ for a very comprehensive screen shot database of how to configure Port Forwarding on your specific hardware 2) Only configure one type of port forwarding mechanism at a time. Do not configure say Port Forwarding and Port Triggering at the same time In the configuration web menu / cli on the router device, you need to configure the following INCOMING ports to be directed to the IP address of your internal Svxlink server. In this example, say this Internal Svxlink machine would be 192.168.0.50. From the Internet, you'd portforward INCOMING: 5198/udp 5199/udp 5200/tcp As mentioned above, if your Svxlink machine is behind TWO network devices like a DSL router and a wireless router, you'll need to do this port forward TWICE (once on the ISP's modem and a second time on your Wireless router) to successfully get the traffic to your Svxlink station. The official Echolink documentation has a section on portforwarding that might be helpful to you. Give it a read. NOT REQUIRED: For completeness (but shouldn't be required except for the most strict firewalls), Svxlink makes OUTGOING 5200/tcp connections to the Echolink server. Svxlink can also need INCOMING 5210/tcp if you're linking multiple Svxlink systems using it's "remotetrx" feature. If you're only using the Echolink support within Svxlink, this port 5210 is not needed. Svxlink vs. Windows Echolink: It might be worth mentioning that Echolink 2.x for Windows and newer versions no longer require specific port forwarding but if you try to work remote Echolink stations that ARE running Echolink 1.x, you will STILL NEED to enable the port forwards. 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 $ & That's it. Now go ahead and stop and then restart Svxlink. From your second radio (HT, etc), load up the Svxlink Echolink module with a "2#" and then issue a local node ID command with "2#". At this point, you should IMMEDIATELY hear the notification sound on your local computer and fairly quickly get an SMS message! Getting a radio setup with Svxlink: ----------------------------------- - Since I'm using a D710, I needed to do the following on the radio but if you're using a different radio, find and enable the similar settings: D710 Menus ---------- IMPORTANT: - Set the Transmit Timeout (TOT) to say 5min - Menu 109 - If there is a system failure that leaves your radio keyed up for long periods of time (read below on the critical D710 serial port issue, you don't want to: A) burn out your radio's final TX amp! B) break the FCC Part97 rules You can set this to 3, 5, or 10minutes. I recommend 5. NOTE: I confirmed that the D710 does indeed stop transmitting after say 5 minutes but it does NOT indicate that the TOT timer is inhibiting TX! Bummer. You have to first stop whatever program from asserting the RTS serial line and then the radio will start transmitting again. - Turn off Automatic Power Off (APO) - Menu 516 - If the radio is idle for a long time, you don't want it to turn itself off - Set the External DATA band (external audio) to Band-B - Menu 517 - Set so the packet/APRS TNC is on the left narrow receive VFO, voice on the wider receive right VFO. - Set the detection of modulation to "SQL" from the default of "BUSY or TX" - Menu 520 as recommended by the manual - Set the External DATA band to 1200 - menu 518 - The DATA jack has separate pins for audio with the pre-emphasis enabled on the 1200baud line and no emphasis on the 9600 baud line. The Kenwood D710 "Echolink cables" only uses the 1200baud lines. Svxlink DOES have audio processing abilities to re-create the pre-emphasis / de-emphasis effect if you want to use the 9600baud line on other radios RX Frequency and Tone --------------------- As mentioned before, it's key to use a free frequency and a unique CTCSS/PL tone or DCS code to keep your system unique: - Set VFO-B to the desired frequency - I'm using 146.595 IMPORTANT: Please read below on using the QSO_RECORDER feature to make sure you're using a generally free frequency - Cycle the TONE button to display CT (Tone Squelch) - Cycle the T.SEL button to use your desired tone. I'm using 136.5 - Set the power level to the lowest setting available if you plan on using Echolink locally (say in your home, etc) - RECOMMENDED: you should save all this into a unique memory to be able recall all these settings quickly and accurately. NOTE on D710 Rig Control in Echolink mode ----------------------------------------- As previously mentioned, I have the D710 supporting Hamlib rig control with the d710-qsy.sh script posted at: http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/d710-qsy.sh Unfortunately, this script will not function when the D710 is in Echolink mode. LAME! Even out of Echolink mode, if the svxlink program is running, it's takes over use of the "PC" serial port thus Hamlib cannot gain access to the serial port. Bummer. I will be researching if the use of the D710 not in Echolink mode is good enough but I'm pretty sure you loose the COS line which is rather helpful. Adjust internals of the radio for proper operation: --------------------------------------------------- D710 specific ------------- - The D710 is a very powerful dual band radio and one of it's unique features is a specific Echolink mode changes some of it's settings. To enable Echolink mode, you need to turn off the radio, hold down the PF2 button (the last button on the right, closest to the VFO-A knob) /-------------------------------------------------------\ | +--------------------------------------------+ | | | | | | b.1 | D i s p l a y | pwr | | b.2 | | b.12| | b.3 | | b.11| | +--------------------------------------------+ | | /--\ btn btn btn btn btn PF1 PF2 /-\ /-\ | | /VFO \ 4 5 6 7 8 ^ \A/ \B/ | \ \ / | / \---------------------------------------|--------------/ | PF2 and then turn on the radio back on. You can confirm if the D710 is in EL mode if there is a little icon in between the PM and TNC display items on the far right side of the display. Once in EL mode and when a remote station is heard, the audio will be send to the computer but only if the matching CTCSS/DCS codes match will the COS line also open up and the Echolink icon will blink. - What else is Echolink mode? Per the "TM-D710-CDROM-English.pdf" file (Echolink section page 23) and from what I have determined, EL mode only does two things: a. It uses alternative audio levels for the audio "DATA" jack on the rear of the radio unit as programed in via Kenwood MCP-2A Windows program compared to the default "external TNC" levels b. It changes the behavior of the RTS/CTS lines on the PC port on the back of the radio unit from standard RS232 signals to: CTS line : TTL level : changes upon SQL and CTCSS open/close RTS line : TTL level : changes used to key up the radio +------------------------------------------------------------------------------+ | Critical Issue: Improper serial port shutdown with the D710 | | | | I consider it a major flaw that Kenwood connected the PTT | | line to the RTS line. Why? | | | | Almost all programs that use serial port (including Svxlink) will | | first initialize the serial port and assert the RTS line as part | | of standard hardware flow control. It's the right thing to do per the | | standard. Unfortunately since Kenwood chose to use this specific | | serial line for PTT when in Echolink mode, that means the D710 will key | | up the PTT and start transmitting! What's worse is that when these | | serial programs exit, almost all will leave the serial port | | initialized (RTS will still be high and PTT is still asserted on the | | D710 and will continue transmitting FOREVER. | | | | This EXACT issue happens with Svxlink if Svxlink doesn't have the right | | ALSA audio subsystem /dev/snd/ permissions! Svxlink will initialize | | the serial port, fail to initialize the ALSA system because in Centos6, | | the "audio" group in /etc/group doesn't have the "svxlink" user defined | | as being allowed and then svxlink will abort leaving the serial port | | initialized. That means the D710 is stuck transmitting! This is | | horrible and can destroy your radio's transmitter as it wasn't | | designed for 24/7 full duty FM transmission! | | | | NOTE: The Kenwood D710 does have a Transmission Timeout option that | | can save your radio in this specific situation. See above for | | setting the D710's "TOT" feature! | | | | Please see the modemtest perl script in the "Serial port troubleshooting | | and tools" section on how to un-initialize the RTS line upon a serial | | port not being being completely shutdown properly. | +------------------------------------------------------------------------------+ - GRIPE: I don't understand why Kenwood put the SQL status signal line on the "PC" port when they clearly had available pins already on the "DATA" jack! Because of these missing lines, you cannot use something like Echolink in non-EL D710 mode with the stock Kenwood PG-5H cables. You might be able to make your own Echolink cables to gain access to this cable though but it's unclear what the behavior of CTCSS squelch line would be. Read below on the "Echolink RX monitor" feature below for more details. !!!!! - NOTE2: The manual says that that the internal D710 cannot use !!!!! the internal AX.25 TNC when in Echolink mode per the "TM-D710-CDROM-English.pdf" file (Echolink section page 23). Yet the "E_TM-D710AE.book.pdf" manual, page 39 says it's should work fine. I personally am using both at the same time and don't have any problem when running the D710's internal TNC in KISS mode with use with standard packet operation (not APRS mode). If it doesn't work for you, maybe your running an old version of the D710 firmware. Internal D710 specific settings via Windows software ---------------------------------------------------- These settings are specific to the Kenwood D710. If you aren't using a D710, you can skip this section. - There are three settings on the D710 for Echolink mode that can ONLY be configured via the free Kenwood MCP-2A Windows program: - Echolink RX monitor - Echolink RX audio level - Echolink TX audio level These settings CANNOT be set via any menu item on the radio itself nor or a Linux program that I'm aware of. It's also worth noting that these Echolink settings only activated when you restart the radio into Echolink mode. NOTE: I don't know if this MCP-2A software can operate from WINE but if you know if it does / doesn't work, I'd love to get an email about it from you! See the D710 Echolink manual for more details on how to install and operate this software but the only item you absolutely need to change is: Echolink RX monitor ------------------- What this feature does is that enables the monitoring any received signal that breaks squelch with the D710's volume. What's unique is that ONLY if the signal also includes the configured CTCSS/DCS tones while the radio is in CT (tone squelch) mode, will that audio be sent out of the "DATA" jack on the back of the radio unit towards the connected computer for sending into the Echolink network Mandatory: - Before trying to use the MCP-2A software, you MUST Take the D710 out of Echolink mode via a power cycle and the PF2 key - If the D710 is in packet KISS mode, shut down your packet programs and daemons as well - Connect the D710's COM port to an available serial port on your Windows computer (for USB users, it's highly recommended to use an FTDI-based serial adapter as many problems are seen with Prolific-based units) - Configure the MCP-2A program to use: - The proper Windows-detected serial port under Setup --> COM port setting (I have to set this to COM16) - I personally must use the AUTO setting for the COM port speed. Manually setting it to say the 9600 baud speed does NOT work for me. - Have the MCP-2A connect to the D710 by clicking on Program --> "Read data from transceiver" to download it's settings from the radio to the computer. Once read, the D710 will do a soft reset but all your various settings are left intact. - Now set the radio to properly send the heard audio from the RF side to the svxlink connected computer when CTCSS/DCS is present by: Edit --> Menu --> Transmit/Receive --> Echolink RX monitor :: Set it to "Busy Only" from the default of "CTCSS/DCS" You also might need to change the the D710's Echolink RX/TX audio levels via the MCP-2A program but you won't know if you do until start doing final audio level testing. - Edit --> Data Terminal --> PR1 Output level --> For Echolink Sysop mode :: Set it from the stock setting of 3 to either to 6 to 7 (this level really depends on your echolink-attached sound card and you settings might vary) - Edit --> Data Terminal --> PKD Input Sensitivity --> For Echolink Sysop mode :: Set it from the stock setting of 2 to 5 (this level really depends on your echolink-attached sound card and you settings might vary) - Click on ok - Have the MCP-2A write these changes to the D710 by clicking on Program --> "Write data to transceiver" to upload the settings from the computer to the radio. Once complete, the radio will do a soft reset to activate the changes. - Since you're already here, you might as well goto File --> "Save As" and save a copy of all your radio's settings to a backup file on the computer just in case! - Disconnect the serial connection from the radio and re-connect it to the Linux machine - Turn off the radio and put it back into Echolink mode via the PF2 button Ok, go ahead and start up the svxlink program ONLY AS A TEST in non-background mode: sudo svxlink /usr/bin/svxlink NOTE: It's HIGHLY recommended that once full configured, you start svxlink via the start-svxlink.sh script mentioned in a later section if you use a Kenwood D710! - At that point, you should see something like the following: -- SvxLink v1.4.0 (Apr 18 2015) Copyright (C) 2003-2014 Tobias Blomberg / SM0SVX SvxLink comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it in accordance with the terms and conditions in the GNU GPL (General Public License) version 2 or later. Using configuration file: /etc/svxlink/svxlink-std.conf --- Using sample rate 48000Hz Starting logic: SimplexLogic Loading RX: Rx1 Loading TX: Tx1 Loading module "ModuleHelp" into logic "SimplexLogic" Module Help v1.0.0 starting... Loading module "ModuleParrot" into logic "SimplexLogic" Module Parrot v1.1.0 starting... Loading module "ModuleEchoLink" into logic "SimplexLogic" Module EchoLink v1.3.0 starting... Loading module "ModuleTclVoiceMail" into logic "SimplexLogic" Module Tcl v1.0.1 starting... SimplexLogic: Event handler script successfully loaded. EchoLink directory status changed to ON Connected to APRS server 207.182.41.4 on port 14580 --- EchoLink directory server message: --- EchoLink Server v2.5.9997 ECHOEC2-3: Herndon, VA USA -- NOTE: Notice that svxlink only loaded the ModuleHelp, Parrot, EchoLink, and VoiceMail modules. These modules can be disabled and many other modules enabled per "MODULES" line the the "[SimplexLogic]" section of the svxlink.conf configuration file. NOTE2: If you didn't see any messages about APRS, you have an invalid GPS configuration (check your coordinates being in DMS vs. Decimal) Unfortunately, Svxlink doesn't throw an error about this. NOTE3: You might see errors from svxlink about NOT being able to log into the Echolink servers. For example: -- EchoLink directory status changed to ON --- EchoLink directory server message: --- NOT LOGGED IN Because of a system problem, you are not currently logged in. Please wait several minutes for the server to reset. -- This is either a problem with Svxlink or the Echolink system. Svxlink will automatically retry to log in a few minutes later but alternatively, you can simply shutdown the Svxlink program with control-C and then restart it. It will almost always log you into the Echolink servers just fine the second time. Settings the radio link audio levels ------------------------------------ - Svxlink has some configuration settings to help speed this along: http://sourceforge.net/apps/trac/svxlink/wiki/InstallationInstructions#Postinstallstuff But the quick and dirty of it is: Setting the Soundcard INPUT or Microphone level ----------------------------------------------- - If you're already using other soundcard levels for HF (Fldigi), Packet radio (soundmodem), etc., you should restore those levels FIRST, then tune these Svxlink levels, and then save all the new levels together. To start off, restore all your old levels you might have had with: /sbin/alsactl restore If you receive any errors like: -- /sbin/alsactl: state_lock:125: file /etc/asound.state lock error: Permission denied /sbin/alsactl: load_state:1683: Cannot open /etc/asound.state for reading: Permission denied -- This is due to changes that have been coming in via what seems to be PulseAudio. The crux of the issue is the user running the command being unable to create the /var/lock/asound.state.lock file. Either the above "/sbin/alsactl restore" command must be run with "sudo" or the user you're running this command must be in the "lock" unix group defined in /etc/groups. If you go this latter route, you must log out of Xwindows (yes the whole thing) to pick up the new changes. - Next, open up the Linux soundcard mixer controls. On my system, I use Kmix from KDE - Find the tab for the specific sound card connected to your radio - Back in the window running svxlink, change the radio to NOT use PL/DCS tone squelch and then open up squelch level on the radio. You should see something like the following (assuming you configured Svxlink for "VOX" and not "SERIAL" (aka COS mode): -- Rx1: The squelch is OPEN (0.161287) Rx1: The squelch is CLOSED (5.85425) -- NOTE: I had originally tried doing this step with my D710 in NON-Echolink mode and saw the following: -- Rx1: The squelch is OPEN (2.93365) Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: The squelch is CLOSED (5.85425) Rx1: The squelch is OPEN (0.774545) Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: Distorsion detected! Please lower the input volume! Rx1: The squelch is CLOSED (5.89493) -- These "Distorsion detected" warning errors are due to the fact that my D710 radio was using the higher audio levels associated with the non-Echolink mode (external packet mode). When the D710 was put into in Echolink mode, the audio levels were OVERLY lowered which required me to change the hidden Echolink levels via the MCP-2A Windows program. - While those messages are still scrolling across the window, go to your preferred soundcard mixer application. I've described some of the options in the Soundmodem section. On my setup, I did used KDE's "kmixer" application for the following: - Un-check the MUTE button for Auto Gain Control - On the Microphone setting - Make sure the Capture checkbox is checked - There are two sliders on my setup - The RIGHT SLIDER is the "Mic (capture)" slider that works on this cheapy USB soundcard fob. This slider has 17 level lines on it for some strange reason! The left slider has a mouse over label of "Mic" and doesn't seem to do anything. - With the D710 in Echolink mode with the stock Echolink levels, I needed to slide that up to 100% level but I never could increase the levels to show the "distortion detected" as recommended by the svxlink documentation. Once I altered the Echolink levels as described earlier in a previous section, I COULD get the "Distorsion" warnings and then tune the system as recommended. For me, I needed to move the Kmix slider level setting to 5 of 17 (four keyboard up-arrows to get to that level). - The left "Mic" slider with much courser level markings didn't have any bearing on the Echolink volume setting. This is probably due to being a left channel of a stereo mic and that side isn't wired to the D710. Setting the Soundcard OUTPUT or "Speaker" level ----------------------------------------------- - Have your second radio (HT) turned on, set to the correct Svxlink frequency and is generally ready to receive - Open up the Sound card mixer control, select the Echolink sound card, and be prepared to change the "Speaker" level - Go to the running Svxlink program running in the foreground (not in daemon mode) and type in the key sequence: # (that's asterisk and then pound) - Svxlink should mention it's enabling TX and then start transmitting on frequency. NOTE: If you start seeing various errors, see the next section for some examples and resolutions. Listen to the quality of the audio on the second radio (HT) and adjust the "Speaker" mixer level to have full volume without any distortion. I recommend you move the volume slider all the way down and slowly work it back up until a) the volume stops getting louder and b) the audio doesn't start to distort. NOTE: When I initially tried out Echolink mode on the D710, a volume level of 100% (11/11) was pretty good. Once I changed the internal D710 Echolink Receive sensitivity level to a 5, I needed to adjust the volume to about 5% (2/11). That is 16 keyboard up-arrow presses to get there. - Once you're happy with the levels, save them with: /sbin/alsactl store NOTE: If you see any errors with this command, please see the above "alsactl restore" section Ok, you should be all setup now! You now might consider using my start-svxlink.sh script to start/stop Svxlink. It's mentioned in the next section. Testing remote connectivity from an Internet-connected Echolink system ---------------------------------------------------------------------- - From a properly configured remote Echolink computer or Smartphone, look up your callsign with the -L suffix and see if it can log in. In this example, I'm connecting as KI6ZHD (no suffix) from my Echolink app on my Android phone into KI6ZHD-L and then I disconnect: -- Spurious audio packet received from 68.178.200.136 Incoming EchoLink connection from KI6ZHD (David) at 68.178.200.136 Spurious audio packet received from 68.178.200.136 Incoming EchoLink connection from KI6ZHD (David) at 68.178.200.136 --- EchoLink directory server message: --- EchoLink Server v2.5.9997 ECHOEC2-3: Herndon, VA USA Incoming EchoLink connection from KI6ZHD (David) at 68.178.200.136 Activating module EchoLink... KI6ZHD: Accepting connection. EchoLink ID is 485085... KI6ZHD: EchoLink QSO state changed to CONNECTED --- EchoLink info message received from KI6ZHD --- Station KI6ZHD David - Santa Clara, CA Santa Clara, CA KI6ZHD is running EchoLink for Android on a Motorola DROID2, with Android version 2.3.4. Tx1: Turning the transmitter ON Tx1: Turning the transmitter OFF KI6ZHD: EchoLink QSO state changed to BYE_RECEIVED KI6ZHD: EchoLink QSO state changed to DISCONNECTED -- Notice above that the Svxlink program gets the remote client's detail from the Echolink server and then it keys up the radio and then plays back audio giving the remote station status details (see below what it would send). NOTE: If your radio doesn't start transmitting, make sure you have configured the svxlink.conf file correctly and/or the PTT circuit is wired correctly. For D710 users, you must put the radio into EchoLink mode for PTT on the PC port to function using the Kenwood Echolink cables (documented above) NOTE2: When you first installed the svxlink RPM package and did NOT create the required directory and symbolic link for the audio files, you'll see the following error messages: -- WARNING: Could not find audio clip "activating" in context "Default" WARNING: Could not find audio clip "name" in context "EchoLink" WARNING: Could not find audio clip "connected" in context "EchoLink" WARNING: Could not find audio clip "phonetic_k" in context "Default" WARNING: Could not find audio clip "phonetic_i" in context "Default" WARNING: Could not find audio clip "phonetic_6" in context "Default" WARNING: Could not find audio clip "phonetic_z" in context "Default" WARNING: Could not find audio clip "phonetic_h" in context "Default" WARNING: Could not find audio clip "phonetic_d" in context "Default" WARNING: Could not find audio clip "greeting" in context "EchoLink" -- Please read back in the above Svxlink installation section on how to create the mandatory symlink (this has also changed for newer versions of Svxlink that uses 16k samples) - Echolink testing via a local radio link (a second HT radio) ------------------------------------------------------------ - Setup another radio (say an HT with DTMF buttons on it) to use the same frequency, and tone as your svxlink radio setup) - Listen to the frequency for some time and ensure that it's not in use. - Key up the HT, verbally call out your callsign to ID and say something like "KI6ZHD, controlling". - Check the svxlink STDOUT messages and confirm the svxlink program should output lines like: -- Rx1: The squelch is OPEN (0.774545) Rx1: The squelch is CLOSED (5.85425) -- - Good! Ok, lets do some more TX tests: - Key up the HT radio, verbally call out your callsign to ID and state your intentions. For me, I would do a "This is KI6ZHD, controlling an echolink LINK node". Then then press: "" and then "#" (or "#") --> The svxlink system should make an announcement about the configured callsign, system's time, the configured PL tone, and a mention of the help system. The audio should be very clear, understandable, and not distorted in any way. If you don't have all of those data points, re-check the audio levels on the sound card and possible the radio too. - Next, lets try some longer audio: "0#" --> HELP: To get more audio out of the system for better tuning, try the svxlink help. The system should play back the help audio for the specific svxlink module enabled (0 modulehelp, 1 parrot, or 2 echolink). Enter in "#" to exit help. - Now lets do some combo RX/TX tests. Key up the second radio, and issue the following DTMF command and then release the PTT: "1#" --> PARROT mode: The svxlink system will hear and then playback the heard audio from you. This is very helpful for tuning the audio levels. - At this point, key up the second radio again and talk into it's microphone with a normal voice level and talk for a little bit. Once done, release the PTT. At that point, the Svxlink program will playback the recorded audio. While your listening to this, you might want to make additional soundcard mixer adjustments to get the audio just right. - Once you're done with the Parrot mode, again key up the second radio and simply issue the "#" DTMF tone to end the Parrot mode. Testing with the Echolink Test Server: -------------------------------------- - Ok, last step! Let's check your end-to-end VoIP connectivity to the Echolink Test server. Please note that the Svxlink DTMF commands are a little different than the standard Echolink DTMF commands. That's ok and it's also a LOT more powerful! 1. Key up the second HT radio, verbally call out your callsign to ID and state your intentions. For me, I would do a "This is KI6ZHD, controlling an echolink LINK node" 2. Activate the Echolink module by keying up the radio and while keyed, enter in the following DTMF tones: 2# and then let go of the PTT. The Svxlink program should tell you that the Echolink module has been loaded. 3. To confirm your configured Echolink node number, again issue the DTMF tones: 2# and the svxlink program should announce your Echolink node number. NOTE: If you also enabled my Svxlink patches, you should have heard a audio sound on the default sound system (my laptop speakers in this example) AND you should have received an SMS text message on your configured cellphone number 4. To confirm if any remote stations just happen to be already connected to your station, key up the radio and issue the DTMF tones: 1# and the svxlink program should announce how many stations are connected to your system. 5. So let's connect the station to the official Echolink TEST server and see how we sound. Key up the radio and enter the following DTMF tones: 9999# and then let go of the PTT. The Svxlink program should link up to the Echolink server and then the remote Echolink system should announce you that you're connected in a very clear, crisp, and non-distorted voice. NOTE: If you also enabled my Svxlink patches, you should have heard a audio sound on the default sound system (my laptop speakers in this example) AND you should have received an SMS text message on your configured cellphone number - At this point, key up the radio and speak into the microphone just like you did before for the local test. Once done, unkey the radio and the Echolink system should play back what you said. Confirm that the audio sounds good. - The audio levels should be good as we already tested it locally. If the levels are wrong (too low, too high, etc), re-do your testing of the local levels as described earlier in this doc - If the audio is garbled, it's most likely an Internet upload/ download issue. We can't cover that in this document but feel free to email me if you need some help 7. Once complete with your Echolink "ECHO" testing, key up the second radio and while keyed, enter in the "#" DTMF key. This will log you out from the remote Echolink TEST server. If you're done with Echolink all together, again, go ahead and key up the second radio and issue the DTMF "#" command. At this point, the Svxlink echolink module will be unloaded. If you don't use the system for a while, the Echolink module will automatically get unloaded and the svxlink system will make an announcement as of such. Saving your new Soundcard audio levels -------------------------------------- As mentioned in great detail in the "Soundmodem - Setting the right audio levels" section above for packet radio stuff, you can use the command: /sbin/alsactl save NOTE: If you see any errors with this command, please see the above "alsactl restore" section to save all of these soundcard levels for both your svxlink soundcard levels but also for all your other soundcards as well. Fine tuning the Svxlink Configuration for VOX users: ---------------------------------------------------- - If you are using VOX in your setup, you're probably going to need to do some fine tuning to get it working just right. The parameters in the /etc/svxlink/svxlink.conf file will really depend on your specific radio, your soundcard, etc. but here are some of the values I played with: [Rx1] #default is 0 sql_start_delay=50 #default is 2000 vox_hangtime=2500 #Minimum input voice volume factor to trip VOX - default is 20 vox_Filter depth = 15 #default is 1000 vox threshhold = 800 As mentioned in the "Critical Issue: Improper serial port shutdown with the D710" note above (go read it if you haven't already), the design of the Kenwood D710 in Echolink lends itself to leaving the radio always keyed!! I've submitted a bug report about this issue to the Svxlink folk but until then, please consider using the "start-svxlink.sh" and recovery script located at: http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/start-svxlink.sh This script also requires the following other scripts: -- http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/modemtest-reset-serialport.pl http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/enable-disable-sleep.sh This start-svxlink.sh script does the following: - Ensures that if Svxlink crashes when it's transmitting, it resets the PTT signal so the radio isn't left transmitting. This uses a modified version of the modemtest-reset-serialport.pl script as part of the "perl-Device-SerialPort" package which is not included with Svxlink. - Restores saved soundcard volume levels for consistent audio levels - Verifies that the ALSA audio system has the right permissions for the svxlink user to initialize it - Disables your computer from going to sleep for 24/7 operation when starting and re-enables sleep when Svxlink is shutdown - Runs Svxlink in the foreground under a screen session so you can monitor the logs, see what users are sending in the Echolink chat, etc - Selects different svxlink config files to be loaded at start to send different descriptions to the Echolink servers and APRS-IS objects You can get it here: http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/start-svxlink.sh To use the script, you have to do the following: 1. Put the script into /usr/local/sbin 2. Edit the script to use your specific system settings (executing username, etc) 3. Rename the stock Svxlink executable so there is NO confusion of how to start svxlink mv /usr/bin/svxlink /usr/bin/svxlink.bin 4. Move your svxlink.conf file to point to a new file mv /etc/svxlink/svxlink.conf /etc/svxlink/svxlink-std.conf 5. Give things a manual test with running: sudo -u svxlink /usr/bin/svxlink.bin --config /etc/svxlink/svxlink-std.conf 6. If things work fine here, you'll just want to run Svxlink in the future with: /usr/local/sbin/start-svxlink.sh It might be worth showing a quick cheat-sheet of other Svxlink commands that are available: ------------------ Enabling various modules ------------------------ 0# - Help 1# - Parrot 2# - Echolink 3# - Svxlink voicemail QSO Recorder (if enabled in the svxlink.conf file ------------------------------------------------- 81# - Enables the svxlink QSO recorder. When the system detects that SQL is open, it will record a WAV file to the /var/spool/svxlink/qso_recorder/ directory. Read below for more details on this feature and how to play the files. 80# - Disables the svxlink QSO recorder User Defined Macros ------------------- D1# - Executes the MACRO section in the svxlink.conf file. Automatically loads the Echolink module and connects to the Echolink Test server D2# - Per the example above, load the echolink module and connect to KI6ZHD-L's node if logged in Example steps to connect to the EchoTest system (assuming it's fully running) ----------------------------------------------------------------------------- Step #1 - tune your second radio (HT, etc) to your Svxlink station's chosen frequency (see the next section for recommendations on how to pick a frequency and PL) Step #2 - Listen to the frequency for a period of time to make sure the frequency is free. If it is, now key up your radio (PTT) and announce that your using this frequency the system. For example, I would say: "Is this frequency in use? <pause>KI6ZHD controlling" Step #3 - (optional) key up your HT's radio (PTT) and punch in and then # and then release PTT. You should hear the Svxlink station announce itself Step #4 - Enable the Echolink mode by entering PTT + 2 + # + ReleasePTT Step #5 - Connect to the EchoTest node by using PTT + 9999 + # + ReleasePTT. At that point, the Svxlink station will try to connect over the Internet to the EchoTest station. Assuming that works, the Svxilnk system will announce the connection was successful and then the remote station will most likely announce itself as well Step #6 - Key up your HT (PTT), talk into the radio as usual, and then release PTT. At that point, your voice will be played back to you from the remote EchoTest server. Talk as much as you want Step #7 - To disconnect from the EchoTest node, you would use PTT + # + ReleasePTT Step #8 - key up your radio (PTT) and announce that your done using the frequency. For example, I would say "KI6ZHD clear in using this frequency" Picking a Simplex frequency to operate Svxlink on QSO_RECORDER: --------------------------------------------------------------- As previously mentioned, a lot of HAMs in your area might camp out on a particular simplex frequency and "claim it as their own". Yes, we all know that they don't own the frequency but if they have been using that frequency for their own nets, etc for a long time, it's probably NOT good to put your Svxlink system on that frequency. To avoid any conflicts, the svxlink QSO_RECORDER feature can really help you here. What you should do is the following: 1. Disable tone squelch on your radio ("CT" on the D710) so that all signals will be recorded 2. Either via a second radio or on the svxlink STDIN window, issue the DTMF command: 81# The svxlink program will announce that the QSO_RECORDER feature has been enabled. NOTE: Please note that the QSO recorder can ONLY be enabled or disabled from the top level. It cannot be enabled or disabled if say the Echolink module is loaded. 3. The first time the squelch is broken, svxlink will create a timestamped file in the /var/spool/svxlink/qso_recorder directory such as: tmp_121010090933.wav Each additional time the squelch is broken, the audio will be recorded and appended to the file. All svxlink announcements will NOT be recorded. 4. Once you're done with the recordings, issue the DTMF command: 80# Which will disable the QSO recording. At that point the temporary file will be renamed to reflect a final name with start and stop timestamps. For my example: from: tmp_121010090933.wav renamed to: qsorec_121010090933_121010093615.wav 5. Don't forget to re-enable Tone Squelch (CT) on your radio to avoid false squelch openings for normal operation 6. To listen to these recordings, I had to use a a similar elaborate command when used to test the Svxlink sound card. To play my specific QSO file back to the built-in sound-card, I used the following command: aplay -D"plug:'hw:0,0'" -c 1 -f S16_LE /var/spool/svxlink/qso_recorder/qsorec_121010090933_121010093615.wav NOTE: WAV files get big FAST so watch them. If you want to keep recordings around for a long time, consider compressing them with say an MP3 encoder such as "lame". Feel free to email me if you need help with Lame. Notes about Svxlink that might interest you, possible bugs found, etc. ---------------------------------------------------------------------- Changing the automated voice prompts ------------------------------------ - If you ever want to edit the Svxlink audio prompts (I didn't like the length of the Echolink connected prompt), I used Audacity for Linux to change the file as I deemed fit (email me if you want a copy). To save the file, it's a little complicated since Svxlink only uses 8Khz files. Once edited, select - File --> Export - Name the file (say /tmp/greeting16.wav ) - Change the file format to "Other uncompressed files" - Click on Options - Header: WAV (microsoft) - Encoding: Signed 16bit PCM - Open a shell and goto /tmp - Convert the 16bit WAV file to an 8bit WAV file sox -c 1 -b 16 -e signed-integer greeting16.wav -r 8000 greeting.wav - Backup the old file and put in the new one: mv /usr/share/svxlink/sounds/en_US/EchoLink/greeting.wav \ /usr/share/svxlink/sounds/en_US/EchoLink/greeting.wav.orig mv /tmp/greeting.wav \ /usr/share/svxlink/sounds/en_US/EchoLink/greeting.wav To Add to the doc: ------------------ - Svxlinkwrapper - A python wrapper script that improves on svxlink system logging, etc. http://guysoft.wordpress.com/2012/05/17/svxlinkwrapper/ Linux Power management ---------------------- - One additional thing you will need to consider is if you have power management enabled on your computer. If the computer is set to suspend due to inactivity, this will interrupt Echolink operation. Consider looking at the power management management function in the packetrig.sh script for ideas. Possible Svxlink Bugs: ---------------------- - If the ALSA sound card ID as configured in svxlink.conf is wrong and "serial" RX detection is enabled, when you start up the svxlink program, it will key up the D710's radio transmitter, exit with an error. What's worse is that it leaves the radio keyed up with no way to stop it from transmitting other than turning it off or running a special program! -- Starting logic: SimplexLogic ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card ALSA lib pcm_hw.c:1401:(_snd_pcm_hw_open) Invalid value for card ERROR: Open capture audio device failed: No such file or directory Error: Could not open audio device for receiver "Rx1" ERROR: Could not initialize RX "Rx1" ERROR: Could not initialize Logic object "SimplexLogic". Skipping... ERROR: No logics available. Bailing out... -- Please see the note on the start-svxlink.sh script to work around this issue. - The Fedora svxlink.spec file doesn't set secure file permissions on the configuration file: chmod 660 /etc/svxlink/svxlink.d/ModuleEchoLink.conf chown -R svxlink.daemon /etc/svxlink/ chown svxlink.daemon /var/spool/svxlink/qso_recorder - The Fedora /etc/rc.d/init.d/svxlink init script seems to be broken and svxlink won't start -- [fix me] - If there is an error in the APRS GPS coordinates (user configured Decimal vs. DMS coordinates), it won't throw an error or warning though it should Future Feature requests for Svxlink: ------------------------------------ - Support security prefix DTMF tones for all svxlink commands - Ability to remap svxlink DTMF buttons to letters to emulate the official Echolink key layout (Kenwood D710 mic) - Be able to play svxlink announcements out an additional soundcard to monitor what's being said instead of having to need a second radio. Maybe if PulseAudio was supported, we could use it's "monitor" feature. It sounds like this might already be possible by modifying some specific svxlink shell scripts - Have Qtel be able to directly interact with Svxlink to allow for browsing of other stations, connect the svxlink system to the chosen remote stations, etc - Have QSO monitor annotate in the wav file what's going on, squelch open, DTMF x, etc. - Support a simple way to redefine all DTMF codes to say be identical with the official Echolink program (73s to disconnect vs. using #, etc.) - possibly solved with svxlink_wrapper? - Time stamp svxlink STDOUT lines when events occur - Be able to change the APRS symbol via the config file - Support HUPing the svxlink process to reload the config w/o disconnecting from the Echolink server, etc. - The 8# command should not give an error, it should get better help about using 80# and 81# instead - Have the system be able to announce the use of DCS codes and not just CTCSS PL tones - Have a "TX inhibit" command on the STDOUT console so that the system will never transmit until turned off. Good to have when say I do a 80# and then 81# to create a new qso monitor wav file, etc. - 10/26/12 - Enabling QSO_RECORDER is not logged in STDOUT - 10/26/12 - When connecting from an Android Echolink client - 10/26/12 - If svxlink is run under the svxlink user but that user doesn't have a home directory, you will see errors like the following. The solution is to create a proper home directory for the svxlink user. My spec file has been updated to reflect that ERROR: Unable to handle event: EchoLink::remote_greeting KI6ZHD (Could not send the message. /sent: Permission denied (errno = 13)) No protocol specified XOpenDisplay() failed Home directory / not ours. W: core-util.c: Failed to open configuration file '//.pulse//daemon.conf': Permission denied W: daemon-conf.c: Failed to open configuration file: Permission denied ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused /usr/bin/play formats: can't open output file `default': cannot open audio device 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! 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. 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 publicly posted on the Echolink/IRLP website. For example, see the bottom of this IRLP status page: http://status.irlp.net/?nodeid=3246 Alternatively, those codes might be posted on the repeater/ham club's website. If not posted, the codes might be reserved for members only. Once you have the controlling EchoIRLP codes, give it a try! NOTE: Though most Echolink enabled nodes and links usually uses the same standardized DTMF codes, IRLP doesn't have as much standardization. As such for IRLP, you need to look at the bottom of the IRLP status web page for a given IRLP node to see what the codes are (if they are given). If nothing is shown, you need to look at the repeater's website and see if it's there (very common for open repeaters). If not, you need to contact the repeater's trustee to get the codes. +------------------------------------------------------------------------------------------+ | NOTE#2: Below is the generic commands for Echolink and IRLP. These don't nessisarily | | match up with the commands required by Svxlink. It's also important to note | | that some Echolink and IRLP stations change their commands, access codes, etc | | to be "unique". You'll need to contact that trustee of that station to | | understand what those different commands, access codes, etc are | +------------------------------------------------------------------------------------------+ Some common Echolink codes include the following and you can find more examples at http://www.echolink.org/Help/dtmf_functions.htm : 2+# - SVXlink specific command to enable Echolink Mode node-number+# - connects to the remote Echolink node number one example is the 9999 node number which is the Echolink "Echotest" node that will replay anything you say at it (similar to Svxlink's local "parrot" mode) C+callsign+# - connects to the remote Echolink station by callsign. To enter a callsign from the DTMF keypad, you have to press two digits for each letter and a number which assumes your DTMF buttons on your radio conform to: button 1 - Q,Z button 6 - M,N,O button 2 - A,B,C button 7 - P,R,S button 3 - D,E,F button 8 - T,U,V button 4 - G,H,I button 9 - W,X,Y button 5 - J,K,L NOTE: Svxlink uses a different key to letter layout - The first digit is the button on which the letter appears (using 1 for Q and Z - see letter to button layout above) - the second digit is 1, 2, or 3, to indicate which letter is being entered. To enter a digit, press the digit followed by 0. When finished, end with the pound key (#). - For example to connect to my station by CALLSIGN, you would enter: C K I 6 Z H D # -- + -- -- -- -- -- -- + -- 23 52 43 60 12 42 31 # # - Disconnects the last connected Internet-facing Echolink station. If there are other stations connected to your Echolink station, their connection won't be affected ## - Disconnects ALL connected Internet-facing Echolink stations --- 00 - Connect to any random node regardless of type 01 - Connect to any random -L LINK or -R REPEATER node type 02 - Connect to any random conference 03 - Connect to any random single user (non-L or -R) node type --- 001 - Connect to a random FAVORITE-configured node regardless of type. Favorites are selected either on official Windows Echolink or Android/Ipod clients. 011 - Connect to a random FAVORITE-configured random -L LINK or -R REPEATER node type 021 - Connect to a random FAVORITE-configured conference 031 - Connect to a random FAVORITE single user (non-L or -R) node type --- 08 - Announces the currently connected Internet-facing Echolink station 09 - Reconnects to the last Echolink node that connected to this station - Plays the Echolink information message 07+callsign+# - Fetches the status of the remote Echolink station by callsign 06+node-number - Fetches the status of the remote Echolink station by Echolink node number 73 - Disconnect the local system from the remote EchoIRLP node Don't forget that once you're done with the QSO, unlink from the remote destination with the "73" code. 2. Using Echolink computer software only: -------------------------------------- Installing the free Echolink is simple (available on Windows, iPhone, Android). Other non-official solutions are available as well like EchoMac for Apple computers, Svxlink+Qtel for and Linux, etc. The only other things you need is an Internet connection, a headset (for better TX audio), and valid Echolink account. 3. Echolink Smartphones: A free Echolink application is available on the iPhone and Android platforms. All you have to do is enter the respective phone's App Store and install it. Once installed, you need to enter your validated callsign and password (as mentioned above). Once configured, there isn't any need for a headset as your phone was specifically designed to work with microphones. BTW, the speakerphone function on Smartphones works well and makes using Echolink very VERY simple to use this way. So what is Dstar? Is it voice? Is it Data? The answer is it's both. I always describe Dstar to people as: Dstar is a technology first created by the JARL (Japanese Amateur Radio League) that sends digital voice and data at the same time is Dstar frames. The voice can work for local simplex or repeater communications or it can be linked to the Internet to cluster repeaters or connect to reflectors just like what you can do with Echolink or IRLP. Dstar 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 Dstar 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 Dstar still sounds 100%. 4. The DVSI company makes these chips available to HAM radio for ea and there a lot of homebrew kits coming out to create your own Dstar compatible system for pretty cheap! KJ6VU, a local linked analog repeater owner (and Dstar 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? Dstar. 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!" Here are some links for learning more about Dstar: 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 Dstar 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 Dstar 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 DStar Callsign Servers: US Trust server (K5TIT), Robin Cutshaw (AA4RC), Dutchstar 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 Dstar blog. This chronological blog also illuminates how Dstar has fundamentally changed over the years from when it first debuted from Japan to where the Amateur community is taking it: http://napasars.net/2011/dstar-blog-2/ - Some additional points that might be helpful as well: - How to get consistent radio memories across radios both digital and analog: http://chirp.danplanet.com/ - Build your data own cable for both radio memories and accessing the DV-DD data.. and save yourself from a pointless 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 Dstar'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! I had heard about D-RATS some time ago as a form of a digital messaging system for the slow data side of the DStar DV mode. What I've come to realize the following and they are NOT what I expected: - D-RATS can work strictly over the Internet (no radio required) if you want - D-RATS can use packet radio (custom KISS traffic or true AX.25 formatted) --> Seems it cannot use Linux's native AX.25 stack today - D-RATS can also use the Dstar DV data network - D-RATS offers a POP email client (Internet based) - D-RATS offers a Winlink internet and VHF / AX.25 packet email client - D-RATS offers a file server for serving files - D-RATS can create Internet to RF relay systems - D-RATS is multi-platform and runs on Linux, Max, Windows, etc It's truly a very slick software package that the creator of CHIRP has created and all this comes in just v0.3.3! Check out the following presentation for more details: http://www.d-rats.com/download/doc/D-RATS-TCARC-2010.pdf Here are some screen captures of it in action: The chat view where you can see who's on, chat with them, etc:

Able to send/receive POP/SMTP email (TLS-supported), Winlink, ICS213/NTS forms, etc:

Send and receive files:
Before we get started, it's worth mentioning that D-RATS developement stopped on 4/17/2014 by the primary developer Dan Smith. The program does continue to function just fine but there aren't any newer releases of code. There is a glimer of hope as a new fork seems to be starting up that might get things going again: https://github.com/DigitalHERMES/d-rats the above URL is the same as https://github.com/rafael2k/d-rats #Another project that's now Stale but might have some interesting fixes in it # https://github.com/maurizioandreotti/D-Rats-0.3.ev We will all have to Watch that space and see if it makes progress. Some new coding effort is badly needed as some dependenies like pygtk have been deprecated and Python2 is getting pretty old. Assuming you're ok with that, let's get it installed! As usual, we have some dependencies that need to be installed first but if you've installed CHIRP from the previous chapter, you should be good to go: yum install pygtk2 libxml2-python libxslt-python Two unique packages to D-Rats is libxslt-python and python-feedparser but both are easily installed: - From the Centos Repo: yum install libxslt-python - From the EPEL repo: yum install python-feedparser Next, I'd recommend to install the last development version of D-rats dated 4/17/14 as found at http://d-rats.com/hg/ . This was http://dev.d-rats.com/drats_daily/ but this doesn't seem to be working as of 9/21/16). This daily versions of code is reliable and has the full feature set. NOTE: I have not made this an RPM of this package just yet but it's in the plan cd /usr/src/redhat/SOURCES #This is broken # wget http://dev.d-rats.com/drats_daily/daily-02232012/d-rats-daily-02232012.tar.gz # #This works wget http://d-rats.com/hg/hgwebdir.cgi/d-rats.hg/archive/tip.tar.gz mv d-rats-hg-aa9e84e65b2a.tar.gz d-rats-daily-04172014.tar.gz cd /usr/src/redhat/BUILD/ tar xzvf ../SOURCES/d-rats-daily-04172014.tar.gz mv d-rats-hg-aa9e84e65b2a d-rats-daily-04172014 ln -s d-rats-daily-04172014 d-rats-daily Ok, that's IT! Since it's a python program, there isn't anything to compile, etc. Let's start it up and configure it: cd /usr/src/BUILD/D-rats/d-rats-daily #As a NON-root user, run the following on a Xwindows'ed environment: ./d-rats At this point, you should be prompted that since you're a new user, you need to configure the application. Fill out the following prompts as follows which includes some recommendations from Paul, N3TSZ: +--> Preferences | | | +--> Callsign (don't use any SSIDs here, just your call like KI6ZHD) | +--> Name (your full name) | +--> Sign-on/off msg (customize it a bit if you like) | | | +--> Paths | | +--> File Transfer path: /var/ftp/pub (this can be any path you wish) | | (make sure that directory is writable) | | (with say a chmod 777) | | | +--> GPS | | +--> (Change your Lat/Long/Alt and comment if you so wish) | | +--> APRS symbol (See http://db.aprsworld.net/datamart/symbol-count.php) | | | +--> Appearance | | +--> Notice RegEx: (put in your callsign here so you'll get | | | a notice when your callsign is used) | | | | | +--> Ignore RegEx: [QST] (put reoccurring QSTs in a unique tab) | | | +--> Chat | | +--> Scrollback lines: 9999 | | | +--> Messages | +--> Enable: Automatically Forward Messages | +--> Queue flush interval: 30 | +--> Station TTL: 600 | +--> My Winlink SSID: 10 | +--> Radio | +--> Port: net:ref-d-rats.com:9000 NOTE: By default, only Internet based | | connections are allowed on port | | 9000. For RF connections, use | | port 9001. | | | +--> For Dstar radio connections, use the SERIAL connection (more to come | | here -- add udev serial device :: IC80AD runs at 9600 baud | | | +--> For packet radio stuff, it's not clear how it works since it's AX.25 | support asks for a serial port which it shouldn't :: researching | but I suspect D-Rats cannot use Linux's AX.25 stack Click on OK Now, once everything is configured for D-Rats, do the following: 1. Click on the Chat tab 2. Goto File --> Ping Station 3. Type in the Station: CQCQCQ 4. Select the port RAT 5. Hit OK That above step sends out broadcast ping which will populate your callsign list with everyone that's currently logged into the the default "RAT:9000" ratflector. Next, get some key files: 1. Click on the Files tab 2. In the far-right column, make sure that K2TJW is shown 3. In the middle-right column in the "Station" field, type in K2TJW and click on the connect icon 4. Highlight the "ratflector-list-03022012.txt" and download it NOTE: D-rats does not download files anything faster than what a standard Dstar radio's DV-Voice data can support: 999Bytes/sec 5. Download the Ratflector list 03022012.txt file That's it for now. I plan on setting up a D-Rats Internet to RF gateway and ratflector in the future! PS. If you have a local Winlink system available to you, try sending a "email" form message to yourself with one KEY point: Destination Callsign : Add the prefix "WL2K: to send a Winlink message. You'll soon notice in the "Messages" tab that the message just showed up. Fast, nothing to configure, etc. Wow.. its that's simple! +---------------------------+ | To be updated for Centos6 | +---------------------------+ I'm still working on this one but the DSD toolset seems very robust to decode: P25 Phase 1 ProVoice EDACS Digital voice X2-TDMA - Motorola public safety TDMA system with P25 style signaling (mostly based on DMR) DMR/MOTOTRBO - Digital Mobile Radio standard NXDN - 9600 baud (12.5 kHz) NEXEDGE and 4800 baud (6.25 kHz) NEXEDGE/IDAS C4FM modulation GMSK modulation (including GMSK and other filtered 2/4 level FSK) QPSK modulation (sometimes marketed as "LSM") The following formats are currently under investigation or development: P25 Phase 2 - standard not finalized yet, vocoder is supported by mbelib OpenSky - four slot format vocoder may be supported by mbelib. Will not be supportable if it is determined that voice encryption is not optional D-STAR - Voice frames recognized, vocoder not supported by mbelib. May be possible to pass voice bits to DVDongle. http://wiki.radioreference.com/index.php/DSD --------------------------------- - Download the newest code (you have to wait 45 seconds per file to download it) - The files are double-wrapped so you'll have to un-tar and then un-tgz the files: #I will make an RPM for this shortly mkdir /usr/src/archive/DSD cd /usr/src/archive/DSD tar xvf mbelib-1.2.3-src.tar tar xzvf mbelib-1.2.3.tar.gz tar xvf dsd-1.4.1-src.tar tar xzvf dsd-1.4.1.tar.gz cd mbelib-1.2.3 make make install #Make sure the LDPATH was updated /sbin/ldconfig -p | grep mbe cd ../dsd-1.4.1 make make install To test this system, I did a few things: - Installed audacity (a great sound editing and viewing tool): yum install audacity - Connected the output of the Kenwood D710 VFO-B (external TNC) to the Mic Input of the laptop (AC97) - D710: - Tuned the VFO-B to a known MotoTRBO frequency - Set EXT. Data speed to 9600 (discriminator tap) - NOTE: do NOT try to use Fldigi's "RX audio capture" feature as it only samples at 8000. DSD wants 48k - Find the audio input device you want to record with: arecord -l #16bit, little endian, 1 channel (mono), 48k samples, no end duration # output is wav arecord -vv -f S16_LE -c1 -r48000 -d 0 -t wav --device=hw:1,0 /tmp/capture.wav Serial port Troubleshooting --------------------------- When troubleshooting PTT circuits say for my first setup with a Kenwood TH-F6A ( http://www.dunmire.org/projects/DigitalCommCenter/index.html --> PTT), I needed tools to make sure the serial ports were working properly. Finding useful serial tools wasn't as easy as I thought it would be. As such, I've put together a few tools that I like to use: Classic Linux tools: #finding a process that's using the serial port and thus initializing it sudo ls -l /proc/[0-9]/fd/ |grep /dev/ttyUSB0 #Alternative approach of finding a process that's using the serial port and thus initializing it sudo yum install lsof sudo lsof /dev/ttyUSB0 #Confirm the OS thinks the DTR line should be high on the port # # If you're using real serial ports like ttyS0, use this command sudo cat /proc/tty/driver/serial #If you're using USB serial ports, use this command: sudo cat /proc/tty/driver/usbserial #See what else might be set on the serial port stty -F /dev/ttyUSB0 statserial - Shows the state of the various serial pins and what not. Very helpful. #from the EPEL repo: yum install statserial statserial /dev/ttyUSB0 setserial - Allows for setting speeds, flow controls, etc. much of this program is no longer needed as all programs that use a serial port will already initialize the serial port again NOTE: Though setserial can display the current stat of a serial port's data lines, I've found that it's initialization routine will SET or ALTER the state of the port's hardware flow control lines especially on USB-based serial ports. Once these programs exit, it does not bring things lines down and thus a Kenwood D710 in Echolink mode will key up and NEVER unkey! Very bad! See "statserial" above which avoids this issue. stty - A tool to send lower level commands with controlled formatting to tty ports modemtest - This program comes as part of the perl-Device-SerialPort package and has the ability to display the current state of the serial lines (buggy?) and then reset those lines to a sane state when done. This is critical if a serial port is keying up say a Kenwood D710 radio via the RTS line (stupid design) and you can't unkey the radio!! 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 detachable terminals controlling serial ports - can also show serial port status with Control-A + i - Coolterm - Supports Mac, Win, Linux (minimal support) - displays serial port pin status, - Supports receiving / sending ASCII / HEX - 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. +---------------------------+ | 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 -------------------------------------------------------------------------- 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 +---------------------------------------------------------------------+ | NOTE: | | This is probably not useful information to you but it might | | be. Up to you.. this is legacy notes that need to be removed | +---------------------------------------------------------------------+ 144.910Mhz ---------- 10:29am 5/29/09 (Friday) Callsign Port Packets Last Heard W6XSC-6 vhfdrop 2 Fri May 29 11:58:33 -- BEACON: Santa Clara County Digi Milpitas. K6KP-6 vhfdrop 12 Fri May 29 11:58:09 W6XSC-2 vhfdrop 2 Fri May 29 11:56:06 K6SNY vhfdrop 5 Fri May 29 11:55:36 W6XSC-5 vhfdrop 84 Fri May 29 11:43:31 KE6AFE-10 vhfdrop 1 Fri May 29 11:01:12 KI6ZHD-8 vhfdrop 146 Fri May 29 10:22:06 -- me With soundmodemconfig, I also see the following that axlisten doesn't: -- Packet: fm WR6ABD-0 to ID-0 UI pid=F0 WR6ABD/R LPRC2/D WR6ABD-1/B LPRC2/N Packet: fm WR6ABD-0 to BEACON-0 UI pid=F0 Loma Pioneer Repeater Club www.LPRC.net -- 223.660Mhz ---------- Nothing as of 10:29am 5/29/09 (Friday) 441.500Mhz ---------- Good packet sessions : ---------------------- broadcast K6KP-6 is a BBS run by KN6PE -- vhfdrop: fm K6KP to MAIL ctl UI^ pid=F0(Text) len 67 0000 Mail for: GIL KN3PE LGREDC LGTEOC MSOEOC SAREOC SNCEOC SNYEOC W6 0040 TDM fm K6KP-6 to KI6ZHD-8 ctl I10+ pid=F0(Text) len 104 0000 [JNOS-1.10m-IHM$]..Welcome ki6zhd,.to the K6KP-5 TCP/IP Mailbox 0040 (JNOS 1.10m (8088))..Currently 1 user... fm K6KP-6 to KI6ZHD-8 ctl RR1- fm K6KP-6 to KI6ZHD-8 ctl I11+ pid=F0(Text) len 110 0000 '?' or 'h command` for help. Please send local messages to 'user 0040 s'..Questions to sysop..Enjoy! -- jim kn6pe... vhfdrop: fm K6KP-6 to KI6ZHD-8 ctl I12+ pid=F0(Text) len 112 0000 You have 0 messages..Area: ki6zhd Current msg# 0..?,A,B,C,D,E,F, 0040 H,I,IH,IP,J,K,L,M,N,NR,O,P,PI,R,S,T,U,V,W,X,Z >. -- W6XSC-2 on 144.910 doesn't work W6XSC-5 on 144.910 is controller node a few things: -- PORTS XSCNOD:W6XSC-5} Ports: 1 144.910 Mhz 1200 Baud 2 223.660 Mhz 1200 Baud 3 441.500 Mhz 1200 Baud 4 Bridge to County #Seems the PORTS command there is mis-configured as I'm connected on 144.910 #but when I list port#3 (441.500), I get: MHEARD 3 XSCNOD:W6XSC-5} Heard List for Port 3 KI6ZHD-8 09:59:11 W6XSC-6 09:57:30 K6KP-6 09:57:07 WR6ABD 09:57:00 W6MOL 09:56:23 W6XSC-2 09:54:55 K6SNY 09:54:33 WD0DNM 09:48:13 KE6AFE-10 09:36:11 K6KP 09:34:55 KB6YNO-10 09:19:45 K6SNY-1 08:59:43 KA3L-2 07:55:20 AD6TL-3 06:26:28 WB6EOC 01:50:46 WB6TMS 23:22:33 WB6TMS-15 22:42:33 K6OTT 22:09:21 SNYEOC 21:51:43 K3OES-10 19:36:56 USERS XSCNOD:W6XSC-5} G8BPQ Network System V4.08a (133) Uplink 3(KI6ZHD-8) -- ------------------------ call vhfdrop WR6ABD --- also known as LPRC2 (with less commands) ENTER COMMAND: B,J,K,L,R,S, or Help > B(ye) PBBS WILL DISCONNECT J(heard) CALLSIGNS WITH DAYSTAMP J S(hort) HEARD CALLSIGNS ONLY J L(ong) CALLSIGNS WITH DAYSTAMP AND VIAS L [x [y]] [;] LIST MESSAGES x THRU y YOU CAN READ L <|> call LIST MESSAGES FROM OR TO CALL LB LIST BULLETINS LC [cat] LIST CATEGORIES LL n LIST LAST n MESSAGES LM(ine) LIST UNREAD MESSAGES ADDRESSED TO YOU LO [+|-] LISTING ORDER LT LIST TRAFFIC LTn DISPLAY LOCATION TEXT n=1-4 K(ill) n DELETE MESSAGE NUMBER n KM(ine) DELETE ALL READ MESSAGES ADDRESSED TO YOU R(ead) n DISPLAY MESSAGE NUMBER n RH n DISPLAY MESSAGE n WITH HEADERS RM(ine) READ ALL MESSAGES ADDRESSED TO YOU S(end) call SEND MESSAGE TO callsign S[B|P|T] call SEND BULLETIN, PRIVATE, or TRAFFIC ENTER COMMAND: B,J,K,L,R,S, or Help > ENTER COMMAND: B,J,K,L,R,S, or Help > J L K6ACS-10 > BEACON 05/29/2009 16:05:38 KB6YNO-10 > BEACON 05/29/2009 16:18:53 VIA WD0DNM,WB6EOC,LPRC2 K6SNY-1 > KI6RLD 05/29/2009 16:23:28 KI6RLD > K6SNY-1 05/29/2009 16:23:29 W6MOL > BEACON 05/29/2009 16:25:33 AD6TL-3 > BEACON 05/29/2009 16:25:36 N6FRG-5 > ID 05/29/2009 16:27:34 WD0DNM > ID 05/29/2009 16:28:22 WA6PIC > BEACON 05/29/2009 16:28:52 VIA MAR5,SARA WB6TMS > ID 05/29/2009 16:31:32 K6KP > MAIL 05/29/2009 16:34:06 W6XSC-2 > CQ 05/29/2009 16:34:32 KE6AFE-10 > BEACON 05/29/2009 16:35:19 VIA LPRC2 K3OES-10 > ID 05/29/2009 16:35:58 W6XSC-5 > ID 05/29/2009 16:38:15 W5OES-10 > ID 05/29/2009 16:38:21 K6SNY > BEACON 05/29/2009 16:38:44 KI6ZHD-8 > WR6ABD 05/29/2009 16:38:59 ------------------------------ k6sny-1 -------------------------------------- ENTER COMMAND: B,J,K,L,R,S, or Help > B(ye) PBBS WILL DISCONNECT J(heard) CALLSIGNS WITH DAYSTAMP J S(hort) HEARD CALLSIGNS ONLY J L(ong) CALLSIGNS WITH DAYSTAMP AND VIAS L [x [y]] [;] LIST MESSAGES x THRU y YOU CAN READ L <|> call LIST MESSAGES FROM OR TO CALL LB LIST BULLETINS LC [cat] LIST CATEGORIES LL n [;] LIST LAST n MESSAGES LM(ine) LIST UNREAD MESSAGES ADDRESSED TO YOU LO [+|-] LISTING ORDER LT LIST TRAFFIC LTn DISPLAY LOCATION TEXT n=1-4 NL n SET PAGE SIZE WHEN READING MESSAGES K(ill) n DELETE MESSAGE NUMBER n KM(ine) DELETE ALL READ MESSAGES ADDRESSED TO YOU R(ead) n DISPLAY MESSAGE NUMBER n RH n DISPLAY MESSAGE n WITH HEADERS RM(ine) READ ALL MESSAGES ADDRESSED TO YOU S(end) call SEND MESSAGE TO callsign S[B|P|T] call SEND BULLETIN, PRIVATE, or TRAFFIC U(sers) DISPLAYS EVERYONE CONNECTED TO BBS ENTER COMMAND: B,J,K,L,R,S, or Help > -------------------------------------- > Looking from the output of axlisten, things look ok but it's probably an > issue with outpost. Watching it run, it's very chatty and creates a lot > of unnecessary checks. Is outpost in active development? Sure looks like it could use some optimizations and add some latencies to let other people into both the band and a given BBS. It really seems to dominate. >I see retransmits from you (however my antenna is very low and has a lot >of local noise near it). Does your TNC show full decodes of traffic on the air? Is that how you're seeing the retransmits? I'm on a Kenwood TH-F6A HT using soundmodem (TNC emulation) on Linux. The whole rid isn't very ideal right now. I plan on getting a good antenna this weekend (comments on Comet vs. Diamond, vs. ???). I have an email I've been working over if you'd be willing to look it over. >I have an older KPC3 hardware TNC. It seems like the hardware TNCs do better than soundmodem but this soundmodem tool is free, it's not very actively developed, etc. but it does work. >Look on the NCPA web site for BBS frequencies: >http://www.n0ary.org/ncpa/ncpabandplan.html i Bandplans are one thing but does anyone USE them around here? 4.910 seems busy. There was also a question on tonight's City of Santa Clara RACES NET about any cross band digipeaters. I want to say w6XSC can but I don't know if it's configured. Thoughts? --David; KI6ZHD -andreas de K6OTT 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. 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) It's never done... EVER. Adding support for Centos6 should be proof to that! Sheesh! - Add SDR-Angle which a new SDR application that can decode many different AMBE vocoded signals - Figure out what ax25spyd isn't reliable in compiling! a. Doc Fldigi WWV calibration Page Views since 02/17/14:
Flag Counter
11/23/18 - Updated the section on picking a radio soundcard solution 10/21/18 - Added a note that the VE7FET repos have receive major improvements and changes which will impact the RPM spec files. I haven't had a chance to update the doc fully yet 10/18/18 - Updated Direwolf to 1.5 Release 09/28/18 - More details on APRS clients and servers 09/21/18 - Added a list of various APRS clients and servers to the APRS section - Updated the ARDOP v1 version from 1.0.2.5l to 1.0.4.1b - Added a new section on renewing expiring LOTW certificates using tqsl 09/09/18 - Noted that I'm going to start supporting IPv6 in the future 08/17/18 - Noted that the current Qsstv is 9.2.6. Updated the startup script as well to include supporting the unique config for the Kenwood D710 08/03/18 - Updated the version of Outpost 05/29/18 - Added a new section for RTLSDR-Airband 04/25/18 - Updated the version of ARIM to v1.8 and also updated the configuration of ARIM a little bit 04/21/18 - Completed the PAT section that works via it's CLI and GUI interfaces with protocols including TELNET (Internet), AX.25 packet, and ARDOP 04/05/18 - Updated the D-Rats section about a different fork that might revitalize D-rats - Updated the Direwolf spec file to support Direwolf-1.5Beta2 03/31/18 - Upgraded Hamlib to 3.2 - Upgraded ARIM to 1.7.0 03/30/18 - Fixed HTML tag issue for the building ARIM section 03/29/18 - Added a quick noted on users looking to build hamlib 3.2 - Updated the ARDOP section to reflect the new source code archive name 03/28/18 - Updated the Qsstv section to reflect a new version (9.2.6) and the requirement for Qt5 03/26/18 - Properly added sections for installing, configuraing and operating ARDOP and ARIM - Some more formatting fixes 03/17/18 - Noted a PTT hang workaround for the CP210x based USB to serial adapters 03/10/18 - Updated the fltk section to 1.3.4.2 03/09/18 - Some few changes to the ax25spyd section 03/08/18 - Added notes about the Logicneed CH340/341 USB to serial adapters 02/15/18 - Added an example Svxilnk test connection in the Svxlink CheatSheet 02/03/18 - Added a note to install pulseaudio-utils to use pacmd configure PulseAudio sound device routing and audio levels as an alternative to the GUI pavucontrol tool - Updated the Chirp section to now include the Python-Serial module for newer versions of Chirp 01/29/18 - Fixed the broken link for yum-ax25-upgrade-workaround.sh to point to update-glibc-ax25-workaround.sh 01/17/18 - Fixed the index a bit 01/05/18 - Updated URL for the ax25spyd patch 12/16/17 - Updated the Linpac section to reflect version 0.25 - Noted issues heard about DTR on CP2102 based serial adapers - Added SDR-Angle to the todo list 11/28/17 - Updated the version of Outpost 11/06/17 - Updated the SoftTNC intro and added a link on the real performance of AFSK1200 modem over FM 11/05/17 - New publish 10/10/17 - Minor cleanups and updates to the DRM section 09/26/17 - Updated the Serial port Troubleshooting section 09/23/17 - Updated Java JRE to v8 Update 144 09/05/17 - New publish 08/27/17 - Updated the Kernel update section to mention that the ElRepo kernels support the AX.25 and other amateur radio kernel modules which means most people no longer need to recompile the kernel from sources - Updated the FreeDV section to reflect that this package is now in the EPEL repo and no longer in the Fedora COPR - Updated the TrustedQSL section to reflect that binary RPMs are now available via EPEL 08/16/17 - Added some clarifying points on SUID for Xastir 06/27/17 - Updated the mheardd section 05/28/17 - Updated the AMPR section, added new examples, updated the AMPR GW IP, and made all this it's own section 05/22/17 - Added a few other programs that support Winlink for VHF packet and HF Pactor - New repo home for paclink-unix 05/09/17 - Added Direwolf section to reflect v1.4 as well as updated the doc to reflect that AX.25 connected sessions are now supported as well 04/27/17 - Update to Fldigi 4.0.2 and Flrig 1.3.30 04/23/17 - Fixes for changes in restoring soundcard mixer levels alsactl as things have changed due to recent Centos6 fixes 03/14/17 - Added another URL for finding quality FTDI-based serial cables 02/21/17 - Added a specific note that Svxlink's Echolink module's location is in ARC seconds 01/25/17 - Updated SDRPlay driver section slightly to mentioned the SDRPlay's closed source Mirics driver will never see Centos6 support. Also added there is a 3rd party OSS driver in the works as well that might open this support up 12/04/16 - Noted that Gpredict 1.4git is not compatible with Centos6 due to needing a newer version of glib 12/03/16 - Linpac init.mac: noted that newer 4.8.x kernels require the "Loopback Mixing" option enabled to hear the PC speaker output 12/02/16 - Updated the kernel section for the ElRepo 4.8.11 ML kernel 10/23/16 - Updated the kernel section to support newer ElRepo-ML kernels as well as mention failed steps on compiling Centos7 kernels on Centos6 machines 10/20/16 - Updated the ax25spyd section a bit - Update the GPS coordinate subsection in the Xastir section 10/19/16 - Minor intro section changes 10/07/16 - Updated Gqrx to 2.6.0 and Qt to 5.6.1 09/21/17 - Updated some of the D-rats download URLs 09/13/16 - Added a new URL for newer versions Golang 09/08/16 - Updated the Direwolf section to include URLs for tuning packet levels as well as TXDELAY parameters - Index fixes 08/26/16 - Added more thoughts on packet radio audio tuning 08/22/16 - Added details and images on the LimeSDR, BladeRF, Ettus B200, and mentioned more SDR HW - Reorganized the SDR section a bit 08/18/16 - Updated the Xastir Git version which has proper steps for creating the archive 08/13/16 - Updated Gqrx to build either mainline releases and also TIP bleeding edge Git code where all the newest features are 08/09/16 - Updated the Xastir Git version which has new online map sources 08/07/16 - Updated the QSL Service section a bit 08/06/16 - New publish mostly for Rpi APRS doc 07/30/16 - Fixed some formatting issues in the Index and elsewhere - Fixed a LOT of spelling mistakes using Aspell (ugg.. sorry about all that) 07/24/16 - Added the Xastir-sounds package for local Xastir sounds - Added an Xastir tuning section to improve the map view, APRS icons, etc - Updated the Xastir GIT version 07/17/16 - Added an alternative way to find the soundcard's native sampling rates 07/16/16 - Added a link to Valley Enterprises for USB cables 07/08/16 - Updated Xastir to use new Git repository and updated the spec file 07/07/16 - Major update to the building of libax25/ax25apps/ax25tools as that section was still using the old GoogleCode URLS and didn't support Git versioning. 07/05/16 - Mentioned in the Airspy section that the packing feature DOES require more CPU processing 07/04/16 - Updated Gnuradio to 2.7.9.2 and gr-osmosdr to the Feb 28, 2016 1.5.0GIT - Added more details on how to validate that the build is going to have want you need it it, etc - Added a 10MSPS Gqrx screen capture - Added firmware upgrade notes for the Airspy r2 - Updated the airspy-host section to 1.0.8 and included the tuning for the USB packing feature - moved around the RTL-SDR rtltesting section to be closer to building the drivers - Updates to the Gqrx + Airspy configuration stage for optional parameters - Added a Gqrx performance troubleshooting section 07/01/16 - Updated Qsstv to 9.1.7 - Updated Xastir to 2.0.8 - Formatted the section a little bit better, broke it up into a few more sections 06/28/16 - Updated Qsstv to 9.1.6 05/13/16 - Mentioned what specific Fldigi modems are 8bit clean 05/07/16 - Added a new section: UI-Chat - renamed the Fldigi TCP-KISS section to "NextGen HF packet - Using Fldigi's modern modes with Linux's native AX.25 stack via TCP-KISS" - Updated the PSKmail section to recommend a newer version of Java 05/06/16 - Updated the Direwolf section on compiling version 1.3 as well as how to configure and tune it - Significantly enhanced the "Initial AX.25 setup system settings" section for new users - More enhancements for first-time manual packet setups including URLs for KISS ON/OFF for Kenwood D710 and Kantronics KPC3s 04/27/16 - Additional work on UroNode - Added a note on flexd and how the only solution here is to run pc/FlexNet in DOSEmu emulator today - Added note on the need for unique SSIDs / differences in how say a KPC3 TNC uses SSIDs for Netrom vs AX.25 connections 04/17/16 - Updated the Fldigi KISS section to include the new, far more reliable TCP-KISS method 04/16/16 - Forgot to include the installation of the built gpsd-devel-3.5-1.el6.x86_64.rpm for other programs to build and include gps support 04/10/16 - Updated the Uronode section to 2.5.1 04/09/16 - Updated the Qsstv section to reflect 9.1.1 and also cleaned up and updated the overall chapter a bit (added sections, moved things around, etc). I also updated the associated image resizing script to use GraphicsMagic vs. ImageMagick since I find GraphicsMagick to work better on Centos as well as ImageMagick does NOT work well with Xastir 04/01/16 - Noted that Pat needs a newer version of Git to work - section still incomplete 03/08/16 - Moved the DSD section to be section 46 - Created a new section for Pat, the mult-platform Winlink client program written in Go. This is NOT complete yet 03/07/16 - Updated Gqrx to 2.5.3 - Updated the Gqrx section a bit on how to configure various hardware 02/11/16 - Updated the SDR section a bit more with more details - Major updates to the Airspy section 02/08/16 - The libusbx package was been merged back into libusb back in 2014. I've made a note of this and will update the docs shortly to install the superset libusb package install instead of libusbx - Fixed an SDR index issue 02/06/16 - Added a note on an updated 300baud Soundmodem patch for those who still use Soundmodem. I personally recommend Direwolf now - Updated the update-glibc-ax25-workaround.sh script - Packaged the Mirics sdrplay API into an RPM - Working with SDRPlay to get a Centos6 compatible binary API package - Updated the fact that the current Airspy r2 unit is 12bit 01/31/16 - Added the gr-iqbal and libosmo-dsp GnuRadio modules - Started the SDR-Play support including updates the Udev and GR-OSOMO sections 12/23/15 - Added the recommendation to run volk_profile at the end of the GnuRadio section 12/14/15 - Updated the Gqrx section 2.4.0 (updated SPEC file, etc) - Updated the gr-osmodr from 0.1.1 to 0.1.5 to support Gqrx 2.3.0 11/20/15 - Updated the Linpac section to reflect new version - New posted version to the Internet 11/04/15 - Added new packet modems: dxlAPRS and other options under say JavaScript, Go, etc 10/30/15 - Updated the Xastir section to use GraphicsMagick over ImageMagick (have fixed this a long time ago but didn't update the doc) - Updated to use the tip of tree CVS (currently at 2.0.7) 10/14/15 - Updated the linpac-check-msgs.sh and packetrig.sh scripts to use /var/lock instead of /var/tmp for state flags as some cronjabs would clean out these directories 10/12/15 - Started work to update Tqsl to 2.1.2 10/10/15 - Updated the Qsstv screen captures 10/01/15 - New Qsstv version - Deprecated the atrpms repo as it's gone silent - Uploaded a new release of this doc 09/27/15 - Detail in the Svxlink network section that Port Forwarding and Port Triggering are NOT the same thing 09/25/15 - Added a portforwarding section to the Svxlink chapter 09/02/15 - New URL for VE7FET's AX.25 repository but the AX.25 section still needs work to support the new Git workflow 08/31/15 - Updated Direwolf URL 07/25/15 - Fixed some index issues 07/24/15 - new URL and version of Tom Sailer's Soundmodem posted 07/22/15 - Added Tom Sailer soundmodem mirror URL 07/12/15 - Minor formatting changes in Linpac section - Updated Qsstv to 8.2.12 06/26/15 - Chirp on Centos6 now requires the python-argparse package 06/21/15 - Updated the Linpac index and section - Added missing Soundmodem screen captures 06/16/15 - Fixed an index formatting issue 06/06/15 - Added xorg-x11-apps to get xfontsel for Xastir font resizing - Shortened some long sourceforge URLs 06/03/15 - Updated the Winlink APRS section a little 06/02/15 - Updated the Fltk section a little 05/24/15 - Updated the Linpac init.mac section to mention that the order of screen look commands MATTERS 05/23/15 - Changed the Xastir system to stop using SUID root and instead use the dialout group 05/10/15 - New release 05/06/15 - Fixed Pskmail startup command 05/04/15 - Updated Svxlink Git Maint repo to get new Echolink IP address conflict fix 04/22/15 - Spelling corrections 04/19/15 - Updated the Svxlink soundcard test section a bit to use 16k samples - Other svxlink section updates as well as some serious improvements to the svxlink spec file 04/11/15 - Updated the Svxlink section to reflect the newer Git based Svxlink code that has various fixes for things like hearing periodic beeping from remote Apple IOS based clients, etc - New settings [Rx1] Change SERIAL_PIN=CTS:SET to SERIAL_PIN=CTS [Tx1] Add PTT_TYPE=SerialPin 03/30/15 - Updated the APRX section to use the W6KWF version via Git which has some major big fixes - Added passcode support to the aprx configuration section 03/07/15 - Updated the TRXAMADRM and Qsstv sections to refer to my new resize-jpg-jp2-640-variqual.sh script that now converts jpg files to jp2 (jpeg2000), resize to 640x480, and upsizes files to have the maximum quality possible. It's cleanup routines are improved as well 02/15/15 - Updated the external /usr/local/sbin/usinterface-commands.sh script to work properly and support better troubleshooting - Updated the Qsstv section for FT950 users where their radios stay keyed up and they hear a constant CW tone - Added a picture of the US Interface Navigator 02/01/15 - Added more details to the Fldigi KISS script which enables using Fldigi's digital modes with Linux's native AX.25 stack 12/26/14 - Added a new section on enabling coredumps and ABRT on non-packaged files 12/22/14 - Added an advanced APRS command section - minor fix in HTML coding for 6a.soundcards 12/20/14 - Updated the Qsstv section to the newest version; updated it's spec file, and added some additional screen captures 12/15/14 - Moved up the Adobe Yum repo priorities as critical flash fixes were being over shadowed by older RPM Forge RPMs 12/07/14 - Updated the VE7FET ax.25 packages - Updated the kernel to Elrepo 3.17.5 - Added the /usr/local/sbin/start-fldigi-socat-packet.sh script 12/06/14 - Added a new Advanced Fldigi section on interfacing Fldigi to Linux's AX25 stack for HF packet 11/16/14 - Added a Soundcard selection section touching on various cheap to expensive USB soundcards - Updated the Software TNC description area a bit (Direwolf, etc) 11/08/14 - Added a new section: FreeDV 10/26/14 - Published a new version of the doc to the web 09/06/14 - Updated GnuRadio section a little bit to talk about needing to use a pre-release 3.7.6 version to fix several issues I've found 09/01/14 - Updated Gnuradio to 3.7.4 to include required fixes for GnuRadio Companion - This requires some additional heavy lifting with upgrades to pygtk2 and pygobject - stripped out the legacy GnuRadio 3.6.3 material - updated the gr-osmosdr section - updated the other sections to reflect that when upgrading GnuRadio, you will also have to rebuild other gnuradio dependent applications as well 08/31/14 - Updated the Fedora foundation library section a little - Updated the Persistent Device documentation to also include the newer /dev/serial/by-id UDEV method 08/20/14 - Updated the Linpac section to now use 0.20 08/16/14 - Updated the PSK Mail section to show the newest steps for installing Oracle Java 1.7 08/09/14 - Updated the APRS EMAIL-2 section a bit to make it clearer 08/03/14 - Updated the Linpac section to reflect that 0.20 is about to be released as well as specifically call out the older versions of Linpac and their unique use 06/07/14 - Updated the APRX section a little bit to mention that newer APRX code requires a valid APRS passcode to be able to inject data into APRS-IS 05/17/14 - Updated the WSPR and WSJT sections to specifically call out that the newer versions called WSPR-X and WSJT-X have significantly newer package requirements - Update the Gqrx section to specifically call out that it's almost always required to upgrade GnuRadio if the user wants to upgrade to a newer version of Gqrx 05/02/14 - Updated the Qsstv section to 8.2.7 04/15/14 - Fixed the APRSLink section for multi-line messages. You cannot use multiple SP (send private) commands 04/04/14 - Updated the Svxlink section about configuring the correct GPS coordinate system - Updated the Qsstv section to 8.2.6 and did some minor cleanups 03/22/14 - Updated the RTL dongle test and blacklist section a bit 03/18/14 - Added a new APRSlink section - Receive a Winlink message via APRS messages - expanded the Send a Winlink message via Internet email section 03/15/14 - Updated QSSTV to 3.2.4 with caveats that 3.1.17 is the only stable version for me running Centos 6.5 right now 03/13/14 - Cleaned up the Build Environment section a bit 03/10/14 - Fixed the index to make Direwolf first 03/08/14 - Changed the Appendix A section to be about Centos RPM quirks and how to recover from various broken "yum update" situations 02/27/14 - Index formatting improvements - Reordered the Packet Tutorial and Soundcard Packet sections 02/18/14 - Added FlagCounter counter just to get an idea how many people are viewing the doc - Renamed the document title from "Hampacketizing Centos-6 and Centos-5" to "Ham Radio Software on Centos Linux" 02/14/14 - Fixed some broken links for ax25mail-utils 02/05/14 - Updated the QSSTV section to reflect version 8.1.14 which is considerably cleaner to build. Still need to update to update the configuration section 01/06/14 - Added an additional kernel build step to include the kernel firmware 01/05/14 - Added a Using Gqrx section while includes setting the frequency offset 12/21/13 - Updated the Svxlink section to require opus-devel >1.0.0 and to also include vorbis-tools 12/16/13 - Added a blacklist entry for the dvb_usb_rtl28xxu so that the SDR functionality will work - Added Qsstv 8.1.3 that now has HamDRM digital SSTV support 12/15/13 - Added a note in the tqsl section about different broken versions of cmake - added a custom cmake build section - updated the uhd section - updated the gr-osmosdr section - Updated the Gqrx section 12/09/13 - Updated the RTL SDR section with more updated packages, broke it up into more sections, etc. 12/07/13 - Updated qwt which took some work - starting to compile all RPMs as non-root and I will re-work the whole document to reflect this proper best-practice - Updated GnuRadio section to 3.7.2.1 12/02/13 - Starting to think about upgrading GnuRadio to v3.7, QT to 5, etc. to support new versions of Gqrx 12/01/13 - Updated the Svxlink section to the new Dec 2013 release which has major improvements since Aug 2011 when I first wrote this section. This required some significant updates to the spec file, etc 11/28/13 - Updated to support TrustedQSL (LOTW) v2.0 - New version of ldsped-1.17 - Updated packetrig.sh script to support new ldsped startup syntax 11/21/13 - Fixed some formatting issues in the Index 10/29/13 - Added more terminal communication programs to the Serial troubleshooting section - Updated the Xastir section a bit, improved the RPM spec file quite a bit too 10/20/13 - Make a new Logging section and added CQRLog 10/18/13 - Fixed some broken formatting in the Flrig section 10/01/13 - Updated the Outpost for Wine section to a new version - Updated the Outpost section to use LDSPED / AGW connections 09/27/13 - Made APRS an entire section and put the previous sections under it - Added a new section on Other APRS clients, specifically breaking down various clients including the N7NIX DanTracker - Also added a section of my efforts running a Raspberry Pi with a TNC-Pi, WIFI, DanTracker, etc 09/12/13 - Added the missing "mv" in disabling Modem Manager 09/08/13 - Replaced the Unode node software with the new UroNode code - Fixed a very important Netrom configuration error in /etc/ax25/ax25d.conf 09/05/13 - Minor update on the qt.spec file BuildRequires 08/30/13 - Completed the LDSPED section 08/29/13 - Added a new soft-TNC, extmodem 08/28/13 - Updated the Ldsped section to include compiling patches, etc though incomplete - Consolidated the two Ldsped sections as well 08/25/13 - Updated the WSPR section to support Centos6 as well as create bleeding edge versions from SVN. 08/13/13 - Renamed the Soundmodem section to Soft-TNCs - Added updated details on DireWolf that it works better on HF packet than soundmodem - Made soundmodem a subsection - Added the beginnings of a Direwolf section 08/11/13 - Cleared up a key point in the soundmodem section that you do NOT use kissattach with soundmodem based soft-tncs - Cleared up a key point that the device created by soundmodem (usually sm0) is correlated to a userspace device such as "f6a" in the /etc/ax25/axports file. Users will never use the sm0 device directly. - Added a soundmodem troubleshooting section - Added mention of a needed DCD patch to not key up the radio upon RX for US Interface Navigator and other soundcard setup 08/10/13 - Updated the kernel compiling section to mention modern ElRepo ML and LT kernels - Added a cleanup stage for the VE7FET SVN AX.25 sources 08/07/13 - Updated the Winlink messaging section to cover more ways to send messages - Added a link to a short and concise cheat sheet to advanced Winlink messaging features 08/05/13 - Minor formatting changes for the picking a AX.25 stack section 08/04/13 - Updated the AX25 packages section - Added a few sub-sections where the new sections cover how to get the newest VE7FET code from the SVN trunk and added an additional Netrom patch to be more compatible with KPC3 quality calculations - Moved the Xlog section up a few to make space for a new APRS messaging section - Added a new section on how to send/receive emails to APRS stations 07/04/13 - Added a new LDSPED section 07/02/13 - Updated the packet node section a bit - Added a new section for Uronode 2.x - Made the Unode documentation it's own section and deprecated it 06/28/13 - Fixed a minor issue in the Linpac building section 06/27/13 - Added an example HELP section for Linpac - Updated the AMPR section a bit 06/24/13 - Added the "COMP" command to the allowed Linpac commands init.mac file as well as recommending users to support lowercase commands and adding them to the help.cmd file 06/16/13 - Updated the Wine and Outpost sections - Outpost now works fine with Wine 1.4+ - Updated the screen capture for TRXAMADRM - Updated Section 1's indexing a bit 06/02/13 - Updated the linpac-check-msgs.sh to check for files being activity written to avoid sending empty notifications 05/26/13 - Added screen captures for the Gqrx SDR section - Updated the Gpredict section to support Centos6 and added screen captures - Improved the Linpac email notification tool to better track the sending callsign+SSID 05/21/13 - Added rtl_test -t for offset identification 05/12/13 - Change the SDR section around to support compiling GnuRadio, rtl_sdr, and gqrx - Added a recommendation to support SMP RPM builds by default - Dropped the enabling of -g debugging objects for RPM builds - Added another link for non-root RPM compiling 05/07/13 - Added a link to my other netrom connection doc 05/04/13 - Added the date-listen-log.sh script to date the packet listen log - Added the linpac-check-msgs.sh script to send an email when you receive a new Linpac message 03/29/13 - Added a list of currently known Linux and Windows soundcard packet modems, their qualities, etc. 03/21/13 - Added an update to the Soundmodem section that there are two alternative SoftTNC programs out there that should significantly out-perform the classic soundmodem. More research coming on this topic 03/20/13 - Broke up the PreSetup section to more clearly break out some of the more common issues that need to be fixed on Linux (regardless of distro) 03/05/13 - Added a new section following Chirp on some programming ideas to have consistent programming across many different radios 03/02/13 - Updated the Svxlink section to better show the PF2 button on the D710 for Echolink mode 02/16/13 - Added a new section for APRX to support sending APRS objects into APRSIS as well as support UI unproto digipeating for packet 02/09/13 - Added an important note and reference to a Yum script to work around Glibc conflicts with the VE7FET libax25 libraries 02/03/13 - Added the modem-manager section to the deterministic Udev serial port section 01/27/13 - Added some additional details on mixer programs in the Soundmodem section - Added some recommended saving and restoring sound levels in the Svxlink section and the start-svxlink.sh script 01/18/13 - Moved some of the RPM build environment setup from the custom kernel section to the PreSetup section - Added a Centos link on how to setup a non-root based build environment 01/11/13 - Added a new URL on how to reprogram the USB VID/PID values for FTDI devices 12/16/12 - Added some minor cleanups to the Udev sections 12/10/12 - Updated Xastir from 2.0.1CVS to 2.0.5CVS - Fixed some missing steps in renaming the CVS directory - Added a new dependency for Xastir 12/08/12 - Updated one of the URLs for the isolation boards 12/01/12 - Updated the TRXAMADRM section to reflect the common unification, more details on rig control, RX image file uploads via FTP, etc 11/11/12 - Added Flamp - Added a new section on how to easily upgrade the various Fl-suite of programs - Rearranged the Fldigi and logging related sections to be together 11/06/12 - Updated the Linpac section with a fix for macro/commands 11/05/12 - Start writing up on AMPR tunneling over the Internet. 10/31/12 - Started updating the Soundmodem section to better reflect Centos6 settings 10/30/12 - Added a reference to a 2 port FTDI-based USB to serial port adapter 10/26/12 - Major update to the Svxlink section - Added a new details on a dangerous issue with the D710 using the RTS serial line to control the radio's PTT. - Added a startup script to work around this issue - noted that the QSO recorder feature only works from the top level and not when other modules are loaded - Added a section on how to edit the default voice prompts - Removed serlook as it's not compatible with Centos5 or Centos6 10/22/12 - Significant update to the Dstar section - Added local audio and SMS notifications to Svxlink echolink connections 10/18/12 - Minor svxlink section updates 10/17/12 - Updated the LOTW section for Centos6 as well as added notes on details on renewing your certificates (wow.. it's been 3yrs!) - Updated a broken URL for how to submit logs via LOTW and EQSL - Noted that the compiling of ax25spyd is still unreliable the first time - Added a new section for ldsped but it's just getting started 10/15/12 - Added a Qtel client section - More svxlink updates 10/08/12 - Finished the ALSA enumeration section -- man.. very complicated - Greatly expanded the Svxlink section to include it's configuration, configuring the Kenwood D710 for Echolink mode, etc. - Added some Dstar tutorial links 10/04/12 - Added a new Svxlink+Qtel echolink section. It's not complete yet - Updated the Echolink section a bit, refining it, added more details in setting up a new account, etc. - Added a quick section on paper QSL managers for bureaus - Updated the RXAMADRM and TXAMADRM versions 09/25/12 - Added the start of how to create consistent ALSA device enumeration 09/16/12 - Added a link to another 4port FTDI based device for serial connections 09/15/12 - Fixed an important issue where you MUST use the Fedora SRPM to get critical patches regardless of which SPEC file you download - Broke up the Fldigi section a bit - Broke out Hamlib into it's own compiling section - More comments on Qsstv 7.1 and it's serial keying 09/14/12 - Updated RXAMADRM version - Major update to the TXAMADRM section 09/13/12 - Updated the QSSTV section to support Qsstv 7.1.7 - Removed all references to QSSTV 6.0 Alpha (was broken) 09/07/12 - Changed the Linpac section as the SP/SB commands have to be upper case 09/02/12 - Updated the Linpac configuration section 08/31/12 - Updated the RXAMADRM section with new text, new version, etc - Split out the TXAMADRM into it's own section - a work in progress 08/25/12 - Updated the third-party RPM repo section a bit 08/24/12 - Some changes for kernel compiling, more comments in there, etc 08/22/12 - Some additional cleanups on the Fldigi compiling section - Updated the EPEL repo section a little - Added some more details on USB to serial adapters 08/20/12 - Fixed a typo on checking the installed RPMs for creating a build environment. Thanks WA6MBZ - Cleaned up the Fldigi section a little 08/19/12 - Added some missing lines for downloading patch files needed for various SPEC files and other programs - Added a patch for fixing Unode coredumps when locally executed - Added a fix in the packetrig.sh script to assign callsigns to various daemons (needed by Unode) 08/18/12 - Updated the legacy node section to be complete -- for troubleshooting node servers via netrom - Added some key troubleshooting notes in troubleshooting Netrom node services - Added a key update to the ax25d.conf file for Netrom based connections - Added a note about the core problems I was seeing with Unode where a workaround and a fix have been identified 08/17/12 - Added a new Dstar and D-RATS section - pretty cool program that doesn't require Dstar.. who knew? - Added screen captures of some of the programs 08/11/12 - Added the start of an Echolink / IRLP :: EchoIRLP section. Intro is there, installation and setup needs to be written - Change the default Netrom route update to be 60 min - Added some descriptions on what the various RPM build directories are for, etc. 08/03/12 - Added a note about not setting VERBOSE on Netrom broadcasts - Updates to the AX.25 messaging tools section but still no solution 06/28/12 - Cleaned up a bit of the Udev USB enumeration sections, improved the debugging details, etc. 06/21/12 - Changed the recommended base AX.25 packages to VE7FET's which integrated all of F6BVP's changes. There is one issue with the ax25tools package but it's been resolved via a patch 06/11/12 - Added a new section on filtering packet logs 06/10/12 - Got Unode running on centos 6.2 though there is an outstanding issue where if I connect to the node via localhost, the process will coredump. 06/02/12 - More Unode troubleshooting 06/01/12 - Updated the netrom settings as they were inconsistent (and wrong) - Broke out the Netrom and Node services into different chapters - Updated the ax25mail-utils section to include that we need to configure four other files to properly relay messages to/from the local BBS - Trying to build Unode but the program is coredumping 05/29/12 - Working with N6ACK to fix some screwy linpac compile issues using non-standard paths 05/26/12 - Updated the Packet radio section talking about trying to find a simple PBBS style messaging solution. Covered pms, axmail so far - Added a new, overly simplified section for ax25ipd for tunneling AX.25 packets over the Internet - Added initial ax25spyd support - Adding better Linpac support via adding new sections for ax25mail-utils and ax25spyd support - Updated the Linpac section talking about editing the help, info and init.mac files 05/16/12 - Updated the gpsd and Xastir sections to support Centos6 as well as newer versions of GPSd 04/07/12 - Added an additional appendix section to document my findings in patching the Centos5 2.6.18 kernel to properly support RS232 based Baycom TNCs - Added a URL in Appendix-C to easily browse kernel commits by file and not by date. Helpful to see if anything has changed for specific drivers, etc - Added a link to the Radio.Linux.org.au site 04/04/12 - Added some additional AX25 troubleshooting. - More improvements have been made to the packetrig script - Had to add the CONFIG_BAYCOM_EPP parameter to custom kernel compiling for Centos5 03/31/12 - Updated the soundmodem section a bit and made significant updates to the packetrig.sh script to support 300baud HF soundmodem - Updated the soundmodem.spec file to support patching in these fixes 03/24/12 - Newer Centos kernels broke the initial udev setup when recognizing the first two serial ports on the US Interface Navigator. Fixed with adding ENV{ID_MM_DEVICE_IGNORE}="1", to the udev rule - Updated the RXAMADRM section to reflect the new 0_4 version that's coming that has lots of fixes, etc. - Redhat no longer hosts Fedora SRPMs so I updated the impacted URLS - Updated Hamlib to 1.2.15 03/18/12 - Updated the kernel compiling section a bit - Update the power management section a bit, moved it to PreSetup section - the updated the packetrig.sh script to include another attempt to be able to disable suspend 03/12/12 - More updates on the RXAMADRM chapter 03/03/12 - Added a fix for missing mheard dir path and added a check in the packetrig.sh script 03/02/12 - Updated the rxamadrm program to properly compile and run on Centos6 02/18/12 - Updated the user permissions in /usr/src/redhat to allow for non-root RPM building - Started working on RXAMADRM for Centos6 but roadblocked for now 02/14/12 - Changed the background to a light grey - significantly cleaned up the index, renamed a few sections to be much clearer on their actual content, identified more sections that need Centos6 updates by the beginning of their respective sections 02/12/12 - First public version of the new Centos6 materials pushed out to the website 01/29/12 - Added PC speaker patch to the Linpac 0.17pre3 section - Added a recommendation to backup the config-x86_64-generic-rhel for future uses - Updated the pskmeter.py section for Centos6 01/22/12 - Moved away from adding US Interface Navigator support via kernel source code changes and I'm not using UDEV tricks - Updated the 3rd party repo section a bit 01/15/12 - Stripped out significant sections of legacy, confusing kernel configuration sections - Changed the AX25 tools from the Official sources to the F6BVP repo - consolidated and removed older ax25 details, related bug reports, etc. - Added in some important rpmbuild optimizations to make sure the created RPMs are optimized for your hardware. This is very important for x86_64 systems - moved the configuration of 3rd party repos to the top of the document and not an appendix 12/28/11 - Updating the documentation to now include Centos6 support 11/29/11 - Will be replacing the Linuxnode section for the Unode software as has more features, has security fixes, etc. - Broke up the AX.25 packet section into a few sections to be more modular 11/23/11 - Added missing AX.25 and US Navigator kernel patches to archives and better documented them here 11/20/11 - Updated the nrbroadcast file to lower the default weight of learned routes 11/13/11 - Added a Soundmodem level tuning URL in the soundmodem section 11/06/11 - Added a Creative Commons license to the doc 10/30/11 - Changed the nrports file to only advertise the node as it seems to be bad form to send out multiple routes to the same station 10/22/11 - still tweaking the nrports file to get it right 10/20/11 - added URLs to specific AX25 apps/libs/tools bugs - added an additional repo as it might be better than the official ax.25 CVS 10/17/11 - some fixes and clarifications for Netrom interfaces - updates to the packetrig.sh script to enable ADVAX25 depending on the picked BEACON path 10/15/11 - Added Linuxnode : full Netrom proto system that offers a lot more features - Enabled ax25d to support other programs as well - revamped the ax25-tools section to work around buggy code in the nrattach.c file 09/17/11 - Added my LoTW / eqsl.cc notes to the LoTW section - Changed the LOTW chapter name to ARRL Logbook (and Eqsl.cc) logging with Fldigi and other tools 09/04/11 - updated sources for the ax25 tools 08/23/11 - Added Gpredict 0.90 though supporting Centos5 is becoming harder and harder 07/04/11 - Added a Serial troubleshooting section, fixed overlapping chapter numbers 06/27/11 - Updated the Winlink2k section, better phrasing, formatting, some typos 06/19/11 - Updated soundmodem to 0.16 06/11/11 - Added some recommendations for tuning the Signal browser in Fldigi 06/10/11 - Updated Flrig to 1.1.3CY 06/09/11 - Updated the Fldigi section to reflect a new update to Hamlib 1.2.13.1 05/19/11 - Added Flwrap and configuring Flarq 05/18/11 - Added Flmsg 05/15/11 - Added an additional URL for SRPMs - Update the Flrig section to reflect building Alpha versions 05/14/11 - Updated the Outpost install on Wine 05/01/11 - Added flwkey 04/30/11 - Added flrig - Added fixes to other sections for the legacy --vendor SPEC attribute 04/24/11 - Added missing setup and configuration info for Linpac 04/20/11 - Updated the 3rd party RPM repo appendix to work around an issue with conflicts that priorities doesn't fix 03/27/11 - Added initial DSD docs 03/15/11 - Added a new start to a Winlink2000 section 03/14/11 - Added some URLs in the beginning touching on Packet tutorials for both VHF and HF 03/09/11 - Added wxtoimg for APT and WeFAX satellite decoding - Added links to - NAVTEX decoding - PACTOR-1 / AMTOR decoding 03/06/11 - Updated LOTW tqsllib to 2.2 and TrustedQSL to 1.13 02/12/11 - Added Chirp - HTMLized the document - 1st phase - Added a patch to Linpac to support many UNPROTO digipeaters 01/24/11 - Added Wine for eventual Outpost 12/26/10 - Added PskMail 10/30/10 - minor updates 09/29/10 - start to undo the Tk-8.5 damage required by RXADM - Added notes to Fldigi to recommend tuning the soundcard with WWV calibration and to also tune the IMD settings - Added a TODO section 09/23/10 - Working with W1HJK, upgraded portaudio from the ElRepo 0.19-8 to tip of tree 2010-09-23 to try in resolve various FLdigi TX timeout errors. So far, Contestia seems to be working now, etc. 08/30/10 - simplifying the kernel compiling steps using more patches all through the kernel-2.6.spec file and patch-99000 08/28/10 - added the removal of the setroubleshoot RPM as it causes issues when the daemon isn't running - disabled busted gpsd udev rules 08/14/10 - new version of soundmodem that fixes all the spectrum analysis hangs. woohoo! Cleaned up the soundmodem section a little too 08/01/10 - Added a new gpsd section for support with Xastir and Ambicom GPSes. Moved the incomplete Delorme section to it. Updated the Xastir section 07/25/10 - added Xlog 07/09/10 - updated all ECST URLs 07/04/10 - cleaned the doc up a little, added QSSTV 06/20/10 - updated the kernel section; - added mention of the US navigator kernel changes 05/08/10 - added comments about fldigi contesting, upgraded to fldigi 3.20.11 02/17/10 - added WSPR support 12/27/09 - added JT65 support `11/28/09 - added new kernel steps 11/15/09 - added new Latitude aumix / kmix numbers; pskmeter numbers 10/23/09 - added TQSL 09/05/09 - updated to fldigi 3.12.4 from 3.11.5; updated SPEC file to include new files and --enable-optimizations flag 08/02/09 - added jnos 07/03/09 - added fldigi - Start of this document

100. - Errata

99. - To Do - Things that I need to still do

Appendix D - Radio Quirks : Using my specific radios

Appendix C - Misc other topics: Baycom TNCs, etc

Appendix B - KI6ZHD Running Packet notes for QTH

Appendix A - Centos updating quirks

51. - Other useful tools for the Linux HamShack

50. - Serial port troubleshooting and tools

46. - DSD - Decoding MotoTrbo, P25, ProVoice, NXDN, etc

45b. - D-rats - Email, IM messaging, and more via Internet, D-Star, packet radio, and more

45.a - Learning DStar - Setting up a US Trust account and learning about how it all works

45. - DStar - Digital Voice, Data and other related technologies

44.c - Using Echolink and IRLP

44.b - Echolink Validation

44.a - Overview of Using Echolink and IRLP

44. - Echolink and IRLP Internet Linking

43.j - Configuring and using Qtel for Echolink

43.i - Svxlink Cheatsheet, Using QSO Monitor to pick a free link frequency, bugs, and future features

43.h - Svxlink Startup: Safely Start/Stop Svxlink for local control and logging

43.g - Testing the Svxlink system

43.f - Setting the Svxlink audio levels

43.e - Interfacing Svxlink with a Kenwood D710

43.d - Getting Svxlink to send SMS text messages upon connection/disconnection

43.c - Svxlink and enabling the Network / Port Forwarding

43.b - Configuring the Svxlink server

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

43. - SVXlink and Qtel - Echolink client and server - Ham Radio and VoIP over the Internet

42.m - Noting other SDR Applications for Linux (GHPSDR, SDR-J, SDR#)

42.l - RTLSDR-Airband: Multi-slice SDR demodulator for up to 8 simultaneous audio streams

42.k - LinRad - a powerful rtl compatible sdr application

42.j4 - Troubleshooting Gqrx Performance issues

42.j3 - Using Gqrx

42.j2 - Gqrx - Compiling Gqrx

42.j1 - Gqrx - Installing final Gqrx dependencies

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

42.i - GR-OSMOSDR - Supporting the RTL dongle and SDR-Play SDR devices

42h. - SDR-Play Support - Adding the supporting software for the SDR-Play devices

42g. - Airspy Support - Adding the supporting software for the AirSpy devices

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

42e. - RTL Support - Adding the supporting software for the RTL2838 devices

42.c4 - GR-IQBAL - Supporting the IQ-Balance GnuRadio module

42c3. - Installing GnuRadio

42c2. - Compiling GnuRadio Dependencies

42c1. - GnuRadio Dependencies: installing the required sub-applications

42c. - GnuRadio - The gold standard for Software Defined Radio software

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

42a. - Picking SDR Hardware - Quick overview of RTL, Airspy, SDRPlay, BladeRF, LimeSDR, etc

42. - Software Defined Radio (SDR)

41. - Gpredict - Satellite tracking, prediction and graphical mapping tools

40.g - Operate Pat via the web based GUI

40.f - Operate Pat CLI with ARDOP

40.e - Operate Pat CLI with AX25 Packet

40.d - Operate PAT via CLI using the Internet

40.c - Configure Pat

40.b - Install Pat

40.a - Install Google Go

40. - PAT - A Multi-protocol / Multi-platform Winlink client

39d. - Advanced Winlink commands via APRS

39c. - Receive a Winlink message via APRS messages

39b. - Send a Winlink message via Internet email

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

39. - Winlink 2000 - Sending messages to / from Winlink Email, APRS, and Packet

38. - WXTOIMG - Decoding APT and WeFAX satellite images

37a. - Thoughts on Chirp and radio memory synchronization

37. - Chirp - Multi-Radio memory programming tool program

36. - Outpost - Outlook like Packet messaging program via Wine

35. - Wine - Running Windows programs within linux (used for Outpost)

34. LinKT - HF/VHF/UHF packet terminal for Qt

33. - TXAMADRM - Digital SSTV using HamDRM

33. - RXAMADRM - Receiving Digital SSTV

32. - Tuning Dream -DRM

31. - Dream - Digital Radio Mondiale (DRM) - Digital Phone - transmit/receive

30. - IBP - International Beacon Project beacon tracker

29. - GeoID - MaidenHead distance calculator

28c. - QSSTV - Configuring and Using Qsstv

28b. - QSSTV - Building older versions

28a. - QSSTV - Compiling it

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

27. - PSKMeter - BPSK31 signal quality diagnostic meter and software

26. - JNOS - Full AX25 and TCP/IP enabled packet BBS

25. - WSJT - JT65 and other HF / EME weak signal digital modes

24.a - Configuring WSPR and time management

24. - WSPR - HF weak signal beacon

23b. - Configuring FreeDV

23a. - Getting FreeDV and it's required components

23. - FreeDV - Digital voice mode using CODEC2

22.e. - Operate ARIM

22.d. - Configure ARIM

22.c. - Compile and Install ARIM

22.b. - Configure ARDOP

22.a. - Compile and Install ARDOP

22. - Compiling and Configuring ARDOP and ARIM

21.a. - Configuring and Running UI-Chat

21. - UI-Chat

20c. - APRS-IS Email via Winlink

20b. - APRS-IS Email - How HAMs can send short Internet SMTP emails back and forth to an APRS station

20a. - APRS functionality - Commands you can use with APRS to get information about the area around you

20. - Advanced APRS Usage

19d. - APRX - APRS iGate + digipeater software

19c. - Other APRS Clients for Linux

19b4. - Xastir - Tuning for better look and feel

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

19b3. - Xastir Sounds - Create the associated sound package

19b2. - Xastir - Compile the APRS mapping and digipeating tool

19b1. - Xastir - Building the Dependencies

19b. - Xastir - The APRS mapping and digipeating tool

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

19. - APRS -Automatic Packet Reporting System

18c. - Xlog - Alternative QSO Logged with automatic log uploads to LOTW/EQSL for FLdigi

18b. - CQRlog - Powerful / full featured logging

18a. - Fldigi / Fllog - Good full featured logging for the Casual user

18. - Logging - Compiling and configuration of Contact loggers

17c. - QSL Service - Tips on dealing with paper QSL cards send via bureaus

17b. - Renewing TrustedQSL certificates

17a. - Using TQSL - How to install TrustedQSL certificates and use the application

17. - TrustedQSL for Logbook of the World (LOTW) - online and offline logging with Fldigi and other tools

16b. - NextGen HF packet - Using Fldigi's modern modes with Linux's native AX.25 stack via TCP-KISS

16a. - PskMail and Fldigi - HF email and APRS system used with Fldigi

16. - Advanced Configurations with Fldigi - HF AX.25 packet, email and APRS with Fldigi

15f. - An easy way to update your various Fl-suite of programs

15e. - Flwkey - Winkeyer CW keyer software support

15d. - Flamp - FLdigi program for broadcasting messages to multiple parties

15c. - Flwrap - FLdigi plugin for sending binary files

15b. - Flmsg - FLdigi plugin for NBEMS forms

15a. - Flarq - Error corrected CONNECTED mode communications with Fldigi

15. - Other Fldigi Related Programs: Flwrap, Flmsg, FLamp, etc.

14. - Fldigi - Configuring the digital mode software

13a. - Flrig - Configure rig control

13. - Flrig - Rig control with or without Fldigi

12d. - Fldigi - Final Compiling

12c. - Fldigi - Dependencies step #2

12b. - Hamlib for Fldigi (and other apps) - Rig control for your radio

12a. - Fldigi - Dependencies step #1

One thing I've been missing on my system is a simple way for users to leave messages and for me to reply to them. Below I describe what I've found and the integration of axmail-utils with Linpac gets close but ultimately, Linpac wants to forward those messages on to a remote FBB BBS. I don't want that.. I want it all local and without using a Mail Transfer Agent (MTA) which won't let me reply to the user's message without them having a Unix account on my box! Gahhh!! Read on to see what I've found so far.. NOTE: ----- I am now the maintainer of ax25mail-utils and I plan on releasing 0.12 shortly which integrates all of the Ubuntu patches. Until then, the below notes still apply axmail-utils: ------------- This suite is used by say Linpac to transfer messages to/from a FBB BBS. Most of the versions on the internet are stale and cannot compile due to it looking for the pre-2.4 head files such as netax25/kernel_ax25.h and netax25/kernel_rose.h. Fortunately, Debian has an updated patch set that gets things working ok: cd /usr/src/redhat/SOURCES #no, the Debian sourced one is no different wget http://iweb.dl.sourceforge.net/project/ax25mail/ax25mail-utils/0.11/ax25mail-utils-0.11.tar.gz #get the Debian patches wget http://ftp.ubuntu.com/ubuntu/pool/universe/a/ax25mail-utils/ax25mail-utils_0.11-6.1.diff.gz #Optionally, you can find them on my site as well: # wget -r -l1 --no-parent -nd -A ax25mail www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ gunzip ax25mail-utils_0.11-6.1.diff.gz #Next, download my patch and ax25mail-apps.spec file from: cd /usr/src/redhat/SOURCES wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ax25mail-utils_0.11-ulistd.diff cd /usr/src/redhat/SPECS wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ax25mail-utils.spec #Ok, time to build it: #for 64bit systems rpmbuild -bb --target=x86_64 ax25mail-utils.spec rpm -ivh /usr/src/redhat/RPMS/x86_64/ax25mail-utils-0.11-7.1.el6.x86_64.rpm #for 32bit systems rpmbuild -bb --target=i686 ax25mail-utils.spec rpm -ivh /usr/src/redhat/RPMS/i686/ax25mail-utils-0.11-7.1.el6.i686.rpm Once you install the RPM, you'll need to manually create the following directory (I couldn't get the %dir macro to work properly in the .spec file): mkdir /var/ax25/ulistd --- If you are manually doing things without the .spec file ------------------------------------------------------- cd /usr/src/redhat/BUILD tar xzvf ../SOURCES/ax25mail-utils_0.11.orig.tar.gz cd ax25mail-utils-0.11.orig/ vi ulistd/ulistd.c and delete the two lines: #include >netax25/kernel_ax25.h< // new for libax25 #include >netax25/kernel_rose.h< // required by axlib.h patch -p0 < ../SOURCES/ax25mail-utils_0.11-6.1.diff ./configure make make install Incomplete - To do: ------------------- Once installed, the ax25mail-utils prgram needs the following configuration files to be configured to relay mail to/from Linpac: /etc/ax25/axgetlist.conf /etc/ax25/axgetmail.conf /etc/ax25/bulletins.OK0PAB /etc/ax25/logins /etc/ax25/ulistd.conf Out of the box, this program can forward/relay messages from FBB, JNOS, and a few other BBSes and it seems extensible to support other BBSes as well. NOTE: I have tried configuring these files but regardless of what I do (I've tried all kinds of callsign permutations, etc), when I run ulistd, I always get: no BBS specified in configuration file /etc/ax25/ulistd.conf If you know the solution to this error, I'd love to hear from you on what I'm doing wrong! --------------------------------------------------------------------------- PMS: --- There is an old program called "pms" which was apart of the deprecated ax25-utils package. This program only receives messages and it forwards the resulting message to email via Sendmail (no simple / local PBBS mail) and it also doesn't support sending messages to other hams using your PBBS as their mailbox. This program also does not support reading any messages. This program was abandoned a long time ago when the ax25-utils package was broken into the ax25-apps and ax25-tools packages. Axmail: ------- I found this Axmail program (0.0.5) at http://benghi.wz.cz/vyvoj.html but this program also uses Sendmail to send/receive emails and it also uses the axspawn mechanism to dynically create Unix accounts to support new users on demand. Inbox ----- A HAM has posted his Perl version of what is similar functionality to what the PMS program does. Unfortunately for me, it still uses a local MTA to deliver messages and doesn't provide any way for me to respond to the user's message like one could on a classic TNC PBBS. http://www.kingsqueak.org/2011/10/a-linux-packet-radio-personal-message-inbox/ Still researching this for a viable PBBS canidate on Linux as of 08/03/12 but it still looks like Linpac is your best bet Ax25spyd is very much like the AX.25 "listen" program (or axlisten for you Debian users) that comes with ax25-apps package. It acts like a sniffer on your AX.25 interfaces but it has a few key differences to the listen program: - ax25spyd is now split into two pieces (client and server): ax25spyd - The daemon runs as the root user and provides all network socket connections to ax25spy clients. This design allows other programs that previously required to be run as ROOT to now run as a regular user (this is a more secure design) - The daemon can detect transit packet messages and send them to a SMTP host - The daemon can capture all traffic on a per-callsign basis (not just all traffic on a given frequency) and put this filtered view it in a SRC to DST callsign named file: /var/lib/ax25/ax25spyd/call1->call2 ax25spy - The ax25spy client which communicates to the ax25spyd daemon - displays decoded AX.25 packets much like the ax25apps "listen" does - Can display packets similar to a DX-cluster display - Can change it's view to just show various AX.25 packet types like I, UI, IP, show unique QSOs, etc Debian has a patched version of the ax25spyd code that's more modern than the official version posted at http://linkt.de/ax25spyd/ . This updated version works with modern Linux kernels and libraries. Let's use that version with Centos: cd /usr/src/redhat/SOURCES wget http://linkt.de/ax25spyd/ax25spyd-0.23.tar.gz #Get the patch files from the Debian sources wget https://cloudfront.debian.net/debian-archive/debian/pool/main/a/ax25spyd/ax25spyd_0.23-8.diff.gz #Alternatively, you can find the patches from my site too wget -r -l1 --no-parent -nd -A ax25spy www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ #Next, download my ax25spyd.spec file from: cd /usr/src/redhat/SPECS wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ax25spyd.spec #Ok, time to build it: #for 64bit systems rpmbuild -bb --target=x86_64 ax25spyd.spec #or for 32bit systems rpmbuild -bb --target=i686 ax25spyd.spec NOTE: ----- I have seen a strange transient error where the compile will FAIL with errors like: -- cd . && automake --gnu Makefile configure.in:4: your implementation of AM_INIT_AUTOMAKE comes from an configure.in:4: old Automake version. You should recreate aclocal.m4 configure.in:4: with aclocal and run automake again. make: [Makefile.in] Error 63 error: Bad exit status from /var/tmp/rpm-tmp.sbVtCD (%build) -- I found if you try building the RPM several times times back to back, the compile will eventually succeed anyway. Dunno why and it's still happening as of 10/16/12! Maybe this is an issue with the older Automake shipped with Centos6?? Anyway, let's move on: # Now go ahead and install it #for 64bit systems rpm -ivh /usr/src/redhat/RPMS/x86_64/ax25spyd-0.23-8.1.el6.x86_64.rpm #for 32bit systems rpm -ivh /usr/src/redhat/RPMS/i686/ax25spyd-0.23-8.1.el6.i686.rpm If you AREN'T going to build things via the SPEC file, follow this workflow: ------------------------------------------------------------------- cd /usr/usr/redhat/BUILD tar xzvf ../SOURCES/ax25spyd_0.23.orig.tar.gz gunzip ../SOURCES/ax25spyd_0.23-8.diff.gz patch -p0 < ax25spyd_0.23-8.diff ./configure make NOTE: I've seen strange transient build error (shown above)): -- To work around this, I ran "aclocal" which didn't give any output, I then deleted the ax25spyd sources in /usr/src/redhat/BUILD, re-untared the archive, and patched them and then re-did the configure and make and things worked fine Ok, now with ax25spyd installed, try running src/ax25spyd as the root user for a moment: NOTE: You can invoke "ax25spyd -s" which will create unique files in /var/lib/ax25/ax25spyd\ for per-callsign detail Info: ----- Linpac: The Ncurses Linpac terminal program will automatically connect to the ax25spyd daemon as an alternative to trying to use the ax25 listen daemon (which requires ROOT access) LinKT: The KDE-based LinKT terminal program has a packet monitoring program called MonKT that uses the ax25spyd daemon NOTE on Logging: ---------------- Fldigi supports exporting it's QSO logs to both EQSL and LOTW. In addition to this native support, you can use external logging programs such as Xlog to automatically upload your logs to LOTW, EQSL, etc. If you want to use Xlog, you must be running Fldigi 3.20.21 or newer Notes about Fldigi on centos5 ----------------------------- Performance ----------- I have seen where fldigi running on slower machines (1.7Ghz Pentium-M) can have the annoying problem where if Firefox or Chrome is open and is specifically running a web page loaded with JavaScript. A big offender ironically seems to be QRZ.com: a. Fldigi can get stuck when you try to transmit. The program becomes very slow and it eventually asserts PTT but it won't start transmitting any digital tones, etc. You can hit the ESC to abort the TX but it can take 5-10 seconds to release PTT. The ONLY solution to solve this after it starts happening is to first shutdown FF/Chrome and then completely restart Fldigi. Fldigi 3.20.x does NOT fix this. Contesting ---------- If you ever want to try contesting with Fldigi, make sure you have Configure --> Contest --> Duplicate Check : ON with at least the MODE box checked. New FLdigi compile time features ------------------------------- New behind-the-scenes compile-time features are added into fldigi all the time so I recommend you manually run it's configure script via "./configure" and not just install the newest binaries to see what new options have been added. If you want something that might be disabled by default, you'll need to modify the SPEC file or manually compile it to reflect the change. Ok, let's get down to it! +-----------------------------------------------------------------------+ | NOTE: | | The following example assumes Fldigi 3.21.36 and Centos6 but Centos5 | | is specifically called out as well | +-----------------------------------------------------------------------+ Download the sources -------------------- # NOTE: # As of 3.21.35, Fldigi now supports more modern Fltk tool kits. I do # NOT recommend you install older versions of the Fltk toolkits cd /usr/src/redhat/SOURCES #Getting the version 4.0.2 - change the version number to match the newest # release version available wget -O fldigi-4.0.2.tar.gz https://downloads.sourceforge.net/project/fldigi/fldigi/fldigi-4.0.2.tar.gz It's recommended to download and use my TrinityOS SPEC file (which enables the kitchen sink for Fldigi): cd /usr/src/redhat/SPECS wget -O fldigi.spec \ http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/fldigi.spec +------------------------------------------------------------------------+ | If you choose use my SPEC file (recommended), you will STILL NEED to | | follow all the below dependency steps to ensure your machine has the | | additional required packages to both compile and install Fldigi. | +------------------------------------------------------------------------+ Alternatively, you can follow the below steps to manually build your own without doing the final compile/install via RPMs. You'll still need to fill in the various requirements at "configure" time and compile, install, and configure Fldigi itself at the end of this section. ------------------------------------------------ Building up your own SPEC file (not recommended) ------------------------------------------------ This section is only useful to understand how I started to build my Fldigi SPEC file. There is little value in this section otherwise than maybe comparing what I'm doing to your build creation file (SPEC, deb, etc) - The last fedora package I saw was using Fldigi 3.10 which very very old as 3.12.5 was current at that time. Grabbing the Fedora SPEC file still helped a lot to start things off - Using the Fedora fldigi.spec file has non-identified errors and will die with errors like: -- error: Installed (but unpackaged) file(s) found: /usr/share/man/man1/fldigi.1.gz to fix this, find the line -- %{_datadir}/pixmaps/ -- and add the following under it (flarq is new to 3.12.4) -- %{_datadir}/applications/flarq.desktop %{_mandir}/man1/fldigi.1.gz %{_mandir}/man1/flarq.1.gz -- to improve the build, replace the configure line with: -- %configure --enable-optimizations=native make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" -- NOTE: Changes between my older Fldigi 3.12.5 for Centos 5 and the and the newer Fldigi 3.20.11 for Centos 6 notes: 1. In the 3.12.5 build notes, I used %configure --enable-optimizations=native which seems to throw warnings that the resulting code would be using legacy i80387 FPU instructions. It turns out this was an issue with the older Centos5 compilers and using "native" is both recommended and enabled at the beginning of this document and via the /etc/rpmrc file. 2. Starting in the 3.20.11 notes, I've added support for the xmlrpc system which is used by the excellent Flrig rig control program but Hamlib works as well. 3. LEGACY (no longer needed): The old Fldigi 3.20.11 now REQUIRES the obsolete and deprecated fltk 1.1.9 toolkit though the Fldigi docs say it should work with 1.1.7. It's not true. ------------------------------------------------------------------------ NOTE: If you're upgrading from an older version of Fldigi, make sure to : 1. make a copy of the old SPEC file, for me I do: cp /usr/src/redhat/SPECS/fldigi.spec \ /usr/src/redhat/SPECS/Old/fldigi.spec 2. update the SPEC file to: a. use the newer source tarball version b. update the changelog section to reflect your changes Next, regardless of using my SPEC file your you building your own, make sure the version number reflects the current version of Fldigi Netrom - Netrom is a protocol that rides over AX.25 and has two main purposes 1. advertise known local neighbors with an associated link quality in periodic "netrom" route updates 2. connect to remote stations found in the netrom route table without requiring the user to know each of the hops to get to that final destination To configure Netrom on Linux, first you need to configure the /etc/ax25/nrports file. In this example, the sole line configures SSID -5 which will announce the "SCLARA" node alias using the netrom interface called "netrom" which will resolve back to KI6ZHD-7 for netrom connections. The first configured item in that file is the netrom DEVICE which nothing can connect (this is similar to the "ax0" interface that's configured but never directly used. The next parameter is the callsign that is used when both advertising netrom routes (both locally generated and optionally re-advertised routes) and is the source callsign used when making Netrom connections. In this example, I'm using an SSID of -5 for my outbound connections which is common for Northern California Netrom nodes. NOTE: The man pages speak of putting a # in front of the NetROM alias of "SCLARA" to mean it won't ever be announced by the NetRom system. I'm not sure if the # trick is working as I still see SCLARA / KI6ZHD-5 getting announced NOTE2: All of these "aliases" listed here must be UNIQUE to the netrom table in your area. Please make sure you MONITOR your chosen frequencies and netrom systems before choosing these names. Here in Norcal, the general recommendation is to have a netrom alias that calls out your general location. NOTE3: blank lines in this file are NOT legal!! -- # /etc/ax25/nrports # # The format of this file is: # # name callsign alias paclen description # netrom KI6ZHD-7 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-advertised - def_qual - this "default quality" is the initial value we first set to the route - worst_qual - minimum quality of a received route to be added to the local netrom table - verbose - A setting of verbose=0 will NOT advertise learned routes and only advertise locally generated routes (ourself). A setting of "0" is a GOOD default until you a) have a good handle on NetROM routing and b) you're machine has good reachability to other nodes and your system can handle the potential transit traffic -- # /etc/ax25/nrbroadcast # # The format of this file is: # # ax25_name min_obs def_qual worst_qual verbose d710 5 190 100 0 -- Next, bring up the netrom interfaces by issuing: /sbin/modprobe netrom /usr/sbin/nrattach -i 44.4.10.40 netrom -------------------- VERY IMPORTANT NOTE: -------------------- After running each one of those nrattach lines (if you have multiple), you should get a new "nr" device like nr0, nr1, nr2. If you don't a unique device and instead each line reuses nr0, you're running a buggy version of the ax25-tools package! The solution to this is to either add a patch (discussed in the section where this document covered the installation of the ax25-tools package OR (probably the more recommended way if you're starting from scratch), use newer versions of the AX tools (be it the CVS version "official AXTools" (last updated June 2011), the FPAC / F6BVP version, or the VE7FET version posted on Github. -- Finally, to get the netrom service running, issue the commands where: -i : will send a netrom route update immediately -l : turns on logging for both programs -t 30 : send updates every 60 minutes /usr/sbin/ax25d -l /usr/sbin/netromd -i -l -t 60 # NOTE: These commands are fully integrated into the master packetrig.sh script Make Netrom connections locally: ------------------------------- As part of the ax25-apps package, the "call" program can make direct Netrom connections. The man page eludes to this but what if fails to mention that for the "port", you need to use the netrom device as defined in /etc/ax25/nrports! As an example, if I make a regular AX.25 connection with: call d710 woody I would make a netrom call by doing the following: call netrom wbay I bet you might be able to create Netrom connections via Linpac but you need to be able to change the port from say "d710" to "netrom". You might be able to do this on a per-F-key basis but I haven't looked. Two other useful programs: - nrparms :: manually create NetROM routes - nodesave :: Store (and optionally reload) learned netrom routes -- If you have a machine running a long time on a frequency and it's stored up a long list of NetROM routes, you can SAVE them from the /proc/net/nr_routes file with this tool which creates a shell script that you can simply run to restore these routes if you had to reboot, etc. Do be careful about this and try not to use very old saved tables as nodes come and go all the time! For example, I use: /usr/sbin/nodesave /var/ax25/nr-routes-145050.sh +----------------------------------------------------------------------------------------------+ | You can learn more about making direct Netrom connections, etc via this separate doc: | | | | http://www.trinityos.com/HAM/CentosDigitalModes/misc/145.050-netrom-and-tcpip-connects.txt | +----------------------------------------------------------------------------------------------+ Important note: --------------- To help make all of this easy and reliable, ALL of these configurations are already present in my TrinityOS packetrig.sh master shell script! An AX.25 node program allows remote users to connect to your machine, run various local programs as well as initiate connections from your machine on to remote machines. This connect and initial approach is superior to digipeating as each hop can do per-link retries. This is compared to digipeating where the source station has to send complete end to end retries all the way through the path. This method is quite error-prone and rarely works over paths with more than THREE digis. It's also more common to connect to a node via Netrom connections vs. say a standard AX.25 connection but both approaches are supported. There are at least five Node programs out there for Linux that I am aware of. These are listed in general order from recommended to not recommended: - Uronode - [ Recommended ] A heavily modified version of Awznode that has additional features such as Flexd for Flexnet routing code beyond all the features available in Linuxnode. A very powerful node program. - Actively maintained - FPAC - Part node, part ROSE protocol daemon, part packet switch. I haven't used this program much but it's heavily used in Europe. Well supported and cross supported with the FBB BBS software http://www.f6fbb.org/fpac/fpac.html - Actively maintained - FlexNet - A very powerful packet switch / routing system that is heavily deployed in the Eastern United States and Europe. It has several common attributes to the ROSE protocol specifically being more efficient, more intelligent than Netrom, etc. Supported via the Linux's flexd daemon, Xnet, and other packages. - Linuxnode - [ Not Recommended ] Also named '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. Quite powerful. It works but previously had KNOWN security issues. It's unclear if those security issues have been resolved. - Generally not updated anymore - Awznode - [ Not Recommended ] A fork of the original Linuxnode that added several major features but was abandoned. See below for supported commands. - Abandoned code - Unode - [ Not Recommended ] A fork of the previous available version of UroNode 1.x software available at: https://github.com/kd1zd/Unode/tarball/master - Was created because active development and availability of UroNode had ceased. This is no longer the case. - Was never actively maintained and now abandoned You can read about other nodes, what made them unique, their prompts, etc. here: http://www.proaxis.com/wagnerj/ka7ehk/map/noderef.html Uronode ------- The Uronode software offers not only a NODE interface for remote users to hop packets off your system but also offers many other features. For example, here is the main prompt given to a remote user: -- ?, Bye, Connect, Desti, Escape, Finger, Help, HOst, Info, INTerfaces Links, MHeard, MSg, Nodes, Ping, Quit, Routes, SEssions, Status Telnet, Users, Version, Who, WInlink -- Unode is also extensible and you can add additional node commands by calling other local Unix commands. For example, I've also seen machines setup to allow for the following: -- ?, Bye, CAllbook, CLuster, Connect, CONVers, Escape, Finger, Help, HOst Info, Links, Mheard, NLinks, Nodes, PIng, Ports, Routes, Status, TAlk Telnet, Users, ZConnect, ZTelnet -- -- LinuxNode - Comes as part of ax25-tools (for historical comparison) ------------------------------------------------------------------- Supported commands are: ?, Bye, Connect, Escape, Finger, Help, HOst, Info, Links, Mheard NLinks, Nodes, PIng, Ports, Routes, Status, TAlk, Telnet, Users, ZConnect ZTelnet Awznode (for historical comparison) ---------------------------------- Supported commands are: !, ?, Bye, Connect, Dest, Escape, Finger, Help, HOst, Info Links, MHeard, MSessions, Nodes, PIng, Ports, Routes, Send, TAlk, Telnet Users Setting up UroNode ------------------ Anyway, for this document, we're going to setup Uronode. To get the software, you can either get it directly from SourceForge.net or from N1uro.net but then it needs to be cleaned up a bit: # Get the newest sources and patches - Using 2.5.1 as of this writing # cd /usr/src/redhat/SOURCES wget http://downloads.sourceforge.net/project/uronode/uronode-2.5.1.tgz # Next, get the SPEC file for this: # wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/uronode.spec # Now that you have the SPEC file, modify it to make sure it matches with # your downloaded version of UroNode, etc. Version: 2.5.1 So what's in the patches? a) the configure script is an interactive ncurses script and not a configure script that an automated system would expect. One patch changes this to make it automation friendly #Ok, time to build it: #for 64bit systems sudo rpmbuild -bb --target=x86_64 uronode.spec sudo rpm -Uvh /usr/src/redhat/RPMS/x86_64/uronode-2.5.1-1.x86_64.rpm #for 32bit systems sudo rpmbuild -bb --target=x86_64 uronode.spec sudo rpm -Uvh /usr/src/redhat/RPMS/i686/uronode-2.5.1-1.i686.rpm If you previously had an older UroNode installation you may receive warnings like: -- warning: /etc/ax25/uronode.perms created as /etc/ax25/uronode.perms.rpmnew warning: /etc/xinetd.d/uronode created as /etc/xinetd.d/uronode.rpmnew -- If you receive any of these warnings, please review the differences in the config files. I would recommend to review it by using commands like: diff -u /etc/xinetd.d/uronode /etc/xinetd.d/uronode.rpmnew It's worth noting that UroNode includes several other utilities that might be useful but aren't covered in this document: axdigi - a simple packet digipeater calibrate - tool to properly set your levels for proper FM deviation flexd - a FlexNet routing client (does NOT include the routing server; it's recommended by N1URO to run the pc/FlexNet program in the DOSEmu application. The alternative Xnet program that does have a Linux port has only been released in binary form and those binaries are too old to use on modern operating systems. It's understood that the developer's consider this code as private and will not release the sources. As such, Linux doesn't have many other options to support Flexnet. Configuring UroNode ----------------- The UroNode RPM installs several configuration files in /etc/ax25: - Make sure the nrports and nrbroadcast files are configured as mentioned in the previous section /etc/ax25/uronode.conf - the main configuration file - In this file, you need to change the following: - IdleTimeout : leave this value at 900 (15min) - ConnTimeout : leave this value at 600 (10min) - HostName : to reflect your callsign - in my case, it's set to ki6zhd.ampr.org Ideally, you have already requested an AMPR IP address through your local AMPR coordinator. If you don't know how, email me and I'll help you out with this very simple process - Email : Address to reach you over the internet. Change this to use whatever email address you use - LocalNet : If you have an AMPR address, put it in here with the right subnet mask. if not, give it a unique IP that is in the RFC1918 range with a /32 mask. In my case, it's set to: 44.4.10.40/32 - Alias : This section contains all the command aliases to run Linux programs over Telnet. This is where the power of Uronode comes in. Most of the pre-defined entries are ok assuming you're ok to allow users to use your internet connection to check on callsigns, connect to a remote Converse server (like IRC), etc. You might need to disable the following two lines: #Alias DXCluster "connect dxnet" connect dxnet unless you have a DX packet cluster configured on your system. Removing the second line is to remove a duplicate "quit" entry in the "help" output (it's redundant). Any aliases added here will automatically show up in the Uronode "help" when a user requests help - HiddenPorts : Allows Sysops to disable the showing of ports. Disabled by default - ExtCmd : Similar to aliases, you can invoke Linux commands from packet connections. Any aliases added here will automatically show up in the Uronode "help" when a user requests help. I do recommend to disable the default example by adding a # in front: #ExtCmd NEstat 1 nobody /bin/netstat netstat --inet Why? Remote HAMs don't need to see what remote Internet connections you have on this computer. - NodeId : replace XXXXXX:XX#XX-# to your desired node alias, callsign with SSID. For me, the ALIAS to my node (as setup in the /etc/ax25/nrports fle is: SCLARA:KI6ZHD-5 - FlexId : This is the CALLSIGN and SSID for both proper station identification and Flexnet routing. This must be configured and align to your Netrom CALLSIGN+SSID. For me, I'm using: FlexId KI6ZHD-5 - NrPort : Outgoing interface name used for NetROM connections. This should reflect the netrom interface name defined in /etc/ax25/nrports. In my setup, it's called "netrom" but make it match whatever you have in the /etc/ax25/nrports file. It should NOT be low level devicename, "nr0" - LogLevel : once your comfortable with the setup, you should drop the logging level from 3 to say 2 If you have specific questions, do a "man uronode.conf" and "man uronode" ---------------------- Other important files: ---------------------- uronode.motd - the message displayed when users connect to it - Update it to reflect your setup uronode.info - the message displayed when users issue the "info" command - Update it to reflect the technical setup of your setup. Your specific radio, antenna, etc. uronode.perms - permissions - When a remote user connects to Uronode, it can present the user with a slew of commands to run depending on the default or explicit per-callsign permissions. The permission number is a binary value assuming a bitfield reading from right to left. You set the bits you want and then add them all up and that is your value. For example: bit bit bit bit bit bit bit bit bit bit 512 256 128 64 32 16 8 4 2 1 --- --- --- --- --- --- --- --- --- --- Uronode default: no no no no no yes yes yes yes yes == 31 My recommendation: no no no no no yes no yes yes yes == 23 I recommend to # out all lines for any pre-defined users and CHANGE the default permission items to the following. # user type port passwd perms ax25 23 netrom 23 rose 0 local 23 ampr 23 inet 23 host 23 You can have PER callsign permissions if you want but for now, my defaults are the following as callsigns are easily spoofed. See the uronode.perms man file for full details but the following "perms" value of "7" will setup: bit# 1 - permits logging in even if no other more-specific permissions are given bit# 2 - permits outgoing AX.25 / Flexnet connects bit# 4 - permits outgoing NET/ROM connects bit# 8 - DOES NOT permit telneting to hosts in the "local" network as defined in uronode.conf(5). bit# 16 - permits telneting to other hosts out in amprnet (only enable if you have a working AMPR.ORG connection running) bit# 32 - DOES NOT permit telneting to other Internet hosts neither in the "local" network nor in amprnet (aka, general hosts on the Internet, etc) bit# 64 - DOES NOT permit using hidden ports in outgoing AX.25 and Flexnet connections bit#128 - DOES NOT allow outgoing ROSE connects (not configured yet) bit#256 - Leave the escape mechanism (disconnect from the remote service and reconnect to the master uronode command prompt still functional bit#512 - ANSI colors - Leave unset to DISABLE this as it's always unclear if the remote station can display ANSI colors. You can enable this on a per callsign basis Linpac supports colors but it's unclear if Putty, Hyperterminal, Outpost's ip serial, UISS, etc can uronode.users ------------- - If you want to allow specific remote Sysop access to your machine, you can configure per callsign logins with passwords to allow those user's Linux shell access. Please remember that their password will be shown in CLEARTEXT over the airwaves. As such, any lurkers could later log in as their callsign, use the password, and then have shell access to your Linux machine. NOT a great idea and NOT recommended uronode.routes -------------- - This file allows to configure pre-defined AX.25 or Flexnet destinations so users don't have to specify a specific interface to make the connection on ax25d.conf ---------- Next, when an incoming Netrom connection session connects, we need to configure the /etc/ax25/ax25d.conf file to tell Linux what to do with it. This file is very similar to the /etc/xinetd.d or /etc/inetd.conf systems that associates incoming TCP connections to the correct daemons. This file is for controlling AX25/Netrom/Rose/Flex RF links. When a given RF connection packet comes in with the matching destination callsign and SSID, this file will match the CALL+SSID to the configured program and start it up. IMPORTANT NOTE: --------------- Every SSID in use on Linux must be unique and this can get confusing for some people coming from a hardware TNC background. Specifically, the SSID used in the nrports file to broadcast Netrom routes can only be used for Netrom connections. This chosen SSID CANNOT be also used to connect to via an AX.25 connection. This behavior is different from say a KPC3 hardware TNC which does allow for this double use. For my specific configuration, I want the SCLARA Netrom node to be associated with KI6ZHD-5 yet allow AX.25 connections to my "d710" AX.25 connection on KI6ZHD-7 SSID. /etc/ax25/axports file. See the packetrig.sh script's comments for full technical details. To support running the Uronode software, the second stanza is required: /etc/ax25/ax25d.conf -- #To allow connections to KI6ZHD-5 from a AX.25 connection [KI6ZHD-7 VIA d710] NOCALL L default - root /usr/sbin/urnode uronode #To allow connections to SCLARA from a AX.25 connection <netrom> NOCALL L default - root /usr/sbin/uronode uronode -- NOTE #1: Previously, I had an entry in the ax25d.conf file for "[SCLARA VIA d710]". This was wrong as SCLARA is a NETROM device but it was surrounded by [ ] brackets which means AX.25. It also seems that when specifying netrom devices with < >, you cannot use the "VIA d710" syntax. With those errors, I was seeing the following error when trying to make outbound connections from Uronode: ERROR: connect_to: bind: Cannot assign requested address It's key that the NETROM device (for me, it's "netrom") as defined in /etc/ax25/nrports be enclosed in the < > characters NOTE #2: Unless you've previously started the ROSE daemon for Rose routing, starting up ax25d will error out complaining about the "rsports" file missing. Simply run "touch /etc/ax25/rsports" and that will no longer be a blocking error. Local connections via TELNET: ----------------------------- If you want to enable the ability to connect to Uronode from a local telnet connection, you need to edit two files: /etc/xinetd.d/uronode - Edit this file and change disable to "no" Please note this file is created by my RPM spec file but it's not included by default with the stock Uronode sources. /etc/services - This file correlates the TCP socket to an application name. -- uronode 3694/tcp # AX.25 Uronode -- To get everything recognized, you need to restart xinetd: /etc/rc.d/init.d/xinetd restart AXPARMS: -------- If you plan on connecting to Uronode locally from the shell and your Linux username is NOT your callsign, you're going to have a problem. To work around this issue you can use something like the following command to associate your Linux username ("dranch" in this example) to a callsign (KI6ZHD): axparms -assoc KI6ZHD dranch This is already setup in the packetrig.sh script so it's recommended to enable that command via that script Starting it all up: ------------------- That's it! The last key thing is to have the "ax25d" daemon running to listen to connections. You can manually start it as the root user with: /usr/sbin/ax25d -l If you reboot your computer, that daemon will not restart automatically. I recommend you use the hampacket.sh script that will do this all for you upon every reboot. Using local connections: ------------------------ - If you try to use "telnet localhost 3694", you might get the response: -- Trying ::1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. -- What's happening here is that Centos is defaulting to IPv6 which URONode doesn't support as of this writing. Use your IPv4 address found in the output of "ifconfig". NOTE: If you had configured Linpac (previous section) to use the -5 SSID, you should unconfigure that to avoid any conflicts in the /Linpac/macro/init.mac file ------------------------------------------------------------------------------- Unode - [ Abandoned ] - Configuring the legacy Node fork ------------------------------------------------------------------------------- [ Abandoned ] - This section is kept in for historical reasons: cd /usr/src/redhat/SOURCES wget https://github.com/kd1zd/Unode/tarball/master #Next, lets rename it and update it to reflect a new version mv master kd1zd-Unode-f685a9a.tar.gz #This is v1.0.0-1 cd /usr/src/redhat/BUILD tar xzvf ../SOURCES/kd1zd-Unode-f685a9a.tar.gz mv kd1zd-Unode-f685a9a Unode-1.0.1 tar czvf ../SOURCES/Unode-1.0.1.tgz Unode-1.0.1/ NOTE: The "configure" script in the Unode package is: a) a Shell script and not the normal configure script that you would expect. It's interactive and thus can't be automated b) If run, will call everything UroNode where as the pre-configured Makefile will call everything "Unode". c) It seems this package includes a previously compiled version of axdigi from the original FlexNode package but I have no idea if this will run. I would recommend to later DELETE this file and compile up your own from this "Flexnode" package NOTE#2: To fix many of those issues (and several others), I've posted several patch files at the following URL and they are REQUIRED if your going to use my spec file shown below: cd /usr/src/redhat/SOURCES wget http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/Unode #Get the spec file from my directory # cd /usr/src/redhat/SPECS wget -o unode.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/Unode.spec #Get all the patches too.. cd /usr/src/redhat/SOURCES wget -r -l1 --no-parent -nd -A Unode www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ #Ok, time to build it: #for 64bit systems rpmbuild -bb --target=x86_64 Unode.spec rpm -Uvh /usr/src/redhat/RPMS/x86_64/Unode-1.0.0-1.x86_64.rpm #for 32bit systems rpmbuild -bb --target=x86_64 Unode.spec rpm -ivh /usr/src/redhat/RPMS/i686/Unode-1.0.0-1.i686.rpm Once installed, the RPM installs several files in /etc/ax25: - Make sure the nrports and nrbroadcast files are configured as mentioned in the previous section +-----------------------------------------------------------------+ | [ Abandoned ] - This section is kept in for historical reasons: | +-----------------------------------------------------------------+ Configuring Unode ----------------- unode.conf - the main configuration file - In this file, you need to change the following: - IdleTimeout : leave this value at 900 (15min) - ConnTimeout : leave this value at 600 (10min) - HostName : to reflect your callsign - Ideally, you have already requested an AMPR IP address through your local AMPR coordinator. If you don't know how, email me and I'll help you out with this very simple process - ReConnect : This is optional but I personally like to set this to ON. With this, when the user disconnects from a remote station, they will drop back to your node - LocalNet : If you have an AMPR address, put it in here with the right subnet mask. if not, give it a unique IP that is in the RFC1918 range with a /32 mask - NodeId : replace OH2BNS-10 to your callsign. For me, I set it to the following where the first parameter is an ALIAS to this node (if you set one in /etc/ax25/nrports and the next one is your callsign+SSID for the node. For me: SCLARA:KI6ZHD-5 - Alias : I recommend you DISABLE any pre-defined Aliases with a # until you a) know what commands you want b) have an operational AMPR connection (for some of these examples) and c) and understand the security implications. Any aliases added here will show up in the "node" interface when people are connected to it - ExtCmd : I recommend to disable any pre-defined Aliases with a # until you know what you want and understand the security implications. Any aliases added here will show up in the "node" interface when people are connected to it - NrPort : Outgoing interface name used for NetROM connections. The default is "netrom" but if not defined here, it will either use the FIRST entry in /etc/ax25/nrports or you can make it match something ELSE in the /etc/ax25/nrports. I'm using my configured alias of: SCLARA - LogLevel : once your comfortable with the setup, you should drop the logging level to say 2 - NodePrompt : DEPRECATED - not sure if this is honored anymore I recommend to # out the top \n example and re-enable the bottom one for now with the full string but change the callsign to reflect your own: "\nSCLARA:KI6ZHD-5} " If you have specific questions, do a "man node.conf" and "man node" unode.motd - the message displayed when users connect to it - There isn't much to change in this one unode.perms - permissions - When a user connects to Unode, it presents the user with a slew of options as shown at the beginning of this section. I recommend to # out all lines for any pre-defined users and CHANGE the default permission items to the following. # user type port passwd perms ax25 7 netrom 7 rose 7 local 7 ampr 7 inet 7 host 7 You can have PER callsign permissions if you want but for now, my defaults are the following as callsigns are easily spoofed. See unode.perms for details but the following "perms" values is for: - permits logging in even if no other permissions are given - permits outgoing AX.25 / Flexnet connects - permits outgoing NET/ROM connects - permits outgoing ROSE connects. - DOES NOT permit telneting to hosts in the "local" network as defined in node.conf(5). - permits telneting to hosts in amprnet (only enable if you have a working AMPR.ORG connection running) - DOES NOT permit telneting to hosts neither in the "local" network nor in amprnet (aka, hosts on the Internet, etc) - DOES NOT permit using hidden ports in outgoing AX.25 connections - Escape mechanism for this user is still enabled - No ANSI colors - who knows what the remote users are using. Linpac can deal with it but can Outpost, ipserial, UISS, etc? The defaults are the following (which I think are WAY too open) --------------------------------------------------------------- # user type port passwd perms ax25 31 netrom 31 local 31 ampr 31 inet 0 host 31 node.info - details on your station - Edit this file to give some info on your station ax25d.conf ---------- The final file we need to configure is the /etc/ax25/ax25d.conf file. This file is very similar to the /etc/inetd.conf file but for AX25/Netrom/Rose/Flex RF links. When a given RF connection packet comes in with the correct destination callsign and SSID, this file will match the CALL+SSID to the configured program and start it up. For my specific configuration, I want the node to be associated with KI6ZHD-5 to my "d710" AX.25 connection (see the packetrig.sh script for full details). To support running the Linuxnode software, the second stanza is required: ax25d.conf -- #To allow connections to KI6ZHD-5 from a AX.25 connection [KI6ZHD-5 VIA d710] NOCALL L default - root /usr/sbin/node node #To allow connections to SCLARA from a AX.25 connection [SCLARA VIA d710] NOCALL L default - root /usr/sbin/node node #To allow connections to SCLARA from a Netrom connection <netrom> parameters 1 10 NOCALL L default - root /usr/sbin/unode unode -- That's it! NOTE: If you had configured Linpac (previous section) to use the -5 SSID, you should unconfigure that to avoid any conflicts in the /Linpac/macro/init.mac file NOTE#2 When you eventually start up ax25d and it complains about the rsports file for the Rose protocol, simply run "touch /etc/ax25/rsports" and that will no longer be a blocking error ------ 09/09/11 - New issue with Unode If I netrom OUT of my machine to WBAY, come back into it via SCLARA, and then try to netrom BACK out to another machine, I get: c WSTGAT ERROR: connect_to: bind: Cannot assign requested address ------ ------ Previous Issue with Unode (resolved in an above patch and the packetrig.sh script: ------ - If you try to run /usr/sbin/unode locally on the machine and you get: $ /usr/sbin/unode Segmentation fault (core dumped) This means two things. One, you didn't apply the Unode-local-execution-coredump-fix.diff patch from Steven, K6SPI as found in http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES/ Alternatively, you can work around this issue with putting the following command in your packet startup script. For this setup, I put the following in the packetrig.sh script for my callsign to username correlation: axparms -assoc KI6ZHD dranch - The symptoms: I have determined that if you run Unode from localhost, the program will coredump but it works fine via external RF links. I'm researching this but it's not a fatal issue as ax25d will dynamically spawn new connections as needed. Here is my ongoing troubleshooting for this issue and this will be removed once I resolve the issue: -- 1. I had to modify the spec files for unode and libax25 to add the following line to be line #1: %define debug_packages %{nil} and then recompile those RPMs and install them. Additionally, install the following debug RPMS: yum --nogpgcheck --enablerepo=debug install glibc-debuginfo yum --nogpgcheck --enablerepo=debug install zlib-debuginfo [[email protected] ]# unode Segmentation fault (core dumped) [[email protected] ]# 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. This is a placeholder to get me started but it has NOT been integrated into the packetrig.sh script as of yet. NOTE: Depending on your selection of the ax25-apps that you installed, you might need to apply a patch or you will get fatal tunneling errors. This is discussed above in the AX.25 installation section 1. Update /etc/ax25/axports and define the ipct port This is currently another filename as /etc/ax25/axports-udp 2. /usr/sbin/kissnetd -p2 & - Please record the FIRST port and SECOND port out of that list for follow-on commands 3. /usr/sbin/kissattach -l /dev/pts/7 ipct 44.4.10.40 - In this example, /dev/pts/7 camesfrom the output of the kissnetd command above. 44.4.10.40 is my AMPR IP address and you need to put in your OWN IP address that you can get free from your local AMPR IP coordinator. NOTE: Your kernel MUST have legacy /dev/pty support for this work 4. From the output of command in step 2, take the SECOND port given (not the first port) and put that into /etc/ax25/ax25ipd.conf for the "device" line NOTE: socket ip - means proto 93 socked udp - mean UDP defaulting on port 10093 5. run /usr/sbin/ax25ipd 6. Per db0fhn security, you MUST log into Echolink via the same egress IP address (easily done via NAT) as this AXUDP connection. 7. Connect to the remote station: call ipct db0fhn Scripting the PTY values: 1. See the JNOS section of the packetrig.sh script 2. http://wiki.complete.org/LinuxPacketRadio#ax25ipd-1 3. Other HAMs have used the "socat" program to script this PTY setup As mentioned in the previous SoftTNC section, AGW/PE is a suite of software that is usually used for it's soundcard based TNC functionality for Windows. In addition to it's soft-tnc (and hardware based TNC) support, it also comes with a suite of programs to interact and troubleshoot with packet. One of these tools allows interacting with remote TNCs using the AGW API over TCP/IP network sockets which many other applications have adopted. These APIs use a TCP based protocol which can be run over various networks, this allows for very flexible configurations. Most of the Linux packet applications described in this document ONLY work with Linux's AX.25 stack but one non-Linux application does not: Outpost for Windows. The Outpost application which is described in a different section either runs the TNC from "command mode" or directly in t KISS mode. Either mode doesn't use Linux's AX.25 stack approach. Fortunately, Outpost supports the AGW API so this section documents how to get this working with LDSPED as the middle-ware. ---------------------------------------------------------------------------- NOTE: There are two ways to get AGW API support on to Linux: ---------------------------------------------------------------------------- #1 - Use a soft-TNC program. The Direwolf soft-tnc natively supports the AGW API. #2 - Use the LDSPED middleware. This requires you log into the author's website at http://www.on7lds.net/42/user and register. Once your account gets authorized, you can goto the Download link and download either the pre-compiled binaries or email the developer to get the sources Current LDSPED Functionality and compatibility: ----------------------------------------------- - AX.25 CONNECTED packets INBOUND only (no outbound support yet) - supports sending AX.25 UNPROTO packets in and out - Remote programs using the AGW API that are confirmed to work include: Outpost, UI-View, Xastir, UISS, Paclink, digi_ned. Please see http://on7lds.net/42/node/10 for a complete list Getting the LDSPED program is only officially available from the developer's website and requires that you setup an account on his website first. Alternatively, there seems to be a copy of the code on Github: https://github.com/ampledata/ldsped I recommend to get the official sources to honor the main developer's wishes so follow the prompts at: http://www.on7lds.net/42/node/12 to request and account, an hopefully it will be authorized pretty quickly. Once your account is created, go and download the code: - ldsped-1.16.tgz : 32bit pre-compiled program - ldsped64-1.16.tgz : 64bit pre-compiled program You'll notice there aren't any sources provided. ON7LDS did this on purpose but if you contact him, he was willing to provide the sources. Until then, try using the downloadable 64bit binaries for use with say Centos 6. If you'd like, I can email you my RPMs packages as well. Compiling LDSPED: ----------------- Assuming you have the sources, do the following: - Place the source .tgz into /tmp - Run the following commands to create a proper .tgz file cd /tmp mkdir ldsped-1.16 cd ldsped-1.16 tar xzvf ../ldsped-sources-1.16.tgz cd .. tar czvf /usr/src/redhat/SOURCES/ldsped-1.16.tgz ldsped-1.16 rm -Rf /tmp/ldsped-1.16 - Next, there are several patches required to make these sources compile on Centos / Fedora systems. There are enough changes needed for the autoconf system that it's just easier for you to just get them from below vs with: cd /usr/src/redhat/SOURCES wget -r --no-parent -nd -Aldsped http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SOURCES - Next, there isn't a .spec file included in the current version of Ldsped (I did send the author my .spec file if he was interested in including it). Go ahead and get my spec file: cd /usr/src/redhat/SPECS wget -o ldsped.spec http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/ldsped.spec - Ok, time to compile it up and install it: rpmbuild -bb --target=x86_64 ldsped.spec rpm -Uvh --force /usr/src/redhat/RPMS/x86_64/ldsped-1.16-1.x86_64.rpm Configuring Ldsped: ------------------- Ok, now lets configure it. Open up your favorite editor and edit /etc/ax25/ldsped.conf but keep in mind that I intend to use LDSPED as AGW API gateway ONLY. I don't intend to use any of it's APRS functionality so I disable all of it. If you do intend to use the APRS functions, make the required changes to suit your needs: - Ldsped's default R/W port is on port 8001 which doesn't follow norm so lets change that. Find the line "# define packet engine ports" and change the ports around to read: rw :8000 ro :8001 - Disable the station status line by putting a # in front of: #stationtext $V (check www.on7lds.net) - Disable ldsped from sending the "heard traffic" object traffic 0 - Under the "probesendport -1" line, add the following line to disable ldsped from replying from APRS probe packets. NOTE: this following line must show up as the LAST line probe 0 - Finally, there are a few scripts at the bottom that can be run by sending an APRSG query containing the command like "up" or "datum". If you don't want this, go ahead and # those lines out That's it! To run it, simply run: NOTE: ldsped must be run as root today /usr/sbin/ldsped The program will instantly run the background and send all logs to /var/log/messages. If there are issues, kill the running instance of ldsped and re-run it with: /usr/sbin/ldsped -dlllll (that's 5 slower case Ls) If you are using my packetrig.sh script, any of the profiles that use the ADVAX25 parameters as enabled via which beacon you choose to run will look and run ldsped if present and configured. Like any amateur radio transmission, all signals are broadcasted for all to hear and it's sometimes useful to monitor the packet traffic on a given frequency. In my packetrig.sh script discussed elsewhere in this document, it starts a promiscuous "listen" process in the background that decodes all heard packets and logs them to a file named /var/log/listen->date<.log. At any time, you can view, tail, etc. this file to see what's been going on. One minor issue is that the listen log doesn't give a full datestamp with it's entries. I've added the date-listen-log.sh script which will add a daily stamp which can help you track things. To use this script, copy that script into /usr/local/sbin and then issue the commands: chmod 744 /usr/local/sbin/date-listen-log.sh ln -s /usr/local/sbin/date-listen-log.sh /etc/cron.daily/ Pretty useful! The issue with monitoring this traffic is is that there is a LOT of redundant traffic on a channel with beacons, NETROM route updates, etc. With all that "noise", viewing logs can get very tedious. My solution is the filter-packet-listen-logs.sh that can be found at: http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/bin/filter-packet-listen-logs.sh This script needs to be modified by the reader to match your specific local stations but it does greatly reduces the amount of repetitive text that you probably don't want. It's structured to filter out individual beacons in one section and netrom updates in another section but also supports command line options to reverse this behavior as well. FUTURE: The "listen" process has the ability to color the text to make things far more readable but saving this color information into a log file makes parsing the data very difficult. As such, the packetrig.sh script disables this coloring. I hope to update the filter-packet-listen-logs.sh script to include the use of supercat to re-color the output to make the resulting filtered text more readable. http://supercat.nosredna.net/ +---------------------------+ | 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 immediately disconnects, this most likely means that the binary program (node, unode, etc.) as specified in the /etc/ax25/ax25d.conf file is improperly configured or isn't there. To confirm the network is listening, try the following commands: /sbin/ifconfig :: Shows all interfaces (I've removed my internal Ethernet ones ---------------------------------------------------------------- ax0 Link encap:AMPR AX.25 HWaddr KI6ZHD inet addr:44.4.10.40 Bcast:44.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
The main window where you can switch between SSIDs using the F-keys, see live decodes, etc:
Linpac is a great command-line packet terminal program using Linux's native AX.25 stack using an AX.25 TNCS in KISS mode. It seems to both emulate and surpass older premium DOS programs like the KaGold program, etc. Older Ka-Gold review: http://www.interflex.com/private/review1.htm Though you can use Linux's basic AX25 "call" program to connect to remote packet nodes, etc., Linpac offers quite a bit more: - It gives you a keyboard to keyboard interface for MULTIPLE people connecting to your station at the same time from one user interface - allows for 8 simultaneous inbound or outbound connections - notifies you when people connect to you - Supports a very easy to use UNPROTO mode - Offers a configurable three views to show received, sent, and promiscuous AX.25 decodes In the above screen capture: - The placement and color of each screen area is configurable - The main typing INPUT area is at the top (black text on a green background) - The blue line is the status of the current connection - showing my callsign, # of ACKed and NON-ACKed packets, etc - The main window color codes status messages (light blue), TX text (red), and RX text (green) - The next line is the connection line - the "1:" corresponds to the QSO or "stream" running on the F1 key. There aren't any current QSOs on F2, F3, F4, F5, F6, F7, or F8 but yes, you can have up to eight simultaneous QSOs! - There is also the F10 screen which is used for sending UNPROTO or UI packets - The bottom screen is the AX.25 monitor showing all TX packets (red), RX's packet frame data (green), and the RX payload (light blue) for the current frequency Able to view your inbox of incoming packet messages:
In the above screen capture: - Here on my LOCAL machine (UI is not currently available for remote users), you can see the INBOX and all of the received messages Able to READ but not reply to messages (this will be fixed..):
In the above screen capture: - Here you can read the various messages and if configured, send a reply Ok, let's get down to downloading and compiling Linpac: +-------------------------------------------------------------------------+ | There are TWO versions of Linpac available today: | | | | Active Branch | | 0.25 - Up to date, stable Ncurses UI - Current Recommended release | | | | Alpha Branch; not Active | | 1.0pre4 - a split client/server system with the Ncurses style UI | | from the previous Linpac but also a Java-based client UI | | This version is currently Broken but is being repaired. | | It's not currently covered in this document yet | +-------------------------------------------------------------------------+ 12/10/17 - Linpac 0.25 has been posted -- First wave of lowered the CPU load caused by Linpac's original design but more work is needed. Includes fixes to resolve Segfault issues found in very new versions of Fedora and Debian. Includes other code-related clean ups -- 11/19/15: Linpac 0.24 has been posted -- The new release is out has many compile fixes, some bug fixes, etc. and is the new version being added into the Debian repos -- cd /usr/src/redhat/SOURCES wget -O linpac-0.25.tar.gz \ https://downloads.sourceforge.net/project/linpac/LinPac/0.25/linpac-0.25.tar.gz +----------------------------------------------------------------------------+ | NOTE: Supporting local messaging | | | | Linpac can integrate with the axmail-utils package that can be found | | at https://sourceforge.net/projects/ax25mail/ . Linpac does NOT | | look / emulate a classic TNC's prompting or PBBS simple messaging. | | This program currently is designed to forward (proxy) messages | | to/from a FBB style BBS but it is able to receive local messages and | | display them for the local operator. It does NOT support letting | | remote HAMs pick up their messages at the moment. | | | | See the "AX.25 Packet Programs" section for more messaging tool | | options | +----------------------------------------------------------------------------+ Next, download the RPM SPEC file at: cd /usr/src/redhat/SPECS wget -O linpac-0.25.spec \ http://www.trinityos.com/HAM/CentosDigitalModes/usr/src/redhat/SPECS/linpac-0.25.spec +----------------------------------------------------------------------+ | NOTE #1: Issue with the ./configure script | | | | It seems linpac is hard coded to "listen" and not say | | finding Debian/Ubuntu's naming convention of "axlisten". n | | You can fix this in Linpac's src/constants.h file or more | | simply create a symlink pointing to the ax listen binary to | | listen: | | sudo ln -s /usr/bin/axlisten /usr/bin/listen | +----------------------------------------------------------------------+ +----------------------------------------------------------------------+ | NOTE #2 - TBD: Probably obsolete with 0.21 - researching | | | | NOTE #1: Issue with the ./configure script | | | | In the user's Linpac directory, the bin/ directory creates | | possibly wrong symlinks to /usr/local/share/linpac/bin | | You can fix this with the following command: | | | | ln -s /usr/local/share/linpac /usr/share/linpac | +----------------------------------------------------------------------+ Ok, now compile up the RPM: #for 64bit systems rpmbuild -bb --target=x86_64 linpac-0.25.spec #for 32bit systems rpmbuild -bb --target=i686 linpac-0.25.spec And now install it! #for 64bit systems rpm -ivh /usr/src/redhat/RPMS/x86_64/LinPac-0.25-1.x86_64.rpm A few more required steps: #To properly support local messaging, do the following as root # This will be eventually done via the RPM installer) mkdir /var/ax25/mail chmod 777 /var/ax25/mail #Future sections to expand on To support full FBB mail forwarding as well as support the :mail feature, you must compile and install ax25mail-utils first Before running Linpac for the first time, there are a few things to consider: Fixups before running --------------------- - Fixme: Before starting Linpac as a normal user (not root), you need to allow for users to create Lock files. To do this, run as root: touch /var/lock/LinPac.0 chmod 666 /var/lock/LinPac.0 Choosing what user to run Linpac as / Traffic Monitoring -------------------------------------------------------- - Linpac has the ability to show all real-time traffic on a given packet frequency in a section of the window. To show this real time traffic, you either need to: - Run the ax25spyd daemon as root as described in a previous section. If ax25spyd is running when Linpac is started, all Linpac configuration files are put into that user's home directory and this non-root users can see the traffic data. +---------------------------------------------------------------+ | NOTE: For general Linux security reasons, it's recommended to | | use the ax25spyd method and NOT run Linpac as the root | | user. | +---------------------------------------------------------------+ - 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 - You will not hear the connection and disconnection PC beeps Starting up Linpac for the first time ------------------------------------- - As above, you need to choose if you're going to run Linpac as a regular user as root. Once decided, become that user and prepare to run Linpac for the first time. - When you first run Linpac on the local machine, it creates a directory in the process owner (root or regular user's) home directory called "LinPac". In this directory, Linpac copies over all kinds of default files, etc. into their $HOME/Linpac directory. - Now that the various skeleton files have all be copied over, issue the command :sys to exit Linpac and return to the system. Now you will need to edit the config files Mail Forwarding --------------- NOTE: This section is NOT complete and there might be some missing steps. If you need help, please contact me - Linpac has a mail forwarding system built into it where it can do bulk uploads and downloads of messages from a different BBS. Once fetched, you can read and reply to messages all offline while not connected to any station. Once done, you and tell Linpac to send the messages and get any new ones. NOTE: This is NOT like a simple PBBS as found on TNC2/KPC3/etc TNCs If you want to use this feature, you need to have followed the previous section's instructions to get ax25mail-utils and ulistd installed. Once installed, need to do the following to get Linpac forwarding working. NOTE: It's good to know about the purpose of the following dirs: $HOME/LinPac/mail : where local messages are stored /var/ax25/ulistd : where ?message lists? are stored /var/ax25/mail : where message bulletins are stored 1. Choose a remote BBS that's on the same frequency as your packet station. Today, it seems Linpac supports FBB and TNOS as valid remote BBS types but there might be more. I hope to add simple KPC3 PBBS forwarding support into Linpac in the future. 2. Configure this station in the homeuser's Linpac/station.data file. For example, I'm using the K6FB-1 BBS: [K6FB-1] NAME=K6FB PBBS TYPE=FBB Linpac main configuration ------------------------- - Linpac is configured by the $HOME/LinPac/macro/init.mac file. In this file, you need to make several changes to fit your specific environment. You need to put in your proper: - AX.25 port name - callsigns and SSID to F-key mapping - unproto callsign and optional path - optional BBS forwarding call and ssid +--------------------------------------------------------------+ | NOTE: The Hampacket "packetrig.sh" script automatically | | switches Linpac configs based upon how it's started | | to select the correct ax.25 device, etc. | +--------------------------------------------------------------+ $HOME/LinPac/macro/init.mac -- ;;the default AX25 device name. For my packetrig.sh script with ;; VHF/UHF, it's named "d710" port d710 ;;Set the default terminal type to ANSI term ansi ;; Linpac's primary display view ;; ;; I prefer the following look where the type-in area is at the TOP ;; The status bar of the connection, AX.25 stats, etc SECOND ;; The area where you read the incoming text from the remote station THIRD ;; The connection bar that shows the different connected stations via F-key FOURTH ;; A large AX25 monitoring window at the bottom ;; ;; NOTE: The order that these lines are enter in MATTERS. If you ;; want a different layout, reorder the lines and restart ;; linpac statline 5 chnline 30 infoline 5 swapedit redraw ;;With LinPac, each F-key in a Linux terminal can be a different ;; connection and each on can have their unique SSID if you'd like. ;; Notice here that I have KI6ZHD (that's SSID -0) listed twice. Linpac ;; allows to have two DIFFERENT remote callsigns connected to the same ;; local -0 SSID ;; ;; Note : the F10 key is a dedicated screen where ALL UNPROTO can be sent ;; using the configured digi path ;; ;; Here in Northern California, I do NOT configure the -5 SSID as that's ;; used for the UrnoNetrom NODE as described in the NetRom section ;; [email protected] KI6ZHD [email protected] KI6ZHD [email protected] KI6ZHD-1 [email protected] KI6ZHD-1 ;;For unproto traffic, address it to the proper source and ;;destination -- Be sure to change this to your callsign unsrc KI6ZHD ;;For basic one-hop UNPROTO communications, don't use any digipeated paths ;; undest INFO ;;For multi-hop UNPROTO communications, you need to use digipeated paths. ;;Assuming you enabled the digipeat patch from above AND you live in the ;; South BayArea, California, I use the following path: ;; undest "David WOODY KBERR KTUO KMOC KBETH KLIVE KPAC" ;; Other settings - Allow the system to make a bell sound when remote users connect ;; Most modern PCs now have this PC speaker output wired to the soundcard ;; speakers but it requires your soundcard mixer settings to have the ;; "Speaker" and "Beep" outputs both unmuted and at a high audio level. ;; It seems the volume setting for Speaker doesn't change the levels but ;; the "Beep" levels do work. In very new kernels, they seem to need a new ;; "Loopback mixing" feature ENABLED to hear the sounds (it's off by default). ;; ;; To test these PC speaker or Beep sounds, run: sudo /usr/local/share/linpac/bin/bell ;; Yes, root level permissions are required to play sounds though ;; the PC speaker on modern kernels cbell on knax on ;; Required to be on or linpac won't accept any // commands from the remote user remote on infolevel 1 ;; Default QRG - A comment for remote stations - set whatever is your primary packet frequency set [email protected] "145.050 MHz" ;; Default set of commands to let users run - EVERY command must be in ALLCAPS ;; and if you want to allow lowercase commands, they also need to be present or ;; aliased in the macros/commands file set [email protected] "AB D E VER L RP B MH N RT YPUT W R WB RB A COMP CONV I H Q U CS SP SB" ;;Optional mail forwarding ;; Path to home BBS - the port name is REQUIRED ;; ;;The syntax is: ;; The ax25 port name as shown above, the @0 is Linpac's reserved F-key connection number, the ;; BBS name and it's proper SSID, and any additional digis required to reach the destination ;; to get to said BBS set [email protected] "d710:K6FB-2" ;; HOME_ADDR must be assigned or you won't be prompted for a subject ;; This example reflects using K6FB found in Northern California, CA, USA set HOME_ADDR "K6FB.#NCA.CA.USA.NOAM" -- Final Tweaks ------------ - It's important to recognize that ANY commands that you want remote users to run must be defined in ALL CAPS the init.mac "DEF_RCMD" file. For HamPacket packetrig.sh script users, please be sure to update all your macro/init.mac files to contain the required changes. - By default, Linpac supports commands in UPPER case commands ONLY. To support the lowercase version of the same commands, they can be aliased to the UPPER-CASE commands in the [linpac user]/LinPac/macro/commands file. If the lowercase command is not aliased but the specific .mac file exists in the macro/ directory, those macros will run but ONLY if the command's "case" matches the filename's CASE. Putting it another way, the "sp.mac" macro would work for "//sp" but won't work for "//SP". For a base system that you want to accept messages on, I recommend to edit the following file and add these two lines to accept "Send Private" and "Send Bulletin" in upper or lower case: macro/commands -- sb SB sp SP -- My complete file is: -- activity Activity comp COMP connect Connect conv CONVers help Help info Info init INIT quit Quit users Users users CStatus pw PW sb SB sp SP -- Site-Wide Configuration changes ------------------------------- Menu Prompts ------------ - I recommend you edit the $HOME/LinPac/macro/info.mac file as root and populate it with all the interesting info about your specific packet setup. - Linpac has the ability to do simple messaging but the default help file doesn't clearly mention this! To make sure users can know about this, edit the /usr/local/share/linpac/macro/help.mac as root and insert the lines: //SP <address> [<subject>] - write a Private message to user [optional subject] //SB <address> [<subject>] - write a Bulletin message to everyone [optional subject] - Any other commands you enabled via the macro/init.mac "DEF_RCMD" variable should also be added to the macro/help.mac file as well for good ease of use. Here is my help.mac file: -- LinPac - available commands //Activity - print the time since last operator response //Bell - call operator by acoustic signal //COMPress <on,off> - Turn on Huffman compression - your client must support this to work //Connect [port:]call [digi [digi...]] - connect to remote stations : try connecting and using node: KI6ZHD-5 //CStatus - list of connected stations //DELMSG <message_number> - Mark the message for delete //Disconnect - end the QSO immediately //Echo <text> - send the text back //GETMsg <numbers> - Reads the messages from BBS //Help - this help //Info - print station info //MHeard - list of heard stations //Name <name> - store your name //Quit - normal end of QSO //Read <filename> - send text file //RBin <filename> - send binary file //RPrg <filename> - send the file using autobin protocol //RTt - determine round trip time //SENDFile [p|b] <file> <address> [<num_messages>] - This command takes a binary file, splits the file to num_messages parts using 7plus and creates a separate message for each part. //SP <address> [<subject>] - write a Private message to user [optional subject] //SB <address> [<subject>] - write a Bulletin message to everyone [optional subject] //Users - list of connected stations //VERsion - print the version of LinPac //Write <filename> - Start writing to the text file (stop with "//W off") //WBin <filename> - Start writing to the binary file (stop with "//WBin off") //YPUT <filename> - send the file using YAPP protocol -- Email notification of packet messages ------------------------------------- I've added the linpac-check-msgs.sh script to the Compressed archive of hampacket-CentosDigitalModes document as well as directly here: http://www.trinityos.com/HAM/CentosDigitalModes/usr/local/sbin/linpac-check-msgs.sh This will send you an email or it can send you an SMS text message when you get a new packet message. You will need the "mutt" email program installed to use this script and you will need to edit this file to reflect your own personal email address (or email to SMS gateway email address). To activate this notification say every hour, do the following as ROOT: chmod 700 /usr/local/sbin/linpac-check-msgs.sh ln -s /usr/local/sbin/linpac-check-msgs.sh /etc/cron.hourly You can find another short Linpac setup doc here (very rare to find Linpac docs on the Internet): http://www.zs6mrk.org/pakket_met_linux.htm If you know of any or if you're a Linpac user, please send me an email to tell me as such! FLdigi is a free HF Digital mode program that supports most of the digital modes including BPSK31, RTTY, Olivia, CW, and many many other modes. It runs on Linux, Windows, and Apple OSX and even supports being used as a TNC for using it's modems with Linux's AX.25 stack. Very cool! Please understand that this is a BIG section and requires lots of dependencies to get everything in place before building. Be patient, follow these steps and not only will it work, but it's very worth it! This is the main window for making QSOs, seeing decodes of other signals, running macros, etc:

12. - Fldigi - Fldigi - Compiling the program for HF digital modes

11b. - Linpac - Configuring the packet terminal program

11a. - Linpac - Compiling and installing the program

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

10g. - AX.25 Packet troubleshooting

10f. - AX.25 Packet traffic monitoring

10e. - LDSPED access to AGW/PE packet API support

10d. - AX.25 Tunneling over the Internet via AXIP or AXUDP

10c. - AX.25 Node Services - UroNode

10b. - AX.25 NetROM Routing and connections

10a. - ax25spyd - Next generation packet monitoring daemon

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

9a. - ax25mail-utils - AX.25 messaging tools for used with Linpac

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

8. - First time AX.25 setup and bringup

7d. - Soundmodem Troubleshooting - Fixing issues in running Soundmodem

7c. - Soundmodem - Running the daemon with other AX.25 services for a functional system

7b. - Soundmodem - Setting the right audio levels

7.a. - Soundmodem - Configuring the soundcard based TNC

7. - Soundmodem - Compiling, Configuring, and tuning (LEGACY)

6.d - Tuning Direwolf Audio levels

6.c - Configuring and Tuning Direwolf

6.b - Compiling Direwolf



Related news

F de snedecor para que sirve
Nissan titan ground modality
D aeronca gemona moda operandi
Logo groupme banque populaire massif
Khasav boutique air
Biliardo cinque birilli regole baseball
Palanque madeira plastica
Hernie discale l5 s1 que faire paris