0xFF

Iridium 통신위성을 이용한 위치추적기 만들기 - 1부 본문

RF/위성통신

Iridium 통신위성을 이용한 위치추적기 만들기 - 1부

캡스락 2019. 8. 25. 17:24

이리듐 위성 네트워크란?

전 지구 100% 커버리지를 자랑하는 이리듐 위성 네트워크입니다.



이리듐 네트워크는 780km 상공의 극궤도를 도는 통신 위성으로 구성된 위성 네트워크입니다.

6개의 궤도면마다 11기의 위성이 배치되어 총합 66기의 위성으로 서비스가 제공되고 있으며, 위 그림에서 보실 수 있듯 위성의 커버리지는 서로 겹치도록 설계되어 있으므로 사용자는 말 그대로 지구 상 어느 곳에서나(남, 북극 및 해양 포함) 위성을 통해 서비스를 제공받을 수 있습니다.

단, 아무래도 위성인 만큼 하늘로의 시야가 제한되는 건물 내부나 지하, 또는 울창한 나무 아래 등 장애물이 있을 경우 쉽게 끊김이 발생할 수 있습니다.

더보기

이리듐은 과거 1990년대 초반 미국 모토로라의 주도로 우리나라의 SK 텔레콤(당시 한국이동통신)을 포함한 15개국 25개 기업에서 출자하여 이리듐 컨소시엄을 결성하며 시작되었습니다.

 

80년대 말까지만 해도 휴대폰 로밍 서비스가 없었는데, 당시 전 세계 휴대폰 시장에서 현 삼성, 애플급 위상을 갖던 모토로라에서 인공위성을 올려 지구 어느 곳에서든 전화가 가능하게 하겠다는 획기적인 프로젝트를 발표하고 투자자를 모집했다고 합니다. 세계 휴대폰 1위 기업이 그런 말을 하니, 각국 통신사들은 미래의 통신 기지국은 우주의 인공위성이 될 것이라는 아이디어에 일말의 의심 없이 낚인 것이었죠.

물론, 위성 통신은 커버리지 면에서는 현존하는 그 어떤 통신 방식도 따라올 수 없겠으나 신호 수신 안정성, 위성당 수용 가능한 동시 통화 수, 커다란 안테나 등 위성 기반 전화기가 일반 휴대폰을 대체하기에는 장점보다 단점이 많았고, 이는 당시에도 충분히 예측 가능했을 것으로 생각되나, 당시 모토로라는 그대로 사업을 밀고 나갑니다. 

더구나 이리듐의 핵심인 위성 제작 단가와 발사 비용이 낮아진 지금 시점에서 봐도 66개나 되는 위성을 쏘아 올린다는 것은 보통 일이 아닌데, 당시 모토로라에서는 이렇게 실패 확률이 농후한 이리듐 프로젝트를 그대로 추진하였고 실제로 모든 위성을 발사하게 됩니다.

발사된 위성들로 구축된 위성 네트워크와 단말기는 훌륭한 글로벌 통신 서비스를 제공했고, 기술적으로는 완벽히 성공한 사업이라는 평가를 받았습니다..

만.. 위성 발사 비용 회수를 위한 천문학적인 단말기 가격과 요금제로 서비스 시작부터 외면당한 이리듐은 휴대폰 로밍 서비스가 막 활성화되기 시작하던 당시 상황과 맞물리며 서비스 시작과 동시에 초고속으로 망하기 시작합니다.

결국 이리듐은 전 지구적 스케일에도 불구하고 그 가입자 수가 국내 약 150명, 전 세계 총합 5000명 정도(1999년 1~2월 기준) 밖에 되지 않았다고 합니다. 당시 이리듐은 가입자 50만 명을 예측했으나 사실상 아무도 가입하지 않은 것이었죠..

기존 휴대전화만으로도 충분했던 일반인들은 비싼 단말기 가격과 전화비, 그리고 실내에서 통화가 불가능한 단점을 가진 이리듐을 쓸 이유가 전혀 없었고, 결국 가입자 부족으로 서비스 시작 9개월 만에 모토로라는 무려 5조를 들인 이리듐 사업을 내놓게 됩니다.

그렇게 2001년, 이리듐은 위성을 포함해 겨우 250억 원이라는 헐값에 간신히 다른 사업자에게 팔리게 되었고, 이후 미군의 군 통신수단으로 채택된 후 지금까지도 미군이 가장 큰 고객이자 밥줄이 되어 잘 돌아가고 있습니다.

다만 스타링크, 원웹, 카이퍼 등 저가+고속+저지연 위성인터넷 서비스가 실제로 상용화되기 시작하는 요즘은 이리듐과 같은 기존 업체들도 살아남기 위해선 변화가 필요할 것으로 보입니다. (특히 요금)


이리듐 모뎀 구매까지의 과정..

우선 이리듐 위성망을 쓰기 위해서는 이리듐 위성과 통신할 수 있는 전용 모뎀이 필요합니다.

해외 웹을 통해 아두이노나 라즈베리파이에서 사용할 수 있도록 나와 있는 이리듐 모듈을 알게 되었지만,

Rock7mobile에서 판매중인 이리듐 모듈


무려 249 달러, 모듈 하나에 우리 돈으로 약 30만 원이라는 정신나간 가격을 보여줍니다..

여기에 무관세 기준인 150달러를 초과하니 관세 10%가 추가된다고 가정하면 최소 33만 원 정도가 소요된다고 생각할 수 있겠습니다.

사실 '위성 통신망'이라는 엄청난 스케일과 함께 그 고객 수가 얼마 되지 않는다는 점을 상기해 보면 그렇게 이해가 가지 않는 가격 책정은 아니지만,

가난한 학생인 제가 순전히 재미로 구매해 보기에는 진입 장벽이 너무 높았습니다.

저는 아래 130달러짜리를 주문했는데 그새 더 저렴한 물건이..^^

이대로 포기하긴 아쉬워서 다른 방법을 모색해본 결과,

이베이에서 락블록 제품에 사용된 것과 같은 모델의 중고 이리듐 모뎀(정식 모델명은 Iridium SBD9602)이 돌아다니고 있는 것을 목격하게 되었고

락블록의 이리듐 모듈은 락블록 전용이 아닌 범용 제품이라는 점도을 알게 되었습니다.

하지만 애초에 개인을 위한 물건이 아니었던 만큼, 락블록을 제외하고 국내외 할 것 없이 모뎀 단품을 구매해서 사용해 본 후기는 어디서도 찾을 수 없었습니다.

결국 답답한 마음에 Rock7에 중고로 구한 모뎀을 등록하여 사용하는 것이 가능한지에 대해 문의해 봤는데,
의외로 별도의 비용 없이도 IMEI만 알려주면 락블록과 똑같이 등록하여 사용할 수 있다는 답변을 받았습니다.

(좌) 제어 명령어 레퍼런스 (우) SBD9602 데이터시트

그리고 검색 중 어째서인지 Confidential이 붙은 채로 배포되고 있는 데이터시트와 이리듐 공식 명령어 레퍼런스까지 어렵지 않게 찾아내는 데 성공했습니다 ㅋㅋㅋ

데이터 시트를 읽어 보니 모뎀 제어는 UART 핀을 통해 AT 명령어로 이뤄진다는 것을 알 수 있었고,
먼 곳에 위치한 위성과 통신하는 만큼 발신 시 전원부에서 8.3밀리초간 1.5A의 전류 공급을 보장해야 한다는 점이 중요한 점이었습니다.

아무튼, 이렇게 모뎀을 직접 구매해도 개통에는 문제가 없다는 것을 알게 되었기에 락블록 짝퉁(?)을 직접 만들어 보기로 결정했습니다.

구매한 부품은 다음과 같습니다.
SBD9602 모뎀, 1.27mm 10핀 2열 헤더 핀 커넥터, 적색 및 녹색 LED, 슈퍼콘덴서 5.5V 3F, mmcx to sma 변환 케이블, 콘덴서 역류방지용 다이오드, 1.27mm 만능 기판
전자부품 쇼핑몰인 디바이스마트에서 구매했고, 약 만 원 정도 들었습니다.

부품 조립 및 납땜

저에게 가장 자신 없는 부분입니다..

더구나 핀 간격이 1.27mm 밖에 안 돼서 납땜하는데 한참 걸렸습니다.

납땜해줄 부분은 데이터시트를 참고하셔서
헤더 핀 커넥터, 네트워크 상태 LED, 전원 LED, 슈퍼콘덴서, TTL RX 및 TX, 다이오드만 연결하시면 됩니다.

또한 슈퍼콘덴서를 장착해야 하니 10옴 정도의 저항을 하나 달아주시는 것을 강력히 권장드립니다.


작동 테스트는 PL2303, CP2102와 같은 USB to UART 변환 어댑터를 통해 컴퓨터에 연결하시면 되고, 시리얼 포트는 다음과 같이 설정하시면 됩니다.
Baud Rate: 19200 bps, Data Bits: 8, Parity: None, Stop Bits: 1

이제 기본적인 작동 여부를 확인해 보기 위해 'AT'라고 전송하고, 이에 모뎀이 'OK'라고 응답하는 것을 확인하셨다면 일단 양품이라고 보시면 되겠습니다.

추가로 TTL 연결을 사용할 때에는 데이터 흐름 제어 핀을 사용하지 않으므로 'AT&K0' 명령어로 꺼 주시는 것이 좋습니다. 이 명령의 실행 결과도 'OK'라고 응답하는지를 확인하시면 되겠습니다.

AT 입력 결과


이제 작동 여부가 확인되었으니 모뎀을 개통하고 데이터 송수신 테스트를 진행해 보겠습니다!

개통 방법은 크게 두 가지가 있는데, 하나는 이리듐 서비스 프로바이더로 지정된 업체를 통해 이리듐에 직접 등록하는 방법과 Rock7mobile 이라는 영국 파트너사를 통해 등록하는 방법이 있습니다.

이 둘은 과금 체계나 서비스 이용 방식에서도 차이가 있는데, 간단하게 결론만 말씀드리자면 3개월 이상의 장기 이용이 필요하신 경우 이리듐 프로바이더를 통한 직접 등록이 낫고, 단순 테스트 또는 1~2개월 정도의 단기 프로젝트를 진행하신다면 Rock7을 이용하시는 것이 비용적으로 낫다고 보여집니다.

Rock7의 경우 부수적으로 웹 관리 UI나 HTTP API를 기본적으로 제공(이리듐은 TCP 소켓 통신)해 줘서 비교적 쉽고 빠르게 개발을 시작할 수 있다는 것도 장점입니다.

좀 더 구체적으로 말씀드리자면 이리듐에 직접 등록(한국은 국내 이리듐 프로바이더인 아리온통신을 통해 개통)하는 방법의 경우, Rock7 대비 데이터 요금이 저렴하다는 장점은 있으나, 가입 시 선택한 요금제의 요금과 함께 가입비(38,000원 가량)를 별도로 받으며, 메시지 전송 API 사용을 위해 이리듐 게이트웨이에 IP 화이트리스트 등록 요청을 할 때도 수수료가 발생하기 때문입니다.

물론 저도 호기심에 사용해 보는 것이기 때문에 이리듐에 직접 등록하는 대신 Rock7mobile에 등록하였습니다.
Rock7은 이리듐 위성망을 임대하여 재판매하는 일종의 '별정 통신사' 같은 개념으로 보시면 적절할 것 같습니다. 이름에서 알 수 있듯 RockBLOCK 모듈을 판매하는 업체이기도 합니다.

1. 모뎀 개통하기

그럼 이제 본격적인 개통을 진행해 보겠습니다.

모든 개통 과정은 락블록 관리자 포털에서 이루어지는데, 그 전에 구매한 모뎀을 자신의 계정에 등록해야 합니다.

RockBLOCK Admin

하지만 회원가입 후 관리 포털에 들어가 보면 기본적으로 자사 락블록 제품의 등록 코드 입력란 외에 모뎀의 IMEI를 직접 입력할 수 있는 부분은 없다는 것을 아실 수 있을 것입니다.

따라서 별도로 구한 모뎀을 등록하여 사용하고자 한다면 IMEI를 이메일로 보내 등록 요청을 해야 하는데요,

Rock7의 고객센터 주소인 support@rock7.com 이곳으로 자신이 구매한 모뎀의 IMEI를 자신의 계정(가입 시 작성한 메일주소)에 추가해 달라고 말씀하시면 됩니다.

뭐라고 보내야 할지 잘 모르시겠다면 제가 작성한 아래의 양식(미천한 실력이지만..)을 참고해서 보내셔도 괜찮을 것 같습니다.

Hello.

I got an used iridium sbd modem from ebay,
but I couldn't get registered it to my account because it has no serial sticker which RockBlock has.
So, I'll thank you to register my modem with its IMEI number I attached, if it's possible.
My IMEI number is <IMEI>, and my Rock7 account is <계정 이메일>.

Kind Regards,

Credits and Line Rental


Rock7의 일처리는 꽤 빨라서, 메일을 보내고 당일~하루 정도면 답장을 받을 수 있는 것 같습니다.

저는 문의한 당일 등록이 완료됐다는 답장을 받았습니다.

이렇게 모뎀 추가가 완료되었다면 포털의 'My RockBLOCKs' 메뉴에서 요청한 IMEI가 등록된 것을 확인하실 수 있게 됩니다.

이제 등록된 모뎀에 대해 이용료를 결제하기 위해 'Credits and Line Rental' 메뉴로 이동해 보겠습니다.


1개월 회선 요금 12파운드 + 크레딧 100개 13파운드 = 41,000원

Monthly Line Rental은 단순 회선 유지 비용(선불)으로 1개월에 12파운드(한화 약 20,000원)이며, 원하는 사용 개월수만큼 선택하시면 됩니다.

Credits는 데이터 50바이트에 1개씩 차감되는 데이터 과금 단위인데, 아래와 같이 묶음으로 판매되고 있으며, 역시 필요한 만큼 미리 충전해 두어야 합니다.

최소 구매 단위는 100개(5,000 바이트) 묶음으로, 약 21,000원입니다.

크레딧 묶음별 가격

해당 상품 기준으로 단가는 0.13파운드로, 결국 50바이트에 210원이라는 말인데.. 그야말로 미친 가격입니다 ㅋㅋㅋ
가장 저렴하게 월 5KB만 이용하려고 해도 기본료까지 포함하면 월 4만원을 내야 하는 셈인거죠..

또한 하나의 크레딧은 최대 50바이트 범위 안에서 사용량과 무관하게 무조건 1개 단위로 차감되므로 가능하면 첫 50바이트 내로 데이터를 잘 압축하셔야 합니다.

예를 든다면 다음과 같습니다.

보면 볼수록 진짜 날강도가 따로 없습니다 ㅋㅋㅋㅋ

그나마 다행인 점은 잔여 크레딧은 라인 렌탈 기간이 끝난다고 해서 바로 소멸되지는 않고, 마지막 라인 렌탈 기간이 종료된 날짜를 기점으로 12개월까지 유지해 준다고는 합니다.

필요한 만큼 라인 렌탈과 크레딧을 선택하신 다음 Purchase 버튼을 누르고, 비자나 마스터 등 해외 결제가 가능한 카드 번호를 입력하여 결제를 마치면 즉시 사용 가능한 상태가 됩니다.

이리듐 전용 안테나를 연결하고 창틀에 올려둔 모습

이제 모든 준비를 마쳤으니 만든 모듈에 안테나를 연결하고 창가로 나가보겠습니다!

그리고 사진처럼 패치 안테나의 앞면이 하늘을 향하도록 놓아두었더니..


모뎀의 19번 핀에 연결된 LED. 로직 레벨은 3.3V 입니다.


곧 위와 같이 Network Availability 핀에 연결된 LED가 켜지는 것을 확인할 수 있었습니다.

이는 모뎀이 이리듐 위성에서 방송하는 일종의 비콘 신호를 수신했다는 의미인데, 사용자나 소프트웨어로 하여금 언제 통신을 시도해야 할지 일종의 힌트를 주는 역할을 합니다.

이외에도 이리듐 모뎀에서는 아두이노와 같은 MCU 보드에서 활용할 수 있도록 위성 신호의 강도를 보다 구체적인 수치로 확인해 주는 AT+CSQ(Check Signal Quality)와 AT+CSQF라는 두 명령어를 제공하고 있습니다.

AT+CSQ

이 명령을 실행하면 '+CSQ: X'와 같은 형식의 응답을 받을 수 있으며 신호 상태에 따라 X 부분이 0~5까지의 수로 출력됩니다.

여기서 잠깐 CSQ와 CSQF의 차이를 말씀드리자면, CSQF는 이리듐 모뎀이 일정 간격으로 위성에서 보내는 비콘 신호의 강도를 확인 후 저장해 두었던 값을 불러오기만 하는 명령입니다.

그리고 여기서 말하는 '일정 간격'은 상황에 따라 신호가 수신되지 않는 상태임이 확인되면 계속해서 늘어나도록 되어 있기 때문에 CSQF만 사용하게 되면 배터리 환경에서 전원 절약에 조금이나마 도움이 된다는 장점이 있습니다.
하지만 그만큼 실시간성은 다소 떨어진다는 것이 단점이 되겠습니다.

반면 CSQ는 CSQF와는 달리 실행할 때마다 즉시 위성 채널을 스캔하여 신호 수신 강도를 확인한 다음 해당 결괏값을 반환합니다.

따라서 CSQ의 장점은 거의 실시간으로 수신 상태를 확인할 수 있다는 점이고,
단점은 CSQF 대비 전력 소모가 늘어날 여지가 있다는 점, 그리고 실행시마다 신호를 탐색해야 하기 때문에 응답을 얻기까지 5초 전후의 대기 시간이 필요하다는 점이 있겠습니다..

결국 둘 다 장단점이 있기 때문에 상황에 맞춰 적절히 활용하시면 됩니다.

1. +SBDWT와 +SBDIX 명령 - 기기에서 서버로 메시지 전송하기

신호 수신 상태를 확인했으니 이제 모뎀에서 메시지를 전송해 보도록 하겠습니다.

데이터 전송은 먼저 버퍼 쓰기 명령으로 데이터를 메모리에 임시 보관한 다음, 적절한 시점에 접속 명령을 실행하여 보관되어 있던 메시지를 위성으로 보내는 순서로 진행됩니다.

AT+SBDWT=내용

우선, 데이터를 저장하기 위해 'AT+SBDWT=메시지'와 같은 형식으로 명령을 전송하시면 우선 MO 버퍼에 메시지가 저장되며, 문제가 없다면 모뎀이 'OK'라고 응답하는 것을 확인하실 수 있습니다.

여기서, MO 버퍼에는 메시지를 하나만 보관할 수 있으며, 이미 MO 버퍼에 메시지가 존재하는 상태에서 SBDWT를 실행하면 덮어쓰기가 이뤄진다는 점 유의하시기 바랍니다.

또한 SBDWT 명령어는 오직 ASCII 문자만 지원하므로, 한글 또는 문자가 아닌 데이터를 전송해야 하는 경우 SBDWB를 사용하여 바이너리 메시지 형태로 처리해야 합니다. (이 부분은 잠시 후 다뤄보겠습니다)

SBDIX 명령을 실행하고 응답받은 모습입니다.

다음으로 보관된 메시지를 전송하기 위해 'AT+SBDIX'를 입력하시고 수 초 정도(상황에 따라 5~10초 정도)를 기다리시면 통신 시도 결과가 출력됩니다.

제가 SBDIX를 실행한 화면을 보시면 '+SBDIX: 0, 1270, 0, 0, 0, 0' 과 같은 응답을 받은 것을 보실 수 있는데, 여기서 각 필드는 다음과 같이 구분하여 해석할 수 있습니다.

  +SBDIX: <MO status>, <MOMSN>, <MT status>, <MTMSN>, <MT length>, <MT queued>  

※ 용어 설명
MT : Mobile Terminated의 약자로 모바일 종료를 의미합니다. 말이 다소 어색한데, 모뎀을 기준으로 수신되는 메시지를 의미합니다.

MO : Mobile Originated의 약자로 모바일 발생을 의미합니다. MT의 반대이므로 모뎀에서 발송되는 메시지를 뜻합니다.
MSN : Message Sequence Number의 약자로 메시지의 순서를 구분하는 데 도움을 주기 위해 순서대로 부여되는 번호입니다.
MT length : MT 메시지의 바이트 단위 크기입니다.
MT queued : 게이트웨이에서 대기 중인 잔여 MT 메시지의 수를 나타냅니다.

아래는 MO, MT status의 값에 따른 의미입니다.

MO status:
0
- MO 메시지 전송됨.
1 - MO 메시지는 전송하였으나, 대기열의 MT 메시지는 수신하지 못함.
2 - MO 메시지는 전송하였으나, 위치 업데이트는 실패함.
MT status:
0 - 게이트웨이에서 수신한 MT 메시지 없음.
1 - 게이트웨이에서 성공적으로 메시지를 수신함.
2 - 게이트웨이로부터 메일함 확인 또는 메시지 수신 중 에러 발생.

그 외 SBDIX 응답값의 상세 설명은 아래 접은글에 원문 매뉴얼을 번역해서 올려드렸으니, 좀 더 정교한 제어가 필요하신 경우 읽어보시면 좋을 것 같습니다.

더보기

<MO status>:

MO 전송 처리 결과를 나타내며, 다음 결괏값을 가질 수 있습니다.

게이트웨이 보고값:
0 - MO 메시지가 있는 경우 전송 완료됨.
1 - MO 메시지가 있는 경우 전송 완료됨. 그러나 대기열의 MT 메시지는 너무 커서 수신하지 못했음.
2 - MO 메시지가 있는 경우 전송 완료됨. 그러나 위치 업데이트는 실패함 (주. SBDIX는 위치 등록도 함께 수행합니다)
3..4 - 사용되지 않음. MO 세션 성공함.
5..8 - 사용되지 않음. MO 세션 실패함.
10 - 사용되지 않음. 게이트웨이에서 데이터 콜이 허용 시간 내에 완료되지 않음.
11 - 게이트웨이의 MO 메시지 수신 대기열이 가득 차서 일시적으로 처리 불가 상태임.
12 - MO 메시지에 포함된 세그먼트가 너무 많음. (주. 여기서 말하는 세그먼트가 무슨 뜻인지는 모르겠습니다.. 아시는 분들은 댓글 남겨주시면 감사하겠습니다)
13 - 게이트웨이에서 세션을 처리하지 못함.
14 - 세그먼트 크기가 유효하지 않음.
15 - 액세스 거부됨.

모뎀 자체 보고값:
16 - 모뎀이 잠겨 있어 SBD 콜을 발신할 수 없음. (+CULK 명령어 참고).
17 - 게이트웨이가 응답하지 않음. (장비 자체 타임아웃).
18 - 연결 끊김 (전파 미도달).
19 - 연결 실패 (콜 종료 중 프로토콜 에러 발생).
20..31 - 사용되지 않는 값. 실패를 나타냄.
32 - 네트워크 신호 없음. 콜을 만들 수 없음.
33 - 안테나 결함. 콜을 만들 수 없음.
34 - 통신이 비활성화되어 콜을 만들 수 없음. (*Rn 명령어 참고).
35 - ISU is Busy. 콜을 만들 수 없음. (주. 백그라운드에서 자동 위치 등록 실행 중이면 발생한다고 합니다)
36 - 마지막 위치 등록 후 3분 후 재시도할 것.
37 - SBD 서비스가 일시적으로 비활성화됨.
38 - 트래픽 관리 기간이 지난 후 재시도 (+SBDLOE 명령어 참고)
39..63 - 사용되지 않는 값. 실패를 나타냄.
64 - 주파수 대역 제한 (허용 주파수 대역을 초과하는 주파수 발신 시도).
65 - PLL 잠금 실패; 발신 중 하드웨어 오류 발생.

<MOMSN>:
발신 메시지를 구분하기 위해 모뎀에서 할당하는 메시지 구분용 값입니다. 범위: 0~65535.

<MT status>:
MT 전송 처리 결과를 나타내며 다음 값을 가질 수 있습니다.

0 - 게이트웨이에서 수신한 MT 메시지 없음.
1 - 게이트웨이에서 성공적으로 메시지를 수신함.
2 - 게이트웨이로부터 메일함 확인 또는 메시지 수신 중 에러 발생.

<MTMSN>:
수신 메시지를 구분하기 위해 게이트웨이에서 할당하는 메시지 구분용 값입니다. <MT status>가 0이면 받은 메시지가 없는 세션이므로 이 필드를 사용하지 않습니다. 범위: 0~65535.

<MT length>:
게이트웨이로부터 수신한 메시지의 바이트 단위 크기를 나타냅니다. 수신한 메시지가 없는 경우 이 필드는 0입니다.

<MT queued>:
이리듐 가입자 단말로 전달 대기 중인 SBD 메시지의 수입니다.

응답 메시지에서 가장 중요한 부분은 역시 <MO(또는 MT) status>인데요, 지금은 메시지가 잘 보내졌는지가 궁금한 상황이니까 <MO status>가 0으로 표시되는지를 확인하시면 됩니다.

제 경우 태블릿의 화면을 보시면 앞선 두 번의 시도에서는 실패했다가, 세 번째 시도에서 성공적한 것을 확인하실 수 있습니다.

아파트 창틀에서 안테나만 내놓고 한거라 위성이 잘 안 보여서 그랬던게 아닌가 싶습니다.

메시지가 잘 들어왔습니다

모뎀의 응답을 확인한 후, 곧바로 관리자 페이지를 확인해보니 메시지가 잘 보내진 것을 확인할 수 있었습니다.

Delivery Groups 메뉴

이때, 매번 관리자 페이지를 확인하지 않고 수신되는 메시지를 자신의 서버로 자동 전달하고 싶다면 웹훅 메뉴얼 참고하셔서 서버 측에 데이터를 전달받기 위한 웹훅을 만들어 두시면 됩니다.

구축한 웹훅의 URL은 관리자 페이지의 'Delivery Groups' 메뉴에서 경우에 따라 HTTP_JSON 또는 HTTP_POST 포맷으로 등록할 수 있고, 이렇게 하면 모뎀으로부터 새로운 메시지가 수신될 때 Rock7 서버에서 실시간으로 이를 전달받을 수 있습니다. 

이외에도 위 사진에서 볼 수 있듯 웹훅 외에도 이메일 등 다양한 포맷을 지원하고 있으며, 중복 등록도 가능하니 상황에 맞춰 구성하시면 됩니다.
무려 SBD to SBD도 지원하는군요 ㄷㄷ

웹훅 사용시 유의하실 점은 Rock7의 아웃바운드 IP 주소인 109.74.196.135와 212.71.235.32를 웹훅 서버의 인바운드 허용 목록에 등록해 주셔야 한다는 것입니다. (방화벽을 사용 중인 경우)

1-1. +SBDWB 명령 - 바이너리 데이터 보내기

AT+SBDWB(Write as Binary) 명령은 바이너리 데이터를 그대로 MO 버퍼에 기록하는 명령으로, SBDWT가 ASCII 영숫자 및 기본 기호 영역만 지원하는 것과는 비교됩니다.

따라서 말씀드린 바와 같이, 한글 등 아스키 영역 외 문자나 커스텀 데이터의 전송이 필요하신 경우에 사용할 수 있습니다.

다만 SBDWB는 SBDWT에 비해 귀찮은 부분이 다소 존재하는데, 직접 테스트해 보기 위해서는 다음과 같이 준비해야 합니다.

  1. 전송하고자 하는 데이터를 16진수로 변환한다. (변환 사이트 또는 헥사 에디터 이용)
    예) 한글ABC123!@#  ED 95 9C EA B8 80 41 42 43 31 32 33 21 40 23 (예시는 UTF-8 인코딩)
  2. 데이터의 크기를 바이트 단위로 구한다.
    예) 15
  3. 데이터를 바이트 단위로 모두 더하여 체크섬을 구한다.
    이를 256으로 나누고 몫과 나머지를 차례로 구하면 1바이트씩 나눌 수 있다.
    예) ED+95+9C+EA+B8+80+41+42+43+31+32+33+21+40+23 = 06 20
  4. 데이터 뒤에 체크섬을 덧붙이면 준비 완료!
    예) ED 95 9C EA B8 80 41 42 43 31 32 33 21 40 23 06 20

그리고 SBDWB 또한 이미 MO 버퍼에 메시지가 존재하는 상태에서 실행하면 기존 메시지가 덮어씌워진다는 점도 참고하시기 바랍니다.

C언어로 구현한 뒤 실행한 모습입니다.

더보기
#include <stdio.h>
#include <string.h>

int main(void) {
    unsigned short int sum = 0;
    unsigned char data[] = {0xED, 0x95, 0x9C, 0xEA, 0xB8, 0x80, 0x41, 0x42, 0x43, 0x31, 0x32, 0x33, 0x21, 0x40, 0x23};
    unsigned len = strlen(data);
    
    for(int i = 0; i < len; i++) sum += data[i];
    
    printf("Message size : %d Byte(s)\n", len);
    printf("Checksum : %02x %02x\n", sum / 256, sum % 256);
    
    return 0;
}

보시다시피 3번이 가장 귀찮기 때문에 간편하게 구하실 수 있도록 간단한 체크섬 계산기를 만들어 보았습니다.

See the Pen IridiumSBDChecksumCalculator by capslock (@caps10ck) on CodePen.

체크섬까지 구하셨으면 이제 데이터를 전송해 보도록 하겠습니다.

SBDWB

먼저, 터미널에서 텍스트 모드로 ②에서 구한 크기를 이용하여
AT+SBDWB=데이터 길이
와 같이 명령을 보내어 모뎀에게 n 바이트의 바이너리를 보낼 예정임을 알립니다. (단, 1 ≤ n ≤ 340)

그리고 위와 같이 응답으로 "READY"(16진수로 52 45 41 44 59 0D 0A) 문자열이 돌아오면 모뎀 측에서도 데이터를 수신할 준비가 된 것입니다.

바이너리 전송

이제 바이너리(ASCII 인코디드 HEX 아님) 모드로 ④에서 준비한 체크섬이 붙여진 데이터를 보내야 합니다.

바이너리 전송 모드는 툴마다 차이가 있지만 대부분 존재하니 잘 확인해 보시고, 만약 본인이 사용 중인 터미널이 지원하지 않는다면 EBTerminal 사용을 추천드립니다.

파일 전송 모드가 있다면 헥사 에디터를 이용해 파일로 만들어 보내는 것도 방법입니다. (이 경우 ZModem 등의 프로토콜 없이 보내야 함)

<CR><LF> 또는 <CR> 등 별도의 개행 없이 only 체크섬을 포함한 데이터만 보내면 바로 다음과 같은 응답을 받을 수 있으며, 응답값은 다음과 같이 해석할 수 있습니다.

문자열: <CR><LF><응답값><CR><LF><CR><LF>OK<CR><LF>
16진수: 0D 0A <응답값> 0D 0A 0D 0A 4F 4B 0D 0A

0 (0x48) - 성공적으로 기록됨.
1 (0x49) - 60초 간 데이터가 입력되지 않아 취소됨. (타임아웃)
2 (0x50) - 체크섬이 일치하지 않음.
3 (0x51) - 메시지 크기가 잘못됨. MO 메시지의 최소 크기는 1바이트, 최대 크기는 340바이트임.

 

SBDTC

응답값이 0인 것까지 확인했으니 정말 제대로 들어갔는지 확인을 해봐야 할 텐데,

이를 위해서 AT+SBDTC 명령으로 MO 버퍼의 데이터를 MT 버퍼로 복사해 줍니다.

(좌) 폰에서 데이터를 읽어본 모습 (우) PC 터미널에서 바이너리로 읽어본 모습

그러고 나서 MT 버퍼의 내용을 바이너리로 읽어오는 AT+SBDRB 명령을 이용하면 보낸 데이터를 읽을 수 있습니다.

보시다시피 한치의 오차도 없이 그대로 기록된 것을 확인할 수 있네요 ㅎㅎ

마지막으로, 바이너리 메시지 전송 역시 AT+SBDIX를 이용하여 AT+SBDWT로 아스키 메시지를 보낼때와 동일하게 진행할 수 있습니다.
## 211002 17:46 - 1003 09:27

2. Rock7 MT API - 서버에서 모뎀으로 메시지 보내기

MO 메시지 발송까지 해봤으니, 이번에는 인터넷으로 MT 메시지를 보내고 모뎀에서 수신해 보겠습니다.

모뎀으로 데이터를 보내는 방법에는 여러 가지가 있으나, 개발할 때 쉽고 간단하게 적용 가능하다고 생각되는 Rock7 API를 이용하는 방법으로 설명드리도록 하겠습니다.

MT API URL은 https://rockblock.rock7.com/rockblock/MT 이고, POST 메소드로 다음 파라미터를 폼 인코딩으로 전송하시면 됩니다.

※ 파라미터 설명
username - 로그인 시 사용하는 이메일 주소입니다.
password - 로그인 시 사용하는 비밀번호입니다.
imei - Rock7 계정에 등록된 모뎀 중 메시지 발송을 원하는 모뎀의 IMEI를 지정합니다.
data - 16진수로 인코딩 된 데이터입니다. 데이터를 그대로 첨부하는 것이 아니라, 16진수를 나타내는 ASCII 문자(0~F)를 사용하여 나타낸다는 것에 주의합니다.
flush (옵션) - MT 대기열에서 전송 대기 중인 메시지들을 삭제합니다. 필요한 경우에만 'yes' 를 넣어 호출하고, 그렇지 않은 경우에는 이 파라미터 자체를 포함하지 않습니다.

위 스크린샷은 API 테스트 프로그램이고, 실제 코드상에서 구현하는 방법은 2부에서 상세히 다뤄보겠습니다.

아래는 웹으로 구현한 API 호출 툴입니다.

data 필드에 영숫자나 한글 등 문자열을 바로 넣고 호출하고 싶다면 입력 후 16진수 변환을 켜면 되고,
호출 후 결과 화면에서 초기 화면으로 돌아가려면 오른쪽 하단의 'Rerun' 버튼을 누르면 됩니다.

개발자 도구로 확인해 보시면 아시겠지만 위 툴의 모든 입력값은 별도의 서버를 거치지 않으며, 브라우저 단에서 곧바로 Rock7 서버로 전송되니 안심하셔도 됩니다.

API 호출 결과 넣어준 값들에 문제가 없으면 다음과 같은 형식의 응답을 받을 수 있고,
OK,XXXXXX
에러가 발생했다면 다음과 같은 형식의 응답을 받을 수 있습니다.
FAILED,에러코드,설명

발생 가능한 모든 에러코드와 그 설명은 다음과 같습니다.

이후 API 호출에 성공했다면 이리듐 게이트웨이에서는 전송한 메시지를 임시 보관하게 됩니다.

그리고 모뎀의 마지막 등록 위치를 이용하여 해당 지역을 지나는 이리듐 위성을 통해 메시지 도착 알림을 지상으로 전송하고, 실제 메시지 본문은 이후 모뎀이 위성에 접속(SBDIX)할 때 전달하게 됩니다.

이 메시지 알림은 수신 여부가 확인되지 않는 단방향 채널을 통해 브로드캐스트되고, 별도의 처리가 없는 한 기본적으로 첫 번째 알림 이후 20초 후에 두번째이자 마지막으로 한번 더 알림이 발송된다는 특징이 있습니다.

또한, 모뎀은 위성으로부터 이러한 알림 신호를 수신하면 'SBDRING'이라는 문자열을 시리얼 포트로 출력하여 사용자, 또는 프로그램이 이를 인지할 수 있도록 하고 있습니다.

하지만 알림을 모두 받지 못하면(전원 꺼짐, 터널 등 음영지역으로) 모뎀에서 직접 MO 메시지 없이 SBDIX 명령을 실행하여 확인하는 방법밖에 없으니 유의하셔야 합니다. (심지어 받을 메시지가 없다면 이것도 MO 메시지 발송으로 간주하여 크레딧을 깎습니다 ㄷㄷ)

통신 흐름 : 장비 ↔ 이리듐 모뎀 ↔ 안테나 ↔ 위성(들) ↔ 게이트웨이 ↔ 국사내 SBD 서버 ↔ 고객 서버

아무튼, 저는 테스트를 위해 "Testing Rockblock MT API!" 라는 메시지를 작성하여 직접 API를 호출해 봤습니다. 

그리고 모뎀으로 알림 신호를 받을 수 있었는데, 직접 재어 보니 API 호출 후 늦어도 약 20초 정도면 받을 수 있는 것 같았습니다.

SBDRING 알림이 수신되었습니다.

안테나를 내놓고 기다리니 잠잠하던 터미널 화면에 'SBDRING'이라는 문자열이 표시됐습니다.

이 문자열이 시리얼 포트로 들어오는게 확인되면 AT+SBDIX를 실행하여 메시지를 수신하면 되는데요,

이때 MO 버퍼에 발신 대기중인 메시지가 존재한다면 해당 SBD 세션에서 MO 발송 및 MT 수신 처리를 동시에 진행하게 된다는 점도 참고하시기 바랍니다.

즉, 메시지 수신을 위한 명령과 발송을 위한 명령을 별도로 구분하고 있지는 않는 것이죠.

데이터가 수신되었습니다!

SBDIX 응답 메시지에서 <MT status> 필드가 1인 것까지 확인하였다면 메시지를 성공적으로 수신한 것으로, AT+SBDRT(Read Text) 명령어로 MT 버퍼에 보관된 데이터를 출력할 수 있습니다.

이때, 만약 수신할 데이터가 ASCII 문자열이 아니라면 AT+SBDRB(Read as Binary) 명령을 사용하셔야 원본 데이터를 온전히 불러올 수 있습니다.

마지막으로 <MT status> 필드가 2인 경우에는 다운로드에 실패했다는 의미이므로 다시 시도하셔야 합니다.

## 201024 추가: SBDRING 알림 수신 후 위성에 접속할 때의 주의사항입니다. ##

Page 47, ISU AT Command Reference


사용자가 SBDRING 알림을 수신한 후 이를 처리하기 위해 SBD 세션을 만들려는 경우 AT+SBDIX 대신 AT+SBDIXA를 사용해야 두 번째로 오는 SBDRING 알림을 취소할 수 있다고 합니다.

AT+SBDIX는 잔여 알림 발송을 취소하지 않기 때문에 'SBDRING'이 감지될 때 메시지 다운로드를 시도하도록 프로그램을 작성하실 경우 유의하셔야 할 내용입니다.
## 201024 추가 끝 ##

3. 네트워크 등록(위치 등록)의 개념과 필요성

허전해 보여서 넣은 그림

다음은 모뎀의 위치 등록에 관한 이야기입니다.

바로 위에서 보셨듯 이리듐 모뎀에는 메시지를 언제 수신해야 할 지 알려주기 위해 위성의 ring alert 신호를 받아 시리얼로 알림을 보내주는 기능이 존재합니다.

여기서 중요한 점은 모뎀측의 메시지 발송과 달리 위성측 ring alert 발송의 경우 위성은 모뎀과 마지막으로 통신이 이루어졌던 위치로 발송할 수 밖에 없다는 점인데요,

왜 그런가 하면 모뎀은 위성과 상시 연결되어 있는 것이 아니라, 데이터를 송수신하는 시점에만 접속하기 때문에 모뎀의 위치가 변경되어도 위성은 그 사실을 알 방법이 없기 때문입니다.
그래서 이러한 문제를 해결하기 위해 모뎀에는 별도의 MO 메시지 발송 없이 자신의 현재 위치만 업데이트할 수 있는 기능이 존재하며, 이를 네트워크 등록(Network Registration) 또는 간단히 위치 등록이라고 합니다.

이러한 네트워크 등록은 별도의 GPS 모듈이나 좌표값 인자 없이 단순히 AT+SBDREG 명령을 실행하기만 하면 되는데, 이는 이리듐 위성이 내장된 스팟 빔 안테나(위 그림에서 하단에 부착된 주황색 부품)로 대략적인 신호의 발신지를 파악하여 위경도 값을 도출하기 때문입니다. (따라서 SBDIX 명령 실행시에도 메시지 송수신과 함께 위치 업데이트가 이뤄지긴 합니다)

이 명령을 실행했을 때의 응답으로 '+SBDREG:2,0' 을 받으신 경우 등록된 것이며 이외의 값은 통신에 실패했다고 보시면 되고, 위치 등록 명령의 재실행 최소 주기는 3분 입니다.

그리고 추정한 위치의 위경도 값과 최대 예상 오차 거리는 Rock7 서버로부터 MO 수신 시 'iridium_cep' 필드에 제공되고 있으니 참고하시기 바랍니다. (단위는 km)

## 201024 추가 : 위치 재등록이 권장되는 최소 이동거리에 대한 내용입니다. ##

Page 51, ISU AT Command Reference

전원을 끈 상태에서 150km 이상의 거리를 이동한 경우(전원은 켜져 있지만 위치 등록을 하지 않은 경우도 해당할 것 같습니다), SBD Ring Alert를 안정적으로 수신하기 위해서는 위치 재등록이 권장된다고 합니다.
## 201024 추가 끝 ##

1부만 했는데도 많이 길어졌네요..
모뎀 구입과 기본적인 명령어 사용법은 이쯤에서 끝내도록 하겠습니다.
긴 글 읽어주셔서 감사합니다.

※ 궁금하신 점이나 수정이 필요한 부분이 있다면 댓글로 알려주시면 감사하겠습니다!