Sujets

1

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

2

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

3

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

4

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

5

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
 

6

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

7

Vos projets / Retrosignalisation RS LENZ et ARDUINO

« le: octobre 12, 2020, 09:33:59 pm »

Bonjour

Une bibliothèque a été crée par Aiko PRAS pour gérer le protocole RS LENZ avec les ARDUINO.

Le soft et e hard sont proposés sur ces pages:

https://github.com/aikopras/RSbus

Les info sont disponibles ici:

https://sites.google.com/site/dcctrains/about

Nul doute que cela pourra être très utile à la réalisation d un détecteur d'occupation/rétrosignalisation émettant en protocole RS ou à un éventuel convertisseur RS/CAN-CAN/RS.
Autre possibilité, l'intégrer sur un mini centrale...

A voir!

Exploitable;

Laurent

8

Vos projets / AU LABO: montages utiles

« le: septembre 06, 2020, 04:11:48 pm »

Bonjour

Nous sommes nombreux à "bricoler" autour de nos ARDUINO et de leurs dérivés.

Si les champions du code ont l'IDE et des simulateurs le passage à la phase de réalisation peut être une étape parfois délicate à franchir.

Avec une plaque à essai, une alim de laboratoire, une petite centrale DCC et des composants traversant on arrive a se débrouiller...

Toutefois électronique moderne recours de plus en plus aux Composants de type Montage en Surface: CMS ( SMD/SMT en anglais)

Aussi quelques montages "utiles" et génériques peuvent être réalisés. Correspondant à des fonctions bien identifiés: ex entrée du signal DCC via optocoupleur ou par résistances vers la broche D
 de nos Arduino, régulateur de tension de type LDO ou DC/DC (BUCK ou BOOST...


J ai donc passé "un peu de temps sur la planche" pour concevoir une série de montages. Il en reste toujours d'autres à faire...

Voila ce que cela donne pour le moment...
On y trouve:
Pont de diode (signal ou moyenne puissance)
DCC vers Signal via OPTO
Sortie OPTO ou directe vers signal DCC via pont diode
Capteurs directs pour feedback ( BEMF, AD, DCC SIGNAL via résistances...)
Pont en H pour commande de moteurs
Générateur de courant constant (faible intensité) via 2 NPN et résitances
Réference de tension (via TL431)
Supercapaciteurs (unique ou montage en serie)
Régulateur de tension de type:
x DC-DC STEP-UP (BOOST)
x DC-DC STEP-DOWN (BUCK)
x LDO fixes ou a sortie de tension variable.
pilotage MOSFET (CANAL-N) ( BSS138)

Le tirage n'est pas encore lancé mais... s'il y a des personnes intéressées elles peuvent manifester leur intérêt ou indiquer quels autres montages utiles nous pourrions aussi produire.

Laurent

9

Vos projets / DECODEUR DCC Loco et fonctions

« le: août 04, 2020, 12:41:51 pm »

Bonjour

LOCODUINO ne s est pas encore (beaucoup) penché sur la réalisation de decodeurs embarqués maison qui seraient des alternatives valables aux décodeurs DCC pour nos locomotives ( ou nos véhicules)

Les principales limites de ce type de réalisation tiennent souvent plus aux problèmes de place et de volume disponible pour réaliser de tels décodeurs.
Le recours aux composants de type SMD/SMT ( CMS  composant monté en surface) de petite taille sont un prerequis presque indispensable.

Toutefois leur diffusion devient aujourd'hui massive et leur mise en oeuvre soignée ne pose le plus souvent pas de "trop gros problème" au moins pur du format jusqu à 0805 voir 0603.
Le cas des microprocesseurs reste voisin mais toujours jouable avec le bon materiel (flux, bonnes soudure, air chaud, fer régulé,...)

Mes différentes lectures et recherches sur internet m ont conduit a voir que si différentes solutions ont pu etre esquissées ci ou la, il n y a pas à ce jour de réalisation "up to date" ( à jour) avec nos composants habituels dont la mise en œuvre est très souvent décrite sur le site: je pense en tr autre aux ATMEGA et ATTINY. ( plus specifiquement aux ATTINY45/85 et 44/84)

L idée serait donc de réaliser des décodeurs DCC Maison pour loco et ou fonction.

Je me permets de mettre un lien vers un site japonais qui présente des réalisations interessantes et dont on peut surmement exploiter une part de contenu.

http://www13.plala.or.jp/katsuraan/Decoder/decoder.html#ATtiny44StandardDecoder

Je recommande l utilisation du navigateur Google CHROME et l utilisation de la fonction TRADUCTION en français pour obtenir une lecture simplifiée

Idem pour le site en allemand suivant
http://1zu160.eu/index.php/dcc-decoder.html
 details ici
http://1zu160.eu/index.php/decoder-hardware.html
http://1zu160.eu/index.php/programmierung.html

download ici
http://1zu160.eu/index.php/download-18.html#DCC-Decoder

A voir donc ce que vous pensez que nous pourrions collectivement concevoir et implémenter.

Mes pistes de réflexion
ATTINY45/85 pour moteur et 2 sorties de fonctions au delà si besoin supérieur ATTINY44/84
Régulation par MIC5233-5.0YM5 après pont de diode
IN signal DCC vers MCU via pont+ résistance (33K à 100K voir plus)
2 ponts MOSFET N et P pour l exécution ( ne pas oublier les 2 résistances de 10K pour la désaturation)
NPN ou MOSFET pour l exploitation des sorties complémentaires.
connectique pour MTC21 PLUX16/22 8 et 6 broches

***Montage***
PCB 6/10 (ou 4/10)
Resistance en 0603 si possible (ou 0805 si puissance nécessaire)
Condo en 0805 (ou 0603)
Diode en SOD323F
Transistor SOT23 ou SOT323...
ICSP pour programmation du decodeur...
connecteur (PLUX/MTC, sortie pads...)

Reste comme toujours cette partie de code à écrire et ou adapter... (HELP!?) je pense pouvoir traiter efficacement la partie schématique et PCB avec vos suggestions
La gestion du "back EMF" semble un point a traiter spécifiquement.

Pour memo duex autres réalisation à citer également
les decodeur NMRA (voir exemples de la librairie NMRA-DCC dont SMA de Geoff BUNZA)

decodeur du site de Rudy BOER
https://rudysmodelrailway.wordpress.com/software/

A vous lire prochainement sur ce beau sujet...

PS: J ai fait volontairement à ce stade abstraction du cout de réalisation qui sera aussi à considérer devant l offre du marcher... ( ESU, ZIMO, LENZ,... etc) mais ceci ouvrira peut etre des possibilites de decodeur custom pour des engins specifiques ou ces tels decodeurs ne peuvent tenir ou sont insuffisants...


Laurent

10

Vos projets / ULTIME BARRETTE: decodeur de fonction intégré sur base ATMEGA328P

« le: juillet 16, 2020, 12:23:26 am »

Bonjour à tous

Je poursuis mes réalisations de barrettes d éclairage pour matériel avec décodeur de fonction intégré sur base d'un ATMEGA328p-AU au format TQFP. ( le petit carré de 10mmx10mm environ avec 32 pattes! Cela se soude bien avec le bon matos! Zen 

La réalisation est assez bien avancée et plusieurs prototypes sont en cours de qualification.

Là ou je pêche, comme toujours, c est sur le code à y glisser...

Je suis parvenu à mixer plusieurs éléments pour répondre à mon cahier des charges:


A/alim de régulation sans dégagement excessif de chaleur ( convertisseur DC/DC ou lineaire?)

B/ commande individuelle de 16 sorties avec:

C/ possibilité de générer un pseudo PWM pour moduler la luminosité

D/ rendre directionnel le sens d allumage (idéal pour des inversions feux rouges-blancs par exemple)[/li][/list]

E/ animatique pseudo aléatoire des sorties pré sélectionnées (activation des compartiments selon le trajet par exemple de facon autonome)

F/ doit pouvoir fonctionner en courant DC ordinaire ayant en memoire les sorties actives ou non

G/ 1 sortie pour le ACK (et donc la lecture des valeurs du décodeur) (d ou programmation/lecture possible)

H/ ICSP (pour mise a jour/injection du code)

I/ Composants SMD (0805 pour les condo, 0603 pour les résistances et Leds)

J/ Composants SMD pour les optocoupleurs et transistors, quartz,...[/li][/list]

K/ ...

Je me suis basé sur le code de Geoff BUNZA et ses fameux décodeurs SMA. (SMA17 Ftn 01 et SMA17 Ftn 06...) Base bibliothèque NMRA DCC.

J'ai trouve une version augmentée en fonctions ( ack+mode aléatoire) mais sans la sens directionnel sélectionnable ni l affectation (selection) de sorties données pour le mode aléatoire.

La syntaxe est assez poussée ( trop pour moi! HELP!!)

Dominique doit y jeter un œil plus poussé des qu'il aura un moment mais si d autres se sentent "inspirés" nous pouvons co-construire ce code qui sera portable à tout autre réalisation pour laquelle je publierai alors les schémas complets.

L idéal serait de mixer les deux fichiers fournis et de compléter... Dans ce qu ils offrent de plus riche.

Il ne manquerait plus alors qu'une fonction avec 2 états de puissances différentes d'éclairage pour des feux ( croisement/pleinne ligne) pour parfaire le chef d oeuvre!

Par ailleurs quelques remarques sur le code NEW_FUNCTION_DECODER_V2.0_OK_avec_led_dir_variable_34_39_44_etc

il fonctionne bien 
Cependant dans certains cas (coupure et re alimentation) les leds ne se réalument pas forcement comme elles le devraient et il faut re activer des sorties "hautes" des fonctions superieures à 8.
(ex activer 15 OFF/ON pour que 14 et 15 se réactivent)
Je ne sais pas d ou vient ce "phenomene" exotique?! A vos avis!!

Une piste pour pallier cela me parait être de stocker que dans l eeprom l état et de n appliquer qu'en cas de modification les allumages/extinctions... mais je me posais la question de savoir si ce n est pas déjà fait dans le code initial ou s il y a juste une initialisation via lecture CV...

Donc si vous vous sentez inspirés pour m assister sur ce beau projet... votre aide sera la bienvenue.

D avance merci

Ci joint les fichiers des codes cités.
PS je vais compléter par quelques photos

Amitiés
Laurent

11

Vos projets / Definir le sens de circulation pour un decodeur de fonctions embarquées.

« le: mai 14, 2020, 09:44:41 pm »

Bonjour

En DCC existe t il un moyen de définir le sens de circulation et de l'exploiter dans l Arduino ( vers l'avant ou l’arriéré en DCC)

Ex dans un décodeur de fonction pour par exemple n éclairer que les leds blanches à l'avant et les rouges à l'arriéré en cas d activation.

Je n'ai rien trouve sur ce sujet.

Avez vous quelques pistes sur cette thématique?

Je vos bien l idée d ajouter une valeur ( CV) pour indiquer actif si AVANT ou ACTIF si ARRIÈRE ou DANS LES DEUX SENS ou INACTIF par exemple.
Mais comment trouver ce sens de circulation!...


Je suis preneur de vos idées....

Laurent

12

Vos projets / Levée de boucliers!

« le: août 08, 2019, 12:30:31 am »

Bonjour

Cela fait un moment que cela cogite dans tous les sens... alors il faut bien produire un petit quelque chose!

Dans les grandes lignes je me suis inspiré de nombreuses lectures sur le net, ici même mais aussi sur les "bonnes adresses" qui vont bien pour ingurgiter" digérer et produire!

Je vous présente donc modestement le fruit des ces nombreux efforts et heurs passées à ces réalisations.
N étant pas du tout un champion de la ligne de code je me suis surtout borné à travailler sur la HARD, et faute d(avoir un "soft maison", j ai repris ici et la quelques très bon exemples qui vont permettre de donner vie au HARD.

J informe qui le veut bien que la ré écriture de ces codes, voir leur reconstruction (évolution etc) sera la bien venue afin d être "sans attache" avec le travail de qui que se soit des codes d'origine.

Sur le modèle des "cartes satellites V2" mais avec une tout autre approche orientée Accessoire DCC et sur les modèles développés par
Geoff BUNZA https://model-railroad-hobbyist.com/blog/geoff-bunza
Nico TEERING (ARCOMORA) https://www.arcomora.com/
MERGE https://www.merg.org.uk/
...

Fidèle à ma philosophie de relier les monde existants* (voir ce sujet: http://forum.locoduino.org/index.php?topic=803.0 j ai donc repris "le meilleur" pour réaliser un ensemble de "BOUCLIERS" complémentaires ( cartes diverses) ayant chacune des affectations techniques dédiées.
Chacune se veut simple à réaliser (composants traversant à 99%), robuste, évolutive dans la partie logicielle ou avec des composants substituables selon les provenances, stocks...

• BOUCLIER DE BASE: support de l'Arduino/ATMEGA328P, gestion des alimentations, du signal DCC et des connecteurs d'extension vers les autres bouclier
  BOUCLIER SERVOS pouvant gérer la connexion de servos jusqu'au nombre de 8.
  BOUCLIER RELAYS pouvant gérer jusqu à 8 relais.
  BOUCLIER RELAYS DC ( double bobine), jusqu à 4 relais double bobine
  BOUCLIER BIG COILS avec CDU pour traiter 4 paires de bobines de forte consommation type PECO intégrant une décharge capacitive (CDU)
  BOUCLIER EXTENSION SIGNAL socle de liaison aux signaux type DECAPOD et autres

Tout d abord le BOUCLIER DE BASE:

Basé sur un design repris d'ARCOMORA et du SMA, il combine une régulation DC 5V (ou 6V) provenant au choix du signal DCC ( option à ne pas privilégier mais possible! ce qui évite de parfois retirer des kilomètres de câbles dans un coin perdu du réseau ou seul passe un FEEDER DCC! Quelle chance!) ou source extérieure de 9 à 18V AC ou DC.
Le traitement du signal DCC vers l'ARDUINO
2 connecteurs "normalisés" indiqués "BAS" et "HAUT"avec une source poistive "+5V" = 4V4 ou 5V selon le régulateur 7805 ou 7806 mis pour la gestion de l alimentation, une MASSE = "GND" et 8 entres sorties numérotées "1","2","3","4","4","5","6","7"et "8" pour la partie "BAS" et de "9" à "18" pour la partie "HAUT"
Nous le verrons plus loin... cette répartition en 2 groupes de 8 n' est pas "innocente" et permet de s'affranchir de nombreuses combinaisons d'usage.
Monté, testé, croquis chargé, paramétré il fonctionne à merveille! (avec une extension de pilotage simple de LED en TOUT ou RIEN sur chaque sortie par exemple)

J attends à ce stade la réception d ici la fin du mois des autres BOUCLIERS actuellement en transit pour poursuivre les montages... et les tests!

Dans cet intervalle, pour ceux qui auraient un peu de temps libre pour cogiter sur quelques lignes de codes qui vont bien... le HARD serait preneur d un code lui permettant de traiter 24 ou 32  (voir plus) combinaisons d affichage des 8 sorties de leds à partir d une commande DCC type ACCESSOIRE pour des signaux type SNCF mais aussi autre ( SNCB, DB , NL, RENFE,...) ( la dernière entrée effaçant l'état précédent, chaque sortie peut être gérée en ÉTEINT, FIXE, FLASHING, et avec graduation progressive montante et descendante (simulation inertie lampe à filament)...

Avis au talentueux!
La suite(tres) bientot...

Laurent

13

Discussions ouvertes / Universalité des réalisations: de l'Arduino vers l' "industriel" et vice versa

« le: août 06, 2019, 10:36:43 pm »

Bonjour à tous

Suite à une très riche discussion avec Dominique et aux propos que j avais pu exposer lors de TRAINMANIA 2019 je relance ce sujet de fond pour favoriser (influer) sur un axe de mis en oeuvre stratégique de réalisations avec LOCODUINO.

Il existe de très nombreux exemples sur LOCODUINO comme sur la toile présentant des utilisations riches et variées  d'ARDUINO ( UNO, PRO, NANO, MEGA, ATMEGA 328P... et leur dérivés et clones divers)

Le projet des cartes SATELLITE V1 puis V2 ouvre une voie très intéressante et présente une approche solide, évolutive et configurable en "sur mesure"! MAIS...

Si l'utilisation du BUS CAN est un atout notable pour assurer un bus de communication fiable, robuste et éprouvé, la mise en oeuvre des cartes s adresse à un public (une petit peu) restreint et averti.
Ce n est pas tant la mise en oeuvre (montage et injection du code) que la personnalisation de la carte qui peut vite "effrayer"...
Et au delà comment en exploiter la quintessence... qui plus est facilement!

Pour ouvrir à un plus large public de pratiquants ( qui va mettre en oeuvre et utiliser ) il faut compléter l'approche par des IHM ( interfaces graphiques simples et conviviales) pour "customiser" les options d’implémentation des dites cartes.

On aura alors franchi une étape important MAIS sans avoir encore assez de vastes débouchés ( ou du moins les plus vastes qui soient)

La plus grande partie des modélistes "modernes" qui se sont tournés vers le DCC et qui désirent ensuite utiliser leur réseau avec des mécanismes d exploitation avancés ( automatismes, bloc, gestion d accessoires, retrosignalisation, identification et suivi des trains...) conjuguent alors avec un logiciel et des cartes d interface.

Les industriels ont développé des gammes de produits complémentaires, concurrents, plus ou moins compatibles avec des protocoles d'interface normalisées plus ou moins bien documentées. La note est parfois lourde!
Citons quelques normes pour illustrer ces éléments: DCC, S88n, RS LENZ, LOCONET DIGITRAX, CAN ZIMO, CAN ESU, ROCO RBUS, ...t
Coté interface informatique les logiciels de gestion de réseau ont aussi fleuri.
Parmi les plus connus citons JMRI, CDM-RAIL, RRTC, ROCRAIL & WINDIGIPET.

Hormis une "poignée" d 'élus capable de "prouesses technologiques" ( il y en a beaucoup sur se forum , ils se reconnaîtront, et merci à eux pour leur rôle de "locomotive")  en développant, mettant au point, tout de A à Z ( hardware, software, réglages, utilisation très avancées, documentation, articles...) il faut reconnaître que la plus grande majorité de pratiquants ne dispose pas "encore " de produits "clé en main" ou d'assez de savoir faire dans mener un (des) projet(s) complet(s) du début à la fin... ( moi même y compris!)
Rien n est perdu! L'union fait la force!
"May the force be with you!"

Un des points structurant repose selon mon analyse sur l'inter opérabilité des réalisations et des implémentations.

Le "fait maison"  ou DIY, ARDUINO ( LOCODUINO) compris ne doit pas échapper à cette règle.
Le plaisir de faire soit même, la maîtrise du budget, la "customisation" pour couvrir son "petit besoin spécifique" sont autant d’éléments qu il faut garder à l'esprit autant que la SIMPLICITÉ de mise en OEUVRE.

Arduino a été un excellent vecteur de dynamisme ou grâce à quelques lignes de codes, des mécanismes autrefois gérés par des électroniques dédiées et non évolutives sont devenus des approches caduques.

Un jeune bien encadré doit pouvoir monter une carte, y souder les composants et y injecter le code qui va bien. Un adulte aussi et cela quelque soit son niveau de pratique modelistique, informatique ou électronique.

Les logiciels précédemment cités utilisent majoritairement le protocole DCC pour gérer les locomotives équipées de décodeurs, mais aussi les accessoires DCC ( pilotage des accessoires, Aiguillages, signaux, ...) mais beaucoup d'entre eux se révèlent malheureusement incomplets ou trop "fermés" pour autoriser les protocoles de communication avec des produits "non industriels" novateurs tel que les satellites V1 ou V2, ou du moins nativement.
Ils se retranchent alors derrières des produits industriels qui servent de passerelle multi bus pour gérer les circulations, la retrosignalisation, les accessoires, ...

Je pense que pour "réconcilier" une approche intermédiaire doit être développée avec un but multiple:

• toucher un grand nombre d adeptes. (familier ou non d ARDUINO, du DCC ou même du monde du modélisme ferroviaire!
  simplifier la mise en oeuvre et la prise en main avec des IHM "user friendly".
  couvrir des cas généraux adossés à des protocoles industriels majoritairement présents chez les utilisateurs
  proposer des évolutions et réutilisations si possible par une approche modulaire
  fiabiliser les approches des bases par des éléments éprouvés proposant les meilleurs compromis
  réconcilier l'ancien monde qui a déjà fait ses preuves, et pousser au delà!
  s'interfacer avec de l'existant standardisé
  ...

Une belle tentative a pu être proposée par le projet ARCOMORA https://www.arcomora.com/

Certains trouveront cela très "minimaliste" ou incomplet, voir insuffisant mais cela permet de

• mettre un premier pieds dans ARDUINO ( et cela sans se plonger longuement dans le "code"
  couvrir tous les besoins essentiels que l'on rencontre sur un réseau
  réaliser soit même
  attribuer facilement les composants aux usages attendu d'un produit customisable
  interfacer avec des équipements normalisés (industriels ou DIY)
  interfacer avec des logiciels de large diffusion (gratuit ou non)

Bref, cette voie me semble être une bonne direction vers laquelle s'orienter. Elle aura pour but d 'élargir la base de pratiquants.
Que nous "manque t il pour arriver à ce résultat?

Finalement pas autant que cela!

Les satellites V2 existent au niveau HARDWARE, le soft est toujours en cours de finalisation mais déjà bien avancé.
D'autres montages sont dans les "cartons" ou adaptables à moindre coût.
De nombreuses bibliothèques existent... ( NMRA, LOCONET, XPRESSNET, CAN,...)
Les talents se conjuguent!

Il manque une/des IHM de paramétrage(s) simple(s) et facile(s), conviviale(s). (l âme du système)
Il faudrait une/des passerelles pour conjuguer le bus CAN et les cartes Satellites pour s interfacer vers des protocoles industrialisés ( DCC, S88n, RS LENZ, LOCONET voir CAN ( ESU, ZIMO,...))

Ainsi on réconcilie les mondes... et on fait circuler nos trains avec plaisir, fiabilité et sécurité!
Ceux qui voudront  (toujours) pousser plus loin le pourront bien naturellement mais "la masse" sera embarquée et pourra se satisfaire de progresser à son rythme, compléter son équipement, explorer de nouvelles approches, participer et dépasser ses appréhensions!

A cogiter...

Amitiés
Laurent

14

Vos projets / PASSERELLE CAN vers protocoles types: S88N, XPRESSNET, RS LENZ, LOCONET,...,WIFI

« le: février 04, 2019, 11:27:56 am »

Bonjour

Les récents articles de présentation de la carte satellite V1 et de la mise en oeuvre du BUS CAN ont bien mis en avant la qualité et la simplicité de la réalisation. ( quelques composants, des bibliothèques, ...)

A ce jour tout ce qui est en cours ( de développement ou de mise en oeuvre) repose sur le transfert par bus CAN des informations collectées ou a transmettre.

Cette démarche fonctionne si la cible est aussi de disposer d un environnement d exécution/traitement/affichage compatible.

La démarche d utiliser le CAN pour le transport des info du S88N a montré le gain de l'usage du CAN et l ouverture vers "l'EXTERIEUR" des standards du marché ( ici le S88n)

Sur le même principe je pense qu il pourrait être intéressant de réaliser des PASSERELLES CAN vers des protocoles "STANDARDS" comme LOCONET, XPRESSNET, RS BUS...

L intérêt est ainsi de combiner les avantages du CAN et de pouvoir interfacer les réalisations qui l'utilisent avec des équipements voir des logiciels ayant déjà pignon sur rue:
ex cote hardware:
la DR5000 de DIJIKEJS propose en sortie les interfaces suivantes:
S88n
XPRESSNET
RS LENZ
LOCONET

l ECOS2
S88n
LOCONET via Adaptateur
CAN ESU (mal et peu documenté!)

ex coté software:
RRTC sait gérer les centrales/interfaces exploitant LOCONET, XPRESSNET, S88, RS...
CDM RAIL pour sa part XPRESSNET, RS et S88n

Les bibliothèques existent. ( XPRESSNET, LOCONET, S88, CAN,...)

Je me pose donc la question de savoir si cette( ces) PASSERELLE(s) CAN vers XXX est quelque chose de réalisable et si on peut la (les) mettre en oeuvre

( l idée qui est derrière est de pouvoir utiliser des cartes SATELLITE ou la future carte de DÉTECTION d OCCUPATION avec IDENTIFICATION RAILCOM vers des interfaces de sortie dites "standards" avec des produits du commerce. (hard et soft)

En quelques mots simples: faire coexister le meilleur des deux mondes.

Ex d’implémentation:

On prends sur le signal DCC les trames à destination des ACCESSOIRES DCC, ainsi la voie reçoit le signal DCC FULL mais sera dévolue au pilotage des engins exclusivement) ( on pourrait aussi filtrer pour que la voie ne reçoive les informations qu à destination des décodeurs de matériel ( décodeurs classiques et décodeurs de fonctions))
Les trames DCC des Accessoires sont converties pour passer sur le BUS CAN, en sortie on passe du CAN en DCC ACC pour piloter des équipements au format DCC.

On passe du CAN vers le S88n ( comme décrit avec la fonction GATEWAY S88 del article su site) ( ici bus unidirectionnel pour remonter des info d'occupation)

On passe du CAN vers le RS LENZ ( ici bus uni directionnel pour remonter les info d'occupation)

On passe du CAN vers le LOCONET ici bus Bidirectionnel mais dont ont peut commencer par implémenter le sens de remontée des information comme pour le S88n et le RS Lenz.

...

Etc

In fine et pour résumer on aurait ainsi sous le réseau:
1 BUS puissance ( alim des cartes et accessoires)
1 BUS DCC pour la traction
1 BUS CAN universel qui transporte toutes les info de tous les interfaces avec leurs protocoles respectifs)
(en option un bus DCC ACC et un bus DCC TRACTION séparés.)

Le débat est lancé...

Laurent

15

Vos projets / Barette eclairage avec decodeur integre sur base ARDUINO/328

« le: janvier 26, 2019, 01:26:52 pm »

Bonjour

Sur la base de l excellent travail réalise par Geoff Bunza
 disponible à cette adresse:
https://model-railroad-hobbyist.com/node/24316

J ai eu l idée de reprendre et d'adapter le tout à une réalisation "universelle" dédiée à un éclairage pour véhicules.

J ai choisi de commencer par la réalisation de 2 barrettes dédiées aux VU ROCO: l A9c9ux et le chaudrons commun des A11,B11, B10c10ux.

Les bases sont très proches et la partie alimentation est modulaire. Garantie "anti chauffe" par un convertisseur "BUCK" DC to DC.

L Arduino étant "trop gros" je suis parti sur l'utilisation direct du 328P dans sa version la plus petite ( ca se soude bien!)

Reste encore à finaliser!
Quelques composants sont encore à recevoir ( et PCB dédié à la programmation du chip)  ainsi que l’adaptation du code pour ajouter quelques fonctions spécifiques:


>gestion "aléatoire" de l'activation de l'allumage des différentes LED ( avec choix de celles à considérer)

>Optimisation du chargement du croquis dans le chip...

Pour ceux qui voudraient s y essayer aussi j ai des PCB de dispo... à monter bien sur!