Тема цифровых раций интересна. Я повторять конструкцию 1-в-1 пока не собираюсь, но есть несколько вопросов по работе с кодеком Speex.
1.При повреждении пакета, что я думаю не редкость в данной реализации, какие возникают артефакты звучания?
2.Что лучше - пропустить битый пакет на вход кодека или, сделав побольше защитных бит, проигнорировать новый пакет не прошедший по контрольным битам?
3.Если пакет не прошёл, то как обеспечивается непрерывность воспроизведения при провалах на входе кодека?

Ну и классический вопрос ̶с̶к̶о̶л̶ь̶к̶о̶ ̶ж̶р̶ё̶т̶ ̶с̶к̶о̶л̶ь̶к̶о̶ ̶п̶р̶ё̶т̶ на каком расстоянии удавалось обеспечивать устойчивую связь?

Судя по количеству комментариев, тема цифровой связи зацепила только меня.
И автор не собирается как то комментировать. Его право.
Всё же поделюсь парой идей. Сейчас китайцы уже продают цифровые рации DMR, так что наличие типично цифровых пакетов в диапазоне PMR и тем более LPD не должен вызвать ни у кого подозрений. Если, конечно не работать непрерывно.
Так как городить конструкцию с ноля, ради просто исследовательского интереса слегка накладно, я собираюсь взять обычную аналоговую рацию LPD или PMR за 300-500р и вклиниться в её аналоговый тракт микроконтроллер.
То есть данные с микрофона прогнать через АЦП-ЦАП и то же сделать в выходном НЧ тракте. А управление трансивером оставить штатное.
А далее можно уже пробовать гнать битики по аналоговому тракту, реализовав аналог модема.
Скорости, я думаю, можно получить в 2-3кбит/с. Модуляция BPSK или FSK.
Под эти скорости надо реализовать речевой кодек.
В общем то, с этого я и начал. Сразу скажу SPEEX мне не особо понравился, так как работает во временнОй области. Я глубоко убеждён, что низкие битрейты с нормальной разборчивостью можно получить опираясь сразу на частотный анализ.
Самый известный вариант частотного анализа - преобразование Фурье. В цифровой технике доминирует его аналог - Быстрое Преобразование Фурье.
Пока план такой:
Для кодера:
1.Оцифровываем сигнал.
2.С помощью БПФ переводим последовательность сэмплов в последовательность спектров. На этом этапе, скорее всего, придётся избавиться от фазовой информации в спектре, так как она хуже поддаётся анализу.
3.Анализируем амплитудный спектр на предмет наличия устойчивых паттернов, которые и кодируем в сжатую последовательность
Для декодера
1. Преобразуем сжатую последовательность в спектр.
2.Отправляем спектр на синтезатор, что преобразует данные из частотного представления во временное. Тут надо будет как то правдоподобно восстановить фазовую информацию, но это, с учётом сжатия будет меньшая проблема. Скорее всего сжатие и так наложит свой отпечаток, вопрос в том как сильно. Но главное чтобы основная информация была сохранена.
3. Синтезатор выдает данные на ЦАП, завершая цикл кодирования - декодирования.

Что Вы об этом думаете? Достойно заниматься таким радиолюбителям в наше время или уже всё придумано за нас?
Если Всё же появятся заинтересованные, то я буду сюда выкладывать результаты своих изысканий.

Вы о чем?

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

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

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

@Novice user
О создании малоресурсного кодека, способного сжимать речь в 2-3кбит/с для применения в самодельных цифровых рациях. Мне эта тема стала интересна после прочтения статьи, обозначенной в заголовке. Вот, хочу спросить, кто то заинтересован? Может есть идеи, предложения? А то я не нашёл открытых кодеков, кроме SPEEX, адаптированных под работу на МК.

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

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

Подробнее>>

Ну таки вперд. Тут целый НИИ этим занимался долго и упорно и влез таки 2400 бод - но система зело суровая вышла. Около 100 ячеек на 1821ВМ85+1815ИА1+еще что-то. С трудом переносится одним человеком. Военные отказались по причине - невозможно по голосу понять кто говорит. Схемотехника и алгоритм закрыты.

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

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

Подробнее>>

Но современные микроконтроллеры почти как компьютеры 20-летней давности. Думаю, что в 3кбит/с ужаться более, чем реально. Стандартные китайские DMR рации как то ужимаются.

nHz, все уже украдено до вас, посмотрите к примеру AMR: https://ru.wikipedia.org/wiki/AMR_(%D1% ... 0%BA%D0%B0)

Я, если честно, уже начитался про всякие открытые стандарты так , что голова пухнет.
Мне бы какой нибудь гайд по конкретным исходникам, чтобы был объяснён алгоритм, а потом указано где и как это реализовано в коде.
А то исходники без пояснения что там делается в подобных специфических вещах почти бесполезны.

Зато в процессе чтения сопутствующих статей про сжатие речи родилась идея как ̶и̶з̶о̶б̶р̶е̶с̶т̶и̶ ̶с̶в̶о̶й̶ ̶в̶е̶л̶о̶с̶и̶п̶е̶д̶ реализовать свой кодек и ужаться в 3кбит/с

Напишу здесь, пока не забыл.
1. Делим поток семплов на кадры, чтобы считать БПФ. Частота кадров пусть будет 50 в секунду. Кадры будут с перекрытиями, так как придётся наложить оконную функцию. Размер кадра 512. Алгоритмическая сложность БПФ N*log2(N). Количество операций МК, требуемых для выполнения ядра БПФ пусть будет 100(с запасом). Итого операций МК для БПФ потребуется 512*9*100*50=23040000(23Мопераций/c)
2. Для поиска закономерностей в речевом спектре неплохо было бы определить частоту основного тона(ОТ) голоса. Эта частота легко ищется, если взять БПФ от амплитудного спектра. Так как спектр реального сигнала имеет в 2 раза меньше значимых компонент, то БПФ от результата 1 шага потребует 256*8*100*50=10240000(10Моп/с)
3.Из спектра полученного на шаге 1 получаем новый ужатый спектр, содержащий только частоты кратные частоте ОТ. Для такого спектра достаточно 60 значений.
4.Так как разрешение нашего слуха по частоте падает с ростом частоты, то можно объединить ВЧ компоненты, усредняя смежные значения. Таким образом превратив 60 значений в 16.
5.Выделяем амплитуду сигнала и нормируем полученный 16 размерный вектор.
6.Логарифмируя значение элементов вектора и округляем их, нормируем их так, чтобы каждый компонент имел значение от 0 до 7, т.е. умещался в 3 бита.
7.В итоге получаем битрейт 7бит для кодирования ОТ+4 бита для общей амплитуды+3бита частотные компоненты*16 штук и все это 1 кадр, а их 50, соответственно (7+4+3*16)*50=2950бит/с
8.Количество операций для пунктов 3-6 будет не более 10М, т.е. общее количество операций для кодека 40М. Подойдёт почти любой 32-битный камень, правда для многих будет больше 50% загрузка. Это кодер.

Декодер же можно построить прямым синтезом частот, т.к. данные от кодера содержат просто набор синусоид определённой частоты и амплитуды и уложиться в 10М-40М операций.

И замечу, что такой подход не учитывает корреляцию между соседними кадрами, которая весьма сильна. Но это уже для получения супер сжатия в битрейт менее 1кбит/с

Есть и самоделки. Вот интересная тема: https://electronix.ru/forum/index.php?a ... &id=137505

Интересно, но люди гонятся за ультранизкими битретами. К сожалению, ссылки в статье не работают. Но почти всё, что я слышал менее 1500бит./с очень искажено. менее 800бит./c вообще слушать невозможно. Хоть и можно, иногда, разобрать, что говорят.

Поэтому, реально взглянув на проблему и свой текущий уровень её понимания ниже 2кбит./с опускаться пока не планирую. Главное, что мне пока нравится в моём алгоритме - полная прозрачность. Никакой особой магии и психоаккустики. Буду пробовать его на python быстренько закодить. Там и преобразование Фурье на все вкусы и прочие удобства. Результаты проверки, думаю, будут скоро.

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

без специализированых дещевых ДСП туда не стоит и лезть мк ширпотребные там не прокатят даже любимые некоторыми сташаки из стм32

Сейчас во многих средних и старших линейках 32 разрядных МК встроены FPU. То есть можно даже не мучаться с целочисленной арифметикой, имитируя фиксированную точку.(нужно для БПФ) Расклад по операциям для моего алгоритма я написал.
40M операций сможет и слабый stm32f103 на 72Мегагерцах. А если взять что нибудь постарше, то тем более. Со специальным ДСП будет, конечно, лучше. Но этот путь не для любителей.

В идеале, создать библиотеку которая может работать и на целых числах и на float'ах.

Накидал скрипт на python, реализующий получение ужатого спектра, содержащего только частоты ОТ.
Таким образом, получается в вектор размером 30-60 поместить спектр размером 256 с минимальными потерями. Причём только нижние гармоники важно передавать полностью, высшие(>10) уже можно склеивать вместе и усреднять.

Спойлер

Код:

#размер кадра data=512 семплов, частота дискретизации 16кГц, частота кадров 50Гц(шаг кадров 320семплов)
data*=maskH #накидываем оконную функцию
sp=np.fft.rfft(data)#вычисляем спектр от действительных данных
       
#получаем амплитудный спектр и немножко его нормируем(чтобы амплитуда компонент на превышала 1.0)
spA=np.abs(sp)
spA=spA/(len(spA)*0.5)#делитель подбирается в зависимости от реализации FFT и размерности входных данных
spA[:3]=0  #ФВЧ,отсекающий постоянку и частоты до 100гц
     
       
#коэффициент основного тона(ОТ) eсли 0.6..1.0, то в сигнале определённо есть основной тон, иначе считаем, что сигнал шумовой(без ОТ)
kF0=np.dot(data,np.roll(data,1))/(max(np.dot(data,data),0.00001))
       
spA32=np.zeros(32)#резервируем вектор для урезанного спектра
if kF0<0.6:#для шумового сигнала f0 фиксирована
       f0=float(len(spA))/len(spA32)
else:
       #получение частоты основного тона в масштабе спектра f0=2.0..12.0 всего 127 шагов(7бит)
       f0=getF0(spA)
       
       #заполняем урезанный спектр из основного с учётом частоты ОТ
i32=1
i=f0
while i<len(spA):
   
      k1=i%1.0
      k2=1.0-k1
      spA32[i32]=k2*spA[int(i)]+k1*spA[int(i)+1]
      i32+=1
      i+=f0
      if i32>=len(spA32) or i+2>len(spA):
           break
#на синтезатор посылаем f0 и вектор spA32
#вектор spA32 представляет из себя амплитуды синусоид кратных f0
#например, 10 элемент spA32 это амплитуда синусоидального колебания частотой 10*f0
#f0 представляется 7 битами, можно уменьшить шаг до полутона и представить диапазон 5 битами(32 значения)

При таком подходе речь ещё остаётся весьма разборчивой. Хоть и звучит весьма "металично". Частично побороть этот эффект, я думаю, возможно в синтезаторе, слегка "распушив" высокие частоты. Но это не первостепенная задача, так как надо сначала поработать над сжатием. Синтезатор работает весьма примитивно, выдавая на каждом шаге частоты дискретизации(16кГц) сумму синусоид определённой амплитуды и частоты.

Основное сжатие будет происходить на векторе ужатого спектра.Амплитуды синусоид могут быть представтлены весьма грубо вплоть до точности +- в 2 раза. Из чего родилась идея логарифмировать их по основанию 2 и оставить только целую часть. Максимальное значение амплитуды 1 , минимальное 0.
Примем минимальное значение равным 2 в степени -15, тогда с учетом округлени до целого каждая компонента будет занимать 4 бита.
Получаем сжатый поток (7+31*4)*50=6550 бит/с.
Но такой большой динамический диапазон в 30000 раз слегка избыточен. Можно выделить характеристику, отвечающую за среднюю амплитиуду(энергию) спектра(4бита) и тогда можно представить компоненты с разрешением в 3 бита(динамический диапазон около 100 раз)
Поток почти не теряет в качестве, зато ужимается до (7+4+31*3)*50=5200 бит/с.

Дальнейшая идея сжатия основана на том, что соседние компоненты весьма коррелированы и можно объединить их в группу, представив средней амплитудой, уменьшив таким образом размерность вектора спектра. Практика показала, что младшие компоненты лучше не объединять, во всяком случае, до 5-го. Дальше уже можно по парам и далее, чем выше номер компонента, тем больше можно делать размер группы. Я перепробовал несколько формул объединения и приятнее всего мне показалась такая.[1,1,1,1,1,1,1,1,2,2,2,3,4,5,5] - цифрами обозначены размеры групп. Размер вектора спектра получается 15 и битрейт (7+4+15*3)*50=2800 бит/с. Звук, конечно, портится, но разборчивость всё ещё нормальная.
Ну и не мог я не попробовать ужаться совсем экстремально по формуле [1,1,1,1,1,3,3,10,10] до (7+4+9*3)*50=1900 бит/с. Качество, как по мне, неприемлемое, даже для рации. Но я сравнивая с готовыми кодеками менее 2кбит/с скажу, что они все звучат немного не нормально. К тому же я пытаюсь хоть как то представить высокие частоты (>4кГц), в то время как большинство не вылазят за полосу 4кГц, начиная с источника 8кГц частотой дискретизации. Может и я к этому приду, но пока я работаю с исходным сигналом в 16кГц и явно слышу разницу в высоких частотах. Пока так. Образцы звука в архиве. Подумаю пока как ещё можно сжать данные, сохранив качество получше. С эти можно ещё поработать.

Насчёт МК думаю взять китайский ESP32. Его быстродействия точно хватит. Там и FPU есть и 2 ядра. И цена неплохая. Пока разбираюсь с SDK.
примеры звука