Обсуждение AdHoc бинарный протокол.

[pvvx]

Вам пример из древности, про формат простейшего звукового CD:

Весьма распространено мнение, что на CD-DA якобы нет защиты от ошибок чтения и что, как на грампластинке, любая пылинка или легкая царапинка приводит к сбоям в звуковом потоке, которые исправляются только путем сглаживания (интерполяции), что портит качество звучания диска. Говорят еще, что только на CD-ROM предусмотрены нормальное обнаружение ошибок и их коррекция.

На самом деле защита от ошибок в формате CD-DA есть, и весьма серьезная: информация как бы размазана по диску, и блоки собственно звуковых данных собираются при чтении из совершенно не смежных между собой кадров низкого уровня, а большинство возникших ошибок исправляются (корректируются) при помощи специального избыточного кода, способного исправлять как единичные, так и множественные ошибки. Избыточность (доля дополнительной информации в ее общем объеме) корректирующего кода Рида-Соломона в CD-DA составляет 25%, а поверх этого кода накладывается еще и канальный код 8/14, так что окончательная избыточность равна 57%. Иными словами, более половины всей информации на диске занимают проверочные и корректирующие данные.

Адресация звуковых блоков (кадров) в CD-DA выполняется по меткам в так называемых подканалах (subchannels), которые кодируются вместе со звуковой информацией. Один кадр имеет длительность 1/75 секунды и вмещает 2352 байтов данных (588 стереофонических звуковых отсчетов).

Формат CD-ROM базируется непосредственно на формате CD-DA. Помимо корректирующей способности CD-DA в CD-ROM имеется еще один уровень защиты от ошибок и их коррекции (дополнительно 12% избыточности), за счет чего надежность чтения CD-ROM заметно возрастает. Впрочем, это тоже не дает никакой гарантии, что хорошо видно на многих китайских дисках, которые надежно читаются только в первые несколько месяцев с момента выпуска. А затем «навороченность» привода уже перестает играть заметную роль, и диск надежно не читается нигде.

(источник: Точное копирование звуковых компакт-дисков)

Т.е. для получения минимального байта требуется забуферизировать целую дорожку с множественными кадрами. Что не выполняли китайские проигрыватели. Только проф.оборудование.

Вы идете тем-же путем – предельного китай-упрощения ради малого удешевления работы ведомого начинающего программера?
Креативные западные клоуны-дядьки вам написали кривые языки ради своей рекламы, а вы пытаетесь адаптировать их к устаревшим интерфейсам типа UART по причине детсадовских знаний современного аппаратного уровня?
Может стоит пойти другим, более правильным и коротким путем?

 

[cheblin]

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

прочитайте внимательно, что я Вам писал про раздробление AdHoc пакетов на несколько фрэймов транспортного протокола. c последущим восстановлением пакета на приёмнике.

с вашим подходом Вы НЕ сможете организовать эффективной передачи данных. у вас будут сплошные дыры в передачи, а не сплошной поток, как это происходит с AdHoc протоколом

 

[pvvx]

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

прочитайте внимательно, что я Вам писал про раздробление AdHoc пакетов на несколько фрэймов транспортного протокола. c последущим восстановлением пакета на приёмнике.

с вашим подходом Вы НЕ сможете организовать эффективной передачи данных. у вас будут сплошные дыры в передачи, а не сплошной поток, как это происходит с AdHoc протоколом

Если я раздроблю с помощью AdHoc на несколько фрэймов транспортного протокола, то теряю в совокупности по минимуму от 1/4 потока, а в среднем более 50% пропускной способности.
В итоге с AdHoc не получается достичь передачи и 2-х килобайт в сек (из возможных к 10..40 килобайт в сек на данном чипе при почти тех-же условиях)

 

[cheblin]

то теряю в совокупности по

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

 

[cheblin]

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

ваши действия? алгоритм, с кодом желательно

 

[pvvx]

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

Более конкретные характеристики:

Под одним номерком BLE characteristic передается более 25 типов структур (команды с данными).

AdHoc кодирует числа в своем формате, но поток от того-же ADC несжимаемый, что и-за специфики увеличивает размер пакета данных от ADC c меткой времени на 25% по минимуму.

Позволить это недопустимо – есть стек BT/BLE 5.0 с совмещением размера пакета BT 4.2, который формирует пакеты до 256 байт путем дробления – первый пакет всего 20 байт данных пользователя, последующие по 27 байт данных пользователя. На каждый пакетик требуется время передачи и прием подтверждения от приемника (с проверкой CRC в пакетике).

Постоянная передача категорически запрещена – забьем канал и сядет батарейка.

Для накопления данных более максимального MTU в большинстве BLE чипов тупо нет места в RAM. Данные от ADC получаем аппаратно в виде блока в RAM (DMA или какое FIFO). Остальные данные лежат в своих структурах.

Для формирования кодированного пакета в AdHoc требуется время и вторичный буфер, которого нема. И так уже есть дубли фрагментов в стеке BLE в виде статических и фиксированных на размер пакетика rx_fifo[64][2] и tx_fifo[40][8]. Накидать в стек побайтно – такой функции нема. При передаче байта используется полный буфер tx_fifo[40], а их всего 8 на всё.

Последовательно по байтам передавать не можем – на один байт уйдет по минимуму от 1..2 ms. Итог будет до 500 байт в сек при полной загрузке канала. По этому применяется метод отправки увеличенного пакета (корректнее с увеличенным MTU для совместимости разных версий BT/BLE).

Диаграммы затрат на передачу большего пакета вам приводил.

 

[pvvx]

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

ваши действия? алгоритм, с кодом желательно

Для ADC: По мере оцифровки, накопления в FIFO данных, передаю заголовок с фиксед байтом, далее метку времени (индекс пакета), далее данные до кратности специфики формирования пакетов в MTU BLE.
При FIFO требуется буфер для выемки с заголовком в 3 байта, на время передачи данных в стек BLE (он их распихает в свои буфера согласно очереди передачи).

 

[pvvx]

Код приемной стороны в HTML обработки пакета ADC, с формированием данных для графика:

        for (let i=2;i<value.byteLength;i+=2) {
            datau.push([cur_idx/smprate, value.getUint16(i,true)]);
            cur_idx++;
            if(cur_idx >= samples) datau.shift();
        }

 

[cheblin]

Для ADC: По мере оцифровки, накопления в FIFO данных, передаю заголовок с фиксед байтом, далее метку времени (индекс пакета), далее данные до кратности специфики формирования пакетов в MTU BLE.
При FIFO требуется буфер для выемки с заголовком в 3 байта, на время передачи данных в стек BLE (он их распихает в свои буфера согласно очереди передачи).

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

 

[cheblin]

в HTML обработки

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

 

[cheblin]

Постоянная передача категорически запрещена

ссылка на запрещение бы не помешала

и сядет батарейка

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

 

[pvvx]

ссылка на запрещение бы не помешала

А как будут работать другие устройства? У вас опять в голове UART?
Приемник шлюза и т.д. не резиновый и не умеет следить за всеми каналами сразу и каналов раз и обчелся...

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

Для кого как. Энергия не бесплатна. Поменяйте это на нашем шарике... Опять абстрактный отрешенный программер забыл про реальность?
----------
По коду:
Переносим указанное выше на TCP/IP, WebSocket, UDP, HTTP payload content / http multidata,... Код не меняется.
Даже на ModBus.
Все предоставляют разбивку на фреймы в низком уровне и к API.

Но вот при UART 9600 - да...

 

[cheblin]

А как будут работать другие устройства?

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

Энергия не бесплатна

вас опять колбасит...
давайте определяться крестик или трусы.
обсуждаемая высокоскоростная передача больших объёмов требует энергии. Ы?

 

[cheblin]

TCP/IP

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

 

[pvvx]

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

Все имеющиеся у пользователя и обывателя.
UART среди них нет. Нет такого разъема на PC или другом девайсе повседневного бытового применения.
Достаточно?

 

[cheblin]

хватит маняврировать....

что там с передачей двух пакетов?

 

[cheblin]

на PC

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

 

[pvvx]

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

Это давно понятно - у вас абстрактный UART и заморские креативные языки.
У нас проще - обычные чипы, вставляемые в разъемчики называемые в простонародье USB брелками или встроенными адаптерами с ограничениями - одын канал в одно время и несколько одновременных соединений с несколькими устройствами. Ограничение на кол-во одновременно отслеживаемых Services и их characteristic по соединениям у Win10, Android и т.д.

вас опять колбасит...
давайте определяться крестик или трусы.
обсуждаемая высокоскоростная передача больших объёмов требует энергии. Ы?

Т.е. для AdHoc необходим высокоскоростной канал peer-to-peer (т.е. одноранг) на полную загрузку чтобы никто более туда не влез без всяких маршрутизаций?
Почему эти особые и важные требования не описаны в заголовке?

 

[cheblin]

Почему эти особые

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

 

[pvvx]

Для непонимающих перефразируем “на банки”:

Вася может носить только ведро на 8 литров раз в 10 минут. У нас 7 клиентов и каждому надо доставить воду. AdHoc предполагает, что в ведро мы нальем побайтно (по 1 литру) каждому клиенту и 1 литр Васе на попить в дороге (1 бит для кодировки AdHoc), Вася пробежится по всем 7 клиентам за 10 минут до каждого и передаcт им по 1 литру воды, затем заправка. В итоге, для передачи каждому клиенту 7 литров затратим 7*7*10 = 490 минут и сгинет к 70 литров воды.

Если не использовать AdHoc то за 7*10= 1 час 10 минут мы передадим по 7 литров каждому клиенту, и Вася выпьет за данное время не более 1 литра.

Выгода от неиспользования AdHoc тут составляет более 10 раз.