Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Звук по CAN
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
zpv
Доброго времени суток. Может не на этом формуме задаю вопрос, но уверен, что здесь масса людей которые могут мне помоч. Есть необходимость организовать передачу цифровой речи (качество не актуально) на расстояние до 50 метров. Подскажите возможно ли использование для этих целей CAN и сколько пар абонентов одновременно общающихся он выдержит. Звук планирую кодировать в MP3. Буду рад любым рассуждениям на данную тему. Заранее благодарен.
Jury093
Цитата(zpv @ Feb 5 2011, 11:17) *
Есть необходимость организовать передачу цифровой речи (качество не актуально) на расстояние до 50 метров. Подскажите возможно ли использование для этих целей CAN и сколько пар абонентов одновременно общающихся он выдержит. Звук планирую кодировать в MP3. Буду рад любым рассуждениям на данную тему.

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

если коммерция, то я бы пошел, исходя из вопроса, по пути IP телефонии..
AlexandrY
Цитата(zpv @ Feb 5 2011, 10:17) *
. Есть необходимость организовать передачу цифровой речи (качество не актуально) на расстояние до 50 метров. Подскажите возможно ли использование для этих целей CAN и сколько пар абонентов одновременно общающихся он выдержит. Звук планирую кодировать в MP3.


Если речь, то MP3 здесь явно не в тему. Есть движки с лучшим сжатием до 4.8 Кбит/сек c нормальным качеством.
Как в этом проекте:
http://www.indemsys.ru/practical-electroni...ryptophone.html

Но нужен ARM с сопроцессором вычислений с плавающей точкой.
Как в этом проекте: http://www.indemsys.ru/products/46-armgeos...pyder2-pcb.html

Передавать по CAN аудио поток не сложнее чем любые другие файлы.
На 50 м можно сделать скорость 1 Мбит. Если принять коэффициент использования данными 0.8 то получаем 800 Кбит для всех аудиопотоков.
Итого получаем около 83 дуплексных разговорных каналов.
Сейчас как раз работаю над таким демо проектом.
Punk
Цитата(zpv @ Feb 5 2011, 11:17) *
Доброго времени суток. Может не на этом формуме задаю вопрос, но уверен, что здесь масса людей которые могут мне помоч. Есть необходимость организовать передачу цифровой речи (качество не актуально) на расстояние до 50 метров. Подскажите возможно ли использование для этих целей CAN и сколько пар абонентов одновременно общающихся он выдержит. Звук планирую кодировать в MP3. Буду рад любым рассуждениям на данную тему. Заранее благодарен.


А зачем, если не секрет, передавать звук по CAN ? Может езернет лучше? или, например, MOST
AlexandrY
Цитата(Punk @ Feb 5 2011, 20:03) *
А зачем, если не секрет, передавать звук по CAN ? Может езернет лучше? или, например, MOST


Последние ARM-ы просто позволяют это легко сделать. Почему собственно вопрос в теме про ARM-ы и появился подозреваю.
Передавать звук через езернет все и так умеют biggrin.gif

zpv
Спасибо за отзывы. Планируется разработка учебно-тренировочных средств по обучению работы на радиостанциях, поэтому появилась идея использовать идентификатор CAN-пакета, привязав его к частоте радиостредства, чтобы имитировать радиосвязь радиостанций настроенных на одну частоту. В качестве микроконтроллера планирую использовать AT91SAM7X256 (ранее его пользовал). В бюджете пока никто не ограничивал. Спасибо за полезные ссылки. Вообще, в плане цифровой обработки и передачи звука я не очень, поэтому буду весьма признателен если кто-нибудь еще поделится своими идеями. Может есть какие микросхемы аппаратного сжатия звука и как его передавать, может ссылки на готовые проекты? И вообще каким образом лучше реализовать данную тему. Заранее благодарен.
Velund
QUOTE (zpv @ Feb 6 2011, 10:53) *
Может есть какие микросхемы аппаратного сжатия звука и как его передавать


Погуглите DVSI AMBE-2020 например.
zpv
Цитата(Velund @ Feb 7 2011, 02:34) *
Погуглите DVSI AMBE-2020 например.

Редкая вещь. А не потянет ли AT91 алгоритм программного сжатия?
Shein
Цитата(zpv @ Feb 6 2011, 09:53) *
Может есть какие микросхемы аппаратного сжатия звука и как его передавать, может ссылки на готовые проекты? И вообще каким образом лучше реализовать данную тему. Заранее благодарен.

Посмотрите вот это, возможно подойдет.
Мы применяем CMX618, даже при скорости 2400 и небольшом количестве потерянных данных качество и разборчивость речи хорошее. Единственно, кодек фреймовый, т.е. потеря любого одного или даже нескольких фреймов не страшна, но вот потеря части фрейма приводит к рассинхронизациии. Это просто надо учитывать при организации протокола передачи в линии.
С доставаемостью CML'евских микросхем проблем не было.
С реализацией на АРМе я бы лично не связывался, разве что с модулем поддержки ЦОС. ИМХО - это работа для всяческих DSP.
Hann
Цитата(AlexandrY @ Feb 5 2011, 12:31) *
На 50 м можно сделать скорость 1 Мбит. Если принять коэффициент использования данными 0.8 то получаем 800 Кбит для всех аудиопотоков.
Итого получаем около 83 дуплексных разговорных каналов.
Сейчас как раз работаю над таким демо проектом.


Интересная арифметика получается. Если использовать CAN 2.0B, передавать 8 байт в пакете и взять в среднем 10 Stuffed Bits на весь пакет, то на каждые 64 бита полезной информации приходится 77 служебных бит или 0.45 от всего потока. И это при условии, что пакеты передаются без ошибок и нет повторных трансляций. Но даже если каким-то боком получится на 1Мбите протащить 800Кбит чистых данных, то давайте посчитаем ширину одного аудио-канала. В телефонии для нормальной передачи речи используется ширина канала порядка 3кГц (точно цифру не помню, но это и не существенно). По теореме Котельникова нужно иметь 30ksps. Даже если одна оцифровка имеет разрядность 8 бит то имеем 30ksps*8bit=240kbps. Или 480 Кбит в секудну на один дуплексный канал. Не понимаю как получилось воткнуть туда еще 80 каналов...
vovkaSOL
Из личного опыта скажу (в новом поезде метро Москвы стоит наша информационная система), звук по CAN очень плохое решение, реально возможен только один канал передачи данных на скорости 125 кб при кодировании обычного вав по мю закону, на 50 метров вам можно скорость конечно поднять.
SergeyDDD
Цитата(Hann @ Mar 15 2011, 14:18) *
Интересная арифметика получается. Если использовать CAN 2.0B, передавать 8 байт в пакете и взять в среднем 10 Stuffed Bits на весь пакет, то на каждые 64 бита полезной информации приходится 77 служебных бит или 0.45 от всего потока. И это при условии, что пакеты передаются без ошибок и нет повторных трансляций. Но даже если каким-то боком получится на 1Мбите протащить 800Кбит чистых данных, то давайте посчитаем ширину одного аудио-канала. В телефонии для нормальной передачи речи используется ширина канала порядка 3кГц (точно цифру не помню, но это и не существенно). По теореме Котельникова нужно иметь 30ksps. Даже если одна оцифровка имеет разрядность 8 бит то имеем 30ksps*8bit=240kbps. Или 480 Кбит в секудну на один дуплексный канал. Не понимаю как получилось воткнуть туда еще 80 каналов...


А вы про речевые кодеки почитайте

например:
http://ru.wikipedia.org/wiki/G.729

а их много разных

И на свой мобильный телефон взгляните. Это живой пример того "как"

Да и для 3kHz верхней частоты спектра 30ksps это многовато. Сигнал восстанавливается при удвоенной частоте квантирования - 6ksps
Кстате мультимедийная частота квантирования 44.1 ksps
А 30ksps это слишком круто для речи
klen
как ни странно тема актуална для многих. сам тут заморочился подобным. для себя выбрал в качестве кодека speex - хорош именно для речи, открытй, за использование mp3 нада будет платить лицензию или продавать изделия по серым схема в случае комерческого продутка, да и воще, speex лучше для речи - он для нее задуман изначально.
вот архив на пример как это делать предлагает ST на своих STM32 http://www.st.com/internet/com/SOFTWARE_RE...WARE/an2812.zip
разница в сорте и цвете микроконтроллера на мой взгляд не существенна.

Encoder Flash memory size in bytes 31844
Encoder RAM size in bytes 6456
Decoder Flash memory size in bytes 31636
Decoder RAM size in bytes 3680
Encoder + decoder Flash memory size in bytes 31904
Encoder + decoder RAM size in bytes 7216
Encoding CPU load in % 52
Decoding CPU load in % 8

я так понял что загрузка проца измерялась при 72 МГц

я еще озвученное выше не делал но чтото сомневаюсь что тут на форуме никто к такому варианту не прилаживался, кто уже наверно делал и может расказать что получилось
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.