LOCODUINO
Parlons Arduino => Le logiciel DCC++ => Discussion démarrée par: Fabien73 le août 05, 2019, 04:39:56 pm
-
Hellou out le monde
Je rencontre un problème de retour des infos de décodeur de différente marque sous JMRI.
Je voudrais donc savoir comment les infos des décodeurs sont renvoyé à la base station. Faut il impérativement un module de controle de courant comme un MAX471 ou le retour se fait autrement.
Pour info je suis encore en mode test de la basestation DCCpp.
Cordialement
-
Le retour d'info peut prendre plusieurs formes. Avec les shields prévus par la version originale, c'est eux qui retournent l'info. Avec un LMD18200 par exemple, une broche existe dessus pour retourner la consommation, mais elle n'a pas été jugée fiable. Donc dans tous les cas sans shield, on recommande un circuit comme le max471 qui fait très bien ce boulot. A noter qu'avec deux voies, une principale et une programmation, il faut deux circuits.
La problématique de la reconnaissance telle qu'elle est codée dans DCC++, c'est que la valeur utilisée comme seuil pour identifier une consommation est fixée arbitrairement à 300 alors qu'elle devrait sans doute varier en fonction de facteurs comme la consommation effective du décodeur et du moteur de la loco, la puissance de l'alimentation... C'est pourquoi dans la fonction begin des CurrentMonitor dans la bibliothèque DCCpp, j'ai ajouté un argument optionnel pour cette valeur. Si elle n'est pas précisée, on reste à 300, sinon on peut fixer ce que l'on veut.
Par contre, je n'arrive pas à m'expliquer comment font les centrales du commerce pour que leur reconnaissance marche dans beaucoup plus de cas que sur DCC++...
-
Je te remercie pour ta réponse très claire->Cool
Après sur les centrales du commerce, il y a peut être deux lectures de la conso de courant. Une pour la protection des court-circuit et une autre qui gère juste le conso moteur pour le retour info décodeur mais avec une valeur de lecture plus basse.
-
Si la lecture du décodeur renvoi un échec, on peut imaginer une itération qui fasse varier la variable du seuil progressivement jusqu'à une une lecture sans échec ou qui sort de l'itération après un nombre arbitraire de tentatives infructueuses.
-
Après une petite plongée dans le code de la lecture/écriture des CVs, il se trouve que ce n'est pas la valeur de 300 qui est utilisée pour la discussion avec les décodeurs, mais un define ACK_SAMPLE_THRESHOLD qui représente une valeur pondérée du delta entre un état de base de la broche analogique, et un état avec une consommation observée.
Cette valeur est par défaut fixée à 30, et il faudrait peut être la diminuer pour certains couples décodeur/moteur qui sont moins gourmands. Je vais étudier la possibilité de la fixer par programme sans toucher au fichier PacketRegister.h qui la définit aujourd'hui.
-
En tout cas merci les chefs
ça fait plaisir de voir des personnes qui répondent à un newbi comme moi.
-
Merci Thierry,
C'est une piste que je vais tester dès que possible, mais malheureusement pas sans doute avant une quinzaine de jours.
-
Pour améliorer les choses, je viens de pousser une version 1.3.7 sur le LocoHub avec une fonction pour pouvoir fixer cette valeur initialement à 30, plus quelques amélios pour gagner de la mémoire programme...
Au passage, il est devenu possible de faire quelque chose comme ça dans le setup d'un ino :
int locoId = -1;
byte ackValue = DCCpp::ackThreshold; // nouvelle valeur de la 1.3.7, à 30 au départ.
while(locoId == -1)
{
locoId = DCCpp::identifyLocoIdMain();
if (locoId == -1)
{
ackValue--;
DCCpp::ackThreshold = ackValue;
Serial.print("ackValue reduced to ");
Serial.println(ackValue);
}
}
Ce code va chercher à identifier la loco présente sur le réseau, et si il n'y arrive pas, il va réduire la valeur de ack et refaire un essai.
A noter qu'en debug j'ai ajouté des affichages pendant la lecture pour mieux comprendre ce qui se passe. Il faut aussi comprendre qu'un décodeur qui envoie un 'ack', c'est une machine qui a un soubresaut. Et sur ma petite Bachmann quasi neuve en N, chaque vibration fait perdre le contact électrique à la loco... Il faut appuyer dessus avec un doigt pour que ça remarche... Bref, c'est moyennement facile de faire quelque chose de fiable à 100%...
-
Bonjour Thierry,
Je n'ai finalement pas pu attendre et j'ai dès ce matin cherché à vérifier si le changement de la valeur de ACK_SAMPLE_THRESHOLD solutionnait le problème.
J'ai fait le test sur un autorail (X3800 Mistral) en HO donc pas de problème de prise de courant sur les rails.
Je n'avais pas beaucoup de temps alors je n'ai pas pu faire une véritable itération comme tu l'as fait. J'ai simplement modifié la valeur de ACK_SAMPLE_THRESHOLD et chargé le sketch à chaque fois puis fait le test.
Je n'ai testé que les valeurs suivantes : 15, 10, 1 et 45. Mais je n'ai rien obtenu de résultat positif. Ma configuration était fonctionnelle puisque j'ai aussi testé avec succès sur un décodeur Marklin.
Je vais continuer peut être demain en testant toutes les valeurs de 30 à 1 !
Un peu déçu donc pour le moment mais toutes les combinaisons n'ont pas été testées donc il reste de l'espoir.
Bien amicalement.
Christophe
-
Bonjour les gars,
J’ai aussi des décodeurs récalcitrants (CT Electronic je crois) est j’ai testé pas mal de seuils de mesure, avec DCC++, avant DCCpp, mais sans succès. Cette question est récurrente sur le forum DCC++ et il semble qu’il n’y ait aucune avancée sur ce sujet.
Pourtant d’autres centrales y parviennent parfois mais j’en doute un peu car beaucoup de modélistes semblent programmer des décodeurs sans relecture des CVs, simplement en testant si ça marché.
Amicalement
Dominique
-
Bonjour Dominique,
Entre les enduits dans la cuisine et la peinture des chambres, j'ai pris encore un peu de temps pour tester les seuils. De 1 à 16 avec un pas de 1 mais aucun résultat ! J'ai même testé 0 qui bien sûr donne quelque chose mais totalement faux.
Je crois que la piste est dans le hard et comme je l'avais déjà indiqué, j'ai vu que l'on pouvait placer une resistance. Mais laquelle ? Quelques Ω, quelques dizaines, quelques centaines ?
-
J'ai lu 120 ohms en parallèle sur la voie mais je n'ai eu que des retours négatifs.
A tenter : à mettre en parallèle directement avec le moteur ...
-
Le plus simple ne serait-il pas de mettre une résistance sur la sortie moteur du décodeur. Des essais à faire qui nécessitent de démonter le decodeur ?
-
J'ai vu sur une notice qu'on pouvait mettre une résistance de 45ohm en serie
-
Avec quel objectif ?
Je veux dire : pourquoi la notice propose de mettre une résistance en série ?
La valeur de 45 ohms est curieuse.
Même sur du N, ça consomme quasiment toute la tension disponible.
L'idée serait peut-être de la mettre à la place du moteur ?
-
Voilà ce que j'ai observé lors d'une réponse d'un décodeur sur interrogation d'un CV. On a de l'ordre de 0,3V pendant 5 à 6 ms pour chaque impulsion : faut pas le rater !!!
-
ben lorsque j'ai pris une ptite loco Arnold, sur la notice il y a un ptit schéma avec une résistance de 47ohm en série
-
Tu peux être plus précis ? Joindre copie de cette notice ?
-
ben lorsque j'ai pris une ptite loco Arnold, sur la notice il y a un ptit schéma avec une résistance de 47ohm en série
Si c'est une résistance montée d'origine, on peut supposer qu'il s'agit d'un moteur 5V avec une résistance d'adaptation pour 12V -??? Mais avec le schéma ce serait plus facile que de deviner.
-
je vous mets en PJ la notice du décodeur.
-
Merci pour la doc. Il faut maintenant tester. J'ai cependant à priori un petit doute car la doc concerne un LokPilot (v4.0) et personnellement je n'ai jamais rencontré de problème avec ces décodeurs.
Mais au point ou nous en sommes, c'est à dire sans le moindre début de solution, tout est bon à prendre.
-
Du coup je suis passé avec des ACS712 pour le contrôle des courants.
Mais j'ai bien un retour maintenant mais farfelu je trouve.
JMRI me donne une adresse de loco de 127 alors que la central intellibox me donne 1.
-
Voilà ce que j'ai observé lors d'une réponse d'un décodeur sur interrogation d'un CV. On a de l'ordre de 0,3V pendant 5 à 6 ms pour chaque impulsion : faut pas le rater !!!
Le module MAX471 que j'utilise a une résistance de 2000 ohms standard qui donne 1V/A en sortie.
0,3V correspond donc à 300 mA, classique pour le N.
Une résistance de 47 ohms ne changera pratiquement rien ici puisqu'elle va entrainer une chute de tension de 1,5V donc de l'ordre de 10%.
J'imagine que le but est de protéger le décodeur contre des manipulations hasardeuses.
A essayer aussi le condensateur de 22 pf à 270 pF qui fait merveille pour le circuit décodeur de Mynabay.
-
Je suis en "train" de tester un booster très économique et puissant (6 à 8A), le TLE9201SG avec une mesure de courant toute simple : une résistance de 40mΩ et un ampli de mesure de courant ZXCT1086, selon ce schéma suggéré par Jean-Luc.
(http://forum.locoduino.org/index.php?action=dlattach;topic=797.0;attach=2392;image)
Le montage est piloté par un Nano qui contrôle le TLE9201 par les pin :
- 3 : PWM
- 10 : DIR
- 7 : DIS (à LOW)
Pour tester , j'utilise une version très expurgée de DCC++ à l'aquelle j'ai ajouté l'interrogation de l'adresse (courte et longue) du décodeur.
J'ai ajouté une sortie print() du courant mesuré dans la fonction CurrentMonitor::check()
J'ai fait quelques mesures de courant avec ce montage, en affichant la valeur de la variable current obtenue par lissage exponentiel de la lecture sur la pin A0 reliées à la sortie "current sense du montage :
current = analogRead(A0) * 0.01 + current * 0.99
Cela donne ces valeurs (lues toutes les secondes) : 5.28 5.14 5.16 4.79 4.83 4.89 5.06 4.82 5.49 5.39
Ensuite, le lance une demande de lecture de l'adresse DCC d'une petite loco (autorail Ganter en N) : <rm123|123|1 24> : succès ! j'obtient l'adresse 24 (qui est la bonne réponse).
Ensuite je fait rouler la machine : <T1 50 1> 3.40 22.53 26.85 36.03 43.54 46.84 45.02 41.78 42.24 42.34 39.94 Toujours le courant lissé lu toutes les secondes.
Le courant traversant la résistance de 40mΩ est I. Le gain de l'ampli est 50.
La tension sur A0 est I*0,040*50 = 2*I
Les valeurs lues sur A0 correspondent à peu près à 5mV par unité (1023 pour une tension de 5V) (voir article http://www.locoduino.org/spip.php?article57 (http://www.locoduino.org/spip.php?article57))
En roulant ma loco indique 45 sur A0 donc 45*5 = 225 mV, soit un courant mesuré I = 225/2 = 112,5 mA.
A l'arrêt (avant la lecture de l'adresse) on lit 5*5=25mV soit I =12,5mA (c'est la consommation du décodeur dans la loco)
Je pense que tout ceci est cohérent et ce montage ouvre des perspectives :D
Le montage en CMS (voir photo) occupe 5cm par 2cm et est l'équivalent d'un LMD18200 (double intensité) et d'un Max471 (non limité à 3A mais à 6A).
Amicalement
Dominique
-
Bonjour tout le monde.
Je reviens sur mon capteur de courant qui est un ACS712 20A avec une tension de 2.5v sans conso de courant et un ratio de 100mV/A.
Y a t'il des changements à faire dans le programme DCC++?.
Par avance merci a tous.
-
Deux changements : la sensibilité est 10 fois moindre : 100mV/A au lieu de 1V/A et l'offset de 2,5V au lieu de 0.
Le code donné en exemple est ci dessous.
Bonne chance.
-
merci bien je vais essayer de voir ce que je peux faire
mega cool
-
Bonjour tout le monde.
Je reviens vers vous car j'ai besoin d'aide pour la programmation de DCCpp pour fonctionner avec un ACS712 20A.
C'est surtout sur la voie de programmation des CV que ça va me poser problème car je n'ais plus la même sensibilité ni le même offset.
En parcourant le forum j'ai vu que des personnes l'utilisaient aussi, mais à aucun moment ils ne parlent des modifications apportées à DCCpp.
Par avance je vous remercie des infos que vous pourrez me fournir.
-
Dans un premier temps, tu essayes : probable que ça va marcher car DCCpp s’adapte automatiquement au niveau de base.
-
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,
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 !
-
Il est intéressant de comparer DCCpp à des centrales du commerce. J’ai une Marklin MS2. Si elle détecte un décodeur alors que DCCpp ne détecte pas, alors je vais noter ce cas et regarder de plus près.
-
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 (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 !
-
Ah, un grand merci à toi Thierry. Je m'en vais tester cela au plus tard ce WE. Si cela pouvait fonctionner ce serait un vrai plus.
Bien amicalement.
Christophe
-
Merci Thierry,
Je vais tester cela dès que possible avant de se voir dans 8 jours.
Amicalement
Dominique
-
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 (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 !
J'ai fait la modification dans ma fonction readCV_Main() (remplacer "loadPacket(0,resetPacket,2,1);" par "loadPacket(0,bRead,3,1);") qui sert à trouver l'adresse d'une loco sur vie principale :
et voilà ce que ça donne :
- avec mon petit autorail Ganter (je sais pas quel type de décodeur s'y ytrouve) : pas de changement ça marche comme avant !
- avec mon autorail ABKJ Etat (décodeur CT Electronic) : ça ne marche toujours pas (snif !)
je vais tester mes autres locos...
-
L'idée serait peut-être de la mettre à la place du moteur ?
Oui, de toute évidence ;D
-
Désolé, j'avais fait les tests également mais je n'avais pas répondu, sans doute par ce que dépité ! En effet, comme Dominique, ça n'a absolument rien changé !!!
-
Encore un mystère de plus :
sur un petit locotracteur V36 de LENZ, tentative de reset du décodeur avec DCCpp sans résultat alors que les CV se modifient.
passage sur une z21 de ROCO : reset réussi du premier coup.
J'ai constaté qu'avec la z21 l'opération s'est faite en deux temps (deux frémissements rapprochés)
Conclusion, ce n’est pas qu'une question de timing et de tension (z21 = 18V), mais aussi de protocole ?
-
Tout à fait d’accord.
Il faut utiliser l’oscilloscope à mémoire maintenant pour avancer (je n’en ai pas malheureusement)
-
noël approche ;)