Olá, garagistas! Montei uma estação meteorológica com arduíno e um shield datalogger para meu projeto de pesquisa. Aparentemente ela funciona perfeitamente, programei para ela gravar os dados obtidos em um cartão SD a cada 30 minutos, porém quando deixei ela funcionando em campo por um tempo, percebi que do nada os dados começaram a ser gravados a cada minuto, depois voltavam a ser gravados a cada 30 minutos e assim ia. Constei também que os dados param de ser gravados do nada, por exemplo, com as medidas a cada meia hora, deveria ter aproximadamente 12 gravações durante o dia completo, porém em muitos dias só haviam 5 ou 6 gravações. Retirei o cartão SD dia 3 de março e percebi que desde o dia 18 de fevereiro não havia novas gravações. Estou um pouco perdido no que pode estar acontecendo.

Segue o código:

CODIGOMESTRE.ino

Exibições: 1070

Responder esta

Respostas a este tópico

Boa tarde GTBM, (se não gosta que te chame pelas iniciais, avise),

gostaria muito de te ajudar, mas para isto recomendo as seguintes ações:


1. Remova seu sketch da área de texto do seu tópico;
2. Leia http://labdegaragem.com/forum/topics/sugest-o-de-como-postar
3. Comente as linhas do seu sketch. Fica mais fácil entender o que vc quer fazer com cada
     linha e facilita a ajuda.
4. Clique em : " Deseja carregar arquivos? " e depois em " Escolher arquivo" e anexe o arquivo
     com o seu sketch.

RV

ok!

Boa tarde GTBM,

minhas primeiras observações:

1.   " com as medidas a cada meia hora, deveria ter aproximadamente 12 gravações durante o dia completo," 

    Errado; Se o dia completo tem 24 horas e a gravação é feita a cada meia hora deveria ter 48 gravações.

2. Vc está usando um delay de 1.800.000 mSeg (30 minutos).

    Está parando todo o processamento por meia hora.

    Nada é feito durante este tempo, nada é medido.

3, Se está usando um RTC, não precisa usar este delay, use o RTC pra controlar as gravações.

4, Existe uma abre chave { na linha 130 e uma fecha chave  }  na linha 150 sem nenhum significado.

5. A rotina de gravar dados está misturada com a rotina de obter dados, isto torna fluxo do programa

  confuso, e  com possibilidade de problemas.

6. Alguns dispositivos tem um tempo de resposta muito grande (ex; DHT11), e podem até travar

   o processamento,    Sempre verifique se eles não travaram o processamento.

RV

olá Gabriel.

      Já auxiliei em diversos Sistemas semelhantes ao seu, inclusive aqui no LDG. Então se vc permitir,  gostaria muito auxiliá-lo.

      Porém precisaria que vc tivesse a mente aberta, pois como o RV disse,  seu código tem diversos problemas.  Claramente,  o "grosso" do código foi obtido da internet, e alguns pontos foram ajustados sem muito critério.

      A questão é que a forma básica como o código atual funciona, está totalmente equivocada, e é uma receita para não funcionar direito, fazendo aparecer efeitos colaterais esquisitos e inclusive resultados não tão confiáveis (atenção, pois vc pode ter a impressão que são confiáveis, mas será que são?).

     Me adiantando,  analisei em detalhes todo o código,  para verificar os pontos problemáticos, e já prever como solucioná-los. E felizmente, constatei que isso é 100% possível e até simples.

     O  RV ("Minerin") já apontou alguns "problemas". Mas há muitos outros além daqueles que o RV listou (como eu disse, analisei o código em detalhes), e alguns são "graves" (mas como eu disse, perfeitamente resolvíveis).

     Eu teria algumas perguntas a fim de esclarecer pontos duvidosos no código, e há também um ou dois pontos que são um tanto obscuros.  Assim listando estes pontos, e iniciando pelos mais óbvios que apenas precisaria que vc confirmasse, e deixando por último os mais "obscuros",  seguem as perguntas enumeradas:

      1)  diversos pontos no seu código sugerem que vc está usando o Arduino Mega.  Vc confirma?

      2)  no pino "7" está conectado um Sensor DHT22, e segundo o código ele é usado para medir a Humidade e a Temperatura do Ar.  Vc confirma que estas medições são realmente do "Ar" ?  E é mesmo o DHT22 ou algum outro modelo DHT ?

      3) no pino "8" está conectado um Sensor DS18B20, e segundo o código ele é usado para medir a Temperatura do Solo.  Vc confirma que é realmente medição da Temperatura do Solo?

      4)  no pino "A1", segundo o código está conectado um Sensor da Humidade do Solo.  Vc confirma isso?  Como é este sensor?  Ele é daqueles que o pessoal usa muito nos projetos com Arduino (tipo para medição da Humidade nos vasos de plantas) ?

     5) no pino "2" segundo o código, está conectado um sensor "Hall",  usado para medir a RPM de um Anemômetro.  Vc confirma que é isto?  (desculpe, eu sei que isto parece 100% óbvio, mas precisaria confirmar)

     6) no pino "3" segundo o código, está conectado um "Reed Switch", usado para medir o índice de Chuva.  Vc confirma isso?   Se sim,  vc poderia descrever em linhas básicas como ele funciona?   (pergunto porque fiquei um pouco curioso sobre o funcionamento do próprio sensor)

      7) no pino "A0" segundo o código, está conectado o Sinal Analógico do sensor de CO2 (um sensor "MQ135").  Vc confirma isso?

      8)  no pino "4" segundo o código, está conectado o Sinal Digital do sensor de CO2 (o mesmo "MQ135").  No entanto Gabriel, este sinal digital  não é usado  no código.  Vc confirma isso?

      Obs.:  se ele realmente não estiver sendo usado (como eu realmente acho que não está, já que o CO2  já está sendo medido via sinal Analógico do mesmo sensor), então recomendo que ele seja desconectado do pino "4", deixando este pino "livre" para outros usos.

     9) agora o mais misterioso de todos:  no código o pino "5" é configurado como uma saída digital.  Mas ele não é usado em nenhum momento no código.  Tem realmente algo ligado neste pino,  ou acabou "sobrando"  aquela linha onde ele é configurado no "setup" do Arduino ?

      Tenho algumas outras questões, mas são menos significativas neste momento, como por exemplo os diversos informes que são feitos pela Serial semelhante a um "debug",  e também uma dúvida sobre um informe seletivo da quantidade de chuva.  Mas acho melhor perguntar isso no post seguinte,  se como eu disse anteriormente,  vc permitir que eu colabore.

      O código estava muito confuso e "misturado". Então pra que eu pudesse analisar e entender o que estava ali,  acabei organizando todo ele. Em seguida, otimizei diversas operações ali existentes, aumentando a eficiência da execução. Também deixei mais claro o que cada trecho estava fazendo, e qual a função de cada item no Sistema.  Isso seria o mínimo para que o funcionamento seja confiável (usando técnicas clássicas e portanto consagradas).

      Fico no aguardo.

      Abrçs,

      Elcids

1) CONFIRMO.

2) CONFIRMO.

3) CONFIRMO.

4) CONFIRMO. Este mesmo, muito usado em projetos de umidade de plantas em vaso, nas suas próprias casas.

5)CONFIRMO.

6)CONFIRMO. Ele funciona basicamente do mesmo jeito que o anemômetro, cada pulso que gera um campo magnético e ao passar pelo imã do switch, é contabilizado. De maneira matemática ese pulso é transformado em quantidade de chuva.

7)CONFIRMO.

8)CONFIRMO. Realmente o pino 4 não está sendo utilizado!

9)Não possuo nada conectado ao pino 5. Um erro, retirei.

Muito obrigado pelos toques, Elcids, aguardo ansiosamente o seu retorno!

olá Gabriel.

      Com estas suas informações,  já atualizei o código com "nomes" relativos a cada função. Isto permite facilmente identificar quem é quem dentro do código.  Isso é importante, porque no código original existiam "nomes" (ou como chamamos em programação: "identificadores") que nada diziam sobre a funcionalidade. Vou dar um exemplo:  havia uma variável global  chamada "counter",  e esse nome hiper-genérico não ajuda.  Mas agora já está tudo identificado de forma funcional.

      Sobre os pinos  "4" e "5" que não estão sendo utilizados,  também já os "liberei" no código.

      Embora mais caro,  sua escolha pelo Mega  foi uma ótima opção.  Há memória mais que suficiente para tudo que está sendo feito (no UNO  vc provavelmente iria ter problema com o "Heap", o que seria catastrófico para o funcionamento), e ainda te permite expandir seu Sistema, já que há muitos I/Os disponíveis (analógicos e digitais).  Também o fato de existirem Seriais de Hardware "sobrando",  permite que vc caso precise posteriormente,  conecte dispositivos onde esta Interface é necessária.

      O código que "reajustei", já está quase "no ponto".  Faltam alguns poucos detalhes para finalizar, e acredito que amanhã publico ele aqui.

      Mais há alguns pontos que ainda achei interessante verificar com vc:

      1)   O Acumulado de Chuva,  começa zerado quando se liga o Sistema. Depois ele só aumenta, ou seja,  em nenhum momento é zerado novamente enquanto o Sistema estiver ligado.  É isto mesmo que deve ocorrer?

      2)  não seria interessante que existisse também,  uma contagem do Acumulado de Chuva para por exemplo,  a última hora,  ou então para as ultimas 24 horas (isso dispensaria depois fazer cálculos com o Acumulado total pra se obter estes valores intermediários).

      3)  ainda sobre a Chuva:  sempre que se conclui um "ciclo" de medições (ou seja, a cada meia hora),  é exibido via Serial do Arduino,  o acumulado durante este período (a última meia hora).  Isto está sendo realmente usado?

          Pergunto porque esse valor não fica registrado (não é gravado no Cartão),  e como o Sistema fica em "campo" para registrar as medições por dias seguidos (como vc informou), acredito que provavelmente não deve existir nada conectado à Serial (por exemplo um Notebook), o que significaria que aquela informação da última meia hora "ninguém iria ver".  Se for isso mesmo,  então não seria mais interessante o que eu sugeri sobre registrar também acumulados de chuva intermediários no Cartão?

      4)  o "formato" dos dados gravados no Cartão, já está "facilitado" para vc posteriormente facilmente exportar para alguma planinha?  Caso não,  eu poderia colocar em um formato que facilitasse isso?

      5)  e finalmente:  as demais informações enviadas via Serial do Arduino  a cada ciclo de medição (a cada meia hora), estão sendo realmente sendo usadas,  ou apenas são usadas em testes com o Sistema (ou seja, testes sem estar em "campo")?

      Sobre esta última pergunta (a "5"),  eu inclui no Sistema a opção de vc ligar ou desligar o envio daquelas informações pela Serial (esta opção coloquei logo no início do código).  Isto permite que se compile também com a opção de não enviar as informações pela Serial,  o que aumenta a performance do Sistema quando ele estiver em "campo".

      Mas há uma outra possibilidade que talvez vc possa achar interessante:  acrescentar uma chave física (tipo On/Off),  e o estado desta chave determinaria se o Sistema envia ou não as informações via Serial. Isto facilitaria testes antes de deixar o Sistema em "campo",  bastando selecionar o que o Sistema deve fazer através da chave. Isto é muito simples de fazer, apenas precisaria reservar um pino no Arduino para se ler o estado da chave. Caso ache isso interessante,  eu posso incluir no código.

      Outra coisa que pode ser interessante, é o Sistema fazer um "auto-teste" de Gravação no Cartão, logo depois que vc liga a alimentação, informando assim algum eventual  problema. Mas para isso seria necessário acrescentar algo como um "Buzzer",  que alertaria de forma sonora, que um problema foi detectado (por exemplo,  quando o Sistema está sendo deixado em campo mas esqueceram de colocar o Cartão nele).

      Fico no aguardo de suas considerações.

      Abrçs,

      Elcids

1)Não é o que deve acontecer. Porém não consegui ajeitar isso.

2)Com certeza seria!

3)Você está certo, desta forma não estou pegando o acumulado. Então seria muito interessante a sua idéia!

4)Já está facilitado, mas muito obrigado!

5)Estão realmente sendo usadas.

Quanto as outras situações que você mencionou, é de muito interesse, umas vez que pronta a estação ficará em um lugar longe, estou pensando um jeito de receber esses dados á distância.

Muito obrigado!

olá novamente Gabriel.

      Seguem as considerações sobre cada item que vc respondeu:

      1)  isto é uma questão comportamental, ou seja:  vc determina como deve ser, e no código temos apenas a implementação. Pelo seu código original, eu vi que era isso que estava acontecendo, então eu entendi que era isso que deveria acontecer.  Então, se não for como está no código, qual deveria ser o comportamento ?  Por favor, descreva claramente.

      2)  já implementei isso no código. Assim além do Acumulado "geral", é também computado o acumulado na última hora, e também o acumulado nas últimas 24H.

      3)  não entendi ainda o motivo da exibição via Serial, daquele valor "intermediário".  De qualquer forma, acho que o que informei no item "2", já dá o tratamento adequado (e se não, se possível me esclareça melhor).

      4)  ok, eu já imaginava, devido aos "campos" estarem separados por vírgulas (típico para exportação para planilhas). Mas precisava confirmar.

      5)  sobre as "exibições" via Serial a cada Gravação dos dados (ou seja, a cada meia hora), fiquei curioso:  qual seria o motivo?  Os únicos motivos que consigo imaginar são "debug" (quando se está desenvolvendo o Sistema) e verificação das funcionalidades antes de liberar o equipamento em "campo". Lembrando que depois de liberado o equipamento em campo, se algum computador (provavelmente seria um Notebook) for conectado ao Mega via Interface USB,  isto provocará um Reset do Mega (claro, provavelmente não seria um problema, pois ele recomeçaria o monitoramento novamente de forma automática, e sem perder nenhum dado já gravado no Cartão).

      Ainda sobre o item "5",  eu implementei no Sistema, o controle da exibição "on the fly"  dos dados via Serial. Ou seja:  mudando a posição de uma Chave física  conectada a um pino do Arduino,  a qualquer momento vc pode habilitar ou desabilitar a exibição dos dados via Serial (e sem interferir  com outros processos incluindo a gravação no Cartão).  Então acho que esse controle poderá ser bem prático, dependendo de como o Sistema for usado.

      Também incluí um LED,  chamado LED "Alive",  o qual sempre indica que o Sistema está funcionando, piscando a intervalos regulares.  Atualmente, há dois intervalos:  pisca duas vezes por segundo para indicar que a "exibição" via Serial está habilitada,  e pisca uma vez a cada 3 segundos para indicar que a "exibição" está desabilitada (ou seja:  olhando para o LED vc sabe que o Sistema está funcionando e também se a "exibição" está habilitada ou não).

      Implementei também outras funcionalidades que acredito vc irá apreciar, mas irei descrever logo que eu postar a implementação (estes "features" não interferem com as funcionalidades originais).

      Também simulei o Sistema no Proteus, e funcionou exatamente como esperado. O circuito que usei na Simulação vc pode ver na figura a seguir:

(clique na figura para "zoom")

      Para a simulação tive que implementar circuitos que tivessem comportamentos equivalentes a alguns sensores, e tomei o cuidado para que isto fosse realístico. Uma curiosidade:  há modelos "prontos" para o Mega, como o do "TEP" (um site estrangeiro)  e o "Simulino Mega", mas um é cópia do outro, e ambos tem problemas com os canais Analógicos, e por este motivo usei na simulação o próprio ATMega2560  "original".

      Também e apenas para a simulação,  "encurtei" os intervalos que os dados eram aquisitados e gravados,  para que eu não precisasse ficar esperando por horas pra ver o resultado da Simulação (já que originalmente a Gravação no Cartão é a cada meia-hora).  No caso,  deixei o intervalo de Gravação a cada 15 segundos.  O resultado do arquivo gravado (sim, o Proteus permite essa "proeza"), após 8 gravações (não tive muita paciência), vc pode ver na figura a seguir:

(clique na figura para "zoom")

      Observe que marquei os campos, informando o significado de cada um. Veja que o formato da Hora/Data agora está "homogêneo" e assim mais "entendível" (isto não interfere na exportação para uma Planilha, já que são "zeros não significativos"). Tirando essa "melhoria" na Hora/Data, mais nada foi alterado, estando os campos na exata sequência original.

      No entanto, veja que não incluí na gravação, os Acumulados de Chuva da última hora e das últimas 24H.  Assim, agora que o Sistema está computando estas informações, elas seriam inseridas na Gravação???  Se sim, como ficaria a ordem dos campos?

      Além disso,  há no sistema a contagem total do número de Gravações já efetuadas. Há também a informação de se ocorreu alguma falha de gravação, inclusive com um Contador de Falhas.  Vc acha que seria interessante também inserir estas informações na Gravação?   Se sim, como ficaria?  Seria a cada gravação,  ou seria a cada "N" gravações?   (obs.:  no formato dos campos no arquivo, teria que ser feito de forma a não interferir na exportação dos campos originais para uma Planilha).

      Acho que eu não precisaria dizer que a implementação foi feita com técnicas sólidas e consagradas, e  que acrescentam enorme confiabilidade ao funcionamento do Sistema.   Depois irei também te dar algumas dicas de Hardware,  para que sua montagem física também seja confiável.

      Acredito que está próximo de fecharmos isso aqui. Mas ainda fico no aguardo de suas considerações pra isso.

      Abrçs,

      Elcids

Boa tarde, Elcids!

1) No código original, em algum momento a quantidade de chuva zerava, porém, não sei dizer qual o critério. Estou bem confuso quando a isso. O funcionamento perfeito seria que quando começasse a chover, mostrasse o quanto choveu nesse intervalo de 15 segundos, depois acumulasse com a quantidade dos próximos 15 segundos e em algum momento quando parasse de chover, essa quantidade zerasse. Também poderia funcionar mostrando somente  quantidade que choveu dentro desses intervalos de 15 segundo, sem acumular.

5) Eu botei a cada meia hora pois não preciso de muitas amostras de dados ao longo do dia, apenas por esse critério!

Adorei essa melhoria na Hora/Data!

Este acumulado total de chuva não precisa ser mostrado, tanto o diário quando o de hora em hora, porém obrigado!

Não é necessário inserir um contador de falhas, porém muitíssimo obrigado mais uma vez.

olá Gabriel.

      Sobre o Acumulado de Chuva, se vc não tem certeza do critério a ser usado,  então minha sugestão é que inicialmente seja usado como está no código original que vc postou aqui.  Eu implementei desta forma, ou seja, conforme seu código original.  Veja a justificativa para seguir esta linha:  o código que implementei é extremamente flexível, organizado, robusto e confiável,  e então se posteriormente vc quiser mudar a forma como o "Acumulado"  é usado, será bem simples, e ao mesmo tempo mantendo todas estas características que mencionei.  Além disso, conforme vc for usando o Sistema, vc mesmo aliado a outras pessoas da sua área,  irão perceber as necessidades de uso desses dados, e assim será mais efetivo ajustar o Projeto para atender esse uso.

      Sobre o "Serial Print",  eu não tenho certeza, mas acho que vc pode estar se confundindo.  Veja: os dados são gravados no Cartão, exatamente como antes, na mesma taxa do seu código original (ou seja: a cada meia-hora).  Mas estes dados são também enviados (ou "printados")  via Serial padrão do Arduino (também chamado de "Terminal do Arduino").  Então o questionamento que fiz, é sobre esses dados "printados" via Serial.  Mas eu posso estar enganado, e vc já esteja se referindo a esta "printagem".  Mas ainda assim, a existência dessa "printagem" via terminal,  ainda parece sem muita lógica, dado o Hardware que vc descreveu até aqui.  De qualquer forma,  eu fiz a implementação seguindo a funcionalidade do seu código original, com a possibilidade de vc desabilitar essa "printagem" a qualquer momento, através de uma chave física no Hardware (olhe o circuito que postei da simulação).  Este "ON/OFF" da "printagem" é do tipo "on the fly", ou seja: vc pode mudar a posição da chave física a qualquer instante, e o código vai habilitar ou desabilitar a "printagem" via Serial conforme esta seleção via chave física.

      E esclarecendo novamente:   preparei duas versões do código. Uma delas tem as temporizações "reais"  (por exemplo, a Gravação no Cartão é a cada meia-hora).  Já a outra versão, é apenas para facilitar a simulação no Proteus, e não precisar ficar esperando horas para ver o resultado (por exemplo, nesta versão a Gravação no Cartão é a cada 15 segundos).  Estou esclarecendo, pois tive a impressão que houve alguma confusão em relação a isso.

      Aguardo suas considerações, mas acho que postar aqui o Sistema na forma como está neste ponto, pode ser a melhor opção neste momento.

      Abrçs,

      Elcids

olá Gabriel, e a todos que acompanharam este tópico.

      Como já faz algum tempo que não tenho respostas sobre os pontos  que questionei,  então estou postando o Sistema que implementei, sem ir mais adiante em termos de "refiná-lo".

      De qualquer forma,  o Sistema está totalmente funcional, e por estar organizado, e por terem sido utilizadas no código técnicas clássicas e consagradas,  é possível que se continue a desenvolvê-lo de forma harmoniosa, simples e confiável.

      O  Sistema  foi testado em Simulação no Proteus,  através do Hardware mostrado na figura a seguir:

(clique na figura para "zoom")

      Como eu disse num post anterior neste tópico, para a simulação eu reduzi os períodos de tempos originais, de forma que se possa ver os resultados mais rapidamente na tela do Proteus (pois os tempos originais, equivalem a vários minutos e até horas).

      Assim, como resultado  há dois códigos:  um com períodos de tempo para o Sistema "real", e um com períodos para a Simulação.  Deixei isto evidenciado no começo de cada um destes códigos,  e para o Sistema "real" isso pode ser visto na figura a seguir:

(clique na figura para "zoom")

      E para o código para simulação, a informação está como mostrado na figura a seguir:

(clique na figura para "zoom")

      Como se vê, a única diferença são os períodos de tempo, sendo a lógica de funcionamento idêntica nos dois códigos.

      O  Sistema sendo simulado no Proteus, pode ser visto na figura a seguir:

(clique na figura para "zoom")

      Esclarecendo alguns pontos importantes do Sistema:

      1)  para alterar o Acumulado de Chuva,  pressiona-se o Botão correspondente no circuito equivalente ao Sensor de Chuva.  A cada dois pressionamentos do Botão, será equivalente a acrescentar 1 mm de Chuva, exatamente como o Sensor "real" descrito pelo Gabriel. Observar que o Contador Digital que acrescentei ali, também registra essa contagem, permitindo que se confira se a coisa está realmente funcionando.

     2)  a Velocidade do Vento, pode ser ajustada via Potenciômetro que determina a Frequência de um Oscilador,   assim  alterando  a  frequência dos pulsos  que  seriam  gerados via Anemômetro "real".  Para obter melhor precisão neste controle,  criei duas faixas:  uma de 15 a 55 km/h, e outra de 55 a 370 km/h (certo: exagerei, pensando naqueles tornados lá no meio-oeste Americano).  Assim devido a estas duas faixas, existem dois Potenciômetros  para se ajustar a Velocidade do Vento desejada, e uma Chave (SW30 no circuito) permite que se selecione a faixa a ser usada (na simulação isto pode ser feito a qualquer momento).  Observar que acrescentei um Frequencímetro Digital  ali,  a fim de que se possa ver a frequência do Oscilador  a qualquer momento, e com isso conferir se a velocidade indicada está de acordo. Lembrando que o Anemômetro do Gabriel,  fornece pulsos na frequência de 5.4 Hz para uma velocidade de 10 m/s (ou 36 km/h). Então é só fazer regra de três.

      3)  os Sensores DHT e DS18B20,  são originalmente do Proteus mesmo, e os ajustes são feitos ali mesmo.  Notar que para o DS18B20  eu reajustei alguns parâmetros, pois o setting default não estava de acordo para funcionar corretamente na simulação (o ajuste não foi  "chutado", mas sim conforme uma análise que fiz na temporização do barramento "OneWire" implementado via Biblioteca no Arduino).  Então fica a dica quando forem usar o DS18B20  no Proteus: basta copiar os mesmos parâmetros que deixei setado nesta simulação.

      4)  sobre os Sensores de Humidade do Solo e da taxa de CO2,  praticamente não há o que dizer, uma vez que eles fornecem saídas de tensão na faixa que os Sensores "reais" fornecem, e que serão convertidos via ADC do Arduino.

      5)  para o RTC DS1307, notar que acrescentei os dois Resistores de 4.7k necessários para o barramento I2C.  Isto deve ser feito apenas se o módulo DS1307 que estiver sendo usado no Sistema, não tiver estes dois Resistores já incluídos na plaquinha do módulo.

      6)  para o ATMega2560, não se deve esquecer de selecionar o arquivo "HEX" correspondente ao código a ser executado. Este arquivo está na mesma pasta da simulação. Se isto não for feito, dará erro imediatamente ao se iniciar a simulação (claro, depois de selecionado o arquivo, este setting ficará salvo no arquivo de Simulação do Proteus, dispensando fazer a seleção novamente). Isto é necessário, porque a seleção do "HEX" estará com o caminho do arquivo no meu computador, e deve se setada para o caminho do arquivo no PC de cada um.

      7)  para o SD Card, também deve ser especificado o arquivo da "imagem do Disco" correspondente.  A extensão deste arquivo é "IMA", e está na pasta da simulação com o nome "SDCard_Image_01.IMA".  A seleção é igual ao processador ATMega, e basta ir em "propriedades" do componente (o Cartão no circuito) e selecionar este arquivo. Se isto não for feito,  o código não conseguirá gravar  no Cartão,  e indicará o erro via Serial do Arduino.  Atenção, pois no modelo do Proteus  o Cartão é "ejetável" (basta clicar nas setas junto ao modelo), e se ele estiver ejetado não irá gravar.  E sempre que a simulação é pausada,  será aberta uma janela correspondente aos arquivos no Cartão.  Assim basta clicar com o botão direito do mouse para que este arquivo seja copiado em um arquivo "real" no Computador (bem legal isso, não é?). Inclusive, é possível "formatar" o SD Card, nas opções exibidas.

      8)  finalmente, sobre o LED "Alive" e a Chave "Debug".  O LED "Alive" sempre indicará que o Sistema está funcionando, piscando a intervalos regulares. A frequência de piscada do "Alive" indicará se o "Debug" está ou não ativado:  piscará 2 vezes por segundo se o "Debug" estiver ligado,  e uma vez a cada 3 segundos se o "Debug" estiver desligado.  Estes intervalos das piscadas podem ser facilmente alterados no código, estando inclusive especificado em segundos.  E o "Debug" nada mais é do que a possibilidade ver dados via Serial do Arduino (ou "Terminal do Arduino") e isto é selecionado pela Chave "SW1" (ao lado do LED "Alive" no circuito).  A posição da Chave pode ser mudada a qualquer momento,  seja na simulação, seja numa montagem "real",  pois o Sistema identifica a seleção imediatamente, e isto refletirá automaticamente no LED "Alive".

      Observar que o Sistema original do Gabriel, "printava" na Serial do Arduino  a intervalos regulares,  algumas informações, como por exemplo o Acumulado de Chuva (e nesta implementação "printa" também o acumulado na última hora e nas últimas 24 horas). Isto foi mantido, mas pode ser facilmente excluído no código, ou então comentado para não ter mais efeito.

      Um "feature" interessante que acrescentei:  na inicialização,  se o Sistema não detectar o Sensor DS18B20,  ele faz 3 tentativas de detecção (o número de tentativas é facilmente alterado no código).  Então o sistema informa via Serial do Arduino,  se o DS18B20 foi ou não detectado, e a quantidade de tentativas que foram executadas.

      Da mesma forma, se uma Gravação no Cartão  falhar (seja qual for o motivo), o Sistema tenta até 5 vezes, sendo cada tentativa a cada 2 segundos,  e só desiste após todas as tentativas falharem (mas tentará novamente quando for o próximo momento de Gravar).  A quantidade de tentativas e o intervalo entre elas, pode ser também facilmente alterado no código.  As falhas também são informadas via Serial do Arduino (ou seja, via "Debug").

      Uma curiosidade:  alguns podem estar se perguntando, porque não usei um daqueles modelos de Arduino existentes para o Proteus, como por exemplo o do "TEP" (aquele site das Arábias). Ocorre que as entradas analógicas do Arduino MEGA naqueles modelos, não funcionam. Então usei o modelo do Processador ATMega2560  original do Proteus, pois este funciona sempre.

      Todas as características do Sistema estão bem claras e documentadas no código, assim como as possibilidades de configuração. Então acredito que não é necessário falar mais sobre elas aqui neste texto.

      Apenas aconselho que além deste post,  aqueles que forem implementar o Sistema, leiam o Histórico do tópico até aqui, para não deixar passar alguma informação relevante.

      Segue o código com períodos de tempo do Sistema "real":   "Estacao_Tempo_02.zip"

      E com períodos de tempo para facilitar a Simulação:   "Estacao_Tempo_02_simul.zip"

      Encerro minha participação neste tópico, mas fico disponível para quaisquer esclarecimentos sobre a implementação.

      Abrçs,

      Elcids

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço