Carte détecteur de présence 16 entrées RailCom

[bobyAndCo]

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

[laurentr]

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

[lebelge2]

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.

[laurentr]

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

[bk4nt]

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.

[lebelge2]

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.

[laurentr]

Hello

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

Ltr

[lebelge2]

Impossible de différencier deux locos sur une même zone avec le canal 1, ça a toujours été comme ça.

[bk4nt]

Dans un tout autre registre au grès de mes recherches je suis tombé sur ceci
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.

[Dominique]

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)

[bk4nt]

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 

[Dominique]

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 

[bk4nt]

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

[bk4nt]

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