• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Обсуждение 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

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

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

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

pvvx

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

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

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

cheblin

Member
допустим 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, с формированием данных для графика:
JavaScript:
        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

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

cheblin

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

pvvx

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

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

cheblin

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

pvvx

Активный участник сообщества
понятно, ссылки на запрет не будет.
как они будут работать это не мой головняк - это проблема нижележащего транспортного уровня. интересно как именно всё разруливаются? читайте мануал, а не несите ....набросы, это не ваше.
Это давно понятно - у вас абстрактный UART и заморские креативные языки.
У нас проще - обычные чипы, вставляемые в разъемчики называемые в простонародье USB брелками или встроенными адаптерами с ограничениями - одын канал в одно время и несколько одновременных соединений с несколькими устройствами. Ограничение на кол-во одновременно отслеживаемых Services и их characteristic по соединениям у Win10, Android и т.д.
вас опять колбасит...
давайте определяться крестик или трусы.
обсуждаемая высокоскоростная передача больших объёмов требует энергии. Ы?
Т.е. для AdHoc необходим высокоскоростной канал peer-to-peer (т.е. одноранг) на полную загрузку чтобы никто более туда не влез без всяких маршрутизаций?
Почему эти особые и важные требования не описаны в заголовке?
 

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 раз.
 
Сверху Снизу