projet centrale "LaBox" wifi DCC++ Can

[trimarco232]

bits 0 stretchés :
1) mamaille horrible pour piloter 1 loco analogique (adresse 0) ... (et la détruire)
2) donner du temps au mcu quand il en a besoin

[msport]

Bonjour,

le passage du DCC d'une z21 au sniffer semble valider celui-ci : 100% des packets sont valides.
la totalité des bits UN sont vus à 57 et 58 µs et sauf exception les bits ZERO sont vus à 115 -116 µs
càd que 5% des bits ZERO sont longs : jusqu'à 522 µs
Pendant les 4s d'observation, en conséquence, la z21 délivre 22990 bits et LaBox 28453 bits.
Et la largeur des 1/2 bits UN de LaBox est très dispersée autour des 58µs (même en l'absence des analogRead) (cf message plus haut).

[AmadeusHF]

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

[AmadeusHF]

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.

[msport]

Effectivement le but était de valider le sniffer pour ne pas incriminer LaBox d'anomalies qui dont il serait responsable du fait de l'optocoupleur et du fameux condensateur sur l’entrée.
La z21 n'étant pas mon sujet mais une référence.
Pour LaBox on avait déjà validé l'étage de sortie à base de L6203 et de transistor inverseur sur une BaseStation à Nano.
Mais pour aller plus loin, j'ai repris le signal DCC directement sur la pin 33 de l'ESP32 pour l'envoyer directement sur la pin 5 de l'ESP32 du sniffer. Avec la version 0.80 de LaBox, on constate la même dispersion des 1/2 bits des UN avec une moyenne de 58,9 µs (référence à 58 µs).
Ce qu'on voyait (difficilement mais nettement) à l’œil nu à l'oscilloscope.

[AmadeusHF]

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

[AmadeusHF]

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

[msport]

L'objectif est d'avoir un minimum de packets Out of spec NMRA avec la tolérance "decoder" de la norme (+/- 6µs) : 0 pour la z21.
Et on teste tout ce que Thierry nous soumet.

[AmadeusHF]

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

[trimarco232]

(...)généralement 55 sur le premier et 56 sur le second.

ce qui pourait très bien s'expliquer par un dead time de commande des mosfets qui serait de 1/2µs
typiquement ce dead time ne peut être vu par un analyseur logique ou un dispositif de capture : donc il est lu systématiquement à high (ou low ..), ce qui fait qu'il va s'ajouter à une alternance de bit DCC, et se retrancher à l'autre
pour l'observer, il faudrait relier la sortie de puissance DCC à un diviseur de trension par 2, relié au + et au - de l'étage de puissance, et le voir à l'oscillo comme un pallier d'1/2 µs au millieu d'un flanc montant ou desçandant au milieu ou entre chaque bit DCC

[AmadeusHF]

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

[AmadeusHF]

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

[AmadeusHF]

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.

[Dominique]

La question reste posée: comment obtenir cette précision avec l’ESP32, sachant que les moyens de mesures fiables et précis existent maintenant ?
Avec un grand merci à vous deux.

Idéalement la génération des bits devrait se faire à l’extérieur de l’ESP32, avec une sorte de registre à décalage “serie-serie” chargé en I2C, I2S ou PCI, avec un doublement des bits 0 pour conserver une période de 55 uSec partout et un pattern d’IDLE quand le truc n’est pas chargé ou vide. Il faudrait aussi un marqueur de fin de commande car elles ont dès longueurs variable.

Une sorte de FPGA sur mesure ou alors la même fonction a l’intérieur de l’ESP32 mais à l’abri du RTOS.

Qu’en pensez-vous ?

[AmadeusHF]

Si effectivement on arrive pas à générer un signal stable directement avec l'ESP, oui il faut confier ça à un composant externe. Plutot qu'un FPGA j'aurais tendance à garder un petit CPU 8 bits facilement sourçable et que tout le monde sait programmer....

Maintenant j'ai pas vu de réponse la question relative à des tests sur ESP en modulant la priorité des task de génération....@Thierry tu peux m'en dire plus sur le code (je n'ai pas regardé, sincèrement...)