Stand-by - DC detect - delay - temp

[tomekk_]

Dobry.

Jeśli ktoś potrzebuje stand-by + parę podstawowych zabezpieczeń, to wrzucam na forum.
Modyfikujcie jak chcecie.

Układ realizuje
- stand-by (na włączniku bistabilnym niskie napięcie)
- delay (opóźnione podłączenie głośników/szybkie odłączenie)
- DC detect (detekcja napięcia stałego w dwóch kanałach)
- temp (zabezpieczenie termiczne na termostatach bimetalicznych


Krótko.
Układ oparty na attiny2313 - tak więc można sobie dowolnie zmienić zachowanie itd.

Stand-by - to tak naprawdę przełącznik pomiędzy trafem i mostkiem, ultra proste, bezpieczne niezawodne.

Delay - programowe 3 sekundowe opóźnienie podłączenia przekaźników wyjść głośnikowych.
Układ posiada wspólny punkt masy na płytce, który należy połączyć z masą centralnie w układzie.

DC detect - układ realizowany na oklepanym układzie:

Jeśli wszystko jest OK to stan wysoki na pinie AVR jest utrzymywany, w przypadku detekcji - stan niski.
Kondensatorkiem można w pewnym stopniu wpływać na czułość.
Układ może łapać false positive'y z układami lampowymi podczas startu - trzeba by poprawić soft.

Temp - to naprawdę dwa wejścia na płytce, które trzeba zewrzeć - obojętnie jak - stosując tanie termostaty bimetaliczne możemy zrobić sobie zabezpieczenie termiczne - mega proste i niezawodne, bez dobierania rezów czy programowania 1-wire (zwarcie pinow w X2/X3 uruchomi TEMP alarm - również dobrze można te termostaty podłączyć równolegle i użyć tylko jednego X2 bądź X3 , a drugie wejście oprogramować pod inne zabezpieczenie czy zewnętrzny trigger):


Układ zbudowany na powszechnie dostępnych elementach i lutuje się wygodnie bo THT ;-)
Na płytce gniazdo IDC10 żeby wprost na płytce programować sobie układ.

Układ wielkości 10x10cm mam w planach zrobić do niego piętrowego shield'a z podstawowym EMI, DC blockerem i Soft Startem.

To chyba tyle.
Have fun.

Uwaga to DIY, nie ma gwarancji na nic ;-)

W załączniku projekt eagle, gerbery, soft i BOM.

standby-delay-dc-temp.zip

[LuSzTi]

Podrzuć schemat w PDFie :) Albo jako obrazek :)

[tomekk_]

Sure thing!


W zalaczniku w PDF.
Elementy w BOMie.

schemat.pdf

[tomekk_]

[tomekk_]

Jajca, te dwa PADy od konektora płaskiego nie SA połączone na PCB, zalejcie sobie cyna - tylko ten konkrety.
Myślałem ze ten element w bibliotece jest połączony domyślnie, jako ze to element jednego konektora płaskiego - jednak nie - tak wiec pamiętajcie:


Gerbery są poprawione - zabawne ;-)
Pisze to dla osób, które dostaną płytki niebawem żeby nie było zdziwienia.
Oczywiście po przylutowaniu konektora problem znika - jest tylko wtedy gdy ktoś sobie na krótko przylutuje.

[tomekk_]

Drobny update w BOM - podalem zle gniazdo do programowania uC.
Wybaczcie, teraz powinno byc ok.

[tytka]

A nie myślałeś o tym, aby układy detekcji napięcia stałego na wyjściu wzmacniacza podłączyć do wejść przerwań zewnętrznych kontrolera? I obsłużyć tą procedurę z przerwania?
Ja chyba poszedł bym w tym kierunku.

Wiem powiesz pewnie, że się czepiam, bo pętla programu krótka i porty szybko i często skanowane, ale przerwanie dawałoby chyba większą gwarancję szybkości zadziałanie tego zabezpieczenia.

[tomekk_]

Kondensator, ktory jest na wejsciu tej analogowej detekcji daje większego laga niz ten program.
Zas bez konda, jest to za czule i glupieje.

[tytka]

Bez kondensatora, to chyba trzeba by mierzyć czasy, a to bez sensu.

Piszesz, że ten kondensator wprowadza większe opóźnienie, niż pętla programu i tak jest. Rozumiem Twoje racje, szanuję pomysł i wykonanie.

Aczkolwiek sam tworząc coś podobnego, poszedł bym inną drogą, bo:
1. - takie rozwiązanie jak zrobiłeś, powoduje że czas zadziałania składa się z trzech składowych: czasu opóźnienia na kondensatorze, czasu skanowania portów, czasu realizacji procedury wykonawczej; a przy wykorzystaniu przerwania, ta druga składowa byłaby wyeliminowana (mała różnica, ale jednak jest);
2. - przerwania zewnętrzne zostały wymyślone dla rozwiązań gdzie ważny jest priorytet i wręcz się proszą, aby ich tu użyć.

[sylvester]

Myślę, że nie ma co kruszyć kopii o przerwania do tak trywialnego programu, kiedy można zmodyfikować pętlę główną żeby praktycznie cały czas wisiała na sprawdzaniu stanu portów. Czas reakcji będzie wtedy i tak znacznie mniejszy niż okres sygnału 20 kHz...

Bardziej skupił bym się tutaj na zapewnieniu, że cały program nie pójdzie w maliny, m.in. włączając Brown-Out detector poprzez zaprogramowanie fuse bitów BODLEVEL i może dodając obsługę watchdoga.

[tomekk_]

Wysyłam Wam za fraje po jednej płytce i lecicie z softem ;-)

[tytka]

He, he, wielkie dzięki.
Aby napisać soft według swojego pomysłu nie potrzeba mi tej płytki.

Myślę, że nie ma co kruszyć kopii (...)

A kto tu kruszy kopie??
Forum chyba jest także po to, by móc wyrazić swoją opinię, a nie tylko przyklaskiwać.
Czasami przedstawienie swojego zdania, a nawet konstruktywnej krytyki jest bardzo przydatne, dla autora projektu jak i śledzących wątek. Taka sensowna dyskusja na temat, powoduje, że kolejne projekty wykonuje się jeszcze lepiej.

No, chyba, że to forum tego nie toleruje.

[sylvester]

Wysyłam Wam za fraje po jednej płytce i lecicie z softem ;-)

I o to chodzi, wszystko jest udostępnione nic tylko usprawniać Jeszcze mam gdzieś usbaspa na płytce uniwersalnej i jakiś układ testowy z atmega8, tylko z czasem słabo, zawsze coś na kolejce todo wisi :/ Gdybym miał się bawić w taki układ stand-by to chyba raczej na module ESP32, żeby moc sterować z resztą rzeczy po MQTT, w openhab2 np.

Czasami przedstawienie swojego zdania, a nawet konstruktywnej krytyki

Moim zdaniem próbujesz rozwiązywać problem tam gdzie go nie ma. Sygnał na wejściu jest filtrowany dolnoprzepustowo, tak aby odciąć nawet najniższe częstotliwości w sygnale audio. Więc z racji tego sygnał z detektora jest stosunkowo wolnozmienny (czas reakcji rzędu 50 ms). Nie ma większego znaczenia, czy zrobimy tutaj polling w pętli głównej czy zastosujemy przerwanie INTx, różnica w czasie reakcji będzie rzędu pojedynczych mikrosekund. Tomek dodał opóźnienie w pętli głównej i próbkuje piny co ok. 100 ms, żeby pozbyć się false positivów. Można by to usprawnić próbkując częściej i odłączając głośniki dopiero, gdy w kolejnych próbkach będzie ciągle stan niski, coś jakby de-bouncing. Z powodzeniem można to zrobić w pętli głownej, AVR jest stosunkowo szybki. W przerwania można by oczywiście się bawić, trzeba by pewnie wówczas użyć też jakiś timer do generowania podstawy czasu. Nie widzę wyższości takiego rozwiązania. A inne koncepcje to w zasadzie osobny temat.

[tytka]

Moim zdaniem próbujesz rozwiązywać problem tam gdzie go nie ma.

Tak próbuję, nawet bardzo.
Zauważ, że nigdzie nie stwierdziłem iż moje podejście jest lepsze.
Zapytałem tylko autora, czy nie myślał o zastosowaniu przerwań sprzętowych. Napisałem też (co jest prawdą), że szanuje jego podejście i wykonanie. Jednak pozwoliłem sobie stwierdzić, że ja podszedł bym do tego inaczej, ale nikomu tego nie narzucałem, ani nie narzucam.

Przepraszam, że zabrałem głos w temacie i go zakłóciłem, już się wyłączam z niego.