Almanaque GPS versus búsqueda en el cielo

Los datos totales del almanaque se transmiten en 25 mensajes de navegación. Cada mensaje de navegación tarda al menos 30 segundos en transmitirse. Por lo tanto, recibir los datos del almanaque de los satélites toma al menos 12,5 minutos, sin tener en cuenta el GPS asistido por el momento. Si se perdió la señal al recibir el mensaje, se debe volver a recibir el mensaje completo. Esto podría duplicar el tiempo que se tarda en descargar los datos del almanaque, según el mensaje de navegación que falte.

Sin embargo, todos los datos del almanaque realmente te dan una pista de qué satélites buscar. Esta información realmente no vale el tiempo y la energía que necesita al diseñar un sistema de bajo consumo. Requiere que realice un seguimiento de la hora, la ubicación aproximada/última conocida y los datos del almanaque.

La mayoría de los receptores GPS hoy en día incluyen muchos correladores de canales , hasta 256 por lo que he visto. Una señal de satélite se repite cada milisegundo y podría desplazarse 1023 bits. Usando un solo canal por satélite, determinar si el satélite está a la vista o no puede tomar un segundo, antes de pasar al siguiente satélite. Con 256 canales, determinar si el satélite está a la vista o no solo puede tomar 4 milisegundos.

Realizar una búsqueda del cielo significa que el receptor procesará todos los satélites y verificará si están a la vista. Esto me parece más lógico que descargar los datos del almanaque para determinar qué satélite buscar. Con hasta 256 canales, teóricamente solo tomaría 100 milisegundos saber qué satélites están a la vista y necesitan descargar sus datos de efemérides.

Entonces, la pregunta aquí es: ¿es realmente necesario descargar el almanaque? ¿Sería mejor omitir la descarga de los datos del almanaque cuando la cantidad de energía disponible es baja? Especialmente cuando desea evitar la necesidad de tener un RTC, etc.

Editar:

Hice una suposición incorrecta sobre los intentos de decodificación de la señal del satélite, como lo señaló Dmitry .

Sin embargo, queda la pregunta de si sería factible ignorar los datos del almanaque. Por ejemplo, la hoja de datos del módulo GPS Maestro A2035-H indica que tiene más de 400.000 correladores. Consume 40 mA mientras busca satélites visibles y 29 mA mientras rastrea (obteniendo los datos de efemérides y calculando la posición). Solo se necesitan 35 segundos para adquirir una posición con un arranque en frío, sin un almanaque reciente o una estimación de tiempo y posición.

Para mí, parece que ignora el almanaque como sugerí. ¿Sigue siendo útil el almanaque?

Hasta donde sé, el GPS usa solo un canal para todos los satélites.
@MarkoBuršič La respuesta a esta pregunta implica lo contrario
Hay más de una interpretación de "canal"... la pregunta/respuesta enlazada dice: "Antecedentes: todos los satélites transmiten esencialmente en la misma frecuencia. Técnicamente, están caminando sobre las señales de los demás". que es lo que Marko quiere decir con un solo canal.
@ Spectre208 Citando de la respuesta vinculada: cada correlacionador se denomina "canal" por el bien del marketing. Entonces, sí, por canal me refiero a una sola frecuencia con ancho de banda dedicado, así es como funciona el GPS. Lea la respuesta vinculada nuevamente.
@MarkoBuršič Tienes razón, lo siento. no entendí bien tu comentario

Respuestas (3)

Hay varios puntos destacados en el artículo de Wikipedia sobre la adquisición de señales GPS:

  • Solo los satélites con una línea de visión clara se pueden adquirir sin el almanaque. Los satélites visibles a través de reflejos no se pueden utilizar.
  • Se requieren muchos más de 1023 intentos de decodificación para detectar una señal de un solo satélite (Wikipedia da dos estimaciones: 40 920 y 104 346 evaluaciones, según el método utilizado).
  • Una vez que se encuentra un satélite, obtener el almanaque requiere poca energía ya que solo tiene que ejecutar un solo canal. Ejecutar 256 canales en paralelo requerirá 256 veces más energía.

Al final, puede haber situaciones en las que pueda prescindir de un almanaque. Si su dispositivo está estacionario y no hay obstáculos alrededor que bloqueen la vista, es posible que pueda encontrar satélites directamente. Si esto le ahorrará algo de energía dependerá de cuánto consumirán su memoria y RTC en comparación con ejecutar 256 canales en paralelo, y con qué frecuencia usará el receptor GPS.

Gracias, me perdí el espacio de frecuencia. El punto es que mi aplicación solo necesita una única posición de GPS todos los días. Esperaba no necesitar alimentar el RTC y la memoria. En cuanto a mi aplicación, obtener el almanaque en realidad no consume poca energía.
Con 1 medición de GPS por día, no usar el almanaque puede ser realmente interesante. Pero me temo que puede ser difícil encontrar un receptor optimizado para sus necesidades. Los receptores GPS típicos están hechos para un funcionamiento continuo en aparatos en movimiento (satélites que van y vienen fuera de la vista todo el tiempo), por lo que dependen del almanaque.
Los típicos receptores GPS modernos realmente no necesitan el almanaque. En el mejor de los casos, podría ahorrar un par de segundos.

La mayoría de los receptores en estos días funcionan muy bien sin el almanaque. Excepto en condiciones de señal muy débil (o condiciones de interferencia muy fuerte), normalmente pueden adquirir y comenzar a rastrear todos los satélites a la vista en unos pocos segundos desde un inicio en frío, es decir, sin ninguna información previa sobre la posición y el tiempo del receptor y sin ningún almanaque. o datos de efemérides. Esta adquisición rápida puede realizarse con la ayuda de muchos correladores de hardware tradicionales que trabajan en paralelo, correladores de hardware "multi-tap" extendidos o técnicas FFT ** que permiten buscar simultáneamente en todo el espacio de fase del código.

El tiempo para la primera reparación está entonces dominado por el tiempo que lleva recibir suficientes tramas de mensajes de navegación para armar las efemérides del satélite. Esto puede variar de 18 a 36 segundos dependiendo de en qué parte del ciclo de transmisión se encendió el receptor.

Andreas destaca la mejora de la calidad de la solución después de esperar los datos de corrección de la ionosfera y UTC.

Para su aplicación que necesita una sola solución diaria y es muy sensible a la energía, en caso de que no necesite usar la información de posición/velocidad/tiempo en el dispositivo integrado, sino que simplemente necesite registrarla y poder determinar la P /V/T más tarde, puede usar una técnica de bajo consumo y huella de hardware muy pequeña que simplemente registra unos pocos milisegundos de datos de banda base de RF (aproximadamente 50 kB) para el posprocesamiento fuera de línea. Esta patente vencida describe los principios y he publicado un código de fuente abierta para realizar el procesamiento posterior, aunque no está bien documentado para los nuevos usuarios. Probablemente podría ser persuadido para arreglarlo y escribir mejores documentos.

** No tengo idea de por qué este documento se consideró publicable, ha sido una técnica bien conocida durante años, pero esta es al menos una explicación convenientemente enlazable

Un receptor puede prescindir de los datos de las subtramas 4 y 5 del mensaje de navegación (Almanac, Iono, UTC offset, banderas de salud, corrección de mensajes, mensajes de texto). También puede prescindir de la memoria no volátil y del reloj en tiempo real. Estas simplificaciones degradarán el rendimiento de varias formas:

  1. Si el almanaque, la última posición conocida o la estimación de tiempo actual no están disponibles, el receptor debe realizar una adquisición en frío al encenderse. Tomará más tiempo obtener una solución inicial.
  2. Si no se utilizan los datos del almanaque, el receptor no tendrá idea de cuándo buscar naves espaciales que se eleven por encima del horizonte. Tendrá que usar más de sus correladores para buscar nuevas señales todo el tiempo.
  3. No utilizar la corrección ionosférica deteriorará la precisión del posicionamiento.
  4. No usar los datos UTC significa que el receptor solo conoce la hora GPS (que difiere de la UTC por varios segundos y no tiene segundos bisiestos)
  5. Las banderas de salud y la tabla de corrección son formas de lidiar con el mal funcionamiento de la nave espacial. No decodificarlos significa que el sistema es menos robusto.

La descarga de estos datos no es un proceso activo. El receptor tiene que mantener la sincronización en los límites de bit y en el marco de todos modos. Entonces obtienes los bits gratis. La decodificación de los datos es computacionalmente económica en comparación con el procesamiento que se necesita para rastrear la señal. No hará mucha diferencia con respecto a la eficiencia energética. Sin embargo, el impacto en el tamaño del código de firmware es notable, ya que hacer que todo sea correcto requiere bastantes líneas de código.

Una vez que se completa el almanaque, el receptor solo necesita monitorear el campo TOA de 8 bits, que se garantiza que cambiará para cada nueva versión. Los nuevos datos suelen estar disponibles cada 24 horas (este intervalo no es fijo).

El receptor no tiene que empezar de nuevo si la recepción es inestable. Todos los satélites transmiten el mismo Almanaque sincrónicamente (que no es óptimo en mi humilde opinión). Se pueden utilizar datos de almanaque parciales. Los receptores normalmente utilizarán los últimos datos disponibles para cada subpágina, que puede ser una combinación de varias versiones de almanaque.

¿El almanaque contiene solo el desplazamiento UTC o el tiempo UTC completo? Encuentro información contradictoria sobre eso, y tal vez alguien aquí lo sepa mejor. Estoy hablando del almanaque, subtrama 4, no de la señal gps "normal".
@TJJ No te equivoques t o t (subtrama 4 página 18) como hora actual , es hora de referencia para la aplicación de correcciones de primer orden A 1 . Si no cuenta la palabra de traspaso CÓMO como parte del almanaque, entonces no hay hora actual en el almanaque. CÓMO (enviado en cada subtrama) da la hora de la semana TOW truncada a múltiplos de 6 segundos, pero puede inferir la falta de precisión hasta el momento del código de difusión (1/1,023,000 seg). Y para saber la semana, necesitas el subtrama 1.
@TJJ Al leer su comentario por segunda vez, creo que está preguntando "compensación frente a tiempo completo". La respuesta a esto es "solo compensación", tiempo de GPS a compensación UTC para ser específicos. Y solo a partir de los bits de datos del almanaque (sin usar el CÓMO), no puede saber cuándo se envió (ni en tiempo de GPS ni en UTC).
Almanaque GPS versus búsqueda en el cielo
RespuestasAquíPolítica de privacidad1y, 2v