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.


Sujets - laurentr

Pages: [1] 2
1
    Bonjour

    Souvent le terme ARDUINO englobe de nombreux anspects aux frontières parfois mal connues.

    L IDE Arduino (interface de programmation)  est une interface simplifiant la réalisation du code puis son injection dans des microprocesseurs.
    Il utilise le langage C++.

    Il a permis de développer la communauté de pratiquants de l'électronique en passant de l'électronique discrète (à composants "standards"  à l'électronique programmable.

    A LOCODUINO comme ailleurs les domaine d'application sont nombreux.

    ARDUINO doit une part de son succès à la réalisation de cartes mues par un CPU microcontrôleur offrant des performances redoutables pour un prix très compétitif.

    Parmi les plus connus et souvent utilisés ici on retrouve dans la famille AVR:

    les ARDUINO UNO et MICRO équipés de la puce ATMEGA328P
    les AVR MEGA à base de CPU ATMEGA2560
    les TINY à base  de CPU ATTINYx5 comme les ATTINY85, 45, 25.[/li]


On voit ici que des chiffres apparaissent et il vont avoir un rôle pour identifier les générations de processeurs et ou leur ressources.
Sur le ATTINY85 on retrouve 8K de mémoire contre 4K seulement pour le 45 et seulement 2 pour le 25.
Le chiffre 5 étant l'indice de la série de ces processeurs.

Apparus il y a plus de 10 ans ces processeurs ont vu leur descendance s'étendre en apportant leur lot d'innovations et d'apports.

A titre d exemple de nouveaux processeurs sont aussi devenus "compatibles ARDUINO", c'est à dire programmables via l'interface IDE ARDUINO.
Les plus connus sont le LESP8266 et l'ESP32 (dans leur différentes déclinaisons)

Dans la lignée de leur ainés chez ATMEL MICROCHIP les AVR on vu la gamme complétée des AVRx:
On distingue 2 groupes de façon générale: (avec qq exceptions):
les TINY dont le nombre de broches est <=24
les "MEGA" qui ont dont un nombre de broches >24

Dans ces 2 groupes plusieurs générations se sont suivies: série 0, série 1, série 2.

On se reportera aux datasheets de chaque item pour leur caractéristiques propres.

Toutefois ces CPU disposent d'organes communs, souvent méconnus dont nous allons présenter quelques éléments utiles:
TIMER
EVENT
GLU LOGIC
COMPARATOR

Pour assurer la portabilité entre le code et le soft on a recours a des frameworks qui vont faire "en sous marin" des opérations complexes avec une mise en œuvre simplifiée.
Pour les AVRx on dispose de 3 framework selon les CPU:

AVRX MEGA série 0 : les célèbres ATMEGAx08 et X09 dont le ATMEGA4809 qui équipe les ARDUINO NANOEVERY ==>framework MEGACOREX
https://github.com/MCUdude/MegaCoreX

AVRX "TINY" pour les "petits CPU" serie 0, 1 et 2: ==>framework MEGATINYCORE
https://github.com/SpenceKonde/megaTinyCore

AVRX "MEGA" serie 0, 1, 2 avec : ==>framework DXCORE
https://github.com/SpenceKonde/DxCore

Ltr



2
Vos projets / RailCom: Générateur de CutOut avec booster
« le: avril 28, 2024, 04:21:36 am »
Bonjour

J'arrive un peu après la bataille... désolé

Toutefois je vous présente le "petit dernier".

BOOSTER RAILCOM(Able) avec toute la circuiterie qui va autours! Elle est ici très réduite du fit des apports des composants natifs du CPU. (Events, CCL, AC, Timer B, ...)

Le cœur est un CPU à 32 broches AVR type ATmega 4808 (celui du Nanoevery) ou un AVR Dx ( idéalement les DB et DD).

(On peut avec certains TINY de la série 2 arriver à quelque chose de très similaire, sinon il faut re ajouter des composants externes)

Le hard  reprend les signaux DCC d une centrale n'émettant pas de CUTOUT sur sa sortie signal. Entrée sur les plots C D E normalisés.
La conversion de puissance est confiée à un L6203
La protection est fixé à 4A
Alim DC DC locale pour alimenter le montage depuis l'entrée puissance.
De nombreuses leds sont ici présentes pour faciliter le décodage/troubleshooting des I/O.

J'ai passé un peu de temps à sélectionner les répartitions des pins au mieux de capacités/restrictions des CPU 32 broches.
L idée était d utiliser le plus possible tous leurs composants internes pour piloter l'ensemble du montage.

Fortement inspiré des montages BOOSTER CDE de PACO et du DCC BOSTER d'OPEN DCC est ici une évolution vers un CPU plus contemporain.

Que du classique...

Cote code je pars de la librairie d'AIKO PRAS ( AP DCC LIBRARY) qui doit être complétée pour ce montage.
Comme elle permet lors de l'assemblage d'identifier le bit 1 de fin de trame on sait alors partir de ce point pour générer le cutout et piloter les différents I/O.

A noter que le composant COMPARATEUR AC0 est utilisé pour la protection et que son déclanchement coupera le fonctionnement du montage ( AC0 OUT est mixé dans les CCL LUT dont es tables de vérités sont adaptées)

Ltr

3
Bus DCC / Optimisation du hardware autour de l opto 6N137
« le: mars 28, 2024, 10:45:34 am »
Bonjour

Au hasards de mes recherches je suis tombé sur cette mine d'information pour optimiser le hardware autour de l opto 6N137 qui est très souvent utilisé comme interface CPU <-> DCC.

https://wakwak2popo.wordpress.com/2020/12/11/dcc-sniffer/


On voit que les tests poussés à l'oscillo montrent bien un optimum pour avoir des fronts les plus nets possible.

Aussi cela se fait avec la combinaison d une capa de 1nF en entrée cote signal DCC, la diode 1N4148 et une résistance de PULLUP mise à 470r

Information précieuse qui favorisera la qualité des signaux transmis à nos équipements.


Laurent

4
Vos projets / LaBox : Evolutions ?
« le: février 19, 2024, 06:42:41 pm »
Bonjour

Une question pour laquelle je n'ai pas trouve de réponse claire et je m'en excuse, vous pourrez m'apporter vos compléments:

Quand vous évoquez RAILCOM avec LABOX ( ou DCC truc truc ( all inclusive!)...) de quoi est il question précisément?
On parle d'incompatibilités.
De quelle natures sont elles?

A/ générer le CUTOUT entre grosso modo 29us et 488us?
B/ récupérer et analyser les retours d'info des messages RAILCOM durant le CUTOUT?
C/ autres points?

J'avoue ne pas avoir réussi à identifier de quoi il retourne car en opposition avec les info du projet de centrale de Christophe qui elle supporte RAILCOM et pourtant partageant une hardware commun à base d'ESP32 (peut être pas le même?)

D'avance merci pour vos éclairages.

Ltr

5
Vos projets / DETECTION ET PROTECTION CONTRE LES COURT-CIRCUITS
« le: février 07, 2024, 02:55:02 pm »
Bonjour

Ce sujet important est souvent abordé en filigrane mais n'a jamais encore fait l'objet d'une section dédiée.

Consacrons nous y.

Traditionnellement il est d usage de mesurer la consommation et en cas de dépassement d un seuil fixé de procéder à une coupure de l alimentation, ce qui met fin au court circuit ou à la surcharge.

Historiquement des fusibles à plomb, calibrés assuraient ce rôle.

D autre solutions existe aussi comme des lampes ballaste.

La solution "ultime" repose toujours sur un temps de réaction le plus bref possible ce qui assure l'efficacité de la protection.

Un disjoncteur mécanique actionne des contacts d une position fermée assurant la continuité à une position ouverte qui coupe la continuité!.
C est ce que réalise un relais

Les temps de bascules sont de l'ordre de quelques milli secondes. (ms) à quelques dizaines de ms.

Si ceci est mécaniquement rapide c'est électriquement ( et donc électroniquement) long voir très long.

En effet nos microprocesseurs travaillent à des vitesses beaucoup plus rapide. Les composants électroniques aussi.

Autant alors optimiser le tout dans une mise en œuvre visant une efficacité optimale que nous allons pouvoir développer dans ce post.

Ltr


6
Vos projets / BASIC_AUTO_LOOP_REVERSER
« le: janvier 31, 2024, 10:58:26 pm »
Bonjour

Sous cet acronyme Anglo saxon un peu barbare se trouve un petit montage efficace pour gérer une boucle de retournement ou toute autre forme de mise en œuvre nécessitant une inversion des polarite des rail DCC. ( auto sensing)

Cette version repose sur la bascule d'un relais lors de la mise en cour circuit de la détection entre une zone a inverser et une zone fixe ( non inversable) servant de référence comme point fixe.

A noter que cette détection par CC ( court-circuit) est non destructrice au niveau des composants mis en œuvre ici :).

Il se peut toutefois que vos décodeurs de locomotive n'apprécient pas à outrance ce genre de situation... Mais c'est un mécanisme qu'utilise de nombreux produits du commerce.

Le principe repose sur le bypass des diodes de l'opto coupleur bidirectionnel ( BA354 par exemple)  par le premier essieux franchissant cette séparation en cas de polarites opposées entre les parties de rail fixe et  inversable qui va générer une interruption sur une entrée d'un CPU qui commute alors les sorties d un relais pour procéder aux alignements des polarite des deux zones.

L'alimentation n'est pas prélevée sur le courant DCC ce qui évite d'avoir une détection par consommation de courant faussée par l'énergie prélevée sur la zone fixe par le montage pour fonctionner.
Elle provient donc d'une source externe DC en 5V.

A noter que le montage doit impérativement être alimenté en 5V courant continu.

2 sorties auxiliaires permettent via une entée additionnelle d'utiliser une autre source de tension et de récupérer l'état de commutation, ce qui sera précieux pour un monitoring éventuel ou une visualisation, voir un asservissement.

Cette alimentation externe peut être en 3V3 ;) ( idéal pour aller vers un CPU type ESP32) ou si en 5V un petit jumper présent sur la carte fera gagner un raccordement dans un bornier :)

A noter que ce dispositif me semble être très rapide pour commuter et sera toujours liée au temps de bascule du relais de l'ordre de 3 à 10 ms.

hormis remplacer le relais par d'autres composants, il sera impossible d'aller plus vite!

Notez qu'un petit bouton poussoir est aussi présent pour commuter par pression la position qui est indiquée visuellement par deux leds( ex rouge et verte)

Voici déjà le schéma correspondant en plus  d'un aperçu du montage.


Encore quelques lignes à écrire pour vous soumettre cet ensemble complet.

Laurent













7
Vos projets / Les SATELLITES AUTONOMES: évolutions du socle initial
« le: janvier 18, 2024, 12:08:01 pm »
Bonjour

Comme cela avait été évoqué dans la présentation du fil de présentation de cette solution novatrice et innovante nous discuterons ici d'évolutions possibles/utiles qui viennent compléter la solution initiale conçue par Christophe.

Ces évolutions peuvent être de différentes natures tant soft que hard.

Une approche du hardware va être de reprendre l'existant avec un nouveau design des cartes, apporter une approche modulaire des blocs de composants ( alim, détection, alimentation, extensions, introduire un nouveau bus de communication (I2C), …)

Pour vous donner un avant gout de cela voici une vue de deux blocs fonctionnels portant pour l'un la mesure de courant/tension ( SENSOR INA219 via bus I2C) et l autre l'identification RAILCOM telle que déjà présentée par Christophe et Michel.

La suite au fur et à mesure sur cette branche Hardware.

Pour la branche soft je vais apporter quelques compléments dans les prochains messages pour vous exposer notamment le gestion des grills d'aiguillages ( zones complexes denses, TJD, TJS, croisement, bretelles, "bif",...)
Ceci se portera aussi sur quelques ajouts hardware ( relais, puces I2C, …) et un peu de câblage inter cartes/modules.


Laurent



8
Vos projets / Décodeur de locomotive multifonctions
« le: octobre 18, 2023, 12:24:53 am »
Bonsoir à tous
 Quitte a bien faire je pense qu'il faut “pousser” un peu plus loin sur différents axes que j expose ci après.
En terme de coût pour une fabrication industrielle finalement le delta sera surtout sur les composants mis en œuvre principalement

Premier point: la régulation de tension: on le voit tout de suite cela chauffe ce qui est contre productif à ce qui est recherché.
Point de salut sans un convertisseur DcDc pour éviter le phénomène.
Il y en a beaucoup de différentes marques avec des caractéristiques aussi très hétérogènes.
Un choix peut être opéré.
Mon dévolu irait volontiers sur un MPM3510A
C est un cousin de celui présent sur les Arduino Nano Every avec une entrée plus haute en tension jusqu'à 36v en entrée et 1.2A en sortie.
4 composants basiques autour est on a une régulation solide sur le 5v.
Son seul inconvénient va été sont prix.( proche de 5€)

Point 2 :
Plus discutable mais le 328p… est “un peu hasbeen”…
Pour le même prix de CPU et tout aussi compatible nous avons les AVR de générations plus récentes ( séries d Avr0/1/2 et leur cousins Megatiny) qui vont aussi offrir plus de possibilités et de capacités avec un prix et une dispo similaire sinon meilleure!
On a l'embarras du choix.
Disons un avr32dd32 par exemple ou un atmega4808 en 32 broches sont de bons candidats.
L intérêt du 32 broches est la portabilité au travers toutes les familles. En cas de manque de place il faudra descendre en broches au sacrifice de ressources hardware. Ou à l inverse monter vers 48 mais la toutes les déclinaisons ne seront pas disponibles.
Si 32Ko de flash sont "étroits" on pourras passer à 64Ko.
Les librairies MEGACOREX, DXCORE  et MEGATINYCORE appelleront facilement la prise en charge de ces puces.


Point 3
Comme je l'avais indiqué dans mes échanges avec “le Belge” il est possible de basculer de la lib NMRA vers celle d Aiko Pra ( AP Dcc library ) optimisée pour ce hardware ( séries 0/1/2 AVR ou MEGATINY)

Elle n'est pas aussi complète en revanche pour Railcom, Consist mode … mais ça peut être là une opportunité collective de l'enrichir.

Point 4
Les dimensions d un décodeur sont normalisées en interface 21MTC ou Plux22
En gros 15x30 mm maxi ( dim max des versions sonores…)
Donc sans le son on peut aussi cibler cet encombrement.

Pour tenir le challenge un passage en 4 couches sera de mise pour le routage …
Mais la encore rien d'insurmontable .

Point 5
Pont en H… je préconise  un TB67H450 qui conviendra même aux modèles les plus gourmands  à piloter
Sinon des demi ponts à sélectionner et au pire celui déjà sélectionné.

Point 6
Choisir des Mosfet compacts pour la gestion des I/O


Tout cela combiné doit offrir une solution robuste

Alors oui cela aura sûrement aussi un coût plus élevé surtout en faible volume mais on parle aussi d un élément plus abouti techniquement.

Qu'en pensez vous ?

Laurent




9
Bonjour

Je profite des ponts de moi de mai ( hélas le dernier sic!) pour avancer sur une problématique "simple" et construire une solution facilement déclinable pour pouvoir piloter un moteur via pont en H à une fréquence "qui va bien "idéalement pour un décodeur embarqué.

De quoi parlons nous plus précisément:

Coté CPU:
les candidats sont les AVR séries 0/1/2 ( ATmegax08,x09, AVR DA DB DD EA ( et futurs EB) et la famille des MEGATINY Attinyx6 x7 des séries 0/1/2.
Tous sont dotés du TIMER A ( ( certains ont en même deux A0 et A1).
Ces derniers sont tout particulièrement indiqués pour la génération du PWM.

Néanmoins par "hardware design" toutes les broches ne sont pas nécessairement éligibles ou disponibles selon les modèles (ref et/ou nombres de pins) , il va donc convenir de bien avoir en tète les datasheets! associées au hardware

Par "défaut" sur ARDUINO NANO EVERY équipé d'l'ATMEGA4809 pour des raisons de compatibilité les fréquences des broches supportant le PWM HARDWARE ( = sans BIT BANGING) ont une fréquence "limitée" à ~1Khz pour les plus rapides.

Ce ~1Khz qui convient fort bien pour des usages tel que le pilotage d'une led est en revanche "insuffisant" (comprendre trop lent) pour le pilotage d'un moteur. On peut mieux plutôt simplement.

Par chance on peut modifier les "paramètres qui vont bien" pour passer à des fréquences plus élevées de plusieurs dizaines de Khz.

Les décodeurs ESU par exemple proposent 40khz et jusqu'à ~50Khz sur leur dernière génération de produits. C est donc une plage bien adaptée.
Je me souviens du 15(k) 2/3Hz cher à certains pour piloter leur modèles miniature! ...

Pour s'en approcher il y a deux approches:
fixer une fréquence donnée ici par exemple 40Khz et construire autour la solution quelque soit la vitesse du CPU.
laisser le fréquence proportionnelle à la vitesse de CPU.

Par défaut les librairies MEGACOREX, DX CORE et MEGATINY CORE vont configurer pour rester 100% "Arduino" compatible le TIMERA en mode "SPLIT"  (2x 8 Bits mode ) avec un prescaler de /64.
(voir doc MICROCHIP TB3217)
On a ainsi 16Mhz (160000000/64/256 valeurs en 8bits) 976Hz ~1Khz

Et bien si on joue sur ce prescaler on joue alors sur la fréquence de sortie ( Attention ce n'est pas sans impact!)

Ainsi on peut obtenir toujours en 8bits @16Mhz 40Khz via le calcul suivant 16000000/2/200 = 40000hz = 40Khz Magique non?
Si on laisse par défaut on aura @16Mhz  16000000/1/256 = 62.5Khz et 16000000/2/256 = 31Khz250

Si on a une vitesse de CPU plus élevée disons à 20Mhz on a alors 20000000/2/256 = 39062.5hz ~39Khz et 20000000/1/256 = 78125Hz = 78Khz125

On voit donc le coté "facile" de la chose a l aide de quelques parametres judicieusement choisis.

Cependant il faut aller encore un peu plus loin et les notes détaillées de la librairie DXCORE explique le bien fondé de travailler avec 255 valeurs et non 256.
Interet un analogWrite (x,0) se traduira comme un DigirtalWrite (x,LOW)  et réciproquement pour un analoguWrtite(x,255) comme un digitalWrite(x,HIGH)

entre les deux on aura un PWM proportionnel.

L'idée va donc etre de permettre de sélectionner en entrée le mode qui "convient" le mieux ( et surtout selon les conséquences associées) avec frequence fixe ou proportionnelle à la vitesse CPU.

Pilotage du pont en H
2 cas de figure existent ici
Les ponts en H pilotés via 2 PINS gérant nativement du PWM (canaux A et B ou IN1 et IN2)
Les ponts en H pilotés via 3PINS: 1PWM 1 pour le sens AVANT ( FORWARD= FWD) l autre pour le sens INVERSE ( REVERSE= REV)

La aussi on poura sélectionner dans l initialisation de l'objet la combinaison souhaitée (magique!)

Il faudrait aller encore un petit peu plus loin pour être complet et gérer l'inversion d'état de sortie car il arrive que des pont en H requièrent 2 entrées hautes pour une sortie basse! ( ex voir la table de vérité du MP6513 bien adapté pour les petites échelles selon DCC NMRA qui invite à tenir 22V VIN MAX NOMINAL et 24V en PIC VIN ( que l on écrêtera au besoin avec une diode TVS de 24V)

Ma préférence pour un peu plus de puissance va vers le TB67H450 mais plus délicat à caser pour de petits volumes au bénéfice d une puissance dispo en sortie très supérieure( jusqu'à 3.5A!)

.

Nous voila déjà bien lancé :)

A suivre

Laurent










10
Discussions ouvertes / Situation d'ULTIMATE MODELS
« le: mars 08, 2023, 04:26:52 pm »
Chers amis modélistes, membres de la communauté LOCODUINO,

Interpelé par plusieurs d’entre vous sur l’état du site internet de la société SAS ULTIMATE MODELS dont on me sait proche et qui est actuellement en maintenance depuis le 1er mars, je me permets de vous livrer les informations ci-dessous :

Je m’appelle Laurent ROEKENS, j’ai 45 ans. Je pratique l’échelle HO depuis mon enfance et ma rencontre du monde ferroviaire.

Depuis le début des années 2000, j’ai développé, crée, mis au point de nombreux produits techniques pour l’équipement du réseau et matériel ferroviaire : barrettes d’éclairage avec décodeur DCC embarqué, décodeurs DCC, platine de digitalisation,…

Le site et la communauté LOCODUINO ayant été un support important pour une part de ces réalisations. merci encore a ceux qui m'y on prêté leur concours.

C’est la raison pour laquelle une collaboration est née en 2021 avec la fondation de la SAS ULTIMATE_MODELS pour proposer des versions industrialisées de mes créations. Je dispose en tant qu’associé fondateur et actionnaire de 24% des parts de cette société.

A l’issue d’une réunion de travail après une AG tenue en février 2022 pour laquelle malgré plusieurs relances je n’ai jamais obtenu le PV (ce qui illustre toute la considération de la direction de l’entreprise à mon égard), M GRENIER, son président a procédé à mon éviction.

Je n’ai donc plus aucun rôle au sein de la SAS ULTIMATE MODELS dont je demeure toujours néanmoins actionnaire.

Depuis lors, je ne cautionne ni la gestion, ni la direction de l’entreprise qui est seule responsable de la situation de cette dernière.

Je ne peux donc que vous enjoindre à contacter directement le président de la société M Sébastien GRENIER au numéro indiqué sur la page du site pour obtenir plus de précisions quant à l’état de maintenance persistant du site et la commercialisation des produits actuellement suspendue.

Bien amicalement.
Laurent

11
Vos projets / PWM Bit Banging ISR
« le: mars 01, 2023, 02:51:21 pm »
Bonjour


On peut utiliser la fonction analoguWrite(à pour utiliser du PWM sur certaines pins de nos CPU qui en sont capable d un point de vue Hardware.

Lorsque le besoin de plus de pins devant générer du PWM on peut soit changer de CPU soit... utiliser une technique nommé PWM Bit Banging qui consiste à passer successivement à intervalles réguliers (rapides) les sorties digital soit à l état haut soit à l état bas.
On évite d'utiliser la fonction delay() entre chaque changement pour permettre l'exécution du reste du code.( mais un exemple trivial avec delay pour s'approprier le phénomène est possible)

Selon cette fréquence de bascule ON/OFF sur une durée donnée (intervalle) on à une tension moyenne qui est perçue et donc simule un niveau de PWM. ( duty cycle)
Pour gérer du PWM sur toutes les sorties de nos CPU nous avons donc cette solution.

On va confier les fonctions millis() et micros() à un Timer hardware ce qui les rendra régulières et non bloquante puisque nous veillerons à ce que ce timer ne soit pas sollicité pour d autres taches autres que de compter pour millis(à et micros().

Oui mais.... selon la charge de traitement du CPU  on peut avoir des "ratés" dans la bonne exécution des instructions du bit banging et donc ne pas avoir précisement le résultat escompté.
Si on veut garantir la bonne exécution de ces bascules ON/OFF je pense que l'on a "tout" intérêt à baser sur une brique hardware (un autre Timer) la gestion de ce PWM.

Malheureusement je ne vois pas comment articuler cette mise en place notamment en utilisant par exemple les très bonnes librairies de Khoih Hoang pour de nombreux CPU:

https://github.com/khoih-prog

(rechercher les repositories avec comme mot clé SLOW_PWM )

Si on peut m'aiguiller sur la bonne voie... d'avance merci.

Le souhait est donc de mettre en œuvre un PWM Bit Banging sur un Timer dédié de façon "simple" et de partager cette réalisation utile au plus grand nombre. ( peut être une via une librairie Locoduino dediée?)

Laurent



12
Vos projets / SIGNAUX: CIBLES ET DECODEURS
« le: janvier 09, 2023, 09:16:37 pm »
Bonjour à tous

Avec un peu de réflexion sur le sujet et dans une tout autre approche que celle avancée par Christian dans son dernier article paru dans Loco Revue j'attaque un nouveau sujet qui me tient particulièrement à cœur: la gestion de la signalisation et plus précisément des affichages de signaux.

PLANTONS LE DECOR:

Les très beaux signaux actuellement sur le marche ( DECAPOD, DRIM 3D, PIKOO MODELS, LEB …,  ou à venir) méritent une gestion adéquate des différentes combinaisons d'affichage.

Hormis les LEB en version DCC ... il y a quelques décodeurs pour gérer les différents état avec plus ou moins de facilité de mise en œuvre.

Néanmoins à un niveau plus en amont il y a une première problématique à traiter: le nombre de fils à utiliser.
Un des points souvent le plus contraignant devient le nombre de fils de liaison à passer entre la cible et une interface situe sous le plateau.

Si sur un signal simple on peut "encore" s'en sortir presque honorablement le cas des potences va être encore plus délicat.

Si pour un CV ( Carré Violet ) 3 fils peuvent suffire il en est tout autrement pour la gestion des cibles G ou H entre autre.

On ajoute les ID...? et on sature!

Pour cela il y a une "solution simple" : multiplexer ou poser au plus prêt des leds la partie décodeur.

La contrainte va être alors la largeur maximale qu'offre une cible.

Le cas des "cibles étroites" est le plus délicat mais pas insurmontable avec des choix "judicieux"

QUID DES SOLUTIONS HARD:

On va écarter de suite une réalisation "à la main" du fait des très petites dimensions du montage. Aussi une réalisation "usine" sera de mise. Ceci nous autorisera aussi a travailler dans les petites dimensions.

Pour ce qui est du MUX/DEMUX une solution consiste à utiliser le bus I2C que supporte très bien nos Arduino, ou directement un CPU pour embarquer le tout.

Pour le MUX/DEMUX la série des SX1507  SX1508 SX1509 offre ce dont on a parfaitement besoin.

Pour le CPU, un petit frère des ATMEGA 480X pourrait aussi bien nous servir directement au dos des cibles.

La partie décodeur elle sera traitée par nos "Arduino habituels".

QUID DES SOLUTIONS SOFT:

Les choix sont ouverts et on sera dans du "classique".

13
Bonjour


Les bases historiques:
Parce qu'il m'appartient de vous partager mon travail et mes retours d'expérience, je vais ci-après vous livrer TOUTES les clés pour réaliser ( ou faire réaliser par un industriel ou un amateur chevronné) vous même vos propres barrettes d éclairage incluant un décodeur de fonction DCC compatible analogique à destination de vos matériels remorques principalement pour le HO, le O ou même le I et leurs dérivés métriques et étroits mais pourquoi pas aussi du N sous certaines réserves des volumes disponibles.

Pour memo cela fait plus de 5 ans que je travaille sur ces concepts enrichis à l'occasion de mes lectures sur ce site et du monde Arduino pour le modélisme ferroviaire.
Je suis donc très heureux de vous en présenter la matérialité tant hardware que software. (schémas, PCB, BOM , code,...)

La rencontre du code de Geoff BUNZA, et la découverte de la bibliothèque DCC NMRA, les quelques conseils avisés de plusieurs d'entres vous dont Christian, Thierry et Dominique, que je tiens spécialement à remercier m'ont alors fait passer à une phase de réalisation qui m'a conduit dès TRAINMANIA 2017 à présenter sur le stand Locoduino mes premières réalisations de barrettes d éclairage à décodeur intégré (à l'époque munies d'un ATMEGA328P comme l'Arduino Uno) pour voiture CORAIL (ROCO). Denis et Dominique avaient entre autre alors reçu une barrette à assembler pour se familiariser avec les composants CMS de grande dimension alors utilisés sur ces réalisations.

Ce projet a continué de progresser jusqu'à ce que je le décline ensuite pour d'autres utilisations en 2018-2019...

La crise COVID de 2020 m'a permis de franchir un cap durant  le temps des confinements et de passer à l'utilisation d'outils de conception ( et non plus de dessin seul) tels EAGLE et KIKAD que je ne maitrisais alors pas.
Je vous recommande les très belles vidéos didactiques d'Eric PERRONNIN ou CYROB pour ne citer qu'eux.

Cette importante étape franchie via une meilleure maitrise des outillages m'a permis ensuite d'avancer plus avant dans des conceptions plus abouties.

La pénurie de semi conducteurs forçant au passage certains des choix techniques et des évolutions de concepts. (approche modulaire)
Le travail fourni est important car il a fallu développer, chercher, trouver, essayer, modifier, enrichir de nombreuses parties du Hardware…CPU, Powerpack, convertisseurs DC-DC... et tout autant sur le soft!


Ce travail mérite d être partagé et diffusé car il constitue une base qui peut aussi être enrichie des apports de chacun.

A vrai dire il me manque principalement la partie "soft" à un niveau supérieur au mien d'où l'intérêt de ce forum pour présenter et en enrichir mutuellement les connaissances et les réalisations mises au service du plus grand nombre.

Toutefois nul le sait de quoi l'avenir sera fait prochainement.

Dans mon prochain message, je vous présenterai les approches techniques, les besoins logiciels et matériels utiles et j'illustrerai mes propos en vous partageant mes fichiers et mon travail.

Bien à vous
Laurent



14
Vos projets / Nouveaux décodeurs!
« le: avril 11, 2022, 08:28:58 pm »
Bonjour

Je travaille actuellement à la mise au point de nouveaux décodeurs embarques (fonction et moteur) pour nos modèles. ( y compris du N!)

Une grande partie est déjà bien avancée bien que des optimisations restent encore nécessaires. (les modules Labo permettront de finaliser prochainement certains tests avec les matériels adéquats)

Néanmoins devant la volatilité des disponibilités de composants une certaine portabilité est requise et déjà mise en œuvre!

On "oublie" le 328P/PB pour le moment bien qu'une version sous attiny-45-85  soit aussi au programme! (plus le 85!)

Actuellement 36 CPU sont (déjà) pleinement compatibles avec le code source de base tournant sur les familles AVR et ATTINY des séries 0,1 &2! Ce qui avec leurs brochages respectifs couvrira certaines indisponibilités et tailles de réalisations.

J'ai encore toutefois une gosse part à traiter et un petit coup de main sera naturellement bien venu pour boucler le tout!

Laurent



15
Bonjour

Je cherche à mettre au point une "micro animation" consistant à simuler la phase d allumage d'un tube néon ( et donc par la suite de rampes de néons).

Une première idée peut être de mettre en œuvre une animation "blink" avec quelques paramètres (canal (0 à N), état (0 ou 1), nombre cycle (0 à N), durée on (0 à N), durée off (0 à N),... ) pour le nombre d éclats avant de passer en mode continue

On a ainsi une base pour générer cette effet.

Par ailleurs et pour optimiser des câblages, je souhaiterais pouvoir utiliser le bus I2C pour transmettre ce type d information. (vers un PCA9685 par exemple à 16 canaux et qui est bien connu)

Est ce que cela vous emble une approche valable? Auriez vous quelques suggestions à me donner pour y parvenir?


Laurent



Pages: [1] 2