"El piloto programa una misión de 90 segundos sobre una torre eléctrica. El dron despega, cubre la grilla, aterriza. Descarga el archivo, procesa el PPK — el reporte termina con 0% FIX. Repite la misión idéntica al día siguiente con el dron encendido 8 minutos antes del despegue. Mismo equipo, mismo cielo, mismo software: 96% FIX. La diferencia no estuvo en el vuelo. Estuvo en lo que el piloto hizo antes de apretar 'takeoff'."
Existe un patrón de fallo que se repite con una regularidad casi ceremonial en los proyectos que llegan a nuestra mesa: vuelos de 1 a 3 minutos —típicos en inspección de torres, líneas de transmisión, obras lineales pequeñas, drones compactos para fotogrametría acotada, missions repetitivas en zonas restringidas— que terminan con el reporte de procesamiento PPK marcando FLOAT en toda la trayectoria, o con ratios de FIX bajísimos (5-30%). El piloto intuye que "el archivo salió mal", cambia de software, revisa la base, repite el vuelo. El resultado es el mismo.
El problema no está en el equipo ni en el software. Está en un hecho físico que ninguna plataforma PPK publicita con suficiente énfasis: la resolución de ambigüedades enteras GNSS requiere un tiempo mínimo de observación que no depende de la voluntad del piloto, sino de la geometría satelital, del número de constelaciones observadas y de la calidad del modelo ionosférico/troposférico que el procesador puede estimar con los datos disponibles. Por debajo de ese umbral temporal, el filtro estadístico no llega a tensar el estado lo suficiente como para que la prueba de ratio LAMBDA supere el umbral de validación — y el resultado formal es FLOAT, aunque el receptor haya estado rastreando impecablemente.
Todo motor PPK moderno —RTKLIB, Trimble Business Center, Inpho UASMaster, DJI Terra, Emlid Studio, TerraPPK— opera internamente como un filtro de Kalman extendido (EKF) que estima simultáneamente varios grupos de estados: posición del rover (x, y, z), velocidad, ambigüedades enteras de fase portadora para cada satélite rastreado, retardos troposféricos residuales, sesgos de reloj del receptor, y —en motores avanzados— combinaciones de frecuencias para atacar la ionósfera. Al arrancar el proceso, todos esos estados se inicializan con varianzas muy grandes: el filtro "no sabe" casi nada y cada observación nueva le entrega información para estrechar esas varianzas.
La resolución de ambigüedades enteras (Integer Ambiguity Resolution, AR) sucede en dos pasos encadenados. Primero se estima una solución flotante donde las ambigüedades son tratadas como reales (no enteras). Luego se aplica el algoritmo LAMBDA (Least-squares AMBiguity Decorrelation Adjustment, Teunissen 1995) que busca el vector entero más probable dentro de un espacio de búsqueda definido por la matriz de covarianza del float. Ese candidato se valida con la prueba de ratio: el cociente entre la distancia al segundo mejor candidato y la distancia al mejor. Si el ratio supera un umbral (típicamente 3.0 en RTKLIB; Takasu 2013), el FIX se declara. Si no, la época queda FLOAT.
Aquí está la trampa temporal: la calidad de ese ratio depende de qué tan decorrelacionado esté el espacio de búsqueda, y esa decorrelación depende a su vez de cuánta variación geométrica han aportado las observaciones. Los satélites GPS se mueven aproximadamente 15°/hora — lo que significa que en 2 minutos el cambio angular es de apenas 0.5°. Con variación geométrica tan baja, las columnas de la matriz de diseño son casi colineales, la matriz de covarianza del float tiene direcciones pobremente condicionadas, y LAMBDA encuentra que el segundo candidato está estadísticamente muy cerca del primero. El ratio no supera 3.0 y toda la trayectoria cae a FLOAT.
Regla física: el FIX no depende solo de cuántos satélites se ven, sino de cuánto se movieron durante la ventana de observación. En 90 segundos los satélites no se mueven lo suficiente para que LAMBDA decorrelacione el espacio de búsqueda. Es matemáticamente imposible tensar el ratio en ese tiempo salvo bajo condiciones excepcionales (cielo limpísimo, baselina corta, triple frecuencia, geometría diversa).
Los números de Time-to-First-Fix (TTFF) publicados en literatura peer-reviewed y documentados por fabricantes de motores de procesamiento convergen en rangos bien establecidos. Aquí un resumen compilado de las fuentes más citadas:
Traducción operacional: si vuelas un dron dual-frequency con multi-constelación bajo cielo abierto, el mínimo estadístico razonable para esperar FIX es 4.5-6.5 minutos de observación continua. Si tu dron es single-frequency GPS (muchos equipos compactos aún lo son), el mínimo sube a 15-22 minutos. Un vuelo de 90 segundos sobre cualquier configuración está por debajo del umbral — no por mal procesamiento, sino porque físicamente el filtro no alcanza a convergir.
Pocos fabricantes de drones publican tiempos mínimos explícitos porque el número depende de muchos factores — pero varios sí han fijado mínimos prácticos que conviene conocer. Recopilación de recomendaciones oficiales:
- DJI Enterprise (Phantom 4 RTK, M300/M350 RTK, P1, L2): el blog oficial recomienda mínimo 15 minutos de vuelo para capturar suficientes puntos GNSS para procesamiento PPK confiable. Anteriormente citaba 10 min. Exige baseline a la CORS <32 km (para drones de mapeo) y <10 km para sensores P1/L2. Fuente: enterprise-insights.dji.com
- Wingtra / WingtraOne: la base debe estar registrando más de 10 minutos antes del despegue. Para el método "Punto Conocido" retrospectivo, observación estática ≥1 hora. Para vuelos cortos, Wingtra advierte literalmente: "áreas de baja precisión no pueden ser compensadas por otras" — una admisión directa de que no hay magia de software que rescate una ventana demasiado corta.
- Propeller AeroPoints 2 (dual-frequency): mínimo 10 minutos de vuelo con Corrections Network, o 2 min con método Known Point. La generación anterior single-frequency requería 45 minutos — el salto se atribuye directamente al paso a dual-frequency.
- DroneDeploy: mínimo 10 minutos en vuelo para la región "Fast" de convergencia; 20 minutos para la región "Global". Reconoce explícitamente que la convergencia es función del número de imágenes capturadas, no solo del tiempo calendario.
- Trimble Applanix PPK: convergencia típica 15-20 minutos; precisión 3 cm H / 6 cm V confiable solo después de 30+ minutos de observación continua.
- Emlid Reach M2/RS2: la documentación reconoce resultados solo-FLOAT cuando las observaciones del vuelo o de la base son muy cortas, o cuando faltan archivos de navegación. Comunidad converge en ≥6 min para baselinas <6 km.
Lectura ingenieril: ningún fabricante serio recomienda vuelos de menos de 6 minutos para PPK, y varios (DJI Enterprise, DroneDeploy, Applanix) piden 15-20 minutos como mínimo. Los vuelos de 1-2 minutos que algunos pilotos intentan rescatar no caen dentro del perfil operacional diseñado para PPK. Están fuera de especificación — no "por poco", sino estructuralmente.
Convertir el BIN nativo del dron (archivo propietario DJI, Wingtra, Emlid) a RINEX multi-constelación mejora el panorama cuando la herramienta del fabricante había perdido Galileo, BeiDou o L5 durante la conversión por defecto. En muchos casos eso lleva la sesión de FLOAT a FIX porque añade observaciones al modelo y reduce el tiempo de convergencia según la tabla de la sección 3 (pasas de perfil dual-freq GPS a dual-freq multi-GNSS, del rango 15-22 min al rango 4.5-6.5 min).
Pero la reconversión no crea observaciones que no estaban: si tu vuelo duró 90 segundos, sigues teniendo 90 segundos de observación. Lo que gana es densidad espectral y calidad del modelo por época, no duración. En vuelos por debajo de 3-4 minutos, la reconversión por sí sola rara vez basta: el filtro sigue sin tener suficiente variación geométrica acumulada. La reconversión es necesaria pero no suficiente.
El matiz técnico: multi-constelación rebaja el piso de tiempo mínimo (menos minutos para fijar), pero existe un piso absoluto debajo del cual ni agregando constelaciones se fija — porque el espacio de búsqueda LAMBDA necesita tiempo, no solo densidad. Reconvertir el BIN es condición necesaria; extender la ventana de observación es la condición que cierra el cálculo.
La intervención más robusta —y barata— es extender artificialmente la ventana de observación sumando segmentos estáticos antes y después del vuelo dinámico. El procedimiento operacional:
- Pre-flight estático (5-10 min): encender el dron en el punto de despegue con el GNSS registrando, y dejarlo quieto —sin girar rotores, sin moverlo— durante al menos 5-10 minutos. El dron debe estar al aire libre, con vista limpia al cielo. Durante ese tiempo el receptor registra observaciones en condiciones estáticas de excelente calidad: sin cycle slips por vibración, sin saltos de SNR, con geometría plenamente observada.
- Vuelo dinámico (lo que dure la misión): el procedimiento normal. No cambia nada en la operación de vuelo — solo lo que pasa antes y después.
- Post-flight estático (5-10 min): tras aterrizar, dejar el dron encendido con el GNSS activo durante otros 5-10 minutos antes de apagarlo. Los motores pueden apagarse; lo que importa es que el receptor siga registrando.
El motivo por el que esto funciona es profundo. El filtro de Kalman procesa observaciones secuencialmente, y el procesamiento Forward+Backward combinado (implementado en RTKLIB y en TerraPPK) corre dos pasadas: una desde el inicio hacia adelante y otra desde el final hacia atrás. Takasu describe explícitamente en el manual RTKLIB que la pasada backward "normalmente aporta FIX hasta el comienzo mismo" cuando los segmentos estáticos extremos alcanzaron convergencia. Los 8 minutos que el dron estuvo quieto pre-takeoff le entregan al filtro forward suficiente ventana para fijar las ambigüedades GPS; los 8 minutos post-landing le entregan al filtro backward el mismo lujo. Cuando el vuelo dinámico de 90 segundos queda encapsulado entre dos segmentos estáticos ya convergidos, las ambigüedades fijadas se propagan a lo largo de la trayectoria por la redundancia Kalman.
El procesamiento combinado forward/backward es la técnica estándar de rescate en PPK corto — pero tiene un límite físico que pocos manuales explicitan. Takasu (rtklibexplorer, 2017) lo resume con claridad: "la pasada backward dará FIX hasta el inicio mismo de la trayectoria, siempre y cuando cualquiera de las dos pasadas haya logrado FIX en algún momento". Si ninguna pasada consigue fijar porque toda la ventana es demasiado corta, el combinado no puede inventar el FIX — no hay qué propagar.
Hay tres casos operacionales:
- Caso ideal: pre-flight ≥8 min + vuelo + post-flight ≥8 min. Forward fija durante el pre-flight, backward fija durante el post-flight, ambas propagan a través del vuelo. FIX casi garantizado bajo cielo abierto multi-constelación.
- Caso asimétrico: solo pre-flight largo (o solo post-flight). La pasada que tuvo el segmento estático fija; la otra quedará float en su tramo de arranque. El combinado decide por la varianza menor de cada época — el resultado suele ser FIX en la mayoría del vuelo.
- Caso sin estático: solo el vuelo corto de 90 s en el archivo. Ni forward ni backward tienen material para fijar. El combinado entrega FLOAT completo, aunque el procesador funciona perfectamente. Físicamente no hay rescate posible desde procesamiento.
Además, el combinado tiene una regla de validación cruzada: cuando forward y backward divergen más de 4σ en la misma época, el motor degrada esa época a FLOAT por seguridad (evita fixes falsos por asimetría entre pasadas). Eso significa que incluso con estáticos pre/post, si el cielo cambió dramáticamente entre ambos segmentos (obstrucción, cambio de constelaciones visibles), algunas épocas pueden marcar FLOAT aunque el FIX estaba técnicamente disponible.
Cuando la operación exige múltiples vuelos cortos el mismo día —típico en inspecciones repetitivas sobre distintas estructuras, o misiones con recarga de batería entre tramos— existe una segunda técnica: concatenar los archivos RINEX del rover en una única ventana extendida, preservando las marcas de evento de cada vuelo. El procesador trata toda la concatenación como una sola sesión y resuelve las ambigüedades sobre la ventana agregada — típicamente 20-40 minutos reales que sí alcanzan convergencia, aunque cada vuelo individual fuera corto.
Hay dos advertencias técnicas para que el splicing funcione:
- No apagar el receptor entre vuelos: cada apagado/encendido invalida las ambigüedades porque el chip pierde bloqueo de fase. Si el dron se apaga, el segmento siguiente reinicia el estado con ambigüedades nuevas. El splicing sirve solo si el GNSS registró continuamente (batería intercambiada en caliente o operación con receptor externo al dron).
- Cycle slip detection ante los gaps dinámicos: entre vuelos suele haber transporte manual del dron (cambio de batería, reposicionamiento). Esos segmentos generan saltos de fase. El motor debe detectarlos y marcarlos como nuevos arcos — si no, inyectan errores en el float. TerraPPK permite ajustar manualmente el umbral de detección de cycle slips para que el splicing sea limpio; muchos motores cerrados no exponen ese control.
Una limitación poco documentada de varias plataformas PPK comerciales cerradas es que el tiempo mínimo para declarar FIX está hardcoded en el motor — típicamente 30 o 60 segundos después del arranque de la sesión, sin posibilidad de ajuste por el usuario. La lógica interna asume que el piloto hará vuelos largos y que la convergencia es un fenómeno transitorio del primer minuto. Esa suposición se rompe en dos direcciones opuestas:
- Vuelos muy cortos: cuando toda la sesión dura menos que el tiempo mínimo hardcoded, el motor ni siquiera intenta fijar. Declara FLOAT por política, no por condición real.
- Condiciones adversas que requieren más tiempo: bajo dosel selvático o cañón urbano, el tiempo de convergencia real puede superar los 10-15 minutos. Si el motor corta la búsqueda de AR tras el primer fix tentativo con ratio marginal, termina declarando fixes falsos o abortando la ambigüedad en momentos donde hubiera convergido con más paciencia.
TerraPPK expone tres parámetros relevantes que en motores cerrados están fijos: min-lock (tiempo mínimo de bloqueo continuo antes de considerar un satélite para AR), min-fix (umbral de ratio LAMBDA, ajustable entre 1.5 y 5.0 según condiciones), y la ventana de historia del filtro backward. Proyectos donde otros motores entregaban FLOAT irrecuperable se han resuelto ajustando estos tres parámetros a las condiciones reales del vuelo — sin cambiar equipo, sin volver a campo, sin modificar el código fuente. Es la consecuencia directa de una filosofía de diseño distinta: exponer al usuario ingeniero los parámetros que otros han elegido ocultar.
Resumen práctico para integrar en el procedimiento estándar de cualquier operación PPK con drones, independiente de marca:
Tabla consolidada de proyectos reales procesados en el último año donde la única variable deliberadamente modificada fue la ventana total de observación (pre-flight + vuelo + post-flight). Equipo rover, base, software y parámetros idénticos entre réplicas.
Todos los vuelos procesados con TerraPPK. Rover: DJI M300 RTK + Zenmuse P1 en casos 1-4; Emlid Reach M2 sobre dron custom en casos 5-6; Trimble R12 sobre dron ala fija Quantum Trinity en caso 7; Wingtra One con Reach M2 en casos 8-9. Base: estaciones IGN cercanas o D-RTK 2 según proyecto. El patrón es consistente entre equipos: la extensión por estáticos pre/post rescata vuelos cortos que de otra forma quedan FLOAT.
Los vuelos cortos no son un defecto del software PPK — son un caso fuera del perfil operacional diseñado por los fabricantes y sustentado por la literatura científica. La resolución de ambigüedades enteras requiere tiempo para que la geometría satelital varíe lo suficiente como para decorrelacionar el espacio de búsqueda LAMBDA. Ningún procesador puede inventar variación geométrica que los satélites no produjeron.
La solución no pasa por buscar un motor mágico. Pasa por integrar en el protocolo de vuelo tres hábitos simples:
- Encender el dron en la base 8-10 minutos antes del despegue con el GNSS registrando. Costo operacional: cero. Rescate estadístico: decisivo.
- Tras aterrizar, esperar 8-10 minutos con el equipo encendido antes de apagar. El backward pass usa ese segmento para fijar y propagar hacia atrás.
- Si la misión estructural debe ser corta (inspección puntual, vuelos repetidos), ajustar el plan para que la ventana total de observación —incluyendo los estáticos— supere los 15-20 minutos.
La diferencia entre un proyecto que se certifica y un proyecto que se repite no está en el software más sofisticado. Está en esos 16 minutos adicionales que el piloto invierte en el campo sin mover la aeronave — minutos que el filtro de Kalman necesita para convergir, y que ninguna cantidad de reprocesamiento puede reemplazar a posteriori.
Si tienes un proyecto con vuelos cortos condenados a FLOAT que crees irrecuperable, escríbenos. En varios casos hemos conseguido rescatar sesiones cerradas por otros procesadores ajustando parámetros que en motores cerrados están bloqueados — pero incluso esa ruta tiene un piso físico: si no hubo observación suficiente, no hay software que invente el FIX. La prevención en campo siempre es más barata que el rescate en oficina.
Teunissen P.J.G. (1995). The least-squares ambiguity decorrelation adjustment. Journal of Geodesy 70(1-2). · Odijk D. (2002). Fast Precise GPS Positioning in the Presence of Ionospheric Delays. Publications on Geodesy 52, Netherlands Geodetic Commission. · Verhagen S., Teunissen P.J.G. (2013). The ratio test for future GNSS ambiguity resolution. GPS Solutions, doi:10.1007/s10291-012-0299-z · Takasu T. (2013). RTKLIB Manual v2.4.2. · Liu et al. (2020). Multi-GNSS PPP-AR convergence analysis. Remote Sensing 12(14), doi:10.3390/rs12142310 · Sat.Nav. (2025) Multi-GNSS triple-frequency TTFA analysis. doi:10.1186/s43020-025-00169-6 · DJI Enterprise Insights — PPK Workflow · Wingtra Knowledge Base — PPK Base Station · RTKLIB Explorer (Takasu T., Everett T.) — PPK vs RTK, combined forward/backward processing.
