Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Earth shadow at sat altitude issues #2510

Closed
axd1967 opened this issue Jul 7, 2022 · 11 comments
Closed

Earth shadow at sat altitude issues #2510

axd1967 opened this issue Jul 7, 2022 · 11 comments
Assignees
Labels
importance: medium A bit annoying, minor miscalculation, but no crash
Milestone

Comments

@axd1967
Copy link
Contributor

axd1967 commented Jul 7, 2022

Expected Behaviour

See #1246 and #2360

Actual Behaviour

Umbra should start where satellites become reported as "not sunlit".

image

image

Also, "Show umbra at distance" (which makes one wonder whether distance to the observer is intended) should probably read "Show umbra at altitude".

Also, it is odd that the umbra sticks above the horizon when the Sun is visible (or e.g. rising/setting). The umbra should be visible above the horizon during the night only, and should touch the horizon at sunrise/sunset (notwithstanding refraction issues).

image

image

It could be (but I haven't checked it) that the umbra should always be near/touch the ASP at any moment.

For geo sats the feature seems to work:
image

The CU locus seems to converge to the Earth at Moon umbra, which is as expected.

image

Steps to reproduce

System

  • Stellarium version: <Name of downloaded installable file?> 9275de9
    Operating System: Kubuntu 20.04
    KDE Plasma Version: 5.18.8
    KDE Frameworks Version: 5.68.0
    Qt Version: 5.12.8
    Kernel Version: 5.4.0-120-generic
    OS Type: 64-bit
    Processors: 8 × Intel® Core™ i7-10510U CPU @ 1.80GHz
    Memory: 15.3 GiB of RAM

Logfile

If possible, attach the logfile log.txt from your user data directory. Look into the Guide for its location.

@alex-w
Copy link
Member

alex-w commented Jul 15, 2022

Please share information about used projection

@axd1967
Copy link
Contributor Author

axd1967 commented Jul 16, 2022

Projection is stereographic, but that shouldn't matter? It looks like the drawing logic does take projection into account: e.g. fisheye gives this:

image

The image shows the ISS about to enter the Earth shadow (red, marked "3") in a few seconds. That is where the Earth shadow should start. According to the current implementation, the ISS should enter the Earth shadow at "2", which clearly conflicts with the calculations of the satellite tool.

@alex-w
Copy link
Member

alex-w commented Jul 16, 2022

Please remember about the trigonometry and projections (or sines/cosines in triangles)...

@Atque
Copy link
Contributor

Atque commented Jul 18, 2022

@alex-w Wouldn't the shadow markings fit anyway?

@alex-w
Copy link
Member

alex-w commented Jul 18, 2022

@alex-w Wouldn't the shadow markings fit anyway?

See the placement of satellite at points A and B on the drawing:
IMG_2694_1

We render the umbra's circle at altitude H and we do not compute projection the placement of satellite to axis of shadow cone.

@gzotti
Copy link
Member

gzotti commented Jul 18, 2022

I started investigating this yesterday. The circle should be drawn not at distance "earth_radius+H" but at "(earth_radius+H)*cos(earth_radius+H, antisolar_direction)" where "earth_radius+H" is of course the (geocentric) satellite position.

@Atque
Copy link
Contributor

Atque commented Jul 18, 2022

I don't see the point in showing the shadow, if it does not reflect the border between visible and invisible.

@gzotti
Copy link
Member

gzotti commented Jul 18, 2022

In the drawing, when the satellite is at B, the shadow circle likewise must go through B. This can be achieved with the above change.

@gzotti gzotti added this to the 0.22.3 milestone Jul 18, 2022
@gzotti gzotti added the importance: medium A bit annoying, minor miscalculation, but no crash label Jul 18, 2022
@gzotti gzotti modified the milestones: 1.0, 1.1 Sep 25, 2022
@alex-w alex-w modified the milestones: 1.1, 1.2 Oct 17, 2022
@alex-w alex-w modified the milestones: 1.2, 23.1 Dec 24, 2022
@gzotti gzotti self-assigned this Dec 27, 2022
@gzotti gzotti closed this as completed in 647b3f2 Dec 27, 2022
@github-actions
Copy link

Hello @axd1967!

The bug or issue has been fixed! You may test it via building Stellarium from source code or wait the weekly development snapshot...

@alex-w alex-w added state: published The fix has been published for testing in weekly binary package and removed state: fixed labels Mar 13, 2023
@github-actions
Copy link

Hello @axd1967!

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

@alex-w alex-w removed the state: published The fix has been published for testing in weekly binary package label Mar 27, 2023
@github-actions
Copy link

Hello @axd1967!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
importance: medium A bit annoying, minor miscalculation, but no crash
Development

No branches or pull requests

4 participants