@cool2000 - Встраиваю запись истории. Но беда с передачей. Не найти функции типа callback или другой, по которой возможно определить - передача Notify будет ещё возможна или нет (сводободны ресурсы?), предыдущие данные уже улетели или нет(?). Сейчас путем тупого запихивания блоков истории в Notify до ошибки выходит запихать всего 11 блоков.
Лог на приемной стороне:
22:54:05: Ответ на команду (35): 01000a040000b908b30fe10c
22:54:05: Ответ на команду (35): 0200f6030000ba08b30fe10c
22:54:05: Ответ на команду (35): 0300e2030000bb08b40fe10c
22:54:05: Ответ на команду (35): 0400ce030000bd08b50fe10c
22:54:05: Ответ на команду (35): 0500ba030000be08b70fe20c
22:54:05: Ответ на команду (35): 0600a6030000be08ba0fe20c
22:54:05: Ответ на команду (35): 070091030000be08c20fe10c
22:54:05: Ответ на команду (35): 08007d030000be08ba0fe00c
22:54:05: Ответ на команду (35): 090069030000bf08b30fe00c
22:54:05: Ответ на команду (35): 0a0055030000bf08b00fe10c
22:54:05: Ответ на команду (35): 0b0041030000c008b30fe20c
После 11 штук и HCI_bm_alloc() у Notify() переполняется.
А надо как-то знать, что пока не надо выуживать новый замер из истории в Flash, т.к. буфера Notify() уже забиты. И надо что-бы кто-то вызвал следующую итерацию, когда появится пустота в HCI_bm_alloc(). Иначе скорость передачи будет плачевная.
Вот в первом активном цикле данной пачки большинство и передаются, плевав на MTU и прочие. Т.е. как надо.
Далее уже идут согласования... Интервал соединения 30 мс, Latency 29 - это если ничего передавать, то сервер может не выходить на связь до (29+1) интервалов, но клиент всё равно должен ожидать приема в каждое событие интервала соединения со включением окна приема (т.е. каждые 30 мс без пропусков).
Если не забивать буфер у Notify под завязку, то скорость упадет до менее 1 пакета в интервал соединения.
А глубина памяти замеров на текущих прошивках - 30675 records.
На BT4.0 это будет более 30675*0.03 = 920.25 секунд. А можно выжать на 1M PHY BT4.2 к 1 минуте...
