Rede de sensores sem fio de baixo custo na banda de 433 MHz: 5 etapas (com imagens)

2024 Autor: John Day | [email protected]. Última modificação: 2024-01-30 11:37

Muito obrigado a Teresa Rajba por gentilmente me dar sua aceitação de usar os dados de suas publicações neste artigo

* Na imagem acima - as cinco unidades sensor-emissor que usei para testar

O que são redes de sensores sem fio?

Uma definição simples seria: as redes de sensores sem fio referem-se a um grupo de dispositivos eletrônicos distribuídos em uma determinada área para monitoramento e registro de dados ambientais, que são transmitidos sem fio a um local central para serem processados e armazenados.

Hoje em dia as Redes de Sensores Sem Fio podem ser utilizadas de várias maneiras, abaixo estão apenas alguns exemplos:

• Áreas de vigilância ecológica de florestas, rios, lagos, mares e oceanos;
• Possibilidade de alertar em caso de ataques terroristas, químicos, biológicos, epidêmicos;
• Sistemas de monitoramento de crianças, idosos, pacientes ou portadores de necessidades especiais;
• Sistemas de vigilância na agricultura e estufas;
• Sistema de monitoramento de previsão do tempo;
• Vigilância do trânsito da cidade, escolas, parques de estacionamento;

E muitos, muitos outros aplicativos.

Neste artigo, quero mostrar os resultados de um experimento com redes de sensores sem fio que têm sido usadas para monitorar dados de temperatura e umidade, com uma variação lenta e relativamente previsível. Para este experimento, escolhi usar sensores-remetentes que construí por conta própria usando módulos acessíveis. O receptor também é DIY, a comunicação é unidirecional (na banda de rádio 433 MHz), o que significa que os sensores apenas transmitem os dados e a central apenas recebe. Não há comunicação entre os sensores e do receptor para os sensores.

Mas por que escolher usar vários transmissores e apenas um receptor? Obviamente, o primeiro motivo seria “tornar as coisas simples”. Quanto mais simples for a montagem, menor será a probabilidade de falha e, definitivamente, é muito mais fácil reparar e substituir os componentes individuais em caso de mau funcionamento. O consumo de energia também é menor, as baterias vão durar mais (os sensores só vão consumir durante o monitoramento e recebimento, o resto do tempo o dispositivo estará em modo de hibernação). O fato de ser simples torna o dispositivo também barato. Outro aspecto a ser considerado é a área de cobertura. Porque? É muito mais fácil construir e usar um receptor sensível do que ter um receptor sensível e um transmissor poderoso nos sensores e no módulo central (isso é necessário para uma boa comunicação bidirecional). Com um receptor sensível e de boa qualidade é possível receber dados de longa distância, mas emitir dados para a mesma distância requer alta potência de emissão e isso vem com altos custos, consumo de eletricidade e (não nos esqueçamos) a possibilidade de ultrapassar o potência máxima legal do transmissor na banda de 433 MHz. Usando um receptor de qualidade média, barato, mas com uma antena de alta qualidade (mesmo DIY) e transmissores baratos com uma antena de boa qualidade, podemos alcançar excelentes resultados por uma fração do custo das redes de sensores sem fio existentes.

Etapa 1: Considerações teóricas

A ideia de construir uma rede de sensores sem fio para monitorar a temperatura e a umidade do ar e do solo em diferentes áreas de uma estufa me veio à mente há muito tempo, quase 10 anos. Eu queria construir uma rede de 1 fio e usar sensores de temperatura e umidade de 1 fio. Infelizmente, há 10 anos os sensores de umidade eram raros e caros (embora os sensores de temperatura fossem amplamente difundidos) e, uma vez que espalhar fios por toda a estufa não parecia uma opção, desisti da ideia rapidamente.

No entanto, agora a situação mudou radicalmente. Conseguimos encontrar sensores baratos e de boa qualidade (temperatura e umidade), e também temos acesso a transmissores e receptores baratos na banda de 433 MHz. Só há um problema: se tivermos mais sensores (digamos 20) como resolvemos as colisões (lembre-se de que se trata de uma comunicação unilateral), ou seja, sobrepondo a emissão de 2 ou mais sensores? Enquanto procurava por uma solução possível, encontrei estes artigos muito interessantes:

Transmissão de convergência de sensor sem fio com base em procedimento de operações aleatórias - por RAJBA, T. e RAJBA, S.

e

A probabilidade de colisões na Rede de Sensor Wireless com envio aleatório - por RAJBA S. e RAJBA. T

Basicamente, os autores nos mostram que a probabilidade de colisões em uma rede de sensores sem fio pode ser calculada se os pacotes forem emitidos em determinados momentos de acordo com uma distribuição poissoniana (exponencial).

Um extrato do artigo acima lista as características da rede estudada.

• um grande número de unidades sensor-emissor N;
• as unidades sensor-emissor permanecem completamente independentes e ligá-las ou desligá-las não tem influência na operação da rede;
• todas as unidades sensoras emissoras (ou uma parte delas) podem ser móveis, desde que estejam localizadas dentro do alcance de rádio da estação receptora;
• os parâmetros físicos que mudam lentamente são submetidos a medições, o que significa que não há necessidade de transmitir os dados com muita frequência (por exemplo, a cada vários minutos ou várias dezenas de minutos);
• a transmissão é do tipo unilateral, isto é, da unidade sensor-emissor até o ponto de recepção em intervalos de tempo médios T. As informações são transmitidas no protocolo em t_p tempo de duração;
• qualquer sensor selecionado começa a transmitir aleatoriamente em tempos de Poisson. PASTA (Poisson Arrivals See Time Averages) será usado para justificar o envio de sondas em épocas de Poisson;
• todas as unidades sensor-emissor permanecem aleatoriamente independentes e irão transmitir as informações em um momento de tempo selecionado aleatoriamente de t_p duração e de T tempo médio de repetição;
• se um ou mais sensores começarem a transmitir enquanto o protocolo de t_p a duração está sendo transmitida de outro sensor, tal situação é chamada de colisão. A colisão torna impossível para a estação base central receber as informações de maneira correta.

Ele se encaixa quase perfeitamente com a rede de sensores que desejo testar …

Quase.

Não estou dizendo que entendi completamente a matemática do artigo, mas com base nos dados apresentados e nas conclusões, pude entender um pouco do que se trata. A única coisa é que um valor utilizado no papel me preocupou um pouco:). É a variável t_p - duração da transmissão de dados que se presume ser 3,2x10^-5 s. Portanto, o tempo de transmissão dos dados coletados seria de 3,2 nós! Isso não pode ser feito na banda de 433 MHz. Quero usar o rcswitch ou o radiohead para programar os sensores do transmissor. Estudando os códigos das duas bibliotecas, cheguei à conclusão que o menor tempo de transmissão seria de 20ms, bem acima do valor de 3,2 us. Com os transmissores de 2,4 GHz, é possível t_p tempo tão pequeno … mas isso é outra história.

Se aplicarmos a fórmula proposta pelos autores deste artigo, o resultado será:

Dados iniciais (um exemplo):

• Número de sensores N = 20;
• Duração da transmissão de dados t_p= 20x10^-3 s (0.020s)
• Intervalo médio de transmissão T = 180s

A fórmula:

A probabilidade de colisão no intervalo T é

se levarmos em consideração os dados iniciais, a probabilidade de colisão no intervalo T será de 0,043519

Este valor, que indica a probabilidade de ter 4,35 colisões por 100 medições, é, na minha opinião, muito bom. A probabilidade pode aumentar se aumentarmos o tempo médio de transmissão, portanto, com um valor de 300s, teremos uma probabilidade de 0,026332, ou seja, 2,6 colisões por 100 medições. Se considerarmos que podemos esperar perda de pacote de dados de qualquer maneira durante a operação do sistema (dependendo das condições climáticas, por exemplo), então este número é realmente excelente.

Eu queria fazer uma simulação deste tipo de rede, mas também uma espécie de assistente de design, então fiz um pequeno programa em C, você pode encontrar o código-fonte no github (também um binário compilado que está rodando na linha de comando do Windows - liberar).

Dados de entrada:

• sensor_number - o número de sensores na rede;
• Measures_number - número de medições para simular;
• Average_transmission_interval - tempo médio entre as sucessivas transmissões de dados;
• transmissão_time - a duração efetiva da transmissão de dados.

Saída:

• o tempo de medição máximo calculado;
• a lista de colisões entre dois sensores;
• número de colisões;
• probabilidade teórica das colisões.

Os resultados são bastante interessantes:)

Chega de teoria, não gostaria de insistir mais na parte teórica, os artigos e o código-fonte são bastante eloqüentes, então é melhor eu ir para a implementação prática e efetiva da rede de sensores sem fio e para os resultados dos testes.

Etapa 2: Implementação Prática - o Hardware

Para sensores-transmissores, precisaremos dos seguintes componentes:

• Microcontrolador ATtiny85 1,11 $;
• Soquete de circuito integrado 8DIP 0,046 $;
• Sensor de temperatura / umidade DHT11 0,74 $;
• Módulo transmissor H34A 433 MHz 0,73 $;
• Suporte de bateria 4xAA com switch 1 $;

Total 3,63 $;

O receptor usado para os testes é um Arduino UNO (apenas para teste) e um módulo receptor H3V4F (0,66 $) com uma antena de arco barata (0,32 $).

Esquemas de sensor-remetente

As unidades transmissor-sensor são alimentadas por baterias 3xAA, 1,5v (no quarto compartimento do porta-baterias está o conjunto eletrônico). Como você pode ver, a fonte de alimentação do transmissor e o sensor de temperatura-umidade estão ligados ao pino PB0 do microcontrolador (o transmissor e o sensor são alimentados quando o pino é definido como ALTO). Portanto, quando o microcontrolador está no modo de hibernação, ele pode atingir um consumo de corrente de 4,7uA. Considerando que o tempo de despertar do transmissor-sensor seria de cerca de 3s (medição, transmissão etc.) e o tempo médio entre as transmissões de 180s (como no exemplo do capítulo anterior), as baterias devem resistir bastante. Com algumas baterias alcalinas de boa qualidade (ou seja, 2000 mAh), a autonomia pode ser superior a 10 meses, conforme calculado em omnicalculator.com (onde o consumo total de corrente é: sensor - 1,5 mA, módulo transmissor - 3,5 mA e microcontrolador ATtiny85 - 5 mA, total 10 mA)

Na foto abaixo você pode ver o conjunto sensor-emissor quase concluído.

Abaixo está a foto da unidade do receptor de teste.

Etapa 3: Implementação Prática - Software

O software carregado em execução no microcontrolador attiny85, principal componente das unidades sensor-remetentes, tem por objetivo ler os dados fornecidos pelo sensor, convertê-los para serem transmitidos por rádio e transmiti-los dentro de intervalos de tempo de Poisson (distribuição exponencial ou PASTA - Chegadas a Poisson Ver Médias de Tempo). Além disso, por meio de uma função simples, ele monitora o status das baterias e avisa se a tensão necessária para o sensor não for mais fornecida. O código-fonte está disponível no github. O código para o receptor de teste é muito simples, estou postando abaixo.

// biblioteca rcswitch modificada de https://github.com/Martin-Laclaustra/rc-switch/tree/protocollessreceiver// o código é uma versão modificada de exemplos da biblioteca rcswitch original #include RCSwitch mySwitch = RCSwitch (); dados longos sem sinal = 0; void setup () {Serial.begin (9600); mySwitch.enableReceive (0); // Receptor na interrupção 0 => que é o pino # 2} void loop () {if (mySwitch.available ()) {unsigned long data = mySwitch.getReceivedValue (); // output (mySwitch.getReceivedValue (), mySwitch.getReceivedBitlength (), mySwitch.getReceivedDelay (), mySwitch.getReceivedRawdata (), mySwitch.getReceivedProtocol ()); umidade interna = bitExtraído (dados, 7, 1); // menos 7bits significativos da posição 1 - primeiro bit mais à direita int temperature = bitExtracted (data, 7, 8); // próximos 7 bits da posição 8 para a direita e assim por diante int v_min = bitExtracted (data, 1, 15); int packet_id = bitExtraído (dados, 3, 16); // 3bits - 8 ids de pacote de 0 a 7 int sensor_id = bitExtracted (dados, 6, 19); // 6 bits para 64 IDs de sensor - total de 24 bits Serial.print (sensor_id); Serial.print (","); Serial.print (packet_id); Serial.print (","); Serial.print (temperatura); Serial.print (","); Serial.print (umidade); Serial.println (); mySwitch.resetAvailable (); }} // código de https://www.geeksforgeeks.org/extract-k-bits-given-position-number/ int bitExtracted (número longo sem sinal, int k, int p) {return (((1 (p - 1)));}

Tentei incluir tantos comentários quanto possível para tornar as coisas mais fáceis de entender.

Para depuração, usei a biblioteca serial do software e a placa de desenvolvimento attiny85 com o programador USBasp (veja também minhas instruções sobre isso). O link serial foi feito com o conversor Serial to TTL (com um chip PL2303) conectado aos pinos tortos (3 e 4) da placa de desenvolvimento (veja a imagem abaixo). Tudo isso foi de uma ajuda inestimável para completar o código.

Etapa 4: Resultados do teste

Criei 5 unidades de sensor-emissor que coletam e enviam valores medidos pelos sensores DHT11. Gravei e salvei as medidas, com a ajuda do receptor de teste e um programa de emulação de terminal (foxterm), durante três dias. Eu escolhi um intervalo de 48 horas para estudar. Não estava necessariamente interessado nos valores medidos (o sensor 2, por exemplo, mostra valores errados), mas no número de colisões. Além disso, os sensores foram colocados muito próximos (a 4-5 m) do receptor para eliminar outras causas de perda de pacotes. Os resultados do teste foram salvos em um arquivo cvs e carregados (veja o arquivo abaixo). Eu também carreguei um arquivo excel baseado neste arquivo csv. Eu fiz algumas capturas de tela para mostrar como é uma colisão (em meus testes, é claro), adicionei comentários também a cada captura de tela.

Você pode se perguntar por que eu não usei um serviço de carregador de dados, por exemplo, ThingSpeak. O fato é que tenho muitos registros, muitos sensores e dados chegando frequentemente em intervalos irregulares, e os serviços de IoT online só permitem dados em um determinado número de sensores e apenas em intervalos razoavelmente grandes. Estou pensando no futuro em instalar e configurar meu próprio servidor IoT.

No final, 4.598 medições em 5 unidades sensor-emissor (aprox. 920 / sensor) resultaram em um total de 5 colisões por um período de 48 horas (0,5435 colisões / 100 medições). Fazendo algumas contas (usando o programa wsn_test com dados iniciais: 5 sensores, tempo médio de 180s, tempo de transmissão de 110 ms), a probabilidade de colisão seria 0,015185 (1,52 colisões / 100 medições). Os resultados práticos são ainda melhores que os teóricos, não é?:)

De qualquer forma, também há 18 pacotes perdidos neste período, então as colisões realmente não importam muito nesse aspecto. Claro que o teste deve ser realizado por um período mais longo de tempo para obter os resultados mais conclusivos, mas na minha opinião é um sucesso mesmo nessas condições e confirma totalmente os pressupostos teóricos.

Etapa 5: considerações finais

Aplicação imediata

Em uma grande estufa, várias culturas são cultivadas. Se a irrigação for feita manualmente, sem monitoramento do clima, sem automação, sem registro de dados existe o risco de super ou subirrigação e também o consumo de água é alto, não há evidências de otimização do consumo de água, há risco para as lavouras em em geral. Para evitar isso, podemos usar uma rede de sensores sem fio:)

Sensores de temperatura, sensores de umidade do ar, sensores de umidade do solo podem ser colocados em toda a estufa e com a ajuda dos dados transmitidos várias ações podem ser feitas: válvulas elétricas start-stop para deixar a água fluir onde é necessário, ventiladores elétricos start-stop para reduzir a temperatura em áreas diferentes, aquecedores start-stop conforme necessário e todos os dados podem ser arquivados para análise futura. Além disso, o sistema pode fornecer uma interface da web acessível em qualquer lugar e alarmes por e-mail ou SMS em caso de condição anormal.

Qual é o próximo?

• Testando com um maior número de sensores;
• Teste em tempo real com sensores remotos na área de cobertura;
• Instalação e configuração de um servidor IoT local (em um Raspberry Pi, por exemplo);
• Testes também com transmissores (transceptores) -sensores em 2.4Ghz.

então … continua …:)

AVISO LEGAL: O uso da banda de frequência de 433 MHz em sua região pode estar sujeito a regulamentações de frequência de rádio. Por favor, verifique sua legalidade antes de tentar este projeto

Vice-campeão no concurso de sensores