LOCODUINO
Discussions Générales => Bus DCC => Discussion démarrée par: bobyAndCo le octobre 14, 2023, 03:39:57 pm
-
Bonjour à tous.
J’avais déjà parlé dans divers fils du forum du travail réalisé en commun avec Marcel (Catplus) pour réaliser une solution complète de détection Railcom.
Un article du site éditorial présente en détail cette réalisation : https://www.locoduino.org/spip.php?article334
mais il ne peut malheureusement pas aborder tous les points et/ou les aborder avec tout le niveau de précision que certains auraient pu souhaiter.
L’objectif de ce fil créé en parallèle de l’article est justement de permettre à chacun de s’exprimer, de proposer, de poser des questions.
Ainsi, nous l’espérons, nous pourrons faire évoluer encore les choses et probablement apporter des compléments à la publication de base.
N’hésitez surtout pas à vous mettre au clavier !
Christophe
-
Bonjour,
J’ai une question de définition ; est-ce que Railcom ne s’utilise que pour les locos ?
Lorsque l’on discute avec un décodeur d’accessoires (décodeur de signaux par exemple), est-ce la même norme ou une différente ?
Merci.
-
Bonjour,
Par sa nature même, oui Railcom ne s'utilise que sur les locos puisque qu'il s'agit de lire l'adresse (CV1) d'un décodeur !!!
-
Salut Christophe, super initiative ça! J'avais suivi un peu le truc avec Marcel, impressionnant le boulot. Je vais checker l'article et probablement revenir avec quelques questions. Y a toujours des trucs à peaufiner ou à ajouter, c'est ça qui est cool avec la communauté. À plus sur le clavier!
-
Avec plaisir pour répondre à tes questions. Le moins que l'on puisse dire c'est que ce fil ne me donne pas beaucoup de travail donc ...
Christophe
-
Pour ma part, je répond juste pour manifester mon intérêt mais je crains ne pas pouvoir apporter grand chose au niveau technique...
Railcom me semble être une évolution majeure dans la gestion d'un réseau. Je pense que toutes les solutions actuelles avec les suivis de trains sur les logiciels n'auraient pas été conçues de la sorte si Railcom avait été présent dès le début.
Dans l'optique d'un réseau modulaire qui se construit par étape et non pas par conception complète dès le départ, la notion de gestion décentralisée est primordiale. Je pense bien sur aux satellites autonomes même si je trouve un peu compliqué d'avoir une carte par canton.
L'exemple qui me vient à l'esprit est le controle aérien (ca doit exister pour les trains... ) quand un avion est sur une zone, il est géré par un contrôle puis lorsqu'il la quitte, c'est un autre qui prend le relais.
Il est bien sur possible de tracer le train de zone en zone en communiquant son CV, mais c'est aussi possible de détecter n'importe quel train qui se présente à l'entrée d'une zone et de gérer son comportement sur cette zone. De cette façon, une seule carte gestionnaire par zone peut gérer quelques cantons. On pourrait même envisager de changer de réseau avec des bascule de cantons comme les boucles de retournement, Ou travailler à plusieurs, chacun sur des modules indépendants qui se relieraient pour une expo...
Pour cela 2 pré-requis:
- une zone doit avoir des entrées et sorties à sens unique ( possible en voie unique mais il faut alors un minimum de communication entre les zones.)
- un train qui n'est pas au feu rouge doit avancer.
On peut ensuite "jouer" ou programmer des scenarios et gérer la sécurité dans chaque zone.
Tout comme les satellites autonomes, ce mode de gestion n'est pas applicable à tout réseau et ne conviendrait pas à tout le monde.
J'aurais vraiment envie d'expérimenter dans cette voie mais je suis pour l'instant bloqué par mes centrales DIY : un Mega avec shield moteur puis maintenant Labox, qui ne gèrent pas le Cutout nécessaire au railcom.
Vu l'activité impressionnante de création sur ce site, je suis sur qu'une solution diy, finira par se présenter...
-
Railcom me semble être une évolution majeure dans la gestion d'un réseau. Je pense que toutes les solutions actuelles avec les suivis de trains sur les logiciels n'auraient pas été conçues de la sorte si Railcom avait été présent dès le début.
Oui c'est vrai que Railcom est vraiment la meilleure solution selon moi. J'ai maintenant un peu plus d'une année de recul avec une utilisation intensive pour la mise au point des satellites et vraiment, je lui trouve de plus en plus de qualités.
J'avais envisagé au départ faire cohabiter RFID et Railcom dans les satellites. Mais outre le fait que le RFID nécessite un peu plus d'infrastructure (perçage du plan, plus de fils, tag sous la loco...) j'ai été par exemple confronté au fait que l'on doit attendre de passer sur le capteur qui est souvent en milieu de canton pour une voie à double sens. C'est trop long pour le cas où il faut un ralentissement. Reste aussi que le RFID décroche si la vitesse du train est trop rapide.
Ca reste une bonne solution si on les place à des points stratégiques comme l'a fait Dominique (entrée ou sortie de gare par exemple) mais on n'aura pas une reconnaissance sur chaque canton comme Railcom sauf à mettre un suivi logiciel des trains ce qui n'est pas très compliqué avec les satellites autonomes.
même si je trouve un peu compliqué d'avoir une carte par canton
C'est vrai qu'on peut le voir comme cela. Maintenant, quand je vois finalement le nombre de choses que l'on peut faire (que l'on doit faire), je me dis que ce n'est pas superflus. Tu as peut-être vu que je cherche maintenant à faire une détection locale de trains mais aussi de wagons et aussi une gestion locale des courts-circuits, alors oui ça peut sembler beaucoup. A chacun de peser le pour et le contre.
Il y a d'autres approches j'en suis convaincu. Je n'ai pas prétendu que cette version serait un point final. J'ai compris dès le départ, et j'ai été conforté au fur et à mesure que j'écrivais le code, que le concept est loin d'être bridé. Je pense par exemple à une gare cachée avec de nombreuses aiguilles et je pense que le concept est bien adapté.
Merci de nous tenir informé de tes avancées.
PS : Si vraiment tu veux Railcom sur le hard de la Box, je l'ai développé mais on n'a pas toutes les fonctions de la Box (Lecture et programmation de cv's, écran LCD...) mais pour faire des tests.
Pour Railcom sur la Box, tu as peut être vu mon post suite à la récente publication de Thierry. Sur ESP32, je suis loin d'être aussi optimiste que lui. Aux vues des avancées de développements, je pense sur Mega dans un premier temps et STM32 rapidement ensuite.
Christophe
-
Hello everyone,
I have been experimenting for a while with Railcom and Arduino and was very pleased to discover this project :)
Electronics is not my speciality but i was able to order some PCBs from the supplied Gerbers and assemble a working decoder board. I would like to make a custom version now but would like to understand if there is anything special about the non-polarised capacitor types. It looks like there is RC filter with a 1nF at the output of the cutout detection, and then another one with a 680pF at the output of the 7402 where the serial is detected. Does it matter if these are MLCC, or polypropylene, polystyrene, or anything else?
Thanks in advance, i will keep you posted with my progress...
Best,
Joel.
-
Dear Joel
Welcome!
MLCC capacitors should be enough on such layout for "uncoupling" ( X5R, X7F).
I invite you to follow the Satellites Autonomes posts where some refondation of this project have been made ( my proposal).
Ltr
-
J’avais déjà parlé dans divers fils du forum du travail réalisé en commun avec Marcel (Catplus) pour réaliser une solution complète de détection Railcom.
Christophe
Bonjour Christophe,
jusqu'à présent le Railcom n'avait pas éveillé ma curiosité vue la petitesse de mon réseau, mais j'ai de plus en plus de gros réseaux autour de moi pour lesquels je crée des cartes diverses, souvent à base de WeMos ou d'ESP32 et certains de leur propriétaire commencent à me poser des question sur cette technologie.
Aurais-tu encore des PCB de disponibles (avec ou sans composants) et serais-tu d'accord de m'en vendre 1 ou 2 ?
Merci par avance pour ta réponse et bon dimanche soir à toi.
Cordialement
Antoine
-
Bonjour Antoine,
Pour l'instant, je n'ai que des cartes montées. Celles-ci reviennent à 6€ environ. Tu as une alternative avec Laurent de son côté vient juste de produire des cartes Railcom en composants CMS. Marcel les a testées et elles sont OK.
J'ai des cartes vierges qui sont en production mais je pense qu'il faut encore compter 10 jours environ.
Dis moi ce que tu décide !
Christophe
-
Super, je suis preneur de 2 cartes montées, donne moi le montant total avec port et si PayPal est possible pour toi, je t'envoie mon adresse par MP.
-
Bonjour,
A tout hasard, est il possible d'avoir les fichiers pour commander les cartes en smt, je ne sais pas si ils avaient été publiés.
Merci beaucoup
-
Bonjour à tous
Content que ce sujet commence à vous intéresser.
2 choses:
La carte construite par Christophe fonctionne parfaitement (à voir l'encombrement)
La carte construite par Laurent fonctionne également sans aucun problème (les composants utilisés sont de type cms, un autre avantage l'encombrement est beaucoup plus petit)
Mais Attention NE PAS OUBLIER, IMPERATIF que votre centrale soit être équipée du CUTOUT (voir tous les posts de Christophe, LeBelge2, etc...)
A voir
https://www.locoduino.org/spip.php?article334
-
Bonjour,
Je me suis monté une carte de Christophe, j'utilise une centrale Labox avec la modif pour le Cutout mais je n'ai pas le résultat escompté :
J'utilise le 1er programme dans l'article.
Dès que la loco rentre sur le canton, j'ai une suite de chiffre qui défile trés rapidement sur le moniteur série avec de temps à autre le message "adresse loco :12850" (l'adresse réelle est 50) ou 12800 quand l'adresse réelle est 3
Quand le loco est à l'arret, je n'ai plus de message.
l'horodatage des messages donne une idée de la vitesse de défilement. (j'ai également une petite vidéo)
Je ne sais pas trop ou regarder
Merci d'avance si vous avez une idée....
-
Bonjour,
Peux-tu être plus précis sur la version du programme et le nom du projet.
Ceux-ci s'affichent dans le moniteur série au démarrage du programme et sont également écrits dans le programme :
#define VERSION "v 1.4"
#define PROJECT "Railcom Detector ESP32 (freeRTOS)"
-
A priori, c'est la version 1.4
J'ai copié/collé directement le code dispo sur le site sans aucune modification.
J'ai juste branché la sortie detection sur le GPIO14
J'avais auparavant essayé avec Railcom in class sur la pin 33 mais ça ne fonctionnait pas non plus.
Je me demandais comment pouvoir controler le signal qui sort de la carte
/*
Programme de lecture et de décodage des messages Railcom ©
qui retourne l'adresse d'un décodeur (adresse courte ou longue)
Fonctionne exclusivement sur ESP32
*/
#ifndef ARDUINO_ARCH_ESP32
#error "Select an ESP32 board"
#endif
#include <Arduino.h>
#define VERSION "v 1.4"
#define PROJECT "Railcom Detector ESP32 (freeRTOS)"
#define AUTHOR "christophe BOBILLE Locoduino : christophe.bobille@gmail.com"
#include <RingBuf.h> // https://github.com/Locoduino/RingBuffer
#define NB_ADDRESS_TO_COMPARE 100 // Nombre de valeurs à comparer pour obtenir l'adresse de la loco
RingBuf<uint16_t, NB_ADDRESS_TO_COMPARE> buffer;
TaskHandle_t ReceiveData;
TaskHandle_t ParseData;
// Identifiants des données du canal 1
#define CH1_ADR_LOW 4
#define CH1_ADR_HIGH 8
const byte railComRX = 14; // GPIO14 connecté à RailCom Detector RX
const byte railComTX = 12; // GPIO12 non utilisée mais doit être déclarée
// Queue
#define QUEUE_SIZE 10
QueueHandle_t xQueue;
void receiveData(void *pvParameters)
{
TickType_t xLastWakeTime;
xLastWakeTime = xTaskGetTickCount();
uint8_t compt{0};
uint8_t inByte{0};
for (;;)
{
while (Serial1.available() > 0)
{
if (compt == 0)
inByte = '\0';
else
inByte = (uint8_t)Serial1.read();
compt++;
if (compt == 3)
compt = 0;
xQueueSend(xQueue, &inByte, 0);
Serial.println(inByte);
}
// Serial.println("---------");
vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(10)); // toutes les x ms
}
}
void parseData(void *pvParameters)
{
bool start{false};
byte inByte{0};
uint8_t rxArray[8]{0};
uint8_t rxArrayCnt{0};
byte dccAddr[2]{0};
int16_t address{0};
TickType_t xLastWakeTime;
xLastWakeTime = xTaskGetTickCount();
const byte decodeArray[] = {255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 64, 255, 255, 255, 255, 255, 255, 255, 51, 255, 255, 255, 52,
255, 53, 54, 255, 255, 255, 255, 255, 255, 255, 255, 58, 255, 255, 255, 59, 255, 60, 55, 255, 255, 255, 255, 63, 255, 61, 56, 255, 255, 62,
57, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 36, 255, 255, 255, 35, 255, 34, 33, 255, 255, 255, 255, 31, 255, 30, 32, 255,
255, 29, 28, 255, 27, 255, 255, 255, 255, 255, 255, 25, 255, 24, 26, 255, 255, 23, 22, 255, 21, 255, 255, 255, 255, 37, 20, 255, 19, 255, 255,
255, 50, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 14, 255, 13, 12, 255, 255, 255, 255, 10, 255,
9, 11, 255, 255, 8, 7, 255, 6, 255, 255, 255, 255, 255, 255, 4, 255, 3, 5, 255, 255, 2, 1, 255, 0, 255, 255, 255, 255, 15, 16, 255, 17, 255, 255, 255,
18, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 43, 48, 255, 255, 42, 47, 255, 49, 255, 255, 255, 255, 41, 46, 255, 45, 255, 255,
255, 44, 255, 255, 255, 255, 255, 255, 255, 255, 66, 40, 255, 39, 255, 255, 255, 38, 255, 255, 255, 255, 255, 255, 255, 65, 255, 255, 255, 255,
255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255};
auto check_4_8_code = [&]() -> bool
{
if(decodeArray[inByte] < 255)
{
inByte = decodeArray[inByte];
return true;
}
return false;
};
auto printAdress = [&address]()
{
Serial.printf("Adresse loco : %d\n", address);
};
for (;;)
{
do
{
xQueueReceive(xQueue, &inByte, pdMS_TO_TICKS(100));
if (inByte == '\0')
start = true;
} while (! start);
start = false;
for (byte i = 0; i < 2; i++)
{
if (xQueueReceive(xQueue, &inByte, pdMS_TO_TICKS(100)) == pdPASS)
{
if (inByte > 0x0F && inByte < 0xF0)
{
if (check_4_8_code())
{
rxArray[rxArrayCnt] = inByte;
rxArrayCnt++;
}
}
}
}
if (rxArrayCnt == 2)
{
if (rxArray[0] & CH1_ADR_HIGH)
dccAddr[0] = rxArray[1] | (rxArray[0] << 6);
if (rxArray[0] & CH1_ADR_LOW)
dccAddr[1] = rxArray[1] | (rxArray[0] << 6);
address = (dccAddr[1] - 128) << 8;
if (address < 0)
address = dccAddr[0];
else
address += dccAddr[0];
uint16_t j = 0;
buffer.pop(j);
buffer.push(address);
bool test = true;
do
{
if (buffer[j] != address)
test = false;
j++;
} while (test && j <= buffer.size());
if (test && address > 0)
{
printAdress();
}
// else
// Serial.println("NOK");
}
rxArrayCnt = 0;
for (byte i = 0; i < 2; i++)
rxArray[i] = 0;
vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(100)); // toutes les x ms
}
}
void setup()
{
Serial.begin(115200);
Serial.printf("\n\nProject : %s", PROJECT);
Serial.printf("\nVersion : %s", VERSION);
Serial.printf("\nAuthor : %s", AUTHOR);
Serial.printf("\nFichier : %s", __FILE__);
Serial.printf("\nCompiled : %s", __DATE__);
Serial.printf(" - %s\n\n", __TIME__);
Serial1.begin(250000, SERIAL_8N1, railComRX, railComTX); // Port série pour la réception des données (250k bauds)
uint16_t x = 0;
for (uint8_t i = 0; i < NB_ADDRESS_TO_COMPARE; i++) // On place des zéros dans le buffer de comparaison
buffer.push(x);
xQueue = xQueueCreate(QUEUE_SIZE, sizeof(uint8_t)); // Création de la file pour les échanges de data entre les 2 tâches
xTaskCreatePinnedToCore(receiveData, "ReceiveData", 2048, NULL, 10, NULL, 0); // Création de la tâches pour la réception
xTaskCreatePinnedToCore(parseData, "ParseData", 2048, NULL, 10, NULL, 1); // Création de la tâches pour le traitement
while (true)
;
}
void loop(){}
Tu reconnaiteras la carte :)
je ne m'en sers que comme branchement de la pin14, pour le reste (Can..) rien n'est activé dans le code
-
Bon j'ai regardé. J'avais une version plus récente (1.5) qui fonctionne chez moi.
Elle est en PJ. Dis moi si ça fonctionne pour toi et je mettrai à jour sur le site
Christophe
-
J'en ai profité pour tester les autres versions que j'avais publiées.
La plus intéressante à mon sens est ici sur le Github : https://github.com/Locoduino/Railcom_detector_inClass/tree/main/src
Il s'agit d'une version où, tout d'abord, le code est organisé en fichiers séparés, un peu comme un bibliothèque. Ce qui fait que la partie de code exposé à l'utilisateur est très sommaire et plus simple à comprendre. Ce code est par ailleurs organisé sous forme de classe c++. Il est donc possible de créer plusieurs instances qui fonctionnent en parallèle. On peut relier jusqu'à trois lecteurs Railcom. Trois étant le nombre de ports série hardware sur un ESP32.
Voici le code du fichier principal :
/*
Programme de lecture, de decodage et d'affichage des messages Railcom ©
qui retourne l'adresse d'un decodeur (adresse courte ou longue) sur le port serie (250000 bauds)
Fonctionne exclusivement sur ESP32
© christophe bobille - locoduino.org
lib_deps = locoduino/RingBuffer@^1.0.3 / https://github.com/Locoduino/RingBuffer
*/
#ifndef ARDUINO_ARCH_ESP32
#error "Select an ESP32 board"
#endif
#include <Arduino.h>
#include "Railcom.h"
#define VERSION "v 1.7"
#define PROJECT "Railcom Detector ESP32"
#define AUTHOR "christophe BOBILLE Locoduino : christophe.bobille@gmail.com"
#define UNUSED_PIN 255
Railcom railcom_0(GPIO_NUM_14, (gpio_num_t) UNUSED_PIN); // Instance de la classe Railcom
Railcom railcom_1(GPIO_NUM_16, (gpio_num_t) UNUSED_PIN); // Instance de la classe Railcom
Railcom railcom_2(GPIO_NUM_13, (gpio_num_t) UNUSED_PIN); // Instance de la classe Railcom
void setup()
{
Serial.begin (250000); // <- ATTENTION
Serial.printf("\n\nProject : %s", PROJECT);
Serial.printf("\nVersion : %s", VERSION);
Serial.printf("\nAuthor : %s", AUTHOR);
Serial.printf("\nFichier : %s", __FILE__);
Serial.printf("\nCompiled : %s - %s \n\n", __DATE__, __TIME__);
}
void loop ()
{
// Affiche toutes les secondes dans le moniteur serie l'adresse de la locomotive
Serial.printf("Adresse loco 0 = %d\n", railcom_0.address());
Serial.printf("Adresse loco 1 = %d\n", railcom_1.address());
Serial.printf("Adresse loco 2 = %d\n", railcom_2.address());
delay(1000);
}
Il faut faire attention à la vitesse du port série programmée à 250Kbs. Il faut paramétrer le moniteur série de l'IDE en fonction.
Il suffit juste de régler la bonne broche pour chaque entrée de lecteur Railcom
Christophe
-
Je profite de ce fil pour savoir si quelqu'un peut m'apporter la réponse :
J'ai vu qu'il était normalement possible de détecter le sens de roulage des locomotives avec Railcom. Or je ne vois pas comment. Depuis que j'ai fait l'acquisition d’un oscilloscope, je me rattrape et je passe à la moulinette tout ce que j’aurais aimé faire avec au paravant.
J’ai donc scanné le retour du signal Railcom. J’espérais voir à l’oscillo un changement quelconque en changeant le sens de roulage ou en retournant la locomotive. Mais que nenni, l’image ne change pas !
Le signal en bleu est le DCC, celui en jaune Railcom. Je trouve étonnant que Railcom ait une polarité positive au repos (quand il n’y a pas de signal). Mais peut-être que tout ceci tient à la conception même de la carte.
Christophe
-
Il faut faire attention à la vitesse du port série programmée à 250Kbs. Il faut paramétrer le moniteur série de l'IDE en fonction.
Il suffit juste de régler la bonne broche pour chaque entrée de lecteur Railcom
Christophe
Je vais ré-essayer ça lundi (je bosse tout le WE)
Sinon, sur cette page, ils parlent en effet d'autres informations que l'on peut récuperer par le railcom (tout en précisant que ça dépend du décodeur)
Pour ma part, j'ai des lenz standard V2
https://usuaris.tinet.cat/fmco/railcom_en.html (https://usuaris.tinet.cat/fmco/railcom_en.html)
Autre petit souci, notamment par rapport à ce schema sur le site
(https://www.locoduino.org/IMG/jpg/decodeur_02.jpg)
j'ai du inverser le DCC entre l'entrée et la sortie. je ne pense pas avoir fait d'erreur de câblage mais si je branchais tel que sur le schéma, ma centrale se mettait en court circuit à l'arrivée de la loco dans la zone.
Merci de ton retour en tous cas
-
Autre petit souci, notamment par rapport à ce schema sur le site
j'ai du inverser le DCC entre l'entrée et la sortie. je ne pense pas avoir fait d'erreur de câblage mais si je branchais tel que sur le schéma, ma centrale se mettait en court circuit à l'arrivée de la loco dans la zone.
Merci de ton retour en tous cas
En DCC malgré ce que l'on pense souvent, il y a une polarité. Si tu as été obligé de modifier la polarité sur la carte Railcom, c'est qu'au niveau de tes rails, il y a une inversion de polarité et pas dans la carte Railcom. Tout tes rails intérieurs doivent être branchés sur la même polarité (couleur de câble) et tous les rails extérieurs sur l'autre polarité !!!
-
Bonjour,
Sur "Railcom out", c'est normalement un signal UART classique: 1 au repos... arrive un start bit (0), suit la data (8 bits), un stop bit (1), puis le signal reste 1 si la transmission est finie.
Le sens de la loco, on le trouvera aux sorties des deux LM339.
-
Ok, je comprends l'histoire de polarité avec l'UART 1 état repos 0 état actif. Merci
Le sens de la loco, on le trouvera aux sorties des deux LM339.
Comment peut-on récupérer cette info ? Aurait-il fallu un branchement supplémentaire ?
-
Ok, je comprends l'histoire de polarité avec l'UART 1 état repos 0 état actif. Merci
Le sens de la loco, on le trouvera aux sorties des deux LM339.
Comment peut-on récupérer cette info ? Aurait-il fallu un branchement supplémentaire ?
Sur "Railcom out", on trouve la combinaison des sorties LM339, via le 7402. Un signal adapté à un UART, peu importe le sens de la loco.
Pour le sens, il faudrait exploiter la sortie d'un LM339 au moins, ajouter quelques composants et un optocoupleur.
-
Comment peut-on récupérer cette info ? Aurait-il fallu un branchement supplémentaire ?
Il s'agirait d'un projet en soi... j'avais pensé à ce qui suit, avec un RP2040
La base de ce schéma récepteur Railcom a 20 ans. Une solution alors simple et efficace: n'importe quel AVR ou PIC entrée de gamme avec un UART pouvait recevoir du Raicom. A l'époque, les CPU n'étaient ni aussi rapides ni aussi dotées que celles d'aujourd'hui.
Sais tu si un UART software à base de RMT peut fonctionner à 250kbps? Il n'y a que quelques octets à recevoir, de temps en temps. Tu peux peut-être faire des tests avec Railcom out, ou encore avec un UART qui envoie quelques octets/s à 250k vers un UART RMT...
Ca ne dit rien d'une vitesse max (qui serait aussi fonction du nombre d'octets/s à traiter):
https://github.com/naffej/esp32-rmt-uart
Edit... je viens de voir ce lien, plus haut. Ca peut donc fonctionner avec du software serial:
https://github.com/Locoduino/Railcom_detector_inClass/tree/main/src
On a trois points qui nous intéressent sur la carte Railcom:
- la sortie de V1/3, la détection du cutout Railcom
- les sorties des deux LM339
Ca ferait 3/4 fils à raccorder:
- V1/3, pour activer deux Rx UART RMT au moment du cutout seulement
- les deux Rx UART RMT étant connectés aux sorties des LM339
- le GND de l'esp32 étant raccordé au DDC 0V
Selon le sens de la loco, le retour Railcom se fera par l'un ou l'autre des deux UART RMT.
En étant prudent avec les alims, il devrait être possible de faire de premiers essais sans optocoupleurs. Sinon, il faut isoler.
Sur ce schéma, R14/C6 doivent être utiles à éliminer du bruit. C'est plutôt à cet endroit, sur C6, qu'il faudrait raccorder les Rx RMT, en utilisant deux portes 7402: une porte et circuit R/C pour chacun des LM339, pour des signaux distincts.
Aux différents points de ce récepteur, la donnée Railcom est inversée ou non. Selon les signaux et où l'esp est connecté, il pourrait y avoir à adapter la bibliothèque UART RMT. Ou le schéma serait à modifier pour une polarité adaptée.
-
Pour que ce que tu proposes fonctionne, il faut que d'une manière ou d'une autre, les informations véhiculées par l'un ou l'autre rail soient différentes. Mais j'ai beau chercher, je ne vois nulle part quelque chose qui confirmerait cela.
Je crois qu'il faut ressortir l'oscillo, décidément un bon investissement, et regarder si le retour d'infos se fait sur un seul rail, ce dont je doute cependant !!!
Sais tu si un UART software à base de RMT peut fonctionner à 250kbps? Il n'y a que quelques octets à recevoir, de temps en temps. Tu peux peut-être faire des tests avec Railcom out, ou encore avec un UART qui envoie quelques octets/s à 250k vers un UART RMT...
Et pourquoi ne pas utiliser les UART hard ? Quoiqu'il en soit, Hard ou Soft, à 250Kbs ça ne doit pas poser de problème sur un ESP ou un RP.
C'est des tests qui peuvent en effet être facilement réalisés, il n'est pas compliqué d'envoyer 2 octets à 250 Kbs à partir d'un µc et de les lire avec un autre.
-
Si on a des UART hard libre, ça le fera aussi. Les UART soft permettant plus de possibilités, dont d'en avoir plus, et manifestement, ça suffit pour d'aussi petits débits.
Avec Railcom, les décodeurs envoient un courant DC/pulsé dans la voie; la data. La polarité du signal reçu sera fonction de l'orientation physique de la loco sur la voie.
Si c'est un signal positif, c'est un des LM339 qui le détecte. Sinon, c'est l'autre LM339. L'un a sa ref à +18mV, l'autre à -18 mV.
-
Avec Railcom, les décodeurs envoient un courant DC/pulsé dans la voie; la data. La polarité du signal reçu sera fonction de l'orientation physique de la loco sur la voie.
Si c'est un signal positif, c'est un des LM339 qui le détecte. Sinon, c'est l'autre LM339. L'un a sa ref à +18mV, l'autre à -18 mV.
Ok, effectivement c'est OK alors. Au même moment, je viens de trouver quelque choses d'assez détaillé qui traite de cela, je regarde et je te redis.
-
Pour moi, c'est du DC pulsé, la data. Et la polarité est fonction de l'orientation de la loco sur la voie.
Donc, c'est l'un ou l'autre des LM339 qui détecte le signal, selon qu'il soit positif ou négatif.