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.
sur quel bloc t'as essayé??
Ca m'intéresse, ce sujet.
Ca me fait penser que sur la Nistune ils l'ont fait aussi, mais après coup ils se seraient rendus compte que la fréquence d'échantillonnage était pas assez rapide sur certains ecus
Le Consult relevait aucun cliquetis lors d'un passage au banc alors qu'elle cliquetait beaucoup
c'était sur une skyline je crois, mais j'ai un doute.
Je me demandais si c'est le même principe ?
Mais là ils comptaient les coups de knock, peut être que l'ecu est plus réactif pour "juste" basculer entre les cartos.
Et ça a peut être été corrigé depuis, en plus.
le sujet m'intéresse beaucoup surtout pour la stratégie, tu peux développer s'il te plait ?
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
Boyou, tu es un détracteur
Connaître le principe général est une chose, le mettre en évidence sur les bonnes variables en est une autre, au degré près.
Il faut qu'il y ait des accélérations particulières et fortes sans cliquetis pour générer un retour PROGRESSIF à la normale.
Je dis tout là :
http://forum.nistune.com/viewtopic.php?p=8496#8496
respect ! Je sais ce que ça représente ! Pour avoir étudier les registres du NATS, le cryptage/logique, etc... je sais ce que c'est quoi taff, mais ça reste un taff bien plus facile que ce que tu as fais, là faut titiller des capteurs !
D'ailleurs tu as fais comment pour le stimuler ???
il a peter a cote du capteur
Rhaaa!! J'aimerais bien avoir du beau matériel!!
J'ai ni Consult (CA18) ni Nistune. Pour le cliquetis, j'ai un bricolage qui va vous faire marrer mais qui me donne, à peu près satisfaction:
Je récupère le signal cliquetis à la pin du calculateur, je le raccorde à une prise jack mâle sur la borne signal et je récupère la masse ECU pour faire masse. Je plugge dans le PC portable sur l'entrée audio et j'enregistre en échantillonnage maxi en mono grâce à un petit logiciel d'acqui appellé Goldwave.
Ensuite, j'écrête entre 5 et 7kHz (plage de fréquence du cliquetis) et j'affiche le spectre avec un rendu graphique faisant varier la couleur avec l'intensité du signal... et j'identifie le cliquetis.
Je sais c'est 45min de post-traitement pour une seule accel mais c'est le seul moyen à ma disposition pour le moment.
Un jour je passerai peut être au Nistune (et j'arrêterai aussi avec ce fichu effaceur UV et le Burn d'EPROM qui foire une fois sur deux)!!
... et je pourrai profiter des trouvailles savantes de Romchip!!
Justement, d'après ce que je comprends de la nistune, sur SR20, le knock a une plage allant de 7.5 à 9khz. Donc si l'ecu detecte cette plage, il bascule sur les secondary fuel &timing map. Par contre pour ce qui est du quid de la réactivité, j'en sais pas plus...
kweko a écrit :Justement, d'après ce que je comprends de la nistune, sur SR20, le knock a une plage allant de 7.5 à 9khz. Donc si l'ecu detecte cette plage, il bascule sur les secondary fuel &timing map.
http://www.phormula.co.uk/KnockCalculator.aspx
6.7kHz sur sr20 d'après ce calculateur.
Mais je sais pas ce que ça vaut réellement ...
Jibe a écrit :Rhaaa!! J'aimerais bien avoir du beau matériel!!
J'ai ni Consult (CA18) ni Nistune. Pour le cliquetis, j'ai un bricolage qui va vous faire marrer mais qui me donne, à peu près satisfaction:
Je récupère le signal cliquetis à la pin du calculateur, je le raccorde à une prise jack mâle sur la borne signal et je récupère la masse ECU pour faire masse. Je plugge dans le PC portable sur l'entrée audio et j'enregistre en échantillonnage maxi en mono grâce à un petit logiciel d'acqui appellé Goldwave.
Ensuite, j'écrête entre 5 et 7kHz (plage de fréquence du cliquetis) et j'affiche le spectre avec un rendu graphique faisant varier la couleur avec l'intensité du signal... et j'identifie le cliquetis.
ta technique n'est pas si con que ça ! C'est même certainement plus efficace que l'ECU ! Il faut juste synchroniser la phase d'écoute avec les phases de compressions et tu élimine les bruits parasites !
Respect !
Pourquoi tu veux synchroniser ?
Tu filtres en fréquence, et tu vois si le cliquetis se pointe.
Je voulais le faire à une époque ... et puis j'ai laissé tomber
mais c'est la méthode la plus efficace, les détecteurs de cliquetis du commerce font comme ça, l'ecu aussi mais en moins évolué.
Le mieux ça reste d'enregistrer le bruit "normal" du moteur, pour faire des comparaisons ensuite.
folken a écrit :kweko a écrit :Justement, d'après ce que je comprends de la nistune, sur SR20, le knock a une plage allant de 7.5 à 9khz. Donc si l'ecu detecte cette plage, il bascule sur les secondary fuel &timing map.
http://www.phormula.co.uk/KnockCalculator.aspx
6.7kHz sur sr20 d'après ce calculateur.
Mais je sais pas ce que ça vaut réellement ...
tiens, faut que je vois sur la nistune comment s'effectue la commande exactement.
la methode des ecouteurs,avec ampli,et acqui en temps reel est la meilleure Jibe
tout les tuner,sur banc,font de cette maniere
c'est 'empirique',mais ca s'adapte a toutes voitures sans investissement surrealiste
Oui mais ça reste du domaine de l'analyse. Alors que si tu arrives à trouver les fréquences exactes, tu les incorpore dans la nistune, tu crées ta map secondaire et hop, complètement transparent à l'usage!
folken a écrit :Pourquoi tu veux synchroniser ?
C'est ce que font les boitiers les plus poussés !
Ton capteur c'est rien d'autre qu'un micro avec une plage de sensibilité bien particulière, mais le moteur c'est des vibrations, des frottements, des turbulences de fluides divers, des cognements.
On synchronise l'écoute avec la phase de compression jusqu'à l'allumage + quelques degrés après, avant c'est inutile d'écouter et après c'est bruyant pour ensuite devenir inutile. Certes entre deux compressions il se passe peu de temps mais suffisant pour qu'un bruit parasite soit mal interprété !
Le problème, c'est que ça va surement perturber l'analyse en fréquence en rajoutant des harmoniques à la con au moment du déclenchement et de la coupure de l'acquisition
On trouvera probablement pas de logiciel conçu pour écouter sur plein de petites plages temporelles, du moins pas pour le grand public.
Donc il analysera sur la durée complète de l'échantillon, et au moment des synchronisations ça rajoutera l'équivalent d'autres bruits parasites à mon avis (ces fréquences parasites seront très probablement situées dans les hautes fréquenes et ne devraient pas gêner, mais dans le doute
)
Et pour un peu que le matos soit pas de très bonne qualité et rajoute encore des parasites au moment des commutations
Je suis pas certain que ce soit gênant de prendre la totalité de l'acquisition à notre niveau, c'est sûr que ce serait mieux d'écouter uniquement quand ça nous intéresse mais les fréquences induites par le cliquetis doivent pouvoir assez bien se différencier du reste du bruit moteur logiquement.
Je pense quand même qu'il devraient être possible de ne pas passer par un post traitement, mais de tout faire en temps réel.
Les oscilloscopes à mémoire sont capables de faire un affichage en temps/fréquence, et pourtant leur puissance est ridicule face à celle d'un PC. A moins qu'ils aient une puce dédiée qui soit plus rapide (comme les GPU dans un PC, qui sont spécialisées dans les calculs graphiques et beaucoup plus performants pour ce type de calcul qu'un CPU à fréquence égale). Mais ça semble pas bouffer tant de ressources que ça quand WMP ou Winamp affichent les fréquences en visualisation.
Les morceaux de codes pour le faire doivent déjà exister, le vrai défi consisterait à les intégrer un même programme pour faire l'analyse fréquentielle, garder uniquement celles que l'ont veut, et déclencher une alerte en cas de dépassement d'un seuil jugé normal.
Ou alors un bête passe bande avec un comparateur derrière, y'en a pour 5 de composants à tout casser, mais faut être sacrément confiant dans la qualité des composants et du montage pour risquer un moteur dessus
Pourquoi vouloir l'écouter en externe, filtrer, post-processer, alors que l'ECU fait déjà tout ce travail pour vous et qu'en plus, en loggant, cela vous permet de corréler toute apparition de cliquetis à un TP (charge) et à un RPM (régime) donnés !??
Je comprends qu'écouter est une méthode simple et fiable mais sans graphe, ca permet seulement de savoir à peu près dans quelle région le cliquetis apparaît.
folken a écrit :Le problème, c'est que ça va surement perturber l'analyse en fréquence en rajoutant des harmoniques à la con au moment du déclenchement et de la coupure de l'acquisition
lol ! si tu fais la coupure et la commutation avec une relais je crois que ça va être la misère ! lol ! là je te parle de traitement numérique, le signal est numérisé avec une grande précision et ensuite on ignore les octets des plages numérisées qui ne sont pas utiles ! D'ailleurs l'ecu d'origine à aussi une fenêtre d'écoute, mais j'ignore si c'est matériel ou logiciel (et dans ce dernier cas comment la configurer !)
pour les oscilloscopes c'est très souvent des DSP qui font le boulot de quantification, c'est possible à faire de façon logiciel mais ça serait plus lent ou alors aussi rapide mais plus basic !
Y'a pas de différence avec le traitement numérique, à partir du moment où tu passe de rien à un signal tu rajoutes des fréquences parasites c'est inévitable.
Ou alors t'as pas cité la bonne partie de mon message, là où je parlais des parasites à la commutation par exemple, mais le morceau que tu as cité reste valable même en numérisant.
folken a écrit :Y'a pas de différence avec le traitement numérique, à partir du moment où tu passe de rien à un signal tu rajoutes des fréquences parasites c'est inévitable.
Ou alors t'as pas cité la bonne partie de mon message, là où je parlais des parasites à la commutation par exemple, mais le morceau que tu as cité reste valable même en numérisant.
Je bosse quotidiennement sur des microcontroleurs, je fais des numérisations de signaux et des interprétations, traitements, mise en forme etc... donc je pense savoir de quoi je parle !
Et même si on décide de bosser avec un multiplexeur (comme souvent dans les microcontroleur ayant plusieurs canaux d'entrée analogique) on ne souffre pas de ce genre de problème s'il est bien conçu et les composants extérieur sont bien dimensionnés !
La numérisation est en continu, aucune commutation du signal analogique, aucune commutation des données numériques, simplement on remplie un buffer et on ne fait qu'un traitement sur les zones intéressante, ensuite on ne fait que la lecture sur la zone intéressante, pour éviter les craquements lors de la lecture d'un son "sec" il y a rien de plus simple que de faire un "fondu" entre deux échantillons ou une composante interpolé entre les deux échantillons, donc inaudible !
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), pas de commutation électronique (et de toutes façon un transistor ne fait pas d'effet rebond), on ne fait que du traitement numérique, si tu coupe ton fichier tu n'as pas de parasite ! lol !
Certes un transistor à un temps d'ouverture, une caractéristique d'amplification pas toujours linéaire, mais à cet échelle c'est imperceptible !
RomChip_200 a écrit :Pourquoi vouloir l'écouter en externe, filtrer, post-processer, alors que l'ECU fait déjà tout ce travail pour vous et qu'en plus, en loggant, cela vous permet de corréler toute apparition de cliquetis à un TP (charge) et à un RPM (régime) donnés !??
Je comprends qu'écouter est une méthode simple et fiable mais sans graphe, ca permet seulement de savoir à peu près dans quelle région le cliquetis apparaît.
C'est que je voulais dire maladroitement dans mon précédent message. Moi je me fous de savoir dans quelle plage est le cliquetis, du moment que l'ECU lui le voit et bascule sur la deuxième carto.
Par contre j'aimerais savoir quand l'ecu le détecte pour travailler la basemap originale et evincer le phénomène au maxi
et je pense, que la nistune peut nous tracer des logs précis à ce sujet!
Non, tu ne veux pas switcher sur la 2eme carto ==> plus de puissance.
Non, Nistune ne logge pas le cliquetis, d'où mon post !
Mais j'ai détourné Nistune pour pouvoir le faire.
RomChip_200 a écrit :Non, tu ne veux pas switcher sur la 2eme carto ==> plus de puissance.
Non, Nistune ne logge pas le cliquetis, d'où mon post !
Mais j'ai détourné Nistune pour pouvoir le faire.
J'ai pas compris pour le "plus de puissance".
Tu log par les entrées analogiques et en recréant une plage de réponse ??
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!
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:
Topic très très intéressant, merci aux intervenants
Pour extraire les fréquences souhaitées, on peut le faire en numérique avec un circuit DSP, faut se renseigner du côté de la transformée de Fourier et des algorithmes qui vont avec. Pour info on peut faire ça avec un dsPIC (microcontroleur DSP pas cher, ça commence à 1,20), faire une recherche sur FFT pour les électroniciens (
) ou matheux (
) que ça intéresse.
