Discrepancy between current (next) pass and the actual current pass
@deshadspace is already working on this.
Since Feb 1, 2026.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 30/100
Research direction
The payload names no source files, so begin by finding where the upcoming-passes list computes the next AOS/LOS and where the polar view selects its pass, then compare how each applies the minimum elevation. Reproduce it with a satellite and ground station where the first pass stays below the minimum elevation. Done when both views show the same pass, and the maintainer has confirmed which behaviour is intended.
Written by the indexing model from the issue text.
Description
Hello!
I've noticed that there's a discrepancy between what the "current" or "next" pass shows with what actually is shown on the polar view.
If you look at the screenshot, these are 2 different passes although it should be the same.
I think it might be somehow connected to the AOS/LOS and minimum elevation. I think that the next AOS/LOS ignores the minimum elevation and the pass is shown in the upcoming passes but the actual pass on polar view used for that pass is the next pass (first pass that fulfills the minimum elevation).
I've checked it both on version 2.3 and the 2.4 version form Homebrew.
- Dominant language
- C
- Stars
- 1.2k
- Forks
- 305
- Avg merge
- 8h 48m
- Merged PRs (30d)
- 3
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from csete/gpredict
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 Under an hour Newbie friendliness 60/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 78/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
micropython/micropython#19786 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
vercel-labs/zerolang#442 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
mewencode: base256[] and base128[] are indexed out of bounds by a non-ASCII octetPossibly taken @kazu-yamamoto claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
kazu-yamamoto/Mew#276 ·
Maintainers usually reply within 1 day