"Mismo vuelo, misma base, mismo software de procesamiento, mismo operador. Solo cambiamos la forma de convertir el archivo BIN. La tasa FIX pasó de 34% a 91%. Ese día dejamos de usar el conversor del fabricante para siempre."
En el procesamiento PPK (Post-Processing Kinematic) de vuelos de drones, el flujo de trabajo estándar que prácticamente toda la industria sigue es simple: el dron aterriza, el software del fabricante —DJI Assistant, Autel Mission Hub, WingtraOne Toolkit, o similares— genera un archivo RINEX a partir del log de vuelo, y ese RINEX se carga en el software de procesamiento junto con los datos de la estación base.
Durante meses, en Terraplaniq procesamos cientos de vuelos siguiendo ese flujo exacto. Los resultados eran inconsistentes: algunos vuelos llegaban a 85-92% FIX sin problemas, pero un porcentaje preocupante de misiones —especialmente en zonas con geometría satelital no ideal— se quedaba atascado en FLOAT permanente, incluso con base cercana, buen PDOP y condiciones de cielo despejado.
Optimizamos máscaras de elevación. Ajustamos el ratio AR. Probamos distintos modelos troposféricos. Cambiamos la configuración de RTKLIB. Nada funcionaba de manera consistente. El problema no estaba en el software de procesamiento: estaba en los datos que le estábamos dando.
La hipótesis surgió de una pregunta aparentemente simple: ¿el archivo RINEX que genera el software del fabricante contiene realmente todos los datos que rastreó el receptor GNSS del dron?
Para responderla, tomamos un vuelo con resultado FLOAT persistente (34% FIX en diez intentos de procesamiento distintos) y lo procesamos de dos maneras:
- Método A: RINEX generado por el software oficial del fabricante del dron (el flujo de trabajo estándar de la industria).
- Método B: Conversión del archivo BIN raw del receptor directamente a RINEX 3.05, preservando todas las observaciones sin ningún tipo de filtrado ni procesamiento intermedio.
Todo lo demás fue idéntico: misma estación base, mismo software de procesamiento, mismos parámetros, mismo operador.
La diferencia no fue marginal. Fue un cambio de un resultado inutilizable a un resultado de precisión centimétrica con el mismo vuelo. Esto dejó de ser una curiosidad técnica para convertirse en el núcleo del motor de conversión de TerraPPK.
Para entender por qué ocurre esto es necesario entender la evolución del formato RINEX (Receiver Independent Exchange Format). RINEX 2.11 —el formato que todavía generan muchos software de fabricantes— fue diseñado en los años 90 para receptores GPS únicamente. Su estructura de encabezado tiene un campo fijo para el tipo de observación, con códigos de dos caracteres que cubren las frecuencias clásicas de GPS.
El problema es que los receptores GNSS modernos que llevan los drones de precisión —u-blox ZED-F9P, chips propietarios DJI, receptores Septentrio embarcados— rastrean simultáneamente cuatro o más constelaciones con múltiples frecuencias:
RINEX 3.05 resuelve esto mediante códigos de observación de 3 caracteres que identifican unívocamente la constelación, la frecuencia y el tipo de medición (fase portadora, pseudodistancia, Doppler, intensidad de señal). El código L5Q significa: portadora de fase (L), frecuencia L5 (5), codificación Q (Q). No hay ambigüedad, y el conversor sabe exactamente qué datos del receptor mapear a qué campo del archivo.
Cuando el software del fabricante convierte a RINEX desde su propio pipeline interno —en lugar de desde el BIN raw— frecuentemente solo exporta las señales GPS L1/L2, descarta o agrupa incorrectamente las señales de otras constelaciones, y el archivo resultante parece correcto sintácticamente pero está vacío de la mayor parte de la información disponible en el receptor.
El procesamiento PPK resuelve un problema de estimación estadística: dadas las mediciones de fase portadora del rover (el dron en vuelo) y la base estacionaria, ¿cuáles son los valores enteros de las ambigüedades de ciclo entero N que minimizan los residuos? Cuando esas ambigüedades quedan fijadas a valores enteros, el resultado se llama FIX y la precisión es centimétrica. Cuando no se pueden fijar con suficiente confianza estadística, el resultado es FLOAT y la precisión es decimétrica o peor.
El algoritmo estándar para resolver esto es LAMBDA (Least-squares AMBiguity Decorrelation Adjustment), desarrollado por Peter Teunissen en 1995 en la TU Delft. LAMBDA busca en el espacio de enteros la solución óptima usando una transformación de decorrelación que reduce drásticamente el espacio de búsqueda. Al final del proceso, calcula un ratio de validación: la relación entre la segunda mejor solución entera y la mejor. Cuando ese ratio supera un umbral (típicamente 3.0 en RTKLIB), la ambigüedad se declara FIX.
¿Qué determina si el ratio supera ese umbral? La calidad y cantidad de ecuaciones de observación independientes. Cada satélite adicional de cualquier constelación que se pueda usar en la doble diferencia agrega una ecuación. Cada frecuencia adicional del mismo satélite agrega otra ecuación. Con el doble de satélites visibles (porque ahora incluimos Galileo y BeiDou), el sistema tiene mucho más redundancia y la solución LAMBDA converge a FIX con mayor confianza.
Tras publicar internamente estos resultados, surgió una pregunta legítima del equipo: "Pero algunos drones ya generan RINEX 3.05 nativamente desde el firmware. ¿Por qué esos también dan FLOAT a veces?"
La respuesta es importante y sutil: el formato RINEX 3.05 no garantiza que el contenido sea correcto ni completo. Un archivo puede cumplir al 100% la especificación IGS de RINEX 3.05 —tener la cabecera bien formada, los códigos de observación correctos, la estructura de épocas adecuada— y aun así contener datos silenciosamente corruptos o incompletos.
Lo que encontramos en varios firmware de drones que generan "RINEX 3.05 nativo" es que el archivo resultante declara en el header tipos de observación como L1C L2W E1C E5aQ pero en las épocas de datos, las filas de Galileo y BeiDou están vacías o rellenas con ceros. Es un RINEX 3.05 formalmente válido, pero con la misma información útil que un RINEX 2.11 de GPS solo.
En esos casos, reconvertir el BIN directamente —sin pasar por el pipeline del firmware— es la única manera de recuperar las observaciones reales que rastreó el chip.
Conclusión clave: No es el formato del archivo RINEX lo que determina la tasa FIX. Es la integridad y completitud de las observaciones que ese archivo contiene. El archivo BIN del receptor es el único testigo fiel de lo que rastreó el chip durante el vuelo. Cualquier conversión intermedia es una oportunidad de pérdida de datos.
log raw del chip — no borrar hasta tener resultados FIX confirmados
sin filtrado · sin suavizado · todas las constelaciones y frecuencias
IGS · CORS · o base propia
RTKLIB / TerraPPK Engine
La razón por la que la industria no ha popularizado este hallazgo tiene una explicación estructural. La mayoría de motores de procesamiento PPK comerciales —incluidos los integrados en paquetes fotogramétricos ampliamente usados— tratan la conversión a RINEX como una etapa interna no expuesta: aceptan el archivo RINEX que el software del fabricante del dron ya produjo y pasan directamente al ajuste de ambigüedades. El paso que está destruyendo los datos queda fuera del alcance del ingeniero.
Cuando el resultado llega a FLOAT, el mensaje suele reducirse a "no se pudieron fijar las ambigüedades" — sin instrumentación para identificar si la causa es la geometría, el firmware de origen, o el conversor RINEX intermedio. Si el pipeline es cerrado, todas las decisiones —qué frecuencias conservar, qué LLI respetar, qué modelo estocástico aplicar— están codificadas internamente por el fabricante del software, con presets que funcionan bien en el caso promedio y fallan silenciosamente en los casos que se apartan del promedio.
TerraPPK llegó a este descubrimiento porque su módulo de conversión BIN→RINEX fue diseñado desde el inicio como una etapa independiente y configurable — no como una caja negra previa al procesamiento. Varios de los clientes que nos contactan cada mes llegan después de semanas intentando procesar vuelos con herramientas cerradas sin resultado, y el diagnóstico termina recurrentemente en lo mismo: el RINEX del fabricante estaba descartando más de la mitad de las observaciones útiles. Reconvertir el BIN devuelve la solución FIX sin tocar el vuelo. El hallazgo no es una optimización marginal: es la consecuencia natural de exponer al usuario una etapa que otras plataformas han elegido ocultar.
Si tienes el archivo BIN del vuelo, nunca uses directamente el RINEX que genera el software del fabricante para procesamiento PPK. Reconviértelo a RINEX 3.05 con un conversor que preserve todas las constelaciones y frecuencias del chip original, sin filtrado ni suavizado intermedios.
El archivo BIN es el activo más valioso que tienes después de un vuelo. El RINEX del fabricante es, en el mejor de los casos, una versión incompleta de ese activo. En el peor caso, como hemos demostrado, puede ser la razón por la que llevas semanas sin poder obtener un resultado FIX.
Este hallazgo es el núcleo de la funcionalidad de conversión BIN que implementamos en TerraPPK 1.1.0. No es una función de conveniencia — es la diferencia entre un resultado útil y un resultado inutilizable con los mismos datos de campo.
