Duvida

[hmfarm]

Pessoal tenho 1 rocket M5 com 35 clientes conectados entrando uma banda de 30 MB e os clientes estão liberados tudo pra eles.

Por que tenho clientes passando 50 mb por 50 mb, e outros passando 11mb por 50 mb?

ROCKET M5



Cliente Bom


Cliente Ruim

[Conectiva]

Cliente bom esta as 300 Mts com versão de SW mais antiga. Ja o ruin esta a 200M com versão de SW em 5.5.9. Bem estranho. Acho que pode ser alinhamento ou interferência de algum equipamento ou enlace de outro ISP ou ate um de seus painéis. Tenta mexer no alinhamento ou trocar o canal para teste, baixa a potencia um pouco esta bem perto. tudo é valido. nos informa aqui qual foi o resultado. abraço sucesso ai!

[brunocemeru]

Amigo multiponto passando 50M tá bom demais no meu ver.
Acredito que oscilação nisso vai ser uma constante pois o rocket "dedica" banda a uma solicitação assim pode prejudicar outros.

[rubem]

Olha sempre o nível dos sinais.

Nos 2 exemplos, um cliente tem sinal ruim de -59dBm, isso é sinal ruim pra um data rate de 300M (MCS15 em 40MHz).

Mas o outro tem sinal ainda pior, -77dBm, está num data rate bem menor, MCS12 (162M em 40MHz) mas MCS12 igual só fica decente com sinal bem acima de uns -72dBm.

Tem que melhorar esses sinais ou usar um data rate de acordo com o sinal. -77dBm só fica bom se fixar em MCS9 ou MCS10.

(O throughput em datarate baixo será obviamente baixo, mas pelo menos o CCQ fica bom, não há perda de pacote, logo, a navegação fica boa)


Se tem tráfego médio tão pequeno, pra que usar 40MHz o ocupar tanto espaço?
Pra um tráfego médio de 4Mbps , ou que seja o triplo disso, 16Mbps, pode usar só 20MHz pra ocupar uma área menor do espectro e pra ter menos portadoras pro chipset de RF processar os dados. E se usar fixo em MCS12 vai ter throughput mais que suficiente pra isso, com a vantagem que o CCQ será melhor que com MCS15 (Com o "automatic").


Nível de sinal é tudo, esquece "cor", olha os números, sinal de chain0 e chain1, nenhum pode estar abaixo de certos valores pra cada data rates, pra MCS15 só vai ter CCQ de 100% se tiver sinais acima de -55dBm (Acima é -54, -53, -52, etc), pra MCS12 só acima de -70dBm (Acima é -69, -68, -67, etc).

No caso desse segundo cliente com -69 num chain, e -77 no outro, provavelmente tem algo na zona de Fresnel. Não tem regra, mas geralmente o primeiro chain é a horizontal e o segundo a vertical, como é o segundo que está com sinal baixo talvez a maior obstrução é nela, algo logo abaixo da linha de visada tapando a zona de Fresnel da vertical. Teria que subir essa CPE.

(Mas ainda assim, se os 2 chains ficarem em -69dBm, isso é sinal ruim pra MCS15)

[hmfarm]

Olha sempre o nível dos sinais.

Nos 2 exemplos, um cliente tem sinal ruim de -59dBm, isso é sinal ruim pra um data rate de 300M (MCS15 em 40MHz).

Mas o outro tem sinal ainda pior, -77dBm, está num data rate bem menor, MCS12 (162M em 40MHz) mas MCS12 igual só fica decente com sinal bem acima de uns -72dBm.

Tem que melhorar esses sinais ou usar um data rate de acordo com o sinal. -77dBm só fica bom se fixar em MCS9 ou MCS10.

(O throughput em datarate baixo será obviamente baixo, mas pelo menos o CCQ fica bom, não há perda de pacote, logo, a navegação fica boa)


Se tem tráfego médio tão pequeno, pra que usar 40MHz o ocupar tanto espaço?
Pra um tráfego médio de 4Mbps , ou que seja o triplo disso, 16Mbps, pode usar só 20MHz pra ocupar uma área menor do espectro e pra ter menos portadoras pro chipset de RF processar os dados. E se usar fixo em MCS12 vai ter throughput mais que suficiente pra isso, com a vantagem que o CCQ será melhor que com MCS15 (Com o "automatic").


Nível de sinal é tudo, esquece "cor", olha os números, sinal de chain0 e chain1, nenhum pode estar abaixo de certos valores pra cada data rates, pra MCS15 só vai ter CCQ de 100% se tiver sinais acima de -55dBm (Acima é -54, -53, -52, etc), pra MCS12 só acima de -70dBm (Acima é -69, -68, -67, etc).

No caso desse segundo cliente com -69 num chain, e -77 no outro, provavelmente tem algo na zona de Fresnel. Não tem regra, mas geralmente o primeiro chain é a horizontal e o segundo a vertical, como é o segundo que está com sinal baixo talvez a maior obstrução é nela, algo logo abaixo da linha de visada tapando a zona de Fresnel da vertical. Teria que subir essa CPE.

(Mas ainda assim, se os 2 chains ficarem em -69dBm, isso é sinal ruim pra MCS15)

Rubem , eu ente di muito pouco , VC tem algum vídeo no YouTube pra me passar sobre mcs e cálculo de potência de ubiquiti pra eu dar uma estudada no assunto ?

Obrigado.

Sent from my XT1039 using UnderLinux mobile app

[rubem]

No brasil mal tem livro ou qualquer coisa escrita, você quer logo Youtube? (O lugar que tem MENOS conteúdo técnico do mundo)

Recomendo uma lida em todos os tutoriais (Mesmo os sem nada a ver como wifi) da www.teleco.com.br , ou pegar conteúdo tipo esse:
http://www.piscespacific.org/livesit...alculation.pdf
E sair googlando por cada termo que não entender, até entender cada palavra dele.

Com esse sotaque complica, mas até em inglês tem pouca coisa:


Especifico pra Ubiquiti... aí complica, se até sobre os padrões do IEEE tem pouca coisa, imagina pra uma marca! E na verdade a UBNT não tem nada especial, toda a teoria que se aplica a MK se aplica a UBNT.
No site da www.entelcotelecom.com.br , na loja virtual, tinha um livro sobre Airmax e/ou Ubiquiti, é do pouco conteúdo específico sobre eles que vi.

E tem o canal do Zé Alves ou Granlabor no Youtube, alias, talvez tinha, ficou uns meses sem nada, sei lá o que houve, tem partes das palestras e aulas dele mas não tem tudo em ordem desde o começo (Não é um be-a-ba).

[hmfarm]

No brasil mal tem livro ou qualquer coisa escrita, você quer logo Youtube? (O lugar que tem MENOS conteúdo técnico do mundo)

Recomendo uma lida em todos os tutoriais (Mesmo os sem nada a ver como wifi) da www.teleco.com.br , ou pegar conteúdo tipo esse:
http://www.piscespacific.org/livesit...alculation.pdf
E sair googlando por cada termo que não entender, até entender cada palavra dele.

Com esse sotaque complica, mas até em inglês tem pouca coisa:


Especifico pra Ubiquiti... aí complica, se até sobre os padrões do IEEE tem pouca coisa, imagina pra uma marca! E na verdade a UBNT não tem nada especial, toda a teoria que se aplica a MK se aplica a UBNT.
No site da www.entelcotelecom.com.br , na loja virtual, tinha um livro sobre Airmax e/ou Ubiquiti, é do pouco conteúdo específico sobre eles que vi.

E tem o canal do Zé Alves ou Granlabor no Youtube, alias, talvez tinha, ficou uns meses sem nada, sei lá o que houve, tem partes das palestras e aulas dele mas não tem tudo em ordem desde o começo (Não é um be-a-ba).

Obrigado

Sent from my XT1039 using UnderLinux mobile app

[hmfarm]

Olha sempre o nível dos sinais.

Nos 2 exemplos, um cliente tem sinal ruim de -59dBm, isso é sinal ruim pra um data rate de 300M (MCS15 em 40MHz).

Mas o outro tem sinal ainda pior, -77dBm, está num data rate bem menor, MCS12 (162M em 40MHz) mas MCS12 igual só fica decente com sinal bem acima de uns -72dBm.

Tem que melhorar esses sinais ou usar um data rate de acordo com o sinal. -77dBm só fica bom se fixar em MCS9 ou MCS10.

(O throughput em datarate baixo será obviamente baixo, mas pelo menos o CCQ fica bom, não há perda de pacote, logo, a navegação fica boa)


Se tem tráfego médio tão pequeno, pra que usar 40MHz o ocupar tanto espaço?
Pra um tráfego médio de 4Mbps , ou que seja o triplo disso, 16Mbps, pode usar só 20MHz pra ocupar uma área menor do espectro e pra ter menos portadoras pro chipset de RF processar os dados. E se usar fixo em MCS12 vai ter throughput mais que suficiente pra isso, com a vantagem que o CCQ será melhor que com MCS15 (Com o "automatic").


Nível de sinal é tudo, esquece "cor", olha os números, sinal de chain0 e chain1, nenhum pode estar abaixo de certos valores pra cada data rates, pra MCS15 só vai ter CCQ de 100% se tiver sinais acima de -55dBm (Acima é -54, -53, -52, etc), pra MCS12 só acima de -70dBm (Acima é -69, -68, -67, etc).

No caso desse segundo cliente com -69 num chain, e -77 no outro, provavelmente tem algo na zona de Fresnel. Não tem regra, mas geralmente o primeiro chain é a horizontal e o segundo a vertical, como é o segundo que está com sinal baixo talvez a maior obstrução é nela, algo logo abaixo da linha de visada tapando a zona de Fresnel da vertical. Teria que subir essa CPE.

(Mas ainda assim, se os 2 chains ficarem em -69dBm, isso é sinal ruim pra MCS15)

Oi rubem,



Segue ai os 2 moradores que eu havia mandado a semana passada.

creio que o morador com o download baixo esteja com a zona fresnel afetada por isso esta assim, mas por exemplo, qual potencia de saida e MCS devo deixar em cada um deles ?

E qual a potencia de saida que devo deixar no rocket M5?

Obs: Quando mudei o cliente bom pra MCS 14 o CCQ dele caiu pra 70% mas n afetou muito os megabytes que passam, mas ai voltei a deixar automatic.

[rubem]

Esse cliente "bom" está usando na verdade MCS13 no Tx, é o data rate de 216M a 40MHz. Passar ele pra MCS14 realmente vai piorar o CCQ já que pra SUBIR o data rate precisa sinal MAIOR.

O cliente "ruim" está usando MCS12 de TX, se o CCQ tá bom então deixa pra lá, só seria um problema se perder ping (-l 1470 , nem vale a pena dar ping comum de 32 bytes). Mas se for pra mudar algo, tem que usar um data rate menor que o atual, se no modo automatic o cliente está em MCS12 e tráfego nalgum sentido é ruim, tem que BAIXAR o data rate pra ter menos perda de pacotes, e testar as opções ABAIXO de MCS12.

Veja os data rates nominais:
http://mcsindex.com/

162M e 180M são MCS12 em 40MHz de largura (Precisa mesmo usar 40MHz?), o tempo de guarda pode ser diferente nos 2 lados.

E 216M, o data rate de TX do cliente "bom", é MCS13.

A sensibilidade de cada data rates está no datasheet:
https://dl.ubnt.com/loco_m5_datasheet.pdf
No exemplo de MCS13, a sensibilidade é de -79dBm. Mas se usar -78dBm a rede será um lixo, precisa ter uma MARGEM entre sensibilidade e o sinal presente (E o que vale é o sinal do chain0 e chain1, não a barrinha colorida), eu só considero boa a rede que tem essa margem em 20dBm. Ou seja, se a sensibilidade é de -79dBm, o maior CCQ e throughput com o sinal lá pelos -59dBm.

(E o cliente "bom", que está usando MCS13 (216M) tem sinal melhor que -59dBm, ele tem -58dBm)

O cliente ruim em MCS12 tem sinal -75dBm (No chain1, nivela pelo PIOR), e a sensibilidade em MCS12 é de -84dbm, ou seja, ele tem apenas 9dBm de margem! Põe ele num data rate que dê 20dBm de margem até a sensibilidade que terá ZERO perda de pacotes (Que seria MCS8, mas é melhor não baixar tanto, é melhor aumentar a antena desse cliente, sinal -75dBm não devia ser usado, trabalha com sinais APENAS acima de -70dBm, pra usar pelo menos MCS10).

Essa margem que falo é tipo o SNR, mas o SNR é a margem até o RUÍDO, um SNR tipo 10dBm gera uma rede lixo, e pra mim uma margem de 10dBm até a SENSIBILIDADE (Do data rate usado) também.
Se aplicar a mesma fórmula de SNR pra margem até a sensibilidade, a conta não bate porque com 20dBm de margem até o throughput fica ok, mas 20dB de SNR nem sempre.

Fica em 15 a 20dBm de sensibilidade que tá ok, no mínimo uns 13dBm se for rede que pode ter qualidade baixa, mas menos de 12dBm nunca.

https://community.ubnt.com/t5/Wirele...dB/td-p/464171


E esse seu problema é mais uma prova que o software é burro na seleção automatica de data rate, usa MCS12 com -75dBm, com margem péssima de 9dBm, ao invés de baixar o data rate pra ter perda menor de pacotes. Se o software funcionasse corretamente com a mudança automática só haveria perda de pacotes com sinais inferiores a -80dBm, pois esse é o sinal mínimo pra ter um pingo de qualidade com MCS8.

E canal de 40MHz geramente precisa sinal um pouco mais alto (2 ou 3dBm) que a 20MHz, se não vende planos de 10M pra cima não vejo pra que ficar gastando processamento do chipset com mais portadoras usando 40MHz.

[hmfarm]

Esse cliente "bom" está usando na verdade MCS13 no Tx, é o data rate de 216M a 40MHz. Passar ele pra MCS14 realmente vai piorar o CCQ já que pra SUBIR o data rate precisa sinal MAIOR.

O cliente "ruim" está usando MCS12 de TX, se o CCQ tá bom então deixa pra lá, só seria um problema se perder ping (-l 1470 , nem vale a pena dar ping comum de 32 bytes). Mas se for pra mudar algo, tem que usar um data rate menor que o atual, se no modo automatic o cliente está em MCS12 e tráfego nalgum sentido é ruim, tem que BAIXAR o data rate pra ter menos perda de pacotes, e testar as opções ABAIXO de MCS12.

Veja os data rates nominais:
http://mcsindex.com/

162M e 180M são MCS12 em 40MHz de largura (Precisa mesmo usar 40MHz?), o tempo de guarda pode ser diferente nos 2 lados.

E 216M, o data rate de TX do cliente "bom", é MCS13.

A sensibilidade de cada data rates está no datasheet:
https://dl.ubnt.com/loco_m5_datasheet.pdf
No exemplo de MCS13, a sensibilidade é de -79dBm. Mas se usar -78dBm a rede será um lixo, precisa ter uma MARGEM entre sensibilidade e o sinal presente (E o que vale é o sinal do chain0 e chain1, não a barrinha colorida), eu só considero boa a rede que tem essa margem em 20dBm. Ou seja, se a sensibilidade é de -79dBm, o maior CCQ e throughput com o sinal lá pelos -59dBm.

(E o cliente "bom", que está usando MCS13 (216M) tem sinal melhor que -59dBm, ele tem -58dBm)

O cliente ruim em MCS12 tem sinal -75dBm (No chain1, nivela pelo PIOR), e a sensibilidade em MCS12 é de -84dbm, ou seja, ele tem apenas 9dBm de margem! Põe ele num data rate que dê 20dBm de margem até a sensibilidade que terá ZERO perda de pacotes (Que seria MCS8, mas é melhor não baixar tanto, é melhor aumentar a antena desse cliente, sinal -75dBm não devia ser usado, trabalha com sinais APENAS acima de -70dBm, pra usar pelo menos MCS10).

Essa margem que falo é tipo o SNR, mas o SNR é a margem até o RUÍDO, um SNR tipo 10dBm gera uma rede lixo, e pra mim uma margem de 10dBm até a SENSIBILIDADE (Do data rate usado) também.
Se aplicar a mesma fórmula de SNR pra margem até a sensibilidade, a conta não bate porque com 20dBm de margem até o throughput fica ok, mas 20dB de SNR nem sempre.

Fica em 15 a 20dBm de sensibilidade que tá ok, no mínimo uns 13dBm se for rede que pode ter qualidade baixa, mas menos de 12dBm nunca.

https://community.ubnt.com/t5/Wirele...dB/td-p/464171


E esse seu problema é mais uma prova que o software é burro na seleção automatica de data rate, usa MCS12 com -75dBm, com margem péssima de 9dBm, ao invés de baixar o data rate pra ter perda menor de pacotes. Se o software funcionasse corretamente com a mudança automática só haveria perda de pacotes com sinais inferiores a -80dBm, pois esse é o sinal mínimo pra ter um pingo de qualidade com MCS8.

E canal de 40MHz geramente precisa sinal um pouco mais alto (2 ou 3dBm) que a 20MHz, se não vende planos de 10M pra cima não vejo pra que ficar gastando processamento do chipset com mais portadoras usando 40MHz.

Mas eu n to tendo perda de pacotes, o unico problema é que o cliente ruim ta com pouco download. sera que baixando o MCS dele eu consigo aumentar o MB que passa ?

[hmfarm]

Esse cliente "bom" está usando na verdade MCS13 no Tx, é o data rate de 216M a 40MHz. Passar ele pra MCS14 realmente vai piorar o CCQ já que pra SUBIR o data rate precisa sinal MAIOR.

O cliente "ruim" está usando MCS12 de TX, se o CCQ tá bom então deixa pra lá, só seria um problema se perder ping (-l 1470 , nem vale a pena dar ping comum de 32 bytes). Mas se for pra mudar algo, tem que usar um data rate menor que o atual, se no modo automatic o cliente está em MCS12 e tráfego nalgum sentido é ruim, tem que BAIXAR o data rate pra ter menos perda de pacotes, e testar as opções ABAIXO de MCS12.

Veja os data rates nominais:
http://mcsindex.com/

162M e 180M são MCS12 em 40MHz de largura (Precisa mesmo usar 40MHz?), o tempo de guarda pode ser diferente nos 2 lados.

E 216M, o data rate de TX do cliente "bom", é MCS13.

A sensibilidade de cada data rates está no datasheet:
https://dl.ubnt.com/loco_m5_datasheet.pdf
No exemplo de MCS13, a sensibilidade é de -79dBm. Mas se usar -78dBm a rede será um lixo, precisa ter uma MARGEM entre sensibilidade e o sinal presente (E o que vale é o sinal do chain0 e chain1, não a barrinha colorida), eu só considero boa a rede que tem essa margem em 20dBm. Ou seja, se a sensibilidade é de -79dBm, o maior CCQ e throughput com o sinal lá pelos -59dBm.

(E o cliente "bom", que está usando MCS13 (216M) tem sinal melhor que -59dBm, ele tem -58dBm)

O cliente ruim em MCS12 tem sinal -75dBm (No chain1, nivela pelo PIOR), e a sensibilidade em MCS12 é de -84dbm, ou seja, ele tem apenas 9dBm de margem! Põe ele num data rate que dê 20dBm de margem até a sensibilidade que terá ZERO perda de pacotes (Que seria MCS8, mas é melhor não baixar tanto, é melhor aumentar a antena desse cliente, sinal -75dBm não devia ser usado, trabalha com sinais APENAS acima de -70dBm, pra usar pelo menos MCS10).

Essa margem que falo é tipo o SNR, mas o SNR é a margem até o RUÍDO, um SNR tipo 10dBm gera uma rede lixo, e pra mim uma margem de 10dBm até a SENSIBILIDADE (Do data rate usado) também.
Se aplicar a mesma fórmula de SNR pra margem até a sensibilidade, a conta não bate porque com 20dBm de margem até o throughput fica ok, mas 20dB de SNR nem sempre.

Fica em 15 a 20dBm de sensibilidade que tá ok, no mínimo uns 13dBm se for rede que pode ter qualidade baixa, mas menos de 12dBm nunca.

https://community.ubnt.com/t5/Wirele...dB/td-p/464171


E esse seu problema é mais uma prova que o software é burro na seleção automatica de data rate, usa MCS12 com -75dBm, com margem péssima de 9dBm, ao invés de baixar o data rate pra ter perda menor de pacotes. Se o software funcionasse corretamente com a mudança automática só haveria perda de pacotes com sinais inferiores a -80dBm, pois esse é o sinal mínimo pra ter um pingo de qualidade com MCS8.

E canal de 40MHz geramente precisa sinal um pouco mais alto (2 ou 3dBm) que a 20MHz, se não vende planos de 10M pra cima não vejo pra que ficar gastando processamento do chipset com mais portadoras usando 40MHz.

O CCQ caiu pra 70% qdo mudei o cliente pra mcs 13

[rubem]

Veja que o throughput usado SUBIU, em auto ele fica em 213M, fixo em MCS13 ele vai pra 240M. Data rate mais alto precisa sinal mais alto.

213M e 240M são tudo MCS13, mas muda o tempo de guarda (Short Guard Interval, ou Long Guard Interval).

Testa então MCS12, pro CCQ subir.

(E o "pouco download" que fala do cliente, é perda de pacote, se ele fica a 1km da torre, um ping devia levar 1 ou 2ms, se o ping -l 1450 leva 20 a 50ms isso é um pacote que foi enviado, 2ms depois não houve resposta, aí ele foi enviado de novo, a resposta foi enviada 1 ou 2ms depois mas a resposta é que foi perdida, e assim o tempo total pro ping e sua resposta sair e chegar foi de 20ms, toda demora em distância curta é pacote perdido, porque se pacote é perdido ele é reenviado. É bem diferente de um ping rumo ao Japão, aí é questão de distância e vários roteamentos no caminho)

De qualquer forma -75dBm é sinal baixo demais pra conseguir alguma coisa que presta, nesse cliente ruim o jeito seria colocar o AP da torre fixo em MCS12 a 20MHz (E esse cliente fixo em MCS10 talvez) , limitar o data rate de TODOS por causa de 1 cliente. Acho melhor ir melhorar o sinal dele, fazer ele subir pra -70dBm ou mais (Nos 2 chains pelo menos isso de sinal), aí sim daria pra deixar o AP da torre com data rate auto.

(Veja que limitando o TX Rate no cliente você só altera o... TX do cliente, que é o upload (TX do cliente é o RX no AP da torre, sai do cliente e entra no AP, é o upload do cliente). Se quer melhor APENAS o download, teria que baixa o TX da TORRE, dado que sai da torre e vai pro cliente é TX na torre e RX do cliente, é o download. Com -75dBm não tem muito o que fazer nesse cliente, baixa TX Rate na torre só por causa dele pode ser feito, mas baixaria o download de todos, com MCS12 na torre mal dá pra trafegar 60 ou 70Mbps agregado)

[hmfarm]

Veja que o throughput usado SUBIU, em auto ele fica em 213M, fixo em MCS13 ele vai pra 240M. Data rate mais alto precisa sinal mais alto.

213M e 240M são tudo MCS13, mas muda o tempo de guarda (Short Guard Interval, ou Long Guard Interval).

Testa então MCS12, pro CCQ subir.

(E o "pouco download" que fala do cliente, é perda de pacote, se ele fica a 1km da torre, um ping devia levar 1 ou 2ms, se o ping -l 1450 leva 20 a 50ms isso é um pacote que foi enviado, 2ms depois não houve resposta, aí ele foi enviado de novo, a resposta foi enviada 1 ou 2ms depois mas a resposta é que foi perdida, e assim o tempo total pro ping e sua resposta sair e chegar foi de 20ms, toda demora em distância curta é pacote perdido, porque se pacote é perdido ele é reenviado. É bem diferente de um ping rumo ao Japão, aí é questão de distância e vários roteamentos no caminho)

De qualquer forma -75dBm é sinal baixo demais pra conseguir alguma coisa que presta, nesse cliente ruim o jeito seria colocar o AP da torre fixo em MCS12 a 20MHz (E esse cliente fixo em MCS10 talvez) , limitar o data rate de TODOS por causa de 1 cliente. Acho melhor ir melhorar o sinal dele, fazer ele subir pra -70dBm ou mais (Nos 2 chains pelo menos isso de sinal), aí sim daria pra deixar o AP da torre com data rate auto.

(Veja que limitando o TX Rate no cliente você só altera o... TX do cliente, que é o upload (TX do cliente é o RX no AP da torre, sai do cliente e entra no AP, é o upload do cliente). Se quer melhor APENAS o download, teria que baixa o TX da TORRE, dado que sai da torre e vai pro cliente é TX na torre e RX do cliente, é o download. Com -75dBm não tem muito o que fazer nesse cliente, baixa TX Rate na torre só por causa dele pode ser feito, mas baixaria o download de todos, com MCS12 na torre mal dá pra trafegar 60 ou 70Mbps agregado)

Verdade troquei o mcs para 12 no cliente bom e o CCQ estabilizou bem em 99.1 99. e 100%.

e um sinal de -67 db eu fixo em quanto ? o MCS ?

[rubem]

Com -67dBm eu usaria MCS11, e só olhar a sensibilidade no datasheet e acrescentar 20dBm.