la1k / flyby Goto Github PK

Currently displays all satellites in the menu. Should only display whitelisted satellites.

Replace the current command line option parsing with getopt and provide long names for options. A review of all command line options should be conducted as part of this work.

It should be possible to specify options both as command line options and config file options. Coordinate work on this with #1.

Depends on: #47

To reduce the amount of satellites shown in multitrack, a filter that removes all passes with max elevation lower than a user-defined amount should be implemented.

Currently silently ignores entries with neither uplink nor downlink defined. Should rather display something about these being ignored.

No need to have both imperial and metric units. Could consider to have option to use either units.

Imperial units were already removed from multitrack earlier.

(Reported by VK5DG)

When you are defining transponders show what unit the input is in.

Ie. Show that the code expects a value in MHz.

Use FIELD and FORM structs from libform instead of flyby's kbEdit-function.

Flyby displays some cues that rotctld is enabled and working, but doesn't display much about rigctld. This is also related to #16. Should give more feedback.

See issue #4.

The orbit calculation algorithms have been moved into libpredict (https://github.com/la1k/libpredict). Flyby should use the library instead of its own algorithms.

Until libpredict adds support for a TLE database, predict should use its own. Even after libpredict adds support, it might be useful to have a separate flyby TLE file.

Transponder schedule was never implemented in Predict, and subsequently not in Flyby. The only indication that this was supposed to be implemented is that you always have to enter "No weekly schedule\nNo orbital schedule\n" in each transponder entry of the transponder database, and that these are read into "unsigned char dayofweek" and "int phase_start, int phase_end". The values are never used.

Some satellites have transponders that are turned on only at specific times or days. Does it make sense to try to implement this? Is it useful? How should it be displayed? How should it be used?

I've removed the physical variables for now in the branch dealing with issue #17 (though the fields are still required to be present in the files, at least for now). The complexity of the scheduling probably requires something more than the initial implementation indicated in Predict (more than just an unsigned char describing the day).

Should de-globalize the socket and VFO variables and rewrite the hamlib interface into structs and nicer functions.

See issue #4.

This might depend on features planned, but not yet implemented for milestone 2.0.0 in libpredict.

Add more filtering options to satellites displayed in EditWhitelist().

• Filename filtering (show satellites from 'weather.txt', ...)
• Filter satellites with defined transponders
• Filter on satellite number

Configuration is broken. Config defaults are not copied to /etc/flyby, config defaults are subsequently not copied to ~/.flyby/, and flyby silently exits after prompting the user for QTH coordinates (and the paths also miss a '/', so that the paths are /etc/flybyflyby.tle instead of /etc/flyby/flyby.tle).

User receives no warning if those files are missing. Master branch also has some memory violations which makes flyby segfault if flyby proceeds without tle-database (fixed in libpredict-branch). Not sure if we should just fix install rules in CMakeLists.txt for the configuration files, or if we also should add warnings in flyby and/or let user proceed without .tle- or .db-file, or whether we should just fix this for the more proper configuration fix in issue #1.

@ryeng suggested that the current main menu is exchanged by a main menu based on MultiTrack().

One solution is to apply the menu stuff in Select() to MainMenu(). The menu itself would then probably have to be something shown to the left of the satellite listing, not sure how dynamic the menu items can be, or whether we would be able to preserve the color coding.

Should it still sort the orbits based on their AOS/LOS times? Should the cursor follow the orbit as it is sorted, or should the cursor stay in one place? How should the various menu options be presented to the user? One solution is to clutter up the UI with keybinding hints, or we could display more options after the user has pressed 'enter' on one satellite.

UTC clock is present in singletrack, but not in multitrack view. Useful for time comparisons, as flyby uses UTC for all predicted times.

(Reported by VK5DG)

(gdb) bt
#0  0x00007ffff6f008f4 in fclose@@GLIBC_2.2.5 () from /usr/lib/libc.so.6
#1  0x000000000040f938 in whitelist_from_file ()
#2  0x000000000040fa72 in whitelist_from_search_paths ()
#3  0x00000000004063fb in main ()
(gdb) 

Stesps to reproduce, build 4cae199, start flyby.

TLE database is currently limited to 250 satellites. Remove this limit. (And adjust transponder database size accordingly)

• Make sure all writing to the TLE database goes through the API functions (it should, but might be some remnants left)
• Make sure access to transponder database does not assume anything about a pre-defined size
• Take in TLE database in the transponder database creation function and use corresponding number of entries
• Resize dynamically in add-function
• Ensure creation function is used for all instances of tle_db
• Ensure destroy function is used for all instances of tle_db
• Remove MAX_NUM_SATS variable

Legacy code from Predict. ~~~Uncovered weird errors in connection with #49, which probably have to do with very specific numbers of characters used in extracting lines. Symptoms are that some of the transponder entries are not properly read.~~~ Turns out the problem was elsewhere, but will still rewrite for clarity reasons since it was difficult to debug.

Settings variables are numerous (file paths, latitude/longitude convention, whether databases are loaded, ...) and all global. Making them local will clutter up the function arguments (see libpredict-branch). Collecting them in a struct should simplify matters.

Currently have to specify e.g. --rotctld-host=[HOST] in order to enable connection to rotctld (and rigctld).

Additional possibilities (in addition to current CLI options):

• Detect availability of rotctld/rigctld automatically (and add possibility for disabling entirely)
• Add configuration files
• In-program configuration

Do an assessment on whether any of the above makes this more inconvenient and cumbersome or not.

rigctld autodetection will be problematic, won't know what to choose for uplink and downlink, but might be good to rethink this a bit.

See issue #4.

This might depend on features planned, but not yet implemented for milestone 2.0.0 in libpredict.

Update manpage in docs/man/.

• Basic manpage covering all tools and command line options.
• Remove incorrect information in the manpage
• Consider whether the remaining information is useful or not, reduce to bare minimum
• Convert blogpost about flyby on http://la1k.no to markdown, update any changes since it was written
• (automate the screenshotting?)
• Reorganize README, no need to mention paths for TLEs and transponder database before the easy way to obtain these files
• Dependencies in README

Add option for adding TLEs to the correct paths through flyby-executable instead of forcing to copy manually.

#49 will give a basic implementation of transponder database fetching, but will overwrite the user's existing database by writing directly to the assumed DB path. It should rather merge, compare entries, give option to force overwriting, ensure that everything is written to the directory as defined internally in flyby, give option for trying to write to system-wide directory, etc.

This can be done by implementing extra command line options similar to flyby's --update-tle-db, to be applied to a fetched database file saved to a temporary file.

Will probably be more complex, add additional transponder database CLI utility.

• Switch from uplink etc arrays to transponder structs
• Take transponder database file(s) as input, write to database structure
• Merge with existing database, wait for user response if there is a difference for an entry
• Print differences
• Option for forcing (ignore differences)
• Option for silent mode
• Use in fetch_satnogs_db.py
• Convert scripts to .in and include in cmake process, process executable name as cmake variable
• Find better name for transponder utility

See issue #4.

Steps to reproduce

1. Start flyby
2. Enter the transponder database view, hit the e key
3. Hit the q key

Expected result

Return to the main menu

Actual result

Segfault

Tested against bb32ab9. I only set the ground station information and have not added any TLE or anything else, from a clean install.

Backtrace

#0 0x000000000040d5b9 in DisplayTransponderEntry ()
#1 0x000000000040dbb3 in EditTransponderDatabase ()
#2 0x000000000040e0ed in RunFlybyUI ()
#3 0x000000000040596a in main ()

The DIY open ground station network SatNOGS has a database module that contains transponder-information that can be found here.

The transponder database is based on user-inputs and contains uplink and downlink information in a reasonable format. It also indicates if the satellite is alive or not.

The database has an API which can be found here.

Flyby should ship with a tool similar to update-tle that fetches data from db.satnogs.org to generate a transponder database.

Use full terminal height in multitrack listing, and do dynamic resizing when LINES changes.

Very related to la1k/libpredict#49.

In the worst case, we can shuffle back the code from Predict, implement the functions outlined above and squeeze it into libpredict when we get more sense over what is convenient and not, so that we can close this issue.

Actually not an error yet, but will be.

The doppler shift obtained from libpredict has wrong sign. Flyby switches the sign around, so that the frequency displayed and used in flyby still is correct, but once la1k/libpredict#64 is solved, this will be wrong. :-)

Move from global to local scope within main(). Do this after issues #4-#10 have been resolved to reduce the amount of necessary headache.

See issue #4.

Flyby segfaults when attempting to enter single track mode (T) from the main menu when no TLEs are loaded.

From flyby.c:5200:

5200                         /* Send data to rotctld, either when it changes, or at a given interval
5201        * (as specified by the user). TODO: Implement this, currently fixed at
5202        * once per second. */

A common way to estimate the quality of a satellite pass is by the maximum elevation angle.
For a LEO satellite the path loss is the lowest when the satellite passes over zenith (90 deg), the distance between ground station and satellite typically varies between 2000 to 4000 km at 0 degree elevation and 300 to 600 km (orbit height) at 90 degree. At zenith it is also likely to be the least obstructed by vegetation and buildings.

Getting data from satellites is much easier with a "good pass", ie. high elevation angles (30-90 degrees), than with a "bad pass" (5-10 degrees).

For this reason the maximum elevation of a pass should be displayed in multitrack.

The predict network server functionality belongs in a separate predict daemon, not in the client application. This will also remove the pthread dependency.

If we end up with a system-wide TLE database (issue #1), or add support for multiple TLE files, or even now when the single TLE file becomes large and cumbersome to edit, it might be nice to be able to mark in a checklist which TLEs we want to display in MultiView() and be able to track in SingleTrack() and Predict().

E.g.

[ ] AAUSAT
[X] NOAA-15
[ ] NOAA-17

, in a separate view. Will require a new config file, however. A blacklist over TLEs not to display, where the default option is to not have the file at all, and thus show all satellites.

Can be implemented in practice by having the full list of TLE-strings available within the program, and let the array over predict_orbit_t be restricted to TLEs not contained within the blacklist.

Search functionality might be nice. Might also be nice to have the option to sort the checklist into the files they come from and deselect entire TLE-files.

Steps involved for using search field in multitrack view ('/') is different from steps involved for filtering in whitelisting (CAPITAL LETTERS). This could be confusing.

Currently still uses Predict's direct insert of doppler shift calculations.

The transponder database file (flyby.db) is horrible to edit or add new entries to. An edit utility would be nice. It probably also has a lot of secret, undocumented features.

flyby_-prefix on files are redundant. Can also move the .h- and .c-files to subdirectories in order to avoid cluttering up the root dir.

Should add automatic tests, in order to avoid later idiot mistakes in the more fundamental parts of the program.

At the very least:

• Check behavior of database functions/config functions when no database files/config files are defined
• Test correct behavior for TLE database handling functions (merge, add, overwrite)
• Test xdg basedir functions, against expected output (when defining XDG_DATA_HOME, when XDG_DATA_HOME is empty, ...)
• Test hamlib interface? Can create a socket and check for expected commands.

Should also consider whether to test some of the underlying handling functions for the UI elements that operate on the internal data structures, check corner cases and expected outcomes: filtered menu (for whitelist editing), transponder editor, search functionality in multitrack...

Correctness of the numerical satellite tracking results are already handled in libpredict.

See issue #4.

We have some secret, undocumented features which would be nice to make more intuitive from the user interface by displaying hints.

List of implemented features (scrutinized from the code in SingleTrack()):

• Key left/key right or +/- key switches the tracked satellite
• Space switches between the transponders
• Key down (or <)/key up (or >) shifts the uplink and downlink frequencies by 1 kHz steps between defined start and end frequencies
• ,/. does the same as above, but in 100 Hz steps
• d/D and u/U turns on/off downlink/uplink updates to rigctld (f turns on both)
• F/f forces a read of the downlink and uplink frequencies from rigctl (overwrites corresponding variables)
• f turns on downlink and uplink updates to rigctld
• m/M turns on/off automatic frequency reading from rigctl. Frequencies are read from rigctld, inversely rectified against doppler shift and set to canonical downlink and uplink frequencies. Similar to F above, but does this continuously.
• x reverses VFO of downlink/uplink
• Q/q/ESC escapes single track mode

Other views are either intuitive or do not have secret keys.

A common way to estimate the quality of a satellite pass is by the maximum elevation angle.
For a LEO satellite the path loss is the lowest when the satellite passes over zenith (90 deg), the distance between ground station and satellite typically varies between 2000 to 4000 km at 0 degree elevation and 300 to 600 km (orbit height) at 90 degree. At zenith it is also likely to be the least obstructed by vegetation and buildings.

It would be nice to see the maximum elevation and the angle and time at which it occurs in single track mode. It would also be nice to see when and at what angle AOS and LOS occur.

Flyby should search for config files (flyby.qth, flyby.tle and flyby.db) in a defined order and provide sensible defaults if no config file is found. Maybe following the XDG Base Directory Specification (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html) is a good idea.

It should be possible for the system administrator to provide a default for users that don't have their own config files, e.g. in /etc/flyby.qth. System satellite TLE and frequency databases would also be easier to keep up-to-date than files spread out in users' home directories.

The current approach, copying files from a known location if no config files are found, is not a good solution for providing defaults. Flyby should be able to start without any config files or templates in known locations.

I guess flyby.qth is a config file, but are flyby.tle and flyby.db data files or config files according to the XDG?

Should the TLE list be the union of all TLE files in the search paths, or should flyby use the first file found? What about the frequency database? If a union of all files is used and there's a file in /etc/flyby/, the user can't remove orbit parameters/frequencies listed in that file by having a different database in $HOME/.flyby/. Maybe $XDG_CONFIG_DIRS is a good enough solution to that problem.

Should there be an /etc/flyby.tle.d/ directory with several files? That would make it easier to organize satellites into groups (e.g., amateur.tle, weather.tle, etc.), or to add satellites during a launch.

It is very large.

When calling flyby with option --rotctld-horizon=-10 it does not start tracking the satellite at -10 degree elevation angle.