GPS para Cubesats: ¿8 km / s es demasiado rápido para los chips de consumo?

10

Los satélites en órbita terrestre baja se mueven cerca de 8 km / seg. La mayoría de los chips GPS de nivel de consumidor aún invocan los límites de CoCom de 1000 nudos, aproximadamente 514 m / s. Los límites de CoCom son límites voluntarios para las exportaciones sobre los que puede leer más en esta pregunta y respuesta y esta pregunta y respuesta y en otros lugares.

Para esta pregunta, supongamos que son límites numéricos en la sección de salida del firmware. El chip debe calcular la velocidad (y la altitud) antes de poder decidir si se excede el límite, y luego presentar la solución a la salida o bloquearla.

A 8000 m / s, el desplazamiento doppler a 2 GHz es de aproximadamente 0,05 MHz, una pequeña fracción del ancho natural de la señal debido a su modulación.

Hay varias compañías que venden unidades de GPS para cubesats, y son caras (cientos a miles de dólares) y probablemente valen cada centavo porque (al menos algunas de ellas) están diseñadas para aplicaciones satelitales y probadas en el espacio.

Ignorando la implementación de los límites de CoCom y todos los demás problemas de operación en el espacio además de la velocidad , ¿hay alguna razón por la cual un chip GPS moderno con una velocidad máxima de 500 m / s no podría funcionar a 8000 m / s? Si es así, ¿Que son?

nota: 8000 m / s dividido por c (3E + 08 m / s) proporciona aproximadamente 27 ppm de expansión / compresión de las secuencias recibidas. Esto podría afectar algunas implementaciones de correlación (tanto en hardware como en software).

gps UH oh
fuente
3
La primera razón que me viene a la mente es que no tiene sentido siquiera probar, y mucho menos diseñar para estas velocidades, por lo tanto, trabajar allí es pura suerte o coincidencia.
PlasmaHH
2
Estoy con PlasmaHH en este caso. Si voy a lanzar un producto que el 99.9% de mis clientes usarán a velocidades automotrices típicas o menos, no vale la pena probarlo a 8000 km / h, incluso si espero que funcione. No hace falta decir que es una tontería poner una especificación de algo que no has probado.
Dmitry Grigoryev
3
La prueba de GPS @DmitryGrigoryev generalmente se realiza con un simulador de señal: la velocidad es solo un número ingresado. No cuesta comprobarlo, y los buenos ingenieros siempre querrán saber el límite de rendimiento de un diseño. Pero, por favor, mi pregunta es qué parte de la función GPS probablemente será la primera en fallar a alta velocidad, no "qué haría si fuera un ingeniero de producto".
uhoh
2
@uhoh Tal vez se probaron a 8000 kilómetros por hora usando un simulador. Aún así, no pondría ese número en la especificación sin probar la cosa real. He visto muchas cosas trabajando en un simulador o banco de pruebas, y luego fallan espectacularmente en la práctica.
Dmitry Grigoryev
1
@DmitryGrigoryev, ¿podemos alejarnos de lo que harías si ...
uhoh

Respuestas:

6

No recomendaría usar una solución GPS integrada (que contenga MCU y firmware de código cerrado) para una aplicación satelital. Hay varias razones por las cuales esto podría no funcionar:

  1. El plan de frecuencias frontend podría optimizarse para un rango doppler limitado. Típicamente, la interfaz de RF mezclará la señal a un IF inferior a 10MHz (un IF más alto requerirá una frecuencia de muestreo más alta y consumirá más energía). ¡Este IF no se elige arbitrariamente! El cociente IF / samplerate debe ser no armónico para todo el rango doppler para evitar tonos espurios de errores de truncación a / d en la señal muestreada. Puede observar efectos de latido, que hacen que la señal sea inutilizable a algunas velocidades doppler.
  2. El correlacionador de dominio digital necesita reproducir una réplica de la portadora y el código C / A a la velocidad correcta, incluidos los efectos doppler. Utiliza DCO (osciladores controlados digitalmente) para impulsar la generación de portadores y códigos, que se sintonizan a través de registros de configuración de la MCU. El ancho de bits de estos registros puede estar limitado al rango Doppler esperado para un receptor basado en tierra, lo que hace que sea imposible sintonizar el canal a la señal si viaja demasiado rápido.
  3. El firmware tendrá que realizar una adquisición en frío si no hay una estimación de posición / tiempo disponible. Buscará contenedores de frecuencia Doppler y fases de código para encontrar una señal. El rango de búsqueda estará restringido al rango esperado para un usuario en tierra.
  4. El firmware generalmente usará el filtrado Kalman para las soluciones de posición. Esto implica un modelo de posición / velocidad / aceleración del receptor. Si bien la aceleración no será una preocupación para un satélite, el modelo fallará por velocidad, si el firmware no está adaptado para su uso en órbita.

Todos estos problemas pueden abordarse si utiliza un frontend y un correlacionador libremente programables con un firmware personalizado. Puedes mirar a Piksy .

Andreas
fuente
Para el punto 1. (ancho de banda frontal), el ancho de banda original de la señal es mucho más amplio que el desplazamiento Doppler: considere el peor de los casos con velocidades relativas de 10 km / seg frente a 3E + 05 km / seg, la velocidad de la luz será de alrededor de 50 kHz. Pero 2, 3, 4 suenan como potenciales acuerdos para chips y firmware optimizados para el consumidor.
uhoh
2
@ uhoh: estoy de acuerdo con su argumento de ancho de banda, pero el punto 1 no se trata del ancho de banda. Debería haber explicado mejor. Si su frecuencia de muestreo es 16,368,000 / sy la señal en IF está centrada en 4,092,000 Hz, y tiene un a / d con una resolución de 4bits, entonces tiene un problema con el latido. Cada error de truncamiento de muestras irá en la misma dirección. Hay muchos puntos malos (cero IF es otro muy malo pero cualquier armónico es malo). Deberá mantener la distancia (depende del período de integración) a estos puntos para cualquier doppler esperado.
Andreas
Genial, muchas gracias por esta respuesta! Me da mucha información sobre lo que está sucediendo. Todavía no entiendo el error de latido / truncamiento, pero puedo leer un poco y tal vez hacer una pregunta después. Tengo una pregunta ACD diferente que está relacionada con ADC de tres bits de alta frecuencia (PiSky tiene ADC de 3 bits).
uhoh
1
Tiene que ver con el S / N de las muestras individuales, lo cual es realmente malo. Invertir en más precisión en el ADC no mejorará tanto el rendimiento general del sistema. Es una compensación complicada, intentaré darle una respuesta útil a su pregunta de ALMA.
Andreas
4

Algunas personas implementan COCOM como un o , otros como un y . De cualquier manera, para los clientes calificados bajo EAR o ITAR, los vendedores con gusto le venderán una opción de firmware por $$$ que deshabilita esa funcionalidad. El hardware es idéntico.

Fuera de esa difícil limitación, se convierte en un problema de comunicaciones de RF, junto con el diseño de su hardware para tolerar los efectos de la radiación. Su Eb / N0 probablemente será algo mejor ya que está (literalmente) más cerca de los SV y evitando la pérdida de trayectoria atmosférica, pero sus circuitos de recepción también necesitarán tolerar una cantidad considerable de Doppler.

Sin embargo, no es solo la posición en la que los CubeSats están interesados, por cierto, el tiempo GPS es un producto de datos valioso que ayuda a un satélite a descubrir dónde está, dado un TLE. Incluso si el receptor se niega a darle una posición debido a COCOM, si le da el tiempo, puede valer la pena.

Krunal Desai
fuente
¿Qué significan "Eb / N0" y "SV"? ¿Sabe con certeza si se informa el tiempo real cuando las coordenadas espaciales están bloqueadas, o simplemente se refiere a la señal de 1pps? Tenga en cuenta que especifiqué: "Ignorando la implementación de los límites de CoCom, y todos los demás problemas de operación en el espacio además de la velocidad ..."
uhoh
Hace dos años, los satélites se reclasificaron como "no municiones", por lo que ITAR ya no se aplica, pero ahora EAR se aplica como usted menciona. ¡Todavía hay MTCR y el Acuerdo de Wassenaar también y posiblemente más!
uhoh
3
@uhoh Supongo que el término es Eb / N0 => relación señal / ruido y SVs => vehículos espaciales (los satélites GPS reales)
usuario 2943160
@ user2943160 Gracias, tiene sentido. Siempre trato de aprender cosas nuevas; si Eb es un término específico, me gustaría aprenderlo.
uhoh
He estado haciendo muchas cosas de comunicación últimamente, Eb / No es solo la SNR "normalizada", o SNR por bit. Realmente, probablemente habría sido más preciso usar solo SNR o RSSI en esa respuesta. Como anécdota, he oído que algunos conjuntos de chips (creo que siRF) todavía informarán el tiempo pero lo congelarán fuera de posición, pero no lo he confirmado personalmente.
Krunal Desai
2

Si este documento sobre ejemplo de arquitectura GPS es representativo, entonces los chips consisten en una interfaz de RF, correlacionadores de hardware en el dominio digital, y toda la decodificación real de la señal se realiza en software.

En cuyo caso, el único problema probable es Doppler. El software puede descartar valores "excepcionales", pero deberá reemplazar o modificar el firmware de todos modos si desea omitir los límites de CoCom.

Una pregunta más interesante es si puede tomar prestado un simulador de GPS que se puede programar para simular el caso de alta velocidad. Pensé que sería posible; después de todo, ¿cómo probaría un fabricante que su dispositivo está aplicando los límites de CoCom?

pjc50
fuente
3
Tenga en cuenta que incluso a 0 km / h tiene que lidiar con Doppler, ya que los satélites ya se están moviendo a 8000 m / s.
Dmitry Grigoryev
Me gusta tu logica! Es realmente un cambio de tipo (hasta) +/- 60 kHz aplicado de manera diferente a cada señal de satélite, es muy probable que la mayoría de los simuladores puedan hacerlo. Solo para que conste, en realidad no estoy haciendo esto , ¡solo estoy preguntando esto!
uhoh
2
No @DmitryGrigoryev, estás equivocado con respecto al 8000. Se están moviendo mucho más lentamente porque están en órbitas mucho más altas. Pero tiene razón en que hay mucho Doppler además del movimiento de la unidad GPS. Es un buen punto!
uhoh
@ uhoh Mi error. Mi comentario debería leer 14,000 km / h en su lugar.
Dmitry Grigoryev
55
Sin embargo, eso es mucho menos relevante en el terreno: la velocidad tangencial para el observador no causa Doppler. Sin embargo, causa un pequeño efecto relativista: physics.stackexchange.com/questions/1061/…
pjc50
2

Realmente depende de la implementación. Como ejemplo, un receptor en el que he trabajado tiene un registro de frecuencia NCO de portadora de punto fijo en cada canal de correlación, con un ancho de 17 bits. El valor máximo que se puede almacenar en este registro corresponde a alrededor de 6 km / s, y también debe incluir una contribución del error de frecuencia del reloj del receptor. Por lo tanto, no podría rastrear ningún satélite cuya tasa de alcance supere ese límite, que serían muchos de ellos si el receptor se mueve a velocidades orbitales.

pericintion
fuente
1

Los Cubesats se pueden usar con unidades de GPS comerciales que cuestan menos de 1000 $. El fabricante elimina los límites, por lo que uno esperaría poder probar con ellos eliminados. Tienen emuladores de GPS o acceso a ellos.

El fabricante debe eliminar los límites de Cocom, y el fabricante solo lo hará si puede obtener una excepción a través de su gobierno. No estoy seguro del proceso, pero sé que es posible al menos en los Estados Unidos. Fuera de los Estados Unidos, esto puede ser casi imposible.

No sé la precisión de la unidad GPS, pero todavía hay efectos ionosféricos que deben tenerse en cuenta, si vuelas en LEO. También necesitará un sistema ADCS decente para estimar la posición de su nave espacial

Pico de voltaje
fuente
¿Los efectos ionosféricos aún no inducirían errores en la escala de metros o en el peor de los casos, decenas de metros? A menos que el cubesat esté haciendo cosas que requieran un tiempo de milisegundos o un vuelo de formación basado en GPS, esto no terminaría siendo importante para la mayoría de los cubesats. Sin embargo, es bueno recordarlo, ¡gracias!
uhoh