projet centrale "LaBox" wifi DCC++ Can

[Jean-Luc]

C'est quoi exactement votre « cafouillage au démarrage à froid » ? Je soupçonne qu'on ne parle absolument pas de la même chose 

[Dominique]

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 ?

[bobyAndCo]

Ce ne serait pas sorcier de faire un breakout à 7 pins (le +5 est juste à coté) avec un MCP2562.

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.

[msport]

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.

[Thierry]

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 :

Code: [Sélectionner]

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

[Dominique]

Waouhh!

[AmadeusHF]

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

[msport]

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.

[msport]

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.

[Pyk35]

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.

[Dominique]

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

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

[Pyk35]

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+

[Dominique]

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.

Pour le CAN, il aurait fallut intégrer la passerelle CAN / Wifi non ?

Sans doute mais il faudrait que je la regarde sérieusement.

[msport]

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.

[DDEFF]

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 !

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.

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