Messages

61

Modélisation, Architectures logicielles et matérielles / Re : Re : DCC : Détection par consommation avec des courants faibles

« le: février 29, 2024, 09:04:06 pm »

Je pense que tu pourrais laisser le CPU sur le 5V au lieu du 3v3 ( venant de l ESP). voir dans ce cas tirer le 5v du régulateur en place.

Possible mais :
- Je n'ai pas fait le bilan de puissance du L7805. Il me paraît un peu léger. A faire.
- Si j'alimente l'ensemble du montage en 5V il faut que j'interface la sortie de l'ATTiny pour rendre le signal envoyé sur 33 de l'ESP32 pour ne pas dépasser 3,3V. D'où un circuit en plus.

Il n'y a pas de pbme avec le convertisseur de 5V de la carte, il débite 1A et il n'y a rien sur le satellite qui consomme. Quant à abaisser à 3,3v pour entrer dans l'ESP, je croyais que tu avais mis un pont diviseur ?

Tu peux ajouter au besoin les connecteurs de PROG pour le CPU si on veut le mettre à jour in situ ou si c est un composant CMS. ( il peut être substituable par un ARTINY202 ou 402 par exemple) ( brochage a vérifier)

Ca va charger la carte pour peu d'usage. Perso. je préconiserai un support.

Je te rejoins sur ce point

Peut être aussi ajouter une résistance talon sur la partie variable afin de ne pas avoir un seuil trop haut au cas où.

D'accord. Mais à vous de me dire la valeur après essais.
N'oubliez pas les différentes échelles HO et N dans vos essais.

Je ne sais pas de quoi on parle, jocker !

Toutefois dans ce montage la détection de conso qui va assurer la protection est  après la mesure railcom.
Il semble que LENZ procède à l'inverse et donc il faudrait alors plutôt positionner l'AS103 en amont de la mesure railcom cote source DCC.

C'est un sujet maintes fois discuté mais jamais expliqué techniquement. Les raisonnements se basent uniquement sur ce que semble faire LENTZ.
Pour ma part je privilégie une coupure au plus près du CC, et la mesure de courant est ainsi débarrassée du régime transitoire des alimentations lors de la remise en tension de la voie.
Tout risque d'interférence entre les circuits Railcom et la mesure d'intensité est ainsi écarté. Toujours positionner le capteur au plus près du défaut probable, principe d'AMDEC (Analyse de Modes de Défaillances de leur Effets et de leurs Criticité).

Bref à valider expérimentalement...

CQFD

62

Modélisation, Architectures logicielles et matérielles / Re : Re : DCC : Détection par consommation avec des courants faibles

« le: février 29, 2024, 06:03:08 pm »

Je pense que tu pourrais laisser le CPU sur le 5V au lieu du 3v3 ( venant de l ESP). voir dans ce cas tirer le 5v du régulateur en place.

Bien vu Laurent pour le 5v. Et je pense que c'est aussi le cas pour le relais et tant qu'à faire aussi la LED qui est reliée au relais.

Il semble que LENZ procède à l'inverse et donc il faudrait alors plutôt positionner l'AS103 en amont de la mesure railcom cote source DCC.

Nous avons convenu avec René que je vais tester cela en rentrant la semaine prochaine avant d'envoyer en prod. Il sera toujours temps de modifier.

Merci pour la contribution.

63

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: février 29, 2024, 03:57:08 pm »

Merci René, c’est vraiment très sympa de ta part. Il y a quelques experts en électronique sur le site qui ne manqueront pas j’en suis sûr d’examiner cela et de faire leurs suggestions.

Je vois que tu as tenu compte du fait que le montage était en 5V mais que l’entrée digitale du l’ESP32 (satellite) elle est en 3,3v

Quelqu'un peut-il me dire le nb de tours nécessaires pour L1 (TALEMA-AS103) car sous la référence il y a plusieurs modèles avec des nb de spires différentes. Attention : il faut penser HO mais aussi N, les consommations peuvent être différentes...

Quelle est la question exactement, le nombre des spires de la bobine ? 1000 dans celles que j’ai acheté sur AliExpress (Les mêmes que Cédric avait utilisé). Mais je pense que tu veux parler du nombre de tours qu’il faut faire autour de la bobine avec le conducteur DCC ? De mémoire, Etienne disait je crois qu’il en avait fait deux ! Je pense qu’il faut tester différents cas au moment de la mise en place. Je crois qu'il est intéressant de relire son message :
https://forum.locoduino.org/index.php?topic=1656.msg18504#msg18504

Dans cet excellent article souvent cité, l'auteur dit qu'après de nombreux tests, il a fini par adopter des bobines de 50 spires !!! : http://www.sumidacrossing.org/LayoutControl/TrainDetection/InductiveDetectionCircuit/

Je remarque aussi que tu as prévu une résistance variable pour ajuster les réglages.

Je vois aussi que tu as mis un transistor entre l'ATTiny et le relais. Sur le principe, je trouve ça bien mais cela ne rajoute'il pas un peu de latence dans la commutation ? J'avais pensé à des relais basse consommation comme celui-ci, justement parce qu'on est en dessous des 40mA max des broches de l'ATTiny et je pensais, peut-être à tort qu'il n'y aurait pas besoin de transistor : https://fr.rs-online.com/web/p/relais-de-signaux/1762909?gb=s

Pour la partie programmation de l’ATTiny, je n’ai pas de soucis, ce sera assez simple. Tu programmes comme si c’était un Arduino. C’est d’ailleurs un Arduino qu’il faut utiliser pour les tests et ensuite on recopie sur l’ATTiny.

En attente des avis !!! Merci par avance

64

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: février 28, 2024, 03:16:13 pm »

Merci Réné pour ta contribution et ta proposition pour aider sur les PCB en particulier.

Je sais que les développements de Laurent souvent cités dans ce fil contribuent à créer de la confusion.

Je pense qu’il fera en sorte de contenir ce qui concerne ses propres évolutions sur ses fils à l’avenir.

Le projet des satellites autonomes, du point de vue matériel, est un projet mature et stable. Et ce pour quelques temps encore.

Cela veut dire que la carte des satellites dont la dernière version est la v7 ne sera pas modifiée dans un futur proche.

La fameuse carte de détection n’est pas indispensable au fonctionnement des satellites autonomes + Railcom et je précise qu’elle n’est pas obligatoire pour le fonctionnement de l’ensemble.

Son objectif est double :

1° - Savoir si un canton est toujours occupé alors que la locomotive a elle-même quitté ce canton. Typiquement, c’est le cas de wagons qui eux occupent toujours le canton.

2° - Il me semble que dans le concept de satellite (gérer au maximum ce qui peut l’être en local), il est intéressant de faire en local la détection de courts-circuits et d’apporter aussi en local une coupure de l’alimentation avec un relais comme tu l’as bien noté.

Ces deux fonctions ne sont pas spécifiques aux satellites autonomes, ce pourquoi il est envisagé d’en faire une carte seule pour ceux qui ne l’utilisent pas dans ce cadre.

Concernant les satellites autonomes, je te rejoins, cela ferait beaucoup de cartes, ce pourquoi j’ai dessiné un PCB de la carte Railcom qui va recevoir aussi ces éléments de consommation de courant et de coupure du courant d’alimentation des rails. Il y a une logique à regrouper les deux.

Pour le montage électronique, j’ai rappelé dans ce fil que je retenais le montage de Cédric (Pyk35) qui est simple et je connais la rigueur de Cédric et je lui fais confiance. Je rappelle qu’à quelques variantes près, etienne66 a lui aussi testé ce montage et a obtenu de bons résultats.

https://forum.locoduino.org/index.php?topic=489.msg9139#msg9139

Sans oublier Eric (nopxor) qui est celui qui nous a fait connaitre ce type de montage : https://forum.locoduino.org/index.php?topic=489.msg4982#msg4982

Moi-même, je ferai les tests dès mon retour en France le 6 mars. Je veux de plus que le traitement du signal analogique en numérique soit séparé de l’ESP32 de la carte satellite. Il y a plusieurs raisons déjà largement développées sur ce fil et ailleurs.

Je vais donc mettre un ATTinny pour faire la conversion Analogique / Numérique et qui enverra un seul signal digital à l’ESP32, l’état occupé ou non du canton.
Au passage, je remercie Christian pour sa série d’articles sur l’ATTinny (en particulier celui qui traite du sujet) https://www.locoduino.org/spip.php?article195

Après relecture des différents articles, je suis convaincu que c’est une solution simple, efficace et économique.

Voilà j’espère que ceci rendra plus clair l’état de l’ouvrage.

Alors, oui, René, je retiens ta proposition pour m’aider car tout ceci est beaucoup de travail. Cela vaut également pour toutes les autres bonnes volontés.

Et n’hésitez pas les uns et les autres si vous avez des questions.

Christophe

65

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: février 28, 2024, 11:28:43 am »

Merci pour le rappel. Mais effectivement c'est bien le baba et c'est prévu.

Pour préciser les choses, le relais n'est pas reliée à l'ESP32 mais commandé par l'ATTiny qui est sur la carte de détection.

L'ESP32 n'est relié à l'ATTiny que par une broche en numérique qui envoie une seule information, "busy" si le seuil de détection est dépassé, dès que par exemple la résistance sur l'essieu d'un wagon ait suffit à dépasser ce seuil. Et en cas de court-circuit, l'information "busy" est bien évidement encore d'actualité !

Christophe

66

Modélisation, Architectures logicielles et matérielles / Re : Re : DCC : Détection par consommation avec des courants faibles

« le: février 27, 2024, 05:12:30 pm »

Je reviens sur l'usage de l'ACS712 et des ses "limites".

Laurent,

Pour moi la question de l'ACS712 ne se pose plus dans le cadre du sujet qui nous intéresse ici. Je n'ai jamais caché mes limites en électronique, mais il me semble que Etienne démontre bien du le zmct103c fait le job, tant pour les courants faibles que pour des courants dépassant 1 ou quelques ampères ce qui permet aussi de traiter les courts-circuits.

Le montage d'Etienne me semble être celui de Cédric avec quelques différences de composants. Or connaissant Cédric, il n'y a pas de doute à avoir quand il dit que ça fonctionne.

Je suis 100% d'accord avec toi sur les limites de l'ADC de l'ESP32, d'où l'intérêt, dans un montage un peu conséquent comme les satellites autonomes, de dédier un composant à cette tâche exclusivement.

Perso, je vais essayer avec un ATTiny car j'avoue que je ne trouve pas très simple le codage et le fonctionnement pour les composants (MEGATinny) que tu préconises. Mais bon, au stade des tests ça n'a pas grande importance.

Christophe

67

Vos projets / Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.

« le: février 27, 2024, 03:32:02 pm »

La question était en fait, si toutes les leds sont allumées en même temps, cela représente quelle valeur de courant "tiré" sur le MEGA en même temps ?

68

Vos projets / Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.

« le: février 27, 2024, 03:18:14 pm »

Voilà qui me semble une optimisation optimale de ce que l'on peut faire pour un TCO avec un MEGA.

@Dominique, je ne comprends pas 5 x 74HC595 chainés = 3 pattes ? Je pensais que l'on ne pouvait enchainer que deux 74HC595.

Combien de leds peuvent-être allumée en même temps ? Ou, ce qui est la question exacte, quel est le courant maxi nécessaire pour les leds ?

Christophe

69

Aide / Re : Dcc++base station + DCC controler

« le: février 26, 2024, 04:53:05 pm »

Mario,

Tout d’abord et nous le répétons régulièrement, il n’y a pas (ou peu) de questions stupides, surtout quand elles émanent de débutants qui ont envie de progresser et qui s’en donnent les moyens. Par contre, il est arrivé que nous en ayons vu persister dans l'erreur, s'enfoncer dans les ténèbres et finalement sombrer dans le chaos malgré les conseils que nous avons pu leur apporter. Ce dernier cas de figure existe en effet.

Ceci dit, je vois à quelle station tu fais référence, c’est un article que j’ai rédigé. Il est estampillé avec deux étoiles (sur trois) ce qui veut dire qu’il s’adresse à des « niveaux » confirmés en Arduino, électronique et accessoirement en programmation Arduino.

Cet article date de 2016, et bien que tout soit encore d’actualité, des possibilités plus faciles (moins DIY) sont accessibles aux débutants.

Dans ton cas, puisque tu possèdes le Mega, la carte moteur et le shield Ethernet, je te conseille de construire une centrale avec le logiciel DCC-Ex (évolution de DCC++) aujourd’hui adopté par Locoduino et qui sera rapidement opérationnelle. Tu trouveras facilement sur Locoduino des utilisateurs pour t’aider au besoin.

Il est vrai que la solution que je proposais dans l’article offre une interface de conduite de locomotives. Cela sera toujours possible avec la centrale DCC-EX, on en reparlera d’autant que j’avais justement pour projets dans les semaines qui viennent de reconstruire exactement ce que je viens de te décrire (Mega + Ethernet + DCC-Ex) Seule la carte moteur sera différente, LMD18200 dans mon cas.

Donc regarde d’abord ici : https://dcc-ex.com/ex-commandstation/get-started/index.html#gsc.tab=0

Réalise une station pilotée par le port USB (sans Ethernet pour l’instant), fais bouger des locomotives et reviens vers nous.

Intéresse-toi aussi à JMRI qui est une bonne solution pour le pilotage simple et pour la programmation des CVs. Tu pourras débuter avec JMRI.

Enfin, regarde avant de te lancer les différents articles rédigés par msport, ils sont très didactiques et abordables avec peu de connaissances. En voici un avec JMRI justement : https://www.locoduino.org/spip.php?article305

En espérant avoir pu t'aider.

Christophe

70

Aide / Re : Dcc++base station + DCC controler

« le: février 26, 2024, 01:59:07 pm »

Bonjour Mario,

Peux tu préciser certaines choses ?

Quelle carte moteur exactement ? Quel shield Ethernet exactement ? Avec quel système envisages-tu de piloter la centrale ? Logiciel, JMRI, Rocrail ? ou manette physique comme a pu en présenter par exemple Michel ? Quelle échelle (ça peut aider).

Le choix de l'Ethernet, pas du tout critiquable loin de là, répond-il à une raison précise ou non ?

Il existe plein de solutions sur Locoduino, dont celles de Michel (msport) qui a du proposer 5 ou 6 montages, il faut juste nous orienter.

Christophe

71

Aide / DÉPLACÉ: Carte ESP32 universelle + CAN

« le: février 26, 2024, 04:31:01 am »

Ce sujet a été déplacé vers https://forum.locoduino.org/index.php?topic=1648.msg18513#msg18513

72

Vos projets / Re : Carte ESP32 universelle + CAN

« le: février 26, 2024, 04:30:18 am »

Bonjour,

Pour le lien sur le PCB de la carte ESP32 universelle, il est ici : https://forum.locoduino.org/index.php?topic=1648.msg17802#msg17802

ou plus directement ici : https://www.locoduino.org/IMG/zip/esp32_can_v6_38_pins_gerber-2.zip

Tu notes bien que tous ls composants ne sont pas obligatoirement à commander.

Le fil pour la centrale DCC Railcom est ici : https://forum.locoduino.org/index.php?topic=1352

Le programme de la centrale est téléchargeable ici : https://github.com/BOBILLEChristophe/DCCxx-ESP32-Railcom

Bien lire le readme sur la première page du Github qui donne les pins à raccorder. En particulier pour le CAN qui utilise le broches 22 et 23 au lieu de 4 et 5 habituellement.

#define CAN_RX GPIO_NUM_22
#define CAN_TX GPIO_NUM_23

Pour les autres broches :

#define PIN_PWM GPIO_NUM_12 // ENABLE (PWM)
#define PIN_DIR GPIO_NUM_13 // SIGNAL (DIR)
#define PIN_BRAKE GPIO_NUM_14 // CUTOUT (BRAKE)
#define CURRENT_MONITOR_PIN_MAIN GPIO_NUM_36 // Mesure de courant

Pour les composants, s'il t'en manque ou si parfois il faut commander de trop grosses quantités, tu me fais signe car j'ai pas mal de réserve.

Attention aussi à commander les bons ESP32 (wroom, 2cœurs, 240Mhz, 38 pins) En cas de doute, ne pas hésiter à m'envoyer le lien.

Je vais aussi relancer une commande de PCB pour les satellites (mais ce n'est pas ce qui coute le plus cher).

Et n'hésite surtout pas à partager si tu as des questions, des problèmes ou si tout fonctionne bien pour en faire profiter tout le monde.

Christophe

73

Vos projets / Re : Re : LaBox" : Une Centrale DCC polyvalente et abordable

« le: février 22, 2024, 01:35:07 am »

A mes heures perdues (trop peu nombreuses...) je tente de controler Labox via le CAN,

C'est mieux que d'aller au bistrot !

- Je pense qu'il est nécessaire d'établir un protocole CAN défini, même si il l'est uniquement à l'échelle de locoduino. Cela permet à chacun de pouvoir apporter sa petite pierre à l'édifice à coté des développeurs chevronnés qui sévissent ici et de s'assurer de la compatibilité du code dans le temps.  (une petite manette CAN, un TCO, un accessoire,....)

C'est ce que nous sommes en train de réaliser. Cela fait un petit moment que nous échangeons après avoir étudier de nombreux autres protocoles dont celui de Marklin qui m'a le plus inspiré. En fait, l'implantation du CAN dans la Box avec la structure de messages que je propose doit valider (ou non) cette proposition, ce pourquoi j'ai profité de la perche tendue par Thierry pour relancer le sujet.

- Le protocole doit rester abordable: le gros avantage de DCCex était quand même d'être controlé par des instructions simplissimes <1 xx xxx ....> Un débutant sait très vite envoyer une instruction sur un port série. Son principal inconvénient était de ne communiquer que dans un sens.
La nécessité initiale du CAN était d'apporter cette communication bidirectionnelle au gestionaire.

Non le protocole sous forme <1 xx xxx ....> ne communique pas que dans un sens. Pour les commandes CAN de la Box, j'ai également programmé les confirmations de réception de commandes avec le CAN mais je me suis limité à celle qui sont d'origine dans DCC++ /DCC Ex ! On pourra élargir si le besoin est exprimé.

J'ai étudié les liens que Christophe m'a indiqué sur le CAN avec les possibilités de filtre. Rien n'est insurmontable ..... mais a t'on besoin d'apporter de la complexité supplémentaire?
(Concernant les satellites autonomes, c'est un concept tellement différent que les besoins en communication peuvent être différents également.)

Je ne crois pas apporter de la complexité, même en CAN, tu pourrais toujours communiquer "à l'ancienne <1 xx xxx ....>". Le propre d'un protocole c'est justement de pouvoir répondre à TOUS les besoins avec la même structure. La structure pour les satellites est la même. Comme le petit programme pour le TCO que j'ai mis en ligne ce matin. C'est le propre d'un protocole, sa raison d'être que ce soit la même chose pour tout le monde.

Je ne veux surtout pas froisser les développeurs qui font un travail monstre, qui ont conçu Labox plein d'autres choses, mais en tant qu'amateur, on se sens vite largué quand on voit l'évolution impressionnante des projets, et de ce fait on se dit qu'on ne peut pas apporter grand chose... Je pense qu'il ne faut pas perdre l'aspect pédagogique et abordable pour l'amateur.
En tous cas, encore félicitations pour tout le travail accompli et aussi pour votre réactivité sur les forums quand on pose des questions. On ne reste jamais bloqué très longtemps.

Merci pour les appréciations.

Malheureusement, nous sommes actuellement essentiellement sur des projets complexes. Il n'existe pas vraiment de programmes simples pour les projets complexes. Par contre, nous faisons en sorte, Thierry en particulier, moi aussi, de faire que cela soit très simple côté utilisateur.

Pour finir, je prendrais le cas des commandes pour la Box. Les seules commandes que l'utilisateur ait besoin de connaitre sont dans le fichier à partir de la ligne 54, tu avoueras que ce n'est tout de même pas très compliqué : https://github.com/BOBILLEChristophe/Test_CommCan_LaBox/blob/main/src/Test_CommCan_LaBox.cpp

Et en plus j'ai mis des commentaires explicites.

Quand nous serons d'accord sur la structure des identifiants CAN et accessoirement des datas il faudra rédiger effectivement toute la correspondance des fonction, ce ne sera pas de la tarte.

Pour vous donner une idée, je vous joins la doc du protocole CAN de Marklin, ça va vous donner une idée du boulot à venir. Et encore, je n'ai traduit que la moitié environ ! Le lien vers le document original est au début de la traduction, il comporte 68 pages.

Christophe

PS : Peut être les responsables de ce fil préfèreront-ils ouvir un nouveau sujet pour le CAN qui n'est d'ailleurs pas spécifique à la Box ?

74

Vos projets / Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.

« le: février 21, 2024, 05:30:04 pm »

Pour ma part, je préférerais la solution d'une carte à laquelle je pourrais envoyer un signal via un TCO physique (bouton poussoir) et qui serait capable de transmettre mes ordres aux aiguilles concernées...
Cette solution existe-t-elle ?

Pour répondre au souhait de LocoFred de réaliser un TCO « physique », avec des boutons poussoirs pour changer la position des aiguilles sur les satellites autonomes, j’ai écrit ce petit programme qui fait le job.

Je suis parti d'un postulat qui est que nous avions 10 aiguilles (donc 10 boutons)

Code: [Sélectionner]

const uint8_t nb_btn = 10;           // Nombre de boutons
Que la première broche utilisée (sur un Mega) est la broche 20.

Code: [Sélectionner]

const byte firstBtnPin = 20;         // Première broche de connexion des boutons
Que les boutons actionnent dans l'ordre les aiguilles des satellites comme suit :

Code: [Sélectionner]

  btn[0].sat = 11; btn[0].aig = 0;
  btn[1].sat = 11; btn[1].aig = 1;
  btn[2].sat = 12; btn[2].aig = 0;
  btn[3].sat = 12; btn[3].aig = 1;
  btn[4].sat = 12; btn[4].aig = 2;
  btn[5].sat = 13; btn[5].aig = 0;
  btn[6].sat = 14; btn[6].aig = 0;
  btn[7].sat = 14; btn[7].aig = 1;
  btn[8].sat = 15; btn[8].aig = 0;
  btn[9].sat = 16; btn[9].aig = 0;
La bibliothèque CAN utilisée est acan2515 de Pierre Molinaro : https://github.com/pierremolinaro/acan2515/tree/master

Le shield CAN recommandé est celui de SEED Studio : https://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/
qui autorise 1Mbps de débit.

Sur un Mega, il sera nécessaire de respecter le brochage suivant :



Voici le code que vous pouvez aussi télécharger :

Code: [Sélectionner]



/*
    Etude du programme pour des commandes d'aiguilles à partir de boutons poussoirs sur un TCO (physique)
    à destination des satellites autonomes
    Ce programme est destiné à fonctionner sur Arduino Uno ou Mega.

    Les broches sont commutées sur HIGH à l'état repos de boutons poussoirs par activation des résistances PULLUP internes
    Elles sont commutées sur LOW par l'appui sur le bouton poussoir lorsqu'elles reçoivent un signal à la masse (GND)
    Cet état LOW correspond au bouton appuyé.
   
    v 0.0.1 - 21/02/2024

    copyright (c) 2024 christophe.bobille - LOCODUINO - www.locoduino.org
*/

const byte thisNodeId = 252;         // N° de nœud CAN du TCO sur le bus

const uint8_t nb_btn = 10;           // Nombre de boutons
const byte firstBtnPin = 20;         // Première broche de connexion des boutons
const uint32_t delayDebonce = 100;   // Delay du debonce (en millisecondes)
const uint32_t delaySendMsg = 2000;  // Delay entre l'envoi de messages CAN (en millisecondes)


class Button
{
private:

public:
  byte ID;
  byte pin;
  bool pressed;
  uint32_t lastDebounceTime;
  uint32_t lastTimeSendMsg;
  byte sat;
  byte aig;
  Button();
};

Button::Button()  // Constructeur
  : ID(0),
    pin(255),
    pressed(false),
    lastDebounceTime(0),
    lastTimeSendMsg(0) {}

Button btn[nb_btn];  // Instances de Button

/************************ ACAN *****************************/
// If you use CAN-BUS shield (http://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/) with Arduino Uno,
// use B connections for MISO, MOSI, SCK, #9 or #10 for CS (as you want),
// #2 or #3 for INT (as you want).
#include <ACAN2515.h>
static const byte MCP2515_CS = 53;  // CS input of MCP2515 (Arduino Mega)
static const byte MCP2515_INT = 2;  // INT output of MCP2515 (Arduino Mega)
ACAN2515 can(MCP2515_CS, SPI, MCP2515_INT);
static const uint32_t QUARTZ_FREQUENCY = 16UL * 1000UL * 1000UL;  // 16 MHz

CANMessage frame;  // Instance de CANMessage
/**********************************************************/

void setup() {
  Serial.begin(115200);

  /************************ ACAN *****************************/
  //--- Begin SPI
  SPI.begin();
  //--- Configure ACAN2515
  Serial.println("Configure ACAN2515");
  ACAN2515Settings settings(QUARTZ_FREQUENCY, 1000UL * 1000UL);  // CAN bit rate 1000 kb/s
  const uint16_t errorCode = can.begin(settings, [] {
    can.isr();
  });
  if (errorCode != 0)
  {
    Serial.print("Configuration error 0x");
    Serial.println(errorCode, HEX);
  }
  /************************ ACAN : paramètres du messages *******************/
  // Structure de l'identifiant des messages CAN : https://www.locoduino.org/IMG/png/satautonomes_messageriecan_v1.png
  const byte prio = 0x03;     // Priorité la moins élévée
  const byte commande = 0xE1; // Identifiant des commandes d'aiguilles pour les satellites autonomes
  const byte resp = 0x00;     // Ceci n'est pas une réponse


  frame.id |= prio << 27;        // Priorite 0, 1 ou 2
  frame.id |= commande << 19;    // commande appelée
  frame.id |= thisNodeId << 11;  // ID expediteur
  frame.id |= resp << 2;         // Response
  frame.ext = true;                 // Identifiant long (29 bits) = true
  frame.len = 2;                     // Nombre d'octets de données du message
  /**********************************************************/


  for (byte i = 0; i < nb_btn; i++)
  {
    btn[i].ID = i;
    btn[i].pin = firstBtnPin + i;
    pinMode(btn[i].pin, INPUT_PULLUP);
    Serial.print("setup btn : ");
    Serial.println(i);
  }

  // Exemple d'aiguilles à commander
  // sat désigne sur quel satellite s'applique la commande
  // aig désigne sur quelle aiguille de ce satellite s'applique la commande
  btn[0].sat = 11; btn[0].aig = 0;
  btn[1].sat = 11; btn[1].aig = 1;
  btn[2].sat = 12; btn[2].aig = 0;
  btn[3].sat = 12; btn[3].aig = 1;
  btn[4].sat = 12; btn[4].aig = 2;
  btn[5].sat = 13; btn[5].aig = 0;
  btn[6].sat = 14; btn[6].aig = 0;
  btn[7].sat = 14; btn[7].aig = 1;
  btn[8].sat = 15; btn[8].aig = 0;
  btn[9].sat = 16; btn[9].aig = 0;
}

void loop()
{
  for (byte i = 0; i < nb_btn; i++)
  {
    // Le bouton est détecté comme appuyé
    if (LOW == digitalRead(btn[i].pin))
    {
      // L'état pressed est vrai et le delay de debonce est dépassé
      if (btn[i].pressed && millis() > btn[i].lastDebounceTime + delayDebonce)
      {
        // Le delai par rapport au dernier envoi est dépassé
        if (millis() > btn[i].lastTimeSendMsg + delaySendMsg)
        {
          // Envoi du message CAN de commande
          frame.data[0] = btn[i].sat;  // ID satellite destinataire
          frame.data[1] = btn[i].aig;  // Aiguille à commuter
          const bool ok = can.tryToSend(frame);
          if (ok)
            btn[i].lastTimeSendMsg = millis();
          else
            Serial.println("Send failure");         
        }
        btn[i].lastDebounceTime = millis();
      }
      btn[i].pressed = true;
    }
    else
      btn[i].pressed = false;
  }
}


75

Vos projets / Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.

« le: février 21, 2024, 03:54:43 pm »

Lorsque l'on associe une paire de satellites le fait de presser 1 bouton sur le premier va faire clignoter la led de celui ci.

OUI

Cet état de clignotement reste présent sur chaque satellite dont 1 bouton est pressé tant que le processus d association n'est pas achevé.

OUI

Le processus d'association bascule la led en allumage FIXE une fois le processus d'appairage achevé ET que 1 bouton sur chaque satellite reste pressé.

OUI

Elle est OFF ensuite en fois les boutons relâchés.

OUI

C est bien cela? ( elle est OFF en utilisation normale)

OUI

Si par "accident" un bouton d'appairage est pressé sans autre binôme dans le processus de découverte il n'y a pas de modification des attributions existantes?

NON

Que se passe t il si un satellite n'a pas de voisin? (soit horaire soit antihoraire) C'est le cas d'une voie en impasse par exemple.( tiroir ou gare terminus)
J'imagine que le soft gèrera le ralentissent dans la zone traitée par ce satellite et arrêtera le train une fois le capteur ponctuel horaire atteint. C'est bien cela?

OUI, s'il n'y a aucun satellite identifié à la sortie d'un canton (en fonction de la position des aiguilles éventuellement) on est dans le même cas que pour un canton occupé, le signal se met au rouge, le train frein puis s'arrête !

Pour un mouvement dans le sens de circulation opposé, y a t il des critères à avoir?

Pas comprendre la question

Tout mouvement des lors que les sécurités de "bloc automatique" sont respectées sont autorisées dans une zone d'un satellite donné?

Les commandes des trains ne suivent pas la signalisation qui n'est la que pour la décoration. Le satellite déduit des possibilités en fonctions de son environnement (position des aiguilles, occupation ou non de cantons voisins (jusqu'à +2). Ce sont ces états qui conditionnent si l'on peut appliquer tel ou tel ordre à une locomotive et qui déduisent la signalisation adéquate.