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)
- Bug tracker - View and file bugs against project
- Hardware repository - View and download hardware design files
- Firmware repository - View and download firmware source code
- UI repository - View and download desktop app source code
- Quick-Start
- Preparing for Launch
- OpenTrack XBee Configuration
- Module Development Guide
- Build your own OpenTrack System
- Ground Station Application
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
[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
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)
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.
- Recommended male header: M22-2511005
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
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 codeTrackuino – 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
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
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
- HA5KDR article (in Hungarian)
- Dangerous Prototypes
- Hack a day
FreeTrak63 - APRS PSK63 TrackerBuild 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.
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.
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.
APRS Messenger Setup
After you download and install the program, this screen will appear each time you start the program:
for an
extensive discussion on the relationship between audio tone frequencies and
the resulting radio frequencies they produce.
|
- 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.
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
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.
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.
|
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.
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.]
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.
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 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.) |
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 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.
|
The APRS Messenger program provides a simple way to send and receive APRS messages from an APRS TNC Digi Tracker on VHF and by APRS over PSK, MFSK and GMSK modes on HF.
Features include:
·
Serial terminal program
to setup APRS TNC Digi Tracker
·
APRS over PSK, MFSK and
GMSK modes for high performance HF APRS using the PC soundcard/
·
Receive only Igate for
VHF APRS
·
Two way messaging smart
Igate for HF APRS over PSK, QPSK and GMSK
·
APRS over PSK, QPSK and
GMSK has packet error checking and frequency hopping receiver AFC/
·
GPS beaconing over APRS
over PSK, QPSK and GMSK for HF mobile use
·
Now with twenty four
simultaneous receivers for PSK, MFSK and GMSK modes
·
Now has PSK, MFSK, GMSK
and APRS-IS only transmit options
·
Simple to use for APRS messaging to the latest APRS specification
·
Emergency messaging
format for special event and emergency use
·
Packet converse mode for
multi-operator net messaging
·
All messages saved to
separate transmit and receive log files on the computer hard drive for later
evaluation
·
Can send messages with
non-English characters depending on Windows language settings
·
TCP/IP output on port
8063 to connect to RadioMobile or APRSIS32 for map display
·
Igate HF/VHF transmit
function can be remotely controlled by an APRS message
·
Tested on all versions
of Windows from Windows 95 to Windows 7
APRS Messenger version 3.27 can be downloaded as a freeware 1.3 MB zip
file here .This latest version has a modified decoder routine to allow Mic-E APRS packets to be received over HF digimodes.
This allows it to work with a new PSK-63 GPS tracker under development by Mike Berg, N0QBH.
It also has the MFSK-16 mode as an option. MFSK-16 can operate down to very low signal/noise ratios typically down to -13.5 dB below the noise power in a 2.5 kHz bandwidth.
This version has multiple software receivers per mode to improve the receive performance with a revised receiver routine.
MFSK-16 and the GMSK modes are useful as they can be run at full power through a SSB transceiver or Class C amplifier.
It is now possible with this version to remotely control the VHF and HF transmit function with an APRS message sent over HF, VHF or the APRS-IS.
It also has an APRS-IS transmit option to send messages to other radio amateurs directly via the APRS-IS internet system.
This version will run on all versions of Windows and uses minimal CPU resources so will run on older PC's.
It has also been tested running on Linux on Ubuntu 10.04 running on Wine.
This version can now work with the new USB version of the APRS TNC Digi Tracker using any comm port up to 255.
It can also be used with a KISS TNC or the AX25-SCS DSP TNC program as a sound card TNC for 300 or 1200 bd AX.25 APRS.
Received APRS messages are also available on TCP/IP port 8064 for distribution to other programs. This version uses the KISS routine from the discontinued APRS-SCS program written by John Blowsky, KB2SCS.
A Windows installer for the AX25-SCS DSP TNC program can be downloaded here. This will allow the installation of AX25-SCS and the drivers needed for Windows PCs.
A useful web page describing the set-up and theory behind APRS Messenger is available here.
The frequencies used for APRS over PSK, MFSK16 and GMSK are 10.1497 MHz worldwide and 7.0497 MHz in the UK. A frequency of 14.1017 MHz is also used for Net14 APRS over digimodes and testing of APRS over MFSK16 is currently taking place on this frequency. Radio frequency on a SSB transceiver is dial frequency + tone frequency USB or dial frequency - tone frequency LSB. Igates in Europe, US and Australia are already in operation. Please use an SSID of -63 for APRS over PSK, MFSK and GMSK operation. The original program only had PSK-63 hence the choice of -63.
Although the program is designed to promote our APRS TNC Digi Tracker it will work with other serial TNC's that accept the conv and Ctl-C commands for converse operation.
Contact Chris Moulding, G4HYG via 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.
