если есть потребности в газовых турбинах, то логичнее построить дополнительный завод по их производству, чем вложить примерно столько же средств в разработку технологии по конверсии турбин очень разного качества с хранения... и всё равно потребуется завод...
так что очень странное предложение от ведущей в технологиях страны, только если считать, что компетенции производства турбин нужных мощностей утрачены... ну тогда ой...
расскажу свою историю: радиотехники собрали собственную плату и добавили туда визард управления питанием и шиной USB3.0, которой не было в референсной плате, две недели они думали что делать, так как USB устройства на плате не определялись.
Никогда до этого не работал с linux, с помощью нейронки развернул SDK для процессора на ubuntu 18.04 (такая требовалась для SDK) в virtualbox для сборки ядра. Ещё несколько дней с ИИ собирал DTSI для платы и подошёл к USB и визарду fusb301. Говорю нейронке, ищи драйвер в инете и вообще какие есть варианты, на что она отвечает, что драйвера нет, смысла искать нет, напиши его сам и даёт мне заготовку на Си с пустыми функциями. Я чутка прифигел, ну и отвечаю ей, что нет, так не пойдёт, напиши драйвер сама. Она - "Ок" - вот драйвер. Дальше четыре часа отладки и есть полностью рабочий драйвер под fusb301, устройства usb3.0 поднялись и работают. И да, я полностью понимаю (в том числе благодаря комментариям ИИ и отладочным сообщениям в коде драйвера) как работает конкретный драйвер в linux, порядок его загрузки и отработки прерываний.
Итог: я больше не боюсь Linux, так как теперь уверен, что с ИИ могу развернуть среду разработки под Linux, а также она мне подробно объяснит как работает build.sh и вообще происходит сборка образа, как функционирует плата под ОС, как сконфигурить дерево устройств DTS и даже как написать драйвер. Дальше мы с ней разработали драйвера акселерометров, магнетометров и других устройств, что были на плате, демо код на питоне проверки работы драйверов. И да, я не программист, я - радиотехник.
В умелых руках - ИИ мощнейший инструмент, но нужно им пользоваться как инструментом (как отвертками, пассатижами, ключами, мы же не пытаемся болты откручивать руками, а используем инструменты), а не пытаться подменить себя ИИ.
посмотрите кадр в моей статьей подписанный "Вот кадр с VS320 (SWIR):", там явно видно, что небо светится в SWIR - это естественное свечение в верхних слоях атмосферы. Чуть ниже кадр сняты в тоже время, но в видимом свете, видно, что небо в видимо свете черное и явно видны звезды. Именно свечение атмосферы в ближней ИК области (в значительной степени) используется ЭОП ПНВ.
еще такой вопрос, как LLM модели работают с данной архитектурой и asm? есть ли полное, но краткое описание для подгрузки в LLM?
вопрос вот к чему, столкнулся с низкоуровневыми вопросами реализации IP блоков на system verilog, загружал LLM свой код и pdf описание нужных мне IP блоков, после качественной подгрузки данных (но они должны быть не большими) LLM очень помогала с верификацией написанного кода модулей (своих и чужих) и поиском узких мест. Для новичков в новой архитектуре копилот на LLM был бы, возможно, полезен, но ньюансы архитектуры ей нужно как-то компактно подгрузить...
это значение для конкретной матрицы и примененного объектива, измеренное на практике с применением этой конкретной матрицы.
К сожалению, очень много времени прошло, можно заново пересчитывать и измерять, но порядок примерно такой, что ночью на пиксель 11х11мкм прилетает 50-70 фотонов на кадр 50мс.
Другой вариант, возможно, более надежный - выбраться с радиометром от 0.4 до 1мкм и промерить фактическую освещенность (но именно радиометром, а не люксметром).
нет, так как, если это кремний, а не InGaAs, то спектральная чувствительность определяется в первую очередь шириной запрещенной зоны в материале, именно по этому для чувствительности разных квантов применяются разные материалы.
В данном случае для диапазона до 2.4мкм - это InGaAs.
с огромным удовольствием прочитал!))) спасибо за замечательную хронику) а главное с подробностями, которые интересны с точки зрения понимания архитектуры ZX.
автор, может быть реализовать эмулятор под КУВТ-2 (MSX) машинку? там тоже Z80, но видео процессор от TI. 9918/9938/9958
есть дополнительная емкость для каждого пикселя, в которую переливается заряд после завершения экспозиции кадра (одновременно для всех пикселей, такой подход обеспечивает единую экспозицию для всех пикселей кадра). Дальнейшее считываение происходит уже из данной емкости. Но за все приходится платить, требуется место для дополнительного транзистора и этой емкости, что уменьшает (в общем случае) эффективную фоторегистрирующую площадь и, как следствие, общую квантовую эффективность (как произведение квантовой эффективности на эффективную площадь (QE*FF, где FF - fill factor). Так же дополнительная емкость снижает емкость основной фоторегистрирующей емкости и, как следствие, динамический диапазон матрицы. Но это все ньюансы. Конечно, же глобальный затвор лучше строкового, но значительнее сложнее в реализации.
- Та-а-к, монитор - это я понимаю, системный блок, клавиатура...
Багровеет и орет:
- А это что!? КОВРИК ДЛЯ МЫШИ!? Вы бы еще тапочки для тараканов прикупили!
ps: выглядит так, как будто чувак всю жизнь проектировал метро... 3д печатью тут не ограничиться))) тут и полиграфия, и литье пластика, и электроника...))) короче чума)))
к сожалению, по "ASIS - TOBE" гугл не выдал ничего по части стандартизации, есть много различных европейских или общемировых стандартов оформления документации на результат выполненной работы, да даже в РФ есть что-то хотя может и морально устаревшее. Проект очень масштабный, отсюда и вопрос, на базе чего можно зафиксировать результат выполненной работы, чтобы иметь возможность перенести этот результат на другие производства. У меня остался открытым вопрос, как вы считаете, вы сможете по вашей документации повторить результат на другом производстве?
ps: без подколов, к сожалению, сам занимаюсь разработкой более простых устройств, но всегда интересовало, что нужно для выполнения масштабных проектов командой, на подобие описанного вами, чтобы результат был повторяемый. Пока из ответов самому себе - это документирование, но на каком фундаменте эффективно выполнять документирование, пока вопрос открытый.
а как вы решаете вопросы с документацией? результат отличный, но какие документы разрабатываются? У вас документация общего плана или сильно заточенная под конкретное производство? 1500 датчиков - это очень серьезные должны быть схемы и толмуты технологической и технической документации? какими стандартами пользуетесь при оформлении? спасибо за статью
ps: давно занимался изучением характеристик автомобильных и не только аккумуляторов в личных целях, к сожалению, не хватило терпения для таких подробных и длительных экспериментов. Уверен, что ваши результаты полезны, хотя и узкому кругу специалистов и любителей, спасибо за публикацию. лайк)
почитайте, предположу, что есть закладки, которые целевые, типа вы закупаете через тендер набор серверов или ПК, а вам поставляют в этом тендере некоторый процент (или 100%) с аппаратными закладками, при этом все ЭВМ тендера визуально не отличимы между собой и серийными изделями в маркете... конечно, за 11 лет технологии шагнули вперед и простыми средствами не отличить
кстати, в связи с этой темой, целесообразность собирать свои сервера на уровне дизайна плат из импортных комплектующих - имеет смысл, тк закладки работают в основном в определенной среде ПО железа
еще раз поясню, что пишу не для вас, а для тех, кто прочитает статью и захочет использовать этот нестабильный ИОН в своих проектах, это вредный совет, которому более 10 лет и инженеры постоянно наступают на эти грабли и все равно приходят к тому, чтобы использовать внешние источники опорного напряжения, никакие калибровки не помогут.
pss: в современных реалиях attiny25/85 не перспективные морально устаревшие контроллеры, ценник на который сильно завышен, есть более удачные со стабильным ИОН, точным стабильным встроенным генератором, большей памятью за цену меньше бакса. Много кодил под tiny, когда перешел на современные - с облегчением выдохнул...
ps: а когтеточный бизнес чем плох?) вот та статья была хороша))
если есть потребности в газовых турбинах, то логичнее построить дополнительный завод по их производству, чем вложить примерно столько же средств в разработку технологии по конверсии турбин очень разного качества с хранения... и всё равно потребуется завод...
так что очень странное предложение от ведущей в технологиях страны, только если считать, что компетенции производства турбин нужных мощностей утрачены... ну тогда ой...
расскажу свою историю: радиотехники собрали собственную плату и добавили туда визард управления питанием и шиной USB3.0, которой не было в референсной плате, две недели они думали что делать, так как USB устройства на плате не определялись.
Никогда до этого не работал с linux, с помощью нейронки развернул SDK для процессора на ubuntu 18.04 (такая требовалась для SDK) в virtualbox для сборки ядра. Ещё несколько дней с ИИ собирал DTSI для платы и подошёл к USB и визарду fusb301. Говорю нейронке, ищи драйвер в инете и вообще какие есть варианты, на что она отвечает, что драйвера нет, смысла искать нет, напиши его сам и даёт мне заготовку на Си с пустыми функциями. Я чутка прифигел, ну и отвечаю ей, что нет, так не пойдёт, напиши драйвер сама. Она - "Ок" - вот драйвер. Дальше четыре часа отладки и есть полностью рабочий драйвер под fusb301, устройства usb3.0 поднялись и работают. И да, я полностью понимаю (в том числе благодаря комментариям ИИ и отладочным сообщениям в коде драйвера) как работает конкретный драйвер в linux, порядок его загрузки и отработки прерываний.
Итог: я больше не боюсь Linux, так как теперь уверен, что с ИИ могу развернуть среду разработки под Linux, а также она мне подробно объяснит как работает build.sh и вообще происходит сборка образа, как функционирует плата под ОС, как сконфигурить дерево устройств DTS и даже как написать драйвер. Дальше мы с ней разработали драйвера акселерометров, магнетометров и других устройств, что были на плате, демо код на питоне проверки работы драйверов. И да, я не программист, я - радиотехник.
В умелых руках - ИИ мощнейший инструмент, но нужно им пользоваться как инструментом (как отвертками, пассатижами, ключами, мы же не пытаемся болты откручивать руками, а используем инструменты), а не пытаться подменить себя ИИ.
wiki не всегда права, верить практике
посмотрите кадр в моей статьей подписанный "Вот кадр с VS320 (SWIR):", там явно видно, что небо светится в SWIR - это естественное свечение в верхних слоях атмосферы. Чуть ниже кадр сняты в тоже время, но в видимом свете, видно, что небо в видимо свете черное и явно видны звезды. Именно свечение атмосферы в ближней ИК области (в значительной степени) используется ЭОП ПНВ.
спасибо!
и ждем статью про реализацию FFT!
еще такой вопрос, как LLM модели работают с данной архитектурой и asm? есть ли полное, но краткое описание для подгрузки в LLM?
вопрос вот к чему, столкнулся с низкоуровневыми вопросами реализации IP блоков на system verilog, загружал LLM свой код и pdf описание нужных мне IP блоков, после качественной подгрузки данных (но они должны быть не большими) LLM очень помогала с верификацией написанного кода модулей (своих и чужих) и поиском узких мест. Для новичков в новой архитектуре копилот на LLM был бы, возможно, полезен, но ньюансы архитектуры ей нужно как-то компактно подгрузить...
дополню, чтобы чуть лучше разобраться в люксах, ваттах, фотонах и электронах, можно почитать статью Михаила Крутика и Виктора Майорова:
Люмены, канделы, ватты и фотоны. Измерения чувствительности телевизионных камер на основе ЭОП и ПЗС
"что залито - затечь не может"
класс, нужно запомнить =)))
вопрос: в гидробаке морская вода?
это значение для конкретной матрицы и примененного объектива, измеренное на практике с применением этой конкретной матрицы.
К сожалению, очень много времени прошло, можно заново пересчитывать и измерять, но порядок примерно такой, что ночью на пиксель 11х11мкм прилетает 50-70 фотонов на кадр 50мс.
Другой вариант, возможно, более надежный - выбраться с радиометром от 0.4 до 1мкм и промерить фактическую освещенность (но именно радиометром, а не люксметром).
нет, так как, если это кремний, а не InGaAs, то спектральная чувствительность определяется в первую очередь шириной запрещенной зоны в материале, именно по этому для чувствительности разных квантов применяются разные материалы.
В данном случае для диапазона до 2.4мкм - это InGaAs.
с огромным удовольствием прочитал!))) спасибо за замечательную хронику) а главное с подробностями, которые интересны с точки зрения понимания архитектуры ZX.
автор, может быть реализовать эмулятор под КУВТ-2 (MSX) машинку? там тоже Z80, но видео процессор от TI. 9918/9938/9958
есть дополнительная емкость для каждого пикселя, в которую переливается заряд после завершения экспозиции кадра (одновременно для всех пикселей, такой подход обеспечивает единую экспозицию для всех пикселей кадра). Дальнейшее считываение происходит уже из данной емкости. Но за все приходится платить, требуется место для дополнительного транзистора и этой емкости, что уменьшает (в общем случае) эффективную фоторегистрирующую площадь и, как следствие, общую квантовую эффективность (как произведение квантовой эффективности на эффективную площадь (QE*FF, где FF - fill factor). Так же дополнительная емкость снижает емкость основной фоторегистрирующей емкости и, как следствие, динамический диапазон матрицы. Но это все ньюансы. Конечно, же глобальный затвор лучше строкового, но значительнее сложнее в реализации.
Шеф фирмы изучает счет за компьютер:
- Та-а-к, монитор - это я понимаю, системный блок, клавиатура...
Багровеет и орет:
- А это что!? КОВРИК ДЛЯ МЫШИ!? Вы бы еще тапочки для тараканов прикупили!
ps: выглядит так, как будто чувак всю жизнь проектировал метро... 3д печатью тут не ограничиться))) тут и полиграфия, и литье пластика, и электроника...))) короче чума)))
понятно, спасибо за подробный ответ
к сожалению, по "ASIS - TOBE" гугл не выдал ничего по части стандартизации, есть много различных европейских или общемировых стандартов оформления документации на результат выполненной работы, да даже в РФ есть что-то хотя может и морально устаревшее. Проект очень масштабный, отсюда и вопрос, на базе чего можно зафиксировать результат выполненной работы, чтобы иметь возможность перенести этот результат на другие производства. У меня остался открытым вопрос, как вы считаете, вы сможете по вашей документации повторить результат на другом производстве?
ps: без подколов, к сожалению, сам занимаюсь разработкой более простых устройств, но всегда интересовало, что нужно для выполнения масштабных проектов командой, на подобие описанного вами, чтобы результат был повторяемый. Пока из ответов самому себе - это документирование, но на каком фундаменте эффективно выполнять документирование, пока вопрос открытый.
а как вы решаете вопросы с документацией? результат отличный, но какие документы разрабатываются? У вас документация общего плана или сильно заточенная под конкретное производство? 1500 датчиков - это очень серьезные должны быть схемы и толмуты технологической и технической документации? какими стандартами пользуетесь при оформлении? спасибо за статью
спасибо за ваш труд, в закладки
ps: давно занимался изучением характеристик автомобильных и не только аккумуляторов в личных целях, к сожалению, не хватило терпения для таких подробных и длительных экспериментов. Уверен, что ваши результаты полезны, хотя и узкому кругу специалистов и любителей, спасибо за публикацию. лайк)
https://habr.com/ru/articles/209746/
почитайте, предположу, что есть закладки, которые целевые, типа вы закупаете через тендер набор серверов или ПК, а вам поставляют в этом тендере некоторый процент (или 100%) с аппаратными закладками, при этом все ЭВМ тендера визуально не отличимы между собой и серийными изделями в маркете... конечно, за 11 лет технологии шагнули вперед и простыми средствами не отличить
кстати, в связи с этой темой, целесообразность собирать свои сервера на уровне дизайна плат из импортных комплектующих - имеет смысл, тк закладки работают в основном в определенной среде ПО железа
машинально - вторым было бы idkfa )))
трактористы жеж... )))
еще раз поясню, что пишу не для вас, а для тех, кто прочитает статью и захочет использовать этот нестабильный ИОН в своих проектах, это вредный совет, которому более 10 лет и инженеры постоянно наступают на эти грабли и все равно приходят к тому, чтобы использовать внешние источники опорного напряжения, никакие калибровки не помогут.
pss: в современных реалиях attiny25/85 не перспективные морально устаревшие контроллеры, ценник на который сильно завышен, есть более удачные со стабильным ИОН, точным стабильным встроенным генератором, большей памятью за цену меньше бакса. Много кодил под tiny, когда перешел на современные - с облегчением выдохнул...
ps: а когтеточный бизнес чем плох?) вот та статья была хороша))