Messages

1336

Vos projets / Re : Re : projet centrale wifi DCC++ Can

« le: mars 22, 2020, 12:10:49 pm »

Mais je suis tout de même très réservé sur le principe de faire des développements sur la base d’un logiciel « non open source » que nous ne pouvons pas adapter alors que nous sommes tout à fait capables de réaliser nos propres développements. Et sur lequel nous n’avons aucune certitude pour le futur. Mais c’est juste une opinion et chacun peut faire comme il l’entend.

Là je suis d'accord si quelqu'un peut développer une manette open source meilleure que Withrottle, ce qui est possible évidemment. Par ailleurs les manettes d'Antoine sont très chouettes 
Juste ne pas oublier le trait-d'union entre Withrottle et JMRI.

Personnellement et puisque tu nous demandes notre avis, voici comment moi je vois les choses.

-   Un ESP32 qui sert de passerelle WiFi entre des périphériques communicants en TCP (Withrottle, JMRI, manette de Tony, développements propres comme mon controller …) C’est très vaste. Ca peut aussi être quelque chose de plus matériel (moins virtuel) comme la manette de Tony pour peu que l’un implémente dans la manette un codeur en langage DCC++. Ce n’est pas très compliqué et s’apparente à ce qui a été fait pour Withrottle.
-   Un Arduino Nano qui fait office de Base Station pour DCC++ en attendant un déploiement de DCCpp sur ESP32
-   Ces deux cartes étant implantées sur un PCB, je verrais bien sur le PCB l’implantation d’un pont en H (18200 ou mieux carte 4A dont vous parliez)
-   L’emplacement pour un second pont en H (pour une voie de programmation optionnelle) qu’il serait possible d’implanter ou non selon le choix de chacun.
-   Et bien sûr les mesures de courant et de tension pour les sécurités.
-   Et puis des écrans oled, c’est vrai que ça fait chic pour tracer l’activité ! Et c’est pratique.

Voilà à quoi je me limiterais. Cela ferait donc une (petite) central DCC++ pouvant être pilotée par de nombreux périphériques, pour certains totalement logiciels comme JMRI ou mon controller, d’autres logiciels avec conversion de signaux comme Withrottle, d’autres très matériels avec des boutons et des encodeurs rotatifs pourquoi pas. On voit bien que ça devient une centrale très universelle avec un point de convergence, DCC++ qui fait l’unanimité.

Cette centrale, je me répète, pouvant disposer ou non des composants électroniques permettant de disposer ou non d’une voie de programmation et implantés ou non.

Il n’y a pas pour moi de nécessité de disposer du CAN sur cette carte.

Automate ou gestionnaire font pour moi l’objet d’un autre projet (en lien certes) mais sinon, nous ne sortirons jamais rien. Bien sûr, gestionnaires et automates sont des périphériques à part entière comme ceux que j'ai cité car ils se servent de cette Base Station pour transmettre leurs ordres aux locomotives.

Je suis totalement convaincu et je pousserai toujours pour l’utilisation des satellites et de la communication en CAN pour le gestionnaire, l’automate, la rétrosignalisation, les commandes d’aiguillages, de feux de signalisation etc… etc… mais je pense que vous avez bien compris que c’est pour moi un autre projet.

Christophe

Là, par contre, je te rejoins grandement, avec ces quelques différences selon mon point de vue :

• Le Nano pour DCCpp : on attend de savoir si DCC++ est dispo sur ESP32 : on n'est pas à un mois près
• Le 2ème pont en H me semble un coût supplémentaire et prend de la place sur une version simplifée au coût minimal (on peut programmer sur voie principale en prenant des précautions avec quelques tests logiciels). Si la majorité le réclame, une version plus complète est toujours possible.
• Le Can ne coûte rien puisqu'il suffit d'équiper ou non le CJMCU-230, le driver de ligne, et les prises RJ11 (qui prennent de la place aussi)
• Je suis d'accord que les développements de gestionnaire, automates, etc.. et même de gestion des satellites sont parfaitement séparables du projet de base

Ce serait interessant d'évaluer la taille d'un PCB avec toutes ces options (2eme pont et Can).

Donc nos points de vue peuvent converger et l'avis de nos amis et collègues est attendu 

1337

Vos projets / Re : Re : projet centrale wifi DCC++ Can

« le: mars 22, 2020, 11:44:47 am »

Par exemple, je n'envisage pas de conduire mes trains avec un mobile. Ce n'est pas une nécessité.
Il faut pouvoir commander bêtement avec un ou plusieurs boutons qui seraient sur la Box et un simple TCO physique avec des vrais boutons et des LED.
Pour moi, c'est ça la brique de base, avec DCCpp.
Mais avec un CAN pour commander les aiguilles, le retour d'information, ...
Pensez à tous ceux qui, comme moi, aimeraient comprendre comment ça marche :
On tourne un potar, on appuie sur un bouton, on allume une LED, ça c'est du vrai et on essaie de suivre comment ça se passe dans la programme.

Parce que si on utilise le JMRI via le wifi pour utiliser le CAN, on y comprend que dalle.
Ce n'est pas par là qu'il faut commencer.
Ne perdez pas en route ceux qui essaient de vous suivre.
Denis

Merci Denis,
Voilà une réponse comme j'en attends, avec (c'est trop facile) une petite pointe négative sur ce dont on a pas (encore) besoin, parce qu'on ne connait pas, ce qui est excusable évidemment.
Le Wifi fait partie de l'ESP32  donc ne coûte rien, il peut toujours être inactif. Ce processeur double coeur a de multiples avantages par ailleurs.
Personnellement je suis comme Denis, je pilote mes trains avec des potars :
et les aiguilles avec des inverseurs :

Mais  quand j'ai vu la facilité avec laquelle mon petit fils utilise Withrottle à 3 ans 1/2, comparativement à la prise en main de JMRI, je pense que tu devrais essayer un de ces jours.

1338

Vos projets / Re : Re : projet centrale wifi DCC++ Can

« le: mars 22, 2020, 10:27:14 am »

Alors que je viens tout juste de terminer cette première brique, je me rends compte qu’il y a tout de même une grosse lacune et qu’il est bien exagéré d’appeler ceci « centrale DCC ».

En effet, WiThrottle qui au passage est totalement verrouillé et pas du tout open source, ne permet pas de faire le moindre réglage sur les décodeurs ni même de lire l’adresse d’une locomotive. C’est pour cela que vous voyez deux locomotives sur la vidéo, j’avais complètement oublié l’adresse de la 150 Y et il m’était impossible de l’utiliser.

On ne peut pas avoir que des locomotives avec la seule adresse 3.

Tout au mieux, je pense qu’il faut considérer ce projet à ce stade comme une manette de commande qui ne peut se dispenser d’un logiciel comme JMRI et en particulier de son extension Decoder Pro !

Ou alors, il faut implémenter dans l’ESP32 une partie logicielle qui permettra de lire et écrire sur les décodeurs, modifier les adresses et certains paramètres comme le volume du son…

Dans la mesure où l’ambition de cette centrale est assez modeste, cette programmation devra pouvoir se faire sur la voie principale avec une seule carte moteur donc.

Donc ce n’est pas fini. Moi je suis plus tenté de faire une centrale autonome et je propose donc développer la partie programmation des décodeurs avec une IHM qui va bien sur l’ESP32.

A suivre donc.

Christophe

Ton point de vue me semble un peu négatif mais la discussion est ouverte !

Les fonctions de programmation de décodeur et surtout de lecture de l'adresse ont été intégrées à ma version 8266 et c'est l'objet du mini écran Oled et des boutons +, -, SEL qui sont prévus au minimum (je n'ai pas attendu pour programmer les décodeurs sur la voie principale). Withrottle est effectivement un logiciel fermé mais gratuit et utilisable à condition de leur en demander l'autorisation, ce que j'ai déjà obtenu (comme quelques constructeurs de centrales US).

Comme Withrottle permet de choisir l'adresse DCC et l'enregistre en local pour les fois suivantes, il est facile de caractériser ses propres locos dans son propre smartphone (pour un usage personnel non partagé, ce qui sera le principal cas même dans les clubs). Mais c'est vrai qu'il est limité dans sa version gratuite (Lite). Sa version payante (PRO) est plus complète mais elle nécessite JMRI, ou beaucoup plus de logiciel dans le serveur wifi.
Il ne faut pas oublier également quelques limitations du DCC++ (il n'interroge pas tous les décodeurs). La plupart d'entre nous s'en arrange.

C'est pour cela que cet ensemble Withrottle + JMRI + Centrale wifi a du sens à la fois pour une large population de modélistes qui pourront démarrer simple sans JMRI, puis l'intégrer plus tard pour profiter des fonctions plus sophistiquées (décoder Pro, panel Pro, etc..).
Pour ceux qui ont déjà JMRI, Withrottle restera une manette wifi vis à vis de JMRI et la centrale Wifi ne sera qu'une centrale wifi.

Par contre, l'ajout du bus Can ouvre des possibilités à d'autres combinaisons, notamment d'autres logiciels de circulation (y compris de simples automates intégrés à l'ESP32, ne rêvons pas, un gestionnaire complet ne tiendra pas ou il faudra ajouter d'autres processeurs, et encore... ) et les bénéfices d'un bus fiable et rapide sur lequel il est simple de greffer des éléments d'IHM (TCO, postes d'aiguillages, etc..) et surtout les satellites à (re)découvrir pour la rétrosignalisation et les appareils de voie.

Je comprends les doutes : il ne s'agit pas de faire LA-centrale-universelle-qui-fait-tout, mais une plateforme minimale qui a des atouts à exploiter, que ceux qui voient des opportunités en profitent.

En ce qui concerne les "simples automates intégrés à l'ESP32", il s'agit encore de profiter de l'occasion pour satisfaire des besoins des petits réseaux, projets simples, automates de circulation comme un va-et-vient ou des animations de décor via le Can.

J'invite donc les lecteurs de ce fil à indiquer ce qu'ils souhaitent et ce qu'ils en penses de leur point de vue.

Bien amicalement
Dominique

1339

Vos projets / Re : Re : projet centrale wifi DCC++ Can

« le: mars 22, 2020, 09:14:21 am »

Je suis parti d’un code que Dominique avait trouvé sur internet : https://github.com/vhar/withrottle

J’ai corrigé quelques bugs sur les requêtes TCP et je l’ai adapté à l’ESP32 car à l’origine, il a été développé pour l’ESP8266.

Il faut que je mettre le code au propre et je le déposerai très bientôt sur le github de Locoduino (à moins que certains soient si pressés que je doive leur envoyer en l’état).

Bravo Christophe,
J’avais fait fonctionné ce code sur 8266, ajouté le support d’Engine Driver, la connexion à DCC++ en mode I2C pour libérer les ports serie et intégré l’écran Oled.

Oui je suis preneur de ton adaptation à l’ESP32 pour comprendre ce qui change et réintégrer les ajouts.

Cordialement
Dominique

1340

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 20, 2020, 08:49:57 am »

Une chose sera sûre, en cas de panne wifi ou coupure, les trains s’arrêtent. C’est déjà le cas avec les applications smartphone : Withrottle : un appel téléphonique arrive -> le train s’arrête  !
Idem si la batterie est trop faible !

Dans les spécifications du projet, nous prendrons en compte tous les cas possibles de sécurité.
Et tester, tester et tester ...

1341

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 19, 2020, 06:21:54 pm »

Bravo 

1342

Vos projets / Re : Re : projet centrale wifi DCC++ Can

« le: mars 19, 2020, 01:38:01 pm »

Dès que l'on aura une idée précise des messages sur le CAN, je ferai tout pour que mon gestionnaire soit compatible.

Ah une bonne nouvelle ! On t’aidera.

1343

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 19, 2020, 01:34:36 pm »

Je suis tout à fait d’accord avec Michel : il n’y a pas d’IHM du tout dans cette centrale. Le petit écran n’est là que pour juger de son bon fonctionnement.

Évidemment un réseau sans IHM, sans TCO, c’est dommage.

Un TCO sur Can c’est facile à faire, simplement à partir des messages Can qui circulent (occupations, libérations, commandes aiguilles et itinéraires, commandes des trains, etc..). Je publierai le mien 

Là c’est extérieur à la centrale. Il est évident qu’il existe des solutions logicielles sur PC, Mac, RPi qui doivent pouvoir s’interfacer à cette centrale sans passer par le Can éventuellement.

Svp, montrez un schéma de votre cas personnel, de vos attentes.

1344

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 19, 2020, 12:33:36 pm »

Dans cette image, il ne faut pas voir le mot "Arduino" comme un seul et unique processeur ! Mea Culpa si ça vous enduit d'erreur 



Je démultiplie et je donne des exemples :

• boite verte, la centrale DCC++ : on a tous plus ou moins réalisé une ou plusieurs centrales minimales avec un Nano et le logiciel DCC++ de Gregg ou celui DCCpp de Thierry. Nous avons là un processus (générateur DCC) qui peut être aussi un processeur dédié. Généralement on utilise DCC++/pp soit en système autonome (comme mon Va-et-vient) ou piloté par une ou des manettes (comme Antoine avec un éméteur/récepteur), ou par un PC (avec JMRI ou le gestionnaire de Pierre). Dans cette application, on a besoin de piloter uniquement des locos (traction et fonctions) et/ou aussi piloter des accessoires de voie (aguilles). DCC++ sait le faire sous forme de trames DCC (NMRA) sur les rails. Un peu de rétrosignalisation est aussi possible
• Donc attaquer DCC++ par le port USB/série à la mode SProg est un minimum syndical !
• Je n'ai pas fait figurer de port Ethernet RJ45 mais j'ai plutôt privilégié l'accès Wifi. Il faut donc un serveur wifi qui assure la connexion sans fil et transmet dans les 2 sens les ordres DCC++. C'est le mode de fonctionnement de JMRI. Les messages échangés sont ceux de DCC++ . Le serveur wifi (en jaune sur le schéma) peut être séparé du processeur DCC++ (comme je l'ai montré sur la photo du post ici : https://forum.locoduino.org/index.php?topic=922.msg9656#msg9656 avec un ESP8266 et un Nano.
• On peut évidemment profiter du serveur Wifi pour traduire les commandes de manettes "non DCC++" en commandes DCC++. C'est déjà fait pour ma part avec les applications Withrotle et Engine Driver (au passage on découvre un autre type de messages, format et contenus différents). C'est le mot "traducteur" sous la boite jaune "Connecteur Passerelle"
• Après il y a 2 gros trucs qui ne parlent pas à tout le monde de la même façon : le CAN et le gestionnaire
• Pour le Can, l'idée simple est l'utilisation des satellites présentés à Orléans et Lille mais malheureusement peu utilisés. Rappel : c'est l'interface la plus simple possible et fiable entre le système de gestion et la rétrosignalisation (capteurs et actionneurs). Mais cela apporte des contraintes :
  - Il y a l'interface SAM (boite orange - une bibliotheque ou pas) qui gère les communications Can et présente les appareils de façon standardisée en masquant les détails (quelle led dans quel signal par exemple)
  - JMRI n'a pas encore d'interface compatible SAM, ce qui pousse ses utilisateurs vers d'autres interfaces décrites dans le sujet ad hoc http://forum.locoduino.org/index.php?board=22.0. C/MRI est probablement une brique à ajouter dans cette architecture (après étude de faisabilité et prototypes).
  - Le système de gestion n'est pas forcément intégré dans ce projet, comme le soulignent Denis et Pierre, ce qui est le cas de JMRI évidemment, mais ce qui n'empêche pas d'en mettre un comme un automate qui serait très utile si nous trouvons un système de configuration simple et efficace : zone de forte créativité possible ici !
• Maintenant il est envisageable de remonter la rétrosignalisation par le Wifi ou l'USB : je ne sais pas si JMRI en est capable, ou d'autres gestionnaires sur PC. Il faudrait surement une interface spécifique type C/MRI déjà mentionné.
• Enfin, le Gestionnaire (en bleu) qui peut être complètement extérieur ou simple et interieur ou une combinaison des 2 si on imagine une extension des commandes DCC++ : encore une zone de créativité possible ici !

Voilà une première tentative pour décortiquer ce projet et vous demander ce qui vous semble indispensable ou qu'il manque dans cette boite !
On ne peut pas encore affirmer s'il faudra 1, 2 ou 3 Arduinos pour y parvenir mais, après un phase de maquettes et prototypes, j'espère fortement qu'on aboutisse à une plateforme "Locoduino" assez universelle pour couvrir de nombreux cas d'usage et peu onéreuse.

Bien cordialement et bonne santé surtout.

Dominique

1345

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 19, 2020, 10:56:09 am »

Un mot pour dire que vos réactions vont dans le sens attendu : on ne vise pas une usine à gaz, on définit les modules nécessaires et les extensions probables ou souhaitables.
On en déduira les types et formats de messages d’échanges et les messages ensuite.

Je comprends ces 3 avis car nous avons des points communs dans nos projets. Mais j’aimerai avoir 2 autres avis :

- celui de la communauté JMRI qui est concernée par le fait que DCC++ est compatible et qui n’a pas encore manifesté son intérêt pour les satellites.

-celui des experts en programmation/performances pour évaluer la faisabilité de l’intégration de plusieurs processus dans l’ESP32 ( avec DCC++ ou pas).

Je rappelle que, si j’imagine à la cible une petite plateforme pour petits/moyens réseaux, simple à utiliser pour élargir l’attrait de notre discipline, il est tout à fait possible de passer par des stades de prototypes.

1346

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 18, 2020, 07:49:29 pm »

Ou plus simple avec 2 transistors et 4 résistances :
A noter : When using the ESP32 with Arduino IDE, the default I2C pins are GPIO 22 (SCL) and GPIO 21 (SDA)

1347

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 18, 2020, 05:30:35 pm »

Oui c'est ça, le trait sous le traducteur est bien le lien "transparent" comme l'entrée USB série. La Box serait comme une SProg.
La question qui se pose est "sous quelle forme donner accès au port USB de l'ESP32" : faut-il ajouter sur le PCB un convertisseurs serie/USB et une prise USB sur le boitier ?

Cédric demande également de pouvoir rendre accessible le bus I2C avec un prise 3pins (SDA, SCL, GND) et probablement en 5V donc avec des convertisseurs de niveau (2N7000)..

1348

Vos projets / Re : projet centrale wifi DCC++ Can

« le: mars 18, 2020, 02:34:20 pm »

Bonjour à tous,

Cette discussion sur le multitâche, multi-core de l’ESP32 me conforte sur le bon choix de ce processeur pour ce projet dont la difficulté va se situer dans le logiciel, bien évidemment.

Il est donc important de lister les tâches qui vont résider dans ce processeur et les messages qui devront passer de l’une à l’autre (ou les autres).

• La première est le générateur DCC++ matérialisé dans la bibliothèque DCCpp que Thierry met au point en moment, s’il a le temps. Cette tache comprend le générateur binaire sous interruption qui va traduire sur une broche de l’ESP32 les contenus des registres des trames DCC (traction locos répétitives et fonctions locos non répétitives) en fonctions des commandes DCC++ qui proviendront d’autres tâches :
• Le serveur wifi qui peut avoir 2 types de client : les apps smartphones Wittrottle ou EngineDriver qui envoient des commandes compatibles JMRI mais pas DCC++.
  
• il faut donc insérer un traducteur de commandes entre ce client wifi et DCC++
  
• ou un client gestionnaire si on choisit de piloter les locos depuis JMRI, capable d’envoyer des commandes DCC++, le traducteur n’ayant plus lieu d’être.
  
• les communications sur le bus CAN, soit pour piloter DCC++ à distance (probablement en concurrence avec un/des smartphone/s) à partir d’un gestionnaire sur Can (il n’y en a pas encore sauf chez moi), soit pour accéder à la retrosignalisation des Satellites, ce qui peut induire :
  
• soit un « mini » gestionnaire intégré dans l’ESP32 qui ne serait probablement pas « complet »,
  
• soit une passerelle Can/wifi pour mettre cette retrosignalisation à disposition d’un gestionnaire wifi.
  
• enfin une boîte de configuration de tout cela. Je n’imagine pas tout mettre dans ce pauvre ESP32, je vois plutôt des projets dérivés sur une même plateforme matérielle.
  

Un petit rappel sur le synoptique ci-dessous.

Je n’ai pas forcément listé toutes les opportunités que cette plateforme offrirait, vous pouvez les compléter.

Personnellement j’ai déjà fait le traducteur 3, à refaire au propre dans ce projet. Avec quelque satellites et un micro-gestionnaire, je vois bien le petit réseau que mon petit fils attend dans sa nouvelle chambre 

Bon confinement à tous!
Dominique

1349

Composants / Re : Article de blog sur les attiny85.

« le: mars 18, 2020, 01:46:28 pm »

Bonjour,

Un grand merci pour ce partage qui permettra aux lecteurs des articles de Christian de trouver quelques compléments utiles, concrets et pratiques, notamment sur les petites cartes (en évitant les publicités).

Bien cordialement
Dominique

1350

Vos projets / Re : Re : projet centrale wifi DCC++ Can

« le: mars 17, 2020, 11:07:02 am »

Il m’intéresserait d’appliquer cela à ma passerelle CAN/WiFi car c’est exactement la problématique.

Ce dont on aura besoin aussi dans la "Box". Super