Mesure de l'AFR en embarqué

Bah jte le prete, pas besoin de louer. En revanche, y'aura des adaptations a faire pour un 990...

Autre point interessant sinon que j'ai découvert par hasard hier :

Le fait de laisser branché le signal du capteur TPS au boitier Arduino sans alimenter le boitier Arduino crée des interferences dans le signal du TPS (ça j'ai pas encore compris pourquoi mais je creuse). Quoi qu'il en soit, l'ECU considere que la valeur du TPS est non conforme et c'est la que ca devient interessant, il décide de lui même de ne plus gerer le mode ride by wire et entre dans un mode dégradé ou l'ouverture de papillon n'est plus gerer electriquement via un moteur mais mecaniquement, par le cable de la poignée comme sur une moto "classique"...

Sauf erreur de ma part, sur le 990 il y a aussi une sécurité de ce type permettant de virer la notion de moteur pas à pas et de le faire commander uniquement via la poignée d'accélérateur et le cable. Cette option peut être activée via une coche sur la dernière version de Tunnecu.

pour tes problemes d interferences regarde du cote de la masse digital. j ai souvent eu le probleme avec des power commander si entre le boitier et l ecu, le tps, les sondes, tu n as pas une masse digital commune ca peut merdé. c est pour cela que je prends toutes les infos capteurs directement sur l ecu. aussi la masse digital de l ecu est raccorde au boitier X.

par ailleurs je regardais tes photos je ne suis vraiment pas certain du positionement de ta sonde. en effet elle est n est pas situe dans le flux gazeux de l echappement ce qui entraine des erreurs de lecture (elle est dans un renfoncement : depression...). pour avoir fait un montage similaire avec un wideband, j avais le meme souci d ecrou et donc sonde pas dans le flux gazeux.

et bien entre la sonde de la moto et celle du banc j avais des lectures differentes...donc sonde moto inutilisable. je suis bien emmerde car c est un colleur titane. pour l instant j essaie de trouver qq qui soude du titane.

merci pour l info quant au tps car je voulais virer ce moteur electronique qui ,parfois, fait n importe quoi.
mais en tout cas je le redis : superbe travail

Hello Puma4

La masse est commune pour l'ensemble. Je pense néanmoins avoir trouvé une piste. Quand l'arduino n'est pas alimenté, la broche sur laquelle arrive ma derivation de sonde TPS est dans un état indéfini, et a forte impédance, et donc agit comme un aspirateur de courant, et affaibli le signal reçu par l'ECU d'ou la deconnexion du ride by wire

A vérifier ce soir...

J'ai l'impression de regarder ARTE dans les premiers années de leur diffusion

Du beau travail et une bonne avancé pour nos katoch
félicitations

Koufig a écrit:J'ai l'impression de regarder ARTE dans les premiers années de leur diffusion

hahaha nan mais sans déconner, c'est a la porté de tout le monde. j'ai jamais fais d'electronique ni de meca ni rien mis a part de l'informatique. c'est juste le resultats de nombreuses nuits a avaler des tonnes et des tonnes d'infos sur le web (souvent de la merde d'ailleurs). Le plus compliqué, c'est de reussir a faire le tri et la synthèse...

unityraptor a écrit:

Koufig a écrit:J'ai l'impression de regarder ARTE dans les premiers années de leur diffusion

hahaha nan mais sans déconner, c'est a la porté de tout le monde. j'ai jamais fais d'electronique ni de meca ni rien mis a part de l'informatique. c'est juste le resultats de nombreuses nuits a avaler des tonnes et des tonnes d'infos sur le web (souvent de la merde d'ailleurs). Le plus compliqué, c'est de reussir a faire le tri et la synthèse...

En tout les cas, chapeau madame casquette!

TUTO 690 SM 2007 - ETAPE 2 - Electronique :

Matériel nécessaire :

- Un arduino : Pour ma part, j'ai utilisé un arduino Mega mais d'autre modèles peuvent fonctionner
- Un boitier plastique : N'importe quel boitier plastique permettant de faire rentrer l'arduino + le LCD. J'ai utilisé un boitier plastique special Arduino mega vendu sur le shop arduino
- Un module LCD avec bus I2C : Le prog de l'arduino est compatible avec les modules LCD 16x2 SainSmart ou YwRobot.
ex : http://cgi.ebay.fr/Neu-SainSmart-IIC-I2C-TWI-1602-Serial-LCD-Modul-Display-For-Arduino-UNO-R3-MEGA-/221038732758?pt=Wissenschaftliche_Geräte&hash=item3376ef65d6
- Le Inline Controller de AEM : http://www.ebay.co.uk/itm/AEM-INLINE-TYPE-WIDEBAND-UEGO-CONTROLLER-30-2310-/290405822715



Brochage Arduino :



Petit point sur le pont diviseur de tension (les 2 resistances) :

J'ai donné ici des valeurs qui fonctionnent mais vous pouvez utiliser d'autre valeur pour R1 et R2 en respectant la formule suivante :

Tension sortie souhaitée = (R2 / (R1 + R2) ) x Tension entrée

Avec :
Tension d'entrée = 12V la batterie
Tension de sortie souhaitée : entre 4 et 5 V

Si vous souhaitez alimenter l'Arduino via la batterie et que vous avez tiré un fil supplementaire du + après contact comme indiqué en étape 1, ce fil doit être relié a la borne de l'arduino nommé Vin (a coté du +5v et des 2 bornes GND)

Brochage LCD :





Brochage Inline Controller :





Résultat attendu :



A noter :

- Le pont diviseur de tension + diode est caché dans la gaine thermoretractable au centre de la photo.
- toutes les masses de l'arduino (GND) communiquent. Vous pouvez donc intervertir les cables comme bon vous semble entre les bornes de masse














---------------------------------------------------------------------------------------------------------------------------------

EDIT du 14/12/2012

---------------------------------------------------------------------------------------------------------------------------------


Alimentation autonome de l'Arduino :

Pour ceux qui voudrait visualiser les données sur le boitier sans forcement brancher un ordinateur portable sur l'arduino en USB (qui sert également d'alimentation), il est possible d'alimenter l'arduino directement via la batterie. Ce dernier accepte une tension d'alimentation comprise entre 7v et 12v, avec une limite max a 20v. il regule ensuite cette tension d'entrée en +5v automatiquement.

La batterie pouvant enregistrer des pics de tensions (supérieur a 12v), j'ai préféré ne pas surcharger le régulateur 5v de l'arduino et donc intercaler entre la batterie et ll'alimentation de l'arduino, un étage de regulation en +12v.

Le ptit schéma qui va bien :



Je viens de mettre en place ce montage, ca fonctionne a merveille.

T'arrives à récupérer les valeurs en live maintenant?

mrictdi a écrit:T'arrives à récupérer les valeurs en live maintenant?

tjrs pas reussi a aller rouler, j'attends desesperement mon robinet de reservoir qui a cassé.

Bon c'est good, tout est remonté, y'a plus qu'a attendre qu'il ne pleuve plus pour aller faire mes 1ers roulages, car je suis pas sur que mon boitier soit étanche...

unityraptor a écrit:Bon c'est good, tout est remonté, y'a plus qu'a attendre qu'il ne pleuve plus pour aller faire mes 1ers roulages, car je suis pas sur que mon boitier soit étanche...

Tu nous fais languir...

Vendredi il ne pleut pas, jpense que j'irais au taff avec mon boitier pour une 1ère serie de mesures.

unityraptor a écrit:Vendredi il ne pleut pas, jpense que j'irais au taff avec mon boitier pour une 1ère serie de mesures.

2

Tu nous mets l'eau à la bouche.

je viens de remonter le boitier en prévision de demain. je vais faire des petits test ce soir et laisser touner en continu mon prog pour voir s'il n'y a pas de bug dans le datalogging...

Faudrait pas tomber en rade sur le bord de l'autoroute

Pour faire taire les mauvaises langues....



Un petit test sur le ralenti :

Ca fonctionne comment? Ca te calcul une moyenne sur les régimes ou ça prend une valeur tous les X temps?

Pour l'instant, je prend 2 mesures par seconde (mais je peux facile monter a 7/8) et je peuple un tableau avec la valeur de l'AFR pour un regime donné et une ouverture de pap.

Si la mesure n'existe pas, je l'ajoute.
Si la mesure existe déja, pour l'instant je la remplace par la nouvelle -> pas idéal

Ma prochaine évolution du programme consistera à faire la moyenne entre l'ancienne et la nouvelle valeur, pondérée par le nb de mesure déja effectuées.

Auras tu les mêmes valeurs sur des régimes spécifiques à régime constant versus sur une phase d'accélération? Est ce que le fait de prendre 7 à 8 mesures par secondes est suffisant pour disposer d'une valeur significative en phase d'accélération?

Il me parait faire du sens que de prendre en considération les conditions atmosphériques lors de ta prise de valeurs.

Dispose tu des valeurs de température du moteur et de pression atmo?

Pour le nombre de mesures, je pense que ca devrait être ok.

Pour les conditions atmo et la t°, il est tout a fait possible de s'interfacer avec les capteurs mais la question est dans quel but ?

Mon objectif, c'est de pouvoir corriger la table EFI pour arriver a une base de travail propre pour l'ECU après suppression de la sonde lambda. De la même manière que l'un d'entre vous a determiné qu'il fallait diminuer les temps d'injection de 7% sur la plage 0 à 5000 trs/m sur le LC8.

Comme je ne sais pas quelles corrections effectue (s'il en fait) l'ECU en fonction de la t° et de la pression atmo, autant ne pas en tenir compte puisque de toutes manieres je ne saurais pas interpreter les resultats.

Donc en gros je le laisse faire ses petites affaires dans son coin tant qu'au final, j'arrive a un ratio qui me convient.

ça te parait aberrant ?

Non, ta logique est implaccable au regard des limites que tu te fixes.

Le seul point que je tendais à soulever, c'est que la composition de se mélange air essence sur lequel tu vas jouer est calculée initialement en fonction de certains facteurs comme la pression atmosphérique et l'humidité de l'air.

Dans ce cadre les corrections que tu peux faire sur la cartographie doivent tenir compte de ce facteur me semble t'il afin d'éviter qu'en fonction d'une variation de pression atmosphérique forte ou d'humidité de l'air, ton mélange soit trop riche ou trop pauvre.

Le gros avantage dont tu disposes avec le 690 est justement la possibilité de switcher les cartos. C'est donc une carto montagne, ville, et pluie que je me créerais à la place des trois cartos actuellement disponibles pour convenir au mieux à la situation

Malheureusement non, le switch de carto ne fait pas varier la carto d'injection mais uniquement la carto EPT (reponse à la poignée de gaz).

En revanche, je suis d'accord avec toi, je pense que je me fabriquerais une carto "hiver" et une carto "été" si je me rend compte que cela change enormément le mélange. je devrais en revanche obligatoirement passer par la case TuneEcu pour la charger dans la bécane.

Après, ce point fait partie des questions que je posais en debut du post; a savoir, l'impact des conditions atmospheriques necessite-t-il de prévoir plusieurs carto ou la marge de correction de l'ECU est-elle suffisante pour effectuer les corrections adéquates si tant est que la table de base est bien parametrée ?

Supermothard, si tu passes dans le coin ? j'imagine que vu le nombre d'heure que tu as passé sur ton banc de puissance, tu dois avoir une petite idée la dessus...

Bon mis a part ça, 1er test en condition réelles ce matin...

La good news, c'est que le circuit ne crée aucune interference sur le comportement de la moto, que les valeurs sont bien recup sur l'ordi portable, que les calculs permettant la mise en forme des valeurs dans le tableau sont ok (j'ai d'ailleurs fais une petite correction ce matin pour réaliser la moyenne de valeur et non plus le remplacement).

La bad news, c'est que j'ai fais une grossiere erreur de conception au niveau du prog de l'arduino qui me fausse le calcul des RPM en cas de variations trop rapides. Et comme j'ai pas envie de bosser touday, je vais en profiter pour faire la correction et charger ca dans la moto ce midi.

Donc ce soir, trajet retour, essai n° 2