Zenith Satellite Rotator Tracking
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 22/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- c
- Área
- desktop-dev
Línea de trabajo
The payload names no source files. Start from the rotator tracking path that sends azimuth and elevation to rotctld, and check how elevation is handled when a pass crosses the zenith. Reproducing needs a rotator or a simulated rotctld backend. Done when an auto-tracked pass near 90 degrees keeps elevation moving past 90 without a full 180-degree azimuth flip, and the 180-degree elevation limit setting takes effect.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I am using GPredict 2.3.37, hamlib 4.5.5, SPID MD01, rotctld, and a Big-Ras rotator, on a Windows 10 64 bit computer.
The commands sent to the rotator for near satellite passes near the zenith do not seem to be working properly. When a satellite passes near the zenith (an elevation angle of 90 degrees) with satellite tracking on and the rotator engaged, the rotator does a full 180 degrees azimuth turn instead of making the elevation angle go past 90 degrees. If the elevation angle was in the range of 90-180 degrees before the satellite, going through the zenith, the elevation angle sent to the rotator will stay above 90 degrees, and if the elevation angle was in the range of 0-90 degrees, the elevation angle will stay lower than 90 degrees. This full 180 degree azimuth turn takes time for the rotator to perform so the rotator does not track the satellite for a while. These high elevation angle passes are critical for communicating with a Cubesat so it is important that it is tracked consistently. I had the settings for the rotator having a maximum elevation angle of 180 degrees as shown in the image, but that did not make a difference. I can use GPredict to manually control the rotator and set it past 90 degrees in elevation, but GPredict does not use the full 180 degree elevation angle capability when tracking the satellite automatically.
https://github.com/csete/gpredict/assets/90346350/b66fc0c3-8218-46ee-ac08-1db61ec1d487
- Lenguaje dominante
- C
- Estrellas
- 1.2k
- Forks
- 305
- Merge medio
- 8 h 48 min
- PR fusionados (30 d)
- 3
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de csete/gpredict
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
Dificultad 2/5 Menos de una hora Aptitud para principiantes 60/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 78/100
Todos los issues de csete/gpredict
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
micropython/micropython#19786 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
vercel-labs/zerolang#442 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Los mantenedores suelen responder en 1 día
-
mewencode: base256[] and base128[] are indexed out of bounds by a non-ASCII octetPosiblemente ocupada @kazu-yamamoto la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
kazu-yamamoto/Mew#276 ·
Los mantenedores suelen responder en 1 día