Вот тут описано что такое 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;

Вот тут

http://code.google.com/p/mytracks/source/browse/MyTracks/src/com/google/android/apps/mytracks/services/sensors/PolarMessageParser.java

Парсер данных от какого-то 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. Но есть вероятность, что его можно просто игнорировать.

Enter your comment. Wiki syntax is allowed:
 
  • linux_faq/polar-reverse-protocol.txt
  • Last modified: 2019/02/11 09:13
  • by 127.0.0.1