Что такое bluetooth spp

Обновлено: 06.07.2024

Профиль последовательного порта определяет требования к устройствам Bluetooth, необходимые для настройки эмулируемых последовательных кабельных соединений с использованием RFCOMM между двумя одноранговыми устройствами. Требования выражены в терминах услуг, предоставляемых приложениям, а также в определении функций и процедур, необходимых для взаимодействия между устройствами Bluetooth.

По сути, профиль последовательного порта определяет протоколы и процедуры, которые должны использоваться устройствами, использующими Bluetooth для эмуляции последовательного кабеля RS232 (или аналогичного). абстракция виртуального последовательного порта (которая сама по себе зависит от операционной системы).

Для получения дополнительной информации: загрузите спецификацию K5 с веб-сайта SIG или посетите страницу документов.

Оглавление

< td width="67%">Соответствие < td width="67%">Пейджинг
5.1 Обзор профиля
5.1.1 Область
5.1.2 Стек протоколов
5.1.3 Роли/конфигурации
5.1.4 Сценарии профиля
5.1 .5 Основы профиля
5.1.6
5.2 Прикладной уровень
5.2.1 Обзор процедуры
5.2.2 Режим питания и обработка потери связи
5.3 Требования к интероперабельности RFCOMM
5.3.1 Управляющие сигналы RS232
5.3.2 Индикация состояния удаленной линии
5.3.3 Удаленное согласование портов
5.4 Требования к совместимости L2CAP
5.4.1 Типы каналов
5.4.2 Сигнализация
5.4.3 Параметры конфигурации
5.5 Требования к совместимости SDP< /td>
5.6 Требования к совместимости с Link Manager
5.6.1 LM Configura Параметры
5.6.2 Поведение при ошибках LM
5.6.3 Политика ссылок
5.7 Требования к совместимости контроллера связи
5.7.1 Запрос
5.7 .2 Сканирование запросов
5.7.3
5.7.4 Поведение при ошибке

5.1 Обзор профиля

5.1.1 Область применения

  • Доступ к локальной сети для одного устройства Bluetooth.
  • Доступ к локальной сети для нескольких устройств Bluetooth.
  • От ПК к ПК (с использованием сети PPP через эмуляцию последовательного кабеля).

Baseband , LMP и L2CAP — это протоколы Bluetooth уровня 1 и 2 OSI. RFCOMM — это Bluetooth-адаптация GSM TS 07.10, предоставляющая транспортный протокол для эмуляции последовательного порта. SDP — это протокол обнаружения службы Bluetooth.

Уровень эмуляции порта — это объект, эмулирующий последовательный порт или предоставляющий API для приложений. Приложения на обеих сторонах обычно представляют собой устаревшие приложения, способные и желающие обмениваться данными по последовательному кабелю (который в данном случае эмулируется). Но устаревшие приложения не могут знать о процедурах Bluetooth для настройки эмулированных последовательных кабелей, поэтому им нужна помощь от какого-то поддерживающего Bluetooth приложения с обеих сторон. (Эти проблемы явно не рассматриваются в этом профиле; основная проблема здесь связана с функциональной совместимостью Bluetooth.)

    Устройство A (DevA) — это устройство, которое берет на себя инициативу для установления соединения с другим устройством (DevA является инициатором в соответствии с «Конфигурациями/ролями» в GAP).
  • Устройство B (DevB) – это устройство, ожидающее, когда другое устройство проявит инициативу для подключения.(DevB является Принимающей стороной в соответствии с «Конфигурациями/ролями» в GAP). Обратите внимание, что порядок подключения (от DevA к DevB) не обязательно должен иметь какое-либо отношение к порядку запуска устаревших приложений на каждой стороне соответственно.
  • Настройка виртуальных последовательных портов (или эквивалентных) на двух устройствах (например, ПК) и их соединение с помощью Bluetooth для имитации последовательного кабеля между двумя устройствами. Любое устаревшее приложение можно запустить на любом устройстве, используя виртуальный последовательный порт, как если бы два устройства соединялись настоящим последовательным кабелем (с управляющей сигнализацией RS232).

Для этого профиля требуется поддержка только однослотовых пакетов. Это означает, что этот профиль обеспечивает возможность использования скорости передачи данных до 128 Кбит/с. Поддержка более высоких ставок не является обязательной.

В этом профиле одновременно обрабатывается только одно соединение. Следовательно, рассматриваются только двухточечные конфигурации. Однако это не должно толковаться как налагающее какие-либо ограничения на согласие; несколько запусков этого профиля должны выполняться одновременно на одном и том же устройстве. Это также включает одновременное выполнение двух разных ролей (как DevA и DevB).

  • Связывание явно не используется в этом профиле, поэтому поддержка связывания не является обязательной.
  • Установление связи инициируется DevA. Для настройки эмулируемого последовательного кабельного соединения необходимо выполнить процедуры обнаружения служб.
  • Фиксированных подчиненных ролей не существует.
  • RFCOMM используется для передачи пользовательских данных, сигналов управления модемом и команд конфигурации.

Когда заявлено соответствие этому профилю, все возможности, указанные как обязательные для этого профиля, должны поддерживаться указанным образом (процесс-обязательный). Это также относится ко всем необязательным и условным возможностям, для которых указана поддержка. Все обязательные возможности, а также дополнительные и условные возможности, для которых указана поддержка, подлежат проверке в рамках программы сертификации Bluetooth.

5.2 Прикладной уровень

  • При чтении GAP сторона A (инициатор подключения) эквивалентна DevA, а сторона B эквивалентна DevB.
  • Все обязательные требования, определенные в GAP, являются обязательными для этого профиля.
  • Если ниже не указано иное, все необязательные требования, определенные в GAP, не являются обязательными для этого профиля.
  1. Отправьте запрос с помощью SDP, чтобы узнать номер канала сервера RFCOMM нужного приложения на удаленном устройстве. Это может включать возможность просмотра, позволяющую пользователю выбирать среди доступных портов (или служб) на равноправном устройстве. Или, если точно известно, с какой службой связаться, достаточно найти необходимые параметры, используя идентификатор класса службы, связанный с нужной службой.
  2. При необходимости можно потребовать аутентификацию удаленного устройства. Кроме того, при необходимости включите шифрование.
  3. Запросите новый канал L2CAP для удаленного объекта RFCOMM.
  4. Инициировать сеанс RFCOMM на канале L2CAP.
  5. Запустите новое соединение канала передачи данных в сеансе RFCOMM, используя вышеупомянутый номер канала сервера.

После шага 5 виртуальное последовательное кабельное соединение готово к использованию для связи между приложениями с обеих сторон.

  1. По запросу удаленного устройства принять участие в процедуре аутентификации и, при дальнейшем запросе, включить шифрование.
  2. Принять индикацию установления нового канала от L2CAP.
  3. Принять установление сеанса RFCOMM на этом канале.
  4. Примите новое подключение канала передачи данных в сеансе RFCOMM. Это может инициировать локальный запрос на аутентификацию удаленного устройства и включение шифрования, если пользователь потребовал этого для подключения к эмулируемому последовательному порту (и процедуры аутентификации/шифрования еще не были выполнены).

Регистрация служебной записи в локальной базе данных SDP. Эта процедура относится к регистрации служебной записи для эмулируемого последовательного порта (или его эквивалента) в базе данных SDP. Это подразумевает наличие базы данных службы и возможность отвечать на запросы SDP.

Все сервисы/приложения, доступные через RFCOMM, должны предоставить запись сервиса SDP, которая включает параметры, необходимые для доступа к соответствующему сервису/приложению, см. Раздел 6.1. Для поддержки устаревших приложений, работающих на виртуальных последовательных портах, регистрация службы должна выполняться каким-либо вспомогательным приложением, помогающим пользователю в настройке порта.

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

Если используется режим прослушивания, парковки или удержания, ни DLC RFCOMM, ни канал L2CAP не освобождаются.

Если устройство обнаруживает потерю связи, RFCOMM считается отключенным. Перед возобновлением связи на более высоких уровнях необходимо выполнить процедуру инициализации сеанса RFCOMM.

5.3 Требования к интероперабельности RFCOMM

В этом разделе описываются требования к RFCOMM в устройствах, соответствующих профилю последовательного порта.

Согласно TS 07.10, раздел 5.4.6.3.7, все устройства должны отправлять информацию обо всех изменениях в управляющих сигналах RS232 с помощью команды состояния модема.

Однако, поскольку RFCOMM может использоваться с уровнем адаптации, реализующим любой тип API (не только виртуальные последовательные порты), необязательно использовать все сигналы управления RS232, кроме управления потоком (сигнал RTR в TS 07.10 [5]). . Этот сигнал может быть сопоставлен с RTS/CTS или XON/XOFF или другими механизмами API, что является проблемой реализации.

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

DevA может информировать DevB о настройках порта RS232 с помощью команды удаленного согласования порта непосредственно перед созданием DLC. Это необходимо сделать, если API для уровня адаптации RFCOMM раскрывает эти настройки (например, скорость передачи данных, четность). DevB разрешено отправлять команду удаленного согласования порта.

5.4 Требования к совместимости L2CAP

Следующий текст вместе со связанными подпунктами определяет обязательные требования в отношении этого профиля.

В этом профиле должны использоваться только каналы, ориентированные на соединение. Это означает, что в этом профиле не будут использоваться трансляции.

В поле PSM пакета запроса на подключение необходимо использовать значение RFCOMM, определенное в документе Assigned Numbers.

Только DevA может выдавать запрос на подключение L2CAP в рамках выполнения этого профиля. Помимо этого, профиль последовательного порта не накладывает никаких дополнительных ограничений или требований на передачу сигналов L2CAP.

Максимальная единица передачи: этот профиль не накладывает никаких ограничений на размер MTU сверх ограничений, указанных в спецификации L2CAP (в разделе 6.1).

Тайм-аут сброса: данные последовательного порта передаются по надежному каналу L2CAP. Для тайм-аута сброса должно быть установлено значение по умолчанию 0xffff.

Качество обслуживания: согласование качества обслуживания в этом профиле является необязательным.

5.5 Требования к совместимости SDP

Нет служебных записей SDP, связанных с профилем последовательного порта в DevA.

Чтобы получить служебные записи для поддержки этого профиля, объект клиента SDP в DevA подключается и взаимодействует с объектом сервера SDP в DevB с помощью процедур SDP и L2CAP, представленных в разделах «Обнаружение служб» и «L2CAP» SDAP. Согласно SDAP, DevA играет роль LocDev, а DevB — RemDev.

5.6 Требования к совместимости Link Manager

В дополнение к требованиям к поддерживаемым процедурам, указанным в самой спецификации Link Manager, этот профиль также требует поддержки шифрования как в DevA, так и в DevB.

Если модуль пытается использовать обязательную функцию, а другой модуль отвечает, что она не поддерживается, инициирующий модуль должен отправить LMP_detach с причиной отключения "неподдерживаемая функция LMP".

Блок всегда должен иметь возможность обработать отклонение запроса на дополнительную функцию.

Для выполнения этого профиля нет фиксированных ролей ведущий-ведомый.

В этом профиле не указаны какие-либо требования в отношении того, какие режимы с низким энергопотреблением использовать или когда их использовать. Это зависит от Link Manager каждого устройства, чтобы решить и запросить, как это будет уместно, в пределах ограничений требований к задержке.

5.7 Требования к функциональной совместимости Link Controller

5.7.1 Запрос

Когда запрос вызывается в DevA, он должен использовать общую процедуру запроса, см. «Режимы обнаружения» в профиле GAP. Только DevA может запрашивать выполнение этого профиля.

Для сканирования по запросу должен использоваться (как минимум) GIAC в соответствии с одним из режимов обнаружения, определенных в GAP. То есть разрешено использовать только ограниченный режим обнаружения, если он подходит для приложений, находящихся в DevB.

В сообщениях DevB INQUIRY RESPONSE поле Class of Device не будет содержать подсказок о том, участвует ли DevB в выполнении профиля последовательного порта или нет. (Это связано с тем, что обобщенная служба последовательного порта для устаревших приложений, предоставляемых этим профилем, не соответствует ни одному из основных битов класса обслуживания в определении поля «Класс устройства».)

5.7.3 Пейджинг

Только DevA может выполнять пейджинг в рамках выполнения этого профиля.Шаг пейджинга будет пропущен в DevA, когда начнется выполнение этого профиля, когда между DevA и DevB уже есть соединение основной полосы частот. (В таком случае соединение могло быть установлено в результате предыдущего пейджинга DevB.)

Поскольку большинство функций на уровне LC должны быть активированы процедурами LMP, ошибки в основном будут обнаруживаться на этом уровне. Однако есть некоторые процедуры LC, которые не зависят от уровня LMP, например. запрос или пейджинг. Злоупотребление такими функциями трудно, а иногда и невозможно обнаружить. Не существует определенного механизма для обнаружения или предотвращения такого ненадлежащего использования.

Примечание: приведенный выше текст содержит выдержки из спецификации Bluetooth SIG, а также различные интерпретации спецификаций. Полную информацию о различных разделах см. в действующей спецификации Bluetooth.

Профили Bluetooth – это дополнительные протоколы, основанные на базовом стандарте Bluetooth и позволяющие более четко определить, какие данные передает модуль Bluetooth. В то время как спецификации Bluetooth определяют, как технология работает, профили определяют, как она используется.

Профили, которые поддерживает устройство Bluetooth, определяют, для каких приложений оно предназначено. Например, гарнитура Bluetooth для громкой связи будет использовать профиль гарнитуры (HSP), а контроллер Nintendo Wii будет реализовывать профиль устройства с интерфейсом пользователя (HID). Чтобы два устройства Bluetooth были совместимы, они должны поддерживать одинаковые профили.

Давайте рассмотрим несколько наиболее часто встречающихся профилей Bluetooth.

Профиль последовательного порта (SPP)

Если вы заменяете последовательный коммуникационный интерфейс (например, RS-232 или UART) на Bluetooth, вам подойдет профиль SPP. SPP отлично подходит для отправки пакетов данных между двумя устройствами. Это один из наиболее фундаментальных профилей Bluetooth (первоначальная цель Bluetooth заключалась в том, чтобы заменить кабели RS-232).

При использовании SPP каждое подключенное устройство может отправлять и получать данные так же, как если бы между ними были соединены линии RX и TX. Например, два Arduino могут общаться друг с другом из разных комнат, а не из-за стола.

 Пример изображения SPP

Устройство с интерфейсом пользователя (HID)

HID — это профиль для устройств ввода данных с поддержкой Bluetooth, таких как мыши, клавиатуры и джойстики. Он также используется во многих современных игровых контроллерах, таких как контроллеры WiiMotes или PS3.

Пример изображения HID

Профиль Bluetooth HID на самом деле представляет собой вариацию на профиль HID, уже определенный для USB-устройств ввода данных человеком. Подобно тому, как SPP служит заменой кабелям RS-232, HID стремится заменить кабели USB (гораздо более сложная задача!).

Профиль громкой связи (HFP) и профиль гарнитуры (HSP)

Эти Bluetooth-наушники, из-за которых важные деловые люди выглядят болтливыми чокнутыми? Обычно они используют профиль гарнитуры (HSP) или профиль громкой связи (HFP).

HFP используется в аудиосистемах громкой связи, встроенных в автомобили. Помимо функций HSP, в нем реализовано несколько функций, позволяющих выполнять стандартные действия по телефону (прием/отклонение вызовов, завершение вызова и т. д.), когда телефон остается в кармане.

Расширенный профиль распространения аудио (A2DP)

Расширенный профиль распространения звука (A2DP) определяет способ передачи звука с одного устройства Bluetooth на другое. В то время как HFP и HSP отправляют звук на оба устройства и с них, A2DP является улицей с односторонним движением, но качество звука может быть намного выше. A2DP хорошо подходит для беспроводной передачи звука между MP3-плеером и стереосистемой с поддержкой Bluetooth.

Пример конфигурации A2DP

Большинство модулей A2DP поддерживают ограниченный набор аудиокодеков. По крайней мере, они будут поддерживать SBC (поддиапазонный кодек), а также могут поддерживать MPEG-1, MPEG-2, AAC и ATRAC.

Профиль дистанционного управления аудио/видео (AVRCP)

Профиль дистанционного управления аудио/видео (AVRCP) позволяет удаленно управлять устройством Bluetooth. Обычно он реализуется вместе с A2DP, чтобы удаленный динамик мог указать устройству, отправляющему звук, перемотать вперед, назад и т. д.

Умные считыватели RFID для СМАРТФОНОВ

Стартовый комплект RFID

IDBLUE подписывает N4 Systems Inc. в качестве авторизованного реселлера IDBLUE.HF / Что такое Bluetooth SPP и HID? Какая версия устройства мне нужна?

При подключении через Bluetooth наши устройства настроены на использование одного из следующих предопределенных профилей Bluetooth:

    – Устройство IDBLUE настроено с помощью драйвера последовательного порта Bluetooth, который может отправлять и получать команды с помощью нашего API IDBLUE. Это позволяет:
    • полный контроль пользовательского интерфейса и доступ ко всем функциям
    • интеграция с любым сторонним приложением
    • возможность чтения идентификатора тега или чтения/записи в пользовательскую память тега
    • для связи с нашим устройством требуется наш IDBLUE API.
    • HF-теги — идентификатор тега.
    • Теги УВЧ – код EPC из банка памяти EPC.

    Доступные способы связи

    Если вам нужно просто отсканировать идентификатор тега/код EPC в приложение, мы рекомендуем наши версии IDBLUE HID Bluetooth считывателя IDBLUE.HF и IDBLUE.UHF без необходимости в каком-либо дополнительном программном обеспечении. Если вам нужно интегрировать дополнительные функции через Bluetooth, мы рекомендуем наши версии IDBLUE SPP Bluetooth наших считывателей IDBLUE.HF или IDBLUE.UHF, которым потребуется наш API через наш IDBLUE SDK для управления устройством.

    ПРИМЕЧАНИЕ. Если вы хотите использовать нашу версию SPP Bluetooth в качестве клавиатуры:

    • Microsoft Windows: вы можете загрузить IDBLUE Keyboard Sender для Windows на странице «Драйверы устройств и программное обеспечение».
    • Google Android: вы можете загрузить IDBLUE Keyboard Wedge для Google Android на странице драйверов устройств и программного обеспечения.
    • Apple iOS: из-за ограничений и ограничений операционной системы клавиатурный клин для iOS недоступен.

    Оба типа наших устройств работают одинаково при подключении через USB через Windows с помощью нашего USB-драйвера IDBLUE для Windows и имеют доступ к полному набору функций наших ридеров.

    Для получения дополнительной информации вы можете связаться с нашим отделом продаж IDBLUE, чтобы узнать, какое устройство лучше всего соответствует вашим требованиям.

    Как известно, модуль Bluetooth делится на два типа: классический Bluetooth (BR/EDR) и Bluetooth с низким энергопотреблением (BLE).

    Существует множество профилей Classic Bluetooth и BLE: SPP, GATT, A2DP, AVRCP, HFP и т. д.

    Для передачи данных SPP и GATT являются наиболее часто используемыми профилями Classic Bluetooth и BLE соответственно.

    Что такое профиль SPP?

    SPP (профиль последовательного порта) — это классический профиль Bluetooth. SPP определяет требования к устройствам Bluetooth, необходимые для настройки эмулируемых последовательных кабельных соединений с использованием RFCOMM между двумя одноранговыми устройствами. Требования выражены в терминах услуг, предоставляемых приложениям, а также в определении функций и процедур, необходимых для взаимодействия между устройствами Bluetooth.

    Что такое профиль GATT?

    GATT (общий профиль атрибута — это профиль BLE, он определяет спецификации для двух устройств BLE для связи через службу и характеристику, две стороны связи GATT — это отношения клиент/сервер, периферийный — это сервер GATT, центральный — это клиент GATT, все коммуникации инициируются Клиентом и получают ответ от Сервера.

    Комбинация SPP+GATT

    SPP и GATT играют роль передачи данных, следует отметить, что при использовании модуля Bluetooth для связи с мобильным приложением для смартфона iOS BLE (GATT) является единственным поддерживаемым профилем двусторонней передачи данных, который можно использовать бесплатно, для Android-смартфона он поддерживает как SPP, так и GATT, поэтому важно, чтобы модуль поддерживал как SPP, так и GATT.

    Если модуль Bluetooth поддерживает и SPP, и GATT, это означает, что это двухрежимный модуль Bluetooth. Любые рекомендуемые двухрежимные модули Bluetooth?

    FSC-BT836B — это двухрежимный модуль Bluetooth 5.0, основная особенность которого — высокая скорость передачи данных, в режиме SPP скорость передачи данных составляет до 85 КБ/с, а в режиме GATT — до 75 КБ/с. (При тестировании с iPhone X).

    FSC-BT909 — это двухрежимный модуль Bluetooth 4.2, относящийся к классу 1, дальность передачи которого может достигать 500 метров при добавлении внешней антенны.

    Эти два модуля не очень подходят для вашего приложения? Свяжитесь с Feasycom прямо сейчас!

    Читайте также: