Обновить
70
Антон Кортунов@ToSHiC

Программист

25
Подписчики
Отправить сообщение
У Melexis есть драйвер (правда какой-то кривоватый): github.com/melexis/mlx90640-library
Не, там всё хорошо, только погрешность растёт, в даташите есть график. Вроде, при 64 герцах получается чуть больше 1 градуса погрешности. Но в том же даташите есть, что если хочется измерять абсолютные величины — то надо после подачи питания подождать 4 минуты, чтобы корпус и матрица равномерно прогрелись и не вносили искажения.
Вообще Melexis крутые ИК сенсоры делает, конкретно у этого Programmable refresh rate 0.5Hz…64Hz. То, что китайцы так мало смогли с помощью stm32 прокачивать — это уже их проблемы, кажется. Шина i2c, питается от 3 вольт — то, что надо, чтобы напрямую к малице цеплять.
С 500 км скорее всего уже за год, если не быстрее, спустится до плотных слоёв атмосферы и сгорит.
Я про DT в 104 мс как-то не очень уловил. При частоте коммутации в 100 кГц (жёлтая надпись 102.4 кГц — это же как раз частота переключений ключа?) период будет всего 10 мкс, и 1% от этого — примерно 100 нс. Да и на скриншоте цена деления времени 40 нс вроде как (W сверху справа).
Действительно, вкралась опечатка. Спасибо за внимательность!
Маловероятно, тут была классическая гонка, для этого теоретически существуют специальные инструменты типа fbinfer.com/docs/racerd.html, но они не гарантируют 100% поимки подобных проблем. А уж если у вас в коде есть lockless контейнеры, то дебаг будет особенно приятным :)
Этим летом был зафиксирован формат bitstream в AV1, с этого момента производителям SoC нужно примерно 1.5-2 года, чтобы реализовать декодер в кремнии, после этого можно будет аккуратно начинать внедрять на практике. Представители netflix говорят, что они будут пробовать раньше, декодируя софтово, но только на низких разрешениях — чтобы сэкономить битрейт у пользователей с очень плохим интернетом.

AV1 в хроме конечно же будет, потому что это в том числе и гугловая разработка, и в youtube обязательно будет использоваться.
Webp (по сути — ключевой кадр, сделанный кодеком VP8) давно в продакшене и активно используется многими, heic (H265) в айфонах уже почти год как.
Так это только в плоских мультиках объекты реально сдвигаются на экране. В фильмах плоского сдвига почти никогда нету, почти всегда присутствует либо поворот, либо приближение/отдаление от камеры, а чаще всего и то, и другое одновременно. А ещё фон под движущимся объектом на переднем плане постепенно появляется, и он тоже может двигаться по экрану, причём с другой скоростью. Поэтому самая затратная часть современных кодеков — это motion estimation, попытка угадать, какому блоку в предыдущих кадрах соответствует вот этот блок текущего кадра. Чем эффективнее работает эта часть — тем меньше разница между текущим блоком и тем, на который он ссылается, тем меньше битрейт. Собственно, по большей части пресеты veryfast-->veryslow в libx264 как раз крутят настройки motion estimation: какого размера блоки искать (от 16х16 до 4х4, кажется), нужна ли субпиксельная точность вектора движения, какой алгоритм поиска применять и т.д.
Проблем особо не было, только непонимание, нафига вообще всё вот это извращение нужно, чего не могли сделать нормальный публичный сетевой RPC.
О том, насколько громадное количество наслоений и костылей представляет из себя Oracle DB, я понял уже после того, как в первый раз настраивал Toad: больше 10 лет прошло, а я всё ещё помню название файла tnsnames.ora, и какой адок там творится.
(Размышления диванного теоретика, начитавшегося форумов на rcdesign.ru)
Мне кажется, что главной ошибкой было класть плиты пенопласта горизонтально, а не вертикально, и резать надо было струной. Второй фейл — плохая обработка болвана, есть резон прямо на пенопласт положить слой стекла и обработать шпатлевкой+шкуркой для получения гладкой поверхности. Пенопласт, конечно, при этом должен быть устойчивым к смоле. А дальше уже мазать разделителем и лепить стекло, если без негативных форм делать. Для массового съёма — сделать нормальные формы по болвану и в них формовать корпусы.
Я бы не рекомендовал ориентироваться на работу на удалёнке. Да, это может быть удобно и комфортно, но о действительно хорошем развитии в большинстве случаев можно забыть. Самый эффективный рост, всё же, когда все вокруг на голову сильнее тебя, а задачи кажутся реально сложными. В этот момент особенно важно плотное общение с коллегами, с которым на удалёнке почти наверняка будут проблемы, ведь к этому должны быть готовы и вы, и коллеги.

Как многие писали выше, полностью уходить от железа тоже вряд ли стоит, ведь это реально ваше конкурентное преимущество. Например, сейчас на хайпе всяческие IoT, где как раз очень важно понимать, что же происходит с железом, а не бездумно лепить поделки на esp32 (во всяким случае, я на это очень надеюсь!).
Нет смысла — асики более энергоэффективны. Майнинг на FPGA меньше полугода был прибыльным, вроде.
В такой постановке вопроса — скорее нет, либо ваш DPI будет медленно развиваться. С точки зрения скорости разработки я бы для этой задачи брал всё же что-то типа DPDK. Вот там, где в latency операций упираться начинаете — есть смысл думать про FPGA, но сил надо затратить очень много. Прямо сейчас Intel предоставляет некоторый acceleration pack для нейросеток, но там не любые архитектуры сетей поддерживаются, да и в целом геморройной будет.
Поливать покрышки водой — стрёмная затея, они же очень скользкими станут сразу. Не далее, как сегодня катался на Moscow raceway — если заехать на астротёрф после первого поворота, то следующий двойной левый очень тяжело ехать, т.к. колёса начинают сильно скользить.

В целом, если говорить именно про кольцо, то вот типичная картина у кузовных авто:
image
И основной путь борьбы с выделением большого количества тепла это использование высокотемпературных компонентов. А именно: толстые вентилируемые диски, причём двухсоставные, с плавающим ротором, чтобы избежать микротрещин в районе крепления ротора, гоночная тормозная жидкость с температурой кипения в 300+ градусов цельсия (у обычной dot4 — 230 градусов), высокотемпературные колодки (на этой фотке, судя по всему, стоят Endless CCRG), иногда — использование частиц меди в колодках, которые эффективно уносят тепло при торможении, и делают эффект бенгальских огней :) Ну и охлаждение роторов, на фото — оранжевая труба слева от тормозного диска. В неё подаётся воздух примерно из того места, где обычно противотуманки, а труба этот воздух подаёт в примерно центр ротора. Ротор вентилируемый, т.е. состоит из двух рабочих полотен, между которыми радиальные перемычки. При вращении перемычки работают как лопасти вентилятора, прокачивая прохладный воздух от центра ротора к краю.

В особых случаях, как например в формуле 1, есть существенные ограничения на диаметр тормозного диска — он, вместе с суппортом, должен помещаться в колёсный диск диаметром 13" (дада, диаметр как на жигулях!). Чтобы всё это работало, диск и колодки приходится делать из карбона.
Если лень паять — то да, можно эвалборды взять.
SkyTraq сделали дешёвые модули с прошивкой, которая считает RTK прямо на модуле: navspark.mybigcommerce.com/s2525f8-gl-rtk-gps-glonass-rtk-receiver-module, для работы нужна, соответственно, пара таких модулей.
802.11r начиная с Galaxy S6, 802.11k и 802.11v начиная с Galaxy S8.
support.samsungknox.com/hc/en-us/articles/115013403768-Enhanced-Roaming-Algorithm

Информация

В рейтинге
4 308-й
Откуда
Россия
Зарегистрирован
Активность