projet centrale "LaBox" wifi DCC++ Can

[Dominique]

Juste pour éclaircir le débat, un SProg n'est ni plus ni moins qu'un microcontroleur dédié au DCC et à la programmation des décodeurs, et qui peut aussi servir de petite centrale. Ça ressemble furieusement à un Nano chargé de DCC++ ou DCCpp !!

J’ai passé un bon bout de temps à réaliser un tel « Sprog » Locoduino qui, comme le dit Thierry n’est qu’un Nano chargé de DCC++ ou DCCpp légèrement modifié. J’y ai adjoint la partie « puissance » qui n’a pas donné les résultats attendus, donc je vais refaire ce projet avec un bon vieux L298 qui permet de cracher 4A avec ses 2 ponts en parallèle.
En plus, puisque jusque là ça n’est qu’une sorte de « Sprog », j’ai adjoint une passerelle Can et une passerelle Wifi pour piloter un train à partir d’un smartphone.
Le projet n’est pas encore publiable et je manque de temps, pas d’idées, mais est-ce qu’il vous intéresse ?
On pourrait envisager un travail collectif, oui ou non ?


Amicalement
dominique

[msport]

Bonjour Dominique,
j'ai l'impression que toi et Thierry avez déjà mis à disposition sur Locoduino largement mieux qu'une SPROG :
Ton va-et-vient permet de gérer du DCC++ puisque le serial RX/TX est disponible :
https://forum.locoduino.org/index.php?topic=810.msg8888#msg8888
Et la centrale autonome de Thierry permet de programmer les CV sans ordi.
http://locoduino.org/spip.php?article224
https://forum.locoduino.org/index.php?topic=752.msg8459#msg8459

Mais si en plus, tu prévois WiFi et CAN en plus, bravo. Effectivement, il ne manque plus que le temps pour le faire.

[Pyk35]

Dominique,

C’est un très beau projet, une centrale DCC 4A permettrait de couvrir énormément de cas de figure pour moins de 30€.
Alors le wifi en plus, c’est clairement une bonne idée.

Si je peux me permettre, je propose une autre idée. Et si on prenait un bon ESP32 comme ça on profiterait du wifi et du CAN natif ?
On intègrerait la passerelle wifi CAN qui va bien, le DCC+, un L298, et un SN65HVD230 pour le can. On ajouterait un Max 471 pour surveiller le courant Max.
Je veux bien contribuer si vous le souhaitez.

[msport]

Le LMD18200 a l'avantage sur le L298 de ne pas nécessiter l'inversion du signal et d'être à 3A nominal au lieu de 2A. Il a les faveurs de Locoduino dans plusieurs réalisations.
Il n'a qu'un double pont mais on peut prévoir la programmation des CV ailleurs, c'est d'ailleurs plus sur.

[Dominique]

Dominique,

C’est un très beau projet, une centrale DCC 4A permettrait de couvrir énormément de cas de figure pour moins de 30€.
Alors le wifi en plus, c’est clairement une bonne idée.

Si je peux me permettre, je propose une autre idée. Et si on prenait un bon ESP32 comme ça on profiterait du wifi et du CAN natif ?
On intègrerait la passerelle wifi CAN qui va bien, le DCC+, un L298, et un SN65HVD230 pour le can. On ajouterait un Max 471 pour surveiller le courant Max.
Je veux bien contribuer si vous le souhaitez.

Oui c’est une bonne idée. J’ai fait un proto avec un ESP8266 et les chips Can (plus exactement c’est Jean-Luc qui me l’a fait  ). L’ESP32 devient la norme donc je le regarde mais de préférence une version bon marché genre WEMOS Mini. Garder le Nano pour DCC++ me semble plus facile pour commander la centrale en USB. De même j’ai pensé au L298 qui est moins cher que le LMD18200 mais nécessite une interface à 2 sorties inversées moins chère que la différence de prix du LMD. L’originalité sera de regrouper les ingrédients (sans CMS) sur un CI 10x10 cm et de rendre cette centrale assez simple pour un enfant de 4 ans avec un smartphone, mais pas forcément avec un soft pc serveur.
Et ne pas tenter une usine à gaz évidemment, en restant sous les 30€.

On peut essayer de cogiter à plusieurs si ça ne diverge pas !

On est 2 donc je vais créer un sujet dans « vos projets »

[msport]

L'utilisation des deux ponts du L298 en parallèle m'inquiète un peu.
Si l'inversion n'est pas considérée comme rédhibitoire on peut regarder le L6203 donné pour 4A RMS (que j'ai testé fonctionnellement)
Environ 1€ sur eBay.
Prêt à faire le PCB (Eagle) et les tests de base ...
https://www.ebay.fr/itm/5PCS-L6203-ST-ZIP-11-DMOS-FULL-BRIDGE-DRIVER-NEW/392626909730

[Pyk35]

Côté esp32, voici un état des lieux intéressant qui parle notamment de Wemos : https://projetsdiy.fr/quelle-carte-esp32-choisir-developper-projets-diy-objets-connectes/

Je vous propose de partir avec cette puce à 240 MHz (ça change de nos 16 MHz !!!) : ESP32-WROOM-32U. Le 32u n’intègre pas d’antenne wifi onboard mais il y a un connecteur pour mettre sa petite antenne extérieur, la portée est alors bien plus performante. Pour le développement, un modèle 32D peut s’avérer pratique, moins de bagarre sur la breadboard.

Pour le produit, on pourrait partir sur une carte comme celle-là pour 5€ :
https://fr.aliexpress.com/item/4000103411061.html?spm=a2g0o.productlist.0.0.176935f2jcQKrC&algo_pvid=28ad0c71-ce7d-4139-bb1c-130426d293c6&algo_expid=28ad0c71-ce7d-4139-bb1c-130426d293c6-1&btsid=0b0a182b15831901621045148eb97b&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

Pour les PCB, je ne connais pas trop vos habitudes mais pour ma part j’apprécie EasyEda (https://easyeda.com/ , de chez Jlcpcb) car il a notamment l’avantage de permettre de travailler en équipe tout en étant gratuit (mais pas open source) et surtout très simple. Il y a un client pour Windows et mac mais sinon la version en ligne fonctionne nickel sur toutes les plateformes. Un routeur exécutable en local pour Windows/mac/Linux permet de router plus rapidement. On pourrait penser que l’on est coincé avec JLCPCB mais non, on a bien les gerber à la fin. Après la fabrication chez Jlcpcb est tellement efficace... notre carte 10cm x 10cm coûtera moins d’un euro.

Pour les drivers, après probablement un bon débat sur le choix j’imagine, on pourra les intégrer directement sur le PCB (pas de shield). Est-ce que l’on prévoit une voie de programmation (avec un driver 1A par exemple) ?

[Dominique]

J'ai transféré les messages du sujet "Enfin lancé, enfin inscrit !" dans ce nouveau sujet "projet centrale wifi DCC++ Can"
Nous continuerons donc ici 

Amicalement
Dominique

[Dominique]

L'utilisation des deux ponts du L298 en parallèle m'inquiète un peu.
Si l'inversion n'est pas considérée comme rédhibitoire on peut regarder le L6203 donné pour 4A RMS (que j'ai testé fonctionnellement)

J'ai eu l'occasion de tester la mise parallèle des ponts du L298 et c'est présenté officiellement dans la datasheet du L298

Ci-dessous une photo du prototype utilisant une carte comportant un L298 et un support de Nano. Malheureusement les connexions entre le Nano et le L298 ne permettent pas d'utiliser DCC++ sereinement. J'ai donc ajouté à coté mon proto avec un ESP8266 et un Nano.

Mais tu as probablement raison, le L6203 est surement mieux adapté.

[Dominique]

Coté ESP32, le choix est entre le DevkitC et le Wemos D1 mini : si on veut l'interface Can, le premier sera probablement nécessaire (je n'ai pas encore regardé en détail).

De même, peut-on faire tourner DCC++/DCCpp dans l'ESP32 ? Thierry a surement la réponse.
Mais on serait plus tranquille de séparer les fonctions DCC en gardant l'interface série (USB) pour une connexion filaire avec JMRI par exemple (comme un Sprog), des fonctions wifi : j'ai développé un convertisseur du protocole Withrottle (ou Engine Driver) destiné à JMRI en commandes DCC++.
Avec ces applications gratuites, c'est un vrai jeu d'enfant de mettre en route des locos en DCC.

Pour interconnecter l'ESP32 avec le Nano : je l'ai fait avec le bus I2C, ce qui libère les ports série et permet le debugging.

Du coup on peut ajouter un écran Oled comme sur la photo ci-dessus ! Voir un exemple d'écran ci-dessous.

En ce qui concerne l'interface Can, le but est de permettre une rétrosignalisation en adaptant des satellites V1 (ou V2 à venir, peut-être s'il y a de la demande). L'ESP32 est capable d'embarquer pas mal de lignes de code. Un gestionnaire simple me semble possible et là c'est un vrai travail de création collectif, si ça vous tente 

Pour l'alimentation, je verrai bien 2 jacks côte à côte : l'un en 2,1/5,5mm (IEC 60130-10 Type A) pour les alims classiques jusqu'à 4A et l'autre en 3,1/6,5 mm (IEC 60130-10 Type D) pour supporter les alims de PC portable.

[Dominique]

Un exemple d'interface can (uniquement le transceiver est nécessaire)

Les pins pour le Can sont GPIO5->CAN TX et GPIO16->CAN RX.
Le circuit SN65HVD232 (3.3V) est idéal mais le MCP2551 (avec adaptation 5v<->3,3v) est pas mal aussi (si je préfère une version traversante - non-CMS).

[Thierry]

(Je remet mon message au bon endroit, je l'avais posté sur l'ancien fil...)

Vraiment simple en effet comme messagerie! On peut la coder sur n’importe quel langage, même depuis un autre Arduino/esp voire pire, en php ou en basic 

A mon avis, le format de cette messagerie n'a d'intérêt que par son aspect bas niveau qui permet de faire exactement ce que l'on veut en respectant la norme DCC au plus près, mais c'est rebutant si l'on cherche des commandes un peu plus simples.

Il y a deux gros nœuds gordiens à trancher dans tout ça:
Les registres : piloter une locomotive suppose de lui dédier un registre pour les ordres continus comme la vitesse, et éventuellement un autre pour les fonctions (c'est un choix si l'on veut éviter de perdre l'info après une grosse coupure d'alimentation...), mais connaître ou affecter en dynamique des registres selon les engins pilotés à l'instant T est relativement compliqué pour quelqu'un qui ne connait pas le fonctionnement de DCC++ et sa liste de registres limitée en taille.
Les fonctions : activer ou désactiver une fonction particulière relève du chemin de croix pour celui qui ne maîtrise pas le binaire sur le bout des doigts (je rappelle qu'il y a 10 catégories de gens, ceux qui comprennent le binaire et les autres...). Il faut différencier les messages selon les fonctions, se rappeler des fonctions actives ou non pour ne pas toucher aux autres en construisant ce message, et stocker tout ça pour chaque locomotive ou engin piloté...

J'ai pour projet à moyen terme d'ajouter à DCCpp un gestionnaire de locomotives qui permettra de définir au fur et à mesure quelles sont celles qui sont pilotées, avec leurs fonctions associées. C'est ce gestionnaire qui affectera les registres, et contiendra un exemplaire (une instance) pour chaque loco de la classe FunctionsState déjà présente dans DCCpp. Ce type d'architecture devrait permettre de définir une interface texte bien plus simple, du genre "L4  S=-60" qui signifierai 'met la loco 4 à 60 en sens inverse' ou "L3 F17=1" 'active la fonction 17 de la loco 3'... Je pense que la gestion de ces locos par un JMRI ou un 'throttle' s'en trouverai grandement facilitée.

Autre sujet: la version DCCpp qui marche sur ESP32 est réalisée et fonctionnelle. Elle n'est juste pas à disposition parce que j'ai voulu me lancer dans de grands chantiers avec du Wifi, du Bluetooth et un programme Android... Je vais revenir un peu en arrière et pousser la version ESP32 d'ici peu (tout est relatif, hein..), sans ces connecteurs sans fil.

[Dominique]

Voici un peu plus de détails de ce que j'ai en tête (et je m'entête  )

Au départ il existe des applications gratuites sur smartphones : Withrottle (iOS) et Engine Driver (Android) sont des applications bien faites et assez simples Ce sont des postes de conduite pour le logiciel JMRI (jmri.org). Le but est de pouvoir utiliser les fonctionnalités les plus importantes, pour la commande directe de cette centrale.

Cahier des charges :

• connexion au serveur WiFi (ESP12 ou ESP32) en mode point d’accès (ne nécessite pas de box internet avec login et password, ce qui est plus pratique dans les expos).
• Choix des adresses des locos (courtes et longues selon NMRA) au clavier de Withrottle et mémorisé d’une fois sur l’autre.
• Possibilité de piloter 2 locos en même temps avec 1ou 2 smartphones
• La/les locos s’arrêtent automatiquement en cas d’appel téléphonique et lorsque l’application n’est plus en premier plan ou le smartphone mis en veille.
  
• Marche avant et arrière (avec passage par la vitesse 0)
• Fonctions des locos (Light et F1..F28) si supportées.
• Reconnaissance automatique de l’adresse DCC d’une loco posée seule sur les rails.
• Ecran Oled 4 lignes (petites) pour suivre le fonctionnement, et configurer quelque chose
• Interface Can pour agir sur les locos (ralentir, s'arrêter, repartir...) sous contrôle d'un bloc système ou d'un gestionnaire alimenté par une rétrosignalisation
• Réaliser une plateforme matérielle aussi simple et bon marché que possible permettant d'autres applications et possibilités par évolutions logicielles
• Une seule prise d'alimentation (un petit et un gros jack pour utiliser les alims qu'on a en stock)

Il y a déjà un certain nombre de choses faites (voire à refaire) :

• Le serveur Wifi (sur ESP8266) qui reçoit les commandes de Withrottle (ou Engine Driver qui est légèrement différent) et les transforme en commandes DCC++. Pour le moment je n'ai pas implémenté les commandes d'accessoires (ce serait possible avec les versions payantes des applications)
• Les communications I2C entre l'ESP et le Nano, ainsi que l'OLED
• L'adaptation de DCC++ pour prendre en compte les communications I2C


J'imagine un mini-gestionnaire de réseau embarqué s'occupant de la rétrosignalisation avec des satellites sur le Can : vers un réseau ultra simple et ouvert... mais pas facile a configurer !

A un moment j'ai ajouté un mode PWM, mais c'est dangereux car la tension d'alimentation du montage ne doit pas dépasser celle des locos présentes alors que le DCC nécessite une tension plus élevée (j'ai cramé une loco  ) et ça complique le matériel avec un régulateur de puissance supplémentaire.

Je vois que Thierry a aussi des idées donc ça va être interessant !

Qu'en pensez-vous ?
En particulier voyez-vous d'autres applications d'une plateforme de ce type ?

[Pyk35]

Bonsoir,
On vous laisse une journée et vous avancez comme des fous!!  Bravo!

Je réagis donc :

*  L’esp32 dispose de 3 UART donc on devrait arriver à dédier un UART pour le CAN, un pour la console et un pour une connexion directe USB. A contrôler en détail. Ça me peine un peu de voir le nano dans ce montage mais pourquoi pas.
* L’écran Oled, super idée. Résultat pro garantie.
* pour le double L298, pas de problème pour moi.
* Côté CAN, on pourrait embarquer un mode passerelle pour transmettre l’intégralité des trames selon les filtres retenus. On pourrait faire une page d’admin pour configurer la gateway can notamment pour donner les filtres. Un mode bridge CAN pourrait permettre de transmettre les infos venant CAN selon une messagerie au niveau selon les règles du gestionnaire intégré comme proposé.
* pour le gestionnaire CAN, il faudrait le déclarer sous forme json dans un fichier et ne pas chercher à le configurer en web. On ferait une page web pour un import/export de ce fichier json et chacun éditera son json dans un notepad++, json reste lisible.
* Pour la compatibilité avec les applications smartphone, ça serait un plus, peut-être en attendant de faire la notre . Je pensais que l’on pourrait stocker la configuration des locos dans l’esp ce qui permettrait à tous les smartphones de récupérer les locos de la console. C’est vrai que c’est le défaut de la multimauss de ROCO où il faut se palucher les locos dans chaque souris. Un stockage Json semble une bonne solution.
* côté wifi, que la centrale soit point d’accès, c’est très bien notamment en club ou expo par contre à la maison, ça serait gonflant car il faudrait quitter son wifi de la maison pour se connecter à la console et surtout, on perdrait la communication internet du smartphone. Il faudrait donc aussi pouvoir être client wifi.

++

[Dominique]

Les ports Can sur ESP32 - VROOM32 (DEVKIT C  entre autres) sont :
CanTx : GPIO5
CanRx : GPIO4
Ce ne sont pas des UART.
Ces ports sont gérés par un contrôleur Can interne du même type que le MCP2515 ou SJA 1000 décrit dans ce site. Il faut donc utiliser une bibliothèque Can conçue pour l’ESP 32 et ce contrôleur (il en existe plusieurs et voir les articles sur le site éditorial).
Ces 2 ports doivent être connectés à un transceiver Can externe comme le SN65HVD233 (en 3,3v).

Je n’ai pas encore testé le Can sur ESP32 mais ça ne saurait tarder