Auteur Sujet: Carte détecteur de présence 16 entrées RailCom  (Lu 2169 fois)

lebelge2

  • Jr. Member
  • **
  • Messages: 79
    • Voir le profil
Carte détecteur de présence 16 entrées RailCom
« le: novembre 09, 2024, 12:38:57 am »
Bonjour, ma dernière réalisation pour le suivi des trains dotés de la technologie RailCom ou non.
Détection de la présence de matériel roulant par consommation de courant et identification du numéro de loco. sur 16 canaux.

Le détecteur est composé d'une carte fille de chez Olimex  (processeurs Atmel ATXMEGA128A1) et de composants traversants.

C'est un clone du  GBM16T dont les plans, la construction et les fichiers sont libres de droits.

Pour les caractéristiques, je vous renvoie sur le site de l'auteur de la carte originale.
(16 entrées, faible insertion (0,3v), sensibilité ajustable, alimentation par DCC ou séparée, isolation galvanique des masses, etc…)

https://www.opendcc.de/s88/gbm_bidi/gbm_bidi_f.shtml

Je fournis le plan, la liste des composants, le fichier gerber (voir mon Github) ainsi qu’un support pour les interessés de cette réalisation.

https://github.com/Lebelge2/Carte-16-entrees-RailCom


La carte transmet les  rapports d'occupations et détection RailCom via son interface série isolée galvaniquement (9bits, 250.000 bauds)

Les messages peuvent être envoyés sur un logiciel de train tel que : CDM-Rail, JMRI, Rocrail ou LaBox.

La carte fille ATXMEGA128 est fournie sans Bootloader, un programmateur spécifique (PDI) est nécessaire. Voir la doc. (Programmer ATXMEGA128) sur mon Github.


Prix aproximatif des composants de la carte :

PCB carte mère (5 pièces JLCPCB)         5 €
ATXMEGA128 carte fille Olimex         15 €
1 ADUM 1201 (Isolateur magnétique)     1 €
33 diodes 1N5821 (lot de 50)                   4,15 €
32 résistances 1k (lot de 100)                   1,50 €
3 réseaux R1k (lot de 10)                          1,90 €
4 connecteurs mâles 2x10 (lot de 10)        2 €
20 LED 3mm (lot de 100)                         2 €
1 régulateur 7805 (lot de 10)                     1 €
21 borniers pich 5,08 (lot de 30)               3,40 €

Petit matériel
-----------------
1 transistor Mosfet BS170
2 condensateurs 22µF
2 condensateurs 100nF
1 diode Zener 3v3
1 résistance 100  Ohms
1 résistance 10K
1 résistance 20   Ohms 1W
1 Barette pico mâle et femelle 2,54

!!! Remarque :  Les frais de livraisons sont plus chères que le prix des pièces !!!

Démo. avec ce petit script à mettre dans le  void loop()  du  .ino
Affiche dans le moniteur les itinéraires  et numéros des locomotives.


unsigned long crT1 = 0;      // currentTime1
unsigned long pvT1 = 0;     // previousTime1
int DataTemp;
int Data[10];
int NbrData;
int i;

void setup() {   // Dans le setup configurer le sériél
  Serial1.begin(250000, SERIAL_8N1, 13, 14);   // Carte RailCom
//  Serial2.begin(250000, SERIAL_8N1, 15, 17);   // Carte RailCom
}

void loop() {  // A mettre à la fin du loop()

  if (Serial1.available()) {
    DataTemp = (Serial1.read());                 // Lit Data
    crT1 = millis();
    if ((crT1 - pvT1) > 10) {                    // >10ms,  Premier Data
      pvT1 = crT1;
      i = 0;                                     // Init tableau
      NbrData = DataTemp;                        // Nombre de Data dans trame
    }
    Data[i++] = DataTemp;                        // Mémorise les data
    if (i == NbrData + 1) {                      // Tous les Data reçus ?
      if (Data[1] == 2) {                        // Détection RailCom
        Serial.print("Loco n°");   Serial.print(Data[3]);
        if (Data[4] == 0)          Serial.print(" entre dans canton n°");
        else                       Serial.print(" entre à contre sens dans canton n°"); //0x80
        Serial.println(Data[2]+1);
      }
    }
  }
}

Bien à vous.

lebelge2

  • Jr. Member
  • **
  • Messages: 79
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #1 le: novembre 09, 2024, 12:40:55 am »
Premier essai  de trois cartes 16 entrées RailCom, un Arduino Mega et LaBox.

(Voir image)

( Le Mega possède quatre entrées séries, trois sont programmées en entrées et reçoivent les données (9bits) des trois cartes, la quatrième programmée en sortie envoie les données (8bits) vers LaBox.)

Un nouveau fichier nommé Automat.cpp est ajouté  à LaBox.

Fonctions automate programmable.

Deux fonctions principales.

1)   Gestion des signaux automatiquement en mode 2 ou 3BAL.
             Arrêt des locos. devant un signal rouge
             Redémarrage des locos au signal orange (vitesse réduite) ou vert.

2)   Une loco entrant sur un canton peut déclencher des événements, par ex.:
-   Allumage des feux.  (Entrée tunnel (extinction à la sortie))
-   Modifier sa vitesse, sens  ou arrêt.
-   Changer de position un ou plusieurs aiguillages.
-   Gérer une autre locomotive.

Nombreuses possibilités en vue, sans câblage « type usine à gaz » et matériel coûteux…
 
A suivre…


Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 3048
  • 100% Arduino et N
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #2 le: novembre 09, 2024, 10:27:35 am »
Bravo Lebelge2,

Voilà une belle réalisation bien illustrée qui devrait donc intéresser pas mal de modélistes.

Les photos sont superbes.

Pourrais-tu joindre une schéma de principe d'une installation complète montrant les bloc fonctionnels et les liaisons entre blocs.
On voit bien que les 3 cartes détection présence+railcom sont raccordées à un Méga (qui peut offrir les 3 ports série nécessaires) qui est caché sous LaBox.
On voit bien aussi la carte extension Xpressnet reliée à LaBox.

Pour avoir une vue d'ensemble, ces 2 parties sont-elles reliées ensemble ou seulement à un PC avec un logiciel de train ? Et comment ?

Une version avec le buis Can à la place des ports série pourrait être une évolution future possible qui permettrait de se passer du Mega (ou pas ?).

Encore bravo  ;D
« Modifié: novembre 09, 2024, 10:38:53 am par Dominique »
Cordialement,
Dominique

lebelge2

  • Jr. Member
  • **
  • Messages: 79
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #3 le: novembre 09, 2024, 02:38:43 pm »
Bonjour Dominique

Pour mon réseau, je n’utilise pas de PC, auparavant c’était un Arduino Uno qui gérait les signaux en 3 Bal et l’arrêt et le redémarrage des trains.
Cela fonctionnait correctement.
Actuellement je transcris le code pour l’ESP32 de LaBox, les premiers essais sont en cours.
Il est possible de remonter les messages d’occupations vers un logiciel PC à condition de connaître le protocol !
Je n’y connais rien en CAN, j’ignore si une transmission en 9 bits 250.000 Bauds est possible !
Ci-joint un schéma bloc de mon installation.

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 3048
  • 100% Arduino et N
    • Voir le profil
Re : Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #4 le: novembre 09, 2024, 04:23:15 pm »
Je suis dans le même cas : pas de PC ni Mac (une tablette iPad à la rigueur mais je n'aurai pas le temps d'apprendre Swift et la programmer).
Je préfère un gestionnaire qui ne fait que cela, reçoit tous les événements du réseau et commande les trains, les signaux et les aiguilles (voire beaucoup plus comme les animations du réseau). Le seul gestionnaire hors PC que je saurais maitriser et adapter est celui de Pierre59 à configurer dans le code ou en JSON (si ça arrive bientôt).

Le bus CAN est la meilleure solution pour séparer les entités fonctionnelles et réaliser des développements indépendants les uns des autres et j'affirme que ce n'est pas plus compliqué que gérer un port série, et surement avec moins de problèmes :
- tout le protocole CAN est géré dans un contrôleur qui est soit intégré (comme dans l'ESP32 et de plus en plus de circuits) soit extérieur comme le MCP2515 ou 2517FD.
- Il s'interface en bus SPI donc ce qu'il y a de plus rapide avec 3 pins (MISO, MOSI et CLK) + in CS (chip sélect) et une entrée INT interruptions. Donc plusieurs périphériques SPI en // possibles. C'est presque moins que 3 ports série (6 pins).
- le contrôleur contient des tas de buffets d'entrée et de sortie intégrés et il gère intelligemment la présence des autres entités dans le réseau (tu déconnectes un cable, ça s'arrête et l'émetteur est prévenu, tu reconnectes et ça repart.
- les données ne sont jamais perdues (pas comme le serial, qui n'a qu'un seul buffet et en perd souvent, très souvent)
- des cables de liaison n'ont besoin que de 2 fils (on utilise du fil téléphonique en général) et on peut ajouter l'alimentation comme le fait Christophe.
- plus rapides : jusqu'à 1Mb/s et même 8Mb/s en CAN FD (que je n'ai pas essayé). Chaque message CAN peut contenir jusqu'à 8 octets en Can classique (celui qu'on utilise en général) et jusqu'à 64 octets en Can FD
- tu n'es plus limité aux 3 ports série du Mega, le Can supporte plus de 100 entités sur le même bus !
- etc : il y a plein de choses écrites sur le Can dans Locoduino et même le bouquin de Pierre Molinaro qui fournit les bibliothèques.



Je n’y connais rien en CAN, j’ignore si une transmission en 9 bits 250.000 Bauds est possible !
Ci-joint un schéma bloc de mon installation.

Comme indiqué plus haut, ce sont des octets de 8 bits chacun, en messages de 1 à 8 octets qu'on peut combiner de toutes les façons possibles (64 bits)

Il faut essayer le Can avec pratiquement tous les microcontroleurs c'est possible : on en a parlé très souvent.
LaBox supporte le Can sans problème : elle contient déjà un fichier Can prévu pour les commandes Marklin. On peut définir d'autres messages si besoin en plus ou à la place.

Pour démarrer en CAN, le plus simple est de faire un montage de test et d'utiliser les exemples fournis dans la bibliothèque ACAN-ESP32 par exemple, LoopBackDemo pour commencer et vérifier les branchements avec le contrôleur Can. Après tu remplaces le mode LoopBack par le mode Normal et tu branches un autre circuit. Il n'y a qu'un instruction send et une instruction receive : c'est très simple !

En ce moment je fais joujou avec des satellites PICO de Jean-Luc et ça fonctionne très facilement avec un Pico et un MCP2515.


Dis nous si tas as des questions.

« Modifié: novembre 09, 2024, 04:41:54 pm par Dominique »
Cordialement,
Dominique

Dominique

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 3048
  • 100% Arduino et N
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #5 le: novembre 09, 2024, 07:02:22 pm »
Et merci pour ton schéma d’installation, il est très clair.
Cordialement,
Dominique

bk4nt

  • Newbie
  • *
  • Messages: 32
    • Voir le profil
Re : Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #6 le: novembre 14, 2024, 07:15:31 pm »
Bonjour lebelge2,

D'abord merci pour tous vos partages.

Même si après vous avoir un peu lu seulement, je ne sais déjà plus par où commencer   ;)

Pour le moment, je n'ai qu'un projet et je cherche à comprendre mieux le fonctionnement de ces solutions avant de me lancer.

C'est un clone du  GBM16T dont les plans, la construction et les fichiers sont libres de droits.

Pour les caractéristiques, je vous renvoie sur le site de l'auteur de la carte originale.

Je n'ai pas trouvé les codes sources, juste un hex, et je me pose des questions, dont sur Railcom, le protocole. Et le site de l'auteur ne répond pas à toutes les questions qu'on pourrait se poser sur le fonctionnement de la solution mise en oeuvre avec ce GBM16T. Je vais essayer de creuser encore...

Nombreuses possibilités en vue, sans câblage « type usine à gaz » et matériel coûteux…

Cette version GBM16T a manifestement été très simplifiée. Ce ne sont plus des récepteurs Railcom, mais de simples détecteurs, 16, de signaux sur une portion de voie. Ce qui semble être suffisant et de fait économique, dont en terme d'encombrement (type et nombre de composants, dimensions de la carte, pour une solution économique).

Les 16 ports/portions de voies sont reliés à des entrées analogiques. De là, il est facile de mesurer une tension/courant pour évaluer une occupation de voie, par la consommation de courant de ce qui y circule.

Par contre, j'ai du mal à comprendre comment ce système peut effectivement traiter/détecter des signaux Railcom, un signal série, à 250000 Baud... ou des transitions électriques rapides et très faibles en amplitude lorsqu'une loco répond. Peut-être par échantillonnage des 16 voies, pour détecter ces signaux? Puis pour identifier une loco, le processeur s'en tient à ce qui a été précédemment envoyé via DCC?

Dans la doc de la NMRA, en 3.1, je lis: "Channel 1 is used for locating mobile decoders on the layout (see app: adr). To do this, they must send their DCC address after every DCC packet sent to a mobile decoder, which is then received by local detectors on the layout." https://www.nmra.org/sites/default/files/standards/sandrp/DCC/S/s-9.3.2_bi-directional_communication.pdf

Ce qui signifierait bien qu'on peut se contenter d'être à l'écoute des trames DCC, puis de constater sur quelle voie la loco correspondante répond, sans nécessairement bien lire et ni décoder le message que la loco renvoie.


Sur la version allemande du site, on trouve la version A de ce GBM16T qui était plus complexe. Mais avec de vrais récepteurs Railcom. On pourrait supposer que ces versions avec multiples récepteurs Railcom sont inutiles pour un système simple, qui n'utiliserait pas le canal 2 de Railcom.

Le PDF de la version A, le schémas est plus dense que la version B: https://www.opendcc.de/s88/gbm_jk1/bidi_xpn_gbm.pdf

Je réfléchissais à construire quelque chose de similaire à la version A. Mais si la version B est suffisante...
« Modifié: novembre 14, 2024, 07:19:21 pm par bk4nt »

lebelge2

  • Jr. Member
  • **
  • Messages: 79
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #7 le: novembre 14, 2024, 08:14:00 pm »
Bonjour.
Ce sont bien les convertisseurs Analogiques digitales qui échantillonnent le signal RailCom (250.000 Bauds)
Il y en a quatre et sont très rapides (2 millions de conversions par seconde)
Comme je peux le comprendre, il y a quand même un multiplexage.
Un convertisseur échantillonne à la fois deux trames RailCom en alternant deux entrées.
Ainsi, huit entrées sont analysées par trames.

Ici extrait du Datasheet de l'ATXMEGA128

25.2 Overview
The ADC converts analog signals to digital values. The ADC has 12-bit resolution and is capable of converting up to two
million samples per second (MSPS). The input selection is flexible, and both single-ended and differential measurements
can be done. For differential measurements, an optional gain stage is available to increase the dynamic range. In
addition, several internal signal inputs are available. The ADC can provide both signed and unsigned results.


Et dans la doc. de l'auteur (Traduite de l'allemand)

Plusieurs locomotives dans une section
Railcom reconnaît 2 canaux pour recevoir les messages en provenance des locomotives. Le canal 1 est un canal de diffusion (broadcast) dans lequel chaque décodeur envoie en continu sur son adresse. S'il y a plusieurs décodeurs dans une section, les signaux se chevauchent et interfèrent. Au contraire, dans le canal 2 seulement le décodeur adressé peut envoyer (diffuser) son adresse.

Le GBM16T reçoit sur deux canaux, et peut ainsi distinguer jusqu'à 4 locomotives. Si dans le canal 1 aucune erreur ne s'est produite sur trois annonces d'adresses successives, cette adresse est acceptée comme valable. De même l'adresse DCC actuelle est acceptée comme valable, si le canal 2 reçoit une réponse exacte.


L'auteur ne fourni plus le code source, uniquement .hex et .epp

Bien à vous.


bk4nt

  • Newbie
  • *
  • Messages: 32
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #8 le: novembre 14, 2024, 09:44:56 pm »
Merci pour la réponse.

En effet, l'ADC semble être évolué, rapide, avec 4 canaux (et deux ports 8 entrées utilisés) pour les conversions, avec un transfert via DMA. Mais les comptes n'y sont pas, même avec les 2 millions de conversions par secondes selon les specs du constructeur. 16 canaux à 250k, ça devrait nécessiter 4 millions de conversions par seconde, en étant synchrone. Son code se contenterait d'un bit sur deux? Les données Railcom sont encodées 4/8.

Il y a quelque chose de mystique dans la solution, dont pour interfacer cet ADC avec les signaux électriques, qui peuvent être négatifs selon le sens de circulations des locos. J'imagine qu'il utilise les pull-ups des entrées, pour décaler la tension en entrée de l'ADC.

Et en effet, je viens de lire que son code source n'est plus accessible que sur demande. Dommage, il doit être intéressant à lire.

J'ai repéré une autre solution (commerciale) qui annonce faire la même chose, mais la carte est plus grande et à nouveau plus fournie en composants.

trimarco232

  • Sr. Member
  • ****
  • Messages: 345
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #9 le: novembre 15, 2024, 01:53:04 am »
Bonjour,
mystique , je ne pense pas , les choses sont peut-être même assez simples :
- il détecte , sans les décoder , la présence de signaux railcom sur le canal 2 , en correspondance avec le message dcc qui vient d'être envoyé : les décodeurs doivent au moins renvoyer un ACK
- il faut pouvoir , pour cette détection , traiter des petits signaux négatifs et en donner le signe : l'adc de l'xmega sait le faire , parce qu'il fonctionne en différentiel , et accepte des signaux j'usqu'à -0.3v (schottky de protection de la broche)

donc la seule info qu'on a , c'est la présence de la loco , avec son adresse dcc et son sens de placement ; les infos du genre vitesses de la loco ne sont pas décodées , il faudrait en effet + d'électronique pour ça
« Modifié: novembre 15, 2024, 11:54:32 am par trimarco232 »

bk4nt

  • Newbie
  • *
  • Messages: 32
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #10 le: novembre 19, 2024, 09:08:31 pm »
Bonjour,

Je suis allé voir la doc de l'ATXMEGA128. Il est bien limité à 2MSPS (sur 8 bits, pas 12). Ce qui ne suffirait donc pas pour décoder 16 signaux Railcom à 250kbps. Par échantillonnage de quelques bits sur le canal 2, on ne pourrait donc que détecter qu'il existe un signal sur une voie.

Je ne sais pas s'il serait possible de décoder les canaux 2 de quelques voies seulement, ce après avoir détecté une présence via les canaux 1. Ce qui nécessiterait d'être parfaitement synchro.

Je ne pense pas que le principe soit basé sur l'ADC en mode différentiel (différence entre deux entrées, limité pour une part entre les entrées 0 à 3, et avec les autres canaux pour du différentiel).

La doc ATXMEGA explique que généralement, ces ADC ne peuvent pas mesurer 0V, qu'ils rapportent tous des valeurs légèrement supérieures. Pour y palier, en single ended, donc 16 entrées distinctes, cet ADC a un offset sur sa référence. Ce qui permet de calibrer l'ADC, et pour afficher 0 pour 0V en entrée. Puis de ce fait, cet ADC permettrait de mesurer des valeurs négatives, légèrement inférieurs à 0V. D'après ce que j'ai lu, de l'ordre de -0,1V max. Faudrait tester pour voir comment ça se comporte, ce que l'auteur a dû faire.

22 Ohm pour détecter +/- 10mA... Cette solution serait donc adaptée pour mesurer des valeurs nulles, ou à +0,22V, ou à -0,22V. Supposant qu'il s'agit d'une réponse ou d'un Ack à un message DCC, on en déduit l'ID de la loco. Puis selon le signe, on en déduira l'orientation.


Du coup, je me demande s'il est utile d'en faire plus.

Ce genre de détecteurs "simples" sont ils complétés par un récepteur Railcom au niveau du booster? Pour avoir à la fois les occupations/orientations et les messages du canal 2. Soit dans l'exemple d'ici, des modules 16 détecteurs pour localiser les locos, et en ajoutant un récepteur Railcom unique au booster pour lire les CH1 et CH2.

Ou serait-il utile de se casser la tête pour avoir un récepteurs Railcom dédié à chaque petite portion de voie? Ce serait un peu plus compliqué ou dense en composants.

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #11 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



bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1088
  • HO avec DCC++
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #12 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
« Modifié: novembre 20, 2024, 12:50:46 pm par bobyAndCo »

bk4nt

  • Newbie
  • *
  • Messages: 32
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #13 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.
« Modifié: novembre 20, 2024, 01:35:26 pm par bk4nt »

laurentr

  • Hero Member
  • *****
  • Messages: 648
    • Voir le profil
Re : Carte détecteur de présence 16 entrées RailCom
« Réponse #14 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