Другие похожие приложения действительно есть, я добавил скриншот одного из них в статью. Но я не смог найти приложение, которое поддерживало бы BLE датчики. Мне хотелось использовать COROS как запасной датчик, а в ANT он не умеет.
Что можно сказать точно про ускорения, что там пульс строго выше 180 ударов. А это порог когда 3 удара в секунду превращаются в 4 удара. Может тут есть какая-то связь.
Каденс шлёт сам датчик. Что вместо пульса начинает отображаться каденс - исключено.
Более интенсивно трётся футболка - возможно. На финишных ускорениях очень сложно думать своей головой.
Пульс также шлёт сам датчик, тут Гармин ничего не выдумывает при отрисовке.
Быстро погуглил. Сходу не нашёл как он считается и чем он так хорош.
Есть мысли посчитать DFA alpha 1. По слухам этот показатель может указать на первый порог. Но ему нужны очень точные интервалы HRV, чего я сейчас и пытаюсь добиться.
Если всем датчикам приходится работать с кардиограммой, как на моём первом графике ЭКГ - то никакой алгоритм тут не вытащит.
Хотя у меня были подозрения, что Polar может пытаться угадывать, когда должен был быть следующий удар. В случае нормальной работы сердца и правильном анализе HRV - примерное время будущего удара довольно очевидно.
Мои тесты показывают, что абсолютно любой датчик может как внезапно уплыть, так и стабильно работать достаточно долгое время. Не думаю, что тут будет какая-то принципиальная разница между брендами.
После моих опытов не думаю, что все эти модели как-то принципиально отличаются. Есть конечно разные поколения оптических датчиков. Более свежие будут точнее.
Но тесты показывают, что оптические подходят только для примерного измерения пульса. Хотя подавляющему большинству этого будет достаточно.
А нагрудные меня никогда не напрягали. Разве что сейчас три ремня одновременно вызывают лёгкий дискомфорт.
Я понятия не имею, как его надо калибровать. Он у меня живёт своей жизнью. Всегда думал, что он сам калибруется после нескольких пробежек с GPS. Как минимум, я бы на месте разработчиков сделал именно так.
У меня были отдельно мысли написать в перспективе алгоритм автоматической калибровки для Garmin HRM. Но пока собираю статистику и сконцентрирован на HRV.
Какой-нибудь "маргинальный браузер" это как раз мой проект :) Я не стал делать поддержку MJPEG без Content-Length. Были даже пользователи, которые жаловались на это. Возможно это как раз ваши пользователи.
У меня конечно есть поддержка автоматического поиска конца JPEG кадра. Но она работает только для формата, где кадры идут один за другим, без HTTP multipart заголовков. Возможно стоит усложнить код и MPJPEG формата (как его именует FFmpeg).
Кстати в таких глобальных проектах как ваш правильнее писать комменты на английском языке.
Спорное утверждение, что транспорт RTP UDP лучше для MJPEG потока, чем обычный HTTP. Но в образовательных целях статья отличная. Все особенности JPEG внутри RTP описаны довольно подробно и точно.
Кстати у браузера Chrome был (и возможно всё ещё есть баг), что он отображает MJPEG поток с задержкой в 1 кадр. То есть отображает прошлый кадр только когда прийдёт следующий. Чтоб эту задержку победить - можно написать свой собственный MJPEG клиент. Он тоже есть в вышеупомянутом проекте.
Вообще, Xiaomi шлюзы вполне себе умеют локальные автоматизации. Более того, они даже умеют локальные межшлюзовые автоматизации (когда датчик на одном шлюзе может включить устройство, привязанное к другому шлюзу).
Но если есть какие-то проблемы с настройкой локальной сети (чаще всего по вине самого пользователя) - автоматизации переходят в облачный режим.
Спасибо, интересно. У меня за пять лет получилось создать пару десятков проектов. Один на 8к звезд, два на 2к, два на 1к и ряд на 100+. Всё можно найти в профиле GitHub.
Практически никогда не пытался активно их двигать. Только несколько статей на habr и пара выступлений на конференциях.
На самом старте очень помогло, что известный YouTube блогер заметил и снял ролик про мой первый проект. Это дало большой приток аудитории и мотивации продолжать.
Ну и когда твой проект включают в состав других более крупных проектов, у меня это история про go2rtc, Frigate и Home Assistant - это тоже даёт колоссальный буст для роста аудитории.
UVC/MJPEG с минимальной задержкой и минимальной нагрузкой на CPU лучше всего передавать в MJPEG формате.
Недавно добавил в go2rtc нативную поддержку V4L2. Пробовали его на младшем Кинетике на процессоре MIPS. Тянет три USB камеры 1600х1200 + 640х480 + 640х480 с нагрузкой всего 5%.
Любые виды транскодинга будут сильно нагружать CPU и добавлять задержку.
1. Поддерживаемые форматы USB камеры можно посмотреть в веб интерфейсе go2rtc > Add > USB. Там же будут примеры, как лучше добавить эту камеру в конфиг.
2. Камера поддерживает MJPEG, а значит, при желании, можно получать поток в этом формате вообще без транскодирования. Нагрузка на CPU будет минимальной. Плюсом можно написать конфиг так, что на выходе будут и MJPEG и H264 потоки.
3. Снапшоты также выгоднее получать из MJPEG потока, так не будет транкодирования. Но если мы работаем с H264 потоком, то снапшоты в Telegram выгоднее отправлять в MP4 формате. Telegram такое поддерживает, и тут также не будет транскодирования.
Думаю практически все WiFi устройства от Sonoff поддерживают управление через подмену DNS. Из них большинство реле на новых прошивках поддерживает дополнительно локальный протокол. И некоторые устройства на супер старых прошивках поддерживают запасной протокол на основе WebSocket (сервер запускается на самом устройстве при отсутствии интернета).
Приходите к нам в чат Telegram. Так как раз вчера скинули свои варианты DIY по кофеваркам. С автоматическим включением и сливом мимо чашки.
Но что-то дорабатывать в готовом приборе это не мой стиль. Если внимательно посмотрите - все мои интеграции работают с устройствами в заводской комплектации без паяльников и прошивок.
Сейчас этот рандомайзер отличается менее чем на 1% от GPS на протяжении нескольких недель.
И я не могу использовать слово "ошибается". Потому что нет гарантий, что именно GPS выдаёт более точную дистанцию.
Спасибо за расширенный отзыв.
Другие похожие приложения действительно есть, я добавил скриншот одного из них в статью. Но я не смог найти приложение, которое поддерживало бы BLE датчики. Мне хотелось использовать COROS как запасной датчик, а в ANT он не умеет.
Примерно 206 максимум. Не меняется с самого начала занятий бегом, более 10 лет.
Рабочий полумарафон от 190 до 195. Также не меняется более 10 лет. 200 это был перебор в жару и по горкам.
На днях делал холтер - ненадолго ночью опускается ниже 50. Но в среднем пульс покоя 55 ударов.
Много вопросов.
Что можно сказать точно про ускорения, что там пульс строго выше 180 ударов. А это порог когда 3 удара в секунду превращаются в 4 удара. Может тут есть какая-то связь.
Каденс шлёт сам датчик. Что вместо пульса начинает отображаться каденс - исключено.
Более интенсивно трётся футболка - возможно. На финишных ускорениях очень сложно думать своей головой.
Пульс также шлёт сам датчик, тут Гармин ничего не выдумывает при отрисовке.
Быстро погуглил. Сходу не нашёл как он считается и чем он так хорош.
Есть мысли посчитать DFA alpha 1. По слухам этот показатель может указать на первый порог. Но ему нужны очень точные интервалы HRV, чего я сейчас и пытаюсь добиться.
Спасибо, посмотрю. Пока не нужно. Приложение не сильно популярное.
Если всем датчикам приходится работать с кардиограммой, как на моём первом графике ЭКГ - то никакой алгоритм тут не вытащит.
Хотя у меня были подозрения, что Polar может пытаться угадывать, когда должен был быть следующий удар. В случае нормальной работы сердца и правильном анализе HRV - примерное время будущего удара довольно очевидно.
Мои тесты показывают, что абсолютно любой датчик может как внезапно уплыть, так и стабильно работать достаточно долгое время. Не думаю, что тут будет какая-то принципиальная разница между брендами.
После моих опытов не думаю, что все эти модели как-то принципиально отличаются. Есть конечно разные поколения оптических датчиков. Более свежие будут точнее.
Но тесты показывают, что оптические подходят только для примерного измерения пульса. Хотя подавляющему большинству этого будет достаточно.
А нагрудные меня никогда не напрягали. Разве что сейчас три ремня одновременно вызывают лёгкий дискомфорт.
Я понятия не имею, как его надо калибровать. Он у меня живёт своей жизнью. Всегда думал, что он сам калибруется после нескольких пробежек с GPS. Как минимум, я бы на месте разработчиков сделал именно так.
У меня были отдельно мысли написать в перспективе алгоритм автоматической калибровки для Garmin HRM. Но пока собираю статистику и сконцентрирован на HRV.
У вас довольно известный и мощный проект.
Нашёл место о котором вы говорите
https://github.com/pikvm/ustreamer/blob/94752dde757cabde0e629f8b75d29e09e5ef2140/src/ustreamer/http/server.c#L647-L653
Какой-нибудь "маргинальный браузер" это как раз мой проект :)
Я не стал делать поддержку MJPEG без Content-Length. Были даже пользователи, которые жаловались на это. Возможно это как раз ваши пользователи.
У меня конечно есть поддержка автоматического поиска конца JPEG кадра. Но она работает только для формата, где кадры идут один за другим, без HTTP multipart заголовков. Возможно стоит усложнить код и MPJPEG формата (как его именует FFmpeg).
Кстати в таких глобальных проектах как ваш правильнее писать комменты на английском языке.
Спорное утверждение, что транспорт RTP UDP лучше для MJPEG потока, чем обычный HTTP. Но в образовательных целях статья отличная. Все особенности JPEG внутри RTP описаны довольно подробно и точно.
На реализацию того же самого на языке go можно посмотреть тут
https://github.com/AlexxIT/go2rtc/blob/master/pkg/mjpeg/rtp.go
Пару лет назад пришлось попотеть.
Кстати у браузера Chrome был (и возможно всё ещё есть баг), что он отображает MJPEG поток с задержкой в 1 кадр. То есть отображает прошлый кадр только когда прийдёт следующий. Чтоб эту задержку победить - можно написать свой собственный MJPEG клиент. Он тоже есть в вышеупомянутом проекте.
Вообще, Xiaomi шлюзы вполне себе умеют локальные автоматизации. Более того, они даже умеют локальные межшлюзовые автоматизации (когда датчик на одном шлюзе может включить устройство, привязанное к другому шлюзу).
Но если есть какие-то проблемы с настройкой локальной сети (чаще всего по вине самого пользователя) - автоматизации переходят в облачный режим.
Спасибо, интересно. У меня за пять лет получилось создать пару десятков проектов. Один на 8к звезд, два на 2к, два на 1к и ряд на 100+. Всё можно найти в профиле GitHub.
Практически никогда не пытался активно их двигать. Только несколько статей на habr и пара выступлений на конференциях.
На самом старте очень помогло, что известный YouTube блогер заметил и снял ролик про мой первый проект. Это дало большой приток аудитории и мотивации продолжать.
Ну и когда твой проект включают в состав других более крупных проектов, у меня это история про go2rtc, Frigate и Home Assistant - это тоже даёт колоссальный буст для роста аудитории.
UVC/MJPEG с минимальной задержкой и минимальной нагрузкой на CPU лучше всего передавать в MJPEG формате.
Недавно добавил в go2rtc нативную поддержку V4L2. Пробовали его на младшем Кинетике на процессоре MIPS. Тянет три USB камеры 1600х1200 + 640х480 + 640х480 с нагрузкой всего 5%.
Любые виды транскодинга будут сильно нагружать CPU и добавлять задержку.
Спасибо за статью. Пара дополнений по go2rtc:
1. Поддерживаемые форматы USB камеры можно посмотреть в веб интерфейсе go2rtc > Add > USB. Там же будут примеры, как лучше добавить эту камеру в конфиг.
2. Камера поддерживает MJPEG, а значит, при желании, можно получать поток в этом формате вообще без транскодирования. Нагрузка на CPU будет минимальной. Плюсом можно написать конфиг так, что на выходе будут и MJPEG и H264 потоки.
3. Снапшоты также выгоднее получать из MJPEG потока, так не будет транкодирования. Но если мы работаем с H264 потоком, то снапшоты в Telegram выгоднее отправлять в MP4 формате. Telegram такое поддерживает, и тут также не будет транскодирования.
Думаю практически все WiFi устройства от Sonoff поддерживают управление через подмену DNS. Из них большинство реле на новых прошивках поддерживает дополнительно локальный протокол. И некоторые устройства на супер старых прошивках поддерживают запасной протокол на основе WebSocket (сервер запускается на самом устройстве при отсутствии интернета).
Вроде кофеварка ругается, когда любой из этих параметров достигает критической величины. Заранее не ругается.
Этого пока в интеграции нет, но при случае добавлю.
Приходите к нам в чат Telegram. Так как раз вчера скинули свои варианты DIY по кофеваркам. С автоматическим включением и сливом мимо чашки.
Но что-то дорабатывать в готовом приборе это не мой стиль. Если внимательно посмотрите - все мои интеграции работают с устройствами в заводской комплектации без паяльников и прошивок.
Ну, кстати, кофеварки Jura до сих пор паяют. Кому-то проще припаять ESPшку, чем потратить пару дней на анализ Bluetooth-протокола :)