Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - trimarco232

Pages: 1 ... 17 18 [19] 20
271
pour en revenir, si vous voulez bien, sur la pertinence de la détection par transfo :
je trouve que l'intérêt est limité du fait de l'encombrement

les diodes ont l'inconvénient de la chute de tension, qui est de 0v7 dans le cas d'une détection par transistor et de 1v4 pour une détection par optocoupleur. Il faut de + équiper les sections pour lesquelles on n'a pas besoin de faire de détection, ceci pour équilibrer les potentiels

mais elles ont l'avantage d'être + discrètes et de permettre la détection en courant continu pour la compatibilité avec l'analogique
et souvent la chute de tension n'a pas d'importance, ou peut être aisément compensée au niveau de l'alimentation de la centrale

272
paradoxalement, ici il vaut mieux être en court circuit que de rester ouvert
mais il y a peut-être aussi quelque chose, qui nous échappe pour l'instant, qui fait que le montage rocrail n'est pas pur, mais ne présente en fait aucun danger ?

273
Bonjour,
quelle est la sensibilité du montage ?
n'y a-t-il pas de risque du fait de l'absence de resistance en série avec la zener ?

274
Le logiciel DCC++ / Re : Problème de retour d'info des decodeurs
« le: octobre 09, 2019, 01:04:10 pm »
noël approche  ;)

275
Le logiciel DCC++ / DCC++ avec ESP32 ?
« le: octobre 05, 2019, 08:08:01 pm »
Bonjour,
juste pour vous dire que j'ai écrit un bout de code qui pourrait servir de petit début à une station dcc animée par un esp32

le but est de générer des bits 0 et 1 en dcc, selon un principe proche de celui utilisé pour dcc++

explication :
un bit dcc ressemble à une période pwm, dont la durée est 200µs pour le bit 0 et 116µs pour le bit 1, le rapport cyclique étant dans tous les cas 1/2 ... simple ...
il faut donc après l'émission de chaque bit dcc, générer une interruption au service de laquelle on indiquera au timer la prochaine période à respecter : si la valeur du bit dcc change, on rentre la nouvelle période (200 ou 116µs) ; si la valeur du bit dcc ne change pas, il n'y a rien à faire /// dans tous les cas on dispose de 58µs pour rentrer la nouvelle période, un éternité pour l'esp32

auparavant il faut configurer un canal de timer :
- en pwm
- avec un rapport cyclique de 1/2
- pour qu'une interruption se déclenche à la fin de chaque période

concrètement :
(je suis loin d'être un pro du soft, je me suis débrouillé avec des fonctions dénichées dans le sdk, on peut sûrement faire mieux)

on commence par les déclarations :
// on utilise un module qui s'appelle ledc ... selon la tradition esp32 les modules pwm servent d'abord aux leds ...
#include "driver/ledc.h" // les fonctions spécifiques sont décrites ici

const int dcc_pin = 19;  // choix de la broche dcc out : n'importe laquelle peut être utilisée /// en se servant de la matrice du gpio

// setting PWM properties
#define dcc_sig_1_freq 8621 // le sdk demande la fréquence : celle-ci correspond à ~116µs ... quelque chose arrondira à la valeur exacte
#define dcc_sig_0_freq 5000 // 200µs (ici j'utilise des macros pour définir ces constantes)
const int dcc_pin_channel = 0; // il y a foison de canaux pwm, j'ai choisi le 1er
const int dcc_sig_resolution = 1; // nombre de bits définissant la résolution du pwm ; ici un seul bit (2 valeurs différentes) suffit
/// la résolution, c'est la granulométrie du rapport cyclique : la + grosse (ne) permet (que) de faire du 50%
const int dcc_sig_duty = 1; // pour le rapport cyclique de 1/2 il faut la valeur 1 (si non c'est 0 ... )
// initialisation de la variable au bit dcc 0 ; why not ; noter que la fonction utilisatrice veut le type uint32_t pour la fréquence
uint32_t dcc_sig_freq = dcc_sig_0_freq;

et voici le setup :
void setup() {
  // configuration du canal pwm 0 avec une fréquence et la résolution
  ledcSetup(dcc_pin_channel, dcc_sig_freq, dcc_sig_resolution); // ledc les faire ...
  // relie le canal pwm à la pin choisie pour la sortie pwm /// ... et dcc par conséquent
  ledcAttachPin(dcc_pin, dcc_pin_channel); /// ! pour détacher (si besoin), il faut impérativement passer par la matrice gpio
  // fixe le rapport cyclique du canal à 1/2
  ledcWrite(dcc_pin_channel, dcc_sig_duty);
  // programme l'interruption à la fin de la période
// je n'ai pas trouvé de manière élégante pour le faire avec le timer, alors je me suis rabattu pragmatiquement sur une interruption provoquée ... par le basculement de la pin
  attachInterrupt(dcc_pin, dcc_sig_isr, RISING); // l'interruption "dcc_sig_isr" provoquée à la fin de chaque période (voire au début de la suivante)
}

et l'isr :
pour vérifier le fonctionnement je génère une suite de 0/1/0/1 ad lib
il faudra adapter pour dcc++
void dcc_sig_isr() {
  if (dcc_sig_freq == dcc_sig_0_freq) dcc_sig_freq = dcc_sig_1_freq ; // inverse la valeur du bit dcc précédent
  else dcc_sig_freq = dcc_sig_0_freq ;
// la fonction qui permet d'écrire la nouvelle fréquence demande :
// - le mode : ici high speed, (au pif) qui va bien
// - le timer utilisé : j'ai supposé bêtement que le canal pwm 0 correspond au timer pwm 0 /// je crois qu'il y a 2 canaux par timer
// - la fréquence, of course
  // ledc_set_freq(ledc_mode_tspeed_mode, ledc_timer_ttimer_num, uint32_t freq_hz)
  ledc_set_freq(LEDC_HIGH_SPEED_MODE, LEDC_TIMER_0, dcc_sig_freq); // new -or not - period value
}

pour ceux qui veulent vérifier, un petit main qui fait travailler l'esp32 :
void loop() {
  delay(10); // mettez ici ce que vous voudrez
}


les mesures réalisées donnent des résultats très corrects : il manque parfois 41ns à une période. Peut-être mon modeste matériel, en tous cas, je n'ai pas les moyens d'en trouver la cause, et on est de toute façon largement dans les clous


 

 

276
il existe des shields pas cher pour convertir le format nano en format uno


le nano-every m'a l'air bien, à un prix très correct, mais il m'a l'air un peu tarabiscoté
toujours que je critique un peu

277
Vos projets / Re : panneaux depart arrivée aurillac
« le: septembre 21, 2019, 09:07:54 pm »
Bonjour,
j'ai jeté un rapide coup d'oeil :
- les oled i2c ne sont pas adressables
- les version 7 fils peuvent être commandées individuellement par leurs lignes CS
- les versions 4 fils doivent se trouver seules sur les lignes sda et scl. Si on en a plusieurs, "simplement" utiliser software i2c

278
Trucs & astuces / Re : DC_DCC_ALIMENTATION
« le: septembre 21, 2019, 08:43:30 pm »
l'électronique du décodeur consomme très peu de courant pour son propre fonctionnement, c'est pour cela que les régulateurs 5v ou 3v3 chauffent peu

toutefois quand il y a beaucoup de monde sur la puce, pour les décodeurs de son notamment, les régulateurs sont à découpage : exemple LS 5, si je ne m'abuse, le régulateur est un ic minuscule qui intègre le découpage et la self

279
Vos projets / Re : Eclairage constant des trains en analogique
« le: septembre 21, 2019, 08:34:27 pm »
si on met un pont à la place de la 1n4148, ça marchera dans les 2 sens

280
Vos projets / Re : Eclairage constant des trains en analogique
« le: septembre 21, 2019, 01:04:06 pm »
Bonjour,

quelques réflexions pèle-mêle :
(1) sans condensateur dans les voitures, le risque est de voir la lumière clignoter au gré des imperfections inévitables de la voie

(2) le 1er matériel industriel français en H0m arrive, est-ce qu'il supportera le traitement de l'éclairage bf ?

(3) la solution de l'éclairage bf date de l'ère de l'incandescence : est-elle encore pertinente avec les leds ?

(4) en bf, on doit pouvoir faire quelque chose avec des modules existants, mais il vaut mieux alors, peut-être, avoir du continu pur (pas pwm) pour la traction. Les modules : alim avec tension réglable, relais ou inter pour inversion du sens, géné bf, ampli bf + les selfs et condos pour les séparations

(5) ce que tu veux faire par arduino est théoriquement viable en ajoutant un pont en H : le pont sert pour inverser le sens, créer la pwm pour la traction, et dans les créneaux à 0 volts, créer la tension sinus avec un pwm dans le pwm   8)
mais :
a) à vue de nez  :-\, parmi les matériels habituels, ni l'arduino ni le pont en H ne seraient assez rapides pour travailler aux fréquences recommandées
b) le créneau à +Vcc serait vu comme un courant continu par les condensateurs de l'éclairage bf, qui le bloqueront. Ton éclairage s’affaiblit comme la vitesse augmente ... il faudrait pallier en offrant les 2 sources : bf + continu à l'éclairage -> trop compliqué

(6) on peut imaginer superposer la pwm de la traction au bf de l'éclairage, mais dans ce cas :
a) la partie impulsionnelle du pwm serait en partie bloquée par la self en série avec les moteurs, comment serait alors la réponse de ceux-ci ?
b) la partie impulsionnelle du pwm s'ajouterait à la bf de l'éclairage, cela pourrait créer des variations de l'intensité de l'éclairage, qu'il faudrait compenser ?




c'est une question ancienne, mais restée d'actualité ; il serait en effet intéressant d'y retrouver une solution, + ou - élégante, avec les moyens actuels


281
Trucs & astuces / Re : Comment faire un reset software d'un ATMega328
« le: septembre 15, 2019, 10:52:39 pm »
Bonjour,
très intéressant, Dominique, peux-tu nous faire un retour ?

282
Débuter / Re : Rétrosignalisation
« le: septembre 11, 2019, 10:33:13 pm »
merci d'intervenir spontanément

je suis un peu hs, donc je créerai un topic dédié quand j'aurai quelques éléments

à Pierre59, ton système est-il décrit quelque part ?

283
Débuter / Re : Rétrosignalisation
« le: septembre 08, 2019, 10:12:10 pm »
merci Dominique, je vais regarder la bibliothèque
pourquoi pas, c'est parce que les 2 modes cohabiteraient en même temps sur le même réseau, les cantons commuteraient de mode selon la nature du train qui les parcourent
bien sûr, il ne faut pas se tromper, un manque de fiabilité du suivi des trains constituerait le risque qui fait capoter le projet
passer d'un mode à l'autre ne doit pas me poser de problème vu les modules que je compte utiliser (blue pill). Le bus de rétrosignalisation devra aussi comporter une ligne de synchro dcc et une ligne de synchro du pwm

du pain sur la planche donc, et il ne faudra pas être pressé pour voir le résultat, tout reste à faire :
- hard
- soft analogique
- soft digital
- soft mixte
et seuls les deux 1ers sont à l'ordre du jour


284
Débuter / Re : Re : Rétrosignalisation
« le: septembre 08, 2019, 05:20:13 pm »
J'ai le sentiment qu'il vaudrait mieux réserver le mixed grill à la plancha ?
c'est une vielle idée, genre avoir un engin ancien en N, qu'il nest pas possible d'équiper même avec le + petit décodeur, mais qu'on souhaite quand-même faire circuler, avec les autres trains, sur son réseau numérique ...
on peut en effet discuter de sa pertinence, en ce sens qu'il semblerait que cette possibilité n'ait jamais manqué à personne depuis l'avènement du numérique

pour un réseau que je souhaite pouvoir commuter en analogique / numérique, j'ai bien entendu la possibilité de le faire par commutateur sec ou relais, mais je veux une solution entièrement électronique. La base sera donc là pour réaliser cette exploitation mixte simultanée
quand on fait ses propres pcb, il faut essayer de penser à tout, y compris à ce qu'on ne voit pas venir sur le moment, dans le but de ne pas avoir à refaire ultérieurement
et tant qu'à s'em... à faire soi même, autant tenter d'y apporter une + value
j'essaye donc de collecter le + d'éléments possibles avant de me lancer

ou bien je me suis trompé de rubrique ?

285
Débuter / Re : Rétrosignalisation
« le: septembre 05, 2019, 05:43:48 pm »
merci Jean-Michel,
en fait ce que je recherche c'est une solution élégante qui fonctionne aussi bien en analogique qu'en digital
(le fantasme c'est d'avoir un suivi des trains qui permet de mélanger les 2 modes. Pour chaque canton -ou circuit de voie - il y aurait un booster qui commute d'un mode sur l'autre si besoin, en assurant la détection et la rétrosignalisation)

Pages: 1 ... 17 18 [19] 20