Messages récents1
Vos projets / Re : PASSERELLE CAN vers protocoles types: S88N, XPRESSNET, RS LENZ, LOCONET,...,WIFI
« Dernier message par laurentr le février 14, 2019, 03:06:22 pm »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
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