www.swiatelka.pl
...czyli forum miłośników światełek... ;-)

nasze projekty, modyfikacje - Driver Flagiusza (programowalny) - nowa odsłona

df - 08-01-2010, 19:36
Temat postu: Driver Flagiusza (programowalny) - nowa odsłona
Witam,
po kilku miesiącach przerwy, chciałbym Wam przedstawić kolejny nowy projekt sterownika, który jest efektem zbieranych od ponad 3 lat doświadczeń oraz opracowywania i testowania najrozmaitszych rozwiązań.

Projekt ten nie jest ani demonstracją możliwości, ani rozwiązaniem iście kosmicznym, dalekim od realiów i potrzeb "normalnego" użytkownika - nie jest, bo z założenia taki miał nie być.

Wręcz przeciwnie jego celem było stworzenie rozwiązania wysoce dojrzałego, które połączyłoby wszystko to, co zostało wypracowane w poprzednich wersjach i co sprawdziło się w codziennym użytkowaniu.
Natomiast to, czego w poprzednich moich projektach brakowało, zostało tu uwzględnione i dodane.

Jako wielki pasjonat elektroniki i miłośnik latarek, jak zawsze zadbałem również o to, by rozwiązanie to było pod każdym względem wyjątkowe i bardzo dobrze przemyślane.

Oczywiście nadal moim priorytetem jest przede wszystkim: wysoka intuicyjność, ergonomia i funkcjonalność - w projekcie tym będzie to mam nadzieję bardzo dobrze widoczne. Wysoka dbałość o najdrobniejsze szczegóły ma zapewnić nie tylko komfort i pewność użytkowania, ale i sprawiać ich właścicielowi wiele radości.

W projekcie tym najwięcej ciekawych i innowacyjnych rozwiązań znajduje się w jego środku i choć przeciętny użytkownik nie będzie miał świadomości o tym, co tam w środku tak naprawdę się dzieje, to mimo wszystko zachęcam wszystkich zainteresowanych do dyskusji - chętnie podzielę się zdobytą wiedzą i doświadczeniem oraz opiszę rozwiązania techniczne zastosowane w tym projekcie (a jest ich tam całkiem sporo).

Podobnie jak wszystkie poprzednie moje projekty także i ten powstał całkowicie hobbystycznie, choć jego opracowanie i bardzo dokładne wytestowanie pochłonęło sporo mojego prywatnego czasu, którego niestety ostatnio mam jak na lekarstwo.

OK, to tyle tytułem wstępu - przejdźmy zatem do konkretów :-)


Parametry
    - zasilanie: 2,9 – 6,0V (1x Li-Ion / 1x Li-FePO / 3x NiCd / 3x NiMH / 3x alcaline 1,5V)
    - sterowanie LED`ami mocy od 1 do 4W (350mA/700mA/1A/1,4A) - możliwość sterowania kaskadowego kolejnymi modułami
    - wymiary PCB: średnica 16.8mm (17mm), wysokość 3.3mm (wersje do 1,4A)

Funkcje
    - sterownik wielotrybowy (ilość i liczba trybów predefiniowana, zależna od wybranego wariantu)
    - przełączanie trybów w sekwencji np. 1->2->3->1->2->3... itd.
    - pamięć ostatnio używanego trybu o działaniu natychmiastowym
    - możliwość blokady pamięci - konfigurowana sprzętowo (on/off)
    - możliwość programowania jasności przez użytkownika
    - indywidualne nastawy jasności dla każdego trybu niezależnie i dla wszystkich dostępnych trybów (zarówno ciągłych jak i sekwencyjnych)
    - szeroki zakres regulacji: od 0,4% do 100% (w tym super-low ok. 4mA w LED dla wersji 1A)
    - poziomy jasności rozłożone logarytmicznie (równomiernym dla oka)
    - cyfrowe sterowanie (Fast-PWM)
    - no-flickering / no-ringing – brak efektu migotania oraz piszczenia w pełnym zakresie pracy
    - możliwość sprzętowej blokady zmian ustawień (setup`u) z pełnum zachowaniem wszystkich dokonanych uprzednio konfiguracji
    - liniowa stabilizacja prądu diody na bazie układów AMC 7135
    - możliwość sterowania dodatkowymi modułami AMC (wersje >1,4A) w postaci kaskadowego łączenia dodatkowych modułów
    - automatyczna kontrola napięcia zasilania
    - sygnalizacja niskiego poziomu napięcia baterii (<3,2V)
    - moon-mode – tryb oszczędzania energii o obniżonej jasności (<3,05V)
    - zabezpieczenie ogniwa przed głębokim rozładowaniem (<2,9V) z sygnalizacją pełnego rozładowania
    - wsparcie dla rozwiązań rowerowych, czołówkowych i stacjonarnych
    - wyjście cyfrowe z możliwośią bezpośredniej sygnalizacji stanu pracy sterownika oraz poziomu baterii na dodatkowej diodzie LED małej mocy (np. wyprowadzonej w widocznym miejscu)
    - możliwość sterowania niskoprądowym micro-switch`em astabilnym (np. wyprowadzonym w dobrze dostępnym miejscu)

Sterowanie
    - zmiana trybu: 2-klik (2 krotne szybkie odcięcie zasilania lub przyciśnięcie micro-switch`a)
    - wejście do trybu konfiguracji jasności: 3-klik (3 krotne szybkie odcięcie zasilania lub przyciśnięcie micro-switch`a)
    - akceptacja wybranej jasności w trybie konfiguracji: 1-klik przy wybranej jasności
    - anulowanie zmian i wyjście z trybu konfiguracji: 1-klik w fazie sygnalizacji konfiguracji (pierwsze 2 sek. od wejścia do ustawień) oraz automatycznie po 6 pełnych cyklach zmian jasności bez dokonania wyboru
    - natychmiastowy powrót do trybu pierwszego (dot. konfiguracji z wyłączoną pamięcią trybów): 1-klik

Sygnalizacja
    - normalna praca
      - główny LED: tryby oraz jasność zgodnie z dokonanymi ustawieniami
      - wyjście cyfrowe: stan niski (opcjonalna dioda sygnalizacyjna zgaszona)

    - informacja o wejściu do opcji konfiguracji (setup)
      - główny LED: 2 podwójne błyski o średniej jasności
      - wyjście cyfrowe: przebieg 4Hz (opcjonalna dioda sygnalizacyjna szybko błyska)

    - sekwencja wyboru ustawień jasności (tryb konfiguracji - setup)
      - główny LED: cykliczne zmiany jasności od minimum do maksimum i z powrotem z pauzami oraz pojedynczym mignięciem przy wartościach skrajnych
      - wyjście cyfrowe: przebieg 4Hz (opcjonalna dioda sygnalizacyjna szybko błyska)

    - informacja o rozładowaniu ogniwa (<3,2V)
      - główny LED: krótkie pojedyncze "ciemne" mignięcia powtarzane w odstępach co ok. 8s
      - wyjście cyfrowe: przebieg 1Hz (opcjonalna dioda sygnalizacyjna wolno pulsuje)

    - informacja o zbliżającym się do końca rozładowaniu ogniwa (<3,05V)
      - główny LED - przejście w tryb o obniżonej jasności (moon-mode) oraz krótkie pojedyncze "ciemne" mignięcia powtarzane w odstępach co ok. 8s
      - wyjście cyfrowe - stan wysoki (opcjonalna dioda sygnalizacyjna świeci światłem ciągłym)

    - informacja o całkowitym rozładowaniu ogniwa (<2,9V)
      - główny LED - 4 półsekudnowe błyski o niskiej jasności i wyłączenie się sterownika
      - wyjście cyfrowe - 4 półsekudnowe błyski i przejście w stan niski

Opis
Zmiana trybu następuje "dwuklikiem" czyli 2-ma następującymi po sobie miękkimi kliknięciami (odłączającymi zasilanie sterownika), co jest rozwiązaniem bardzo wygodnym i zarazem praktycznym, gdyż dobrze zabezpiecza przed przypadkowym przełączeniem się trybów podczas użytkowania (np. jazda rowerem po wertepach).

Każdy z trybów zarówno ciągłych jak i specjalnych (sekwencje) może mieć dowolnie ustawioną przez użytkownika jasność. Dzięki temu możliwe jest nie tylko ustawienie swoich własnych preferowanych poziomów siły światła w poszczególnych trybach pracy, ale i ich kolejności (np. low->mid->high, high->mid->low, low->high->mid itd.), co czyni całe rozwiązanie niezwykle uniwersalnym.

Zmiana jasności (setup) możliwa jest po wykonaniu 3-kliku i dotyczy ona trybu aktualnie aktywnego.
Sterownik zasygnalizuje ten stan 2-ma podwójnymi błyskami, a następnie przejdzie do procedury wyboru jasności.
Pojedyncze kliknięcie lub wyłączenie latarki podczas sekwencji poprzedzającej wybór ustawień anuluje tryb konfiguracji, bez dokonywania żadnych zmian.
Właściwa sekwencja wyboru rozpoczyna się od poziomu najniższego i stopniowo (co ~0,5s) sterownik zwiększa jasność do wartości maksymalnej, a następnie przebiega w drugą stronę od wartości maksymalnej do minimalnej.
Poziomy skrajne (min i max) trwają nieco dłużej i są sygnalizowane jednym krótkim mignięciem, co doskonale ułatwia ich identyfikację oraz upraszcza wybór wartości skrajnych.

Dostępne jasności zawierają się w bardzo szerokim przedziale (od 0,4 do 100%) i zostały pogrupowane na 9 poziomów rozłożonych w skali logarytmicznej. Rozkład logarytmiczny jest bardziej naturalny niż podział liniowy (proporcjonalny), gdyż sprawia wrażenie, że każdy z kolejnych poziomów jest równo oddalony od poziomu go poprzedzającego. Natomiast ich podział na 9 poziomów daje wystarczająco dużą przestrzeń do wyboru własnej preferowanej siły światła, przy jednoczesnym zachowaniu wysokiej czytelności i powtarzalności wyboru (możliwe jest np. odliczanie kroków od wartości skrajnych).

Wybór siły światła polega na pojedynczym kliknięciu w chwili występowania danej jasności.
Po tym sterownik przechodzi do używanego wcześniej trybu, ale już z ustawioną nową wybraną przez użytkownika jasnością. Od tego momentu wybrana przez użytkownika jasność zostanie zapisana w pamięci sterownika i będzie przypisana do danego trybu, aż do czasu kolejnej jego zmiany (ponownej rekonfiguracji).
Gdy przez 3 pełne cykle nie zostanie dokonany żaden wybór, sterownik automatycznie wyjdzie z trybu konfiguracji przywracając ostatni wybrany tryb i zachowując pierwotną jego jasność.
Każdy z trybów posiada swoje niezależne nastawy jasności, a ich konfiguracja nie różni się niczym, poza wykonaniem operacji wejścia do ustawień (3-kliku) z pozycji innego wybranego przez siebie trybu.

Sterownik posiada możliwość zablokowania opcji konfiguracji, po uaktywnieniu której dalej będzie on respektował wszystkie dokonane uprzednio ustawienia, ale nie pozwoli na ich dalszą zmianę.
Blokada polega na założeniu zwory (lub zwarcie padów np. kroplą cyny) w miejscu PCB oznaczonym symbolem R3. Gdy pole jest otwarte (wartość domyślna) opcja konfiguracji jest dostępna.

Sterownik posiada pamięć ostatnio używanego trybu pracy, dzięki czemu po włączeniu zawsze uruchomi się on w trybie ostatnio używanym - czyli w tym, w którym został on wyłączony.
Także i tę opcję można wyłączyć zwierając pady oznaczone na PCB jako R5. Wówczas przy każdym uruchomieniu sterownik zawsze będzie startował z trybu pierwszego. W tej konfiguracji dostępna jest dodatkowa opcja natychmiastowego przejścia z dowolnego trybu do trybu pierwszego po pojedynczym krótkim kliknięciu (podwójny klik standardowo zmienia tryb na następny).

Stabilizacja prądu diody zrealizowana została w oparciu o specjalizowane układy AMC 7135 zapewniające prawidłowe warunki pracy diody LED zarówno w trybach ciągłych jak i impulsowych. Dzięki temu w bardzo szerokim zakresie napięć zasilania (przy zachowaniu wymaganego dla układów AMC warunku: VCC > VF + 0,15V) oraz w pełnym zakresie poziomów jasności zachowuje on stałą jasność oraz wysoką stabilność barwy światła.

Cyfrowa regulacja jasności zrealizowana w oparciu o szybką modulację szerokości impulsu (Fast-PWM) sprawia iż nawet w najniższych trybach nie widać migotania światła, a praca sterownika w pełnym zakresie jest całkowicie bezgłośna.

Sterownik posiada wbudowaną funkcję automatycznej kontroli stanu rozładowania akumulatora, którego parametry dobrane zostały dla ogniw typu Li-Ion, a które pasują również dla popularnego zasilania 3x NiCd/NiMH.

Elektroniczny układ na bieżąco monitoruje stan rozładowania ogniwa i gdy pozostała ilość energii spadnie poniżej ok. 5%, sterownik zacznie sygnalizować użytkownikowi kończącą się energię krótkimi ciemnymi błyskami powtarzanymi w odstępach co ok. 8 sekund.
Gdy pozostała ilość energii spadnie do wartości ~2,5% latarka automatycznie przełączy się w tryb oszczędny o obniżonej do ok. 4% wartości maksymalnej jasności, zachowując bieżący tryb pracy (np. ciągły, czy strobe itp.).
Jest to tzw. "moon-mode", czyli poziom awaryjny o obniżonej jasności, umożliwiający awaryjne działanie latarki jeszcze przez co najmniej 10-15 minut (wartość orientacyjna dla ogniw typu Li-Ion 18650 / 2500mAh).

Gdy napięcie akumulatora osiągnie minimalną, bezpieczną dla niego wartość (2,9V), sterownik zasygnalizuje użytkownikowi pełne rozładowanie 4-ma półsekundowymi mignięciami poczym wyłączy się. Mechanizm ten zabezpiecza akumulator przed szczególnie niebezpiecznym dla ogniw Li-Ion głębokim rozładowaniem, co istotnie wpływa na jego bezpieczeństwo, pojemność oraz długie i bezawaryjne użytkowanie. Sterownik ten może być zatem bezpiecznie stosowany z ogniwami bez wbudowanych zabezpieczeń (unprotected).

Sterownik ten udostępnia także sygnał cyfrowy informujący o parametrach jego pracy, który to może być bardzo prosto wykorzystany do dodatkowej sygnalizacji np. na "czerwonej" diodzie LED (małej mocy) bieżącego stanu zasilania oraz opcji specjalnych (trybu konfiguracji). Funkcja ta jest jedynie dodatkiem pomocnym w niektórych zastosowaniach i jej użycie nie jest niezbędne do prawidłowego działania sterownika.

Możliwe jest również sterowanie zmianami trybów oraz opcjami konfiguracji przy pomocy chwilowego przycisku astabilnego np. tzw. micro-switch`a.

Obie ostatnie funkcje powstały przede wszystkim z myślą o zastosowaniu w latarkach rowerowych, czołówkach jak i rozwiązaniach stacjonarnych, gdzie dodatkowa opcjonalna "czerwona" dioda sygnalizacyjna może być wyprowadzona w dowolnym dobrze widocznym dla użytkownika miejscu, a możliwość bardzo wygodnej zmiany trybów przy pomocy miniaturowego niskoprądowego przycisku zwiększy pewność i wygodę użytkowania.

Ufff... to tak mniej więcej chyba tyle.

lennin - 08-01-2010, 19:48

Musze powiedzieć że testuje właśnie ten sterownik. Wersja trzytrybowa bez wodotrysków. Co do samego zabezpieczenia aku przed nadmiernym rozładowaniem sprawa ma sie troche inaczej niz darek opisuje. Zapomina że przy wysokim poborze prądu napięcie akumulatora dość szybko sięga dna i przechodzi nam sterownik w tryb moon. W tym momencie pobór prądu jest tak mały ze po dwóch godzinach ciągle mamy światło. Ile to potrwa jeszcze nie wiem. Świeci i świeci i pewnie długo jeszcze zanim driverek odetnie zasilanie :) Gratuluje projektu. Jako ciekawostkę muszę dodać iż nie widać tak drażliwego dla poniektórych efektu migotania PWM. To ja idę bawić sie dalej :twisted:
df - 08-01-2010, 20:10

Pomiar napięcia akku jest jedynym wyznacznikiem jego stanu rozładowania.
Sterownik nie wie, czy niskie jego napięcie było spowodowane tym, że ktoś "zajeżdżał" akkusa wielkim prądem i po przekroczeniu dolnej granicy napięcia, przy którym następuje przejście w moon-mode pozwoli złapać mu nieco oddechu, czy też akumulator "ciurkał" sobie na niskim trybie i się "wyciurkał" do napięcia, które przełączyło go w moon-mode.

Z wykonanych pomiarów na realnym 18650 brałem pod uwagę najbardziej niekorzystny przypadek - właśnie takiego rozładowywania spokojnego, sytematycznego i do końca.
I przy przejściu do moon-mode sterownik pracował jeszcze przez ok. 18 minut po czym napięcie spadło do 2,9V i sterownik się zgodnie z oczekiwaniem wyłączył.

Testowałem różne algorytmy pomiaru napięcia i reakcji sterownika:
1. z powrotami
2. z zatrzaskiwaniem

Opcja 1 - z powrotami polegała na tym, że sterownik reagował na przekroczenia ustalonych progów napięć w obie strony (z nieznaczną histerezą). I wówczas przy silnym obciążeniu pojawiał się taki efekt, w którym przełączał się on w moon-mode i po chwili wracał do np. max`a i tak w kółko - było to trochę denerwujące, dlatego zrobiłem inaczej

Opcja 2 - z zatrzaskiwaniem polega na tym, że jeżeli sterownik osiągnie w danej chwili wartość najniższą napięcia, to sterownik wykona daną czynność (np. przejdzie w moon-mode), ale nie będzie wracał do stanu poprzedniego nawet jak napięcie po chwili pracy nieznacznie wzrośnie (przekraczając w górę dany próg). Świadomie podjąłem taką decyzję, aby uniknąć efektu opisanego w pkt.1 oraz nie robić za dużej pętli histerezy (bawiłem się ma dV=0,1V i co kilka sekund się przełączało).
Wyszedłem też z innego założenia, że bateria podczas pracy nie będzie raczej ładowana, a więc skoro jej napięcie spadło do danego poziomu, to znaczy, że ogniwo jest wystarczająco mocno rozładowane.

Natomiast w tym stanie (wymuszony moon-mode) dowolne kliknięcie np. pojedyncze kasuje chwilowe wskazania napięcia baterii i przywraca stan pierwotny trybu - a więc możesz samemu sobie "kliknąć" i wymusić na pewien czas ponownie dowolny tryb lub np. przełączyć się z max`a na coś pośredniego, co zaoszczędzi energii, a zarazem będzie czymś mocniejszym niż moon-mode.

Dodam, że po każdym kliknięciu zmiany stanu spowodowane pomiarem napięcia są blokowane na ok. 8 sekund - dzięki czemu przez te kilka sekund, nawet przy bardzo niskim napięciu można spokojnie zmienić tryb na bardziej oszczędny i dalej z latarki korzystać.

I tak też zrobiłem, gdyż uznałem, że tak właśnie będzie najlepiej.

lennin - 08-01-2010, 20:28

Widać mam mocno sfatygowane ogniwa. Poubijam inne zobaczymy jak to będzie :mrgreen:
df - 08-01-2010, 20:34

Oczywiście jest jeszcze trzecie rozwiązanie - sterowanie adaptatywne, w którym sterownik płynnie zdejmuje obciążenie z akkusa zmniejszając prąd, aż do osiągnięcia stabilności napięcia co najmniej na ustalonym granicznym poziomie.

Jednakże takie podejście powodowałoby rozłożone w czasie stopniowe przygasanie diody bez widocznego efektu zbliżającego się końca.

Moim założeniem było dociągnąć ile się da w trybie jaki chciał użytkownik i już na samych oparach przejść awaryjnie w moon-mode gdzie przez kilkanaście minut poświeci i przy minimalnej wartości napięcia zabezpieczyć ogniwo wyłączając cały sterownik: LED`a, AMC`ki oraz sam procesor. Nie ma nic gorszego, niż nagła i nieoczekiwana utrata światła, którą np. wymusi działające 0/1-kowo zabezpieczenie na akku protected.

Z myślą o CR123, ale i o tych którzy po prostu tak by chcieli niebawem będzie opcja konfiguracji pomiaru napięcia, którą będzie można sobie wedle uznania włączyć lub wyłączyć.

Volt - 08-01-2010, 20:49

Gratuluję, bardzo fajny, prosty sterownik. Ostatnio sam wziąłem się za wykonie sterownika na AMC7135, i czytając ten jakże rozległ... znaczy się dokładny :razz: opis, zauważyłem że korzystam z podobnych rozwiązań (min. 4mA, 9 stopni jasności) które w sumie są związane z wykorzystaniem tego akurat procka.

df napisał/a:
chętnie podzielę się zdobytą wiedzą i doświadczeniem oraz opiszę rozwiązania techniczne zastosowane w tym projekcie


No to ja pierwszy: nie widzę na płytce kondensatora podtrzymującego napięcie procka... no chyba że to ten mały jest - jak wobec tego jest zrealizowana tu zmiana trybu? Program podejrzewam że pisany w assemblerze?

Pozdrawiam :wink:
Volt

Darek - 08-01-2010, 21:12

Witam.
Świetny sterowniczek.Szczególnie podoba mi się sygnalizacja stanu aku na dodatkowej diodzie.I teraz zasadnicze pytanie kiedy bedzie dostepny i czy bedzie?.
Pozdrawiam.

df - 08-01-2010, 21:19

Volt napisał/a:
Gratuluję, bardzo fajny, prosty sterownik.

Dzięki :-)

Volt napisał/a:
(min. 4mA, 9 stopni jasności) które w sumie są związane z wykorzystaniem tego akurat procka.

To nawet nie tyle zależy od samego procka, tylko od 8-mio bitowego timera, na którym sprzętowo realizowany jest PWM. A że w swych rozwiązaniach preferuję logarytmiczną skalę nastaw jasności tak jest po prostu najłatwiej. A rozwiązanie to stosowałem już w 2007 roku, więc też nowością to wielką nie jest ;-)
W części wersji df&cali było więcej poziomów, bo 13-cie i dużo niższy low schodzący do 1:4000 pełnej jasności. Tutaj uznałem, że 0,4% jest wystarczające i nie ma co sztucznie wchodzić w zakresy, z których i tak nikt nie będzie korzystał. To rozwiązanie z założenia miało być praktyczne i użyteczne, a nie stanowić mało praktyczny pokaz możliwości.

Volt napisał/a:
No to ja pierwszy: nie widzę na płytce kondensatora podtrzymującego napięcie procka... no chyba że to ten mały jest - jak wobec tego jest zrealizowana tu zmiana trybu?

Bo tutaj sterowanie zrobione jest w zupełnie inny sposób niż w rozwiązaniach poprzednich.
Po pierwsze procesor bardzo mocno oszczędza prąd - wiele rzeczy robi sprzętowo, większość czasu "śpi" na idle`ach.
Po drugie, zaimplementowana tu logika oraz przechowywanie stanów pośrednich w pamięci pozwala na realizację tych wszystkich funkcji bez konieczności ciągłego utrzymywania procesora przy życiu na dużych pojemnościach podtrzymujących. Dzięki temu nie ma potrzeby wsadzania dużego kondensatora, zwłaszcza, że nie ma tam za wiele miejsca (cały sterownik razem z PCB ma wysokość niespełna 3,3mm).

Działa to tak:
1. procesor startuje (sprawdza kilka różnych rzeczy np. napięcie Vbatt przy starcie itp.) ustawia w pamięci znacznik stanu oznaczający "właśnie się podniosłem"
2. po założonym czasie np. 1/100 s pracy zmienia ten znacznik, co dla jego logiki będzie stanowiło informację "po podniesieniu pracowałem na tyle długo, że nie było klika"

I teraz jeżeli MCU się budzi i widzi stan "1" to wie, że był klik, jak "2" to że nie było klika.
Wielokliki realizuję tak samo, ale dodatkowo zliczam kolejne przejścia typu "1-go".
Proste i zarazem pomysłowe - prawda?

Robię to oczywiście bardzo, bardzo optymalnie, by minimalizować do niezbędnego minimum zapisy do pamięci (częstość, ich liczbę oraz ilość zmienianych danych) jak również stosuję dość zaawansowany algorytm rozpraszania zapisów w całej przestrzeni pamięci by optymalnie zużywać jej cykle zapisów.

Volt napisał/a:
Program podejrzewam że pisany w assemblerze?

Tak - tak jak i wszystkie moje poprzednie, a dlaczego to w szczegółach wyjaśniałem w poprzednich projektach

P.S. Ponieważ zdradzam wszelkie tajniki, które z prawnego punktu widzenia stanowią moją własność intelektualną oraz do których dojścia poświęciłem naprawdę sporo czasu, wiedzy oraz których wypracowanie pochłonęło wymierne koszty, nie wyrażam zgody na ich odpłatne/komercyjne wykorzystywanie, dopuszczając je wyłącznie do zastosowań czysto amatorskich oraz zgodnych z zasadami GPL jednakże pod warunkiem każdorazowego podawania informacji o ich autorze oraz źródle.

df - 08-01-2010, 21:33

Darek napisał/a:
Świetny sterowniczek.Szczególnie podoba mi się sygnalizacja stanu aku na dodatkowej diodzie.

Dzięki :-)

Darek napisał/a:
I teraz zasadnicze pytanie kiedy bedzie dostepny i czy bedzie?.

Aktualnie mam kilka pojedynczych sztuk (1A), które mogę odstąpić - szczegóły na PW.

lennin - 08-01-2010, 21:45

Z tego co rozumiem procesor ma ograniczoną mozliwość włacz wyłacz czy tylko zmiany trybów? Jak jest przybliżona w kliknieciach(?) żywotność?
Pyra - 08-01-2010, 21:55

Witam
Jak zwykle "dałeś czadu".

Tak się akurat składa, że również mam na tapecie od jakiegoś czasu ten driverek, jednak chciałbym podzielić sterowany prąd na dwie wartości, o czym już pisałem.
Będzie to tak: przecinam ścieżkę sterującą AMCkami pomiędzy 5 i 6 nóżką Atmelka, następnie robię mostek pomiędzy nóżką 5 (PWM A) a odciętymi 2 szt AMC. Wtedy R5 pozostanie niestety zajęty przez sygnał PWMA
Mój projekt na razie zatrzymał się na rozwiązaniu detekcji klików, chcę to rozwiązać sprawdzaniem tempa spadku napięcia na zasilaniu procka. W związku z tym, że driverek posiada możliwość pomiaru napięcia zasilania (obniżonego o spadek na diodzie), chciałem je wykorzystać:
Primo - do kontroli stanu rozładowania akumulatora
Secundo - do detekcji klików poprzez wykrywanie odpowiednio szybkiego spadku napięcia. Niestety z braku czasu nie mogę na razie prowadzić doświadczeń, jedyną moją obawą, jest to, że podczas przejścia z Lo do Hi, układ może to wykryć jako klik :-|
Na razie odrzuciłem pierwotny pomysł, z wykryciem spadku napięcia poniżej pewnego progu, bo było by wtedy trudno zrealizować pomiar napięcia i zabezpieczenie przez nadmiernym rozładowaniem AKU.
Mój projekt przewiduje obniżenie trybu po wykryciu spadku napięcia poniżej zaprogramowanego progu, i tak oż do moon mode, który był by ustalony na stałe mimo braku takowego w skonfigurowanych jasnościach, bo chcę zrobić konfigurowaną przez użytkownika jasność trybów. Nad sygnalizacją wymuszonego obniżenia trybu jeszcze się nie zastanawiałem, choć jest ona w planach.
df napisał/a:
Działa to tak:
1. procesor startuje (sprawdza kilka różnych rzeczy np. napięcie Vbatt przy starcie itp.) ustawia w pamięci znacznik stanu oznaczający "właśnie się podniosłem"
2. po założonym czasie np. 1/100 s pracy zmienia ten znacznik, co dla jego logiki będzie stanowiło informację "po podniesieniu pracowałem na tyle długo, że nie było klika"

Pamiętam tą dyskusję z EdiM, też chciałem to zastosować, ale ochrona pamięci przekracza moje możliwości umysłowe :oops:


Pozdrawiam

df - 08-01-2010, 22:25

lennin napisał/a:
Z tego co rozumiem procesor ma ograniczoną mozliwość włacz wyłacz czy tylko zmiany trybów? Jak jest przybliżona w kliknieciach(?) żywotność?

Pewnie jak wszystko w życiu ma ograniczoną żywotność.

W tym rozwiązaniu przy kliknięciu lub wyłączeniu jest robiony zapis, a w pewnych sytuacjach max. 2 zapisy podczas normalnej pracy (od włączenia do wyłączenia). Cykle zapisu są jednak rozpraszane w całej pamięci, a zapisywane dane są silnie agregowane, przez co zmieniana jest nie tylko minimalna liczba bajtów, ale i bitów w ich obrębie (zerowanie bitów stanowi problem i tu także są stosowne specjalne zabiegi).

Deklarowana przez producenta (Atmel) żywotność pamięci w tych układach to min. 100.000 cykli kasowania/zapisu. W przyjętym rozwiązaniu rozpraszanie danych jest na całą 64 bajtową pamięć (przestrzeń 512 bitów).

A zatem przy najbardziej skrajnym przypadku, zakładającym, że każda komórka pamięci wytrzyma dokładnie tylko tyle ile deklaruje producent (100.000 cykli) i ani jednego więcej, to liczba pełnych włączeń i wyłączeń sterownika nie powodujących żadnych perturbacji wyniesie grubo ponad 3,2 miliona razy (ok. 6,4 miliona cykli).

Zakładając, że jesteś prawdziwym "kosmitą" i włączasz oraz wyłączasz latarkę raz na 5 minut przez 24 godziny na dobę, 7 dni w tygodniu, przez 365 dni w roku, to przy i tak mocno wyśrubowanych założeniach dojdziesz do gwarantowanej żywotności pamięci po... uwaga: ponad 30 latach! (3.200.000/288/365)

Celowo w wyliczeniach przyjąłem najbardziej niekorzystne wartości, aby pokazać Wam, że przy odpowiednim podejściu nie ma tu najmniejszego zagrożenia.

Jeżeli więc tyle klikasz i przeszkadza Ci to że po 30 latach w pamięci sterownika może pojawić się problem, to rzeczywiście zalecam rozwiązanie z dodatkową dużą pojemnością podtrzymującą - czyli takie jakie stosowałem we wcześniejszych projektach.

Dodam, że oprócz rozpraszania oprogramowanie weryfikuje wszystkie zapisy i gdy pojawi się problem pomija uszkodzoną komórkę pamięci i przeprowadza zapis na kolejnej sprawnej. Zaimplementowany przeze mnie mechanizm mapowania uszkodzonych komórek w dużym przybliżeniu przypomina nieco mechanizm mapowania bad-sectorów w dyskach twardych.

A zatem w rzeczywistości, zwłaszcza że stosuje zapisy bardzo bliskie (0xFF) - czyli minimalizuję liczbę zerowanych bitów, które pamięć zużywają, przy założeniu, że w takich warunkach nie każda komórka wytrzyma tylko i dokładnie tyle ile podaje producent, ale znacznie więcej oraz że jestem w stanie pomijać komórki faktycznie uszkodzone, ten czas jeszcze bardziej się zwiększa co najmniej kilkukrotnie w stosunku do obliczonej super skrajnej wartości.

Schodząc na ziemię - przy założeniu, że przeciętny użytkownik każdego dnia roku w ciągu każdej doby 10x włącza i wyłącza oraz 10x zmienia tryby, to przy założeniu minimalnej deklarowanej żywotności pamięci moje rozwiązanie będzie działać co najmniej: (6.400.000 / ( 2*(365*10) + 1*(365*10))) = 584,5 lat!

Mało?

Dodam, że Chińczycy nie robią żadnych z zabiegów, których arkana w szczegółach Wam opisuję, a zatem ich rozwiązanie jest co najmniej kilkaset razy bardziej narażone na taki przypadek.

Przekonałem?

Gardol - 08-01-2010, 22:47

Jestem laikiem elektronicznym ale funkcjonalności wygląda SUUUPER! Gratulacje!
Szczerze mówiąc myślałem o czymś podobnym jako driver i sterowanie do Ledlenser P7 (jest osobny temat) ale mam pytanie o zakres - piszesz do 6V, czyli jak to będzie wyglądało przy 4xAAA (bateria alkaliczna) no i 4xaku NiMH (niby coś koło 4.8V)?

Pozdrawiam, Paweł

df - 08-01-2010, 22:48

Pyra napisał/a:
Jak zwykle "dałeś czadu".

Dzięki ;-)

Pyra napisał/a:
W związku z tym, że driverek posiada możliwość pomiaru napięcia zasilania (obniżonego o spadek na diodzie), chciałem je wykorzystać: [...] do detekcji klików poprzez wykrywanie odpowiednio szybkiego spadku napięcia.

Testowałem to - możesz sobie od razu odpuścić.
Przy stosowanej wielkości <1uF nie zdążysz wykryć zaniku by bezpiecznie zrobić zapis do EE, a przy trybach sekwencyjnych (migaczach) będziesz miał fałszywe odczyty i nie zapanujesz nad tym - a przynajmniej mi się to nie udało.
Drugim rozwiązaniem które testowałem (i które także odrzuciłem) było połączenie pinu 5-go z bardzo blisko znajdującą się przelotką od +Vcc i badanie "wprost" stanu logicznego na zasilaniu. Przy tak małej pojemności jest za mało czasu na reakcję i trzeba zwiększać pojemność podtrzymującą - czyli stosować dobrze znane Ci rozwiązanie, na którym opierałem się w poprzednich projektach.

Pyra napisał/a:
jedyną moją obawą, jest to, że podczas przejścia z Lo do Hi, układ może to wykryć jako klik :-|

Dokładnie tak.

Pyra napisał/a:
Mój projekt przewiduje obniżenie trybu po wykryciu spadku napięcia poniżej zaprogramowanego progu, i tak oż do moon mode, który był by ustalony na stałe mimo braku takowego w skonfigurowanych jasnościach, bo chcę zrobić konfigurowaną przez użytkownika jasność trybów. Nad sygnalizacją wymuszonego obniżenia trybu jeszcze się nie zastanawiałem, choć jest ona w planach.

OK, z zainteresowaniem będę śledził Twoje próby.

Pyra napisał/a:
Pamiętam tą dyskusję z EdiM, też chciałem to zastosować, ale ochrona pamięci przekracza moje możliwości umysłowe :oops:

Zgadza się pomysł tego rozwiązania nie jest nowością - na jego temat wielokrotnie dyskutowałem również w ramach tego forum i także z EdiMem, dlatego też pochyliłem się nad tematem i zadbałem o to by wszystko było zaprojektowane w sposób bezpieczny, architektonicznie najbardziej poprawny i nie robię z zastosowanych przeze mnie rozwiązań żadnych tajemnic, gdyż dobrze wiem, że nie ma w nich żadnych "kruczków" - i nie mam tu nic do ukrycia.

To jest tak samo jak z kryptografią - nie jest sztuką zrobić black-box`a i przekonywać na słowo, że jest on odporny na ataki oraz zmuszać łamaczy nie do odnajdywania algorytmicznie słabych punktów nieznanego (utajonego) rozwiązania oraz jego reverse-engeeneringu.
Prawdziwą sztuką jest pokazać rozwiązanie/algorytm w szczegółach, który sam się obroni użytą w nich myślą i nietuzinkowym rozwiązaniem - co w odniesieniu do analogi z dobrą kryptografią nie sprowadza się do "zaufania na słowo", lecz jest jawnym dowodem np. matematycznie uzasadniającym siłę danego rozwiązana na kryptoanalizę.

df - 08-01-2010, 22:59

Gardol napisał/a:
funkcjonalności wygląda SUUUPER! Gratulacje!

Dziękuję :-)

Gardol napisał/a:
mam pytanie o zakres - piszesz do 6V, czyli jak to będzie wyglądało przy 4xAAA (bateria alkaliczna) no i 4xaku NiMH (niby coś koło 4.8V)?


4xAAA (bateria alkaliczna) to 4x1,5V = 6V, a zatem jest OK.
4xaku NiMH to 4x1,2V w porywach do 4x1,5V (tuż po skrajnym naładowaniu) = 4,8-6V, a zatem także jest OK.

Pyra - 08-01-2010, 22:59

Gardol napisał/a:
Jestem laikiem elektronicznym ale funkcjonalności wygląda SUUUPER! Gratulacje!
Szczerze mówiąc myślałem o czymś podobnym jako driver i sterowanie do Ledlenser P7 (jest osobny temat) ale mam pytanie o zakres - piszesz do 6V, czyli jak to będzie wyglądało przy 4xAAA (bateria alkaliczna) no i 4xaku NiMH (niby coś koło 4.8V)?

Pozdrawiam, Paweł


To 6V wynika z dwu powodów, deklarowane przez producenta max napięcie zasilania ATTiny13 wynosi 5,5V. W związku z tym, że ATtiny jest zasilany poprzez diodę krzemową tak więc 5,5 +0,6 daje 6,1V, ale musimy mieć jakiś zapas. Ponadto ważna jest też moc strat na elementach regulacyjnych czyli AMC, Dla prądu znamionowego 350mA, dopuszczalne napięcie na AMC to około 2V.....

Pozdrawiam

lennin - 08-01-2010, 23:04

df napisał/a:
Zakładając, że jesteś prawdziwym "kosmitą" i włączasz oraz wyłączasz latarkę raz na 5 minut przez 24 godziny na dobę, 7 dni w tygodniu, przez 365 dni w roku, to przy i tak mocno wyśrubowanych założeniach dojdziesz do gwarantowanej żywotności pamięci po... uwaga: ponad 30 latach! (3.200.000/288/365)


To sprawdzimy czy jestem kosmitą za 30 lat napisze czy wytrzyma :twisted:

df - 08-01-2010, 23:12

lennin napisał/a:
To sprawdzimy czy jestem kosmitą za 30 lat napisze czy wytrzyma :twisted:

Trzymam Cię za słowo :-)

Gardol - 08-01-2010, 23:16

co do tych 6V to wolę wyjaśnienie Flagiusza niż Pyry... nie będę wyjaśniał swoich zdolności po raz kolejny :)
Można się odezwać na PM w sprawach konkretnych jeśli chodzi o zastosowania do LL P7 jak już cała reszta składników będzie na miejscu?

Pyra - 08-01-2010, 23:20

df napisał/a:

Drugim rozwiązaniem które testowałem (i które także odrzuciłem) było połączenie pinu 5-go z bardzo blisko znajdującą się przelotką od +Vcc i badanie "wprost" stanu logicznego na zasilaniu. Przy tak małej pojemności jest za mało czasu na reakcję i trzeba zwiększać pojemność podtrzymującą - czyli stosować dobrze znane Ci rozwiązanie, na którym opierałem się w poprzednich projektach.

Biorę to pod uwagę. Kondziołka większego chyba zmieszczę w miejscu opisu D1/R5, wtedy na Pin 2 lub 3 podał bym VCC z baterii, ale chyba by tu trzeba przez jakiś rezystorek, bo
Uwe pin > VDD proc, trochę mnie to niepokoi :roll:
Pin 5 ma już u mnie swoją rolę do odegrania ;)

df napisał/a:
OK, z zainteresowaniem będę śledził Twoje próby.

Mam nadzieję, że będzie tam coś interesującego. Podwaliny pod to rozwiązanie położyłem w projekcie, w którym 1 klik - tryb w górę, 2 kliki - tryb w dół.
Zastanawiałem się też czy obniżenie trybu w rozumieniu numeru to dobry pomysł, w wypadku programowalnych trybów, bo może sobie ktoś ustawić np.: Low, Hi, Mid. Niekorzystną sytuacją by było gdyby driverek próbował przeskoczyć w dół z Mid, ustawił by Hi i szybko przeskoczył znów niżej czyli w Low. Ale w sytuacji ustawień Hi, Mid, Lo, już nie będzie tak wesoło..... Rozważam aktualnie możliwość programowego obniżania wartości PWM, bez faktycznej zmiany trybu....


df napisał/a:
Zgadza się pomysł tego rozwiązania nie jest nowością - na jego temat wielokrotnie dyskutowałem również w ramach tego forum i także z EdiMem, dlatego też pochyliłem się nad tematem i zadbałem o to by wszystko było zaprojektowane w sposób bezpieczny, architektonicznie najbardziej poprawny i nie robię z zastosowanych przeze mnie rozwiązań żadnych tajemnic, gdyż dobrze wiem, że nie ma w nich żadnych "kruczków" - i nie mam tu nic do ukrycia.

To jest tak samo jak z kryptografią - nie jest sztuką zrobić black-box`a i przekonywać na słowo, że jest on odporny na ataki oraz zmuszać łamaczy nie do odnajdywania algorytmicznie słabych punktów nieznanego (utajonego) rozwiązania oraz jego reverse-engeeneringu.
Prawdziwą sztuką jest pokazać rozwiązanie/algorytm w szczegółach, który sam się obroni użytą w nich myślą i nietuzinkowym rozwiązaniem - co w odniesieniu do analogi z dobrą kryptografią nie sprowadza się do "zaufania na słowo", lecz jest jawnym dowodem np. matematycznie uzasadniającym siłę danego rozwiązana na kryptoanalizę.


O to to to!

Pozdrawiam

df - 08-01-2010, 23:32

Gardol napisał/a:
co do tych 6V to wolę wyjaśnienie Flagiusza niż Pyry... nie będę wyjaśniał swoich zdolności po raz kolejny :)

Jest dokładnie tak jak napisał to Kolega Pyra.

Natomiast minimalne napięcie sterownika jest uwarunkowane następującymi czynnikami:
- procesor (ATtiny13v) - aby pracował musi mieć zasilanie co najmniej 1,8V, a ponieważ w szeregu z jego zasilaniem jest krzemowa dioda, trzeba dodać +0,7V co daje minimum na poziomie 2,5V
- napięciem Vf diody LED, którą sterownik będzie zasilał powiększonym o +0,15V spadku napięcia na stabilizatorach prądu diody (AMC) w zakresie pełnej stabilizacji
- oraz oczywiście ustawioną w sofcie minimalną wartością napięcia pracy, przy której włącza się zabezpieczenie akumulatora - 2,9V, ale pewnie je obniżę do 2,8V

Gardol napisał/a:
Można się odezwać na PM [...]

Jeżeli ktokolwiek ma do mnie pytania nie związane bezpośrednio z tematem dyskusji dot. tego projektu (lub wstydzi się o coś zapytać publicznie na łamach forum) to jak najbardziej zapraszam na PW ( flagiusz@op.pl )

df - 08-01-2010, 23:42

Pyra napisał/a:
Kondziołka większego chyba zmieszczę w miejscu opisu D1/R5

Tak, da się - to dobre miejsce bo na pin.4 masz GND.

Pyra napisał/a:
wtedy na Pin 2 lub 3 podał bym VCC z baterii, ale chyba by tu trzeba przez jakiś rezystorek, bo Uwe pin > VDD proc, trochę mnie to niepokoi :roll:

A czemu nie na pin.5?

Jest zdecydowanie bliżej i albo zworkę, albo kilka-kilkanaście kiloomów idealnie tam wejdzie.
Każdy port (poza resetem) jest zablokowany do masy i Vcc zwrotnie diodami (ESD).
jak podłączysz zasilanie do dowolnego portu (poza res.) to procek wstanie i zacznie pracować, bo prąd zamknie się przez port, diodę zabezpieczającą do Vcc.
Przy założeniu, że nie będziesz go zasilał w takiej konfiguracji z napięcia >5,5V to nie masz się czego obawiać.

Pyra napisał/a:
Pin 5 ma już u mnie swoją rolę do odegrania ;)

No tak, oj kuszą Cię widzę te dwa kanały PWM, oj kuszą ;-)

Calineczka - 09-01-2010, 00:05

Darku, gratuluję ;-)
Od niedawna dwuklikam sobie tym twoim pomysłem i całkiem mi to do gustu przypadło.
Koledzy dopytują o wersję komercyjną, kiedy pojawi się w sklepiku?
Pisałeś o możliwości sterowania switchem-gdzie go podłączyć? Na schemacie nie jest zaznaczony. Może w przypadku jego zastosowania można by zmienić sposób sterowania?

Bulba - 09-01-2010, 22:21

Zajefajna konstrukcja, nareszcie driver bez pieciuset trybow, siedmiuset grup etc....
No i zabezpieczenie dla tych ktorzy uzywaja lijonow nonprotect :)
Jezeli cena bedzie przystepna, to widze tutaj malego Hita :)
Gratulacje!

czarny_kruk - 10-01-2010, 00:07

Gratulacje df. Pokazales co mozna wyciagnac z tego sterowniczka dzieki swietnemu softowi. W zasadzie nie ma sie czego doczepic. Zasugerowalbym jedynie zmiane w ostrzeganiu o rozladowanym accu. Z praktyki moim zdaniem lepsze jest konkretna ilosc (np. 5-8) migniec co 8sek po przekroczeniu progu niz mruganie niepotrzebnie przez kilkanascie minut. Alternatywne rozwiazanie to aby klikniecie po wlaczeniu sie ostrzegania powodowalo zaprzestanie dalszego migania co 8sek, zejscie do moon-mode pozostaje aktywne.

Co do watpliwosci Calineczki to microswitcha mozna podlaczyc do dowolnego wolnego portu i masy, zatem najlatwiej bedzie skorzystac z ktorejs pociagnietej sciezki. Po zmianie softu zamiast ktorejs blokady (trybow albo poziomow) bedzie mozna podlaczyc softswitcha. Tak przypuszczam.

df - 10-01-2010, 13:22

Bulba napisał/a:
Zajefajna konstrukcja, nareszcie driver bez pieciuset trybow, siedmiuset grup etc.... No i zabezpieczenie dla tych ktorzy uzywaja lijonow nonprotect :)
[...]
Gratulacje!

Dziękuję

czarny_kruk napisał/a:
Gratulacje df. Pokazales co mozna wyciagnac z tego sterowniczka dzieki swietnemu softowi.

Dziękuję, choć nie powiedziałem jeszcze ostatniego słowa :-)
Ale o tym za chwilę...

czarny_kruk napisał/a:
Zasugerowalbym jedynie zmiane w ostrzeganiu o rozladowanym accu. Z praktyki moim zdaniem lepsze jest konkretna ilosc (np. 5-8) migniec co 8sek po przekroczeniu progu niz mruganie niepotrzebnie przez kilkanascie minut.

Jeżeli ostrzeganie o niskim stanie miałoby się samo po kilku razach wyłączyć, to jaki miałoby ono sens? Celem tego jest właśnie informowanie użytkownika, że kończy się energia i jest on dopóty informowany, dopóki napięcie na akumulatorze jest poniżej ustalonej wartości.
Założę się, że wielu użytkowników po kilku ostrzeżeniach nie będzie już tego pamiętać i nagle zostanie zaskoczonych ciemnością (zabezpieczenie przed głębokim rozładowaniem).

czarny_kruk napisał/a:
Alternatywne rozwiazanie to aby klikniecie po wlaczeniu sie ostrzegania powodowalo zaprzestanie dalszego migania co 8sek, zejscie do moon-mode pozostaje aktywne.

Użytkownik w każdej chwili ma możliwość zmiany trybu na inny (jak i zmiany jasności w trybie), więc może świadomie zmienić tryb na mniej prądożerny.
Jeżeli tego nie zrobi, a napięcie zbliży się do granicy odcięcia, to sterownik ten sam podejmie za niego decyzję i przełączy jasność w moon-mode zachowując dany tryb pracy.
Jedno kliknięcie wycofa moon-mode przywracając ustawioną jasność w tym trybie itd.

czarny_kruk napisał/a:
Co do watpliwosci Calineczki to microswitcha mozna podlaczyc do dowolnego wolnego portu i masy, zatem najlatwiej bedzie skorzystac z ktorejs pociagnietej sciezki. Po zmianie softu zamiast ktorejs blokady (trybow albo poziomow) bedzie mozna podlaczyc softswitcha. Tak przypuszczam.

Mikroswitch włączyć można między pin 1 MCU, a masę - sterowanie takie samo jak odcięciem zasilania.

OK, pracuję nad rozszerzoną wersją 2.1, która zachowa wszystkie funkcje co opisana 2.0, a dodatkowo będzie miała tryb konfiguracji sterownika (nie mylić z ustawieniami jasności) z możliwością sprzętowej blokady. Tryb ten będzie osiągalny po 5-ciu szybkich kliknięciach i będzie się składał z 4 kolejnych opcji wyboru: TAK / NIE.

W ten sposób możliwe będzie softwarowe ustawianie następujących parametrów:
1. dostępność trybu strobe-rowerowy (tak=będzie/nie=nie będzie)
2. opcja pomiaru i kontroli stanu napięcia baterii (tak=włączona/nie=wyłączona)
3. pamięć ostatniego trybu (tak=włączona/nie=wyłączona)
4. opcja konfiguracji jasności dostępna po 3-kliku (tak=włączona/nie=wyłączona)

Każda z opcji wyboru przebiega w następujący sposób:
- przez 2 pierwsze sek. sterownik oczekuje ze zgaszoną diodę - kliknięcie w tym czasie anuluje zmianę danego parametru i powoduje przejście do kolejnego z zachowaniem jego aktualnej wartości
- następnie sterownik zapali diodę z jasnością średnią (tak) i co 2 sekundy będzie zmieniał jej jasność na niską (nie) i spowrotem - pojedyncze kliknięcie w danym stanie oznacza dokonanie wyboru danej opcji i przejście do kolejnego parametru
- brak dokonania wyboru dowolnej z opcji w czasie 10 sek. spowoduje wyjście z trybu konfiguracji bez dokonywania zmian.

Istnieje możliwość blokady trybu konfiguracji poprzez zwarcie zworki R3 - będzie to jedyny sprzętowy "przełącznik", gdyż reszta została przeniesiona do softu.

Rozwiązanie to wnosi nowy wymiar w możliwościach adaptacji działania sterownika pod indywidualne potrzeby użytkownika.

W nowej wersji obniżyłem progi napięć w funkcji pomiaru napięcia ogniwa na:
< 3,05V - ostrzeganie
< 2,9V - przełączenie w moon-mode
< 2,8V - wyłączenie (zabezpieczenie przed głębokim rozładowaniem)

A zatem w praktyce będzie to działać tak:
- pracujący wybrany tryb (do czasu spadku napięcia do ok. 3,05V)
- pracujący wybrany tryb z ostrzeganiem co 8 sek. (3,05-2,9V)
- przełączenie w moon-mode
- przełączenie w moon-mode + ostrzeganie
- wyłączenie sterownika (zabezpieczenie)

Wersja 2.1 przechodzi aktualnie testy.

emerel - 10-01-2010, 14:25

df napisał/a:

Wersja 2.1 przechodzi aktualnie testy.

Gratuluję i czekam (-y ;-) ) na wersję "produkcyjną", szerzej dostępną.

pozdrawiam!

Bulba - 10-01-2010, 16:16

Zapomnialem zapytac wczesniej, jaka jest jego sprawnosc ?
czarny_kruk - 10-01-2010, 16:41

df napisał/a:

czarny_kruk napisał/a:
Zasugerowalbym jedynie zmiane w ostrzeganiu o rozladowanym accu. Z praktyki moim zdaniem lepsze jest konkretna ilosc (np. 5-8) migniec co 8sek po przekroczeniu progu niz mruganie niepotrzebnie przez kilkanascie minut.

Jeżeli ostrzeganie o niskim stanie miałoby się samo po kilku razach wyłączyć, to jaki miałoby ono sens? Celem tego jest właśnie informowanie użytkownika, że kończy się energia i jest on dopóty informowany, dopóki napięcie na akumulatorze jest poniżej ustalonej wartości.
Założę się, że wielu użytkowników po kilku ostrzeżeniach nie będzie już tego pamiętać i nagle zostanie zaskoczonych ciemnością (zabezpieczenie przed głębokim rozładowaniem).


Wg mnie to dyskusyjna sprawa. Kwestia ilosci tych przypomnien. Po 5-8 mozna juz dosc dobitnie zapamietac o co chodzi, a z autopsji wiem ze miganie przez kilkanascie minut JEST uciazliwe, kiedy to mozemy jeszcze w pelni korzystac z energii.

df napisał/a:

czarny_kruk napisał/a:
Alternatywne rozwiazanie to aby klikniecie po wlaczeniu sie ostrzegania powodowalo zaprzestanie dalszego migania co 8sek, zejscie do moon-mode pozostaje aktywne.

Użytkownik w każdej chwili ma możliwość zmiany trybu na inny (jak i zmiany jasności w trybie), więc może świadomie zmienić tryb na mniej prądożerny.
Jeżeli tego nie zrobi, a napięcie zbliży się do granicy odcięcia, to sterownik ten sam podejmie za niego decyzję i przełączy jasność w moon-mode zachowując dany tryb pracy.
Jedno kliknięcie wycofa moon-mode przywracając ustawioną jasność w tym trybie itd.

Tyle, ze po przelaczeniu na nizszy tryb przez uzytkownika miganie zdaje sie nie znika? Czyli zalozmy - korzystajac ze sredniej jasnosci wlacza sie miganie i z racji nieduzego obciazenia mamy to miganie zagwarantowane przez kilkadziesiat minut. :(

Bulba napisał/a:
Zapomnialem zapytac wczesniej, jaka jest jego sprawnosc ?

Srednia sprawnosc dla zasilania z li-ion i tego rozwiazania (driver liniowy) wyniesie okolo 90%.

lennin - 10-01-2010, 17:41

czarny_kruk napisał/a:
df napisał/a:

czarny_kruk napisał/a:
Alternatywne rozwiazanie to aby klikniecie po wlaczeniu sie ostrzegania powodowalo zaprzestanie dalszego migania co 8sek, zejscie do moon-mode pozostaje aktywne.

Użytkownik w każdej chwili ma możliwość zmiany trybu na inny (jak i zmiany jasności w trybie), więc może świadomie zmienić tryb na mniej prądożerny.
Jeżeli tego nie zrobi, a napięcie zbliży się do granicy odcięcia, to sterownik ten sam podejmie za niego decyzję i przełączy jasność w moon-mode zachowując dany tryb pracy.
Jedno kliknięcie wycofa moon-mode przywracając ustawioną jasność w tym trybie itd.

Tyle, ze po przelaczeniu na nizszy tryb przez uzytkownika miganie zdaje sie nie znika? Czyli zalozmy - korzystajac ze sredniej jasnosci wlacza sie miganie i z racji nieduzego obciazenia mamy to miganie zagwarantowane przez kilkadziesiat minut. :(


Nie do końca tak jest. Z autopsji wiem że mryganie w 100% ustępuje przy przełączeniu na przykładowe 10% na długi okres czasu. Pewnie to wina mich akusów :)

czarny_kruk - 10-01-2010, 17:49

lennin, nawet na Twoich akusach jak wskoczy Ci miganie na poziomie mid (powiedzmy 30%) to masz ladnych kilkadziesiat minut (jak nie wiecej) mrugania co 8sekund :roll:
df - 10-01-2010, 19:07

czarny_kruk napisał/a:
Kwestia ilosci tych przypomnien. Po 5-8 mozna juz dosc dobitnie zapamietac o co chodzi, a z autopsji wiem ze miganie przez kilkanascie minut JEST uciazliwe, kiedy to mozemy jeszcze w pelni korzystac z energii.

Uznałem, że tak będzie lepiej, ale jeżeli chcesz, to specjalnie dla Ciebie Maćku mogę zrobić, że będzie 5 lub 8 i koniec ;-)
Dla mnie nie jest to żaden problem, choć osobiście uważam to za ryzykowne i mniej przejrzyste dla użytkownika.

czarny_kruk napisał/a:
Tyle, ze po przelaczeniu na nizszy tryb przez uzytkownika miganie zdaje sie nie znika?

Znika, a pomiary są liczone od nowa.
A więc jak masz dużą jasność i napięcie mocno przysiądzie, to po zmianie na med lub low jeżeli tylko napięcie na ogniwie "podniesie się" ponad próg to migać nie będzie - i w praktyce tak właśnie się dzieje, co niezależnie potwierdza Adam:

lennin napisał/a:
czarny_kruk napisał/a:
Tyle, ze po przelaczeniu na nizszy tryb przez uzytkownika miganie zdaje sie nie znika? Czyli zalozmy - korzystajac ze sredniej jasnosci wlacza sie miganie i z racji nieduzego obciazenia mamy to miganie zagwarantowane przez kilkadziesiat minut. :(

Nie do końca tak jest. Z autopsji wiem że mryganie w 100% ustępuje przy przełączeniu na przykładowe 10% na długi okres czasu.

Tak właśnie jest.

czarny_kruk napisał/a:
Czyli zalozmy - korzystajac ze sredniej jasnosci wlacza sie miganie i z racji nieduzego obciazenia mamy to miganie zagwarantowane przez kilkadziesiat minut.

Sterownik mierzy wyłącznie napięcie i nie ma wiedzy ani o pojemności ogniwa, ani o jego odporności na obciążenie (rezystancji wewnętrznej), ani nie ma też wiedzy o obciążeniu.
Tak jak pisałem wcześniej sterownik bierze pod uwagę wyłącznie pomiary napięć i na ich podstawie podejmuje decyzje kiedy zacząć ostrzegać, kiedy przejść w moon-mode i kiedy się wyłączyć chroniąć ogniwo przed głębokim rozładowaniem.
Jasne, że przy dużej jasności (dużym prądzie) czas od rozpoczęcia ostrzegania do wyłączenia będzie krótszy niż przy małej jasności (prądzie) i trudno tu cokolwiek wymyślić poza odpowiednim dobraniem progów, tak by uzyskać jakiś kompromis.
Można oczywiście starać się badać PWM i w zależności od jasności przesuwać te progi, ale IMHO jest to gra nie warta świeczki, bo i tak wiele zależy od pojemności użytego akku oraz prądu diody (silnie zależnego od jej Vf - bo przy tych napięciach /2.8-3.05V/ już jest czynnikiem najsilniej decydującym).

Zauważ Maćku, co by było jakbyśmy odwrócili przypadek:
Sterownik pracuje sobie w low, akku został niskim prądem wyssany praktycznie do zera - napięcie spadło <3,05V (w wersji lennina było 3,2V - obecnie zmiejszyłem je). Sterownik zaczyna sygnalizować i przełączasz w tryb wyższy i co się dzieje - napięcie siada poniżej dopuszczalnej wartości i sterownik (lub zabezpieczenie na akkumulatorze) odcina Ci zasilanie.

W moim rozumieniu (choć nie twierdzę, że nie jestem w błędzie) z dwojga złego lepsze jest sygnalizowanie użytkownikowi niskiego stanu i sugerowanie mu zmiany trybu na bardziej oszczędny oraz zapewnienie bezpiecznego czasu niż "oszukiwanie" go że jest luzik i nagle przy potrzebie użycia większego prądu zapada nagła ciemność.

czarny_kruk napisał/a:
Bulba napisał/a:
Zapomnialem zapytac wczesniej, jaka jest jego sprawnosc ?

Srednia sprawnosc dla zasilania z li-ion i tego rozwiazania (driver liniowy) wyniesie okolo 90%.

Dzięki Maćku - sprawność jest generalnie taka jak układów AMC - im bliższe napięcie zasilania do Vf diody tym większa, jednakże do pełnej stabilizacji prądu na AMC Vcc powinno być o ok. 0,15V wyższe niż Vf. Układy AMC, to stabilizatory liniowe (analogowe), więc prąd przez nie płynący jest praktycznie taki sam jak prąd LED`a, natomiast różnica między napięciem zasilania, a Vf pracującej w takich warunkach diody pogarsza sprawność, gdyż w postaci mocy traconej odkłada się na AMC. Czyli dla Vcc bliksim Vf - sprawność będzie najwyższa, a im większa będzie różnica Vcc >> Vf tym będzie spadać.
Tak jak napisał Maciek, dla zasilania Li-Ion będzie to średnio ok. 90% (mniej na w pełni naładowanym ogniwie, więcej na częściowo rozładowanym).

Natomiast sam procesor pobiera ok. 1mA, więc w stosunku do tego co idzie LED`a to znikoma kropla w morzu.

I jeszcze słówko technicznego komentarza - napisałem, że sterownik robi nie pomiar, a pomiary napięcia, gdyż w istocie na podejmowaną przez niego decyzję nie wchodzi pojedynczy odczyt z przetwornika ADC, ale seria kilku kolejnych pomiarów.
Dlaczego tak - dlatego, by uśredniał on odczyty i nie brał wartości chwilowych, które mogą być spowodowane PWM`em oraz pracującymi trybami sekwencyjnymi (przetwornik ten działa na zasadzie podwójnego całkowania) - tak jest bezpieczniej, a pomiary są dokładniejsze.

Pyra - 10-01-2010, 19:42

df napisał/a:

I jeszcze słówko technicznego komentarza - napisałem, że sterownik robi nie pomiar, a pomiary napięcia, gdyż w istocie na podejmowaną przez niego decyzję nie wchodzi pojedynczy odczyt z przetwornika ADC, ale seria kilku kolejnych pomiarów.
Dlaczego tak - dlatego, by uśredniał on odczyty i nie brał wartości chwilowych, które mogą być spowodowane PWM`em oraz pracującymi trybami sekwencyjnymi (przetwornik ten działa na zasadzie podwójnego całkowania) - tak jest bezpieczniej, a pomiary są dokładniejsze.


Znaczy, uśredniasz, czy odrzucasz odbiegające od "normy"?

Ja do tej pory zawsze robiłem uśrednianie od 8 do nawet 128 pomiarów.

Pozdrawiam

df - 10-01-2010, 21:31

Pyra napisał/a:
Znaczy, uśredniasz, czy odrzucasz odbiegające od "normy"?
Ja do tej pory zawsze robiłem uśrednianie od 8 do nawet 128 pomiarów.


Metod jest wiele - w tym przypadku akurat robię kolejne 3 pomiary i odrzucam wartości skrajne. Wcześniej stosowaną metodą były 2 kolejne pomiary, których różnica nie była większa niż N. To są metody proste i nie wymagające przechowywania dużych ilości danych oraz szybkie i realizowane przy pomocy prostych operacji arytmetycznych.

Tam gdzie jest więcej pamięci i mam operacje mnożenia i dzielenia często stosuję bądź to arytmetyczne uśrednianie bloków pomiarów typu: p1, p2, p3 => wynik = (p1+p2+p3)/3, bądź uśrednianie adaptatywne (wagowe z historią) typu: wynik = (a*p + b*wynik`)/(a+b), gdzie p - to ostatni pomiar, wynik` to ostatnia wartość poprzedniego uśrednienia, a "a" i "b" to wagi, np.
wynik = (p + 9*wynik)/10

Pyra - 10-01-2010, 22:03

df napisał/a:

Tam gdzie jest więcej pamięci i mam operacje mnożenia i dzielenia często stosuję bądź to arytmetyczne uśrednianie bloków pomiarów typu: p1, p2, p3 => wynik = (p1+p2+p3)/3, bądź uśrednianie adaptatywne (wagowe z historią) typu: wynik = (a*p + b*wynik`)/(a+b), gdzie p - to ostatni pomiar, wynik` to ostatnia wartość poprzedniego uśrednienia, a "a" i "b" to wagi, np.
wynik = (p + 9*wynik)/10


Jeśli dobrze zrozumiałem, to zmieniając wagi (a i b) masz możliwość regulacji wpływu pomiaru na uśrednianie wyniku... :roll:

Ja robiłem uśrednienie 8 pomiarów (łatwo dzielić)
a=a+ADC - 8 razy
i teraz główna część pomiarowa:
as=a/8
a=a-as
a=a+ADC

Wartość średnia to as
ADC to wartość z bieżącego pomiaru
Na tej zasadzie mam uśrednianie wyników pomiarów w termostacie w akwarium

Pozdrawiam

df - 10-01-2010, 22:37

Pyra napisał/a:
Jeśli dobrze zrozumiałem, to zmieniając wagi (a i b) masz możliwość regulacji wpływu pomiaru na uśrednianie wyniku... :roll:

Dokładnie tak - im większe a w stosunku do b, tym uśrednianie słabsze - czyli wynik szybciej podlega zmianom kolejnych pomiarów.
Zaleta tego jest taka, że mamy 2 zmienne - jedno to średnia, która iteracyjnie jest wykorzystywana do wyliczeń samej siebie w kolejnych cyklach, a drugie do wartość kolejnego pomiaru.

Pyra napisał/a:
Ja robiłem uśrednienie 8 pomiarów (łatwo dzielić)
a=a+ADC - 8 razy
i teraz główna część pomiarowa:
as=a/8
a=a-as
a=a+ADC

Wartość średnia to as
ADC to wartość z bieżącego pomiaru
Na tej zasadzie mam uśrednianie wyników pomiarów w termostacie w akwarium

Tak Twój algorytm odpowiada sumie (p1+p2+p3....+p8)/8 czyli średniej arytmetycznej łączonej z wartością ostatniego pomiaru - tak na oko będzie odpowiadać to mojej metodzie z a i b - a=1, b=8.
Tylko o ile faktycznie dzielenie przez 8 (generalnie 2^n) robi się na przesunięciach bitowych bardzo łatwo, to Twoje zmienne powinny być co najmniej 16-to bitowe, albo rozdzielczość ADC będzie bardzo mała by zmieścić sumę 8 pomiarów w 1-bajcie.

Do dokładnych pomiarów na ADC można freezować procesor, co zmniejsza szumy i zwiększa dokładność odczytów (jest do tego wsparcie sprzętowe w Atmelach).

Czasem warto też filtrować sygnał wchodzący na port układem RC - np. tak jak to zrobiliśmy z Arkiem w df&cali do pomiaru średniej wartości prądu.

Pozdrawiam,

Pyra - 11-01-2010, 09:29

df napisał/a:

Pyra napisał/a:
Ja robiłem uśrednienie 8 pomiarów (łatwo dzielić)
a=a+ADC - 8 razy
i teraz główna część pomiarowa:
as=a/8
a=a-as
a=a+ADC

Wartość średnia to as
ADC to wartość z bieżącego pomiaru
Na tej zasadzie mam uśrednianie wyników pomiarów w termostacie w akwarium

Tak Twój algorytm odpowiada sumie (p1+p2+p3....+p8)/8 czyli średniej arytmetycznej łączonej z wartością ostatniego pomiaru - tak na oko będzie odpowiadać to mojej metodzie z a i b - a=1, b=8.
Tylko o ile faktycznie dzielenie przez 8 (generalnie 2^n) robi się na przesunięciach bitowych bardzo łatwo, to Twoje zmienne powinny być co najmniej 16-to bitowe, albo rozdzielczość ADC będzie bardzo mała by zmieścić sumę 8 pomiarów w 1-bajcie.

Tak tak 16 bitów ;)
Uzyskałem w ten sposób zadowalającą precyzję pomiaru z dokładnością do 0,1°C

df napisał/a:
Do dokładnych pomiarów na ADC można freezować procesor, co zmniejsza szumy i zwiększa dokładność odczytów (jest do tego wsparcie sprzętowe w Atmelach).

Czasem warto też filtrować sygnał wchodzący na port układem RC - np. tak jak to zrobiliśmy z Arkiem w df&cali do pomiaru średniej wartości prądu.


A ja robiłem próby z wprowadzaniem asynchronicznych przebiegów do Vref, zgodnie z notą Atmela i wychodziły zadowalające wyniki, 12-to bitowa rozdzielczość nie była problemem, ale trzeba było uśredniać dużo większą liczbę pomiarów.

Pozdrawiam

lennin - 12-01-2010, 11:55

A ja sie nie mogę doczekać testowania wersji 2.1 :)
Darek - 13-01-2010, 16:29

Witam
Do mnie sterowniczek juz dotarł.Niedługo testy :) .
Dzieki za piekną robote i wielkie zaangazowanie.

Ragrastin - 13-01-2010, 22:18

Jeszcze ja coś od siebie
Sterownik z tego co widzę po prostu CUDOWNY, gratuluje tak udanego projektu
Driverek już zamówiłem i czekam na niego z niecierpliwością

DNF - 18-01-2010, 15:15

Wlasnie, z drzacymi rekoma, otwieram przesylke :D
Wielkie dzieki :)
Pozdrawiam
DNF

Marcio - 21-01-2010, 13:01

Pozdrawiam.
Nie jestem az tak wspanialym elektronikiem, ale mam 2 pytania:
1. Jest regulacja jasnosci linearna? Wg mnie chyba nie.
2. Jezeli VCC > VF + 0,15V, to jak Vf=3,2V a driver odcina sie dopiero przy 2,9V, to jak otworzy diode przy Vcc=3,3V? Przeciez nie ma tam boost elektroniki... (3,3-0,15=3,15<3,2)
Dzieki

Pyra - 21-01-2010, 13:08

Marcio napisał/a:
Pozdrawiam.
Nie jestem az tak wspanialym elektronikiem, ale mam 2 pytania:
1. Jest regulacja jasnosci linearna? Wg mnie chyba nie.

Regulacja jasności jest bardzo zbliżona do liniowej, przynajmniej w poprzednim tak było, a nie sądzę, żeby df "się cofnął" z postępem. Zresztą była obszerna dyskusja na forum w tym temacie.

Marcio napisał/a:
2. Jezeli VCC > VF + 0,15V, to jak Vf=3,2V a driver odcina sie dopiero przy 2,9V, to jak otworzy diode przy Vcc=3,3V? Przeciez nie ma tam boost elektroniki... (3,3-0,15=3,15<3,2)
Dzieki

No tak, tyle tylko, że powiedzmy: 3,2V jest dla prądu 1A, a przy prądzie 100mA to już będzie 2,98V; a przy 10mA tylko 2,5V.
Vf diody określa sie dla założonego prądu.

Pozdrawiam

Marcio - 21-01-2010, 13:21

A tak. Ciekawe.
Wywstaja dalsze pytania:
- do jakiego napiecia na akusie potrafi ten driver regulowac prad 1A w diode?
- co sie dzieje z napieciem, ktore ma naladowany akus? (Vcc=4,2V a dioda na 1A Vf=3,5 naprzyklad) Czy roznica napiecia nie zmieni sie w cieplo?

Pyra - 21-01-2010, 13:49

Marcio napisał/a:
A tak. Ciekawe.
Wywstaja dalsze pytania:
- do jakiego napiecia na akusie potrafi ten driver regulowac prad 1A w diode?


Vf(1A) + 0,15V (AMC) = Ubat

Marcio napisał/a:
- co sie dzieje z napieciem, ktore ma naladowany akus? (Vcc=4,2V a dioda na 1A Vf=3,5 naprzyklad) Czy roznica napiecia nie zmieni sie w cieplo?

Dokładnie, moc start zostanie wydzielona w postaci ciepła na układach AMC

Ragrastin - 21-01-2010, 17:57

Od wczoraj ostro męczę ten wspaniały driver!
Spodziewajcie się niedługo mojego prototypu w projektach!

Nie udało mi się dojść tylko do jednego jak podłączyć mikroswitch'a!
Flagiusz pisze:
Cytat:
Mikroswitch włączyć można między pin 1 MCU, a masę - sterowanie takie samo jak odcięciem zasilania.

Pin 1 MCU? nie mogę dojść gdzie to jest, sprawdzałem w katalogu attiny nie ma takiego pinu jak MCU! A podłączenie do masy, gdzie dokładnie do masy attinego (GND)?
Może ktoś miejsce podłączenia wskazać na schemacie lub zdjęciu z 1 posta?

czarny_kruk - 21-01-2010, 18:02

Ragrastin napisał/a:
Od wczoraj ostro męczę ten wspaniały driver!
Spodziewajcie się niedługo mojego prototypu w projektach!

Nie udało mi się dojść tylko do jednego jak podłączyć mikroswitch'a!
Flagiusz pisze:
Cytat:
Mikroswitch włączyć można między pin 1 MCU, a masę - sterowanie takie samo jak odcięciem zasilania.

Pin 1 MCU? nie mogę dojść gdzie to jest, sprawdzałem w katalogu attiny nie ma takiego pinu jak MCU! A podłączenie do masy, gdzie dokładnie do masy attinego (GND)?
Może ktoś miejsce podłączenia wskazać na schemacie lub zdjęciu z 1 posta?


hehe... MCU to skrot od procesorka (MCU=MicroControlerUnit) :wink:
1 pin jest zaznaczony w attiny13 kropka przy oznaczeniach układu.
GND to masa, na obwodzie driverka po obu stronach plytki.

Zgodnie z prosba - zaznaczam to na zdjeciu z 1 posta.


Ragrastin - 21-01-2010, 22:16

Dzięki Czarny Kruku, tak też myślałem ale wolałem się upewnić
df - 23-01-2010, 12:28

Ragrastin napisał/a:
Sterownik z tego co widzę po prostu CUDOWNY, gratuluje tak udanego projektu

Bardzo dziękuję :-)

DNF napisał/a:
Wlasnie, z drzacymi rekoma, otwieram przesylke :D
Wielkie dzieki :)

To ja dziękuję :-)

Marcio napisał/a:
1. Jest regulacja jasnosci linearna? Wg mnie chyba nie.
2. Jezeli VCC > VF + 0,15V, to jak Vf=3,2V a driver odcina sie dopiero przy 2,9V, to jak otworzy diode przy Vcc=3,3V? Przeciez nie ma tam boost elektroniki... (3,3-0,15=3,15<3,2)

Marcio, jest tak, jak opisał to kolega Pyra (dzięki).
Uściślając:

Adn.1 sterownik ma liniową stabilizację prądu opartą na specjalizowane układy AMC 7135
Regulacja jasności odbywa się na zasadzie modulacji szerokości impulsów PWM (wypełnienia) w sposób cyfrowy. A zatem pełna 100% jasność oznacza pełne włączenie 3-ech układów AMC co daje pełną sprzętową stabilizację prądu na poziomie 3x350mA = ok. 1A. Wybór innego poziomu jasności (<100%) oznacza sterowanie układami AMC, które pracują z podanym przez kontroler wypełnieniem, a zatem stabilizują one dalej prąd maksymalny o wartości ok. 350mA na każdy z układów AMC w bardzo szybkich cyklach (16kHz) zależnych od współczynnika wypełnienia podawanego przez mikrokontroler. W wyniku tego średnia rzeczywista wartość prądu ulega proporcjonalnemu zmniejszeniu zależnie od współczynnika PWM, co skutkuje zmniejszeniem maksymalnej siły światła.

Adn. 2. Założenie Vcc >= VF + 0,15V odnosi się do zakresu pracy układów AMC w obszarze pełnej stabilizacji prądu (constant current) i nie ma ono żadnego związku z mikrokontrolerem, ani pracującym na nim oprogramowaniu.
Parametr Vf diody LED o którym jest tu mowa oznacza spadek napięcia na wyprowadzeniu diody LED jaki odłoży się gdy przez daną diodę popłynie zadany prąd (np. 1A).
Przykładowo gdy Vf=3,2V @1A nie oznacza, że poniżej 3,2V (np. przy 3,0V) zasilania przestanie ona świecić. Nadal będzie ona świecić, ale z mniejszą jasnością, gdyż przy mniejszym napięciu zasilania popłynie przez nią mniejszy niż wcześniej prąd.

Dioda (także i LED) jest elementem nieliniowym, a zatem wartość Vf jest silnie i nieliniowo (nieproporcjonalnie) zależna od płynącego przez nią prądu. Charakterystykę prądowo-napięciową podają producenci i w zależności od konkretnego egzemplarza może być ona nieznacznie różna.

Układy AMC są w istocie źródłami prądowymi, co znaczy że ograniczają one "nadmiar" (nadwyżkę) prądu do wartości ustalonej. Natomiast nie potrafią one "podnieść" napięcia powyższej napięcia zasilania - nie jest to przetwornica typu step-up.

A zatem rozwiewając Twoje wątpliwości, dla diody o Vf=3,2V będzie ona świecić także przy zasilaniu napięciem 2,9V (choć ze słabszą jasnością).
I w takim stanie sterownik będzie w stanie poinformować użytkownika o kończącej się energii jak również przełączyć się w tryb moon-mode by zmniejszyć pobór prądu i wydłużyć tym samym awaryjnie pozostały czas pracy.
Większość (białych) diod LED przestaje świecić przy napięciu ok. 2-2,5V
A to oznacza, że co najmniej do tych wartości napięć pobierają one ze źródła zasilania prąd. Rodzi to zatem realne zagrożenie, że pozostawiona w stanie włączonym latarka "wyssie" z akumulatora tyle energii, że jego napięcie spadnie co najmniej do tej wartości.
A 2, czy nawet 2,5V dla ogniwa Li-Ion stanowi już bardzo poważne zagrożenie.
Sterownik kontroluje więc napięcie zasilania i nie dopuszcza do tak głębokiego rozładowania ogniwa, stosując odpowiednie techniki - ostrzegania użytkownika, przełączenia w moon-mode, a na końcu po prostu wyłączenia diody LED, tak by zabezpieczając go, powstrzymać dalsze jego rozładowanie.

Marcio napisał/a:
Wywstaja dalsze pytania:
1. do jakiego napiecia na akusie potrafi ten driver regulowac prad 1A w diode?
2. co sie dzieje z napieciem, ktore ma naladowany akus? (Vcc=4,2V a dioda na 1A Vf=3,5 naprzyklad) Czy roznica napiecia nie zmieni sie w cieplo?

Na te pytania także odpowiedział już kolega Pyra (dzięki), ale odpowiem też własnymi słowami:

Adn.1. Regulacja (stabilizacja) prądu do wartości 1A w diodę ma miejsce dla napięcia zasilania Vcc większego lub równego od napięcia pracy diody LED przy tym prądzie (Vf@1A) powiększonego o 0,15V (a dokładniej 0,12V spadku na układach AMC).
A zatem, jeżeli posiadasz diodę LED, która ma Vf(1A)=3,2V, to począwszy od max. napięcia zasilania 6,0V aż do 3,35V dioda LED będzie otrzymywać stały prąd zasilania o wartości ok.1A, a następnie wraz z dalszym spadkiem napięcia, jej prąd zacznie się zmniejszać.

Adn.2. Różnica napięć pomiędzy zasilaniem, a napięciem na diodzie LED odkłada się zgodnie z II prawem Kirhoffa na połączonych w szeregu (względem LED`a i zasilania) układach AMC. A zatem dla Vcc=4,2V i diody Vf=3,5V@1A na układach AMC odłoży się napięcie 4,2-3,5=0,7V.
Moc wydzielona na układach AMC oczywiście zmieni się w ciepło i jest to zachowanie całkowicie typowe i charakterystyczne dla wszystkich stabilizatorów linionwych.
W praktyce jednak nie uda Ci się utrzymać na ogniwie Li-Ion (typu 18650 i mniejszych) napięcia 4,2V pod ciągłym obciążeniem 1A przez więcej niż kilka-kilkanaście sekund.
Napięcie to bardzo szybko spadnie do 3,7-3,8V lub niżej i przez większość czasu rozładowywania się ogniwa będzie w tych granicach.
A zatem w takich warunkach (zdecydowana większość czasu pracy) spadek napięcia na AMC wyniesie ok. 0,2-0,3V

Moc jaka się wytraci na AMC w postaci ciepła, to: 0,2V*1A= 0,2W
Moc jaka się wytraci na diodzie LED, to: 3,5V*1A= 3,5W
A zatem w takich warunkach sprawność układu wyniesie 94,6% (3,5W/3,7W), co jest sprawnością całkiem niezłą i trudną do osiągnięcia na przetwornicach impulsowych typu buck (step-down), a tym bardziej w układach typu boost (step-up).

Układy step-up sprawdzają się lepiej tam, gdzie niezbędnie wymagane jest podniesienie napięcia np. do zasilania LED z 1x 1,2V, natomiast step-down dla napięć Vcc >> Vf, czyli napięć zasilania znacznie wyższych od napięcia pracy diody LED, np. przy zasilaniu z 2x 3,7V, z 12V itd.

Ragrastin napisał/a:
Od wczoraj ostro męczę ten wspaniały driver!
Spodziewajcie się niedługo mojego prototypu w projektach!

Nie udało mi się dojść tylko do jednego jak podłączyć mikroswitch'a!
Flagiusz pisze:
Cytat:
Mikroswitch włączyć można między pin 1 MCU, a masę - sterowanie takie samo jak odcięciem zasilania.

Pin 1 MCU? nie mogę dojść gdzie to jest, sprawdzałem w katalogu attiny nie ma takiego pinu jak MCU! A podłączenie do masy, gdzie dokładnie do masy attinego (GND)?
Może ktoś miejsce podłączenia wskazać na schemacie lub zdjęciu z 1 posta?

Jest dokładnie tak, jak opisał to Maciek (dzięki).
Przepraszam, ale kilku osobom tłumaczyłem to na PW, ale faktycznie powinno się to znaleźć również w opisie w tym wątku.

EdiM - 23-01-2010, 22:06

Witam
Weraz trafiłem na ten wątek.
Ciekaw jestem Twojej opinii DF, które rozwiązanie wydaje się Ci teraz lepsze? Sterownik PWM w pierwszej wersji, czy taki oparty na AMC?

Nie wiem, czy przeprogramowałeś już więcej tych driverków, ale czy spotkałeś się z problemami z przeprogramowaniem tych chińskich driverków? Jakiego programatora używasz?

Programowałem ich sporo dla Bociana wcześniej, bo on miał problemy. No i części układów po prostu nie dało się ruszyć, nawet w trybie wysokonapięciowym.
Moja prosta wersja softu zakładała zmianę rezystora na większy w celu podtrzymania trybów. Z 10k na 100k. Nie wnikałem, do czego ten dzielnik może być stosowany.

Swoją drogą ciekawe, jak chińczycy sobie poradzili z jedno-klikiem w takim wykonaniu - chyba właśnie tak się przełącza tryby w oryginale.

Co do dwukliku, to na samym początku mojej przygody ze sterownikami, właśnie tak zrobiłem, ale Midi sprowadził mnie na ziemię, że wszystkie drivery przełącza się pojedynczym klikiem. A mnie od początku wydawało się, że dwuklik jest niegłupi - trudniej o przypadkową zmianę trybu.

Pyra - 23-01-2010, 22:36

EdiM napisał/a:
Programowałem ich sporo dla Bociana wcześniej, bo on miał problemy. No i części układów po prostu nie dało się ruszyć, nawet w trybie wysokonapięciowym.


A no właśnie, ja też nie mogłem się dobrać do procka, AVR ISP, w ogóle go nie rozpoznawał, wymieniłem na inny..... :roll:

Pozdrawiam

df - 23-01-2010, 23:14

EdiM napisał/a:
Witam
Weraz trafiłem na ten wątek.
Ciekaw jestem Twojej opinii DF, które rozwiązanie wydaje się Ci teraz lepsze? Sterownik PWM w pierwszej wersji, czy taki oparty na AMC?

Witaj Edim,
Oba rozwiązania mają swoje plusy i minusy. W wersji AMC plusem jest lepsza (dokładniejsza) stabilizacja prądu w szerszym zakresie napięć wejściowych oraz mniejsze chwilowe wartości szczytowe prądu powodujące przesunięcia barwy, natomiast minusem jest trudniejsza zmiana maksymalnego prądu, która wymaga ingerencji sprzętowej w postaci dodawania układów AMC.
W wersji z AMC odpadł mi spory kawałek kodu związany z kontrolą prądu i jego regulacją. W zamian tego mogłem oprogramować nowe funkcje np. pomiar napięcia i rozbudować logikę sterowania oraz konfiguracji. W obecnej wersji AMC procesor przez większość czasu śpi w idle`u, przez co bardzo mocno oszczędza energię.

EdiM napisał/a:
Nie wiem, czy przeprogramowałeś już więcej tych driverków, ale czy spotkałeś się z problemami z przeprogramowaniem tych chińskich driverków?

Tak, ostatnio kupiłem ich troszkę i niestety miałem z nimi sporo problemów, bo nie dość że były dość brzydko poblokowane (powyłączane na fuse-bit`ach SPIEN), to jeszcze nie we wszystkich z nich poprawnie przechodził chip-erase oczywiście robiony w HVSP. Układy czytały się poprawnie, ale nie chciały się przeprogramować (np. zapisać nowe ustawienia kalibracji i fuse).

EdiM napisał/a:
Jakiego programatora używasz?

Używam swojej własnej konstrukcji kompatybilnej pod względem protokółu komunikacyjnego z STK-200 (ISP) oraz opracowanego specjalnie do tego celu własnego rozwiązania sprzętowego do HVSP.

EdiM napisał/a:
Programowałem ich sporo dla Bociana wcześniej, bo on miał problemy. No i części układów po prostu nie dało się ruszyć, nawet w trybie wysokonapięciowym.

Problem Bociana w pełni rozwiązałem - w części driverów była zworka blokująca linię MISO oraz był przestawiany preskaler zegara (CKSEL) na inną częstotliwość, przez co procki wymagały zastosowania trybu z wolniejszym programowaniem. Szybsze programowanie prowadziło do błędów i blokowania się kontrolerów, a problem ten ujawniał się bardzo niedeterministycznie i tylko na części układów. Od kiedy Bocian używa sterowników z moim softem i innych ustawień dot. procesu samego programowania nie ma żadnych problemów ani z ich działaniem, ani programowaniem.

Pyra napisał/a:
A no właśnie, ja też nie mogłem się dobrać do procka, AVR ISP, w ogóle go nie rozpoznawał, wymieniłem na inny..... :roll:

Ja się tak naciąłem na PCB z 4x AMC - niestety problemy, na które natrafiłem dość znacznie podniosły koszty całego rozwiązania :-( o dodatkowo pochłoniętym czasie nawet nie wspominając.

EdiM napisał/a:
Moja prosta wersja softu zakładała zmianę rezystora na większy w celu podtrzymania trybów. Z 10k na 100k. Nie wnikałem, do czego ten dzielnik może być stosowany.

Ja wykorzystuję ten dzielnik do pomiaru napięcia zasilania, ale niestety wymaga on dokładnej kalibracji praktycznie dla każdego egzemplarza z osobna - rozrzut jest stosunkowo duży, może nie na samych rezystorach, co na diodzie zasilającej MCU.

EdiM napisał/a:
Swoją drogą ciekawe, jak chińczycy sobie poradzili z jedno-klikiem w takim wykonaniu - chyba właśnie tak się przełącza tryby w oryginale.

Podejrzewam, że mogli zastosować takie samo rozwiązanie jak ja w części wcześniejszych swych wersji, a mianowicie zapamiętanie trybu w pamięci robią z opóźnieniem np. w 8-mej sekundzie pracy. Wówczas przez pewien czas zaraz po włączeniu jest aktywne "okno" do zmiany trybów, a po tym czasie następuje zatrzaśnięcie stanu do kolejnego wyłączenia.

EdiM napisał/a:
Co do dwukliku, to na samym początku mojej przygody ze sterownikami, właśnie tak zrobiłem, ale Midi sprowadził mnie na ziemię, że wszystkie drivery przełącza się pojedynczym klikiem. A mnie od początku wydawało się, że dwuklik jest niegłupi - trudniej o przypadkową zmianę trybu.

Dwuklik ma swoje zalety - np. trudniej jest przypadkiem zmienić tryb np. w latarce na rowerze podskakującej na wybojach. Znam wiele osób, które do tego podchodziły bardzo sceptycznie, ale po chwili zabawy zmieniały zdanie przekonując się do tego.
Jak wiesz w swych projektach stosowałem oba rozwiązania - przy dużej liczbie trybów szybszy jest 1-klik, ale w zastosowaniach praktycznych (a nie "pokazowych") bardziej zależy na pewności i powtarzalności, bez przypadkowej ich zmiany. 2-klik jest bardziej świadomym (mniej przypadkowym) zdarzeniem, niż 1-klik który bardzo często może pojawić się nieoczekiwanie i co przy dużej liczbie trybów może być dość irytujące, bo trzeba się przez nie wszystkie przeklikać by wrócić spowrotem do tego, co miał być.

Pyra - 24-01-2010, 08:52

df napisał/a:

Jak wiesz w swych projektach stosowałem oba rozwiązania - przy dużej liczbie trybów szybszy jest 1-klik, ale w zastosowaniach praktycznych (a nie "pokazowych") bardziej zależy na pewności i powtarzalności, bez przypadkowej ich zmiany. 2-klik jest bardziej świadomym (mniej przypadkowym) zdarzeniem, niż 1-klik który bardzo często może pojawić się nieoczekiwanie i co przy dużej liczbie trybów może być dość irytujące, bo trzeba się przez nie wszystkie przeklikać by wrócić spowrotem do tego, co miał być.


No i właśnie to mnie skłoniło do rozwiązania 1 klik w górę, 2 klik w dół.

Pozdrawiam

EdiM - 24-01-2010, 11:22

To jeszcze zapytam - DF jakiego softu używasz do obsługi STK200?
Można w nim zmniejszyć szybkość programowania?

Z tego co widzę, to minimalny zegar dla Attiny to 128k, czyżby to było za wolno. No i nie wydaje mi się by twórcy programu zeszli tak nisko z taktowaniem, bo nie ma to za bardzo sensu. DLA HVSP z tego co widzę to w ogóle taktowanie jest zewnętrzne.

Dla mnie kolejna ciekawostka to fakt, że nie mogłem tych procków ruszyć programatorem Uprog (rk-system). Tam jest możliwość programowania wysokonapięciowego i wtedy programowanie nie korzysta z wewnętrznego zegara.

No ale może za mało czasu temu poświęciłem.

Volt - 24-01-2010, 14:47

EdiM napisał/a:
Z tego co widzę, to minimalny zegar dla Attiny to 128k

Jak ustawimy jeszcze do tego CKDIV/8 to mamy 16kHz.
No i o ile 128kHz za pomocą stk500v2 (przełączonym na tryb 'niższego taktowania') jeszcze obsłużysz, to z 16kHz już się nie komunikuje.

Właśnie jeden taki na 16kHz mi leży i jeszcze nie wiem co z nim zrobić :mad:

EdiM - 24-01-2010, 14:56

Jakoś nie widzę, by stosowanie tak niskiej częstotliwości dla driverka LED miało sens - a mowa była o chińskich driverach.
No chyba, że specjalnie tak przestawiłeś, to już inna bajka.

Volt - 24-01-2010, 15:44

EdiM napisał/a:
Jakoś nie widzę, by stosowanie tak niskiej częstotliwości dla driverka LED miało sens - a mowa była o chińskich driverach.

Oczywiście, w driverach nie ma potrzeby ani sensu schodzić tak nisko z częstotliwością taktowania, chciałem jedynie zaznaczyć, że taka możliwość istnieje.

ad2. - tak, sam tak ustawiłem, z czystej ciekawości :wink:

pawelsz - 24-01-2010, 15:55

zgodzę się z DF odnośnie dwukliku, a i paru moich kumpli tez to potwierdzi- jest praktyczniejszy w użyciu, po prostu zmiana trybu jest świadoma i można chwilowo przyświecić sobie mając włącznik forward, przy jednokliku nie zrobimy tego tak prosto.
Wolę pewność działania niż dyskotekę

MardoQ - 24-01-2010, 17:18

Volt napisał/a:
EdiM napisał/a:
Z tego co widzę, to minimalny zegar dla Attiny to 128k

Jak ustawimy jeszcze do tego CKDIV/8 to mamy 16kHz.

A to nie jest tak, że 128 uzyskuje się właśnie dla Fosc=1MHz i włączony CKDIV/8 ?

Pyra - 24-01-2010, 17:28

MardoQ napisał/a:
Volt napisał/a:
EdiM napisał/a:
Z tego co widzę, to minimalny zegar dla Attiny to 128k

Jak ustawimy jeszcze do tego CKDIV/8 to mamy 16kHz.

A to nie jest tak, że 128 uzyskuje się właśnie dla Fosc=1MHz i włączony CKDIV/8 ?


To jest osobny oscylator RC o niskiej dokładności:

Table 2. Device Clocking Options Select(1)
Device Clocking Option ................CKSEL1..0
Calibrated Internal RC Oscillator.......... 01, 10
External Clock .......................................00
128 kHz Internal Oscillator ......................11

Pozdrawiam

hEx - 25-01-2010, 17:49

powitania ;)
Bardzo fajny projekt, ciekawostka: kiedyś testowałem eeprom w ATmega8, średnio do pierwszego błędu wyszło 4537000 zapisów (tej samej komórki).
Do wydłużenia żywotności używałem dwóch buforów cyklicznych, jeden na wskaźnik, drugi na daną (o takiej samej długości, wskaźnik ostatnio zapisanej komórki z oczywistych względów nie mógł być zapisywany ciągle w tym samym miejscu).

df - 25-01-2010, 18:17

hEx napisał/a:
powitania ;)
Bardzo fajny projekt, ciekawostka: kiedyś testowałem eeprom w ATmega8, średnio do pierwszego błędu wyszło 4537000 zapisów.

No to ładnie - to będzie jakieś 45x więcej niż gwarantuje producent.
Zakładam, że leciałeś licznikiem w kółko w pełnym zakresie od 0-0xff.

Ja minimalizuję zerowanie bitów, negując (do postaci logicznie komplementarnej) wszystkie zapisywane fizycznie do pamięci wartość i odwracam je tuż po odczycie. A więc tam, gdzie operuję na prostych wartościach 0,1,2,3... nie zużywam niepotrzebnie pamięci na ff-owanie i zaraz po tym ponowne zerowanie bitów, co jeszcze bardziej powinno zwiększyć jej długie i bezawaryjne życie.

hEx napisał/a:
Do rozłożenia używałem dwóch buforów cyklicznych, jeden na wskaźnik, drugi na daną (o takiej samej długości, wskaźnik ostatnio zapisanej komórki z oczywistych względów nie mógł być zapisywany ciągle w tym samym miejscu).

Ja swoje rozpraszanie zrobiłem podobnie, tylko że moja przestrzeń wskaźników jest stosunkowo mała (silnie agreguje różne dane na pojedynczych bajtach) i mam dodatkową kopię przestrzeni wskaźników, gdyż uznałem, że one także pomimo setek tysięcy/milionów rzadziej występujących zmian także powinny być redundantne i zabezpieczone. Reszta pamięci to liniowa dużą przestrzeń, w którą dynamicznie mapuję docelowe wartości.
Każdy zapis weryfikowany jest odczytem i jeżeli odczytam co innego niż zapisałem (błąd), to posługując się algorytmem obliczenia "najdalszego" wskaźnika +1 określam nowy adres danej komórki modyfikując dany wskaźnik.
Obszar wskaźników zmieniany jest tylko przy relokacjach danych - a więc zmienia się on tylko, gdy nie uda się weryfikacja odczytu zapisanej danej, a więc nastąpi jej relokacja.
Dodam, że zapasowy bufor na wskaźniki nie jest równolegle zapisywany wraz z buforem głównym, ale wykorzystywany tylko i wyłącznie dla wskaźnika, którego komórka bazowa uległa uszkodzeniu - wówczas następuje przeniesienie tego konkretnego wskaźnika i dalsze jego zapisy idą wyłącznie na bufor drugi (na kopię). W ten sposób także i wszystkie wskaźniki mają swoje "zapasowe" kopie.

hEx - 26-01-2010, 09:45

df napisał/a:

Zakładam, że leciałeś licznikiem w kółko w pełnym zakresie od 0-0xff.

Tak, choć na początku nie było to takie oczywiste - w pierwszej wersji zapisywałem ciągle tą samą liczbę, gdzieś w okolicach 10mln zorientowałem się że coś nie gra (mimo że wartość zapisana była równa odczytanej). Okazało się że ona mi tam zamarzła na stałe, z eeproma zrobił się prom ;).

Każdy sposób spełniający zadanie jest dobry.

lennin - 26-01-2010, 17:24

Uff w końcu dostałem :D kochana nasza poczta polska. Ide sobie klikać. Dzięki Darku :mrgreen:
Bulba - 26-01-2010, 23:22

Ja czekam na wersje 1.4A :)
No moze nie ja tylko moja V-65C :D

Calineczka - 01-02-2010, 21:48

df napisał/a:

......

W ten sposób możliwe będzie softwarowe ustawianie następujących parametrów:
1. dostępność trybu strobe-rowerowy (tak=będzie/nie=nie będzie)
2. opcja pomiaru i kontroli stanu napięcia baterii (tak=włączona/nie=wyłączona)
3. pamięć ostatniego trybu (tak=włączona/nie=wyłączona)
4. opcja konfiguracji jasności dostępna po 3-kliku (tak=włączona/nie=wyłączona)

Każda z opcji wyboru przebiega w następujący sposób:
- przez 2 pierwsze sek. sterownik oczekuje ze zgaszoną diodę - kliknięcie w tym czasie anuluje zmianę danego parametru i powoduje przejście do kolejnego z zachowaniem jego aktualnej wartości
- następnie sterownik zapali diodę z jasnością średnią (tak) i co 2 sekundy będzie zmieniał jej jasność na niską (nie) i spowrotem - pojedyncze kliknięcie w danym stanie oznacza dokonanie wyboru danej opcji i przejście do kolejnego parametru
- brak dokonania wyboru dowolnej z opcji w czasie 10 sek. spowoduje wyjście z trybu konfiguracji bez dokonywania zmian.



Wersja 2.1 przechodzi aktualnie testy.



mam, mam właśnie przechodzi :mrgreen:
Pierwsze wrażenia bardzo pozytywne, jak się do dwukliku człowiek przyzwyczai to nawet chyba jest lepszy od jednokliku...oswajam się...
Będę miał jakieś wnioski to się pochwalę :mrgreen:
Idę klikać :razz:

pawelsz - 01-02-2010, 21:55

ano ja od dawna ćwiczę inne wersje, ale jednak dwuklik
na razie jest ok, musze ogniwo wyładować celem obaczenia bajerków, hmm, ale coś z uwag wymyślę, żeby nie było, że nie klikałem
edi
us wiem
wchodzimy do programowania jasności i se mryga 2 razy po 2 mrugnięcia i dopiero potem zmiania, ale w sumie jak się wie, to nie jest to złe, kurczę ide dalej klikać forwardem

freebike - 01-02-2010, 22:10

Też klikam, popieram że dwuklik jest ok. Co do informowania o słabym zasilaniu wolałbym rozwiązanie bez ciągłego mrugania. Kilka mrugnięć informujących mnie że czas oszczędzać to co jeszcze zostało w aku lub zmienić go na nowy, z pewnością mi wystarczy. Mógłby się powtarzać przy ponownym włączeniu latarki. Mrugacz co 8 sek trochę denerwuje. Wolałbym zejść na niższy tryb i świecić mniejszą mocą do nowej granicy gdzie latarka mnie poinformuje że trzeba zejść na jeszcze niższy tryb. Później odcięcie zasilania.

Oczywiście doceniam pracę DFa nad projektem i wciąż jestem podekscytowany posiadaniem takiego drivera :) Chciałem tylko napisać co może być zmienione.

Marcio - 02-02-2010, 13:27

U mnie tez wczoraj wyladowal paczek z wersja 1A i 1,4A. Narazie testowalem 1,4A i jest fajnie. Troche musialem sie przyzwyczaic do UI i jeszcze chyba musze sie pobawic z klikiem, bo na dwuklik trzeba go miec bardziej czuly.
Bardzo mi sie podoba moon mode, ciekawy jestem, jak dlugo potrafi zaswecic na takim trybie :)

lennin - 02-02-2010, 13:32

Szukałem błędów w tej wersji. Jak na razie po dwóch dniach klikania nie wpadło mi nic w oko ;) Gratuluje pomysłu i wykonania po raz kolejny.
Pikom - 02-02-2010, 14:22

Trafiła do mnie latarka z tym driverkiem i klikam... Jestem pod wrażeniem, zwłaszcza że bałem się troszkę jak to będzie z dwuklikiem - ale jest wygodnie. Gratuluję i dziękuję za udostępnienie driverka :)
Calineczka - 02-02-2010, 14:52

...a ja zapowiadam, że wsadzę (a przynajmniej spróbuję) ten sterowniczek do czołówki Ultrafire H3, wykorzystam sterowanie switchem i postaram się zdać foto-relację;-)
Calineczka - 06-02-2010, 22:10

no to mam problem ;-)
testuję najnowszą wersję...i
Chciałem go wsadzić do H3-ki, własnie teraz....ale BARDZO przydało by się by mikroswitchem DAŁO SIĘ CAŁKOWICIE kontrolować driverek. Albo nie wiem jak, albo nie mogę go wyłączyć switchem, jedynie odcinając zasilanie. A bardzo przydała by się taka funkcja-np. dłuższe przytrzymanie switcha i driverek robi off. Darku, co Ty na to???

Mimo wszystkow sadziłem go do H3. Po to, by klikać. Nie wiem, czy zrobiłem coś nie tak, czy coś źle zaprogramowałem, ale od tego klikania zrobiło mi się tak, ze mam 3 tryby, z czego 1 i 2 zawsze mają taka samą jasność. Bez względu na to, czy programuję jasnośc na 1wszym czy na 2gim-ustawiam ja dla obu-na identyczną. :o Na 3cim mogę miec tylko najniższy. Jak wchodze w procedurę reg. jasności....zatwierdzam jasnośc to po wyjściu od razu mam następny tryb(strobo)
Kolejna ciekawostka...pamiętacie, jak niektórym gasły LED-y gdy w najniższym trybie poświeciło się na soczewkę? No to mam to samo :mrgreen: Myslałęm, w czasie zabawy w programowanie, że mi coś nie styka, a tu led pod lampkę biurkową-gaśnie, oddala-robi się jasniejszy :mrgreen: Aha, po tym jak zepsułem te regulacje jasności to próbowałem też regulowac ją przez odłączanie zasilania-efekt ten sam.

Marcio - 09-02-2010, 14:00

No i ja tez mam cos ciekawego. Mam wersje 1,4A i dzis mialem okazje zrobic pomiary na zrodle napiecia stabilizowanego z ragulacja. Testowalem XPG-R5. Prad trzymal sie na 1,46A od 6 do 4,2V i raptem zaczal spadac. Przy 4,0V bylo 1,1A i przy 3,7V mialem juz tylko 0,82A.
Czyzby takie wysokie Vf LEDa??? Jutro bede madrzejszy, zrobie taki sam pomiar dla samego LEDa.
Zrobilem taki sam pomiar do wersji 1A z XP-E Q3 i 1A trzymal sie praktycznie do 3,6V.
Mam 2 pytania:
1. Czy moze byc jakis problem w regulacji? To chyba nie sprawa programu, tak?
2. Moge podlaczyc zasilanie LEDa bezposrednio na stykach PCB i zarowno miec podlaczonego driverka? Bo nie chce mi sie odlutowac druciki (styki musze miec plaskie), ale nie chce uszkodzic driwera.

lennin - 09-02-2010, 17:19

Wygląda na wysokie Vf XP-G to też częściowo odpowiedz na pierwsze pytanie. ad2 to nie potrafię pojąć pytania.
pawelsz - 09-02-2010, 17:33

miałem pare xpg, wszystkie miały mniejsze Vf niż xpe czy xre
przy tym sterowniku 1.4A moja xpg r5 miała Vf coś ok 3.2V chyba- sprawdzę wieczorem (ponotowałem toto) i może jutro sprawdzę ile idzie A w diodę przy rozładowanym akusie
edi
sprawdziłem pomiary- świecy akus, w diodę szło 1.45A i Vf wtedy było 3.1V
jak znajdę miernik to zmierzę Vf i A dla rozładowanego akusa i tej samej diody

pawelsz - 09-02-2010, 21:48

i ju z z grubsza wiadomo- jak to zazwyczaj bywa, nieważne jest ile mamy V bez obciążenia, ale ile V jak latara działa
prosty test , akus z ozysku V na nim (bez obciążenia) 3.87 i mamy na diodzie kole 1A, wsadziłem akusa od AW ma bez obciążenia 3.85V i na diodzie mamy 1.35A (mniej niż obiecane niby ale znacznie więcej pomimo mniejszego V)
Także zasilanie czy sterownik ? pozostawiam to otwarte

Marcio - 10-02-2010, 08:51

Problem rozwiazany. Moze za to wysokie Vf diody.
Oto pomiary. Najpierw pomiar pradu do drivera (Idriver), potem zasilana dioda bez drivera (Idiody). Widac, ze regulacja dziala, jak powinna (cca 0,15V).
Uin Idriver Idiody
4,2 1,34 1,60
4,1 1,21 1,46
4,0 1,10 1,30
3,9 1,00 1,13
3,8 0,92 1,05
3,7 0,82 1,00

Szkoda.
PS: Kupie XP-G w jak najcieplejszej barwie na PCB 14-16mm z niskim Vf.

greg - 10-02-2010, 08:51

Im startsze ogniwo, tym większa rezystancja wewnętrzna. Zwłaszcza widać to na akumulatorach z odzysku, ze starych baterii laptopowych. Teoretycznie wyglądają dobrze, ładują się, napięcie ponad 4V, podłączasz driver i po 2 minutach jest już 3,3V i samo Vf LEDa ogranicza prąd do niskich wartości. Zetknąłem się już nie raz z tym problemem. Zatem uwaga na "doskonałe" ogniwa z odzysku.
Marcio - 10-02-2010, 08:52

W moim przypadku ogniwa sa OK - patrz na pomiary powyzej.
greg - 10-02-2010, 10:02

Marcio, to było ogólne stwierdzenie. Radzę posprawdzać napięcia na ogniwach pod obciążeniem, zwłaszcza tych "z odzysku".
Marcio - 10-02-2010, 12:51

Rozumiem. Ale moje pomiary sa zrobione za pomoca zasilacza z napieciem stabilizowanym, tzn. nie z akumulatora.
pawelsz - 10-02-2010, 13:19

Marcio, przy zasilaniu z lion wychodzi całkiem inaczej, dochodzi klasa ogniwa itd
natomiast nie jestem do końca przekonany, czy tylko Vf ma wpływ na spadanie jasności/prądu na diodzie, zreszta bardziej krytyczny jest spadek napięcia na akumulatorze pod obciążeniem, także pomiary z zasilaczem labo to taka mega fikcja

lennin - 10-02-2010, 13:46

Do tego każdy spadek napięcia na sprężynce, gwincie czy cienkim przewodziku. Z dzisiaj nowe ogniwa 18650 Trustfire DXowe. 4V w spoczynku 3.85V przy 0.5A i 3.65V przy 1A obciążenia. Resztę możecie sobie sami domówić ;)
Marcio - 10-02-2010, 13:53

Wszysko jasne, panowie :)
Tylko tyle, ze jak sie do tego wszystkiego przykloci wosokie Vf diody, to nie bedzie duzo swiatla...

Biszkopt - 01-03-2010, 13:08

Mam małą sugestię. Może warto by było zmienić sposób (poziom logiczny) blokady ustawień na przeciwny, czyli zwarcie pinów zezwala na programowanie. A po co to zamieszanie? Po zabudowaniu drivera w latarce lub czołówce, pomimo wcześniejszej decyzji o skorzystaniu z dobrodziejstwo uniknięcia niezamierzonego przekonfigurowania ustawień, po zastosowaniu małego kontaktronu będzie można dokonać ewentualnych zmian w sposobie działania, bez konieczności zazwyczaj kłopotliwego dostępu do drivera. Wystarczy magnes neodymowy przyłożony do obudowy i pełna funkcjonalność drivera będzie dostępna. Ewentualnie można jeszcze wykorzystać piny od rezystora R5, które chyba w obecnej wersji oprogramowania są wolne, do definiowania poziomu sygnału umożliwiającego dostęp do menu ustawień (jeżeli taka potrzeba okaże się pożądana).
pawelsz - 01-03-2010, 13:14

a po co , skoro blokadę możesz ustawić też w setupie ?
Biszkopt - 01-03-2010, 13:31

Blokada ustawień jasności tak, a moja sugestia dotyczy wejścia w tryb konfiguracji parametrów sterownika. (5 - klików).
Calineczka - 02-03-2010, 19:24

Biszkopt, może i ma to jakiś sens ale zrobić 5cio klika przypadkiem łatwo nie jest ;-)
pawelsz - 02-03-2010, 20:04

ano... i trza szybko klikać dość
Pyra - 02-03-2010, 20:27

A jak ktoś morse'a zna to tylko "5" ti, ti, ti, ti, tit ;) łatwo poszło
vcppp_p - 20-03-2010, 19:49

pytanie do Autora projektu:

na stronie jest napisane (odnośnie stabilizacji prądu)
"...natomiast w wersji testowej "na pająku" ostatnie próby przechodzi pełne autonomiczne rozwiązanie."

czy można prosić o jakieś szczegóły?! :)

df - 20-03-2010, 23:40

vcppp_p napisał/a:
pytanie do Autora projektu:

na stronie jest napisane (odnośnie stabilizacji prądu)
"...natomiast w wersji testowej "na pająku" ostatnie próby przechodzi pełne autonomiczne rozwiązanie."

czy można prosić o jakieś szczegóły?! :)

Opisany w tym wątku projekt sterownika v2.x jest czym innym niż v4.x opisana na mojej stronie WWW (projekt 9).

v2.x - to sterownik podłączany "klasycznie", w którym sterowanie odbywa się przede wszystkim chwilowym odcinaniem zasilania i który zapewnia stabilizację prądu diody LED

v4.x - to prototypowy sterownik "szeregowy", którego zadaniem jest sterowanie pracą LED`a (tryby, jasności) przy pomocy microswitch`a, ale bez stabilizacji jego prądu, która powinna być zrealizowana osobno

Calineczka - 20-03-2010, 23:47

Darku, czy jest jakaś szansa żebyś w sterowaniu switchem zaimplementował on/off?
df - 20-03-2010, 23:53

Korzystając z okazji spieszę poinformować, że zakończone zostały prace nad rozszerzoną wersją 2.2.xxx, która posiada wszystko, co miała wersja 2.1.xxx plus dodatkowo wprowadzona została w konfiguracji opcja wyboru sposobu sterowania zmianami trybów.

W tej wersji użytkownik może sam sobie wybrać, czy sterownik ma zmieniać tryby 2-klikiem (jak było do tej pory), czy też 1-no klikiem.

Zmiana trybu pojedynczym klikiem możliwa jest w 3-sek. oknie czasowym od chwili włączenia sterownika lub ostatniego kliku, po czym tryb zostaje "zatrzaśnięty".

Rozwiązanie to działa niezależnie od wszystkich pozostałych opcji konfiguracji sterownika (w tym opcji pamięci trybów) i daje alternatywną możliwość nieco prostszego dla użytkownika nawigowania między trybami, przy jednoczesnym zachowaniu dzięki 3-sek. blokadzie odpowiedniej odporności na przypadkowe zmiany trybów spowodowane np. utratą kontaktu baterii przy silnych wstrząsach podczas jazdy rowerem w trudnym terenie.

df - 21-03-2010, 00:22

Calineczka napisał/a:
Darku, czy jest jakaś szansa żebyś w sterowaniu switchem zaimplementował on/off?

Szansa oraz działające prototypy jak najbardziej są - pierwszy z nich powstał 3 lata temu, kolejny zastosowany został w ramach pewnej "niedoszłej" inicjatywy, a ostatni kilka dni temu przygotowywany dla jednego z naszych kolegów i jeszcze nie ukończony.

Ponieważ rozwiązanie to wymaga innego połączenia portów (chodzi tu przede wszystkim o INT0 i możliwość budzenia z głębokiego uśpienia) najbardziej eleganckie jest więc przygotowanie pod te potrzeby nowego projektu PCB.
Można oczywiście zastosować w części gotową platformę sprzętową, ale należy się liczyć z koniecznością cięcia i poprowadzenia dodatkowych ścieżek i zmiany rezystorów w dzielniku pomiaru Vbatt itd., co nie jest już tak bardzo eleganckie.

Natomiast będzie to już osobna wersja softu dedykowana w całości do sterowania micro-switchem, a nie rozszerzenie sterowania opisanej w tym wątku wersji 2.x ze sterowaniem odcinaniem zasilania. Na chwilę obecną nie planuję łączenia tych 2 koncepcji w jedną, a zaoszczędzoną w ten sposób pamięć zamierzam poświęcić na inne funkcje i nowe ciekawe pomysły.

gorgu - 23-04-2010, 23:22

Ten Twój sterownik to jest przerywacz tranzystorowy (chopper)?
I on będzie jedynie dobrze pracować jeżeli U zasilania ≈ Uf diody?

Pyra - 23-04-2010, 23:26

gorgu napisał/a:
Ten Twój sterownik to jest przerywacz tranzystorowy (chopper)?
I on będzie jedynie dobrze pracować jeżeli U zasilania ≈ Uf diody?

Bardziej adekwatne jest tu jednak stwierdzenie:
Uz > Vf + 0,15V
Ze względu na to, że stabilizacją prądu zajmują się tu układy AMC (spadek minimum 0,12V)

Pozdrawiam

skaktus - 24-04-2010, 13:04

Ja mam takie pytanko, kiedy driver będzie dostępny oficjalnie ? (chodzi mi o wersję z prądem 1,4)

Informacje, jakie uzyskałem od Ciebie Darku to :

-początek maja

-koniec maja

Więc rozbieżność znaczna. Da to się w miarę określić ?

gorgu - 26-04-2010, 17:10

Pyra napisał/a:
gorgu napisał/a:
Ten Twój sterownik to jest przerywacz tranzystorowy (chopper)?
I on będzie jedynie dobrze pracować jeżeli U zasilania ≈ Uf diody?

Bardziej adekwatne jest tu jednak stwierdzenie:
Uz > Vf + 0,15V
Ze względu na to, że stabilizacją prądu zajmują się tu układy AMC (spadek minimum 0,12V)

Pozdrawiam


Tak, zgadza się. Jeszcze spadek napięcia na mosfecie.

P.S. Ale ten AMC7135 to jest regulator liniowy :o . A to ma tragiczną sprawność. :(

Calineczka - 26-04-2010, 17:21

gorgu napisał/a:
A to ma tragiczną sprawność. :(

a zdefiniuj tragiczną. I oblicz, możesz się zdziwić...i napisz ile Ci wyszło i przy jakich załozeniach ;-)

Pyra - 26-04-2010, 18:36

gorgu napisał/a:
Tak, zgadza się. Jeszcze spadek napięcia na mosfecie.

P.S. Ale ten AMC7135 to jest regulator liniowy :o . A to ma tragiczną sprawność. :(


Tam nie ma mosfeta, procek załącza układy AMC podając na nie zasilanie.

Co do sprawności......, jak napisał Calineczka, zdziwisz się :twisted: .
Ale weź cały zakres pracy, a nie tylko świeżo naładowane akumulatorki, w ciągu 2 minut ;)

Pozdrawiam

gorgu - 02-05-2010, 20:02



Przetwornica Buck była obciążona jednym 3 W Edison'em (700mA Uf=3,3V)
AMC był obciążony 1W Edisonem (350mA Uf=3,2V).
Predator, ze względów bezpieczeństwa, został obciążony H4.
Gdzie żarnik 55W i 60W zostały połączone szeregowo. Aby mniej więcej symulować 4 x EPAW w połączeniu 2s2p.

Dla AMC sprawność została policzona według η=(Pwe-ΔP)/Pwe.
Gdzie ΔP to iloczyn spadku napięcia ΔU na AMC i prądu I przepływającego przez AMC.

Dla pozostałych układów η=Pwy/Pwe.
Uf to napięcie, jakie odłoży się na diodzie przy nominalnym strumieniu świetlnym.

Mała sprawność impulsówek przy małym napięciu jest spowodowana tym, że zastosowane tranzystory mają za duże rds.
Ale za to wytrzymają 40 A i więcej albo 50 V :)
I chyba to jest powód dlaczego driverki od International Rectifier mają zabezpieczenie UVLO.
Dobrze, że Predator tego nie ma, bo wie ile prądu można przepuścić, aby taki mosfet nie wybuchnął. :P

Może kiedyś powstanie impulsowy odpowiednik AMC, ale to kiedyś. :)

Pyra napisał/a:

Co do sprawności......, jak napisał Calineczka, zdziwisz się :twisted:


To było do przewidzenia ;d

df - 02-05-2010, 23:27

gorgu,

1. porównujesz jabłka z gruszkami - przecież wiesz, że drivery na układach AMC są przeznaczone głównie do zasilania z pojedynczych ogniw Li-Ion, które mają max. 4,2V i to w stanie spoczynku (bez obciążenia). Dlaczego zatem stosujesz skalę pomiaru aż do 18V, nie mam pojęcia.

2. Gdybyś podszedł do tematu nieco rzetelniej, to zrobiłbyś porównanie w zakresie napięć do jakich tego typu układy są przeznaczone, a wtedy samemu byś się przekonał, że AMC w tym zakresie napięć jest bardzo dobrym i sprawnym rozwiązaniem.



Jeśli nadal masz wątpliwości, to wykonaj proszę test i zdejmij charakterystykę sprawności z rzeczywistego ogniwa Li-Ion na tych 3 różnych układach i wykreśl ją sobie w skali czasu, a przekonasz się co mówi Calinaczka, czy Pyra (ogniwo co najmniej przez 95% czasu będzie dawało napięcie <4V dla którego nawet na Twoich ch-kach AMC wypada najlepiej).

Żeby była jasność, przetwornice typu buck bardzo dobrze sobie radzą dla napięć Vin >> Vout (znacznie większych) i co do tego nie ma nikt wątpliwości.
Natomiast dla napięć Vin~>Vout (bliskich lub nieco większych), a tak jest dla ogniw Li-Ion i białych LED`ów, układy AMC są zwykle od nich znacznie lepsze.
Driver ten jest właśnie przeznaczony do zasilania z pojedynczego ogniwa Li-Ion, a nie z 18V dla których przedstawiłeś pomiary.

Wybacz, ale w taki sposób jak Ty to ukazujesz można udowodnić cokolwiek, np. że przetwornice typu boost są lepsze niż buck, bo buck nie działają dla Vin<Vout lub że żarówka od latarki 4,5V jest lepsza od żarówki na 220V, bo ta druga podłączona do baterii słabo świeci... Tylko że takie rozumowanie jest IMHO po prostu śmieszne i mało poważne.

EOT.

Pozdrawiam,

pawelsz - 02-05-2010, 23:40

ahha- jak znajdę chwilę czasu, to chyba rozlutuję pigułę D26 - moja wersja drivera Flagiusza (bardzo Ci dziękuję) chyba straciła możliwość programowania, no dziwne, ale prawdziwe- 3 kliki i cisza, ale rozbiorę , żeby wykluczyć rózności
df - 15-05-2010, 17:27

Ponieważ dostaję wiele pytań dotyczących sterowania LED`em przy pomocy wyższych prądów załączam przykładowe diagramy powszechnie dostępnych modułów zawierających układy AMC, przy pomocy których bardzo prosto można zwiększyć wydajność prądową sterownika.

Każdy dodatkowy układ AMC 7135 to ok. +350mA prądu w diodę.




Widoczne na 2 ostatnich zdjęciach diody w obudowach melf mogą zostać zwarte, co poprawi stabilność pracy przy niskich napięciach zasilania.

Zwiększając liczbę układów AMC należy pamiętać, by mieć bardzo wydajne źródło napięcia zasilania oraz bardzo dobre połączenia, gdyż w przeciwnym razie tak znaczny przepływający prąd będzie powodował straty, w wyniku których osiągnięcie odpowiednio wysokich wartości prądu może być trudne lub wręcz niemożliwe.

Rozwiązanie to jest generyczne i działa nie tylko z moim konkretnym rozwiązaniem, ale i z każdym innym wykorzystującym jako źródła prądowe układy AMC.

upek - 15-05-2010, 17:54

Hej,
czy planowałeś użycie innego regulatora zamiast kilku AMC7135?, żeby zapewnić większy prąd przy mniejszych wymiarach i zmniejszyć Vdroopa? Znalazłem np. Texasa TPS737xx - może coś takiego?

pzdr

df - 15-05-2010, 18:29

upek napisał/a:
Hej, czy planowałeś użycie innego regulatora zamiast kilku AMC7135?, żeby zapewnić większy prąd przy mniejszych wymiarach i zmniejszyć Vdroopa? Znalazłem np. Texasa TPS737xx - może coś takiego?

Nie, nie szukałem, gdyż mnie osobiście 1A... no może 1,4A w max całkowicie wystarcza.
A to są zaledwie 3 lub 4 układy AMC, które razem z innymi elementami bez problemu mieszczą się na jednej stronie PCB o fi 15-17mm.

Diagramy załączyłem po to by obrazowo pokazać jak można to zrobić, choć robienie stabilizacji 4A na AMC jest trochę śmieszne.

Przy tak wysokich prądach oczekiwałbym wyższego napięcia zasilania, tak by wraz z jego spadkiem spowodowanym rozładowywaniem się ogniwa oraz samym znacznym jego obciążeniem mieć nieco dłużej utrzymany pełny zakres stabilizacji.
Tak naprawdę >2A w LED`a to IMHO już tylko i wyłącznie wchodzą w grę dobre przetwornice impulsowe step-down i chyba tylko one.

Ale dzięki upek za info - może komuś się to przyda.

Dodam jeszcze, że zamiast AMC do wyjścia mikrokontrolera (pin.6) można podłączyć wprost mosfet`a i sterować praktycznie czymkolwiek (n-mosfet: źródło do masy, bramka do pin.6, dren do układu sterowanego - obciążenia względem +Vcc.
Jak się dobrze przytuli, to da się takiego mosfeta bez problemu położyć na miejscu jednego z AMC-ków.

upek - 15-05-2010, 21:00

Pomysł na inną regulację pojawił się, gdy Calineczka zaprzestał produkcji wcześniejszego driverka z twoim softem. Mam latarkę na 3 sztukach XP-G równlolegle i przy łacznym prądzie 3A na Df@Cali i mam pełną moc do końca ogniwa (AW 2600mah)

Teraz pojwaił się pomysł na 4x XP-G z jednego 18650 i chyba Twój pomysł z mosfetem jest najlepszy bo 12xAMC7135 to przesada. Step-down(czy -up i diody szeregowo) z jednego ogniwa 18650 to chyba niemożliwe.

EdiM - 22-05-2010, 21:49

upek napisał/a:
Hej,
czy planowałeś użycie innego regulatora zamiast kilku AMC7135?, żeby zapewnić większy prąd przy mniejszych wymiarach i zmniejszyć Vdroopa? Znalazłem np. Texasa TPS737xx - może coś takiego?

pzdr

Zauważ, że to zwykłe LDO. Niewiele to ma wspólnego ze źródłem prądowym AMC7135.

Istnieje natomiast np. AMC7140 (700mA), ale ona ma porażający dropout, rzędu 500mV.

Ogólnie jeśli chodzi o większe prądy to ja mogę polecić CC LED driver 3-5V 2,8A L528 - tryby. Tam jest na prawdę niskie napięcie dropout oraz szeroki zakres możliwych prądów wyjściowych.

Robiłem dla Midiego wersie nawet ponad 6A, o ile dobrze pamiętam. No niestety sterowanie mikroprocesorowe tam zastosowane nie ma zbyt ciekawych cech - główna wada brak pamięci. No i nie jest też odporny na odwrotne podłączenie zasilania.

upek - 23-05-2010, 00:53

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 potrzebnaby była kolejna płytka PCB z prockiem i lepszym softem, a to już się nie zmieści. (chyba że zrobisz super oprogramowanie :mrgreen: )
adpa - 20-09-2010, 11:55

Z flagiuszowym sterownikiem zrobiłem sobie roboczo "miękki/ciepły start", który zarazem działa podświetlająco. Tryb specjalny dostałem stroboskop 8 Hz. Nie używam takiego trybu, więc przestawiłem go na najniższą jasność (0,4%=4mA), a zasilanie spiąłem na stałe. Roboczo dlatego, że 4mA, to jednak dużo. Do tego najlepiej też wybrać tryb "piknięcie" co 2 lub 3 sekundy. Czy obecny sterownik da radę pracować niżej niż 0,4%? Może być nawet tak słaby, żeby nie odpalał światła, byleby umożliwiał sterowanie mikroprzełącznikiem.

Trzy tryby i poświęcenie specjalnego, to sensowne rozwiązanie. Można wtedy wrzucić włącznik kontaktronowy, itp.

EDYTOWANO: parę byków rzeczowych zrobiłem :D

df - 15-12-2010, 14:15

upek napisał/a:
Do Twojego sterownika potrzebnaby była kolejna płytka PCB z prockiem i lepszym softem, a to już się nie zmieści. (chyba że zrobisz super oprogramowanie :mrgreen: )

Hmmm... Super oprogramowanie powiadasz...

A co powiedziałbyś na wszystko to co teraz jest plus dodatkowo możliwość swobodnego dobierania ilości, kolejności oraz rodzaju trybów?
Powiem więcej - posiadająca to wersja siedzi już w mojej latarce i przechodzi właśnie testy ;-)

Druga zaś wersja prototypowa ma pomiar temperatury ;-) z płynną regulacją prądu i sygnalizacją na zewnętrznej sygnalizacyjnej diodzie LED.

Ciekaw jestem, jaka jest Wasza opinia - czy bardziej przydatny jest pomiar temperatury (z automatycznym ograniczaniem prądu), czy możliwość swobodnego komponowania własnych trybów?

Niestety obu tych funkcji prawdopodobnie nie zmieszczę na raz do pamięci 13-tki, choć z drugiej strony jak na to spojrzę, to sam się sobie dziwię ile dało się wcisnąć do 1kB kodu ;-)

pawelsz - 15-12-2010, 14:54

hmm- raczej temperatura bardziej się przyda, myślę, że jeśli będą ze 3-4 programowalne tryby to już będzie mega fajnie i bardzo przydatne dla latarek dających ostro czadu w diodę/diody - jeśli to jest możliwe
Pyra - 15-12-2010, 15:21

Głosuję na temperaturę, trzy cztery tryby ciągłe są wystarczające, a jeśli będą konfigurowalne..... :mrgreen:

Pozdrawiam

PS: Mnie się dużo mniej mieści do 13-tki :-(

df - 15-12-2010, 15:58

Korzystając z chwili oddechu przedstawiam Wam kolejny swój projekt z pogranicza sfery wizyjno-koncepcyjnej - tym razem jest to działający prototyp (v3.0) sterownika będący wynikiem długich przemyśleń i chęci stworzenia jeszcze bardziej uniwersalnego rozwiązania sterownika, który poprzez możliwość jeszcze szerszej konfiguracji i personalizacji byłby w stanie spełnić potrzeby i oczekiwania najbardziej wybrednych użytkowników.

Zdaję sobie sprawę, że duże możliwości nie idą zwykle w parze z prostotą i łatwością użytkowania.
A więc także i tu celem nadrzędnym było stworzenie czegoś jeszcze fajniejszego niż to co wymyślono i stworzono dotychczas, ale jednocześnie czegoś, co nadal będzie mieściło się w ramach akceptowalnej intuicyjności i wartości użytkowej.


OK, a zatem co dokładnie może prototyp v3.0 z konfiguracją sekwencji trybów i jak to wszystko działa.

Wersja 3.0 posiada wszystko to, co miała wersja 2.2 natomiast nowością jest możliwość definiowania i swobodnej zmiany przez użytkownika ilości, kolejności i rodzaju trybów.

Konfiguracja trybów realizowana jest przy pomocy wbudowanego w oprogramowaniu sterownika kreatora. Kreator ten umożliwia zbudowanie niczym z klocków dowolnej kombinacji sekwencji od 1-go do 8-miu trybów.

"Klocki" z których budowane są sekwencje dostarczają następujących funkcji:


[1] - tryb ciągły
[2] - stroboskop (8Hz)
[3] - tryb policyjny (naprzemienne 3 jasne i 3 ciemne błyski w krótkich odstępach czasu)
[4] - światło ostrzegawcze (1 błysk co 1s)
[5] - migacz (1Hz wypełnienie 50%)
[6] - tryb SOS (... --- ...)
[7] - lokalizator (podwójny błysk co 8 sek)
[8] - fade-in/fade-out (nie wiem jak to ładnie nazwać, ale efekt polega na płynnym rozjaśnianiu przez 1s i płynnym przygasaniu przez kolejną 1s)

Każdy z tych klocków może być użyty wiele razy i być umieszczony w różnych miejscach w sekwencji. Przykładowo dzięki temu swobodnie można stworzyć zestawy zawierające: jeden tryb ciągły, trzy tryby ciągłe, SOS+2 stroboskopy+lokalizator+kolejny strobe itd. w których każdy z trybów ma niezależnie konfigurowaną i szybką do zmiany jasność.


Wszystkich możliwych unikalnych kombinacji ustawień sekwencji trybów jest bardzo dużo - jeżeli dobrze liczę, to będzie ich coś ok. 43 milionów (wariacja z powtórzeniami na zbiorze 9 elementowym na 8 pozycjach (n^k-1))

Nie ukrywam, że największym wyzwaniem było wymyślenie przyjaznego dla użytkownika mechanizmu sterowania, w którym przy pomocy jednego wyłącznika zasilania dałoby się to wszystko ogarnąć.

Opracowana przeze mnie koncepcja kreatora działa tak:
1. użytkownik w konfiguracji wybiera opcję kreatora sekwencji trybów (dla tych, co znają soft 2.2 jest to umieszczona na ostatniej pozycji ustawień po 5-cio kliku)
2. sterownik wchodzi w tryb wyboru trybu na pozycji pierwszej prezentując kolejno każdy z dostępnych "klocków" przez 6 sekund. Czyli przez 6s mamy tryb ciągły, następnie sekunda przerwy i kolejny dostępny tryb - stroboskop, później policyjny itd.
3. pojedyncze kliknięcie w czasie prezentacji danego "klocka" powoduje jego zapisanie na danej pozycji i przejście sterownika do wyboru kolejnego trybu na pozycji następnej. Dla każdej pozycji (numeru kolejnego trybu w sekwencji) proces wyboru "klocków" wygląda dokładnie tak samo jak w pkt. 2, dzięki czemu można wielokrotnie wybierać te same "klocki"
4. nie wybranie żadnego z klocków kończy sekwencję konfiguracji i powoduje wyjście z kreatora. Działanie kreatora kończy się także po przypisaniu wszystkich z 8-miu dostępnych pozycji.

Graficznie wygląda to tak (na przykładzie ustawienia takiej oto wymyślonej sekwencji trybów: 2 ciągłe, policyjny, lokalizator):
- 1, 2, 3, 4... - to numer wyświetlanego "klocka"
- [2] - numer "klocka" w nawiasie to klocek wybrany 1-klikiem

Kod:
pozycja 1:   [1]                                           - wybrany ciągły
pozycja 2:   [1]                                           - wybrany ciągły po raz drugi
pozycja 3:    1 -> 2 -> [3]                                - wybrany tryb policyjny
pozycja 4:    1 -> 2 -> 3 -> 4 -> 5 -> 6 -> [7]            - wybrany lokalizator
pozycja 5:    1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 -> X    - brak wyboru, koniec konfiguracji sekwencji (wyjście z kreatora)


I w konsekwencji mamy, to co chcieliśmy :-)



Każdemu z ustawionych w ten sposób trybów można następnie zarówno przypisać jak i w dowolnej chwili zmienić indywidualną jasność, np.:



Wersja ta siedzi aktualnie w moim EDC i "się testuje".
Z uwagi na brak miejsca bardzo trudno będzie ją pogodzić z pomiarem temperatury, który w obliczu coraz to większych mocy traconych na LED`ach staje się coraz bardziej istotny.

Niezależnie od dalszych losów tego przedsięwzięcia mam nadzieję, że zebrane i opisane przy jego opracowywaniu spostrzeżenia i wnioski być może komuś się do czegoś przydadzą.

*/ Edycja 2010-12-26 - dodane obrazki

df - 15-12-2010, 17:24

Drugi prototyp to wersja 2.2 rozszerzona o pomiar i regulację temperatury (z możliwością wyłączenia w konfiguracji).
Rozwiązanie to z założenia miało być proste, nie wymagające dużej ilości zmian w sprzęcie (dodatkowe elementy, zmiany połączeń), nie utrudniające pracy użytkownikowi, a przede wszystkim skuteczne.

Z uwagi na problemy z dokładnością pomiaru przy PWM metodą na Vf (więcej tutaj) zdecydowałem się na pomiar przy pomocy termistora. Pomiar bezpośredni temperatury na podstawie Vf jest jak najbardziej możliwy, ale wymaga dalszych badań i precyzyjnych obliczeń (np. w celu sekwencyjnego próbkowania wartości dokładnie w aktywnych fazach PWM-a) i z całą pewnością będzie przedmiotem dalszych moich analiz.

Pomiar temperatury:

Podobnie jak napięcie akumulatora pomiar temperatury odbywa się przy pomocy przetwornika ADC na jednym z wolnych kanałów multipleksera.
By ograniczyć liczbę zewnętrznych elementów do niezbędnego minimum wpadłem na pomysł dość nietypowego rozwiązania - a mianowicie pomiar napięcia realizowany jest
na porcie ze skonfigurowanym pull-up`em.
Dzięki temu mamy podciągnięcie do Vcc wewnętrznym rezystorem rzędu 40k wyprowadzenia, między którym, a masą znajduje się sam termistor.

Początkowo wykorzystałem termistor NTC o Ta=10k@25*C i B w okolicy 2500, tak by w całym istotnym zakresie temperatur (20-120*C) zmieścić się w "wysokim" zakresie odczytów ADC (tuż pod 1,1V dla Vref) zapewniającym wysoką dokładność pomiaru.

Po serii testów rozwiązanie to okazało się niezbyt precyzyjne, gdyż na wynik pomiaru ma wpływ napięcie zasilania, a więc stan ogniwa.
I choć mając realizowany naprzemiennie z pomiarem temperatury pomiar napięcia można było zastosować programową kompensację, znalazłem inne znacznie lepsze rozwiązanie - zmiana napięcia referencyjnego z Vref na Vcc.

W ten oto prosty sposób uniezależniłem dzielnik napięciowy jaki tworzy Rwewn.portu(40k) i termistor od napięcia zasilania :-)
Dla większej dokładności pomiaru w takim układzie korzystniej będzie zastosować NTC o Ta=33k-100k.

ATtiny ma 1-en przetwornik ADC, więc pomiar wartości analogowych odbywa się za pośrednictwem wbudowanego multipleksera analogowego naprzemiennie - raz temperatura, raz napięcie akku.
Ponieważ przełączane są nie tylko porty, ale i napięcia referencyjne pomiar realizowany jest synchronicznie do timera (robiącego PWM) z zachowaniem dużego marginesu czasu na przełaczanie i ustalanie się napięć.
Dodatkowo tak samo jak przy pomiarze napięcia, odczyty temperatury reazlizowane są w seriach, z których wartość końcowa jest uśredniana.
Podnosi to istotnie dokładność pomiaru i uodparnia układ na zewnętrzne zakłócenia.

Regulacja:

Sterownik analizuje temperaturę względem 2 ustalonych progów:
Ta - wartości akceptowalnej, która nie powinna być przekraczana
Tk - wartości krytycznej, powyżej której zasilanie sterownika powinno być natychmiast odcięte

Przekroczenie progowej wartości Ta powoduje płynne zmniejszenie prądu idącego w LED-a/LED-y.
Z uwagi na sporą bezwładność temperaturową (dla automatyków: odpowiedź impulsowa o charakterze całkującym) stała czasowa dla zmiany prądu przyjęta została na poziomie ok. 0,4% / sek.
Dzięki temu proces regulacji następuje stopniowo i płynnie podążając za bezwładnością termiczną układu w sposób niezauważalny dla oka ludzkiego.

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)

Sygnalizacja:

Informacja o przekroczeniu progu temperatury Ta i zadziałaniu ograniczenia wyprowadzona jest na jedno z wyjść cyfrowych, do którego można podłączyć sygnalizacyjną diodę LED.
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.

Kalibracja:

Długo zastanawiałem się jak skutecznie zrealizować możliwość dobierania temperatury progowej Ta przez użytkownika bez konieczności zaszywania sztywnych progów w kodzie programu zwłaszcza, że miejsce pomiaru będzie obarczone gradientem, jak również i termistory mają różne parametry (wsp.temperaturowy - B) i o ile w 25*C ich rozrzut nie jest za duży o tyle w okolicach 80-90*C ich rozbieżność będzie już znaczna.

Postanowiłem więc dodać w konfiguracji sterownika opcję kalibracji, po której wyborze sterownik dokona odczytu bieżącej temperatury i zapiszę ją do pamięci jako wartość progową Ta.
A zatem kalibracja niezależnie od typu zastosowanego termistora oraz miejsca pomiaru (na diodzie, na MCPCB, pod pigułą itd.) polegałaby na rozgrzaniu latarki do indywidualnie akceptowalnej temperatury i dokonaniu zapisu przez sterownik odpowiadającej temperaturze tej wartości.
Natomiast wartość progu Tk może być już obliczana automatycznie np. jako +20% wartości Ta.


Wiem, że moje opisy są miejscami dość mocno techniczne, niemniej jednak zapraszam wszystkich do komentowania opisanego rozwiązania lub zgłaszania innych ciekawych pomysłów.

midi - 15-12-2010, 17:47

Jak dla mnie nic dodać nic ująć, jeśli driver będzie pracował stabilnie i nie będzie miał jakiś małych błędów to będzie to sterownik idealny :wink: , gratuluję pomysłu, z przyjemnością używał bym takich driverów w swoich latarkach.
Pozdrawiam.

swietlik - 15-12-2010, 17:48

Jak zawsze same delicje :)

df napisał/a:

[8] - fade-in/fade-out (nie wiem jak to ładnie nazwać, ale efekt polega na płynnym rozjaśnianiu przez 1s i płynnym przygasaniu przez kolejną 1s)


a to chyba będzie po prostu pulsowanie?

jezjacek - 15-12-2010, 18:00

Moim skromnym zdaniem, latarka powinna mieć trzy tryby słaby, średni i max. Reszta jest zbędna, a cały wysiłek geniuszu powinien iść na pozbycie sie amceków np przez sterowanie pwmem tak aby nie przekroczyć dopuszczalnego prądu diody (aż mnie skręca na myśl, że cenna enargia jest zamieniana w ciepło w amc).
yano - 15-12-2010, 19:16

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.
Cytat:
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
Cytat:
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ą :wink:

df - 15-12-2010, 20:34

Dziękuję za komentarze.
yano napisał/a:
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ć.

Pyra - 15-12-2010, 21:04

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ę ;)

upek - 15-12-2010, 22:31

Cytat:
Hmmm... Super oprogramowanie powiadasz...


Cytat:
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 :twisted:

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

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

Pozdrawiam
upek

lennin - 15-12-2010, 23:22

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 :o

Moje gratulacje Darku.

yano - 15-12-2010, 23:44

Podpisuję się pod tym, co napisał Pyra - wydaje mi się, że dla niektórych użytkowników (np. dla mnie :wink: ) 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 :)

Saul - 16-12-2010, 01:03

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.

df - 17-12-2010, 11:33

yano napisał/a:
Podpisuję się pod tym, co napisał Pyra - wydaje mi się, że dla niektórych użytkowników (np. dla mnie :wink: ) 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.

df - 17-12-2010, 12:21

Saul napisał/a:
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 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?

Saul napisał/a:
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ć.

wojtek_krakow - 17-12-2010, 19:23

df napisał/a:
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 ?

Saul - 17-12-2010, 20:01

df napisał/a:
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.

EdiM - 23-12-2010, 22:23

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.

df - 27-12-2010, 11:24

EdiM napisał/a:
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.

EdiM - 27-12-2010, 18:07

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.

Marcio - 13-04-2011, 07:45
Temat postu: Nedza
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

Kuras77 - 08-01-2012, 19:47

Mam pytanie - czy ten driver jest gdzieś do kupienia? Napisałem PMkę do df ale jeszcze jej nawet nie odczytał a jego ostatnia wizyta na forum miała miejsce 2 października :(
Sid Gotama - 22-08-2012, 17:10

>Kuras77
I jak, otrzymałeś odpowiedz?

Kuras77 - 22-08-2012, 20:04

Niestety nie. Użyłem zmodyfikowanego (350mA) drivera od grega.
connan12345 - 19-12-2013, 18:14
Temat postu: Re: Nedza
Marcio napisał/a:
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

Dzień dobry!
Czytam już kolejny temat jak dobrą książkę. Do tej pory programowałem (i nadal to robię) w BASCOM, C++ jakoś do mnie nie przemawia choć niektórzy mówią że łatwiejszy , może kiedyś przemówi. Co do programowania Attiny ja używam zwykłego pcb wyciętego nożykiem do tapet. A sam układ dociskam klipsem do suszenia . Trzeba pamiętać o czystości połączenia między ścieżkami a PCB. Też się zastanawiałem nad clipem z ebay ale wpadłem właśnie na ten pomysł z PCB. Niby prowizorka ale działa (jak to prowizorka). Tak poprowadziłem ścieżki by zrobić złącze Canda , a programator mam USBtiny bez bufora .
Od jakiegoś czasu kombinuję by zrobić driverka do LED. Potrzeba na dziś to zasilenie 3 diod 3W lub jednej 10W. Co do pierwszej potrzeba 10.5V i 700mA , a co do drugiej 10V i 1A. Nie posiadam jeszcze AMC7135 o którym dowiedziałem się od kolegi z forum-nuras oraz z balastnurkowy.cba.pl .W końcu zamówiłem i czekam .Do chwili aż przyjdą do mnie taki driverek chciałbym złożyć. Czemu nie lepszy jest NE555 tylko Attiny13? Czy tylko ilość elementów na PCB przekonuje nad wyższością tego drugiego? Moje pytanie w związku z tematem to jak ma się "pojemność" cewki , kondensatora do częstotliwości z jaką "biega" PWM ?
Jeśli moje pytania nie w temacie proszę o przesunięcie. Dziękuję i pozdrawiam.


Powered by phpBB modified by Przemo © 2003 phpBB Group