331
Présentez vous ! / Re : Bonjour à tous
« le: février 08, 2020, 09:35:44 pm »
Merci JCG et bienvenue parmi nous.
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.
332
Vie du site rédactionnel et du forum / Re : Voeux 2020
« le: janvier 01, 2020, 08:46:17 pm »
Tous mes vœux également pour nos membres. Plein de réalisations Arduino, de train, et beaucoup de sous pour acheter tout ça !
333
Vos projets / Re : La bibliothèque SlowMotionServo en 8 bits pour ATTiny
« le: décembre 19, 2019, 04:20:19 pm »
Est ce qu'il ne vaudrait pas mieux modifier la bibliothèque originale et utiliser des #ifdef en fonction du modèle d'Arduino pour compiler ?
334
Discussions ouvertes / Re : condensateur et passage au DCC
« le: décembre 12, 2019, 05:54:34 pm »
On peut aussi faire pour de petits volumes, par exemple en N en utilisant des composants cms :
https://shop.1001-digital.de/umbau/elektronik/117/bauteil-set-ladeschaltung-10er-packung
https://shop.1001-digital.de/umbau/elektronik/117/bauteil-set-ladeschaltung-10er-packung
335
Discussions ouvertes / Re : condensateur et passage au DCC
« le: décembre 11, 2019, 06:16:20 pm »
Les condensateurs ont tendance à lisser le signal -simili- carré DCC... Du coup ça marche beaucoup moins bien. Alors que sur du continu, le lissage rend service !
336
Vos projets / Re : Wagon de mesure distance et vitesse
« le: décembre 10, 2019, 06:09:06 pm »
Et je confirme, c'est un super boulot. Le texte présenté ici pourrait presque être copié/collé tel quel vers un article...
337
Vos projets / Re : Faire varier la vitesse d'un moteur DC en fonction de la distance
« le: décembre 08, 2019, 02:48:57 pm »
Bonjour
Vous êtes ici sur le forum d'un site dont le but est de promouvoir l'utilisation des Arduino sur les réseaux de modélisme ferroviaire. Nous ne répondons pas en dehors de ce cadre. Vous devriez voir avec des forum plus généralistes pour trouver une solution à votre problème, comme forum.arduino.cc par exemple.
Vous êtes ici sur le forum d'un site dont le but est de promouvoir l'utilisation des Arduino sur les réseaux de modélisme ferroviaire. Nous ne répondons pas en dehors de ce cadre. Vous devriez voir avec des forum plus généralistes pour trouver une solution à votre problème, comme forum.arduino.cc par exemple.
338
Le logiciel DCC++ / Re : Problème de lecture et programmation de CVs avec DCC++
« le: décembre 06, 2019, 05:52:34 pm »
Sur la bibliothèque DCCpp (la version 1.3.7 présente sur Github, la modif date du mois d'aout...), il y a une fonction que tout le monde peut appeler dans son setup : DCCpp::setAckThreshold(60); par exemple. Si cette valeur se révèle meilleure, effectivement je la poserai comme valeur par défaut de la bibliothèque, mais c'est déjà possible de tester avec DCCpp sans modifier la bibliothèque.
339
Vos projets / Re : Eclairage constant des trains en analogique
« le: septembre 19, 2019, 03:03:49 pm »
Bonjour
Le problème en analogique, c'est la source d'énergie. Autant en DCC les rails sont constamment et régulièrement alimentés, autant en analogique la tension varie selon l'utilisateur. Il faut donc palier à ce manque, et je ne pense pas qu'un Arduino soit la solution. Il pourrait même devenir un problème supplémentaire, puisqu'il consommera sans doute encore plus que la led à allumer, et donc qu'il faudra lui aussi l'alimenter.
Une partie de la solution réside dans les condensateurs que l'on voit fleurir maintenant dans les kits d'éclairage de voiture et fin de convoi. Le condensateur est prévu généralement pour permettre une continuité de l'éclairage même en cas de micro-coupure. Mais selon sa puissance, il va tenir d'une seconde à au mieux une ou deux minutes pour un feu de fin de convoi moins gourmand qu'un éclairage complet de voiture...
Donc pour moi deux possibilités très proches :
1 : trouver un condensateur qui a un rapport puissance / encombrement suffisant pour assurer l'alimentation voulue, mais c'est dépendant de la consommation de l'éclairage et de la place disponible (beaucoup ici sont en N... Et le HOe n'est pas beaucoup mieux loti).
2 : Soit disposer d'une alimentation locale, type batterie embarquée rechargée par les rails, mais là encore l'encombrement va forcément limiter les possibilités.
Une autre solution consiste à ajouter un signal pulsé sur la voie que le moteur n'interprète pas comme une tension continue. Voir ici http://amfn.nice.free.fr/eclbf.htm
Le problème en analogique, c'est la source d'énergie. Autant en DCC les rails sont constamment et régulièrement alimentés, autant en analogique la tension varie selon l'utilisateur. Il faut donc palier à ce manque, et je ne pense pas qu'un Arduino soit la solution. Il pourrait même devenir un problème supplémentaire, puisqu'il consommera sans doute encore plus que la led à allumer, et donc qu'il faudra lui aussi l'alimenter.
Une partie de la solution réside dans les condensateurs que l'on voit fleurir maintenant dans les kits d'éclairage de voiture et fin de convoi. Le condensateur est prévu généralement pour permettre une continuité de l'éclairage même en cas de micro-coupure. Mais selon sa puissance, il va tenir d'une seconde à au mieux une ou deux minutes pour un feu de fin de convoi moins gourmand qu'un éclairage complet de voiture...
Donc pour moi deux possibilités très proches :
1 : trouver un condensateur qui a un rapport puissance / encombrement suffisant pour assurer l'alimentation voulue, mais c'est dépendant de la consommation de l'éclairage et de la place disponible (beaucoup ici sont en N... Et le HOe n'est pas beaucoup mieux loti).
2 : Soit disposer d'une alimentation locale, type batterie embarquée rechargée par les rails, mais là encore l'encombrement va forcément limiter les possibilités.
Une autre solution consiste à ajouter un signal pulsé sur la voie que le moteur n'interprète pas comme une tension continue. Voir ici http://amfn.nice.free.fr/eclbf.htm
340
Présentez vous ! / Re : bonjour a tous
« le: septembre 13, 2019, 02:34:22 pm »
Bonjour et bienvenue
N'hésites pas à partager aussi ton projet ferroviaire avec nous.
N'hésites pas à partager aussi ton projet ferroviaire avec nous.
341
Débuter / Re : Rétrosignalisation
« le: septembre 09, 2019, 09:40:33 am »
Bonjour. Attention DCC++ et ses déclinaisons Locoduino (DCCpp, DcDccNanoController...) ne gèrent pas les STM32 dites 'Blue-Pill' aujourd'hui. Seuls les Nano et Mega sont gérés d'entrée. Une version ESP32 existe, mais je n'ai pas réussi à la compiler...
342
Vos projets / Re : Interface Digikeijs DR5000 pour moteur d'aiguillage piloter par Arduino
« le: août 30, 2019, 03:45:39 pm »
Une autre solution plus 'locale' serait d'utiliser nos bibliothèques Commanders (https://www.locoduino.org/spip.php?article165) pour le décodage DCC et Accessories (https://www.locoduino.org/spip.php?article178) pour le pilotage des accessoires. Le premier reçoit les ordres de la centrale et les transmet à la seconde qui fait le boulot... Les articles décrivent bien le comportement, mais les exemples d'Accessories sont encore plus parlants.
343
Trucs & astuces / Re : Comment faire un reset software d'un ATMega328
« le: août 24, 2019, 09:42:39 am »
Peut être la bibliothèque de Jean Luc avec son watchdog ? Est ce qu'il ne fait pas ce genre de chose ?
344
Le logiciel DCC++ / Re : Problème de retour d'info des decodeurs
« le: août 23, 2019, 09:48:12 am »
Il semble qu'une réponse ait été trouvée sur ce problème sur le forum du créateur de DCC++ :
https://www.trainboard.com/highball/index.php?threads/dcc-issues-with-d-h-10c-resolved.106064/#post-1105369
La solution de ce forumiste : changer un peu les paquets d'attente de réponse -trois paquets de reset- qui sur ses décodeur D&H empêchaient l'envoi du ACK. La modif a d'ailleurs été confirmée par le service technique de D&H . Il a aussi modifié un peu la manière de chercher l'info en réduisant de moitié le nombre de mesures de courant et en passant à 5 au lieu de 30 la sensibilité de la détection...
Je joins les fichiers modifiés pour ceux qui veulent tester sur leur décodeurs récalcitrants. Reste à vérifier que ça marche encore sur les autres !
https://www.trainboard.com/highball/index.php?threads/dcc-issues-with-d-h-10c-resolved.106064/#post-1105369
La solution de ce forumiste : changer un peu les paquets d'attente de réponse -trois paquets de reset- qui sur ses décodeur D&H empêchaient l'envoi du ACK. La modif a d'ailleurs été confirmée par le service technique de D&H . Il a aussi modifié un peu la manière de chercher l'info en réduisant de moitié le nombre de mesures de courant et en passant à 5 au lieu de 30 la sensibilité de la détection...
Je joins les fichiers modifiés pour ceux qui veulent tester sur leur décodeurs récalcitrants. Reste à vérifier que ça marche encore sur les autres !
345
Le logiciel DCC++ / Re : Problème de retour d'info des decodeurs
« le: août 20, 2019, 10:41:35 am »
Plus j'avance, plus je pense que c'est un problème de timing plutôt que de niveau. la norme (https://www.nmra.org/sites/default/files/s-9.2.3_2012_07.pdf ligne 46) définit une fenêtre assez étroite de 6ms de retour de communication, après l'envoi de la fin du dernier paquet,
et je ne suis pas sûr :
1 que DCCpp respecte ce timing
2 que tous les décodeurs respectent le timing !
Citer
General Acknowledgment timing
For either type of Acknowledgment, if a Service Mode Write is being performed, Acknowledgment pulse(s) should
not occur from the decoder until internal updating of all affected non-volatile data storage is complete in the
55 decoder. During Service Mode the Programmer should scan for any Acknowledgment current pulse(s) in the
Acknowledgment time window starting at the Packet End bit of the second service mode instruction packet and
extending through the required number of instruction packets and in the case of write operations through the
specified decoder-recovery-time A Command Station/Programmer may not stop sending packets to the
programming track (which turns off power to the decoder) until the end of the Decoder-Recovery-Time.
et je ne suis pas sûr :
1 que DCCpp respecte ce timing
2 que tous les décodeurs respectent le timing !