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

IO-117 (greencube) 2nd next pass is not listed #128

Open
kconkas opened this issue Mar 9, 2024 · 2 comments
Open

IO-117 (greencube) 2nd next pass is not listed #128

kconkas opened this issue Mar 9, 2024 · 2 comments

Comments

@kconkas
Copy link

kconkas commented Mar 9, 2024

I noticed that, when there is a Greencube (IO-117) pass in progress, its next pass isn't listed in Look4Sat. Hitting the refresh button while the pass is ongoing doesn't help. Once the pass is over, hitting the refresh button brings the next pass to the list. I am certain about the next pass' existence because several other prediction tools, such as Gpredict or Amsat.org online prediction tool, whose predictions usually agree with those of Look4Sat,
all list them. LEO hamradio satellites don't seem to be affected by this issue.

@kconkas
Copy link
Author

kconkas commented Mar 9, 2024

Update: it isn't just the next pass while one is visible. It appears that the 2nd next pass is affected.

@kconkas kconkas changed the title IO-117 (greencube) next pass not listed when current pass is in progress IO-117 (greencube) 2nd next pass is not listed Mar 9, 2024
@rt-bishop
Copy link
Owner

Hey @kconkas! Sorry for such a late reply. There was a data related issue #126 that was resolved in the latest app version v3.1.4. If you still observe the same issue, I'd suggest to play with the passes filter dialog in the bottom left of the passes page.

The precision of passes calculation is +/- 5 sec and that slightly affects all the other pass data like the max elevation for example. It is possible that it just goes below and above your set filter and dissappears from the list. Maybe one day I'll go through the pass calculation process and set it to use monotonic time, that should improve the precision and fix this once and for all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants