Capteur de proximité VL6180X

[Tony04]

voila Jean-Luc, c'est testé avec 2 capteurs sur le même port I2C et.... ça fonctionne super bien. Je n'ai pas compris pourquoi l'initialisation des capteurs ne se fait pas avec les lignes qui sont commentées, mais cette initialisation se passe bien dans les dernières lignes du setup, mystère.

Bonjour,

je suis malheureusement obligé de revenir sur ma réponse (en citation) car après de nouveaux essais je n'arrive plus à faire fonctionner les 2 capteurs séparément.
Peut-être n'avais-je pas fait attention que c'est toujours la ligne 61 (le sensor 1) qui donne le résultat, quel que soit le capteur utilisé, ce qui veut dire que c'est toujours l'adresse par défaut qui est lue (0x29).

J'ai commandé quelques capteurs VL53L0X selon la vidéo de Denis (merci à toi) car pour ces capteurs il y a des exemples d'utilisation avec plusieurs adresses I2C. Le résultat quand les capteurs seront arrivés.

Bon dimanche à tous.
Cordialement
Antoine

[DDEFF]

Bonjour Antoine,

Avec un testeur comme toi, on ne peut qu'avancer !
Merci
J'ai reçu les miens, mais je ne les ai pas encore testés.

Denis

[Tony04]

Fais vite STP 

Lesquels as-tu réceptionné ?

[DDEFF]

VL6180X

[Tony04]

VL6180X

Super, bonne chance à toi et bon dimanche am

[Tony04]

La solution serait peut-être à trouver en modifiant la librairie Adafruit ci-jointe dans la routine du "Adafruit_VL6180X::begin" dans le même esprit que la modification de Jean-Luc pour la librairie Pololu ?

Avis aux amateurs, moi je ne sais pas faire 

Cordialement
Antoine

[simontpellier]

@ Tony04 :

Au sujet de ce problème de double adressage, connais tu ces tutos ?

[Tony04]

Bonjour,

oui Simon, je connais ces tutos et j'ai du passer au VL53L0X qui lui fonctionne avec le changement d'adresse au reset. J'en ai mis 20 en réseau sur le bus I2C.

Mais, comme pour un autre article du forum, ce bus n'est pas suffisamment robuste avec quelques dizaines de cm de fils car dès que les fils passent près d'une ligne alimentée en DCC tout se bloque.

De plus, même avec un seul capteur avec des fils courts et sans ces parasites, de temps en temps le capteur envoie une information de présence alors que rien n'est passé devant.

Dans mon application du réseau de 9m de long avec près de 30 capteurs, cette solution n'était pas suffisamment fiable.
Du coup je suis repassé à la vrai barrière IR avec la led d'émission au raz du sol et la led de réception à environ 30mm du sol et le tout en travers dans les 2 sens. J'ai fait tourner mon petit réseau de test pendant une demi journée sans le moindre soucis.

Adieu donc cette belle technologie de pointe dont j'ai 20 exemplaires en stock et s'il y a des amateurs, je peux vous en fournir, car pour certaines applications c'est un produit super.

Merci à toi pour tes recherches.
Bonne soirée à tous.

Cordialement
Antoine

[simontpellier]

Bonsoir Tony
à peu près la même expérience...
Petit réseau de test équipé au départ avec des barrières IR (huit). Sauf que je n'avais pas pensé à la judicieuse mise en travers "haut-bas"...
Ça marchait... ou pas, mais au moins c'était clair : le montage n'étant guère stable, quelque chose avait bougé. Après... pas évident à régler quand même ces barrières !

Et puis passage aux CJMCU-3216 sur lesquels j'ai posté mes commentaires. Produit absolument parfait en lui-même, mais avec juste le défaut de communiquer via I2C, avec les soucis que tout le monde rapporte. Je m'en suis néanmoins tiré avec des lignes de code supplémentaires mais me voilà bien inquiet pour entreprendre un "vrai" réseau avec détection sur la base de ces modules.
Alors "adieu la belle technologie" ?
Et retour aux barrières IR, pas vraiment gracieuses avouons le... ?

Je pense à une solution mixant I2C et bus CAN (que j'ai juste commencé à expérimenter, c'est donc théorique mais sans rien de particulier)
- constituer des groupes avec ces détecteurs, idéalement de 8 (*) mais pourquoi pas moins, groupes basés sur la proximité géographique ;
- chaque groupe émettant sur un indispensable multiplexeur TCA9548A (* à 8 canaux), indispensable du moins pour les modules CJMCU-3216 qui ne sont pas adressables, pas indispensable dans le cas des VL53L0X qui le sont ;
- chaque groupe (ou chaque multiplexeur) étant lu par un NANO dédié ;
- et chaque NANO doublé d'une carte d'interface CAN, déversant sur un réseau CAN.
Une architecture modulaire donc et avec des composants très bon marché.

Ça devrait marcher qu'en penses tu ?
Si je parviens à mettre en pratique, je tam-tam ça tout de suite. (Mais ça n'est pas pour demain !)

[Tony04]

Bonjour Simon,

si je peux me permettre une suggestion: Essaye d'abord de faire tourner 1 seul capteur avec un nano et dans les conditions d'utilisations finales, cad proche des rails, longueur du bus I2C comme il sera dans le pire des cas, puis de laisser tourner cet ensemble pendant plusieurs minutes voire plus en affichant le résultat sur la console série.

Je ferais ce test à plusieurs endroits du réseau et ensuite à toi de décider selon le résultat.

Il est vrai que les lectures fantômes peuvent être contournées par quelques lignes de code mais, mes 40 ans d'expériences en bureau d'études en électronique m'ont appris à me méfier des comportements aléatoires des composants et je ne voudrais pas être le responsable du plus grand crash de trains de 2020.

En pièce jointe le montage de mes barrières.

Cordialement
Antoine

[DDEFF]

Bonjour,

Si je comprends bien, c'est surtout le bus I2C qui n'est pas bon...
Je note la proposition d'Antoine pour proposer de revendre ses VL6180X.

Denis

[Tony04]

Bonsoir Denis,

oui, je pense que c'est le bus I2C qui est fragile mais tout dépend de la fiabilité que l'on veut obtenir, j'ai bien réussi à récupérer les infos de mes 20 capteurs mais de temps en temps une lecture fantôme et surtout des blocages à l'approche des lignes DCC.

Où en es-tu toi même de tes essais ?

Cordialement
Antoine

[trimarco232]

juste une remarque : il existe la librairie SoftWire, je ne l'ai pas essayée, mais elle devrait permettre de créer autant de bus i2c que de paires de broches ... pour des applications "sporadiques", comme ici, on devrait pouvoir l'utiliser pour résoudre les problèmes :
1) des composants i2c qui n'ont qu'1 adresse
2) du parasitage des bus i2c : avec un seul composant par bus, la ligne serait moins tentaculaire à attraper des parasites ; dans l'idéal on implanterait l'arduino pour que les bus soient le + courts possible, et on mettrait les 2 pull-up de 4k7 de chaque côté des bus, cad. côté arduino et côté composant ... il me semble qu'on se plaint beaucoup de la fiabilité de l'i2c, mais qu'on a peu parlé des pull-up

merci aux contributeurs de nous avoir donné les résultats de leurs tests

[simontpellier]

Bonjour,

Le post de Trimarco est l'occasion de rapporter une expérience très positive concernant l'I2C.

Il s'agissait comme envisagé plus haut de lire des détecteurs, donc à priori en grand nombre et (donc) au travers d'un multiplexage. Moyennant une organisation par zones de proximité, pour des distances de fil raisonnables (jusque 60cm dans ma configuration), le tout marche PARFAITEMENT.
Tant côté bus I2C que capteurs (décidément idéaux) : jamais de fausse détection (sauf main qui traîne malencontreusement mais du point de vue du détecteur ça n'est pas une fausse détection...), le besoin néanmoins d'un filtrage logiciel sur les détections faibles, ce qui n'est pas un inconvénient car c'est fort utile : la latence qui en résulte à la retombée de la détection se traduit par une distance de dégagement avant, par exemple, la libération d'un canton quitté. Un traitement logiciel juste un peu évolué permet même que cette distance soit indépendante de la vitesse du convoi ; pour cela le gestionnaire doit rétro-signaler régulièrement au détecteur la vitesse de "l'objet" détecté. Ainsi, lorsque c'est un attelage qui est au surplomb, condition de détection la plus défavorable, une vitesse très faible entraînant une latence importante l'attelage reste détecté.
(une précision : les capteurs communiquent avec le multiplexeur et ce dernier à un arduino "satellite" par I2C / la communication satellites-gestionnaire est assurée par bus CAN)

Chaque système a ses limites (voir notamment si ceci serait transposable au HO car les "trous" entre wagons sont plus conséquents qu'en N...) mais dans mon cas je n'ai plus aucun problème. Et la satisfaction de toujours voir les feux changer lorsqu'un canton vient de se libérer, de façon constante quelque soit la vitesse, le sens traction ou refoulement.

La nécessité des résistances de tirage... en effet mais on ne risque pas de l'oublier car sans, on obtient une lecture "random". De ci de là, j'avais lu qu'il fallait mettre des 10kOhms... ça marche tout aussi bien qu'avec des 4,7 qui "tirent" pourtant plus fort bien sûr.

Seconde expérience positive : l'affichage par le gestionnaire sur écrans OLEDs, avec une seule adresse et donc également au travers d'un multiplexeur. Mais là les distances sont encore plus courtes. En tous cas, aucun souci !