Introduçãoedit

Conhecido inicialmente como um sistema de navegação, o Global Positioning System é utilizado também para disseminar o tempo de forma precisa, intervalos de tempo e frequência. O GPS transmite sinais gerados por relógios de alta precisão embarcados nos satélites. Esse tempo é utilizado para auxiliar na computação da localização geográfica do receptor. Porém receptores de tempo e frequência utilizam essas transmissões advindas dos satélites para controlar 'timing signals' e 'oscillators'.

alt

Tempo e intervalo de tempo são conceitos distintos. Tempo é a marcação de um evento com respeito a uma referência de origem. O intervalo de tempo é uma medida de duração. O tempo de um evento é horas, minutos, segundos, enquanto intervalo de tempo pode ser medido pela quantidade de segundos decorridos entre dois eventos subsequentes.

Frequência é a medida do número de eventos que ocorreram em um determinado intervalo de tempo. Assim sendo Coordinated Universal Time (UTC) é um sistema de tempo adotado em diversos países em 1972. UTC é coordenado pelo Bureau International des Poids er Mesures (BIPM) na França e é baseado na combinação ponderada dos relógios atômicos espalhados pelo mundo. Ocasionalmente o UTC muda através da adição de saltos de segundos.

GPS é capaz de disseminação global de tempo e frequência 24 horas por dia. A precisão da frequência pode ser comparado ao alcançado pelas estações Loran-C, e a precisão do tempo esta no raio de 100 nano segundos. O tempo informado pelos GPS’s é um padrão preciso relacionado ao UTC.

Para sincronizar um receiver GPS, o receiver deve encontrar satélites GPS, ou Space Vehicles (SV) , em uma das duas frequências disponíveis. Intervalos de tempos no receiver podem ser produzidos pela repetição de 1 milhão de vezes do código PRN.

Para obter o tempo com precisão, a posição tridimensional do receiver precisa ser conhecida. Um erro de posição de um metro equivale a um erro de precisão de tempo de 3 nano segundos e aproximadamente 1 milihertz de erro de frequência.

Outras fontes de erros que podem ser encontradas e afetarão a precisão do sinal de GPS. O receiver GPS deve estar localizado em uma área aberta e desobistruida , com ampla vista do céu. Além disso devemos considerar o atraso inerente da passagem do sinal pela atmosfera. Para tratar tal erro o sistema utiliza um modelo embarcado que calcula um atraso médio para corrigir parcialmente este tipo de erro.

Devem ser considerados os erros de órbita, esta terminologia refere-se a falta de precisão em relação à localização do satélite. Outro fator importante seria em relação ao relógio do receiver que pode conter um pequeno timing error.

A mensagem de navegação é constituída por três componentes principais. A primeira parte contém a data de GPS e de tempo, mais o estado do satélite e uma indicação da sua saúde. A segunda parte contém informação orbital chamada dados de efeméride e permite que o receptor calcule a posição do satélite. A terceira parte, chamada de almanaque, contém informações e status sobre todos os satélites, os seus endereços e números de PRN.

A mensagem de navegação em si é construída a partir de um quadro de 1500 bits, o qual é dividido em cinco subquadros de 300 bits cada, e transmitidos a 50 bit / s. Cada subquadro, portanto, requer 6 segundos para ser transmitido. Cada subquadro tem o tempo GPS. Subtrama 1 contém a data de GPS (número semanas) e informação para corrigir o tempo do satélite para o tempo GPS, além de estado do satélite. Subquadros 2 e 3 juntos contêm dados do satélite de transmissão da efeméride. Subquadros 4 e 5 contêm componentes do almanaque. Cada quadro contém apenas 1/25 do almanaque total; um receptor deve processar 25 frames inteiros para recuperar toda a mensagem almanaque. Nesse ritmo, 12,5 minutos são necessários para receber o almanaque inteiro a partir de um único satélite.

CDMA

CDMA é uma forma de spread spectrum, uma família de técnicas de comunicação digital que foram utilizadas para aplicações militares durante anos.

O princípio do spread spectrum é a utilização de ondas portadoras similares ao ruído e com largura de banda muito maior do que a requerida para uma simples comunicação ponto a ponto com a mesma taxa de dados. Originalmente, isto se deve a dois motivos: resistir a esforços inimigos para confundir as comunicações (anti-jam) e até mesmo esconder o fato que alguma comunicação estava sendo realizada, baixa probabilidade de interceptação (LPI).

O CDMA gasta pouca energia, usas as freqüências disponíveis de forma eficiente, simplifica o planejamento com um padrão de reuso de freqüência único, usa um sistema um sistema de códigos que permite receber o sinal em situações adversas, impede a interferência e o rastreamento da transmissão.

O uso de CDMA para aplicações civis em rádio móvel foi teoricamente proposta no fim da década de 1940, mas nenhuma aplicação prática tomou lugar no mercado civil até 40 anos depois.

As aplicações comerciais se tornaram viáveis devido a dois desenvolvimentos evolucionários. Um foi a disponibilidade de circuitos digitais com baixo custo e alta densidade de integração, que reduziam o tamanho, peso e custo das estações de assinante a um valor aceitável.

O outro foi a descoberta quee, para a otimização de comunicações de acesso múltiplo, era requerido que todas as estações de assinante regulassem a potência de seus transmissores para o mais baixo nível que permitisse adequada qualidade de sinal.

O CDMA muda a natureza da estação de assinante de um aparelho predominantemente analógico para um aparelho predominantemente digital.

Antigos modelos de receptores separavam estações ou canais pela filtragem no domínio da freqüência. Receptores CDMA não eliminam totalmente o processo digital, mas separam os canais de comunicação através de uma modulação pseudo-aleatória que é aplicada e removida no domínio digital, não na base da freqüência. Múltiplos usuários ocupam a mesma banda de freqüência.

Esta reutilização de uma freqüência universal não é por acaso. Ao contrário, é crucial para uma altíssima eficiência espectral que é característica do CDMA.

Requisitosedit

O propósito do nosso projeto é realizar um estudo referente aos receptores GPS disponíveis atualmente, de modo a analisar a precisão de recepção do tempo de relógio advindo de satélites equipados com relógios atômicos, que possuem uma precisão de 1 ps, assim como a frequência de recebimento dos mesmos. Para nosso caso selecionamos um receptor GPS , EM-406A, que possui uma saída PPS (Pulse Per Second) e uma frequência de atualização de 1Hz. Devemos usar o sinal de PPS para regir o tempo do sistema, garantindo assim a precisão do relógio em relação à fonte de tempo.
Deve-se atentar ao fato do escorregamento do relógio do sistema para saber em quanto tempo precisamos trocar uma mensagem NMAE com o módulo GPS para obter o GPS Time e utilizá-lo como base de sincronização.

Requisitos não-funcionaisedit

Performance: O sistema deve garantir uma precisão de microsegundo. Dado que a precisão do modulo GPS é de 300 microsegundos, alcançaríamos tal precisão ao regir o relógio do sistema usando o PPS.
Confiabilidade: O sistema deverá ter alta disponibilidade, esta disponibilidade sendo estritamente relacionada ao desempenho e precisão do sistema.
Requisitos de implementação: O sistema será implementado em C++, utilizando o EPOS como Sistema Operacional e o modulo GPS supracitado.
Requisitos de interoperabilidade: Considerando a interoperabilidade do protocolo de comunicação, entre dispositivo e modulo GPS, a mesma será garantida entre o dispositivo e qualquer modulo GPS que aceite o padrão NMEA 183.

Especificaçãoedit

Máquina de Estados

Modelo Funcional

Diagrama 1

Diagrama 2

Diagrama de Classes

Módulo GPSedit

20 Channel EM-406A SiRF III Receiver with Antenna

Características:
- 20 canais de recepção
- Antena embarcada
- Alta Sensibilidade - 159 dBm
- Hot Start: 8 segundos
- Warm Start: 38 segundos
- Cold Start: 42 Segundos
- 70 mA de consumo de energia
- 30 mm x 30 mm x 10,5 mm

Datasheet

Apresentação de progresso do trabalho

- Realizamos a importação do EPOS para o arduino mega 1280.

Alguns ajustes precisaram ser feitos para o correto funcionamento do EPOS no arduino 1280, dado que o foi realizado o mapeamento apenas do atmega128 e atmega1281.

Algumas das alterações foram:

- Ajuste da frequencia do relógio para o relógio do arduino - 16MHz:
- /mach/atmega1281/traits.h
L:22 static const unsigned long long CLOCK = 16000000; //16MHz

- Identificamos uma incompatibilidade entre o mapeamento da UART encontrado no EPOS e o registrador do atmega 1280, para resolver o problema alteramos a seguinte linha.
- /mach/atmega1281/traits.h
L:71 static const unsigned int DEFAULT_UNIT = 0

Foi estabelecida a comunicação serial entre o modulo GPS e o atmega1280 para transmissão dos dados do receptor para o microcontrolador.
Para tratar as mensagens que são enviadas do modulo GPS implementamos um parser para o protocolo NMEA-0183 V3.01. Basicamente precisamos da mensagem GPRMC, que contem o tempo UTC, data UTC, posicionamento (latitude e longitude) , status do receptor, velocidade e curso. O parser pode ser facilmente estendido para outras mensagens suportadas pelo protocolo com o objetivo de auxiliar o SO nos cálculos para o ajuste do tempo.

Para correta implementação e alteração estudamos o mapeamento dos registradores de I/O para garantir a compatibilidade entre a implementação do EPOS para o atmega1281 e o microcontrolador utilizado, o atmega1280.

Navigation System

A mensagem GPS é um fluxo contínuo de dados transmitido à uma taxa de 50 bits por segundo. Cada satélite envia a seguinte informação para a terra.

Tempo do sistema e valores de correção do relógio. Sua data orbital extremamente precisa (ephemeris) e os dados orbitais aproximados para todos os outros satélites (almanac).

Sistema de Tempo

Para determinar o tempo de viagem do sinal de tempo entre os satélites até os receptores, alguns sistemas de tempo são necessários.

UTC
GPS Time, o tempo do sistema GPS. O tempo do GPS varia em alguns segundos em relação ao UTC ( no ano de 2008 a diferença chegava à 14 segundos) mais uma fração de segundos menor que 1μs. A diferença entre o GPS Time e o UTC e as características dessa diferença são enviadas na Mensagem enviada pelos satélites ( Subframe 4 ).
Satellite Time, o onboard time para cada satélite, A diferença específica entre o tempo do satélite e o GPS time e suas características são enviadas no Subframe 1 da mensagem de navegação.
Receiver Time, o tempo dentro do receptor de GPS. Este tempo é determinado através de um oscilador de quartz interno e é diferente do GPS time e/ou UTC. A diferença T0 é desconhecida no inicio da operação de um receptor GPS, mas pode ser reduzido após algumas medições.

Determinação do tempo de Transmissão

Todo subframe da mensagem de navegação começa com um preâmbulo de 8 bits. O preâmbulo na TLM é definido pelo seguinte padrão: 10001011. Essa sequência é repetida a cada 6 segundos. O tempo de transmissão ( em Satellite Time ) do preâmbulo é incluído na HOW (Hand Over Word) do subframe anterior com os 17-bit Time of Week ( TOW ) Message.

O receptor GPS realiza uma busca na Navigation Message recebida para o padrão 10001011. Dado que este padrão pode aparecer em outras partes da mensagem de navegação, as condições para os outros parâmetros também precisam ser cumpridas, assim como:

Dois 0’s devem aparecer nos bits 51 e 52 após o fim do preâmbulo assumido.
A paridade iniciando 16 bits após o preambulo assumido devem estar corretos.
Os dois bits antes preambulo assumido devem ser 0.
O tempo enviado na mensagem TOW ( 17 bit ) iniciando 22 bits depois do fim do preambulo assumido deve estar aproximadamente correto. Dado que a informação do tempo é repetida a cada 6 segundos, não há nenhuma necessidade de grande precisão para a medida de tempo do receptor.

GPS Time e Transmissão

A epoch GPS inicial é 0000 UT (meia-noite) em 06 de janeiro de 1980. GPS Time não é ajustado e, portanto, é compensado em relação ao UTC por um número inteiro de segundos, devido à inserção do leap seconds. O número se mantém constante até o salto do próximo segundo ocorrer. Esse deslocamento também é fornecido na mensagem de navegação (NAV) e o receptor deve aplicar a correção automaticamente.
Além dos leap seconds, existem correcções adicionais dadas na mensagem NAV. O tempo de sistema, por sua vez, é referenciado pelo o relógio mestre (MC) no USNO e guiado para UTC (USNO) a partir do qual o tempo de sistema não irá desviar-se mais do que um microssegundo (requisito PPS). A diferença exata está contida na mensagem NAV sob a forma de duas constantes, A0 e A1, dando a diferença de tempo e a taxa de tempo do sistema em relação à UTC (USNO, MC).
A mensagem de navegação do satélites GPS contém o número de segundos de offset entre o GPS e tempo UTC. Em geral, a inserção de um leap second só é decidido cerca de 2 meses antes de ser feito. Apesar de tudo, baseia-se nas anomalias na taxa de rotação da terra, que não é previsível, mas apenas mensurável.

Em cada satélite, um derivado de 1,5 epoch second fornece uma unidade conveniente para precisamente realizar a contagem e comunicação do tempo. Tempo indicado desta maneira é referido como uma Z-contagem. A Z-contagem é fornecida ao utilizador como um número binário de 29 bits que consiste em duas partes, como se segue:

O número binário representado pelos 19 bits menos significativos da Z-contagem é referido como o tempo de semana (TOW) count e é definido como sendo igual ao número de 1,5 segundos que ocorreram desde a transição da semana anterior.

Uma versão truncada do TOW, que consiste dos seus 17 bits mais significativos, está contido na palavra hand-over (HOW)

Os dez bits mais significativos da Z-count é uma representação binária do sequencial

número atribuído à semana GPS presente.

NOTE:
1. TO AID IN RAPID GROUND LOCK-ON THE HAND-OVER WORD (HOW) OF EACH SUBFRAME CONTAINS A TRUNCATED TIME-OF-WEEK (TOW) COUNT.

2. THE HOW IS THE SECOND WORD IN EACH SUBFRAME.

3. THE HOW-MESSAGE TOW COUNT CONSISTS OF THE 17 MSB's OF THE ACTUAL TOW COUNT AT THE START OF THE NEXT SUBFRAME.

4. TO CONVERT FROM THE HOW-MESSAGE TOW COUNT TO THE ACTUAL TOW COUNT AT THE START OF THE NEXT SUBFRAME, MULTIPLY BY FOUR.

5. THE FIRST SUBFRAME STARTS SYNCHRONOUSLY WITH THE END/START OF WEEK EPOCH.

O HOW é de 30 bits de comprimento e é a segunda palavra em cada subframe / página, imediatamente a seguir à palavra TLM. Um HOW ocorre a cada 6 segundos no quadro de dados. O MSB é transmitido em primeiro lugar. O HOW começa com as 17 MSBs do tempo-de-semana count (TOW). (A contagem total TOW consiste dos 19 LSBs dos 29-bit Z-count). Os outros 10 bits do Z-count dizem respeito ao número da semana desde o start date.

Próximos Passos:

- Implementar o tratador de interrupção

- Verificar mapeamento das portas para interrupção no atmega1280.

- Calcular tempo de offset da transmissão do dado do módulo gps até o tempo em que se configura o tempo RTC no sistema operacional.

- Quebrar a barreira de 1 microsegundo para timekeeping

Objetivoedit

O objetivo deste projeto é desenvolver um driver que permita à um micro-controlador ATMEGA1280 rodando EPOS, sincronizar suas informações temporais (hora, data) com um módulo GPS (ME1000RW ou ME622R) e também ter seu tempo regido pela saída 1PPS do módulo (ME622R).
O objetivo original de obter as mensagens oriundas diretamente do GPS e realizar os cálculos de correção de posição 3D e tempo foi abandonado devido à impossibilidade de fazê-lo com os módulos GPS aos quais tivemos acesso.

Especificação

Driver

Máquina de Estados

Modelo Funcional

Diagrama 1

Diagrama 2

Diagrama de Classes

Parser

Máquina de estados 1

Máquina de estados 2

Testes de unidadeedit

Testes:

ASCL é uma linguagem de especificação para programas em C, usando pré e pós-condições estilo Hoare. Pode ser classificado como uma Linguagem de Especificação de Comportamento de Interface (Behavioral Interface Specification Language (BISL)).
Objetiva especificar propriedades comportamentais de código fonte C. É inspirada na linguagem da ferramenta Caduceus para verificação dedutiva de propriedades comportamentais.

Receive NMEA/RMC sentence:

/*@ requires \valid(message)
ensures \result == valid(NMEAMessage)
ensures \result == msg

*/
NMEAMessage * NMEAParser:parse(char* message)Parse NMEA/RMC sentence

/*@ requires \valid(message)
requires \message = valid(size)
requires \valid(message(parameters))
ensures \allocated(time)
ensures \allocated(date)
ensures \allocated(lat)
ensures \allocated(lon)
ensures \allocated(speed)
ensures \allocated(course)
ensures \parsed(msg)

*/
RMCMessage * NMEAParser:parse_rmc(char* message) ''Interrupt

/*@ requires \avaible(I/O)
requires \exists(Function)
requires \valid(Interrupt)
ensures \valid(int_vector(Interrupt, Function))
ensures \PCMSK0 == 0
ensures \PCICR == 0
ensures \EICRA == 3
ensures \EIMSK == (1 << 0 )
ensures \SREG == (1 << 7)
inductive Interrupt_Status
case Interrupt
blink(LED)
case !Interrupt
!blink(LED)

/

GPS/EPOS Communication:

/*@ requires \avaible(UART)
requires \connected(Tx/Rx)
requires \powered(GPS)
ensures \correct(baud)
ensures \correct(start_bit)
ensures \correct(stop_bit)
inductive UART
case Connected
receive(message)
case !Connected
assigns \nothing

/

Alarm:

/*@ requires \avaible(Alarm)
requires \valide(date)
ensures \valid(Alarm)
inductive Alarm
case Activated
request(NMEA)
case !Activated
assigns \nothing

/

PPS:''

/*@ requires \precise(PPS)
requires \system(date)
ensures \date == date + 1 second

• /

Implementaçãoedit

gps.cc

1. include
2. include
3. include
4. include
5. include
6. include
7. include
8. include
9. include "parser_nmea.h"
10. include "rtc.h"//#include __USING_SYS

OStream cout;

void parse(){

cout << "PPS\n";

}
int main()
{

UART uart(9600, 8 , 0 , 1);
char msg30;
typedef IO_Map IO;
IC:int_vector(IC::IRQ_IRQ0, parse) CPU:out8(IO::PCMSK0, 0) CPU:out8(IO::PCICR, 0);

CPU::out8(IO::EICRA, 3)

CPU:out8(IO::EIMSK, (1 << 0)) CPU:out8(IO::SREG, (1 << 7)) char * date;
ParserNMEA p; int i;
while(true){
i=0;
if(uart.get() == '\n'){
while(i < 30){
msgi = uart.get();
i++;
}
if(msg0 == '$' && msg1 == 'G' && msg2 =='P' && msg3 == 'R'){
date = p.parse(msg);
cout << date << "\n";
free(date);
}
}
}
return 0;

}

parser_nmea.h

1. ifndef _PARSER_NMEA_H_
2. define _PARSER_NMEA_H_

1. include

/*

• Protocol NMEA-0183 V3.01
• GGA - Global Positioning System Fix Data
• GLL - Latitude, Longitude
• GSA - GNSS DOP and Active Satellites
• GSV - GNSS Satellites in View
• RMC - Recommended Minimum Specific GNSS Data
• VTG - Course Over Groung and Groud Speed
• /class ParserNMEA {

public

enum MessageType {
GGA, GLL, GSA, GSV, RMC, VTG
} char* parse(char* message);

private

MessageType get_type(char* message) char* parse_rmc(char* message);
};

1. endif

parser_nmea.cc

1. include "parser_nmea.h"
2. include
3. include

typedef ParserNMEA

:MessageType MessageType char* ParserNMEA:parse(char* message) {
MessageType type = get_type(message) char* result;
char * date;

switch(type) {
case RMC

result = (char*)(malloc(18*sizeof(char))) date = parse_rmc(message);
strcpy(result, date);
break;
}
free(date);
return result;
}

char* ParserNMEA

:parse_rmc(char* message) {
const int TIME_SIZE = 10 const int DATE_SIZE = 6;
const int TOTAL_SIZE = TIME_SIZE+DATE_SIZE+2;

char* date = (char*)(malloc(TOTAL_SIZE*sizeof(char)));
for(int i=7; i<17; i++) {
datei-7 = messagei;
}
int i = TIME_SIZE;
datei = ' ';

int comma_count = 0;
while (comma_count < 9) {
if(*message == ',')
comma_count++;
message++;
}

i++;
while (*message != ',' & i < TOTAL_SIZE-1) {
datei = *message;
message++;
i++;
}
dateTOTAL_SIZE-1 = '\0';

return date;
}

MessageType ParserNMEA

:get_type(char* message) {
char s4 s0 = message3;
s1 = message4;
s2 = message5;
s3 = '\0';
MessageType type;
if(strcmp(s,"GGA") == 0)
type = GGA;
if(strcmp(s,"GLL") == 0)
type = GLL;
if(strcmp(s,"GSA") == 0)
type = GSA;
if(strcmp(s,"GSV") == 0)
type = GSV;
if(strcmp(s,"RMC") == 0)
type = RMC;
if(strcmp(s,"VTG") == 0)
type = VTG;
return type;
}

Implementação e Testes Globaisedit

Nesta etapa realizamos

• a criação do alarme que sincroniza, periodicamente, o relógio do EPOS com o horário obtido do GPS

a contagem dos ciclos de relógio decorridos desde o início da leitura dos dados vindos do módulo GPS até a sua disponibilização na NIC;conversão do tempo UTC para o formato usado no PTP (Precision Time Protocol);

Alarme

Foi criado um alarme periódico cujo handler atualiza o horário UTC do EPOS com o horário vindo do módulo GPS.

Contagem dos ciclos de relógio

Para realizar a disseminação do tempo de maneira correta, se faz necessário conhecer o tempo decorrido desde a leitura dos dados na fonte (i.e. módulo GPS), até a sua disponibilização na NIC. Nesse caminho a mensagem NMEA vinda do GPS passa pelo parser, que extrai dela as informações necessárias, e pelo driver do GPS, que vai realizar o controle de tempo no EPOS.
Este cálculo foi divido em etapas: o atraso da UART foi calculado usando a taxa de transmissão (9600 baud) e a quantidade de caracteres que precisamos receber para completar a mensagem. Já o tempo de processamento foi calculado analisando o fluxo de execução do programa e o código assembly gerado.
O atraso total ficou em 3,398 milisegundos. Pode-se verificar que a maior parte do atraso está na recepção dos dados na UART (3,125 milisegundos / 92%). O atraso causado pelo parser e pelo driver totalizou 0,273 milisegundos (8%).

Conversão do tempo UTC para tempo UNIX

Foi realizada a conversão do tempo UTC vindo do módulo GPS para o formato de tempo do UNIX (segundos decorridos desde 01/01/1970 00:00:00), que é o formato de tempo utilizado pelo PTP.

Transferência do timestamp para a NIC

Feita a conversão do UTC temos o Timestamp necessário para começar a utilização do protocolo PTP, fazemos o registro do Timestamp na mensagem após realizar a compensação dos atrasos calculados.

Referência Bibliográfica[edit]

• “The Role of GPS in Precise Time and Frequency Dissemination”
• http://en.wikipedia.org/wiki/GPS_signals#Basic_GPS_signals
• www.kowoma.de/en/gps/data_composition.htm
• http://www.satsleuth.com/GPS_User/index.htm