Тема: Всё о RailCom
Показать сообщение отдельно
Старый 27.12.2017, 16:06   #35
Rokfor
Engineer of DCC
 
Регистрация: 18.09.2009
Адрес: Москва
Сообщений: 2,034
Сказал(а) 'не согласен(а)'!: 23
Сказали 'не согласен'! 25 раз(а) в 17 сообщениях
Сказал(а) спасибо: 140
Поблагодарили 2,269 раз(а) в 894 сообщениях
Репутация: репутация неоспорима (2289)
По умолчанию

Разбирательство с рэилкомом выявило следующие моменты:

Как оказалось из за нечеткости прописанного на сайте NMRA документа возникают некоторые сложности с работой Railcom.
Railcom устроен так, что информация передаваемая декодером зависит от того какой DCC пакет был передан станцией перед данным cutout’ом.
В старой редакции 2005г (RP-9.3.2 V2.06) говориться, что свой адрес (broadcast transmission) декодер не может передавать в cutout’е идущем за DCC пакетом на свой адрес, т.е. он должен передавать свой адрес в 1-м канале в cutout’е после пакетов другим лок декодерам. Передавать свою скорость декодер может только во 2-м канале в cutout’е, идущем после команды на свой адрес, (это положение не поменялось в следующей редакции протокола).

В новой редакции S-9.3.2 (July 2012) (это текущая редакция, выложенная на сайте NMRA, были и более поздние, но похоже от них отказались, документация по ним удалена) правило передачи пакетов описано по другому – декодер должен передавать свой адрес в 1-м канале в cutout’е после DCC пакета на любой адрес.
Странное решение, оно неизбежно будет приводить к конфликту, если на участке 2 или более лок декодеров. А глобальный детектор вообще будет видеть кашу от всех лок декодеров на макете.

Я проверил как работают разные декодеры, я взял старый lenz gold, старый звуковой декодер ZIMO MX640, esu lokpilot (версий не знаю, но они старые), - они работают в соответствии со старой редакцией протокола.
Так же работают и все лок декодеры modelldepo (в которых есть railcom).

Более новые декодеры - звуковой ZIMO MX648, esu loksound V4.0 работают по новой редакции, т.е. передают свой адрес в каждом cutout’е после любой локомотивной команды. Из этого следует, что при желании проверить что передает декодер – декодер должен быть единственным, подключенным к детектору раилкома, если будет второй, то они сделают кашу.

Первая редакция протокола позволяет избежать конфликта, когда 2 локомотива оказались на одном участке. Каждый передает свой адрес после чужого пакета – конфликта нет.
Но есть и одна проблема – если включить станцию и выбрать только один локомотив с таким же адресом как и декодер (на экосе удалить второй контролер или сделать их с одним адресом), то станция будет посылать команды только на этот адрес, а значит в DCC потоке никогда не будет пакетов на другой адрес и декодер никогда не сможет передать по раилкому свой адрес, вероятно поэтому детектор не всегда видит адрес в раилкоме.
Тоже самое и со скоростью, если выбрать другой адрес (не адрес декодера) и этот другой адрес будет являться единственным в потоке DCC команд, то декодер сможет передавать детектору только свой адрес и никогда не сможет передать свою скорость.
Если кто то надумает тестировать раилком – не надо об этом забывать, в этом протоколе есть много тонкостей и нелогичных вещей.

Еще, у экоса есть одна особенность: если выставить на контроллере скорость=0, то через некоторое время он перестает посылать команды на этот адрес, занятный момент, можно долго искать передачу адреса от одних декодеров и передачу скорости от других. (Возможно у меня старый экос и это уже изменили).

Да, еще, ранее я писал, что декодеры esu передают по раилкому текущую скорость, это не соответствует действительности, похоже это был другой декодер.
Проверил еще раз те esu-ные декодеры, что у меня есть – ни один не передает. Только свой адрес. Странно, но факт.
Rokfor вне форума   Вверх
Пользователь сказал 'не согласен'! - за это бесполезное сообщение:
Saddam (27.12.2017)
7 пользователя(ей) сказали cпасибо: