Auteur Sujet: Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.  (Lu 10853 fois)

msport

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2217
  • HO avec DCC++ en DIY Réseaux très éphémères
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #45 le: janvier 16, 2024, 10:16:54 am »
Bonjour à tous,

la question des longueurs de câble se pose avec les protocoles non redondants, bas niveau (5V) et ne travaillant pas en différentiel :
A contrario du CAN.
déjà pour le Railcom : des problèmes avec 50 cm entre la voie et la détection. A réduire au maximum.
l'I2C est bien adapté aux liaisons courtes (moins de 50 cm)
le S88 que j'ai abandonné.

Blinder les câbles n'est une panacée : il faut gérer et éviter les boucles de masse.
Dans l'industrie les câbles UTP (non blindés) sont le standard pour l’Ethernet.

Les retours d'expérience sont les bienvenus.
Cordialement

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 932
  • HO avec DCC++
    • Voir le profil
Une autre question plus d ordre implémentation à propos de la frequence d émission des messages que tu as mis sur 100 millis sec. ( 0.1 secondes)
Cette frequence parait très rapide de prime abord et on pourrait penser que 1/4 de seconde ( par exemple donc 0.25 secondes)  semblerait suffisant. Aussi pourquoi aller "aussi vite" dans l envoi des trames toutes les 100millis sec? N'émet t'on pas que ce qui as changé?

Qui peut le plus peut le moins. Cette fréquence est déjà celle des satellites V1. Si l'on peut fonctionner comme cela, c'est préférable. En effet, une détection ponctuelle par définition furtive peut "échapper".

J'ai fait le calcul que si le bus fonctionne à 1Mbps, que l'on a 25 satellites qui échangent des messages de 8 bytes de data avec un identifiant long de 29 bits, le bus était chargé tout au plus à 15-17 % de ses possibilités. Pourquoi se gêner !

C'est plus au niveau du récepteur que cela peut poser problème qui lui même peut "sauter des messages". Mais ce ne sera pas pire que de baisser la fréquence.
« Modifié: janvier 16, 2024, 10:22:28 am par bobyAndCo »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 932
  • HO avec DCC++
    • Voir le profil

Merci Michel aussi pour ta contribution. Voilà de nouvelles compétences ! Je précise que nous travaillons avec Michel à l'implémentation d'un protocole CAN au sein de LaBox pour la rendre elle aussi totalement intégrée à un réseau de satellites et de gestionnaire.

Blinder les câbles n'est une panacée : il faut gérer et éviter les boucles de masse.

Tu peux développer ?

laurentr

  • Hero Member
  • *****
  • Messages: 580
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #48 le: janvier 16, 2024, 10:31:33 am »
Hello

L I2C est plutôt économique avec les SX1509 et PCA9685 en regard des possibilités qu'ils apportent.

Pour le SX1509 la lib existe:
https://github.com/sparkfun/SparkFun_SX1509_Arduino_Library

Idem cote PCA9685 il y en plusieurs, donc voir c elle qui offre le plus de confort à l'usage.

A noter de suite que la puce SX travaille en 3v3 ( avec IO 5V tolérant) et la PCA en 5V, ceci imposera la présence d un "level shiftter" ( 4 résistances 10K et 2 Nmosfet type BSS138 par exemple) et des tensions adéquates aux abords.


On peut aussi les considérer selon leur usage comme des "extends" facultatifs avec une approche modulaire. ex Si pas de signaux car gare cachée, on n'équipe pas. ( besoin non nécessaire)
Si pour des raisons éco on doit étaler la dépense on équipe quand on est plus "argenté" ou pas exemple lorsque l'on met en place la signalisation... mais le cœur du dispositif est opérationnel sans les "extends" facultatifs.

Je peux regarder pour un ACS712 ou un cousin d ordre similaire à placer a coté de la détection RAILCOM.
Si je comprend l idée ses mesures permettraient de distinguer le passage de l'engin moteur sur une section mais aussi de déclencher des sécurités en cas de court circuit / dépassement de seuil ( Discussion que j avais eu avec Michel à l'expo de Gennevilliers en juin 2023)

D autres usages en vue?

Ltr

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 932
  • HO avec DCC++
    • Voir le profil
J ai une question d'ordre fonctionnel:

Dans le réseau de démo sur la TJS:
Si nous avons un train en mouvement sur C5 vers A1 qui est déviée alors le bloc agira et lorsque la loco se présentera dans C5 sur le capteur ponctuel d entrée, le ralentissement va s'opérer jusqu' à l arrivée sur le capteur de "sortie" proche de A1 ou s arrêtera le convoi (machine en tête ou en queue)

Toutefois que se passe t il si un engin est détecté sur la TJS alors que
le train n'est pas encore dans C5: ici le train sur la TJS ( et surement en mouvement entre  C2 ou C0) sera détecté par le capteur RAILCOM de C5, ne va t on pas alors arrêter le mauvais convoi? ( puisque c est l adresse de ce train qui va être associée au canton C5 car FIFO? ( First IN dans le satellite)
le train est dans C5: on a alors un imbroglio pour la lecture de l adresse RAILCOM car 2 engins ne peuvent emmètre en  même temps ( tout cela est peut être très théorique mais me semble être des combinaisons plausibles d'enchainements de différents mouvements).
J ose en déduire qu' il faut donc en principe que le train dans C5 s'identifie avant qu'une possible détection émettant sur la TJS ne vienne placer son adresse dans le satellite.
ou bien que la solution peut reposer sur une détection de présence seule (par conso de courant)  et non railcom sur une aiguille en pointe?

Alors déjà, un mouvement de C5 vers A1 ne me dit rien. Tout d’abord, on ne sait toujours pas laquelle est A1 et laquelle est A3. Pierre a posé la question plusieurs fois mais je crois toujours sans réponse.

Alors, s’agit il de C5 vers C1 via A1 ou de C5 vers C0 via A1 (ou A3 ?) ?

Je vais donc faire une réponse globale qui de toutes les façons vaudra quel que soit le cas :

Deux possibilités : La TJS isole de façon interne et selon la position de ses aiguilles C5 de C0 (et donc C6) ou pas.

Dans le premier cas, il n’y a pas d’interférence dans la détection Railcom donc pas de problème. Dans le second cas, il faut isoler par exemple C5/C1 la TJS. Il n’y a pas besoin de détection Railcom dessus, juste une détection par consommation de courant pour savoir si elle est occupée ou libre. Détection qui sera assurée par le satellite sur C0 ou C6 (très certainement C0 d'ailleurs).
« Modifié: janvier 16, 2024, 11:02:53 am par bobyAndCo »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 932
  • HO avec DCC++
    • Voir le profil
Je peux regarder pour un ACS712 ou un cousin d ordre similaire à placer a coté de la détection RAILCOM.
Si je comprend l idée ses mesures permettraient de distinguer le passage de l'engin moteur sur une section mais aussi de déclencher des sécurités en cas de court circuit / dépassement de seuil ( Discussion que j avais eu avec Michel à l'expo de Gennevilliers en juin 2023)

D autres usages en vue?

Ltr

Bien sûr qu'une détection "locale" apporterait beaucoup. Certainement en termes de latence et de précision. Et puis pourquoi stopper tout le réseau pour un court-circuit "local". En cas de détection, l'état du canton est placé à "busy" pour tous les autres et aucun train ne peut s'engager dessus.

Oui j'ai l'intuition qu'il y aura d'autres usages et je suis intéressé de savoir ce que Michel en pense. La lecture analogique peut nous renseigner sur la nature de la consommation (locomotive > xxxmA, wagon < yyy mA) etc...

laurentr

  • Hero Member
  • *****
  • Messages: 580
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #51 le: janvier 16, 2024, 11:02:12 am »
Pour préciser qui est A1 et A3 on prend le sens de circulation anti horaire de la "V1" et on incrémente les appareils de numéros impaires au fur et a mesure de leur introduction sur la "voie principale" dans le sens de circulation nominal (le plus souvent utilisé)

Donc A1 est la première lame de la TJS (la plus à gauche) A3 celle placée à droite

L'itinéraire "voie" principale favorise toujours un positionnement des lames en position directe (non déviée) ou par prise en talon d une aiguille ( pour Vmax)
Par principe sur une voie on ne trouve pas:
  • d aiguille triple (au moins en double voie et on évite en VU sauf ligne "secondaire")
  • la direction "droite" d une TJS / TJD est toujours celle qui est retenue
  • Si la géométrie des appareils le permet on peut passer une aiguille  "déviée" à une vitesse nominale (celle de la zone traversée  <= vitesse max de la ligne)  sinon réduite. ( et par principe réduite dans les autres cas)
Plusieurs vitesses sont possibles grâce au TIV (tableau indicateur de vitesse ex 70) sinon à la signalisation lumineuse par défaut ( Ralentissement 160, 60, 30,...)
[/list]

Ici V1 avec une circulation à gauche type SNCF tourne dans le sens anti horaire.
V2 dans le sens horaire.


Ltr
« Modifié: janvier 16, 2024, 03:43:52 pm par laurentr »

dmskd

  • Newbie
  • *
  • Messages: 45
  • Arduino et N
    • Voir le profil
@Dominique. Laurent répond bien à ta question. Moins on a de câbles sur le réseau et mieux c'est. Moins on a de longueur pour chaque câble et mieux.
Tout à fait d'accord, mais l'âge avançant très vite, moins on a d'équipements sous la table et mieux c'est.
Cordialement,
Dominique

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 932
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #53 le: janvier 16, 2024, 11:47:17 am »
Tout à fait d'accord, mais l'âge avançant très vite, moins on a d'équipements sous la table et mieux c'est.

C'est pour cela que j'ai placé les cartes en façade de mon réseau !



Mais aussi, nous allons faire en sorte de regrouper tout sur une seule et même carte.

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 932
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #54 le: janvier 16, 2024, 12:18:11 pm »
Retour à la présentation des satellites autonomes.

Dans un précédent post, nous avons vu les fichiers du programme. Je vais maintenant vous présenter les fichiers contenus dans le dossier data, dossier qui est copié en mémoire flash de l’ESP32.



Favicon.png est la petite image que vous avez dans les onglets du navigateur web. Vous pouvez la changer par une autre si vous le souhaitez.

Les fichiers index.html, scripts.js et w3.css sont les fichiers qui assurent le fonctionnement de la page web qui renseigne sur les liaisons du satellite avec ses voisins et permet différents réglages comme les buttées de servomoteurs.



Index.html, c’est la partie codée en HTML pour l’affichage de la page.

https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/data/index.html

Scripts.js, le code JavaScripts qui assure l’interactivité de la page, l’échange de données en entrée et en sortie avec le programme principal en C++.

https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/data/script.js

w3.css est une bibliothèque graphique pour enrichir le rendu visuel de la page : https://www.w3schools.com/w3css/w3css_examples.asp

Enfin, le fichier settings.json qui regroupe les informations de paramétrages spécifiques pour chaque satellites.

Voici une petite partie du contenu de ce fichier avant sa première utilisation. C’est un peu effrayant de prime abord, mais je vous rassure, vous n’avez que deux informations à renseigner. Pour toutes les autres, c’est le programme qui s’en chargera automatiquement à l’occasion du processus de découverte et pendant l’exploitation (position des aiguilles, locomotives présentes etc…).

"idNode":255,
"wifi_on":true,
"ssid":"xxxxxxxxxx",
"password":"xxxxxxxxxx",
"discovery_on":true,
"comptAig":0,
"masqueAig":0,
"p00":"null",
"p01":"null",
"p10":"null",
"p11":"null",
"m00":"null",
"m01":"null",
"m10":"null",
"m11":"null",

Mais il faut impérativement renseigner le « ssid » de votre box et son « password » en remplaçant « xxxxxxxxxx » et « yyyyyyyyyy » par vos propres valeurs.

Une fois cette modification réalisée une première fois, elle sera valable pour tous les satellites, vous n’aurez plus à vous en préoccuper.

L'intégralité du fichier settings.json est visible ici : https://github.com/BOBILLEChristophe/Satellites_autonomes_client/blob/main/data/settings.json

Voilà pour le contenu du dossier data à copier sur l’ESP32 en même temps que le programme principal.
« Modifié: janvier 16, 2024, 12:24:13 pm par bobyAndCo »

msport

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 2217
  • HO avec DCC++ en DIY Réseaux très éphémères
    • Voir le profil
Blinder les câbles n'est une panacée : il faut gérer et éviter les boucles de masse.

Tu peux développer ?

Un petit schéma ...

Si entre deux modules, on blinde le câble signal et que l'on raccorde des deux cotés le blindage à la masse on créé une boucle d'induction pour les champs parasites. On créé alors un courant de circulation qui développe un potentiel qui se superpose au signal.
Il est donc recommandé de ne mettre à la masse qu'un coté du blindage.
Cette solution simple sur le papier se révèle plus compliquée dans la réalité.
Cordialement

Remi

  • Newbie
  • *
  • Messages: 36
  • HO en 3 rails (Marklin)
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #56 le: janvier 16, 2024, 07:18:25 pm »
Bonjour Christophe, bonjour à tous,

Ci dessous un lien qui pointe vers un site sur la CEM (compatibilité électro magnétique) et qui explique entre autre la façon de raccorder les masses d'un câble blindé.
Dans le cas du schéma proposé (carte 1, liaison, carte2), il me semble qu'il faut raccorder la tresse du câble blindé aux 2 extrémités, car les 2 cartes sont elles même déjà relié à la masse par l'alimentation. En principe, l'impédance du câble de masse de l'alimentation étant inférieur à celle du blindage (section du câble d'alimentation plus forte, donc moins impédante), relier les 2 extrémités du blindage à la masse ne pose pas de problème pour ce cas précis.

Ceci n'est que mon humble avis et je peux me tromper !

https://www.tecnipass.com/cours-electronique.cem-cem.perturbations-cem.solutions?page=6

A+  Rémi
« Modifié: janvier 16, 2024, 07:21:32 pm par Remi »

Etienne66

  • Jr. Member
  • **
  • Messages: 97
    • Voir le profil
Bonjour Christophe, bonjour à tous,
 il me semble qu'il faut raccorder la tresse du câble blindé aux 2 extrémités, car les 2 cartes sont elles même déjà relié à la masse par l'alimentation. En principe, l'impédance du câble de masse de l'alimentation étant inférieur à celle du blindage (section du câble d'alimentation plus forte, donc moins impédante), relier les 2 extrémités du blindage à la masse ne pose pas de problème pour ce cas précis.

Ceci n'est que mon humble avis et je peux me tromper !

Non, c'est justement parce qu'elles sont déjà reliées qu'il ne faut pas les relier une seconde fois sinon tu crées la boucle.

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 932
  • HO avec DCC++
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #58 le: janvier 16, 2024, 07:39:40 pm »
Merci Remi,

Toutes ces contributions sont importantes. et même si elles peuvent présenter des inexactitudes elles ont le mérite de lever des questions qui trouveront j'en suis certain des réponse avec d'autres contributeurs. Et comme on le voit, ça aborde de vrais questions.

Bon, la bonne réponse semble t'il est arrivée pendant ma réponse !
« Modifié: janvier 16, 2024, 07:41:41 pm par bobyAndCo »

Remi

  • Newbie
  • *
  • Messages: 36
  • HO en 3 rails (Marklin)
    • Voir le profil
Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.
« Réponse #59 le: janvier 16, 2024, 09:12:57 pm »
Re,
Vous trouverez ci joint, uniquement à but d'information, un extrait d'un document de 2009 (voir la première page) qui explique pourquoi il est nécessaire de relier le blindage d'un câble aux deux extrémités. Ces règles sont toujours appliquées dans l'industrie des systèmes de télécommunications depuis plus de 30ans.
Après, je ne sais pas si cela éclaircira le sujet.
A+ Rémi