Messages

1

Vos projets / Re : Carte détecteur de présence 16 entrées RailCom

« le: novembre 21, 2024, 11:15:39 am »

Hello

Donc sans canal 2 point de salut si plus d'un engin sur une zone? ( on en revient à la justification du CH2)

Ltr

2

Vos projets / Re : Carte détecteur de présence 16 entrées RailCom

« le: novembre 20, 2024, 03:57:06 pm »

Déduction de ton retour:

Le canal 1 adresse bien les ID de chaque engin même présent sur la même section RAILCOM.
Le canal 2 à minima traite les ACK dans ce cas afin d avoir un mécanisme d association ACK et adresse qui forme un filtre.

Est ce la bonne déduction?

Ltr

3

Vos projets / Re : Carte détecteur de présence 16 entrées RailCom

« le: novembre 20, 2024, 03:17:34 pm »

Oui Christophe pour ce qui est de la version d'origine de 2012 tu as tout à fait raison et on peut déjà taper dedans.

La version de 2024 attend encore son "translate" et contient quand même des updates "significatifs". ( surtput pour POM n Cie)

Ltr

4

Vos projets / Re : Carte détecteur de présence 16 entrées RailCom

« le: novembre 20, 2024, 02:55:59 pm »

Merci pour vos compléments. Les réflexions peuvent donc se poursuivre.

Pour ce qui est du doc source de référence pour RAILCOM on peut se baser sur

https://normen.railcommunity.de/RCN-217.pdf

Une version "in english" serait quand même bienvenue... à défaut de la version "Molière".


Pour le bénéfice du canal 2 on peut y glisser le cas des UM (unités multiples) et de la programmation/consultation POM donc en voie principale de façon "chirurgicale" à un décoder dédié. ( c est la tendance du moment)

Sinon tout ce qui a trait à des évolutions de mise en tête / recomposition de convoi ayant déjà un émetteur RC ( ex une mis en tête cote opposé à la loco arrivée en tête avec le convoi pour un départ en sens inverse après dételage de la loco d origine sans l avoir fait dégagé le canton ou stationne la convoi.

Attrait aussi dans une structure comme un dépôt où une concentration d engins moteur est présente sans avoir à saucissonner les sections de voies... (gros bénéfice ici)

Dans un tout autre registre au grès de mes recherches je suis tombé sur ceci
https://github.com/bakerstu/openmrn

(Voir plus spécifiquement la partie src et les fichiers ayant trait à RAILCOM)

Dominique en a déjà parle par ailleurs.( du LLC)

Je note juste qu'ici un gros travail semble avoir été fait sur le traitement du RAILCOM dont on peut peut être s inspirer aussi.

Ltr

5

Vos projets / Re : Carte détecteur de présence 16 entrées RailCom

« le: novembre 20, 2024, 10:41:57 am »

Bonjour

En fait on manque d'info sur le "comment" est traite le signal dans cette réalisation faute de code source.
Ce qui est dommage car après bien des recherches je n'ai pas trouvé de réalisation de gestion du CH2 RAILCOM.

Peut être que Christophe B y regardera un jour pour améliorer son identificateur RAILCOM actuellement basé sur l exploitation du CH1 et tournant sur un ESP32.

La doc pour ce "KANAL2" étant dans la langue de Goeth, cela ne facilite rien....

Par ailleurs si la vitesse des ADC du XMEGA128 est élevée, il y a des CPU "récents" qui le proposent également.( ou s en approchent voir le dépassent))
L'ADC peut travailler en 12 bits et on peut "surechantiolloner" jusqu' a 16bits.

Voir la série des AVR EA pour exemple qui entre 2 à 2.5MHz semble acquis ( au moins déjà sur le papier)
https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/AVR64EA-28-32-48-DataSheet-DS40002443.pdf

On peut déjà se baser sur les travaux de Spence KONDE et sa librairie DXCORE ( pour les AVR Dx )/MEGATINYCORE ( pour les MegaTiny) avec des informations pertinentes ici:

https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_Analog.md

Donc je pense qu'on pourrait imaginer un détecteur local à base d un de ces CPU envoyant sur un bus CAN les infos d'identification, occupation 'n Cie.

Peut etre qu'un ESP32 serait plus "veloce" pour traiter ce que l'on desire faire, je ne le connais pas assez pour me positionner.

Il reste de toute facon le besoin de traiter le canal 2 en cas d emetteur RC multiple au sein d'une meme section.

L exploitation du "ack" que trimarco232 indique semble interessante...


Ltr

6

Bus CAN / Re : Le CAN sur nos réseaux : Pourquoi et comment ?

« le: septembre 23, 2024, 11:38:49 am »

Bonjour

Je rejoins Christian sur ses observations pertinentes.

Je voudrais souligner au passage que les librairies ACANxxx de Pierre MOLINARO ont maintenant une maturité forte et, transposées à des hardwares plus récents et performants et qui sont du même coup, il me semble, plus simples à utiliser ( 32 masques et 32 filtres par exemple) quelques exemples pourraient être actualisés aussi.
Je pense au MCP2517FD notamment (en lieu et place du MCP2515)
Idem pour les déclinaisons ESP32, Teesny, ST32,... Quelques exemple de base.

Sur ESP32, un petit tuto sur comment créer des pages web pour configurer des valeurs que le code va utiliser aurait aussi une forte plus value pour les débutants.( c'est utile)

Quelques exemples "contemporains" pourront relancer l'intérêt.

Pour ma part je combine actuellement un CMP2517FD avec un TJA1052i dans l'esprit "carte historique" d'interface CAN LOCODUINO avec quelques ajouts.

A noter que la TJA1052i permet l'isolation galvanique

On y retrouve la connectique RJ45 (compatible Satellites autonomes) et des connecteurs additionnels alternatifs ainsi qu'une alimentation DC DC local pouvant monter à 5V 2.5A/3A ce qui couvrira bien des usages!
Format 50/70mm en cours de finalisation. ( led d activité à ajouter et quelques contrôles à boucler)


Ltr

7

Vos projets / Re : Pantographe fonctionnel en HO

« le: septembre 17, 2024, 11:44:54 pm »

Bonsoir Frederic

Il y a parfois un peu d inertie avant qu'un sujet "décolle".

La place et le volume sont des éléments clé.

Quand on conçoit un modèle en 3D on sait tout de suite ou on réserve ce qui est nécessaire.
Mais quand on hérite d un modelé déjà existant non prévu d'origine le premier point va être de faire un relevé des cotes et voir ce qui peut être utilisé/aménagé.

Le recours à des micro servos linéaires va aider.
Cela ne résoudra pas tout non plus.

Un peu d électronique de commande sera à ajouter soit depuis un décodeur existant ( sorties amplifiées) soit en "construction intégrale". ( a base d ATtiny par exemple)


Ltr

8

Bus CAN / Re : Le CAN sur nos réseaux : Pourquoi et comment ?

« le: septembre 09, 2024, 02:34:58 pm »

Bonjour

Merci Christophe pour cette initiative.

Il y a peut être plusieurs "Levels" à démystifier.

Tout d abord ce qui a trait au hardware puis au soft.

Depuis les articles initiaux il y a eu grâce aux librairies de Pierre MOLINARO quelques mises à jour de la bibliothèque et les exemples pourraient être actualisés ( notamment dans les #include) ou tout est " en un" me semble t il à présent.

Dans la partie soft je vois la conception de la "messagerie" et la façon de l'observer.

J ai eu une petite déconvenue avec CAN qui utilise le SPI sur un NanoEvery.

Je désirai utiliser l'interruption de port sur une série de broches ( reliées à des capteurs de présence) et je n y suis pas parvenu!( erreur!! et compilation impossible).
J en ai déduit que l interruption de port n'était pas possible en cohabitation avec CAN et en suis revenu a une approche plus classique de faire une lecture des broches de façon cyclique plutôt que par interruption.
Je n ai toutefois trouver nulle part d info sur cette limitation.

Pour illustrer un exemple plus parlant et compilant plusieurs sujets traités par Locoduino voici une thématique d'utilisation:
gestion de servo avec pilotage par CAN ou DCC de 4 servos avec pilotage de relais inverseur pour les polarisations de pointe de cœur.

Au niveau "hard" ca peut ressembler à ceci...

Mais j ai encore un peu de grain à moudre cote code.

Laurent

9

Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable

« le: août 24, 2024, 02:12:44 am »

Bonsoir Dominique

Kikad génère bien sure le placement de tous les objets.  C est lors de l export des fichiers de fabrication que le fichier de placement est traité.
Il est à fournir avec la BOM pour la fabrication usine des assemblages.

Petite subtilité il faut le retravailler un peu pour le format JLCPCB. On "nettoiera" au passage de cette liste tout ce qui sera traiter manuellement ( assemble par l utilisateur) dont par exemple les connecteurs.

A noter que Kikad dispose d'une option pour ne pas faire figurer un objet dans la BOM et donc dans la liste des objets à placer: ex un logo qui n est pas une référence de composant à assembler.

On entre la il est vrai dans des usages moins courant de cet outil.

Laurent

10

Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable

« le: août 23, 2024, 03:54:28 pm »

Bonjour

Bien que je suive le post de loin je me permets de suggérer une révision du nommage telle que:

3.X.X pour ce qui embarque à présent RAILCOM( on demend) et avec les futurs nouveaux PCB
4.X.X pour ce qui aura trait en plus à l intégration CAN ( et donc préalablement de RAILCOM sur la V3xx)

Ceci me semblera plus simple à comprendre pour ceux désirant se plonger dans la réalisation.


Comme je l ai déjà dit pour moi il ne manque alors à "LABOX" que le protocole XPRESSNET afin de l'interfacer avec les softs du marché.( je sais j insiste!)
Je doute en effet que devant la complexité du projet de gestionnaire beaucoup franchisse ce cap même si tout y est fait pour aller au plus simple et efficace.
De plus cela ouvre un point intermédiaire de mise en œuvre sur un réseau.

Laurent

11

Vos projets / Re : Upgrade de La Box pour compatibilité RailCom.

« le: août 07, 2024, 12:04:26 pm »

Bonjour

Excellente nouvelle!
Peut être même que les 7/100 sont encore challengeables en ajustant certains des timings?

A défaut c est déjà opérationnel.

Ltr

12

Vos projets / Re : Booster La Box

« le: août 07, 2024, 12:00:18 pm »

Bonjour

Petite question...

le "booster" la BOX est proposé sur un L298HN proposant 2 sorties de 2Amp MAX.

Il est connecté à LABOX via les pins assurant: IN1 IN2 ENABLE SENSE et masse commune.

Donc en principe il est possible de le substituer par un L6203 ou je fais erreur? ( et de paralléliser plusieurs L6203 également)

Ltr

13

Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable

« le: août 03, 2024, 02:46:55 am »

Bonjour Thierry

Beau boulot.

Quelques bricoles à revoir selon moi.
Ton plan de mass est abes,t sur cette version  creation des zones, affecttation au pole GND et ensuite remplissage.

Je te recommande de placer les plots de fixation de façon équidistante aux 4 angles.

Utilité de led sur "le dos?"...

enfin pourquoi pas une version FULL CMS? Dominique n était par (trop) partant pour mais je pense que cela peut valoir le coup?

Qu' en pensez vous?

Apres si l’amélioration RAILCOM est opérationnelle, il faudra l'y ajouter.

Il ne manquera alors à "cette boite" "que" XPRESSSNET" qui ouvrira alors LABOX à tous les logiciels de pilotage du marcher comme interface universalisée... Ce qui ouvre alors d autres perspectives d emploi...

Mais on me dira que c est HS... or not!?

Ltr

14

Vos projets / Re : RailCom: Générateur de CutOut avec booster

« le: mai 30, 2024, 01:24:37 pm »

Bonjour


Mes tests se poursuivent (mais le temps manque pour avancer aussi rapidement que souhaité!)

Pour des raisons de commodité j'ai porté aussi le code vers les AVRx ( AVRDx et Atmega serie0  x08 & x09).

Je me suis aussi aperçu à cette occasion d'une simple modification dont les effets de bords sont plus qu'appréciables et dont je vais devoir aussi consacre du temps de test.

En effet il ne s'agit ni plus ni moins que de pouvoir porter pour un décodeur mobile ( dit décodeur de fonctions) la capacité à emmètre des trames de messages railcom.
Le mécanisme d analyse de la trame DCC est similaire à celui déjà mis en œuvre dans cet exemple pour placer au bon moment la fenêtre CUTOUT et les actions qui en découlent.

Ici un noInterrupt() vient lors des conditions de mise en œuvre du cutout suspendre toutes les interruptions. avant de les rétablir une fois le fenêtre cutout close.
Si pour le booster ce mécanisme est suffisant pour laisser un blanc dans la trame d'émission, cela rend impossible d'utiliser d'autres interruptions pourtant nécessaires à d'autres usages dont justement Serial pour emmètre les trames de messages RAILCOM pour un décodeur mobile par exemple.

Quelle est la magie derrière? Juste une utilisation judicieuse/astucieuse des ressources des CPU et de leurs librairies.

Mon implémentation actuelle est "en dure": comprendre que j'ai volontairement choisi des attributions de broches de manière fixe et placer les alias dans le code. Aussi le mapping n'est pas dynamique avec l'utilisation de certaines ressources. Cela ne semble pas être un frein outre mesure, juste une contrainte de design de routage de PCB au plus et une portabilité réduite de la solution.
Cela fera peut-être l'objet d'un axe d'évolutions futures mais je n'ai pas trop envie de m'aventurer dans cette voie pour le moment. Si certains veulent s'en occuper... je n'ai rien contre! Bien au contraire même!! Et il faudra alors créer le post qui va bien pour discuter de cette solution... et de ses déclinaisons/usages

15

Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable

« le: mai 30, 2024, 02:10:16 am »

Bonjour Marc

J ai poursuivi mes tests.
Pour des raisons de commodité également j ai "refait le boulot" pour passer sur des AVRx (série ATmegax08 x09 et AVR Dx)

Une reprise complète du mapping est aussi de circonstance mais les principes restent inchangés.

Toutefois à la lumière des tests je me suis aussi aperçu d une petite modification supplémentaire à intégrer qui pourra simplifier ensuite l'usage de RAILCOM.
Les canaux d'EVENT supplémentaires sur les AVRx sont ici bienvenus pour porter le "reroutage" des éléments...

Encore des tests à faire mais le principe semble acquis pour fonctionner avec la LIB d AIKO PRAS ou des mécanismes similaires...

J en parlerai mieux sur le post liée au booster et railcom.

Ltr