projet centrale "LaBox" wifi DCC++ Can

[msport]

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.

[laurentr]

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

[Thierry]

Bonsoir.

Nouvelle version 0.7.2 (j'arrête pas...)

• La commande d'arrêt d'urgence (speed 1) était bloquée par un traitement trop pointu de la vitesse à envoyer sur les rails. J'ai donc tout supprimé, et la vitesse envoyée dans les paquets est celle demandée par les applis, sans filtre.
• Du coup, les messages Idle et stop de WiThrottle sont maintenant traités, de même que leur équivalent 'Arrêt' et 'Main levée' de EngineDriver.
• J'ai mis sous condition les messages que j'avais ajouté dans la gestion des événements Hmi. Ca en réduit le volume.
• Un motif de plantage dans hmi lors de l'utilisation de la commande série a été corrigé.
• Une fois de plus, la liaison série a été corrigée et devrait maintenant -enfin- fonctionner via le ThrottleSerial ! Il est d'ailleurs présent dans Labox.ino .

[Thierry]

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.

[Dominique]

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

[msport]

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.

[Thierry]

Voilà, avec la 0.7.3, les commandes DCC++ devraient arriver aux rails ! Le traitement de chaîne de la Throttle 'bouffait' les espaces !

[msport]

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.

[DDEFF]

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 

[Thierry]

L'inertie est traitée en interne par le décodeur, donc pas moyen de connaître le cran réel à l'instant t...

[DDEFF]

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 

[trimarco232]

Bonjour,
aviez vous jeté un oeil à ceci : 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 ?

[Dominique]

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

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.

[trimarco232]

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 ?

[msport]

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.