Here are some common questions that I have been asked regarding PocketSat:
How do I upgrade PocketSat?
Registered PocketSat receive free upgrades when they become available. If you see that there's a new version out, drop me a note and ask for it. If you registered via PalmGear they will send it to you automatically.
I start PocketSat, press the 'calc' button, and nothing happens.
If nothing at all seems to happen (the little 'spinner' doesn't appear in the upper right hand corner, and you don't see any satellite names displayed) it is almost certainly the case that you have no satellite data loaded. Choose the 'Satellites...' menu item from the main form to go to the satellites form. If no satellites are listed, refer to the answer to: I've loaded an import database onto my Palm, but I don't see any satellites listed in the Satellites form. If satellites are listed, verify that at least one is selected and has a check mark beside it.
I press the 'calc' button, the thingy spins and the satellite names flash by, but nothing gets listed.
Chances are, no passes were found that meet your 'Preferences' specifications. If you're using the trial version, which will only check 5 satellites per calculation, it is a good idea to set the start and end times to be several days to a week apart. Even then, you may well not find anything. To insure that things are working, go to the preferences form and set "Show:" to "All Passes" and "Min Elev:" to 0 degrees. Now running a calculation (even for a single day) should result in some passes being displayed.
I've loaded an import database onto my Palm, but I don't see any satellites listed in the Satellites form.
Loading the import database onto your Palm is just the first step. Now you have to actually perform the 'import,' which copies the data into PocketSat's working database. From the main for, choose the "Satellites..." menu item to go to the Satellites form. From this for choose the "Import from DB..." menu item which will bring up a list of the import databases currently loaded on the PalmPilot. Select one and press 'import'. The data will be copied into PocketSat's internal satellite database. Once the data is loaded it is OK to delete the import database.
Why does PocketSat require the user to manually adjust for Daylight Savings Time?
First, doing it automatically is actually pretty difficult. Different countries (and states in the US) use different rules to determine when it should be in effect, if at all. Moreover, there are some places which use half-hour Daylight Savings offsets. If I were to make it automatic, I'd have to require the user to enter when it is in effect and what his local offset should be. The problem is that I don't think most people actually know their local rules. I certainly don't.
Another option would be to include a "DST" checkbox instead of requiring an actual timezone change. Honestly, these always confuse me, since I never can tell whether they mean "I live in a place that uses DST, so do it automatically when it's supposed to happen" or "It is now DST."
I've been hoping that Palm would get smart and implement DST into PalmOS, and it would cease being an issue. I've noticed reference to it in the latest system header files, so maybe some day...
I'm having trouble entering my location into PocketSat.
PocketSat expects for you to enter your Latitude and Longitude in degrees and minutes (a minute is 1/60th of a degree), which is the traditional way to express them. Sometimes when you look up the map coordinates for your location you will find them displayed in decimal degrees, which you must then convert to degrees and minutes.
If your position looks like: Lat 42° 15' N then you're good. Just enter it as is. If, on the other hand, it looks like: Lat 42.25 N then it's in decimal degrees and must be converted. To do the conversion, just enter the whole degrees (42) into the degree field and multiply the fractional part (.25, in this case) by 60 to get 15 minutes, which goes in the minutes field. Easy, right?
Why does PocketSat only calculate the position of satellites in Low-Earth orbits? Are you planning on adding support for higher satellites?
There are a couple of reasons for this. The original one is that PocketSat was initially designed as a naked-eye visual observing tool, and low-Earth satellites are the only ones you can see with the naked eye (as far as I know.) There didn't seem to be any point in doing the extra math required in order to compute the positions of higher ones.
As more and more radio amateurs started using PocketSat, they started asking for the ability to track higher satellites, since they don't care if you can see them or not. When I looked into the possibility, I found a couple of other, more sticky, issues. First, PocketSat is very much designed around the idea that, during a given time period, passes either happen or they don't. That is, a satellite either rises, peaks and sets, or it doesn't. The way I've organized things it just doesn't work to have satellites whose passes don't start or end during the period.
Also, the Palm is not a very powerful math engine. Since it's important that PocketSat use the "real" SGP4 orbit model, it has to do the real math. In order for it to be able to do this for a large number of satellites and finish in a reasonable amount of time, heuristics and tricks need to be used to minimize the number of calculations that get performed. One of the most important of these is the assumption that the Earth doesn't rotate much during a single orbit of a satellite. This just isn't the case for medium and high orbits.
For these and a couple of other reasons it seems to make more sense to let PocketSat remain a LEO observing tool and to perhaps write a different one to be more of a "tracking" tool, in the sense that ham radio operators are looking for. I'm planning on writing it... really. I've just been kinda busy
How can I check to see if I've set up PocketSat correctly? Well, you can run outside and see if satellites are where they're supposed to be :-) Really, though, just because a satellite is passing overhead and is illuminated doesn't necessarily mean that you'll be able to see it - sometimes they're still too dim. Another way to check is to visit www.heavens-above.com (you should probably do that anyway - it's a great site) and compare the predictions there with PocketSat. Times should agree to within a couple of seconds. If not, look at the next question:
[insert program here] and PocketSat disagree about the location of [insert satellite here.]
PocketSat really does work. Honest. And it's very accurate. If its predictions don't agree with those from another product, and you trust that the other product is set up properly, there are several possible options:
There is a really big disagreement. A satellite listed as a good pass by one of the programs isn't listed at all by the other.
Are you going to write a version of PocketSat for Windows CE?
I dunno. I hadn't planned on it, mostly just because I don't own a WinCE device, and it's more money than I want to spend on a toy that I don't have any use for. Also, the development kit was a fair bit of money.
Lately, however, I've noticed that the dev kit is available as a free add-in to Microsoft Visual Studio (which I have) and includes an emulator - in theory making it possible for me to do the whole thing for free, sorta. The only expense would be the time involved in learning the WinCE operating system and the "way things are done." Unfortunately, that's actually a pretty high price.
In other words, not "yes" but not "no"...
I'm having trouble trying to import data from a memo.
There are two major causes for this. The first and most common is that you've forgotten to include a "title" line at the top of the memo. The first line of the memo in considered to be the title and is not part if the data itself. Take a look at the example in the documentation.
The second most likely problem is that, somewhere between the original data source and the memo, all of the cutting and pasting and word wrapping has resulted in the introduction of spurious spaces or carriage returns in the data. Since TLE lines are fixed-field Fortran-style records, this is pretty much fatal. Unfortunately, it's also pretty hard to detect.