Добрый день!

Помогите сориентироваться плиз!
До этого занимался стеком UDP, таймерами, флешками, uart-ами, пока на 8-битных PIC-ах.

Хочу передавать звук, в "хорошем переговорном" качестве. Чтобы грубо говоря на другом конце линии RS-485 собеседник совершенно отчетливо понимал сказанное, ну, практически телефония. Аналоговую часть опустим. Но high-definition не требуется.

Вопрос - на чем лучше организовать захват-обжим-воспроизведение? Я в принципе собираюсь освоить STM32, на PICах это мутить не хочу.

Может для задачи ЗА ГЛАЗА хватит какого-нибудь простейшего аппаратного кодека? Какие они бывают, где про это почитать?
Ну в принципе после миграции на STM32 могу заморочится захватом средствами самой STM32, программно, вроде есть примеры, но вот надо ли?
(т.к там помимо передачи звука будет масса других задач)

Нет такого термина в нашей области. Циферки, циферки пожалуйста...

А так, по простому - АЦП -> RS485 -> ЦАП. На скорости 128 кбод, можно передавать звук с качеством в 8 бит и частотой дискретизации = 16 КГц. Что сможет абсолютно любой МК, имеющий на борту UART и АЦП.
Такого качества хватит не только для речи. Музыку можно гонять спокойно.

В GSM протоколы и алгоритмы открыты, т.к. производителей оборудования (было) немеряно, а отраслевой стандарт должен быть примерно один, иначе телефон одного производителя не станет работать с базовой станцией другого. Голос там ужимали до передачи по каналу 9600 бод, насколько это "хорошее переговорное" качество, возможно, можете помнить сами. Если разговаривали по мобильному телефону GSM в конце 90-х - самом начале 2000-х. Если не помните, поверьте на слово - речь разборчива
Аналоговую часть опускать не нужно, т.к. от неё будет ооочень зависеть качество. Кодек, предположительно, будет ограничивать верхний диапазон частот в звуке килогерц до 8-ми (больше для голоса не нужно). В GSM, если склероз меня не подводит, резали до 4-х кГц. Всё, что выше нужно будет убрать фильтрами в аналоговой части, чтобы оно не превращалось в шум и не мешало достоверной передаче полезного сигнала.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

>>- АЦП -> RS485 -> ЦАП
Ну, это первое что родилось при обдумывании. Но получается приличный объем RAW-данных!?


Спасибо за комментарии!
По факту дело обстоит так. К устройству подходит RS-485 19200кб/с. (modbus). Устройств до 32, в "нормальном режиме"(без звука) по каналу будет летать телеметрия с датчиков.
При включении звука я ему буду выдалять .. ну никак не меньше 9600, с максимальным возможным сдвигом приоретизации для звука, но передача телеметрии остановиться не должна.

Отсюда предполагаю что компрессировать придется.
Со всеми этими датчиками наработки хорошие, но со звуком впервые сталкиваюсь, отсюда и вопросы.


Откуда цифра 19200 в RS 485? практика показала что с этим битрейтом можно забить на топологию линии (на практике - вообще - как хочешь так и ложат линию, с любым количеством веток любой длины... прямой линией даже отдаленно и не пахнет). При этом потери 0-2% - замеряю. Получается топология "расчески".

Требуется и дальше продолжить забивать. Но... может и получится отвоевать изменение тех.условий, и получится повысить ну максимум, до 27-28 кб/с. Тогда под звук смогу выделить пропорционально больше чем 9600.
Будет еще вариант исполнения с ethernet, но основной способ - RS-485.

И вот отсюда и предпосылки - ориентироваться на обработку средствами самой STM32, или существуют аппаратные кодеки?

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

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

Как раз сейчас пробую организовать похожий канал. Чем ниже битрейт UART тем больше дальность. Оцифровываю 8бит 8кГц. Без сжатия все красиво только 64кбод много. Простейший кодек ADPCM пока косячит. Ищу пример по GSM кодеку. Там 13кбод максимум.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Классический пример в моем случае - дом, 20 подъездов, по чердаку RS485, с чердака 20 ответвлений до 1 этажа, этажность 10-22. На чердаке центральная точка, с нее в антенну улетает на сервер, через IP-сеть.
На скорости 19200 пашет идеально. Если всплеск потерь хоть на одной точке - это пишется в базу и ремонтная бригада выезжает.

И вот туда хочу звук добавить.

Есть еще g726 кодек 16,24,32 кбод. 16 меня устроит, смотрю код, оцениваю затраты проца.

16.24 это можно в принципе...
Т.е Вы склоняетесь, процом обжимать?

STM32F0 на 65 МГц. Двойной буфер по 160 байт. Пока один отправляется, второй заполняется кодированными данными. Нужно успеть закодировать быстрее 75 мсек

можно и отдельный проц выделить под это..

Как вариант: вообще отказаться от RS-485 и передавать модемом. Сколько пролезет: зависит от стабильности характеристик линии (равномерности и стабильности её АЧХ). Но явно пролезет много больше чем с RS-485.
Не знаю только - хватит ли силёнок у дохлого STM32 на демодуляцию. Когда то делал подобные модемы на TMS320VC5502.

Допилил дифференциальное сжатие с нелинейным квантованием. 8кГц 8бит в поток 32 кбод. Пока многовато,но может сеть потянет на скорости 38400, ниже только 19200.
Добавил шумопонижение. Речь разборчива, почти не отличается от несжатого потока.
На оцифровку,код,декод и вывод звука STM32F030 расходует 2,5% процессорного времени.

Добрый день!

Как эксперименты с кодеком? У меня дошли руки, разобрался с АЦП-ЦАПом на АРМе, сейчас умею записывать-воспроизводить несжатый поток, выставлять битрейт, на CMSIS, победилось путем недолгого танца с бубном.

А где можно найти рабочие сорцы 726-го?

Проект пока отложен. Мне нужно передавать поток по радио. Настройка радиоканала хромает. Из-за шума иногда появляется ошибка контрольной суммы,что приводит к искажениям. По проводу все идет красиво.