Перейти к содержанию
    

andrey_p

Участник
  • Постов

    137
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о andrey_p

  • Звание
    Частый гость
    Частый гость
  • День рождения 27.09.1974

Информация

  • Город
    Array

Посетители профиля

2 273 просмотра профиля
  1. Теперь понял! @mitya1698, @aaarrr спасибо!
  2. Ток я узнаю для подключённого светодиода. Вопрос в том, на какой ток рассчитана коробочка, залитая компаундом. Если она сгорит, проработав минут 5, то замена коробочки обойдётся тысяч в 20, если её вообще можно будет купить. Светодиод на 20мА я уже подключал. Работает, но по ощущениям не такой яркий по сравнению с оригинальным.
  3. Добрый день! Я понимаю, что вероятность небольшая, но вдруг. Мне нужно опознать светодиод по фотографии. Не саму марку, а хотя бы рабочий ток. Белый светодиод из подсветки шуруповёрта Festool, диаметр 5мм, сгорел после нескольких лет эксплуатации. Шуруповёрт недешёвый, подсветка была довольно яркая. Блок управления представляет из себя коробочку, залитую компаундом, то есть доступа к управляющим элементам нет. Я так понимаю, что рабочий ток 20мА или 40мА. Заранее спасибо!
  4. С WebRTC вам не нужен ни Zoom, ни Skype - вы получаете всё из коробки. Набираете условный номер и получаете видеозвонок с каналом для MIDI данных. К тому же Вы можете сделать UI точно под Ваши потребности (ноты, задачи, и т.п.)
  5. Сейчас в драфте находится стандарт WebUSB, который позволяет из браузера работать с устройствами USB. Стандарт (драфт) уже поддержан многими браузерами по умолчанию. Подозреваю, что у Вас планируется параллельно использовать видеозвонок / конференцию, поэтому хорошим решением может оказаться связка WebRTC для аудиопотока / видеопотока и передачи данных для MIDI, считанных через WebUSB. WebRTC использует прямое соединение двух клиентов, однако нужен сигнальный сервер для установления соединения и "пробивки" каналов через NAT посредством ICE. Еще потребуется сервер STUN для ICE. Сейчас можно пользоваться множеством открытых сервисов STUN, но даже в случае их недоступности этот сервис можно поднять самому. Сервис TURN Вам вряд ли понадобится, так как вероятность того, что Ваши клиенты окажутся за симметричным NAT или они будут в связке симметричный NAT / port restricted NAT, стремится к нулю. Ещё потребуется сертификат для https, но это не проблема с Let's encrypt. Ах да, и бесплатно. Если кратко, то всё можно сделать через WEB. Если нужна помощь, обращайтесь. Знаю всё, кроме WebUSB и MIDI, с которыми ещё не работал.
  6. Конструктивно) Этот "бред какой-то" используется известными Вам производителями телекоммуникационного оборудования. Но Вам, конечно, виднее... P.S.: Каюсь, внесу уточнение:) Для использования JITA нужно иметь ОСРВ на обоих концах, а также канал с практически постоянной задержкой. То есть это не описываемый случай. Идея JITA заключается в том, что один терминал говорит другому, в какой момент тот должен подготовить и отправить пакет с голосовыми данными. Этот момент выбирается таким образом, чтобы на принимающей стороне пакет пришёл ровно в тот момент, когда "едва" хватит времени на его преобразование. При этом "канал" в одном из решений выглядел так: терминал 1 - радиоканал - устройство 1 - Ethernet (IP) - устройство 2 - E1/T1 - устройство 3 - E1/T1 - устройство 4 - Ethernet (IP) - устройство 5 - радиоканал - терминал 2 В случае "непрямого" канала мы не можем гарантировать постоянство задержки, поэтому придётся вырабатывать jitter адаптивными буферами по худшему варианту. Поэтому от RTP просто так уйти не удастся. RTP бесполезен для ОСРВ в случае постоянной задержки канала, в противном случае необходим. P.P.S.: Но SIP на устройство тащить точно не нужно, здесь я остаюсь при своём мнении.
  7. Just-in-Time Audio. Грубо говоря, приёмник управляет буфером отправки передатчика, минимизируя задержку на стороне передатчика. То есть необходимое количество отсчётов собирается в аккурат ко времени отправки буфера.
  8. Можно, конечно, без сервера, но тогда все устройства должны каким-то образом поддерживать актуальные "адреса" остальных устройств. Также придётся решать проблемы аутентификации и ещё много чего. Вам это не нужно, поверьте. У Вас стоит задача сделать закрытую систему связи, ориентированную на сеть IP. Судя по контроллеру, сильно "закрытую". Выбор SIP выглядит вполне логичным. Для работы со стационарных компьютеров Вам понадобятся "клиенты" SIP. Также нужен сервер SIP, в обязанности которого будет входить регистрация "клиентов", маршрутизация и парковка вызовов, поддержка конференций (с микшированием звука), запись разговоров при необходимости и ещё много стандартных и нестандартных функций PBX. Подозреваю, что любой из этих компонентов должен иметь открытый исходный код, который "некто" будет проверять с лупой. Явно потребуется отказоустойчивость, которая будет гарантировать работоспособность системы при выходе одного или нескольких(?) серверов SIP из строя. Тут есть разные варианты, для закрытых систем они несколько проще. Что касается "переносного" устройства на микроконтроллере, то на него я бы не тащил SIP (+RTP), а сделал бы упрощённый протокол сигнализации. И про RTP - для ОСРВ он бесполезен, на ОСРВ для передачи голоса используются другие подходы (вроде JITA, например). Со стороны сервера SIP нужно сделать адаптер для подключения данных устройств. Сейчас, наверное, только интернет. Я этой темой с 1998 года занимаюсь (проводная телефония, SIP телефония, мобильная связь, транкинговая связь, и т.п.). Работал и над "сильно закрытыми" системами, но здесь об этом писать не буду. Как показывает мой опыт, порог входа в эту область сейчас достаточно большой - "обзорные" курсы не сильно помогут.
  9. Не нужно тащить полный SIP на микроконтроллер, лучше использовать что-нибудь легковесное и сделать шлюз на компьютере. По аналогии с verto у freeswitch - когда все тащили полный SIP на JS, эти ребята придумали урезанный протокол поверх JSON, а в SIP перешли на шлюзе. Что-нибудь подобное нужно реализовать и здесь. И ещё нужно не забыть про STUN / TURN (хотя последний вряд ли будет у Вас задействован) и RTP. Я бы резал всё на контроллере и переносил функционал SIP в шлюз. И ещё, не используйте Asterisk, лучше базироваться на Freeswitch или Yate. Я в своё время выбрал последний - за 8 лет эксплуатации крупной боевой системы не было ни одного нарекания. P.S.: @Chameleos, будут вопросы - обращайтесь
  10. Это неверная оценка ситуации. Вы, видимо, не видели, что происходит с талантливыми инженерами, "свалившими" в крупные компании в США. Через два года они либо уходят в менеджмент двигать "колбаски", либо перестают быть талантливыми инженерами. Жизнь для живота не располагает к полному погружению в работу. Именно поэтому эти компании ощущают кадровый инженерный голод и активно аутсорсят проекты, в том числе и в нашу страну. Даже компании под отдельных людей создают. Остальные причины Ваших проблем и неудач объяснили выше.
  11. Если речь о разработке уникального решения подобного масштаба, то таких компаний нет нигде. Если, конечно, у Вас не безграничный бюджет. Если система более-менее типовая, то есть компании интеграторы. Но они строят систему на основе готовых компонентов. Возможно, с небольшой доработкой. Именно с небольшой. Если доработка существенная, то обычно выставляется заградительный ценник. Для примера: некий компонент, разработанный в отечественной компании с нуля, обошёлся примерно в 20 млн. руб. Западный вендор, собиравшийся адаптировать своё решение под наши требования, выкатил ценник в 60 млн. руб. Я считаю доработку решения вендора несущественной, так как очень хорошо знаком с их решением.
  12. Ниже описан процесс разработки некой системы схожего масштаба. Разработка велась западной компанией, в которой я работал. Заказчик хочет сделать "чтобы было зашибись". Свои пожелания он излагает в кратком документе (1-2 страницы) "своими словами". Этот документ называется WP (White Paper) и/или VoC (Voice of the Customer). Действия исполнителя (сначала потенциального исполнителя): На основе WP / VoC создаётся HLSA (High Level Solution Approach). Обычно HLSA делается в виде презентации для демонстрации заказчику с целью согласования единого видения функционала. Причём техническая часть презентации создаётся группой системных инженеров / архитекторов (эта группа тесно связана с "продаванами"). В некоторых случаях проводится НИОКР. По результатам обсуждения HLSA с заказчиком вырабатывается общее понимание. HLSA может итеративно дорабатываться исполнителем в ходе обсуждения. На основании HLSA создаётся TRD (Technical Requirements Document). Это те самые высокоуровневые требования, под которыми подписывается заказчик и по которым делается оценка. На основании TRD заказчик будет проводить приемо-сдаточные испытания. На основании TRD исполнитель создаёт SRD (System Requirements Document), включающий внутренние требования, невидимые заказчику. Это часть очень важна, так как требования в TRD являются слишком высокоуровневыми для создания системы. Количество требований в SRD может в десятки раз превышать количество требований в TRD. Делается TM (Tracability Matrix) из TRD в SRD. На основании SRD делается SAD (System Architecture Document), описывающий декомпозицию и интерфейсы между компонентами. Делается TM из SRD в SAD. На основе SAD для каждого компонента делаются BR (Box Requirements) и TM из SAD/SRD в BR. BR используется тестировщиками для создания документов по тестированию, а затем и самих тестов. Создаются TM до самых тестов. На основе SAD для каждого компонента делаются HLD/LLD (High Level Design / Low Level Design) со сквозными ТМ. Создаются сами компоненты. Низкоуровневые части компонентов тестируется разработчиками на основании HLD/LLD (Unit Testing) Каждый компонент проверяется соответствующей группой тестирования на соответствие конкретному BR. Вся система тестируется на соответствие SRD. Этот этап разделяется на два: системная интеграция / системное тестирование SI/ST (System Integration / System Testing) Система передаётся заказчику для приемо-сдаточных испытаний (по TRD) Писал по памяти, но, вроде, ничего не упустил:) Ещё есть документы финансовые, по линии проектного менеджмента, QA, сопроводительная документация, но о них я даже не пишу - это вообще отдельный мир. Каждый из перечисленных этапов оплачивается заказчиком. На начальном этапе может быть несколько потенциальных исполнителей. Мне удалось поработать на всех этапах, кроме последнего (11) и мне очень хорошо знаком этот процесс изнутри. По мере возможностей пытаюсь внедрять этот подход в отечественных компаниях. Что-то получается, что-то нет. Грамотные руководители очень хорошо понимают необходимость подобного подхода к разработке сложных систем. Мне кажется, что разработать описываемую Вами систему без подобного процесса невозможно в принципе.
  13. Только почему-то технологически доминирующий запад приходит на наш рынок за мозгами. И не только на наш. Поэтому у нас открывается куча как подразделений головных компаний, так и аутсорсинговых компаний. Вы удивитесь, но "американских" инженеров в США не существует уже давно. Я жил и работал в США в крупных западных компаниях и знаю, о чём говорю. Они давно здесь. Некоторые уезжают "туда", но большинство работает здесь. Большинство уехавших "туда" теряют свою квалификацию через несколько лет. От сытой жизни.
  14. То же самое происходит в крупных западных корпорациях. Когда-то я этому удивлялся, теперь нет. Не хочется повторяться, но всё то же самое происходит в крупных западных корпорациях. Линейные менеджеры об этом знают и очень внимательно отслеживают настроения этих 3-4 разработчиков. Любой проект в период становления держится на конкретных людях. Это потом можно заменять всех универсальными винтиками, о которых бредит менеджмент. Попробуйте декомпозировать задачу и ищите исполнителей на отдельные подзадачи. И Вам придётся отбирать компании, которые умеют делать реальные вещи. Методом проб и ошибок. Таких компаний много, но они редко побеждают в тендерах. В противном случае Вам придётся искать кого-то, кто сделает это за Вас. Но вот только стоимость результата там будет совсем другая.
  15. Работал с Google S2T, Deepgram и одним отечественным решением. Решение от Amazon, насколько я знаю, не поддерживает русский язык. Самое лучшее качество распознавания было у Google S2T. Единственный нюанс, это работа с ключами. Google выдаёт сертификат, на основании которого каждый час генерируются ключи. Ключи используются в запросах на распознавание и генерируются сервисом от Google. Библиотека для запроса ключей по сертификату закрыта, написана под .NET core. Для разработки нужны требования по задержкам. Большинство "распознавалок" работают в пакетном и потоковом режимах. Для пакетного режима нужно перекрытие фреймов, но работать с ним проще. Для повышения эффективности использования канала хорошо бы задействовать VAD. Ну и разбор ответов нетривиальный.
×
×
  • Создать...