Blista, effectivement, c'est la FFT qui est utilisée dans les oscilloscopes à mémoire
Mais bon, je pense que je passerai mon tour pour la recherche, j'en ai assez vu des transformées de fourrier
(même rapides).
Natraya a écrit :Il n'y a pas de commutation mécanique (donc pas d'effet rebonds provoquant une fréquence parasite, je pense que tu fais allusion à cela)
Non, je faisais pas du tout allusion à ça, du moins pas dans le morceau que tu avais cité, mais laisse tomber, j'arriverai pas à te faire comprendre ce que je voulais souligner et je veux pas polluer un topic intéressant ...
Et tu as raison quand tu dis que si (et seulement si) c'est bien fait, ça reste possible, mais il n'y a pas que des ingénieurs en traitement du signal sur ce topic ... je voulais juste faire une mise en garde pour ceux qui ne maitriseraient pas le sujet, mais si tu préfères te foutre de ma gueule, soit ...
Je comprends et approuve les dires de folken. En restant en tout numérique, on ne va pas engendrer de parasites "mécaniques" sur le signal, mais lors de l'analyse (type FFT si on s'oriente là-dessus) les variations brutales du signal engendrées par le couper/coller des "octets" (même en tout numérique, j'insiste sur ce point) vont apparaitre bizarrement après processing... même si c'est tout numérique. Pour faire une image (et j'espère n'embrouiller personne), c'est comme du suréchantillonnage, tu engendres des défauts de par ta manière de traiter le signal.
Tout ça pour dire qu'il ne suffit pas de savoir coder une FFT et un masquage d'une zone temporelle pour être au point, puisque le masquage va modifier le signal et fausser les résultats de la FFT...
folken, tu parlais bien de ça au moins ?
Topic tres intéressant !
Bravo à Romchip pour le boulot de post traitement effectué pour comprendre le fonctionnement et la gestion du cliquetis en registres ! Ca a du etre loonnnnnggg !
Dommage que je n'ai pas une gestion Nistune car ca a l'air de bien évoluer par rapport à ma Haltech qui est un peu out of time !
Natraya, ce que tu dis n'est pas tout a fait exact, une numérisation ne se fait presque jamais en continue... la plupart des uC et dspic industriels ont des ADC de type SAR (approx successives) ou il te faut une certaines électronique amont pour fixer le settling time lors de l'échantillonage de ton ADC (tu fais un sample and hold à la fréquence de conversion). Idem pour les convertisseurs Pipeline ou tu as un sample & hold en entrée.
On a donc bien une commutation sur le signal analogique qui attaque le convertisseur. Apres, c'est vrai que ca n'apporte pas de bruit supplémentaire si les compodants discret sont bien choisis.
Seul les ADC Delta-Sigma font réellement du continue car tu fais un suivi de la tension d'entrée mais ou tu as une latence importante suivant le filtrage utilisé (filtre sync par ex.)... Ce type de convertisseur est tres rare dans les uC.
J'ai aussi passé pas mal de temps à "étudier" le capteur de cliquetis (sur Honda par contre). La pluspart des capteur de cliquetis automobiles sont des capteurs piezo déjà calibré pour résonner à une fréquence propre déterminé en fonction des mode de vibration de l'ensemble mtoeur (en général, ils sont ajuster sur les harmoniques de rang 1 ou 2 et non le fondamental à cause du bruit ambiant basse fréquence causé par les soupapes, injecteurs, culbu...)
Le meilleur traitement qui puisse être fait sur ce type de capteur et un traitement humain ! Et oui, c'est dur de faire un filtrage adaptative aussi performant que notre cerveau...
Je ne peux que vous conseillez de faire un spectrograme plutot qu'une FFT (sous matlab par exemple), vous aurez bcp plus d'infos au premier coup d'oeil sur ce qui se passe à toutes les fréquences ! Et ca se fait en temps réel donc il est possible de le faire à partir de l'entré micro de votre carte son !
Ex:
http://www.mathworks.com/products/signal/?BB=1
![[Image: sg_mainimage_wl_4216.gif]](http://www.mathworks.com/cmsimages/sg_mainimage_wl_4216.gif)
boyou2 a écrit :boyou2 a écrit :RomChip_200 a écrit :Pour ceux que cela intéresse, je sais mettre en évidence à travers Consult, donc sur route, l'apparition de cliquetis à une charge et régime donné, je sais le logger. J'ai compris la stratégie du calculateur dans le retard de l'allumage et le retour à la normal.
Tout cela permet de faire un travail à posteriori, optimiser la carto aux limites sans cliquetis.
ca serait pas une descente de l'avance a l'allumage par incrementation de quelques degres(genre 5° moteur)avant de revenir a la valeur nominal+1°(ou plus),puis detection du cliquetis,puis redescente,puis retour a la valeur normal+1(ou plus),etc....??
car si c'est ca,ca fait 3ans que je le sais
=
kweko a écrit :ok, donc il ne va pas lire du tout dans la deuxième carto comme je le pensais à la base, mais il crée des incrémentations réduisant l'avance jusqu'à la disparition du cliquetis??
Mais en plus, je l'avais lu ton post sur le fofo de la nistune, mais je n'avais pas réagit 
faudrait que je m'inscrive d'une fois pour toutes pour échanger les infos!
:roll:
Je parlais dans le cadre de la nistune, car il y apparait une map secondaire de fuel/timing exprés pour le knock alors qu'a aucun moment en fouillant le logiciel je n'ai trouvé d'incrémentations concernant la baisse d'avance en cas de cliquetis :roll:
folken a écrit :mais si tu préfères te foutre de ma gueule, soit ...
Arf ! non ! loin de là, désolé si c'est l'impression que j'ai donné, c'est mon plus gros défaut, je crois qu'on c'est mal compris ou que je t'ai mal compris donc pour éviter de polluer
MP
kenini on est d'accord ! "continu" est un terme très mal choisie dans ce cas de figure.