verlichtingsschakeling voor kunstwerk

Mechanisch lijkt me geen reeele optie. Te veel kinderziektes (heb wel een nieuw model gebouwd met veerstaal).

Ik dacht eigenlijk dat de micrcontroller al helemaal werkte. Heb ik dat verkeerd begrepen?

Wat betreft de analoge oplossing hebben we het dan over jouw linker schema van een 30mei 13.25. Deze werkt helemaal goed?

Als beide het doen kan ik mischien de analoge gebruiken in de testopstelling en van de digitale een tegel maken. Kan ik later wat testen meedoen en de verschillen laten zien.

Dat zou mischien nog wel de beste oplossing zijn.

Het schema van 30 mei 13:15, en dan de linker, inderdaad.

Die doet het bij mij prima, al kan ik moeilijk beoordelen hoe de gevoeligheid is vergeleken met de microcontroller.

De schakeling van Lucky Luke werkt wel, geloof ik, maar ik betwijfel of het haalbaar is dat je daar, zonder hulp, binnen 2 weken 25 stuks van kunt produceren, aangezien je ook nog even moet leren met die programmer om te gaan en zo.

Aan jouw de keus, zeg het maar.

Als je nog moet leren programmeren (de taal dan) dan is het waarschijnlijk onmogelijk maar het programma is er al. Een programma in een AVR schieten heb je wel snel onder de knie op voorwaarde dat je die AVRISP mkII hebt (of een waarvan je zeker bent dat er geen problemen mee zult hebben)

Misschien effe prijs analoog/digitaal vergelijken? Dus hoeveel kost alles samen tussen de LED's en de buzzer? €1 Verschil scheelt hem toch al €25 en dat voor een proefopstelling die nadien toch niet voor de eventuele uitbreiding kan gebruikt worden, die zal er waarschijnlijk toch anders gaan uitzien.

Ik heb morgen examen wiskunde, en daarna in principe vakantie. Dus daarin kan ik in dit topic wel uitleg geven hoe en programma in een avr te schieten (dat kunnen een hele hoop andere CO'ers ook, er zijn best veel AVR mensen, en de meeste zijn beter dan ik.). En nog wat aanpassingen doen aan het printje en evt. het programma.

Het programma in de AVR wat er nu staat werkt gewoon (doet wat het in het filmpje doet), en is dus in principe af (het doet wat er in de startpost staat). Of het in de attiny13 ook werkt heb ik alleen niet kunnen testen (ik heb geen attiny13). Ik verwacht echter dat het wel zal werken. Mocht je later meer functionaliteit willen, dan kan iedereen die bekend is met BASOM je helpen. De vraag is of ze dat ook allemaal willen, maar ik vind dit iig een leuk project, dus zolang het niet te gek word, wil ik wel helpen. Mits je ook echt wat met dat programma doet natuurlijk.

Wat betreft kostprijs... Je zult zelf even moeten kijken wat de onderdelen kosten, en printje e.d.

Wat betreft flexibiliteit: de digitale oplossing is denk ik het makkelijkst aan te passen.

En een programma in een AVR schieten is ook niet echt lastig. Je sluit de programmer aan op je computer (heb je een parallelle poort?, dat hebben de meeste, en ook de goedkopere AVR programmers nodig. Er zijn er ook die op USB werken, hoeft ook niet echt duur te zijn, laatst nog een SK (samenkoopactie, zie samenkopen.net) van geweest), je start de bijbehorende software, opent de .hex file ermee, sluit de avr aan op de programmer (meestal via de ISP / ICSP header, anders zet je de AVR in een voetje), je klikt op een knopje "load" of "flash" oid, afhankelijk van welke software je gebruikt, en enige seconden (minuten bij erg grote files en lage kloksnelheden) later zit je file in je AVR en klaar is Kees.
Ikzelf gebruik avrdude onder linux in type iets in de terminal (er is wel een GUI, maar had niet echt tijd die op te zoeken en dit werkt ook), dat lijkt in het begin lastiger maar heb je ook na 2x wel door.

Dat de microcontroller voor het eindproduct de meeste mogelijkheden biedt, stond niet meer echt ter discussie, geloof ik. Het ging nu om de korte termijn: de presentatie.

Mijn schakeling bestaat, naast de buzzer, LED en voorschakelweerstand, nog uit 2 weerstanden, 2 transistors en 1 condensator. Dit kost samen nog geen 50 cent.

De ATTINY13 kost, bij een afname van 25 stuks, 1,26 euro per stukk bij Farnell.

Dit prijsverschil lijkt me zo klein, dat het weinig uitmaakt voor de uiteindelijke keuze.

Beide ontwerpen kunnen zonder al te veel moeilijkheden op experimenteerprint opgebouwd worden; een printje is leuk, maar in dit geval absoluut niet nodig.

Of je nu een 8-pins microcontroller met 2 weerstanden en een transistor op een printje zet, of een de 5 onderdelen van mijn schakeling, maar ook erg weinig uit.

Het voordeel van de analoge schakeling is dat je geen programmer nodig hebt, en daar dus ook niets mis kan gaan. Daarnaast heb je maar 1 voeding nodig.

Het grootste voordeel van de microcontroller lijkt me, dat je er ook na je presentatie meer verder kunt, door een nieuw programma te laden, en eventueel pinnen aan te sluiten voor de datacommunicatie.

Daar komt natuurlijk wel weer bij dat ik de analoge versie zelf wel erg elegant vind, en het gewoon jammer vind om een computer te gebruiken om een LED te laten knipperen. Voor mijn gevoel is dat zoiets als een prachtige antieke stoomlocomotief helemaal reviseren, en er dan een computergestuurd stoom injectie systeem op maken. Het klopt gewoon niet.

[Bericht gewijzigd door SparkyGSX op (13%)]

Goed nieuws, de tegel wordt iets groter. Dit betekent 13 tegels voor het proefmodel en veel minder werk!

Ik denk dat ik op termijn wel wil leren hoe je een controller programmeert. Lijkt me best leuk om te kunnen. Voor nu wil ik eigenlijk met beide opties aan de slag.

@ sparky
Ik wil de analoge versie vanavond / morgen even bouwen, kan ik het zelf zien ervaren (ook niet onbelangrijk). Heb al even gezocht maar kan niet vinden welke waarde de verschillende onderdelen hebben. Zou je dit kunnen posten?

@ lucky luke
succes met je examen, vwo?

Ja, VWO. Ging wel goed :)

Een computer om een led te laten knipperen is inderdaad wat overkill, dus het zou leuk zijn 'm ook wat meer computerdingen te laten doen. Dus extra effectjes etc. die analoog lastig of niet voor elkaar te krijgen te zijn. Anders is analoog inderdaad eleganter.

Nou kan die attiny13 ook weer niet alles hé, het is geen corei7 met 8 GB ram... het is een 8 bittertje met 64 byte ram, 64 byte (eep)rom, en 1 kword aan programmageheugen. (en dat is zelfs voor een microcontroller nogal weinig) Hij kost dan ook maar 75 cent, dat is bij Niels Woelders, want als je 25 (of 13 dan) attiny13's en een flinke berg leds nodig hebt vallen de verzendkosten uit china wel weer mee. Farnel zal ook wel verzendkosten rekenen...

Een echte print is niet strikt noodzakelijk, en gaatjesprint is goedkoper. Maar ik ben persoonlijk gaatjesprint een beetje zat, zeker dat fenolpapier, dat stinkt. En dat andere (glasvezel versterkt epoxy) is weer niet lekker te snijden/breken. Ik zou gaatjesprint voor 13 stuks niet aanraden. Het is mogelijk met wat doorzettingsvermogen, maar je bent het na de derde echt wel zat. Misschien als je nog nooit gesoldeerd hebt en het leuk blijkt te vinden pas na de 12e maar je wordt het een keer zat.

Damn, ik was straks bezig met het lijstje van de onderdelen toen ik werd gestoord. Hier alsnog:

De NPN tor is een BC337, de PNP een BC327 (resp. BC547 en BC557 werkt waarschijnlijk ook wel). De condensator is 4.7uF. De basisweerstand van de NPN transistor is 1k2. De weerstand die parallel staan aan het piezo element is 33k. Vooral deze laatste is nogal op de gok gekozen (dat was de eerste van meer dan een paar k die ik op mijn bureau zag liggen), en deze heeft waarschijnlijk wel een redelijke invloed op de gevoeligheid.

Ik zal straks even een poging doen met een potmetertje, om de bekijken wat de invloed precies is.

Ik heb al heel lang de mogelijkheid om printen te maken, maar werk nog steeds graag met experimenteerprint. Gaatjesbord vind ik irritant, maar de printen met steeds 3 gaatjes per track, of steeds een setje van de en dan 2 losse pads vind ik ideaal. Je kunt heel snel dingen veranderen.

Het probleem van een groter aantal produceren zie ik ook niet echt; je steekt in 1 keer alle onderdelen op de print, gaat er in razend tempo langs met een hete bout en een rol tin, knipt vervolgens alle draadjes af en pakt een kleine ijzerzaag om het van elkaar los te zagen.

[Bericht gewijzigd door SparkyGSX op (31%)]

Bedankt voor de waarden, winkel was toch al dicht geweest dus dit is vroeg zat. Ga morgen bouwen. Ben benieuwd hoeveel tijd ik er aan kwijt ben.

Die ene weerstand kan ik later eventueel wel veranderen.

Ik heb een mailtje naar Niels gestuurd, hij kon de printjes (op tijd) etsen. Als ik weet wat het wordt dan ga ik oefenen met het tekenen van een printplaat. Ziet er lekker profi uit (ook belangrijk) en scheelt mij eem hoop frustraties ;)

De variaties die jullie noemen ken ik niet maar daar ga ik ook even naar kijken. misschien ook best oke voor deze kleine serie.

@ lucky luke, cool... Geslaagd??

Als het de controller zou worden denk ik aan de golf effecten (eventueel met botsen), wisselen van kleur (rgb leds) en misschien ook wel een soort van programma's (bv lopend licht over de volle breedte, etc...

Dan heb je (als ik je goed begrijp) niet voldoende aan de controller die ik gevonden heb. Wat zou je dan nemen (hoe groot is ongeveer nodig)?

@SparkyGSX:
Die onderdeeltjes heb ik ook liggen gelukkig :) Kan ik de analoge versie ook eens proberen. Ik heb dus 1M parallel aan de piezo, maar de ADC van een attiny is wat anders dan de basis van een tor natuurlijk.

@Scotch:

Op 2 juni 2009 21:37:25 schreef Scotch:
Ik heb een mailtje naar Niels gestuurd, hij kon de printjes (op tijd) etsen. Als ik weet wat het wordt dan ga ik oefenen met het tekenen van een printplaat. Ziet er lekker profi uit (ook belangrijk) en scheelt mij een hoop frustraties ;)

Betekend dat dat ik geen aanpassingen meer hoef te maken aan het printje wat ik gepost heb, omdat je dat zelf doet?
Of betekend het dat je het onaangepaste printje al naar Technojunk gestuurd hebt? In dat laatste geval zul je dus nog wat onderdelen erbij moeten zien te proppen en krijg je een klein probleempje met programeren... (er ontbreken nog 2 onderdelen op het printje, en er is geen ICP header. Er zijn ook nog geen headers-voor-het-geval-dat, trouwens.

Of ik geslaagd ben hoor ik later, dan trap ik het bijbehorende geslaagd topic wel omhoog (als een ander me niet voor is). Maar volgens mij ging alles wel goed :).

Botsen van golven... Geen idee hoe ik dat voor elkaar zou moeten krijgen... RGB is makkelijker, hangt af van wat je wilt. Simpelste is dan een controller met 3 hardware PWM kanalen (volgens mij had de attiny2313 dat... kijkt ff het zijn er zelfs 4). Met minder hardware PWM kanalen kan het ook, maar dan moet je software PWM gaan doen. Dat kan, maar hardware is makkelijker en tenminste zeker weten flikkervrij.

De demoversie vanBASCOM gaat tot 4KB , dus dat is eigenlijk het maximum. Voor het ontwikkelen een controller met 4K pakken, dan heb je gewoon veel ruimte om te prutsen. Voor de "productie" dan gewoon de goedkoopste controller met voldoende geheugen pakken, die verder ook voldoet qua PWM kanalen etc. Die attiny2313 heeft dacht ik 2K geheugen. O wacht, dat zijn wel 10-bit words, terwijl bascom 4k Byte zegt... Ik hoop dat ze word bedoelen...

Goedemorgen trouwens.

Ik heb het printje wat jij getekend hebt naar Niels gestuurd als voorbeeld, kon hij vast even kijken. Wil zelf proberen een print te ontwerpen als het nodig is.

Die komt hier dan weer ter controle ;)

Kan ik de controller (grote) versie nu ook bouwen? Volgens mij is die nog niet compleet in schema getekend. Dan wil ik hem graag maken met 4 LED's

Je bedoeld met de attiny26? Daar heb ik geen schema van, verder kun je 'm bouwen. Ik wil evt. wel een schema maken.

ik bedoelde met de controller die je in eerste instantie gebruikt had. Was dat de 26?

ja. Schematje:

http://www.uploadarchief.net/files/download/stamptegelschema_t26.png

Ik noem het maar stamptegel. In de praktijk zal je niet echt hoeven stampen, maar tegel-die-licht-gaat-geven-als-je-er-op-gaat-staan(enz.) werd een beetje te lang.

thanks, ga eens even kijken of ik deze controller hier in de stad kan krijgen

Die 4k beperking is wel erg weinig, maar ik geloof dat een licentie van BASCOM ook niet bijzonder kostbaar is. Ik heb wel eens projectjes gehad die, zelfs zonder significante libraries en zo, over de 16k ging.

Elke controller is [0,0] en heeft de buren [1,0], [0,1], [-1,0] en [0,-1] (oftwel N-O-Z-W). Voor sommige effecten zo je misschien ook nog met [1,1], [-1,1], [-1,-1] en [1,-1] willen communiceren.

Voor elke controller tel je de variabelen die dat punt op de golf moeten voorstellen van de 4 omringende controllers op, deelt dat door 4, en laat de LEDs daar naartoe faden. Na een bepaald aantal cycli, geef je die waardes weer door naar de controller tegenover degene waar je ze van gekregen hebt, en begint het opnieuw. Als blijkt dat een controller geen aangrenzende controller heeft aan een kant, geef je de waarde terug aan de controller waarvan je hem gekregen hebt. Als je er dan bij elke keer doorgeven een kleine constante of percentage vanaf trekt, zullen de golven langzaam uitdoven.

Dit is, naar mijn idee, veel eenvoudiger met het communicatiesysteem wat ik eerder voorstelde, maar het is zeker niet onmogelijk met een I2C bus of zo. In dat geval zal een centrale controller al het reken- en communicatiewerk moeten doen.

ik zou de tegels dit zelf laten regelen, geen mega brein erachter zetten (dit bedoel jij ook toch)

Wat me wel handig lijkt is een centrale unit waar je kan kiezen voor bepaalde programma's.
Bv
1 = standaard stamp effect
2 = golven
3 = alles aan
4 = kleuren wisselen
5 = etc...

Je zou dit misschien ook wel op een doorgeef manier kunnen doen. Je vertelt 1 tegel dat hij nu programma 2 gaat draaien, deze verteld dat door aan zijn omliggende, etc... Lijkt mij eigenlijk nog de mooiste oplossing.

Precies, dat was ook mijn idee. Sterker nog (heb ik hier ook al eerder verteld) je zou ook een commando mee kunnen geven met de toevoeging: "3 stappen naar beneden, 2 stappen naar links", waarmee je een specifieke controller zou kunnen aansturen.

Ik denk dat effecten op lange afstand toch niet echt interessant zijn, voor golven vanuit een trilling, of gewoon golvende kleuren of zo, hoef je alleen met de directe buren te communiceren.

Communicatievorm moeten we het dan nog over eens worden, ik denk zelf aan gewoon lompweg serieel. En dan met een-of-andere simpele "commandoset"*.

Ideetje voor heel simpel golf effect: stuur je gemeten ADC waarde naar de buren. Die delen het door 2, tellen het bij hun waarde op, als dat hoger is gebruiken ze het, anders niet, en vervolgens delen ze het resultaat weer door 2 en sturen dat naar de buren. Probleem is dat je dan ook je eigen spul terugkrijgt, maar als het goed is is wat je dan toegestuurd krijgt lager dan dat wat je al hebt. (en heb je er dus geen last van)

Delen door 2, of door 4 ofzo, moet nog even uitgezocht worden wat het mooiste is.

En prutsen met waardes van buren levert iig een samenwerkingseffect op, of het nou een golf is of niet, als het een leuk effect is is het doel bereikt.

4K bascom een beperking? Het is een leuk project hoor, maar 4k code schrijven zie ik mezelf nog niet doen... Ik heb meer te doen... Maar hé, het is zo open source als wat, niemand belet wie dan ook er op voort te bouwen. (en ik sluit absoluut niet uit dat ik er nog wat aan ga doen...)

[toelichting "commandoset"]
*= dus dat je b.v. telkens 3 bytes zend. 1e is wat er moet gebeuren (als: fade naar waarde = 1 , tel waarde bij je huidige input op = 2, ga volledig aan = 3, ga volledig uit=4), 2e is de waarde, 3e is hoeveel tegels het verder nog verzonden moet worden (waar dus elke tegel weer 1 van af haalt). Ik noem maar een voorbeeld hoor.

Het idee is: tegel1 verzend 2,128,2. tegel 2 ontvangt dat (of evt. alle buren) en stuurt 2,128,1 naar alle volgende tegels, die weer 2,128,0 naar alle volgende tegels sturen en dan houd het op. Eventueel kunnen de tegels ondertussen ook nog de waarde aanpassen.

Let op: ik noem maar iets, dit is niet noodzakelijkerwijs wat ik ook ga implementeren, áls ik dat al doe. Het hoeft ook niet handig of nuttig te zijn, en misschien zit er een denkfout van hier tot Tokio in.
[/einde toelichting]

Verder heb ik maar 2 attiny26's... dus communicatie tussen meer dan 2 controllers testen zal niet echt gaan...

En ik denk dat er een bug zit in de attiny13's code, ik heb het niet getest, maar op de attiny26 gebruik ik toch de gewone PWM uitgang en niet de geinverteerde. Bij de attiny13 heb ik nu als het goed is (fout dus) het signaal geinverteerd omdat ik de gewone uitgang gebruik op de attiny13 i.t.t. de geinverteerde op de attiny26. Wat dus op de attiny26 al de gewone uitgang blijkt te zijn, waardoor ik het voor niks geinverteerd heb... Als ik het al geinverteerd heb want ik kan mijn code niet testen bij gebrek aan een attiny13.

De ATtiny2313 behoort niet meer tot de mogelijkheden, het heeft meer i/o's en kan sneller maar mist in zijn datasheet het hoofdstuk ADC :)

Wat communicatie betreft (niet voor de demo dus) blijf ik bij de centrale uC. Dan heb je een kleuren touchscreen van 6500 pixels en ALLES blijft mogelijk.
Nog een paar voorbeelden.
Alles bvb rood, waar je stapt wordt het blauw, als er op de laatste rode tegel gestapt wordt, plots alles groen.
Gebruik het als reclame bord om de kosten te recupereren (bvb in een winkelcentrum met verdiepingen waar de vloer duidelijk zichtbaar is).
enz..

Dat is allemaal makkelijk met centrale uC, niet te doen zonder. Het enige lastige is de initialisatie voor 6500 tegels. Cameratje samen met intilligent programma die de boel in een wip initialiseert, lijkt wel een toffe uitdaging :)

Achja, waar trek je de grens..

sinds wanneer gaat het over 65000 tegels? 't idee is leuk verder, maar daar heb je toch meer een PC voor nodig om dat te sturen, vrees ik. Of toch een sterker uC dan een attiny.

goed, geen attiny2313 dan. Als die R/G/B ook niet allemaal gedimd hoeft te worden kan het met een attiny26 ook wel, alleen heeft die maar 2 PWM kanalen. Dus kunnen maar 2v.d 3 gedimd worden. Vallen alsnog leuke dingen mee te doen. En er is densoods nog software PWM... Liever andere uC pakken.

13 tegels/m², en Scotch sprak over eventuele oppervlaktes van 500m² -> 6500 tegels
(ik dacht wel eerder 16 tegels/m² maargoed :))

Aansturen met ATtiny heb ik nu ook niet gezegd. Een ARM zal wel vostaan, pc is nu ook weer niet nodig.

ATtiny26 zou ik dan niet nemen als Scotch RGB wilt voor de demonstratie.
ATtiny24 lijkt mij het beste als je in de ATtiny's wil blijven. Lijkt mij ook het goedkoopst.

Waarom zou dat niet te doen zijn zonder centrale uC? Dat elke controller alleen met zijn buren communiceert, wil niet zeggen dat informatie niet verder kan komen dan dat, en daar heb je niet eens een ingewikkeld routing protocol voor nodig.

Met I2C o.i.d. kom je al heel snel in de problemen met de beschikbare bandbreedte, fan-in/fan-out van je controllers, de maximale lengte van de transmissielijnen voor de arbitration, etc. I2C is leuk voor op een print, of binnen een apparaat, maar het is geen veldbus.

Die zelfde problemen zul je krijgen bij bijna elke veldbus, en daarbij ontkom je bijna niet aan line drivers die duurder zijn dan de rest van de schakeling bij elkaar.

Zelfs als je 16 tegels in een vierkante meter legt, heb je al een buslengte van minimaal 5 meter, aangezien je langs alle controllers moet.

Op 3 juni 2009 20:42:02 schreef SparkyGSX:
Waarom zou dat niet te doen zijn zonder centrale uC?

Store-and-forward delays, queing delays.. het zal in het honderd lopen. Veel geluk met debuggen. Get the point, ik zei: "Dan heb je een kleuren touchscreen van 6500 pixels en ALLES blijft mogelijk." Je kan het geheel dan beschouwen als een normaal display.

Dat elke controller alleen met zijn buren communiceert, wil niet zeggen dat informatie niet verder kan komen dan dat, en daar heb je niet eens een ingewikkeld routing protocol voor nodig.

Toen je communicatie voorstelde met enkel de buren, heb ik gezegd dat er routing geimplementeerd zal moeten gebeuren. Waarom zou ik nu plots denken dat dat niet meer gaat?

Met I2C o.i.d. kom je al heel snel in de problemen met de beschikbare bandbreedte, fan-in/fan-out van je controllers, de maximale lengte van de transmissielijnen voor de arbitration, etc. I2C is leuk voor op een print, of binnen een apparaat, maar het is geen veldbus.

Denk je nu echt dat ik 6500 slaves op 1 I²C bus zou hangen? (verder is de lengte van de verbindingen niet relevant, wel de capaciteit bij I²C)
Verdeling over grote afstand eventueel met ethernet, opsplitsen RS-232 ofzo, allemaal geen probleem.

[edit] Owja, die line drivers duurder dan de rest van de schakeling? 50 cent voor een max232. Waarschijnlijk zijn er zelfs nog goedkopere.

Ik heb eigenlijk geen idee hoe een bus te maken dat elke tegel weet wat zijn buren zijn om alleen die te doen oplichten...

Simpeler idee: alleen de linkerbuur van een tegel licht mee op, bij de rand gekomen alleen de tegel eronder en vanaf daar de rechterbuur.


1.2.3.4
8.7.6.5
9.A.B.C

Als elke tegel dan alleen kan praten met de tegel met een opeenvolgend nummer (dus 1 praat tegen 2, 2 tegen 3, enz), en dus alleen 1 weg communicatie, dan kan als er op een tegel gestapt word te tegel met een opeenvolgend nr te horen krijgen dat 'ie mee op moet lichten, zonder dat er echt lastige software of een bus master aan te pas komt.

Dat dan icm de commandoset uit mijn voorvorige post valt nog best te programmeren... Dan moet op de eerste tegel nog even een bedieningsiets worden aangesloten dat de eerste tegel verteld om een oneindig aantal tegels verder te vertellen dat ze nu in een andere modus moeten gaan werken. (dus volgens de commandoset uit de vorige post: 0,2, 255) Waarbij die commandoset even word uitgebreid naar "is het eerste byte een 0, dan betekend dat dat je naar een andere modus moet overschakelen, de 2e byte verteld je welke modus, 1= normaal stamp effect, 2 = linkerbuur fade mee, 3 = alles vol aan, 4 = alles vol uit, 5 en verder: not implemented), en de derde byte op 255 betekend: alle volgende tegels vertellen, niks van 255 afhalen)

Maar voor "alle omringende tegels faden mee" heb ik geen flauw idee hoe het aan te pakken.

Scotch: is het erg als het meefade effect nogal beperkt wordt, door slechts 1 naastliggende tegel mee te laten faden? (die dan wel weer evt zijn buur kan laten meefaden, etc.)

EDIT:
@Sparky:

Op 2 juni 2009 19:54:12 schreef SparkyGSX:
De NPN tor is een BC337, de PNP een BC327 (resp. BC547 en BC557 werkt waarschijnlijk ook wel). De condensator is 4.7uF. De basisweerstand van de NPN transistor is 1k2. De weerstand die parallel staan aan het piezo element is 33k. Vooral deze laatste is nogal op de gok gekozen (dat was de eerste van meer dan een paar k die ik op mijn bureau zag liggen), en deze heeft waarschijnlijk wel een redelijke invloed op de gevoeligheid.

De basisweerstand van de NPN, als die uitmaakt, dan maakt de weerstand voor de LED (en de weerstand van de LED) toch ook uit?

Ik ga ook even met die analoge schakeling spelen :)

EDIT2: WOW :D Die doet het goed! Fade alleen een beetje kort... En als ik 10uF pak fadet 'ie wel wat langer, maar is 'ie ook wat lastiger aan te krijgen...

Desondanks: erg leuk schakelingetje. 2 torren die doen waar ik een attiny voor nodig heb... Respect!