Звук по CAN Опции

[zpv]

Доброго времени суток. Может не на этом формуме задаю вопрос, но уверен, что здесь масса людей которые могут мне помоч. Есть необходимость организовать передачу цифровой речи (качество не актуально) на расстояние до 50 метров. Подскажите возможно ли использование для этих целей CAN и сколько пар абонентов одновременно общающихся он выдержит. Звук планирую кодировать в MP3. Буду рад любым рассуждениям на данную тему. Заранее благодарен.

[AlexandrY]

. Есть необходимость организовать передачу цифровой речи (качество не актуально) на расстояние до 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 дуплексных разговорных каналов.
Сейчас как раз работаю над таким демо проектом.

[Hann]

На 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 каналов...

[SergeyDDD]

Интересная арифметика получается. Если использовать 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 это слишком круто для речи