Messages récents

Pages: [1] 2 3 ... 10
1
Vos projets / Re : Carte détecteur de présence 16 entrées RailCom
« Dernier message par lebelge2 le novembre 20, 2024, 05:33:59 pm »
Attention.
Le canal 1 adresse bien les ID de chaque engin mais pas sur la même section RailCom et avec multiplexage des entrées.
Si deux engins se trouvent sur une même section, c'est le canal 2 et leurs Ack qui déterminent l'adresse des locos.
2
Vos projets / Re : Carte détecteur de présence 16 entrées RailCom
« Dernier message par bk4nt le novembre 20, 2024, 05:25:58 pm »
Je constate en tous cas que la couche physique n'a pas évoluée.

La solution ESP32 de Christophe doit utiliser RXD, la combinaison des signaux. Je pense utiliser directement les sorties des AOP, chacun vers un PIO UART d'un RP2040. De ce fait, Rx sur UART A ou UART B, indiquant alors l'orientation de la loco...

Pour un circuit très simple et compact 4 voies, avec une isolation entre le RP2040 et les 339. Pour 8 voies, il faudrait un RP Pico, pour disposer de plus d'IO, et des composants en plus pour détecter l'orientation; ça pourrait finir plus encombrant.
3
Vos projets / Re : Carte détecteur de présence 16 entrées RailCom
« Dernier message par laurentr 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
4
Vos projets / Re : Carte détecteur de présence 16 entrées RailCom
« Dernier message par lebelge2 le novembre 20, 2024, 03:36:25 pm »
Bonjour, je vous communique les conclusions d’un petit test de détection.

Mise en service du réseau , le signal DCC est uniquement composé de trames IDLE (Préambl, 0xFF, 0x00, 0xFF)

Nous avons deux locomotives RailCom  canal 1 (Cv28 à 1) (Adr 1 et adr 4)

Dépose d’une loco sur les rails ;  Immédiatement reconnue par le détecteur, adresse 1.
Dépose de la deuxième sur un autre canton ; Immédiatement reconnue par le détecteur, adresse 4.

Conclusion : La détection  de la loco se fait sans besoin de l’adresser.

Conditions pour détecter deux locos sur un même tronçon :
1)   Adresser la loco. (vitesse ou fonctions)
2)   Activer bit 0, 1 et 7   du Cv28
Dans ces conditions le canal 2 envoi 6x   0xF0 (Ack) et le détecteur peut déterminer l’adresse des locos.

5
Vos projets / Re : Carte détecteur de présence 16 entrées RailCom
« Dernier message par laurentr 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
6
Vos projets / Re : Re : Carte détecteur de présence 16 entrées RailCom
« Dernier message par bobyAndCo le novembre 20, 2024, 03:08:17 pm »
Pourquoi faire simple quand on peut faire compliqué ?

Le document dont tu donnes le lien :
https://normen.railcommunity.de/RCN-217.pdf

est déjà un traduction de l'anglais : https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf

ça ira plus vite que de le traduire en reverso !

Christophe
7
Vos projets / Re : Carte détecteur de présence 16 entrées RailCom
« Dernier message par laurentr 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

8
Vos projets / Re : Carte détecteur de présence 16 entrées RailCom
« Dernier message par bk4nt le novembre 20, 2024, 01:30:41 pm »
Bonjour,

Je viens de lire Christophe, j'allais ajouter ce qui suit, plus bas. J'ai l'impression que d'une certaine façon, je lui répondais, notamment avec le RP2040...

> Il me semble que ce projet n’a aucun intérêt pratique mais c’est un bel exercice de recherche et développement

J'ai du N, et j'ai pour projet un petit réseau avec plein de sections dans 2m2. Géré par 4 x 16 voies, ça pourrait avoir du sens.

> Ne serait-ce que pour des questions de longueurs de câbles, l’exercice est périlleux.
> Le signal Railcom est très faible et donc très sensible à l’environnement électromagnétique.

> le concept des satellites cherche à promouvoir la notion de de proximité

> un décodeur Railcom adresse un signal environ toutes les 250ms je crois. Si vous multipliez ça par 16 !!!

Ca, c'est bien noté, merci  :)

Avant de me lancer dans le grand de 2m2, je pense construire un réseau de test sur 1m2 avec 4 récepteurs 4 ou 8 voies.


J'ai repéré une autre carte, pour LCC, développée en 2015, qui est intéressante également. Elle n'a que 6 canaux/voies, mais selon une vidéo de présentation, elle a plein de features. Techniquement, c'est encore plus mystique car même le schémas ni d'ailleurs la photo du verso de la carte ne sont disponibles... Voir en page 16 du PDF:

https://openlcb.org/wp-content/uploads/2015/04/LCC-introduction-presentation-Indy-2016.pdf


Les ADC peuvent suffire pour détecter du Railcom. Je pense qu'il faut les oublier pour le décoder car la synchro bits, le taux d'échantillonnage puis le traitement requis poserait vite un problème de performance. Sans compter le prix, j'ai rapidement cherché, ce serait s'orienter vers des modèles d'ADC rapides à 4 ou 8 canaux à plus de 50€.... puis avec des problèmes d'interfaçage avec un petit processeur, lui même rapide.

En UART sur SPI, pour étendre les capacités d'un CPU, je n'ai pas trouvé grand chose. Un FPGA pourrait être la solution, mais compter 50 à 100€ pour un petit kit de dev... Des choses pas trop chères ont été annoncées mais ce n'est pas encore disponible:
https://tinyfpga.com/

Les Teensy 4.0 et 4.1 pourraient être une solution, pour plus d'UARTs dans la puce, 7 à 8, qu'il suffirait d'interfacer avec le circuit connu à comparateurs +/- 18mV. Techniquement, ce devrait être simple. En cas de "présence", les datas CH1 et CH2 aboutiraient dans les UART.

Si j'ai bien compris,  CH1 peut être "pollué" s'il y a plus d'un décodeur/loco sur une même portion de voie. Mais CH2 est utilisé exclusivement par le décodeur adressé, qui y répond par un Ack ou avec des infos supplémentaires (je suppose que ce sera aussi le canal utilisé par RailcomPlus...).


Probablement approprié aussi, et plus abordable, les RP2040 et RP2350, des versions Tiny ou Zero, pour un encombrement moindre. Ces puces n'ont que deux UART matériel. Par contre, ils ont une fonctionnalité PIO qui permet de créer des automates pour émuler jusqu'à 8 ou 12 UART en RX... pour un équivalent "software serial" mais accéléré par le matériel IO:

https://arduino-pico.readthedocs.io/en/latest/piouart.html "Equivalent to the Arduino SoftwareSerial library, an emulated UART using one or two PIO state machines is included in the Arduino-Pico core. This allows for up to 4 bidirectional or up to 8 unidirectional serial ports to be run from the RP2040 without requiring additional CPU resources."

Le 2040 a 8 automates, le 2350 en a 12. Je vais essayer de faire des tests avec le 2040 (dual core à 133MHz compatible IDE Arduino et FreeRTOS). Je pensais d'abord à interfacer 8 voies avec un 2040, mais cela ne permettrait pas de détecter aussi l'orientation d'une loco. Pour 8 voies avec aussi l'orientation, il faudrait un montage plus complexe, des composants en plus... on y perdrait le bénéfice de la simplicité et d'une petite taille.

Du coup, je pense à un petit récepteur simple, pour 4 voies seulement, avec deux PIO UART par voie. Avec le montage connu à deux comparateurs, selon l'orientation de la loco, les données Railcom devraient être reçues dans l'UART A ou B.

Ou encore à plusieurs 2040 sur une même carte pour plus dense, les 2040 échangeant par I2C ou SPI, un main vers le bus CAN et des SPI slaves pour recevoir les données Railcom. Ce serait peut-être une solution éco et simple à mettre en oeuvre pour retrouver jusqu'à 8 ou 16 voies sur une même carte pas trop grande.

Vous avez d'autres avis à ces sujets? Ou existerait-il d'autres solutions assez simples encore?

PS: je n'avais pas vu la solution ESP32 de Christophe à 3 voies / 3 UARTs, je vais aller voir en quoi ça consiste.
9
Vos projets / Re : Carte détecteur de présence 16 entrées RailCom
« Dernier message par bobyAndCo le novembre 20, 2024, 12:48:05 pm »
Bonjour,

Je lis votre fil depuis l’origine avec intérêt mais pas mal de circonspection.

Je me dis après tout que chacun est libre d’imaginer les choses les plus folles (et ce n’est pas péjoratif) mais les atterrissages sont parfois douloureux. Je sais de quoi je parle car je suis adepte de la discipline.

Mais comme mon nom est apparu dans un précédent post, cela m’incite à vous répondre

Il me semble que ce projet n’a aucun intérêt pratique mais c’est un bel exercice de recherche et développement. La preuve, ça a provoqué pas mal de discussions et c’est très bien.

Dans la réalité, a-t-on vraiment besoin qu’un seul microcontrôleur (une seule carte) fasse la détection de 16 zones « Railcom » ?

Ne serait-ce que pour des questions de longueurs de câbles, l’exercice est périlleux. Le signal Railcom est très faible et donc très sensible à l’environnement électromagnétique. Dans la pratique également, le concept des satellites cherche à promouvoir la notion de de proximité avec des cartes « généralistes ». On est ici à l’inverse avec un carte spécialisé qui nécessite qui plus est des performances importantes.

Nous avions réalisé avec MSport, notre regretté camarade Michel, une carte à trois détections Railcom sur un ESP qui compte 3 ports série. C'est déjà pas mal non ?

https://github.com/BOBILLEChristophe/Railcom-detector-freeRtos-inClass/tree/main

Les traitements du signal Railcom sont complexes et nécessitent pas mal de ressources CPU. Ne serait-ce que le décodage 4/8 dont il a été question précédemment. Il faut aussi que ça aille vite, un décodeur Railcom adresse un signal environ toutes les 250ms je crois. Si vous multipliez ça par 16 !!!

Perso, j’irai plus dans le sens de ce que Laurent avance, un petit microcontrôleur ATTinyXXX affecté à une seule détection et une transmission du résultat sur bus CAN. Solution économique et facilement déployable sur un réseau.

Quant à Railcom CH2, quand on m’aura convaincu d’un intérêt pratique quelconque sur un réseau, je veux bien m’y coller comme je l’ai fait pour le CH1. Mais que l’on ne me parle pas de 2 ou plusieurs locos sur une même zone de détection ce qui m’apparait comme un non-sens.

Sur ce, enjoy !

Christophe
10
Vos projets / Re : Carte détecteur de présence 16 entrées RailCom
« Dernier message par laurentr 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


Pages: [1] 2 3 ... 10