La carte Satellite V1
Principes fondateurs
. Par : , , ,
Vous répondez à :
J’attendais avec une certaine impatience que vous rentriez dans le détail de cette carte et des principes de fonctionnement.
Cette notion de ’non-spécialisation’ des cartes, et donc de configuration à distance par le gestionnaire, me laisse perplexe. J’ai commencé à dessiner ma carte mais pour ma part, je pense que j’adapterai le programme selon le nœud (du moins dans la 1ère version).
Hâte de lire la suite !!
22 Messages
-
La carte Satellite V1 19 janvier 14:06, par Tanguy
Encore bravo pour ce travail extraordinaire. Je suis très inspiré par ce principe de carte banalisée (la Locoduino Uno ?) et pense le mettre en oeuvre un jour sur mon réseau. Je pense avoir compris la notion d’API mais ne comprend pas celle de "proxy".
Les prochains ? articles me permettront probablement d’y voir plus clair.Longue vie à Locoduino !
-
Merci Tanguy :)
Il y a 3, voire 4, autres articles à venir qui sont en court d’écriture. Et cette notion de proxy y sera expliquée.
-
-
La carte Satellite V1 20 janvier 15:58, par Patrick
Merci à toute l’équipe de mordus pour la qualité des articles et le travail accompli.
Je suis en train de réaliser un projet dans lequel je souhaite mettre en œuvre les cartes satellite, aussi je suis impatient de découvrir les prochains articles en particulier les cartes version V2 qui permettront d’en limiter la quantité.
Bravo Locoduino-
Merci Patrick.
La suite arrive et en parallèle, je mettrai des infos sur la Satellite V2 sur le forum.
-
-
La carte Satellite V1 21 janvier 13:31, par Pierre
Je me joins à Tanguy et Patrick pour vous féliciter à mon tour ! L’article est très bien écrit. J’ai tout compris malgré mes faibles connaissances en la matière (je ne connaissais même pas l’existence des cartes Arduino il y a 3 mois…). Je suis en train de réfléchir à l’implantation d’un nouveau réseau et j’envisage de suivre cet exemple. Je me réjouis de lire les articles suivant sur ce sujet !
-
Merci Pierre :-)
-
-
La carte Satellite V1 21 janvier 22:16, par Charles
Bonjour,
Je suis depuis quelques temps les articles publiés sur Locoduino et le vôtre m’a particulièrement intéressé. Je travaille également sur la réalisation d’un système de commande des équipements et des capteurs utilisés dans un réseau de trains. Mais cela traine depuis des mois faute de temps …Je suis parti sur un système similaire à celui présenté dans l’article, à savoir au centre un ordinateur avec un programme serveur chargé de la supervision du système et de l’exploitation des convois. Ce programme propose d’un côté d’un service HTTP afin de pouvoir communiquer avec un navigateur web où se trouve l’IHM pour la configuration et l’exploitation du réseau (dont le TCO). Une application Web a l’avantage de tourner sur toutes les plate-formes (Mac, Linux, Windows, iOS, Android, …) De l’autre côté, grâce à un carte maître Arduino connectée en USB ou une ESP8266 en WiFi, le serveur peut envoyer des commandes à des cartes esclaves et recevoir les signaux des détecteurs.
Pour le bus entres les cartes maître et esclaves j’étais également parti sur du CAN mais j’ai découvert il y a quelques mois le bus PJON qui me semble plus simple à mettre en oeuvre.
Pour la programmation des cartes esclaves, je pensais à des application spécialisées (pilote de signaux, pilote de moteurs d’aiguille et récepteur des signaux de détection). Mais le principe de l’application unique me plait et il n’y a pas d’inconvénient à déplacer l’« intelligence » du système sur le serveur.
Pour piloter les LED des signaux, je suis en train d’essayer les registres à décalage 74HC595 qui permet de piloter 8 feux par circuits et qui sont chaînables pour arriver à piloter 8, 16 ou plus LED. Donc en « consommant » seulement 5 ports digitaux de l’Arduino on peut piloter deux ou trois signaux.
Merci pour cette première approche et j’attends avec impatience la suite de la présentation de vos travaux.
-
Bonsoir,
j’ai rapidement jeté un œil à PJON. Il s’agit d’un protocole et non d’un bus. Je ne trouve pas qu’il soit particulièrement facile à mettre en œuvre à priori et je n’ai pas trouvé d’exemple qui me semble facilement compréhensible pour démarrer. Je trouve le CAN plutôt limpide en comparaison et il offre un matériel qui gère tout le protocole.
Le défaut principal est que tout est implémenté en soft et que je ne vois pas quel hardware mettre dessous. Le problème est que le protocole à une empreinte mémoire assez conséquente et que le temps CPU pour la stack ne sera pas là pour autre chose. À vrai dire nous visons une empreinte mémoire quasi nulle en RAM en employant un autre contrôleur CAN, le MCP2517FD qui contient 2ko de buffer, dans la version 2.
Enfin, quand je lis sur l’accueil du Github :Many protocols massively applied worldwide like 1-Wire, i2c and CAN expose dangerous vulnerabilities, their error detection algorithms are weak and they are not resilient to interference. The PJON network protocol stack is based on years of analysis and study not to make the same repeated mistakes present in most alternatives and provide with a set of simpler and more efficient solutions.
sans que rien ne soit avancé à l’appui ce ces affirmations, je ne sais pas quoi penser de PJON.
Pour compléter : je viens d’installer PJON et de compiler le sketch Receiver qui allume ou éteint la LED 13 en fonction de ce qui est reçu. 55% de la RAM est occupée pour un sketch qui ne fait quasiment rien. Ce n’est tout simplement pas utilisable sur un Nano.
-
-
aaah, enfin ! 21 janvier 22:28, par railyRabbit
J’attendais avec une certaine impatience que vous rentriez dans le détail de cette carte et des principes de fonctionnement.
Cette notion de ’non-spécialisation’ des cartes, et donc de configuration à distance par le gestionnaire, me laisse perplexe. J’ai commencé à dessiner ma carte mais pour ma part, je pense que j’adapterai le programme selon le nœud (du moins dans la 1ère version).
Hâte de lire la suite !!-
aaah, enfin ! 22 janvier 06:56, par Jean-Luc
Bonjour,
Cette notion de ’non-spécialisation’ des cartes, et donc de configuration à distance par le gestionnaire, me laisse perplexe.
C’est pourtant ce que nous avons fait pour Orléans. Dominique a fait un configurateur avec un Arduino et bobyAndCo dans un navigateur Web :)
-
aaah, enfin ! 22 janvier 18:15, par railyRabbit
"perplexe" dans le sens… mais comment cela fonctionne-t-il donc ? ;)
-
aaah, enfin ! 22 janvier 19:20, par Dominique
Bonjour,
Vous le saurez bientôt avec les articles suivants ;)
-
-
-
-
La carte Satellite V1 26 janvier 21:14, par jerome
Très bon article, merci. Où peut-on trouver des infos sur l’interface DCC/CAN ?
-
Hmmm … Pour quel usage ?
-
-
La carte Satellite V1 8 février 12:23, par DDEFF
Cette série d’articles promet d’être passionnante.
Ayant prêché depuis longtemps pour des fils courts vers ce que j’appelais des "modules", je n’en suis que plus heureux.
Il fallait une carte satellite V1 "à tout faire" pour démarrer le processus et tester un maximum de cas et, qu’au moins, ça marche sur un petit réseau. C’est fait et c’est très bien.
Dans le cas de réseaux plus grands, et, au hasard (!), une grande gare en PRS, il faudra des satellites qui sachent s’adapter à
N*(1 aiguille+1 détection) pour un Arduino pour optimiser le nombre de satellites. J’ai bien compris que c’était en cours.
Et, comme il faut bien que Locoduino ait aussi des gestionnaires pour s’adapter à ce bus, je ferai bientôt partie de ceux qui proposeront leur système.
Denis -
La carte Satellite V1 7 juillet 23:11, par Cyril
Bonsoir,
Je n’ai pas tout compris (débutant) donc pardon d’avance si je pose une question idiote !
Je suppose qu’il est nécessaire de séparer électriquement les cantons les uns des autres afin de pouvoir y mesurer la consommation de courant ?
Donc pouvez-vous me préciser la manière dont le feeder DCC est géré (d’un point de vue électronique) sur chaque canton dans votre projet LOCODUINODROME ?
Pourquoi ne pas faire passer le feeder dcc par la carte satellite ?
Merci d’avance
-
Bonjour Cyril,
Je suppose qu’il est nécessaire de séparer électriquement les cantons les uns des autres afin de pouvoir y mesurer la consommation de courant ?
OUI.
préciser la manière dont le feeder DCC est géré
Le signal DCC est appliqué en sortie de centrale à une ligne de 2 fils, le feeder, qui coure sous le réseau. Les satellites sont connectés en entrée au feeder en parallèle. Chaque satellite V1 est connecté aux rails d’un canton pour qu’il puisse mesurer le courant.
-
Les cantons sont-ils alimentés en permanence ?
-
La carte Satellite V1 10 juillet 06:30, par Dominique
Oui les cantons sont alimentés en permanence.
-
-
-
Bonjour
Pourquoi ne pas faire passer le feeder dcc par la carte satellite ?
Parce que les pistes du premier satellite de la chaîne devraient encaisser l’intensité de la totalité des cantons.
-