본 포스팅에서 다뤄볼 내용은 NMEA-0183 문장의 checksum 계산 방법이다.

보통 GPS chip은 해석한 GPS신호를 NMEA라는 특정 형태의 프로토콜로 제공한다.

NMEA 가 무엇인지에 대해서 더 자세히 알고싶다면 아래 포스팅을 참고하도록 하자.

2017/08/10 - [하드웨어 Note/GPS 이야기] - [GPS 이야기] NMEA-0183 형식, NMEA Sentence Format

위 포스팅에 나와있듯이, NMEA sentence는 $ 문자로 시작해서 * 문자로 끝난다.

checksum의 계산은 $, * 의 사이에 있는 각각의 문자 하나하나를 exclusive-or (XOR) 연산 및 누적하면 된다.

어떤 NMEA sentence가 주어졌을 때, "*" 뒤에 있는 16진수 두자리의 checksum도 같이 주어질 텐데, 직접 XOR연산하여 checksum을 계산한 값과 주어진 checksum값이 일치하는지를 검사해야 한다. 일치하지 않는다면, 그 sentence는 통신상의 문제 등의 이유로, 결함이 있는 것으로 간주해야 하며, 사용하면 안된다. 

구체적인 계산 예제 코드를 제시한다.

NMEA 체크섬 계산 함수(JAVA 버전)

char checkSum(String nmeaStr) {
  char check = 0;
  // iterate over the string, XOR each byte with the total sum:
  for (int c = 0; c < theseChars.length(); c++) {
    check = char(check ^ theseChars.charAt(c));
  } 
  // return the result
  return check;
}

인자 'nmeaStr' 은 $와 * 사이의 NMEA문자열을 넣으면 된다. 각 문자 하나하나를 XOR연산하여 'check' 변수에 저장하여 반환한다.

return type은 char 이다. 이것을 2bytes hex string으로 변환해서 사용하면 된다.

NMEA 체크섬 계산 함수 (C 버전 1)

#include <stdint.h>

#define NMEA_END_CHAR_1 '\n'
#define NMEA_MAX_LENGTH 70

uint8_t
nmea_get_checksum(const char *nmea_str)
{
    const char *n = NULL;
    uint8_t chk = 0;
    if (strcmp(nmea_str[0], '$') == 0) {
        n = nmea_str + 1; // skip '$' by plus one
    } else {
        n = nmea_str;
    }

    /* While current char isn't '*' or sentence ending (newline) */
    while ('*' != *n && NMEA_END_CHAR_1 != *n) {
        if ('\0' == *n || n - sentence > NMEA_MAX_LENGTH) {
            /* Sentence too long or short */
            return 0;
        }
        chk ^= (uint8_t) *n;
        n++;
    }

    return chk;
}

인자 nmea_str은 $와 * 사이의 NMEA sentence를 넣으면 된다. 그러나 만약 인자로 들어오는 NMEA sentence가 $ 를 포함하고 있다면 생략하도록 방어코드를 넣어 두었다.

이제, checksum 값은 아래와 같이 계산하면 된다.

GPRMCBuf 가 NMEA sentence이다.

uint8_t chk = nmea_get_checksum(GPRMCBuf);

NMEA 체크섬 계산 함수 (C 버전 2)

또다른 방법으로 NMEA의 checksum 계산을 구현한 C언어 버전이다. 

첫번째 인자 'buf'가 계산하려는 NMEA sentence이다. 위의 버전1과는 달리 $ 부터 * 까지의 NMEA sentence를 인자로 넣어도 된다. 

두번째 인자 'len'는 buf의 길이이다.

int calc_NMEA_Checksum( char *buf, int len )
{
    char Character;
    int Checksum = 0;
    int i;              // loop counter

    // foreach(char Character in sentence)
    for (i=0; i < len; ++i)
    {
        Character = buf[i];
        switch(Character)
        {
            case '$':
                // Ignore the dollar sign
                break;
            case '*':
                // Stop processing before the asterisk
                i = len;
                continue;
            default:
                // Is this the first value for the checksum?
                if (Checksum == 0)
                {
                    // Yes. Set the checksum to the value
                    Checksum = Character;
                }
                else
                {
                    // No. XOR the checksum with this character's value
                    Checksum = Checksum ^ Character;
                }
                break;
        }
    }

    // Return the checksum
    return Checksum;
}

이 함수를 통해 checksum을 계산하면 int 형 결과가 반환된다.

이제, 비교하려는 NMEA sentence에서 2bytes의 char형 checksum 문자를 읽고, 1byte의 hex형으로 변환 한 후, 위 함수의 반환값과 비교하면 된다.

만약 당신이 GNSS와 직접적으로 관련된 일을 한다면.

혹은 간접적으로 GPS등과 같은 것을 통해 얻은 위치정보등을 다뤄야 할 일이 있다면.

조만간 'NMEA' 라는 것을 마주하게 될 수도 있다.

위치정보라는것은 어떤 목적으로 활용하느냐에 따라 다뤄야 하는 데이터는 달라진다.  

현재 위치에 기반하여 날씨정보를 보여주는 어플리케이션처럼 간단히 위도, 경도만 알면 되는 경우가 있는가 하면,

목적지까지 경로를 알려주는 내비게이션 어플리케이션처럼 때로는 위도, 경도 뿐만아니라 속도, 위치정확도 오차값, 방향.. 등을 알아야 하는 경우도 존재 한다.

또한 종종 등산 트래커 어플리케이션처럼 고도를 활용하는 경우도 있다. 사실 고가의 GPS가 아닌 이상, 스마트폰과 같은 저렴한 GPS칩이 주는 고도값은 부정확하다고 알려져있다.

그리고 이 와중에, NMEA라는 것이 있다. 자세히는 몰라도 되는 것이지만, 알면 도움이 될 수도 있다. (알면 좀 있어보이기도 한다.) 

이 포스팅에서는 NMEA란 무엇이고, NMEA데이터를 해석하기 위해 알아야 할 내용들을 간략히 다루어 보겠다.

NMEA의 개념정도를 잡아보자는 생각으로 가볍게 읽어보자.

지구에서 보이는 위성의 개수 이해하기

NMEA 개요

NMEA는 'National Marine Electronics Association'의 앞글자를 딴 약자이다.

해양 전자공학 산업의 발달과 교육을 위해 모인 비영리 단체를 지칭한다.

그리고 NMEA 표준은 ”해양 전자 장비 기자재들 간의 통신을 위해 정의된 전기적 인터페이스 및 데이터 프로토콜” 이라고 정의할 수 있다.

해양 전자 장비 기자재들 간의 통신을 위해 정의된 전기적 인터페이스 및 데이터 프로토콜

NMEA에서는 몇가지 프로토콜을 정의 했는데, 현재 GPS통신에서는 'NMEA-0183'을 표준 프로토콜로 사용하고 있다.

표준을 관리하는 NMEA의 웹사이트는 http://www.nmea.org 이니 알아두도록 하자.

NMEA 들여다보기

NMEA Sentence 기본 형태

먼저 어떤 모양인지 보자. NMEA는 아래와 같은 형태로 되어있다.

GNSS에서는 언제 NMEA-0183을 사용하는가?

위성신호를 해석해낸 GPS수신기가 해석한 정보를 외부에 알리는데 사용하는 방법이다.

GPS측위가 시작되면 GPS위성으로부터의 반송파에 실려오는 데이터를 GPS수신기는 해석을 할텐데, 해석되는 내용을 알려주는 방식이라고 이해하면 쉽다.

GPS수신기는 이와 같은 내용을 1초 ~ 수초마다 Serial 출력의 형태로 내보낸다.

위의 예를 보면 '$' 라는 문자로 시작되는데, 이렇게 $로 시작되는 각각의 한줄을 'NMEA Sentence' 혹은 'NMEA 문장' 이라고 부른다.

이 그림은 GPS수신기가 GPS위성 시스템으로부터 반송파를 받아 해석한 후, NMEA 문장(혹은 NMEA 메세지)으로 내보내는 과정을 보여주고 있다. 

NMEA메세지는 기본적으로 정보나 데이터의 패킷이다. 

GPS수신기는 해석된 각각의 정보를 이 NMEA메세지를 한줄 한줄 내보내는데, 이 NMEA메세지는 여러 타입으로 분류된다. 각 NMEA메세지는 타입에 따라 고유한 프로토콜을 가지고 있다. 따라서, 타입을 먼저 파악 한 후, 그에 맞는 프로토콜로 해석을 해야 한다. 타입은 NMEA메세지의 'Device ID'와 'Sentence ID'라고 불리는 첫 5글자를 읽어서 파악할 수 있다.

보다 더 자세한 내용은 아래에서 설명한다.

NMEA Sentence 구성요소

그럼 NMEA Sentence의 구성요소를 알아보자.

$GPRMC,141114.999,A,3730.0264,N,12655.2351,E,15.51,202.12,101200,,*3C

이 문장을 다시 보자.

문장의 시작을 의미하는 $ 보이고, GP라는 Device ID(Talker ID)를 가지고 있으며, RMC라는 Sentence ID(Sentence Name)을 가지고 있다.

맨 마지막에 붙는 '3C'는 checksum값이다. 두자리 16진수 이다. 데이터가 올바르게 전달 되었는지 확인하는 용도이다.

checksum 계산 방법은 아래부분에서 다루도록 하겠다.

자, 색상으로 칠해진 부분은 이제 읽을 줄 알게 되었다.

가운데 검은색 부분은 어떻게 읽으면 되는지 알아보자. 어떻게 읽는지는, Sentence ID에 따라 달라진다.

참고로, 통상적인 GPS 수신기에서는 몇가지 Device ID만 제한적으로 출력된다.

GPGGA

GPGGA는 'Global Positioning System Fix Data'를 의미한다.  아래의 GPGGA 예제 sentence를 살펴보자.

GPGGA는 총 17개의 field를 가진다. 

참고로 예제에서는 12 ~ 15 필드는 비어 있다.

그리고, 17번 필드는 그림에서는 보이지 않는데, 그 이유는 Terminator문자인 CR/LF 이기 때문이다.

NMEA-0183 GPGGA 문장의 예

몇가지 부연설명을 하고자 한다.

10번의 고도값이 있는데, 이는 생각보다 부정확하다. 일반적으로 GPS는 수평오차보다 수직오차가 크다고 알려져있다. 간단하게 말하면 위성이 우리의 발 밑에는 없고 전부 머리 위에 있기 때문으로 이해하면 될 것같다. 즉, 고도 값 자체를 너무 신뢰하지는 말아야 한다.

12번에서 언급하는 Geoid와 WGS-84 타원체는 좌표에 대해 다루면서 좀 더 자세히 알아보겠다. GPS에서 등장하는 경도, 위도 좌표는 모두 WGS-84 타원체를 기준으로 하고 있다고만 알아두자.

GPRMC

문서에 의하면 GPRMC는 'Recommended Minimum Specific GNSS Data'로 정의되어있다. 

NMEA에는 GPS에서 필수적인 PVT(Position, Velocity, Time) 데이터의 고유한 버전이 있다. 

그것을 RMC라고 부른다. 'RMC'에서 RM이 Recommended Minimum의 약자이고, C는 GNSS를 의미한다. RMA, RMB도 있으며 각각 LORAN-C와 Navigation을 의미한다. 상식으로 알아두자.

아래와 같은 형태이다.

NMEA-0183 GPRMC 문장의 예

GPGSA

문서에 의하면 GSA는 "GNSS DOP and Active Satellite"를 의미한다고 되어있다. GSA는 단독으로 쓰이기 보다는 GSV와 조합해서 위성상태를 확인하거나 Graphical하게 천공도를 그리는데 사용될 수 있다.

NMEA-0183 GPGSA 문장의 예

4번부터 15까지는 수신기에 잡힌 GPS위성의 번호가 나와 있다. 일반적으로 12채널 GPS수신기라고 말하면 위성신호를 12개 까지 수신할 수 있다는 의미이다. GPS위성 전용 수신기는 12채널이면 충분하며, 사실 그 이상은 의미가 없다. 왜냐하면, GPS위성은 총 24개가 배열되어 있고, 지표면상에서는 12개 이상의 위성은 보이지 않도록 각 위성의 궤도를 설정하기 때문이다. 물론, 높은 하늘에서라면 이야기가 달라진다. 지표면에서 사용하는게 아닌, 항공기나 전투기 등에서 사용하는 GPS수신기는 12채널 이상이어도 의미가 있다는 얘기. 

그런데 예외가 있다. GPS 뿐만 아니라, GLONASS, Baidu, Galieo 위성 등 위치 측위에 사용할 수 있는 위성들이 여럿 존재한다. 이들 모두을 동시에 수신할 수 있는 수신기의 경우에는 또 이야기가 달라진다. 비글보드, 라즈베리파이 등에 붙여서 자주 사용되는 제품중에 'Adafruit Ultimate GPS breakout' 이란 것이 있는데, 66채널 수신이 가능한 제품이다. 

Link : https://www.adafruit.com/product/746

또한 참고로, NMEA sentence상에서 수신되지 않은 위성의 자리는 NULL처리되어 있다.

16번부터 18까지는 위성의 측위 오차에 관한 항목이다. 

수신기에서 4개이상의 위성이 감지되더라도 수신기는 PDOP이 최소인 위성 4개의 배열을 잡아 위치를 계산해 낸다. 

 PDOP은 수신기 위치를 꼭지점으로 각각의 위성이 이르는 사각뿔의 체적에 반비례한다. 체적이 큰 경우가 측위 오차가 적게 되는데 이는 위성이 널리 퍼져 오차가 상쇄되기 때문으로 이해하면 될 것이다. 수직방향은 그러한 상쇄되는 면이 없기 때문에 (위성은 전부 하늘에 있다.) 수평오차보다 크게 된다.

 VDOP은 수직오차를 HDOP은 수평오차를 말한다. PDOP = Sqrt(HDOP*HDOP + VDOP*VDOP)의 관계가 성립한다. 최적값은 1.0으로 대개 6이하면 쓸만하다고 보면 된다.

사실 전문가가 아니면 크게 필요없는 내용이다. 더 자세한 내용을 알고자 하면 인터넷에서 검색해보기 바란다. 상당히 많은 내용이 나와 있을 것이다.

GPGSV

GSV는 'GNSS Satellite in View' 를 의미한다. 각각 위성의 상태에 대해 나와있는 문장이다.

아래와 같은 모양이다.

NMEA-0183 GPGSV 문장의 예

그런데, GSV를 해석할 때 유의할 점 한가지가 있다.

GSV는 한 문장에 4개의 위성에 대한 정보만을 가진다. 따라서 만약 총 12개의 위성을 수신 중인 상황 에는 GPGSV문장이 3개 연속으로 등장하게 된다. 만약 7개의 위성을 수신 중인 상황에서는 GPGSV문장이 2개 연속으로 등장하게 될 것이다.

NMEA checksum 계산방법 및 예제코드

지금까지 예제로 보여준 NMEA sentence들을 살펴보면 알겠지만, checksum은 * 뒤에 16진수 두자리로 표시한다.

checksum의 계산은 $, * 의 사이에 있는 각 문자를 exclusive-or (XOR) 연산한 값을 표시한다.

어떤 NMEA sentence가 주어지면, "*" 뒤에 있는 16진수 두자리의 checksum과 직접 XOR연산한 값이 일치하는지를 검사해야 한다. 일치하지 않는다면, 그 sentence는 통신상의 문제 등의 이유로, 결함이 있는 것으로 간주해야 하며, 사용하면 안된다. 

예를 들어보자.

이와 같은 NMEA sentence가 주어졌을때, checksum계산을 위한 XOR연산은 아래 각 문자들에 대해서 수행하면 된다.

Checksum 계산 하는 코드는 다음 포스팅을 참고하기 바란다.

2017/08/26 - [하드웨어 Note/GPS 이야기] - [NMEA-0183] Checksum 계산 예제코드 (How to calculate checksum of NMEA-0183)

NMEA Sentence ID (Sentence Name) 목록

아래는 NMEA Sentence의 모든  ID와 그것이 어떤 것을 의미하는지를 나열 한 것이다.

또한, 첨부파일을 참고해도 좋다.

nmea_0183_identifier_list(20130801).pdf

여기까지 읽었으면, GPRMC, GPGGA, GPGSA, GPGSV 이렇게 4개 설명하는데도 상당한 양이라는 것을 알 것이다. 따라서 모든 내용을 다루기엔 무리가 있다.

각 항목 하나하나의 자세한 설명은 본 포스팅에서는 더이상 하지 않기로 한다.

우선 각 코드들의 의미 정도만 파악해 보고, 자세한 내용은 추후에 기회가 된다면 다뤄보겠다.

$GPAAM - Waypoint Arrival Alarm
$GPALM - GPS Almanac Data
$GPAPA - Autopilot format "A"
$GPAPB - Autopilot format "B"
$GPASD - Autopilot System Data
$GPBEC - Bearing & Distance to Waypoint, Dead Reckoning
$GPBOD - Bearing, Origin to Destination
$GPBWC - Bearing & Distance to Waypoint, Great Circle
$GPBWR - Bearing & Distance to Waypoint, Rhumb Line
$GPBWW - Bearing, Waypoint to Waypoint
$GPDBT - Depth Below Transducer
$GPDCN - Decca Position
$GPDPT - Depth
$GPFSI - Frequency Set Information
$GPGGA - Global Positioning System Fix Data
$GPGLC - Geographic Position, Loran-C
$GPGLL - Geographic Position, Latitude/Longitude
$GPGRS - GPS Range Residuals
$GPGSA - GPS DOP and Active Satellites
$GPGST - GPS Pseudorange Noise Statistics
$GPGSV - GPS Satellites in View
$GPGXA - TRANSIT Position
$GPHDG - Heading, Deviation & Variation
$GPHDT - Heading, True
$GPHSC - Heading Steering Command
$GPLCD - Loran-C Signal Data
$GPMSK - Control for a Beacon Receiver
$GPMSS - Beacon Receiver Status
$GPMTA - Air Temperature (to be phased out)
$GPMTW - Water Temperature
$GPMWD - Wind Direction
$GPMWV - Wind Speed and Angle
$GPOLN - Omega Lane Numbers
$GPOSD - Own Ship Data
$GPR00 - Waypoint active route (not standard)
$GPRMA - Recommended Minimum Specific Loran-C Data
$GPRMB - Recommended Minimum Navigation Information
$GPRMC - Recommended Minimum Specific GPS/TRANSIT Data
$GPROT - Rate of Turn
$GPRPM - Revolutions
$GPRSA - Rudder Sensor Angle
$GPRSD - RADAR System Data
$GPRTE - Routes
$GPSFI - Scanning Frequency Information
$GPSTN - Multiple Data ID
$GPTRF - TRANSIT Fix Data
$GPTTM - Tracked Target Message
$GPVBW - Dual Ground/Water Speed
$GPVDR - Set and Drift
$GPVHW - Water Speed and Heading
$GPVLW - Distance Traveled through the Water
$GPVPW - Speed, Measured Parallel to Wind
$GPVTG - Track Made Good and Ground Speed
$GPWCV - Waypoint Closure Velocity
$GPWNC - Distance, Waypoint to Waypoint
$GPWPL - Waypoint Location
$GPXDR - Transducer Measurements
$GPXTE - Cross-Track Error, Measured
$GPXTR - Cross-Track Error, Dead Reckoning
$GPZDA - UTC Date / Time and Local Time Zone Offset
$GPZFO - UTC & Time from Origin Waypoint
$GPZTG - UTC & Time to Destination Waypoint

참고 [GNSS, NMEA-0183(National Marine Electronics Association) Format 쉽게 설명] : http://joongyup.egloos.com/9173927

참고 [Glenn Baddeley - GPS - NMEA sentence information] : http://home.mira.net/~gnb/gps/nmea.html

참고 : [NMEA data] http://www.gpsinformation.org/dale/nmea.htm

이 글이 도움이 되었다면 아래 '공감' 버튼 콕!

여기서는 GPS에 대해 이야기를 해볼까 합니다.

GPS는 Global Positioning System의 약자인 것은 널리 알려진 내용인데요.

오늘은 GPS의 이야기를 시작하기에 앞서, 몇가지 용어를 알아볼까 해요.

TTFF

TTFF(Time To First Fix)란 GPS 수신기의 전원을 켰을 때 GPS 수신기가 현재 위치를 파악하는 데까지 소요되는 시간을 뜻하며, 상황에 따라 Factory Start, Cold Start, Warm Start, Hot Start로 구분됩니다.

TTFF를 이해하기 위해서는 먼저 Almanac 데이터와 Ephemeris 데이터에 대하여 이해할 필요가 있습니다.

지상의 여러 부 관제국에서 GPS 위성신호를 항시 관측하여 그 데이터를 주 관제국으로 보내고, 주 관제국에서는 그 데이터를 토대로 Almanac 데이터와 Ephemeris 데이터를 작성하여 일정주기로 각 GPS 위성으로 보내며, 이는 다시 GPS 위성신호 중 항법 메시지에 포함되어 지상의 각 GPS 수신기로 송신됩니다.

Almanac 데이터

Almanac 데이터는 GPS 위성배치의 개략적인 궤도 파리미터 정보이며, 몇달에 한번씩 갱신됩니다.

GPS 수신기는 Almanac 데이터를 통해 특정 시각의 특정 지점에서 어떤 위성들의 신호를 수신할 수 있는지 미리 파악할 수 있기 때문에 보다 신속하게 자기 위치를 계산할 수 있습니다.

각 위성별로 모든 위성의 Almanac 데이터를 2분 30초 동안에 전송완료 하며, 지속적으로 이를 재전송합니다.

GPS 수신기가 Almanac 데이터를 가지고 있지 않으면 데이터 전체를 수신하며, Almanac 데이터를 가지고 있되 일부가 최신 데이터가 아니면 해당 부분만 수신합니다.

Ephemeris 데이터

Ephemeris 데이터는 GPS 위성의 아주 정교한 궤도 및 시각보정 정보이며, 매 5시간마다 새로이 갱신됩니다.

GPS 수신기는 Ephemeris 데이터를 통해 정밀하게 자기 위치를 파악할 수 있습니다.

각 위성별로 해당 위성의 Ephemeris 데이터를 30초 동안에 전송완료 하며, 지속적으로 이를 재전송합니다.

GPS 수신기가 특정 위성의 가장 최신의 Ephemeris 데이터를 가지고 있지 않으면 해당 위성의 가장 최신의 데이터 전체를 수신하는데, GPS 수신기의 전원을 켰을 때 Ephemeris 데이터의 중간부터 수신하기 시작하였다면 다음번 전송 주기에 처음부터 끝까지 전체를 수신하며, 수신과정에서 일시적으로 수신이 끊어진 경우에도 다음번 전송 주기에 다시 전체를 수신합니다.

GPS 수신기는 최신의 Almanac 데이터를 통해 어떤 위성들의 신호를 수신할 수 있는지 미리 파악하고, 최신의 Ephemeris 데이터를 수신한 위성들 중 한 위성으로부터 신호를 받아 위성들과의 시각동기를 이루고, 다른 2개 이상의 위성들로부터 신호를 받아 각 위성들까지의 거리를 측정하여 자기 위치를 파악하는 것입니다. 이 때, 2개 위성에 대하여 거리를 측정하면 지구타원체(WGS84)상의 경위도 좌표값만 구할 수 있고, 3개 이상의 위성에 대하여 거리를 측정하면 지구타원체(WGS84)상의 경위도 좌표값 및 타원체고를 구할 수 있으며, 이 타원체고는 표준 지오이드 모델을 바탕으로 해발고로 환산되어 표현됩니다.

TTFF는 Almanac 데이터와 Ephemeris 데이터의 수신 여부에 따라 Factory Start, Cold Start, Warm Start, Hot Start로 구분할 수 있습니다.

Factory Start

Factory Start는 전원을 켠 후, 위성신호로부터 Almanac 데이터 전체와 신호가 수신되는 위성 중 최소 3개 이상의 위성으로부터 각각의 Ephemeris 데이터 전체를 수신하여 위치를 파악하는 데 소요되는 시간으로 대략 15분 정도입니다.

GPS 수신기가 공장에서 출고될 때에는 특정 시점의 Almanac 데이터 전체와 각 위성의 Ephemeris 데이터 전체가 입력되어 있습니다.

GPS 수신기를 그 시점보다 수개월이 지난 시점에 처음 사용하거나 사용했던 GPS 수신기를 끈 후, 수개월간 사용하지 않다가 다시 사용하는 경우가 이에 해당됩니다.

Cold Start

Cold Start는 전원을 켠 후, 위성신호로부터 Almanac 데이터 일부와 신호가 수신되는 위성 중 최소 3개 이상의 위성으로부터 각각의 Ephemeris 데이터 전체를 수신하여 위치를 파악하는 데 소요되는 시간으로 대략 30초에서 1분 30초 정도입니다.

사용했던 GPS 수신기의 전원을 끈 후, 수십일 동안 사용하지 않다가 다시 사용하는 경우가 이에 해당됩니다.

Warm Start

Warm Start는 전원을 켠 후, 신호가 수신되는 위성 중 1~2개의 위성으로부터 각각의 Ephemeris 데이터 전체를 수신하여 위치를 파악하는 데 소요되는 시간으로 대략 10초에서 40초 정도입니다.

사용했던 GPS 수신기의 전원을 끈 후, 수시간 이내 다시 사용하는 경우가 이에 해당됩니다.

* 참고 : Cold Start는 신호가 수신되는 위성들 중 대다수가 Ephemeris 데이터의 갱신이 있었던 경우이고, Warm Start는 신호가 수신되는 위성들 중 일부만 Ephemeris 데이터의 갱신이 있었던 경우입니다.

Hot Start

Hot Start는 새로운 데이터의 수신없이 위치를 파악하는 데 소요되는 시간으로 대략 3초에서 20초 정도입니다.

사용했던 GPS 수신기의 전원을 끈 후, 수분 이내 다시 사용하는 경우와 GPS 수신기 사용 중 장애물(건물, 터널 등)에 의해 일시적으로 위성신호를 수신하지 못하여 위치파악을 하지 못하다가 다시 위성신호를 수신하게 된 경우가 이에 해당됩니다.

GPS 단말기의 위성화면에는 대부분 2개의 동심원이 그려져 있는데 이 중 바깥쪽 원은 현위치 기준의 평면(수평선)을 표시하는 것이고, 안쪽 원은 현위치 기준의 고도각 45도 영역을 표시하는 것입니다.

GPS 수신기는 Almanac 데이터를 바탕으로 위성화면 동심원에 각 위성들의 위치를 표시합니다.

그리고 위성화면 하단에서 막대 그래프의 길이는 각 위성들의 신호강도를 표시하는 것이고, 막대 그래프의 색깔은 Ephemeris 데이터의 활용가능여부를 나타냅니다.

현재 저장되어 있는 특정 위성의 Ephemeris 데이터가 최신 것으로 확인되면 막대 그래프의 색이 채워지고, 그렇지 않은 경우에는 막대 그래프의 테두리 선만 표현되지만 새로운 Ephemeris 데이터의 수신이 완료되면 색이 채워지게 됩니다.

내용정리

그런데, TTFF는 위에서 설명한 Almanac 데이터와 Ephemeris 데이터의 수신 여부만으로 결정되는 것은 아닙니다.

GPS 수신기의 전원을 끈 채로 1,000km 이상 떨어진 곳으로 이동하여 다시 GPS 수신기의 전원을 켜면 TTFF가 굉장히 길어지는 것을 경험하신 분도 계실 것입니다.

이는 GPS 수신기가 위성들의 원자시계와 정확한 시각동기를 이루기 위한 과정이 길어지기 때문에 발생하는 문제입니다.

GPS 수신기는 각 GPS 위성들로부터 전파(PRN 코드)를 수신하여 전파가 도달한 시간을 측정하고, 이를 통해 해당 위성까지의 거리를 측정합니다.

그런데 문제는 GPS 위성에서 GPS 수신기까지 전파가 도달하는 시간을 측정하려면 GPS 위성과 GPS 수신기의 시각이 아주 정밀하게 일치해야 된다는 것입니다.

실제로 GPS 위성은 원자시계를 탑재하고 있지요.

그런데 GPS 수신기에도 원자시계를 탑재할 경우... GPS 수신기의 무게와 부피는 아주 커지게 되고요, 그 가격 또한 수천만원을 넘게 될 것입니다.

실효성이 떨어지겠지요.

그렇기때문에 실제로 일반적인 제품에서 사용하는 방법은, GPS 신호를 통해 GPS 수신기의 시각동기를 이루는 것입니다.

그런데 여기서 또 문제가 발생합니다.

GPS 위성에서 현재의 정확한 시각정보를 전파에 실어 GPS 수신기로 보내면,

그 신호가 수신기에 도달할 때에는 이미 그 시각이 아니라는 것입니다.

그래서 다시 이 문제를 해결하기 위해 예상소요시간의 개념이 도입는데 이는 GPS 위성과 GPS 수신기의 거리를 고려하여 전파가 도달하는 예상소요시간을 산출하는 것입니다.

즉, GPS의 시각정보가 GPS 위성으로부터 GPS 수신기까지 도달하는 예상소요시간을 고려하여 GPS 수신기의 시각을 동기화 시키는 것입니다.

특정 시각의 GPS 위성 위치는 Ephemeris 데이터를 통해 산출할 수 있지만 문제는 GPS 수신기의 위치는 파악할 수 없다는 것입니다.

그래서 GPS 수신기의 위치는 최후로 위치파악이 되었던 곳을 기준으로 하여 예상소요시간을 산출하고, 시각을 보정하고, 이를 바탕으로 본격적으로 GPS 수신기의 위치파악에 들어갑니다.

만약 최후로 위치파악이 되었던 곳이 아닌 다른 곳에서 다시 GPS 수신기를 사용한다면 당연히 예상소요시간도 틀린 값이며, 시각도 정확하게 동기화 되지 않은 것이며, 좌표값도 산출도 불가능할 것입니다.

이 때, GPS 수신기의 프로세서는 예상소요시간을 가감하며 다시 위치계산을 되풀이 하게 되는데 산출된 결과를 살펴서 보다 신뢰할 수 있는 결과가 나올 수 있도록 예상소요시간을 변경해 갑니다.

여기서 산출된 결과를 살핀다는 것은 글로 설명하기 정말 어려운 부분인데,

예를들어 3개 위성과의 거리(의사거리 : Pseudorange)로 산출한 위치에 4번째 위성과의 거리값을 적용하여도 그 위치가 나오는지 확인하는 것으로,

4번째 위성과의 거리값이 더 길어야 되는지 혹은 더 짧아야 되는지 확인하여 예상소요시간의 가감을 결정하는 것입니다.

예상소요시간의 가감하여 3개 위성을 통해 산출한 위치에 4번째 위성과의 거리값을 적용하여도 정확히 일치하는 결과가 나왔다면 그 좌표값은 신뢰할 수 있는 좌표값이며,

그 때의 예상소요시간은 정확한 소요시간이 되기 때문에 GPS 수신기는 정확한 시각동기를 이룬 것입니다.

다시 본론으로 돌아가 GPS 수신기의 전원을 끈 채로 1,000km 이상 떨어진 곳으로 이동하여 다시 GPS 수신기의 전원을 켜는 경우를 생각해보죠.

GPS 수신기는 1,000km 떨어진 이전의 위치를 기준으로 예상소요시간을 부여하고 위치계산에 들어가게 되는데,

이 예상소요시간은 실제 소요시간과 큰 차이를 보이기 때문에 당연히 정확한 소요시간을 찾아내는 데 많은 시간이 필요하게 됩니다.

이 때, 사용자가 직접 수동으로 GPS 단말기에 자신의 개략적인 위치와 고도 및 시각을 입력해 준다면 GPS 수신기는 Almanac 데이터를 통해 해당 시각과 지점에서 위성위치를 파악할 수 있고,

그 위치를 기준으로 예상소요시간을 부여하기 때문에 좀 더 빨리 정확한 소요시간을 찾아내게 되어 시각동기를 이루게 될 것이고, 곧 위치파악을 할 수 있게 됩니다.

이러한 기능을 초기화(Initialize) 또는 재시작(Restart GPS)이라 합니다.

풀업 저항, 풀다운 저항 (Pull-up, Pull-down) - 입력단 회로

MCU나 임베디드 시스템을 구성할 때, 입력부분을 설계해야 하는 경우가 있다. 여기서 입력 부분이라 하면, 버튼이나 스위치 같은 물리적인 입력이 발생하는 부분을 말한다. 이때, 풀업 (Pull-up) 저항을 달거나 풀다운(Pull-down) 저항을 달게 된다.

왜 그런지 이유를 알아보자. 이 저항이 무슨 목적을 가지고 있는지를 이해하면 된다.

그리고 더 나아가, 이 저항을 얼마짜리를 달아야 하는지, 저항값 계산 방법을 알아보자.

플로팅 상태

풀업 / 풀다운이 왜 필요한지를 이해하려면 먼저 플로팅(Floating) 상태라는 것을 알면 쉽다.

플로팅은 '떠있다, 부유하는, 유동적인' 등의 뜻이다. 

디지털회로에서 플로팅 상태 라고하면, '알수없는 상태' 라고 이해하면 된다.

좀더 쉽게 설명해보자. 아두이노, AVR Atmega, Cortex-M3, 라즈베리파이 등등... MCU좀 다뤄봤다 싶은 분이라면 GPIO 핀을 떠올려 보자.

정상적인 상황이라면 어떤 GPIO핀을 딱 잡고, '너 무슨상태야?' 했을 때, '0(Low)이야' 아니면 '1(High) 이야'이라고 대답해야 한다.

그런데, '나... 잘 모르겠는데?' 라고 대답하는 녀석. 이녀석이 바로 플로팅 상태이다.

어리버리한 녀석.

왜 이런 녀석이 등장하느냐? 

전원 5V를 인가하는 MCU를 가정해보자.

0V~0.8V 쯤은 Low로 하고, 2.8V~5V 쯤은 High로 하는 MCU라고 가정해보자.

그러면 0.8V 초과 ~ 2.8V 미만의 애매한 전압이 핀에 들어가면? 이 MCU는 그 핀을 플로팅 상태라고 인식하게 될 것이다.

입력단에 풀업 저항이나, 풀다운 저항을 두지 않는다면, 이런 플로팅 상태를 겪게 될지도 모른다.

그리고 들어가기에 앞서 일단 기억할 것이 있다. 

왜 이렇게 기억할게 많냐? 라고 생각하지 말고 기억하자. 피가되고 살이된다. 몸매관리때문에 살찌기 싫으면 까먹던지.

1. 지금 설명하는 풀업 저항, 풀다운 저항은 모두 입력단 회로에 대한 것이다.

2. 입력 스위치가 OFF 일 때, 플로되는 걸 막는게 목적이다.

3. 이름에서 풍기는 스멜을 느끼자.

4. 풀업은 '스위치가 OFF일때 플로팅에 빠져 허우적 거리는 어리버리한 녀석을 High 상태로 끌어올리는(Pull-up) 저항이다.

5. 반대로, 풀다운은 '스위치가 OFF일때 플로팅에 빠져 허우적 거리는 어리버리한 녀석을 Low 상태로 끌어내리는(Pull-down) 저항이다.

오케이. 시작하자.

1. 풀업(pull-up) 저항

논리적으로 H-레벨 상태를 유지하기 위해 신호의 입력/출력 단자와 전원(Vcc) 단자 사이에 접속하는 저항

그림1의 Logic은 입력을 low로 만들어놓은 그림이다. 

여기서(a)와 (b)의 차이가 바로 풀업 저항의 의미가 된다.

일단, (a) 그림을 보자.

스위치가 ON되면 전원으로부터 접지라인까지 바로 연결이 되니까 이 Logic은 Low가 인가가 된다.

그런데 스위치가 OFF 될 경우는 어떠한가? 입력 상태가 어떤 상태인지 알 수가 없다. 

당장은 High로 보일 수 있지만, 정전기라던지, 전압에 순간적인 변화가 생기면 Low로 바뀔 수도 있는 애매한 상황이다. 이런 경우를 floating 되어있다고 한다. 

floating 상태에서는 입력 레벨이 어떤지 알 수 없기 때문에(즉, Low일수도 있고 High일수도 있고 왔다갔다 할수도 있고...) Logic Device가 동작하는데 문제가 생길 수 있다.

왜냐하면 알 수 없는 입력이 들어왔기 때문에 알 수 없는 결과값이 나오게 되기 때문이다.

이런 floating 되어 있는 입력 상태를 없애주고자 고안된 것이 바로 풀업 저항(Pull-up)이다.

풀업 저항의 주 목적은 바로 스위치가 OFF 될 때가 된다. 

이 풀업 저항을 이해하려면 (b) 그림을 유심히 살펴보자.

(b)그림을 보면 (a)그림과는 다르게 풀업 저항을 통해서 디지털 회로가 전원 +5V로 연결이 되어 있기 때문에 스위치가 OFF되더라도 입력값의 혼동이 없다. 즉, 스위치가 OFF되면 High 상태가 된다. 이른바 알려진 입력 상태가 되는 것이다.

스위치가 ON되면 Low 상태가 된다. 버튼이 GND와 연결되어 있어서, 전원으로부터 전류가 디지털 회로로 가지않고 모두 버튼쪽으로 흘러가게 되기 때문이다.

그리고 풀업 저항이 없으면 스위칭 시 과도한 전류가 흐를 개연성이 많기 때문에, 디바이스의 회로에 안 좋은 영향을 끼칠 수가 있다. 

이런 문제도 풀업(또는 풀다운)저항으로 해결할 수가 있다.

2. 풀다운(pull-down) 저항

스위치가 OFF될 때, 논리적으로 Low레벨 상태를 유지하기 위해 신호의 입력/출력 단자와 접지 단자 사이에 접속하는 저항

풀 다운은 풀업과는 반대로 연결되어 있다.

즉, 스위치와 저항의 위치가 풀업과는 다르게 바뀌어 있다.

그래서 스위치가 OFF되면 Low 상태가 되고, 스위치가 ON되면 High 상태가 된다. 일반적으로 MCU의 입력부분에는 저항이 달려있는데, 풀업, 풀다운 저항보다 아주 아주 큰값이므로 전압분배 법칙에 의해 대부분의 전압이 MCU의 입력부분으로 흘러 High 상태가 된다.

저항의 크기 계산

이러한 스위치 입력회로에서 만약 풀업 저항이나 풀다운 저항을 사용하지 않고 직접 +5V 또는 GND 단자에 스위치를 접속하면?

스위치를 눌렀을 때 그대로 단락되어 과전류가 흐르게 될 것이다.

그러므로 저항의 크기를 결정할 때는 입력신호와 관련되기 보다는 스위치를 눌렀을 때 형성되는 폐회로에 흐르는 전류의 크기를 감안하여 결정하면 된다. 일반적으로 이 전류의 크기는 수 mA가 되도록 하며, 따라서 보통 수 KΩ 정도의 저항을 사용하면 된다.

정리

일반적으로 풀다운 보다는 풀업이 노이즈에 강하다.

그래서 풀업을 더 많이 사용한다.

그리고 TTL과 같은 디지털 논리소자는 구조적으로 입력신호가 플로팅 상태이면, H상태와 같이 동작하도록 설계 되어 있다. 하지만 실제로 회로를 이렇게 사용하면 잡음에 매우 취약해지는 등의 부작용으로 회로시스템이 불안정해진다.

라즈베리파이 스마트 조명 (Pi-Light: Raspberry Pi Powered Smart Light)

이 프로젝트를 위한 github : https://github.com/JamesPoole/PiLight

출처 : http://jamespoole.me/2016/10/11/pilight-raspberry-pi-powered-smart-light/

라즈베리파이 보안카메라 (Raspberry Pi Security Camera)

소개

Welcome to the official tutorial for building your very own Particle-connected security camera with Raspberry Pi! This project uses the Raspberry Pi integration with the Particle Cloud to control a PIR sensor, Neopixel LED ring, and Raspberry Pi camera to watch for intruders, snap a photo, and upload it to the web via Dropbox.

All firmware and software files for the project are located at the following GitHub repository: https://github.com/spark/particle-pi-camera

출처 : https://docs.particle.io/tutorials/projects/particle-pi-security-camera/

선형 전압 레귤레이터(Linear Voltage Regulator)

Embedded system을 설계하려면 가장 먼저 고려해야 할 점이 '전원회로를 어떻게 구성할 것인가' 이다. 

특히 휴대용 Embedded system을 설계할 때는 가장 중요한 부분이라고 할 수 있겠다.

요즘 스마트폰이나 테블릿 들이 여러 새로운 기능으로 변신을 하고 있지만, 여전히 가장 중요한 것 중 하나는 배터리(Battery)의 크기를 소형화 하는 것과 장치 자체가 사용하는 전력소모를 줄이는 것이다.

여기서는 간단히 Embedded system 설계에 필요한 Power 회로의 특징을 이해하는 정도만 알아보겠다.

첫 순서로 가장 많이 그리고 쉽게 사용하는 Linear Voltage Regulator 이다.

Linear Voltage Regulator 하면 그 용어가 생소할 수도 있는데...

우리가 +5V를 위해 흔히 사용하는 7805와 같은 3-단자 Voltage Regulator가 Linear Voltage Regulator 이다.

Linear Voltage Regulator는 일종의 가변저항으로 생각하면 되겠다.

즉, 일정한 Regulator 출력전압을 유지하기 위해 "Voltage Controlled Current Source"를 사용한다.

Voltage-Controlled Current source diagram

아래쪽의 직사각형 부분인, Sense/Control circuitry는 출력전압을 감지(sensing)하고 (부하에 의해 더 많은 전류가 필요할 경우) 원하는 값으로 출력전압을 유지하기 위해 Current source를 조정하여 부하로 공급되는 전류를 제어한다.

물론, Current source의 조정은 regulator의 최대 부하 전류 허용범위에 한정된다. 쉽게 말해서, 부하전압(현재 회로에 걸리는 전압)이 지정된 출력전압 이하로 떨어지면 부하에 더 많은 전류를 공급해서 출력전압을 상승시키고 출력전압이 지정된 출력전압 위로 상승하면 부하에 공급되는 전류를 줄여서 출력전압이 떨어지도록 계속해서 제어하는 것이다.

회로 설명에서 알수 있듯, 어떤 스위칭 동작이 없이 부하에 계속적으로 전류가 흐르게 된다. 따라서, Linear Regulator는 Switching Noise를 발생하지 않는다.

그리고, Power 회로를 구성하는데 주변 부품을 거의 필요로하지 않으므로 공간이 문제가 되는 곳에 적합하다고 할수 있겠다.

이 두가지 정도가 장점이다.

단점은 발생하는 열이 많아서, 필요할 경우 방열판이나 냉각팬을 설치하는 등의 방열을 위한 조치를 해야한다.

그리고 열이 발생되는 만큼 효율도 낮다고 할수 있겠다.

적용에 적합한 Linear Regulator의 선정시 고려해야 하는 요소들

1. Maximum Load Current 

Worst-case 동작 조건에서 부하에 충분한 전류를 공급하도록 Regulator를 선정

2. Type of Input Voltage Source (Battery or AC) 

Battery-powered application : LDO(Low Dropout) regulator (Best Choice)

Input 전압을 보다 많이 사용하기 위해 일반적으로 Linear Regulator는 입력과 출력 사이에 2V 이상의 전압차가 필요하다. (LDO Regulator는 Voltage drop이 0.5V ~ 1.3V로 작다.) 

AC : AC를 정류해서 regulator에 입력되는 DC 전압을 얻을 경우 regulator의 dropout  voltage는 더 이상 큰 문제가 아니다.

AC transformer의 2차측 전압을 올려 충분한 regulator input 전압을 얻을 수 있기 때문이다. 이런 경우 경제적이고 보다 많은 부하전류를 공급할 수 있는 “Standard regulator"가 일반적으로 선택되며, 보다 정밀한 출력전압을 요구할 경우 ”LDO regulator"가 'Best Choice'가 될 수 있다. 

3. Output Voltage Precision(Tolerance)

대부분의 linear regulator는 5% 범위 내에서 출력전압을 보장하며 이는 대부분의 응용에 있어 적합한 수준이다.

4. Quiescent (Idling) current

Battery-powered application에서 특히 중요한 인자로 idle 상태에서 소자가 source로부터 끌어오는 전류를 말한다.

몇몇 application에서 regulator는 대부분의 시간동안 standby (또는 shut off) 상태에 있다가 main regulator가 fail 된 경우에만 부하전류를 공급할 수도 있다.

이런 경우 Quiescent current가 battery 수명을 결정한다. 대부분의 typical regulator는 수 milliamps의 Quiescent current를 가지고 LDO type은 75 ~ 150㎂ 정도이다.. 

5v 시스템에 3.3v 장치를 연결해 본 사람은 그것이 얼만다 번거로운 일인지 잘 알 것이다.

5v 인 ATmega128에 블루투스 FB155BC 칩을 붙인 다던가 하는 작업 말이다.

BOB-08745 라는 Logic Level Converter 가 있다. 

링크 : https://www.sparkfun.com/products/8745

이것은 5v 시그널을 3.3v 로 낮춰주기도 하고 3.3v 를 5v 로 높여주기도 한다고 한다.

2.8v 과 1.8v 에 대해서도 동작한다고 한다. (오!)

아직 사용해 보지는 않았지만, 추후 이런 상황이 발생하면 이걸 사용해 볼까 한다.

가격도 1.95 달러로 저렴. (홍보하는 것 같지만, 나와는 상관없다. 유용한 정보인 것 같아서 기록 해 둔다.)

이미지는 무단도용!

출처는 위 링크!