Hi Marzie,
Thanks for the suggestion. As you say though, there is actually some black on them and you could easily make a case capable of hiding the white altogether. Also I really don't want to change this aspect of the PCB as knowing my luck I won't get it right first time and I've spent enough on prototype runs so far! I've got a better pic of the jacks for you:
As for how things are going, I'm currently trying to resolve a small software issue. When changing source, about 1 time in 10 the DACs fail to mute and there is a horriffic noise through the outputs. The other 9 times, the DACs mute nicely and the source changes and they come back up again. If anyone with some software knowhow has any ideas why this may be, they'd be gratefully received!
Here is a sample bit of code for looking at the switches:
Code:
Code:
[left]if (bit_is_clear(PINB, 3) && (current_src != 3)) { for (counter = 0; counter <= mute_time; counter++) { PORTD &= ~(1<<1); // Mute DACs } //SPDIF source = 011 i2c_start(WM8805+I2C_WRITE); i2c_write(0x08); // write address = 08 i2c_write(0x1B); // data = 1Bh i2c_stop(); // stop, release bus current_src = 3; //put on corresponding LED: PORTB = 0x8f; // source 3 - output 3 on; inputs with pullups. for (counter = 0; counter <= mute_time; counter++) { PORTD &= ~(1<<1); // Mute DACs } PORTD |= 1<<1; //unmute DACs } else {//no change in source, move on... counter = 0; //do something useless }[/left]
I know I haven't done a lot to deal with switchbounce, but my feeling is that the opening 'if' means that this is only ever executed once and the 'if_bit_is_clear' decision decides that the switch is or is not pressed, after that it should be immaterial. Oh, also, the two 'for' loops is just me trying stuff to try and make it work, there was originally only one.
I have considered that it may be due to the optimiser removing what it considers to be useless instructions, but then I think the mute would fail every time.
As I have said, my C and, in particular, microprocessor knowledge is limited so any advice gratefully received!
A second issue is what looks on the face of it to be oscillation at the output filters. When probing the outputs with no music, I can see a sine wave of a few 10s of mV in the 10's of MHz region. I am convinced that this is being caused by the capacitance of my cheap 'scope probe - i.e. it isn't there unless I'm looking for it! It only happens with the AD797, not the OPA134. I am further convinced that it is caused by the probe since changing the probe to x10 mode (this changes the capacitance of the probe) changes the frequency and amplitude of the oscillation - the amplitude isn't changed by the factor of 10 expected, it is much less. Anyone got any views on this? As I say, I'm fairly sure it is caused by the probe so it isn't a problem, but I don't want to pass this problem onto other people until I'm certain!