Вот тут описано что такое RR
http://www.physionet.org/tutorials/hrv/#inter-beat-rr-intervals
В двух словах - это интервалы между биениями сердца. В той же статье написано как визуализировать эти данные.
ВОт последовательность RR. Одна единица - это 1/128 секунды.
105 104 101 101 101 104 84 127
А вот кусок дампа:
Timer | Flag | Count | … Ticks (counter, flag: data) …
1953 | 0x00 | 1, 2 | 2FDh(765), 0x2: FDh(253) |
969 | 0x01 | 1, 0 | 2D7h(727), 0x2: D7h(215) |
1953 | 0x00 | 1, 1 | 2D6h(726), 0x2: D6h(214) |
2906 | 0x00 | 1, 1 | 2FCh(764), 0x2: FCh(252) |
Мне почему-то кажется, что data - это RR интервалы выраженные в 1/256 долях секунды.
То есть то есть пульс тут должен быть такой - 60 / (253/256) = 60,7 bpm; 60 / (214/256) = 71 bpm;
Вот тут
Парсер данных от какого-то bluetooth устройства Polar. Есть подозрение, что структура данных может быть похожа.
Вот что написано в каментах:
/** * An implementation of a Sensor MessageParser for Polar Wearlink Bluetooth HRM. * * Polar Bluetooth Wearlink packet example; * Hdr Len Chk Seq Status HeartRate RRInterval_16-bits * FE 08 F7 06 F1 48 03 64 * where; * Hdr always = 254 (0xFE), * Chk = 255 - Len * Seq range 0 to 15 * Status = Upper nibble may be battery voltage * bit 0 is Beat Detection flag. * * Additional packet examples; * FE 08 F7 06 F1 48 03 64 * FE 0A F5 06 F1 48 03 64 03 70 * * @author John R. Gerthoffer */ /** * Applies Polar packet validation rules to buffer. * Polar packets are checked for following; * offset 0 = header byte, 254 (0xFE). * offset 1 = packet length byte, 8, 10, 12, 14. * offset 2 = check byte, 255 - packet length. * offset 3 = sequence byte, range from 0 to 15. * * @param buffer an array of bytes to parse * @param i buffer offset to beginning of packet. * @return whether buffer has a valid packet at offset i */
ВОт лог из скайпа про Polar.
там они примерно одинаковую структуру имеют. Т.е. в виде бинарных данных там я не включал отображение, уже сразу в файлик расшифровыванные части скидывал
Значит,
1. в 8-м - там вначале идут мои пульсы на тот момент, чтобы примерно представлять, в каком диапазоне и как раскиданы данные
2. Поля:
TIMER - это не входит в пакет. Моя измерялка интервалов между пакетами.
FLAG (FLAG RR) - первое значение в пакете. какой-то флажок
COUNT (RR, REAL) - кол-во тиков в пакете. RR - это из RR-пакета (соотв. RR-функция),
REAL - это кол-во чеготонепонятного (из другой REAL-функции. Эти 2 функции вызываются параллельно, заканчивают работать одновременно и, соотв., что-то показывают)
TICKSRR - тики, данные в пакете. Каждый тик, предположительно, состоит из флага и данных. Каждый тик представлен: в 16-чном представлении 1) целиком, 2) флаг + данные;
и то же самое в 10-чном представлении 1) целиком, 2) флаг + данные
(TIMER измеряется в ms)
(я поменял форму отображения тиков TICKSRR в 8-м и 9-м файлика, а так по сути данные одни и те же)
Если надо, могу 1) сюда же включить и хексовое представление пакетов, 2) сделать другой вид отображения полей, 3) заменить TIMER на просто миллисекунды или убрать его
нафиг (по идее, полар сам меряет пульс)
В поляровской программе ProTrainer.exe используется 2 Dll-ки: hrmcom.dll и PolarWindLink.dll (насколько я понимаю, PolarWindLink - новая библиотека нижнего уровня для
протокола WindLink, hrmcom.dll - старая, для вообще девайсов полара, и она делает некоторые вызовы к PolarWindLink.dll)
Судя по трейсам (а отладка там запрещена - защищается программа с помощью привилегий. Поэтому у меня в распоряжении есть только внедряющийся трассировщик вызовов к
внешним библиотекам, типа этих вот. Я, правда, не пробовал еще SoftICE. Кстати, тоже мысль!)
Кароче! Судя по трейсам (могу выслать, кстати, трейсы) ProTrainer.exe в Online Record-режиме обращается к обоим библиотекам.
1) Он делает к hrmcom.dll несколько вызовов функций, видимо, стандартных для всех пульсометров (с любыми протоколами). Среди них - _fnHRMCom_GetRealOnlineData. Данные,
полученные с ее помощью помечены REAL. В дампах этих данных кроме первого поля только определенное кол-во тиков. В тиках только нули и посередине есть одна и та же
циферка. Первое поле - Count, кол-во тиков.
2) Кто-то (ProTrainer.exe или, скорее, hrmcom.dll) делает запрос к PolarWindLink.dll, вызывает функцию fnOnlineCom_GetRRPacket. Данные, получаемые из нее, помечены RR.
Они разные от вызова к вызову, поэтому RR-дампы и приведены в этих файлах.
И вот до кучи (просто чтобы сравнить, вдруг что-то полезное делается) я воткнул в выходной файл тот REAL-Count. Но есть вероятность, что его можно просто игнорировать.