limitador de RPM com arduino

[Thiago Miotto]

@ComandateGustavo Esse tipo de erro é bem normal, eu mesmo vivo fazendo

Eu recomendo marcar todas as variaveis, tipo ao invés de pot e potb,  use "pota e potb", ou "pot1 e  pot2", ou ainda colocar a funcao, tipo "potdelay e potfreq"
 

[aphawk]

5 horas atrás, ComandateGustavo disse:

será que justamente por este código usar a interrupção ele tem mais precisão porém perde desempenho em outras funções? Me corrija se entendi errado, mas quando ocorre a interrupção o AT328 para tudo o que está fazendo e foca naquilo que foi programado para fazer durante a interrupção, nesse caso contar pulsos, e justamente por contar exatamente todos os pulsos ele tem muito mais precisão, porém durante a interrupção ele faz apenas isso, não lê potenciometro nem manda nada para o monitor serial nem pisca led, então não é que ele está lento, é que ele está focando na contagem de pulsos e o restante fica em segundo plano dando impressão de estar mais lento, é isso?

 

Para saber exatamente eu teria de olhar o que essa library faz....

 

Sobre os Atmegas, eles não tem prioridade de interrupções, assim SEMPRE que ocorre uma interrupção ele é obrigado a atender imediatamente.

 

Quando ocorre uma interrupção, o programa pàra o que estava fazendo e vai para a rotina de interrupção.  A partir daí o controle de processamento pode ser exclusivamente dessa rotina, a menos que ela habilite novamente as interrupções  ( podem ser todas , ou algumas, ou apenas uma ), algo que é bem difícil de um programador não profissional continuar com o controle de tudo.

 

Meio off-topic mas interessante :

 

Eu particularmente habilito novamente todas as interrupções assim que ocorre uma interrupção,  mas uso alguns Flags para sinalizar quando eu não posso ser interrompido ( claro que acabo sendo interrompido por alguns nanosegundos até consultar os Flags mas isso não afeta nada em 99% dos casos ). Isto já é algo um pouco mais avançado para você neste momento do seu aprendizado, mas acho bom você saber , assim um dia saberá como proceder em algum problema mais sério de programação...

 

Voltando ao tópico :

 

Se essa rotina de interrupção foi escrita para manter o processamento com ela, sem liberar outras interrupções,  e ela resolver esperar a contagem de pulsos por 500 milissegundos, durante esse tempo nada mais vai funcionar, nem serial, nem display, nada... mas repare que isto é uma escolha do programador que escreveu essa library.

 

A sua conclusão final sobre a lentidão pode sim ser válida, mas para ter 100% de certeza só mesmo olhando o código-fonte dessa biblioteca.

 

Cá entre nós, gostei de ver essa sua dúvida, é a prova do que te falei antes, você continua aprendendo cada vez mais !

 

Infelizmente não consigo ajudar nada nesse seu programa por não saber programar nessa linguagem, então espere pelo pessoal mais habilitado nela para te dar mais informações,  ok ?

 

Paulo

[Sérgio Lembo]

11 horas atrás, ComandateGustavo disse:

usei o código cru sem nada e ele realmente é mais preciso do que o anterior, ele mede até décimos de frequência, mas é mais devagar do que o código usando a biblioteca  freqcount e curiosamente em frequências mais baixas fica mais lento ainda, a atualização das linhas do monitor serial sobem mais devagar, depois que passa de uns 150Hz aí começa a ficar mais rápido.

A questão é a seguinte: o programa executa uma sequência de leitura por evento. Assim sendo, se a frequência for de 1Hz terás apenas 1 leitura por segundo. Um pouco mais abaixo foi feita essa sequência:

if (FreqMeasure.available()) {
    // average several reading together
    sum = sum + FreqMeasure.read();
    count = count + 1;
    if (count > 30) {
      float frequency = FreqMeasure.countToFrequency(sum / count);
      Serial.println(frequency);
      sum = 0;
      count = 0;

 

com essa sequência o resultado será publicado a cada 30 medições. Isso explica a relação entre a frequência e a resposta.

Uma pergunta que deve se fazer: precisa mesmo de ter uma média de 30 medições? Fazer ou não média de leituras e a quantidade de leituras para fazer a média deve ser vista sob o ponto de vista da sua aplicação.

Existem várias formas de se descascar um abacaxi. Caso deseje ter uma grande média de leituras sem comprometer a velocidade da resposta pode-se montar uma tabela com ponteiro móvel rotativo:

- monta-se uma tabela de n posições

- a cada leitura o valor é gravado na posição apontada pelo ponteiro, o valor do ponteiro é incrementado, é feita a média de todas a s leituras da tabela e o resultado publicado.

- a cada incremento do valor do ponteiro verifica-se se este chegou ao final e se positivo este retorna ao início.

Com esta sequência terá a cada leitura a publicação da média das últimas leituras. Há um problema de ordem prática: se sua intenção é limitar uma rotação ter um sistema que depende de tantas leituras para se atualizar não irá prejudicar o performance do limitador? Nos valores em que pretende limitar a rotação veja quanto tempo ele demora para dar a resposta. Motor não acelera tão rápido assim, existe a questão da inércia. O bom senso deve entrar nesse momento para determinar o tempo máximo de resposta que o sistema pode ter para ser efetivo.

[aphawk]

@Sérgio Lembo

7 horas atrás, Sérgio Lembo disse:

- monta-se uma tabela de n posições

- a cada leitura o valor é gravado na posição apontada pelo ponteiro, o valor do ponteiro é incrementado, é feita a média de todas a s leituras da tabela e o resultado publicado.

 

Pode-se também fazer o processo de amortecimento exponencial, assim não precisa ficar guardando várias leituras, apenas a média do ultimo tratamento e a partir desta nova leitura calculo uma nova média. Eu uso muito nos meus programas para estabilizar a leitura dos sensores e potenciometros acoplados mecanicamente a algum tipo de eixo...

 

Paulo

[Sérgio Lembo]

@aphawk

Paulo

Estou montando um sistema que usa um sensor com vários metros de cabo. Como são centenas de leituras por segundo estava pensando em fazer média de 128 ou 64 valores com avaliação a cada leitura conforme descrevi acima além do clássico cabo torcido para matar os ruídos. Esse truque de amortecimento exponencial não conheço. Eu não conheço o Bascon, então descreva por pseudo-código, eu prefiro.

Sérgio

[aphawk]

@Sérgio Lembo ,

 

O nome técnico correto é Exponential Moving Average, ou EMA.

 

 

Bem simples e funcional, só depende de você ajustar o valor de alpha. Isso é experimental.

 

Eu uso como alpha o valor 45/64 , ou 0,7031. Funcionou muito bem com os movimentos dos rotores de antena, estabilizando bem a leitura do potenciômetro interno, e facilitou muito o cálculo pois uso variáveis tipo Word, ADC de 10 bits, e rotinas de 16 bits dentro de uma interrupção a cada 20 milisegundos e que não pode demorar muito...., a formula acima complica quando gera números negativos, então tive de particularizar esse calculo, multiplico o acumulador por 45,  depois multiplico a ultima leitura por 19 , somo as duas, e divido o resultado por 64, que é apenas um shift de 6 casas.

 

Para você ter uma ideia, esse potenciômetro fica a uma distância de 35 metros da placa controladora, e os fios não são torcidos e nem blindados, subindo na vertical, o que vira uma baita antena de ruídos .... uso filtros RC para dar uma limpada. A minha sorte é que o movimento mecânico é lento, demorando cerca de 1 minuto para ir de um extremo a outro do potenciômetro. Mas preciso medir tensões de  20 milivolts com uma boa precisão e estabilidade. Como uso um Atmega a 18.432 Mhz, consigo fazer o cálculo, converter para graus ( 0 a 359 ) , e calcular a posição de até 6 antenas, sem perder o tempo de 1 byte de dados a 9600 Bauds, graças ao buffer de 1 byte existente na serial por hardware, e sobra bastante tempo.

 

No seu caso, com centenas de leituras por segundo, uma boa opção seria usar o Adc com apenas 8 bits ( se puder claro ), facilitaria bastante os cálculos. 

 

Paulo

[Sérgio Lembo]

@aphawk

Por conta dos cálculos parti para o Arm M0, 32 bits de cálculo te dá muita liberdade. A intenção é gerar valores de até 16 bits e como somar 2 valores sem estourar a calculadora? daí os 32 bits.

Quanto ao filtro capacitivo, esquece. A leitura é por RC e também utiliza o capture do timer como o exemplo do tópico. Nas minhas experiências peguei um cabo paralelo e torci com uso da parafusadeira.

Quanto ao uso do shift faço o mesmo. Tenho algumas constantes de calibração <1. Ponto flutuante encarece o processador ou exige uma rotina que come memória e tempo. Então multiplico a constante por 64k para ter um número inteiro. Na parte do processo onde se aplica a correção multiplico a variável pelo número inteiro e depois faço o shift 16 com o requinte de testar o carry e arredondar o valor, apenas 2 instruções a mais, uma de 32 bits e outra de 16.

[mlegnari]

@ComandateGustavo quase me matou com esse código seu confuso kkk vamos começar do zero de novo, dessa vez vou te ensinar algumas lições, não podemos deixar que o legado da @.if de piscar um led seja perdido! Vem comigo vou ser seu "coach"  

 

Primeira coisa de todas você precisa aplicar alguns conceitos de programação método agil/scrum, você define o projeto, todas as funções e divide ele por prioridades ALTA/MEDIA/BAIXA. Não adianta você trabalhar em um LCD se não sabe nem se o básico esta rodando! Estamos falando de ignição, um erro de programação pode cortar sua centelha com uma carreta carregada na descida atrás de seu carro, o resto já sabe...

 

O mais importante ALTA é o motor cortar quando chegar em uma determinada rotação.

 

Ter um potenciômetro é legal para você ajustar durante o funcionamento o corte, apesar que você não ira mexer nisso toda hora e você pode usar tranquilamente com um corte já pré-programado, deixe isso como prioridade MEDIA e será pensado nisso somente após resolver a ALTA.

 

Display LCD é fofura, redundante, já que você tem o RPM do painel, então não apareça com isso no código até resolver o restante ok? 

 

Bibliotecas não devem ser usadas quase nunca principalmente por um iniciante, elas te deixará preguiçoso a pensar e você não terá conhecimento total do código que se passa. É claro que podemos abrir uma exceção e

usar algumas funções da IDE do Arduino que já economizam muito código e neurônios.

Um exemplo de quando usar biblioteca: mover um motor de passo que envolve uma lógica mais complexa! Ou usar um LCD que nos poupa tempo configurando pino a pino..

 

Calcular um simples intervalo de tempo não se deve usar não, e outra coisa, interrupção é algo que você deverá usar quase sempre no futuro, deve saber como fazer elas sem usar bibliotecas, não precisa fazer também a nível baixo com os registradores etc, seu projeto não requer tudo isso, mas usar uma biblioteca também é proibitivo.

 

O código abaixo trabalha nas interrupções em que o pino 2 vai de 0v para 5v, o circuito de interface com seu módulo você já tem exemplos nesse e outro tópico que fechou (deixe tudo num só o assunto é o mesmo, eu mesmo devo ser recordista em paginas dos meus tópicos dando trabalho para o pessoal nas minhas dúvidas) 

 

Sempre que houver um pulso, ele contabiliza uma flag, desabilita a interrupção para que o micro controlador possa trabalhar sem ser interrompido, calcula o RPM de modo mais acurado, se você usar frequência em números inteiros sempre terá uma precisão de no mínimo 80 rpm, desse jeito que te passei a precisão pode ficar praticamente 99% a partir de 3000 RPMs.

 

O if else depois é para ver se esta acima de 4000, caso sim, corta por 10 ms e depois descorta (ficaria estranho falar corte/emenda), deixando o motor girar de novo. Aqui você ajusta o RPM e a DURAÇÃO DO CORTE.

 

Existe algumas melhorias a se fazer, como por exemplo, não calcular o RPM caso esteja acima de um rpm inatingível pelo seu motor como 10000 RPM, isso indica que se subir disso houve alguma interferência/ruído que computou algo errado, você deverá descartar e:

 

Off: nesse momento eu penso que queria ter alguém me falando essas palavras quando comecei lá atrás, iria me poupar meses de trabalho e pesquisa...

 

Continua: acender um LED permanentemente quando houver um RPM acima de 9000 para indicar que seu circuito de aquisição ainda esta meio podregulho.

 

// Creditos: MARCELO LEGNARI
// Limitador de RPM v0.1


float pulso_atual; 
float pulso_anterior;
float diferenca;
float rpm;

int pulso_recebido;

void setup(){
  
 pinMode(2, INPUT); 
 pinMode(5, OUTPUT); 

 digitalWrite(2,LOW); 
 digitalWrite(5,LOW);
 
 attachInterrupt(digitalPinToInterrupt(2), pulso, RISING);
  
 pulso_atual=0;
 pulso_anterior=0;
 pulso_recebido=0;
 diferenca=0;
 rpm=0;
  
}

void loop(){
  
  if (pulso_recebido == 1){

  pulso_anterior = pulso_atual; 
  pulso_atual = millis(); 
  diferenca = pulso_atual - pulso_anterior; 
    
  rpm = ((1/diferenca)*60000);
 
  pulso_recebido=0; 
  interrupts(); 
  }
  
  if (rpm >= 4000){
    digitalWrite(5,HIGH);
    delay(10);
    digitalWrite(5,LOW); 
    }
    else{
    digitalWrite(5,LOW); 
    }
  
      
}

void pulso(){
  
 pulso_recebido=1;
 noInterrupts(); 
  
}

 

Continue a modificar o código SOMENTE EXTRITAMENTE OBRIGATORIAMENTE após testar se o corte funciona bacana, ajuste o RPM e a DURAÇÃO do mesmo, filma pra nós!

 

E cuidado onde você põe as instruções, esta usando leitura de potenciômetro no loop principal, esse loop se repete a menos de 100 microssegundos quando não há nada a processar, qual a necessidade de ler o potenciômetro nesse intervalo curto? Isso equivale a uma criança ter perguntar 10000 vezes por segundo durante uma viagem: esta chegando??? seu arduino vai ter enxaqueca e vai se autodestruir, além disso comprometer seriamente o timer para os cálculos, o pot demora 100us +- para ler, esse tempo deve ser respeitado antes de prosseguir, senão se você pedir uma leitura logo em seguida vai pegar uma leitura passada.

 

Feito os testes acima, adicione o recurso que te falei do LED para indicar se houve ruídos, isso é prioridade ALTA, pois vai inutilizar seu display LCD exibindo dados errados, e seu potenciômetro será só mais uma pedra no sapato para atrapalhar no desenvolvimento e até inviabilizar o mesmo caindo no desânimo e desistência.

 

Obs: lição de casa: nos meus 12/13 anos de idade quando tive contato com o C e o VisualBasic, eu queria muito aprender, mas nunca saia do básico, não havia livros ace$$iveis nem cur$o$ que eu pudesse fazer na época com meu pentium 166 em meios de pentium 4 pra cima, o que me ajudou MUITO foi: cada linha do código eu comentava e escrevia o que ela fazia, mesmo sedo besta:

 

tempo = 1; // atribui o valor 1 para a variável tempo

 

escrevia em todas até fixar na cabeça, reescrevia o mesmo código 50 vezes comentando do zero, nunca copiava e colava, fazia do zero, nível russo de loucura, quando me dei conta já tinha tirado as muletas e estava andando sozinho.

[Sérgio Lembo]

em revisão, posto depois

 

 

 

 

[GustavoH93]

2 horas atrás, mlegnari disse:

@ComandateGustavo quase me matou com esse código seu confuso kkk vamos começar do zero de novo, dessa vez vou te ensinar algumas lições, não podemos deixar que o legado da @.if de piscar um led seja perdido! Vem comigo vou ser seu "coach"  

 

Primeira coisa de todas você precisa aplicar alguns conceitos de programação método agil/scrum, você define o projeto, todas as funções e divide ele por prioridades ALTA/MEDIA/BAIXA. Não adianta você trabalhar em um LCD se não sabe nem se o básico esta rodando! Estamos falando de ignição, um erro de programação pode cortar sua centelha com uma carreta carregada na descida atrás de seu carro, o resto já sabe...

 

O mais importante ALTA é o motor cortar quando chegar em uma determinada rotação.

 

Ter um potenciômetro é legal para você ajustar durante o funcionamento o corte, apesar que você não ira mexer nisso toda hora e você pode usar tranquilamente com um corte já pré-programado, deixe isso como prioridade MEDIA e será pensado nisso somente após resolver a ALTA.

 

Display LCD é fofura, redundante, já que você tem o RPM do painel, então não apareça com isso no código até resolver o restante ok? 

 

Bibliotecas não devem ser usadas quase nunca principalmente por um iniciante, elas te deixará preguiçoso a pensar e você não terá conhecimento total do código que se passa. É claro que podemos abrir uma exceção e

usar algumas funções da IDE do Arduino que já economizam muito código e neurônios.

Um exemplo de quando usar biblioteca: mover um motor de passo que envolve uma lógica mais complexa! Ou usar um LCD que nos poupa tempo configurando pino a pino..

 

Calcular um simples intervalo de tempo não se deve usar não, e outra coisa, interrupção é algo que você deverá usar quase sempre no futuro, deve saber como fazer elas sem usar bibliotecas, não precisa fazer também a nível baixo com os registradores etc, seu projeto não requer tudo isso, mas usar uma biblioteca também é proibitivo.

 

O código abaixo trabalha nas interrupções em que o pino 2 vai de 0v para 5v, o circuito de interface com seu módulo você já tem exemplos nesse e outro tópico que fechou (deixe tudo num só o assunto é o mesmo, eu mesmo devo ser recordista em paginas dos meus tópicos dando trabalho para o pessoal nas minhas dúvidas) 

 

Sempre que houver um pulso, ele contabiliza uma flag, desabilita a interrupção para que o micro controlador possa trabalhar sem ser interrompido, calcula o RPM de modo mais acurado, se você usar frequência em números inteiros sempre terá uma precisão de no mínimo 80 rpm, desse jeito que te passei a precisão pode ficar praticamente 99% a partir de 3000 RPMs.

 

O if else depois é para ver se esta acima de 4000, caso sim, corta por 10 ms e depois descorta (ficaria estranho falar corte/emenda), deixando o motor girar de novo. Aqui você ajusta o RPM e a DURAÇÃO DO CORTE.

 

Existe algumas melhorias a se fazer, como por exemplo, não calcular o RPM caso esteja acima de um rpm inatingível pelo seu motor como 10000 RPM, isso indica que se subir disso houve alguma interferência/ruído que computou algo errado, você deverá descartar e:

 

Off: nesse momento eu penso que queria ter alguém me falando essas palavras quando comecei lá atrás, iria me poupar meses de trabalho e pesquisa...

 

Continua: acender um LED permanentemente quando houver um RPM acima de 9000 para indicar que seu circuito de aquisição ainda esta meio podregulho.

 

// Creditos: MARCELO LEGNARI
// Limitador de RPM v0.1


float pulso_atual; 
float pulso_anterior;
float diferenca;
float rpm;

int pulso_recebido;

void setup(){
  
 pinMode(2, INPUT); 
 pinMode(5, OUTPUT); 

 digitalWrite(2,LOW); 
 digitalWrite(5,LOW);
 
 attachInterrupt(digitalPinToInterrupt(2), pulso, RISING);
  
 pulso_atual=0;
 pulso_anterior=0;
 pulso_recebido=0;
 diferenca=0;
 rpm=0;
  
}

void loop(){
  
  if (pulso_recebido == 1){

  pulso_anterior = pulso_atual; 
  pulso_atual = millis(); 
  diferenca = pulso_atual - pulso_anterior; 
    
  rpm = ((1/diferenca)*60000);
 
  pulso_recebido=0; 
  interrupts(); 
  }
  
  if (rpm >= 4000){
    digitalWrite(5,HIGH);
    delay(10);
    digitalWrite(5,LOW); 
    }
    else{
    digitalWrite(5,LOW); 
    }
  
      
}

void pulso(){
  
 pulso_recebido=1;
 noInterrupts(); 
  
}

 

Continue a modificar o código SOMENTE EXTRITAMENTE OBRIGATORIAMENTE após testar se o corte funciona bacana, ajuste o RPM e a DURAÇÃO do mesmo, filma pra nós!

 

E cuidado onde você põe as instruções, esta usando leitura de potenciômetro no loop principal, esse loop se repete a menos de 100 microssegundos quando não há nada a processar, qual a necessidade de ler o potenciômetro nesse intervalo curto? Isso equivale a uma criança ter perguntar 10000 vezes por segundo durante uma viagem: esta chegando??? seu arduino vai ter enxaqueca e vai se autodestruir, além disso comprometer seriamente o timer para os cálculos, o pot demora 100us +- para ler, esse tempo deve ser respeitado antes de prosseguir, senão se você pedir uma leitura logo em seguida vai pegar uma leitura passada.

 

Feito os testes acima, adicione o recurso que te falei do LED para indicar se houve ruídos, isso é prioridade ALTA, pois vai inutilizar seu display LCD exibindo dados errados, e seu potenciômetro será só mais uma pedra no sapato para atrapalhar no desenvolvimento e até inviabilizar o mesmo caindo no desânimo e desistência.

 

Obs: lição de casa: nos meus 12/13 anos de idade quando tive contato com o C e o VisualBasic, eu queria muito aprender, mas nunca saia do básico, não havia livros ace$$iveis nem cur$o$ que eu pudesse fazer na época com meu pentium 166 em meios de pentium 4 pra cima, o que me ajudou MUITO foi: cada linha do código eu comentava e escrevia o que ela fazia, mesmo sedo besta:

 

tempo = 1; // atribui o valor 1 para a variável tempo

 

escrevia em todas até fixar na cabeça, reescrevia o mesmo código 50 vezes comentando do zero, nunca copiava e colava, fazia do zero, nível russo de loucura, quando me dei conta já tinha tirado as muletas e estava andando sozinho.

 

 

Eita eu fiz o teste hoje  a tarde mas foi com o código antigo @mlegnari vi seu comentário agora pouco se não eu teria testado seu código antes obrigado pela ajuda em breve vou testar seu código na prática, mas cheguei a um outro problema, como comentei antes o rele desliga o negativo da bobina, e descobri que isso interfere no conta giros do painel, dá pra ouvir no video pelo som do motor que ele não acelera, mas o conta giros do painel está indicando que está acelerando.

 

https://www.youtube.com/watch?v=nuu_5Zcra3Y

 

aqui o esquema da ignição, o problema é que ele não mostra a ligação do contagiros do painel, pelo que entendi o contagiros pega o sinal de pulsos com a bobina, não é o sinal que sai do módulo de ignição.

 

 

https://golcht.com.br/wp-content/uploads/2020/05/modulo142gauss-350x275.jpg

 

baseando pelo esquema, sabe de algum outro fio que podemos interromper no lugar do negativo da bobina?

[Sérgio Lembo]

@mlegnari

Tem uma coisa que não entendi no seu código: está usando a função millis como geradora de tempo e sempre comparando a atual com a anterior. A impressão que dá é que millis vai ao infinito, não zera nunca.

 

[mlegnari]

@Sérgio Lembo  Zera com uns 50 dias o Millis() já o micros() uns 70 minutos, daí tem um tratamento simples.. If Millis() < pulso_anterior, pulso atual = 0, da para usar essa lógica!

 

Curiosidade: cada vez o número fica maior, mas não estoura a float, eu simulei a matemática de números gigantes no atmega, o tempo que gasta para fazer 55950-60000 é o mesmo que gastaria para fazer dois números com 10000x o tamanho! Impressionante, pensei que fosse impactar uns 200us a mais quando começasse a aumentar o tamanho dos números!

 

Uma outra abordagem é resetar o timer a cada volta, mas Arduino já sabe como é né afeta várias funções que dependem do timer 1

58 minutos atrás, ComandateGustavo disse:

https://www.youtube.com/watch?v=nuu_5Zcra3Y

@ComandateGustavo seu painel deve estar ligado no negativo da bobina então!  Mas vamos ao ponto: o relê não vai servir mesmo! Vida útil curta. 

 

O fio do sinal do hall funciona como? Ele vai de 0 para 5v ou inverso? Eu colocaria um transistor para chavear ele para o terra, daí você iria trabalhar com baixa tensão e potencia, além de resolver o painel! Mas precisamos saber se ele trabalha com que nível de sinal! Experimenta ligar o relé nele puxando para o terra, caso de certo, substitui o relé por um transistor npn ou um mosfet de nível lógico (que com 5v você aciona ele plenamente direto da porta do micro controlador)

[Thiago Miotto]

Quanto ao caso do tópico, acredito que o não precisamos nos preocupar com o reset do millis.
Creio que cada vez que o motor for desligado o Arduino será desligado junto e  a contagem de millis zere.
Mas era uma curiosidade que tinha também, embora nunca tinha pesquisado sobre.

[GustavoH93]

2 horas atrás, mlegnari disse:

O fio do sinal do hall funciona como? Ele vai de 0 para 5v ou inverso? Eu colocaria um transistor para chavear ele para o terra, daí você iria trabalhar com baixa tensão e potencia, além de resolver o painel! Mas precisamos saber se ele trabalha com que nível de sinal! Experimenta ligar o relé nele puxando para o terra, caso de certo, substitui o relé por um transistor npn ou um mosfet de nível lógico (que com 5v você aciona ele plenamente direto da porta do micro controlador)

o hall vai de 0 para 8V nos testes eu usei um resistor de 1k em série para evitar queimar a porta do arduino, aqui tem um video detalhado de como funciona o sistema de ignição com o sensor hall, esse aí do video é exatamente o mesmo que o meu.

 

 

 

mas @mlegnari se eu interromper o sensor hall de mandar o sinal para o módulo de ignição o módulo também não vai mandar sinal para a bobina e sem sinal da bobina o conta giros do painel também não vai funcionar, ou estou enganado?

[mlegnari]

@Thiago Miotto pois é basta saber esses limites básicos de dias ou minutos e se atentar quando usar, mas colocar o artifício na programacao para saber se estourou o timer sempre é útil!

 

@ComandateGustavo não tem sentido você mandar sinal para bobina e cortar ele, já corta na fonte! Experimenta cortar o hall. O painel até onde eu sei, usa motor de micropassos, ele não vai zerar de uma só vez quando cortar, até porque ele começa a fechar e antes de zerar já voltou o sinal, você o vera oscilando entre o corte e o rpm que retornou o pulso, essa oscilação depende da duração do corte, testes e testes.

[GustavoH93]

17 horas atrás, mlegnari disse:

não tem sentido você mandar sinal para bobina e cortar ele, já corta na fonte! Experimenta cortar o hall. O painel até onde eu sei, usa motor de micropassos, ele não vai zerar de uma só vez quando cortar, até porque ele começa a fechar e antes de zerar já voltou o sinal, você o vera oscilando entre o corte e o rpm que retornou o pulso, essa oscilação depende da duração do corte, testes e testes.

@mlegnari pois é só testando mesmo, estava pensando de qualquer forma cortando a bobina ou o hall o efeito no ponteiro vai ser o mesmo, mas essa oscilação é um "mal necessário" como ele é ligado na bobina vai ter que ser assim mesmo, em breve vou testar novamente com seu código, levei o carro para polir a pintura hoje cedo, na quarta feira pegarei ele de volta e aí continuarei com os testes... 

[mlegnari]

@ComandateGustavo vi sua cidade ai no perfil Limeira esta aqui perto de Rib Preto SP! eu não atualizei a minha, não moro em minas faz tempo !

 

Se você cortar o sinal do hall o ponteiro não vai subir! primeiro que, ele deveria estar ligado no modulo (saída tacômetro) mas por algum motivo não esta ou não parece estar... faz um teste: desliga o fio de saída do tacômetro do modulo, veja se o painel ainda responde! se for o caso nos aterramos ele também! mas eu enxergo isso como um nível MEDIO de prioridade, testa o que te passei de código veja se vai cortar legal, depois desenvolve o detector de ruídos como propus acima, garantindo que não tem ruídos e que corta legal no rpm que você escolheu a gte parte para essa parte do painel e depois as pequenices como alterar o corte por chavinha, potenciômetro etc...

[GustavoH93]

Em 12/05/2021 às 11:00, mlegnari disse:

vi sua cidade ai no perfil Limeira esta aqui perto de Rib Preto SP! eu não atualizei a minha, não moro em minas faz tempo !

limeira e ribeirao preto tem quase 200km de distância, não é muito perto não kkkkkk mas também não é longe, já fui pra ribeirão algumas vezes...

 

 

Em 12/05/2021 às 11:00, mlegnari disse:

desliga o fio de saída do tacômetro do modulo

não tem como esses carros VW mais antigos o tacometro pega o sinal do rpm diretamente pela bobina o tacometro não tem nenhuma conexão direta com o módulo...

 

Em 12/05/2021 às 11:00, mlegnari disse:

testa o que te passei de código veja se vai cortar legal, depois desenvolve o detector de ruídos como propus acima, garantindo que não tem ruídos e que corta legal no rpm que você escolheu a gte parte para essa parte do painel e depois as pequenices como alterar o corte por chavinha, potenciômetro etc...

certo @mlegnari vou fazer isso hoje, estava meio ausente porque mandei o carro para polir então demorou um pouco lá com o rapaz, mas já está de volta, vou fazer o upload do seu código e testar do jeito que está, interrompendo o negativo da bobina de ignição, o tacometro é o de menos, depois que conseguirmos limitar a rpm certinho aí vemos os outros detalhes.

@mlegnari acabei de testar, primeiro fiz os testes na bancada e funcionou normalmente, não tinha monitor serial pra ver a frequência medida, mas dava pra ouvir o rele ligando e desligando.

 

Mas na hora de testar no carro nada feito, ao girar a chave o arduino fica doido ligando e desligando o rele, o motor mal consegue ligar, será que é interferencia do motor de partida?

[mlegnari]

@ComandateGustavo deixe a placa desligada e o rele desligado, ligue o carro, após isso ligue a placa e veja se o relê fica doido ou se fica a espera dos 4000rpm

[GustavoH93]

3 horas atrás, mlegnari disse:

@ComandateGustavo deixe a placa desligada e o rele desligado, ligue o carro, após isso ligue a placa e veja se o relê fica doido ou se fica a espera dos 4000rpm

abaixei para 2000 rpm para não ficar girando muito o motor, o escapamento é esportivo então faz bastante barulho, será que para 2000 rpm o código não tem muita precisão e fica doido ou não tem nada a ver? liguei o carro e depois liguei o arduino nos 12v da bateria e aconteceu a mesma coisa.

[GustavoH93]

@mlegnari estou aguardando a sua resposta para prosseguir enquanto isso nas horas livres estou fazendo alguns ajustes no carro, trocando válvula termostática, fluido do radiador... Carro antigo sempre tem coisas pra fazer 

[mlegnari]

@ComandateGustavo testei aqui na bancada e no simulador esta ok, filma seu teste na bancada para eu ver! Como na sua bancada deu certo e no carro nao?

[GustavoH93]

@mlegnari também não sei como deu certo na bancada e no carro não, estou usando apenas o opto acoplador para ligar o rele, na bancada funcionou de boa no carro ficou doido... vou filmar o teste na bancada e no carro. Estou demorando para atualizar porque estou fazendo outras coisas no carro e tive que fazer umas coisas no motor, essa semana eu testo certinho e coloco o video.

[Sérgio Lembo]

Ruídos, ruídos e ruídos. É o que diferencia o teste de bancada e a realidade da aplicação. São 2 as linhas de trabalho nessas condições:

1 - Blindagem, supressão de ruídos, filtros e afins. É um método fácil quando a sujeira elétrica possui características muito distintas do sinal real. Torna-se complicado quando a característica da sujeira se assemelha ao sinal.

2 - Convivência com os ruídos. Isso pode provocar um atraso de resposta ou imprecisão, tem que mensurar e analisar se tais efeitos são aceitáveis na sua aplicação.

 

Nas postagens disse que o sistema fica doido no carro mas vai bem na bancada. Isso indica que o sistema é bom e a instalação ruim. Quero te lembrar que o carro utiliza a carcaça como referência e condutor de zero e que o aço não é o melhor dos condutores. Se está usando o sinal do sensor Hal na entrada do Arduíno então o zero do Hal tem que ser o mesmo que o zero do arduíno. Entre a bateria do carro e o arduíno existem comprimentos de cabo e comprimentos de cabo são antenas receptoras de ruídos. Vale o mesmo raciocínio entre a bateria e o sensor Hal. Dessa forma ter uma ligação entre o zero do arduíno e o zero do sensor Hal torna-se importante. O outro sinal que te interessa é a saída do sensor Hal. Sendo este sinal uma ddp entre a saída e o zero do Hal precisamos desse par de fios para sensibilizar a entrada do arduíno. No percurso esse par de fios estará sujeito aos ruídos. Trançar o par tal qual se faz com os cabos de telefonia e cabos de rede é um excelente método de supressão de ruídos. Não basta ter o sinal, este tem que chegar com qualidade no destino.

 

De forma adicional ao parágrafo acima pode implantar no programa uma sequência de validação para corte da bobina. Já que a frequência de corte é 66Hz, isso significa 16ms de intervalo. Uma sequência de 2 ocorrências sequenciais para validação do corte vai atrasar a resposta em 16ms. Vamos então criar uma variável validade.

 

na inicialização, validade = 0

 

A parte decisória do programa está assim:

if (rpm >= 4000){

  digitalWrite(5,HIGH);

  delay(10);

  digitalWrite(5,LOW);

  }

  else{

  digitalWrite(5,LOW);

}

Com a validação ficará assim:

if (rpm < 4000){

  digitalWrite(5,LOW);

  validade = 0

  }

  else{

  validade ++

  if (validade > 1){

    digitalWrite(5,HIGH);

    delay(10);

    digitalWrite(5,LOW);

  }

}

 

[GustavoH93]

13 horas atrás, Sérgio Lembo disse:

Arduíno então o zero do Hal tem que ser o mesmo que o zero do arduíno

o zero dos dois é o negativo da bateria @Sérgio Lembo

13 horas atrás, Sérgio Lembo disse:

Trançar o par tal qual se faz com os cabos de telefonia e cabos de rede é um excelente método de supressão de ruídos. Não basta ter o sinal, este tem que chegar com qualidade no destino.

isso de trançar os cbos eu não sabia, achei que era apenas para facilitar a organização interna dos cabos, bem interessante isso vou trançar os cabos.

 

13 horas atrás, Sérgio Lembo disse:

if (rpm < 4000){

  digitalWrite(5,LOW);

  validade = 0

  }

  else{

  validade ++

  if (validade > 1){

    digitalWrite(5,HIGH);

    delay(10);

    digitalWrite(5,LOW);

  }

}

vou implementar no código para ver como fica, bem interessante a sua resposta, vou alterar o código em breve e testar na bancada depois no carro, realmente deve ser interferência que está causando o problema, mas curiosamente no código anterior apesar de ser impreciso não tinha esse problema, será que a função interrupt é mais sucetível a interferencias @mlegnari ?