Limitation a 4 accessoires contournable?

[Armoricain]

Bonjour,
Tout d'abord, je presente mes excuses pour le manque d'accents et les fautes d'orthographe a venir. Tout d'abord, je reside a l'etranger depuis un moment et mon Francais se rouille, secondement mon clavier n'est pas configure pour le Francais.
D'apres ce que je comprends, je peux avoir des centaines de decodeurs d'accessoires en DCC, mais comme precedemment indique, seulement 4 accessoires (de 0 a 3) par decodeur a cause de la sous adresse utilisant 2 bits.
Je souhaite  automatiser le fonctionnement de mes trains avec l'option de faire des modifications manuelles de routes. Pour cela j'ai commence a jouer avec DCC++ / Processing. J'ai de bons resultats sur mes tests, mais je trouve la limitation a 4 accessoires par  decodeur franchement peu pratique pour mes besoins.
Du a des contraintes de miniaturisation et d'espace -J'utilise l'echelle N et je suis tente d'essayer Z-  j'utilise des servomoteurs miniatures (SG90) pour mes aiguillages, et je n'ai pas la place (ou le desir) d'avoir 3 decodeurs l'un a cote de l'autre pour gerer un groupe de 10-12 aiguillages (et d'autres pour les signaux, animations etc) lorsqu'un arduino nano (J'en ai une quantite impressionnante , ce sont mes cartes de choix) peut gerer 17 servos sans souci si ce n'est cette limitation des sous adresses.
Donc:
- Il y a-t-il moyen de contourner cette limitation?
- Devrais-je tenter d'avoir ma base station controler directement des aiguillages sans envoyer de commandes par les rails?

Il est possible que l'information que je cherche soit deja disponible sur le site, mais je ne l'ai pas (encore?) trouvee.

[Dominique]

Bonjour,

La réponse est probablement dans cet article, les 16 feux sont décodés par un seul Mega qui gère donc 16*4=64 états.

http://www.locoduino.org/spip.php?article199

[msport]

Bonjour,
pour autant que j'ai compris, c'est un problème de codage.

Bien que les accessoires et les aiguillages partagent les mêmes adresses (mais si l'ID de l'aiguillage correspond à la sous-adresse d'un accessoire, leur mode de commande diffèrent) :

Controlling a Accessory Decoder** with **< a ADDRESS SUBADDRESS ACTIVATE >
•   <: Begin DCC++ command
•   a (lower case a) this command is for a Acessory Decoder
•   ADDRESS: the primary address of the decoder controlling this turnout (0-511)
•   SUBADDRESS: the subaddress of the decoder controlling this turnout (0-3)
•   ACTIVATE: (0) (Deactivate, Off, Unthrown) or (1) (Activate, On, Thrown)
•   >: End DCC++ command
o   However, this general command simply sends the appropriate DCC instruction packet to the main tracks to operate connected accessories. It does not store or retain any information regarding the current status of that accessory.

Controlling a Defined Turnout
•   Sets turnout ID to either the "thrown"(turned) or "unthrown"(straight) position
•   The Turnout format is < T ID THROW >
•   ID: The numeric ID (0-32767) That you gave the turnout to control when you defined it.
•   THROW: 0 (unthrown) or 1 (thrown)
•   Returns: < H ID THROW > or < X > if turnout ID does not exist
Ce qui consomme quatre fois moins d'adresses.

Ceci est extrait de la documentation du Git de DCC++
Dans ces colonnes a été décrit un décodeur (de l'un ou l'autre type suivant le programme de Rudy Boer mais plutôt orienté aiguillage) utilisant un Nano.
http://forum.locoduino.org/index.php?topic=566.msg6240#msg6240

Attention, j'ai moi-même fait la confusion entre les deux programmes, donc vérifier avant de mettre en œuvre.

[Armoricain]

Merci a tous deux.
Je vais reprendre doucement la lecture de toutes les sources que j'ai a ma disposition pour mieux comprendre.
Je devrais pouvoir contourner le probleme en utilisant un decodeur dont le code lit tous les paquets circulant, pas seulement ceux concernant l'adresse/CV qui est la sienne.
Dans tous les cas, j'ai du pedaler en arriere de quelques pas: mes 2 decodeurs prototypes ne lisent plus les paquets aujourd'hui, et echanger les 6n137 n'a rien resolu.
Je reviendrai!

[Dominique]

Regardes ici :

http://forum.locoduino.org/index.php?topic=556.msg6346#msg6346

La solution est une petite capa à ajouter.

[Armoricain]

Bonjour Dominique.
Merci pour le lien, je vais l'etudier pour apprendre un peu plus au sujet de l 'electronique.
regardant la capa, J'ai installe d'origine un capaciteur ceramique -en 220pf je crois- en parallele a ma diode 1n4148 apres la resistance 1K et il fonctionne (normalement) a merveille.
J'avais trouve un sketch assez sympa ici: https://sites.google.com/site/sidloweb/elektrika/16-dekoder-pro-15-serv
et m'en etais inspire pour creer mon sketch sur Eagle et fabriquer mes circuits imprimes.
Regardant mon souci de decodeur, c'etait un peu plus simple et embarassant:
Mon souci etait un fil dcc pousse trop loin dans un 'sucre' de raccord (sur mon banc de test) et pince sur sa gaine isolante.  Probleme resolu apres avoir epuise mon vocabulaire d'expletifs et pris une pause.
Finalement, J'ai commence a bidouiller le sketch 'DCC monitor' de Mynabay en m'appuyant sur des exemples provenant d'un peu de partout, y compris l'exemple mentionne ci-dessus. Je ne connais rien a C++, C#, java, python etc, mais comme cela je suis bien plus a l'aise pour faire nimporte quoi. Mon code ne sera certainement pas beau, mais si il marche, je serai satisfait.
J'ai essaye de me baser sur des travaux plus complets comme ceux de Geoffrey Bonza (https://model-railroad-hobbyist.com/blog/geoff-bunza)
Mais son code me passe tres haut au dessus de la tete pour l'instant.
Note additionelle: Je viens de trouver le code dont j'avais besoin deja fait et operationnel ici : https://rudysmodelrailway.wordpress.com/ , Dans le fichier Arduino_DCC_S88.zip. Le nom du fichier est RB_DCC_decoder_Servo.ino, au cas ou un autre debutant serait interesse.

[msport]

Bonjour,
désolé de ne pas avoir été plus précis pour les décodeurs de Rudy, mais c'est bien de ceux-là que je parlais.
Bien voir qu'il y en a un pour les accessoires et un pour les aiguillages.

[Armoricain]

Merci et desole MSport.
J'avais effectivement ma reponse depuis un moment.
Ma lecture du lien etait trop superficielle, j'avais juste regarde la piece attachee visible en haut du premier message.(pour la carte) . Sketch trouve en bas de la reponse #4.

[msport]

Bonjour,
pour lancer des ordres aux décodeurs d'accessoires (en l'absence de tout matériel du commerce), j'ai adapté la throttle de D Bodnar :
http://forum.locoduino.org/index.php?topic=367.msg3482#msg3482
Depuis j'ai intégré dans une seule manette locos et  aiguillages mais je n'ai pas encore publié le programme correspondant (qui intègre une adaptation de D Bodnar). Je ne suis pas actuellement à la maison, mais j’essaierai d'y penser.

[Armoricain]

Merci encore msport!
Je suis effectivement tres interesse par les manettes sans fil.
Mes yeux me font la tete regardant la resolution du schema du decodeur. Je n'arrive pas a lire/deviner certaines valeurs. Je vais regarder si ce schema est egalerment present sur RudysModelRailway.wordpress.com. EDITION: Apres une bonne nuit de sommeil, j'ai realise que ce sont les schemas de Dave Bodnar a la base.

Ceci etant dit, mon but principal reste cependant l'automatisation totale de chaque reseau.
Pour mode de controle principal dans ce projet actuel, j'envisage un tableau de bord facon "processing" (cf le controlleur DCC++ de Gregg Berman).
J'ai besoin de tester dans un procha avenir si un raspberry 3b+ peut faire tourner processing sous un linux/raspbian serieusement denude/depouille (Si c'est le cas, j'envisage un ecran tactile capacitif de 1024x600 en 7").
Si la solution n'est pas satisfaisante, j'ai un autre plan que je commence a tester en ce moment.

[Dominique]

Faire tourner Processing dans Raspbian : on l’a montré à Orléans et je peux te dire que le RPi tient bien la route.

http://forum.locoduino.org/index.php?topic=515.msg7000#msg7000

[Armoricain]

Merci Dominique! Plus de lecture au coin du feu pour moi, on dirait 
Je n'arrive pas a me decider pour ce qui est des commandes/souris/manettes. J'aime le minimalisme visuel, et j'aime tout autant l'idee de pouvoir controller tout mon reseau depuis la paume de ma main (aiguillages, signaux, animations, sons ambiants etc). Je vais devoir construire un exemplaire de chaque...
Et je vais oublier opur un moment que mon objectif principal etait suppose d'automatiser tout cela...