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

simontpellier

  • Full Member
  • ***
  • Messages: 114
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #15 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...
« Modifié: juillet 09, 2020, 03:30:53 pm par simontpellier »

msport

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1937
  • 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 #16 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.
Cordialement

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2655
  • 100% Arduino et N
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #17 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 ?
« Modifié: juillet 10, 2020, 09:18:20 am par Dominique »
Cordialement,
Dominique

simontpellier

  • Full Member
  • ***
  • Messages: 114
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #18 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!







Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2655
  • 100% Arduino et N
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #19 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.
« Modifié: août 12, 2020, 03:10:41 pm par Dominique »
Cordialement,
Dominique

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2655
  • 100% Arduino et N
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #20 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

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

Bienvenue aux contributions !
« Modifié: août 12, 2020, 03:12:35 pm par Dominique »
Cordialement,
Dominique

simontpellier

  • Full Member
  • ***
  • Messages: 114
    • Voir le profil
Re : CJMCU-3216 : Le détecteur de proximité parfait ?
« Réponse #21 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.