Auteur Sujet: CJMCU-3216 : Le détecteur de proximité parfait ?  (Lu 33621 fois)

simontpellier

  • Full Member
  • ***
  • Messages: 115
    • Voir le profil
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.
« Modifié: mai 02, 2020, 09:23:36 pm par simontpellier »

Pyk35

  • Full Member
  • ***
  • Messages: 110
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #1 le: avril 30, 2020, 11:10:20 pm »
Intéressant, merci pour le partage.

Pour les artefacts sur tes écrans, avais-tu mis des résistances de pullup sur les 2 fils de l'I2C ?
Ayant pas mal pratiqué le SSD1306 avec la librairie Adafruit, j'ai constaté que sans les pullup, l'affichage devenait instable ce qui ne se reproduisait plus avec.
Mais je n'ai pas essayé avec 2 écrans + 2 autres équipements I2C ce qui commence à faire beaucoup !

A+
Cédric

msport

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2217
  • HO avec DCC++ en DIY Réseaux très éphémères
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #2 le: avril 30, 2020, 11:13:55 pm »
Merci pour cette (première mais excellente) contribution.

Pour les SSD1306, la gourmandise de la bibliothèque Adafruit vient d'être évoquée récemment par rapport à celle de Greiman, mais revers de la médaille, cette bibliothèque n'affiche que des caractères. Que l'on peut néanmoins enrichir par des caractères graphiques de son cru. Dans ces conditions, on peut certainement la préférer.

Pour le module CJMCU-3216, qui comporte un détecteur de proximité utilisé dans les téléphones portables, ce composant aux caractéristiques très intéressantes a été déjà signalé dans le forum mais n'a pas retenu l'attention qu'il mérite. Je l'ai testé et effectivement son insensibilité à la lumière parasite est exceptionnelle. (à contrario des détecteurs à infra rouge basiques). Peut-être que les déboires rencontrés avec le bus I2C ont découragé ceux qui l'ont utilisé en environnement réel.
Cordialement

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 3038
  • 100% Arduino et N
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #3 le: mai 01, 2020, 11:11:11 pm »
Bonjour et un grand merci pour cette contribution.

Je vois ici une solution élégante pour les détecteurs ponctuels des zones d'arrêt dans la gare cachée.

Je vais essayer.

Bien amicalement
Dominique
Cordialement,
Dominique

Pyk35

  • Full Member
  • ***
  • Messages: 110
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #4 le: mai 01, 2020, 11:26:42 pm »

Je vois ici une solution élégante pour les détecteurs ponctuels des zones d'arrêt dans la gare cachée.


J’imagine aussi de beaux arrêts au heurtoir dans des va-et-vient!
A+
Cédric

simontpellier

  • Full Member
  • ***
  • Messages: 115
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #5 le: mai 02, 2020, 09:51:21 pm »
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
« Modifié: mai 05, 2020, 05:51:55 pm par simontpellier »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • HO avec DCC++
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #6 le: mai 03, 2020, 10:30:50 pm »
On dirait par rapport aux photos que le capteur est le TCRT1000 de WISHAY. J’ai deux petites remarques :

1° - Il vaut mieux l’acheter non monté sur son PCB, ce sera plus discret. Et mettre les composants complémentaires sous le plateau (sur un PCB maison pourquoi pas) d’autant qu’il s’agit de deux résistances, 1 de 10 KΩ (PULLUP) et une de 150Ω. Et il coute surtout beaucoup moins cher, 0,42€ chez TME : https://www.tme.eu/fr/details/tcrt1000/capteurs-photoelectriques-pour-pcb/vishay/

De cette manière, il est possible « d’économiser » le port I2C et donc pourquoi pas d’en monter plusieurs sur la même carte.

2° - Le TCRT1000 ne donne vraiment des réponses fiables que si la distance avec la cible est de 2 à 3 mm, ce qui est tout de même assez faible, même en N.

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 :

Je n’ai pas mis la vidéo du TRCT1000 car ce n’était pas convainquant.

Sinon, on peut aussi voir le capteur SHARP dont Jean-Luc parle ici : https://forum.locoduino.org/index.php?topic=978.msg10259#msg10259


Pyk35

  • Full Member
  • ***
  • Messages: 110
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #7 le: mai 04, 2020, 06:27:19 pm »
Christophe, comme d'habitude, bravo pour cette vidéo très didactique.

je m'interroge sur un point.
Là ton obstacle était bien perpendiculaire à l'émetteur. Penses tu que le résultat serait aussi fiable si tu l'inclines à 45° par exemple ?
A+
Cédric

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • HO avec DCC++
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #8 le: mai 04, 2020, 07:00:41 pm »
Bonsoir Cédric,

Je vais malheureusement te faire une réponse de normand ! En fait, comme il s’agit d’un capteur de luminosité, toute choses égales par ailleurs, la mesure peut déjà varier selon la luminosité.

Si c’est pour faire des capteurs tout ou rien comme il est question dans ce fil, il est assez simple de dire > à xxx ou < à yyy en gardant une marge de tolérance confortable.

Ca reste des capteurs à 2 balles ou moins, faut sans doute pas leur demander trop.

Par contre, si tu veux faire de la mesure de distance, les capteurs réfléchissants Sharp dans la série GP2Y0xxxxx sont assez impressionnants : https://fr.rs-online.com/web/c/afficheurs-et-optoelectronique/optocoupleurs-photodetecteurs-capteurs-optiques/capteurs-optiques-reflechissants/?searchTerm=sharp

Moi je craque particulièrement pour celui-ci (technologie IR) :

https://fr.rs-online.com/web/p/capteurs-optiques-reflechissants/6666580/

que je voudrais installer sur mon pont tournant et qui est aussi vendu en circuit tout monté par Pololu  : https://www.pololu.com/product/2579

Et je ne résiste pas de vous parler de ce capteur IR (CMS) avec I2C qui travaille sur 200mm et mesure 5cm X 2,5 et 0,83 d’épaisseur à 2,50€. Acheté mais pas encore testé.

https://fr.rs-online.com/web/p/capteurs-proximites/1226792/





« Modifié: mai 04, 2020, 09:29:45 pm par bobyAndCo »

Pyk35

  • Full Member
  • ***
  • Messages: 110
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #9 le: mai 04, 2020, 09:57:35 pm »
Compris! Merci!!
A+
Cédric

simontpellier

  • Full Member
  • ***
  • Messages: 115
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #10 le: mai 04, 2020, 11:18:26 pm »
... 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 !)
« Modifié: mai 04, 2020, 11:19:58 pm par simontpellier »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • HO avec DCC++
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #11 le: mai 05, 2020, 12:56:37 am »

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!
On ne pourrait pas voir plus clairement que la détection est correcte jusqu'à 60mm.

Le TRCT1000 n'a pas les "yeux" mais effectivement les performances que tu montres sont bien supérieures au TRCT1000

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,

Les soudures sont plus délicates mais loin d'être très difficiles si tu as un bon fer à panne fine. Par exemple, je vais tester ce composant qui est en CMS mais je pense que je ne vais pas avoir de difficultés à souder des fils sur les quatre pâtes, fils qui vont traverser le plateau et se raccorder en dessous. Deux de pattes sont par ailleurs des GND :

https://docs.rs-online.com/e968/0900766b816af51d.pdf

Pour le coup, discetion assurée, 6,8mm X 3 et 3,2 d'épaisseur.

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 !)

Le composant seul ne dispose pas de l'I2C intégré, du moins je ne pense pas. L'I2C est ajouté avec les autres composants sur le PCB.

Si tu trouves le composant seul, tu peux donc relier sa sortie directement à une des pins de l'Arduino (via resistances il s'entend). Et de ce fait 2, 3 et peut-être même plus de capteurs en déjouant les problèmes d'adresses I2C qui se posent souvent.

Ces échanges d'expérience sont intéressants car les capteurs ont des éléments importants pour le fonctionnement optimal des réseaux.
« Modifié: mai 05, 2020, 01:02:37 am par bobyAndCo »

Jean-Luc

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1714
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #12 le: mai 05, 2020, 09:14:22 am »
Le TRCT1000 ne dispose pas non plus d’émetteur IR, c’est juste un récepteur

Et si j’en juge par ce que je vois sur le PCB, ce sont des résistances et des capas. Rien qui permette d’ajouter de l’I2C

Ce n’est pas un TRCT1000 sur la carte.

C’est un composant à 8 broches. Ce n’est pas un VL53L0X qui a 10 broches ni un VLVL6180 qui en a 12.

Edit : mauvaise pioche

C'est un AP3216 : https://datasheetspdf.com/pdf-file/1016217/LITE-ON/AP3216C/1

C'est fait pour détecter qu'on met le portable à l'oreille afin d'éteindre l'écran.
« Modifié: mai 05, 2020, 05:31:04 pm par Jean-Luc »
Cordialement

simontpellier

  • Full Member
  • ***
  • Messages: 115
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #13 le: mai 15, 2020, 02:32:44 pm »
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 ?)
« Modifié: mai 15, 2020, 03:07:53 pm par simontpellier »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1081
  • HO avec DCC++
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #14 le: mai 15, 2020, 05:20:08 pm »
Oui ces capteurs réagissent différemment selon la couleur du matériaux sur lequel ils se réfléchissent. Cela réfléchit très bien sur le blanc et pas du tout ou presque sur le noir et les couleurs sombres en général.

C'est d'ailleurs pour cela qu'il sont beaucoup utilisés pour les robots suiveurs de lignes.

Dans ma vidéo c'est bien pour cela que la cible est blanche.

Pour ce qui est des wagons ou des locomotives, il peut être envisagé est de coller une étiquette blanche sous le véhicule.

Quant à chercher à mesurer des distances, je ne m'y risquerais pas, mais en capteur tout ou rien...