Modo 2

DPF=[15:Prop] y SAP=1

0D 21 23

Como continuación a los tipos de protocolos que nos aportan datos GPS encontramos éste que, aun teniendo los mismos DPF y SAP que el modo anterior, se observa que los 3 últimos octetos de la primera línea son diferentes.

Para poder explicarlo con más claridad vamos a mostrar primero un paquete de datos con la combinación de hexadecimales (0D 21 23) que queremos tratar en este tema.

Data Header DPF=[15:Prop] SAP=1 MFID=16  02 01 11 01 22 0D 21 23
Rate 1/2 Data 38 34 1F 89 48 04 4A 55 33 77 24 C6
Rate 1/2 Data FC 32 19 78 01 47 3A 02 03 31 6C 00 
Rate 1/2 Data 0F 56 88 70 00 27 65 4C 97 9F EC C0  

En el paquete de datos anterior se muestran los datos de diferenciación con respecto al Modo 1, hay que recordar que se trata de la misma combinación de protocolos y que la diferencia la encontrábamos en los 3 últimos octetos de la primera línea.

A las líneas de código se le ha quitado aquellas partes que no van a ser estudiadas en este capítulo.

Al fijarse en esos 3 octetos (0D 21 23) se puede ver que el octeto 0D coincide en la misma posición que en el Modo 1, éste indicaba que existían datos GPS, por contra los otros 2 (21 23) son diferentes, en esta ocasión no se puede hacer la conversión a decimal y dividir por 2 ya que salvo errores de bits no son coincidentes con la posición de los datos GPS.

Como ocurre en la mayoría de los casos lo primero que encontramos es el token del tiempo, ya veremos que hay ocasiones en las que no nos aparece este dato ni el propio grupo fecha/hora.

 Token del tiempo: se observa en el siguiente paquete de datos que el octeto número 10 corresponde al número hexadecimal 34, correspondiendo al token del tiempo.

Data Header DPF=[15:Prop] SAP=1 MFID=16  02 01 11 01 22 0D 21 23
Rate 1/2 Data 38 34 1F 89 48 04 4A 55 33 77 24 C6
Rate 1/2 Data FC 32 19 78 01 47 3A 02 03 31 6C 00 
Rate 1/2 Data 0F 56 88 70 00 27 65 4C 97 9F EC C0 

Grupo fecha/hora o tiempo: los siguientes 5 octetos del patrón de tiempo (1F 89 48 04 23), se encuentran entre los octetos 11 al 15 y su conversión corresponde al grupo fecha/hora 2018/05/04 00:16:35, no se van a mostrar las fórmulas por motivos obvios ya que representan un tema sensible.

Ya se explicó en el Modo 1 que existe un desfase de tiempo con respecto al grupo fecha/hora de la parte izquierda, si estuviera el paquete de datos completo y no recortado como lo presentamos en el siguiente paquete de datos, no existe ningún error, esto es debido como ya se explicó a lo siguiente:

• El grupo fecha/hora fruto de los hexadecimales corresponde a cuando el equipo envía su posición GPS.

• El grupo fecha/hora de la parte izquierda de cada una de las líneas de datos corresponde a cuando se ha captado la señal en el aire o si se hiciera una grabación en IF a cuando se realice la demodulación de la señal.

Data Header DPF=[15:Prop] SAP=1 MFID=16  02 01 11 01 22 0D 21 23
Rate 1/2 Data 38 34 1F 89 48 04 4A 55 33 77 24 C6
Rate 1/2 Data FC 32 19 78 01 47 3A 02 03 31 6C 00 
Rate 1/2 Data 0F 56 88 70 00 27 65 4C 97 9F EC C0

Token del GPS: En este caso se encuentra alojado en el octeto número 16 y corresponde  al número hexadecimal 55.

Data Header DPF=[15:Prop] SAP=1 MFID=16  02 01 11 01 22 0D 21 23
Rate 1/2 Data 38 34 1F 89 48 04 4A 55 33 77 24 C6
Rate 1/2 Data FC 32 19 78 01 47 3A 02 03 31 6C 00 
Rate 1/2 Data 0F 56 88 70 00 27 65 4C 97 9F EC C0

Latitud: Como sabemos, los octetos correspondientes a la latitud son los 4 siguientes al token del GPS, por tanto, son los octetos 33 77 24 C6 y ocupan los octetos 17 al 20. Su conversión corresponde a 36,18661280632639 de latitud norte.

Data Header DPF=[15:Prop] SAP=1 MFID=16  02 01 11 01 22 0D 21 23
Rate 1/2 Data 38 34 1F 89 48 04 4A 55 33 77 24 C6
Rate 1/2 Data FC 32 19 78 01 47 3A 02 03 31 6C 00 
Rate 1/2 Data 0F 56 88 70 00 27 65 4C 97 9F EC C0

Longitud: Según se puede observar en la siguiente imagen del paquete de datos, los octetos 21 al 24 son los correspondientes a la longitud (FC 32 19 78), su conversión equivale a  -5,34979521421478 de longitud oeste. 

Hay un concepto sobre la longitud y sobre el resto de datos que se aportan en el paquete de datos que no se ha mencionado hasta ahora, hay que imaginar que los distintos octetos de las cuatro líneas de código de este ejemplo, pero también las que haya de cualquier muestra que se estudie, como mencionábamos, hay que imaginar que los octetos forman una sola línea y no 4, cinco o seis líneas, en este caso se presentan 12 octetos por línea, pero imaginemos que el paquete de datos fuera un paquete de datos no confirmado con un Data Rate de 1, tendríamos 24 octetos por línea, esto sólo representa que cada línea tendría esos 10, 12 16, 18, 22 o 24 octetos por línea, pero la información que porta puede ser la misma en cada uno de ellos, con lo que conviene imaginar que es una sola línea como ocurre en el caso del "Raw Data" que se estudiará más adelante.

Data Header DPF=[15:Prop] SAP=1 MFID=16  02 01 11 01 22 0D 21 23
Rate 1/2 Data 38 34 1F 89 48 04 4A 55 33 77 24 C6
Rate 1/2 Data FC 32 19 78 01 47 3A 02 03 31 6C 00 
Rate 1/2 Data 0F 56 88 70 00 27 65 4C 97 9F EC C0

Token de la velocidad: El siguiente dato conocido a mostrar es el token de la velocidad (6C) que, como ya sabemos es el número hexadecimal 6C y se encuentra en el octeto 31.

Data Header DPF=[15:Prop] SAP=1 MFID=16  02 01 11 01 22 0D 21 23
Rate 1/2 Data 38 34 1F 89 48 04 4A 55 33 77 24 C6
Rate 1/2 Data FC 32 19 78 01 47 3A 02 03 31 6C 00 
Rate 1/2 Data 0F 56 88 70 00 27 65 4C 97 9F EC C0

Velocidad: Según se puede observar en la imagen siguiente, la velocidad se encuentra en los octetos 32 y 33 (00 0F), en este caso su conversión corresponde a 0,1171875 m/s.

Data Header DPF=[15:Prop] SAP=1 MFID=16  02 01 11 01 22 0D 21 23
Rate 1/2 Data 38 34 1F 89 48 04 4A 55 33 77 24 C6
Rate 1/2 Data FC 32 19 78 01 47 3A 02 03 31 6C 00 
Rate 1/2 Data 0F 56 88 70 00 27 65 4C 97 9F EC C0

Si recordamos el "Modo 1", la velocidad era el último dato conocido que se proporcionaba, en este modo y a continuación de la velocidad, se muestra en el siguiente octeto, número hexadecimal 56, el token del azimut o dirección en la que se mueve el emisor.

Token del azimut: Tal y como se ha expresado en el párrafo anterior, el octeto 34 corresponde al token del azimut, siendo siempre el número hexadecimal 56.

Data Header DPF=[15:Prop] SAP=1 MFID=16  02 01 11 01 22 0D 21 23
Rate 1/2 Data 38 34 1F 89 48 04 4A 55 33 77 24 C6
Rate 1/2 Data FC 32 19 78 01 47 3A 02 03 31 6C 00 
Rate 1/2 Data 0F 56 88 70 00 27 65 4C 97 9F EC C0

Azimut: Por último, encontramos en el siguiente octeto, octeto número 35, al número hexadecimal 88 que corresponde a 272 grados de azimut. Con este dato hay que gastar cuidado ya que nos podría llevar a error, me explico, aunque nos de esta referencia o dato no significa que el emisor se esté moviendo, un ejemplo de ello lo podemos ver en nuestro coche, si tenemos navegador, o nuestro smartphone, si activamos el navegador y paramos en un semáforo, al observarlo, podemos ver como comienza a girar en la mayoría de las ocasiones, esto es debido a la pequeña oscilación que ejecuta el GPS con respecto al satélite, con el DMR ocurre igual, cuanto más rápido se mueve el transmisor, más estable es la señal en lo referente a su dirección, por lo cual tendremos que prestar más atención a la velocidad para saber si este emisor se está moviendo, en el caso de que así fuera si haríamos caso a este dato (azimut).

Data Header DPF=[15:Prop] SAP=1 MFID=16  02 01 11 01 22 0D 21 23
Rate 1/2 Data 38 34 1F 89 48 04 4A 55 33 77 24 C6
Rate 1/2 Data FC 32 19 78 01 47 3A 02 03 31 6C 00 
Rate 1/2 Data 0F 56 88 70 00 27 65 4C 97 9F EC C0