Selecione pela faixa de frequência de interesse para visualizar o conteúdo
disponível!
Ou utilize o ÍNDICE abaixo para uma listagem
hierárquica do site.
|
|
|
Diagramas, scripts, demais informações sobre a WRAP, 3G e etc.
1) Notas iniciais: Como uso um GPS conectado à WRAP pela porta serial (RS232 4800-8-N-1), antes de mais nada foi necessário, através da configuração da BIOS, liberar a tal porta para o sistema operacional. Nesta série de embedded PCs, essa operação é irreversível. Ou seja: uma vez que se libere à porta em questão ao OS, não há mais como reverter essa operação, exceto por uma reprogramação externa da flash, retirando-a da WRAP (retrabalhar o PCB, portanto). Como esta série está fora de linha, tratei de me certificar que tinha a última revisão da BIOS instalada e então liberei a porta serial. O sistema operacional é da Mikrotik. No site do desenvolvedor há a versão 3.20 disponível (hoje, 24/02/09). Mas estou utilizando a versão "3.21" pois a 3.20 tem um bug que não permite visualizar os recursos USB na interface gráfica de configuração (Winbox). Recorri ao suporte e em 24 horas recebi por e-mail um link para donwload desta versão "3.21". Perfeito, tudo funcionando normalmente. Mas a versão ainda não aparece disponível no site, não sei por que. Uso um modem Huawei E156. Ele é reconhecido pelo ROS Mikrotik normalmente. As únicas configurações necessárias na criação do client-ppp são o número do telefone e senha. O único string de inicialização que uso é ATZ (reset do modem). E o MTU ajustei para 1400, depois de verificar que é o valor que meu provedor de acesso 3G tem usado. Outra providência, antes de esquecer o modem na WRAP, foi efetuar uma conexão usando a interface gráfica do provedor e nas configurações me certificar de remover o modem do modo "automático". Tive que recorrer à aplicação do provedor pois a Huawei é meio "misteriosa" na divulgação dos protocolos usados para mandar (ou receber) instruções de configuração ao/do modem. Me dei conta que se o fizesse usando a interface do provedor, desconectasse e removesse o modem da porta USB do PC, que ele guardaria - pelo menos - esta configuração relativa ao modo e faixa de frequências. Normalmente, tanto a seleção do tipo de conexão (GPRS/GSM/UMTS) como a faixa de frequências (800/900/1800/1900/2100 MHz) são automáticas. Não queria o modem "decidindo" entre GSM e UMTS. Então selecionei somente WCDMA e na faixa de frequências, 2100MHz). Mantive a seleção e registro na operadora em automático. No ROS da Mikrotik, uma vez que a conexão ppp esteja funcionando, pode-se abrir um "new terminal" e com a linha de comando (no meu caso) "sys serial-terminal USB2" ter acesso à telemetria do modem. É possível também enviar alguns comandos, ler de 1 em 1 segundo o RSSI (ajuda no ajuste da posição da antena) e etc. Até um "hard reset" é possível digitando o comando "AT+CGATT=0" (ele desliga a alimentação do modem e volta à ligar). O recurso SMS do ROS Mikrotik funciona normalmente com este modem. Desta forma pode-se configurar o ROS para enviar SMS em casos selecionados e críticos (falta de energia elétrica, violação de regras no firewall, etc).
2) Scripts básicos: Como minha aplicação é doméstica, uso apenas dois scripts para manter as coisas o mais livre possível de intervenção e operação. O ponto de maior vulnerabilidade é, sem dúvidas, a conexão à internet. Ao longo do tempo verifiquei que mesmo estando "conectado", as vezes não era possível trafegar. Não sei em que ponto da rede do provedor há este travamento. Certeza que não é na WRAP pois testei usando uma conexão discada convencional via porta serial e não trava nunca (leia-se semanas, a conexão discada, antes do GPS conectado, era meu fall-back). Então depois de consultar os foruns do desenvolvedor do ROS, cheguei à um script que em suma é um watchdog. Ele verifica um determinado endereço IP no core da rede do provedor (uns 2 ou 3 hops depois da ERB) à cada 5 segundos. Se não obtiver resposta à um ping em até 5000ms, o estado deste watchdog comuta para down e incia-se uma rotina mais precisa de verificação deste travamento. Essa rotina dispara uma série de pings contra um outro endereço no core da rede, um à cada 1 segundo, com 1000ms de timeout. São disparados 15 pings e, se nestes 15 nenhum resultar em resposta, o script desabilita a interface ppp, aguarda 10 segundos e volta à habilitar. Isso quer dizer que em caso de problemas com a conexão, são 5 segundos do watchdog, 15 segundos da segunda rotina, 10 segundos de espera e o tempo de reconexão (discar é 1 segundo, autenticar pode variar de imediato à 30 segundos). Ou seja: na melhor das hipóteses, após um travamento na conexão, em 35 segundos estará tudo normal novamente. O script em questão é este. Não esqueça de substituir os nomes do ppp-client para o nome usado.
Não criei um script separado para ser "chamado" pelo Netwatch do ROS (tools>netwatch). Configurei o Netwatch para disparar pings contra o tal endereço no core do provedor e no tab "on down" redigi a rotina que está aí em cima na moldura. O ping com 128 bytes foi usado pois observei uma coisa: parece que a rede 3G do provedor não "gosta" de pings com 32 bytes. O RTT ficava variando entre 90ms e 500ms, perdendo alguns inclusive. Para pacotes maiores que 40 bytes, o RTT se mantém em 90ms em média, perda zero (à não ser quando o pessoal de IT da operadora se embanana nas reconfigurações dos roteadores no core da rede. Nesses eventos, a latência varia entre três valores observados: 90, 220 e 500ms. E a operadora "jura" que não há nada na rede, que o sinal 3G é sujeito à chuva, efeitos de propagação, etc. Normal). Outra rotina que foi implementada, e aí usando a arquitetura para scripts do ROS, foi uma que verifica se os dados entregues pelo GPS à WRAP são válidos. Essa informação é dada pelo GPS, um par de bytes na sentença RMC. Quando os dados do GPS não são válidos - quer dizer - o GPS informa que não está com seu relógio interno sincronizado com os satélites - o ROS deixa de ajustar o RTC da WRAP. E então este fica à deriva, ou melhor, dependente de um oscilador com ressonador cerâmico de qualidade duvidosa. Como a WRAP é meu NTP server para os PCs de casa, é de meu interesse que o clock da placa esteja sincronizado ou ao GPS, ou à um NTP server na internet (time-b.nist.gov, por exemplo). A rotina que foi implementada verifica então se os dados do GPS são válidos, à cada 10 minutos. Se o GPS está sincronizado, o clock da WRAP fica amarrado ao GPS. Há uma rotina no ROS que verifica o drift do relógio da placa e assim esta rotina determina de quanto em quanto tempo tem que aplicar correções ao clock, seja usando o GPS como fonte, seja um NTP server na internet. Porém se os dados do GPS não são válidos, este script desabilita o ajuste da hora da placa pelo GPS e habilita um NTP client, que aponta para dois servidores NTP. O script continua verificando o status do GPS e tão logo os dados deste sejam válidos novamente, ele desabilita o NTP client e permite o ajuste do clock da WRAP pelo GPS, novamente. No ROS, em "system>scheduler" foi criado um job com intervalo de 5 minutos, e no campo "on-event" há o nome do script à ser chamado (no meu caso, "gps-ntp"). O código-fonte do script é este:
Ainda não adicionei uma bateria para o RTC da WRAP (3V, de máquina fotográfica), mas acontecerá antes da instalação no local definitivo. |
Visitantes: Solar X-rays
|
Copyright © 2009 PY3CRX Amateur Radio PY2PLL
|
