Сейчас немного знакомлюсь с цифрой, так в рамках только аналогового управления некоторые задачи решить трудновато - видимо придется всеж идти в сторону аналого-цифрового управления локами. Например в аналоге пока не нашел решения "минуты готовности", т.е. когда загорелся разрешающий сигнал и подано питание на блок-участок, но лок не сразу начинает двигаться, а только через какое-то время. Да и управление скоростью тоже на аналоге получается "туповатое". Идея видится задействовать "цифру" так: лок заходит на новый блок-участок, читает его код, обнаруживает, что он стал другой по сравнению с предыдущим, шлет уведомление контроллеру о занятии нового блок-участка и начале освобождении предыдущего (состав то еще там продолжает ехать). Только пока не знаю способны ли существующие цифровые модули локов работать в обе стороны, или они могут только ловить адреса и команды совершенно "не вникая" кто их послал...
Идея-то в том, чтобы после подачи напряжения лок включил свет и плавненько начал набирать скорость, а не рывком. Вообще подумываю и хотелось бы, чтобы разделить "автоблокировку" (маршруты) и "тайм-тейбл", т.е. движение локов "по расписанию". Для примера: на светофоре может быть зеленый, но на этой станции надо делать остановку на "пару минут" согласно "тайм-тейблу". С другой стороны ошибочная команда на начало движения локу при "несобранном" маршруте до него не доходит по запрету автоблокировки.
RocRail в принципе неплохо укладывается в мою концепцию на уровень того самого "тайм-тейбла". Как раз есть расп-пи чтобы ознакомится "что-за" программа. Единственная проблема всех виртуализаторов - это проблема обратной связи виртуальной модели с реальной моделью, но в рамках DCC я пока не вижу решения. Кто-то занял, а кто - кто его знает - нет же обратного отклика: "я лок адрес такой-то занял блок-участок номер такой-то..." Достаточно просто случайно переставить лок на соседний путь. И крах "Матрицы".
Блочный подход задачу несколько упрощает. Но управление движением, остановками целесообразно перенести на программный уровень. Вот тут-то цифра вполне удобна. Пусть может не сразу, но в эту сторону надо двигаться.
Положение и направление движения.
В цифре это довольно актуальный вопрос. Тем более если локов больше двух. Потому что в аналоге перевернул симметричный лок на 180 градусов и не страшно - он поедет все равно в ту сторону, которая задана полярностью на рельсах, а вот в цифре из-за выпрямления "сторона движения вперед" изменится и это может оказаться сюрпризом для "Матрицы". Я уж не говорю про случаи, когда стрелка может не полностью перевестись...
Как вариант технология RFID или что-то аналогичное - тем более на локах есть питание и не надо делать большие катушки воздушных трансформаторов для питания чипов - небольшая петелька антенны под локом. Это получается достаточно интересное решение. Сами чипы дешевые, да и надо их на локи счетное количество. Только цена считывателей мне не известна, хотя здесь не требуется работа на дальности в 10-100 м. Главный вопрос помехоустойчивость решения. Может уже кто-то попытался реализовать что-то подобное - это уже почти как на жд получается...
Использовать обычные сенсоры? А что есть сенсор? Если он механически замыкается, то любой подвижной состав давит на этот сенсор. Если электрически, то помимо локов еще вагоны с металлическими колесами будут так же "давить" на это сенсор. Тогда как программа отличит: это давил лок, это вагон в том поезде, а это другой "лок-призрак"? Ахтунг поезд-беглец! Так что надо не просто знать что "кто-то давит эту кнопку", но и " а кто это был". Только тогда картины виртуальная и реальная будут ближе.
Решений получить инфу только два - либо внешний путь (с различными ухищрениями чтобы сохранить DCC без модификаций), либо реализовать DCC 2.0, умеющую это делать внутри себя.
RFID там упоминается, но проблема скорее в уровне помех в N или в H0, так как токи потребления локами разные и уровень помех тоже.
По поводу двухстороннего обмена в DCC - там точно написано "Need new DCC equipment" - нужно новое оборудование DCC, с поддержкой OpenDCC/BiDiB. Так что все идет к сформулированному мной ранее:
Идея видится задейстовать "цифру" так: лок заходит на новый блок-участок, читает его код, обнаруживает, что он стал другой по сравнению с предыдущим, шлет уведомление контроллеру о занятии нового блок-участка и начале освобождении предыдущего (состав то еще там продолжает ехать)... Зачем эти все сложности? Потому что когда локов 2 уже неплохо знать где "гуляет" каждый, а если 5-10, то и подавно.