Messages

31

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: juillet 29, 2021, 10:02:14 pm »

Suite 3 ET FIN
- avec ABANDON de la piste asservissement
car ça marche... fort mal ou sinon dans des conditions extrêmement étroites (mais si c'est faux, je suis vivement intéressé par une démonstration).
Le signal de la mesure FCEM se contredisant régulièrement d'une mesure à l'autre, impossible d'en déduire la moindre action Proportionnelle. Et si l'Intégrale permet d'isoler une tendance, une action intégrale trop majoritaire, ça pompe, c'est obligé.

- MAIS...
idée : substituer à l'action proportionnelle une PWM "classique" : un cran donné de réglage => un équivalent tension => une vitesse... plus OU MOINS assurée compte tenu des nombreux facteurs quasiment tous d'accord pour ralentir (si ça n'est bloquer) la loco.
Plein d'excellentes occasions pour l'intégrale de faire son retour !
Et ça s'appelle de la COMPENSATION DE CHARGE ; dès que quoique se soit ralentit la loco, la FCEM diminuant, l'intégrale se réveille et... compense. (L'intégrale pourrait aussi faire du moins... il faut juste que ça soit à bon escient sinon on retrouve le souci du pompage)

J'aurais tout de suite compris toute la substantifique signification de "compensation de charge"... que j'aurais gagné bien du temps !
Car ça, ça marche ! Et sans aucun besoin d'électronique (problème réglé !) et ça donne enfin un fonctionnement en analogique propre, fluide, régulier, reproductible. Réaliste !
(j'admire au passage le fait que le DCC puisse intégrer, "in situ" qui plus est, une fonction tout de même complexe mais tellement indispensable).

Et pour ce qui est de la marche à basse vitesse... match nul non ? Analogique (avec compensation de charge donc !) et DCC se rejoignent forcément sur les mêmes réalités : selon la loco on obtient effectivement du 5kmh régulier, pour d'autres ça sera jamais moins que 25kmh (et ceci bien sûr à condition que les roues soient astiquées, les rails décapés, les contacts nickels...).
Dernière remarque ; sous réserve que j'ai à peu près compris ce qu'est un réseau en DCC : la loco se charge de tout ! Alors que dans l'analogique ça sera loin d'être aussi simple ; le problème à résoudre sera celui du sectionnement électrique qui impose de compiler et traiter plusieurs relevés de FCEM pour un même train, tant en traction qu'en refoulement (même dans le cas d'une loco solo !).
Mais ça se fait et c'est typiquement le plaisir collatéral de l'analogique, faire tourner un code !

Peut-être à bientôt pour de nouvelles aventures ?
En tous cas bien cordialement

Philippe

32

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: juin 15, 2021, 09:19:38 pm »

Merci à Laurent pour son indication.

En effet ça vole haut. Et c'est surtout très intéressant.

J'ai regardé le code "DSDCCDec_motor_BEMF_04a" et c'est confirmé, j'avais à priori pensé que c'était totalement impossible mais les décodeurs DCC font exactement le travail que propose Jean-Luc en analogique! Seule petite différence, l'algorithme fait en effet plutôt dans la "force brute", plus (+) de mesures, aucun filtrage.

Le gros avantage de l'analogique restant qu'on a pas la contrainte terrifiante de devoir tout faire tenir sur un timbre poste !
Bon d'accord... il ne reste aucun avantage si on a pas comme Laurent le challenge de faire ses propres décodeurs ( !) 

Pour ce qui est de la question de msport  "la branche positive envoie l'AO en saturation dès qu'une tension positive est appliquée. Est-ce le but ? "... Jean-Luc pourrait (pourra ?) sûrement le dire...

33

Infos et bonnes affaires / Re : ESP32 "bonne affaire"

« le: juin 15, 2021, 09:04:55 pm »

Bonsoir,
Merci pour la modif !

RE-RE-EDITION :
J'ai testé PlatformIO. Chez moi pas possible d'installer le dernier release. Mais au moins la 1.10.0 s'installe (en insistant !)

Que ce soit sous PIO ou l'IDE Arduino, l'OTA fonctionne à merveille (à condition de ne pas s'aviser entre temps de désinstaller Python... malheureux !)
La différence avec ce que rapporte BobyAndCo est peut-être que je n'ai pas (encore) tenté de mettre un mot de passe "projet".

Penser éventuellement qu'il faut avoir autorisé les adresses MAC des ESP32 (car ils en ont, chacun la leur !) si dans sa box on est en filtrage (et il vaut mieux)

 

34

Infos et bonnes affaires / Re : Re : ESP32 "bonne affaire"

« le: juin 14, 2021, 11:27:25 am »

A voir : le cloud Arduino pour ESP32 qui propose un televersement en OTA.
Je n’ai pas encore essayé...

Bonjour,
téléverser sans fil, le rêve ! Surtout si l'on imagine un hard avec une dizaine de cartes... le boulot évité chaque fois qu'on veut mettre à jour !
J'ai regardé le cloud Arduino mais je crois qu'il vaut mieux oublier : il faut un abonnement, même s'il y a une option "free" mais limités à 200secondes de compilation par jour...

Mais pourquoi passer par le cloud ? Le WI-FI direct... idéal mais je viens de lire des informations contradictoires sur la faisabilité pour un ESP.
Par contre le WI-FI de la maison c'est apparemment sans problème  :
https://projetsdiy.fr/arduinoota-ota-mise-jour-sans-fil-ide-arduino-programmes-esp8266/

J'ai hâte d'essayer mais attention à la dispersion...

EDITION : Je n'y ai pas résisté.
Voici la procédure, simplissime !
https://projetsdiy.fr/arduinoota-esp32-mise-jour-sans-fil-wifi-ota-ide-arduino/

Le gerber de Boby&Co pour ESP 38 pins va sauver mes cartes (deux) (que j'aurais bien sûr proposées ! ça ne se jette pas !!)
Première chose à faire, une petite modif pour intégrer le condo (à moinsse qu'une version V6 soit déjà prévue dans ce sens ??) car la soudure directe sur la carte... pour le coup elles seraient certainement bonnes à jeter (et c'est trop moche)
(essais en vue pour choisir le condo car le gap entre 0.1µF et 1000µF est monstrueux...!)

35

Infos et bonnes affaires / Re : ESP32 "bonne affaire"

« le: juin 13, 2021, 10:10:09 pm »

Bonsoir,

ESP32 bonne affaire ? Oui finalement car pour un prix incroyablement ridicule on a une puissance de feu et des possibilités étonnantes ! Je pense en faire des cartes "satellites type V2" et elles y seront infiniment sous-employées.
Mais mais mais... j'ai bien  failli jeter l'éponge car ces petites bêtes sont capricieuses et je n'ai pas encore compris ce qu'on doit leur dire pour, par exemple, qu'elles acceptent un download plus de 5 fois sur 100 sans avoir besoin de forcer le boot via le minuscule bouton.
Ça et la note en début du code que je joins...
Peut-être le souci n'est-il pas l'ESP32 mais que le couple avec l'IDE Arduino est mal assorti ? Trimarco parle quelque part de PlatformeIO... à voir.

Le pire a été le bus CAN et quand rien ne marche et que les causes sont multiples... mais enfin ça fonctionne.

Les cartes de la photo postés par Boby&Co vont donc beaucoup m'intéresser... sauf que j'ai maintenant des ESP 38pins, faut d'avoir détecté que les 6pins "flash" ne serviraient à rien !
Alors question à Boby&Co : n'ayant encore jamais édité de fichier Gerber, pour ne pas essuyer de plâtres je serais bien content de profiter du vôtre que je pourrais assez facilement transformer il me semble... mais il n'est pas en PJ comme annoncé ?
Ou, si vous en avez un gros stock, vous demander de me fournir mais dans ce cas je devrais "jeter" mes 38 pins et en commander des 30pins... je n'ai aucune idée de la meilleure solution d'un point de vue économique (à terme je pense que j'en consommerai une dizaine).
En tous cas, cette carte avec le transceiver intégré est parfaite ! (et plus de problème avec l'empattement !)
(Mais pourquoi un convertisseur 5V ? la carte est prévue pour alimenter autre chose ? Et, si je dois approvisionner, quel est ce composant vertical entre le transceiver et le convertisseur ??)

Et à propos encore de cette photo : merci car c'est elle je crois qui m'a donné la solution au problème du bus CAN avec ses deux pins sorties sur RX2 et TX2. Car en brochant sur RX0 et TX0 (deux jours d'obstination !) RIEN ne fonctionne et, même, plus aucun download possible !! (?) (à remarquer que la datasheet espressif est fort sommaire... peut-être pas assez bien cherché ?)

Mais ça marche. Faire obéir la librairie ACAN_ESP32 n'a cependant pas été facile ; on reconnaît en effet le "moule" mais les syntaxes sont sensiblement différentes or tous les exemples fournis sont en loopbak...

Pour éviter peut-être à quelqu'un d'autre de patauger comme je l'ai fait, voici un code sommaire qui tourne. Notez l'avertissement en préambule... vaut mieux le savoir !

Code: [Sélectionner]

/* AVERTISSEMENT (AIMABLE)
 *  Ce code conduira probablement à un message "ERREUR DE COMPILATION", sauf à y effectuer pour commencer n'importe quelle modif inutile, un espace ici par exemple
 *  (va comprendre! vrai en tous cas avec "ESP32 Dev Module" + l'IDE Arduino)
 */

#include <ACAN_ESP32.h>

uint32_t lastTime;
const uint16_t TIMER(1000); 

uint8_t message = 1;
static const uint32_t FREQUENCE_DU_BUS_CAN = 125ul * 1000ul;

CANMessage messageToCAN;      /* MESSAGES EN EMISSION */
CANMessage messageFromCAN ;   /* MESSAGES EN RECEPTION */
/* *************************************************************************** */
void setup() {
  Serial.begin(115200);
  delay(200);
  /* parametres CAN */
  ACAN_ESP32_Settings settings(FREQUENCE_DU_BUS_CAN);
  settings.mRxPin = GPIO_NUM_16 ; // TX2
  settings.mTxPin = GPIO_NUM_17 ; // RX2
//  settings.mDriverReceiveBufferSize = 4;
//  settings.mDriverTransmitBufferSize = 6;
  /* demarre CAN */
  const uint32_t errorCode = ACAN_ESP32::can.begin(settings) ;
  ACAN_ESP32_Filter filter = ACAN_ESP32_Filter::acceptAll () ;
  if (errorCode == 0) /* =>*/ { Serial.println("Configuration OK"); }
  else /* =>*/ { Serial.print("Error Can: 0x"); Serial.println(errorCode, HEX); }

  /* identifiant (standard) des messages émis */
  messageToCAN.id = 0b10000;
  messageToCAN.len = 1 ; 
}

/* *************************** messages CAN réception ************************ */
void fromCAN(const CANMessage & inMessage) {
  Serial.print("Reception message : ");
  Serial.println(inMessage.data[0]);
}

/* **************************** messages CAN émission ************************ */
void toCAN(const uint8_t MESSAGE) {
  messageToCAN.data[0] =MESSAGE;
  const bool OK = ACAN_ESP32::can.tryToSend(messageToCAN);
  if (OK) { Serial.print(F("Emission message : ")); Serial.println(MESSAGE); }
}

/* *************************************************************************** */
void loop() {
  if (ACAN_ESP32::can.receive(messageFromCAN)) /*=>*/ fromCAN(messageFromCAN);

  if ((millis() - lastTime) < TIMER) /*=>*/ return;  // TIMER ne vise pas à soulager le BUS mais seulement à simuler des événements déclencheurs

  toCAN(message);
  message++;
  lastTime = millis();
}

(merci pour toutes les pistes  à propos des breadboards king size)
Cordialement

36

Infos et bonnes affaires / Re : ESP32 "bonne affaire"

« le: juin 04, 2021, 10:51:44 pm »

Bonsoir,
Merci msport pour ces éclaircissements (nécessaires !)

D'après la photo sur Aliexpress, il semble que l’empattement des shields soit bien 25.4 mm

Eh non, la différence est tellement faible que c'est trompeur, c'est du 22,86 mm que j'ai reçu.


"laBox"? Je m'étais appuyé sur la photo de la réponse 467 ! Sans faire attention à la largeur et en retournant regarder il me semble que c'est une carte de 25mm.

Ce qui est d'ailleurs fort embêtant sur les breadboard Arduino classiques car elles limitent le câblage à un seul côté avec une ESP de 25mm !!



Mais après avoir regardé la photo "467" de plus près, je découvre qu'il existe des breadboards "spéciales" avec 2x6 rangées de brochages !
https://forum.locoduino.org/index.php?topic=922.467

Dommage qu'aujourd'hui elles semblent introuvables...

37

Infos et bonnes affaires / ESP32 "bonne affaire"

« le: juin 03, 2021, 08:55:12 pm »

Bonjour,

ESP32... on lit des choses qui donnent envie d'essayer. Mais ESP32 c'est toute une famille alors qui adopter ? J'ai ...opté pour un 38pins (tant qu'à faire) à 3,20euro pièce :
https://fr.aliexpress.com/item/32959541446.html?spm=a2g0s.9042311.0.0.63916c37cLotyv
plus 3Xrien pour le port (pourtant reçu en moins de 15j) et accompagné, pour simplifier les essais, d'un shield d'expansion :
https://fr.aliexpress.com/item/1005002363013005.html?spm=a2g0s.9042311.0.0.63916c37cLotyv

Sauf que... dans la famille ESP32 certains sont plus costauds que d'autres... et les miens sont trop larges pour les cartes d'extension ! (d'un pas "dupont", 2.5mm, argh...)

Les ESP32 je ferai autrement par contre les shield (il y en a deux) je ne m'en servirai jamais mais je n'aime pas jeter.
Aux dernière nouvelles, ils seraient prévus pour des ESP Vroom (?).
 
Si quelqu'un en à l'usage, je les cède pour rien, juste le prix du timbre pour l'expédition.

Qu'on se le dise.

Cordialement

38

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: mai 31, 2021, 08:45:11 pm »

Bonsoir,

Asservissement de vitesse pour les nuls... saison 2

Résumé de la saison 1 : c'est fou, la FCEM ça se capte avec juste un bout de fil, deux résistances et un code minimaliste ! Et encore... la saison 2 démontrera que le code peut être encore plus simpliste. Voire carrément remplacé par un circuit RC ? Ce qui donnerait corps à la remarque de Msport :

Les 15kmh, oui, mais c'est du DCC et les décodeurs comportent une compensation de charge qui est manifestement basée sur la mesure de la FCEM ...

Alors SAISON 2 : Un code élaboré pourra-il produire EN SITUATION un véritable asservissement, plus "intelligent" que de la compensation de charge ?

En résumé : un peu oui et beaucoup non (en attendant la saison 3 !!)

Du côté du non :
Il y a deux conditions à une régulation réellement opérante : une mesure fiable de la grandeur et des corrections très fréquentes.

• Première condition : l'horreur. Avec deux principaux problèmes :
   - un bruit de fond relativement important, cad l'impossibilité de mesurer une "erreur" (entre demande et constat) plus faible que le bruit de fond moyen
   - ET les transitoires aux frontières électriques, cad lorsque la motrice est à cheval  (mais il faut aussi raisonner "train", car la motrice une fois passée tout wagon générera du bruit de fond en maintenant la section sous tension ...)
• Seconde condition : confiés à un nano qui a d'autres choses à faire, 100 cycles de mesures à la seconde ne sont pas loin du maximum possible. Malheureusement, 10millisecondes, du point de vue d'une boucle d'asservissement, c'est une éternité.

Autant du fait de la première que de la deuxième condition, pas la peine de penser à une correction "dérivée"... il faudra donc faire avec une proportionnelle fantasque (capable d'un freinage brutal immédiatement après un grand coup de +) et une intégrale vite chatouilleuse.

Le but est tout de même de tirer le maximum de ces FCEM, puisqu'il est possible de mesurer "quelque chose" !

• Améliorer la mesure ?
  On a deux approches possibles :
  
  • un filtrage logiciel "élaboré" sur les mesures elles-mêmes. Dans cette approche, mes expériences n'ont pas donné mieux que ce que propose Jean-Luc : la moyenne des quatre valeurs médianes dans un groupe de six.
  • aucun filtrage : on prend tout de qui arrive, sans précaution préalable, sans même de délai de coupure du courant traction avant mesure, mais on prend le maximum de mesures possible. Et on compte sur l'effet statistique.
    Après moult essais, je n'ai pas su faire de différence sensible entre les deux approches (ce qui conforte à nouveau l'hypothèse de la compensation de charge DCC par rétroaction FCEM)
  
  
• Peaufiner le code ?
  C'est ce qui peut faire la différence avec une compensation aveugle. Mais les contraintes inhérentes à la mesure sont toujours là, le code ne peut que tenter de différencier des situations pour apporter à chacune la réponse la plus appropriée. La complexification est presque sans limite.
  Mais deux exemples, deux situations très perturbées :
  
  • un train est détecté sur deux, ou plus, sections électriques : au milieu des mesures qui arrivent, lesquelles relèvent-elles d'un bruit de fond "wagons" ? Sachant qu'au démarrage, une motrice est tout d'abord vue comme du bruit de fond...
  • La correction proportionnelle devant être appliquée avec beaucoup de modération, comment régler la correction intégrale ? Si le convoi en marche lente "accroche" un point dur et s'arrête... l'intégrale doit très vite réagir mais si en réponse (tardive) le train "bondit", elle ne doit pas le stopper aussitôt mais le ralentir en délicatesse... les coefficients ne seront donc pas les mêmes.

Du côté du oui :
Dans ces conditions, il y a un réel plus par rapport à une conduite par la PWM: une régularité d'horloge, la quasi certitude de ne plus avoir de train définitivement bloqué sur un point délicat, une vitesse identique loco à vide ou en traction, des accélérations et ralentissements sous contrôle
...mais un ralenti "au pas"... heu pas vraiment.  Ou peut-être s'en approcher avec des conditions "labo" : une motrice très courte avec un max de roues au contact, lente car fortement démultipliée (donc grosse FCEM même à vitesse faible),  une seule zone électrique, pas d'aiguilles, des grands rayons... là oui, et/ou avec en plus le renfort d'une électronique assez futée pour doper le signal mais pas le bruit de fond (la phase 3 !) ça doit pouvoir être plutôt sympa!

Alors voilà pour l'instant ce que ça donne chez moi.
Avec trois "crans" : 15%, 11%, 8%. Sur ce  dernier, on voit nettement, surtout si on tremble en même temps que l'image, que la régulation flirte avec la capacité à distinguer le signal du bruit de fond... résultat : 25kmh et pas moyen en l'état de faire mieux...


... en attendant la phase 3 !
Mais là, gros problème. Car si un code c'est, pour moi, un peu comme les sous-titre anglais d'un film : je comprends plus ou moins et quand c'est mon tour d'écrire, en insistant je finis par me faire comprendre.
Mais un schéma électronique... ce coup, c'est un film avec des sous-titre en russe !
Quelqu'un aurait-il le temps et la gentillesse de me "traduire" ce schéma proposé par Jean-Luc ? Nécessaire et suffisant sauf erreur (de ma part !).
J'ai approvisionné les ampli OP, révisé les différents types de montage (sans reconnaître celui-du schéma...), me manquera plus que l'impression de ne pas faire n'importe quoi !

Un énorme merci par avance au volontaire (pourvu que !)

39

Vos projets / Re : Un Arduino par canton

« le: mai 30, 2021, 10:24:15 am »

Bonjour Jean-Luc,

... j'aurais besoin d'un coup de pouce siouplé...

Dans la laborieuse mise au point de mon asservissement de vitesse et pour m'éviter un téléversement chaque fois que je bouge un paramètre, j'aimerais utiliser la librairie CommandInterpreter et juste adapter les moniteur.cpp moniteur.h de votre code AlimentationTraction. Or lorsque je charge ce dernier, autant les "strings" sont acceptés sans souci, autant je n'arrive pas à passer un "int". J'ai essayé des tas de syntaxe, dont la plus évidente (par exemple : gi 20)... rien à faire. La lecture de la valeur est OK, les messages d'instruction OK, mais la modif de la valeur... non.
La solution est bien sûr dans la librairie elle-même... mais le code est hélas trop abscons pour mon niveau ! Pouvez vous me dire ce qu'il faut écrire ?

Grand merci par avance

40

Infos et bonnes affaires / Re : Capteur de proximité VL6180X

« le: mai 13, 2021, 09:42:26 am »

Bonjour,

Le post de Trimarco est l'occasion de rapporter une expérience très positive concernant l'I2C.

Il s'agissait comme envisagé plus haut de lire des détecteurs, donc à priori en grand nombre et (donc) au travers d'un multiplexage. Moyennant une organisation par zones de proximité, pour des distances de fil raisonnables (jusque 60cm dans ma configuration), le tout marche PARFAITEMENT.
Tant côté bus I2C que capteurs (décidément idéaux) : jamais de fausse détection (sauf main qui traîne malencontreusement mais du point de vue du détecteur ça n'est pas une fausse détection...), le besoin néanmoins d'un filtrage logiciel sur les détections faibles, ce qui n'est pas un inconvénient car c'est fort utile : la latence qui en résulte à la retombée de la détection se traduit par une distance de dégagement avant, par exemple, la libération d'un canton quitté. Un traitement logiciel juste un peu évolué permet même que cette distance soit indépendante de la vitesse du convoi ; pour cela le gestionnaire doit rétro-signaler régulièrement au détecteur la vitesse de "l'objet" détecté. Ainsi, lorsque c'est un attelage qui est au surplomb, condition de détection la plus défavorable, une vitesse très faible entraînant une latence importante l'attelage reste détecté.
(une précision : les capteurs communiquent avec le multiplexeur et ce dernier à un arduino "satellite" par I2C / la communication satellites-gestionnaire est assurée par bus CAN)

Chaque système a ses limites (voir notamment si ceci serait transposable au HO car les "trous" entre wagons sont plus conséquents qu'en N...) mais dans mon cas je n'ai plus aucun problème. Et la satisfaction de toujours voir les feux changer lorsqu'un canton vient de se libérer, de façon constante quelque soit la vitesse, le sens traction ou refoulement.

La nécessité des résistances de tirage... en effet mais on ne risque pas de l'oublier car sans, on obtient une lecture "random". De ci de là, j'avais lu qu'il fallait mettre des 10kOhms... ça marche tout aussi bien qu'avec des 4,7 qui "tirent" pourtant plus fort bien sûr.

Seconde expérience positive : l'affichage par le gestionnaire sur écrans OLEDs, avec une seule adresse et donc également au travers d'un multiplexeur. Mais là les distances sont encore plus courtes. En tous cas, aucun souci !

41

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: mai 07, 2021, 12:31:02 pm »

Il n'y aurait pas une capa dans cette loco ?

... toouute petite !! sert à rien ??

42

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: mai 06, 2021, 07:50:21 pm »

oh ! l'idée du 18V, c'est pas mal non plus !

Mais je revenais pour une correction. Car après avoir mieux regardé la vidéo, et jusqu'à la fin (avec la ligne droite), ça fait pas plus que +/- du 5kmh !!! Eh bé !

43

Présentez vous ! / Re : Bonjour à tous

« le: mai 06, 2021, 06:16:42 pm »

Maintenant à la retraite, j'ai une bonne raison de m'occuper les jours de pluie!

Haha ! ATTT-TENTION !! car quand on est vraiment pris pas le truc, il n'y a plus de météo !

Bienvenue et au plaisir par avance de vos points d'avancement

44

Vos projets / Re : Asservissement de vitesse pour les (trains des) nuls

« le: mai 06, 2021, 06:00:45 pm »

Jean_Luc - Voilà ce que ça donne chez moi :

C'est magnifique ! Et je devine que ni 5 ni 10 wagons derrière ne changeraient le résultat. Pas possible sans un asservissement n'est ce pas ?
Merci pour vos deux réponses, je me demandais où placer la barre.

Mais si je calcule : 15kmh, à l'échelle ça fait 2.5 cm seconde. Or si tes coupons sont comme il semble des coupons de 10cm, ça correspond au +/- 4 secondes par coupon ?

Car les 15kmh je pense que ça sera possible (sans pont de diode qui bouffe la plage de basses vitesse, ça c'est confirmé) mais moins que 15kmh... je suis à peu près certain que je ne pourrai pas : en dessous plus rien ne sort du moteur, sinon par bouffées entre deux hoquets (je parle toujours d'un mode "mesure" sans bouclage d'asservissement).

Et cette vidéo, c'est à quelle fréquence de PWM car j'ai - vraiment - de plus en plus besoin de comprendre.
En effet, après ce n'ième rappel sur les "bonnes ondes" et un peu penaud d'avoir tant insisté sur mes 40Hz, je me suis vu reparti à refaire quelques essais "à la base", avec une PWM native de MEGA2560 (la 5 pour tout dire). Et si je suis incapable de refaire la théorie, je peux au moins rapporter les faits :

- aux paramètres par défaut : constat immédiat d'un retard à l'allumage rédhibitoire, assorti évidemment de l'impossibilité de "vrais" ralentis. Par exemple : là où je paramètre les PWM de "décollage" sur 50, en moyenne (selon la loco... puis variable selon son humeur, ce qu'elle tire, si elle démarre en courbe ou non, la direction du vent etc), c'est vers PMW 100 qu'elle se décidait à démarrer ("bondir" serait plus exact), feux prés-allumés pendant les longues secondes de la montée des crans de la programmation habituelle pour un démarrage progressif. Et je parle d'ampoules bulbe, pas de LEDs, ce qui donne idée du courant de court-circuit. Si ça ça ne fait pas chauffer le néodyme !!

- Alors qu'en ajoutant juste : TCCR3B = TCCR3B & B11111000 | B00000101; pour une PWM à 30Hz, je reviens immédiatement à la souplesse de mes 40Hz maison.


Le cran 1 du DCC me laisse dont admiratif et rêveur.
Mais le DCC c'est comme un univers parallèle pour moi. Sauf que dans ce cas je ne doute pas (vraiment) que ça existe, alors j'ai deux questions pour Dominique :

- cran 1 (sur 128), cad correspondant à une PWM de 2 ?? (sur 255 donc). Avec un moteur supraconducteur sur paliers fluides ?? En tous cas avec une mécanique top forme sinon c'est pas possible !! (et sans rien à tracter ? car j'ai lu et je veux bien le croire qu'on ne peut pas embarquer l'asservissement dans une loco DCC mais c'est peut-être faux)

- et donc cran1 : véritable cran1 ou est-ce le cran 1 après un talon ? (l'équivalent de ma PWM de décollage)

45

Vos projets / Re : projet : barrette à led strip rvb

« le: mai 04, 2021, 08:26:50 pm »

Hé bonsoir Trimarco,

feras tu mieux que 1euro le wagon ?
J'ai découvert ce sujet à l'occasion d'un wagon témoin qui m'énervait à ne pas être allumé en refoulement : https://modelclub-draveil.eu/fr/eclairer-un-wagon-avec-des-leds-pour-un-euro

Du coup le sujet m'a intéressé. Et m'intéressera peut-être quand je me demanderai ce qui reste à régler !
Mais sur du N ça risque d'être un peu décevant non ? Comme mon wagon témoin qui maintenant est allumé en marche arrière... style clignotant. Mais les deux côtés en même temps.
Car quand je lis lis condensateur et supercondensateur, on est forcément au moins dans du HO ?