LOCODUINO
Parlons Arduino => Vos projets => Discussion démarrée par: lebelge2 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.
-
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…
-
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
-
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.
-
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.
-
Et merci pour ton schéma d’installation, il est très clair.
-
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...
-
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.
-
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.
-
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
-
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.
-
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 (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 (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
-
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 (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
-
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.
-
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 (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 (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
-
Pourquoi faire simple quand on peut faire compliqué ?
Le document dont tu donnes le lien :
https://normen.railcommunity.de/RCN-217.pdf (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
-
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
-
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.
-
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
-
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.
-
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.
-
Hello
Donc sans canal 2 point de salut si plus d'un engin sur une zone? ( on en revient à la justification du CH2)
Ltr
-
Impossible de différencier deux locos sur une même zone avec le canal 1, ça a toujours été comme ça.
-
Dans un tout autre registre au grès de mes recherches je suis tombé sur ceci
https://github.com/bakerstu/openmrn (https://github.com/bakerstu/openmrn)
Du coup, je me permets de dévier un peu alors que LCC m'a intéressé également. Ce sont des librairies pour des ESP32, des TI ou des ST (etc...) (voir le contenu de la rubrique boards). Et apparemment, ça gère l'écriture de données LCC persistantes en flash, sur un système de fichier (d'où des memory maps dans la section boards).
Problème pour mon projet à base de RP 2040: ce chip là n'est pas supporté car il n'intègre pas de hardware CAN. Ce qui m'amènera peut-être à en faire plutôt un petit périphérique SPI, pour un ESP32. Ca resterait peu encombrant.
En complément, j'ai trouvé ceci, tout un contenu à explorer. "This is a collection of Model Railroad open hardware and open source projects, using LCC / OpenMRNIDF, for the ESP32 family of MCUs"
https://github.com/RobertPHeller/ESP32-LCC
Des schémas, des cartes, et même des sketchs pour les utiliser (ça devrait être exploitable avec Jmri):
https://github.com/RobertPHeller/ESP32-LCC/tree/master/ESP32MRNSketches
Y a de quoi faire. Et probablement de quoi en faire un sujet nouveau.
OpenMRNIDF, je pense que c'est cela, le sous ensemble OpenMRN pour l'IDE Expressif. La version LCC Lite de OpenNRM pour Arduino, c'est déjà moins dense, plus abordable:
https://github.com/atanisoft/OpenMRNIDF/
La carte 16 voies Railcom proposée par lebelge2 n'étant pas perdue. Sa sortie sur 9 bits devrait être un protocole ou une trame toute simple. Qu'un ESP32 pourrait traiter et interfacer avec CAN ou Wifi avec du LCC.
-
Ajouter le Can à un RP2040 est très simple en lui associant un MCP2515 et un MCP2562. En le connectant au port SPI1 (il y a 2 SPI sur le RP2040), il reste le SPI standard pour connecter d’autres périphériques et une dizaine de ports restant.
Actuellement je teste avec Can + écran TFT + carte SD avec les bonnes bibliothèques TRT_eSPI, RP2040_SD et ACAN2515.
Ca fonctionne nickel et ça va vite avec un bus Can à 125 kb/s (pour une longue distance)
-
Evidemment, souder quelques fils et utiliser des librairies existantes, c'est facile. Dans la rubrique Board des librairies, plus haut, les définitions pour un RP-2040 n'existent pas; ça en fait une toute autre histoire :)
-
Si ça existe pour le TFT et le SD.
Pour ACAN2515, c’est du SPI tout simple et il y a des exemples PICOSPI en plus des exemples ESP32 et Teensy.
Et en plus ça marche ;D
-
C'est un problème de performance, et de librairies existantes ou non.
Pour le RP 2040, il y a eu une demande (récente) pour qu'il soit ajouté: https://github.com/bakerstu/openmrn/issues/802
La réponse: "it may or may not be feasible for some use cases (higher data rates such as used in CDI/FDI/datagram communications)."
Seul certains processeurs ou gammes assez performantes ont dû être évalués et approuvés par le groupe de travail, avec des IDE pour processeurs embarqués. Je n'y vois pas non plus le Tensy 4.x qui ne manque pourtant pas de ressources. Et leur version pour Arduino (esp32 ou STM32 seulement) n'est que Lite (sans que je sache pour le moment à quoi ça correspond).
Apparament, avec le LCC, les performances des CPU/interfaces CAN pourraient avoir un impact avec un grand nombre de noeuds, qui échangent entre eux, des notifications, des changements d'états. "The Node is the building block of an OpenLCB/LCC network. Each Node can communicate with any other Node on the network by sending events or datagrams over the common bus. "
-
il y a des exemples PICOSPI en plus des exemples ESP32 et Teensy.
Je suis fainéant. Si je peux éviter d'adapter ou d'avoir à trop modifier des librairies, je préfère :)
Github, un océan difficile à sonder... Pour du Pico, du Teensy ou même des ATMega ave un 2515, des solutions (puis des dérivés/fork) existent bien:
https://github.com/openlcb/OpenLCB_Single_Thread/tree/master
Pour le Pico, du coup, c'est particulier. Il n'a pas de périphérique CAN. Mais le RP2040 a donc 8 automates PIO; ils en utilisent 4 pour émuler un périphérique CAN:
https://github.com/openlcb/OpenLCB_Single_Thread/tree/master/src/Pico
Pour mon projet, il me faudrait alors un Pico RP2050 qui a 12 PIO: 4 PIO pour le CAN, et 8 pour les UART Rx.
J'ai trouvé cette autre info, qui est à nouveau aussi en rapport avec le sujet initial, la carte 16 voies Railcom, pour identification des locos et de leur direction. Une fois les locos détectées ou les messages Railcom reçus, il faut en faire quelque chose...
Côté OpenLCB/LLC, un message avec payload (Railcom, RFID, QR code, ...) est encore à l'étude:
https://groups.io/g/openlcb/topic/106923474#msg16081
https://github.com/openlcb/documents/blob/c688d6e/drafts/LocationServiceWN.pdf