TB-03F TLSR8253 - кто-нибудь пробовал "звуковые" возможности?

[aloika]

Еще такие вопросы, на общую эрудицию, вдруг кто сталкивался.
Сейчас у меня звук идет в TLSR с PDM-микрофона, в целом всё работает. Помехи, связанные с питанием и с rf-частью удалось устранить. Эти помехи были периодические, характерные и в принципе было понятно, чем они вызваны.

Но остался еще на слух белый шум, который непонятно откуда берется и непонятно что с ним делать. Он не сказать, что сильно громкий по сравнению с сигналом, но слышимый отчетливо. Откуда он может браться? От самого PDM-микрофона? А может, это adpcm-кодирование/раскодирование добавляет? Может быть такое?

Я этот шум записал, разложил по частотам в Audacity - ну да, по всем частотам от 50 Гц и до 10 кГц он.

Что еще делал: менял частоту PDM-микрофона - не особо влияет, шум остается. Включал/выключал FLD_DOUBLE_DOWN_SAMPLING_ON - тоже не особо что-то меняется. Включал фильтры, которые в SDK есть - слышно, что фильтры работают, но шум на то и белый, что простыми фильтрами не фильтруется. Есть еще в SDK какой-то static inline int noise_supression (s16 md), включал, никакой разницы вообще не заметил.

Пробовал два разных PDM-микрофона (разных моделей) - разница несущественная в плане этого шума.

 

[aloika]

Из идей: надо бы попробовать несжатый звук передать (но хватит ли пропуской способности, не знаю) - проверить, не сжатие ли это влияет.
Еще есть I2S микрофон у меня, его попробовать подключить (пока не знаю, как именно, но вроде что-то такое в SDK есть).

 

[pvvx]

А может, это adpcm-кодирование/раскодирование добавляет?

Низкая дискретизация и adpcm - .
"Как правило, адаптация к статистике сигнала в ADPCM состоит просто из адаптивного коэффициента масштабирования перед квантованием разницы в кодере DPCM".
И если там впихнуто mu-law или A-law - то "это система логарифмического сжатия, в которых 13- или 14-битный номер выборки линейной ИКМ преобразуется в 8-битное значение"
Что естественно ведет к дополнительному шуму.

 

[pvvx]

Из идей: надо бы попробовать несжатый звук передать (но хватит ли пропуской способности, не знаю) - проверить, не сжатие ли это влияет.
Еще есть I2S микрофон у меня, его попробовать подключить (пока не знаю, как именно, но вроде что-то такое в SDK есть).

Достаточно взять нормальную запись, перекодировать в аналогичный формат на компе и прослушать.

 

[pvvx]

Я нашел список телефонов, совместимых c coded phy

С простым то BLE (именно с Bluetooth Le) Linux был испорчен в Kernel после версии 3.17.
Kernel <3.17: 20 seconds timeout for BLE connections.
Kernel >=3.17,<4.16: added a timeout of 2 seconds for BLE auto-connections: torvalds/linux@09ae260
Kernel >=4.16: raised previous timeout to 4 seconds: torvalds/linux@1f01d8b (https://lists.ubuntu.com/archives/kernel-team/2017-November/088166.html)
А тут ещё телефоны и WiFi

 

[pvvx]

Wifi ESP - это 20dBm , что дает увеличение дальности в 2 и более раз по сравнению с TLSR или ESP_BLE.

И самая низкая надежность - частые выпадения из сети у ESP (не соединения с AP, а внутренние глюки с IP и сокетами, возможно из-за организации Heap):

Из-за программного перенаворота с IP и сокетами в малом SoC.
Потом все журналы в красных полосочках:
2022-01-29 02:58:43 ERROR (MainThread) [custom_components.localtuya.common] [bf4...u9u] Connect to 192.168.2.23 failed
Хотя другие, ещё 5-ть розеток с WiFi имеют значительно меньше выпадений.

Т.е. без громадного буфера и большой задержки для буферизации WiFi не годится для передачи "живого" звука...

 

[nikolz]

И самая низкая надежность - частые выпадения из сети у ESP (не соединения с AP, а внутренние глюки с IP и сокетами, возможно из-за организации Heap):
Посмотреть вложение 11798
Из-за программного перенаворота с IP и сокетами в малом SoC.
Потом все журналы в красных полосочках:
2022-01-29 02:58:43 ERROR (MainThread) [custom_components.localtuya.common] [bf4...u9u] Connect to 192.168.2.23 failed
Хотя другие, ещё 5-ть розеток с WiFi имеют значительно меньше выпадений.

Т.е. без громадного буфера и большой задержки для буферизации WiFi не годится для передачи "живого" звука...

вообще-то, ESP я привел как пример Wifi с 20 dBm.
Если не нравиться ESP, можете взять другой чип с 20 dBm.
Вне зависимости как Вы обзываете протокол WiFi или BLE, дальность связи зависит от бюджета канала.
У BLE чипов мощность обычно 0 dBm т е в 100 раз меньше , чем у ESP Wifi.
Если у Вас много помех в эфире в деревне, то BLE даст дополнительный выигрыш за счет более узкой полосы.
Но так как речь идет о расстоянии в 10 метров и поглощении стенами, то дальность у WiFi больше исключительно из-за бюджета канала и пути прохождения сигнала.
Протокол не имеет никакого значение и тем более не влияет потребляемый ток от батарейки на дальность связи.

 

[nikolz]

Еще такие вопросы, на общую эрудицию, вдруг кто сталкивался.
Сейчас у меня звук идет в TLSR с PDM-микрофона, в целом всё работает. Помехи, связанные с питанием и с rf-частью удалось устранить. Эти помехи были периодические, характерные и в принципе было понятно, чем они вызваны.

Но остался еще на слух белый шум, который непонятно откуда берется и непонятно что с ним делать. Он не сказать, что сильно громкий по сравнению с сигналом, но слышимый отчетливо. Откуда он может браться? От самого PDM-микрофона? А может, это adpcm-кодирование/раскодирование добавляет? Может быть такое?

Я этот шум записал, разложил по частотам в Audacity - ну да, по всем частотам от 50 Гц и до 10 кГц он.

Что еще делал: менял частоту PDM-микрофона - не особо влияет, шум остается. Включал/выключал FLD_DOUBLE_DOWN_SAMPLING_ON - тоже не особо что-то меняется. Включал фильтры, которые в SDK есть - слышно, что фильтры работают, но шум на то и белый, что простыми фильтрами не фильтруется. Есть еще в SDK какой-то static inline int noise_supression (s16 md), включал, никакой разницы вообще не заметил.

Пробовал два разных PDM-микрофона (разных моделей) - разница несущественная в плане этого шума.

Если шум белый, то сделайте его розовым. Для этого надо поставить не цифровой, а аналоговый фильтр.

 

[nikolz]

Не работает.
Стена - дерево, утеплитель и железный экран от камина.
Через эту стенку впихнута розетка с WiFi. До роутера 3 метра по прямой через эту стенку. Роутер там Кинетик - внешне-многоантенный. Фигу стабильно работет - уровень сигнала ужасен.
Но термометр с BLE около этой розетки и уровнем TX всего +0Дб пробивает это дело без потерь - в роутер воткнут шлюз BLE без внешних антенн.
Так что ваши критерии не всегда работают.

Вы используйте экран от камина в качестве антенны.

 

[pvvx]

Протокол не имеет никакого значение и тем более не влияет потребляемый ток от батарейки на дальность связи.

Протокол имеет первостепенное значение для реал-тайм систем и передачи звука.
В сетях IP при загрузке пусть пакетами VOIP или другими с приоритетом, ваши будут вытеснены на неопределенный срок и часто просто скипнуты если не влезли сразу в канал. Это одна беда, а вторая в ресурсоемкости реализации IP на малых SoC - они все страдают потерями и неадекватностями. В показанном примере - неадекватность поведения - перегрузка или нехватка динамической RAM в чипе без MMU и фрагментация, с итогом - невозможности открытия соединения, пока другие процессы не освободили фрагменты в памяти или чип не перезагрузился из-за естественного глобального сбоя (по архитектуре памяти).
И в данном случае Ротуер не зафиксировал обрыва связи с устройством, а сокет на нем не открывается.
Ещё одна беда реализаций на SoC типа ESP - TCP в TIME_WAIT. Т.к. соединения создаются практически по одним и тем-же портам и IP, то для открытия следующего такого-же с теми-же порт/ip требуется пауза в 120 сек, для ожидания затерявшихся пакетов и защиты соединения (чтобы вы не влезли в то-же соединение). Но конкретно ESP это дело скипает и лезет по тому-же порту, и долго удивляется что сервер ей шлет дубли закрытия соединения. И пока оно в такой стадии - какие ещё включения лампочек или передача звука?
Итог - нулевая надежность при использовании такого WiFi. Радио канал и не стоит уже учитывать,

 

[pvvx]

Вы используйте экран от камина в качестве антенны.

Проще заменить "вумную" розетку на ZigBee или BLE, что и проделано. Измеряет потребление компа и включает его удаленно, а переносить стены и обвешиваться проводами - тут на форуме есть такие увлеченные

 

[nikolz]

Протокол имеет первостепенное значение для реал-тайм систем и передачи звука.
В сетях IP при загрузке пусть пакетами VOIP или другими с приоритетом, ваши будут вытеснены на неопределенный срок и часто просто скипнуты если не влезли сразу в канал. Это одна беда, а вторая в ресурсоемкости реализации IP на малых SoC - они все страдают потерями и неадекватностями. В показанном примере - неадекватность поведения - перегрузка или нехватка динамической RAM в чипе без MMU и фрагментация, с итогом - невозможности открытия соединения, пока другие процессы не освободили фрагменты в памяти или чип не перезагрузился из-за естественного глобального сбоя (по архитектуре памяти).
И в данном случае Ротуер не зафиксировал обрыва связи с устройством, а сокет на нем не открывается.
Ещё одна беда реализаций на SoC типа ESP - TCP в TIME_WAIT. Т.к. соединения создаются практически по одним и тем-же портам и IP, то для открытия следующего такого-же с теми-же порт/ip требуется пауза в 120 сек, для ожидания затерявшихся пакетов и защиты соединения (чтобы вы не влезли в то-же соединение). Но конкретно ESP это дело скипает и лезет по тому-же порту, и долго удивляется что сервер ей шлет дубли закрытия соединения. И пока оно в такой стадии - какие ещё включения лампочек или передача звука?
Итог - нулевая надежность при использовании такого WiFi. Радио канал и не стоит уже учитывать,

Вопрос в том, что Вы конкретно хотите передать.
В данном случае, как всегда, вместо того, чтобы рассчитать и понять,
что можно получить, в ход идет ползучий эмпиризм и метод тыка.
Все же уже давно определено в документации VOIP.
Какой смысл в сотый раз убеждаться в правильности закона Ома?
Вам это интересно?

 

[nikolz]

дальность связи не зависит от протокола (речь идет о Wifi и BT,BLE).
Она зависит исключительно от бюджета канала связи.
Так как изначально WiFi предполагает более мощный передатчик чем BT, то при прочих равных условиях WiFi потенциально более дальнобойный.
---------------------
примеры:
ESP мощность передатчика WfiFi 100 мВт, а мощность модулей BT(BLE) 1...10 мВт.
---------------
В итоге имеем мощность WiFi в 10 -100 раз больше.
Это значит что дальность связи при прочих равных будет в 3-10 раз больше.
----------------
Далее на дальность связи влияет структура канала .
В Wifi связь конечных пользователей всегда через точку доступа, т е схема звезда.
В ВT(BLE не сеть) связь точка-точка.
Это значит , что в WiFi расстояние может быть в 2 раза больше при прочих равных условиях.
----------------------
Желающие это проверить могут провести эксперимент.
взять два модуля ESP и установить связь по ESP-NOW.
Это будет аналог BT(BLE) но с мощностью передатчика 100 мBт.
взять два модуля BLE и установить связь между ними.
И сравнить результаты.
================

 

[nikolz]

относительно передачи звука.
Дальность зависит от указанных выше параметров.
При увеличении дальности , сначала будет изменяться качество связи. т е будет связь, но с пропусками пакетов.
А вот на максимальной дальности связи не будет вообще.
Поэтому протокол связи не влияет на дальность связи.

 

[nikolz]

При организации передачи звука в локальной сети нет надобности разбивать звук на мелкие пакеты
Поэтому качественно передачу звука можно реализовать и на WiFi через любой протокол, например через UDP
----------------
При этом надо различать понятия - задержка звука и непрерывность звука.
Тогда будет все просто и понятно, а не куча из котлет и мух.

 

[pvvx]

Вопрос в том, что Вы конкретно хотите передать.
В данном случае, как всегда, вместо того, чтобы рассчитать и понять,
что можно получить, в ход идет ползучий эмпиризм и метод тыка.
Все же уже давно определено в документации VOIP.

Какая самокритичность.
Ну наконец-то, вы прочитали моё сообщение и узнали, что есть другие решения.

При организации передачи звука в локальной сети нет надобности разбивать звук на мелкие пакеты
Поэтому качественно передачу звука можно реализовать и на WiFi через любой протокол, например через UDP
----------------
При этом надо различать понятия - задержка звука и непрерывность звука.
Тогда будет все просто и понятно, а не куча из котлет и мух.

Для передачи звука на короткие дистанции давно откатан и всех устраивает обычный bluetooth. Тем более там всё полностью отработанно и под рукой у всех имеются все составляющие за дешево для реализации оптимального решения.
А данная тема не о WiFi, в котором нет хороших реализаций передачи звука и стандартов для этого, а о "звуковых" возможностях чипа не имеющего WiFi и пока не позволяющий реализовать новый стандарт передачи звука в BLE с новыми кодеками.

 

[pvvx]

Желающие это проверить могут провести эксперимент.
взять два модуля ESP и установить связь по ESP-NOW.

Предлагаю сравнить с рацией на пару Вт в 27MГц.
Там другой протокол и всё успешно передается на километры и имеются в наличии в магазинах на любой вкус и цвет

 

[pvvx]

Вопрос в том, что Вы конкретно хотите передать.

Зная автора темы - он занимался типа "радио-няней".
Т.е. надо передать звуки плачущего ребенка и типа. И передать на типовые устройства, имеющиеся у большинства потребителей и работающее в зашумленной городской обстановке. А наиболее зашумлена она в области WiFi 2.4ГГц.
WiFi роутер к этой теме не относится. ESP с ESP-NOW в кармане у маманьки находящейся в соседней комнате тоже не имеется.
Т.е. обычно есть Смартфон и ничего более. Всё остальное - это уже специальное, дорогое и нетипичное решение.
Для такой задачи лучше всего подходит чип имеющий Bluetooth и BLE одновременно, т.к. создает упрощение в типовой реализации ПО для установок по BLE и передаче звука по Bluetooth.
Для DIY и мелко-подпольно-серийки это наверно это туда https://esp8266.ru/forum/threads/jl-soc.5500/
Но я думаю, что автор темы и сам это знает.

 

[pvvx]

Тогда будет все просто и понятно, а не куча из котлет и мух.

Т.е. вы так и не заметили, что тут разделяем мух от котлет.
И данном случае вас опять развели на показ своей некомпетенции и в вопросе простой передачи звука для бытовых погрямушек.
Ваше желание переоснастить всё на ESP8266 с ESP-NOW не находит применения нигде, как и было проанализировано при его анонсе.
И ваша реклама ESP-NOW не помогает принятию его другими производителями.

 

[nikolz]

результаты тестирования задержки в BLE-Mesh при малом числе прыжков и малом пакете

Как видим задержка более 30 msec.
По данным тестирования сетей с разными протоколами ведущих фирм-производителей чипов, самая медленная сеть на основе протокола BLE.
Пропускная способность BLE-Mesh практически не зависит от числа узлов и составляет примерно 2-3 кб/с.