Messages

31

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 09, 2021, 09:41:18 am »

Meme dispositif de capture connecté à la sortie d'une DR5000

Code: [Sélectionner]

15188460:1:56:61
15188560:1:56:61
15188680:1:56:61
15188796:1:56:61
15188912:1:56:61
15189032:1:56:61
15189148:1:56:61
15189268:1:56:61
15189384:1:56:61
15189500:1:56:61
15189616:1:56:61
15189736:1:56:61
15189852:1:56:61
15189972:1:56:61
15190088:1:56:61
15190212:1:56:61
15190416:0:104:108
15190628:0:104:108
15190840:0:104:108
15191056:0:104:108
15191264:0:104:108
15191384:1:56:61
15191596:0:104:108
15191808:0:104:108
15191924:1:56:61
15192136:0:104:108
15192348:0:104:108
15192564:0:104:108
15192676:1:56:61
15192796:1:56:61
15192912:1:56:61
15193032:1:56:61
15193148:1:56:61
15193264:1:56:61
15193476:0:104:108
15193592:1:56:61
15193804:0:103:108
15193924:1:56:61
15194040:1:56:61
15194156:1:56:61
15194276:1:56:61
15194488:0:104:108
15194604:1:56:61
15194816:0:104:108
15194932:1:56:61
15195152:0:104:108
15195356:0:104:108
15195572:0:103:108
15195688:1:56:61
15195900:0:104:108
15196016:1:56:61
15196132:1:56:61
15196252:1:56:61
15196780:R:30:496
15196840:R:496:56
15196896:1:56:61
15197012:1:56:61
15197128:1:56:61
15197248:1:56:61
15197364:1:56:61
15197480:1:56:61
15197600:1:56:61
15197716:1:56:61
15197844:1:56:61
15197952:1:56:61
15198068:1:56:61
15198184:1:56:61
15198304:1:56:61
15198420:1:56:61
15198536:1:56:61
15198656:1:56:61
On a une "anomalie" (496) insérée entre le bit stop du premier paquet et le préambule du paquet suivant.
Ca ne perturbe pas le décodage néanmoins. Il s'agit du cutout railcom à priori.

Le signal reste dans les tolérances mais l'asymétrie des alternances est marquée.
A peu près 4uSec à chaque fois. La seconde demie alternance est plus proche du nominal de la norme que sur la mesure faite avec la LENZ.
Les timings sont néanmoins toujours constants.

32

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 09, 2021, 09:11:34 am »

Exemple de séquence, d'un préambule à un autre.

Timestamp(uSec)|bit|first pair|second pair

Code: [Sélectionner]

410281220:1:56:56
410281336:1:56:56
410281452:1:56:56
410281560:1:56:56
410281672:1:56:56
410281788:1:56:56
410281896:1:56:56
410282008:1:56:56
410282120:1:56:56
410282240:1:56:56
410282344:1:56:56
410282456:1:56:56
410282568:1:56:56
410282684:1:56:56
410282796:1:56:56
410282912:1:56:56
410283024:1:56:56
410283132:1:56:56
410283340:0:104:105
410283548:0:104:105
410283756:0:104:105
410283968:0:104:105
410284176:0:104:105
410284384:0:104:105
410284592:0:104:105
410284704:1:56:56
410284816:1:56:56
410285028:0:104:105
410285136:1:56:56
410285348:0:104:105
410285556:0:104:105
410285668:1:56:56
410285876:0:104:105
410286084:0:104:105
410286196:1:56:56
410286308:1:56:56
410286520:0:104:105
410286632:1:56:56
410286840:0:104:105
410287048:0:104:105
410287168:1:56:56
410287368:0:104:105
410287580:0:104:105
410287796:0:104:105
410287996:0:104:105
410288108:1:56:56
410288220:1:56:56
410288332:1:56:56
410288444:1:56:56
410288556:1:56:56
410288668:1:56:56
410288780:1:56:56
410288896:1:56:56
410289008:1:56:56
410289120:1:56:56
410289232:1:56:56
410289344:1:56:56
410289456:1:56:56
410289568:1:56:56
410289680:1:56:56
410289796:1:56:56
410289904:1:56:56
410290020:1:56:56

33

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 09, 2021, 09:09:50 am »

Ca ou autre chose....temps de commutation de la diode de redressement, caractéristiques propres au port INPUT de l'Atmega...

Dans les chiffres ci-dessus, j'introduit une légère correction : j'avais tronqué ma mesure de temps d'impulsion (calculée à 16 Mhz, donc 16 unités par uSec) au lieu de faire un ROUND plus approprié...
En faisant ce ROUND j'obtiens un léger décallage moyen d'une uSec vers le haut des valeurs :

56:56 pour les bits 1 qui, du coup, paraissent symétriques à la mesure.
104:105 pour les bits 0 qui eux le sont du coup un peu moins (j'avais 102:104) en tronquant.

Ca ne change pas le résultat final car dans tous les cas j'étais dans la norme, largement....mais en situation limite c'est mieux d'avoir un round qu'un trunc sur la mesure....en fait idéalement je devrais ne pas la toucher et comparer aux seuils DCC x 16....mais là c'est un choix d'implémentation logicielle sur l'étage suivant...

34

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 08, 2021, 08:18:17 pm »

Pour info, j'ai analysé le flux généré par une LENZ durant pratiquement une heure :

19.4 millions de bits générés
Aucun bit en erreur (timings 100% dans la norme)

Durée des demi-bits 1 : 55 et 56 ms, généralement 55 sur le premier et 56 sur le second.
Pas d'autre valeur mesurée.

Durée des demi-bits 0 : 103 et 104 ms. généralement 104 et 104, parfois 103 sur le premier demi-bit.

La mesure de temps utilise un Atmega 4808 configuré en INPUT CAPTURE sur deux canaux, un pour les alternances MONTANT / DESCENDANT, l'autre pour les alternances DESCENDANT / MONTANT. (Ce CPU ne sait pas capturer les deux sur un seul timer.

La mesure de temps est faite par des timers 16 bits cadencés à l'horloge système, soit 16 Mhz.
Les 3 "rejected pairs" rapportées par le résumé ci-dessous correspond à la recherche de synchro lors du démarrage du test....Il a fallu 3 demi-bits pour que le décodeur se synchronise correctement.

Code: [Sélectionner]

Current mode      :2
Running time      :2910592840
Valid bits        :19398649
Glitch            :0
Rejected pair     :3
Invalid packets   :0
Valid packets     :408783
Dropped packets   :0
Idle packets      :37162
Filtered packets  :334457
Processed packets :37162

35

Composants / Re : arduino nano : faut-il se dépêcher d'en acheter ?

« le: septembre 07, 2021, 12:07:24 pm »

Oui c'est un peu le problème avec l'univers STM : moins ouvert de base, moins bien supporté en dehors de leur propre environnement. Ca reste la grande force du monde ATMEL....

36

Composants / Re : arduino nano : faut-il se dépêcher d'en acheter ?

« le: septembre 06, 2021, 09:19:37 am »

Les aléas de composants sont une réelle difficulté quotidienne. Il y a plusieurs manières de gérer la question et, sincèrement, je crois qu'il faut mixer les approches pour gérer.

Nous avons laissé tomber le 328p des arduino pour deux raisons. La première est sa disponibilité incertaine effectivement. La seconde est son manque de RAM qui en fait un outil trop limité....Pour le même prix, tout en restant sur de l'Atmel, on peut faire mieux (exemple : 4808/4809 des Nano Every).

Stocker peut être jouable à un niveau personnel...mais ça pose tout de même la question de la portée d'un montage : si personne d'autre ne peut le réaliser parce que les composants sont indisponibles...on a choisi de notre côté de jouer la carte de la versatilité : pouvoir changer facilement le processeur par une autre référence, en cas de rupture d'appro.

Ca suppose de prévoir large, d'anticiper des implantations multiples sur le PCB ou de choisir des packagings compatibles...mais ça ne marche que dans une gamme donnée. Par exemple le 4808 et les 64A et B sont, à une broche près que l'on peut traiter à part, compatibles broches à broches.

La démarche est aussi vraie sur d'autres composants critiques : convertisseurs buck/boost, et meme les optocoupleurs....

Mais malgré tout on tombe facilement dans des impasses d'un mois sur l'autre....du coup il faut être agile et savoir changer rapidement son fusil d'épaule. Pas simple car le logiciel doit suivre !

De ce point de vue, travailler sur un framework relativement portable comme celui de l'Arduino permet de réduire les effets de portabilité du code...mais dès qu'on travaille sérieusement avec le hardware (timers...), c'est limité : il faut adapter à chaque fois de façon spécifique.

Bref, c'est une époque compliquée pour le monde des équipements électroniques !

37

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 03, 2021, 07:59:11 pm »

Est-ce que des tests différents ont été faits en augmentant la priorité du gestionnaire d'interruption qui traite le timer ?

38

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 03, 2021, 07:43:00 pm »

La dispersion existe mais tu as quand meme un sacré pic de valeurs à 58 et 59....Effectivement ça traduit probablement les fluctuations de réaction du code au regard du scheduler du système d'exploitation.

Il est vraissemblable que la seule solution propre pour éviter ça serait d'avoir un co-processeur esclave qui se charge uniquement de la génération du flux, sans possibilité d'influence de ce que fait l'ESP32.

Il faut aussi se poser deux questions liées à l'architecture de l'ESP :
1/ Stabilité de l'horloge et
2/ Mise en oeuvre des fonctions d'économie d'énergie (qui intrinsèquement ralentissent les CPU)....

39

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 03, 2021, 05:36:19 pm »

Note aussi que tu as reçu 464 paquets pour 463 de ces demi-bits allongés.....étonnant ? ou pas !

Après la question est de savoir si tu cherches à valider le signal de la Z21 ou le traitement du sniffer. Si c'est bien le sniffer que tu cherches à valider (pas certain d'avoir tout suivi avant de mettre mon grain de sel dans cette histoire), je dirais que ces mesures sont conformes à ce que j'ai pu constater à l'oscillo de mon coté.

Note que si le demi-bit problématique est bien généré là ou je le crois dans le flux, il intervient durant la première partie du préambule. Si celui-ci est assez long, le décodeur retrouve tout de suite sa synchro et ne rate pas le paquet suivant.

Tu as reçu 115 paquets / sec dont une bonne partie en paquets extendeds (4 octets avec le checksum), ce qui correspond à la charge utile du DCC à priori....donc je ne pense pas que le sniffer ai "sauté" des paquets.

40

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 03, 2021, 05:32:33 pm »

@msport : regardes mieux les chiffres de la Z21 : il y a une anomalie.

Tu as (à 1 près) le meme nombre de demi-bits à 115 et à 116, ce qui correspond aux ZERO transmis en valeur nominale (environ 220 uSec)

Par contre, tu as un déséquilibre dans les demi-périodes liées aux UN.
Les demi-bits des UN sont les 57 et 58, la norme autorisant un écart par demi-alternance de 3 uSec je crois.
Or tu as :
5384 + 7874 en premiere alternance pour la durée 57
5384 + 7411 en seconde alternance pour la durée 58

Il y a 463 demi-alternances manquantes, qui correspondent à des bits 1 à compléter.

Tu retrouves ces 463 demi alternances en bas....ce qui veut dire que le décodeur a reçu une demi-alternance longue (>141) à un moment ou il attendait la seconde demi-alternance d'un 1...

Ton outil annonce le décodage correcte de 22990 bits dont 13026 bits à UN.
7411+5384 = 12795
7874+5384 = 13258

Ca ne colle pas....

Le décodage des paquets reste propre car, du fait de la présence de ces 463 demi-alternances étranges, le décodeur perd la synchro et doit se recaler ensuite...il saute des bits....une fois resynchronisé, il retrouve ses petits et les paquets décodés sont bons....mais régulièrement la centrale ROCO injecte un demi-bit foireux.

Le meme comportement que j'ai eu avec celle que j'ai testé (qui est bien plus vieille que la Z21).

41

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 01, 2021, 08:38:21 pm »

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.

42

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 01, 2021, 12:36:27 pm »

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

43

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 01, 2021, 12:19:04 pm »

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.

44

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 01, 2021, 09:49:43 am »

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

45

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 01, 2021, 09:07:18 am »

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