PASSERELLE CAN vers protocoles types: S88N, XPRESSNET, RS LENZ, LOCONET,...,WIFI

[laurentr]

Bonjour

Les récents articles de présentation de la carte satellite V1 et de la mise en oeuvre du BUS CAN ont bien mis en avant la qualité et la simplicité de la réalisation. ( quelques composants, des bibliothèques, ...)

A ce jour tout ce qui est en cours ( de développement ou de mise en oeuvre) repose sur le transfert par bus CAN des informations collectées ou a transmettre.

Cette démarche fonctionne si la cible est aussi de disposer d un environnement d exécution/traitement/affichage compatible.

La démarche d utiliser le CAN pour le transport des info du S88N a montré le gain de l'usage du CAN et l ouverture vers "l'EXTERIEUR" des standards du marché ( ici le S88n)

Sur le même principe je pense qu il pourrait être intéressant de réaliser des PASSERELLES CAN vers des protocoles "STANDARDS" comme LOCONET, XPRESSNET, RS BUS...

L intérêt est ainsi de combiner les avantages du CAN et de pouvoir interfacer les réalisations qui l'utilisent avec des équipements voir des logiciels ayant déjà pignon sur rue:
ex cote hardware:
la DR5000 de DIJIKEJS propose en sortie les interfaces suivantes:
S88n
XPRESSNET
RS LENZ
LOCONET

l ECOS2
S88n
LOCONET via Adaptateur
CAN ESU (mal et peu documenté!)

ex coté software:
RRTC sait gérer les centrales/interfaces exploitant LOCONET, XPRESSNET, S88, RS...
CDM RAIL pour sa part XPRESSNET, RS et S88n

Les bibliothèques existent. ( XPRESSNET, LOCONET, S88, CAN,...)

Je me pose donc la question de savoir si cette( ces) PASSERELLE(s) CAN vers XXX est quelque chose de réalisable et si on peut la (les) mettre en oeuvre

( l idée qui est derrière est de pouvoir utiliser des cartes SATELLITE ou la future carte de DÉTECTION d OCCUPATION avec IDENTIFICATION RAILCOM vers des interfaces de sortie dites "standards" avec des produits du commerce. (hard et soft)

En quelques mots simples: faire coexister le meilleur des deux mondes.

Ex d’implémentation:

On prends sur le signal DCC les trames à destination des ACCESSOIRES DCC, ainsi la voie reçoit le signal DCC FULL mais sera dévolue au pilotage des engins exclusivement) ( on pourrait aussi filtrer pour que la voie ne reçoive les informations qu à destination des décodeurs de matériel ( décodeurs classiques et décodeurs de fonctions))
Les trames DCC des Accessoires sont converties pour passer sur le BUS CAN, en sortie on passe du CAN en DCC ACC pour piloter des équipements au format DCC.

On passe du CAN vers le S88n ( comme décrit avec la fonction GATEWAY S88 del article su site) ( ici bus unidirectionnel pour remonter des info d'occupation)

On passe du CAN vers le RS LENZ ( ici bus uni directionnel pour remonter les info d'occupation)

On passe du CAN vers le LOCONET ici bus Bidirectionnel mais dont ont peut commencer par implémenter le sens de remontée des information comme pour le S88n et le RS Lenz.

...

Etc

In fine et pour résumer on aurait ainsi sous le réseau:
1 BUS puissance ( alim des cartes et accessoires)
1 BUS DCC pour la traction
1 BUS CAN universel qui transporte toutes les info de tous les interfaces avec leurs protocoles respectifs)
(en option un bus DCC ACC et un bus DCC TRACTION séparés.)

Le débat est lancé...

Laurent

[laurentr]

Bonjour

Commençons par documenter un peu le sujet:
CAN <==>S88
Il s agit exclusivement de faire descendre l'info S88 sur le bus CAN avant de repasser celle ci du bus CAN vers une sortie en S88/S88n pour utilisation par des interfaces ( centrales) et logiciel supportant ce standard.

Pour la partie CAN vers S88 le sujet a déjà été abordé ici même:
https://www.locoduino.org/spip.php?article180

Hormis un hardware spécifique ( dont je peux me pencher sur la réalisation) il faudrait peut être une IHM pour programmer cela de manière plus "user friendly" ( ou une mega doc pour savoir tut ce qu il faut  ajouter/modiifer comme valeurs avant injection dans le nano ( ou 328P )
A défaut il suffira d aller poser les bonnes valeurs aux bon endroits dans le croquis avant injection. mais sans trame directrice ce n est pas encore à la portée du plus grand nombre.

Il conviendra de définir avec rigueur une plage réservée à l usage de la RETROSIGNALISATION et particulierement à la version S88 ici meme.

Passons à présent à la partie suivnate:
RS LENZ <==>:
A ma connaissance il n y a pas de bibliothèque dédiée.

En tout état de cause voici ce que j ai trouve sur ce protocol:

LENZ RS bus Specifications :

How does the RS-Bus work?
 
Pretty simple actually. LZ100 or something simular acts as a master and sends 130 pulses, around 109 us high and around 93 us low, with an interval of 7 seconds. The feedback moduls counts these pulses. When the number of pulses is equal to the address in the feedback module, the module sends one byte of data, and one byte only. Only the status of 4 ports can be sent in one byte, so if the modules need to send status for all the ports on one address, it will send two bytes. But the second byte will be sent the next time the master is sending out pulses
From an electronic point of view, this bus have a couple of advantages compared to other buses. The transfer is made thru current levels, and not voltage leves as in example S88. The data is also protected by a parity bit, and the bus wont be over flooded with data with alot of modules on it.
 
Protocol
The data is transered with the speed of 4800bits / s. It contains 8 bits of feedback data.
•   Startbit (0)
•   Parity (even)
•   2 TT bits (always 10 with a standard module)
•   Nibblebit (0 = input port 1-4, 1 = input port 5-8)
•   4 databits D3, D2, D1, D0
D0-D3 represent input 1 to 4, or 5 to 8 depending on the nibblebit. This is the reason why we need to send two bytes to return status for all 8 ports
The TT bit identify the type of feedback module.
00 – turnout decoder without feedback
01 – turnout decoder with feedback
10 – standard feedback (this is what we use)
11 – reserved for future use
It’s unknown why Lenz created this encoding. For standard feedback modules, we always send 10 in the TT bits.
These 8 bits are sent, the other way around compared to standard UARTS, with the P bit first, and the D0 last
P 1 (t), 0 (T), Nibble, D3, D2, D1, D0
 
Message example
The message is coded in the following way
S, P, T1, T0, N, D3, D2, D1, D0
S – Start bit (Low)
P – Parity(Even)
T1 – always 1 for feedback moduls
T0 – always 0 for feedback moduls
N – Nibble (0 for input 1-4, 1 for input 5-8)
D3 – Input 4 or 8
D2 – Input 3 or 7
D1 – Input 2 or 6
D0 – Input 1 or 5
Example:
No.   S   P   T1   T0   N   D3   D2   D1   D0   Description
1   0   0   1   0   0   0   0   0   0   Input 1, 2, 3 & 4 low
2   0   1   1   0   0   0   0   0   1   1 high, 2, 3 & 4 low
3   0   1   1   0   0   0   0   1   0   2 high, 1, 3 & 4 low
4   0   0   1   0   0   0   1   0   1   1 & 3 high, 2 & 4 low
5   0   0   1   0   1   0   0   0   1   5 high, 6, 7 & 8 low
6   0   0   1   0   1   1   0   0   0   8 high, 5, , & 7 low
7   0   1   1   0   1   0   0   0   0   input 5, 6, 7 & 8 low
8.1   0   1   1   0   0   0   0   0   1   2 messages: 1 and…
8.2   0   0   1   0   0   0   0   1   0   … 6 high, resten low
References
For additional information, and also the page where I learned about the RS-bus, I can recommend Der-Moba’s webpage.

Source:
http://www.der-moba.de/index.php/RS-R%C3%BCckmeldebus


Ici donc, comme pour le S88 on doit pouvoir convertir une entrée de signal RS provenant d un detecteur vers le BUS CAN, puis realiser l operation inverse: sortir du BUS CAN les info a passer au bus RS

Je présume que des mécanismes analogue a ceux du S88 pourront être adoptés.

Question qui de plus doué/qualifié que moi peut s y pencher?
La encore une fois cette partie traitée je veux bien m'occuper de la partie design de l'interface physique pour mettre la solution en oeuvre.

Pour ceux qui n auraient pas mesurer l apport de ces passerelles elles permettront par exemple de pouvoir utiliser les cartes SATELLITE V2 avec les équipements et logiciels "usuels" du monde DCC.

Pour la partie DCC en Split DCC accessoires vs DCC conduite des engins nous verrons cela dans un autre temps.
Idem pour la partie LOCONET qui est elle BIDIRECTIONNELLE.

Laurent