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

10

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).

gps

— uhoh
fonte

3

A primeira razão que me vem à mente é que não faz sentido nem testar, e muito menos projetar para essas velocidades, trabalhando assim há mera sorte ou coincidência.

— PlasmaHH

2

Estou com o PlasmaHH neste. Se eu for lançar um produto que 99,9% dos meus clientes usarão em velocidades típicas de automóveis ou menos, não vale a pena testá-lo a 8000 km / h, mesmo que eu espere que funcione. Escusado será dizer que é tolice colocar uma especificação que você não testou.

— Dmitry Grigoryev

3

O teste de GPS @DmitryGrigoryev geralmente é feito com um simulador de sinal - a velocidade é apenas um número digitado. Não custa checar, e bons engenheiros sempre querem saber o limite de desempenho de um projeto. Mas, por favor, minha pergunta perguntando qual parte da função GPS provavelmente será a primeira a falhar em alta velocidade, não "o que você faria se fosse um engenheiro de produto".

— uhoh

2

@uhoh Talvez eles sejam testados a 8000 km / h usando um simulador. Ainda assim, eu não colocaria esse número na especificação sem testar a coisa real. Eu já vi muitas coisas trabalhando em um simulador ou banco de testes e depois falhei espetacularmente na prática.

— Dmitry Grigoryev

11

@DmitryGrigoryev podemos afastar-se o que você faria se você ...

— uhoh

6

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:

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.
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.
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.
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 .

— Andreas
fonte

Para o ponto 1. (largura de banda do front-end), a largura de banda original do sinal é muito maior que o deslocamento do doppler - considere o pior caso em velocidades relativas de 10 km / s em relação à velocidade da luz 3E + 05 km / s em torno de 50 kHz. Mas 2, 3, 4 parecem todos potenciais rompedores de chips e firmware otimizados para o consumidor.

— uhoh

2

@ uhoh: Concordo com o seu argumento de largura de banda, mas o ponto 1 não é sobre largura de banda. Eu deveria ter explicado melhor. Se a sua taxa de amostragem for 16.368.000 / se o sinal em IF estiver centralizado em 4.092.000 Hz, e você tiver um a / d com resolução de 4 bits, terá um problema de batida. Todo erro de truncamento de amostras seguirá a mesma direção. Existe um monte de pontos ruins (zero IF é outro muito ruim, mas qualquer harmônica é ruim). Você deseja manter distância (depende do período de integração) desses pontos para qualquer doppler esperado.

— Andreas

Ótimo, muito obrigado por esta resposta! Isso me dá muita percepção do que está acontecendo. Ainda não entendo o erro de espancamento / truncamento, mas posso ler e talvez fazer uma pergunta depois. Eu tenho uma pergunta ACD diferente relacionada a ADCs de alta frequência e três bits (o PiSky possui 3 bits ADC).

— uhoh

11

Tem a ver com o S / N das amostras individuais, o que é realmente ruim. Investir em mais precisão no ADC não melhorará tanto o desempenho geral do sistema. É uma troca complicada, tentarei dar uma resposta útil à sua pergunta do ALMA.

— Andreas

4

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.

— Krunal Desai
fonte

O que significam "Eb / N0" e "SVs"? Você sabe ao certo se o tempo real é relatado quando as coordenadas espaciais são bloqueadas ou você quer dizer apenas o sinal de 1pps? Observe que especifiquei: "Ignorando a implementação dos limites do CoCom e todos os outros problemas de operação no espaço, além da velocidade .."

— uhoh

Dois anos atrás, os satélites foram reclassificados como "não-munições", então o ITAR não se aplica mais - mas agora o EAR se aplica como você mencionou. Ainda há MTCR e o Acordo Wassenaar também e possivelmente mais também!

— uhoh

3

@uhoh Presumo que o termo é Eb / N0 => relação sinal-ruído e SVs => veículos espaciais (satélites GPS reais)

— user2943160

@ user2943160 Obrigado, faz sentido. Estou sempre tentando aprender coisas novas - se Eb é um termo específico, eu gostaria de aprender.

— uhoh

Ultimamente, tenho feito muitas coisas de comunicação, Eb / No é apenas o SNR "normalizado" ou SNR por bit. Realmente, provavelmente teria sido mais preciso usar apenas SNR ou RSSI nessa resposta. Curiosamente, ouvi dizer que alguns chipsets (SiRF, eu acho) ainda reportam tempo, mas congelam você fora de posição, mas eu pessoalmente não confirmei isso.

— precisa saber é o seguinte

2

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?

— pjc50
fonte

3

Observe que, mesmo a 0 km / h, você precisa lidar com o Doppler, pois os satélites já estão se movendo a 8000 m / s.

— Dmitry Grigoryev

Eu gosto da sua lógica! É realmente uma mudança do tipo (até) +/- 60 kHz aplicada de maneira diferente a cada sinal de satélite, boas chances da maioria dos simuladores fazer isso. Só para constar, na verdade não estou fazendo isso - só estou perguntando isso!

— uhoh

2

Não, @DmitryGrigoryev você está errado sobre o 8000. Eles estão se movendo muito mais devagar porque estão em órbitas muito mais altas. Mas você está certo de que há muito Doppler além do movimento da unidade GPS. É um bom argumento!

— uhoh

@uhoh Meu erro. Meu comentário deve ser 14.000 km / h.

— Dmitry Grigoryev

5

Isso é muito menos relevante no solo - a velocidade tangencial para o observador não causa doppler. No entanto, causa um pequeno efeito relativístico: physics.stackexchange.com/questions/1061/…

— pjc50 6/6

2

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.

— pericynthion
fonte

1

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

— Voltage Spike
fonte

Os efeitos ionosféricos ainda não induziriam erros na escala de metros ou, na pior das hipóteses, dezenas de metros? A menos que o cubesat esteja fazendo coisas que exijam cronometragem de milissegundos ou vôo de formação baseado em GPS, isso não acabaria importando para a maioria dos cubesats. É bom lembrar, obrigado!

— uhoh