есть исходники
http://hawksoft.com/hawkvoice/
http://www.speex.org/
берем любую подходящую железяку и реализуем.
сильно много не надо. вот тут тесты производительности
http://hawksoft.com/hawkvoice/codecs.shtml
арму надо всего 8Мтактов/секунду.
тут еще немного инфы по требованиям g.729
http://www.dspwizard.com/

Хватит разборчивости.
И что значит засорять? Не надо подмешивать свой субъективизм. Не настолько быстр этот канал, чтобы его можно было засорить. Передается пакет данных в котором первый байт - телеметрия, остальные - голос.
Де юре - телеметрия это основное, а голос на всякий случай, связаться, реально может понадобиться 1 раз в неделю. Де факто же, по понятным причинам, вся нагрузка и вся сложность проекта в голосе, а передать телеметрию - плевое дело.

Пожеланием заказчика было - "шоб было как буд-то к рации подключили устройство, подмешивающее телеметрию, но: 1. Это должно быть одно устройство. 2. Сборка устройства не долджна предполагать покупку и раскурочивание раций."
Плюс сроки, которые горят. Заказчик так и сказал - если сократить сроки позволит покупка готовых модулей, деньги не вопрос.

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

А цифровой радиомодем, выбранный мной хорош следующим:
1. Я уже работал с чипами CC11хх. (Не забываем про сроки)
2. При невысоких требованиях к качеству звука мы получаем шифрацию переговоров (приветствуется заказчиком).
3. В проекте есть еще ряд тонкостей, для которых радиомодем предпочтителен.


Вот так я и пришел именно к такому решению.

blackfin


В VS1003 есть режим MPEG-2.5.

Вот кстати выдержка из даташита (см. скриншот)

Объясните неучу, значит ли эта таблица, что кодеком, скажем MPEG2.0 можно сэмплировать с частотой 16 кгц, а на выходе в зависимости от параметра, заданного алгоритму кодирования, можно получить от 8 до 160 кбит/сек с соответствующим битрейту качеством? Причем загрузка контроллера при большей степени сжатия не увеличится, так как ее полностью осуществляет VS1003 ?

Да, всё именно так и есть..

вот черт... только он не кодирует звук в MP3.... это сводит на нет его декодерские возможности...
Новую микру VS1063, которая делате все - нигде не заказать....

Господа, сформулирую свой вопрос тогда так:
посоветуйте микросхему, включающую в себя кодер и декодер одновременно, (ибо пару - кодер+декодер) способную не только кодировать но и сжимать. Микросхем ADPCM с их 64 кбит/сек как грязи. Есть что либо не софтовое, а железное, позволяющее получить кодуированную речь объемом меньшим, чем 64 кбит/сек?

Может есть какие микросхемы с кодеками G.xxx ?

1. Я подмешиваю не субъективизм, а здравый смысл, базирующийся на элементарном инженерном опыте. В вашей задаче что-то не так, причем это очень хорошо ощущается. А профессиональное чутье подводит меня довольно редко.

2. Если бы это было "плевым" делом, вы бы не заводили темы в форуме, а давно сделали бы все сами и получили бы деньги ...

3. Заказчик правильно сказал - все сведется к покупке раций, почти наверняка - КВ. Но уже после того, как вы, вдоволь наигравшись с вашим радиомодулем, завалите все сроки и ухлопаете кучу денег. Чудес не бывает.

4. Ну и что, что вы с ними работали ? В данном конкретном применении они подходят ? Хорошо, если так. Но что-то меня терзают сомнения. Вы на моделистов не смотрите. Самолетиком управляют в условиях прямой видимости. Судомоделью - тоже. Машинкой - тем более. Поэтому подходящие для моделистов решения могут не подойти вам.

не подменивайте понятия. Плевое дело для меня - передача данных (см. п.4), а тему я завел про кодирование звука.


А вот опыт человека, ответившего мне в разделе RF, говорит о передаче звука 64 кбит/сек радомодемом. Просто его устраивало ADPCM без сжатия по дальности. А у меня условие - дальность побольше, а посему - данные столько-то метров, а звук - как получится, но желательно подальше.

Вот я, человек с меньши опытом, чем у Вас, но обладающий здравым смыслом, прихожу к логичному выводу, что при одной и той же мощности сжатый звук можно передать дальше, чем несжатый. А коли так, то ищу железячечное решение этой проблемы, дабы не грузить контроллер и не париться с DSP и софтовым кодеком.
Так что же крамольного в моем решении? Я не стремлюсь получить идеал, я хочу лишь использовать все имеющиеся на данные момент возможности.
Решение есть - VS1063, но в России оно недоступно.
Вот я и задал простой вопрос - есть ли нечто пусть не аналогичное, но похожее по функциям.

Делайте, я не против. Только вы начали решать задачу не с начала, а с конца. Сначала нужно бросить все силы на радиоканал. И только после достижения требуемых результатов в этом направлении (практических, а не "бумажных") есть смысл переходить к передаче речи. Радиоканал - основное, все прочее глубоко вторично. А то потом выяснится, что "лампочки куплены, для электрификации поселка осталось протянуть 50 километров ЛЭП".

P.S. Хотя дело ваше. Делайте, что хотите. Я вас просто пытаюсь предостеречь ...

Мне непонятно, как Вы хотите получить разную дальность для телеметрии и данных (оцифрованного звука) используя один и тот же радиоканал? Цифровые каналы связи они либо работают, либо нет, если отношение сигнал-шум в радиоканале превышает некое пороговое значение. В последнем случае Вы ни данных, ни телеметрии не получите, вернее, они будут испорчены. Откуда уверенность что "сжатый звук можно передать дальше, чем несжатый"? Какая принципиальная разница в передаче нулей и единиц в этих двух случаях?

GDI, попробую объяснить.
Скорость с которой можно передать данные обратна расстоянию.
Допустим ставим мы скорость на максимум, отошли на 100 м, смотрим анализ радиообмена - 50% битых пакетов. Снижаем скорость чуток - смотрим - 10% битых пакетов. Еще снизили - 0% битых пакетов. Радуемся.

Реализуем алгоритм, при котором битый пакет запрашивается повторно.
В резултате, если телеметрия содержит в себе 30 байт, то на скорости в 300 бод и 90% битых пакетов можно дождаться результата за 1 секунду (пренебрежем временем на переключение).

С речью хуже - речь должна быть при устойчивой связи не ниже 64 кбит/сек (дуплексный режим не рассматриваем).

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


Испорчены будут не все, а процент будет зависеть от качства сигнала и от скорости.

Я это к тому, что, вот есть у Вас некий цифровой радиоканал с некоей битовой скоростью, так с этой скоростью и будут передаваться и телеметрия, и звук. И битые пакеты будут одинаковы, ведь по сути, насколько я понял, Вы собираетесь передавать телеметрию и оцифрованный звук в одном пакете. То что Вы будете передавать телеметрию раз в секунду, нисколько не меняет ситуацию, потому что битовая скорость все равно будет некоей постоянной величиной. Т.е. Вы можете уменьшить битовую скорость всего радиоканала, применив некий звуковой кодек, т.е. передавать со скоростью, чуть большей чем надо звуку, чтобы еще и телеметрия поместилась. А если Вы еще и повторы передавать хотите, то битовую скорость нужно значительно увеличивать. Т.е. не будет такого, что телеметрию Вы на 10м передадите, а звук на 15. Всегда будет, либо 10, либо 15. Вам вообще не надо разделять передачу данных, считайте, что у Вас передается один пакет с данными, а что там внутри пакета, звук или звук+талеметрия - это не важно.

Да что вы говорите?

А если так:


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

Господа, я рад, что эта тема стала ареной для критики моей задачи, но почему-же никто так и не ответил на мой вопрос, а?
Ну так и скажите, что не существует доступных в России микросхем для аппаратного сжатия или же не знаем мы о существовании таковых.

Посмотрите на систему связи с другой стороны: есть канал связи с его характеристиками (дальность, затухание, замирания, переотражения и т. д.). Задана скорость передачи двоичных данных. Ответьте себе на вопрос: "Какие характеристики приемника и передатчика обеспечивают заданный BER при указанных условиях распространения?" (мощность излучения, чувствительность приемника, примененный вид модуляции и кодирования, размер пакета и т.д.). И на следующий: "Как измениться BER при изменении частоты передачи пакетов? (остальное не изменяется)" .

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

mdmitry


Правильно говорите, товарищ!
Это зависит от выигрыша при сжатии. Для 8 кГц битрейт несжатой речи равен 64 кбит/сек. Если использовать Mpeg2.5, с минимальным битрейтом в 8 кбит/сек, то получаем (в теории, если не учитывать накладные расходы) 1 период передачи данных и 7 периодов бамбукокурения, в течение которого можно повторить передачу.
С несжатым ADPCM при появлении битого пакета его придется пропускать, иначе будет задержка звука, да и то, если в системе есть буферная память.

Вас побуждают взглянуть на свою задачу шире. Кодек не главное - главное радиоканал. Недавно на Сахаре сказали комуто "Вот когда Вы нам сможете объяснить свою задачу, тогда уже и сами поймете как ее решать".