Провели температурный тест оптического рефлектометра при температуре около -10 градусов по Цельсию. Как раз сегодня в Питере была такая температура ;)

При такой температуре за бортом вентиляция прибора выключается и внутренняя
температура многих деталей выше, чем -10 градусов. Например, батарея имеет -3 градуса, а сам модуль рефлектометра, подключенный к Беркут-ММТ, имеет температуру +3 градуса.

А поскольку рабочие точки оптических компонентов рефлектометра рассчитаны на диапазон 0-50 градусов, то рефлектометр сохраняет свои характеристики даже при минусовой температуре!

больше новостей нет.

разве что, небольшой багфикс по желаниям пользователей в Беркут-ETL: теперь переключение уровней шлейфа выполняется не сразу, а с задержкой. поэтому, например, порт коммутатора Cisco не упадёт, зафиксировав loopback. релиз можно скачать где обычно, то есть тут.

Тонкость нулевая — много аккумуляторов, хороших и разных.

Всё начинается с того, что smart battery сама определяет алгоритм заряда, а зарядное устройство только следует её указаниям. Существует как минимум 2 широко распространённых технологии аккумуляторов (LiIon и NiMH/NiCD) и для NiMH существует несколько возможных алгоритмов заряда. Если Li-Ion аккумуляторы заряжаются достаточно просто (нужно только ограничить зарядный ток и напряжение, а конец заряда определяется по снижению зарядного тока до определённого порога), то в случае с NiMH аккумуляторами есть несколько вариантов заряда, с различными критериями его прекращения и разными областями применения.
Начнём с простейшего trickle charge, который может использоваться для заряда глубоко разряженной батареи или для заряда батареи в условиях низкой температуры. Это заряд с током не превышающим 0.1C (то есть 0.1 ёмкости батареи). По заверению GP, в этом режиме батарея может заряжаться 1 год, без вреда для себя, но полный заряд занимает 14 часов, что в общем-то для портативного прибора неприемлемо.
Дальше имеется второй режим заряда, fast charge. В этом режиме батарея заряжается намного быстрее, зарядные токи порядка 0.3C-1C для него норма. Но в этом режиме необходимо точно контролировать температуру батареи и вовремя заканчивать заряд. Отсюда мы плавно переходим к тонкости номер один.

Тонкость первая — сколько вливать миллиамперчасов или конец заряда.

Как уже было написано выше, в случае с LiIon конец заряда определяется просто — в батарею просто перестаёт течь ток. В случае с NiMH всё несколько сложнее. По мере окончания заряда, в батарее химические процессы заряда начинают сопровождаться выделением газа. В случае trickle charge выделение имеет небольшую скорость и компенсируется поглотителем и в общем безопасно. Этот процесс сопровождается выделением тепла. В случае быстрого заряда, тепловыделение намного выше и если заряд не будет остановлен вовремя возможно повреждение батареи. Так мы приходим к различным критериям прекращения заряда.  В случае с trickle charge, критерием прекращения заряда достаточно использовать таймер на 14 часов. Если же используется быстрый заряд, то возможно два критерия окончания заряда — по температуре и по напряжению. Оба эти критерия используют один и тот же физический процесс и практически взаимозаменяемы. Вот только для первого критерия был нужен термодатчик, и достаточно точный, находящийся в тепловом контакте с батареей. Кроме того, так как этот метод использует скорость нарастания температуры в качестве критерия, он не надёжен при изменяющейся температуре окружающей среды. Поэтому в нашем варианте батареи используется критерий окончания заряда по dV/dt. В этом случае момент окончания заряда определяется по тому моменту, когда напряжение на батарее перестаёт расти и начинает падать. Сложность здесь заключается в том, что падение напряжения невелико (милливольты) и достаточно медленное.
Ещё одна тонкость заключается в том, что необходимо предотвратить немедленное начало заряда при небольшом падении уровня заряда, иначе батарея будет систематически перезаряжаться. Это связано с тем, что для определения момента окончания заряда требуется определённое время.

Тонкость вторая — учёт ёмкости, калибровка и КПД.

Одно из преимуществ системы Smart Battery в том, что батарея может оценивать время заряда и разряда. Для этого батарея ведёт учёт своей ёмкости на заряде и разряде. И уже исходя из учтённой ёмкости и текущего тока вычисляет время заряда/разряда. По критериям конца разряда и конца заряда батарея рекалибруется, то есть обновляет значение максимальной ёмкости. Это необходимо делать в связи с тем что батареи отличаются по ёмкости уже с завода а так же стареют, и теряют емкость. Таким образом калибровка необходима для знания точного времени требуемого для заряда батареи, а так же для точного вычисления процента заряда.
И тут в этот простой с виду процесс вклинивается реальный мир в лице страха и ужаса создателей вечных двигателей, а именно КПД. Дело в том что не вся энергия уходящая на заряд батареи преобразуется в химическую энергию, часть уходит в тепловые и другие потери. Если бы КПД был более менее постоянен, то его учёт был бы простой задачей. Но как обычно, законы физики мешают программистам и КПД меняется от множества разных факторов, начиная от температуры батареи и режима заряда и заканчивая фазой луны возрастом батареи. Таким образом точный учёт КПД невозможен или затруднителен. Просто игнорировать КПД можно если он достаточно высок. Например в случае с LiIon аккумуляторами, где он составляет примерно 90%. В случае NiMH аккумуляторов, КПД меняется в зависимости от режима заряда и других факторов и может составлять от 60 до 90%. Неточности учёта КПД приводят к проблемам учёта заряда при неполных циклах батареи, то есть если батарея не разряжается до конца и соответственно рекалибруется только по концу заряда, может нарастать ошибка учёта ёмкости, что приводит к некорректным оценкам времени работы и процента заряда.
Здесь мы подходим к третьей тонкости, а именно учёту саморазряда батареи.

Тонкость третья, саморазряд.

От саморазряда страдают все батареи, отличается только его величина. Кроме того в случае Smart Battery, к саморазряду добавляется потребление контроллера батареи, который питается от батареи. Отсюда возникает проблема учёта саморазряда, особенно на NiMH батареях высокой ёмкости, где саморазряд может достигать 30% в месяц. Сам процесс учёта саморазряда не сложен — достаточно просто вычитать некоторую константу из накопленной ёмкости батареи с определённым временным интервалом. Вот только константа эта на самом деле констатной не является, саморазряд не постоянен по времени и зависит от температуры. Наибольший саморазряд приходится на первые сутки после заряда (порядка 5-10%). Затем он снижается до 1% в день (при комнатной температуре), высокие температуры значительно ускоряют этот процесс. Для упрощения в нашем случае был взят вариант саморазряда с постоянной скоростью в 1% в день.

Вот собственно пока и все тонкости из тех что вспомнились через 2 недели после конца разработки батареи.

В следующих выпусках этого нерегулярного блога :) будет рассказно о сложностях отладки сложных систем на примере умной батареи.

Инструкция по замене идущего в комплекте с Colibri MS Windows на linux доступна на нашем wiki.

Исходные тексты ядра linux и патчи к нему тут.

Разработали схемы, определились с форм-фактором… Стали заказывать компоненты. Но не тут-то было. Процессоров, как выяснилось, в наличии нет и производство их ещё не начато. Вот спасибо фирме Atmel за обломчик-с.

На самом деле, нас это не пугает, потому как всегда есть запасные варианты. И мы будем их использвать.

В отличие от нашего предыдущего проекта, в Colibri стоит NAND флэш, а не NOR. NAND получает все большее и большее распространение в силу своей дешевизны и при этом большей вмесимости чем NOR (небольшое сравнение NOR  и NAND можно посмотреть тут).

Процессор Marvell PXA320 со своим встроенным NAND контроллером и сама микросхема NAND флэш поддерживаются основной веткой ядра. В общем, ничто не предвещало беды и было решено пойти  по накатанной — развернуть на NAND JFFS2 (Journaling Flash File System version 2) с корневой файловой системой.

Но тут вдруг обнаружилось что старый добрый JFFS2  мало того что полторы минуты сканирует NAND, дак еще и работать отказывается напрочь =(. Попробовав различные версии ядра, различные конфиги ядра и способы разворачивания файловой системы на флэш (монтирование и разворачивание из архива, запись образа напрямую в NAND) работоспособности я так и не добился. Ну да не JFFS-ом единым подумал я и стал смотреть в сторону других файловых систем.

Первым под руку попался проект YAFFS (Yet Another Flash File System) — пропатчил ядро (в основной ветки поддержки YAFFS нет, но это не беда — можно скачать патч с сайта проэкта и запатчить им ядро), собрал, запустил — сканирование всего раздела (чуть меньше гига) заняло минуту с небольшим, при последующих загрузках все происходило быстро, без задержек. Но при первом же аварийном завершении — опять минуту с небольшим. В остальном, вполне работоспособная вещь.

Вторым была выбрана UBIFS (Unsorted Block Image File System) — файловая система от создателей JFFS2. Перелопатив тонны описаний от разработчиков обнаружил интересную вещь — UBIFS состоит из двух частей — UBI (Unsorted Block Image) и UBIFS. UBI очень похож на LVM (Logical Volume Manager) — тоже поддерживает создание логических томов на одном физическом разделе. Причем  в роли файловой системы поверх UBI можно запустить тот же JFFS2, как утверждают разработчкики. А можно загрузить FTL (Flash Translations Layer) и получить обычное блочное устройство, на которое хоть EXT3 можно натянуть. При этом такие вещи, как журналирование и слежение за равномерным износом NAND будет выполнять UBI.

Я поставил поверх UBI файловою систему UBIFS. Разработчики обещали быстро и надежно, да и сравнительные тесты показывали тоже самое. Первый запуск — присоединение тома занимает около 10 секунд, монтирование происходит моментально, без задержек. Особенность UBI — присоединение тома занимает на гиговом разделе (том 900Мб. Почему не весь раздел — об этом далее) всегда занимает 10 секунд. С одной стороны, много. Но с другой, если работа была завершена аварийно, присоединение тома займет те же 10 секунд, но монтироваться система будет чуть дольше. Но с JFFS2/YAFFS все равно не сравнимо. Как и JFFS2, UBIFS  поддерживает сжатие on the fly, что уже не может не радовать.

Почему том не занимает весь раздел? Потому что UBI резервирует часть свободного места: если какой либо блок будет помечен как плохой то вместо него будет использоваться блок из свободного места. По умолчанию UBI резервирует 1% для этого, но это можно изменить в конфигурации ядра.

Cравнение различных файловых систем для raw flash — тут.

Почему в качестве файловой системы не была взята привычная ext2/ext3/raiserfs? А все потому, что эти системы рассчитаны на работу с блочным устройством, т.е. между самой памятью и ядром есть еще некая реализация FTL внутри устройства. NAND/NOR же таких продвинутых штук не имеют, да и не надо им это. По этому для них и используются такие хитрые файловые системы.

Для тех кто хочет помучать UBI и UBIFS , или кто хочет более детально разобраться:

1. http://www.linux-mtd.infradead.org/faq/ubi.html
2. http://www.linux-mtd.infradead.org/doc/ubi.html