GPredict should not stop tracking when another module is selected
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
Research direction
The payload names no source files, so begin by finding the rotator control window and the code that handles module selection in the GPredict C sources. Reproduce it by starting rotator tracking in one module, switching to another, and checking whether tracking freezes. Done means tracking continues after a module switch, verified with a rotator or a simulated one.
Written by the indexing model from the issue text.
Description
I was using GPredict to control my rotator, where I have several modules containing different categories of satellites I often track.
FengYun-3B was set to be tracked in GPredict's rotator control window, opened from my "L-Band" module.
In the meantime, I was waiting for another satellite, FengYun-3E, to come around. So I checked in my "X-Band" module, realized I was a bit late and rushed outside, forgetting to switch back to the "L-Band" module.
When I came back, I realized GPredict's rotator control was frozen and did not track anything, I switched back to the other module and it carried along as it should.
Shouldn't the expected behavior be for GPredict to carry on tracking even when another module is selected if a rotator is being controlled?
- 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 3/5 1-2 days Newbie friendliness 55/100
Similar issues
-
v9.6.0: CMake incorrectly enforces presence of libevdevPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
[Bug] Unhandled ValueError terminates watchdog thread when GISRC value contains multiple colonsOpenbug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
bug Component component: net
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
RT-Thread/rt-thread#11913 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
contiki-ng/contiki-ng#3289 ·
Maintainers usually reply within 3 days
-
area:docs help wanted type:enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day