Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - simontpellier

Pages: 1 ... 6 7 [8]
106
C’est assez amusant car j’étais justement en train de le tester, comme son grand frère le TRCT5000 qui est à peine plus encombrant, un peu plus cher, 0,79€ mais qui autorise des distances de détection beaucoup plus importantes.

J’ai mis en ligne une vidéo :

Hello Boby (et toute la compagnie bien sûr) ;

J'aimerais parler de vos tests et avoir vos conclusions ; les miennes sont négatives et je voudrais être sûr que c'est "normal".
En effet, si j'ai pu vérifier que la distance de détection est importante, j'ai aussi constaté que la mesure n'est pas reproductible et très différente selon le matériau "vu" par le détecteur.

Dans une application de détection d'une loco ou wagon, d'après mes expérimentations :
- en détection latérale, le résultat pourrait être exploitable, mais je n'ai pas fait assez de tests pour savoir si TOUTES les couleurs/textures des wagons et/ou locos peuvent être détectées sans erreurs et j'en doute ;
- mais en détection sous voie, ça ne fonctionne pas. Ou du moins les possibilités d'exploitations sont très limitées car si la réponse est immédiate et franche dès le surplomb, même par un attelage, elle disparaît dès que le signal émis se réfléchit sur les roues/essieux pour réapparaitre entre. Un convoi arrêté sur un détecteur donnera donc une réponse incertaine malgré toute tempo qu'on aura pu mettre sur le signal.

Ceci est décevant car l'avantage de ce détecteur est d'être directement lu en analogique et/ou digital sans qu'il soit besoin d'utiliser une transmission I2C. A l'inverse du CJMCU3216 qui a une détection imperturbable, mais cette qualité est pourrie par l'instabilité du bus. (Rien ne peut donc être parfait dans ce monde ?)

107
... dans le programme d'essais j'ai moi aussi le TCRT5000 ! Les premiers tests sont intéressants, la taille est un peu pénalisante en N...

Et un autre capteur à 2,50euros que j'attends : détection laser jusque 1m ! (faut-il encore savoir avec quelle cible...) :

On dirait par rapport aux photos que le capteur est le TCRT1000 de WISHAY.
Je penche plutôt pour le capteur SHARP de Jean-Luc car je ne vois pas les "yeux" sur le WISKAY ? De plus le CJMCU3216 voit bien plus loin que 3mm!
J'ai fait moi aussi une petite vidéo, en prenant modèle car je n'aurais pas aimé avoir la honte en faisant moins bien !

https://youtu.be/hdA89_zblMg/

On ne pourrait pas voir plus clairement que la détection est correcte jusqu'à 60mm.

Je comprends bien l'intérêt qu'il y aurait à déporter la tripaille sous le plateau, s'il n'y avait comme le dit Jean-Luc la question de la faisabilité question soudures, mais je ne comprends pas ceci :
De cette manière, il est possible « d’économiser » le port I2C (...)
puis-je avoir une explication ? (merci  d'avance !)

108
Bonsoir,

Quelques nouvelles, et un petit souci car j'ai eu affaire à de fausses détections. J'ai lu que ces détecteurs étaient sensibles aux parasites ; problème à traiter si c'est bien la cause mais je n'ai pas pu le confirmer clairement.

En réalité les capteurs fonctionnent parfaitement. Mais il arrive, aléatoirement, que la valeur lue sur un canal du multiplexeur se trouve recopiée sur un autre. Avec les même effets qu'une fausse détection ! C'est un problème de bus U2C, déjà chargé par ailleurs, je cherche la solution...
 
Bien cordialement
Philippe

109
Composants / CJMCU-3216 : Le détecteur de proximité parfait ?
« le: avril 30, 2020, 10:39:52 pm »
Bonjour tout le monde

Premier post, alors je commence par un grand merci à tous les contributeurs et un énorme merci aux locomotives de ce site. En partant de zéro, arduino et C++, c'était mon cas il y a un an, Locoduino est une bénédiction.
Aujourd'hui j'ai peut-être à mon tour une contribution à apporter.

De lien en lien, je suis tombé un jour sur un détecteur I2C encore jamais évoqué ici semble-il, peut-être pas parce qu'il est généralement vendu comme détecteur de luminosité  : le CJMCU-3216.

Mais c'est aussi un DETECTEUR DE PROXIMITE. Long long délai d'attente (chine + premier envoi perdu...) mais la patience valait la peine, je crois qu'il n'a que des avantages !

- Il est MINUSCULE, au point de se glisser sous la voie entre deux traverse MÊME en échelle N ;
- il détecte parfaitement UN ATTELAGE, CONVOI A L’ARRÊT OU NON ;
- il semble indifférent aux conditions de luminosité (ou pas) ambiante ;
- et il coûte presque rien.
Seul petit inconvénient (peut-être), il fonctionne au maximum sous 3,5V.

Voici la merveille. Qui va remplacer les barrières infra-rouge encombrantes, inesthétiques et parfois gaffeuses (petites gaffes mais gros bazar).


(Ça n'est encore qu'un circuit d'expérimentations. Faute de ballast, la planche est décaissée de 2mm pour loger le composant)

Ce détecteur est paramétrable.
A minima il faut le déclarer comme "détecteur de proximité en continu" (paramètre PS). Et ça suffit pour qu'il marche très bien. Je n'ai pas assez testé l'intérêt des autres paramètres sauf celui de la SENSIBILITÉ qui, en la réglant sur 4 plutôt que 2 (réglage par défaut), m'a permis la détection à tout coup des attelages (attention,  Je parle pour le N... doute pour le HO).

Exemple pour "n" détecteurs. Le " tcaselect(i)" se rapporte à l'indispensable multiplexeur vu que le composant n'est pas adressable, ce qui est normal vu sa taille. Puis il faut un proxSensor.init(); par détecteur et donc le déclarer "PS" ; le reste est facultatif.

for (byte i(0); i<n; i++)
    { tcaselect(i) ;
      proxSensor.init();
      proxSensor.setMode(PS);                       // PS: proximity sensor continous
      proxSensor.setPSGain(4);                      // Choose between 4 gain values: 1, 2(default), 4, 8 : higher gain increases sensitivity as well as noise - 2 is good.
      proxSensor.setNumberOfLEDPulses(2);           // Choose between 1(default),2,3,4 pulses of LED IR for proximity : more pulses increase (slightly) the max. distance
      proxSensor.setPSMeanTime(PS_MEAN_TIME_50);    // Meantime (milliseconds) for proximity measurement : _50, _37_5, _25 or _12_5 ; longer meantime provides less spreaded values
      proxSensor.setPSIntegrationTime(8);           // This function helps to increase the max distance. Choose value between 1 and 16.
    }

Bien sûr , on peut préférer un paramétrage individuel, en fonction d'exigences de détection différenciées.

En sortant un peu du sujet mais pas complètement et pour ceux qui auraient des problèmes de lenteur en I2C : je signale qu'avant de réussir à faire fonctionner ce senseur sur mon bus I2C déjà sollicité (transmission de données d'un MEGA vers un NANO + affichage sur OLED) j'ai eu de  gros soucis liés à la library ADAFRUIT des écrans SSD1306. Il y a des références sur le net à des problèmes de lenteur ces afficheurs ; c'est ce que j'ai connu dès le deuxième écran, le MEGA qui faisait "tout" tourner, pourtant pas grand chose, a paru d'un coup très fatigué. D'où le NANO, dédié à l'affichage... faute de bien avoir bien analysé le problème. En tous cas pb réglé... jusqu'à ce que j'ajoute un CJMCU3216 sur le bus (sur un autre multiplexeur TCA9548A avec bien sûr son adresse propre).
Impossible de faire cohabiter le tout. Des conflits sur le bus créaient un proportion importante (+- 20%) de données aberrantes, tant sur les écrans que que les CJMCU.
Avec de plus le problème toujours présent d'un rafraichissement extrêmement lent des afficheurs : 180ms par OLED, soit 360ms pour deux, à l'extrême limite de l'acceptable.
Jusqu'à trouver cette autre library ; SSD1306AsciiWire : (https://github.com/greiman/SSD1306Ascii
- de 360ms m'a loop est passée à 70... puis 40 avec un peu d'optimisation ;
- plus aucun conflit ;
- en prime, disparition de menus problèmes dont des artefacts sur les écrans.

Pour tester de détecteur, voici par exemple où je l'ai commandé : https://fr.aliexpress.com/item/32817340841.html?spm=a2g0s.9042311.0.0.2df16c37QV8oNx

Pour ma part, l'essayer fut l'adopter.

110
Vos projets / Re : Un Arduino par canton
« le: avril 18, 2020, 03:32:14 pm »
Bonjour Jean-Luc,

Désolé de vous solliciter : j'ai commencé à prendre en main le croquis "AlimentationTraction" (très formateur !) que je vais expérimenter par tranches mais je voulais vous signaler une difficulté.

Pour commencer j'ai trouvé votre librairie : https://framagit.org/locoduino.org/CommandInterpreter
mais qui étrangement provoque cette erreur :
"class CommandInterpreter' has no member named 'readUnsignedLong'; did you mean 'readUnsignedInt'?" ;

Par similitude avec l'existant, j'ai donc tenté d'ajouter dans le CommandInterpreter.h cette ligne :
bool readUnsignedLong(unsigned long& result);et dans le .cpp la fonction bool CommandInterpreter::readUnsignedLong(unsigned long& result)
{
  char **endChar;
  char *arg = mBuffer.getArg();
  if (! isANumber(arg)) return false;
  long longResult = strtol(arg, endChar, 0);
  if (**endChar != '\0' || longResult < 0 || longResult > 65535) return false;
  else {
    result = (unsigned long)longResult;
    return true;
  }
}

Ceci m'a permis de compiler (mais pas d'affirmer que le code ainsi bricolé fonctionne...)
J'espère ne pas être hors du sujet de ce fil, dans ce cas j'effacerai ce message, mais que mon retour d'expérience puisse servir.

Bien cordialement
Philippe








111
Vos projets / Re : Re : Un Arduino par canton
« le: avril 16, 2020, 02:59:37 pm »
Bonjour Jean-Luc,

Merci pour la réponse et le lien ! (chic du travail qui rentre... )

Pour ce qui est de la carte :

Je ne peux pas t'envoyer une carte en ce moment, ma poste est fermée.

... je lis que ça sera donc possible "après" ? Un grand merci d'avance, voilà certainement beaucoup de temps et de composants épargnés !! Je n'aurai "plus qu'à" trouver comme résoudre mon cas particulier évoqué en MP : ayant choisi de ne pas polariser les cantons au moyen de relais inverseurs mais via des ponts H, il me faudra mesurer une FCEM polarisée !

Bien cordialement
Philippe


112
Vos projets / Re : Un Arduino par canton
« le: avril 06, 2020, 11:40:47 am »
Bonjour Jean-Luc,
Ce fil est passionnant et contient énormément d'éléments. Mais la complexité du sujet fait quand même peur et il faudra certainement y aller doucement et "réinventer" en partie, refaire le chemin.
Objectif 1 : un premier montage qui me permette d-obtenir un signal tension représentatif de la FCEM.
Et pour cela, lui fournir les bonnes mesures comme expliqué : la moyenne de quatre sur 6, les extrêmes étant éliminées.
Pour éviter de tâtonner sur ce point là... trouver la durée de l'interruption de PWM, l'intervalle de temps entre chacune des 6 mesures etc (puisque dans le fil la seule donnée disponible est la fréquence de l'échantillonnage tous les 10us) serait-il possible d'avoir... carrément !... le bout de code qui permet d'obtenir ces valeurs ?
En vous remerciant par avance ?
Bien cordialement
Philippe

113
Présentez vous ! / Présentation perso et présentation "projet"
« le: septembre 16, 2019, 09:37:24 pm »
....................
sans intérêt


114
Débuter / PMW et timers ... pour débutant
« le: mai 31, 2019, 09:42:45 pm »
Bonsoir,

Ce site est décidément une mine ! Les perspectives que j'y ai entrevues sont... exaltantes ! Merci d'avance à tous les auteurs. Et à ceux des fils et articles que j'ai déjà exploités.

Pour l'instant, mon préalable à tout projet est de disposer d'une alimentation fiable et agréable.
Et j'y suis... presque. Par la grâce de la PWM.
Ayant compris pourquoi nos motrices n'aiment pas trop le 490Hz standard des cartes Arduino, j'ai plongé dans la littérature sur les timer. Assez pour comprendre les tenants et aboutissants... mais sans aller jusqu'à ouvrir le datasheet du processeur (comme parfois recommandé) !

Je suis sur un Arduino Mega. Pour obtenir une PWM à 4Mz ou 31 Kz, j'ai donc intégré à mon code l'une OU l'autre des deux commandes suivantes, opérant sur le timer 3 :   
TCCR3B = TCCR3B & B11111000 | B00000010;
TCCR3B = TCCR3B & B11111000 | B00000001;   

et j'aimerais une explication de ce que je constate, sur une motrice Jouef HO (+/- 1990)

- par rapport à la PWM 490 hz, pas de différence d'un point de vue sonore. (mais j'entends mal les aigus)
- pas de différence non plus en ce qui concerne la capacité à tenir un ralenti très lent.
- mais la grosse différence par rapport au 490 (que ce soit en 4 Mz ou 31kHz) est que la motrice "décolle" beaucoup plus tard : avec un rapport cyclique autour de 30% dans le premier cas, plus ou moins le double pour les hautes fréquences de PWM.

J'imagine que cela tient aux fronts de montée/extinction du signal ? Mais au delà de l'explication théorique j'aimerais savoir si c'est "normal" et surtout, s'il y a une solution car dans l'état, la plage d'utilisation des 256 valeurs de PWM devient fort réduite et la conduite moins agréable.

J'espère ne pas avoir ouvert un sujet intempestivement mais une recherche consciencieuse ne m'a pas permis de trouver une discussion traitant de cette question.
Merci par avance de vos commentaires !

Philippe


115
Composants / Re : Le booster L298 ne booste pas
« le: mai 31, 2019, 04:33:12 pm »
Bonjour,

Je réveille ce "vieux fil" (qui m'a néanmoins été bien utile) pour faire une sorte de tutosynthèse de mes soucis/expérimentations/conclusions avec un L298(H).
Car y trouve finalement peu de choses à son sujet sur le net, en français en tous cas, et ce qu'on y lit peut être contradictoire.

Alors voici. Et pardon pour les évidences à ceux qui savent déjà.

Donc c'est un booster. Et facultativement, un hacheur;
Une carte type Arduino n'étant pas taillée pour fournir un courant puissance, c'est un shield du type L298 qui s'en charge, selon des instructions PWM... ou binaires ! fournies par Arduino ou consort.
Mais pour pouvoir fournir son client final, moteur ou autre, il doit lui-même être d'abord alimenté par une source suffisamment costaude, entre 5 et 35V CC.
Ce qui n'est pas encore pas suffisant car pour pouvoir traiter les instructions reçues à ses bornes en(able) et in(put), il a AUSSI besoin d'une source 5V.

Ce 5V qui m'a créé quelques problèmes, les mêmes apparemment que ceux de "francisch".

Car il y a une borne "5V" sur la carte L298H, à droite (vue de face !) de la borne GND.
Mais est-ce une entrée ou une sortie ?? Ehhhh bien les deux ! ... suivant le site que l'on consulte !
Et en fait ça peut également être l'un ou l'autre. Mais pas l'un ET l'autre... bien sûr.

Par défaut, cad dans l'état initial, celui dans lequel on reçoit la carte direct de Chine... sans le moindre mode d'emploi, cette borne 5V est une sortie qui PEUT alimenter par exemple une carte Arduino.
Et ceci parce que le discret cavalier situé juste derrière les bornes du + et - de la source puissance est en place et que dans cette configuration le shied produit lui-même son 5V à partir de la source puissance.
MAIS A CONDITION QUE CETTE DERNIERE NE SOIT PAS (trop... cf commentaire de MSPORT) SUPERIEURE A 12V !
Auquel cas il faut déponter ce "jumper". Mais les fonctions logiques du shied ne sont alors plus alimentée et il FAUT donc dans ce ce cas lui fournir un 5V externe, via Arduino par exemple. La borne 5V est donc dans ce cas une entrée.

Dans la pratique...
Il peut y avoir le détail... qui a failli me tuer ! Car jumper en place, cad shied s'autoalimentant en 5V, je constatais une chute de tension systématique aux bornes "OUT" de la carte de l'ordre de 5V (un hasard ??) à vide, s'aggravant dramatiquement en charge.
Et ceci que ce soit avec un petit moteur 6V, avec une ampoule ou une loco 12V.

Au final...
voici, joint, le schéma de ce qui ne marchait pas, et ceux de ce qui marche. (les bornes Arduino de la PWM sont bien sûr indicatives)
Avec un seul tout petit fil qui fait toute le différence. Il fait bien l'objet de quelques allusions sur le net mais c'est en réalité une condition première au fonctionnement de cette carte.
Laquelle permet alors de disposer pour 3 sous (hors transfo) d'une alimentation idéale !

A + !!

Pages: 1 ... 6 7 [8]