¿Qué datos encontramos?
Cuando realizamos una grabación de DMR con la herramienta DSD+ nos reporta una serie de log dependiendo de cómo hayamos programado nuestra herramienta, en esta entrada lo que pretendo es explicar lo que se observa en él.
Comencemos con una grabación realizada en mi casa, vamos a observar uno de los log que me ha reportado esta grabación.
Antes de comenzar mostrando esta imagen quiero explicar que se trata de una transmisión de datos donde no hay voz, como es lógico el log cambia drásticamente a cómo nos representaría estos datos si fuera una conversación de voz.
Esta primera secuencia de datos que se muestran en la imagen corresponde a como tenemos programado el DSD, lógico cada persona lo configura a su gusto, en la imagen se ve que he realizado una programación básica y no le vamos a prestar demasiada atención, como decía en las líneas explica cómo está programado en relación al cable virtual, qué comandos se han programado en la línea de comandos para ver que grabamos, etc.
Veamos la siguiente imagen:
Esta imagen ya empieza a reportarnos más datos, si comenzamos en la primera línea vemos que da un grupo de fecha hora que es coincidente con la hora de cuando se está grabando esta señal, con esto hay que gastar cuidado, si nosotros realizamos una grabación en FI de esta señal y se la pasamos al DSD 10 minutos más tarde nos dará esta segunda hora, no de cuando se grabó, con lo que es la hora en que el DSD está escuchando la señal.
Después indica que se ha sincronizado con una transmisión de DMR, vamos a observar ese signo menos (-) que hay delante del DMR, según he podido leer en el foro RadioReference cuando pone el signo negativo (-) corresponde a una transmisión europea, por contra si pusiera positivo (+) sería un equipo americano, este hecho no lo he podido confrontar, sé que efectivamente sale un menos (-) o un más (+) delante de la palabra DMR, pero no puedo asegurar que sea por este motivo.
En la segunda línea observamos que existe un error en el Cach, recordar de entradas anteriores que expliqué que era el Cach, al final de la línea indica que el error es el 19.
El resto de líneas a excepción de la última nos indica por qué slot está transmitiendo (slot1 o slot2), que se trata de una estación base (BS), que está en transmisión de datos (DATA), que usa el código color 3 (DCC=3) y que está en trama idle o en espera (Idle), aunque la traducción correcta sería ocioso.
En la última línea nos indica que el control de enlace corto opcode es un nulo (SLCO - Short Link Control Opcode).
Vamos a ver por partes esta imagen.
En ella no voy a repetir los datos ya conocidos, partiendo desde CSBK o Bloque de señalización de control (Control Signalling Block), indica que tiene un preámbulo que correspondiente al 8001 y que tiene un Tgt o Target número 71 y un Src o Source número 2.
Aquí quiero hacer una pequeña explicación sabemos que el TG o Talk Group es el grupo de conversación y que el RID o radio ID es el identificador de la radio. En la línea que estábamos viendo el Tgt es el destino con lo que dependiendo de a quién se le envié la información puede ser un TG cuándo es a todo el grupo de conversación o un RID cuando es a una sola radio. De la misma forma el Src es el origen con lo que siempre será lo equivalente a un RID.
En la segunda línea se observa la siguiente información:
- El último bloque es el 1 (Last Block - LB=1).
- El control de señalización del bloque opcode es el 61 (Control Signalling BlocK Opcode - CSBKO=61).
- El indicador de función es el 0 (Feature ID - FID=0). En el ETSI TS 102 361-1 V1.4.5 (2007-12) existe una tabla (Tabla MFID) donde se le asigna a cada fabricante uno o varios números, con lo que con este número podremos saber quién es el fabricante del equipo que transmite, por ejemplo, Motorola es el 16, mientras que Hytera es el 8 y el 104, en este caso el 0 es reservado (estos dos documentos se comparten en la parte inferior de la entrada).
- El v16 nos indica que es un Tier III con el preámbulo 8001 (v16=8001).
- El destino (id1=71), es similar en cuanto a explicación al Tgt.
- El origen (id2=2), es similar en cuanto a explicación al Src.
La tercera línea nos ofrece la información de CSBKO, FID, id1 e id2 en hexadecimal y el preámbulo en decimal.
Por último, la última línea nos ofrece lo mismo, pero en binario.
Vamos a continuar con el estudio de la primera secuencia.
En esta imagen lo que se puede observar es que sólo está enviando información por el slot 1, estando el 2 sin actividad, aunque no es cierto del todo ya que se está enviando por él una trama idle, no está apagado.
Vamos ahora a la primera línea de datos:
- Data Header indica que comienza el encabezado de datos.
- El formato de paquetes de datos es 2:UcData (Data Packet Format - DPF=[2:UcData]).
- El destino es el 71 (Tgt=71).
- El origen es el 2 (Src=2).
- La configuración es la 0 (Conf=0).
- El punto de acceso al servicio es 4:IP Data (Service Access Point - SAP=[4:IP Data]).
- Que posee 4 bloques (Blocks=4), el número de bloques es equivalente al número de líneas que nos va a presentar con datos.
- Que el Pad o almohadilla es igual a 2.
- Que la última es la 0.
- Y que la secuencia es 0.
En cuanto al resto de líneas con información indicar primero que la secuencia “Rate ½ Data” es la forma de presentarnos los datos, éstos son los números hexadecimales que observamos a continuación.
En la tabla 8.1 del ETSI TS 102 361-1 V2.4.1 nos presenta como se muestran estos datos.
En nuestro caso se observa que corresponde al modo no confirmado de 12 octetos.
En cuanto a qué información está transmitiendo será objeto de otra entrada que haré más adelante.
Sí indicar que en la última línea nos indica que usa el protocolo LRRP (Location Request/Response Protocol), aunque en realidad no está dando su posición GPS, también nos vuelve a dar el Tgt y el Src.