ArduinoECU - CDI programmable à base d'arduino

j'avoue que tout ça semble bien complexe, beaucoup d'infos à la suite! Je m'y perd un peu aussi ^^
Merci pour le résumé Stef3376 !


Petit test du soir avec quelques photos

Tester les interruptions sur une entrée digital :
Un petit test tout simple, activé une sortie pendant 1ms dès qu'on reçois un front montant sur la PIN D2.

Comme on peut le voir sur la photo, j'ai utiliser un arduino pour générer les pics sur l'entrée D2 d'un deuxième Arduino.


ceci était dans le but de voir le temps de réponse de l'arduino quand on détecte un front montant (normalement venant du capteur d'allumage).
Je ne sais pas trop quoi en tirer de ce petit test, environ 50µs de retard avant que la sortie passe à 1.
Faut que je laisse passer la nuit.. là je sature un peu ^^ j'ai déjà passer ma journée devant le PC au boulot, là Stop !   Je réfléchirai demain

Il faut savoir prendre du repos!

Petit test suivant essayer de voir le temps de réaction avec la méthode de pooling de PhL.
Cela permettra de juger si cela vaut le coup de continuer sur les interruptions.

Stef3376 a écrit:

Il faut savoir prendre du repos!
Petit test suivant essayer de voir le temps de réaction avec la méthode de pooling de PhL.
Cela permettra de juger si cela vaut le coup de continuer sur les interruptions.

Petit test très vite fait du matin,
Enlever les opérations pour calculer le temps écoulé entre deux front dans l'interruption:
juste garder le "NewFront = true", du coup le retard passe à 9.5µs.

et je viens de penser à ça :
"Le temps de calcul à compenser se trouve dans tcor= 120/140 µs. Cette valeur a été retranchée de C2 lors de son évaluation avant stockage. La valeur tcor a été mesurée avec un oscilloscope numérique de precision."
Dans le code de PhL il enlève le temps de calcul


On verra ce soir ou demain pour le pooling !

Attention........
Prêt ? ...
ET Encore une question !

Qu'est ce que ça fait quoi si on d'éclanche l'étincelle avec un tour de retard ?
Je ne sais pas trop comment expliquer...

Admettons j'utilise le capteur 10°, mais je veux 30° d'avance.
Je peux pas prédire le capteur donc il faut bien attendre 360-(30-10)=340° après le front ?
ça se pratique ça ?


Si non, on prend le capteur 36°, mais on eut pas dépasser 36° - temps de calcul avant de produire l'étincelle...

Oui bien sur ça marche PhL l'utilise dans la version PIC de son allumage et cela peut s'utiliser aussi avec le 36 degrés

Bon pas de grandes avancées.. mais pour tenir informé les quelques personnes qui suivent le post :
Beaucoup de boulot et faut aussi que j'apprenne un peu plus le langage pour Arduino..

Entre interruption ou pooling, pour ce que j'ai besoin de faire ça se vaut. tout dépend de où sont placé les lignes de calculs.
j'ai remarqué que ce qui prends surtout du temps sont les fonctions millis() et micros().


J'aimerai bien rester sur les interruptions.
- une interruption sur une entrée pour le capteur d'allumage
- une interruption d'overflow du timer 1 pour d’éclancher l’étincelle.

Je pense que point de vue code ça serait pas mal et simple à comprendre.
Juste encore un problème que j'ai du mal à résoudre, comment initialiser le timer1 (initialize(period)) alors que celui ci n'a pas fini sa précédente période.. ?
(faut que je regarde à quoi sert la fonction read() peut être que c'est la solution pour détecter si il est déjà stopper ou non...? Je creuse, je creuse !

easy_ride a écrit:

j'ai remarqué que ce qui prends surtout du temps sont les fonctions millis() et micros().
normal ces fonctions font les temporisations. Le pb c'est que le micro ne peut rien faire pendant ce temps.

J'aimerai bien rester sur les interruptions.
- une interruption sur une entrée pour le capteur d'allumage
- une interruption d'overflow du timer 1 pour d’éclancher l’étincelle.
il te faut un timer supplémentaire pour évaluation du régime moteur ou gérer par un registre capture/compare.
Je pense que point de vue code ça serait pas mal et simple à comprendre.
Juste encore un problème que j'ai du mal à résoudre, comment initialiser le timer1 (initialize(period)) alors que celui ci n'a pas fini sa précédente période.. ?un deuxième compteur
(faut que je regarde à quoi sert la fonction read() peut être que c'est la solution pour détecter si il est déjà stopper ou non...? Je creuse, je creuse !

C'est pour ces raisons que PhL fait ses calculs avant les tempo et donc place son capteur avec assez d'angle (=temps) en avance.

Stef3376 a écrit:

easy_ride a écrit:

j'ai remarqué que ce qui prends surtout du temps sont les fonctions millis() et micros().
normal ces fonctions font les temporisations. Le pb c'est que le micro ne peut rien faire pendant ce temps.

millis() et micros() sont des fonctions pour réccupérer le temps depuis le démarrage de l'arduino.
Ne confonds tu pas avec "delay()" et "microsdelay()" qui elles, sont des fonctions pour attendre ? ?

J'aimerai bien rester sur les interruptions.
- une interruption sur une entrée pour le capteur d'allumage
- une interruption d'overflow du timer 1 pour d’éclancher l’étincelle.
il te faut un timer supplémentaire pour évaluation du régime moteur ou gérer par un registre capture/compare.


Le régime pourrai être calculé directement dans l'intérruption du capteur d'allumage non ? j'ai fais des test, ça semble fonctionner.

Je pense que point de vue code ça serait pas mal et simple à comprendre.
Juste encore un problème que j'ai du mal à résoudre, comment initialiser le timer1 (initialize(period)) alors que celui ci n'a pas fini sa précédente période.. ?un deuxième compteur


Oui je pense bien qu'il n'y pas d'autre solution simple !

(faut que je regarde à quoi sert la fonction read() peut être que c'est la solution pour détecter si il est déjà stopper ou non...? Je creuse, je creuse !

C'est pour ces raisons que PhL fait ses calculs avant les tempo et donc place son capteur avec assez d'angle (=temps) en avance.

Encore merci pour ton aide : )

Cela fait un moment que je n'ai pas regardé ce code il est très possible qu'en effet je confonde...
Je vais essayer de relire cette semaine.

Un peu de temps est passé pour mieux réfléchir
(surtout parce que j'étais vachement occupé...)

J'ai un peu avancé les 2/3 derniers jours.

L'avancement dans le code 'avance' bien  

-> Solution interruption sur le capteur d'allumage 12°
-> Overflow du Timer1 pour remettre la sortie bobine à 1 après 'x' µs après l'étincelle.
-> boucle while : regarde tout le temps si le temps depuis le démarrage du µC est égal au temps calculé pour déclancher une étincelle (avec deux variables au cas ou Time(n) est < à Time(n-1))

C'est vraiment pas facile d'écrire ça, le mieux c'est de lire le code pour ceux qui comprennes un peu, rien de très compliquer !!!!

seul chose à savoir : micros(); = temps en µs depuis le démarrage du µC.


Le fichier source disponible sur le drive. Le renommer en .C si jamais vous ne pouvez pas l'ouvrir.
Lien Fichier source

une petite image, j'ai réussi à installer les driver de mon oscillo  


ce qu'il reste à faire avant des test réels :
- Faire des test plus précis que avec mon oscillo, matériel de mesure du boulot devrait le faire ! (mesuré le temps de calcul)
- Regler le soucis au démarrage (pour l'instant besoin de 3 fronts avant d'activer la sortie)


- Pouvoir renter une courbe d'avance (pour l'instant c'est 2 points : 0tr/min = 12° et 8000tr/min = 36°, c'est juste pour les tests)
- Mettre des commentaires propres dans le code et faire une synthèse pour expliquer le tout
- Connaître le temps nécéssaire pour activer le thyristor qui décharge le condo dans la bobine.
- Attendre de recevoir ma commande RadioSpares (jeudi ou vendredi)

J'avais tellement hâte de mettre à jour le post que je n'avais pas poussé assez loin les tests :


En fait, avec l'enregistrement au format Row de l'oscilloscope sur PC , j'arrive à extraire 20.000 points par courbes. C'est bien précis au final :

Du coup j'ai pu optimiser l'offset à ajouter pour le temps de calcul :
- réglage de l'avance : Fixe à 12° : donc sortie bobine = entrée capteur 12° (avec un décallage de 1 période)


et en zoomant (vue qu'il y a assez de points)


Faut que je cherche si j'ai tout bon ou pas. Il est tard le cerveau est fatigué !
Et faire une mesure sur une plus petite période

Ça avance Bien!
Pour ton 'soucis' des trois fronts j'ai une question: combien de temps laisse tu a ton arduino 'allumage' avant de lui appliquer le signal capteur ? Peut-être est-il encore en train de booter ?
Pour l'impulsion sur le thyristor les oscillogrammes de transmic semblent montrer 1 ms (à l'arrache sur mon tel)

Stef3376 a écrit:

Ça avance Bien!
Pour ton 'soucis' des trois fronts j'ai une question: combien de temps laisse tu a ton arduino 'allumage' avant de lui appliquer le signal capteur ? Peut-être est-il encore en train de booter ?
Pour l'impulsion sur le thyristor les oscillogrammes de transmic semblent montrer 1 ms (à l'arrache sur mon tel)

J'attends qu'il a fini de booter avant de lui envoyé le signal.
Le problème vient du code, je n'ai pas ajouter de fonction pour le démarrage.

Vue que l'étincelle est calculé pour le prochain tour, le µc a besoin de connaitre le temps entre deux front pour calculer l'étincelle du prochaine (donc du troisième..)

Il faut que j'ajoute une regle comme par exemple :
si  RPM < 500tr/min, déclencher l'étincelle directement après le front.

Fait que je regarde, mais j'ai peur des retours de kick.
Dans le code de Philippe Loutrel, il prévoit un RPM mini pour autoriser l'étincelle.
il faut donc au minimum deux front pour connaitre la vitesse non ?

-> IL faut que je mesure un bon coup de kick pour voir ce qu'il se passe.



edit :
le temps de l'impulsion sur le thyristor c'est le "dwell time" non ?

Non le Dwell time est utilisé sur les TCI c'est le temps de chargement bobine,  la il te faut un temps pour amorcer la conduction du thyristor.
Et effectivement il faut un tour complet pour faire le calcul de vitesse de rotation donc deux pulse capteur.

OK merci, je vais voir la doc du thyrisor ça va m'aider à trouver le bon delay pour le commander + des test bougie à la main sera encore mieux !


Je reviens sur la question concernant le retour de Kick. (Les autres copains peuvent aussi aider là !Pour soulager un peu Stef3376 de toutes mes questions )

Dois-je m'en inquiéter?
j'ai réussi à réduire  d'un front le calcul :
Il y'a même moyen que ça soit sur le premier, mais pas très précis pour le moment.

La question c'est : Si je cherche le point de compression, genre je descend le kick jusqu'au "point dur" , je remonte, puis je kick un grand coup.
Pendant la descente ou je cherche le point dur, il risque d'y avoir une explosion non ?

ps : j'ai jamais eu de retour de kick et n'ai jamais connu de moto avec ce 'risque' là donc je ne connais pas le phénomène. Ni le pourquoi du comment !?!?

Oui la pour le kick je ne vais pas être d'une grande aide...

Stef3376 a écrit:

Oui la pour le kick je ne vais pas être d'une grande aide...

Après si tu as une idée quand même c'est volontiers

easy_ride a écrit:

La question c'est : Si je cherche le point de compression, genre je descend le kick jusqu'au "point dur" , je remonte, puis je kick un grand coup.
Pendant la descente ou je cherche le point dur, il risque d'y avoir une explosion non ?

Le cycle du 4 temps est;
Admission,
Compression,
Explosion,
Échappement.

L'explosion a lieu la première fois au tout tout début de la descente du kick.

Par contre je ne saurai pas te dire combien de tours réalise un coup de kick??



et non je ne crois pas qu'il puisse y avoir une étincelle en dessous d'un certain régime moteur.

encore que ça m'est arrivé de démarrer mon XT sans le vouloir, justement en cherchant le point de compression....

Te voila plus avancé!

marchdu a écrit:

easy_ride a écrit:

La question c'est : Si je cherche le point de compression, genre je descend le kick jusqu'au "point dur" , je remonte, puis je kick un grand coup.
Pendant la descente ou je cherche le point dur, il risque d'y avoir une explosion non ?

Le cycle du 4 temps est;
Admission,
Compression,
Explosion,
Échappement.

L'explosion a lieu la première fois au tout tout début de la descente du kick.

Par contre je ne saurai pas te dire combien de tours réalise un coup de kick??



et non je ne crois pas qu'il puisse y avoir une étincelle en dessous d'un certain régime moteur.

encore que ça m'est arrivé de démarrer mon XT sans le vouloir, justement en cherchant le point de compression....

Te voila plus avancé!

4 temps = 2 tours de vilo.
Et vue notre cdi d'origine, ou celui qui je programme, une étincelle à chaque tour (donc une qui ne sert à rien)

Je vais mesure demain ou ce week-end combien de tour j'arrive à faire avec un coup de kick.

Au pire, laisser le coupe circuit pendant qu'on cherche le point G, puis l'enlever pour le vrai coup de kick. Ça mérite test tout ça.

Voilà voilà, je suis avancé mais pas trop

Sinon j'ai pensé faire tout comme le CDI de Transmic,
Utilisé la capteur 12° pour contrôler directement le thyristor.
+ Arduino pour gérer l'avance > à 12°.



Mais les questions qui peuvent se poser sont (surtout la premiere !):

1- Qu'est ce qui se passe si on déclenche à (par ex) 30° (par arduino et calcul) puis à 12° (direct du capteur).... ?

2- Le temps de charge du condo sera suffisant ?
--->pire des cas  : déclenche à avance max (environ 35-40°) et déclenche aussi à 12° :
--------> on a plus que 360-(35-12) degrée pour charger le condo
-------------->

Code:

t = R.C.ln(Va - Vi/Va - Vf)

R : Résistance du circuit de charge en ohm
C : Capacité du condensateur qui se charge en farad
Va: Tension d’alimentation du circuit (appelée aussi tension asymptotique) en volt
Vi : Tension initiale (tension de départ) aux bornes du condensateur en volt
Vf :Tension finale (tension d’arrivée) aux bornes du condensateur en volt
t : Temps que mettra le condensateur pour se charger de la tension Vi à la tension Vf en seconde

Oui mais ....c'est quoi ma résistance? et j'aime pas les calculs...etc...

La résistance dans le cas présent c'est celle de la bobine d'allumage (je pense que les fils sont négligeables) à voir dans la RTM.
Sinon pour ta question 1 ne te bille pas trop pour cela car cela marche pour le CDI transmic... Cela doit donner une étincelle à l'avance max suivi d'une deuxième (peut-être plus faible) à 12deg. J'ai tendance à penser que cela ne sera pas nuisible.

Aujourd'hui bonne journée pour un peu de soudure, de beaucoup de réflexion, de calcul et enfin des test à l'oscillo pour au final...monter le tout sur la bécane et :
.
..
...
....
.....
Premier démarrage du XT depuis bien longtemps!!!!!!!!
YYYYEEEAAAAAHHH !


Bon l'aventure est loin d'être terminée.
C'était pour valider la première partie du montage à savoir : Allumage sans passer par l'arduino en utilisant le capteur 12°.
Le montage n'a donc pas encore sa greffe de l'arduino et des 2-3 composants associés.

Mais première satisfaction ! Le montage est validé! (ce n'est que un proto on est d'accord ! )

Les photos :






et la petit vidéo :

Bien Joué!

Stef3376 a écrit:

Bien Joué!

Je suis bien heureux qu'elle a demarré ! Quel plaisir



La question que je me pose pour la suite c'est :
Est-ce que j'utilise le capteur 36° ou non.. ?

J'essaie de peser le pour ou contre:
- plus précis de 12° à 32° (enfin plutôt 26-27° car temps de calcul et réaction ) si on prends le capteur 32°
- Quand même nécessaire de faire le front sur le tour suivant si on veut dépasser les 32°
- ?

Est-ce bien utile ? J'en sais rien en fait
pourquoi ne pas tout baser sur le capteur 12°?

Fais des essais, d'abord sur table et si tout te semble ok, sur ta machine. C'est le seul moyen de savoir.