AP Ubiquiti x Cliente Mikrotik = Sofrimento de mais de 1 ano

Prezados amigos,

Como não achei nada relacionado ao que estou passando aqui, resolvi abrir esse novo tópico para que alguém possa me ajudar a solucionar ou pelo menos esclarecer o que acontece:

A cerca de 1 ano passo por um problema de conexão entre AP UBNT (Rocket com Basestation) e Clientes Mikrotik (SXT Lite 5). Tudo começa sem aviso prévio e sem alteração no Cenário. Está tudo normal como mostra a Imagem em anexo, de repente o CCQ do AP começa a cair vertiginosamente (Chega a 30) levando os dos clientes junto, o tráfego para, e os clientes são desconectados. Em questão de menos de 1 minuto voltam a se conectar e tudo se normaliza. Já penei com varias configurações diferentes, realinhar cliente por cliente e trocar o AP por um novo. A única coisa que resolveu em definitivo foi dividir os Clientes por Fabricante. Colocar Clientes UBNT em AP UBNT e Clientes MK em AP MK. Queria uma solução mais barata pois ainda tenho torres UBNT com fabricantes misturados (UBNT e MK) onde não compensa de forma alguma eu colocar 2 interfaces 5.8 para atender 15 clientes.

Algumas considerações:

Pior Sinal da Torre usada como controle é -72
Acontece com todas os APs UBNT que tem 1 ou mais SXTs junto com as Nanos x Grids
Acontece de forma esporádica em horários e intervalos distintos e as vezes até dias de intervalo.
Não uso protocolo TDMA proprietário nos APs
O log do AP UBNT fala que o cliente está sendo desconectado por sinal ruim.
Problema de interferência já foi eliminado, pois estou sozinho e acontece em todas as torres com equipamento misto.
Só uso UBNT E MK.
Dividindo os Fabricantes o problema desaparece (Não é a solução adequada para mim no momento).

Se alguém já passou pelo problema e conseguiu uma configuração adequada para funcionamento, favor compartilhar. Ajudará uma alma desesperada a dormir em paz.
Anexo 58573

É vc ja usou tipo em vez de ubnt no ap uma ap mikrotik tipo uma basestation com a rb912 pra ver como se comporta pois o mikrotik em redes mista se sai melhor.

Caro wala,

Obrigado pelo interesse. Estou pensando em fazer isso, porem queria descobrir o porque do problema já que uso as 2 marcas dominantes do mercado e não acredito que seja incompatibilidade a nível de protocolo. Devo estar errando alguma configuração no AP ou cliente SXT, já que no cliente ubnt não tem muito o que configurar. Mesmo eu trocando e resolvendo vou continuar com aquela pedrinha no sapato. Sou daqueles que gosta de saber o porque, por isso pedi ajuda ao grande conhecimento coletivo do Under...

Um grande abraço !

Pablo você mesmo já deu a solução para a sua paz e está coberto de razão, mas... a paz vem acompanhando de um preço que você terá de pagar.

Ap Mikrotik com CPE Mikrotik e NV2 ativado.
Ap Ubiquiti com CPE Ubiquiti e AIRMAX ativado.

Eu contei no seu AP 29 estações conectadas e o nivel de sinal não está ruim. Faça deste jeito mesmo. Pega um dia, faz um multirão e arruma isso ai. Não adianta.

Até por que, usando MISTO você perde o que ambas as marcas possuem de melhor. Os protocolos proprietários.

Quais a configurações que vc coloca nas sxt? Coloca aqui que assim o pessoal pode te ajudar melhor.

Wala, as duas únicas telas da wireless que altero estão abaixo: Estou testando essas configurações agora. Com o chain1 TX e RX ativado o problema continua. Com banda A/N Largura 20/40 e Protocolo Any o problema agrava. Acrescento as configurações do AP tb. Versão do firm 5.5.10 (Ultima)
Anexo 58578 Anexo 58579Anexo 58580Anexo 58581

Zucchi,

Obrigado pela atenção. Realmente o aconselhado é isso mestre. Porem não estou me conformando. A maioria das minhas torres estão separadas. As que ainda não separei é porque não compensa. Vejo muita gente trabalhando com equipamentos inferiores numa mistureba danada sem passar pelo problema. É inconformismo mesmo. Mesmo se eu trocar tudo não serei feliz por não ter descoberto a questão... Hehehe

Um abraço !

Mas tem muita coisa errada aí.
130M é datarate de MCS15, cuja sensibilidade no datasheet ( http://dl.ubnt.com/rocketM5_DS.pdf ) é -75dBm. Aplicando uma margem de 20dBm sobre a sensibilidade isso diz que pra usar MCS15 nos clientes você PRECISA sinal -55dBm ou maior.

-69 é uma margem de apenas 6dB com relação a sensibilidade de -75, inviável em teoria ter SEQUER 50% de CCQ.

Experimenta os clientes com SXT transmitirem apenas em MCS10 (39M de datarate, dá pra 20Mbps de throughput na prática), a sensibilidade do Rocket (Recebendo) em MCS10 é -90, que dá uma margem bem segura de 20dB com relação a maioria dos sinais em -70 a -68dBm.

E experimenta transmitir nos Rocket (Max TX Rate) em MCS13, datarate de 104M, deve dar na prática um thghoutput de uns 60Mbps, acho que deve ser suficiente pra você.

Datarate alto precisa sinal alto, -69 é absurdamente baixo pra algo acima de MCS13, é só ver as sensibilidades no datasheet e aplicar um signal margin decente de 20dB (Acima de uns 10Km parte pra 25dB de margem).

E isso não é culpa de UBNT+MK ou UBNT+Arruba, ou MK+Cisco, esses equiptos estão é fazendo milagres com esses sinais tão baixos pros datarates em uso, devia é ficar o tempo todo com CCQ baixo.

Grande Rubens... Começou a me dar uma luz. Explica para uma pessoa ignorante: O que devo alterar no AP e o que devo alterar nas SXTs. Por isso não desisti da aplicação. Por saber que não seria culpa de uma marca ou de outra e sim da pessoa desprovida de conhecimento que vos fala.

Um grande Abraço !

Nos Rocket: MAX TX Rate em MCS13, e desmarca a caixa automatic do lado (Senão vai ficar esse monte de TX's diferentes)

Nos SXT: Modo N only, e na aba MCS HT marca APENAS MCS10 (Se marcar todos vai ter esse monte de RX's diferentes)

O resumo é isso.

Tem como otimizar mais um pouco com ack-timeout nos SXT, mas por enquanto teste só reduzir os datarates pra "aproveitar" melhor esses sinais baixos.

Rubens. Minha aba datarates da SXT está defaut, não permitindo eu mudar as configurações no MCSHT. O que devo deixar marcado no datarates já que vou ter de colocar configure ?

Muito grato pela ajuda !
Anexo 58582

@pablozac, a distância máxima das tuas estações está a no máximo 2km mesmo? (como informa a maior distancia medida pelo ACK do teu AP)

Se sim, qual a razão de usar 27dB de potencia no Rocket?
Eu tenho 2 rockets aqui, um que tem clientes a 7km ou mais, que dai boto uma potenciazinha maior, e outro com clientes a menos de 2km, no qual coloquei potencia de 10dB e mesmo assim to achando alto. @rubem, por que motivo você pratica 20dB de margem para a sensibilidade máxima que vc quer atingir? É para evitar variações decorrentes de ambiente? Pois mesmo um temporal infernal, a distancia de 2km, não vai atenuar o sinal nem em 5dB (pelo menos aqui não atenua). Mas de repente to falhando em perceber algo.

Acho que até uns 3 km em linha reta inquiery. A Basestation que está conectada é de 16 DB.

Grato pelo interesse !

Alias @pablozac, qual o sinal mais baixo que você tem, do lado das estações? E que potência você usa em média nos radios das estações?

Tenta diminuir a potência pra algo em torno de 10-12dBm, e diminuir a potência nas estações também, mesmo que chegue perto do -70 o sinal que o AP vai pegar das estações. O @rubem não vai gostar dessa sugestão, mas faz só pra teste :)

Nas estações, recebendo um sinal por volta dos -70, ainda vai poder estabilizar em MCS alto.

Sinal mais baixo é -72 e a potencia de tx dos clientes regulo para ficar no máximo -55 na torre.

Citação:

---

Postado originalmente por pablozac

Rubens. Minha aba datarates da SXT está defaut, não permitindo eu mudar as configurações no MCSHT. O que devo deixar marcado no datarates já que vou ter de colocar configure ?

Muito grato pela ajuda !

---

Na aba datarates tanto faz o que marcar se colocar no modo "Only N". Pode colocar em "Configured" e marcar o que quiser.
O que importa é na aba HT MCS, lá que você marca apenas MCS10 (O default é tudo marcado, ou seja, mudança automatica conforme o sinal, mas mudança automatica sempre falha)

Citação:

---

Postado originalmente por inquiery

@rubem, por que motivo você pratica 20dB de margem para a sensibilidade máxima que vc quer atingir? É para evitar variações decorrentes de ambiente? Pois mesmo um temporal infernal, a distancia de 2km, não vai atenuar o sinal nem em 5dB (pelo menos aqui não atenua). Mas de repente to falhando em perceber algo.

---

Sobre o link margin de 20dB que recomendo (Pra PTMP de distancia pequena, tipo menos de 10Km), infelizmente tem pouco conteúdo na web. De maneira geral se trata o mínimo necessario pra ter qualidade como 15dB de margem:
http://en.wikipedia.org/wiki/Link_margin

Mas com 10dB de margem já é raro a conexão cair, por isso tem gente com duvida se 10, 15 ou 20dB é o "mínimo":
https://community.ubnt.com/t5/Wirele...dB/td-p/464171

Se não me engano o Airlink da UBNT dá como OK somente 20dB de margem em PTMP:
http://airlink.ubnt.com/

É a mesma margem que esse calculador dá em distancias maiores:
http://mayo.nuvisions.net/ubnt_link/

Exemplo, em 3Km margem de 13 ou 14dBm, mas em distancia maior a margem em verde (Ou seja, ok) é 19 ou 20dBm (Abaixo disso fica em vermelho, indicando sinal abaixo do recomendado)
Anexo 58583

E eu já ví paper da UBNT recomendando link margin de no mínimo 20dB, tenho certeza que ví isso, mas não encontro mais.

Se achar uma tabela com valores de SNR mínimo já é raro, imagina pra link margin! SNR a maioria concorda que deve ser 20dB ou mais, então isso só suporta ainda mais que a margem (Com relação ao ruído ou com relação a sensibilidade) deve ser a mesma. Toda vez que ví SNR ou link margin menor que 20dB o throughput não era grande (Nem perto do máximo), por mais que o CCQ fosse 95 ou 99%.


Eu sugiro manter o sinal entre 20dB acima da sensibildiade do datarate escolhido (Azar de quem usa o modo auto, com datarates diferentes, merece sofrer), e o isolamento entre polarizações que a antena tem. Antena Airmax grande (17-20dBi) tem isolamento entre polarizações de 28dB, então sugiro sinal dos clientes chegando entre 20 e 28dB acima da sensibilidade, para que o link margin mínimo de 20dB seja respeitado, e para que um sinal 28dB acima da sensibilidade não "vaze" pra outra polarização.
(Se usar SISO isso não importa)

Uma coisa é fazer um PTP, num PTP com margem de 18dBm em area sem poluição você consegue quase todo o throughput possível, com canal de 40MHz e margem de 25dB (Sinal -50, quando a sensibilidade é -75) sempre consegui toda a banda prometida (throughput maximo). Mas em PTMP você tem duzias de CPE's mandando dados, sinal alto demais chega na outra polarização ou chega por reflexo (Vem em linha reta em 5ns, mas reflete lá longe e chega 10ns atraso já que fez caminho mais longo), mas sinal baixo demais fica distorcido. Um MCS14 ou 15 aqui, como fica ilegível com apenas 21dB de margem:
Anexo 58584
Na esquerda os pontos (simbolos) são bem nítidos, tem 64, então é um 64QAM. Na direita não dá pra ler direito, digo, não dá pra separar bem todos os simbolos pra definir de qual quadrante é cada um (São 64 quadrantes). Isso resulta em throughput baixo, perda de pacotes, o que derruba o CCQ também.

Também dá pra colocar assim:
Anexo 58585
Nesse caso há ruído, por isso só há legibilidade de 30dB pra cima. Ambiente ruidoso tem esse problema. Esse EVM é um percentual de erros, 30% de erro com sinal baixo, significa que 1 em cada 3 pacotes precisa reenvio, isso tira tempo que poderia estar sendo usado por outro cliente.

Os firmwares recentes pra Rocket (Só o beta pra AC?) tem o Constelation Diagram, neles dá pra ver bem intuitivamente que sinal baixo resulta em distorção. Eles tratam como CINR:
https://www.ubnt.com/broadband/software/
(Terceira imagem)

Nos Unifi é o RSSI, é um percentual baseado no SNR mínimo requerido, mas de maneira geral o mínimo pra manter conexão (Unifi não é focado em altos throughputs, mas sim em conexão mobile e cia, que querem estabilidade sem cobrar trafego alto) é de mais de 10dB acima da sensibilidade.

SNR não foi padronizado, RSSI menos ainda, CINR também não, e link margin... pff... esse está mais longe ainda de padronização ou de concenso, mas só ví estabilidade total onde se usar margem de 20dB. Pode ser exagero? Pode, mas mal não faz, um MCS12 tem throughput de uns 50Mbps, quem precisa de mais banda que isso num PTMP? Pra aumentar a margem é só reduzir os datarates, especialmente o de transmissão do cliente (Vender upload de 1M mas usar cliente>torre um datarate tipo 65M exige sinal alto, que raramente o cliente terá, se usar datarate menor tipo 20-30M o throughput do cliente ainda estará garantido mas poderá usar potencia menor no cliente, pra evitar problema em etapa de RF (Perda de potencia, por exemplo), e pra evitar poluição no espectro (Potencia alta gera, quando tem centenas de CPE's em potencia alta, um nível de ruído alto tipo -85, o espectro está f*dido no brasil devido aos usos bestas tipo canal de 40MHz em PTMP pra planinho mixuruca de 1M/256K, e pelo uso de potencias absurdas tipo 50dBm EIRP (Como se com 27dBm EIRP não chegasse em digamos 4Km tranquilamente).

Alias... estão usando 5,6GHz então estão usando limite de 27dBm EIRP né? E DFS também? Essa faixa PRECISA potencia menor e DFS, azar se a faixa dos 5,7 a 5,8GHz já está poluída, só lá que pode ter potencia alta, são os ossos do oficio aprender a trabalhar com apenas 27dBm EIRP caso queira usar canal abaixo de 5,7GHz (Ninguém é obrigado a trabalhar como wifi, mas quem quer trabalhar tem que seguir a legislação, potencia baixa em 5,3-5,6GHz, e NÃO usar 5,1-5,2GHz outdoor. Lei é lei).

Caro rubem, não sei se vc é artista, mais um fã já está garantido... Amanhã faço as alterações sugeridas e posto o resultado.

Muito obrigado pela aula!

A solucção mais facil mno meu modo de ver é SUSTITUIR os AP UBNT por Mikrotik e por a trabalhar todos em modo NV2. Assim de simples.

Com clientes em -72dBm não vai funcionar NUNCA. Vai ter sempre problemas (sinal muito baixo para imunidade as interferenças ). O sinal ideal é -60dBm para acima.

Citação:

---

Postado originalmente por pablozac

Prezados amigos,

Como não achei nada relacionado ao que estou passando aqui, resolvi abrir esse novo tópico para que alguém possa me ajudar a solucionar ou pelo menos esclarecer o que acontece:

A cerca de 1 ano passo por um problema de conexão entre AP UBNT (Rocket com Basestation) e Clientes Mikrotik (SXT Lite 5). Tudo começa sem aviso prévio e sem alteração no Cenário. Está tudo normal como mostra a Imagem em anexo, de repente o CCQ do AP começa a cair vertiginosamente (Chega a 30) levando os dos clientes junto, o tráfego para, e os clientes são desconectados. Em questão de menos de 1 minuto voltam a se conectar e tudo se normaliza. Já penei com varias configurações diferentes, realinhar cliente por cliente e trocar o AP por um novo. A única coisa que resolveu em definitivo foi dividir os Clientes por Fabricante. Colocar Clientes UBNT em AP UBNT e Clientes MK em AP MK. Queria uma solução mais barata pois ainda tenho torres UBNT com fabricantes misturados (UBNT e MK) onde não compensa de forma alguma eu colocar 2 interfaces 5.8 para atender 15 clientes.

Algumas considerações:

Pior Sinal da Torre usada como controle é -72
Acontece com todas os APs UBNT que tem 1 ou mais SXTs junto com as Nanos x Grids
Acontece de forma esporádica em horários e intervalos distintos e as vezes até dias de intervalo.
Não uso protocolo TDMA proprietário nos APs
O log do AP UBNT fala que o cliente está sendo desconectado por sinal ruim.
Problema de interferência já foi eliminado, pois estou sozinho e acontece em todas as torres com equipamento misto.
Só uso UBNT E MK.
Dividindo os Fabricantes o problema desaparece (Não é a solução adequada para mim no momento).

Se alguém já passou pelo problema e conseguiu uma configuração adequada para funcionamento, favor compartilhar. Ajudará uma alma desesperada a dormir em paz.
Anexo 58573

---

Caro rubem, efetuei as configurações e houve um probleminha. Tenho Airgrids que não trabalham em mimo nesse AP. Quando passei para MCS13 consequentemente elas pararam. Tem alguma outra alternativa de MCS que eu possa usar já que a rocket não permite a escolha de mais de 1 ?

Agradecido !

Acho que vc pode deixa no automatico mesmo ate o 13 as outras irao conectar o problema de deixar fixo e algum ap ter problema e desconectar totalmente, as vezes ele acaba modulando em mcs 0 e ai vc pode tentar conseguir acessalo e mudar de celula.

Isso, MAX TX em MCS13, mas automatic marcado então.

Mas o principal é baixar o datarate Nos clientes. Coloca os Airgrid em MCS3 (Equivale a um MCS10, só muda o numero de chains), e o que for MIMO coloca em MCS10.

Valeu amigos. Procedendo com as mudanças. Devo alterar as grids e Nanos ? Deixo no auto tb no cliente ubnt? Na sxt deixo marcado MCS 10 No HT supported e Basic como na imagem?
Anexo 58604

Na configuração de MCS13 e auto marcado na rocket, as SXTs ficaram com RX de 6Mbps. Todas elas. Desmarca o auto as grids não conectam.

O RX é meio irrelevante, 6M é o menor datarate em 802.11A então está caindo nisso (O modo no SXT não está em N-only?), é normal dar isso quando não tem tráfego (Hora que der trafego deve ir pra MCS10).

"O que importa" é não ter RX grande tipo 65M ou 130M, poderia até usar MCS0 nos Airgrid e MCS8 nos SXT que não faria tanta diferença, esses datarates tem throughput de 4 e 8Mbps respectivamente, e você deve vender upload de no máximo 1Mbps, então ainda tem banda sobrando pro upload.

@rubem, aproveitando seu gancho e sua explicação, tenho um PTP de 600 metros com um par de SXT AC

Frequência usada: 5290 (a única livre aqui)
Canal: 20mhz
Wireless Protocol: NV2

Na aba DATA RATES eu coloquei em "configured" e habilitei em SUPPORTED RATES A/G marquei a opção 6mbps
Na aba HT, marquei todos os Chains e em AMPDU Priorities apenas o 0 (zero).

Na aba HT MCS em HT Supported MCS estão marcados os MCS de 8 até 23

Em HT Basic MCS marquei apenas o MCS 8

Potencia: 8dmb
Nivel de sinal: -52/-53
SNR: 51db

Neste PTP eu preciso REALMENTE do MÁXIMO de banda que puder e mais um pouquinho. Esta configuração é a ideal ou você poderia me sugerir algo ?

Caro Rubem, agradeço imensamente pelas palavras coerentes e paciência.

Respondendo a suas perguntas, quando falo RX 6M, é o RX na antena cliente equivalente ao TX no AP. As SXTs estão todas em N-only. Esperei alguns cliente trafegarem e atingirem o máximo do plano e o 6MB ficou inabalável. O que eu fiz para teste é deixar o AP em MCS5 sem deixar o auto marcado. Também alterei as configurações de todos os clientes Nano e Airgrid para respectivamente MCS10 e MCS3 como você sugeriu. Tirem um print de como ficou os cliente na torre e as configurações que ficaram o AP e os clientes para que você analise e faça suas valiosas considerações apontando o que pode ser melhorado. Pois vc disse para que eu trabalhasse em MCS13 Auto no AP (Sensibilidade -90) e eu deixei MCS5 sem auto (Sensibilidade -83) por conta do RX de 6 MB dos clientes. Queria tentar corrigir isso. Segue imagens (Cliente A = SXT e AB = NANO/AIRGRID):
Anexo 58608Anexo 58609Anexo 58610Anexo 58611Anexo 58612Anexo 58613Anexo 58614Anexo 58615

Citação:

---

Postado originalmente por Zucchi

@rubem, aproveitando seu gancho e sua explicação, tenho um PTP de 600 metros com um par de SXT AC

Frequência usada: 5290 (a única livre aqui)
Canal: 20mhz
Wireless Protocol: NV2

Na aba DATA RATES eu coloquei em "configured" e habilitei em SUPPORTED RATES A/G marquei a opção 6mbps
Na aba HT, marquei todos os Chains e em AMPDU Priorities apenas o 0 (zero).

Na aba HT MCS em HT Supported MCS estão marcados os MCS de 8 até 23

Em HT Basic MCS marquei apenas o MCS 8

Potencia: 8dmb
Nivel de sinal: -52/-53
SNR: 51db

Neste PTP eu preciso REALMENTE do MÁXIMO de banda que puder e mais um pouquinho. Esta configuração é a ideal ou você poderia me sugerir algo ?

---

Eu marcaria não 6M mas sim 54M na aba datarates.

Quanto a marcas os HT MCS até 23, não faz nenhum efeito marcar 16 a 23, já que eles são rates de sistema com 3 chains.
(0 a 7 é de 1 chain, 8 a 15 de 2 chains, e 16 a 23 de 3 chains)

Então se tem antena de dupla polarização marque apenas 8 a 15. Mas se quer velocidade maxima marque apenas MCS14 e 15 mesmo. -52 é sinal suficiente pra MCS14.
(E na parte Basic MCS marque 14 e 15 também)

Pra usar MCS15 tente conseguir sinal -50, teria que subir a potencia um pouco, 10dBm é 2dBm acima dos 8 atuais, então deve subir o sinal de -52 pra -50dBm.

Eu particularmente marco somente 1 (um) HT MCS, só o que eu quero, trabalhando com sinal 20-25dB acima da sensibilidade se um dia algo aparecer na frente e o sinal cair, digamos cair 10dBm, ainda conseguirei acessar pra marcar um datarate mais baixo pra quebrar o galho enquanto não subo a antena. Esse negócio de marcar datarate baixo "por precaução" não tem utilidade em PTP, se o trafego normal é digamos 60Mbps, marcar um MCS8 vai limitar ele a uns 6Mbps, vai gerar uma rede lixo igual ter um MCS15 com sinal apenas 10dB acima da sensibilidade (Ou seja, se o sinal cair por alguma coisa na frente sua rede VAI ficar ruim, marcando mais datarates ou não).


(Porque as SXT AC mostram 3 chains se na verdade só tem 2? Porque o chipset é comum as RB's 91x e 92x com 3 chains, eles preferiram deixar o RouterOS reconhecer os 3 chains dos SXT (Que não tem 3 etapas de RF) do que correr o risco de não reconhecer um dos 3 chains numa RB922 (Das AC que tem 3 etapas de RF). Então marque apenas os chains 0 e 1, porque SXT não tem 3 antenas)

Testar marcar todos os AMPDU, em distancia pequena deve fazer diferença.
E testa ack-timeout fixo e levemente maior nos 2 lados, pra 600m eu diria pra testar 30us.

Acabei de ver aqui. Ficou perfeito durante uma hr e meia e voltou a desconectar todos. A diferença é que o CCQ das SXTs não saiu de 100% e os das UBNT desandaram todos...

Citação:

---

Postado originalmente por pablozac

Caro Rubem, agradeço imensamente pelas palavras coerentes e paciência.

Respondendo a suas perguntas, quando falo RX 6M, é o RX na antena cliente equivalente ao TX no AP. As SXTs estão todas em N-only. Esperei alguns cliente trafegarem e atingirem o máximo do plano e o 6MB ficou inabalável. O que eu fiz para teste é deixar o AP em MCS5 sem deixar o auto marcado. Também alterei as configurações de todos os clientes Nano e Airgrid para respectivamente MCS10 e MCS3 como você sugeriu. Tirem um print de como ficou os cliente na torre e as configurações que ficaram o AP e os clientes para que você analise e faça suas valiosas considerações apontando o que pode ser melhorado. Pois vc disse para que eu trabalhasse em MCS13 Auto no AP (Sensibilidade -90) e eu deixei MCS5 sem auto (Sensibilidade -83) por conta do RX de 6 MB dos clientes. Queria tentar corrigir isso. Segue imagens (Cliente A = SXT e AB = NANO/AIRGRID):
Anexo 58608Anexo 58609Anexo 58610Anexo 58611Anexo 58612Anexo 58613Anexo 58614Anexo 58615

---

É muito dado pra ver, calma aí.

Bom, coloque todos os UBNT não como 20/40MHz, mas sim apenas 20MHz.
Não tem como colocar o modo de operação em somente N ?? (Está em A/N, por isso tem RX de 48 e 54M, isso são clientes conectados em 802.11A)

Quanto ao Rocket M5, ele não está ligado numa antena de dupla polarização? Se sim, coloque em MCS13 mas marque a caixa "automatic" do lado. Se está com antena de polarização simples pode ser esse MCS5 atual.

Nos Airgrid marque desmarque a caixa "auto adjust to EIRP limit", com ela ativa o Airgrid vai sempre transmitir na potencia maxima já que o ganho da antena está em branco (Aí ele entende que tem antena de 3dBi, e tenta chegar sempre no limite EIRP de 27dBm pra essa frequencia).

Alias, em todos os UBNT desmarque o "auto adjust to EIRP limit", senão todos vão gritar na potencia maxima.

Teste marcar o datarate module nos UBNT em Alternative.

Nos SXT também marque canal apenas de 20MHz, e não 20/40 como está hoje. Neles tem que marcar Basic rates A/G igual os suported rates, eu marco apenas 54M (Como é alto ele nunca usa). Ative o DFS mode nos SXT, a faixa dos 5,3 a 5,6GHz precisa DFS por lei.
(E 5,1 a 5,2GHz nem devia ter usado por provedor)

Agora essa parte de ficar 90% com todos com CCQ em 100%, e do nada cair, pode ser excesso de cliente nos Rockets, alguém acessa com CCQ baixo, gera reenvio de pacotes demais, e isso zoneia todo o resto da rede.
Pra evitar isso dá pra testar 2 coisa:
1 - Aumentar o ack-timeout dos clientes (Não nos Rocket como AP, esse deixa automatico) pra um valor acima do real, se no modo auto está em 30uS marque 35, se em modo auto está em 42 marque manualmente 48us, sempre desmarcando a caixa automatic do lado
2 - Na mesma aba Advanced dos UBNT ativa o RTS Threshold e marque um valor baixo tipo 512. Isso vai obrigar o cliente a "perguntar" antes de enviar (Request To Send) se o pacote for maior que 512 bytes. Pacote menor ele vai enviar sem perguntar. O fragmentation threeshold logo abaixo pode testar, mas um marcaria 1550 ou mais pra testar, quando testei valores menores coisa tipo MSN perdia conexão toda hora (Não sei se os messengers hoje teriam esse problema).

O ack-timeout maior que o real eu usaria de qualquer forma. O RTS threshold só teria que testar pra definir se há melhora na SUA rede com ele e com quais valores (512, 1200, 1400, 2000...), e o Frag. threshold duvido que faça muito efeito positivo com tanto cliente conectado.

Eu sempre usei MK como AP, adoooooro o cartão R52HN pra isso, marco HT MCS em MCS3 e MCS12, desse modo clientes single-polarization recebem em MCS3, e os com CPE de dupla polarização MCS12. UBNT infezlimente te obriga a usar OU um range enorme de datarates ou apenas 1 (um) datarate, por isso digo que é firmware pra senhorinha, muito simplificado.

Muito Obrigado Rubem

Na Rocket
não está dando a possibilidade de alterar A/N para N. Coloquei MCS13 as SXTs estão conectando só a 6MB de download
Experimentei marcar Basic rates A/G igual os suported rates em 2 sxt que após o procedimento não voltaram a se conectar. Lembrando que estão setadas em MCS10.
Preciso conseguir que as SXTs se conectem acima do througput de download de 6 MB com a Rocket em MCS13 auto. Se eu coloco MCS13 sem auto elas conectam a 52Mb porem as Grids não se conectam. Se eu Marco o auto as grids se conectam e as SXTs ficam com 6Mb. Fujo de um e caio no outro. Tenho 50 clientes simultâneos nessa rocket.

O ruim da ubnt e que ela e muito travado nas configurações, ve se a possibilidade de vc deixar uma celula com rb912 e comparar o desempenho, e rb tem mais ajustes finos

Bem vindo ao maldito mundo do idiota modo A/N, que mistura 802.11A, uma velharia péssima de 1999, com 802.11N, de 2009. A UBNT te obriga a usar 2 modos de eras tão diferentes, mania de quem quer simplificar, mas acaba atrapalhando.

O pouco que dá pra fazer é na aba advanced desmarcar a opção Multicast Data, ela separa os clientes e manda pacotes pros registrados em datarates maiores, em teoria o melhor desempenho é com isso habilitado, mas... misturando marcas e com esses noobs modos automaticos que a UBNT usa as vezes o desempenho muda ao contrário da teoria.

Os SXT mesmo em modo N-only conectam em 6M, que é um datarate de 802.11A? É lindo isso. E acredite, é culpa de UBNT. Sempre faço mais PTP's, quando coloco UBNT e MK acontece isso de variar por datarates de modo A (6, 12, 18, 24, 36, 48 e 54M), enquanto MK+MK, ou MK+Intelbras, ou MK+Engenius não cria isso, se seto somente N eles usam somente N.

Realmente não tenho solução pra esse caso, se com o Rocket fixo em MCS5 o RX nos SXT ainda é 6M (De 802.11A) aí já foge da lógica e da teoria que conheço, e até onde eu tenha testado isso é culpa dessa opção travada nos UBNT em modo A/N.
(Eu já ví essa opção liberada, já coloquei em N, mas não lembro se era versão de firmware ou alguma linha específica tipo unifi e cia)

Caro Rubem, foi de grande valia seu conhecimento a respeito do assunto. Desisti de fazer funcionar por ter esbarrado em 2 obstáculos. O primeiro você já disse acima. Ubnt como AP é uma negação devido ao firmware travado. O segundo foi a impaciência dos clientes que com razão estão xingando minha mãe e outros entes queridos. Das outras vezes que passei por este problema, nem fui tão longe na tentativa de solução. Simplesmente acrescentei um AP MK e migrei as SXTs pra ele. Simples assim. Agora abusando da sua boa vontade. Dessa vez quero fazer diferente e romper as amarras da escravidão da UBNT, já que tenho mais de 50% de clientes sendo atendidos pela marca. Lembrando que esse POP tem 50 clientes simultâneos hoje, e sempre cresce um aqui e outro ali, o que você faria no meu lugar?

1 - Acrescentaria um MK (Estou pensando em SXT SA) e viraria os cliente para ele ou
2 - Substituiria a Rocket pelo MK e tentaria solucionar de maneira inversa: AP MK e Clientes SXT X NANO X GRID

Lembrando que a primeira opção e solução certa e a segunda duvidosa...

PS. Já voltei as configurações do AP e clientes todas para o que estava, e na minha opinião, depois das configurações que você me passou aplicadas, não eram os clientes SXT que estavam atrapalhando e sim os UBNT.

Grande Abraço Rubem !!!

Eu só uso AP se for MK, então sou suspeito pra falar.

Com MK como AP coloquei tudo que puder imaginar em cliente, Krazer, APRouter, Abocom, GTS, Smartlan, Oiwtech, Elsys, Engenius, TPlink, Intelbras, Ubnt, isso falando em 5GHz N (De 802.11a lembro de Edimax, Kozumi, Firemax e Eternatec). Dá problema? Dá, por exemplo quem tinha APRouter, o desempenho era ruim, mas o desempenho só desse cliente era meia-boca, não afetava o resto, se manter o TX rate dos clientes baixos, e o ack-time deles meio alto eles não vão tomar muito tempo da torre, um cliente ruim não afetará muito a qualidade do resto. Mas SXT, Airgrid e NS não tem nada de ruim pra trabalharem juntos.

Com MK como AP, e UBNT nos clientes, ocorreria isso dos UBNT transmitirem pro MK em 6M, mas... isso vai afetar apenas o upload, e datarate de 6M é suficiente pra mais de 3Mbps de trafego real (Mas na prática hora que tiver tráfego deve ir pro Max TX Rate setado, deve ficar em 6M só quando não tem trafego. Com MK como AP é isso que ocorre).

MK pra mim nasceu pra ser AP em provedor, é tudo perfeito pra esse uso. Outros roteadores tem isso de somente um TX rate (Ou 1 ou todos, você não tem muita escolha) fora outras bobeirinhas.

Não lembro de nenhum problema grave usando MK como AP e UBNT nos clientes.
Alias, a UBNT demorou pra lançar os Rocket, antes dos Rocket ela só tinha equipto pra cliente, tipo Bullet e NS. Eu conheci UBNT como equipto pra cliente e ainda não consigo aceitar bem UBNT como AP (Em PTP vai, mas só graças a Airmax, idem pra iPoll, esses modos TDMA que dão algum motivo pra comprar equipto tão caro).

Rubem meu amigo, não fuja há responsabilidade de mentor... Hehehe... Se fosse contigo o que faria? Acrescentaria um novo Ap mikrotik ou substituiria o atual por mk. Lembrando que já estamos com 50 clientes nesse ap...

Eu acrescentaria se tivesse espaço, porque em teoria o numero de clientes sempre aumenta e sempre precisamos mais AP's.

Muito obrigado rubem. Vou fazer isso...

Citação:

---

Postado originalmente por rubem

Eu marcaria não 6M mas sim 54M na aba datarates.

Quanto a marcas os HT MCS até 23, não faz nenhum efeito marcar 16 a 23, já que eles são rates de sistema com 3 chains.
(0 a 7 é de 1 chain, 8 a 15 de 2 chains, e 16 a 23 de 3 chains)

Então se tem antena de dupla polarização marque apenas 8 a 15. Mas se quer velocidade maxima marque apenas MCS14 e 15 mesmo. -52 é sinal suficiente pra MCS14.
(E na parte Basic MCS marque 14 e 15 também)

Pra usar MCS15 tente conseguir sinal -50, teria que subir a potencia um pouco, 10dBm é 2dBm acima dos 8 atuais, então deve subir o sinal de -52 pra -50dBm.

Eu particularmente marco somente 1 (um) HT MCS, só o que eu quero, trabalhando com sinal 20-25dB acima da sensibilidade se um dia algo aparecer na frente e o sinal cair, digamos cair 10dBm, ainda conseguirei acessar pra marcar um datarate mais baixo pra quebrar o galho enquanto não subo a antena. Esse negócio de marcar datarate baixo "por precaução" não tem utilidade em PTP, se o trafego normal é digamos 60Mbps, marcar um MCS8 vai limitar ele a uns 6Mbps, vai gerar uma rede lixo igual ter um MCS15 com sinal apenas 10dB acima da sensibilidade (Ou seja, se o sinal cair por alguma coisa na frente sua rede VAI ficar ruim, marcando mais datarates ou não).


(Porque as SXT AC mostram 3 chains se na verdade só tem 2? Porque o chipset é comum as RB's 91x e 92x com 3 chains, eles preferiram deixar o RouterOS reconhecer os 3 chains dos SXT (Que não tem 3 etapas de RF) do que correr o risco de não reconhecer um dos 3 chains numa RB922 (Das AC que tem 3 etapas de RF). Então marque apenas os chains 0 e 1, porque SXT não tem 3 antenas)

Testar marcar todos os AMPDU, em distancia pequena deve fazer diferença.
E testa ack-timeout fixo e levemente maior nos 2 lados, pra 600m eu diria pra testar 30us.

---

Rubem, primeiramente algo além do meu muito obrigado !!!

É o seguinte, fiz as alterações que você cita e entendi a explicação sobre os MCS.

Com potencia em 10dbm o nível de sinal ficou em -51/-51, logo, coloquei 1dbm a mais e fez com que o enlace fosse fechado a -49/-50 tudo bem?

Lá na aba DATA RATES em Supported Data Rates A/G, só deixei marcado o 54mbps.

Na aba HT, deixei marcado todos os AMPDU Priorities, alias, para que propriamente serve esta função?

Na aba HT MCS em:

HT Supported MCS deixei marcado 14 e 15 (sim, você disse para deixar apenas um deles mas por questão psicologica deixei os dois assim por 24 horas para ver como o enlace se comportaria).

HT Basic MCS deixei marcado também o 14 e o 15. Faz-se necessário?

Anexo 58625

Quanto ao ACK, onde fica esta config?

Citação:

---

Postado originalmente por pablozac

1 - Acrescentaria um MK (Estou pensando em SXT SA) e viraria os cliente para ele ou
2 - Substituiria a Rocket pelo MK e tentaria solucionar de maneira inversa: AP MK e Clientes SXT X NANO X GRID

---

Pablo, seus planos são de qts MB?

Sei que a pergunta foi para o Rubem mas vou dar pitaco rs.

Cambium. ePMP com GPS como AP e ePMP 1000 nos clientes. Até 120 clientes por setor com sincronização por GPS.
Nunca mais você vai ter sofrimento na vida e pode oferecer planos BEM maiores.

Sim é mais caro. Mas se vc está crescendo, se sua celula está crescendo... profissionalize-se.

Caro @Zucchi,

Muito obrigado pela dica, quando eu crescer talvez consiga padronizar dessa forma. Hehehe. Talvez o investimento correto daqui pra frente seja a Fibra...

Amigo @rubem,

Fiz o seguinte, mandei o funcionário ao POP acrescentar uma SXT-SA para dividir os clientes, porém antes disso, já que eles já estão querendo me esfolar vivo, uma horinha a mais ou a menos não fará diferença. Queria deixar todos na SA primeiro para ver como o MK se comportaria nessa situação como AP. Como devo configura-lo para substituir a Rocket apenas para testes. Lembrando que estão misturados SXT e Nano 2X2 juntamente com Grid 1x1.

A meu ver o maior problema de usar misturado é a perda do TDMA, que pra PTMP vai fazer o CCQ cair bastante.
Se pudesse conectar os equips ubiquiti no Rocket e as estação SXT no AP SXA-SA, e abilitar AirMax no Rocket e nv2 no SXT-SA, acho que iria melhorar bastante.

Citação:

---

Postado originalmente por Zucchi

Rubem, primeiramente algo além do meu muito obrigado !!!

É o seguinte, fiz as alterações que você cita e entendi a explicação sobre os MCS.

Com potencia em 10dbm o nível de sinal ficou em -51/-51, logo, coloquei 1dbm a mais e fez com que o enlace fosse fechado a -49/-50 tudo bem?

Lá na aba DATA RATES em Supported Data Rates A/G, só deixei marcado o 54mbps.

Na aba HT, deixei marcado todos os AMPDU Priorities, alias, para que propriamente serve esta função?

Na aba HT MCS em:

HT Supported MCS deixei marcado 14 e 15 (sim, você disse para deixar apenas um deles mas por questão psicologica deixei os dois assim por 24 horas para ver como o enlace se comportaria).

HT Basic MCS deixei marcado também o 14 e o 15. Faz-se necessário?

Anexo 58625

Quanto ao ACK, onde fica esta config?

---

O AMPDU é um tipo de agregação de dados numa parte do envio de dados, a parte de sincronia e cia é mantida, a parte de inicio de prembulo não muda, mas quando chega na parte do processo (Que leva nansegundos, por isso preambulo LONGO é 800ns, ou seja, 0,8us, ou 0,0008ms, ou 0,0000008 segundos) em que o layer chamado MAC trafegaria os dados (Cada dado é um PDU, Protocol Data Unit, unidade de dados do protocolo, um PDU pode ser um bit ou um pacote inteiro) esse AMPDU pode Agregar (Daí que vem o A) mais unidades de dados (Mais pacotes, ou mais bit), pra aproveitar melhor o trafego.

Assim como o uso de preambulo longo aumenta o trafego, porque o tempo perdido em sincronia e cia (Posso enviar? Pode. Tô enviando. Tá, tô recebendo. Chegou? Chegou. Mas chegou o que, lê aí a 5ª letra pra ver se chegou certo) é enorme. Alias, aumentando o tempo pra enviar unidades (PDU's) mesmo passando de 400 pra 800ns faz o datarate aumentar só pouco mais de 10% (Aumenta de 65M pra 72M, digamos), então tudo o que faça a torre perder menos tempo com cada pacote melhora o desempenho.

AMPDU também tem sistema que verifica erros, então onde a zona de fresnel é parcial ou onde o SNR é baixo ele devia ajudar.

Mas onde se trafega muita coisa (PTP), ele pode criar gargalo, o chipset vai perder tempo acrescentando dados, esse tempo pode atrapalhar o throughput, então de qualquer forma você tem que testar.
(Seja PTP ou PTMP. Agregar mais dados num único envio diminui o tempo que a torre gasta com cada cliente, aumenta o uso do processamento do chipset de RF então onde isso piora o resultado é porque o chipset de RF está no gargalo, está sendo utilizado demais)
Os numeros de 0 a 7 não indicam o numero de unidades agregadas, mas as unidades de quais prioridades serão agregadas, dados de sincronia e cia tem prioridade mais alta (0), dados do cliente tem prioridade mais baixa (8, ficou de fora), depende do chipset como ficará o desempenho de qualquer forma.

O HT MCS Basic é o datarate mais baixo que o sistema vai usar, se marcar 14 e 15 como "basico" é pra esses que o sistema vai baixar quando ficar sem tráfego (Economia de energia e cia, datarate mais baixo permite o uso de sinais mais baixos portanto potencias menores e etc, em modo auto isso funciona lá de vez em quando), pra provedor isso não tem muita utilidade.

Sobre o ack-time, essa opção fica na aba Advanced da interface wireless, mas lembra de clicar no botão Advanced Mode na direita em baixo, senão não aparecem todas as abas.
O ack-timeout é exibido nesse ponto em micro-segundos, us (Onde u é a letra grega mi), 1us é 0,001ms, ou 0,000001s. O default é dynamic (automatico), eu uso assim: Mínimo de 25uS se for 150m ou menos, e depois 1us a cada 133m.
(Ou seja, 1000m seria 1000/133 = 8, mais 25 do mínimo = 33uS, sobe pra 36 ou 39us (10-20%). Pra 2Km seriam 16 da distancia + 25 do mínimo = 41us, sobe pra 45 ou 49uS)
Se fizer a conta como 25 de mínimo, e 1us por 100m em distancia pequena já vai ter o numero um pouco maior que o real, já serve bem, é o que faço, aí só aumento 1/3 (mais 33%, que é o que 133 está para 100).

Na opção wireless, na aba registration, tem como setar pra exibir o ack-time, mas não sei bem porque as vezes isso não é exibido, se depende do modo ou da versão do firmware. Em dynamic lá geralmente fica o valor real da distancia SOMENTE quando a zona de fresnel é perfeita, se lá aparecer numero grande (Digamos 50us em cliente a 500m) pode ter certeza que tem algo físico atrapalhando, coloca esse cliente em digamos 60us pra quebrar o galho enquanto você não vai ver com os olhos a obstrução (E se pode resolver).

Sobre o ack-time na torre, ó o que a UBNT mesma diz:
If two or more stations are located at the considerably different distance from the Access Point are associated to, the highest ACK Timeout for the farthest station should be set at the AP side.
(Tá aqui: http://wiki.ubnt.com/AirOS_5.3 )

Ou seja, se tem cliente de 200m a 2Km, sete o ack no AP pra 2Km (Em 802.11n seria uns 41us, mas eu colocaria 45us por precaução.

Tá no site da UBNT... pra ninguém achar que eu tiro essas informações do ar.

Citação:

---

Postado originalmente por pablozac

Prezados amigos,

Como não achei nada relacionado ao que estou passando aqui, resolvi abrir esse novo tópico para que alguém possa me ajudar a solucionar ou pelo menos esclarecer o que acontece:

A cerca de 1 ano passo por um problema de conexão entre AP UBNT (Rocket com Basestation) e Clientes Mikrotik (SXT Lite 5). Tudo começa sem aviso prévio e sem alteração no Cenário. Está tudo normal como mostra a Imagem em anexo, de repente o CCQ do AP começa a cair vertiginosamente (Chega a 30) levando os dos clientes junto, o tráfego para, e os clientes são desconectados. Em questão de menos de 1 minuto voltam a se conectar e tudo se normaliza. Já penei com varias configurações diferentes, realinhar cliente por cliente e trocar o AP por um novo. A única coisa que resolveu em definitivo foi dividir os Clientes por Fabricante. Colocar Clientes UBNT em AP UBNT e Clientes MK em AP MK. Queria uma solução mais barata pois ainda tenho torres UBNT com fabricantes misturados (UBNT e MK) onde não compensa de forma alguma eu colocar 2 interfaces 5.8 para atender 15 clientes.

Algumas considerações:

Pior Sinal da Torre usada como controle é -72
Acontece com todas os APs UBNT que tem 1 ou mais SXTs junto com as Nanos x Grids
Acontece de forma esporádica em horários e intervalos distintos e as vezes até dias de intervalo.
Não uso protocolo TDMA proprietário nos APs
O log do AP UBNT fala que o cliente está sendo desconectado por sinal ruim.
Problema de interferência já foi eliminado, pois estou sozinho e acontece em todas as torres com equipamento misto.
Só uso UBNT E MK.
Dividindo os Fabricantes o problema desaparece (Não é a solução adequada para mim no momento).

Se alguém já passou pelo problema e conseguiu uma configuração adequada para funcionamento, favor compartilhar. Ajudará uma alma desesperada a dormir em paz.
Anexo 58573

---

O airmax de todos equipamentos estão desativados? Tem que estar!
E nas SXT deixa o protocolo 802.11

Citação:

---

Postado originalmente por pablozac

Amigo @rubem,

Fiz o seguinte, mandei o funcionário ao POP acrescentar uma SXT-SA para dividir os clientes, porém antes disso, já que eles já estão querendo me esfolar vivo, uma horinha a mais ou a menos não fará diferença. Queria deixar todos na SA primeiro para ver como o MK se comportaria nessa situação como AP. Como devo configura-lo para substituir a Rocket apenas para testes. Lembrando que estão misturados SXT e Nano 2X2 juntamente com Grid 1x1.

---

Só pra referencia, é assim que "gosto" de usar:
Anexo 58629

DFS depende do canal, potencia depende do canal. Nessa versão do RouterOS o ack-time está como distancia (Nos seus SA pode estar em us, colocaria 50us, se o cliente distante for 2Km), mas o grosso está aí.
(WDS marcado desse modo pro caso de usar pppoe, caso não use ignore essa aba)

acompanhando o tópico!

Obrigado @rubem. Vou aproveitar muitas coisas. Só de fazer a substituição pelo AP MK já houve uma melhora considerável. Sem fazer nenhum ajuste o consumo do pop que não passava de 8mb já virou de 15 a 20. Ainda ocorrem as desconexões, porem de 3 a 5 clientes dos 50. Na ubnt caiam todos. A desconexão dura segundos, a rocket chegou a demorar de 2 a 3 minutos para normalizar... Enfim, creio que com os ajustes corretos o problema será resolvido em breve. Vou mantendo todos informados...

Um grande abraço !

Essa configuração que me enviou é PMP ou PTP ? Você tem uma tabela da relação de MCS x Sensibilidade da MK. Olhei o brochure da SXT_SA e não entendi muito bem. Estou com o Firmware 6.21.1. Quando habilito a opção Noise Floor Threshold o valor que aparece é -120. Devo deixar -90 ao contrario de 90 que está sua imagem ?
Anexo 58633

Pra PTP só não marcaria o HT MCS3, ele é um datarate de polarização simples (Em teoria pros Airgrid, mas algums equiptos MIMO de sinal baixo talvez usem esse datarate, não é preocupante).


Quanto as sensibilidades, a MK não divulga tabela completa de nada ultimamente, no caso dos SXT pode se basear nos dados do Rocket:
http://dl.ubnt.com/rocketM5_DS.pdf
A sensibilidade é 1dBm diferente, não faz muita diferença. A potencia é que muda mais, o SXT tem 1 ou 2dBm a mais de potencia em cada datarate, mas o grosso é igual o Rocket.
(E igual quase todo equipto recente, a sensibilidade dos chipsets anda muito igual. A potencia varia mais, porque depende do amplificador de saída usado (E da configuração dele))

Grande @rubem,

Então de acordo com suas explicações, o MCS12 e 3 como você deixou marcado, permite uma sensibilidade de -84 e -90 de acordo com o datasheet (arredondando). Então o sinal ideal para MCS12 tirando a faixa de segurança de 20dB é de no mínimo -74. Ainda estou em dúvida de como calcular o máximo. Você explicou que o sinal máximo interessante seria 28 dB acima da sensibilidade, o que evitaria vazamento entre polaridades. Então nesse caso específico, o AP setado em MCS12 o sinal ideal tem que ficar entre -66 e -74 ?

Determinei as configurações que você mandou ontem pelo ZIP, porem elas não são todas compatíveis com UBNT. Se eu seguir ao pé da letra as configurações da Aba Advanced as UBNT (NanoL e Grid) conectam mais não trafegam. Nem acesso eu consigo depois das configs aplicadas. Só não descobri ainda o que é incompatível na aba, pois como está em produção estou com medo de fuçar a toda hora. Sei que Distance setada não é. E também verifiquei que com Preambulo Curto as UBNTs não se conectam...

Como diz você: Azar de quem mistura equipamentos.... Hehehe