Satellite tracing is donated to the DIGI_NED project by Alex Krist, KG4ECV. Alex wrote two papers with information about this function, "Sattrack.txt" and "Sattrack.doc" which are included in the distribution.
Alex presented his implementation of satellite tracking in DIGI_NED at the Charleston, SC Hamfest February 3, 2001. In this chapter many of the information out of his documents is copied.
The objective of the Satellite Tracking module in DIGI_NED is to give APRS users a tool to track satellites on APRS without having to invest time and/or money in satellite tracking software. APRS users can use their APRS client software to obtain satellite-tracking information. The only requirement on the client side is that the APRS client must be able to send regular APRS messages.
To minimize channel load, the module has been implemented in such a way that tracking is only done on demand. No bandwidth is wasted by loading the channel with information that no one requested. The software is designed so that the tracking module can be excluded from DIGI_NED in order to minimize the size of the executable in case this functionality is not desired and/or if the size of the executable is of concern.
General The tracking module has three main functions. These are,
- Satellite Inquiry,
- Satellite Tracking
- and Updating of the Satellite Information Database.
An APRS user can inquire DIGI_NED for information about a particular satellite by sending a message query to DIGINED. The satellite-tracking module in DIGI_NED uses the 4 position Amsat designator to specify satellites (i.e. Sunsat is so35). Such a query could look like:
Upon reception of this message, DIGI_NED will send back a message informing the user whether or not the satellite is in range, and an object containing information about the satellite. This object will be displayed by the APRS client software on a map. The status text of the object will contain AOS (Acquisition Of Signal) information if the satellite is not in range. For example:
AOS@2-3 12:00 LOC
This means that the next pass will be as 12 noon on February third, local time. The time can also be indicated in UTC, and is configurable by the digi owner. If the satellite is in range, the status text will contain information necessary to track the satellite. For example:
U145.823 7D435.398 1 E71 A123 MB
This status text informs the user of the doppler-corrected uplink and downlink frequencies (U145.823 D435.398), the elevation angle (E71), the azimuth (A123) and in which mode the satellite is operating (MB, Mode B). The extra 7 and 1 in the status text are for display purposes only on a Kenwood TH-D7A(G)/E. This allows for display of elevation and azimuth together on the first screen of the object information display on this particular radio. In case the satellite does not exist or if the query is not correctly formulated, DIGI_NED will send an appropriate error message back to the APRS user.
Satellite Tracking Tracking is actually very similar to Satellite Inquiry. An example of a tracking query is:
The main difference between inquiry and tracking is that after sending the initial in range/out of range message and initial object, DIGI_NED will be put in tracking mode. This means that DIGI_NED will continuously transmit objects with updated satellite information up to a maximum allowed time set by the digi owner. The interval between the transmission of objects depends on whether or not the satellite is in range. If the satellite is out of range, an object is only transmitted every 15 minutes.
As soon as the satellite comes in range DIGI_NED will transmit a new object every minute. When the satellite disappears below the horizon again, DIGI_NED will resume transmitting objects at the long interval.
These intervals can be configured by the digi owner. The information in the status text of the object changes dynamically also. While the satellite is out of range it will contain AOS information, and tracking information when the satellite is in range.
Updating Satellite Information.
In order for Satellite Inquiry and Satellite Tracking to be meaningful, the satellite database containing the keppler elements of each satellite needs to stay current.
Just download a new keppler sets in TLE format from the Amsat website (http://www.amsat.org) or from the ARRL website (http://www.arrl.org). Copy this into the update file specified by the update_tle_file rule and issue the "utle" command. Do this about every two weeks. Every week is better. You can also subscribe to a mailing list on both sites which will send you a new file every week. Take advantage of these services so that you will be reminded to update your satellite database on a regular basis.
Don't worry if the file you are downloading also contains satellites or other space objects that you have not defined in your satellite database. The update command will simply ignore these objects. Also, if the file you download does not contain a satellite you have in your database then the satellite will not be deleted from your database.
To update the satellite database, one can put a NASA Two Line Element (TLE) file in a specified directory on the DIGI_NED computer (remotely if necessary) and then send the update command to DIGI_NED. This command is:
This stands for Update Two Line Element. Once this command is issued, DIGI_NED will read the TLE and extracts the information needed to update its satellite information database.
This command can only be issued by the digi owner and the file names and directories can be specified in the DIGI_NED configuration file.
The availabilty of satellites in the sattelite service depends to what is made available bij the DIGI_NED owner. The following satellites and spacecrafts are a example of what could be available in the satellite information database:
OSCAR-10 AO10 OSCAR-11 UO11 OSCAR-14 UO14 PACSAT AO16 WEBERSAT WO18 LUSAT LO19 OSCAR-20 FO20 OSCAR-22 UO22 OSCAR-23 KO23 OSCAR-25 KO25 ITAMSAT IO26 OSCAR-27 AO27 OSCAR-29 FO29 OSCAR-36 UO36 TECHSAT GO32 TMSAT TO31 SEDSAT-1 SO33 RS-12/13 RS12 RS-15 RS15 AO-40 AO40 SAUDI-1A SO41 SAUDI-1B SO42 MIR MIR_ ISS ISS_
The underscores are necessary when the designator is only 3 characters long. DIGI_NED expects a 4-letter designator.
Actually, the satellite-tracking module needs only one file, besides the sources of course if you compile it under Linux. This file is the Satellite Information Database. This file contains 24 satellite entries. A fully functional and up to date (as of March 2001) database is included with this distribution of DIGI_NED. The name of the file is "digi_ned.sat".
Another file that is of interest and is included with this distribution is the "digi_ned.tle file". This file contains update information for the Satellite Database.
Standard the satellite option is compiled in the distribution. But for some reason it might be necessary to do it manually.
When compiling with BCC3.1 the sattrack files need to be added to the project file. To do this, open the project menu, this can be done through the menu Window->Project. Press insert in the Project window. A dialog window appears. In the Name field first type "sat.c" and then press tab. Click the Add button. Then enter "predict.c in the Name field and hit TAB. Click the Add button. Now the dialog can be closed, click Done. At this point we have added the new
sources to the project. Now we have to add the definition _SATTRACKER_. Otherwise, DIGI_NED will still compile without this function. To do this open the Options Menu. Select
Compiler. Choose the entry Code generation... Now you have a dialog with a number of fields. One of them is a field with the label "Defines". There you fill in _SATTRACKER_. After you're done, press OK. In the project file shipped with the DIGI_NED source the sattracker is
already enabled. If you don't want to use the sat tracker remove the _SATTRACKER_ definition in the Options->Compiler->Code generation... dialog. You can build the code by selecting "Build all" from the Compile menu.
Near the top of the Makefile file you will find the following section:
# if satellite tracker needs to be included then uncomment the next line
#DEFS += -D_SATTRACKER_
To include the satellite-tracking module in DIGI_NED make sure that the pound sign (#) preceding the "DEFS += -D_SATTRACKER_" line is removed.
Then issue a "make clean" to remove old code and then issue a "make depend" to resolve code dependencies. Finally run "make" (no parameters) to build the executable.
In the current distribution de '#' is removed by default. If you don't want to use the sat tracker then add the pound sign (#) as shown above.
Configuration of the satellite tracking module:
The satellite tracking module is fully configurable through the *.ini file which is read at startup of DIGI_NED. This module introduces several new rules, which I will describe below. I'll also include an example of the rules section.
The first rule is actually not a new one, but one that was introduced when the dx functionality was implemented in DIGI_NED. This is the digi_pos: rule. The satellite tracking module uses this rule to determine the position of the digi and uses it in the calculation necessary to predict passes of a satellite. See the DIGI_NED documentation for an explanation of these rules. Example:
digi_pos: 5213.61N 00600.00E
The position may also be defined in through the digi_pos_file (see DIGI_NED documentation) as:
The altitude rule indicates at what altitude, in meters, the digi resides. It's not a very critical parameter but we do need it for the calculations. 1 meter is approximately 3.28 feet. Example:
As a digi owner you also need to decide if you want the information AOS time information to be displayed in either UTC or local time. This has nothing to do with the time of creation of the object. That will always be displayed in UTC per APRS Specifications. This rule accepts two values. "1" for local time, "0" for UTC. If one chooses local time, then AOS information will be displayed in the object as "AOS@08-02 17:00 LOC". If UTC is chosen then the
info will be displayed as "AOS@08-02 22:00 UTC" Example:
For satellite tracking you also need to specify the UTC offset for the digi. For EST this would be -5. Make sure you correct this for daylight savings.Example:
To specify the interval at which objects should be transmitted when a satellite is in range, use the sat_in_range_interval rule. The inteval is specified in minutes. Example:
To specify the interval at which objects should be transmitted when a satellite is out of range, use the sat_out_of_range_interval rule. The interval is specified in minutes. Example:
You can set the maximum time you want a satellite to be tracked with the
track_duration rule. It takes most FM birds to orbit the earth in about one and a half hour. So a good choice is something just above that. This rule has been introduced to prevent DIGI_NED from having to track a satellite indefinitely when someone requests it. If a person needs to track it longer than they can just reissue the request. Track duration is specified in minutes. Example:
The file containing the satellite database can be defined by the satellite_file rule. You can specify a path if you want. If you don't, then the module will assume it's located in the same directory as the DIGI_NED executable. Example:
The file containing Two Line Element (TLE) information from which DIGI_NED can update its satellite database is specified through the update_tle_file rule. The same goes as for the satellite database file specification; you can specify a path, but if you omit the path, DIGI_NED will assume it is located in the same directory as the DIGI_NED executable.
In the DIGI_NED configuration examples the satellite tracking default values are also given
A suggestion would be to issue a bulletin or announcement to the local APRS network announcing that you have this service available. In fact it may be a good idea to do this if you have an active Tiny Web Pages server on your DIGI_NED digi. This is pretty much the only way to inform people that you have this service available (besides the regular status text in your posit of course).