Chapter 13

휴대폰 속 GNSS

측량용 GNSS 수신기는 접시만 한 안테나를 쓰는데, 휴대폰은 손톱만 한 안테나를 기기 귀퉁이에 넣는다. 그런데도 지도 앱은 몇 초 만에 몇 m 안으로 위치를 잡고, 배터리도 크게 줄지 않는다. 이 장은 지금까지의 내용이 휴대폰 안에서 어떻게 합쳐지는지 보고, Android가 열어 둔 원시 측정값으로 의사거리를 직접 계산해 본다.

휴대폰 GNSS의 약점(작은 선편파 안테나, 몸, 배터리)과 그것을 메우는 방법을 안다.
Android의 GnssClock·GnssMeasurement 값으로 의사거리를 직접 계산한다.
듀티 사이클이 배터리를 아끼는 대신 무엇을 잃는지 안다.
터널처럼 GNSS가 끊긴 동안 관성 센서만으로 위치를 이어 갈 때 오차가 어떻게 커지는지 계산한다.

작은 안테나, 많은 위성

위성 신호는 오른쪽으로 도는 원편파다. 휴대폰 안테나는 공간이 없어 대개 선편파이고 이득도 낮아, 그것만으로 3 dB 이상 잃고 손·몸·케이스가 더 깎는다. 그래서 휴대폰의 맑은 하늘 C/N0는 측량 수신기보다 5~10 dB 낮다. 대신 요즘 칩은 다음으로 메운다.

여러 위성군: GPS·GLONASS·Galileo·BeiDou·QZSS를 함께 들어 하늘의 위성 수십 기를 쓴다(2·11장). Android는 위성군을 번호로 구분한다: GPS 1, SBAS 2, GLONASS 3, QZSS 4, BeiDou 5, Galileo 6, NavIC(IRNSS) 7.
이중 주파수: 2018년 이후 L1 + L5(E1 + E5a) 휴대폰이 나와 전리층을 지우고(10장) 도시의 다중 경로에 강해졌다(11장).
A-GNSS: 통신망에서 궤도력·대략 위치·시각을 받아 몇 초 만에 첫 위치를 잡는다(5장).
센서 융합: 가속도·자이로·기압계·와이파이·셀 위치와 함께 계산해, 신호가 흔들리거나 끊겨도 위치를 이어 간다.

위성군 번호: Android frameworks/base GnssStatus.java의 CONSTELLATION_GPS = 1 … CONSTELLATION_IRNSS = 7

원시 측정값으로 의사거리 계산하기

Android 7(2016)부터 앱이 칩의 원시 측정값을 받을 수 있다. 위치 결과만이 아니라, 9장에서 수신기가 쓰는 재료 그대로다. 의사거리는 “받은 시각 − 보낸 시각”에 빛의 속도를 곱한 것이고, Android는 두 시각을 이렇게 준다.

받은 시각(GPS 시간): TimeNanos − (FullBiasNanos + BiasNanos). TimeNanos는 칩 하드웨어 시계, FullBiasNanos는 그 시계와 1980년 1월 6일부터의 GPS 시간의 차이(7장).
보낸 시각: ReceivedSvTimeNanos, 그 주 일요일 0시부터의 위성 시각(TOW를 해독했을 때, STATE_TOW_DECODED).

CALCULATOR

GnssClock + GnssMeasurement → 의사거리

받은 시각(주내 ns)—

비행시간—

의사거리—

계산: t_Rx = TimeNanos + TimeOffsetNanos − (FullBiasNanos + BiasNanos), 주내 시각 = t_Rx mod 604,800 × 10⁹, 의사거리 = (주내 t_Rx − ReceivedSvTimeNanos) × c × 10⁻⁹. 예시 값은 설명용이다(실제 기록과 같은 크기). 해볼 것: FullBiasNanos를 1 µs(1,000 ns) 바꾸면 의사거리가 300 m 바뀐다. 모든 위성에 똑같이 바뀌므로 위치가 아니라 시계 오차로 흡수된다(1·9장). 같은 측정의 반송파 위상은 AccumulatedDeltaRangeMeters로 오고, 사이클 슬립은 ADR_STATE_CYCLE_SLIP으로 표시된다(6장).

“local estimate of GPS time = TimeNanos − (FullBiasNanos + BiasNanos)”, GPS 시간 기준 1980-01-06: Android GnssClock.java · getReceivedSvTimeNanos(), getAccumulatedDeltaRangeMeters(), getCn0DbHz(), STATE_TOW_DECODED, ADR_STATE_CYCLE_SLIP: GnssMeasurement.java

듀티 사이클: 배터리와 맞바꾸기

GNSS 칩이 쉬지 않고 추적하면 휴대폰에서 꽤 큰 전류를 쓴다. 그래서 칩은 위치가 필요 없는 짧은 순간마다 수신부를 껐다 켜는 듀티 사이클을 한다. 꺼져 있는 동안에도 시계와 대략의 위치·도플러를 기억하므로 다시 켜면 금방 잡지만(열시동, 5장), 반송파 위상의 연속성은 끊긴다(6장). 그래서 정밀 측정이 필요한 앱을 위해 Android에는 듀티 사이클을 끄고 전체 측정을 강제하는 개발자 옵션이 있다.

SIMULATOR

듀티 사이클과 배터리

켜져 있는 비율 내비게이션 시간

평균 전류—

배터리(5,000 mAh) 중 GNSS 몫—

반송파 위상 연속—

그래프: 1초 안의 수신부 켜짐(막대). 가정(예시 값, 칩마다 크게 다름): 추적 중 25 mA, 꺼짐 1 mA. 해볼 것: 25%면 전류가 약 7 mA로, 2시간 내비게이션에 배터리의 0.3%쯤이다. 화면과 통신이 훨씬 많이 쓴다. 대신 반송파 위상이 끊겨 RTK·정밀 앱(12장)에는 부적합하다.

터널 속 위치: 관성 센서의 한계

터널에 들어가면 GNSS가 끊긴다. 휴대폰은 마지막 속도와 가속도·자이로로 위치를 이어 간다(추측 항법). 문제는 센서의 작은 치우침이 시간의 제곱으로 위치 오차가 된다는 것이다. 가속도계가 0.05 m/s²만 치우쳐도 30초 뒤 위치는 ½·0.05·30² ≈ 22 m 벗어난다. 그래서 차량 내비게이션은 바퀴 속도나 지도의 도로(지도 맞추기)로 함께 묶어, 터널을 나오면 다시 GNSS로 바로잡는다.

눈 감고 걷기

눈을 감고 걸음 수와 방향만으로 걸어 보면 처음 몇 걸음은 정확하지만 조금씩 틀어진 것이 쌓여 금세 엉뚱한 곳에 서 있게 된다. 관성 센서도 같다. 가속도를 두 번 적분해 위치를 구하므로 작은 치우침이 시간의 제곱으로 커진다. 그래서 GNSS가 돌아오면 곧바로 다시 맞춰야 한다.

예측해 보기

가속도계에 0.1 m/s² 치우침이 남아 있다. GNSS 없이 60초를 가면 위치 오차는?

거리 오차 = ½ × 치우침 × 시간².

½ × 0.1 × 60² = 180 m. 20초면 20 m로, 시간이 3배면 오차는 9배다. 그래서 차량은 바퀴 속도(속도 오차가 시간에 비례해 쌓임)나 지도 맞추기를 함께 쓴다. 아래 시뮬레이터에서 비교해 보자.

SIMULATOR

GNSS 없이 버티는 시간

가속도계 치우침 터널 길이(초) 차량 속도·지도 맞추기 함께 쓰기(속도 오차 1%)

관성 센서만—

속도·지도 함께—

출구에서 다시 잡는 데—

그래프: 터널 안 시간(가로)에 따른 위치 오차(세로, 로그). 모델: 관성 센서만 = ½·치우침·t², 속도·지도 = 진행 방향 1% 오차(시속 60 km) + 지도가 옆 방향을 잡아 줌. 출구 재획득은 열시동(5장의 A-GNSS 열시동, 약 1~2 s).

핵심 정리

휴대폰 안테나는 작고 선편파라 C/N0가 낮다. 여러 위성군, L1+L5, A-GNSS, 센서 융합으로 메운다.
Android 원시 측정값: 받은 시각 = TimeNanos − (FullBiasNanos + BiasNanos), 보낸 시각 = ReceivedSvTimeNanos, 의사거리 = 차이 × c.
듀티 사이클은 배터리를 아끼지만 반송파 위상 연속성을 끊는다. 정밀 앱은 전체 측정을 강제한다.
관성 센서만의 위치 오차는 t²로 자란다(0.05 m/s², 30 s → 22 m). 속도·지도와 묶고 GNSS로 다시 잡는다.

확인 퀴즈

Android에서 Galileo의 위성군 번호는?

GnssStatus.CONSTELLATION_GALILEO = 6. BeiDou는 5.

FullBiasNanos가 모든 위성에 1 µs 틀리면?

모든 위성에 공통인 오차는 네 번째 미지수가 먹는다.

듀티 사이클의 대가는?

RTK 같은 정밀 계산에 부적합해진다.

가속도계 치우침 0.1 m/s²로 20초 버티면 위치 오차는?

½ × 0.1 × 20² = 20 m.