projet centrale "LaBox" wifi DCC++ Can

[Thierry]

La ligne en question était le HMI.begin() du setup dans le .ino, mais ce n'est plus commenté normalement.

[Dominique]

En effet c'est ligne 70 de LaBox.ino

Code: [Sélectionner]

  //----------- Start HMI -------------
  boxHMI.begin();

A chaque nouvelle version de la bibliothèque il vaut mieux repartir de l'exemple LaBox dans le dossier exemples de la bibliothèque.

A noter que la bibliothèque LaBox a besoin des autres bibliothèques (listées dans la doc page 23) nécessaires pour réaliser une compilation avec succès :
"Adafruit_GFX"
"Adafruit_SSD1306"
"OneButton"
"ArduinoJson"
Ces dernières bibliothèques sont installables par l'IDE Arduino (menu Croquis/Inclure une Bibliothèque/Gérer les bibliothèques).
Je fais également leur mise à jour au fur et à mesure des versions Labox à tester.

[Dominique]

J'ai fait un nouveau test de lecture d'adresse de ma locomotive d'adresse 18 : seule la lecture du CV29 est tentée et échoue à chaque fois.

Code: [Sélectionner]

readCVraw : start reading cv 29
Bit  : 0, ACK   , samples : 24, gaps : 1, max : 32, start : 22992us, duration : 1006us
Bit  : 1, ACK   , samples : 95, gaps : 1, max : 33, start : 94004us, duration : 1008us
Bit  : 2, NO-ACK, samples : 101, gaps : 0, max : -112, start : 0us, duration : 0us
Bit  : 3, ACK   , samples : 87, gaps : 1, max : 37, start : 86134us, duration : 1003us
Bit  : 4, NO-ACK, samples : 100, gaps : 0, max : -112, start : 0us, duration : 0us
Bit  : 5, ACK   , samples : 86, gaps : 1, max : 33, start : 84885us, duration : 999us
Bit  : 6, NO-ACK, samples : 100, gaps : 0, max : -112, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 101, gaps : 0, max : -112, start : 0us, duration : 0us
Verif:  , NO-ACK, samples : 100, gaps : 0, max : -119, start : 0us, duration : 0us

Je ne recopie pas toutes les tentatives qui sont toutes différentes (les bits ACK ne sont pas au même endroit).

Finalement en essayant 5-6 fois et en appuyant avec le doigt sur le loco, son adresse 18 apparait enfin, mais les bits du CV 29 me semblent bizarres (0 n'est pas normal) :

Code: [Sélectionner]

readCVraw : start reading cv 29
Bit  : 0, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 1, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 2, NO-ACK, samples : 100, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 3, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 4, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 5, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 6, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 100, gaps : 0, max : -113, start : 0us, duration : 0us
Verif:  , ACK   , samples : 27, gaps : 2, max : 32, start : 24938us, duration : 2003us
readCVraw : start reading cv 1
Bit  : 0, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 1, ACK   , samples : 16, gaps : 1, max : 35, start : 15027us, duration : 1002us
Bit  : 2, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 3, NO-ACK, samples : 100, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 4, ACK   , samples : 66, gaps : 1, max : 31, start : 64901us, duration : 1000us
Bit  : 5, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 6, NO-ACK, samples : 101, gaps : 0, max : -113, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 100, gaps : 0, max : -113, start : 0us, duration : 0us
Verif:  , ACK   , samples : 11, gaps : 2, max : 39, start : 8609us, duration : 1998us

J'apprécie la nouvelle logique de lecture des CVs. Quand le CV29 est validé, ça passe au CV1 (dans le cas des adresses courtes).
Ce qui est dommage c'est qu'après avoir "vu" l'adresse 18, la recherche recommence et échoue finalement.

J'aimerai savoir ce que signifie les valeurs affichées pour chaque bit...

[msport]

De mon coté, erreur de raisonnement, des causes différentes peuvent produire les mêmes effets ...
Ici c'était le bouton Select qui ne faisait plus contact.

Donc, mes locos bougent et font afficher imperturbablement 16383. (adresses 8 et 12)
Et à l'occasion la lecture finit par en faire partir une toute seule.

En PJ ce que voit le sniffer (3e/3)

[Thierry]

Suite au remarques, petite version 0.9.1 pour tenter d'améliorer les choses :

- La lecture affiche maintenant la valeur lue sur la console, ça n'y était même pas !
- Toute lecture de Cv, et pas uniquement celles faites par identifyLocoId(), provoque la mise en route DCC.
- Un délai de 50ms a été ajouté au cas où entre deux tentatives...
- Enfin le meilleur pour la fin, l'application Z21 permet maintenant de lire les Cvs en demandant à les lire sur la voie de programmation ! Bien pratique pour tester...

De mon côté, j'ai essayé ma vieille G2000 semble t-il équipée d'un décodeur Viessmann, une Class 66 Kato qui prétends avoir un décodeur Trix (?), et une Bachmann S4. Toutes les trois répondent, à des degrés divers. La lecture d'une Cv isolée par l'appli z21 marche mieux que l'identification par LaBox... Enfin la Bachmann veut aussi avancer dès qu'elle est sur les rails alors qu'aucune throttle n'est encore connectée ! A noter que les durées de ack sont bien plus conformes avec la Kato et la Bachmann... Bien plus que le décodeur Viessmann.

Pour Dominique, petite explication des affichages de lecture de bit   'Bit  : 0, ACK   , samples : 24, gaps : 1, max : 32, start : 22992us, duration : 1006us'  :

- samples : nombre de valeurs mesurées, généralement entre 100 et 102 lors d'un NO_ACK. La mesure est interrompue lorsque que la fin d'un ACK est détectée, donc le nombre de mesures est inférieur.
- gaps : parmi les mesures, nombre de celles qui ont dépassé le seuil.
- max : seuil le plus haut mesuré parmi les gaps. Rappelons que la valeur par défaut du ackThreshold est fixée à 30... La valeur est en relatif par rapport à la valeur de base relevée avant les mesures. Donc autour de 0 lorsqu'il n'y a pas de ack, et à ackThreshold plus un chouilla lors d'un ack.
- start: date de début du ack depuis le début de la boucle de mesures.
- duration : durée du ack.

A noter aussi que la Bachmann renvoie des valeurs d'environ 100, la Kato de plus de 200, tandis que la G200 monte à 450 ! Il y a peut être de grosses différences de consommation entre les modèles de décodeur, et/ou des moteurs des machines.
Peut être qu'en réduisant le seuil à 20 ou 25, on aurait plus de résultats à tester sur des machines peu puissantes.

[Dominique]

Je vais tester à nouveau le petit décodeur Fleischmann dans ma loco, sans doute en baissant un peu le seuil ackThreshold.

Pour une prochaine version, je verrai bien le processus de lecture s’arrêter quand le résultat est trouvé, sans recommencer une lecture.

[Thierry]

Oui, la lecture continue est causée par le menu, pas par la fonction d'identification... Je pense que ce n'est pas le bon événement qui est utilisé. Cedric ? Ton avis ?

[msport]

0.9.1 peu de changement pour moi, testé avec un "gros" moteur ROCO aussi. (255, 3, ERROR au milieu).

[Dominique]

J'ai testé la version 0.9.1 en ajoutant, dans l'exemple LaBox un petit moyen de faire varier le AckThreshold pour voir si la sensibilité change la lecture des CVs sans reverser le sketch à chaque changement:

il faut évidemment désactiver le throttleSerial dans le setup:

Code: [Sélectionner]

  //throttleSerial.begin();


Code: [Sélectionner]

void loop()
{
  boxHMI.update();
  DCCpp::loop();

  if (Serial.available()) {
    char inChar = Serial.read();
    if (inChar == '+') ackNewValue += 1;
    if (inChar == '-') ackNewValue -= 1;
    int old;
    old = DCCpp::setAckThreshold(ackNewValue);
    Serial.print("AckThreshold old ");Serial.print(old);
    Serial.print(" -> new ");Serial.println(ackNewValue);
  }
}
Je n'ai obtenu aucun résultat probant. Sur une dizaine d'essais je n'ai vu la lecture du CV 29 correcte (=6 dans mon cas) qu'une seule fois. Parfois, les bits lus sont bons mais la vérification échoue. Au total, la lecture des CVs 29 et 1 n'a jamais été correcte

Deux hypothèses :
1) Les commandes de lecture d'un CV (bit 8 fois et byte 1 fois par CV) n'arrivent pas à temps au décodeur dans la locomotive pour être exécutées.
Je pense que cette hypothèse est bonne car en posant un doigt sur ma locomotive, je la sens bien bouger à chaque fois qu'une réponse ACK a lieu. Par exemple :

Code: [Sélectionner]

readCVraw : start reading cv 29
Bit  : 0, NO-ACK, samples : 100, gaps : 0, max : 12, start : 0us, duration : 0us
Bit  : 1, ACK   , samples : 48, gaps : 13, max : 358, start : 34914us, duration : 13001us
Bit  : 2, ACK   , samples : 48, gaps : 13, max : 370, start : 34799us, duration : 13000us
Bit  : 3, NO-ACK, samples : 101, gaps : 0, max : 20, start : 0us, duration : 0us
Bit  : 4, NO-ACK, samples : 100, gaps : 0, max : 21, start : 0us, duration : 0us
Bit  : 5, NO-ACK, samples : 101, gaps : 0, max : 12, start : 0us, duration : 0us
Bit  : 6, NO-ACK, samples : 100, gaps : 0, max : 14, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 101, gaps : 0, max : 20, start : 0us, duration : 0us
Verif:  , NO-ACK, samples : 101, gaps : 0, max : 13, start : 0us, duration : 0us
end reading value:-1
Là j'ai senti 2 coups pour les bits 1 et 2 (c'est normal), mais rien pour la vérification.

Ici ça a marché et j'ai senti 3 coups sur le CV29, puis 3 sur le 1:

Code: [Sélectionner]

readCVraw : start reading cv 29
Bit  : 0, NO-ACK, samples : 100, gaps : 0, max : 16, start : 0us, duration : 0us
Bit  : 1, ACK   , samples : 48, gaps : 13, max : 344, start : 34914us, duration : 13000us
Bit  : 2, ACK   , samples : 48, gaps : 13, max : 341, start : 34796us, duration : 13000us
Bit  : 3, NO-ACK, samples : 101, gaps : 0, max : 16, start : 0us, duration : 0us
Bit  : 4, NO-ACK, samples : 100, gaps : 0, max : 15, start : 0us, duration : 0us
Bit  : 5, NO-ACK, samples : 101, gaps : 0, max : 18, start : 0us, duration : 0us
Bit  : 6, NO-ACK, samples : 100, gaps : 0, max : 11, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 101, gaps : 0, max : 14, start : 0us, duration : 0us
Verif:  , ACK   , samples : 32, gaps : 13, max : 349, start : 18596us, duration : 12996us
end reading value:6
readCVraw : start reading cv 1
Bit  : 0, NO-ACK, samples : 101, gaps : 0, max : 29, start : 0us, duration : 0us
Bit  : 1, ACK   , samples : 87, gaps : 1, max : 35, start : 85919us, duration : 999us
Bit  : 2, NO-ACK, samples : 101, gaps : 0, max : 30, start : 0us, duration : 0us
Bit  : 3, NO-ACK, samples : 101, gaps : 0, max : 27, start : 0us, duration : 0us
Bit  : 4, ACK   , samples : 53, gaps : 17, max : 378, start : 35904us, duration : 17000us
Bit  : 5, NO-ACK, samples : 101, gaps : 0, max : 31, start : 0us, duration : 0us
Bit  : 6, NO-ACK, samples : 101, gaps : 0, max : 28, start : 0us, duration : 0us
Bit  : 7, NO-ACK, samples : 101, gaps : 0, max : 29, start : 0us, duration : 0us
Verif:  , ACK   , samples : 32, gaps : 13, max : 364, start : 18978us, duration : 12996us
end reading value:18
Mais j'ai un doute pour le CV1 !

2) La lecture (série d'analogueRead ou équivalent) n'est pas centrée sur l'arrivée de l'impulsion de courant (6 ms, 60mA).
Cela peut se déduire des valeurs lues : quand le max est élevé (+ de 300), c'est bon, sinon (35 ci-dessus) c'est mauvais et cela se confirme en regardant la duration qui est faible et qui démontre que la plage de lecture doit être décalée par rapport à l'impulsion de courant (tout est "raduc").
Il me semble que cette hypothèse est aussi bonne !

Je pense qu'il faudrait élargir la plage de lecture (donc lire plus d'échantillons).
Ou enchainer plusieurs plages de lecture courtes comme je l'avais proposé dans les versions antérieures et choisir la meilleure plage. Si un bit est à 0, il n'y aura aucune plage valable de toute façon.
Je n'ai pas eu le temps de me replonger dans le code donc c'est une hypothèse personnelle
Mais les anciennes versions fonctionnent toujours bien sur cette fonction (2 exemplaires OK toujours en service)

[msport]

A titre de comparaison, ce qu'on voit au sniffer quand une multiMAUS + z21 interroge le CV1 d'une loco (CV1 = .

Et là, il faut alimenter le sniffer car la z21 coupe le courant en attendant une commande.

[msport]

Et avec "Une station DCC complète, polyvalente et économique avec JMRI " version UNO et GY-169 sur A1. DCCpp_UNO d’origine (DCC++) alimenté en 12v ou en 15V, lecture à 100% avec <R 1 123 123>.

[Dominique]

Est-ce que ce serait possible de traduire cet affichage en commandes et réponses de type NMRA :
- reset packet
- bit read
- iodle packet
- verify packet

Sachant que LaBox (et DCCpp) appliquent cette suite d'instructions :

Code: [Sélectionner]

       loadPacket(0, resetPacket, 2, 3);         // NMRA recommends starting with 3 reset packets
loadPacket(0, bRead, 3, 5);                // NMRA recommends 5 verify packets
// loadPacket(0, resetPacket, 2, 1);         // forces code to wait until all repeats of bRead are completed (and decoder begins to respond)
loadPacket(0, idlePacket, 2, 6);          // NMRA recommends 6 idle or reset packets for decoder recovery time

ret = RegisterList::checkAcknowlegde(i, channel, base);
En se focalisant sur ces types de paquets, on y verrait plus clair pour la lecture de CV.
Quand j'aurai reçu mes ESP32 je tenterai de faire ce décodage, mais pas tout de suite.. désolé !

[msport]

... beyond my skills !
mais la piste à suivre est là : https://rudysmodelrailway.wordpress.com/2015/10/23/dcc-sniffer-packet-analyser-with-arduino/

[Dominique]

Super, la piste est bonne 

[msport]

Version 2 :

https://github.com/cbries/modeling/blob/master/Arduino%20DCC/Arduino_DCC_S88/RB_DCC_Sniffer_v2/RB_DCC_Sniffer_v2.ino

Plus récent mais même inspiration :

https://github.com/DCC-EX/DCCInspector-EX

Je pense que le sniffer ne voit que les paquets de commande, il n'est pas équipé pour détecter les pics de consommation.