GPS para Cubesats - 8 km / s é muito rápido para chips de consumo?

Os satélites em órbita baixa da Terra estão se aproximando de 8 km / s. A maioria dos chips GPS de consumo ainda invoca os limites de CoCom de 1000 nós, cerca de 514 m / s. Os limites do CoCom são limites voluntários para exportações, sobre os quais você pode ler mais nesta pergunta e resposta e nesta pergunta e resposta e em outros lugares.

Para esta pergunta, vamos supor que sejam limites numéricos na seção de saída do firmware. O chip deve realmente calcular a velocidade (e a altitude) antes de decidir se o limite é excedido e, em seguida, apresentar a solução à saída ou bloqueá-la.

A 8000 m / s, o deslocamento do doppler em 2GHz é de cerca de 0,05 MHz, uma pequena fração da largura natural do sinal devido à sua modulação.

Existem várias empresas que vendem unidades de GPS para cubesats, e elas são caras (centenas a milhares de dólares) e provavelmente valem cada centavo porque (pelo menos algumas delas) são projetadas para aplicativos de satélite e espaço testado.

Ignorando a implementação dos limites do CoCom e todos os outros problemas de operação no espaço além da velocidade , existem razões para um chip GPS moderno salpicar a 500 m / s de velocidade máxima não seria capaz de trabalhar a 8000 m / s? Se sim, o que são?

nota: 8000m / s dividido por c (3E + 08m / s) fornece cerca de 27ppm de expansão / compressão das sequências recebidas. Isso pode afetar algumas implementações de correlação (tanto em hardware quanto em software).

Eu não recomendaria o uso de uma solução GPS integrada (contendo MCU e firmware de fonte fechada) para um aplicativo de satélite. Há várias razões pelas quais isso pode falhar:

1. O plano de frequência do front-end pode ser otimizado para um intervalo limitado de doppler. Normalmente, o front-end de RF reduz o sinal para um IF menor que 10MHz (um FI mais alto exigirá uma taxa de amostragem mais alta e consumirá mais energia). Este FI não é escolhido arbitrariamente! O quociente IF / amostrador deve ser não-harmônico para todo o intervalo do doppler para evitar tons espúrios devido a erros de truncamento a / d no sinal amostrado. Você pode observar efeitos de batida, que tornam o sinal inutilizável em algumas taxas de doppler.
2. O correlacionador de domínio digital precisa reproduzir uma réplica da transportadora e o código C / A na taxa correta, incluindo efeitos doppler. Ele usa DCOs (osciladores controlados digitais) para acompanhar a geração de portadoras e códigos, que são ajustados através de registros de configuração do MCU. A largura de bit desses registradores pode ser restrita à faixa doppler esperada para um receptor em terra, tornando impossível sintonizar o canal no sinal se você estiver viajando muito rápido.
3. O firmware terá que fazer uma aquisição a frio se nenhuma estimativa de posição / tempo estiver disponível. Ele pesquisará caixas de frequência doppler e fases de código para encontrar um sinal. O intervalo de pesquisa será restrito ao intervalo esperado para um usuário em terra.
4. O firmware normalmente usa a filtragem kalman para soluções de posição. Isso envolve um modelo de posição / velocidade / aceleração do receptor. Embora a aceleração não seja uma preocupação para um satélite, o modelo falhará em velocidade, se o firmware não estiver adaptado para uso em órbita.

Todos esses problemas podem ser solucionados, se você usar um frontend e correlacionador livremente programável com um firmware personalizado. Você pode, por exemplo, olhar para Piksy .

Algumas pessoas implementam o COCOM como um ou , outras como e . De qualquer forma, para clientes qualificados sob EAR ou ITAR, os fornecedores venderão com prazer uma opção de firmware para $$$ que desativa essa funcionalidade. O hardware é idêntico.

Fora dessa limitação rígida, torna-se um problema de comunicação de RF, além de projetar seu hardware para tolerar efeitos de radiação. Seu Eb / N0 provavelmente será um pouco melhor, pois você está (literalmente) mais próximo dos SVs e evitando a perda de caminho atmosférico, mas seu circuito de recebimento também precisará tolerar uma quantidade considerável de Doppler.

A propósito, não é apenas a posição em que o CubeSats está interessado - o tempo do GPS é uma mercadoria valiosa de dados que ajuda um satélite a descobrir onde está, considerando um TLE. Mesmo que o receptor se recuse a fornecer uma posição devido ao COCOM, se houver tempo, isso pode valer a pena.

Se este documento sobre a arquitetura GPS de exemplo é representativo, os chips consistem em um front-end de RF, correlacionadores de hardware no domínio digital e toda a decodificação real do sinal é realizada em software.

Nesse caso, o único problema provável é o doppler. O software pode descartar valores "excepcionais", mas você precisará substituir ou modificar o firmware de qualquer maneira, se desejar ignorar os limites do CoCom.

Uma pergunta mais interessante é se você pode emprestar um simulador de GPS que pode ser programado para simular o caso de alta velocidade. Eu pensaria que seria possível - afinal, como um fabricante testaria se o dispositivo está aplicando os limites de CoCom?

Realmente depende da implementação. Como exemplo, um receptor em que trabalhei tem um registro de frequência NCO da portadora de ponto fixo em cada canal correlacionador, com uma largura de 17 bits. O valor máximo que pode ser armazenado neste registro corresponde a cerca de 6 km / s e também deve incluir uma contribuição do erro de frequência do relógio do receptor. Portanto, não seria possível rastrear satélites cuja taxa de alcance exceda esse limite, o que seria bastante deles se o receptor estivesse se movendo em velocidades orbitais.

O Cubesats pode ser usado com unidades GPS comerciais de prateleira inferiores a 1000 $. O fabricante remove os limites, portanto, seria de esperar que eles pudessem testar com os mesmos removidos. Eles têm emuladores de GPS ou acesso a eles.

Os limites do cocom devem ser removidos pelo fabricante, e o fabricante fará isso somente se você puder obter uma exceção através do seu governo. Não tenho certeza do processo, mas sei que é possível pelo menos nos EUA. Fora dos EUA, isso pode ser quase impossível.

Não sei a precisão da unidade GPS, mas ainda há efeitos ionosféricos que precisam ser contabilizados, se você estiver voando no LEO. Você também precisará de um sistema ADCS decente para estimar sua posição de naves espaciais