"La base era un Trimble R10 de última generación. El rover, un DJI M350 RTK. Dos receptores excelentes. Y sin embargo el procesamiento no pasaba de FLOAT. El problema no estaba en el hardware: estaba en que ambos receptores hablaban dialectos GNSS ligeramente distintos — y RTKLIB estaba tratando de interpretar los dos como si fueran el mismo."
En Terraplaniq procesamos vuelos con bases de múltiples orígenes — estaciones CORS oficiales, IGS, y bases de cliente que, en topografía geodésica profesional, muchas veces son receptores Trimble (R10, R12, R12i, NetR9) por ser el estándar de facto. El rover, en cambio, típicamente es un dron DJI M300 / M350 / P4 RTK con receptor u-blox ZED-F9P o variante propietaria DJI.
Ambos receptores son excelentes en su categoría. Pero no observan el mismo conjunto de señales de la misma manera. Cuando intentamos resolver ambigüedades por doble diferencia en RTKLIB, los resultados eran erráticos: algunos vuelos daban FIX limpio al primer intento, otros quedaban atrapados en FLOAT permanente incluso con base a menos de 5 km, cielo despejado y PDOP < 2.
Tras reunir logs de decenas de procesamientos —exitosos y fallidos— identificamos tres ajustes de configuración que, combinados, recuperaron el FIX de forma consistente. Este artículo documenta cada uno con su fundamento técnico y la evidencia de campo.
El primer patrón que detectamos fue contraintuitivo. Si activábamos la resolución de ambigüedades GLONASS en RTKLIB (pos1-glomodear = on o ARMODE_ON), el procesamiento colapsaba a FLOAT. Si la desactivábamos, el FIX volvía.
Esto rompe la lógica ingenua de que "más constelaciones = más satélites = mejor FIX". GLONASS estaba empeorando el resultado, no mejorándolo. La pregunta: ¿por qué?
A diferencia de GPS, Galileo y BeiDou —que usan CDMA (Code Division Multiple Access), donde todos los satélites de la constelación transmiten en la misma frecuencia portadora y se distinguen por el código de modulación— GLONASS usa FDMA (Frequency Division Multiple Access): cada satélite emite en una frecuencia ligeramente distinta.
Cuando una señal entra al receptor, pasa por filtros RF, amplificadores LNA y etapas de down-conversion que introducen un retardo de grupo. Ese retardo varía con la frecuencia portadora. En GPS o Galileo, todos los satélites comparten la misma frecuencia, por lo que el retardo es común y se cancela automáticamente en la doble diferencia rover-base.
En GLONASS FDMA, cada satélite usa una frecuencia distinta. El retardo RF es distinto para cada uno. Esta diferencia es el Inter-Frequency Bias (IFB). Entre dos receptores del mismo fabricante y modelo, el IFB es prácticamente idéntico y se cancela. Entre un Trimble R10 y un u-blox ZED-F9P (DJI), el IFB es distinto — los filtros RF, el firmware y la arquitectura del front-end no son los mismos.
Punto clave matemático: en la doble diferencia de fase GLONASS entre receptores de marcas distintas, la ambigüedad entera N deja de ser realmente entera. Tiene una componente fraccionaria adicional introducida por el IFB no cancelado. El algoritmo LAMBDA, que busca la mejor solución en el espacio de enteros, no encuentra ninguna candidata cuyo ratio supere el umbral de validación — y por conservadurismo mantiene la solución en FLOAT, incluso si el resto de constelaciones están listas para FIX.
La solución no es descartar GLONASS por completo —eso sería desperdiciar ~8-10 satélites adicionales de geometría. La solución es usar GLONASS para el posicionamiento (contribuye a la solución float) pero no intentar fijar sus ambigüedades a enteros. En RTKLIB:
Con este ajuste, GLONASS aporta pseudodistancias y fases para estabilizar la solución float, pero el proceso de resolución entera se limita a las constelaciones CDMA —donde la doble diferencia sí cancela los sesgos de frecuencia. El ratio LAMBDA sube drásticamente porque ya no hay ambigüedades GLONASS "contaminadas" tirando del ratio hacia abajo.
Con GLONASS-AR ya desactivado, ciertas épocas seguían quedando en FLOAT: tramos de vuelo cerca de taludes, bordes de zonas con vegetación, o cambios de altitud. Al examinar los residuos en el archivo de estadísticas de RTKLIB, vimos un patrón: muchas observaciones marcadas como "rechazadas por SNR mask", y residuos grandes en las que pasaban.
Dos efectos se estaban combinando:
- SNR mask demasiado duro: el umbral por defecto (35 dB-Hz) descarta observaciones perfectamente usables cuando el drone está en maniobra y la antena no mira directamente al satélite. Menos observaciones → menos geometría → ratio LAMBDA bajo.
- AutoCal desactivado: las correcciones sistemáticas (mareas terrestres, PCV de antena, troposfera) no se estaban aplicando. Los residuos tenían componentes no-aleatorias que RTKLIB interpretaba como incertidumbre de la fase, y el modelo estocástico perdía confiabilidad.
"AutoCal" es el nombre interno que usamos en Terraplaniq para el conjunto de correcciones automáticas de RTKLIB —las opciones posopt1 a posopt6. Cada una corrige una fuente sistemática de error:
Por qué esta combinación funciona: el modelo estocástico de RTKLIB ya pondera internamente las observaciones según su SNR (a mayor SNR, menor varianza asignada a la ecuación). No hace falta el filtro duro del SNR mask, que elimina observaciones sin reposición. En su lugar, dejamos que RTKLIB incluya todas las observaciones y las pondere. Con los sesgos sistemáticos corregidos por AutoCal, los residuos se comportan realmente como ruido blanco — y el ratio LAMBDA puede usar el incremento de geometría sin penalización.
Evidencia de campo: en un vuelo de 38 min con taludes y bordes de vegetación, desactivar SNR mask + activar AutoCal aumentó las observaciones válidas por época de ~22 a ~31 (+41%). El ratio LAMBDA promedio pasó de 2.1 a 4.6. La tasa FIX saltó de 58% a 89% — sin cambiar nada del vuelo ni del hardware.
En algunos proyectos —particularmente fuera de Asia-Pacífico— observamos el patrón inverso: activar BeiDou empeoraba el resultado. Investigando, identificamos dos razones técnicas diferenciadas.
Razón A: la coexistencia BDS-2 / BDS-3. BeiDou tiene dos generaciones operativas que conviven:
- BDS-2 (BeiDou-2): sistema regional — satélites GEO (geoestacionarios sobre Asia) e IGSO (inclinados geosincrónicos). Señales B1I, B2I, B3I.
- BDS-3 (BeiDou-3): sistema global — satélites MEO (órbita media terrestre). Señales B1C, B2a, B2b, B3I.
Un Trimble R10 con firmware reciente rastrea ambas generaciones. El DJI M350 puede rastrear principalmente BDS-3 MEO (dependiendo del firmware y versión del chip). Cuando RTKLIB intenta la doble diferencia, no encuentra parejas consistentes para BDS-2 — y los satélites BDS-2 que logra parear aportan observaciones ruidosas que degradan el modelo.
Razón B: geometría BDS-2 en Sudamérica. Los satélites GEO de BeiDou-2 están fijos sobre Asia. Desde Perú o Colombia se ven a elevaciones muy bajas (5-15°) o no se ven en absoluto. Las observaciones de elevación tan baja sufren:
- Multipath severo — la señal rebota en terreno, edificios, masas de agua.
- Retardo troposférico residual elevado — el modelo Saastamoinen degrada su precisión a elevaciones <15°.
- Fase portadora poco estable — mayor probabilidad de cycle slips no detectados.
| Escenario | GLONASS-AR | SNR mask | AutoCal | BeiDou |
|---|---|---|---|---|
| Base Trimble + rover DJI | OFF | OFF | ON | Selectivo |
| Base y rover misma marca | ON | Default | ON | ON |
| Vuelo en Sudamérica | OFF | OFF | ON | OFF / elmask 25° |
| Vuelo en Asia-Pacífico | ON* | Default | ON | ON |
| Muchas obstrucciones / dosel | OFF | OFF | ON | Selectivo |
* Solo si base y rover comparten IFB calibrado (mismo fabricante o tabla IFB cargada).
La razón más frecuente por la que estos tres ajustes no están disponibles en la mayoría de software PPK del mercado es puramente arquitectónica: los motores comerciales cerrados fijan internamente decisiones como el modo de AR para GLONASS, el tratamiento del SNR mask, la política de constelaciones activas o el preset de ponderación estocástica. Esas decisiones viven en el binario, no en un archivo de configuración del usuario. El ingeniero no las puede tocar — fueron tomadas en tiempo de desarrollo por el equipo del fabricante, con valores que funcionan bien "en promedio" y dejan de funcionar en cuanto el proyecto se aleja de ese promedio.
Esa rigidez es manejable mientras base y rover son de la misma marca, el vuelo está en la región para la que los presets fueron calibrados, y el hardware del drone no impone exigencias particulares al modelo estocástico. En cuanto una de esas tres condiciones cambia —base Trimble geodésica + rover u-blox en DJI, vuelo fuera de Asia-Pacífico donde BDS-2 GEO castiga la solución, o dosel vegetal que deprime el SNR— el procesamiento se estanca en FLOAT sin que el usuario pueda intervenir. El diagnóstico típico es frustrante: los datos están ahí, la geometría es buena, pero el motor no ofrece la palanca para corregir el ajuste.
El motor de TerraPPK se construyó con la convicción opuesta. Cada parámetro que describimos arriba —GLONASS-AR independiente, SNR mask relajable, navsys granular, posopt configurable por escenario, modelo estocástico ajustable— está expuesto, documentado y acompañado de presets sugeridos por combinación de hardware detectada. Esos presets no salieron de un manual: son la agregación de proyectos reales que llegaron a Terraplaniq después de haberse estancado en software cerrados. Mineras con bases Trimble R12 y flotas DJI. Topógrafos con receptores Emlid conectados a drones WingtraOne. Proyectos forestales en selva amazónica donde ninguna herramienta comercial mantenía el FIX. Cada uno aportó un caso, cada caso obligó a afinar un parámetro, y ese parámetro quedó disponible para el siguiente usuario que enfrente un escenario similar.
Esa es la lógica iterativa del Laboratorio TerraPPK: el software no mejora por un roadmap predefinido, mejora por exposición a condiciones de campo heterogéneas. Cada FLOAT convertido en FIX ha dejado su huella en el motor. Es el motivo por el que escenarios que derrotan a las herramientas rígidas —base de una marca, rover de otra, región geográfica atípica— aquí son simplemente otro preset del panel.
No existe una configuración de RTKLIB que sea óptima para todos los vuelos. La configuración depende del par específico de base + rover, de la ubicación geográfica y de las condiciones del entorno. Lo que hace la diferencia no es un único parámetro: es entender por qué cada ajuste existe, qué fenómeno físico corrige, y cuándo aplicarlo.
Los tres hallazgos documentados en este artículo forman un sistema — no funcionan de forma aislada. GLONASS-AR off resuelve el problema del IFB. AutoCal + SNR mask off preserva la geometría sin arrastrar sesgos sistemáticos. La gestión selectiva de BeiDou evita satélites de baja calidad en regiones donde su geometría es subóptima. Es la combinación de los tres lo que devuelve el FIX en escenarios donde el preset por defecto falla.
En TerraPPK 1.1.0 hemos automatizado la detección de estos escenarios: cuando el motor identifica una base Trimble y un rover DJI, y detecta la región geográfica del vuelo, propone este preset como configuración por defecto. El ingeniero sigue teniendo control total, pero parte de una base técnicamente correcta en lugar de los valores genéricos de RTKLIB.
Si tienes un vuelo con base Trimble u otra marca de receptor geodésico y el resultado se queda en FLOAT, este es el primer conjunto de ajustes que te recomiendo probar. Documenta tus resultados y escríbenos — el Laboratorio TerraPPK sigue creciendo con datos reales de campo.
