www.swiatelka.pl

Witam
Jako laik i użytkownik latarek napiszę tak - przedstawiony przez Ciebie sposób kontroli temperatury (pomijając terminologię techniczną, z której niewiele zrozumiałem) jest bardzo przyjazny dla przeciętnego użytkownika.

Logika sterowania jest prosta:
- jeżeli Temp < Ta - to w LED idzie tyle ile ma iść
- jeżeli Ta < Temp < Tk - to sterownik stopniowo zmniejsza prąd
- jeżeli Temp < Ta i prąd jest poniżej wartości planowanej (został ograniczony) - to sterownik stopniowo zwiększa prąd aż do założonej wartości
- jeżeli Temp > Tk - to sterownik natychmiast się wyłącza (analogicznie do zejścia napięcia zasilania poniżej 2,8V)

- bardzo dobre rozwiązanie

Uznałem, że nie ma sensu w tym przypadku migać LED`em głównym, gdyż monitorowanie temperatury z założenia ma mieć charakter zabezpieczenia jako element bezpieczeństwa i nie ma konieczności dodatkowego informowania o tym użytkownika.

- dokładnie tak!
Co do kalibracji - czy byłaby to czynność jednorazowa, czy możliwa byłaby ponowna kalibracja "z poziomu użytkownika"?
edit. Czekam z niecierpliwością na wersję komercyjną

Dziękuję za komentarze.

yano pisze:Co do kalibracji - czy byłaby to czynność jednorazowa, czy możliwa byłaby ponowna kalibracja "z poziomu użytkownika"?

Opcja kalibracji będzie dostępna z poziomu użytkownika i tak jak inne ustawienia w wersji 2.2 będzie znajdować się w menu konfiguracji (tym po 5-cio kliku) jako jedna z dostępnych tam pozycji.

Mechanizm ten będzie działał dokładnie tak samo jak włączanie i wyłączanie strobe`a, czy kontroli napięcia ogniwa, z tym, że podczas włączania funkcji pomiaru temperatury automatycznie będzie przez sterownik przeprowadzana procedura kalibracji odczytująca wartość zastanej temperatury i ustawiająca ją jako próg Ta.

A zatem w dowolnej chwili nową funkcję pomiaru temperatury będzie można aktywować (przeprowadzając tym samym nową kalibrację) lub deaktywować.

Witam
Opcja kalibracji temperatury przez użytkownika, jest dla mnie bardzo atrakcyjna, tym nie mniej widzę tu pewną pułapkę w postaci określenia przez użytkownika temperatury progowej. Jeśli będzie to miało miejsce podczas nagrzewania latarki, to wymusiło by pomiar innym termometrem faktycznej temperatury LEDa, gdyż niewiele latarek spełnia warunek właściwego odprowadzania ciepła. Tak więc pomiar "na oko" przez ocenę temperatury body, może być bardzo mylny.
Moim zdaniem, trzeba by wymyślić jakąś procedurę "wygrzewania latarki" np, w styropianowym pojemniku (jak na butelki dla niemowląt), wtedy ograniczone zdolności wypromieniowania ciepła przez obudowę, będą powodowały lepsze zrównanie się temperatury diody i obudowy.
Uważam, że dobrym rozwiązaniem była by dystrybucja driverka z jakimś domyślnym ustawieniem, dla "zwykłych zjadaczy chleba".


Podziwiam i pozdrawiam

PS: A kiedy można liczyć na egzemplarz komercyjny, bo zaczynam odkładać kasę

Hmmm... Super oprogramowanie powiadasz...

Brak fajnego softu to dla mnie spora wada. Pamięć i możliwość indywidualnego programowania trybów to największe zalety sterownika df'a. Do Twojego sterownika (Edim)potrzebnaby była kolejna płytka PCB z prockiem i lepszym softem, a to już się nie zmieści. (chyba że zrobisz super oprogramowanie )

Odnosiło się to do do driverka Edima L528

Co do projektu v 3.0 to rozumiem, żę nadal pozostają grupy trybów,a układanie "klocków" jest w obrębie każdej grupy?

Twoją najnowsza odsłona jest dla mnie niemal idealna

Kontrola temperatury jest też przydatna, ale dla mnie nie konieczna(może uda się jeszcze wcisnąć zalety wersji 3.0 i wersji z kontrolą temp. w procku? Może jakiś inny mały Atmel?)

Mam jednak pytanie natury technicznej - masz może jakiś plan zastąpienia AMC-ków jakimś bardziej wydajnym prądowo rozwiązaniem(a jednocześnie równie kompaktowym) Chodzi mi o ograniczenie prądu na poziomie ok. 5A

Oczywiście jestem chętny na wersję komercyjną v 3.0

Podziwiam włożony wkład pracy - twoje sterowniki nie mają sobie równych.

Pozdrawiam
upek

Ciekawe co uda Ci sie jeszcze tam wcisnąć? A właściwie co jeszcze mogło by sie przydać to już nie mam pojęcia

Moje gratulacje Darku.

Podpisuję się pod tym, co napisał Pyra - wydaje mi się, że dla niektórych użytkowników (np. dla mnie ) najlepszym rozwiązaniem byłoby ustawienie określonych wartości Ta i Tk bez możliwości przestawienia z poziomu użytkownika:
1) nie każdy ma techniczną możliwość ustawienia optymalnych wartości Ta i Tk - nie za wysokich, ale i nie za niskich;
2) instalując w latarce sterownik z kontrolą temperatury nie potrzebowałbym możliwości deaktywacji tej właśnie funkcji, która w założeniu ma zapewnić właściwe warunki pracy sterownika i diody, a tym samym jak najdłuższą ich trwałość (podobnie jak kupując samochód z systemem ABS nie potrzebuję możliwości deaktywacji tego systemu, który z założenia ma poprawić bezpieczeństwo podróżnych).
edit. lennin, miło Cię widzieć na forum

Darku, a nie myślałeś aby użyć ATtiny25 i zrobić pomiar temp. z wykorzystaniem wewnętrznego czujnika? Na pewno myślałeś Używając gotowego driverka 8*AMC można stworzyć w miarę tanią opcję, z kontrolą temperatury, do zasilania XM-L. Driverek nie zmienia praktycznie swoich rozmiarów. Pigułę z powierzchnią procka można połączyć np. przy pomocy miedzianej kostki. Mam spreparowany taki układ. Kalibracji dokonuję w temp. pokojowej, a w sofcie mam tylko offset dla różnych progów.

Podoba mi się Twój pomysł z klockami.

yano pisze:Podpisuję się pod tym, co napisał Pyra - wydaje mi się, że dla niektórych użytkowników (np. dla mnie ) najlepszym rozwiązaniem byłoby ustawienie określonych wartości Ta i Tk bez możliwości przestawienia z poziomu użytkownika

Jakie zatem wartości temperatury sugerujecie?

Zakładam, że nie każdy będzie miał możliwość umieszczenia czujnika temperatury tuż przy diodzie LED i czasem jedyną pozostającą możliwością będzie przytulenie go na krawędzi MCPCB lub wręcz umieszczenie wewnątrz "piguły" po drugiej stronie radiatora z diodą LED (od spodu).

I tu niestety sprawa się nieco komplikuje, gdyż dość istotnie zmieniają się warunki pracy: temperatura, która im dalej od struktury diody, tym będzie mniejsza oraz rośnie bezwładność temperaturowa, czyli obserwowalna zmiana temperatury, która zachodzi z pewnym opóźnieniem.

Pierwszy czynnik związany z gradientem temperatury łatwo jest skompensować poprzez obniżenie progu wartości granicznej pomiaru - przykładowo, dla pomiaru na MCPCB może być to 80*C, a, dla tylnej części piguły np. 50*C

Drugi problem oddalania punktu pomiaru związany jest z bezwładnością termiczną. A to z kolei utrudnia prawidłową regulację, gdyż zależnie od konkretnego rozwiązania radiatora i jego pojemności cieplnej informacje odbierane przez czujnik docierają do niego po pewnym czasie.

W wyniku tego do prawidłowej regulacji konieczne jest nie tylko zastosowanie specjalnych algorytmów, ale i znajomość tzw. charakterystyki odpowiedzi, czyli reakcji źródła ciepła - LED`a oraz całej ścieżki na drodze do czujnika temperatury.

Jednocześnie algorytm regulatora musi pracować w zakresie liniowym, a więc w taki sposób regulować prądem diody, aby zmiany te były na tyle wolne i o małych wartościach by nie były zauważalne dla użytkownika. Natomiast z drugiej strony musi być na tyle szybki by reagować na ciągle zachodzące zmiany, tak by nie doprowadzić do niestabilności lub wzbudzenia się układu.

Zjawisko to przypomina ciągłe balansowanie na linie.

Aktualnie na rzeczywistych układach testuję zachowanie się różnych rozwiązań implementacyjnych regulatorów - od pierwotnej najprostszej koncepcji z jednym progiem decyzyjnym, poprzez rozwiązanie 2-progowe ze "strefą martwą" pomiędzy nimi, aż po zaawansowane rozwiązanie adaptatywne i proaktywne, działające z wyprzedzeniem - w tym, wykorzystujące pomiar drugiej pochodnej (analizę nie tylko wartości bezwzględnej temperatury, ale i jej tendencji: wzrostu lub spadku).

Temat jest skomplikowany z uwagi na różnorodność reakcji rzeczywistego zastosowanego w latarce układu odprowadzania ciepła, gdzie ciężko jest zastosować jeden dobrze sparametryzowany algorytm, dający zawsze optymalne rezultaty.

Saul pisze:Darku, a nie myślałeś aby użyć ATtiny25 i zrobić pomiar temp. z wykorzystaniem wewnętrznego czujnika? Na pewno myślałeś

Oczywiście, że brałem pod uwagę takie rozwiązanie.
Plusem jest to, że w środku układu na 5-tym kanale multipleksera jest ów czujnik temperatury, który daje dość liniowe wartości odczytów na ADC, które wprost można zamapować na daną temperaturę. Nie bez znaczenia jest także 2x więcej pamięci kodu niż w 13-tkach, której nigdy nie ma za wiele
Minusem jest natomiast brak możliwości pomiaru temperatury w miejscu jak najbliżej położonym do źródła ciepła (LED-a) oraz cena układu, konieczność dodatkowych nakładów pracy związanych np. z przelutowywaniem itd.
Z tego powodu na chwilę obecną zdecydowałem się jednak na rozwiązanie z zewnętrznym termistorem.
Jak starczy mi czasu, to wrócę do tematu pomiaru temperatury bezpośrednio ze struktury diody LED - chwilowo temat musiałem odłożyć, bo przy stosowanych u mnie szybkich PWM-ach, pomimo sprzętowej synchronizacji wyzwalania pomiaru na ADC z timerem nie uzyskiwałem wystarczająco dokładnych wyników pomiaru.

Saul pisze:Używając gotowego driverka 8*AMC można stworzyć w miarę tanią opcję, z kontrolą temperatury, do zasilania XM-L. Driverek nie zmienia praktycznie swoich rozmiarów. Pigułę z powierzchnią procka można połączyć np. przy pomocy miedzianej kostki. Mam spreparowany taki układ. Kalibracji dokonuję w temp. pokojowej, a w sofcie mam tylko offset dla różnych progów.

A w jaki sposób zrealizowałeś regulację temperatury?

Saul pisze:Podoba mi się Twój pomysł z klockami.

Przy ograniczonej możliwości komunikowania się użytkownika ze sterownikiem, to chyba jedyne w miarę rozsądne rozwiązanie. W każdym razie niczego prostszego nie udało mi się wymyślić.

df pisze:Pierwszy czynnik związany z gradientem temperatury łatwo jest skompensować poprzez obniżenie progu wartości granicznej pomiaru - przykładowo, dla pomiaru na MCPCB może być to 80*C, a, dla tylnej części piguły np. 50*C

Drugi problem oddalania punktu pomiaru związany jest z bezwładnością termiczną. A to z kolei utrudnia prawidłową regulację, gdyż zależnie od konkretnego rozwiązania radiatora i jego pojemności cieplnej informacje odbierane przez czujnik docierają do niego po pewnym czasie.

W wyniku tego do prawidłowej regulacji konieczne jest nie tylko zastosowanie specjalnych algorytmów, ale i znajomość tzw. charakterystyki odpowiedzi, czyli reakcji źródła ciepła - LED`a oraz całej ścieżki na drodze do czujnika temperatury.

Można chyba przyjąć, że do każdej lampki, do jakiej będzie montowany driver, trzeba będzie modifykować kilka parametrów, różna lampa=różny radiator.

Fajnie, fajnie, zapowida się naprawdę ciekawy driver.
Jeśli przegapiłem, albo nie doczytałem, czy mógłbyś przybliżyć poza funkcjami - programem coś wiecej? Ostatnie Twoje drivery były do rozwiązań 1 diodowych.

Czy planujesz te rozwiązania stosować do dzisiejszych coraz bardziej popularnych modułów 3 i 5 ledowych ?

df pisze:Saul napisał/a:
Używając gotowego driverka 8*AMC można stworzyć w miarę tanią opcję, z kontrolą temperatury, do zasilania XM-L. Driverek nie zmienia praktycznie swoich rozmiarów. Pigułę z powierzchnią procka można połączyć np. przy pomocy miedzianej kostki. Mam spreparowany taki układ. Kalibracji dokonuję w temp. pokojowej, a w sofcie mam tylko offset dla różnych progów.

A w jaki sposób zrealizowałeś regulację temperatury?

Na razie temperaturę kontroluję w bardzo prosty sposób. Po przekroczeniu progu zmieniam tryb na niższy. Sprawdzam po czasie czy temp. rośnie, jeśli tak to ponownie zmieniam tryb na niższy. Działa to w jedną stronę, czyli po wystygnięciu nie przeskakuje do wyższego trybu. Oczywiście taka opcja działa tylko przy założeniu, że tryby są rozłożone prądowo narastająco (np. 1-10%, 2-50%, 3-80%, 4-100%).

Co innego jednak opracować sterownik z kontrolą temperatury pod konkretny wyrób (po testach parametry można ustawić na sztywno), a co innego przygotować uniwersalny produkt "dla mas", do wykorzystania w różnych warunkach.
Jedyny prosty pomysł jaki mi przychodzi od głowy to kalibracja i zapis wartości dla temp. pokojowej do pamięci. Następnie utworzenie tablicy wartości offsetu dla kilkunastu-kilkudziesięciu progów. Kolejne progi byłyby oddalone np. o ~4*C.
Teraz wystarczyłoby zrobić w setupie opcję wyboru progu gdzie np. każdy błysk oznaczałby +4*C w stosunku do temp. pokojowej. Np. akceptacja po 8 błysku oznaczałaby 8 x 4*C + temp. pokojowa = ~52*C
Jeśli użytkownik stwierdziłby po testach, że jednak próg mu nie odpowiada to w każdej chwili może zmienić w górę lub w dół. W ten sposób będzie szansa na właściwe ustawienie progu, niezależnie od tego gdzie będzie zamontowany termistor. Odstępy między progami nie muszą być precyzyjnie wyznaczone. Moim zdaniem jak będzie nawet rozrzut między 3 a 5*C to będzie OK.
Oczywiście najlepiej aby użytkownik podczas takiej kalibracji mierzył temp. jakimś niezależnym miernikiem w okolicach diody (ew. na obudowie; w zależności od konstrukcji lampy) i na tej podstawie dobierał próg zadziałania zabezpieczenia termicznego.

Witam
Pomysł z pomiarem temperatury w procku ma kilka wad.
1. Mierzymy temperaturę płytki na której mamy driver, jak rozumiem domyślnie AMC, czyli im wyższe napięcie tym większa moc tracona w driverze i goręcej na płytce, a na diodzie LED bez zmian.
2. Słaba dokładność pomiaru.

Niestety napięcie referencyjne takich procesorków jest mało dokładne. Ja też stosuję termistor podłączony bezpośrednio do masy i opornik do zasilania, natomiast napięcie zasilania jako referencję.
Co do samego algorytmu, to coś takiego, że powyżej pewnej temperatury zaczynamy obniżać, czyli działanie z jednym progiem nie jest zbyt dobre. Niestety ja też w ostatnim sofcie coś takiego byłem zmuszony zastosować, ze względu na brak wystarczającego miejsca w pamięci na kod. Wcześniej z powodzeniem stosowałem coś takiego, że jasność zależała bezpośrednio od wskazań ADC w pewnym zakresie. Czyli np. od 100% dla 70 stopni do 5% przy 80 stopniach. Niestety wymagało to trochę więcej obliczeń na liczbach dłuższych niż bajt i po prostu brakło w tym sofcie miejsca.

EdiM pisze:Niestety napięcie referencyjne takich procesorków jest mało dokładne. Ja też stosuję termistor podłączony bezpośrednio do masy i opornik do zasilania, natomiast napięcie zasilania jako referencję.

Edim, z mojego doświadczenia wewnętrzne napięcie referencyjne (1,1V) jest dość stabilne.
Problem stanowi zaś metoda zastosowanego pomiaru.

Dla pomiaru wartości bezwzględnej napięcia zasilania (stan akumulatora) stosuję wewnętrzny Vref, który sprawdza się doskonale.

Natomiast w przypadku pomiaru temperatury, a więc napięcia na dzielniku w skład którego wchodzi termistor + rezystor, źródłem błędu jest niestabilność napięcia zasilania Vcc, które w przypadku Li-Ion może się zmieniać w bardzo szerokim, bo ponad 30% zakresie (2,9-4,2V).
Ponieważ w tym przypadku nie jest istotna wartość bezwzględna, lecz współczynnik podziału (proporcja napięcia) - by skompensować zmieniającą się w czasie wartość Vcc zarówno dzielnik jak i napięcie referencyjne dla ADC powinny być identyczne i podlegać dokładnie tym samym zmianom.

Attiny13 nie ma możliwości wyprowadzenia Vref na port wyjściowy, a zatem jedyną możliwością kompensacji pomiaru napięcia na dzielniku zasilanym z Vcc jest przyjęcie napięcia referencyjnego ADC jako Vcc.

Pamiętaj także, by zachować odpowiednie timingi wymagane do pomiaru ADC.
Jest to szczególnie istotne, gdy przełączany jest multiplekser lub zmieniane w locie napięcie referencyjne.
Producent zaleca po zmianie Vref zignorowanie pierwszego odczytu z uwagi na niepewność pomiaru nawet przy zachowaniu wymaganej liczby cykli na przetwarzanie przetwornika - i potwierdzam, że jest to faktycznie bardzo ważne.

Co do napięcia referencyjnego to jest stabilne ale niedokładne. Według dokumentacji 1,1V +/- 0,1V.
Czyli tolerancja ok. 10%, Bardzo słaba. Jeśli to przykładowo z progu rozładowania 2,9V robi się 2,6V lub 3,2V.

Panowie drodzy!
Przepraszam za OT, ale:
Jezeli jest jeszcze miedzy wami ktos, kto umie programowac Attiny mikroprocesorki, to niech sie do mnie zlosi na PM. U nas w Czechach jest na forum ogromny glod po driwerkach, elektroniki sa, ale trzeba nam lepiej mody zprogramowac.
Pytalem Flagiusza, ale sie nie zglasza
Dzieki