projet centrale "LaBox" wifi DCC++ Can

[Dominique]

Bonjour 

Pour répondre a la question, est ce que cela m'intéresse ?

Je répondrai oui, pour moi.
Je suis ce fil en sous-marin depuis bien longtemps.

Mais vous m'avez coulé depuis … bien longtemps aussi !
 J'ai pas tout compris 

Et bien on s'éfforcera de répondre à tes questions 

[DDEFF]

Bonsoir Thierry,

redémarrer l'ESP suffit...

J'ai dû louper quelque chose 

Denis

[Thierry]

Les connections réseau s'établissent pendant le setup, toutes les connections Wifi par exemple, mais aussi la connection via une carte ethernet si c'était disponible pour l'ESP32... Donc si à la fin du setup, le serveur Wifi n'a pas été trouvé, personne ne tentera plus tard de se connecter. La seule solution est alors de redémarrer l'ESP pour relancer le setup et retenter la connection.
Cela dit, on pourrait prévoir un bouton (ou une option de menu) qui relancerai les connections des Throttles pas encore connectées, et qui vérifierai les autres. On pourrait aussi imaginer de redonner une chance à la connection toutes les minutes...

[DDEFF]

OK, Thierry, je comprends le problème.
Mais si on relance le setup, cela veut dire qu'on arrête l'ESP32 ... et donc le DCC, le CAN.

Pas longtemps, bien sûr, mais c'est un problème qu'on va avoir à régler.
Avec plein de mémorisations (cran des locos, positions des locos, des aiguilles, ...).

Je pense que toutes ces infos doivent être dans le gestionnaire (le TCO, en particulier) qui va les mémoriser et les refournir suite à la coupure.
Nota : cela règlera aussi la coupure de jus inopinée. C'est la même problématique.

Pour le projet actuel, ce n'est pas gênant.

Denis

[Dominique]

Les connections réseau s'établissent pendant le setup, toutes les connections Wifi par exemple

Dans ma version compatible Withrottle (sur ESP8266, mais ce sera pareil sur ESP32), il est possible d’ajouter des connexions l’une après l’autre, après le setup, évidemment, grâce au DNS, si je ne me trompe. Est-ce grâce au mode soft-AP ? Je ne pense pas (a creuser).

Je pense que toutes ces infos doivent être dans le gestionnaire (le TCO, en particulier)

Évidemment si c’est le gestionnaire (externe) qui gère les connexions des manettes, il n’y a plus de problème (cas de JMRI).

[Pierre59]

Bonjour

Habituellement avec un ESP32 on établit la connexion WIFI avec un point d'accès WIFI pendant le setup(), cette connexion n'est qu'une connexion "physique" du média de communication. N'importe quand par la suite on peut établir des connexion réseau (IP,TCP ou UDP) en nombre quelconque ou les abandonner. Ces connexion se font en mode client/serveur, un client peut accéder à un serveur s'il connait son adresse IP, si on dispose d'un serveur de noms (DNS) on peut utiliser des noms pour faire ces connexions.

Pierre

[DDEFF]

Merci Pierre,

Me voilà rassuré 
J'avais un peu de mal à comprendre qu'à chaque connexion d'un nouveau mobile on doive arrêter l'ESP32.
Donc, tout va bien.

Denis

[Jeje_12_34]

Bonsoir

J'ai tout relu, et presque tout compris, cette fois.
Je vais tout de meme intervenir en tant que néophyte qui ne connaissait pas les Arduinos il y a trois mois.

J'espère que la connexion wifi de LaBox peut "facilement" être remplacée par une liaison Ethernet au réseau domestique.
J'ai cru comprendre que oui.
Ou alors,  on peut connecter la box par wifi au réseau domestique ? (mais je préfère le filaire sur ce coup la)

Parce que pour ma configuration "immobilière", le graal c'est :
-   JMRI par wifi sur la box du FAI (parce que j'ai compris le mode basique de JMRI )
-   LaBoX"locodudino" par Ethernet sur le routeur de la box du FAI.
-   Gestion des locos, de la retro et les accessoires via JMRI.
-   Avoir la possibilité d'ajouter ensuite et de facon totalement optionnelle un bon vrai TCO avec de bons gros boutons et tout plein de voyants, façon Star Treck  , sans que cela ne perturbe  JMRI.

Donc si j'ai bien compris, on oublie l'Arduino, pour passer sur une autre carte plus puissante et plus intégrée, mais qui se programme via l'IDE de l'Arduino.

Autre chose  :

Je pense que vous essayez de faire une centrale "le moins cher possible", mais peut être que vous visez trop bas.
A mon sens, si vous visez vraiment un public de "néophyte", l'essentiel est la simplicité.
Les centrales du commerce sont hors de prix, et pourtant elles se vendent.
Si LaBox coute, disons 60€ (a la louche hein … c'est pour donner une idée) , vous aurez beaucoup d'intéressés surtout s'il faut réfléchir un peu (de façon ludique) et que cela reste accessible et clair.

Je suis désolé de ne pas avoir osé intervenir auparavant dans cette discussion, pour vous apporter des questions de néophytes. 

Jerome
Pas loin de Montpellier

[msport]

Juste une remarque : dans un projet, on fixe d'abord les objectifs. Ici, Dominique a fait un cahier des charges. A noter qu'il s'agit d'une brique, bien sur centrale.
A partir de là, on tente de le réaliser à un cout optimal.

La démarche "pas assez cher, mon fils" c'est une question marketing ... Qu'on peut toujours résoudre sans difficulté, en choisissant ses composants ailleurs que sur eBay. Les prix sur les sites institutionnels (+port) sont entre deux et trois fois plus élevés.

Si les centrales (consoles ?) du commerce se vendent, c'est que leurs utilisateurs veulent du clé en main, avec documentation et support complet. Et ce qu'ils trouvent à redire au DIY, c'est qu'en fonction de leurs compétences, la réussite n'est pas obligatoirement au bout. Dans ce cas, 60€, c'est beaucoup. D'autre part le ludique, on peut le trouver autant dans la réalisation du réseau que dans l'utilisation du fer à souder et le dépannage de l'électronique ou le débogage de programmes.

Maintenant, sur Locoduino, il y a la place pour des projets plus ambitieux du type la centrale ou la console à tout faire avec un écran 10" ou plus pour gérer un réseau de 500 locomotives sur un réseau de 6mx9m. On cherche un chef de projet, sachant qu'il vaudrait mieux définir l'architecture d'abord ainsi que les objectifs à atteindre ensuite. Il n'est pas trop tard. En tout état de cause, on est à la version 1.0 (ou même 0.1) et on verra en fonction des retours que nous aurons.

Voir : http://locoduino.org/spip.php?article233

[Jeje_12_34]

Bonsoir

Ce dernier message me laisse à penser que je n'ai vraiment pas compris grand chose de ces  15 pages de discussion  .

Je vais a nouveau tout relire et essayer de ne pas poster un hors sujet lors de ma prochaine intervention.

Bonne soirée à tous

Jerome

[Dominique]

Bonjour Jerôme,

Il est difficile de s'y retrouver dans la 1ère lecture de ces 15 pages sur le projet, un fil de forum comme celui de Locoduino n'est pas un vrai outil de gestion de projet utilisé seulement par les développeurs de projet.

Il y a un mélange entre les idées de ceux qui voient bien où aller et qui vont réaliser le projet (et qui ont bien commencé après quelques étapes de validation des concepts) et les autres qui postent des avis parfois en contradiction avec le fil du projet, avis qui entraiment des réponses qui contribuent à s'écarter du droit fil. Donc c'est une discussion dans laquelle il faut savoir extraire l'essentiel.

Peut-être aurait-il fallu se réunir et discuter du projet en mode caché (comme nous l'avons fait pour le Locoduinodrome pour Orléans), puis annoncer "voilà c'est comme ça !"

Au contraire, nous sommes partis de façon complètement publique pour bien sentir les réactions et les sensibilités de chacun, ce qui a permis de voir des personnes rejoindre ce projet avec des compétences pointues qui vont contribuer au résultat.

Ce qui fait que les contours du projet (le cahier des charges) sont apparus effectivement à la page 13 : https://forum.locoduino.org/index.php?topic=922.msg9956#msg9956

Alors, pour aider tous ceux, comme Jérôme, qui cherchent à comprendre et se demandent si ce projet les intéressent, je vais essayer de retracer les grandes étapes du raisonnement.

Autant le dire tout de suite, ce raisonnement est basé sur la présence et la disponibilité des éléments techniques de ce projet d'une part, des personnes qui peuvent les porter, d'autre part, ainsi que sur l'expérience et l'historique de chacun.

Dans les contributions suivantes, je vais définir les points importants de ce projet :

• pourquoi le DCC ?
• pourquoi le Wifi ?
• pour commander les trains et comment ?
• avec quelle puissance électrique (ampères)
• avec quelles relations avec des organes externes (rétrosignalisation, gestionnaires)
• etc..

A suivre ...

[Thierry]

Non, non, ce n'est pas hors sujet, c'est juste que le débat a déjà eu lieu...
La volonté de monter un projet simple résulte aussi dans une problématique que l'on rencontre -presque- tous dans notre pratique du modélisme : à vouloir trop en faire, on ne finit jamais rien ! Se fixer des objectifs atteignables et raisonnablement faisables permettront, j'espère, d'arriver au bout du projet. Il faut du travail, et nous sommes dedans jusqu'au cou, mais le bout du tunnel est perceptible. Et puis une fois que la version 1.0 sera réalisée, il faudra faire grossir les ambitions et mettre en chantier la version 2.0 . On a déjà eu une expérience similaire, et les satellites version 2.0 n'ont pas vu le jour... Alors restons humbles.

[Dominique]

Merci Thierry, c'est essentiel de rappeler ce principe 

1) Pourquoi faire une centrale DCC ?
Vous l'avez remarqué, tous les modélistes qui veulent piloter plusieurs trains sur un réseau, petit ou grand, ont besoin d'une alimentation pour les locos connectée aux rails. Bien-sûr il y a le courant continu ou le PWM qui n'est pas exclu de ce projet (le projet de Jean-Luc "un Arduino par canton" https://forum.locoduino.org/index.php?topic=36.0 est la quintescence de ce qui peut se faire de mieux). Mais, il semble que la grande majorité des modélistes ferroviaires soit passée au DCC ou va y passer. Ce projet pourra faire une transition douce  , il me semble.

Depuis le début, Locoduino décrit le DCC (https://www.locoduino.org/spip.php?article14) et nous avons la chance d'avoir déniché (grâce à Denis) le logiciel DCC++ de Gregg E. Berman qui a été ensuite transformé  en bibliothèque DCCpp par Thierry (https://www.locoduino.org/spip.php?article228). Cette bibliothèque, à l'origine, a été écrite pour les processeurs ATMega 328 et 2560.
En cherchant rapidement on peut trouver des quantités de réalisations de centrales DCC sur Locoduino. Alors pourquoi encore une ?
La réponse est dans la suite !

2) Pourquoi l'ESP32 ?
Depuis l'arrivée des processeurs ESP32, très puissants,  double coeur et doté d'un grosse mémoire (https://en.wikipedia.org/wiki/ESP32), avec wifi, bluetooth, I2C, SPI, CAN, etc.. tout intégré, on peut penser réaliser quelque chose qui parait simple (à première vue) et bon marché et qui reste "ouvert" pour les besoins de chacun (probablement avec du développement personnel).
Mais ne nous y trompons pas, comme insiste Thierry, on ne peut surement pas tout faire d'un coup, soyons raisonnable et nous avons écouté tout le monde, puis choisi une première destination qui doit être faisable. Les ingrédients définis dans cette étape sont là (https://forum.locoduino.org/index.php?topic=922.msg9956#msg9956).

Il faut bien être conscient que plusieurs fonctions doivent coexister dans ce processeur doublé coeur et doté d'un OS dit "temps réel" (freeRtos), donc les développements doivent satisfaire quelques principes nécessaires. Nous allons installer un certain nombre de fonctions (peut-être pas toutes à la fois) et il serait sympa qu'une ouverture aux développeurs (vous) soient possibles.

3) Pourquoi le Wifi ?
Tous le monde a au moins un smartphone et un tour dans les clubs nous montre que les centrales les plus populaires peuvent supporter des applications sur smartphone en intégrant un serveur Wifi. J'ai eu l'occasion de realiser ce concept avec un ESP8266 qui est un des parents de l'ESP32.
Par ailleurs, la plupart des logiciels de gestion de réseau et de matériel ferroviaire (JMRI, RocRail pour n'en citer que deux) savent communiquer par Wifi avec les centrales, y compris celles intégrant DCC++. Donc le Wifi servira à cela.

Comme JMRI en particulier permet d'utiliser des applications gratuites Withrottle (IOS) et Engine Driver (Android), piloter directement notre centrale avec ces applications est une évidence !
Ce qui n'empêche pas d'installer JMRI plus tard, une évolution intéressante pour nous modelistes, qui permet de profiter de toutes les fonctions des applications smartphone

Et rien n'empêche de développer d'autres applications smartphone pour cette centrale !

4) Avec quelle puissance électrique ?
Tous les lecteurs de Locoduino connaissent les LMD18200 et aussi les L298. Le premier est cher et le second un peu limité.
Là nous avons choisi le L6203 de ST Microelectronics car il permet de monter à 4 A pour un prix raisonnable, ce qui est largement suffisant pour la plupart des réseaux, sachant qu'il est possible de faire des booster complémentaires en cas de besoin.

5) Pourquoi un circuit imprimé ?
Tout le monde sait bien que c'est plus simple de monter des composants sur un circuit imprimé. Personnellement j'ai monté tellement de prototypes câblés sur des plaques à pastilles que j'en ai marre maintenant !
Et les fabricants de pcb (en Chine) nous proposent 10 cartes 10 x 10 cm pour 5 $. Avec le port cela fait 15 €, soit 1,5 € par carte : on ne prend pas beaucoup de risques. Mais il faut attendre 

J'ajoute au passage que toutes les fonctionnalités décrites ici n'occupent que peu de composants, donc allons-y !

Par contre le premier circuit qui est en cours de livraison doit être considéré comme un prototype qui servira d'expérience pour les suivants.

6) Pour quelles interfaces humaines (pilotes, conducteurs, postes de conduite...) ?
Nous avons parlé des smartphones : chacun sa manette pour un pilotage manuel.
Idem avec les logiciels de gestion de conduite de trains : sur écran de PC ou tablette, mais la complexité se déporte dans ces logiciels.
Mettre des boutons et des curseurs : pourquoi pas.

Ajouter un afficheur : oui, au moins pour visualiser ce qui se passe et permettre la détection d'erreurs. Là le sujet est vaste !
Je n'entre pas dans le sujet de la configuration et des mises à jour logicielle, vous vous doutez que ce sera très important.

7) Quelle rétrosignalisation ?
C'est là que le bus Can intervient !
L'ESP32 intègre un contrôleur Can intégré et je l'ai testé : ça marche. Chacun comprend, à la lecture de ce Forum, que le Can est résistant, fiable et facile à mettre en oeuvre.
Par ailleurs, nous avons maintenant une expérience non négligeable avec les satellites. Je les ai testé en communication avec l'ESP32 : j'ai confiance. Je pense qu'on va reparler des satellites V2 car cela semble bien compris par de nombreux habitués de Locoduino et ce n'est pas pour rien que Jean-Luc s'est décarcassé pour eux 
D'ailleurs je suis en train de connecter une paires de détecteurs RFID RC522 de chaque coté de ma gare principale pour identifier les trains à coup sûr avec un Nano et les interfaces Can et RFID : c'est presque un satellite V2 !

Personnellement tout est connecté sur un bus Can sur mon réseau et il y a un vraie possibilité d'évolutions, d'ajout de fonctions.
Mais une interface universelle pour les développeurs serait la bienvenue (merci Denis de le pointer).
Yes we Can 

Au final, quoi faire avec cette centrale ?
Tout n'a pas été écrit ci-dessus et la créativité de chacun peut s'exprimer.
Je pense et j'espère que la mémoire de l'ESP32 pourra supporter quelques fonctions en plus du Wifi, du DCC, du Can et permettre le développement de petits automates internes comme mon va-et-vient ou d'autres animations.
L'accès au bus Can, donc à toutes sortes de capteurs et actionneurs va permettre de réaliser de très belles choses que vous serez fiers de présenter dans les salons.

Voilà,

J'espère avoir donné un meilleur éclairage à ce projet 
Et j'ai surement omis des tas de choses (à vos questions ....)

Amicalement
Dominique

[Pyk35]

Bonjour,

Voici une vidéo de l'IHM que j'ai développée pour La Box. C'est un point d'avancement à date, 2500 lignes au compteur à ce stade.




Ne pas s'inquiéter du clignotement, c'est juste une histoire de fréquence de l'IHM vs la fréquence de la caméra. En vrai, tout est net et sans clignotement.

Les grands principes :

* Le code est un ensemble de classes autonomes. La classe principale est dérivée de la classe Adafruit_SSD1306 d'adafruit.
* Le menu a été conçu pour se transformer facilement en librairie. L'utilisation reste assez simple et on peut dériver les classes pour faire notre propre écran. Par exemple, je prévoir un écran pour la saisie de valeurs comme un adresse IP ou un entier.
* Le multilangue est géré, aujourd'hui par des macros, demain on pourra le gérer facilement dynamiquement mais à voir l'intérêt car cela consommera pas mal de mémoire.
* L'idée est de créer dans l'application un objet unique, un singleton, que chaque module pourra appeler par 2 primitives simples.
  o void hmi::addNotification(int addr, uint8_t order, uint8_t value, bool functionState) -> @adresse du train, le type d'ordre, la valeur, la fonction appelée
  o void hmi::addNotification(char* msg) -> Notification de type message libre (20 caractères) en vue d'être stockés dans une pile d'événements. L'idée est que chaque module de l'appli peuvent "logger" des événements importants par ex : connexion d'une trottle, court-circuit, etc.

* l'IHM conserve une mémoire des 10 derniers trains pilotés (un objet train par train). Le stockage est fait dans une pile, à chaque notification, le dernier train piloté est mis en haut de la pile.
* Evidémment, 0 delay dans le code
* Utilisation de la classe OneButton pour gérer les 3 boutons up/down/select.
* Il y a plusieurs tableaux de bord :
 o Tableau de bord de base pour les états OFF et court-circuit. On peut voir aussi les 5 derniers événements.
 o Tableau de bord 1 train : on présente sur l'écran l'état du dernier train avec l'affichage des tension/courant, un barres graphs pour la vitesse, la valeur de la vitesse [0:128], l'indicateur des phares (F0), la dernière fonction pilotée, l'adresse du train, le sens de circulation.
 o Tableau de bord 2 trains : non codé encore mais je n'en vois pas l'intérêt donc il est probable que je le supprime
 o Tableau de bord 3 trains : quasiment identique à 1 train mais en plus petit. Je n'affiche pas les tension/courant et les fonctions. Les 3 trains sont les 3 derniers trains pilotés donc l'ordre change dynamiquement.
 o Une vue de consultation des événements
* Une gestion des log de debug un peu évoluée (enfin un peu mieux que des prints mais pas fou non plus)

Reste à faire :
* Un classe globale de gestion des paramètres en EEPROM
* Le codage des fonctions de type action du menu au cas par cas.
* Menu de saisie des valeurs (@IP, entier)
* L'optimisation de certaines images à convertir en fonction pour économiser de la flash (j'ai commencé avec certains symboles comme le phare (F0) et le barre graph)
* Finir la vue de consultation des événements
* Un stockage dans le Git de Locoduino ?

* et surtout, une première intégration avec vos codes les amis pour augmenter le déverminage...

Merci pour vos remarques que j'attends nombreuses et pertinentes... 

[Dominique]

J'ai peut être oublié de publier le schéma de cette première version de La Box. Le voici :