Página 1 de 3 123 ÚltimoÚltimo
+ Responder ao Tópico



  1. Olá pessoal,

    Estou com um problema no meu PTP de 43km, sinal bom e CCQ muito ruim, Mikrotik RB Metal 5Shpn + Antena de 29Dbi. Segue a foto:
    Clique na imagem para uma versão maior

Nome:	         ccq.jpg
Visualizações:	499
Tamanho: 	99,9 KB
ID:      	63936

  2. mande print das suas configurações....obrigado



  3. Tem sinal -64dBm, com MCS4 (No RX).

    A ficha do Groove Metal não fala as sensibilidades de todos os datarates. Se for comparar com o Bullet, o Groove tem sensibilidade 3dBm pior nos 2 rates informados. Tanto no Bullet M como no Bullet Titanium.

    Então acho que é bem certo supor que a sensibilidade do Groove Metal em MCS4 será de -83dBm.

    De -83 pra -64dBm tem uma margem de 19dB de sinal.

    Em PTP de 1km até uma margem de 12 ou 13dB dá CCQ e throughput excelente.
    Em PTP de uns 10km já precisa margem tipo 20dB.
    Nunca passei de 30km, e em 30km uma margem de 25dB já não dá 100% de CCQ! Precisa mais de 25dB até pra 30km!

    Em 3km eu uso -70dBm e tenho coisa tipo 40Mbps half tranquilo, com CCQ de 95-98%. Em 15km com os mesmos -70dBm, o CCQ só chega em 95% se usar MCS10, e mal passa 20Mbps half. Eu gosto e procuro sempre usar MCS12 (É um MCS4 de 2 chains), mas em PTP distante ele exige muito mais sinal que em PTP próximo. Nos outros data rates também ocorre isso, -64dBm daqui até no outro quarteirão pega 99% de CCQ em MCS15 (Ou MCS7), mas depois de 10km só dá 99% de CCQ em MCS12 (Ou MCS4).

    Tem tabela tosca sobre margem, tipo:
    Clique na imagem para uma versão maior

Nome:	         margin.gif
Visualizações:	102
Tamanho: 	16,1 KB
ID:      	63938

    Dá pra usar esse site, ele pelo visto aplica a mesma fórmula:
    http://mayo.nuvisions.net/ubnt_link/

    Ele dá em verde a margem boa:
    Clique na imagem para uma versão maior

Nome:	         b5m.jpg
Visualizações:	307
Tamanho: 	90,9 KB
ID:      	63939

    As em vermelho são margens insuficientes (Refaz a conta com antena de 34dBi, e rádio a 20dBm de potência, pra ver como fica ok pra MCS4. É cálculo teórico pra ptp com 100% da zona de Fresnel limpa. Se tiver ela só 99% limpa já vai ter sinal menor que o cálculo).

    Ou seja, em 43km ele diz que a margem pra ter 100% de CCQ seria de 32dB. Se a sensibilidade é -83dBm, então o sinal precisaria estar em -83 + 32 = -51dBm.

    Em distâncias menores tipo 10 a 28km isso pra mim sempre deu certo. Nem sempre sigo porque as vezes um MCS12 com CCQ de 90% ainda dá mais throughput que um MCS11 com CCQ de 99%.

    Perguntar pra Ubiquiti e pra Mikrotik já perguntei, só me responderam coisa genérica tipo "Recomendamos 20dB de margem". A resposta de sempre fala em uptime igual os livros tratando disso, mas eles dizem pra levar em conta não só a 1ª zona de Fresnel, mas também a 2ª e 3ª (Ou seja, 200 e 300% da zona de Fresnel), aí complica, impossível coletar esses dados com precisão, teria que analisar o efeito ponta-de-faca em cada árvore no caminho, a difração na atmosfera, mas acho que o que mata a qualidade mesmo são os reflexos na zona de Fresnel (Talvez acima de certa distância, acima da 100% da zona de Fresnel), gera pacote chegando em linha reta nanosegundos antes dos reflexos, por isso um sinal mais alto seria necessário em distância maior, pra continuar mais legível.
    Clique na imagem para uma versão maior

Nome:	         82068-omni-vs-direct7.gif
Visualizações:	112
Tamanho: 	11,8 KB
ID:      	63940

    Apesar disso falar em percentual de uptime, isso diz respeito na verdade a quantidade de dados perdidos, com 18dB de margem esse post da UBNT fala em 99% de uptime, mas seria 99% de dados cehgando de forma legível. O pequeno problema é que wifi tem checksum, um pacote de 1600 ou 4000 bytes é gerado e o rádio de TX lê um CRC ou checksum dele, se 1 mísero bit (E 1 a cada 99 deve sair ilegível) for lido errado (E ainda que ele esteja ilegível, tem 50% de chance de erro e de acerto, afinal ele só tem 2 estados possível, 0 ou 1) ele vai gerar um pacote 1 bit diferente, se esse bit for levado em conta na hora do rádio de RX ler o pacote pra formar o CRC/checksum, ele vai responder um CRC/checksum errado, aí o rádio de TX avisa: "Você recebeu o pacote com erro, joga ele fora que eu vou enviar de novo".

    Nessas situação, aumentar o acktimeout pra um número muuuuito maior as vezes melhora o throughput, porque aumenta a espera pra não ler reflexo, gera um pouco a menos de perdas. Mas não resolve o problema, sei lá se costuma melhorar o throughput em 5%.

    Alias, dá pra calcular que parece que você não tem a zona de Fresnel 100% limpa (E quem tem, em mais de 20km?), porque com o rádio em 22dBm digamos, devia ter pelo cálculo sinal de -60dBm, só teria -64dBm se usar potência tipo 18dBm. Eu não passaria disso, mas acho que você deve estar usando potência mais alta que isso.


    Dá uma testada com MCS0 em 20MHz e veja se o CCQ sobe, depois MCS1, depois MCS2, depois MCS3, se você ver o CCQ caindo conforme sobe o data rate, é a margem de sinal diminuindo, pois o sinal permanecerá o mesmo (Enquanto a potência de RX for a mesma) mas cada data rate tem sensibilidade diferente.
    (Os chipsets são iguais em MK e UBNT, tirando pequenas variações a ficha de sensibilidade da maioria desses rádios baratos é igual)

    Talvez se apontar as 2 antenas 0,5 ou 1° pra cima da posição atual (Erguer menos de 1°), o sinal caia 1dBm mas o CCQ suba um pouco. Apontando a antena mais pra cima você diminui o ganho dos reflexos que chegam meio que "de baixo pra cima", diminui a intensidade do que não chega em linha reta mas sim refletindo no que tem na zona de Fresnel (Geralmente só o que tem na 1ª incomoda).

    Enfim, pra distância grande um "sinal bom" é sempre coisa muito mais alta que pra PTP de 1km, com -64dBm eu uso MCS7 tranquilo daqui até o outro quarteirão, mas sei por experiência que lá pelos 10km isso já mal dá pra MCS4 mesmo, a margem entre sinal e sensibilidade só fica bem visível em distância grande mesmo.

  4. Citação Postado originalmente por Junior Prestes Ver Post
    Olá pessoal,

    Estou com um problema no meu PTP de 43km, sinal bom e CCQ muito ruim, Mikrotik RB Metal 5Shpn + Antena de 29Dbi. Segue a foto:
    Clique na imagem para uma versão maior

Nome:	         ccq.jpg
Visualizações:	499
Tamanho: 	99,9 KB
ID:      	63936


    Em principio seu link pode estar interferido por outro canal adjacente ou co-canal. Quer dizer voce esta com bom sinal porem os interferentes atrapalham e não deixam os rádios se comunicarem livremente.

    Uma forma fácil para entender o CCQ considerar a quantidade de pacotes transmitidos que conseguem ser recebidos. No seu caso so 63% tem sucesso.

    Agora , se esta com bom sinal, também com S/N bom, o que pode atrapalhar essa recepção? algum outro rádio disputando a frequência com o seu.

    É fácil de ver a melhor frequência a ser utilizada no Mikrotik observando a ferramenta de ocupação de frequências, em ambos rádios.

    Uma forma de , a principal, de diminuir o problema e configurar a menor largura de banda possível em Wireless. Isso vai fazer que você transmita em uma faixa menor , por tanto com menor probabilidade alguém o interfira. Dai você vai aumentando ( 5MHz, 10MHZ , 20MHz, 40MHz) e observando o CCQ .



  5. Hoje meu enlace tá melhorzinho, mas o CCQ fica oscilando de 45~75% em testes.
    Segue a foto das minhas configurações:
    Clique na imagem para uma versão maior

Nome:	         config.mikro.jpg
Visualizações:	326
Tamanho: 	377,1 KB
ID:      	63942

    Obrigado pessoal!






Tópicos Similares

  1. Mikrotik aceitando apenas clientes com sinal bom
    Por peritinaicos no fórum Redes
    Respostas: 17
    Último Post: 14-04-2016, 20:57
  2. Respostas: 13
    Último Post: 14-05-2011, 08:24
  3. lentidão com sinal bom em aprouter!
    Por cls7007 no fórum Redes
    Respostas: 15
    Último Post: 25-10-2009, 14:37
  4. Mikrotik com sinal fraco durante a noite
    Por ShadowRed no fórum Redes
    Respostas: 2
    Último Post: 07-11-2008, 08:29
  5. Mikrotik com sinal otimo, derrepente...
    Por rogeriodj no fórum Redes
    Respostas: 0
    Último Post: 24-08-2007, 20:21

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L