projet centrale "LaBox" wifi DCC++ Can

[AmadeusHF]

La mesure des timings réalisée sur un Arduino est relative : on ne peut pas la prendre comme référence.

Le traitement des interruptions diffère d'une architecture CPU à une autre, et les interruptions s'opposent les une aux autres, avec un traitement asynchrone dans certains cas.

Pour analyser le signal on doit utiliser une broche IN et réagir aux fronts via une interruption...dans laquelle on va lire l'horloge via "micros()", cette horloge dépendant elle-même d'une interruption (le timer 0, qui gère l'horloge système).

Si l'entrée DCC déclenche alors que le CPU est en train de traiter une autre interruption (typiquement TIMER 0), alors on traitera le déclenchement quelques uSec après sa survenance réelle, et comme on ne peut pas capturer l'horloge précisément au moment ou le signal survient, on introduit du "jitter".

Le seul moyen de valider les timings du signal généré c'est l'oscillo.

A noter que ce que je dis est moins vrai en génération de signal, et c'est une bonne chose.

En effet, pour générer le PWM on produit une interruption au moment du DEMI BIT, donc bien avant la fin de la double demie-impulsion. On charge les registres PWM avec les valeurs du prochain bit qui seront prises en compte lors du reset du compteur, c'est à dire précisément à la FIN du bit, sans décallage. C'est une mécanique purement hardware synchrone....donc tant que le chargement des registres va assez vite, on a pas de jitter sur la génération du signal qui reste nickel (à la variation de l'horloge du CPU près).

C'est une bonne chose car les décodeurs doivent concilier avec à la fois les imprécisions de mesure liées à leur propre architecture ainsi qu'avec les défauts du signal lié à la transmission fluctuante via les rails....donc il vaut mieux avoir un signal très propre à la source pour simplifier la vie des décodeurs.

Pour info, avec un NANO EVERY (Atmega 4809 ou 4808) tournant sur oscillateur interne à 16 Mhz, j'arrive à un décodage de 100% du flux de trames avec les centrales du marché...mais j'ai systématiquement un bit de perdu : le premier bit de préambule qui suit la réception d'une trame ! Le temps supplémentaire nécessaire à mettre la trame reçue en file d'attente pour son traitement introduit un défaut de mesure sur la demie-alternance en cours de transmission, qui fait que la symétrie du bit n'est plus bonne et sort de la tolérance.

C'est sans conséquence puisque d'une part c'est à ça que sert le train de préambule : à gérer la synchro ET à absorber les fluctuations....et que par ailleurs la norme spécifie qu'un décodeur n'a pas à recevoir deux trames à moins de 25 ms d’intervalle (trames qui lui sont destinées)....donc même si je perdais la trame suivante, ce qui n'est pas le cas, je serais dans la norme. Là je perd le premier bit de préambule de la trame suivante mais comme il faut en émettre au moins 14 et que le décodeur doit quant à lui en recevoir au moins 10....j'arrive toujours à récupérer la trame.

Enfin bref : attention à l'analyse de trame réalisée via Arduino. Le contenu, ok. Les timings sont quant à eux intrinsèquement entachés d'une légère erreur de mesure au niveau de l'heure de chaque front, ce même si l'Arduino ne fait rien d'autre que mesurer....

[AmadeusHF]

@Trimarco : dans ton analyse, tu exclu le bit de fin de paquet du préambule suivant.
La norme spécifie le contraire. Note de bas de page 1 du 9.2 de la spec :

The Packet End Bit may count as one of the preamble bits of the subsequent packet if there are no inter-packet bitsfrom an alternative command control protocol.  The DCC bitstream must continue for an additional 26 μS(minimum) after the packet end bit.

[Dominique]

Le sujet du "sniffer DCC" est très important car nous avons besoin d'un outil pour vérifier ce qui fonctionne bien et pour comprendre ce qui fonctionne mal.

Cela faisait longtemps que je creusais cette question sans vouloir engager de dépenses pour un oscilloscope sérieux, question de budget familial comme tout le monde..

Finalement je me suis arrêté (pour le moment) sur celui de DCC++EX dénommé "DCCInspector-EX" que je mets en PJ ci-dessous.

Il tourne sur un ESP32 et sort les résultats conformes au sniffer de Rudy Boer soit sur le moniteur, soit sur une page Web qu'on peut récupérer sur un navigateur en wifi.
msport a en chantier un circuit imprimé qui nous sert de banc de mesure en ce moment. Evidemment la section wifi-serveur html n'améliore pas la précision de la mesure, mais j'ai fait quelques comparaisons entre Labox et d'autres centrales comme une DCCpp sur Nano/Uno, et ma MS2 Marklin: ces deux dernières montrent des timings irréprochables, ce qui prouve que cet outil peut être utilisé avec confiance.



Comme les mesures de timing sont basées sur l'Input Capture, je pense que c'est la méthode la plus précise et l'ESP32 est bien plus rapide que les AVR.

Dans ce programme j'ai ajouté une commande au moniteur: x/X qui permet d'afficher tous les paquets, plutôt qu'un seul paquet par catégorie.

Votre avis nous intéresse car, avec msport, on pourrait finaliser un circuit imprimé et présenter ce projet dans un article sur le site rédactionnel. Merci d'avance.

[trimarco232]

Bonjour,
pour ceux que ça intéresse, l'analyse logique à 10 balles :
- acheter un clone salae ... + les petites pinces qui vont bien (que j'ai soudées pour qu'elles aillent mieux) + des rallonges dupont de qualité
- télécharger et installer le logiciel salae, c'est juste pour avoir le driver
- télécharger et installer PulseView ; on peut voir les bits à ce stade
- télécharger "sigrok-DCC-Protocoll" ; extraire le dossier "DCC" et l'ajouter dans le repertoire "decoders" ; chez-moi :C:\Program Files\sigrok\PulseView\share\libsigrokdecode\decoders
- dans la config du decoder, dans "01 or 10", choisir "10"

(aucune raison que le sniffer à base d'ESP32 ne fonctionne pas parfaitement)

[Dominique]

Bonjour,
pour ceux que ça intéresse, l'analyse logique à 10 balles :
- acheter un clone salae ... + les petites pinces qui vont bien (que j'ai soudées pour qu'elles aillent mieux) + des rallonges dupont de qualité
- télécharger et installer le logiciel salae, c'est juste pour avoir le driver
- télécharger et installer PulseView ; on peut voir les bits à ce stade
- télécharger "sigrok-DCC-Protocoll" ; extraire le dossier "DCC" et l'ajouter dans le repertoire "decoders" ; chez-moi :C:\Program Files\sigrok\PulseView\share\libsigrokdecode\decoders
- dans la config du decoder, dans "01 or 10", choisir "10"

(aucune raison que le sniffer à base d'ESP32 ne fonctionne pas parfaitement)

J'aimerai bien mais sur Mac, point de soft possible

[Dominique]

D'ailleurs l'auteur du sniffer ESP32 a constaté aussi des glitch dans la génération du code DCC sous interruptions:

Example ESP32 Monitoring DCC++ EX 3.0.4 (5V, 6N137 Optocoupler, Main Track, Strict NMRA)

When the DCC signal is generated within interrupt handling code within the Command Station, the accuracy of the signal cannot be maintained to such a high accuracy. Below, we can see that the pulse length varies over a range of around 14us.
This would mean that some packets are outside of the NMRA specification and may be ignored by the loco decoder. The analyser reports 81 packets as out of spec and 351 in-spec, i.e. around 20% are out of spec. This is not normally a problem on a DCC layout as each packet is transmitted at least three times. If one packet doesn't get through, the probability is that one of the retransmissions will!

The half-bit counts are turned off here, but CPU monitoring within the analyser is turned on.

-
Bit Count/4 sec=24865 (Zeros=10167, Ones=14697), Glitches=0
Valid Packets=351, NMRA out of spec=81, Checksum Errors=0, Lost pkts=0, Long pkts=0
0 half-bit length (us): 115.9 (109-122) delta < 14
1 half-bit length (us): 57.5 (51-64) delta < 14
IRC Duration (us): 2.2 (1-10),  CPU load: 27.5%
--
Loc 7552 Fwd128 33      11011101 10000000 00111111 10100010
Loc 3 Fwd128 25         00000011 00111111 10011010
-

[trimarco232]

(... !)
J'aimerai bien mais sur Mac, point de soft possible

c'est pour cette raison, entre autres IDE exotiques, que je me coltine windows aussi

[trimarco232]

@Trimarco : dans ton analyse, tu exclu le bit de fin de paquet du préambule suivant..

oui, je n'avais pas non plus encore incorporé, au stade où j'ai remis le projet dans une boîte, le calcul de la cheksum 
terminer le paket dcc par le 1er bit du preamble du paket dcc suivant est une bonne idée, si on utilise le pwm : ainsi, si le soft n'est pas prêt pour donner le paket suivant au timer, celui-ci continue tout seul à générer des bits dcc 1 entiers , ce qui n'est pas péjorant

[msport]

... pour ceux que ça intéresse, l'analyse logique à 10 balles ...

Super, on va pouvoir faire passer un test PCR au sniffer.

L'interface à base de Mynabay (et ses adaptations), apporte son lot de délais (1K / 1nF mais j'ai fait plus light (1k / 100pF)).
Sur une période complète, ça n'intervient pas.
https://github.com/DCC-EX/DCCInspector-EX#readme

[AmadeusHF]

Dans tout ça il faut largement moduler les "vérités" qui sont lancées ici ou là...

Le traitement des interruptions sur ESP32 donne lieu à une commutation de thread de RTOS et à l'activation d'un contexte....opération relativement lourde d'une part, mais aussi totalement soumise au scheduler de l'OS.
On parle de RTOS donc on est pas trop mal loti, mais il est clair que ça sollicite un mécanisme pas totalement controlé.

Pour générer un flux continu de données contraintes temporellement, on aura plus intéret dans ce cas précis à lancer une tache avec des paramètres de scheduling spécifiques indiquant justement au scheduler que le timing doit etre stricte : c'est à ça que sert RTOS. Une priorité élevée pourra suffire à obtenir un résultat de qualité...possible qu'on arrive au même résultat avec un paramétrage fin de la tache que l'on met en "sticky" pour le gestionnaire d'interruption, mais pas sur...

En revanche, sur un Atmega ou autre ce n'est pas du tout pareil : en dehors du cas ou on a bloqué les interruptions explicitement via "cli", on aura un traitement immédiat d'une interruption déclenchée....sauf si une autre est déjà en cours de traitement.

J'ai traité à l'oscillo lors de mes tests plusieurs systèmes :

• Centrale Lenz LZV100
• Centrale Dgikeijs DR 5000
• Multimouse avec booster ROCO 10764
• Ma Base Station construite avec mon code + Arduino MEGA et carte de booster fournie par msport

Les signaux obtenus sur la Lenz, la DR5000 et la Base Station sont nickels et stables. J'ai d'ailleurs fourni il y a quelques temps une capture à l'oscillo du signal issu de la Base Station.

Les signaux issus de la Multimaus + booster ROCO sont propres dans l'ensemble, mais la centrale insère systématiquement une perturbation (ou un signal à destination d'un autre dispositif, or de la norme DCC). Globalement le décodage "passe au dessus" mais cela fait appel implicitement à un contrôle stricte des bits...car si on "ouvre un peu la tolérance" pour le décodage (par rapport aux spécifications DCC), comme le fait par exemple la lib NMRADCC, on aura un décodage de trames bidons....qui sera ensuite filtré par un mauvais checksum de paquet, mais pas toujours ! (J'ai eu le cas en tests.....)

Je n'ai en revanche pas essayé à ce jour de génération de signal sur ESP32....je n'ai que du décodage à traiter....mais ça peut venir demain, donc si vous voulez un coup de main pour quelques tests, n'hésitez pas.

Bon, tout ça pour dire que le problème ne vient pas du fonctionnement "sous interruption" de façon générale...mais du fait qu'on est sur un système d'exploitation qui "pollue" ce traitement...et que le code sous interruption utilisé sur un ATMEGA marche parfaitement bien, car dans ce cas on a un meilleur contrôle sur le comportement global du CPU.

[trimarco232]

Dans tout ça il faut largement moduler les "vérités" qui sont lancées ici ou là...
(...)
la centrale insère systématiquement une perturbation (ou un signal à destination d'un autre dispositif, or de la norme DCC)

si c'est le railcom, c'est dans la norme

vous voulez un coup de main pour quelques tests, n'hésitez pas.

(hs) j'ai une centrale à faire avancer, mais pour le coup de main il faudrait + que quelques tests ... (hs\)

[AmadeusHF]

Non ce n'est pas le cutout...j'ai bien entendu vérifié

[msport]

Non ce n'est pas le cutout...j'ai bien entendu vérifié

Des précisions seraient utiles : quelle marque, quel modèle ? quel contexte ?
Mais j'ai constaté qu'une z21 coupait complètement le signal DCC avant une interrogation de CV.

[AmadeusHF]

J'ai précisé au dessus Michel. Roco 10764 relié à une Multimous (à jour).

C'est un des tous premiers modèles de ROCO, bien avant la Z21.
Il y a de nombreuses centrales qui n'alimentent la voie de programmation que lors de l'envois d'une commande.
C'est le cas aussi de la Lenz que j'ai testé : en dehors d'une commande de programmation, la voie est coupée.

[msport]

La z21 (blanche) n'a qu'une sortie voie. Je vais regarder si il y a un contexte particulier où elle couperait le DCC (hors Railcom) sans y passer plus de temps que quelques trames ....
Dans la norme, un décodeur doit accepter un ZERO bit qui dure 10000 microseconds pour chaque demi-période alors qu'une station doit émettre des bits ZERO de moins de 12000 microseconds (période).
Reste à savoir ce que Lenz pourrait bien faire des bits ZERO longs.