Messages

151

Composants / arduino nano : faut-il se dépêcher d'en acheter ?

« le: septembre 05, 2021, 11:32:46 am »

Bonjour,
c'est en passant commande pour des nouveaux avr que je me suis rendu compte d'une indisponiblilté durable - 1 an - de ces produits microchip
le covid et la pénurie mondiale de semiconducteurs sont passés par là
pour les atmega328p chers à nos uno, nano, micro, c'est pareil
le microcontrôleur coutait 1€50 du temps de sa disponibilité, c'est 3-4€ maintenant
il serait logique que cette hausse de prix et cette pénurie touchent aussi les arduino à base de ces atmega : pour l'instant, il y a encore du stock et des prix corrects : si vous avez des projets dans les ... 2 années à venir, je me permetrais de vous suggérer d'anticiper
affaire à suivre
les prix ont été multipliés par 4 sur beaucoup de produits, et comme la tva s'est ajoutée, ça fait x5 ...

pour ma part, je vai passer sur stm8s pendant cette période (repasser, en fait, je connais) : mais bien que fabriqués en chine, donc en principe non soumis aux aléas de la production occidentale, il subissent quand-même une hausse de tarif par ricochet
j'en ai commandé une cinquantaine pour être tranquile, on verra bien si le vendeur veut les expédier au prix affiché ...

152

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 01, 2021, 09:23:06 pm »

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

153

Vos projets / Re : Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 01, 2021, 12:33:55 pm »

Dans tout ça il faut largement moduler les "vérités" qui sont lancées ici ou là...
(...)
la centrale insère systématiquement une perturbation (ou un signal à destination d'un autre dispositif, or de la norme DCC)

si c'est le railcom, c'est dans la norme

vous voulez un coup de main pour quelques tests, n'hésitez pas.

(hs) j'ai une centrale à faire avancer, mais pour le coup de main il faudrait + que quelques tests ... (hs\)

154

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 01, 2021, 10:51:59 am »

@Trimarco : dans ton analyse, tu exclu le bit de fin de paquet du préambule suivant..

oui, je n'avais pas non plus encore incorporé, au stade où j'ai remis le projet dans une boîte, le calcul de la cheksum 
terminer le paket dcc par le 1er bit du preamble du paket dcc suivant est une bonne idée, si on utilise le pwm : ainsi, si le soft n'est pas prêt pour donner le paket suivant au timer, celui-ci continue tout seul à générer des bits dcc 1 entiers , ce qui n'est pas péjorant

155

Vos projets / Re : Re : Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 01, 2021, 10:51:23 am »

(... !)
J'aimerai bien mais sur Mac, point de soft possible

c'est pour cette raison, entre autres IDE exotiques, que je me coltine windows aussi

156

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 01, 2021, 10:25:31 am »

Bonjour,
pour ceux que ça intéresse, l'analyse logique à 10 balles :
- acheter un clone salae ... + les petites pinces qui vont bien (que j'ai soudées pour qu'elles aillent mieux) + des rallonges dupont de qualité
- télécharger et installer le logiciel salae, c'est juste pour avoir le driver
- télécharger et installer PulseView ; on peut voir les bits à ce stade
- télécharger "sigrok-DCC-Protocoll" ; extraire le dossier "DCC" et l'ajouter dans le repertoire "decoders" ; chez-moi :C:\Program Files\sigrok\PulseView\share\libsigrokdecode\decoders
- dans la config du decoder, dans "01 or 10", choisir "10"

(aucune raison que le sniffer à base d'ESP32 ne fonctionne pas parfaitement)

157

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: septembre 01, 2021, 02:45:36 am »

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 

158

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: août 31, 2021, 07:47:40 pm »

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

159

Vos projets / Re : Re : projet centrale "LaBox" wifi DCC++ Can

« le: août 31, 2021, 01:14:07 am »

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)

160

Vos projets / Re : signaux sncf réalisés avec un pcb, avec commande 4 fils muliplexée

« le: août 29, 2021, 09:17:30 pm »

il n'y avait qu'à demander

161

Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can

« le: août 29, 2021, 06:53:18 pm »

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

162

Vos projets / Re : signaux sncf réalisés avec un pcb, avec commande 4 fils muliplexée

« le: août 29, 2021, 07:00:24 am »

(chevauchement en cours avec le topic de palou : ne pas oublier de lui répondre, la lecture du mien peut attendre)

la fin des glitches
voir le dessin ci-dessous
en 1er, j'ai repris le dessin du "pwm problématique" : on voit que le souci est que les opérations de multiplexage (sélection de la résistance, choix des polarités high/low, choix des impédances de sortie outout/input) se font alors que le signal pwm est déjà actif ;
la solution c'est de geler la période pendant laquelle les opérations de multiplexage se produisent ; on aurait quelque chose comme le dessin "notre pwm idéal" : ici, pendant la durée des opérations de multiplexage, le sinal serait coupé (haute impédence, partie orange), puis rétabli pour faire la partie utile du rapport cyclique (entre les flèches grises) ; cette partie utile serait alors amputée de 1 ou 2%, mais c'est sans importance, car de toutes façons on est déjà multiplexé dans le temps : un timeslot ne dispose que de 20% maxi du temps pour faire éclairer la led, 2% de 20%, c'est peanuts ;

vous vous souvenez (#3) de la broche InH du 4052 est relié à la broche "pwmux" de l'arduino (voir le dessin #2)
j'ai dessiné un petit rond au droit de cette entrée, cela veut dire qu'elle est active à l'état low ; donc high = gaute impédance (coupé), et low = donné (sélection selon les entrées A et B) ;
on est donc dans le cas du dessin "pwm 4052" : le timing est le suivant :
- de 0% à 2% : la sortie pwm de l'arduino se voit imposer une valeur minimale de 2% ; ce qui correspond à la durée pendant laquelle le 4052 sera d'office en haute impédance ; on pourra effectuer tranquilous les opérations de multiplexage pendant ce temps ;
- de 2% à 100% : on est dans la partie utile du signal ; on fera varier le rapport cyclique de 100% vers 2% pour faire varier l'intensité lumineuse de la led de 0 à 98% , cad un maping de 0 -> 100% vers 100 -> 2%

à ce stade on a jeté les bases de quelque chose qui devrait (pourait) fonctionner, reste à le prouver ; un nano, ça a 2 sorties pwm 16 bits ; ça vous dirait un shield avec optocoupleur pour faire un décodeur dcc, et avec 2 4052 + résistances pour commander 2 signaux sncf complexes ?

163

Vos projets / Re : signaux sncf réalisés avec un pcb, avec commande 4 fils muliplexée

« le: août 28, 2021, 06:58:47 pm »

le glitch logiciel
le problème n'était pas matériel mais logiciel, voyons le dessin ci-dessous :
on les 5 timeslot avec des couleurs différentes, et des rapports cycliques de pwm différents (cad. chacune des 5 leds éclaire avec une intesité lumineuse différente : ce n'est pas le cas dans cette application, mais théoriquement possible)
les 5 timeslot constituent une trame, il y a 3 trames sur le dessin ; les trames servent à incrémenter ou décrémenter le rapport du pwm, le cas échéant, selon les leds, selon les besoins
l'avancement des timeslot et des trames est "interrupt driven", cad. on ne se sert pas de micros(), lais on génère une interruption à chaque nouvelle période du timer (à chaque changement de couleur sur le dessin), puis on compte les 5 timeslot, puis on compte les trames ; il faut un certain nombre de trames pour compléter l'alumage, l'extinction, ou le clignotement d'une led, on en reparlera

où est le problème ? il apparait clairent dans la ligne du bas, on observe le timeslot bleu à la loupe : l'interruption, c'est quand la rampe 'le timer) passe à 0 ; c'est le début de la période pwm, c'est là où la sortie pwm est mise à l'état high ; suite à cette interruption, il faut faire un certain nombre de choses, dont le timing est donné très schématiquement par les flèches grises :
d'urgence
- déselectionner la résistance de la led du timeslot précédent, au niveau du mux
- sélectionner la résistance de la led du timeslot en cours
- donner les bons niveaux, high ou low, aux sorties, selon le sens de la led sélectionnée
en moins urgent
- entrée la valeur du pwm de la led suivante dans le buffeur ; cette valeur, on l'a vu, sera effective au début de la prochaine période pwm

le souci, donc, c'est que même si on se dépèche de faire les instructions urgentes, mêmes si le tout dure moins qu'une microseconde, l'opération n'est pas pure, et ça se voit !
par exemple, quand la nouvelle période pwm commence, la sortie pwmm est immédiatement active, alors qu'on est encore connecté sur la led précédente, qui doit peut-être être éteinte, en tous cas qui n'a pas besoin qu'on lui mette un rab d'impulsion lumineuse
de même, en ne commutant pas instantanément au niveau du mux (c'est impossible !), on prive la led en cours du début de son rapport cyclique, et ça se voit aussi : sans pitié, le glitch logiciel !

il faut trouver une parade

164

Vos projets / Re : signaux sncf réalisés avec un pcb, avec commande 4 fils muliplexée

« le: août 28, 2021, 01:03:51 pm »

le glitch du pwm
il suffit de faire une recherche, et on trouve plein de gens, oscillogrammes à l'appui, qui y sont confrontés
dans l'illustation, on voit un signal pwm de rapport cyclique ~50% qui passe à un rapport ~10%, et entre temps il s'est passé un truc, c'est le gltch ; j'ai dessiné en orange l'effet du glitch
les conséquences d'un tel glitch sur des commandes de moteur, ou de chauffage, par exemple, sont négilgeables, à fortiori si la fréquence du pwm est élevée
par contre pour des leds, même à des rapportrs élevés, ça saute aux yeux, donc à fortiori si le rapport cyclique (éclairage vu comme faible), est petit
il faut absolument s'en prémunir ;

au niveau électronique, par exemple pour un pwm généré directement par le timer d'un microcontrôleur (arduino), le problème se passe quand on change le rapport cyclique alors que la période est en cours
on a une rampe ascendante qui se répète périodiquement, en dents de scie ; au début de la période, cad. au bas de la rampe, la sortie pwm est mise à high ; quand la rampe atteint la consigne, la sortie pwm passe à low ; si la consigne est basse, la rampe l'atteint rapidement, l'impulsion est courte (rapport cyclique faible) ; si la consigne est élevée, la rampe mettra du temps à atteindre la consigne, l'impulsion est longue (rapport cyclique élevé)
revenons à l'exemple de notre infortuné internaute, que s'est-il passé ?
au début, le rapport cyclique est de 50%, au début de la rampe, la sortie pwm est high, la rampe se dirige vers les 50% pour atteindre la consigne, et mettre la sortie à low ; or, quand la rampe arrive vers les 40%, la consigne est brutalement mise à 10% : la rampe n'a plus aucune chance d'atteindre la consigne, car elle est allé au-dessus, la sortie restera high au moins jusqu'à la fin de la période, cad. quand la rampe (descendra brusquement) à 0 ; c'est le glitch électronique du pwm
les fabricants de microcontrôleurs et autres ics donnnent la parade à ce glich : la nouvelle consigne, quand elle est entrée par le programmateur (internaute du site locoduino), est mise dans un buffer ; elle n'est transferrée comme consige effective que quand la rampe atteint 0 (début de la période) ; le glitch est mis en echec
notons que ces notions sont aussi à prendre en compte par qui écrirait du pwm purement en soft ; ce n'est pas ma philosophie : les périphériques sont là, utilisons les  (vaste débat que je clos aussitôt)

confronté au glitch, j'ai donc programmé l'arduino pour la mise en buffer de la consigne ... mais les glitches étaient toujours visibles, le problème était ailleurs ... 

165

Vos projets / Re : signaux sncf réalisés avec un pcb, avec commande 4 fils muliplexée

« le: août 28, 2021, 11:42:12 am »

le multiplexage
pour rappel, le but est de simplifier au maximum le câblage du signal ; un panneau type H comme celui qui est illustré, comporte 10 feux ; généralement les productions commerciales proposent 10 leds, donc 20 fils qu'il faut dévernir et manipuler et souder avec énormément de précautions
ici, on a 4 fils, il n'y a pas photo au niveau de la facilité de mise en oeuvre, et de plus le gros du câblage est déjà fait par le pcb au niveau des leds ;
on a vu que la partie résistances du multiplexage est résolu (il y a d'autres méthodes que le 4052, on en parlera), reste la question du soft ;
quand on a un paneau du type H, (et pas mal d'autres types), le nombre de feux succeptibles d'être allumés simultanément est de ... 6 !
en effet, quand les panneaux de cette époque passent d'une indication vers une autre, la commutation est faite par des relais, c'est pratiment instantanné ; par contre, alors que les nouveaux feux s'allument progressivement, les anciens s'éteignent progressivement, c'est l'inertie de la chaleur des filaments ;
en illustration, (je n'ai pas pu résister), les arguments de LDT pour vanter la qualité de ses décodeurs : c'est faux ! j'ai dessiné la courbe correcte à droite ;
si on passe d'une indication RR+A à une indication C, les feux qui s'éteignent sont RR1, RR2, A, et Oe(illeton), alors que ceux qui s'allument, c'est C et S : on a bien 6 feux allumés en même temps ; notons que dans mon cas, RR1 et RR2 sont en série, ils ne sont vus par le système que comme 1 seule led, ce qui ramène le nombre de leds "simultanées" à 5
or le système du multiplexage ne permet, par essence, de n'alumer qu'une seule led à la fois ... il faut un truc

le truc, c'est la fameuse persistance de l'impression rétinienne : on va allumer les 5 leds à tour de rôle, circulairement, rapidement, l'oeil  humain n'y verra que des feux
pour ce faire, on va diviser le temps en 5 timeslots, qui se répéteront circulairement ; chaque led qui devra briller, s'alumer, s'éteindre, ou clignoter, disposera de son propre timeslot ; il faudra donc gérer l'affectation des timeslots en fonction des besoin ; on a dit 5 leds maximum, mais aussi 1 led minimum, pour Cv ou M

à l'intérieur de chaque timeslot, il faudra faire varier la durée effective de l'alumage de la led, en fonction de l'intensité lumineuse ; j'utilise pour cela le pwm, ce qui me fait prêter le flanc à l'ennemi mortel de ceux qui font ce type de montage : le glitch du pwm ! ce sera lui, ou moi