"3-stabilni" klopny obvod

Zpráva

smitke · #1 Příspěvek od **smitke** » 02 pro 2009, 14:39

Zdravim,

potreboval bych poradit s obvodem, ktery deli vstupni signal tremi. Potrebuju to k cernobile kamere, kde kamera trigruje RGB svetla, ty se postupne zapinaji R->G->B->R->G ... a jede to porad dokola (vzdy sviti pouze jedna barva) viz prilozeny obrazek. Presne tak funguje bistabilni klopny obvod, ktery by takto trigroval 2 svetla. Premyslel jsem nakombinovat vic bistabilnich dohromady, ale myslim, ze delitel 3 z toho nikdy nevyleze.

Mohl byste mi nekdo poradit jak na to?

Diky

#2 Příspěvek od **Hill** » 02 pro 2009, 14:56

A co tak kruhový čítač nebo děličku čtyřmi s nulováním při dosažení stavu 3 (výstupy Q1 i Q2 vyhodnotíš hradlem NAND a jeho výstupem resetuješ obvod)?

procesor · #3 Příspěvek od **procesor** » 02 pro 2009, 17:23

To má byť demultiplex? Potom sa to musí aj nejako synchronizovať.
Z tých priebehov to nie je možné. Chýba ešte čosi.

Crifodo · #4 Příspěvek od **Crifodo** » 02 pro 2009, 20:02

posuvný registr, např. 74164. Hodiny jsou ze snímkového impulsu?

smitke · #5 Příspěvek od **smitke** » 04 pro 2009, 09:43

Vstupni signal jde z enkoderu, kde rychlost otaceni je promenliva velicina. (to jsem asi mel nakreslit, ze to nejsou konstatni pulsy) Jediny co je k dispozici je tento input, nelze dale s nicim synchronizovat.
A nebyli by trochu konkretnejsi priklady? treba "kruhovy citac" mi nic nerika... pro me by bylo vysvobozeni nejake schema, protoze sam nic nevyplodim. Dik

Andrea · #6 Příspěvek od **Andrea** » 04 pro 2009, 10:03

Třeba takhle. Ale je potřeba ošetřit ten výstup z enkodéru, aby neobsahoval zákmity.

Crifodo · #7 Příspěvek od **Crifodo** » 04 pro 2009, 17:18

smitke píše:treba "kruhovy citac" mi nic nerika... pro me by bylo vysvobozeni nejake schema, protoze sam nic nevyplodim. Dik

s googlem po ruce mi takové tvrzení zavání alibismem. případně hledej výraz ring counter. Nějaké základy číslicové techniky by to chtělo, aby ses nezastavil na prvním dílčím problému...
Podle zmínky o triggerování R-G-B světla bych myslel že se sekvence spouští elektronicky, ten enkodér zase vypadá na rotující filtr před objektivem, tak jak teda?

procesor · #8 Příspěvek od **procesor** » 04 pro 2009, 18:49

Keď dobre zadefinujem svoj problém, som už krôčik od riešenia. V opačnom prípade sa vzďaľujem...

smitke · #9 Příspěvek od **smitke** » 05 pro 2009, 15:46

Triggerovani se pousti elektronicky, prave z elektronickeho encoderu (dela input signal z mko.gif, napr. pro kamery bezne pouzivany: http://www.rls.si/document/RM22D01.pdf), kterej jednak dela trigger kamere, druhak svetlum. Filtry pochopitelne nejsou potreba, pac jak uz bylo receno, postupne se rozsvecuji RGB svetla (z techto 3 mono-obrazu se slozi jeden barevny).

Ale myslim, ze definici pochopil-a nejlepe Andrea, takze diky, pristi tyden vyzkousim. Jinak diky vsem zucastnenym za cas, pokud bude fungovat schema, je to presne to, co jsem potreboval. Smitke

Crifodo · #10 Příspěvek od **Crifodo** » 05 pro 2009, 18:43

možná jsem se ještě úplně neprobudil, ale ten enkodér který spouští kameru i světla elektronicky, je poháněn čím?

procesor · #11 Příspěvek od **procesor** » 05 pro 2009, 19:44

Na začiatku bola tma. Ten MKO.gif zdanlivo v nekonečnom čase generuje hodiny, z ktorých sú tie tri priebehy, len počiatok by bolo treba občas definovať. Ten by mal byť vtelený aj do tej chytrej Andreinej sch.
Ešte sa tu niekto bude postupne budiť :wink:

Crifodo · #12 Příspěvek od **Crifodo** » 05 pro 2009, 20:55

mně jen pořád nedochází, k čemu je v zařízení kde nic rotujícího není, rotační enkodér který začíná někde na 80,- euro...

smitke · #13 Příspěvek od **smitke** » 05 pro 2009, 21:05

No ok, jestli vas to tedy stale jeste zajima, muzu vam poskytnout trosku vic detailni vysvetleni. Snazil jsem se jen, po uspesnem vyreseni, co nejrychleji ukoncit toto tema, aby se to tu zbytecne nezahnojovalo (zvyk z jinych for)

Line-scanova kamera jede na linearnim posunu z bodu A do bodu B (sirka scanu x vzdalenost AB = format scanu, napr. 8192x20.000 pixelu) rychlosti v radu desitek centimetru za sec, pricemz dela pocet scanu v radu jednotek/desitek tisic za sekundu. Pri posouvani se otaci kolo od enkoderu, ktery dava cca 4-10x vice pulzu nez je triggeru do kamery (v obrazku mko.gif uz jsou pouze pouzite pulsy pro trigger). Ted delam barevnyou obraz na trikrat - nejdrive s R, na zpatecni ceste s G, a znovu s B-svetlem. Nyni jsem chtel zarizeni vylepsit tak, ze se bude pri 1/3-nove rychlosti skladat barevny obraz rovnou pri switchovani svetel.

Nevim, jestli je to pravda (?), ale myslim, ze hodinam se rika konstatnimu prubehu signalu. Signal z enkoderu konstantni neni, protoze pri tomto rozliseni (v radu jednotek/desitek micrometru/pixel) ani velmi kvalitni lineary neudrzi konstantni rychlost (pri eliminovani rozbehu/dobehu)

Pripadne dalsi diskuze bych navrhoval pres SZ ale nevim, jak to tady chodi, jsem tady novacek... :wink:

Crifodo · #14 Příspěvek od **Crifodo** » 05 pro 2009, 21:20

Zahnojováním tématu se netrap, zahnojuje se tu mnohem horším balastem tohle je aspoň technické téma.
Jestli tomu rozumím tak se ti jedná o nějakou obdobu snímací lišty skeneru, který kvůli lepšímu rozlišení neobsahuje dichroické filtry pro r-g-b pixely a skenuje jen v č/b a ty se snažíš upravit firmware na 1 průchod. Ten posun není odvozen od impulsů pro krokový motor ? to je přece nejpůvodnější zdroj hodin a mechanika posuvu by ho měla udržet, jestli má adresování odpovídat skutečnosti.
I když rychlost konstantní není, ten dělič třemi není s ničím synchronní takže ani nerovnoměrný pohyb nebude vadit, jen se bude měnit doba po kterou bude v akci příslušná barva světla, pokud to nevadí expozici.

smitke · #15 Příspěvek od **smitke** » 05 pro 2009, 21:51

Duvod neni nepritomnost filtrovaci mrizky (resp. dalsich dvou radku - nejpouzivanejsi zpusob barevneho scaneru - trilinear) ale je zcela prozaicky: maximalni velikost soucasnych RGB line-scanovych chipu je 3x4k pixelu (mam ke zkouseni 3x12k, ale radsi se neptej na cenu..), kdezto CB chipy jdou vyrobit takrka "neomezene" dlouhe; a taky cena.

Vetsinou se pouziva samostatny enkoder pro kameru, takze ten bezi uplne nezavisle na krokovani linearu. At uz kvuli cca 10x vetsimu rozliseni, nez co je standartne dodan k linearu, tak at uz kvuli ruseni. Ale mas pravdu, ze by to z toho bezelo taky.

Jinak poznamka o hodinach byla jen ze mi vrtalo hlavou, zda-li se nemysli hodinama vzdy konstantni prubeh. Ja vim, ze toto nebude mit vliv. Tady je nabiledni prave otazka, zda-li vadi delka output pulsu.

Existujou v podstate dva systemy: s nastavitelnou pevnou expozicni dobou (s temito systemy obvod fungovat bude) a s expozicni dobou zavislou od prichodu dalsiho pulzu (s temito systemy fungovat nebude, nebo resp. pri pomalem scanu bude jasnejsi obraz) a nastavuje se prave delkou osvetleni, coz se u normalniho, jednoducheho osvetleni resi delkou strobe signalu. Ale protoze nejsem zadny zkuseny elektronik, pro jistotu me radsi ani nenapadlo, ptat se na obvod, kde se bude jeste nastavovat pevna delka vystupniho pulsu (asi by se to poradne zkomplikovalo) ...