Is there a way to visualize a custom TLE on Celestrak or any other online or installable software?
For example, I would find it interesting to visualize the latest TLE for SpaceX Transporter 5 to see if/when it is overhead so I might be able to see it.
I tried to find an option to add a custom TLE to Celetrak but I was only able to visualize orbits from Celestrak’s own database.
Use Orbitron or GPredict and load your own preliminary tle
Both have an option for realtime and simulation and can also calculate predictions.
There is also old no longer developed web based tool called retroTrack
Is that what you are looking for?
Hey,
Recently I wrote some Python scripts to do this for GNSS (“GPS”) systems, pulling TLEs from Celestrak. It can read any TLE, just change the URL. One set of scripts uses Cesium. Cesium is in-browser, but a proprietary web backend. I did another script that converts TLEs for use in Celestia. Celestia is a standalone application. It has much better visualization than Cesium.
With Cesium:
With Celestia:
If you want to view the TLE from the ground (e.g. lat/lon on Earth), you can load TLEs into Stellarium directly.
Re-reading that, I think Stellarium is very good for this too. It has a whole Satellite plugin system built into it, that allows custom TLE sources, along with Celestrak.
For example, with Starlink:
Very nice. Thank you!
I see this could be useful too:
Astrosat: forecasting satellite transits for optical astronomical observations
I was able to build this on Debian Bookworm (testing/12) with slightly different instructions. Quick & dirty Debian build dependencies:
apt install git make dos2unix sextractor wcslib-dev libgsl-dev \
gfortran libpng-dev libx11-dev libjpeg-dev libexif-dev \
giza-dev libgiza0 libpgplot0 unzip
There is no pgplot5 in Debian, but giza is a drop-in replacement. I added all giza-dev libgiza0 libpgplot0, which may be more than needed, but it worked.
It wouldn’t download the catalog.tle without me creating an account on https://space-track.org , though it “should” work without an account.
I added thusly to ~/.bashrc:
export ST_COSPAR=9990
export ST_DATADIR=$HOME/devel/cbassa/sattools
export ST_TLEDIR=$HOME/devel/cbassa/TLE
export ST_OBSDIR=$HOME/devel/cbassa/satobs
export ST_LOGIN="identity=myesnail@foobar.com&password=passwurd"
Add this file (not sure where to get complete sites.txt, any halp?). Order appears to be COSPAR (9990 if you don’t have your own number), two-letter name abbreviation, then lat/long/alt, then name.
echo "9990 JM 40.568912 -105.225852 1843 Jeff Moe" > $ST_DATADIR/data/sites.txt
Then just:
tleupdate
skymap
Voila! Not so bad.
Interesting! I have Stvid running on a Raspberry Pi, and it is using SATTOOLS (satid) for identifying satellites in optical observations. I didn’t have much success with giza, but also didn’t try it hard enough. Instead I have build pgplot5 from the sources and had lots of challenges with dependencies. I needed an older version of libpng, for instance. I have tried to reconstruct and documented what I have done to get sattools and stvid running on a Raspberry Pi:
Next time, I will keep your post in mind and try again, it looks a lot easier.
And the 2 characters in sites.txt is used as an abbreviation for your name. Just write JM. 
The sattools docs specifies an older version of qfits, version 5.2.0, which is what I used in my build. There have been many qfits releases since then: 5.3.0, 5.3.1, 5.4.0, 6.0.0, 6.1.0, and 6.2.0.
I was able to build all the above qfits versions in Debian Bookworm ok. Starting with version 6.0.0 it looks like it has gone from a permissive license to the GPLv2. All of the file paths and many filenames changed. The sed command in the sattools build docs should be updated to this, if building with version 6+. Though I’m a bit skeptical why this is needed in any version, it is in the sattools docs:
sed -i -e "s/swapfd = open(fname, O_RDWR | O_CREAT);/swapfd = open(fname, O_RDWR | O_CREAT, 0644);/g" src/qfits_memory.c
I believe giza is installed as a dependency of wcslib, and hence conflicts with pgplot5. On Ubuntu systems it usually is sufficient to uninstall giza after installing wcslib and then install pgplot5. I have not tried building all the software on a Raspberry Pi yet.
As for qfits; none of the newer versions have been tested, but if there are no API changes then they may just work. The 0644 addition in the file opening was added a while back to deal with permission issues; I have also not tested if this addition is still required.
I built sattools OK on Debian stable (11/Bullseye) with qfits versions 5.2.0, 5.3.0, 5.3.1, and 5.4.0. It appeared to work fine, but I didn’t do extensive testing. See screenshot with build of sattools running skymap built with qfits 5.4.0.
At qfits version 6.0.0 lots has changed including the maintainer. sattools fails to build with this. The last qfits release dates from 2007.
I also created a git repo of qfits with it’s history, since ftp is…old…
You’re screenshot looks different then I am used to. Do you get the grid drawn? For comparison this is how mine looks using PGPLOT5:
Quite possible it is missing bits with giza. Can you perhaps give me the exact command you ran and test files, if any, and I’ll test against that. Thanks!
Yes, it is giza that gives you that plot. Replace it with pgplot5 and rebuild.
Thanks for checking the later qfits releases and good to know they’re no longer compatible.
Thanks for the info about the build. I’m finally getting why this is happening in Debian. From pgplot home page:
PGPLOT is not public-domain software. However, it is freely available for non-commercial use. The source code and documentation are copyrighted by California Institute of Technology, and may not be redistributed or placed on public Web servers without permission.
I do see there was a sattools roadmap about python ports…
Yes indeed. The roadmap details (detailed) a plan to move over the tools specific to video/photographic observations to the stvid and stphot codebases, and some of that has indeed happened. This would in the end remove the dependency on qfits in sattools and pgplot in stvid and stphot. Work is progressing slowly though.
I wrote to the PGPLOT author requesting a modern libre license. A lot of these applications are older than “open source”. Same for SPICE/NAIF.
I got this back from NASA about SPICE:
Just last year NASA reviewed SPICE toolkit licensing in the process of moving PDS software to open source, and specifically exempted it from key open source provisions:
JPL-PDS Open Source Software Policy — NASA PDS Software B14.0 documentation
I hope this answers your questions.
That page states, in sum, that JPL software should be libre, except SPICE:
Exemptions
Exemption from Apache 2.0 license or other license for the SPICE Toolkit.
Rationale: The SPICE Toolkit source code is provided as open source via their website [1] with an open source license that limits redistribution [2]. The license was already agreed upon due to concerns over the security, backwards-compatibility, and quality of the software. This exemption will be reviewed at the next major release of the software.
Exemption from Open Development and GitHub requirement for the SPICE Toolkit.
Rationale: The SPICE Toolkit source code is provided as open source via their website [1]. The previously agreed upon open source license [2] limits open development and redistribution, and it is cost prohibitive to migrate to an open development framework and GitHub. This exemption will be reviewed at the next major release of the software.
[1] https://naif.jpl.nasa.gov/naif/toolkit.html
[2] Rules
