vendredi 22 novembre 2013



The OpenTrack is an open-source modular high altitude balloon tracking and sensor data acquisition platform. OpenTrack can be used as a low-cost single-board tracking solution or a robust mesh network of airborne sensors. The system is modular both in hardware and software, allowing for a variety of uses. OpenTrack is released under the GNU Affero General Public License.
Project Overview
  • Design Presentation (.pptx)
  • Poster (.pptx)
  • Technical Report (.pdf)
Project Resources
User Guides
Questions? If you have any questions regarding this project, feel free to

System Overview


The master motherboard is the heart of the OpenTrack system. This board includes core features which are essential for high-altitude balloon tracking:
  • Onboard NEO-6M GPS module with battery backup, EEPROM, and SMA antenna connector
  • Onboard HX1 300mW 144.39MHz (APRS) Transmitter with SMA antenna connector
  • (Optional) MicroSD card slot for logging
  • (Optional) Headers for XBee radio for slave communication

The master PCB also includes:
  • Onboard resistive heater
  • Onboard PCB temperature sensor
  • 3.3v and 5v regulators
  • 12 indicator LEDs
  • ICSP and JTAG connectors
  • GPS programming connector
  • Auxiliary buzzer connector

Indicator LEDs

The master PCB includes 12 status LEDs to indicate the system's current state. The functionality of each LED is described below.

There are 4 white indicator LEDs in the middle of the board. These LEDs show a “spin” animation when the board is operating properly.

  • err (Red): Flashes code and remains on when an error occurs
  • stat (Blue): Illuminated when the board heater is on
  • rf (Green): XBee status indicator (flashes when XBee attached)
  • pwr (White): Flashes to indicate the master is running

  • act (Amber): Flashes when the GPS module sends an NMEA sentence
  • cyc (Blue): Flashes when a message is being logged to the SD card

Slave Motherboards

The Slave Motherboard is the data collection platform of the system. By working in conjunction with the sensors on a daughterboard, the slave motherboard collects and conditions data before sending it back to the master module wirelessly. Up to 6 motherboards can be used on one balloon, which allows the deployment of numerous sensor arrays. By default, all slave motherboards return the board temperature and battery level to the master regardless of the connected daughterboard. If a daughterboard is inserted, the slave will transmit sensor readings from the daughterboard in addition to these default readings.
To keep modules at a safe temperature, a resistive heater on the slave motherboard turns on when the board temperature falls below a set threshold (0 Celsius by default). This threshold is configurable in the slave firmware's config.h file.
The slave motherboard includes several indicator LEDs to display the firmware's current status:

The following details the statuses indicated by each LED
  • ASC - Amber - Associated - Blinks when connected to the Xbee radio
  • RUN - Blue - Run Loop - Blinks when module functions are executed
  • TX - Green - Transmission - Turns on when recovering from Watchdog Reset (WDR) (note that the TX label is incorrect)
  • STAT - White - Status - Blinks when data request from master is received
  • HEAT - Red - Heater - Turns on when heater is turned on

The slave motherboards require a 5 to 12 volt power source to operate properly. Due to the extremely low temperatures at high altitudes, lithium batteries are recommended. Power should be applied to the port labeled “BATT.” The polarity of the battery port is marked, but the motherboards include reverse-voltage protection if voltage is accidentally applied backwards.

To communicate with the master, each slave motherboard needs an XBee ZB (Series 2) radio. Each radio must be properly configured as outlined in the OpenTrack XBee Configuration. Install the XBee radio on the bottom of each slave motherboard.


Daughterboards plug directly into slave motherboards with two headers. To attach a daughterboard, line up the dots at the end of the header row with the dots on the motherboard. Once attached and powered on, no additional configuration is required: motherboards automatically determine which slave is plugged in.
To acquire sensor data, you may use one of our pre-designed daughterboards or design your own. For instructions on designing your own daughterboard or integrating custom auxiliary sensors into this system, reference the Module Development Guide.

Geiger Counter

The Geiger counter daughter board uses a Geiger–Müller tube to measure radiation levels in CPM (Counts Per Minute.) The counts received from the daugterboard are placed into a 60 second moving average filter to smooth out random fluctuations. Because the system uses a moving average, the CPM reading must take 60 seconds to settle after starting up or experiencing a large shift in radiation. The Geiger tube requires a high voltage to operate, therefore it is important not to touch anode of the tube or any area inside the dashed line labeled “High Voltage.”

Atmospheric Sensors

The atmospheric sensors daughterboard has several sensors on board to measure conditions such as barometric pressure, ambient light, humidity, and temperature. The main board has the pressure sensor which measures pressure in kPa. The pressure sensor is also used to calculate the altitude in feet.

The humidity and ambient light sensors are on an auxiliary board that attaches though the “AuxSens” port. Humidity is measured as a relative percentage from 0 to 100. Ambient light is measured in lux and represents the brightness of ambient light hitting the sensor. For the temperature sensor to operate a thermocouple is required to be attached on the “Temp” port.

Camera Control and Accelerometer

The camera control board provides output for 4 camera remote shutters, and also provides an auxiliary port for development of stand-alone sensors without creating a custom daughterboard. The auxiliary port exposes the i2c port and an I/O pin. For more information about auxiliary sensors, refer to the Module Development Guide.
The camera control board triggers the shutter of attached cameras every 30 seconds. By default, this pulse lasts for 400 milliseconds, but this value can be changed in the slave's config.h file:
#define CAMERA_FREQ 30000 // Camera pulse frequency (Should be 30000 for 30 Secs)
#define CAMERA_PULSE 400  // Camera pulse duration
The cameras are programmed using the Canon Hackers Development Kit (CHDK). If the cameras receive a pulse from between 100 and 600 milliseconds on their USB power pins, they take a picture. If the pulse lasts longer than 600ms, they begin taking a video and continue until receiving a similar pulse. If no pulse is detected, they will take a picture approximately every two minutes as a failsafe.
The camera control board includes the MMA8452Q 3-axis 8-bit accelerometer. The current code does not support the use of this chip, but support may be added in the future. The accelerometer could allow for interesting new features, such as only taking pictures when acceleration falls below a certain level. The accelerometer also features a freefall mode, which can inform the master module that the balloon has popped and the system is descending.

.... vient de nous pencher sur un projet, lui et quelques collègues ont travaillé l'an dernier pour leur projet de
conception senior. C'est un matériel / logiciel ouvert  pour les "trackers" haute altitude ballon à faible coût avec des capteurs qui forment un réseau maillé avec un nœud maître . Ce dernier (ci-dessus ) comprend un ATmega644 , un module GPS embarqué ( NEO- 6M ) , un slot pour carte micro SD , un émetteurAPRS 300mW ( 144.39MHz )  et, enfin, une prise pour brancher une radio XBee . Cette plate-forme est donc en charge de l'obtention de données sans fil à partir des plates-formes esclaves , les stocker dans la carte usd tout en transmettant la position du ballon via APRS avec d'autres données . Il est intéressant de noter que pour garder la conception à faible coût , ils ont choisi un module relativement pas cher de la radio analogique ( environ 40$ ) et piraté ensemble leur signal de sortie de modulation AFSK  avec sorties PWM avec
une table de consultation d'onde sinusoïdale .

Les nœuds esclaves sont composés de « mères esclaves » sur lesquels peuvent être branchés plusieurs
cartes-filles : compteurs Geiger , capteurs atmosphériques , panneaux de contrôle de l'appareil photo / accéléromètre . Si vous voulez construire votre propre système, n'oubliez pas de consulter cette page qui
inclut toutes les instructions et les ressources nécessaires .

If you dabble in the ham radio hobby we’re sure you’ve heard of GPS position monitoring or tracking using APRS packet data commonly transmitting over the VHF ham band and FM modulated. One of the issues you’ll face using this common method is range limitations of VHF. [Mike Berg] a.k.a [N0QBH ] tipped us off to his latest project to greatly increase the range of a standalone APRS system utilizing the HF bands on single-sideband (SSB).

There are some unique challenges transmitting packet data using SSB over HF bands.  High Frequency APRS has been around for decades utilizing FSK AX.25 packet transmissions at 300 baud, but it was quite susceptible to noise and propagation aberrations. More recently PSK-31 at the slower 31 baud speed helped alleviate many of these issues. [Mike] utilized the somewhat updated APRS with PSK-63 and the “APRS Messenger” program to overcome these challenges. [Mike’s] hardware solution consists of a PIC 16F690 micro which is coded to receive data from a GPS receiver, convert it into PSK-63 and then transmit on 30 meters over an attached HF radio. A second receiving station or stations at great distances can pick up and decode the transmission using the “APRS Messenger” program connected to the receiving radio over the computer’s soundcard. The program can then forward the tracking information, if good, to tracking websites like and APRS.FI.

You can build your own FreeTrak63 by downloading [Mike’s] parts list, assembly code, HEX file, manual and schematic. The PCB is available on OSH Park if you don’t want to make your own or wire point-to-point. Let’s not forget to mention how hackable this hardware is, being really just an eight bit DAC, micro, serial in and radio out. One could reprogram this hardware to do other modulation schemes like AX.25 packet or MFSK16, the sky’s the limit. If short-distance on VHF with existing Internet linked receiver networks using an Arduino compatible platform is more to your taste, then checkout the Trackuino open source APRS Tracker.

A Low-Cost Modular High Altitude Balloon Tracker with Mesh Networked Sensors

November 21, 2013 by Mathieu Stephan

[Ethan] just tipped us about a project he and a few colleagues worked on last year for their senior design project. It’s a low-cost open hardware/software high altitude balloon tracker with sensors that form a mesh network with a master node. The latter (shown above) includes an ATmega644, an onboard GPS module (NEO-6M), a micro SD card slot, a 300mW APRS (144.39MHz) transmitter and finally headers to plug an XBee radio. This platform is therefore in charge of getting wireless data from the slave platforms, storing it in the uSD card while transmitting the balloon position via APRS along with other data. It’s interesting to note that to keep the design low-cost, they chose a relatively cheap analog radio module ($~40) and hacked together AFSK modulation of their output signal with hardware PWM outputs and a sine-wave lookup table.
The slave nodes are composed of ‘slave motherboards’ on which can be plugged several daughter-boards: geiger counters, atmospheric sensors, camera control/accelerometer boards. If you want to build your own system, be sure to check out this page which includes all the necessary instructions and resources.

Long-distance High Frequency APRS Tracking Using The FreeTrak63

November 14, 2013 by Todd Harrison

If you dabble in the ham radio hobby we’re sure you’ve heard of GPS position monitoring or tracking using APRS packet data commonly transmitting over the VHF ham band and FM modulated. One of the issues you’ll face using this common method is range limitations of VHF. [Mike Berg] a.k.a [N0QBH ] tipped us off to his latest project to greatly increase the range of a standalone APRS system utilizing the HF bands on single-sideband (SSB).
There are some unique challenges transmitting packet data using SSB over HF bands.  High Frequency APRS has been around for decades utilizing FSK AX.25 packet transmissions at 300 baud, but it was quite susceptible to noise and propagation aberrations. More recently PSK-31 at the slower 31 baud speed helped alleviate many of these issues. [Mike] utilized the somewhat updated APRS with PSK-63 and the “APRS Messenger” program to overcome these challenges. [Mike’s] hardware solution consists of a PIC 16F690 micro which is coded to receive data from a GPS receiver, convert it into PSK-63 and then transmit on 30 meters over an attached HF radio. A second receiving station or stations at great distances can pick up and decode the transmission using the “APRS Messenger” program connected to the receiving radio over the computer’s soundcard. The program can then forward the tracking information, if good, to tracking websites like and APRS.FI.
You can build your own FreeTrak63 by downloading [Mike’s] parts list, assembly code, HEX file, manual and schematic. The PCB is available on OSH Park if you don’t want to make your own or wire point-to-point. Let’s not forget to mention how hackable this hardware is, being really just an eight bit DAC, micro, serial in and radio out. One could reprogram this hardware to do other modulation schemes like AX.25 packet or MFSK16, the sky’s the limit. If short-distance on VHF with existing Internet linked receiver networks using an Arduino compatible platform is more to your taste, then checkout the Trackuino open source APRS Tracker.

SSTV beacon based on a Raspberry Pi

October 6, 2013 by Mathieu Stephan 

The Budapest hackerspace did some joint work with a local ham radio club and created an SSTV beacon housed inside a CCTV case that takes an image of its environment and transmits it using slow-scan television over ham bands.
As the title says, the build uses a Raspberry Pi to process the image taken from its camera and then transmits it over the air using a Ricofunk UHF transceiver with a main frequency of 433.425MHz. On the software side, PySSTV is used to convert images to frequency/time tuples, UNIXSSTV then creates the actual audio file and finally sox plays it. To avoid screwing up the Raspberry SD card, every part of the filsystem is either mounted in read-only mode (things like /home and /usr) or uses a ramdisk (things like /tmp and logs).
The plans, schematics and source code are available, so they hope that other hackerspaces will join the ranks!

Listening in on weather balloons with RTL SDR

January 12, 2013 by Brian Benchoff 

Every day, twice a day, over 800 weather balloons are launched around the world at exactly the same time. The data transmitted from these radiosondes is received by government agencies and shared with climatologists and meteorologist to develop climate models and predect the weather. Near [Carl]‘s native Auckland, a weather balloon is launched twice a day, and since they transmit at 403 MHz, he decided to use a USB TV tuner to receive data directly from an atmospheric probe.
The hardware portion of this project consisted of building a high gain antenna designed for 162 MHz. Even though the radiosonde transmits at 403 MHz, [Carl] was easily able to receive on his out-of-band antenna.
For the software, [Carl] used SDRSharp and SondeMonitor, allowing him to convert the coded transmissions from a weather balloon into pressure, temperature, humidity, and GPS data.


Master Setup

Plug the buzzer, GPS antenna, APRS antenna, and an SD card into the master module. Plug an XBee into the bottom of the motherboard if you plan on using slave modules.

Slave Setup

Plug all desired slave daughterboards into slave motherboards. Make sure each slave motherboard has an XBee attached.

System Powerup

Connect battery packs to each slave module. Wait for the blue and amber LEDs to flash continuously. The blue LED will flash more rapidly than the amber one. Once all slave boards are powered, turn on the cameras by pressing the on/off button.
Next, power on the master module by attaching its battery pack. The master module will initialize and the LED indicator will spin rapidly. After a few seconds, the central LED indicator will display the number of nodes detected. If the master does not detect all slaves, power-cycle the master module.

Desktop App Setup

First, turn on the radio and plug it into the serial port. Then run the the executable for the application and select the appropriate COM port to read from. Also change the default APRS callsign to your own. As transmissions are received you should see them appear in the message log at the bottom of the application. To start placing markers on the map and saving data click on the Collect Data checkbox.
It is also suggested to cache map data for offline use. To do this, go to the “cache” panel of the sidebar, select an area of the map using ALT+left click drag, and then click the “Prefetch selected area” button. Be aware that caching can take a long time if a large area is selected. To save time, it is recommended to cache the starting area and the predicted landing area fully and then cache a few levels of zoom for the predicted route.


If you encounter issues during system setup, please refer to our OpenTrack Troubleshooting section.

Preparing for Launch

To prepare your system for launch, you must first tweak the software constants on the master, prepare an SD card, prepare battery packs, and prepare enclosures.



To use the master motherboard, connect a GPS antenna and APRS antenna to the SMA connectors on the motherboard. We recommend using an omnidirectional GPS antenna for maximum performance.

Next, take a FAT or FAT32-formatted microSD card and place it in the microSD socket on the back of the master PCB. The OpenTrack supports SD cards of up to 4 gigabytes. Note: most launches generate less than 10 megabytes of data.
All position and sensor data will be automatically logged to CSV files on the SD card. A new file is created every time the system is powered on.

If desired, plug a buzzer into the “buzzer” connector. This buzzer will start beeping after the system is at a low altitude, or if a maximum time limit has been reached (whichever comes first). The buzzer is powered directly from battery voltage.
Finally, plug in a battery pack to the battery connector. For the master module, we recommend 6 lithium AA cells which provides more than 35 hours of continuous operation.
If you plan on operating in stand-alone mode (using only the master motherboard, no slave modules), you do not need to attach an XBee radio. Otherwise, plug an XBee ZB (Series 2) radio into the headers on the bottom of the motherboard. Make sure the radio is properly configured for OpenTrack – reference the OpenTrack XBee Configuration for more details.

After completing the above steps, you should have a ready-to-launch setup as shown in the image above. Note: The APRS antenna is not connected in the above photo as it was too large to fit in the frame.

Usage: Stand-Alone Operation

In stand-alone operation, only the master motherboard is used. No additional slave motherboards or daughterboards are employed, resulting in a very simple yet robust tracking solution.


To configure the master, place a file named “config.ini” on the SD card. You may click on “config.ini” below to download this sample. Make sure you change the callsign and durations to match your predicted flight characteristics.
temp = 5   ; Heater regulation temperature, Degrees C
enable = true
timeout = 1200000 ; Turn off non-critical leds after X ms
failsafe = 9600000 ; Trigger buzzer after X ms
call = "XXXXXX" ; APRS callsign
call_id = 11    ; Callsign ID (11 for balloon)
period = 35000 ;  APRS transmit interval (ms) no less than 30,000
Note: You must have a valid amateur radio Level 1 Technician Class license or higher to use the OpenTrack system!

Powering up

After you plug in a battery pack, the system will now power on, detect zero slaves, and begin operating in stand-alone mode. In this mode the module will immediately attempt to acquire a GPS fix and start transmitting APRS packets. APRS packets contain the latitude, longitude, altitude, speed, board temperature, error messages, and battery level.
Your system is now ready for launch!
Note: After 20 minutes of operation all status LEDs will turn off except for the RF and Power LEDs to conserve system power. The error LED will still illuminate when the system encounters an error.

Usage: Multi-Node Operation

In multi-node operation, the master motherboard and 1-6 slave modules are used. This system allows for flexible sensor data acquisition and robust tracking.


temp = 5   ; Heater regulation temperature, Degrees C
reqrate = 3000 ; Query slaves for data every X ms
enable = true
timeout = 1200000 ; Turn off non-critical leds after X ms
mintime = 2700000 ; Don't trigger buzzer before X ms
maxalt = 2000 ; Trigger buzzer after mintime and altitude below X feet
failsafe = 9600000 ; Trigger buzzer after X ms if altitude conditions not met
call = "XXXXXX" ; APRS callsign
call_id = 11    ; Callsign ID (11 for balloon)
period = 35000 ;  APRS transmit interval (ms), no less than 30,000
Note: You must have a valid amateur radio Level 1 Technician Class license or higher to use the OpenTrack system!

Powering up

First, power on all slave modules that you wish to use. Next, power on the master module. The master module's progress indicator LEDs will spin rapidly as it performs network detection. After network detection is complete, the number of detected nodes will be displayed on the progress indicator for 2 seconds. If one or more of your slaves is not detected, power cycle the master and try again.
After network discovery the master will begin querying slaves for data, logging all data to the SD card, and will begin transmitting sensor values in interleaved APRS packets.
Your system is now ready for launch!
Note: After 20 minutes of operation all status LEDs will turn off except for the RF and Power LEDs to conserve system power. The error LED will still illuminate when the system encounters an error.

Ground Station

For enhanced offline mapping and tracking, we developed a ground station application. If you wish to use the ground station application in combination with an APRS-capable HAM radio, reference the Ground Station Application documentation.
You may also track your balloon using the APRS network at Our system transmits APRS packets in the following format:
Position-only packet:
KD8TDF-11>APRS,WIDE2-1:/051959z3906.98N/08330.33WO146.62/45.391 ~v45.391~_031~|914
Position and data packet:
APRS packets are interleaved: every other packet contains only the position information and excludes other sensor readings and error messages. This allows for packet propagation in the APRS network when there is significant congestion or interference, as a shorter packet is more likely to maintain integrity during transmission.
Basic APRS Format Reference
  • '|' - Longitude least significant digits
  • '_' - Latitude least significant digits
  • 't9' - Master motherboard PCB temperature (celcius)
  • 's' - Satellites in view
  • 'h' - Horizontal dilution of precision (meters)
  • 'v' - Velocity (knots)
For a detailed explaination of our APRS comment format, see the APRS Format page.



The master module includes a robust error detection, recovery, and logging system. Error codes are flashed on the error LED and are logged to error.csv on the SD card. A summary of error codes and solutions are below.
  • Error 0: Slave timeout. Ensure all slaves are powered.
  • Error 1: SD card initialization failure. Make sure your SD card is inserted.
  • Error 2: SD partition open failure. Make sure your SD card is formatted properly.
  • Error 3: SD file open failure. Make sure your SD card is formatted properly and config.ini exists.
  • Error 4: Config parse error. Make sure config.ini is formatted properly.
  • Error 5: XBee timeout. Make sure your XBee is seated properly. Try power cycling the system.
  • Error 6: Unknown fatal error. Try power cycling the system.
  • Error 7: Enter AT mode fail. Make sure the XBee is seated properly, check the XBee's baud rate, and restart the system.
  • Error 8: Exit AT mode fail. Make sure XBee is seated properly, and restart the system.
  • Error 9: InfoText. System warning, non-critical. Check error.csv for details.
  • Error 10: Watchdog error. The system booted after hitting the watchdog timer. System will proceed as normal.


Troubleshooting the slave is simple when using the LEDs in conjunction with this guide.
  • Slave won't turn on - Ensure that the power is properly connected with correct polarity.
  • No communication with Master - Ensure Xbee is plugged in and “ASC” LED is blinking.
  • Unsure if communicating with Master - Watch “STAT” LED to see if it periodically blinks.
  • RUN LED is solidly ON or OFF - Slave is frozen or waiting for a daughterboard to be connected.
  • TX LED is on - Slave has recovered from a watchdog reset.

OpenTrack XBee Configuration

Preparing X-CTU

To configure your XBee modules you will need an XBee to USB adapter and the XBee module(s) you wish to configure.
First, install X-CTU from the Digi website. Download the installer from the link below and run the installer. No special options are needed during installation. Download: X-CTU Installer

Next, plug the XBee you want to configure into the XBee to USB adapter and connect the adapter to your computer. Windows will install a driver for a USB to Serial adapter that is on this board.
Finally, launch the X-CTU program. Select the COM port of the radio the first tab (which should be the only COM port aside from COM1), and select a baud rate of 9600 if this radio has not yet been configured. If you are reconfiguring this radio, select 115200 baud.
Click on the modem configuration tab and press “read” which will load settings from your radio. If reading fails, make sure your radio is properly seated and that you have selected the proper COM port. If the radio still does not work, consult the user manual of the radio you ordered to determine the default baud rate of the radio (older radios may have different default baud rates).

Configuring the Radio

Make sure you are on the configuration tab of X-CTU. Scroll down to the “Addressing” section.

Click on the line labeled “Node Identifier” and then click the “set” button. You may now specify a name for this radio module. This name will prepend each column in the master module's CSV log that corresponds to sensors on this radio's slave daughterboard.

Scroll down to the “Serial Interfacing” section and change the baud rate to 115,200.

Finally, scroll down to “AT Command Options” and set “Guard Time” to 2.

To save these settings to the radio, press the “Write” button at the top of X-CTU.
Your modem is now configured and is ready for use!
Photo credit: SparkFun Electronics

Module Development Guide

If you want to integrate your own custom sensors into OpenTrack, you have three options:
  • Design a custom daughterboard (recommended): You can fully utilize slave I/O in a robust form factor. A PCB/Schematic template is provided.
  • Use the Camera daughterboard AUX connectors: You may use a limited number of analog and digital I/O on auxiliary cables
  • Use the slave headers directly: You can fully utilize slave I/O, but your connections may not be as robust as the previous two options.

Design a custom daughterboard

Developing a custom daughterboard is quite simple. We have created a blank daughterboard template with notes and documentation on the schematic to speed up the design process. Download the blank schematic and board files at the link below.
Place any components and connectors you desire and route the PCB. Make sure you do not change the location of the headers (the headers are locked parts, so you shouldn't be able to move them unless you unlock them).
We recommend OSH Park for fabrication of these small PCBs. You may order your PCB for $5 / square inch, and you will receive 3 copies of your design.

Custom header cable

To make full use of the slave motherboard's I/O, you may design a simple cable for your custom sensors. Refer to the schematic below for pin functions:

- All PD* pins are capable of digital input and output - All PA* pins are capable of digital I/O and analog input (0v-3.3v) - SCK, MISO, and MOSI may be used for SPI or digital I/O - VCC is a regulated 3.3v supply - VBAT is a direct connection to battery voltage
Note: Pins labeled by PD* and PA* are referred to by this name in software. For instance, PA4 is referenced as pin 4 of PORTA in software.
To directly make use of these functions, you can directly solder wires to a male header and then insert the header into one of the slave daughterboard's female headers. Although this option is not as robust as a custom PCB, it allows for rapid prototyping of designs.

Camera daughterboard auxilliary sensors

Each 2-pin port on the camera daughterboard can act as a digital output, digital input, or analog input (0v-3.3v). These connectors include a ground pin and a signal pin.
The camera daughterboard also includes a 5-pin connector for digital sensors. This connector includes I2C lines (SDA and SCL), a regulated 3.3v voltage supply, and a single digital input / output pin.
All of these connectors can be used for custom external sensors. At the minimum, you will likely need to use the 5-pin auxiliary connector to get 3.3v regulated power, which also provides digital I/O and I2C. If you need analog inputs, you will need to add additional 2-pin connectors for each required analog input.
Refer to the software configuration section below for configuring your inputs and outputs.

Writing slave firmware to support a new daughterboard

Adding a new daughterboard to the slave firmware is fairly simple. Follow the steps below to add your custom daughterboard or auxiliary sensors to the slave firmware.

1. Choose a blank module template

Several blank custom module templates have been created in the firmware for custom daughterboards:
  • Custom 1 - DIP position 4
  • Custom 2 - DIP position 5
  • Custom 3 - DIP position 6
To use custom configurations, change the rotary DIP switch on the slave motherboard to position 4, 5, or 6.
Choose an unused custom module template and continue to the next step. It does not matter which you choose.

2. Configure Pins

If you are using simple digital or analog inputs or I2C sensors, startup configuration is already done for you. No additional code is required!
Additional configuration is only required if you are using the SPI module.
If you are using a SPI sensor, open modules.c and scroll to customX_setup() where “X” is the custom module you chose. Add a call to the setup_spi(); which will configure the SPI module to run at 172kHz. Feel free to modify the setup_spi() function if you desire to change the clock frequency (refer to the AVR manual for details).

3. Read the Sensor(s)

Each sensor is read by functions placed in the modules.c file at a configurable interval (which is set in config.h). To make custom daughterboard implementation easier, we have already created several empty functions for custom daughterboards. Open modules.c and scroll down to the function modules_custom1().
In this function you can read from any of your sensors. We have created some simple functions which perform simple digital and analog reading so you don't have to write much code.
Below is an example of a custom daughterboard. We started with the empty modules_custom1() function and added in some functions to read values from different pins.
void modules_custom1()
      // Read an analog value on PORTA pin 2 (PA2) and PORTA pin 5 (PA5)
      // Read a digital value from PORTA pin 6 (PA6)
      // Read a digital value from PORTD pin 6 (PD3)
If you want to read from digital sensors such as I2C or SPI, refer to the AVR manual and place all reading functionality inside this custom function.

4. Transmit Sensor Readings

Now that the slave is periodically reading your custom sensors, we need to make it transmit these readings to the master when the master requests the slave for data.
Open up masterComm.c and scroll down to the masterComm_modules() function.
Find the case statement for the module you are working on. In our example, we are using Custom 1 which corresponds to case 4.
Now you can get your sensor readings and prepare them for transmission to the master. If needed, you can perform any scaling / other math on your sensor readings before transmission.
You must assign a unique ID to each data type you transmit. For your sensors, choose any letter in the English alphabet. You can use uppercase or lowercase letters.
case 3:
  // Custom1
  // Send analog reading with some scaling and a linear offset
  masterComm_packetSend_signed('A', sensors_getAnalog(2) * 0.25 + 273.15);
  // Send analog reading without any preprocessing
  masterComm_packetSend_unsigned('B', sensors_getAnalog(5));
  // Send first digital reading
  // Send second digital reading
The last change you need to make is updating definitions in config.h. DATATYPES_CUSTOM* constants define how many sensor readings we are going to transmit to the master.
Some onboard sensor readings are transmitted by default: battery voltage, board temperature, and heater status. For our example using Custom 1 we need to add 4 additional sensors (2 analog readings and 2 digital) to the 3 default sensors. This brings the total sensor count to 7, as shown below.
#define DATATYPES_CUSTOM1 7  // Modules already automatically send 3 values (temp, batt, and heater status.)
#define DATATYPES_CUSTOM2 3  //    Additional sensor readings should be added onto the 3
#define DATATYPES_CUSTOM3 3  //    For example a daughterboard with two sensors would be 3+2=5
Save, compile, and program your daughterboard. Set the DIP switch to the number corresponding with your chosen custom module (refer to the table in Step 1 above) and power on the module. You are now reading your custom sensors!

Build your Own

OpenTrack is completely open-source under the AGPL, so feel free to build, program, and modify your own!


PCB design files are available on the Mercurial repository for the project here: Hardware repository. Schematic design and PCB layout were done in Eagle. Our board is small enough that the free version of Eagle is adequate for editing.
We recommend OSH Park for fabrication.


A BOM of current components is not available, but you can easily export a BOM from Eagle and source your own components. We hope to have Mouser and DigiKey BOMs posted in the near future.


Most soldering is surface-mount. The smallest component is 0603 which allows for easy hand soldering if necessary. There are over 100 components on the Master PCB, so expect to spend some time soldering!


You will need any standard AVR programmer to program our boards. Our code was developed in Atmel Studio 6, so we would recommend using a standard Atmel programmer (Dragon, ISP MKII, etc) with Atmel Studio to program. Alternatively, you can write a makefile and program with avrdude and any supported 3rd party programmer. You may download our source code from the firmware repository.
Supplemental Links

GPS Programming

After you assemble your master PCB, you will need to program your GPS. First, make a JST cable or solder wires to the GPS connector on the motherboard. Next, connect a USB to TTL serial adapter to the GPS pins.
Place a jumper over the GND and RST pins on the ICSP header to put the microcontroller in reset (so all pins are held in high-Z). Next, plug the USB to serial adapter into your computer and launch u-center.
Use the configuration menu to set the GPS's baud rate to 115,200 and configure the module to only send GGA and RMC messages. Next, change the GPS's settings to optimize for an airborne platform. Then, go to the configuration submenu of the configuration dialog and save all settings to EEPROM. See the u-center documentation for more information.
You may now remove your GPS programming cable; your GPS is ready to use.

Desktop Application

UI repository - View and download desktop app source code 

Trackuino – an Open Source Arduino APRS Tracker

April 20, 2011 by Jason Komp 

Trackuino is a new open source (GPLv2 license) Arduino APRS tracker designed by [Javier Martin]. If you are unfamiliar: APRS (Automatic Packet Reporting System) is an amateur radio method used to relay small packets of position-tracking data to an online database for easy access and mapping. In this case, GPS telemetry data is used to track latitude, longitude, altitude, course, speed, and time measurements in near real-time via
Although this reminds us of the WhereAVR that we covered previously, the Trackuino includes an onboard radio so no external handheld unit is necessary. Since the Trackuino was designed primarily for high-altitude balloon tracking, a number of useful related features are also included: dual temperature sensors, support for a humidity sensor, and a remote “cut-down” trigger really make this a complete package.
Initially there was some concern that the 300mW radio used would not be powerful enough to reach the ground-based receivers from peak altitudes. This was clearly not an issue however, as the signal was heard from nearly 600Km away during the maiden voyage. If this still doesn’t sound like enough power, a 500mW radio is also supported.
Make sure to check out [Javier]’s blog for some amazing high-altitude photos and everything needed to get your own Trackuino up and running in no time!
Thanks [Brad]!

SSTV beacon based on Raspberry Pi

This project aims to build such a beacon that transmits images taken with its camera using SSTV over ham radio. The computing part is a Raspberry Pi Model A, and a Ricofunk UHF transceiver is used to carry the images over the air. The first beta operation can be watched on a YouTube video. Working installations use a Raspberry Pi camera module to transmit live images, larger resolution photos of the build can be opened by clicking on the thumbnails, the full list of images can be found in a DropBox folder.

Working installations

  • MH Altiszti Akadémia, Szendendre, Hungary
    • Frequency: 433.425 MHz
    • Modulation: FM / Martin M2
    • Timing: every 15 minutes
    • QTH locator: JN97MP 86uv(external link)
    • Coordinates: N 47° 39.28′ E 19° 04.51′

Sample images

Image received during assembly using speaker/microphone coupling
Image received from installed beacon using a cheap handheld radio and a smartphone from 12 km away


The first prototype used PySSTV to convert images to sound. As of v0.1.9, a (2 minutes long) Martin M1 image is generated in 4. A more effective solution is in progress at UNIXSSTV, this is currently combined with PySSTV. The software pipeline can be seen below, source code can be found in the rpi-sstv GitHub repository.
raspistill --(BMP image)-> PySSTV --(freq+time tuples)-> UNIXSSTV --(raw samples)-> sox

BMP was chosen since it wouldn't make sense compressing an image (wasting CPU cycles) right before parsing it in another component, and discarding the image forever. PySSTV is used for generating frequency-time tuples (e.g. 1500 Hz for 10 msec, then 2000 Hz for 25 msec, ...) as it's fast enough and it's easy to use PIL to manipulate the image, which in our case consists of resizing it and putting the callsign (HA5KDR) in the top left part of the image. UNIXSSTV performs the parts which are not that complicated, but would be too time consuming in pure Python in a constrained environment as the Raspberry Pi, and
SoX (more precisely play) is used to divert the samples towards the audio output.

To avoid screwing up the SD card, by default, every part of the FS is either mounted in read-only mode (things like /home and /usr) or uses a ramdisk (things like /tmp and logs). The beacon is activated periodically using cron; even though the Raspberry Pi doesn't have a real-time clock (RTC), it can measure the time since it booted, so if configured to run every n minutes, it will do that, but it will not be synchronized to any clock.

Mounting the Raspberry Pi

The Raspberry Pi is mounted using two screws to the metal plate inside the case.
Mounting the camera
The Raspberry Pi camera is mounted to the metal plate inside the case using screws and a floppy disk cut in half and put back together using hot glue.
Connecting the transceiver and the RPi
The bridge to the right and with its schematics below makes three connections possible:
  • it exposes the Raspberry Pi serial console to a 6-pin header compatible with the USB TTL Serial cable, using a voltage divider, so it the device can be accessed without network connectivity
  • it connects the audio output of the Raspberry Pi to the microphone input of the transceiver
  • it makes possible for the Raspberry Pi to switch the transceiver into transmit mode by putting GPIO 18 into high state (there could be a resistor between the GPIO and the LED, but the actual LED used didn't require one)

RS-232 level translation (serial console)

The voltage divider makes sure that voltage on the serial receive pin of the Raspberry Pi is 3.3 volts or lower. The other direction requires less attention as 3.3 volts are still above the 2.5 volts compare level used by the 5 volts FTDI cable.

Audio output

As it turned out the levels matched perfectly, we found it best to turn the volume to the maximum on the Raspberry Pi. Don't forget to select the appropriate output device if you have HDMI connected!

Transmit mode

Transmit mode can be switched using an NPN transistor connected to GPIO 18 (pin 12), for example using the following Python code (based on the openmicros example).
$ sudo python
>>> import RPi.GPIO as GPIO
>>> GPIO.setmode(GPIO.BCM)
>>> GPIO.setup(18, GPIO.OUT)
>>> GPIO.output(18, True)

Remote operation

The final placement of the Raspberry Pi requires to place the radio 10-15 meters away from the transceiver, and a UTP cable is used to transmit signal, TX control and power. The wire assignment is the following:
Raspberry Pi
+5V power supply
GPIO 1-2
transceiver PTT/TX
transceiver audio signal
3.5 mm TRS jack
transceiver audio signal GND

Future plans / TODO

  • install more cameras around the city
    • and in other cities (countries?)
    • synchronize them to send images over a single frequency
      • using RTC?
      • listening into each others' signals? what about timeouts?
  • since the resolution of the cam is much better than SSTV, it could simulate panning
  • SSDV
  • add 2-3 seconds of silence after and before sending the image
  • add (enable) FSKID
  • handle pitch dark night
    • system info
    • long exposure

Featured on

FreeTrak63 - APRS PSK63 Tracker

Build Your Own HF PSK Tracker

The FT-63 is an APRS Tracker for PSK-63
The point of my design is to be a new kind of stand alone APRS tracker to exist between a GPS and an HF SSB transmitter.
Like it's predecessors, it transmits APRS position packets - only now using the much more robust PSK63 modulation in the APRS Messenger packet format.
The APRS Messenger program 3.26 (or newer) support decoding FreeTrak63 position packets and can forward them on to the Findu map display web site.
Chris G4HYG has done a great job with this program, greatly expanding the useful possibilities of APRS, HF radio and the Internet. By melding a platform supporting multiple HF digital modes along with APRS parsing, a whole new avenue for development exists in HF APRS.
PSK63 coupled with the compressed Mic-e packet option make this a formidable combination for your weak signal HF APRS.
How it Works
A PIC 16F690 micro receives serial position data from a GPS, converts the data into an APRS packet and creates a PSK-63 modulated tone containing the data.
This tone is transmitted using SSB to receiving stations running APRS Messenger program. Only a few stations scattered across the country are required to provide coverage.
Besides costing under $50 to make, using it is simple too.
Two switches. Power and option. Option chooses between sending compressed Mic-e or conventional coordinate packets.
An internal jumper invokes idle mode or the serial configuration mode.
A LED indicates FT-63 status.

APRS Messenger - The other half of the equation
APRS Messenger is a free Windows program that ties everything on the receive end together.
It interfaces with the computers sound card to decode and display the FT-63 PSK63 "packets" heard by a HF radio.
Because the method of propagation is SSB HF and we use the Internet to collect reports, the number of receive stations necessary to provide adequate coverage is small in comparison to VHF.
FreeTrak63 was designed from the ground up to work with APRS Messenger.
It will decode with any PSK63 program, but only APRS Messenger has CRC16 checksum validation of the data.
The screen capture below is what APRS Messenger shows when a FreeTrak63 transmits. Both conventional and compressed outputs are displayed here along with what the signal looks like on the waterfall display.

PSK-63 Circuit Description
The schematic below is the FreeTrak63 circuitry.
Input to the FT-63 is in the form of serial data either from a GPS or computer.
It requires the GPRMC sentence at 4800,8,N,1 which most GPS units send by default. Q1 is an open collector, active low output transistor switch. It keys the radio to transmit.
Q2 and Q3 are the serial inverter/buffers passing data via the RS232 port. J3 is a 2 line swap switch utilizing 4 pins and 2 jumpers.
Five volt power is regulated by a low drop out (LDO) 2950 regulator.
A PIC 16F690 running at 16 MHz controls an 8 bit DAC which creates the 2000Hz phase shifted tone.
A low pass RC filter (R22/C8) cleans up the DAC output.
R24 prevents over loading and should only be bypassed with JP4 as a last resort.
Radios requiring more drive than the 2k pot can provide should use a 5k pot instead.
PSK-63 APRS Tracker Schematic

Below is an example of what you will see when configuring a FreeTrak63.
Set the FT-63 serial jumpers for PC and set the terminal program to 4800,8,N,1 connected.
Connect the FT-63 to a RS232 serial port or if your PC doesn't have one, use a Keyspan USB RS232 dongle.
With the JP7 jumper ON and SW1(S1)ON, turn on power(J6) to FT-63.
The FT-63 will be in configure mode and will send the top four lines seen below, telling you it's present configuration.
At the arrows enter the callsign. Next you'll be prompted for transmit interval, then symbol and finally, optional tail message.
FreeTrak63 Configure Screen

FreeTrak-63 with a GPS and Yaesu FT-857D
Uncased FT-63 far right shows what's inside.
Check out the US activity on 30m - 10149.700

Project PCB

Enlarged top view of the FT-63 PCB.
FT-63 PCBs Available from OSH Park

A parts list, schematic and manual are included in the FT-63 files download.


Background  |  The "APRS Messenger" PSK63 Program  |  Setting up APRS Messenger  |  Using the PSK63 Program With Other APRS Applications  |  Using PSK63 APRS and "Classic" AX.25 FSK APRS At the Same Time |  Understanding the Relationships Between Audio and Radio Frequencies on SSB

(Links Jump To Points On This Page)

Some Technical Background

For decades, APRS activity on HF has been conducted using traditional 300-baud 200-Hz-shift FSK AX.25 packet.
Conventional packet is a rather poor data transmitting mode for HF.  The 300 changes/sec symbol rate, combined with no form of redundancy or forward error correction in the packets, makes conventional packet extremely susceptible to the noise pops, static crashes, interference from other stations, rapid fading & flutter and phase distortion commonly encountered on HF.  [HF, as monitored in an SSB receiver (i.e. a form of amplitude modulation) is chronically noisy. On HF, you almost never have the equivalent of a noise-free fully-quieted channel of the type you get on FM.]
Frequently, a transmitted HF signal will arrive at the receiver over several different paths of differing lengths, due to reflections from different parts of the earth's ionosphere responsible for long-range radio transmission.  If the path distances differ by only a half wave-length (about 15 meters or about 43 feet at 10 MHz) the two will arrive at the receiver out of phase and cancel, sometimes completely. Any odd integer multiple of the half-wave difference can produce the same effect. Most of the time, numerous versions of the signal, propagated over paths of various lengths will be present, mixed together, causing an ever-changing pattern of partial cancellation and constantly-fluctuating signal strength.
Frequency-selective fading due to this multipath propagation is common on HF, and can make one or the other of the two FSK tones used disappear entirely for a second or more at a time. [The characteristic "watery" or "flangey" sound of long-distance HF-SSB voice or shortwave broadcasts is due largely to selective fading of parts of the signal.] TNCs intended for the far more benign VHF-FM environment (that use FM-type limiter/discriminators, zero-crossing pulse counters or phase-locked-loop modem chips) perform very poorly as one or the other of the two tones periodically disappears or noise crashes add additional zero crossings.
Worse, a transmitted HF signal can arrive at the receiver over several different paths, due to reflections from layers of the earth's ionosphere many MILES/KILOMETERS apart, resulting in major TIME delays as well as phase changes.  Consider that light and radio waves propagate at 300,000,000 meters/sec in free space, or 300 meters/microsecond .  If a signal reflects simultaneously from two layers of the ionosphere with a total path-length difference of only 30 KM (about 19 miles), these two versions of the same signal will arrive at the receiver one hundred microseconds apart.   The successive 1s and 0s of the digital data stream start overlapping in time, smearing or obliterating the transitions between ones and zeros.
The nature of FSK packet being ill-suited to the noisy HF environment is demonstrated as one routinely monitors HF packet stations having to re-transmit the same packet 4 or more times before receiving an ACK from the receiving station.  Despite these problems, FSK packet has been used on HF APRS primarily because APRS evolved as an application built on AX.25 packet on VHF. As APRS expanded to HF, operators wanted to continue to use the same protocols and existing TNC hardware as on VHF.  And because no easily-usable inexpensive alternatives existed.

A Data Mode Really Suited To HF

The most popular HF data mode in recent years has been PSK31 (Phase Shift Keying - 31 Bits/sec).  This mode is vastly better suited to the HF environment than classic FSK packet.  It transmits only about 30 symbols per second (compared to 300/sec for packet) making it far more resistant to pops of noise and the multipath-induced time-delay smearing of transitions between 1s and 0s. The transmission's effective bandwidth of only about 30 hz, vastly reduces the effect of frequency-selective fading. The audio-DSP receiving systems used synthesize an effective receive bandwidth of only about 35-40 Hz (compared to about 500 Hz minimum for traditional HF packet), vastly reducing the effect of random noise and static. 
All this is done with "smoke, mirrors and software" on an ordinary PC with a sound card. No exotic, expensive or specialized hardware is required -- just a couple of audio patch cords to connect a radio's receive and transmit audio to the computer sound card audio-in and audio-out ports.  Until recently, PSK31 has been used for live hand-typed conversations directly between operators. It has been used as a replacement for CW (Morse Code) or classic 1950's vintage RTTY (Radio TeleTYpe) operation.
PSK31 is incredibly effective at low signal-to-noise ratios -- a situation that exists more often than not on HF.  Many solid PSK31 contacts are made with stations not even audible in the receiver speaker. (Your ears are responding to the noise power present in the entire 2500-3000 Hz bandwidth of the SSB receiver, while the PSK31 application is only dealing with the noise power present in the 35 Hz bandwidth of a DSP audio filter.)

APRS Combined with PSK31

"APRS Messenger" is an application, developed by Chris Moulding G4HYG, that sends and receives APRS beacons and messages using PSK63 (a faster variant of PSK31), GMSK, or MFSK16 modulation.  This freeware program can downloaded from his web site at:
This compact program (just over one megabyte) combines:
  • A typical PSK soundcard send/receive application with waterfall tuning display, with the GMSK and MFSK16 modes added.
  • An APRS messaging send/receive client.
  • Position beaconing capability for a mobile station when used with a GPS receiver attached to a computer's serial port (either physical or virtual).
  • A TCP/IP client interface that allows the program to act as an "igate" (Internet Gateway) for connecting to the APRS Internet Server system. By default, the program functions as a receive-only igate, but can be enabled for full bi-directional "reverse" igating of messages from the APRS-IS.
  • Two TCP/IP server interfaces that allow other APRS apps  to connect to Messenger.
Although this program lacks mapping ability, it can be combined with other APRS applications such as UIview, APRSpoint or APRSICE32 that do produce maps by using either of the two TCP/IP server ports.  (Details below)
Typical PSK programs have no error detection and will sometimes display "garbage" in the middle of otherwise valid strings of text, if there is interference or signal fading. APRS Messenger attaches packet-style checksums to the transmitted strings of APRS data or messages, allowing the receiving end to determine if the string has been damaged in transmission. Corrupted "packets" will be displayed locally inside the program, as in most PSK programs, but WILL NOT be passed to external APRS applications (or the Internet, if you are using the igate function).  [Note that due to Messenger's added packet-style checksums, "normal" PSK applications such as Digipan or MixW will NOT interoperate with APRS Messenger, even if they are set to PSK63 instead of the more customary PSK31.]
Unlike most PSK applications that allow you to click anywhere in a waterfall display to select an audio tone frequency for transmission and reception at will, APRS Messenger is fixed on a single audio tone.  The single tone is chosen from a list when the program is first started.  This is actually an advantage for long-term unattended operation; you can't accidentally change the transmit/receive frequency with an errant mouse click.
The program can be used three ways:
  • As a fixed station for HF soundcard-based PSK63/GMSK/MFSK16 APRS send/receive only.

  • As a mobile APRS tracker with an NMEA GPS receiver attached.  The tracker mode also allows full transmit/receive operation for messaging as well. Of course, this mobile "tracker" will require a mobile laptop or netbook, unlike the usual VHF tracker using only a dedicated hardware device like a TinyTrack or OpenTracker.

  • As a dual-port send/receive terminal.

    The first port is the PSK/GMSK/FMSK sound card mode.

    The second port can be any of a variety of external hardware- or software-based TNCs
    on either 1200 baud VHF or 300 baud HF.   For example,  a classic command-line hardware TNC (i.e. TNC2, KPC3, etc), a KISS-interface hardware TNC (i.e. TNC-X, TinyTrack4, Tracker2, etc), or another (separate) sound card software TNC.  The program directly supports the KB2SCS 300/1200 baud soundcard soft TNC, the AGW Packet Engine and the new UZ7HO "Soundmodem".   Currently (as of APRS Messenger Ver 3.27) the latter two are supported on receive-only. Full transmit/receive capability will be provided sometime in the near future in an updated release of APRS Messenger. 

    Incoming traffic for the PSK/GMSK port and the second port appear in separate windows. Each port can have a different callsign/SSID if desired.

    The TNC serial port can accommodate either a physical TNC on a real COM port, a logical COM port created by applications like MixW operating in KISS TNC emulation mode, or a logical COM port provided by the driver for a USB<-->serial "dongle".   The sound card soft TNCs are accommodated by TCP/IP links rather than serial COM ports.  

    Traditionally, the second port TNC, either physical or software-based, was used on 1200 baud VHF APRS at the same time as the PSK sound-card mode was used on HF.  (The program was originally developed to provide a messaging terminal for the hardware
    Cross Country Wireless APRS TNC Digi Tracker.)  However, a 300-baud HF TNC or HF soundcard "soft TNC" can be used on the second port instead.  This allows operation on both classic AX.25 packet-based APRS on 30-meters and the new PSK63-based APRS at the same time.  Note that due to the second port's heritage as a VHF TNC interface, that references to "VHF TNC" appear in various menus, even if the second port is being used on HF.

Note that the application is not a full-fledged APRS client with mapping, although it can be linked to external programs like UIview, APRSpoint or APRSisce.

APRS Messenger Setup

After you download and install the program, this screen will appear each time you start the program:
Check the single audio tone you wish to use for PSK63 operations. Unless you have a specialized requirement (such as wanting the received PSK63 audio to pass through a narrow bandwidth CW filter in the radio's receiver) select the 2100 Hz tone.  Note that the tone selected will determine what RF frequency you set on the transceiver's VFO.  
for an extensive discussion on the relationship between audio tone frequencies and the resulting radio frequencies they produce.
The program can be used three ways:
  • As a fixed station send/receive program with a TNC for VHF send/receive and soundcard setup for HF send/receive.
  • As a fixed station for HF soundcard-based PSK63 send/receive only.
  • As a mobile APRS tracker on HF with an NMEA GPS receiver attached.
If you are using the program  with a hardware TNC on VHF, along with a soundcard setup on HF, check the radio button in the "TNC baud rate box" for the terminal baud rate that matches your TNC.  (This IS NOT the over-the-air baud rate; it's only the speed for the connection between the TNC and the computer and is typically 9600 baud.)
Then select the appropriate COM port in the "TNC comm port" window.   This box, and the "GPS comm port" box above, it will list all serial COM ports found in your system. This includes both physical serial ports and logical COM ports from serial<-->USB dongles, the MixW Serial Port Bridge and anything else that "looks like" a COM port such as ifra-red (IRDA) and BlueTooth interfaces. 
If you are using the program for fixed station operation on HF only with a sound card, check the radio button for "No TNC".  
If you are using the program as a mobile tracker, either on HF or VHF or both,  select the serial com port the GPS is connected to from the list in the "GPS comm port" window.    The GPS MUST provide an industry-standard NMEA-0183 output at either a physical or virtual (i.e. from a serial<-->USB dongle) RS-232 serial COM port.  The GPS must be set to operate at the NMEA-standard 4800 baud output. 
NOTE1: Car-navigator-type GPS units or USB-connected GPS devices will not work unless they provide a hardware interface or software driver to emulate a classic RS-232 serial com port outputting standard NMEA format.  The vast majority of Garmin, TomTom, etc car navigators CAN'T DO THIS. Their USB ports are for uploading software updates, points of interest, battery charging, etc only.  They DO NOT output live data from their internal GPS receivers.

NOTE2:  APRS Messenger does not support separating GPS data from RX TNC data received on the SAME com port, such as provided by the Kenwood APRS radios in "PACKET" mode.  The external TNC (if used) and the GPS must be on separate physical or virtual (emulated) COM ports.

Check the desired APRS symbol from the list. The "GPS beacon text" field is only active if you enable the program as a mobile tracker.  

If you are going to use typical sound card transmit PTT keying via the handshake lines of a serial port, check the appropriate COM number in the "HF PTT Comm Port" box.  If you are using a VOX-activated sound card interface such as the WA8LMF tone-keyed interface described here, or a TigerTronics SignalLink (or the VOX in an HF transceiver), choose "None".
Choose the HF beacon rate. The faster rates are only selectable if the mobile tracker mode is active.

Finally, choose the sound system to used with the program.
The "Sound card or device" array of radio buttons is a vestige from earlier versions of the program. Their use can be confusing. If you have more than one sound card, "Auto select" will select whatever sound system is defined as "default" in the Windows Control Panel "Sounds & Audio Devices" applet.  The other sound system(s) is selected by checking "Card 1". A third card would be "Card 2", etc.  [The "default" sound sytem, whatever it is, is always "Card 0".]  Note that external USB-connected sound systems (such as the TigerTronics SignalLink USB, Mix RigExpert, etc) may show up as different card numbers if plugged into different USB ports on the computer.
Rather than go through the uncertainty of the "Sound card or device" setting, use the pulldown list "Select sound card" instead. This allows you to choose soundcards by NAME, and will automatically check the appropriate radio button in the "Sound card or device" radio button array.

The settings made on this screen will be "sticky", and will return each time you start the program (unless you choose to change them).   Each time you start the program, you have 60 seconds to review and/or change the settings on this startup screen.  If you do nothing, the main screen below will appear after 60 seconds; i.e. the program can recover and start itself automatically after reboots, launches by the UI-View Scheduler or XTR files, etc.  To get to the main screen without the 60 second wait, click the "START" button.

Main Operating Screen

In this screen-shot, N0QBH-63 sent a compressed Mic-E-format position report, just before WA8LMF-60 sent a beacon in the normal APRS "plain-text" format. Another PSK-63-format beacon is currently being received and is visible in the waterfall display, while WA8LMF-60 is getting ready to send a message to W5CQU-63 .

Enter your callsign, including the desired SSID into the "My call" field. The convention is to use an SSID of -63 to make PSK63 stations immediately identifiable on the APRS Internet system, and on any maps displaying a mix of PSK and conventional packet APRS stations. (It is impossible for a conventional AX.25 packet station, HF or VHF, to have an SSID above -15.)
If you want your station location to show up on APRS maps,,, etc , you must enter your coordinates, in proper APRS format, into the "Fixed Beacon or Status Text" box.  Details on the standard APRS position format and the control codes for APRS symbols (a.k.a. "icons") are here on this website. Note that the APRS tracking websites or will not show your station, unless they have received at least one valid position report.
For igate operation, enter any valid APRS server URL into the "APRS-IS Server" field, enter your APRS server validation code into the "Passcode" box, and then click the "Connect to APRS server" button.  The passcode is the same 4 or 5 digit number you got with UIview, APRSplus, APRSpoint, WinAPRS or any other APRS application when you registered it. (The APRS server passcode is based solely on a hash of your callsign; not what program you are using.)
If a white "Beacon ON" button is showing, click the button to start beaconing at the rate selected on the startup screen. If the button is green and showing "Beacon On", the beacon is already enabled. (The button defaults to the green "Beacon On" at startup.) You can manually force a beacon at any time by clicking the "Send HF Beacon" button.

APRS Messenger is capable of supporting both the sound card modes on HF, and a second HF or VHF TNC, either hardware or software (i.e. soundcard-based) at the same time.
The round radio buttons in the "Transmit" area to the right of the waterfall display  allow you to choose which band/mode to transmit on, when sending a message.  You can choose either the second-port TNC (if enabled), or any of the PSK, QPSK or GMSK sound card modes on HF.
Normally, the program also sends any message out the TCP/IP port to the APRS Internet System, in addition to the selected over-the-air mode.  You can send to the Internet System only (no RF transmission) by checking the button "APRS-IS Only". These buttons only determine the mode used to transmit.  The program will automatically receive in all modes without selection.
The current versions of APRS Messenger offer PSK63, MFSK16, and GMSK250 transmit modes on HF. 
  • PSK63 is the original and default mode. It is much slower, but will work with extremely weak signals at far lower signal-to-noise ratios on HF than the MFSK mode. It can receive through extremely narrow bandwidth CW filters (150-200 Hz).  However, because PSK is actually two simultaneous tones, the average to peak ratio of the transmitted tones is low. For the typical "100 watt" output (on key-down CW or FM) HF transceiver, the average power output has to be kept under 25-30 watts to prevent severe intermodulation distortion of the two tones. (This is exactly the same issue encountered in normal PSK31 operating.)
  • MFSK16 is a 16-tone  very-low-symbol-rate  FSK scheme that is incredibly effective at very low signal levels. It can provide solid copy from signals that are literally inaudible in the speaker. Due to the low symbol rate, it is almost totally impervious to HF multipath and phase distortion (i.e. works well on 80 or 160 meters at night or for auroral propagation).  However it is very slow - the same beacon or message takes about 5 times as long to send as with PSK63.
  • GMSK250 uses a single tone at a time, frequency-shifted like classic FSK RTTY or HF packet.   The GMSK mode is far faster, but requires a stronger signal for reliable results, and occupies a greater bandwidth than PSK63 or MFSK16 on the air.   The minimum receiver filter bandwidth will need to be about 500 Hz for reliable results. 

    Some interesting details on how GMSK (Gaussian Minimum Shift Keying) works are here:

    What Is GMSK Modulation" on Radio-Electronics website.
Unlike PSK modes, both MFSK16 and GMSK are  single-tone-at-a-time  modes. As a result, the SSB transmitter or a class C amplifier can be saturated and driven to it's full key-down CW or FM power output,  -without- the intermodulation distortion problems characteristic of  simultaneous-multiple-tones-at-a-time  modes like PSK,MT63 or EasyPal digital SSTV.
The "hardwired" destination "call" for Messenger beacon transmissions on HF is "APSK63" for the PSK mode. It automatically changes to "APSK25" when the GMSK trnasmit mode is selected, and to APSK16 when the MFSK16 transmit mode is selected. This allows you to determine which HF transmission mode was used after-the-fact in program logs, and in listings at and, etc.

Comparison of Waterfall Trace & Occupied Bandwidth
Screenshots from APRS Messenger 3.26 - Tones Centered on 2100 Hz

Since version 2.80, APRS Messenger has the capability of being an HF digipeater. To enable the digipeater mode, check the "HF Digipeat" box. The digipeater function is hardwired to respond to the path "WIDE2-1" only.   Checking "Digipeat Me" adds a single hop WIDE2-1 to your own transmitted path.
To send a message to a specific station, enter the text into the long yellow "Type message" box, enter the callsign (including SSID) into the "Send message to:" box, and then click the "Send" button. 
To send a message to no particular station (such as an announcement or CQ call) enter "APRS" into the "Send message to:" box. If you don't want broadcast messages to be repeated endlessly in a vain effort to receive an ACK, be sure "Satellite mode (No ACKs)" is checked. 

An alternative for broadcast messaging would be to enter "BLNn" as the addressee where N is a number from 01 to 99.  This will make sent messages appear as APRS bulletins to other stations.

Sent message traffic will appear in the large white box.  Received traffic will appear in the lower cyan box. In mobile tracker mode, the upper cyan box will show a continuous live scrolling display of GPS NMEA data, if the GPS hookup is correct and working.
The three yellow "Data" boxes are used only with RAYNET messaging mode. (RAYNET is the British equivalent of ARES or RACES in the U.S.)  Strings entered into the three boxes will be concatenated into a single string, delimited with commas when transmitted.
IMPORTANT:    PSK63 is a simultaneous two-tone transmission, unlike conventional FSK  packet or RTTY which are single-tone-at-a-time constant power transmissions similar to key-down CW. 
It is essential to keep the average output power of the SSB transmitter far below maximum in the PSK mode, to avoid severe inter-modulation distortion (IMD) of the transmitted signal.
High IMD will make your signal occupy excessive bandwidth on the air, and worse make it unreadable to others, even if the RF level is strong.  If the transmit level is PROPERLY SET, the PSK63 signal will be received without errors, even on signals too weak to move the S-meter.
  1. Disable any speech processors, limiters or compressors in the transmitter audio chain.
  2. If you are reading transmitter output power on an averaging-type wattmeter, you must adjust the soundcard audio level (or transmitter mic gain) for an indicated power of about 1/3rd of the keydown maximum power on CW or FM.  You should NOT be showing any ALC (automatic level control) voltage which would indicate that you are at or exceeding maximum transmitter power output.
  3. If you are reading power output on a PEAK reading wattmeter (or monitoring the TX signal on a scope), gradually increase the soundcard output level (or transmitter mic gain) until the power output stops increasing.  Then turn the level back down a bit until the output drops about 20%.  This will ensure that you are not saturating the transmitter power stages. 

Using UIview Or Other External APRS Programs With APRS Messenger

APRS Messenger can easily communicate with external APRS programs such as UIview or APRSpoint to map incoming position reports received via PSK63.   All connections are done via TCP/IP sockets.
APRS Messenger can act as a APRS server on ports 8062 and 8063, and as an APRS client on port 14580, or both at the same time. 
Any APRS application that supports connecting to an APRS Internet Server can connect to APRS Messenger instead.  Set the application to connect to "localhost" on port  8062 or 8063 instead of a "real" APRS-IS server. ("Localhost" is a "magic" TCP/IP address that always refers to your own computer.) In most applications,  this would be expressed as  localhost:8063 .  With most APRS applications, using this hookup will require that you give up your "real" Internet server connection in order to connect to the "virtual" Internet server inside APRS Messenger.
UIview contains a unique advanced feature that simplifies this setup, and allows you to retain a live Internet connection.    In addition to the main TCP/IP port that normally connects to the Internet, UIview has a second "local server" TCP/IP port.  This port makes everything UIview hears or sends, either from RF (via TNC) or the Internet, available to other programs. These programs can be either on the same computer, or on other computers on the same LAN.   [The original intent of the "local server" was to allow a UIview workstation with an RF (radio/TNC) and/or Internet connection to share it's connections with several other APRS workstations in an EOC or special events station.]
To enable the UIview local server to work with APRS Messenger:
  • Shut down UIview if it is running.
  • Open   UIview32.ini   in the main UIview program folder with a basic ASCII text editor such as Windows Notepad. Search for the string [SERVER].  Change the line below, beginning PORT= to PORT=14580. When finished the entry should look like:


  • Save the file and exit.
  • Restart UIview.
  • Pull down "Setup, APRS Server Setup" from the UIview menu bar.
  • Check the box for "Enable local server".  OK and exit.
Note that there is no conflict between the port localhost:14580 and and an address like being used by the main TCP/IP port on the "real" Internet.
Any number of other APRS applications can now connect to "localhost:14580" , if they are on the same computer. APRS programs on other computers on the same LAN can point their Internet connections to "machinename:14580" where machinename is the computer's network name assigned in Windows.
The other programs/machines will "see" any and all traffic that the UIview host sees, either from the Internet or from the radio/TNC.  Any posits heard by, or originated from, external programs (or from other machines on the LAN) will appear on the UIview map. exactly like ones heard by UIview itself. Further, UIview will forward any traffic arriving at the local port out the main TCP port connected to the Internet.

In APRS Messenger, enter "localhost" into the "APRS-IS Server" box, and click the "Connect to APRS server" button. You should immediately see "UIview32 V2.03 APRS Server" appear below the three yellow data boxes. If UIview is connected to a "real" Internet server, you should see the periodic javAPRS keep-alive messages in this monitor area, every few seconds.
When an HF beacon is sent, either automatically or by clicking the "Send HF Beacon" button, it is also sent out the TCP port to UIview. It will show up like any other incoming traffic in the monitor window at the bottom of the UIview screen,  and will immediately plot your own position and PSK63 callsign on the map. 

This screen shot of APRS Messenger on top of UIview shows this operation.  APRS Messenger has just transmitted a beacon with the call WA8LMF-60 . As soon as the PSK transmitter unkeyed, the posit was also echoed out the TCP port to UIview which plotted it on it's map, near Los Angeles. You can see the PSK63 beacon message in the UIview monitor window. The transmission was also sent to the Internet via UIview's main APRS server connection.  [You can also see a conventional AX.25 FSK packet burst in the waterfall display spanning the tone frequencies of 1600/1800 Hz -- just below the PSK tone frequency of 2100 Hz at the display's center.] 
for an actual off-the-air screen shot of 30-meter PSK63 APRS as monitored from my mobile installation. 

Using 30-meter PSK63 APRS And "Classic" AX.25 FSK APRS Simultaneously On The Same Radio

The standard mark and space frequencies for classic AX.25 FSK APRS on 30 meters are 10.149 200 Mhz and 10.149 400 Mhz.  The standard frequency for PSK63 APRS is only 300 Hz higher at 10.149 700 Mhz.  All three frequencies can easily pass through the 2-2.5 KHz bandpass of the typical SSB transceiver at the same time (or even through the typical 500-Hz CW filter, if the passband skirts are not too steep).
Assuming you are using a KAM, MFJ-127x, TNC2 or other TNC hardware or software device that uses standard 200-Hz-shift audio tones of 1600 and 1800 Hz, set your transceiver VFO to an indicated

10.147 600 MHz  USB

This will cause:
·         The 1600 Hz tone to yield  10.149 200 MHz .
·         The 1800 Hz tone to yield  10.149 400 MHz .
·         The 2100 Hz PSK63 tone to yield 10.149 700 MHZ
This is an actual screen shot of the waterfall display in MixW showing a normal FSK packet transmission followed by a PSK63 transmission in the same audio passband of a Kenwood TS-50 on USB. (Radio is set to the frequency above.) MixW is operating in packet mode with the 200-Hz-shift "HF modem" tuned to the 1600/1800 Hz audio tone pair.  MixW is ignoring the PSK63 signal falling just outside the DSP-synthesized passband for FSK operation. [The dark blue band just after the packet burst is the relative quiet in the receiver passband after the transmission, until the radio's AGC recovers and restores full gain to the receiver.)
If you have a reasonably fast PC (800-1000 MHz Pentium III or higher), you can use a sound card "soft modem" to decode FSK packet at the same time APRS Messenger is decoding PSK63 in software.  MixW, the UZ7HO "SoundModem" and AGW Packet Engine Pro version (i.e. the version you pay for) can be set to decode the standard 1600/1800 Hz audio tones that hardware devices like the KAM respond to. In turn, these programs can act as virtual TNCs with virtual COM ports to external programs.  
The most obvious way to do this is to install a second sound card in the PC,  or connect an external sound card interface that incorporates a dedicated sound system such as the TigerTronics SignalLink-USB or Mix Rig Expert to a USB port on the PC.  With this setup, PSK63 is handled by one sound card, and FSK AX.25 by the other.
However, you may not even need a second sound card. One of the less obvious changes in Windows XP and later (compared to earlier versions of Windows) is that more than one program can use the sound card at the same time!  You can actually set APRS Messenger and MixW, UZ7HO or AGWpe to use the SAME sound card at the same time.  This works on receive, and will work on transmit as long as you don't try to transmit on both modes at the same time.   
I have actually successfully run two slow-scan TV programs (mmSSTV for analog and EasyPal for digital) & the AGW Packet Engine simultaneously on the same sound system on a 877 MHz Pentium III Dell Dimension L866r running Windows XP SP3.  The key to doing this is to:

1)   Ensure you DO NOT have numerous unnecessary "crapware" background utilities such as printer status monitors, email pingers, instant messaging clients, automatic updaters, proprietary audio and video control panels, program fast launchers, floating toolbars, "gadgets", etc eating up memory and CPU clock cycles.  You should not have more than 3 or 4 items in the "system tray" next to the Windows clock. [Do not confuse this with the "quick launch" menu at the left next to the "Start" button. These icons represent shortcuts to start programs.  The icons in the "tray" next to the clock represent stuff that is CURRENTLY RUNNING.]

2)   Use a tone-activated sound card interface like the TigerTronics SignalLink USB or my own tone-keyed soundcard interface described
here on this website,  rather than the customary serial-port PTT keying.  This avoids the problem of multiple applications  trying to control the same serial port simultaneously.

3)   Use a HARDWARE-based sound card with it's own accurate dedicated crystal-controlled timebase, instead of the "brain-dead" sound systems integrated into the motherboard of recent computers. Most of the sound system in these systems is emulated in software with massive drivers, while the timing is derived from CPU interrupts competing for CPU air time with all the other processes running on the machine.  This places a huge load on the CPU, making multitasking multiple sound card applications that depend on precise timing difficult.  A Tigertronics SignalLink USB or Mix Rig Expert provides it's own accurately-timed "sound card", or try almost any inexpensive USB-connected external sound system to take a lot of loading off the CPU. 

Reviews of two low-cost external sound systems (the Griffin Electronics "iMic" and the Behringer UCA-202) that are excellent for ham soundcard-app purposes are
here and here on this website.

(The venerable Dell mentioned above actually has the dedicated hardware components of a Soundblaster 64 PCI card built onto the motherboard, rather than the software-based AC'97 sound system found in nearly all newer machines.  As a result, this "mere" Pentium III 866 MHz machine runs sound card apps BETTER than most newer multi-GHz "hotrods" with dumber sound systems!)

If you wish to use the freeware version of the AGW Packet Engine with it's tones of 2100 Hz and 2300 Hz, the PSK63 tone now has to be 300Hz above the higher of these, or 2600 Hz.   To make these land on the same *RF* frequencies as above, you will now have to set the suppressed carrier (i.e. "dial") frequency of the radio to 10.147.100 MHz.

     10.147 100 MHz + .002 100 =  10.149 200 MHz  Packet MARK
     10.147 100 MHz + .002 300 =  10.149 400 Mhz  Packet SPACE

     10.147 100 MHz + .002 600 =  10.149.700   PSK63

The problem is that virtually NO SSB rigs have audio passbands/filter systems that will pass an audio tone as high as 2600 Hz.

[  Unless of course you are one of the hard-core guys at the low end of 75 meters at night playing with "HiFi" SSB using broadcast audio consoles and studio condenser mics, running heavily modified rigs employing special wide-band filters on SSB! ]

If the 2600 Hz tone does somehow just barely get through the SSB filter, the tone will land right on the filter's upper skirt where it will be subject to severe phase shift and group-delay distortion. (Which is exactly what you DON'T want in a phase-shift modulation scheme!)

Operating on *LSB* (rather than *USB**INVERTS* the tone relationship; i.e. the higher the audio tone, the LOWER the resulting RF frequency.

If one places the PSK63 tone 300 Hz below the lower AGWpe packet tone of 2100, it will be safely within  the SSB audio passband.   (You would check the 1800 Hz choice in APRS Messenger.)   Setting the radio to a suppressed carrier (i.e. "dial") frequency of 10.151 500 MHz on LSB will invert the tone relationships and yield the following:

     10.151 500 MHz - .001 800 = 10.149 700   PSK63

     10.151 500 MHz - .002 100 = 10.149 400   Packet SPACE
     10.151 500 MHz - .002 300 = 10.149 200   Packet MARK

Note that while the dial indicates you are transmitting outside the ham band, the suppressed carrier frequency of 10.151 500 Hz IS NOT TRANSMITTED (assuming your rig is properly aligned with good carrier suppression).  As long as you generate audio tone(s) higher than 1.500 Khz, the resulting modulation products will be inside the ham band, assuming you don't overdrive the transmitter modulator and produce intermodulation distortion.

HOWEVER, most current ham gear will not transmit when the indicated carrier frequency is moved outside the ham bands.  You will have to hack the radio for the so-called general-coverage transmit capability.  This is usually a trivial exercise, done by clipping a single diode on the radio's controller board or slashing one board trace with an X-Acto knife and then resetting the radio's CPU.   See

<> for info on the general-coverage mod for virtually any HF/SSB transceiver.

Understanding Frequency Relationships on HF/SSB

Perhaps the most confusing issue for newcomers to HF is the difference between the FM modulation mode they know on VHF, and the FSK or SSB modulation modes used on HF. There is considerable mis-understanding about the relationship between the audio frequencies produced by packet TNCs or "sound card" data programs on computers, and the radio frequencies that result from these tones.
SSB radio transmission can be through of as a frequency translator that shifts audio frequencies to radio frequencies (RF) while retaining their relative spacing.  At the receiver, the radio frequencies are shifted back down to audio. If the transmitter and receiver are on exactly the same radio frequency, the recovered audio frequencies will be the same as the originals.   If the transmitter and receiver are not on the exact same radio frequency, the recovered audio frequencies will be different from the originals.  For example, if the receiver is on a frequency 100 Hz different from the transmitter, all recovered audio tones will be 100 Hz higher or lower, depending on the direction of the error. 
The effective bandwidth of the DSP-synthesized audio filters in PSK receive software are extremely narrow; often less than 70 Hz. Because the audio frequencies recovered in the receiver are directly proportional to radio frequency errors,  you must be able to accurately set the radio frequency to within 20 Hz or so, and keep it there indefinitely.  Old mechanical-dial analog-VFO radios such as Kenwood TS-820s, Yaesu FT-101s and 707s, Heathkit SB-101s, etc are hopeless for this kind of operation. They simply can't be set precisely enough in the first place and thermally-induced frequency drift will guarantee that they will quickly "wander" off frequency.  The frequency calibration/resolution issue is especially critical if you are going to transmit "in the blind" without a signal to tune in on receive first! (I.e. typical transmit-only mobile trackers that don't receive.) Ideally you want a modern synthesized rig with an accurately calibrated TCXO high-stability master oscillator.

The digital frequency displays on modern radios ARE NOT frequency counters.  They DO NOT guarantee that you are actually on the frequency shown in the readout.
The display is only an indicator of the frequency that the radio's frequency synthesizer has been requested to produce.  The actual frequency produced is determined by the calibration of a single master frequency standard; typically a 5.0 or 10.0 Mhz temperature-controlled crystal oscillator. If this master oscillator is off-frequency, ALL generated receive/transmit frequencies will be correspondingly off frequency, regardless of what the digital display says.
The only way to know that the displayed "dial frequency" is correct is to tune in a known-accurate standard-frequency station such as WWV (or an accurately-calibrated RF signal generator)  and verify that the display reads correctly.
Since the master oscillators of most synthesizers operate at 5 or 10 Mhz, one can usually couple a small sample of the oscillator's signal back into the antenna jack (use a piece of wire or a meter probe & a coax "tee" connector). While receiving on AM, directly compare the standard's frequency with WWV on the appropriate frequency. [This works especially well on 30 meters since the 10 MHz WWV signal is only 100-150 KHz down the band; any 30M antenna should receive it very well.]  If the two frequencies are different, you will hear a growl or squeal. If they are the same, you will hear nothing (or a slow "pulsating" of the background noise if the two are a fraction of a Hz apart in frequency).
If there is an error, you adjust a small variable capacitor that is part of the frequency standard to "pull" the crystal's frequency ever-so-slightly to make it match WWV's frequency.  [Traditionally this process was referred to as "zero-beating" as the squealing tone will drop to nothing as you match frequencies and then rise again as you move off to the other side of WWV's frequency.] Usually this alignment process requires taking the cabinet off the radio, although some radios do provide an access hole on the side or bottom of the case.
Or note the frequency error and add (or subtract, depending on the error direction) this value from the dial reading to determine what frequency you are really on.

On SSB equipment: 
  • The indicated "dial frequency" on SSB is the suppressed carrier frequency.
  • The suppressed carrier frequency is NOT transmitted.
  • What IS transmitted are frequencies that are offset above the carrier freq on USB (or below the carrier on LSB) by the exact value of the AUDIO tones fed into the radio mic jack from the TNC, soundcard, modem, etc.
  • Feeding a single audio tone into the mic jack of an SSB rig causes the transmitter to produce a single RF frequency. Feeding a different frequency audio tone into the same rig causes a different single RF frequency to be produced.  With NO tone into the mic jack, a keyed-up SSB transmitter produces NO RF output at all.
  • On voice, the complex mixture of multiple simultaneous audio frequencies in the voice causes a corresponding group  of simultaneous RF frequencies to be generated; i.e. a "sideband" rather than a single RF frequency.
Since the net resulting RF signal frequencies are the sum (or difference) of both the modulating audio tone frequencies and the RF frequency,  simply quoting the RF "dial frequency" for HF data modes is ABSOLUTELY MEANINGLESS unless you qualify it with the AUDIO tone frequency being used.
The actual transmitted RF frequency is the indicated suppressed carrier frequency (i.e. "dial frequency") plus the audio tone frequency (USB)  -or- the suppressed carrier frequency minus the audio tone frequency (LSB).  The actual dial frequency you want WILL DEPEND ON THE SIDEBAND YOU CHOOSE (either one will work) --AND-- ON THE PARTICULAR AUDIO TONE FREQUENCY produced by the PSK program.
It is highly recommended to use USB rather than the more common LSB because:
  • USB is the universal standard for HF/SSB operation with commercial/marine/aviation/military radios on all frequencies. Only ham equipment normally offers LSB operation.
  • Audio spectrum and "waterfall" displays read "right-side up"; i.e. a higher RF frequency shows as a higher audio frequency. (On LSB, the relationship between RF frequency and audio frequency is inverted -- can be very confusing when tuning.)
  • You avoid the need to "hack" the radio to allow "out-of-band" transmit (i.e. set the VFO to an indicated frequency above 10.150 000 MHz) as is required on LSB. 
The differing AUDIO frequencies are really not a problem on SSB, and are easily accommodated. Unlike FM, the audio frequency heard at the receiving end is affected by the exact RF frequencies the transmitter and/or receiver are set to.

The audio frequency heard in the receiver will change exactly Hz for Hz with changes of the radio frequency tuning dial. You cause the the audio tone frequencies heard in the receiver to be the ones required by your program, by tuning the receiver to a slightly higher or lower RF frequency.

[This cuts both ways. If the transmitter is off frequency, the audio tones recovered at a correctly-tuned receiver will be correspondingly off-frequency.]

AGAIN: Quoting "dial frequency" alone on non-FM modes is ABSOLUTELY MEANINGLESS unless you qualify it with mode (USB/LSB/DATA, etc) and the AUDIO tone frequencies in question.

The single RF frequency for  30-meter PSK63 APRS operation is

10.149 700 MHz
(This radio frequency is 300 Hz higher than the higher of the
 two FSK frequencies for conventional AX.25 APRS packet.)

No matter how you diddle and fiddle with audio and radio "dial frequency" settings, the end result must be this frequency. The simplest way to achieve this frequency is to set the PSK63 audio tone in APRS Messenger to 2100 Hz, and the transceiver's RF ("dial frequency") to 10.147 600 MHz USB.
It is highly recommended to use USB rather than the more common LSB because:
  • USB is the universal standard for HF/SSB operation with commercial/marine/aviation/military radios on all frequencies. Only ham equipment normally offers LSB operation.
  • Audio spectrum and "waterfall" displays read "right-side up"; i.e. a higher RF frequency shows as a higher audio frequency. (On LSB, the relationship between RF frequency and audio frequency is inverted -- can be very confusing when tuning.)
  • You avoid the need to "hack" the radio to allow "out-of-band" transmit (i.e. set the VFO to an indicated frequency above 10.150 000 MHz) as is required on LSB. 
The audio tones used by particular devices, the desire to use narrow-band CW or audio filters, passband tuning limitations, or the needs of simultaneous FSK/PSK63 operation may require you to use other tone frequencies and/or LSB mode operation. 
The combinations of audio tone frequencies and indicated RF "dial" frequencies required to place the actual transmitted signal on the correct RF frequency (10.149 700 MHz) are summarized in this table:
Audio Tone
Freq in Hz
Selected In
APRS Messenger
"Dial" Frequency
"Dial" Frequency
10.149 000
10.150 400
Allows use of 500-Hz narrowband CW receive filters on most HF rigs.
10.148 400
10.151 000
Compatible on LSB with standard KAM/TNC2/AGWpe Pro tones on HF (1600/1800 Hz) for simultaneous conventional FSK/PSK63 operation.
10.148 300
10.151 100

10.148 200
10.151 200.

10.148 100
10.151 300.
Compatible on USB with odd-ball TigerTrak HF tones (1100/1300 Hz) for simultaneous conventional FSK/PSK63 operation.
10.147 900
10.151 500
Compatible on LSB with freeware AGWpe or AEA/Timewave PK-232 tones on HF (2100/2300 Hz) for simultaneous conventional FSK & PSK63 operation.

Compatible on USB with SCS Pactor modems default AX.25 tones (1400/1600) Hz, for simultaneous conventional FSK & PSK63 .
10.147 600
10.151 800
Compatible on USB with standard KAM/TNC2/AGWpe Pro tones on HF (1600/1800 Hz) for simultaneous conventional FSK & PSK63 operation.

Cross Country Wireless APRS Messenger program

The APRS Messenger program provides a simple way to send and receive APRS messages from an APRS TNC Digi Tracker on VHF and by APRS over PSK, MFSK and GMSK modes on HF.

Features include:

·         Serial terminal program to setup APRS TNC Digi Tracker
·         APRS over PSK, MFSK and GMSK modes for high performance HF APRS using the PC soundcard/
·         Receive only Igate for VHF APRS
·         Two way messaging smart Igate for HF APRS over PSK, QPSK and GMSK
·         APRS over PSK, QPSK and GMSK has packet error checking and frequency hopping receiver AFC/
·         GPS beaconing over APRS over PSK, QPSK and GMSK for HF mobile use
·         Now with twenty four simultaneous receivers for PSK, MFSK and GMSK modes
·         Now has PSK, MFSK, GMSK and APRS-IS only transmit options
·         Simple to use for APRS messaging to the latest APRS specification
·         Emergency messaging format for special event and emergency use
·         Packet converse mode for multi-operator net messaging
·         All messages saved to separate transmit and receive log files on the computer hard drive for later evaluation
·         Can send messages with non-English characters depending on Windows language settings
·         TCP/IP output on port 8063 to connect to RadioMobile or APRSIS32 for map display
·         Igate HF/VHF transmit function can be remotely controlled by an APRS message
·         Tested on all versions of Windows from Windows 95 to Windows 7
APRS Messenger version 3.27 can be downloaded as a freeware 1.3 MB zip file here .
This latest version has a modified decoder routine to allow Mic-E APRS packets to be received over HF digimodes.
This allows it to work with a new PSK-63 GPS tracker under development by Mike Berg, N0QBH.
It also has the MFSK-16 mode as an option. MFSK-16 can operate down to very low signal/noise ratios typically down to -13.5 dB below the noise power in a 2.5 kHz bandwidth.
This version has multiple software receivers per mode to improve the receive performance with a revised receiver routine.
MFSK-16 and the GMSK modes are useful as they can be run at full power through a SSB transceiver or Class C amplifier.
It is now possible with this version to remotely control the VHF and HF transmit function with an APRS message sent over HF, VHF or the APRS-IS.
It also has an APRS-IS transmit option to send messages to other radio amateurs directly via the APRS-IS internet system.
This version will run on all versions of Windows and uses minimal CPU resources so will run on older PC's.
It has also been tested running on Linux on Ubuntu 10.04 running on Wine.
This version can now work with the new USB version of the APRS TNC Digi Tracker using any comm port up to 255.
It can also be used with a KISS TNC or the AX25-SCS DSP TNC program as a sound card TNC for 300 or 1200 bd AX.25 APRS.
Received APRS messages are also available on TCP/IP port 8064 for distribution to other programs. This version uses the KISS routine from the discontinued APRS-SCS program written by John Blowsky, KB2SCS.

A Windows installer for the AX25-SCS DSP TNC program can be downloaded
here. This will allow the installation of AX25-SCS and the drivers needed for Windows PCs.

A useful web page describing the set-up and theory behind APRS Messenger is available here.
The frequencies used for APRS over PSK, MFSK16 and GMSK are 10.1497 MHz worldwide and 7.0497 MHz in the UK. A frequency of 14.1017 MHz is also used for Net14 APRS over digimodes and testing of APRS over MFSK16 is currently taking place on this frequency. Radio frequency on a SSB transceiver is dial frequency + tone frequency USB or dial frequency - tone frequency LSB. Igates in Europe, US and Australia are already in operation. Please use an SSID of -63 for APRS over PSK, MFSK and GMSK operation. The original program only had PSK-63 hence the choice of -63.
Although the program is designed to promote our APRS TNC Digi Tracker it will work with other serial TNC's that accept the conv and Ctl-C commands for converse operation.
Contact Chris Moulding, G4HYG via  for more details or to provide feedback on the program.

Click to join cross_country_wireless
APRS is a registered trademark of Bob Bruninga WB4APR. Click here to view Bob's website.
Cross Country Wireless Ltd is licensed by the trademark holder so that our
APRS TNC Digi Tracker can be offered as a commercial product.

APRS is an international network of amateur radio stations providing real-time GPS based vehicle or event position reporting, weather reporting and simple message handling for educational, experimental or emergency use. APRS uses a common radio frequency of 144.800 MHz throughout Europe. Digital repeating (digipeating) is used to extend the range of mobile and low power stations over a wider area. In addition to the radio network internet gateways provide a two-way port to the APRS-IS (APRS Internet System) so that stations local to the gateway can be seen worldwide on APRS viewing programs such as Xastir or UI-View.

APRS over PSK and GMSK is a new mode allowing mobile or fixed station
APRS operation on HF from remote areas away from the coverage of the VHF APRS network. Using 10.1497 MHz as a common frequency in Europe and the USA a typical range of 400 to 2000 miles from fixed and mobile stations using modest equipment can be expected. There are several Igates operating in Europe and the USA transferring received packets and messages from 7.0497 MHz and 10.1497 MHz to the APRS-IS.