Как мы уже знаем, никуда не деться от L2CAP, именно по его каналам сверху будет идти трафик AVDTP-протокола.
L2CAP канал в этом случае открывается с новым значением PSM, соответствующим протоколу AVDTP.

Один L2CAP канал открылся для сообщений сигнализации, второй для данных AVDTP, а третий для Audio/Video Control Transport Protocol (для передачи сигналов от колонки к источнику звука) инициировала колонка.

Обратите внимание на пары Source CID/Destination CID, это точки входа для L2CAP-каналов. Пара Src/Dst CID однозначно определяет L2CAP-канал.

После установления нужных L2CAP-каналов запустился процесс обмена служебными сообщениями между AVDTP-протоколами на обеих сторонах соединения. Среди служебных сообщений стоит отметить:

Команда Discover позволяет узнать у удаленного устройства, а, собственно, что конкретно оно может предложить в рамках аудио/видео передачи. В ответ должно прийти описание возможностей в виде списка Service Endpoints (точек предоставления сервиса).

На первый взгляд непонятно, почему у колонки две точки в роли “приемник аудио”. На этот вопрос отвечает следующая пара сообщений:

Обратите внимание на пару значений Min Bitpool и Max Bitpool, вскоре они сыграют важную роль.

Так как Klipsch KMC3 умеет понимать два кодека — обязательный для A2DP-устройства SBC кодек и опциональный, проприетарный AptX кодек — то мы и видим две точки предоставления AVDTP-сервиса, они отличаются только типом поддерживаемого кодека, не более того.


AptX vs SBC

После получения сведений о возможностях сервисных точек AVDTP протокол сообщением Set Config выбирает работу с кодеком AptX.

НЕ нашли? Не то? Что вы ищете?

Так было с Klipsch, но Edifier Spinnaker не поддерживает кодек AptX, поэтому его список сервисных точек состоял ровно из одной штуки с обязательным кодеком SBC (Low Complexity Subband Coding). В итоге дампы, снятые при установлении к двум системам, отличались лишь в выбранном кодеке передаваемого аудио!

Окей, но ведь AptX такой навороченный, платный, закрытый и пиарящийся на CeBITах, почему он, собака, начинает “замирать” в определенных условиях, и можно ли как-то заставить работать колонку Klipsch с SBC-кодеком, чтобы убедиться, что проблема именно в этом?

Для проверки я подключился к Edifier, повторил опыт с расположением ноутбука за своим телом во время записи дампа, и вот, что я увидел. Ниже представлен фрагмент AVDTP-протокола, содержащий в себе закодированный кодеком SBC фрагмент передаваемого аудио.

Т. к. SBC — кодек открытый, то в дампе можно увидеть относящуюся к нему информацию, связанную с передаваемыми аудиоданными. В спецификации A2DP подробно описана работа SBC-кодека, откуда можно выяснить, что одним из ключевых параметров, влияющих в итоге на качество кодирования, является значение bitpool.

Из дампа видно, что значение bitpool для данной порции трафика равно 48, но стоило мне закрыть телом путь от ноутбука до колонки, как значение bitpool стало снижаться, сопровождаясь прерываниями и щелчками.

После того, как значение bitpool устаканилось на уровне 30, щелчки пропали, проигрывание аудио стало вновь непрерывным. Все указывало на то, что кодек выполнил автоподстройку, заметив деградацию качества сигнала.

Но неужели я своим бренным телом вносил такое существенное затухание? Что ж, время взглянуть на график индикации уровня мощности принимаемого сигнала:

Хорошее тело, качественно вносит затухание, о которое и спотыкаются кодеки. Вот только SBC-кодек подстроился под эти условия, снизив качество кодирования, а тем самым и необходимую пропускную способность, а AptX, по-видимому, нет.

Чтобы окончательно убедиться в том, что виноват AptX, я отключил его поддержку в Mac OS X и снова стал домогаться до Klipsch. Теперь был согласован кодек SBC между макбуком и колонкой, т. к. AptX’а ноутбук был принудительно лишен. Стоит ли говорить, что с SBC-кодеком Klipsch перестал так сильно заикаться в условиях падения уровня мощности сигнала?

Долго ли коротко, но проблема диагностирована, и ввиду закрытости AptX у меня не было никаких шансов повлиять на работу кодека (как это можно сделать с SBC, задав вилку значений bitpool в OS X). Поэтому осталось лишь не маячить телесами на пути видимого сигнала или использовать трюк с отключением кодека AptX в макоси.

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

Расчёт параметров линии связи Bluetooth. Линк бюджет

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

Следующие параметры включены в основной расчёт линк бюджета:

    мощность передатчика усиление антенн (передающей и приёмной) потери в фидерном тракте (приёмника и передатчика) тип и размер антенн потери в среде распространения

Некоторые вторичные факторы напрямую или косвенно влияют на параметры линк бюджета:

    Чувствительность приёмника (это не часть реального линк бюджета, но параметр необходимый для подсчёта вероятности приёма сигнала) Требуемая дальность связи Доступная полоса пропускания Объем передаваемых данных Протоколы передачи данных Интерференция и функциональная совместимость

Выражение для простого линк бюджета:


где:        – мощность сигнала на приёмной стороне [дБм]

– мощность  передатчика [дБм]

– усиления в тракте (усиления приёмной и передающей антенн [дБ]

– потери при распространении [дБ]


Выражение (1) содержит различные усиления и потери между передатчиком и приёмником. При оценке линии связи, можно спроектировать систему так, чтобы удовлетворять потребности и возможности в пределах желаемой стоимости. Определённые потери могут изменяться во времени. Для примера период возрастания отношения числа поврежденных бит (BER) для цифровых систем или период спада отношения сигнал-шум (SNR) для цифровых систем.

Дальность связи

В беспроводной связи, дальность связи обычно определяется из потерь в свободном пространстве (FSPL - Free Space Path Loss). FSPL – модель потерь мощности сигнала электромагнитной волны, проходящей в области прямой видимости, т. е. модель не предполагает нахождения препятствий на пути прохождения сигнала и не учитывает такие явления как отражения и искривления волн. Потери - это сокращение мощности сигнала электромагнитной волны при её распространении сквозь свободное пространство.

Также потери происходят при преломлении, отражении, дифракции, рассеянии электромагнитной волны. Уровень влияния этих явлений обусловлен типом местности, окружением (городской или сельской местностью, растительностью и флорой), средой распространения (влажный или сухой воздух), расстоянием между приёмником и передатчиком, высотой антенны и местоположением. Модель потерь в свободном пространстве FSPL лучше всего работает для применения вне помещений при прямой видимости приёмника и передатчика, и высоко размещёнными антеннами.

Формула для расчёта потерь при свободном распространении:


где:

–уровень потерь сигнала при распространении в свободном пространстве[дБ];

– частота несущей радиоволны [МГц]

– расстояние между приёмником и передатчиком [км]

Выражение (2) подходит для расчёта идеального канала, для реального

Ко мне в руки попала интересная штуковина под названием XS-3868. Это встраиваемый модуль с чипом OVC3860, предназначенный для организации передачи данных и звука по Bluetooth протоколу. Мышка, интернет и принтер у меня уже давно подключаются к ноутбуку по воздуху, оставалось разобраться с проводами от акустики и решение было найдено в виде этого модуля.

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7