Sujets

1

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

2

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

3

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

4

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

5

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

6

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

7

Vos projets / pilotage moteur via utilisation du TIMER A0 (AVR & MEGATINY séries 0/1/2)

« le: mai 29, 2023, 12:12:15 am »

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

8

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

9

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

10

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

11

Vos projets / Réalisez vos propres barrettes d'éclairage avec dcodeur DCC-analogique intégré!

« le: mai 03, 2022, 10:30:09 pm »

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

12

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

13

Vos projets / simuler l'éclairage d un tube néon et de rampes de tubes néons

« le: mars 13, 2022, 02:42:23 pm »

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

14

Shields et Modules / ATMEGA 328PB WATTUINO

« le: octobre 19, 2020, 08:18:39 pm »

Bonjour

Pour ceux qui recherchent quelques fonctionnalités supplémentaires par rapport a l'ATMEGA328P son évolution vers l'ATMEGA 328PB pourra seduire.

Malheureusement disponible uniquement en format à souder il s est peu rependu. (TQFP32 entre autre)

Certains clones chinois en sont parfois pourvu mais sans exploiter les sorties supplémentaires.
D autres clones récents disposent eux de 2 sorties supplémentaires mais pour les trouver c est un peu la loterie...

Néanmoins des cartes comme la A-STAR  de POLULU peuvent convenir pour exploiter les nouvelles fonctionnalités qu'il offre ( voir datasheet)

Pour ma part j ai préféré la version de WATTUINO. (PRO MINI PB)

Pourquoi?

Une question de brochage que je trouve optimisé pour une utilisation simplifiée un peu comme un ARDUINO PRO.

Le modèle en question.

https://shop.watterott.com/Wattuino-Pro-Mini-PB-5V-16MHz-ATmega328PB_1

J ai retenu pour ma part le modèle en 5V à16Mhz il existe aussi en 3.3V à 8Mhz.

https://shop.watterott.com/Compatible-with-Arduino

livraison DHL en 48H! RAS c est top.

Possible donc à présent d exploiter les sorties supplémentaires pour certains montages... en étant 100% compatible Arduino UNO/NANO

Veillez à installer les cartes  pour en tirer partie ensuite dans vos codes.

Laurent
 

15

Vos projets / LA PASSERELLE

« le: octobre 14, 2020, 07:22:33 pm »

Bonjour

A force expériences nouvelles je progresse dans la maitrise du monde "Arduino"! (mais je reste encore bien junior!)

J'ai poursuivi mes lectures et me suis intéressé aussi nouvellement aux cartes TEENSY (plus spécialement à la 3.2)

J'ai toujours en projet la réalisation de différentes interfaces dont voici les fonctionnalités.


1/interface DCC->CAN:
Pour la commande des accessoires ex servo et leds de signaux
On convertit une adresse (accessoire) DCC en la portant sur une adresse CAN et en transmettant un état
On exploite l'élément via par exemple une carte SATLLITEv1 pour activer un servo ou des leds (signaux) ou relais...

Intérêt du dispositif: n'importe quelle centrale peut piloter les accessoires y compris via un logiciel du marché pour le pilotage du réseau en DCC qui est alors 100% compatible. (RRTC, CDM Rail, ROCKRail, et meme JMRI! ...)

On peut aussi créer des décodeurs autres que les satellites pour piloter leds, servo, relais, etc.
On utilise le bus CAN pour transmettre les instructions de commandes et l utilisation d'une bibliothèque nous y aidera.

On peut utiliser une bibliothèque pour décoder le signal DCC, par exemple la NMRADCC en version 2.0.5 qui est justement compatible avec les TEENSY 3.x! (Youpi!)

Grace a cela on peut alors via une fonction ad hoc récupérer l adresse d un accessoire d une trame et l'état

Code: [Sélectionner]

extern void notifyDccAccTurnoutOutput( uint16_t Addr, uint8_t Direction, uint8_t OutputPower )
 
2/ interface de remontée de rétrosignalisation:

Ici il s agit de remonter des informations de détecteurs d"occupation ou de position via des protocoles normalisés exploitable par nos centrales du commerce. (et donc un logiciel peut ensuite exploiter aussi ces informations)
3 protocoles sont retenus:

• le S88
  
• le RS LENZ
  
• le LOCONET
  

SUPPORT DU CAN:
Pour le CAN, le TEENSY3.2 peut le gérer au niveau HARDWARE sur les broches 3 (TX CAN) et 4 (RX CAN) ( comme un MCP2515)
Il faut alors compléter au niveau HARDWARE avec un "tranceiver" tel que le MCP2551 ou le MCP2542 pour gerer les ignaux CAN_L et CAN_H. ( et le terminateur avec pont pour la resistance de 120r)

Ou pourrait alors utiliser la bibliothèque ACAN TEENSY 3.1/3.2 qui permettra d exploiter la CAN du TEENSY comme celui d un MCP2515. ( si j ai bien tout compris?!)

https://github.com/pierremolinaro/acan

D autres sources sont peut être aussi valables?( celle ci me semble toutefois bien convenir  )


Pour le RS LENS une bibliothèque existe aussi ( re Youpi!) mais sur 328P ( et "d autres bestioles" (sic)) Toutefois cela semble assez explicite pour pouvoir être utiliséaussi sur TEENSY. ( à vos avis??)

On peut trouver les informations ici et la télécharger:

https://sites.google.com/site/dcctrains/rs-bus-feed/software

Pour le S88 il y a déjà eu sur LOCODUINO des articles et on devrait donc pouvoir la aussi "piocher" dans l'existant.

https://www.locoduino.org/spip.php?article180

Pour LOCONET, il y a aussi des bibliothèques qui devraient pouvoir être exploitées.

Au niveau HARDWARE les PINS du TEENSY 3.2 semblent pouvoir couvrir tout nos besoins de par leur nombre ou leur spécificité.

Voila qui "plante le décors" de ce qu'il est conceptuellement possible de faire.

Mais voila ce concept est il une "pure hérésie" ou bien est il bien matériellement réalisable?

Le hardware ne semble pas être un obstacle premier infranchissable
Le bloc logiciel (librairies) existent pour la majorité des besoins à couvrir
Leur exploitation est par contre pour moi plus délicate mais collectivement nous devrions nous en sortir et pourquoi pas présenter une réalisation prochainement!!

Pourquoi pas en expo à TRAINMANIA 2021 en Mai prochain?

Laurent