Messages récents

Pages: 1 ... 6 7 [8] 9 10
71
Composants / Re : Compatibilité PCA9685 et DFPlayer
« Dernier message par trimarco232 le mars 18, 2025, 02:28:05 pm »
c'est singulier (sans jeu de mot) ; peux-tu mesurer le 5v , avec les servos et le DF en "service" ?
73
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« Dernier message par DDEFF le mars 18, 2025, 01:03:39 pm »
Bonjour à tous,

Mais pourquoi donc ai-je réalisé ce programme ?

C'est vrai qu'on pourrait se poser la question à une époque où il y a des IA qui génèrent automatiquement un fichier JSON à partir de données.

Pourquoi un fichier au format JSON ?

C'est un format moderne qui permet de ranger des informations dans une structure claire, en identifiant bien les objets. En plus, il est géré nativement dans Processing, ce qui ne gâche rien.

Le choix du format JSON étant fait, pourquoi se casser la tête avec un programme de plus de 10 000 lignes, avec plus de 1 000 "if" et près de 500 "case" ??
Parce que, si la rédaction d'un fichier au format JSON quand on a déjà les infos est automatisable par IA, le calcul de toutes les infos l'est beaucoup moins.

Il faut se rendre compte que mon fichier JSON contient 90 % d'infos calculées, pour 10 % d'infos directes !
Par exemple, je dis qu'une zone s'appelle "Z25" et qu'elle "a un signal côté B".
Dans le JSON, on saura ça :
------------------------------------------------------------------
zone Z25 signal cote A : panneau -, signaux = -
zone Z25 signal cote B : panneau Cv sol, G, signaux = C1 : A, VL, RR30, (Z26 lames2), RR60, (Z26 lames1),  R30, (Z28), C, Cv, M,  Bs19
1°) Il n'y a pas de signal côté A (ça, ce n'est pas dur)
2°) Du côté B, il y a un signal sur un panneau "G", avec un signal au sol qui affiche "Carré violet" et "Manœuvres" et, sur le panneau, qui s'appelle "C1", les signaux "Avertissement", "Voie Libre", "Rappel de Ralentissement à 30 km/h" quand l'aiguille de la zone Z26 a les lames en position 2, "Rappel de Ralentissement à 60 km/h" quand l'aiguille de la zone Z26 a les lames en position 1, "Ralentissement à 30 km/h" si vous allez vers la zone Z28, le "Carré" et que la balise qui concerne ce signal a le numéro 19.

Au passage, ça vous dit quels panneaux acheter pour votre réseau et comment brancher vos moteurs d'aiguilles pour économiser les boutons (bretelles détectées automatiquement, "super appareils" pour regrouper les moteurs)

Et, "accessoirement", on dessine un TCO dans la foulée…

Et, tout ça sans à priori sur le réseau qui peut être de n'importe quelle taille et composé de n'importe quels éléments.

Denis
74
Composants / Re : Compatibilité PCA9685 et DFPlayer
« Dernier message par Beber le mars 18, 2025, 11:40:35 am »
Bonjour,
oui le DFPlayer marche seul sur Méga. Idem pour le pilotage des servos.
Ce sont les 2 ensembles qui ne fonctionnent plus.

Merci.
75
Aide / Re : Alimentation de plusieurs cartes Nano séparées
« Dernier message par loulout le mars 18, 2025, 10:17:09 am »
Je crois que j'ai obtenu toutes les infos auprès de Gemini (IA), de manière assez précise et concise. Résultat résumé : une alimentation en 5V au moyen d'un transfo délivrant au moins 1A et d'un hub usb alimenté.

Ce type de système IA devrait permettre de poser beaucoup moins de questions dans les forums. On peut donc gagner en précision, concision et rapidité au détriment peut-être du dialogue avec autrui. Mais pour des questions "bateau" comme celle que j'ai posée, ça peut être pertinent.
76
Je n’ai pas le temps nécessaire pour étudier ce problème en ce moment.

Après téléchargement, que se passe-t-il ?
77
Composants / Re : Compatibilité PCA9685 et DFPlayer
« Dernier message par trimarco232 le mars 17, 2025, 11:20:57 pm »
Bonjour,
est-ce que le DFPlayer seul sur le mega , ça fonctionne ?
78
Les réseaux / Re : Re : Mes petits réseaux hybrides à base d'Arduino
« Dernier message par loulout le mars 17, 2025, 11:09:00 pm »
Bravo, est une belle réalisation.

Le bluetooth est une technique de transmission qui a été très peu mise en avant jusqu'ici sur Locoduino. Est-ce que tu accepterais de faire une petite synthèse avec avantages et inconvénients maintenant que tu as pas mal de recul.

Personnellement, je reste dans mes zones de confort (CAN et TCP (WiFi mais principalement Ethernet). Il faudra bien qu'un jour pour bousculer un peu mes neurones, je teste le BT. J'essayerai sans doute pour commencer des petits périphériques comme des capteurs éloignés.

Félicitation encore, voilà un projet ferroviaire concret et bien avancé. Tiens nous informés de la progression.

Christophe
Merci pour les félicitations ! Toutefois je dois dire que la gestion du Bluetooth est relativement simple à programmer, sans doute beaucoup plus que le wifi, et qu'il existe pas mal d'exemples de code sur lesquels je me suis appuyé, aussi bien en C++ (notamment sur le site stackoverflow) qu'en langage Arduino (sketch "LED" fourni dans les exemples). C'est sans doute un premier avantage.

Côté inconvénients, je n'ai pas à l'esprit avoir remarqué des défauts ou des ennuis si on respecte bien l'initialisation du service Bluetooth que l'on doit inclure dans les codes de l'appli et des sketchs. J'avoue cependant ne pas utiliser intensément et très souvent l'application. Mais à chaque fois que je l'utilise, je ne rencontre pas de problème. Le démarrage du service est plutôt rapide, quelques secondes.

Autre avantage, les temps de réponse sont excellents. Une action sur la tablette (qui est assez basique et pas très récente), vitesse, feux, klaxon, ..., est exécutée immédiatement sur le réseau. Idem dans le sens inverse lorsque j'ai testé un capteur à effet Hall et où l'info est remontée dans l'appli. Ou bien encore, un changement de CV, par exemple pour changer la sonnerie de la loco puis l'actionner, est instantané.

Toutefois, il faut avoir à l'esprit que l'utilisation du Bluetooth découle uniquement du désir d'utiliser une appli "maison" à la place d'un logiciel du commerce ou simplement d'une centrale DCC. Mais si on est, comme moi, un peu exigeant en matière d'appli, simple, conviviale, personnalisable, il n'y a pas vraiment d'autre solution "wireless", du moins il me semble.

Je ne sais pas si j'ai répondu à ta demande de synthèse mais je peux développer certains points si besoin.

Louis
79
Je viens de changer le code de cette ligne par ceci :
ESP32Encoder::useInternalWeakPullResistors= puType::up;
Dans la bibliothèque, il spécifié ceci :
enum class puType {
   up,
   down,
   none
};...
static puType useInternalWeakPullResistors;

Est-ce que ma modification est pertinente ? Je n'ai plus d'erreur de compilation.
Merci
80
Bonjour,

Merci pour ta réponse.
J'ai bien vu que msport est malheureusement décédé, ses contributions m'intéressaient beaucoup.
L'erreur apparaît dans l'IDE version 2.3.4.
Il s'agit du fichier *.ino indiqué dans l'article : https://locoduino.org/IMG/zip/s_dials-18.zip
Le problème est à la ligne 733 avec ce message d'erreur :
C:\Users\jb\Downloads\s_dials-18\S_dials-18\S_dials-18.ino: In function 'void setup()':
C:\Users\jb\Downloads\s_dials-18\S_dials-18\S_dials-18.ino:733:46: error: 'UP' was not declared in this scope; did you mean 'UDP'?
  733 |   ESP32Encoder::useInternalWeakPullResistors=UP;
      |                                              ^~
      |                                              UDP
exit status 1
Compilation error: 'UP' was not declared in this scope; did you mean 'UDP'?

Il y a probablement un problème lié à la bibliothèque "ESP32Encoder.h"(https://github.com/madhephaestus/ESP32Encoder), mais je suis désolé, j'ai toujours été nul en programmation.
Comment savoir si les lignes #include <driver/gpio.h> et #include <driver/pcnt.h> de la bibliothèque sont bien trouvées par l'IDE ?
C'est d'autant plus regrettable que j'ai tout le hardware qui semble fonctionner.
Pages: 1 ... 6 7 [8] 9 10