"Llevaste tu equipo al campo, ocupaste el punto durante cuatro horas, descargaste los datos limpios. Descargas el RINEX de la estación IGN más cercana y ves que viene en 2.0x. Procesas la sesión y el reporte termina en FLOAT. Antes de volver a campo con el equipo a repetir la medición, hay un paso intermedio que cambia el resultado."
El Instituto Geográfico Nacional del Perú (IGN) es la autoridad oficial encargada de mantener la red geodésica nacional —la red REGGEN— y el marco de referencia SIRGAS-Perú enlazado al sistema continental SIRGAS. Cualquier proyecto topográfico, catastral, minero o de infraestructura que requiera coordenadas oficiales debe amarrar sus mediciones a esta red. Esa vinculación se hace mediante observaciones GNSS estáticas prolongadas (típicamente entre 30 minutos y 4 horas por punto, según el orden geodésico que se certifique) procesadas contra una o más estaciones permanentes de la red.
El procedimiento es conceptualmente simple: el ingeniero ocupa el punto con un receptor geodésico de doble o triple frecuencia, descarga la sesión, obtiene los datos RINEX de las estaciones IGN cercanas desde el portal oficial, y corre un procesamiento diferencial (baselines) o una red ajustada por mínimos cuadrados. El producto final es un certificado con coordenadas en el marco oficial, desviaciones estándar acotadas, y un reporte de procesamiento reproducible. Ese certificado es el que acepta el IGN, las municipalidades, SUNARP, los gobiernos regionales y la mayoría de entidades que exigen datos geodésicos con trazabilidad.
Varias estaciones de la red REGGEN distribuyen sus datos en RINEX 2.10 o 2.11 por el portal público. Esto es comprensible desde una perspectiva de compatibilidad —todo software geodésico del planeta lee RINEX 2.x— pero es técnicamente limitante en 2025. RINEX 2.x fue estandarizado cuando GPS era la única constelación operativa en cobertura global. Su gramática de tipos de observación usa códigos de dos caracteres, concebidos para GPS L1/L2 y —con extensiones parciales— GLONASS L1/L2.
En sesiones estáticas donde el ingeniero llega con un receptor multi-constelación moderno (Trimble R10, R12i, Leica GS18, Topcon HiPer VR, Emlid Reach RS3), la asimetría se vuelve problemática: el rover observa GPS + Galileo + BeiDou + GLONASS + QZSS, pero la base oficial IGN le entrega solo GPS. Cuando el software de procesamiento forma las dobles diferencias, solo los satélites comunes entre base y rover entran en la solución. El resto de observaciones del rover aporta a la solución float, pero no al proceso central de resolución de ambigüedades enteras sobre baselines. En sesiones de geometría marginal —punto cerca de taludes, canyon urbano, dosel vegetal— esa pérdida de constelaciones es exactamente la diferencia entre FIX y FLOAT.
RINEX 2.10/2.11 tiene tres limitaciones estructurales que impactan directamente en la resolución estática:
- Códigos de observación de 2 caracteres: no pueden distinguir entre L1C (civil), L1P (precise), L1W (Z-tracking), L1X (Galileo). El conversor es forzado a decidir o descartar. Señales de fabricantes distintos (Trimble P-code vs u-blox C/A) se agrupan en el mismo slot, rompiendo la consistencia.
- Sin soporte completo para Galileo, BeiDou, QZSS, IRNSS: RINEX 2.x se diseñó antes de estas constelaciones. Las extensiones posteriores (2.12) son parciales y no todos los fabricantes las implementan igual. En la práctica, el archivo 2.11 distribuido por IGN típicamente contiene solo GPS y parcialmente GLONASS.
- Sin L5, sin E5a/E5b, sin B2: las frecuencias modernas que habilitan combinaciones libres de ionosfera de segunda generación (Melbourne-Wübbena avanzada, triple-frequency ambiguity fixing) simplemente no se transportan. Para sesiones largas donde el error ionosférico residual pesa, esto reduce la precisión del float y retarda la convergencia del FIX.
Hay una distinción fundamental en el significado de "FIX" entre ambos modos de procesamiento, y conviene fijarla antes de seguir. En PPK dinámico (drones, vehículos, embarcaciones) la solución se recalcula para cada época —típicamente cada 0.1 s a 1 s— y el resultado es una trayectoria compuesta por miles o decenas de miles de posiciones. El FIX se evalúa por época: puedes tener 94% de épocas FIX y 6% FLOAT, y el entregable convive con esa métrica estadística. En procesamiento estático geodésico el resultado no es una trayectoria: es una sola coordenada para el punto ocupado. La ambigüedad entera o se resuelve para esa sesión o no se resuelve. El FIX es binario y aplica a un único punto certificable; no hay "porcentaje de FIX" que negociar.
FIX estático ≠ FIX PPK. En certificación geodésica procesas una ocupación de 30 min – 4 h sobre un solo punto, y el producto es una coordenada única con su elipse de error. El motor resuelve las ambigüedades enteras GPS una sola vez para toda la sesión, valida con el ratio LAMBDA, y entrega FIX o FLOAT para ese punto. Si falla, no hay redundancia temporal que compense — toca volver al campo o intervenir los insumos. Por eso un cambio marginal en el modelo (agregar Galileo/BeiDou al rover vía RINEX 3.04) puede ser la diferencia entre certificar y repetir la visita.
Esa asimetría entre modos es lo que amplifica el impacto del formato RINEX. En PPK, un modelo ligeramente subóptimo se diluye sobre la trayectoria — pierdes algunas épocas pero el vuelo se rescata. En estático, ese mismo modelo subóptimo puede condenar toda la sesión a FLOAT: cuatro horas de espera en campo producen un reporte inutilizable para amarre oficial. La resolución de ambigüedades enteras descansa sobre la calidad del modelo en su conjunto; un modelo limitado a GPS single-frequency o dual-GPS sin Galileo/BDS converge más lento, requiere sesiones más largas y, en condiciones marginales, simplemente no fija.
El software estático —Trimble Business Center, Leica Infinity, Topcon MAGNET, GNSS Solutions, Gamit/Globk, Bernese, RTKLIB en modo estático— alimenta las observaciones a modelos que típicamente usan ionosphere-free combinations entre frecuencias, Melbourne-Wübbena para wide-lane, y triple-frequency ambiguity resolution cuando las tres frecuencias están disponibles. Sin L5/E5a/B2a en el archivo de entrada, esos procedimientos degradan a su versión dual-frequency o monofrecuencia, con un espacio de búsqueda de ambigüedad más grande y un ratio LAMBDA más bajo. Es la misma física que aplica a PPK — amplificada por la expectativa estática de entregar una única coordenada con centímetros absolutos sobre el marco oficial.
La mayoría de receptores Trimble geodésicos (NetR9, R10, R12, R12i) almacenan los datos en formato nativo .T02 (también .T01/.T00/.DAT en equipos más antiguos). Ese archivo binario contiene la totalidad de las señales que el receptor rastreó — GPS L1/L2/L5, Galileo E1/E5a/E5b/E6, BeiDou B1I/B2I/B2a, GLONASS L1/L2, QZSS completo. Es la fuente de verdad de lo que observó el equipo en campo.
El flujo de trabajo habitual de muchos topógrafos peruanos consiste en exportar ese .T02 a RINEX usando la herramienta del fabricante, que por defecto produce RINEX 2.11 —heredado de la época en que era el formato estándar— perdiendo en el proceso las constelaciones modernas que sí estaban en el binario original. Cuando esa pérdida se combina con un archivo base (IGN) que también es 2.11, el procesamiento queda doblemente limitado.
La intervención es exportar el mismo .T02 a RINEX 3.04 (o 3.05). El archivo de rover ahora contiene todas las observaciones del chip. Aunque la base IGN siga en 2.0x, el procesador cambia su comportamiento de tres formas medibles:
- Solución float más ajustada: las constelaciones adicionales del rover entran en la estimación de estado, reducen la varianza del float y mejoran la estimación de retardos troposféricos residuales — incluso sin parejas de doble diferencia en esas constelaciones.
- Detección de cycle slips más robusta: con fase en múltiples frecuencias y Doppler preservado, el detector de slips por épocas consecutivas opera con mucha más redundancia interna. Los arcos de fase GPS usados en la AR entran al proceso con menos interrupciones artificiales.
- Modelado ionosférico mejorado: el rover puede estimar residuos ionosféricos con más señales, lo que tensa el modelo y libera al float de absorber esa componente. El espacio de búsqueda LAMBDA se estrecha y el ratio sube.
En la práctica hemos visto sesiones estáticas de 1-2 horas —condenadas a FLOAT con el flujo tradicional Trimble .T02 → RINEX 2.11— que pasan a FIX estable para ese punto con solo repetir la exportación en 3.04. Una sola coordenada certificable por ocupación, resuelta con ratio LAMBDA por encima del umbral. Sin volver al campo. Sin cambiar el equipo.
Hay una objeción legítima ante este hallazgo: si la base IGN sigue en RINEX 2.0x con solo GPS, ¿cómo puede el mero hecho de mejorar el rover cambiar el resultado? La doble diferencia requiere satélites comunes base-rover, y esos siguen siendo solo GPS. La explicación está en que el FIX no depende únicamente de la doble diferencia: depende del modelo completo que el procesador usa para estimar el estado.
Un filtro de Kalman estático (o un ajuste por mínimos cuadrados iterativo) tiene como estado las coordenadas del punto, las ambigüedades enteras GPS, los retardos troposféricos residuales, y —en configuraciones avanzadas— los sesgos de reloj de receptor y satélite. Las observaciones multi-constelación del rover no producen dobles diferencias con la base, pero sí producen ecuaciones de pseudodistancia y fase absolutas que restringen el estado: fijan mejor la troposfera, estiman mejor los sesgos, pulen la convergencia del float. El resultado es que cuando LAMBDA busca las ambigüedades enteras GPS sobre las pocas dobles diferencias que sí existen, el punto flotante sobre el que busca está mucho mejor caracterizado — y el ratio de validación supera el umbral.
Adicionalmente, si tu software admite procesamiento PPP (Precise Point Positioning) combinado con el amarre a la base IGN, las observaciones multi-constelación del rover son usadas directamente por el motor PPP para estimar coordenadas absolutas de alta precisión, que luego se amarran a la red oficial por desplazamiento residual. En ese flujo, la calidad del archivo del rover domina el resultado.
Lectura clave: en procesamiento estático geodésico no basta con "tener los mismos datos que la base". Cualquier observación adicional del rover mejora la calidad del estado estimado para ese punto, y eso se traduce en FIX —entendido como una resolución binaria única para la sesión ocupada— cuando la configuración marginal que tenías antes no lo alcanzaba. La mejora es real incluso con base asimétrica, y el entregable sigue siendo una coordenada certificable por punto, no una trayectoria.
La herramienta oficial de Trimble para convertir .T02 a RINEX es convertToRINEX (disponible gratuitamente desde el portal Trimble). Desde sus versiones recientes (3.10+) soporta la generación de RINEX 3.04. Ejemplo por línea de comandos:
La regla práctica: nunca exportes a RINEX 2.x por defecto desde tu Trimble. Cuando abras convertToRINEX o el asistente del receptor, verifica manualmente que la versión seleccionada sea 3.04 o superior, y que las constelaciones Galileo/BeiDou/QZSS estén marcadas. Es un clic, pero ese clic es la diferencia entre un RINEX que pierde la mitad de tus observaciones y uno que las conserva.
| Sesión | Duración | Rover 2.11 | Rover 3.04 | σ horiz. (mm) |
|---|---|---|---|---|
| Costa (terreno despejado) | 2 h 15 min | FIX | FIX | 4 → 3 |
| Sierra (taludes) | 1 h 45 min | FLOAT | FIX | — → 7 |
| Selva (dosel parcial) | 3 h 30 min | FLOAT | FIX | — → 9 |
| Urbano (canyon parcial) | 1 h 20 min | Parcial | FIX | — → 11 |
| Minero (abierto) | 4 h 00 min | FIX | FIX | 3 → 2 |
Base: estaciones IGN AREV/PIUR/IQUI en RINEX 2.11 (sin cambio). Rover: Trimble R10 y R12i, mismo equipo en ambos escenarios. Procesador: RTKLIB estático con mismos parámetros. En los escenarios marginales (sierra, selva, urbano), la reconversión a 3.04 convirtió sesiones inutilizables en certificaciones válidas — evitando una segunda vuelta a campo de dos días y ~US$ 1,200 en costo logístico.
Este artículo contiene una conclusión técnica con implicación institucional. Las estaciones permanentes de la red REGGEN —operadas con receptores Trimble NetR9 o similares— rastrean señales multi-constelación en su hardware, pero el portal público recorta esa información al distribuir los datos en RINEX 2.11. La pérdida de datos ocurre en la etapa de publicación, no en la observación.
La recomendación técnica concreta al IGN es migrar progresivamente el portal de descarga a RINEX 3.04 o 3.05 como formato primario, manteniendo 2.11 disponible como opción de compatibilidad. Esto implica:
- Actualizar la cadena de conversión .T02 → RINEX en los servidores del portal a convertToRINEX ≥ 3.10 (o equivalente), con output por defecto en 3.04.
- Publicar junto al archivo RINEX los parámetros completos de antena (ARP, PCV) en formato ANTEX IGS vigente — no los genéricos. Esto cierra el ciclo para que el software del usuario aplique correcciones de fase absolutas.
- Documentar el modelo de receptor y firmware activo en cada estación, con historial de cambios. Un firmware mal documentado oculta IFBs de GLONASS que el usuario no puede calibrar.
- Distribuir archivos de navegación mixtos (.NAV) con efemérides de todas las constelaciones disponibles, no solo GPS — esencial para que el software estático pueda utilizar Galileo/BeiDou del rover aunque la base sea GPS-only.
Este cambio no requiere inversión en hardware. Los receptores ya observan los datos. Solo requiere actualizar la etapa de publicación. El impacto para los profesionales que certifican geodésicamente es significativo: menos sesiones fallidas, menos repeticiones de campo, más confianza en los resultados.
Para el profesional que certifica puntos ante el IGN, una sesión FLOAT no es solo un archivo fallido — es un costo operativo y de oportunidad concreto. Una segunda vuelta a campo típicamente implica: movilización de equipo (camioneta, chofer, combustible), jornadas perdidas del topógrafo, estadía si el punto es remoto, y el retraso asociado al cronograma del cliente. En proyectos mineros, forestales o de infraestructura en zonas remotas del Perú, esa segunda vuelta puede costar entre US$ 800 y US$ 3,000 dependiendo de la ubicación.
Lo que este artículo describe es un proceso de escritorio que toma 15 minutos: localizar el archivo .T02 original, exportarlo de nuevo en RINEX 3.04 con las constelaciones completas, reprocesar la sesión. Cuando funciona, elimina por completo la necesidad de la segunda vuelta. Cuando no funciona, al menos eliminó el formato como variable y permite diagnosticar el problema real (base demasiado lejana, geometría insuficiente, obstrucciones físicas, etc.) — en lugar de desperdiciar recursos repitiendo una medición cuyo archivo estaba subdeclarado desde el inicio.
La mayoría de paquetes de topografía comerciales ligados a marca —los que acompañan al receptor— tienen la exportación a RINEX configurada con defaults que priorizan compatibilidad amplia sobre completitud técnica. RINEX 2.11 se mantiene como default en muchos asistentes exportadores, y la opción de 3.04 está oculta en submenús o requiere activar módulos adicionales. Los flujos guiados que acompañan al equipo rara vez mencionan la diferencia, porque desde la perspectiva del fabricante ambas versiones "funcionan" — solo que una descarta la mitad de los datos en silencio.
Algo similar ocurre con los motores de procesamiento estático integrados en paquetes comerciales cerrados: el modelo estocástico, las ponderaciones por constelación, las máscaras de elevación diferenciadas por sistema, el tratamiento de IFB GLONASS y otros detalles que determinan si una sesión marginal fija o no, suelen estar fijos en el binario del software. Cuando el procesamiento sale en FLOAT, el mensaje al usuario es genérico. No hay panel donde el ingeniero pueda explorar qué combinación habría llevado al FIX.
El flujo de reconversión del .T02 a 3.04 que describimos aquí, y el diagnóstico de por qué mejora el resultado, son el tipo de hallazgo que aparece cuando se trabaja con un conjunto amplio de clientes y escenarios heterogéneos. A Terraplaniq llegan recurrentemente topógrafos peruanos que han agotado el flujo estándar de su paquete comercial y necesitan certificar un punto sin volver a campo — con bases IGN asimétricas, condiciones de selva o sierra, o sesiones cortas que no pueden repetirse por restricciones logísticas. Cada uno de esos casos deja una decisión afinada en el motor de TerraPPK: un preset de conversión, una regla de constelaciones recomendadas por geometría, una alerta automática cuando detecta un .T02 que va a exportarse en 2.11. No son features anticipadas en un roadmap — son consecuencia de exponer el software a condiciones de campo reales, iterando con cada caso que las herramientas rígidas no resolvieron.
Si trabajas certificando puntos geodésicos ante el IGN Perú y te has encontrado con sesiones estáticas que terminan en FLOAT cuando la base oficial te llegó en RINEX 2.11, antes de volver al campo a repetir la medición: verifica el formato en que exportaste tu archivo .T02. Si está en RINEX 2.11, reexpórtalo en 3.04 con todas las constelaciones activas, y reprocesa. En una fracción significativa de los casos, el FIX aparece — y la certificación se completa sin una segunda vuelta.
En paralelo, vale la pena que la comunidad geodésica peruana plantee formalmente al IGN la migración del portal de descargas a RINEX 3.04+. La red REGGEN observa los datos — solo falta que los publique completos. Es un cambio de backend con alto impacto para quienes trabajamos en precisión geodésica profesional.
Si tienes un caso específico —una sesión FLOAT que no pudiste resolver, una certificación bloqueada por formato— escríbenos. El Laboratorio TerraPPK crece con casos reales.
