Кодирование звука на AVR, помогите найти компромис Опции

[-=Женек=-]

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

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

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

[_pv]

В общем подскажите в сторону чего смотреть.

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

[-=Женек=-]

на mp3 encode у авр силёнок, пожалуй, не хватит.

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

[V_G]

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

[-=Женек=-]

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

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

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

[Dog Pawlowa]

контроллер отправил в VS1003 пакет данных и курит, пока тот его проиграет.

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

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

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

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

[-=Женек=-]

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

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

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

[V_G]

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

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

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

[-=Женек=-]

Это другое дело, но топик-то назвали "кодирование звука на АВР",

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

[rx3apf]

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

[-=Женек=-]

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

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

[blackfin]

Скажите, какие преимущества дает MP3 кодирование?

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 кбит/с.

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

Сообщение отредактировал blackfin - Feb 20 2012, 17:39

[-=Женек=-]

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

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

[kovigor]

Стало быть для приемлемого на слух качества при использовании ADPCM нужно 64 кбит/сек, я правильно понял?

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

[dx40]

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

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

[_pv]

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

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

[-=Женек=-]

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

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

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

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

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


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

[-=Женек=-]

blackfin

Есть, правда, проприетарный MPEG-2,5,

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

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

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

Эскизы прикрепленных изображений

 

[blackfin]

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

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

[-=Женек=-]

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

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

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

[kovigor]

Не надо подмешивать свой субъективизм.

... а передать телеметрию - плевое дело.

... Заказчик так и сказал - если сократить сроки позволит покупка готовых модулей, деньги не вопрос.

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

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

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

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

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

[-=Женек=-]

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

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

А профессиональное чутье подводит меня довольно редко.

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

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

[kovigor]

Так что же крамольного в моем решении?

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

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

[GDI]

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

[-=Женек=-]

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

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

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

Откуда уверенность что "сжатый звук можно передать дальше, чем несжатый"?

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

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

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

[GDI]

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

[-=Женек=-]

Т.е. не будет такого, что телеметрию Вы на 10м передадите, а звук на 15. Всегда будет, либо 10, либо 15.

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

А если так:

Код

while (1)
{
if (процент_битых_пакетов>=ДоХрена) Уменьшим_Скорость();
if ((Скорость<=самая_минимальная)&& (процент_битых_пакетов>=ДоХрена) )  Сигнализируем_о_потере_связи();
if ((Скорость<=минимальная_для_разборчивости_речи)&& (процент_битых_пакетов>=ДоХрена) )
  {
     Выключаем_передачу_речи();
     Передаем_телеметрию();
   }
else  Передаем_речь_и_телеметрию();


счетчик_переданных_пакетов++;
if (счетчик_переданных_пакетов>=100) процент_битых_пакетов=Посчитать_процент_битых_пакетов();


}

Извините за корявость конструкции, но вы не компилятор, вы поймете.

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

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

[mdmitry]

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

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

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

[-=Женек=-]

mdmitry

но его надо оценить с учетом потери пакетов-подтверждений

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

[GDI]

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

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

[blackfin]

Кодек не главное - главное радиоканал.

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

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

Как-то так..

[GDI]

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

[kovigor]

Параметры кодека, точнее, его выходной битрейт, определяют требования к радиоканалу.

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

[blackfin]

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

А это что:

радиоканал поддерживает 256 кбит/сек
Так что в настоящий момент планируется RFM12BP или cc1100-PA-LNA, контроллер AVR и кодер/декодер речи.

???

[zheka]

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

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

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

Человек спрашивает микросхемы аппаратных кодеков, доступных в России.

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

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

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

И при этом он решил сперва взяться за кодек

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

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


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

Сообщение отредактировал zheka - Feb 22 2012, 19:19

[rx3apf]

Есть радиоканал, мощность которого более чем достаточна и увеличивать ее не очень хочется.

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

[-=Женек=-]

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

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

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

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

[rx3apf]

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

[kovigor]

Поэтому я никак не пойму, причем здесь радиоканал ...

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

[-=Женек=-]

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

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

[rx3apf]

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

[kovigor]

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

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

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

[-=Женек=-]

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

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

[rx3apf]

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

Сообщение отредактировал rx3apf - Feb 24 2012, 16:37

[-=Женек=-]

У TI можно посмотреть примеры реализации аудиомодемов.

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

[-=Женек=-]

У TI можно посмотреть примеры реализации аудиомодемов.

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

[rx3apf]

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

[-=Женек=-]

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

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

[rx3apf]

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

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

[-=Женек=-]

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

[blackfin]

PS. На заметку: ADF7021-V

[ArtemDement]

AVR - необходимое условие ?

Посмотрите у ST есть примеры применения, вот навскидку:

Vocoder demonstration using a Speex audio codec on STM32F101xx and STM32F103xx microcontrollers

Audio software codec for the STM8

Audio software codec for the STM8L15xxx

[-=Женек=-]

Спасибо, на будущее возмьу на заметку- как раз месяц назад заказал себе STM32F103 и уже отладочную платку нарисовал, да руки никак не дойдут разораться с этим камнем.
Ежели бы не сроки, то делал бы на STM.
Кроме того, модем мне будут везти долго, так что я уже рацию купил.

Да господа, если кому не трудно гляньте на микру, что в этой рации http://files.radioscanner.ru/files/downloa...7/an29160aa.pdf

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

Другими словами - можно ли куда-нибудь подать прямоугольные импульсы, дабы на "другом конце провода" их же и получить?

А это, схема похожей рации http://www.radioscanner.ru/files/midland/file7307/

[rx3apf]

Там есть компаратор аудиосигнала для дальнейшей обработки "в цифре" (вывод 36), и теоретически можно и Tx прямоугольником подать. Не занимайтесь ерундой, делайте нормальный аудиомодем и не надо лезть внутрь станции.

[-=Женек=-]

Не занимайтесь ерундой, делайте нормальный аудиомодем и не надо лезть внутрь станции.

Погуглил. V.21 меня вполне устроит.

P.S. блин, как же дороги микросxемы CMX

[kovigor]

Погуглил. V.21 меня вполне устроит.

P.S. блин, как же дороги микросxемы CMX

Если нужна парочка дивайсов, купите обычные БУ телефонные модемы, вроде IDC, и настройте на выделенку с V.21. Кстати, такое решение может служить хорошей отправной точкой для "обкатки" вашей системы ...

А еще есть такая ИС: FX604 (это тоже модем)

[muravei]

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

Интересно , а в "умных " телефонах и коммуникаторах они аппаратные, или ВинМобаил это умеет ?

[blackfin]

Интересно , а в "умных " телефонах и коммуникаторах они аппаратные, или ВинМобаил это умеет ?

By default, Windows Embedded CE includes the following codecs:

- G.711 (both A-law and mu-law encoding)
- GSM 610 (must be included by an OEM in the run-time image)
- G.722.1 (must be included by an OEM in the run-time image)
- SIREN (must be included by an OEM in the run-time image)

Windows Embedded CE also supports other codecs, such as G.729 or G.723, if they are licensed and installed by the customer.

[muravei]

By default,Windows Embedded CE includes

Значит можно надеятся , что WM 6.1 на моем телефоне они могут быть?