Criar rede RF sem interferência

[PingoDeSolda]

Bom dia a todos!

Ultimamente tenho feito testes com esses receptores/transmissores RF que sao vendidos no eBay:
http://www.ebay.com/itm/2-sets-433Mhz-R ... 3a8d102ffe

Minha ideia é colocar um par desses em cada cômodo da minha casa, para que eu possa acionar lâmpadas e outras cargas através de um controle remoto RF.

Criei um algoritmo de inundação (que evita loops), para que os receptores mais próximos do controle repassem o sinal, até que este chegue ao destino, caso o destino não esteja no alcance do controle.

Porém li que pode haver muita interferência com tantos receptores/transmissores, e acho que no meu caso, com esse algoritmo de inundação, a coisa pode piorar.


Gostaria da opinião de vocês sobre como posso evitar estas interferências numa rede deste tipo!

Tenho usado AVR's ATMEGA168/328 e ATTiny85, com a lib do arduino VirtualWire.

Preciso utilizar encoders/decoders? Como fazer isso com tantos receptores/emissores, de modo que todos continuem se comunicando?


Agradeço muito a ajuda!


Um abraço!

[xultz]

Olha, se você quer fazer uma rede que repasse pacotes para dispositivos mais longe, o ideal seria usar uma rede Zigbee. Existem módulos XBee que são compráveis no Brasil mesmo em pouca quantidade, e são relativamente simples de implementar.

[MOR_AL]

Acho que se você quiser manter os transmissores e receptores baratos, deveria usar um protocolo de comunicação tal que apenas um transmissor esteja transmitindo por vez. Algo como uma lógica ou exclusiva para funcionamento dos transmissores.
Cada módulo tem que possuir o seu endereço de identificação.
O pacote de dados poderia ser dividido em três partes.
Parte 1 com o endereço do módulo seguinte.
Parte 2 com o endereço do módulo de destino.
Parte 3 com a mensagem (ou comando) propriamente dito.
Quem transmite tem que transmitir para o módulo mais próximo, com sentido para o módulo de destino. Você tem que determinar, de acordo com a geometria local, qual deve ser o módulo seguinte para aquele sentido.
Quem tiver o endereço seguinte, altera o pacote na parte 1
Quem recebe identifica o endereço seguinte. Se não for o seu, ou se houver erro, não transmite nada. Se o endereço seguinte coincidir com o seu, o módulo altera o endereço seguinte retransmite o pacote para o seguinte, até o destino.
Quem tiver com o endereço de destino, aceita a mensagem, efetiva o comando e retransmite para o endereço anterior, alterando a parte 1 e a parte 2.

Para que a mensagem seja confirmada, deve-se retorná-la à origem, quando então é comparada com o que foi transmitido. Caso ocorra algum erro no caminho, pode-se retransmitir a mensagem, até um número limite de vezes, para evitar loop infinito, quando então deveria acusar erro definitivo.

Na etapa de testes pode-se incluir em cada módulo, um led vermelho para indicar erro de recepção, ou algum outro erro. Inclui-se também um led verde para indicar que a mensagem foi recebida e retransmitida.
Os leds devem ser desligados ou após algum tempo, ou por meio de uma chave do tipo campainha NA. Isso permite identificar o local, ou módulo que está recebendo com erro.
As três partes do pacote podem possuir algum meio de identificar um erro. Há muitos meios de se conseguir isso. Pesquise na net.

Bom. Isso é um chute inicial.
MOR_AL

[PingoDeSolda]

Olha, se você quer fazer uma rede que repasse pacotes para dispositivos mais longe, o ideal seria usar uma rede Zigbee. Existem módulos XBee que são compráveis no Brasil mesmo em pouca quantidade, e são relativamente simples de implementar.

xultz, muito obrigado pela dica!

Ainda não tinha lido sobre Zigbee, e achei ótimo!


Valeu!!

[PingoDeSolda]

Pow, MOR_AL! Muito agradecido pela atenção!

Acho que seu método resolve o problema!

Antes a ideia era ter que evitar essa configuração pela topologia pra facilitar o código, o que realmente aconteceu.
Pois por inundação eu poderia adicionar receptores em outros lugares da casa sem ter que alterar nada.

Nesse seu método, caso eu adicione algum receptor novo, na lavanderia, por exemplo, eu teria que reconfigurar algum receptor/transmissor de outro cômodo, pra atualizar esse "caminho virtual", certo?


Vou trabalhar nisso pra poder testar em breve!


Muito obrigado!

[tcpipchip]

nao esquece do preambulo durante a tranmissao.
começa com 01010101

[PingoDeSolda]

nao esquece do preambulo durante a tranmissao.
começa com 01010101

Valeu, tcpipchip!


Eu tinha bolado um formato que inicia e termina com o caractere '#' , que fica 100011.
Mas 01010101 parece bem melhor!

[cfreund]

O colega quis dizer que esses receptores super regenerativos, precisam de um tempo para se ajustar. Então, antes do seu protocolo de comunicação, envie alguns caracteres (0x55), talvez 3 bytes seja o suficiente. Diminuindo o risco de perder pacotes.

[MOR_AL]

É isso que acontece quando o receptor super regenerativo recebe o primeiro bit '1'. Essa foto é de um receptor super regenerativo que eu fiz. Sem a parte do comparador analógico.
Observe que a tensão do trem de pulsos vai subindo como a carga de um capacitor.
Tem que dar um tempo, enviando de preferência 101010... para que o ponto de operação do circuito se estabilize.
Observe que este sinal vai entrar num circuito comparador analógico. Sem os bits iniciais, os primeiros bits podem não possuir tensão suficiente para serem identificados.
Após algum tempo, que varia para cada fabricante, os bits já alcançaram o nível de operação normal. No meu caso foram cerca de 5ms.



Observe a faixa de tensão de 400mV entre o nível máximo no início do trem de pulsos e o nível mínimo já após 4,5ms. Sem os primeiros bits para estabilização, seria esta faixa de tensão disponível para o comparador. Ou seja +200mV e -200mV.
Aguardando o circuito se estabilizar, a faixa aumenta para 620mV. O nível de comparação tem que ficar, aproximadamente no meio da faixa de tensão APÓS a estabilização.
Isso aumenta a faixa dinâmica do receptor. Em outras palavras, vai funcionar com distâncias maiores.

MOR_AL

[cfreund]

MOR_AL,

Não ficou claro para mim. Este primeiro bit que vc está se referindo, seria em nível alto? Caso positivo, você fez experimentos utilizando uart como fonte de dados? Lembrando que, repousa em nível alto e vai à zero no start bit.

[MOR_AL]

MOR_AL,

Não ficou claro para mim. Este primeiro bit que vc está se referindo, seria em nível alto? Caso positivo, você fez experimentos utilizando uart como fonte de dados? Lembrando que, repousa em nível alto e vai à zero no start bit.

1 - Projetei a parte de UHF e do primeiro estágio de ganho em baixa frequência do receptor super regenerativo, que vem antes do estágio comparador analógico, que amplifica o sinal a níveis TTL. Não fiz o estágio comparador analógico.
2 - Montei o circuito em uma PCI com filetes menores possíveis e componentes o mais próximo possíveis. Esse procedimento exigiu umas três a quatro tentativas.
3 - Coloquei a ponteira do osciloscópio na saída do estágio de ganho em baixa frequência.
4 - Energizei o circuito.
5 - Preparei o osciloscópio para gravar a partir do nível de trigger ser ultrapassado. Veja a setinha no eixo vertical à direita abaixo do nível sem sinal.
6 - Usei o único gerador de UHF que possuía. Um chaveiro de alarme de carro. Ele envia um montão de bits, mas eu estava interessado no comportamento do ponto de operação tanto no início dos bits, como quando eles se estabilizam. Isso determina o nível de trigger do comparador analógico e o tempo de espera para estabilização. O nível do trigger está a 240mV abaixo do nível da saída. Como com o sinal o nível sobe, o nível do trigger poderia ser maior. Digamos a cerca de 100mV abaixo do nível sem sinal. Isso faz com que o trigger ocorra mais para o meio da transição do sinal, tendendo a manter as comutações de acordo com as que foram transmitidas.
Só me preocuparia em manter o transmissor sem alimentação, ou em estado de pouco consumo, quando sua entrada tiver '1' lógico. Isso coincide com o interesse para os níveis exteriorizados pela UART. Em '1' não há dados.
Em termos de projeto do receptor, realmente não importa se o primeiro bit for '0' ou '1'. Os primeiros bits servem apenas para que o ponto de operação do receptor fique corretamente estabelecido. Se o bit for '0' ou '1' só vai importar mais tarde, quando o receptor todo estiver pronto. Isso é o de menos e fácil de resolver, pois só depende em qual entrada do comparador vai o sinal e qual vai o nível de trigger (se entrada positiva ou negativa).
No9 meu caso, a taxa de comutação se mantém boa até cerca de 1k2Hz, o que é comum para estes receptores.
Espero ter esclarecido.
MOR_AL

[PingoDeSolda]

Pessoal, criei o protocolo hop-by-hop que o MO_RAL descreveu no terceiro post, usando a VirtualWire/Arduino (depois entendi a questão do preâmbulo, que a própria VirtualWire insere na mensagem).


Utilizei um esquema em que o caminho a ser percorrido está na propría mensagem, por exemplo, para enviar uma mensagem a partir da placa 1 para a placa 8, passando pelas placas 2, 3, 4, 5 e 7, a seguinte mensagem é criada: #1234578+ack+id+payload#


Percebi que quanto maior a mensagem, maior a probabilidade de erro/interferência.
Em uma situação em que seja necessário passar por 20 hops (nao sei se precisarei de tantos intermediários em algum momento, acho que nao), 20 bytes seriam só de endereços. Por isso, estou pensando em implementar uma mensagem que contenha somente o endereço de origem e endereço de destino, e talvez o endereço atual ou próximo endereço, pra ter controle do trajeto, e a lógica do caminho da rede estaria nas próprias placas, ou seja, cada placa sabe de quem ela pode receber e pra quem ela pode repassar. Isso eliminaria os 20 bytes de endereços, além de não limitar o caminho em 20 dispositivos somente.
Mas isso ainda estou vendo.


Percebi que, após receber uma mensagem, se eu imediatamente enviar uma resposta, ninguém recebe nada.
Por isso uso um delay de 10ms ou 30ms antes de enviar a resposta/ack.

Será que pode ser porque a mensagem transmitida está refletindo e atrasando, e consequentemente, quando envio a resposta imediatamente, ocorre interferência?


De qualquer forma, estou utilizando o hardware RF mais barato disponível, e como gostei da brincadeira, comprei algumas peças de um hardware melhor, da HopeRF, modelo RFM69CW:
http://www.ebay.com/itm/181249440892?ss ... 1497.l2649



Aproveitando a mensagem, alguém tem algum livro ou pdf legal sobre radio-frequência e pode me indicar?


Muito obrigado!

[xultz]

Cara, se você usar módulos Zigbee, toda essa questão de rede, hoping, roteamento, ele faz prá você. O Zigbee é interessante porque ele se organiza sozinho, você não precisa criar tabelas de roteamento. E se você desliga um dispositivo, a rede se reorganiza sozinha e continua roteando os pacotes. É muito bem feito.

Esse mês eu estava testando um módulo da Hope, o RFM73, que funciona em 2,4GHz. Eu achei o resultado bem meia boca, perdia muito pacote. Ele usa um chip chinês que tenta ser um clone do nRF24L01+. Aí eu comprei umas plaquinhas com o nRF24L01, usando o mesmo firmware, e o resultado era muito melhor, não tinha a menor comparação. Esses módulos da Hope são irresistivelmente baratos, mas eu fiquei com um pé atrás depois deste teste.

[chrdcv]

Olá amigo!

Através do link passado, dei uma olhada rápida na descrição do transceiver que utiliza e percebi que o mesmo não possui CSMA implementado. Sendo assim, tudo o que desenvolver para esses caras deverá ser algo do tipo baseado ou derivado das idéias do ALOHA ou slotted-ALOHA.

[PingoDeSolda]

Cara, se você usar módulos Zigbee, toda essa questão de rede, hoping, roteamento, ele faz prá você. O Zigbee é interessante porque ele se organiza sozinho, você não precisa criar tabelas de roteamento. E se você desliga um dispositivo, a rede se reorganiza sozinha e continua roteando os pacotes. É muito bem feito.

Esse mês eu estava testando um módulo da Hope, o RFM73, que funciona em 2,4GHz. Eu achei o resultado bem meia boca, perdia muito pacote. Ele usa um chip chinês que tenta ser um clone do nRF24L01+. Aí eu comprei umas plaquinhas com o nRF24L01, usando o mesmo firmware, e o resultado era muito melhor, não tinha a menor comparação. Esses módulos da Hope são irresistivelmente baratos, mas eu fiquei com um pé atrás depois deste teste.

Entao, minha ideia inicial era usar Zigbee, só que, por causa do preço, resolvi tentar primeiro essas placas RF baratas, eu mesmo implementando um protocolo básico por software.

Depois, acabei vendo que existem bibliotecas pro nRF24L01 que implementam bons protocolos, e só recentemente, com algumas pesquisas a mais, vi que o pessoal elogia bastante essa placa. Tem ela no eBay mais barato do que esses módulos que estou usando:
http://www.ebay.com/itm/High-Quality-NR ... 2ed01dd960


Entao xultz, eu to animado com esses RFM69 por causa do projeto Moteino. É um mini-arduino, com o ATMega328 e a RFM69 já soldada.
http://lowpowerlab.com/moteino/

E usa a biblioteca do próprio criador do Moteino, que parece ser a que o pessoal usa por aí afora.
https://github.com/LowPowerLab/RFM69


O que me chamou a atenção nessa RFM69 foi a criptografia AES por hardware.

Só que se rolar essa perda de pacotes, vou partir direto pro nRFL2401L+.


Valeu!