After our initial posts about flyby and libpredict back in February-March 2017, we got some extra impetus for implementing new features and fixing up both flyby and libpredict. This resulted in the release of libpredict 2.0 during December last year, which has been closely interwoven with development of flyby.
Flyby (https://github.com/la1k/flyby) and libpredict (https://github.com/la1k/libpredict) represent a fork of the satellite prediction program Predict (with patches from predict-g1yyh), but where all satellite models and calculations have been wrapped in an API and split into a separate C library as libpredict. Flyby is an ncurses user interface for satellite tracking, including rotor and rig control, which uses libpredict to do the necessary calculations for predicting the satellite tracks.
The initial post from February 2017 roughly sums up the changes we’ve done to flyby after forking it from Predict. Since then, we’ve done further changes.
TLE handling changes:
- The size limit on the TLE database has been removed. As a left-over from Predict, we had a fixed size limit on the TLE database. This can now be arbitrarily large. This is not a very huge change from a user’s perspective, but going from a very limited, hard-coded size with direct access, to arbitrary-size TLE databases with a more abstract access interface was a long step.
- While it still does not a very convenient or intuitive interface (improvements planned), we’ve added more advanced filtering options to the satellite enable/disable menu. It is now possible to filter based on not only the satellite name, but also the filename of the TLE file, the satellite category number and whether the satellite has a transponder.
Transponder handling changes:
- Minor interface changes to the transponder editor: The choosable satellites are reduced to the actual enabled TLEs, and we display the expected unit of the transponder frequencies.
- We also added a utility for obtaining transponder information from the SatNOGS database, as an alternative to inputting transponder entries manually.
Documentation updates:
- We’ve created an extensive usage guide based on an earlier blog post.
- The manpage now actually describes flyby, and not Predict :-).
- We’ve revised the CLI options, removed unecessary features, added new ones and renamed and simplified the names and the arguments. We’ve added the possibility of adding new TLE files to flyby’s configuration through the flag –add-tle-file, so that it is not strictly necessary to remember to add it to the correct path (.local/share/flyby/tles/). Connections to rotctld and rigctld are now done using HOST:PORT instead of separate flags for host and port.
Changes to the singletrack view:
- Behind the scenes, the code has been slightly refactored and split in order to cope with some clutter.
- Some parts of the interface has also been changed and fixed, to cope with artifacts and make room for more properties.
- We’ve added pass quality data like max elevation and more information on AOS/LOS, and added a new shortcut for turning the rotor towards AOS in preparation for passes.
- The bottom of the screen now also contains a couple of keyhints, which also leads to a more detailed keybinding list in a separate help screen.
Changes to the multitrack view:
- We now resize the multitrack listing dynamically to fit the size of the terminal.
- We’ve re-arranged the property display and added max elevation to the listing.
- We’ve added the possibility for filtering passes based on the max elevation, in order to be able to ignore low-quality passes. At the same time, it is also now possible to sort the listing based on the max elevation regardless of the time until AOS.
- A help screen has been added to the multitrack listing for better overview over the color coding and key hints.
- As a remnant from Predict, the listing was previously sorted almost every update using a home-grown bubble sort algorithm. This has been replaced by GNU’s quicksort algorithm, and we sort only when necessary. Weird CPU-usage and erratic update timesteps have been reduced.
Hamlib interface changes:
- Flyby is made to not allow for uplink and downlink control against the same rigctld instance or rigctld VFO.
- We’ve had some freezes in the hamlib interface functions which are now fixed.
- A status screen for displaying information about hamlib connections has been added.
Other changes:
- Automatic tests have been added for some parts of the core functionality.
- Addition of XDG directories has been made more robust, and made to recursively add all new folders if necessary.
- We now use libpredict’s PKGCONFIG information for locating libpredict.
- Instead of having to input the coordinates, it is now possible to input the maidenhead grid locator.
- We’ve added a basic UI for tracking the sun and moon using rotctld.
This is in preparation for ARK’s 1-10 GHz project, and we anticipate the addition of other sources like Cassiopeia, Jupiter and Venus, which are interesting for calibration purposes.
Since libpredict 2.0 has been released, the next step will be to prepare for the release of flyby 1.0. After that, it is very likely that the 1-10 GHz project will drive the development of other features in flyby, especially for enabling higher accuracy tracking. We’re also planning to do improvements to the satellite selection subscreen. The latest development version of flyby can be obtained from https://github.com/la1k/flyby.
Thanks to bostrt, VK5DG, LB6RH and LA3WUA for reporting issues and submitting feature requests and fixes! Flyby probably wouldn’t have gotten much further without someone actually testing the software and suggesting improvements.
Wondering if you ever noticed while using predict before re-engineering it as flyby if you noticed that the end of satellite passes were different from other tracking programs?
Haven’t tried flyby yet but going to give it a try to see if the end of passes are better or not.
I noticed the difference in end pass times back when predict first came out but it did what I needed it to do at the time. Now that I am trying to use predict to do pass predictions for NOAA Polar Orbital Satellites, I have noticed that the scripts end recording passes early and I don’t get as much data as I should.
Here’s the link for the site that I got the scripts from:
https://www.instructables.com/id/Raspberry-Pi-NOAA-Weather-Satellite-Receiver/
Jim, N8NZB, (the one who did the actual scripts), has also noticed that predict makes pass times that end too early.
Hi! Thanks for the comment.
Seems that the schedule_satellite.sh script uses Predict’s functionality for printing “[P]: Predict Satellite Passes” within the UI directly to standard output. The output looks like this: https://pastebin.com/xtSEMGBc . The script picks out the first and last line of this output to determine the start and end of the pass.
The output here was probably mostly optimized for displaying properties throughout a pass concisely and nicely to a human, and not for accuracy or for accurate determination of pass start and end. Predict uses its FindAOS()-function to estimate AOS and determine the start of the pass, which should be accurate-ish. Then it loops through the pass using a weird step function until int(elevation) is zero, in order to be able to display “0” as the elevation angle nicely at the end. If it is negative, Predict uses FindLOS() to fine-tune.
This means that in the worst case, the pass will end at approximately 1 degree elevation instead of when the satellite disappears over the horizon (int(0.999999) -> 0). How much earlier do the passes end in your experience, and does this 1 degree elevation deviation explain it?
Other applications would probably just display AOS and LOS directly when displaying pass information, instead of looping through it in the way Predict does for display. Predict also has (more accurate?) LOS and AOS times available, but not as easily accessible from outside as the pass prediction table.
Flyby does more or less the same thing as Predict here, and libpredict uses the same base algorithms for finding AOS and LOS. Would expect Flyby to behave similarly, but not yield exactly the same results as Predict in the pass printing functionality.
Aside from the int(elevation) thing leading to at worst 1 degree offset, the AOS and LOS estimating functions are also not necessarily very accurate, and uses weird step functions to step through passes and fine-tune the times. The accuracy varies a bit, and it can behave a bit weirdly for some passes. I haven’t yet checked the accuracy systematically (or against what other satellite applications do), but this might be an idea for a future blog post.