Simulera dåligt lysrör

[FormerMazda]

Har tänkt hjälpa svågern med en ljuseffekt till ett billjudsbygge han har på gång.
Kortfattat ska det simulera ett dåligt lysrör som inte riktigt vill tända. Det ska alltså blinka lite, lysa lite, lysa lite på lägre effekt och sådär som man kan tänka sig.

Här är ett exempel som är ganska så bang on: https://www.youtube.com/watch?v=D3ZRA3KGNa0
Som synes har jag redan frågat killen som gjort det, men han svarar inte.

Alltså, problemet är inte hur jag ska skriva koden, problemet är att skriva kod för att få en snygg sekvens på ljuset.
En flummig idé är att spela in ljuset med en fotocell och bara logga analoga värden var 5:e ms eller liknande. Koden i sig behöver ju inte vara snygg eller optimerad på nåt vis.

Fler idéer?

[Icecap]

Har inte tittat på filmen men att "slumpa" ett tal är relativt enkelt:
Ta två primtal.
Deklarera en variabel, t.ex en unsigned byte. Jag kallar den "Slump" här.

Räkna sedan:
Slump *= Primtal_1;
Slump += Primtal_2;

Nu får du ett värde i Slump som du kan skala som du vill, väljer du rätt primtal får du 256 olika värden varefter de upprepar sig.

Du kan enkelt skala till en annan variabel så att t.ex. värden över 60% blir 100% osv. Resten är bara en fråga om hur snabbt (ofta) regleringen ska ske och hur.

Jag har använd detta princip mycket och om man inte är skitpetig är det rikligt slumpmässigt till väldigt mycket.

[sodjan]

Nu så är väl inte ett blinkande lysrör helt slumpmässigt.
Man får nog bestäma en grundsekvens som man sedan
gör slumpmässiga variationer på. Man kan nog även skapa
en längre fast/hårdkodad sekvens, efter ett tag så kommer
nog ingen att uppfatta att det "börjar om" igen...

[olalofberg]

Jag tror jag skulle rendera nån sekvens med en lysrörständning i för 10år sen, vad jag kommer ihåg
tror jag att jag spelade in ett riktigt lysrör med fotoresistor, och sen konverterade sekvensen
till data jag kunde använda.

Måste du ha olika nivåer? Kan du kontrollera olika ljusstyrkor?
Annars duger ju en bitström med 0 och 1.
Men det är klart, man sparar väl plats om man lagrar tiderna mellan omslagen istället.

[FormerMazda]

Jag tror att för ett mer trovärdigt resultat så vill man nog få in olika styrkor också, inte bara blink.
Se filmen så syns det varför det blir mer trovärdigt.

Sodjans idé med olika sekvenser som slumpas är en bra idé, så det inte syns att det är en slinga liksom.
Så där kan man ju även implementera IceCaps slump.

[matsadona]

Det finns färdiga kit för modelljärnväg ho Conrad, som simulerar svetsljus och lysrör m.m.. Har inte sett dem i verkligheten, så jag kan inte svara på om den är användbar eller inte.

http://www.produktinfo.conrad.com/daten ... LICHT_.pdf

[FormerMazda]

Youtubade lite snabbt, och det är ändå rätt bra effekter.
Tackar för tipset!

[JohnA]

För ett par år sedan provade jag några olika pseudoslumpgeneratorer, de flesta ganska enkla med XOR och skift. Först när jag råkade på något som heter Galois shift register fick jag något som funkade riktigt fint. Programexemplet från Internet simulerar en stearinljuslåga via två lysdioder på vardera PWM-utgången hos en ATtiny13. Koden snurrar ganska snabbt och 32-bitarsvarianten ger en ruskigt lång "slumpsekvens" innan det upprepar sig, men även 16-bitsvarianten (som är betydligt snabbare" ger ett ganska vitt brus om man ansluter en liten högtalare till en portpinne som matas från valfri utmaskad bit i slumpgeneratorn.

Jag gillar åskväder och experimenterade därför med att simulera blixtar. Minns inte hur jag skrev koden, ska se om jag hittar något att posta här. Borde fungera fint att simulera dåligt lysrör genom att invertera utsignalen från detta projekt.
Ett slitet lysrör flämtar ju lite "halvslumpigt" med ett mestadels ganska jämnt intervall för att då och då bryta mönstret. En tidsloop som påverkas i mindre grad av slumpgeneratorn och till detta några större "tidshopp" som helt släcker ner någon gång ibland genom att man maskar ut ett kortare slumptalsintervall som aktiverar undantagen borde vara en bra metod.

Att simulera dåliga lysrör ligger på min egen lista med mindre seriösa leksaksprojekt och är tänkt att göra ett hängsmycke med LED mer intressant än ett konstant lysande sken.

[JohnA]

Kod: Markera allt

//*************************************************************************
//*** Galois Nightflash - påbörjad 2013-06-09
//*** Med WDT:n satt till maxtid (8s) ger en char-multiplikator
//*** blinkintervall från åtta sekunder upp till 34 minuter. (8*256/60)
//*** Varje blinkevent innehåller 1-3 blixtar i snabb följd
//*************************************************************************
#include <macros.h>
#include <iot13Av.h>

//------------ LED macros --------------------------------------------------

//  LED anode to PB3/pin2, LED cathode to PB4/pin3

#define comLED_on DDRB|=(0x01<<3);DDRB|=(0x01<<4);PORTB|=(0x01<<3);PORTB&=~(0x01<<4) 
// both=out, A=1 C=0, 

#define comLED_off DDRB|=(0x01<<3);DDRB|=(0x01<<4);PORTB&=~(0x01<<3);PORTB&=~(0x01<<4) 
// both=out, both=0

#define comLED_chrg DDRB|=(0x01<<3);PORTB&=~(0x01<<3); DDRB&=~(0x01<<4);PORTB|=(0x01<<4) 
// A=0 C=in - PN layer capacitance is charged via internal pullup resistor Rpu

#define comLED_float PORTB&=~(0x01<<4)
// Rpu at PB1 (LED cathode) = off

#define comLED_read (PINB&(0x01<<4))
// "true" if cathode=1 (comLED PN-layer have charge left)


/*
*****************************************************************
*********   Watchdog Timer Interrupt => Shut down the WDT   *****
*****************************************************************/

#pragma interrupt_handler int_wdt:iv_WDT

void int_wdt(){				// Disable interrupts from watchdog timer
    WDTCR &= ~(1<<WDTIE);	
}


/*
*****************************************************************
********* wddelay(t) - Sleep in Power down, single-shot.    *****
*****************************************************************/

// t=0 => 16ms 
// t=1 => 32ms 
// t=2 => 64ms 
// t=3 => 125ms 
// t=4 => 250ms 
// t=5 => 500ms
// t=6 => 1s
// t=7 => 2s 				
// t=8 => 4s 
// t=9 => 8s  (t>8)

void wddelay(char t){

// Enable Watchdog Interrupt Mode.
// Disable Watchdog System Reset Mode if unintentionally enabled.
// Set Watchdog Timeout period to nn.


	if(t == 8) t= (1<<WDTIF)|(1<<WDTIE)| 	
             (1<<WDCE )|(0<<WDE  )|  
             (1<<WDP3 )|(0<<WDP2 )|(0<<WDP1)|(0<<WDP0); 
 
 	else if(t > 8) t= (1<<WDTIF)|(1<<WDTIE)| 	
             (1<<WDCE )|(0<<WDE  )|  
             (1<<WDP3 )|(0<<WDP2 )|(0<<WDP1)|(1<<WDP0); 

   	else t |= (1<<WDTIF)|(1<<WDTIE)|(1<<WDCE )|(0<<WDE);   



// ------- The following must be written in a timed sequence: ----------------

    MCUSR  &=  ~(1<<WDRF);			// Clear WDRF if it has been unintentionally set.
	WDTCR = (1<<WDCE )|(1<<WDE  );	// Enable configuration change.
    WDTCR = t;

	asm("WDR");						// Reset Watchdog to ensure correct timing.

	MCUCR  |= (1<<SM1) | (1<<SE);	

	asm("SLEEP");					// ZZZZZZzzzzzzz...
	asm("NOP");
}



//***********************************************************
//**** 32-bit Galois linear feedback shift register PRNG ****
//***********************************************************


char prng(char upset) {

	static long lfsr;
	char l;

	if( lfsr == 0 ) lfsr = 0xA0DE5214;
	lfsr = lfsr + upset;
	lfsr = (lfsr >> 1) ^ (0 - (lfsr & 1u) & 0xd0000001u);
	return (char)(lfsr & 0x000000FF);
}

// *********************************************************************************
// *****************        M A I N         ****************************************
// *********************************************************************************

char wl; // WDT-cycles loop - multiplikatorloop för tid till nästa event
char fn; // Flash number - antal blixtar vid varje event
char fl; // Flash counting loop

void main(){

// ---------- RESET/Init ------------------------------------------------------------

	DDRB  = 0xFF;           
	PORTB = 0x00;			

	PRR = 0xFF;				// Shut down ALL modules to save a lot of power!
	SREG |= 0x80; 			// Set global interrupt-flag


//-------  MAIN LOOP - repeat over and over again until battery goes dead  ---------------


	while (1){

							// Measure ambient light by reverse-biasing the LED
		comLED_chrg;		// and see how fast itŽs PN-layer capacitanse is
		asm("nop");			// discharged. Bright light gives a quicker discharge.
		asm("nop");
		asm("nop");
		asm("nop");
		asm("nop");
		asm("nop");
		asm("nop");
		asm("nop");
		comLED_float;		// PN-charge period over, release, wait and measure. 
		wddelay(5);

		if(comLED_read){	

		fn = prng(1) &0x03;

			for(fl=0;fl<fn;fl++){
//			for(fc=0;fc<2;fc++){
				comLED_on;			
				wddelay(1);			
				comLED_off;
				wddelay(1);			
			}

			for(wl=0;wl<prng(0);wl++){
				wddelay(8);	
//comLED_on;						// DEBUG
//comLED_off;
			}
		}
	}
}

[JohnA]

Lite långt exempel för att bara beskriva en bra PRNG kanske. Koden ovan gör mer än bara blinka en lysdiod slumpmässigt. För att spara batteri släcker den ner helt dagtid genom att bakvända lysdioden och använda den som en ljussensor. Dessutom används watchdogtimern i stället för fördröjningsloopar och under väntetiderna sover CPU:n djupt.

Här nedanför är C-kod för 16-bitars Galois PRNG i sin enklaste form, vilken är snabbare än 32-bitsvarianten men
ändå ha en mycket längre pseudoslumpsekvens än vad som behövs för att "blinka lysrör".

Kod: Markera allt

char prng(void) {

	static int lfsr;
	char l;

	if( lfsr == 0 ) lfsr = 0xACE1;    // Om alla bitar blir noll kommer PRN-genereringen att köra fast
	lfsr = (lfsr >> 1) ^ (-(lfsr & 1) & 0xB400); 
	return (char)(lfsr & 0x00FF);
}

Lite wikipediafakta om LFSR PRNG: http://en.wikipedia.org/wiki/Linear_fee ... t_register

[hanzibal]

...genom att bakvända lysdioden och använda den som en ljussensor

Smart

EDIT: Och den där LFSR PRNG:n var ju också fiffig, blir bokmärke på den.

[JohnA]

Lite OT förvisso, men det där med bakvänd LED är så fantastiskt att det förtjänar en förklaring:

En belyst LED fungerar förvisso som en solcell, dock en mycket dålig sådan. Med en FET-förstärkare mellan lysdioden och en ingångsport på microcontrollern kan man absolut använda den som ljussensor, men det är inte speciellt smart.
Om man har TVÅ portar lediga kopplar man lysdioden mellan dem och kan på så vis tända den som vanligt men också bakvända den. Det fiffiga med det senare är att man då laddar upp kapacitansen i PN-övergången. Låter man sedan den positivt laddade katoden flyta fritt kommer det ta en liten stund (mikro- eller millisekunder) innan läckage i lysdioden och den anslutna porten laddar ur spänningen och porten mäter "nolla" i stället för "etta". Lysdiodens självurladdning påverkas starkt av infallande belysning och därmed har vi en riktigt fin ljusmätare, i synnerhet om man kombinerar med hårdvarutimer och interrupt eller en tidmätande programloop.

Olika lysdioder har olika egenskaper. Röda är snabbare och mer "all round" än blå som befinner sig i andra änden av synbara spektrat. I princip är en lysdiod relativt "blind" för längre våglängder än den de själva sänder ut.

Det absolut coolaste är inte att en minimalistisk konstruktion typ "blinka lysdiod" kan vila i dagsljus för att spara batteri, och det utan en enda liten extern komponent, utan det faktum att man kan konstruera en dubbelriktad dataport med samma teknik! Överföringshastigheten blir ganska låg, några 100-tal Baud max med röda LED om jag minns rätt, och ännu sämre med gröna eller blå enligt mina egna experiment. Det finns en hel del att hitta på Internet om detta och tekniken har varit känd så pass länge att det är förvånande att man inte ser den i kommersiella produkter. Googla på "ledcom" och "i-dropper".
Här är nog det bästa jag läst i ämnet: http://math.hws.edu/vaughn/cpsc/336/docs/led-sensor.pdf

[hanzibal]

Fortsatt OT: Ja, en Jef Han gjorde en "led touch sensor" med en vanlig led-matris som jag tror bygger på samma grunder. Tyvärr funkar inte videolänken längre:
http://cs.nyu.edu/~jhan/ledtouch/index.html
Detta diskuterades en del på forumet och jag tror någon gjorde en egen ledsensor men jag hittar inte tråden.

EDIT: Hittade videon på youtube:

[JohnA]

Åh, touchmatrisfilmen har jag sett, supercoolt!

Aningen mer ON topic nu: PRNG-koden jag klistrade in är som ni kanske förstått inte min egen skapelse och i ärlighetens namn är den en bit över vad jag själv brukar skapa i något programmeringsspråk, men jag förstår den tillräckligt väl för att åtminstone kunna använda den till något vettigt. Jag har som sagt provat några enklare varianter med XOR-skift som stökar till ett "random number seed" om och om igen vid asynkrona händelser (knapptryckningar m.m.) och det har inte på långa vägar funkat lika fint som koden jag visade ovan.

I vissa applikationer duger det utmärkt med 16 bitar eller t.o.m. färre för att ge känslan av total slump. I en del fall är just PSEUDO-slumpningen en förutsättning. Ibland vill man dock ha riktig slumpgenerering och en lösning jag funderat på är att "injicera" en liten störning i ovan visade PRNG. Men vad är mest effektivt på att stöka till i PRNG-sekvensen?

Att skicka t.ex. en byte till PRNG-funktionen där den loopar skiftet n gånger stökar till det rejält men dels är det fortfarande samma sekvens, dels kostar det CPU-cykler ganska rejält. Mer effektivt borde vara att göra en enkel addition, men även om sekvensen tar ett skutt framåt blir nästa "slumptal" ändå stark baserad på någon del i den naturliga sekvensen.
Allra effektivast borde kanske vara att påverka själva skiftsekvensen, men hur? Det vill ju också till att man hanterar eventuella "dödlägen" där skiftet fastnar.

[JohnA]

Helt ON topic nu:

Om jag skulle göra något av mina egna idéer till en simulering av dåliga lysrör blir nog det första att beskriva de olika speciella saker ett dåligt lysrör kan ha för sig. -Det kan göra sega tändförsök med lång glödning följt av en kort ljusblink och sedan en lång paus innan något händer igen. Det kan också vara precis tvärt om, d.v.s. längre perioder av konstant ljus med korta avbrott i mer eller mindre rytmiska intervall. Sedan kan otygen också uppföra sig ganska normalt under både kortare och längre perioder.

Min programvara skulle alltså börja med att "grovslumpa" fram ett av de tre grundfallen, välja en totaltid för sekvensens varaktighet, slumpa fram detaljer i beteendet som t.ex. tidsintervall mellan blinkningarna, anropa respektive funktion och därefter upprepa hela urvalsprocessen. Med en bra PRNG-funktion, eventuellt kryddad med "asynkront bit-stök", kan man enkelt välja exakt vilken sannolikhet man vill ha för vart och ett av de olika grundfallen. T.ex. kan sannolikheten sättas ganska låg för fast ljussken men när det väl inträffar kan det få pågå ganska länge. Långa lysande intervall med rytmiskt upprepade flämtningar kan däremot få vara något av ett defaultläge. De tvekande uppstarterna med svagt glödande och korta blinkningar kan göras vanliga endast efter systemreset.

Minns inte hur mycket jag lyckades få med i min åskväderssimulering, men tanken var iaf att ha med flera olika typiska beteenden som t.ex. det faktum att blixten ofta stöter fler än en gång i samma "blixtkanal" av joniserad luft under de millisekunder fenomenet varar. Tanken var att bygga en liten trivselmanick att sätta i sovrumsfönstret bakom rullgardinen. Med lysdioden som ljussensor skulle jag kunna få ett litet trevligt åskväder några slumpvis valda kvällar i veckan en stund efter skymningen. Med flera lysdioder i olika riktningar fångas ytterligare en dimension av naturfenomenet genom att mjukvaran också får välja vilken lysdiod som ska blixtra.

Kör man sedan PRNG-funktionen ett större antal gånger i snabb följd via ett externt lågpassfilter får man kanske något som kan föreställa åskmuller.

Hmm, till en lysrörssimulator vore det kanske inte fel att också härma 100Hz-surret från lysrörsarmaturens reaktor, samt det plingande ljudet av glimtändaren.