Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 88
Шикарно, для умного дома делаете?
Умный дом пока только в перспективе. Просто было интересно, как будет выглядеть распознавание речи при помощи микроконтроллера.
Хм… интересное решение, но куда более интересным было бы сделать без участия интернета а своими силами на МК, что система не была зависима от интернета.
Успехов :).
Есть делать систему под конкретного человека, то это достаточно легко, надо просто записать набор команд и делать сравнение записанной команды и того что слышим сейчас, если смотреть на применение системы относительно умного дома.
p.s. а за что минусы то?
p.s. а за что минусы то?
Минусы — за бред. Просто представьте на минутку, сколько нужно проделать работы и изучить матана, чтобы упихать распознавание речи на МК в одиночку. Это как собрать самолёт у себя в гараже из деталей со свалки (:
Простите но если мы говорим не об полноценном распозновании речи а о распозновании команд то тут хватит теории вероятности со 2 или 3 курса университета.
Работы тут на 1 день, качественный МК, запись команд на память, при произношении команды сравнение того что получили с вариантами команд и при заданной вероятности выполнение команды. При количестве команд в рамках разумного времени и мощности Мк потребуется не много.
Работы тут на 1 день, качественный МК, запись команд на память, при произношении команды сравнение того что получили с вариантами команд и при заданной вероятности выполнение команды. При количестве команд в рамках разумного времени и мощности Мк потребуется не много.
Если бы все было так просто, то мы бы уже давно с бытовой техникой разговаривали.
Разговор дело со всем другое, там требуется огромный словарь, что и вызывает основную сложность, ваш вариант очень интересный и я не спорю что это очень хороший результат я лишь говорю то что по моему без использования интернета было бы интересней.
И мой вариант требует большой и длительной настройки под каждого человека что в рамках серийного производство не позволительно.
И мой вариант требует большой и длительной настройки под каждого человека что в рамках серийного производство не позволительно.
для прототипа хватит качественного инженерного решения использующее сервис распознавания, но дальнейший шаг подразумевает локальное решение на случай если например инета не будет.
Как вариант — при первом включении попросить хозяина обучить устройство. В фильме «Двухсотлетний человек» насколько я помню было что-то подобное.
Ага. А к инструкции приложить трехтомник «Войны и мира», сборник собраний сочинений Солженицына и пару-тройку желтушных книжонок…
И научить МК работать 64-битными адресами и поддерживать оперативку на DDR3. И работать с жестким диском.
И научить МК работать 64-битными адресами и поддерживать оперативку на DDR3. И работать с жестким диском.
достаточно раза 3 повторить команду, а дальше как написали выше матан, но есть ошибка, для заданных команд и действий и не слов и букв подойдет стандартная теория вероятности которая на 2 или 3 курсе университета, и большой мощности МК не потребуется
Мы, вообще-то, о распознавании речи говорим, а не о двух-трех командах…
Вообще то о распозновании речи к умному дому, т.е распозвании команд для системы и о разумном количестве команд это ну до 1000 где то. а не 2 или 3
Вы хотите 1000 команд записать сами? И где их все хранить?
1000 команд — это уже не 2-3. Здесь простой «слепок» не подойдет: слишком много информации хранить придется. Так что, либо пилить полноценную распознавалку, либо сохранять все на объемной флешке и не пенять устройство за «тугодумство».
обьемная флешка не потребуется я думаю что команда будет весить больше сотни кбайт, а если ввести умный поиск то он будет не долгий)
Да Мк потребуется приличный 8 битные AVR не подойдут на Cortex M3 я думаю, спокойно можно сделать)
Вообще спор меня за интриговал, и я подумываю реализовать это) ну или пробовать) но боюсь не скоро смогу… завал на работе) как сделаю отпишусь)
Да Мк потребуется приличный 8 битные AVR не подойдут на Cortex M3 я думаю, спокойно можно сделать)
Вообще спор меня за интриговал, и я подумываю реализовать это) ну или пробовать) но боюсь не скоро смогу… завал на работе) как сделаю отпишусь)
А ведь вместо кнопки можно сделать пороговый детектор…
Если я правильно вас понял, то не на весь шум будет срабатывать, после отправки запроса, вы получаете данные такие как, % распознания и вы можете отсеивать посторонние и не распознанные звуки.
Значение точности распознавания действительно передается. Только из-за шума возможно большое количество лишних запросов, при этом во время передачи запроса и ожидания ответа запись невозможна.
При этом главная проблема детектора звука — первые звуки слова теряются.
При этом главная проблема детектора звука — первые звуки слова теряются.
Я делал алгоритм на запись звука используя технологию Google и добился записи звука и первых звуков.Могу поделиться, если требуется, но вы я думаю и так знаете как это сделать.
Как вариант, можно анализировать уровни сигнала с микрофона и время.
Например если был высокий уровень в течении 100мс, а потом низкий уровень 500мс, то это просто помеха или был сигнал более 100мс, а потом пауза 800мс, то из сигнала вычитаю 800мс и отправляю его на конвертирование.
Например если был высокий уровень в течении 100мс, а потом низкий уровень 500мс, то это просто помеха или был сигнал более 100мс, а потом пауза 800мс, то из сигнала вычитаю 800мс и отправляю его на конвертирование.
Забавная игрушка.
Почему-то мне кажется, что эта плата может распознавать звук и сама, без гугла. 168МГц + элементы DSP — это нешуточная вычислительная мощность.
Почему-то мне кажется, что эта плата может распознавать звук и сама, без гугла. 168МГц + элементы DSP — это нешуточная вычислительная мощность.
Думаю, что максимум голосовые команды, да и то после предварительной записи.
Минимум придётся портировать существующий софт с сорцами, если таковой имеется. Причём, DSP здесь не сильно поможет: тут больше не обработка сигнала будет грузить ядро, а алгоритм распознавания. Ну, а если софта нет, тогда лучше запастись зубами — грызть гранит науки придётся долго и усердно.
В реальном времени — очень вряд ли.
И потом, написать самому софт нереально, а существующий должен крутиться на какой-то оси.
И потом, написать самому софт нереально, а существующий должен крутиться на какой-то оси.
Интересно, спасибо.
Особенно пригодятся примеры, т.к. такая плата имеется, но ничего серьёзного именно на F4 не собирал. Просто дороговаты контроллеры сами по себе.
И вопрос: почему не использовали имеющийся там Ethernet? А то модуль дороже самой платы выходит.
Особенно пригодятся примеры, т.к. такая плата имеется, но ничего серьёзного именно на F4 не собирал. Просто дороговаты контроллеры сами по себе.
И вопрос: почему не использовали имеющийся там Ethernet? А то модуль дороже самой платы выходит.
Для построения «умного дома», в той части, где нужно распознавать речевые команды, можно воспользоваться вот такой штуковиной — EasyVR (Multi-language speech recognition module with serial interface)
www.tigal.com/product/1770
Можно запрограммировать платку на 32 голосовые команды.
www.tigal.com/product/1770
Можно запрограммировать платку на 32 голосовые команды.
Попробовал speech api.
Фраза «accessing google speech api» распозналась как «texas in google speech be».
Я бы не стал в свой дом засовывать такую штуку… А то ещё включит плиту вместо телевизора.
Фраза «accessing google speech api» распозналась как «texas in google speech be».
Я бы не стал в свой дом засовывать такую штуку… А то ещё включит плиту вместо телевизора.
Так а чеж вы с ним на не родном языке говорите, попробуйте на русском, процент успешного распознования значительно улучшится.
Хм, а ссылочку не дадите? Я только english нашёл.
Вроде как вот тут про переключение языка написано.
Увидев в названии статьи довольно мощный DSP, подумал, что обнаружу в ней реализацию собственно распознавания.
168 мегагерц DSP жмут чужим кодеком и распознаются чужим ПО на облачном сервере, ну ладно… Но передавать данные через привешенную на проводах платку уарт-усб, имея на борту USB-контроллер, это, простите, моветон.
168 мегагерц DSP жмут чужим кодеком и распознаются чужим ПО на облачном сервере, ну ладно… Но передавать данные через привешенную на проводах платку уарт-усб, имея на борту USB-контроллер, это, простите, моветон.
*простите, следует читать "168 мегагерц DSP жмут аудиоданные чужим кодеком, которые распознаются чужим ПО"
Но-но, не пинайте так автора. Во-первых, ковырять и отлаживать USB или UART — две большие разницы (вы в курсе, я думаю). Во-вторых, для прототипа и проекта «для поиграться» результат всё равно хороший.
Да, я тоже ожидал увидеть матан и прочие потроха алгоритма распознавания… Ну что ж поделать, я автора прекрасно понимаю: я сам недавно начал писать драйвер SD-карт, но потом подзабросил, ибо дофига рутины и отладки (и вообще это нудятина), а выхлоп мизерный — можно взять готовый шмат чужого говнокода, который уже работает, а свой писать да отлаживать никаких мотивации и времени не хватает.
Впрочем, я когда-нибудь к своему драйверу вернусь, и надеюсь, что автор когда-нибудь зафигачит распознавание на самом МК. Это будет настоящий подвиг (:
Да, я тоже ожидал увидеть матан и прочие потроха алгоритма распознавания… Ну что ж поделать, я автора прекрасно понимаю: я сам недавно начал писать драйвер SD-карт, но потом подзабросил, ибо дофига рутины и отладки (и вообще это нудятина), а выхлоп мизерный — можно взять готовый шмат чужого говнокода, который уже работает, а свой писать да отлаживать никаких мотивации и времени не хватает.
Впрочем, я когда-нибудь к своему драйверу вернусь, и надеюсь, что автор когда-нибудь зафигачит распознавание на самом МК. Это будет настоящий подвиг (:
прикольно, а я такой драйвер для sd карточек как раз только что закончил более-менее :)
Делитесь сорцами. Если они не привязаны к железу, я бы на STM32 с радостью потестил, да и вообще можно совместно пилить проект, если там осталось что-то (:
Я, кстати, исключительно по спекам драйвер пилю (SD Specifications Part 1 Physical Layer Simplified Specification Version 3.01).
Я, кстати, исключительно по спекам драйвер пилю (SD Specifications Part 1 Physical Layer Simplified Specification Version 3.01).
Да, я как раз по официальным спекам и сделал. Делаю это для STM32F217.
Из примеров, которые можно найти в инете толкового ничего не нашёл. Сделал сам, нормально детектируются/инициализируются и читаются/пишутся карты SDSC и SDHC — у меня тут их горсть целая (правда 8 гиг всего самая «большая»). Скоро вот раздобуду 64 гиг и проверю что у такой SDXC карточки записано в регистрах CSD & SCR…
Возможно нужно будет немного подкрутить тайминги, меня вообще сильно удивило насколько карточки различаются по скорости — FTL кое-где вообще плохо реализован.
Да, чуть не забыл, всё это у меня для шины SPI, есть в планах сделать нормальный SDIO 4-х пиновый чтоб выжимать максимум скорости и ещё задействовать DMA чтобы проц не грузить.
Мне интересно если бы кто-то потестил на разных картах — может что ещё поправить надо будет.
Из примеров, которые можно найти в инете толкового ничего не нашёл. Сделал сам, нормально детектируются/инициализируются и читаются/пишутся карты SDSC и SDHC — у меня тут их горсть целая (правда 8 гиг всего самая «большая»). Скоро вот раздобуду 64 гиг и проверю что у такой SDXC карточки записано в регистрах CSD & SCR…
Возможно нужно будет немного подкрутить тайминги, меня вообще сильно удивило насколько карточки различаются по скорости — FTL кое-где вообще плохо реализован.
Да, чуть не забыл, всё это у меня для шины SPI, есть в планах сделать нормальный SDIO 4-х пиновый чтоб выжимать максимум скорости и ещё задействовать DMA чтобы проц не грузить.
Мне интересно если бы кто-то потестил на разных картах — может что ещё поправить надо будет.
По поводу UART — это очень быстрое и простое решение. Использовать встроенный USB я умею, вот только не известно, как прерывания от USB (а при наличии соединения с компьютером они есть всегда), будут влиять на работу программы, в частности на запись сигнала.
По поводу распознавания на контроллере — в свое время экспериментировал с распознаванием голосовых команд при помощи голосового движка от Micosoft. Запускалось оно на Pentium 133 MHz под win2k (А ведь это помощней контроллера будет — там и математический сопроцессор, и ОЗУ много, и диск есть). Движок приходилось более получаса обучать, перед началом распознавания надо было указать, какие команды будут ожидаться. И все равно распознавание работало некачественно, очень часто определялось не то слово.
По поводу распознавания на контроллере — в свое время экспериментировал с распознаванием голосовых команд при помощи голосового движка от Micosoft. Запускалось оно на Pentium 133 MHz под win2k (А ведь это помощней контроллера будет — там и математический сопроцессор, и ОЗУ много, и диск есть). Движок приходилось более получаса обучать, перед началом распознавания надо было указать, какие команды будут ожидаться. И все равно распознавание работало некачественно, очень часто определялось не то слово.
Так это и есть то, что делает проект интересным и отличающимся от тонн подобных игрушек.
Использовать DMA для считывания сигнала с микрофона, например. Описать ваше решение.
Это и придало бы весу статье.
Куда интереснее прочесть про реализацию распознавания, пусть и не такого качественного, как у гугла, чем сотую вариацию на тему «послать данные всемогущему облаку».
Между прочим, есть проект распознавания на АВРке — некачественное, конечно, на уровне команд а не распознавания слов, но все же. На 16-мгц 8-бит АВРке. А тут целый ДСП. Интересно поглядеть на то, как он справится с такими задачами.
Использовать DMA для считывания сигнала с микрофона, например. Описать ваше решение.
Это и придало бы весу статье.
Куда интереснее прочесть про реализацию распознавания, пусть и не такого качественного, как у гугла, чем сотую вариацию на тему «послать данные всемогущему облаку».
Между прочим, есть проект распознавания на АВРке — некачественное, конечно, на уровне команд а не распознавания слов, но все же. На 16-мгц 8-бит АВРке. А тут целый ДСП. Интересно поглядеть на то, как он справится с такими задачами.
Да, справедливости ради замечу — с практической точки зрения ваша реализация (за исключением USB, это все-таки нужно любыми способами привести в норму, чтобы избавиться от переходника) наверняка куда более ценна, нежели свои велосипеды по распознаванию — потому что, все таки, мелкой ДСП плате тягаться с гугловскими серверами и алгоритмами бессмысленно. И в используемом продукте я бы сам выбрал такой же вариант, потому что важен результат. Так что девайс у вас хороший (только USB прикрутите =) )
А вот статья, конечно, была бы более интересна про реализацию распознавания, очень уж хочется почитать отзывы тех, кто эту DSPшку пощупал с этой точки зрения.
Да, а вы не касались правового вопроса? Допустим вот вы решите производить свою систему умного дома (гипотетическая ситуация) — что в этом случае говорит гугл относительно использования своего сервиса, это приемлемо?
А вот статья, конечно, была бы более интересна про реализацию распознавания, очень уж хочется почитать отзывы тех, кто эту DSPшку пощупал с этой точки зрения.
Да, а вы не касались правового вопроса? Допустим вот вы решите производить свою систему умного дома (гипотетическая ситуация) — что в этом случае говорит гугл относительно использования своего сервиса, это приемлемо?
Правовой вопрос совершенно не рассматривал, так как даже и в мыслях не было что-то продавать. Кроме того, Google может в любой момент изменить протокол связи, так что устройство можно применять только на свой страх и риск.
По правде сказать, UART используется только для демонстрации работы контроллера — во время программирования и отладки я использовал semihosting, а UART — USB преобразователь я активно использовал при отладке работы WIFI-модуля — только так можно наблюдать, как идет процесс обмена данными с контроллером.
USB — это хорошо, но без компьютера бессмысленно. Если я буду делать устройство, действительно являющееся частью умного дома, то компьютера там не будет, и весь код для USB придется выкинуть.
Если уж кому-то и нужны примеры для работы с USB на STM32F4, то можно посмотреть здесь:
Ссылка.
Между прочим, в этом проекте ресурсы контроллера достаточно активно используются — кодирование звука при помощи Speex требует большого числа операций, да и памяти тоже требуется немало, поскольку только кодек использует 7 КБ, а еще есть аудиобуферы, буферы приема информации wifi модуля. Так что на STM32-Discovery запустить не удастся. Такое потянет отладочная плата с установленной stm32f103, но у меня ее нет, да и стоят они достаточно дорого.
По правде сказать, UART используется только для демонстрации работы контроллера — во время программирования и отладки я использовал semihosting, а UART — USB преобразователь я активно использовал при отладке работы WIFI-модуля — только так можно наблюдать, как идет процесс обмена данными с контроллером.
USB — это хорошо, но без компьютера бессмысленно. Если я буду делать устройство, действительно являющееся частью умного дома, то компьютера там не будет, и весь код для USB придется выкинуть.
Если уж кому-то и нужны примеры для работы с USB на STM32F4, то можно посмотреть здесь:
Ссылка.
Между прочим, в этом проекте ресурсы контроллера достаточно активно используются — кодирование звука при помощи Speex требует большого числа операций, да и памяти тоже требуется немало, поскольку только кодек использует 7 КБ, а еще есть аудиобуферы, буферы приема информации wifi модуля. Так что на STM32-Discovery запустить не удастся. Такое потянет отладочная плата с установленной stm32f103, но у меня ее нет, да и стоят они достаточно дорого.
Это на DSP, это лишь дополнительный набор DSP инструкций в ядре мк общего назначения.
Автору пожелание в усовершенствовании конструкции.
Чтобы не остаться без такой полезной штуки если отключится интернет, воткните в порт USB( у этого контроллера вроде есть поддержка хоста) модем типа «свисток» и будет у вас резервный GPRS/EDGE/3G канал в интернет.
Плюсов огромное количество:
— опыт работы с usb хостом
— опыт запуска TCP/IP
— реверс инджениринг протокола свистка
— занятие простаивающих ресурсов контроллера чем-то полезным
— статья на хабре :-)
Чтобы не остаться без такой полезной штуки если отключится интернет, воткните в порт USB( у этого контроллера вроде есть поддержка хоста) модем типа «свисток» и будет у вас резервный GPRS/EDGE/3G канал в интернет.
Плюсов огромное количество:
— опыт работы с usb хостом
— опыт запуска TCP/IP
— реверс инджениринг протокола свистка
— занятие простаивающих ресурсов контроллера чем-то полезным
— статья на хабре :-)
Вижу уже не первую подобную статью где используется серве Google для распознавания речи.
Много любителей есть также прикрутить Google к Аsterisk серверу.
Но зачем гонят столько трафика, напрягать Гугле такой ерундой.
Почему-то никто не может предложить использовать, например, CMU Sphinx, песплатный, есть русские акустические и лингвистические модели готовые. Для умного дома тем более у вас ограниченный набор фраз/команд, а не спонтанное распознование как делает Google.
Много любителей есть также прикрутить Google к Аsterisk серверу.
Но зачем гонят столько трафика, напрягать Гугле такой ерундой.
Почему-то никто не может предложить использовать, например, CMU Sphinx, песплатный, есть русские акустические и лингвистические модели готовые. Для умного дома тем более у вас ограниченный набор фраз/команд, а не спонтанное распознование как делает Google.
Чёта с каждым новым сервисом гугла становится всё сыкатней и сыкатней. Понастроишь таких умных домов, потом дыц — америкосы решат, что пора — и каюк. Придёшь домой — а он тебе «ты кто такой? досвиданья» ;)
Автор молодец. Но для умного дома, считаю, надо делать автономные сервисы, ну кроме если тольно внешнего управления.
Автор молодец. Но для умного дома, считаю, надо делать автономные сервисы, ну кроме если тольно внешнего управления.
Я уж думал и в правду на F4 речь распознают, а тут облом. Но всё равно интересно, работы тоже проделана не малая. Спасибо.
Я тоже думал, что кто-то либо изобрел мегаИИ, впендюривающийся в скудную оперативку, обслуживаемую МКшкой, или построил вокруг контроллера полноценный компьютер…
Хотя, если взять ARM…
Хотя, если взять ARM…
>>Хотя, если взять ARM…
По вашему взят AVR?
По вашему взят AVR?
Мы тут умудрились на SoC с CPU 20 Mhz + 48 Kb RAM + n Gb NAND flash запихать:
— реляционную базу данных (полный CRUD-фарш с индексами, joins, транзакциями)
— веб-сервер с сервлетами на JavaCard (правда эта жава самое узкое место во всём этом)
И на этом добре крутится вполне приличное веб-приложение.
Собственно самая алгоритмически навороченая часть ( БД ) занимает всего 8 Kb RAM!
Тормозов не наблюдается, в полутора десятках таблиц хранится около ста тысяч записей в каждой.
Так что распознавалку сделать можно если сильно напрячься…
Но я как и многие подумал что в статье пишут как кто-то этого добился :)
— реляционную базу данных (полный CRUD-фарш с индексами, joins, транзакциями)
— веб-сервер с сервлетами на JavaCard (правда эта жава самое узкое место во всём этом)
И на этом добре крутится вполне приличное веб-приложение.
Собственно самая алгоритмически навороченая часть ( БД ) занимает всего 8 Kb RAM!
Тормозов не наблюдается, в полутора десятках таблиц хранится около ста тысяч записей в каждой.
Так что распознавалку сделать можно если сильно напрячься…
Но я как и многие подумал что в статье пишут как кто-то этого добился :)
Поправлю автора: распознавание голоса и распознавание речи — разные задачи.
Распознавание голоса — определение человеческого голоса среди других звуков (то есть задача — определить, что человек что-то сказал и отреагировать).
Распознавание диктора — определение персоны человека по голосу среди других людей.
Распознавание речи — расшифровка аудиосигнала, перевод речи в текст.
Распознавание голоса — определение человеческого голоса среди других звуков (то есть задача — определить, что человек что-то сказал и отреагировать).
Распознавание диктора — определение персоны человека по голосу среди других людей.
Распознавание речи — расшифровка аудиосигнала, перевод речи в текст.
По поводу шума — можно попробовать фильтровать данные по частоте и амплитуде — например после записи делать бпф — резать все частоты, не попадающие в интервал человеческого голоса, а также частоты, которые ниже порога определенного
Позволяет ли данный WIFI-модуль RN-171 принимать и передавать потоковое аудио?
В каком смысле?
Если вы о программной передаче — то да, в принципе может. Правда, качество звука будет зависеть от выбранного протокола.
Как раз на базе той же STM32F4-Discovery и RN-171 я делал WIFI радиоприемник, способный принимать данные с серверов Shoutcast. Приемник работал, но иногда звук прерывался или обрывалась связь с сервером, причем была явная зависимость качества звука от расстояния до роутера(при большем расстоянии становится больше потерь пакетов). Если бы я смог узнать, как управлять потоком в Shoutcast, то может быть, удалось бы добиться лучшего качества.
Как раз на базе той же STM32F4-Discovery и RN-171 я делал WIFI радиоприемник, способный принимать данные с серверов Shoutcast. Приемник работал, но иногда звук прерывался или обрывалась связь с сервером, причем была явная зависимость качества звука от расстояния до роутера(при большем расстоянии становится больше потерь пакетов). Если бы я смог узнать, как управлять потоком в Shoutcast, то может быть, удалось бы добиться лучшего качества.
Да, есть желание тоже сделать wi-fi интернет-радио с софтовым декодированием mp3 или aac потока на Cortex M3/M4. Если не жалко, очень хотелось бы взглянуть на исходники вашего проекта. Ещё вопрос, хватит ли у RN-171 пропускной способности и скорости стека для обработки хотябы 92 кбит\с звука. Протокол tcp-ip.
К сожалению, я не смог запустить последнюю версию программы на DISCOVERY, так что пока не могу выложить исходники. Я постараюсь разобраться, из-за чего не работает проект и выложу его, как только смогу.
Я использовал декодер mp3 вот отсюда: jjmz.free.fr/?p=65
У меня звук воспроизводился на скорости 128 кбит/с. Однако, как я уже говорил выше, модуль работает на пределе возможностей, так что при слабом сигнале поток прерывается и соединение может разрываться.
Я использовал декодер mp3 вот отсюда: jjmz.free.fr/?p=65
У меня звук воспроизводился на скорости 128 кбит/с. Однако, как я уже говорил выше, модуль работает на пределе возможностей, так что при слабом сигнале поток прерывается и соединение может разрываться.
Спасибо за помощь, пробовал портировать декодер helix но стабильной работы не получил пока. Может проблема была в антенне? А если внешнюю использовать?
Заказал себе WiFly Module, ждёмс.
Заказал себе WiFly Module, ждёмс.
Я пробовал подпаивать антенну от роутера, немного получше стало, но проблемы остались, так что отпаял ее.
Нашел ошибку в программе, исправил ее, так что приемник запустился.
Ссылка на исходники: ссылка
Вот пример работы приемника:
Ссылка на исходники: ссылка
Вот пример работы приемника:
Выглядит очень неплохо) Кстати, в wi-fi модуле есть команда переключения антенны set wlan ext_antenna. По умолчанию включена внутрення чип-антенна (параметр равен 0). В данной модификации её нет и этот параметр должен быть при инициализации установлен в 1. Связь нестабильна т.к. фактически ваша RN-XV сейчас работает без неё. Модификация с разъёмом SMA кажется более практичной, антенну можно скрутить, например, со старого роутера :)
По поводу команды цитата из даташита: «This command applies only to RN-131. This command is not applied to the RN-171. Issuing this command on the RN-171 will give an error message: ERR: Bad Args».
У нас RN-171 и чип-антенны в нем нет. Так что 0 в данном случае — это внешняя антенна. Когда я перепаивал антенну, то в определенный момент ее контакт отошел, и модуль перестал работать, что свидетельствует о том, что используется именно внешняя антенна.
У нас RN-171 и чип-антенны в нем нет. Так что 0 в данном случае — это внешняя антенна. Когда я перепаивал антенну, то в определенный момент ее контакт отошел, и модуль перестал работать, что свидетельствует о том, что используется именно внешняя антенна.
А под какой средой писался проект? Вроде где-то coocox проскакивал в конфигах.
P.S. все сообщения в этом топике написаны по просьбе инженера-разработчика. Если у кого есть возможность — пришлите инвайт f_i_l_i_n@list.ru
P.S. все сообщения в этом топике написаны по просьбе инженера-разработчика. Если у кого есть возможность — пришлите инвайт f_i_l_i_n@list.ru
Да, под Coocox. Это связано с тем, что проект был написан на основе этого: jjmz.free.fr/?p=65, а там используется компилятор ARM GCC. Я пробовал скомпилировать код в IAR, но столкнулся с тем, что в IAR совершенно другой обработчик ассемблера.
а вот вы бы ещё библиотеки юсб прикрутили от stm), чтоб можно было не только через блютуз передавать
Это вы вообще к чему? Какой bluetooth?
тьфу, то есть вайфай), это я заработался, это я через блютуз тут передаю)
Ну а USB то куда приделать?
сжатую инфу в комп перегонять, а там можно уже декодировать и преобразовать в wav файл, в контейнере ogg
А смысл? Если есть компьютер, то он сам с чем угодно справится, и контроллер уже не нужен.
ну там же не только звук может писаться, а ещё куча другой инфы и всё на одной платформе, а на компе прога которая всё эту инфу перерабатывает. Или возможно даже в raw писать и по USB сбрасывать, а уже не компе файл формировать, там кстати если я не ошибаюсь ogg контейнер только для сжатых данных speex нужен, а в wav уже могут быть сырые данные. Да вроде так.
Известны ли кому ASIC чипы, которые аппаратно преобразует потоковый двухканальный pdm в pcm? Чтобы прям готовый i2s выходил наружу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Распознавание речи на STM32F4-Discovery