projet centrale "LaBox" wifi DCC++ Can

[msport]

Il faut alors un connecteur HE10 à 8 broches et une nappe.

la connectique est un sujet annexe mais ô combien problématique. Le module BTS7960B à 43A est hors sujet mais pour les projets qui l'intègre, le HE10 est la solution native (photo du module) et professionnelle qui s'impose en câblage interne (ou en solution du pauvre en header 2.54) plutôt que de multiples soudures sur un DB9. Mais si on veut faire "pro", regardons ce qui se fait dans notre domaine.
A mon sens, un des objectifs sera d'intégrer tout sur la carte et mettre les connecteurs en bord de celle-ci pour être accessibles via des découpes dans le boitier et ce, sans câblage.
Si il doit y avoir un booster, il utilisera le signal DCC lui-même.
Et quant aux bus I2C ou SPI, il faudrait là aussi en définir le besoin. Restons intégré, le CAN est là pour ça (lui est normalisé en DB9, mais j'imagine qu'on lui préférera le RJ12 ?)
Inutile de devenir les rois du pétrole, le prix du baril n'arrête pas de baisser !

[Pyk35]

Inutile de devenir les rois du pétrole, le prix du baril n'arrête pas de baisser !

Excellent ! Je me suis un peu emporté j'avoue

En fait la question est est-ce que le booster 43A est dans la centrale ou est-ce qu'il sera une extension ?
Est-ce que la centrale est réalisée avec un unique booster 4A et ceux qui le souhaiteront devront développer un 2e booster sous forme d'extension?
Si il est dans le boitier, en effet, le HE10 est adapté pour aller sur les 8 Pin du shield.

Dans l'idée que j'exprimais, je pensais à un connecteur subd9 soudé sur le PCB qui servirait uniquement d'extension pour les plus exigeants d'entre nous partant sur le principe que 90% des gens se contenteront de 4A et des fonctions natives.

Si il doit y avoir un booster, il utilisera le signal DCC lui-même.

On est d'accord mais du coup il faut juste une masse, le signal IN et le Enable je pense non ?

Et quant aux bus I2C ou SPI, il faudrait là aussi en définir le besoin. Restons intégré, le CAN est là pour ça

Pas certain en fait. Le CAN nous apportera toute la communication fonctionnelle et là on standardise la connexion en RJ12 comme pour les cartes satellites.
Par contre l'I2C ou SPI peuvent offrir une véritable extension électronique pour ajouter par exemple :

• Une EEPROM
• Un autre écran
• Un second microcontroleur
• Un lecteur RFID
• tout autres composants pas trop idiots...

Je pense qu'il faut trancher ces questions de fond et après bien entendu on ne va pas se battre sur un type de connecteur en effet.

[Dominique]

Bonjour à tous,

je tiens à calmer un peu les ardeurs qui risquent de nous conduire vers l'usine à gaz 

J'ai fixé à 4A le courant de sortie du DCC parce que ça suffit dans 90% des cas. Chez moi j'ai un LMD18200 donc 3A pour l'ensemble de mon réseau en N et ça suffit (le seuil de détection de court-circuit est bien inférieur). Pour le HO je concède 1A de plus.
Dans mon esprit ce projet sert à faciliter l'accès au digital donc pour des modélistes qui démarrent et qui n'ont pas encore un très grand réseau. Celui qui voudra la taille au dessus aura déjà acquis assez d'expérience pour construire une solution DIY adaptée à son besoin, il y a plein d'exemples dans le site dont ceux de Christophe avec toutes sortes de pont en H (booster ..). D'ailleurs, si ce projet a du succès, il s'en trouvera toujours quelqu'un pour faire une version gonflée.
A partir du moment où il est possible d'adjoindre un booster de course via la ligne DCC, alors il n'est plus nécessaire de concevoir un connecteur : le connecteur DCC suffit (il faudra juste prévoir la masse commune et le booster externe devra avoir sa propre alimentation).

Pour les autres types d'extensions, l'I2C et le SPI sont réservé pour des extensions de proximité, pas au bout d'un long câble (évitons plein de problèmes de parasites en tous genres), donc seulement sur la carte principale (l'I2C pour l'afficheur).
Par contre le Can, le Wifi et le bluetooth (sans antenne car on est toujours très près) sont vraiment faits pour des coopérations plus loin à l'extérieur : par exemple un configurateur, un TCO graphique et tactile, un système de mise à jour logiciels et données en OTA, et surtout l'ensemble de la rétrosignalisation via les satellites déjà équipés de Can (donc plus de S88 ou autre) 
Je n'oublie pas les utilisateurs de JMRI qui apprécieront l'interface Wifi ou USB et la rétrosignalisation via une passerelle intégrée.
La vraie limitation que nous allons rencontrer sera principalement du coté logiciel car l'ESP32 n'a "que" 1,3 Moctets de ROM-flash et 327,6 Koctets de SRAM (d'après l'IDE) et surtout le développement et l'intégration des fonctions que chacun voudra y mettre.
C'est largement très ambitieux comme ça et on risque peut-être d'y arriver  .

[Thierry]

J'aime beaucoup ce projet qui fait écho à mes multiples projets personnels, de DCCpp à DcDccNanoController en passant par les récents développements de DCCpp en ESP32.

Cette partie est à finaliser. En tenant de faire une version à diffuser, j'ai évidemment voulu re-tester, et bien sûr, rien ne marche... Donc ça va venir, mais peut être pas aussi vite que je l'aurais voulu.

Pour ce qui est du cahier des charges, je voudrais ajouter deux points:
- La centrale doit aussi être capable de faire de l'analogique sur du courant pulsé en PWM. Tous les utilisateurs de DCC ont sur leur étagères des vieilles locos issus de leur histoire ou de leur achats compulsifs qui ne sont pas -encore- digitalisées et qu'ils voudront malgré tout faire tourner. Il ne faut pas les oublier.
- Pour répondre à l'interrogation de Dominique au sujet de la capacité mémoire de l'ESP32, il faut savoir que la dépense mémoire est bien plus importante à programme équivalent sur un ESP que sur un Avr. C'est lié à l'architecture et aussi au fond de routines qu'il faut inclure à côté du programme utilisateur pour le faire tourner... Ça ne va clairement pas dans le bon sens ... Malgré tout, je pense que la limite ne sera pas atteinte avant longtemps: mon programme de test DCCpp ne prend que 25% de la mémoire. Et puis au pire, rien n'empêche d'avoir une architecture distribuée, avec un ESP8266 (moins cher...) qui gère les communications Bluetooth, Wifi, CAN et autres, et qui envoie via SPI/I2C/Serial les ordres reçus au DCCpp présent sur l'ESP32 ... Ça serai aussi certainement salvateur pour les timings DCC qui ne seraient plus perturbés par tout ce qu'il faut faire autour.

[Pyk35]

Bonjour Thierry,

La centrale doit aussi être capable de faire de l'analogique sur du courant pulsé en PWM.

J'ai prévu ceci dans le cahier des charges:
Alimentation
La centrale s’alimente par une alimentation externe dont la tension sera adaptée au type de réseau :

• 18/19V pour du Ho
• 15V pour du N
• 12V pour de l’analogique pur

L’alimentation permet de fournir le signal de puissance DCC (4A max) mais d’alimenter la centrale. Un convertisseur DC/DC soudé au PCB permet d’abaisser une tension comprise entre [12 VDC; 19 VDC] vers du 5 VDC afin d’alimenter l’électronique. L’ESP32 s’alimente en 3.3V mais la carte “DEVKIT” intègre un régulateur capable de générer le 3.3V depuis le 5V alors que le 5V servira également à d’autres composants.

La connexion d’alimentation se fait au travers d’un connecteur femelle au format 5.5 mm x 2.1 mm soudé sur le PCD. Pour les utilisateurs ne disposants pas d’une alimentation compatible avec ce format, il sera possible d’acquérir l’adaptateur ad' hoc (Cf BOM).

Cas particulier du pilotage de trains analogiques
Il existe une demande pour réaliser une centrale numérique destinée à piloter des trains analogiques. On pourrait donc, sous réserve d’avoir une tension qui n'excède pas la limite des moteurs (12V ou 14V à confirmer) développer un mode analogique dont le but sera de faire varier en PWM la tension de sortie entre [-12V;0V] et [0V;+12V].
L’effort pour le développement de ce mode est minime pour un apport très intéressant et surtout peu répandu voire inexistant sur le marché.

Cela te convient ?

[Thierry]

Parfait. Penser à juste pouvoir régler la fréquence du PWM pour s'adapter à divers types de moteur.

[Dominique]

Et bien on s'entent bien ce qui est le principal

Dans le document de cahier des charges en cours sur Google docs (pour épargner le site Locoduino qui en bénéficiera quand il aura été un peu décanté), je vais ajouter mon historique : un projet similaire qui me porte à croire que ce que nous visons est possible. Vous y verrez les choix que j'ai fait et les embuches que j'ai rencontrées.

Pour la partie PWM que j'ai voulue compatible avec les commandes DCC++, j'ai été surpris par la simplicité du logiciel ajouté à DCC++ donc j'ai hâte de voir la version de Thierry !
Seule précaution : ne piloter qu'une seule machine (j'ai évidemment mis 2 machines pour voir et c'est marrant car elles n'ont pas toujours les même vitesses). Dans ce cas un découpage du réseau en cantons alimentés séparément (via des satellites d'alimentation - Jean-Luc sait bien nous expliquer ça ) pourrait permettre de s'y adonner. Mais pas de PWM et de DCC en même temps (sur des voies séparées).

[msport]

Si il doit y avoir un booster, il utilisera le signal DCC lui-même.

On est d'accord mais du coup il faut juste une masse, le signal IN et le Enable je pense non ?

En fait, les deux fils du DCC suffisent :
https://forum.locoduino.org/index.php?topic=891.msg9426#msg9426

Merci Dominique d'avoir rappelé la philosophie de ce projet. Et d'ailleurs Thierry constate que les timings du DCC ne cohabitent pas toujours bien avec le reste (bon courage à lui).
Encore une fois on voit que Gregg a eu raison en séparant le temps réel de la gestion ...
Sur un 100x100 on peut effectivement distribuer les rôles.

Pour l'analogique, Thierry a montré que cela se fait par logiciel dans sa "petite centrale toute prête"
https://www.locoduino.org/spip.php?article224

Pour les tensions, ce sera à l'utilisateur de choisir le(s) bloc(s) secteur qui convient à son matériel.
En fonction de ses décodeurs ou de ses locos analogiques (et de son gout du risque)

[Dominique]

Pour les tensions, ce sera à l'utilisateur de choisir le(s) bloc(s) secteur qui convient à son matériel.
En fonction de ses décodeurs ou de ses locos analogiques (et de son gout du risque)

C'est important car j'ai cramé le moteur d'une de mes locos en N : il ne faut pas dépasser les 12V !
Jongler avec plusieurs alimentations est un peu casse-gueule !

[msport]

Jongler avec plusieurs alimentations, casse-gueule ? Guère plus que de choisir par configuration la tension appliquée au pont. Sinon la sécurité est de recommander de rester à 12V.
Mettre un step down de puissance et de plus réglable par l'utilisateur ne va pas dans le sens de la simplicité.
Mieux vaut expliciter au futur utilisateur le choix de la tension et qu'il s'y tienne une fois pour toutes.
A mettre en priorité 2 ?

[Thierry]

Et puis cette centrale s'adresse à toutes les échelles, et dans les grandes échelles la tension peut monter à 20v...

[DDEFF]

Je me demande si on doit absolument avoir un bus CAN dans la centrale DCC.

1°) si on n'a pas de gestionnaire, on n'a carrément pas besoin de bus du tout.
Nota : ce sera le cas de tous les débutants

2°) si on a un gestionnaire, on va échanger des informations.
La distance entre le PC/Mac/Linux et la centrale est courte.
Les parasites seront donc faciles à éliminer.

Les informations vont être très simples :
On a dit précédemment dans le bus V1 que c'est la centrale qui va gérer les accélérations et les ralentissements. Le gestionnaire se contente donc de dire :
"train n° N : vitesse maxi arrêt"
"train n° N : vitesse maxi 30 km/h"
"train n° N : vitesse maxi 60 km/h"
"train n° N : vitesse maxi 90 km/h"
"train n° N : vitesse maxi plein pot"

Dans la pratique, il faudra avoir étalonné ses locos pour que la vitesse maxi corresponde à un cran de vitesse (parmi 14 ou 128)
Dans mon gestionnaire, puisqu'il gère maintenant la composition des trains (bientôt le post sur le forum), il sera très facile d'indiquer :
"la 150X02 : 30 km/h = cran 25, 60 km/h = cran 65, 90 km/h = cran 118" (un simple fichier Excel)

On a donc CINQ ordres depuis le gestionnaire -> centrale DCC
Et AUCUN ordre             depuis la centrale DCC -> le gestionnaire.

En effet, le gestionnaire se moque de la vitesse réelle du train puisqu'elle est gérée directement par la centrale DCC (on n'a donc pas à l'envoyer au gestionnaire) et les infos d'occupation de zones viennent des modules V1/V2, via un CAN, là, indispensable.

Donc, je trouve que mettre un CAN pour 5 ordres dans un seul sens, c'est luxueux. Et on gagne 2 RJ (au moins) et on n'est pas obligé de choisir un processeur avec le CAN en natif.

Reste les fonctions F0 F28 qui sont des ordres, eux aussi, mono directionnels et dans le même sens que les autres.
N'importe quel bus sait faire ça. On prend le plus simple et le moins gourmand en place.

Denis

[msport]

On a donc CINQ ordres depuis le gestionnaire -> centrale DCC
Et AUCUN ordre             depuis la centrale DCC -> le gestionnaire.

Mais ce n'est plus une centrale, c'est un booster, et je crois qu'on en a déjà. Une centrale comme son nom l'indique doit pouvoir centraliser les échanges DCC++. Et les satellites exécutent des ordres en plus de remonter des informations.

[Dominique]

Je me demande si on doit absolument avoir un bus CAN dans la centrale DCC.

Moi je ne me le demande pas ce qui fait qu'on l'intègre d'emblée dans le projet 

1°) si on n'a pas de gestionnaire, on n'a carrément pas besoin de bus du tout.
Nota : ce sera le cas de tous les débutants

C'est justement l'hypothèse fausse qui t'amène à cette conclusion :
Pourquoi n'y aurait-il pas un gestionnaire dans la centrale ?
L'exemple le plus simple est mon va-et-vient qui est justement une centrale avec un petit gestionnaire intégré qui a donc besoin des informations de rétrosignalisation. Un exemple de cette nouvelle centrale sera donc un nouveau va-et-vient avec des satellites (capteurs, aiguilles et signaux) pour 2 trains sur voie unique avec une voie d'évitement au centre, et pourquoi pas d'autres trains comme le train du mont blanc de St Gervais au Nid d'Aigle.
Mais je suis certain que d'autres exemples vont fleurir partout !
L'ESP32 dispose de suffisamment de mémoire pour envisager cette hypothèse de gestionnaire (ou chef de gare ou poste de triage...) intégré. C'est justement une zone de créativité !
Par ailleurs on peut y loger une passerelle CAN-WIFI (interface Satellites pour JMRI par exemple).

2°) si on a un gestionnaire, on va échanger des informations.
La distance entre le PC/Mac/Linux et la centrale est courte.
Les parasites seront donc faciles à éliminer.

Et si on ne veut pas de PC Mac Linux qui, eux, n'ont pas de Can natif...
La rétrosignalisation par les satellites via Can (sans parasites, ni S88, ...) reste d'actualité.

On a donc CINQ ordres depuis le gestionnaire -> centrale DCC
Et AUCUN ordre             depuis la centrale DCC -> le gestionnaire.
Donc, je trouve que mettre un CAN pour 5 ordres dans un seul sens, c'est luxueux. Et on gagne 2 RJ (au moins) et on n'est pas obligé de choisir un processeur avec le CAN en natif.

quel économie fais-tu en supprimant le Can, voire l'ESP32 que tu remplaces par quoi ?
Si tu ne veux pas équiper la carte (sans les RJ11 et le driver de ligne Can), tu es libre de le faire : tu pourras revenir sur ce choix plus tard.

Alors Denis, toi qui prône toujours l'usage du Can, n'en privons pas ce projet 

[Pyk35]

Bonsoir,
Avec Dominique, on pensait qu'il fallait pouvoir profiter de l'ESP32 et notamment de ses doubles coeurs processeur.
L'ESP32 embarque le FreeRTOS, un OS temps réel puissant mais qui pour autant un peu bridé par Arduino IDE qui n'exploite au final qu'un coeur (le coeur n°1, sachant que le coeur n°0 ingère de l'idle pendant ce temps).
Et bien sachez que ce n'est pas compliqué (je n'ai pas encore testé donc c'est certainement très facile d'en parler  ) de profiter des 2 coeurs : https://randomnerdtutorials.com/esp32-dual-core-arduino-ide/

Dans le setup(), on déclare une fonction, Task1code dans l'exemple mais c'est libre, qui sera affecté sur le coeur 0. Exemple :

Code: [Sélectionner]

xTaskCreatePinnedToCore(
      Task1code, /* Function to implement the task */
      "Task1", /* Name of the task */
      10000,  /* Stack size in words */
      NULL,  /* Task input parameter */
      0,  /* Priority of the task */
      &Task1,  /* Task handle. */
      0); /* Core where the task should run */
et ensuite on implémente notre fonction :

Code: [Sélectionner]

Void Task1code( void * parameter) {
  for(;;) {
    Code for task 1 - infinite loop
    (...)
  }
}

Comme vous le voyez, c'est très simple, on pourrait très bien avoir une loop_core0() et une loop_core1()  ->


Un beau cas d'usage pour notre projet serait de séparer la partie web du reste de la centrale pour être sûr de ne pas ralentir quoi que ce soit selon le nombre de client. A creuser.

Après on entre dans le domaine du multitâche / multi thread donc attention aux MUTEX qu'il faudra gérer à la pogne si nécessaire.