Mesure de l'AFR en embarqué

Hello à tous,

Après une petite semaine de recherches intensives sur le net, j'ai finalisé mes préparatifs pour me faire un système d'acquisition de données me permettant de régler ma richesse au poil en prévision de la suppression de la sonde lambda et de l'ouverture de la boite à air.

Je poste un petit schéma explicatif qui sera plus parlant que des tonnes de blabla...



Je vous tiendrais au courant des résultats...

Edit : je précise que l'idée est de réaliser l'aquisition de données en roulant avec le portable dans le sac a dos puis d'exploiter les résultats pour faire des corrections sur la table d'injection; puis de recommencer jusqu'a ce que le résultat me convienne...

J ai reçu mon odb2 Bluetooth je vais me tester ça d ici peu

yes ! moi je l'attends pour lundi

Vous me chauffez les gars

mrictdi a écrit:J ai reçu mon odb2 Bluetooth je vais me tester ça d ici peu

Je voudrais pas plomber l'ambiance mais le dongle BT, j'ai testé ça il y a un moment avec un smartphone et le logiciel Torque et ben... ça marche pô
Alors que le même dongle sur ma MINI fonctionne
Je crois que les 3 fils que nous connectons à partir de la prise diag ne sont pas suffisant mais je n'ai pas cherché plus loin

Theoriquement ca devrait etre bon si le dongle est basé sur un composant LM 327 et qu'il supporte le protocole KWP2000 (iso 14230) qui est semble-t-il le protocole de communication.

Normalement, le composant LM327 permet à l'utilisateur de s'affranchit des differents protocoles et lui présente uen interface de communication unifiée, au moins pour un minimum de données du genre RPM, papillons, etc. c'est un standard et c'est juridiquement obligatoire de le proposer pour l'ensemble des constructeur depuis 2001.

Après, si ca marche pas avec le dongle, perso je recupererais directement les valeurs des capteurs en volt via l'arduino

Dans tous les cas je pense que si tu veux faire de l'acquisition de données, tu DOIS prendre directement les mesures sur les capteurs. Si tu passes par l'ECU le temps de réaction/transmission sera trop lent et tu ne pourras pas mettre en regard les mesures AFR, ouverture des papillons et régime moteur.

unityraptor a écrit:Theoriquement ca devrait etre bon si le dongle est basé sur un composant LM 327 et qu'il supporte le protocole KWP2000 (iso 14230) qui est semble-t-il le protocole de communication.

Normalement, le composant LM327 permet à l'utilisateur de s'affranchit des differents protocoles et lui présente uen interface de communication unifiée, au moins pour un minimum de données du genre RPM, papillons, etc. c'est un standard et c'est juridiquement obligatoire de le proposer pour l'ensemble des constructeur depuis 2001.

Après, si ca marche pas avec le dongle, perso je recupererais directement les valeurs des capteurs en volt via l'arduino

Ce qu'il manque, c'est peut-être juste une alimentation pour le dongle

Je me disais qu'avec 2 valeurs à recup ca chargaient pas trop et j'esperais pouvoir faire 2 cycles de mesure par seconde. A tester je pense...

unityraptor a écrit:Normalement, le composant LM327 permet à l'utilisateur de s'affranchit des differents protocoles et lui présente uen interface de communication unifiée, au moins pour un minimum de données du genre RPM, papillons, etc. c'est un standard et c'est juridiquement obligatoire de le proposer pour l'ensemble des constructeur depuis 2001.

En bagnole avec les normes OBD, oui.
En moto, je ne serais pas aussi catégorique.

Riton a écrit:Dans tous les cas je pense que si tu veux faire de l'acquisition de données, tu DOIS prendre directement les mesures sur les capteurs. Si tu passes par l'ECU le temps de réaction/transmission sera trop lent et tu ne pourras pas mettre en regard les mesures AFR, ouverture des papillons et régime moteur.

L'ECU est bien assez rapide (fréquences habituellement utilisées entre 1ms et 100ms), seulement, ce sont ses communications externes qui sont bien limitées, notamment via le réseau de bord (sur le CAN en auto), où on peut en effet tomber à des fréquences de raffraichissement de l'ordre de la seconde (autrement dit inexploitable en embarqué).

Reponse demain quand j'aurais reçu mon bignou

Le plus important dans l'acquisition des données c'est d'avoir les valeurs du TPS et Trs/min, sans ça les réglages deviendront aléatoire.

Changement de cap sur le projet...

Après des tests multiples toute la nuit, impossible de faire fonctionner le dongle BT. J'ai testé tous les protocoles possibles, rien ne passe la connexion ne s'établit pas. il y a donc tout ou partie des échanges qui ne font pas partie du standard.

2 solutions s'offrent à moi :

1 - Faire un reverse engineering de TuneEcu pour créer mes propres trames: j'ai analyser rapidement les trames qui passent via le cable TuneECU, ca va pas être simple de décrypter sans avoir un minimum de doc.

2 - Me brancher en direct sur les capteurs et faire l'acquisition des valeurs analogiques via l'arduino

J'ai retenue la solution n° 2 et commencé à creuser de ce coté. L'idéal semble être de venir mesurer le signal envoyé au compteur du 690, en se branchant derriere le tableau de bord.

Pin n° 4 - Regime moteur : BLANC-BLEU
Pin n° 5 - Vitesse : NOIR-ORANGE

Il me reste maintenant a analyser les valeurs analogiques pour voir les adaptations à réaliser (12V ? 5V? tension continue, Fréquence)



Je mets le brochage du compteur (trouvé sur le net) si jamais ca interesse quelqu'un :

1 - 12V always on

2 - 12V key on (from power relay)

3 - From wheel speed sensor

4 - From ECU pin 40 is the tach signal

5 - From coolant temp sensor

6 - unused

7 - From fuel level sensor

8 - High beam indicator

9 - Right blinker

10 - Left blinker

11 - Neutral indicator

12 - From ECU pin 38 is the MIL signal

13 - unused

14 - unused

15 - Ground

16 - unused

17 - unused

18 - Ground

19 to 22 - unused

23 - From wheel speed sensor

24 - Ground

25 to 32 - unused

unityraptor a écrit:
2 - Me brancher en direct sur les capteurs et faire l'acquisition des valeurs analogiques via l'arduino

J'ai retenue la solution n° 2 et commencé à creuser de ce coté. L'idéal semble être de venir mesurer le signal envoyé au compteur du 690, en se branchant derriere le tableau de bord.

Pin n° 4 - Regime moteur : BLANC-BLEU
Pin n° 5 - Vitesse : NOIR-ORANGE

Il me reste maintenant a analyser les valeurs analogiques pour voir les adaptations à réaliser (12V ? 5V? tension continue, Fréquence)

Je pense que c'est la meilleure piste !

Par contre je pense que le TPS, en conjonction avec le régime moteur et tes mesures d'AFR, est plus important que l'information vitesse si tu veux corriger ta carto (et je pense que c'est le but )
Pour le TPS l'info est en volts et tu peux voir les valeurs dans Tuneecu en mode test.
Pour le régime moteur il faudrait voir dans le manuel d'atelier s'ils en parlent ?!?
Je ne sais pas s'il est dispo pour le 690 mais c'est peut-être pareil que pour les 990 (d'ailleurs les couleurs de fils que tu as relevé régime moteur/vitesse sont les mêmes que sur mon ex SM 990) => à creuser

bonne chance pour la suite

Oups, effectivement ! je voulais bien entendu parler du TPS. La vitesse on s'en fou

Pour les valeurs du TPS, c'est recuperable en se branchant sur le connecteur qui relie le capteur à l'ECU (connecteur sumitomo 3 fils-> merci Supermothard et Katomeuch ) et je pense sur le fil Jaune/liseré Orange branché sur le port 13 de l'ECU. c'est normalement du 0-5V. En revanche, j'ai lu que les capteurs TPS n'etait pas forcement linéaire.

Donc en gros, je vais relever quelques valeurs pour en déduire la courbe :

- brancher TuneECU pour visualiser l'ouverture TPS en %
- regarder ma valeur analogique équivalente

unityraptor a écrit:

1 - Faire un reverse engineering de TuneEcu pour créer mes propres trames: j'ai analyser rapidement les trames qui passent via le cable TuneECU, ca va pas être simple de décrypter sans avoir un minimum de doc

Ouaou tu nous avais caché ces compétences !!! Contact meeou sur le fofo, si besoin je te file son mail en mp c est lui qui a crée le sort à partir de tuneboy via reverse engineering .

hihihi déja fait depuis 1 semaine. il vient de me répondre. Il m'a confirmé le protocole de communication (KWP2000) et le fait qu'une bonne partie (du protocole) n'est pas standard a priori sur les katoches. Il m'a également confirmé que ca ne vaut pas le coup via OBD car seulement 4/5 lectures par seconde

bon pour rigoler, je m'amuse quand même a essayer de decrypter le protocole katoche... meeou si tu vois ce post, te faches pas, je dirais rien si je trouve:lol!:

Jpense avoir trouver la chaine d'initialisation mais c'est un peu galere, j'ai l'impression qu'il y'a un timing en millisecondes a respecter, je retrouve des constantes.

Ensuite, y'a une gestion de mot de passe. l'ECU envoit une chaine de caractere qu'on doit renvoyer en changeant une partie de la chaine... reste à decrypter l'opération réalisée.

l'ecu confirme la bonne authentification en renvoyant une chaine spécifique "80 f5 d5 02 67 04 b7".

80 semble etre le header

D5 et F5 sont les adresses respectives de l'ecu et du pc puisqu'elles s'inversent selon le sens de la communication.

une fois les etapes d'init et le mdp réalisé, on passe au polling des valeurs de capteur mais je me suis pas penché dessus encore

J'suis largué

Ptain ou est mon tournevis.....

huhuhu j'ai decrypter la tronche des trames :

ex: "80 f5 d5 02 67 04 b7"

80 c'est le descriptif du header
f5 adresse physique du PC
D5 adresse physique de l'ECU
02 c'est la longueur de la chaine de donnéés hors header (67 04 -> 2 octets)
67 le code identifiant le service
04 c'est une donnée
B7 n'est qu'un simple checksum (somme de l'ensemble de la chaine hors checksum modulo 256)

je progresse...

unityraptor a écrit:
je progresse...

Je rame

Katomeuch a écrit:J'suis largué

ledom a écrit:Ptain ou est mon tournevis.....

Là on a un expert mécano en informatique