Гаражные войны

[serggio]

А вы попробуйте?  Слабо?  А как же гуру?

Ну понимаете, достаточно сложно модерировать технический раздел не разбираясь в нюансах.
Одно дело просто реагировать на жалобы, но даже разбирать жалобу надо с точки зрения ее адекватности. Не всегда они, эти жалобы, адекватны.
С другой стороны переносить оффтоп из темы в тему и просто удалять оффтоп - тоже надо знать тематику. Иначе темы таким клубком переплетутся и в дрязгах и разносторонних вопросах потонут, что огого.

Я например не лезу в тему моноколесников, или там велофар или доработки контроллеров и БМС. Пускай их местные модераторы там разбираются. К нам остальные глобальные модераторы тоже как вы заметили не ходят. Но если там откровенный мат, полный беспредел, то конечно выписываю пилюлю без разбора.

А вы попробуйте?  Слабо?  А как же гуру?

Кстати, а почему не вы? Вы вроде как не участвуете в дискуссиях?

[Alex Rad]

Цитата: Alex Rad писал Сегодня в 16:07
А вы попробуйте?  Слабо?  А как же гуру?
Кстати, а почему не вы? Вы вроде как не участвуете в дискуссиях?

Сам являюсь админом и создателем двух форумов, времени может не хватить.

[СтэпАн]

В чем разошлись мнения?..  не вижу каких-то серьезных противоречий.  БЛка закончила заряд на подъеме токе в 5А и напряжении около 15В.

это нормально или не штатно?

[UriBas]

Каюсь, что не следил за анализом графиков по БЛ-ке.
Правильно ли понял, что на любой емкости АКБ min-ток окончания заряда ~45mA у этого ЗУ ? 

Скорей всего так и есть - минимальный порог = 40-50мА.  Потому, что меньше - это уже почти за пределами ее разрешения.

это нормально или не штатно?

У БЛки это видимо штатно (5А до порога) по отношению к режиму до 15,2В..  в основном (режиме) у нее штатно понижение до 40-50мА.

[Branimir]

Скорей всего так и есть - минимальный порог = 40-50мА.  Потому, что меньше - это уже почти за пределами ее разрешения.У БЛки это видимо штатно (5А до порога) по отношению к режиму до 15,2В..  в основном (режиме) у нее штатно понижение до 40-50мА.

Если так, то это отличный зарядник, но только для АКБ емкостью выше 50Ah.
Причем, чем выше емкость АКБ, заряжаемого данным устройством (если действительно min-ток окончания заряда 45-50mA!!!) тем лучше будет результат полноты заряда.

Проверю в ближ. время min-ток окончания заряда на АКБ большей емкости и на всех программах (пусть и с нарушением правил замеров, т.е. включая амперметр в цепь заряда).

Кстати, сопротивление DT9205A в режимах амперметр с пределом 20А и в режиме миллиамперметр до 200mA одинаковое, подскажет кто-нибудь?


Недавно обнаружил среди старых архивов записки по тому несчастному наливняку 60Ah EN540 (что умер с КЗ банки после BL-ки) с остатком емкости около 20Ah (при разряде по ГОСТ, как серджио любит) с зарядом БЛ-кой
с последовательным увеличением порядкового номера программ (с №1 по №4) и увидел, что перезапуск программы №4 был аж 6 раз,
но Umax не поднималось выше 15,86v и падало с каждым перезапуском (и увеличением нагрева).
Так, что я отличился, но и ограничения тока на ЗУ видимо были не шибко приятны для остаточной емкости ~35%...
Что-то не так в датском королевстве, все-таки.

[Vova_n]

Полагаете, что БЛ-ка на разной емкости АКБ имеет разный min-ток окончания заряда?

Иначе и быть не может.

Вот где-то тут и может быть собака... На границе СССV

Покажите мне здесь границу СС/СV   

Смотрим в право видим установки по этапам программы, как тока так и напряжения, видим установка напряжения 16в смотрим в график, откуда начались флуктуации? смотрим выше они вообще дошли до 16в? в головах у вас, что то рас синхронизировалось ребятки, расцениваю дальнейшее, как тролиг и не более ибо уличить вас в дилетантстве в рэа особых поводов нет.

На графике видно как быстрый CV пропустил ограничение 15В задрав напряжение выше. Период измерения логгера желает быть лучше, т.к. заснятый ток не дружит с напряжением. Конечно, основываясь на такой лог можно напридумывать, что угодно.

Так и не вижу обоснований про

какие-то импульсы с АКБ, идущие с периодичностью 3 раза в сек..

Я делился наблюдениями и необычным поведением тока и напряжения снятых с акб и нравится вам или нет буду это делать если посчитаю это нужным.
Логгер вполне приличный для поставленных ему задач и всё там дружит и ток и напряжение, когда ток растёт напряжение чуть проседает на несколько мв, придирки кидайте туда же, что и раньше в свою топку да по глубже 

Спойлер

Хотелось бы узнать, в своих исследованиях измеряли пару двойных слоев, или для точности измерений все 24 слоя соедини последовательно ?

знакомый заход тролика, не единожды и более 24раз видел подобное и детально изучил.

Ошибаетесь. Уже давно, если ссылаюсь на ЗУС - рассматриваю его как пример ЗУ заряжающее АКБ прерывистым током, до недавних пор рекламируемое многими форумчанами. Не поверите - не хочу задеть Алксандра или его ЗУ.

ну да ну да охотно верю.
Вообще мне жены хватает для стимуляции мозга по средства мозгоклюйства, не стоит делать попытки занять её место.

Жду полтора года, могу еще подождать.

Ваше право ждать от жизни чего угодно, я перед собой задач не ставил оправдать ваши ожидание по данному поводу.

Надеюсь тест делали корректно, заряд глубоко разряженной АКБ продолжался 12ч ?

вы пробовали внимательно читать, что вам пишут? говорят помогает 
Вот вам на пару с [user]SapienzSPB[/user], график с нормального agm не имеющего значительных отличий в ячейках, на том же самом приборе с "хреновым стабилизатором и логгером"

За одно подумайте может ли в последовательной цепи имеющей разные по свойствам состоянию сложные элементы возникнуть ситуация при которой может возникнуть дифференциальное отрицательное сопротивление http://femto.com.ua/articles/part_2/2711.html
Или это противоречит вашему мирозданию? 

[Cyberpapa]

Я делился наблюдениями и необычным поведением тока и напряжения снятых с акб и нравится вам или нет буду это делать если посчитаю это нужным.

Лично мне нравится. Т.к. мы тут собрались чтобы делиться наблюдениями и их обсуждать.

[Cyberpapa]

У меня было более 2000 "плюсиков", а теперь откройте статистику и посмотрите кто мне "убрал" все плюсики..... 

[user]Alex_Soroka[/user], проведите простой эксперимент, возможно получите ответ на свой вопрос и догадаетесь куда пропала подавляющая часть ваших плюсиков:
1) Запомните свою статистику благодарностей.
2) Поставьте 5 или 10 минусов, под плохими на ваш взгляд сообщениями. (в теме десульфатации малыми токами найдете кучу таковых)
3) Еще разок посмотрите свою статистику благодарностей, подсчитайте, как и на сколько она изменилась.
4) Если Вы действительно хороший программист - напишите парсер подсчитывающий кол-во поставленных вами минусов, запустите его ночью, дабы не подгружать форум в часы пик....

ИМХО, после подсчета вспомнится народная мудрость: "Как аукнется так и откликнется" и получите ответ на свой вопрос "кто мне "убрал" все плюсики ?"

[СтэпАн]

У БЛки это видимо штатно (5А до порога) по отношению к режиму до 15,2В..  в основном (режиме) у нее штатно понижение до 40-50мА.

а мне представляется, что в этом тесте случился терморазгон и БЛка прервала процесс заряда да бы не навредить всем и всему...
я достаточно часто практикую 3-й режим, подзаряжая свои акумв в неотапливаемом холодном гараже осенью и весной, и ни разу не видел на финише зарядный ток да же более 0,2...0,3А а здесь где то ок. 5А....

[SapienzSPB]

Смотрим в право видим установки по этапам программы, как тока так и напряжения, видим установка напряжения 16в смотрим в график, откуда начались флуктуации? смотрим выше они вообще дошли до 16в? в головах у вас, что то рас синхронизировалось ребятки, расцениваю дальнейшее, как тролиг и не более ибо уличить вас в дилетантстве в рэа особых поводов нет.

Спокойнее, коллега. Я предположение (на основании своего опыта) сделал. Вы предоставили график который показывает что это вряд ли так. Я с ним согласен. Действительно CCCV граница четкая.  Где троллинг?
Предположительно остается две версии Ваша и Киберпапы(о малых токах). Вы думаете я не хочу найти новые эффекты в АКБ? Я уже заочно согласен с тем что они есть. Теперь давайте спокойно подтвердим находку, отсекая ошибки измерения, но без истерик и уважительно..
А что за трапеция перед началом 3го режима? Какова ее длительность? И что во время нее творится с током? Вы не изучали этот вопрос?

[Alex_Soroka]

разбирали по косточкам, но мнения крепко разошлись...
я вон повторно выложил тот график, так да же после дополнения его подробным логом ни кто не смог  прокомментировать...

Я комментировал, но все мои каменты оттуда вытерли. ЧТобы не портить светлого лика БЛ-ки.

[Alex_Soroka]

Изучил вдоль и поперёк как XL4016 так и XL4015, так и устройство самой платформы прощупал.

то есть, вы проверили поведение БП и его реакцию на "единичный импульс" воздействия?
Коммутация — процессы, происходящие в первый момент времени после переключения в электрических цепях при замыканиях и размыканиях различных участков цепи.
И исследовали "функцию управления", и как БП реагирует на факт переключения? ("моргалка" это как раз "коммутация" в чистом виде, БП на индуктивно-емкостную нагрузку, которой является АКБ).

На напряжение и на ток стоит два отдельных О.У. на ток OP213e на напряжение LM358 МК в зависимости от установок задаёт на них опору стабилизации, рулят О.У. шимом через шустрый мультик CD4053M, скорость переключения не хуже 0,5мкс.

это ниочем не говорит  есть оптопары ОС, есть конденсаторы сглаживания, и всю эту цепочку надо рассматривать в целом как "переходную функцию". Иначе будет "как всегда": мы взяли БП с кучей кондеров во вторичке и пытаемся им ключевать АКБ, и все было хорошо, пока "тау" регулирования было быстрее чем наши "ключевания", и запаса в кондерах хватало, а потом началось...

Вы можете сопоставить цифры в 1,2мс это скорость обратной связи с ШИМ формирующая опорное напряжение и то, что твориться на линии напряжения снимаемой логгером раз в секунду

я говорю о переходных процесса в БП  которые происходят при коммуутации. Это гораздо меньшее время чем ваши 1.2мс.
для сравнения, в типовых БП на базе например ТОР250 "тау" колеблется в пределах 1/1200 -- 1/1500 секунды.
Это "полная реакция системы", а не быстродействие отдельного ОУ 

Добавлено 29 Нояб. 2019 в 12:04

На границе СССV что-то рассинхронизируется и наблюдаются колебания.

не что-то а "Бурст режим" БП начинается, потому что "пулемет" преобразователя БП, начинает "строчить с перерывами", и все висит на емкостях выходных (тысячи мкФ) самого БП, и в этом-же месте начнинаются "коммутации" АКБ на БП зарядки от "моргалки"(или ЗУ). В итоге - если не согласовано управление МК--оптопары-БП , то будет болтанка еще та.
И "лечить" ее очень сложно, потому что очень велика инерция на выходе БП.

[Alex_Soroka]

Если быстродействие отличается не на единицы процентов а хотя бы на десятки - либо кривой компилятор C либо код написан настолько странно что оптимизатор компилятора с ним не может справиться.

1) вы сам программист ? Писали на Асемблере или только почитали что-то? Я серьезно спрашиваю, чтобы понимать с кем разговариваю.
2) оптимизирующий компилятор С при работе на 8-и битных платформах, и так "творит" кучу конструкций которые постоянно трогают стек, причем если я заведомо стараюсь избавляться от "вызова процедур" и дебильного "процедурного программирования", то компиляторы упорно "приводят в соответствие". 
3) у меня в программе несколько параллельных процессов и несколько прерываний  компилятор не может знать и предугадать что и зачем происходит.

Зачастую после хороших компиляторов код работает быстрее чем на асме

нда...
я начинал писать на Асме где-то в 1984 году. До того как узнал что где-то там на западе есть какие-то "компиляторы С".
не смешите меня насчет "компилятор делает быстрее". Компилятор не знает что я хочу получить в итоге, и зачем пишу именно так, чтобы он не вмешивался в логику, и не расставлял CALL там, где мне категорически этого не хочется...

[MichaelOdessa]

1) вы сам программист ? Писали на Асемблере или только почитали что-то? Я серьезно спрашиваю, чтобы понимать с кем разговариваю.

Да, с 1993 года АСМ, c 1995 C и далее С++, потом уже куча всего разного.

2) оптимизирующий компилятор С при работе на 8-и битных платформах, и так "творит" кучу конструкций которые постоянно трогают стек, причем если я заведомо стараюсь избавляться от "вызова процедур" и дебильного "процедурного программирования", то компиляторы упорно "приводят в соответствие".

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

3) у меня в программе несколько параллельных процессов и несколько прерываний  компилятор не может знать и предугадать что и зачем происходит.

Компилятору и не нужно - у вас насколько я понимаю не многоядерный процессор и синхронизация потоков, а последовательное выполнение в пределах определенного периода времени. А вот прерывания иногда сильно портят картинку - они как раз заставляют сохранять все где-то - например в стеке. Иногда цикл опроса получается оптимальнее с точки зрения производительности (не знаю ваших нюансов поэтому общее мнение).

нда...

В том же ядре linux уже постепенно отказываются от асма - код поддерживать сложнее, выигрыша в производительности нет. Есть конечно набор специфических задач когда невозможно на том же C объяснить какой именно набор команд в конечном итоге необходимо использовать (но это как правило в сторону векторных вычислений и то есть специальные расширения), вот там приходится выкручиваться только через асм.

и не расставлял CALL там, где мне категорически этого не хочется...

По идее не должен если все параметры влазят в регистры, присутствует команда jmp и код удовлетворяет ограничениям на длину прыжка.

Ну это все лирика, обычно быстро получается на простых примерах проверить что генерирует компилятор и принять решение - либо менять компилятор, либо таки да писать отдельные части на асме если компилятор совсем тугой.

Кстати, иногда дешевле сменить и контролер и компилятор чем разрабатывать оптимизированные версии софта (просто по деньгам и трудозатратам)

[СтэпАн]

Я комментировал, но все мои каменты оттуда вытерли. ЧТобы не портить светлого лика БЛ-ки.

да ладно, вам...кто там только не топтался по БЛке...не была ни когда БЛка под крышей модераторов...
так что скорее всего ваши посты удалили из-за хамоватой формы их изложения...
кстати, и минусовал вам тогда за критические замечания по БЛке тот, кто нынче громче всех истерит...

[serggio]

ИМХО, после подсчета вспомнится народная мудрость: "Как аукнется так и откликнется" и получите ответ на свой вопрос "кто мне "убрал" все плюсики ?"

Мне надо было просто раньше во все это непотребство вмешаться..
Может и не было бы ситуации с вопросом «кто кому убрал плюсики».
Первый за минусы уже со штрафным баллом ходит, можете продолжать. Возможно и плюсики в дальнейшем уже не понадобятся..

[Vova_n]

А что за трапеция перед началом 3го режима?

Всё просто, всё что вы видите справа вверху это пред установки по этапам с заданными параметрами тока и напряжения, о ни по очереди включаются и как только заданные условия выполнены, включается следующий этап. При выполнении каждого из этапов идёт отключение стабилизатора от акб и вновь включается с новыми установками. Сами установки ток стабилизации и ток окончания этапа смотрите так же в колонке справа, не вижу там ничего особенного.

[Alex_Soroka]

Да, с 1993 года АСМ, c 1995 C и далее С++, потом уже куча всего разного.Мало времени уделил всяким мелким контролерам и их компиляторам.

и зря мало уделяли 
сейчас идет поголовная шиза от "писателей компиляторов" на тему применения GCC везде где только можно 
а начиная с 11 версии GCC, если я не ошибаюсь (сейчас уже 14-е...) компилятор стал настолько "умным" что вмешивается в работу программы, компилируя то что сам хочет, ибо считает "так лучше".

В компиляторе для них есть возможность подсказать компилятору что из переменных должно быть в регистрах, что из функций inline и т.п.?

нет. Не во всех компиляторах и не всех фирм.

Стек используется при вызове функций по большей части как передача параметров

вот для реалтайма на 8 битах мне только этого не хватало! прятать в стек кучу регистров а потом делать CALL, а потом пробегает табун прерываний и потом надеемся что стек размотается взад.
При последовательной работе (как в скетчах Ардуины) там все просто - что закатали в стек то потом и выкатаем, все операции идут одна за другой, потому что main loop. У меня-же не так. У меня несколько процессов занимаются своими делами.

если функция разворачивается как inline - стек использоваться не должен.

для inline нужно очень много памяти  а в МК ее катастрофически ни на что не хватает... Не забывайте что еще и для ЖКИ надо кучу текстов хранить...

у вас насколько я понимаю не многоядерный процессор и синхронизация потоков, а последовательное выполнение в пределах определенного периода времени.

многозадачность у меня, с разделением ресурсов, а не "временных слотов". хотя и "слоты" есть, но не том понимании как в книгах.

В том же ядре linux уже постепенно отказываются от асма - код поддерживать сложнее, выигрыша в производительности нет.

отказываются потому что вымерли те кто на Асме писал  остались одни "писатели для фрейворков" и сферических в вакууме процессоров. Я недавно удивлялся вирусу, который 80 мегабайт весит и написан на .NET 
печально это.

Ну это все лирика, обычно быстро получается на простых примерах проверить что генерирует компилятор и принять решение - либо менять компилятор

не сильно большой выбор есть для Атмега  или использовать его "рекомендованное" на GCC которое на компе весит 1 гиг в установке, и генерит код который не влазит в память МК, либо CVAVR , который генерит очень компактный код, но выделывается знатно при оптимизации, создавая иногда разные ситуации.
а паралельные процессы реалтаймоввого управления "отладчиком" непросто проверять, на реальном железе получается быстрее и понятнее.

Кстати, иногда дешевле сменить и контролер и компилятор чем разрабатывать оптимизированные версии софта (просто по деньгам и трудозатратам)

вот я и сменил Атмел на MSP430 
земля и небо...