![]() |
Downloading
|
InstantTrack 1.50 is a DOS program, but many people run it under Windows. Because of InstantTrack's age and DOS heritage, there are some special considerations when you deal with files. Keplerian elements downloads can be particularly troublesome, since you're forced to use an email program or a web browser (probably the newest, fanciest program on your computer) together with this old dinosaur. This page contains some tips to help you solve the problems that can arise.
This recipe should work with most programs. You can vary this recipe in many ways, but if you follow it precisely you will probably succeed. If you don't succeed, see the section on troubleshooting below.
If you need help with step 1, try the AMSAT Keplerian Elements page and click on either one of the current bulletins.
The file name must comply with DOS limitations:
KEPSElements.txtdownload.TXTnew kepskeplerian.txtmy*filekeps.txt.txtThe directory name (if not the InstantTrack directory) must also comply with the above limitations.
Windows programs will sometimes add an extension you didn't expect. The file you think is named "KEPS" might really be named "KEPS.TXT". Even stranger, the file you think is named "KEPS.TXT" might really be named "KEPS.TXT.TXT". See below for a way to troubleshoot this problem.
Windows is often configured to hide common extensions in filenames. A file may show up as "Keps" in the Explorer even though its name is really "Keps.txt".
Some programs will save in HTML format even if you don't want them to, or make the switch to turn off this behavior very difficult to find. If you look carefully, you'll probably find a way to save a plain text file. If not, switch to another program.
If you received the elements by email, your email program may have reduced multiple spaces to a single space. This is no problem for AMSAT verbose format elements, but will destroy NASA 2-line format elements. You'll get the error message "wrong line length".
If you are able to download Keplerian elements successfully and load them into InstantTrack with no problems, but you still get erroneous predictions from InstantTrack, check the following.
1. On the main screen, look at the UTC time displayed in the upper left corner. Is it right? Now hit the "Z" key to switch to your local time. Is it right? If both are wrong the same amount, you need to set your computer's clock. If one is right and the other is wrong, or both are wrong but by different amounts, then you probably need to fix the timezone settings in InstantTrack. See the manual for details. (Note that the feature for timezones that aren't offset from UTC by an integer number of hours is broken in version 1.50.)
2. On the Manual Edit Satellite Elements screen (hit 6 A 8 from the main screen and then select a satellite), hit the "D" key to display derived values. The top derived value says "Epoch was ### days ago." Is that number reasonable? If that number is huge, then InstantTrack has misinterpreted the element set. The only known cause of this is running InstantTrack version 1.00 on an element set with an Epoch Time in year 2000 or later. It's a Y2K bug, and the fix is to upgrade to InstantTrack version 1.50. See the InstantTrack home page for upgrade details.
3. On the Edit Station Elements screen for your home station (hit 6 B 1 Enter from the main screen), check the description of your location under "Computed information...". Is it about right? If not, you need to edit the latitude and longitude on this screen to correct it. Use W after the number for west longitudes. S for south latitudes.
As shown on What is a Satellite Tracking Program, those three things (time, station location, and Keplerian elements) are all InstantTrack needs to do the computations. If you've checked these things and you're still getting bad answers, then either the Keplerian elements are bad or you've found a new bug in InstantTrack. Try another tracking program to find out which.
If you use NASA 2-line format elements published by AMSAT-NA, you will see this apparent error message in red:
DECODE 2-LINE ELSET -- checksum didn't match
This is normal. The KEPS bulletins always contain some text at the top that explains the format of the 2-line element sets. This text looks so much like a real 2-line element set that InstantTrack tries to decode it. When it doesn't decode, InstantTrack displays the above "error". Just disregard this message.
Follow this procedure to make sure that the downloaded file exists, is in the directory you think it's in, and has the name you think it has.
1. Bring up a command prompt window. This is found under the Start menu and is named either "MS-DOS Prompt" or "Command Prompt" depending on your version of Windows. You may have to look under "Accessories" to find it.
2. In the command prompt window, switch to the disk drive where you
think the file is located. If you're following the basic recipe above,
the disk drive is named "C:". To do this, type the following
(and then hit Enter):
C:
3. In the command prompt window, switch to the directory where you
think the file is located. If you are following the basic recipe above,
the directory is called "\IT". Use the "CD" command.
To do this, type the following (and then hit Enter):
CD \IT
4. Still in the command prompt window, try to look at the file. If
you are following the basic recipe above, the file is named "KEPS.TXT".
Use the "TYPE" command. To do this, type the following (and
then hit Enter):
TYPE KEPS.TXT
5. Examine the results. There are three possible outcomes:
The system cannot find the file specified.
File not found - KEPS.TXT
If you got an error message in the preceding step, you need to figure out where the file really ended up. Windows provides an easy way for you to find files.
If it didn't find any files, review your procedures. Either you didn't really download the elements to a file, or else you've searched incorrectly.
If if found lots of files, you have to play detective. Look at each file until you find the right one.
If it found just one file, now you know its true location. Is it what you expected? If not, you have two choices:
If the location is right, the name might still be wrong. Remember,
Windows will sometimes hide the extension (last part) of the filename
from you. Go back to the command prompt window and type:
DIR /P
This displays an old-fashioned directory listing with the real filenames. Look for your file, and see how the name has been changed. Again, you have two choices:
If you find that the contents of the file are in the wrong format, you have two options.
If you recognize that the file ended up in HTML (by seeing a bunch of keywords set off in angle brackets like <HTML> and <BODY>), then you can probably change your procedures to avoid the problem. Go back to the program you used to download, and look for a way to make it save as a "Text File" or in "Plain Text" format. If you can't find an option like that, try another program.
If multiple spaces in your NASA 2-line element sets were reduced to single spaces, the same fix should work (but may not).
If the file ended up in some other bogus format, please let me know. I'm not aware of any other common format problems that InstantTrack 1.50 can't handle.
If you need to convert the existing file, the simplest way is to edit the file using NOTEPAD (find it on the Start menu under Accessories) and delete everything that doesn't look right. See the Keplerian Elements Formats page if you're not sure what elements are supposed to look like. This is a very tedious procedure, so you won't want to do this every time.
Avoid the special names CON, AUX, PRN, COM1, COM2, LPT1, LPT2, NUL, etc. These names are special to DOS (and thus to Windows) and will do something you don't expect.
If the file ends up in Unicode format, you may not be able to fix it with NOTEPAD, because recent versions of NOTEPAD understand Unicode too. You can use EDIT (which you can run from the command prompt) instead of NOTEPAD. EDIT is still unaware of Unicode, and probably always will be. This problem is more likely to occur with email than on the web.
You can avoid most of the pitfalls by downloading using the command-line FTP client that's included with all versions of Windows. Here's a sample session. You typed what's in red.
D:\>c: C:\>cd it C:\IT>ftp ftp.amsat.org Connected to amsat.org. 220 ftp.AMSAT.Org FTP server (BSDI Version 7.00LS) ready. User (amsat.org:(none)): ftp 331 Guest login ok, send your email address as password. Password: 230 Guest login ok, access restrictions apply. ftp> cd /amsat/keps/current 250 CWD command successful. ftp> ascii 200 Type set to A. ftp> get nasa.all 200 PORT command successful. 150 Opening ASCII mode data connection for 'nasa.all' (7944 bytes). 226 Transfer complete. ftp: 8112 bytes received in 0.14Seconds 57.94Kbytes/sec. ftp> quit 221 Goodbye. C:\IT>
Then when you're in InstantTrack, the filename is just "NASA.ALL". This procedure should work as long as you have an Internet connection, regardless of what other too-fancy software you might have getting in the way.
You can use the compressed filename or directory name to access files that would otherwise have illegal names. For instance, to access C:\Downloaded Junk\Latest Keps.txt you could tell InstantTrack to use C:\DOWNLO~1\LATEST~1.TXT. This may occasionally be more convenient than putting the file where InstantTrack can access it.
File name conventions are partially relaxed for network files named according to UNC. For instance, you can probably access a network file named \\mississippi\downloaded\keps.txt even though some of the components of this name don't comply with DOS limitations.
If you're using InstantTrack on a plain DOS machine most of these problems don't happen. If you're using InstantTrack on a non-DOS, non-Windows machine, I assume you're probably experienced enough to figure out what to do.
If this page doesn't give you enough help to solve your problem, please write an email message to me (kb5mu@amsat.org) and explain your problem in as much detail as possible. Include the exact procedure you're using, including the name and version number of all programs used, and the exact failure you're seeing. I will try to help, and then I will update this page.
Written by Paul Williamson, KB5MU. Last updated 16 February 2002. Comments to kb5mu@amsat.org