Protecţii amplificator cu micro-controller.

[Mircea]

Astea sunt accesorii, dar se pot implementa.

 

Ideea e de conceput ceva care are suficient hardware pentru alte optiuni, idei care vin mereu dupa.

Astea sunt accesorii, dar se pot implementa.

 

Ideea e de conceput ceva care are suficient hardware pentru alte optiuni, idei care vin mereu dupa.

 

Pe tema LED-urilor, ca sa nu facem "semafoare" pe panoul frontal. Se poate si bi, si tri (3 culori numai), dar si RGB (cate culori vrei).

 

Care sunt "standardele" de semnalizari cu LED-uri?

Editat Ianuarie 4, 2018 de thunderer

[hpavictor]

Cred că îmi pierd vremea pe aici , funcțiile principale au fost enumerate și nu e cazul sa le repet .

Cine are chef să descopere America , e liber să o facă .

Chiar vă e lene să citiți lista cu funcțiile unei protecții universale ?

Dacă implementezi hardware toate detectoarele , restul poate fi înlocuit cu un banal 555 .

Eu am studiat foarte multe scheme de protecții , am descoperit avantajele și dezavantajele fiecăreia dintre soluțiile folosite de majoritatea proiectanților de HiFi sau AudioPro .

uC poate ajuta la comanda personalizata a LED-urilor , în rest e overkill pentru cei cu așteptări mici de la viață .

Îmi pare rău că nu mă pricep la scris software ...

Dacă nu se baga nimeni la uC cu intrare ADC pentru FFT , eu am alte treburi .

Mai gândiți-vă , de obicei nu mă răzgândesc .

[hpavictor]

Pentru cei ce nu au priceput cum stă treaba cu detectoarele hardware , pot înlocui Q3 cu un microcontroler și un software care să aprindă eventualele LED-uri .

 

 

Spor la treabă !

[Sharky]

Da, poate de aia ar fi bine sa nu dai sfaturi in directia asta.

O lista de chestii nu ajunge. Vrei ceva munceste!

Cine vrea sa continue, sa ia lista sa descrie un use case, pt fiecare caz, ca omul care implementeaza sa stie ce face.

e.g.:

- DC(asta e cam evident, dar) apare DC mai mare de xV pt y secunde => avarie

- SOA: mai multe use case aici:

- atingerea unui prag maxim => avarie

- atingerea unui prag cu integrare in timp (reglabil) si variabil in functie de temperatura => avarie (scenariu super simplicat, trebuie elaborat)

- etc

- conditia de avarie: -> decupleaza releu, aprinde led eroare, taie alimentarea, logare status senzori, suna 112, etc.

Apoi vedem ce implementam, cum e mai simplu, cum e mai complex.

Si da, treaba cu FFT mare lucru nu aduce.

Mai bine faci "FFT" cu niste filtre analogice si un prag reglabil de activare a unei intreruperi, sau citirea pur si simplu a nivelului cu un ADC si luarea unei decizii.

Un filtru analog nu da gres, e usor de simulat, in special de unul care e total paralel la programare.

Setezi un prag, un delay, astea fiind programabile, dar restul analogice.

Pui filtre pt detectie DC, HF.

Acopera fara probleme ceea ce vrei si poti vrea.

Crede-ma, ce e simplu e mai bun!

Plus ofera o dezvoltare rapida a produsului iar dupa ce toate problemele se pun la punct si produsul merge se poate trece pe full FFT sa vedem daca ofera un avantaj real.

Si cu FFT ce crezi ca iese? Crezi ca cineva iti face tie o interfata ca in multisim cu care sa te joci cu protectia ca un baron?

HAHAHA! Doar aia in sinee un proiect infinit mai elaborat decat o banala protectie.

Doar daca gasesti tu ceva gata facut si o modalitate simpla sa treci de la un grafic la niste valori cheie pt FFT. Posibil sa existe o asa biblioteca.

Pe de alta parte sa nu crezi ca esti singurul care a auzit de protectii in amplif sau alte chestii care sunt prezente si in cea mai banala combina muzicala, dar nu in echipamente audiofile.

Hai las-o-ncolo de treaba si de aere.

Vrei ceva te implici, nu mai tot da ordine ca nu face nimeni pt tine asta asa de-a gratis, doar sa nu te oftici tu.

Spui ca acest proiect nu e pe masura acestui forum, ce sa zic, mai degraba atitudinea ta nu e deloc demna pt un semenea proiect.

Ma rog, poate asa e la tine la lucru, vine seful, urla 3 fraze si voi va bateti capul sa intelegeti ce naiba vrea.

Dar ghici ce, aici nu se aplica.

[Mircea]

Cred ca e timpul de citit un pic despre FIR/IIR si FFT. O sa vad ce timp imi gasesc.

[hpavictor]

Nicio problema .

După ce îți faci o idee cum ar trebui abordată problema , putem discuta ce și cum .

Se pare că " unii " au un dinte împotriva acestui subiect .

[Sharky]

Nu e dinte, e realism!

Pt ce e nevoie din cele scrise de tine toata treaba se rezolva analogic la fel de bine.

Si nu, nu o faci la fel cu 555 sau ce mai vrei tu.

Toata ideea la uC e ca totul e configurabil f usor.

De aia as merge pe o solutie si un OS cat mai popular si cu cat mai multe extensii/utilitare de-a gata, gen arduino.

Timere reglabile din tastatura, nu din trimmere, prag de DC tot asa, prag temperatura, logari, etc.

Ce telecomanda si LCD care oricum il pui tot tiganeste arata. Poti lega toata treaba la smartphone relativ simplu si ieftin?

Ca sa nu zic de HDMI si audio prin bluetooth care poti fi adaugate f usor. Nu ca ar fi ceva de calitate, dar e al naibii de util, oricat de audiofil te dai.

Eu in directia asta mi-as consuma energia daca tot vb de un controller.

Eu asta as face in prima faza pt ca se face repede si iese ceva, o platforma, de acolo dezvolta fiecare ce vrea acasa.

PIC-uri si alte chestii preistorice nu sunt productive si nu incurajeaza colaborarea.

E mult de lucru, abordabil de putini oameni, greu de intretinut/dezvoltat ulterior.

Apoi ca si POC se poate reimplementa totul cu FFT si testa in paralel.

In mod sigur sunt ceva biblioteci gata facute si iti usureaz munca, dar vreau sa vad un singur avantaj palpabil al FFT fata de detectia analogica care nu da gres niciodata.

Chiar si de da Tudose un OUG nu schimba legile fizicii.

Eu as incerca ceva in genul asta:

https://learn.adafruit.com/fft-fun-with-fourier-transforms/spectrum-analyzer

https://processing.org/reference/libraries/sound/index.html

Roata a fost inventata deja. Dar daca te simti jupan poti inventa una mai rotunda decat actuala.

Poti sa nu te razgandesti, is curios la urma ce iese.

Chiar daca te superi abordarea ta e f naiva si agatata puternic in trecut.

In general nu e nimeni impresionat cand tragi cu tunul dupa pasari intr-un proiect fara vreo utilitate cu tehnologii si abordari expirate.

Success!

[hpavictor]

Uite un exemplu clasic de protectie cu uC , care realizeaza doar functiile de baza :

- manualul service : http://docdro.id/T2OGFCH

- schema : http://docdro.id/qOI3dS8

Reprezinta o cale simpla , o buna sursa de inspiratie pentru incepatori .

Se pot imbunatati etajele de detectie , dar mai intai astept dialogul constructiv pe tema schemei de mai sus .

[Mircea]

@Sharky, eu ti-am inteles punctul de vedere de la primul mesaj. Nu ti l-am considerat inutil sau preistoric (555, tu glumesti?!).

 

La a doua interventie ai devenit off-topic batand apa in piua.

 

La al treilea ai inceput sa trollezi topicul. DSP-uri preistorice? 555 de actualitate?

 

Esti in masura sa dezvolti o solutie magica cu 555? Nu te retine nimeni, doar deschide alt topic. Dar sa fie unul in care vorbesti despre ce stii.

[Sharky]

Dacă implementezi hardware toate detectoarele , restul poate fi înlocuit cu un banal 555 .

De aici duma cu 555.

2:

Cand te apuci de ceva in primul rand stabilesti clar ce e de facut.

Daca asta se cheama a bate apa in piua, cum consideri.

I-am atras atentia lui Victor, dar tot se plictiseste, ar putea detalia mai mult cele 7 randuri care chipurile sintetizeaza functionarea.

Decat sa puna link-uri si dume cum ca uC e pt comanda ledurilor.

Ar fi f util cuiva care se apuca de lucru.

Postul 3:

Mi se parea ca o platforma gen arduino e mai ok, plus niste exemple pt asa ceva. Imi pare rau daca asta incurca.

Ca sa nu zic ca loc de dezvoltare e din belsug si biblioteci gata facute.

Mai departe decat mici experimente nu am facut, dar candva oi avea timp si de astea.

De la o simpla protectie poti inclusiv sa extinzi la redat manele de pe sd si sa sparga seminte. (se intelege ca asta e o gluma, pt exemplficare)

Preistorice erau niste referiri la protectie cu PIC. S-a discutat initial despre asa ceva.

DAca asta inseamna troll, atunci ce sa mai zic de interventiile lui victor?

[Mircea]

@Sharky, in afara cazului unde alegi un Arduino Due sau Yun (care costa - originalul -

intre 50 si 100$ bucata) cu restul de Arduino nu faci FFT decat la 2-3kHz.

 

Cata vreme nu ajuta topicul, este inutil, adica off, adica troll daca se persista.

 

Iti apreciez munca si prestatiile pe forum, dar problemele tale cu alti colegi de forum nu sunt interesante pentru mine.

[Sharky]

Ar fi ok si asa.

Pana la urma ce speri cu acel FFT?

(Si dintr-o data postul nr2 in care am insistat pe specs capata sens.)

Oricum spor la treaba, de o iei de la zero o sa ai de lucru nu gluma.

E cod pe github, ai o baza buna de pornire.

[Mircea]

Nu pornesc de la zero. Am biblioteci si pentru filtre, dar si pentru FFT.

 

Ce urmaresc: sa invat ceva nou. Tu crezi ca eu am nevoie de o protectie de amplif? In schimb am ceva curiozitati de satisfacut.

[hpavictor]

Sharky , iti multumesc din nou pentru parere .

Ca sa-ti fac pe plac , voi proceda exact pe dos , deci nu voi dezvolta nimic legat de tema FFT , nu eu am propus-o si nu imi apartine .

Eu am mentionat doar masurarea frecventei semnalului de pe iesire , urmand ca uC sa ia o decizie in functie de nivelul , frecventa si durata semnalului considerat periculos pentru incinte .

Pot intelege ca nu ai inteles la ce ma refer , deoarece nu au inceput discutii despre cum trebuie abordate cerintele din lista de functii prezentate anterior .

Nu uita : eu nu raspund la intrebari nerostite si nu raspund provocarilor unor anumiti useri , se stiu ei .

[hpavictor]

Și eu sper să iasă din prima .

Aștept dialogul constructiv al celor care au ceva cu adevărat de spus , mă refer la cei ce au citit deja lista de funcții propusă anterior .

Restul vor fi ignorați din start , nimeni nu își poate pierde vremea cu cei ce nu pricep despre ce discutăm in subiect ...