projet centrale "LaBox" wifi DCC++ Can

[Thierry]

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.

[msport]

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.

[Thierry]

Oups, version 0.6.3 poussée !

[msport]

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.

[Dominique]

Des nouvelles du projet :

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

• L'erreur de distance entre les 2 rangées de pins de l'ESP32 est corrigée.
• Une belle sérigraphie des broches de l'ESP32
• l'écran Oled ne sera monté qu'à plat (parallèle aux circuit, au dessus du régulateur 5V
• on va tacher de trouver une belle boite pour ce bijou 

A suivre, le schéma, la liste des ingrédients et d'autres améliorations...

[Dominique]

Le schéma de la version 03 :




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

• Le shunt pour la mesure de courant est constitué de 2 résistances CMS de 0,5Ω chacune.
• Le gain de l'amplificateur de mesure du courant est de 4.
• 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.
• Un ajustable est ajouté pour régler l'affichage à peu près à 0V à vide.
• La mesure de courant est affectée à la broche SVP (IO36) de l'ESP32.
• La mesure de tension (du bloc d'alimentation) est affectée à la broche IO34 de l'ESP32. Cette mesure de tension n'est utile qu'au démarrage de la centrale. Elle est utile pour prévenir les dégats éventuels en cas de tension trop élevée.

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.

[Dominique]

La liste du matériel (fichier .xlsx en PJ):

[Dominique]

quelques écrans en fonctionnement :



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.

[laurentr]

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

[Dominique]

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

[Thierry]

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

[Thierry]

Je viens de pousser une version 0.7.0 de la librairie Labox qui continue de progresser :

• Les modifications de Dominique sur la lecture des CVs, l'affichage des valeurs tension/courant et la nouvelle option du menu pour identifier la machine sur la voie ont été poussées.
• Après avoir récupéré la dernière version officielle de DCC++ Classic (https://dcc-ex.com/download/dccex-downloads/), le fork du vieux DCC++ pour Uno/Mega corrigé par l'équipe de DCC++Ex, j'ai intégré leurs dernières corrections sur la lecture/écriture de Cvs. Cela concerne exclusivement le type et le nombre de paquets émis pendant ces phases là. Il semble qu'ils se soient bien davantage approchés des recommandations de la NMRA à ce sujet, c'est pour ça que j'ai intégré ces modifs. A tester et voir si ça marche mieux avec certains décodeurs récalcitrants.
• A côté de la commande <R> qui permet à DCC++ de lire une Cv sur la voie de programmation, j'ai ajouté une commande <r> qui lit une Cv sur la voie principale, avec bien sûr une seule loco sur la voie...
• Il est maintenant possible d’arrêter complètement une machine ! Le pas 0 n'était pas accessible...
• Les envois par WiThrottle ou Z21 de demandes pour mettre ou couper le courant sur la voie ne fonctionnaient pas, c'est corrigé.
• Dans le cas d'une interface WiThrottle, les fonctions ont été revues. Sur ces applis, c'est JMRI qui sait que telle fonction est un interrupteur (éclairage...) ou un poussoir (son...). Comme on ne dispose pas de ces informatrions, il a été décidé que la fonction 0 serait un interrupteur, et toutes les autres des poussoirs. Ainsi la fonction de base d'allumage des feux fonctionne, et les sons fonctionnent. Par contre aucune des fonctions d'éclairage autre que F0 ne fonctionnera. SI l'on veut bénéficier des fonctions dans leur intégralité, mieux vaut passer à une appli Z21 qui permet de définir le rôle de chaque fonction.
• Pour les applis Z21, la lecture des CVs a été implémentée. L'appli officielle ne permet que de lire des CVs sur la voie de programmation, ou de passer par un mode POM que labox ne gère pas (encore ?). Pour malgré tout arriver à lire une CV sur la voie principale, j'ai fait en sorte lorsqu'il n'y a pas de voie de programmation déclarée (pas de beginProg() dans le setup...) et que l'utilisateur demande une lecture sur la voie de programmation, de faire la lecture sur la voie principale.
• L'envoi de commandes DCC++ par la ligne série a été amélioré.
• Enfin, une nouvelle Throttle est apparue : ThrottleAutomation. Elle reprend le mode de fonctionnement qui était présent dans l'exemple AutoTest.ino sur la librairie DCCpp. Elle permet d'envoyer des commandes DCC++ texte à des intervalles de temps fixés par l'utilisateur. Ça peut être pratique pour automatiser une animation, un va et vient, ou juste un test comme dans l'exemple AutoTest.ino fourni et mis à jour. Si les commandes parviennent bien à DCC++ et sont donc envoyées sur la voie, leur effet n'est pas du tout visible sur l'écran du HMI. En effet celui ci ne considère que les accès Wifi et dans l'exemple, on a pas besoin de Wifi ! C'eut été très sympa de voir bouger l'écran au gré des commandes envoyées (le retour d'info des fonctions n'est pas encore géré...). Dans son état actuel, seuls des intervalles de temps en dur permet d'enchaîner les commandes. J'aimerai à terme pouvoir tester l'état d'une broche pour passer à l'action suivante. Ca permettrait de réagir à un capteur via les 'sensor' de DCC++ plutôt que d'attendre un temps déterminé... A creuser.

[Dominique]

Et bien Bravo ! Chapeau l'artiste 
J'ai hâte de tester ... avec les petits enfants qui arrivent cet après-midi ...

[Dominique]

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

[DDEFF]

Bonjour à tous,

On voit que ça avance et c'est super.

J'ai commandé tout le matériel que je n'avais pas. Ça arrivera ... quand ça arrivera 
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 ?

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/

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