LOCODUINO

Parlons Arduino => Vos projets => Discussion démarrée par: Dominique le mars 02, 2020, 11:08:13 am

Titre: projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mars 02, 2020, 11:08:13 am
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
Titre: projet centrale wifi DCC++ Can
Posté par: msport le mars 02, 2020, 03:25:33 pm
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.
Titre: projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 02, 2020, 08:43:50 pm
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.
Titre: projet centrale wifi DCC++ Can
Posté par: msport le mars 02, 2020, 09:11:11 pm
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.
Titre: projet centrale wifi DCC++ Can
Posté par: Dominique le mars 02, 2020, 10:38:19 pm
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  ;D). 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 »
Titre: projet centrale wifi DCC++ Can
Posté par: msport le mars 02, 2020, 11:45:39 pm
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
Titre: projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 03, 2020, 12:21:53 am
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) ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 03, 2020, 09:10:49 am
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  ;D

Amicalement
Dominique
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 03, 2020, 09:21:15 am
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é.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 03, 2020, 09:34:43 am
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  ;) :D ;D

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.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 03, 2020, 10:49:07 am
Un exemple d'interface can (uniquement le transceiver est nécessaire)
(https://blog.danman.eu/wp-content/uploads/2018/10/IMG_20181030_210918-e1540931831133-768x576.jpg)
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).
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 03, 2020, 11:25:16 am
(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  ;D

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.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 03, 2020, 05:39:33 pm
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 03, 2020, 08:40:10 pm
Bonsoir,
On vous laisse une journée et vous avancez comme des fous!!  ;D 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.

++
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 03, 2020, 10:06:06 pm
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  :D
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 06, 2020, 01:33:27 pm
Bonjour à tous,

Quelques questions :

Comment voyez-vous l'alimentation ?
On aurait une alimentation extérieur de 18V et il faudra l'abaisser pour l'alimentation de la carte donc l'ESP32.
L’entrée Vin du «ESP32 DEVKIT» doit fonctionner entre 4,5 et 12 volts. Un régulateur (NCP1117) sur le circuit abaisse la tension à 3,3 volts et fournit un courant maximum de 800ma. Le ESP32 fonctionne entre 2,2 et 3,6 volts.

Je propose de transformer le courant en 5V pour la carte. Il nous faut donc un convertisseur DCDC 18V->5V 1A par exemple.
On peut trouver ce genre de composant :
https://fr.rs-online.com/web/p/regulateurs-a-decoupage/1933998/
https://fr.farnell.com/tracopower/tsr-1-2450/convertisseur-dc-dc5v1asip/dp/1696320
Ayant déjà utilisé des Traco, j'ai un petit faible pour le dernier.

Concernant le SN65HVD233, cela me va bien mais on ne le trouve pas en traversant. Dominique est-ce un point si bloquant pour un voire 2 composants ?

Pour surveiller le courant, étant donné que l'on veut aller jusqu'à 4A, on élimine le max471. Il reste l'ACS712 qui fonctionne  en 5V et non en 3.3V. Voyez vous d'autres composants pour cette fonction ? Est-ce que ca serait ce composant qui ferait la détection de court-circuit ou un montage plus instantané qui ne passerait pas par le microcontroleur ?
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 06, 2020, 06:49:43 pm
Bonjour Pik35 (Rennes, St Malo, Dinard, Cancale ? tu as un prénom ?)

Bonjour à tous,

Quelques questions :

Comment voyez-vous l'alimentation ?
On aurait une alimentation extérieur de 18V et il faudra l'abaisser pour l'alimentation de la carte donc l'ESP32.
L’entrée Vin du «ESP32 DEVKIT» doit fonctionner entre 4,5 et 12 volts. Un régulateur (NCP1117) sur le circuit abaisse la tension à 3,3 volts et fournit un courant maximum de 800ma. Le ESP32 fonctionne entre 2,2 et 3,6 volts.

Je propose de transformer le courant en 5V pour la carte. Il nous faut donc un convertisseur DCDC 18V->5V 1A par exemple.
On peut trouver ce genre de composant :
https://fr.rs-online.com/web/p/regulateurs-a-decoupage/1933998/
https://fr.farnell.com/tracopower/tsr-1-2450/convertisseur-dc-dc5v1asip/dp/1696320
Ayant déjà utilisé des Traco, j'ai un petit faible pour le dernier.
ou celui-là : AMSRI-7805-NZ qui fourni 500mA largement suffisant à mon avis, pour 3€
https://www.tme.eu/en/details/amsri-7805-nz/dc-dc-converters/aimtec/ (https://www.tme.eu/en/details/amsri-7805-nz/dc-dc-converters/aimtec/)

Citer
Concernant le SN65HVD233, cela me va bien mais on ne le trouve pas en traversant. Dominique est-ce un point si bloquant pour un voire 2 composants ?
Si on ne peut pas éviter le CMS on fera une exception : il faudra que certains d'entre nous soudent ce composant pour ceux qui ne peuvent pas. L'entr'aide fonctionne bien !
Sinon il reste la possibilité de souder une petite carte breakout de ce type :
https://www.ebay.com/itm/TJA1050-CAN-controller-interface-module-bus-driver-interface-module-NEW-/142673037587 (https://www.ebay.com/itm/TJA1050-CAN-controller-interface-module-bus-driver-interface-module-NEW-/142673037587) ou plutôt
https://www.ebay.com/itm/SN65HVD230-CAN-bus-transceiver-communication-module-For-Arduino-AT/313017061996?hash=item48e145526c:g:CmkAAOSw69BeXmbx (https://www.ebay.com/itm/SN65HVD230-CAN-bus-transceiver-communication-module-For-Arduino-AT/313017061996?hash=item48e145526c:g:CmkAAOSw69BeXmbx)
C'est juste une barette de 6 pattes pour le second  ;D

Citer
Pour surveiller le courant, étant donné que l'on veut aller jusqu'à 4A, on élimine le max471. Il reste l'ACS712 qui fonctionne  en 5V et non en 3.3V. Voyez vous d'autres composants pour cette fonction ? Est-ce que ca serait ce composant qui ferait la détection de court-circuit ou un montage plus instantané qui ne passerait pas par le microcontroleur ?
L'ACS712ELCTR-05B-T suffirait (5A), mais c'est aussi  en CMS ou sous cette forme de carte à adapter :
https://www.ebay.com/itm/1pcs-5A-ACS712ELCTR-05B-Range-Hall-Current-Sensor-Module/253045596473?hash=item3aeab16139:g:R6IAAOSwJq1ZaC61 (https://www.ebay.com/itm/1pcs-5A-ACS712ELCTR-05B-Range-Hall-Current-Sensor-Module/253045596473?hash=item3aeab16139:g:R6IAAOSwJq1ZaC61)
ou un simple ampli op avec ses résistances pour fixer le gain, là c'est facile en traversant.

Sur mon réseau la détection de court-circuit se fait avec un Max471 (je suis en N et avec 8 locos ça réagit très vite). J'ai juste modifié un peu la mesure de courant logicielle pour qu'elle soit plus rapide. En même temps j'affiche le courant instantanné à tout moment. Passer par le microcontroleur devrait suffire.

Petite question au passage : pour le Jack d'alim : un seul ou 2 (1 gros+ 1 petit ) ou un bornier à vis (mais autant éviter d'être obligé de charcuter un cable d'alim à découpage secteur !

Je vois que ça progresse bien ! Merci de ta participation.
Dominique
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 06, 2020, 09:30:51 pm
Dominique,

J'ai mis à jour mon profil, je m'appelle Cédric, 44 ans et je suis de Dinard (juste à côté en fait, Pleurtuit). Désolé pour l'anonymat, ce n'était pas voulu :)

Pour l'alimentation, je partira sur un truc comme ça :
https://fr.aliexpress.com/item/32848625402.html?spm=a2g0s.9042311.0.0.33886c37zejE0W

On est avec le connecteur classique 5.5*2.1 que l'on retrouve partout. Je propose que l'on soude sur le PCB ceci :
https://fr.aliexpress.com/item/4000034340966.html?spm=a2g0o.productlist.0.0.3b696f55YVDI1X&algo_pvid=823fa3d9-99bc-4305-8e53-bc80e7ae7fa8&algo_expid=823fa3d9-99bc-4305-8e53-bc80e7ae7fa8-0&btsid=0b0a01f815835254451058952e9621&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

Je ne suis pas très fan d'un second connecteur à vis, je ne trouve pas ça hypra propre. On pourrait par contre associer cette pièce pour permettre de supporter toutes les sources d'énergie :
https://fr.aliexpress.com/item/32990462283.html?spm=a2g0o.detail.1000014.38.24d43f8fSE8m1d&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.13338.128125.0&scm_id=1007.13338.128125.0&scm-url=1007.13338.128125.0&pvid=ff49e2e4-dd50-4dcd-9eb8-b1dc175d1427

Citer
ou celui-là : AMSRI-7805-NZ qui fourni 500mA largement suffisant à mon avis, pour 3€
https://www.tme.eu/en/details/amsri-7805-nz/dc-dc-converters/aimtec/
=> Nickel !

Citer
https://www.ebay.com/itm/SN65HVD230-CAN-bus-transceiver-communication-module-For-Arduino-AT/313017061996?hash=item48e145526c:g:CmkAAOSw69BeXmbx
C'est juste une barette de 6 pattes pour le second  ;D
=> Celui-ci me va bien !

Citer
L'ACS712ELCTR-05B-T suffirait (5A), mais c'est aussi  en CMS ou sous cette forme de carte à adapter :
https://www.ebay.com/itm/1pcs-5A-ACS712ELCTR-05B-Range-Hall-Current-Sensor-Module/253045596473?hash=item3aeab16139:g:R6IAAOSwJq1ZaC61
ou un simple ampli op avec ses résistances pour fixer le gain, là c'est facile en traversant.
Là ça me dérange beaucoup plus. Je pensais souder en direct un L298N sur notre PCB, sans prendre une carte breakout, en pontant les 2 drivers pour en voir qu'un seul donc la mesure de courant se prendrait directement sur le PCB, pas de connectique. Ca ferait un PCB super propre !
https://www.aliexpress.com/item/5PCS-L298N-ST-DUAL-FULL-BRIDGE-MOTOR-DRIVER-IC-ZIP-15/32662999247.html?spm=a2g0s.9042311.0.0.3f876c37TQZjPy

Pour la détection de court-circuit à base d'AOP, je ne maitrise pas assez les calculs pour le concevoir. Tu serais faire le croquis et les calculs qui vont bien ? Je trouverais quand même bien cool d'afficher sur l'écran le courant instantané. Il faut donc trouver une solution, mais je me propose si cela arrange de faire la commande de PCB pour les volontaires et de souder les quelques composants CMS les autres seraient alors à la charge de chacun. A voir avec "msport" qui s'est proposé également.
Pour ceux qui ne sont pas à l'aise du tout avec l'électronique, j'ai un jeune de 15 ans à la maison qui serait ravis de se faire 3 sous ;)

Comment est-ce que l'on peut se partager un fichier pour préparer la BOM avec les liens vers les sites de e-commerce ? Une feuille excel partagée ou un tableur google doc pourrait être une solution. Quelle est votre meilleure expérience en la matière ?

A+

Cédric


Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 07, 2020, 09:13:24 am
Dominique,

J'ai mis à jour mon profil, je m'appelle Cédric, 44 ans et je suis de Dinard (juste à côté en fait, Pleurtuit).
Étonnant, l’année dernière le 1er septembre je suis passé à Pleurtuit ! J’étais à Dinard. J’aime bien cette région. Moi j’ai 72 ans, je prends mon temps.

Citer
Pour l'alimentation, je partira sur un truc comme ça :
On est avec le connecteur classique 5.5*2.1 que l'on retrouve partout. Je propose que l'on soude sur le PCB.

Je ne suis pas très fan d'un second connecteur à vis, je ne trouve pas ça hypra propre. On pourrait par contre associer cette pièce pour permettre de supporter toutes les sources d'énergie :
Oui. Le but est d'utiliser une alim qu'on a déjà dans un tiroir. Pour le HO (18 ou 19V) ça correspond aux alims de PC portable. Il y en a qui on un gros jack (6,5mm) : j'ai commandé un convertisseur 6,5 <-> 5,5 mais le vendeur s'est trompé et ça ne correspond pas. Ton convertisseur Jack-bornier me semble plus adapté.

Citer
Là ca me dérange beaucoup plus. Je pensais souder en direct un L298N sur notre PCB, sans prendre une carte breakout, en pontant les 2 drivers
Oui pour souder le pont.
D’après l’expérience de Msport, je partirai plutôt sur le L6203 : un seul canal pour 4A. Je vais le tester. On mettra un peu de composants discrets autour (un transistor ou inverser le DIR pour alimenter IN1 et IN2).

Oui, je vais faire un tableau (Bom) avec les liens fournisseurs. J'ai l'habitude de commander chez tme.eu (c'est du pro, moins risqué) mais on peut mettre une colonne supplémentaire pour d'autres fournisseurs perso.
Je vais essayer de faire le schéma avec les choix de composants en même temps (cela m'oblige à faire les "devices" pour mon logiciel de CAO de CI).

à bientôt !
Dominique
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 07, 2020, 06:09:53 pm
Salut Dominique,

Je te remercie pour la mise en relation avec Christophe, c'est en effet assez incroyable comme coïncidence. Nous avons pas mal échangé et on a prévu de se voir la semaine prochaine à mon club de Dinan (Les amis du rail Dinannais) ! Il m'a aussi parlé de votre rencontre annuelle en Bretagne !

Citer
J'ai l'habitude de commander chez tme.eu (c'est du pro, moins risqué)

TME est en effet très bien mais c'est cher. Le L6203 coute 6.72€ chez TME, sur AliExpress, j'en ai 5 pour 5.14€ port compris. Après les délais ne sont pas les mêmes donc pour un proto, c'est bien.
https://fr.aliexpress.com/item/32906357507.html?spm=a2g0o.productlist.0.0.110f5e3e3CbwkO&algo_pvid=4ce4eaa7-b63a-45b7-9ab6-cc7f739e8a3d&algo_expid=4ce4eaa7-b63a-45b7-9ab6-cc7f739e8a3d-0&btsid=0b0a119a15835960659286701ef034&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_

Côté câble du L6203, j'ai trouvé ce schéma :
http://mech.vub.ac.be/teaching/info/mechatronica/finished_projects_2012/Twinbot1/images/component_selection_clip_image006_0000.jpg

On part la-dessus ? Pourquoi voyais-tu la nécessité de mettre un transistor ? Tu vois un problème à connecter les IN sur des Pin de l'ESP32?

Il faudrait que l'on répartisse les jobs sur ce projet. Pour ma part, je n'ai pas un temps infini en raison de mon job mais j'aimerai contribuer et je ne sais pas trop comment. Je ne voudrais pas froisser qui que ce soit non plus par rapport aux habitudes du Locoduino club...

Pour le développement de PCB, j'apprécie EasyEda par rapport à l'aspect collaboratif, son prix (0€) et sa simplicité mais je comprends que chacun ait ses habitudes. Eagle reste la référence dans le domaine mais carrément moins accessible de mon point de vue.

Dans les rôles, il faudrait définir qui travaille sur les activités du projet :

On pourrait commencer à créer un dépôt sur le https://github.com/locoduino. On pourrait mettre le fichier de la BOM dessus et d'autres documents.

Pour ma part, j'utilise les outils suivants :



Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 07, 2020, 09:07:36 pm
... un problème à connecter les IN sur des Pin de l'ESP32?
C'est justement le problème du L298 et du L6203. Ce problème a été résolu pour un UNO avec son shield moteur (à L298) puisque c'est la Base Station DCC++ d'origine. Je n'en ai pas vu la transposition sur Nano ou Mini, ce qui me fait supposer que ce n'est pas immédiat pour une autre plateforme. Les timings du DCC sont à respecter. Et donc l'avantage du LMD18200 qui ne nécessite pas deux signaux en opposition de phase.
Le schéma d'un module DCC à L6203 est joint. Il peut remplacer un module à base de LMD18200. Dominique va le valider.

J'ai lu que Fusion360 intégrait maintenant Eagle (qui est par ailleurs gratuit en version éducation, limité à 80x100mm, limitation apparemment contournable)
Titre: Re : Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 07, 2020, 10:08:02 pm
Je n'en ai pas vu la transposition sur Nano ou Mini...

Justement voici les 2 schémas que j'ai trouvé chez Gravitec et DeekRobot qui utilisent soit des inverseurs trigger de schmidt, soit des portes Nand. Le schéma de Gravitec montre aussi comment est faite la mesure de courant, ce qu'on peut reproduire sur le L6203
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=2813;image)

Malheureusement, comme je l'ai dit plus haut, ce shield est impropre à l'utilisation de DCC++.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 08, 2020, 10:39:53 am
Bonjour,

En fait j'ai relu vos messages mais je ne comprends le problème.
Citer
C'est justement le problème du L298 et du L6203. Ce problème a été résolu pour un UNO avec son shield moteur (à L298) puisque c'est la Base Station DCC++ d'origine. Je n'en ai pas vu la transposition sur Nano ou Mini, ce qui me fait supposer que ce n'est pas immédiat pour une autre plateforme. Les timings du DCC sont à respecter. Et donc l'avantage du LMD18200 qui ne nécessite pas deux signaux en opposition de phase.

L'ESP32 n'arrive pas dans le même cycle à piloter les 2 IN ce qui imposerait de piloter une seule IN et de faire son complément via un transistor ?
C'est ce qu'il faut comprendre ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 08, 2020, 11:38:23 am
Bonjour,
je n'ai pas les compétences pour savoir où se trouve le problème mais le résultat est que je n'ai pas vu de code capable de générer les deux IN en dehors de celui de Gregg Bormann et de ses disciples pour DCCpp_Uno. (pour UNO et MEGA).
Je suis donc prêt à admirer son adaptation pour ESP32 mais est-ce utile de dépenser son énergie (et de précieux octets/cycles) pour remplacer un transistor à 0,01 € et deux résistances dans le cas du L6203 et L298 ?
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 08, 2020, 03:11:47 pm
mais est-ce utile de dépenser son énergie (et de précieux octets/cycles) pour remplacer un transistor à 0,01 € et deux résistances dans le cas du L6203 et L298 ?

Nous répondrons que non !
Maintenant que Thierry a porté DCC++ sur ESP32, est-ce que change quelque chose de ce coté ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 09, 2020, 06:05:14 pm
Bonjour à tous,

Projet effectivement très intéressant et, cerise sur le gâteau, nous faisons la connaissance de Cédric. Bravo !
Vous cherchez donc à faire une centrale très bon marché et tout le monde va forcément être d'accord.
Comme on disait dans mon ancien boulot, faire du "mieux disant" et pas du "moins disant". Le but n'est pas, à tout prix  :D de baisser les coûts.
Des fois, pour quelques euros de plus, on peut avoir des fonctions supplémentaires très utiles, voire indispensables pour certains.

Pour moi, les points que je retiens de vos échanges sont les suivants :
1°) DCC++ via DCCpp de Thierry
2°) Possibilité de commander via un WIFI "propriétaire", j'entends par là indépendant des box internet qu'on a à la maison.
3°) Pour moi, c'est évident que ça doit être compatible CAN
4°) Commandable par un mobile : oui, mais pas seulement. C'est justement l'intérêt du CAN.
Donc, la centrale DCC doit pouvoir recevoir des ordres d'un mobile, mais aussi d'un bus CAN bidirectionnel relié à un gestionnaire.
5°) On ne doit pas avoir de limite au nombre de trains et, en tous cas pas 2 !
Évidemment, ça augmente le nombre d'ampères, mais Christophe en a bien fait une qui sort 10 A...
L'autre façon de voir les choses :
La centrale gère plusieurs trains, c'est une chose, mais les ampères, c'est le booster qui s'en charge. Il faut dissocier les deux problèmes.

J'ajouterai que ce n'est plus possible à notre époque de se satisfaire d'un écran 2 x 20 caractères avec des petits points. Ras le bol de la Multimaus !

Denis
Bientôt 64 ans ("When I'm sixty four"), Montpellier
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 09, 2020, 06:42:08 pm
Bonjour Denis,

C'est bien de donner ton avis sur les caractéristiques que tu souhaiterais, merci  :D et j'invite tous ceux qui sont intéressés à en faire autant.

Par contre ce sera tout sauf une usine à gaz !
On travaille un peu de notre coté pour le moment pour définir un cahier des charges avec les fonctions de base d'une V1 et les extensions possibles des V2, 3, ..x qui nous sembleraient possibles (mais à démontrer) en combinaison avec d'autres éléments ou pas.

Dans les choses interessantes que tu suggères, j'aime bien :
- mettre un connecteur d'extension pour utiliser un booster externe (10A par exemple) en n'équipant pas le booster interne (L6203)
- commander plus de 2 trains mais pas forcément par des smartphones (il existe des manettes inventives chez nos Locoduinistes) sachant qu'il y a du série/usb, du wifi, du Bluetooth, du can (n'en jetez plus !!). Il n'y aura pas tout au début !
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 09, 2020, 07:27:37 pm
- mettre un connecteur d'extension pour utiliser un booster externe (10A par exemple) en n'équipant pas le booster interne (L6203)
A partir du moment où on a mis un inverseur pour le L6203, il peut servir pour un module à BTS7960B vendu pour 43A (Antoine connait).
Il faut alors un connecteur HE10 à 8 broches et une nappe.
Mais si on ne trouve pas la place sur le pcb de 100x100 mm pour un connecteur HE10 à 8 broches, on a parlé dans ces colonnes du booster de Dave Bodnar (à BTS7960B ) qui reprend tout simplement le signal DCC de n'importe quelle centrale.
Et on a déjà évoqué la question de savoir si avec une centrale costaude on ne doit pas protéger chaque canton à 3A.

Pour l'écran 2x20, je suggère de s'en passer tant qu'on a pas défini ce qu'on veut en faire. Définissons les besoins avant les solutions.
En particulier, vise-t-on une centrale ou une console ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 09, 2020, 08:32:56 pm
La vraie raison pour laquelle j'ai fait ce post, c'est que je ne veux pas d'une mini-centrale.
Si ça ne tient pas sur un 10x10, on en met 2 !  8)

Par exemple : il y a un booster pour qu'il n'y en ait pas dans la centrale. Pas de booster interne.
Quitte à faire un booster avec seulement un L298, un L6203, un LMD18200, ...
Suivant ses besoins, on choisit son booster.

Je pense qu'il faudrait faire un schéma de ce qu'on veut sous forme de pavés de fonctions.
En particulier, bien définir les interfaces et connecteurs (c'est cher, un connecteur et ça prend de la place)
On verra après quel composant on utilise pour remplir la/les fonction.s.
Aller du général au particulier.

Je suis d'accord avec Dominique : ne pas faire une usine à gaz. On ne fera pas tout, tout de suite.
Mais il ne faut pas faire une mini-centrale inextensible. Il y en a déjà plein le web.

Donc, au départ, raisonner en modules de fonctions, bien définies, avec toute la souplesse possible.
Si plusieurs fonctions sont liées, on les met sur un seul 10x10 et on gagne des connecteurs et de la place.
Tout le monde n'aura pas besoin de tout.

J'ajoute autre chose : on ne cherche pas de compatibilité avec aucun bus DCC.

Allez, je risque un "gros mot" : faire un cahier des charges  :o :o

Denis


Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 09, 2020, 09:34:20 pm
Bonjour,

Citer
Projet effectivement très intéressant et, cerise sur le gâteau, nous faisons la connaissance de Cédric. Bravo !
Je te remercie pour ce message sympathique Denis, je suis très honoré de pouvoir travailler avec votre équipe que je suis depuis longtemps.

Citer
J'ajouterai que ce n'est plus possible à notre époque de se satisfaire d'un écran 2 x 20 caractères avec des petits points. Ras le bol de la Multimaus !
La question qui se pose est à quoi doit servir l'écran ? Cette console serait piloté essentiellement par un smartphone, une tablette ou un PC. Leurs écrans remplacent avantageusement la multimauss. L'écran que Dominique a retenu (genre 4x20, https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcQFXeI82cxspLbzkulmZarLNwKCnhaBx1pCjp89EzFd8g8VEYUjoxHZwtpNMPwJTqpE1s6VrMir&usqp=CAc) sur la console serait minimaliste et tu trouveras dans les captures d'écran (draft) ci-joint des cas d'usage que j'imagine.
La petite capture correspond à une vue après le démarrage et la grande image correspond à la vue après la première mise en ligne. On verrait le courant débité, les 3 dernières commandes reçus et un indicateur 3en ligne" ou "Stop". La description est sommaire, en mode caractère, mais avec les Oled il y aurait possibilité de faire des truc un peu plus jolie en mode graphique. A voir quand il n'y aura plus que ça à faire.
Tout ceci fait partie d'un draft du cahier des charges donc tout est open ! On peut partir sur un écran comme ça https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcRYucseFoL_KGNwuRd4_GayPrYy7bQ0dnzOmOVsoAZxSDVbFlj3cV-4JCyKIHkuKvyMyUyGsryq&usqp=CAc ou encore https://ouilogique.com/files/2015-08-14-2-4-in_TFT_Touch_screen/2-4-in_TFT_Touch_screen_front.jpg mais il faudra travailler les use cases car là je ne vois pas.

Msport écrit :
Citer
Il faut alors un connecteur HE10 à 8 broches et une nappe.

Pas évident ce genre de connecteur. J'imagine que cette console pourrait ressembler à une box tv (voir photo) et je n'imagine pas un connecteur HE10 avec sa nappe. Je pense que notre centrale doit avoir de l'ambition, avoir de la gueule, même devenir un produit fini distribuable et pas seulement un truc que l'on vissera sur une planche en bois avec des fils qui sortent de partout. Je serai plutôt partant sur un Subd-9 pour faire sortir le GND/IN/Enable et tant qu'on y ait, le bus I2C et l'interface SPI (SDA/SCL/MISO/SCK/CS, MOSI) pour une extension très large. A voir si le 5V est nécessaire mais pas convaincu à ce stade.
Avec le sud-9, on peut faire un câble propre vers une box booster.

Citer
Allez, je risque un "gros mot" : faire un cahier des charges  :o :o
On est sur le coup, avec Dominique nous avons attaqué un document avec déjà 9 pages au compteur et il est loin d'être terminé.
Si vous souhaitez lire/compléter/critiquer, donnez moi votre adresse gmail en mp afin que je vous partage le document (google document).

Citer
Donc, au départ, raisonner en modules de fonctions, bien définies, avec toute la souplesse possible.
Si plusieurs fonctions sont liées, on les met sur un seul 10x10 et on gagne des connecteurs et de la place.
Tout le monde n'aura pas besoin de tout.
Très bonne remarque. Je pense que si on se donne la possibilité de sortir un bus I2C et une interface SPI, on sera les rois du pétrole en matière d'extension (à nos risques et périls aussi) !


Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 09, 2020, 11:21:36 pm
Citer
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 !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 09, 2020, 11:49:46 pm
Citer
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 ;D

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.

Citer
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 ?

Citer
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 :

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. :D
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 10, 2020, 08:18:47 am
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)  :D ;D
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  8).




Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 10, 2020, 09:34:18 am
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.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 10, 2020, 09:46:30 am
Bonjour Thierry,

Citer
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 :
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 ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 10, 2020, 10:03:39 am
Parfait. Penser à juste pouvoir régler la fréquence du PWM pour s'adapter à divers types de moteur.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 10, 2020, 10:22:05 am
Et bien on s'entent bien ce qui est le principal ;D

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).
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 10, 2020, 10:28:38 am
Citer
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)
Titre: Re : Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 10, 2020, 11:03:01 am
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 !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 10, 2020, 01:51:49 pm
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 ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 10, 2020, 03:16:58 pm
Et puis cette centrale s'adresse à toutes les échelles, et dans les grandes échelles la tension peut monter à 20v...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 11, 2020, 06:14:53 pm
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
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 11, 2020, 09:14:06 pm

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.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 11, 2020, 09:32:11 pm
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  ;D

Citer
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).

Citer
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é.

Citer
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  ;)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 11, 2020, 10:27:25 pm
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  ;D) 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 :
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 :

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()  8) 8) -> https://www.youtube.com/watch?v=i8ffEbyU-7w


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.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 11, 2020, 10:57:38 pm
Bonsoir Dominique,

Je reste un fervent défenseur du CAN. Je ne vais pas me renier (et j'ai même fait un article dessus et j'en reste très fier)
Mais entre le gestionnaire et le réseau.

On peut le garder pour la centrale DCC. Pourquoi pas ?
Je dis simplement que c'est luxueux ... à cet endroit. Et INDISPENSABLE ailleurs, entre les modules V1/V2 et le gestionnaire.

Ce que j'ai abandonné, c'est vrai, c'est de caser un gestionnaire COMPLET dans un processeur.
A part des cas très particuliers, qui fonctionnent parfaitement, et tes réalisations en sont la preuve, je suis persuadé qu'il n'y a pas la place.

Les logiciels classiques (Trains Controller, JMRI, ...) gèrent le réseau sur un ordi et utilisent la centrale effectivement quasiment comme un booster, comme l'a dit msport.
A une nuance près, importante :
La gestion qui doit être dans la centrale DCC, c'est la gestion du ralenti, de l'accélération, de l'inertie, des fonctions. Et là, on n'est plus dans le booster.

Question : il y a un bus CAN dans la centrale parce qu'on envisage de commander les aiguilles, de créer des itinéraires, d'afficher les occupations de zone ?
Alors là, oui, il faut un CAN. Et un écran plus grand ou une interface vers un TCO physique.
Mais ce n'est pas ce que j'avais compris au départ.

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 12, 2020, 11:12:25 am
Analysons le positionnement des différentes fonctions et des infos échangées :

Depuis un mobile, en Wifi, et avec l'appli JMRI qui va bien (suivant IOS/Android), on commande non seulement les trains, mais aussi les aiguilles.
Donc, il existe un "traducteur CAN" d'une action sur un bouton virtuel sur le mobile vers une commande CAN adressée au module V1/V2 destinataire.
Ce traducteur est forcément dans la centrale.

De même, il existe un "traducteur DCC" d'une action d'un potar virtuel sur le mobile vers une commande DCC vers les rails pour commander les locos.
Ce traducteur est forcément dans la centrale.

Dans l'autre sens, le réseau envoie via le CAN des infos d'occupation (entre autres) qui, à priori, ne vont pas à la centrale SAUF si celle-ci gère un TCO sur écran ou physique.
Sinon, ces infos vont directement au gestionnaire externe sur ordi.

Quant aux infos type lecture de CV, elles sont acheminées via les rails vers la centrale. Et ne concernent pas le gestionnaire externe, à priori.

Si on a un gestionnaire externe, soit il est relié directement par USB ordi <-> centrale et on utilise les traducteurs précédents en envoyant dans l'USB les ordres qui vont bien et qui simulent les actions sur les mobiles.

1°) Bouger un potar sur l'écran de l'ordi ou bouger un potar virtuel sur un mobile aboutissent au même traducteur DCC et donc ont le même effet.

2°) Commander un itinéraire de, mettons, 3 aiguilles sur le gestionnaire PC aboutiront à l'envoi de 3 ordres sur l'USB, équivalents à 3 appuis sur les boutons virtuels sur un mobile et via le traducteur CAN de la centrale vers les aiguilles choisies.

Autre solution : on n'a pas de connecteur USB dans la centrale.

On fait une interface USB <-> CAN avec un traducteur CAN direct (la commande du gestionnaire n'emprunte pas le traducteur CAN de la centrale)
Ce traducteur CAN gérera aussi les actions sur la vitesse (les 5 messages du précédent post) et les 29 fonctions vers le traducteur DCC de la centrale.
Et, dans l'autre sens, l'interface récupère toutes les infos en provenance du réseau via le CAN.

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 12, 2020, 11:54:39 am
On peut représenter le projet sur la figure ci-dessous qui tient dans un ESP32 :
- une centrale DCCpp
- une interface wifi pour 2 types de clients (pas forcément en même temps :
    - un gestionnaire type JMRI (avec ses manettes)
    - des manettes smartphone en direct (avec traducteur Withrottle <-> commandes DCC++)
- une interface Can pour communiquer avec les satellites
- un mini-gestionnaire de circulation (à inventer avec interface de programmation : le concours est ouvert !!!)

reste à savoir si c'st faisable !
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 12, 2020, 11:15:20 pm
Les logiciels classiques (Trains Controller, JMRI, ...) gèrent le réseau sur un ordi et utilisent la centrale effectivement quasiment comme un booster, comme l'a dit msport.
A une nuance près, importante :
La gestion qui doit être dans la centrale DCC, c'est la gestion du ralenti, de l'accélération, de l'inertie, des fonctions. Et là, on n'est plus dans le booster.
Tu as raison pour les réseaux assez grands comme ceux que tu traites dans ton logiciel : la modélisation (définition) du réseau (cantons, aiguilles, signaux, itinéraires, beaucoup de trains) avec une IHM de configuration demandent un PC a part entière, pour adresser tous les cas possibles.
La centrale fabrique surtout les trames de bits 0 et 1 des commandes DCC avec des timings rigoureux que le booster traduit en tension et courant.

Mais on oublie plein de cas :
Je vois bien sur le site nombre de modélistes qui démarrent avec des réseaux simples et qui n’ont pas besoin d’un RRTC ou un JMRI pour faire quelques manœuvres même sophistiqués. On devrait pouvoir intégrer dans cette centrale, outre les accélérations et ralentissements, quelques scenarii de manœuvres sympa, sous forme de lignes de commandes.
Des trains automatiques aussi sont possibles tant qu’il ne doivent pas traverser le grill de la gare saint lazare !
A partir d’une certaine taille de réseau (comme le mien) j’admet qu’il faut un gestionnaire externe, ce que je fais, sur le Can évidemment, mais sans PC . Chacun reste libre !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 13, 2020, 09:32:48 am
Citer
Des trains automatiques aussi sont possibles tant qu’il ne doivent pas traverser le grill de la gare saint lazare !

Ah ? Toi aussi, la reproduction en HO à Railexpo du grill de la gare St Lazare (Tranchée des Batignolles), ça t'a marqué ?
C'est vrai que Jean-Paul Guimbert (Régions & Compagnies) a fait très fort !
Je ne le connais malheureusement qu'au travers des photos de Loco Revue Janvier 2020, mais c'est impressionnant.
Ceux qui l'ont vu et qui me connaissent ont dû se dire : c'est un réseau pour Denis !  ;D

Pour les petits réseaux, bien sûr, pas d'ordi. Et tu as raison : ce sont les plus nombreux.
Je propose de faire une interface CAN pour TCO physique (boutons et LED).

Un traducteur direct bouton poussoir -> CAN  vers les satellites pour les aiguilles
On peut bien sûr pré-programmer un bouton qui fait un itinéraire : il enverra autant d'impulsions que nécessaire pour que les aiguilles soient toutes orientées dans le bon sens. Un séquenceur.

Un traducteur direct bouton poussoir -> CAN vers la centrale pour les 5 ordres de vitesse (maxi) pour ceux qui ne veulent pas commander avec un mobile (et il y en a)
En général, seul l'ordre d'arrêt est utilisé.

Exemple de configuration :
Je gère manuellement 2 trains en DCC.
En bas du TCO, 2 boutons poussoir (un par train)
Sur chaque voies de gare : un bouton poussoir.
Je veux arrêter le train 2 voie 1.
J'appuie simultanément sur le bouton du train 2 et de la voie1. L'ordre est mémorisé.
Quand on a l'occupation de la voie 1, on envoie l'ordre dans le bus CAN -> centrale DCC.
Nota : on récupère le fait que c'est bien la centrale qui gère les ralentissements, ce qui fait que le train s'arrête doucement.
On peut même sécuriser avec un ILS au pied du signal qui donne l'arrêt complet du train (on est alors contents d'avoir mémorisé le numéro du train  ;))

Et un dernier traducteur CAN -> LED qui récupère le message d'occupation envoyé par le satellite et allume la LED.

En général, il n'y a pas de signalisation sur les petits réseaux. C'est là que commencent les ennuis ... ???

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 13, 2020, 10:39:51 am
C'est là que commencent les ennuis ...
... Et les choses intéressantes !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 13, 2020, 10:47:19 am
Et oui, avec des satellites on gère les signaux comme les aiguilles et les détecteurs !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 13, 2020, 11:16:33 am
Citer
Et oui, avec des satellites on gère les signaux comme les aiguilles et les détecteurs !

Oui, ... mais non.
La couleur du signal à afficher est complexe à calculer.
Quand je dis que c'est complexe, je sais de quoi je parle.

Ce n'est pas envoyer l'ordre "allume le Carré" qui est dur, c'est de déterminer qu'il faut allumer le carré.
Sur des réseaux de pleine voie, c'est facile. Dans le gares.... ???
Les R, RR, Cv sont de vraies chausse-trappes. Et le Carré qui peut être manuel...
Mais sur de petits réseaux, dont on parle ici, c'est facile à déterminer.

Pour votre info, je suis actuellement sur le rouge clignotant pour entrer à 15 km/h dans une zone occupée (UM, wagons à raccrocher, ...).

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 15, 2020, 01:11:36 pm
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).

Cédric,

C'est à mon sens une très bonne suggestion pour une utilisation puissante et optimale. Et très simple à mettre en œuvre

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.

FreeRTOS dispose d'une API de "Queue" pour la communication entre tâches très simple à utiliser également et aussi très riche en fonctionnalités. Voir ici à partir de la page 109 : https://www.freertos.org/Documentation/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide.pdf (https://www.freertos.org/Documentation/161204_Mastering_the_FreeRTOS_Real_Time_Kernel-A_Hands-On_Tutorial_Guide.pdf)


Bien amicalement.

Christophe

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 15, 2020, 06:55:21 pm
Bonjour Christophe,

La doc de FreeRTOS est vraiment bien faite, merci pour le lien.
Le mécanisme de Queue est bien décrit ; il faudra maintenant, selon nos choix d'implémentation, identifier les données à échanger par ce mécanisme pour un fonctionnement safe.

A+

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 15, 2020, 07:38:41 pm
Très interessant, mais est-ce accessible à l'Arduino IDE ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 15, 2020, 08:27:24 pm
Citer
Très interessant, mais est-ce accessible à l'Arduino IDE ?

Je pense que oui car le fonction pour affecter une tâche à un coeur vient de là donc toute l'API doit être utilisable.

Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 15, 2020, 08:37:01 pm
Dans les deux derniers Elektor (j'ai eu le dernier hier soir avant la fermeture), une série d'articles :
"Le multitâche en pratique avec l'ESP 32"
Je n'ai pas tout lu, sauf qu'il y a maintenant 25 (!!) niveaux de priorité, de 0 à 24.
Cela ne va pas être triste à gérer...

Moi, à mon humble niveau, je vais plutôt me concentrer sur les messages à échanger, de façon aussi détaillée que possible, en particulier pour des échanges de haut niveau avec un gestionnaire complet. Après, je laisserai les spécialistes mettre ça en musique dans l'ESP32.
Par exemple, l'occupation des zones doit avoir la priorité la plus élevée dans le CAN.

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pierre59 le mars 16, 2020, 08:53:04 am
Bonjour

Je ne pense pas que pour le moment cela soit bien utile de faire une liste complète des messages.

L'expérience de la mise au point du Locoduinodrome pour Orléans m'a montré que si avais pu modifier ou ajouter des messages j'aurais pu corriger quelques anomalie beaucoup plus facilement.

Je pense qu'il faut définir un format de messages suffisamment souple et ouvert, la liste des messages viendra petit à petit.

Ces messages doivent êtres de haut niveau et il ne faut pas se préoccuper à ce niveau du support physique qui sera utilisé, mais on peut prévoir des messages plus urgents.

J'ai du il y a quelques temps, pour des essais, remplacer la communication USB/Série entre le Mac et l'Arduino pour une liaison réseau (wifi en l'occurence), j'ai juste du changer quelques lignes dans les deux programmes et en 5 min cela marchait.

Cordialement

Pierre
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 16, 2020, 05:34:26 pm
En lisant l'article de Denis, j'ai vu que les différentes tâches pouvant être programmées sur un ESP32 et exécutées sur le core0 et le core1 partageaient le même espace mémoire.

Concrètement, cela veut dire qu’une variable globale peut être vue et manipulée par les différentes tâches. Voir l’exemple simple ci-dessous.

Ce n’est bien sûr pas le plus recommandable mais après tout, tant qu’il n’y a pas de corruption des données ou de fuites de mémoire…

En fait, je travaillais sur le passage de valeurs entre les tâches par l’intermédiaire de files, ça m’a fait une petite distraction.



TaskHandle_t Task0;
TaskHandle_t Task1;

int intVar = 0;

void setup() {
  Serial.begin(115200);
  delay(2000);
  Serial.printf("\n");

  //create a task that will be executed in the Task0code() function, with priority 1 and executed on core 0
  xTaskCreatePinnedToCore(
    Task0code,   /* Task function. */
    "Task0",     /* name of task. */
    10000,       /* Stack size of task */
    NULL,        /* parameter of the task */
    1,           /* priority of the task */
    &Task0,      /* Task handle to keep track of created task */
    0);          /* pin task to core 0 */
  delay(500);

  //create a task that will be executed in the Task1code() function, with priority 1 and executed on core 1
  xTaskCreatePinnedToCore(
    Task1code,   /* Task function. */
    "Task1",     /* name of task. */
    10000,       /* Stack size of task */
    NULL,        /* parameter of the task */
    1,           /* priority of the task */
    &Task1,      /* Task handle to keep track of created task */
    1);          /* pin task to core 1 */
  delay(500);
}

//Task0code
void Task0code( void * pvParameters ) {
  Serial.printf("Task0 running on core : %d\n", xPortGetCoreID());

  for (;;) {
    intVar++;
    delay(1000);
  }
}

//Task1code
void Task1code( void * pvParameters ) {
  Serial.printf("Task1 running on core : %d\n", xPortGetCoreID());

  for (;;) {
    Serial.printf ("intVar = %d\n", intVar);
    delay(1000);
  }
}

void loop() {}
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 16, 2020, 07:28:36 pm
Bonjour Christophe,

Je pense que sur une donnée partagée de type int, ton code ne risque rien. Par contre, si on s'amuse à modifier un objet sur un coeur et de manipuler l'objet par l'autre coeur, je crois qua ça se passera mal tôt ou tard.
A+
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 16, 2020, 09:44:31 pm
Bonjour Christophe,

Je pense que sur une donnée partagée de type int, ton code ne risque rien. Par contre, si on s'amuse à modifier un objet sur un coeur et de manipuler l'objet par l'autre coeur, je crois qua ça se passera mal tôt ou tard.
A+

Je suis bien conscient des limites et je l'ai bien précisé. Cependant, en y regardant de plus près, il me semble que ce petit exemple est réaliste dans un système de messagerie par exemple. Il n’y a en effet de modification de données que dans une seule deux tâches.

C’est je crois le cas que tu évoquais précédemment avec le traitement web dans une tâche et le reste dans une autre tâche.

Mais comme il n’y a pas de gestion de file, la valeur de la variable peut avoir été modifié dans la tâche 1 avant même que la tâche 2 n’ai pu la traiter. C'est une autre limite.

Ce petit exemple voulait également répondre à quelqu’un qui disait que ça semblait compliqué. En fait pas du tout et il y a dans ce que je montre tout pour faire fonctionner une tâche sur le core 0 et un autre sur le core 1  permettant ainsi d’accroitre les performances.

Le seul vrai problème se pose comme tu le précises bien lorsque les deux tâches travaillent sur les mêmes objets en modification.

Je trouve en tous cas ceci amusant !


Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pierre59 le mars 17, 2020, 08:30:21 am
Bonjour

Ce n'est pas évident que cela fonctionne bien. Cela dépend comment est réalisée l'instruction  intVar++; si elle n'est pas faite avec une SEULE instruction du langage machine, du genre charger dans un registre, incrémenter le registre, remettre en mémoire, cela foirera inexorablement, un changement de tache pouvant se faire entre les instructions.

J'ai beaucoup pratiqué le multitâche jadis et ai travaillé dans des équipes de recherche sur le parallélisme, il faut gérer des sections critiques.

J'ai des doutes aussi avec les Serial.print.

Cordialement

Pierre

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 17, 2020, 08:54:00 am
L'exemple est sympa et parlant. La difficulté de la gestion multi-tâche réside essentiellement par les synchronisations qu'il faut généralement mettre en place pour éviter les conflits d’accès et/ou d'écriture sur les mêmes données. Les langages C et C++ prévoient des mécanismes type mutex, sémaphore ou lock pour justement contourner ces problèmes. Je ne sais pas ce qui est vraiment disponible pour l'ESP32, et en particulier si c'est utilisable avec un Arduino IDE...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pierre59 le mars 17, 2020, 09:53:42 am

Autre problème pouvant arriver, le compilateur C/C++ fait des optimisations assez poussées à la compilation, par exemple il pourrait garder la variable intVar dans un registre (s'il y en a assez sur le processeur) et ne pas la ranger en mémoire partagée, on peut palier ce problème en la rendant "volatile" (volatile int intVar).
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Jean-Luc le mars 17, 2020, 10:02:56 am
Bonjour

Pierre et Thierry ont 100% raison.

J'ai un TP là dessus en OS temps-réel. C'est amusant de voir la variable partagée prendre des valeurs arbitraires.

Le plus pénible avec la concurrence d'accès à des données partagée est que, à moins de faire un programme taillé exprès pour la mettre en évidence rapidement, le bug ne se produit que rarement. Donc quasi impossible à trouver par des tests.

FreeRTOS possède des sémaphores pour mettre en œuvre des sections critiques : https://www.freertos.org/a00113.html

Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 17, 2020, 10:10:35 am
L'exemple est sympa et parlant. La difficulté de la gestion multi-tâche réside essentiellement par les synchronisations qu'il faut généralement mettre en place pour éviter les conflits d’accès et/ou d'écriture sur les mêmes données. Les langages C et C++ prévoient des mécanismes type mutex, sémaphore ou lock pour justement contourner ces problèmes. Je ne sais pas ce qui est vraiment disponible pour l'ESP32, et en particulier si c'est utilisable avec un Arduino IDE...

L’API de FreeRTOS est vraiment très complète pour gérer en particulier les queues, les semaphores et les mutexes.

Je pense que l’on doit pouvoir arriver à des choses fiables sur un ESP32 en multi-tâches. Pour l’instant, je m’intéresse au passage de données d’une tâche à une autre (qui était l’exemple pris par Cédric) dans le cas d’une messagerie avec gestion de la communication web sur une tâche et traitement des données sur une autre par exemple.

Les différents paramètres du message seraient stockés dans une structure (date, ID, contenu, …) qui elle-même serait passée en paramètre entre les tâches.

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

Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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  :D
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pierre59 le mars 17, 2020, 04:45:24 pm

j'ai fait tourner le programme de Christophe sur un Esp32 bicore. Quand les délais dans la boucle de chaque taches sont identiques cela se passe bien, touts les entiers successifs sont affichés.

Mais évidemment si les délais ne sont pas identique cela ne marche pas on rate des valeurs ou certaines sont multipliées.

En suivant le lien fourni par Jean-Luc j'ai monté un sémaphore d'exclusion mutuelle et changé un peu le programme.

Il y a un compteur pour chaque tache, grâce au sémaphore ces compteurs sont incrémentés de façon synchrone (toujours égaux à 1 près) et ceci quelque soient les délais de chaque tache. Les deux entier qui s'affichent sont toujours égaux et il n'en manque pas, il n'y a pas de duplication non plus.

Cela ressemble un peu à un envoi de message d'une tache à l'autre avec accusé de réception.

Le programme :

TaskHandle_t Task0;
TaskHandle_t Task1;

SemaphoreHandle_t xSemaphore = NULL; // semaphore d'exclusion mutuelle

int intVar0 = 0;
int intVar1 = 0;

void setup() {
  Serial.begin(115200);
  delay(2000);
  Serial.printf("\n");

  xSemaphore = xSemaphoreCreateMutex(); // creation du semaphore

  //create a task that will be executed in the Task0code() function, with priority 1 and executed on core 0
  xTaskCreatePinnedToCore(
    Task0code,   /* Task function. */
    "Task0",     /* name of task. */
    10000,       /* Stack size of task */
    NULL,        /* parameter of the task */
    1,           /* priority of the task */
    &Task0,      /* Task handle to keep track of created task */
    0);          /* pin task to core 0 */
  delay(500);

  //create a task that will be executed in the Task1code() function, with priority 1 and executed on core 1
  xTaskCreatePinnedToCore(
    Task1code,   /* Task function. */
    "Task1",     /* name of task. */
    10000,       /* Stack size of task */
    NULL,        /* parameter of the task */
    1,           /* priority of the task */
    &Task1,      /* Task handle to keep track of created task */
    1);          /* pin task to core 1 */
  delay(500);
}

//Task0code
void Task0code( void * pvParameters ) {
  Serial.printf("Task0 running on core : %d\n", xPortGetCoreID());

  for (;;) {
   if( xSemaphore != NULL )
    {
        if( xSemaphoreTake( xSemaphore, ( TickType_t ) 10 ) == pdTRUE ) // essai d'obtention du semaphore
        {
            if (intVar0==intVar1) intVar0++;
           
            xSemaphoreGive( xSemaphore ); // liberation du semaphore
        }
        else
        {
            Serial.printf("Task0 on core : %d pas obtenu semaphore\n", xPortGetCoreID());
        }
    }   
    delay(10); // delay(1000); // plus vite ou moins vite
  }
}

//Task1code
void Task1code( void * pvParameters ) {
  Serial.printf("Task1 running on core : %d\n", xPortGetCoreID());

  for (;;) {
   if( xSemaphore != NULL )
    {
        if( xSemaphoreTake( xSemaphore, ( TickType_t ) 10 ) == pdTRUE ) // essai d'obtention du semaphore
        {
            if (intVar0==intVar1+1) { intVar1++; Serial.printf (" %d %d\n", intVar0,intVar1); }
           
            xSemaphoreGive( xSemaphore );  // liberation du semaphore
        }
        else
        {
            Serial.printf("Task1 on core : %d pas obtenu semaphore\n", xPortGetCoreID());
         }
    }   
    delay(500);
  }
}

void loop() {}
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 17, 2020, 05:04:21 pm
J'ai complété le programme pour avoir une vraie file d'attente pour faire une messagerie qui échangerait les données d'une tâche à l'autre. Bien sûr, une tâche tourne sur le cœur 0 et l'autre sur le cœur 1 sinon ça n'a pas d'intérêt.

Ca m'intéresse d'avoir vos retours.

PS : Pierre, je viens juste de voir ta réponse et je ne l'ai pas analysée. Cependant, le ne suis pas certain qu'il y ait besoin de sémaphore dans ce cas car il n'y a pas de modifications de données entre les tâches, non ?

TaskHandle_t vSenderTask;
TaskHandle_t vReceiverTask;

/* Declaration d'une variable xQueue de type QueueHandle_t qui servira a stocker la file. */
QueueHandle_t xQueue;
/* Taille de la file*/
int queueSize = 1000;
/* Taille maxi de la chaine de caractere */
#define maxCaractInQueue 25


void setup() {
  Serial.begin(115200);
  delay(2000);
  Serial.printf("\n");

  xQueue = xQueueCreate( queueSize, maxCaractInQueue );
  if ( xQueue != NULL ) {

    xTaskCreatePinnedToCore(
      vSenderTaskCode,            /* Task function. */
      "vSenderTask",              /* name of task. */
      10000,                      /* Stack size of task */
      NULL,
      1,                          /* priority of the task */
      &vSenderTask,               /* Task handle to keep track of created task */
      0);                         /* pin task to core 0 */
    delay(500);

    xTaskCreatePinnedToCore(
      vReceiverTaskCode,          /* Task function. */
      "vReceiverTask",            /* name of task. */
      10000,                      /* Stack size of task */
      NULL,                       /* parameter of the task */
      2,                          /* priority of the task */
      &vReceiverTask,             /* Task handle to keep track of created task */
      1);                         /* pin task to core 1 */
    delay(500);
  }
  else
    /* The queue could not be created. */
    Serial.printf("The queue could not be created.");
}



void vSenderTaskCode( void *parameter ) {
  BaseType_t xStatus;
  /* Variable qui va contenir la valeur a envoyer*/
  char strTx[maxCaractInQueue];
  Serial.print("vSenderTask\n");
  for (int i = 0; i < queueSize; i++) {
    sprintf(strTx, "Ligne %d", i);
    xStatus = xQueueSendToBack( xQueue, (char*) strTx, 0 );
    if ( xStatus != pdPASS )
      Serial.printf( "Could not send to the queue.\r\n" );
    else
      Serial.printf("Send : %s\n", strTx);
  }
  vTaskDelete( NULL );
}

void vReceiverTaskCode( void *parameter ) {
  BaseType_t xStatus;
  /* Variable qui va contenir la valeur recue*/
  char strRx[maxCaractInQueue];
  const TickType_t xTicksToWait = pdMS_TO_TICKS( 100 );
  Serial.print("vReceiverTask\n");
  for ( ;; ) {
    if ( uxQueueMessagesWaiting( xQueue ) != 0 )
      Serial.printf( "Queue should have been empty!\n" );

    xStatus = xQueueReceive( xQueue, &strRx, xTicksToWait );
    if ( xStatus == pdPASS )
      /* Data was successfully received from the queue, print out the received
        value. */
      Serial.printf( "Received : %s\n", &strRx );
    else
      Serial.printf( "Could not receive from the queue.\r\n" );
  }
}

void loop() {}
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pierre59 le mars 17, 2020, 05:12:21 pm

Oui il n'y a pas de modifications entre les taches, cela marche aussi sans sémaphore, désole.

Je cherche un exemple plus convaincant.

Pierre
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pierre59 le mars 17, 2020, 06:04:55 pm
Je pense avoir un exemple plus convaincant du fonctionnement des sémaphores.

J'ai une chaine de caractères partagée. Je la fabrique lentement après l'avoir effacée dans un tache et je l'affiche lentement dans l'autre tache.

J'ai du mettre en commentaires les affichages de non obtention de sémaphore car il polluent l'affichage.
Cela veut aussi dire que les taches n'obtiennent pas toujours le sémaphore.
Voila ce que cela donne :

Task0 running on core : 0
Task1 running on core : 1
0123456789
0123456789
0123456789
0123456789
0123456789
0123456789

Voila ce que cela donne sans sémaphore :

Task0 running on core : 0
Task1 running on core : 1
0123456789
----------
0123456789
01--------
--23456789
0123------
----456789
012345----
------6789
01234567--
--------89
0123456789
----------
0123456789
01--------
--23456789
0123------
----456789


TaskHandle_t Task0;
TaskHandle_t Task1;

SemaphoreHandle_t xSemaphore = NULL; // semaphore d'exclusion mutuelle

char chaine[11]; // chaine de 10 caracteres

void setup() {
  Serial.begin(115200);
  delay(2000);
  Serial.printf("\n");

  chaine[10]=0;
 
  xSemaphore = xSemaphoreCreateMutex(); // creation du semaphore

  //create a task that will be executed in the Task0code() function, with priority 1 and executed on core 0
  xTaskCreatePinnedToCore(
    Task0code,   /* Task function. */
    "Task0",     /* name of task. */
    10000,       /* Stack size of task */
    NULL,        /* parameter of the task */
    1,           /* priority of the task */
    &Task0,      /* Task handle to keep track of created task */
    0);          /* pin task to core 0 */
  delay(500);

  //create a task that will be executed in the Task1code() function, with priority 1 and executed on core 1
  xTaskCreatePinnedToCore(
    Task1code,   /* Task function. */
    "Task1",     /* name of task. */
    10000,       /* Stack size of task */
    NULL,        /* parameter of the task */
    1,           /* priority of the task */
    &Task1,      /* Task handle to keep track of created task */
    1);          /* pin task to core 1 */
  delay(500);
}

//Task0code
void Task0code( void * pvParameters ) {
  Serial.printf("Task0 running on core : %d\n", xPortGetCoreID());

  for (;;) {
   if( xSemaphore != NULL )
    {
        if( xSemaphoreTake( xSemaphore, ( TickType_t ) 10 ) == pdTRUE ) // essai d'obtention du semaphore
        {
            for (int i=0; i<10; i++) { chaine[i]='-'; delay(5); } // effacement de la chaine
            for (int i=0; i<10; i++) { chaine[i]='0'+i; delay(5); } // fabrication de la chaine
            xSemaphoreGive( xSemaphore ); // liberation du semaphore
        }
        else
        {
            //Serial.printf("Task0 on core : %d pas obtenu semaphore\n", xPortGetCoreID());
        } 
    }   
    delay(10); // delay(1000); // plus vite ou moins vite
  }
}

//Task1code
void Task1code( void * pvParameters ) {
  Serial.printf("Task1 running on core : %d\n", xPortGetCoreID());

  for (;;) { //int intVar;
   if( xSemaphore != NULL )
    {
        if( xSemaphoreTake( xSemaphore, ( TickType_t ) 10 ) == pdTRUE ) // essai d'obtention du semaphore
        {           
            for (int i=0; i<10; i++) { Serial.printf ("%c",chaine[i]); delay(10); }
            Serial.printf ("\n"); // affichage de la chaine
           
            xSemaphoreGive( xSemaphore );  // liberation du semaphore
        }
        else
        {
            //Serial.printf("Task1 on core : %d pas obtenu semaphore\n", xPortGetCoreID());
         }
    }   
    delay(500);
  }
}

void loop() {}
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 17, 2020, 07:01:11 pm
Merci Pierre, l'exemple est en effet simple et parlant.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 18, 2020, 12:14:47 am
La même chose que ce que j'ai posté précédemment mais avec des structures pour manipuler des variables complexes.

/*
   Documentation @ http://web.ist.utl.pt/~ist11993/FRTOS-API/group___queue_management.html#xQueueReceive
*/

TaskHandle_t vSenderTask;
TaskHandle_t vReceiverTask;

/* Declaration d'une variable xQueue de type QueueHandle_t qui servira a stocker la file. */
QueueHandle_t xQueue;
/* Taille de la file*/
const uint32_t queueSize = 1000; // Prevoir une taille suffisante pour ne pas perdre de messages
/* Taille maxi de la chaine de caractere */
#define maxCaractInQueue 25

struct Msg {
  uint32_t id;
  char str[maxCaractInQueue];
} msg;


void setup() {
  Serial.begin(115200);
  delay(2000);
  Serial.printf("\n");

  xQueue = xQueueCreate( queueSize, sizeof( struct Msg * ));
  if ( xQueue != NULL ) {

    xTaskCreatePinnedToCore(
      vSenderTaskCode,            /* Task function. */
      "vSenderTask",              /* name of task. */
      10000,                      /* Stack size of task */
      NULL,
      1,                          /* priority of the task */
      &vSenderTask,               /* Task handle to keep track of created task */
      0);                         /* pin task to core 0 */
    delay(500);

    xTaskCreatePinnedToCore(
      vReceiverTaskCode,          /* Task function. */
      "vReceiverTask",            /* name of task. */
      10000,                      /* Stack size of task */
      NULL,                       /* parameter of the task */
      2,                          /* priority of the task */
      &vReceiverTask,             /* Task handle to keep track of created task */
      1);                         /* pin task to core 1 */
    delay(500);
  }
  else
    Serial.printf("The queue could not be created.");
}


void vSenderTaskCode( void *parameter ) {
  struct Msg *ptTxMsg;
  BaseType_t xStatus;
  ptTxMsg = &msg;
  Serial.print("vSenderTask\n");
  for (int i = 0; i < 10000; i++) {
    ptTxMsg->id = i;
    sprintf(ptTxMsg->str, "Ligne %d", i);
    xStatus = xQueueSendToBack( xQueue, (void*) &ptTxMsg, 0 );
    if ( xStatus == pdPASS )
      Serial.printf("Send : %d\n", ptTxMsg->id);
    else
      Serial.printf( "Could not send to the queue.\n" );
  }
  vTaskDelete( NULL );
}

void vReceiverTaskCode( void *parameter ) {
  struct Msg *ptRxMsg;
  BaseType_t xStatus;
  const TickType_t xTicksToWait = pdMS_TO_TICKS( 100 );
  Serial.print("vReceiverTask\n");
  for ( ;; ) {
    if ( uxQueueMessagesWaiting( xQueue ) != 0 )
      Serial.printf( "Queue should have been empty!\n" );
    xStatus = xQueueReceive( xQueue, &(ptRxMsg), xTicksToWait );
    if ( xStatus == pdPASS )
      Serial.printf( "Received n° %d - value : %s\n", ptRxMsg->id, ptRxMsg->str );
    else
      Serial.printf( "Could not receive from the queue.\n" );
  }
}

void loop() {}
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pierre59 le mars 18, 2020, 07:53:42 am
Bonjour

Tu est sur que les xQueue incluent un mécanisme de protection contre les accès simultanés issus de plusieurs taches ?

Pierre
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 18, 2020, 09:51:04 am
Tu est sur que les xQueue incluent un mécanisme de protection contre les accès simultanés issus de plusieurs taches ?

Bonjour Pierre,

Une fois encore ce n'est pas l'accès simultanés issus de plusieurs taches qui peut poser problème mais que plus d'une tâche puisse modifier les données ou l'ordre des données. Or ici, il s'agit de la base d'un principe de messagerie avec une tâche qui copie les messages reçus les uns derrière les autres dans la file et une autre tâche qui les lit et libère l'espace mémoire une fois fait.

Il s'agit donc avant tout d'un banal sujet de gestion de file et j'espère en effet que les concepteurs ont bien fait le travail dans la classe.

Le code est très proche de l'exemple donné dans la documentation (url au début du programme).

Par ailleurs, les passages des données se fait par référence, ce qui veut dire que les différentes tâches qui peuvent manipuler les données le font toujours sur le même espace mémoire. C'est donc un sécurité pour l'intégrité de la donné. Par contre, ce serait certainement différent si une tâche modifiait l'ordre des données dans la liste et là effectivement il faudrait un mécanisme de sémaphore.

Enfin, il est facile de créer un mécanisme de vérification. Le process 0 envoyant des données incrémentées, il est facile de vérifier dans le process 2 si l'incrémentation est respectée.

Bien amicalement

Christophe
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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).


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  ;D

Bon confinement à tous!
Dominique


Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pierre59 le mars 18, 2020, 03:30:15 pm
Bonjour

Pour clore la polémique, j'ai regardé les sources C++ de FreeRTOS, ils utilisent bien des sémaphores pour gérer les "queues". Je pensais bien que c'était indispensable.

Pierre
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 18, 2020, 05:14:10 pm
... 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).
Bonsoir,
en ce qui me concerne, j'ai investi sur le bus DCC jusqu'ici (et renoncé à l'I2C), avec donc DCC++ coté manettes et TCO.
Pour me permettre une évolution en douceur vers les satellites en CAN, au moins l'entrée de commandes en serial sur RX/TX me serait nécessaire.

J'ai complété le schéma de Dominique dans ce sens (si je l'ai compris) ...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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)..
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 18, 2020, 06:38:44 pm
Pour l'USB, je verrais simplement une découpe dans le boitier pour accéder au port USB de l'ESP32. Ce que je fais dans mes Base Stations (mais est-ce bien la question ?)
Pour l'I2C on peut prévoir un level shifter comme :
https://www.ebay.fr/itm/New-IIC-I2C-Logic-Level-Converter-Bi-Directional-Module-5V-to-3-3V-For-Arduin-SN/153844938771
comme il y a 4 ports, 2 peuvent servir au RX/TX, mais dans mon cas le module radio HC12 fonctionne en 3,3V, quid de l'I2C pour Cédric (le module peut être coté "esclave", donc externe)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 19, 2020, 06:01:11 am
Pour bien comprendre, sur le schéma, ce qui est encadré par un rectangle et qui inclus Centrale DCC++, connecteur passerelle, traducteur, système de gestion de circulation et SAM ..., vous voyez tout cela sur un seul ESP32 ou cela désigne pour vous un ensemble qui lui même peut contenir plusieurs cartes : un ESP32, un Arduino Nano... ???

Pour me permettre une évolution en douceur vers les satellites en CAN, au moins l'entrée de commandes en serial sur RX/TX me serait nécessaire.

C'est aussi la raison pour laquelle je posais la première question.

La passerelle que j'ai développée sur la base d'un ESP32 inclus également le port série. Il n'y aurait donc pas de problème pour satisfaire cette demande.

Mais si tout ce qui est décrit ci-dessus devait tourner sur un seul ESP32, je crains fort que la pauvre bête ne crève à la tâche.

Pour ma part, je pense qu'il faut concevoir un système modulaire : Centrale DCC++ et passerelle d'une part, système de gestion de circulation, SAM et satellites d'autre part. Tout ceci pouvant faire l'objet d'un seul PCB ou pas.

Il y a une solution simple à réaliser, je veux dire par là qui réutilise des éléments déjà existants :

- Mettre DCC++ sur un Arduino Nano (en attendant DCCpp sur ESP32)
- La passerelle sur un ESP32 (déjà existant), reste à développer le traducteur, long à faire mais pas si complexe
- Système de gestion de circulation et SAM sur une autre carte (ESP32, Mega, Uno, Nano ???)

Merci pour les précisions apportées.

Christophe.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 19, 2020, 09:06:59 am
A mon avis, le gestionnaire, même mini, doit être à l'extérieur de la Box.

Dans un monde uniquement DCC, on peut changer la position d'une aiguille en envoyant un ordre DCC (par exemple depuis la Multimaus).
Vu de l'utilisateur, il y a une seule interface (un seul clavier, un seul "écran" d'affichage, un seul bus)
Ici, il n'est pas prévu d'envoyer cet ordre vers le DCC, mais vers le CAN. On est tous d'accords là dessus.

C'est donc plus conséquent : il faut que le clavier et l'écran puissent s'adresser à deux bus, deux bus qu'il faut gérer.
Je ne dis pas que ce soit la partie la plus complexe (loin de là...), mais ça fait des choses en plus à faire.

Et, pour moi, gestionnaire = TCO. Même un TCO basique (3 boutons et 4 LED). A fortiori si le gestionnaire est sur un ordi.
Je ne considère pas que la possibilité de modifier la position d'une aiguille soit de la gestion.

Ce n'est que mon avis.

Je pense qu'il faut raisonner en modulaire et éclater le schéma. Proposition :
1°) On dessine un module par fonction. Au départ, une fonction = un processeur.
2°) On adducte le module au bon bus (DCC ou CAN) et on termine sur un ESP32 (le seul qui soit commun aux deux bus)
3°) S'il reste de la place sur l'ESP, on intègre la fonction directement dans l'ESP. Et on gagne des processeurs, des connecteurs et des CI.

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pierre59 le mars 19, 2020, 09:51:41 am

Bonjour

Je pense comme Christophe et Denis que l'aspect modulaire est essentiel, ne fabriquons pas une usine à gaz.

Je pense aussi que les communications entre modules doivent êtres aussi "modulaires". Il serait extremement souple de pouvoir utiliser le maximum d'outils de communications entre les modules.

Pas mal de modules auront en pratique à disposition plusieurs moyens de communications dans une vaste palette :  CAN, WIFI, DCC, Bluetooth, USB, série, I2C, …

Pour pouvoir utiliser indifféremment un moyen ou un autre , il faut avoir un protocole de communication de haut niveau pouvant être implémenté sur tous les outils de communications.

Cela nécessite un format de messages bien précis, simple mais souple. Ce n'est pas le moment de faire des listes de messages, mais plutôt chercher un  format adapté.

Cordialement

Pierre
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 19, 2020, 11:34:34 am
Pour ce qui est de la performance, deux threads, c'est à dire deux coeurs qui marchent simultanément, c'est équivalent à deux Nano (à la vitesse d'un coeur ESP...) complètement séparés. La seule contrainte serait le partage de données qui obligerait un thread à attendre l'autre. Mais si on répartit les choses logiquement, c'est à dire un thread pour DCCpp avec ses propres données, et un autre pour la communication vers l'extérieur, ou même un gestionnaire, ça peut tout à fait fonctionner. A moins qu'il n'y ait quelque chose que je ne vois pas.

A noter que ces jours ci je travaille, mais je vais très probablement me remettre à l'ESP ce week end...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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  :-\

(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=2834;image)

Je démultiplie et je donne des exemples :


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
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 19, 2020, 12:39:08 pm
A mon avis, le gestionnaire, même mini, doit être à l'extérieur de la Box.

Dans un monde uniquement DCC, on peut changer la position d'une aiguille en envoyant un ordre DCC (par exemple depuis la Multimaus).
Vu de l'utilisateur, il y a une seule interface (un seul clavier, un seul "écran" d'affichage, un seul bus)
Ici, il n'est pas prévu d'envoyer cet ordre vers le DCC, mais vers le CAN. On est tous d'accords là dessus.

...


Denis,

de mon coté, je vois ce projet comme une centrale et non comme une console.
j'ai déjà réalisé nombre de manettes et mini TCO permettant de commander respectivement locos, aiguilles et accessoires avec DCC++
Dans mon optique si il y a plusieurs locos sur le circuit, il y a autant de manettes. Plus celle(s) pour les aiguilles, la plaque tournante, les PN, les rails décrocheurs.
j'aimerai bénéficier du CAN pour fiabiliser les échanges entre le réseau et la centrale via les satellites et la signalisation. Surtout pour la rétrosignalisation.
j'aimerai utiliser JMRI (ou CDMrail) pour automatiser mes circuits, donc avec DCC++.
de là, l'IHM (OLED, boutons, ...) sur cette centrale doit juste permettre de la configurer (et de tester à minima sa fonctionnalité, cf Dominique)


Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 19, 2020, 01:34:30 pm
Pour les démos, je propose trois modules :

1°) un module CAN avec un servo, une LED et un détecteur de consommation (on n'a pas besoin d'autre chose)
2°) un autre module CAN avec trois BP et une LED (c'est un TCO, si, si !) Je mets 3 BP : 2 pour commander le servo et un pour arrêter le train.
3°) une interface DCC

On branche "tout ça" à un ESP32 et on voit comment gérer.

Puis on augmente progressivement : plusieurs modules pour voir si on on gère bien les adresses.

Et après, le wifi, les bus I2C, USB ....

Denis
Pour Michel :
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.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 19, 2020, 02:58:38 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)
C'est justement le schéma de la moitié de ce module à 0,92€ ...

Et pour RX/TX je tombe sur :
 * U0UXD is used to communicate with the ESP32 for programming and during reset/boot.
 * U1UXD is unused and can be used for your projects. Some boards use this port for SPI Flash access though
 * U2UXD is unused and can be used for your projects.

UART      RX IO       TX IO         CTS          RTS
UART0    GPIO3      GPIO1        N/A         N/A
UART1    GPIO9      GPIO10      GPIO6     GPIO11
UART2    GPIO16    GPIO17      GPIO8     GPIO7

https://circuits4you.com/2018/12/31/esp32-hardware-serial2-example/
et
https://quadmeup.com/arduino-esp32-and-3-hardware-serial-ports/
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 19, 2020, 04:16:12 pm
Pour ceux que ça intéresse, voici le moyen d’utiliser JMRI en Wifi. C’est la première brique que je propose pour cette centrale. (et dans l’attente de DCCpp sur ESP32)

Le procédé est très simple, JMRI communique en TCP (Ethernet) avec l’ESP32, les deux étant reliés à votre box.

Les commandes reçues de JMRI par l’ESP32 sont « routées » par le port « Serial2 » de l’ESP32 au port série (Pins TX et RX) de l’Arduino UNO (ou autre) qui supporte DCC++.

De la même manière, les informations envoyées par DCC++ sont « routées » en TCP à JMRI.

N’oubliez pas que le TX de l’un va dans le RX de l’autre et vice-versa.

Attention, le courant sur les pins de l’Arduino est en 5V et sur celles de de l’ESP en 3,3V. Vous devrez ajouter un convertisseur de tension comme sur la photo.

Chez moi, le serveur DHCP a donné l’IP 192.168.1.126 à l’ESP. Il vous faut entrer dans JMRI l’adresse IP attribuée à l’ESP32 dans votre propre configuration.

N’oubliez pas de mettre vos propres identifiants internet dans le fichier config.h

#define WIFI_SSID           "votre_ssid"
#define WIFI_PSWD           "votre_password"

A votre disposition si ces informations ne sont pas suffisantes pour l’installation.

Prochaine étape, je vais essayer de piloter à partir de WiThrottle avec les informations fournies par Dominique.

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 19, 2020, 06:21:54 pm
Bravo  :) ;) :D ;D
Titre: Re : projet centrale wifi DCC++ Can
Posté par: CATPLUS le mars 19, 2020, 08:34:21 pm
Bonsoir à tous

Aie  :(, j'ai du mal à suivre (je ne dois pas être le seul, enfin j'espère) mais je m’accroche.

Juste une réflexion, si j'ai bien tout compris !!!! vous voulez que du WIFI et aucune possibilité d'une sortie sur RJ45, ma requête et demande si coupure du signal plus aucun moyen de commander, d'arrêter le système. Sous JMRI, même perte du signal on peut continuer manuellement.

Cordialement
Marcel

Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 19, 2020, 08:46:16 pm
Marcel, qu'est-ce que tu appelles "continuer manuellement" ?

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 19, 2020, 10:47:18 pm
Bonjour Marcel,

On ne parle de connexion à Internet mais de Wifi supporté par la centrale DCC.
Le Wifi est dans la box, indépendamment de votre internet Orange, Bouygues ou autre. Si le wifi de la centrale DCC ne fonctionne plus, c’est que la centrale est en panne.

Espérant avoir été clair.

Cédric
Titre: Re : projet centrale wifi DCC++ Can
Posté par: CATPLUS le mars 20, 2020, 07:52:48 am
Bonjour,

Ok c'est clair , j'ai du loupé un épisode (à relire)

Donc, je reprends mon exemple  je suis équipé d'une centrale ZIMO première génération MX31ZL (voir en page 3 et 23 du pdf)

http://www.zimo.at/web2010/documents/MX31E.pdf

je la jette et la remplacerai par votre projet !!!! :-[

Quoi qu'il en soit si vous regardez les sorties sur le boitier ZIMO, on branche sur le CAN un adaptateur pour l'antenne (se que j'ai fait)
Si panne de batterie dans la manette de commande, je peux brancher  un câble sur la seconde sortie RJ45 (d'ou ma remarque)

@ Christophe
Marcel, qu'est-ce que tu appelles "continuer manuellement" ?

Dans tous les Systems qui doivent être utilisés "communication" (portable, tablette, souris, etc) il faut une énergie. A un moment "X" il y a aura coupure de l'alimentation (déchargement de la batterie)
Reprendre la main sur le System en branchant un câble RJ45

Il y a quelques années (en 2014) j'ai essayé le wifi avec JMRI, ce fût une mauvaise expérience (depuis les bugs de JMRI et Engine Drivers sont & seront corrigés)
https://teamtrack.soforums.com/t1242-JMRI-1.htm

J'utilise le SPROG & JMRI pour la programmation de me locos, pas de WIFI & des centrales DCC++ pour des petits montages (nettoyage de mes locomotives, va et vient, etc...)

Votre  projet est ambitieux et promet beaucoup, à suivre.

Cordialement
Marcel


Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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 ...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 22, 2020, 12:11:20 am
Bonjour à tous,

Dans le prolongement de la première centrale réalisée avec JMRI, j’ai développé une passerelle pour WiThrottle sur un ESP32 pour pouvoir, comme pour JMRI, commander par WiFi un Arduino (Uno, Nano ou Mega) avec DCC++.

Le montage est bien connu, ici un Mega avec DCC++ et un LMD18200.

La centrale est en principe capable d’être pilotée par 2 ou 3 périphériques  WiThrottle

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).

En attendant, voici une petite vidéo : https://www.youtube.com/watch?v=YgPwCOJ9aEg&feature=youtu.be
 (https://www.youtube.com/watch?v=YgPwCOJ9aEg&feature=youtu.be)

 (https://youtu.be/YgPwCOJ9aEg)


Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 22, 2020, 12:24:21 am
Bravo Christophe!
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 22, 2020, 09:14:21 am
Citer
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
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 22, 2020, 09:21:23 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

Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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

Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 22, 2020, 10:52:10 am
Bonjour,
je pense que nous avons tous dans nos tiroirs les reliques de nos projets trop ambitieux qui n'ont pas abouti. Tirons en la leçon.
La philosophie de Dominique me parait donner une base à une intégration du CAN qui pourra servir de base à des projets plus complets grâce aux briques logicielles qui ne manqueront pas de voir le jour.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 22, 2020, 11:19:21 am
Je suis d'accord avec Michel. Il ne faut pas un projet trop ambitieux qu'on ne finira jamais.

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, ...

Pour le wifi, qui, pour l'instant, nécessite un JMRI en plus fermé, on verra plus tard.

Je tiens absolument à ce que ça marche avec de vrais boutons pour une autre raison : c'est didactique !

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 le 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
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 22, 2020, 11:37:25 am
Ton point de vue me semble un peu négatif mais la discussion est ouverte !

Non je ne crois pas que dire ce que je dis est négatif. Tu le dis toi même, il faut définir le périmètre de ce projet et en disant ce que je dis, je pose bien des limites.

On voit bien que le recours à Withrottle « bride » le projet à l’état de manette plus que de centrale, mais ce n’est pas une critique.

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.

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


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.

Dans l’impatience d’avoir vos propositions et réactions par rapport à ce que je propose.

Bien amicalement

PS : Pendant que je rédigeais, sont tombés les posts de Michel et Denis qui me semblent rejoindre ma proposition.

Christophe
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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 :
(http://www.locoduino.org/IMG/jpg/ac5da181-b91b-47fe-81c5-dd73a5207ed0.jpg) et les aiguilles avec des inverseurs :
(http://www.locoduino.org/IMG/png/montcoendur.png)
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.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique 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 :

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  8)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 22, 2020, 02:36:29 pm
Le Nano pour DCCpp : on attend de savoir si DCC++ est dispo sur ESP32 : on n'est pas à un mois près

Il en dit quoi le principal intéressé ???
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 22, 2020, 02:53:53 pm
Bonjour à tous.

Je vous informe que la brique essentielle que vous attendiez tous est enfin disponible ! J'ai poussé la version 1.4.0 de DCCpp qui intégre l'ESP32, mais aussi d'autres nouveautés comme le pilotage à une seule interruption en AVR, la possibilité de fixer par code le seuil de reconnaissance de lecture de CV, etc...
Je n'ai pas testé toutes les parties annexes : turnout, sensor, outputs... Par contre le pilotage par liaison série fonctionne bien.
La preuve en image, que ça marche sur mon banc de test + locodrome, le tout validé par Monia, toujours très intéressée par ce qui bouge tout seul :

https://www.youtube.com/watch?v=QN1Beb4KR7o (https://www.youtube.com/watch?v=QN1Beb4KR7o)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 22, 2020, 03:00:50 pm
Chapeau l'artiste  ;D :D ;) :)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 22, 2020, 03:06:25 pm
Bravo Thierry !

Mais mets quand même l'image  ;D

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 22, 2020, 05:11:11 pm
De mon coté de viens de valider le pont en H L6203 (la partie puissance du DCC).

Sur la photo on voit le CI à gauche avec un ESP8266 contenant le serveur wifi et le traducteur Withrottle -> DCC++ et un Nano suportant DCC++. Tout cela devrait être remplacé par l'ESP32 !
Et à droite la carte L6203 faite par Michel, compatible avec une carte LMD18200 mais pouvant fournir 4A.

A l'oscillo le signal est propre.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 22, 2020, 05:27:20 pm
J'ai poussé la version 1.4.0 de DCCpp qui intégre l'ESP32

Merci Thierry. Je suis en train de faire l'installation.

Peux tu me donner le mapping correspondant à un ESP32 et un LMD18200

DCCpp::beginMain(UNDEFINED_PIN, DCC_SIGNAL_PIN_MAIN, 11, A0);

Un grand merci.

Christophe
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 22, 2020, 05:43:43 pm
Et à droite la carte L6203 faite par Michel, ... pouvant fournir 4A.

Vous avez prévu de le refroidir ou pas plus que ça ?

Pour l'approvisionnement, en L6203, avez-vous prévu quelque chose de particulier ? Tout le monde à pu se rendre compte qu'avec la Chine, c'était de plus en plus long.

Pour ma part, ayant un compte chez RS, je peux les toucher à 6,47 l'unité ou à 5,58 par 25. Franco de port, livré le lendemain même en ce moment. Est-ce que ça vous parait intéressant ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 22, 2020, 05:58:28 pm
C'est comme tu veux Christophe, vu que l'ESP32 peut faire fonctionner quasiment toutes ses broches sous interruption. Pour mes tests j'ai utilisé

DCCpp::beginMain(UNDEFINED_PIN, 22, UNDEFINED_PIN, A0);

Mais comme le dis Dominique, les broches 22 et 23 sont aussi utilisées pour la communication I2C... Donc une autre peut faire l'affaire. Le troisième argument, je le laisse indéfini dans mon cas, je n'ai pas de bouton pour désactiver physiquement le DCC, mais s'il devait y en avoir un, ce serait avec cette broche.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 22, 2020, 06:02:18 pm
Merci Thierry,

Ok toute broches sous interruption donc.

Je vais tester cela tout de suite et je fais un retour.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 22, 2020, 06:43:15 pm

Vous avez prévu de le refroidir ou pas plus que ça ?

Pour l'approvisionnement, en L6203, avez-vous prévu quelque chose de particulier ? Tout le monde à pu se rendre compte qu'avec la Chine, c'était de plus en plus long.

Pour ma part, ayant un compte chez RS, je peux les toucher à 6,47 l'unité ou à 5,58 par 25. Franco de port, livré le lendemain même en ce moment. Est-ce que ça vous parait intéressant ?

A mon avis, il doit être monté vertical avec un radiateur (calculs thermiques à faire).

Les principales usines de fabrication de ST sont situées à Agrate Brianza et Catane (Italie), Crolles, Rousset et Tours (France), ainsi qu'à Singapour. S'y ajoutent les sites d'assemblage et de test implantés en Chine, en Malaisie, à Malte, au Maroc, aux Philippines et à Singapour.

Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 22, 2020, 06:49:36 pm
Les principales usines de fabrication de ST sont situées à Agrate Brianza et Catane (Italie), Crolles, Rousset et Tours (France), ainsi qu'à Singapour. S'y ajoutent les sites d'assemblage et de test implantés en Chine, en Malaisie, à Malte, au Maroc, aux Philippines et à Singapour.

Ok mais ça répond pas à ma question.

Je demandais simplement si : à 6,47 l'unité ou à 5,58 par 25. Franco de port, livré le lendemain même en ce moment. Est-ce que ça vous parait intéressant ?

Il y en a 75 en stock livrables mardi si commande lundi avant 19 H.

En d'autres termes, seriez vous intéressés que je passe commande à ce prix et que je dispatch (pas trop tout de même pour ne pas ajouter trop de port) ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 22, 2020, 06:50:47 pm
Félicitations au chat et à son maitre !

ci-dessous les gerber du pcb pour en faire 45 (9x5) prédécoupés chez jlcpcb.com pour 6,57€

Radiateur ? : Pas testé à 4 A, je note que le shield moteur Arduino à L298 avec ce boitier n'a pas de radiateur, donc à vérifier.
Prix optimum 0,88€ pièce par 5 (eBay, aliexpress)

Pour la Chine, ça a l'air de redémarrer. Coté transport, un envoi économique du 2 mars serait arrivé en France.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 22, 2020, 06:58:47 pm
Bizarre : j'ai bien l'image de la vidéo de Thierry et, dès que je lance, ça plante.
La photo de couverture montre un matériel de pro !

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 22, 2020, 07:12:17 pm
Les principales usines de fabrication de ST sont situées à Agrate Brianza et Catane (Italie), Crolles, Rousset et Tours (France), ainsi qu'à Singapour. S'y ajoutent les sites d'assemblage et de test implantés en Chine, en Malaisie, à Malte, au Maroc, aux Philippines et à Singapour.

Ok mais ça répond pas à ma question.

Je demandais simplement si : à 6,47 l'unité ou à 5,58 par 25. Franco de port, livré le lendemain même en ce moment. Est-ce que ça vous parait intéressant ?

Il y en a 75 en stock livrables mardi si commande lundi avant 19 H.

En d'autres termes, seriez vous intéressés que je passe commande à ce prix et que je dispatch (pas trop tout de même pour ne pas ajouter trop de port) ?

Désolé pour la réponse : pour le L6203 particulièrement je ne sais pas.
J'en 2 en stock commandés sur eBay, un vendeur français à 6,80€ (reçu en 3 jours). Il y a au moins 50 vendeurs !
6,72€ et 389 en stock chez TME.
Je pense qu'on n'est pas prêts à en commander 25 sauf si nous recevons des intentions d'achat rapidement (moi : 2), et si on peut concevoir le pcb donc après s'être mis d'accord sur ce qu'il contiendra (faire la BOM prend du temps).
En plus les ESP32 Devkit C qui sont les plus populaires doivent venir de chine !

Michel a dessiné un 1er PCB, s'il peut nous le montrer pour se fixer les idées.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 22, 2020, 08:05:50 pm
C'est comme tu veux Christophe, vu que l'ESP32 peut faire fonctionner quasiment toutes ses broches sous interruption. Pour mes tests j'ai utilisé

DCCpp::beginMain(UNDEFINED_PIN, 22, UNDEFINED_PIN, A0);


Thierry, excuse moi de revenir à la charge mais je n'obtiens pas le résultat escompté.

Sur ma carte ESP32 (courte) je n'ai pas d'entré A0 mais la broche 34 qui peut aussi être utilisées comme entrée analogique avec l'identifiant A6.

Quand je lance la commande <1>, j'ai une très furtive alimentation des rails et puis plus rien. Est-ce un problème de mesure de courant ? Moi qui n'ai pas câblé comme il conviendrait ?

Petite question au hasard, as tu fait le nécessaire pour le calcul de consommation de courant fournis sous 5V par le MAX471 et échantillonné en 3,3 sur l'ESP.

Peux tu me dire dans ton cas sur quelles broches de ton ESP tu as câblé le PWM du LMD18200 et le DIR, je vais faire exactement le même montage pour limiter les incertitudes.

J'ai essayé : DCCpp::beginMain(UNDEFINED_PIN, 32, UNDEFINED_PIN, A6); et DCCpp::beginMain(UNDEFINED_PIN, 32, UNDEFINED_PIN, 34);

Merci par avance.

Christophe
Titre: Re : Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 22, 2020, 09:38:47 pm
Michel a dessiné un 1er PCB, s'il peut nous le montrer pour se fixer les idées.
les gerbers sont plus haut.
Dans le bom, les 15nF peuvent être remplacés par des 100nF.
Les diodes sont normalement des diodes rapides RS1M ou FR107 ou des schottky, mais sur les shield moteur arduino, ce sont des 1N4007.

Dans l’ordre du schéma PDF
5 GND                                     noir
4 SENSE R si en C/C = GND, laisser en l‘air
3 DIR = IN1          D10 du V&V
2 PWM = ENABLE  D3 du V&V
1 ENABLE               "


Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 22, 2020, 11:07:21 pm

Vous avez prévu de le refroidir ou pas plus que ça ?


Quelques éléments pour votre prise de risque :

Le L6203 est doté d'un thermal shutdown à 150°

Son RDs on est de 0.3 ohm typ.
à 2.5 A cela fait 1,875W (je néglige les pertes de commutation vu la faible fréquence du DCC)

La résistance thermique boitier / ambiance est de 35° / W soit ici 65° d'élévation de température.

A vous de voir si cela justifie un bout d'aluminium ou un beau radiateur taillé pour le boitier Multiwatt11 (en fonction de l'aération du boitier et de l'échelle de votre réseau)

Corrigez moi si j'ai commis une erreur.



Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 23, 2020, 08:57:10 am
J'ai essayé : DCCpp::beginMain(UNDEFINED_PIN, 32, UNDEFINED_PIN, A6); et DCCpp::beginMain(UNDEFINED_PIN, 32, UNDEFINED_PIN, 34);

Désolé d'apprendre que ça ne marche pas tout de suite. Mais de mon côté je viens de faire l'essai sur un coin de table (je travaille en théorie...).
De l'un de mes cartons de déménagement (celui qui aurait dû avoir lieu samedi...), j'ai ressorti un ESP32 tout neuf, et j'ai pris mon exemple 'Autotest' avec ta config 32/34 et ça a marché du premier coup. Il faut juste renommer la variable 'time' en 'timeValue', parce que time est un mot réservé de l'ESP32... Et avec l'oscillo j'ai bien un signal DCC sur la broche 32.
Je n'ai pas changé les valeurs de reconnaissance de court circuit, je ne suis pas sûr de savoir faire ça, alors j'ai laissé dans l'état. Mais si quelqu'un me donne les valeurs, je les intègre dans une nouvelle version avec la correction de 'time' en plus.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 23, 2020, 09:07:02 am
Merci Thierry et je comprends que ce n'est pas les conditions idéales pour toi.

Relié à la broche 32 on est d'accord qu'il s'agit bien de l'entrée PWM du 18200. Est-ce que l'entrée DIR du 18200 est reliée quelque part ?

Sinon, je vais effectivement reprendre un ESP32 neuf mais je ne vois pas pourquoi.

Bien amicalement

Christophe

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 23, 2020, 09:25:27 am
Non, la broche 32, c'est le Dir. PWM est à relier à la broche du troisième argument, la EnablePin.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 23, 2020, 09:31:13 am
Ok ça fonctionne.

AT du MAX471 sur la broche 36 (VP ou A0) de l'ESP32
PWM du LMD18200 sur broche EN de l'ESP32
DIR du LMD18200 sur broche 32 de l'ESP32

Voici mon parametrage : DCCpp::beginMain(UNDEFINED_PIN, 32, UNDEFINED_PIN, 36);

Attention : En fait il faut bien mettre le DIR sur la broche 32. Je n'avais pas vu ça tout de suite mais les broches 34, 35, 36 et 39 de l'ESP32 sont INPUT ONLY

Merci Thierry.

Je vais maintenant développer le code pour passer les commandes à l'ESP en WiFi. Peut-être pas tout de suite WiThrottel qui nécessite un traducteur de commandes mais avec mon controller qui envoie ses commandes en textuel DCC++.

Ce sera la bonne occasion pour essayer la réception des commandes en WiFi sur l'un des cœur et passage des messages via une queue comme je l'ai montré dans les précédents posts.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 23, 2020, 09:51:05 am
Bonjour à tous,

Je vais faire un test aussi de mon côté en partant aussi sur les pins 30 et 32.

Pour la mesure de courant, sachant qu’on utilisera le L6203 avec un ampli du côté GND ( contrairement au Max471), on déterminera cette valeur par expérience.

Je reviens vers vous dans la matinée.

Dominique
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 23, 2020, 12:04:35 pm
A titre indicatif, j'ai conservé le MAX471 du montage à LMD1800 avec le L6203 ( R sense shuntée) sans souci.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 23, 2020, 12:18:13 pm
A titre indicatif, j'ai conservé le MAX471 du montage à LMD1800 avec le L6203 ( R sense shuntée) sans souci.

Mais il  est limité à 3A et, apparemment plus disponible chez Maxim, ni TME !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 23, 2020, 12:40:39 pm
Donc reste l'ACS712, malheureusement seulement en CMS.

L'ampli op n'est peut-être pas nécessaire, la résistance de 1 ohm donne suivant la loi, 1V / A comme le MAX471 avec sa R Sense de 2Kohm.
A tester en filtrant et protégeant l'entrée contre les surcharges.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 23, 2020, 02:07:52 pm
Bonjour,

Tant qu'on en est aux limiteurs de surintensités, il faudra se rappeler de ce qu'on dit quand on en sera aux boosters.
Ex : 4 limiteurs 2,5 A en sortie d'un booster 10 A en séparant les zones.
Comme ça, si on a un CC à un endroit, on ne plante pas tout le réseau, mais seulement une zone correspondant à son limiteur.

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 23, 2020, 02:39:39 pm
Bonjour à tous,

Je vais faire un test aussi de mon côté en partant aussi sur les pins 32 et 34.

Pour la mesure de courant, sachant qu’on utilisera le L6203 avec un ampli du côté GND ( contrairement au Max471), on déterminera cette valeur par expérience.

Je reviens vers vous dans la matinée.

Dominique

Test de DCCpp 1.4.0 concluant : Les signaux sont propres (durée des 1 et 0, 3,3V d'amplitude), ça devrait plaire au L6203 (test à venir).

Pour ce test j'ai choisi :
DCCpp::beginMain(UNDEFINED_PIN, 32, 34, UNDEFINED_PIN); // 32=DCC(Dir), 34=pwm/enable, 36=A0 current senseLe moniteur affiche le déroulement des commandes DCC++.

Le croquis utilise 241901 octets (18%) de l'espace de stockage de programmes. Le maximum est de 1310720 octets.
Les variables globales utilisent 15740 octets (4%) de mémoire dynamique, ce qui laisse 311940 octets pour les variables locales. Le maximum est de 327680 octets.

Bravo à Thierry, il reste plein de place pour les parties wifi (passerelle et traducteur), à priori.

A suivre ...

Dominique
 
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 23, 2020, 06:47:47 pm
J'ai recherché les chiffres de consommation des cartes ESP32 DEVKIT C pour définir les besoins en 5V, donc le dimensionnement du régulateur (à découpage, j'y reviendrai plus loin).

Sur le forum https://esp32.com/viewtopic.php?t=2662 (https://esp32.com/viewtopic.php?t=2662), je trouve pour une carte comprenant une CPU et son électronique autour :

SCENARIOCPU80MHzCPU160MHzCPU240MHz
CPU + électronique38mA51mA73mA
CPU + électronique + BT113mA123mA141mA
CPU (deep sleep) + électronique3.5mA3.5mA3.5mA

Par contre, en lançant la fonction WiFi.scanNetworks() au début le module consomme 500mA pendant 10 ms avec les pics d'approximativement 700mA.
Après le module consomme en moyenne 130 mA avec des pics de 600mA. Ces pics durent environ 0.5 ms toutes les 100 ms.

La datasheet semble indiquer que la consommation est de 0.3A max (50 mA pour la CPU et 240 mA max pour le WiFi).

Cela veut dire qu'il faut prévoir un régulateur 5V 1A supportant une tension d'entrée d'au moins 18V. Ce qu'un régulateur série ne peut pas faire  :o
Ce type me parait convenir à 6,15€ : https://fr.farnell.com/wurth-elektronik/173010578/fixed-step-down-regulator-5-0v/dp/2577479 (https://fr.farnell.com/wurth-elektronik/173010578/fixed-step-down-regulator-5-0v/dp/2577479)

Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 23, 2020, 07:39:57 pm
Bonjour,

Tant qu'on en est aux limiteurs de surintensités, il faudra se rappeler de ce qu'on dit quand on en sera aux boosters.
Ex : 4 limiteurs 2,5 A en sortie d'un booster 10 A en séparant les zones.
Comme ça, si on a un CC à un endroit, on ne plante pas tout le réseau, mais seulement une zone correspondant à son limiteur.

Denis

Je vais peut-être te décevoir, mais on va probablement se limiter à un seul booster 4A (le L6203) sur le pcb, pour cette première étape,  mais rien n'empêche de prévoir un connecteur d'extension sur le bord du pcb relié à certaines pins inutilisées de l'ESP32, pour permettre ce genre d'extension, moyennant une extension logicielle ad hoc (hic  :-\).
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 23, 2020, 09:42:12 pm
Le WURTH est une belle solution.
Mais avant de se poser la question du régulateur 5V, il faut se demander pourquoi cette tension est de 5V est choisie en Vin ?
apparemment on peut monter à 20V dernière limite, 12V serait possible. Des avis ?
Que prévoit-on d'alimenter à coté de l'ESP ? Une alimentation commune est-elle souhaitable ?

Si c'est bien 5V
1. un 7505T (1.5A, 35V) pourrait convenir en N avec un bloc en 12V (voire en 15V avec un radiateur ou +65° nu)
Rth = 50°C/W à l’ambiance soit pour 130mA et 7V de chute de tension  => +45° (ou +58° si le Vin est à 9V pour un bloc à 18v)

2. Dans la philosophie du chinois pas cher et pas trop mauvais (dixit un vendeur de la rue Montgallet qui a su conserver son humour) :
https://www.ebay.fr/itm/3A-Voltage-Regulator-Converter-Buck-Converter-Mini-Step-Down-LM2596-2596S-Module/263153078280
Les 3A sont certainement optimistes mais 130mA, voire 600mA devraient passer. (1.5A permanent)

De toute façon, on peut prévoir les trois implantations, celle du WURTH est identique à celle de 7805T (le hasard??) mais plus haut / à plat.
Le circuit à base de MP158 est plat et tient sous l'afficheur. (la référence au LM2596 est fausse)

Une réalisation à base d'ESP32 :
https://espacerm.com/webgen/controleur-multifonctionnel-elabore-autour-du-esp32-devkit-v1-doit/

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 23, 2020, 09:57:26 pm
Bonsoir,

Pour les 58° à évacuer, ça semble vraiment compliqué.

Citer
2. Dans la philosophie du chinois pas cher et pas trop mauvais (dixit un vendeur de la rue Montgallet qui a su conserver son humour) :
https://www.ebay.fr/itm/3A-Voltage-Regulator-Converter-Buck-Converter-Mini-Step-Down-LM2596-2596S-Module/263153078280
Les 3A sont certainement optimistes mais 130mA, voire 600mA devraient passer. (1.5A permanent)
Je connais et j’aime assez ce composant. Il a inconvénient même si c’est plutôt mineur, il faut régler la tension de sortir avec le potentiomètre. Cela ne me semble pas le plus simple par contre le rendement est tellement qu’il chauffe peu.
Autre avantage, il ne coute pas grand chose surtout par 5 ou 10.

Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 24, 2020, 08:52:19 am
Bonjour,

Pour mon alimentation analogique, je suis tombé sur un cours d'électronique concernant les buck converters.
En particulier, il comparer les différents modèles en fonction de la puissance demandée
Je trouve ça très instructif.

https://drive.google.com/file/d/1VeMU_egBPXgHgYRc_cscn_vdXFCZeKut/view?usp=sharing (https://drive.google.com/file/d/1VeMU_egBPXgHgYRc_cscn_vdXFCZeKut/view?usp=sharing)

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 24, 2020, 09:55:25 am
Je connais et j’aime assez ce composant. Il a inconvénient même si c’est plutôt mineur, il faut régler la tension de sortir avec le potentiomètre. Cela ne me semble pas le plus simple par contre le rendement est tellement qu’il chauffe peu.
Autre avantage, il ne coute pas grand chose surtout par 5 ou 10.

J'ai en stock ce modèle à base de MP2307 qui fonctionne très bien :
https://www.ebay.fr/itm/10PCS-Supper-mini-3A-DC-DC-Converter-Step-Down-buck-Power-3V-5V-16V-MP2307-Chip/201073184176?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 (https://www.ebay.fr/itm/10PCS-Supper-mini-3A-DC-DC-Converter-Step-Down-buck-Power-3V-5V-16V-MP2307-Chip/201073184176?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649)

Pour réduire au minimum l'inconvénient du potentiomètre, on pourrait appliquer la sortie, réglée sur 7,5V environ sur l'entrée Vin de l'ESP32 et récupérer le 5V et le 3,3V sur les pins dédiées de l'ESP32. Ainsi, le réglage de tension du MP2307 ne devient plus critique.

Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 24, 2020, 10:49:19 am
Le module a  MP158  (1er) semble plus performant que celui a MP2307 (2e), plus petit. Mais on peut prévoir les deux empreintes superposées ...

MP158 
Whole network smallest maximum 3A output.
Input voltage: 4.5-28V
Output Voltage: 0.8-20V (adjustable)
Output current: rated current 3A(MAX).
Switching Frequency: 1MHz
Output Ripple:less than 30mV
Efficiency:96%(max)
Operating temperature: Industrial grade (-40 C to +85 C)
Module Properties: Non-isolated step-down module (buck)
Size:22*17*4mm

MP2307
Module Properties: Non-isolated step-down module (BUCK)
Rectification: Synchronous rectification
Input voltage: DC 4.75V-23V
Output voltage: DC 1.0V-17V (Adjustable, Output < Input)
Output current: Rated current 1.8A (3A MAX, can not be prolonged)
Conversion efficiency:96%(highest)
Switching Frequency: 340KHz.
Output ripple:30mV(no-load)
Load regulation:±0.5%
Voltage regulation:±2.5%
Operating Temperature: Industrial (-40℃ ~ +85℃)
Short circuit protection: No(Please do not short-circuit)
Input Reverse protection: No(Can not be reversed)
Dimension: approx.17mm*11mm*3.8mm(L*W*H)/17*11*3.8 Supper mini board
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 25, 2020, 09:49:23 am
Bonjour à tous,

Avec l’aide de Thierry, j’ai fait l’implémentation du WiFi dans DCCpp. Concrètement, cela veut dire qu’un terminal peut envoyer par le WiFi des commandes au format de la messagerie DCC++ (en HTTP) mais surtout en TCP.

C’est le cas de JMRI auquel il suffit de dire que la centrale est de type DCC++ en lui donnant l’IP et le port.

C’est aussi, en théorie, le cas de Withrottle. Je dis bien en théorie car en l’état le traducteur entre la messagerie de Withrottle et celle de DCC++ que j’ai terminé il y a quelques jours n’est pas implémenté et, à mon avis, ne doit pas l’être en l’état. En effet, cela reviendrait à coder les messages Withrottle en messages DCC++ pour ensuite les décoder afin qu’ils soient exécutés par DCCpp qui lui fonctionne avec des méthodes natives. Donc une consommation inutile de ressources pouvant se traduire par une baisse des performances.

Dominique, je suis désolé, mais tout est donc à réécrire ! Je veux bien commencer à regarder et faire cela avec toi et avec tous ceux que ça intéresse.

Concernant la possibilité de communiquer via CAN avec cette centrale, l’une des premières préoccupations est d’adopter une messagerie performante. En existe t’il déjà ? Qui n’aurait pas forcément besoin d’être au format DCC++. Seule la structure en message CAN de chaque commande nous intéresse : Avant, arrière, vitesse, eStop, fonctions etc… Faut-il en créer une ? Oui s’il n’y en a pas. Par contre, pour la programmation et la lecture des CV's ça va être une autre paire de manche.

A+ pour de nouvelles aventures.

Christophe

PS : Pour disposer de DCCpp en Wifi, il faut attendre les instructions de Thierry pour savoir comment il souhaite mettre à dispo ces modifications pour contrôler les versions en circulation.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 25, 2020, 10:56:49 am
Dominique, je suis désolé, mais tout est donc à réécrire ! Je veux bien commencer à regarder et faire cela avec toi et avec tous ceux que ça intéresse.

Concernant la possibilité de communiquer via CAN avec cette centrale, l’une des premières préoccupations est d’adopter une messagerie performante. En existe t’il déjà ? Qui n’aurait pas forcément besoin d’être au format DCC++. Seule la structure en message CAN de chaque commande nous intéresse : Avant, arrière, vitesse, eStop, fonctions etc… Faut-il en créer une ? Oui s’il n’y en a pas. Par contre, pour la programmation et la lecture des CV's ça va être une autre paire de manche.
Il n'y a pas à être désolé car je comprends bien qu'on peut éviter deux parser en série et qu'il doit être possible d'attaquer DCC++ (paquetRegister) directement. Mais c'est une méthode d'accès nouvelle qui doit nécessiter une interface (qui existe déjà, à mon avis). Pour ce qui concerne le décodage des messages de Withrottle, le parser reste à peu près le même mais ne génèrera pas de messages DCC++.

Concernant la messagerie Can dont les messages comportent un identifiant et 8 octets de données, on peut partir du format qui a éte défini pour les satellites et l'étendre pour ajouter les commandes de traction et fonctions. On peut noter que la centrale peut envoyer des messages (en service, court-circuit, #loco roule ou non, etc..).

Pour la lecture et la programmation des CVs, il n'y a pas plus de difficulté. Mais si la centrale ne dispose pas d'une sortie spéciale pour une voie de programmation, il faut les interfaces ad hoc sur la voie principale, ce qui existe déjà (readCVmain, writeCVByteMain et writeCVBitMain).  Je vais commencer à regarder cela.

Un document de spécifications est en cours d'écriture et attend les premiers retours avant d'être diffusé plus largement.

Bon courage à tous !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 25, 2020, 10:57:48 am
Citer
Le module a  MP158  (1er) semble plus performant que celui a MP2307 (2e), plus petit. Mais on peut prévoir les deux empreintes superposées ...

J'aime assez ces petits convertisseurs et surtout, on arrive à en acheter 10 pour 4€ ce qui fera chuter de manière significative le coût du projet.
On peut donc proposer sur le PCB les 2 empreintes pour permettre à chacun de choisir son composant.

Pour le réglage de la tension, j'ai un doute Dominique. J'ai regardé les schémas de l'ESP32 DevKitC et je vois un seul régulateur qui fait du 3.3V depuis une source 5V Externe. Cette source vient soit de la PIN 5V Ext soit de l'USB mais du coup il faut que cela soit un vrai 5V et non un 7 ou 8V car il ne sera pas régulé. Je crains que l'étalonnage s'impose.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 25, 2020, 11:12:31 am
J'ai regardé les schémas de l'ESP32 DevKitC et je vois un seul régulateur qui fait du 3.3V depuis une source 5V Externe. Cette source vient soit de la PIN 5V Ext soit de l'USB mais du coup il faut que cela soit un vrai 5V et non un 7 ou 8V car il ne sera pas régulé. Je crains que l'étalonnage s'impose.

Mea culpa, il n'y a pas d'entrée Vin donc il faut régler le régulateur (buck) sur 5V. Mais comme le régulateur interne abaisse cette tension à 3,3V, je pense que l'étalonnage n'est pas critique (plage de tolérance à regarder de près). Le seul composant qui utilise le 5V est l'interface USB (CP2102) qui le génère quand l'USB est branché.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 25, 2020, 02:56:05 pm
Sur les pinouts de l'ESP32 DevKit que j'ai, j'ai bien un vin...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: CATPLUS le mars 25, 2020, 04:21:46 pm
Bonjour

https://model-railroad-hobbyist.com/node/35652

Marcel
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 25, 2020, 04:31:46 pm
Bonjour

https://model-railroad-hobbyist.com/node/35652

Marcel

Oui c'est une alternative au smartphone : une manette pour commander une centrale via JMRI comme withrottle (mais moins cher qu'un smartphone  ;D).
Je remarque que cette carte ESP32 dispose aussi d'un Vin : elle a 2x20 pins alors que celle de Thierry en a 2x15 et celles que j'ai à la maison en ont 2x19 et sans Vin !!
Bonjour les multitudes de versions !!!
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 26, 2020, 09:17:38 am
On a un problème de choix de la carte ESP32 : la carte officielle (image ci-dessous) qui a la chance de se trouver partout a 38 pins et pas de Vin
La carte de Thierry et cette de Geoff Bunza dans le lien de Catplus ont un Vin mais pas le même nombre de pins.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 26, 2020, 11:01:16 am
la carte officielle (image ci-dessous) qui a la chance de se trouver partout

A vrai dire, j'ai beau chercher je ne trouve pas ta carte, juste des tonnes d'exemplaires de la mienne, que ce soit sur ebay ou les sites chinois... Je voulais vérifier que le composant qui ressemble à un 7805 au milieu de ta carte était bien ça.
Titre: Re : Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 26, 2020, 11:28:29 am
la carte officielle (image ci-dessous) qui a la chance de se trouver partout

A vrai dire, j'ai beau chercher je ne trouve pas ta carte, juste des tonnes d'exemplaires de la mienne, que ce soit sur ebay ou les sites chinois... Je voulais vérifier que le composant qui ressemble à un 7805 au milieu de ta carte était bien ça.

Tu as peut-être raison mais les 4 premières cartes achetées ont 38 pins sans Vin.
Je vois des DEVKIT V1 à 30 pins avec Vin qui supporte de 4,5 à 12 Volts. on en trouve à 2-3€ Ce sont les plus anciennes.
En fait il y en a aussi plein avec 38 pins car c'est le DEVKITC V4 le plus recent (2019) conforme à celui d'espressif et au alentours de 4 à 5€.

Je sonde un peu les vendeurs, les prix, et les IO disponibles, etc.. pour voir si lequel est recommandé.

https://espacerm.com/webgen/2018/11/12/esp32/ (https://espacerm.com/webgen/2018/11/12/esp32/)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: CATPLUS le mars 26, 2020, 12:31:05 pm
Sans être rabat-joie, j'ai commandé ces ESP32 pour la raison que GEOFFB explique ci-aprés.

https://www.ezsbc.com/index.php/wifi01-35.html#.XnyRRYhKj4Y

Cordialement
Marcel
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 26, 2020, 12:48:03 pm

Sans être rabat-joie, j'ai commandé ces ESP32 pour la raison que GEOFFB explique ci-aprés.l

Dis moi Marcel, sans vouloir moi non plus être rabat-joie, je ne vois ni le CAN, ni l'Ethernet sur ta carte !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 26, 2020, 12:49:37 pm
OUi je m'en doutais !

C'est donc maintenant que nous devons indiquer nos préférences

Elles ont toutes les deux le même ESP32 à 39 pins et les même IO.
J'attend vos réponses !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le mars 26, 2020, 12:55:05 pm
Comme Thierry, j'utilise principalement cette carte parce que c'est celle qui me donne le plus de satisfaction et on la trouve à la tonne sur ebay à des prix de l'ordre de 5€

https://espacerm.com/webgen/2018/11/12/esp32/

Donc ma préférence va vers cette carte
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 26, 2020, 01:27:07 pm
Bonjour,

Je comprends l'idée qu'on utilise un ESP32 qui coûte 5 €. C'est un plus.
Ceci dit, il n'y a pas besoin qu'il y ait des broches CAN puisqu'il y a des sorties SPI.

Concernant les modules (ex satellites), il faudra pouvoir en retirer un SANS couper le bus CAN. ;)
Cela me parait fondamental.
Ce qui implique qu'il y ait des cartes sur le bus CAN qui contiennent les RJ, les 2515/2551. Ces cartes existent déjà (BOB Jean-Luc).
Et on branche les modules dessus via le SPI. A ce moment, on peut enlever un module sans perturber le CAN.
Évidemment, on perd les fonctions du module. C'est imparable.

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 26, 2020, 01:55:19 pm
Bonjour,

J’ai 4 ESP32 et ils ont tous le même nombre de pin 2x19) et sans Vin.
Ce format me va bien du coup, j’ai l’impression que c’est le devkit C

Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 26, 2020, 04:28:51 pm
Il faut remonter à la source qui est ESPRESSIF :
on y trouve le schéma open source de la carte de développement :
Apparemment (à vérifier) l'entrée 5V ne fait qu'alimenter le régulateur 3.3V, un AMS1117 3.3 donc capable de tenir jusqu'à 15V.
Le problème reste la dissipation de température, Rth = 90°/W, température de fonctionnement maxi : 125°C avec protection thermique.
Mais il vaut mieux rester au standard de Vin = 5V si on ne voit pas de bonne raison d'en changer.
Le schéma open source prévoit un connecteur 2x19 pour cette version du 6/12/2017.
Cette version peut être retenue pour notre projet.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-devkitc.html
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 26, 2020, 04:44:42 pm
De mon côté, pas vraiment de préférence. J'ai utilisé ce que je trouvais sur mes sites habituels. Chez Banggood par exemple, il n'y a pas d'autre choix en ESP32 ou les TTGo... Donc passer à une Dev V4 me parait une bonne idée si les fonctionnalités sont les mêmes, a condition de trouver un fournisseur à un prix raisonnable.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 26, 2020, 06:28:00 pm
Il faut remonter à la source qui est ESPRESSIF :
on y trouve le schéma open source de la carte de développement :
Apparemment (à vérifier) l'entrée 5V ne fait qu'alimenter le régulateur 3.3V, un AMS1117 3.3 donc capable de tenir jusqu'à 15V.
Le problème reste la dissipation de température, Rth = 90°/W, température de fonctionnement maxi : 125°C avec protection thermique.
Mais il vaut mieux rester au standard de Vin = 5V si on ne voit pas de bonne raison d'en changer.
Le schéma open source prévoit un connecteur 2x19 pour cette version du 6/12/2017.
Cette version peut être retenue pour notre projet.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-devkitc.html

En effet voici le schéma de la carte ESP32 DEVKITC V4 (version actuelle) qui montre que le 5V externe n'est utilisé QUE par le regulateur NCP1117 (3,3V 1A, supportant jusqu'à 20V, mais il faudra l'éviter !!). En l'absence d'alimentation ce 5V est fourni par la prise USB qui est protégée par une diode schottky

ON peut donc choisir une alimentation à découpage réglable dont la tension de sortie n'est pas rigoureusement égale à 5V.
Pour le modéliste utilisateur, il faudra monter l'alimentation 5V AVANT l'ESP32 et mesurer la tension avec un multimètre pendant la manoeuvre du petit potentiometre qui est sur cette carte alimentation. Lorsque la tension obtenue est entre 4,9 et 5,1V il pourra monter l'ESP32 ensuite. Donc 2 points de tests 5V et GND doit être prévus sur le PCB.

Le DEVKITC V4 que je recommande apparait quand même en plus grand nombre sur les sites de vente (eBay, AliExpress, etc..) mais nous ne pourrons éviter d'avoir quelques ESP32 dans nos stocks qui ne correspondent pas exactement (c'est mon cas).
Exemple à 3,65€: https://fr.aliexpress.com/item/4000155919030.html (https://fr.aliexpress.com/item/4000155919030.html)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 27, 2020, 08:47:47 pm
Bon on a quand même un gros problème : ce projet n'a pas de nom !

Pour continuer les développements de la bibliothèque DCCpp sans polluer la version actuelle, je me proposait d'en faire un fork -une version séparée- qui pourrait être généreusement modifiée. A charge pour moi ensuite de réintégrer les meilleurs morceaux dans la version officielle. Mais pour faire un fork, il faut que je lui donne un nom !

Qui a des idées ? Je propose PicoDcc, LocoDCCuino (mais c'est pas facile à dire...), MicroDcc, et CentralDcc.

A vos plumes.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 27, 2020, 09:00:06 pm
Bon on a quand même un gros problème : ce projet n'a pas de nom !
A vos plumes.

Oui on y a pensé et on a quelques propositions qui me plaisent bien  :
Dominique : La Box Locoduino ou simplement La Box;
Pik35 : Locobox;

Mais comme tu dis : à vos plumes !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 27, 2020, 09:03:40 pm
Lâchons nous : Boxoduino.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 27, 2020, 09:08:02 pm
Denis : La Box

Pour les personnes de l'extérieur, pour ne pas se mélanger, diront d'eux mêmes : "La Box de Locoduino"
Mais, pour nous, comme il n'y aura pas d'ambiguïté, on dira "La Box" ou "Notre Box"

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 28, 2020, 12:00:56 pm
Je viens de tester avec succès la combinaison de l'ESP32 DevKit C (V4), une alim à découpage buck converter fournissant du 5V, le pont en H L6203 ET DCCpp 1.0.4 avec l'exemple Autotest.

Ma loco fonctionne parfaitement avec le clignotement de ses feux à la fin du script.

Le signal DCC est propre.

C'est encourageant  ;D

Nous préparons un premier circuit imprimé de test, le cahier des charges, le choix des composants, etc.. Si vous souhaitez le consulter, vous pouvez m'envoyer un MP.

Amicalement
Dominique
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le mars 28, 2020, 02:42:42 pm
Comme prévu, un nouveau projet Locoduino est apparu sur Github, appelé 'LaBox'. Ce nom pourra changer ultérieurement si nécessaire.
Le projet reste une librairie sur le modèle de DCCpp. Par contre un seul exemple est fourni, c'est le code WifiDcc.ino de Christophe.
De son côté, DCCpp va retrouver le visage qu'elle présentait avant l'intervention de Christophe sur ses sources.

Pour ceux qui veulent travailler sur ce projet, je vous conseille de cloner le repository sur votre machine, soit par ligne de commande (la syntaxe doit se trouver sur le net...) soit, pour les fainéants des doigts comme moi, avec un outil interactif plus sympathique. Sans vouloir imposer mes outils, j'utilise depuis le début de Locoduino un outil qui s'appelle Gitkraken qui me permet de gérer ma douzaine de repositories sans taper une ligne de commande ! Cet outil est gratuit, et disponible sur toutes les plateformes. https://www.gitkraken.com/ (https://www.gitkraken.com/) .Il n'a qu'un petit défaut, il n'existe qu'en anglais.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 31, 2020, 02:27:19 pm
Bonjour,

Dans la série des disjoncteurs américains, je viens de trouver des modèles beaucoup moins chers.

http://voltscooter.com/?page_id=134 (http://voltscooter.com/?page_id=134)

Pour $5,95, on peut régler le courant d'une sortie 0.75 A, 1.5A, 2.3A.
Ré-enclenchable (bouton inclus) et on peut ajouter une LED pour voir la disjonction.

Il existe un modèle 0.6A, 1.1A, 1.8A, 2.5A montable en façade.

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le mars 31, 2020, 03:56:23 pm
C'est pas mal du tout ces petites protections.

Après, ST propose des schémas pour la protection court-circuit :
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=15&ved=2ahUKEwj9xM2g7sToAhVOa8AKHegiCR8QFjAOegQIARAB&url=https%3A%2F%2Fwww.st.com%2Fresource%2Fen%2Fapplication_note%2Fcd00003789-shortcircuit-protection-on-the-l6201-l6202-and-the-l6203-stmicroelectronics.pdf&usg=AOvVaw1sojnaaDRGm-AyuF4z_d47



Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 31, 2020, 04:35:31 pm
Bonjour Cédric,

Je sais, il y a des protections dans les L620x. OK
Non, ce que je vois, c'est de diviser le réseau en sections.
En sortie de La Box, on a 4A. C'est bien pour un réseau, mais c'est trop (à mon avis) pour une section.

Mon idée : séparer les sections de façon à ce qu'un CC ne plante pas toute La Box. Avec ce schéma, on n'a qu'une zone de coupée.
C'est dans cet usage que j'ai proposé ce petit circuit.

(http://www.locoduino.org/local/cache-vignettes/L150xH100/alimentation_des_sections-8757d-43b84.png?1585665187)

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 31, 2020, 04:56:09 pm
Non, ce que je vois, c'est de diviser le réseau en sections.
En sortie de La Box, on a 4A. C'est bien pour un réseau, mais c'est trop (à mon avis) pour une section.

Mon idée : séparer les sections de façon à ce qu'un CC ne plante pas toute La Box. Avec ce schéma, on n'a qu'une zone de coupée.
C'est dans cet usage que j'ai proposé ce petit circuit.

C'est très bien et pas cher et on peut l'installer en plus de La Box quand on peut.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le mars 31, 2020, 06:10:58 pm
Bonjour,

ça ressemble au Polyfuse qui est une protection par PTC (résistance à coefficient positive). On en voit sur certains de nos Arduino.

https://www.ebay.fr/itm/20PCS-6V-2A-Resettable-Fuse-PPTC-1206-3-2mm-1-6mm-SMD/332228475512 : 2,5€ / 20 = 0,125€ pièce

Le principe est que la résistance chauffe et donc augmente avec le courant de court-circuit et finit par réduire ce courant.
Ce principe est bien moins rapide qu'une détection électronique et risque de ne fonctionner qu'après la détection générale (et donc jamais).

Cette question est celle de la sélectivité des protections que les électriciens (BT et HT) adorent.

Faites nous un retour de vos expériences.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mars 31, 2020, 07:05:07 pm
Pendant que vous confinez, je test un proto de La Box avec les ingrédients cibles (L6203, OLED, CAN, convertisseur DC/DC, etc..)
- DCC = ça marche (une loco roule avec la bibliothèque La Box),
- OLED = OK avec boutons + / - / SEL.
je passe au CAN maintenant avec les Arduinos de test !!
A suivre ..
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mars 31, 2020, 07:36:23 pm
Bravo Dominique,

On sent que ça carbure... !

Le béotien que je suis est inquiet qu'il n'y ait que 3 boutons.
Pourvu qu'on ne passe pas son temps en menu, sous-menus, monter, descendre...
OK pour tester, mais pas dans la version définitive.
Mais on verra l'ergonomie plus tard.

M. Jourdain (qui fait de l'informatique sans le savoir  ;D)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 01, 2020, 01:00:18 pm
Maintenant  je confirme que le CAN fonctionne, en tout cas pour la réception : je dois faire pas mal de tests pour bien utiliser la bibliothèque "CAN" de Sandeep Mystry qui se trouve dans le gestionnaire de bibliothèque et qui contient une documentation claire.

Par exemple, j'ai testé une connexion avec mon configurateur de satellites. c'est ce qu'il envoie aux satellites via le bus Can (voir l'article https://www.locoduino.org/spip.php?article243 (https://www.locoduino.org/spip.php?article243), à la fin, paragraphe "configuration" pour plus de détails :

commandes de luminosité de led:
Received extended packet with id 0x1FFFFF27 and length 3 hex 1 4 FF
Received extended packet with id 0x1FFFFF27 and length 3 hex 81 4 FF

commandes de position maxi d'un servo :
Received extended packet with id 0x1FFFFF27 and length 4 hex 0 1 6 A5
Received extended packet with id 0x1FFFFF27 and length 4 hex 0 1 6 A6
Received extended packet with id 0x1FFFFF27 and length 4 hex 0 1 6 A7
Received extended packet with id 0x1FFFFF27 and length 4 hex 0 1 6 A8
Received extended packet with id 0x1FFFFF27 and length 4 hex 0 1 6 A9

commandes de vitesse de rotation d'un servo :
Received extended packet with id 0x1FFFFF27 and length 6 hex 0 2 40 C CC CC
Received extended packet with id 0x1FFFFF27 and length 6 hex 0 2 40 13 33 32
Received extended packet with id 0x1FFFFF27 and length 6 hex 0 2 40 19 99 98
Received extended packet with id 0x1FFFFF27 and length 6 hex 0 2 40 1F FF FE

Etat des détecteurs de satellites :
Received packet with id 0x20 and length 3 hex 0 0 0
Received packet with id 0x26 and length 3 hex 0 0 80
Received packet with id 0x22 and length 3 hex 0 0 80
Received packet with id 0x24 and length 3 hex 0 0 0

Donc d'ors et déjà je valide les choix des pins CAN : TX 5 et RX 4
ainsi que l'I2C : SDA 21 et SCL 22

A suivre
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 01, 2020, 03:51:19 pm
Ce qui nous donne les allocations des pins de l'ESP32 DevkitC suivante :
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 01, 2020, 03:53:19 pm
et le schéma suivant de la bestiole :
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 01, 2020, 04:48:28 pm
Bonjour Dominique,

Beau boulot. Impressionnant.👏

Il semble y avoir quelques divergences entre l'affectation des pins et le schéma Eagle, mais c'est de la relecture.

Je ne comprends pas le branchement du MP2307, ni d'où vient le 3.3V ?

Mais je suis bien conscient que c'est toujours plus facile de geindre que d'être aux commandes...
(toute ressemblance avec la situation actuelle est tout à fait fortuite ;D)

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 01, 2020, 05:42:43 pm
Merci Denis pour ton concours actif  ;D

Il semble y avoir quelques divergences entre l'affectation des pins et le schéma Eagle, mais c'est de la relecture.
Le mieux est que tu signales tout ce que tu vois.

Citer
Je ne comprends pas le branchement du MP2307, ni d'où vient le 3.3V ?
LE MP2307 est une alternatif au MP1584. Les entrées à gauche pour le MP2307 sont décallées par rapport aux entrées du MP1584 de façon à pouvoir équiper la carte soit avec l'un, soit avec l'autres (les sorties sont les même).
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 01, 2020, 07:10:24 pm
Bon Ok Denis, j’ai du me tromper de fichier :C'est corrigé et toi tu mets à jour ta liste ci-dessus en mode correction  ;D ;D
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 02, 2020, 10:05:48 am
Bonjour,

Dans l'Arduino, l'une des idées géniales est la création des shields.
Je pense qu'on pourrait l'utiliser ici.

En effet, on voit bien qu'on n'a pas utilisé toute la substantifique moelle de l'ESP 32. Il reste des broches inutilisées, des nouvelles fonctions à créer...
Or on veut faire un module de base extensible.

Je propose d'utiliser des connecteurs comme ceux de l'Arduino, qu'on peut empiler. En plus, on gagne des fils, c'est plus propre, comme montage.
Si vous regardez le dessin que j'ai fait, vous voyez, au milieu un éventuel shield. Il est au milieu pour que l'affichage (sans fils, donc) soit en haut.
Si on ne met pas de shield on met quand même les connecteurs pour que l'écran soit juste en dessous du haut du boîtier, quelle que soit la configuration.
En plus, ça laisse de la place pour ventiler le 6203 qui va chauffer avec 4A.

Et le 6203 est au bord, pour qu'on puisse mettre un radiateur.

Voilà, voilà ...
Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le avril 02, 2020, 12:21:03 pm
Bonjour,
excellente idée, je pense qu'on la garde pour la version 2.0
Cordialement

PS : le 6203 est au bord pour qu'on puisse y mettre un radiateur.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 02, 2020, 12:56:43 pm
Le CI est déjà fait ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le avril 02, 2020, 02:09:30 pm
Non, mais l'essentiel du boulot pour la V1.0, oui.

Mais pour la V2.0, ne pas oublier qu'on peut souder l'ESP32 directement sur le pcb, mais que si on le met sur un support, celui-ci a la même hauteur que le support du shield.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pierre59 le avril 02, 2020, 02:27:55 pm
Bonjour

L'idée de Denis d'empiler les cartes filles est une bonne idée, cela améliore beaucoup la modularité.
Mais pourquoi ne pas mettre la partie puissance (booster) aussi sur une carte séparée de l'ESP32 , cela améliorerait beaucoup la modularité.

Cordialement

Pierre
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le avril 02, 2020, 02:41:10 pm
Au point où nous en sommes (et on ne doute pas d'aller beaucoup plus loin ensuite pour faire la centrale universelle) on cherche une solution compacte, qui puisse être réalisée par des amateurs peu entrainés (et tout à fait capables de faire des erreurs de câblage).
Donc un seul circuit, rassemblant tous les composants, avec des connecteurs parait raisonnable.
Un booster indépendant existe, voir le montage de Dave Bodnar.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 02, 2020, 09:28:49 pm
Au point où on en est, autant préciser le cadrage du projet :

Le projet initial en version 1 représenté dans le cadre de gauche « Etape 1 » se limite à être une centrale DCC ouverte. Des extensions peu couteuses sont prévues (et optionnelles, les composants pouvant ne pas être installés) pour permettre des développements complémentaires possibles ultérieurement.

(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=2942;image)

On y voit un unique micro-contrôleur ESP32 Devkit C, serveur Wifi et générateur DCC, un écran OLED 4 lignes de 20 caractères, un pont en H à base de L6203 pour délivrer 4A avec mesure de tension et de courant, une alimentation 5 V à découpage et un bus Can (driver de ligne). A cela s’ajoute une alimentation externe de type bloc secteur 15V 4A (ou alim de PC portable pour le HO) qui n’est pas comptée dans le projet (chacun en possède au moins une à la maison).
L’ESP32 réalise un serveur WiFi 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). Mais aussi en mode client Wifi d’une box pour usage à la maison. Ce serveur peut être un point d’accès Wifi pour des smartphones ou pour le logiciel JMRI.
L’ESP32 réalise aussi une centrale DCC++ avec une sortie de 4A vers les rails, pouvant être commandée par le Wifi ou par le port USB-série de l’ESP32 ou par commandes logicielles de la bibliothèque DCCpp (maintenant dénommée "La Box").
Malgré les possibilités étendues de l’ESP32, le projet se limitera à la base représentée à gauche de ce schéma (une centrale DCC), mais laisse la possibilités d’extensions possibles du fait de ses caractéristiques techniques intéressantes. Ces extensions ne seront pas mises en oeuvre dans le cadre du projet initial.

Donc une plateforme  prototype (circuit imprimé) correspond au projet initial et supportant tous les ingrédients ci-dessus.
A ce stade nous avons vérifié grosso modo le fonctionnement de "La Box", de l'interface Wifi, de l'interface Can (avec les satellites) et de l'OLED, ne serait-ce que pour confirmer le schéma et lancer un circuit imprimé prochainement.

Le but est déjà le pilotage de DCC++/DCCpp/La Box par le WiFi, à partir de JMRI par exemple qui sait transmettre les commandes natives de DCC++ en WiFi, ou d’autres systèmes de gestions de circulation. Dans ce cas des smartphones pourront être connectés à JMRI en WiFi pour les commandes des trains;
Possibilité de commande directe de DCC++ en mode USB/série.
Possibilité de commandes de trains directes par smartphones sans passer par JMRI

Parmi les extensions du projet (dans une phase ultérieure), il y aura la gestion du bus Can permettant de connecter une rétrosignalisation (capteurs) et des appareils de voie (aiguilles, signaux), ainsi que des commandes d’éléments de décor (éclairages, passages à niveau, annonces en gare, etc..). Si l’ESP32 le permet,  un automate de réseau embarqué pourrait tirer profit des satellites sur le Can.
Une voie possible à explorer serait aussi de remonter la rétrosignatisation venant du Can vers JMRI.
Mais on en est pas là et il est souhaitable que d'autres participants se joignent au projet.

C'est pour cela que la réalisation en phase 1 reste ouverte du point de vue matériel, sans prétendre prévoir toutes les extensions possibles et les variantes mécaniques qui en découlent. Un connecteur d'extension est disponible sur le coté de la carte pour y brancher une nappe à parvers une fente dans le boitier en 3D à faire.

Sans ces extensions, cette petite centrale sera déjà capable de faire beaucoup de choses  ;D...si on y arrive  8), et si ça vous intéresse, préparez-vous à proposer votre participation dans les semaines prochaines (c'est trop tôt maintenant).



Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 04, 2020, 10:30:59 am
Bonjour,

Mais, au fait, on prévoit une sortie pour la voie de programmation ? 1A est suffisant.

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 04, 2020, 10:43:54 am
Bonjour,

Mais, au fait, on prévoit une sortie pour la voie de programmation ? 1A est suffisant.

Denis
Non, sauf via le bus d'extension
Pour un débutant et pour le majorité des cas, la programmation sur le voie principale sera suffisante (comme la Z21 blanche)
On veut un petit prix pour faciliter l'adoption.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le avril 04, 2020, 03:51:16 pm
Bonjour à tous

Nouvelle version de 'LaBox' aujourd'hui :

- La réception de messages par le port série est actif dés que USE_TEXTCOMMAND est actif, et ceci même si le Wifi ou l'Ethernet sont activés. Dans DCCpp, ce sont des modes mutuellement exclusifs. C'est utile par exemple pour tester le Wifi tout en gardant la possibilité d'envoyer un ordre par la console de l'IDE...
- La réception de messages est passée sur le coeur 0, sachant que le programme principal du .ino est lui sur le coeur 1.
- Dans Locomotives, il y a maintenant une affectation automatique des registres à concurrence du nombre maximum déclaré dans config.h .

Il faut tester pour savoir si c'est efficace et si on ne perd plus de messages. La pile est fixée en dur à 10 messages maximum, de 9 caractères maxi, mais on peut augmenter tout ça si besoin.

La prochaine étape sera d'allouer une pile de messages par type d'entrée : Wifi, Ethernet et Serial, voire I2C ou SPI, pourquoi pas... Les modes ne doivent plus être mutuellement exclus et doivent pouvoir cohabiter. Il faut permettre d'avoir à l'instant T une manette Wifi, un site Web et la console IDE ou JMRI en série qui donne des ordres. Mais il subsiste un gros problème, c'est la réponse donnée à celui qui demande une action par le même canal. Il faut donc remplacer DCCPP_INTERFACE par quelque chose de plus souple et dédié à chaque manette. Je pense coder une classe Throttle qui disposera de sa propre pile de messages, saura quel est son mode de communication, et qui transmettra ses propres réponses. A creuser.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 04, 2020, 04:57:47 pm
Waooh !

Je me demandais comment répartir les tâches entre les 2 coeurs...  et ben voilà  ;D

Merci Thierry !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 05, 2020, 07:09:58 pm
La version 8g du pcb permet les 2 variantes des boutons (droits et 90°) ainsi que les 2 variantes d’Oled (0,91“ 4 lignes et 0,96“ 5 lignes) qui seront quasiment superposées pour que les éléments restent au même endroit en face avant. La variante « a plat » sur le pcb permettra de monter les composants à plat, sans nécessiter de boitier et un accès plus simple aux organes. Un boitier standard sera peut-être facile à adapter (donc sans imprimante 3D).
Quelques images montrent les variantes à plat et en face avant.
Le schéma et le pcb sont en PJ.
Un grand connecteur d’extension est disponibles sur le coté du pcb pour tester des extensions (2ème booster, par exemple).

A ce stade il va être bientôt possible de commander des pcb à JLCPCB (prix + port : 5 ex : 2+7=9€ ou 10ex : 5+10=15€) Je pense en commander 10 (1,5€ chaque) pour commencer à tester.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 05, 2020, 07:18:47 pm
et d'autres images..
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 05, 2020, 07:23:55 pm
J'ajoute la BOM, liste des composants à se procurer par soi-même ou en bourse d'échange.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 06, 2020, 10:34:22 am
Bonjour,

Sur un schéma d'Elektor qui utilise un ESP32, on nous explique que si l'alimentation n'est pas faite par un 7805, mais par un convertisseur DC/DC, la tension de sortie (le 5V) peut n'être pas tout à fait stable au début.
Ils conseillent de brancher un condo de 10 µF entre la broche EN (broche 2) et la masse, ce qui retarde la mise en route de l'ESP32, le temps que la tension se stabilise.

Mais il est certainement trop tard pour modifier le CI...

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 06, 2020, 05:15:59 pm
Bonjour,

Sur un schéma d'Elektor qui utilise un ESP32, on nous explique que si l'alimentation n'est pas faite par un 7805, mais par un convertisseur DC/DC, la tension de sortie (le 5V) peut n'être pas tout à fait stable au début.
Ils conseillent de brancher un condo de 10 µF entre la broche EN (broche 2) et la masse, ce qui retarde la mise en route de l'ESP32, le temps que la tension se stabilise.

Mais il est certainement trop tard pour modifier le CI...


Denis

Non, pas trop tard et c'est fait !
J'ai mis à jour les images du schéma et du pcb.
La commande des CIs va partir aujourd'hui. Nul ne sait quand elle arrivera ... :o
MAIS C'EST PARTI !

Un grand merci à Michel (msport) qui a écouté et réalisé toutes nos demandes.. nombreuses  ;D
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 06, 2020, 06:50:38 pm
Effectivement, rien qu'à voir le numéro de version, on a une idée du travail de Michel.
Merci à lui.

J'aurais bien voulu trouver cet article avant, mais c'est bien qu'il ait été pris en compte.

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le avril 06, 2020, 07:11:28 pm
... le numéro de version ...

je suis plutôt facétieux (1er avril oblige), je numérote à partir de mon heure de réveil !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le avril 07, 2020, 12:46:34 am
Premiers essais de l’IHM sur la vue tableau de bord :

https://www.youtube.com/watch?v=3vp-6vu-WzM (https://www.youtube.com/watch?v=3vp-6vu-WzM)

Il y a le logo Locoduino pendant les 2 premières secondes du boot.
Je pousse des ordres aléatoires histoire de faire bouger les choses.
Veuillez me pardonner si vous voyez des appels de fonction de l’ordre de F190 ou F240.
La liste à gauche représente les 4 derniers ordres reçus sachant qui il y a une pile de 10 messages.
Sinon le message est composé de l’adresse de la machine, le type d’ordre et la valeur.
Les valeurs de courant/tension sont émulées. Il y a même du courant alors la centrale est à l’arrêt.
L’éclair signifie que la centrale est hors ligne/court-circuit (je dois créer une image pour distinguer les 2 états).
A suivre.

Le clignotement est liée à la fréquence de l’afficheur avec celui de l’appareil photo.

Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 07, 2020, 07:40:31 am
Apparemment, un pb de video...
Je ne vois rien  :P
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le avril 07, 2020, 08:49:53 am
Ca devrait être mieux...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 07, 2020, 09:01:11 am
Merci Thierry !

Et j'ai même pu voir Monia...
Je ne sais pas ce que tu as fait, mais c'est bon.

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 07, 2020, 11:35:09 am
Les circuits qui arriveront seront distribuées comme suit :

Michel2
Dominique2
Cédric1
Christophe1
Thierry1
Denis1
Marcel1

Il en reste 1 pour un retardataire  :D
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 08, 2020, 10:43:18 am
Voici la liste des composants :
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 11, 2020, 09:36:42 pm
Et si ça vous intéresse de suivre la livraison, le numéro de suivi est LL255349414LU

Le circuit a été expédié  (发货) le 2020-04-09 à 07:22:49
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 13, 2020, 02:55:20 pm
Bonjour à tous,

Maintenant que le premier proto de cette centrale est en cours de livraison (10 plaques que j'attends d'ici à 3-4 semaines), certains d'entre nous ont commandé des composants manquants.

Vous qui visitez ce site, qu'en pensez-vous ?
Ce projet peut-il vous intéresser (vous, votre club, vos enfants) ?
Quelles suggestions feriez-vous ?
Merci de votre réponse.

Cordialement
Dominique
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le avril 13, 2020, 04:54:42 pm
Bonjour à tous

Nouvelle version 0.2 de LaBox livrée sur Github.

Les Throttles sont apparues. Une Throttle est basique-ment un moyen de recevoir des ordres texte DCC++. Il y a quatre variantes de Throttle disponibles, dont 3 sont utilisables sur un ESP32. J'ai volontairement bloqué ThrottleEthernet aux seuls AVR pour l'instant.
Un throttle reçoit des ordres de l'extérieur, qu'elle pousse dans la MessageStack générale introduite dans la version précédente. Dans le message est intégré à son début un numéro sur trois digits qui correspond à l'identifiant de la Throttle, et qui va servir à demander à cette même Throttle de renvoyer la réponse lorsque le message sera traité. Toute cette partie continue bien sûr d'être exécutée sur le second core de l'ESP32 .
Toutes les Throttles déclarées sont dans une liste chaînée gérée par la classe Throttles. Le constructeur de base de Throttle pousse 'this' dans la liste... Il suffit de déclarer un nouveau Throttle pour le voir apparaître dans la liste visualisable sur la console avec Throttles::printThrottles(). Il peut y avoir plusieurs Throttle de chaque type, chacune ayant son identifiant et son nom. L'identifiant est fixé automatiquement.
Aujourd'hui, il n'y a pas de moyen de remplir la liste des Throttles dynamiquement en fonction de ce qui apparait ou pas, mais chacune peut être connectée ou non. Il suffit dans le .ino de prévoir une plage suffisamment large de tout ce qui peut être connecté, et lorsqu'une Throttle doit se connecter, redémarrer l'ESP suffit... On va voir qu'il y a malgré tout une possibilité plus souple.

- ThrottleSerial.
    C'est le Throttle de base, celui qui permet de recevoir des commandes depuis la console de l'IDE. Contrairement à ce qui se faisait jusque là dans DCCpp (et DCC++), toutes les interfaces séries sont exploitables, y compris les versions émulées comme avec SoftwareSerial ou AltSoftwareSerial. Il suffit de déclarer un SERIAL_INTERFACE avec un type et un nom.
Par exemple SERIAL_INTERFACE(Serial3, MaBoxAMoi) va créer un canal de communication sur le port Serial3 qu'un ThrottleSerial pourra exploiter sous le nom SerialInterfaceMaBoxAMoi. L'exemple LaBox.ino permet de mieux comprendre le fonctionnement. A noter que c'est un mécanisme que j'ai déjà employé dans Commanders depuis longtemps...

- ThrottleWifi
    C'est exactement ce que Christophe avait codé dans la version précédente de LaBox. Par contre je ne l'ai pas testé.

- ThrottleWifiAPClient
    Il s'agit de la déclaration par l'ESP32 d'un point d'accès Wifi suivi de la création d'un certain nombre de clients. Le nombre de client est fixé dès le démarrage pour éviter les allocations/désalocations qui fragmentent la mémoire pendant le fonctionnement. Dans l'exemple LaBox par exemple, j'en ai déclaré quatre. Ces clients se connectent et se déconnectent au fur et à mesure des besoins. Sans doute faudra t-il mieux tester cette partie, je n'ai pu qu'en connecter deux différents à la fois... C'est le seul moyen aujourd'hui d'avoir une centrale dynamique sur qui se connectent plusieurs intervenants, qui peuvent ensuite laisser leur place à d'autres.

/*************************************************************
project: <LaBox>
author: <Thierry PARIS>
description: <LaBox Wifi Controller sample>
*************************************************************/

#include "LaBox.h"

#if !defined(USE_TEXTCOMMAND) || !defined(USE_WIFI)
#error To be able to compile this sample,the lines #define USE_TEXTCOMMAND and #define USE_WIFI must be uncommented in DCCpp.h
#endif

// WIFI

const char* ssid     = "ssid";
const char* password = "password";

// the media access control (ethernet hardware) address for the shield:
uint8_t wifiMac[] = { 0xBE, 0xEF, 0xBE, 0xEF, 0xBE, 0x80 };
//the IP address for the shield:
uint8_t wifiIp[] = { 192, 168, 1, 100 };

// SERIAL

SERIAL_INTERFACE(Serial, Normal);

ThrottleSerial throttleSerial("Serial", new SerialInterfaceNormal());
ThrottleWifi throttleWifi("Wifi", wifiMac, wifiIp, 2560, TCP);

void setup()
{
  Serial.begin(115200);
  Serial.println("LaBox 0.2");

  // Add 4 Wifi clients
  ThrottleWifiAPClient::connectWifi(ssid, password, 23, 4);

  Throttles::printThrottles();
 
  DCCpp::begin();
  /* Configuration for ESP32, can be adapted...
  DIR -> GPIO_32
  PWM -> EN
  MAX471 -> GPIO_36 (A0)
  */
  DCCpp::beginMain(UNDEFINED_PIN, 32, 34, A0); 
}

void loop()
{
  DCCpp::loop();
}
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Jeje_12_34 le avril 13, 2020, 05:07:48 pm
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  :)

Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 13, 2020, 05:51:40 pm
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  ;D
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 13, 2020, 05:58:06 pm
Bonsoir Thierry,

Citer
redémarrer l'ESP suffit...
J'ai dû louper quelque chose  :o

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le avril 13, 2020, 08:42:16 pm
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...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 13, 2020, 09:13:04 pm
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
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 13, 2020, 10:09:08 pm
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).
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pierre59 le avril 14, 2020, 09:32:09 am

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
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 14, 2020, 09:37:54 am
Merci Pierre,

Me voilà rassuré  ;D
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
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Jeje_12_34 le avril 18, 2020, 07:43:55 pm
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
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le avril 18, 2020, 09:59:44 pm
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
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Jeje_12_34 le avril 18, 2020, 11:15:44 pm
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
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 19, 2020, 09:22:27 am
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 (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 :
A suivre ...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le avril 19, 2020, 09:26:32 am
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.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 19, 2020, 11:28:29 am
Merci Thierry, c'est essentiel de rappeler ce principe  :D

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 (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 (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 (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 (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 (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  :P

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
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  ;D

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  ;D
Et j'ai surement omis des tas de choses (à vos questions ....)

Amicalement
Dominique
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le avril 24, 2020, 12:44:38 pm
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.

https://m.youtube.com/watch?v=ubl6p8n7N1U


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...  ;)

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 27, 2020, 02:42:44 pm
J'ai peut être oublié de publier le schéma de cette première version de La Box. Le voici :

(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3074;image)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 27, 2020, 03:12:35 pm
Pour utiliser très prochainement l'IHM de Pik35, le serveur Wifi pour les applications Withrottle (IOs) et Engine Driver (Android) fonctionne maintenant sur ESP32.
Jusqu'à 3 manettes Smartphones possibles pour commander 3 locos (voire 6 car les applications peuvent en piloter 2 chacune.

L'écran Oled ci-dessous est minimal (pour la mise au point) et affiche l'adresse IP du point d'accès  et  3 manettes maximum (adresse dcc, direction et vitesse).

Pour l'anecdote, la vitesse de la loco d'adresse 18 est à zéro, car j'ai changé d'application pour prendre la photo avec l'un des iPhones, ce qui entraîne l'arrêt automatique de la loco (on n'est pas sensé faire 2 choses à la fois !)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 30, 2020, 10:02:34 am
Bonjour,

Plein de choses à dire sur diverses interventions.

1°) Thierry (19 Avril) :

Je suis tout à fait d'accord avec ton analyse. Il faut faire ce qu'on a dit et se "limiter" à ce qu'on a dit.
Mais quelle limite !

Juste ce qui se fait de mieux comme microcontrôleur abordable, l'ESP32, la meilleure bibliothèque DCC, la DCCpp, le meilleur bus, le CAN…
Et un écran qui, bien que minuscule, a le mérite d'exister. Rappelons que SPROG et Pi-SPROG ONE ($170,95 aux US) n'en ont pas. Et c'est un vrai plus, quand on voit ce que Cédric arrive à nous sortir.
Donc, ne minimisons pas ce qu'on est en train de faire, c'est une formule 1.

En plus, comme c'est nous qui le faisons, c'est open-source et ça peut toujours être amélioré. Et on saura comment faire, le moment venu.

2°) Dominique (19 Avril) :

Voilà le "cahier des charges" que j'aurais voulu avoir au début. Cela m'aurait évité de raconter pas mal de bêtises  ::).
Mais, comme on le voit pour la pandémie, c'est beaucoup plus facile de faire la météo de LA VEILLE… ;)
C'est très clair, bien détaillé. On voit où on va.

Juste un détail : l'appli Withrottle (iOS) est nettement meilleure (et plus jolie) que celle de Engine Driver (Android). Tu vas trouver ça "normal", bien sûr.
Bon, elles ont le mérite d'exister et ça nous fait ça de moins à faire dans un premier temps.

On va pouvoir se concentrer sur le CAN qui, de toute façon, sera identique quelle que soit la version.

Nota : je suis cité 2 fois (en bien ;D) et je t'en remercie.

3°) Cédric (24 Avril) :

C'est vraiment bien. Plein de bonnes idées et visiblement, une bonne maîtrise. Bravo !

Citer
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.
Désolé, mais, si, je m'inquiète. Il faut ajuster la fréquence de l'IHM pour qu'on n'ait plus ce phénomène. Tu vas me dire que je m'intéresse plus à la forme qu'au fond (et, ici, tu as raison), mais je n'ai toujours pas vu la fin de la vidéo (c'est vraiment pénible). Sorry…

C'est marrant que tu aies pensé, d'emblée, de gérer du multilingue…

Je note que tu parles de mémoriser et c'est une excellente chose.
Que doit-on mémoriser quand on a fini la session pour pouvoir la retrouver la prochaine fois ?
Qu'est ce qui est vraiment indispensable ?
Mémorise-t-on des choses périodiquement pour pouvoir repartir suite à coupure courant ? (on appréciera lors d'une démo).
On sera certainement très limité par la taille de l'EPROM.

Je note que tu gère les trois derniers trains dynamiquement. Tu verras quand je publierai très prochainement la dernière version de mon gestionnaire sur laquelle je travaille actuellement qu'on a eu la même idée.

Concernant les images : très bonne idée d'afficher notre logo au départ (sur ma télé, c'est marqué "Phillips" pendant 10 secondes).
Par contre, par la suite, je pense qu'on pourrait gagner une ligne ? (encore la forme)

Pour le fond, j'ai vu que tu pensais afficher la tension et l'intensité (avec 2 chiffres après la virgule).
Franchement, ce serait super bien, mais, à mon avis infaisable tel quel.

On n'a pas de capteurs et on ne va pas pouvoir en mettre comme avec une alim analogique (un en série et un en parallèle) en sortie d'alim.

Pour mesurer une tension/intensité DCC, il faut un multimètre haut de gamme ("True RMS") pour que l'indication veuille dire quelque chose.

D'autre part, ce qui serait intéressant, ce serait la tension/intensité aux bornes du moteur.  ;)
Parce que, sinon, ça ne veut pas dire grand-chose puisque ce qui circule dans les rails, ce sont des messages DCC.

Là où on pourrait indiquer quelque chose, c'est en sortie du convertisseur buck puisqu'on est encore en analogique. Là, j'y crois.
Et on pourrait éviter quelques grillages de locos... ::)

Enfin, comme l'ESP32 sait quel palier DCC est envoyé dans les rails (parmi 14/28/128) et qu'on a la tension maxi en sortie de convertisseur, on pourrait afficher une tension par une simple règle de trois.
Et, cerise sur le gâteau, on pourrait même tenir compte des CV2 à 6 et, ainsi, afficher quasiment la tension exacte aux bornes du moteur.
Voir, par exemple https://www.opendcc.de/french/information/dcc_cv_f.shtml (https://www.opendcc.de/french/information/dcc_cv_f.shtml)

Nota : la NMRA a mis à jour sa norme électrique DCC (maintenant 9.1) le 7 mars 2020. C'est très récent.
Je pense traduire la doc NMRA des CV. On y apprend, par exemple, que les CV 105 et 106 sont réservés aux utilisateurs… :P

Dominique (27 Avril) :

Je ne vois pas le 10 µF sur la broche ENABLE ? Ni dans la BOM ?

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 30, 2020, 10:19:22 am
Bonjour Denis,

As-tu un téléphone Android ? et un ESP32 ? (les 2 à la fois)
Si oui puis-je te demander si tu peux tester mon programmes Wthrottle/EngineDriver et me rapporter les sorties sur le moniteur de l'IDE ?

Merci d'avance
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 30, 2020, 10:47:12 am
Désolé...

J'ai, bien sûr, un Androïd, mais pas d'ESP32. Je vais faire une commande chez TME.

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 30, 2020, 10:50:37 am
Désolé...

J'ai, bien sûr, un Androïd, mais pas d'ESP32. Je vais faire une commande chez TME.

Denis
ceux-là ont l'air pas mal : https://www.aliexpress.com/snapshot/0.html?orderId=8011987484957074 (https://www.aliexpress.com/snapshot/0.html?orderId=8011987484957074)
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le avril 30, 2020, 03:32:16 pm
Bonjour Denis,

Merci pour cette analyse pertinente.
Je vais tenter de te répondre point par point.

Citer
C'est vraiment bien. Plein de bonnes idées et visiblement, une bonne maîtrise. Bravo !
Merci  ;)

Citer
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.
Désolé, mais, si, je m'inquiète. Il faut ajuster la fréquence de l'IHM pour qu'on n'ait plus ce phénomène. Tu vas me dire que je m'intéresse plus à la forme qu'au fond (et, ici, tu as raison), mais je n'ai toujours pas vu la fin de la vidéo (c'est vraiment pénible). Sorry…
Je comprends, c'est pénible. Je t'assure que l'on ne voit rien à l'oeil. Ensuite cela ne vient pas de moi, j'ai beau mettre un vilain delay de 5000 dans la loop, cela clignote pareil. Pas contre mes boutons deviennent inutilisables :)

Je viens de faire une nouvelle vidéo. J'ai un peu triché, je l'ai filmé en accéléré et je l'ai ralenti lors de l'export. Cela fait bizarre mais ça clignote beaucoup moins !

https://www.youtube.com/watch?v=Mp-nRcj-NLk (https://www.youtube.com/watch?v=Mp-nRcj-NLk)

Citer
C'est marrant que tu aies pensé, d'emblée, de gérer du multilingue…

Oui, j'ai essayé. Maintenant à voir si on fera ce choix à la compilation (#define...) ou dynamiquement au travers des menus. Si on le fait dynamiquement, le code va bien grossir donc tant que l'on n'a pas fait une première intégration, je ne bouge pas. Le code est actuellement prévu avec des macros pour tous les textes donc on pourra réaliser la modif sans trop de difficulté.

Citer
Je note que tu parles de mémoriser et c'est une excellente chose.
Que doit-on mémoriser quand on a fini la session pour pouvoir la retrouver la prochaine fois ?
Qu'est ce qui est vraiment indispensable ?
Mémorise-t-on des choses périodiquement pour pouvoir repartir suite à coupure courant ? (on appréciera lors d'une démo).
On sera certainement très limité par la taille de l'EPROM.
Pour l'instant je mémorise en RAM et je ne me suis pas encore penché sur l'EEPROM.
Se protéger de la coupure de courant, je n'y avais pas pensé mais est-ce vraiment si pertinent ? Je ne sais pas trop mais ça serait assez facile à faire étant donné que chaque train mémorisé est un objet.
Les données que je garde sont :

Citer
Je note que tu gère les trois derniers trains dynamiquement. Tu verras quand je publierai très prochainement la dernière version de mon gestionnaire sur laquelle je travaille actuellement qu'on a eu la même idée.
Nickel ! En fait j'en garde 10 en mémoire mais l'afficheur permet simplement d'afficher 3 trains (les 3 premiers de la pile). A chaque réception d'un changement pour un train, je positionne ce train en haut de la pile (indice 0). Les autres sont alors tous décalés des un, jusqu'à l'effacement en cas de 11 trains pilotés.

Citer
Concernant les images : très bonne idée d'afficher notre logo au départ (sur ma télé, c'est marqué "Phillips" pendant 10 secondes).
C'était facile à faire et on apporte une petite finition ;)

Citer
Par contre, par la suite, je pense qu'on pourrait gagner une ligne ? (encore la forme)
Oui en effet. Pas de souci sur la forme, je trouve aussi que c'est très important.

Citer
Pour le fond, j'ai vu que tu pensais afficher la tension et l'intensité (avec 2 chiffres après la virgule).
Franchement, ce serait super bien, mais, à mon avis infaisable tel quel.

On n'a pas de capteurs et on ne va pas pouvoir en mettre comme avec une alim analogique (un en série et un en parallèle) en sortie d'alim.
On a mis un pont diviseur en entrée d'alim (sur la tension continue) donc on devrait avoir une image de la tension correcte je pense. Attention à bien mettre des résistances de 1% ou mieux.

Citer
Pour mesurer une tension/intensité DCC, il faut un multimètre haut de gamme ("True RMS") pour que l'indication veuille dire quelque chose.
Ce point là est la grand inconnue, cela fait partie des chosse que l'on doit tester dès réception des cartes. Cela va dépendre de la qualité du signal que l'on sera exploiter de la sortie Sense du L6203. Pas gagné en effet.

Citer
D'autre part, ce qui serait intéressant, ce serait la tension/intensité aux bornes du moteur.  ;)
Parce que, sinon, ça ne veut pas dire grand-chose puisque ce qui circule dans les rails, ce sont des messages DCC.
C'est une autre histoire en effet. On connait la tension secteur, on connait le cran, il faut connaitre les paramètres de CV puis calculer la tension moyenne sortie du décodeur. Ca peut être rigolo en effet mais cela restera je pense assez théorique et on risque de ne pas être compatible avec tous les décodeurs non ?

Citer
Là où on pourrait indiquer quelque chose, c'est en sortie du convertisseur buck puisqu'on est encore en analogique. Là, j'y crois.
Et on pourrait éviter quelques grillages de locos... ::)
Je ne connais pas assez bien le sujet, désolé.

Citer
Enfin, comme l'ESP32 sait quel palier DCC est envoyé dans les rails (parmi 14/28/128) et qu'on a la tension maxi en sortie de convertisseur, on pourrait afficher une tension par une simple règle de trois.
Et, cerise sur le gâteau, on pourrait même tenir compte des CV2 à 6 et, ainsi, afficher quasiment la tension exacte aux bornes du moteur.
Voir, par exemple https://www.opendcc.de/french/information/dcc_cv_f.shtml (https://www.opendcc.de/french/information/dcc_cv_f.shtml)

Nota : la NMRA a mis à jour sa norme électrique DCC (maintenant 9.1) le 7 mars 2020. C'est très récent.
Je pense traduire la doc NMRA des CV. On y apprend, par exemple, que les CV 105 et 106 sont réservés aux utilisateurs… :P
Tout un sujet en effet !!

Encore merci pour tes remarques.

Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Jean-Luc le avril 30, 2020, 03:44:01 pm
Désolé, mais, si, je m'inquiète. Il faut ajuster la fréquence de l'IHM pour qu'on n'ait plus ce phénomène. Tu vas me dire que je m'intéresse plus à la forme qu'au fond (et, ici, tu as raison), mais je n'ai toujours pas vu la fin de la vidéo (c'est vraiment pénible). Sorry…

C'est pas la « Fréquence de l'IHM » Denis :)

C'est l'interférence entre la fréquence de balayage de l'écran (hardware) et la fréquence de prise de vue de la caméra (images par seconde)

Les roues de bagnole tournent à l'envers dans les films, ça fait 100 ans que ça dure, c'est le théorème de shannon/nyquist en action, Céric n'y peut rien sauf si tu lui payes une caméra à quelques milliers d'images/s  8)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 30, 2020, 04:14:28 pm
OK, Jean-Luc.
Dire que tu as réussi à recaser le théorème de Shannon/Nyquist...  ;D

Mais Cédric a trouvé une parade sympa (compliquée, mais efficace). Bravo Cédric. Et sans delay !!

Denis.
PS pour Dominique : j'ai commandé la BOM chez TME (je ne sais pas pourquoi, en ce moment, j'ai du mal à commander trop loin de chez moi  ;))
Total 89,54 €. Je pense que j'aurais tout lundi.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 30, 2020, 05:08:24 pm
D'autre part, ce qui serait intéressant, ce serait la tension/intensité aux bornes du moteur.  ;)
Parce que, sinon, ça ne veut pas dire grand-chose puisque ce qui circule dans les rails, ce sont des messages DCC.

Là où on pourrait indiquer quelque chose, c'est en sortie du convertisseur buck puisqu'on est encore en analogique. Là, j'y crois.
Et on pourrait éviter quelques grillages de locos... ::)
Denis
Denis,

C'est exactement ça (éviter de griller les locos) ; la mesure de tension est celle de l'adaptateur secteur présentée sur le jack d'alim, donc AVANT le convertisseur buck. Cette mesure ne sert qu'à éviter de griller une loco (je sais pourquoi, j'en ai grillé une chez moi  :'()
D'ailleurs il n'y a pas besoin de précision. En principe, si on est en mode PWM, à 100% le montage délivre toute la tension d'entrée et si cette tension est supérieure à 12V (en N et en HO sans doute, je ne sais pas pour les autres formats) on grille le moteur. Donc le soft au démarrage bloquera la sortie puissance si on est en PWM (en DCC c'est le décodeur qui régule la tension appliquée au moteur), avec un message d'excuse.
L'utilisateur sera obligé d'utiliser l'adaptateur secteur qui convient à son parc et son mode de fonctionnement.
Nous n'avons pas envisagé de mesurer la tension coté loco, à quoi cela servirait-il ?
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 30, 2020, 05:13:12 pm
Je ne vois pas le 10 µF sur la broche ENABLE ? Ni dans la BOM ?

Si elle est présente : C9.
Mais le schéma que j'ai publié n'était pas le bon. j'ai corrigé.
Par contre je l'ai oubliée dans la BOM.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le avril 30, 2020, 05:25:31 pm

PS pour Dominique : j'ai commandé la BOM chez TME (je ne sais pas pourquoi, en ce moment, j'ai du mal à commander trop loin de chez moi  ;))
Total 89,54 €. Je pense que j'aurais tout lundi.
Tu vas être le premier, mais c'est cher !
Moi j'ai encore un bout de temps à attendre.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le avril 30, 2020, 06:59:37 pm
Bien sûr, c'est cher... Mais c'est quand même abordable. Il ne faut pas exagérer. Et c'est européen.
Par ailleurs, tu voulais que je fasse des tests  ;)

OK Pour le 10µF. Mais c'était normal qu'on ne le voie pas.

Mesure de tension :

Pour moi, c'est important.
1°) Pour savoir quelle est la tension max (fonction de l'échelle) et donc, ça sert. Bon, avant ou après, pas de problème. Il suffit qu'on mesure bien une tension analogique.
2°) Mesurer la tension aux bornes du moteur n'est pas possible, évidemment.
Mais comme la tension à cet endroit correspond à la vitesse "réelle" de la loco, ce serait intéressant de la connaître.

Ma proposition :


Supposons qu'on ne s'intéresse pas aux CV 2 à 6 (dans un premier temps) : Le cran de vitesse correspond linéairement à la vitesse.
En N, si la tension max vaut 12V, quand on va avoir 6V, c'est que la loco va à la moitié de la vitesse.  :P

Dans un premier temps, on fait tourner UNE LOCO et on la chronomètre. On va finir au bout d'un "certain temps" par avoir une table qui va donner cran de vitesse => vitesse réelle POUR CETTE LOCO.
En la multipliant par l'échelle, on aura la vitesse réelle de la loco.
Et c'est d'ailleurs là qu'on va trouver qu'au cran maximal, on dépasse allègrement la vitesse maximale de la vraie loco. Un grand classique.

Voici le schéma donné dans OpenDCC :

(http://www.locoduino.org/IMG/png/cv2-6.png)

En agissant sur le CV5, on va corriger le tir et la vitesse maximale de la maquette sera la vitesse maximale de la vraie loco.
Donc, à ce moment, cran de vitesse => vitesse à l'échelle de la loco. Et on pourra l'afficher en km/h. C'est quand même sympa.

Puis on voit sur le schéma qu'au lieu d'avoir une seule droite pour aller de zéro au max, on peut avoir un point intermédiaire avec le CV6.
Mathématiquement, c'est à peine plus compliqué. Il y a seulement 2 droites ! J'ai vu pire dans mon gestionnaire...

Donc, je propose d'afficher les km/h via les crans de vitesse.
Normalement, via les CV, on tient compte de la FCEM et donc des pentes et de la charge du train. Ce qui veut dire que c'est le DCC qui "garantit" qu'on peut faire un lien plausible entre les crans de vitesse et la vitesse du train.

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mai 02, 2020, 07:18:46 pm
Bonsoir,

Je suis en train de décortiquer la norme DCC pour les CV qui s'occupent de la vitesse.
On constate qu'il y a des choses sur internet, parfois contradictoires  :( et, en particulier très très peu de choses en français (comme d'hab) sur les CV 67 à 94.
La référence, à mon avis imbattable (pour l'instant), c'est Decoder Pro's de JMRI.

A propos, comment on gère les CV dans LaBox ? Avec la souris ?

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 02, 2020, 07:52:54 pm
Denis,

Le moyen le plus exhaustif de gérer les CVs c’est avec Decoder Pro de JMRI, en liaison wifi transparente avec DCCpp. Mais ce n’est peut-être pas le moyen le plus simple pour beaucoup de modélistes. Car il faut installer JMRI et s’en servir !


Sachant que les interfaces existent dans La Box pour gérer les CVs de façon directe par un programme interne, on a donc 2 autres possibilités :
- écrire une programme interne sur ESP32 utilisant l’HMI comme interface utilisateur
- développer une configurateur de CVs externe, avec interface Can ou Wifi

Maintenant, comme on n’a pas vraiment besoin de grand chose en général ( je ne pense pas qu’il y ait beaucoup de modélistes qui s’affairent sur les CVs 2 à 6 et 67 a 94), il y a quelques possibilités d’utiliser l’interface de Withrottle sans changement, combinée avec les boutons de La Box pour récupérer l’adresse d’une loco et pour programmer son adresse (changer l’adresse 3 quand elle sort de chez le marchand).

Je reste toujours un inconditionnel de la simplicité pour adresser le plus possible de modélistes en évitant les cas extrêmes pour lesquels il s’agit d’un autre projet qui risque de ne jamais voir le jour  ;D
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 02, 2020, 08:01:18 pm

Dans un premier temps, on fait tourner UNE LOCO et on la chronomètre. On va finir au bout d'un "certain temps" par avoir une table qui va donner cran de vitesse => vitesse réelle POUR CETTE LOCO.


Tu sais que c’est ce que je fais chez moi en étalonnant certains crans (15,30,60,90 par exemple) pour qu’ils correspondent au vitesses réelles. On n’a pas besoin de tout étalonner pour avoir le plaisir de jouer au train. Mais pour cela il faut quelques capteurs sur le réseau et ramener les événements à la centrale.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mai 04, 2020, 09:02:21 am
Bonjour Dominique,

Tu as raison : décortiquer la norme DCC et ses 1024 (!!) numéros de CV n'a rien à faire dans ce fil. C'est hors sujet ici.
Quand j'aurais un peu de temps, je créerai un fil spécifique pour ça.

Le problème de la vitesse réelle est fondamental pour moi puisque, à terme, mes petits trains virtuels doivent être en phase avec les trains sur le réseau. J'en suis loin, mais c'est une autre histoire. ;D

Denis
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 04, 2020, 11:08:35 am
Le problème de la vitesse réelle est fondamental pour moi puisque, à terme, mes petits trains virtuels doivent être en phase avec les trains sur le réseau. J'en suis loin, mais c'est une autre histoire. ;D
Bonjour Denis,

Vouloir une bijection parfaite entre la valeur des crans (128 évidemment) et la vitesse réelle est, à mon avis, un coquetterie peu utile.

D’ailleurs comment fais-tu quand la vitesse du train dépasse 126 km/h ?

Je comprend que ton gestionnaire calcule tout en vitesse réelle et qu’il ne sait peut-être pas rattraper les écarts de position à chaque transition de canton. Pourtant c’est classique dans les gestionnaires, d’autant que chaque detection te permet de recaler les pendules : quand le gestionnaire est en avance, il attend le train, quand il est en retard, il rattrape.
C’est comme ton GPS en voiture quand tu traverses un tunnel !!

Je dirai que si c’est aussi fondamentale alors tu as une analyse incomplète des événements dans ton gestionnaire.

Mais je te fais confiance ... :D
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 05, 2020, 05:52:15 pm
Les PCBs sont arrivées :

(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3099;image)

Je porterai les envois demain à La Poste, probablement avec des timbres en Francs !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mai 05, 2020, 06:07:45 pm
Moi aussi, TME m'a livré. ;D
TME : commandé jeudi soir et arrivé le mardi. Avec un WE, et en ce moment, c'est très honnête comme délai.

C'est cher, mais c'est européen* et c'est très rapide.
Denis
* (je n'ai aucune illusion : les composants sont chinois)  ;D
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 05, 2020, 06:11:42 pm
Moi je n'ai reçu, pour le moment que les capuchons des poussoirs et les ESP32.

Ca va être long.
Heureusement j'ai le proto cablé à la main  ;)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 09, 2020, 10:24:02 pm
Premier montage de la centrale... et elle fonctionne bien avec Withrottle sur mon iPhone !

Je vais ajouter une 2ème résistance de 0,5Ω (R14) en parallelle de la première (R13). Avec un gain de 3 dans l'ampli op, l'entrée analogique (IO36) délivre une mesure de 1,066 mA par pas. Donc jusqu'à 4,37 A maximum  :o
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 09, 2020, 10:41:13 pm
Avec Withrottle à la commande (on ne voit pas le petit autorail qui tourne en même temps)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 24, 2020, 12:29:17 pm
Les premiers circuits imprimés sont montés, après la découverte d'une erreur de 2,54mm dans l'espacement entre les 2 rangées de broches de l'ESP32  :-\ Chacun y est allé avec sa solution, mais il faudra donc refaire le circuit imprimé prochainement. Nous avons décidé d'attendre différents tests qui peuvent entrainer d'autres modifications.

Coté logiciel, les choses se passent plutôt bien  ;D

La bibliothèque DCCpp change de nom et s'appelle "LaBox" pour le projet. A terme ces 2 bibliothèques seront alignées et n'en feront plus qu'une. Je vais dtailler un peu plus loin.
Une autre bibliothèque est en train de voir le jour : "HMI" qui va produire l'interface utilisateur sur l'écran OLED en conjonction avec les 3 boutons.
L'ensemble DCCpp + HMI sera intégré à terme, dans LaBox.

Nous avons eu une petite réunion la semaine dernière, en visio comme il se doit (et on n'habite pas les uns à coté des autres), et en voici les principaux éléments à retenir.

DCCpp
On pourra monter jusqu'à 41 registres dans DCCpp, le registre 0 est réservé pour toutes les fonctions ponctuelles et les autres pour les fonctions permanentes comme les fonctions de vitesse qui sont répétées en permanence ce qui évite de perdre des ordres sur coupure.
La classe Locomotives affecte un registre libre à chaque nouvelle locomotive pilotée. Une version pourrait supporter un registre pour la vitesse et un autre pour les fonctions pour chaque locomotive évitant ainsi les problèmes de perte d’activation des fonctions lors d’une coupure de courant fugitive.
La classe Throttle est le moyen de transmettre les ordres à DCCpp. Chaque Throttle peut avoir un MessageConverter associé qui réalise la traduction des messages reçus vers DCCpp, que ce soit en appel direct de fonctions DCCpp ou en traduction vers les commandes DCCpp texte habituelles. Lorsqu’aucun MessageConverter n’est spécifié, alors les commandes reçues doivent être au format DCCpp et seront envoyées directement.

L’ESP32 dispose de 4 Mo de mémoire flash. Le programme de test avec Withrottle et HMI occupe 53% de la place de l’espace de stockage du programme. Si on était amené à stocker des pages web, les 4 Mo seraient utilisés à cet effet sans impact sur les espaces programmes. La configuration de LaBox via un Webadmin nous semble la solution à retenir. Elle devrait se trouver dans cet espace si l’écriture dynamique y est possible.

Programmation de CV et détection de court-circuit

La lecture du courant dans l’ESP permet d’avoir à 4 A une tension sur l’entrée de l’ESP < à 3.3V donc l'ESP est protégé et on est en capacité de détecter un court-circuit.
On détecte bien les fronts de 60 mA en réponse à la lecture de CV. Cependant, la fonction n’est pas encore opérationnelle. La recherche d'une bonne gestion du convertisseur analogique-digital et de l'instant précis où apparait cette impulsion de 60mA pendant 6mS est encore à l'étude.

Du côté des nouvelles fonctions, des concepts présentés semblent intéressants


Un schéma provisoire d'architecture du logiciel de LaBox est ci-dessous




Titre: Re : projet centrale wifi DCC++ Can
Posté par: Jean-Luc le mai 24, 2020, 01:44:44 pm
Le package de l’ESP32 est un package d’un bibliothèque « contribuée » par la communauté des makers ?

Parce que pour Eagle je ne sais pas mais je peux vous dire que les bibliothèques KiCad sont truffées d’erreurs, c’est la fête du slip. Tout doit être vérifié, aucune confiance ne doit être accordée.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 24, 2020, 01:58:26 pm
Parce que pour Eagle je ne sais pas mais je peux vous dire que les bibliothèques KiCad sont truffées d’erreurs, c’est la fête du slip. Tout doit être vérifié, aucune confiance ne doit être accordée.

Tu as raison, Msport a du résumer l’ESP32 à 2 rangées de 19 broches !
Le résultat est que ça marche bien, à l’espacement près !
Comme quoi on vérifie soigneusement et on ne voit pas la grosse erreur au milieu !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mai 24, 2020, 02:14:49 pm
Bonjour à tous,

Excellentes nouvelles !  ;D

Je serais pour scinder en deux projets :

1°) LaBox pour les débutants (version "TrainInBox")

DCCpp+HMI+modification possible du CV1 (c'est un minimum).

Je ne suis pas certain, dans cette version, qu'il y ait besoin d'un connecteur JP1 (pour le prochain CI)
Si on veut faire un joueur de scénario, même interne, même minimal, il va falloir pouvoir commander quelques aiguilles et donc avoir un bus CAN.
Ou alors, on commande les aiguilles de l'extérieur (boutons sur un TCO physique), indépendant de LaBox. Je pense que c'est la solution à retenir.
Et comme scénario : une navette, puisque ça n'utilise pas les aiguilles.
Obligation du Wifi pour la Throttle.
Prévoir de brancher quand même une MultiMaus filaire ?

2°) Les essais de fonctions plus sophistiquées (développeurs)
Là, il faut un bus CAN (aiguilles, signaux et logiciel de gestion) et les développements de Christophe.
Pour WebAdmin, je me demande si ça ne pourrait pas être déjà sur la version débutants.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 24, 2020, 03:13:31 pm
Pour compléter, voici quelques images de l'HMI qui rend très bien sur l'écran OLED  ;D 8)

On y voit notamment l'adresse IP de connexion Wifi (nécessaire au moins la première fois que l'on se connecte avec un smartphone - ici j'utilise Withrottle sur iPhone),
le bon lancement du DCC confirmé par les leds situées juste à coté du connecteur de sortie, la représentation graphique de la vitesse et de la fonction "lumière", ainsi que la consommation en courant (là la loco est à l'arrêt) et la tension de l'alim (à titre indicatif).
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 24, 2020, 03:22:07 pm
Je serais pour scinder en deux projets :

1°) LaBox pour les débutants (version "TrainInBox")

DCCpp+HMI+modification possible du CV1 (c'est un minimum).

On est complètement d'accord  :D
mais on essaye de voir un peu plus loin pour définir la façon de configurer simplement cette belle petite machine qui a probablement plein de possibilités !

C'est certain qu'il y aura une Box pour débutant, même avec du PWM pour permettre à un modéliste qui souhaite numériser une de ses locos, de s'en servir immédiatement après l'opération.

Citer
Je ne suis pas certain, dans cette version, qu'il y ait besoin d'un connecteur JP1 (pour le prochain CI)
L'idée pour le moment est de déplacer ce connecteur sous l'ESP32, le rendant accessible par des connecteurs coudés à 90°.

Citer
Si on veut faire un joueur de scénario, même interne, même minimal, il va falloir pouvoir commander quelques aiguilles et donc avoir un bus CAN.
J'ai testé le Can avec un satellite.

Citer
Ou alors, on commande les aiguilles de l'extérieur (boutons sur un TCO physique), indépendant de LaBox. Je pense que c'est la solution à retenir.
Et comme scénario : une navette, puisque ça n'utilise pas les aiguilles.
Obligation du Wifi pour la Throttle.

Prévoir de brancher quand même une MultiMaus filaire ?

2°) Les essais de fonctions plus sophistiquées (développeurs)
Là, il faut un bus CAN (aiguilles, signaux et logiciel de gestion) et les développements de Christophe.
Pour WebAdmin, je me demande si ça ne pourrait pas être déjà sur la version débutants.

Bonnes suggestions
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le mai 27, 2020, 06:53:47 pm
Bonjour,

Très bel affichage. (j'attends toujours que le mien arrive, d'ailleurs)

Je me pose plusieurs questions :

1°) Cette centrale DCC est bien indépendante du Wifi de la Box de l'opérateur ? C'est important.
D'autant qu'il ne faut pas oublier que certains modélistes ont un réseau au grenier ou à la cave et que la réception Wifi de la box opérateur peut y être très mauvaise.

2°) Comment calcule-t-on l'intensité affichée ? Je ne suis pas certain que ce soit si facile que cela.

3°) Je pense qu'il faut afficher, à chaque démarrage, "LaBox Locoduino.org" pendant quelques secondes, par principe, puis plus jamais (ça fait perdre une ligne et on n'en a pas tant que ça)

4°) Le réseau TrainInBox a 3 aiguilles. Je pense qu'il faut développer un mini-CAN pour commander un TCO physique

Première possibilité :
Commande directe sur un TCO physique par 3 inter. Simple et efficace. Indépendant de LaBox.

Deuxième possibilité :
Sans développer pour l'instant un CAN version XXL super sophistiquée, on fait un CAN capable de gérer mettons 5 boutons et 15 LED

L'interface CAN/TCO est donc hyper simple.

L'interface aiguille aussi : on reçoit seulement 2 ordres : TD et DV et réémet 2 ordres : allumer la LED TD ou DV sur le TCO pour cette aiguille.
Pour 5 aiguilles, ça fait 10 LED au TCO + 5 LED pour les occupations de zone.

On a maintenant la possibilité de commander l'aiguille de 2 façons : l'inter et la throttle. C'est "classe" comme on dit maintenant.
Évidemment, l'inter ne commande plus l'aiguille, mais donne l'ordre au CAN.

Dans LaBox, on peut générer un scénario qui, cette fois, peut agir sur des aiguilles.
Un scénario très simple : par exemple, une gare terminus à 2 voies et, de l'autre côté, une gare terminus simple.
Et le train navette change de voie de gare à chaque passage du côté où il y en a deux.

Ce que je vois comme avantage à ce mini CAN, c'est que, petit à petit, on accrédite l'idée qu'on peut commander les aiguilles hors DCC.
Et on n'a pas besoin d'une V2 pour ça.
On accrédite aussi une autre idée : dans un TCO, il peut n'en sortir qu'un seul câble. Ce n'est pas forcément un magma de fils.

Enfin, pour donner une idée du prix, un mail que j'ai reçu parce que je suis abonné à "Model Railroader" :
http://link.mail.trainsmail.com/YesConnect/HtmlMessagePreview?Q-XBCrtKbry6lZaoSGsq4MFGn_Vzf5CpVSEaL0sjdIQ=.enc&msgVersion=web (http://link.mail.trainsmail.com/YesConnect/HtmlMessagePreview?Q-XBCrtKbry6lZaoSGsq4MFGn_Vzf5CpVSEaL0sjdIQ=.enc&msgVersion=web)
Si vous suivez le lien, vous verrez qu'on arrive, pour des CI quand même assez simples, à des prix assez conséquents ($59 et $119)
Les CI sont très joli, je ne le nie pas, mais, bon ...

Denis


Titre: Re : projet centrale wifi DCC++ Can
Posté par: Souris verte le mai 27, 2020, 09:31:12 pm
Bonsoir,

A vouloir en ajouter toujours un peu plus, cela risque de finir comme les satellites v2....
Il faut rester humble et ne pas trop s’écarter de la cible.

Le projet, c’est une base stable fonctionnelle, utilisable en wifi ou série. La suite serait modulaire et développée plus ou moins en fonction des aspirations (MQTT, TCO balaise...) effectivement le CAN reste un choix mûri.

Le mini TCO me semble juste un peu tard ou un peu trop tôt...

Yannick
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le mai 28, 2020, 02:39:23 pm
Bonsoir,

A vouloir en ajouter toujours un peu plus, cela risque de finir comme les satellites v2....
Il faut rester humble et ne pas trop s’écarter de la cible.

Le projet, c’est une base stable fonctionnelle, utilisable en wifi ou série. La suite serait modulaire et développée plus ou moins en fonction des aspirations (MQTT, TCO balaise...) effectivement le CAN reste un choix mûri.

Le mini TCO me semble juste un peu tard ou un peu trop tôt...

Yannick

Merci Yannick pour cette mise au point.

Nous la partageons aussi car c’est une base stable que nous visons donc pour des usages de base comme tu les cites, mais aussi pour des développements futurs.

Pour répondre à Denis sur la programmation d’adresse, ce sera mis en œuvre évidemment : une adresse DCC se programme dans le CV 1 si cette adresse est « courte » (entre 1 et 127). Pour les adresses « longues » (au delà de 128), l’adresse est découpée en 2 parties stockées dans les CVs 17 et 18. Pour différencier les 2 types d’adresse le bit 5 du CV29 est utilisé.

Depuis pas mal de temps, Thierry a intégré la lecture de l’adresse DCC, courte ou longue. C’est ce que j’essaye de mettre au point sur l’ESP32 (ça marche sur l’ATMega 328 et 2560).
De plus, le fait de n’avoir pas de voie de programmation dédiée n’est pas un problème étant donné la richesse des commandes de DCCpp. On peut s’adapter.

Je dois dire donc qu’il est prématuré de supputer divers types de scenarii de pilotage interne, via Can ou gestionnaire externe. Nous nous concentrons d’abord sur l’essentiel.

Si Denis veut une version qui permet de commander des trains via Can (a partir de son gestionnaire), alors on la fera avec plaisir.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le juin 10, 2020, 06:35:12 pm
Un progrès significatif est intervenu aujourd'hui avec la reconnaissance d'adresse DCC d'une loco.

La séquence d'images ci-dessous montre :
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le juin 10, 2020, 06:59:08 pm
Et en plus, on ne risque plus sa vie en manipulant 490,5 Volts !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le juin 11, 2020, 08:22:56 am
Magnifique !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le juillet 03, 2020, 03:41:10 pm
La phase que les électroniciens et développeurs n'aiment pas ! La mise en coffret.
Ci-joint la version à afficheur vertical. (torticolis assuré)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le juillet 05, 2020, 11:28:33 am
La version avec afficheur horizontal.

En photo avec Engine Driver, opérationnel sur la loco 36.

Actuellement, les fonctions d' Engine Driver n'ont pas encore été implémentées et un seul smartphone Android peut commander La Box. Mais ça avance.
La version WiThrottle (Apple) est certainement plus avancée mais je suis sous W10 et Android.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le juillet 05, 2020, 12:12:46 pm
C’est splendide  ;D ;D

J’ai un peu de boulot pour implémenter les fonctions et corriger la mesure de courant affichée, mais quelques jours d’évasion à la montagne vont entraver cet élan... pas longtemps  8)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le août 28, 2020, 04:36:32 pm
Bonjour à tous

On pourrait croire de loin que le projet végète, voire qu'il stagne. Pourtant il n'en est rien. Il bouge encore et n'a pas dit son dernier mot.

Du côté logiciel, côté que je partage avec Cédric et Dominique, j'ai commencer à faire progresser Labox pour y ajouter le HMI de Cédric. Pour rendre le projet plus ouvert, j'ai intercalé une interface entre le HMI et la partie DCC++/Wifi de Labox. Le but est de pouvoir remplacer l'écran proposé par défaut par un autre plus simple, donc moins cher, ou au contraire plus évolué, plus cher mais plus grand, plus beau, plus... tout !
En ces temps troublés, et faute d'accéder à mon labo d'électronique encore en cartons après mon déménagement précipité de Juin (et aussi sans internet viable...) ,  je ne peux pas tester mes modifications sans passer par mon simulateur d'Arduino sur lequel je tente de greffer un écran pilotable par la bibliothèque Adafruit_GFX, base de celle créée pour le petit écran de Labox. J'ai des résultats, mais c'est un peu laborieux. Grâce à Dominique, je vais peut être avoir une carte Labox équipée à disposition pour ces tests. Ça devrait aider.

Toujours au niveau logiciel, les recherches de Dominique sur la lecture des CVs ont donné des résultats et l'on peut maintenant faire fonctionner la programmation des locos sur un ESP32. Dans un autre fil, il y a aussi des recherches sur le même thème dans DCCpp et DcDccNanoController mais sur des contrôleurs AVR. Ces modifications seront reportées sur le mode AVR de Labox. Pour rappel, la partie DCC de Labox, c'est DCCpp. Lorsque Labox sera fiabilisée, les modifications apportées seront aussi reportées sur DCCpp, à la fois sur sa partie ESP32 et AVR.

Dominique planche maintenant sur la lecture de la consommation de courant, et accessoirement sur la détection de court-circuit, qui ne donnent pas de résultats assez fiables pour le moment. Et de mon côté je vais continuer à intégrer le HMI pour qu'au final on puisse tous travailler sur la même base logicielle.

Restez connectés !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le août 28, 2020, 07:35:58 pm
Thierry, n'hésite pas à me dire sur quelle partie je dois continuer.
Il reste la sauvegarde par fichier.

A+
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le août 29, 2020, 09:41:13 pm
En plus de la lecture de la consommation de courant (courante), il y a la lecture de la tension d’alim qui affiche 12V invariablement  : :P

A ce propos, je propose que chaque testeur (nous) diffuse un rapport de bug normalisé (modèle à définir: numéro, date, initiales du testeur, description).

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le août 30, 2020, 11:11:03 am
En fait l’idéal serait de mettre en place un bug tracker comme Redmine (mon préféré) ou Bugzilla.
Cela permet d’identifier les bugs, le reste a faire, et d’affecter le dev à un développeur.

Qu’en pensez-vous ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le août 30, 2020, 11:42:20 am
Pas d'avis n'étant pas impliqué dans le développement mais pour lequel ce peut être utile.
Le projet a d'autres volets car on est encore en amont du bug reporting :
- son interaction avec WiThrottle et EngineDriver,
- son interaction avec le hardware (il est nécessaire de rendre la référence au display moins dispersée pour permettre une évolution future)

Pour le 12V :
Il semble que ce que j’ai constaté aussi (GPIO0 HIGH) soit un bug du bootloader non corrigé :
https://www.esp32.com/viewtopic.php?t=2205
Et qu’il peut être évité avec :
REG_WRITE(GPIO_FUNC0_OUT_SEL_CFG_REG, SIG_GPIO_OUT_IDX);


Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le août 30, 2020, 01:35:17 pm
Pour les bugs et les demandes d'évolution, le mécanisme existe dans GitHub. Il suffit de déclarer un 'Issue' dans le projet Labox.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le août 30, 2020, 05:00:11 pm
Pour les bugs et les demandes d'évolution, le mécanisme existe dans GitHub. Il suffit de déclarer un 'Issue' dans le projet Labox.
Tout à fait d'accord !
D'ailleurs Michel a posté 2 issues, aussitôt dit aussitôt fait !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le août 30, 2020, 05:02:12 pm
J'en profite pour diffuser le dernier schéma à jour, le 08h, avec l'affectation des pins de l'ESP32, ce qui rend plus facile la lecture des liaisons avec les autres composants.

(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3357;image)

Michel, peux-tu vérifier, notamment la résistance R4 qui fixent le gain de l'ampli op
Les valeurs des résistances de l’ampli op sont actuellement :

R4=3,3K, R3 = 10K

VS = (1 + R3/R4) VE
R3 = 10K
R4 = 3,3K
donc R3/R4 = 3
VS = 4 VE (gain de 4)

On remplacera le LM358 par un MCP6002

Je publie aussi une liste des composants à jour..
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le août 30, 2020, 05:22:11 pm
Pour le 12V :
Il semble que ce que j’ai constaté aussi (GPIO0 HIGH) soit un bug du bootloader non corrigé :
https://www.esp32.com/viewtopic.php?t=2205
Et qu’il peut être évité avec :
REG_WRITE(GPIO_FUNC0_OUT_SEL_CFG_REG, SIG_GPIO_OUT_IDX);

Lu sur le site d'Espressif : "Sometimes to program ESP32 via serial you must keep GPIO0 LOW during the programming process"
https://github.com/espressif/arduino-esp32 (https://github.com/espressif/arduino-esp32)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Pyk35 le août 30, 2020, 08:39:34 pm
Dominique, la détection de l’intensité de court-circuit fonctionne ?
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le août 30, 2020, 10:14:11 pm
R4=3,3K, R3 = 10K

VS = (1 + R3/R4) VE
R3 = 10K
R4 = 3,3K
donc R3/R4 = 3
VS = 4 VE (gain de 4)

Avec une résistance équivalente de 0.25 ohm et ce gain de 4, on a la valeur classique de détection de la BaseStation de 1 V / A ( Ok pour ~ 5A permanent en limite)

On peut également utiliser 10K / 10K, G=2 avec une résistance de 0.5 ohm 3W ( Ok pour 2,5A permanent en limite)
Titre: Re : Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le août 30, 2020, 10:22:27 pm
Pour le 12V :
Il semble que ce que j’ai constaté aussi (GPIO0 HIGH) soit un bug du bootloader non corrigé :
https://www.esp32.com/viewtopic.php?t=2205
Et qu’il peut être évité avec :
REG_WRITE(GPIO_FUNC0_OUT_SEL_CFG_REG, SIG_GPIO_OUT_IDX);

Lu sur le site d'Espressif : "Sometimes to program ESP32 via serial you must keep GPIO0 LOW during the programming process"
https://github.com/espressif/arduino-esp32 (https://github.com/espressif/arduino-esp32)

La formule magique est à inclure dans le setup, donc n'intervient pas dans la phase programmation (qui suivant la direction du vent nécessite ou non d'appuyer et relâcher BOOT ou ENABLE pour se lancer)
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le août 30, 2020, 11:58:14 pm
Dominique, la détection de l’intensité de court-circuit fonctionne ?

OUI Cédric,

Dans ma version, je détecte les court-circuits dans la loop de mon programme, sans passer par DCCpp.
C'est la fonction readCurrent, ligne 185 : il n'y a pas de filtrage en cas de court-circuit, c'est plus rapide !
// A voir ce que l'on fait de cette fonction par rapport à celle de la HMI
void readCurrent() {
  float c=0.0;

// TODO TODO TODO TODO
// Short-circuit détection
  if (analogRead(PIN_CURRENT_MES) > 3000) {          // 2,41A ??? A définir, c'est juste pour mettre la condition
    shortCircuit(); 
    }
  // Filtre sur la mesure de courant
  for(int j=0;j<300;j++){
     c=(analogRead(PIN_CURRENT_MES)*0.2)+(c*0.8);
  }
  current = c;
  if (current > topCurrent) {
    topCurrent = current;
    Serial.print("topCourant ");Serial.println(topCurrent);
  }
}
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le août 31, 2020, 04:19:50 pm
Attention aux afficheurs OLED !!!

J'ai acheté 2 écrans ici et les pins VCC et GND sont inversées  :-[ :( >:(
https://www.ebay.fr/itm/0-96-I2C-IIC-Serial-128-64-OLED-LCD-Screen-LED-Display-Module-for-Arduino-fr/123074727750? (https://www.ebay.fr/itm/0-96-I2C-IIC-Serial-128-64-OLED-LCD-Screen-LED-Display-Module-for-Arduino-fr/123074727750?)

D'autres ont les pins SDA et SCL inversées !!

Je regarde si ce cas est isolé ou non. Sinon il faudra prévoir une inversion des fils par straps sur le PCB.
Ou restreindre les choix des offres.


Avant que je m'en aperçoive, il a bien chauffé mais n'est pas mort !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le août 31, 2020, 04:57:14 pm
J'ai déposé un prototype de La Box chez Thierry cet après-midi, pour lui permettre de tester in situ.

J'atteste qu'il a vraiment beaucoup d'occupations, en plus de son boulot et sa famille, avec sa nouvelle belle maison où il y a des travaux de finition, comme toujours :P).

Mais il est très confiant quand aux qualités de cette Box à venir. Nous allons donc être patients et respectueux.

A part nous trois (Michel, Thierry et moi) : Marcel, Denis, Christophe : avez-vous fait des tests ?



Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le septembre 01, 2020, 10:57:30 am
Avant que je m'en aperçoive, il a bien chauffé mais n'est pas mort !

Expérience vécue : le boitier s'en sort avec une cloque ! On note.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le septembre 05, 2020, 06:33:24 pm
Bonjour à tous.

Suite à la visite de Dominique et grâce à sa centrale, j'ai suffisamment avancé sur l'intégration du HMI de Cédric dans Labox pour en pousser un premier jet sur Github aujourd'hui. Voici les différentes modifications apportées au code:

- Isolement HMI/Reste du code
L'interface utilisateur (le HMI) qui a été ajoutée au codage de Dominique pour WiThrottle, est aussi ajoutée à Labox pour donner la possibilité de signaler à l'utilisateur ce qu'il se passe sur la centrale via un écran. La présence de boutons permet aussi de faire des réglages, ou de changer le type d'affichage à l'aide d'un menu. Pour éviter de retrouver du code HMI au milieu de DCCpp ou des Throttles, j'ai décidé d'ajouter une interface qui déconnecte complètement les deux parties. Une nouvelle classe HmiInterface virtuelle pure a été définie côté DCCpp. Cette classe est dite pure parce qu'elle a au moins une fonction dont elle ne donne pas d'implémentation. La classe qui décidera de dériver d'elle, comme ici 'hmi', devra fournir obligatoirement ces fonctions. Elles sont peu nombreuses, au nombre de deux seulement : HmiInterfaceLoop() qui va traiter les événements envoyés par Labox, et HmiInterfaceRefreshDrawing() qui rafraîchira l'écran pour tenir compte des derniers événements. J'ai bien sûr codé la version de hmi dans HmiInterface.cpp. Grâce à cette interface, on pourrait tout à fait remplacer l'écran actuel par un écran LCD 4 lignes par exemple, sans toucher au reste de Labox !

- Gestion du multi-cœur
Maintenant que la partie DCCpp de Labox s'exécute sur le second cœur de l'ESP32, il faut s'assurer que la partie HMI s'exécute sur le bon cœur, sinon des risques de collisions de données sont possibles. Donc le numéro du cœur est enregistré pendant le begin de Hmi lancé par le setup() et qui s'exécute sur le même cœur que le fichier ino. La plupart des fonctions de Hmi ont étés sécurisées pour qu'elles sortent tout de suite si l'exécution n'est pas sur le bon cœur... Pour bien isoler le fonctionnement des deux cœurs, un CircularBuffer (bien amélioré au passage) a été implémenté pour discuter entre les deux. Ce buffer circulaire va recevoir les événements envoyés par les fonctions DCCpp (cœur 1), et réceptionnées par le HmiInterfaceLoop() (cœur 0) dont j'ai parlé plus tôt pour mettre à jour l'écran.

- Pour éviter les problèmes de nommage, j'ai renommé toutes les macros DEBUG de Hmi en HMIDEBUG...

- Tout comme le programme de Dominique, maintenant la première Throttle qui se connecte provoque l'allumage de la tension DCC. Cela ne se reproduit plus ensuite, même si toutes les throttles se déconnectent, puis se reconnectent. Je rappelle au passage que toutes les Throttles compatibles WiThrottle (comme WiThrottle sur iPhone ou EngineDriver sous Android) ou Z21 (comme les applis de Roco et Fleischmann toujours sous Android) fonctionnent. Que la centrale Labox est câblée par défaut (dans labox.ino) pour accepter trois connexions WiThrottle/EngineDriver plus trois connexions Z21. Que chaque connexion peut piloter plusieurs locos... On est donc très ouverts !

- Cette version intègre également les modifications de Dominique pour la lecture/écriture de CVs sur ESP32. A tester !


Que reste t-il à faire ?

Le tableau tab_trains de Hmi me semble faire double usage avec les Locomotives de Labox qui contiennent les mêmes données et sont mise à jour par les connexions successives de Throttles... A creuser.

Les fonctions semblent bizzarement gérées dans EngineDriver : par exemple l'allumage des feux est immédiatement éteint ! Tout se passe comme si l'allumage était déclaré comme une fonction transitoire, comme un klaxon sur une loco sonore, et pas comme une fonction qui reste dans l'état demandé... En Z21, pas de problème.

La sauvegarde des données dans un fichier json sur l'ESP32 est toujours à faire...

Il y a encore des ajustements à faire sur le Hmi, par exemple lorsque l'on veut lire/écrire des CVs.

Pour les développeurs, travailler en parallèle dans la librairie Labox et l'IDE est tout à fait possible facilement. Il suffit d'avoir ouvert simultanément l'IDE, et un éditeur multi fichiers comme Visual Studio Code ou Visual Studio Community. C'est également possible avec des éditeurs de texte plus basiques comme SublimeText ou Notepad++, mais Visual offre une navigation facilitée dans les sources, un contrôle en temps réel de ce qui est tapé et beaucoup d'autres facilités, comme l'intégration de Github. Quel que soit l'éditeur, il suffit de modifier ce que l'on veut, de tout sauvegarder, puis d'aller dans l'IDE et de lancer la compilation.

Voilà. J'espère des retours pour corriger les problèmes et améliorer le traitement des Throttles et des locos.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le septembre 05, 2020, 06:48:55 pm
Super ! Énorme travail !
Voilà du pain sur la planche aux Contamines  :D
Je teste asap  ;)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le septembre 06, 2020, 03:40:13 pm
Premiers tests de la version de la bibliothèque LaBox version 0.6 (version indiquée ligne 61 du sketch LaBox.ino) du 5 Septembre 2020. Elle se trouve sur le git Locoduino :
https://github.com/Locoduino/LaBox (https://github.com/Locoduino/LaBox)


Mais partir de 1.0.0 me semblerait une bonne chose.

Après installation de la bibliothèque (transfert à la main dans le dossier "libraries", les exemples n'apparaissent pas encore dans le menu exemples de l'IDE. Faire "ouvrir Exemples/LaBox/LaBox.ino". Puis choisir la carte ESP32 Dev Module.

A la première compilation et le premier téléversement, il n'y a aucune erreur.

Attention il y a une modification du sketch pour s'adapter à la carte en cours de développement :
A la ligne 91, il faut changer les numéros des pins :
DCCpp::beginMain(UNDEFINED_PIN, 33, 32, 36);
Car la pin 33=DCC(Dir), la pin 32=pwm/enable, la pin 36-SVP= current sense.

Thierry me signale à l'instant que ces modifications sont maintenant intégrées dans la version 0.6.1 disponible sur le Git.

Sur ma carte j'ai changé la pin de mesure de tension en reliant la pin IO0 à la pin IO34 :
   *  #define PIN_VOLTAGE_MES         34Cette dernière modification est à faire dans le fichier hmiConfig.h, ligne 22
ainsi que le coefficient de mesure de tension ligne 24 de ce fichier :
#define HMI_VoltageK            0.10        // Voltage scaling coefficient

J'avais trouvé précédemment que la mesure de tension ne marchait pas sur IO0, mais je vais refaire ce test pour éviter une modification du circuit imprimé.

J'ai également changé la fonction de mesure de tension dans le fichier hmi.cpp, ligne 728 :
  voltage = ((analogRead(PIN_VOLTAGE_MES) - 2740) * HMI_VoltageK) - 24 ;
La nombre 2740 est la valeur lue lorsque la tension est 0V. Le résultat n'est pas parfait et demande plus d'investigations.

Après toutes ces modifications, tout marche nickel :
- la connexion de mon iPhone en mode point d'accès (La Box - Locoduino), sur l'adresse IP 192.168.4.1, port 44444
- la sélection d'une loco (adresse DCC)
- la commande des vitesses et des fonctions de la loco.

Sur ces images, on voit les différents cas :
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3369;image)

- L'écran d'accueil après démarrage du wifi : indique l'adresse IP de LaBox
- la connexion avec succès d'un smartphone (ici Withrottle sur iPhone), avec l'alimentation des rails (voir la photo ci-dessous)
- quelques commandes de vitesse et de fonction (ici la lumière fonctionne et les autres fonctions apparaissent dans un petit carré)


Bravo à Thierry : on n'applaudira jamais assez  ;D ;D

Et à suivre...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le septembre 06, 2020, 03:47:54 pm
Pour info, j'ai poussé il y a deux minutes une nouvelle version avec juste les bonnes pins dans Labox.ino, et le numéro de version propre à Labox qui continuera d'évoluer : 0.6.1 . En développement, on ne met la version 1.0 que lors de la première distribution publique à fonctionnalités complètes du produit. On en est pas tout à fait là, même si on s'en approche.

Donc WiThrottle semble mieux gérer les fonctions que EngineDriver qui ne laisse pas les lumières allumées... En tout cas c'est ce que laisse présager la photo avec l'écran qui signale la fonction activée et la lumière allumée de la loco.

Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le septembre 06, 2020, 04:09:58 pm
Pour info, j'ai poussé il y a deux minutes une nouvelle version avec juste les bonnes pins dans Labox.ino, et le numéro de version propre à Labox qui continuera d'évoluer : 0.6.1 . En développement, on ne met la version 1.0 que lors de la première distribution publique à fonctionnalités complètes du produit. On en est pas tout à fait là, même si on s'en approche.
En effet, d'ailleurs je n'ai pas trouvé la fonction de recherche d'adresse DCC dans les menus HMI.
Aussi, de nombreuses commandes du menu HMI ne fonctionnent pas (j'ai testé le reset sui marche).

Citer
Donc WiThrottle semble mieux gérer les fonctions que EngineDriver qui ne laisse pas les lumières allumées... En tout cas c'est ce que laisse présager la photo avec l'écran qui signale la fonction activée et la lumière allumée de la loco.
Ce n'est pas totalement certain car j'ai constaté que la lumière s'est éteinte et ne s'est pas rallumée alors que le symbole * est sur l'écran. J'ai mis cela sur le compte des faux contacts et le fait que les commandes de fonction ne sont pas répétées en permanence.
De même, le retour des commandes de fonctions sur Withrottle qui inverse le bouton sur l'écran ne fonctionne pas pour le moment. J'avais obtenu ce résultat dans une ancienne version mais il faut que je retrouve les messages à retourner au smartphone en cas de commande.
Titre: Re : Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le septembre 07, 2020, 07:56:19 pm
Pour info, j'ai poussé il y a deux minutes une nouvelle version avec juste les bonnes pins dans Labox.ino, et le numéro de version propre à Labox qui continuera d'évoluer : 0.6.1 . En développement, on ne met la version 1.0 que lors de la première distribution publique à fonctionnalités complètes du produit. On en est pas tout à fait là, même si on s'en approche.
En effet, d'ailleurs je n'ai pas trouvé la fonction de recherche d'adresse DCC dans les menus HMI.
Aussi, de nombreuses commandes du menu HMI ne fonctionnent pas, sauf le redémarrage qui marche, mais avec une phase  en tension continue - non DCC - (donc la loco part à fond la caisse) puis DCC off jusqu'à le connexion d'un throttle.
Je confirme le bon fonctionnement de la nouvelle version 0.6.1 avec les bonnes pin ...

Sauf la mesure de tension qui ne fonctionne que sur le pin 34 (voir les modifications plus haut des fichiers hmiConfig.h et hmi.cpp).

En ce qui concerne les commandes de vitesses, msport a signalé - et je confirme - que la mise de la vitesse à zéro (ou avec bouton STOP) est affichée 002 sur l'Oled au lieu de 000. En déconnectant le smartphone, la vitesse passe alors bien à 000.

Citer
Donc WiThrottle semble mieux gérer les fonctions que EngineDriver qui ne laisse pas les lumières allumées... En tout cas c'est ce que laisse présager la photo avec l'écran qui signale la fonction activée et la lumière allumée de la loco.
Quand la lumière est allumée elle reste bien allumée, sauf faux contact.
Par contre on ne peut plus éteindre la lumière !
Si la lumière s'est éteinte à cause d'un faux contact, elle ne se rallume pas alors que le symbole * est sur l'écran.
Le problème est connu car les commandes de fonction ne sont pas répétées comme les commandes de vitesse/direction.
La commande de lumière sur Withrottle ne commande pas l'extinction de la lumière de la loco, ni le symbole *.
Confirmation aussi, le retour visuel des commandes de fonctions sur Withrottle qui inverse le bouton sur l'écran ne fonctionne pas pour le moment. Je vais regarder dans le code Withrottle.

En ce qui concerne la mesure de tension sur la pin 34, c'est pas trop mal mais pas précis et ça fluctue (ou mon alimentation est bizarre).
Par ailleurs la mesure de courant doit être améliorée (un peu-beaucoup faible). Je regarde aussi.

Bon travail en tout cas !

Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le septembre 08, 2020, 05:24:54 pm
Bravo à tous !

C'est quand même particulièrement réussi.
Petit, mais costaud  ;D

D'ici la semaine prochaine, je teste la toute première version sur un UNO avec un shield juste pour tester mon interface.
Puis je sors le fer à souder et je fabrique cette centrale : ça doit dépoter  8)

Denis
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le septembre 08, 2020, 09:55:23 pm
Après un essai infructueux pour avoir la fibre (gaine bouchée à l'entrée du terrain... ce sera pour plus tard !), puis un crash de mon disque principal avec tous mes documents Arduino, les fichiers des PCB de mon banc de test, les images de la famille, les mails, etc... A ce sujet, ne jamais négliger les sauvegardes ! J'en avais fait une fin Août, bien m'en a pris ! Je n'ai perdu que peu de choses, avec en plus mes développements en cours sauvés sur Github très récemment...

Bref, après ces péripéties, je viens de pousser une 0.6.2 avec ;
- un numéro de version correct (j'espère) !
- de menues corrections pour éviter des warnings dans SerialInterface et hmi.cpp
- Le numéro de pin correct dans hmiconfig.h pour la mesure
- une adaptation de labox.ino pour supprimer ma tentative de faire fonctionner les applis qui envoient des ordres texte DCC++ via une connexion ethernet ou Wifi et qui ne marche pas.
- une autre adaptation de labox.ino pour décommenter le support de la liaison série et permettre d'envoyer des ordres par la console de l'IDE.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le septembre 09, 2020, 04:10:20 pm
Merci pour cette nouvelle version :

Arduino : 1.8.13 (Windows 10), Carte : "ESP32 Dev Module, Disabled, Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS), 240MHz (WiFi/BT), QIO, 80MHz, 4MB (32Mb), 921600, None"

...

LaBox-master mis dans libraries de mes documents (comme la précédente) mais cette fois, problème à la compilation :


Arduino : 1.8.13 (Windows 10), Carte : "ESP32 Dev Module, Disabled, Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS), 240MHz (WiFi/BT), QIO, 80MHz, 4MB (32Mb), 921600, None"

....

no matching function for call to 'ThrottleSerial::begin()'

Bon courage.

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le septembre 09, 2020, 05:50:03 pm
Oups, version 0.6.3 poussée !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le septembre 09, 2020, 10:55:24 pm
C'est OK en compilation.

Engine Driver : bon début de prise en compte de la liaison série : la n° de la première loco s'affiche sur le HMI, un premier DCC off/on est exécuté mais plus rien ensuite. Par encore regardé ce qu'il y a sur les rails.

Très encourageant, merci.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le octobre 04, 2020, 10:17:05 am
Des nouvelles du projet :

un nouveau circuit imprimé a été commandé hier soir :

(https://www.locoduino.org/IMG/png/image.png)


A suivre, le schéma, la liste des ingrédients et d'autres améliorations...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le octobre 04, 2020, 10:19:43 am
Le schéma de la version 03 :

(https://www.locoduino.org/IMG/jpg/centrale03_sch.jpg)


Liste des améliorations et autres modifications par rapport au premier proto :

Voici l'écran d'accueil avec une alimentation de 12V
Le courant de 2mA signifie peut-être une consommation à vide du L6203  puisqu'ici je n'ai pas branché de rails sur la sortie DCC.
(https://www.locoduino.org/IMG/jpg/ecran_accueil1.jpg)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le octobre 04, 2020, 10:48:04 am
La liste du matériel (fichier .xlsx en PJ):


(https://www.locoduino.org/IMG/png/bom03.png)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le octobre 04, 2020, 06:15:21 pm
quelques écrans en fonctionnement :

(https://www.locoduino.org/IMG/jpg/laboxmedia.001.jpg)

On voit tourner la loco d'adresse DCC 18 à différentes vitesses en avant et en arrière.
L'intensité mesurée est substantiellement variable, mais avec des valeurs cohérentes (lues avec un Max471).
On voit également l'allumage des lumières et la commande de la fonction F2.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: laurentr le octobre 06, 2020, 12:53:11 pm
Hello

Ahg... c est beau...
Cela donne envie de sortir le fer a souder!!

Petite question on voit bien sur les capture la fonction 2 ou 5 activée mais que voit on si on a x fonctions actives, en même temps? (rotation d affichage, complétude jusque à saturation de l ecran? perte du reste? limites?
Aussi est il "possible d avoir un second écran pour d autres info ( ou une autre loc....?

Je dits cela... enfin ca peut servir!... :)
Laurent
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le octobre 06, 2020, 01:06:17 pm
Hello

Ahg... c est beau...
Cela donne envie de sortir le fer a souder!!

Petite question on voit bien sur les capture la fonction 2 ou 5 activée mais que voit on si on a x fonctions actives, en même temps? (rotation d affichage, complétude jusque à saturation de l ecran? perte du reste? limites?
Aussi est il "possible d avoir un second écran pour d autres info ( ou une autre loc....?

Je dits cela... enfin ca peut servir!... :)
Laurent

Surcharger l'écran n'est pas le but, seulement un moyen de contrôle.
L'écran de l'appli smartphone fait ce boulot bien mieux que ce petit écran et on regarde normalement plus le smartphone et la loco que la centrale.
Mais tout est possible : un port d'extension est prévu sur la gauche de l"ESP32.

Merci pour ces encouragements à ceux qui bossent plus que moi (Thierry, Msport et Cédric).
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le octobre 06, 2020, 01:28:13 pm
Je voudrais pas dire, mais sans dénigrer le travail de mes collègues, je pense que c'est toi qui travaille le plus sur le sujet ! (en tout cas par rapport à moi c'est sûr...)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le octobre 25, 2020, 11:17:24 am
Je viens de pousser une version 0.7.0 de la librairie Labox qui continue de progresser :

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le octobre 25, 2020, 11:50:47 am
Et bien Bravo ! Chapeau l'artiste  ;D ;D
J'ai hâte de tester ... avec les petits enfants qui arrivent cet après-midi ...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le octobre 25, 2020, 02:29:22 pm
J’ai lu dans la documentation Digikeijs ou Z21 que les commandes des fonctions sont répétées automatiquement (pas très vite) ce qui permet aux locos de ne pas perdre les états des commandes à chaque faux contact.
Ce n’est pas dans la norme comme les commandes de vitesse, mais cela peut être un plus appréciable.

On avait une discussion avec Antoine sur ce sujet : la solution était de passer les commandes de fonction dans les registres répétés. Il y a peut-être une solution plus élégante..
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le octobre 25, 2020, 03:33:36 pm
Bonjour à tous,

On voit que ça avance et c'est super. ;D ;D

J'ai commandé tout le matériel que je n'avais pas. Ça arrivera ... quand ça arrivera  8)
Mais, par expérience, les liens ebay sont ... volatiles. IL était urgent de commander.

Le schéma électrique ne tient pas dans la page affichée. Pourrait-on le mettre en PJ pour l'avoir en entier ?
Sur le schéma, des LM358 et sur la BOM des MCP6002. C'est quoi, la différence ?

Citer
Compte-tenu du gros défaut de linéarité du convertisseur analogique-numérique de l'ESP32, près du 0V, un offset de 0,2V est appliqué à l'entrée + de l'ampli et il est corrigé par logiciel dans le calcul de l'intensité.
Néanmoins la mesure d'intensité n'est pas très précise mais donne une bonne idée de la consommation sur les rails.

J'ai trouvé la courbe sur internet. C'est vrai que ça n'est pas vraiment linéaire.
https://itechnofrance.wordpress.com/2019/02/13/utilisation-des-ports-de-conversion-analogique-numerique-sur-un-esp32-en-micropython/ (https://itechnofrance.wordpress.com/2019/02/13/utilisation-des-ports-de-conversion-analogique-numerique-sur-un-esp32-en-micropython/)

Dans la pratique, la consommation de courant est une donnée sympa, utile, mais dont la valeur à trois chiffres après la virgule n'est pas vraiment fondamentale.
Et, juste pour avoir une idée, je pense que c'est suffisamment linéaire.
La non-linéarité est d'ailleurs plus "inquiétante" lorsqu'il s'agit des hautes tensions que pour les basses tensions.

Concernant les avancées de Thierry, c'est impressionnant !
Merci pour <r>. Encore un petit effort et on aura <w>  :D
Je précise pourquoi :
Si on veut régler les paramètres de vitesse, il faut tester sur un circuit bouclé, puis modifier les CV, puis retester, etc...

Dernière question :
Si, par exemple, mais alors tout à fait par hasard ::), on envoie des commandes DCCpp sur le port série de l'ESP, sont elles interprétées ?

Denis





Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le octobre 25, 2020, 06:19:08 pm
Bonsoir à tous,
bravo à Thierry pour ces avancées.
un premier test confirme
l'affichage des valeurs tension/courant et l'option pour identifier la machine. (ça marche mieux avec certains décodeurs récalcitrants).
le pas 0 est accessible.
mettre ou couper le courant sur la voie via Engine Driver fonctionne (pas testé avec WT ou Z21)
F0 fonctionne en fixe.
par contre je n'ai pas réussi à faire envoyer des commandes DCC++ par la ligne série (USB ou RX/TX)

pour Denis, le MCP6002 est une version LM358 spécifiée pour 3.3 V. Mais dans la pratique, il n'y a pas problème avec le LM358.
Et un schéma rétréci.
En fait ce n'est pas vraiment un problème de non-linéarité pour la conversion A/D de l'ESP, mais un écrêtage en haut et en bas. Il a suffi d'en tenir compte.

On pourrait garder des entiers pour l'affichage des valeurs tension/courant.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: laurentr le octobre 25, 2020, 07:02:10 pm
Bonsoir

J’ai lu dans la documentation Digikeijs ou Z21 que les commandes des fonctions sont répétées automatiquement (pas très vite) ce qui permet aux locos de ne pas perdre les états des commandes à chaque faux contact.
Ce n’est pas dans la norme comme les commandes de vitesse, mais cela peut être un plus appréciable.

Je te confirme bien que sur la DR5000 cela est tout à fait paramétrable. Ainsi pour les sorties de fonctions par groupe on peux fixer le nombre de répétitions très simplement en ajustant la valeur du nombre des cycles. Pur ma part j ai mis 4 pour chaque groupe est cela donne bien satisfaction.
A noter aussi qu'au démarrage on configurer aussi si tous les groupes sont actifs c est à dire s il envoie les informations  d'activation ou non des sorties.
Si pour les décodeurs de locomotives qui ont au plus 6 - 8 sorties c est par défaut actif, il en est tout autrement pour les sorties de décodeurs de fonctions qui pour ceux de ma production ont jusqu'à 16 sorties autonomes... Il faut alors veiller a ce que les états jus qu'à F16 au moins soient communiqués au décodeur...

J essayerai de te mettre prochainement une capture d écran pour illustrer la vue de configuration en question.

Laurent

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le octobre 26, 2020, 08:28:05 pm
Bonsoir.

Nouvelle version 0.7.2 (j'arrête pas...)

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le octobre 26, 2020, 08:32:12 pm
Pour ce qui est de la répétabilité des paquets de fonction, je l'avais traité de manière brutale dans DcDccNanoController en assignant systématiquement deux registres à chaque loco.

Il faudrait faire un peu plus fin en envoyant en boucle sur le registre 0 ou sur un autre registre dédié uniquement aux fonctions, l'état de toutes les fonctions de toutes les locos déclarées. Pour une loco, ça représente cinq paquets, ce qui n'est pas si important. Il faut juste trouver comment faire pour remplir la pile d'envoi en continu.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le octobre 26, 2020, 10:00:12 pm
Mais la perte de fonction sur coupure n’est gênante que pour la lumière ou les fonctions on/off (non fugitives). Certaines de mes locos gardent l’état en mémoire (même quand j’éteins tout). Donc pour les décodeurs basiques et les locos n’ayant que 2 essieux non bandagés.

Ca peut attendre si c’est un peu compliqué!
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le octobre 26, 2020, 10:51:43 pm
Bonsoir à tous,

effectivement, ça n'arrête pas et on s'en réjouit.

Test limité à <0> et <1> qui effectivement fonctionnent via RX0/TX0.
Mais par contre les commandes des locos  ne retrouvent pas sur la voie. (même avec ED connecté qui est OK) Elles arrivent bien à l'ESP qui cligne de l'oeil.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le octobre 27, 2020, 09:03:56 pm
Voilà, avec la 0.7.3, les commandes DCC++ devraient arriver aux rails ! Le traitement de chaîne de la Throttle 'bouffait' les espaces !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le octobre 27, 2020, 11:25:33 pm
Bonsoir à tous,

cette fois on a atteint le point d'étape, cohabitation de Engine Driver et des throttles (et autres TCO) sur RX/TX pour piloter les locos.

Et comme le pcb LaBox 0.3 n'a pas révélé de nouveaux bugs, (photo) c'est le bonheur.

Merci pour tous ces efforts soutenus.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le octobre 29, 2020, 10:35:11 am
Bonjour,

Petit à petit, je reçois les pièces manquantes via La Poste. Mais pour combien de temps encore ?  ::)
Je suis très heureux des avancées du projet.
Bravo à tous.

J'ai une question tordue :
Quand on envoie une "commande de vitesse" via DCCpp, en fait, on envoie une "demande de cran de vitesse".
Si on a bien testé sa loco, on peut lui affecter une vitesse réelle, à l'échelle, à chaque cran, une fois pour toute, suite à des essais, par exemple sur un rond.
Donc, on peut afficher le cran demandé et la vitesse demandée, par simple conversion.

On peut donc mettre un cadran gradué en km/h. OK.

Mais la loco a une inertie simulée via les CV. Elle met donc "un certain temps" ;) à atteindre la vitesse demandée. OK.

Peut-on récupérer l'information du cran de vitesse actuel (qui évolue jusqu'à atteindre le cran demandé) ?

Denis  :P
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le octobre 29, 2020, 10:37:59 am
L'inertie est traitée en interne par le décodeur, donc pas moyen de connaître le cran réel à l'instant t...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le octobre 29, 2020, 11:55:25 am
OK, merci pour l'info. Dommage...

J'ai une idée :

Dans le CV3 (pour l’accélération) et le CV4 (pour la décélération), on définit une durée du cran de vitesse.
Donc, si la loco est au cran 45 et qu'on veut la faire aller au cran 100, ça va durer (100 - 45) x CV3.
Par ailleurs, on connait la courbe de croissance (CV67 à 94)

Ce ne sera certainement pas une certitude et deux chiffres après la virgule, mais ça me paraît jouable.
A tester.

Denis  :P
Titre: Re : projet centrale wifi DCC++ Can
Posté par: trimarco232 le octobre 29, 2020, 12:31:58 pm
Bonjour,
aviez vous jeté un oeil à ceci : https://forum.locoduino.org/index.php?topic=830.0 (https://forum.locoduino.org/index.php?topic=830.0)
il n'y a pas eu de réaction ; avez vous utilisé une telle méthode afin d'avoir un signal dcc net, et de diviser par 2 le nombre d'interruptions du timer, nécessaires à la génération des bits dcc ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le octobre 29, 2020, 01:40:10 pm
Bonjour Marc,

En fait je me souviens de ton post et je devais être occupé à ce moment.

DCC++ et ensuite DCCpp font exactement la même chose.

Ça me rappelle mon premier article sur le DCC
 https://www.locoduino.org/spip.php?article17 (https://www.locoduino.org/spip.php?article17)

Et il y a sûrement d’autres manières de fabriquer du DCC.

Pour la question de Denis, je me demande à quel point le réalisme a besoin d’une telle précision. La pratique montre que la précision n’est pas nécessaire à ce point.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: trimarco232 le octobre 29, 2020, 03:27:58 pm
Bonjour Dominique,
on parle bien du principe d'utiliser un pwm matériel pour générer un bit dcc ?
en effet le(s) gent(s) de DCC++ on réussi à implanter ceci avec un avr, grâce à un peu d'astuce
pour DCCpp, j'en suis moins sûr ; malgré mes grandes faiblesses en c++, toutes les lectures que je peux faire du code indiquent une interruption systématique au terme des 58 ou 98µs de chacune des 2 impulsions d'un bit dcc ...
... alors qu'avec la méthode du pwm, l'interruption n'est déclenchée qu'au terme de la génération d'un bit dcc entier (soit 116 ou 196µs), ce qui divise le nombre d'interruptions par 2, et amha constitue un avantage déterminant
que vous en pense-t-il ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le octobre 29, 2020, 06:42:38 pm
Bonsoir,

Pour revenir au sujet de ce fil, et sur le problème du pcb première version qui comportait un support pour l'ESP trop étroit, on a identifié une version compatible avec les n° des broches de l'ESP32 DevkitC (36 broches) et qui s'implante directement sur le circuit sans modifications. Voir le lien eBay ci-dessous.

Sauf que deux modifications sont nécessaires pour être compatible avec le logiciel LaBox 073 :

1.   Changement de pin pour la mesure de tension
2.   Ajout d’une résistance de décalage de seuil (connecter provisoirement un potentiomètre de 1 Mohm pour évaluer la valeur de la résistance pour afficher ~0mA)

Une troisième est utile pour utiliser un module radio HC-12 ou bluetooth HC-6 sur RX0/TX0 .

3.   Inversion RX0/TX0 pour enficher directement un module radio HC-12 ou bluetooth HC-6.

Les photos pour les modifications :

A : ajout des liaisons au dos du pcb (1 fil pour la tension, 2 fils pour RX0/TX0, 1 résistance).
B : pistes à couper pour RX0/TX0.
C : piste à couper pour la tension.

Notons que cette première version du circuit permet d'installer l'afficheur en position verticale au bord du pcb, ce que ne permet plus aussi facilement la version 0.3
 
https://www.ebay.fr/itm/ESP-WROOM-32-ESP32-ESP32S-2-4GHz-WiFi-Bluetooth-Development-Board-for-Arduino/184310896504
Cette version de l'ESP32 n'est donc pas compatible avec le pcb 0.3, et est à réserver aux possesseurs du premier circuit.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Thierry le novembre 08, 2020, 04:02:11 pm
Merci pour <r>. Encore un petit effort et on aura <w>  :D

Après vérifications, ça existe depuis fort longtemps ! Les 'w' et 'b' (pour un seul bit) sont présents depuis le tout début de DCCpp...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le novembre 08, 2020, 04:19:31 pm
Merci Thierry !

Ça va m'être très utile pour Decoduino. ;D

Bien amicalement
Denis  :P
Titre: Re : projet centrale wifi DCC++ Can
Posté par: CATPLUS le novembre 09, 2020, 05:52:59 pm
Bonsoir
Après ce petit clin d'oeil (voir http://forum.locoduino.org/index.php?topic=1094.0) quelques news du montage de  "LaBox"
Il me manque certaines pièces, boutons poussoirs, potentiomètre réglable & les prises pour le Can.
Appel au 2 spécialistes "Dominique et Michel" pour les conseils,
une résistance de 260K pour remplacer le potar, pour les boutons et les prises on verra plus tard.
Un soucis avec une bibliothèque pour ESP32.
Une fois tout ceci résolu, mise en route, test avec "Engine Driver"

Le fonctionnement est impeccable et du 1er coup.

Poursuite de mes investigations, je souhaite connecter "Labox" avec  "Decoder Pro => JMRI"
Dans Decoder Pro il n'y a pas dans le menu déroulant une option Arduino, dans la liste on trouve tout le matériel disponible sur le marché, la seul option est DCC++.

Installation dans les préférences

J'ai testé les 4 réglages possibles
Sur les 4 le seul qui répond présent est "Simulator".
Après connection hélas rien, la seule chose que l'on peut afficher => le bouton marche/arrêt  (vert-rouge)
A suivre




Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le novembre 09, 2020, 08:07:14 pm
Je tenterai une connexion via l'USB de l'ESP / PC si ce n'est ce qui est fait (?)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: CATPLUS le novembre 09, 2020, 09:01:34 pm
C'est ce que j'ai fait
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le novembre 09, 2020, 09:51:38 pm
Je n'ai pas encore tenté la connexion JMRI, mais je pense qu'il attend la ligne :
<iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-1.2.1+ / Dec 28 2018 19:27:29><N0: SERIAL>

Et LaBox ne dit pas ça du tout.

Ceux qui connaissent JMRI pourront peut être confirmer comment il reconnait DCC++. (la doc ??)
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le novembre 25, 2020, 09:08:44 pm
Bonjour à tous.

Nouvelle version de Labox 0.7.4 aujourd'hui.

En premier lieu, j'ai implémenté une sauvegarde des locomotives enregistrées par les différentes throttles avec leurs caractéristiques: nom, vitesse, direction, fonctions, etc... Cette sauvegarde est effectuée par code à la demande (appeler Locomotives::SaveAll() ), et pour l'instant personne ne la demande. Je m'interroge d'ailleurs sur le besoin... Mais c'était l'occasion de tester ArduinoJson et de l'implanter sur mon simulateur  :)

Secondement, j'ai implémenté une répétition des packets de fonction sur le registre 0. Pour l'instant, les messages sont répétés toutes les 50ms afin de ne pas trop augmenter la charge d'envoi des paquets, et laisser du temps de traitement pour le reste de DCC++.
Pour une seule loco, il faut cinq packets différents pour renvoyer l'état de toutes ses fonctions. On peut au maximum avec 41 registres sur un ESP32 avoir quarante locos sur le réseau piloté par la centrale, ce qui est discutable électriquement vu la puissance de LaBox. Cela fait 200 paquets au maximum à envoyer chacun son tour, à 50ms d'intervalle, ce qui représente une rotation du même paquet toutes les 10000ms, soit dix secondes pour une fonction qui aurait été perdue suite à une coupure... Evidemment, Labox fait le tri entre les locos qui ne sont pas déclarées et les fonctions qui ne sont pas activées pour sélectionner les bons paquets. En réalité pour dix locos avec juste leurs feux d'allumé, ce sont seulement dix paquets et donc 500ms qui vont s'écouler entre deux répétitions des mêmes fonctions. Si l'on ajoute que nombre de décodeurs intègrent leur propre mémoire qui peut courir sur plusieurs minutes (cas de ma loco de test...) et donc n'ont pas besoin de cette sécurité, le rythme choisi devrait être suffisant. A noter que pour des raisons internes l'ordre d'extinction d'une fonction est lui envoyé immédiatement, en plus d'être répété plus tard si une autre des fonctions du paquet est activée.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le novembre 26, 2020, 08:36:20 am
Bonjour Thierry,

Cette fois encore je lève mon chapeau pour ces progrès importants dans La Box.

Évidemment la répétition des commandes de fonctions est bien indispensable, vu que le  nombre de registres (41) le permet aisément car je doute que l’on déploie souvent 40 locos en même temps. Mais qui peut le plus, peut le moins et avec un booster externe adéquat (en cours d’investigations par Marcel et Michel), dans un club, ça va sûrement arriver  8)

Pour la sauvegarde des locomotives, j’avoue que je ne me suis pas encore penché sur cette question mais je pressents son utilité dès la mise en place des premiers automatismes et pour mieux banaliser les throttles simples. Je vais essayer cette fonctionnalité prochainement.

De mon côté je prépare un jeu de satellites V1 pour gérer des zones d’arrêt en gare et les signaux correspondants, et pour intégrer cette rétro signalisation sur le bus Can de La Box, ce qui risque de me voir demander quelques .h et .cpp supplémentaires dans cette belle bibliothèque.

En parallèle nous sommes nombreux à tester La Box dans nos environnements respectifs ce qui me permettra prochainement de faire un point global sur ce fil.

Titre: Re : projet centrale wifi DCC++ Can
Posté par: fcot2002 le novembre 26, 2020, 04:48:14 pm
Bonjour @ tous !

Ayant été embarqué par Marcel (que je remercie chaleureusement d'ailleurs) je commence par vous féliciter du job ! ! !

Pour ce qui me concerne cette "LaBox" ne sera pas pour un réseau, mais un diorama de présentation avec essieux moteurs fonctionnels sous vitrine. (oui en O on roule pas toujours mais on aime bien présenter ses bijoux (pas de famille hein ::) ::) ::) ).

Alors la sauvegarde je dis OUI. Pour atteindre rapidement l'une des deux machines présentées.

Merci pour le job !

@ François
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Dominique le novembre 26, 2020, 05:37:40 pm
Merci François de nous rejoindre sur ce projet.

Il est important que tout utilisateur chanceux de La Box nous transmettra ses usages, ses souhaits (qui ne seront pas tous exhaussés) et toutes remarques utiles qui permettront de décrire La Box au mieux (un peu de marketing) et de l’améliorer.

Il me reste un ou deux circuits imprimés et on peut en faire d’autres (demander les gerbers).
Merci.
DIY
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le novembre 26, 2020, 06:25:17 pm
Bonjour Dominique,

J'ai presque tous les composants de la deuxième mouture.
Je veux bien un CI  ;D ;D

D'avance, merci
Denis :P
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le novembre 26, 2020, 07:32:52 pm
Bonjour Dominique,

J'ai presque tous les composants de la deuxième mouture.
Je veux bien un CI  ;D ;D

D'avance, merci
Denis :P

OK Denis,
ça partira demain, ou samedi.

Dominique
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le novembre 29, 2020, 05:43:42 pm
Bienvenue à LaBox 0.7.5

Cette nouvelle version permet de bien gérer la liste des locomotives pilotées et de leurs fonctions lorsque l'on utilise des messages texte. Ainsi une commende <f 3 144> va ajouter une loco adresse 3, pour un registre automatiquement sélectionné si elle n'existe pas déjà. Ensuite la fonction F0 de cette loco sera activée, et l'écran mis à jour pour refléter cette activation. De même, l'ordre <t 5 31 64 1> va de la même manière créer un nouvelle loco et du coup l'affichage sur l'écran changera pour montrer la courbe de vitesse de cette nouvelle loco.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le novembre 29, 2020, 06:19:15 pm
Bon c'est pas encore ça. Je dois y passer un peu plus de temps... C'est surtout l'écran qui me pose problème et ne reflète pas correctement l'état des fonctions. De plus j'ai des dépassements de capacité dans le CircularBuffer...
Titre: Re : projet centrale wifi DCC++ Can
Posté par: DDEFF le novembre 29, 2020, 06:36:12 pm
Bonsoir Thierry,

Juste pour ma gouverne, je serais preneur d'une photo de l'écran des fonctions, justement.

Enfin, et je te rejoins parfaitement, ce projet s'appelle "LaBox", sans blanc. L'intérêt, c'est que c'est aussi un "labo" et ce fil le prouve grandement.

Denis  :P
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le décembre 02, 2020, 06:18:06 pm
Voilà, je viens de pousser une version 0.7.6 qui cette fois doit bien réagir à l'utilisation de commandes texte.
D'un autre côté, je tente de me connecter à JMRI autrement que par la liaison série, et pour être sûr de bien le faire, je voudrais voir le code de la partie interface DCC++ dans JMRI, et notamment ce qu'il attends, mais je ne sais pas où chercher... Quelqu'un sait ?
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le décembre 02, 2020, 09:12:38 pm
J'ai trouvé le code ici : https://github.com/JMRI/JMRI/tree/master/java/src/jmri/jmrix/dccpp/network
Reste à le comprendre...
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: msport le décembre 02, 2020, 11:28:12 pm
... une version 0.7.6 qui cette fois doit bien réagir à l'utilisation de commandes texte ...
Effectivement un pas de plus, les commandes depuis une throttle de Dave Bodnar via HC12 sont affichées synchro sur LaBox. Nickel !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: bobyAndCo le décembre 02, 2020, 11:37:52 pm
Ah, tout le monde n'a pas la même chance. Pou moi, erreur de compilation quand je veux jouer l'exemple WifiDcc.ino

WifiDcc:16:27: error: declaration of 'Throttle* TextCommand::pCurrentThrottle' outside of class is not definition [-fpermissive]
 WiFiServer DCCPP_INTERFACE(2560);
                           ^
WifiDcc:16:32: error: invalid conversion from 'int' to 'Throttle*' [-fpermissive]
 WiFiServer DCCPP_INTERFACE(2560);
                                ^
/Users/christophe/Documents/Arduino/libraries/LaBox-master/examples/WifiDcc/WifiDcc.ino: In function 'void setup()':
WifiDcc:23:3: error: 'beginWifi' is not a member of 'DCCpp'
   DCCpp::beginWifi(ssid, password, EthernetProtocol::TCP);
   ^
Plusieurs bibliothèque trouvées pour "WiFi.h"
Utilisé : /Users/christophe/Library/Arduino15/packages/esp32/hardware/esp32/1.0.4/libraries/WiFi
Non utilisé : /Applications/Arduino.app/Contents/Java/libraries/WiFi
Utilisation de la bibliothèque LaBox-master version 1.4.0 dans le dossier: /Users/christophe/Documents/Arduino/libraries/LaBox-master
Utilisation de la bibliothèque ArduinoJson version 6.15.2 dans le dossier: /Users/christophe/Documents/Arduino/libraries/ArduinoJson
Utilisation de la bibliothèque WiFi version 1.0 dans le dossier: /Users/christophe/Library/Arduino15/packages/esp32/hardware/esp32/1.0.4/libraries/WiFi
Utilisation de la bibliothèque Adafruit_GFX_Library version 1.5.7 dans le dossier: /Users/christophe/Documents/Arduino/libraries/Adafruit_GFX_Library
Utilisation de la bibliothèque Adafruit_SSD1306 version 1.3.0 dans le dossier: /Users/christophe/Documents/Arduino/libraries/Adafruit_SSD1306
Utilisation de la bibliothèque Wire version 1.0.1 dans le dossier: /Users/christophe/Library/Arduino15/packages/esp32/hardware/esp32/1.0.4/libraries/Wire
Utilisation de la bibliothèque SPI version 1.0 dans le dossier: /Users/christophe/Library/Arduino15/packages/esp32/hardware/esp32/1.0.4/libraries/SPI
Utilisation de la bibliothèque OneButton version 1.5.0 dans le dossier: /Users/christophe/Documents/Arduino/libraries/OneButton
Utilisation de la bibliothèque FS version 1.0 dans le dossier: /Users/christophe/Library/Arduino15/packages/esp32/hardware/esp32/1.0.4/libraries/FS
Utilisation de la bibliothèque SPIFFS version 1.0 dans le dossier: /Users/christophe/Library/Arduino15/packages/esp32/hardware/esp32/1.0.4/libraries/SPIFFS
exit status 1
conflicting declaration 'WiFiServer* TextCommand::pCurrentThrottle'

Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le décembre 03, 2020, 08:44:59 am
En fait, l'exemple LaBox.ino classique fonctionne très bien. Prends le fichier joint qui est un peu modifié et qui m'a servi à me connecter à JMRI en wifi ! Dans la prochaine version, je retirerai l'exemple WifiDcc qui n'a plus d'intérêt, ou je le modifierai pour qu'il ne gère qu'une throttle wifi et pas les autres...
Dans LaBox, c'est le Throttle throttleWifi0 qui fait la connection TCP. Tu peux tenter de changer en HTTP si tu veux tester le mode connexion à ton site de pilotage, mais je pense qu'il y a des choses qui ne marcheront pas...

Michel, avec ton HC12 tu n'as fait aucune modif dans LaBox ? Sinon elles m'intéressent !

Au passage, JMRI fonctionne donc, et eux ont leur propre mécanisme pour gérer le problème des fonctions, JMRI renvoie en boucle les fonctions qui ont été touchées par un régulateur !
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le décembre 03, 2020, 09:53:08 am
HC-12 : Aucune modification du pcb de LaBox 0.3 pour brancher le module HC12 sur le header 4pins (le SET reste en l'air). Le premier pcb inversait RX/TX. Il faut coucher le potentiomètre (qui d’ailleurs ne sert plus une fois que le zéro mA est réglé, si on ne change pas d'ESP)
Pas de configuration particulière du HC12, sauf la vitesse à 115200b, avec le petit utilitaire joint.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: Thierry le décembre 03, 2020, 10:08:10 am
Je parlais surtout de modif logicielle, mais c'est vrai que je n'avais pas vu qu'une entrée rx/tx extérieure était prévue.
Titre: Re : projet centrale wifi DCC++ Can
Posté par: msport le décembre 03, 2020, 03:21:01 pm
J'utilise LaBox.ino tel quel ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le décembre 06, 2020, 06:12:22 pm
Bonjour à tous,

Depuis le 4 Octobre, date du nouveau circuit imprimé V0.3 :
(https://www.locoduino.org/IMG/png/image.png)
et du schéma qui va avec :
(https://www.locoduino.org/IMG/png/centrale03_sch.png)

Nous avons fait un bout de chemin, surtout du coté logiciel, grâce à Thierry  ;D


Donc si vous voulez vous lancer dans l'aventure, le mieux est de lire d'abord la description des phases de fabrication en mode DIY, afin de vous rendre compte si vous êtes capable de construire votre LaBox.

Il y aura donc la liste des composants à se procurer, puis des étapes avec photos du montage pas à pas, puis la programmation de l'ESP32 qui équipe LaBox, avant de brancher l'adaptateur secteur et faire rouler vos trains.

Enfin, je décrirai les fonctionnalités de LaBox, testées par nous-même et tous ceux qui viendront se joindre à nous, ainsi que les évolutions prévues, attendues, souhaitées, sachant que le but n'est pas d'en faire une usine à gaz  >:(

Attachez votre ceinture !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le décembre 06, 2020, 06:22:00 pm
1) Le circuit imprimé

Le voici vue recto et vue verso :
(https://www.locoduino.org/IMG/jpg/laboxmediahq.002.jpg)

et la sérigraphie des composants pour se repérer :
(https://www.locoduino.org/IMG/jpg/laboxmediahq.009.jpg)

Bien entendu les fichiers Gerber sont disponibles en PJ. Nous les avons fait tirer chez JLCPCB
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le décembre 06, 2020, 06:29:39 pm
2) Les composants


Voici la liste en PJ et en image ici :
(https://www.locoduino.org/IMG/png/bom03.png)

Vous verrez que c'est assez (ou très) compliqué d'obtenir ces composants à des prix très faibles (on peut arriver au alentours de 35€), étant donné les délais qui s'allongent à cause de la Covid (mérite-t-elle une majuscule ?) et bientôt du nouvel an chinois.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le décembre 06, 2020, 06:30:38 pm
3) le montage des composants


J'en monte une pour décrire ces opérations  ::)

On commence toujours par les composants les plus petits. Il faut utiliser un fer à souder ayant une pointe fine de préférence et s'assurer que la soudure colle bien en remontant un par capillarité sur les bouts de queue des composants. Attention au sens de diodes 1N5819 : l'anneau blanc  doit correspondre au trait blanc sur la sérigraphies.
La résistance R6 de 10kΩ peut être réduite si vos leds ne sont pas très "basse consommation" (>5mA) : 4,7kΩ doit faire l'affaire dans ce cas (n'oubliez pas qu'elles sont alimentées en 12 à 18V donc avec la valeur de 330Ω vue ailleurs sur des exemples en 5V, 15mA, c'est leur mort assurée !).

(https://www.locoduino.org/IMG/jpg/laboxmediahq.003.jpg)

Après installation de ces 17 composants, vérifiez bien visuellement en comparant à l'image ci-dessus. Avec une loupe forte (d'horloger), regardez si les soudures sont belles (et bonnes ).
Puis :

(https://www.locoduino.org/IMG/jpg/laboxmediahq.004.jpg)

Pour le soudage des résistances CMS de 0,5Ω chacune, je recommande de couper un petit bout de soudure, de le placer à coté d'une extrémité de la résistance (image 1), de tenir la résistance en appuyant avec une pince brucelles fine tout en approchant la pointe du fer à souder (image 2) puis de souder l'autre coté de façon habituelle (image 3) :

(https://www.locoduino.org/IMG/png/soudage_cms.png)

Après examen visuel à la loupe, on procède au montage du module régulateur 5V :
On prépare 4 paires de broches mâles qu'on insère, coté longues pattes dans les trous à souder du circuit imprimé, correspondant au régulateur. Puis on place le régulateur sur les pattes courtes et on soude coté régulateur. Puis on retourne la platine, et on soude les autres cotés des broches mâles sur le circuit imprimé et on coupe l'excédent.
C'est parfois un jeu de patience !
Ensuite on soude une paire de broches mâles à l'emplacement du strap DCC (au dessus d'une résistance CMS R500) et enfin le jack femelle d'alimentation J1.
On peut souder 2 ou 4 broches mâles à l'emplacement "TEST 5V" qui va servir à la mesure de la tension AVANT d'installer d'autres composants, en particulier l'ESP32 qui ne supporterait pas autre chose que 5V. Pour ce faire, on branche un voltmètre sur les pattes "Test 5V" : le +5V est à gauche et le GND est à droite.
Branchez une alimentation sir le jack d'alimentation : au moins 7V (9, 12V...)
Si vous avez un module régulateur équipé d'un potentiomètre, il est probable que la tension de sortie soit supérieure à 5V. tournez le potentiomètre pour obtenir 5V ou un valeur approchante (de 4,95V à 5,03V par exemple).

Ensuite on installe les autres composants mentionnés sur la photo ci-dessous.
On installe seulement les 2 leds Led1 et Led2 ou Led3 et Led4 selon le chois du connecteur DCC (à vis ou connecteur mâle-femelle).
Les 2 leds doivent être montées en tête-bèche : l'anode de l'une avec la cathode de l'autre. Les couleurs n'ont pas d'importance : quand le DCC est généré, les 2 Leds doivent être allumées ensemble car c'est un signal alternatif. Si une seule Led est allumée, alors c'est une tension continue et ça ne va pas !
Les supports 19 pattes pour l'ESP32 peuvent être des supports 20 pattes dont on enlève une patte du coté de l'antenne (ça ne se voit pas).
La Led "défaut" avoir sa grande patte (+, anode) vers le bas du circuit imprimé (voir la sérographie plus haut dans laquelle j'ai ajouté le sens de la Led car la sérigraphie sur le circuit imprimé ne la mentionne pas).

(https://www.locoduino.org/IMG/jpg/laboxmediahq.005.jpg)

Puis on peut installer les composants les plus hauts : les condensateurs électrolytiques, les connecteurs femelles RJ11, le L6203 et les 3 boutons poussoirs : attention, il y a un sens à respecter : le contact bouton enfoncé doit se trouver à droite du contact milieu (relié au Gnd). un test à l'ohmmètre est nécessaire et vous évitera de détruire un bouton ou le circuit imprimé.

(https://www.locoduino.org/IMG/jpg/laboxmediahq.006.jpg)

Et enfin, la mise en place des modules ESP32 Devkit V4, l'Oled, l'interface Can. Celle-ci doit être mntée avec son circuit intégré en dessous (non visible) : vérifiez toujours que les indications sur le module correspondent à celles inscrites sur le circuit imprimé.
En ce qui concerne l'Oled, il existe quelques versions dont les broches d'alimentation sont inversées : il ne peut pas être monté sur LaBox. L'ordre des broches de gauche à droite doit être SDA, SCL, VIN et Gnd.
Bien faire correspondre la position de l'Oled avec le cadre imprimé sur le circuit imprimé et utiliser les emplacements du connecteur à l'intérieur de ce cadre. Ainsi il sera possible de bloquer l'écran Oled en soudant une tige (queue de diode par exemple) sur 1 ou 2 coins de l'Oled et le trou métallisé qui se troupe (presque) en face.

(https://www.locoduino.org/IMG/jpg/laboxmediahq.007.jpg)

A ce stade, LaBox ne fonctionne pas encore, il faut d'abord charger le logiciel dans l'ESP32 ! ;D
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le décembre 06, 2020, 06:31:24 pm
4) le chargement du logiciel


1) Téléchargement du dossier  "LaBox" (https://github.com/Locoduino/LaBox) sur le dépôt Git de Locoduino

Ce dossier doit être placé dans le dossier "libraries" de l'IDE Arduino. C'est une bibliothèque mais il n'est pas (pour le moment) installable par l'IDE (menu Croquis/Inclure une Bibliothèque/Gérer les bibliothèques).

2) D'autres bibliothèques sont nécessaires pour réaliser une compilation avec succès :
"Adafruit_GFX"
"Adafruit_SSD1306"
"OneButton"
"ArduinoJson"
Ces dernières bibliothèques sont installables par l'IDE Arduino (menu Croquis/Inclure une Bibliothèque/Gérer les bibliothèques).

3) Installer l'environnement ESP32 dans l'IDE Arduino :
Dans les Préférences de l'IDE Arduino, ajouter l'URL de gestionnaire de cartes supplémentaires suivantes : https://dl.espressif.com/dl/package_esp32_index.json
Puis redémarrez l'environnement IDE Arduino.
Dans le menu Outils/Type de cartes/Gestionnaire de cartes, cherchez et installez "esp32" de Espressif Systems (version 1.0.4 ou suivante).

Lorsque l'installation est terminée (cela peut prendre un peu de temps), sélectionnez la carte ESP32 Dev Module (la première dans la liste)

(https://www.locoduino.org/IMG/jpg/esp32_dev_module.jpg)

En ouvrant à nouveau le menu Outils/Type de cartes, on doit voir la description du module ESP32 Dev Module et on peut le relier à l'ordinateur par un câble USB et choisir le port correspondant :

(https://www.locoduino.org/IMG/png/typedecarteesp32.png)

4) Ouvrir l'exemple LaBox.ino qui se trouve dans le dossier libraries/LaBox/examples/LaBox

Si la compilation se passe bien, on obtient le texte suivant dans la fenêtre de compte-rendu de l'IDE :

Le croquis utilise 751854 octets (57%) de l'espace de stockage de programmes. Le maximum est de 1310720 octets.
Les variables globales utilisent 44240 octets (13%) de mémoire dynamique, ce qui laisse 283440 octets pour les variables locales. Le maximum est de 327680 octets.

on peut alors téléverser le logiciel dans l'ESP32 et on obtient ce mesasge concluant :

Le croquis utilise 751854 octets (57%) de l'espace de stockage de programmes. Le maximum est de 1310720 octets.
Les variables globales utilisent 44240 octets (13%) de mémoire dynamique, ce qui laisse 283440 octets pour les variables locales. Le maximum est de 327680 octets.
esptool.py v2.6
Serial port /dev/cu.SLAB_USBtoUART
Connecting........_
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 24:6f:28:7c:67:14
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 8192 bytes to 47...
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.0 seconds (effective 5131.6 kbit/s)...
Hash of data verified.
Compressed 17392 bytes to 11186...
Wrote 17392 bytes (11186 compressed) at 0x00001000 in 0.1 seconds (effective 988.7 kbit/s)...
Hash of data verified.
Compressed 751968 bytes to 452725...
Wrote 751968 bytes (452725 compressed) at 0x00010000 in 7.0 seconds (effective 863.8 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 128...
Wrote 3072 bytes (128 compressed) at 0x00008000 in 0.0 seconds (effective 1794.4 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Sur l'écran Oled de LaBox, on doit voir apparaître successivement les écrans suivants :

(https://www.locoduino.org/IMG/png/demarrage.png)

5) Réglage du "zéro" de la mesure de courant
En tournant le potentiomètre Pot de 500k à droite de l'écran Oled, cherchez à obtenir un affichage proche de 0 mA. Evitez principalement une valeur négative mais une valeur positive entre 2 et 5 mA conviendra parfaitement. La mesure de courant qui s'affiche sur l'Oled reste une valeur approximative qui donne une idée de la consommation de courant du matériel roulant sur la voie.

6) Dans le moniteur de l'IDE (s'il est ouvert) on doit lire :

Server IP address: 192.168.4.1 (Locoduino LaBox) connected ! connectWifi achieved.
Ino executing on core 1
Throttles command receivers executing on core 0
begin achieved
Signal started for Main track on pin 33
Main track DCC ESP32 started.
beginMain achivied with pin 33
*** LaBox LIBRARY : 0.8.0
VERSION DCC++     : 2.0.0
COMPILED          : May 15 2021 17:13:23
   ENABLE(PWM): 32
   CURRENT: 36
Throttles ------------------
0 : Serial
1 : JMRI
2 : ThrottleWifi: Z21 - 1  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
3 : ThrottleWifi: Z21 - 2  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
4 : ThrottleWifi: Z21 - 3  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
5 : ThrottleWifi: WiThrottle - 1  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
6 : ThrottleWifi: WiThrottle - 2  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
7 : ThrottleWifi: WiThrottle - 3  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected

7) connexion d’un Throttle Withrottle (IOS)

Observez ce qui s’affiche dans la fenêtre moniteur de l’IDE

a- choix du réseau WiFi Locoduino LaBox:

dhcps: send_nak>>udp_sendto result 0
b- lancement de Withrottle et réglage sur le serveur LaBox (192.168.4.1:44444):

Converter : New client
5 -> VN2.0
5 -> RL0
5 -> PPA2
5 -> RCL0
5 -> PW12080n
DCCpp PowerOn
Throttles ------------------
0 : Serial
1 : JMRI
2 : ThrottleWifi: Z21 - 1  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
3 : ThrottleWifi: Z21 - 2  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
4 : ThrottleWifi: Z21 - 3  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
5 : ThrottleWifi: WiThrottle - 1  WifiPort: 44444  WifiProtocol: TCP  timeout: 60000 (WiThrottle converter)  start:0 end:10 ip:192.168.4.2
6 : ThrottleWifi: WiThrottle - 2  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
7 : ThrottleWifi: WiThrottle - 3  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
5 From Throttle : NiPhoneDB

c- reconnaissance de la connexion de Withrottle (iPhone):

Throttle 5 NiPhoneDB
5 -> <p1>*10
5 From Throttle : HUBDE241D3-07EA-4A60-BD6B-EE19
Throttle 5 HUBDE241D3-07EA-4A60-BD6B-EE19

d-choix de l’adresse DCC : 3 (ou reconnaissance automatique préalable et choix de l’adresse affichée sur l’écran Oled):

5 From Throttle : MT+S3<;>S3
Throttle 5 MT+S3<;>S3
5 -> MT+S3<;>
5 -> MTAS3<;>F00
5 -> MTAS3<;>F01
5 -> MTAS3<;>F02
5 -> MTAS3<;>F03
5 -> MTAS3<;>F04
5 -> MTAS3<;>F05
5 -> MTAS3<;>F06
5 -> MTAS3<;>F07
5 -> MTAS3<;>F08
5 -> MTAS3<;>F09
5 -> MTAS3<;>F010
5 -> MTAS3<;>F011
5 -> MTAS3<;>F012
5 -> MTAS3<;>F013
5 -> MTAS3<;>F014
5 -> MTAS3<;>F015
5 -> MTAS3<;>F016
5 -> MTAS3<;>F017
5 -> MTAS3<;>F018
5 -> MTAS3<;>F019
5 -> MTAS3<;>F020
5 -> MTAS3<;>F021
5 -> MTAS3<;>F022
5 -> MTAS3<;>F023
5 -> MTAS3<;>F024
5 -> MTAS3<;>F025
5 -> MTAS3<;>F026
5 -> MTAS3<;>F027
5 -> MTAS3<;>F028
5 -> MT+S3<;>V0
5 -> MT+S3<;>R1
5 -> MT+S3<;>s1
Locomotives ------------------
0 : Loco reg:1 id:3 max:128      +/-speed:0      functions:

e- variation de la vitesse avec le curseur de vitesse de Withrottle:

5 From Throttle : MTAS3<;>V3
Throttle 5 MTAS3<;>V3
DCCpp SetSpeed for loco 3 : 3/128 )
5 From Throttle : MTAS3<;>V16
Throttle 5 MTAS3<;>V16
DCCpp SetSpeed for loco 3 : 16/128 )
5 From Throttle : MTAS3<;>V26
Throttle 5 MTAS3<;>V26
DCCpp SetSpeed for loco 3 : 26/128 )
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le décembre 06, 2020, 06:31:52 pm
5) Les premiers démarrages

LaBox peut être commandée de différentes manières : Commençons par les applications sur smartphone, dans le même esprit que pour JMRI (https://www.jmri.org/help/en/package/jmri/jmrit/withrottle/UserInterface.shtml).

Je donne ici, pour commencer, deux exemples avec Withottle Lite et Z21 Mobile, sur IOS (parce que j'ai un iPhone), mais il en existe aussi sur Android Engine Driver et Z21 Mobile aussi. On commencera donc par installer l'une de ces applications (gratuites) sur votre smartphone.

Ensuite, on va connecter le smartphone sur le serveur WiFi que LaBox a créé : Locoduino LaBox, qui est un réseau sans mot de passe, mais sans risque pour votre réseau personnel à la maison.
(https://www.locoduino.org/IMG/jpg/wifichoix1_copie.jpg)

1) Exemple avec Withrottle Lite
Le Wifi de LaBox étant lancé et connecté en préalable, on peut lancer l'application Withrottle et cheminer dans les écrans (pour plus de détails on pourra se reporter à la documentation Withrottle (https://www.withrottle.com/html/home.html))

(https://www.locoduino.org/IMG/png/withrottlelite.png)
Le premier écran montre les paramètres de le connexion Wifi.
A la connexion, remarquez que les Leds à coté du connecteur DCC s'allument toutes les deux : le DCC est présent sur les rails  ;D
Le deuxième écran montre le choix de la locomotive (adresse DCC 18, soit dans l'historique, soit par saisie au clavier).
Le troisième écran montre le pilotage de la locomotive avec un curseur pratique, les fonctions et la direction.

Quelques remarques : si le téléphone sonne et que vous prenez un appel ou si vous changez d'application en cours de jeu, votre locomotive va s'arrêter !!

2) Exemple avec Z21 Mobile

Le Wifi doit être aussi lancé en préalable.

On trouvera aussi tous les détails sur cette application Z21-app (https://www.z21.eu/en/z21-system/z21-app)

(https://www.locoduino.org/IMG/png/z21mobile_.png)
Le premier réglage est l'adresse IP de LaBox dans "App Settings"
Puis le choix d'une loco dont on connait l'adresse DCC (soit dans la liste préexistante, soit en la créant)
Enfin le pilotage selon le même principe avec le curseur de vitesse, la direction et les fonctions.

Quelques remarques : l'adresse IP de LaBox étant enregistrée dans l'application, aux lancements suivants l'application se connecte toute seule sans passer par un écran de connexion. Mais, contrairement à Withrottle, si on change d'application, la locomotive ne s'arrête pas tout de suite (il faut attendre que LaBox s'aperçoive de la perte de session avec l'application lorsqu'on la quitte). De même lorsque le téléphone sonne, mais il y a des réglages possibles à explorer...

3) Comment trouver l'adresse DCC d'une locomotive (dont on ne connait pas l'adresse) ? :o ???

Et bien c'est là que LaBox est géniale  8) :

On se sert des boutons de Labox :
(https://www.locoduino.org/IMG/jpg/updownsel.jpg)

Au préalable il faut que LaBox soit connectée sur les rails et que les voyants DCC soient allumés (en connectant l'application smartphone, même si on ne connait pas -encore- l'adresse de la loco). Attention, une seule loco doit être posée sur les rails.

On premier appui sur le bouton "SEL" fait apparaitre une liste de fonctions.
Avec le bouton "DOWN" on sélectionne "Lecture addr Train".
Puis on appuit sur SEL.

(https://www.locoduino.org/IMG/png/lectureadressedcc.png)

Au bout de quelques secondes, l'adresse DCC apparaît sur l'écran, après avoir vu la loco gigoter sur les rails (c'est le norme DCC décrite dans NMRA).
La lecture est répétée une 2ème et une 3ème fois pour une réussite plus certaine. En cas d'erreur (message "ERROR" affiché), on peut incriminer un mauvais contact entre les rails et la loco : je préconise de mettre un doigt léger sur la loco pour appuyer plus fermement les roues sur les rails.
Mais ce sujet sera amplemnet décrit sur le forum.

Voilà vous avez son adresse, il ne reste plus qu'à la programmer dans l'application et piloter votre loco.

LaBox autorise plusieurs locomotives sur le même réseau donc plusieurs smartphones en même temps, ce qui permet de jouer à plusieurs avec sa propre manette associée à son propre train.

Dans ce cas, vous pouvez changer le "Type de vue trains" avec les boutons pour afficher 1, 2 ou 3 curseurs sur l'écran Oled. Cet écran permet de vérifier la conformité du comportement de LaBox avec votre application sur smartphone.

Alors ça vous plait ? :)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le décembre 06, 2020, 06:42:10 pm
6) Les applications possibles de LaBox

Ce chapitre viendra progressivement, alimenté par votre expérience et les corrections suites aux anomalies constatées : merci de contribuer à la suite de ce tutoriel  :D

La suite à venir...




après cette description, il serait super si vous pouviez donner votre avis, si vous souhaitez acquérir LaBox et dans quel environnement l'utiliserez-vous.
Titre: Re : Re : projet centrale wifi DCC++ Can
Posté par: Dominique le décembre 07, 2020, 06:53:45 pm
Voilà, je viens de pousser une version 0.7.6 qui cette fois doit bien réagir à l'utilisation de commandes texte.

Je viens de compiler l'exemple Labox.ino de cette version 0.7.6 : erreur de compilation due à l'absence de la bibliothèque ArduinoJson !.

Laquelle faut-il installer : cette de Benoit Blanchon version 6.17.2 ?
Après installation, la compilation est OK  ;)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le décembre 08, 2020, 03:50:34 pm
Bonjour à tous,

Le tutoriel LaBox de la page 23 est pratiquement terminé : il y a maintenant tout ce qu'il faut pour monter et utiliser LaBox.

J'attends vos retours pour le compléter et l'améliorer.

Merci d'avance
Dominique
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jeje_12_34 le décembre 08, 2020, 06:12:15 pm
Bonjour a tous

Je réaliserai cette box, mais je ne peux pas m'y lancer immédiatement.

Le  concept de Locoduino Satellite Can evolutif et peu cher m'intéresse vraiment, autant le faire avec LaBox.


Pour l'instant,  il y a plein de choses que je n'ai pas encore fait depuis mes débuts l'année dernière entre autres : le soudage de cms, la réalisation de détecteurs, des satellites  et l'utilisation de circuits imprimes  dédiés.

Ah oui il me faut aussi faire un "vrai" petit réseau de test, mon double ovale n'est vraiment pas assez complexe : ni canton, aucune détection et les aiguilles sont manuelles.

J'aurai beaucoup plus de temps disponible à partir de mai  ... :) si tout va bien

Si aucun autre néophyte ne vous fait de retour, vous pourrez compter sur moi.

Vous pouvez me mettre une platine de coté, ou il faudra que je la fasse faire en Chine ?


Jerome
Pret a vous aider, mais pas tout de suite :)



Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le décembre 08, 2020, 07:08:36 pm
Le  concept de Locoduino Satellite Can evolutif et peu cher m'intéresse vraiment, autant le faire avec LaBox.

Vous pouvez me mettre une platine de coté, ou il faudra que je la fasse faire en Chine ?


Jerome
Pret a vous aider, mais pas tout de suite :)

Merci Jerome,

Mais chacun se fait plaisir selon son temps disponible.

La question des approvisionnements se posera forcément s'il la demande grossit : des achats groupés seront envisagés.
Je t'inscrit dans la liste  :)

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le décembre 08, 2020, 08:36:24 pm
Bonjour à tous

Plusieurs évolutions/corrections dans la dernière version 0.7.7 de LaBox :

- Un ThrottleWifiJMRI a été ajouté. Il permet à la centrale d'être pilotée par JMRI par Wifi.
- J'ai passé en revue les différents #define USE_* présents dans DCCpp.h et qui permettent de n'utiliser que certaines parties de la bibliothèque. Par exemple, il est tout à fait possible maintenant de ne pas utiliser HMI et de faire soi-même son interface utilisateur dans son .ino, voire de ne pas en avoir du tout (cas d'une centrale 'boite noire' sans écran). Possible aussi de redescendre le niveau de fonctionnalités de LaBox au niveau d'un simple DCCpp, sans Throttles, sans HMI, et même sans les Locomotives gérées par LaBox. Mais dans ce dernier cas, la fonctionnalité d'envoi périodique des fonctions n'est plus disponible, elle est intimement liées à ces locos.
- J'ai fait le ménage dans les exemples livrés avec LaBox pour ne laisser que ceux qui sont vraiment utiles .
  - A tout seigneur, tout honneur, LaBox.ino est bien l'exemple le plus parlant pour la centrale. Cet exemple permet de recevoir des ordres texte par la ligne série, comme l'IDE ou JMRI par cable USB. Le nouveau ThrottleWifiJMRI est également présent et permet de laisser JMRI piloter la centrale en Wifi. De plus, trois points d'entrée WiThrottle/EngineDriver sont présents, ainsi que trois points d'entrée Z21. Ce sont ainsi huit moyens différents de piloter la centrale sans changer une ligne de code de LaBox.ino !
  - Autotest est toujours présent et permet d'automatiser un ou plusieurs convoi.
  - SerialDcc est un exemple minimaliste repris de DCCpp. Il marche tel quel, n'utilisant que la partie DCCpp de la bibliothèque. Seul changement, l'appel du bon fichier .h ...
  - ThrottleSerialDcc est lui l'ancien exemple série, qui ne gère que l'entrée par port série, mais à la façon LaBox avec une throttle.


Bravo pour la doc Dominique, je dois de mon côté commencer à rédiger la doc du code, j'espère avec l'aide de Cédric.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: DDEFF le décembre 09, 2020, 10:53:02 am
Bonjour Thierry,

Dans Decoduino, je teste la présence d'un Arduino et son shield moteur en envoyant sur le port série la commande :
port.write("power on <1>");
Si je reçois :
<p1>
j'en déduis :
1°) qu'il y a bien un Arduino
2°) qu'il contient bien DCC_controller.ino

Comme je teste tous les ports, je trouve le premier qui me répond <p1>. J'ai donc trouvé le bon port et je m'y connecte.

Je pense que la même manip va me permettre de trouver LaBox.

Y-a-t-il une façon de différentier la réponse en fonction de ce sur quoi on est branché ?
Je m'explique :

Puis-je avoir comme réponse <p1 Arduino> ou <p1 LaBox> (ou <p1 Atmega328p>, <p1 ESP32>, ...) suivant là ou je suis branché ?

Denis  :P
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Lilian.A le décembre 09, 2020, 11:01:53 am
Bonjour

bien que tout nouveau je me permet de répondre par une piste
a la connexion ma carte envoie ca

<iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-1.2.1+ / Dec  1 2020 17:08:09>

je suppose que labox doit faire de même ??

il y a aussi une fonction qui renvoie la version.

cordialement .
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le décembre 09, 2020, 12:27:43 pm
Bonjour et merci de participer.
Votre acquittement est celui de la BaseStation.

Ici on est sur le fil de LaBox avec un ESP32.

LaBox ne répond pas à < s > ou < D >

Avec la version 0.76 on a
avec <1>
0 From Throttle : 1
0 Message From Throttle :
Throttle 0 <1>
<1> parse command
DCCpp PowerOn
<p1>

- avec un reset :

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1216
ho 0 tail 12 room 4
load:0x40078000,len:9720
ho 0 tail 12 room 4
load:0x40080400,len:6352
entry 0x400806b8
LaBox 0.7.6
Server IP address: 192.168.4.1 (Locoduino LaBox) connected ! connectWifi achieved.
Ino executing on core 1
Throttles command receivers executing on core 0
begin achieved
Signal started for Main track on pin 33
Main track DCC ESP32 started.
beginMain achivied with pin 33
*** DCCpp LIBRARY ***
VERSION DCC++:      2.0.0
VERSION DCCpp library: 1.4.1
COMPILED:     Dec  9 2020 11:30:24
   ENABLE(PWM): 32
   CURRENT: 36
Throttles ------------------
0 : Serial
1 : ThrottleWifi: Z21 - 1  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
2 : ThrottleWifi: Z21 - 2  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
3 : ThrottleWifi: Z21 - 3  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
4 : ThrottleWifi: WiThrottle - 1  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
5 : ThrottleWifi: WiThrottle - 2  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
6 : ThrottleWifi: WiThrottle - 3  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le décembre 11, 2020, 05:57:13 pm
Si, si, LaBox répond à la commande <s >, tout comme DCCpp et DCC++. Dans la dernière version 0.7.8 poussée en début de semaine, elle dit même qu'elle est LaBox et non plus DCCpp, pour peu que USE_THROTTLES soit activé...

nb : un espace ajouté devant >
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le décembre 11, 2020, 06:41:47 pm
Effectivement, autant pour moi, avec LaBox 076 :
ci-dessous les réponses respectivement à <1>,   <0>,   <s >,  <D> et enfin <1> :

0 From Throttle : 1
0 Message From Throttle :
0 Message From Throttle :
Throttle 0 <1>
<1> parse command
DCCpp PowerOn
<p1>
0 From Throttle : 0
0 Message From Throttle :
0 Message From Throttle :
Throttle 0 <0>
<0> parse command
DCCpp PowerOff
<p0>
0 From Throttle : s
0 Message From Throttle :
0 Message From Throttle :
Throttle 0 <s >
<s > parse command
<p1>
<iDCCpp LIBRARY BASE STATION FOR ARDUINO : V-2.0.0 / Dec 11 2020 18:27:49>
<N ETHERNET :0460460460><X><X>
0 From Throttle : D
0 Message From Throttle :
0 Message From Throttle :
Throttle 0 <D>
<D> parse command

Entering Diagnostic Mode...
Signal stoppedfor Main track on pin 33
Signal started for Main track on pin 33
0 From Throttle : 1
0 Message From Throttle :
0 Message From Throttle :
Throttle 0 <1>
<1> parse command
DCCpp PowerOn
<p1>


Nota, j'ai du ajouter quelques espaces avant > de <s > pour éviter de voir mon texte barré.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: DDEFF le décembre 11, 2020, 07:29:47 pm
Bonsoir,

J'avoue être largué.
Vous répondez à Lillian.A ou à moi ?

On ne peut pas lancer une commande vers LaBox avec le port série ?
On ne peut pas envoyer "power on <1>" ?

Denis  :o
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le décembre 11, 2020, 09:00:33 pm

On voit ci-dessus les réponses de LaBox  respectivement à <1>,   <0>,   <s >,  <D> en texte intégral. ( parse command = commande analysée )
C'est bien avec le serial monitor que ces commandes sont envoyées et les réponses reçues.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Lilian.A le décembre 12, 2020, 02:00:39 pm
Bonjour

 :D j'ai souvent tort d'avoir raison trop tôt ... ::)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le décembre 18, 2020, 08:28:13 pm
Bonjour

Encore une nouvelle version, la 0.7.9 :

- Ajout de la possibilité de ne pas répéter les paquets DCC des fonctions, notamment parce que certains programmes ou throttles le font déjà (JMRI...). Ca passe par l'appel d'une fonction   
DCCpp::setResendFunctions(false);  Par défaut, la répétition est activée.
- La possibilité de répondre aux Throttles connectées pouvait être bloquée par la fonction DCCpp::setReplyToCommands(false); mais cette fonction ne fonctionnait pas. Elle a été corrigée, et le nom est passé de DontReply à ReplyToCommands pour enlever la négation et permettre de mieux comprendre son rôle.
- Une Throttle déclarée mais qui n'appelait pas son begin() plantait toute la centrale. Ce n'est plus le cas. Et la fonction Throttles::printThrottles() signale les Throttles non activées par leur begin().
- Pour une meilleure compréhension du modèle objet, je me suis permis de renommer certains sources du Hmi : HmiInterface.cpp est devenu hmi.interface.cpp, tandis qu'à l'inverse HmiInterfaceBase.cpp est devenu HmiInterface.cpp. Pourquoi ? Parce toute la classe hmi est ainsi décrite par des sources qui commencent par "hmi.", et toute la classe HmiInterface est contenue dans des sources qui commencent par 'HmiInterface.' ! Bien entendu, si Cédric tu n'es pas d'accord, fais le moi savoir. Au passage quelques warnings de compilation ont été supprimés dans Hmi.

Voilà pour cette fois.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le décembre 18, 2020, 10:15:36 pm
Merci, ok pour moi.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le décembre 22, 2020, 12:20:59 pm
Pour les amateurs de O ou de G on a déjà signalé l'intérêt du module à BTS7960B.
Le composant est donné pour 43A, ce qui n'est pas totalement incohérent mais pousse le composant sur le module au delà des limites :
J'évalue le radiateur à une résistance thermique de 5°C/W
La dissipation pour 40A sur 7+9 mohm = 22W soit 110°C d'élévation
Néanmoins, il y a de la marge par rapport au L6203, et il est toujours possible d'en surveiller la température.

Ce module a été utilisé par Antoine pour sa souris sans fil : https://www.locoduino.org/spip.php?article237
Pour LaBox, l'idée retenue a été de l'utiliser comme booster complémentaire avec la réalisation de Dave Bodnar :
http://www.trainelectronics.com/DCC_Arduino/DCC_Booster/ qui fonctionne parfaitement moyennant une petite correction.
mais dans ce cas, la détection d'adresse sur la voie principale ne fonctionne bien sur pas.

Sur LaBox, si on renonce à cette possibilité il est possible de remplacer le L6203 par un module à BTS7960B. La mesure de courant de ce module comporte un seuil qui rend la détection des 60 mA pour la lecture d'adresse très problèmatique.
Sur la photo jointe on voit
les fils gris reliés à IN1 et IN2 (signaux DCC inversés)
le fil noir au GND
le fil rouge à EN (ENABLE)
le fil blanc à Isense qui permet la détection de C/C (une résistance de 2Kohm donne une sensibilité de ~0.25V/A qui avec le gain de 4 du LM358 conduit à 1V/A prévu par le programme de LaBox). Ce dernier point est encore à expérimenter compte tenu du seuil du module et en particulier si on veut dépasser les 3A.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: CATPLUS le décembre 22, 2020, 01:39:02 pm
Bonjour
Avec les modifications de Michel, j'ai fait le montage et utilise la puissance du Booster Digitrax ref PS2012E
J'attends une machine en O pour confirmer

Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: fcot2002 le décembre 22, 2020, 08:21:17 pm
Bonsoir

J'attends une machine en O pour confirmer

J'arrive   8) 8) 8)
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Paul le décembre 30, 2020, 02:57:04 pm

après cette description, il serait super si vous pouviez donner votre avis, si vous souhaitez acquérir LaBox et dans quel environnement l'utiliserez-vous.

Suite aux messages de Dominique (page 23 de ce sujet), je me suis lancé dans la construction...

Je voudrais d'abord remercier les contributeurs pour la qualité extrêmement élevée de ce projet.
C'est à mon sens vraiment remarquable et je pense qu'il faut vraiment le souligner.

Ceci dit, je donne ci-après un résumé du parcours jusqu'à  présent.

La chasse aux composants:
J'ai essayé d'éviter au maximum les vendeurs chinois qui vendent directement sur ebay, pricipalement vu les délais et le caractère aléatoire des livraisons.
J'ai en définitive acheté les composants principaux (ESP32, OLED, CAN, alimentation) sur amazon.fr. Avantage: livraison gratuite en Belgique (et en France) à partir de 25€ pour les articles expédiés par amazon, délais assez courts et respectés. Prix relativement concurrentiel mais souvent il faut acheter plus qu'un exemplaire (inconvénient ou avantage ? )
Pour l'ESP32, j'ai rencontré plusieurs modèles un peu ou beaucoup différents de celui utilisé ici. Points d'attention: VROOM-32D , 2x 19 connections , pas de trous de fixations qui rendent la plaquette plus longue. Pour l'alimentation j'ai cherché un modèle 5V fixe sans ajustable sur la carte, mais en fait ceux avec ajustables conviennent apparement aussi.
Pour le L6203  chez le vendeur français indiqué au départ même si les frais de port sont (beaucoup) plus élévés pour la Belgique.
Pour la plupart des autres composants : TME: service impeccable, livraison DHL express en 24h pour 7€.
Pour la carte: jlcpcb: service et qualité impeccable, livré en 21 jours, prix défiant toutes concurrences
Finalement j'ai seulement commandé les boutons poussoirs via ebay / Chine. Résultat: j'ai reçu les capuchons en une semaine et les boutons eux-mêmes devraient arriver avant le 2 mars (2021?). C'est le seul composant qui manque pour commencer le montage.
Finalement le coût total des composants utilisés: environ 40€ sans tenir compte du prix des composants restant qui augmentent évidemment ma dépense totale.

Le montage

Les explications de Dominique à la page 23 sont très claires, il suffit de suivre soigneusement et tout se monte facilement
Etape 1: j'ai mis R6 = 4.7K comme suggéré et R11 = 1K comme sur le schéma
Etape 2: soudure des CMS sans problème avec la méthode de Dominique. Mes condensateurs 100nF sont à l'écartement 2.54 et pas 5mm: il faut plier les pattes, c'est Ok pas vraiment propre. 
Etape 3: branchement du régulateur: 4.9 V mesurés, pas de réglage disponible. Cela ne semble pas poser de problèmes pour la suite. Pour les barrettes femelles , j'utilise des barrettes standards de 40 , cela se coupe facilement pour faire 19 ou 6 ou 4 ... Le condensateur C9 est polarisé: monter le - vers le haut. Mettre la barette de l'OLED à l'intérieur du cadre. J'ai aussi installé les barrettes femelles pour RX/TX , I2C et les 13 broches extensions à gauche.
Etape 4: rien de particulier, je passe les boutons poussoirs ...
Etape 5: surprise pour l'interface CAN, au dos de la carte les indications sont inversées par rapport à la photo. De plus ces indications sont inconsistantes avec celles au recto. Après recherches, ce problème a déjà été souvent rencontré par d'autres et ce sont les indications du verso qui sont fausses : il faut donc bien monter la carte comme indiqué.  Pour l'OLED j'ai ajouté 4 entretoises en nylon de 12 mm avec vis de 2mm. Il faut juste adapter légèrement les 2 trous de droite prudemment avec une mèche de 2.

Installation du soft:
Les instructions sont très claires et tout se passe bien.
L'OLED s'allume. Impeccable.

Premiers tests
J'ai fait quelques tests de base pour valider la construction:
- commande par le serial moniteur via USB: OK
- commande par JMRI via liaison cablée USB: OK
- connection au WIFI à partir d'un smartphone Android: OK
- commande avec Engine Driver sur Android. Il faut introduire manuellement l'adress IP, le port et l'adresse DCC puis cela démarre sans problème.

Je n'ai pas testé Z21, ni le CAN , ni forcémment l'usage de l'interface avec les boutons...

Je vais continuer à explorer.

J'espère que ceci n'était trop long.
Et encore en grand bravo aux créateurs de ce projet.

JP.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le décembre 30, 2020, 04:21:29 pm
Franchement, merci Jean-Paul et ça valait le coup de détailler pour encourager tout le monde à tenter l'aventure  ;D ;D ;D

Je vais mettre à jour la page 23 pour tenir compte de tes remarques (à force de regarder je ne suis pas aperçu du cas des connecteurs Can...)
Très important l' ESP32 - VROOM 32D
Je ferai aussi une variante de la BOM (c'est vrai que les composants en trop enchérissent un peu la centrale, mais en général, il servent dans d'autres projets et nous avons cherché à utiliser des composants classiques, autant que possible).
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: fcot2002 le décembre 30, 2020, 07:29:13 pm
Bonsoir @ tous,
Merci de cet excellent retour d'expérience.
Titre: Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le janvier 01, 2021, 03:24:04 pm
Etape 5: surprise pour l'interface CAN, au dos de la carte les indications sont inversées par rapport à la photo. De plus ces indications sont inconsistantes avec celles au recto. Après recherches, ce problème a déjà été souvent rencontré par d'autres et ce sont les indications du verso qui sont fausses : il faut donc bien monter la carte comme indiqué.  Pour l'OLED j'ai ajouté 4 entretoises en nylon de 12 mm avec vis de 2mm. Il faut juste adapter légèrement les 2 trous de droite prudemment avec une mèche de 2.
Bonjour Jean-Paul et bonne année 2021  ;D

Je ne comprends pas bien la surprise à l'étape 5 : il faut bien respecter la sérigraphie sur le PCB : du haut en bas : L =  CanL, H = CanH, R=CRx, T=CTx, G=Gnd, 3=3V3, donc les composants de cette carte sont en dessous, et non au dessus comme on pourrait le penser (je me suis fait piéger 2 fois). Il n'y a pas d'erreur  ;D

Pour la fixation de l'écran OLED, j'kai trouvé une astuce : au lieu d'une entretoise de 2mm de diametre (difficile à approvisionner), je soude une queue de led (rigide) entre le pcb et l'Oled sur 2 points seulement, à droite de l'écran : ça suffit  ;D

(https://www.locoduino.org/IMG/jpg/laboxmediahq.007.jpg)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Paul le janvier 01, 2021, 05:43:39 pm

Bonjour et meilleurs voeux pour 2021 !!!

Le problème est avec les cartes CAN que j'ai reçues: dans cette série de cartes , la même position est indiquée CANL sur la face composant mais 3V3 sur l'autre face , ce qui impossible et inconsistent.
Les infos trouvées sur le net indiquent qu'il s'agit bien d'une erreur de sérigraphie sur la face sans composants.

Il faut donc bien monter la carte composants en-dessous comme prévu mais on voit alors les inscriptions fausses: la position la plus haute est bien le CANL même si on voit 3V3 !

Pour les entretoises, on peut en trouver par exemple ici : https://www.amazon.fr/Entretoise-Entretoises-Femelle-Assortiment-Rangement/dp/B07LFX31JM

Amicalement.
JP.
Titre: Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Paul le janvier 04, 2021, 03:06:46 pm
Je n'ai pas testé Z21, ...

Bonjour,

J'ai installé Z21 mobile sur Android. Se connecte sans problème à Labox. Il faut évidemment introduire manuellement les locos et leurs adresses.
J'ai trouvé cette app nettement plus agréable à utiliser que Engine Driver.

Sur Google Play (https://play.google.com/store/apps/details?id=vivid.planet.roco) on trouve 'Z21 mobile' qui correspond aux écrans de la page 23. Et qui ne semble plus être maintenue par Roco depuis 2017 et plus présente sur le site https://www.z21.eu

On trouve aussi une app 'Z21' (https://play.google.com/store/apps/details?id=eu.z21.app) plus récente, (beaucoup) plus lourde et pas compatible avec d'anciennes versions d'Android. Je n'ai pas essayé. Pourrait-elle être compatible ave Labox? Est-elle aussi présente sur iphone ?

JP.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le janvier 04, 2021, 03:17:12 pm
Bonjour, et meilleurs vœux aussi !

L'appli en question fonctionne aussi avec LaBox. En fait je n'ai pas trouvé d'appli Z21 (Roco, Fleischmann, Digitrains, Locotouch) qui ne marche pas. Les seules à refuser de se connecter sont LocoMotive, mais parce que son fonctionnement impose le bluetooth, et RtDriveDcc++ qui est censé fonctionner avec des commandes textes DCC++ mais qui refuse de se connecter... Tout ça sur Android, je n'ai pas tout testé sur iPhone...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le janvier 04, 2021, 05:18:36 pm
Bonjour et bonne année LaBox !

J'ai mis à jour le schéma (inversion de R1 et R2) et l'implantation correspondante (ne pas tenir compte des anneaux de couleurs sur les résistances) : sur la page 23 qui est à jour !
(https://www.locoduino.org/IMG/jpg/laboxmediahq.003.jpg)

R6 à 4,7K donne une meilleure luminosité des leds DCC, mais chacun adaptera en fonction de ses types de leds.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Paul le janvier 10, 2021, 11:04:55 pm
En ce qui concerne les boutons poussoirs, en l'absence chez moi du modèle prévu '6 pattes', il est parfaitement  possible d'utiliser les petits boutons '4 pattes' très courants, ils se montent sans problèmes, il faut juste ajouter un petit pontage au dos entre la patte non connectée et le GND. Et cela marche parfaitement.
C'est évidemment moins joli, surtout par rapport au montage éventuel en boitier, mais cela dépanne.

Amicalement

Jean-Paul.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le janvier 10, 2021, 11:25:03 pm
Tout à fait d'accord,
mon premier proto était équipé de boutons de ce genre et j'avais aussi fait un pontage à partir du schéma.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le janvier 10, 2021, 11:56:57 pm
De fait, la version 0.1 de LaBox offrait la possibilité de choisir entre les deux versions de boutons avec des pontages optionnels.
On avait également la possibilité de monter l'afficheur verticalement et les boutons horizontalement (voir plus haut dans ce fil)
En l'absence de réactions et vu la facilité de réaliser les ponts, ils n'ont pas été conservés sur la version 0.3

Mais ces boutons 6x6 sont adaptables sur cette version, de plus, ils sont effectivement disponibles en France jusqu'en 18 mm :
https://www.ebay.fr/itm/BP-CI-6x6mm-Tactile-Tact-Push-Button-Micro-Switch-plusieurs-hauteurs-dispo/142532577189

Pour une mise en boite correcte, il faut les prendre avec une tige de 18-20mm. Cette tige longue les rend fragiles et il faut que le trou dans le boitier maintienne le capuchon de la tige latéralement.
Les boutons 8x8, rehaussés sur des supports tulipe sont plus robustes et tombent bien par rapport à la surface supérieure du boitier.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: fcot2002 le janvier 16, 2021, 02:57:37 pm
Hello la cie  8) 8) 8)

Alors la vidéo du test avec machine en O avec le booster à CatPlus.

Je vais tester ici avec mon alim. Projet très très prometteur.

Le seul bémol actuel : La Box se prend les pieds dans le tapis avec les fonctions (sifflets lumières etc. etc.) Marcel vous en dira plus. Réponse venue : pas encore installé.

https://youtu.be/hYWjtz8qQIk (https://youtu.be/hYWjtz8qQIk)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le janvier 16, 2021, 03:47:49 pm
Thierry l’a déjà expliqué: selon les décodeurs, certaines fonctions sont de courte durée et doivent être commandées On puis Off, d’autres sont permanentes comme les phares.
Le logiciel de LaBox n’est pas complet, terminé et testé sur les fonctions des décodeurs. Pour les lumières la fonction est permanente mais pour les autres cela dépend du throttle (JMRI ou engine driver).

Comme je l’ai dit ce matin à Marcel, l’expression “LaBox se prend les pieds” n’est pas très parlante comme diagnostic !

Patience: c’est pas simple  ;D
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: CATPLUS le janvier 16, 2021, 03:58:20 pm
Bonjour,

Cette locomotive échelle "O" de marque MTH est relativement lourde, les tests avec La Box seule n'ont pas pu être fait.

J'ai ajouté  un Booster  pour plus de chevaux voir le post de Dave Bodnar et de MSPORT plus haut

http://www.trainelectronics.com/DCC_Arduino/DCC_Booster/

Cela fonctionne parfaitement. Lors de nos essais un problème à surgi l'utilisation des touches de fonctions (sons en général) lors de l'appui sur la cloche c'était le sifflet, etc... tout était mélangé. La seule fonction opérationnelle  F0 On/Off de la lumière.

Suite à mon entretien avec Dominique, il semble que cela soit normal (même si cela est Anormal) pour le moment le soft n'est pas encore en adéquation avec la demande (mise à jour).

Je vais faire un tableau via Excel avec les fonctions et le transmettre à qui de droit ;)

Un plus La Box fonctionne avec toutes les Echelles

Quoi qu'il en soit c'est un bon produit (bravo de l'avoir fabriquer) et le faire évoluer.



Titre: Vitesse max : 126 ou 127
Posté par: Jean-Paul le janvier 16, 2021, 04:49:55 pm
Bonjour,

J'ai remarqué que, avec Z21 Mobile, l'app envoie le cran 127 quand on va au maximum. Et la loco s'arrête ...
Dans le même cas JMRI envoie 126.

Dans RegisterList::setThrottle(int nReg, int cab, int tSpeed, int tDirection) , on a :
b[nB++] = tSpeed + (tSpeed>0) + tDirection * 128;   // max speed is 126, but speed codes range from 2-127 (0=stop, 1=emergency stop)
Ce qui résulte en '0' si tSpeed = 127.

Je préfererais avoir
 if (tSpeed > 126) tSpeed = 126 ;
juste avant pour se protéger de tout débordement quelque soit le comportement des throttles.

Amicalement.

Jean-Paul

Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le janvier 16, 2021, 05:36:31 pm

Je vais faire un tableau via Excel avec les fonctions et le transmettre à qui de droit ;)

Bonsoir,

en fait ce sera le tableau des fonctions du décodeur qui pilotent les accessoires de la locomotive.
LaBox est transparente pour la conversion des codes DCC++ en DCC tels que décrits dans la documentation DCC++ :

To set functions F0-F4 on=(1) or off=(0): <f CAB BYTE1 [BYTE2]>

    < = Begin DCC++ command
    f = (lower case f) This command is for a CAB,s function ie: Lights, horn, bell
    CAB: the short (1-127) or long (128-10293) address of the engine decoder
    BYTE1: 128 + F1*1 + F2*2 + F3*4 + F4*8 + F0*16
    ADD the ones you want ON together
    Add 1 for F1 ON
    Add 2 for F2 ON
    Add 4 for F3 ON
    Add 8 for F4 ON
    Add 16 for F0 ON
    128 Alone Turns OFF F0-F4
    BYTE2: omitted
    > = End DCC++ command

Envoi d'un 1 = activation, envoi d'un 0 désactivation (bit par bit)

Mon sniffer masque probablement l'affichage des répétitions, je ne les ai pas vues.

Mais le juge de paix, c'est le moniteur série :
Il suffit d'envoyer la commande <f CAB BYTE1> à la locomotive suivant le calcul ci-dessus et voir le résultat.


Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: fcot2002 le janvier 18, 2021, 10:50:15 am
Bonjour @ tous,

Merci des précisions concernant les fonctions. @Dominique j'ai employé le terme "humoristique" sachant que tout n'était pas terminé   ;) ;) ;)

Voici les paramètres de l'alimentation DCC que j'utilise avec ma centrale DCC++, pensez-vous que je puisse l'utiliser avec La Box ?

Output : 19,5Volts 4,6Amp  - neg à l'extérieur / + pos à l'intérieur.

Bien @ vous !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le janvier 18, 2021, 12:51:15 pm
Bonjour,
alimentation 19,5V : ça dépend du step-down ->5V acheté : mais je n'en ai pas vu qui tienne moins de 23V.
Si on n’attrape pas de cloque en mettant le doigt dessus, ça devrait être Ok.
Ampérage : ce n'est pas LaBox qui consomme, c'est les locos et il y a une protection contre les surcharges.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le janvier 18, 2021, 01:43:22 pm
Il faut sûrement un radiateur et surtout remonter au maximum la mesure de tension de court-circuit qui est actuellement aux alentours de 1A !. Normalement avec 1v/A il n’est pas possible de depasser 3,3A à moins de réduire le gain de l’aop.
A l’heure actuelle ca ne doit pas être possible. Il va falloir inventer quelque chose.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le janvier 18, 2021, 02:32:57 pm
Le booster est externe à LaBox, c'est à lui de protéger contre les courts-circuits.

Sinon pour pousser le LM6203 à 2A, on peut remplacer R3 (33K) par une 10K (G=2 au lieu de 4). Mais la lecture des CV risque d'être problématique.
Titre: Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Paul le janvier 18, 2021, 03:13:08 pm
...
LaBox est transparente pour la conversion des codes DCC++ en DCC tels que décrits dans la documentation DCC++ :
....
Il suffit d'envoyer la commande <f CAB BYTE1> à la locomotive suivant le calcul ci-dessus et voir le résultat.
....

Vérifié chez moi pour toutes les fonctions F0 à F28 (une à la fois).
- activation de la fonction dans JMRI sur PC
- commande DCC vue dans le 'DCC traffic monitor' de JMRI
- affichage sur l'écran de LaBox (lumière pour F0 , 1 à 28 pour les autres fonctions)
- décodage du signal DCC dans mon sniffer
A chaque fois les 4 sont parfaitement alignés.

Amicalement.
Jean-Paul.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: fcot2002 le janvier 18, 2021, 05:23:05 pm
Bonsoir,

Il faut sûrement un radiateur et surtout remonter au maximum la mesure de tension de court-circuit qui est actuellement aux alentours de 1A !. Normalement avec 1v/A il n’est pas possible de depasser 3,3A à moins de réduire le gain de l’aop.
A l’heure actuelle ca ne doit pas être possible. Il va falloir inventer quelque chose.

Ok wait and see comme ils disent. Sinon je vais déjà tester avec les 3.3A. C'est ce que j'ai sur ma centrale avec le shieldmotor classique. Je peux tester le roulement et toutes les fonctions, y compris fumigène, mais limiter la vitesse à 50% après.... c'est le drame :o :o :o
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le janvier 18, 2021, 06:23:29 pm
Attends un peu François,

Il faut générer une nouvelle version officielle de Labox avec une valeur de inSampleMax = 4000 (pour 3,22A) au lieu de 800 (0,65A)
C'est dans CurrentMonitor.h, ligne 40 :

void begin(int pin, int inSignalPin, const char *msg, float inSampleMax = 800);
Mais il faut l'aval de Thierry !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le janvier 18, 2021, 08:26:10 pm
Non, pas besoin d'une version pour ça. Il suffit d'ajouter une ligne au setup de labox.ino avec DCCpp::setCurrentSampleMaxMain(4000);
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: fcot2002 le janvier 20, 2021, 10:21:03 am
Bonjour

OK je modifie la ligne setup comme indiqué. Je ne pourrai tester avant ce week-end par contre.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Paul le janvier 24, 2021, 05:50:22 pm
Bonjour,

Si comme moi, vous désirez protéger l'AP WiFi en ajoutant un mot de passe, il faut prévoir au moins 8 caractères ! Un mot de passe trop court empêche LaBox de démarrer..

dans labox.ino
const char* password = "";                     // OK, WiFi ouvert
const char* password = "1234";             // ne marche pas
const char* password = "123456789";   // ok

Amicalement
Jean-Paul
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le janvier 29, 2021, 02:34:16 pm
Merci pour cette contribution à mettre dans le mode d'emploi (pas encore écrit .. un volontaire ?)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le janvier 29, 2021, 10:34:01 pm
Bonjour,
(en espérant ne pas déranger)
quels sont le principes retenus pour la planification, en fonction de leur nature, de l'envoi des pakets dcc (priorité, redondance, cycle ...) ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le janvier 29, 2021, 11:17:47 pm
Ce sera Thierry qui dira mais la réponse est certainement à rechercher chez Gregg E. Berman qui a conçu DCC++.

La question qui a déjà été évoquée est la répétition des commandes reçues, typiquement vitesse et sens, ainsi que l'éclairage pour éviter que la moindre perte de contact arrête ou éteigne une locomotive qui n'a pas de stay-alive.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le janvier 30, 2021, 05:11:22 am
merci, je vais jeter un coup d'oeil (si je peux comprendre ce qu'il a voulu faire)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le janvier 30, 2021, 09:55:32 am
Et aussi les normes NMRA que Gregg E. Berman a respecté au mieux.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le janvier 30, 2021, 10:40:21 am
Bonjour,

C’est effectivement une question utile dont la réponse sera dans la future doc avec des conséquences sur les performances du bus DCC.

Les commandes DCC sont placées dans des registres d’où elles sont extraites et émises sous interruption.
Les commandes de vitesse et direction sont répétées automatiquement à partir d’un registre dédié à cet effet. Les autres commandes (fonctions des locos et accessoires) ne sont normalement pas répétées.

Mais une couche « locomotives » a été ajoutée dans LaBox et DCCpp pour ajouter des comportements spécifiques : les commandes des lumières sont maintenant répétées.
Pour les autres commandes c’est plus compliqué du fait que certaines se sont que fugitives et d’autres permanentes. Par exemple avec JMRI, c’est gèré dans JMRI. L’interface « locomotives » le permettrai aussi dans LaBox moyennant un peu de développement.

Thierry confirmera ces explications ou les corrigera si je me trompe  ???
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le janvier 30, 2021, 01:23:58 pm
ça se clarifie pour moi
les fonctions lumières, je n'y avais pas pensé - merci - ; pour les autres fonctions, je m'en tiendrai à laisser le job des répétitions si besoin, à la couche au-dessus (en dehors)
hs
limiter les messages à 11 trains permet une répétition en fréquence + que satisfaisante des pakets ; en fait, la centrale que je projette sera avec un esp32, donc je m'affranchirai totalement des contraintes liées à la compatibilité avec les avr ; de 11 je pourrais allègrement passer à 256, ce qui demanderait un planificateur + costaud ; mais d'une part, 11 trains en marche ça doit suffire pour + de 99% des réseaux ... et d'autre part, la modestie de ma centrale fait qu'un planificateur simple (mais efficace) conviendra très bien
hs\
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 06, 2021, 03:08:30 pm
Parlons du CAN


J'avais testé le bus Can de l"ESP32 en me servant de la carte LaBox qui contient son intterface : un simple circuit SN65HVD230 de Texas que l'in trouve sur des petites cartes CJMCU-230 entre 5 et 6 €.
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3684;image)
Le programme de test est joint ci-dessous : "Can-test-Jan-21"
Et la discussion initiale ici : https://forum.locoduino.org/index.php?topic=1140.msg12284#msg12284 (https://forum.locoduino.org/index.php?topic=1140.msg12284#msg12284)
Comme ciible de test j'avais utilisé une carte satellite V1 programmée avec son logiciel d'origine que l'on trouve sur le Git Locoduino, dans le dossier Locoduinodrome : https://github.com/Locoduino/Locoduinodrome (https://github.com/Locoduino/Locoduinodrome)
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3686;image)
Le fil noir sert à exciter les entrées des détecteurs ponctuels.

Ensuite j'ai réalisé un programme de test en combinant la version LaBox-078 et un jeu de test consistant à envoyer des commandes de signaux toutes les 2 secondes et à recevoir les messages Can venant du satellite, à savoir : la détection de présence et les 2 détections ponctuelles.
Ce programme est bien évidemment donné ci-dessous : "LaBox-078-TEST_CAN_SATELLITE"
Avec son ID_SAT =  5, ce satellite reçoit sur ID 25 et émet sur ID 15.
Ce programme permet de faire fonctionner simultanément des trains à partir des Withrottle, EngineDriver, Z21 et la petite télécommande radio de msport qui est décrite dans l'article ici : (demain).
Il envoit aussi une suite de commande pour deux signaux : un sémaphore (3 leds); un carré avec rappel de ralentissement (5 leds) et un servo d'aiguillage :
Les 3 octets des messages Can envoyés toutes les 2 secondes sont :
byte jeuTestsSignaux[7][3] = {
  0x20, 0x20, 0x00, //VL1 + VL2
  0x02, 0x20, 0x00, //A1 + VL2
  0x08, 0x80, 0x82, //S1 + RR2 + Devie
  0x02, 0x20, 0x00, //A1 + VL2
  0x20, 0x02, 0x00, //A1 + A2
  0x02, 0x40, 0x01, //A1 + RRc2
  0x08, 0x08, 0x80  //S1 + C2 + devie
};

LaBox est reliée à un port USB pour afficher les messages dans le moniteur de l'IDE.
Le satellite est relié à un autre port USB et j'utilise un émulateur de terminal pour visualiser ce qui en sort.

Jusque là, vous me suivez ?

Bon, les résultats :


J'ai 4 cartes LaBox équipées et 5 cartes CJMCU-230 qui, je le rappelle, ne contiennent que l'ampli de ligne en 3,3V : SN65HVD230.

Mes 4 cartes Labox fonctionnent avec ce test mais avec UNE SEULE des cartes CJMCU-230 !
Avec les 4 autres cartes le bus CAN ne transmet rien (le satellite ne reçoit rien) et le fonctionnement de LaBox est perturbé (possibilité de connecter un Throttle Wifi, mais impossible de sélectionner une adresse DCC donc pas de commandes DCC)

Ca ne va pas plus loin que :
4 From Throttle : NiPhoneDB
4 From Throttle : HUBDE241D3-07EA-4A60-BD6B-EE19
4 From Throttle : MT+S18<;>S18
4 From Throttle : MT-S18<;>r
4 From Throttle : MT+S18<;>S18
4 From Throttle : MT-S18<;>r
4 From Throttle : MT+S18<;>S18

au lieu de :
4 From Throttle : NiPhoneDB
Throttle 4 NiPhoneDB
4 -> *10
4 From Throttle : HUBDE241D3-07EA-4A60-BD6B-EE19
Throttle 4 HUBDE241D3-07EA-4A60-BD6B-EE19
4 From Throttle : *+
Throttle 4 *+
envoi 0 0x20 0x20 0x0
recu de 21 : 0x0
envoi 1 0x2 0x20 0x0
recu de 21 : 0x0
4 From Throttle : MT+S18<;>S18
Throttle 4 MT+S18<;>S18
4 -> MT+S18<;>
4 -> MTAS18<;>F00
4 -> MTAS18<;>F01
4 -> MTAS18<;>F02
4 -> MTAS18<;>F03
4 -> MTAS18<;>F04
4 -> MTAS18<;>F05
4 -> MTAS18<;>F06
4 -> MTAS18<;>F07
4 -> MTAS18<;>F08
4 -> MTAS18<;>F09
4 -> MTAS18<;>F010
4 -> MTAS18<;>F011
4 -> MTAS18<;>F012
4 -> MTAS18<;>F013
4 -> MTAS18<;>F014
4 -> MTAS18<;>F015
4 -> MTAS18<;>F016
4 From Throttle : *
4 -> MTAS18<;>F017
4 -> MTAS18<;>F018
4 -> MTAS18<;>F019
4 -> MTAS18<;>F020
4 -> MTAS18<;>F021
4 -> MTAS18<;>F022
4 -> MTAS18<;>F023
4 -> MTAS18<;>F024
4 -> MTAS18<;>F025
4 -> MTAS18<;>F026
4 -> MTAS18<;>F027
4 -> MTAS18<;>F028
4 -> MT+S18<;>V0
4 -> MT+S18<;>R1
4 -> MT+S18<;>s1
Locomotives ------------------
0 : Loco reg:1 id:18 max:128      +/-speed:0      functions:
Throttle 4 *
4 -> *10
envoi 2 0x8 0x80 0x82
recu de 21 : 0x0
envoi 3 0x2 0x20 0x0
recu de 21 : 0x0
4 From Throttle : *
Throttle 4 *
4 -> *10
envoi 4 0x20 0x2 0x0
recu de 21 : 0x0
envoi 5 0x2 0x40 0x1
recu de 21 : 0x0
4 From Throttle : *
Throttle 4 *
4 -> *10
envoi 0 0x20 0x20 0x0
recu de 21 : 0x0
envoi 1 0x2 0x20 0x0
recu de 21 : 0x0
où l'on voit la connexion de Withrottle et les messages émis et reçus

Diagnostic :

Ce sont les cartes CJMCU-230 qui posent problème : une seule fait que l'ensemble fonctionne bien et les 4 autres perturbent l'ESP32.

J'aimerai savoir si, parmi ceux qui ont monté LaBox, vous avez pu tester la connexion Can. Attention, pour ne pas mettre le circuit à l'envers, le SN65HVD230 doit se trouver du coté de la carte LaBox.
Je ne m'attends pas à beaucoup de réponses mais vous avez tout ce qu'il faut maintenant pour le faire et je vous en remercie d'avance.
Je vais donc commander d'autres  CJMCU-230 auprès d'autres fournisseurs.

Autre anomalie :


J'ai constaté qu'à la mise en route du couple LaBox + Satellite (avec la bonne carte CJMCU-230) , les messages Can envoyés ne sont pas ceux du jeu de test, par exemple, vu coté satellite :
Rid: 25 0x0 0x20 0x0 nor
Rid: 25 0x0 0x2 0x0 nor
Rid: 25 0x0 0x20 0x0 nor
Rid: 25 0x0 0x2 0x0 nor
Rid: 25 0x0 0x20 0x0 nor
Rid: 25 0x0 0x2 0x0 nor
Mais dès qu'un Throttle est correctement connecté, le test Can redevient normal. Cela vient peut-être du logiciel LaBox.
Mais le lendemain, tout fonctionne bien : je ne sais pas ce qu'il s'est passé : espoir !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: simontpellier le février 06, 2021, 04:47:15 pm
Bonjour Dominique (c'est presque un message privé...)

Cette semaine, je cherchai un transceiver CAN pour interfacer non un ESP32 mais un TEENSY, ce qui ne change rien sur le fond.
Le souci que tu rencontres avec les CJMCU-230 n'est pas isolé, il y a des cas sur d'autres forum (mais tout de même, 1/5 c'est pas banal !)
(D'après ce que j'ai lu, le problème serait fonction du débit : https://esp32.com/viewtopic.php?t=380&start=170 )

Parce que j'étais impatient et avec le sentiment probablement illusoire d'un risque moindre, j'en ai trouvé UN (le dernier !) chez un vendeur France, relativement pas cher, toujours très rapide : commandé jeudi reçu ce midi : https://www.ebay.fr/itm/CJMCU-230-module-communication-%C3%A9metteur-r%C3%A9cepteur-bus-CAN-SN65HVD230-1345Z/293132899616?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2648

Pas de DCC ni donc de LaBox dans mon cas, je ne pourrai donc pas apporter de réponse à ta question.
Mais c'est moi qui en ai une ! Je ne peux pas utiliser ton code pour tester mon module. Mais y aurait-il un test tout simple, un test "de paillasse", qui distingue celui qui marche des 4 autres ? Car il serait trop beau que l'adaptation du code ne réserve pas aussi des surprises et alors comment savoir !
Si tu as une idée, merci d'avance !

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le février 06, 2021, 05:25:43 pm
Concernant ces petites cartes CJMCU-230, je me souviens avoir lu quelque part que la sérigraphie était inversée entre deux pins... Se pourrait-il que ce marquage soit quelquefois vrai, selon le fournisseur ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le février 06, 2021, 07:20:44 pm
Utilisez un MCP2562. Il est moins cher que ce module et il fonctionne  :)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 06, 2021, 08:17:06 pm
Merci pour la réponse : il est moins cher et son brochage est proche de celui du SN65HVD230. Je peux en trouver en France rapidement et me faire une mini carte sur plaque de pastille pour tester. Heureusement il y a assez de place sur LaBox, au dessus du régulateur 5V.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 06, 2021, 08:20:25 pm
Concernant ces petites cartes CJMCU-230, je me souviens avoir lu quelque part que la sérigraphie était inversée entre deux pins... Se pourrait-il que ce marquage soit quelquefois vrai, selon le fournisseur ?

Vu à la loupe des deux cotés : pas de différence.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 06, 2021, 08:38:47 pm
Bonjour Dominique (c'est presque un message privé...)
Mais y aurait-il un test tout simple, un test "de paillasse", qui distingue celui qui marche des 4 autres ? Car il serait trop beau que l'adaptation du code ne réserve pas aussi des surprises et alors comment savoir !
Si tu as une idée, merci d'avance !

Tu sais, en général je pars des exemples fournis avec la bibliothèque et je les bricole pour faire un test rapidement. Le plus simple (selon moi) est de commencer par faire un récepteur-emetteur (qui réémet tout ce qu'il reçoit, voire en modifiant au passage)  avec un Nano et une carte comme expliqué dans l'article sur ACAN de Jean-Luc. Il faut toujours avoir ce truc dans un tiroir. Moi j'ai un Nano avec une écran LCD et une carte Locoduino. Malheureusement en CAN tu ne peux pas relier CANH et CANL, ça ne marche pas.
Titre: Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le février 06, 2021, 09:05:17 pm
Concernant ces petites cartes CJMCU-230, je me souviens avoir lu quelque part que la sérigraphie était inversée entre deux pins... Se pourrait-il que ce marquage soit quelquefois vrai, selon le fournisseur ?

Vu à la loupe des deux cotés : pas de différence.

Et on trouve bien une 120ohms entre CANH et CANL sur les quatre cartes que j'ai.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le février 06, 2021, 09:16:25 pm
A priori aucune de mes quatre cartes ne fonctionne :
coté satellite :
controleurCAN configuration OK
versionSW 0.1 17 Janvier 2021message envoyé
message envoyé
message envoyé
message envoyé
message envoyé
echec de l'envoi 
echec de l'envoi 
echec de l'envoi
etc.

coté LaBox :
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1216
ho 0 tail 12 room 4
load:0x40078000,len:9720
ho 0 tail 12 room 4
load:0x40080400,len:6352
entry 0x400806b8
LaBox 0.7.9
Server IP address: 192.168.4.1 (Locoduino LaBox) connected ! connectWifi achieved.
Ino executing on core 1
Throttles command receivers executing on core 0
begin achieved
Signal started for Main track on pin 33
Main track DCC ESP32 started.
beginMain achivied with pin 33
ESP32 CAN - LaBox + Satellite V1
*** LaBox LIBRARY : 0.7.9
VERSION DCC++     : 2.0.0
COMPILED          : Feb  6 2021 17:17:16
   ENABLE(PWM): 32
   CURRENT: 36
Throttles ------------------
0 : Serial
1 : ThrottleWifi: Z21 - 1  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
2 : ThrottleWifi: Z21 - 2  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
3 : ThrottleWifi: Z21 - 3  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
4 : ThrottleWifi: WiThrottle - 1  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
5 : ThrottleWifi: WiThrottle - 2  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
6 : ThrottleWifi: WiThrottle - 3  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
envoi 0 0x20 0x20 0x0
envoi 1 0x2 0x20 0x0
envoi 2 0x8 0x80 0x82 0 From Throttle : 1
0 From Throttle : 1
0 From Throttle : t1 8 0 0
0 Message From Throttle :
0 Message From Throttle :


Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 06, 2021, 11:08:29 pm
Utilisez un MCP2562. Il est moins cher que ce module et il fonctionne  :)

Et en plus j'en ai déjà 10 en cms !
Titre: Re : Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 06, 2021, 11:12:34 pm


Et on trouve bien une 120ohms entre CANH et CANL sur les quatre cartes que j'ai.

Mais alors on n'a pas besoin du strap et de la 120 Ω sur la carte LaBox !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: DDEFF le février 07, 2021, 09:46:32 am
Je ne comprends pas bien : il ne faut une 120 Ω qu'aux deux extrémités.
Donc il faut pouvoir choisir, pour chaque carte, si on met la 120 Ω ou pas.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le février 07, 2021, 10:22:37 am
On peut toujours dessouder la 120 ohms CMS si on veut.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Paul le février 07, 2021, 10:47:29 am
Bonjour,

J'avais déjà testé avec succès, une de mes cartes CJMCU-230 comme expliqué ici https://forum.locoduino.org/index.php?topic=1140.0 avec les programmes de Dominique:
Côté LaBox programme : Can-test-Jan-21 Librairie: https://github.com/miwagner/ESP32-Arduino-CAN
Côté Nano + Can : Test_ACAN_Send-Receive_ID7

Aujourd'hui j'ai soudé les broches sur les autres cartes de mon lot (https://www.amazon.fr/gp/product/B07RDKRRN9).
Résultats :
1. elles fonctionnent toutes
2. la sérigraphie est fausse sur toutes les cartes, il suffit de monter comme prévu sans regarder les inscrptions (voir photo)

J'ai aussi installé le programme LaBox-078-TEST_CAN_SATELLITE sur LaBox sans rien changer côté Nano.

J'obtiens bien la communication

Sur Labox;
envoi 4 0x20 0x2 0x0
recu de 7 : 0x1 0x2 0x4 0x8 0x16 0x32 0x64 0x128
recu de 7 : 0x1 0x2 0x4 0x8 0x16 0x32 0x64 0x128


Sur Nano:
Message envoyé
Message envoyé
Message reçu: 1047
ID: 37 Data:  0x20 0x2 0x0


Indépendemment du contenu des messages, cela prouve en tout cas que les cartes et la communication fonctionnent..

Pour ce qui est de la résistance de 120 ohms, dans cette configuration simple (2 noeuds, un cable téléphonique de 1m) je ne vois pas de différence avec ou sans le jumper sur la carte Labox (?)

Amicalement
Jean-Paul





Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 07, 2021, 03:14:48 pm
Toutefois, il y a ici une contribution interessante pour éviter de changer éventuellement le driver 230 sur cette carte CJMCU230 : connecter la pin RS au gnd pour forcer le mode haute vitesse, à condition que le 230 ne soit pas pourri !

https://esp32.com/viewtopic.php?t=380&start=170#p59173 (https://esp32.com/viewtopic.php?t=380&start=170#p59173)
Citer
Be aware that they are some "FAKE" transceiver based on VP230 (SN65HVD230) !!!

I've lost days with 2pcs CJMCU-230 coming from the same supplier on Aliexpress. They were almost working at low speed (125kb) & only for few seconds at 500kb... Forcing High Speed mode with Rs connected to GND did not help really.

Applying another similar transceiver from Waveshare with same VP230 SN65HVD230 with Rs grounded solved all my troubles. Plugg & run! Smooth ESP32 read & writte at 500kb for hours with heavy REC trafic (Rx_PDO1_20ms, Rx_PDO2_1s, Rx_PDO3_5s, Tx_PDO1_1s)
https://www.waveshare.com/sn65hvd230-can-board.htm

Sur la carte CJMCU-230, le RS est relié au 3,3V via une pull-up de 10K.

J'ai relié RS au GND mais cela ne change rien : aucune transmission donc circuit HS
Je n'ai pas encore essayé à 125kb/s..
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le février 08, 2021, 12:01:26 am
Un extrait de la doc du VP230 : (fait 700K je ne peux pas la joindre, voir google)
On the SN65HVD230 and SN65HVD231, pin 8 provides three different modes of operation: high-speed, slope
control, and low-power modes. The high-speed mode of operation is selected by connecting pin 8 to ground,
allowing the transmitter output transistors to switch on and off as fast as possible with no limitation on the rise
and fall slopes. The rise and fall slopes can be adjusted by connecting a resistor to ground at pin 8, since the
slope is proportional to the pin's output current. This slope control is implemented with external resistor values of
10 kohm, to achieve a 15-V/ms slew rate, to 100 kohm, to achieve a 2-V/ms slew rate. See the Application Information
section of this data sheet.
The circuit of the SN65HVD230 enters a low-current standby mode during which the driver is switched off and
the receiver remains active if a high logic level is applied to pin 8. The DSP controller reverses this low-current
standby mode when a dominant state (bus differential voltage > 900 mV typical) occurs on the bus.
The unique difference between the SN65HVD230 and the SN65HVD231 is that both the driver and the receiver
are switched off in the SN65HVD231 when a high logic level is applied to pin 8 and remain in this sleep mode
until the circuit is reactivated by a low logic level on pin 8.
The Vref pin 5 on the SN65HVD230 and SN65HVD231 is available as a VCC/2 voltage reference.
The SN65HVD232 is a basic CAN transceiver with no added options; pins 5 and 8 are NC, no connection.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 08, 2021, 05:53:56 pm
Tiens je n'ai pas utilisé la version 079 !!

quand le Can marche je vois ceci :
La 1ère ligne est le programme de test
La 2e ligne est la version LaBox

ESP32 CAN - LaBox + Satellite V1
*** LaBox LIBRARY : 0.7.8
VERSION DCC++     : 2.0.0
COMPILED          : Feb  5 2021 18:31:39
   ENABLE(PWM): 32
   CURRENT: 36
Throttles ------------------
0 : Serial
1 : ThrottleWifi: Z21 - 1  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
2 : ThrottleWifi: Z21 - 2  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
3 : ThrottleWifi: Z21 - 3  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  not connected
4 : ThrottleWifi: WiThrottle - 1  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
5 : ThrottleWifi: WiThrottle - 2  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
6 : ThrottleWifi: WiThrottle - 3  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 not connected
envoi 0 0x20 0x20 0x0
recu de 21 : 0x0
envoi 1 0x2 0x20 0x0
recu de 21 : 0x0
envoi 2 0x8 0x80 0x82
recu de 21 : 0x0
envoi 3 0x2 0x20 0x0
recu de 21 : 0x0
envoi 4 0x20 0x2 0x0
recu de 21 : 0x0
envoi 5 0x2 0x40 0x1
recu de 21 : 0x0
envoi 0 0x20 0x20 0x0
recu de 21 : 0x0
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le février 09, 2021, 12:05:42 am
On va tranquillement vers une intégration du MCP2562 sur la carte LaBox.
Tenir compte de ce que sa tension d'alimentation est 5V, et voir les I/O.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 09, 2021, 09:28:05 am
D’après la datasheet, sa tension d’alimentation est de 5V, mais en reliant VIO à 3,3V, il y a une conversion de niveau interne pour les pins TxD et RxD.

Voir figure 1-2

D’ailleurs il vaut mieux que tous les transmetteurs sur un réseau Can soient alimentés en 5v.
Bien que ça marche aussi si certains sont en 3,3v : c’est mon cas chez moi où j’ai un Due en 3,3V qui n’a jamais posé de problème. J’ai déjà expliqué ça ailleurs dans le site.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: simontpellier le février 09, 2021, 08:32:32 pm
A signaler à toutes fins utiles... il semblerait qu'on puisse même se passer tout simplement de transceiver !

https://forum.pjrc.com/threads/43684-CAN-bus-Teensy-Teensy-communication-without-transceiver
https://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 09, 2021, 11:40:33 pm
Citer
CAN sur Teensy,

On n’est plus dans le sujet dédié à LaBox . Peux-tu le déplacer sur un autre sujet relatif au Can ?

On est déjà à 28 pages : Faut pas se disperser !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le février 10, 2021, 06:09:42 pm
Pour info je viens de faire un "panier" sur eBay, principalement avec les liens fournis par Dominique : la plupart fonctionnent encore.
Il y a quelques pièces en rupture de stock mais rien qu'on ne puisse contourner.

Voici une idée du budget achat BRUT, j'entends par là non pas le cout de revient d'une box, mais le cout d'approvisionnement en composants : il faut acheter des lots et bien que l'on utilise que une ou deux unités d'un lot, il faut bien payer le tout au départ, à voir si l'on réutilise le reliquat ensuite.

Cela donnera une idée du budget pour une personne (comme moi) qui n'a pas de stock (enfin sur peu de choses).

En résumé :
65.28 € sur eBay FR de matériel
31.39 € de frais de port (50 % !)
12.27 $ eBay COM

Je n'ai pas inclus dans ce budget les LEDS et les résistances 1/4 W que j'ai effectivement en stock en pagaille.

Donc grosso-modo, il faut compter une 100aine d'€ d'achats ce à quoi il faut ajouter la fabrication et frais de port du PCB.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 10, 2021, 09:00:47 pm
En attendant de recevoir quelques MCP2562 en boitier DIP 8 pattes, j'ai fait un petit schéma pour remplacer la carte CJMCU-230 par une bidouille se branchant sur le même connecteur 6 pattes :

(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3712;image)

Une première remarque : il faudra une patte de plus pour amener le 5V sur le MCP2542, la patte existante 3V3 étant destinée à la pin 5 (VIO) pour le convertisseur interne de niveau.

Heureusement on a un 5V juste à coté sur la carte LaBox.

A un moment j'ai cru possible l'échange du SN65HVD230 par le MCP2562 (!). Et bien non, ce n'est pas possible.

PS: premier essai de EasyEDA pour le schéma. C'est pour ça que ce n'est pas terrible  :-[

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le février 10, 2021, 09:37:37 pm
Pour info je viens de faire un "panier" sur eBay ...

Effectivement plusieurs paramètres entrent en jeu :
- depuis la crise sanitaire, les vendeurs chinois font plus rarement le port gratuit. Les français sont bien sur plus cher.
De plus, ceux qui proposent des prix attractifs, revoient leur tarifs ensuite. Il faut renouveler les recherches avec une partie du libellé pour optimiser.
Les vendeurs british sont maintenant à éviter.
- nous avons donné des liens pour des lots pour optimiser le port et le coût. Pour faire UNE box, il faut revoir le choix des vendeurs ou des lots.
Et élargir la recherche à "Monde entier"

La question de constituer des kits s'est bien sur posée, mais tout le monde comprend que c'est un boulot de romain que les redistribuer, de plus exposé au manque d'expérience des utilisateurs. Mais les bonnes volontés sont encouragées. A noter que chez JLCPCB, c'est le même tarif de un à cinq exemplaires (avec une promo permanente à ~7€). Ce qui peut conduire à prévoir les composants en rapport.
Et donc, en monter cinq exemplaires et les céder pour couvrir ses frais annexes.

Cette description détaillée s'adresse aux amateurs disposant d'une certaine expérience des montages électroniques. Il faut être capable de lire un schéma et de vérifier les implantations.
Et de souder avec une précision certaine, la proximité des pads et des vias doit être soigneusement vérifiée pour éviter des court-circuits.
Cette expérience s'accompagne en général, de l'accumulation des composants standard.
Et au final, certains composants sont facultatifs, remplaçables, voire inutiles :
D3 (Z3.3v),
la diode PROT_INV,
C9, 10µF
R17, une fois évaluée, la remplacer par une résistance fixe.
LED1,2,3,4 seules deux sont utiles.
Bornier : un seul est utile. (3.51 ou 5.08)
La 120 ohms du CAN est déjà sur le module CAN.
2N3904 : n'importe quel NPN fait l'affaire
Le radiateur utile seulement pour la circulation simultanée de plusieurs locomotives en permanence à pleine vitesse (ou de nombreux accessoires DCC)
Attention à la version de l'Oled : bornier dans l'ordre GND, VCC, SCL, SDA
Le boitier (?)

Le choix des fournisseurs, comme plusieurs fois discuté à Locoduino fait intervenir votre gout du risque pour eBay en particulier et certains préféreront les institutionnels comme TME. A noter que Aliexpress semble sélectionner ses vendeurs (mais on les retrouve aussi sur eBay).

12.27$ de COM : de quoi s'agit-il ?

En tout cas bon courage pour le montage !

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le février 10, 2021, 09:43:10 pm
Dans la liste de liens fournis par Dominique, deux références sont sur ebay.com, les autres sur ebay.fr
D'ou les 12$. Le reste est en euros de fait... ;)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le février 10, 2021, 10:01:01 pm
Comme exposé, les liens valent avant tout pour le libellé et la description. Une recherche pour mettre à jour est utile.
Bien sur, il n'est pas question de commander aux États-Unis, ni en Angleterre maintenant.

A noter pour JLCPCB, choisir le port via Airmail (~5€) et non DHL (15€) sauf si on est pressé.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 11, 2021, 03:39:54 pm
je viens de recevoir 4 circuits MCP2562 (distri-compo en France) et j'ai cablé une mini carte sur le connecteur Can habituel 6 pins, + une liaison au 5V :
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3717;image)
Ça marche comme l'avait prédit l'ami Jean-Luc, à 500 kb/s.
Mais il reste un cafouillage au démarrage à froid de l'ESP32 qui se résoud par un reset de l'ESP32.

A suivre...

Ce ne serait pas sorcier de faire un breakout à 7 pins (le +5 est juste à coté) avec un MCP2562.
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3712;image)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 12, 2021, 06:09:32 pm
Voilà un test du bus Can avec une pré-version de la bibliothèque ACAN (actuellement encore sous forme de fichiers à placer dans le croquis) et un driver de bus MCP2562 (qui n'a aucune incidence sur le programme).

Après compilation, on voit qu'il reste de la place pour des applications utilisant la rétrosignalisation par satellites :
Le croquis utilise 755366 octets (57%) de l'espace de stockage de programmes. Le maximum est de 1310720 octets.
Les variables globales utilisent 44376 octets (13%) de mémoire dynamique, ce qui laisse 283304 octets pour les variables locales. Le maximum est de 327680 octets.

Le fonctionnement est parfait en même temps que des commandes Throttle et la génération DCC.
Il manque encore les masques (pas ceux de la Covid !) et les filtres (probablement assez différents de ceux du MCP2515, car adaptés au SJA1000). Donc il y aura une autre version définitive.

Toutes les anomalies constatées précédemment semble avoir disparu. Neanmoins il va falloir intégrer le MCP2562 qui remplacera le SN65HVD230.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 14, 2021, 11:19:45 am
J'ajouterai que la bibliothèque ESP32CAN utilisée précédemment dans le programme Can-test-Jan-21 présenté 2 pages avant celle-ci (https://forum.locoduino.org/index.php?topic=922.msg12387#msg12387 (https://forum.locoduino.org/index.php?topic=922.msg12387#msg12387), se bloque si la liaison CAN ne s'établit pas et si les messages émis ne partent pas (ce qui se produit immanquablement quand le tampon d'émission est plein).

La conséquence est grave : si la centrale est utilisée sans le bus CAN, il devient impossible de connecter un Throttle au moment de la déclaration de son @ DCC. Donc ça ne marche pas.

Avec le programme LaBox079-TEST_ACAN_SATELLITE, lorsque le tampon d'émission est plein, l'erreur de défaut d'émission est constatée mais cela ne bloque pas le reste des fonctions de la centrale.

Donc c'est ce dernier programme à utiliser pour vos tests et développements CAN (en attendant la bibliothèque définitive et son intégration dans LaBox avec une option de compilation ou un paramètre de configuration, ainsi que la fonction HMI correspondante : Hey les gars, il y a encore un peu de boulot  ;))
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le février 20, 2021, 10:31:18 pm
Sur les indications de Dominique, j'ai testé les modules CJMCU-230 que j'avais. Aucun ne fonctionnait tel quel.

Pour les passer en haute vitesse, il faut remplacer la résistance dite Rs de la documentation (10 Kohms CMS, R1 du module) par un pont. (2) sur la photo.

On constate également un autre problème : les trous de ce circuit imprimé ne sont pas métallisés et la continuité entre les deux faces n'est pas assurée si la soudure que l'on met ne passe d'une face à l'autre. Il y a lieu d'insister pendant 5 à 10 secondes et vérifier au moins sur les broches d'extrémité que la soudure a bien atteint l'autre face (à postériori). (3) sur la photo.

Et à la même occasion, on peut supprimer la résistance CMS R2 de 120 ohms, LaBox en comporte une. (1) sur la photo.

Si malgré cela, le module ne fonctionne pas, et avec un peu d'entrainement, vous pouvez remplacer le composant marqué VP230 par un VP232.
https://www.ebay.fr/itm/393093063744 : reçu en 13 jours …
Tous ceux que j'ai remplacés fonctionnent.
Le dessoudage est relativement facile : on présente une épingle pour la glisser sous un coté du composant quand on applique une large goutte de soudure sur les quatre pattes.
On déplace alors l'épingle en dessous puis vers l'extérieur ce qui soulève et désolidarise le dit composant. Le deuxième coté se défait alors sans difficulté par une goutte de soudure appliquée sur les quatre autres pattes.
Après nettoyage, il ne reste (!) qu'a ressouder le nouveau composant. Question d'entrainement.
Titre: Sondage "LaBox"
Posté par: Dominique le février 21, 2021, 10:15:39 am
Bonjour à tous,

J’ai mis un sondage sur ce projet, ... pour tester les sondages !
Ce faisant, autant recueillir vos attentes aussi.

Il est visible en haut de chaque page du sujet  8).

Si les options proposées ne suffisent pas, donnez votre avis dans une réponse en gardant le titre “Sondage LaBox”.
Nous en déduirons les priorités pour les développements à venir, puisque ceux-ci sont basés sur le bénévolat et la disponibilité des contributeurs.

Merci d’avance  ;D
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: fcot2002 le février 22, 2021, 11:31:03 am
Bonjour Dominique,

Pour te répondre plus précisément et concernant MON utilisation :

- centrale DCC de démonstration sur diorama / support vitrine etc. En O (mais je pense pouvoir tester rapidement que 3A seraient suffisant). Donc une LaBox sous chaque dio / support vitrine. Sauf, évidemment, si les supports sont accolés alors une LaBox pour plusieurs supports (à concurrence de 3A :D :D :D)

Merci de tout cet excellent boulot !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 22, 2021, 01:22:48 pm
Merci François,

A noter que cette limite de 3A peut être repoussée à 4A, maximum 5A (Le 6203 risque de se mettre en protection thermique), à condition de modifier un peu le gain de l’ampli de courant et surtout de mettre un bon radiateur.
Dans ce cas la mesure de courant pour lire et programmer les CVs ne fonctionnera plus (théoriquement). Mais à ce prix là on peut en faire une de plus, dédiée à cet usage  ;)
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 22, 2021, 01:30:37 pm

- centrale DCC de démonstration sur diorama / support vitrine etc. En O (mais je pense pouvoir tester rapidement que 3A seraient suffisant). Donc une LaBox sous chaque dio / support vitrine.

En cas de plusieurs dioramas et plusieurs centrales, on pourrait imaginer synchroniser les centrales grace au bus can, l’une des centrales pilotant les autres. Je vais prendre en compte ce cas dans mes tests can.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: fcot2002 le février 23, 2021, 11:07:10 am
Hello à tous !

Merci Dominique pour la réponse.

Pour l'ampérage, comme discuté avec Marcel, 3A devrait suffire pour 1 machine. Actuellement c'est ce que j'ai avec le shield motor de base de DCC++, et cela convient à mes essais demo ; juste limiter la vitesse à 50% mais avec sons fumigène etc. etc. Donc ça devrait le faire aisément.

Oui effectivement dans le cadre de plusieurs demo, le CAN peut venir en aide. Mais je ne pense pas être dans cette configuration dans les mois à venir. Je pense dans un premier temps à plusieurs machines sur un banc, mais évidemment une machine fonctionne à la fois.

Mais tout ceci amène de belles idées
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le avril 03, 2021, 07:38:37 pm
J'ai retiré le sondage qui occupe beaucoup toutes les pages du sujet.

Mais le résultat reste ici quand même :
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3829;image)

Il est daté fin Mars 2021 et j'espère en ouvrir un autre plus tard s'il y a des modélistes interessés.

En attendant, comme je n'ai pas idée de qui a répondu au sondage et pourquoi son choix, je vous invite à répondre à ce message avec votre avis pour éclairer votre vote.

En ce qui me concerne j'ai voté pour l'option 5, tout en bas, car je vois dans LaBox un terrain de développements personnels, mettant en oeuvre les communications Can avec des périphériques (capteurs et actionneurs) accompagnés d'exemples de programmation.

Je n'ai pas eu de temps récemment pour aller beaucoup plus loin que les tests Can présentés précédemment, mais j'espère m'y replonger bientôt.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 03, 2021, 09:17:10 pm
Que dire de plus que je souhaiterais y développer de petits automatismes à partir d'un ou ou des exemples comme le va-et-vient réaliste bien connu avec une rétro-signalisation fiable via CAN.
Pour cela, il faudrait que les exemples restent d'un niveau accessible au programmeur de base et évitent les arcanes des objets ... (ou qu'on ne soit pas obligé de modifier les dits objets)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Latse le avril 04, 2021, 05:21:22 pm
Tout d'abord, un grand merci à l'équipe de LOCODUINO pour son site et son forum que je suis avec beaucoup d'attention avec mes modestes compétences. J'ai voté pour l'option 5.
Comme Msport, je souhaiterai le développement d'automatismes agrémentés d'exemples simples que l'on puisse adapter facilement dans la construction de projets modulables et aussi de fiches de mise en service de la centrale DCC. Bref, j'ai tellement d'idées pour mes projets que j'ai tendance à m'éparpiller.
Cordialement,
Pierre,
PS: Serait-il possible de disposer du fichier GERBER du détecteur de présence DCC par consommation du courant en version simple et non double?
Par avance MERCI.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le avril 04, 2021, 05:39:58 pm
Citer
Serait-il possible de disposer du fichier GERBER du détecteur de présence DCC par consommation du courant en version simple et non double?

Oui on va organiser ça  ;D
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Latse le avril 04, 2021, 07:32:32 pm
Un grand merci !
 
Pierre,
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jeje_12_34 le avril 04, 2021, 08:23:49 pm
Bonsoir,

J'ai du répondre 5 aussi, même si je n'en suis pas certain, puisque je suis attiré par l'automatisation du réseau et des itinéraires.

Je reste un néophyte qui se fait souvent larguer dans la compréhension, surtout sur le forum.
Je voudrai encore une fois vous remercier tous pour la qualité du site et votre capacité à me motiver et à me faire monter en compétence.

Mais vous avez du boulot  :P



Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le avril 06, 2021, 12:12:55 pm
PS: Serait-il possible de disposer du fichier GERBER du détecteur de présence DCC par consommation du courant en version simple et non double?
Par avance MERCI.

En attendant de publier ces fichiers Gerber, vous pouvez demander à bobyAndCo de vous fournir des cartes de ce type de détecteur car il en a plusieurs en stock : envoyez-lui un MP  :D
Cela vous fera gagner du temps, je pense.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le avril 10, 2021, 10:56:55 am
Petite version 0.7.12 du matin : simplification du code à divers endroits, retrait de fonctions inutiles, codage dans ThrottleAutomation de la possibilité de déclencher un ordre via un changement de broche par les Sensor de DCC++ (non physiquement testé...). Crédit (mérité) du copyright à Cédric et Dominique.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 10, 2021, 12:02:32 pm
Petit souci de compilation : (IDE 1.8.13)
C:\Users\miche\Documents\Arduino\libraries\LaBox-0712\src\Throttles\ThrottleAutomation.cpp: In member function 'void ThrottleAutomation::printThrottleItems()':
C:\Users\miche\Documents\Arduino\libraries\LaBox-0712\src\Throttles\ThrottleAutomation.cpp:177:37: error: 'SENSORID' was not declared in this scope
    Serial.print(SENSORID(curr->delay));
                                     ^
C:\Users\miche\Documents\Arduino\libraries\LaBox-0712\src\Throttles\ThrottleAutomation.cpp:179:40: error: 'SENSORSTATE' was not declared in this scope
    Serial.print(SENSORSTATE(curr->delay) ? "HIGH" : "LOW");

0.7.12 pris sur le git, placé dans libraries, LaBox laissé dans examples
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le avril 10, 2021, 01:14:51 pm
Exact. J'ai poussé une version 0.7.13 qui corrige ça. Au passage, Throttle Automation a vu arriver une autre façon de tester une broche directe en plus d'un Sensor de DCC++ . Voir l'exemple AutotestSensor pour ça....
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 10, 2021, 01:51:46 pm
Nickel ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 10, 2021, 05:33:25 pm
Problème en compilant l'exemple AutotestSensor :

C:\Users\miche\Documents\Arduino\libraries\LaBox-0713\src\Throttles\ThrottleAutomation.cpp:193:15: error: #if with no expression

en ligne 193 il y a : 193.   #if USE_SENSOR, et il y a bien en 202.   #endif
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le avril 10, 2021, 08:26:02 pm
Oui j'ai mis à jour la version 0.7.13 ... J'espère que c'est la bonne.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 10, 2021, 09:07:05 pm
J'ai juste mis à jour ThrottleAutomation.cpp et le sketch se télécharge.
Le HMI est mis à jour avec l'animation et le DCC est on.
Je continuerai avec une loco demain ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 12, 2021, 11:02:53 pm
Avec AutotestSensor c'est OK, la loco 3 sur les rails fait bien ses allers-retours et ses clins d’œil.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le avril 15, 2021, 09:39:33 am
je viens de recevoir 4 circuits MCP2562 (distri-compo en France) et j'ai cablé une mini carte sur le connecteur Can habituel 6 pins, + une liaison au 5V :
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3717;image)
Ça marche comme l'avait prédit l'ami Jean-Luc, à 500 kb/s.
Mais il reste un cafouillage au démarrage à froid de l'ESP32 qui se résoud par un reset de l'ESP32.

A suivre...

Ce ne serait pas sorcier de faire un breakout à 7 pins (le +5 est juste à coté) avec un MCP2562.
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3712;image)


Après avoir tenté en vain de faire fonctionner 2 séries de CJMCU-230 en essayant d’appliquer les recettes trouvées ici et là sur internet ou celles proposées par Michel, je ne suis arrivé à rien et je vais adopter la solution que tu préconises Dominique à savoir le MCP2562. Il existe un MCP2562FD, lequel est préférable ?

Sur la photo de ton montage Dominique on dirait que tu as une diode non polarisée, est-ce que tu confirmes ? Si oui pourquoi et quelle en est la valeur ?

Comme j’ai besoin d’un nombre assez important (20 à 30) de transceivers, je vais faire réaliser un PCB ad hoc, ceux qui sont intéressés peuvent se manifester.

Pour les transceivers, j’ai trouvé chez RS les MCP2562 à 0,87€ l’unité par 10 et les MCP2562FD à 0,93€ l’unité par 10 je pense qu’il sera difficile de trouver beaucoup moins cher et de plus je ne paye pas le port chez RS.

Pour les CJMCU-230, je précise que j’ai eu deux séries qui fonctionnent parfaitement puis j’ai acheté 2 autres séries (chez les chinois) qui ne fonctionnent ni l’une ni l’autre. Je confirme bien que sur une série, la sérigraphie est inversée entre le verso et le recto. Sur une face est écrit 3,3v et sur l’autre pour la même pin CANL. Et il en est ainsi de toutes les pins !!!
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le avril 15, 2021, 09:45:06 am
Salut Christophe,

FD est relatif au CANFD; FD signifie Flexible Datarate. Le protocole CANFD porte la taille des données d'une trame à 64 octets et le débit jusqu'à 8 Mbits pendant la transmission des données.

L'ESP32 ne possédant pas de contrôleur CANFD, un transceiver CANFD est inutile.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le avril 15, 2021, 09:46:42 am
Merci Jean-Luc, comme quoi vaut mieux se renseigner avant d'acheter !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le avril 15, 2021, 09:54:24 am
Mettez le une bonne fois pour toute sur la carte de la LaBox ce transceiver : un circuit DIP, deux capa de 100nf (une sur VDD-VSS et une sur VIO-VSS), un strap, une résistance de 120Ω. Est-ce la peine de dépendre d'une BB foireuse pour si peu ?  :)
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le avril 15, 2021, 09:56:38 am
Ce ne serait pas sorcier de faire un breakout à 7 pins (le +5 est juste à coté) avec un MCP2562.
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3712;image)

il manque les capas de découplage (100nF). Tant qu'à faire, met la résistance de terminaison de 120Ω et un strap pour la mettre en fonction. :)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le avril 15, 2021, 09:59:07 am
Oui pour le strap et la résistance de 120Ω. La capa est entre quelles broches ?

Et pour ma culture générale, c'est quoi une "BB foireuse" ?
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le avril 15, 2021, 10:05:13 am
Oui pour le strap et la résistance de 120Ω. La capa est entre quelles broches ?

Sur l'alimentation. Le 2562 a une double alimentation : VDD-VSS pour le bus (5V) et VIO-VSS pour l'interface avec le micro (3.3V). Donc une capa de 100nF (céramique ou polyester) entre VDD et VSS et une entre VIO et VSS le plus proche possible. Ces capas servent de réserve d'énergie locale pour les circuits numériques lors des commutations.

Citer
Et pour ma culture générale, c'est quoi une "BB foireuse" ?

BB = Breakout Board.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le avril 15, 2021, 10:17:41 am
Ok, merci pour les infos. Et pour la BB foireuse, je suis d'accord avec toi et c'est pour cela que je veux faire un PCB. J'ai effectivement besoin de ce composant pour d'autres usages que la box et par exemple des passerelles CAN-WiFi où là j'envisage de l'intégrer au PCB principal.

Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le avril 15, 2021, 10:25:54 am
Mais il reste un cafouillage au démarrage à froid de l'ESP32 qui se résoud par un reset de l'ESP32.

Il existe des circuits spécialisés qui maintiennent le micro en reset tant que l'alim n'est pas stabilisée. Ça vaudrait le coup d'essayer. Par exemple : https://befr.rs-online.com/web/p/voltage-supervisors/0138506/

Il y a moins cher chez TI mais c'est du CMS
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le avril 15, 2021, 10:34:18 am
Selon un montage comme celui-ci ?
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le avril 15, 2021, 10:37:40 am
Selon un montage comme celui-ci ?

Oui. Note que le poussoir et la capa sont censés déjà être sur l'ESP32. Donc c'est encore plus simple.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le avril 15, 2021, 10:39:12 am
Oui oui bien sûr pour le bouton et la capa. Mais ce qui va sans dire va mieux en le disant !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le avril 15, 2021, 01:09:23 pm
C’est bien ce qu’on s’est dit en réunion : une v3 bientôt!
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le avril 15, 2021, 01:36:59 pm
J’ai raté plusieurs épisodes dans cette discussion. Désolé 😣

Pour le Reset, on l’a fait sur le Due de cette façon.

Pour tes BB type Max471, mais avec un max472, Msport  l’a fait: est-ce suffisant ?
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le avril 16, 2021, 09:24:02 am
Pour le Reset, on l’a fait sur le Due de cette façon.

C’est là, avec un mcp230 :
 https://forum.locoduino.org/index.php?topic=258.msg2375#msg2375 (https://forum.locoduino.org/index.php?topic=258.msg2375#msg2375)
Titre: Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le avril 16, 2021, 09:27:59 am
C’est là, avec un mcp230 :
 https://forum.locoduino.org/index.php?topic=258.msg2375#msg2375 (https://forum.locoduino.org/index.php?topic=258.msg2375#msg2375)

MCP130 qui a l'avantage d'être bien moins cher :)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 16, 2021, 12:20:26 pm
Attention, le MCP130 a une résistance de pull-up de 5K au VDD, donc pas possible de tester le 5V directement.
Et comme le 3.3V provient de l'ESP32, c'est douteux de le tester.

Donc si on teste le 5V, il faut une diode anti retour ou vérifier si le ENABLE de l'ESP32 supporterait le 5V.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le avril 16, 2021, 01:01:37 pm
Mais c'est le 3.3V qu'il faut tester. Le VDD est le 3.3V. Le fait qu'il ne soit pas fiable est justement ce qu'on veut tester.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 16, 2021, 02:50:59 pm
Pas convaincu : le 3.3V peut être bon sans que le 5V le soit.
Le plus tardif est le 5V, c'est lui qu'il faut tester.
Si le 5V est bon, l'ESP se charge de se faire un 3.3V qu'il lui faut.

Et on a besoin d'un 5V propre pour le CAN.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le avril 16, 2021, 02:56:02 pm
C'est quoi exactement votre « cafouillage au démarrage à froid » ? Je soupçonne qu'on ne parle absolument pas de la même chose  ;)
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le avril 16, 2021, 09:21:59 pm
C'est quoi exactement votre « cafouillage au démarrage à froid » ? Je soupçonne qu'on ne parle absolument pas de la même chose  ;)
En relisant les messages du 11 Février, je me pose également la même question !
Et le mot « cafouillage » n’est pas conforme à l’éthique du diagnostic !
Peut-être s’agissait-il d’un problème avec la bibliothèque Can avant celle, ACAN, de Pierre Molinaro.
Quelqu’un d’autre a-t-il plus d’infos ?
Titre: Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le avril 17, 2021, 11:51:44 am
Ce ne serait pas sorcier de faire un breakout à 7 pins (le +5 est juste à coté) avec un MCP2562.
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=3712;image)

il manque les capas de découplage (100nF). Tant qu'à faire, met la résistance de terminaison de 120Ω et un strap pour la mettre en fonction. :)

Je suis trop content, ça fonctionne nickel et j'ai même pu échanger des données à 1000Kbs.

Le MCP2562-E/P m'est revenu à 1,03€ chez RS (et en plus j'étais livré le lendemain !) J'ai bien ajouté les deux capa de 100nF comme tu me l'as précisé Jean-Luc.

Pour les tests, l'ESP est alimenté par le port USB, le 5V est pris sur la broche VIN et le 3,3v sur la broche 3,3v.

Voici le montage sur une BB foireuse mais je vais modifier mon PCB en conséquence.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 25, 2021, 10:42:18 am
A noter que si la compilation de LaBox 0713 se passe bien avec l'IDE 2.0.0-beta3, le résultat est très instable : LaBox reboote dés qu'on envoie des ordres répétés sur le serial. S'en tenir à l'IDE 1.8.13.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 08, 2021, 04:12:53 pm
Nouvelle version de LaBox qui franchit un cap : 0.8.0 !

- En fait d'évolution, c'est plutôt un recul puisque par défaut la répétition de fonction n'est plus activée. Et voici pourquoi :
Après les discussions avec l'équipe lors de notre dernière assemblée générale visio-conférence, et suite à des essais infructueux voire un peu destructeurs de la version 0.7.13, il a été décidé de limiter la répétition à la fonction 0, dite 'FL' pour les feux.  Ce qui est ressorti de mes propres tests, et que j'avais joyeusement occulté, c'est qu'il se trouve que le DCC communique par groupe de fonctions. Donc la mise à jour de la fonction 0 doit forcément se faire en même temps que les fonctions F1 à F4, mais comme je ne sais pas si j'ai le droit de les répéter, j'ai choisi de ne pas le faire du tout.
En fait c'est un peu plus subtil. J'ai mis en place dans cette version la possibilité de fixer la modalité de chaque fonction d'une loco donnée. Une fonction est modale si son fonctionnement est permanent comme les lumières, et non modale si elle est à durée limitée comme un sifflet de vapeur ou une annonce en gare sur un décodeur sonore. Par défaut, seule la fonction F0 est déclarée modale. Pour que la répétition d'un bloc de fonctions soit activé, il faut que TOUTES les fonctions d'un même bloc (F0->F4, F5->F8, F9-F12, F13->F20, F21->F28) soient modales ! Donc dans la version par défaut, la répétition ne s'active pas. Si on souhaite rendre modale une fonction, c'est possible via la classe Locomotive :
  Locomotive* pLoco = Locomotives::add("Test", 3);

  pLoco->functions.setModal(1);
  pLoco->functions.setModal(2);
  pLoco->functions.setModal(3);
  pLoco->functions.setModal(4);
Bien sûr là c'est par code, et il faut être sûr de son coup. Si on veut aller plus loin, il devrait être possible de faire une page web permettant de configurer les fonctions, mais même dans ce cas, il est peu probable que les fonctions modales d'un décodeur se suivent au point de constituer un bloc complet... Donc l'usage devient rare, voire inexistant. J'attend vos réflexions sur le sujet, mais du coup je ne suis plus très sûr du bienfondé de cette fonctionnalité.
- Dans ce mouvement de fond sur les fonctions, la classe FunctionsState a changé de nom pour devenir simplement Functions.
- La documentation a été complétée et corrigée un peu partout à certains endroits.
- La compilation pour un UNO n'était plus possible suite à des ajouts spécifiques ESP, c'est de nouveau possible, même si je n'ai pas testé le résultat...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 08, 2021, 06:33:04 pm
Waouhh!
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le mai 08, 2021, 07:02:10 pm
Je dirais que le choix de répéter les commandes de fonction induit nécessairement une perte de bande passante d'une part, et l'augmentation de la sollicitation du décodeur d'autre part, qui pourrait éventuellement se retrouver à traiter des commandes trop rapprochées. La norme imposant que deux commandes à destination du même décodeur soient espacées d'au moins 5 ms, il faut garantir non plus un délais de répétition d'une même commande (qui se gère très simplement au niveau de la structure mémoire de la commande en horodatant le dernier envois) mais l'espacement d'un groupe de commande concernant une même adresse, ce qui complique significativement l'ordonnancement des paquets si l'on ne veut pas perdre de bande passante (ie : ne rien émettre quand on pourrait le faire)....

Qu'est-ce qui a motivé le besoin de répéter les commandes autres que celle de vitesse ?

Actuellement dans ma lib, les commandes SPEED & DIRECTION sont en répétition permanente et les "autres commandes" du mode opération sont répétées (arbitrairement) 5 fois...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 08, 2021, 09:27:45 pm
Merci Thierry pour cette mise à jour et de rappeler que du fait du standard adopté par le NMRA, les fonctions sont traitées par groupe.
Ce qu'on retrouve dans les commandes prévues par DCC++.
Ce qui entraine le problème suivant : si on répète pour F0, on répète également pour F1 à F5.
Or si F0 est l'éclairage, les suivants sont souvent sifflet, cloche, etc.
En soi, ce ne serait pas un problème si les émetteurs de code traitaient proprement les commandes, à savoir que si c'est une commande ponctuelle type sifflet, l’émetteur devrait positionner la désactivation aussitôt après avoir envoyé l'activation.
Répéter la désactivation ne posant à priori pas de problème. (il s'agit d'un bit repositionné à 0 dans le groupe)
Comme on constate à postériori que ce n'est pas obligatoirement le cas, je pense qu'on peut la prévoir paramétrable mais que de base, la répétition ne soit pas activée, et laissée à la charge de l'émetteur de le faire.
Et dans ce cas, on ne pourra pas reprocher à LaBox d'être transparente.
Quant au taux de répétition (si activée) on peut se contenter d'une fréquence basse de plusieurs centaines de millisecondes, la persistance rétinienne faisant le reste.
Mais tout autre argumentaire mérite d'être pris en considération.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 09, 2021, 10:01:49 am
Pour compléter la réflexion, on pourrait faire l'inventaire du mode d'émission des différentes commandes (manettes, automates, ...) que nous avons réalisées ou utilisées :
Récemment en lisant le programme de la throttle ESP32 de Geoff Bunza, j'ai constaté qu'il faisait réémettre les fonctions toutes les 200 ms mais qu'il y avait prévu une correction (mise en commentaire) qui prévoyait la désactivation systématique après ces 200 ms.
En ce qui concerne la manette de Dave Bodnar (à la base de mes différentes variantes), les fonctions sont traitées en  toggle : un coup, on active, un coup on désactive. ce qui oblige pour donner un coup de sifflet à deux actions sur le bouton. Sauf erreur, la répétition est basée sur un delay(500).
En attente de vérification.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Pyk35 le mai 09, 2021, 06:32:20 pm
Hello,

Je reprends le train en marche sur le sujet.
Pouvez-vous me préciser les souhaits d'évolution de l'interface visuelle (HMI) sur La Box ? Lors de notre dernière AG  ;) visio conférence j'ai noté quelques points mais j'ai perdu mes notes (oui je sais... le boulet). Après tout, le forum est le mieux pour tracer ça ou alors le Git aussi (https://github.com/Locoduino/LaBox/).

Merci.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 09, 2021, 09:37:17 pm
Bon, j'ai retrouvé ma liste :

Voici les fonctions visibles sur l’OLED et Thierry ajoutera ou enlèvera des éléments

1) Menu Stop DCC
   - On Line (ou DCC on) à faire
   - Off Line (ou DCC off) à faire
   en répercutant l’état sur l’écran d’accueil (entre le titre et l’adresse IP) et la génération du DCC bien-sur, qui se vérifie sur les leds reliées aux sorties.

Nota :  en cas de court-circuit, le DCC devient OFF automatiquement et se voit sur l'OLED: il faut un moyen par ce menu de le reactiver ON)

2) Lecture addr train = c’est fait

nota : il y a 3 lectures de l’adresse DCC. Faut-il  en conserver 3 ?
En cas de succès il n’est plus nécessaire de réaliser les lectures suivantes, mais garder le résultat plus longtemps à l'écran

3) Type de vue Trains
   Je crois que le mode 2 vue n’est pas complètement implémenté (les 2 barres ne sont pas à distance égale du milieu, c’est la mode 3 barres avec seulement 2 affichées)

4) Mesure U et I ne sert à rien en fait, car c’est présent sur l’écran d’accueil ou l’écran des vitesses : à supprimer

5) Liste événements n’est plus nécessaire, je pense (ou je n’ai pas compris son utilité, sauf debug)

6) Langue : Français c’est sur et l’anglais peut-être si ça ne prend pas trop de place

7) Wifi
   - infos Wifi
   - activation wifi (est-ce utile, perte du Wifi = reset ?)
   - mais il serait sans doute utile de pouvoir configurer un accès via Box Internet (associé à USE_WIFI_EXTERNSSID)
   nota : entrer des lettres et des chiffres pour l’adresse et le mot de passe est quasi impossible
   Il faudrait prévoir un mode de configuration genre ligne de commande, soit via l’USB, soit via CAN (avec un configurateur externe qui aurait du sens s’il sert aussi pour les satellites), ou peut-être en WiFi (ce que j’ai cru comprendre de Christophe).

8) Reseau Can
   - Passerelle Can Wifi (ON ou OFF)
   - Adresse CAN (c’est plutôt « identifiant CAN »)
   - infos CAN (can OK ou NOK)
nota : je n’ai pas encore une bonne visibilité des fonctions CAN à faire tant que je n’ai pas étudié les interfaces de Thierry et fait quelques exemples (je suis à la bourre !)

9) Infos système (c’est plutôts des infos que Thierry peut remonter du reste du logiciel)

10) Redemarrage (est-ce bien utile quand on peut débrancher le jack d’alilm, plus vite que d’appuyer 10 fois sur le bouton dowm ?)

11/ Factory Reset (oui s’il y a des paramètres configurables autrement que par compilation-versement)

A tout cela, il faut peut-être ajouter un mode démo tel que AutotestSensor proposé par Michel, avec, en plus une visualisation des capteurs activés ou déactivés (genre tableau avec des cases rouge/vert ou blanc/noir) qui pourrait être utilisé par le Can et visualiser la rétrosignalisation).
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Pyk35 le mai 11, 2021, 01:35:40 pm
Bonjour,

J'ai une bonne liste de courses.
Je reviens sur la vue 1/2/3 trains. Je m'interroge sur l'intérêt de toutes ces vues et du coup est-ce que la vue 1 train ne suffirait pas ? Vous utilisez quoi de votre côté?

Pour le CAN, il aurait fallut intégrer la passerelle CAN / Wifi non ?

A+
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 11, 2021, 01:55:43 pm
Je reviens sur la vue 1/2/3 trains. Je m'interroge sur l'intérêt de toutes ces vues et du coup est-ce que la vue 1 train ne suffirait pas ? Vous utilisez quoi de votre côté?

Pour moi la vue 1 me suffit.
Mais si il y a plusieurs manettes, celle qui s’affiche est alors la dernière vue.

Citer
Pour le CAN, il aurait fallut intégrer la passerelle CAN / Wifi non ?

Sans doute mais il faudrait que je la regarde sérieusement.
Titre: Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 11, 2021, 07:59:52 pm
Pour moi la vue 1 me suffit.
Mais si il y a plusieurs manettes, celle qui s’affiche est alors la dernière vue.
Je pense aussi, mais dans une optique sniffer, comme Thierry a déjà développé un affichage Loco Vitesse Sens pour débuguer, un affichage des commandes fonctions / accessoires reçues ne serait peut-être pas trop compliqué à mettre en place ?
A rendre accessible par un menu.

Par ailleurs, l'écran I2C de 0,96", driver SSD1306 pourrait être remplacé en option par un I2C de 1,35", driver SH1106. (1€ de plus).
On lui trouvera de la place dans la prochaine version de pcb.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: DDEFF le mai 11, 2021, 08:36:21 pm
Bonsoir à tous,

Ça bouillonne dans les cerveaux, ça fuse de partout. Il reste évidemment des améliorations et il en restera toujours.
Mais on en est à la page 32 sur le forum ! :o

Je pense qu'il est temps de faire une pause, de faire un ARTICLE avec la V2 du CI.
Ce sera une base qui fait déjà suffisamment de choses, et qui ravira déjà de nombreuses personnes.

Alors après, OK pour qu'on fasse une V3, une V4, avec, par exemple une entrée série sur le CI, une sortie vers une voie de programmation, une possibilité de brancher un gestionnaire externe, que sais-je encore ?...

C'est la force de notre beau site que d'avoir des articles. ;D

Un forum, ça bouillonne, ça explore des pistes qui seront abandonnées parce qu'une meilleure est trouvée,… mais ça devient illisible, à ne plus tenir compte des fausses pistes.

Denis
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 11, 2021, 09:09:58 pm
Bonsoir Denis,
c'est trop tôt pour faire un article, il faut déjà stabiliser le soft. Et donc de profiter d'un créneau de disponibilité.

Et du coup, ton message est obsolète, on est à la 33 !
Titre: Re : Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Pyk35 le mai 12, 2021, 07:32:37 am
Citer
Par ailleurs, l'écran I2C de 0,96", driver SSD1306 pourrait être remplacé en option par un I2C de 1,35", driver SH1106. (1€ de plus).
On lui trouvera de la place dans la prochaine version de pcb.
A priori cet écran a la même résolution donc pas trop de mal.
Pour la librairie, il y aura un changement mais Adafruit met à disposition une librairie similaire à la première donc il est possible que l'effort d'adaptation ne soit pas trop lourd.

Après je veux bien essayer mais il ne faudrait pas garder les 2 écrans pour basculer uniquement vers ce nouvel écran non ?
On parle bien de cet écran ?
https://fr.aliexpress.com/item/1005001950055514.html?spm=a2g0o.productlist.0.0.78ae312aS4K8aY&algo_pvid=09a66e6e-9484-4421-8422-a9029f48c47c&algo_expid=09a66e6e-9484-4421-8422-a9029f48c47c-0&btsid=0b0a0ae216207970950534131eac46&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 12, 2021, 08:09:13 am
Bonjour

Pour bien faire, il faudrait virtualiser suffisamment pour rendre l'accès physique à l'écran uniquement via une interface. On pourra ensuite changer d'affichage très facilement.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 12, 2021, 10:12:25 am
Bonjour à tous,

Oui, la définition de ces deux écrans étant identique, je voyais effectivement le choix d'un écran simplement par le remplacement du driver comme j’ai pu le voir dans des programmes plus basiques.
L'appel des tft.print et des positions étant identique dans les deux cas.
Les graphiques étant à vérifier, mais probablement compatibles si l'auteur des deux drivers est le même.
Ce qui simplifierait le choix en fonction de ce qu'on trouve dans ses tiroirs.
Mais tant qu'à faire, on préfèrera un brochage identique à celui du 0.96" déjà utilisé :
https://www.ebay.fr/itm/264394039798
GND et VCC sont dans le même ordre.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 12, 2021, 12:15:37 pm
https://github.com/nhatuan84/esp32-sh1106-oled

je n'ai pas vu ce que l'auteur a modifié par rapport à la bibliothèque SH1106 Adafruit pour l'ESP32.
Sur cette page, il donne le lien pour entreprendre cette modification.

http://www.iotsharing.com/2017/05/how-to-use-arduino-esp32-to-display-oled.html
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 12, 2021, 01:53:31 pm
Intéressant !

N’oublions pas que le fait de devoir débrancher le Vcc pendant le téléversement et le rebrancher dans les 2 secondes qui suivent va être une difficulté ou cause d’échec pour pas mal de gens.

Une autre sera de bien installer l’IDE avec toutes les bibliothèques requises, avec le risque que les évolutions de certaines pourraient conduire à un échec.

Quels avantages/inconvénients de l’un pr à l’autre ?
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Pyk35 le mai 12, 2021, 02:57:06 pm
https://github.com/nhatuan84/esp32-sh1106-oled

je n'ai pas vu ce que l'auteur a modifié par rapport à la bibliothèque SH1106 Adafruit pour l'ESP32.
Sur cette page, il donne le lien pour entreprendre cette modification.

http://www.iotsharing.com/2017/05/how-to-use-arduino-esp32-to-display-oled.html

Je lance l'achat et je ferai le portage.
Pour la proposition de Thierry de faire une interface, oui on peut, mais on aura toujours le problème du changement de résolution. Comme le 100% scalable sur de telles résolutions me semble très difficile, on ne fera pas des miracles en termes de souplesse mais ça sera un pas pour la compatibilité avec tous les drivers compatibles avec la librairie Adafruit GLX (librairie qui permet de tracer des traits, des cercles, des rectangles, etc.).

Si on choisit de changer d'écran, est-ce que l'on devrait pas viser un écran encore plus imposant comme un 2.8" TFT avec une résolution de 240x320 mais avec interface SPI (8€ + 2€ de port) ? Le driver sera le même et là on peut faire des choses très sympas :
https://fr.aliexpress.com/item/4001135326039.html?spm=a2g0o.productlist.0.0.65e43ddeOVQN5Z&algo_pvid=29532d0a-c87d-4254-a5c5-620eeab23522&algo_expid=29532d0a-c87d-4254-a5c5-620eeab23522-10&btsid=0b0a050116208235135541526e1f7c&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_
Cet écran est tactile donc cela ouvre d'autres possibilités !
Par contre c'est une interface SPI donc cela touche notre carte électronique.

Cela demandera un peu de boulot mais si je dois m'y remettre, pourquoi pas.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le mai 12, 2021, 03:01:43 pm
N’oublions pas que le fait de devoir débrancher le Vcc pendant le téléversement et le rebrancher dans les 2 secondes qui suivent va être une difficulté ou cause d’échec pour pas mal de gens.

 ???

C'est à dire ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 12, 2021, 03:07:06 pm
Dans la page ici :  http://www.iotsharing.com/2017/05/how-to-use-arduino-esp32-to-display-oled.html (http://www.iotsharing.com/2017/05/how-to-use-arduino-esp32-to-display-oled.html)

Se trouve cet avertissement :

Citer
Here we connect:
[ESP32 3.3V – OLED VCC]
[ESP32 GND – OLED GND]
[ESP32 IO12– OLED SDA]
[ESP32 IO14 – OLED SCL]
NOTE: while flashing SW for ESP32 if you see md5 error, please detach OLED VCC from ESP32 3.3V, after finishing flashing, attach again (I put delay(2000) in setup() so we have enough time to attach) or you can use external power for OLED.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le mai 12, 2021, 03:13:44 pm
Ça viendrait pas de l'IO12 ça ? (boot fails if pulled high). l'I2C est pas dispo ailleurs ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 12, 2021, 03:32:18 pm
L'I2C est sur IO21 et IO22 (voir https://www.locoduino.org/IMG/png/centrale03_sch.png (https://www.locoduino.org/IMG/png/centrale03_sch.png))
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Jean-Luc le mai 12, 2021, 03:37:03 pm
Ok, donc l'écran n'est pas connecté comme indiqué dans l'article. Pourquoi y aurait-il le même problème ?

Ou alors c'est un snafu avec la numérotation d'IO vu le bazar intégral de l'ESP32 à ce niveau :)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 12, 2021, 03:46:20 pm
Peut-être,

en tout cas nous n'avons pas eu ce problème depuis les réalisations des protos. Il me semble en effet avoir vu ce pb sur l'IO12 qui est une des pins du SPI, mais je ne me souviens plus des détails.

En tout cas les choix des pins est ci-dessous.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le mai 12, 2021, 04:29:29 pm
IO12 est une des broches du HSPI. Si besoin d'utiliser un SPI, préférer le VSPI qui n'utilise pas cette broche.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 12, 2021, 07:26:14 pm
Bonsoir,
je crains qu'avec le SPI et le changement de résolution, on ne s’embarque sur un autre projet.
Terminons ou au moins menons celui-ci à un point d'étape.
Je pensais qu'en gardant la résolution, la technologie Oled et le monochrome, la transposition serait une formalité.
Dans la mesure où ce n'est pas le cas, restons avec le 0.96" et gardons sous le coude le changement de taille de l'afficheur.
Pour mémoire, on a retenu  que la vocation de cette version de LaBox est de rester sous la table, et de n'être consultée que pour des mises au point.

Et merci à Denis de nous avoir alertés.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 12, 2021, 07:34:35 pm
Et hop : 34  8)

Je suis pleinement d’accord avec Michel !

Nous pouvons stocker les idées dans un cahier des charges LaBox V2.

Pour moi la vocation d’une centrale n’est pas d’afficher plus que le nécessaire (la liste plus haut) et le bus Can est parfait pour déporter des infos plus complexes et plus graphiques en liaison avec un gestionnaire par exemple.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 15, 2021, 07:31:51 pm
Bonjour à toutes zé tous,

J'ai écrit un petit document en pdf avec:

Comme il est trop "gros" pour tenir dans les fichiers joints, j'ai mis à jour la page 23 (https://forum.locoduino.org/index.php?topic=922.330)

Et il peut être téléchargé  ICI (https://www.locoduino.org/IMG/pdf/demarrage_labox_2.pdf)

Avis aux utilisateurs non-MacOS et non-IOS : je suis prenneur des adaptations de cette documentation pour intégrer ces environnements (contactez-moi par MP ou mail). Merci d'avance.

Comme l'exemple "LaBox" présent dans la bibliothèque 0.8.0 contient une toute petite erreur (un / de commentaire indésirable), je joins une version corrigée qui contient en outre l'allumage de la led Erreur jusqu'à la fin du Setup.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 15, 2021, 08:20:03 pm
Bien la doc... Il y a une petite faute, un 'amplement' pas vraiment bien orthographié... Pour le téléversement, sur Windows (je ne sais pas sur les autres systèmes...) il faut appuyer sur le bouton 'boot' de l'ESP32 pendant l'affichage des points d'attente pour que le téléversement démarre. Il vaudrait mieux en parler.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: DDEFF le mai 15, 2021, 08:59:24 pm
Merci Dominique (peut être aidé par d'autres ?)
En tous cas, c'est bien fait. ;D

Mon problème, dans l'ordre, est de déjà souder tous les composants (que j'ai depuis longtemps) au CI.
Il y a P23 ce qu'il faut, dans le détail, et, à l'époque, j'allais le faire ...

Arrive le post du 06/02 où tu parles d'un problème avec la carte d'interface CAN SN65HVD230 .
Comme je n'ai rien pour tester le CAN (et que c'est ma plus grosse attente sur LaBox), j'attendais.
Peut-on simplement tester si le SN65HVD230 que j'ai est un "bon" SN65HVD230  ?

Denis
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 15, 2021, 09:14:22 pm
Il y a une petite faute, un 'amplement' pas vraiment bien orthographié... Pour le téléversement, sur Windows (je ne sais pas sur les autres systèmes...) il faut appuyer sur le bouton 'boot' de l'ESP32 pendant l'affichage des points d'attente pour que le téléversement démarre. Il vaudrait mieux en parler.

Merci, c'est amplement corrigé !
Mais je ne sais pas à quel moment, dans le fil des affichages, il faut appuyer sur le bouton 'boot' de l'ESP32.
J'ai mis ta phrase mais pas forcément au bon endroit  :o
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 15, 2021, 09:19:30 pm
Merci Dominique (peut être aidé par d'autres ?)
Bah oui, testes donc et donnes moi les choses à préciser...

Citer
Mon problème, dans l'ordre, est de déjà souder tous les composants (que j'ai depuis longtemps) au CI.
Il y a P23 ce qu'il faut, dans le détail, et, à l'époque, j'allais le faire ...

Arrive le post du 06/02 où tu parles d'un problème avec la carte d'interface CAN SN65HVD230 .
Comme je n'ai rien pour tester le CAN (et que c'est ma plus grosse attente sur LaBox), j'attendais.
Peut-on simplement tester si le SN65HVD230 que j'ai est un "bon" SN65HVD230  ?

Denis

La seule nécessité, pour tester le Can, c'est de disposer de 2 points qui communiquent entre eux. As-tu une autre carte Arduino avec son interface Can (un satellite ou autre chose..?).
Si oui on trouvera ensemble les programmes à installer de chaque coté pour savoir si ton 230 fonctionne. S'il ne marche pas je pourrai te dépanner.

La doc ne mentionne pas encore le Can. Mais dès que ACAN définitif sera testé et que j'aurai un exemple (sans doute avec une carte satellite et un petit automate qui bouge une aiguille et change des signaux en fonction du passage d'une loco et d'un appui sur un bouton), j'ajouterai une troisième partie.
On peut faire beaucoup de choses avec une détection de présence, 2 détection ponctuelles, une commande de servo et 10 leds !

Es-tu partant pour qu'on la fasse ensemble ?
Titre: Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 15, 2021, 10:49:04 pm
Pour le téléversement, sur Windows ... il faut appuyer sur le bouton 'boot' de l'ESP32 pendant l'affichage des points d'attente pour que le téléversement démarre.

Mais je ne sais pas à quel moment, dans le fil des affichages, il faut appuyer sur le bouton 'boot' de l'ESP32.


Le croquis utilise 752642 octets (57%) de l'espace de stockage de programmes. Le maximum est de 1310720 octets.
Les variables globales utilisent 44408 octets (13%) de mémoire dynamique, ce qui laisse 283272 octets pour les variables locales. Le maximum est de 327680 octets.
esptool.py v2.6
Serial port COM4
Connecting....

C'est là qu'il faut éventuellement appuyer et relâcher !!! sur boot. sinon on a du genre  __*__* jusqu'à time out.
et la magie de Windows fait que ce n'est pas nécessaire à tous les coups (la première fois semble-t-il ...)

c'est au niveau de : 4) Ouvrir l'exemple LaBox.ino qui se trouve dans le dossier libraries/LaBox/examples/LaBox
Si la compilation se passe bien, on obtient le texte suivant dans la fenêtre de compte-rendu de l'IDE :

Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 84:cc:a8:5c:30:08
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 15, 2021, 10:57:41 pm
... problème avec la carte d'interface CAN SN65HVD230 ...

Denis, vois le message que j'ai fait à ce sujet :
https://forum.locoduino.org/index.php?topic=922.msg12498#msg12498

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: DDEFF le mai 16, 2021, 10:25:24 am
Merci Dominique et Michel,

Je vais souder les éléments de LaBox. Quels sont les tests indispensables pour vérifier qu'on ne s'est pas trompé en soudant ?
On n'est pas en phase industrielle, mais il y a certainement 2 - 3 choses à faire.

Après, concernant le CAN, j'ai les éléments de l'article 151 https://www.locoduino.org/spip.php?article151&var_mode=calcul (https://www.locoduino.org/spip.php?article151&var_mode=calcul)

J'ai absolument besoin du CAN pour tester ses liens avec mon gestionnaire. Et je veux être sûr du fonctionnement du CAN, électroniquement parlant.
Ne plus avoir que des problèmes logiciels à tester. D'où mes questions.
Envoyer un octet, recevoir un octet, le tout de façon parfaitement fiable. Après, c'est de la programmation.

Bien amicalement
Denis
PS : je prendrais des photos de mes avancées en soudure, ça peut toujours servir. Mais laissez-moi quelques jours  ;)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 16, 2021, 11:06:35 am
Denis,
je ne sais plus à quelle occasion j'avais eu de  Dominique ce programme de test qui envoie sur le bus CAN avec un identifiant 25 et reçoit avec un identifiant 15.
Il y est dit :
Test du bus Can avec la biblio provisoire ACAN ESP32
Echanges avec satellite Id 5 (reçoit sur Eid=25 et emet sur Rid=15)


Les LED du satellite s'allument en séquence quand la communication est établie.
Mais si la communication n'est pas établie, le buffer est saturé et c'est affiché sur le serial.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 16, 2021, 11:17:05 am
Je suis en train de tester la bibliothèque ACAN_ESP32 en intégration avec LaBox 0.8.0 (la dernière).

Je t'envoie le programme dès que disponible.
Pour le montage et la mise au point pas à pas, relis la page 23 et suivantes : tout y est pour les DIYers.

Tu n'as pas répondu à ma question : qu'est ce que tu as en face de LaBox sur le bus Can ? (ton gestionnaire ? quelle carte, quel schéma de l'interface Can, quel soft ?)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 16, 2021, 11:39:37 am
Pour ma part je dirais vérifier deux fois les soudures à la loupe : pas de soudures sèches, pas de pont de soudure intempestif.

Par ailleurs en finale avant d'implanter l'ESP32 : vérifier la tension de 5V directement sur le support de l'ESP32 : suivre les flèches.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: DDEFF le mai 16, 2021, 11:42:26 am
A terme, j'aurais mon gestionnaire (en cours d'amélioration côté dessin des voies) qui fonctionne, pour l'instant, avec des trains virtuels.

En particulier, c'est le dessin des locos et wagons en mouvement qui génère l'occupation des zones.
Évidemment, ce sera le vrai train qui enverra, via le CAN, la vraie occupation des voies.

Pour cela, il faudra une interface CAN (côté bus) / Port Série (coté ordi) qui, pour l'instant, n'existe pas.

Physiquement, j'ai :
1°) un Arduino DUE qui a deux interfaces CAN
2°) les tous premiers breakoutboards de Jean Luc : (https://www.locoduino.org/local/cache-vignettes/L500xH375/branchement_sur_la_breakoutboard_can_du_due-ceb1e.jpg?1548598324]https://www.locoduino.org/local/cache-vignettes/L500xH375/branchement_sur_la_breakoutboard_can_du_due-ceb1e.jpg?1548598324) que j'ai en 3 exemplaires.

Voilà.
Dans un premier temps, même si c'est luxueux, je peux prendre le DUE qui a bien une interface Série et un CAN

Denis
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 16, 2021, 01:18:50 pm
Ton Due est comme l’ESP32: il a besoin d’un driver externe comme le HVD230. Si tu as des doutes sur ceux que tu as, n’utilises pas le Due mais un simple UNO, Nano ou Mega avec la carte Can de Jean-Luc qui a tout ce qu’il faut et qui fonctionne à coup sûr.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: DDEFF le mai 16, 2021, 01:44:13 pm
Dans l'article, j'utilisais le DUE et une partie de l'interface de Jean-Luc (voir en haut de l'image).
(https://www.locoduino.org/local/cache-vignettes/L500xH375/photo_generale-3e721.jpg?1548598330)

Pour un NANO, j'utilise toute l'interface de Jean-Luc :
(https://www.locoduino.org/local/cache-vignettes/L500xH667/la_partie_module_4_aiguilles-4e40f.jpg?1548598425)

Donc, mon problème se situera unique côté LaBox. Le reste a déjà marché, donc c'est OK.

Je construit déjà LaBox, mais il va falloir un programme côté ESP32 et un programme côté DUE (ou éventuellement NANO) pour tester le bus.

Denis
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 16, 2021, 03:05:21 pm
Citer
Je construit déjà LaBox, mais il va falloir un programme côté ESP32 et un programme côté DUE (ou éventuellement NANO) pour tester le bus.

Je m'en occupe on verra ça en mails privés et si ça a de l'intérêt pour tout le monde, je publierai  :D

Mais il faudra en premier lever le doute sur le HVD230 que tu dois avoir (sans doute pas bon, mais parfois la chance...) et je te conseille en // de te procurer un circuit DIP MCP2562
comme indiqué précdemment :
https://forum.locoduino.org/index.php?topic=922.msg12941#msg12941 (https://forum.locoduino.org/index.php?topic=922.msg12941#msg12941)

Le plus rapide car c'est un vendeur français :
https://www.ebay.fr/itm/184018171938?mkevt=1&mkcid=1&mkrid=709-53476-19255-0&campid=5338624522&toolid=10001&customid=ae5e5eb5bb72548ce68ce6131eeeacd4 (https://www.ebay.fr/itm/184018171938?mkevt=1&mkcid=1&mkrid=709-53476-19255-0&campid=5338624522&toolid=10001&customid=ae5e5eb5bb72548ce68ce6131eeeacd4)
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 16, 2021, 09:20:28 pm
Je construit déjà LaBox, ...
... HVD230 que tu dois avoir ...
Il faut au moins remplacer la 10 K par un pont pour avoir une chance après le premier essai ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 17, 2021, 02:43:46 pm
Test de la version 080 modifiée pour afficher l'HMI:

1) la lumière ne fonctionne pas: le symbole * s'affiche sur l'Oled mais la lumière ne s'allume pas sur la loco
sur le moniteur:
5 From Throttle : MTAS18<;>F10
Throttle 5 MTAS18<;>F10
DCCpp SetFunctions for loco 18 / Activated : 0


A l'appui suivant, le symbole * s'eteint sur l'Oled et la lumière reste éteinte
5 From Throttle : MTAS18<;>F10
Throttle 5 MTAS18<;>F10
DCCpp SetFunctions for loco 18 / Activated :

Les commandes de vitesse et direction fonctionnent bien:
5 From Throttle : MTAS18<;>V33
Throttle 5 MTAS18<;>V33
DCCpp SetSpeed for loco 18 : 33/128 )

L'appui sur la touche IDLE est sans effet:
5 From Throttle : MTAS18<;>I
Throttle 5 MTAS18<;>I
DCCpp SetSpeed for loco 18 : 32/128 )
5 From Throttle : *
Throttle 5 *
5 -> <T2 18 32 1>*10

L'appui sur la touche STOP n'arrête pas la loco, elle ralenti à la vitesse 1 comme si l'emergency stop n'existait pas dans le décodeur.
D'ailleurs la vitesse 1 est possible avec le curseur et la loco avance bien très lentement !
5 From Throttle : MTAS18<;>X
Throttle 5 MTAS18<;>X
DCCpp SetSpeed for loco 18 : 1/128 )
5 From Throttle : *
Throttle 5 *
5 -> <T2 18 1 1>*10

la lecture de l'adresse loco ne fonctionne plus: après démarrage LaBox, Withrottle connecté pour établir le signal DCC sur les rails, mais pas d'adresse de loco sélectionnée. La machine ne bouge pas du tout !
Le message ERROR s'affiche trop vite : on n'a pas le temps de le lire et je ne vois pas de compte-rendu -1 sur la trace moniteur.
14:28:26.021 -> readCVraw : start reading cv 29
14:28:26.095 -> bit : 0 iter : 9, max : 9
14:28:26.731 -> bit : 1 iter : 11, max : 13
14:28:27.393 -> bit : 2 iter : 13, max : 11
14:28:28.069 -> bit : 3 iter : 2, max : 8
14:28:28.696 -> bit : 4 iter : 18, max : 14
14:28:29.367 -> bit : 5 iter : 6, max : 14
14:28:30.023 -> bit : 6 iter : 18, max : 10
14:28:30.653 -> bit : 7 iter : 0, max : 12
14:28:31.323 -> verif :  iter : 19, max : 14
14:28:31.913 -> readCVraw : start reading cv 1
14:28:31.985 -> bit : 0 iter : 14, max : 7
14:28:32.660 -> bit : 1 iter : 6, max : 13
14:28:33.299 -> bit : 2 iter : 1, max : 13
14:28:33.936 -> bit : 3 iter : 3, max : 13
14:28:34.596 -> bit : 4 iter : 19, max : 16
14:28:35.270 -> bit : 5 iter : 0, max : 11
14:28:35.899 -> bit : 6 iter : 10, max : 10
14:28:36.566 -> bit : 7 iter : 1, max : 15
14:28:37.235 -> verif :  iter : 10, max : 11
14:28:37.897 -> readCVraw : start reading cv 29
14:28:37.969 -> bit : 0 iter : 3, max : 17
14:28:38.603 -> bit : 1 iter : 12, max : 15
14:28:39.244 -> bit : 2 iter : 4, max : 13
14:28:39.917 -> bit : 3 iter : 9, max : 10
14:28:40.587 -> bit : 4 iter : 1, max : 11
14:28:41.240 -> bit : 5 iter : 3, max : 11
14:28:41.875 -> bit : 6 iter : 2, max : 14
14:28:42.534 -> bit : 7 iter : 18, max : 13
14:28:43.199 -> verif :  iter : 2, max : 12
14:28:43.766 -> readCVraw : start reading cv 1
14:28:43.838 -> bit : 0 iter : 1, max : 9
14:28:44.510 -> bit : 1 iter : 3, max : 13
14:28:45.141 -> bit : 2 iter : 19, max : 9
14:28:45.814 -> bit : 3 iter : 4, max : 9
14:28:46.448 -> bit : 4 iter : 13, max : 9
14:28:47.108 -> bit : 5 iter : 12, max : 13
14:28:47.769 -> bit : 6 iter : 17, max : 11
14:28:48.435 -> bit : 7 iter : 5, max : 10
14:28:49.070 -> verif :  iter : 7, max : 11
14:28:49.749 -> readCVraw : start reading cv 29
14:28:49.819 -> bit : 0 iter : 0, max : 10
14:28:50.453 -> bit : 1 iter : 5, max : 12
14:28:51.126 -> bit : 2 iter : 8, max : 12
14:28:51.763 -> bit : 3 iter : 10, max : 12
14:28:52.437 -> bit : 4 iter : 15, max : 15
14:28:53.101 -> bit : 5 iter : 14, max : 12
14:28:53.730 -> bit : 6 iter : 6, max : 12
14:28:54.372 -> bit : 7 iter : 15, max : 12
14:28:55.040 -> verif :  iter : 6, max : 12
14:28:55.634 -> readCVraw : start reading cv 1
14:28:55.701 -> bit : 0 iter : 19, max : 11
14:28:56.374 -> bit : 1 iter : 0, max : 12
14:28:57.021 -> bit : 2 iter : 9, max : 9
14:28:57.653 -> bit : 3 iter : 4, max : 12
14:28:58.309 -> bit : 4 iter : 3, max : 11
14:28:58.985 -> bit : 5 iter : 19, max : 10
14:28:59.621 -> bit : 6 iter : 18, max : 11
14:29:00.289 -> bit : 7 iter : 10, max : 8
14:29:00.948 -> verif :  iter : 15, max : 15
14:29:13.753 -> Converter : client 5 disconnected

Dans DCCpp.cpp je vois DCCpp::ackThreshold = 30 dans le begin.
Là on voit qu'on est bien en dessous.. Je dois essayer avec une Labox dernière version du PCB

Voilà avec la version 079 (et du Can intégré) : la lecture est très concluante.
Ca fait comme si la commande de lecture des CVs n'est pas envoyée à la loco (?)
14:53:04.169 -> readCVraw : start reading cv 29
14:53:04.237 -> bit : 0 iter : 11, max : 8
14:53:04.415 -> bit : 1 iter : 3, max : 358
14:53:04.587 -> bit : 2 iter : 6, max : 357
14:53:04.788 -> bit : 3 iter : 8, max : 8
14:53:04.961 -> bit : 4 iter : 15, max : 9
14:53:05.129 -> bit : 5 iter : 11, max : 6
14:53:05.337 -> bit : 6 iter : 6, max : 8
14:53:05.507 -> bit : 7 iter : 6, max : 8
14:53:05.712 -> verif :  iter : 6, max : 392
14:53:05.814 -> readCVraw : start reading cv 1
14:53:05.886 -> bit : 0 iter : 4, max : 8
14:53:06.055 -> bit : 1 iter : 6, max : 362
14:53:06.190 -> 4 From Throttle : *
14:53:06.257 -> bit : 2 iter : 8, max : 6
14:53:06.432 -> bit : 3 iter : 14, max : 11
14:53:06.609 -> bit : 4 iter : 3, max : 361
14:53:06.777 -> bit : 5 iter : 5, max : 8
14:53:06.951 -> bit : 6 iter : 16, max : 9
14:53:07.159 -> bit : 7 iter : 0, max : 6
14:53:07.334 -> verif :  iter : 6, max : 389

Cela ne m'empêche pas de travailler sur le Can en attendant  ;D
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 17, 2021, 05:38:10 pm
Ayant commencé à étudier l'intégration du bus Can avec la bibliothèque ACAN_ESP32 de Pierre Molinaro (https://github.com/pierremolinaro/acan-esp32), je vous présente un petit exposé sur les masques et les filtres qui permettent de limiter la réception de messages aux seuls qui sont attendus par le programme.

On se reportera d'abord sur les 2 articles "La bibliothèque ACAN" (1) (https://www.locoduino.org/spip.php?) et (2) (https://www.locoduino.org/spip.php?article269)

L'ESP32 étant équipé en interne d'un chip SJA1000 de NXP, je joins la datasheet ICI (https://www.locoduino.org/IMG/pdf/sja1000-datasheet.pdf).

Avant de rentrer dans le cas spécifique de ce contrôleur Can, voici des généralités sur les filtres et les masques :
Le but de ces registres est d'analyser chaque message qui passe sur le bus pour décider si ce message intéresse le noeud (votre carte connectée au bus Can) ou pas. Si oui, le message est placé dans la file de réception, sinon il est ignoré.

La décision d'acceptance se fait sur l'analyse de l'identifiant (Id), bit à bit, au regard de 2 registres appelés Masque et Filtre.
Si la logique d'acceptance est favorable, alors le message est réceptionné dans la file de réception et sera servi à votre programme par le jeu d'une interruption. Tout ceci est géré en interne par le composant Can et la bibliothèque.

Il faut donc se concentrer sur ce qu'il faut mettre dans les filtres et les masques !

Principe :
Chaque bit du masque ne fait rien d’autre que de valider ou invalider le bit correspondant du filtre.
Dans le cas de l'ESP32 :
Un bit '0' valide le bit correspondant du filtre.
Un bit '1' permet d'ignorer le bit correspondant du filtre.


Chaque bit du filtre validé par le masque teste l’égalité avec le bit correspondant de l’identifiant, les autres bits pouvant avoir n’importe quelle valeur donc sont validés d’office.
Le résultat global du test (un & sur l’ensemble des tests bit individuels) autorise l’entrée du message dans la file d’attente du récepteur Rx du CAN et arme une interruption.
Donc un message dont l’identifiant n’est pas validé par ce test est invisible par le programme.

Le plus simple pour comprendre est de regarder quelques exemples basés, pour commencer, sur le cas des identifiants de 11 bits (standards).
Dans le cas du SJA1000, cela peut concerner aussi des identifiants de 29 bits (étendus) et il existe un ou 2 couples de masques et filtres maximum, ainsi que des possibilités de filtrage sur les 2 premiers octets de données du message.
Mais il faut procéder par étape donc on commence à s'interesser uniquement au cas des identifiants courts (11 bits) pour comprendre la logique.

Exemples pour un identifiant de 11bits :

MasqueFiltreResultat
0b00000000000 (0x0000) (tous les bits validés)0b11111111111 (0x07FF)Le Rx ne recevra que les messages avec l’Id 0x07FF
0b00000000000 (0x0000) (tous les bits validés)0b01111111110 (0x03FE)Le Rx ne recevra que les messages avec l’Id 0x03FE
0b00000000001 (0x0001)0b01111111111 (0x03FF)Le Rx ne recevra que les messages avec l’Id 0x03FE ou 0x03FF car le bit 0 du filtre est invalidé par le bit 0 du masque
0b00000000001 (0x0001)0b01111111110 (0x03FE)Le Rx ne recevra que les messages avec l’Id 0x03FE ou 0x03FF car le bit 0 du filtre est invalidé (idem cas précédent)
0b00000000000 (0x0000) (tous les bits validés)0b01111111000 (0x03F8)Le Rx ne recevra que les messages avec l’Id 0x03F8
0b00000000111 (0x0007)0b01111111000 (0x03F8)Le Rx recevra tous les messages avec l’Id 0x03F8, 0x03F9, 0x03FA, 0x03FB,0x03FC, 0x03FD, 0x03FE, 0x03FF car les bit 0,1 & 2 du filtre sont invalidés
0b00000000000 (0x0000) (tous les bits validés)0b00000000001 (0x0001)Le Rx ne recevra que les messages avec l’Id 0x001
0b00000000111 (0x0007)0b00000000000 (0x0000)Le Rx recevra tous les messages avec l’Id 0x000,0x001,  0x002, 0x003, 0x004, 0x005, 0x006, 0x007 car les bits 0,1 & 2 jeu filtre sont invalidés
0b11111111000 (0x07F8)0b00000000000 (0x0000)Le Rx recevra tous les messages don’t l’Id se termine par 0, 1, 2, 3, 4, 5, 6, ou 7 (0x121 = acepté, 0x0128 = eliminé)
0b11111111111 (0x07FF)0b00000000000 (0x0000)Tous les messages sont acceptés quelque soit l'identifiant



On pourrait presque dire que le masque et plus prépondérant que le filtre dans cette logique d'acceptance.
Le filtre définit une valeur de base et le masque définit une plage d'acceptance autour de la valeur du filtre.


Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 17, 2021, 05:39:31 pm
S'il n'y avait qu'un seul couple masque-filtre, les possibilités de filtrage seraient limitées.
Le SJA1000 permet d'utiliser 2 couples masque-filtre dont les plages d'acceptance s'additionnent : il suffit qu'un message soit acceptable par l'un des couples pour être autorisé à entrer dans la file de réception.

Contrairement au MCP2515 qui a 2 masques et 6 filtres, l'ESP32 n'a que 2 masques de 32 bits et 2 filtres de 32 bits chacun.
En fait, les masques sont définis dans 4 registres 8 bits AMR0, AMR1, AMR2, AMR3 (dits "Acceptance Mask Registers").
Et les filtres sont définis dans 4 registres 8 bits ACR0, ACR1, ACR2, ACR3 (dits "Acceptance Code Registers").
Ces 8 registres peuvent être combinés de 4 façons différentes pour réaliser le filtrage des messages. Mais, selon le cas, il faut faire attention à ce qu'on fait !

1) Un seul filtre pour messages standard (Id de 11 bits):
L'identifiant de 11 bits, le bit de mode remote RTR et les 2 premiers octets de donnée du message sont inclus dans le processus d'acceptance. Un message peut néanmoins être accepté s'il ne contient qu'un seul ou aucun octet de données ou s'il est un message de remote (bit RTR) donc sans données.
(https://www.locoduino.org/IMG/png/singlefilterstandardframe.png)

2) Deux filtres pour messages standard (Id de 11 bits):
Dans ce cas, le premier filtre compare l'Id entier (11 bits) et le RTR, ainsi que le premier octet de données. Le deuxième filtre compare seulement l'identifiant et le RTR.
(https://www.locoduino.org/IMG/png/dualfilterstandardframe.png)

3) Un seul filtre pour messages étendus (Id de 29 bits):
Ici, la totalité de l'identifiant, incluant le RTR est comparé aux registres.
(https://www.locoduino.org/IMG/png/singlefilterextendedframe.png)

4) Deux filtres pour messages étendus (Id de 29 bits):
Ici, seuls les 2 premiers octets de l'ID sont comparé et ceci pour les 2 filtres.
(https://www.locoduino.org/IMG/png/dualfilterextendedframe.png)


PS: je ne garanti pas les éventuelles erreurs dans les figures qui sont issues de la datasheet !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 17, 2021, 05:39:38 pm
Pour illustrer les possibilités - certes limitées - de filtrage CAN de l'ESP32, la bibliothèque ESP32_CAN propose des exemples correspondant aux cas ci-dessus :
Ils sont traduits de la documentation acan-esp32.pdf qui se trouve dans le dossier "extra" de la bibliothèque.

Dans chaque cas, la définition des filtres et masques tient en une seule ligne dans le setup :

ESP32CANAcceptOnlyStandardFilterDemo
  const ACAN_ESP32_Filter filter = ACAN_ESP32_Filter::acceptStandardFrames () ;
Dans ce cas, les messages étendus sont rejetés et tous les messages standards sont acceptés.

ESP32CANAcceptOnlyExtendedFilterDemo
  const ACAN_ESP32_Filter filter = ACAN_ESP32_Filter::acceptExtendedFrames () ;
Dans ce cas les messages standards sont rejetés et tous les messages étendus sont acceptés.

ESP32CANSingleStandardFilterDemo
  const ACAN_ESP32_Filter filter = ACAN_ESP32_Filter::singleStandardFilter (ACAN_ESP32_Filter::data, 0x123, 0x404) ;
Le premier argument indique si on veut recevoir :
Les bits de 0x404 sont le #2 et #10. Les bits #2 et #10 de 0x123 sont ignorés dans le filtrage. En conséquence les messages d'identifiants 0x123, 0x127, 0x523 et 0x527 sont reçus.
un "0" comme dernier argument indique que le seul message accepté sera celui dont l'identifiant est égal au 2ème argument.

ESP32CANDualStandardFilterDemo
  const ACAN_ESP32_Filter filter = ACAN_ESP32_Filter::dualStandardFilter (
    ACAN_ESP32_Filter::data, 0x123, 0x110,
    ACAN_ESP32_Filter::remote, 0x456, 0x022
  ) ;
Pour le 1er filtre, les bits de 0x110 sont les #4 et #8: bits 4 et 8 de 0x123 sont ignorés dans le filtrage. Donc les identifiants 0x023, 0x033, 0x123 and 0x133 sont recevables.
Pour le 2eme filtre, les bits de 0x022 sont les #1 et #5: bits 1 et 5 de 0x456  sont ignorés dans le filtrage. Donc les identifiants 0x454, 0x456, 0x474 et 0x476 sont recevables et s'ajoutent à ceux du 1er filtre.

ESP32CANSingleExtendedFilterDemo
  const ACAN_ESP32_Filter filter = ACAN_ESP32_Filter::singleExtendedFilter (ACAN_ESP32_Filter::data, 0x12345678, 0x20202) ;
Le 1er argument est "date" ou"remote" ou "dataAndRemote"
Le 3eme argument si "0" indique que le seul message accepté sera celui dont l'identifiant est égal au 2ème argument.
Les bits de 0x20202 sont le #1 , #9 et #17: ils sont ignorés dans le filtrage de 0x12345678.
Donc les identifiants 0x12345478, 0x1234547A, 0x12345678, 0x1234567A, 0x12365478, 0x1236547A, 0x12365678 et 0x1236567A seront acceptés.

ESP32CANDualExtendedFilterDemo
  const ACAN_ESP32_Filter filter = ACAN_ESP32_Filter::dualExtendedFilter (
    0x12345678, 0x00060000, // First filter
    0x19876543, 0x00009000  // Second filter
  ) ;
Noter que les bits 0 to 12 dans les paramètres sont toujours ignorés par ce type de filtre.
Par exemple, le 1er filtre compris entre 0x12344000 et 0x12345FFF donnera toujours le même résultat.
Dans le 2ème masque 0x00009000, le bit #12 est toujours ignoré, donc toutes les valeurs entre 0x00008000 et 0x00009FFF donneront le même résultat. Finallement, ce filtre accepte des messages data et remote étendus dont l'identifiant est de la forme 1 0010 0011 0xx0 010x xxxx xxxx xxxx (215 étendus et 215 remote) ou 1 1001 1000 0111 x00x xxxx xxxx xxxx (214 étendus, 214 remote).

après chaque définition de filtre et masque suit le begin du Can:
  const uint32_t errorCode = ACAN_ESP32::can.begin (settings, filter);
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 17, 2021, 05:40:25 pm
Voici quelques exemples de programmation des filtres et masques avec la bibliothèque ACAN_ESP32 :

1) La méthode settings est crée en indiquant la vitesse du bus CAN (exemple, ici 500 kb/s):

static const uint32_t DESIRED_BIT_RATE = 500UL * 1000UL ; // 0,5 Mb/s
ACAN_ESP32_Settings settings (DESIRED_BIT_RATE) ;

2) On choisit le mode de fonctionnement: NormalMode dans tous les cas de nos réseaux ou LoopBackMode dans les exemples donnés avec la bibliothèque aux fins de test uniquement.
La définition des pins Tx et Rx pour le can sont laissées en commentaire car elles sont celles utilisées par LaBox, donc inchangées par rapport aux valeurs pas défaut.

settings.mRequestedCANMode = ACAN_ESP32_Settings::NormalMode ;
//  settings.mRxPin = GPIO_NUM_4 ; // Optional, default Tx pin is GPIO_NUM_4
//  settings.mTxPin = GPIO_NUM_5 ; // Optional, default Rx pin is GPIO_NUM_5

Si on veut utiliser un seul jeu de masque et filtre, la méthode singleStandardFilter permet de déclarer le type de message (ici data, puis le filtre, puis le masque).
Ensuite on appelle begin avec 2 arguments: settings et filter.
const ACAN_ESP32_Filter filter = ACAN_ESP32_Filter::singleStandardFilter (ACAN_ESP32_Filter::data, 0x000, 0x01F) ;
 // masque = tous les Id acceptes de 00 à 1F
const uint32_t errorCode = ACAN_ESP32::can.begin (settings, filter);

Si on veut utiliser deux jeux de masque et filtre, la méthode dualStandardFilter permet de déclarer deux type de message (ici data, puis le filtre, puis le masque).
Ensuite on appelle begin avec 2 arguments: settings et filter.
const ACAN_ESP32_Filter filter = ACAN_ESP32_Filter::dualStandardFilter (
    ACAN_ESP32_Filter::data, 0x000, 0x00F,    // acceptés de 00 à 0F
    ACAN_ESP32_Filter::data, 0x010, 0x00F);   // acceptés de 10 à 1F
 const uint32_t errorCode = ACAN_ESP32::can.begin (settings, filter);

Enfin, si on ne veut pas de filtrage du tout, il n'y a aucune déclaration de filtre à faire.
Ensuite on appelle begin avec un seul argument: settings.

const uint32_t errorCode = ACAN_ESP32::can.begin (settings) ;

En pièce jointe se trouve le programme de tests que j'ai utilisé sur l'ESP32 de LaBox, en laison CAN avec un satellite qui reçoit des messages avec l'ID 25 et qui emet des messages avec l'Id 15.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 17, 2021, 09:42:02 pm
Test de la version 080 modifiée pour afficher l'HMI:

Test avec manette et Engine Driver
1) la lumière fonctionne et la lumière s'allume sur la loco (avec F5) et les deux fonctions testées aussi  le symbole * s'affiche sur l'Oled

2) Les commandes de vitesse et direction fonctionnent bien

3) Arrêt avec ma manette :

0 From Throttle : t1 19 0 1
0 From Throttle : t1 36 0 1
0 From Throttle : t1 8 0 1
0 From Throttle : t1 18 0 1
Throttle 0 <t1 19 0 1>
<t> parse command
<T1 19 0 1>
0 From Throttle : t1 2 0 1
Throttle 0 <t1 18 0 1>
<t> parse command
<T1 18 0 1>
0 From Throttle : 0
Throttle 0 <t1 2 0 1>
<t> parse command
<T1 2 0 1>
Throttle 0 <0>
<0> parse command
DCCpp PowerOff
<p0>
Throttle 0 <t1 36 0 1>
<t> parse command
<T1 36 0 1>
Throttle 0 <t1 8 0 1>
<t> parse command
<T1 8 0 1>

4) la lecture de l'adresse loco ne fonctionne plus : signal DCC sur les rails, adresse de loco 8 . La machine bouge trois fois la même adresse s'affiche 16383. (trois adresses différentes dans un deuxième test, 2 adresses et un ERROR au 3e)
Le message adresse s'affiche tardivement après déplacements.
0 From Throttle : 1
Throttle 00  From Throttle : t1 19 0 0
<1>
<1> parse command
DCCpp PowerOn
<p1>
0 Message From Throttle :
0 Message From Throttle :
Throttle 0 <t1 19 0 0>
<t> parse command
<T1 19 0 0>
readCVraw : start reading cv 29
bit : 0 iter : 3, max : 34
bit : 1 iter : 7, max : 1113
bit : 2 iter : 7, max : 1021
bit : 3 iter : 18, max : 36
bit : 4 iter : 4, max : 33
bit : 5 iter : 8, max : 32
bit : 6 iter : 14, max : 31
bit : 7 iter : 1, max : 35
verif :  iter : 3, max : 35
readCVraw : start reading cv 18
bit : 0 iter : 7, max : 36
bit : 1 iter : 12, max : 34
bit : 2 iter : 16, max : 40
bit : 3 iter : 3, max : 33
bit : 4 iter : 8, max : 34
bit : 5 iter : 13, max : 32
bit : 6 iter : 18, max : 33
bit : 7 iter : 5, max : 30
verif :  iter : 9, max : 32
readCVraw : start reading cv 17
bit : 0 iter : 14, max : 44
bit : 1 iter : 19, max : 32
bit : 2 iter : 5, max : 34
bit : 3 iter : 10, max : 34
bit : 4 iter : 15, max : 32
bit : 5 iter : 2, max : 34
bit : 6 iter : 7, max : 33
bit : 7 iter : 12, max : 31
verif :  iter : 14, max : 36
readCVraw : start reading cv 29
bit : 0 iter : 18, max : 39
bit : 1 iter : 3, max : 1113
bit : 2 iter : 3, max : 1131
bit : 3 iter : 15, max : 38
bit : 4 iter : 19, max : 41
bit : 5 iter : 1, max : 65
bit : 6 iter : 11, max : 33
bit : 7 iter : 16, max : 38
verif :  iter : 18, max : 34
readCVraw : start reading cv 18
bit : 0 iter : 4, max : 35
bit : 1 iter : 9, max : 35
bit : 2 iter : 6, max : 40
bit : 3 iter : 19, max : 36
bit : 4 iter : 6, max : 33
bit : 5 iter : 11, max : 37
bit : 6 iter : 16, max : 39
bit : 7 iter : 3, max : 33
verif :  iter : 6, max : 36
readCVraw : start reading cv 17
bit : 0 iter : 10, max : 36
bit : 1 iter : 15, max : 39
bit : 2 iter : 1, max : 38
bit : 3 iter : 6, max : 24
bit : 4 iter : 10, max : 33
bit : 5 iter : 14, max : 37
bit : 6 iter : 19, max : 36
bit : 7 iter : 6, max : 31
verif :  iter : 10, max : 35
readCVraw : start reading cv 29
bit : 0 iter : 14, max : 38
bit : 1 iter : 3, max : 1092
bit : 2 iter : 7, max : 1076
bit : 3 iter : 11, max : 38
bit : 4 iter : 17, max : 33
bit : 5 iter : 2, max : 40
bit : 6 iter : 7, max : 37
bit : 7 iter : 13, max : 37
verif :  iter : 14, max : 33
readCVraw : start reading cv 18
bit : 0 iter : 19, max : 35
bit : 1 iter : 5, max : 34
bit : 2 iter : 10, max : 40
bit : 3 iter : 15, max : 37
bit : 4 iter : 2, max : 36
bit : 5 iter : 6, max : 19
bit : 6 iter : 12, max : 36
bit : 7 iter : 17, max : 35
verif :  iter : 2, max : 36
readCVraw : start reading cv 17
bit : 0 iter : 6, max : 38
bit : 1 iter : 11, max : 36
bit : 2 iter : 15, max : 37
bit : 3 iter : 2, max : 39
bit : 4 iter : 2, max : 65
bit : 5 iter : 12, max : 36
bit : 6 iter : 17, max : 36
bit : 7 iter : 4, max : 35
verif :  iter : 5, max : 27

A suivre.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 17, 2021, 09:48:37 pm
tiens, c'est déjà mieux que mes tests

La lumière s'allume effectivement en cliquant sur "light" puis F1 (ou F2 ou F3 ou F4). un clic sur light eteint la lumière.
Je ne lis toujours pas l'adresse
Je continue les tests.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 17, 2021, 10:07:49 pm
Curieux, dans mon relevé sur le serial, il n'y a pas de tentative de lecture du CV1 ...
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 17, 2021, 10:11:55 pm
Curieux, dans mon relevé sur le serial, il n'y a pas de tentative de lecture du CV1 ...

ne serait-ce pas le transmetteur radio qui bloque le RxTx de l'USB ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 17, 2021, 10:25:21 pm
Non, pas de changement, les messages sont propres,
seuls les CV 29, 18 et 17 sont lus - trois fois.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 18, 2021, 09:22:02 am
Pour les fonctions, je suis d'accord, ça ne marche pas bien, je dois repasser un peu de temps.
Pour les vitesses, j'ai testé avec EngineDriver et c'est conforme aux spécifications : la vitesse la plus basse est le cran DCC '0' (arrêt total) qui est atteinte soit au curseur, soit avec le bouton arrêt de l'application sous le curseur. Le bouton 'Idle', qui est une icône de main sur EngineDriver, envoie la vitesse DCC '1' qui  selon la norme est un arrêt d'urgence. Je dois essayer avec WiThrottle mais je ne vois pas ce qui pourrais changer... Pour la lecture de CV, je n'ai pas les moyens de tester pour le moment...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 18, 2021, 12:15:28 pm
Thierry,
Je suis d'accord avec toi pour les vitesses sur Withrottle: c'est la même chose avec une curiosité : en quittant Withrottle, la vitesse affichée sur l'Oled passe à 0 mais la loco ne s'arrête pas. Sur le moniteur le throttle 5 est disconnected après la commande Q
11:59:08.755 -> 5 From Throttle : MT-S18<;>r
11:59:08.860 -> 5 From Throttle : Q
11:59:08.860 -> Throttle 5 MT-S18<;>r
11:59:08.860 -> 5 -> <T1 18 34 0>MT-S18<;>
11:59:08.860 -> Locomotives ------------------
11:59:08.860 -> 0 : Loco reg:1 id:18 max:128      +/-speed:-33      functions: 1
11:59:08.860 -> 1 : Loco reg:2 id:14 max:128      +/-speed:0      functions:
11:59:08.959 -> Throttle 5 Q
11:59:08.959 -> Converter : client 5 disconnected

En ce qui concerne la lecture des CVs, rien ne marche (comme Michel) et pourrais-tu me dire où il faut regarder ou comparer le code ?
Ma mesure de courant sur l'Oled a l'air correcte (environ 50 mA avec ma petite loco, <5mA quand elle s'arrête suite à un mauvais contact).
Le message ERROR s'affiche juste après l'échec de la lecture du CV1 mais juste une fraction de seconde !
A la fin le throttle est déconnecté.

11:51:23.777 -> readCVraw : start reading cv 29
11:51:23.850 -> bit : 0 iter : 15, max : 5
11:51:24.484 -> bit : 1 iter : 6, max : 8
11:51:25.152 -> bit : 2 iter : 5, max : 7
11:51:25.787 -> bit : 3 iter : 0, max : 5
11:51:26.458 -> bit : 4 iter : 6, max : 6
11:51:27.122 -> bit : 5 iter : 1, max : 7
11:51:27.760 -> bit : 6 iter : 0, max : 5
11:51:28.420 -> bit : 7 iter : 12, max : 6
11:51:29.064 -> verif :  iter : 14, max : 5
11:51:29.666 -> readCVraw : start reading cv 1
11:51:29.734 -> bit : 0 iter : 10, max : 4
11:51:30.392 -> bit : 1 iter : 1, max : 11
11:51:31.020 -> bit : 2 iter : 7, max : 4
11:51:31.679 -> bit : 3 iter : 6, max : 5
11:51:32.336 -> bit : 4 iter : 12, max : 6
11:51:32.977 -> bit : 5 iter : 3, max : 5
11:51:33.645 -> bit : 6 iter : 2, max : 3
11:51:34.266 -> bit : 7 iter : 11, max : 7
11:51:34.957 -> verif :  iter : 6, max : 5
11:51:35.616 -> readCVraw : start reading cv 29
11:51:35.683 -> bit : 0 iter : 3, max : 3
11:51:36.320 -> bit : 1 iter : 1, max : 5
11:51:36.986 -> bit : 2 iter : 9, max : 5
11:51:37.636 -> bit : 3 iter : 12, max : 5
11:51:38.292 -> bit : 4 iter : 0, max : 5
11:51:38.927 -> bit : 5 iter : 17, max : 6
11:51:39.596 -> bit : 6 iter : 5, max : 4
11:51:40.259 -> bit : 7 iter : 17, max : 4
11:51:40.891 -> verif :  iter : 19, max : 6
11:51:41.473 -> readCVraw : start reading cv 1
11:51:41.545 -> bit : 0 iter : 8, max : 6
11:51:42.208 -> bit : 1 iter : 17, max : 7
11:51:42.870 -> bit : 2 iter : 19, max : 5
11:51:43.490 -> bit : 3 iter : 18, max : 5
11:51:44.159 -> bit : 4 iter : 14, max : 6
11:51:44.825 -> bit : 5 iter : 8, max : 4
11:51:45.449 -> bit : 6 iter : 18, max : 4
11:51:46.115 -> bit : 7 iter : 2, max : 3
11:51:46.777 -> verif :  iter : 18, max : 4
11:51:47.435 -> readCVraw : start reading cv 29
11:51:47.502 -> bit : 0 iter : 7, max : 5
11:51:48.154 -> bit : 1 iter : 17, max : 5
11:51:48.815 -> bit : 2 iter : 5, max : 5
11:51:49.474 -> bit : 3 iter : 0, max : 5
11:51:50.100 -> bit : 4 iter : 2, max : 3
11:51:50.769 -> bit : 5 iter : 11, max : 6
11:51:51.397 -> bit : 6 iter : 3, max : 3
11:51:52.058 -> bit : 7 iter : 0, max : 3
11:51:52.718 -> verif :  iter : 10, max : 6
11:51:53.322 -> readCVraw : start reading cv 1
11:51:53.389 -> bit : 0 iter : 2, max : 5
11:51:54.039 -> bit : 1 iter : 11, max : 6
11:51:54.705 -> bit : 2 iter : 7, max : 5
11:51:55.326 -> bit : 3 iter : 12, max : 6
11:51:55.977 -> bit : 4 iter : 4, max : 6
11:51:56.630 -> bit : 5 iter : 6, max : 3
11:51:57.284 -> bit : 6 iter : 8, max : 5
11:51:57.955 -> bit : 7 iter : 10, max : 6
11:51:58.626 -> verif :  iter : 9, max : 5
11:52:09.962 -> Converter : client 5 disconnected

Une remarque au passage :
La manette de michel démarre le DCC à la fin de son setup (elle envoie <1>, même plusieurs fois)
Withrottle n'envoie <1> qu'après la connexion wifi, ce qui est normal
Mais pour récupérer l'adresse DCC d'une loco, il faut donc connecter un Throttle au préalable. La commande du menu HMI ne le fait pas !
Ne serait-il pas utile d'établir le DCC (comme <1>) juste avant une lecture d'adresse, quite à le couper juste après s'il n'y a aucun throttle connecté ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 18, 2021, 09:31:56 pm
Nouvelle version 0.8.1 :

Corrige le bouton 'Stop' de WiThrottle qui mets bien maintenant la vitesse DCC à 1 (arrêt urgence).
Corrige le bouton 'Idle' de WiThrottle qui mets bien maintenant la vitesse DCC à 0 (arrêt total normal).
Stoppe l'effet 'timeout' de déconnexion des throttles pendant la lecture de l'adresse de la loco.
Corrige un problème de compilation sur l'IDE 2.0 Beta 6.
Allumage du DCC si une demande de lecture d'adresse de loco a été faite au menu.
Ajout de la led de statut pendant le setup() dans labox.ino (merci Dominique).
Retrait de la répétition des fonctions pour le moment.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le mai 19, 2021, 10:04:13 am
Je trouve pas le pouce bleu ! D'ou qu'il est le pouce bleu ???? :D

Thx Thierry !
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 19, 2021, 10:42:13 am
Nouvelle version 0.8.1 :

Corrige le bouton 'Stop' de WiThrottle qui mets bien maintenant la vitesse DCC à 1 (arrêt urgence).
OK
Citer
Corrige le bouton 'Idle' de WiThrottle qui mets bien maintenant la vitesse DCC à 0 (arrêt total normal).
OK
Citer
Stoppe l'effet 'timeout' de déconnexion des throttles pendant la lecture de l'adresse de la loco.
NoK : le throttle est toujours déconnecté à la fin de la lecture
Et la lecture ne se fait pas : la loco ne gigote pas, ce qui me fait supposer que les commandes de lecture de CV sur la main ne sont pas émises.
Alors que les commandes de vitesse/direction et fonction sont bien émises.
A vérifier au sniffer DCC.
Citer
Corrige un problème de compilation sur l'IDE 2.0 Beta 6.
je n'ai pas pu tester
Citer
Allumage du DCC si une demande de lecture d'adresse de loco a été faite au menu.
OK
Citer
Ajout de la led de statut pendant le setup() dans labox.ino (merci Dominique).
OK: merci Thierry
Citer
Retrait de la répétition des fonctions pour le moment.
Pour allumer les lumières (phares), il faut encore cliquer sur FL, puis F1 (ou F2..). Un nouveau clic sur F0 eteint les lumières.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: CATPLUS le mai 19, 2021, 02:53:41 pm
Viens de tester la nouvelle Version 0.8.1 avec  Engine Driver

Connexion => ok
Choix loco  => ok
Sens de marche => ok
Arrêt affichage rouge => ok

Si la loco est allumée, avec changement de sens les  leds => ok
Si appuis sur F0 arrêt de lumière. IMPOSSIBLE de remettre en activité la lumière. En touchant la touche de fonction F2 on arrive a remettre en route.
C'est la loterie ou Aléatoire. Puis a un moment la loco ne répond plus. Blocage, il faut relancer le system
A noter l'affichage sur l'Oled de l'icone lumière, il s’allume & s'éteint avec la touche de fonction F0 => ok

J'ai refait un test avec la version 0.7.6 => aucun problème
Marcel



Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 19, 2021, 07:02:03 pm
Une version 0.8.2 est sortie et devrait corriger les problèmes de fonction.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: DDEFF le mai 19, 2021, 07:17:28 pm
Je suis sûr que la version ESP32 de Thierry finira par être parfaitement au point (et même meilleure que certaines solutions du commerce)
On voit son évolution en direct. C'est impressionnant!

Bravo Thierry !  ;D

(https://www.locoduino.org/IMG/png/pouce_bleu.png)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le mai 19, 2021, 08:18:01 pm
Ah ben voilà ! ça c'est du pouce bleu ! Merci Thierry, et merci Denis !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 19, 2021, 10:03:44 pm
Effectivement les fonctions ont un comportement classique (non répétées)
Mais pour la recherche d'adresse, j'ai maintenant le même comportement que signale Dominique : la loco ne bouge pas à tous les coups et l'affichage d'une fausse adresse disparait en un clin d’œil.
J'ai des adresses courtes et le CV1 n'est pas lu.
J'ai compilé LaBox à partir de l'exemple en ayant remplacé la totalité de la library.
Bon courage !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le mai 20, 2021, 09:02:48 am
Dans la suite d'échanges sur ce fil au sujet du MCP2562 implanté avec un ESP32 et aux recommandations de Jean-Luc,

https://forum.locoduino.org/index.php?topic=922.msg13002#msg13002

voici le montage que j'ai réalisé sur un PCB. Cela fonctionne parfaitement jusqu'à 1Mbs.

Sur la photo, il s'agit d'une petite carte "universelle" pour simplifier l'utilisation des ESP32 et en particulier la connexion CAN, mais cela vaut pour toutes autres utilisations.

Exit pour moi les CJMCU-230 SN65HVD230 foireuses !

(https://alkans.fr/locoduino/img/_DSC9055.jpg)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 21, 2021, 01:40:41 pm
Très jolie carte : bravo Christophe,

Peux-tu joindre le schéma ?
J'idée d'avoir une passerelle WiFi-Can avance dans mon réseau. Je serais intéressé par un couple de cartes de ce type, ainsi que la source des ESP32 30 pins utilisés.

Merci d'avance
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 21, 2021, 04:01:58 pm
Suite des tests des masques et filtres CAN (de la page précédente) :

Voici le programme LaBox avec gestion des messages CAN échangés avec un satellite (N°5) qui fonctionne en même temps que les commandes de loco avec un smartphone

Il est basé sur le programme exemple LaBox avec la bibliothèque version 0.8.2, auquel est ajouté le test Can présenté à la page précédente :
https://forum.locoduino.org/index.php?topic=922.msg13295#msg13295 (https://forum.locoduino.org/index.php?topic=922.msg13295#msg13295)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 21, 2021, 05:00:24 pm
J'en reviens pas : je branche et ça marche avec un VP230 (ponté).
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 21, 2021, 08:17:09 pm
Je n’en doutais pas.  ;) :D

Exercice plus difficile : la page précédente sur masques et filtres est-elle claire ?
Je l’ai refaite en faisant les tests, les masques fonctionnant différemment de ce que je pensais.
Attention, c’est peut-être différents sur d’autres contrôleurs Can  ???
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le juin 03, 2021, 08:48:26 pm
Nouvelle version 0.9.0 de LaBox.
Le but de cette nouvelle version était principalement de régler ces histoires de lecture de Cv. On verra plus tard pour l'écriture !

- La nouvelle fonctionnalité de mise en route du DCC (powerOn() ) dès la demande de lecture a provoqué le premier problème : j'ai ajouté un délai de 200ms lors de l'alumage du DCC pour permettre au décodeur dans la loco de s'initialiser correctement. C'est ce qui expliquait la perte systématique du premier bit...
- J'ai transformé la routine d'aquisition du ack pour qu'elle dépende d'un temps au delà duquel le ack n'est pas validé (100ms) et non de la durée de deux boucles imbriquées.
- J'ai ajouté un affichage en debug du résultat plus parlant je pense, y compris pour la vérification de ce qui a été lu.
- Les routines DCCpp::readCvMain() et DCCpp::readCvProg() ont été crées pour forcer trois essais de lecture à chaque Cv lue. Dès qu'une vérification valide la lecture, on passe au CV suivant.
- J'ai supprimé le lissage effectué lors de la lecture du ack pour prendre les valeurs brutes...
- analogRead() a été remplacée par une fonction plus bas niveau de l'ESP32 et plus rapide.

Avec ces premières mesures, la lecture de l'adresse de la loco fonctionne à 99% (en tout cas sur ma vieille G2000 ...) .

- J'ai ajouté une fonction DCCpp::getDecoderInfo() qui est censée renvoyer les données du constructeur grace à la lecture des Cv 8 et 7. Une matrice constante a été créée à partir des fichiers de config de JMRI pour cette liste, plus complète que celle du NMRA.

Malgré ces avancées, il subsiste des problèmes :
- Justement, la lecture du Cv8 ne fonctionne pas du tout, et je n'ai pas d'explication... Donc getDecoderInfo a le mérite d'exister, mais elle n'est pas testée !
- Les timings renvoyés par l'affichage du résultat du ack sont fantaisistes. Un ack devrait durer en 4000 et 6500 micro-secondes d'après le NMRA, hors j'en trouve à plus de 20000 et à moins de 2000 ! J'ignore si le calcul de temps est le problème ou si c'est juste ma G2000 et son décodeur qui font des fantaisies. A noter que dans DCC++Ex pour Uno/Mega, le timing est précisément mesuré et ce qui en sort (entre 2000 et 8500us chez eux) n'est pas validé !

Voili, voilou.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le juin 04, 2021, 02:25:23 pm
Merci Thierry pour ce travail en profondeur  ;D

J'ai installé la version 0.9.0 ce matin et le fonctionnement de ma petite locomotive habituelle est toujours bon, mais la lecture des CVs échoue encore. Cependant j'ai senti bouger la locomotive un peu (très peu) avec une trace sur le moniteur :
readCVraw : start reading cv 29
Bit  : 0, NO-ACK, samples : 101, gaps : 0, max : -131, start : 0us, duration : 0us
Bit  : 1, ACK   , samples : 56, gaps : 12, max : 33, start : 43887us, duration : 12001us
Bit  : 2, ACK   , samples : 31, gaps : 13, max : 35, start : 17713us, duration : 13002us
Bit  : 3, NO-ACK, samples : 101, gaps : 0, max : -131, start : 0us, duration : 0us
Bit  : 4, NO-ACK, samples : 100, gaps : 0, max : -131, start : 0us, duration : 0us
Bit  : 5, NO-ACK, samples : 101, gaps : 0, max : -131, start : 0us, duration : 0us
Bit  : 6, NO-ACK, samples : 100, gaps : 0, max : -131, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 100, gaps : 0, max : -131, start : 0us, duration : 0us
Verif:  , NO-ACK, samples : 101, gaps : 0, max : -131, start : 0us, duration : 0us
qui prouve qu'une commande est bien parvenue à la locomotive.
Mais les répétitions sont différentes et échouent à 100%
J'ai une autre locomotive à tester, sinon ce sera la semaine prochaine à mon retour à la maison.

On voit maintenant le message "error" assez longtemps et le processus est plus rapide.
A suivre..
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le juin 04, 2021, 02:52:07 pm
Petit souci de mon coté : le HMI doit être commenté quelque part (problème déjà rencontré mais je n'a pas retrouvé le message indiquant la ligne à dé-commenter ...)
Les lignes s'effacent et ne peuvent être sélectionnées.
J'ai récupéré la totalité de LaBox sur le git et compilé avec la 1.8.13 et la 2.0.0
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le juin 04, 2021, 04:01:24 pm
La ligne en question était le HMI.begin() du setup dans le .ino, mais ce n'est plus commenté normalement.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le juin 04, 2021, 04:51:46 pm
En effet c'est ligne 70 de LaBox.ino

  //----------- Start HMI -------------
  boxHMI.begin();

A chaque nouvelle version de la bibliothèque il vaut mieux repartir de l'exemple LaBox dans le dossier exemples de la bibliothèque.

A noter que la bibliothèque LaBox a besoin des autres bibliothèques (listées dans la doc page 23) nécessaires pour réaliser une compilation avec succès :
"Adafruit_GFX"
"Adafruit_SSD1306"
"OneButton"
"ArduinoJson"
Ces dernières bibliothèques sont installables par l'IDE Arduino (menu Croquis/Inclure une Bibliothèque/Gérer les bibliothèques).
Je fais également leur mise à jour au fur et à mesure des versions Labox à tester.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le juin 04, 2021, 05:53:53 pm
J'ai fait un nouveau test de lecture d'adresse de ma locomotive d'adresse 18 : seule la lecture du CV29 est tentée et échoue à chaque fois.
readCVraw : start reading cv 29
Bit  : 0, ACK   , samples : 24, gaps : 1, max : 32, start : 22992us, duration : 1006us
Bit  : 1, ACK   , samples : 95, gaps : 1, max : 33, start : 94004us, duration : 1008us
Bit  : 2, NO-ACK, samples : 101, gaps : 0, max : -112, start : 0us, duration : 0us
Bit  : 3, ACK   , samples : 87, gaps : 1, max : 37, start : 86134us, duration : 1003us
Bit  : 4, NO-ACK, samples : 100, gaps : 0, max : -112, start : 0us, duration : 0us
Bit  : 5, ACK   , samples : 86, gaps : 1, max : 33, start : 84885us, duration : 999us
Bit  : 6, NO-ACK, samples : 100, gaps : 0, max : -112, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 101, gaps : 0, max : -112, start : 0us, duration : 0us
Verif:  , NO-ACK, samples : 100, gaps : 0, max : -119, start : 0us, duration : 0us

Je ne recopie pas toutes les tentatives qui sont toutes différentes (les bits ACK ne sont pas au même endroit).

Finalement en essayant 5-6 fois et en appuyant avec le doigt sur le loco, son adresse 18 apparait enfin, mais les bits du CV 29 me semblent bizarres (0 n'est pas normal) :
readCVraw : start reading cv 29
Bit  : 0, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 1, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 2, NO-ACK, samples : 100, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 3, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 4, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 5, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 6, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 100, gaps : 0, max : -113, start : 0us, duration : 0us
Verif:  , ACK   , samples : 27, gaps : 2, max : 32, start : 24938us, duration : 2003us
readCVraw : start reading cv 1
Bit  : 0, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 1, ACK   , samples : 16, gaps : 1, max : 35, start : 15027us, duration : 1002us
Bit  : 2, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 3, NO-ACK, samples : 100, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 4, ACK   , samples : 66, gaps : 1, max : 31, start : 64901us, duration : 1000us
Bit  : 5, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 6, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 100, gaps : 0, max : -113, start : 0us, duration : 0us
Verif:  , ACK   , samples : 11, gaps : 2, max : 39, start : 8609us, duration : 1998us

J'apprécie la nouvelle logique de lecture des CVs. Quand le CV29 est validé, ça passe au CV1 (dans le cas des adresses courtes).
Ce qui est dommage c'est qu'après avoir "vu" l'adresse 18, la recherche recommence et échoue finalement.

J'aimerai savoir ce que signifie les valeurs affichées pour chaque bit...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le juin 04, 2021, 06:31:00 pm
De mon coté, erreur de raisonnement, des causes différentes peuvent produire les mêmes effets ...
Ici c'était le bouton Select qui ne faisait plus contact.

Donc, mes locos bougent et font afficher imperturbablement 16383. (adresses 8 et 12)
Et à l'occasion la lecture finit par en faire partir une toute seule.

En PJ ce que voit le sniffer (3e/3)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le juin 04, 2021, 06:59:00 pm
Suite au remarques, petite version 0.9.1 pour tenter d'améliorer les choses :

- La lecture affiche maintenant la valeur lue sur la console, ça n'y était même pas !
- Toute lecture de Cv, et pas uniquement celles faites par identifyLocoId(), provoque la mise en route DCC.
- Un délai de 50ms a été ajouté au cas où entre deux tentatives...
- Enfin le meilleur pour la fin, l'application Z21 permet maintenant de lire les Cvs en demandant à les lire sur la voie de programmation ! Bien pratique pour tester...

De mon côté, j'ai essayé ma vieille G2000 semble t-il équipée d'un décodeur Viessmann, une Class 66 Kato qui prétends avoir un décodeur Trix (?), et une Bachmann S4. Toutes les trois répondent, à des degrés divers. La lecture d'une Cv isolée par l'appli z21 marche mieux que l'identification par LaBox... Enfin la Bachmann veut aussi avancer dès qu'elle est sur les rails alors qu'aucune throttle n'est encore connectée ! A noter que les durées de ack sont bien plus conformes avec la Kato et la Bachmann... Bien plus que le décodeur Viessmann.

Pour Dominique, petite explication des affichages de lecture de bit   'Bit  : 0, ACK   , samples : 24, gaps : 1, max : 32, start : 22992us, duration : 1006us'  :

- samples : nombre de valeurs mesurées, généralement entre 100 et 102 lors d'un NO_ACK. La mesure est interrompue lorsque que la fin d'un ACK est détectée, donc le nombre de mesures est inférieur.
- gaps : parmi les mesures, nombre de celles qui ont dépassé le seuil.
- max : seuil le plus haut mesuré parmi les gaps. Rappelons que la valeur par défaut du ackThreshold est fixée à 30... La valeur est en relatif par rapport à la valeur de base relevée avant les mesures. Donc autour de 0 lorsqu'il n'y a pas de ack, et à ackThreshold plus un chouilla lors d'un ack.
- start: date de début du ack depuis le début de la boucle de mesures.
- duration : durée du ack.

A noter aussi que la Bachmann renvoie des valeurs d'environ 100, la Kato de plus de 200, tandis que la G200 monte à 450 ! Il y a peut être de grosses différences de consommation entre les modèles de décodeur, et/ou des moteurs des machines.
Peut être qu'en réduisant le seuil à 20 ou 25, on aurait plus de résultats à tester sur des machines peu puissantes.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le juin 04, 2021, 07:26:43 pm
Je vais tester à nouveau le petit décodeur Fleischmann dans ma loco, sans doute en baissant un peu le seuil ackThreshold.

Pour une prochaine version, je verrai bien le processus de lecture s’arrêter quand le résultat est trouvé, sans recommencer une lecture.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le juin 04, 2021, 08:18:30 pm
Oui, la lecture continue est causée par le menu, pas par la fonction d'identification... Je pense que ce n'est pas le bon événement qui est utilisé. Cedric ? Ton avis ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le juin 04, 2021, 08:42:30 pm
0.9.1 peu de changement pour moi, testé avec un "gros" moteur ROCO aussi. (255, 3, ERROR au milieu).
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le juin 05, 2021, 06:29:47 pm
J'ai testé la version 0.9.1 en ajoutant, dans l'exemple LaBox un petit moyen de faire varier le AckThreshold pour voir si la sensibilité change la lecture des CVs sans reverser le sketch à chaque changement:

il faut évidemment désactiver le throttleSerial dans le setup:
  //throttleSerial.begin();

void loop()
{
  boxHMI.update();
  DCCpp::loop();

  if (Serial.available()) {
    char inChar = Serial.read();
    if (inChar == '+') ackNewValue += 1;
    if (inChar == '-') ackNewValue -= 1;
    int old;
    old = DCCpp::setAckThreshold(ackNewValue);
    Serial.print("AckThreshold old ");Serial.print(old);
    Serial.print(" -> new ");Serial.println(ackNewValue);
  }
}

Je n'ai obtenu aucun résultat probant. Sur une dizaine d'essais je n'ai vu la lecture du CV 29 correcte (=6 dans mon cas) qu'une seule fois. Parfois, les bits lus sont bons mais la vérification échoue. Au total, la lecture des CVs 29 et 1 n'a jamais été correcte

Deux hypothèses :
1) Les commandes de lecture d'un CV (bit 8 fois et byte 1 fois par CV) n'arrivent pas à temps au décodeur dans la locomotive pour être exécutées.
Je pense que cette hypothèse est bonne car en posant un doigt sur ma locomotive, je la sens bien bouger à chaque fois qu'une réponse ACK a lieu. Par exemple :
readCVraw : start reading cv 29
Bit  : 0, NO-ACK, samples : 100, gaps : 0, max : 12, start : 0us, duration : 0us
Bit  : 1, ACK   , samples : 48, gaps : 13, max : 358, start : 34914us, duration : 13001us
Bit  : 2, ACK   , samples : 48, gaps : 13, max : 370, start : 34799us, duration : 13000us
Bit  : 3, NO-ACK, samples : 101, gaps : 0, max : 20, start : 0us, duration : 0us
Bit  : 4, NO-ACK, samples : 100, gaps : 0, max : 21, start : 0us, duration : 0us
Bit  : 5, NO-ACK, samples : 101, gaps : 0, max : 12, start : 0us, duration : 0us
Bit  : 6, NO-ACK, samples : 100, gaps : 0, max : 14, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 101, gaps : 0, max : 20, start : 0us, duration : 0us
Verif:  , NO-ACK, samples : 101, gaps : 0, max : 13, start : 0us, duration : 0us
end reading value:-1
Là j'ai senti 2 coups pour les bits 1 et 2 (c'est normal), mais rien pour la vérification.

Ici ça a marché et j'ai senti 3 coups sur le CV29, puis 3 sur le 1:
readCVraw : start reading cv 29
Bit  : 0, NO-ACK, samples : 100, gaps : 0, max : 16, start : 0us, duration : 0us
Bit  : 1, ACK   , samples : 48, gaps : 13, max : 344, start : 34914us, duration : 13000us
Bit  : 2, ACK   , samples : 48, gaps : 13, max : 341, start : 34796us, duration : 13000us
Bit  : 3, NO-ACK, samples : 101, gaps : 0, max : 16, start : 0us, duration : 0us
Bit  : 4, NO-ACK, samples : 100, gaps : 0, max : 15, start : 0us, duration : 0us
Bit  : 5, NO-ACK, samples : 101, gaps : 0, max : 18, start : 0us, duration : 0us
Bit  : 6, NO-ACK, samples : 100, gaps : 0, max : 11, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 101, gaps : 0, max : 14, start : 0us, duration : 0us
Verif:  , ACK   , samples : 32, gaps : 13, max : 349, start : 18596us, duration : 12996us
end reading value:6
readCVraw : start reading cv 1
Bit  : 0, NO-ACK, samples : 101, gaps : 0, max : 29, start : 0us, duration : 0us
Bit  : 1, ACK   , samples : 87, gaps : 1, max : 35, start : 85919us, duration : 999us
Bit  : 2, NO-ACK, samples : 101, gaps : 0, max : 30, start : 0us, duration : 0us
Bit  : 3, NO-ACK, samples : 101, gaps : 0, max : 27, start : 0us, duration : 0us
Bit  : 4, ACK   , samples : 53, gaps : 17, max : 378, start : 35904us, duration : 17000us
Bit  : 5, NO-ACK, samples : 101, gaps : 0, max : 31, start : 0us, duration : 0us
Bit  : 6, NO-ACK, samples : 101, gaps : 0, max : 28, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 101, gaps : 0, max : 29, start : 0us, duration : 0us
Verif:  , ACK   , samples : 32, gaps : 13, max : 364, start : 18978us, duration : 12996us
end reading value:18

Mais j'ai un doute pour le CV1 !

2) La lecture (série d'analogueRead ou équivalent) n'est pas centrée sur l'arrivée de l'impulsion de courant (6 ms, 60mA).
Cela peut se déduire des valeurs lues : quand le max est élevé (+ de 300), c'est bon, sinon (35 ci-dessus) c'est mauvais et cela se confirme en regardant la duration qui est faible et qui démontre que la plage de lecture doit être décalée par rapport à l'impulsion de courant (tout est "raduc").
Il me semble que cette hypothèse est aussi bonne !

Je pense qu'il faudrait élargir la plage de lecture (donc lire plus d'échantillons).
Ou enchainer plusieurs plages de lecture courtes comme je l'avais proposé dans les versions antérieures et choisir la meilleure plage. Si un bit est à 0, il n'y aura aucune plage valable de toute façon.
Je n'ai pas eu le temps de me replonger dans le code donc c'est une hypothèse personnelle ;)
Mais les anciennes versions fonctionnent toujours bien sur cette fonction (2 exemplaires OK toujours en service)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le juin 09, 2021, 05:14:19 pm
A titre de comparaison, ce qu'on voit au sniffer quand une multiMAUS + z21 interroge le CV1 d'une loco (CV1 = 8).

Et là, il faut alimenter le sniffer car la z21 coupe le courant en attendant une commande.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le juin 09, 2021, 05:47:32 pm
Et avec "Une station DCC complète, polyvalente et économique avec JMRI " version UNO et GY-169 sur A1. DCCpp_UNO d’origine (DCC++) alimenté en 12v ou en 15V, lecture à 100% avec <R 1 123 123>.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le juin 09, 2021, 06:41:45 pm
Est-ce que ce serait possible de traduire cet affichage en commandes et réponses de type NMRA :
- reset packet
- bit read
- iodle packet
- verify packet

Sachant que LaBox (et DCCpp) appliquent cette suite d'instructions :
       loadPacket(0, resetPacket, 2, 3);         // NMRA recommends starting with 3 reset packets
loadPacket(0, bRead, 3, 5);                // NMRA recommends 5 verify packets
// loadPacket(0, resetPacket, 2, 1);         // forces code to wait until all repeats of bRead are completed (and decoder begins to respond)
loadPacket(0, idlePacket, 2, 6);          // NMRA recommends 6 idle or reset packets for decoder recovery time

ret = RegisterList::checkAcknowlegde(i, channel, base);

En se focalisant sur ces types de paquets, on y verrait plus clair pour la lecture de CV.
Quand j'aurai reçu mes ESP32 je tenterai de faire ce décodage, mais pas tout de suite.. désolé !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le juin 09, 2021, 08:25:34 pm
... beyond my skills !
mais la piste à suivre est là : https://rudysmodelrailway.wordpress.com/2015/10/23/dcc-sniffer-packet-analyser-with-arduino/
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le juin 09, 2021, 09:08:14 pm
Super, la piste est bonne  ;D
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le juin 09, 2021, 09:22:43 pm
Version 2 :

https://github.com/cbries/modeling/blob/master/Arduino%20DCC/Arduino_DCC_S88/RB_DCC_Sniffer_v2/RB_DCC_Sniffer_v2.ino

Plus récent mais même inspiration :

https://github.com/DCC-EX/DCCInspector-EX

Je pense que le sniffer ne voit que les paquets de commande, il n'est pas équipé pour détecter les pics de consommation.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le juin 09, 2021, 11:08:31 pm

https://github.com/DCC-EX/DCCInspector-EX

Je pense que le sniffer ne voit que les paquets de commande, il n'est pas équipé pour détecter les pics de consommation.

Oui c’est sur, l’oscillo s’impose  ;)

Mais là on a un projet intéressant 🤔 avec un model de hardware.
Bravo pour la super 👍 🔦 recherche 🧐
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: laurentr le juin 12, 2021, 11:46:50 pm
Bonsoir à tous

Dominique, une suggestion qui me vient par rapport a ces soucis de lecture de cv et de ack...
Je vais faire une analogie avec la DR5000 qui dispose d un paramètre d ajustement de la sensibilité du hack
En effet la norme donne une certaine durée et un certaine consommation sur cette durée.
Cependant il arrive que cela soit plus aléatoire Qu autre chose... 6ms c est bref. Passer à 8 améliore parfois aussi un peu les choses...
Par chance la DR5000 dispose d une option qui permet de régler le seuil de charge ou pour ainsi dire le seuil à partir du quel elle doit interpréter un ack. On peut ainsi descendre assez bas ce qui est un avantage certain notamment quand on programme des décodeurs d accessoires qui ne disposent pas de moteur et ont donc une faible consommation.
 A voir si cette piste peut aider au delà d un code affinné et adapté...

Nul doute que vous aller percer ces mystères!

Laurent

Mon interprétation est la suivante: en cas de sensibilité inadaptée en jouant sur ce seuil on a de bien meilleurs résultats de lecture !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: train56 le juillet 03, 2021, 10:05:59 pm
Bonjour à tous,

Je suis admiratif devant vos connaissances, je vous suis depuis un temps certain , je cherchais à faire coexister centrale DCC++ et Can, je crois que grâce à vous j'ai trouvé la solution. J'ai déjà réalisé une centrale DCC economique avec un uno et un LMD18200. Mais je vais sauter le pas pour passer à cette box. Pour ce faire reste-t-il un PCB que je souhaitherais acquérir, avant d' en commander  chez JLCPCB auquel cas j'en aurai 4 de dispo.
Cdt
Hervé
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le août 06, 2021, 10:48:47 am
Bonjour,

un petit revamping de LaBox 0.1 en boite :

1. pour avoir la visibilité sur la présence du DCC avec un petit perçage au diamètre 3 à l'arrière et sur le dessus pour y mettre un bout de rond de même diamètre en acrylique transparent.

2. Et puis pour avoir accès aux boutons BOOT et/ou ENABLE : un ou deux petits trous sur le dessus de la boite en face des dits boutons : accès via un trombone. BOOT est utile pour lancer le téléchargement du programme et ENABLE permet d'afficher les messages à la console.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le août 07, 2021, 03:20:41 pm
Bonjour,

autre amélioration de LaBox 0.1  :

il apparait que le seuil (threshold) de détection de courant pour la lecture des CV, modifié à 80 pour l'ESP32 (30 utilisé par DCC++ sur UNO) conduit à une détection de 140 mA dans le cas de LaBox : 80 / 4095 x 3.3V

Pour se rapprocher des 60 mA de la norme NMRA, sans modifier le programme, il suffit de réduire le gain de la détection de courant de 1 V/A à 0,5 V/A en sortie du LM358.

Et donc de mettre une résistance de 15K au dos du pcb en parallèle avec la R3 de 33K. Ce qui donne une valeur équivalente de ~10Kohm.

Sur mon exemplaire, la lecture du CV 1 est quasi systématique même avec un décodeur récalcitrant. *** LaBox LIBRARY : 0.7.13 COMPILED : Apr 25 2021
Cela fonctionne aussi avec la 0.8.0 compilée vers cette date. Les versions ultérieures ne semble pas compatibles.

L'inconvénient : l'affichage du courant est divisé par deux. Ce qui peut-être modifié par un coeficient dans le programme.
Attention la bibliothèque ESP32 ayant été modifiée, cette modification ne fonctionne pas avec les versions plus récentes.
Il vaut mieux attendre une version stable pour recompiler le programme de LaBox.

Ensuite il faut retoucher le courant à vide (valeur de 0 à 15 mA - 25mA). En l'absence d'un ajustable, il suffit de souder provisoirement un potentiomètre de 1 Mohm entre les broches 3 et 8 du LM358, de régler l'affichage entre 15 et 25 mA en partant de 1 Mohm, de mesurer la valeur obtenue et de remplacer le potentiomètre par une résistance fixe de la valeur approchante pour 15 mA. La valeur typique est de 120 Kohm pour ce gain de 0,5V/A.

Avantage : la détection de court-circuit qui était un peu trop sensible à 700 mA, est portée à 1,4 A. Attention, ce n'est pas testé, le courant limité semble plus important.

Le pilotage des locomotives et accessoires n'est pas affecté.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le août 15, 2021, 04:50:52 pm
Un mystère éclairci ...

Le lancement du télé-déversement dans les ESP32 semble être soumis aux caprices de la météo ?
On trouve sur internet des montages affreux avec des condensateurs chimiques de 10 µF  ...
Manifestement inutile pour certains exemplaires.
En comparant les livraisons, on s’aperçoit que ceux qui ne nécessitent pas d'appuyer sur ENABLE, comportent un petit condensateur rapporté, mesuré à 0,75µF.
En cas de difficulté avec LaBox, il suffit de laisser l'ESP32 sur son support pour le programmer, après avoir remplacé C9 (100nF) par un 1µF :
https://www.ebay.fr/itm/264325249414

EDIT On peut rappeler la documentation d'ESPRESSIF :

Download button. Holding down Boot and then pressing EN initiates Firmware Download mode for downloading firmware through the serial port.

Téléchargement. Maintenir Boot enfoncé puis appuyer sur EN pour lancer le téléchargement du micrologiciel via le port série.


https://docs.espressif.com/projects/esp-idf/en/stable/esp32/hw-reference/esp32/get-started-devkitc.html
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le août 15, 2021, 05:59:55 pm
Bravo pour cette explication lumineuse et la solution simple.

Petit à petit des chapitres s’ajoutent à la documentation de mise en œuvre qui remonte à la page 23 (debut 2021).

Le circuit imprimé a évolué à cause de composants obsolètes et des composants changent de valeur.
Il nous reste encore un mystère logiciel à lever.
Une mise à jour verra le jour prochainement, soyez patient !

Merci beaucoup. :D ;)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le août 22, 2021, 12:03:14 pm
Quel courant pour LaBox ?

Le L6203 est donné pour 3 ampères (et 48V).

Mais d'autres limitations apparaissent :
La fiche de spécification du L6203 indique :
pour S/D diode RDS ON = 0,3 ohm (typ.) et VDS ON (@3A) = 0.9 V
pour transistors (@3A) VSD = 1,35V
soit 2,25 V je suppose que c'est pour chaque DMOS, donc 4,5V pour le pont

De fait, en test alimenté par un bloc 15V 6A qui présente une chute de tension de 0,5V à 14,8V avec une charge de 3A on évalue la tension DCC à l'oscilloscope à 32 V crête à crête à vide et 23 V cc avec une charge de 4 ohms. Soit respectivement 16 V et 11,5 V efficaces. (photos)
Un redressement donne la valeur des plateaux du signal carré.

L'afficheur indique 1350 mA (version 0.8 de LaBox et facteur de courant 1/2 avec  0,5V/A sur le pcb) soit 2700 mA. La résistance de 4 ohms 100W devient vite bouillante et le radiateur du L6203 devient rapidement chaud, il dissipe ~15W.
La protection de LaBox qui, avec ce montage est théoriquement à 2800 mA ne se déclenche pas.

Le montage peut être alimenté avec 18V, je n'ai pas fait de tests avec cette tension, car j'utilise entre autres des décodeurs LAISDCC qui recommande de ne pas dépasser 15V.
Mais les chutes de tension étant liées au courant, celles-ci seront identiques.
Ce test corrobore donc les spécifications aux incertitudes de mesure près.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le août 22, 2021, 12:34:38 pm

Une mise à jour verra le jour prochainement, soyez patient !


Et pour les impatients, la version de Labox 0.8 semble être la dernière qui détecte l'adresse de la locomotive posée sur les rails en lançant le choix adhoc. La mise sous tension de la voie par Smartphone, JMRI ou manette est nécessaire auparavant.
Cette version recompilée actuellement avec les bibliothèques mises à jour ne détecte plus l'adresse.
La solution est d'utiliser ESPTOOL pour télécharger le fichier flash_080.bin ci-dessous et d'utiliser un facteur de courant de 0,5V/A sur le pcb.
https://www.dropbox.com/s/dfbx4vyzjyi59qq/flash_080.bin?dl=0

Cette version de Labox 0.8 fonctionne à peu près avec JMRI (problème de lecture des CV sauf le CV1)

La procédure pour installer ESPTOOL a été décrite sur le site éditorial :
https://www.locoduino.org/spip.php?article279#forum5612
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le août 29, 2021, 11:14:16 am
Bonjour à tous

Après trois semaines de vacances à la maison, beaucoup de bricolage, et aussi un peu de programmation pour voir de quoi est fait l'ESP32, j'ai enfin quelques éléments de réponse sur notre problème de timing découvert voilà maintenant plusieurs mois...

Premier objectif pour moi, tester les timings interruptions simples sur ESP32. Rien ne permet de penser que ces interruptions ne fonctionnent pas bien, mais quand on cherche à résoudre un problème, on commence par la base... J'ai donc pondu un fichier ino (joint ici) avec un programme de test de timing. Il fonctionne -a priori- aussi bien en ESP32 que sur un Nano. Son but est d'abord de compter le temps entre deux appels à la fonction d'interruption et de rendre un rapport après un certain nombre de mesures. Je l'ai fixé à peu près au maximum d'un entier non signé, c'est à dire 60000 mesures. Ce devrait statistiquement être suffisant. Chaque interruption va mesurer le temps passé depuis le précédent appel, et selon le résultat, incrémenter un compteur. Comme le temps est idéalement fixé à 58us, j'ai donc utilisé une matrice de compteurs qui vont stocker le nombre trouvé de timings à +-10us autour du temps référence. C'est donc une matrice de 48 à 68, mais comme elle commence à 48, c'est en réalité une matrice de 20 longs non signés. L'élément 0 donne le compteur des 48us, l'élément 1 de 49us, etc... Deux autres compteurs sont ajoutés : l'élément 20 qui compte le nombre de timings en dessous de 48us, et l'élément 21 qui compte le nombre au dessus de 68us. Trois autres temps sont mesurés : le timing le plus court de toute la série, le plus long, et le temps passé à l'intérieur de la fonction d'interruption. Un pourcentage permet de rendre compte de la proportion de timings à la valeur idéale de 58us, et aussi la proportion de timings conformes à la norme NMRA, c'est à dire entre 55 et 61us inclus. Le timing moyen est aussi calculé.
Pour mieux comprendre l'influence de ce qui tourne autour de l'interruption, j'ai ajouté des define à l'entrée du programme pour jouer avec différents paramètres:

Voici le rapport sans rien activer du tout, juste la mesure des temps :

isr : 2
min : 54
max : 62
ave : 57.50
< 48: 0
= 48: 0
= 49: 0
= 50: 0
= 51: 0
= 52: 0
= 53: 0
= 54: 120
= 55: 0
= 56: 120
= 57: 0
= 58: 59520 (99.20%)
= 59: 0
= 60: 120
= 61: 0
= 62: 120
= 63: 0
= 64: 0
= 65: 0
= 66: 0
= 67: 0
> 68: 0

NMRA compliant: 59760 (99.60%)

Le temps passé dans la routine d'interruption est de 2us, ce qui est très raisonnable avec un temps moyen de 57.5us très correct.
L'ensemble des temps mesurés se situe entre 54 et 62us, on est donc à près de 100% de réussite sur une norme NMRA.
Le timer de l'ESP32 fonctionne sur une démultiplication des ticks donnés par la fréquence du processeur. Ca explique les timings réguliers toutes les deux us : 54, 56, 58, 60, 62, 64... Certaines fois le timer doit arriver un chouilla trop tôt ou trop tard...

Voyons ce que ça donne avec LOOP_COMPUTE, INT_COMPUTE et SETPIN activés :
isr : 23
min : 53
max : 63
ave : 57.50
< 48: 0
= 48: 0
= 49: 0
= 50: 0
= 51: 0
= 52: 0
= 53: 120
= 54: 0
= 55: 120
= 56: 0
= 57: 240
= 58: 59043 (98.40%)
= 59: 241
= 60: 0
= 61: 120
= 62: 0
= 63: 120
= 64: 0
= 65: 0
= 66: 0
= 67: 0
> 68: 0

NMRA compliant: 59764 (99.60%)

Le temps passé dans la routine d'interruption s'est bien alourdi, mais le bilan global reste correct. On a un peu de timings perturbés à 57 ou 59us, et les temps mini/maxi se sont un peu aggravés, mais restent corrects.

Voyons ce qui se passe si l'on active uniquement la mesure de courant LOOP_ANALOG_READ:

isr : 3
min : 25
max : 90
ave : 57.50
< 48: 2352
= 48: 0
= 49: 0
= 50: 0
= 51: 0
= 52: 0
= 53: 0
= 54: 198
= 55: 960
= 56: 1849
= 57: 6489
= 58: 6554 (10.92%)
= 59: 20937
= 60: 17559
= 61: 1059
= 62: 174
= 63: 91
= 64: 99
= 65: 857
= 66: 272
= 67: 214
> 68: 344

NMRA compliant: 55407 (92.33%)

Et là c'est le drame... Les temps mini/maxi ont explosé, seulement 10% des timings sont respectés. Et même si d'un point de vue NMRA 92% des timings sont respectés, ont voit bien que dans un signal DCC de grandes disparités peuvent intervenir entre les fronts montants et les fronts descendants du signal... Le fait de passer la routine d'interruption sur le second coeur améliore un peu le traitement, mais pas au point de redevenir acceptable.

Le constat est sans appel, l'analogRead ESP32 est très lent. J'ai lu quelque part qu'il lui fallait 100us pour faire sa tâche, et que pendant une partie de ce temps les interruptions sont bloquées... C'est un problème que le nano n'a pas.
Voilà pour la partie théorique de l'analyse. Reste à trouver une solution et à l'appliquer à DCCpp et donc à Labox.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le août 29, 2021, 11:33:16 am
Super : une vraie démarche scientifique  ;D

Quelle influence a freeRtos sur les timings ? Je vois chez d’autres le comptage de ticks système, tantôt faits dans ESP-IDF, tantôt pas.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le août 29, 2021, 11:51:52 am
Deuxième partie de mon analyse : DCCpp.

Pour éviter toute influence de ce que nous avons ajouté dans Labox avec les throttles et les diverses modifications, j'ai décidé de repartir de DCCpp. Lui ne s'occupe que du signal proprement dit. Le fichier ino utilisé (joint ici, avec aussi mon DCCpp du moment) est une variante de l'exemple autotest. En effet, il me fallait trouver un protocole de test suffisamment fiable et répétitif. Si en plus je pouvais me passer d'un circuit et de matériel roulant... Bref, une séquence programmée répétitive, avec un nombre d'actions bien déterminé devait faire l'affaire. Après réflexion, je me suis dit qu'en fait je n'avais pas besoin d'actions ! La simple génération de paquets 'Idle' devaient suffire à tester les timings. Ils contiennent suffisamment de bit à 0 et 1 pour tester. Il suffit d'allumer le DCC, d'attendre un peu, de clore le DCC puis d'afficher un rapport. C'est ce que fait le .ino avec une attente de 10s.
Avant de passer par la première étape citée plus tôt avec mon ESP32_timer.ino indépendant, j'avais tenté de remplacer l'interruption classique de DCCpp par une variante introduite dans la version officielle depuis peu, la version avec une seule interruption (USE_ONLY1_INTERRUPT). Contrairement à la routine classique qui décide à chaque changement de bit de la durée du prochain timing (58us ou 96us), la nouvelle dispose d'un timing constant à 58us, et compte les appels : 2 pour un un (un front montant, un front descendant) ou 4 pour un zéro (deux pour le front montant, deux autres pour le front descendant). Le gros avantage c'est que ça m'a permis de reporter mon calcul de timings quasiment tel quel depuis mon programme indépendant.
C'est en essayant de reproduire les timings de ESP32_Timer que je me suis aperçu de l'influence d'analogRead. En effet, si on ne demande pas de surveiller le courant (passer UNDEFINED_PIN comme dernier argument de DCCpp::beginMain() ) les timings bruts sont bien meilleurs. Je n'ai pas fait le test pour savoir si du coup le sniffer y trouvait son compte. A tester.

Evidemment, tout ça ne sert à rien si on a pas une solution à offrir. Pas question de se passer de la mesure de courant, que ce soit pour gérer les court circuits ou pour la programmation. Sur le net, j'ai fini par trouver une fonction de remplacement d'analogRead qui va plus vite.

#include <soc/sens_reg.h>
#include <soc/sens_struct.h>

int local_adc1_read(int channel)
{
uint16_t adc_value;

SENS.sar_read_ctrl.sar1_dig_force = 0; // switch SARADC into RTC channel
SENS.sar_meas_wait2.force_xpd_sar = SENS_FORCE_XPD_SAR_PU; // adc_power_on
SENS.sar_meas_wait2.force_xpd_amp = SENS_FORCE_XPD_AMP_PD; // channel is set in the convert function

// disable FSM, it's only used by the LNA.
SENS.sar_meas_ctrl.amp_rst_fb_fsm = 0;
SENS.sar_meas_ctrl.amp_short_ref_fsm = 0;
SENS.sar_meas_ctrl.amp_short_ref_gnd_fsm = 0;
SENS.sar_meas_wait1.sar_amp_wait1 = 1;
SENS.sar_meas_wait1.sar_amp_wait2 = 1;
SENS.sar_meas_wait2.sar_amp_wait3 = 1;

//set controller
SENS.sar_read_ctrl.sar1_dig_force = false;      //RTC controller controls the ADC, not digital controller
SENS.sar_meas_start1.meas1_start_force = true;  //RTC controller controls the ADC,not ulp coprocessor
SENS.sar_meas_start1.sar1_en_pad_force = true;  //RTC controller controls the data port, not ulp coprocessor
SENS.sar_touch_ctrl1.xpd_hall_force = true;     // RTC controller controls the hall sensor power,not ulp coprocessor
SENS.sar_touch_ctrl1.hall_phase_force = true;   // RTC controller controls the hall sensor phase,not ulp coprocessor

//start conversion
SENS.sar_meas_start1.sar1_en_pad = (1 << channel); //only one channel is selected.
while (SENS.sar_slave_addr1.meas_status != 0);
SENS.sar_meas_start1.meas1_start_sar = 0;
SENS.sar_meas_start1.meas1_start_sar = 1;
while (SENS.sar_meas_start1.meas1_done_sar == 0);
adc_value = SENS.sar_meas_start1.meas1_data_sar; // set adc value!

SENS.sar_meas_wait2.force_xpd_sar = SENS_FORCE_XPD_SAR_PD; // adc power off return adc_value;

return adc_value;
}

Je vous rassure, je n'y comprend rien non plus. Ca fait appel à des fonctions de base de l'ESP32 dont se sert aussi le classique analogRead. Effectivement, ça va plus vite, mais dans mon b...l provisoire, je ne l'ai pas testé en situation réelle. Je ne sais pas où sont mes potars ! Il faudrait au moins tester que ça marche sur un programme de lecture de potar de base en comparant la valeur qu'elle retourne à celle que retourne le vrai analogRead. Si la fonction marche, on pourra alors envisager de remplacer tous nos appels à analogRead par cette fonction. Elle réclame un channel et pas un numéro de pin, alors il faut utiliser
int channel = digitalPinToAnalogChannel(pin);
pour faire la conversion.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le août 29, 2021, 06:53:18 pm
Bonjour Thierry
pour la génération des bits dcc, j'utilise le pwm : cela fait des timings on ne peut + précis, et il n'y a qu'1 seule interruption par bit dcc, voire moins ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le août 29, 2021, 09:19:12 pm
Bonsoir Thierry,

à priori le adcl suit bien la valeur de l'analogread (potentiomètre à 3V3 sur le GPIO 36, décalé par pas) :
analogRead = 1699
adc1_read = 1699
analogRead = 1702
adc1_read = 1700
analogRead = 1703
adc1_read = 1699
analogRead = 1702
adc1_read = 1701
analogRead = 1711
adc1_read = 1702
analogRead = 1702
adc1_read = 1696
analogRead = 1703
adc1_read = 1699
analogRead = 1703
adc1_read = 1687
analogRead = 1706
adc1_read = 1688
analogRead = 1706
adc1_read = 1699
analogRead = 1695
adc1_read = 1833
analogRead = 2631
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 3509
adc1_read = 2702
analogRead = 2734
adc1_read = 2731
analogRead = 2745
adc1_read = 2739
analogRead = 2736
adc1_read = 2644
analogRead = 2734
adc1_read = 2741
analogRead = 2715
adc1_read = 2736
analogRead = 2735
adc1_read = 2731
analogRead = 2736
adc1_read = 2733
analogRead = 2740
adc1_read = 2737
analogRead = 2733
adc1_read = 2731
analogRead = 2431
adc1_read = 1472
analogRead = 1472
adc1_read = 1477
analogRead = 1480
adc1_read = 1598
analogRead = 1583
adc1_read = 1565
analogRead = 1579
adc1_read = 1591
analogRead = 1581
adc1_read = 1577
analogRead = 1585
adc1_read = 1575
analogRead = 1584
adc1_read = 1582
analogRead = 1575
adc1_read = 1267
analogRead = 688
adc1_read = 644
analogRead = 645
adc1_read = 645
analogRead = 589
adc1_read = 639
analogRead = 647
adc1_read = 642
analogRead = 625
adc1_read = 640
analogRead = 654
adc1_read = 645
analogRead = 646
adc1_read = 640
analogRead = 479
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 73
analogRead = 87
adc1_read = 80
analogRead = 79
adc1_read = 81
analogRead = 78
adc1_read = 85
analogRead = 80
adc1_read = 80
analogRead = 80
adc1_read = 99
analogRead = 80
adc1_read = 80
analogRead = 81
adc1_read = 80
analogRead = 82
adc1_read = 82
analogRead = 80
adc1_read = 85
analogRead = 80
adc1_read = 80
analogRead = 80
adc1_read = 84
analogRead = 75
adc1_read = 80
analogRead = 80
adc1_read = 80



#include <soc/sens_reg.h>
#include <soc/sens_struct.h>

int canal = digitalPinToAnalogChannel(36);

void setup() {
  Serial.begin(115200);
  Serial.println("LaBox ");
}

void loop() {
  // put your main code here, to run repeatedly:
   Serial.print("adc1_read = ");
   Serial.println(local_adc1_read (canal));
 delay(500);
   Serial.print("analogRead = ");
   Serial.println(analogRead(36));             // debug value
    delay(500);
}

#include <soc/sens_reg.h>
#include <soc/sens_struct.h>

int local_adc1_read(int channel)
{
  uint16_t adc_value;

  SENS.sar_read_ctrl.sar1_dig_force = 0; // switch SARADC into RTC channel
  SENS.sar_meas_wait2.force_xpd_sar = SENS_FORCE_XPD_SAR_PU; // adc_power_on
  SENS.sar_meas_wait2.force_xpd_amp = SENS_FORCE_XPD_AMP_PD; // channel is set in the convert function

// disable FSM, it's only used by the LNA.
  SENS.sar_meas_ctrl.amp_rst_fb_fsm = 0;
  SENS.sar_meas_ctrl.amp_short_ref_fsm = 0;
  SENS.sar_meas_ctrl.amp_short_ref_gnd_fsm = 0;
  SENS.sar_meas_wait1.sar_amp_wait1 = 1;
  SENS.sar_meas_wait1.sar_amp_wait2 = 1;
  SENS.sar_meas_wait2.sar_amp_wait3 = 1;

  //set controller
  SENS.sar_read_ctrl.sar1_dig_force = false;      //RTC controller controls the ADC, not digital controller
  SENS.sar_meas_start1.meas1_start_force = true;  //RTC controller controls the ADC,not ulp coprocessor
  SENS.sar_meas_start1.sar1_en_pad_force = true;  //RTC controller controls the data port, not ulp coprocessor
  SENS.sar_touch_ctrl1.xpd_hall_force = true;     // RTC controller controls the hall sensor power,not ulp coprocessor
  SENS.sar_touch_ctrl1.hall_phase_force = true;   // RTC controller controls the hall sensor phase,not ulp coprocessor

  //start conversion
  SENS.sar_meas_start1.sar1_en_pad = (1 << channel); //only one channel is selected.
  while (SENS.sar_slave_addr1.meas_status != 0);
  SENS.sar_meas_start1.meas1_start_sar = 0;
  SENS.sar_meas_start1.meas1_start_sar = 1;
  while (SENS.sar_meas_start1.meas1_done_sar == 0);
  adc_value = SENS.sar_meas_start1.meas1_data_sar; // set adc value!

  SENS.sar_meas_wait2.force_xpd_sar = SENS_FORCE_XPD_SAR_PD; // adc power off return adc_value;

  return adc_value;
}
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le août 30, 2021, 08:22:00 am
Bonjour,

Je suis sans doute pas bien réveillé mais j'ai du mal à comprendre pourquoi imbriquer des analogRead systématiquement dans la génération du signal DCC.
Bien-sur il faut lire la valeur du courant pour la détection de court-circuit qui, elle, doit se faire une fois par loop principale et il faut lire le courant faible de 60 mA lors des lectures de CV, mais ce qui n'est pas fréquent et uniquement dans les phases de programmation de décodeur.

Evidemment la durée d'une loop principale fait moins de 58µS donc ces analogRead (ou équivalents) pour la détection de court-circuit tombent forcément et plusieurs fois dans un créneau 1 ou 0 du générateur DCC. Et cela perturbe les interruptions. N'est-il pas ?

Je suppose donc que notre ami trimarco232 n'inclut pas de lecture analogique du courant dans sa génération ultra-précise du DCC en PWM.

Pour éviter cet inconvénient, on pourrait faire appel à une mesure de courant extérieure à l'ESP32 avec un convertisseur analogique-numérique extérieur.
Mais comme l'ESP32 comporte 2 coeurs, ne serait-il pas possible de faire la génération DCC dans un coeur et la lecture analogique dans l'autre coeur ?


Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le août 30, 2021, 09:22:59 am
Aujourd'hui, la lecture du courant se passe effectivement dans la loop principale DCCpp::loop() . Il y a à la fois la lecture de courant sur la voie principale puis sur la voie de programmation, ce qui signifie 100 analogRead par loop(). C'est sans doute trop fréquent, et on pourrait vraisemblablement ne laisser la mesure que chaque dixième de seconde, voire quart de seconde. Mais ça resterait encore trop fréquent et perturberai encore les timings à ces moments là. La lecture de CV est aussi perturbée, mais bien plus rarement, effectivement.
Il y a l'option dans ESP32_Timer pour faire faire la mesure au second core, mais si les choses s'améliorent un peu, ça reste trop perturbant pour les timings. Je pense qu'analogRead touche des choses bas-niveau de l'ESP qui sont communes à tous les coeurs.
Les tests de Michel montrent que la fonction remplaçante fait bien son boulot. Merci Michel ! Il faut maintenant vérifier que les timings DCC sont bons avec la lecture analogique débranchée (UNDEFINED_PIN sur le troisième argument de beginMain() dans Labox.ino...), et si c'est le cas, alors il faudra implémenter la nouvelle lecture analogique partout et revérifier avec le sniffer.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le août 30, 2021, 09:49:27 am
Depuis que j’utilise DCCpp (et a fortiori DCC++), je place une mesure de courant de court-circuit personnelle dans la LOOP de mon programme, qui ne fait qu’un seul analogRead, sans aucune moyenne car c’est un seuil absolu a ne pas dépasser donc à réaction instantanée.
Quand cela arrive, la détection de cc de DCCpp ne se déclenche jamais car trop lente.

On pourrait donc simplifier DCCpp de cette façon.

Évidemment un lissage est nécessaire pour la lecture des réponses de programmation.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le août 30, 2021, 10:00:57 am
... vérifier que les timings DCC sont bons avec la lecture analogique débranchée (UNDEFINED_PIN sur le troisième argument de beginMain() dans Labox.ino...) ...

c'est la pin 36 qui fait la mesure de courant, donc avec :
  // configuration pour L6203 La Box
  DCCpp::beginMain(UNDEFINED_PIN, 33, 32, UNDEFINED_PIN); sauf erreur, on la neutralise. (LaBox 091 et DCCpp 142)

Pour autant, est-ce qu'il n'y a plus d'analogRead ? car le résultat semble sans changement flagrant.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le août 30, 2021, 10:04:34 am
J'ai certainement raté quelque chose, l'affichage du courant reflète la consommation ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le août 30, 2021, 11:04:57 am
Oui, dans HMI.cpp, l'analyse du courant consommé est à base d'analogRead. Il faudrait mettre les lignes 730 et 751-752 en remarque:

D:\Documents\Arduino\libraries\LaBox\src\hmi\hmi.cpp:
  728  {
  729    _HMIDEBUG_FCT_PRINTLN("hmi::readVoltage().. Begin"); 
  730:   voltage = (float) (analogRead(PIN_VOLTAGE_MES) * HMI_VoltageK);
  731  #ifdef _HMIDEBUG_SIMUL
  732    voltage = ((float)random(175, 185)) / 10;
  ...
  744  {
  745    _HMIDEBUG_FCT_PRINTLN("hmi::readCurrent().. Begin");   
  746:   //current = analogRead(PIN_CURRENT_MES) * HMI_CurrentK ;
  747    // DB : remplacé par une moyenne de 50 mesures
  748    float base = 0;
  749  for (int j = 0; j < 50; j++)
  750  {
  751: float val = (float) analogRead(PIN_CURRENT_MES);
  752  base += val;
  753  }
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le août 30, 2021, 01:41:16 pm
C’est sur que s’il y a des analogRead un peu partout, les perturbations augmentent.

Il vaudrait mieux centraliser cette lecture dans le cœur de DCCpp.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le août 30, 2021, 02:58:54 pm
Cette fois on a bien -100 mA à l'affichage.

Mais les timings n'ont pas gagné grand chose à mon avis.
adcl3.jpg = avec des commandes DCC pour les locos.
adcl2.jpg = des idles
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le août 30, 2021, 04:46:35 pm
C'est aussi pour ça que j'ai préféré repartir de DCCpp et éviter les surcharges de Labox...
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le août 31, 2021, 01:14:07 am
Je suppose donc que notre ami trimarco232 n'inclut pas de lecture analogique du courant dans sa génération ultra-précise du DCC en PWM.
(...)
non, je n'en suis pas là ; toutefois les interruptions n'ont lieu qu'à chaque bit dcc, cad. 116µs minimum, ce qui laisse beaucoup + de temps d'y faire des choses ...
(l'ultra précision n'est pas nécessaire dès qu'on reste dans les tolérences, mais ça ne coûte rien de l'avoir)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le août 31, 2021, 05:24:56 pm
Merci Trimarco232.

Pourrais-tu partager ton code ESP32 pour la generation DCC ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le août 31, 2021, 07:47:40 pm
c'était là : http://forum.locoduino.org/index.php?topic=830.msg9034#msg9034 (http://forum.locoduino.org/index.php?topic=830.msg9034#msg9034)
un peu sec, alors j'ai ajouté ces /// complémentaires
n'hésitez pas pour + d'infos
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le août 31, 2021, 08:19:05 pm
Désolé c’était passé sous les radars et avec l’âge on ne s’améliore pas !

Merci en tout cas  ;D
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le août 31, 2021, 09:37:40 pm
Bonsoir à tous,

quand on passe au sniffer le DCC pwm installé sur LaBox, les timings ne sont pas irréprochables :
Pour les UN on a 60 µs pour la 1ere demi-période, 55 µs pour la seconde soit 115 µs en tout.
Les ZERO n'ont pas de conséquence, évalués à 97-102 µs.

Il faudrait construire quelques paquets pour voir la conformité au NMRA.
Nota : limites pour les UN : 55 - 61, même si les décodeurs sont supposés accepter 52 -64 (+/- 6 µs). Norme S 9.1
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le septembre 01, 2021, 02:45:36 am
pwm installé sur ma station, 2 générateurs actifs simultanément : tout est nickel !
1) ça décode (bon, les pakets du  1er géné sont en chantier)
2) les bits dcc 1 sont à 116,0000 µs
3) le bits dcc 0 dont à 198,0000 µs --> parce que je les ai programmé ainsi

@msport : il faut peut-être que tu fasses vacciner ton sniffer  ;D
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le septembre 01, 2021, 08:37:59 am
Les timings sont bien bons, effectivement. Et l'analyseur logique qui décode le DCC tout en surveillant les trames, c'est juste génial !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 01, 2021, 09:07:18 am
La mesure des timings réalisée sur un Arduino est relative : on ne peut pas la prendre comme référence.

Le traitement des interruptions diffère d'une architecture CPU à une autre, et les interruptions s'opposent les une aux autres, avec un traitement asynchrone dans certains cas.

Pour analyser le signal on doit utiliser une broche IN et réagir aux fronts via une interruption...dans laquelle on va lire l'horloge via "micros()", cette horloge dépendant elle-même d'une interruption (le timer 0, qui gère l'horloge système).

Si l'entrée DCC déclenche alors que le CPU est en train de traiter une autre interruption (typiquement TIMER 0), alors on traitera le déclenchement quelques uSec après sa survenance réelle, et comme on ne peut pas capturer l'horloge précisément au moment ou le signal survient, on introduit du "jitter".

Le seul moyen de valider les timings du signal généré c'est l'oscillo.

A noter que ce que je dis est moins vrai en génération de signal, et c'est une bonne chose.

En effet, pour générer le PWM on produit une interruption au moment du DEMI BIT, donc bien avant la fin de la double demie-impulsion. On charge les registres PWM avec les valeurs du prochain bit qui seront prises en compte lors du reset du compteur, c'est à dire précisément à la FIN du bit, sans décallage. C'est une mécanique purement hardware synchrone....donc tant que le chargement des registres va assez vite, on a pas de jitter sur la génération du signal qui reste nickel (à la variation de l'horloge du CPU près).

C'est une bonne chose car les décodeurs doivent concilier avec à la fois les imprécisions de mesure liées à leur propre architecture ainsi qu'avec les défauts du signal lié à la transmission fluctuante via les rails....donc il vaut mieux avoir un signal très propre à la source pour simplifier la vie des décodeurs.

Pour info, avec un NANO EVERY (Atmega 4809 ou 4808) tournant sur oscillateur interne à 16 Mhz, j'arrive à un décodage de 100% du flux de trames avec les centrales du marché...mais j'ai systématiquement un bit de perdu : le premier bit de préambule qui suit la réception d'une trame ! Le temps supplémentaire nécessaire à mettre la trame reçue en file d'attente pour son traitement introduit un défaut de mesure sur la demie-alternance en cours de transmission, qui fait que la symétrie du bit n'est plus bonne et sort de la tolérance.

C'est sans conséquence puisque d'une part c'est à ça que sert le train de préambule : à gérer la synchro ET à absorber les fluctuations....et que par ailleurs la norme spécifie qu'un décodeur n'a pas à recevoir deux trames à moins de 25 ms d’intervalle (trames qui lui sont destinées)....donc même si je perdais la trame suivante, ce qui n'est pas le cas, je serais dans la norme. Là je perd le premier bit de préambule de la trame suivante mais comme il faut en émettre au moins 14 et que le décodeur doit quant à lui en recevoir au moins 10....j'arrive toujours à récupérer la trame.

Enfin bref : attention à l'analyse de trame réalisée via Arduino. Le contenu, ok. Les timings sont quant à eux intrinsèquement entachés d'une légère erreur de mesure au niveau de l'heure de chaque front, ce même si l'Arduino ne fait rien d'autre que mesurer....
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 01, 2021, 09:49:43 am
@Trimarco : dans ton analyse, tu exclu le bit de fin de paquet du préambule suivant.
La norme spécifie le contraire. Note de bas de page 1 du 9.2 de la spec :

The Packet End Bit may count as one of the preamble bits of the subsequent packet if there are no inter-packet bitsfrom an alternative command control protocol.  The DCC bitstream must continue for an additional 26 μS(minimum) after the packet end bit.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 01, 2021, 10:14:30 am
Le sujet du "sniffer DCC" est très important car nous avons besoin d'un outil pour vérifier ce qui fonctionne bien et pour comprendre ce qui fonctionne mal.

Cela faisait longtemps que je creusais cette question sans vouloir engager de dépenses pour un oscilloscope sérieux, question de budget familial comme tout le monde..

Finalement je me suis arrêté (pour le moment) sur celui de DCC++EX dénommé "DCCInspector-EX" que je mets en PJ ci-dessous.

Il tourne sur un ESP32 et sort les résultats conformes au sniffer de Rudy Boer soit sur le moniteur, soit sur une page Web qu'on peut récupérer sur un navigateur en wifi.
msport a en chantier un circuit imprimé qui nous sert de banc de mesure en ce moment. Evidemment la section wifi-serveur html n'améliore pas la précision de la mesure, mais j'ai fait quelques comparaisons entre Labox et d'autres centrales comme une DCCpp sur Nano/Uno, et ma MS2 Marklin: ces deux dernières montrent des timings irréprochables, ce qui prouve que cet outil peut être utilisé avec confiance.

(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=4172;image)

Comme les mesures de timing sont basées sur l'Input Capture, je pense que c'est la méthode la plus précise et l'ESP32 est bien plus rapide que les AVR.

Dans ce programme j'ai ajouté une commande au moniteur: x/X qui permet d'afficher tous les paquets, plutôt qu'un seul paquet par catégorie.

Votre avis nous intéresse car, avec msport, on pourrait finaliser un circuit imprimé et présenter ce projet dans un article sur le site rédactionnel. Merci d'avance.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le septembre 01, 2021, 10:25:31 am
Bonjour,
pour ceux que ça intéresse, l'analyse logique à 10 balles :
- acheter un clone salae ... + les petites pinces qui vont bien (que j'ai soudées pour qu'elles aillent mieux) + des rallonges dupont de qualité
- télécharger et installer le logiciel salae, c'est juste pour avoir le driver
- télécharger et installer PulseView ; on peut voir les bits à ce stade
- télécharger "sigrok-DCC-Protocoll" ; extraire le dossier "DCC" et l'ajouter dans le repertoire "decoders" ; chez-moi :C:\Program Files\sigrok\PulseView\share\libsigrokdecode\decoders
- dans la config du decoder, dans "01 or 10", choisir "10"

(aucune raison que le sniffer à base d'ESP32 ne fonctionne pas parfaitement)
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 01, 2021, 10:30:42 am
Bonjour,
pour ceux que ça intéresse, l'analyse logique à 10 balles :
- acheter un clone salae ... + les petites pinces qui vont bien (que j'ai soudées pour qu'elles aillent mieux) + des rallonges dupont de qualité
- télécharger et installer le logiciel salae, c'est juste pour avoir le driver
- télécharger et installer PulseView ; on peut voir les bits à ce stade
- télécharger "sigrok-DCC-Protocoll" ; extraire le dossier "DCC" et l'ajouter dans le repertoire "decoders" ; chez-moi :C:\Program Files\sigrok\PulseView\share\libsigrokdecode\decoders
- dans la config du decoder, dans "01 or 10", choisir "10"

(aucune raison que le sniffer à base d'ESP32 ne fonctionne pas parfaitement)

J'aimerai bien mais sur Mac, point de soft possible :-\
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 01, 2021, 10:44:02 am
D'ailleurs l'auteur du sniffer ESP32 a constaté aussi des glitch dans la génération du code DCC sous interruptions:

Example ESP32 Monitoring DCC++ EX 3.0.4 (5V, 6N137 Optocoupler, Main Track, Strict NMRA)

When the DCC signal is generated within interrupt handling code within the Command Station, the accuracy of the signal cannot be maintained to such a high accuracy. Below, we can see that the pulse length varies over a range of around 14us.
This would mean that some packets are outside of the NMRA specification and may be ignored by the loco decoder. The analyser reports 81 packets as out of spec and 351 in-spec, i.e. around 20% are out of spec. This is not normally a problem on a DCC layout as each packet is transmitted at least three times. If one packet doesn't get through, the probability is that one of the retransmissions will!

The half-bit counts are turned off here, but CPU monitoring within the analyser is turned on.

-
Bit Count/4 sec=24865 (Zeros=10167, Ones=14697), Glitches=0
Valid Packets=351, NMRA out of spec=81, Checksum Errors=0, Lost pkts=0, Long pkts=0
0 half-bit length (us): 115.9 (109-122) delta < 14
1 half-bit length (us): 57.5 (51-64) delta < 14
IRC Duration (us): 2.2 (1-10),  CPU load: 27.5%
--
Loc 7552 Fwd128 33      11011101 10000000 00111111 10100010
Loc 3 Fwd128 25         00000011 00111111 10011010
-
Titre: Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le septembre 01, 2021, 10:51:23 am
(... !)
J'aimerai bien mais sur Mac, point de soft possible :-\
c'est pour cette raison, entre autres IDE exotiques, que je me coltine windows :-\ aussi
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le septembre 01, 2021, 10:51:59 am
@Trimarco : dans ton analyse, tu exclu le bit de fin de paquet du préambule suivant..
oui, je n'avais pas non plus encore incorporé, au stade où j'ai remis le projet dans une boîte, le calcul de la cheksum  :-\
terminer le paket dcc par le 1er bit du preamble du paket dcc suivant est une bonne idée, si on utilise le pwm : ainsi, si le soft n'est pas prêt pour donner le paket suivant au timer, celui-ci continue tout seul à générer des bits dcc 1 entiers , ce qui n'est pas péjorant
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le septembre 01, 2021, 11:09:54 am
... pour ceux que ça intéresse, l'analyse logique à 10 balles ...

Super, on va pouvoir faire passer un test PCR au sniffer.

L'interface à base de Mynabay (et ses adaptations), apporte son lot de délais (1K / 1nF mais j'ai fait plus light (1k / 100pF)).
Sur une période complète, ça n'intervient pas.
https://github.com/DCC-EX/DCCInspector-EX#readme


Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 01, 2021, 12:19:04 pm
Dans tout ça il faut largement moduler les "vérités" qui sont lancées ici ou là...

Le traitement des interruptions sur ESP32 donne lieu à une commutation de thread de RTOS et à l'activation d'un contexte....opération relativement lourde d'une part, mais aussi totalement soumise au scheduler de l'OS.
On parle de RTOS donc on est pas trop mal loti, mais il est clair que ça sollicite un mécanisme pas totalement controlé.

Pour générer un flux continu de données contraintes temporellement, on aura plus intéret dans ce cas précis à lancer une tache avec des paramètres de scheduling spécifiques indiquant justement au scheduler que le timing doit etre stricte : c'est à ça que sert RTOS. Une priorité élevée pourra suffire à obtenir un résultat de qualité...possible qu'on arrive au même résultat avec un paramétrage fin de la tache que l'on met en "sticky" pour le gestionnaire d'interruption, mais pas sur...

En revanche, sur un Atmega ou autre ce n'est pas du tout pareil : en dehors du cas ou on a bloqué les interruptions explicitement via "cli", on aura un traitement immédiat d'une interruption déclenchée....sauf si une autre est déjà en cours de traitement.

J'ai traité à l'oscillo lors de mes tests plusieurs systèmes :

Les signaux obtenus sur la Lenz, la DR5000 et la Base Station sont nickels et stables. J'ai d'ailleurs fourni il y a quelques temps une capture à l'oscillo du signal issu de la Base Station.

Les signaux issus de la Multimaus + booster ROCO sont propres dans l'ensemble, mais la centrale insère systématiquement une perturbation (ou un signal à destination d'un autre dispositif, or de la norme DCC). Globalement le décodage "passe au dessus" mais cela fait appel implicitement à un contrôle stricte des bits...car si on "ouvre un peu la tolérance" pour le décodage (par rapport aux spécifications DCC), comme le fait par exemple la lib NMRADCC, on aura un décodage de trames bidons....qui sera ensuite filtré par un mauvais checksum de paquet, mais pas toujours ! (J'ai eu le cas en tests.....)

Je n'ai en revanche pas essayé à ce jour de génération de signal sur ESP32....je n'ai que du décodage à traiter....mais ça peut venir demain, donc si vous voulez un coup de main pour quelques tests, n'hésitez pas.

Bon, tout ça pour dire que le problème ne vient pas du fonctionnement "sous interruption" de façon générale...mais du fait qu'on est sur un système d'exploitation qui "pollue" ce traitement...et que le code sous interruption utilisé sur un ATMEGA marche parfaitement bien, car dans ce cas on a un meilleur contrôle sur le comportement global du CPU.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le septembre 01, 2021, 12:33:55 pm
Dans tout ça il faut largement moduler les "vérités" qui sont lancées ici ou là...
(...)
la centrale insère systématiquement une perturbation (ou un signal à destination d'un autre dispositif, or de la norme DCC)
si c'est le railcom, c'est dans la norme

vous voulez un coup de main pour quelques tests, n'hésitez pas.
(hs) j'ai une centrale à faire avancer, mais pour le coup de main il faudrait + que quelques tests ... (hs\)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 01, 2021, 12:36:27 pm
Non ce n'est pas le cutout...j'ai bien entendu vérifié ;)
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le septembre 01, 2021, 05:45:44 pm
Non ce n'est pas le cutout...j'ai bien entendu vérifié ;)
Des précisions seraient utiles : quelle marque, quel modèle ? quel contexte ?
Mais j'ai constaté qu'une z21 coupait complètement le signal DCC avant une interrogation de CV.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 01, 2021, 08:38:21 pm
J'ai précisé au dessus Michel. Roco 10764 relié à une Multimous (à jour).

C'est un des tous premiers modèles de ROCO, bien avant la Z21.
Il y a de nombreuses centrales qui n'alimentent la voie de programmation que lors de l'envois d'une commande.
C'est le cas aussi de la Lenz que j'ai testé : en dehors d'une commande de programmation, la voie est coupée.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le septembre 01, 2021, 09:13:01 pm
La z21 (blanche) n'a qu'une sortie voie. Je vais regarder si il y a un contexte particulier où elle couperait le DCC (hors Railcom) sans y passer plus de temps que quelques trames ....
Dans la norme, un décodeur doit accepter un ZERO bit qui dure 10000 microseconds pour chaque demi-période alors qu'une station doit émettre des bits ZERO de moins de 12000 microseconds (période).
Reste à savoir ce que Lenz pourrait bien faire des bits ZERO longs.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le septembre 01, 2021, 09:23:06 pm
bits 0 stretchés :
1) mamaille horrible pour piloter 1 loco analogique (adresse 0) ... (et la détruire)
2) donner du temps au mcu quand il en a besoin
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le septembre 03, 2021, 11:10:19 am
Bonjour,

le passage du DCC d'une z21 au sniffer semble valider celui-ci : 100% des packets sont valides.
la totalité des bits UN sont vus à 57 et 58 µs et sauf exception les bits ZERO sont vus à 115 -116 µs
càd que 5% des bits ZERO sont longs : jusqu'à 522 µs
Pendant les 4s d'observation, en conséquence, la z21 délivre 22990 bits et LaBox 28453 bits.
Et la largeur des 1/2 bits UN de LaBox est très dispersée autour des 58µs (même en l'absence des analogRead) (cf message plus haut).
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 03, 2021, 05:32:33 pm
@msport : regardes mieux les chiffres de la Z21 : il y a une anomalie.

Tu as (à 1 près) le meme nombre de demi-bits à 115 et à 116, ce qui correspond aux ZERO transmis en valeur nominale (environ 220 uSec)

Par contre, tu as un déséquilibre dans les demi-périodes liées aux UN.
Les demi-bits des UN sont les 57 et 58, la norme autorisant un écart par demi-alternance de 3 uSec je crois.
Or tu as :
5384 + 7874 en premiere alternance pour la durée 57
5384 + 7411 en seconde alternance pour la durée 58

Il y a 463 demi-alternances manquantes, qui correspondent à des bits 1 à compléter.

Tu retrouves ces 463 demi alternances en bas....ce qui veut dire que le décodeur a reçu une demi-alternance longue (>141) à un moment ou il attendait la seconde demi-alternance d'un 1...

Ton outil annonce le décodage correcte de 22990 bits dont 13026 bits à UN.
7411+5384 = 12795
7874+5384 = 13258

Ca ne colle pas....

Le décodage des paquets reste propre car, du fait de la présence de ces 463 demi-alternances étranges, le décodeur perd la synchro et doit se recaler ensuite...il saute des bits....une fois resynchronisé, il retrouve ses petits et les paquets décodés sont bons....mais régulièrement la centrale ROCO injecte un demi-bit foireux.

Le meme comportement que j'ai eu avec celle que j'ai testé (qui est bien plus vieille que la Z21).
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 03, 2021, 05:36:19 pm
Note aussi que tu as reçu 464 paquets pour 463 de ces demi-bits allongés.....étonnant ? ou pas !

Après la question est de savoir si tu cherches à valider le signal de la Z21 ou le traitement du sniffer. Si c'est bien le sniffer que tu cherches à valider (pas certain d'avoir tout suivi avant de mettre mon grain de sel dans cette histoire), je dirais que ces mesures sont conformes à ce que j'ai pu constater à l'oscillo de mon coté.

Note que si le demi-bit problématique est bien généré là ou je le crois dans le flux, il intervient durant la première partie du préambule. Si celui-ci est assez long, le décodeur retrouve tout de suite sa synchro et ne rate pas le paquet suivant.

Tu as reçu 115 paquets / sec dont une bonne partie en paquets extendeds (4 octets avec le checksum), ce qui correspond à la charge utile du DCC à priori....donc je ne pense pas que le sniffer ai "sauté" des paquets.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le septembre 03, 2021, 07:37:53 pm
Effectivement le but était de valider le sniffer pour ne pas incriminer LaBox d'anomalies qui dont il serait responsable du fait de l'optocoupleur et du fameux condensateur sur l’entrée.
La z21 n'étant pas mon sujet mais une référence.
Pour LaBox on avait déjà validé l'étage de sortie à base de L6203 et de transistor inverseur sur une BaseStation à Nano.
Mais pour aller plus loin, j'ai repris le signal DCC directement sur la pin 33 de l'ESP32 pour l'envoyer directement sur la pin 5 de l'ESP32 du sniffer. Avec la version 0.80 de LaBox, on constate la même dispersion des 1/2 bits des UN avec une moyenne de 58,9 µs (référence à 58 µs).
Ce qu'on voyait (difficilement mais nettement) à l’œil nu à l'oscilloscope.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 03, 2021, 07:43:00 pm
La dispersion existe mais tu as quand meme un sacré pic de valeurs à 58 et 59....Effectivement ça traduit probablement les fluctuations de réaction du code au regard du scheduler du système d'exploitation.

Il est vraissemblable que la seule solution propre pour éviter ça serait d'avoir un co-processeur esclave qui se charge uniquement de la génération du flux, sans possibilité d'influence de ce que fait l'ESP32.

Il faut aussi se poser deux questions liées à l'architecture de l'ESP :
1/ Stabilité de l'horloge et
2/ Mise en oeuvre des fonctions d'économie d'énergie (qui intrinsèquement ralentissent les CPU)....
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 03, 2021, 07:59:11 pm
Est-ce que des tests différents ont été faits en augmentant la priorité du gestionnaire d'interruption qui traite le timer ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le septembre 03, 2021, 09:04:49 pm
L'objectif est d'avoir un minimum de packets Out of spec NMRA avec la tolérance "decoder" de la norme (+/- 6µs) : 0 pour la z21.
Et on teste tout ce que Thierry nous soumet.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 08, 2021, 08:18:17 pm
Pour info, j'ai analysé le flux généré par une LENZ durant pratiquement une heure :

19.4 millions de bits générés
Aucun bit en erreur (timings 100% dans la norme)

Durée des demi-bits 1 : 55 et 56 ms, généralement 55 sur le premier et 56 sur le second.
Pas d'autre valeur mesurée.

Durée des demi-bits 0 : 103 et 104 ms. généralement 104 et 104, parfois 103 sur le premier demi-bit.

La mesure de temps utilise un Atmega 4808 configuré en INPUT CAPTURE sur deux canaux, un pour les alternances MONTANT / DESCENDANT, l'autre pour les alternances DESCENDANT / MONTANT. (Ce CPU ne sait pas capturer les deux sur un seul timer.

La mesure de temps est faite par des timers 16 bits cadencés à l'horloge système, soit 16 Mhz.
Les 3 "rejected pairs" rapportées par le résumé ci-dessous correspond à la recherche de synchro lors du démarrage du test....Il a fallu 3 demi-bits pour que le décodeur se synchronise correctement.

Current mode      :2
Running time      :2910592840
Valid bits        :19398649
Glitch            :0
Rejected pair     :3
Invalid packets   :0
Valid packets     :408783
Dropped packets   :0
Idle packets      :37162
Filtered packets  :334457
Processed packets :37162
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le septembre 08, 2021, 10:03:20 pm
(...)généralement 55 sur le premier et 56 sur le second.
ce qui pourait très bien s'expliquer par un dead time de commande des mosfets qui serait de 1/2µs
typiquement ce dead time ne peut être vu par un analyseur logique ou un dispositif de capture : donc il est lu systématiquement à high (ou low ..), ce qui fait qu'il va s'ajouter à une alternance de bit DCC, et se retrancher à l'autre
pour l'observer, il faudrait relier la sortie de puissance DCC à un diviseur de trension par 2, relié au + et au - de l'étage de puissance, et le voir à l'oscillo comme un pallier d'1/2 µs au millieu d'un flanc montant ou desçandant au milieu ou entre chaque bit DCC
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 09, 2021, 09:09:50 am
Ca ou autre chose....temps de commutation de la diode de redressement, caractéristiques propres au port INPUT de l'Atmega...

Dans les chiffres ci-dessus, j'introduit une légère correction : j'avais tronqué ma mesure de temps d'impulsion (calculée à 16 Mhz, donc 16 unités par uSec) au lieu de faire un ROUND plus approprié...
En faisant ce ROUND j'obtiens un léger décallage moyen d'une uSec vers le haut des valeurs :

56:56 pour les bits 1 qui, du coup, paraissent symétriques à la mesure.
104:105 pour les bits 0 qui eux le sont du coup un peu moins (j'avais 102:104) en tronquant.

Ca ne change pas le résultat final car dans tous les cas j'étais dans la norme, largement....mais en situation limite c'est mieux d'avoir un round qu'un trunc sur la mesure....en fait idéalement je devrais ne pas la toucher et comparer aux seuils DCC x 16....mais là c'est un choix d'implémentation logicielle sur l'étage suivant...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 09, 2021, 09:11:34 am
Exemple de séquence, d'un préambule à un autre.

Timestamp(uSec)|bit|first pair|second pair

410281220:1:56:56
410281336:1:56:56
410281452:1:56:56
410281560:1:56:56
410281672:1:56:56
410281788:1:56:56
410281896:1:56:56
410282008:1:56:56
410282120:1:56:56
410282240:1:56:56
410282344:1:56:56
410282456:1:56:56
410282568:1:56:56
410282684:1:56:56
410282796:1:56:56
410282912:1:56:56
410283024:1:56:56
410283132:1:56:56
410283340:0:104:105
410283548:0:104:105
410283756:0:104:105
410283968:0:104:105
410284176:0:104:105
410284384:0:104:105
410284592:0:104:105
410284704:1:56:56
410284816:1:56:56
410285028:0:104:105
410285136:1:56:56
410285348:0:104:105
410285556:0:104:105
410285668:1:56:56
410285876:0:104:105
410286084:0:104:105
410286196:1:56:56
410286308:1:56:56
410286520:0:104:105
410286632:1:56:56
410286840:0:104:105
410287048:0:104:105
410287168:1:56:56
410287368:0:104:105
410287580:0:104:105
410287796:0:104:105
410287996:0:104:105
410288108:1:56:56
410288220:1:56:56
410288332:1:56:56
410288444:1:56:56
410288556:1:56:56
410288668:1:56:56
410288780:1:56:56
410288896:1:56:56
410289008:1:56:56
410289120:1:56:56
410289232:1:56:56
410289344:1:56:56
410289456:1:56:56
410289568:1:56:56
410289680:1:56:56
410289796:1:56:56
410289904:1:56:56
410290020:1:56:56
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 09, 2021, 09:41:18 am
Meme dispositif de capture connecté à la sortie d'une DR5000

15188460:1:56:61
15188560:1:56:61
15188680:1:56:61
15188796:1:56:61
15188912:1:56:61
15189032:1:56:61
15189148:1:56:61
15189268:1:56:61
15189384:1:56:61
15189500:1:56:61
15189616:1:56:61
15189736:1:56:61
15189852:1:56:61
15189972:1:56:61
15190088:1:56:61
15190212:1:56:61
15190416:0:104:108
15190628:0:104:108
15190840:0:104:108
15191056:0:104:108
15191264:0:104:108
15191384:1:56:61
15191596:0:104:108
15191808:0:104:108
15191924:1:56:61
15192136:0:104:108
15192348:0:104:108
15192564:0:104:108
15192676:1:56:61
15192796:1:56:61
15192912:1:56:61
15193032:1:56:61
15193148:1:56:61
15193264:1:56:61
15193476:0:104:108
15193592:1:56:61
15193804:0:103:108
15193924:1:56:61
15194040:1:56:61
15194156:1:56:61
15194276:1:56:61
15194488:0:104:108
15194604:1:56:61
15194816:0:104:108
15194932:1:56:61
15195152:0:104:108
15195356:0:104:108
15195572:0:103:108
15195688:1:56:61
15195900:0:104:108
15196016:1:56:61
15196132:1:56:61
15196252:1:56:61
15196780:R:30:496
15196840:R:496:56
15196896:1:56:61
15197012:1:56:61
15197128:1:56:61
15197248:1:56:61
15197364:1:56:61
15197480:1:56:61
15197600:1:56:61
15197716:1:56:61
15197844:1:56:61
15197952:1:56:61
15198068:1:56:61
15198184:1:56:61
15198304:1:56:61
15198420:1:56:61
15198536:1:56:61
15198656:1:56:61

On a une "anomalie" (496) insérée entre le bit stop du premier paquet et le préambule du paquet suivant.
Ca ne perturbe pas le décodage néanmoins. Il s'agit du cutout railcom à priori.

Le signal reste dans les tolérances mais l'asymétrie des alternances est marquée.
A peu près 4uSec à chaque fois. La seconde demie alternance est plus proche du nominal de la norme que sur la mesure faite avec la LENZ.
Les timings sont néanmoins toujours constants.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 09, 2021, 10:06:09 am
La question reste posée: comment obtenir cette précision avec l’ESP32, sachant que les moyens de mesures fiables et précis existent maintenant ?
Avec un grand merci à vous deux.

Idéalement la génération des bits devrait se faire à l’extérieur de l’ESP32, avec une sorte de registre à décalage “serie-serie” chargé en I2C, I2S ou PCI, avec un doublement des bits 0 pour conserver une période de 55 uSec partout et un pattern d’IDLE quand le truc n’est pas chargé ou vide. Il faudrait aussi un marqueur de fin de commande car elles ont dès longueurs variable.

Une sorte de FPGA sur mesure ou alors la même fonction a l’intérieur de l’ESP32 mais à l’abri du RTOS.

Qu’en pensez-vous ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 09, 2021, 10:15:32 am
Si effectivement on arrive pas à générer un signal stable directement avec l'ESP, oui il faut confier ça à un composant externe. Plutot qu'un FPGA j'aurais tendance à garder un petit CPU 8 bits facilement sourçable et que tout le monde sait programmer....

Maintenant j'ai pas vu de réponse la question relative à des tests sur ESP en modulant la priorité des task de génération....@Thierry tu peux m'en dire plus sur le code (je n'ai pas regardé, sincèrement...)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 09, 2021, 10:54:17 am
J'ai trouvé quelques remarques relatives à la gestion précise de délais sous FreeRTOS....en particulier pour un utilisateur qui cherche à réaliser des délais de quelques microsecondes dans une tache :

Citer
A Semaphore that is given in an ISR and waited for in the delay function is one good way to implement shorter than a tick delays/periods. If the operation to be done is simple/quick enough, it could even be done in the ISR.

This works well for delays on the order of a 100us or longer (depending on the speed of your processor). Note that the actual delay in the function will be a bit longer than the timer setting as you have the ISR processing delay, and the subsequent task switch (and possible additional delays if a higher priority task becomes ready)

This doesn’t work well for short (like 5us) delays  where you really need a precise value. That isn’t the time frame that an RTOS is aimed at. For that you either need “hardware” to do it, or you disable interrupts and do precisely timed stand alone code.

S'agissant d'une méthode courante (un wait fait sur un signal) pour séquencer du code, vous noterez la remarque précisant que le scheduler assurera une précision suffisante pour des timings de l'ordre de 100 uSec, mais que la précision sera très relative en deça.....Avec comme conséquence de de voir bypasser les fonctions usuelles de l'OS pour mettre les mains dans le cambouie...
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 09, 2021, 02:39:14 pm
Si effectivement on arrive pas à générer un signal stable directement avec l'ESP, oui il faut confier ça à un composant externe. Plutot qu'un FPGA j'aurais tendance à garder un petit CPU 8 bits facilement sourçable et que tout le monde sait programmer....

Un petit ATtiny pourrait être retenu (ou un modèle compact plus approvisionnable a moyen/long terme).
Le fait  que le principe des registres dans DCC++ et DCCpp permet de construire et mettre en file d’attente les commandes DCC. Le transfer dans le microcontroleur annexe sans contrainte de temps réel (celui-ci émet des IDLE quand son tampon est vide) soulagerait l’ESP32. Évidemment une nouvelle version du PCB serait à faire.

Dans une version antérieure du projet que j’avais tenté avec un ESP8266, j’utilisais un Nano avec un DCCpp minimal alimenté par des commandes DCC++ via I2C. Là ce serait encore plus simple, je pense. 
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 09, 2021, 03:38:20 pm
Oui ça revient à faire un sous-système autonome qui gère le bus, donc une version simplifiée de ce que fait DCC++.
SPI, UART, I2C, le moyen de communiquer est assez large de choix. En prototypage, une version UART me semble facile d'accès puisqu'il n'y a pratiquement rien à coder de particulier et que quelques cables dupont suffisent à valider.

Par contre effectivement ça impose une nouvelle carte.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 09, 2021, 05:41:41 pm
J'ai continué à explorer en détail la spec de l'ESP32 et je suis tombé sur un périphérique que je n'avais jusque là pas regardé : le transmetteur RMT (normalement prévu pour envoyer/recevoir des codes de télécommande, d'ou son nom).

Ce périphérique est prévu pour générer une suite de pulsations sur une broche de sortie, à partir d'une liste qu'on lui fourni dans un buffer.

Chaque élément de la liste indique la durée de la pulsation ainsi que l'état haut ou bas du signal durant cette pulsation. A priori très exactement ce que l'on cherche à faire pour émettre une trame complète.

Vous avez expérimenté ce générateur ? Sachant qu'il peut fonctionner aussi en récepteur (décodeur), pour lire un signal. Je vais le mettre en oeuvre pour la réception du DCC à priori....des retours à ce sujet ?

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/rmt.html
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le septembre 09, 2021, 05:55:41 pm
Bonjour

La partie RMT de l'ESP32 est maintenant utilisée par l'Esp32CommandStation d'Atany https://github.com/atanisoft/ESP32CommandStation (https://github.com/atanisoft/ESP32CommandStation) pour la génération des trames DCC. Ca semble bien correspondre au besoin, mais je ne me suis pas penché dessus. C'est un peu le même principe que le PWM qui lui aussi utilise des alternances bien calibrées... On peut imaginer que l'adoption de cette fonctionnalité de l'ESP32 est intervenue pour corriger les mêmes problèmes de timing que nous.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 09, 2021, 06:22:00 pm
De ce que j'en lis dans la doc, c'est assez trivial à utiliser.
Tu configures le diviseur d'horloge à 80 pour avoir une unité de pulsation de 1 uSec.

Tu fournis une liste de demi-pulsations exprimées en uSec...la taille de la liste en émission n'est pas limitée, donc tu peux fournir la séquence de bits complète d'un paquet.

Tu démarres l'émission et ta trame est générée dans son coin.
Tu boucles sur le "wait done" pour passer à la suite, ou tu fournis une callback qui sera appelée sur fin d'envois.

Lorsque tu n'as rien à envoyer tu peux demander au RMT de boucler sur une liste. Il suffit de charger une liste contenant un "1" et tu as ta modulation de repos....

Et si aucun paquet à envoyer durant 30ms....et bien il faut insérer l'inévitable IDLE de la norme.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 09, 2021, 06:25:07 pm
UN rapide coup d'oeil sur les exemples montre l'utilisation de l'ESP-IDF.

Comment intégrer un driver RMT dans le code Arduino ?

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 09, 2021, 06:27:30 pm
Tu as toujours accès aux fonctions de l'API meme avec le framework Arduino : le framework est une surcouche aux API, donc il suffit de faire les bons #include pour bypasser Arduino.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 09, 2021, 06:36:26 pm
effectivement le fichier RMTTrackDevice.cpp fait tout le boulot !
https://github.com/atanisoft/ESP32CommandStation/blob/master/components/DCCSignalGenerator/RMTTrackDevice.cpp (https://github.com/atanisoft/ESP32CommandStation/blob/master/components/DCCSignalGenerator/RMTTrackDevice.cpp)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 09, 2021, 06:54:13 pm
Effectivement.
Un poil compliqué vu qu'il implémente un virtual file system pour ça....mais en tout cas le code y est.

A noter que ce code est sous-optimal niveau DCC : la trame génère plusieurs bits 1 inutiles en fin de paquet.

Je rappelle ce que j'ai déjà dit : la transmission du dernier octet se terminant par un bit à 1 qui indique qu'il n'y a plus d'octet à suivre (sinon on aurait un bit BYTE START = 0), ce bit à 1 peut faire partie du préambule du paquet suivant.

Ici le code génère un 1 marqueur de fin d'octet
+ un 1 marqueur de "fin de paquet" qui n'existe pas dans la norme
+ insertion d'un 1 supplémentaire annoté "RMT" dans le code

Suivra le préambule du paquet suivant....constitué de 1 !

Donc trois bits de perdus à chaque trame....
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le septembre 09, 2021, 10:07:09 pm
"on" (le monde est petit) m'avait parlé du RMT, mais j'en suis resté au PWM parce qu'il m'a semblé que le RMT ne permet pas de générer le cutout du railcom (je suis dans le principe de réserver cette possibilité) ... mais si Atani l'a fait, on va y jeter un coup d'oeil
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le septembre 09, 2021, 10:08:10 pm
Donc trois bits de perdus à chaque trame....
qui peut mieux faire ?
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 10, 2021, 08:39:59 am
il m'a semblé que le RMT ne permet pas de générer le cutout du railcom

??????

Ca n'est qu'un moyen de moduler l'état d'une PIN. En qui cela t'empeche-t-il de décider périodiquement de forcer l'état bas de la broche pour couper le jus ???? C'est même exactement l'inverse ici : tu pourrais très bien imaginer insérer un état bas de 488 uSec dans la séquence que tu émets.

Enfin bref....

Il reste néanmoins un point que ce dispositif ne gère pas c'est la continuité du signal en dehors d'une trame donnée. Je vais aller en profondeur dans le code voir ce que ça donne...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 13, 2021, 04:48:35 pm
Quelques retours sur l'usage du RMT après expérimentation intensive.

Le système n'est PAS utilisable pour RECEVOIR du DCC, meme si la spec pourrait le laisser entendre.
Sa mise en oeuvre est relativement simple et on peut arriver rapidement à faire une acquisition de signal fiable MAIS....

Mais ce composant ne PEUT PAS réaliser une acquisition d'un signal continue : il stocke ses mesures dans un buffer limité en taille, et il ne livre ce buffer à l'application (via interruption) qu'une fois qu'il s'est arrété de traiter le signal...ce qu'il fait uniquement quand le signal passe à un état de repos : signal stable plus longtemps qu'un délais configurable.

Or en DCC, le signal est modulé et continu : sauf en cas de cutout, on a pas d’arrêt des alternances puisqu'entre deux paquets on doit remplir avec des UN.

De fait, si on demande au RMT de faire la lecture du signal il se bloque en erreur après quelques 100ème de secondes.

Si on le configure pour considérer les ZERO (plus long) comme délais d'arret, il arrive à échantillonner parfaitement tous les UN.

Bref : pas fait pour ça, il est conçu pour faire l'acquisition de trames finies, telles que celles d'une télécommande !

En revanche, en émission, il possède un mode à buffer CIRCULAIRE qui permet d'injecter un flux en continu dans le système...avec une interruption levée quand une fraction du buffer est consommée (ce qui permet de le recharger).

Je n'ai pas essayé ce mode....mais ça doit le faire.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 14, 2021, 09:50:37 am
En revanche, en émission, il possède un mode à buffer CIRCULAIRE qui permet d'injecter un flux en continu dans le système...avec une interruption levée quand une fraction du buffer est consommée (ce qui permet de le recharger).

Je n'ai pas essayé ce mode....mais ça doit le faire.

Merci Sébastien : c’est dans ce mode émission que la solution aux problèmes de timing de LaBox devrait se trouver.
J’ai vu qu’il existe des bibliothèques Arduino à base de RMT. Je n’ai pas pu essayer mais cela doit pouvoir s’implémenter dans l’environnement Arduino.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 16, 2021, 02:06:44 pm
Dans la foulée, un essai valide cette faisabilité mais c'est un exemple qui n'est pas encore intégré avec le reste (donc il peut y avoir des interactions):

La maquette utilisée : LaBox complète avec son booster, connectée au sniffer ESP32.
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=4185;image)
Les résultats récupérés par msport.
(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=4187;image)
Le code de l'exemple qui ne nécessite aucune bibliothèque.

Je reviendrai sur les détails au retour de mes courses...

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le septembre 16, 2021, 02:18:08 pm
Super, il va falloir implanter ça dans DCCpp-LaBox et voir si le résultat est toujours le même...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 16, 2021, 07:14:29 pm
Ce que j'ai fait n'est pas sorcier, en partant d'un exemple.
L'IDE Arduino propose un générateur de code morse, moi j'ai pris un exemple de télécommande infrarouge ailleurs sur le web.

Les includes sont tous dans le core ESP32 (aucune bibliothèque à ajouter):
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/event_groups.h"
#include "Arduino.h"

#include "esp32-hal.h"

J'ai ensuite créé une série de bits d'un paquet IDLE qui sera répété indéfiniment.
#define NR_OF_IDLE_BITS 40


///////////////////////////////////////////////////////////////////////////////
// The NMRA DCC Signal is sent as a square wave with each half having
// identical timing (or nearly identical). Packet Bytes have a minimum of 11
// preamble ONE bits in order to be considered valid by the decoder. For
// RailCom support it is recommended to have at least 16 preamble bits. For the
// Programming Track it is required to have a longer preamble of at least 22
// bits. Packet data follows immediately after the preamble bits, between the
// packet bytes a DCC ZERO is sent. After the last byte of packet data a DCC
// ONE is sent.
//
// DCC ZERO:
//    ----------------
//    |      96      |
// ---|     usec     |      96      ---
//                   |     usec     |
//                   ----------------
// DCC ONE:
//    --------
//    |  58  |     
// ---| usec |  58  ---
//           | usec |
//           --------
//
// The timing can be adjusted via menuconfig with the above being the default
// values when using the APB clock.
// Une trame IDLE est émise quand il n’y a pas de trame de commande à envoyer,
// de façon à alimenter continuellement la voie :
// 111111111111 0 11111111 0 00000000 0 11111111 1
//
///////////////////////////////////////////////////////////////////////////////
int IDLE_pattern[NR_OF_IDLE_BITS] = {1,1,1,1,1,1,1,1,1,1,1,1, 0, 1,1,1,1,1,1,1,1, 0, 0,0,0,0,0,0,0,0, 0, 1,1,1,1,1,1,1,1, 1};
rmt_data_t idle_data[NR_OF_IDLE_BITS];
rmt_obj_t* rmt_send = NULL;
et les 2 variables idle_data (les formes de bits à émettre et rmt_send, pointeur nécessaires au driver.

Ensuite, tout est dans le setup:
void setup()
{
    Serial.begin(115200);
    Serial.println("init RMT pin33");
   
    if ((rmt_send = rmtInit(33, true, RMT_MEM_64)) == NULL) // init sur DCC pin = 33
    {
        Serial.println("init sender failed\n");
    }

    /**
    *    Sets the clock/divider of timebase the nearest tick to the supplied value in nanoseconds
    *    return the real actual tick value in ns
    */
    float realTick = rmtSetTick(rmt_send, 1000); // a calculer pour 1 uS
    Serial.printf("real tick set to: %fns\n", realTick);

    int i=0;
    /*
     * Preparation du jeu d'essai : une trame IDLE
     */
    for (i=0;i<NR_OF_IDLE_BITS; i++) {
      if (IDLE_pattern[i]==0) { // UN
        idle_data[i].level0 = 1;
        idle_data[i].duration0 = 96;
        idle_data[i].level1 = 0;
        idle_data[i].duration1 = 96;
      } else {                  // ZERO
        idle_data[i].level0 = 1;
        idle_data[i].duration0 = 58;
        idle_data[i].level1 = 0;
        idle_data[i].duration1 = 58;
      }
    }
    pinMode(32, OUTPUT); 
    digitalWrite(32, HIGH); 
    Serial.println("loop");

    // Send the data
    rmtLoop(rmt_send, idle_data, NR_OF_IDLE_BITS);
}

rmtInit(33, true, RMT_MEM_64) définit la pin de sortie de l'ESP32, le mode émission seulement et la taille du tampon mémoire utilisé.
rmtSetTick(rmt_send, 1000) définit la période des TICKS, ici proches de la microseconde, ce que confirme realTick.

Ensuite la variable Idle_data est garnie avec les valeurs correspondant à chaque bit de la trame DCC
        idle_data.level0 = 1;        // le 1/2 bit haut
        idle_data.duration0 = 96; //aura une durée de 96 uS
        idle_data.level1 = 0;        // le 1/2 bit bas
        idle_data.duration1 = 96; // également 96 uS

Et l'instruction rmtLoop(rmt_send, idle_data, NR_OF_IDLE_BITS) se charge d'envoyer le signal DCC automatiquement et de façon répétitive.

De ce fait tout cet exemple tient dans le setup.

Mais j'aurai pu utiliser dans la loop l'instruction rmtWrite(rmt_send, idle_data, NR_OF_IDLE_BITS) avec les même arguments,
qui pourrait donner les mêmes résultats ou permettre d'émettre des séquences de trames DCC plus complexes.
Mais il vaut mieux contrôler les flux entre le programme et le tampon RMT, probablement comme l'indique Sébastien en utilisant les interruptions disponibles lorsqu'une fraction du tampon est disponible, car la norme DCC nécessite que les émissions soient permanentes pour alimenter le matériel roulant.

Maintenant il faut intégrer ce mécanismes avec toutes les autres tâches (Wifi, Serial, Can, I2C, AnalogInputs, ..)

Mais cela peut nous rassurer pour le moment, en espérant que ce projet puisse intéresser plusieurs contributeurs pour se renforcer  :D ;D
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: AmadeusHF le septembre 17, 2021, 02:56:54 pm
Tu as remarqué que tu avais 732 paquets DCC émis, et 732 "second half" d'un bit à UN qui étaient plus longues d'une microseconde ?

Lorsque tu utilises le RMT en mode LOOP, pour envoyer une cyclique une trame unique finie, il "perd" un cycle après le dernier bit de la trame, le temps de repartir au début. C'est dans la doc. Tu as donc un bit à UN (le bit de fin de ta trame je pense) dont la seconde partie dure une uSec de plus.

Normalement, en mode WRAP AROUND, dans lequel le buffer d'émission est saturé, ce phénomène ne se produit pas.
En mode CYCLE (LOOP) que tu as utilisé, le RMT identifie la fin de la séquence par le marqueur 0/0 de la liste, ce qui explique le cycle perdu....en mode WRAP AROUND, le buffer est saturé à 100% et il n'y a pas de marqueur de fin....donc pas d'introduction d'un cycle perdu.

Théoriquement !

A vérifier dans la pratique.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 17, 2021, 04:20:13 pm
Merci Sébastien.
Maintenant j’ai une base pour expérimenter les autres modes, le mode LOOP n’étant sûrement pas celui qu’il faut dans LaBox
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le octobre 24, 2021, 09:58:34 am
Il reste un test à faire (je viens d’y penser): lancer des lectures analogiques de tension (mesures de courant) périodiques pour vérifier qu’elles ne dégradent pas la précision du RMT.

A suivre…
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 02, 2021, 09:09:11 pm
Je suis rassuré ! ;D

J'ai ajouté dans la loop une lecture périodique de la pin 36 qui sert à la mesure de courant
    int val = analogRead(36);
    Serial.print(val); Serial.print('-');
    linecount++;
    if (linecount > 50) {
      Serial.println();
      linecount = 0;
    }
    delay(25);

Donc toutes les 25 millisecondes, une mesure de tension a lieu avec analogRead et un Serial.print suit dans la foulée, de quoi perturber notre trame IDLE émise par RMT si le driver RMT est influencé dans l'environnement freeRTOS.

Et bien, QUE NENI, les durées des bits DCC restent parfaites durant les 2 secondes de lecture, mesure et rapport des caractéristiques du DCC sortant de LaBox !!

20:58:24.995 -> Bit Count/4 sec=29294 (Zeros=8055, Ones=21239), Glitches=0
20:58:24.995 -> Valid Packets=733, NMRA out of spec=0, Checksum Errors=0, Lost pkts=0, Long pkts=0
20:58:25.029 -> 0 half-bit length (us): 95.5 (95-96) delta < 1
20:58:25.029 -> 1 half-bit length (us): 57.5 (57-59) delta < 2
20:58:25.029 -> --
20:58:25.029 -> Idle                    11111111 00000000

Donc, le driver RMT travaille de son coté, indépendamment de freeTROS.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: furiet le février 21, 2022, 05:47:31 pm
Bonjour

Ou est-il possible de se procurer un circuit imprimé de "LaBox" ?

Cordialement
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le février 21, 2022, 06:18:27 pm
Il est là dans la réponse 339
 https://forum.locoduino.org/index.php?topic=922.msg12063#msg12063 (https://forum.locoduino.org/index.php?topic=922.msg12063#msg12063)

Mais je regarde la dernière version qui apporte des améliorations... sous réserve de coquille que nous n'aurions pas vue...
La voici, la version 0.4 du 14-06-2021 qui intègre l'ampli de ligne Can MCP2564 à la place su support pour la petite carte qui n'existe plus.

(https://forum.locoduino.org/index.php?action=dlattach;topic=922.0;attach=4523;image)

et la BOM
voir les pièces jointes
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: furiet le février 22, 2022, 12:47:06 pm
Merci beacoup
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: CLB89 le avril 13, 2022, 11:38:36 am
Une question naïve d'un néophyte qui bien qu'ayant parcouru les longs et captivants échanges de ce forum reste sur sa faim : est-il possible de faire fonctionner la bibliothèque de LaBox sur un arduino Mega sur lequel j'ai beaucoup investi ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le avril 13, 2022, 11:45:22 am
Pour un Mega, c’est la bibliothèque DCCpp qu’il faut utiliser.

Il y a l’essentiel en commun.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: CLB89 le avril 15, 2022, 06:31:52 pm
Merci de votre réponse et excusez cette question imbécile : l'ESP32 n'a rien à voir avec la famille Arduino !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 15, 2022, 06:39:07 pm
Un petit effort d'information avant de poster serait utile ...
L'ESP32 se programme avec l'IDE Arduino.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le avril 15, 2022, 06:44:23 pm
Qu'entend-on par "famille Arduino" ?

Si on se réfère à https://fr.wikipedia.org/wiki/Arduino (https://fr.wikipedia.org/wiki/Arduino), la famille est très large et comprend, à mon avis tous les processeurs qui peuvent être programmés avec l'IDE Arduino.

Dans ce wiki ci-dessus, l'ESP32 n'y est pas (ou j'ai mal lu) mais l'ESP8266, du même fabricant, y est : c'est probablement le wiki qui n'est pas à jour


Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 15, 2022, 09:03:12 pm
On peut même interroger le site du fabricant :

https://docs.espressif.com/projects/arduino-esp32/en/latest/installing.html
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: CLB89 le avril 17, 2022, 11:56:18 am
Sans vouloir polémiquer, j'ai simplement questionné dans l'IDE Arduino 2.0 le "Boards Manager" et n'est pas trouvé l'ESP32 dans la liste. D'où ma déduction "polémique" que l'ESP32 ne faisait pas partie de la famille Arduino. Mais je suis bien au fait qu'il existe une Library IDE ESP32 !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le avril 17, 2022, 01:14:22 pm
Polémique Victor ;D
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le avril 17, 2022, 06:03:56 pm
Mais je suis bien au fait qu'il existe ...

Un bon début, continuez !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 14, 2022, 09:56:41 am
Bonjour à tous
Après une longue éclipse pour causes diverses, je reviens vers LaBox... Sur le Github de Locoduino, vous trouverez une version de CommandStation-Ex, un fork nommé 'CommandStation-Ex-Labox'. Le terme 'fork' désigne une copie locale du projet dans le but de l'améliorer. J'espère proposer à l'équipe DCCex par exemple l'organisation du code avec les 'Throttles' mis en place dans le projet Labox original. Je voudrais aussi y ajouter le support de l'application Z21 que ne supporte pas CommandStation-Ex. Bref, du boulot en perpective.
En attendant, je vous propose de récupérer la branche 'labox' qui est une version allégée de CommandStation-Ex adaptée à notre centrale, avec la gestion de l'écran et des boutons sur une base ESP32. Tout n'est pas implanté, il manque en particulier beaucoup de messages sur l'écran, mais la centrale tourne. Je n'ai pas les moyens de tester, en particulier j'ai un problème matériel avec l'étage de puissance que je dois tripoter pour qu'il accepte d'envoyer du courant sur la sortie. Sans doute une soudure à refaire, mais je n'arrive pas à mettre la main sur mon poste à souder.
Bref, pourriez vous essayer de votre côté ?

Pour ceux qui ne savent comment récupérer une version depuis Github, le zip est joint...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Juan le novembre 14, 2022, 01:18:07 pm
Bonjour Thierry
Je suis très heureux que vous soyez de retour au LaBox, mais pourquoi pas un article dans Locoduino ?
J'aimerais vraiment faire cette centrale, mais en suivant les messages sur le Forum, c'est très compliqué pour moi.
Je crois sincèrement qu'un article dédié dans Locoduino serait la bombe !
Cordialement,
Juan
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 14, 2022, 01:32:00 pm
Bonjour Juan,

On pense évidemment faire une série d’articles concernant LaBox sur le site éditorial de Locoduino 😉 .

Mais, comme toujours le projet doit être suffisamment complet pour garantir le succès des modélistes qui le voudraient.
Je vais de ce pas tester ce que Thierry nous propose, un grand merci 🤩 .
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 14, 2022, 03:12:31 pm
Bonjour à tous et merci à Thierry,

j'ai probablement mal cherché mais je n'ai pas vu de config.h ou d'exemple.

Il y en a eu un exemple en mars mais il est très générique. Et j'imagine que pour faire tourner LaBox avec DCC-EX, il faut préciser quelques détails et comment s'y prendre.

Dominique, tu as peut-être les éléments nécessaires ?
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 14, 2022, 07:17:18 pm
Bonjour à tous et merci à Thierry,

j'ai probablement mal cherché mais je n'ai pas vu de config.h ou d'exemple.
Il y en a eu un exemple en mars mais il est très générique. Et j'imagine que pour faire tourner LaBox avec DCC-EX, il faut préciser quelques détails et comment s'y prendre.
Dominique, tu as peut-être les éléments nécessaires ?

Il n'y a pas besoin de fichier exemple comme pour une bibliothèque !
Il suffit de lancer "CommandStation-EX.ino" dans son dossier "CommandStation-EX" (ou un autre nom à donner au .ino ET au dossier, comme d'habitude) qui doit contenir tous les autres fichiers pour compiler.

Mais il faut encore préparer le fichier "config.h" adapté à tes paramètres de réseau et en choisissant le type STANDARD_MOTOR_SHIELD dans le premier #define

Je vérifie...

Ca compile bien pour un Mega :

   #warning config.h not found. Using defaults from config.example.h
Le croquis utilise 50340 octets (19%) de l'espace de stockage de programmes. Le maximum est de 253952 octets.
Les variables globales utilisent 1634 octets (19%) de mémoire dynamique, ce qui laisse 6558 octets pour les variables locales. Le maximum est de 8192 octets.

et pour un UNO :
Le croquis utilise 29104 octets (90%) de l'espace de stockage de programmes. Le maximum est de 32256 octets.
Les variables globales utilisent 737 octets (35%) de mémoire dynamique, ce qui laisse 1311 octets pour les variables locales. Le maximum est de 2048 octets.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 14, 2022, 09:10:05 pm
Je parlais de
// To obtain a starting copy of config.h please copy the file config.example.h which is
// shipped with the code and may be updated as new features are added.
//
// If config.h is not found, config.example.h will be used with all defaults.

Incidemment j'ai une erreur de compilation (à priori, c'est nouveau)  :
soc/soc_caps.h: No such file or directory

ESP32 et IDE 1.8.19

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 14, 2022, 10:54:46 pm
Évidemment c’est l’ESP32 qui est la cible sur LaBox !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 15, 2022, 09:28:19 am
Quelques précisions complémentaires:

- Tu as raison Michel, le config.h n'est effectivement pas inclus, il est joint ici. Ca vient du fait que j'ai utilisé github pour générer le zip, et que lui ne le connait pas.
- Ce projet (appelons le Labox 2) n'est pas une bibliothèque, mais bien un projet simple complet. Donc à ne pas mettre dans Arduino/Library mais directement dans Arduino.
- Du coup, le fichier ino est bien présent au milieu des autres sources.
- Le .ino et le config sont déjà paramétrés pour notre box. Ils marchent dans l'état chez moi, aux tests DCC près.
- Je n'ai compilé que la version ESP32. Je ne sais pas du tout si la version Uno tournera...
- Contrairement au projet original CommandStation-EX qui contient une interface réduite pour les écrans Oled inadaptée à nos besoins, il est nécessaire d'utiliser les mêmes bibliothèques que Labox 1 pour l'écran et les boutons (SSD1306, GFX et OneButton).
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 15, 2022, 10:03:32 am
Bonjour à tous,

Quelques problèmes de compilation :

hmi.h: No such file or directory  : à renommer ?

toujours manquant #include "soc/soc_caps.h" si on le commente on a l'erreur suivante

'SOC_GPIO_PIN_COUNT' was not declared in this scope

de mémoire on peut commenter sans problème :
#error wrong IDF version
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 15, 2022, 06:27:33 pm
Oui, pour hmi.h tu as raison, il faut changer en HMI/hmi.h, et là je compile sur les IDE 2.0.1 et 1.8.19 .
Pour l'autre erreur, je me demande si tu es bien à jour avec les cartes ESP32 . Sur mes trois IDE (je compile aussi avec Visual Studio Code et Platform.IO), j'ai installé les modules ESP avec "https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json" .
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 15, 2022, 07:12:49 pm
Bonsoir,

j'utilisais :

https://dl.espressif.com/dl/package_esp32_index.json

https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json n'a pas réglé le problème

Précédemment on pouvait négliger #error wrong IDF version. Apparemment, maintenant, il faut l'IDF 4.4.3

Je vais rependre le processus d'installation.
https://dl.espressif.com/dl/esp-idf/?idf=4.4 (1Go quand même)


OK pour HMI\mhi.h, j'aurais du le voir.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 15, 2022, 09:37:54 pm
Oui, moi aussi j'aurais dû le voir... Ci joint une version qui marche cette fois avec config.h... J'ai testé avec une loco, et avec les messages d'ajout de loco et de vitesse/direction ajoutés. Reste à tester la lecture/écriture de CV, et peut être aussi la qualité du signal avec le sniffer.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 15, 2022, 10:01:58 pm
Mais je cale à nouveau sur l' IDF

J'ai installé l'IDF 4.4.3 via l’installeur offline  Windows - 3e choix de :

https://dl.espressif.com/dl/esp-idf/


J"ai mis in extenso le lien vers  "soc/soc_caps.h" donc plus d'erreur mais j'ai l'erreur suivante 'SOC_GPIO_PIN_COUNT' was not declared in this scope
Je pourrais partir à la pêche mais ça me semble sans fin.

J'en conclus que la variable d'environnement vers l'IDF 4.4.3 Espressif, variable supposée avoir été créée ne fonctionne pas puisque j'ai toujours #error wrong IDF version.

Incidemment, il n'y a rien dans soc/soc_caps.h
/*
 * SPDX-FileCopyrightText: 2021 Espressif Systems (Shanghai) CO LTD
 *
 * SPDX-License-Identifier: Apache-2.0
 */

/**
 * NOTE: this is not the original header file from the soc component. It is a stripped-down copy to support mocking.
 */


Un redémarrage a été fait ... Le répertoire  Espressif  a été mis à la racine de c:\.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 15, 2022, 10:32:44 pm
De mon côté, je n'ai jamais installé ni utilisé l'IDF, j'ai juste mis l'adresse citée plus tôt dans les préférences de l'IDE, et ça marche comme ça.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 16, 2022, 09:25:04 am
je viens d'installer l'IDE 2.0.1 avec le lien vers l'ESP32 indiqué plus haut et le dossier "CommandStation-EX-LaBox"
Après un bon moment a explorer tous les onglets, au moment de la compilation l'IDE me répond :"No connection established
Compilation error: No connection established"

Ai-je oublié quelque chose ? (l'internet via wifi est bien connecté sur mon Mac) mais l'ESP32 n'est pas branché (d'habitude le compilateur ne le requiert pas).

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 16, 2022, 09:28:21 am
Tu veux surement parler de la version 2.0.1, je vérifierai ce soir si j'ai bien utilisé la même adresse que celle que j'ai donné qui est utilisée dans mon 1.8.19 .
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 16, 2022, 09:29:31 am
Oui en effet c'est la dernière version de l'IDE (j'ai corrigé mon post)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 16, 2022, 09:51:44 am
Dans le 1.8.19, c'est la même adresse (en tout cas ça ressemble !)
1.8.19 : "https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json"
2.0.1   : "https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json"


En fait la 1.8.19 le compile bien :
Le croquis utilise 752705 octets (57%) de l'espace de stockage de programmes. Le maximum est de 1310720 octets.
Les variables globales utilisent 39352 octets (12%) de mémoire dynamique, ce qui laisse 288328 octets pour les variables locales. Le maximum est de 327680 octets.

En fait ça compile bien aussi sur la 2.0.1 : maintenant
Sketch uses 752705 bytes (57%) of program storage space. Maximum is 1310720 bytes.
Global variables use 39352 bytes (12%) of dynamic memory, leaving 288328 bytes for local variables. Maximum is 327680 bytes.

J'ai relancé l'IDE et j'ai du sélectionner l'ESP32 Dev Module deux fois pour qu'il le prenne bien en compte. La compilation prend un certain temps la première fois car il doit importer les fichiers ESP32

J'avais sélectionné avant le DUE et il faut fermer l'autre projet DUE pour que le projet LaBox s'initialise bien. En tout cas l'IDE associe le processeur au projet à l'ouverture du projet, ce qui est une bonne chose.


Y'a plus qu'à installer le soft sur une de mes LaBox et tester...
A suivre  ;D

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 16, 2022, 10:53:11 am
Bon, j'y suis arrivé avec mes problèmes d'IDF et de soc.

Ce n'est pas les pilotes soft qui coinçaient mais je trainais toujours une veille version de hardware : mis à jour en 2.0.5 (via gestionnaire de carte) et c'est réglé.

Comme dit Dominique : à suivre.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 16, 2022, 03:33:43 pm
Encore quelques problèmes de téléversement et on teste sur LaBox (-> mise à jour de l'IDE en 2.0.1)

mais pas d’affichage sur l'Oled ... Ai-je oublié quelque chose dans config.h ?
pas de DCC.
cet ESP avait fonctionné avec la version Ex de Dominique.

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13864
load:0x40080400,len:3608
entry 0x400805f0
<* License GPLv3 fsf.org (c) dcc-ex.com *>
<* Platform: ESP32 *>
<* LCD0:DCC++ EX v4.2.4 rc1 *>
<* LCD1:Lic GPLv3 *>
Start wifi
........................................<* Could not connect to Wifi SSID freebox_CKIHWJ *>
<* Forcing one more Wifi restart *>
E (22645) wifi:sta is connecting, return error
........................................<* Wifi STA mode FAIL. Will revert to AP mode *>
<* Wifi AP SSID DCC_0689F0 PASS xxx mon pw xxx *>
<* Wifi AP IP 192.168.4.1 *>
<* Server will be started on port 2560 *>
End wifi
<* CurrentPin=A0, Offset=2695, TripValue=1000 *>
<* Channel 0 DCC signal for MAIN start *>
<iDCC-EX V-4.2.4 rc1 / ESP32 / ESP32 G-PORTX-HAL-20220830>
<* LCD3:Ready *>
<p0>
<* LCD2:Power Off *>
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 16, 2022, 05:11:07 pm
Tu as pris le config.h et le .ino presents dans le zip de mon message d'hier soir à 21h37 ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 16, 2022, 06:04:29 pm
Pour être totalement affirmatif, je viens de les récupérer à nouveau et les téléverser dans LaBox : pas de DCC, rien sur l'Oled.

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13864
load:0x40080400,len:3608
entry 0x400805f0
<* License GPLv3 fsf.org (c) dcc-ex.com *>
<* Platform: ESP32 *>
<* LCD0:DCC++ EX v4.2.4 rc1 *>
<* LCD1:Lic GPLv3 *>
Start wifi
E (483) wifi_init_default: netstack cb reg failed with 12289
........................................<* Could not connect to Wifi SSID VIDEOFUTUR_ED5939_2.4G *>
<* Forcing one more Wifi restart *>
E (20513) wifi:sta is connecting, return error
........................................<* Wifi STA mode FAIL. Will revert to AP mode *>
<* Wifi AP SSID DCC_0689F0 PASS 2932003454 *>
<* Wifi AP IP 192.168.4.1 *>
<* Server will be started on port 2560 *>
End wifi
<* CurrentPin=A0, Offset=168, TripValue=1000 *>
<* Channel 0 DCC signal for MAIN start *>
<iDCC-EX V-4.2.4 rc1 / ESP32 / ESP32 G-PORTX-HAL-20220830>
<* LCD3:Ready *>
<p0>
<* LCD2:Power Off *>

W10, IDE 1.8.19
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 17, 2022, 02:02:19 pm
Voici une version qui devrait se compiler et afficher quelque chose sur l'écran !

En fait, dans l'IDE Arduino USE_HMI n'était pas défini, donc on compilait bien mais on avait une version sans interface graphique. Alors que dans Visual Code, je l'avais défini autrement, c'est pourquoi ça marchait complètement chez moi.
Une fois ajouté USE_HMI, les problèmes ont commencé, parce que si Visual Code permet de dire 'va aussi chercher les fichiers dans HMI', ce n'est pas possible avec l'IDE. J'ai donc basculé tous les fichiers du répertoire HMI dans le même que les autres sources, modifié quelques include, et là ça compile et ça marche avec l'IDE 1.8.19 !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 17, 2022, 07:15:16 pm
Prometteur !

Gestion du serial et affichage. DCC on.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 18, 2022, 11:48:16 am
Pas de succès avec le WiFi :

Box address :
192.168.4.1
... WifI ok ...
 !! No WiFi !!

Quelle configuration pour se mettre en mode AP ? (devait y basculer automatiquement ?)

Est-ce que de base LaBox Ex devrait se connecter au WiFi domestique ?

on a dans defines.h  #define WIFI_ON true

on a dans config.h
#define WIFI_HOSTNAME "LaBox"
#define IP_ADDRESS { 192, 168, 1, 200 } // IP LaBox
#define IP_PORT 2560 // port IP LaBox

j'ai modifié :
#define WIFI_SSID "box maison"
#define WIFI_PASSWORD "pw maison ?"

Todo : affichage tension, courant. Activation des boutons


Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 18, 2022, 02:47:21 pm
Pour le mode AP, si je lis bien à la fois le config_example.h fourni dans la version originale de CommandStation-Ex et le code de connexion, il faut laisser la ligne comme dans la version originale :
#define WIFI_SSID "Your network name"

Ils testent explicitement sur 'Your network' !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 18, 2022, 04:01:15 pm
Avec le config.h non modifié, CommandStation-EX-LaBox crée un réseau WiFi avec un SSID DCC_0689F0 apparemment protégé par WPA2
(si on ne met pas de mot de passe dans config.h, le WiFi n'est pas activé.)
Et je n'arrive pas à entrer le mot de passe pour DCC_0689F0.
Donc pas de SSID LaBox.


Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 18, 2022, 09:06:11 pm
Oui, il y avait un problème. La version jointe crée un AP.
Le nom du SSID dépend de l'adresse MAC de la carte, et le password (visible sur la console) reprend le SSID et échange au début DCC par PASS !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 18, 2022, 09:35:34 pm
Toujours DCC_0689F0 et pas LaBox
Problème authentification ...
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13864
load:0x40080400,len:3608
entry 0x400805f0
<* License GPLv3 fsf.org (c) dcc-ex.com *>
<* Platform: ESP32 *>
<* LCD0:DCC++ EX v4.2.4 rc1 *>
<* LCD1:Lic GPLv3 *>
Start wifi
E (4555) wifi_init_default: netstack cb reg failed with 12308
<* Wifi AP SSID DCC_0689F0 PASS PASS_0689F0 *>
<* Wifi AP IP 192.168.4.1 *>
<* Server will be started on port 2560 *>
End wifi
<* CurrentPin=A0, Offset=169, TripValue=1000 *>
<* Channel 0 DCC signal for MAIN start *>
<iDCC-EX V-4.2.4 rc1 / ESP32 / ESP32 G-PORTX-HAL-20220830>
<* LCD3:Ready *>
<p0>
<* LCD2:Power Off *>
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 18, 2022, 09:40:29 pm
Désolé je n’ai pas encore eu le temps de tester. Probablement dimanche.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 18, 2022, 10:21:31 pm
SSID DCC_0689F0 PASS PASS_0689F0

Pas Labox, mais DCC_0689F0 (chez toi...)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 18, 2022, 10:26:47 pm
Oui, mais pas moyen de connecter un smartphone avec EngineDriver sur DCC_0689F0 (l'entrée du mot de passe n'est pas proposée)  ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 19, 2022, 05:35:51 pm
Do mon côté, ça marche en AP si je coupe l'accès aux data par le téléphone. Seul le Wifi doit être branché. ça faisait déjà ça avec mon ancien téléphone, et je pense que c'est une limitation d'Android en mode AP...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 19, 2022, 10:15:23 pm
Sur mon vieux smartphone dédié à EngineDriver, les data sont désactivées, d'autant plus qu'il n'a  pas de carte SIM, ce qui ne l"empêche pas de se connecter à ma box en WiFi ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 20, 2022, 09:34:06 am
Et ça fonctionnait avec Labox V1? Ou avec Labox V2 sur uno ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 20, 2022, 09:39:36 am
Et ça fonctionne toujours avec la V1 ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 20, 2022, 10:25:29 am
Les réseaux WiFi vus :
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 20, 2022, 09:57:19 pm
Hello,

J'ai compilé la dernière version LaBox-2 : OK avec l'IDE 1.8.19 (mais échec avec l'IDE 2.0.1)
Téléversement OK
Réseau Wifi : le PA est DCC_7C6714 et le password PASS_7C6714 (c'est pas aussi simple qu'avant avec LaBox sans EX mais en attendant ça marche)
Ensuite Withrottle iPhone configuré comme avant : 192.168.4.1 qui s'affiche sur l'OED
Port 44444 ... ça ne marche pas : "network has been disconnected"

A part cela les boutons et l'HMI fonctionnent comme avant, mais je ne peux pas sélectionner et commander une locomotive

Beau début !

J'ai réessayé l'IDE 2.0.1 un peu plus tard et ça a fonctionné (compilation et téléversement) : mais ça fait chauffer le processeur du Mac !!! (on entend le ventilo !) Bizarre ! De plus l'ouverture de l'IDE avec ce programme est très longue.
J'ai upgradé en 2.0.2 et c'est mieux : compilation plus rapide sans chauffer le Mac mais ouverture longue à cause de la quantité de fichiers ...

Là maintenant je sèche 😩

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 21, 2022, 09:02:38 am
Pour le port, je n'ai pas changé le port par défaut de CommandStation, c'est 2560 qui marche chez moi.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 21, 2022, 12:00:10 pm
OK ça se connecte bien, je récapitule :

en point d'accès le SSIP est DCC_XXXXX (XXXXX étant déduit de l'adresse Mac de l'ESP32 comme expliqué par Thierry, on le trouve dans la liste de PA commençant par DCC_ ,  c'est simple)
mot de passe du PA PASS_XXXXX (même suffixe ci-dessus, pas demandé les fois suivantes sur mon iPhone)

adresse 192.168.4.1
port 2560

Si la connexion est OK vue de Withrottle, les commandes de vitesse (curseur sur Withrottle) ne sont pas répercutées sur le HMI de l'OLED
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 21, 2022, 02:03:12 pm
Bonjour,

avec un smartphone plus récent, connexion automatique sur DCC_0689F0.

Avec Engine Driver :
Mise sous tension DCC OK
Affichage de la loco / vitesse dans le HMI

Réaction des boutons très aléatoire.
Pas de tension / courant.

Pour ne pas condamner mon ancien smartphone à retourner dans son tiroir, il faudrait soit supprimer le mot de passe WiFi, soit le passer en WPA PSK au lieu de WPA2 PSK.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 22, 2022, 10:35:45 pm
Voici une nouvelle version, avec un SSid qui s'appelle Labox_xxx, et un mot de passe Pass_xxx . Pas de moyen pour l'instant de supprimer complétement le mot de passe, ou de passer en mode WPA simple. C'est normalement tout le temps compatible WPA, WPA2 et même WPA3 !
J'ai mis en route aussi l'affichage voltage/courant. Par contre, les routines utilisées pour la remontée d'info de la voie ne semblent pas fonctionner... Ce qui fait que la lecture de CV ne marche pas. La loco vibre, mais rien ne remonte, malgré l'adaptation nécessaire à la lecture de CV sur la voie principale.

Est il prévu un jour d'avoir une Labox avec deux sorties, voie principale et voie de programmation ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 22, 2022, 11:21:17 pm
Pas de succès avec mon vieil Android ... problème mot de passe conservé

Par contre avec celui que j'utilise connexion sur Labox_xxxxxx avec le mot de passe mis en dur dans le programme (pas encore testé à "" ) :
Affichage loco sur hmi qui suit EngineDriver
Courant et tension présents
Boutons inopérants
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 23, 2022, 10:49:08 am
mon vieil Android ... a bien voulu passer le mot de passe et donc a repris du service.

Mettre à blanc le mot de passe WiFi ne fonctionne pas : LaBox ne génère pas d'AP, on reste sur un écran partiel.
C'est le mot de passe de ma Freebox que j'ai mis et qui est pris en compte.

Pour les boutons : où sont définis les GPIO correspondants ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 23, 2022, 01:23:47 pm
#define PIN_BTN_SEL             18
#define PIN_BTN_BTNUP           23
#define PIN_BTN_BTNDWN          19

dans hmiConfig.h
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 23, 2022, 02:56:12 pm
Dans bibliothèque OneButton, on a :

OneButton::OneButton(const int pin, const boolean activeLow, const bool pullupActive)

dans hmi.cpp, on a :

  BtnUp = new OneButton(PIN_BTN_BTNUP, true);
  BtnDown = new OneButton(PIN_BTN_BTNDWN, true);
  BtnSelect = new OneButton(PIN_BTN_SEL, true);

est-ce qu'il ne faudrait pas pour activer les pullup, avoir ?

  BtnUp = new OneButton(PIN_BTN_BTNUP, true, true);
etc.



Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 23, 2022, 03:35:44 pm
... mais sur la version de pcb que j'ai ressorti j'ai un problème d'inversion de contact ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 23, 2022, 03:45:07 pm
Du côté HMI, c'est le code tel qu'il est utilisé dans Labox V1, à part quelques subtilités... Je n'ai rien changé au code des boutons.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 23, 2022, 04:03:20 pm
Autant pour moi, une fois les boutons dans le bon sens, j'ai accès aux menus. Le pullup doit être activé par ailleurs.
La détection d'adresse n'est pas encore implémentée ? Mais la voie est mise sous tension.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 23, 2022, 05:00:03 pm
C'est implémenté, mais la remontée d'info par la lecture analogique de la broche 36 ne semble pas fonctionner dans ce cadre là...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le novembre 24, 2022, 10:16:07 am
Et après réflexion, je pense que ce sont les facteurs de seuil et de valeur qui ne doivent pas correspondre à notre implémentation matérielle. A creuser.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 24, 2022, 09:14:38 pm
Du coté timings, c'est plus que bon ...

Moi aussi, j'ai des problèmes de version d'IDE après installation de la 2.0.2.

La 1.8.19 termine la compilation avec : 'struct esp_wps_config_t' has no member named 'crypto_funcs'
alors que la 2.0.2 la traite correctement

mais cette 2.0.2 refuse de téléverser DCCInspector-EX, heureusement j'ai une précédente installation de la 1.8.19 sur un autre ordinateur.


Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 24, 2022, 10:14:54 pm
De mon côté la 2.0.2 a fonctionné nickel (compile et televersement)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le avril 22, 2023, 02:40:33 pm
Bonjour à tous

Nouvelle version 2.1.0 aujourd'hui. Le protocole Z21 a été appliqué et les applis Z21 sont donc devenues compatibles. Je travaille toujours sur la partie lecture de CV, mais je patine...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 04, 2023, 08:49:43 pm
Et voilà, une nouvelle version 2.2.0 est poussée sur Github, et elle permet enfin de lire l'adresse de la loco sur le réseau.

Le chemin a été long, jusqu'à ce que je me demande si l'original CommandStation-ex fraichement téléchargée de leur Github sait, elle, déjà lire les CVs. Et là, surprise, en utilisant l'entrée par la console via la commande <R 1 2 3> et en configurant la voie de programmation, ça marche ! Et même plutôt bien puisque trois locos différentes avec des décodeurs différents ont été testées avec un taux de réussite de plus de 90%.
Boosté par cette découverte, alors que je commençais à émettre des doutes sur mon matériel ou sur la capacité d'un ESP32 à lire une donnée analogique, je suis reparti de plus belle à la chasse au fautif dans Labox v2. Et je me suis aperçu après moultes essais que c'est la mise à jour de l'affichage sur l'écran Oled qui nuit à la qualité de réception des Ack (acknowledgement) , ces petites consommations de la loco qui font vibrer la machine et répondent à la centrale. Je pense que les timings de rafraîchissement de l'écran décalait d'autant les mesures de consommation, et on devait louper la plupart des acks qui ont un timing très précis. Et en bloquant le rafraîchissement de l'écran, par ailleurs inutile à ce moment, le temps de la lecture d'un CV le problème est résolu !
Je tente alors de faire fonctionner la lecture de CV sur la voie principale puisque la carte Labox n'a pas de sortie pour une voie de programmation. Là encore je rencontre un mur, j'ai tout tenté en essayant de leurrer le moteur de lecture des Ack, la génération des signaux DCC, mais rien n'y a fait. Je me suis alors rabattu sur une honteuse astuce pour contourner le problème. Ce n'est pas élégant, mais ça marche.
Impossible de contourner la lecture pour la convaincre de fonctionner sur la voie principale, la lecture ne marche que si dans la configuration on déclare une voie de programmation. Et cette configuration est fabriquée au lancement de l'ESP32... Vous me voyez venir ? J'ai tout simplement fait redémarrer l'ESP pour le changer de mode. Le mode est stocké tout au bout de la mémoire EEPROM pour ne pas gêner un éventuel usage par le moteur DCC, un seul et unique octet qui est soit un 'M' soit un 'P' qui dit dans quel mode sera la centrale lorsqu'elle redémarrera. Si rien n'a jamais été écrit là, on reste en mode pilotage ou 'M'.
En mode 'M', tout fonctionne correctement avec les applis compatibles. Les trains sont pilotés, ainsi que les accessoires comme sait le faire le successeur de DCC++. Lorsque l'on va dans le menu et que l'on demande à lire une CV, un 'P' est écrit dans l'EEPROM, et ESP.restart() est appelé ce qui redémarre le microcontrôleur. Pendant ce démarrage en mode 'P', je n'ai pas réussi à enlever la connexion Wifi qui est pourtant inutile pour ce mode, par contre l'affichage reste sur l'écran de lecture avec un ---- qui représente la valeur non lue. Dès que possible la lecture est lancée et la valeur remplace le '----'. Si l'on appuie sur le bouton 'Select' de la centrale, un 'M' est écrit dans l'EEPROM puis l'ESP est redémarré, et on revient dans le mode de pilotage.
C'est à peu près transparent, mais avec le redémarrage on a perdu les valeurs courantes des vitesses et des fonctions de la loco... Mais ça vaut mieux que de ne pas avoir de lecture de CV. Ca veut dire aussi que les commandes série de lecture/écriture (comme le <R 1 2 3>) ne fonctionneront pas en mode pilotage.

A noter que j'ai mis à jour la partie CommandStation-ex avec leur dernière version qui apporte notamment des corrections sur la lecture pour certains décodeurs récalcitrants.

En espérant que vous pourrez tester.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 04, 2023, 11:11:35 pm
Un grand BRAVO à toi, Thierry !
Quel progrès et quel boulot, surtout avec toutes ces explications.

Je vais tester dès que possible, avec impatience.

Amitiés.
Dominique
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 05, 2023, 09:01:37 am
Merci Dominique.

J'ai oublié de préciser qu'il faut ajouter une ligne

#define LABOX_MOTOR_SHIELD   new MotorDriver(32, 33, UNUSED_PIN, UNUSED_PIN, 36, 2.00, 2000, UNUSED_PIN)

dans config.h .
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 05, 2023, 06:02:06 pm
Un grand BRAVO à toi, Thierry !
Quel progrès et quel boulot, surtout avec toutes ces explications.

Je vais tester dès que possible, avec impatience.

Mais où est cette version ?
(Sur le Git Locoduino, elle semble ancienne)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 05, 2023, 10:42:58 pm
Il faut sélectionner la branche Labox en haut à gauche de l'écran.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 06, 2023, 09:47:59 am
... mais de quel écran ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Souris verte le mai 06, 2023, 02:56:02 pm
https://github.com/Locoduino/CommandStation-EX-LaBox/tree/LaBox (https://github.com/Locoduino/CommandStation-EX-LaBox/tree/LaBox)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 06, 2023, 03:13:22 pm
Très bien, mais comment arrive-t-on à cet écran depuis celui du Git ?

https://github.com/Locoduino/CommandStation-EX-LaBox

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 06, 2023, 04:38:56 pm
Cliquer sur le nom de la branche courante (Master)
Sélectionner la nôtre : Labox.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 06, 2023, 05:00:51 pm
OK, c'est vu, merci.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 06, 2023, 05:51:42 pm
Petit problème de compilation ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 06, 2023, 06:10:28 pm
Peut-être mettre à jour la biblio ESP32 ?

Chez moi c’est sans erreur !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 06, 2023, 06:12:02 pm
Oui j'ai dû aussi mettre à jour l'ESP32 pour que ça marche dans mon IDE 2.1.0 .
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 06, 2023, 07:57:49 pm
Oui, passage de la 2.0.8 à la 2.0.9 pour compiler (IDE 1.8.19)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 06, 2023, 10:07:16 pm
Opérationnel avec le config.h complété.

Mais si la loco commandée ( la 8 ) reçoit bien ses ordres sur la voie, au sniffer, on voit passer des ordres fantômes pour d'autres locomotives : 15, 1566 et autres.
Les commandes d’accessoires sont aussi fantaisistes.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 16, 2023, 12:25:50 pm
Enfin j'ai trouvé un peu de temps pour tester le logiciel LaBox 2.2.0 sur la version 4.2.1 rc1 de DCC-EX, avec l'IDE 2.10 et la bibliothèque ESP32 2.0.9 et le bon fichier config.h réglé sur mon réseau wifi : ça parait compliqué d'identifier les ingrédients mais c'est important et... CA MARCHE !

Voir les 2 photos ci-dessous :
L'application Z21 iPhone
L'écran Oled sur LaBox

Dans l'écran du Moniteur, on voit passer toutes les commandes et on peut passer facilement d'une loco à une autre avec cette appli.
J'ai essayé WiThrottle et là ce n'est pas concluant, mais, finalement l'application Z21 est franchement mieux.

Il me reste à tester sur les rails avec de vrais locos, ce qui va me prendre un peu de temps car mon réseau est en chantier, interrompu depuis pas mal de temps, donc après un nettoyage soigneux des traces de plâtre et de peinture ...

Super boulot de Thierry qui est un peu seul sur le logiciel. Merci, merci !!

J'aimerai tester le Can un de ces jours mais l'intégration de fichiers supplémentaires dans l'architecture DCC-EX est complexe. Je dois replonger dedans.

A suivre...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 18, 2023, 01:15:40 pm
Nouvelle version 2.2.1 de Labox (https://github.com/Locoduino/CommandStation-EX-LaBox/tree/LaBox)

Comme j'en ai parlé plus tôt, si l'on demande à lire l'adresse de la loco à la centrale, elle va redémarrer dans un mode qui lui permet de le faire. La nouveauté consiste à permettre à une application Z21 comme celle de Fleishmann/Roco de lire et écrire les CV dans ce mode. Il suffit de demande à lire l'adresse via le menu de Labox comme expliqué auparavant, et une fois que l'adresse est lue et avant de retourner au mode de pilotage, de demander à l'appli Z21 de lire ou d'écrire des CVs. Je ne crois pas que les applis wiThrottle ou EngineDriver en soient capables...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 18, 2023, 01:35:33 pm
Je pense qu’on peut se concentrer sur l’appli Z21 qui est compatible avec les le plateformes IOS et Android.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 18, 2023, 09:50:07 pm
Rebonjour.

Pour m'amuser autour de Labox, j'ai créé une nouvelle application à installer sur la centrale Labox pour la transformer en petite centrale Sprog.
CommandStation-Ex-LProg est une variante de Labox qui n'est pas encore sur Github et qui permet de lire et d'écrire les CV uniquement avec le clavier de la centrale.
C'est compatible avec la lecture/écriture de CVs de l'application Z21, et aussi à partir d'un navigateur avec l'appli web WebThrottle-EX-SM-Prog-Tab  (https://github.com/tanner87661/WebThrottle-EX/tree/SM-Prog-Tab) développée par un membre du groupe Discord DCC-Ex . L'inconvénient de cette méthode, c'est que la centrale doit être connectée en USB. Apparemment c'est compliqué voire impossible de communiquer en Wifi à partir de HTML. L'application EX-Toolbox dérivée de EngineDriver fonctionne également.

L'ergonomie de LProg est des plus simples :
On arrive sur l'écran de lecture de CV. Si l'on a rien commencé, un appui sur 'Select' va sur le menu, et la première option permet de lire les CV, la deuxième d'en écrire.
Pour la lecture : appuyer sur les boutons haut/bas pour changer le numéro de CV à gauche de l'écran puis Select pour lancer la lecture. La valeur s'affiche à droite sur l'écran.
Pour l'écriture : appuyer sur les boutons haut/bas pout fixer le numéro de CV à écrire à gauche de l'écran, puis Select pour passer sur la valeur à droite. Appuyer sur haut/bas pour fixer la valeur, puis Select pour lancer l'écriture. Si l'écriture a réussi , un OK apparait à côté de 'Value' sur l'écran. Un appui sur Select repart fixer l'adresse pour une nouvelle écriture. Si l'écriture a échoué, un FAIL apparait à côté de 'Value'. Un appui sur Select refait une tentative.

L'ergonomie pourrait sans doute être améliorée, mais je pense que le principal usage devrait se faire depuis une application externe. Peut être relancer l'idée de Denis sur une appli Processing ? Ou une appli Node.js qui permettrait d'être indépendant de la plateforme...
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le mai 20, 2023, 09:58:05 pm
Apparemment c'est compliqué voire impossible de communiquer en Wifi à partir de HTML.

Que nenni mon cher Thierry, bien au contraire si tu es sur un ESP32.

Ma centrale dcc railcom qui est commandée par mon contrôleur que vous connaissez en HTML fonctionne comme cela.

(https://alkans.fr/locoduino/img/centrale_esp32.jpg)

Je ne peux pas mettre l'ensemble du projet en PJ car cela fait au total 16Mo mais tu peux le télécharger ici : https://alkans.fr/locoduino/DCC_controller_ESP32.zip (https://alkans.fr/locoduino/DCC_controller_ESP32.zip)

N'hésite pas si tu veux en parler.

Christophe
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 21, 2023, 09:45:04 am
En regardant le site de DCC-EX, je pense que LaBox devrait figurer en bonne place parmi les “motor shield” proposés.

Justement pour éviter cette connexion avec un PC et toutes les conditions de compatibilité qui font couler beaucoup d’encre.

Les fonctions de programmation des CVs sont importantes et c’est juste qu’elles soient possibles mais elle restent quand mème épisodiques. Elles n’ont pas besoin d’un environnement lourd. Le plus simple est le mieux.

Je trouve donc que la direction donnée par Thierry au projet LaBox est bien la bonne.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 21, 2023, 03:59:11 pm
Une question à Thierry : est-ce que DCC-EX intègre bien le cut-out nécessaire au décodage de Railcom ?

Sur le git Locoduino du projet de Christophe (https://github.com/Locoduino/DCCxx-ESP32-WiFi-Railcom (https://github.com/Locoduino/DCCxx-ESP32-WiFi-Railcom)) c’est bien indiqué :
« Ce programme permet la réalisation d'une station de commande DCC en WiFi qui génère le cutout nécessaire pour la détection RailCom ».

Donc oui semble-t-il mais est-ce cas dans la version Labox 2, version 2.2.1 qui n’adresse que le L6203 et non le LMD18200 ?

Si je comprends Railcom, ce cutout est présent dans DCC-EX qui le génère automatiquement. Il n’y aurait donc très peu de modification du logiciel Version 2.2.1 sauf la pin du LMD a ajouter pour le court-circuit dans le fichier config.h

Autrement dit, en utilisant la nouvelle carte LaBox développée par Michel (photo ci-dessous), qui contient le LMD18200, donc capable de faire le cutout, n’assiste-on pas à une évolution naturelle de LaBox ?

Cela permettrait de faire converger les projets !

Cette carte est fabriquée avec les composants CMS soudés en usine. Le bus Can est toujours supporté. L’esp32 est en version 30 pins.

Vos retours sont les bienvenus !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 21, 2023, 04:06:28 pm
Mille excuses, je viens de voir mon erreur : DCCxx-Railcom de Christophe n’est pas hérité de DCC-XX appliqué à LaBox 2.

Donc pour converger, il faut souhaiter que DCC-XX  fasse le cutout naturellement. Est-ce le cas ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le mai 21, 2023, 04:09:09 pm
Bonjour Dominique,

Je ne serais pas aussi affirmatif que toi concernant la génération du cutout dans DCC-Ex. Il en est question depuis longtemps et puis finalement c'est toujours reporté. Pour le cutout, il ne suffit pas du hard, 18200 comme tu cites pas exemple, mais c'est aussi logiciel : Il faut que le soft arrête l'envoi de tout courant sur la voie (avec l'entrée break du LMD18200) pendant une durée de 454 à 488 µSec

NMRA page 6 : https://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.3.2_bi-directional_communication.pdf (https://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.3.2_bi-directional_communication.pdf)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 21, 2023, 04:42:05 pm
tu as raison, sur Discord :
Citer
Just to be clear.. the brake output is not used in dcc-ex 4.x but will be used on 5.x if you wish to run DC locos as well as DCC.
Brake is also required should we ever support the RailCom cutout.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 21, 2023, 04:51:50 pm
Donc si je pense « convergence » ce n’est pas sur le logiciel tant que le cutout n’est pas implémenté dans DCC-Ex.

Il reste le matériel qui peut être animés par 2 logiciels différents en attendant la convergence logicielle.

N’est-il pas ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le mai 21, 2023, 05:51:14 pm
Effectivement, ce n'est pas géré par CommandStation-EX, mais il y a une branche Railcom (https://github.com/DCC-EX/CommandStation-EX/tree/RailCom) dont on pourrait peut être s'inspirer pour lui donner cette facilité. Sinon on attend la version 5 en cours de développement qui intègrera directement Railcom d'après Discord... Mais ce n'est pas forcément pour tout de suite, et la version ESP32 ne sera peut être pas la première...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 21, 2023, 07:03:30 pm
En tout cas, le soft 2.2.1 se charge bien sur la carte Railcom Avec un LMD18200. J'essaierai sur les rails demain peut-être...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le mai 22, 2023, 09:45:13 am
Attention, il faut réaffecter les sorties de l'ESP aux broches du LMD pour la faire fonctionner LaBox sur la carte Railcom.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 22, 2023, 11:17:17 am
Ca veut dire qu'il faut modifier le config.h avec les pins suivantes :
DIR = IO13
PWM = IO12
BRAKE = IO14 (pour plus tard avec le version Railcom)
CURRENT = IO36 ou selon un strap en JP3 à expliciter

Ce qui devrait donner :

#define LABOX_MOTOR_SHIELD   new MotorDriver(12, 13, UNUSED_PIN, UNUSED_PIN, 36, 2.00, 2000, UNUSED_PIN)

et des valeurs de courant à travailler


Est-ce bon ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 22, 2023, 09:50:24 pm
Bon, avec cette définition ça ne marche pas.
Je pense que les pins 32 et 33 sont mieux adaptées au timer pour la génération du DCC

A creuser...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le mai 23, 2023, 10:23:34 am
Je reviens sur la version 2.2.1 de LaBox avec booster (pont en H) L6203 avec l'application Z21:

Fonctionnement totalement intuitif, connexion rapide au réseau Wifi, Z21 se connecte aussi instantanément à LaBox et le choix des locos est simple.
Si ça ne se connecte pas automatiquement, il faut simplement vérifier si l'adresse IP de LaBox, indiquée sur l'écran, correspond à celle de la configuration Z21 dans les paramètres de l'application. Modifier en conséquence et cliquer sur "Rétablir".

Grâce à la liste des locos en dessous du curseur de vitesse, on passe très facilement d'une locomotive à une autre.
J'ai testé sur mon réseau dans la zone de va et vient qui peut s'isoler du reste.

Par contre, un manque important c'est l'arrêt automatique du/des trains en cas de changement d'application dans le smartphone (mais un appel téléphonique entrant devrait stopper les trains d’après les réglages de l’appli) : c'est la perte de contrôle assurée. Withrottle n'a pas cet inconvénient.

Très beau travail avec cette intégration de DCC-EX dont la version 5 est prévue prochainement. A noter que DCC-EX est devenu une société commerciale.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 15, 2023, 04:47:02 pm
J'en avais envie : commuter la source DCC sur mon réseau entre la centrale interne (Méga LMD18200) et une source externe en l'occurence LaBox.

Voilà c'est fait et j'ai pu tester la commande de 4 trains simultanément avec l'application Z21. Ca marche bien et on peut passer facilement d'un train à un autre en cliquant sur l'image du train sous le curseur. Le train précédent continue à rouler. Pour un arrêt d'urgence il faut être agile des doigts pour récupérer le train rapidement.

Il s'agit de la version 2.2.1. qui se trouve ici : https://github.com/Locoduino/CommandStation-EX-LaBox/tree/LaBox (https://github.com/Locoduino/CommandStation-EX-LaBox/tree/LaBox)
Petite correction à faire : dans le code la version 2.2.0 n'a pas été mise à jour.en 2.2.1. Mais elle apparait dans le commentaire de chaque fichier.

J'ai testé aussi la lecture de l'adresse et ça marche aussi .
Si la lecture réussit, le mode principal revient automatiquement après reboot automatique.
Mais si la lecture échoue, laBox reste bloquée indéfiniment ou faire un reboot manuel.

J'ai testé sur au moins 2 cartes LaBox de version différente.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le septembre 17, 2023, 06:25:12 pm
Bonjour

Suite aux tests de Dominique, j'ai produit une version 2.2.2 pour améliorer un peu les choses du côté de la lecture de l'adresse de la loco:

- Une fois la valeur lue, le message 'ERR' s'affiche si un problème s'est produit.
- Après la lecture, un petit menu à deux entrées 'Relire' et 'Quitter' apparait. Les boutons Up/Down changent l'option sélectionnée. Select la valide.
- Si la lecture s'est bien passée, 'Quitter' est sélectionné, mais il est possible de réessayer en utilisant 'Relire'.
- Si la lecture a échoué, 'Relire' est sélectionné pour refaire un essai si besoin.
- Lors du reboot transparent après avoir quitté le mode programmation, le logo Locoduino et le logo du Wifi ne s'affichent plus.
- La version anglaise des messages du HMI a été complétée. Il en manquait les trois quart !

Pour aussi tenir compte de la facilité d'accès au code, la branche Labox est maintenant sélectionnée par défaut dans Github.

Voilà, voilà...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le septembre 17, 2023, 07:15:19 pm
Bravo Thierry 👍😅
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le octobre 04, 2023, 09:08:58 pm
Et j’attend la dernière version du circuit imprimé fait par Michel pour compléter les tests et continuer l’écriture de l’article sur la construction de LaBox.

Ça ne chaume pas !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le octobre 07, 2023, 01:30:33 pm
Bonjour ,
maquette pour une implémentation de signaux dcc exacts avec cutout parfaitement synchronisé
à vos analyseurs logique !
à votre disposition pour toute question
EDIT : suite à la remarque de msport :
- le DIR doit être sur la broche 13 : pièce jointe rectifiée en ce sens
- le PWM doit être en HIGH sur 12 : pour des raisons de sécurité , je ne l'ai pas ajouté , si vous le souhaitez ajoutez-le dans le setup :
pinMode(12, OUTPUT);
digitalWrite(12, HIGH);
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le octobre 07, 2023, 07:47:26 pm
Bonjour,

probablement intéressant mais pour fonctionner avec LaBox, il faudrait analyser les commandes DCC++ (dont serial) pour créer les paquets.
Et gérer les boutons et l'afficheur 0.96"
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le octobre 08, 2023, 11:32:24 am
Bonjour msport,
ma proposition se borne à envoyer (en bonnes et dues formes) les packets que lui confie le scheduler
(il a bien fallu que je fasse un scheduler embryonnaire pour la démo , mais ce n'est pas (encore) le sujet)
je dois pouvoir adapter la méthode de Gregg E. Berman à la mienne , avec éventuellement votre aide , si vous voulez bien , vu mon "niveau" en C++
après , on verra bien , si ça n’intéresse personne , je le garderai pour moi
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le octobre 08, 2023, 12:20:45 pm
... mais la démo n'allume pas le DCC sur LaBox version Railcom à LMD18200 (DIR 13, PWM 12, BRAKE 14)
PWM n'est pas affecté dans  la démo.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le octobre 08, 2023, 02:44:45 pm
attention , ce n'est pas une démo mais une maquette destinée à montrer la bonne forme des signaux à l'analyseur logique ou à l'oscillo
elle envoie en alternance un iddle et un packet bidon , qui m'ont permis à débuger , alors
surtout n'allez pas mettre là dessus vos "brass platinium paragon golden ulimate silver" !
j'ai mis le DIR sur 12 et le BRAKE sur 14 c'est pas juste ? EDIT : ben non c'est pas juste , je rectifie !
quand  au PWM , il ne fait pas dans ce cas partie de la maquette , il faudrait l'activer manuellement pour avoir des signaux en sortie du lmd , mais ça n'a pas de sens
merci de l’intérêt porté
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le octobre 08, 2023, 06:36:23 pm
    Dans la DEMO :
   DIR = IO13
    /// PWM = IO12
    BRAKE = IO14 (pour plus tard avec le version Railcom) /// maintenant

ce qui est ok, mais PWM doit être à high (sauf détection de C/C)

BRAKE doit être à low (sauf quand pilotée par le railcom)

Mais une fois PWM mis à high, la démo ne sort pas un signal DCC sur DIR = IO13 mais seulement un signal high

compilé avec IDE 1.8.19 / W10
pcb LaBox 3.0 30s3D pour LMD18200
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le octobre 08, 2023, 08:15:36 pm
oui , mais je m'a gouré dans le setup , désolé , si tu veux bien , 2ème onglet :
tu remplaces :
const int dcc_1_pin = 13;  // choix de la broche dcc out ...
au lieu de :
const int dcc_1_pin = 12;  // choix de la broche dcc out ...

puis tu intercales :
pinMode(12, OUTPUT); // pour l'entrée PWM du LMD
digitalWrite(12, HIGH);
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le octobre 08, 2023, 08:56:25 pm
à priori on a du DCC en sortie, pcb  LaBox 3.0 30s3D ... à suivre.
A noter que pour LaBox,  c'est la cohabitation avec le serial, l'analogRead et la gestion de l'HMI qui gâchait tout ...
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le octobre 08, 2023, 09:18:02 pm
Ci-joint résultat au sniffer.
Mais quid avec l'environnement nécessaire pour faire une centrale.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le octobre 08, 2023, 09:27:39 pm
En référence, les timings de la centrale Railcom de Christophe et Marcel (même pcb)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: trimarco232 le octobre 08, 2023, 10:15:55 pm
à mon analyseur logique , échantillonné à 24MHz , les bits font pile poil 58+58 et 100+100us , tandis que le cutout fait 30+470us , à la précision du quartz de l'esp32 près , normal je l'ai programmé pour ça
pour faire une comparaison objective avec une vraie centrale en service , il faudrait que que mon moteur soit incorporé à une telle centrale ; la charge sur l'esp32 de ma maquette est légère , du fait qu'il n'y a qu'un seul canal (je l'ai essayé avec 2 canaux, tout est nickel , mais je te rejoins , il faudrait en effet tout vérifier sur une période assez longue avec un programme suffisamment chargé , je pense notamment à la wifi)
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le octobre 19, 2023, 06:00:09 pm
Bonjour à tous

Nouvelle version 2.3.0 de Labox .

On passe à CommandStation-EX V5.0 sortie pendant l'été. Cette version apporte un support natif pour l'ESP32. Donc plus besoin d'aller chercher une branche exotique pour avoir des sources à jour, et la maintenance générale de l'appli nous bénéficiera aussi. A noter que j'ai dû corriger leurs sources suite à une régression qui ne permettait plus à la lecture de CV de fonctionner. Je vais tenter de leur suggérer la correction via Github.
Pour Michel, il semble qu'un define WIFI_FORCE_AP a fait son apparition dans config.h et permettra sans doute de corriger les problème d'accès AP.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le octobre 23, 2023, 05:31:08 pm
Bonjour à tous,

effectivement en laissant le SSID à blanc, on passe cette fois en AP mode. Même sans positionner define WIFI_FORCE_AP.

Dans ce cas, le password n'est pas pris en compte, c'est un password généré automatiquement qui est affiché après un SSID généré lui aussi automatiquement.
(et non DCCEX_*)
Wifi AP SSID Labox_50d37c PASS PASS_50d37c

C’est OK en AP avec Engine Driver, il faut entrer le pw donné sur l’affichage (à la fin du SSID fourni)
La détection d’adresse fonctionne bien et le pilotage par les manettes est ok en parallèle avec le smartphone.

la mesure de courant est sous-estimée et le seuil de détection de c/c est environ 1,5A avec un ratio de 1V/A
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le octobre 23, 2023, 10:07:18 pm
Excellents résultats!

De mon côté j’ai utilisé WIFI_FORCE_AP true, SDID=“LaBox230”, PW=“”.

C’est plus simple et efficace.

Avec WIFI_FORCE_AP false, tu peux configurer un accès wifi via ta box internet et, quand tu n’y a plus accès, ça passe en mode AP automatiquement: je n’ai pas essayé mais retour à la maison dans 2 jours.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le octobre 24, 2023, 08:41:17 pm
LProg est lui aussi passé à CommandStation-EX V5 .
En réalité, un fork a été créé à partir de la branche Labox, ce qui signifie que LProg est une modification de Labox, lui même une modification de CommandStation-EX ! La branche CommandStation-EX-LProg a été créée sur Github pour l'occasion. Les deux programmes ont été mis au même niveau par rapport à CommandStation-EX V5.0.4, et peuvent maintenant être compilés automatiquement à chaque fois que quelqu'un (souvent moi ...) y poussera une modification. Ce sont les actions automatiques de Github qui font ce travail.

Du côté de LProg, j'ai amélioré l'ergonomie pour faciliter son utilisation avec l'écran et ses boutons. Il est passé du coup en 2.3.0 lui aussi.

Plusieurs pistes sont maintenant à explorer :
- amélioration de la partie Z21 pour mieux gérer les accessoires, EX-RAIL et d'autres petites choses sur lesquelles j'ai fait l'impasse, occupé que j'étais à faire marcher le pilotage de locos... Ce sont ces manques qui empêchent l'adoption de notre code Z21 par l'équipe de CommandStation-EX .
- D'autre part, j'aimerai voir si on peut faire fonctionner la programmation POM (Program Over Main), c'est à dire la programmation sur la voie principale qui demande à spécifier l'adresse de la loco que l'on veut modifier. Dans ce mode, pas de programmation de la CV1 possible, et pas de ACK qui seraient de toutes façons perturbés par la présence des autres locos sur le réseau.
- Enfin, les parties Railcom et Lenz ABC sont des possibilités d'évolution non négligeables vu ce que l'on a vu dans d'autres fils.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le octobre 24, 2023, 08:52:06 pm
Je pense que LaBox va devenir une réalisation de référence pour DCC-EX.
De quoi les inciter à ajouter le Railcom !

Pour compléter, je vais développer une passerelle wifi-Can avec une manette de commande de trains en html, sur la base de la carte de Christophe. Pour tester le Can !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le octobre 25, 2023, 10:36:51 pm
Est-ce que la version 5 intégre Railcom maintenant ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Thierry le octobre 26, 2023, 08:03:06 am
Non toujours pas. Il y a une branche de la version 4 qui le fait, mais pas pour un ESP32 .
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le octobre 31, 2023, 08:59:18 pm
Bonsoir,

Une question qui s'adresse peut-être plus à msport : Où sont les connecteurs CAN sur le PCB de la box ? Est-ce les deux prises RJ45 ? Si oui, sur quel connecteur sont le CAN L et le CAN H ?

Merci par avance pour la réponse.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le octobre 31, 2023, 09:35:56 pm
Bonsoir Christophe,
effectivement les deux RJ12 sont les connecteurs CAN dont le rôle est identique.
Chacun comporte le CAN L et le CAN H
Le standard Locoduino a été lancé par les satellites : le CAN H se situe sur les deux broches centrales (3 et 4) et le CAN L est sur les deux extérieures (2 et 5)
Un jumper met en service la 120 ohm terminale.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 03, 2023, 10:10:50 am
Il est là dans la réponse 339
 https://forum.locoduino.org/index.php?topic=922.msg12063#msg12063 (https://forum.locoduino.org/index.php?topic=922.msg12063#msg12063)

Mais je regarde la dernière version qui apporte des améliorations... sous réserve de coquille que nous n'aurions pas vue...
La voici, la version 0.4 du 14-06-2021 qui intègre l'ampli de ligne Can MCP2564 à la place su support pour la petite carte qui n'existe plus.

et la BOM
voir les pièces jointes

Bonjour à tous,

Je me suis lancé dans l'aventure avec la v0.4 de LaBox.
Pourriez-vous me dire à quoi correspond le composant IC1? Car malheureusement les liens sont hs.

En vous remerciant par avance,
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 03, 2023, 11:53:28 am
Bonjour,
IC1 est un pont L6203.
Par exemple :
https://fr.aliexpress.com/item/33003883508.html
A noter qu'un article est en cours de rédaction.
Avec la possibilité d'un circuit imprimé déjà équipé de la plupart des petits composants (CMS soudés)
Le soft restera compatible.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 03, 2023, 01:01:50 pm
Bonjour,
IC1 est un pont L6203.
Par exemple :
https://fr.aliexpress.com/item/33003883508.html
A noter qu'un article est en cours de rédaction.
Avec la possibilité d'un circuit imprimé déjà équipé de la plupart des petits composants (CMS soudés)
Le soft restera compatible.

Merci! Cela tombe bien il m'en restait du projet précédent.
J'ai déja reçu les pcb, donc je vais aller jusqu'au bout.
Une dernière question, il me manque que le composant de la partie Can. A quoi correspond le MCP2564?
Il a un format différent de la version 3?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 03, 2023, 03:03:33 pm
Cette version du circuit utilise un module d'interface pour le CAN : le CJMCU-230 (attention certains ont une sérigraphie inversée)

https://fr.aliexpress.com/item/32635274058.html

Les nouvelles versions du circuit utilisent un composant CMS dédié, le MCP2562 soudé par JLCPCB. Ou par soi-même si on acquiert le circuit nu.

le MCP2562 assure la même fonction que le module qui comporte un SN65HVD230.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 03, 2023, 07:14:31 pm
Cette version du circuit utilise un module d'interface pour le CAN : le CJMCU-230 (attention certains ont une sérigraphie inversée)

https://fr.aliexpress.com/item/32635274058.html

Les nouvelles versions du circuit utilisent un composant CMS dédié, le MCP2562 soudé par JLCPCB. Ou par soi-même si on acquiert le circuit nu.

le MCP2562 assure la même fonction que le module qui comporte un SN65HVD230.

Merci pour ces précieuses informations! Tout est plus clair.
(J'avais acheté les deux versions dans le doute.)
Finalement, il ne me manque que le LM358P que je n'avais pas trouvé dans le fichier BOM.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 03, 2023, 09:31:22 pm
En fait, dans la BOM, il y a pour IC2, un MCP6002 qui est fonctionnellement équivalent au LM358.
On utilise le LM358 sous 3,3V, ce qui ne fait pas partie de ses spécifications mais on l'a utilisé pour sa plus grande disponibilité.
Il semble que la contrepartie est que pour certains exemplaires, on rencontre une limitation de la plage de réglage de la détection du courant de court-circuit.
Mais votre remarque nous amène à reconsidérer l'utilisation de ce composant dans la version assemblée chez JLCPCB

Dans votre cas, regardez :
https://www.ebay.fr/itm/232213779460
ou
https://www.ebay.fr/itm/224902666493
ou
https://fr.aliexpress.com/item/33022821492.html
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 04, 2023, 01:19:30 pm

Merci pour cette nouvelle précision, je vais utiliser le MCP6002 comme vous le préconisez.
Je me permet de vous poser une dernière question.

Concernant les condensateurs 100nf, je me suis trompé, j'ai commandé des céramiques.
Sont-ils utilisables ou dois-je absolument recommander des polyester?

https://www.ebay.fr/itm/324469940050

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 04, 2023, 03:13:32 pm
Les condensateurs céramique sont même potentiellement mieux adaptés, mais les polyesters ne posent aucun problème.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 06, 2023, 10:34:00 am

Parfait! Merci pour votre retour.

J'avance doucement dans le projet et je me suis rendu compte que les connecteur RJ11 femelles ne s'adaptent pas dans le PCB.
J'ai commandé des RJ11 4P4C comme indiqué dans le fichier BOM, peut-être ai-je fais une erreur?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 06, 2023, 03:30:50 pm
Bonjour,

la BOM n'est pas assez précise. Le lien est périmé ou erroné.

Le RJ11 comporte 6 positions et est décrit comme 6P4C : 6 positions et 4 conducteurs.

Il est compatible au niveau de l'empreinte avec le RJ12 6P6C. On n'utilise que les conducteurs centraux (ceux du RJ11) pour le CAN. Il y a eu un échange récent sur le question dans le forum.

Par ailleurs l'image du circuit imprimé montre bien que RJ11 et et RJ12 sont possibles (6 positions).
4P4C correspond aux RJ9, RJ10 et RJ22 pour les cordons téléphoniques. Plus étroit non compatible.

Attention, toutes les prises socket RJ11/RJ12 n'ont pas les ergots au même endroit :
Celles-ci vont bien sur le circuit imprimé :
https://fr.aliexpress.com/item/33006103304.html.
Celles que je vois sur eBay sont plus courtes et ne conviennent pas.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 07, 2023, 02:22:16 pm
Bonjour,

Merci beaucoup, je commande ce modèle.
Je me suis appuyé sur la procédure version 0.3 pour l'implémentation mais j'ai remarqué que la version 0.4 possède quelques emplacements pour des composants supplémentaires (entouré en jaune sur la photo ci-jointe).

Pourriez-vous m'aiguiller sur les composants à implémenter?
En vous remerciant par avance,
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 07, 2023, 03:11:18 pm
Ces composants correspondent à des fonctions non retenues jusqu'à présent.
Sauf peut-être la 100n F de filtrage.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 09, 2023, 06:25:24 pm
Bonjour,

Merci encore pour toutes ces informations.

Je souhaite installer les interrupteurs, dans quel sens dois-je les installer?
Ci joint la photo de l'interrupteur, en rouge la continuité en position haute et en vert lorsque je le maintiens en position basse.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 09, 2023, 06:57:03 pm
Bonsoir,

si votre circuit est bien LA BOX 0.3 vos boutons doivent fermer momentanément les deux points en bas à droite de l’empreinte des boutons.
Ce ne sont pas des interrupteurs mais des poussoirs.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 12, 2023, 01:08:37 pm
Bonjour,

Merci pour votre aide, j'ai pu intégrer les poussoirs, tout fonctionne bien de ce coté la.

En attendant de recevoir les RJ12, j'ai voulu faire quelques tests.
Tout fonctionne bien, hormis que je n'ai pas d'alimentation sur la voie.
Lorsque je connecte une application (z21 ou withrottle), la connexion est initialisée et l'icone "check" clignote continuellement.

Est-ce un problème d'origine matériel ou logiciel?
Merci par avance,
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 12, 2023, 03:07:39 pm
Comment avez-vous configuré votre iPhone (wifi ET paramètres Z21)?
LaBox est-elle en mode STA ou PA?
Quelle version du soft LaBox ?

Il faut tout dire+ copies d’écran, photos…

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 12, 2023, 03:36:25 pm

Pour la configuration wifi, je l'ai paramétré sur mon réseau wifi domestique:
-J'ai renseigné le ssid et le mot de passe

#ifdef USE_WIFI_EXTERNSSID
const char* ssid = "Livebox-****";
const char* password = "****************";

-Configuré l'adressage IP

IPAddress ip      (192,   168,  1,  44);
IPAddress gateway (192,   168,  1,  1);
IPAddress subnet  (255,   255,  255,  0);
IPAddress dns     (192,   168,  1,  1);

Commenté USE_WIFI_LOCALSSID et décommenté USE_WIFI_EXTERNSSI dans le fichier DCCpp.h

-J'ai renseigné l'ip 192.168.1.44 dans l'application Z21, la Box me semble reconnue (cf captures ci-jointes).

- Pour la version du soft LaBox, j'ai récupéré la branche master sur github (j'ai suivi la procédure indiquée pour la version 0.3)

Concernant, le mode LaBox (STA ou PA), je ne saurais vous répondre, je ne sais pas de quoi il s'agit.

Merci pour votre aide,
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 12, 2023, 09:38:07 pm
Bonsoir,

pouvez vous nous poster votre config.h
et la capture du (re)démarrage de l'ESP32 après un reset sur le serial.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 12, 2023, 09:46:30 pm

Concernant, le mode LaBox (STA ou PA), je ne saurais vous répondre, je ne sais pas de quoi il s'agit.

Merci pour votre aide,

Pour info,
LaBox est bien en mode station (STA) puisqu’elle se connecté à votre Livebox et l’appli Z21 se connecte à LaBox à l’adresse indiquée sur l’Oled 192.168.1.44.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 12, 2023, 09:58:15 pm
... mais avez vous tenté d'envoyer <1> via le serial monitor à 115200 bauds ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 12, 2023, 10:22:58 pm
Et les RJ12 ne servent que pour le CAN, ils n'interviennent pas autrement dans le fonctionnement de LaBox.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 13, 2023, 08:49:09 am
En attendant vos réponses, je remarque que :
- votre alim de 15v est branchée et la mesure de tension fonctionne et s’affiche sur l’oued
- l’indication <DCC ON> semble dire que la sortie DCC devrait être alimentée!

Mais les leds au pied du connecteur vert de sortie DCC ne sont pas allumées alors que le 15V est présent.

Comme le suggère Msport, dans le moniteur de l’IDE, tapez <1> pour mettre en route la sortie DCC et <0> pour l’arrêter et regardez les leds de sortie DCC : les 2 doivent s’allumer (1) et s’éteindre (0).

Sinon révisez les soudures, relevez les tensions aux bornes du L6203, etc et expliquez bien vos symptômes.
Ça va marcher !
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 13, 2023, 04:49:38 pm
Bonsoir,

pouvez vous nous poster votre config.h
et la capture du (re)démarrage de l'ESP32 après un reset sur le serial.

Bonjour,

Ci-joint le fichier config.h et ci-dessous la capture lors du redémarrage de l'ESP32

mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13964
load:0x40080400,len:3600
entry 0x400805f0
LaBox 0.9.3
...Server IP address: 192.168.1.44 (Livebox-DBAC) connected ! connectWifi achieved.
Ino executing on core 1
Throttles command receivers executing on core 0
begin achieved
Signal started for Main track on pin 33
Main track DCC ESP32 started.
beginMain achivied with pin 33
*** LaBox LIBRARY : 0.9.3
VERSION DCC++     : 2.0.0
COMPILED          : Nov 12 2023 11:47:31
   ENABLE(PWM): 32
   CURRENT: 36
Throttles ------------------
0 : Serial
1 : JMRI
2 : ThrottleWifi: Z21 - 1  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  ip:0.0.0.0
3 : ThrottleWifi: Z21 - 2  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  ip:0.0.0.0
4 : ThrottleWifi: Z21 - 3  WifiPort: 21105  WifiProtocol: UDP (Z21 converter : )  ip:0.0.0.0
5 : ThrottleWifi: WiThrottle - 1  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 ip:0.0.0.0
6 : ThrottleWifi: WiThrottle - 2  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 ip:0.0.0.0
7 : ThrottleWifi: WiThrottle - 3  WifiPort: 44444  WifiProtocol: TCP (WiThrottle converter)  start:60 end:62 ip:0.0.0.0
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 13, 2023, 04:53:06 pm
... mais avez vous tenté d'envoyer <1> via le serial monitor à 115200 bauds ?

Je viens de tester, j'ai ce retour sur la console.

0 From Throttle : 1
0 Message From Throttle :
Throttle 0 <1>
<1> parse command
DCCpp PowerOn Main
<p1>

Du coté de la coté la box, les leds ne s'allument toujours pas et j'ai le symoble "check" qui clignote sur l'oled.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 13, 2023, 08:50:17 pm
Bonsoir,
je pense que vous êtes tombé dans le piège suivant :
il faut un pont ou un jumper entre les pointes des deux flèches du schéma joint.

un pont de soudure au dos convient.

A suivre pour le Wifi.

PS : ce n'est pas le config.h que vous avez utilisé que vous nous avez envoyé.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 13, 2023, 08:57:44 pm
Notez que l’icône check indique qu'effectivement une throttle est connectée.
L'affichage change quand LaBox reçoit une commande pour une locomotive.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 14, 2023, 10:32:34 am
Bonjour,
deux photos :
celle du verso montre un petit pont correspondant à une piste oubliée pour le CAN.
(sur cette version 0.42)
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 14, 2023, 06:48:10 pm
Bonsoir,
je pense que vous êtes tombé dans le piège suivant :
il faut un pont ou un jumper entre les pointes des deux flèches du schéma joint.

un pont de soudure au dos convient.

A suivre pour le Wifi.

PS : ce n'est pas le config.h que vous avez utilisé que vous nous avez envoyé.
Bonsoir,

Merci! J'ai mis en place le jumper et en effet j'ai bien les deux diodes qui s'allument et j'ai mes 15v au niveau de la voie.
Reste à tester avec une locomotive.
Pour le config.h j'ai donné celui qui était dans le dossier labox, je n'en ai pas trouvé d'autre.

Cordialement,
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 14, 2023, 07:28:40 pm
Bonsoir,

Très heureux que vous ayez pu avancer.

Nota : le début du Config.h que vous avez envoyé

/**********************************************************************

Config.h
COPYRIGHT (c) 2013-2016 Gregg E. Berman
Adapted for DcDcc by Thierry PARIS

Part of DCC++ BASE STATION for the Arduino

le début du Config.h que vous avez heureusement modifié et utilisé

/*
 *  © 2022 Paul M. Antoine
 *  © 2021 Neil McKechnie
 *  © 2020-2023 Harald Barth
 *  © 2020-2021 Fred Decker
 *  © 2020-2021 Chris Harlow
 *  © 2023 Nathan Kellenicki
 * 
 *  This file is part of CommandStation-EX
 *
 *  This is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, either version 3 of the License, or
 *  (at your option) any later version.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 15, 2023, 07:08:49 am
Bonjour,

En parcourant les différents échanges de ce sujet, je viens de me rends compte que je n'ai pas renseigné de fichier config.h

Je dois partir sur ce modèle?

https://github.com/DCC-EX/CommandStation-EX/blob/master/config.example.h

Dans quel dossier le déposer?

Merci par avance,
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 15, 2023, 08:56:53 am
ne pas confondre DCCpp et DCC-EX  :-\
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 15, 2023, 09:16:03 am
ne pas confondre DCCpp et DCC-EX  :-\

Oups , désolé  :-[

Donc pas de config.h et je m'appuie sur le principe de cet article pour la configuration?

https://www.locoduino.org/spip.php?article228
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 15, 2023, 10:22:54 am
Bonjour,

ce n'est pas le bon article puisque qu'à ce jour, l'article LaBox n'est pas encore publié.

vous avez certainement récupéré CommandStation-EX-LaBox dans le Github
https://github.com/Locoduino/CommandStation-EX-LaBox/tree/LaBox

vous avez certainement modifié le configLaBox.h avec le SSID et pw de votre box et renommé en config.h puisque vous vous êtes connecté.
De ce coté plus de problème.

Quid du test d'une locomotive ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 15, 2023, 07:30:56 pm
Bonjour,

Compliqué, pas de réaction de la locomotive car la connexion entre labox et l'application z21 n'est pas persistante.
J'ai beau cliquer sur "Reconnect to z21", pas de reconnexion.
Pour pouvoir tenter une reconnexion, je suis obligé de redémarrer labox.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 15, 2023, 09:04:03 pm
Bonsoir,

pouvez vous nous poster le config.h que vous avez modifié  ? Masquez votre SSID et password.
Il est dans le répertoire CommandStation-EX-LaBox

Et faire un essai avec JMRI en connexion USB.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 15, 2023, 11:25:05 pm
Pouce !!!

Il faudrait commencer, enfin, par lever le doute sur le logiciel que vous avez chargé dans LaBox :
Soit LaBox récupéré ici
 https://github.com/Locoduino/LaBox (https://github.com/Locoduino/LaBox)

Soit Commandstation-EX-Labox recuperé là :
 https://github.com/Locoduino/CommandStation-EX-LaBox (https://github.com/Locoduino/CommandStation-EX-LaBox)



Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 16, 2023, 10:14:38 am
Bonjour,

J'ai chargé celui-ci: https://github.com/Locoduino/LaBox

De le même temps, je vois joins les deux fichiers que j'ai modifié.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 16, 2023, 10:40:49 am
Je vous propose de changer votre fusil d'épaule  :D

Installer le logiciel CommandStation-EX-LaBox de cette façon : Télécharger la version (actuelle 2.3.0).

https://github.com/Locoduino/CommandStation-EX-LaBox (https://github.com/Locoduino/CommandStation-EX-LaBox)

Renommez le dossier "CommandStation-EX-LaBox-LaBox" en "CommandStation-EX-LaBox ». Il contient le programme "CommandStation-EX-LaBox.ino".

Dans ce dossier, renommez le fichier "config.LaBox.h" en "config.h".

Ouvrez le programme "CommandStation-EX-Labox.ino" avec l’IDE Arduino. Cela prend un peu de temps car l’IDE charge et ouvre environ 120 éléments !

Vérifiez le contenu de votre fichier "config.h" avec l’IDE Arduino : il doit contenir la définition de la carte LaBox, lignes 61 à 66 :
#define LABOX_MOTOR_SHIELD   new MotorDriver(32, 33, UNUSED_PIN, UNUSED_PIN, 36, 0.80, 2500, UNUSED_PIN)
#define LABOX_MAIN_MOTOR_SHIELD F("LABOX"), LABOX_MOTOR_SHIELD
#define MOTOR_SHIELD_TYPE LABOX_MAIN_MOTOR_SHIELD

Cette configuration mets LaBox en mode Point d’Accès, avec le nom de réseau "LaBox230"
Compiler et téléverser le logiciel dans l’ESP32 avec l’IDE Arduino.
Ouvrir le moniteur série de l’IDE Arduino à la vitesse de 115200 b/s.
Au démarrage, l’OLED doit afficher l’interface utilisateur qui donne l’adresse IP de LaBox qui doit être configurée dans l’application de pilotage.
Au préalable configurez l'application (Z21 ?) sur l'adresse IP de LaBox.
Testez et rendez nous compte de vos tests  ;D

Si vous voulez utiliser LaBox en station Wifi connectée à votre réseau internet, modifiez comme suit :
Ligne 118 indiquez le SSID de votre box internet à la place de "LaBox230" : #define WIFI_SSID "Your network SSID"
Ligne 124 indiquer le mot de passe de votre box : #define WIFI_PASSWORD "Your network passwd"
Ligne 138 changez true en false : #define WIFI_FORCE_AP false
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le novembre 18, 2023, 07:42:16 am
Bonjour à tous,

Voilà un beau projet qui est sur le point d’aboutir ! Bravo aux auteurs.

Pour ma part, je me suis déjà approprié la partie hard depuis plusieurs mois (PCB, carte moteur LMD18200, communication CAN…) et cela fonctionne parfaitement.

Le logiciel est cependant un développement propre puisque j’ai besoin sur mon réseau de générer un cutout pour Railcom, ce que laBox ne fait pas encore.

J’ai trois questions pour le moment :

1° - Avez-vous déterminé un protocole de messagerie pour la communication en CAN des commandes de locomotives ?
-   Quel identifiant de message (court ?, long ?), comment est structuré l’identifiant ?
-   Je suppose que vous avez au moins quatre trames de data, deux  pour l’adresse de la locomotive, une pour la direction et une pour la vitesse. Dans quel ordre ? data[0] = ?, data[1] = ? …
2° - Je suppose que le L6203 et le LMD18200 n’ont pas les mêmes brochages et que donc il doit y avoir une version de PCB pour le premier et une autre pour le second, non ?
3° - J’aurais une préférence pour le L6203, mais il me semble qu’il ne peut pas recevoir la commande break nécessaire pour générer le cutout de Railcom. Confirmez-vous ?

Aux nombreuses possibilités de pilotage de la box, j’en ai ajouté une personnelle au travers de mon application propre que j’ai déjà présentée et qui est stockée comme data sur la mémoire flash de l’ESP32 sous forme d’application web. Là aussi ça fonctionne très bien et c’est très simple à mettre en œuvre.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 18, 2023, 10:11:45 am
Bonjour Christophe,

merci pour ces encouragements et pour ce retour positif,
1. Pour le CAN, je suis suiveur, tout en validant le support hardware sur les circuits imprimés successifs de LaBox.
2. Il y a effectivement deux versions en cours du circuit imprimé de LaBox, une pour le L6203, une pour le LMD18200. Les deux sont pré équipées.
3. Le L6203 n'a pas de broche BRAKE et je pense qu'il ne peut pas générer de Cutout.

Et merci pour le partage de ton application de pilotage.

Actuellement, le logiciel de Thierry fonctionne sur la deuxième version du circuit imprimé (celle à LMD18200), elle attend le support du Railcom par DCC-EX.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 18, 2023, 12:30:27 pm
D'après les datasheet respectives, il me semble que le brake est possible sur le L6203.

Il existe bien un état SINK1 - SINK2
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le novembre 18, 2023, 02:43:48 pm

Et merci pour le partage de ton application de pilotage.


Ah oups, Michel !!! J'ai oublié le lien : https://github.com/BOBILLEChristophe/DCC_controller_ESP32
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 18, 2023, 04:57:06 pm
D'après les datasheet respectives, il me semble que le brake est possible sur le L6203.
Il existe bien un état SINK1 - SINK2

Oui, pour le BRAKE c'est Sink - Sink, c'est bien ce qui ressort de la spécification du LMD18200. Les deux transistors du high end sont allumés.

On a  le même résultat sur le L6203, avec EN = high,  IN1 = IN2 = low, donc on devrait avoir le retour du courant en provenance du décodeur.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: laurentr le novembre 19, 2023, 02:44:03 am
Bonjour

Le L6203 gère très bien le "cutout".

Le BOOSTER CDE de PACO CANADA (ES) permet de l'exploiter sur un BOOSTER 3A type CDE.(avec ou sans RAILCOM selon la programmation des valeurs en EEPROM)

en voici la notice
https://usuaris.tinet.cat/fmco/download/BoosteR-CDE_manual.pdf (https://usuaris.tinet.cat/fmco/download/BoosteR-CDE_manual.pdf)

le code source est dispo ici:
https://usuaris.tinet.cat/fmco/download/BoosteR-CDE.zip (https://usuaris.tinet.cat/fmco/download/BoosteR-CDE.zip)
A titre d info:

Le site de PACO est une vraie mine d or même si ce n'est pas de l Arduino mais du PIC.
Les montages sont éprouvés et restent fonctionnels malgré leur "âge" relatif.

On peut d ailleurs "moderniser" sur la base des éléments proposés ( ex suppression de la régulation LM350 par une alim à découpage avec un Vout de 16 à 18V DC et conserver le reste du montage.

Pour les curieux donc:

https://usuaris.tinet.cat/fmco/main_en.html (https://usuaris.tinet.cat/fmco/main_en.html)


Laurent


Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 19, 2023, 12:17:29 pm
Merci Laurent,

En effet le L6203 est utilisé dans un montage de type Booster, donc recopie exactement les signaux DCC en entrée sur ses entrées IN1 et IN2 via 2 optocoupleurs.
Donc c'est bien la combinaison des signaux IN1 et IN2 à LOW qui provoque le Cut-Out.

Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 20, 2023, 09:18:46 pm
Bonsoir à tous,

j'ai testé tous les états du L6203 en réutilisant une carte faite par Michel pour remplacer les cartes à base de LMD18200.

J'ai un peu galéré pour que ça marche après avoir douté de mes L6203 : il a fallu installer la plupart des composants prévus pour cette carte à l'exception du transistor inverseur et de la mesure de courant. J'avoue n'avoir pas tout compris pourquoi ça ne marchait pas sans ces composants. Moi bon, le résultat est là.

Les entrées G:Gnd, U=IN2, P=ENABLE, D=IN1 ont été reliées à un Nano pour faire varier toutes les combinaisons de ces entrées (un patch relie l'entrée U au IN2 directement)

Dans les 2 cas sourceX - sinkY, l'une des 2 leds s'allume
Dans le cas sink1 - sink2, la résistance mesurée aux bornes de sortie est très faible (de l'ordre d'un poil d'ohm), ce qui correspond bien à l'état court-circuit.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: bobyAndCo le novembre 20, 2023, 09:34:07 pm
Bien Dominique, ça avance tout ça !!!

Merci pour la contribution
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le novembre 23, 2023, 07:39:31 pm
Je vous propose de changer votre fusil d'épaule  :D

Installer le logiciel CommandStation-EX-LaBox de cette façon : Télécharger la version (actuelle 2.3.0).

https://github.com/Locoduino/CommandStation-EX-LaBox (https://github.com/Locoduino/CommandStation-EX-LaBox)

....

Bonsoir,

Un premier retour suite au passage vers CommandStation-EX-LaBox, pour laquelle la compilation et l'installation se sont déroulé sans encombres.

- Mes problématiques avec l'application Z21 restent les mêmes, impossible de faire avancer la loco et perte de connexion.
- J'ai donc testé avec l'application withrottle, et tout semble fonctionner correctement, la loco avance, l'allumage des feux est fonctionnel.

Je vais continuer mes recherches pour trouver d’où vient le problème avec l'appli Z21..

Cordialement,
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 23, 2023, 08:22:55 pm
Bonsoir,

on revient au config.h

vous avez choisi le mode AP (Point d’Accès) et non le mode station ?

#define WIFI_SSID "LaBox230"
#define WIFI_PASSWORD "12345678"

Vous connectez votre smartphone sur ce réseau avant de démarrer Z21 ?

Vous pouvez regarder ce que dit le serial monitor après un reset de l'ESP32 ?
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 23, 2023, 08:28:27 pm
Mettez le password à “”
Il devrait y être déjà.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 23, 2023, 08:38:36 pm
Je lis dans config.h :
The AP mode password must be at least 8 characters long.
Le mot de passe du mode AP doit comporter au moins 8 caractères.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le novembre 23, 2023, 09:21:24 pm
Moi je ne mets rien pour ne pas me le demander à la connexion : “”

Les 8 cars mini, c’est quand on en met un.

Mon app Z21 sur iPhone marche bien.

Et je viens de lire avec succès les adresses de 6 locos dont 2 n’étaient pas lisibles avec LaBox/DCCpp.
Sans connexion de smartphone, seulement avec les boutons et le menu HMI.
Donc au départ le DCC n’est pas appliqué à la voie, mais durant la lecture le DCC s’active puis s’arrête à la fin de la lecture.

C’est tres pratique  :D :D :D
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le novembre 23, 2023, 09:41:12 pm
Le temps de vérifier : c'est confirmé : pas de mot de passe.
Titre: Re : Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: drmanu le décembre 13, 2023, 05:34:30 pm
Bonsoir,

on revient au config.h

vous avez choisi le mode AP (Point d’Accès) et non le mode station ?

#define WIFI_SSID "LaBox230"
#define WIFI_PASSWORD "12345678"

Vous connectez votre smartphone sur ce réseau avant de démarrer Z21 ?

Vous pouvez regarder ce que dit le serial monitor après un reset de l'ESP32 ?

Bonjour à tous,

Un petit retour de mes tests avec l'application Z21, un peu tardif par manque de temps.

J'ai bien configuré labox en mode AP, malheureusement l'application Z21 (du 21 décembre 2022) proposée sur le play store ne fonctionne toujours pas.

En visualisant la dernière vidéo de Dominique, cela m'a interpellé car l'interface n'est pas du tout la même que mon application.

Après quelques recherches, j'ai retrouvé une ancienne version nommée "Z21 Mobile" (du 2 aout 2017), qui elle fonctionne parfaitement.

Cordialement,
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: Dominique le décembre 13, 2023, 06:05:40 pm
Bravo !
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le janvier 20, 2024, 06:38:30 pm
@ Juan,

après tests de la version 0.4, on a constaté que le circuit externe gérant le reset de l'ESP32 est inutile et qu'un simple condensateur de 100 à 220 nF sur EN convenait parfaitement.
Tous les composants correspondants peuvent être supprimés comme sur le schéma joint.
Titre: Re : projet centrale "LaBox" wifi DCC++ Can
Posté par: msport le janvier 29, 2024, 04:24:46 pm
Bonjour,

n'utilisez ce fil que pour des questions générales sur le projet ou des questions spécifiques aux anciennes versions décrites depuis le début.

Pour l'article LaBox : Une Centrale DCC polyvalente et abordable publiée sur le site éditorial le 21 novembre 2023 https://www.locoduino.org/spip.php?article346 :
utilisez le fil :
https://forum.locoduino.org/index.php?topic=1618.msg18096#msg18096