Результаты поиска

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

оспидя... этой мудрости тыща лет в обед.... хочешь со всего тырнету случайных статеек сюда понадёргать?? расскажи, какое, это всё, имеет отношение к обсуждаемому контексту BLE где MTU куда скромнее TCP/IP - шных 1460 байт. или в головушке случился очередной гиперскачёк в TCP/IP? так НЕ...

смешно и совершенно не по делу впрочим я повторяюсь

не пишите про AdHoc, ибо каждый раз получается смешно и совершенно не по делу. если что не ясно, почитайте либо спросите у первоисточника.

?? причём тут это. BLE обсуждаем. жеж

хватит маняврировать.... что там с передачей двух пакетов?

TCP ? в BLE ? UDP? продолжай...

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

ссылка на запрещение бы не помешала причём тут батарейка? задача не сохранить батарейку а передать максимальнон количество данных - это разнонаправленные условия

думал HTML больше упоминаться не будет. после очевидной фактолоогии. ан нет... ошибался

это не ответ. это белый шум. я специально указал два пакета, их размеры и MTU

допустим MTU 300 байт, а пакеты для передачи получилсь 922 и 301 байт ваши действия? алгоритм, с кодом желательно

попробуйте аргументировать свои гипотезы-набросы

судя по вопросам вы пытаетесь базируясь на BLE MTU, ОРГАНИЗОВАТЬ ПРИМИТИВНУЮ передачу данных. пакеты которые длиннее MTU вызывают попоболь. прочитайте внимательно, что я Вам писал про раздробление AdHoc пакетов на несколько фрэймов транспортного протокола. c последущим восстановлением пакета...

не грусти, а то грудь не будет рости! бери StdProtocol котрый опирается на сервисы, предоставляемые нижним транспортным уровнем, Правда, правда, прям так и пишут

For unreliable, noisy channels with a high probability of errors, like UART over a radio, an improved, noise-protected version of the AdvProtocol protocol is used. It used CRC16 and Byte(0x55) stuffing framing for fast recovery after an error.

нужно конкретно брать и сравнивать. ненужно ничего увеличивать и уменьшать не нужно. AdHoc как газ, занимает весь выделенный объём. :D Работает ДАЖЕ поверх CAN протокола. Большой AdHoc пакет дробиться передатчиком на мелкие части, и собирается на приемнике. Всё работает даже если MTU будет...

пфф вернулся в привычный уклад.. покопался у себя... и нашел ZeroFormatter у них наиболее широкий охват по benchmarks и вот на что стоит обратить особое внимание ... то что всякие JSON привычно, многократно соснули... и это не зависит от платформ и имплементации, ага. бинарное...

все эти UUID/GATT это банальный API предопределенных, часто используемых функций... если они покрывают потребности пользователя, то и ОК. ему больше ничего не нужно а если недостаточно, то ВСЕГДА. ВСЕГДА (!) будет и есть UART. и гоняй поверх него хоть Protocol Buffers хоть ZCM хоть AdHoc ...

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