Aller au contenu
  • Ceci n'est pas un forum, mais une communauté !

    20100521_GTX_0003.JPGNous aimons tous cette voiture mythique et populaire, parce que nous avons navigué dedans étant petits, parce que quelqu’un de la famille en avait une ou simplement parce qu’elle nous a toujours fait envie… parce qu’elle est attachante, quoi qu’on en dise.

    Son grand succès est certainement du au fait qu’avec une mécanique simple, avec peu ou pas d’électronique elle est facile à entretenir par soi-même sans un outillage hors de prix, sans oublier que les pièces ne sont pas chères et toujours faciles à trouver. Aujourd’hui encore elle est pour certains foyers, étudiants, et personnes avec un "budget serré", une source de grand confort à moindre prix : loin des crédits auto et du garagiste qui deviennent de plus en plus inaccessibles. Les modèles à petite cylindrée (les plus répandus) sont très robustes et consomment toujours très peu, parfois même moins que les voitures récentes « équivalentes », ce qui la rend par définition tout aussi écologique, si ce n’est même plus de par le simple fait que nous l’utilisons toujours au lieu d’en acheter des neuves… Au niveau du contrôle technique / expertise, bénéficiant de son « ancienneté », elle ne subit pas les normes modernes bien trop contraignantes, la tranquillité est assurée.

    Aujourd’hui elle demeure encore une voiture intéressante pour l’usage quotidien, notamment et clairement d’un point de vue économique.

    Les collectionneurs commencent aussi à s’intéresser à cette « mamie » de 30 ans : restauration, remise à neuf ou d’origine, réparations, etc… permettent de retrouver des modèles « plus neufs que neufs » pour le plaisir des yeux et de voir ce patrimoine français ainsi sauvegardé.

    Nous avons créé cette communauté pour réunir tous ceux qui s’intéressent et qui souhaitent prendre part à cette aventure pour préserver leur Renault Super 5, que ce soit par de l’entretien, de la réparation ou de la restauration : vous trouverez ici toutes les informations et astuces utiles à ces propos.

    Le forum est accessible gratuitement dans sa totalité : il n'y aucune obligation de cotiser, d'achat, ni d’adhérer à quoi que ce soit pour intégrer la communauté et participer.

    Pour pouvoir poser des questions et partager vôtre intérêt, il suffit uniquement de vous inscrire et de vous présenter convenablement !

    Vous ne devez pas nécessairement posséder une Super 5 : un intérêt pour la mécanique automobile suffit ! ;)

    Bienvenue !

     

    (Ce message disparaît si vous vous inscrivez au forum)
     

Interface De Contrôle (?)


Mathusalem

Messages recommandés

Je ne comprends pas ton problème. Le moteur arrêté, il n'y a pas de circulation d'air, donc la pression est la même partout. Un préalable évident est que si l'air se met à circuler, c'est qu'il y a une différence de pression (sinon pourquoi ?)Donc, le moteur tournant, tu as une pression inférieure à la pression athmo dans les tuyaux. Dans la boite à air, tu as une faible différence, et après le papillon une différence importante. Ces différences dépendent du débit, c'est à dire du régime moteur et de la charge.Ou alors j'ai raté une marche !
Lien vers le commentaire
Partager sur d’autres sites

  • Réponses 119
  • Créé
  • Dernière réponse
Salut!Pour ma part j'e préfère lire les valeurs en hexadecimal dans un log, et de les convertir au besoin.En ce qui concerne le 45 06 je pense que ca fait plus référence au type de calculateur pour que la XR25 puisse savoir quel vehicule est diagnostiqué.Je pense que c'est normal que la pression atmospherique ne varie pas en fait. Car c'est une mesure prise et qui sert de référence.La pression atmospherique ne varie pas, mais uniquement la pression collecteur. Tu dois pouvoir verifier les mesures car moteur arrêté la pression collecteur doit être très voisine voire égale à la pression atmospherique.
Lien vers le commentaire
Partager sur d’autres sites

Justement, Dans le principe, pour connaître un débit d'air, il suffit de connaître la section du passage (position papillon) et la différence de pression de chaque côté de ce passage. Or il n'y a qu'un capteur de pression, et dans le collecteur. Avant que le moteur ne tourne, il suffit donc de se dire qu'on a la même pression de chaque côté, donc un seul capteur, on recopie la valeur, et on la garde comme référence pour calculer le débit une fois le moteur en route.Mais là où je bloque, c'est que le calculateur m'envoie deux valeurs pour les pressions : 247 pour le collecteur et 07 pour l'extérieur. Il faut donc deux formules qui donneraient le même résultat, non? si pour trouver la bonne valeur, 247 x 4 = 988mb et (255 - 7) x 4 = 992mb, on part déjà sur une mauvaise base, non?Je viens de refaire une mesure :Température moteur = 82 (11°)Température air = 77 (8°)Pression collecteur = 253 (1012mb)Pression athmo = 1 (1016mb)Et vu que le collecteur est grand, la température dedans est la même que dans l'air (moteur froid, entendons-nous).Est-ce que à tout zazard, on n'aurait pas une différence permanente de 4mb? Tracteur, peux-tu confirmer par rapport à des trames que tu aurais dans un coin, que la somme des deux octets = 254 (le cas de mes deux relevés)?Mais je trouve complètement débile de ne pas avoir la même formule pour les deux données, sauf s'il y a une correction par rapport à la température, et là, on est mal!EDIT : j'ai trouvé une trame d'un espace 2.2 essence, elle donne des valeurs très cohérentes, et il y a aussi ce 4mb de différence...
Lien vers le commentaire
Partager sur d’autres sites

@Super_CinciCa ne peut pas marcher, ton affaire. Suppose quelqu'un qui a décidé de faire une balade en montagne, il peut facilement monter de 1000 m sans arrêter son moteur... il faut bien tenir compte de la pression athmo (de temps en temps, pas obligé de faire ça en temps réel)...
Lien vers le commentaire
Partager sur d’autres sites

Oui, je suis tout à fait d'accord avec toi, mais ça, c'est l'affaire du calculateur... moi, je veux surtout réussir à décoder cette valeur... pour les températures, ils ont utilisé la même formule, alors que pour les pressions, non... :wacko:tracteur : c'est pas urgent, t'inquiète! ;)
Lien vers le commentaire
Partager sur d’autres sites

Oui, je suis tout à fait d'accord avec toi, mais ça, c'est l'affaire du calculateur... moi, je veux surtout réussir à décoder cette valeur... pour les températures, ils ont utilisé la même formule, alors que pour les pressions, non... :wacko:

Comme j'ai dit, il y a probablement un traitement différent pour la pression athmo, qui ne peut varier que très lentement (à moins de tomber dans un ravin très profond...) et la pression dans le collecteur, qui doit être traitée en temps réel. Comme ça n'est pas utilisé par la même routine du software, il est possible que le codage soit différent. Si ça se trouve l'un a été codé par une équipe suisse, et l'autre par des italiens :)Pour les températures, le problème ne se pose pas...
Lien vers le commentaire
Partager sur d’autres sites

Bon, relevé aujourd'hui, météofrance a relevé 1027,40mb à midi, et ça n'a pas trompé : mon calculateur sature à 1020mb sur les deux valeurs. Je ne vais pas me plaindre de la présence d'un anticyclone au dessus de ma tête, mais pour avoir des mesures plus raisonnables, vivement la prochaine tempête... :)J'ai surtout relevé mon calculateur pour avoir une idée de la rapidité qu'il va me falloir pour traiter une trame avant que la suivante n'arrive... Alors si mon bidule m'envoyait une trame toutes les 256ms, mon calculateur, lui, banane de 25 à 30ms, soit de 33 à 40 trames par seconde (en même temps, moteur arrêté, il n'a que ça à faire en attendant qu'on démarre). Il va donc falloir les traiter rapidement si je ne veux pas me perdre en cours de route avec des buffers qui débordent... Je vais donc ajouter une petite fonction qui mesure le temps que je mets à convertir et afficher mes valeurs sur PC pour être sûr que l'on reste encore compatible.Ca me fait quand même un log qui se remplit à 4.5Ko/s, soit un fichier de 135Ko sur un audit de 30 secondes (1050 trames)Est-ce qu'on garde un tel débit, ou peut-on se permettre d'en oublier une ou deux de temps en temps? genre toutes les 100ms, je lis une trame en ignorant toutes les autres jusqu'à la prochaine... Je pense surtout au graphe que je suis en train de faire, une sorte d'oscilloscope qui affiche l'évolution des données au cours du temps, et donc les méthodes graphiques risquent de prendre du temps (une ligne à tracer par donnée et par trame + enregistrer la trame dans un fichier). ou alors je sous-estime rave mon PC, et il sera à la hauteur... ?
Lien vers le commentaire
Partager sur d’autres sites

Salut!Je pense qu'une acquisition de trame toute les 100 ms me semble pas mal, en dessous les valeurs affichées évoluent trop vite et ce n'est pas exploitable. Après il faut voir l'aspect paramètres physiques du moteur et de son environnement, et je pense que 100ms est largement rapide.
Lien vers le commentaire
Partager sur d’autres sites

J'étais parti sur la réception d'une trame sur deux (soit dans les 60ms), mais 1 sur 3 peut être suffisant (ça fait 10 mesures / seconde quand même).

En fait, j'ai un timer qui va piocher toutes les données dispos dans le buffer de réception série du PC, toutes les 20ms. A chaque fois qu'il détecte un début de trame (FF-00), il part du principe que le tableau de données est complet (trame précédente), et balance le décodage / affichage des données. Histoire d'alléger le traitement (version 1.1), le "décodeur" ne s'occupe que des valeurs qui ont changé (c'est le timer qui dit quelle valeur a bougé au moment de la réception), et en effet, ça change beaucoup de choses, le traitement est bien plus court.

Ca, c'est la première partie, la fenêtre principale que je vous ai montrée. Je suis en train d'en faire une seconde, sous la forme donc d'un oscilloscope. On a une zone graphique qui peut afficher jusqu'à 22 courbes de données (je pense que c'est largement suffisant, certaines données n'ont aucun intérêt). Le principe est simple, les courbes s'affichent au fur et à mesure, une fois arrivé au bout de la zone, on repart au début en "écrasant" les courbes précédentes.

Image IPB
Dans cette fenêtre, à gauche : la liste des courbes à afficher (légende). On peut en ajouter, enlever... un vrai bonheur, mais rien ne s'affiche : je n'ai pas encore implémenté la partie dessin.
En haut, quelques boutons à l'image d'un magnétophone : Play (lecture d'un fichier LOG), Rec (enregistrement d'un LOG), Stop/Eject (réinitialisation / chargement / choix d'un fichier LOG), Mon (Affichage ou non de la trame en cours de réception sur le graphique).

Je suis parti sur une échelle de base de 1000 points sur l'axe X. Donc, selon comment j'organise la chose :

Méthode "point" :
- chaque relevé donne un point, soit affichage de 1000 relevés sur la longueur totale du graphe.
- si un relevé toutes les 100ms, alors le graphe affichera l'évolution sur 1'40".
- Avantage : méthode de traçage rapide, longue période d'observation.
- Inconvénient : Lecture de la courbe par points : pas très ergonomique...

Méthode "ligne" :
- chaque relevé donne une ligne de 3 points sur X, de la valeur précédente à la nouvelle. Soit une courbe continue.
- on divise donc par 3 la durée de balayage : plage de +/-30".
- Avantage : Lecture de la courbe plus ergonomique...
- Inconvénient : la méthode de traçage prend plus de temps, période d'observation moins longue.

J'ai cependant un petit bémol sur ce graphique : je ne vois pas trop comment gérer le décodage au fur et à mesure, du coup, le graphique affichera les données brutes... Passer par un tableau de fonctions peut-être... (désolé pour les non programmateurs, vous devez pas entraver grand chose là, je pense à voix haute...)

Je prévois quand même une échelle modifiable pour l'axe temporel, histoire de pouvoir afficher un relevé plus long (lecture d'un fichier log par exemple), et pourquoi pas zoomer...

S'il y a un pro du VB6 dans le coin, je cherche le moyen d'agir avec une palette graphique au niveau d'un contrôle "PictureBox" (comprendra qui pourra ;) ). En gros, on a des courbes de couleur différentes sur un fond noir, et en sélectionnant l'une des courbes dans une liste, elle passe en blanc, genre "high-light" pour mieux la voir. Je n'ai pas d'historique des courbes, il me faut jouer uniquement sur un graphique...

Bon, allez, une petite image parce que vous avez été sages :

Image IPB

testé avec des trames à 29ms, ça passe bien... le graphique est assez fluide avec une trame sur trois de retenue.

Je crois que tout est "fonctionnel" (ah non, pas l'écriture dans les logs, mais ça va venir), reste à trouver les plantages, et les corriger, car il doit forcément y en avoir! des points manquent dans les courbes, je vois pas pourquoi... faut dire que Microsoft a gazé en inventant les twips, une vraie cochonnerie, ça! c'est tellement mieux, un pixel pour dessiner sur l'écran...
Lien vers le commentaire
Partager sur d’autres sites

Bon, on va revenir à des choses plus terre-à-terre. J'ai résolu mon souci de points manquants dans les courbes, c'est à cause de ces twips à la noix (comme la taille des polices : ça ne veut rien dire, mais faut faire avec.), un problème d'échelle.

Je suis également fier de vous présenter mon premier fichier log :

test2_0.log

Ce fichier est l'enregistrement des trames pondues par mon simulateur de trames, à raison d'une trame toutes les 285ms environ, c'est pour ça qu'aucune valeur ne change...

Bon, pour ceux qui voudraient s'amuser à jouer avec, il y a un principe simple de lecture (et donc écriture). Je dois encore mettre cette "norme" au propre, qui fait que si on construit tous nos logs de cette façon, même en rajoutant ou enlevant des choses dedans, ça reste lisible par tous.

Reste quand même que... dans mes trames, il y a trois octets bonus rajoutés à la fin qui correspondent à la durée entre la trame et la précédente, codée en µs sur 3 octets (qu'il faut multiplier par 4, soit une valeur pouvant aller de 0 à 1 minute 7 secondes108 ms et 860 µs. deux octets nous limitaient à 262ms, c'est un peu juste je trouve.). C'est pour l'affichage sur un graphique à échelle temporelle...

oups, pardon, je (re)deviens compliqué...

Il ne me reste plus qu'à faire la lecture de le trame avec affichage dans la zone graphique, et j'aurai une version à proposer, mais encore faut-il se mettre d'accord avec une interface matérielle, je n'ai pas de simple module FTDI sous la main, le dialogue d'initialisation entre mon module et le PC rend le soft inutilisable avec un simple FTDI pour l'instant...

Je tenterai de vous faire une petite vidéo d'un démarrage à froid (j'ai qu'un APN pour ça, et je ne suis pas sûr de réussir à en sortir une vidéo exploitable)...

EDIT : une tentative de mise au propre du format des enregistrements LOG :

Image IPBproposition_de_format_de_fichier_log_v1_0.pdf

Mon idée est que quelle que soit la version du fichier ou du "décodeur" soft, tout fichier peut être interprété par tout "décodeur", mais certaines données d'un fichier en version 2 ne seront pas prises en compte par un décodeur version 1, tout comme certains champs d'affichage en version 2 resteront vides à partir d'un fichier version 1... Je pense qu'avoir un titre, une date et un petit commentaire doit bien suffire dans un premier temps, d'autant plus que la trame contient déjà des infos sur le type du véhicule...

Ah je viens d'y penser, mieux vaut imposer les trois derniers octets d'identification temporelle de chaque trame, sinon, niveau graphique, ça sera pas joli-joli.

bonne nuit... :D
Lien vers le commentaire
Partager sur d’autres sites

Ce matin, démarrage de la 21 à froid, avec une grosse supputation de JDC. J'ai voulu faire une vidéo, mais la pile de l'APN était HS...

Donc en attendant, je vous donne le fichier log de l'enregistrement, environ 50 secondes.

test_vh1_0.log

et une capture d'écran de mon soft (qui sera bientôt disponible, reste quelque retouches de finition à faire (quelques plantages)). j'ai rajouté une légende à la main, le soft ne le fait pas, faut pas trop lui en demander... le graph représente les 24 premières secondes, et environ 980 trames.

Image IPB

Pour obtenir l'image en bitmap non redimensionnée (top qualité) : C'est ICI

La courbe verte représente des données binaires. Elle tombe à 0, c'est quand j'appuie sur l'accélérateur (on voit les courbes RPM, injection, avance allumage qui suivent à ces moments là)

Ca se passe de commentaires... :wub:
Lien vers le commentaire
Partager sur d’autres sites

Je suis admiratif de tout le travail que tu as réalisé. Et le fait de voir l'évolution des différents paramètres au cours du démarrage et suite à un coup d'accélérateur rend la séquence particulièrement intéressante.Et j'ai deux questions sur ton fichier log. Pourquoi as-tu des FF qui traînent au milieu des trames sur les premières lignes ? Ça n'est pas un marqueur exclusivement réservé au début d'une trame ? Et à quoi servent les quelques lignes avec "00" en plus à la fin et que l'on trouve un peu partout dans la séquence ?
Lien vers le commentaire
Partager sur d’autres sites

Pour les FF : tu verras qu'ils sont toujours par nombre pair, à part le premier de la trame. Parce que FF = 255, c'est une valeur possible comme les autres. Maintenant, imagine qu'une donnée est à 255, et la suivante à 0. la trame contiendra donc un "FF-00", donc on va croire que c'est un début de trame! D'où l'idée que si une donnée est à FF, on la double d'entrée de jeu, et au décodage, on saura que le premier FF ne compte pas, et on trouvera les valeurs FF puis 00.

Par exemple, les 4 "FF" vers le début de trame correspondent aux données N°5 et 6, soit la vitesse de rotation du moteur v=15000000/(donnée6 * 256 + donnée5). pour FF-FF, ça donne 228.8tr/min, et avec deux octets, on ne peut pas descendre en dessous de 228.8...

Les zéros en grand nombre, c'est parce qu'il y a beaucoup de données à 0 moteur arrêté... et certainement des données non renseignées par mon calculateur, comme la position papillon, il n'y a pas de potar, donc pas d'info...

Une petite vidéo?

Image IPB_P1010478.avi (20Mo, pas réussi à faire mieux)
Lien vers le commentaire
Partager sur d’autres sites

Oulala c'est méga complexe votre histoire! Je vais etre honnète j'y comprends rien.Vive le carburateur :laugh: . J'ai jamais d'ailleurs compris l'avancée technologique du mono puisque face a un carbu bien réglé, le mono est plus gourmant (enfin j'entends dire ça fréquement)
Lien vers le commentaire
Partager sur d’autres sites

Un petit passage juste pour dire où on en est...Suite à quelques échanges avec Tracteur, ma version n'est pas compatible avec la solution "low-cost", du moins pas encore. Pour bien faire (car j'ai été trop vite, pas assez réfléchi), je dois reprendre toute la gestion du port série en incluant la possibilité d'utiliser des interfaces matérielles de toutes sortes. Je ne vais pas vous obliger à acheter mon bidule, alors que le soft pourrait marcher avec n'importe quelle interface série (qu'il faut néanmoins modifier, mais c'est pas pour le prix d'un transistor que ça va changer le monde, on n'est pas à l'UMP...)Pis je suis un peu ralenti par mes petites galères, donc ça avance moins vite... et je n'ose plus trop démarrer mon moulin-mayo qui a besoin d'un bon coup de jeune, donc je ne peux plus trop tester en direct.Juste pour info, combien d'entre vous seraient intéressés par l'ensemble soft+interface? histoire que ça me motive un peu... ;)
Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines après...
Hello everybodyJ'ai quasiment le meme calculo sur ma clio (ca devrait etre un Fenix 3B sauf erreur). Je suis en train de voir pour faire une interface adéquate entre al sortie et mon pC (je ne me casse pas la tete, deux transistors, 3resistances et hop sur le port Com - je n'aime pas l'usb c'est comme ca :) ).Par contre, question, est ce qu'il y a un lien entre l'organisation des données de la trame et celle qui sont affichée sur le boitier XR25.Typiquement, est ce que le voyant 10 coté Gauche correspond au 10eme bite d'un mot ?est ce que les numeros indiqués avec les# correspondent à des numeros d'octets ?Et question subsidaire, pensez vous qu'on aura le meme organisation de trame ?Sinon, je peux filer un p'tit coup de main.. je suis sous Linux par Contre :op
Lien vers le commentaire
Partager sur d’autres sites

Salut,Si tu arrives à récupérer directement ta trame par port série, c'est tout bon pour toi, car nous, on ne peut pas... Et c'est pour ça que j'utilise l'USB : pour avoir un port série à la bonne vitesse...Pour ce qui est du XR25, comme je ne l'ai jamais eu entre les mains... je ne peux pas te dire.Il se dit que chaque version de calculo a sa propre orga de trame. Jusque là, j'ai réussi à décoder des trames de différents calculateurs avec le même algo.Donne-moi ta trame quand tu l'auras, que l'on puisse vérifier ça!Bonne chance ;)
Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

  • En ligne récemment   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
×
×
  • Créer...

Information importante

En utilisant ce site, vous acceptez nos conditions d'utilisation Conditions d’utilisation et politique de confidentialité Politique de confidentialité.