Railcom и Rocrail
 

А кто-нибудь пробовал "прислюнявить" Railcom к Rocrail-у? В доках я не нашел даже как это должно работать... :( Каким образом информация лока будет отображаться в программе и как это можно использовать? ;)

Кроме Ленц Рейлком читать могут еще несколько железок, в том числе DIY. Делать вырезы умеет Станция и бустеры OpenBooster.

Это известно и понятно, что для этого нужно... Спрошу по-другому тогда... Рокрейл умеет читать Railсom или нет? Если нет, то зачем в свойствах датчиков есть возможность его выбрать?Какие альтернативы?

Я так не считаю, я думаю это самая перспективная система обратной связи и за раилкомом будущее. Через некоторое он будет распространен как сейчас DCC. И скорее всего полностью вытеснит другие системы.
И с чего вы взяли что ему нужны чистые рельсы ?
Нельзя делать такой вывод только потому, что у кого-то что-то не работает. Может быть целая масса других причин.
У меня не было никаких проблем с передачей на грязных рельсах, хоть и теряется часть пакетов, но т.к. они часто повторяются, то львиная доля все равно доходит до приемника, к тому же вся ценная информация - адрес лока передается в одном-двух байтах.

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

ИМХО:
Это похоже на попытки вендоров ДСС оценивать качество попадания в мишень по рикошету дроби. Только непонятно почему они продолжают упираться в однонаправленный интерфейс нагромождая его разными прибамбасами и при этом уже около (сколько там) лет так 15-20 никто не собирается уйти в сторону, например на радио, ИК и т.д., бьются лбом в стену каждый тянет одеяло на себя, но упорно сидят на транспорте который не позволяет выпрыгнуть из штанов...

Они (производители) стремятся сохранить совместимость с тем что выпускали ранее, и это правильно. Если у Вас есть идея, как "уйти в сторону" и при этом сохранить эту совместимость, попробуйте поделиться такой идеей - очень интересно. У меня тоже есть пара идей, см. ниже.

Радио, ИК и т.д. (например блютуф) это конечно хорошо, но поймите - инфа от декодера по протоколу railcom принимается на конкретном блок-участке, что позволяет определить местонахождение лока (вернее только то что он на конкретном участке, не более того). И этим уже можно пользоваться.

Вот мои идейки, не Бог весть какие, но интересно что скажете...

1. Да, можно использовать беспроводной способ обратной связи. Для обеспечения определения местонахождения нужно, что бы блок-участки сообщали локу (декодеру) свое местонахождение. Это можно сделать небольшим блочком, через который подключается блок-участок, который бродкастит свой ID, например во время DCC-idle сигнала (что бы не прерывать передачу полезной информации). Кстати использование railcom позволяет сокращать количество передаваемых DCC-пакетов, так как декодеры могут подтверждать упешный прием, и тогда постоянно повторять пакет не нужно - соответственно idle-пакетов будет больше.

2. Еще один, опять же беспроводной, способ. Декодеры выдают по беспроводному каналу (тот же блютуф и т.п.) свой ID, а их местонахождение будет определяться пассивной радиолокацией с помощью нескольких антенн, установленных в помещении макета. Знаю что практические разработки в этой области уже есть, но несколько в другой области. Для магазинов/супермаркетов разрабатывается специальная система отслеживания перемещения радио-излучателей, таких как сотовые телефоны и блютуф-устройства; данная система позволяет установить, какое время покупатели проводят у различных витрин помещения, тем самым оценивая степень их интересности для клиента. Пока точность определения довольно великовата (1-2 метра), но разрабатываемая система дорабатывается.

Ну а за railcom-ом будущее прежде всего потому, что это нижеследующее высказывание в той или иной степени подходит ко всем:

DCC вытеснил все другие системы, потому, что все (ну почти все) наелись перетягиванием каната и проблемами несовместимости и решили остановиться на чем то одном.
Вы называете DCC односторонним, но как вы себе представляете двухсторонний обмен по одной паре проводов, да еще учитывая то, что у одной из сторон нет своего источника питания, контакт постоянно пропадает и все это на фоне помех от нескольких электродвигателей ?

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

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

Вы хоть представляете что начнется, если хотя бы половина производителей скажет - мы больше не хотим работать на DCC и будем идти своим путем ?

Я думаю - это будет очень плохо для всех и для производителей и для моделистов.
И вообще, мне не понятна ваша нелюбовь к DCC, зато вы постоянно пишете про каких то буржуев, которые что-то придумали только для того, чтобы вытягивать из других деньги.
Система DCC очень проста и надежна, и еще DCC и раилком документированы и лежат в открытом доступе.
Это позволяет делать декодеры всем кто только может.
Разве стали бы так поступать те кто хочет залезть в ваш карман ?
Оставьте эту ненужную паранойю.

Я еще добавлю, что поддержка RailCom уже сейчас заложена в станцию (я имею в виду OpenDCC). Есть целая куча наколенных поделок для передачи-чтения RailCom. Пусть они еще закрыты и нет исходных кодов. Но это дело только времени.
Кстати, уважаемый Rokfor, у Кюфера расписано как должны летать ответы BiDi по XpressNet. Очень занятно.

Возможно я видел то, о чем вы говорите, но не уверен.
Если не трудно - киньте ссылку в личку,
Мне попадался проект, кажется на open dcc, но вся проблема в том, что это был не стандарт, а способ - как использовать xpressnet для
передачи некоторой информации (любой), я сам могу придумать аналогичный вариант - это совсем не сложно, но проблема в том, что производители станций xpressnet под этим не подписывались, а значит в любой момент они могут внести какие-то изменения в шину,
и этот способ начнет конфликтовать с чем нибудь другим, они могут это сделать даже не умышленно, а случайно, я думаю они даже не видели тот проект, который я видел.

---------- Сообщение добавлено в 13:58 ---------- Предыдущие сообщение было в 13:53 ----------

и еще, как только способ передачи данных раилкома в PC будет стандартизован и это примут те, кто пишут софт для управления макетом, так сразу же мы сделаем доступные модули - читалки и объедимим их в шину.
Сами читалки уже есть, проблема - как передать эти данные в программу управлением макета, так, чтобы она их поняла

Существует параллельный проект BiDiB, где ипользуется своя шина для устройств и USB для подключения к компьютеру (RocRail). Информация в документации RocRail.

По BiDi информации еще меньше, чем по RailCom... Особенно по железу, и тем более по DYI... Нет, я понимаю, что порассуждать, "что такое хорошо, а что такое плохо" © это конечно хорошо... Но хотелось бы конкретики: как в Rocrail увидеть данные Railcom?

Леш, нужно читать в доке Рокрейла про Тамс, т.к. у них есть полный комплект железа http://www.wiki.rocrail.net/doku.php?id=tams-railcom-en

есть такая тема, называется согласованная фильтрация, когда фильтр приёмника изначально настроен под маску сигнала, так вот эта штука может "вытягивать" сигнал из очень хреновых с\ш, при этом заморочная реализация у приёмника, которая при существующих аппаратных возможностях позволяет реализовать алгоритм на достаточно простых контроллерах. Отчасти эта штука (в некотором приближении) реализована здесь: в оптическом датчике на Тане13.

Я бы не был бы так категоричен... :-)

Я не критикую, а вижу факты.

по поводу придумать. Уже думать ничего не надо, придумано давно, ещё где-то в 70-х прошлого века, отработано вдоль о поперёк.

Например такое. Ситема типа "муха" (по-умному она является куском от автомата АСЦ).
Применительно к нам реализация системы выглядит следующим образом. над макетом на высоте h размещается камера объективом вниз на макет на контролируемых объектах размещаются ИК излучатели максимумом диаграммы в зенит. Перед камерой ставится ИК фильтр. Таким образом камера "видит" некоторое распределение блестящих точек на плане. Далее всё просто: сигнал с камера передаётся на контроллер, который либо синхронизируясь по ПЦТС, либо прямым съёмом инфо с буфера ПЗС (что даст большую точность). Таким образом мы имеем условную матрицу размером 575х700 точек (для стандартного разрешения) которая применительно к конкретным типам бытовых средней руки камер на высоте подвеса потоплка обычной хрущёвки даст точность определения местоположения цели не хуже 10-15мм. Разрешающая способность не хуже 5-15мм.
Наша задачка облегчается тем, что траектории перемещения целей детерминированы изначально, т.к. паровоз кроме как по рельсам никуда деться не сможет и паровозы в одну локальную точку плана съехаться никак не могут, кроме того всегда существует возможность прямого указания объекту погасить/зажечь ИК для уточнения его местонахождения при срыве сопровождения (если по выходу системы будет работать автомат сопровождения). Таким образом система способна давать не просто целеуказание в привязке к какому-то участку на плане, а дать конкретное местоположение на плане.

Жалко, что тема поднялась только сейчас. 4года назад я мог бы развернуть систему из работы на вертикальную плоскость в горизонтальную и показать как это работает вживую, причём изначальная задачка ставилась на работу по целям, которые могут передвигаться в произвольном порядке, сходиться в локальную точку пространства и не быть доступными в плане обозначения кто ты/где ты? Всё дальше молчу, спать спокойно хочу...

Для той разработки применялась широкоуголка с ХД разрешением (так как надо было держать большой угловой сектор), стоила она по тем временам хорошо. Для нашей задачик и точностей порядка 20-30мм, вполне пойдёт широкоуголка от систем наблюдения, ч/б с обработкой видео контроллером уровня мега8535-мега32 (держать будет около 25-30 точек, если больше - нужно будет упрыгать на АРМ ядра.

Так что либо иметь вариант лок "где-то здесь" с Рейлкомом (см. ниже), либо за 2-3 тыра иметь систему дающую относительно точное местоположение объекта (причём при размещении ИК на вагонах можно будет контрлировать и их, а так как все ударились в токосъём со светом, то проблем быть вроде не должно окромя товарняка).
Ну вот вроде както так...

Вариант второй.
Изначально мне не совсем понятен перенос опознавания непосредственно в лок. Я бы ещё понял это для аналога, но для цифры? Команда отдаётся непосредственно конкретному объекту, т.е. мы имеем скорость (пусть с некоторой долей погрешности), направление движения и изначальную привязку местоположения (например по датчикам занятости). Кто мешает поставив ещё один контроллер ДСС, который будет просто "висеть" на шине и следить за всеми командами к локам, рассовывая по ячейкам кто куда едет и где стоит. Далее по датчикам занятости снимаем инфо о налдичии лока или его уходе с контролирвуемого конкретным датчиком участка, соответственно переписвываем лок из одной ячейки в другую. Если кто-то дочитал мой понос про матрицы - тот поймёт... И не надо при этом в бедны лок соавть нечто, потом пытаться это нечто выловить из ДСС, не понимая отдал лок инфо или нет, при этом дробя макет план опять на куски под блочок который будет ловить ответ...
??? :-(

Причём, насколько я понял ув. тов. Злозло можно с некоторой точность на локах поставить скорость. Таким образом разбросав к существующим датчикам занятости датчики реперов (чтобы корректировать систему) - пару тройку штук на средний макет, можно по математике оценивать местоположение лока по S=V*t, конечно с некоторой погрешностью но всё таки не "где-то - как-то". Думаю цифра эту возможность даётт полностью и без бздыканий Рокрейла...

Не ну нам, русским, присущ конечно максимализм... Кто мешает оставить ДСС как старый формат используя для новых декодеров как питание? обмен же с новыми контроллерами можно ввести на стыке форматов...

Если шашкой рубить - то да...

Ну почему же нелюбовь?

Я не раз писал, что ДСС в плане применения ручных покатушек типа вижу куда еду - ситема самое то, нисколько не ущербная... даже в плане применения лёгкой автоматики, скажем для определения занятости на сркытых участках...

НО!, в плане наворота нна неё серьёзной автоматики, ну извините, ИМХО - геморр полнейший...

в 8-м посте я про это даже не упомянул, так что "постоянно", здесь не уместно...

РС тоже открыт по документации и что?



процент тех кто может?

не аргумент...

О, как, а чего так тихо и не матом? Блиин, Высшая степень культуры...

Спасибо тем кто дочитал. Готов к сотрудничеству...

Дык, для начала надо определить где какой лок находится, а уж потом обсчитывать его в математике... Вот для этого рейсом и нужен был бы: получаем данные с блок участка, идентифицируем лок, и дальше математикой его отслеживаем... А в плане покатушек, когда локи и снимаются и переставляются ручками - самое оно!

:-)
Поставили лок на макет, ручками ввели номер лока и участок на котором он находится, Дальше слежение будет его "держать" на автомате. Выключили/сняли питание, контроллер держит матрицу в ЕЕПром/флэш - не важно где - включили, он забирает данные в работу...

Ещё понимаю у меня, в аналоге, когда каждый раз разложил на полу, покатал на выходные день-два - собрал - убрал - надо постоянно после сборки вбивать кто где стоит и то, если сильно меняю топологию и расположение локов. А если собирается всё "как в прошлый раз" то данные тупо вытаскиваются из памяти и всё пучком.
Кстати мой малой выталкивает локи постоянно из сортировочного тупика: поставил, забил путь №н, установил лок, датчик занятости рявкнул, что кто-то есть неопределённый, он ставит номер лока и выгоняет его на станцию и далее - куда надо и так все по очереди выгоняет на план...

У меня больше времени отнимает под его "хочу" :-) выписывать связи между участками при построении новой схемы. а так как софт я ещё из под ДОСа в винду не перенёс то немного муторновато... :-). Иногда приходится собирать всё вечером в пятницу и вводить план, чтобы потом в субботу покататься :-), Маманя иногда правда ругается, что рельсы на ночь на полу поставили, приходится свет оставлять...

кстати у Вас же в цифре можно назначение адресов локов к конкретным участкам можно производить по слежению за состсоянием датчиков занятости. Например сунули команду конкретному локу стоять - следим на каком участке отозвался по уменьшению тоока, сказали поехали - следим где ток возрос, либо как-то привязать на включение фонарей/освещения. Так можно орпеделять где какой вагон стоит (или их связка)...

Ну, поставили первый лок - контроллер пробежал по адресам, по датчику занятости посмотрел, кто откликнулся, прибил лок к участку, поставили второй - пробежали по н-1 адресам и т.д.

Я имел ввиду контроллер, который ставит ДСС на рельсы, а не тот, что в локе стоит и отвечает куда-то...

Но работает пока только при создании маршрута... Рейлкома не хватает... :( Ну не хочу я создавать маршруты! Слишком много телодвижений нужно сделать, чтобы при моем желании оставить один состав на станции и пустить по этому пути другой... Или запустить на перегон второй состав вдогонку первому... Это один маршрут остановить, второй найти и активировать... А возможных комбинаций при ручном управлении локами (а именно этого и хочется :) ) - "и не сосчитать!" ©

Гоняет. Но их гоняет он, а гонять хочу Я... :) И гонять не случайно, а так как я хочу...

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

оффтопик

"О, сколько нам открытий чудных.." © А.С.Пушкин :)

Чего то я совсем тут затупался... Я всё таки не вьеду нафига для движения поездов, тем более (как теперь оказалось) на ручнике нужен рэйлком с его выдачей адреса вместо простого квитирования типа "я здесь/я теперь здесь"? Ведь это чисто диспетчерская задача и по занятости мест можно по заданному алгоритму пересаживать Иванова, Петрова, Сидорова куда угодно, согласно допусков по правилам, зная изначально, где они сидели в момент времени = 0?

Пример. Едет где-то по макету лок. Какой-то. Далеко от станции, но в ее сторону :) Я хочу его пустить на станцию на первый путь.Вход открыт, выход на боковой путь, на выходном горит желтый. Какой-то лок вьезжает на блок участок первого пути, рейлком определяет кто вьехал и, поскольку желтый рокрейл снижает скорость до половины. Или пока лок едет, я вдруг - раз, и захотел не на первый а на второй путь его загнать... Переключаю входную стрелку... Ну и далее по тексту... :)

На ЖД вдруг не бывает :(