_pv

Это да, но если для батареек разделить эти 100часов на десяток минут работы до разряда, то после такого количества циклов перезарядки они тоже "закончатся".

вот целый дисер по эффективности мелких движков, https://apps.dtic.mil/sti/tr/pdf/ADA631146.pdf но правда совсем уж мелких от 0.16 to 7.5 cm3, у самого крупного из них приводят эффективность по топливу 1.3кг/кВтч, то есть 3МДж/кг, что всё равно раза в 3-5 больше чем у литиевых батареек, и даже если половину веса занять мотором/генератором какой-то выигрыш всё равно будет. для совсем мелких дронов смысла пожалуй не имеет, но когда вес начинает в кг измеряться то уже "всё не так однозначно", и с увеличением веса эффективность у "топлива" будет только расти.

Знакопеременные магниты на роторе при его вращении движутся мимо катушек статора, за последние 200 лет, как Фарадей это придумал, ничего принципиально нового тут никто вроде не открыл, разве что чуть более злые магнитные материалы нашли. з.ы. ещё можно наоброт соединить два bldc мотора проводами, один в другой, безо всякого управления, и один из них покрутить руками :)

Многополюсность-то как мешает? Только подобрать с таким KV чтобы на оптимальных оборотах бензинового двигателя выходное 3х фазное напряжение просто выпрямить без дополнительных преобразований. хотя всё равно скорее всего какая-нибудь буферная батарейка будет.

как уже сказали, авиамодельные движки, вроде такого https://www.aliexpress.com/item/1005005567401612.html 0.5кг 1.5кВт (возможно китайских) и ему на ось какой-нибудь BLDC в качестве генератора, с соответсвующей мощностью и KV, тоже ещё наверное полкило. бензин вроде 30МДж/кг, даже если после всех преобразований от них останется четверть, это почти на порядок больше чем батарейка 18650 - 3.3Ач*3.3В*3600сек = 40кЖд; / 40гр = 1МДж/кг соответственно 1кг генератора + 1кг бензина всё равно в несколько раз лучше 2кг батареек.

не, это просто выход внешнего клока. по сравнению с B/R у highspeed частоты заметно другие. там вроде 120МГц делится на 16 и 10 для дробного делителя. https://www.ftdichip.com/Documents/AppNotes/AN_120_Aliasing_VCP_Baud_Rates.pdf

в виндах при открытии порта в DCB.BaudRate пишется непосредственно скорость, а не делитель. я частотомером не смотрел, но 921600 (не уверен правда что это именно ft232h был, но точно работало) нацело из 60МГц ,которые у FT232h есть в наличии, никак не делится. то есть если в DCB записать сколько именно надо, драйвер сам ближайший делитель подбрать должен.

вы бы его в человеческие вольты перевели :) насколько понял речь про сейсмологию и всякие геофоны (они вроде как скорость измеряют, а на графике - плотность мощности ускорения?), у которых обычно какие-то килоомы выходного сопротивления и соответствующие им просто температурные шумы будут несколько nV/rtHz, (1кОм==4nV/rtHz). а судя по графику который уходит в частоты 0.001Гц я бы на низкочастотные шумы ещё внимание обратил, у быстрых SAR, пусть и на кГц частотах для экономии энергии работающих, НЧ шум 1/f может оказаться несколько выше и может начать пакостить на совсем низких частотах.

речь про кГц, а не про МГц, и от 5В шкалы даже эффективных 24 разряда это 300нВ, что в полосе 1кГц всего лишь 10nV/rtHz, и, если забыть про потребление, цифры совсем не безумные, хоть для сигма-дельта(ads1263) хоть для SAR (ltc2500, с оверсэмплингом). другое дело что шумы на закоротке это конечно здорово, но нелинейности в несколько ppm всё равно останутся.

SINAD, да не особо они отличаются, THD и SFDR у обоих по 100дБ, у i2040 нелинейность чуть выше (30 вместо 6 ppm), поэтому указанный 90дБ SINAD и 100дБ указанного SNR (N без +D) у ADS131 по уровню входного шума на закороченном входе (как эти 18.8 ENOB и намерили) врядли будут уж сильно отличаться. не в 16 раз уж точно. а отдельный АЦП всё равно удобнее, особенно если МК не подходит.

это потребление ядра МК, который для работы АЦП не особо нужен, и его можно усыпить, либо запустить на частоте в несколько кГц, достаточной чтобы данные из АЦП в регистр spi слэйва переложить (дма там нет) а сам АЦП: SD24 Analog plus digital supply current per converter (reference current not included) 190 µA typ 250 max АЦП там тоже так себе, основное предназначение для измерение сетевых 50Гц, <90dB, зато 24бита, ага, и если самого МК как именно МК не хватит, проще отдельный АЦП найти. ads131m04 на пониженной частоте 1.2мА на все 4 канала. можно ещё на ацп для ЭКГ посмотреть типа ads1194 з.ы. а использовать один АЦП и мультиплексировать медленные сигма-дельта АЦП не самая хорошая идея.

msp430i2040

дип корпуса нынче обычно выглядят вот так

Те что по ссылке как раз относительные. Такие же емкостные как в дешевых китайских пластмассовых штангенциркулях, а некоторые из них если сильно быстро дёрнуть, могут и ошибку накопить. Картинка натянутой 100мкм проволочки через самый говёный китайский USB микроскоп, а справа её усреднённое горизонтальное положение, вычисленное по всей этой картинке, график "шумов" и не очень долговременной стабильности, вертикальная шкала на графике в мм. С кучей рисок в кадре найти "фазу" 1мм отметок можно с ещё большим разрешением, другое дело насколько аккуратно эта линейка нарисована. И с оптическими измерениями любая грязь/пыль и даже окружающее освещение (если не закрыть) сильно влияют. Но ТСу микроны и не нужны вроде.

китайские usb эндоскопы

уже стало, но (since C++20): https://en.cppreference.com/w/cpp/language/aggregate_initialization

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

так сам АЦП по DC ничего не измеряет, или предлагаете прям быстро дергать ключом и тем самым, перенести эту разность сигналов по частоте выше фильтра, на частоту дергания ключа, а потом оттуда программно "демодулировать" обратно? как-то слишком много действий для такой копеечной экономии.

любой понравившийся простой скриптовый язык на lua например можно превратить строку в бинарную (последовательность байтов), и потом уже из бинарной строки выдернуть циферки нужного размера, формата, знаковости и endianess: https://www.lua.org/manual/5.4/manual.html#6.4.2 str = "7F 1C 00 00 AA AF 00 00 A1 38 00 00 A4 FF 3F 00 80 0C 94 05 22 00 22 00 05 00 80 0F" t = {} for s in str:gmatch("%x%x") do table.insert(t,tonumber(s,16)) end f1,f2,f3 = (">I4I2I4"):unpack(string.char(table.unpack(t))) print(f1,f2,f3)

там довольно часто любят неотключаемые ВЧ фильтры цифровые добавлять и тем самым резать всё что ниже 10Гц. так что выбирать аккуратнее надо. а какие-нибудь китайские типа HX711 (только без неотключаемого предусилителя чтобы делитель ещё отдельно не калибровать) за те же 20 копеек к этому MS4344 имхо как раз подходят. не за 0.2 но за 1-2$ наверное можно найти 10-12 разрядный ЦАП, который столько со встроенной опоры обеспечит без дополнительных плясок с бубном.

там ещё отдельно температурная стабильность, которая даже не указана, может дополнительно очень удивить. но да, в паре с каким-нибудь таким же низкобюджетным медленным сигма-дельта АЦП (только не аудио! и с нормальной опорой) в качестве "цифровой обратной связи", который будет постоянно выход этого ЦАПа измерять и, соответственно, корректировать, можно попробовать сколхозить более менее аккуратный ЦАП, дешевле и даже аккуратнее чем готовый ЦАП без обратной связи. точность-то 0-10В какая нужна?

то есть по проводам за секунду в процессор прибежало 9Дж, 8.4Дж выделились в тепло, а оставшиеся 0.6Дж получается где-то запаслись, наверное в кэше процессора в виде результатов вычислений? какая замечательная батарейка получается, неограниченной ёмкости, и законы сохранения совсем не нарушает.

каким образом у него там вообще int в этом месте образовался (парсер пролюбил "массивность" или вложенность стуктуры и сразу полез уровнем ниже unsigned gpio инициализировать?), и то что * и [] не абсолютно прям одно и то же, выглядит как-то не очень красиво. имхо что-то они там перемудрили с приведениями типов. возможно какие-то тараканы самого iar, первое приведение внутри sizeof ему совсем не мешает, а при инициализации/присваивании, когда указан прям тот же тип поля что на самом деле есть и делать с ним он ничего не должен вообще - почему-то не нравится. но да, второе приведение {__VA_ARGS__} при инициализации поля структуры тут совсем не обязательно.

С компилятор любой должен, это вроде как стандартный способ инициализации массивов/структур через (type){x, y, z} но плюсовый может и не уметь, там что-то про сишные инициализации вроде бы только в с++23 наконец добавили. попробуйте переключить его в -std=c99 https://godbolt.org/z/TYnqzvqKj у ТСа там массив, неопределённой на момент определения (каламбур-с) длины [] есть, размер которого он хочет получить внутри этой же инициализации, которую компилятор ему не может дать, так как С теоретически позволяет ТСу после определения длины коварно продолжить инициализовать массив через именованную инициализацию.

добро пожаловать в волшебный мир препроцессора C... #define STRUCT_INIT(...) {sizeof((sGPIOItem[]){__VA_ARGS__})/sizeof(sGPIOItem), (sGPIOItem[]){__VA_ARGS__}} sGPIOList gpio = STRUCT_INIT( {GPIOB, 10, B10, OUT_PP_10MHZ}, {GPIOA, 5, B5, IN_NOPULL}, {GPIOA, 4, B4, IN_NOPULL}, {GPIOB, 1, B1, OUT_PP_10MHZ} );