SATELLITES Plugin

[JAY-Githb]

Can a filter be added to just show satellites brighter than a specified magnitude?

I realize that in order to work for all sats, they all have to have a Standard Magnitude. Perhaps for any object where Standard Mag is unknown, just assign a default of 4 if RCS is Large, 6 if Medium, 10 if small.

Thank you.

[github-actions]

Hello @JAY-Githb! Thank you for suggesting this feature.

[alex-w]

Duplicate of #1527

[alex-w]

Do you want filter the satellites by standard magnitude? Please share better explanation for this request, because previously @axd1967 just wanted to ruined demonstration mode.

[JAY-Githb]

Filter by apparent magnitude.
If I'm looking for low altitude satellites, there are many high satellites that clutter the view. A magnitude limit of 8 or 9 would exclude high objects giving a clearer view of the sky.
To look for geosynchronous sats I would choose a much fainter mag limit.
Other times I choose which object to look for based on whether it would be visible in binoculars or telescope.
A visual magnitude filter helps to choose a the appropriate class of objects.
Does this explanation help?
Thank you for your consideration.

[JAY-Githb]

No need to filter by standard magnitude because that has no affect on actual visibility.
Only apparent visual magnitude is useful.

[gzotti]

Erm... "Filter by magnitude, I look for near objects"?
Why not "Filter by distance, I look for bright objects".

Or would "Filter by distance. I look for close objects" be more appropriate?

[github-actions]

Hello @JAY-Githb! Thank you for suggesting this feature.

[github-actions]

This issue already exists.

[alex-w]

Or would "Filter by distance. I look for close objects" be more appropriate?

apparent magnitude is dependent by geometric size and distance of the satellite, so, not all closes satellites are bright.

[alex-w]

Filter by apparent magnitude.

Formally in realistic mode you have hiding invisible satellites already. Probably you use mode with markers, like @axd1967. Is it correct?

If I'm looking for low altitude satellites, there are many high satellites that clutter the view. A magnitude limit of 8 or 9 would exclude high objects giving a clearer view of the sky.

Do you understand that we should hide orbits of all satellites for filtered mode? And not all satellites have standard magnitude or RCS data - all of them will be invisible too.

A visual magnitude filter helps to choose a the appropriate class of objects.

Filtering satellites by class of objects (LEO, MEO, HEO, etc.) already exist.

[JAY-Githb]

Georg asked "Why not "Filter by distance,"
Great Idea. That is definitely much better.
Being able to show just those objects within a minimum and maximum range would be more helpful than sorting by magnitude.

Thanks for the suggestion.

[JAY-Githb]

Alex, I agree with you and Georg that filter by magnitude is not the best way to go.
Being able to set a minimum and maximum Range is much better.

[gzotti]

Now there is a question what "range" means, or what should be filtered: current distance from observer, or current geocentric distance (or altitude above ellipsoid), or some quantity from the TLE, like semimajor axis. (Think Molniya orbits...) I am not in this field, so I don't know what's typically wanted. In addition, a magnitude cutoff filter should be relatively simple. (famous last words ;-) For this to work though, we need meaningful mandatory defaults for RCS. I don't know (not my code), is "standard magnitude" something that derives from e.g. RCS, solar angle and distance, or another independent factor? Is the term "standard magnitude" something used in the satellite observer community, or our own "default" magnitude that we assume without proper data?

[axd1967]

RCS is used (in case it is present) if there is no std mag available:

stellarium/plugins/Satellites/src/Satellite.cpp

Lines 701 to 714 in dd006bc

	else if (RCS>0.) // OK, artificial satellite has RCS value and no standard magnitude
	{
	// Let's try calculate approx. magnitude from RCS value (see DOI: 10.1117/12.2014623)
	double albedo = 0.2;
	if (0.436<=phaseAngle && phaseAngle<1.745)
	albedo = (((((3.1765*phaseAngle - 22.0968)*phaseAngle + 62.182)*phaseAngle - 90.0993)*phaseAngle + 70.3031)*phaseAngle - 27.9227)*phaseAngle + 4.7373;
	else if (1.745<=phaseAngle && phaseAngle<=2.618)
	albedo = ((0.510905*phaseAngle - 2.72607)*phaseAngle + 4.96646)*phaseAngle - 3.02085;
	double rm = range*1000.;
	double fdiff = (std::sin(phaseAngle) + (M_PI - phaseAngle)*std::cos(phaseAngle))*(2.*albedo*RCS)/(3.* M_PI * M_PI * rm * rm);
	vmag = static_cast<float>(-26.74 - 2.5*std::log10(fdiff));
	}

According to #2060 (comment), the user's intention becomes a bit more clear: to study a specific class of satellites, so a mag filter will indeed not help for various reasons (ironically, range is one of them). In #1527 the intention is to help a visual observer filter away satellites that cannot be seen (because below a magnitude level, e.g. 6, or 9 if using binoculars, or some other value if using a telescope etc). The original question made this a duplicate of #1527.

If I understand correctly, the idea is therefore to introduce an altitude band filter, not a magnitude filter; the user wants to exclude satellites below a threshold AND above another threshold (correct, @JAY-Githb ?). The value to filter upon is NOT the range, but the actual altitude (as a minimum, simple case).

This needs to be closely coordinated and thought over taking the already existing sat filters into account (as stated in #2060 (comment)), because there is an overlap in intentions; at first sight, those filters should be the solution @JAY-Githb ; otherwise, it should be explained why they are not useful.

But it feels useful to introduce an altitude band filter, this feels like a very flexible and clean way for a user to filter at will; this could also be a poor man's workaround for #1527 .

[JAY-Githb]

Hello Georg.
I say 'range' the same way it is currently used in Stellarium: current distance from observer.
If the filter is range, then a magnitude filter would not be needed. And since range is already calculated, no other calculations need to be made. That would seem to be the simplest solution.

"standard magnitude" is used in the satellite observer community to calculate predicted visual magnitude.
There are a couple of definitions. Generally, it is the magnitude of a satellite at 1000 km distance.
Since I use the Quicksat prediction program by Mike McCants, I use his 'Intrinsic magnitude'.
I don't know which definition Stellarium uses.
RCS is not used in defining standard magnitude, but is used when other data is not available.
A little history: Originally, standard magnitude was based on size. That is good for payloads and rockets where size is known. It can't be used to predict magnitude for all the "debris" objects. In the 1990s, I became aware of RCS values. RCS can be used to calculate magnitude when size is not available as with debris. I campaigned for NASA to include RCS in the Satellite Situation Report which they soon did. Mike then started using them in his listings.

[gzotti]

Thanks for the history lesson! Yes, filtering on current range (distance) should then be easiest, with min/max settings.

[JAY-Githb]

axd, You are correct that 'the user wants to exclude satellites below a threshold AND above another threshold'.
But it IS the Range, Not the actual altitude that is the factor. RANGE depends on an observer's location so that is more important than a fixed altitude.

I have hundreds of high eccentricity objects on my observing list. I will look for them when they are relatively low but that is just a small part of their orbit. Most of the time they are very high and just clutter up the screen. Ability to not show objects beyond a chosen distance would do a lot to help clear the screen so I could concentrate on current targets.

Jay

[JAY-Githb]

Georg, yes, I agree with you.

[JAY-Githb]

In the discussion between Range versus Altitude, I would say to use as a filter whichever is easiest to implement.
There generally is not that great a difference.

[A-j-K]

Is anyone working or intending to work on this issue soon?

I am asking because I'm intending to open a new issue/PR to implement solutions for the consumption of the new various formats for orbit elements beyond the TLE format as described here:-

https://celestrak.com/NORAD/documentation/gp-data-formats.php

[gzotti]

I have no time for it these weeks. Also, I think these are different issues, so it's the right thing to have another issue/PR about reading the newer file format. (But I read Celestrak will continue delivering the TLE format, so I feel it's not urgent. But yes, please go ahead.)

[A-j-K]

I have no time for it these weeks. Also, I think these are different issues, so it's the right thing to have another issue/PR about reading the newer file format. (But I read Celestrak will continue delivering the TLE format, so I feel it's not urgent. But yes, please go ahead.)

Understood. I will do it in a separate PR. I just wanted folks to note that the current TLE does not provide the RCS value. But the newer XML and JSON versions (from Space Track, ST) do.

Additionally, ST will provide an extended TLE format using "Alpha-5" and I expect to include this in my PR. Legacy classes however will not, restricting "old code" to the legacy class sets. I'd rather be ahead of the curve and Stellarium ready rather than play catch-up.

From the Space Track website FAQ:-

Alpha-5 is a stopgap object numbering schema from the United States Space Force that increases the satellite catalog’s capacity to display up to 339,999 objects in the GP/GP_History API classes using legacy fixed-width Two and Three Line Element Set (TLE/3LE) formats.

Replacing the 1st digit of the 5-digit object number with an alphanumeric character makes it possible to represent 240,000 more numbers. Objects less than 100,000 are unaffected by Alpha-5, as are users who download elsets from the GP and GP_History API classes in other formats like XML, JSON, KVN, and CSV. In order to preserve legacy operations that depend on 5-digit integers, our legacy API Classes tle, tle_latest, and tle_publish will not change to Alpha-5.

Only capital letters and numbers are used in Alpha-5. The letters “I” and “O” are omitted to avoid confusion with the numbers “1” and “0”.

[rkinnett]

I would love to see a filter for estimated visual magnitude! I use those estimates extensively for selecting targets for visual tracking.

[JAY-Githb]

To predict apparent magnitude you have to have a standard mag. I am working on that but as of now there is no list for all objects. The closest to that was RCS which I had included in Sat. Situation Report. Unfortunately, they no longer supply that info. However, if you want a list of the brightest satellites, get VISUAL.TXT at Celstrak.com. I've been compiling that list for 25 years. They are the best targets for visual tracking.

[rkinnett]

My apologies, perhaps I should not have requested visual magnitude specifically. The plugin lists “Approx. magnitude” for many but not all satellites, and I see that these values change dynamically. I have found these estimates to be good indicators of whether or not I can find a particular satellite. Can a minimum filter be designed around those estimates?

Thanks for the tip regarding VISUAL.txt on Celestrak, and thank you for maintaining that!

Heavens-above also produces daily lists of 100ish brightest satellites for a given location. I use that in conjunction with Stellarium but still sometimes find it difficult to navigate with so many markers.

[JAY-Githb]

You'll only get Approx Mag for those objects that have a Standard Mag listed. For those that don't have one, use 5 for objects with Large RCS, 7 for Med. You won't see sats with Small RCS but use 10.
Eventually I'll make a more accurate list.

A list of Quicksat Intrinsic Magnitudes is hosted by Mike McCants. See his web site. You can adapt them for Stellariuim.

[JAY-Githb]

The list on HA is very incomplete. It won't predict if it doesn't have a Standard Mag. I had provided some, but not now.
HA is not very accurate but can be a rough guide.

[github-actions]

Hello @JAY-Githb! Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[alex-w]

@rkinnett, please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[JAY-Githb]

Hello. Whatever you did seems to have fixed the problem. I tried the same predictions on some of those objects from earlier and they worked this time! The only ones that did not work are the last bath of Starlinks that I got from Celestrak. Since those are replaced in a few days with TLE from Spactrack, I'm not concerned about them. Stellarium is working so much better now. Thank you very much for the quick fix! Jay Respler 609-662-7438 ***@***.*** Monroe Township, New Jersey

…

From: "Alexander V. Wolf" ***@***.***> To: "Stellarium/stellarium" ***@***.***> Cc: "JAY RESPLER" ***@***.***>, "Mention" ***@***.***> Sent: Monday, June 20, 2022 3:29:33 PM Subject: Re: [Stellarium/stellarium] SATELLITES Plugin (Issue #2060) [ https://github.com/rkinnett | @rkinnett ] , please check the fresh version (development snapshot) of Stellarium: [ https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot | https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot ] — Reply to this email directly, [ #2060 (comment) | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AODP7UNZBNEEHAXRSXGDE63VQDBB3ANCNFSM5IXWAQXQ | unsubscribe ] . You are receiving this because you were mentioned. Message ID: <Stellarium/stellarium/issues/2060/1160778814 @ github . com>

[rkinnett]

Range filtering appears to work correctly. I still would prefer to see a filter for approximate magnitude as was originally suggested, but this range filter should help.

I really like the umbra/penumbra visualization, although I found the checkbox next to "Show umbra at distance" to be awkward because as far as I can tell, this is a required input for the visualization. Unchecking disables the visualization, making the checkbox redundant with the Show umbra/penumbra checkboxes. Perhaps the umbra distance input could be moved to the same line as the Show umbra checkbox (and color input)?

Thanks

[alex-w]

I really like the umbra/penumbra visualization, although I found the checkbox next to "Show umbra at distance" to be awkward because as far as I can tell, this is a required input for the visualization. Unchecking disables the visualization, making the checkbox redundant with the Show umbra/penumbra checkboxes. Perhaps the umbra distance input could be moved to the same line as the Show umbra checkbox (and color input)?

No. Just try enable umbra visualization and select any satellite ;)

P.S. Show umbra at distance will show umbra at fixed distance and it will ignore altitude of satellite

[JAY-Githb]

rkinnett,
I may have a suggestion.
What is the reason for having a magnitude filter?

Jay

[rkinnett]

What is the reason for having a magnitude filter?

I'm using Stellarium to select satellites for optical tracking (see demo here). I have found the existing "approximate magnitude" field which is shown in the target information display for many (but not all) satellites to be a good predictor of whether I can detect a satellite with a wide field guide scope. Since that "approximate magnitude" field already exists (whether or not it's technically accurate), I hoped it might be easy to wrap a filter on that specific field without needing to derive new/better calculations.

That said, just last night I used the new satellites plugin features while tracking brighter LEO satellites and found the features (especially umbra display and coloring by visibility) highly useful!

As an aside, now I just need help with wishlist issue 2361 to be able to select a satellite and send the NORAD ID or TLE over to my satellite tracking application so i don't have to fat-finger satellite IDs individually. Give me an inch and I'll ask for a mile :)

[github-actions]

Hello @JAY-Githb! Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest

[JAY-Githb]

I installed it.
Works great! All the new features are wonderful.
All your efforts are really appreciated.
THANK YOU.

[JAY-Githb]

RKINNETT, I maintain a list of TLEs for the brightest satellites. You can find them in VISUAL in the Sources tab in the Config window. VISUAL is also in the original location at Celestrak.com. While there are other sats that can occasionally get bright, using the objects in VISUAL should give you reliably good results. You really wouldn't need a mag filter then.
Good luck with your tracking.

Jay Respler