"Tu dron genera RINEX 3.05. Lo inspeccionas con un editor de texto y tiene buen aspecto: header correcto, códigos de observación en orden, épocas bien estructuradas. Lo procesas y obtienes FLOAT. Procesas el BIN con TerraPPK y obtienes FIX. El formato era idéntico. Los datos no."
Existe una confusión muy extendida en la industria del procesamiento GNSS para drones: creer que "RINEX 3.05 compliant" equivale a "datos de máxima calidad para PPK". Esta confusión es comprensible —RINEX 3.05 es el estándar más moderno del IGS para datos GNSS— pero es técnicamente incorrecta.
Un archivo puede cumplir perfectamente la especificación RINEX 3.05 y aun así contener datos que harán imposible obtener una solución FIX. El problema no es el formato. El problema es lo que el firmware del dron hace con los datos antes de escribirlos en ese formato.
A continuación documentamos los seis problemas que encontramos en múltiples modelos y marcas de drones, todos ellos silenciosos —el archivo pasa cualquier validador de formato RINEX— y todos ellos capaces de destruir por completo la tasa FIX de un procesamiento PPK.
datos raw completos: ~30-40 observaciones por época, todas las constelaciones
filtra señales débiles · suaviza pseudodistancias · aplica su propio modelo de cycle slip · usa reloj del sistema
LLI erróneos · Doppler ausente · timestamps desfasados · ARP = 0
sin filtrado · timestamps del TOW del receptor · LLI del hardware · todas las frecuencias
observaciones completas · LLI reales · Doppler preservado · timestamps GNSS
El LLI (Loss of Lock Indicator) es un campo de 1 bit en el encabezado de cada observación de fase portadora en el archivo RINEX. Cuando el receptor pierde el enganche de fase —algo que puede ocurrir por obstrucción física, multipath severo, cambio de ganancia del receptor o una maniobra brusca del dron— el LLI se pone en 1, indicando que la continuidad del arco de fase se ha roto y que la ambigüedad de ciclo entero debe reiniciarse.
El problema que encontramos en múltiples firmware es que marcan el LLI como 1 basándose en heurísticas propias del sistema de navegación del dron, no en el estado real del receptor GNSS. Cuando el firmware detecta una maniobra (giro, aceleración, cambio de altitud), activa el flag LLI en todas las observaciones de esa época —independientemente de si el receptor realmente perdió el enganche o no.
Para RTKLIB, un LLI = 1 es una instrucción inequívoca: reinicia las ambigüedades. En un vuelo dinámico con múltiples maniobras, esto puede significar decenas de reinicios artificiales por hora. Cada reinicio requiere suficientes épocas para volver a converger a FIX. En vuelos cortos o con poca geometría satelital, el sistema nunca llega a FIX de forma estable.
Señal de alerta: Si en el output de RTKLIB ves muchos eventos "phase reset" o "AR reset" que no corresponden con obstrucciones visibles en el log de vuelo, el problema casi con certeza son LLI flags incorrectos en el RINEX del firmware. La solución es reconvertir desde el BIN, donde el LLI viene directamente del estado hardware del receptor.
El suavizado de pseudodistancias con fase portadora (carrier-smoothing o Hatch filter) es una técnica legítima y útil en navegación en tiempo real: reduce el ruido de las pseudodistancias código usando la suavidad de la fase portadora, mejorando la precisión de posicionamiento en modo standalone. Está bien para un GPS de teléfono. Es un desastre para PPK.
Cuando el firmware aplica carrier-smoothing antes de escribir las pseudodistancias en el RINEX, introduce una correlación temporal artificial entre épocas consecutivas. El modelo estocástico que usa RTKLIB (y cualquier software PPK) asume que los errores de medición son independientes entre épocas. Esa independencia es la base matemática sobre la que funciona el filtro de Kalman.
Con pseudodistancias suavizadas, las ecuaciones de observación se vuelven estadísticamente dependientes. Los residuos del filtro de Kalman no se comportan como ruido blanco. El proceso de validación de la ambigüedad LAMBDA recibe información sistemáticamente incorrecta sobre la dispersión de los errores y tiende a subestimar la calidad del FIX, por lo que mantiene la solución en FLOAT como medida de conservadurismo.
Cada época de un archivo RINEX tiene una marca de tiempo que indica cuándo se realizaron las observaciones. Para que el procesamiento PPK funcione correctamente, los timestamps del rover (el dron) y de la base deben ser coherentes con el mismo marco temporal GNSS (GPS Time of Week, TOW).
Muchos firmware de drones escriben los timestamps de las épocas usando el reloj del sistema operativo del ordenador de vuelo —el mismo reloj que gestiona el control del dron, la telemetría y el almacenamiento de datos. Ese reloj tiene un offset respecto al TOW del receptor GNSS que puede llegar fácilmente a 3-7 milisegundos, dependiendo de la carga computacional del dron en ese momento.
Parece poco, pero con señales que se mueven a la velocidad de la luz, 5 ms de error en el timestamp equivalen a ~1.5 km de error en la sincronización de las observaciones. RTKLIB intenta interpolación temporal entre épocas rover y base, pero cuando el offset supera el intervalo de grabación del receptor (típicamente 10 ms para 100 Hz o 200 ms para 5 Hz), la sincronización falla completamente y el procesamiento no converge.
El campo D (Doppler) en RINEX representa la tasa de cambio de la fase portadora — esencialmente, la velocidad radial entre el satélite y el receptor. En modo estático, el Doppler es de valor limitado. En vuelo dinámico, es fundamental.
El principal uso del Doppler en procesamiento PPK es la detección de cycle slips entre épocas consecutivas. Si la diferencia de fase entre dos épocas es inconsistente con el Doppler medido (que predice cuánto debería haber cambiado la fase en ese intervalo de tiempo dada la velocidad del dron), el software sabe que ha ocurrido un slip y puede tratarlo correctamente.
Cuando el firmware no exporta el campo Doppler al RINEX —algo que encontramos en varios modelos populares— la detección de cycle slips se vuelve ciega durante el vuelo. RTKLIB solo puede intentar detectarlos por inconsistencia de fase entre épocas consecutivas, lo cual en drones con velocidades de 10-15 m/s no es suficientemente fiable. El resultado: arcos de fase con slips no detectados que contaminan la estimación de la ambigüedad.
Este es quizás el problema más engañoso porque es perfectamente invisible en una inspección rápida del archivo. El RINEX del firmware puede declarar en el header que incluye observaciones de GPS, Galileo y BeiDou, con múltiples códigos de observación listados. Y cuando abres las épocas de datos, ves filas para satélites de cada constelación.
El problema es que esas filas de datos de Galileo y BeiDou están rellenas de ceros o de campos vacíos. El firmware declaró los tipos de observación que el chip es capaz de producir, pero en la práctica solo exportó los datos de GPS L1 (y a veces L2). El volumen real de información útil es el mismo que en un RINEX 2.11 de GPS single-frequency.
Hemos encontrado esta situación en firmware que fue actualizado por los fabricantes para "añadir soporte RINEX 3.05" sin cambiar fundamentalmente su pipeline de conversión. El resultado es un archivo que pasa todos los tests de validación de formato pero no aprovecha en absoluto las capacidades multi-constelación del receptor hardware.
El ARP (Antenna Reference Point) es la posición física conocida de la antena en el dron. En el header de RINEX, hay campos opcionales para especificar el vector offset entre el ARP y el centro de fase de la antena para cada frecuencia (ANTENNA: DELTA H/E/N). Para receptores GNSS de precisión, este offset puede ser de varios centímetros —y si no se corrige, introduce un error sistemático constante en la solución PPK.
La mayoría de firmware de drones escriben este campo como (0.000, 0.000, 0.000) por defecto, indicando que no hay offset — lo cual es casi siempre incorrecto para receptores integrados en el dron. El centro de fase real del receptor no coincide con el punto de referencia físico de la antena.
El impacto en la tasa FIX es indirecto pero real: el modelo de corrección de fase en RTKLIB usa estos valores para eliminar la componente sistemática de error. Con ARP = 0, el modelo de fase es incorrecto en cada observación, los residuos son mayores de lo que deberían, y el ratio de validación de la ambigüedad LAMBDA queda consistentemente por debajo del umbral de FIX.
Antes de procesar cualquier vuelo, estos son los campos que inspeccionamos en TerraPPK para validar la calidad del RINEX:
Regla de oro del Laboratorio TerraPPK: "RINEX 3.05 compliant" es una propiedad del formato. La calidad para PPK es una propiedad de los datos. Antes de culpar al software de procesamiento, al modelo troposférico o a la geometría satelital, verifica que tu archivo RINEX contiene realmente lo que debería. El BIN original no miente.
Ninguno de los seis problemas documentados arriba está descrito en la documentación oficial de los firmware de dron, ni aparece como verificación automática en la mayoría de software PPK del mercado. La arquitectura típica de esos motores es opaca a la entrada: leen el RINEX, lo procesan, y devuelven una trayectoria o un mensaje genérico de error. No hay visor de LLI por época, no hay comparador de timestamps contra TOW, no hay alerta automática de ARP = 0, no hay control sobre el modelo estocástico cuando el SNR del RINEX está dañado. Todo eso está hardcodeado en el binario — configurado una vez por el equipo de desarrollo del fabricante, con valores que funcionan en el caso promedio y dejan al ingeniero sin herramientas cuando el caso se aparta.
El flujo de diagnóstico que describimos en este artículo existe en TerraPPK porque se construyó iterativamente a partir de vuelos reales de clientes. Cada uno de los seis problemas apareció primero en un caso concreto: un M300 que no fijaba en un proyecto minero, un WingtraOne cuyos timestamps derivaban bajo carga del SO, un vuelo en selva amazónica con cycle slips que el RINEX no marcaba, una base cuyo ARP estaba en cero porque el firmware no lo escribió. Cada caso obligó a añadir una verificación al motor. Hoy ese conjunto de validaciones corre como paso previo al procesamiento — porque sin él la salida depende demasiado del azar de qué tan "honesto" fue el firmware que generó el archivo.
Lo que en otras plataformas es una caja cerrada, en TerraPPK es un panel de inspección. Esa diferencia no es estética — es lo que explica por qué vuelos que en herramientas tradicionales se quedaron en FLOAT llegan a FIX cuando pasan por el diagnóstico, la reconversión correcta del BIN, y el reajuste del modelo estocástico.
Los seis problemas documentados en este artículo no son errores de formato —son decisiones de diseño de firmware que optimizan para casos de uso distintos al procesamiento PPK de precisión. Los fabricantes de drones diseñan el pipeline de conversión RINEX para que funcione con sus propios software de misión, no para maximizar la tasa FIX en software de geodesia de precisión.
La solución no es culpar a los fabricantes: es tener las herramientas adecuadas para extraer los datos correctos del archivo que el receptor hardware realmente generó. El BIN es la fuente de verdad. Todo lo que viene después es una interpretación de esa fuente. Cuantas menos interpretaciones intermedias haya entre el chip y el software de procesamiento, mejor será el resultado.
Este artículo documenta lo que encontramos en campo. Si tienes vuelos con FLOAT persistente y quieres analizarlos con nosotros, escríbenos directamente.
