¿Cómo extraer la identificación del interrogador de un mensaje DF11?

He escrito una clase que decodifica mensajes en Modo S sin formato. Mientras examinaba las especificaciones de la OACI el otro día, noté que la identificación del interrogador se devolvía en el mensaje DF11.

Pensé que sería un ejercicio divertido determinar en qué parte de mi área de cobertura se pueden ver interrogatorios de instalaciones de radar particulares.

Pero me está costando mucho averiguar cómo extraer la identificación del interrogador.

Para este mensaje DF11:

5D406FDB0D62DD

Tengo lo siguiente:

Binary: 01011101010000000110111111011011000011010110001011011101
Integer Words:
    [0] => 93
    [1] => 64
    [2] => 111
    [3] => 219
    [4] => 13
    [5] => 98
    [6] => 221

 CA: 5
 AA: 4222939
 Address: 406FDB
 Parity: 255
 Residual: 0

Como el valor Residual es 0, sé que este es un mensaje DF11 válido y la dirección también se verifica.

De la especificación de la OACI:

"El código utilizado en la generación del campo PI de enlace descendente estará formado por una secuencia de 24 bits (a1, a2,..., a24), donde los primeros 17 bits son CEROS, los siguientes tres bits son una réplica de la etiqueta del código ( CL) (3.1.2.5.2.1.3) y los últimos cuatro bits son una réplica del campo del código de interrogador (IC) (3.1.2.5.2.1.2)".

En ese caso, esperaría que el final de las últimas tres palabras enteras (4,5 y 6) fueran en su mayoría 0, pero no lo son.

Revisé la documentación varias veces, pero no puedo ver cómo sacar los códigos II y SL del valor de paridad.

Estoy calculando el valor de paridad haciendo lo siguiente:

$this->_pi = $this->_int[4] | $this->_int[5] | $this->_int[6];

donde | en PHP es el operador OR. ¿Es este mi error?

Respuestas (1)

Su cálculo de $this->_pisolo OR combina los tres bytes de paridad, lo que ciertamente no tiene ningún sentido. No estoy seguro de lo que esperas obtener de eso. Incluso XORing ellos juntos no parece tener ningún propósito.


El direccionamiento y la suma de verificación en el protocolo Modo S funcionan de manera original, para ahorrar bits. Los últimos 3 bytes de un mensaje se construyen como una suma de verificación CRC (que el Anexo 10 llama "paridad") de los primeros 4/11 bytes, XOR con una dirección para la "conversación" de la que forma parte el mensaje. Cuando recibe un mensaje, se supone que debe calcular el CRC sin procesar por su cuenta y luego XOR de los bytes. Lo que queda es la dirección y, al compararla con las direcciones que le interesan, puede ver si el mensaje era para usted o, alternativamente, confuso o para otra persona.

En el protocolo de interrogación básico del Modo S, esta "dirección" es solo la dirección del fuselaje, y el campo de dirección de suma de verificación xor se denomina AP. Para los mensajes de enlace ascendente, los transpondedores saben cuál es su propia dirección, por supuesto, y para el enlace descendente, los radares saben qué direcciones han interrogado recientemente.

En algunos otros casos, la "dirección" es el "identificador del interrogador" y el campo checksum-xor-address se denomina PI.

Para DF11, el transpondedor sabe qué II poner en sus respuestas porque los saca del mensaje de llamada general, y el radar sabe qué II corresponde a sus propias llamadas generales, por lo que puede reconocer esas respuestas.

Finalmente, en señales espontáneas donde el transpondedor envía un mensaje de enlace descendente sin que lo solicite un mensaje de enlace ascendente, establece la "dirección" en 0.


Si ha estado decodificando transmisiones ADS-B, está escuchando señales espontáneas, por lo que puede identificarlas como aquellas en las que el CRC que calcula es igual al campo PI en el mensaje (porque XORing 0 en el CRC no lo cambia ). Todo lo que tenga una dirección diferente se verá como fallas en la suma de verificación de su código.

Dado que el mensaje DF11 que está mostrando coincide con el cheksum, debe ser un squitter DF11. Hay muchos de esos para escuchar; TCAS depende de que todos los envíen continuamente.

Para encontrar mensajes DF11 con un identificador de interrogador distinto de cero, debe buscar mensajes en los que los últimos tres bytes después de haber extraído el CRC con XOR comiencen con 17 ceros pero luego tengan al menos algunos de los 7 bits restantes distintos de cero.

Gracias por la explicación tan clara :-) Revisaré mi código mañana y lo publicaré de nuevo, pero puedo ver exactamente cómo debería funcionar ahora.