Я так понимаю идет речь о en.wikipedia.org/wiki/Thiele/Small а измерить их быстрее всего методом добавочной массы. Можно заморочить корпус с переменным объемом.
Хм для меня очень непонятно симметричное размещение ВЧ динамика. Эффект «бафла» я так понимаю при проектировании вы не учитывали? Эффект переизлучения от лицевой панели покрытой чем то вы тоже не учитывали?
Я тоже имею пока замороженный проект трех полоски и про «бафл» не знал. После собирания тестовых корпусов и измерения я про него узнал, но было уже увы поздно. Если интересно почитать можно к примеру тут cxem.net/sound/dinamics/dinamic90.php
Очень хочется измерения АЧХ, ФЧХ и импульсного отклика самодельной АС. Слух это очень субъективно.
ЗЫ А так конечно за аккуратность и самоделкиность 5+, довести проект до логического конца это очень здорово!
Я сделал проще поставил последний CHDK по инструкции chdk.wikia.com/wiki/400D (или той что указана в топике, но chdk надо качать с первоисточника самый последний!)
Количество срабатываний затвора определяется двумя кнопками menu а потом disp. Самая нижняя строчка Release Count.
ИМХО проще чем выше обозначенная дикая последовательность кнопок на старом chdk.
Расскажу реальный случай, когда на 1G порту случайно не выспавшийся рубанул петлю. Аплинк на этом коммутаторе был 10G через DWDM в ядро сети.
Заметил ошибку только через минут пять когда увидел что попер трафик в 50 мегабит с порта тестового коммутатора. Но на этом коммутаторе не должно быть его в таком количестве.
Отработали супресы или как мы их называем штормилки, и ничего страшного не произошло.
После этого случая седлал себе отдельный стенд который идет к рабочим коммутаторам через спец порт с жестко прописаными штормилками.
Loopback detection в большинстве случаев требует STP. У 99% свитчей его либо нет, либо по дефолту отключен.
Строили домовую сеть, на оборудование huawei и edge-core, первые после того как выпустили нормальную прошивку перестали требовать включения STP на абонентских портах, вторые же вообще этого не требовали.
А вот с D-Link было все сложнее…
Ихмо правильно настроенная сеть может ограничить все проблемы одним коммутатором/сегментом сети.
Наши монтажники так проверяли патчкорды на железках в домовых шкафах, научились у коллег из другого города. Но там по другому настроены домовые коммутаторы и сами коммутаторы другие. В моих настроен shutdown при loopback-detection. Обнаружил это после их звонка и наезда дескать у тебя весь коммутатор дохлый ни одного живого медного порта.
Можно конечно сделать авто подъем после таймаута, но лень и надо учить криворуких что loopback зло и делать так нельзя.
Вот моя статья о том как я делаю переименование хостов habrahabr.ru/blogs/sysadm/82465/ (опубликовать просил товарища так как у меня не было тогда акаунта на хабре)
Не совсем понял что вы имеете в виду.
На одно обнаружение можно сделать много действий, но зачем делать 10 разных одинаковых Discovery на разные IP? когда в одном можно указать просто все диапазоны IP в которых надо проводить сканирование. В последних версиях работает.
Лучше одним действием делать и проверку и добавление в нужный район, но в этом случае необходимо делать количество действий по количеству районов.
ЗЫ Не сомневаюсь что можно сделать и по другому, но мне так больше нравится.
Официальный мануал достаточно подробный. Переведен на несколько языков.
Discovery вместе с триггерами очень гибкая вещь. Я использую в правиле обнаружения SNMPv2 агент ".1.3.6.1.2.1.1.1.0" который возвращает тип железки который очень часто уникален для одной серии железа.
Дальше пишем действие на обнаружение с использованием «И»
например такое если Полученное значение содержит "MA5600 V100R011"
Состояние обнаружения = "Up"
Тип сервиса = "SNMPv2 агент"
IP адрес узла сети = "10.хх.ххх.2-30"
ипы/диапазон подставьте свои
то делать следующее Присоединить шаблон "Template_Huawei_MA5605_system"
Добавить в группу "Huawei MA5605"
Добавить в группу "Группа какого либо района"
Добавить узел сети
для другого типа железки полученное значение будет другое можно написать другое действия исходя из этого.
Используя подобные правила и действия, можно не беспокоится об изменениях в количестве УД, они будут сами добавляться при настройке на них snmp в данном случае. Также можно их и удалять.
У меня например 73 триггера на обнаружение, и я еще не все настроил, что хотел.
Я тоже имею пока замороженный проект трех полоски и про «бафл» не знал. После собирания тестовых корпусов и измерения я про него узнал, но было уже увы поздно. Если интересно почитать можно к примеру тут cxem.net/sound/dinamics/dinamic90.php
Очень хочется измерения АЧХ, ФЧХ и импульсного отклика самодельной АС. Слух это очень субъективно.
ЗЫ А так конечно за аккуратность и самоделкиность 5+, довести проект до логического конца это очень здорово!
Количество срабатываний затвора определяется двумя кнопками menu а потом disp. Самая нижняя строчка Release Count.
ИМХО проще чем выше обозначенная дикая последовательность кнопок на старом chdk.
Статья писалась давно но скрипт до сих пор работает.
Заметил ошибку только через минут пять когда увидел что попер трафик в 50 мегабит с порта тестового коммутатора. Но на этом коммутаторе не должно быть его в таком количестве.
Отработали супресы или как мы их называем штормилки, и ничего страшного не произошло.
После этого случая седлал себе отдельный стенд который идет к рабочим коммутаторам через спец порт с жестко прописаными штормилками.
Строили домовую сеть, на оборудование huawei и edge-core, первые после того как выпустили нормальную прошивку перестали требовать включения STP на абонентских портах, вторые же вообще этого не требовали.
А вот с D-Link было все сложнее…
Ихмо правильно настроенная сеть может ограничить все проблемы одним коммутатором/сегментом сети.
Можно конечно сделать авто подъем после таймаута, но лень и надо учить криворуких что loopback зло и делать так нельзя.
На одно обнаружение можно сделать много действий, но зачем делать 10 разных одинаковых Discovery на разные IP? когда в одном можно указать просто все диапазоны IP в которых надо проводить сканирование. В последних версиях работает.
Лучше одним действием делать и проверку и добавление в нужный район, но в этом случае необходимо делать количество действий по количеству районов.
ЗЫ Не сомневаюсь что можно сделать и по другому, но мне так больше нравится.
Discovery вместе с триггерами очень гибкая вещь. Я использую в правиле обнаружения SNMPv2 агент ".1.3.6.1.2.1.1.1.0" который возвращает тип железки который очень часто уникален для одной серии железа.
Дальше пишем действие на обнаружение с использованием «И»
например такое если
Полученное значение содержит "MA5600 V100R011"
Состояние обнаружения = "Up"
Тип сервиса = "SNMPv2 агент"
IP адрес узла сети = "10.хх.ххх.2-30"
ипы/диапазон подставьте свои
то делать следующее
Присоединить шаблон "Template_Huawei_MA5605_system"
Добавить в группу "Huawei MA5605"
Добавить в группу "Группа какого либо района"
Добавить узел сети
для другого типа железки полученное значение будет другое можно написать другое действия исходя из этого.
Используя подобные правила и действия, можно не беспокоится об изменениях в количестве УД, они будут сами добавляться при настройке на них snmp в данном случае. Также можно их и удалять.
У меня например 73 триггера на обнаружение, и я еще не все настроил, что хотел.