Я обращаюсь. Так как у меня тупо нет времени для поиска среди десятков сервисов "полноценного". И сидящий там мальчик мне честно говорит - нет, это не мой уровень, не смогу. Либо сами ищите сервис, который сможет, либо я его возьму и отправлю в Питер, где у нас главная мастерская. И меня это вполне устраивает.
И с моей точки зрения (как технаря, представляющего себе как работает любой саппорт/сервис) это наиболее рабочая схема - первая линия минимально квалифицированных людей натренированных на стандартные случаи и передачу сложных случаев на вторую линию. Вторая линия, решающая основной массив сложных случаев.
Сейчас таких практически нет. Большинство матриц имеют 16 строк сканирования (в стандарте HUB75 на скан отведено 4 линии, а в стандарте HUB75E - 5 линий). При заказе на али надо смотреть в параметрах матрицы scan в виде 16S. Вот это и будет количество линий сканирования.
Почему это? На линии адреса строки отдаём выход АЦП. На линию данных раз в длину строки выставляем единицу. Загрузку выходного регистра делаем на каждый клок. Выход постоянно разрешён. И всё - слева направо бежит точка, и высота этой точки (номер строки) напрямую определяется выходом АЦП. Идеальный осцилл :)
Задумался. Теоретически можно взять стандартную китайскую панель с интерфейсом HUB75 и задвигать туда данные в соответствии с уровнем. Получится не чистый осциллограф, а что-то типа стробоскопического осциллографа. Зато легко получить большой красивый экран за копейки :)
Любопытная схема. Надо будет помоделировать - пока не изучал детально, поэтому что-то не очень понимаю как считать коэффициенты и насколько устойчив будет алгоритм к самовозбуждению (особенно при использовании коэффициентов).
Этот подход плохо работает когда частота дискретизации не слишком велика. Например, 1633Гц при частоте дискретизации 32кГц даст всего 20 семплов на период. То есть фактическая частота сгенерированного сигнала будет 32/20=1.6 кГц. В случае DTMF это не критично, но метод табличного синтеза с интерполяцией не сильно сложнее вычислительно, но даёт куда более точное значение синтезированной частоты.
А вообще, вы уже чуть-чуть прикоснулись к ЦОС (DSP)
Задумался, кстати, а какой спектр получится в результате проделанной тс операции - вырезания просчитанного куска на примерно 10 мс и его бесконечного повторения. В голове крутится что-то типа свёртки спектра прямоугольного сигнала частотой 100Гц (то есть sinc) и спектра исходного двухтонального сигнала, так как проделанное чем-то похоже на фазовую модуляцию. Но вот как это аналитически посчитать - ума не приложу. Разве что численно в вольфраме или матлабе считать. Нет идей? :)
Если мы говорим о вашем алгоритме "в лоб", то вам нужно считать ровно столько же таблиц. Только если хранить в памяти только участок 0-90 градусов, то требования к памяти можно уменьшить в 4 раза.
Если же говорить об алгоритме синтеза по таблице, то предпросчитанная таблица к частоте дискретизации не привязана никак вообще. От частоты дискретизации зависит только величина инкремента аккумулятора. Поэтому таблица всего одна для любой частоты.
Надо воспроизвести тестовый звук. Что-нибудь предельно простое, например синус функцию. Затем измерять частоту и сравнить измеренную частоту с воспроизведенной частотой. Если значения совпали, то значит акустическая система воспроизведения работает четко
Генерируемая частота и её значение зависят только от микроконтроллера, который её генерирует. "Акустическая система воспроизведения" на это никак не влияет.
Вот таблица предварительно рассчитанных в RAM памяти микроконтроллера PCM семплов
А если бы вспомнили школьный курс, то достаточно было бы хранить в 4 раза меньше семплов. Так как достаточно хранить только половину полупериода - вторая половина полупериода точно такая же, а второй полупериод в точности равен первому, только с другим знаком.
Если решение и есть, то период уходит далеко в века
Как уже было справедливо указано - все частоты целые, поэтому период в любом случае не может быть больше 1 сек
В микроконтроллере по-любому не хватит никакой памяти, чтобы сохранить дорожку размером в период для суммы синусов с разрешенными частотами
16 вариантов по 1 сек. При частоте семплирования 32кГц и разрядности 16 (дикий оверкилл, на самом деле) получаем 1МБ. А если вспомнить, что вторая половина каждого записи ровно симметрична первой половине, до 512кБ. Для современных контроллеров вполне терпимо.
Но. В любом случае это решение в лоб и так не делают. А делают синтез по таблице.
То есть имеем одну единственную таблицу для значений синуса от 0 до 90 градусов. Как показывает практика обычно 64 точки более чем достаточно. То есть получаем 256 точек на период.
Для каждой генерируемой частоты имеем аккумулятор, который для каждого следующего выходного семпла увеличивается на величину:
генерируемая частота / частоту дискретизации * количество семплов в таблице
Тогда целая часть этого аккумулятора будет номер семпла в таблице, а дробная - определяет с какой пропорцией надо взять этот и следующий семплы для интерполяции. Синус - функция гладкая, поэтому вполне достаточно линейной интерполяции.
Повторяем для всех частот, которые надо сгенерировать, суммируем полученные значения и выдаём на выход.
Спасибо. Я просто вбил всё одной строкой и поменял в data одиночные кавычки на двойные - насколько я помню они транслируются в одиночные. Но попробовал и ваш вариант. Получил Webhook is already set. Но всё равно ничего не работает.
Проверил статус через getWebhookInfo. Всё выглядит правдоподобно:
"result":{"url":"https://xxx.apigw.yandexcloud.net","has_custom_certificate":false,"pending_update_count":13,"last_error_date":1697555723,"last_error_message":"Wrong response from the webhook: 405 Method Not Allowed","max_connections":40,"ip_address":"xx.xx.xx.xx"}
Почувствовал себя обезьянкой, нажимающей на кнопочки по листочку.
Посоветуйте - где, что и как проверять если всё вроде сделал по мануалу, а всё равно не работает. У меня есть подозрение, что синтаксис curl в винде несколько не такой, как описано. Но я что мог поправил, получил в ответ: {"ok":true,"result":true,"description":"Webhook was set"} , но всё равно ничего не работает :)
Вот кстати никогда не понимал - на хрена было матрице симулировать "реальность"? Сделайте в реальном мире общаги на 4 койки, работу забойщиком угля и еду из макарон и витаминных добавок. И как альтернатива - капсулы с VR. Так туда ломанутся разве что не все "добровольно и с песней". Всегда очень хорошо понимал Сайфера :)
Ага, не греет. На старом 412ом москвиче привод вентилятора был прямой от двигателя. Поэтому единственным способом не закипать в пробках на жаре было включить печку на полную мощность. В салоне творился просто ад, несмотря на открытые окна.
Проблема в том, что разработка медицинских средств - это огромные деньги. И чтобы их получить есть два пути - конкурентный и защищенный копирайтами рынок / получение денег у государственных фондов.
Убираем копирайт - получаем невозможность "отбить" затраченные деньги -> в разработку никто не будет вкладываться -> нет новых лекарств, что потенциально обозначает еще больше смертей.
С финансированием государством всё еще хуже, это мы в СССР проходили.
А по топику - крайне странный выбор точки входа. Уже то, что болезнь массовая, а более-менее работающий сенсор смогли сделать только считанные фирмы, должно было насторожить, нет?
Обычный провайдер домашнего интернета по умолчанию выдает динамический IP-адрес, который время от времени меняется. Зафиксировать его можно либо арендовав постоянный IP-адрес
Мммм. А разве сейчас по умолчанию не NAT? И на одном внешнем IP адресе может спокойно висеть пара сотен компов. Или всё-таки реальный внешний адрес дают каждому пользователю (пусть и диначмический)?
Насчет резистентности современных вирусов к ацикловиру - согласен - сам маялся почти месяц с опоясывающим лишаем (к счастью в весьма легкой форме), ацикловир не помогал вообще. Врач вообще был не в курсе альтернатив. Сам догуглил до фамцикловира, который всё прибил за неделю. Но вот насчет конкретно Алпизарина - что-то я глубоко сомневаюсь. Чтобы какой-то левый медцентр, занимающийся практически исключительно продажей экстрактов растительного происхождения нашёл что-то реально антивирусное... Не, чудеса бывают. Наверное. Но в данном случае - не верю.
Я обращаюсь. Так как у меня тупо нет времени для поиска среди десятков сервисов "полноценного". И сидящий там мальчик мне честно говорит - нет, это не мой уровень, не смогу. Либо сами ищите сервис, который сможет, либо я его возьму и отправлю в Питер, где у нас главная мастерская. И меня это вполне устраивает.
И с моей точки зрения (как технаря, представляющего себе как работает любой саппорт/сервис) это наиболее рабочая схема - первая линия минимально квалифицированных людей натренированных на стандартные случаи и передачу сложных случаев на вторую линию. Вторая линия, решающая основной массив сложных случаев.
Сейчас таких практически нет. Большинство матриц имеют 16 строк сканирования (в стандарте HUB75 на скан отведено 4 линии, а в стандарте HUB75E - 5 линий). При заказе на али надо смотреть в параметрах матрицы scan в виде 16S. Вот это и будет количество линий сканирования.
Почему это? На линии адреса строки отдаём выход АЦП. На линию данных раз в длину строки выставляем единицу. Загрузку выходного регистра делаем на каждый клок. Выход постоянно разрешён. И всё - слева направо бежит точка, и высота этой точки (номер строки) напрямую определяется выходом АЦП. Идеальный осцилл :)
Задумался. Теоретически можно взять стандартную китайскую панель с интерфейсом HUB75 и задвигать туда данные в соответствии с уровнем. Получится не чистый осциллограф, а что-то типа стробоскопического осциллографа. Зато легко получить большой красивый экран за копейки :)
Любопытная схема. Надо будет помоделировать - пока не изучал детально, поэтому что-то не очень понимаю как считать коэффициенты и насколько устойчив будет алгоритм к самовозбуждению (особенно при использовании коэффициентов).
Этот подход плохо работает когда частота дискретизации не слишком велика. Например, 1633Гц при частоте дискретизации 32кГц даст всего 20 семплов на период. То есть фактическая частота сгенерированного сигнала будет 32/20=1.6 кГц. В случае DTMF это не критично, но метод табличного синтеза с интерполяцией не сильно сложнее вычислительно, но даёт куда более точное значение синтезированной частоты.
Задумался, кстати, а какой спектр получится в результате проделанной тс операции - вырезания просчитанного куска на примерно 10 мс и его бесконечного повторения. В голове крутится что-то типа свёртки спектра прямоугольного сигнала частотой 100Гц (то есть sinc) и спектра исходного двухтонального сигнала, так как проделанное чем-то похоже на фазовую модуляцию. Но вот как это аналитически посчитать - ума не приложу. Разве что численно в вольфраме или матлабе считать. Нет идей? :)
Если мы говорим о вашем алгоритме "в лоб", то вам нужно считать ровно столько же таблиц. Только если хранить в памяти только участок 0-90 градусов, то требования к памяти можно уменьшить в 4 раза.
Если же говорить об алгоритме синтеза по таблице, то предпросчитанная таблица к частоте дискретизации не привязана никак вообще. От частоты дискретизации зависит только величина инкремента аккумулятора. Поэтому таблица всего одна для любой частоты.
От этого генерируемая частота не изменится. Максимум появятся гармоники.
Да, я знаю, что аккумулятор может быть целочисленный и так даже удобнее.
Просто не стал уже вдаваться в детали :)
Генерируемая частота и её значение зависят только от микроконтроллера, который её генерирует. "Акустическая система воспроизведения" на это никак не влияет.
А если бы вспомнили школьный курс, то достаточно было бы хранить в 4 раза меньше семплов. Так как достаточно хранить только половину полупериода - вторая половина полупериода точно такая же, а второй полупериод в точности равен первому, только с другим знаком.
Как уже было справедливо указано - все частоты целые, поэтому период в любом случае не может быть больше 1 сек
16 вариантов по 1 сек. При частоте семплирования 32кГц и разрядности 16 (дикий оверкилл, на самом деле) получаем 1МБ. А если вспомнить, что вторая половина каждого записи ровно симметрична первой половине, до 512кБ. Для современных контроллеров вполне терпимо.
Но. В любом случае это решение в лоб и так не делают. А делают синтез по таблице.
То есть имеем одну единственную таблицу для значений синуса от 0 до 90 градусов. Как показывает практика обычно 64 точки более чем достаточно. То есть получаем 256 точек на период.
Для каждой генерируемой частоты имеем аккумулятор, который для каждого следующего выходного семпла увеличивается на величину:
генерируемая частота / частоту дискретизации * количество семплов в таблице
Тогда целая часть этого аккумулятора будет номер семпла в таблице, а дробная - определяет с какой пропорцией надо взять этот и следующий семплы для интерполяции. Синус - функция гладкая, поэтому вполне достаточно линейной интерполяции.
Повторяем для всех частот, которые надо сгенерировать, суммируем полученные значения и выдаём на выход.
Всё, простейший табличный синтез.
Побочный вопрос. В тексте функции я вижу прописана
model="gpt-3.5-turbo"Есть ли смысла переходить на 4.0 и если есть, то как это сделать - просто поменять имя модели в функции на gpt-4.0 ?
Всё, с помощью автора разобрался, мой косяк - забыл исправить get на post в конфигурации шлюза. Работает
Спасибо. Я просто вбил всё одной строкой и поменял в data одиночные кавычки на двойные - насколько я помню они транслируются в одиночные. Но попробовал и ваш вариант. Получил Webhook is already set. Но всё равно ничего не работает.
Проверил статус через getWebhookInfo. Всё выглядит правдоподобно:
"result":{"url":"https://xxx.apigw.yandexcloud.net","has_custom_certificate":false,"pending_update_count":13,"last_error_date":1697555723,"last_error_message":"Wrong response from the webhook: 405 Method Not Allowed","max_connections":40,"ip_address":"xx.xx.xx.xx"}
Похоже проблема где-то до этого
Почувствовал себя обезьянкой, нажимающей на кнопочки по листочку.
Посоветуйте - где, что и как проверять если всё вроде сделал по мануалу, а всё равно не работает. У меня есть подозрение, что синтаксис curl в винде несколько не такой, как описано. Но я что мог поправил, получил в ответ: {"ok":true,"result":true,"description":"Webhook was set"} , но всё равно ничего не работает :)
Вот кстати никогда не понимал - на хрена было матрице симулировать "реальность"? Сделайте в реальном мире общаги на 4 койки, работу забойщиком угля и еду из макарон и витаминных добавок. И как альтернатива - капсулы с VR. Так туда ломанутся разве что не все "добровольно и с песней". Всегда очень хорошо понимал Сайфера :)
Ага, не греет. На старом 412ом москвиче привод вентилятора был прямой от двигателя. Поэтому единственным способом не закипать в пробках на жаре было включить печку на полную мощность. В салоне творился просто ад, несмотря на открытые окна.
Вот что надо запатентовать :)
Проблема в том, что разработка медицинских средств - это огромные деньги. И чтобы их получить есть два пути - конкурентный и защищенный копирайтами рынок / получение денег у государственных фондов.
Убираем копирайт - получаем невозможность "отбить" затраченные деньги -> в разработку никто не будет вкладываться -> нет новых лекарств, что потенциально обозначает еще больше смертей.
С финансированием государством всё еще хуже, это мы в СССР проходили.
А по топику - крайне странный выбор точки входа. Уже то, что болезнь массовая, а более-менее работающий сенсор смогли сделать только считанные фирмы, должно было насторожить, нет?
Мммм. А разве сейчас по умолчанию не NAT? И на одном внешнем IP адресе может спокойно висеть пара сотен компов. Или всё-таки реальный внешний адрес дают каждому пользователю (пусть и диначмический)?
Насчет резистентности современных вирусов к ацикловиру - согласен - сам маялся почти месяц с опоясывающим лишаем (к счастью в весьма легкой форме), ацикловир не помогал вообще. Врач вообще был не в курсе альтернатив. Сам догуглил до фамцикловира, который всё прибил за неделю. Но вот насчет конкретно Алпизарина - что-то я глубоко сомневаюсь. Чтобы какой-то левый медцентр, занимающийся практически исключительно продажей экстрактов растительного происхождения нашёл что-то реально антивирусное... Не, чудеса бывают. Наверное. Но в данном случае - не верю.