Поиск датчика, снимающего данные: обернулся скупкой, наверно, всего барахла на алиэкспрессе (потому что продаваемые датчики, в т.ч. из-за особенностей организма человека, - оказались лютым непотребом). Однако подфартило: модуль ЭКГ AD8232 - дал хорошую картинку сердечного сигнала (за свои-то 374руб со скидкой). Далее этот модуль понемногу обрастал обвязкой, были написаны первичные исходники (тормознутая до безобразия телеметрия: 27Гц, плавно переходящая в 7Гц из-за особенностей SD.open()), исходники были несколько раз переписаны (вышел на 3.29кГц).

Чтобы понять, насколько всё плохо:

- Arduino Nano - самая дешёвая и малоконтактная платформа за 150руб, с самыми медленными процессорами. И пытаюсь в неё запихнуть не просто высокочастотное высокоточное измерение, быструю запись на microSD, прочие точные действия. Но ещё и обвес с кучей проводов (для ЭКГ-модуля требуется 5, для SD-модуля 6 и т.д.) - с сохранением компактности. Оперативная память 2КБ - практически закончилась, скоро счёт на десятки байтов пойдёт, ещё раз оптимизировать исходники придётся;

- выяснилось, что Serial выступает жутким тормозом частоты (в нормальных исходниках вышел на 280Гц, убрал 1 цикличную строку Serial - 1.8кГц, убрал вторую - 3.29кГц). То есть, на теоретическую скорость analogRead полагаться нельзя (как и на любые другие теории);

- даже SD.open() файла: если откроешь с параметром FILE_WRITE - чем больше файл, тем больше функция SD.write() будет лагать;

- что читать сначала при такой огромной скорости измерения: время или значение? Или вводить микросекундный сдвиг во времени, равный отрабатыванию команды считывания значения после считывания времени? Вводить ли отдельный таймер 1437.5нс?

Когда телеметрия начала писаться высокочастотно и высокоточно, и на SD стали появляться первые мегабайтные файлы, - обнаружилась проблема дальнейшей обработки полученной информации:

- если мне удалось выйти на 3.29кГц - то в интернете нет ТТХ холтеров (в т.ч. в инструкциях по эксплуатации) - неясно, какое число является оптимальным. ИИ пишет 200-1000Гц, но ему нельзя доверять: картинка-мем, где ИИ заявил о безвредности грибов, и потом вопрошающий сдох, - взялась не на пустом месте (а также представьте 200 точек в секундном графике, на котором пульс 4уд/с, - ну не хватит же). Значит, нужно ещё и графики сигналов сравнивать при разных частотах измерений: оценивать искажения относительно частоты измерений связки analogRead+Serial);

- что видит оператор, когда смотрит на телеметрию холтера, насколько ПО производителя искажает реальные данные? Если выводить все точки на график: большинство модулей отображения графиков языков программирования - попросту захлёбываются. А аппроксимировать или усреднять - не имеешь права: иначе, например, амплитуда пика сердцебиения (зубца R), будет искажена в низшую сторону - а тут уже недалеко до ложного результата слабости сердечной мышцы. Также покупное приложение холтера одновременно отображает несколько графиков - приложение на ПК, точно, многопоточное - а языки программирования и там работают по-разному.

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