OpenTrack
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
Master
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
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 FindU.com 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.
http://hackaday.com/2013/11/21/a-low-cost-modular-high-altitude-balloon-tracker-with-mesh-networked-sensors/
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 FindU.com 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.
http://hackaday.com/2013/11/14/long-distance-high-frequency-aprs-tracking-using-the-freetrak63/
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.
Quick-Start
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.
Troubleshooting
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.
Master
Accessories
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.
Configuration
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.
[general]
temp = 5 ; Heater regulation temperature, Degrees C
[blackout]
enable = true
timeout = 1200000 ; Turn off non-critical leds after X ms
[buzzer]
failsafe = 9600000 ; Trigger buzzer after X ms
[aprs]
call = "XXXXXX" ; APRS callsign
call_id = 11 ; Callsign ID (11 for balloon)
period = 35000 ; APRS transmit interval (ms) no less than 30,000
; EOF
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.
Configuration
[general]
temp = 5 ; Heater regulation temperature, Degrees C
reqrate = 3000 ; Query slaves for data every X ms
[blackout]
enable = true
timeout = 1200000 ; Turn off non-critical leds after X ms
[buzzer]
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
[aprs]
call = "XXXXXX" ; APRS callsign
call_id = 11 ; Callsign ID (11 for balloon)
period = 35000 ; APRS transmit interval (ms), no less than 30,000
; EOF
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 http://aprs.fi/. 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:
KD8TDF-11>APRS,WIDE2-1:/051959z3907.30N/08330.64WO145.25/37.886~v37.886~_976~|704~t911~s08~h1.01~t010~l056~t12~l10~P62965~C0~H999~A12586
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.
Troubleshooting
Master
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.
Slave
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)
sensors_readAnalog(2);
sensors_readAnalog(5);
// Read a digital value from PORTA pin 6 (PA6)
sensors_readDigitalPORTA(6);
// Read a digital value from PORTD pin 6 (PD3)
sensors_readDigitalPORTD(5);
}
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
masterComm_packetSend_unsigned('d',sensors_getDigital(6));
// Send second digital reading
masterComm_packetSend_unsigned('G',sensors_getDigital(5));
break;
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
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.
Components
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.
Assembly
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!
Programming
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 aprs.fi.
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
- 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
|
Software
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:
wire
|
purpose
|
Raspberry Pi
|
orange
|
+5V power supply
|
GPIO 1-2
|
orange-white
|
transceiver PTT/TX
|
GPIO 6
|
green
|
transceiver audio signal
|
3.5 mm TRS jack
|
green-white
|
transceiver audio signal GND
|
GPIO 3
|
blue
|
UART TX
|
GPIO 4
|
blue-white
|
UART GND
|
GPIO 3
|
brown
|
UART RX
|
GPIO 5
|
brown-white
|
UART GND
|
GPIO 3
|
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
CONFIGURING THE FT-63
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.
A
parts list, schematic and manual are included in the FT-63 files download.
HF APRS Using PSK63
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:
http://www.crosscountrywireless.net/aprs_messenger.htm
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, findu.com, aprs.fi, 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 findu.com or APRS.fi 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 APRS.fi and findu.com, etc.
Comparison of Waterfall Trace & Occupied Bandwidth
Screenshots from APRS Messenger 3.26 - Tones
Centered on 2100 Hz
|
PSK63
|
MFSK16
|
MFSK250
|
|
|
|
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.
- Disable any speech processors, limiters
or compressors in the transmitter audio chain.
- 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.
- 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:
[SERVER]
PORT=14580
- 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 socal.aprs2.net:14580 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
<http://mods.dk> 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.
VERY IMPORTANT
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
|
USB
Radio
"Dial" Frequency
|
LSB
Radio
"Dial" Frequency
|
Comments
|
700
|
10.149 000
|
10.150 400
|
Allows use of 500-Hz narrowband CW receive filters on most HF rigs.
|
1300
|
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.
|
1400
|
10.148 300
|
10.151 100
|
|
1500
|
10.148 200
|
10.151 200.
|
|
1600
|
10.148 100
|
10.151 300.
|
Compatible on USB with odd-ball TigerTrak HF tones (1100/1300
Hz) for simultaneous conventional FSK/PSK63 operation.
|
1800
|
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.
|
1900
|
10.147.800
|
|
Compatible
on USB with SCS Pactor modems default AX.25 tones (1400/1600)
Hz, for simultaneous conventional FSK & PSK63 .
|
2100
|
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:
·
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 info@no_spam_crosscountrywireless.net 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.
