Низкая энергия Bluetooth - обновление значения признаков повторно

Последующий вопрос об электротехнике Stackexchange

Я хочу записать значение Низкоэнергетической характеристики Bluetooth за короткий промежуток времени (в качестве возможного варианта использования, представьте себе мышь).

Характеристика с 128-битным UUID имеет длину 20 байт. Поэтому он может быть написан в одной транзакции Low Energy.
Запись происходит со скоростью 50 Гц, что равно записи один раз каждые 20 мс.
Поэтому записываются 20 * 50 * 8 = 8 кбит/с.
Я использую режим Команда/ Запись без ответа, чтобы записать этот признак. Поэтому на уровне атрибута не происходит никаких подтверждений.
Никакие другие устройства Bluetooth или Bluetooth Low Energy не подключены. Ничего не выполняется по WLAN. Никакие другие характеристики не читаются или не записываются во время тестов.

Я тестирую программу, отправив пакеты с номерами последовательностей из iPhone 4S. Номер последовательности увеличивается на один после каждого отправленного пакета.

На принимающей стороне используется программируемая плата разработки, включающая

Ответ 1

Выдача обновления параметров соединения решила проблему и увеличила пропускную способность с 5 кбит/с до ~ 33 кбит/с. Однако это все еще ниже ожидаемого ~ 305 кбит/с.

Conn_Interval = 0x000f = 18.75 ms
Conn_Latency  = 0x0000
Supervision_Timeout = 0x00fc

Существуют ли какие-либо методы для достижения полного ~ 305 кбит/с?

Следующий вопрос по электротехнике Stackexchange

Можно получить ответ от Apple, сжигая TSI и ожидая в течение месяца.

В основном, они говорят, что поведение предназначено в iOS 5.1. Это как-то имеет смысл, потому что они не хотят, чтобы ваше приложение производительность зависит от того, использует ли другое приложение Bluetooth или WiFi.

В комментариях инженеров. В iOS 5.1 должно быть 6 пар уведомлений в течение интервала соединения, что означает   6 * пакетSize * 1000/интервал. Это должно перевести на ~ 55 кбит/с макс (мин.   интервал составляет 20 мс, пакет - 23 байта). Мы приняли решение   ограничить количество пар за интервал и получить минимальный интервал из-за   к тому, что iPhone и iPad имеют общую антенну между   BT classic, BT LE и WiFi.

iOS LE предназначен для транспортировки с низким энергопотреблением. Для более высокой пропускной способности BT classic является лучшим транспортным методом.

Назад ко мне - на основе комментариев инженеров выше, если желание достичь пропускной способности 200 кбит, классический Bluetooth - это ответ.   Однако, если желание работать с приложением на iPhone, я   может понять, что это не простое изменение - Classic BT требует MFI   лицензирования.

Ответ 2

Основная проблема заключается в том, что это проблема с буфером на используемом чипе. Из основной спецификации, том 3, часть F, 3.3.2:

Для уведомлений, которые не имеют ответ PDU, нет управления потоком, и уведомление может быть отправлено в любое время.

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

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