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.


Messages - Thierry

Pages: [1] 2 3 ... 28
1
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

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

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

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

5
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 ?

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

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

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 !

8
Vos projets / Re : Levée de boucliers!
« le: août 17, 2019, 02:53:09 pm »
Ci-joint mon premier jet de ton projet. Ca fonctionne bien sur mon émulateur, mais je n'ai pas câblé physiquement pour voir le résultat...
Le code de la fin de SignalArduinoPattern::beginSignal() entre balises VISUALSTUDIO m'a servi à tester en balayant à intervalles réguliers toutes les combinaisons actives. Si tu enlèves le #define, tu pourras aussi essayer en vrai ce que ça donne, sans avoir encore le décodage DCC...

9
Vos projets / Re : Levée de boucliers!
« le: août 17, 2019, 11:26:05 am »
Un Nano est bien capable de gérer deux feux de 8 leds chacun sans modification. Au delà, il conviendra d'ajouter des multiplicateurs de port, en digital (74HC) ou en PWM (tlc5940)... D'ailleurs, seul un port PWM pourra faire du light dimming (allumage/extinction progressive d'une vieille ampoule), et le Nano ne dispose que 6 broches capables de PWM. Peut être qu'une bibliothèque comme SoftPWM peut rendre ce service...

10
Vos projets / Re : Levée de boucliers!
« le: août 17, 2019, 10:53:48 am »
Je retire ce que j'ai dit ! La broche 2 est bien utilisable sur un Nano, après vérification sur le site de référence arduino.cc .

Le choix du type d'Arduino est fait par l'IDE. Rien à faire dans le code par défaut, mais des adaptations aux bonnes broches pourraient être faites.

11
Vos projets / Re : Levée de boucliers!
« le: août 16, 2019, 10:50:26 pm »
Bonjour

Ca va fonctionner sur un Mega dont la broche 2 est capable de faire ce boulot, mais pas sur un Uno ou Nano. Je n'ai pas retrouvé dans le sujet de référence à un modèle d'Arduino, donc attention... Les autres broches sont ou des entrées ou des sorties, au choix.

La classe SignalArduinoPattern  repose sur la classe AccessoryLightMulti. Celle ci est une liste de Leds dont le comportement est régit par deux entiers, un pour l'allumage et l'autre pour le clignotement. Ces entiers sont codés sur 16 bits, ce qui signifie qu'un signal ne pourra pas avoir plus de 16 leds. Chaque entier est utilisé comme un champs de bits, chacun représentant une led. Chaque Led est associée à un port qui va permettre de l'alimenter.

L'accessoire contient également une liste d'identifiants qui représentent toutes les combinaisons d'allumage/clignotement possibles. Chaque combinaison est nommée par un identifiant qui, dans le cas du DCC, est un mix entre une adresse DCC de décodeur d'accessoires et un numéro d'accessoire. C'est de rôle de la macro de DCCINT() d'assembler ces deux petits entiers pour en faire un gros qui devient l'identifiant d'une combinaison donnée.

Je suis en train de refaire SignalFrench pour permettre de fixer le code DCC de chaque etat individuellement.

12
Présentez vous ! / Re : Presentation
« le: août 15, 2019, 08:17:50 pm »
Bonjour et bienvenue !

13
Vos projets / Re : Levée de boucliers!
« le: août 14, 2019, 05:25:38 pm »
Accessories comme Commanders se configurent à partir de leur fichier .h respectif.

Dans Accessories.h, enlever le commentaire de la ligne

//#define NO_EXPANDER
et comme ça, l'installation des sous-bib pour le 1509 et le 74HC ne sont plus nécessaires.

A l'inverse, le DCC n'est pas activé par défaut dans Commanders, vu que l'essentiel des usages de la bibliothèque se concentre sur les boutons en tout genre. Il faut donc mettre en commentaire l'une des deux lignes

#define NO_DCCCOMMANDER
#define NO_DCCCOMMANDERNMRA

et ainsi obtenir tout ce qui va avec le DCC, dont les macros dont tu parles. Je conseillerai d'utiliser la bibliothèque NMRA plutôt que celle de base. Elle est plus fiable.

Dans les deux bibliothèques, profites-en pour retirer de la compilation par le même moyen tout ce qui ne te servira pas, comme le shield l293d ou les moteurs pas à pas (stepper) dans Accessories. Pour chacune, tu peux double cliquer sur le fichier extras/Doc/index.html pour avoir une doc détaillée en Anglais des classes, defines et autres fonctionnements obscurs. N'hésites pas à me signaler des manques dans cette doc si besoin.

14
Vos projets / Re : Re : Levée de boucliers!
« le: août 12, 2019, 02:34:39 pm »
Allumer éteindre des leds parait simple comme "blink" mais ca devient plus "touchy" des lors que tu combines avec des adresses DCC, des combinaisons d'affichage, des états particuliers, des groupes de leds sur des plages d adresses... Et la tu as deja perdu beacoup de monde!

Et justement, Commanders comme Accessories ne sont pas perdus, ils sont faits pour ça ! Pour Commanders, une ligne unique déclare la présence d'un décodeur DCC. Et pour Accessories, chaque Led ou moteur réagit à des événements qui intègrent déjà l'adresse DCC... Je ne force personne, je dis juste que faire mieux qu'allumer une Led, on le fait déjà très bien, et que ce serait dommage de ne pas capitaliser sur ce qui existe et qui marche (et réponds parfaitement au 'cahier' des charges) !

15
Vos projets / Re : Levée de boucliers!
« le: août 12, 2019, 11:36:14 am »
Pour la partie codage, je signale l'existence du couple de bibliothèques Commanders/Accessories dont la raison d'être est justement le décodage DCC (entre autres) pour la première, et le pilotage de Leds et moteurs au sens large pour la seconde. Toutes les possibilités de paramétrage existent déjà, depuis le light dimming similaire à celui de Jean-Luc, en passant pas la gestion de feux complexes ou le paramétrage des durées de clignotement. Pour les moteurs, les solénoïdes, les moteurs classiques et les moteurs pas à pas sont gérés... De même que les servos.
Commanders de son côté utilise depuis peu la librairie NmraDcc pour le décodage, ce qui lui permet de fonctionner aussi bien sur un AVR qu'un ESP ou un STM...
Et comme l'auteur de ces bibliothèques est gentil, si on lui demande poliment, il pourra ajouter ce qu'il manque et fera ainsi évoluer son produit ! :)

Pages: [1] 2 3 ... 28