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 (como se ha dicho se encuentra en la parte inferior de la entrada) 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.
Documentos compartidos:
Documentos compartidos: