Зачем придумывать велосипед? Скорость равна расстояние делёное на время. Расстояние - это отрезок от датчика до датчика, а время это количество периодов известного генератора при прохождении колеса от датчика №1 до датчика №2.

Поэтому и ПАРА датчиков. Предвидел советы КТСМ=щиков о возможности измерения скорости с помощью одного датчика и временем прохода над ним осей.
Пока у нас с тобой "Манька хвалит Ваньку". Давай замечания по моему алгоритму.

Это не наше (КТСМ)!!!

Ладно, замечания ещё будут, я надеюсь.
Давай прикинем, как реализовать своевременную подачу извещения, подразумевая, что подвижная единица может ускориться между любой парой датчиков, находящихся на участке от начала Р.Ц., с которой осуществляется подача извещения (в моём варианте это 19П) до начала переезда.
У меня есть мысль, но она требует упорядочивания. Не тороплюсь пока.

Какими средствами будет решаться эта и пр. задачи? Предполагаю, что на уровне "железа", тогда какая элементная база? Мой уровень - стандарт ТТЛ 155-1533 серий (ДИСК))).
Если использовать два счётчика, работающих по-очерёдно, то при увеличении скорости сумма на №1 счётчике будет больше чем на №2. Фиксируем этот факт и отправляем депешу: "скорость возросла".

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

про то и речь. На моём рисунке только начало работы схемы. Дальше пока обстоятельно сообразить не могу, но очевидно, что сравниваться должны скорости проследования первой осью подвижного состава датчика и датчика предыдущего. Таким образом, если на участке приближения имеем три датчика, то это уже 4 пары (с учётом двух датчиков, расположенных перед участком приближения).

tyubik добавил 18.05.2011 в 13:58
Подозреваю, что это приведённые величины для различных типов подвижного состава. Нет?

Если хотите, то можно обойтись не парами датчиков а одиночными, но установленными через, например 50м ( для этой цифры еще нужно теоретическое обоснование ) на полигоне от самой дальней точки подачи извещения + эти самые 50м и до 100-200 м до переезда ( опять же нужна математика для обоснования этого числа ) - итого при переезде с извещением за 51 сек на скорости 140 км/ч имеем длину участка приближения около 2000 м - по этим цифрам 38 датчиков только с одной стороны и только по одному пути. Мне самому эта идея всегда нравилась пока она не подхола к стадии экономического обоснования :smile_24:

Прекрасно иметь собеседника, понимающего суть беседы и разговаривающего на одном со мной языке. Верно, для обоснования расстояний между датчиками и количества датчиков нужны математические (сложные для скукоженного от алкоголя тюбикова мозга) расчёты, позволяющие создать алгоритмическую модель работы переезда. Другое дело, что очевидно некоторое критическое расстояние от края переезда, на котором установка счётчиков уже бессмысленна. Таким образом оснащать участок извещения датчиками по все длине не имеет смысла.

tyubik добавил 18.05.2011 в 14:18
про элементную базу пока рано.

tyubik добавил 18.05.2011 в 14:20
Интересненько, а кто и когда этим занимался? Чем всё закончилось?

Не знаю, может официально кто-то и занимался, но я точно не занимался, это просто мои идеи.

У нас на жд очень удобно использовать РЦ в качестве датчиков приближения, поэтому добавка счетчиков осей удорожает стоимость внедрения весьма сильно. С другой стороны с учетом того, что в АБТЦ уже используются достаточно короткие РЦ можно попытаться использовать даже их для реализации Вашего алгоритма, пусть не с такой же точностью, но уж точно с меньшей стоимостью. Да и на станциях достаточно много участков приближения к переездам разбито на станционные РЦ и лишь приемо-отправочные пути нужно оснащать счетчиками осей для реализации Вашего алгоритма и то не все, а лишь главные и безостановочного пропуска, как правило. Идея подана, остается лишь ее реализовать хотя бы "на бумаге". У меня нет на это времени, да и мотивации тоже маловато. А у Вас может получится :thumbup1:

Давно и безуспешно агитирую разработчиков систем счета осей сделать "довесок" к переезду, расположенному на перегоне с числовой кодовой автоблокировкой, который бы позволил не "резать" блок-участок по переезду на две РЦ ради решения достаточно простой задачи - открытия переезда за хвостом поезда. Чтобы не полностью новый (и соответственно дорогой) переезд на счете осей, а именно такой гибрид - классическое закрытие от участка приближения (РЦ) и открытие - по счету осей. Думаю, что там может получиться неплохая экономика - не нужно трансляции кодов, изостыков, дроссель-трансформаторов, кодирования "в хвост" и др.
А если одновременно решить задачу автоматической коррекции времени извещения на переезд - это было бы совсем здорово! И можно предположить, что экономика при этом станет менее "красивой", но останется положительной, что тоже неплохо.

РЦ штуковины не плохие, но речь ведь не только про тоналки, а в обычных фазочувствительных ДТ тоже ведь не 3 копейки стоят. Пока "пристреливаюсь" к наименее сложному переезду на перегоне, (не на удалении/приближении). Материальной мотивации тоже не имею, но для разминки мозгов очень даже приятно. Да и всё равно, рано или поздно, но необходимость в "интеллектуальных" переездах возникнет очень резко.

tyubik добавил 18.05.2011 в 14:52
Простите великодушно, но Тюбик в предыдущем своём посте имел сказать тоже самое.

tyubik добавил 18.05.2011 в 15:03
хм, действительно, целесообразно ещё и за переездом счётчики ос иметь. Тогда про пресловутую потерю шунта под последними вагонами, влияющую на замедление открытия переезда, можно забыть.
Во как, с миру по нитке...
А ничОтак у нас ЦШ, в "мелочи" вникает. Прикольно. Но похвально, ибо дьявол в мелочах.

Ну вообще-то я ЦШ недавно, а СЦБист - давно.

было бы странно, если наоборот :oiE:. Ладно, это лирика, подтрунивать друг над другом иногда полезно.
НикНик, насколько я понимаю, основная доля стоимости ЭССО приходится не на сами датчики, а на аппаратуру обработки и передачи информации? В РФ у нас один монополист в производстве этой аппаратуры?