Intelligent back-up systeem voor DMX-gestuurd lichteffect

Universiteit Gent Faculteit Ingenieurswetenschappen

Intelligent back-up systeem voor DMX-gestuurd lichteffect Project in het kader van het Vakoverschrijdend Projectvak in de Bachelor Computerwetenschappen Derde Bachelor Ingenieurswetenschappen Computerwetenschappen Academiejaar 2010 - 2011

Promotor: Prof.dr.ir. Benjamin Schrauwen Begeleiders: ir. Francis wyffels dr.ir. Michiel D’Haene ir. Karel Bruneel

Groep 2 Wouter Danneels Maarten Herthoge Sam Van den Steen Jonas Van Nieuwenberg

Inhoudsopgave 1 Inleiding

2

2 Doelstelling

3

3 Technologie 3.1 DMX . . . . . . 3.1.1 Algemeen 3.1.2 Timing . 3.2 Dwengo-bord . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

4 Implementatie 4.1 Inleiding . . . . . . . . . . . . . . . 4.2 Master . . . . . . . . . . . . . . . . 4.3 Slave . . . . . . . . . . . . . . . . . 4.3.1 Opnemen en afgeven van de 4.3.2 Beatdetectie . . . . . . . . . 4.3.3 Communicatie . . . . . . . 4.4 Grafische gebruikersomgeving . . .

. . . .

. . . .

. . . .

. . . .

4 4 4 4 5

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . . . . . sturing . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

6 . 6 . 7 . 8 . 8 . 9 . 12 . 13

5 Resultaten

16

6 Testscenario

20

7 Marktonderzoek

21

8 Gebruikte planning en communicatie 22 8.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.2 Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9 Besluit

25

10 Referenties

26

11 Bijlagen 27 11.1 Vergelijkende tabellen marktstudie . . . . . . . . . . . . . . . . . . . . . . 27

1

1

Inleiding

DMX-512 (Digital MultipleXed, zie 3.1) is d´e standaard om lichteffecten aan te sturen op festivals, concerten, fuiven, ... De laatste jaren ziet men ook hier een trend om alle aansturing te digitaliseren bv. via een PC. PC-sturing breekt echter nog niet door vanwege een gebrekkige betrouwbaarheid. Faalt de PC (probleem in de DMX-software, een driverprobleem, slechte bekabeling), dan faalt ook de sturing en valt de lichtshow stil. Dit is onaanvaardbaar in een professionele omgeving voor soms duizenden aanwezigen. Er zijn reeds systemen op de markt met een beperkte hoeveelheid geheugen die in geval van falen van de aansturende PC de laatste stappen in een show herhalen. Deze systemen zijn vaak zeer duur en hun grote gebrek is dat ze enkel voorzien in een statische (gedeeltelijke) show die geen rekening meer houdt met de muziek op dat moment. Dit kan storend en ook medisch niet verantwoord zijn. Voorbeeld van dit laatste is een stroboscoop die blijft flikkeren waardoor het risico op een epileptische aanval onder de aanwezigen sterk toeneemt. Een crash van de aansturende PC of zelfs van gespecialiseerde lichtcontrollers is niet ondenkbaar, aangezien dergelijke toestellen steeds complexer worden. De stuursoftware op een PC draait op een besturingssysteem waarin iets fout kan lopen. Er kan een bug in de stuursoftware zitten die enkel in heel specifieke omstandigheden tot uiting komt en daardoor niet gedetecteerd werd tijdens ontwikkeling. Door warmte of een vochtige omgeving (bv. rookvloeistof die als een nevel neerdaalt na gebruik) kan zelfs een gespecialiseerde controller falen. Als voorbeeld geven wij een avond in La Rocca in Lier waarbij de lichtsturing faalde (zie figuur 1). Door deze crash zaten plots de meer dan duizend bezoekers van de bekende discotheek in het donker. De kans is groot dat sommige bezoekers teveel hadden gedronken, security had geen overzicht meer van de zaal en iedereen zag nog nauwelijks iets. Als er in dergelijke omstandigheden in zo een massa paniek uitbreekt, is er weinig wat de veiligheid van de bezoekers kan garanderen. Zoals het geval in La Rocca zijn er nog talloze bekend. Zelfs van producten van de grote fabrikanten als Martin zijn er gevallen bekend waarbij toestellen specifiek ontworpen voor enkel en alleen lichtsturing crashten. Dergelijke crashes en hun gevolgen proberen we in dit project op een zo goed mogelijke manier op te vangen.

2

Figuur 1: Crash van controller (La Rocca, Lier)

2

Doelstelling

Het doel van ons project is een intelligent back-up systeem te maken voor ´e´en of meerdere DMX-gestuurde lichteffecten. Dit systeem moet de controle van het lichteffect overnemen indien de bedoelde DMX-sturing (bv. PC, analoge stuurtafel) onverwachts wegvalt. Hierbij moet het systeem rekening houden met de muziek op dat ogenblik. Dit alles moet zo onopvallend mogelijk gebeuren. Het moet ook mogelijk zijn om de controle terug te geven aan de bedoelde aansturing indien deze terug in staat is de effecten aan te sturen. Om dit te realiseren moeten we eerst een schakeling bouwen met microcontrollers die DMX-signalen kunnen ontvangen en versturen en een audiosignaal kunnen verwerken. Daarnaast moeten we ook een PC-interface schrijven die het systeem van de nodige informatie voorziet om zich bewust te zijn van de functionaliteit van het aangesloten effect. We zullen ook mogelijkheden bestuderen om het systeem uit te breiden naar meerdere lichteffecten of clusters van lichteffecten. Om het systeem te testen, zullen we een lichteffect aansluiten en dit aansturen met DMX via PC of een analoge stuurtafel. Op een willekeurig moment laten we de bedoelde aansturing wegvallen waarbij ons systeem zo onopvallend mogelijk de controle moet overnemen. Als de bedoelde aansturing alles terug kan overnemen, moet ons systeem dit ook zonder problemen toelaten. De toegevoegde redundantie zou de doorbraak kunnen betekenen voor DMX-sturing via PC. Daarnaast zien we ook de mogelijkheid om ons systeem te gebruiken bij kleine lichtshows als complete vervanging van andere DMX-sturing.

3

3

Technologie

3.1 3.1.1

DMX Algemeen

Digital MultipleXed 512 (DMX-512 of kortweg DMX) is een busprotocol met als basis RS-485, een protocol rond seri¨ele communicatie [1]. Doordat RS-485 een protocol is dat 9 bit woorden gebruikt, brengt dit ook beperkingen met zich mee voor DMX. Zo zijn er slechts 512 adressen beschikbaar. DMX wordt voornamelijk gebruikt bij het aansturen van lichteffecten. Aangezien DMX een busprotocol is, betekent dit dat alle lichteffecten op de bus zijn aangesloten als randapparatuur. Qua structuur wijkt het echter af van de typische bus. De lichteffecten hebben een ingang, waar DMX-signalen binnenkomen, en een uitgang die alle DMX-data gewoon doorstuurt. Zo worden de uitgang en ingang van opeenvolgende lichteffecten met elkaar verbonden en ontstaat er een bus onder de vorm van een zogenaamde daisy-chain. Een belangrijk nadeel hiervan is dat als er zich een defect voordoet in een toestel of in een kabel tussen 2 toestellen, dat de bus na dat defect onderbroken is en de volgende aangesloten toestellen ook geen signaal meer ontvangen. Elk lichteffect heeft op voorhand een adres toegekend gekregen vari¨erend van 0 tot 512. Omdat het DMX-protocol een busprotocol is, is all data beschikbaar op de bus voor alle lichteffecten. Elk toestel moet dus zelf beslissen welke data voor hem is. Dit gebeurt aan de hand van het adres dat het lichteffect heeft gekregen. Het lichteffect telt de ontvangen bytes. Deze bytes worden in het DMX-protocol kanalen genoemd. Een toestel heeft een vast aantal kanalen die het gebruikt en interpreteert om zijn functies aan te sturen. Wanneer de ontvanger tot aan zijn eigen adres heeft geteld, weet hij dat de daaropvolgende kanalen voor hem bedoeld zijn. 3.1.2

Timing

Figuur 2: Timing van een DMX-pakket Een DMX-pakket heeft een specifieke opbouw (zie figuur 2). Tussen verschillende DMXpakketten wordt het signaal laag gebracht. Dit wordt de break genoemd. Om het begin van een pakket aan te geven, wordt het signaal eventjes hoog gebracht, de mark after 4

break. Hierop volgt een startcode (een byte met waarde 0) gevolgd door de eigenlijke inhoud van het pakket. De inhoud van een DMX-pakket bestaat uit DMX-frames. Tussen 2 frames kan er eventueel nog een inter-frame-time voorkomen van variabele lengte. Elk onderdeel heeft strenge timingeisen (zie tabel 1). Beschrijving Break Mark After Break Bit Time DMX pakket

Minimum [µs] 92 12 3,92 1204

Maximum [µs] <1.000.000 4,02 1.000.000

Typisch [µs] 176 4 -

Tabel 1: Timing waarden van het DMX-protocol De opbouw van een DMX-frame is te zien in figuur 3. Een frame begint met een nulbit, de startbit. Deze wordt gebruikt om het onderscheid te maken tussen de stopbits/interframe-time en de eigenlijke data. Na de startbit volgt de data in Little Endian, gevolgd door twee stopbits, die hoog gezet worden. De tijd per bit moet rond 4 µs liggen. Hierdoor hebben we het DMX-protocol op de microcontroller deels in C, deels in de assembly-instructieset van de microcontroller moeten programmeren om aan de strenge timingeisen te voldoen.

Figuur 3: Timing van een DMX-frame

3.2

Dwengo-bord

In ons project gebruiken we enkele Dwengo-experimenteerborden [3]. Deze zijn opgebouwd rond de PIC18F4550 microcontroller. De controller heeft een woordlengte van 8 bit en werkt aan een snelheid van 12 miljoen instructies per seconde (MIPS) met een kloksnelheid van 48 MHz. We gebruiken ook de ingebouwde USART-module. Naast het Dwengo-bord gebruiken we enkele SP485CS-L transceiver chips voor het RS485 protocol op het breadboard. Deze zijn specifiek voorzien om RS-485 communicatie te verzenden. Later in het project werd hier nog een gesoldeerde schakeling voor muziekanalyse aan toegevoegd (zie sectie 4.3.2). 5

4 4.1

Implementatie Inleiding

Onze eindoplossing is opgebouwd uit drie modules zoals weergegeven in figuur 4. Twee van deze modules worden ge¨ımplementeerd op een microcontroller, de derde module is een Java-applicatie.

Figuur 4: Weergave van een mogelijke opstelling. Er zijn drie DMX-subnetwerken die bij een faling van de hoofdcontroller elk afzonderlijk aangestuurd zullen worden door hun eigen slavecontroller. Om te beginnen beschikken we over een zogenaamde Master-module of master (sectie 4.2). Dit is de microcontroller die zich bevindt tussen de computer en het DMX-netwerk. Deze module heeft als taak de data die hij via seri¨ele communicatie van de computer ontvangt om te zetten naar geldige DMX-signalen en vervolgens uit te sturen over het DMX-net. Daarnaast doet de master dienst als een soort programmer voor de aangesloten slaves. Binnen het DMX-netwerk vinden we dan een aantal modules van het tweede type, de zogenaamde Slave-modules of slaves (sectie 4.3). Het gaat hier opnieuw om microcontrollers, die ditmaal de back-up taak voor hun rekening zullen nemen. Deze modules moeten in staat zijn problemen met de DMX-sturing te detecteren en zo nodig zelf DMX-signalen te genereren. De laatste module is een grafische gebruikersinterface (sectie 4.4). Deze verzorgt de interactie met de gebruiker en biedt de mogelijkheid om binnen een grafische omgeving een eenvoudig zaalplan met lichten en back-up microcontrollers (slaves) op te bouwen. Bovendien is de gebruiker in staat om zelf een eenvoudige DMX-show op te stellen door 6

gebruik te maken van een systeem met tijdsassen. De laatste functionaliteit die door deze applicatie aangeboden wordt is het verzenden van configuratie- en show-data naar de master.

4.2

Master

De master is een speciaal geprogrammeerde microcontroller die dienst doet als een soort programmer voor de andere controllers (de slaves) en als een eenvoudige DMX-sturing via PC. Via een seri¨ele interface op de microcontroller kunnen we de master verbinden met een PC zodat die aangestuurd kan worden met behulp van onze GUI (sectie 4.4). Omdat de microcontrollers een beperkte rekencapaciteit hebben, zal de master eerst alle ontvangen configuratiebytes van de PC bufferen. Eens alle bytes van de pc ontvangen zijn, zal de master deze doorsturen naar de slaves. Zo krijgen die voldoende tijd om de datastroom te verwerken en de bytes die voor hen bedoeld zijn in te lezen. Voor de buffer is 2048 byte geheugen gereserveerd op de master. Door de eenvoudige en beperkte configuratie (maximaal 10 bytes per slave afhankelijk van de gekozen configuratie-opties), is deze hoeveelheid geheugen ruim voldoende. In onze testopstelling hebben we ook een gebruikelijke vorm van DMX-sturing nodig. De master hebben we zodanig uitgebreid dat deze na de configuratiemodus dienst doet als eenvoudige DMX-sturing. Via de GUI kunnen we dan een lichtshow aanmaken en uitvoeren. Als de slaves DMX-data ontvangen, dan sturen ze deze door op hun beide uitgangen. We kunnen dus vanuit de GUI via de master alle aangesloten lichteffecten individueel controleren. Op deze manier kunnen we het overnemen van de aansturing door de slaves in geval van falen van de normale aansturing testen (zie 4.3.1). Tot slot was er nood aan een mechanisme om uitgebreide shows door te sturen via de computer naar onze Master-module. De gebruikte microcontrollers beschikken immers slechts over een flashgeheugen van 32 KiB zodat we maximaal 64 compleet verschillende DMX-stappen lokaal kunnen opslaan. Een betere methode zou zijn om op ieder ogenblik slechts twee verschillende DMX-sequenties te bufferen op de microcontroller, enkel de huidige en (een deel van) de volgende stap. Dit vereist een buffergrootte van slechts 1024 bytes. Een probleem hierbij is dat de master, eens het netwerk geconfigureerd is, constant DMX-signalen moet uitzenden. Het bufferen van nieuwe frames moet dus parallel hiermee gebeuren. We hebben een oplossing voor dit probleem gevonden dankzij de flexibiliteit die DMX biedt ten opzichte van de break-tijd. Dit is de duur tussen twee frames (zie sectie 3.1). Tijdens deze break wordt er een constante waarde verstuurd, er hoeft dus niets nieuws berekend te worden. We zijn dus in staat om aan het einde van ieder DMX-frame een timer te starten en gedurende een vooraf bepaald tijdsinterval nieuwe waarden in te lezen van de computer. Dit gebeurt door eerst een controlevariabele naar de GUI te sturen. Deze deelt mee wat het volgende verwachte kanaal is (vergelijkbaar met het sequentienummer in een TCP-stroom). Vervolgens stuurt de GUI een reeks van maximaal 6 7

nieuwe kanaalwaarden uit, uiteraard startend met de kanaalwaarde die aangevraagd werd. Deze bovengrens van 6 werd zo gekozen om te zorgen dat er niet te veel informatie ineens gestuurd wordt, zodat de Master tijdig terug kan starten met het uitsturen van de volgende DMX-iteratie. Merk op dat eenzelfde DMX-frame typisch meerdere keren per seconde herhaald wordt, waardoor het inderdaad zinvol is om het nieuwe frame te bufferen tussen deze herhalingen. Er dient opgemerkt te worden dat deze laatste feature in feite een uitbreiding is op de doelstellingen van ons project, aangezien dit niets te maken heeft met de back-up problematiek. Het bufferen van DMX-frames die doorgestuurd worden door de computer moet immers enkel gebeuren wanneer het systeem zich in zijn normaal functionerende toestand bevindt. Daarom hebben we deze functionaliteit slechts aan het einde van het project ge¨ımplementeerd. De theoretische onderbouw voor het bufferen was reeds volledig uitgewerkt, maar bij de technische implementatie zijn we op een extra moeilijkheid gestoten. Door de grootte van de buffer was het nodig deze te indexeren met 10 bits, daar waar wij voorheen nog alle buffers konden aanspreken met 8 bits. Dit kwam neer op het gebruiken van een int (2 bytes op onze microcontroller) in plaats van een char (1 byte). Omdat de woordbreedte van de gebruikte microcontrollers 8 bits is, leverde dit een aantal problemen op. De berekeningen met deze nieuwe variabelen duurden zo lang door de extra instructies en I/O-operaties van het geheugen, dat zij de strenge timingwaarden van het DMXprotocol in het gedrang brachten. Dit probleem is niet effici¨ent op te lossen op ons type microcontroller omdat het indexeren van de buffer nu langer dan 4 µs duurde. Dit is te lang volgens de eisen die het protocol stelt. Wij waren echter van mening dat ons eindproduct zo compleet mogelijk moest zijn. Daarom hebben we twee beperkingen opgelegd aan de dynamische shows die door de GUI uitgezonden worden. Aan de ene kant leggen we een bovengrens op het aantal aanstuurbare kanalen: 256 in plaats van 512. Anderzijds stappen we af van de gescheiden buffer met plaats voor het oude en nieuwe frame. In plaats daarvan gebruiken we een buffer die exact 256 kanalen kan bevatten en laten we de oude kanalen gaandeweg overschrijven door hun nieuwe waarden. Dit levert goede prestaties voor het aansturen van een bescheiden cluster van DMX-toestellen. Wanneer we echter een groot aantal lichteffecten tegelijk op deze manier aansturen, zien we de nieuwe instellingen als het ware doorsijpelen van lichteffect naar lichteffect. Omdat deze functionaliteit geen onderdeel is van ons project, hebben we dit niet verder uitgewerkt of geoptimaliseerd.

4.3 4.3.1

Slave Opnemen en afgeven van de sturing

De volgende stap in het implementatieverloop was het uitwerken van een mechanisme dat de gedistribueerde microcontrollers (slaves) in staat stelt om te detecteren wanneer 8

de sturing van de hoofdcontroller (master) wegvalt. Wanneer dit gebeurt, moet iedere slave zijn eigen subnetwerk van DMX-aangestuurde toestellen kunnen voorzien van een minimale noodsturing. De slaves mogen hierna echter het hoofdnetwerk niet uit het oog verliezen. Het is immers mogelijk dat het probleem met de master na een tijd opgelost wordt. De slaves moeten dus ook de mogelijkheid hebben om te controleren of het oorspronkelijk DMX-signaal hersteld werd. Zij moeten dan de sturing opnieuw overlaten aan de hoofdcontroller. Om dit probleem aan te pakken, maken wij gebruik van de interrupt-functionaliteit aanwezig op onze microcontrollers. We beschikken over twee prioriteitsniveaus, onderbrekingen met lage prioriteit en met hoge prioriteit. In de hoge prioriteitscode laten we veranderingen op de poort die verbonden is met de DMX-input-kabel registreren. Deze veranderingen worden vervolgens onmiddellijk gepropageerd naar de poort die verbonden is met de DMX-output-kabel. Op deze manier zijn de slaves in staat om, bij correcte werking van de hoofdsturing, passief DMX-signalen door te sturen zonder zich zelf te moeten bekommeren om alle timingdetails. Naast dit doorstuurmechanisme starten we in de lage prioriteitscode een timer. Deze heeft als enige taak te meten wanneer de laatste verandering op de ingangspoort plaatsvond. Wanneer de timer detecteert dat er gedurende een vooraf bepaald tijdsinterval geen nieuwe ingangssignalen waren, zal deze een vlag actief maken om te signaleren dat er problemen zijn met het hoofdnetwerk. De microcontroller neemt vervolgens de controle over en start met het uitvoeren van de ingestelde back-up-mode (zie sectie 5). Wanneer het systeem zich in zijn back-up toestand bevindt, zijn de lage prioriteitstimers uitgeschakeld. Indien er zich echter veranderingen op de ingangspoort voordoen, wordt er nog steeds een onderbreking met hoge prioriteit gegenereerd. Deze zal de backup-vlag en bijhorende timer opnieuw resetten zodat de microcontroller stopt met zelf DMX-signalen te genereren. De slave zal dan terug passief de binnenkomende signalen doorsturen. 4.3.2

Beatdetectie

Hardware Elk liedje heeft een bepaald ritme. Dit ritme wordt voornamelijk bepaald door de aanwezige lage tonen. Omdat de microcontrollers niet snel genoeg zijn om zowel DMX-signalen te genereren als de signaalverwerking voor het identificeren van deze lage tonen uit te voeren, hebben we een schakeling ontworpen die hardwarematig de beats detecteert.

9

Figuur 5: Schakeling die beats in muziek omzet naar blokgolven De ontworpen schakeling is opgebouwd rond vijf blokken (zie figuur 5). Een microfoontje vangt het omgevingsgeluid op. De voorversterker (pre-amp) zorgt voor een geluidsignaal dat voldoende sterk is om verder te bewerken. Dit deel van de schakeling hebben we gevonden op het internet [4]. Vervolgens wordt de DC-component weggefilterd met behulp van een condensator en wordt het voltage opgetrokken naar een gemiddelde van 2.5 volt. Hiervoor zorgt de spanningsdeler bovenaan de figuur van de schakeling. Dan wordt het versterkte signaal door een eerste orde laagdoorlaatfilter gestuurd. De 1 transferfunctie van een dergelijk filter is: RC+1 . R en C werden zodanig gekozen dat de cutoff-frequentie laag genoeg was zodat er enkel lage tonen werden doorgelaten. De lage tonen in muziek hebben een bereik van 20 tot 200Hz. Er werd gekozen voor een cutoff frequentie van ongeveer 194Hz. Volgens bovenstaande formule komt dit overeen met een weerstand van 8.2 kΩ en een condensator van 100 nF. Het signaal dat hier verkregen wordt, is echter nog steeds analoog. Het is nog niet geschikt als ingangsignaal voor de microcontroller. Dit analoog signaal moet getransformeerd worden naar een blokgolf. Dit gebeurt in twee stappen. In de eerste stap worden de lage tonen gedetecteerd. De hoge niveaus moeten overeenkomen met een lage toon, de lage niveaus met het ontbreken van lage tonen. Daarom wordt er gebruik gemaakt van een pulsgenerator op basis van een operationele versterker of opamp. Door als referentiespanning 2.5 volt te kiezen in combinatie met een potentiometer kan het niveau waarbij de opamp schakelt zo worden ingesteld dat deze enkel bij de lagere tonen schakelt. Zo wordt er voor elke lage toon een verzameling pulsen gegenereerd.

10

In de tweede stap gebeurt de eigenlijk transformatie naar een blokgolf. De pulsen worden door een diode gestuurd naar de condensator en de weerstand die er achter liggen. Doordat de condensator moet opladen en weer ontladen kan deze gebruikt worden voor het transformeren naar een soort blokgolf. Deze blokgolf is niet perfect (zie figuur 6), maar wel goed genoeg om door een digitale schakeling herkend te worden als een ´e´en en een nul.

Figuur 6: Beeld van de oscilloscoop met bovenaan het originele muzieksignaal opgevangen door de microfoon en onderaan de output van de beatschakeling De condensator en weerstand mogen uiteraard niet zomaar gekozen worden. Ook hier RC wordt eerst de transferfunctie opgesteld. Deze is RC+1 . De tijdsconstante RC moet groot genoeg zijn zodat ´e´en lage toon naar ´e´en blokgolf wordt omgezet. Experimenteel werd bepaald dat een lage toon rond de 60 ms duurde. Met een weerstand van 8.2 kΩ en een condensator van 6.8 µF wordt een waarde van 55 ms bekomen. Dit is dus nauwkeurig genoeg om een lage toon te transformeren naar een blokgolf. Uiteindelijk kan dit signaal dan gebruikt worden als ingangsignaal voor de digitale schakeling. Software Vervolgens moeten deze digitale beatsignalen geanalyseerd worden door de microcontroller. Oorspronkelijk was het ons idee om dit ook te doen door middel van onderbrekingen. We zouden dan gebruik maken van timers om op een nauwkeurige manier de beatfrequentie te meten. Op basis van deze frequentie kan de microcontroller dan op een intelligente manier de lichteffecten aansturen op het ritme van de muziek. In de praktijk leverde deze methode echter een aantal problemen op. Om te beginnen moet het sample interval voldoende groot zijn om een betrouwbare meting van de frequentie te bekomen. Hierdoor kon het systeem niet ogenblikkelijk reageren op tempoveranderingen in de muziek. Een veel groter probleem was echter de timingvoorwaarden. Doordat de beatsignalen zich op willekeurige tijden aanbieden, kan zich een onderbreking 11

voordoen tijdens het verzenden van een DMX-frame. Als dit gebeurt kunnen we niet langer garanderen dat de DMX-signalen voldoen aan de strenge timingnormen. Daardoor zullen de lichteffecten ongeldige signalen uitlezen. Onze software moet bijgevolg in staat zijn om deze twee taken parallel uit te voeren. Enerzijds moeten we constant het ritme van de muziek analyseren en anderzijds moet ook het DMX-signaal constant uitgezonden worden. De microcontrollers die wij gebruikt hebben, bieden echter geen dergelijke vorm van parallellisme aan. Om bovenstaand probleem op te lossen hebben we geprobeerd om deze twee acties te integreren. Het is namelijk zo dat er aan het einde van iedere frame een breakperiode komt, waarvan de duur variabel is binnen aanzienlijke grenzen. We gebruiken dit interval om aan het einde van ieder DMX-pakket gedurende een periode van ongeveer 1 ms de beatsignalen te analyseren. De precieze duur van dit tijdsinterval hangt samen met de gebruikte technologie. Wij werken met een microprocessor die 12 miljoen instructies per seconde (MIPS) uitvoert. Iedere instructie duurt dus 83,33 ns. Door het aantal instructies dat de timer telt alvorens zijn onderbrekingsvlag te activeren correct in te stellen, kunnen we het gewenste meetinterval benaderen. Verder is het zo dat de kanaaldata van ´e´en DMX-pakket nooit langer dan 22,528ms duurt. Er zijn immers maximaal 512 kanalen. Elk kanaal wordt verzonden onder de vorm van een startbit, 8 databits en 2 stopbits. Iedere bit moet gedurende 4 µs zijn waarde aanhouden. Hieruit volgt dat we iedere 25 ms ongeveer 1 ms spenderen aan het analyseren van de beats. Typisch bevindt het ritme van een muzieknummer zich tussen de 100 en de 150 beats per minuut. Dit betekent dat er nooit meer dan drie beats per seconde zullen optreden. Op deze manier moet ons systeem dus perfect in staat zijn om alle beats te detecteren. Door het analyseren van het geluidsignaal om de 25 ms kunnen we de stijgflank detecteren die een beat aangeeft. Bovendien krijgen we het extra voordeel dat we nu ook binnen de 25 ms na het optreden van een beat de status van de DMXtoestellen kunnen aanpassen. Dit lijkt voor het menselijk oog op een ogenblikkelijke respons op de muziek. 4.3.3

Communicatie

Voor de communicatie tussen de microcontrollers onderling en de microcontrollers met de PC gebruiken we het RS-232 protocol. De Dwengo-borden beschikken over de nodige aansluiting en technologie. Bovendien kunnen we de bibliotheken van Microchip van ons type microcontroller voor RS-232 gebruiken. Alle communicatie wordt over dezelfde kabels als die voor DMX gestuurd. Zo zijn er geen aparte kabels voor de communicatie nodig. Tijdens deze communicatie kunnen er uiteraard geen DMX-signalen worden verzonden. Een aparte microcontroller doet dienst als een soort programmer van de andere controllers en als buffer tussen de PC en de andere microcontrollers. De taak van deze controller is om eerst alle data van de PC in te lezen en deze daarna met extra vertragingen door

12

te sturen. Deze delays zijn nodig om de andere microcontrollers de tijd te geven om de ontvangen bytes te interpreteren en de correcte actie te ondernemen. De delays zijn nooit langer dan een microseconde. Daarnaast kan deze controller ook dienst doen als DMX-aansturing met behulp van de GUI (sectie 4.4). Bij het inschakelen van de slave-modules, kan de gebruiker via de drukknoppen op het Dwengo-bord het startadres invoeren. Als er binnen een bepaalde periode geen manuele invoer komt, leest de slave automatisch het laatst gebruikte adres uit het EEPROM. Vervolgens schakelt het systeem over naar een configuratietoestand. In deze toestand kunnen ze door het ontvangen van een eenvoudige header (twee startbytes en twee adresbytes) nagaan welke bytes voor hen bedoeld zijn. De startbytes in de header zijn nodig omdat de microcontrollers heel vaak ruis interpreteren als data in het RS-232 protocol als er door de programmer nog geen configuratiedata wordt gestuurd. We kiezen twee bytes omdat de kans dat de microcontroller in de ruis toevallig deze twee verschillende bytes in volgorde detecteert voldoende klein is. Het adres van een controller is tegelijk ook het laagste adres van alle lichteffecten verbonden aan die controller. Omdat DMX 512 mogelijke adressen heeft, moeten we het adres opsplitsen in twee bytes. Door het ontvangen en verwerken van deze header kan een microcontroller weten welke bytes voor hem bedoeld zijn. De eerder genoemde delays zijn nodig om de microcontrollers voldoende tijd te geven om de header te verwerken. De eerste byte die na de header wordt ingelezen bepaalt het type show. Momenteel zijn er twee shows voor de LED-spots in onze testopstelling beschikbaar. Beide reageren op muziek. Afhankelijk van het type show krijgen de daaropvolgende ontvangen bytes een specifieke betekenis voor de microcontroller.

4.4

Grafische gebruikersomgeving

Het laatste onderdeel van onze oplossing is de grafische gebruikersomgeving (GUI). Deze laat een gebruiker toe om op een visuele wijze een schaalmodel van de zaalindeling na te bouwen en vervolgens de gewenste configuratie en DMX-signalen uit te sturen over het netwerk. Om dit te realiseren voorziet de GUI twee aparte onderdelen, met name een tabblad voor de grafische indeling (RoomPanel) en een tabblad voor het opbouwen van DMX-shows (ShowPanel). RoomPanel De gebruiker kan een tweedimensionaal veld cre¨eren dat de zaal voorstelt. Dit paneel bevat een aantal knoppen om DMX-toestellen toe te voegen en te verwijderen. Figuur 7 toont een mogelijke zaalindeling met twee back-up modules en een aantal lampen die elk aangestuurd zullen worden door een van deze microcontrollers.

13

Figuur 7: Grafische layout van een zaalopstelling Wanneer de gebruiker kiest om een nieuw toestel toe te voegen verschijnt er een dialoogvenster waarin een aantal eigenschappen van het toestel meegegeven kunnen worden. In het geval van een licht wordt er bijvoorbeeld gevraagd naar het aantal DMX-kanalen, wat ieder kanaal controleert (bijvoorbeeld een RGB-kanaal of een strobe-kanaal)en uiteraard welke microcontroller verantwoordelijk is voor de back-up van dit toestel. Wanneer er een nieuwe back-up module toegevoegd wordt, moet de gebruiker eerst selecteren welke back-up show hij wenst te gebruiken. Vervolgens wordt het dialoogvenster dynamisch aangepast om de verdere configuratieparameters voor de desbetreffende show in te stellen. Een voorbeeld van hoe dit dialoogvenster er kan uitzien wordt getoond in figuur 8.

Figuur 8: Dialoogvenster voor het toevoegen van een back-up module

14

ShowPanel Zodra de gebruiker een plan heeft opgesteld van de zaalindeling, kan hij overschakelen naar het show-tabblad. Hier wordt een overzicht weergegeven van alle lampen die zich in de zaal bevinden. Er wordt ook voor iedere lamp een tijdslijn weergegeven die aangeeft welke waarden achtereenvolgens naar zijn verschillende kanalen gestuurd worden. Onderaan dit venster is er een eenvoudige interface om verschillende showstappen aan de tijdslijn van de geselecteerde lamp toe te voegen. Ingeval de GUI detecteert dat het gaat om een RGB-lamp, wordt deze interface automatisch uitgebreid met een kleurpaneel dat toelaat om op een visueel voor de hand liggende manier kleuren toe te kennen aan deze lamp. Figuur 9 geeft een algemeen idee van de layout van het ShowPanel.

Figuur 9: Grafische layout van een DMX-show. Bovenaan een willekeurig DMX-toestel met 3 kanalen. Onderaan een RGB-lamp met 4 kanalen waarvan de 3 kleurkanalen gecombineerd werden tot ´e´en tijdslijn.

15

5

Resultaten

Uiteindelijk zijn we er in geslaagd om alle voorgestelde functionaliteit te implementeren. Ons eindproduct is een goedkope oplossing die dienst doet als noodoplossing wanneer het DMX-signaal van de hoofdcontroller uitvalt. In tabel 2 vindt u een overzicht van de specificaties waaraan de mastermodule voldoet. De seri¨ele communicatie tussen de GUI en onze mastermodule gebeurt typisch aan een snelheid van ongeveer 1 kBps. Tijdens het dynamisch bufferen van nieuwe DMX-frames is er ongeveer een twintigste van de tijd voorzien om aan deze snelheid gegevens door te sturen (sectie 4.2 ). De doorvoersnelheid bij gebruik is dus ongeveer 50 bytes per seconde. Specificaties Master Communicatie Theoretische maximumsnelheid Pieksnelheid GUI-communicatie Tijdsgemiddelde buffersnelheid Pieksnelheid Slave-communicatie Aansturing Buffering Statisch Max. kanalen 512 Minimale duur DMX-stap 0,5 s

1,2 kBps ca. 1 kBps ca. 50 Bps 1,2 kBps Dynamisch 256 0,5 s

Tabel 2: Specificaties Master Module In tabel 3 staat een overzicht van de specificaties waaraan de slavemodule voldoet. Bij het overnemen van de sturing hebben we er zelf voor gekozen om een vertraging van ongeveer een seconde toe te voegen. Dit is nodig aangezien het kan voorvallen dat er even geen signaalveranderingen doorkomen terwijl de sturing wel nog steeds correct werkt. Dit komt door de variabele break tussen twee DMX-frames (zie sectie 3.1). De controller zou dan ten onrechte denken dat de sturing is weggevallen en het overnemen. Het afgeven van de sturing gebeurt door een high priority interrupt. Daarom is het hier niet nodig om een vertraging toe te voegen. Ieder type DMX-toestel kan een verschillend aantal kanalen gebruiken. Bovendien is de informatie die elk van deze kanalen bevat niet op voorhand geweten. Zo is het mogelijk dat het eerste kanaal van een LED-lamp informatie bevat over de roodcomponent van de gewenste kleur. Het eerste kanaal bij een moving head (een dynamisch lichteffect met bewegende kop) kan de x-positie van de stralenbundel uit de kop van de lamp aangeven. Deze vrijheden zorgen ervoor dat al deze informatie over de kanaaldistributie in de slavemodule aanwezig moet zijn om een zinvol back-up effect voor het specifieke lichteffect te genereren. Daarom hebben wij bij ons proof-of-concept de subnetten beperkt tot slechts ´e´en type lichteffect Er kunnen wel meerdere toestellen van eenzelfde type toegevoegd 16

worden, zolang het totaal aantal kanalen maar onder de 256 blijft. Deze bovengrens van 256 kanalen is een gevolg van de gebruikte technologie (zie sectie 4.2). Stel dus dat we een DMX-subnet opbouwen, bestaande uit LED-lampen met elk vier kanalen (rood, groen, blauw en strobe), dan kunnen er maximaal 64 verschillende lampen van dit type door eenzelfde slave aangestuurd worden. Mits een uitbreiding van ons eigen configuratieprotocol moet het theoretisch gezien mogelijk zijn om de complexiteit van de subnetten uit te breiden met meerdere toesteltypes. Dit zou ondermeer vereisen dat de slave perfect weet wat het type is van ieder lichteffect in zijn netwerk. In geval van grote subnetten is het duidelijk dat dit snel voor een aanzienlijke overhead in de configuratiestap zou zorgen. In het slechtste geval kan dit tot opslagproblemen op de microcontroller leiden. Omdat wij binnen onze testopstelling echter enkel over eenvoudige LED-lampen beschikten, zouden we niet in staat geweest zijn deze code grondig genoeg te testen. Daarom hebben wij gekozen om ons toe te spitsen op subnetwerken met slechts ´e´en toesteltype. Specificaties Slave Communicatie Theoretische maximumsnelheid Pieksnelheid Master-communicatie Back-up Reactietijd bij wegvallen sturing Reactietijd bij teruggeven sturing Maximum aantal kanalen Aantal verschillende toesteltypes Aanwezige back-up modes

1,2 kBps 1,2 kBps 0,8738 s Ogenblikkelijk 256 1 2

Tabel 3: Specificaties Slave Module In onze slave-module werden bij wijze van proof-of-concept twee unieke back-up modes, shows genoemd, ge¨ımplementeerd. Een eerste show is in staat om de even en oneven lampen binnen het DMX-subnetwerk afzonderlijk aan te sturen. Dit gebeurt door deze lampen beurtelings aan en uit te schakelen op het ritme van de muziek. Verder maakt deze mode ook gebruik van een teller om na een aantal beats de lichtkleur te wisselen. Momenteel zijn er 15 sterk verschillende kleuren vastgelegd. Dit laat toe om tijdens een demo de werking duidelijk te illustreren. Het is echter perfect mogelijk dit aantal uit te breiden naar alle mogelijke kleuren en kleurtinten die de toestellen aankunnen. Omdat de kleuren worden berekend aan de hand van een algoritme, gebruikt deze maximaal 1024 bytes geheugen indien de slave alle 512 kanalen moet aansturen met deze show. Dit is ruim binnen de grenzen van onze huidige microcontroller. De tweede show maakt gebruik van een aantal meer geavanceerde visuele technieken. Bovendoen laat hij ook extra configureerbaarheid door de gebruiker toe. Het gaat hier om een fader-gebaseerde lichtshow. De gebruiker kan kiezen om twee kleuren uit een 17

voorgeprogrammeerd gamma van acht kleuren in te stellen (tabel 4). De slave-module zal vervolgens de even en oneven lichten laten afwisselen tussen deze twee kleuren op het ritme van de muziek. Een probleem met de eerste back-up is dat deze enkel van toestand wisselt wanneer er een bastoon gedetecteerd wordt. Nu is het echter perfect mogelijk dat er een nummer gespeeld wordt waarin er even geen beats voorkomen, dit wordt een break genoemd. Tijdens zo’n break zou een show die enkel luistert naar bastonen constant in dezelfde toestand blijven. Bij deze lichtshow hebben wij dan ook gezorgd dat breaks door middel van een primitieve timer gedetecteerd worden. Wanneer we ons in zo’n break-toestand bevinden zullen alle lampen binnen het DMX-netwerk tegelijk faden tussen de twee door de gebruiker gekozen kleuren. De snelheid van deze fader is ook in beperkte mate instelbaar tijdens de configuratie. Op deze manier blijft de show ook tijdens rustigere stukken van een nummer visueel aantrekkelijk. Fader specificaties W R G B Kleur 1 Z C M G W R G B Kleur 2 Z C M G Snelheid Snel Traag Tabel 4: Specificaties van de Fader back-up show Tijdens het ontwerpproces van deze shows hebben we eveneens een derde aansturingsmogelijkheid onderzocht, een zogenaamde lopende lamp. De idee hier was dat alle lampen hetzelfde zouden oplichten, behalve ´e´en lamp die een aparte kleur krijgt. Bij iedere beat zou die unieke spot dan opschuiven naar de volgende positie in de keten, vergelijkbaar met een primitieve teller. Rekentechnisch waren we perfect in staat dit te implementeren, maar doordat we bij onze testopstelling slechts over twee lampen beschikten, hebben we er voor geopteerd om dit idee niet verder te ontwikkelen naar de einddemo toe. Er is immers geen visueel verschil tussen dit soort aansturing en een aansturing die enkel onderscheid maakt op even en oneven posities. Onze huidige code neemt ongeveer 25% van het aanwezige programmageheugen in. Deze code omvat ook alle logica voor het uitzenden van DMX, aanvaarden van configuratieparameters, overnemen en afgeven van de sturing en dergelijke meer. Wij hebben ervoor gekozen om lichteffecten in een beperkt aantal groepen aan te sturen. Hierdoor krijgen we stukken code die een groot aantal keer hergebruikt kunnen worden. Mits enige verdere ontwikkelingstijd zou het perfect mogelijk zijn om het arsenaal aan back-up mogelijkheden uit te breiden. De enige theoretische beperking op de grootte van de aanstuurbare subnetwerken wordt geleverd door het DMX-protocol zelf. Aangezien het protocol gebaseerd is op RS-485 communicatie maakt het gebruik van een 9-bits adresruimte. Er zijn dus maximaal 512 mogelijke kanalen. Bij het dynamisch inladen van DMX 4.2 zijn we echter wel 18

op een architecturale beperking van de gebruikte technologie gestoten. De aangeboden Dwengo-borden maken gebruik van een 8-bit processor. Dit leverde enige technische moeilijkheden. Indien er meer dan 256 verschillende kanalen aangestuurd moeten worden, worden wij gedwongen gebruik te maken van een tellervariabele die twee bytes groot is. Berekeningen met dergelijke variabelen kosten zoveel rekentijd dat het niet langer mogelijk is om de bit time van 4 µs bij het DMX-protocol te respecteren (zie sectie 3.1). Bij een verdere ontwikkeling is het dus aan te raden gebruik te maken van een processor met een woordlengte van 16 bit. Het is bovendien perfect mogelijk om slechts ´e´en unit van ons back-up systeem te gebruiken als enige DMX-sturing in een niet-professionele omgeving. We denken hierbij aan caf´es, jeugdhuizen, in huiselijke kring en op recepties. Dit levert een goedkope oplossing om een klein netwerk van DMX-toestellen te configureren. De eindgebruiker zou dan enkel met behulp van onze gebruikersomgeving de gewenste show van de microcontroller moeten instellen. Deze schakelt dan automatisch over naar zijn back-up mode. Er is immers geen andere DMX-sturing op het hoofdnet aanwezig (wat zou overeenstemmen met een defect in de hoofdlus). Op deze manier kan zelfs een leek zonder veel moeite een eenvoudige, dynamische en op het ritme van muziek reagerende DMX-show genereren. Deze onvoorziene extra toepassing levert een grote praktische en economische meerwaarde aan dit project.

19

6

Testscenario

De belangrijkste test voor dit project was uiteraard het simuleren van een crash in de DMX-sturing. Dit hebben wij op twee manieren onderzocht. Ten eerste door de verbinding tussen een back-up module en de hoofdcontroller te verbreken. Om dit eenvoudig te kunnen testen maakten we gebruik van een zelf gesoldeerde kabel. Het midden van de kabel konden twee connectoren uiteen geklikt worden. Een tweede test was om de stroomtoevoer van de hoofdcontroller af te sluiten. De schaalbaarheid van het project hebben we door middel van simulaties onderzocht. Oorspronkelijk beschikten we slechts over ´e´en lamp. Met deze opstelling was het nogal omslachtig om te controleren of de DMX-sturing voor een groot aantal toestellen tegelijkertijd correct functioneerde. We konden tijdens het testen het luisteradres van deze lamp manueel een aantal keer aanpassen, terwijl steeds hetzelfde signaal gezonden werd. Op deze manier is het mogelijk om met slechts ´e´en lamp toch te controleren hoe alle lampen binnen een DMX-netwerk de uitgestuurde data interpreteren. Het is echter niet mogelijk om een dynamische show grondig te testen met slechts ´e´en toestel, de lampen moeten immers individuele data krijgen. Daarom hebben we na de tweede presentatie een extra lamp gekregen. Op een bepaald punt was het software-team klaar met de implementatie van alle logica voor het uitsturen van DMX-signalen en het overnemen van de controle bij problemen. De volgende stap in het ontwerpproces zou dan zijn om de logica voor het analyseren van muziek te implementeren. Het bleek echter niet zo evident om een goed functionerende hardware schakeling te bouwen die voldeed aan onze specifieke vereisten (zie onderdeel Hardware in sectie 4.3.2). Om toch verder te kunnen werken aan de microcontrollercode, hebben wij eerst met behulp van een tweede microcontroller een eenvoudige dummy-component ontworpen. Deze component simuleerde het gedrag van de hardware schakeling door pulsen uit te sturen volgens een vooraf ingesteld ritme.

20

7

Marktonderzoek

Voor het marktonderzoek hebben we een aantal relevante verhuurfirma’s en bedrijven gecontacteerd. We hebben telkens ons project uitgelegd en gevraagd of er interesse is uit de industrie om een dergelijk product te commercialiseren. Een bedrijf heeft reeds positief gereageerd op ons voorstel. Ons idee zou voorgelegd worden aan de inkoopafdeling. Ook een verhuurfirma heeft reeds gereageerd. In afwachting van meer respons van de gecontacteerde bedrijven hebben we reeds een prijsvergelijkende studie uitgevoerd om de economische waarde van dit project te staven. De verkoopprijs van ons eindproduct wordt geschat op 30 euro per module. Het gaat over een ge¨ıntegreerde PCB waar alle overbodige randcomponenten van het Dwengoexperimenteerbord achterwege gelaten zijn. Een eenvoudig netwerk kan al geconfigureerd worden met ´e´en master en ´e´en slave. De totaalkost komt dus op een 60 euro. Na een uitgebreide internetzoektocht hebben we een aantal systemen gevonden die een soortgelijke functionaliteit aanbieden. Het ging hier echter steeds over statische opslagtoestellen. Deze zijn vooraf configureerbaar met een aantal DMX-sequenties. Ze worden gebruikt om deze statische shows terug af te spelen al dan niet als back-up. Geen van de gevonden oplossingen bieden echter het dynamische karakter van onze oplossing. Wij maken immers gebruik van het ritme van de muziek om een realtime-interactieve show op te bouwen, vertrekkende van een aantal configureerbare parameters. Bovendien is de kostprijs van deze toestellen een tienvoud van het systeem dat wij aanbieden. De gevonden oplossingen kosten typisch 500 tot 700 euro [5, 6, 7]. Een contactpersoon binnen een verhuurbedrijf heeft ons enkele ontwikkelingen in verband met back-up systemen voor DMX uitgelegd. Er is een trend naar het gebruik van systemen die meerdere inputs nemen en deze verdelen over de aanwezige outputs. Dergelijke systemen zijn beschikbaar vanaf 200 euro [8]. Deze systemen kunnen echter niet uit zichzelf een show genereren. Het is een dure oplossing omdat er naast het systeem zelf ook twee volwaardige systemen voor lichtsturing aanwezig moeten zijn met al dan niet dezelfde lichtshow. In bijlage 11.1 hebben we tabellen opgenomen waarin we ons eigen systeem vergelijken met de geciteerde producten.

21

8 8.1

Gebruikte planning en communicatie Planning

In de eerste weken van het project hebben we samen met onze begeleider de doelstellingen in detail vastgelegd en de componenten geselecteerd die we nodig hadden voor ons project. De initi¨ele planning staat in figuur 10. We zijn toen ook begonnen aan een basisimplementatie van DMX op onze microcontrollers. Na die implementatie hebben we ervoor gezorgd dat we het geheel konden uitproberen. Vanaf een PC konden we via seri¨ele communicatie en een commandline Java-applicatie de module aansturen.

Figuur 10: Initi¨ele planning Toen we een stabiele basis hadden, hebben we de doelstellingen van het project onder elkaar verdeeld. Jonas en Maarten gingen de functionaliteit op de microcontrollers uitwerken. In eerste instantie waren dit eenvoudige shows uitwerken. Tevens tastten zij af wat mogelijk was rekening houdend met de beperkingen van de microcontroller. Sam en Wouter gingen een grafische userinterface programmeren om het geheel aan te sturen. Na een aantal weken is Wouter verder gegaan met de GUI zodat Sam de beatschakeling kon ontwerpen. Het maken van de beatschakeling heeft langer geduurd dan gepland. De redenen hiervoor waren onze beperktere opleiding op vlak van analoge elektronica als computerwetenschappers en de weelde aan (vaak tegenstrijdige informatie) op internet. Dit was echter geen probleem omdat we een ruime buffer hadden gepland. Ondertussen werkte Jonas een algoritme uit om de beats te detecteren. Maarten werkte aan de communicatie tussen de microcontrollers en tussen de microcontrollers en de PC. Wanneer de beatschakeling af was, werkte Sam de GUI af. Ondertussen werkte Jonas enkele lichtshows uit die gebruik maakten van de gedetecteerde beats. Maarten werkte verder aan de communicatie tussen de verschillende bordjes en werkte de schaalbaarheid uit. Dit ging trager dan oorspronkelijk gepland door een aantal timingproblemen.

22

Bovendien waren er conflicterende signalen bij de combinatie van DMX-signalen en onderlinge communicatie tussen de microcontrollers. In de twee weken voorafgaand aan elke presentatie deelde de persoon die de presentatie moest geven zijn werk op. In de week voor de presentatie werkte iedereen samen aan een presenteerbare demo. Algemeen hebben we ons goed aan onze oorspronkelijke planning kunnen houden. We kwamen geen tijd tekort om het project tot een goed einde te brengen dankzij de ingeplande buffer. De uiteindelijke planning is terug te vinden in figuur 11. In tabel 5 staat in detail wie wat wanneer heeft gedaan.

Figuur 11: Uiteindelijke planning

Wouter Danneels Week Week Week Week Week Week Week Week Week Week Week Week

1 2 3 4 5 6 7 8 9 10 11 12

GUI

Detailplanning Maarten Sam Herthoge Van den Steen Identificeren Problemen Basisimplementatie DMX Meerstapsshow PC-sturing Programmeren Hardwareschakeling beatdetectie beatdetectie Configuratie microcontrollers

Verslag

Seri¨ele communicatie

GUI Seri¨ele communicatie Verslag en testen

Tabel 5: Detailplanning van het project

23

Jonas Van Nieuwenberg

DMX-implementatie Programmeren beatdetectie

Back-up Shows Verslag

8.2

Communicatie

We hadden tijdens elke sessie contact met onze begeleider Francis wyffels. Op die manier werden problemen direct aangepakt en bleven ze niet aanslepen. In de eerste helft van het semester was er tweewekelijks ook een meeting met de begeleider. Tijdens deze sessies werd de basis van het project besproken. Voor de beatschakeling werd Sam begeleid door Michiel D’Haene. Doorgaans werkten we wekelijks 3 dagen aan het project. Naast het persoonlijk contact tijdens deze sessies, communiceerden we ook regelmatig via mail en een forum opgezet voor het project. Bestanden werden uitgewisseld via Dropbox zodat iedereen steeds van start kon met de meest recente, stabiele versie.

24

9

Besluit

We zijn erin geslaagd een back-up systeem voor DMX-gestuurde lichteffecten uit te werken. Al doende hebben we een aantal belangrijke ervaringen opgedaan. Om te beginnen hebben we de problemen onderzocht en opgelost om een tijdsgevoelig protocol op een eenvoudige microcontroller te programmeren met behulp van C en de assembly-instructieset van de microcontroller. We hebben ook een communicatienetwerk tussen microcontrollers uitgewerkt met mechanismen voor foutdetectie. Hierbij hebben we ondervonden hoe belangrijk de invloed van ruis is op signalen. We hebben geleerd hoe twee belangrijke protocollen voor seri¨ele communicatie in elkaar zitten. Ons project bevatte naast een computerwetenschappelijk gedeelte ook een serieuze elektrotechnische component. Zo hebben we eenvoudige combinatorische circuits gebruikt om bepaalde signalen door te laten of niet. We hebben ook een hardwareschakeling ontworpen om pieken in de lage tonen van een muzieksignaal (zgn. beats) om te zetten in blokgolven. Bij deze schakelingen hebben we onder andere duidelijk gezien dat we in de praktijk rekening moeten houden met ruis en signalen die verre van perfect zijn. Soms moesten we hiervoor softwarematig een oplossing bedenken omdat we hardwarematig tegen grenzen aanliepen. Naar de toekomst toe zou het interessant zijn om een printplaatje (PCB) te ontwerpen dat de nodige hardware compacteert. Voorlopig gebeurden alle tests enkel door gebruik te maken van de standaard Dwengo-experimenteerborden aangevuld met onze eigen schakeling voor muziekanalyse en een aantal transciever-chips die het RS-485 protocol ondersteunen. Het is aan te raden extra aandacht te besteden aan de keuze van de gebruikte microprocessor. Een processor met meerdere interrupts of een klokfrequentie die beter afgesteld is op de vereisten van DMX zou ons immers in staat stellen om op een effici¨entere manier te voldoen aan de tijdsvoorwaarden. Bovendien zou het handiger zijn om te werken met een woordlengte van 16 bit. In DMX zijn 512 kanalen adresseerbaar, wat problemen met zich meebrengt op 8 bit microcontrollers. Het zou ook handig zijn om een ingewikkelder schakeling uit te werken voor de beatdetectie. Momenteel moeten we de gevoeligheid instellen via een potentiometer die we handmatig moeten instellen. Het zou handiger zijn als de schakeling zelfstandig het signaal versterkte of verzwakte naar een bepaald niveau. Dit zou de beatdetectie gevoelig verbeteren. Op internet zijn er voorbeelden van schakelingen te vinden die beweren iets dergelijks te realiseren [9]. Daarnaast zou een hoger orde filter de lage tonen beter kunnen filteren dan de huidige eenvoudige, eerste orde filter.

25

10

Referenties

[1] ANSI/TIA/EIA-485-A-98, http://www.national.com/an/AN/AN-847.pdf [2] Pandya P. (2007). “Using a PIC Microcontroller for DMX512 Communication” [3] Dwengo vzw, http://www.dwengo.org [4] Audio Pre-Amplifier, http://www.sentex.ca/~mec1995/circ/preamp.htm [5] Enttec DMXStreamer, http://www.enttec.com/index.php?main_menu= Products&pn=70015&show=specification [6] XTBA Backfade, http://www.xtba.co.uk/products/backfade.htm [7] iSplay : DMX replay, recall and backup, http://www.innovation-solutions. com/products/iSplay.asp [8] Briteq DMS-26 DMX Merger / Splitter / Booster, http://www.eurobaltronics. com/ned/produkten/briteq-dms26-dmx-merger-splitter-booster.html [9] Elliott Sound Products - Project 62b - LX-800 Lighting Controller (Bass Beat Extractor), http://sound.westhost.com/project62b.htm

26

11 11.1

Bijlagen Vergelijkende tabellen marktstudie Ons systeem

DMXStreamer

Backfade

Type back-up

Dynamische shows

Prijs [EUR] Aantal aanstuurbare kanalen Splitter Live geheugen laatste stappen Reageert op omgeving

30 256

Laatste opnemen 630 512

Laatste opnemen 595 512

ja (2 uitgangen) nee

nee ja

ja (4 uitgangen) ja

ja(muziek)

nee

nee

stappen

stappen

Tabel 6: Vergelijking van ons systeem en verschillende types back-up systemen (deel 1)

Ons systeem

iSplay

DMS-26

Type back-up

Dynamische shows

Prijs [EUR] Aantal aanstuurbare kanalen Splitter Live geheugen laatste stappen Reageert op omgeving

30 256

Statisch programmeerbaar geheugen (op aanvraag) 256

Geen signaal, laatste waarde of nul 209 512

ja (2 uitgangen) nee

nee nee

ja (3 uitgangen) ja (laatste stap)

ja(muziek)

nee

nee

Tabel 7: Vergelijking van ons systeem en verschillende types back-up systemen (deel 2)

27