projet centrale "LaBox" wifi DCC++ Can

[Thierry]

Aujourd'hui, la lecture du courant se passe effectivement dans la loop principale DCCpp::loop() . Il y a à la fois la lecture de courant sur la voie principale puis sur la voie de programmation, ce qui signifie 100 analogRead par loop(). C'est sans doute trop fréquent, et on pourrait vraisemblablement ne laisser la mesure que chaque dixième de seconde, voire quart de seconde. Mais ça resterait encore trop fréquent et perturberai encore les timings à ces moments là. La lecture de CV est aussi perturbée, mais bien plus rarement, effectivement.
Il y a l'option dans ESP32_Timer pour faire faire la mesure au second core, mais si les choses s'améliorent un peu, ça reste trop perturbant pour les timings. Je pense qu'analogRead touche des choses bas-niveau de l'ESP qui sont communes à tous les coeurs.
Les tests de Michel montrent que la fonction remplaçante fait bien son boulot. Merci Michel ! Il faut maintenant vérifier que les timings DCC sont bons avec la lecture analogique débranchée (UNDEFINED_PIN sur le troisième argument de beginMain() dans Labox.ino...), et si c'est le cas, alors il faudra implémenter la nouvelle lecture analogique partout et revérifier avec le sniffer.

[Dominique]

Depuis que j’utilise DCCpp (et a fortiori DCC++), je place une mesure de courant de court-circuit personnelle dans la LOOP de mon programme, qui ne fait qu’un seul analogRead, sans aucune moyenne car c’est un seuil absolu a ne pas dépasser donc à réaction instantanée.
Quand cela arrive, la détection de cc de DCCpp ne se déclenche jamais car trop lente.

On pourrait donc simplifier DCCpp de cette façon.

Évidemment un lissage est nécessaire pour la lecture des réponses de programmation.

[msport]

... vérifier que les timings DCC sont bons avec la lecture analogique débranchée (UNDEFINED_PIN sur le troisième argument de beginMain() dans Labox.ino...) ...

c'est la pin 36 qui fait la mesure de courant, donc avec :
  // configuration pour L6203 La Box
  DCCpp::beginMain(UNDEFINED_PIN, 33, 32, UNDEFINED_PIN); sauf erreur, on la neutralise. (LaBox 091 et DCCpp 142)

Pour autant, est-ce qu'il n'y a plus d'analogRead ? car le résultat semble sans changement flagrant.

[msport]

J'ai certainement raté quelque chose, l'affichage du courant reflète la consommation ...

[Thierry]

Oui, dans HMI.cpp, l'analyse du courant consommé est à base d'analogRead. Il faudrait mettre les lignes 730 et 751-752 en remarque:

Code: [Sélectionner]

D:\Documents\Arduino\libraries\LaBox\src\hmi\hmi.cpp:
  728  {
  729    _HMIDEBUG_FCT_PRINTLN("hmi::readVoltage().. Begin"); 
  730:   voltage = (float) (analogRead(PIN_VOLTAGE_MES) * HMI_VoltageK);
  731  #ifdef _HMIDEBUG_SIMUL
  732    voltage = ((float)random(175, 185)) / 10;
  ...
  744  {
  745    _HMIDEBUG_FCT_PRINTLN("hmi::readCurrent().. Begin");   
  746:   //current = analogRead(PIN_CURRENT_MES) * HMI_CurrentK ;
  747    // DB : remplacé par une moyenne de 50 mesures
  748    float base = 0;
  749  for (int j = 0; j < 50; j++)
  750  {
  751: float val = (float) analogRead(PIN_CURRENT_MES);
  752  base += val;
  753  }


[Dominique]

C’est sur que s’il y a des analogRead un peu partout, les perturbations augmentent.

Il vaudrait mieux centraliser cette lecture dans le cœur de DCCpp.

[msport]

Cette fois on a bien -100 mA à l'affichage.

Mais les timings n'ont pas gagné grand chose à mon avis.
adcl3.jpg = avec des commandes DCC pour les locos.
adcl2.jpg = des idles

[Thierry]

C'est aussi pour ça que j'ai préféré repartir de DCCpp et éviter les surcharges de Labox...

[trimarco232]

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

non, je n'en suis pas là ; toutefois les interruptions n'ont lieu qu'à chaque bit dcc, cad. 116µs minimum, ce qui laisse beaucoup + de temps d'y faire des choses ...
(l'ultra précision n'est pas nécessaire dès qu'on reste dans les tolérences, mais ça ne coûte rien de l'avoir)

[Dominique]

Merci Trimarco232.

Pourrais-tu partager ton code ESP32 pour la generation DCC ?

[trimarco232]

c'était là : http://forum.locoduino.org/index.php?topic=830.msg9034#msg9034
un peu sec, alors j'ai ajouté ces /// complémentaires
n'hésitez pas pour + d'infos

[Dominique]

Désolé c’était passé sous les radars et avec l’âge on ne s’améliore pas !

Merci en tout cas 

[msport]

Bonsoir à tous,

quand on passe au sniffer le DCC pwm installé sur LaBox, les timings ne sont pas irréprochables :
Pour les UN on a 60 µs pour la 1ere demi-période, 55 µs pour la seconde soit 115 µs en tout.
Les ZERO n'ont pas de conséquence, évalués à 97-102 µs.

Il faudrait construire quelques paquets pour voir la conformité au NMRA.
Nota : limites pour les UN : 55 - 61, même si les décodeurs sont supposés accepter 52 -64 (+/- 6 µs). Norme S 9.1

[trimarco232]

pwm installé sur ma station, 2 générateurs actifs simultanément : tout est nickel !
1) ça décode (bon, les pakets du  1er géné sont en chantier)
2) les bits dcc 1 sont à 116,0000 µs
3) le bits dcc 0 dont à 198,0000 µs --> parce que je les ai programmé ainsi

@msport : il faut peut-être que tu fasses vacciner ton sniffer 

[Thierry]

Les timings sont bien bons, effectivement. Et l'analyseur logique qui décode le DCC tout en surveillant les trames, c'est juste génial !