Hunter GE Drive Test (Signal Level)

miércoles, 09 de junio de 2010 3:00:00 Categories: Access Drive Test Google Earth Hunter
Valorar Este Contenido 2 Votos.

Como se ha señalado, el Drive Test es importante para un análisis más completo de la red. Las diversas herramientas de pos procesamiento tienen un conjunto completo de este análisis, pero a veces nuestro trabajo se puede simplificar mucho, y por qué no, a veces conseguir un mejor resultado.

 

 

Este es particularmente el caso para el procesamiento personalizado de drive test - ni siquiera podemos tener el poder de los algoritmos y los detalles de algunos programas, pero tenemos resultados sorprendentemente sencilla y eficaz. Hoy vamos a aprender de una manera creativa para graficar el nivel de señal de datos de una red en Google Earth, no importa lo que ha sido el equipo/software que ha hecho la recopilación de el drive test.

Nota: Todas las telecomHall artículos están escritos originalmente en Portugués. A continuación se hacen traducciones en Inglés y Español. Como nuestro tiempo es escaso, sólo se producen varios errores de ortografía (que utilizar el traductor automático, y sólo entonces hacer una revisión final). Pedimos disculpas, y contamos con su comprensión de nuestro esfuerzo. Si usted quiere contribuir traduciendo / corregir una de estas lenguas, o incluso uno nuevo, por favor comuníquese con nosotros: contacto.

 

Objetivo

De los datos recogidos en un drive test, generar un archivo de salida en formato Google Earth KML con la información trazada de acuerdo a nuestras elecciones.

En otras palabras, determinar los datos de la prueba de conducción en Google Earth, tanto como lo hacemos con mapas temáticos en MapInfo.

 

Estructura de archivos

Otro módulo nuevo. Como siempre, vamos a aumentar nuestra estructura para adaptarse a las necesidades. Usted probablemente ha notado cómo la organización es importante. Cada vez que la herramienta Hunter crece, se hace más importante para mantener los módulos conectados entre sí.

Este es un módulo que también utiliza Google Earth - GE - así se crea la estructura dentro del directorio de GE. Cree el directorio DriveTest (1) como el directorio principal de este módulo. Los otros directorios Data (2), Output (3) y Scripts (4) son los módulos estándar de nuestra herramienta. Tan sólo recordar, son, respectivamente, los directorios donde están nuestros datos entrantes archivos recopilados en el drive test, los datos de salida, donde hoy un archivo. KML con los datos con formato y guiones del directorio, ahora con el archivo que realiza el procesamiento, y se creará a partir de ahora.

 

Tenga en cuenta que tenemos un directorio de asistencia - Help (5). En este almacén de directorio todos los archivos auxiliares para ese módulo en particular. También tenga en cuenta que este módulo utiliza el directorio icon (6), recordando que este directorio se ha creado anteriormente, ya que se comparte con varios módulos.

 

Los datos de entrada

Nuestro principal objetivo es la creación de una aplicación que es compatible con la salida de cualquier equipo o programa informático que se ha utilizado para realizar el drive test.

Cada programa tiene un formato de salida específico, y sería muy complicado ahora - aunque no imposible - para crear una aplicación que lee los datos exportados directamente.

Afortunadamente, todo el software tiene la facilidad para exportar a archivos más comunes como TXT, CSV o XML.

Este es el más simple, y por varias razones, utilizamos el principio. En el futuro, si hay interés, podemos ir más profundo y muestran cómo manejar los datos directamente en el formato propietario de cada software. Hacemos hincapié en que esto no sólo es simple, así que vamos a no hablar de esto hoy.

Nota: ver, esto no es necesariamente un problema. Por ejemplo, si desea analizar sus datos en Mapinfo, primero usted debe también exportar los datos a un formato de MapInfo. Por otra parte, en el caso de nuestra herramienta personalizada, no es para hacer otra cosa además de exportar los datos de software de drive test.

Así podemos tener nuestra entrada como de texto (.TXT o .CSV) o como hojas de cálculo Excel (.XLS o .XLSX). Estos formatos son soportados actualmente por nuestra herramienta personalizada GE Hunter Drive Test. Ver quién está ya muy flexible, ya que es una colección de software que no exportan por lo menos a uno de estos formatos.

 

¿Cómo funciona este módulo?

Los pasos siguientes muestran cómo un procedimiento simplificado para la obtención de los archivos finales.

  • 1) Realizar la recolección de datos, utilizando cualquier dispositivo o una colección de software,
  • 2) La exportación de los datos recogidos para TXT, CSV, XLS o XLSX, y almacenar uno o más archivos en la carpeta C:\Hunter\GE\DriveTest\Data\;
  • 3) Abrir el archivo GE_DriveTest_1.0_RUN.mdb en la carpeta Scripts, ejecutar la macro GE_DriveTest_Main_RUN y esperar a la transformación;
    • El script comprueba si hay algún archivo en el formato anterior, y si lo encuentra, importa el mismo para una tabla DriveTest, a continuación, crea el archivo de salida, con base en la información de la consulta qry_DriveTest. Esta consulta tiene un poco de ingenio y dispositivos, como se discute a continuación.

Pronto. Los datos ya están disponibles en la carpeta de salida de C:\Hunter\GE\DriveTest\Output\.

 

La entrada de datos

Para demostrarlo, vamos a seguir el procedimiento anterior, mostrando cómo se procesan los datos. Usted debe recordar que sólo tiene que utilizar datos ficticios en nuestros ejemplos, y que en un tutorial anterior que ya exportan datos ficticios para drive test en nuestra red para el archivo log_exported. Así que vamos a usar ese mismo archivo en la actualidad.

 

Importación de un archivo de texto a Access

Una vez que uno o varios archivos en el directorio de datos, puede ejecutar la macro, y generar un archivo KML que corresponde a cada uno de ellos.

¿Y cómo se hace esto? Bueno, de forma manual la importación de datos en Access ya se ha demostrado en un tutorial anterior. Vamos a ver cómo se hace esto a través de código VBA.

Para importar un archivo de forma automatizada, lo primero que debe tener una especificación de importación. ¿Qué significa esto? En pocas palabras, es una especificación que indica a Access cómo el formato del archivo de texto que está importando. Por ejemplo, si el archivo utiliza una coma como separador o pestaña, si la primera línea tiene el nombre de los campos, etc. Así que lo primero que debe hacer es crear nuestra especificación de importación a un archivo de texto con nuestro formato.

Para ello, importar el archivo de forma manual a través de la interfaz normal de menú de acceso - Datos Externos -> Archivo de texto. Pero en el último paso, NO haga clic en Finalizar (1). En su lugar, haga clic en el botón Opciones avanzadas (2).

 

Tenga en cuenta que llegar allí es la información que Access utilizará para completar la importación. Dado que queremos utilizar esta especificación otras veces, se guarda esta especificación, haga clic en Guardar como .. (1).

 

Y guarde esta especificación como DriveTest importación Especificación (1). Haga clic en el botón OK (2).

 

No tienen que terminar la importación, ya hicimos lo que quería, que era para salvar a la especificación de este archivo.

Nota: Si usted completa la importación, Access pregunta si todavía quiere salvar a todos estos pasos para importar. No confunda, esto es otra cosa, y nosotros no lo necesitamos, hemos salvado la especificación, que es lo que nos interesa. Simplemente haga clic en Cerrar.

Pronto. Lo que tenemos hasta ahora? El Access ya saben lo que son las características de nuestro archivo. Ahora cada vez que tiene que importarlo de nuevo - ya sea con nuevos datos, pero en este formato - que podemos utilizar esta especificación.

Y lo haremos directamente en el código.

El comando que hace esto es el TransferirText.

Y los argumentos son muy intuitivos:

  • TransferType: cuando decimos que es una importación delimitado o fijo columnas de longitud. En nuestro caso, está delimitado por tabuladores, elija acImportDelimited.
  • SpecificationName: el nombre de la especificación de importación que se guardó previamente en el caso DriveTest Import Specification.
  • Table Name: el nombre de tabla a la que vamos a importar el archivo, si DriveTest.
  • FileName: nombre completo del archivo, con la ruta. En nuestro caso, C:\Hunter\GE\DriveTest\Data\Hunter_GE_DriveTest.txt.
  • HasFieldNames: la primera línea de nuestro archivo tiene el nombre de los campos, así que pusimos Yes.
  • HTMLTableName: pueden dejar en blanco.
  • CODEPAGE: pueden dejar en blanco.

Y nuestro código responsable de la importación:

 

Nota: Tenga en cuenta que se utiliza el signo _ al final de la línea, lo que indica que no ha terminado. Esto sirve únicamente para legible, para que las líneas no son enormes, y es más fácil analizar el código.

Claro, cuando esa línea se ejecuta, el archivo C:\Hunter\GE\DriveTest\Datos de programa\Hunter_GE_DriveTest.txt se importarán en la tabla DriveTest, con los campos definidos en el acuerdo con la importación especificación DriveTest Import Specification, como ya se ha guardado.

Ahora podemos utilizar estos datos y escribir el archivo KML.

 

El flujo de datos

Pero antes de escribir el archivo KML, que tenemos que hacer algunos tratamientos, porque los datos no son de la mejor manera posible. Y por eso vamos a utilizar las consultas.

En este tutorial, vamos a tener el diagrama de flujo siguiente:

 

Tras el diagrama de flujo, ya importar el archivo Hunter_GE_DriveTest.txt en la tabla DriveTest.

Ahora, puede crear una consulta sencilla, sólo para buscar la base de datos de la tabla DriveTest. Como se mencionó anteriormente, nunca es bueno usar consultas directamente a las bases de nuestra tabla. Esta consulta funciona algo así como un puente. Tratando de explicar, la primera consulta, que es más o menos como un espejo de la tabla (y por eso tal vez usted piensa que no le importaba en absoluto), sino que nos permite hacer algunos ajustes, como cambiar algún tipo de datos - tales como texto a número. Pero bueno, quizás ahora todavía es un poco temprano para que usted pueda entender. De todos modos, vamos a continuar desde el qry_DriveTest consulta, un espejo de nuestra mesa.

Ver el resultado de la consulta qry_DriveTest.

 

El siguiente paso es interesante y requiere una breve explicación de cómo se realiza la recogida.

El equipo de drive test mediante GPS, y recoger datos de forma continua. Y a veces sucede que en algunos puntos se toman varias medidas. O por lo menos en muy cerca uno del otro. Muy bien, podríamos trazar todos los puntos planteados, pero había un pequeño problema, especialmente cuando el drive test es muy grande: más puntos de lo necesario para representar a la demora en cargar. Así que usar el dispositivo para limitar los puntos de la latitud y longitud cuarto decimal. A continuación, se agruparon estos nuevos conjuntos de los puntos, por lo que las operaciones necesarias en otros campos. Por ejemplo, para el nivel de señal, tomamos la media.

Los siguientes cuadros nos ayudan a entender mejor el dispositivo utilizado. En la primera tabla (1) tenemos los datos exportados como en el caso con 6 decimales. La segunda tabla (2) presenta los datos de la misma tabla, sólo que ahora con los valores de latitud y longitud a cuatro decimales, e igual agrupados por colores. En la última mesa (3) tenemos el resultado de la consulta qyr_DriveTest_Coords, utilizado en el trazado de los datos. Tenga en cuenta que nuevo par de latitud y longitud se agrupan, y el campo signal_level nuevo contiene la señal de media en los puntos agrupados.

Este enfoque resulta ser mucho más cercano a la realidad. También porque así aumentamos la precisión en cada punto, es como si hubiéramos realizado varias mediciones y se utilizó el promedio. Simple y eficaz, ¿no?

 

dos informaciones importantes: se puede elegir otro tipo de enfoque, por ejemplo, 5 cifras decimales, o incluso no usar ese enfoque - si es mejor tener un detalle muy grande, todos los puntos - acaba de hacer cambios en esta consulta. Otra cosa: no se preocupe si usted no entiende. Con el tiempo, esto se hará más claro para usted.

Véase ahora el resultado de la consulta qry_DriveTest_Coords.

 

Continuando, llegamos al punto en que tenemos que crear los temas para nuestros archivos. Es decir, cada registro tendrá un nuevo campo calculado de acuerdo con los datos que desea crear el mapa temático. Por ejemplo, si el nivel de señal es de -75 dBm y -65, y la coloración amarilla, si usted está entre -85 y -75 dBm, como el color gris, y así sucesivamente.

Por ello hemos creado el campo themathic_signal_level calculado con la fórmula se muestra a continuación.

themathic_signal_level :
SiInm (([signal_level] <-105), "rojo",
SiInm (([ ] signal_level> =- 105 Y [] signal_level <-95), "naranja",
SiInm (([signal_level]> =- 95 Y [] signal_level <-85), "amarillo"
SiInm (([signal_level]> =- 85 Y [] signal_level <-75), "lightgreen"
SiInm (([signal_level]> =- 75 Y [signal_level <] -65), "verde",
SiInm (([signal_level]> =- 65), "azul",
""))))))

Observe cómo nuestros datos son ahora. En la nueva consulta qry_DriveTest_Themathic, que themathic_signal_level campo. Se basa en los valores de este campo que asignar estilos a cada punto (marcador) en Google Earth.

 

Tenga en cuenta que para cada indicador que creamos, tenemos una leyenda diferente. A continuación se muestra el título de signal_level. Los archivos auxiliares con estas leyendas en wrod se encuentran en el directorio del módulo de Ayuda de GE. En el futuro veremos un poco más sobre la creación de los títulos y los indicadores.

 

Bueno, ahora podemos escribir el archivo KML, utilizando los datos de esta consulta. Así que vamos a seguir ...

 

código

Todos los artefactos y las particularidades que la herramienta utiliza para determinar los datos ya se han mencionado más arriba, y ya puede adaptar su código para funcionar de este modo. Si se suscribe, por favor recuerde que la forma más sencilla de aprender el código es leído, ya que es una revisión completa. Cualquier pregunta, por favor póngase en contacto con nuestro apoyo.

La siguiente es una parte inicial del código, donde los puntos más importantes ya han sido expuestas en el presente o el anterior tutorial.

 

Importante: recuerde que nuestra intención es, sobre todo para enseñar. Usted notará que algunas partes del código original se simplifican. Por ejemplo, el código importa un archivo fijo, o fuertemente codificados - incluso si el nombre viene de una strFileName variable. Si cambiamos el nombre del archivo a algo distinto de Hunter_GE_DriveTest.txt no funcionará más.

Este no es un comportamiento ideal, y desde luego no lo usamos. Pero tenemos que avanzar lentamente, hay varios otros elementos y características que se añadirán a ese módulo y exeplicadas GE DriveTest.

Todavía tendremos nuevas mejoras en su forma genérica, como la creación de formularios - Interfaces - para facilitar la interacción. Una vez más, esto se está creando gradualmente, de modo que usted percibe.

Volviendo a nuestra aplicación de hoy, aunque en cierto modo muy sencillo, especialmente para aquellos que ya programa, el resultado es bastante interesante, como se muestra a continuación.

 

Nota: Es importante que usted sepa que los datos no estén perfectamente alineadas con las calles de Google Earth, ya que se genera de forma aleatoria y no por un error en nuestro programa. Cuando se utiliza con datos reales de la red, podrás ver que los datos están perfectamente alineados, a excepción de algunas inexactitudes del GPS.

Tenga en cuenta que todos los puntos se puede hacer clic, tanto en la interfaz principal, el navegador en el lado. Por ejemplo, si usted quiere navegar a un nivel específico de mala señal, haz doble clic en él.

 

Por otra parte, utiliza todos los recursos que están disponibles. Por ejemplo, puede abrir nuestra red Hunter_GE_Network, y el análisis de una prueba de conducción junto con el sector de la información. Usted puede comprobar rápidamente que la antena se está utilizando, lo que la tilde, etc.

 

Toda esta información, junto con otros que veremos más adelante, ofrecer un análisis mucho más rápida y eficiente. Esa es nuestra meta: crear un único y centralizado, y toda la información disponible clave necesarias para actuar.

Pronto verá cómo este conjunto de información es importante y esencial en la vida cotidiana de un profesional en el ámbito de telecomunicaciones y TI.

 

Conclusión

Nos enteramos hoy la manera de representar gráficamente los datos de una prueba de conducción en Google Earth, desde un simple archivo de texto, exportados por la colección de software oa la transformación.

En términos de programación, vimos cómo se hace la importación de un archivo de texto mediante código VBA. Mientras que la importación no ha sido dinámico - importamos un archivo con nombre fijo y el formato, que sirve para entender las necesidades de futuras implementaciones que minimizan esta limitación.

El resultado final, aunque simple, nos permite ver la importancia de las herramientas que nos ayudan tanto en la velocidad de procesamiento, precisión en el análisis y la facilidad de operación. Este es el objetivo principal del sistema de Hunter, que poco a poco lo sabrás.

Esperamos que tengas gostado. Tire alguna duda en los comentarios en el blog o através de nuestro soporte vía chat o e-mail.

A nuestra próxima reunión, y recuerde: Su éxito es nuestro éxito!

Esperamos que tengas gostado. Tire alguna duda en los comentarios en el blog o através de nuestro soporte vía chat o e-mail.

A nuestra próxima reunión, y recuerde: Su éxito es nuestro éxito!