1
JMRI et Arduino / Re : Protocole de pilotage
« le: décembre 30, 2019, 10:27:30 am »
C'est fait.
Cordialement
Cordialement
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
2
JMRI et Arduino / Re : 24 IN / 48 OUT card for JMRI
« le: décembre 30, 2019, 10:26:31 am »
Bonjour
C/MRI n'inclut aucune détection d'erreur. C'est à mon avis une grave faute de conception.
Le CAN est très facile à utiliser et le contrôleur incorpore tout le traitement du protocole. Il ne reste que le niveau applicatif à faire.
C/MRI n'inclut aucune détection d'erreur. C'est à mon avis une grave faute de conception.
Le CAN est très facile à utiliser et le contrôleur incorpore tout le traitement du protocole. Il ne reste que le niveau applicatif à faire.
3
Débuter / Re : installation du composant attiny85
« le: décembre 30, 2019, 10:04:54 am »
Bonjour,
Et en cliquant sur la petite icone à droite du champ « URL de gestionnaire de cartes supplémentaires » pour ouvrir la fenêtre permettant d'en saisir plusieurs ?
Et en cliquant sur la petite icone à droite du champ « URL de gestionnaire de cartes supplémentaires » pour ouvrir la fenêtre permettant d'en saisir plusieurs ?
4
Vie du forum / Re : Noël 2019
« le: décembre 26, 2019, 12:22:18 pm »
Joyeux Noël Antoine
Et Joyeux Noël à tous.
Et Joyeux Noël à tous.
5
Débuter / Re : pourquoi mon 471 a-t-il cramé ?
« le: décembre 07, 2019, 10:43:06 am »
Donc le courant était proche de 0 et ce n'est donc pas la raison pour laquelle le composant a grillé
6
Débuter / Re : pourquoi mon 471 a-t-il cramé ?
« le: décembre 07, 2019, 09:17:41 am »
Bonjour,
Une intensité ne se mesure pas aux bornes de l’alimentation. L’amperemètre doit être inséré dans le circuit.
Y avait il une charge sur les rails au moment où ca a grillé ?
Une intensité ne se mesure pas aux bornes de l’alimentation. L’amperemètre doit être inséré dans le circuit.
Y avait il une charge sur les rails au moment où ca a grillé ?
7
Vie du forum / Re : Support Servo Moteur pour aiguillages
« le: novembre 08, 2019, 06:37:25 pm »
Voici les fichiers STL
Le palonnier est fait pour s'encastrer sur une palonnier de HK15178 HobbyKing.
Servo que je recommande car, comparé au SG90 (du moins les 2-3 que je possède), il a un mouvement beaucoup plus régulier.
https://hobbyking.com/fr_fr/hobbykingtm-hk15178-analog-servo-1-4kg-0-09sec-10g.html
Le palonnier est fait pour s'encastrer sur une palonnier de HK15178 HobbyKing.
Servo que je recommande car, comparé au SG90 (du moins les 2-3 que je possède), il a un mouvement beaucoup plus régulier.
https://hobbyking.com/fr_fr/hobbykingtm-hk15178-analog-servo-1-4kg-0-09sec-10g.html
8
Trucs & astuces / Re : Comment faire un reset software d'un ATMega328
« le: août 29, 2019, 02:22:48 pm »
Bonjour,
Concernant le watchdog et les bootloader ancienne version, j'avais trouvé des informations indiquant que ces anciennes versions ne désactivaient pas le watchdog. Or lorsque le reset est dû au watchdog, le watchdog reste actif et si le temps d'attente du bootloader pour un nouveau flashage + le temps d'init avant setup est > au délai du watchdog, la carte passe son temps à rebooter. La solution est alors de couper son alimentation.
Le bootloader OptiBoot désactive le watchdog au démarrage et donc n'est pas touché par le phénomène.
Si tu veux que ça fonctionne quelque soit le bootloader tu peux
Concernant le watchdog et les bootloader ancienne version, j'avais trouvé des informations indiquant que ces anciennes versions ne désactivaient pas le watchdog. Or lorsque le reset est dû au watchdog, le watchdog reste actif et si le temps d'attente du bootloader pour un nouveau flashage + le temps d'init avant setup est > au délai du watchdog, la carte passe son temps à rebooter. La solution est alors de couper son alimentation.
Le bootloader OptiBoot désactive le watchdog au démarrage et donc n'est pas touché par le phénomène.
Si tu veux que ça fonctionne quelque soit le bootloader tu peux
- mettre un telai de watchdog suffisamment long pour assurer que tu arrives dans setup où tu vas couper le watchdog
- utiliser une broche en sortie connectée au RESET que tu pourras déclencher avec un simple digitalWrite
9
Vie du forum / Inscriptions en vue de SPAM
« le: juillet 25, 2019, 09:32:04 am »
Bonjour,
Le forum subit depuis ce matin (après un premier succès il y a quelques jours) un flot d'inscriptions bidon afin de disposer d'un compte permettant de spammer le forum (liens commerciaux dans les signatures). J'ai supprimé 7 ou 8 comptes.
La barrière de l'inscription avec la question qui tue ayant fini par être surmontée, j'ai changé la question ... jusqu'à la prochaine fois.
On va voir ce que ça donne.
Le forum subit depuis ce matin (après un premier succès il y a quelques jours) un flot d'inscriptions bidon afin de disposer d'un compte permettant de spammer le forum (liens commerciaux dans les signatures). J'ai supprimé 7 ou 8 comptes.
La barrière de l'inscription avec la question qui tue ayant fini par être surmontée, j'ai changé la question ... jusqu'à la prochaine fois.
On va voir ce que ça donne.
11
Vos projets / Re : BALDUINO WIFI
« le: juillet 05, 2019, 04:27:11 pm »
Bonjour,
le "/R" est le chemin après l'IP.
Par exemple si le serveur est à l'IP 192.168.1.1, accéder à http://192.168.1.1/R avec ton navigateur te renverra "AV"
Ceci dit, je ne pense pas que faire tourner un serveur web pour communiquer soit la bonne solution (à vrai dire ça n'est pas du tout comme ça qu'il faut faire), il vaudrait mieux communiquer directement avec les sockets. Cherche "ESP32 socket examples" tu trouveras des tutos, par exemple : https://techtutorialsx.com/2018/05/25/esp32-socket-server-controlling-a-relay-remotely/
le "/R" est le chemin après l'IP.
Par exemple si le serveur est à l'IP 192.168.1.1, accéder à http://192.168.1.1/R avec ton navigateur te renverra "AV"
Ceci dit, je ne pense pas que faire tourner un serveur web pour communiquer soit la bonne solution (à vrai dire ça n'est pas du tout comme ça qu'il faut faire), il vaudrait mieux communiquer directement avec les sockets. Cherche "ESP32 socket examples" tu trouveras des tutos, par exemple : https://techtutorialsx.com/2018/05/25/esp32-socket-server-controlling-a-relay-remotely/
12
JMRI et Arduino / Re : Protocole de pilotage
« le: juillet 05, 2019, 09:32:49 am »
Bonjour,
Juste pour info, j'ai entrepris de coder un analyseur C/MRI et une émulation des SMINI dans le but de faire apparaître des satellites V1 comme des SMINI pout JMRI. C'est pas fini, ça ne fonctionne pas encore mais l'analyseur est implémenté (un automate pour le message et un pour le protocole) mais évidemment pas testé.
L'architecture objet permet d'ajouter l'émulation des autres cartes C/MRI par la suite. Ça sera étendu aux satellites V2 dans le futur.
Il y a encore de travail : un peu de code à écrire et beaucoup de test.
Le repository est ici : https://github.com/Locoduino/CMRIParser
PS : J'ai examiné la bibliothèque de madleech : https://github.com/madleech/ArduinoCMRI. Elle ne me satisfait pas.
Au moins deux bugs sont présents : lignes 115 et 130 les tests sont faux
La transmission fait une attente active (appel de delay) de 50ms, bloquant les autres opérations sur la carte
La transmission est monolithique et bloque potentiellement sur le buffer d'émission.
Juste pour info, j'ai entrepris de coder un analyseur C/MRI et une émulation des SMINI dans le but de faire apparaître des satellites V1 comme des SMINI pout JMRI. C'est pas fini, ça ne fonctionne pas encore mais l'analyseur est implémenté (un automate pour le message et un pour le protocole) mais évidemment pas testé.
L'architecture objet permet d'ajouter l'émulation des autres cartes C/MRI par la suite. Ça sera étendu aux satellites V2 dans le futur.
Il y a encore de travail : un peu de code à écrire et beaucoup de test.
Le repository est ici : https://github.com/Locoduino/CMRIParser
PS : J'ai examiné la bibliothèque de madleech : https://github.com/madleech/ArduinoCMRI. Elle ne me satisfait pas.
Au moins deux bugs sont présents : lignes 115 et 130 les tests sont faux
La transmission fait une attente active (appel de delay) de 50ms, bloquant les autres opérations sur la carte
La transmission est monolithique et bloque potentiellement sur le buffer d'émission.
13
Vos projets / Re : BALDUINO WIFI
« le: juillet 03, 2019, 08:57:01 am »
Bonjour,
J'ai fait des test longue durée sur une communication en UDP entre mon Mac et un Weimos Mini D1 (ESP8266) pour un truc qui n'a rien à voir avec le modélisme ferroviaire. Le Mac envoyait un message toutes les 10s avec un numéro d'ordre. Le Mini D1 incrémentait de son côté un compteur et le comparait avec le numéro d'ordre pour voir si un message était perdu. L'ensemble a tourné pendant 3 jours.
Résultat : 12% des messages sont perdus, ce qui est bien au dessus de ce qui est attribuable au fait que l'UDP ne fait pas d'acquittement. On va dire que la communication en UDP sur un ESP8266 marche jusqu'à un certain point mais que bon c'est très très loin d'être fiable.
Donc ne pas hésiter à répéter les messages.
Par ailleurs, j'avais aussi fait quelques tests, mais de manière plus informelle, avec un serveur http sur le même Weimos Mini D1. Le serveur répond un peu quand ça lui chante : des requêtes qui n'aboutissent pas ou qui aboutissent après un délai important. Je ne saurais dire la proportion d'échec mais c'est loin d'être négligeable. J'ai pas encore essayé les websocket.
J'ai fait des test longue durée sur une communication en UDP entre mon Mac et un Weimos Mini D1 (ESP8266) pour un truc qui n'a rien à voir avec le modélisme ferroviaire. Le Mac envoyait un message toutes les 10s avec un numéro d'ordre. Le Mini D1 incrémentait de son côté un compteur et le comparait avec le numéro d'ordre pour voir si un message était perdu. L'ensemble a tourné pendant 3 jours.
Résultat : 12% des messages sont perdus, ce qui est bien au dessus de ce qui est attribuable au fait que l'UDP ne fait pas d'acquittement. On va dire que la communication en UDP sur un ESP8266 marche jusqu'à un certain point mais que bon c'est très très loin d'être fiable.
Donc ne pas hésiter à répéter les messages.
Par ailleurs, j'avais aussi fait quelques tests, mais de manière plus informelle, avec un serveur http sur le même Weimos Mini D1. Le serveur répond un peu quand ça lui chante : des requêtes qui n'aboutissent pas ou qui aboutissent après un délai important. Je ne saurais dire la proportion d'échec mais c'est loin d'être négligeable. J'ai pas encore essayé les websocket.
14
Vos projets / Re : Article 232 - Va et vient
« le: juillet 01, 2019, 06:43:50 pm »
Hello Steve
The project uses the DCCpp library (Thierry is the author). This library is available through the library manager of the IDE. In Tools menu, choose Manage libraries... and type DCCpp in the search box
Best regards
PS: to translate you can use this excellent translator: https://www.deepl.com/translator
The project uses the DCCpp library (Thierry is the author). This library is available through the library manager of the IDE. In Tools menu, choose Manage libraries... and type DCCpp in the search box
Best regards
PS: to translate you can use this excellent translator: https://www.deepl.com/translator
15
Vos projets / Re : BALDUINO WIFI
« le: juillet 01, 2019, 07:50:26 am »
Bonjour,
request est un char, il est déclaré deux lignes au dessus. Ce n'est donc pas un objet et par conséquent il n'a pas de méthode indexOf.
request est un char, il est déclaré deux lignes au dessus. Ce n'est donc pas un objet et par conséquent il n'a pas de méthode indexOf.