Я прочитал техническую спецификацию, и я пытаюсь понять, почему BLE 4.2 быстрее, чем BLE 4.1?Почему BLE 4.2 быстрее, чем BLE 4.1
Можем ли мы отправить более крупный размер пакета, чем 20 байтов, или это время соединения быстрее?
Я пытаюсь понять, что делает BLE 4.2 быстрее.
Единственное, что в Bluetooth 4.2, которое дает более высокий уровень по сравнению с предыдущим, - это расширение длины канального уровня. Это позволяет отправлять данные pdus длиной 251 байт вместо 27 байтов, что было предел раньше. Раньше это означало большие накладные расходы, если вы отправляли несколько пакетов из-за размеров заголовков и времени, необходимого между пакетами rx и tx и снова от tx до rx. Сами данные отправляются с 1 Мбит/с по воздуху.
Обратите внимание, что обе стороны должны поддерживать эту новую функцию, а новая максимальная длина должна быть согласована между устройствами до ее использования.
Здесь я объясню типичное событие соединения, в то время как центральный записывает несколько команд команды GATT Write по 20 байтов каждый. Поскольку скорость передачи составляет 1 Мбит/с по воздуху, для передачи требуется 1 мкс на бит. Верхние и нижние колонтитулы уровня канала состоят всего из 80 бит, состоящие из следующих: 1 байт преамбулы + 4 адреса доступа (материал для идентификации пакета для правильного адресата). 1 байт, содержащий поток/ack и тип данных. 1 байт, содержащий длину пакета. Затем идут данные, сопровождаемые 3-байтовой контрольной суммой CRC. Сам пакет пользовательских данных обернут в пакет ATT (3 байтовый заголовок с кодом операции и дескриптором ATT), который, в свою очередь, завернут в пакет L2CAP (2 байтовый идентификатор канала и 2 байта). Таким образом, большой 20-байтовый пакет теперь стал 37 байтами, которые отправляются по воздуху. По воздуху ведущий и подчиненный чередуются между отправкой и приемом. Поэтому, если мастер отправляет много пакетов данных, но ведомый ничего не отправляет, подчиненный должен все равно отвечать пустым пакетом с 80 битами заголовка. Кроме того, между всеми пакетами должно быть радиомолчание в течение 150 мкс, чтобы дать радио время для переключения между RX и TX. Таким образом, событие подключения 4-х пакетов заполнены 20 байт пользовательских данных каждый выглядит следующим образом: 1. Master -> Slave: 296 μs 1st packet 2. Silence 150 μs 3. Slave -> Master: 80 μs empty packet 4. Silence 150 μs 5. Master -> Slave: 296 μs 2nd packet 6. Silence 150 μs 7. Slave -> Master: 80 μs empty packet 8. Silence 150 μs 9. Master -> Slave: 296 μs 3rd packet 10. Silence 150 μs 11. Slave -> Master: 80 μs empty packet 12. Silence 150 μs 13. Master -> Slave: 296 μs 4th packet 14. Silence 150 μs 15. Slave -> Master: 80 μs empty packet Все это добавляет до 2554 мкс
С новым расширением длины пакета мы можем послать те же 80 байт в одном пакете (все еще накладные расходы на заголовок 17 байтов + CRC) = 97 байтов = 776 бит.
1. Master -> Slave: 776 μs packet 2. Silence 150 μs 3. Slave -> Master: 80 μs empty packet
Это добавляет только до 1006 мкс, более чем в два раза быстрее, чем раньше! Теперь радио доступно для обслуживания событий соединения из другого соединения.
Как вы видите, пропускная способность увеличена. Но для того, чтобы эта новая функция была полезной, вам нужно убедиться, что вы заполняете свое событие соединения пакетами. Разумеется, вы можете отправить один и тот же объем данных во время одного события соединения быстрее, но если вы просто простояте оставшееся время до следующего события подключения, вы действительно не отправляете данные быстрее.