Схемы, платы, компоненты

Какой канал связи -- вообще дело десятое. Подход не с того конца. Данные передавать в сыром виде не очень умная идея: домножай ширину канала в 5-10 раз. Далее, не всякий кодек допускает пропуск пакетов. Да и без кодека пропуск пакетов кончится неприятными щелчками по ушам, eсли пропуски частые это может стать фатальным недостатком, при том, что голос вообще разобрать можно. Нужен, стало быть повтор потерянных посылок, но он упирается в большую задержку передачи (ввиду необходимости наличия большого буфера на приёмной стороне), что делает крайне неудобным разговор, или очень маленькие пакеты и минимальные задержки во всём, что может не позволить канал связи. Или какая-то форма forward error correction. Или нужна какая-то форма экстраполяции сигнала при его отсутстии: телефонные кодеки, например, это имеют. Полудуплекс без приличного Voice Activity Detector рискует кончится полным крахом. Прекрасный пример тому всем любимый SIM300. Который не позволяет громкую связь в принципе, если хоть на одном конце (на другом не SIM300, а обычный стационарный телефон, например) звучит музыка или есть шум. Причина понятна: с той стороны, откуда идёт постоянный шумовой сигнал, по его мнению и есть разговор. Другая сторона глушится. Хохма в том, что в call-центрах в обычно в общем-то не тихо... И поэтому работа в режим радиостанции: нажал кнопку и говори -- не самая глупая идея. Если не сделать VAD или полный дуплекс. Но последнее ещё сложней, если действительно громкая связь, а не телефонные трубки -- т.к. требует акустическое эхоподавление (на мой взгляд весьма нетривиальная задача, т.к. фактически динамически должна строится матмодель для многочисленных эхо сигналов в пространстве, кроме того, VAD там тоже нужен...) Если делать полудуплекс, то для варианта с трубками нужен обязательно генератор шума (в тишине) и небольшой эхо-эффект (себя слышать). Иначе ощущение сломавшегося телефона очень сильно мешает (почему через дешёвые поделки IP-телефонии невозможно разговаривать). Переключение, возможно, стоит сделать как в Zello: начавший говорить имеет 6-секундный приоритет, но если через 6 секунд противоположная сторона не замолкает (начинает говорить), то включается она прерывая говорящего Иначе невозможно прервать говорящего, что очень сильно мешает, если последний заговорился. Может быть, использовав кодек по-лучше (или хотя бы IMA-ADPCM, если сейчас в сыром виде) можно и сделать дуплекс. Если говорить о ADPCM, то в каждом пакете можно передавать текущие параметры кодера (и декодера) и таким образом позволить пропуск пакетов (иначе всё пойдёт вразнос моментально). Можно, например, последний фрагмент повторять с затуханием амплитуды, при пропуске. Или исходники GSM 06.10 свободно доступны. Ещё можно на N переданных пакетов передавать N+1-й являющийся XOR всех пакетов и таким образом восстанавливать любой потерянный для небольших значений N (ибо задержка). Как сделать VAD не скажу. Можно подсмотреть в некоторых opensource программах для обработки звука и кодеках. Например в программном комплексе SoX (SOund eXchange) есть функция VAD. Но, боюсь, большая часть алгоритмов не для МК проф. уровня. Потом я не понял комментариев ниже про CAN, переключение уровней и др. чушь. Смешались в кучу люди, кони... Я подразумеваю, что уже есть какая-то сеть на базе RS485. Скорей один ведущий и много ведомых. Передача, естесственно, по запросу от мастера. Остальное требует какого-то арбитража. Сети с использованием CSMA/CD не работают при загрузке канала более 50% и могут давать большие задержки -- думаю лучше откинуть сразу, RS485 всё же не ethernet с многомегабитными скоростями. И не CAN, где есть аппаратный арбитраж. Соответственно, мастер передаёт, когда нужно, свои пакеты и запрашивает всегда (чтоб не усложнять на пустом месте) пакеты от ведомого, а последний передаёт или нет -- сам решает. Если тишина и полудуплекс -- не передаёт. Такую систему легко переделать на дуплекс, если нужно. И управляющую информацию передавать можно будет, отладочную информацию -- очень пригодится, уверен. Нужен какой-то способ совместить N последовательных каналов в одном RS485 канале. Что-то вроде HDLC. Идею передавать звук в сыром виде с направлением передачи определяемым микрофоном -- считаю дурной. PS: да и оцифровать весьма нетривиальная задача. Те же 8кГц на одной стороне -- будут 7.999 на другой стороне. И будет перманентная проблема затыкания из-за нехватки данных (и тут тоже противные щелчки) или переполнения буфера. Проявляться будет на длинных фрагментах речи в полудуплексе и всегда в дуплексе. Задача решена в настоящее время практически во всех аудио-видео проигрывателях. В ранние времена проблема отстающего-спешащего звука, наверное, все сталкивались... Нужен какой-то алгоритм ресэмплинга и согласования скорости на той стороне в динамике. В протоколе, стало быть, номер или метка времени для каждого пакета (на случай пропуска). Физически вывод в ЦАП скорей будет идти на порядок большей частоте, чем исходные 8кГц (чтоб не слышать ступеньку в виде свиста, а если там ADPCM, то он добавит ещё больше), т.е. вариант 8->80кГц с использованием zero stuffing, потом ФНЧ, потом выбираем из получившегося потока с чуть другим шагом. PPS: и таки тишина (но опять же нужен VAD) составляет ~половину времени, что позволит разгрузить канал связи и повысить качество передачи, возможно.