Форум ModelldepO

Форум ModelldepO (http://forum.modelldepo.ru/index.php)
-   Rocrail (http://forum.modelldepo.ru/forumdisplay.php?f=211)
-   -   Rocrail и сообщения RailCom, о качестве сигнала DCC на рельсах(QoS) (http://forum.modelldepo.ru/showthread.php?t=19188)

kej 25.12.2017 19:00

Rocrail и сообщения RailCom, о качестве сигнала DCC на рельсах(QoS)
 
Перенесено из соседней темы:
Цитата:

Сообщение от laba (Сообщение 315358)
никто не может здесь упрекнуть, что я что-то скрывал

Я не ставлю это под сомнение. Интерес мой связан с тем, что я бы хотел увидеть как на Вашем железе отображаются сообщения в части QoS. Роб на своем форуме ответил мне, что "Статистика" работает только с Вашим "железом". Я предполагаю, что если бы сообщения QoS отображались бы так же как и с z21, то с Робом можно было бы и ступить в полемику.

laba 25.12.2017 19:13

Цитата:

Сообщение от kej (Сообщение 315360)
как на Вашем железе отображаются сообщения в части QoS

Так нету у меня декодеров, которые такие сообщения умеют слать. Соответственно и от железа вряд ли что будет приходить в Rocrail.
К тому для получения представления о состоянии пути, нужен определённый объём траффика на макете, а у меня это пока нереализуемо, в силу не готовности макета. Новое железо ещё и не смонтировано вовсе, только недавно закончил собирать все, необходимые мне модули, делаю подготовительную работу по разводке проводов и подключениям к блок-участкам.
По-поводу Роба.
Многие фичи он добавляет только на основе описанных протоколов, не имея реального железа под рукой. Это и понятно, ведь нельзя же держать в доме такое огромное количество различных устройств разных производителей.
Поэтому баги или не совсем правильная работа неизбежны, но как правило многое устраняется достаточно оперативно.

kej 25.12.2017 19:45

Цитата:

Сообщение от laba (Сообщение 315361)
Так нету у меня декодеров, которые такие сообщения умеют слать. Соответственно и от железа вряд ли что будет приходить в Rocrail.

Скажу по проще. Мои декодеры то же не передают QoS, но сообщения станция передает (QoS=0) и в Rocrail в сообщениях контроллера это отображается. Биди работает с теми же декодерами RailCom, локомотивных декодеров БиДи нет. Если бы вид сообщений контроллера в части QoS (по форме а не по содержанию) от Вашего железа в интерфейсе Rocrail был бы такой же как и от z21, то с Робом о чем то уже можно было бы пытаться говорить на тему того, что много энтузиастов БиДи, но среди приверженцев Rocrail не меньше моделистов владеющих другим "железом", в том числе и z21, и было бы совсем неплохо если бы такая очень даже полезная функция "Статистика" работала бы и на том же z21+ОС с RailCom.

laba 25.12.2017 20:44

Цитата:

Сообщение от kej (Сообщение 315364)
в Rocrail в сообщениях контроллера это отображается.

У себя вроде не видел такого рода сообщений.
Цитата:

Сообщение от kej (Сообщение 315360)
Роб на своем форуме ответил мне, что "Статистика" работает только с Вашим "железом"

Я не знаю, что он имел ввиду, потому, что в описании возможностей КС BiDiB, ничего не написано про QoS.

kej 25.12.2017 20:58

Цитата:

Сообщение от laba (Сообщение 315374)
описании возможностей КС BiDiB, ничего не написано про QoS.

http://wiki.rocrail.net/doku.php?id=sensor-statistic-en
http://forum.modelldepo.ru/showpost....&postcount=110

Как я понимаю, работа "Статистики" связанна с обработкой и систематизацией сообщений QoS.

laba 25.12.2017 21:53

А, всё вспомнил. Мысль такая возникла.......
Может это всё обрабатывается внутри программы и сразу отправляется в Статистику, а не выводится в окно Контроллера, раз сделана поддержка только для железа BiDiB.
Ведь тут никакой реакции и настройки от пользователя не нужно, поэтому зачем забивать экран лишней информацией.

Роб собственно Вам и написал, что то, что выводится у Вас, есть ни что иное, как просто информация для размышления и это никоим образом не обрабатывается дальше программой. Откуда это у Вас появляется, это вопрос уже другой и его надо рассматривать на уровне протокола обмена данными, мне так думается.

kej 26.12.2017 09:59

Цитата:

Сообщение от laba (Сообщение 315378)
Может это всё обрабатывается внутри программы и сразу отправляется в Статистику, а не выводится в окно Контроллера, раз сделана поддержка только для железа BiDiB.
Ведь тут никакой реакции и настройки от пользователя не нужно, поэтому зачем забивать экран лишней информацией.

Думаю, что тут все-таки напрашивается сравнение с отображением фактической скорости, и та и другая (QoS) информация - RailCom протоколы передачи и следовательно обаботки в самой программе думаю одни и те же. Мне кажется если Роб переступит через свои религиозные убеждения (имею ввиду БиДиБ):-), то вполне возможно и реализовать функцию "Статистика" и для КС z21 c OC RailCom.
Алексей, все-таки если будет возможность и желание выложите скрин с информацией контороллера в части RailCom (QoS). Думаю 2 звена и небольшие настройки Rocrail будет достаточно.:-)

Пришла такая мысль. Функция "Статистика" находится в свойствах "Датчики". Каждый отдельно взятый датчик привязан как правило к конкретному блоку. Для работы этой функции программа должна знать какой конкретный лок находится на данном блоке (что бы потом указать его в сводной таблице) При работе Rocrail в автоматическом режиме для этого позиционирования не нужны локальные датчики ОС с RailCom. Программа сама расчитает местоположение каждого лока, а для приема данных RailCom (QoS) достаточно будет и глобального детектора RailCom самой z21. А вот при ручном управлении макетом посредством Rocrail отсутствие ОС с RailCom - уже критично. В пояснениях разработчиков по "Статистике" вроде как нет, при каком режиме Rocrail работает эта функция. Возможно кто то поделится своими соображениями по этому поводу.

Rokfor 26.12.2017 11:14

Цитата:

Сообщение от Zitra (Сообщение 315415)
Хотелось бы, по возможности, узнать как это организованно

У меня есть свой тестер-читалка раилкома, которая показывает всю передачу от декодера и DCC пакет в ответ на который декодер передает свою посылку. Вот там я и рассматривал esu и zimo.

А где это показывает экос - я не нашел, похоже, что он никак принятый раилком не показывает юзеру.
Я, по крайней мере, не нашел.

---------- Сообщение добавлено в 11:14 ---------- Предыдущие сообщение было в 11:01 ----------

Я вот подумал насчет QoS.
Эта функция совершенно не нужна в декодере, ее можно легко реализовать средствами станции, а именно глобального детектора.

Каждый декодер в cutout'е после команды на свой адрес передает свою скорость и температуру.
Глобальный детектор может элементарно собрать статистику этих ответов:
- есть ответ декодера = декодер нормально считал DCC пакет
- нет ответа = декодер не смог прочитать пакет = контакт пропал.

Совершенно не обязательно грузить этой фигней MCU декодера.

kej 26.12.2017 11:41

Цитата:

Сообщение от Rokfor (Сообщение 315420)
Я вот подумал насчет QoS.
Эта функция совершенно не нужна в декодере

Всю эту стастику где то надо собрать и скомпоновать, отобразить в форме той же таблицы - только в управляющей программе. Свои мысли я изложил разработчикам Rocrail, посмотрю, что ответят.
Цитата:

Сообщение от Rokfor (Сообщение 315420)
Совершенно не обязательно грузить этой фигней MCU декодера

Попробуйте все-таки сделать даже эксперементальную прошивку(конечно, если это позволят аппаратные возможности LGR1120) с QoS, думаю это очень хороший задел на будущее.

Rokfor 26.12.2017 12:14

Цитата:

Сообщение от kej (Сообщение 315423)
Всю эту стастику где то надо собрать и скомпоновать

Вы не поняли, она (статистика) все равно должна попасть в комп, чтобы юзер ее увидел, вопрос только в том кто будет собирать эту статистику - MCU декодера или MCU читалки раилкома.

Я думаю, что перекладывать эту функцию на декодер - ошибка, он все равно должен будет передавать это читалке раилкома, к тому же декодеру и так есть чем заняться, проще и дешевле это делать в самой читалке.

---------- Сообщение добавлено в 12:14 ---------- Предыдущие сообщение было в 11:51 ----------

Кстати, когда я делал раилком, для отладки я использовал свою читалку и чтобы оценить качество и своевременность передачи байтов декодером, я сделал простой подсчет кол-ва принятых от декодера пакетов и кол-ва ожидаемых пакетов, совсем не трудно разделить одно на другое и получить соотношение потерянных пакетов.
Это элементарная задача, не понимаю, почему так не сделали те, кто описывал механизм QoS в стандарте.

kej 26.12.2017 12:14

Цитата:

Сообщение от Rokfor (Сообщение 315425)
декодеру и так есть чем заняться

Звуковому возможно да, но для того же 1120 думаю было бы вполне комфортно еще и QoS данные.

Rokfor 26.12.2017 13:27

коллеги, а где вы нашли описание механизма QoS ?

На сайте NMRA вывешен S-9.3.2
там нет ни слова про QoS

laba 26.12.2017 14:01

Цитата:

Сообщение от kej (Сообщение 315417)
умаю, что тут все-таки напрашивается сравнение с отображением фактической скорости, и та и другая (QoS) информация - RailCom протоколы передачи и следовательно обаботки в самой программе думаю одни и те же.

Я имею ввиду протоколы обмена между КС и Rocrail, а они у Z21 и BiDiB разные. Соответственно и обработка этих сообщений в программе будет разная.
Цитата:

Сообщение от kej (Сообщение 315417)
Мне кажется если Роб переступит через свои религиозные убеждения (имею ввиду БиДиБ), то вполне возможно и реализовать функцию "Статистика" и для КС z21 c OC RailCom.

Дело не в религиозных убеждениях. Вы упорно не хотите понять, что я писал выше. BiDiB у Роба точно есть, насколько я знаю. Ну если нет у Роба под рукой нужного железа для Z21, что он должен его обязательно купить, только из-за того, что так надо какому-то товарищу из Белоруссии?
Возможно в будущем, что-то и будет сделано в этом направлении, но всёму своё время.

Цитата:

Сообщение от kej (Сообщение 315417)
Алексей, все-таки если будет возможность и желание выложите скрин

После НГ теперь уже. Других дел хватает. Но повторюсь, что в окне Контроллера не помню такого рода сообщений об QoS.

---------- Сообщение добавлено в 14:01 ---------- Предыдущие сообщение было в 13:38 ----------

Цитата:

Сообщение от Rokfor (Сообщение 315436)
коллеги, а где вы нашли описание механизма QoS ?

Володя, судя по информации отсюда, это описывается в спецификации протокола RailCom версии 1.3 от 2014 года.

Rokfor 26.12.2017 14:24

Цитата:

Сообщение от laba (Сообщение 315437)
судя по информации отсюда, это описывается в спецификации протокола RailCom версии 1.3 от 2014 года.

нету там.
в тексте ссылка есть, но она никуда не ведет

kej 26.12.2017 14:30

Алексей, нужна Ваша помощь в этом разговоре. Возможно Вы поможете не только "товарищу из Белоруссии":-)
http://forum.rocrail.net/viewtopic.p...158615#p158615

laba 26.12.2017 16:30

Цитата:

Сообщение от Rokfor (Сообщение 315448)
нету там.
в тексте ссылка есть, но она никуда не ведет

оффтопик

laba 26.12.2017 16:34

Цитата:

Сообщение от kej (Сообщение 315450)
Алексей, нужна Ваша помощь в этом разговоре.

оффтопик

kej 27.12.2017 12:12

Кому еще интересна функция "Статистика" (QoS) от Rocrail.
http://forum.rocrail.net/viewtopic.p...=9459&start=15

kej 28.12.2017 13:13

Вложений: 1
Спорное решение, если судть по числу участников в этой дискуссии.:-)
Ну да ладно, продолжим. В сегодняшнем релизе Rocrail упоминается z21 и сообщения RailCom. Очень осторожно хотелось бы предположить, что это как то касается QoS и компеляции в самой прогрмме таблицы "Статистика". Ведь по большому счету, если в сообщениях контроллера сообщается данные и самое главное их величина, отображается информация RailCom, то я думаю средствами самой программы возможно как то задействовать эту информацию (QoS) и для функции "Статистика". Така как в таблице участвуют элемент № лока с определением этого вполне справляется и глобальный детектор z21. Второй элемент - это номер датчика. Здесь как я предпологаю (датчики всегда привязаны к конкретному блоку) необходим локальный детектор (ОС с RailCom). Думаю, что при работе программы в автоматическом режиме, местоположение лока на конкретном блоке программа высчитывает сама (можно и обойтись без ОС с RailCom) - вот это момент я и предложил разработчикам Rocrail задествовать для реализации функции "Статистика" для КС z21 с OC без RailCom. Но видимо в Европе в самом разгаре Рождественские каникулы. :-)

Saddam 28.12.2017 13:26

оффтопик

Второе что всё таки вы хотите от QoS, еще раз повторю данные о токосьёме он даёт косвенные, так как основан на результатах дешифровки - если есть потери, есть QoS, нет потерь - QoS = 0.

Цитата:

Сообщение от kej (Сообщение 315656)
Думаю, что при работе программы в автоматическом режиме, местоположение лока на конкретном блоке программа высчитывает сама (можно и обойтись без ОС с RailCom)

Нет при режиме Bi-Di приоритет у данных полученных от декодера, это видно при запуске авторежима.

Цитата:

Сообщение от kej (Сообщение 315656)
задествовать для реализации функции "Статистика" для КС с OC без RailCom.

Вы предлагаете перевернуть стандарт с ног на голову, ради чего?

laba 28.12.2017 13:54

оффтопик

Saddam 28.12.2017 14:14

оффтопик

kej 28.12.2017 14:40

Цитата:

Сообщение от laba (Сообщение 315659)
Объяснить мне, кто может на пальцах

Могу только еще раз дать ссылку на видео в начале темы о фактической скорости. Вместе со скорость там и другая информация (в т.ч. и № лока). Думаю, с этим вопросом Робу :-)

"при режиме Bi-Di приоритет у данных полученных от декодера"
Кстати, сообщения глобального детектора (№ Лока, Фактическая скорость, QoS) z21 в интерфейсе Rocrail отображаются и без включения режима "Использовать БиДи соединение" Смею предположить, что все настройки БиДи в Rocrail так или иначе относятся к работе локальных детекторов ОС с RailCom. Все это говорит только в пользу моего предположения о возможности работы функции "Статистика" в автоматическом режиме программы Rocrail c ОС без RailCom с помощью программных решений самой Rocrail.

kej 28.12.2017 15:11

Цитата:

Сообщение от Saddam (Сообщение 315657)
это доработки Роб проводил по моей просьбе,

Выложите скрины работы Rocrail в режиме эмуляции z21 Вашего оборудования с последним релизом программы.

Alex_S 28.12.2017 16:11

Цитата:

Сообщение от laba (Сообщение 315659)
Объяснить мне, кто может на пальцах, пожалуйста. Как Глобальный детектор отфильтровывает сообщения из вырезов в DCC сигнале, которые туда посылают 5 или 10 локов одновременно.

Сообщения в вырезе шлются тем декодером, кому был адресован пакет, предшествующий вырезу.
Это железно. По-другому работать не будет: вырез рассчитан только на две Railcom-посылки (сначала канал 1, потом канал 2).
Проблема возникает в случае сплоток (несколько декодеров с одинаковым адресом сплотки) или сплоток из декодеров с одинаковым обычным адресом.
Текущий стандарт S-9.3.2 рекомендует выключить канал 1 на всех декодерах сплотки, кроме одного. Про это сказано в конце параграфа 5.2 ADR в S-9.3.2. Тогда по каналу 1 будет отвечать только один декодер сплотки.


Текущее время: 15:53. Часовой пояс GMT +3.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc. Перевод: zCarot
Copyright © ModelldepO.ru 2006 -