Jump to content

    

SKov

Свой
  • Content Count

    807
  • Joined

  • Last visited

Community Reputation

0 Обычный

About SKov

  • Rank
    Знающий

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

2719 profile views
  1. Про дроссель у меня была мысль, но я ее оставил на крайний случай. Сейчас смотрю в сторону AUIR3320 и 3330. Первые есть в столе, так что можно пробовать. Возможно, от КЗ это решение, но тогда надо что-то мудрить с режимом заряда. Чтобы ток заряда не шел через внуттренний паразитный диод AUIR. Хотя, это уже меньшее зло.. Спасибо. Буду думать.
  2. Если вы говорите о "китайщине" с Али, то в сети полно сообщений о красочных фейерверках, возникающих при КЗ через такие БМС. Это немножко в сторону от топика, но я себе уже голову сломал, как вообще можно сделать надежную защиту от КЗ при номинальном токе 50А и токе срабатывания защиты, ну скажем 75-100А. Нет, защиту от относительно медленно нарастающей перегрузки понятно как делать, а вот именно защиту от КЗ.. Моя вторая 'батарейка" (титанат, 120Ач) при КЗ мгновенно выдает несколько кА. И что с этим делать? Можно сделать мгновенную схему ограничения тока ну, пусть на уровне 100А, но вот при этом киловатт на ключе даже на очень короткое время.. Это за пределами реального. Если у вас есть на примете схема защиты именно от КЗ при токах КЗ в килоамперы и при внутреннем сопротивлении батареи - меньше миллиома..Не сочтите за труд поделиться ссылкой.
  3. Ну, если есть плата защиты, то это меняет дело. Но тогда почему бы ее не скрестить с балансировкой? При заряде (в конце его) можно, конечно, выставлять малый ток заряда, чтобы дать возможность балансировке окончательно выровнять ячейки. Но, чем меньше ручной работы, тем надежнее система. Пусть плата защиты отрубает зарядку при разбеге одной ячейки до опасного уровня, а когда пассивный балансир подравняет ячейки, пусть эта плата снова включит входной ключ, и зарядка продолжится. Я сейчас как раз мастерю что-то подобное ;) Не могу согласиться. При разряде все определяется самой слабой ячейкой, и работа балансира ее не касается. Пассивные балансиры должны потреблять заметно меньше 1мА в пассивном режиме, и их никто не ставит и не снимает при каждой зарядке-разрядке. Для них должен действовать принцип - поставил и забыл. Так же как и для платы защиты.
  4. C балансирами ситуации немножко туманная. Банки начинают разбегаться значительно только в двух случаях: при зарядке в конце этого процесса, или при разряде, тоже уже ближе к исчерпанию емкости. И в том и в другом случае действуют токи в десятки ампер. Ну, по крайней мере у меня в лодочном моторе (до 50А) и зарядке (20А). Говорить о том, что в таком режиме заряда-разряда пассивные балансиры могут что-то полезное сделать - не приходится. Потому что при заряде главное - не перезарядить, а при разряде - не переразрядить. И жалкие 0.5-1 ампер пассивного балансира не спасут ситуацию. Так что лично для беня балансир имеет смысл в первую очередь как датчик пограничного состояния, при котором уже пора что-то делать ;) Токовая петля как раз может в этом случае помочь. Но для этого надо иметь механизм отключения аккумулятора от нагрузки. Но в этом случае это уже не столько балансир, сколько BMS. Ну, это все мое ИМХО, разумеется.
  5. Зайдите на сайт электротранспорта - там уже много лет обсуждают разные BMS и балансиры, в том числе и на TL431. Выложены вроде бы реальные схемы. А большая рассеиваемая мощность может быть связана с тем, что балансиры сажают прямо на массивные выводы из литиевых банок - там где-то я видел такую фотографию. Для такой банки рассеить пару ватт - вообще ни о чем.
  6. Сработало "инверсное мышление" ;) Здесь одному входному биту соотвествует слово бесконечного веса. А для катастрофичности надо обратное условие: бесконечный вес на входе и конечный на выходе. Да и не бывают систематическиие код катастрофическими. В общем, погорячился ;)
  7. Да, задача немного некорректно описана. А что касается сравнения каждого с каждым, то, очевидно, надо сравнивать каждый с нижними. Все ж в два раза экономия ;)
  8. Ну, не могу с Вами согласиться. Сейчас уже не помню подробностей, но году этак в 2005 с интересом разбирался в этой теме и, в частности, смотрел статью по оптимизации маленького поля. И там были данные, что если для прямого умножения (в 2^14) требуется 500 сумматоров XOR и еще сколько-то AND и еще сколько-то чего-то (все цифры сейчас беру с потолка, но идея будет понятна), то для реализации такого же умножителя, использующего переход в поле 2^7, требуется только 300 сумматоров XOR, чуть меньше AND и еще меньше чего-то еще. Но главноый результат статьи заключался в том, что, как оказалось, сложность реализации умножителя в маленьком поле зависит от выбора полинома для построения маленького поля. Ребята перебрали все неприводимые полиномы для маленького поля и нашли, что оптимальный выбор может сэкономить дополнительно еще 50 XOR-ов и еще 10 AND-ов. Совершенно нормальная статья ;) Другими словами: 1) Переход в маленькое поле все-таки дает некоторый выигрыш по сравнению с прямым умножением (если все аккуратно сделать). 2) Статьи на это тему как появлялись, так и будут появляться с подобными вполне "печатными" результатами. 3) Практическая ценность этого не очень значительна, т.к. экономия в пару сотен XOR-ов почти не заметна на фоне 150K гейтов общей сложности декодера для длинного кода. А "прозрачность", "читабельность" и удобство отладки программы (особенно вериложной) заметно страдает от использования двух полей. Так что выигрыш есть, но стоит ли за ним гнаться - этот вопрос решает для себя каждый проектировщик индивидуально ;)
  9. Не расстраивайтесь. Все равно с этим полезно разобраться. Даже просто для общего кругозора. Бесполезных знаний не бывает ;)
  10. Статей на эту тему много, и одно время было очень модным при декодировании длинных БЧХ переходить от 2^14 к 2^7. Однако, на практике оказывается, что особого выигрыша это не дает. Удобно реализовывать прямое умножение элементов в полном поле и использовать декодер без обратных элементов. Все это ИМХО, разумеется.
  11. В первом сообщении : 2.1 если это LDPC код - то он систематический. Если исходный код был систематический (в классическом смысле, как я описал выше), то обязательно удастся ;) Честно говоря, не встречал информационные биты, рассыпанные как попало по слову. Обычно или в начале или в конце. Ну, спорить не буду, всякое в жизни бывает ;)
  12. Было сказано, что искомый код систематический. Обычно это означает, что порождающая матрица кода имеет вид G=[ I | P ], где I - единичная матрица k*k. Вы набираете (каких попало) k линейно независимых кодовых слов в матрицу, а потом диагонализируете ее на первых k позициях, приводя к единичной матрице в левой части. И получаете единственно возможную искомую порождающую матрицу G для систематического кода. Только, мне кажется, что ТС нужна не порождающая, а проверочная матрица. И он как-то строит ее в обход порождающей ;) И вопрос о многовариантности представления кода с помощью проверочной (или порождающей) матрицы его совершенно не касается, т.к. ему надо ошибки исправлять, а для этого годится любой из многих вариантов проверочных матриц, главное, чтобы там было единиц поменьше, т.к. он, видимо, хочет использовать алгоритм, заточенный под низкую плотность единиц в H ;) А после исправления ошибок он просто возьмет первые k позиций, содержащих полезную информацию. И истинный вид порождающей матрицы его мало волнует.
  13. Это правильно. Просто участники диспута, задающие вопрос об эквивалентных кодах, путают понятия эквивалентных кодов и эквивалентых проверочных матриц для одного и того же кода. Еще народ совершенно зря кошмарит бедного студента по поводу нахождения разреженной матрицы LDPC кода. На самом деле бедному студенту нафиг не нужен код в разреженном виде (хоть студень, возможно, об этом и не подозревает ;)). Похоже, что народ кроме BP и MIN-SUM алгоритмов уже ничего не может сделать с LDPC. Эх, молодежь.. ;)) Для данного случая вполне подойдет декодирование по информационным совокупностям с покрывающими полиномами небольшого веса. В простонародье этот метод называется OSD и он дает вполне приличные результаты именно в хорошем канале. (интересующимся - гугл в помощь). Сильно сомневаюсь в универсальности вашего метода для восстановления сколь-нибудь длинных и сколь-нибудь тяжелых разреженных матриц, пригодных для традиционных методов декодирования LDPC. На самом деле вам надо решать задачу нахождения слов минимального веса в двойственном коде, и из этих слов лепить матрицу. Это трудно.. Хотя, для малых длин и очень разреженных матриц... может быть.
  14. Я похвалил обслуживание. Качество плат пока устраивало. Последние 6 лет. Посмотрим, что будет дальше.