|
|
  |
Звук по CAN |
|
|
|
Feb 5 2011, 08:17
|
Участник

Группа: Участник
Сообщений: 40
Регистрация: 4-11-05
Пользователь №: 10 471

|
Доброго времени суток. Может не на этом формуме задаю вопрос, но уверен, что здесь масса людей которые могут мне помоч. Есть необходимость организовать передачу цифровой речи (качество не актуально) на расстояние до 50 метров. Подскажите возможно ли использование для этих целей CAN и сколько пар абонентов одновременно общающихся он выдержит. Звук планирую кодировать в MP3. Буду рад любым рассуждениям на данную тему. Заранее благодарен.
|
|
|
|
|
Feb 5 2011, 09:32
|
Знающий
   
Группа: Участник
Сообщений: 959
Регистрация: 11-01-06
Из: Санкт-Петербург
Пользователь №: 13 050

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

Ally
     
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050

|
Цитата(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 дуплексных разговорных каналов. Сейчас как раз работаю над таким демо проектом.
|
|
|
|
|
Feb 6 2011, 07:53
|
Участник

Группа: Участник
Сообщений: 40
Регистрация: 4-11-05
Пользователь №: 10 471

|
Спасибо за отзывы. Планируется разработка учебно-тренировочных средств по обучению работы на радиостанциях, поэтому появилась идея использовать идентификатор CAN-пакета, привязав его к частоте радиостредства, чтобы имитировать радиосвязь радиостанций настроенных на одну частоту. В качестве микроконтроллера планирую использовать AT91SAM7X256 (ранее его пользовал). В бюджете пока никто не ограничивал. Спасибо за полезные ссылки. Вообще, в плане цифровой обработки и передачи звука я не очень, поэтому буду весьма признателен если кто-нибудь еще поделится своими идеями. Может есть какие микросхемы аппаратного сжатия звука и как его передавать, может ссылки на готовые проекты? И вообще каким образом лучше реализовать данную тему. Заранее благодарен.
Сообщение отредактировал zpv - Feb 6 2011, 08:27
|
|
|
|
|
Feb 7 2011, 16:38
|
Участник

Группа: Участник
Сообщений: 40
Регистрация: 4-11-05
Пользователь №: 10 471

|
Цитата(Velund @ Feb 7 2011, 02:34)  Погуглите DVSI AMBE-2020 например. Редкая вещь. А не потянет ли AT91 алгоритм программного сжатия?
|
|
|
|
|
Feb 8 2011, 09:29
|
Участник

Группа: Участник
Сообщений: 45
Регистрация: 4-03-07
Пользователь №: 25 855

|
Цитата(zpv @ Feb 6 2011, 09:53)  Может есть какие микросхемы аппаратного сжатия звука и как его передавать, может ссылки на готовые проекты? И вообще каким образом лучше реализовать данную тему. Заранее благодарен. Посмотрите вот это, возможно подойдет. Мы применяем CMX618, даже при скорости 2400 и небольшом количестве потерянных данных качество и разборчивость речи хорошее. Единственно, кодек фреймовый, т.е. потеря любого одного или даже нескольких фреймов не страшна, но вот потеря части фрейма приводит к рассинхронизациии. Это просто надо учитывать при организации протокола передачи в линии. С доставаемостью CML'евских микросхем проблем не было. С реализацией на АРМе я бы лично не связывался, разве что с модулем поддержки ЦОС. ИМХО - это работа для всяческих DSP.
|
|
|
|
|
Mar 15 2011, 11:18
|
Группа: Участник
Сообщений: 5
Регистрация: 25-02-08
Пользователь №: 35 366

|
Цитата(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 каналов...
|
|
|
|
|
Mar 15 2011, 12:09
|
Участник

Группа: Участник
Сообщений: 15
Регистрация: 12-06-09
Пользователь №: 50 228

|
Из личного опыта скажу (в новом поезде метро Москвы стоит наша информационная система), звук по CAN очень плохое решение, реально возможен только один канал передачи данных на скорости 125 кб при кодировании обычного вав по мю закону, на 50 метров вам можно скорость конечно поднять.
|
|
|
|
|
Mar 15 2011, 12:59
|
Местный
  
Группа: Свой
Сообщений: 231
Регистрация: 7-12-06
Из: Киев
Пользователь №: 23 248

|
Цитата(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 это слишком круто для речи
|
|
|
|
|
Mar 15 2011, 13:20
|

бессмертным стать можно тремя способами
    
Группа: Свой
Сообщений: 1 405
Регистрация: 9-05-06
Из: Москва
Пользователь №: 16 912

|
как ни странно тема актуална для многих. сам тут заморочился подобным. для себя выбрал в качестве кодека 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 МГц я еще озвученное выше не делал но чтото сомневаюсь что тут на форуме никто к такому варианту не прилаживался, кто уже наверно делал и может расказать что получилось
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|