verlichtingsschakeling voor kunstwerk

Dat is eigenlijk ongeveer wat ik de hele tijd probeer te schetsen, behalve dan dat ik elke tegel 4 softwarematige communicatiepoorten wil geven, zodat je met meer dan 2 aangrenzende tegels kunt communiceren.

Als alle tegels aan 1 bus hangen, kun je ook nog wel iets slims doen met een paar I/O pinnen waarmee je de topografie van het hele veld kunt uitvinden zonder alle controllers van tevoren een vast adres te hoeven geven.

De basisweerstand is onderdeel van de R/C kring, en deze bepaald dus hoe snel de condensator weer ontladen wordt. De weerstand van het stukje onder de emitter heeft wel invloed, maar volgens mij is dit heel gering. Bij een emittervolger zal de transistor altijd dicht bij zijn maximale versterkingsfactor werken, waardoor maar een kleine stroom nodig is om de transistor open te sturen. De transistor zal zijn emitter steeds 0.6V onder de basis proberen te houden, waardoor de spanning over die basisweerstand altijd heel klein, en over een groot gebied nagenoeg constant zal blijven.

Hey,

Gisteren de analoge schakeling gebouwd, bij mij doet hij het niet. De Leds gaan direct op volle sterkte branden. schema volgens mij wel goed gevolgd, ga het vanmiddag of morgen nog een keer proberen.

@ lucky luke
Het lijkt me essentieel dat iig vier tegels rondom direct aangestuurd worden. Zou eigenlijk zeggen 6 (ook de hoeken).

Tegel comunicatie is voor mij nu niet essentieel, eerst een testmodel.

Volgens mij kan je dit doen:
iedere tegel een stuur kanaal, daarmee vetelt hij al zijn buren ik sta uit, geef licht, etc...

Iedere tegel 4 tot 6 inputs (van alle buren).

Op 4 juni 2009 11:50:54 schreef SparkyGSX:
Dat is eigenlijk ongeveer wat ik de hele tijd probeer te schetsen, behalve dan dat ik elke tegel 4 softwarematige communicatiepoorten wil geven, zodat je met meer dan 2 aangrenzende tegels kunt communiceren.

4 communicatiepoorten... Dat is 't! Dan faden de boven en onderburen (en zijburen) tot de helft, en die vertellen hun zijburen (en boven/onderburen) weer om tot de helft te faden, zodat de schuinonder- en bovenburen van de oorspronkelijke tegel naar een kwart faden...
En de tegels die onderaan niks meer hebben, sluiten we weer aan bovenaan de vloer op de tegels die daar geen buur hebben. (Of we sluiten ze in het geheel niet aan). Beetje astroids effect. Vlieg je onder uit beeld kom je er boven weer in.

Even kijken of je dan niet eeuwig je eigen bericht terugkrijgt... Ja, krijg je, (linkerbuur, linkerbuur'sbovenbuur (=linksbovenbuur), bovenbuur (=linkerbuur'sbovenbuur'srechterzijbuur), jezelf (=linkerbuur'sbovenbuur'srechterzijbuur'sonderbuur), of makkelijker: 7,6,2,3, als je van links naar rechts nummert in 4 rijen van 4 tegels) maar is niet erg... Er is geen bus collision want elke tegel praat alleen met zijn buren. En iets maken dat berichten met een fade-naar lager dan de huidige waarde negeert is ook niet zo moeilijk. (zelfde als een ADC ingelezen waarde, die word al genegeerd als ie te laag is). Iets wat berichten met een fade-naar/2 waarde lager dan 10 niet meer doorstuurt is ook te doen... Waardoor een bericht dus "uitdooft". En on the fly (nouja, bijna on the fly) tegels toevoegen of verwijderen kan ook, zoals je eerder schetste. Prachtig! Dankjewel! Uitleg over het analoge schakelingetje is ook helder .

Puntje van zorg: "gaat dat niet vreselijk veel geheugen vreten"... 3 software UARTs. Ach, we kunnen er altijd nog een PIC in gooien... (ik heb proton PDS full, dus dan hebben we geen limiten van de compiler. Alleen wordt een PIC met veel geheugen een beetje duur). En wat anders: hoe test ik communicatie van 4 (of meer, eigenlijk) controllers, als ik er maar 2 heb... Laat er eerst maar een vloertje zijn dat ik het resultaat kan zien (per filmpje, maar toch). Dat debugt makkelijker. En het is ook leuker programmeren als ik het resultaat zie. Moeten er wel controllers in dat vloertje met een beetje veel geheugen, voor die software UARTS. 'k zou eigenlijk even moeten testen hoeveel geheugen het precies vreet... Om te kijken welke controller er dan in dat vloertje moet.

Op 4 juni 2009 12:44:35 schreef Scotch:
Gisteren de analoge schakeling gebouwd, bij mij doet hij het niet. De Leds gaan direct op volle sterkte branden. schema volgens mij wel goed gevolgd, ga het vanmiddag of morgen nog een keer proberen.

Bij mij doet 'ie t wel, op breadbord, met BC547 en 557, en 470 Ohm voor de LED. Maak anders even een paar goede foto's van je schakeling en post ze hier.

@ lucky luke
Het lijkt me essentieel dat iig vier tegels rondom direct aangestuurd worden. Zou eigenlijk zeggen 6 (ook de hoeken).

uhm, 8 dan...

Tegel comunicatie is voor mij nu niet essentieel, eerst een testmodel.

De techniek schrijdt voort hè . Naar ik ben wel blij dat het niet voor de 17 af moet. Ik houd niet van deadlines bij dingen die ik voor de lol doe.

Volgens mij kan je dit doen:
iedere tegel een stuur kanaal, daarmee vetelt hij al zijn buren ik sta uit, geef licht, etc...

Iedere tegel 4 tot 6 inputs (van alle buren).

Is ongeveer wat ik van plan was, maar dan anders: de buren krijgen niet te horen wat de tegel doet, maar direct wat zij moeten doen. En dat alles over een seriële verbinding, om wat pinnen te besparen. Het principe is wel ongeveer gelijk.

[Bericht gewijzigd door Lucky Luke op donderdag 4 juni 2009 13:06:55 (20%)]

Ik wil er best wat geld in stoppen als jij weet dat het werkt. Wil er dan eerst een bouwen en de tijd begint (een beetje) te dringen....

Nog twee weken.

Als je het leuk vind kan je ook een keer komen kijken als het af is (of als ik aan het bouwen ben). Dat geld natuurlijk voor allen die me hier helpen ( ik zit in Dordt)

Ik weet niet wat je van plan was met het 16 tegel proefmodel? Attiny of analoog? Indien attiny: de code voor de attiny26 die nu al in het topic staat werkt. (De code voor de attiny13 zit hoogstwaarschijnlijk een bug in die ervoor zorgt dat de LED standaard aan is en juist uit gaat als je op de sensor tikt, en vervolgens weer aan fadet. Precies verkeerdom dus. En makkelijk te fixen)

De communicatie is denk ik ook wel werkend te krijgen mits de controller voldoende geheugen heeft. De attiny26 heeft 2k, maar ik moet eerst testen hoeveel ruimte die software UARTS gaan vragen.

En natuurlijk lijkt het me leuk het eindresultaat (of een tussenstadium) te zien. Maar, Dordrecht, hmmm, ik kom iig niet per fiets... Den haag zou al wat dichterbij zijn.

EDIT:
Ik heb even een testcodetje geschreven wat niets nuttigs doet, het zend alleen "test output 1" uit een software UART, en "test output 2" uit een 2e software seriele UART (en dat 4 keer met telkens een ander getal), om vervolgens ook 4 software UART inputs te lezen en daar van elk 4 bytes te vragen. Totaal dus 8 software UARTS, waarvan 4 input en 4 output. Dat vraagt 56% van het geheugen van de attiny26. Dat is behoorlijk wat... Dus het zou handig kunnen zijn om een controller met 4K te pakken. Misschien dat het prima in 2K past hoor, maar het is nogal rottig als je 16 (of 25, of 65000) controllers hebt waar 't progje net niet in past...
Is er een "attiny26, maar dan met 4k geheugen" ?(die dus ook anders heet!). Eens zien of atmel een leuke selector online heeft staan ofzo. hebben ze niet, wel een lijst.

Ander testje met een betere uitkomst: BASCOM support inderdaad 4K grote programma's. Pfoei!

En nog wat: Ik denk dat Scotch, als student, gratis samples kan krijgen... http://www.atmel.com/forms/Samples.asp?family_id=607
In dat geval kunnen we natuurlijk gelijk voor een dikke controller gaan die in ieder geval voldoet. atmega8 ofzo (3 PWM kanalen, 6 ADC kanalen, hardware UART, 8K flash).

[Bericht gewijzigd door Lucky Luke op donderdag 4 juni 2009 15:07:21 (45%)]

UART? Plots de communicatie asynchroon doen?
Collissions? Tuurlijk niet je zit met full duplex..

"gaat dat niet vreselijk veel geheugen vreten"... 3 software UARTs. Ach, we kunnen er altijd nog een PIC in gooien...

Overschakelen naar PIC, das vaag? AVRStudio en WinAVR, geen beperkingen.. C is toch geen probleem? (in mijn ogen beter zelfs)

de buren krijgen niet te horen wat de tegel doet, maar direct wat zij moeten doen

Eigen waarde sturen zie ik nog lukken maar ik zie dan wel vierkanten ontstaan, uitfadende cirkels kan je vergeten op een simpele manier. Opdrachten naar alle buren doorsturen.. Er zal veel ongewenste redundantie onstaan.

ps: ik zou het eerst eens deftig grafisch simuleren.

[edit]
De ATtiny26 geeft ook nog die beperking voor de RGB's. Verder staat er in de datasheets duidelijk "Not recommended for new
designs" Waarom juist weet ik niet precies, er moeten in ieder geval ergens problemen zijn.

[Bericht gewijzigd door plantrekker op donderdag 4 juni 2009 15:05:25 (13%)]

Op 4 juni 2009 14:41:41 schreef plantrekker:
UART? Plots de communicatie asynchroon doen?
Collissions? Tuurlijk niet je zit met full duplex..

Serieel zonder klok is toch asynchroon? En ik zeg toch niet dat er collisions kunnen zijn? Als we wel een bus zouden hebben gebruikt (1 master + berg slaves die terugpraten, of voor mijn part geen master) hadden we dat wel gehad. Of toch kunnen hebben.

[...]Overschakelen naar PIC, das vaag? AVRStudio en WinAVR, geen beperkingen.. C is toch geen probleem? (in mijn ogen beter zelfs)

Ik spreek (nog) geen C... En bascom's basic vertalen naar PICbasic's basic is niet zo heel moeilijk. 't was ook maar een losse gedachte, mochten we er op uitkomen dat het groter gaat worden dan die 4K.

[...]Eigen waarde sturen zie ik nog lukken maar ik zie dan wel vierkanten ontstaan, uitfadende cirkels kan je vergeten op een simpele manier. Opdrachten naar alle buren doorsturen.. Er zal veel ongewenste redundantie onstaan.

Vierkanten? Die tegels zijn vierkant, dus dat krijg je sowiso... Ok, tenzij je er 65000 op een flinke afstand legt. (de pixels op mijn computerscherm zijn ook rechthoekjes, toch kan 'ie een cirkel weergeven).
Verder is het plan tot nog toe: de halve eigen waarde wordt doorgestuurd. Als de ontvangende tegel al hoger zit, houdt 'ie dat, zit 'ie lager neemt 'ie de nieuwe waarde aan. Zodoende krijgen de tegels links, rechts, onder en boven de oorspronkelijke tegel de halve helderheid (of houden hun eigen). De tegels op de hoekpunten van de oorspronkelijke tegel krijgen dan weer te helft van de helft van de oorspronkelijke tegel (via de buren van de oorspronkelijke tegel). Tegels nog verder krijgen weer telkens de halve waarde. Waardes onder de eigen waarde worden niet doorgestuurd, waardes onder de 5 sowiso niet. Dit om te voorkomen dat een bericht maar door blijft kaatsen tussen allerlij tegels.
De oorspronkelijke tegel krijgt dat nog een boel keer terug en negeert het, omdat 'ie hoger zit.

Dit plan kan uiteraard nog veranderen als iemand met iets anders/makkelijkers/beters komt, het is ook maar iets wat ik al post-typende bedacht heb, toen eens overdacht heb, en gepost heb.

Ongewenste redundantie? Als dit ergens in een bedrijf komt te liggen wil je niet dat de boel ermee kapt als een tegel stuk gaat... Misschien is er wel een beetje te veel communicatie, ja. Misschien is communiceren met de tegels links en rechts van je ook al genoeg. En die linkse en rechts tegels weer met de tegels boven en onder zich. En díe tegels weer met de tegels links en rechts, enzovoorts. Alleen krijg je dan wel een heel ander patroon. Namelijk de oorspronkelijke tegel, met naast zich 2 tegels die half zo helder zijn, op zijn hoepunten tegels die een kwart zo helder zijn, en boven en onder zich tegels die nog maar 1/8 van de oorspronkelijke helderheid hebben... Ook geen cirkel.

ps: ik zou het eerst eens deftig grafisch simuleren.

ik heb er wel over nagedacht, maar hoe moet ik het grafisch simuleren? Als je dat kunt, ga je gang! Graag zelfs!

[edit]
De ATtiny26 geeft ook nog die beperking voor de RGB's. Verder staat er in de datasheets duidelijk "Not recommended for new
designs" Waarom juist weet ik niet precies, er moeten in ieder geval ergens problemen zijn.

je bedoeld dat 'ie maar 2PWM kanalen heeft? De atmega8 heeft er gelukkig wel 3 (mochten we inderdaad RGB gaan doen, kan en zal dat zeker van pas komen)

Anyhow thanks voor je commentaar. Kan het project alleen maar beter van worden.

De UART is idd asynchroon. Sparky had een synchrone in gedachten, vandaar.
Serieel zonder klok staat niet gelijk aan asynchroon. Synchroon gaat perfect zonder clock.

Er zijn verschillende manieren om collissions te voorkomen, een bus gaat dus niet altijd gepaard met collisions. In deze toepassing zou dus zowizo een techniek gekozen worden waarbij geen collisions voorkomen, het zou zelfs te zwaar zijn om een contention techniek te implementeren. Een master is hier de beste oplossing als er een bus gebruikt zou worden.

Volgens dat plan ontstaat er een steeds groter (uitfadend) vierkant. Simuleren is niet moeilijk, met flash zou het bvb leuk kunnen, zeker om het hier dan te tonen. Ik heb het nu wel te druk.

Ik had het idd over die beperking van 2 PWM kanalen.

Dit is toch serieel? <voeg smiley die het even niet meer snapt in>
heb je edit gelezen. Laten we het dan maar gewoon serieel noemen en hoe de bijbehorende hardware/in software nageaapte hardware in de AVR heet, ach.

En er ontstaat een gekanteld vierkant inderdaad... (even papiertje gepakt en gewoon PWM waardes in vakjes getekend). Dat is even ervan uitgaande dat de tegels elkaar niet mechanisch beinvloeden, want ze waarschijnlijk wel zullen doen.

Scotch, is dat mooi genoeg, een uitvloeiend vierkant?

En ik denk dat delen door 4 beter is. Delen door 8 kost, als je hard op een tegel stampt, 5 tegels voor het uitdooft... (255,128,64,32,16,8, en 4 is onder 5 dus negeren)) Op een model van 4 bij 4 (16 tegels) gaat dat dus goed zichtbaar zijn. Delen door 4 wordt 255,64,16, kost dus nog maar 2 tegels.

[Bericht gewijzigd door Lucky Luke op donderdag 4 juni 2009 17:07:25 (10%)]

In een van de vorige posts heb ik wat nieuwe onderwerpen aangehaald (bv RGB LED's) die mogen van mij voor nu wel buiten beschouwing gelaten worden. Ging meer om het bepalen van de grote van de controller.

@ lucky luke

Wat bedoel je precies met een uitvloeiend vierkant? De tegel geeft dan de schok (vermindert met waarde x) door aan al zijn buren toch. Dat lijkt me goed. Doen de diagonalen daarin ook mee?

@ plantrekker
Het grote voordeel van een configuratie zonder master lijkt mij het eenvoudige toepassen van het systeem. Je pakt de tegels van een stapel en plaatst ze in de ruimte (onderling verbonden) en bent daarna klaar. Je kan dan 1 tegel, 10, 100, 1000, 1000000, etc... tegels plaatsen zonder enige aanpassing te hoeven doen (behalve een wat zwaardere voeding natuurlijk

Het enige wat ik wel in het systeem zou willen maken is het kunnen kiezen van bepaalde reactie programma's. Dit zou kunnen door ergens (aan de rand) een programma switch te plaatsen. Via de onderlinge comunicatie wordt alles doorgegeven.

de voordelen die je noemt voor een master configuratie (zoals het kunnen gebruiken als beeldscherm) zijn voor dit project niet relevant. Ze zouden dat voor een commercieel product waarschijnlijk wel zijn.

Vanuit de elektro configuratie bekeken kan ik natuurlijk niet zeggen wat de betere optie is. Als product ontwerper ga ik voor de autonome tegels.

Wat denk jij hiervan?

Ow, ik zag het niet als "effe daar een lichtmat van 500m² ergens neerleggen" maar meer als een vaste installatie.
En dit om de volgende reden: (ik illustreer met 16 tegels per m² en niet met 13 tegels m², dat geeft 8000 tegels voor 500m²)

Om die losse tegels die makkelijk in elkaar geklikt kunnen worden van voeding te gaan voorzien..
De eerste tegels waar de voeding op aangesloten is moet al snel (10mA*8000=80) 80A kunnen trekken, minstens 25mm² kabel dus, als doorverbinding van de voeding van tegel naar tegel.
Dat is niet haalbaar, je zal op veel plaatsen voeding moeten voorzien zodat de doorsnede van de doorverbindingen van de tegels naar beneden kan.

Doorverbindingen tot 4A lijken mij haalbaar (om het nog heel makkelijk in elkaar te krijgen). Dat wil zeggen dat voor een vierkant van 22m op 22m (= ongeveer 500m²) aan 1 zijde om de meter voeding moet voorzien worden of de boel smelt wanneer alles samen oplicht.

Het is maar weer effe een schets, je kan ook meerdere connectors voorzien in 1 tegel die intern doorverbonden zijn. Maar hoe groter de stroom hoe meer kans dat het misloopt. Ik bedoel niet enkel slecht aflopen door bvb brand maar tussen de linkse en de rechtse tegel zitten (4x22) 88 doorverbindingen, daar gaat een belangrijk spanningsval optreden vermoed ik.

Wow, opeens een hoop activiteit hier. Ik heb alles even vluchtig doorgelezen (ben intussen aan het koken).

@Lucky Luke: ik bedoelde dus inderdaad een full-duplex synchrone bus, met een clock die door alle controllers gedeeld wordt. Hierdoor heb je alleen een externe interrupt pin nodig, naast 8 datalijnen.

Als het faden te snel gaat, kun je misschien de basisweerstand van die NPN tor nog wat groter nemen. Op een bepaald moment kom je dan wel in de knoop met de versterking van die tor, maar dat zou je dan weer op kunnen lossen door er nog een torretje bij te zetten, en er dus een darlington paar van te maken, of door gewoon een tor te nemen met een hogere versterkingsfactor, natuurlijk.

EDIT @Scotch: Die autonome tegels zijn dus precies wat ik bedoeld. Ik vind dat veel eleganter dan een centrale besturing. Een kapotte tegel is dan ook niet erg, die zal zich waarschijnlijk gedragen als een steen in een vijver; de golven gaan er vanzelf omheen, daar hoef je niets speciaal voor te doen. Dat is precies het soort "emergent behaviour" wat ik bedoel.

Die gedeelde klok kan ook gebruikt worden om ervoor te zorgen dat de golf overal even snel wordt doorgegeven, en alle controllers even snel faden.

Ik weet niet of je al gekeken hebt naar "the game of life", http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life maar dat is dus ook iets wat je heel eenvoudig kunt maken, omdat elke tegel zelf kan beslissen of hij aan of uit moet gaan, aan de hand van de status van de buren. De gedeelde klok wordt dan weer gebruikt om ervoor te zorgen dat alle controllers op hetzelfde moment hun status updaten.

Je kunt een extreem groot veld, zoals die 8000 tegels die Plantrekker schetst, natuurlijk niet vanuit 1 punt voeden, maar als je het hele veld onderverdeeld in 4 kleinere velden, en vanuit het midden van elk van die velden de voeding aanvoert, wordt de stroom door elke aansluiting maar 1/16de deel van het totaal. Daarbij, zelfs als je de tegels kunt maken tegen een kostprijs van 2,50 euro (lijkt me al een erg lage schatting), gaat dat vloertje 20.000 euro kosten. Als het om dergelijke bedragen gaat, kan er ook wel even iemand die er verstand van heeft naar kijken, om ervoor te zorgen dat de voeding geen problemen zal opleveren.

@Scotch: een paar foto's van je schakeling zou wel handig zijn. Kun je de spanning over de condensator meten?

EDIT2: nog een wild idee: fractals! http://nl.wikipedia.org/wiki/Fractal Om mooie fractals weer te geven, heb je natuurlijk wel een flinke resolutie nodig, maar misschien heb je ooit wel genoeg tegels om dat te kunnen doen. Gezamenlijk hebben de controllers meer dan voldoende rekenkracht om dat te kunnen doen.

Je kunt ook een blauwe vloer maken waarbij er steeds een geel achtige vlek rondom elke persoon blijft hangen; Mozes kan dan door de rode zee lopen.

Je zou ook lichtvlekken kunnen maken (enkele oplichtende tegels) die zich snel over de vloer bewegen, en steeds onder een lopende persoon door schieten. De lichtvlekken lijken dan de personen aan te vallen.

Nog een andere variant zou kunnen zijn dat je zulke lichtvlekken rustig een beetje laat bewegen (misschien van verschillende kleuren), maar dat ze bij elkaar klitten in groepjes, en de mensen proberen te vermijden. Je krijgt dan een effect alsof je door een veld met kleine dieren loopt, die bang zijn voor de mensen.

Ik denk dat dit een heel fascinerend project zou kunnen zijn, niet alleen omdat zo'n vloer lijkt te leven, maar ook omdat het reageert op de mensen. Die mensen reageren vervolgens weer op de vloer, en die interactie kan erg leuk zijn. Het is bijvoorbeeld goed mogelijk dat sommige mensen om de groepjes "dieren" heen gaan lopen, omdat ze die niet bang willen maken.

Ik heb ooit een heel eenvoudig wagentje gemaakt met een paar stappenmotoren en schakelaartjes, die bestuurd werd met een heel eenvoudig neuraal netwerkje (een primitieve vorm van kunstmatige intelligentie). We hebben met dat ding, wat zelf heeft geleerd hoe hij om een obstakel heen kon rijden, zitten spelen alsof het een dier was, terwijl ik het helemaal zelf gemaakt had, en elke regel code zelf had geschreven.

EDIT3: ik weet zeker dat dat communicatiesysteem werkt, want ik heb dat eerder gemaakt voor een project op school, en dat liep uitstekend. Het enige echte nadeel is dat je een vrij forse controller nodig hebt, vanwege de 9 I/O pinnen voor de communicatie.

Ik weet niet precies hoe groot die code was, maar het was niet veel. Ik heb het doen zelf in C geschreven. Helaas kan ik de code nergens meer vinden, maar ik denk dat ik het met niet al te veel tijd en moeite nog een keer kan maken.

Weet iemand of een AVR ook programmacode kan uitvoeren vanuit RAM? In dat geval zou je de gecompileerde code voor het effect door het netwerk kunnen sturen, terwijl de rest van de code (communicatie, aansturing van de LEDs, sensor e.d.) gewoon in het flash kan blijven staan.

Aan de andere kant; als alle effecten al aanwezig zijn in de programmacode, kan het geheel uit zichzelf omschakelen. De tegels zou dan kunnen stemmen wanneer ze overschakelen op welk ander programma, op basis van de tijd van de dag, de drukte op de vloer, en wat willekeurige getallen of zo.

[Bericht gewijzigd door SparkyGSX op donderdag 4 juni 2009 20:48:30 (11%)]

Op 4 juni 2009 19:52:43 schreef SparkyGSX:
Je kunt een extreem groot veld, zoals die 8000 tegels die Plantrekker schetst, natuurlijk niet vanuit 1 punt voeden, maar als je het hele veld onderverdeeld in 4 kleinere velden, en vanuit het midden van elk van die velden de voeding aanvoert, wordt de stroom door elke aansluiting maar 1/16de deel van het totaal.

1/4 bedoel je.

Nee, 1/16de. Je deel het hele veld op in 4 stukken, die je elke weer vanuit het midden gaat voeden, waarbij je elke stuk dus eigenlijk weer in 4 stukken deelt, die vanuit een hoek gevoed worden.

Ik denk dat de spanningsval wel mee zal vallen, aangezien de voeding voor elke willekeurige tegel voor een groot aantal andere tegels aangevoerd zal worden.

Zoiets als dit, dus: http://xkcd.com/356/

@ sparky

mooi voorbeelden van effecten, mag ik die meenemen in mijn verhaal op de academy?

Ga vanavond/morgen een foto maken en de condensator nameten. In de winkel heb ik me laten vertellen hoe de npn en pnp aangesloten moeten worden, mischien verkeerd voorgelicht?

@ plantrekker
ik denk dat de instalatie redelijk vast zal zijn (niet even neergelegd voor een korte periode. Het is wel een groot voordeel als je slechts de tegels en een voeding hoeft te plaatsen.

Ik denk aan een voeding die rondom loopt, het geheel moet toch in een lijst komen. De grootste afstand tussen voeding en tegel neemt dan al flink af. Het aantal tegels met een directe aansluiting op de voeding is daarentegen weer een stuk hoger.

Natuurlijk mag je die voorbeelden gebruiken, zolang je erbij vermeld waar ze vandaan komen, natuurlijk. Het lijkt me sowieso verstandig om een verwijzing naar dit topic op te nemen; het is nooit verkeerd om hulp in te roepen van mensen die verstand hebben van een vakgebied waar je zelf niet zo sterk in bent; als ik docent zou zijn, zou je daar bonuspunten voor krijgen.

Ik vind het technisch al een leuk project, maar daarnaast vind ik het ook een geweldig sociologisch / psychologisch experiment, omdat veel mensen het systeem niet zullen begrijpen, en het daardoor snel intelligent gaan vinden, en andere menselijke eigenschappen zullen gaan toekennen.

Voor de aansluiting van die transistors kun je eenvoudig de datasheet vinden met Google. Kijk hier http://www.circuitsonline.net/artikelen/view/17 ook even, daar staat eigenlijk al alles wat je nodig hebt.

Ik denk dat je de transistors verwisseld hebt of zo.

Wow, sparky, al die effecten, dan mag je me serieus gaan helpen programmeren... Het zijn fantastisch mooie ideeën maar ik heb geen idee hoe dat voor elkaar te krijgen. Communicatie mag je me ook even uitleggen vrees ik . (ik dacht dat dit simpeler zou blijven... ach wat, leer ik weer wat bij). Als je een stuk C hebt ofzo: ik spreek geen C, maar ik kan het een klein beetje lezen. (ik ben wel van plan C te leren, op vrij korte termijn)

Ik had eigenlijk tot nu toe het idee voor seriele communicatie zonder klok. Gewoon print #1, var1, var2, varn zegmaar. Alleen: ik zit vast. Letterlijk. input #1, var1,var2, varn is blocking... Het idee was iedere keer die inputroutine af te lopen en dat als delay te gebruiken. Dat gaat zo niet werken natuurlijk... Ik post zo wel wat code.

En een AVR code uit laten voeren uit ram: nee, kan niet (zover ik weet). Er zijn er wel met self programmable flash geloof ik... Maar dat is bedoeld als datastorage...

Emergent behaviour...
1) Mooi, want je schakeling lijkt inteligent te zijn
2) Scheelt weer bugs ("nee nee, dat is geen bug, dat is emergent behaviour" "maar hij doet helemaal niks meer, en er kwam rook uit" "tsja... dan had u maar eerder naar de psychiater moeten gaan... Sissende elco's is vaak een teken van overspannenheid. U gaat toch ook roken bij stress?" "Nee, ik ben de voorzitter van de "Rookverbod Nu" vereniging" "uhm... oeps... Maar het is hoe dan ook geen bug. Als er ergens rook uit komt is het meestal gewoon stuk")
3) Zolang het bij tegels blijft... (zware machines met emergent behaviour lijkt me nogal eng...)

de

$regfile = "attiny26.dat"
' default the internal osc runs at 1 MHz   (voor seriële 
'communicatie kristal neerzetten!) (4mhz, en ckdiv8 uitzetten)
$crystal = 1000000
$hwstack = 32                                               'default
$swstack = 10                                               'ook default
$framesize = 40                                             'wat is dit eigenlijk?

Dim Adc_meting As Integer
Dim Licht As Byte

Dim Id As Byte
Dim Vorigid As Byte
Dim Command As Byte
Dim Fade As Byte
Dim Num As Byte

Const Fadetijd = 32

Open "Coma.0:4800 ,8,N,1" For Input As #1
Open "Coma.1:4800,8,N,1" For Output As #2

'Config Timer1 = Pwm , Prescale = 1 , Compare A Pwm = Clear Down , Compare B Pwm = Clear Down
' maar dan handmatig

Tccr1a = &B01011111
'zie datasheet blz 72 en 77
Tccr1b = &B11000001
'prescale = 1, clearen bij compare, zie datasheet blz 73 en 74
Ocr1a = 28
' output compare, zeg pwm1a =
Ocr1b = 128
' idem, voor b
Ocr1c = 255
' top waarde

Ddrb.1 = 1
'output
Ddrb.0 = 1
Ddra.7 = 0
'input
Porta.7 = 0
                                                'geen interne pullup
Config Adc = Single , Prescaler = Auto , Reference = Avcc   ' AD-Wandler starten
Start Adc

Licht = 128                                                 'licht half aan in 't begin
Adc_meting = 0
Vorigid = 0

Do
Stampmodus:
Adc_meting = Getadc(6)
Shift Adc_meting , Right , 2
   'deel adc_meting door 4  (max 1023 wordt nu max 255)
   If Adc_meting > Licht Then
   Licht = Adc_meting
   Else
      If Licht <> 0 Then Licht = Licht - 1
   Gosub Communicatie
   End If
Ocr1a = Licht
Loop

Alles_aan:
Ocr1a = Fade
Gosub Communicatie
Goto Alles_ Aan

Burenmodus:
Adc_meting = Getadc(6)
Shift Adc_meting , Right , 2
          'deel adc_meting door 4  (max 1023 wordt nu max 255)
   If Adc_meting > Licht Then Licht = Adc_meting
   If Fade > Licht Then Licht = Fade
   If Licht <> 0 Then Licht = Licht - 1
 If Vorigid = 1 Then Id = 0 Else Id = 1
 Vorigid = Id
 Fade = Licht / 4
 Print #2 , Id , 3 , Fade , Num
 'command 3 om in burenmodus te blijven (of nieuwe tegels erin te zetten, num is nog niks
Gosub Communicatie
Ocr1a = Licht
Goto Burenmodus

Gauit:
Ocr1a = 0
Gosub Communicatie
Goto Gauit

Communicatie:
Input #1 , Id , Command , Fade , Num
' dit is blocking... eigenlijk zou ik het na 30ms willen laten time-outen...
   If Id <> Vorigid Then
'voorkomen dat je je eigen bericht eeuwig terugrkijgt.
   Vorigid = Id
   'Id Opslaan
      If Id = 1 Then Id = 0 Else Id = 1                     'nieuw id maken
   Print #2 , Id , Command , Fade , Num                     'broadcast!
       If Command = 0 Then Goto Gauit
       If Command = 1 Then Goto Alles_aan
       If Command = 2 Then Goto Stampmodus
       If Command = 3 Then Goto Burenmodus
   End If
Return

Ik kan niet 100% garanderen dat er bugs in zitten, maar dikke kans.
Het probleem is nu echter dat input #1, id, command, fade, num blocking is...

_{de [ /code ] tag lijkt het niet te doen
mod edit: je had een [ teveel getypt aan het begin}

[Bericht gewijzigd door klein is fijn op vrijdag 5 juni 2009 17:19:47 (1%)]

@ sparky, ik heb natuurlijk al verteld dat jullie mij helpen. Het is erg belangrijk om niet alles zelf te willen doen (kunnen).

In de elektro winkel ben ik verkeerd ingelicht: base en collector zijn omgedraaid. Ga ze zo omdraaien. Zo zie je maar wat ik allemaal fout kan doen

EDIT: ik heb ze omgedraaid maar het werkt nog niet. De LEDs branden continu heel zacht. Als ik de condensator los maak van de grond gaan de LEDs vol branden. De piezo maakt soms een beetje geluid.

EDIT2: de spanning op de condensator is ongeveer 8 volt

Wat is je voedingsspanning? Welke voedingsspanning had SparkyGSX eigenlijk? Zijn je transistors nog heel?

Bij mij werkt 'ie goed, op 5V.
Spanning op de condensator is 2V als de LED uit is (maar daalt, o.a. doordat mijn meter er stroom uit trekt). bij hard tikken stijgt de spanning naar zo'n 4.5 volt. Ik gebruik BC547/bc557

Ik bedenk me nu iets: Dat ID byte zou ook gebruikt kunnen worden om de tegels elk een uniek nummer te geven. Dat je in een bepaald patroon over de vloer moet lopen, tegel voor tegel aantikken, als je ze hard genoeg aantikt laten ze hun LED's oplichten, zodat je weet dat je de volgende moet aantikken. Dan iets maken dat de eerst aangetikte tegel gewoon 0 neemt, dat naar alle anderen stuurt, zodat de volgende 0+1 neemt (dat naar alle anderen stuurt), de volgende 2 (en dat doorstuurt), de volgende weer doorgestuurde waarde + 1 enzovoorts. Dat moet je dan wel elke keer bij powerup doen... (of het in EEPROM zetten, en een mogelijkheid maken de procedure opnieuw te doen als je de vloer anders in elkaar zet). Dan kun je elke tegel uniek aansturen. Probleem is, dat je dan wel weet dat je tegel 12 aanstuurt, maar niet dat dat de onderbuurman is van tegel 9... Dus nog een dergelijke aantikprocedure om de tegels duidelijk te maken wie de buren zijn.

Is dit een goed idee?

Hmm, vreemd. Het zou kunnen dat een van de transistors stuk is, omdat je de basis en collector verkeerd om had aangesloten.

Met een voeding van 9V (batterij) komt de spanning over de condensator bij mij niet boven de 6V. De LED gaat uit zodra de spanning onder de 2V komt, en de spanning over de condensator zakt langzaam maar zeker naar 0V.

Heb je niet per ongeluk een veel kleinere weerstand dan 33k gebruikt over het piezo element? Weet je wel echt zeker dat je een piezo hebt, en geen gewone speaker?

EDIT bij mij doet het ding het op alles tussen de 3 en 12V. De voeding waar hij aan hangt kan niet verder.

@Scotch: hoe je toevallig een multimeter met diodetester? Tussen de basis en collector en basis en emitter zou je zo'n 0.6V diodespanning moeten meten in 1 richting, met de meetpennen andersom helemaal niets, en van de emitter naar de collector in beide richtingen niets. Aangezien je een PNP en een NPN tor hebt, zijn die richtingen verschillend. Dus bij beide torren zou je 2 keer 0.6V moeten meten, en verder alles oneindig.

Als je geen diodetester hebt op je multimeter, kan het ook met de weerstand mode, maar de weerstand die je dan zou moeten meten verschilt per meter. Meestal is dat ongeveer 600 ohm.

EDIT2: De adressen toekennen door de tegels aan te tikken is wel een leuk idee, maar ik kom je niet ophalen als ze je in een gesloten inrichting hebben gestopt omdat je als een bezetene in vreemde patronen op de vloer aan het tikken was he?

Dat is natuurlijk ook niet nodig bij het communicatiesysteem waar we het over hadden, omdat elke tegel alleen met zijn buren kan communiceren. Het is dus niet nodig om elke tegel een adres te geven. Als je specifiek een tegel wilt benaderen, kun je dat doen door in het pakket de route naar de tegel op te nemen.

het probleem is dat die route afhankelijk is van hoe de vloer in elkaar zit... Ok, niet als iedere tegel idd 4 communicatiepoorten heeft, dan weet je waar de buren zitten. Met 3 of 2 lukt dat me iig niet.

Fractals en Game Of Life zie ik al helemaal niet zitten... Als iemand er een programma voor heeft wil ik het wel proberen over te zetten naar bascom, maar ik zou zelf niet weten hoe het te programmeren.

Mozes is niet al te lastig, gewoon alle tegels rood aan, en verder gedragen als normaal: geel aan als er iemand op stapt en dan uitfaden.

Vlek-atack (vlekken die op mensen afkomen) word lastiger, maar is wel een erg leuk idee... Vlekken die bang zijn is ook een erg leuk idee, maar ik zou nu echt nog niet weten hoe.

Misschien is het toch het handigst om de tegels uit te laten zenden wat hun eigen status is (adc waarde/4 en waarde PWM sturing), en de ander tegels daar afankelijk van hun modus (ook in te stellen) iets mee te laten doen.

Wat dachten we eigenlijk van minesweeper? (ook nog geen idee hoe ik dat voor elkaar moet gaan krijgen,maar misschien wel een leuk idee)

Fractals zijn niet eenvoudig, daar zou ik nog eens goed naar moeten kijken, maar the game of life is echt supersimpel.

Er is namelijk maar 1 regel, aan of uit (leven of dood) afhankelijk van het aantal levende buren.

Minder dan 2 levende buren -> dood
Meer dan 3 levende buren -> dood
Precies 3 levende buren -> levend
2 of 3 levende buren -> geen verandering

in code:
Status = ( Buren == 3 ) || ( Buren == 2 && Status );

Dan moet je dus wel weten hoeveel buren er leven, dus ook van de 4 tegels aan de hoekpunten van elke tegel, waar je dus niet direct mee kunt communiceren.

Het lastigste van The Game of Life is dat er steeds een begin gemaakt moet worden om het interessant te maken; dit zou je aan de hand van activiteit op te tegels kunnen doen, of willekeurig af en toe een glider genereren.

Vlek-attack hoeft niet echt moeilijk te zijn, denk ik. Je kunt lichtvlekken hebben met een snelheid en richting, die een voorkeur hebben voor meer actieve tegels. Als elke tegel bijhoudt hoeveel activiteit er is in elke richting, waarbij activiteit die dichter bij is zwaarder gewogen wordt dan activiteit verder weg, kan de vector van de vlek daar met een kleine correctie op aangepast worden. Als je het echt superluxe wilt maken, kun je het Wu algoritme toepassen, waarbij twee aangrenzende tegels allebei een beetje oplichten, als de lichtvlek zich gedeeltelijk onder de ene en gedeeltelijk onder de andere tegel bevindt.

Het idee voor de diertjes is bijna hetzelfde, behalve dat ze niet aangetrokken worden door activiteit, maar juist afgestoten.

Minesweeper lijkt me lastig, omdat je niet gemakkelijk een tegel kunt markeren, omdat je er heen zult moeten lopen. Je kunt natuurlijk alleen over tegels lopen die al open geklikt zijn. Het zou op zich wel kunnen, maar daar moet nog wel even over nagedacht worden.

Het lastige van al deze ideeën is dat ze eigenlijk pas leuk worden als je een behoorlijk groot oppervlak hebt, van toch minimaal een paar honderd tegels.

Op 4 juni 2009 20:53:11 schreef SparkyGSX:
Nee, 1/16de. Je deel het hele veld op in 4 stukken, die je elke weer vanuit het midden gaat voeden, waarbij je elke stuk dus eigenlijk weer in 4 stukken deelt, die vanuit een hoek gevoed worden.

Ik denk dat de spanningsval wel mee zal vallen, aangezien de voeding voor elke willekeurige tegel voor een groot aantal andere tegels aangevoerd zal worden.

Zoiets als dit, dus: http://xkcd.com/356/

Had natuurlijk door dat je bedoelde om het veld in 16 te delen maar dat zei je niet. Waardoor je liet uitschijnen dat het gewoon in 4 opsplitsen, het probleem van de vele voedingkabels helemaal oplost. Je blijft 22 voedingen nodig hebben, of je die nu in het midden of aan de zijkant aansluit, de stroom door de laatste tegel blijft gelijk. (tenzij er al aan elke tegel aan de zijkant van de 'mat' al een voeding zit en dit niet volstaat, dat zal zeker niet het geval zijn)

Op 5 juni 2009 11:27:59 schreef Lucky luke:
Ik bedenk me nu iets: Dat ID byte zou ook gebruikt kunnen worden om de tegels elk een uniek nummer te geven. Dat je in een bepaald patroon over de vloer moet lopen, tegel voor tegel aantikken, als je ze hard genoeg aantikt laten ze hun LED's oplichten, zodat je weet dat je de ...

Is al gezegd indien een bus zou gebuikt worden.

Op 28 mei 2009 00:15:36 schreef plantrekker:
[...]Elk een dip switch 'MAC' adres? Of initialisatie door de tegels in volgorde af te lopen? ... Mogelijkheden genoeg

@ plantrekker

voeding langs de rand (zoals hierboven ergens beschreven) kan wel werken toch? Iig veel voedingspunten.

Met mijn huidig tegelcommunicatieplan wordt dat alsnog lastig...
Conclusie: plan naar prullenbak (letterlijk: het stond op een kladblaaadje)

Nieuw plan:
elke tegel 4 duplex serieële poorten, met klok. SparkyGSX: wil je met uitleggen hoe dat dan werkt? Zou dat dan 9 draden worden? TX1, RX1, TX2, RX2, TX3,RX3, TX4, RX4, gedeelde klok? En hoe dat qua software moet? (ik vrees zo'n beetje handmatig? dus bitje op TX zetten, klok puls geven, andere uC lees bitje in?)

De berichtjes gaan er in het nieuwe plan zo uit zien:
command, Fade, left, right, up, down

command geeft aan welke mode de verzendende tegel in staat (en de ontvangende tegel dus in moet om het bericht te begrijpen)
Fade is de waarde van de PWM van de verzendende tegel (de ontvanger moet het dan maar delen door 4 of wat dan ook, afhankelijk van de mode)

Left geeft aan hoeveel tegels het bericht naar links moet. De ontvangende tegel stuurt het dan door op zijn linker seriele poort na er 1 vanaf te hebben gehaald, tenzij het al 0 is.

right, up en down ook het aantal tegels dat het bericht rechts, omhoog of omlaag moet.

Eventueel left, right, up en down nog een keer erachter om een rechte lijn tussen 2 tegels aan te duiden? weet niet of dat slim is? worden nogal lange berichten dan...

Bij game of life:
Tegel verzend een fadewaarde hoger dan 128: leven
128 of lager: dood
Maar hoe bepaald de ontvanger van welke tegel het afkomt? 'n mode maken waarin je van tegel left,right,up,down de fadewaarde op kan vragen?
dode tegels faden naar 0 of blijven 0
levende faden naar 255 of blijven 255
zoiets?

vlek atack:
(alternatief idee, bedacht voor ik sparkyGSX's laatste post las)
Als iemand ergens op een tegel gaat staan fade een tegel een eindje verder (3 tegels naar links/rechts, 1 omlaag ofzo) van 0 naar 255 als er nog geen licht is ergens (hoe bepaal ik dat?) Die tegel fade uit alsof er op die tegel is gaan staan in "burenmodus". Dan beweegt de vlek richting de tegel waar iemand op is gaan staan. (gaat dat allemaal nog snel genoeg?) (en hoe bepaal ik waar 'ie heen moet?)

bange vlekken:
idem, maar nu licht de tegel naast die waar je op staat op, en beweegt zich al uitfadend verder weg (moet ik ook nog nadenken over hoe dat precies te doen)

SparkyGSX 's ideeën klinken eigenlijk als een beter effect, maar ze vertalen naar basic...

Minesweeper zoals het spelletje word inderdaad een beetje lastig. Maar enkele random tegels (hoe gaan we dat voor elkaar krijgen? Ze gewoon door het veld laten bewegen, zodanig dat je na een tijdje niet meer kunt zeggen waar ze zitten?) laten wachten tot er iemand op stapt, en dan in een flits hard op laten lichten? Met evt een waarschuwend opfaden als je de tegels ernaast betreedt?

Ik moet nog oppassen dat ik met dit project nog aan mijn eigen projectjes toekom...

EDIT:
WBT voeding: gaat dat nou echt een probleem worden voor 16 tegels? of 25? Ik zou ze gewoon per groepje een eigen voeding geven. (van die kleine goedkope schakelende "dikke stekker" voedingen van 1A ofzo.)