Diário da EMM OraProNobis CTA

Adicionado por Leonardo Sehn 6 meses atrás

Manutenção da OraProNobis CTA

A partir de agora a manutenção da OraProNobis CTA passa a ser relatada por aqui. A ideia é fazer um acompanhamento com relato semanal sobre a EMM, formato que também será aplicado para a EMM Butiá INMET neste fórum.

As atualizações sobre a OraProNobis foram feitas pela tarefa #484 até o dia 02/02/2018 (Semanas 1 a 4). Naquela situação, a OraProNobis foi considerada uma EMM estável, por ter enviado dados ininterruptamente por cerca de duas semanas.

Abaixo segue um resumo de informações importantes sobre o período relatado (cheio de spoilers), seguido de um relato detalhado, formato que consiste no modelo elaborado.


Resumo

Período: Semanas 4 a 9 (02/02/2018 a 06/03/2018)
Idade: 57 dias

Dados do Período

Maior período de dados registrados: ~ 10 dias e meio (20:22 de 23/02 às 13:00 de 06/03)[Diversas falhas do DHT22 nesse intervalo]
Maior período de funcionamento pleno: ~ 3 dias e meio (00:00 de 02/02 às 12:01 de 05/02)[Continuação do período anterior]
Maior período de envio de dados para o servidor: ~ 10 dias e meio (20:22 de 23/02 às 13:00 de 06/03)[Diversas falhas do DHT22 nesse intervalo]
Maior período de dados registrados no cartão: ~ 6 dias e meio (00:00 de 02/02 às 14:23 de 08/02)[Continuação do período anterior]
Manutenções: 3 (bem-sucedidas)
Dias de dados registrados: 02/2 (dht) a 08/2 (i), 09/2 (m/w+sd), 10/2 (w+sd) a 14/2 (i/w+sd), 17/2 (i/dht), 18/2 (dht), 19/2 (dht), 20/2 (i/dht), 21/2 (i), 22/2, 23/2 (m) a 01/3 (dht), 02/3, 03/3 (dht), 04/3 (dht), 05/3 (dht), 06/3 (dht).

i = interrupção (genérica)
m = manutenção
w+sd = problemas conjuntos de comunicação WiFi com o servidor e de registro com cartão SD
dht = falhas no sensor DHT22

Registro integral de dados: 16 dias
Registro de dados com interrupções: 15 dias
Sem registro de dados: 2 dias
Total: 33 dias

Conclusões

  • Do dia 18/02 à tarde do dia 23/02 (cerca de 5 dias e meio) temos dados com divergência de horário com relação ao horário local devido à demora no reajuste do relógio da OraProNobis
  • Este período apresentou longos intervalos de tempo com problemas nos dados, causados por três motivos principais:
    • Uma chuva histórica em Porto Alegre, que possivelmente danificou o sensor DHT22, seguido de um longo período de observação antes de decidir pela troca do sensor
    • Um problema no módulo microSD, que também foi observado por um longo período de tempo antes de ser trocado
    • Problemas de mau contato no modem WiFi da rede à qual a OraProNobis conecta-se
  • Os dados de temperatura e especialmente de umidade relativa do ar a partir do dia 09/02 não são plenamente confiáveis, devido à falha do sensor DHT22
  • Não cadastrar medidas de temperatura do BMP foi um erro, pois poderia ter ajudado nas comparações nos casos de falha do sensor DHT22

Pendências

  • Trocar sensor DHT22
  • Verificar e potencialmente trocar módulo microSD

Dados Históricos

Maior período de dados registrados: ~ 19 dias (22:57 de 20/01 a 18:31 de 08/02)
Maior período de funcionamento pleno: ~ 11 dias e meio (22:57 de 20/01 a 12:09 de 01/02)
Maior período de envio de dados para o servidor: ~ 15 dias e meio (22:57 de 20/01 a 12:01 de 05/02)
Maior período de dados registrados no cartão: ~ 11 dias e meio (22:57 de 20/01 a 12:09 de 01/02)
Manutenções: 6 (bem sucedidas)
Dias de dados registrados:
  • Janeiro: 09/1 (m) a 12/1 (m), 13/1 a 14/1 (i), 15/1 (i/m), 16/1 (i), 17/1 a 19/1 (w+sd), 20/1 (m) a 31/1.
  • Fevereiro: 01/2 a 02/2 (dht), 03/2 a 08/2 (i), 09/2 (m/w+sd), 10/2 (w+sd) a 14/2 (i/w+sd), 17/2 (i/dht), 18/2 (dht), 19/2 (dht), 20/2 (i/dht), 21/2 (i), 22/2, 23/2 (m) a 28/2.
  • Março: 01/3 (dht), 02/3, 03/3 (dht), 04/3 (dht), 05/3 (dht), 06/3 (dht).

i = interrupção (genérica)
m = manutenção ou instalação
w+sd = problemas conjuntos de comunicação WiFi com o servidor e de registro com cartão SD
dht = falhas no sensor DHT22

Registro integral de dados: 33 dias
Registro de dados com interrupções: 22 dias
Sem registro de dados: 2 dias
Total: 57 dias


Relato

Semanas 4 e 5 (02/02 a 10/02)

Imagem da EMM OraProNobis no dia 09 de Fevereiro de 2018

Imagem da EMM OraProNobis durante o dia 09 de Fevereiro de 2018

A partir do dia 02/02, a OraProNobis seguiu enviando dados de maneira ininterrupta por mais 3 dias, quando interrompeu a série de 16 dias às 12:01 do dia 05/02. Deste momento até às 11:41 do dia 08/02 (cerca de 3 dias) seguiu registrando os dados no microSD, o que foi apurado posteriormente. Os arquivos de dados da OraProNobis se encontram em anexo ao relato. Então voltou a se comunicar com o servidor, enviando os dados, sem necessidade de intervenção.

É válido ressaltar que no dia 06/02 às 22:06 passaram-se cerca de 45 segundos sem registros de medidas, momento em que possivelmente o sistema passou por algum mau contato. Também foi durante esse período inicial, às 19:56 e às 19:57 que ocorreram as primeiras falhas no sensor DHT22, com três pontos de medida prejudicados. Este erro ocorreu 3 horas depois de o sensor atingir uma medida de umidade relativa do ar de 16,2 % e entrar em um padrão de aumento da umidade nos minutos seguintes, quando abruptamente ocorreram três medidas de 0 % de umidade relativa do ar. A OraProNobis nunca havia atingido um patamar tão baixo de medida de umidade relativa do ar. Essa faixa de umidade relativa do ar é considerada um estado de alerta por órgãos de gerenciamento de emergências e é prejudicial à saúde segundo a OMS.

Medidas de umidade relativa do ar criticamente baixas registradas pela EMM OraProNobis CTA

Durante o dia 08/02, houve uma série de acontecimentos:

  • Primeiramente, às 14:23 os dados pararam de ser registrados no cartão microSD. Uma série de caracteres "ÿÿÿÿ" foram registrados no final do arquivo e nenhum dado a mais foi salvo.
  • Mais tarde no mesmo dia, das 18:31 às 20:27, das 21:11 às 21:41, das 21:45 às 22:39 e das 23:29 às 23:38 ocorreram paradas na comunicação com o servidor. Isso somado à parada no registro dos dados no cartão levou à perda completa de dados nesses quatro períodos, que totalizam cerca de 3 horas e meia. Não se sabe se essas paradas foram falhas no sistema ou quedas de luz ou internet.

Sequência de dados de umidade relativa do ar da EMM OraProNobis CTA com destaque para o vale observado no dia 02 de Fevereiro de 2018.

Sequência de umidade relativa do ar de 02 a 12 de Fevereiro de 2018

No dia 09/02, foi feita uma manutenção de rotina no sistema para verificar seu funcionamento, a partir da leitura dos dados do microSD. Neste processo, foi feita uma série de paradas no sistema:

  • Das 15:16 às 15:27.
  • Das 15:30 às 15:33.
  • Das 15:36 às 15:40.
  • Das 15:40 às 15:43.
  • Das 15:43 às 16:07.

5 paralizações que totalizam cerca de 40 minutos sem registro de dados. Então o sistema foi reestabelecido e enviou dados por 8 minutos (até às 16:15), quando uma intervenção na tomada para alimentação do modem WiFi foi realizada por "outre colaboradore" do CTA, causando a interrupção na comunicação com o servidor.

O reestabelecimento do sistema foi feito logo antes de uma tempestade de vento e chuva muito intensa em Porto Alegre, o que causou danos e problemas a vários serviços na cidade. Isso pode ter causado danos ao sistema, e novos registros no cartão começaram a ser feitos no cartão a partir das 23:01. Ainda assim, acredita-se que o sistema estava funcionando antes disso, pois o registro de começo de funcionamento do logger não foi registrada neste horário, o que indica que o logger estava ativado anteriormente.

No dia 10/2, às 08:14, houve uma falha no registro dos dados no cartão, momento em que foram salvos uma série de caracteres de erro, que ficam registrados como uma série de caracteres "\00\00". Este erro parou às 10:39, cerca de duas horas e meia depois, quando o registro no cartão voltou a funcionar normalmente.

Semana 6 e 7 (11/02 a 24/02)

Esta condição seguiu até o dia 12/2, quando às 12:54, a comunicação com o servidor também voltou, após intervenção de "outre colaboradore" do CTA para retomar a comunicação WiFi, encerrando a série de cerca de 3 dias sem envio de dados. Nesse dia, foi observado novamente um comportamento estranho na medida de umidade relativa do ar com o sensor DHT22, quando às 22:06 houve uma oscilação de 99,9 % para 0 % e então novamente 99,9 %, o que demonstra uma falha no sensor. Outro comportamento como esse ocorreu às 00:43 do dia 13/02, cerca de 3 horas depois, quando uma oscilação de 99,9 % para 1738,3 % e novamente para 99,9 % foi registrada, caracterizando-se como uma nova falha no sistema.

Dados de umidade relativa do ar da EMM OraProNobis de 13 de Fevereiro de 2018 com destaque para o pico e o vale observados

Sequência de dados de umidade relativa do ar com oscilações intensas e sem sentido, com saturações do sensor.

Detalhe para o pico de pressão atmosférica com valor surreal.

Essa comunicação com o servidor seguiu acontecendo até às 20:35 do dia 14/2, quando esta série de cerca de 2 dias e meio de envio de dados foi interrompida, às 20:35. Nesse meio tempo, ocorreram três paradas curtas, das 17:30 às 17:34, das 17:35 às 17:39 e das 17:41 às 17:43 no envio dos dados e uma parada de registros no cartão, a partir das 17:56.

Inspeção realizada durante o dia 14 de Fevereiro de 2018

Quando o cartão foi retirado para inspeção dias depois, verificou-se que o arquivo apresentava um erro na sua abertura com aviso para a presença de caracteres inválidos. A partir de então foram feitas duas tentativas de registro de dados com o cartão microSD, uma delas causou erro de leitura no cartão e outra ainda não foi verificada. Não há dados mais recentes do que estes extraídos de cartões de memória.

No dia 17/02 às 14:57, a comunicação com o servidor voltou sem intervenção, pondo fim a cerca de dois dias e meio sem dados. Logo nessa retomada, houve uma parada de cerca de uma hora, das 14:57 às 15:48. Neste dia, falhas no DHT22 voltaram a ocorrer, com quedas abruptas para 0 % de umidade acompanhadas por interrupções nas medidas de temperatura. Das 18:56 às 19:00 foram duas falhas curtas e então ocorreu uma mais longa, com interrupção até às 19:22. Então às 20:45 houve nova falha, com retorno às 08:27 do dia 18/02. Então às 17:19 apresentou uma falha com interrupção de 4 minutos e às 17:52 uma interrupção longa até às 20:06. No dia 19/02 houve nova interrupção longa, às 01:00, que se estendeu até o dia 20/02, até às 03:01, numa longa série sem dados do DHT22. Então às 08:25 houve nova falha, com interrupção até às 08:44.

A despeito dessas falhas no DHT22, a comunicação seguiu até o dia 20/02, às 17:47, completando cerca de 3 dias de envios de dados.

No dia seguinte, 21/02, às 11:39, os dados voltaram a ser enviados ao servidor, encerrando uma sequência de mais de meio dia sem dados. O envio seguiu até o dia 23/02, às 16:38, completando mais cerca de dois dias com envio de dados. Neste momento, foi feita mais uma manutenção de rotina para conferir o funcionamento do sistema e também realizar a atualização para o horário local de inverno.

A manutenção foi realizada e o sistema efetuou às 20:11 uma medida não representativa, com 234963 Pa de pressão atmosférica. O funcionamento do sistema foi reestabelecido de fato às 20:22 com o horário corrigido.

Dados de pressão atmosférica da EMM OraProNobis CTA durante o dia 24 de Fevereiro de 2018 com destaque para o pico de valor absurdo medido

Medida absurdamente alta de pressão atmosférica realizada no dia 24 de Fevereiro, provavelmente por umidade no sensor.

Semanas 8 e 9 (25/02 a 06/03)

A partir de então, a OraProNobis seguiu enviando dados ao servidor até o dia 06/03 às 13:00, completando cerca de 10 dias de envio de dados. Ainda não foi verificado se foram registrados dados no cartão desde o dia 23/02 até agora.

Neste último período de medidas, ocorreram falhas nas medidas com o sensor DHT22 em quatro ocasiões, com interrupções nas suas medidas no dia 01/03 das 19:10 às 20:11, do dia 03/03 às 19:48 ao dia 04/03 às 03:34, do dia 04/03 às 15:58 até o dia 05/03 às 01:19 e do dia 05/03 às 18:55 até o dia 06/03 às 05:31. Ainda houve uma situação, no dia 28/02, às 21:08, em que o sensor realizou uma medida não realística de 199,8 % de umidade relativa do ar, com interrupção de uma medida de temperatura.

Sequência de dados de temperatura da EMM OraProNobis CTA de 13 de Fevereiro a 06 de Março de 2018 com destaque para a série de interrupções sofridas

Interrupções nas medidas de temperatura com destaque para a ocorrida no dia 17 de Fevereiro

É interessante ressaltar que, ao passo que as medidas de temperatura sofriam interrupções, as medidas de umidade sofriam saturações abruptas na forma de picos ou vales de medida. Nas últimas falhas, as medidas de temperatura retornaram com quedas pronunciadas na temperatura no começo das séries de medida. Além disso, as medidas de umidade passaram a estar saturadas na maior parte do ciclo diurno, em contraste com o que acontecia antes de começarem as falhas.

Por todas esses indícios, acredita-se que o sensor DHT22 tenha sido danificado e deva ser substituído. Não foi possível correlacionar a incidência do defeito com alguma chuva ou fenômetro extremo no momento dos picos surreais de umidade relativa do ar. As medidas de precipitação e umidade instantânea da estação automática do INMET (também em anexo) não corroboraram com essa hipótese, e foram consideradas insuficientes para essa verificação. A falta de registro dos dados de temperatura com o BMP180 foi identificada como um erro de cadastro da EMM, que poderia ter ajudado na comparação entre os dados dos sensores.

Uma hipótese é de que o defeito tenha sido causado pela chuva do dia 09/2, pois o comportamento defeituoso ocorreu pela segunda vez na madrugada do dia 11/2, cerca de um dia depois de o sistema voltar a funcionar após ser interrompido pela chuva. Os dados de precipitação para as 17:00 pelo horário de Brasília, período em que ocorreu a chuva, registraram 24,6 mm de chuva. Portanto, acredita-se que esse fenômeno tenha danificado o DHT22, o que teria se manifestado apenas 32 horas mais tarde. Acredita-se que o posicionamento do DHT22 dentro do abrigo, com fixação próxima à parede do abrigo tenha facilitado a incidência da danificação, sendo que o BMP180 seguiu funcionando normalmente, mesmo que a priori tenha menos proteções do que o outro sensor.

Outra hipótese é de que a falha tenha sido causada pelo patamar de umidade muito baixo atingido na tarde do dia 02/02, logo antes da primeira vez que ocorreu falha no sensor DHT22. Embora a ficha técnica do sensor indique que ele suporta tais condições, este nível de umidade pode ter excedido a condição de operação do sensor, provocando um dano que foi percebido poucas horas depois.

Seguem abaixo imagens dos dados enviados ao servidor para cada um dos parâmetros ao longo do período relatado e do período completo desde a instalação da OraProNobis CTA.

Sequência de dados de pressão atmosférica da EMM OraProNobis CTA de 02 de Fevereiro a 06 de Março de 2018

Sequência de dados de Pressão Atmosférica

Sequência de dados de temperatura da EMM OraProNobis CTA de 02 de Fevereiro a 06 de Março de 2018

Sequência de dados de Temperatura

Sequência de dados de umidade relativa do ar da EMM OraProNobis CTA de 18 a 24 de Fevereiro de 2018

Sequência de dados de Umidade Relativa do Ar

Sequência de dados Luminosidade

DATALOG_2018_2_9_2018_2_14.TXT - Dados da EMM OraProNobis CTA de 09 de Fevereiro de 2018 a 14 de Fevereiro de 2018. (796,5 KB)

dados_inmet_2018_2_9_2018_3_6.md - Dados da estação do INMET de 09 de Fevereiro de 2018 a 06 de Março de 2018. (61,2 KB)

13Fev_umidade_pico_vale.png - Dados de umidade relativa do ar da EMM OraProNobis de 13 de Fevereiro de 2018 com destaque para o pico e o vale observados (60,7 KB)

02Fev_12Fev_umidade_vale.png - Sequência de dados de umidade relativa do ar da EMM OraProNobis CTA com destaque para o vale observado no dia 02 de Fevereiro de 2018. (75,9 KB)

24Fev_pressao_pico.png - Dados de pressão atmosférica da EMM OraProNobis CTA durante o dia 24 de Fevereiro de 2018 com destaque para o pico de valor absurdo medido (69,5 KB)

18Fev_06Mar_umidade_pico_vales_interrupcoes.png - Sequência de dados de umidade relativa do ar da EMM OraProNobis CTA de 18 a 24 de Fevereiro de 2018 (74,7 KB)

13Fev_06Mar_temperatura_serie_interrupcoes.png - Sequência de dados de temperatura da EMM OraProNobis CTA de 13 de Fevereiro a 06 de Março de 2018 com destaque para a série de interrupções sofridas (90,7 KB)

09Fev_OraProNobis.png - Imagem da EMM OraProNobis no dia 09 de Fevereiro de 2018 (706,3 KB)

02Fev_06Mar_temperatura.png - Sequência de dados de temperatura da EMM OraProNobis CTA de 02 de Fevereiro a 06 de Março de 2018 (95,8 KB)

02Fev_06Mar_pressao_sequencia.png - Sequência de dados de pressão atmosférica da EMM OraProNobis CTA de 02 de Fevereiro a 06 de Março de 2018 (85,5 KB)


Respostas (2)

RE: Diário da EMM OraProNobis CTA - Adicionado por Leonardo Sehn 6 meses atrás

Registro do período do dia 07 de Março a 02 de Junho de 2018.

Resumo

Período: Semanas 10 a 21 (07/03/2018 a 02/06/2018)
Idade: 145 dias

Dados do Período

Maior período de dados registrados: ~ 2 dias (14:31 de 06/04 às 16:31 de 08/04)
Maior período de funcionamento pleno: Não aconteceu, pois servidor está com defeito.
Maior período de envio de dados para o servidor: Idem.
Maior período de dados registrados no cartão: ~ 2 dias (14:31 de 06/04 às 16:31 de 08/04)
Manutenções: 3
  1. Dia 16/3: mal-sucedida
  2. Dia 06/4: bem-sucedida
  3. Dia 02/6: mal-sucedida

Dias de dados registrados: 16/3 (m/i/dht), 17/3 (i/dht), 6/4 (m/i), 7/4, 8/4 (i)

i = interrupções ocorreram
m = manutenção ou instalação
dht = problemas com o DHT

Registro integral de dados: 1 dia.
Registro de dados com interrupções: 4 dias.
Sem registro de dados: 83 dias.

Conclusões

  1. O primeiro processo de manutenção consistiu em tentar fazer uma substituição de DHT, que havia sido danificado pela chuva. Devido a uma sequência de erros nas conexões dos fios do sensor com a placa, o processo não foi devidamente concluído nesse dia.
  2. A segunda manutenção tinha como objetivo fazer uma inspeção minuciosa para tentar identificar o erro, e acabou evidenciando esse simples erro. Com a resolução dessa questão de crimpagem do cabo do sensor no RJ11, o sistema voltou a funcionar normalmente. Os dados obtidos com o DHT22 até esta segunda manutenção não podem ser considerados válidos, pois o sensor foi claramente danificado.
  3. A terceira manutenção foi feita para tentar resolver problemas no cartão microSD, que juntamente com os problemas evidenciados no servidor, estavam levando à perda de séries de dados. Em mais de uma oportunidade, o arquivo de dados registrado no cartão passa a exibir caracteres estranhos ou então o próprio cartão é corrompido. Mesmo com uma série de tentativas de recuperar o cartão, não foi possível reestabelecer o funcionamento a ponto de voltar a ser usado na EMM e no momento os dados não estão sendo registrado, há apenas a exibição da informação instantânea no servidor. Essa é uma questão de urgência que deve ser encarada para retomar o funcionamento da OraProNobis.
  4. Devido a outros focos do projeto, fiquei muito tempo sem fazer manutenções nas EMMs. Isso deve ser ajustado e as manutenções devem ser mais recorrentes a partir de agora.

Pendências

A resolução do problema de registro dos dados segue pendente.

Ações planejadas

Para resolver esta questão, são planejadas três possíveis abordagens:

  1. Inclusão de novos filtros próximos ao módulo microSD: É possível que as informações espúrias registradas no cartão sejam devido a interferências eletromagnéticas no módulo microSD, incluir filtros RF nas trilhas próximas ao módulo poderiam garantir proteção a mais contra esse tipo de interferência. Essa abordagem assume o hardware como fonte de erros.
  2. Utilização de cartões de classe 10: O modelo comercializado comumente é o cartão microSD classe 4. Quanto maior a classe, melhor o funcionamento quanto a gravações sucessivas de informações no cartão. Os classe 10 são os mais altos. Essa abordagem assume que a fonte de erros é o cartão.
  3. Inspeção e correção do firmware: A última abordagem e mais trabalhosa é uma verificação profunda no firmware para ver se há possibilidade de o próprio programa eventualmente levar a escrever informações espúrias no cartão. Essa abordagem assume o firmware como fonte de erros.

As abordagens serão aplicadas na ordem descritas, pela praticidade da aplicação.

Dados históricos

Maior período de dados registrados: ~ 19 dias (22:57 de 20/01 a 18:31 de 08/02)
Maior período de funcionamento pleno: ~ 11 dias e meio (22:57 de 20/01 a 12:09 de 01/02)
Maior período de envio de dados para o servidor: ~ 15 dias e meio (22:57 de 20/01 a 12:01 de 05/02)
Manutenções: 9 (7 bem sucedidas e 2 mal sucedidas)
Dias de dados registrados:
  • Janeiro: 09/1 (m) a 12/1 (m), 13/1 a 14/1 (i), 15/1 (i/m), 16/1 (i), 17/1 a 19/1 (w+sd), 20/1 (m) a 31/1.
  • Fevereiro: 01/2 a 02/2 (dht), 03/2 a 08/2 (i), 09/2 (m/w+sd), 10/2 (w+sd) a 14/2 (i/w+sd), 17/2 (i/dht), 18/2 (dht), 19/2 (dht), 20/2 (i/dht), 21/2 (i), 22/2, 23/2 (m) a 28/2.
  • Março: 01/3 (dht), 02/3, 03/3 (dht), 04/3 (dht), 05/3 (dht), 06/3 (dht), 16/3 (i/dht), 17/3 (i/dht).
  • Abril: 6/4 (i), 7/4, 8/4 (i).

i = interrupção (genérica)
m = manutenção ou instalação
w+sd = problemas conjuntos de comunicação WiFi com o servidor e de registro com cartão SD
dht = falhas no sensor DHT22

Registro integral de dados: 34 dias
Registro de dados com interrupções: 26 dias
Sem registro de dados: 85 dias
Total: 145 dias


Relato

Semanas 9 e 10 (07/03 a 17/03)

Preparação do suporte do DHT22

Nesse período a EMM OraProNobis esteve sujetia ao defeito no DHT22, causada pela tempestade ocorrida no mês anterior. Nessa manutenção foi feito um suporte de PVC para o sensor DHT22 para fixá-lo no centro do abrigo e melhor protegê-lo da chuva, por mais forte que seja. Para esse processo foi necessário:

  • Um pedaço de tubo PVC
  • Uma serrinha de mão
  • Uma minirretífica (opcional, pois serve apenas para o furo de fixação superior do sensor)
  • Um parafuso
  • Um grampo/morsa/fixador de qualquer tipo (para melhorar a fixação do PVC no corte e no furo)
  • Um paquímetro ou régua
  • Uma canetinha
  • Uma lixa ou lima
  • Equipamentos de proteção individual (luvas e óculos de proteção)

Ingredientes separados!

Segue um passo a passo desse processo de preparação:

Marcar altura de corte: Começamos marcando o tubo de PVC na altura que queremos cortar. Isso vai depender do tamanho do abrigo, podemos tomar a metade de sua altura como uma boa medida.

Vualá! Um círculo perfeito.

Primeiro corte: Então prendemos o tubo na morsa ou no grampo e realizamos esse primeiro corte transversal ao eixo do tubo com a serrinha de mão.

Partiu!

Medição do DHT22: Então medimos a altura do DHT22 para referência do próximo corte.

Já que é pra medir.

Segundo corte: A seguir cortamos o tubo próximo a uma de suas extremidades afim de deixar apenas o suporte da parte traseira do sensor.

Um tantinho mais.

Terceiro corte: Enfim fazemos novo corte transversal que destaca essa parte do resto.

Mais um pouquinho ali

E fechou!

Lixação: Lixamos com uma lima (preferencialmente) pra ficar bem acabado.

Não se lixe.

Lixe o suporte. Vale a pena.

Marcação do furo: Marcamos com uma caneta o ponto onde pretendemos realizar o furo para fixação do DHT22.

Agora é só furar.

Furação: Enfim é só furar com a minirretífica.

Perfeito!

Então é só prender com o DHT22 com um parafuso e está feito o suporte. O DHT22 agradece, pois não curte muito um banho.

Suporte pronto e lindão.

Substituição do cabo e do sensor DHT22

Então seguimos pras próximas etapas dessa manutenção, que consistiam dos passos necessários para a troca do DHT22.

Abrigo meteorológico antes da manutenção da OraProNobis CTA no dia 12 de Março de 2018

Abrigo meteorológico antes da manutenção

Comecei desrosqueando o eixo do abrigo, mas não consegui ir até o fim, pois haviam cintas plásticas que prendiam os sensores as camadas externas do abrigo. Então removi os parafusos que prendiam essas partes e as soltei levemente.

Parafusos e porcas fora!

Com isso consegui acessar as cintas plásticas e cortá-las.

Corte da cinta plástica em execução.

Então consegui ter uma vista melhor dos sensores dentro do abrigo.

Visão interna do abrigo meteorológico com os sensores durante manutenção da OraProNobis CTA no dia 12 de Março de 2018

Olha eles, não veem a luz do Sol há meses.

E remover as camadas externas completamente.

Sensores ao Sol durante manutenção da OraProNobis CTA no dia 12 de Março de 2018

Bora tomar banho de Sol e fazer vitamina D, galera!

Com as camadas do abrigo retiradas, foi possível fazer aquela faxina com um paninho molhado e remover a poeira.

Abrigo aberto

E livre de poeira.

Então, visualizando claramente qual era o cabo do DHT, e sem nenhum impedimento para tirá-lo, cortei o RJ11 respectivo e pude retirar o cabo.

Bom trabalho! Hora de descansar.

Coloquei o novo suporte com o novo DHT22 e o respectivo cabo na estrutura interna do abrigo.

Aqui o melhor ângulo do BMP

Sensores fixados no novo suporte durante manutenção da OraProNobis CTA no dia 12 de Março de 2018

E aqui o do DHT.

Com isso concluído, pude crimpar o novo cabo. O que fiz três vezes nesse processo (ó vida!).

Crimpagem do cabo do sensor DHT22 durante manutenção da OraProNobis CTA no dia 12 de Março de 2018

Tomada 3!

E me dei por satisfeito com o abrigo novamente montado.

Abrigo meteorológico remontado durante manutenção da OraProNobis CTA no dia 12 de Março de 2018

Sensibilidade renovada!

E infelizmente percebi que o sensor ainda não estava funcionando, mesmo após três tentativas. Convicto de que eu tinha um problema mais profundo diante de mim, decidi deixar o resto da aventura pra outro dia.


Semanas 11 a 13 (18/3 a 07/4)

Nas semanas seguintes, não consegui realizar essa inspeção mais profunda. Até que no dia 06 de Abril decidi botar um ponto final nessa história. Comecei verificando se o cabo do sensor estava inteiro, sem nenhum rompimento interno. Então fui investigar com o multímetro.

Verificação da continuidade do cabo do senso com multímetro durante manutenção da OraProNobis CTA no dia 06 de Abril de 2018

Teste em execução.

E o resultado é de que estava tudo normal.

E a conclusão foi de que o cabo estava inteiro e bem soldado no sensor.

Estava preparado para realizar essa verificação minuciosa, mas decidi começar por nova verificação da conexão dos terminais do RJ11 do cabo do DHT22 com a placa de controle. E não é que era isso mesmo? Foi só recrimpar e fechar a conta.

Realização equivocada de crimpagem durante manutenção da OraProNobis CTA no dia 06 de Abril de 2018

Crimpagem com ordem errada dos fios.

Tomada 4! Claquete! E enfim um bom registro.

E o sistema voltou a funcionar normalmente nesse dia. Sucesso!


Semanas 14 a 21 (08/4 a 02/6)

Até o dia 02 de Junho, a OraProNobis seguiu sem novas manutenções. A única intervenção feita foi uma poda em uma aroeira que estava crescendo perto da OraProNobis e estava dificultando a visualização da EMM e se encaminhando para encobrir sensores em breve. A poda foi feita no dia 17 de Maio, quando ocorreu um evento no CTA. A OraProNobis se arrumou toda para o Hatch da Residência Hacker! Olha que linda:

OraProNobis brilhando!

Ao começar essa manutenção, verifiquei a condição da OraProNobis.

OraProNobis CTA antes da manutenção no dia 02 de Junho de 2018

Estado/Aspecto da EMM:
  • inteira
  • ligada
  • piscando duas vezes
  • últimos dados no servidor em 12/05/2018
  • últimos dados no cartão 08/04/2018

Percebi que os últimos registros no cartão tinham sido logo depois da última manutenção (confira no arquivo em anexo DATALOG_2018_2-24_6-2.txt). Depois de dois dias de coleta de dados, de repente foi escrita uma sequência do caractere estranho "ÿ" e os registros pararam.

OraProNobis aberta para manutenção!

Então tentei uma série de ações para restaurar o funcionamento do cartão

Ações:
  • Removi erros do arquivo
  • Removi arquivo
  • Desliguei e liguei de novo
  • Criei novo arquivo vazio
  • Reconfigurei conexão WiFi com a nova senha do CTA: funcionou dados no site apenas (piscando 5 vezes)
  • Formatei o SD com o processo lento

Mesmo após todas essas tentativas, o cartão não voltou a funcionar para registro de dados. Abria normalmente no computador, mas quando eu ia testar na EMM, não era bem sucedido.

Tive de encerrar a manutenção sem conseguir reestabelecer o funcionamento do sistema. Para as próximas manutenções, tenho em mente três abordagens:

  1. Incluir filtros RC mais próximos do módulo microSD, considerando que o problema pode ser de hardware e que interferências podem estar gerando os erros. O sistema já conta com filtros, mas eles podem estar muito distantes do módulo, não blindando-o suficientemente. Cheguei nessa abordagem por sugestão do colaborador Alisson.
  2. Substituir o cartão por um cartão classe 10, considerando que a fonte de erros é o próprio cartão por sua baixa qualidade. Verifiquei que estes sistemas são sensíveis após conversas com diferentes membros do CTA. Os cartões normalmente vendidos são classe 4, e os classe 10 são os de maior qualidade, mais robustos quando são feitas séries de gravações (só encontrei info sobre melhor desempenho com relação a velocidade de gravação: https://pt.wikipedia.org/wiki/MicroSD, mas vou botar fé de que eles podem ser mais robustos de maneira geral e tentar a sorte).
  3. Verificar o firmware, considerando que o próprio firmware pode estar escrevendo informações espúrias no cartão. Essa possibilidade foi levantada em mais de uma conversa com outros membros do CTA. Essa é uma solução que requer um aprofundamento maior de investigação, por isso será a última abordagem a ser testada.

Com o foco em outras questões do projeto, fiquei muito tempo sem fazer manutenções nas EMMs, o que causou a perda de muitos dados. Essa é uma situação que deve ser ajustada para não prejudicar tanto os registros. As manutenções passarão a ser mais recorrentes. Devo agora trabalhar para corrigir este problema do cartão e tentar entender melhor sua natureza.

Si se puede!

02Jun_manutencao_relato2_OraProNobis.jpg - OraProNobis CTA antes da manutenção no dia 02 de Junho de 2018 (296,6 KB)

12Mar_manutencao_relato2_sensores_interno.jpg - Visão interna do abrigo meteorológico com os sensores durante manutenção da OraProNobis CTA no dia 12 de Março de 2018 (127,4 KB)

12Mar_manutencao_relato2_sensores_fixados.jpg - Sensores fixados no novo suporte durante manutenção da OraProNobis CTA no dia 12 de Março de 2018 (148,1 KB)

12Mar_manutencao_relato2_sensores_ao_sol.jpg - Sensores ao Sol durante manutenção da OraProNobis CTA no dia 12 de Março de 2018 (203,7 KB)

12Mar_manutencao_relato2_crimpagem_cabo.jpg - Crimpagem do cabo do sensor DHT22 durante manutenção da OraProNobis CTA no dia 12 de Março de 2018 (203,8 KB)

12Mar_manutencao_relato2_abrigo_remontado.jpg - Abrigo meteorológico remontado durante manutenção da OraProNobis CTA no dia 12 de Março de 2018 (169,9 KB)

12Mar_manutencao_relato2_abrigo.jpg - Abrigo meteorológico antes da manutenção da OraProNobis CTA no dia 12 de Março de 2018 (231,9 KB)

06Abr_manutencao_relato2_verificacao_multimetro.jpg - Verificação da continuidade do cabo do senso com multímetro durante manutenção da OraProNobis CTA no dia 06 de Abril de 2018 (237,2 KB)

06Abr_manutencao_relato2_cabo_crimpagem_errada.jpg - Realização equivocada de crimpagem durante manutenção da OraProNobis CTA no dia 06 de Abril de 2018 (152 KB)

DATALOG_2018_2-24_6-2.txt - Dados registrados no cartão no período do dia 24 de Fevereiro a a 02 de Junho de 2018. (930,9 KB)

RE: Diário da EMM OraProNobis CTA - Adicionado por Leonardo Sehn 6 meses atrás

Registro do período do dia 03 de Junho a 21 de Junho de 2018.

Resumo

Período: Semanas 22 a 24 (03/06/2018 a 21/06/2018)
Idade: 164 dias

Dados do Período

Maior período de dados registrados: ~ 5 minutos (17:11 de 21/06 às 17:16 de 21/06)
Maior período de funcionamento pleno: Não aconteceu, pois servidor está com defeito.
Maior período de envio de dados para o servidor: Idem.
Maior período de dados registrados no cartão: ~ 5 minutos (17:11 de 21/06 às 17:16 de 21/06)
Manutenções: 1

Dias de dados registrados: 21/6 (m/i/bmp)

i = interrupções ocorreram
m = manutenção ou instalação
bmp = problemas com o BMP

Registro integral de dados: 0 dias.
Registro de dados com interrupções: 1 dia.
Sem registro de dados: 18 dias.

Conclusões

  1. A princípio o problema no módulo do cartão era alguma questão de circuito. Ou algum mau contato, ou curto ou falta de filtro.
  2. É importante ficar atento para ver se essa será uma solução duradoura. Senão, cabe aplicar as demais abordagens indicadas na última manutenção.
  3. O BMP parece estar com defeito. Mas cabe uma investigação para saber se é avaria no sensor ou problema de conexão.

Pendências

Resta investigar o sensor BMP, que não está funcionando, e ajustar o que for necessário.

Ações planejadas

  1. Ajustes dos cabos nos conectores.
  2. Teste de continuidade entre BMP e conector.
  3. Conserto em alguma conexão do cabo ou substituição do sensor.

Dados históricos

Maior período de dados registrados: ~ 19 dias (22:57 de 20/01 a 18:31 de 08/02)
Maior período de funcionamento pleno: ~ 11 dias e meio (22:57 de 20/01 a 12:09 de 01/02)
Maior período de envio de dados para o servidor: ~ 15 dias e meio (22:57 de 20/01 a 12:01 de 05/02)
Manutenções: 10 (8 bem sucedidas e 2 mal sucedidas)
Dias de dados registrados:
  • Janeiro: 09/1 (m) a 12/1 (m), 13/1 a 14/1 (i), 15/1 (i/m), 16/1 (i), 17/1 a 19/1 (w+sd), 20/1 (m) a 31/1.
  • Fevereiro: 01/2 a 02/2 (dht), 03/2 a 08/2 (i), 09/2 (m/w+sd), 10/2 (w+sd) a 14/2 (i/w+sd), 17/2 (i/dht), 18/2 (dht), 19/2 (dht), 20/2 (i/dht), 21/2 (i), 22/2, 23/2 (m) a 28/2.
  • Março: 01/3 (dht), 02/3, 03/3 (dht), 04/3 (dht), 05/3 (dht), 06/3 (dht), 16/3 (i/dht), 17/3 (i/dht).
  • Abril: 6/4 (i), 7/4, 8/4 (i).
  • Junho: 21/6 (m/i/bmp).

i = interrupção (genérica)
m = manutenção ou instalação
w+sd = problemas conjuntos de comunicação WiFi com o servidor e de registro com cartão SD
dht = falhas no sensor DHT22
bmp = falhas no sensor BMP180

Registro integral de dados: 34 dias
Registro de dados com interrupções: 27 dias
Sem registro de dados: 103 dias
Total: 164 dias


Relato

Essa manutenção começou com a verificação do aspecto da OraProNobis e do ambiente ao seu redor. Não houve qualquer mudança significativa e tudo parece em ordem com a EMM.

Firme e forte. Ao seu redor, nada significativo parece ter mudado.

Então abri a caixa estanque e em termos de alimentação também estava tudo normal. A EMM seguia apresentando o mesmo problema e o LED piscava indicando o defeito. Tirei a estação da alimentação e verifiquei o cartão. Realmente, nenhum dado foi salvo nesse meio tempo.

EMM bem alimentada.

Infelizmente, não foi possível conferir os dados no site devido a uma pane recente mais séria no servidor das EMM, e a segunda instância ainda não retornou.

Então, decidi realizar a primeira abordagem elencada na última manutenção para solucionar a questão do cartão microSD: inclusão de um filtro.

Depois de meses, a placa EMM Memória 0.9.8 sai para dar um passeio, radiante.

A proposta consiste em incluir um capacitor mais próximo ao componente, entre sua alimentação e terra, para filtrar ruídos de alta frequência que possam chegar ao sistema. Escolhi o capacitor de 1 uF, o de menor capacitância e mais abundante que tínhamos no CTA. Outro aspecto positivo de realizar esse procedimento é a revisão no circuito para ver se está tudo em ordem.

Ateliê preparado para pintar com estanho.

Capacitor aterrizando na placa.

Capacitor solda. Solda capacitor.

Tudo preparado para a conexão.

E aconteceu.

Decidi colocar o módulo microSD soldado direto na placa, uma das poucas diferenças entre essa placa e a da Butiá, que não apresentou tal tipo de defeito. De uma forma ou de outra, esse processo melhora as conexões do módulo com a placa.

Tirando o barramento perninha por perninha.

Módulo microSD soldado.

Tive alguns problemas no meio desse processo, pois o teste de continuidade do multímetro acusava curto entre a alimentação e o terra. Depois de muito conferir e tentar ajustar todas as conexões, me dei conta que a carcaça do módulo estava encostando na trilha de alimentação do lado posterior da placa. Como o barramento foi tirado, o módulo ficou mais próximo e encostou na trilha. Flexionei um pouco o módulo e o problema foi resolvido. Ao menos serviu para dar uma conferida no circuito.

Durante os ajustes, o capacitor foi desconectado. Então ressoldei o capacitor e tava feito o retoque. Aí era só botar pra funcionar.

Depois de alguns ajustes, o capacitor foi reconectado.

As duas pernas do capacitor devidamente isoladas. Palavras do multímetro.

E o terminal negativo devidamente conectado no terra.

Placa prontinha para voltar à ação.

Recoloquei a placa na caixa, reconectei a alimentação e os sensores e energizei a placa, torcendo esperançoso pelo melhor. E foi sucesso! Ligou e já indicou que estava funcionando com o sinal luminoso.

De volta ao seu lugar! E funcionando!

Retirei o cartão para ver e os dados estavam sendo salvos novamente. Tudo certo, como pode ser conferido no arquivo em anexo DATALOG_18-06-21.txt. Nem precisei trocar o cartão. A princípio, problema resolvido.

Tive que fazer um ajuste da hora, pois ela havia sido zerada. Realizei esse processo e o registro voltou a ser feito corretamente. O arquivo com a configuração pode ser conferido em anexo em configuracao_18_06_21.md.

O único aspecto que restava resolver era a medição com o BMP. O arquivo de registro estava indicando que o sensor não era encontrado. Tentei ajustar a conexão diversas vezes, mas não rolou. Depois de tantas tentativas, começou a escurecer e a cair um toró. Então tive que encerrar o processo e deixar essa investigação mais aprofundada sobre o BMP para outra.

A chuva apertou e a manutenção acabou.

Agora é ficar atento ao BMP e ao andamento da questão do cartão em uma próxima manutenção. E o importante é que a OraProNobis voltou a funcionar e registrar dados! Vitória para a ciência cidadã!

Banho de chuva pra regar a OraProNobis CTA!

DATALOG_18-06-21.txt - Arquivo com dados do período de manutenção do dia 21 de Junho de 2018. (2,8 KB)

configuracao_18_06_21.md - Arquivo de configuração do relógio realizada durante manutenção do dia 21 de Junho de 2018. (4,3 KB)

(1-2/2)