Pull to refresh

Comments 32

Зато с PIC-ом, которые дорогие, медленные, с паршивой периферией и абсолютно нечеловеческой ISA. Но, согласен, приложение мозга в наличии.
А DTMF программно в контролере нельзя декодировать?
Конечно, можно было бы и в контроллере осуществлять декодирование. Но на момент реализации устройства мне было интереснее усложнить схему, чем программу.
А блок питания телефона разве нельзя заюзать заодно? Чего их плодить то?
Можно. Просто не хотелось резать провода «родного» блока питания. Кстати, теоретически можно было взять питание из самого системного блока.
В случае запитки от БП компа можно в телефоне вообще выкинуть аккумулятор, а МК после запуска через какое-то время должен был бы вырабатывать сигнал включения телефона, которым можно было бы имитировать нажатие кнопки включения телефона (тоже через оптореле). Схемку можно упрятать в батарейный отсек и наружу вывести провода — на питание и Reset.
Но тогда да, надо телефон немного курочить было бы.
Рекомендовал бы вам для смены пароля запрашивать новый пароль дважды: password#02#new_password#new_password, и менять его только при совпадении обоих посылок. Иначе есть вероятность, что одна из цифр нового пароля распознается неправильно (или не распознается вообще), и вы лишитесь возможности удаленного управления.
Согласен, делать так для смены пароля — надежнее. Еще можно немного доработать программу и добавить две новые команды: 1) замкнуть контакты управляемого устройства, 2) разомкнуть контакты (сейчас есть только команда на короткое замыкание в течение 100 мс).
А сервер под управлением какой ОС?
У себя дома как-то тоже пробовал при наличии телефона подключенного в юсб сервера по управлением Debian, делать что-то похожее. Но, делал просто, ставил smstools — отправлял на телефон тестовое смс, с определенным кодом. Дальше smstools ложил это смс в каталог, по крону запускался скрипт написанный на perl, который обрабатывал смс, и если нужный код встречался — производились нужные манипуляции с сервером.
Если ОС повисла, то такой способ нерезагрузки уже непрокатит.
Собственно из-за полного зависания ОС и возникла задача дистанционного сброса. Тот сервер был сделан на базе обычного ПК на Windows. У большинства настоящих серверов, насколько я знаю, есть встроенный сторожевой таймер, который сам умеет делать RESET при зависании ОС.
В фидошные времена делали вотчдог на компорт (ЕМНИП), софт дергал ногу регулярно, если дерганья прекращались (комп висит), нехитрая схемка коротила резет, комп перезагружался :)
Схема почти не изменилась и в настоящие времена: регулятор турбины на ГЭС, немецкое производство, центральный контроллер дергает выходом раз в ~10 секунд, чем постоянно сбрасывает реле времени, если контроллер завис — на выходе будет висеть или 1 или 0. Реле времени через некоторое время сработает и пойдет сигнал на верхний уровень управления что к автоматике регулятора в гости пришел пушистый зверек.
Все правильно. Контролировать сложные системы можно:
1) системами сложность которых гораздо ниже, зато надежность выше;
2) системами сложность которых гораздор выше, а надежность повышается путем разнокалиберного контроля параметров и оценки прохождения тестов контролируемой системы.
Примерно вот так выглядит такая схема. Делал ее мой напарник и использовалась она для «разбудки» оператора при зависании компьютера при помощи противного звука.
После прекращения обмена по RS-232 в течении более 3-х минут оператор начинал просыпаться.
Вместо динамика можно подключить выход схемы и к кнопке «Reset» компьютера.
Светодиод подмигивал в такт передаваемым данным.
На схеме нарисовано питание от игрового порта, но на самом деле было использовано +5В от USB.
И вам и отвечающим: а разве нету проблемы с определением, что значит «зависание»?

Не бывает разве багов когда подвисает какая-нибудь важная подсистема, и скажем, сеть отрубается, хотя com-watchdog или подобное продолжает отстукивать? Наверное на важных системах, типа описанного ГЭС дёргание происходит прямо из самой программы которая контролирует? (А не из других частей ОС)
Наверное на важных системах, типа описанного ГЭС дёргание происходит прямо из самой программы которая контролирует?

Да, программа крутится по кругу, время полного программного цикла известно. ОС в таких системах выделить сложно, но она есть. Очень даже возможно, что именно RTOS крутит программные модули по кругу, реагирует на прерывания и т.п., т.к. программист над обработчиками не задумывается, а просто реализует необходимый функционал. Есть контроллеры с резервированием, когда один поймает баг, второй подхватит процесс практически мгновенно, а первый выведет из работы.

Не бывает разве багов когда подвисает какая-нибудь важная подсистема, и скажем, сеть отрубается, хотя com-watchdog или подобное продолжает отстукивать?

Наличие сети диагностирует сам контроллер, потерю связи он заметит, далее зависит от софта. Бывают и закидоны программистские и не програмистские, что при потере одного из устройств система начинает сбоить (без аварий, уж безаварийность стараются предусмотреть). Но каналы связи можно (и нужно) резервировать. Отказ датчиков — датчики резервируют, два в параллель по разным кабелям на разные контролеры. Отказ питания вообще просто — два независимых ввода, может даже и постоянного тока (от АКБ) + бесперебойник внутри шкафа.
Плюс на том же регуляторе с ГЭС возможна работа вообще без контроллера (он просто уставки по мощности/частоте задает и поддерживает), а механикой рулит усилитель-регулятор, с резервированием. А еще противоаварийная автоматика, где почти любой отказ системы предусмотрен.
Автору спасибо за интересную статью!
Понравилось управление при помощи DTMF-команд.
Написал в ответ про подобную штуку, которую в том числе можно использовать для сброса компьютера бесплатно, только при помощи звонков.
Естественно без Arduino
Пароль в этом случае не нужен, так как управление происходит только с одного телефона.
Питание устройства реализовано от аккумулятора телефона и от сети при помощи штатного зарядного устройства.
Но недостаток — требуется модернизация телефона.
Статья «СОС-1. Сотовый охранный сигнализатор»
А что мешает повесить эту систему не на RESET а на POWER — можно таким образом выключать машину и включать!
Я тоже так подума когда прочитал. Но есть тонкости. Я когда это делал пришлось столкнуться.
Если ОС подвисла, то POWER надо удерживать не менее 4 сек. А если при включении компа держать кнопку питания 4 сек, то некоторые материнки успевают выключиться при включении. Т.е. надо тогда еще как-то определять выключен комп сейчас или включен и на основании этого выдавать импульс на POWER нужной длительности. Пути два. Либо аппаратно заводить на МК +5В от БП компа через делитель. Либо программно понимать статус питания компа, т.к. управление все равно через МК идет.
Ах время, ах нравы. У меня 6 лет в серверной стоял старенький PII у которого к светодиоду флоповода было подпаяно реле, а cat /dev/fd0 приводило к передергиваюнию по питанию капризного коммутатора.
Думаю, что держать выделенную линию для «устройства, предназначенного для подключения компьютера к телефонной линии» дороговато.
А мобильный телефон — это что тогда?
В студенческие времена делал подобное устройство на простейшем Atmel + стареньком Siemens S35, контроллер по COM порту лез в список СМС на сотике, читал их, при обнаружении смс с нужной командой делал ресет нужного сервера (было подключено с десяток серверов), попутно еще отправлял СМС о успешном действии.
Мне непонятно зачем тут пик. Сделать управление одной циферкой можно и без него, а несколько циферок нам и не надо.
PIC был в наличии, еще в его EEPROM хранится пароль, он отвечает на команды пользователя, также была вероятность, что надо будет менять логику работы, добавлять новые возможности.
Когда в 96-м году мы делали любительский ретранслятор (г. Троицк, F=145.700) включение-выключение его тоже было сделано с помощью ДТМФ, но пиков тогда не было. Декодер был сделан на логике, корпусов 5. Декодирует трёхзначный код на включение и трёхзначный на выключение. До сих пор исправно работает.
Во многих аэропортах СНГ до сих пор исправно работает навигационное оборудование, сделанное лет 20-25 назад на обычной логике (его периодически продляют — денег на новое оборудование не везде хватает). С 2000 года в разработках начали использовать PICи. И только в последние пять-шесть лет начали активно внедрять DSP :-)
Если бы еще до замыкания reset'а производился «на всякий случай» набор «магической» последовательности REISUB…
Sign up to leave a comment.

Articles