Discussion :

[comode]

Bonjour,

Dans le cadre d'un petit projet arduino consistant à mesurer le pouls, j'échantillonne un signal (~10-20hz) provenant d'une photodiode éclairée par une diode IR au travers du doigt.

Le signal est traité à l'aide d'un filtre "Butterworth" puis d'un autre filtre "IIR" pour supprimer la composante continue du signal. J'ai donc un signal relativement propre, mais d'amplitude malgré tout assez variable dans le temps, surtout lorsque le capteur bouge un peu.



Alors, non, ne vous inquiétez pas, je vais bien, le gros machin en plein milieu, c'est le capteur qui bouge un peu... et qui donc me modifie complètement mes amplitudes de signal... Sachant que je veux courir avec, donc que le capteur va nécessairement bouger un peu et qu'en plus la fréquence est elle aussi est amenée à varier significativement, je ne vois vraiment pas comment faire un algorithme susceptible de détecter efficacement ces pics dans le signal...

Je serais donc très reconnaissant envers toute personne qui saurait m'aiguiller sur une piste viable.

[dourouc05]

Il y a des algorithmes de détection de pic : http://stackoverflow.com/questions/2...40362#22640362, par exemple. Ensuite, tu peux faire un filtre sur tous les pics détectés (ceux qui sont aberrants, puisque tu sembles vouloir des pics à peu près tous de la même hauteur).

[Vincent PETIT]

Salut,

Qu'est ce qui t'intéresse dans ce signal ?

La fréquence des pics ?
L'amplitude des pics ?

Comment as tu échantillonné ?

Une boucle dans le soft ?
Interruption du Timer ?

Si tu l'as fait par interruption du Timer alors tu sais exactement le temps 't' qui sépare 2 éléments de ton tableau de données.

Pour connaître la fréquence, on détecte souvent le passage par 0 du signal 1 fois sur 2 et comme tu n'as plus de composante continue, ça tombe bien puisque tu passes par 0 et si tu as des problème de bruit autour de celui-ci alors tu peux aussi faire une détection de passage par un seuil un peu plus haut que 0. Etant donnée que tu sais exactement le temps entre les éléments de ton tableau alors le calcul de la fréquence devient assez simple.



Dans l'exemple ci dessous et si ton Timer débode toutes les 50ms (20Hz) alors il se passe :

soit 1.17Hz

Pour la détection suivante :

soit 1.33Hz

Ensuite :

soit 1.11Hz

En moyennant tout ça et en prenant en compte ce qui est en bleu sur le schéma, c'est a dire l'autre détection du passage par 0, alors tu peux avoir une bonne interpolation.

Pour connaître l'amplitude mais surtout pour détecter des pics, personnellement, je ferai une dérivée sur mon tableau d'échantillon ou plutôt le calcul du coefficient directeur.



Si tu passes par le Timer alors Echantillon2 - Echantillon1 est connu puisque c'est 50ms (intervalle entre 2 échantillons). En regardant la valeur de D' tu sais si le signal monte ou descend (plus ou moins fort) et je pense que tu peux détecter une montée significative suivie d'une descente significative = pic !

L'électronique que tu as mis en oeuvre + le réglage de l'ADC du Arduino auront un effet important sur le soft. Exemple ici http://www.developpez.net/forums/d16...ure-d-tension/ ou une personne tente d'acquérir des centaines de mV avec un ADC 10bits référencé a +5V (autrement dit les bits de poids forts ne serviront jamais)

[comode]

Bonjour et merci pour vos contributions.

@Vincent, En fait, l'essentiel de mon problème provient du contraste entre la partie gauche et la partie droite du graphique... Sur la partie gauche, je pense que je n'aurai aucun mal à "bricoler" quelque chose qui marche. Sur la partie droite aussi d'ailleurs... Le problème est plutôt de mettre en oeuvre une solution qui marche sur la partie droite ET la partie gauche du graphique !

Le but est bien d'une certaine façon de détecter la fréquence, mais ce qui m'arrangerait d'avantage pour la suite du projet, ça serait de détecter un pic en (quasi) temps réel !

Pour compléter un peu la description du projet, je n'utilise pas directement le CAN de l'atmega, mais une photodiode sur bus I2C qui intègre son propre convertisseur et qui envoie des interruptions externes une fois l'échantillon converti. Le problème n'est cependant pas un problème de timing, car même si la fréquence d'échantillonage ne dépend pas forcément de moi, ce n'est vraiment pas un soucis d'associer un temps à un échantillon ni de calculer l'inverse de la période pour obtenir la fréquence. Le vrai soucis, c'est de repérer un cycle.

Concernant l'algo proposé par dourouc05, faut que je regarde de plus près mais ça a l'air intéressant et surtout adapté... Je vais en tenter une implémentation. Je garde le calcul du coef directeur comme 2nd option !

Encore merci à vous.

Edit : C'est mal, j'ai pas répondu clairement aux questions
Qu'est ce qui t'intéresse dans ce signal ?
La fréquence des pics, et mieux encore, la détection en temps réel des pics. Remarque, pas obligé que ça soit forcément les pics comme tu le disais, il faut juste que je détecte la période du signal. Les pics me semblaient plus facile à détecter. L'amplitude n'a aucun intérêt.

Comment as tu échantillonné ?
Pour le moment, ça bug un peu avec l'interruption externe. C'est donc une boucle dans le soft qui attend un flag d'interruption dans l'un des registres du composant. Pour des raisons d'hygiène et d'économie de batterie, je m'occuperai de revenir à une interruption externe quand j'aurais réglé ce problème de détection de pic.

[Vincent PETIT]

Effectivement le premier algorithme "Smoothed z-score algo" a l'air pas mal.
Si je le comprends bien, il consiste a calculer l'écart type (la dispersion des échantillons) du signal par rapport à une moyenne glissante.

Sur l'animation du gars on voit bien, la standard déviation (écart type en vert) qui est en quelque sorte l'enveloppe et la moyenne glissante en bleue.

Par contre je n'ai pas compris a quoi sert la variable "influence" ?

[comode]

J'avoue avoir un peu de mal avec sa syntaxe algorithmique, et je ne connais pas mathlab... Enfin en me cassant un peu la tête dessus, je devrais y arriver...

Manifestement, l'influence est le poids des nouvelles données dans le calcul du threshold, avec 0 = ignorer les nouveaux échantillons... Enfin il me semble...

[ToTo13]

Si tu veux quelque chose de rapide et simple, tu peux utiliser un Top-Hat. Voir ici page 13 ou ici page 30.

[comode]

Bon, alors là dourouc05, je dis puisse la gloire éclairer ton chemin et allégresse être ta compagne pour l'éternité !

J'ai adapté (et énormément simplifié) l'algo de ton lien, et ça marche nickel ! Pour info a ceux qui tomberont un jour sur ce topic à la recherche d'une solution à ce problème, il a suffit de prendre un tableau (j'ai pris une taille arbitraire de 32 cases) que je remplie cycliquement avec les valeurs échantillonnées. A chaque nouvel échantillon :

Si abs(dernière valeur échantillonnée - moyenne du tableau) > écart type du tableau * 1.5 (valeur arbitraire, mais qui a l'air de bien marcher)
alors c'est un pic !

Encore un immense merci.

[pseudocode]

Pour info, la technique proposée est une approximation de "EWMA control chart".

https://en.wikipedia.org/wiki/EWMA_chart

D'ailleurs, vous remarquerez que la performance de EWMA chart est de 1.5*sigma...
... qui est la valeur arbitraire "1.5" que @comode a déterminé expérimentalement.

Dans le même genre d'idée, il y a les "Shewhart individuals control chart".

https://en.wikipedia.org/wiki/Shewha..._control_chart

[yannoo95170]

Si c'est uniquement pour détecter les pics, celà ne pourrait pas être détecté par un changement de signe (ou un passage à 0) dans la dérivée de la courbe ?

Car quand la courbe monte, sa dérivée est positive et quand la courbe descent sa dérivée est négative

=> là où la dérivée passe de positif à négatif , c'est un pic "en haut"
(et là où la dérivée passe de négatif à positif, c'est un pic "en bas")

La fréquence peut être déterminée en prenant l'inverse d'une période entre 2 pics hauts ou 2 pics bas
(on peut faire la moyenne de plusieurs périodes consécutives afin d'avoir une période moyenne, puis en déterminer la fréquence en en prenant l'inverse, si l'on veut un peu "lisser" les valeurs trouvées )

Je viens de relire le topic et la méthode donnée par comode a l'air relativement simple (un ardino, c'est pas vraiment une bête de calcul ...) et semble de plus (et surtout) très efficace

=> c'est celle que j'aurais tendance à priviligier dans ce cas de figure
(le seul truc qui me gène un peu dans cette méthode c'est qu'il faut calculer l'écart-type sur toute la courbe, mais on doit assez sûrement pouvoir limiter le nombre de points à prendre en compte en ne calculant qu'un écart-type glissant plutôt qu'un écart-type sur toute la courbe)

[Nebulix]

Sauf ton respect, quand la mesure n'est pas bien faite et que le signal issu du capteur n'a plus rien à voir avec le phénomène à étudier, aucun traitement informatique ne pourra donner la bonne réponse.