LOCODUINO

La carte Satellite V1

La carte Satellite V1 (1)

Principes fondateurs

.
Par : bobyAndCo, Dominique, Jean-Luc, Thierry

DIFFICULTÉ :

Début 2018, l’équipe qui anime LOCODUINO a entrepris de développer un démonstrateur de plusieurs technologies permettant la mise en œuvre de la gestion automatique d’un réseau DCC. Ce démonstrateur, le LOCODUINODROME [1], a été présenté au 16e salon international du train miniature à Orléans les 10 et 11 novembre 2018. Plusieurs éléments intéressants et réutilisables ont été développés et cette série d’articles se propose de présenter l’un d’entre eux, le Satellite V1, du point de vue des principes fondateurs d’abord, puis sa réalisation matérielle et logicielle, ainsi que son API pour l’intégration avec un gestionnaire de réseau.

Dans un réseau DCC piloté automatiquement, c’est à dire permettant de gérer le cantonnement en modulant la vitesse des locomotives, en commandant la position des appareils de voie et en pilotant une signalisation réaliste, il est nécessaire de combiner plusieurs éléments :

  • un système généralement centralisé qui, à partir des informations sur la position des engins roulants, sur la position des appareils de voie et sur une représentation informatique de la structure du réseau, va déterminer l’état des signaux et calculer les vitesses des locomotives. Appelons ce système « le Gestionnaire » ;
  • une électronique d’alimentation des rails et de commande des locomotives en DCC ;
  • une électronique et une mécanique de commande des appareils de voie (aiguillages, TJS, TJD) ;
  • une électronique de commande des signaux (lumineux, mécaniques) ;
  • une électronique de détection de la présence des engins roulant en des points stratégiques du réseau (rétrosignalisation).

Choix de l’architecture électronique

Traditionnellement dans un système DCC, l’électronique de commande des appareils de voie et des signaux est également connectée au bus DCC. Ces dispositifs sont donc équipés de décodeurs qui fonctionnent sur un principe similaire à ceux des locomotives. Et, par conséquent, les ordres de positionnement de ces équipements sont donc également transmis via des trames DCC.

Le bus DCC étant unidirectionnel [2] la transmission des informations de détection nécessite un second bus, le S88 en est un exemple.

Ces différentes électroniques sont distinctes. Il faudra généralement un boitier pour piloter quelques appareils de voie, un boitier pour piloter quelques signaux, un boitier pour détecter la présence par consommation de courant, un boitier pour détecter la présence par barrière infrarouge, etc. Le résultat est que le coût financier devient rapidement important et que la densité de l’électronique et du câblage croît également rapidement.

On voit donc que des dispositifs électroniques dédiés à une seule fonction, commande de servomoteurs, commande de signaux, etc, ne sont peut-être pas la meilleure solution, même si cette fonction est implémentée plusieurs fois (4 fois le plus souvent). De plus, ces technologies ont relativement peu évolué depuis une quarantaine d’années et elles peuvent aujourd’hui être avantageusement supplantées par les équipements disponibles en DIY.

Lors de nos réflexions, nous avons conclu qu’il était préférable de réunir plusieurs fonctions sur une seule carte électronique. Cette dernière pourrait à la fois piloter des signaux et des appareils de voie et aussi détecter la présence des engins roulant. Il était aussi très intéressant d’avoir, autant que faire se peut, un seul type de carte qui soit configurable pour s’adapter à un grand nombre de situations. L’idée de la carte Satellite était née.

Le bus DCC quant à lui, si il est indispensable au pilotage des locomotives, peut avantageusement être remplacé par un bus bidirectionnel servant à la fois à la commande et à la rétro-signalisation. Le bus CAN, déjà présenté dans Locoduino, est un bus industriel largement déployé dans différent domaines comme l’automobile, l’avionique ou le spatial. C’est un choix naturel pour plusieurs raisons :

  • la disponibilité de contrôleurs bon marché qui s’interfacent à l’Arduino sur le SPI ;
  • un débit, de 125kbits/s à 1Mbits/s, très suffisant même pour un grand réseau ;
  • la capacité de connecter jusqu’à 112 nœuds sur le même bus.
  • la robustesse de la communication avec l’incorporation de code de correction d’erreur permettant de détecter jusqu’à 5 erreurs de transmission [3] dans une trame ; le contrôleur procédant à la re-émission de manière autonome ;
  • la facilité de mise en œuvre et la disponibilité de bibliothèques matures ;
  • le mode de communication par diffusion qui permet d’ajouter facilement des dispositifs, comme un TCO, sans construire une communication dédiée à ce dernier.

L’architecture générale

L’architecture générale de l’électronique d’un réseau ferroviaire représentée à la figure 1 sépare, en bas, ce qui touche au réseau (engins roulant, actionneurs et détecteurs) de ce qui touche au pilotage, en haut, dont les 3 blocs (poste de conduite, TCO et gestionnaire) peuvent être combinés de différentes manières, ce qui n’est pas le sujet de cette série d’article mais qui représente ce que nous avons mis en œuvre à Orléans.

Figure 1 : Architecture du Locoduinodrome
Figure 1 : Architecture du Locoduinodrome

Le bus CAN (filaire) interface le haut et le bas, avec, optionnellement une couche TCP (WiFi (sans fil) ou Ethernet (filaire)).

Communication : événements ou états ?

Sur une architecture distribuée comme celle que nous vous présentons, on peut communiquer de deux manières et pour illustrer ceci nous allons considérer la communication entre le Gestionnaire et un Satellite pour la manœuvre d’une aiguille et la communication inverse pour que le Satellite rende compte au Gestionnaire de la position effective de l’aiguille.

La première manière consiste à réaliser une communication ponctuelle qui n’est réalisée que lorsqu’il y a un changement d’état (considéré donc comme un événement) : le Gestionnaire désire que l’aiguille change de position et il envoie donc de manière ponctuelle cette demande, via le réseau, au Satellite qui manœuvre l’aiguille. En retour, le Satellite envoie un acquittement lorsque l’aiguille s’est effectivement déplacée.

La seconde manière consiste à réaliser une communication via des états et de manière répétitive. Dans ce cas, le Gestionnaire communique de manière périodique l’état désiré de l’aiguille et le Satellite responsable de l’aiguille reçoit périodiquement cet état et la manœuvre de manière à ce que sa position corresponde à l’état. De la même manière, le dispositif émet périodiquement l’état de l’aiguille. On parle également de communication par variables rafraichies.

La première manière a l’avantage de la sobriété, deux messages seulement sont échangés mais elle possède également deux sérieux inconvénients :

  1. si un message est ponctuellement perdu, l’ordre sera perdu. Il faudra donc gérer cela du côté du Gestionnaire : vérifier que les messages d’acquittement sont arrivés, mettre en place un mécanisme de time-out pour émettre de nouveau le message après un certain temps sans acquittement, etc ;
  2. si un Satellite est débranché puis branché ou s’il est redémarré pour une raison quelconque, par exemple parce qu’on vient de flasher une nouvelle version du logiciel, il faudra émettre de nouveau tous les messages permettant de le remettre dans l’état où il était avant d’être redémarré.

On voit là tout l’intérêt du second mode de communication : les variables d’états représentant l’état du réseau : position des aiguilles, occupation et feux, sont diffusées périodiquement. Si un message est perdu ponctuellement, cela ne se traduira que par un petit retard dans l’actualisation de l’état global et le message suivant remettra les choses en ordre. Si l’un des dispositifs est redémarré, il réacquiert automatiquement son état et débrancher ou redémarrer un Satellite peut se faire à chaud et sans complication.

Bien évidemment ceci a un coût en communication mais ce coût reste raisonnable. Prenons par exemple 100 Satellites sur un bus CAN permettant de communiquer à 100m de distance avec un débit de 500kbits/s. Deux messages d’états transitent entre le Gestionnaire et chaque Satellite. Dans le pire cas, c’est à dire en considérant des trames CAN de longueur maximum, ces deux messages additionnés occupent le bus 540µs et par conséquent, la communication entre le Gestionnaire et 100 Satellites nécessite 54ms. On voit donc que la marge est confortable.

Le principe d’indépendance (relative) des entités du système de pilotage

On peut déduire de la figure 1 que chaque entité fait son travail dans son coin c’est à dire réalise des actions en fonctions des états reçus d’une autre entité et ces actions engendrent des changements d’état qui sont envoyés à d’autres entités.

  • la centrale DCC génère le signal DCC pour la traction (vitesse, direction) et les fonctions des engins roulant sur les voies. Elle reçoit les états désirés des locomotives du gestionnaire et les traduit en commandes DCC quand c’est le gestionnaire qui commande les locomotives. Elle envoie les états des commandes des opérateurs au gestionnaire quand cette centrale dispose de ses propres manettes : on parle de souhaits de vitesse dans ce cas et on peut se trouver en mode double commande. Si la centrale gère les accélérations et les ralentissements, il est indispensable que le gestionnaire connaisse la vitesse réelle à tout instant ;
  • le TCO affiche une représentation graphique du réseau, des appareils de voie et des engins roulants à partir des états des capteurs : détection d’occupation, franchissement de balise et position effective des aiguilles, transmis par les Satellites d’une part et l’état voulu des aiguilles et l’état des feux transmis par le Gestionnaire d’autre part ;
  • le Gestionnaire possède une modélisation du réseau et maintient un ensemble de paramètres décrivant l’état de tous les éléments (occupations, libérations, états des aiguilles, itinéraires, état des trains, etc..). Il commande les appareils de voie et la centrale DCC pour assurer la sécurité. Il gère les signaux. Il reçoit les états de tous les appareils et émet les états souhaités ;
  • le poste de pilotage anime une interface utilisateur de commande d’un ou plusieurs trains (manette, curseur, ..) et affiche le signal vu par le conducteur en bout de canton. Il est donc piloté par le Gestionnaire et lui envoie des souhaits de vitesse de train ;
  • Chaque Satellite, enfin, lit les capteurs qui lui sont associés, émet les états correspondant, reçoit les états souhaités des aiguilles et des feux du Gestionnaire et manœuvrent les aiguilles et les signaux en fonction.

Bien entendu il n’y a pas une seule forme de réalisation imposée de chaque entité, à part le fait qu’elle embarque au moins un Arduino et un programme. Il peut exister dans cette architecture plusieurs formes de réalisation de centrale DCC, de gestionnaire, une seule de chaque en principe, mais plusieurs possibles de TCO, de poste de conduite et de satellites.

Nous avons voulu garder toute la souplesse de réalisation qui permette de choisir sa façon de réaliser chaque entité.

Mais surtout, nous avons une architecture matérielle distribuée qui permet de minimiser le nombre de fils à brancher. Idéalement les seuls fils à courir le long du réseau sont :

  • le feeder du DCC ;
  • le CAN ;
  • l’alimentation 9V.

Tous les autres fils : capteurs, actionneurs, doivent être le plus court possible pour que l’architecture matérielle soit la plus claire possible comme montré à la figure 2.

Figure 2 : Allocation des Satellites sur le Locoduinodrome
Figure 2 : Allocation des Satellites sur le Locoduinodrome
Les Satellites sont figurés par des rectangle verts. Ils sont reliés par le bus CAN et sont connectés à des détecteurs de consommation de courant

, des balises de détection ponctuelles

, des signaux

ou

et des aiguilles

.

Les satellites - principes généraux

Hormis l’idée de faire du Satellite une carte multi-usages, nous avons voulu dès le départ fixer les principes suivants :

  • tous les satellites sont identiques sur le plan matériel (même schéma, mêmes composants). Ils sont placés topologiquement à proximité des appareils à gérer (aiguilles, capteurs, signaux) et selon le nombre et la nature des appareils, un Satellite peut se trouver sous-utilisé ;
  • tous les satellites sont chargés avec le même logiciel pour éviter les erreurs en téléversant un programme unique (seul le numéro du satellite est personnalisé au démarrage) ;
  • comme ils ne sont pas spécialisés, ni sur le plan matériel, ni sur le plan logiciel, mais que leurs fonctions sont hétérogènes, leur spécialisation est faite par le gestionnaire, via le bus CAN. Ces satellites sont des entrées/sorties déportées. Nous avons donc une architecture matérielle extensible à volonté ;
  • pour les gérer, une API sur le gestionnaire définit un ensemble d’objets. Ces objets représentent les objets physiques du réseau (zones, aiguillages, feux, comme des proxy). La façon dont ces objets communiquent avec les nœuds sur le réseau CAN n’est pas du ressort du gestionnaire, il ne voit que l’API Cette même API pourrait servir pour les autres moyens de contrôle du réseau. ;
  • la correspondance entre les entrées-sorties des satellites et les équipements de voie est totalement libre : c’est à dire, par exemple, qu’un feu à 9 ampoules pourrait être géré par 2 Satellites, l’un pour 4 ampoules, l’autre pour 5. Le fait de le voir comme une entité unique est de nature logicielle dans l’API, mais non matérielle ;
  • pas de configuration dans les satellites, ce qui élimine une grande partie de la complexité ;
  • on déploie les satellites sur le réseau ce qui donne un certain nombre de branchements pour les servos, les feux (plusieurs feux par nœud éventuellement) et on branche au plus court. Que telle ou telle LED appartienne à un signal ou à un autre n’est qu’une question de configuration du logiciel qui tourne avec le gestionnaire ;

Les avantages de cette architecture sont multiples :

  • chaque satellite n’a plus à connaître la notion d’objets aiguille, zone ou signal. Il gère seulement des ports. Il synchronise son état régulièrement avec des tables dans le gestionnaire via les messages périodiques qui circulent sur le CAN (dans les 2 sens) ;
  • la spécialisation des feux au niveau d’un satellite n’a pas lieu d’être. Un satellite c’est uniquement des LEDs avec 3 modes : allumé, éteint, clignote. Il n’y a pas de notion de signal dans un satellite. La notion de signal est dans l’API coté gestionnaire et dans la couche qui va traduire l’état d’un signal en états de LED ;
  • tous les types possibles de cibles sont possibles avec cette carte. Les LEDs des signaux sont toutes banalisées : elles auront toutes la même résistance série, l’intensité du signal étant réglée par PWM ;
  • l’application gestionnaire n’a pas à connaitre les formats des messages qui transitent sur le CAN, c’est du ressort de l’API uniquement.

Les évolutions

Cette première version, mise en œuvre sur le démonstrateur présenté à Orléans a permis de montrer la pertinence de l’approche. Mais elle a également été conçue à l’aune du Locoduinodrome et est donc perfectible. Notamment le choix de n’avoir qu’un seul servo et qu’une seule détection par consommation, si elle est adaptée au Locoduinodrome, présente des limites pour des réseaux plus complexes et conduit à un nombre de Satellites excessif et dont une partie des fonctions est inutilisée. Nous avons d’ores et déjà commencé à travailler sur une version 2 plus modulaire et permettant de limiter au minimum les fonctions non utilisées et de rendre le Satellite adaptable au plus grand nombre de situations. Elle disposera également de la possibilité d’identifier (et plus seulement détecter) des locomotives (et/ou des wagons) avec la technologie RFID. Cette seconde version nécessite une configuration qui est la conséquence de la modularisation. En effet, plusieurs fonctions mutuellement exclusives étant possibles, il faut décider de la fonction utilisée.

[1Contraction de LOCODUINO et de LOCODROME

[2Principalement unidirectionnel. On peut envisager de transmettre des informations vers la centrale en associant aux bits 0 et 1 une consommation plus ou moins élevée du dispositif émetteur mais ce mode de fonctionnement est réservé à la programmation des décodeurs, un seul à la fois sur voie de programmation. Il ne peut pas être utilisé pour la rétrosignalisation. Une seconde façon de faire est d’implémenter un système client-serveur où la centrale (le client) interroge un décodeur (le serveur) puis coupe le signal DCC. Le décodeur qui dispose d’une réserve d’énergie pour un court instant, répond sur le bus DCC. Ce système est connu sous le nom de Railcom. Ici aussi le débit est faible.

[35 bits qui auraient une valeur erronée

34 Messages

  • La carte Satellite V1 19 janvier 2019 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 !

    Répondre

    • La carte Satellite V1 19 janvier 2019 20:25, par Jean-Luc

      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.

      Répondre

  • La carte Satellite V1 20 janvier 2019 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

    Répondre

    • La carte Satellite V1 21 janvier 2019 13:04, par Jean-Luc

      Merci Patrick.
      La suite arrive et en parallèle, je mettrai des infos sur la Satellite V2 sur le forum.

      Répondre

  • La carte Satellite V1 21 janvier 2019 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 !

    Répondre

  • La carte Satellite V1 21 janvier 2019 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.

    Répondre

    • La carte Satellite V1 21 janvier 2019 23:07, par Jean-Luc

      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.

      Répondre

      • La carte Satellite V1 22 janvier 2019 18:04, par Charles

        55% de la RAM est occupée pour un sketch qui ne fait quasiment rien.

        Inconvénient rédhibitoire ! On oublie PJON :D

        Comment avez-vous réaliser l’interface CAN ? Du fait maison ou un carte toute assemblée ?

        Répondre

  • aaah, enfin ! 21 janvier 2019 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 !!

    Répondre

    • aaah, enfin ! 22 janvier 2019 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 :)

      Répondre

      • aaah, enfin ! 22 janvier 2019 18:15, par railyRabbit

        "perplexe" dans le sens... mais comment cela fonctionne-t-il donc ? ;)

        Répondre

        • aaah, enfin ! 22 janvier 2019 19:20, par Dominique

          Bonjour,

          Vous le saurez bientôt avec les articles suivants ;)

          Répondre

  • La carte Satellite V1 26 janvier 2019 21:14, par jerome

    Très bon article, merci. Où peut-on trouver des infos sur l’interface DCC/CAN ?

    Répondre

  • La carte Satellite V1 8 février 2019 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

    Répondre

  • La carte Satellite V1 7 juillet 2019 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

    Répondre

    • La carte Satellite V1 8 juillet 2019 18:06, par Dominique

      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.

      Répondre

    • La carte Satellite V1 9 juillet 2019 09:08, par Jean-Luc

      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.

      Répondre

  • La carte Satellite V1 10 novembre 2021 12:06, par Dominique (mais pas celui de Locoduino)

    Bonjour,

    Cet article parle d’une évolution de la version V1 ("Nous avons d’ores et déjà commencé à travailler sur une version 2").
    Serait-il possible de savoir où en est cette version ?

    Cordialement,
    Dominique

    Répondre

    • La carte Satellite V1 10 novembre 2021 17:19, par msport

      Bonjour,
      la V2 est en statut quo actuellement, mais pouvez vous préciser ce que vous attenteriez ?
      Cordialement

      Répondre

  • La carte Satellite V1 11 novembre 2021 09:05, par Dominique

    Je voulais savoir si vous aviez évolué concernant votre réflexion suivante :

    "le choix de n’avoir qu’un seul servo et qu’une seule détection par consommation, si elle est adaptée au Locoduinodrome, présente des limites pour des réseaux plus complexes et conduit à un nombre de Satellites excessif et dont une partie des fonctions est inutilisée (...) Nous avons d’ores et déjà commencé à travailler sur une version 2 plus modulaire et permettant de limiter au minimum les fonctions non utilisées et de rendre le Satellite adaptable au plus grand nombre de situations"

    Répondre

    • La carte Satellite V1 11 novembre 2021 09:24, par msport

      Bonjour,
      En fait, le faible cout d’un satellite ne plaide pas pour une spécialisation de ceux-ci pour en diminuer le nombre.
      Quel nombre de satellites envisagez vous dans sa version actuelle ?
      Cordialement

      Répondre

  • La carte Satellite V1 11 novembre 2021 19:26, par Dominique

    Aucune idée pour le moment.
    Je commence juste à réfléchir à un futur réseau et à la meilleure façon de l’exploiter.
    Merci pour vos réponses.
    Cordialement,
    Dominique

    Répondre

  • La carte Satellite V1 11 novembre 2021 19:43, par Dominique

    Ce qui est indiqué dans l’article est toujours vrai (optimiser les ressources et combiner les fonctions au plus près des besoins est une de nos préoccupations de modéliste ferroviaire).
    Mais le lancement d’une réalisation avec les nécessaires discussions avec les bénéficiaires potentiels (comme on l’a fait pour la V1) demande un investissement en temps et en moyens important. A cela s’ajoute un logiciel modulaire et paramètrable qui n’est pas simple à faire.
    Nous n’avons donc pas encore pris de décision surtout faute d’engagements sérieux des utilisateurs de Locoduino. Mais cela viendra peut-être un jour..

    Répondre

  • La carte Satellite V1 15 novembre 2021 19:00, par Dominique

    Bonjour,
    Les messages gérés par les satellites sont parfaitement décrits dans le très intéressant article "La carte Satellite V1 - La messagerie et l’interface SAM V1", mais trouve-t-on quelque part une description des messages CAN entre le Système de gestion et le module Traction présents dans l’architecture du Locoduinodrome présentée ci-dessus ?
    Cordialement,
    Dominique

    Répondre

  • La carte Satellite V1 15 novembre 2021 21:51, par Dominique

    Oui ça existe chez moi dans doute, je vais rechercher et le publier ;)

    Répondre

  • La carte Satellite V1 18 juillet 2022 19:22, par Olivier

    Bonjour,
    Tout d’abord bravo pour cette mine d’informations qu’est Locoduino, et la haute tenue de certains articles, c’est parfois (souvent !) impressionnant. On imagine la quantité de travail pour arriver à cette qualité !

    Après avoir vu l’excellent article "Communications entre JMRI et Arduino" où je me suis frotté les mains en voyant l’intégralité d’un système de gestion quasiment clés en main, je découvre ce concept de carte satellite qui simplifie drastiquement la quantité de filasse...et j’ai tout de suite été conquis, sachant que n’ayant encore rien commencé, je me suis dit qu’il valait mieux partir sur les meilleures bases possibles :)

    Seul hic : a contrario du premier article où la passerelle entre JMRI et le réseau est déjà écrite, il faut ici entièrement créer la passerelle CAN/Gestionnaire...Ben oui, c’est qu’on prend vite l’habitude dans vos projets d’avoir tout le travail prémâché, aussi... :)

    Je pressens (peut-être à tort) que le code de la carte passerelle Arduino ne devrait pas être trop complexe, en s’inspirant de celui de la carte satellite pour la partie CAN et en écrivant un peu de code pour adapter les messages au protocole d’échange avec le gestionnaire.

    Le code côté gestionnaire me semble par contre une toute autre affaire, et d’ailleurs quel gestionnaire choisir ?

    JMRI ? Il faut maîtriser son environnement Java/Python...ce qui n’est pas mon cas, je ne comprends déjà pas toutes les subtilités du code Python tout fait de Geoff Bunza qui utilise deux ports COM distincts, alors, même en s’en inspirant, je me vois mal écrire un protocole de communication qui soit capable d’envoyer les ordres et recevoir les signaux sur le même port :(

    CDM-Rail ? il est - sauf erreur de ma part - basé sur l’activation d’accessoires via le DCC, pas vraiment adapté à l’approche bidirectionnelle (qui en fait d’ailleurs tout le charme !) de la solution Satellite/CAN

    Gestionnaire maison basé sur Processing ? beaucoup de travail en vue, mais peut-être plus facile à appréhender au final, partant du principe qu’on maîtrise mieux ce qu’on crée de bout en bout...

    Bref, étant très perplexe sur la direction à prendre, quelques petites pistes sur ce que vous avez utilisé lors de votre démo d’Orléans, et quelques conseils pour éviter de partir sur une route semée d’embûches, ne seraient pas de refus :)

    Répondre

  • La carte Satellite V1 18 juillet 2022 19:49, par Dominique

    Merci pour cette bonne question : je partage votre préoccupation depuis longtemps et je réalise un gestionnaire connecté au bus Can, sans pc/Mac.

    il est basé sur le projet “Un gestionnaire en C++ pour votre réseau (1/2/3/4) 100% Arduino” développé par Pierre59.

    Bien sûr il est largement adapté aux caractéristiques de mon réseau et n’utilise pas que des satellites V1.
    Voir mon projet “Réseau Dominique” dans le forum où on pourra en discuter.
    Cordialement.

    Répondre

  • La carte Satellite V1 18 juillet 2022 19:56, par bobyAndCo

    Bonjour,

    Très heureux que vous appréciez ce concept qui est il est vrai assez révolutionnaire. Tout comme Dominique, je vous invite à me contacter par MP car je pourrai vous parler d’une évolution sur laquelle je travaille et qui simplifie beaucoup le gestion de réseau.

    Bien cordialement.

    Christophe

    Répondre

  • La carte Satellite V1 18 juillet 2022 21:24, par Dominique

    Je vous encourage à contacter Christophe qui va pouvoir offrir une approche plus simple à configurer et qui peut être complétée selon vos desiderata.
    Cordialement.
    Dominique

    Répondre

Réagissez à « La carte Satellite V1 (1) »

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)

Rubrique « Projets »

Les derniers articles

Les articles les plus lus