EQUATOR GNSS / BY TECHNOGISAlemanha · Indonésia
RTK e correções

Verificando a interoperabilidade RTCM entre o equipamento GNSS

Teste o conteúdo da mensagem, o suporte do sinal e as informações de referência ao combinar uma base, caster e rover de diferentes sistemas.

Verificando a interoperabilidade RTCM entre o equipamento GNSS

Comece com a combinação completa

RTCM é amplamente utilizado para trocar informações do GNSS, mas a presença do acrônimo Em dois produtos não é um teste completo de interoperabilidade. Uma base pode gerar várias combinações de mensagens e um rover pode suportar apenas parte delas. Documente a configuração exata da base, o caminho de transporte, o modelo Rover e o firmware. A combinação é a unidade que está sendo testada, em vez de duas reivindicações independentes de suporte a padrões.

Defina primeiro o uso pretendido. Um fluxo que carrega observações para RTK convencional é diferente de um fluxo projetado para outro método de correção. O rover deve entender o formato e o significado das informações entregues. Uma conexão de rede bem-sucedida demonstra o transporte de dados; Ele não demonstra que o receptor pode usar todas as mensagens necessárias para o resultado de posicionamento pretendido.

Continue aprendendo Mensagens RTCM: verificar compatibilidade das correções

Estoque As Observações Suportadas

Compare as constelações e sinais observados na fonte com os suportados pelo Rover. Observações comuns úteis são o que importa para o processamento relativo. Uma longa lista de sinais de origem oferece pouco benefício se o rover não puder rastreá-los ou decodificá-los. Obtenha as orientações do fabricante para as versões reais do firmware e evite presumir que os recursos listados para uma versão mais recente se aplicam à unidade em campo.

Onde o equipamento permite a configuração de famílias ou taxas de mensagens, comece com uma combinação documentada com suporte. Mantenha um registro das alterações feitas durante o teste. Não reduza ou adicione mensagens aleatoriamente porque a largura de banda parece alta. Um fluxo pode ser pequeno e incompleto ou grande e ainda incompatível. O objetivo é um conjunto apropriado e utilizável de informações entregues de forma confiável ao receptor.

Continue aprendendo Selecionando um site para uma estação de referência GNSS em operação contínua

Mantenha o transporte e o conteúdo separados

Os dados podem viajar por rádio, por cabo direto ou serviço de NTRIP. Um problema de transporte pode impedir que um bom conteúdo RTCM chegue ao rover, enquanto um problema de conteúdo pode permanecer após a conexão ser restaurada. Inspecione as duas camadas. Confirme se estão chegando bytes ou mensagens e inspecione o diagnóstico do receptor para determinar se os dados são aceitos para posicionamento em vez de meramente recebidos por um aplicativo.

Um rodízio geralmente distribui o fluxo fornecido a ele; Não se deve supor que conserte informações de referência ausentes ou converta todas as mensagens em um formulário compatível com Rover. Se um serviço de conversão for usado deliberadamente, documente-o como outro componente. Preserve sua configuração e versão quando relevante. Esse estágio extra pode explicar por que uma conexão de base direta funciona enquanto uma conexão retransmitida se comporta de maneira diferente.

Continue aprendendo Emparelhando corretamente os arquivos de observação e navegação do Rinex

Verifique as informações de referência

Confirme como a coordenada da fonte e as informações da antena são representadas na saída escolhida. Um rover usando as mensagens de observação corretas ainda pode produzir um deslocamento se a coordenada de base estiver errada ou interpretada sob uma definição de referência inadequada. Mantenha um registro básico fora do fluxo transmitido para que o escritório possa verificar o que a operadora pretendia que a fonte representasse.

Verifique as unidades, o quadro de referência de coordenadas, época, quando aplicável e as convenções da altura da antena. Esses tópicos geralmente são menos visíveis que a tela de conexão, mas podem ter consequências maiores para o conjunto de dados final. Quando uma configuração de equipamento misto discorda do controle, não culpe imediatamente a implementação dos padrões. Uma coordenada compartilhada ou um erro de configuração da antena pode imitar uma falha de interoperabilidade enquanto as próprias mensagens estão sendo decodificadas corretamente.

Continue aprendendo Avaliando um receptor GNSS para o seu fluxo de trabalho de campo real

Receptor GNSS sobre um marco de levantamento perto de um rio e de uma ponte.
Receptor GNSS sobre um marco de levantamento perto de um rio e de uma ponte. · USGS / Public Domain

Execute um teste de campo controlado

Use um local aberto com pontos de validação independentes adequados e o mesmo arranjo de comunicação planejado para produção. Registre o tempo para uma solução utilizável como uma observação operacional, sem tratar um teste como uma especificação garantida do produto. Compare as coordenadas em mais de um ponto e repita verificações importantes após uma nova inicialização. Mantenha as tentativas fracassadas no registro de teste porque descrevem os limites da combinação.

Teste as condições de trabalho relevantes, incluindo a separação esperada da base e de qualquer local de comunicação difícil. Um teste de bancada pode confirmar a decodificação básica, mas não pode estabelecer o desempenho do campo em todo o projeto. Observe quais ambientes permanecem não testados. A aprovação resultante deve descrever uma configuração e um envelope de trabalho, não uma declaração geral de que todos os equipamentos que carregam o mesmo padrão se comportarão de forma idêntica.

Continue aprendendo Mensagens RTCM: verificar compatibilidade das correções

Diagnosticar a incompatibilidade com evidências

Se os dados utilizáveis chegarem, mas o rover não atingir o estado necessário, compare o fluxo com a documentação do destinatário. Use ferramentas de monitoramento aprovadas ou o diagnóstico do receptor para inspecionar a disponibilidade das mensagens. Preservar uma pequena amostra quando permitido, junto com os times e a configuração. Dê ao equipamento ao equipamento uma descrição precisa do que foi transmitido e do que o rover relatou, em vez de apenas dizer que o RTK não funcionou.

Altere uma variável de cada vez. Testar um rover de trabalho conhecido contra a mesma fonte ou o rover suspeito em uma fonte de trabalho conhecida pode restringir o problema. Mantenha o sistema de coordenadas e o procedimento de ponto de validação independentes consistentes durante essas comparações. Caso contrário, uma mudança que parece resolver a decodificação pode simplesmente ter introduzido um arranjo de referência diferente que não é mais comparável ao primeiro teste.

Continue aprendendo Selecionando um site para uma estação de referência GNSS em operação contínua

Aprove e mantenha a configuração testada

Crie um registro de configuração aprovado Dispositivos de listagem, firmware, mensagens de saída, configurações de transporte e verificação de resultados. Mantenha esse registro acessível à equipe enquanto armazena as credenciais de acesso em particular. Quando o firmware, um perfil de saída base ou um caminho de conjuração são alterados, decida quais partes do teste precisam ser repetidas. Uma aprovação de interoperabilidade está vinculada ao arranjo testado e não deve se expandir silenciosamente para revisões não testadas.

Inclua o fluxo de trabalho de equipamento misto aprovado no treinamento. Os operadores devem saber qual predefinição usar, como são os diagnósticos normais e quando interromper a coleta. O benefício de um fluxo de trabalho baseado em padrões é a flexibilidade prática, mas a flexibilidade confiável depende da verificação. Uma combinação documentada que passa por verificações de campo significativas é muito mais útil do que uma promessa não documentada de que qualquer base e rover funcionará automaticamente em conjunto.

Continue aprendendo Emparelhando corretamente os arquivos de observação e navegação do Rinex

Uma matriz de compatibilidade reproduzível

Para um projeto usando várias combinações de equipamentos, mantenha uma matriz pequena em vez de uma única afirmação de que o RTCM funciona. As linhas podem identificar os perfis e as colunas de origem do rover e das combinações de firmware. Cada célula aprovada deve apontar para um registro de teste com a configuração da mensagem, caminho de comunicação e verificações de coordenadas. Uma célula não testada deve permanecer visivelmente não testada, mesmo quando um receptor semelhante trabalhava com a mesma fonte em outro dia.

Quando uma atualização muda um componente, a matriz ajuda a selecionar os testes que precisam ser repetidos. Também impede que um operador assuma que uma avaliação de rádio direta bem-sucedida aprova um fluxo retransmitido não testado. Conserve os registros de teste representativos onde o projeto lhes permite e mantenha o perfil de saída exato disponível para restauração. Essa abordagem torna a interoperabilidade prática: a equipe pode escolher entre os arranjos verificados, mantendo um limite claro entre a compatibilidade observada e uma possibilidade sugerida apenas por um rótulo de padrões.

Continue aprendendo Avaliando um receptor GNSS para o seu fluxo de trabalho de campo real

Lista de verificação prática

Lista de verificação prática

  1. Registre a base exata, mensagens, transporte e versões do rover.
  2. Verifique as informações das coordenadas e da antena separadamente da decodificação.
  3. Reteste combinações importantes após mudanças de firmware ou saída.
EQUATOR GNSS

Planeje sua configuração GNSS

Compare as especificações dos receptores EQ10 e EQ20 e depois converse sobre a configuração e o suporte necessários ao seu projeto.

Comparar receptores GNSS

Referências

  1. BKG — Ntrip: Real-Time GNSS Data
  2. ESA Navipedia — RTK Fundamentals
  3. NOAA NGS — User Guidelines for Single Base Real Time GNSS Positioning