Rocrail и сообщения RailCom, о качестве сигнала DCC на рельсах(QoS)
Перенесено из соседней темы:
Цитата:
|
Цитата:
К тому для получения представления о состоянии пути, нужен определённый объём траффика на макете, а у меня это пока нереализуемо, в силу не готовности макета. Новое железо ещё и не смонтировано вовсе, только недавно закончил собирать все, необходимые мне модули, делаю подготовительную работу по разводке проводов и подключениям к блок-участкам. По-поводу Роба. Многие фичи он добавляет только на основе описанных протоколов, не имея реального железа под рукой. Это и понятно, ведь нельзя же держать в доме такое огромное количество различных устройств разных производителей. Поэтому баги или не совсем правильная работа неизбежны, но как правило многое устраняется достаточно оперативно. |
Цитата:
|
Цитата:
Цитата:
|
Цитата:
http://forum.modelldepo.ru/showpost....&postcount=110 Как я понимаю, работа "Статистики" связанна с обработкой и систематизацией сообщений QoS. |
А, всё вспомнил. Мысль такая возникла.......
Может это всё обрабатывается внутри программы и сразу отправляется в Статистику, а не выводится в окно Контроллера, раз сделана поддержка только для железа BiDiB. Ведь тут никакой реакции и настройки от пользователя не нужно, поэтому зачем забивать экран лишней информацией. Роб собственно Вам и написал, что то, что выводится у Вас, есть ни что иное, как просто информация для размышления и это никоим образом не обрабатывается дальше программой. Откуда это у Вас появляется, это вопрос уже другой и его надо рассматривать на уровне протокола обмена данными, мне так думается. |
Цитата:
Алексей, все-таки если будет возможность и желание выложите скрин с информацией контороллера в части RailCom (QoS). Думаю 2 звена и небольшие настройки Rocrail будет достаточно.:-) Пришла такая мысль. Функция "Статистика" находится в свойствах "Датчики". Каждый отдельно взятый датчик привязан как правило к конкретному блоку. Для работы этой функции программа должна знать какой конкретный лок находится на данном блоке (что бы потом указать его в сводной таблице) При работе Rocrail в автоматическом режиме для этого позиционирования не нужны локальные датчики ОС с RailCom. Программа сама расчитает местоположение каждого лока, а для приема данных RailCom (QoS) достаточно будет и глобального детектора RailCom самой z21. А вот при ручном управлении макетом посредством Rocrail отсутствие ОС с RailCom - уже критично. В пояснениях разработчиков по "Статистике" вроде как нет, при каком режиме Rocrail работает эта функция. Возможно кто то поделится своими соображениями по этому поводу. |
Цитата:
А где это показывает экос - я не нашел, похоже, что он никак принятый раилком не показывает юзеру. Я, по крайней мере, не нашел. ---------- Сообщение добавлено в 11:14 ---------- Предыдущие сообщение было в 11:01 ---------- Я вот подумал насчет QoS. Эта функция совершенно не нужна в декодере, ее можно легко реализовать средствами станции, а именно глобального детектора. Каждый декодер в cutout'е после команды на свой адрес передает свою скорость и температуру. Глобальный детектор может элементарно собрать статистику этих ответов: - есть ответ декодера = декодер нормально считал DCC пакет - нет ответа = декодер не смог прочитать пакет = контакт пропал. Совершенно не обязательно грузить этой фигней MCU декодера. |
Цитата:
Цитата:
|
Цитата:
Я думаю, что перекладывать эту функцию на декодер - ошибка, он все равно должен будет передавать это читалке раилкома, к тому же декодеру и так есть чем заняться, проще и дешевле это делать в самой читалке. ---------- Сообщение добавлено в 12:14 ---------- Предыдущие сообщение было в 11:51 ---------- Кстати, когда я делал раилком, для отладки я использовал свою читалку и чтобы оценить качество и своевременность передачи байтов декодером, я сделал простой подсчет кол-ва принятых от декодера пакетов и кол-ва ожидаемых пакетов, совсем не трудно разделить одно на другое и получить соотношение потерянных пакетов. Это элементарная задача, не понимаю, почему так не сделали те, кто описывал механизм QoS в стандарте. |
Цитата:
|
коллеги, а где вы нашли описание механизма QoS ?
На сайте NMRA вывешен S-9.3.2 там нет ни слова про QoS |
Цитата:
Цитата:
Возможно в будущем, что-то и будет сделано в этом направлении, но всёму своё время. Цитата:
---------- Сообщение добавлено в 14:01 ---------- Предыдущие сообщение было в 13:38 ---------- Цитата:
|
Цитата:
в тексте ссылка есть, но она никуда не ведет |
Алексей, нужна Ваша помощь в этом разговоре. Возможно Вы поможете не только "товарищу из Белоруссии":-)
http://forum.rocrail.net/viewtopic.p...158615#p158615 |
Цитата:
|
Цитата:
|
Кому еще интересна функция "Статистика" (QoS) от Rocrail.
http://forum.rocrail.net/viewtopic.p...=9459&start=15 |
Вложений: 1
Спорное решение, если судть по числу участников в этой дискуссии.:-)
Ну да ладно, продолжим. В сегодняшнем релизе Rocrail упоминается z21 и сообщения RailCom. Очень осторожно хотелось бы предположить, что это как то касается QoS и компеляции в самой прогрмме таблицы "Статистика". Ведь по большому счету, если в сообщениях контроллера сообщается данные и самое главное их величина, отображается информация RailCom, то я думаю средствами самой программы возможно как то задействовать эту информацию (QoS) и для функции "Статистика". Така как в таблице участвуют элемент № лока с определением этого вполне справляется и глобальный детектор z21. Второй элемент - это номер датчика. Здесь как я предпологаю (датчики всегда привязаны к конкретному блоку) необходим локальный детектор (ОС с RailCom). Думаю, что при работе программы в автоматическом режиме, местоположение лока на конкретном блоке программа высчитывает сама (можно и обойтись без ОС с RailCom) - вот это момент я и предложил разработчикам Rocrail задествовать для реализации функции "Статистика" для КС z21 с OC без RailCom. Но видимо в Европе в самом разгаре Рождественские каникулы. :-) |
оффтопик
Второе что всё таки вы хотите от QoS, еще раз повторю данные о токосьёме он даёт косвенные, так как основан на результатах дешифровки - если есть потери, есть QoS, нет потерь - QoS = 0. Цитата:
Цитата:
|
|
|
Цитата:
"при режиме Bi-Di приоритет у данных полученных от декодера" Кстати, сообщения глобального детектора (№ Лока, Фактическая скорость, QoS) z21 в интерфейсе Rocrail отображаются и без включения режима "Использовать БиДи соединение" Смею предположить, что все настройки БиДи в Rocrail так или иначе относятся к работе локальных детекторов ОС с RailCom. Все это говорит только в пользу моего предположения о возможности работы функции "Статистика" в автоматическом режиме программы Rocrail c ОС без RailCom с помощью программных решений самой Rocrail. |
Цитата:
|
Цитата:
Это железно. По-другому работать не будет: вырез рассчитан только на две 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 -