Repérer des câbles en bluetooth

Bonjour nesty68

As-tu pu faire le test que je te proposai au post #153 ?

Je suis entrain de tester une solution avec des modules de mesure reliés par radio.

A+
Cordialement
jpbbricole

Non malheureusement j'ai eu un peu de mal pour me trouver 5 min au travail pour tester et surtout, j'ai retrouvé mon arduino mais pas le câble d'alimentation (sur secteur)...

Bosoir nesty68

Je me suis bien amusé à essayer de faire un système pour repérer des câbles :wink:
C'est fait au moyen de modules pour le côté émission (CE) ou réception (CR) qui sont identiques, seul le programme les différencies.

Le schéma du test :

Le programme se commande par des ordres introduits dans la ligne de commande du moniteur de l’IDE Arduino.
Commande SCANCECE Câblages internes du module du côté émission (CE)

CE00 pt: 0 CE00 7-
CE00 pt: 7 CE00 0-

Commande SCANCECR Câblage des modules distants (CR) vu de CE

CE00 pt: 1 CR01 6
CE00 pt: 2 CR01 5
CE00 pt: 3 CR01 4
CE00 pt: 4 CR01 3-13
CE00 pt: 5 CR01 2
CE00 pt: 6 CR01 1
CE00 pt: 8 CR02 0
CE00 pt: 9 CR02 1
CE00 pt: 10 CR02 2
CE00 pt: 11 CR02 3
CE00 pt: 12 CR02 4
CE00 pt: 13 CR02 5
CE00 pt: 14 CR02 6
CE00 pt: 15 CR02 7

Commande SCANCRCR Câblages internes du module distants (CR)

CR01 pt: 3 CR01 13
CR01 pt: 13 CR01 3
CR02 pt: 8 CR02 13
CR02 pt: 13 CR02 8
CR02 pt: 14 CR02 15
CR02 pt: 15 CR02 14-15

Le montage de test :

La liaison entre les modules se fait par radio, chaque module a une extension de bus MCP23017, mais c’est extensible. Par principe tout les CR ont la même configuration pour ce qui est des ports. Le programme est indifférent quant au fait qu’un port est interne à l’Arduino ou qu’il soit dans un MCP23017.

Je n’ai pas encore fait des essais longue distance, il faut que je trouve un câble et je dois, aussi, faire des essais avec le commun via la terre du réseau.

Si tu es intéressé :wink:

Cordialement

Jpbbricole

1 Like

Bonjour nesty68

J’ai fait des essais avec 30 mètres de câble CAT5 UTP, avec GND commun via la terre du secteur,
image

test fait en appartement avec ce montage.
image
Tout s’est très bien passé.

Câble Ethernet droit

Scanning ports CE > CR
CE00 pt: 0 CR01 0
CE00 pt: 1 CR01 1
CE00 pt: 2 CR01 2
CE00 pt: 3 CR01 3
CE00 pt: 4 CR01 4
CE00 pt: 5 CR01 5
CE00 pt: 6 CR01 6
CE00 pt: 7 CR01 7

Câble Ethernet croisé

Scanning ports CE > CR
CE00 pt: 0 CR01 2
CE00 pt: 1 CR01 5
CE00 pt: 2 CR01 0
CE00 pt: 3 CR01 3
CE00 pt: 4 CR01 4
CE00 pt: 5 CR01 1
CE00 pt: 6 CR01 6
CE00 pt: 7 CR01 7

Voilà, tout ceci (les programmes) est à ta disposition, si tu te sent le courage.

Je suis à ton entière disposition pour t’aider.

A+
Cordialement
Jpbbricole

Bonjour @jpbbricole,

Me revoilà avec des nouvelles !
Je vois que tu as fait tellement pour le projet, merci pour ton implication :smiling_face_with_three_hearts:
J'ai aussi pratiqué quelques tests avec 2 arduino. Alors comme dit, je suis vraiment en débutant donc je tâtonne un peu. J'ai fait un test sur un câble de même section que mon projet, il fait dans les 30m et ça a fonctionné.

A force de réflexion, à la base j'étais sur 1 arduino, puis 1 arduino par prise, puis création de maître esclave, puis ensuite est venu les question du traitement des données,... et maintenant après tout ça, il semblerait que le maître ne soit plus de la partie, que celui ci serait remplacé par un raspberry PI, il pourrait alors lancer le programme et comprendre ce qu'il s'est passé, les arduino serait alors ses ouvriers qui lancent juste un test sans savoir pourquoi et qui répondent à la demande et transmettant le résultat de leur travail.

Alors avec tout ça maintenant je me rends encore plus compte que mon projet à beau l'air d'être banal et simple, avec une telle quantité, celui ci est devenu bien complexe. Oui, si j'avais eu un cahier de charge j'aurai pu savoir quelle direction prendre dès le départ et je ne vous aurais pas fait perdre de temps, sauf que toutes ces réflexions m'ont aussi permis d'apprendre plein de choses que je n'aurais pas appris si je n'étais pas passé par là !

C'est un forum sur l'arduino et en soit ma partie arduino risque de bientôt se "terminer", alors je ne sais pas si je pourrais vous demander des conseils pour la suite comme la mise en place de la base de données et le programme pour comparer les résultats avec celle ci. Il me faudra juste encore apprendre sur la création d'un multiplexeur mais pour cela je pense que je n'aurais qu'à lire des docs comme vous me l'avez conseillé :wink:

Je me permets de laisser le sujet en non terminé et quand mon projet sera fonctionnel, je complèterai le sujet pour le clore.

Bonsoir nesty68

Tu pourrais très bien faire tout ton système de mesures avec des Arduino et traiter les données obtenues avec un RPI.
RPI qui serait connecté sur le CE.
Il suffit d'envoyer l'ordre SCANCECR au CE pour lancer le scanning des prises.

Mais, quoi qu'il en soit, je me suis bien amusé avec ton projet :wink:

Bonne soirée
jpbbricole

Voir ne pas du tout utiliser un raspberry et traiter les données par un microcontrôleur compatible Arduino.
En l'état de se que tu nous as décris un raspberry est superflu, tout comme l'utilisation d'une base de données conséquente, un fichier de données structurées est largement suffisant.

Mon "système" doit pouvoir tester les connexions le plus simplement possible. De ce fait, je ne veux pas que mon code demande de tester que le point A arrive bien au point B car je veux que le point B soit découvert (pour trouver des pannes mais aussi une mauvaise position dans la prise).

Ma base de donnée ça sera les bonnes destination de mes fils, et donc à la fin de mon test, j'aimerai un programme qui compare les résultats avec la base, jusque la rien d'impossible, mais comment mon programme saura que le test partant de A et arriver en B sachant que j'ai une quantité énorme de fils ?

Petit plus (et merci mon entreprise), niveau logiciel je suis super restreint... pour dire, je n'ai que la version en ligne d'excel et pas la version complète "physique". Pour tout ce qui est logiciel externe, à moins que le bon dieu soit de mon côté, jamais je pourrais en installer (pour les arduino je dois faire ça via mon pc perso, le logiciel n'est pas admis sur mon pc pro). C'est une politique contre l'espionnage industriel et même si elle est bien contraignante dans mon cas, je ne peux pas aller à son encontre.

C'est pour ça que j'ai dérivé sur un rapsberry. Petit ordinateur à qui on peut connecter un écran de pc, il peut avoir des logiciels fait maison sans compromettre mon entreprise.

Tu n'a pas compris, si tu peux le faire avec un Rasberry, tu peux aussi le faire avec un Arduino.
Enfin ce que tu décrit est une base de donnée fichier plat, en gros pas vraiment une base de donnée.
Tu peux très bien brancher ton Arduino maitre sur ton PC perso pour l'affichage, si un affichage Arduino est trop contraignant.

Après je ne dis pas qu'avec un raspberry se ne sera pas plus simple.

Concernant les normes de sécurités, oui c'est tout à fait normal et correspond à des pratiques très conventionnelles.
Après si cela correspond à un besoin ou amélioration de productivité, il doit être possible de faire certifier et autoriser l'environnement Arduino par ton SI. Mais ça c'est des fois beaucoup moins simple, que t'introduire un PC personnel ou un raspberry non certifié par le SI dans l'enceinte de ton entreprise. Ce qui devrait normalement être interdis par les règles élémentaires de sécurités :slight_smile:

Mon pc perso me sert à la mise en place du projet mais il ne sera pas à dispo pour mes collègues pour de futur essais !

Ma venu sur le raspberry vient du fait que j'ai suivi ce chemin de pensées :

  • Si arduino maître demande au esclave de tester leurs connexions (pour rappel, mon projet se passe en bluetooth et aucun arduino n'est relié entre eux si ce n'est pas les prises sur lesquels ils sont branchés), l'arduino esclave recoit un signal puis envoi en Bluetooth la réception d'une arrivé/impulsion à l'arduino maître, puis l'arduino maître doit montrer à l'utilisateur ce qu'il a fait (à qui il a demandé le test et qui a répondu), sauf que là, comment voir les résultats sans logiciel ?

J'ai vu des créateurs avec arduino qui font des choses extraordinaires et rien qu'en passant par excel ! génial ! sauf que bah non, j'ai pas excel...

  • L'HTML fut aussi parti des solutions, mais encore une fois, ça demande un serveur local, une connexion,... pleins de choses qui mettrons beaucoup trop de temps à être accepter voir qui peuvent être refuser.

  • Puis est venu la question du raspberry pour lire les résultats. Je n'ai pas encore le raspberry mais rien que de me dire que je serais moins bridé me donne déjà plus envie d'avancer !
    A un moment, après quelques réflexion je me suis dit, et si le raspberry pouvait demander aux arduinos de faire le test ? A quoi servirait le maître alors ? C'est via cela que l'arduino maître est sorti de mon projet.

Comme tu l'as si bien dit, si il y a des normes de sécurités sur les pc pro, mettre en place un raspberry devrait d'office être refusé !
Le truc c'est qu'un pc possède un système d'exploitation avec de potentielles informations sur mon entreprise, mais, un raspberry, bien qu'il soit hackable, à part un fichier qui dira "fil 406 part de prise 1 pour arriver en prise 2", le raspberry ne sera pas une source trop dangereuse en terme de confidentialité.
De plus j'ai appris récemment qu'un projet similaire, mais pour tester seulement une machine, existait et le programme a été "fait maison" par un employé, alors pourquoi je ne recopie pas simplement ? Ce système fait bien plus que du test de continuité et il date des années 90-2000 donc la "machinerie" est très grande et pas adapté à ce que je veux faire.

Je vais vous redonner ma configuration :

  • j'ai 80 prises avec 5 à 80 fils chacune à tester
  • mes fils peuvent avoir une entrée et une sortie espacé de plus de 20m
  • pour une optimisation, j'ai opté pour une système sans fil et pour le moment je suis sur un système qui passerait par le bluetooth
  • pour le test de mes fils, je ne peux pas me référer à une masse
  • je souhaite installer un arduino par prise (ou parfois si 3-4 prises avec 5-6 fils chacune sont proche, je les relirai sur le même arduino)
  • pour pouvoir relier mes arduinos à 80 fils, je passerai par un multiplexeur que je j'assemblerai moi même
  • si je passe par un pc (windows), je ne peux pas installer de logiciel dessus

Maintenant avec cela, si quelqu'un à une idée pour tester mes connexions, savoir qui est branché où, je suis preneur :sweat_smile:

onjour nesty68

Je dois dire que je te comprends de moins en moins, dans ce que tu décris au-dessous de:

Est quasiment appliqué dans ma proposition décrite dans les articles #163 et #164, sauf que ce n'est pas en Bluetooth ( 20 à 30 mètres, tu oublies), mais en RF24 et que la référence commune, le GND, se fait par la terre du réseau, c'est testé sur 30 mètres. Tu peux mettre un Arduino par prise ou plusieurs prises sur un Arduino.

Cordialement
jpbbricole

+1, ou plutôt +10
Je dois avouer qu'après 170 posts, on tourne en rond.
Pour ma part il y a longtemps que j'ai abandonné.

Sur ce point, si tu n'as toujours pas compris qu'une référence est indispensable, c'est grave.

comme vous :thinking:

En Bluetooth avoir un maitre connecté à 80 esclaves, c'est même pas la peine d'y penser, en rf24 c'est possible ?

Il y a aucune différence, un raspberry à aussi un system d'exploitation!
Par contre si un logiciel existe déjà oui, c'est surement plus simple, dommage que @jpbbricole se soit embêter à développer ton application :disappointed_relieved:

absolument pas, un Arduino(esp32) peut très bien le faire sans soucis.

Avec comme tu l'indique un serveur HTTP, un écran d'affichage, un PC connecté en usb est une application dédié, une application dédié sur smartphone connecté en Bluetooth ou en wifi, ...

Il y a aussi plein de chose fait sans Excel, qui n'est absolument pas une nécessité.

Franchement je te le dis sans volonté de te heurter, j'ai l'impression que tu as beaucoup de préjugé et que tu n'es pas du tout dans l'écoute des conseils que l'on peut te donner.
C'est dommage car je pense que l'on comprends tout à fait ce que tu veux faire et que l'on pourrait t'apporter des solutions efficace et d'ailleurs @jpbbricole l'a plus que démontré puisqu'il à déjà un prototype.

Je n'ai jamais essayé jusqu'à 80, ce n'est pas nécessaire, dans le projet de @nesty68.

En RF24 on attribue 2 pipes par "utilisateur", par exemple:

	radioRF24.openWritingPipe(rf24PipeAddressBase + (2 * msIndex));        // Both radios listen on the same pipes by default, and switch when writing
	radioRF24.openReadingPipe(1,rf24PipeAddressBase + (2 * msIndex) + 1);

Cordialement
jpbbricole

Oui, complétement indépendamment du problème de @nesty68 , combien d'utilisateur tu peux connecter au maitre ?
Ou combien d'adresse différente le protocole gère t-il?

Aucune idée :woozy_face:
L'essentiel, comme le RF24 est très utilisé, est d'attribuer des "clefs" de pipes compliquées pour éviter d'éventuelles similitudes.

const uint64_t rf24PipeAddressBase = 0xFDB975468ACEF000LL;              // Pipes addresses base.

par exemple.

Cordialement
jpbbricole

Moi, je n'ai pas compris non plus pourquoi. Voici un montage sans fil de référence physique (chaque fil est potentiellement un fil de dialogue):

A l'initialisation, toutes les broches sont en INPUT_PULLUP. Grâce à elles, pour chaque nano, toutes ses entrées sont au potentiel VDD (5V).

Pour le test des connexions, si le maître met une entrée non reliée à VSS (GND ou LOW ou 0V ou VSS), il ne se passer rien de plus.
Si le maître met une entrée reliée au maître (par exemple la sortie 3). L'entrée reliée va passer à LOW (la 6). Il peut donc voir ses propres bouclages.
Si le maître met une entrée reliée à un esclave (par exemple la sortie 7). Il va y avoir une tension de -5V sur cette broche par rapport à tous les autres connexions. L'entrée de l'esclave va donc passer à LOW (la 6). L'esclave peut alors savoir qu'il vient de recevoir une information de connexion et peut ainsi y répondre.

Pour le dialogue, on peut s'inspirer du protocole onewire qui permet le dialogue bidirectionnel entre plusieurs dispositifs sur un seul fil. Par exemple:
− les broches des nanos ne peuvent prendre que deux états principaux INPUT_PULLUP et LOW, et pour passer de l'un à l'autre passe par INPUT
− chaque Nano possède un code propre et unique (de 0 à 79, ou même jusqu'à 255)
− une nano qui est en attente scrute ses entrées et si elle reçoit un zéro de 1000µs, c'est une demande de présence, elle répond en mettant sa sortie à l'état bas pendant 1000µs Ainsi le maître peut savoir qu'il y a une ou plusieurs cartes qui sont connectées sur ce fil.
− pour savoir qui est connecté sur ce fil, le maître peut envoyer un LOW pendant 500µs pour indiquer "je demande toute votre attention sur cette connexion uniquement". Suit alors une demande d'identification pour chacune des cartes.

Le maître peut donc savoir aussi qu'un fil est branché à un esclave et qu'il va pouvoir dialoguer avec lui sur ce fil. Il peut donc en particulier lui demander le numéro de la broche. Chaque fois qu'une connexion est trouvée, elle est marquée "connue" de la part des deux parties.

Une fois que le maître connaît toutes ses connexions, il se note "complet" et passe la main à une autre carte qui lui dit qu'elle n'est pas "complète". Cette dernière se marquera "complète" et passera la main à une carte non "complète". Si une carte ne trouva pas de carte "non complète", elle le signale à la carte qui lui a donné la main, laquelle cherche alors une autre carte non complète. Si la carte mère ne peut plus trouver de carte "non complète", c'est que tout le réseau a été exploré.

A chaque fois qu'une nouvelle carte est trouvée, cela établi un chemin entre le maître et cette carte qui peut ainsi informer le maître des nouvelles connexions qu'elle trouve.

Si des problèmes de vitesse de transmission se posent, rien n'empêche d'aller plus lentement.

Si on a une prise avec plus de 17 fils, le plus simple est de mettre plusieurs nanos en cascades, on a alors besoin d'un fil de dialogue car comme elles sont ensembles, on peut utiliser VDD et VSS. Cela rajoute 15 broches supplémentaires. Pour 80 fils, il faut 6 nanos.


Question: Pourquoi cela ne fonctionne pas?

Si je ne dis pas de bêtise chaque Arduino aura son propre 5V(VDD) par rapport à la masse(GND).
Si tu n'a pas de masse commune comment tu garantit que chaque VDD à la même différence de potentiel(5V) ?

Si tu branche un capteur uniquement par le fils onewire, sur une alimentation complétement différente de celui de l'Arduino, cela fonctionne-t-il?

Onewire utilise un fil ET un GND

Pas par rapport à LA masse mais à SA masse à lui.
En principe on relie les masses pour avoir une référence pour tout le monde. Mais on peut ne pas relier les masses et relier les 5V. Cela revient au même. Dans mon premier dessin, j'avais mis une référence commune par le 0V, mais dans ce cas je suis obligé de mettre des résistances de pulldown. J'ai donc inversé le montage.

Dans ce montage, je crois, si il n'y a que deux fils branchés en tout avec un maître et un esclave, mettre un fil à LOW ne garantira pas du tout un LOW de l'autre côté:


En rouge le trajet du curant et on a sur l'esclave un peu moins de 2,5V entre l'entrée et le VDD. Pour 3 liaisons en tout on a:


Et on trouve alors Une tension proche de 60% sur la pullup de l'esclave, ce qui est presque la limite pour détectet un 0.

Mais le nombre de liaisons dans le cas qui nous préoccupe est supérieur à 5.

Il y a peut être le cas où Nano 1 a une seule liaison avec nano 2, une seule avec nano 3... et que nano 2 n'ai pas de liaisons avec nano 3, ni nano4....

Si cela pose un problème, on peut aussi lorsque une nano veut envoyer un LOW, mettre la sortie correspondante à LOW et toutes les autres à HIGH, a condition d'avoir vérifié avant qu'il n'y a pas de bouclage entre deux de ses broches (dans le cas contraire, on ne met pas la broche en question à HIGH, mais on la laisse en entrée). Dans ces conditions même avec deux liaisons cela fonctionne.

Non, car il faut toujours deux fils pour qu'il y ait une boucle. et que le courant puisse passer.

Ici le courant passe par la broche en test et revient par les autres.

Le protocole type onewire est intéressant ici car sur une même broche, on peut avoir plusieurs nanos branchées. C'est plus pour cette raison que je parle de ce protocole. Pas pour la reconaissance d'un 0 ou d'un 1.