Interface à base de pic pour gestion d'impulsions

Multiplier la fréquence ne t'apporte aucune précision supplémentaire.

Si au départ tu as 29, 30 ou 31 pulses le fait de multiplier par 10 te donnera 290, 300 ou 310. Je ne vois pas ce que tu gagnes comme précision.

Il suffit que tu mesures l'intervalle entre deux fronts montants (ou descendant si tu veux) pour connaître le temps mis pour faire un 48ème de tour. Repérer le créneau du PMH est un jeu d'enfants car l'inertie du moteur interdit une variation instantanée du régime.

Tu dis que tes impulsions sont bien précises et régulières. Mais si tu n'as pas confiance dans la précision de ces créneaux tu peux pondérer la mesure sur plusieurs créneaux.

Dans ta solution tu ne mesures le régime moteur que 4 fois par secondes. C'est très insuffisant. Ta précision sera au mieux de 1/12 ce qui est très insuffisant aussi (la multiplication de fréquence ne changera rien à cette présision qui est celle du nombre de pulses d'origine par intervalle de mesure. Donc quand tu liras 3000 tr/mn ce sera en fait entre 2750 et 3250 tr/mn.

Il faut absolument que tu reconsidère ton projet à la base en oubliant cette idée fausse que multiplier la fréquence apporte de la précision.

Ce n'est pas un point de vue, c'est une réalité objective. Si tu ne veux pas revoir ton projet tu devras te contenter d'une précision de 1/12.

JLB

jihelbi:
Multiplier la fréquence ne t'apporte aucune précision supplémentaire.
(...)
Dans ta solution tu ne mesures le régime moteur que 4 fois par secondes. C'est très insuffisant. Ta précision sera au mieux de 1/12 ce qui est très insuffisant aussi (la multiplication de fréquence ne changera rien à cette présision qui est celle du nombre de pulses d'origine par intervalle de mesure. Donc quand tu liras 3000 tr/mn ce sera en fait entre 2750 et 3250 tr/mn.

Je crois que tu te laisses un peu embarquer dans les choses. As-tu bien lu le PS du premier message? Pourquoi veux-tu absolument m'imposer TA façon de voir les choses qui est d'ailleurs fausse (je me suis aussi planté quelque part, un tour moteur donne 44 dents (- 4 manquantes), soit 352 impulsions une fois le signal régénéré et multiplié par 8 ) :

avec mon système, 2750tr/min donnent 4130 impulsions en 256ms, 3250 tr/min donnent 4881 impulsion (joli fossé!). il me suffit de diviser mon comptage d'impulsions par 1,5 (ou le multiplier par 0.66666) pour trouver la vitesse en tr/min. ma précision serait alors de +/-0.33tr/min, arrondissons à +/-0.5. Comment arrives-tu à une précision de +/-250?

Si je ne multiplie pas ma fréquence, alors 2750tr/min donnent 469 impulsions en 256ms, 3250 tr/min en donnent 545 impulsion. il me suffirait de multiplier mon comptage d'impulsions par 5,96 pour trouver la vitesse en tr/min. ma précision serait alors de +/-3tr/min. En plus, comme il manque 4 dents, certaines impulsions sont plus longues et m'induiraient en erreur.

J'ai fait ces calculs vite-fait, ils demandent à être vérifiés sur le terrain bien sûr.

Et je me répète, si j'ai pris ce choix, saches que c'est longuement réfléchi. J'ai déjà tenté une mesure de longueur d'impulsion, ça demande un lissage (en 1980, la mécanique n'était pas aussi précise qu'aujourd'hui) qui prend beaucoup de temps sur un arduino. Et je sais exactement quels signaux j'ai à disposition, et surtout ce que je veux en faire.

Comme tu n'as pas compris, j'ai rajouté en dessous les deux signaux que je veux :

Chaque impulsion obtenue dure 1/8ème de l'impulsion précédente (de toute façon, ce qui m'intéresse, ce sont les fronts descendants ou montants, pas les deux). Donc une impulsion représente 1/8ème de l'impulsion de départ, donc plus précis.

Mes 4 mesures par seconde sont justifiées par le temps disponible sur l'arduino, et après tout, ça ne concerne en rien le système à PIC : je veux faire une fonction bien précise sur un bout d'époxy, le reste du traitement se trouve à l'autre bout d'un fil (et dans un autre topic).

Reprenons : je demande une fonction précise, pas qu'on vienne tout me chambouler avec des solutions qui ne sont pas adaptées à mon projet. Si dans une usine, le patron te demande de peindre une voiture en rouge, tu auras du mal à lui faire comprendre que le vert c'est mieux.

Mais il n'existe pas de décimales aux pulses.

Dans mon exemple 29, 30 et 31 donnent une fois multiplié par 10 : 290, 300 et 310. Les valeurs intermédiaires 291,292,293 etc n'existeront jamais.

Pourquoi faire du hardware pour cela ??? Tu n'as qu'à prendre ton nombre de pulses et le multiplier par ce que tu veux (1 milliard si tu veux).

Il n'y a aucun gain de précision en multipliant une fréquence de pulses !!!!!!!!!!!!!!!!!!!!

JLB

Je ne veux rien chambouler. Tu peux bien mesurer une fréquence si tu veux même si personne ne fait ainsi.

Je veux juste te dire que la multiplication de fréquence c'est du hardware et du software qui ne sert absolument à rien.

JLB

Autre précision par l'exemple mais tu peux faire ce que tu veux.

Si tu n'avais qu'un pulse par tour tu pourrais par la mesure de temps donner un régime précis à chaque tour moteur. Par la mesure de fréquence il faudrait que tu sois à 3000 tr/mn pour avoir seulement 50 pulses par secondes. A priori il n'y a pas photo. A 900 tr/mn tu aurais 15 pulses soit une précision de 1/15.

JLB

jihelbi:
Je veux juste te dire que la multiplication de fréquence c'est du hardware et du software qui ne sert absolument à rien.

JLB

C'est bien ce que je pensais, t'as pas compris du tout... le PIC ne doit pas mesurer la fréquence, mais la multiplier (la valeur qu'il peut mesurer dans le premier timer, une fois qu'elle est transmise dans le second timer, on s'en fout). Regarde le graph que j'ai mis : c'est le nombre d'impulsions qui est multiplié, pas une valeur numérique! Si je compte mes impulsions sur la troisième courbe, tu ne crois pas que je vais compter plus ou moins d'impulsions? et pas forcément par bloc de 10... la preuve :

Si mon signal d'entrée fait 25 impulsions / sec (25Hz quoi), je le multiplie par 10 dans le pic à l'aide de ses deux timers. en sortie du pic, j'ai quoi? ben un signal qui fait 250 impulsions par seconde, non?

Bon, dans l'arduino qui est à l'autre bout du fil, si je compte les impulsions du signal d'entrée sur une fenêtre de 990ms, alors je trouve 24 (il faut une seconde complète pour trouver 25 imp). Avec cette même base de temps, je compte le signal généré par le pic : je trouve 247 impulsions. Pour savoir où j'en suis et retrouver le nombre d'impulsions de mon signal d'origine, comme la fréquence à été multipliée par 10, je divise le nombre d'impulsions par 10, et je trouve : float x = NB_Imp / 10 = 24.7

Est-ce que mon comptage n'est pas plus précis en multipliant ma fréquence avant comptage? avec 990ms, je suis très proche de la seconde, donc mon comptage devrait être très proche de 25. avec ma solution, je suis plus proche de 25 qu'en ne comptant que les impulsions de départ.

Dans mon exemple, mon moteur tourne à 34,090909... tr/min.

Comptage des impulsions d'entrée (abstraction des dents manquantes pour le coup) : je dois multiplier le nombre d'impulsions comptées par (60/44/0.99 = 1.37741) pour trouver la rotation du moteur. donc j'ai compté 24, je trouve une vitesse de 33.05784 tr/min Erreur = ~ -1,03.

Comptage des impulsions de sortie du pic : je dois maintenant multiplier par (60/44/0.99/10 = 0,137741), j'ai compté 247, je trouve 34,022027 tr/min. Erreur = ~ -0,07.

Quelle méthode est la plus précise? sachant qu'en réel, mon moteur tournant à 34.09090909... tr/min donne 24.75 impulsions par tranche de temps de 0.99s... dans le premier comptage, on a perdu 0,75 impulsions, dans le second, seulement 0,05. (0,75 x 1,37741 = 1,03305 et 0,05 x 1,37741 = 0.068882). Si t'arrives encore à me dire que je me plante, va falloir que je trouve une nouvelle forme pour te l'expliquer!

De même, il m'arrive d'utiliser le truc suivant pour arrondir un nombre avec des décimales :

float arrondi2(float x){
  float y;
  y = x*100;
  return (int(y)/100);
}

Tu vas me dire que x contenait déjà des décimales... ok, mais dans un beau signal carré où on synchronise les impulsions sur front montant, le front descendant ne correspond-il pas à une demi impulsion (0,5)?

Et un signal de période 1 seconde, est-ce que pour t = 1,4541220147 s on ne peut pas considérer le signal quand même? les impulsions contiennent une donnée importante : la période (le temps entre deux impulsions) qui s'exprime en secondes, ms, µs, ns... ne sont-ce pas des décimales, tout ça? Et c'est justement le rôle des impulsions d'un signal (hormis PWM) de donner des bases de temps. Si ta montre n'affichait pas les secondes, comment ferais-tu un oeuf à le coque? n'essaierais-tu pas d'inventer un système qui te permet de découper les minutes de ta montre et ainsi avoir le temps correct pour la cuisson?

sur mon moteur, une dent correspond à 8.182°. j'ai quand même le droit de savoir ce qu'il se passe quand il est à 45°, même si ça na correspond pas à une impulsion... c'est pas un moteur pas-à-pas... (45 degrées correspond à 5,5 dent).

essaie de comprendre : le système qui compte les impulsions existe déjà. il me faut juste un petit circuit qui adapte le signal. (vais finir pas le faire moi-même...)

Je reconnais que j'ai bien tartiné le truc, un beau pavé, alors si j'ai pris le temps de l'écrire, prends le temps de lire, merci.


A part ça, quelqu'un saurait me programmer un PIC? je viens de télécharger MPLab, pour voir si ça peut me le simuler dans un premier temps... Pis ben... J'voudrais bien programmer moi-même, mais j'ai pas de port // sur mon PC pour utiliser les montages du net.

Bon, dans l'arduino qui est à l'autre bout du fil, si je compte les impulsions du signal d'entrée sur une fenêtre de 990ms, alors je trouve 24 (il faut une seconde complète pour trouver 25 imp). Avec cette même base de temps, je compte le signal généré par le pic : je trouve 247 impulsions. Pour savoir où j'en suis et retrouver le nombre d'impulsions de mon signal d'origine, comme la fréquence à été multipliée par 10, je divise le nombre d'impulsions par 10, et je trouve : float x = NB_Imp / 10 = 24.7

Ce post relève du canular...

COMMENT LE PIC TROUVE T-IL 247 ???????????? IL NE PEUT TROUVER QUE 240 OU 250 OU 230 !!!!!!!!!!!!!!!!!!

JLB

PS: surtout ne pas craquer ! surtout ne pas craquer ! surtout ne pas craquer !..

jihelbi:
Ce post relève du canular...

COMMENT LE PIC TROUVE T-IL 247 ???????????? IL NE PEUT TROUVER QUE 240 OU 250 OU 230 !!!!!!!!!!!!!!!!!!

JLB

PS: surtout ne pas craquer ! surtout ne pas craquer ! surtout ne pas craquer !..

J'essaie de rester zen, mais t'es bougrement têtu! je remets les courbes :

Les deux premières sont identiques, c'est le signal qui sort du capteur. Moi, je veux juste que le pic me fournisse les deux autres courbes, c'est à dire un signal contenant 8 fois plus d'impulsions que celui du capteur. Regarde l'algo du premier post : où vois-tu un comptage? ben non, y'a pas besoin de compter! il suffit de mesurer la période des impulsions avec un timer à 2MHz et de générer avec cette même mesure mais sur un timer 8 fois plus rapide un signal carré... c'est pas assez clair? ]:slight_smile:

MA METHODE DE MESURE SE TROUVE DANS UN AUTRE SYSTEME QUE J'ETALERAI DANS UN AUTRE TOPIC! ICI? IL FAUT JUSTE ME PONDRE LES TROISIEME ET QUATRIEME COURBES.

compte les impulsions de la troisième courbe : tu la comptes 10 par 10? ben pas moi, et encore moins l'arduino dont on ne parle pas ici.

et je répète encore :

le PIC ne doit pas mesurer la fréquence

le pic NE COMPTE PAS LES IMPULSIONS vindédiou!

Je reconnais que j'ai bien tartiné le truc, un beau pavé, alors si j'ai pris le temps de l'écrire, prends le temps de lire, merci.

t'as lu cette phrase? T'es en train de parler d'un autre sujet, et j'imagine que si quelqu'un pouvait me rendre le service que je demande, ben il n'aura plus trop envie de se farcir tout ça...

Bon, dans l'arduino qui est à l'autre bout du fil, si je compte les impulsions du signal

C'est l'arduino qui compte les impulsions!!! et là, c'est un topic qui parle d'une interface contenant un PIC, mais pas d'arduino!

Il est des cas fortuits où l'homme le plus entreprenant est soumis à des vicissitudes des plus aléatoires...

Il n'est point besoin de réagir à l'épiphonème du docte logographe dont je tiens à dulcifier l'éloquence mordacite pour sémiologer une prose hyaline dont l'indéhiscence ne peut apparaître qu'à quelques onguligrades lignicoles à l'affut d'amphibologies gonadotropiques.

A bon entendeur adieu à ce post...

JLB

PS: J'aurais du accepter de lui faire son PIC multiplicateur. Il proposait de l'argent après tout...

Bien tenté, mais ça montre juste que tu t'es rendu compte de ta bourde et que tu n'oses même pas le dire... utiliser des mots si savants est un beau bouclier pour cacher sa bêtise.

Non, je ne paye pas l'intervenant, je le défraie, c'est pas vraiment pareil.

Quelqu'un a compris ce que je cherche et pourrait m'aiguiller?

Réouverture du sujet XD

Je précise également que j'ai indiqué à jihelbi qu'un forum est un espace ouvert où l'on partage les opinions et non pas un exutoire qui sert à imposer ses idées comme étant unique en pensant de façon unilatérale que les autres sont des ignares hébétés profonds.

Je n'ai jamais utilisé un PIC de ma vie (je ne veux pas de faire de faux espoir ;)), en revanche la subtilité de la multiplication de la fréquence me titille les neuronnes...

Ce que j'ai compris :

Tu as un contrôleur côté moteur (disons le PIC), qui lit le signal suivant :

(Au fait, quelle est la fréquence max de ce signal ?)

Il doit :

  • Constituer, un signal basé sur la fréquence T multipliée (disons 10T, c'est humainement plus facile même si au final ça sera 8T ou 16T) ET combler la(es) dent(s) manquante(s)
  • Générer un second signal qui ne montera que durant 1T, juste après constatation de la dent manquante

Le signal multiplié me semble relever du post traitement (ou de l'estimation) et tu ne pourra le générer qu'avec plusieurs T de retard, est-ce acceptable ? dois-tu synchroniser le second signal pour qu'il accuse le même retard ?

Dans le cas ou tu préfère l'estimer à l'avance, tu pars plutôt sur le cas des fronts montants ou descendants ?

Tu as un autre µc qui lit les 2 signaux générés :

  • Il compte régulièrement les changements d'état du premier signal transmis pour définir la vitesse de rotation du moteur (c'est la que la multiplication est utile).
  • Fais je ne sais pas quoi de la dent manquante en rapport avec le retard à l'allumage ?

Suis-je dans le ton ?

Pour avoir 2 timers 16 bits, ne peux-tu pas étendre "logiciellement" l'un des timers 8bits d'un 328P ?

Sev

Pour multiplier une fréquence, une PLL genre CD4046 ne ferait-il pas l'affaire ?

On va réexpliquer un peu...

On part du volant moteur (qui est fixé à l'arbre de sortie du moteur, donc qui tourne tout pareil) :

On voit ici les deux crénaux élargis, à la fin desquels on trouve notre info "synchro" (décalée en réalité de 90°, pour permettre au µP d'avoir un peu d'avance pour calculer le bon moment d'étincelle (entre 8 et 45°avant le PMH réel), ce qui lui laisse 1/4 de tour moteur pour faire son petit calcul).

Pour l'instant, on s'affranchit du décalage...

Le capteur fournit le premier signal :

Il faut donc un circuit qui me sorte les deux signaux du bas.

Dans mon idée,

1) un timer 16 bits mesure le temps T ou 3T entre deux fronts descendants du signal d'entrée, avec une base de 2MHz.
Pour rester ne pas déborder, le temps le plus long étant 3T, ne doit pas dépasser 65535/2.106 = 32,768 ms, soit Tmax = 10,92ms, ce qui correspond à une vitesse de rotation du moteur de Vmot-min = 60/44/Tmax = 125tr/min. De même, On trouvera Vmot-max = 2730000tr/min, mais on n'ira pas jusque là...

  1. A chaque impulsion du capteur, on trouve donc un temps T(n) = T (dent normale) ou 3T = (dent PMH). Donc si T(n) > 2xT(n-1), on en déuit qu'on a à faire à une dent PMH (comme le précisait jihelbi, avec l'inertie du moteur, la vitesse de rotation ne peut pas varier trop vite, et pour que la comparaison T(n) > 2xT(n-1) soit vérifiée en dehors d'une dent PMH, cela reviendrait à faire passer le moteur de 1000tr/min à 500tr/min en 1ms, c'est pas très pensable). Donc deux cas :
    2.a) Si T(n) > 2xT(n-1) (dent PMH) : on met à 1 la sortie "synchro".
    2.b) Si T(n) < 2xT(n-1) (dent normale) : on met T comme nouvelle base pour le timer de sortie (qui tourne à 16MHz) et on met à 0 la sortie Synchro.

Je pense qu'avec ça, j'ai mes deux signaux. Reste une sombre histoire de débordements (lors du démarrage par exemple) du timer d'entrée (si le moteur tourne en dessous de 125tr/min), de ne pas générer de signaux, mais c'est accessoire.

UniseV: Pour avoir 2 timers 16 bits, ne peux-tu pas étendre "logiciellement" l'un des timers 8bits d'un 328P ?

J'y avais pensé, mais j'étais tellement dans mon idée d'un pic à côté qui me gère le tout... attends... heu... En effet, je pourrais utiliser le timer2 en mesure d'entrée avec une ISR(T2_OVF) qui incrémente une variable genre T2_MSB et le timer1 en générateur de sortie avec ICR1H = T2_MSB; ICR1L = TCNT2;
Pas bête... je crois que je vais tester...

barbudor : Pour multiplier une fréquence, une PLL genre CD4046 ne ferait-il pas l'affaire ?

j'en parlais aussi avec Al1fch, par rapport aux dents manquantes, la PLL ne risque pas de "dérailler" un court instant? J'ai pas trop bossé sur les PLL, car à l'école (dans l'temps), on ne les utilisait que pour émission/réception radio, c'était encore du temps où on ne savait pas faire de µP aussi rapides que les quartz, maintenant, les quartz sont largement dépassés par la vitesse de l'électronique... Donc je ne vois pas trop. (puis je me suis spécialisé très vite dans l'audio, donc dès qu'on passe le "mûr du son" qui chez moi est à 300KHz, je suis tout perdu, et je n'utilise jamais de PLL)... Mais si t'as une idée, pourquoi pas...

Et pourquoi ne pas utiliser les 2 sorties "hard" d'un même timer 16bits ?

Genre :
OCR1A & OCT1B sur un 328P.

Sev

UniseV:
Et pourquoi ne pas utiliser les 2 sorties "hard" d'un même timer 16bits ?

Genre :
OCR1A & OCT1B sur un 328P.

Sev

Je vois pas trop... il ne me faut qu'un seul générateur de signal carré... Faut que je regarde comment configurer mon timer justement...

Salut,

Super_Cinci:

UniseV:
Et pourquoi ne pas utiliser les 2 sorties "hard" d'un même timer 16bits ?

Genre :
OCR1A & OCT1B sur un 328P.

Sev

Je vois pas trop... il ne me faut qu'un seul générateur de signal carré... Faut que je regarde comment configurer mon timer justement...

Le générateur de signaux et l'interruption d'overflow/comparaison d'un même module OCRx sont liée physiquement, mais les modules sont séparé entre eux.

Avec le Timer2 (par exemple) tu peut générer un signal carré en utilisant OCR2A + générateur de signaux A.
Et faire ton signal n°2 avec l'interruption "compare match" de OCR2B (+ morceau de code).

Seul contrainte : 1 même timer = 1 prescaler commun, il faut donc calculer le prescaler pour que les valeurs de OCR2A et OCR2B ne dépasse pas la valeur max de TCNT2 (16 bits).

La comme ça, je ne vois pas du tout. Qu'est le "générateur de signaux A"? Il me parrait difficile d'utiliser le timer 2 en sortie, donc j'ai fait un premier code pour le 328p :

/*********************************************
**        Multiplicateur d'impulsions       **
**********************************************
**        Circuit d'accessoire pour         **
**        ODB / REGULATEUR de vitesse       **
**********************************************
** Pin / por - Signal                       **
**  02 - PD2 - PMH IN                       **
**  09 - PB1 - Imp moteur OUT               **
**  10 - PB2 - Imp PMH OUT                  **
*********************************************/

volatile byte T2_MSB;  // extention logicielle de timer2
volatile word TCNT2_New, TCNT2_Old; // ancienne mesure de timer2

void Timers_Setup(){  // configure les timers 1 et 2
  TCCR1A = 0x02;   // WGM1 = fast PWM
  TCCR1A += 0x80;  // Activation PWM sur OC1A
  TCCR1B = 0x18;   // (WGM1 = Fast PWM)
  OCR1A = 200;  // durée d'impulsion sur OC1A
  
  TCCR2A = 0x00; // normal port operation
  TCCR2B = 0x00; // Clock = 0Hz
  TIMSK2 = 0x01; // int sur OverFlow
}

void Timers_start(){
  TCCR1B += 0x01;   //  Prescaler = 1 (16MHz)
  TCCR2B = 0x02; // Clock = 2MHz
  EICRA = 0x02;  // autoriser INT0
}

void setup() {
  Timers_Setup();
  DDRB |= 0x06; // pins PHM_OUT en sortie
  DDRD &= 0xFB; // pin PMH en entrée
  PORTD |= 0x04; // activation pullup pin PMH
  Timers_start();
}

ISR(T2_OVF){   // extention logicielle de T2 en 16 bits
  T2_MSB++;
  if (T2_MSB = 0) { // débordement, le moteur ne tourne pas assez vite ou pas du tout)!
    // a définir
  }
}

ISR(INT0_VECT){   // réception impulsion capteur PMH
  TCNT2_New = TCNT2 + (T2_MSB << 8);    // lecture Timer2
  TCNT2 = 0;
  T2_MSB = 0;  // mise à zéro timer2
  if (TCNT2_New < TCNT2_Old){  // impultion "normale"
    ICR1 = TCNT2_New;   // update Timer1
    TCNT2_Old = TCNT2_New << 1;  // préparation de la prochaine comparaison (TCNT2_Old = TCNT2_New * 2)
    PORTB |= 0xFB; // impulsion PMH OFF
  } else {                     // Impulsion "PMH"
    PORTB |= 0x04; // impulsion PMH ON
  }
}

void loop() {
}

Sachant que pour le tester, j'ai un second code qui me génère le signal du capteur à faire tourner dans un MEGA2560 (je n'ai que ces deux cartes sous la main actuellement). En même temps, la MEGA me génèrera également les autres signaux (vitesse véhicule, conso...) histoire d'avoir un banc de mesure complet...

Super_Cinci, merci pour tes explications, mais je n'ai pas trouvé l'information suivante : "A quelle vitesse max tourne cette roue dentée ?"
D'ailleurs j'ai une autre question : à quelle vitesse minimum tourne cette roue dentée quand le moteur est allumé (ralenti) ?

Je te prépare une proposition de parametrage de timer... qui j'espère te plaira :roll_eyes:

Sev

UniseV:
Super_Cinci, merci pour tes explications, mais je n'ai pas trouvé l'information suivante : "A quelle vitesse max tourne cette roue dentée ?"
D'ailleurs j'ai une autre question : à quelle vitesse minimum tourne cette roue dentée quand le moteur est allumé (ralenti) ?

Je par du principe que lorsqu'on démarre le moteur, il tourne aux environs de 200tr/min, puis une foi au ralenti, minimum 600tr/min. Max : 10 230tr/min (le 230, c'est une vilaine histoire que 10230 = 10 x 1023 et que analogRead() renvoie au max 1023. C'estcon, mais dans l'avenir, ça peut avoir son importance...)

Bref, pour les trois régimes listés ci-dessus, on a :
x = 200; 600; 10230. (tr/min)
T = 6.82ms; 2.27ms; 133.3µs.
3T = 20.46ms; 6.82ms; 400µs.

la formule magique : T = 60/44/x , x étant la vitesse de rotation du moteur en tr/min.