Formatos NTRIP Rev1 versus Rev2

La creación de NTRIP Rev2 fue motivada en gran medida por la necesidad de corregir algunos descuidos menores en el estándar Rev1 original. Esto incluyó corregir los detalles del protocolo para adherirse a los estándares HTTP emergentes y también agregar una mayor seguridad de inicio de sesión para las estaciones base. También se agregaron varias características nuevas, pero su adopción e implementación en este momento sigue siendo muy baja. De hecho, la versión inicial Rev1 sigue siendo tan popular hoy en día que entre los dispositivos NTRIP Client, los usuarios de Rev1 superan en número a los de Rev2 en aproximadamente 25: 1.

Para aquellos que buscan los detalles específicos de cualquiera de las versiones, ambos estándares están disponibles en RTCM ( aquí ). Los nombres formales de los dos documentos se dan a continuación. Es más rentable comprarlos en conjunto.

RTCM 10410.0 (RTCM Paper 200-2004 / SC104-STD, versión 1.0), con la enmienda 1,
estándar para el transporte en red de RTCM a través del protocolo de Internet (Ntrip)

RTCM 10410.1 Estándar para el transporte en red de RTCM a través del Protocolo de Internet (Ntrip)
Versión 2.0 con Enmienda 1, 28 de junio de 2011

En este artículo nos preocupamos de cómo el dispositivo móvil (el cliente NTRIP ) se conecta al dispositivo NTRIP Caster . Esta información es válida para cualquier lanzador, no solo para el lanzador SNIP NTRIP. Se realizaron algunos cambios similares para las conexiones de la estación base ( servidores NTRIP ), entre Rev1 y Rev2, pero no se tratan aquí.

En un contexto de capa OSI, el protocolo NTRIP vive sobre el protocolo HTTP, que a su vez vive sobre el protocolo TCP / IP. El propósito del protocolo es permitir que el dispositivo cliente que se conecta se autentique con el proveedor de datos (el Caster) y luego seleccione un flujo de datos. Una vez que se ha producido este proceso inicial, el flujo de datos seleccionado se envía de vuelta al dispositivo a través del socket abierto. Con la excepción de las sentencias NMEA-183 $ GGA periódicas adicionales (utilizadas por los flujos NEAR para seleccionar la estación base correcta para cada usuario), el dispositivo Cliente NTRIP no envía nada más. En este contexto, NTRIP es un mecanismo de publicación / suscripción simple y elegante.

Nota : En los ejemplos siguientes, mountPt es el nombre de la estación base o ‘flujo’ que se solicita. Y el usuario y la contraseña se utilizan para el par de contraseña de usuario, que a su vez se envía en un formato codificado en Base64 (es decir, usuario: contraseña se convierte en dXNlcjpwYXNzd29yZA ==). Todas estas cadenas distinguen entre mayúsculas y minúsculas y generalmente se limitan al contenido ASCII sin el uso de espacios en blanco. Consulte el estándar para obtener más detalles sobre cadenas válidas y caracteres permitidos. <cr> <lf> delimita el final de cada línea en el encabezado HTTP. Una línea final con solo <cr> <lf> sirve para delimitar el final del encabezado (no se muestra).

 

Conexiones NTRIP Client Rev1

Debido a que NTRIP se basó originalmente en HTTP y un protocolo llamado Shoutcast ( detalles históricos ), usa el verbo GET común para solicitar el mountPt deseado.

Un ejemplo mínimo de NTRIP Client Rev1 sin inicio de sesión de usuario es:

GET / mountPt HTTP / 1.0 <cr> <lf>
Usuario-Agente: NTRIP theSoftware / theRevision <cr> <lf>

Un ejemplo mínimo de NTRIP Client Rev1 con un inicio de sesión de usuario es:

GET / mountPt HTTP / 1.0 <cr> <lf>
Usuario-Agente: NTRIP theSoftware / theRevision <cr> <lf>
Autorización: dXNlcjpwYXNzd29yZA == <cr> <lf>

Cuando el lanzador NTRIP acepta una solicitud, el lanzador responde con:

ICY 200 OK <cr> <lf>

Y a partir de entonces sigue el contenido binario (típicamente mensajes RTCM 3.x ). En caso de cualquier tipo de error, se devuelve la tabla de ruedas y se interrumpe la conexión.

Detalles

Después de la palabra clave GET , se espera encontrar un solo espacio, seguido de “/”, luego el nombre del flujo de datos solicitado, otro espacio y luego la revisión HTTP. Como regla, HTTP espera un solo espacio (hexadecimal 0x20) como delimitador, cualquier espacio en blanco adicional puede causar problemas.

La palabra clave ” User-Agent: ” se utiliza para transmitir dos conceptos clave. Primero, que se trata de un NTRIP Caster (y no un navegador o algún otro agente) y, en segundo lugar, qué marca / modelo de software se está utilizando. [ Nota : El término “Agente de origen:” fue inventado por NTRIP para las estaciones base que envían datos y se usa en Rev1. Quedó en desuso en Rev2]

La palabra clave NTRIP se considera que no distingue entre mayúsculas y minúsculas por razones históricas, aunque las mayúsculas son las más comunes.

A esta palabra clave le sigue el modelo de software NTRIP Client que se está utilizando. Por lo general, en el formato de “Modelo de fabricante / Revisión” sin espacios en blanco. Aquí se puede encontrar una lista típica de cadenas de clientes recientes en un lanzador púbico popular   con cadenas de dispositivos NTRIP típicas.

La palabra clave ” Autorización: ” se utiliza para enviar el usuario y la contraseña codificados en un formato Base64 común, cuando está presente.

La solicitud más simple consta de solo dos o tres líneas en un formulario de encabezado HTTP común. Pero el encabezado HTTP a menudo puede contener metainformación adicional. Además, si se utiliza el formulario HTTP 1.1, se requiere información adicional. Consulte rfc2616 para obtener más detalles.

Aparte # 1 : La forma correcta de solicitar la tabla de caster es enviando “/” después del verbo GET. Y no enviando cadenas arbitrarias como “CasterTable”, que solo funciona porque el comportamiento predeterminado de NTRIP Caster cuando se detecta un error es devolver la tabla de caster y luego desconectarse.

Aparte # 2 : Cuando se envían datos al Caster desde una estación base usando Rev1, se usa la palabra clave “SOURCE”, en Rev2 esto se reemplaza con “POST” junto con otros cambios.

Aparte # 3 : Al enviar datos NMEA-183 $ GGA al Lanzador, el Cliente NTRIP debe esperar hasta que se reciba la respuesta “ICY” que indica que la conexión es aceptada.

Conexiones NTRIP Client Rev2

En Rev2 de NTRIP se limpiaron algunos detalles para seguir mejor HTTP. La mayoría de los cambios de Rev2 se encuentran en la forma en que un servidor NTRIP (la estación base) se conecta al Caster. En SNIP Caster, esto se denomina conexión PUSH-In .

Un ejemplo mínimo de NTRIP Client Rev2 sin inicio de sesión de usuario es:

GET / mountPt HTTP / 1.1 <cr> <lf>
Anfitrión: theCaster.com:2101 <cr> <lf>
Versión de Ntrip: Ntrip / 2.0 <cr> <lf>
Usuario-Agente: NTRIP theSoftware / theRevision <cr> <lf>

Un ejemplo mínimo de NTRIP Client Rev2 con un inicio de sesión de usuario es:

GET / mountPt HTTP / 1.1 <cr> <lf>
Anfitrión: theCaster.com:2101 <cr> <lf> 
Versión de Ntrip: Ntrip / 2.0 <cr> <lf>
Usuario-Agente: NTRIP theSoftware / theRevision <cr> <lf>
Autorización: dXNlcjpwYXNzd29yZA == <cr> <lf>

Cuando el lanzador NTRIP acepta una solicitud, el lanzador responde con al menos:

HTTP / 1.1 200 OK <cr> <lf>

Una respuesta más típica incluye algunos detalles adicionales del encabezado como:

HTTP / 1.1 200 OK <cr> <lf>
Fecha: miércoles, 11 de noviembre de 2020 20:29:36 UTC <cr> <lf>
Servidor: SubCarrier Systems Corp SNIP simpleNTRIP_Caster_ [2.13.00] RwPRO <cr> <lf>
Versión de Ntrip: Ntrip / 2.0 <cr> <lf>
Control de caché: sin almacenamiento, sin caché, edad máxima = 0 <cr> <lf>
Pragma: sin caché <cr> <lf>
Conexión: cerrar <cr> <lf>
Tipo de contenido: gnss / data <cr> <lf>

Y a partir de entonces sigue el contenido binario (típicamente mensajes RTCM 3.x ). En caso de cualquier tipo de error, se admiten una variedad de otras respuestas de error (también conocidas como mensajes HTTP 4xx), además de devolver la tabla de caster al solicitante.

Detalles

El formato Rev2 se basa en el formato Rev 1, así como en la nueva metainformación definida y encontrada en HTTP 1.1. Como antes, el encabezado HTTP a menudo puede contener metainformación adicional. Esto es cierto tanto para los encabezados de solicitud como de respuesta.

Las dos líneas de encabezado adicionales (y obligatorias) contienen la metainformación “ Host: ” y “ Ntrip-Version: ”.

La meta palabra clave ” Host: ” indica a qué servidor específico se refiere el host y el puerto al que se refiere la solicitud. En una máquina donde hay una dirección IP que está asociada con un (y solo uno) host NTRIP, esta información no es requerida, pero es obligatoria por HTTP. En un entorno de host compartido, o donde se utiliza un firewall o proxy, esta información es esencial para enrutar la solicitud al dispositivo host correcto.

La meta palabra clave ” Ntrip-Version: ” está inventada por la especificación NTRIP Rev2 y debe seguir el texto exacto anterior. No se definen otras variaciones del texto del valor en este momento. La presencia de esta línea indica el uso de NTRIP Rev2.

En la respuesta, tenga en cuenta que “ICY” (ICY = Puedo escucharlo) se reemplaza por una línea HTTP 200 OK, que también incluye la versión de HTTP utilizada.

Varias otras palabras clave meta pueden estar presentes opcionalmente en la respuesta, incluido un sello de fecha y detalles sobre el software NTRIP Caster. Aquí, ” Servidor: ” se usa en un sentido web tradicional para el lanzador, no el significado de NTRIP para un servidor NTRIP (una estación base). El ejemplo anterior usa la respuesta de un lanzador SNIP , otras marcas son similares.

Muchos dispositivos no admiten conexiones Rev2. Esto es especialmente cierto en dispositivos de bajo costo. La popular biblioteca de código abierto llamada RTKLIB (ver: aquí aquí o aquí ) solo puede conectarse con el estilo de conexión Rev1. Varias mejoras ramificadas y algún software comercial basado en él, incluido Emlid Reach , tampoco implementan conexiones Rev2. Los dispositivos de grado superior ( Trimble , Leica , Hemisphere , TopCon , etc.) admiten tanto Rev2 como Rev1 y, por lo general, estos dispositivos utilizan de forma predeterminada Rev2. Consulte el manual del propietario específico para obtener más detalles.

En Rev2, las conexiones NTRIP Client están diseñadas para permitir la compatibilidad “descendente” hacia atrás con las conexiones Rev1. Por lo tanto, cualquier Cliente NTRIP que envíe una solicitud Rev2 también debe estar diseñado para aceptar y hacer frente a una respuesta Rev1. Esto no es cierto para las conexiones del servidor NTRIP.

Rev2, el protocolo requiere el uso de HTTP 1.1 y, por lo tanto, requiere el uso de la línea meta del host (consulte rfc2616 para obtener más detalles). Aquí se puede usar un nombre de IP o URL, y también se debe usar el puerto (aunque el estándar RTCM actual es menos claro sobre este detalle, RFC2616 no lo es).

Observaciones finales

No utilice Live Casters para probar el nuevo software NTRIP Client. Es muy probable que el operador Caster bloquee su IP para dicho uso / abuso. El registro de la consola de SNIP Caster proporciona una gran cantidad de detalles sobre las diversas causas de las conexiones incorrectas del Cliente NTRIP. Algunos desarrolladores simplemente descargan una copia Lite (gratuita) de SNIP en su propia máquina local para realizar tales pruebas.

Se recomienda encarecidamente a los productos en desarrollo que busquen los detalles específicos de cualquiera de las versiones de RTCM.

SNIP es totalmente compatible con los estilos de conexión NTRIP Rev1 y Rev2 para Clientes , Casters y Servidores . Lacopia Lite (gratuita) de SNIP está limitada al formato Rev 1 solo para algunas conexiones. Puede examinar todos los detalles del intercambio de protocolos en la vista de la consola habilitando varias opciones de visualización para cada tipo de conexión.