projet centrale "LaBox" wifi DCC++ Can

[Dominique]

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.

Oui c’est sur, l’oscillo s’impose 

Mais là on a un projet intéressant 🤔 avec un model de hardware.
Bravo pour la super 👍 🔦 recherche 🧐

[laurentr]

Bonsoir à tous

Dominique, une suggestion qui me vient par rapport a ces soucis de lecture de cv et de ack...
Je vais faire une analogie avec la DR5000 qui dispose d un paramètre d ajustement de la sensibilité du hack
En effet la norme donne une certaine durée et un certaine consommation sur cette durée.
Cependant il arrive que cela soit plus aléatoire Qu autre chose... 6ms c est bref. Passer à 8 améliore parfois aussi un peu les choses...
Par chance la DR5000 dispose d une option qui permet de régler le seuil de charge ou pour ainsi dire le seuil à partir du quel elle doit interpréter un ack. On peut ainsi descendre assez bas ce qui est un avantage certain notamment quand on programme des décodeurs d accessoires qui ne disposent pas de moteur et ont donc une faible consommation.
 A voir si cette piste peut aider au delà d un code affinné et adapté...

Nul doute que vous aller percer ces mystères!

Laurent

Mon interprétation est la suivante: en cas de sensibilité inadaptée en jouant sur ce seuil on a de bien meilleurs résultats de lecture !

[train56]

Bonjour à tous,

Je suis admiratif devant vos connaissances, je vous suis depuis un temps certain , je cherchais à faire coexister centrale DCC++ et Can, je crois que grâce à vous j'ai trouvé la solution. J'ai déjà réalisé une centrale DCC economique avec un uno et un LMD18200. Mais je vais sauter le pas pour passer à cette box. Pour ce faire reste-t-il un PCB que je souhaitherais acquérir, avant d' en commander  chez JLCPCB auquel cas j'en aurai 4 de dispo.
Cdt
Hervé

[msport]

Bonjour,

un petit revamping de LaBox 0.1 en boite :

1. pour avoir la visibilité sur la présence du DCC avec un petit perçage au diamètre 3 à l'arrière et sur le dessus pour y mettre un bout de rond de même diamètre en acrylique transparent.

2. Et puis pour avoir accès aux boutons BOOT et/ou ENABLE : un ou deux petits trous sur le dessus de la boite en face des dits boutons : accès via un trombone. BOOT est utile pour lancer le téléchargement du programme et ENABLE permet d'afficher les messages à la console.

[msport]

Bonjour,

autre amélioration de LaBox 0.1  :

il apparait que le seuil (threshold) de détection de courant pour la lecture des CV, modifié à 80 pour l'ESP32 (30 utilisé par DCC++ sur UNO) conduit à une détection de 140 mA dans le cas de LaBox : 80 / 4095 x 3.3V

Pour se rapprocher des 60 mA de la norme NMRA, sans modifier le programme, il suffit de réduire le gain de la détection de courant de 1 V/A à 0,5 V/A en sortie du LM358.

Et donc de mettre une résistance de 15K au dos du pcb en parallèle avec la R3 de 33K. Ce qui donne une valeur équivalente de ~10Kohm.

Sur mon exemplaire, la lecture du CV 1 est quasi systématique même avec un décodeur récalcitrant. *** LaBox LIBRARY : 0.7.13 COMPILED : Apr 25 2021
Cela fonctionne aussi avec la 0.8.0 compilée vers cette date. Les versions ultérieures ne semble pas compatibles.

L'inconvénient : l'affichage du courant est divisé par deux. Ce qui peut-être modifié par un coeficient dans le programme.
Attention la bibliothèque ESP32 ayant été modifiée, cette modification ne fonctionne pas avec les versions plus récentes.
Il vaut mieux attendre une version stable pour recompiler le programme de LaBox.

Ensuite il faut retoucher le courant à vide (valeur de 0 à 15 mA - 25mA). En l'absence d'un ajustable, il suffit de souder provisoirement un potentiomètre de 1 Mohm entre les broches 3 et 8 du LM358, de régler l'affichage entre 15 et 25 mA en partant de 1 Mohm, de mesurer la valeur obtenue et de remplacer le potentiomètre par une résistance fixe de la valeur approchante pour 15 mA. La valeur typique est de 120 Kohm pour ce gain de 0,5V/A.

Avantage : la détection de court-circuit qui était un peu trop sensible à 700 mA, est portée à 1,4 A. Attention, ce n'est pas testé, le courant limité semble plus important.

Le pilotage des locomotives et accessoires n'est pas affecté.

[msport]

Un mystère éclairci ...

Le lancement du télé-déversement dans les ESP32 semble être soumis aux caprices de la météo ?
On trouve sur internet des montages affreux avec des condensateurs chimiques de 10 µF  ...
Manifestement inutile pour certains exemplaires.
En comparant les livraisons, on s’aperçoit que ceux qui ne nécessitent pas d'appuyer sur ENABLE, comportent un petit condensateur rapporté, mesuré à 0,75µF.
En cas de difficulté avec LaBox, il suffit de laisser l'ESP32 sur son support pour le programmer, après avoir remplacé C9 (100nF) par un 1µF :
https://www.ebay.fr/itm/264325249414

EDIT On peut rappeler la documentation d'ESPRESSIF :

Download button. Holding down Boot and then pressing EN initiates Firmware Download mode for downloading firmware through the serial port.

Téléchargement. Maintenir Boot enfoncé puis appuyer sur EN pour lancer le téléchargement du micrologiciel via le port série.


https://docs.espressif.com/projects/esp-idf/en/stable/esp32/hw-reference/esp32/get-started-devkitc.html

[Dominique]

Bravo pour cette explication lumineuse et la solution simple.

Petit à petit des chapitres s’ajoutent à la documentation de mise en œuvre qui remonte à la page 23 (debut 2021).

Le circuit imprimé a évolué à cause de composants obsolètes et des composants changent de valeur.
Il nous reste encore un mystère logiciel à lever.
Une mise à jour verra le jour prochainement, soyez patient !

Merci beaucoup.

[msport]

Quel courant pour LaBox ?

Le L6203 est donné pour 3 ampères (et 48V).

Mais d'autres limitations apparaissent :
La fiche de spécification du L6203 indique :
pour S/D diode RDS ON = 0,3 ohm (typ.) et VDS ON (@3A) = 0.9 V
pour transistors (@3A) VSD = 1,35V
soit 2,25 V je suppose que c'est pour chaque DMOS, donc 4,5V pour le pont

De fait, en test alimenté par un bloc 15V 6A qui présente une chute de tension de 0,5V à 14,8V avec une charge de 3A on évalue la tension DCC à l'oscilloscope à 32 V crête à crête à vide et 23 V cc avec une charge de 4 ohms. Soit respectivement 16 V et 11,5 V efficaces. (photos)
Un redressement donne la valeur des plateaux du signal carré.

L'afficheur indique 1350 mA (version 0.8 de LaBox et facteur de courant 1/2 avec  0,5V/A sur le pcb) soit 2700 mA. La résistance de 4 ohms 100W devient vite bouillante et le radiateur du L6203 devient rapidement chaud, il dissipe ~15W.
La protection de LaBox qui, avec ce montage est théoriquement à 2800 mA ne se déclenche pas.

Le montage peut être alimenté avec 18V, je n'ai pas fait de tests avec cette tension, car j'utilise entre autres des décodeurs LAISDCC qui recommande de ne pas dépasser 15V.
Mais les chutes de tension étant liées au courant, celles-ci seront identiques.
Ce test corrobore donc les spécifications aux incertitudes de mesure près.

[msport]

Une mise à jour verra le jour prochainement, soyez patient !

Et pour les impatients, la version de Labox 0.8 semble être la dernière qui détecte l'adresse de la locomotive posée sur les rails en lançant le choix adhoc. La mise sous tension de la voie par Smartphone, JMRI ou manette est nécessaire auparavant.
Cette version recompilée actuellement avec les bibliothèques mises à jour ne détecte plus l'adresse.
La solution est d'utiliser ESPTOOL pour télécharger le fichier flash_080.bin ci-dessous et d'utiliser un facteur de courant de 0,5V/A sur le pcb.
https://www.dropbox.com/s/dfbx4vyzjyi59qq/flash_080.bin?dl=0

Cette version de Labox 0.8 fonctionne à peu près avec JMRI (problème de lecture des CV sauf le CV1)

La procédure pour installer ESPTOOL a été décrite sur le site éditorial :
https://www.locoduino.org/spip.php?article279#forum5612

[Thierry]

Bonjour à tous

Après trois semaines de vacances à la maison, beaucoup de bricolage, et aussi un peu de programmation pour voir de quoi est fait l'ESP32, j'ai enfin quelques éléments de réponse sur notre problème de timing découvert voilà maintenant plusieurs mois...

Premier objectif pour moi, tester les timings interruptions simples sur ESP32. Rien ne permet de penser que ces interruptions ne fonctionnent pas bien, mais quand on cherche à résoudre un problème, on commence par la base... J'ai donc pondu un fichier ino (joint ici) avec un programme de test de timing. Il fonctionne -a priori- aussi bien en ESP32 que sur un Nano. Son but est d'abord de compter le temps entre deux appels à la fonction d'interruption et de rendre un rapport après un certain nombre de mesures. Je l'ai fixé à peu près au maximum d'un entier non signé, c'est à dire 60000 mesures. Ce devrait statistiquement être suffisant. Chaque interruption va mesurer le temps passé depuis le précédent appel, et selon le résultat, incrémenter un compteur. Comme le temps est idéalement fixé à 58us, j'ai donc utilisé une matrice de compteurs qui vont stocker le nombre trouvé de timings à +-10us autour du temps référence. C'est donc une matrice de 48 à 68, mais comme elle commence à 48, c'est en réalité une matrice de 20 longs non signés. L'élément 0 donne le compteur des 48us, l'élément 1 de 49us, etc... Deux autres compteurs sont ajoutés : l'élément 20 qui compte le nombre de timings en dessous de 48us, et l'élément 21 qui compte le nombre au dessus de 68us. Trois autres temps sont mesurés : le timing le plus court de toute la série, le plus long, et le temps passé à l'intérieur de la fonction d'interruption. Un pourcentage permet de rendre compte de la proportion de timings à la valeur idéale de 58us, et aussi la proportion de timings conformes à la norme NMRA, c'est à dire entre 55 et 61us inclus. Le timing moyen est aussi calculé.
Pour mieux comprendre l'influence de ce qui tourne autour de l'interruption, j'ai ajouté des define à l'entrée du programme pour jouer avec différents paramètres:

• LOOP_COMPUTE ajoute un traitement qui se veut un peu lourd dans la loop, un calcul de nombres premiers.
• LOOP_ANALOG_READ ajoute à la loop l'analyse du courant consommé à base d'analogRead tel qu'elle est faite dans DCCpp.
• INT_COMPUTE alourdit la routine d'interruption en faisant des digitalRead. Et on se rend compte là que le ESP32 est bien plus rapide là que le Nano... L'ESP32 passe malgré tout de 2 à 20us...
• SET_PIN fait alterner une broche digitale dans la routine d'interruption. C'est ce que fait DCCpp pour le signal DCC.
• INT_SECOND_CORE envoie la routine d'interruption sur le second coeur. Bien sûr ça ne marche qu'en ESP32...

Voici le rapport sans rien activer du tout, juste la mesure des temps :

Code: [Sélectionner]

isr : 2
min : 54
max : 62
ave : 57.50
< 48: 0
= 48: 0
= 49: 0
= 50: 0
= 51: 0
= 52: 0
= 53: 0
= 54: 120
= 55: 0
= 56: 120
= 57: 0
= 58: 59520 (99.20%)
= 59: 0
= 60: 120
= 61: 0
= 62: 120
= 63: 0
= 64: 0
= 65: 0
= 66: 0
= 67: 0
> 68: 0

NMRA compliant: 59760 (99.60%)

Le temps passé dans la routine d'interruption est de 2us, ce qui est très raisonnable avec un temps moyen de 57.5us très correct.
L'ensemble des temps mesurés se situe entre 54 et 62us, on est donc à près de 100% de réussite sur une norme NMRA.
Le timer de l'ESP32 fonctionne sur une démultiplication des ticks donnés par la fréquence du processeur. Ca explique les timings réguliers toutes les deux us : 54, 56, 58, 60, 62, 64... Certaines fois le timer doit arriver un chouilla trop tôt ou trop tard...

Voyons ce que ça donne avec LOOP_COMPUTE, INT_COMPUTE et SETPIN activés :

Code: [Sélectionner]

isr : 23
min : 53
max : 63
ave : 57.50
< 48: 0
= 48: 0
= 49: 0
= 50: 0
= 51: 0
= 52: 0
= 53: 120
= 54: 0
= 55: 120
= 56: 0
= 57: 240
= 58: 59043 (98.40%)
= 59: 241
= 60: 0
= 61: 120
= 62: 0
= 63: 120
= 64: 0
= 65: 0
= 66: 0
= 67: 0
> 68: 0

NMRA compliant: 59764 (99.60%)

Le temps passé dans la routine d'interruption s'est bien alourdi, mais le bilan global reste correct. On a un peu de timings perturbés à 57 ou 59us, et les temps mini/maxi se sont un peu aggravés, mais restent corrects.

Voyons ce qui se passe si l'on active uniquement la mesure de courant LOOP_ANALOG_READ:

Code: [Sélectionner]

isr : 3
min : 25
max : 90
ave : 57.50
< 48: 2352
= 48: 0
= 49: 0
= 50: 0
= 51: 0
= 52: 0
= 53: 0
= 54: 198
= 55: 960
= 56: 1849
= 57: 6489
= 58: 6554 (10.92%)
= 59: 20937
= 60: 17559
= 61: 1059
= 62: 174
= 63: 91
= 64: 99
= 65: 857
= 66: 272
= 67: 214
> 68: 344

NMRA compliant: 55407 (92.33%)

Et là c'est le drame... Les temps mini/maxi ont explosé, seulement 10% des timings sont respectés. Et même si d'un point de vue NMRA 92% des timings sont respectés, ont voit bien que dans un signal DCC de grandes disparités peuvent intervenir entre les fronts montants et les fronts descendants du signal... Le fait de passer la routine d'interruption sur le second coeur améliore un peu le traitement, mais pas au point de redevenir acceptable.

Le constat est sans appel, l'analogRead ESP32 est très lent. J'ai lu quelque part qu'il lui fallait 100us pour faire sa tâche, et que pendant une partie de ce temps les interruptions sont bloquées... C'est un problème que le nano n'a pas.
Voilà pour la partie théorique de l'analyse. Reste à trouver une solution et à l'appliquer à DCCpp et donc à Labox.

[Dominique]

Super : une vraie démarche scientifique 

Quelle influence a freeRtos sur les timings ? Je vois chez d’autres le comptage de ticks système, tantôt faits dans ESP-IDF, tantôt pas.

[Thierry]

Deuxième partie de mon analyse : DCCpp.

Pour éviter toute influence de ce que nous avons ajouté dans Labox avec les throttles et les diverses modifications, j'ai décidé de repartir de DCCpp. Lui ne s'occupe que du signal proprement dit. Le fichier ino utilisé (joint ici, avec aussi mon DCCpp du moment) est une variante de l'exemple autotest. En effet, il me fallait trouver un protocole de test suffisamment fiable et répétitif. Si en plus je pouvais me passer d'un circuit et de matériel roulant... Bref, une séquence programmée répétitive, avec un nombre d'actions bien déterminé devait faire l'affaire. Après réflexion, je me suis dit qu'en fait je n'avais pas besoin d'actions ! La simple génération de paquets 'Idle' devaient suffire à tester les timings. Ils contiennent suffisamment de bit à 0 et 1 pour tester. Il suffit d'allumer le DCC, d'attendre un peu, de clore le DCC puis d'afficher un rapport. C'est ce que fait le .ino avec une attente de 10s.
Avant de passer par la première étape citée plus tôt avec mon ESP32_timer.ino indépendant, j'avais tenté de remplacer l'interruption classique de DCCpp par une variante introduite dans la version officielle depuis peu, la version avec une seule interruption (USE_ONLY1_INTERRUPT). Contrairement à la routine classique qui décide à chaque changement de bit de la durée du prochain timing (58us ou 96us), la nouvelle dispose d'un timing constant à 58us, et compte les appels : 2 pour un un (un front montant, un front descendant) ou 4 pour un zéro (deux pour le front montant, deux autres pour le front descendant). Le gros avantage c'est que ça m'a permis de reporter mon calcul de timings quasiment tel quel depuis mon programme indépendant.
C'est en essayant de reproduire les timings de ESP32_Timer que je me suis aperçu de l'influence d'analogRead. En effet, si on ne demande pas de surveiller le courant (passer UNDEFINED_PIN comme dernier argument de DCCpp::beginMain() ) les timings bruts sont bien meilleurs. Je n'ai pas fait le test pour savoir si du coup le sniffer y trouvait son compte. A tester.

Evidemment, tout ça ne sert à rien si on a pas une solution à offrir. Pas question de se passer de la mesure de courant, que ce soit pour gérer les court circuits ou pour la programmation. Sur le net, j'ai fini par trouver une fonction de remplacement d'analogRead qui va plus vite.

Code: [Sélectionner]

#include <soc/sens_reg.h>
#include <soc/sens_struct.h>

int local_adc1_read(int channel)
{
uint16_t adc_value;

SENS.sar_read_ctrl.sar1_dig_force = 0; // switch SARADC into RTC channel
SENS.sar_meas_wait2.force_xpd_sar = SENS_FORCE_XPD_SAR_PU; // adc_power_on
SENS.sar_meas_wait2.force_xpd_amp = SENS_FORCE_XPD_AMP_PD; // channel is set in the convert function

// disable FSM, it's only used by the LNA.
SENS.sar_meas_ctrl.amp_rst_fb_fsm = 0;
SENS.sar_meas_ctrl.amp_short_ref_fsm = 0;
SENS.sar_meas_ctrl.amp_short_ref_gnd_fsm = 0;
SENS.sar_meas_wait1.sar_amp_wait1 = 1;
SENS.sar_meas_wait1.sar_amp_wait2 = 1;
SENS.sar_meas_wait2.sar_amp_wait3 = 1;

//set controller
SENS.sar_read_ctrl.sar1_dig_force = false;      //RTC controller controls the ADC, not digital controller
SENS.sar_meas_start1.meas1_start_force = true;  //RTC controller controls the ADC,not ulp coprocessor
SENS.sar_meas_start1.sar1_en_pad_force = true;  //RTC controller controls the data port, not ulp coprocessor
SENS.sar_touch_ctrl1.xpd_hall_force = true;     // RTC controller controls the hall sensor power,not ulp coprocessor
SENS.sar_touch_ctrl1.hall_phase_force = true;   // RTC controller controls the hall sensor phase,not ulp coprocessor

//start conversion
SENS.sar_meas_start1.sar1_en_pad = (1 << channel); //only one channel is selected.
while (SENS.sar_slave_addr1.meas_status != 0);
SENS.sar_meas_start1.meas1_start_sar = 0;
SENS.sar_meas_start1.meas1_start_sar = 1;
while (SENS.sar_meas_start1.meas1_done_sar == 0);
adc_value = SENS.sar_meas_start1.meas1_data_sar; // set adc value!

SENS.sar_meas_wait2.force_xpd_sar = SENS_FORCE_XPD_SAR_PD; // adc power off return adc_value;

return adc_value;
}

Je vous rassure, je n'y comprend rien non plus. Ca fait appel à des fonctions de base de l'ESP32 dont se sert aussi le classique analogRead. Effectivement, ça va plus vite, mais dans mon b...l provisoire, je ne l'ai pas testé en situation réelle. Je ne sais pas où sont mes potars ! Il faudrait au moins tester que ça marche sur un programme de lecture de potar de base en comparant la valeur qu'elle retourne à celle que retourne le vrai analogRead. Si la fonction marche, on pourra alors envisager de remplacer tous nos appels à analogRead par cette fonction. Elle réclame un channel et pas un numéro de pin, alors il faut utiliser

Code: [Sélectionner]

int channel = digitalPinToAnalogChannel(pin);
pour faire la conversion.

[trimarco232]

Bonjour Thierry
pour la génération des bits dcc, j'utilise le pwm : cela fait des timings on ne peut + précis, et il n'y a qu'1 seule interruption par bit dcc, voire moins ...

[msport]

Bonsoir Thierry,

à priori le adcl suit bien la valeur de l'analogread (potentiomètre à 3V3 sur le GPIO 36, décalé par pas) :

Code: [Sélectionner]

analogRead = 1699
adc1_read = 1699
analogRead = 1702
adc1_read = 1700
analogRead = 1703
adc1_read = 1699
analogRead = 1702
adc1_read = 1701
analogRead = 1711
adc1_read = 1702
analogRead = 1702
adc1_read = 1696
analogRead = 1703
adc1_read = 1699
analogRead = 1703
adc1_read = 1687
analogRead = 1706
adc1_read = 1688
analogRead = 1706
adc1_read = 1699
analogRead = 1695
adc1_read = 1833
analogRead = 2631
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 4095
adc1_read = 4095
analogRead = 3509
adc1_read = 2702
analogRead = 2734
adc1_read = 2731
analogRead = 2745
adc1_read = 2739
analogRead = 2736
adc1_read = 2644
analogRead = 2734
adc1_read = 2741
analogRead = 2715
adc1_read = 2736
analogRead = 2735
adc1_read = 2731
analogRead = 2736
adc1_read = 2733
analogRead = 2740
adc1_read = 2737
analogRead = 2733
adc1_read = 2731
analogRead = 2431
adc1_read = 1472
analogRead = 1472
adc1_read = 1477
analogRead = 1480
adc1_read = 1598
analogRead = 1583
adc1_read = 1565
analogRead = 1579
adc1_read = 1591
analogRead = 1581
adc1_read = 1577
analogRead = 1585
adc1_read = 1575
analogRead = 1584
adc1_read = 1582
analogRead = 1575
adc1_read = 1267
analogRead = 688
adc1_read = 644
analogRead = 645
adc1_read = 645
analogRead = 589
adc1_read = 639
analogRead = 647
adc1_read = 642
analogRead = 625
adc1_read = 640
analogRead = 654
adc1_read = 645
analogRead = 646
adc1_read = 640
analogRead = 479
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 0
analogRead = 0
adc1_read = 73
analogRead = 87
adc1_read = 80
analogRead = 79
adc1_read = 81
analogRead = 78
adc1_read = 85
analogRead = 80
adc1_read = 80
analogRead = 80
adc1_read = 99
analogRead = 80
adc1_read = 80
analogRead = 81
adc1_read = 80
analogRead = 82
adc1_read = 82
analogRead = 80
adc1_read = 85
analogRead = 80
adc1_read = 80
analogRead = 80
adc1_read = 84
analogRead = 75
adc1_read = 80
analogRead = 80
adc1_read = 80

Code: [Sélectionner]

#include <soc/sens_reg.h>
#include <soc/sens_struct.h>

int canal = digitalPinToAnalogChannel(36);

void setup() {
  Serial.begin(115200);
  Serial.println("LaBox ");
}

void loop() {
  // put your main code here, to run repeatedly:
   Serial.print("adc1_read = ");
   Serial.println(local_adc1_read (canal));
 delay(500);
   Serial.print("analogRead = ");
   Serial.println(analogRead(36));             // debug value
    delay(500);
}

#include <soc/sens_reg.h>
#include <soc/sens_struct.h>

int local_adc1_read(int channel)
{
  uint16_t adc_value;

  SENS.sar_read_ctrl.sar1_dig_force = 0; // switch SARADC into RTC channel
  SENS.sar_meas_wait2.force_xpd_sar = SENS_FORCE_XPD_SAR_PU; // adc_power_on
  SENS.sar_meas_wait2.force_xpd_amp = SENS_FORCE_XPD_AMP_PD; // channel is set in the convert function

// disable FSM, it's only used by the LNA.
  SENS.sar_meas_ctrl.amp_rst_fb_fsm = 0;
  SENS.sar_meas_ctrl.amp_short_ref_fsm = 0;
  SENS.sar_meas_ctrl.amp_short_ref_gnd_fsm = 0;
  SENS.sar_meas_wait1.sar_amp_wait1 = 1;
  SENS.sar_meas_wait1.sar_amp_wait2 = 1;
  SENS.sar_meas_wait2.sar_amp_wait3 = 1;

  //set controller
  SENS.sar_read_ctrl.sar1_dig_force = false;      //RTC controller controls the ADC, not digital controller
  SENS.sar_meas_start1.meas1_start_force = true;  //RTC controller controls the ADC,not ulp coprocessor
  SENS.sar_meas_start1.sar1_en_pad_force = true;  //RTC controller controls the data port, not ulp coprocessor
  SENS.sar_touch_ctrl1.xpd_hall_force = true;     // RTC controller controls the hall sensor power,not ulp coprocessor
  SENS.sar_touch_ctrl1.hall_phase_force = true;   // RTC controller controls the hall sensor phase,not ulp coprocessor

  //start conversion
  SENS.sar_meas_start1.sar1_en_pad = (1 << channel); //only one channel is selected.
  while (SENS.sar_slave_addr1.meas_status != 0);
  SENS.sar_meas_start1.meas1_start_sar = 0;
  SENS.sar_meas_start1.meas1_start_sar = 1;
  while (SENS.sar_meas_start1.meas1_done_sar == 0);
  adc_value = SENS.sar_meas_start1.meas1_data_sar; // set adc value!

  SENS.sar_meas_wait2.force_xpd_sar = SENS_FORCE_XPD_SAR_PD; // adc power off return adc_value;

  return adc_value;
}


[Dominique]

Bonjour,

Je suis sans doute pas bien réveillé mais j'ai du mal à comprendre pourquoi imbriquer des analogRead systématiquement dans la génération du signal DCC.
Bien-sur il faut lire la valeur du courant pour la détection de court-circuit qui, elle, doit se faire une fois par loop principale et il faut lire le courant faible de 60 mA lors des lectures de CV, mais ce qui n'est pas fréquent et uniquement dans les phases de programmation de décodeur.

Evidemment la durée d'une loop principale fait moins de 58µS donc ces analogRead (ou équivalents) pour la détection de court-circuit tombent forcément et plusieurs fois dans un créneau 1 ou 0 du générateur DCC. Et cela perturbe les interruptions. N'est-il pas ?

Je suppose donc que notre ami trimarco232 n'inclut pas de lecture analogique du courant dans sa génération ultra-précise du DCC en PWM.

Pour éviter cet inconvénient, on pourrait faire appel à une mesure de courant extérieure à l'ESP32 avec un convertisseur analogique-numérique extérieur.
Mais comme l'ESP32 comporte 2 coeurs, ne serait-il pas possible de faire la génération DCC dans un coeur et la lecture analogique dans l'autre coeur ?