Boa noite pessoal!

Peço socorro! Hehe não tenho mais nenhum alternativa que eu saiba para um problema que talvez seja comum. 

Atualmente estou usando um ESP32, preciso fazer leituras do sensor de temperatura DS18b20, consigo fazer as leituras usando as lib da Dallas (DallasTemperature) e uso o protocolo 1-wire.

Funciona praticamente 100% usando o cabo original que tem em torno de 1 metro de comprimento, no entanto preciso levar esse sensor ha uns 40m, usei um cabo LAN CFTV e os resultados foram péssimos, tenho como retorno quando requisito as temperaturas valor como -127.00 ºC ou 85.00 ºC e raramente valores que não são os reais como por exemplo uns 20 graus a mais da temperatura real.

Então decidi usar o CAT5 Blindado, já que esse cabo deve passar junto e/ou próximo a fios elétricos, usando esse cabo eu tive uma pequena melhora mas não resolveu, ainda recebo muuuitos erros ao ler as temperaturas. Esse cabo blindado estou usando da seguinte forma:

Pares verdes para o fio de dados; Pares azuis para o neutro; Pares marrom para o fase (3.3v); a blindagem capa metálica está devidamente aterrada.

Como pull-up estou usando um resistor 4k7 que fica ao lado do ESP. Já testei usando o resistor próximo ao DS18b20 e o resultado foi o mesmo.

Eu acredito que seja interferência da rede elétrica, ou impedância do cabo mas não faço a mínima ideia de como melhoras essas leituras. 

Alguém já passou por essa situação ou possui alguma ideia de como resolver, algum tipo de filtro talvez?

EDIT:

Conclusão, pessoal, acabei de testar com 43 unidades ESP32.

Para realizar as leituras do sensor ds18b20 enquanto a wifi do ESP está ativa é necessário que a rotina de leitura esteja sendo executada no Core1 do ESP.

Sendo assim, nas 43 unidades testadas, TODAS tem leitura livre de erros quando executadas no Core1.

Quando as leituras ocorrem no Core0, ao usar a wifi, o ESP consegue ler o sensor somente as vezes. 

Dispenso a ideia de ter vindo um lote de ESP com problema, pois meus ESP's foram adquiridos de diferentes estados/locais.

Em outros fórum este problema já foi relatado e resolvido da mesma maneira, então deixo aqui a conclusão para quem busca um resultado rápido, talvez não seja a melhor forma mas resolveu.

Se alguém tiver outra sugestão, estou disposto a testar.

Um grande abraço, e obrigado à todos pelas sugestões!

Exibições: 1165

Responder esta

Respostas a este tópico

olá Mateus.

      Vi que usando o exemplo do site RandomNerds,  vc conseguiu fazer os ESP32 funcionarem com o Sensor, sem apresentar problemas de leitura.

      Isto vai de encontro ao que mencionei no post anterior, sobre ainda existir uma possibilidade de solucionar a questão.

      Esta possibilidade reside em inicializar adequadamente o Sistema de forma a encontrar os Sensores no barramento "One Wire",  e subsequentemente acessar esses sensores em um processo confiável, executando corretamente as operações de leitura do Sensor.

      Assim, baseado no código que vc postou aqui (o "DB18B20 código.ino"), fiz uma implementação bastante robusta do Sistema.

      Essa implementação permite vc facilmente acrescentar as demais tarefas de processamento para os valores obtidos da temperatura  (o que provavelmente vc faz através de algum "server" implementado no ESP32  com respectivo protocolo). O código implementado está no final deste post, para download.

      Como vc tem formação em Ciência da Computação, acredito que não precise de esclarecimentos adicionais sobre o funcionamento dessa implementação. Além disso todo o código está comentado funcionalmente, e totalmente organizado (inclusive em termos de hierarquia). Mas caso tenha algum ponto que vc deseje esclarecimento adicional, basta perguntar aqui.

      Ainda assim, mostrando aqui alguns pontos, acredito poupará tempo pra vc. Os principais settings do Sistema, vc encontrará logo no início do código, facilmente identificáveis (ex.: definição do pino do ESP32  onde o Sensor DS18B20  está conectado).

      Outro ponto, é no seu Task de nome "taskDim", que trata os valores de temperatura. Este Task pode ser visto na figura a seguir:

(clique na figura para "zoom")

      Na figura anterior, na área marcada em azul, é feito todo o gerenciamento do Sensor DS18B20.  Isto inclui detectar o Sensor, obter seu endereço no barramento "One Wire", e subsequentemente fazer leituras assíncronas  dos valores de temperatura.  Na detecção do Sensor, também há um mecanismo que informa vc quantas tentativas foram feitas para encontrar o Sensor, informando também o endereço do mesmo (quando detectado). Funcionalmente, é uma Máquina de Estados  que gerencia todo o processo.

      Na área marcada na cor amarela, é informado via Serial  do Arduino, a temperatura lida do SensorImportante notar, que logo após o Sensor ser detectado,  as primeiras leituras podem ser inválidas, pois o Sensor propriamente dito pode levar vários segundos para estar "pronto" para conversão (mas apenas após a detecção inicial).

      Na área marcada em verde, corresponde àquele trecho no seu código original, que faz um processamento específico quando a temperatura está dentro de uma faixa. Então é só vc acrescentar ali o código para isto.

      Já em relação ao Task de nome "taskConn" para tratamento da conexão WiFi, ele é mostrado na figura a seguir:

(clique na figura para "zoom")

      Na figura anterior, na área marcada em azul,  é feito todo o processamento para a conexão WiFi, de uma forma temporizada. Ali é setado o modo de operação (no caso, "STATION"), e aguardado que a conexão seja inicialmente estabelecida. Todo o processamento também é feito por uma Máquina de Estados. Embora não tenha sido implementado um código específico,  ao analisar o funcionamento vc verá que já está preparado para executar ações no Sistema para o caso de eventual perda da conexão  WiFi (veja no estado "WiFi_ready").

      A área marcada em verde, corresponde justamente ao restante do processamento do seu código, que ao que vc deixou a entender é a manipulação de um Banco de Dados (provavelmente com histórico das temperaturas e outros dados). Então está fácil de vc incluir isso ali.

      O código foi testado e está funcionando perfeitamente. Mas é claro que um retorno da sua parte sobre resultados de sua implementação particular, poderá ajudar outras pessoas que estejam visitando este tópico.

      Uma dica:  embora no "background" o ESP32  esteja executando um RTOS,  onde seus tasks são executados rotineiramente,  aconselho evitar usar "delays" e "loops infinitos " dentro dos tasks (como while(true)  ), pois estes fazem com que o RTOS  avalie de forma errônea o tempo de processamento gasto, resultando em algo próximo a 100% de uso, quando na realidade o percentual efetivo é muito menor (exatamente como nos códigos executados no PC, quando códigos pequenos e simples parecem usar 100% da CPU).

      O código implementado está aqui:   "DS18B20_ESP32_teste_02.zip"

      Espero ter ajudado. Qualquer dúvida que esteja a meu alcance, pergunte aqui.

      Abrçs,

      Elcids

Boa tarde Elcids,

Primeiramente, parabéns pelo seu código, muito bem organizado! 

Elcids, tive alguns problemas em executar seu código, como mencionado por você mesmo o "background" do ESP é FreeRTOS, dessa forma no FreeRTOS nenhuma tarefa pode terminar sem algum "retorno" dito isso precisamos chamar um "vTaskDelete(NULL);" antes que ela chegue ao fim ou até mesmo usar um loop infinito (que é o que eu faço)  para manter a execução. Caso a tarefa termine sem uma chamada ao método de delete o ESP reinicia continuamente (foi o que aconteceu comigo utilizando seu código) conforme imagem abaixo.

Caso optarmos por finalizar a tarefa a mesma precisa ser criada novamente utilizando o "xTaskCreate..." para que execute mais "n" vezes quantas forem necessárias. Ou utilizaremos um loop infinito para que a tarefa nunca termine e fique sempre em execução, neste caso se torna "obrigatório" alimentar o contador interno do ESP dentro do loop infinito, quando chamamos "delay(1)" o contador interno é automaticamente alimentado, o delay chama "vTaskDelay (x) ". Há outras formas de resolvermos esse problema do watchdog, mas esta acredito ser a mais simples. Se não utilizarmos um delay o ESP também reiniciará, conforme imagem abaixo. 

Dito isso, optei por colocar um loop infinito no seu código, após isso o ESP não reinicia mais e segue executando o seu código normalmente. No entanto, os erros ainda persistem (descobri uma possível solução, ainda não sei se é válida para todos os ESP, irei testar mais...). Ao usar a wifi, o seu código também apresenta falhas de leituras.

Uma solução por mim encontrada, que funciona tanto no seu código quanto no meu, é inverter as tarefas atreladas aos núcleos. Usamos o Core0 para a "taskDim" e usamos o Core1 para a "taskConn". Se invertermos os núcleos, funciona perfeitamente sem erros de leituras, ainda não sei o porque, mas funciona.

Dessa forma, usarei então a "taskDim" no Core1 e a "taskConn" no Core0. Pelos testes que fiz funciona, conforme imagem abaixo.

Resumindo, a solução que encontrei foi essa, agora basta saber se é válida para todos os meus ESP's.

Antes era:

"xTaskCreatePinnedToCore( taskConn, "taskConn", 10000, NULL, 2, NULL, 1);"
"xTaskCreatePinnedToCore( taskDim, "taskDim", 10000, NULL, 1, NULL, 0);"

e agora passa a ser:

"xTaskCreatePinnedToCore( taskConn, "taskConn", 10000, NULL, 2, NULL, 0);"
"xTaskCreatePinnedToCore( taskDim, "taskDim", 10000, NULL, 1, NULL, 1);"

OBS.: Vi que usa seções criticas no seu código "portENTER_CRITICAL...", as mesmas não podem serem utilizadas no meu modelo atual pois uso interrupções externas (rede elétrica quando passa pelo ponto 0 - zero cross para controle do TRIAC), se houver uma interrupção externa enquanto estou em uma seção critica o ESP reinicia.

olá Mateus.

      Fiz uma análise sobre diversos pontos relacionados, e obtive algumas conclusões. Algumas são óbvias, e outras nem tanto. Mas algumas certamente são importantes.

      Peço que deixe o tópico aberto,  pois assim que possível, irei postar sobre estas análises (além do texto, ainda tenho que capturar e preparar algumas figuras para isso).

      abrçs,

      Elcids

Conclusão, pessoal, acabei de testar com 43 unidades ESP32.

Para realizar as leituras do sensor ds18b20 enquanto a wifi do ESP está ativa é necessário que a rotina de leitura esteja sendo executada no Core1 do ESP.

Sendo assim, nas 43 unidades testadas, TODAS tem leitura livre de erros quando executadas no Core1.

Quando as leituras ocorrem no Core0, ao usar a wifi, o ESP consegue ler o sensor somente as vezes. 

Dispenso a ideia de ter vindo um lote de ESP com problema, pois meus ESP's foram adquiridos de diferentes estados/locais.

Em outro fórum este problema já foi relatado e resolvido da mesma maneira, então deixo aqui a conclusão para quem busca um resultado rápido, talvez não seja a melhor forma mas resolveu.

Se alguém tiver outra sugestão, estou disposto a testar.

Um grande abraço, e obrigado à todos pelas sugestões!

Que bom que resolveu o problema e divulgou a solução para todos. 

Obrigado. 

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço