Ну какой алгоритм хеширования под капотом не особо заметно, если не писать свои инструменты для работы с git. Для 99% сценариев хеш коммита это просто некая последовательность буквенноцифровых символов уникально идентифицирующая коммит. Руками её не вычисляют, а просто копипастят из истории.
А вот названия веток задаются людьми, имеют определённый смысл и изменения здесь заметнее.
Во-первых, master, как правило, полностью контролирует slave (slave должен безоговорочно принимать любые обновления от master, а наоборот не может). Так что в принципе можно сказать, что один на положении раба, а другой хозяина - то есть максимальное неравноправие.
Во-вторых, слова master/slave многозначные и господин/раб лишь одно из возможных значений. Примерно как "тачка" обозначает и машину, и садовый инвентарь, которые имеют весьма отдалённое родство. Так и master/slave вне контекста отношений между живыми существами, значит что-то вроде "ведущий/ведомый", что подтверждается множеством применений именно в таком контексте в информатике и электронике.
Тем более, что в английском в целом распространены многозначные слова посильнее, чем в русском, так что это максимально нативно.
Там же сказано, что у высокоточных биение 5 микрон. Плюс все потери точности складываются. То есть допуск диаметра сверла 2 микрона, плюс допуск биения 5 микрон = итоговый допуск 7 микрон.
А между тем цанга, шпиндель и система позиционирования инструмента в целом тоже имеют не нулевую погрешность и низкая погрешность в одном месте позволяет иметь погрешность в другом месте тоже, где без неё никак.
Потом добавить конкретики, что именно пошло не так.
CF вполне себе делает посты с разборам полётов после крупных инцидентов. Но не во время инцидента. Во-первых, они могут сами не знать до конца, что случилось. Во-вторых, чтобы написать подробности нужно отвлечь одного из сотрудников, кто непосредственно занят расследованием (у кого как не у него будут подробности). В условиях, когда от тебя зависит пол-Интернета и нужно всё починить как можно скорее, отвлекать инженеров на написание пресс-релизов не очень разумно.
Об этом ещё нужно узнать. Человек гуглит информацию о фреймворке и получает материалы о двух фреймворках и ему требуется какое-то время, чтобы научиться быстро понимать релевантность материала (а до тех пор ловя всякие странные ошибки при копировании кода из разных источников). В случае с React все найденные материалы по умолчанию релевантны, как и библиотеки.
Был реакт на классах, стал реакт на хуках.
Да, но классами до сих пор можно пользоваться (то есть если человек найдет гайд под классы и воспользуюется им, его код будет работать). У людей есть две возможности делать одно и то же, одна из них оказалась удобнее другой в большинстве случаев и люди естественно чаще ей пользуются (тот кто сначала узнал про классы переходит на хуки, тот кто узнал про классы уже после хуков не начинает их везде пихать). При этом в принципе иногда встречаются сценарии, где классы удобнее.
В случае Angular или ты используешь один фреймворк, или другой. Никаких плавных переходов, никаких возможностей использовать разные стили кода под разные задачи, гайды от одного фреймворка не работают под другой, а названия близки до степени смешения.
В реакте полторы фичи (это же библиотека), там не чему терять обратную совместимость.
Вероятно, это тоже его секрет успеха. Они сделали достаточно удачную модель рендеринга (как минимум она не слишком тормозная и достаточно понятная разработчикам), а слой данных может эволюционировать независимо (хочешь redux, хочешь effector, хочешь своё пили на контекстах).
Судя по всему, слой данных гораздо сложнее сделать one size fits all и поэтому фреймворк без него имеет преимущество (потому что когда придумывают очередную систему сторов, в React не случается никаких ломающих изменений).
Не смог найти в PDF доступных по ссылке детали о предмете спора. Какое-то ООО взыскала с какого-то ИП 90 тысяч рублей за нарушение интеллектуальных прав. Не ясно, что именно там случилось и насколько оно подпадает под описываемое в статье.
Bluetooth очень маломощный, у него дальность метров 10.
WiFi помощнее, но чтобы клиент начал излучать, он должен поймать сигнал точки доступа. Сразу после отката самолёта от аэропорта это может быть только точка доступа на самолёте (так как дальность WiFi менее сотни метров). Раз мы её видим, кому-то можно излучать на этой частоте (причём именно этом конкретном канале WiFI, а не каком попало), значит и нам можно (оборудование самолёта WiFI не использует, а канал уже всё равно занят).
Режим точки доступа, кстати, на большинстве смартфонов остаётся заблокированным в режиме полёта, только режим клиента. То есть если все его включили, точка доступа может быть поднята только авиакомпанией, а она может выбрать свободную частоту, плюс выключать её на время взлёта и посадки (и все клиенты будут переставать излучать переставая видеть точку).
А вот у мобильной сети передатчики мощнее. А у базовых станций на земле передатчики ещё мощнее. И на малых высотах телефон легко будет ловить БС с земли и пытаться ответить. В итоге будет мощное радиоизлучение (так как БС далеко телефон будет выбирать максимальную мощность ответа) на широком наборе каналов без контроля со стороны авиакомпании.
У Raft логика, что большинство нод будут работоспособны (так как выберут нового лидера, если что). А отвалившееся меньшинство уйдёт в read-only (не смогут выбрать лидера, но если очень нужно, могут продолжать работать со старым состоянием). Когда связь восстановится, они догрузят с большинства все изменения, которые произошли за их отсутствие (своих изменений у них нет, так что конфликтов не будет), а потом продолжат нормальную работу.
Если допустить, что наиболее часто потеря связи с большинством нод означает потеряю связи с внешним миром вообще (например, сбой сетевого подключения), то проблем никаких нет. Нода физически не может отвечать на запросы и пофиг в каком она состоянии, а когда сможет отвечать на запросы, тогда же она и сможет подтянуть новые данные и отвечать актуально.
Вопрос "когда это случится" здесь не может быть задан к алгоритму, так как всё упирается в ситуацию вызвавшую сбой связи. Может сервер вообще физически сгорел и тогда ответом будет "никогда".
Если связь с большинством утеряна, но связь с внешним миром сохранилась, то у нас выбор - либо отвечать во внешний мир старые данные, отвергая запросы на запись, либо перестать отвечать на внешние запросы вообще (выбор зависит от конкретного ТЗ).
Опять же, магии здесь никакой нет. Если физически нет связи с большинством, нам неоткуда взять новые данные. Когда связь восстановится, тогда и получим свежие данные. Зависит от физического мира, а не алгоритмов.
Отдельный особый случай, когда связь с большинством не восстановится никогда (например, сгорел датацентр), обрабатывается админом вручную (ему нужно будет донести до меньшинства, что оно теперь большинство, а их копия данных - самая актуальная). Меньшинство без какого-то внешнего источника информации (причём по иному каналу связи нежели упавший канал связи с большинством) физически неспособно узнать, что большинства больше нет.
То есть Raft даёт вполне разумные гарантии там, где его область ответственности. Ответы на другие вопросы находятся на пределами информационной системы. Условно, чтобы узнать "когда" надо звонить провайдеру Интернета и спрашивать, никакая компьютерная программа не может рассчитать, когда его техники починят оптоволокно перебитое экскаватором.
Можно, конечно, отказаться от перехода в read-only при потере связи с большинством, но тогда это будет вообще другой класс распределённых систем, которые устраивает, что ноды находятся в разном состоянии и что у нас постоянно возникают конфликты синхронизации и их надо решать. Raft не для таких систем, а там где нужно быть уверенным, что конфликтов не будет и всегда есть основная рабочая версия данных (а те у кого основной рабочей версии нет могут быстро понять это и либо перейти в RO, либо перестать обслуживать запросы вообще).
Смейк плох, но он используется большинством современных библиотек и поддерживается всеми популярными IDE. В том числе потому что в нём есть всякие фичи типа экспорта compile commands в JSON (и его архитектура позволила это сделать).
Остальные системы сборки используются в 3.5 проектах и почти не поддерживаются в IDE, либо фундаментально не позволяют нормальную поддержку инструментами (например, потому что система сборки это тупо самописный скрипт и compile commands генерировать получиться только руками).
Есть вариант сказать гуглу, что я забыл пароль, и сгенерить keystore заново, но пару дней вы не сможете публиковать приложение. Все еще не могу взять в толк, зачем нужно было устраивать такой цирк, а не использовать приватный ключ у разработчика и публичный у гугла
В общем-то так оно и сделано, но с каких-то пор появилась опциональная возможность делегировать генерацию ключа в Google.
Android со своего появления позволял ставить приложения из файлов APK, но это потенциально уязвимость - вдруг юзер скачает с какого-нибудь сайта "мод на бесконечные деньги в Сбербанк", который под капотом отправляет все учётные данные пользователя автору. Или ревнивый партнер или спецслужбы обойдут блокировку пинкодом на мессенджере просто накатив поверх модифицированный APK с бекдором (заметно или даже незаметно для юзера).
Поэтому в Android у каждого APK есть цифровая подпись. Система отказывается ставить APK поверх уже установленного приложения с другой цифровой подписью. Как минимум юзеру будет лишний повод задуматься "точно ли я знаю, что делаю?", как максимум, придётся сначала удалить руками старую версию приложения с другой подписью со всеми данными, авторизациями и т. д. Соответственно, приложение с другой подписью не сможет облегчить доступ к чему-то запароленному, а ещё не пройдёт незаметно.
Шло время и приложения опубликованные на Google Play пухли. В итоге Google захотел сделать Android App Bundle - новый формат приложений, который предполагал переупаковку на стороне сервера с выкидыванием всего лишнего на конкретном устройстве пользователя, который качает приложение (например, оставить в APK только одну версию нативных библиотек под нужную архитектуру, а не 2-4 под все поддерживаемые Android, оставить графические ресурсы только под DPI устройства и т. д.). Но возникла проблема - каким ключом Google будет подписывать перепакованный APK? Если новым, своим, то не получится обновить уже установленные приложения до введения фичи, а ещё будет невозможно обновлять приложения полученные из других источников (например, скачанные с официального сайта разработчика) без переустановки.
И Google Play придумал давать разработчикам выбор - он сгенерирует ключ за них (актуально для новых приложений и не очень опытных разработчиков, для которых снижается порог входа) или же разработчик отправляет свой ключ в Google (актуально для старых приложений и для разработчиков, которые по каким-то причинам хотят больше контролировать процесс выпуска ключа, например, чтобы было чем подписывать пререлизную версию приложения до публикации в магазине, а потом ничего не ломать).
Также не забываем, что помимо распространения APK есть ещё альтернативные маркеты и хочется, чтобы можно было поставить приложение из одного и потом без проблем обновить другим.
сказать гуглу, что я забыл пароль, и сгенерить keystore заново
Есть шанс, что после такого финта старые установки приложения не смогут обновиться и будет необходимо переустанавливать приложение.
Первый вопрос: а какая точность по времени у выхода GNSS приёмника? В смысле какая максимальная гарантированная разница между таймингами прихода импульсов от этих конкретных моделей приёмников разнесенных на несколько сотен метров?
Просто если можно запустить АЦП в свободным режиме на высокой частоте, а по сигналу лишь выбирать какие группы импульсов усреднять, то это было бы проще и надёжнее. Но, конечно, если приемник может выдавать сигналы очень точно, то не прокатит.
Ну и в целом, я бы такой проект начинал с анализа предела точности, чтобы знать, что можно добиться на этом оборудовании, а что нельзя (либо чтобы выбирать, собственно, приемники, если их можно выбирать разные).
Хотя и в таком случае правильно было бы использовать свободный режим. Просто вычислить локально время между импульсами от приёмника, вычислить время от подачи сигнала запуска до первого измерения и, получив очередной импульс, выждать разницу первого и второго и самостоятельно выдать сигнал старта, чтобы получить результат аккурат к следующему импульсу. Можно периодически повторять калибровку, если устройство работает неделями и месяцами.
Дело в том, что у АЦП может отличаться точность в свободном и одиночном режиме, причём в случае сигма-дельта АЦП - свободный режим точнее. Кстати, и время между замерами может быть более круглое, чем время одиночного замера.
Наконец, конечно, там лучше подходит не малинка, а ESP32 и аналоги. Та же поддержка WiFi, но риалтайм из коробки без заморочек с модулями ядра. Плюс компактнее и меньше жрёт. По сложности программирования должно быть легко за счёт Arduino SDK, который осваивается прямо по ходу разработки, если уже есть знакомство с embedded.
500 баксов это в разы ниже минимального порога оплаты труда в любой развитой стране. Так что робот таки дешевле за счёт того, что индус останется в Индии.
Как я понял из статьи прибалты стремятся всеми правдами и неправдами прессовать россиян за связь с Россией и для этого толкуют санкции максимально строго. Остальные в принципе не жестят и претензии предъявляют к тем, кто реально живёт больше в России, чем у них (например, руководит парой российских фирм).
Мне помогло закрыть счёт в одном крупном банке написав огромный отзыв на banki.ru. До него техподдержка отвечала "где карту получали, там и закрывайте", а после отзыва они в течении суток со мной связались (причём согласились позвонить на иностранный номер, чтобы у меня не было платы за роуминг) и всё порешали.
С такими законами, по которым под УК подпадает пол населения страны, они выборочно применяются.
Применяющие не дураки и понимают, что миллионы уголовных дел ни правоохранительная и судебная система не пережует, ни экономика (одновременно выбывание миллионов людей из экономической жизни), да и с политической точки зрения есть проблемы (обычно за раз теснят какую-то небольшую группу людей, чтобы большинство могло сказать "моя хата с краю и вообще они сами виноваты").
Так что Неуловимый Джо может пиратить, пока не перейдёт кому-то дорогу или пока Товарищ Майор не захочет повышение, а он окажется не в то время не в том месте.
Возможно, они целятся в сегмент демо плат для бизнеса (на которых в том числе делают ранние прототипы будущих серийных устройств). Типа "с нашей платой сможете брать на работу тех, кто умеет работать с Arduino".
Всякие фичи типа шифрования прошивки (да и деление прошивки на доверенную и недоверенную) в DIY не имеют смысла от слова совсем. А вот бизнесу интересно.
Ну какой алгоритм хеширования под капотом не особо заметно, если не писать свои инструменты для работы с git. Для 99% сценариев хеш коммита это просто некая последовательность буквенноцифровых символов уникально идентифицирующая коммит. Руками её не вычисляют, а просто копипастят из истории.
А вот названия веток задаются людьми, имеют определённый смысл и изменения здесь заметнее.
Во-первых, master, как правило, полностью контролирует slave (slave должен безоговорочно принимать любые обновления от master, а наоборот не может). Так что в принципе можно сказать, что один на положении раба, а другой хозяина - то есть максимальное неравноправие.
Во-вторых, слова master/slave многозначные и господин/раб лишь одно из возможных значений. Примерно как "тачка" обозначает и машину, и садовый инвентарь, которые имеют весьма отдалённое родство. Так и master/slave вне контекста отношений между живыми существами, значит что-то вроде "ведущий/ведомый", что подтверждается множеством применений именно в таком контексте в информатике и электронике.
Тем более, что в английском в целом распространены многозначные слова посильнее, чем в русском, так что это максимально нативно.
Там же сказано, что у высокоточных биение 5 микрон. Плюс все потери точности складываются. То есть допуск диаметра сверла 2 микрона, плюс допуск биения 5 микрон = итоговый допуск 7 микрон.
А между тем цанга, шпиндель и система позиционирования инструмента в целом тоже имеют не нулевую погрешность и низкая погрешность в одном месте позволяет иметь погрешность в другом месте тоже, где без неё никак.
CF вполне себе делает посты с разборам полётов после крупных инцидентов. Но не во время инцидента. Во-первых, они могут сами не знать до конца, что случилось. Во-вторых, чтобы написать подробности нужно отвлечь одного из сотрудников, кто непосредственно занят расследованием (у кого как не у него будут подробности). В условиях, когда от тебя зависит пол-Интернета и нужно всё починить как можно скорее, отвлекать инженеров на написание пресс-релизов не очень разумно.
Тогда бы была не заглушка CloudFlare со скриншотов, а заглушка провайдера или просто ошибка подключения браузера.
Внешние сервисы мониторинга типа downdetector тоже фиксируют сбой
Оно то работает, то не работает, вам просто повезло
Об этом ещё нужно узнать. Человек гуглит информацию о фреймворке и получает материалы о двух фреймворках и ему требуется какое-то время, чтобы научиться быстро понимать релевантность материала (а до тех пор ловя всякие странные ошибки при копировании кода из разных источников). В случае с React все найденные материалы по умолчанию релевантны, как и библиотеки.
Да, но классами до сих пор можно пользоваться (то есть если человек найдет гайд под классы и воспользуюется им, его код будет работать). У людей есть две возможности делать одно и то же, одна из них оказалась удобнее другой в большинстве случаев и люди естественно чаще ей пользуются (тот кто сначала узнал про классы переходит на хуки, тот кто узнал про классы уже после хуков не начинает их везде пихать). При этом в принципе иногда встречаются сценарии, где классы удобнее.
В случае Angular или ты используешь один фреймворк, или другой. Никаких плавных переходов, никаких возможностей использовать разные стили кода под разные задачи, гайды от одного фреймворка не работают под другой, а названия близки до степени смешения.
Вероятно, это тоже его секрет успеха. Они сделали достаточно удачную модель рендеринга (как минимум она не слишком тормозная и достаточно понятная разработчикам), а слой данных может эволюционировать независимо (хочешь redux, хочешь effector, хочешь своё пили на контекстах).
Судя по всему, слой данных гораздо сложнее сделать one size fits all и поэтому фреймворк без него имеет преимущество (потому что когда придумывают очередную систему сторов, в React не случается никаких ломающих изменений).
Не смог найти в PDF доступных по ссылке детали о предмете спора. Какое-то ООО взыскала с какого-то ИП 90 тысяч рублей за нарушение интеллектуальных прав. Не ясно, что именно там случилось и насколько оно подпадает под описываемое в статье.
Есть закон, а есть правоприменительная практика. Надо разбирать конкретные дела или хотя бы рекомендации ведомств.
Пока заметил только, что он отвечает гораздо медленнее, чем gpt5. И всё так же продолжает выдумывать слова при ответах на русском.
Bluetooth очень маломощный, у него дальность метров 10.
WiFi помощнее, но чтобы клиент начал излучать, он должен поймать сигнал точки доступа. Сразу после отката самолёта от аэропорта это может быть только точка доступа на самолёте (так как дальность WiFi менее сотни метров). Раз мы её видим, кому-то можно излучать на этой частоте (причём именно этом конкретном канале WiFI, а не каком попало), значит и нам можно (оборудование самолёта WiFI не использует, а канал уже всё равно занят).
Режим точки доступа, кстати, на большинстве смартфонов остаётся заблокированным в режиме полёта, только режим клиента. То есть если все его включили, точка доступа может быть поднята только авиакомпанией, а она может выбрать свободную частоту, плюс выключать её на время взлёта и посадки (и все клиенты будут переставать излучать переставая видеть точку).
А вот у мобильной сети передатчики мощнее. А у базовых станций на земле передатчики ещё мощнее. И на малых высотах телефон легко будет ловить БС с земли и пытаться ответить. В итоге будет мощное радиоизлучение (так как БС далеко телефон будет выбирать максимальную мощность ответа) на широком наборе каналов без контроля со стороны авиакомпании.
У Raft логика, что большинство нод будут работоспособны (так как выберут нового лидера, если что). А отвалившееся меньшинство уйдёт в read-only (не смогут выбрать лидера, но если очень нужно, могут продолжать работать со старым состоянием). Когда связь восстановится, они догрузят с большинства все изменения, которые произошли за их отсутствие (своих изменений у них нет, так что конфликтов не будет), а потом продолжат нормальную работу.
Если допустить, что наиболее часто потеря связи с большинством нод означает потеряю связи с внешним миром вообще (например, сбой сетевого подключения), то проблем никаких нет. Нода физически не может отвечать на запросы и пофиг в каком она состоянии, а когда сможет отвечать на запросы, тогда же она и сможет подтянуть новые данные и отвечать актуально.
Вопрос "когда это случится" здесь не может быть задан к алгоритму, так как всё упирается в ситуацию вызвавшую сбой связи. Может сервер вообще физически сгорел и тогда ответом будет "никогда".
Если связь с большинством утеряна, но связь с внешним миром сохранилась, то у нас выбор - либо отвечать во внешний мир старые данные, отвергая запросы на запись, либо перестать отвечать на внешние запросы вообще (выбор зависит от конкретного ТЗ).
Опять же, магии здесь никакой нет. Если физически нет связи с большинством, нам неоткуда взять новые данные. Когда связь восстановится, тогда и получим свежие данные. Зависит от физического мира, а не алгоритмов.
Отдельный особый случай, когда связь с большинством не восстановится никогда (например, сгорел датацентр), обрабатывается админом вручную (ему нужно будет донести до меньшинства, что оно теперь большинство, а их копия данных - самая актуальная). Меньшинство без какого-то внешнего источника информации (причём по иному каналу связи нежели упавший канал связи с большинством) физически неспособно узнать, что большинства больше нет.
То есть Raft даёт вполне разумные гарантии там, где его область ответственности. Ответы на другие вопросы находятся на пределами информационной системы. Условно, чтобы узнать "когда" надо звонить провайдеру Интернета и спрашивать, никакая компьютерная программа не может рассчитать, когда его техники починят оптоволокно перебитое экскаватором.
Можно, конечно, отказаться от перехода в read-only при потере связи с большинством, но тогда это будет вообще другой класс распределённых систем, которые устраивает, что ноды находятся в разном состоянии и что у нас постоянно возникают конфликты синхронизации и их надо решать. Raft не для таких систем, а там где нужно быть уверенным, что конфликтов не будет и всегда есть основная рабочая версия данных (а те у кого основной рабочей версии нет могут быстро понять это и либо перейти в RO, либо перестать обслуживать запросы вообще).
Можно поддерживать самое популярное, что уже много лет CMake.
Смейк плох, но он используется большинством современных библиотек и поддерживается всеми популярными IDE. В том числе потому что в нём есть всякие фичи типа экспорта compile commands в JSON (и его архитектура позволила это сделать).
Остальные системы сборки используются в 3.5 проектах и почти не поддерживаются в IDE, либо фундаментально не позволяют нормальную поддержку инструментами (например, потому что система сборки это тупо самописный скрипт и compile commands генерировать получиться только руками).
Так что CMake необходимое зло.
В общем-то так оно и сделано, но с каких-то пор появилась опциональная возможность делегировать генерацию ключа в Google.
Android со своего появления позволял ставить приложения из файлов APK, но это потенциально уязвимость - вдруг юзер скачает с какого-нибудь сайта "мод на бесконечные деньги в Сбербанк", который под капотом отправляет все учётные данные пользователя автору. Или ревнивый партнер или спецслужбы обойдут блокировку пинкодом на мессенджере просто накатив поверх модифицированный APK с бекдором (заметно или даже незаметно для юзера).
Поэтому в Android у каждого APK есть цифровая подпись. Система отказывается ставить APK поверх уже установленного приложения с другой цифровой подписью. Как минимум юзеру будет лишний повод задуматься "точно ли я знаю, что делаю?", как максимум, придётся сначала удалить руками старую версию приложения с другой подписью со всеми данными, авторизациями и т. д. Соответственно, приложение с другой подписью не сможет облегчить доступ к чему-то запароленному, а ещё не пройдёт незаметно.
Шло время и приложения опубликованные на Google Play пухли. В итоге Google захотел сделать Android App Bundle - новый формат приложений, который предполагал переупаковку на стороне сервера с выкидыванием всего лишнего на конкретном устройстве пользователя, который качает приложение (например, оставить в APK только одну версию нативных библиотек под нужную архитектуру, а не 2-4 под все поддерживаемые Android, оставить графические ресурсы только под DPI устройства и т. д.). Но возникла проблема - каким ключом Google будет подписывать перепакованный APK? Если новым, своим, то не получится обновить уже установленные приложения до введения фичи, а ещё будет невозможно обновлять приложения полученные из других источников (например, скачанные с официального сайта разработчика) без переустановки.
И Google Play придумал давать разработчикам выбор - он сгенерирует ключ за них (актуально для новых приложений и не очень опытных разработчиков, для которых снижается порог входа) или же разработчик отправляет свой ключ в Google (актуально для старых приложений и для разработчиков, которые по каким-то причинам хотят больше контролировать процесс выпуска ключа, например, чтобы было чем подписывать пререлизную версию приложения до публикации в магазине, а потом ничего не ломать).
Также не забываем, что помимо распространения APK есть ещё альтернативные маркеты и хочется, чтобы можно было поставить приложение из одного и потом без проблем обновить другим.
Есть шанс, что после такого финта старые установки приложения не смогут обновиться и будет необходимо переустанавливать приложение.
В общем, не теряйте keystore.
Первый вопрос: а какая точность по времени у выхода GNSS приёмника? В смысле какая максимальная гарантированная разница между таймингами прихода импульсов от этих конкретных моделей приёмников разнесенных на несколько сотен метров?
Просто если можно запустить АЦП в свободным режиме на высокой частоте, а по сигналу лишь выбирать какие группы импульсов усреднять, то это было бы проще и надёжнее. Но, конечно, если приемник может выдавать сигналы очень точно, то не прокатит.
Ну и в целом, я бы такой проект начинал с анализа предела точности, чтобы знать, что можно добиться на этом оборудовании, а что нельзя (либо чтобы выбирать, собственно, приемники, если их можно выбирать разные).
Хотя и в таком случае правильно было бы использовать свободный режим. Просто вычислить локально время между импульсами от приёмника, вычислить время от подачи сигнала запуска до первого измерения и, получив очередной импульс, выждать разницу первого и второго и самостоятельно выдать сигнал старта, чтобы получить результат аккурат к следующему импульсу. Можно периодически повторять калибровку, если устройство работает неделями и месяцами.
Дело в том, что у АЦП может отличаться точность в свободном и одиночном режиме, причём в случае сигма-дельта АЦП - свободный режим точнее. Кстати, и время между замерами может быть более круглое, чем время одиночного замера.
Наконец, конечно, там лучше подходит не малинка, а ESP32 и аналоги. Та же поддержка WiFi, но риалтайм из коробки без заморочек с модулями ядра. Плюс компактнее и меньше жрёт. По сложности программирования должно быть легко за счёт Arduino SDK, который осваивается прямо по ходу разработки, если уже есть знакомство с embedded.
500 баксов это в разы ниже минимального порога оплаты труда в любой развитой стране. Так что робот таки дешевле за счёт того, что индус останется в Индии.
Как я понял из статьи прибалты стремятся всеми правдами и неправдами прессовать россиян за связь с Россией и для этого толкуют санкции максимально строго. Остальные в принципе не жестят и претензии предъявляют к тем, кто реально живёт больше в России, чем у них (например, руководит парой российских фирм).
Короче, не живите в Прибалтии.
Мне помогло закрыть счёт в одном крупном банке написав огромный отзыв на banki.ru. До него техподдержка отвечала "где карту получали, там и закрывайте", а после отзыва они в течении суток со мной связались (причём согласились позвонить на иностранный номер, чтобы у меня не было платы за роуминг) и всё порешали.
С такими законами, по которым под УК подпадает пол населения страны, они выборочно применяются.
Применяющие не дураки и понимают, что миллионы уголовных дел ни правоохранительная и судебная система не пережует, ни экономика (одновременно выбывание миллионов людей из экономической жизни), да и с политической точки зрения есть проблемы (обычно за раз теснят какую-то небольшую группу людей, чтобы большинство могло сказать "моя хата с краю и вообще они сами виноваты").
Так что Неуловимый Джо может пиратить, пока не перейдёт кому-то дорогу или пока Товарищ Майор не захочет повышение, а он окажется не в то время не в том месте.
Возможно, они целятся в сегмент демо плат для бизнеса (на которых в том числе делают ранние прототипы будущих серийных устройств). Типа "с нашей платой сможете брать на работу тех, кто умеет работать с Arduino".
Всякие фичи типа шифрования прошивки (да и деление прошивки на доверенную и недоверенную) в DIY не имеют смысла от слова совсем. А вот бизнесу интересно.