Tangentbordsbelysning

[4kTRB]

Detta projekt startade jag i idé-tråden.
Jag började skissa på hur idén skulle implementeras och har påbörjat arbetet
med att rita ett schema som jag tänker ha som utgångspunkt för att koppla
upp kretsarna på labbplatta.

Jag ska ha någon form av matris med typ 10 x 10 RGB LED monterade i en plywoodskiva.
Anordningen ska hänga över tangenbordet i en huv som också fungerar som avskärmning
mot yttre ljus. De har sådana skärmar på många företag där de jobbar med tex bilder för
att få bra kontrast och mindre störande reflexer.

Varje färg R, G resp. B ska gå att ställa intensiteten på individuellt. Det ska gå att få
olika färgat sken med olika intensitet. Jag har tänk att styra det hela från ett java-program
som skickar signaler i form av toner ut på line out på ljudkortet.

Nu har jag skissat på 3 st. tondekodrar för val av den färg jag vill justera.
Tanken är att en signal på 4kHz ska släppa fram inställningssignalen till Röd
och 4.5kHz resp 5kHz till de andra.

Jag kommer inte använda någon mikrokontroller. Det blir nog så kul att skriva Java.
Här är alltså ett förslag på utformningen av dekoderdelen för val av LED-färg:

[4kTRB]

En detalj är ingången till de 3 dekodrarna.
Det är bra om det finns någon typ av filtrering där.
Jag är ju enbart intresserad av frekvenser från 4kHz till 5kHz.
Ur databladet för LM567 står att läsa att ingångresistansen är runt 20k.
Vidare så är en insignal runt 100mV lagom.
Ett BP filter är bra att ha. Men med 3 i parallel så blir det mycket räknande
om man ställer upp jw ekvationer. Därför använde jag PSPICE för att få till
värden som hamnar något så när rätt. Detta får jag utvärdera påkoplingsplattan
senare. 1V signalen ska jag ha till att styra intensiteten med och den frekvensen
hade jag tänkt mig som mest till 1KHz. Det kan hända att jag senare får höja alla
frekvenser beroende på hur intensitetsstyrningen utformas.

[4kTRB]

Kan nämna att tondekodrarna drar utgången låg när de detekterar rätt frekvens.

Det kanske finns någon som labbat med LM567 och kan svara på om de bandbredder
jag valt är lagom?

[4kTRB]

Jag måste ha en plan då det gäller kommandon att styra det hela.
Detta får ske i steg...

1. 4kHz på Line Out
2. Pinne 8 IC7 går låg
3. Stäng av 4kHz, pinne 8 går hög och klockar en T-vippa
4. T-vippans Q-utgång går hög och styr en analog switch, en CD4066
5. Analoga switchen kopplar in Line out till en frekvens till spänningsomvandlare
6. På Line Out läggs en frekvens som är proportionell till önskad intensitet
7. Efter en bestämd tid eller ett visst antal perioder låses intensiteten.
8. Steg 1 upprepas
9. Steg 2 upprepas
10. Steg 3 upprepas
11. T-vippans Q-utgång går låg => switchen bryter Line Out-signalen

Steg 7 är viktigt. Hur tusan ska jag lösa det?

[4kTRB]

Tanken är att en spänning ska styra strömmen genom lysdioderna.
Spänningen beror på frekvensen.
När frekvensen upphör så ska spänningen ligga kvar.
En resetable peak detektor kanske är en lösning.
Den måste kunna hålla kvar spänningen lång tid för har
man väl ställt in en mysig belysning ska den inte ändras.
Det skulle kunna gå att låta java-programmet köra en refresh
med jämna mellanrum för att kompensera peakdetektorns minne.

[m_robban]

Kul projekt. Hur skall du generera signalen i Java. Blir det att spela upp en audiofil med inspelad sinusvåg?

[4kTRB]

Nej,
detta höll jag på med i våras.
Jag bygger upp signaler bit för bit näst intill i en klass jag kallar Oscillator.
Jag använder javax.sound.sampled.AudioInputStream.
Så här ser min oscillatorspelare ut...

Kod: Markera allt

public class OscillatorPlayer
{
	//private static final int	BUFFER_SIZE = 128000;
	public static void main(String[] args) throws IOException
	{
		byte[]	abData;
		AudioFormat	audioFormat;
		int		nWaveformType = Oscillator.WAVEFORM_SINE;
		float	fSampleRate = 192000.0F;
		float	fFrameRate = fSampleRate;		
		float	fSignalFrequency = 12500.0F;
		float	fAmplitude = .25F;

		audioFormat = new AudioFormat(AudioFormat.Encoding.PCM_SIGNED,fSampleRate,16,2,4,fFrameRate,false);
		long lLengthInFrames = (long)(fFrameRate/fSignalFrequency);
		AudioInputStream oscillator =
		new Oscillator(nWaveformType,fSignalFrequency,fAmplitude,audioFormat,lLengthInFrames);
		SourceDataLine	line = null;
		//DataLine.Info info = new DataLine.Info(SourceDataLine.class,audioFormat);
		try
		{
			//line = (SourceDataLine) AudioSystem.getLine(info);
			line = AudioSystem.getSourceDataLine(audioFormat);
			line.open(audioFormat);
		}
		catch (LineUnavailableException e)
		{
			e.printStackTrace();
		}
		catch (Exception e)
		{
			e.printStackTrace();
		}
		line.start();
		abData = new byte[(int)lLengthInFrames * audioFormat.getFrameSize()];
		while (true)
		{
			//int	nRead = oscillator.read(abData,0,abData.length);
			int	nRead = oscillator.read(abData);								// fyll abData med hela multipler av frames
			line.write(abData, 0, nRead); 
		}
	}

}

[Mindmapper]

Det kanske finns någon som labbat med LM567 och kan svara på om de bandbredder jag valt är lagom?

Om bandbredden är nog beror mera på hur frekvensstabil signalen blir. Det var länge sedan jag höll på med 567. Ofta gjorde man felet att beräkna för låg bandbredd på 567 medan det som satte gränsen egentligen var stabiliteten i signalen. Jag tycker i ditt fall att du har en vettig bandbredd.

I övrigt intressant, men komplicerad lösning.

[4kTRB]

Stabil frekvens tror jag det kommer vara, jag får kolla upp
det med en frekvensräknare. Hoppas inte att det ska ställa till problem.
Jag kommer inte skicka ut en ton längre än növändigt.

Låter betryggande att bandbredderna håller sig inom godkända gränser.

Nu har jag funderat mer på hur jag ska få det hela att fungera och har
kommit fram till det här blockschemat...


Räknare, multiplexern, F-V, och generatorn behövs för varje färg.
Det blir begränsat till 16 olika nivåer. Jag får se om det kan räcka.

Idén med generatorn är att då den väl är inställd så kommer den att
ligga med fast frekvens och det blir konstant spänning till strömkällan.

Uppräkningen av binärräknaren sker genom att skicka önskat antal
med skurar med 1kHz så tondekodern ger en puls per skur.

Det kommer bli kul att bygga generatorn då jag tänk använda mig av en PLL.

[Mindmapper]

Tycker att det skulle bli lättare att skippa mux, pll och V/f och istället använda en DA-omvandlare, direkt kopplad till räknaren.

[4kTRB]

En idé ja.
Fast jag är lite nyfiken på PLL lösningen som kan vara användbar också till annat.

Så nu har jag kommit så långt att räknardelen borde fungera, logiskt i vilket fall.
Jag har kopplat upp räknarnas CLEAR logik på labbplatta men där hade jag 3 st. NAND
kopplad som OR så jag får ta och testa det här också. Lösningen med vippa i kombination
med OR är inte helt optimal då det blir glitchar vid omslaget därför får jag ha ett RC-nät
mellan klockan och OR för att fördröja signalen en aning och då såg det fint ut på
oscilloskopet. Då jag ska ha 16 nivåer så behövs 2 st. MUX och de väljs mha OEa och
OEb. 0-7 första MUX:en och resten andra MUX:en.



Jag fick också ändra ingångsfiltret en aning då det tillkommer en tondekoder för räknefunktionen.

[4kTRB]

Adderade också trimmisar för inställning av centerfrekvensen till dekodrarna.

[4kTRB]

Körde ingångsfiltret i PSPICE där den gröna kurvan är för räknardekodern.

[Mindmapper]

Är du sugen på PLL lösningen så ska du naturligtvis köra på den. Blir det bekymmer så har du DA lösningen att falla tillbaka på.

Tror ej du kommer att få några problem med signalerna in till 567 även om du har ett brett ingångsfilter. De är bra på att skilja ut olika frekvenser från varandra. Så länge du inte har en massa fyrkantvågor med lägre frekvens än de önskade signalerna bör det gå bra.

[4kTRB]

Den här kopplingen får hamna på ett eget kretskort, EAGLE friversionen är
ju begränsad till 10x8. Då kan jag ju också bygga ett annat kort med A/D
på senare och testa med det. A/D kan vara fördel om jag vill ha många fler
nivåer men då får jag lägga dit andra räknare eller fler. Men nu har jag ju
principen klar så det blir enkelt att lägga till.