telecomHall BR

 

Hunter GE Drive Test (Signal Level)

terça-feira, 8 de junho de 2010 20:00:00 Categories: Access Drive Test Google Earth Hunter
Rate this Content 1 Votes

Como já vimos, os Drive Test são importantes para uma análise mais completa da rede. As diversas ferramentas de pós-processamento existentes apresentam um completo conjunto para essa análise, mas às vezes nosso trabalho pode ser bem mais simplificado, e por que não, às vezes obtendo um melhor resultado.

 

 

Este é o caso por exemplo do processamento customizado de drive test – podemos até não ter o poder dos algoritmos e detalhamento de alguns softwares, mas conseguimos resultados surpreendentemente simples e eficientes. Vamos aprender hoje uma forma criativa de plotar os dados de nível de sinal de uma rede no Google Earth, não importando qual tenha sido o equipamento/software que tenha realizado a coleta do drive test.

 

Objetivo

A partir dos dados coletados em drive test, gerar um arquivo de saída no formato KML do Google Earth com as informações plotadas de acordo com nossas escolhas.

Em outras palavras, plotar os dados do drive test no Google Earth, mais ou menos como fazemos com mapas temáticos no Mapinfo.

Nota: Na grande maioria dos tutoriais temos os arquivos relacionados, e que são enviados para os Assinantes.

  • Se você é um Assinante, por favor verifique em seu e-mail o arquivo recebido para este tutorial, e utilize o suporte para qualquer dúvida ou problema que encontrar.
    • Blog_013_Hunter_GE_DriveTest_(signal_level).zip.
  • Se você é um Membro comum e tem acesso apenas ao tutorial escrito, aprenderá sempre conceitos muito importantes que com certeza vão lhe ajudar em seus próprios desenvolvimentos. Leia e comprove em cada novo tutorial.
    • Se você deseja contribuir de alguma forma, a maneira mais simples é tornar-se um Assinante.

A nossa audiência vai de estudantes a profissionais experientes. Por isso pedimos um pouco de compreensão e tolerância se alguns dos conceitos hoje apresentados forem básicos para você. Além disso, todos os tutoriais, códigos e programas estão num processo contínuo de edição. Isso significa que se encontrarmos algum erro, por exemplo, de gramática ou ortografia, tentaremos corrigi-lo o mais rápido possível. Também gostaríamos de receber o seu feedback, nos informando de erros encontrados ou passagens que ficaram confusas e merecem ser reescritas.

 

Estrutura de Arquivos

Mais um novo módulo. Como sempre, vamos aumentando a nossa estrutura para nos adequar as necessidades. Você já deve ter percebido como a organização é importante. A cada vez que a ferramenta Hunter cresce, fica mais importante manter os módulos interligados.

Esse é um módulo que também utiliza o Google Earth – GE – por isso a estrutura é criada abaixo do diretório GE. Crie o diretório DriveTest (1), como o diretório principal desse módulo. Os demais diretórios Data (2), Output (3) e Scripts (4) são os padrão dos módulos da nossa ferramenta. Só relembrando, são respectivamente os diretórios onde ficam os nossos dados de entrada como os arquivos coletados no drive test, os dados de saída, no caso de hoje um arquivo .KML com os dados formatados, e o diretório de Scripts, hoje com o arquivo que faz o processamento, e vamos criar a partir de agora.

 

Observe que temos um diretório de Ajuda – Help (5). Nesse diretório armazenamos todos os arquivo auxiliares para esse módulo especificamente. Veja também que esse módulo utiliza o diretório icon (6), lembrando que este diretório já havia sido criado anteriormente, uma vez que é compartilhado com diversos módulos.

 

Os dados de entrada

Nosso principal objetivo é criar uma aplicação que seja compatível com a saída de qualquer que seja o equipamento e/ou software que tenha sido utilizado para realizar o drive test.

Cada um desses softwares possui um formato de saída específico, e ficaria bem complicado agora – embora não seja impossível – criar um aplicativo que lesse diretamente esses dados exportados.

Felizmente, todos esses softwares possuem a facilidade de exportar para arquivos mais comuns, como TXT, CSV ou XML.

Essa é a forma mais simples, e por diversos motivos, a que vamos usar a princípio. Futuramente, se houver interesse, podemos nos aprofundar mais e mostrar como tratar os dados diretamente no formato proprietário de cada software. Reforçamos apenas que isso não é simples, e por isso não vamos falar mais disso hoje.

Nota: veja bem, isso não é necessariamente um problema. Por exemplo, se você quiser analisar seus dados no Mapinfo, primeiro você também deverá exportar os dados para um formato do Mapinfo. Além disso, no caso de nossa ferramenta customizada, não é necessário fazer mais nada além de exportar os dados do software de drive test.

Assim, podemos ter os nossos dados de entrada como texto (.TXT ou .CSV) ou como planilhas do Excel (.XLS ou .XLSX). Esses são os formatos atualmente suportados pela nossa ferramenta customizada Hunter GE Drive Test. Veja que já é bem flexível, uma vez que não existe um software de coleta que não exporte para pelo menos um desses formatos.

 

Como esse módulo funciona?

Os passos abaixo mostram de forma simplificada como é o procedimento para se obter os arquivos finais.

  • 1) Realize a coleta de dados, usando qualquer equipamento e/ou software de coleta;
  • 2) Exporte os dados coletados para o formato TXT, CSV, XLS ou XLSX, e armazene um ou mais arquivos na pasta C:\Hunter\GE\DriveTest\Data\;
  • 3) Abra o arquivo GE_DriveTest_1.0_RUN.mdb localizado na pasta Scripts, rode a macro GE_DriveTest_Main_RUN e aguarde o processamento;
    • O script verifica se existe algum arquivo no formato acima, e caso encontre, importa o mesmo para uma tabela DriveTest; em seguida, cria o arquivo de saída, baseado nas informações da consulta qry_DriveTest. Essa consulta tem alguns truques e artifícios, como veremos a seguir.

Pronto. Os dados já estão disponíveis na pasta de Saída C:\Hunter\GE\DriveTest\Output\.

 

Dados de Entrada

Para demonstrar, vamos seguir o procedimento acima, mostrando como os dados são tratados. Você deve se lembrar que somente usamos dados fictícios em nossos exemplos, e que em um tutorial anterior já exportamos dados fictícios de drive test da nossa rede para o arquivo log_exported. Então vamos usar esse mesmo arquivo hoje.

 

Importando um arquivo de texto para o Access

Uma vez que um ou mais arquivos estejam no diretório Data, podemos rodar a macro, e gerar um arquivo KML correspondente para cada um deles.

E como é feito isso? Bom, a importação de Dados manualmente para o Access já foi mostrada em um tutorial anterior. Vamos ver agora como isso é feito através do código VBA.

Para importar um arquivo de forma automatizada, precisamos primeiramente ter uma Especificação de Importação. O que isto significa? De forma simples, é uma especificação que diz ao Access como é o formato do arquivo texto que ele está importando. Por exemplo se o arquivo usa vírgula ou tabulação como separador, se a primeira linha tem o nome dos campos, etc. Assim, a primeira coisa a fazer é criar a nossa especificação de importação para um arquivo de texto com o nosso formato.

Para isso, importe o arquivo manualmente pela interface normal do Access – Menu Dados Externos -> Arquivo de Texto. Porém, no último passo, NÃO clique em Concluir (1). Ao invés disso, clique no botão Avançado (2).

 

Observe que ficar aí armazenadas as informações que o Access utilizará para concluir a importação. Como desejamos utilizar essa especificação outras vezes, vamos salvar essa Especificação, clicando no botão Save As... (1).

 

E salve essa especificação como DriveTest Import Specification (1). Clique no botão OK (2).

 

Não precisa terminar a importação, já fizemos o que queríamos, que era salvar a especificação desse arquivo.

Nota: se você concluir a importação, o Access ainda vai perguntar se você deseja salvar todos esses passos da importação. Não confunda, isso é outra coisa, e não vamos precisar disso, já temos a especificação salva, que é o que nos interessa. Simplesmente clique em Fechar.

Pronto. O que temos até agora? O Access já sabe quais são as características do nosso arquivo. Agora sempre que precisarmos importá-lo novamente – ou outro com novos dados, mas neste formato – podemos usar essa especificação.

E isso nós vamos fazer diretamente no código.

O comando que faz isso é o TransferText.

 

E os argumentos são bem intuitivos:

  • TransferType: onde dizemos se é uma importação delimitada ou com colunas de tamanho fixo. No nosso caso é delimitado por tabulações, escolhemos acImportDelimited.
  • SpecificationName: o nome da especificação de importação que salvamos previamente, no caso DriveTest Import Specification.
  • TableName: o nome da tabela para o qual vamos importar o arquivo, no caso DriveTest.
  • FileName: o nome completo do arquivo, com o caminho. No nosso caso, C:\Hunter\GE\DriveTest\Data\ Hunter_GE_DriveTest.txt.
  • HasFieldNames: a primeira linha do nosso arquivo tem o nome dos campos, por isso colocamos Yes.
  • HTMLTableName: pode deixar em branco.
  • CodePage: pode deixar em branco.

E nosso código responsável pela importação:

 

Nota: Observe que usamos o sinal _ no final da linha, indicando que a mesma não terminou. Isso serve apenas para fins de leitura humana, para que não fiquem linhas enormes, e fique mais fácil de analisar o código.

Certo, quando essa linha for executada, o arquivo C:\Hunter\GE\DriveTest\Data\ Hunter_GE_DriveTest.txt será importado para a tabela DriveTest, com os campos definidos de acordo com a especificação de importação DriveTest Import Specification, conforme salvamos anteriormente.

Agora já podemos utilizar esses dados e escrever o arquivo KML.

 

Tratando os dados

Mas antes de escrevermos o arquivo KML, precisamos fazer alguns tratamentos, pois os dados não estão na melhor forma possível. E para isso vamos utilizar consultas.

Nesse tutorial, teremos o seguinte fluxograma:

 

Seguindo o fluxograma, já importamos o arquivo Hunter_GE_DriveTest.txt para a tabela DriveTest.

Agora criamos uma consulta simples, apenas para buscarmos os dados da tabela base DriveTest. Como falamos anteriormente, nunca é bom utilizarmos consultas diretamente nas nossas tabelas bases. Essa consulta funciona mais ou menos como uma ponte. Tentando explicar melhor, a primeira consulta, que é mais ou menos como um espelho da tabela (e por esse motivo talvez você imagina que não tivesse importância nenhuma), mas nos permite fazer alguns ajustes, como por exemplo alterar algum tipo de dados – como de texto para inteiro. Mas tudo bem, talvez agora ainda seja meio cedo para você entender. De qualquer forma, vamos continuar a partir da consulta qry_DriveTest, um espelho da nossa tabela.

Veja o resultado da consulta qry_DriveTest.

 

O próximo passo é interessante, e requer uma breve explicação sobre como é realizada a coleta.

Os equipamentos de drive test utilizam GPS, e coletam dados continuamente. E às vezes, ocorre que em alguns pontos são realizadas várias medidas. Ou pelo menos em pontos muito próximos uns dos outros. Tudo bem, poderíamos plotar todos os pontos gerados, mas teríamos um pequeno problema, principalmente quando o drive test for muito grande: mais pontos do que o necessário representam mais demora para carregar. Assim, utilizamos o artifício de limitar os pontos na quarta casa decimal da latitude e longitude. Em seguida, agrupamos esses novos conjuntos de pontos, fazendo as operações necessárias nos demais campos. Por exemplo, para o nível de sinal, tiramos a média.

As tabelas a seguir nos ajudam a compreender melhor o artifício usado. Na primeira tabela (1), temos os dados exatamente como foram exportados, no caso com 6 casas decimais. A segunda tabela (2) apresenta os dados da mesma tabela, só que agora com latitude e longitude com 4 casas decimais, e os valores iguais agrupados por cores. Na última tabela (3) temos o resultado da consulta qyr_DriveTest_Coords, usado na plotagem dos dados. Observe que os novos pares de latitude e longitude são agrupados, e o novo campo signal_level contém a média do sinal nos pontos agrupados.

Essa aproximação mostra-se muito próxima da realidade. Até porque, dessa forma, acabamos aumentando a precisão em cada ponto, pois é como se tivéssemos realizado várias medidas e utilizássemos a média. Simples e eficiente, não?

 

Duas informações importantes: você pode escolher outro tipo de aproximação, como 5 casas decimais, ou até mesmo não usar essa aproximação – se deseja ter um detalhe muito grande, de todos os pontos – basta fazer as alterações nessa consulta. Outra coisa: não se preocupe se não entendeu. Com o tempo, isso vai ficar mais claro para você.

Veja agora o resultado da consulta qry_DriveTest_Coords.

 

Continuando, chegamos ao ponto em que devemos criar os temas para os nossos registros. Ou seja, cada registro terá um novo campo, calculado de acordo com o dado que desejamos criar o mapa temático. Por exemplo, se o nível de sinal estiver entre -75 e -65 dBm, colorir como amarelo, se estiver entre -85 e -75 dBm, colorir como cinza, e assim por diante.

Criamos então o campo calculado themathic_signal_level, com a fórmula mostrada abaixo.

themathic_signal_level:
IIf(([signal_level]<-105),"red",
IIf(([signal_level]>=-105 And [signal_level]<-95),"orange",
IIf(([signal_level]>=-95 And [signal_level]<-85),"yellow",
IIf(([signal_level]>=-85 And [signal_level]<-75),"lightgreen",
IIf(([signal_level]>=-75 And [signal_level]<-65),"green",
IIf(([signal_level]>=-65),"blue",
""))))))

Observe como ficam agora os nossos dados. Na nova consulta qry_DriveTest_Themathic, temos o campo themathic_signal_level. É baseado nos valores desse campo que atribuiremos os estilos a cada ponto (marcador) no Google Earth.

 

Observe que para cada indicador que criarmos, temos uma legenda diferente. Abaixo temos a legenda para signal_level. Os arquivos auxiliares com essas legendas no Wrod encontram-se no diretório Help do módulo GE. No futuro, veremos um pouco mais sobre criação de legendas e indicadores.

 

Pronto, agora podemos escrever o arquivo KML, com os dados dessa consulta. Então, vamos continuar...

 

O código

Todos os artifícios e particularidades que a ferramenta usa para plotar os dados já foram mencionados acima, e você já consegue adaptar seus códigos para que funcionem dessa forma. Se você é assinante, por favor, lembre-se que a forma mais simples de aprender o código é ler o mesmo, já que ele encontra-se totalmente comentado. Qualquer dúvida, por favor entre em contato com o nosso suporte.

A seguir temos uma parte inicial do código, onde os pontos mais importantes já foram explanados nesse ou em tutorial anterior.

 

Importante: lembre-se que nossa intenção é acima de tudo ensinar. Você irá perceber que algumas partes desses código inicial estão simplificadas. Por exemplo, o código importa um arquivo fixo, ou hard-coded – mesmo que esse nome esteja vindo de uma variável strFileName. Se alterarmos o nome do arquivo para algo diferente de Hunter_GE_DriveTest.txt já não vai funcionar.

Esse não é um comportamento ideal, e com certeza não é o que usamos. Mas precisamos avançar aos poucos, existem diversos outros itens e funcionalidades que serão adicionadas e exeplicadas para esse módulo GE DriveTest.

Ainda teremos outras melhorias de forma genérica, como a criação de formulários – interfaces – para facilitar a interação. Novamente, isso vai sendo gradativamente demonstrado, de forma que você apreenda.

Voltando a nossa aplicação de hoje, embora de certa forma bem simples principalmente para quem já programa, o resultado é bem interessante, conforme mostrado abaixo.

 

Nota: é importante que você saiba que os dados não estão perfeitamente alinhados com o arruamento do Google Earth porque eles foram gerados aleatoriamente, e não por um erro do nosso programa. Quando você utilizar com os dados reais de sua rede, verá que os dados ficam perfeitamente alinhados, salvo algumas imprecisões de GPS.

Observe que todos os pontos são clicáveis, tanto na interface principal, quanto no browser ao lado. Por exemplo, se você deseja navegar para um ponto específico de nível de sinal ruim, basta dar um duplo clique no mesmo.

 

Além disso, você utiliza todos os recursos que estiverem disponíveis. Por exemplo, pode abrir a nossa rede Hunter_GE_Network, e analisar o drive test junto com as informações dos setores. Pode verificar rapidamente qual a antena está sendo usada, qual o til, etc.

 

Todas essas informações, aliadas a outras que iremos ver, proporcionam uma análise muito mais rápida e eficiente. Esse é o nosso objetivo: criar uma aplicação única, centralizada, tendo disponível todas as principais informações necessárias para a tomada de ações.

Em breve você ira perceber como esse conjunto de informações é importante, e essencial no dia a dia de um profissional da área de Telecom e TI.

 

Conclusão

Aprendemos hoje como plotar os dados de um drive test no Google Earth, a partir de um arquivo texto simples, exportado pelo software de coleta/processamento.

Em termos de programação, vimos como é feita a importação de um arquivo de texto pelo código VBA. Embora a importação não tenha sido dinâmica – importamos um arquivo com nome e formato fixo, serviu para compreendermos as necessidades de implementações futuras que minimizem essa limitação.

O resultado final, embora ainda simples, nos permite enxergar a importância de ferramentas que nos auxiliem tanto em rapidez no processamento, precisão nas análises e facilidade de operação. Esse é o objetivo maior do Sistema Hunter, que aos poucos você irá conhecer.

Esperamos que você tenha gostado. Tire suas eventuais dúvidas postando seus comentários no Blog ou através do nosso Suporte via Chat ou E-mail.

Até nosso próximo encontro, e lembre-se: O seu sucesso é o nosso sucesso!