besoin d'aide dans le choix d'une solution

[minioim]

Salut à tous

je suis toujours sur mon histoire d'automatisation d'une moto, ce qui implique un compte tour.

première grosse nouvelle: mon compte tour simple fonctionne plutôt pas mal. en simulation on est bon, (une ou 2 instabilité à certaines fréquences du moteur ceci dit mais peut être du à la simulation? je vois pas trop d'autre explication)

et en vrai, sur la moto... bah... ça tourne, le régime moteur s'affiche globalement bien mais le problème c'est que ça "vibre" à une vitesse assez phénoménale. comprenez par là qu'il y a pas mal de "bruit". en gros mon compte tour affiche des valeurs qui varient de + ou - 200 tr/min entre chaque mesure (et il effectue une mesure à chaque impulsion venant du moteur, sachant qu'à 1000 tr/min, celui ci envoie du 33Hz, à 2000 du 66Hz, etc...)

cette variation n'est pas acceptable pour mon projet et je suis tiraillé par le compromis entre précision/stabilité/vitesse de mesure.

en effet j'ai pensé aux solutions suivantes:

faire une mesure sur un temps fixe et au lieu de mesurer les périodes, mesurer le nombre d'impulsions donc la fréquence. mais si je prends une période trop courte, j'ai de grosses variations de fréquences (en fonction de quand tombent les ticks)
si je prend une période plus longue... je perds fortement en vitesse de mesure, or je peux pas me permettre d'afficher un régime moteur une heure après qu'il ait été atteints..

j'ai donc pensé à une autre solution: compter 5 périodes (donc le temps entre 5 impulsions) puis faire la moyenne -> même principe qu'actuellement mais permettant d'avoir plus de tolérance au bruit. à 1000tr/min, ça fait un rafraîchissement de la mesure de 6.6Hz, c'est un peu limite mais passe encore je pense... et puis 1000 tr/min... la moto n'y est jamais. on est au mini à 2000 au ralenti, 4000 en utilisation normale tranquille. donc 13Hz en utilisation lente, ça va encore j'imagine... à tester quand même


enfin reste la solution de convertir la fréquence en tension, ce qui implique du hardware à coté, méthode utilisée par le compte tours à aiguille déjà installé sur la moto (de 1987). soit une conversion en tension, elle même convertie en courant qui alimente un galvanomètre.
une fois la fréquence convertie en tension, utiliser les convertisseur A/D du 16F877 pour traiter l'info.


devant toutes ces solutions, j'aurais besoin d'un petit coup de main pour déterminer la plus efficace/robuste/précise, en fonction de votre expérience... voire m'en indiquer une autre qui surclasse ces 3 là

pour infos:
le signal a traiter est un signal carré de 0 à 10V, de ratio 66% (fixe), de fréquence variable correspondant à 33Hz/1000rpm.
je dispose d'un 16f877 et d'un quartz de 4MHz ou d'un autre de 20MHz



merci à vous,
François
-----

[paulfjujo]

Peux-tu rappeler quel est le post de depart sur ce probleme?
ou remettre un lien sur le programme faisant cette mesure.

Est ce que la mesure de periode ( frequence indirectement) est bien calée sur un front montant pour le depart
et un front descendant pour l'arret de comptage ..
Y a til des debordement de timer possible ?

As tu testé ton programme avec un generateur de 33Hz à ...
33,1 33,2 ..
si c'est OK, le probleme peut etre aussi au niveau de ton signal , mal mis en forme
ou insuffisament filtre pour les frequence superieure à 330 Hz ,
en supposant 10.000 Tr/Mn comme maxima

[minioim]

salut,

hum en fait j'ai plusieurs sujets qui traitent de différent problèmes (je suis sur plusieurs projets qui se recoupent souvent)
pour la mesure de fréquences, non je n'étais pas calé sur front montant et descendant. j'utilisais juste les débordements de timer en comptant le nombre d'impulsions entre 2.
pour la mesure de période par contre oui je suis bien calé sur les fronts montant (je compte entre 2 fronts montant consécutifs avec des timer sans prescal donc une résolution de 1µs)

les débordement de timer sont pris en compte.

pour le test du programme, je n'ai que le simulateur de proteus (où j'utilise effectivement le générateur de signal) et la moto.



ma question reste valide (on est jamais à l'abris de trouver mieux )

cependant, je viens d'appliquer la méthode de la moyenne des périodes (en comptant donc le temps entre 5 périodes pour en faire la moyenne sur une période et le calcul à partir de là)

ça donne un résultat tout à fait probant. précis au niveau du compte tour (au moins à la centaine de tr/min (je n'ai que 2 afficheurs 7 segments donc j'affiche les milliers et les centaines)) et cela jusqu'à 5000tr/min (la moto n'a pas tourné depuis 3 semaines, elle est pas toute jeune, donc je ne l'ai pas poussé au delà pour l'essai)
et la vitesse de rafraîchissement est suffisante.

et surtout... le "bruit" a disparu.

gros avantage: la solution est purement software (ça me facilite la vie question montage)

mais ceci dit je reste à l'écoute, si par hasard quelqu'un avait une meilleure méthode à proposer? même en hardware par curiosité au moins

merci en tout cas pour la réponse paulfjujo

ps: le programme je l'afficherais une fois mis en forme, c'est un peu le bordel pour le moment entre les différentes versions, les parties que je passe en com pour les tests etc...

[Qristoff]

Bonjour,
est-ce que tu peux au moins nous montrer la fonction qui réalise la mise en forme du signal avant d'entrer dans le µC ? en environnement bruité, elle doit être pas mal robuste aux perturbations.

[A voir en vidéo sur Futura]

[minioim]

Salut, hum... Qu'appelles tu la fonction qui réalise la mise en forme?

Pour l'instant j'ai récupéré la sortie du CDI (boitier qui contrôle l'allumage de la moto) qui alimente le compte tour. Je l'ai dérivé vers mon microcontroleur et basta...
A l'oscillo le signal est propre, je pourrais mettre une photo dans 2 jours (quand j'aurais mon PC sous la main) si besoin.

Et quand je fais la moyenne sur 5 périodes, j'ai un résultat stable et précis donc vu le nombre limité de périodes utilisées pour la moyenne, si le signal était trop moche et créait des fausses impulsions je le verrais non?

Pour info, les variations que j'avais correspondaient a du +/-200 tr/min soit une différence de moins de 200 microsecondes entre 2 impulsions a 5000 tr/min... En pourcentage ça ferait environ 3%. Donc finalement quelque chose de faible dans les écarts quand même.

[paulfjujo]

bonjour,

'ai donc pensé à une autre solution: compter 5 périodes (donc le temps entre 5 impulsions) puis faire la moyenne ->

Bizarre, pourquoi 5 ?
avec le mode capture le choix est plutot 4 ou 16

bit 3-0 CCPxM3:CCPxM0: CCPx Mode Select bits
0000 = Capture/Compare/PWM disabled (resets CCPx module)
0100 = Capture mode, every falling edge
0101 = Capture mode, every rising edge
0110 = Capture mode, every 4th rising edge
0111 = Capture mode, every 16th rising edge

[minioim]

Salut,
Hehe tout simplement parce que je me suis pas encore intéressé a toutes les fonctions dispo... Vais m'intéresser au mode capture coup (ça se trouve je l'ai refais manuellement...)

[minioim]

Yop, bon effectivement le mode capture refait globalement ce que j'ai fait manuellement. Il semblait fort intéressant a première vue mais, si j'ai bien tout compris, il a quand même un défaut pour moi: il utilise uniquement le timer1. Or j'ai 2 fréquences a mesurer... Et elles ne sont pas du tout du même ordre (33-400Hz contre 0.5-7Hz)
Ça rend un peu galère la mesure précise, même en enregistrant le nombre de dépassement du timer...
A moins que je ne passe a coté de qqc, je dois pas être le premier a vouloir faire 2 mesures de fréquence, quelqu'un a une meilleure piste svp?
Merci!

[paulfjujo]

Si tu ne mesure pas ces 2 gammes de frequence en simultané
tu peux mesurer la gamme basse ,simplement en mode pooling
et accumulation dans une boucle basée sur le nombre de cycles
avec un timer quelconque te generant le top seconde.
La resolution devrait etre tres grande!

Quand bien meme, tes 2 gammes de frequence n'etant pas si elevées que cela;
meme si le timer 1 est mobilisé,c'est transparent avec le mode CCP
qui fait tout le boulot..
le seul item à surveiller etant le nombre de debordement timer1.
les autres timers peuvent evoluer en meme temps..et pas forcement en mode interrupt
pouvant brouiller le traitement timer1 et CCP

[minioim]

Merci pour tes réponses.

alors les 2 gammes de fréquences doivent être mesurées en même temps (une comparaison étant effectuée en permanence)
utiliser le mode CCP revient au final à récupérer les interruptions dues au changement d'état d'une pin (genre RB0/INT au lieu de la pin CCP1) et, lors de l'interruption, lire la valeur du timer, la sauvegarder dans une variable, puis la traiter dans le programme principal. Tout en surveillant les dépassement du timer utilisé et en les comptant via les interruptions de débordement pour les prendre en compte.

le mode capture du module CCP fait bien globalement la même chose right? il copie l'état du timer dans un registre dédié (au lieu d'une variable perso) au moment du changement d'état de la pin dédié.

donc finalement il apporte peu de choses pour moi... peut être un code plus simple et plus court (ce qui justifie déjà de l'utiliser en soi).

par contre mon principal soucis en ce moment c'est les interruptions. ma méthode déclenche une interruption à chaque impulsion venant de l'une ou l'autre des fréquences à mesurer. ce qui présente le risque que 2 impulsions tombent en même temps et que l'une soit donc ignorée. le risque est statistiquement léger, je suis d'accord, mais diviserait par 2 la fréquence mesurée d'un coup... pouvant provoquer des dysfonctionnement derrière.

Est ce qu'il y aurait moyen d'éviter toutes ces interruptions?

[paulfjujo]

le mode capture du module CCP fait bien globalement la même chose right?

a un petit detail pres, c'est qu'il fait tout seul la lecture du timer, et que cela
ne gaspille pas de cycle machine, alors que manuellement
il faudrait rentrer à chaque fois dans un traitement d'interruption
et aller chercher la valeur du timer , donc a quelques cycles pres...
il apporte donc un peut plus de precision temporelle.

Est ce qu'il y aurait moyen d'éviter toutes ces interruptions?

Pour traiter l'autre mesure à frequence basse
tu peux utiliser l'interruption LOW LEVEL ex associé avec Timer0 +prescaler 1/256 pour gerer
la fenetre de comptage de 1 seconde...
il n'y aura alors que tres peu d'interruption pour compter jusqu'à 1 seconde..
et utiliser le mode pooling pour mesurer , par comptage de cycle , la frequence basse,
pendant ladite seconde.


et pour traiter la frequence plus rapide (Timer1) avec l'interruption HIGH LEVEL
dans laquelle tu peux inclure le comptage du nb de debordment timer1.

sur 1 seconde , tu risque de louper quelques cycles seulement
avec Q=20Mhz x fois 0,2 µsec. par rapport à 1000 000 µsec

Il n'y a pas moyens d'eviter les interruptions
si tu veux avoir quasiment les 2 infos en meme temps..
la notion de temps reel etant toujour relative .. à quelques x 0,2µS

[minioim]

Autant je comprend l'idée que le CCP évite l'interruption pour recopier la valeur du timer, il le fait tout seul. mais il faut bien que je réinitialise le timer après que sa valeur ait été recopiée, et ça à part dans l'interruption déclenchée par le CCP je vois pas trop comment faire, donc au final, ça passe par le traitement de l'interruption non?


je n'ai par contre pas vraiment compris ta 2 ème partie de réponse. et surtout qu'est ce que le "mode pooling"? j'ai cherché mais je tombe surtout sur des trucs de joueurs...

merci

[paulfjujo]

Autant je comprend l'idée que le CCP évite l'interruption pour recopier la valeur du timer, il le fait tout seul. mais il faut bien que je réinitialise le timer après que sa valeur ait été recopiée, et ça à part dans l'interruption déclenchée par le CCP je vois pas trop comment faire, donc au final, ça passe par le traitement de l'interruption non?

je n'ai jamais dis le contraire.. sauf qu'avec le choix 16 edges .. tu ne le fait pas à chaque periode.
et qu'il n'y a pas de pertes de cycle machine..

je n'ai par contre pas vraiment compris ta 2 ème partie de réponse. et surtout qu'est ce que le "mode pooling"? j'ai cherché mais je tombe surtout sur des trucs de joueurs...

sorry, erreur syntaxique : polling avec un seul O

http://en.wikipedia.org/wiki/Polling_(computer_science)