"3-stabilni" klopny obvod

[smitke]

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

[Hill]

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)?

[Hill]

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]

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]

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

[smitke]

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]

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

[Crifodo]

[procesor]

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

[smitke]

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]

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]

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ť

[Crifodo]

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]

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...

[Crifodo]

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]

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) ...