코드 위상은 1 ms 안의 시간만 알려 준다(4장). 위성이 “지금 몇 시 몇 초에 보냈고, 나는 이런 궤도에 있다”고 말해 줘야 거리와 위치를 계산할 수 있다. 그 말이 항법 메시지다. GPS L1 C/A의 옛 메시지(LNAV)는 초당 50비트, 전화 모뎀보다 훨씬 느리다. 이 장에서는 그 메시지의 구조, 오류를 잡는 패리티, 그리고 1980년에 시작한 GPS 시간을 본다.
프레임(30 s)·서브프레임(6 s)·워드(30비트)의 구조와 각 서브프레임의 내용을 안다.
규격 표 20-XIV의 해밍 패리티를 직접 계산하고 오류를 잡아 본다.
궤도력과 알마낙의 차이, 처음 위치에 왜 30초 가까이 걸리는지 설명한다.
GPS 시간의 시작점, 주 번호와 주내 초, 1024주 넘침, UTC와의 18초 차이를 계산한다.
30초 프레임
LNAV 메시지는 1,500비트짜리 프레임(30초)이 반복된다. 프레임은 300비트 서브프레임(6초) 다섯 개, 서브프레임은 30비트 워드 열 개다. 워드마다 24비트 데이터와 6비트 패리티가 있다. 서브프레임마다 맨 앞 두 워드는 같다. 고정 무늬로 시작을 알리는 TLM과, 다음 서브프레임이 시작하는 시각(주내 시간, TOW)을 6초 단위로 알리는 HOW다. 수신기는 HOW로 코드 위상(1 ms)의 “몇 번째 ms”까지 채워 완전한 송신 시각을 안다.
자동차 주행 거리계
다섯 자리 주행 거리계는 99,999 km 다음에 00,000으로 돌아간다. 차를 처음 본 사람은 새 차인지 10만 km를 달린 차인지 숫자만으로는 모른다. LNAV는 GPS 주 번호를 10비트로만 보내 1,024주(약 19.6년)마다 0으로 돌아간다. 수신기는 다른 단서(펌웨어 날짜 등)로 몇 바퀴째인지 정해야 한다.
INTERACTIVE
프레임 탐색기
서브프레임 1·2·3을 다 받을 때까지—
평균 / 최악—
알마낙 전체(25 페이지)—
막대: 한 프레임의 서브프레임 1~5(누르면 내용). 해볼 것: 듣기 시작한 순간을 바꿔 보자. 서브프레임 1이 막 지나간 뒤에 들으면 다음 프레임의 1을 기다려야 해 최대 36초 가까이 걸린다. 평균은 약 24초(18초 + 서브프레임 경계를 기다리는 평균). 그래서 냉시동 TTFF가 30초 남짓이다(5장). 알마낙은 서브프레임 4·5에 25페이지로 나눠 실려 전체를 받는 데 12.5분이 걸린다. 가정: 받는 동안 오류 없음, 같은 궤도력 내용이 반복된다(궤도력은 보통 2시간마다 바뀜).
신호가 약해 비트 하나가 뒤집히면 위치가 수 km 틀릴 수 있다. 그래서 워드마다 6비트 패리티를 단다. 규격은 (32,26) 해밍 부호를 쓴다. 이전 워드의 마지막 두 비트(D29*, D30*)와 이번 워드의 데이터 24비트로 패리티 6비트를 계산한다. 또 이전 워드의 D30*이 1이면 이번 워드의 데이터 비트를 모두 뒤집어 보낸다. 받은 쪽은 같은 계산으로 패리티를 확인하고, 맞지 않으면 그 워드를 버린다.
CALCULATOR
해밍 패리티 계산기
데이터 24비트(d1~d24)와 패리티 6비트(D25~D30, 주황 테두리). 비트를 눌러 뒤집어 보자.
패리티 식은 규격 표 20-XIV를 그대로 옮겼다(예: D25 = D29* ⊕ d1 ⊕ d2 ⊕ d3 ⊕ d5 ⊕ d6 ⊕ d10 ⊕ … ⊕ d23). 해볼 것: ① 데이터 비트 하나를 뒤집으면 패리티 검사가 실패한다. ② 데이터 비트 둘을 뒤집어도 대개 실패한다. ③ “패리티 다시 계산”을 누르면 송신기처럼 새 패리티를 붙인다. 검증 스크립트는 이 계산이 RTKLIB의 decode_word()와 수천 개의 무작위 워드에서 같은 판정을 내는지 확인한다.
패리티 식: IS-GPS-200N 20.3.5, 표 20-XIV(p.139) · 사용자 패리티 알고리즘: 20.3.5.2, 그림 20-5 · 같은 계산의 구현: RTKLIB rtkcmn.cdecode_word()(주석 “see reference [1] 20.3.5.2 user parity algorithm”)
궤도력과 알마낙
서브프레임 1: 주 번호, 위성 상태, 시계 보정 계수(af0, af1, af2)와 기준 시각 toc, 그룹 지연 TGD.
서브프레임 2·3: 그 위성만의 정밀 궤도, 궤도력(ephemeris). 케플러 궤도 요소와 보정 항 16개 남짓이고, 보통 2시간마다 새것으로 바뀌며 4시간 정도 유효하다(8장에서 이것으로 위성 위치를 계산한다).
서브프레임 4·5: 모든 위성의 대략적 궤도, 알마낙(almanac). 정밀도는 km 수준이지만 몇 달 쓸 수 있다. 어떤 위성이 하늘에 있고 도플러가 얼마일지 미리 알아 탐색을 줄인다(5장의 온시동). 전리층 모델 계수(10장)와 UTC 변환 값도 여기 있다.
새 GPS 신호(L2C·L5의 CNAV, L1C의 CNAV-2)와 Galileo의 I/NAV·F/NAV는 더 효율적인 메시지 구조와 강한 오류 정정 부호를 쓴다. 이 장의 LNAV는 가장 오래되고 가장 널리 쓰이는 형식이다.
GPS 시간
GPS 시간은 1980년 1월 6일 0시(UTC)에 0에서 시작해 윤초 없이 계속 흐른다. 수신기는 이것을 주 번호와 주내 초(TOW, 일요일 0시부터 0~604,799초)로 다룬다. UTC는 지구 자전에 맞추려고 가끔 윤초를 넣으므로, 2017년 이후 GPS 시간은 UTC보다 18초 앞서 있다.
LNAV 메시지의 주 번호는 10비트라 1,024주(약 19.6년)마다 0으로 돌아간다. 1999년 8월과 2019년 4월에 실제로 넘쳤고, 이를 처리하지 못한 옛 수신기들이 엉뚱한 날짜를 보였다. 새 메시지(CNAV)는 13비트를 쓴다.
예측해 보기
2019년 4월 주 번호가 넘쳤을 때, 몇 바퀴째인지 고려하지 않은 수신기는 날짜를 언제로 표시했을까?
1,024주 = 7,168일.
2019-04-06 23:59:42 UTC에서 1,024주를 빼면 1999-08-21 23:59:47 UTC 무렵, 직전 넘침 시점이다. 실제로 일부 오래된 수신기와 기기가 이렇게 날짜를 잘못 보였다. 아래 계산기에 2019-04-07을 넣어 주 번호를 확인해 보자.
CALCULATOR
날짜 → GPS 주·주내 초
GPS 주 / 주내 초—
LNAV 10비트 주 번호(넘침 횟수)—
다음 10비트 넘침—
GPS 시간 = UTC + 윤초 차이(2017-01-01 이후 18초, RTKLIB의 윤초 표). 해볼 것: 1999-08-21 23:59:47 UTC와 2019-04-06 23:59:42 UTC 근처를 넣어 보면 10비트 주 번호가 1023에서 0으로 넘어간다. 다음 넘침은 2038년 11월이다.
GPS 시간 기준점(1980년 1월 5일 밤 / 1월 6일 아침 자정 UTC)과 주 번호가 넘침 없이 계속 증가함, LNAV는 하위 10비트만 보냄: IS-GPS-200N 6.2.4(p.47), 20.3.3.3.1.1 · UTC − GPS 윤초 표(2017-01-01부터 −18 s): RTKLIB rtkcmn.cleaps[]