개요
Starlink Viewer는 약 10,000개의 모든 Starlink 위성이 실시간으로 움직이는 라이브 3D 지구본, 디시 위치, 그리고 터미널에 서비스를 제공할 가능성이 가장 높은 위성으로의 추정 연결을 표시합니다.
이상적인 Starlink 모니터링 도구는 주어진 시점에 디시가 통신하는 위성, 새 위성으로의 핸드오프 시점, 디시에서 위성을 거쳐 지상국에 이르는 신호 경로를 정확히 보여줄 것입니다. 이를 위해서는 디시가 서비스 위성의 식별 정보와 전자 빔 조향 방향을 노출해야 합니다. SpaceX는 둘 다 노출하지 않으므로, Nexus는 사용 가능한 데이터에서 서비스 위성을 추정합니다.
추정이 필요한 이유
SpaceX는 소비자 펌웨어에서 접근할 수 없는 인증된 gRPC 엔드포인트 뒤에 위성 식별 데이터를 잠가두고 있습니다.
- **
dish_get_context**에는initial_satellite_id필드가 포함되어 있지만, 펌웨어9f4d05a4(2021년 6월) 이후 소비자 하드웨어에서PermissionDenied를 반환합니다. - **
transceiver_get_telemetry**는lmac_satellite_id와target_satellite_id를 노출하지만, 모든 소비자 터미널에서UNIMPLEMENTED를 반환합니다. - PKI 챌린지-응답 인증은 SpaceX가 관리하는 키를 사용하므로 커뮤니티 우회 방법이 존재하지 않습니다.
- 전자 빔 조향 방향: 서비스 위성을 직접 식별할 수 있는 데이터이지만 어떤 엔드포인트에서도 노출되지 않습니다.
- 디시의 위상 배열 안테나는 보어사이트에서 최대 **±50°**까지 전자적으로 빔을 조향하지만, 이 조향 각도는 API의 외부 소비자에게 전혀 보이지 않습니다.
사용 가능한 데이터
디시에서 측정되는 데이터
| 데이터 | 알 수 있는 것 | 업데이트 주기 |
|---|---|---|
| 보어사이트 방위각 및 고도각 | 디시 본체의 물리적 방향 | 1 Hz |
| PoP ping 지연 시간 | 존재 지점까지의 왕복 시간 | 1 Hz |
| 다운링크 및 업링크 처리량 | 현재 처리량 | 1 Hz |
| 슬롯 타이머 | 위성 슬롯 타이머 (테스트된 하드웨어에서 항상 0) | 1 Hz |
| GPS 좌표 | 디시 위치 | 요청 시 |
장애 이력 (did_switch) |
서비스 중단 중 위성 전환 확인 | 장애 이벤트별 |
| 장애물 맵 (SNR 그리드) | 123×123 픽셀 하늘 맵. 핸드오버 경계에서 리셋되면 실시간 위성 신호 데이터를 포함합니다 (Obstruction Map and Satellite Tracking 참조) | 1 Hz |
외부 소스
| 데이터 | 알 수 있는 것 |
|---|---|
| 약 10,000개 Starlink 위성의 TLE 궤도 요소 (CelesTrak / 18th Space Defence Squadron) | 임의의 관측 위치에서 모든 위성의 계산된 방위각, 고도각, 경사 거리 |
사용할 수 없는 데이터
| 데이터 | 필요한 이유 | 상태 |
|---|---|---|
| 서비스 위성 ID | 직접 식별 | 인증 뒤에 잠김 |
| 전자 빔 조향 각도 | 정확한 빔 방향 | 어떤 엔드포인트에서도 노출되지 않음 |
| 기능하는 슬롯 타이머 | 핸드오프 타이밍 신호 | 필드는 존재하지만 현재 소비자 펌웨어에서 0을 읽음 |
매칭 작동 방식
위성 매칭
뷰어는 1 Hz에서 다음 계산을 수행합니다:
-
관측자 위치:
get_location의 디시 GPS 좌표로 지구상의 위치를 확정합니다. -
위성 위치: CelesTrak의 TLE 데이터에 SGP4 궤도 전파를 사용하여, 디시 위치에서 본 모든 Starlink 위성의 방위각, 고도각, 경사 거리를 계산합니다.
-
시야 필터링: 고도각 10° 이상의 위성만 고려됩니다. 디시의 물리적 보어사이트 방향(
alignment_stats에서 가져옴)이 위상 배열의 약 100° 시야 원뿔의 중심을 정의합니다. -
최근접 후보 선택: 물리적 보어사이트 중심으로부터 각거리가 가장 작은 위성이 서비스 제공 가능성이 가장 높은 위성으로 선택됩니다.
보어사이트 십자선
극좌표 스카이 플롯의 십자선은 전자 빔 방향이 아닌 디시 본체의 물리적 방향을 나타냅니다. Starlink 위상 배열 안테나는 초기 정렬 후 대부분 정지 상태이며, 보어사이트 값은 바람이나 열 효과로 인해 수시간에 걸쳐 소수점 이하의 도 단위로 변합니다. 디시는 개별 위성을 추적하기 위해 물리적으로 움직이지 않습니다.
실제 빔 조향은 위상 배열 내에서 RF 수준으로 전자적으로 이루어지며, 물리적 보어사이트에서 최대 ±50°까지 스위핑하여 서비스 위성을 추적합니다. 이 전자 빔 방향은 어떤 소비자 API 엔드포인트에서도 노출되지 않습니다.
위성 변경 감지
최근접 위성 후보가 변경되면(다른 NORAD ID가 기하학적으로 가장 가까워지면), 이는 추정된 위성 변경으로 기록됩니다. 이러한 변경은 실제 디시 핸드오프와 상관관계가 있지만 확인하지는 않습니다. 이는 궤도 역학을 반영합니다; 위성이 약 7.5 km/s로 상공을 통과하면서, 디시의 보어사이트 중심에 가장 가까운 위성은 자연스럽게 몇 분마다 변경됩니다.
Starlink의 실제 위성 핸드오프는 끊김 없이 설계되어 있으며(make-before-break), 현재 펌웨어에서 신뢰할 수 있는 감지 신호로 사용할 수 있는 지연 시간이나 처리량의 측정 가능한 불연속성을 발생시키지 않습니다.
신뢰도 점수
신뢰도 점수는 매칭된 위성이 실제 서비스 위성일 기하학적 가능성을 반영합니다:
| 신뢰도 | 기준 | 해석 |
|---|---|---|
| 높음 | 보어사이트에서 10° 미만, 근접 후보 3개 이하 | 근처에 위성이 적음; 기하학적으로 강력한 후보 |
| 중간 | 보어사이트에서 25° 미만 | 시야 내에 충분히 위치; 합리적인 후보 |
| 낮음 | 보어사이트에서 50° 미만 | 디시의 조향 범위 내이지만 근접 후보가 많음 |
| 매칭 없음 | 보어사이트에서 50° 초과 | 디시의 전자 조향 범위 내에 위성이 없음 |
이 임계값은 전자 빔이 아닌 물리적 보어사이트(디시 본체 방향)에 대해 교정되어 있습니다. 위상 배열이 디시 면에서 ±50° 조향할 수 있으므로, 서비스 위성은 일반적으로 물리적 보어사이트 중심에서 10-40° 위치에 있습니다. “높음” 신뢰도 매칭은 기하학적으로 강력한 단일 후보가 있다는 의미이며, 식별이 확인되었다는 의미가 아닙니다.
정확도 수준
신뢰할 수 있는 것
지구본상의 위성 위치는 정확합니다. CelesTrak의 TLE 데이터는 권위 있는 데이터(미국 우주군 18th Space Defence Squadron 제공)이며, SGP4 전파는 우주 추적 커뮤니티에서 사용하는 표준 방법입니다. 최근 업데이트된 TLE의 경우 위치 정확도는 일반적으로 수 킬로미터 이내입니다.
디시 위치는 정확합니다. 디시의 내장 GPS에서 직접 가져옵니다.
물리적 보어사이트 방향은 정확합니다. 디시의 IMU(관성 측정 장치)에 의해 약 0.6°의 불확실성으로 측정됩니다.
가시 위성 세트는 정확합니다. 사용자 위치에서 각 위성까지의 계산된 시야각은 기하학적으로 정확하므로, 극좌표 플롯은 어떤 위성이 상공에 있고 하늘의 어디에 있는지 올바르게 표시합니다.
추정되는 것
식별된 위성은 근거 있는 추정입니다. 보어사이트 중심에 가장 가까운 위성이 최적의 기하학적 후보이지만, 디시는 ±50° 전자 조향 범위 내의 어떤 위성과도 통신 중일 수 있습니다. 주어진 시점에 수십 개의 위성이 시야 내에 있을 수 있습니다.
위성 변경은 관측된 기하학이며 확인된 핸드오프가 아닙니다. 최근접 후보가 변경되면, 이는 궤도 드리프트를 반영합니다; 다른 위성이 기하학적으로 가장 가까워진 것입니다. 실제 디시 핸드오프는 이러한 기하학적 변경과 일치할 수도 일치하지 않을 수도 있습니다. 일부 실제 핸드오프는 추정에 보이지 않으며(디시가 다른 위성으로 전환되지만 기하학적 최근접이 변하지 않음), 관측된 변경 중 일부는 순수한 궤도 드리프트입니다(기하학적 최근접이 변했지만 디시가 실제로 전환하지 않음).
신뢰도 점수는 기하학적이며 신호 기반이 아닙니다. “높음” 신뢰도 매칭은 좋은 기하학을 의미하지 검증된 연결을 의미하지 않습니다. 전자 빔 방향이나 서비스 위성 ID에 접근할 수 없다면, 소비자 펌웨어 기반 도구로는 디시가 실제로 사용 중인 위성을 확인할 수 없습니다.
조사한 신호
개발 중 핸드오프 감지를 위해 여러 신호를 평가했습니다. 모두 실제 하드웨어(rev3_proto2, 펌웨어 2026.02.16.cr74084 및 2026.04.07.mr77639.1)에서 테스트했습니다.
| 신호 | 가설 | 결과 |
|---|---|---|
seconds_to_first_nonempty_slot |
위성 슬롯별로 카운트다운하고 핸드오프 시 리셋되어야 함 | 테스트된 소비자 하드웨어에서 항상 0; 필드가 채워지지 않음 |
pop_ping_latency_ms 불연속성 |
핸드오프 중 경사 거리가 변할 때 지연 시간이 점프해야 함 | 핸드오프를 통해 지연 시간이 매끄러움; SpaceX가 make-before-break 전환으로 경로 변경을 흡수하는 것으로 추정 |
장애 이력의 did_switch |
장애 기록의 전환 확인 플래그 | 서비스 중단 시에만 발생, 일상적인 약 15초의 깨끗한 핸드오프에서는 발생하지 않음 |
| 보어사이트 불연속성 | 디시의 물리적 재배치가 핸드오프에 동반될 수 있음 | 디시 본체는 거의 움직이지 않음; 전자 빔 조향이 위성 추적을 조용히 처리 |
| 장애물 맵 SNR (리셋 없음) | 셀별 SNR 변화가 시야 내 위성 이동을 추적해야 함 | 맵을 리셋하지 않으면, 장애물이 없는 디시에서 정적 누적 클리어 스카이 마스크를 반환; 모든 가시 셀이 연속 폴링 간 변동 없이 ~1.0을 읽음. 누적 데이터가 완전히 포화되어 있으므로, 프레임 간 차분에서는 변화가 감지되지 않음. |
| 장애물 맵 SNR (리셋 있음) | dish_clear_obstruction_map 호출 후, 맵이 빈 상태에서 재구축되어 서비스 위성이 매초 새 픽셀을 그려 위치를 드러내야 함 |
작동 확인됨. 핸드오버 경계에서 리셋한 후, 1 Hz 폴링으로 깨끗한 단일 픽셀 위성 궤적이 생성됨. Obstruction Map and Satellite Tracking 참조. |
Obstruction Map and Satellite Tracking
배경
Ahangarpour, Zhao, and Pan의 SatInView 연구(ACM MobiCom '24 LEO-NET Workshop)는 디시의 장애물 맵을 15초 핸드오버 경계에서 리셋하고, 1 Hz로 폴링하며, 인접한 프레임을 XOR하여 시야를 가로지르는 위성의 궤적을 추출할 수 있음을 입증했습니다. 관측된 궤적은 TLE 전파 위성 위치와 매칭되어 거의 명확한 식별을 달성합니다.
Starlink Viewer의 초기 개발 과정에서, 우리는 리셋 없이 장애물 맵을 테스트했습니다. 장애물이 없는 디시에서 맵은 정적으로 보였습니다. 프레임 간 변동 없이 완전히 포화된 클리어 스카이 마스크였습니다. 우리는 데이터에 실시간 위성 신호 정보가 포함되어 있지 않다고 결론지었습니다. 이 결론은 리셋되지 않은 맵에 대해서는 정확했지만 불완전했습니다. 현재 위성이 그릴 수 있는 모든 픽셀이 이전 위성 통과에서 이미 점등되어 있었기 때문에 맵이 정적으로 보였던 것입니다. 누적된 데이터를 먼저 지우지 않으면 XOR이 감지할 새로운 것이 없었습니다.
업데이트된 발견
SatInView 연구팀과의 교신 후, 우리는 rev3_proto2 하드웨어에서 펌웨어 2026.04.07.mr77639.1(2026년 4월)를 실행하여 전체 리셋 기반 접근법을 테스트했습니다. 결과는 이 기술이 현재 하드웨어와 펌웨어에서 작동함을 확인합니다:
- **
dish_clear_obstruction_map**은 사용 가능하고 작동합니다. 호출하면 누적된 SNR 데이터가 지워집니다(테스트에서 377개 활성 픽셀이 1개로 감소). - 리셋 후, 맵은 서비스 위성이 시야를 통과함에 따라 약 초당 하나의 새 픽셀 속도로 재구축됩니다.
- 인접 프레임의 XOR을 1 Hz로 수행하면, 거의 0에 가까운 분산으로 깨끗한 단일 픽셀 궤적 포인트가 생성됩니다.
- 15초 핸드오버 타이밍(매 분의 12초, 27초, 42초, 57초, 전 세계적으로 동기화됨)은 우리 하드웨어에서 확인되었습니다. 연속된 간격은 동일한 위성을 지속적으로 추적했으며, 실제 핸드오버가 발생했을 때 명확한 궤적 점프가 있었습니다.
- 맵은 고정된 활성 디시에서
FRAME_EARTH를 보고합니다. 이는 그리드가 상단 중앙 픽셀이 진북에 해당하도록 방향이 지정되어 있음을 의미합니다. 모바일 또는 비활성 디시는FRAME_UT를 보고할 수 있으며, 이 경우 하단 중앙 픽셀이 보어사이트 방향에 해당합니다.
트레이드오프: Nexus가 기본적으로 맵을 리셋하지 않는 이유
dish_clear_obstruction_map 호출은 파괴적입니다. 디시의 누적된 장애물 프로파일을 지웁니다. 장애물이 있는 설치(나무, 건물 또는 기타 구조물) 사용자의 경우, 이 데이터는 신호 문제를 진단하는 데 가치가 있으며 많은 위성 통과에 걸쳐 시간이 지남에 따라 축적됩니다. 15초마다 리셋하면 디시가 장애물 데이터를 전혀 축적할 수 없게 되고, Starlink 모바일 앱은 비어 있거나 부분적인 맵을 표시합니다.
Nexus는 현재 기본 위성 식별 방법으로 기하학적 추론(보어사이트 방향 + TLE 매칭)을 사용합니다. 이 접근 방식은 비파괴적입니다. 디시의 어떤 쓰기 엔드포인트도 호출하지 않으며 사용자의 장애물 데이터에 부작용이 없습니다.
우리는 기하학적 추론의 정확도를 검증하고 개선하기 위한 보정 도구로 궤적 기반 접근법을 사용하고 있습니다. 또한 맵 리셋 트레이드오프에 대한 명확한 공개와 함께, 고급 사용자와 연구자를 위한 옵트인 모드로 궤적 추적을 제공할지 여부도 평가하고 있습니다.
변경될 수 있는 요소
향후 펌웨어 업데이트나 하드웨어 개정으로 추정 정확도를 향상시킬 추가 텔레메트리가 노출될 수 있습니다:
- 기능하는
seconds_to_first_nonempty_slot: 이 필드가 최신 펌웨어나 하드웨어에서 채워진다면, 핸드오프별 신뢰할 수 있는 타이밍 신호를 제공합니다. - 전자 빔 조향 각도: 위상 배열의 실제 빔 방향이 노출된다면 직접적인 위성 식별이 가능해집니다.
dish_get_context의 인증 완화: SpaceX가initial_satellite_id필드를 다시 활성화한다면 문제가 완전히 해결됩니다.- 비파괴적 실시간 신호 데이터: 향후 펌웨어가 별도의 엔드포인트 또는 장애물 맵의 비파괴적 변형을 통해 위성별 신호 정보를 노출한다면, 사용자의 장애물 데이터를 리셋하지 않고 궤적 매칭 접근 방식을 사용할 수 있습니다.
- 새 하드웨어 세대: SpaceX는 V3 위성과 새로운 터미널 하드웨어를 배치하고 있습니다. 다른 펌웨어나 하드웨어 개정으로 현재 비활성인 필드가 채워지거나 새로운 텔레메트리가 노출될 수 있습니다.
선행 연구
Nexus는 디시에 서비스를 제공하는 위성을 추정하기 위해 기하학적 추론(보어사이트 방향 + TLE 전파 위성 위치)을 사용합니다. 이것은 휴리스틱 접근 방식입니다. 효과적이고 비파괴적이지만 정밀도에 한계가 있습니다.
더 높은 정확도의 식별을 위해, University of Victoria의 Ahangarpour, Zhao, and Pan에 의해 개발된 SatInView 기법(ACM MobiCom 2024, LEO-NET Workshop)은 장애물 맵 궤적을 TLE 데이터와 상관시켜 거의 명확한 위성 식별을 달성합니다. 그들의 접근법은 핸드오버 경계에서 장애물 맵을 리셋해야 하며, 우리는 이것이 현재 하드웨어와 펌웨어에서 작동한다는 것을 확인했습니다(Obstruction Map and Satellite Tracking 참조). 그들의 구현은 github.com/aliahan/SatInView에서 사용할 수 있습니다.
우리는 Starlink Viewer에서 사용되는 기하학적 추론의 정확도를 보정하고 개선하기 위한 참조로 그들의 궤적 기반 기법을 사용하고 있습니다.
궤도 데이터
위성 위치는 CelesTrak 보조 GP 엔드포인트에서 가져오며, 이 엔드포인트는 SpaceX 제공 궤도력과 18th Space Defence Squadron 표준 카탈로그 데이터를 통합합니다. 데이터는 Rust 백엔드에 의해 로컬에 캐시되고 6시간마다 갱신되며, CelesTrak에 연결할 수 없을 경우 48시간 만료 캐시 대체가 사용됩니다. 상태 표시줄에는 현재 위성 수와 데이터 경과 시간이 표시됩니다.
디시 위치
뷰어는 사용 가능한 경우 디시의 get_location 엔드포인트에서 GPS 좌표를 사용합니다. GPS 데이터에 접근할 수 없는 경우, 구성 패널에서 위도와 경도를 수동으로 입력할 수 있습니다.