Sterrenhemel: programmeren "twinkel"

[LiquidSmoke]

hm, sinds kort bezig met een sterrenhemel (3 RGB kanalen, waarvan de RGB instelbaar is en dan de brightness per kanaal regelbaar is, zodat de kleur intact blijft)

Nu heb ik wat standaard effecten zoals faden van kanaal naar kanaal en rollen van kleuren, en wil nu nog een twinkel effect toevoegen.

Een random waarde tussen 0-255 kiezen en deze op de pwm uitgang gooien werkt opzich redelijk, maar oogt nogal trubbelig, ik denk dat ik de huidige pwm waarde op moet slaan, een nieuwe genereren en dan in een x aantal stappen hiernaart moet faden.

Op CO vond ik het volgende;

code:

Do
    ___rseed = Timer0                                       'Random seed uit de timer halen
    Trood = Rnd(255)                                        'Willekeurige nieuwe kleur maken
    Tgroen = Rnd(255)
    Tblauw = Rnd(255)
    Diff = Trood - Rood                                     'Verschil tussen nieuwe en oude kleur
    Staprood = Diff / 40                                    'Faden in 40 stappen
    Diff = Tgroen - Groen
    Stapgroen = Diff / 40
    Diff = Tblauw - Blauw
    Stapblauw = Diff / 40
    For I = 1 To 40
        Stop Timer0                                         'Zorgen dat de PWM niet kan onderbreken als ik de nieuwe waardes instel
        Rood = Rood + Staprood
        Groen = Groen + Stapgroen
        Blauw = Blauw + Stapblauw
        Start Timer0
        Waitms 10
    Next I
Loop

Op zich is het idee prima, maar ik denk dat je al snel op negatieve waardes uitkomt en dus kleursprongen/intensiteit sprongen maakt.

Is er een simpeler beter algoritme, of zit ik gewoon in een verkeerde hoek te denken?

/edit:
In principe kan ik < of > wel gebruiken om op of neer te laten faden zonder problemen, maar ik heb het idee dat ik stomweg iets over het hoofd zie (plus het kost een bult aan sram om voor 12 pwm kanalen alles te onthouden, en dan nog de seriële buffers, booleans, tellers etc etc...)

[ Voor 8% gewijzigd door LiquidSmoke op 20-02-2010 22:11 ]

[LED-Maniak]

LiquidSmoke schreef op zaterdag 20 februari 2010 @ 22:06:

In principe kan ik < of > wel gebruiken om op of neer te laten faden zonder problemen, maar ik heb het idee dat ik stomweg iets over het hoofd zie (plus het kost een bult aan sram om voor 12 pwm kanalen alles te onthouden, en dan nog de seriële buffers, booleans, tellers etc etc...)

Maak je geen zorgen over sram tekort. Ik heb hier controllers staan die 13 kanaals software PWM en 32 kanaals hardware pwm kunnen waarbij elk kanaal onafhankelijk van elkaar beide kanten op kan faden in intensiteit. Genoeg ram en geheugen in een simpele AVR.

[naftebakje]

Ik heb ff je topic afgesplitst, het lijkt me een té interessante vraag om in de kroeg onder te laten sneeuwen.
Als je ergens wat opslagruimte kan versieren (lookup table in het programmageheugen dat je nog over hebt bijvoorbeeld) kan je een voorrgeprogrammeerde "random twinkelen"- reeks gebruiken (waarden waarnaar gefade wordt), vaak geeft dat een beter effect dan échte random. Hoe groter je tabel, hoe meer zaken je er in kan steken, ik zou beginnen met de 3 kanalen in dezelfde reeks hun data te laten halen, met een offset zorg je dat ze niet samen lopen.
Als dat goed werkt, kan je nog wat truken uithalen om de beperking van de voorgeprogrammerde reeks onmerkbaar te maken, zoals de snelheid waarmee de volgende waarde opgehaald wordt te variëren, of een van de kanalen omgekeerd te laten lopen in je lookup table.

[SA007]

Ik ehb eens iets vergelijkbaars gedaan om met een attiny2313 7 leds semi-random te laten knipperen.

Software in de chip is doodsimpel, eigenlijk gewoon haal byte uit geheugen en duw op poort. met fadeaffecten ertussen.


En heb de rest van het geheugen opgevult met data uit een php script wat flink wat complexer is wat een hoop semi-random data heeft gemaakt, met meteen correctie erin voor de poorten enzo.

Ziet er best leuk uit, en volgens mijn berekeningen herhaalt het patroon zich elke 15 minuten ofzo, veel te lang om ook maar een merkbare herhaling te hebben.

[LiquidSmoke]

@Naftebakje, ik snap je idee en wil dat van de week eens proberen, ik gok dat jouw manier het chaotische effect wegneemt doordat je zelf de grootte tussen de waardes bepaald (volg je het nog?)

Het aantal fade-stappen van de ene waarde naar de andere hoeft denk ik niet zo groot te zien, als het verschil tussen de huidige en volgende waarde niet zo groot is (hierdoor zal het rustiger ogen).

Enige probleem lijkt me dat je best een uitgebreide tabel moet hebben, zodat het geen herkenbaar patroon wordt, en de Rnd-functie continu seeden uit timer0 of ruis uit de adc.

@Led-maniak, mijn Atmega16 loopt nu op 11059200 Mhz, en ik genereer 12 PWM-kanalen. Via 15 bytes (startbyte 0xFF,Commando,R1,G1,B1,R2,G2,B2,R3,G3,B3,Kanaal1,Kanaal2,Kanaal3,Snelheid) stuur ik het geheel aan, data komt serieel binnen @ 38400 Baud.
Tis nog best een gepuzzel om de pwm zo min mogelijk te onderbreken en de bytes te verwerken, maar het is te doen. Bascom is tot nog toe geen beperking (Van C/Assembler heb ik toch geen kaas gegeten ).
Data komt nu via Bluetooth binnen d.m.v een BTM-112 module, de software draait nu nog op de pc, maar later op een ipaq. In principe zou ik de ipaq al het rekenwerk kunnen laten doen en de Atmega alleen stom pwm, maar ik wil uiteindelijk ook nog een simpele besturing op de muur hebben...

@SA007, klinkt interessant, heb je dan ook een soort van twinkle tabel gegenereerd door middel van php ofzo?

Verder denk ik dat ik wel erg veel functies kan maken, aangezien ik niet alleen kleuren kan mengen (Common anode leds met de kleuren aan een ULN), maar ook nog eens de lichtsterkte per kanaal kan variëren (de voeding naar de leds aan een UDN).

In principe kan ik een kleur instellen en deze laten twinkelen (kanaal instelbaar of alle kanalen), maar ook een twinkel die zelf random (of voorgeprogrammeerd) verkleurt.

Een heel verhaal, maar als ik van de week iets op poten heb laat ik het weten.

[LED-Maniak]

LiquidSmoke schreef op maandag 22 februari 2010 @ 00:09:
@Led-maniak, mijn Atmega16 loopt nu op 11059200 Mhz, en ik genereer 12 PWM-kanalen. Via 15 bytes (startbyte 0xFF,Commando,R1,G1,B1,R2,G2,B2,R3,G3,B3,Kanaal1,Kanaal2,Kanaal3,Snelheid) stuur ik het geheel aan, data komt serieel binnen @ 38400 Baud.
Tis nog best een gepuzzel om de pwm zo min mogelijk te onderbreken en de bytes te verwerken, maar het is te doen. Bascom is tot nog toe geen beperking (Van C/Assembler heb ik toch geen kaas gegeten ).
Data komt nu via Bluetooth binnen d.m.v een BTM-112 module, de software draait nu nog op de pc, maar later op een ipaq. In principe zou ik de ipaq al het rekenwerk kunnen laten doen en de Atmega alleen stom pwm, maar ik wil uiteindelijk ook nog een simpele besturing op de muur hebben...

Je hebt in de ogen van de AVR echt nog een zee van tijd over. Alles draait om inderdaad planning in de AVR. Om het nog erger te maken zit in mijn 13 kanaals PWM controller ook nog USB en de chip decodeert tegelijkertijd een simpele OOK RF ontvanger(die dus alle data+ruis doorstuurt) die eigenlijk nog de meeste tijd in beslag neemt om 64-bits code te decoderen. Ohja, RS232 op 115k2 werkt ook tegelijkertijd

C en bascom vind ik persoonlijk redelijk gelijk qua tekst alleen is bascom eenvoudiger. Bij C heb je iets meer spul er omheen maar daar prik je na wat knoeien gewoon omheen. Hoe bascom presteert tov. C weet ik eigenlijk niet.

Je kan overigens eenvoudig berekenen hoeveel tijd je AVR nu echt vrij heeft om zijn overige code uit te werken. 1 seconde - (Frequentie * tijd per interrupt). Je zal zien dat dat nog best een hoop is.

Daarnaast: Niet alles hoeft exact op tijd te lopen! Je PWM is zichtbaar dus die wil je niet storen. De UART communicatie kan je zo bouwen dat deze vrijwel geen tijd in neemt(alleen in UDR data ophalen en doorgaan met je programma). Het dimmen van de LED's mag je echter best interrupten door andere processen zoals de PWM. 1/255e waarde verandering merk je toch niet als dit nu 10ms duurt of 20ms.

Een Lookup Table lijkt me inderdaad ook gunstig. Stop het in je progmem en je hebt meteen je sram vrij. Ik neem tenminste aan dat je je AVR niet helemaal vol gepropt hebt met code. Voor extra variatie kan je de richting om de zoveel tijd veranderen of op een ander punt in de LOT beginnen.

Overigens kan je met een vrije ADC en wat ruis ook mooi random functies genereren. Benadski op circuitsonline heeft daar dacht ik eens mee gespeeld voor electrische kaarsen.

Pff, wat een lang verhaal weer

[LiquidSmoke]

Ik heb 2 manieren die ik wil proberen;

1) Gewoon random een waarde tussen 0-255 genereren, en hiernaartoe faden vanaf de huidige waarde, in een x aantal stappen (bijv. 20-30 stappen, zodat het faden niet te lang duurt).

2) Een lookup table met waardes die redelijk dicht in de buurt liggen van elkaar, en dan random hier eentje uit kiezen en hiernaartoe faden (iemand een idee welke waardes of het verschiltussen de waardes je zo ongeveer zou moeten denken?).

@Led-maniak,

De AVR heeft tijd zat, ik heb express het inlezen van seriële data buiten een interrupt gehouden, zodat ik niet telkens de pwm (timer0) hoef te stoppen, deed ik dit niet, dan kreeg ik nogal vreemde resultaten (controller die resette en dergelijke, erg vaag allemaal).

Nu gebruik ik een seriële buffer welke ik eens in de zoveel tijd uitlees, het werkt vlot genoeg om de kleuren vloeiend in te kunnen stellen, ook al zal ik her en der een commando missen, dit is met het blote oog niet te zien iig.

[SA007]

@SA007, klinkt interessant, heb je dan ook een soort van twinkle tabel gegenereerd door middel van php ofzo?

Inderdaad. Heb in php een script geschreven wat op basis van een aantal dingen (zoals maximaal aantal leds wat tegelijk veranderd moet worden, hoe lang een led minimaal aan moet zijn, etc) een blok data genereert wat ik in het progmem van mijn atmel gooi (simpel als progmem array in de code).

Deze array lees ik vervolgens weer uit.

Enige wat de atmel eigenlijk doet is faden tussen de stapjes, meer niet. Zo heb ik 500 combinaties voor 17 leds die ongeveer elke anderhalve seconde wisselen, wat me ongeveer 13 minuten constant andere combinaties garandeert. Dat is echt veel te lang om zelfs als je er continue langs zit er een patroon in te gaan zien.

En mocht dat gebeuren, ik draai het php script nog een keer en ik heb een nieuwe array om in de atmel te frotten

[naftebakje]

LiquidSmoke schreef op maandag 22 februari 2010 @ 00:09:
@Naftebakje, ik snap je idee en wil dat van de week eens proberen, ik gok dat jouw manier het chaotische effect wegneemt doordat je zelf de grootte tussen de waardes bepaald (volg je het nog?)...

Ik heb al nu en dan eens gehoord dat random eigenlijk niet mooi is, en als je er even over doordenkt klopt dat wel. Echte random (voor zover je die kan maken) zal je regelmatig een patroon in herkennen, zal nu eens een tijdje te fel en dan eens te donker zijn, een kwartier lang alles 100% aan is perfect mogelijk in random data.
Als je zoals SA007 met een tabel werkt kan je de "random" aan je wensen aanpassen (bijvoorbeeld dat je niet te veel en niet te weinig verandering wil, 3/4 van de tijd een lagere intensiteit en 1/4 snel pieken, whateaver). En blijkt het effect niet zoals gewenst, maak je een nieuwe tabel tot je er een hebt die overeen komt met wat jij zelf in gedachten hebt bij "random twinkelen".

[LiquidSmoke]

naftebakje schreef op maandag 22 februari 2010 @ 19:15:
[...]
Ik heb al nu en dan eens gehoord dat random eigenlijk niet mooi is, en als je er even over doordenkt klopt dat wel. Echte random (voor zover je die kan maken) zal je regelmatig een patroon in herkennen, zal nu eens een tijdje te fel en dan eens te donker zijn, een kwartier lang alles 100% aan is perfect mogelijk in random data.
Als je zoals SA007 met een tabel werkt kan je de "random" aan je wensen aanpassen (bijvoorbeeld dat je niet te veel en niet te weinig verandering wil, 3/4 van de tijd een lagere intensiteit en 1/4 snel pieken, whateaver). En blijkt het effect niet zoals gewenst, maak je een nieuwe tabel tot je er een hebt die overeen komt met wat jij zelf in gedachten hebt bij "random twinkelen".

Klopt als een bus wat je zegt. ik zal van de week eens proberen zo'n tabel op te stellen, ik denk dat er wel veel finetuning aanzit.

Ik heb inmiddels een andere optie uitgeprobeerd, een waarde tussen 0-255 en hiernaartoe faden, zo ongeveer:

code:

      ___rseed = Timer0
      Random = Rnd(254)

      If Random > Kanaal3temp Then
         For I = Kanaal3temp To Random Step 1
            Kanaal3 = Lookup(i , Pwmvalues)
            For J = 0 To Vertraging Step 1
               nop
            Next
         Next
      Elseif Random < Kanaal3temp Then
         For I = Kanaal3temp To Random Step -1
            Kanaal3 = Lookup(i , Pwmvalues)
            For J = 0 To Vertraging Step 1
               nop
            Next
         Next
      End If

Ik heb het uitgeprobeerd op mijn 3e kanaal, vandaar 'kanaal3temp' en kanaal3.
Dit werkt al een stuk beter aangezien je nu naar een waarde toe fade.

Ik experimenteer nog met de stapgrootte, aangezien het maximale verschil (255 stappen) logischer langer duurt dan 1 stap, al is dit denk ik wel natuurgetrouwer...

/edit: met de nop bepaal ik min of meer de duty cycle, deze is instelbaar via een slider op mijn pc. Verder ben ik niet zo'n fan van nested loops, aangezien de draad nogal makkelijk kwijt te raken is (voor mijn gevoel).

[ Voor 4% gewijzigd door LiquidSmoke op 22-02-2010 19:34 ]