LOCODUINO

Parlons Arduino => Composants => Discussion démarrée par: simontpellier le avril 30, 2020, 10:39:52 pm

Titre: CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: simontpellier 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).

(https://i44.servimg.com/u/f44/11/73/62/86/20200410.jpg)
(Ç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 (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 (https://fr.aliexpress.com/item/32817340841.html?spm=a2g0s.9042311.0.0.2df16c37QV8oNx)

Pour ma part, l'essayer fut l'adopter.
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: Pyk35 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 !

Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: msport 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.
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: Dominique 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
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: Pyk35 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!
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: simontpellier 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
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: bobyAndCo 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 : https://www.youtube.com/watch?v=kLCSsNo7pS8

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

Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: Pyk35 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 ?
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: bobyAndCo 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/





Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: Pyk35 le mai 04, 2020, 09:57:35 pm
Compris! Merci!!
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: simontpellier 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...) : https://www.youtube.com/watch?v=gGtD93wb7xI

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 !)
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: bobyAndCo 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 (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.
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: Jean-Luc 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.
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: simontpellier 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 : https://www.youtube.com/watch?v=kLCSsNo7pS8

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 ?)
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: bobyAndCo 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...
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: simontpellier le juillet 09, 2020, 03:20:55 pm
Bonjour,
Je reviens sur ce sujet pour le compléter d'un retour d'expérience plus approfondi. (et en profiter pour glisser une question... bête de bête j'en ai peur)

D'abord le REX sur les CJMCU-3216. En condensé : totalement positif... mais.
Totalement positif car du point de vue du capteur la fiabilité/reproductibilité est sans faille. Réellement.
Les problèmes, car il faut le dire il y en a, proviennent du bus I2C. Parasitages et amplification des problèmes (je crois... je n'affirme pas) du fait de l'usage de multiplexeurs I2C "TCA9548", indispensables de mon point de vue pour profiter réellement de l'intérêt de ces capteurs CJMCU-3216, c'est à dire en en faisant un large usage.

Ces problèmes ont-ils une solution ?
Ne pouvant parler que de mon expérience, il ne m'est pas possible de donner une réponse absolue car elle sera probablement propre à chaque configuration du réseau.
Je peux néanmoins dire qu'il est possible de parvenir à un fonctionnement parfait moyennant un bon filtrage. Dans son principe, celui qui fonctionne pour moi devrait pouvoir s'adapter avec profit.
Avant de le détailler, je dois probablement préciser que j'ai choisi une logique de gestion par canton, en analogique donc. Un détecteur situé à chaque frontière de canton commande :
- l'application du courant traction spécifique au convoi concerné sur le canton C+1 dès détection d'un convoi, qu'il soit poussé ou tiré ;
- l'extinction du courant traction sur le canton (devenu) n-1 dès que la totalité du convoi à franchi le détecteur (extinction légèrement temporisée).
Par ailleurs, et fort d'une expérimentation concluante, je pense tripler le nombre de détecteurs de façon à avoir en amont de chaque détecteur frontière un autre détecteur, pour ralenti final et arrêt au signal.

C'est l'ensemble de ces détecteurs, ou plutôt je le redis, des transmissions de données, qui demande à être filtré. D'abord par l'installation de condensateurs sur chaque alimentation canton, par précaution mais avec un effet pas vraiment vérifié.
Et essentiellement par un indispensable filtrage logiciel, en trois points.

Suivant l'occupation des cantons par les convois, une fonction en boucle scanne chaque canton (toutes les 25ms dans mon cas) à la recherche d'une éventuelle détection : un train T sur un canton C entraînera la surveillance du détecteur frontière entre le canton C et le canton C+1 pour CE train.

Une première détection (par seuil "haut" réglé chez moi à 200) étant censée mettre un canton donné sous tension (et l'affecter à un convoi précis), cette détection est-elle réelle ?
- dans tous les cas, une fonction de "switch" vers le canton suivant est appelée ;
- une variable booléenne "switched" enregistre ce fait.
- faute de pouvoir décider de la réalité de la détection, la fonction de switch rejette la détection mais enregistre dans une variable booléenne "IRDtoFilter[train]" le fait que le détecteur D a, pour le train N, été vu "détectant" et le met sous surveillance.

A la loop suivante, de deux choses l'une : soit le train est en pleine voie. Il n'y a donc pas de seconde (fausse) détection (cas heureusement jamais rencontré) et il faut donc le concrétiser en annulant la surveillance du détecteur fautif :

=> par exemple en tête de la fonction en loop :
    switched[train] = false ;
et à la fin de la fonction en loop :
for (byte i(0) ; i < TRAINS; ++i)
     { if (switched[i] == false)          // pas de switch pour le train i dans la boucle => une éventuelle fausse détection doit être effacée
        { if (IRDtoFilter[train] == frontIRD[train] )    // frontIRD : numéro du détecteur de sortie du canton, compte tenu des positions d'aiguille et du sens de circulation
            { firstDetection[i][IRDtoFilter[i]] = true ;   // la prochaine détection sera à nouveau vue comme étant la première
              IRDtoFilter[i] = 222 ;                             // aucun détecteur 222 ! signifie qu'il n'y a aucun détecteur à surveiller...
            }
        }
     }

- soit le train est SUR un détecteur et, dans ce cas deux loop, consécutives passeront toutes deux par la fonction de switch qui est alors chargée de faire le ménage :
void switch_to_section(byte train, byte currentSection, byte newSection, byte wichIsCutIRD)
  { // filtrage des fausses détections : second test : si 1er passage, mise sous surveillance du détecteur responsable et sortie de la fonction / premier test : si en seconde lecture ce détecteur est < seuil, il a été filtré et redevient vierge pour action à la seconde détection.
    switched[train] = true ;
    if (wichIsCutIRD != IRDtoFilter[train] && proxSensor.getProximity() < proxThreshold)
      { firstDetection[train][IRDtoFilter[train]] = true ;
        IRDtoFilter[train] = wichIsCutIRD ;
      }     
    if (firstDetection[train][wichIsCutIRD] == true)
      { IRDtoFilter[train] = wichIsCutIRD ;
        firstDetection[train][wichIsCutIRD] = false ;
        firstDetection[train][IRDtoFilter[train]] = false ;
        return ;
      }

       // suit la fonction de switch en elle-même
      }

- troisième patch de filtrage :
il arrive aussi qu'un canal I2C, aléatoire, se bloque sur une valeur... également aléatoire.
Pour pallier ce problème, chaque "loop" reset un des détecteurs, à tour de rôle :
    reset = (reset +1)%NbDeDetecteurs ;
    tcaselect(reset) ;
    proxSensor.init() ;
    proxSensor.setMode(PS);

A noter que le seul paramétrage "proxSensor.setMode(PS)" m'a finalement paru nécessaire et utile.

A l'usage donc, une fois ce filtrage OK :
- toute vraie seconde détection au dessus d'un seuil "HAUT" applique le courant traction du train N au canton C+1 et initialise une temporisation liée à ce détecteur ;
- ensuite, toute détection au dessus d'un seuil "BAS" (20 dans mon cas), réinitialise une temporisation qui signale ce détecteur comme "actif" ,
- à l'extinction de cette temporisation, cad le convoi passé, le courant traction est coupé sur le canton "arrière" qui est libéré pour un autre convoi.
De cette façon, et même convoi à l'arrêt avec un attelage en surplomb du détecteur, LE CONVOI RESTE VU ET AFFECTE AUX DEUX CANTONS encadrants. Ceci a comme avantages :
- de pouvoir repartir dans les deux sens, que la motrice ait été en poussé ou en tiré
- de conserver en permanence un feu de fin de convoi (convoi roulant s'entend ! on parle ici d'analogique).

(Accessoirement et avec un code un peu boosté, cette logique marche également pour un convoi trop long pour un canton et qui occupe donc simultanément trois cantons)

Maintenant la question.
Ce site m'a apporté et m'apporte beaucoup. Un apport absolument essentiel. J'ai lu, je lis beaucoup... mais je ne comprends pas tout !
Notamment sur cette question car elle est en rapport :
J'ai lu beaucoup de choses sur la rétrosignalisation. Je me demande... ces détecteurs 3216, ou d'autres car ils ne font en fait rien d'autre (mais avec quelques fameux avantages) que ce que font des barrières infra-rouge, n'est ce pas de la rétrosignalisation ? pour bien moins cher, bien moins compliqué que des détecteurs de consommation dont l'exploitation me semble finalement plus limitée ? C'est ça qui m'intrigue. Mais de que j'ai lu à propos des détecteurs de consommation, je m'en suis fait l'idée (éronnée ??) qu'ils étaient associés aux réseaux exploités en digital. Bien que je ne vois pas pourquoi. Il y a en tous cas une donnée qui m'échappe gravement et avant de me lancer dans un réseau digne de ce nom j'aimerais tirer ça au clair. Si quelqu'un peut m'y aider...
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: msport le juillet 09, 2020, 06:44:17 pm
Bonjour,
à mon avis, c'est un débat philosophique entre la détection ponctuelle et la détection sur toute une zone. A choisir en fonction ce qu'on considère comme nécessaire : détecter le passage ou détecter la présence ... en prenant en compte les contraintes de mise en œuvre des deux solutions.
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: Dominique le juillet 10, 2020, 12:24:42 am
Comme l’a expliqué Jean-Luc, il y a une grosse différence entre une détection de consommation qui est un état qui dure tout le temps de passage d’un train et une détection ponctuelle comme un ILS ou un effet Hall qui se produit brièvement et représente généralement une transition ou un changement d’état.

Je ne sais pas trop où il faut classer ce capteur CJMCU-3216 qui est ponctuel à priori mais qui peut rester actif pendant le passage de tout un train.

En tout cas la détection d’un état doit être répétée donc confirmée périodiquement, donc jamais ignorée, alors qu’une détection ponctuelle ne peut donner lieu qu’à un message unique avec le risque d’être perdu en cas de problème de transmission.

Comment utilises tu ce détecteur ?

Autre question : l’interface avec Arduino est-elle uniquement en I2C ou existe-t-il une version en PCI ?
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: simontpellier le août 11, 2020, 07:16:16 pm
Bonjour,

Je viens compléter et clôturer (pour ma part du moins) ce fil avec le rapport de mes dernières expériences concernant ce capteur CJMCU-3216.

Et ça n'est que du bon, avec un fonctionnement absolument impeccable.
Ceci en combinant bus I2C et bus CAN.

Ici une parenthèse pour commencer par remercier Jean-Luc sans qui etc... mais c'est "trop" vrai : sans ses articles, les chances de découvrir le CAN et surtout que je parvienne à le mettre en œuvre étaient quasi nulles !

Un "bus" I2C donc, ou plutôt un nœud, pour regrouper les détecteurs sur un multiplexeur TCA9548A (puisque l'adresse des détecteurs n'est pas configurable), en interface avec un nano "satellite", et autant de satellites que de besoin dans une logique de proximité nano-détecteurs. Chaque nano lui-même connecté pas bus CAN pour remonter ses données au "maître".
(une autre solution pour éviter le multiplexage, et à condition que le code ne demande pas une lecture en continu, pourrait être de créer une instance "AP3216" par détecteur et de les utiliser chacun en interruption...? je n'ai pas testé).

En résumé, voici les avantages de ces modules :
- la discrétion : pas plus large qu'une voie N, ils se glissent dessous, le détecteur en lui-même se loge entre deux traverses, au final ils sont quasiment invisibles (peuvent probablement l'être avec un ballastage)
- ceci, allié à leur coût modique, permet d'en mettre "à volonté" : un à chaque frontière de section/canton pour la gestion du trafic + (par exemple) deux autres, de part et d'autres, pour un arrêt précis au signal après approche préalable en marche lente. Ceci sans créer "une forêt" comme ç'aurait été le cas avec des barrières IR classiques.
- autre énorme avantage sur les barrières : la détection est suffisamment fine pour qu'un convoi à l'arrêt reste détecté même lorsque c'est un attelage qui est en surplomb du détecteur. Le risque de "trou" est donc éliminé.
- l'utilisation d'un bus CAN est certes une contrainte, mais remboursée par les communications double-sens qu'il permet par ailleurs et, surtout, elle élimine les aléas des transmissions I2C. Le comportement global est exempt de toute fausse détection au point que tout filtrage logiciel est devenu inutile.

Je pense donc pouvoir répondre définitivement par l'affirmative à la question "CJMCU-3216 : Le détecteur de proximité parfait ?"

Ce qui me semble une excellente nouvelle dans le domaine de la détection!






Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: Dominique le août 11, 2020, 08:55:32 pm
Merci pour ce compte-rendu détaillé et utile au point que je vais commander ces bestioles  ;D

En effet il est écrit dans ses applications « With multiple proximity gain control, multiple IR LED current control and 10-bit ADC output, this device is designed specially to fix low reflection objects, such as black hair. »

Donc bon pour détecter un dessous de loco ou de wagon, généralement noir.
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: Dominique le août 12, 2020, 11:24:48 am
Cependant il est incompréhensible que la logique interne, offrant de nombreuses options de configuration, ne permette pas de différencier plusieurs capteurs sur un même bus I2C avec des adresses différentes !

 https://www.roboremo.com/projects/arduino/reading-ap3216-with-arduino/ap3216c-lite-on.pdf (https://www.roboremo.com/projects/arduino/reading-ap3216-with-arduino/ap3216c-lite-on.pdf)

Avec un tel titre de ce fil, qui le positionne en bonne place sur les recherches internet, nous devrions tenter de trouver une réponse à cette question.

Dans ce document l’adresse I2C est différente : 0x39 au lieu de 0x1E car il s’agit d’un composant similaire : le NOA1305 dont je ne trouve pas de vendeur sur les réseaux habituels.

 https://www.onsemi.cn/PowerSolutions/document/NOA1305-D.PDF (https://www.onsemi.cn/PowerSolutions/document/NOA1305-D.PDF)

Bienvenue aux contributions !
Titre: Re : CJMCU-3216 : Le détecteur de proximité parfait ?
Posté par: simontpellier le août 13, 2020, 04:04:13 pm
Attention Dominique,
ce NOA1305 fait uniquement détecteur d'ambiance et pas détecteur de proximité ; ça n'est pas le même capteur.