LOCODUINO
Discussions Générales => Infos et bonnes affaires => Discussion démarrée par: DDEFF le mai 08, 2020, 03:16:11 pm
-
Bonjour,
Dans le dernier numéro de "Electronique et Loisirs" (hiver 2019), un composant intéressant : le VL6180X.
On peut en acheter chez Pololu ($7 à $8) :
https://www.pololu.com/product/2489 (https://www.pololu.com/product/2489)
C'est un exemple, il y a certainement moins cher ailleurs.
Des détecteur, on en a déjà plein. Mais celui-là a une particularité qui fait la différence avec tous les autres :
D'habitude, on envoie un rayon, il se réfléchit et on le détecte quand il revient.
Mais, particulièrement en infrarouge, c'est très sensible à l'éclairage extérieur. Et c'est très gênant.
Là, ils ont eu une autre idée : 3 trous.
Un laser 850n pour l'émission, un récepteur laser en réception et un troisième trou qui mesure la luminosité ambiante à l'instant de l'émission, avec un cône beaucoup plus grand qui contient le cône de réception.
Il s'ensuit qu'on peut s'en servir en pleine lumière.
Un défaut, toutefois : c'est un laser et, donc, plus dangereux si on le regarde. Heureusement, c'est très bref.
(http://www.locoduino.org/IMG/png/vl6180x.png)
Denis
-
Bonjour Denis,
cela semble effectivement prometteur comme capteur et comme tu l'as dis on le trouve moins cher ici:
https://fr.aliexpress.com/item/32966224014.html?spm=a2g0o.productlist.0.0.68345c5eWgKLva&algo_pvid=23238bc1-2e8e-4bd9-88f2-5917494e6772&algo_expid=23238bc1-2e8e-4bd9-88f2-5917494e6772-3&btsid=0b0a187915889478803643738e5e96&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_
J'en ai commandé un ici pour le tester: https://www.francerobotique.com/distance/712-capteur-infrarouge-tof-vl6180x-art0846-pololutension-dalimentation-27-55v-type-de-sortie-numeriqu.html
Un grand merci pour ce partage.
Cordialement
Antoine
-
Bien sympa avec une porté de 5mm à 100mm.
https://github.com/adafruit/Adafruit_VL6180XPrometteur !
Il y a même une fonction sympa, tu peux programmer en I2C un seuil et te faire réveiller par une interruption. Interressant pour un circuit low power que tu voudrais réveiller que si un objet entre dans la zone (je ne pense pas qu'aux trains mais à l'internet des objets qui fonctionnerait sur batterie).
Comme d'habitude, Adafruit a fait la librairie : https://github.com/adafruit/Adafruit_VL6180X (https://github.com/adafruit/Adafruit_VL6180X)
Par contre france robotique qui fait x3 sur le prix des Chinois, c'est abusé même si adafruit fait x4.
-
Mais, particulièrement en infrarouge, c'est très sensible à l'éclairage extérieur. Et c'est très gênant.
Je trouve dommage de continuer à faire circuler cette information qui tend à décrédibiliser l'IR alors qu'il suffit, pour contourner le problème, d'utiliser des capteurs fonctionnant sur des fréquences de 38Khz (ou autres). Pas très compliqué à piloter en PWM non ? L'IR qui a pourtant nombre de qualités dont le prix et la distance de détection.
Ce capteur par exemple à 1,15€ : https://fr.rs-online.com/web/p/recepteurs-ir/8185241/
Ou sa version Pololu sur PCB avec l'attiraille qui va bien dessus : https://www.pololu.com/product/2579
(https://a.pololu-files.com/picture/0J7392.600x480.jpg?a62cf72bd6e7c8a83c6a87fe48bc05a5)
Qu'on s'entende bien, je ne critique en rien le capteur présenté.
-
Bonjour Christophe,
Sur le lien Polulu que tu cites dans ton post, je lis :
"This sensor can be triggered by ambient IR (e.g. from fluorescent lights; see the right oscilloscope capture below). Some optical shielding, such as by having the sensor mounted receiver-side-down when fluorescent lights are above, might mitigate this. Some advanced analysis of the correlation between the output and toggling of the enable input might also be used to mitigate ambient interference".
Il y a même deux copies d'écrans d'oscillo pour mettre en évidence ce phénomène.
Pour avoir fait pas mal de salons de trains, j'ai souvent entendu parler de ça, et de toutes les ruses d'indien pour que l'IR soit dans une petite boîte, à l'ombre.
En particulier, on le réserve à des barrières horizontales, moins perturbées par les néons.
Alors, je ne sais pas si ce nouveau capteur résiste bien aux tubes fluo, mais il n'y a plus ce commentaire sur le site de Polulu.
Ce nouveau capteur a certainement des défauts (dont le prix et le fait qu'il utilise des lasers potentiellement mauvais pour les yeux), mais je vais le tester.
Denis
-
Pour les capteurs IR entre les traverses, tu peux ajouter la saleté (poussières et autres cochonneries).
Tout marche toujours très bien sur le bureau dans des conditions de lumière normales. Beaucoup moins bien quand tu éclaires le capteur. Sans compter que la plupart du temps la surface est noire. :)
J’avais conseillé à piston93 sur le forum du N des GP2Y0D805Z0F de Sharp qui fonctionnaient parfaitement chez moi et qui sont atteints de myopie sur son module éclairé avec des LED.
Faut voir ce que ça donne avec des TOF que je compte essayer de mettre au fond des remises.
-
Surtout que, si, par exemple, tu est en 1/160, hé bien, les cochonneries, elles, sont toujours à l'échelle 1/1 ! ;D
-
Bonjour,
comme promis voici le résultat de mes premiers tests avec ce nouveau capteur laser.
Conditions d'utilisation:
- Arduino PRO/MINI 3,3V (pour éviter une adaptation de niveau)
- Liaison avec le VL6180X fils volants de 85cm collés le long des rails
- Loco HO avec 2 wagons
- Passage en vitesse maximum
- Passage en vitesse minimum (très très lent)
- Exposition du capteur en plein soleil
Résultats:
Vous trouverez dans le fichier "test VL6180X.txt" ci-joint les valeurs lues avec le sketch de démo "InterleavedContinuous.ino" qui se trouve dans la librairies ici: https://github.com/pololu/vl6180x-arduino
Je vous joins également les photos des conditions d'utilisation.
Un point fort de ce capteur c'est qu'il capte même les crochets d'attelages et qu'il n'y a aucun vide entre les wagons même en vitesse ultra lente (voir le fichier texte joint), ce qui permettrait de supprimer les barrières IR.
J'ai quand même réussi à planter quelque fois le programme avec le message "TIMEOUT" mais avec des liaisons de 20cm et avant même de coller les fils de 85cm le long des rails; je n'ai pas réussi à en trouver la raison mais je suppose que c'est en manipulant le capteur sans précaution. On peut très bien envisager un(e) watchdog car avec un reset par nouveau lancement du moniteur série tout est bien reparti.
Petite précision, je n'ai pas pris le temps de mettre les 2 résistances pullup qui sont recommandées sur le SDA et SCL.
Bonne découverte.
Cordialement
Antoine
-
Merci Antoine,
Tu as déjà reçu le tien ? C'est rapide !
Plein de questions : :P
Qu'est ce que tu as, comme lampe, au dessus ? (LED, néons, ampoule). J'ai bien lu : plein soleil ??
As-tu une idée de l'unité de mesure ? Apparemment, c'est prévu pour détecter jusqu'à 10 cm.
Peut-on dire que 10 cm = 255 ? A mon avis, 255 = + l'infini. Mais combien vaut 1 ?
Est-ce linéaire (ce qui m'étonnerai beaucoup) ?
Si je comprends bien ce que tu dis, on pourrait compter les wagons ? Et ce, sans couper le faisceau !
La mesure est-elle rapide ? Dit autrement, si on va très vite, peut-on quand même compter les wagons ?
Bien amicalement
Denis
-
Est-ce linéaire (ce qui m'étonnerai beaucoup) ?
Et pourquoi ? :)
Il y a un microcontrôleur à l'intérieur.
C'est linéaire
-
Comme d'hab, il fallait lire la datsheet avant de causer... ::)
C'est parfaitement linéaire. C'est génial.
Denis
-
Bonjour Denis et jean-Luc (dans l'ordre des messages ;) ),
oui, je l'ai eu rapidement car je l'ai commandé chez France Robotique au prix total de 15,90€ quand même.
Un néon, ah quelle horreur de nos jours... Pour l'instant c'est en plein soleil que je l'ai testé, ce soir je vais essayer avec les spots leds de mon plafond mais je ne me fais aucun soucis de ce coté.
Il est donné pour 10cm mais la mesure commence bien à partir de 20cm, par contre ne compte pas sur sa linéarité car la mesure est très différente selon la matière à détecter, la main par exemple ne fonctionne pas de façon précise, ce qui me parait normal vu le principe de mesure par laser.
Dans le sketch de démo l'unité de mesure est le mm mais en dessous de 15 ou 10 mm cela devient inutilisable selon la matière.
Je ne vois pas comment compter les wagons puisqu'à aucun moment la mesure n'est repassée à 255 entre 2 wagons et le changement de valeur entre le wagon et le crochet est très aléatoire.
Par contre je viens de découvrir un point intéressant: Pour moi la peur c'est la poussière avec ces 2 tout petits trous dans le capteur, surtout si on le glisse sous les rails, du coup j'ai testé avec un morceau de plexi transparent posé directement sur le capteur et ... miracle la mesure indique 255 et en passant avec le convoi pratiquement pas de différence de valeur. Il est donc possible de se prémunir de la poussière.
Je continu mes essais et vous en fais part, bon appétit en attendant
-
Dans l'article où j'ai trouvé ce composant, ils expliquent que c'est justement fait exprès : c'est prévu pour être sous une "vitre" de mobile (le capteur, à l'intérieur, détecte ce qui se passe "dehors").
C'est vrai que c'est une bonne nouvelle.
Par ailleurs, on a l'air d'avoir une répétition de mesure toutes les 100 ms (10 Hz) d'après la datasheet.
Denis
-
je viens d'essayer de compter les wagons en plaçant le capteur à mi hauteur des wagons et en réduisant le delay entre 2 lectures à 200 ms mais les résultats ne sont pas exploitables, voici les valeurs pour 1 loco et 2 wagons pour une vitesse sur 80 crans:
Ambient: 39 Range: 255
Ambient: 41 Range: 255
Ambient: 41 Range: 255
Ambient: 43 Range: 30
Ambient: 41 Range: 16
Ambient: 11 Range: 14
Ambient: 9 Range: 14
Ambient: 9 Range: 10
Ambient: 9 Range: 14
Ambient: 9 Range: 11
Ambient: 7 Range: 11
Ambient: 8 Range: 73 entre loco et 1er wagon
Ambient: 35 Range: 12
Ambient: 17 Range: 13
Ambient: 13 Range: 15
Ambient: 14 Range: 13
Ambient: 12 Range: 12
Ambient: 12 Range: 182 entre loco et second wagon
Ambient: 24 Range: 20
Ambient: 29 Range: 15
Ambient: 12 Range: 16
Ambient: 9 Range: 14
Ambient: 12 Range: 46
Ambient: 20 Range: 183
Ambient: 37 Range: 255
Ambient: 40 Range: 255
Ambient: 42 Range: 255
Je ne pense pas que ce soit suffisamment parlant.
Si je ne mets pas de delay du tout, TIMEOUT assuré.
Par contre comme remplacement de barrière IR je vais être partant.
A vous pour la suite.
Cordialement
Antoine
-
Par contre si quelqu'un peut m'aider à changer l'adresse I2C du composant, je suis preneur, je n'ai rien trouvé en français.
-
J'avance péniblement avec mon anglais de 6è mais j'ai réussi à changer l'adresse I2C du module laser.
Avec le scanner I2C je trouve bien l'une ou l'autre des adresses.
Mais comment adresser l'un ou l'autre des modules car à aucun moment on ne définie cette adresse dans le code de démo (ci-joint), d'ailleurs je ne trouve pas non plus de mot clé qui permette cette définition ?
Merci d'avance pour vos conseils.
-
Bonjour
Apparemment l'adresse I2C se trouve dans le registre 0x212, elle peut être changée après la mise sous tension (7 bits).
Pierre
-
Regarde dans VL6180X.h, il y a une méthode setAddress ...
Qui écrit dans le registre 0x212, bien vu Pierre.
Par contre j'ai du mal à voir le mise en œuvre quand tu as plusieurs modules. En effet, setAddress change l'adresse dans l'instance de l'objet (membre address) et dans le registre 0x212. J'imagine que ce registre est en mémoire non volatile (j'ai pas vérifié dans la datasheet). On peut imaginer de brancher les modules et de leur donner une nouvelle adresse mais ensuite, une fois qu'on a plusieurs modules avec des adresses différentes, il n'y a pas moyen de donner une adresse de module à l'objet sans qu'il écrive cette adresse dans le registre 0x212.
-
La mesure est-elle rapide ? Dit autrement, si on va très vite, peut-on quand même compter les wagons ?
Je viens de découvrir qu'avec le sketch de démo "RangeSingleShot.ino" la mesure est continue et du coup beaucoup plus rapide que mon premier essai, du coup le comptage des wagons est parfaitement envisageable, mais certainement pas en vitesse maximum.
-
Tony,
A priori le changement d'adresse se fait de manière logiciel.
Le datasheet : https://www.st.com/resource/en/datasheet/vl6180x.pdf
Paragraphe 6.2.55, page 76 :
Je comprends qu'il est de base à l'adresse 0x29 et qu'en envoyant sur le registre 0x212 une valeur compris en 0 et 127 (7 bits), ça doit programmer la nouvelle adresse. Je n'ai pas lu si c'était persistant mais cela me semble évident.
[6:0] super_i2c_slave__device_address: User programmable I2C address (7-bit). Device address
can be re-designated after power-up.
-
Bonjour,
En furetant un peu j’ai trouvé que l’adresse en question n’est pas en mémoire permanente et est donc remise à sa valeur par défaut à chaque mise sous tension.
ST a publie une note d’application : https://www.st.com/resource/en/application_note/dm00114403-using-multiple-vl6180xs-in-a-single-design-stmicroelectronics.pdf
On y trouve notamment la phrase :
Since the VL6180X can have the I2C device address changed by doing an I2C write once it is booted, a separate reset pin would be needed to each VL6180X used in a design. Each device is then taken out of reset one at a time, and then the I2C Device Address is changed to a new unique address. This can be done by using multiple GPIO pins from the microprocessor on the board.
-
Regarde dans VL6180X.h, il y a une méthode setAddress ...
Qui écrit dans le registre 0x212, bien vu Pierre.
Par contre j'ai du mal à voir le mise en œuvre quand tu as plusieurs modules. En effet, setAddress change l'adresse dans l'instance de l'objet (membre address) et dans le registre 0x212. J'imagine que ce registre est en mémoire non volatile (j'ai pas vérifié dans la datasheet). On peut imaginer de brancher les modules et de leur donner une nouvelle adresse mais ensuite, une fois qu'on a plusieurs modules avec des adresses différentes, il n'y a pas moyen de donner une adresse de module à l'objet sans qu'il écrive cette adresse dans le registre 0x212.
Bonjour tout le monde,
j'ai parfaitement réussi à changer l'adresse de manière non volatile en "désalimentant" après chaque changement d'adresse le module et en passant le module par le scanner I2C qui trouve bien la nouvelle adresse. Le problème n'est plus là, il faut maintenant savoir comment adresser ces différentes adresses I2C car à aucun endroit on précise une adresse sauf si on travaille directement avec la librairie wire sans passer par la librairie VL6180X comme dans cet exemple: https://www.redohm.fr/2018/02/tutoriel-arduino-communication-i2c-1-maitre-2-esclaves/
Je viens d'en commander un second pour voir si en utilisant la broche GPIO0/CE on arrive à sélectionner l'un ou l'autre sans y croire vraiment.
Cordialement
-
Veux tu que je modifie la bibliothèque Pololu pour rajouter un constructeur auquel on passe une adresse ?
EDIT: C'est fait, tu peux récupérer la version modifiée ici : https://github.com/Locoduino/vl6180x-arduino
Lors de l'instanciation d'un objet VL6180X, tu peux spécifier l'addresse, par exemple :
VL6180X sensor(56);
C'est évidemment pas testé, je n'ai pas de VL6180X. Si ça fonctionne correctement je ferai une pull request à Pololu et une version 1.2.1 sortira dans les prochains jours si ils sont réactifs.
-
Un grand merci à toi Jean-Luc,
mais je n'arrive plus à changer l'adresse de façon non volatile alors que ce matin cela fonctionnait bien. Ce n'est pas encore gagné mais je continue mes essais.
Bonne soirée
Antoine
-
Veux tu que je modifie la bibliothèque Pololu pour rajouter un constructeur auquel on passe une adresse ?
C'est évidemment pas testé, je n'ai pas de VL6180X. Si ça fonctionne correctement je ferai une pull request à Pololu et une version 1.2.1 sortira dans les prochains jours si ils sont réactifs.
Bonsoir à tous,
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.
Par contre il faut quand même une sortie par capteur pour sa pin CE afin de pouvoir changer l'adresse de chacun des capteurs au moment de l'initialisation (dommage que l'adresse ne soit pas en EEPROM).
Ci-joint mon sketch de test.
Encore merci à toi pour la modification de la librairie.
Bon dimanche soir à tous.
Bien cordialement.
Antoine
-
Bonsoir Antoine,
Je suis ces essais avec beaucoup d'intérêt étant de mon côté en test sur un détecteur voisin (CJMCU3216) en remplacement de barrières IR. Tests très encourageants et dont les résultats rejoignent les vôtres.
Si j'interviens, c'est en fait pour savoir pourquoi ne pas avoir utilisé ce module :
https://learn.adafruit.com/adafruit-tca9548a-1-to-8-i2c-multiplexer-breakout
pour régler ce problème d'adresse unique des capteurs (pareil avec ceux que je teste). Un module = 8 sorties I2C, chaque module pouvant avoir 8 adresses, on peut donc avoir 64 capteurs, même ayant la même adresse. De quoi voir venir !
(et pas de pins "consommés" sur l'arduino).
-
Bonjour Simon
Ce fameux capteur "TCA9548A" je l'ai acheté pour branché les RFID avec la même adresse. Résultat destruction des plusieurs RFIDs
Il me semble qu'il faut être prudent avec ce Multiplexeur (voir la programmation => un programme de test serait le bien venu "hélas au-delà de mes compétences")
Il existe un appareil pour changer l'adresse I2c (impossible de le commander, de plus il coûte un bras et pas sur qu'il soit possible de changer les adresses sur tout type de matériel)
https://modernroboticsinc.com/core-device-discovery/
Quelqu'un a-t-il une piste (logiciel) pour changer ces adresses figées sur un appareil?
Marcel
-
Bonjour,
Ce matin, Youtube m'a gratifié d'une vidéo :
https://www.youtube.com/watch?v=t7dPz7Q2Rig (https://www.youtube.com/watch?v=t7dPz7Q2Rig)
C'est une vidéo du 15/12/19 qui parle d'un ToS plus simple que le VL6180X, le VL53L0X. Il a seulement 2 trous et donc, ne tient pas compte de la lumière ambiante.
C'est effectivement moins bien.
Mais l'intérêt de cette vidéo (en américain, désolé Antoine :(), c'est le fait qu'elle est accompagnée par un lien Github.
On voit le fonctionnement avec ESP32 et MQTT, très bien détaillé sur la fin de la vidéo, et le sketch arduino est fourni.
Je ne suis pas spécialiste, mais je pense qu'il y a des infos intéressantes à glaner dans ce sketch.
Sinon, on a un fonctionnement au mm près ! C'est assez impressionnant. :o
Denis
-
[Hors sujet] Je serais ravis que l’on commence à envisager MQTT dans le domaine ferroviaire !
C’est ce à quoi je vais m’atteler dans le projet « La Box » pour faire une passerelle CAN/MQTT. ;)
-
Si j'interviens, c'est en fait pour savoir pourquoi ne pas avoir utilisé ce module :
https://learn.adafruit.com/adafruit-tca9548a-1-to-8-i2c-multiplexer-breakout
Bonsoir Simon,
tout simplement parce que je ne connaissais pas ce produit, mais ma joie a été de courte durée avec le message de Marcel...
De plus cela rajoute encore un composant et je pense avoir des pins disponibles pour la sélection de chaque capteur puisque j'étais parti pour des barrières IR classiques.
En tous cas le produit semble plaisant à utiliser même à titre d'expérience simplement.
Pour Denis, j'étais déjà tombé sur une vidéo qui en parlait et je viens d'en commander 2 exemplaires chez Ali pour tester car pour mon usage la mesure de luminosité est inutile.
Merci pour ton message.
A Pyk35, une question très bête... C'est quoi MQTT, c'est du langage SMS ? :-[
Cordialement
Antoine
-
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
-
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
-
Fais vite STP :)
Lesquels as-tu réceptionné ?
-
VL6180X
-
VL6180X
Super, bonne chance à toi et bon dimanche am
-
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
-
@ Tony04 :
Au sujet de ce problème de double adressage, connais tu ces tutos ?
https://www.youtube.com/watch?v=RRQASevYK3g
https://www.youtube.com/watch?v=0glBk917HPg
-
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
-
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 !)
-
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
-
Bonjour,
Si je comprends bien, c'est surtout le bus I2C qui n'est pas bon... 8)
Je note la proposition d'Antoine pour proposer de revendre ses VL6180X.
Denis
-
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
-
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
-
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 !