Reprise du message précédent :
 

Je sors du lurkage.
J'ai pas encore mon arduino, mais ça ne saurait tarder

Plein de projets pour allumer des diodes  

@deeplodokus et TotalRecall : trop tard, j'ai commandé hier comme ça met du temps à arriver.

 
http://fr.aliexpress.com/item/UNO- [...] a6ed851f59
 
essaye de voir si tu peux annuler pour prendre celui la

Colis déjà envoyé, ils ont été rapide pour une fois.

Pas grave, tu reprendras l'autre plus tard si tu veux refaire le plein de trucs à bidouiller
C'est vraiment pas cher
La même chose pièce par pièce aux tarifs en vigueur chez nous en magasin spécialisé ça doit vite être dans les 150 à 250€ (même si du fait de cette concurrence féroce ils s'alignent vaguement, je me souviens il y a quelques années ça faisait mal)

Le contenu de ce message a été effacé par son auteur

/!\ ATTENTION PAVE

Je développe sur Arduino, donc au final mon code devra quand même être dans la syntaxe Arduino. Mais c'est surtout la méthode pour arriver au résultat qui m'intéresse.

Données de départ:
Mon outil sert à mesurer la pression dans un moteur Wankel.
Je ne vais pas rentrer dans les détails du fonctionnement mécanique, en résumé le signal varie sous forme de pics. J'ai trois valeurs à mesurer qui reviennent en boucle.
Donc le signal fait: Pic1, pic2, pic3, pic1, pic2, pic3, etc ... La fréquence aux alentours des 4Hz mais variable suivant l'état de charge de la batterie et le démarreur.

Je dois logger les valeurs maximales de chaque pic de pression, cette partie fonctionne déjà bien.
Actuellement mon algo mesure l'entrée analogique et me ressort au final un petit array de la forme [max_pic1, max_pic2, max_pic3]
Je mesure également la période entre chaque pic de pression pour avoir la vitesse de rotation du moteur, c'est une donnée importante pour faire une correction suivant un abaque. J'ai donc un deuxième array avec [RPM_pic1, RPM_pic2, RPM_pic3]

La on est dans un fonctionnement normal du moteur avec 3 beaux pics de pression.

Mon problème:
Mon outil doit également pouvoir servir à controler un moteur HS et dans ce cas il peut manquer un ou deux pics de pression.
S'il manque un pic de pression le signal la sera de la forme: plat, pic2, pic3, plat, pic2, pic3, etc .... toujours plus ou moins à la même fréquence.

Dans ce cas mon algo décale les pics, il va enregistrer pic2 dans max_pic1, puis pic3 dans max_pic2, puis le deuxième pic2 dans max_pic3...
Les intervals entre les pics n'étant pas régulier je vais avoir des valeurs incohérentes dans l'array avec les rpm, entre pic3 et pic2 j'ai le double de la période, donc fréquence divisée par deux.
C'est cet aspect aujourd'hui qui me permet de visualiser qu'il me manque un des pics de pression: les valeurs de rpm ne sont pas cohérentes.
Le problème se complexifie quand il en manque deux sur les trois.

Mon objectif:
Prendre en charge un moteur HS.
Pour cela il faudrait pouvoir détecter un passage à vide. Je ne suis pas encore fixé sur la meilleure méthode, je pense qu'avoir une variable qui fait timer sera la meilleure solution, je connais les intervals mini et maxi théorique entre deux pics de pression.
En résultat il faudrait que mon array soit rempli avec un 0 en cas de pic manquant.

Voici le code que j'utilise actuellement
Les variables:
Pressure : entrée analogique
pressure_min : variable utilisée pour détecter un pic, principe d'hysteresis
max_pressure_PSI[3] : array pour stocker la pression pour chaque pic en PSI
max_pressure_bars[3] : idem en bars
rpm[3] : array pour stocker les rpm pour chaque pic

Bon, après des mois de standby (qui comprend notamment l'arrivée d'un chronophage à couches), je viens de trouver la motivation de ressortir mes petits projets de bidouillage à base d'Arduino  
 
L'occasion donc de sortir de leur emballage les Pro Mini et les NRF24L01+ que j'avais commandé il y a un bail chez les chinois, et tester MySensors.
 
Je soude donc des connecteurs sur un des ProMini, je commence à lire la doc, et là je me rend compte qu'ils sont en 5V alors que les modules radio ont besoin de 3.3V (je le savais en plus à l'époque, mais entre temps j'avais oublié).
 
 
Bon, ben heureusement que j'ai 2 Uno (qui ont une sortie 3.3V), sinon j'étais bon pour poireauter 3-5 semaines (ou bricoler un pont diviseur de tension, je sais pas si c'est adapté dans ce cas). Mais ça va quand même limiter l'étendue de mes expériences
 
 
 

La fréquence est super basse donc tu peux t'en sortir sans interruptions je pense, c'est plus un souci d'algo.
Si j'ai bien compris :
S'il manque un pic tu auras un intervalle entre les différents pics non constant.
S'il en manque deux tu auras un PWM et une fréquence totalement hors tolérances.
Dans les deux cas ça peut se détecter
Je n'ai pas lu ton code mais j'ai l'impression que tu te focalises sur la détection des pics sans tenir trop compte de l'intervalle entre eux alors que c'est là que serait la solution (toujours en supposant que j'ai compris )

Peut être qu'avec un chronogramme pour chaque cas ça serait plus simple à visualiser si tu peux sortir ça ?

Après j'avoue je n'ai pas assez pratiqué les interruptions pour être à l'aise avec donc quand je peux faire sans ça me va bien, mais si ça se trouve je raconte des conneries et il y a très simple.

Avertissement express : oui il y a une alim 3.3V sur Arduino mais ça ne fonctionnera pas forcément bien si le truc branché derrière est branché sur les I/O de l'Arduino qui reste en 5V. Soit tu balanceras du 5V sur ton entrée en 3.3V soit tu balanceras du 3.3V sur ton entrée en 5V selon le sens, et dans les deux cas c'est pas une super idée
J'ai pas regardé ce qu'est un NRFbidule, je parle de façon générale.

 
En effet je n'envisage pas du tout l'utilisation d'interruptions, c'est du pur algo
 
Je vais poster des chronogrammes si besoin, je ne voulais pas surcharger le truc.
J'ai besoin de la détection de pic, car c'est ca qui me permet de déclencher la mesure et de garder la valeur max mesurée.
 
Au vu de ce que tu as compris ma description n'est pas claire, donc les chronogrammes vont arriver.

J'ai lu qu'une fois, c'est sans doute ma faute

https://itechnofrance.wordpress.com [...] -larduino/

Non c'est bon, seulement l'alim a besoin d'être en 3.3V, le bus SPI supporte le 5V.

Le NRFbidule est tolérant 5V  

Je ne dis plus rien alors

 
 
Je prévois de me monter un EDTracker, un tracker 3DOF basé sur un Arduino ; et j'aimerais pourquoi pas me lancer dans des petits projets IoT. Du coup, je suis ici avec intérêt

 
Voila les graphs.
 
Donc un exemple de mesure sur un moteur en bon état:
 

 
Et un moteur avec une face HS, on voit qu'il y a donc un pic sur 3 qui est à zero mais la fréquence reste la même:
 

 
Dans mon code actuel je détecte le passage d'un pic (ou face) à une autre avec un hysteresis, si je passe au dessus de la consigne puis repasse dessous c'est que j'ai eu un pic et que je dois mesurer le suivant.
 
La donnée qui me bloque le plus c'est que la période n'est pas fixe, elle peut varier de pret de 15-20%. Du coup je ne sais pas par quel coté prendre le problème.

Quand tu dis que la période n'est pas fixe, tu veux dire qu'elle n'est pas fixe pour un même moteur ? Ou qu'elle n'est pas fixe pour des moteurs différents ?
 
Autre question, pour un moteur donné, si un pic N est absent, il sera absent à chaque cycle ?
 
J'y connais rien dans ton domaine mais d'un point de vue algorithmique pur, je te conseillerai de faire une "analyse du moteur" avant de chercher à recupérer les valeurs max et rpm.
1) définir un intervalle de ms pour ton cycle
2) sur cet intervalle, tu recherches des pics (0, 1, 2) si le moteur est HS, 3 pics sinon.
3) à partir de là, tu sais si le moteur est HS ou non, donc tu peux remplir les trous dans les pics
 
Ca te semble faisable ?

Au pire, tu câble une LED en série entre l'alimentation 5V et le module radio. Avec la tension de chute classique d'une LED (~ 2V), ça fonctionne (du fait que le NRF24L01+ consomme moins qu'une LED).

 
Entre deux mesures sur le même moteur à 10 minutes d'interval tu peux avoir une différence de vitesse de rotation, c'est dépendant du niveau de la batterie qui se vide à chaque essai. On peux commencer à 250tours/min et finir à 210tours/min.
Le soucis c'est que je bosse en temps réel, je ne loggue pas la mesure pour ensuite l'analyser, je n'ai pas la place dans l'arduino.  
Les séries que tu vois c'est une capture par le port série sur un PC pour validation.
 
Donc je dois en même temps mesurer le signal pour capturer les pics de pression et détecter si un pic est manquant pour mettre zero à la place.

Interesting    
 
Ça fait partie du genre d'astuce que je voudrais bien arriver à pouvoir trouver par moi-même. J'ai de très faibles notions en électronique, et je suis vite largué dès qu'il s'agit de faire des montages avec des diodes, des transistors, ou de calculer la "bonne valeur" d'une résistance ou d'un condo pour une situation donnée.
 
Bref, faudrait que je je prenne le temps de faire un tour sur le topic électronique pour voir s'il y a des ressources (en ligne ou livre) pour apprendre un peu plus, parce que je suis limité à assembler des modules et des montages un peu en mode :

Sauf que les modules radios sont gourmands et que le 3.3v fourni par l'arduino est carrément pas suffisant

 
Ce n'est que mon avis mais si j'avais à résoudre ce genre de problème --> interruption
 
Je n'ai pas étudié tout ton truc mais voila le principe que j'utiliserai :
 
Tu déclenches une interruption peut être toutes les 10 ms dans laquelle tu lis ton capteur de pression ( accessoirement, je ferais ça aussi pour mesurer ton signal, ça permettrai d’échantillonner a fréquence fixe )
Si la pression mesurée correspond à un pic, tu commences a incrémenter une variable.
Comme tu connais approximativement la fréquence du signal à mesurer, tu refais des lectures de ton capteur quand ta variable VAR est tmin<VAR<tmax avec une plage suffisamment large pour être sur de tomber sur un pic quand il devrait y en avoir un.
Tu remets ta variable à zero.
Et ensuite tu n'a plus qu'a remplir ton tableau en fonction de ce que tu as mesuré entre tmin et tmax ( ton pic ou ton 0 ).

 
Je préfère balayer le plus rapidement possible mon signal pour ne pas passer à coté du pic de pression qui peut etre vraiment court.
Mais globalement ca ne change pas vraiment le principe et ton idée est applicable oui.
 
Ca me donne même une autre piste de recherche peut être plus facile à implémenter pour moi.
 
Merci

Ba je ne sais pas trop ce que fait ton programme en dehors de la mesure mais tu parles de logger.
Tu enregistres sur une carte SD ou tu envoies ça peut être sur une liaison série ?
 
Dans les deux cas tu pourrais peut être avoir un échantillonnage plus rapide si tu le faisais par interruption plutôt que d'attendre que ta transmission ou ton enregistrement soit fait pour re mesurer ton signal.
ça rentre dans une entrée analogique ton signal ou c'est un capteur numérique ( I2C SPI etc ... ) ?
Après je dis ça sans savoir ce que fait ton programme donc tu as peut être déjà une interruption qui se déclenche quand la mesure est prête ?
Ou alors tu as une gestion un peu plus évoluée genre tu échantillonnes dans une boucle 100 fois avant de traiter le résultat et de logger/transmettre les données ?

Sur quel Atmel tu fais ça ?

Je ne logge rien, je ne stocke rien justement.
Ca tourne en temps réel sur un 328P à 16Mhz et la boucle d'acquisition/traitement tourne à 1KHz, je n'ai pas réussi à aller plus vite et je ne pense pas qu'une interruption pourrait m'aider. Mais ca me suffit amplement sachant que mon signal d'entrée est aux alentours de 4 Hz, j'ai un échantillonnage suffisant.
 
C'est un petit boitier autonome qui permet de tester l'etat du moteur, on le branche, on fait tourner le moteur et le résultat s'affiche sur un écran. Simple et pas cher, c'est l'idée
 
Ta piste est la bonne je pense, si le signal n'est pas remonté au bout d'un certain interval de temps c'est que le pic est absent et que je peux passer au suivant. C'est un test simple à rajouter à ma fonction existante.

 
Pourtant tu as dis que tu loggais    
 
Effectivement 1khz c'est pas mal, surtout que tu fais un peu de calcul en virgule floatante sur un petit 8bit. ça m’étonne pas que tu n'arrives pas à aller plus vite.
Déjà si tu le faisais tourner à fond ( 20 Mhz ) tu pourrais peut être aller plus vite ou conserver le même échantillonnage mais faire plus de traitement.
 
Si tu t'en sors sans interruption tant mieux mais si tu veux plus tard faire évoluer ton système, je pense que l'équilibre va être un peu fragile puisque chaque instruction supplémentaire que va exécuter ton micro va décaler la fenêtre dans laquelle tu doit vérifier la présence ou non de ton pic.
 
C'est quoi ton LCD ? ça peut prendre du temps d'écrire sur certains de ces machins la    
 
 
 
 

 
Non j'ai dit que les données venaient d'un log, pas que le programme log tout
 
Et oui j'ai remarqué pour l'affichage, la première version faisait de l'affichage en même temps que l'échantillonnage et je tournais à 35Hz    
Depuis j'ai tout repris, je ne touche pas à l'écran le temps de la mesure, elle dure 5 secondes. Ensuite j'affiche le résultat.
Je me demande si je ne vais pas également sortir une partie des calculs en virgule flottante, par exemple la conversion en bar. Ca fera toujours quelques cycles d'économisés.
 
Pour le moment je ne peux pas toucher à la fréquence, à l'interieur du boitier j'ai un arduino pro mini. Mais si ca marche je vais surement faire une révision 2 avec l'atmega en direct et une programmation en ISP et je pourrais passer en 20Mhz je pense.

Un peu dans la même situation. J'ai trouvé des tutos complets pour mes projets arduino, mais très peu expliquent le choix des composants (surtout les mecs qui copient) (ça me rassure, mais ça ne me satisfait pas)
On m'a conseillé de lire Principes électroniques de Malvino.

Je cherchaient aussi des vidéos youtube, souvent très pédagogiques, mais j'en suis à plus de 3h maintenant de visionnages et on arrive péniblement à le loi d'ohm

J'ai le niveau qu'on m'a enseigné : t'as un truc tout cuit et tu calcules différentes valeurs, sans réflexion sur les choix.

Apparemment, de ce que j'en ai compris, le NRF24L01 a des pics de conso que l'arduino n'arrive pas à tenir, mais en mettant un condo entre le GND et le VCC du module, ça résout beaucoup de problèmes de transmission. La quasi-totalité des tutos et des montages que j'ai trouvé sur le net en mettent un, le plus souvent de 4.7uF.

M4vrick
il faudrait que tu stockes le RPM courant
tu sais donc environ quand dois arriver ton pic suivant
si tu as pic1 puis pic2 alors tu connais la vitesse de rotation ensuite pareil entre pic2 et pic3 puis pic3 -> pic1
si tu manques un pic alors la vitesse de rotation sera aberrante
tu peux ainsi détecter l'absence de pic
je ne sais pas si je suis assez clair mais en faisant un schéma et en lisant en temps réel la vitesse de rotation tu sauras quand intervient un erreur de pic.

  je fais pareil

j'imagine que tu as vu ca: https://hackaday.io/project/8952-el [...] eadtracker

vu que je pars de 0 experience en arduino et consorts, j'ai commande exactement les pieces qu'il suggere, sur adafruit. le code qu'il file sur le site (les 2, en fait) ne marche pas bien. du coup je bidouille et j'apprends et je regarde comment ca marche. il semble que les librairies plus recentes se chargent de toute la partie mathematique compliquee du code, donc je pense (je me trompe peut-etre) que y'a moyen de reecrire le code de maniere 100x plus simple. aussi, y'a tres surement moyen de realiser le projet avec des pieces venant de aliexpress/banggood voire des vendeurs sur amazon qui livrent en europe sans frais de port enormes (comme sur adafruit)

bref. tiens moi au courant de l'avancement de ton projet, je te tiendrai au courant egalement. j'ai pas enormement de temps mais ce projet est assez haut dans ma liste de trucs a faire quand j'ai du temps

edit: sorry pour le manque d'accents

Hello,
j'ai un souci avec mon code arduino
 
j'ai une carte GPS / SIM 808
et j'essai de récupérer une chaine de caractère pour voir si le gps est bien check  
 
la fonction AT+CGNSINF
renvoi une chaine du style +CGNSINF: 1,1 , x , d , a d,1 2 , 45 etc
 
impossible de catcher le résultat.
 
si qqun à une astuce je suis preneur , mon code  
 

Ca marche pour d'autres commandes? genre un ATI?

 
oui avec d'autre commande j'y arrive bien  
 
ma sortie

 
le setup et la suite  
 

comme on le vois il est passé dans le if startwidth alors que la valeur n'est pas OK on est sur 1,0 donc gps pas encore dispo (init but not fix)

gps_status ne retourne rien. Suis étonné que ça compile.

Idem pour Startgps

 

 
Je vais me pencher dessus, mais je t'avoue que le temps est hélas inextensible pour moi aussi

 
 
Je suis totalement noob en arduino (quelques montages à but pédago) mais j'adore le concept, j'aurais aimé que cela existe il y a 25 ans en arrière, à une époque où j'aurais vraiment pu investir du temps dedans (au lieu de courir après les filles )  
De ce que je vois de mon coin du net à moi, c'est surtout l'énorme communauté et la quantité astronomique de site et de littérature trouvable autour de ce truc. Et ça, quand on débute, ou même en tant qu'amateur éclairé voire semi pro, c'est vraiment précieux.
 
Je me dis aussi qu'un utilisateur lambda passera déjà beaucoup de temps dessus avant d'avoir complètement fait le tour du sujet et se trouver limité par l'arduino, quand on voit la masse de chose faites avec ce genre de cartes (+ les extensions shields, capteurs divers et le bon interfacage avec les rasp ou les PC)
 
du coup, je pense pas que l'arduino s'oppose finalement à d'autres plateforme du même genre, plus pro, plus puissante ou que sais je, et qu'il faille absolument "choisir son camps".
Ce sont des choses qui se complètent et qui dépendent surtout des besoins ou des objectifs de chacun.