Daniil

Интересно, не знал про такие. Но совсем не бюджетно. Не совсем понял, как эта штука работает. За счёт чего получает стерео? Ценник за новые 2k$+, как посмотрю. Да и габариты те ещё...

Поддерживаю. Задержка есть у всех цифровых микроскопов, очень сложно такими пользоваться. Хотя, наверное, дело привычки. Меня больше напрягает отсутствие стерео. Плоское изображение доставляет не меньше неудобств, чем задержка. Сделал для себя вывод - для пайки только бинокуляр.

Я не хочу знать емкость и понимаю как она определяется, но топикстартер спрашивает, можно ли её определить по напряжению. Вы же пытаетесь сказать, что зная напряжение, ток, температуру, и время заряда можно определить емкость. Да, это так. Но при чем тут определение заряда АКБ по напряжению?

Да ладно? Вы сами себе перечите - сначала говорите, что необходимо учитывать и ток и температуру ("При измерении энергии аккумулятора всегда измеряют ток, напряжение и температуру. Семейство разрядных кривых есть. Из всего этого можно оценить ёмкость. Ессно, кривые тоже должны быть для хотя бы двух температур"), а потом пишите что напряжения достаточно. Вот сравнение кривых разряда литиевых и свинцовых АКБ: Если для свинца (с некоторыми допусками) можно оценить уровень заряда по напряжению, то с литием получается оценить только первые и последние 10%.

Т.е. по сути ответ тот же - нормально измерять заряд литиевого аккумулятора по напряжению не получится.

Интересно, а как? Вот, к примеру, кривая разряда LiFePo4 при разном токе: Какой уровень заряда при напряжении 3.22V, к примеру? И это мы ещё не учитываем температуру и деградацию АКБ со временем.

http://updates.cst.com/downloads/GPU_Computing_Guide_2024.pdf

Ещё вот такое есть в STM32F405/407xx and STM32F415/417xx device errata:

С литием так не получится. Там кривая разряда плоская.

А почему правильные цены = высокие цены? Чем более массовое производство, тем ниже будут цены, как бы вам не хотелось обратного.

Обойти вряд ли получится, а вот установить другой драйвер вполне себе вариант.

Вы меня не слышите. В библиотеке C# есть проверка на максимальную скорость порта, но при работы через WinAPI это можно проигнорировать. Так что первопричина ошибки может быть в драйвере.

Интересно, а вы в диспетчере устройств смотрели в свойствах порта максимальную скорость? Может проблема в драйвере? Может там что-то типа такого?

А где такой продается?

Тут сложно сказать. Проблема исправлена в нативном андроиде. В кастомных версиях андроида разных производителей могут быть свои особенности. Или приложение требует доработки (https://developer.android.com/about/versions/12/features#bluetooth-permissions😞

Мне тоже стало интересно, я с таким не сталкивался раньше. Погуглил и нашел вот это - https://issuetracker.google.com/issues/37065090 Коротко: непонятно зачем это сделали, но этот баг (или фича?) провисел много лет и был исправлен только в 12-м андроиде, если судить по трекеру.

Интересно, а с какого размера партии китайский завод начнёт со мной разговаривать?

Согласен, но это детали. Время выборки все равно сильно медленнее встроенной Flash.

Стр.68 даташита: Да тут вроде очевидно - zero waitstates=code flash, non-zero waitstates=data flash

У них и так чип Flash внешний, только он лежит в том же корпусе поверх основного кристалла ) Они и запускаются медленнее STM32 (100-200ms), т.к. требуется время на копирования содержимого Flash в RAM.

Кэширование в RAM. При запуске содержимое Flash копируется в RAM. Вроде как там обычная отдельная SPI Flash и поэтому время доступа к ней относительно большое. Время доступа в кэшированный и обычный регионы есть в даташите:

Ну совсем в оффлайн режиме тут конечно будет не очень. Но прожить какое то время без связи очень даже возможно.

Пробовал. Несколько лет уже работает. Время получалось по NTP, а не от оператора. Раз или несколько в сутки запуск синхронизации по NTP решает проблему. Трафика это практически не расходует. Указывал три сервера для синхронизации и в случае сбоя синхронизации одного из них выбирался следующий. Без синхронизации разбег на SIM800C за сутки у меня получался несколько секунд (при комнатной температуре). Так что всё не настолько страшно. Я не претендую на правильность метода, но когда требовалась синхронизация +-пара секунд на всех устройствах, то такое решение работало довольно стабильно. Внешний RTC возможно будет стабильнее и проще, но без синхронизации время всё равно на нём уплывет рано или поздно.

Как-то очень похоже на срабатывание по перегрузке по току.

По ссылке речь идет про то, что время сбрасывается при отключении питания и некорректно получается при старте от оператора. Если мы подаем питания с батарейки на VRTC модема, то при перезапуске таких проблем нет. А способ установки времени, в таком случае, это уже дело второе. Можно как руками установить, так и получить через тот же NTP (как самый операторонезависимый). Часовой пояс всегда устанавливал жестко, через настройки, т.к. доверия операторам никогда не было. Для повышения точности можно периодически на фоне запускать синхронизацию через NTP.