Zpětný ohlas Roco (R-Bus/10787)

Úvod

V rámci zkoumání zpětného ohlasu u různých výrobců jsem se dostal i na Roco^®. Zejména s nástupem centrály Z21 o tuto zpětnou vazbu stoupá zájem. Centrála Z21 jí označuje jako R-Bus.
Povedlo se mi zapůjčit si modul Roco 10785 (někdy se také označuje jako Rocomotion podle software k němu dodávaného; také budu toto označení používat) a modul zpětného ohlasu Roco 10787.

Feedback interface Roco (R-Bus/10787)

Introduction

As a part of my various vendors feedback bus research i also take a look for Roco^®. The interest of this feedback increase especially with usage of new Z21 command station. Z21 marking this feedback bus as R-Bus.
I was borrow one module Roco 10785 (sometime called as Rocomotion based on software included with; I will also use this name in this text) and one feedback module Roco 10787.

Předpoklady

Trochu jsem předpokládal, že moduly komunikují s použitím RocoNet, což je derivát XpressNetu. Součástky v modulu tomu odpovídají, takže jsem rovnou připojil modul pro odposlech XpressNetu a začal sledovat co po sběrnici prochází. Bohužel jsem z toho nebyl příliš moudrý. Datagramy které probíhají jsou sice v souladu se zvyklostmi XpressNet, ale nedařilo se mi zjistit, kudy se v nich berou data.
Procházející pakety mají tvar:

DD
DE F4 00 00 02 00 09
5F

Předpokládal jsem, že červená jsou data která generuje centrála (v mém případě Roco multiMAUS) a modrá data generuje Rocomotion na základě informací které nějak dostane od modulů 10787.
Vše docela slušně vychází - XpressNet adresa je 30, to celkem odpovídá, protože PC rozhraní má fixní adresu 29, takže fixní adresa pro zpětné hlášení 30 je celkem logická. Nicméně nedařilo se mi přijít na to, jak se dostanou data od každého z modulů do Rocomotion. Nejprve jsem hledal postranní kanály, ale žádné se mi nedařilo najít. Takže jsem si nakonec připojil logický analyzátor přímo na vývody obvodu SN75LBC176D (vytváří sběrnici RS485, ekvivalent MAX485) a začal sledovat, co se kdy odesílá. Komunikace je s použitím analyzátoru ukázala mnohem zřetelnější.

Stále tedy platí, že se jedná o sběrnici, která odpovídá XpressNet. Tedy 62 500 bits per second, 1 start bit, 9 datových bitů, 1 stop bit, bez paritního bitu.
Devátý bit je použit jen pro označení volacího znaku, proto v popisech můžeme zůstat u osmibitového popisu.

Celá komunikace se dá nejsnáze pochopit s použitím tomto obrázku:

Assumptions

I little assumed, that modules using for communication RocoNet. Roconet is dialect of XpressNet bus. Electronic parts inside module also confirm my assumption. Then I directly connect my XpressNet sniffer and tried to understand communication. But I was not that successful as I expect. The datagrams I saw are in alignment with XpressNet traditional structure, but I can not find where presented data coming from.
The datagrams have following structure:

DD
DE F4 00 00 02 00 09
5F

I was expect, that red data going from command station (mutliMAUS in my case) and blue data are generated by Rocomotion based on information that somehow receive from modules 10787.
All look like good - XpressNet address is 30. It look like logical, because PC interface have fixed address 29, then use next fixed address for feedback look like good. Then address 30 for feedback is fine. But I can not find where data coming from separate modules to Rocomotion. First of all I was searched for side channels, but I can not find any. Then I was connected logical analyser directly to pins of SN75LBC176D (chip that creating RS485 bus, equivalent of MAX485). And then I start watching who sending data in what time. The communication with usage of logical analyser was look much more clear.

It is still valid, that it is dialect of XpressNet. Then 62 500 bits per second, 1 start bit, 9 data bit, 1 stop bit, no parity bit.
Ninth bit is used only for marking call byte, then in description can be used only eight bit values.

I guess all communication is best described on following picture:

Na obrázku je zachycen celý jeden datagram.
Datagram je pro případ, kdy počítač očekával 3 moduly obsazení (adresa 1,2,3), ale přítomen byl jen jeden (adresa 2) a byl na něm aktivován vstup 2.
Začíná žlutou čárou M1, tedy volacím znakem, ten je konstantní 0xDE (+bit9, takže 0x1DE) a vysílá jej centrála (MultiMAUS). Tedy normální přidělení komunikačního času pro ovladač nebo další XpressNet zařízení (podle specifikace XpressNet).
Normálně by následovala komunikace od zařízení s příslušnou adresou směrem k centrále. To ale pro tento konkrétní případ neplatí úplně přesně. Zde nastupují specifika RocoNet oproti XpressNet., tady komunikaci přebírá Rocomotion a odpovídá znakem 0xF4. To je relativně v pořádku. Podle XpressNet se jedná o Hlavičkový bajt. První polovina (F) není ve specifikaci XpressNet, ale Roco jej používá pro svá rozšíření. Druhá polovina (4) určuje počet efektivních znaků. Tedy vlastně korektní XpressNet hlavičkový bajt, za kterým budou následovat 4 další bajty. Rozdíl je pouze v tom, že není určen pro centrálu, ale pro samotné Rocomotion.

Další bajt, který je podle XpressNet označen jako Datový bajt 1 (DB1), také generuje Rocomotion. Jeho hodnota je v našem případě 0x00. Pro jeho pochopení jsem již potřeboval sáhnout po veřejné části specifikace RocoNet (respektive popis komunikace Rocomotion 10785) roconet-v1.6.1.pdf. Zde je definovaný Info-Bajt pro jednu skupinu modulů.

Info-Bajt (Info_R)								Význam
7	6	5	4	3	2	1	0	Význam
0	0	0	G	0	0	0	0	Normální ohlas
1	0	0	G	0	0	0	0	Dotaz na verzi software
1	1	0	G	A	A	A	A	Nastavení adresy modulu na AAAA

kde G označuje skupinu modulů (0 nebo 1). V každé skupině může existovat maximálně 10 modulů, takže adresa AAAA v rozsahu 1-10.

Před dalším znakem si všimněte delší mezery, za kterou následuje znak 0x00. Ta delší mezera je proto, že modul s adresou 1 není přítomen, takže Rocomotion čeká, jestli se modul ozve a on se neozval, takže po uplynutí určitého času za něj odeslala znak 0x00 - tedy žádné obsazení.

A teď to začíná být zajímavé - modul na který sledujeme má adresu 2. Je možné si všimnout, že se připojil ke sběrnici pro zápis (červená čára s písmenem T) a odeslal znak 0x02. To je proto, že jeho vstup 2 je obsazen. Stalo se to rychle, protože ten modul prostě čekal na své datové okno a okamžitě jej využil.

Další modul zase nebyl přítomen, takže timeout a následuje 0x00 od Rocomotion.

A na konci zase znak od Rocomotion 0x09 - zase rychle, protože není na co čekat. To je kontrolní součet (xor znaků od F4 až do kontrolního znaku je FF). Na kontrolním součtu je možné si opět všimnout odchylky. Normální XpressNet má kontrolní součet postavený na hodnotu 0x00, zatímco ohlas dává hodnotu 0xFF. Netuším co k tomu vývojáře vedlo, asi snaha o odlišení paketů na které centrála nemá reagovat.

Takže pokud se znovu podíváme na komunikaci jako na sériovou linku, tak jsme dostali zprávu:

Picture represent all one datagram.
Datagram represent case, when computer expect 3 feedback modules (addresses 1,2,3), but connected is only one (address 2) with activated input 2.
It starting with yellow line marked M1. It is call byte. Call byte is constant - always 0xDE (+bit9, then 0x1DE) and it is sent by command station (MultiMAUS). Then it is standard allocation for communication time for throttle or other XpressNet device (according XpressNet specification).
In standard situation it will follow by standard communication from device with proper address to command station. It is not that valid for this case. Here RocoNet specific dialect is used instead of XpressNet. Here communication is overtaken by Rocomotion. It response with character 0xF4. It is relatively OK. By XpressNet specification it mean header byte. First nibble (F) is not in XpressNet specification, but Roco uses it for its extensions. Second nibble (4) mean effective number of characters. Then it look like standard XpressNet packet. The difference si, it is not for command station, but for Rocomotion itself.

Next character, in XpressNet naming is called Data byte 1 (DB1), also coming from Rocomotion. Its value is in our case 0x00. For understanding of this character I was need take a look into public part RocoNet specification (Better is to say description of Rocomotion 10765 communication) roconet-v1.6.1.pdf. Here is defined Info-Byte for one group of modules.

Info-Byte (Info_R)								Meaning
7	6	5	4	3	2	1	0	Meaning
0	0	0	G	0	0	0	0	Normal feedback
1	0	0	G	0	0	0	0	Software version request
1	1	0	G	A	A	A	A	Configure module address to AAAA

where G is mean group of modules (0 or 1). In every group can be maximum 10 modules, then address AAAA can be in range 1-10.

Take a look for longer time before next character. The character is 0x00. Longer time before character is because module with address 1 does not exist on bus. Then Rocomotion wait until timeout for module. After this timeout Rocomotion send character 0x00 - it mean no occupancy.

And now is turn on module with address 2. You can see, that module take bus for write (red line with marking T) and sent character 0x02. It is because its input 2 is occupied. It was happen quick, because module await his data window and use it immediately.

Next module again was not presented, then after timeout Rocomotion sent 0x00

Last character 0x09 is again from Rocomotion. Again fast, because we have nothing to wait for. This character is checksum in XpressNet notation (xor of characters starting by F4 to last character should be FF). The checksum is again different between XpressNet and RocoNet. Normal XpressNet packets have checksum 0x00, but feedback packets have vallue 0xFF. I§m not sure why it is, I guess, that it is because they would like differentiate packets not dedicated for command station.

Then when we will look again to communication as a serial line, we will get following packet:

0xDD 0xF4 0x00 t0x00 0x02 t0x00 0x09

Červená označuje data od centrály
Modrá označuje data od Rocomotion, malé "t" označuje data odeslaná po timeout
Zelená jsou data od detektoru číslo 2, který byl na sběrnici

Jak již zaznělo - moduly mají adresy 1-10 a to ve dvou skupinách (0 a 1). Při inicializaci počítač posílá příkaz označený jako frekvence čtení. To znamená, kolik volacích znaků Rocomotion vynechá, než vloží hlavičkový bajt. Pochopitelně pokud počítač požaduje informace z obou skupin, pak se pochopitelně střídají datové bajty pro skupinu 0 (0x00 v prvním Datovém Bajtu) a skupinu 1 (0x10 v prvním datovém bajtu).

Poznámky

Všiml jsem si několik drobných nepřesností, na které bych zde chtěl upozornit. Pravděpodobně nemají vliv na funkci modulu, zejména v případě, kdy se někdo rozhodne pro stavbu vlastního. Ale asi se hodí je zde popsat.
První nesrovnalost, které jsem si všiml je, že moduly nesledují obsah hlavičkového bajtu. To v praxi znamená, že pokud máme například na sběrnici modul s adresou 4 a počítač má nakonfigurované pouze 3 moduly, pak tento modul klidně převezme sběrnici a odešle data v době, kdy Rocomotion odesílá XOR kontrolní součet. Ještě horší situace je, pokud existuje modul s adresou 5; ten svá data odešle dokonce až za tímto kontrolním součtem. Modul 6 se již neuplatní, protože moduly sledují přítomnost bitu 9 a následující běžící znak je volací znak pro další XpressNet zařízení.
Druhá podobná nesrovnalost vznikne, při změně adresy modulu. V takovém případě Rocomotion odešle nesprávně hlavičkový bajt stejný jako při běžné komunikaci, tedy 0xF4 v našem případě, pak odešle Info-Bajt 0xC? (? je nová adresa), ale nespustí se funkcionalita na doplňování nepřítomných modulů, nicméně zůstane zaplá funkcionalita pro doplnění XOR součtu, takže se nečekaně tento součet vepíše za třetí následující volací znak. (nebo jakýkoli další třetí znak).
Pokud počítač pošle dotaz na verzi (hodnota 0x80 nebo 0x90 v Info-Byte), moduly začnou odpovídat svojí verzí (v mém případě 0x7A), nicméně Rocomotion tuto informaci nepošle do počítače. Zároveň neprobíhá doplňování neexistujících modulů, takže pokud nejsou v řadě, pak informace o verzi neodešlou.

Závěr

Komunikace je v celku jednoduchá a snadno napodobitelná, takže jí bude velice jednoduché naprogramovat. To se bude hodit zejména majitelům centrály Z21, která vyžaduje právě tento typ zpětného ohlasu do konektoru R-Bus.
Mimochodem - z popisu je zřejmé, že komunikace se dramaticky zpomaluje, pokud jsou některé adresy modulů vynechané, takže je velmi doporučeno všechny adresy obsazovat a opravdu začínat adresou 1. Pochopitelně také maximálně využívat kapacitu modulů s nízkou adresou.

Red mean data from command station
Blue mean data from Rocomotion; "t" marking data after timeout
Green are data from module 2 presented on bus

It was already stated, that modules have addresses 1-10 in two groups (0 and 1). During initialization computer sending command named reading frequency. It mean, how many call bytes Rocomotion skip, before will insert header byte. Of course once computer request information from both groups, then group data bytes are of course switched between group 0 (0x00 in first Data byte) and group 1 (0x10 in first Data byte)

Notes

I was recognized few little inaccuracies I would like to remark here. They have probably no effect to module function, especially when somebody will decide to create its own module. But it will be good to info about them.
First inaccuracy I found is, that modules does not read value in header byte. In practice it mean, if we have on bus for example module with address 4 and computer have configured only 3 modules, then module with address 4 will take bus and send his data in time, when Rocomotion sending XOR checksum. Maybe worst situation is, once we have module with address 5; this module will send his data after XOR checksum byte. Module 6 will have no effect, because modules looking for ninth bit on bus and next byte is call byte for next XpressNet device.
Second similar inaccuracy will happen during address change packet. In this case Rocomotion will send incorrect header byte same as used for standard read, then 0xF4 in our example, then will send Info-Byte 0xC? (? is new address), but it will not start functionality for timeouts for non responding modules, but functionality for calculating XOR checksum will remain active. Then unexpected this checksum will be send after third following call byte. (or after any else third character).
Once computer will ask for version (value 0x80 or 0x90 in Info Byte), then modules will start responding its version (0x7A in my case). But Rocomotion will not transfer this information to computer. During this time also not filling zeroes for non existing modules, then if we have not modules in alignment, Rocomotion will not receive this information.

Conclusion

Communication seems like easy and simple to replicate. Then it will be simple to program it. It will be useful especially for owners of Z21 command station, which request those modules as only one possible feedback in R-Bus socket.
By the way - it is visible, that communication is dramatic slower, when we have not used some addresses. Then it is strongly recommended to use all addresses and always start with address 1. And of course maximum use capacity of modules with lower addresses.