Господа, есть задача - транслировать по радиоканалу звук.
Послушав различное качество звука я пришел к выводу что 24 кбит/сек устроят. Меньше не хотелось бы.

Посоветовали использовать кодирование звука, дабы слать меньший объем данных. Снизит ли это нагрузку на контроллер?
В общем вопрос сформулирую следующим образом: для 24 кбит/сек и 16 МГц авр-микроконтроллера чем лучше кодировать звук? ПРочих задач у контроллера минимум, поэтогму 95% его загруженность вполне устроит.

Что лучше взять ADPCM или MP3 кодек?
В общем подскажите в сторону чего смотреть.

на mp3 encode у авр силёнок, пожалуй, не хватит.
еще можно посмотреть на hawkvoice и speex.
хотя они в основном для голоса и с несколько меньшими битрэйтами.

это имеется ввиду если AVR будет сам кодировать MP3 ?
Если поставить VS1003, получится ли?

Кодирование звука повышает нагрузку на контроллер и снижает нагрузку на канал связи. Про чистый AVR не скажу, 8-битный звук все-таки маловато, а с нормальной исходной разрядностью ему сложновато будет справиться. Если AVR, то наверное, все-таки AVR32.

Хм... объясните как оно повышает нагрузку на контроллер?
Вот у нас микросхема VS1003, она "слушает" микрофон. Кодирует звук и уменьшает количество информации. ОТдает ее в AVR для последующей передачи. ПОчему данный способ будет медленнее, чем если бы звук тупо оцифровывался АЦП контроллера?

То же самое с воспроизведением - насколько я понял, контроллер отправил в VS1003 пакет данных и курит, пока тот его проиграет.

Или меня просто не поняли и думают, что я хочу возлоржить саму процедуру кодирвоания на микроконтроллер.

Может, микроконтроллер и кодек и не нужны? ;)
Почему бы не вернуться к чистому радиолюбительству - микрофон + передатчик?

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

Иначе вопросы "ниачём".
Вот моя жена сидит сейчас на диване и рассуждает, хватит двух трубок обоев в комнату на втором этаже, или не хватит.
Я ей стараюсь намекнуть, что не мешало бы подняться и посчитать.

Так вот и Вам не мешало бы посчитать на бумажке, а мы уж проверим.

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

изначально думалось использовать обычную рацию и передавать данные с помощью DTMF. Но этот вариант пришлось отвергнуть по ряду причин.
Так что в настоящий момент планируется RFM12BP или cc1100-PA-LNA, контроллер AVR и кодер/декодер речи.
Загрузка контроллера посторонними задачами минимальна настолько, что ей можно пренебречь.

Это другое дело, но топик-то назвали "кодирование звука на АВР", т.е. кодеком должна быть авр, что ей не по силам. А если это делает профессиональная ИС, то на здоровье!
Хотя для передачи голоса цифрой я все-таки поискал решения из GSM, там битрейт пониже.

Да и необходимость цифры тут непонятна. Аналог энергетически и по полосе выгодней

ну.. виноват.
Я имел ввиду, справится ли АВР с объемом данных, поставляемым кодеком.
Собственно микру уже выбрал VS1003 и пример для ATMega8 нашел. Мне интересно, какой битрейт потребуется радиоканалу, если звук ужимать до "телефонного" качества. Кто-нибудь может примерно прикинуть?

"Телефонное качество" - это PCM 64 кбит/с, с логарифмической компрессией. Если битрейт меньше - это уже несколько не то... Ну, есть еще ADPCM 32Kбит (DECTовые телефоны), тоже, в некотором роде, "телефонное". Как задача изначально озвучивалась (эпизодически передача данных + голосовой канал) взял бы за основу именно радиостанцию a la LPD, а для передачи данных - низкоскоростной модем. Стыковка с радиостанцией - по аудиовходу-выходу +PTT. Не устраивает готовое решение - ну, взять схемотехнику простой радиостанции за основу. Городить скоростную передачу данных только для голосового канала - разве что из соображений безопасности. В ущерб надежности и дальности.

Обсудил с заказчиком. Тому в восторге от соображений безопасности. И, как выяснилось, главное собственно, не голос, а данные. Данные можно передавать хоть на 300 бод. Голос - это на крайний случай, так что меньшая дальность по голосу устраивает. Был еще раз рассмотрен вариант с радиостанцией и DTMF и в итоге отвергнут.

Скажите, какие преимущества дает MP3 кодирование? Стоит ли брать микросхему VS1003, в которой ADPCM+MP3, причем будет использоваться что-то одно, или же лучше взять бюджетный вариант VS1103, в котором только ADPCM и MIDI ? Стоит то в 3 раза дешевле.

MP3 в основном используют для сжатия музыки с большой частотой семплирования и, соответвенно, с большим битрейтом на выходе.
Есть, правда, проприетарный MPEG-2,5, но не факт, что он поддерживается в VS1003.

Для сжатия речи обычно применяют специальные кодеки, которые позволяют получить на выходе очень низкий битрейт:

MELP: 1.2 кбит/с - 4.8 кбит/с,
Speex: 2 кбит/с - 44 кбит/с,
G.729x: 6.4 кбит/с - 11.8 кбит/с,
G.726: 16 кбит/с,
G.711: 64 кбит/с.

Общее правило: чем ниже битрейт на выходе кодека, тем выше помехозащищенность канала связи и, как следствие, большая дальность устойчивой связи и меньшие помехи в эфире для соседних радиостанций.

Хм... век живи век учись и дураком помрешь.
ТОлько что узнал, что ADPCM это только кодирование, но еще не сжатие.
Стало быть для приемлемого на слух качества при использовании ADPCM нужно 64 кбит/сек, я правильно понял?. А если использовать указанные вами кодеки... мне не совсем понятно - ваши цифры это диапазоны?

И... есьт железячные решения реализующие указанные вами кодеки?

Вам нужно качество или с головой хватит разборчивости ? Что говорит заказчик ? Я так полагаю, что имеет место вариант 2, тем более, что речевыми данными вы зачем-то собираетесь "засорять" канал, по которому идет телеметрия ...

Внесу еще немного сумбура в тему.
Во первых - все-таки можно легко передавать данные поверх голосового канала. Если DTMF не подходит - есть протоколы V21, V23 и другие. Для V23 есть микрухи (например FX604). V21 - можно реализовать на аврке програмно.

Далее. ADPCM легко реализуется програмно на AVR. Если взять ATXMega то вообще все здорово должно получиться.

есть исходники
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 при появлении битого пакета его придется пропускать, иначе будет задержка звука, да и то, если в системе есть буферная память.

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

Как раз наоборот..

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

Как-то так..

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

Так в том-то и дело, что сейчас у ТС нет вообще никакого радиоканала, а есть очень смутные представления о том, как и на чем его реализовать. И при этом он решил сперва взяться за кодек

А это что:

???

А еще можно ходить с ноутбуком. В нем MP3 плейер, с кодеком....только связь по USB наладить.
Ну что ж вы меня в сторону уводите?

Я же писал, что сроки поджимают, с АРМ работал но давно это было, вспоминать неохота. Почему я вообще должен переходить на более мощный процессор (я теоретически могу ничего мощнее АВР не знать), если есть техническая возможность использовать аппаратны кодек, с управлением которым справится и АВР?



А что же главнее, уважаемый? Как вы мне предлагаете определяться с радиоканалом? Передавать речь без сжатия, а дальность добивать мощностью? Это совет профессионала?



Это у вас смутные представления о теме, которую вы не читаете, о чем вам указал blackfin.


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

Уважаемые господа, я ничуть не сомневаюсь в вашем профессионализме, кроме того я сам любитель и соображаю куда меньше вашего.
Но вот только не надо спекулировать своим профессионализмом. На вопрос "почему ?" вы отвечаете "да потому что я сказал... я профи...". Будьте добры, обосновывайте свои советы чем то иным, кроме своего авторитета.


Пардон, вылез с компа соседа. Я -=Женек=-

А он (радиоканал) точно уже ЕСТЬ ? Потому как, помнится, совсем недавно Вы его только выбирали... И мощность точно ДОСТАТОЧНА ? Вы бы для начала в реальности проверили хоть с низкоскоростной передачей телеметрии, на реальный километр требуемой дальности, в реальных условиях (о которых Вы упорно не желаете рассказать - а зря). А вот потом можно и вернуться к звуковым кодекам и требуемым битрейтам... "Меня терзают смутные сомнения..." ©

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

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

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

Ну почему этого никто, кроме blackfin, не понимает?

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

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

Судя по всему, не получится у меня проверить радиомодем с кодеком - нету модемов в РФ, поставка месяца 2.
ПОследую совету использовать LPD и низкоскоростной модем.

Вот и зреет вопрос - а чем лучше модулировать - как было раньше сказано DTMF или есть другие более прогрессивные методы?

DTMF со стандартными кодеками - медленно и ненадежно. Это совсем от бедности.

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

бррр.. вы что, подумали, что я DTMF для речи собирался использовать? Речь будет в рабочем режиме, а DTMF именно для телеметрии. И все это целиком средствами рации. Ну или не DTMF - я потому и спросил, как лучше передать телеметрию с помощью LPD рации, точнее, через ее звуковой канал.

У DTMF вообще есть понятие скорости или длительность кодовых посылок стандартна?

Нет, для передачи оцифрованной речи использовать DTMF-кодирование - такую траву еще не вывели. Но и для передачи телеметрических данных это совсем поганый вариант. Говорю же - от бедности. Понятие скорости - есть, ограничение на максимальную скорость - см. характеристики кодеков. Лучше что-нибудь более подходящее. У TI можно посмотреть примеры реализации аудиомодемов. А я бы сделал как в стареньком SmarTrunk-2, фазовая манипуляция звуковой несущей. Просто и весьма надежно. Целый выводок разных звуковых модемов есть у CML, но все это дорого и достаточно экзотично, а можно обойтись копеечным микроконтроллером.

А нельзя ли ключевых слов конкретных для поиска на сайте TI?
А то я набрел там на TI на раздел кодеки, думал MP3 найду, так и не понял, что в этих кодеках особенного.

А нельзя ли ключевых слов конкретных для поиска на сайте TI?
А то я набрел там на TI на раздел кодеки, думал MP3 найду, так и не понял, что в этих кодеках особенного.

Где-то в аппликухах для MSP430, насколько припоминаю.

Извините, но на TI ничего кроме аудиокодеков и DTMF модемов не нашел. Пните в правильном направлении.

И еще - никогда с LPD рациями дела не имел. Я конечно буду брать помощнее и чтобы наворотов, усложняющих интеграцию, было поменьше, но все же на что обращать внимание при их выборе?

Это были "MSP430 Embedded Soft-Modem Demo " и "FSK Modulation and Demodulation With the Microcontroller MSP430". На самом деле, там ничего хорошего нет, припоминалось что-то, но, оказалось, несколько не то.

Радиостанции - брать как минимум с разъемами подключения внешней гарнитуры. Из популярных и неплохих моделей Midland G225. Можно что-нибудь и в китайских магазинах поискать, правда, месяц ехать будет.

остановил свой выбор на Jet! XT и Midland G55XT. Все Китай
Но брать наверное буду Jet! XT, в нем зарядка настольная.