Rank: Member
Groups: Member
Joined: 11/9/2007(UTC)
Posts: 453
Location: usa
|
Good to know. Thanks! If you make improvements, let us know.
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 10/6/2008(UTC)
Posts: 29
Location: peoples paradise NY
|
Ronpod, care to share what you have done with the forum? Also it is OK with glt to share this info with everybody?
Judging by the amount of views on this topic, I am not the only one who would like to see how this was done.
Step by step if possible with a BOM. For us weak minded types.........
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 7/17/2010(UTC)
Posts: 22
Location: Colorado USA
|
Washout - I followed Glt's blog instructions mostly except I used a different display because it was available quickly. I would suggest using the same display as in Glt's blog to make life easier. My use of a different display required that I interpret a German web forum to understand the program code necessary to adapt that display. So Glt's original recipe may have the short cuts you would desire to make the build simplified.
I will be out for a few days but can help when I get back...
Merry Christmas!
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 11/9/2007(UTC)
Posts: 453
Location: usa
|
Washout, yes it is OK with me to share any info... Have fun with the project. Feel free to ask questions
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 10/6/2008(UTC)
Posts: 29
Location: peoples paradise NY
|
glt, spent alot more time looking at the info you have listed, and it is laid out in a very "step by step" manner. So, sorry for asking for something already there! It does look like a very interesting project, not nearly as scary as I had imagined.
I do have to ask a question before I start. I am out of room for an lcd in my currently planned case for the Buff. Will there be any problem with a short umbilical from the Arduino in a separate case to the I2C header on the Buff dac via a RJ45 type plug? I don't think the over all length would be more 10-12 inches.
ronpod and glt, thanks for the offers to help. I'm sure there will be questions.
|
|
|
|
|
|
Rank: Administration
Groups: Administration, Customer
Joined: 10/24/2006(UTC)
Posts: 3,979
Location: Nashville, TN
Thanks: 25 times
Was thanked: 89 time(s) in 83 post(s)
|
It shouldn't be a problem at all. I2C is a low speed and not very finicky protocol.
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 11/9/2007(UTC)
Posts: 453
Location: usa
|
Yeah, what Russ said. I use the CD-audio wires you find inside PCs. It has 3 wires, already terminated for pin connectors and it is about 16 inch in length. And they are free :-) http://media.digikey.com...n%20Photos/AK2525-.5.jpgI have also update the " BOM" for those interested Edited by user Tuesday, December 21, 2010 10:11:33 PM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 9/4/2008(UTC)
Posts: 11
Location: NL
|
I have built the "glt-controller" as well. It works like a charm. Have one question though: is there a specific startup sequence required? Should the DAC be powered on after or before starting the Arduino? And what if the DAC is restarted when the 'glt' keeps running? How are the registers set then?
The Arduino and display are fitted in a seperate enclosure to the BII and I used standard UTP cable to connect the two. Works fine as well.
I did make some modifications to fit everything on a VFD type 16*2 display, so I moved the samplerate readings and other stuff to a second page. You reach this second page by a double-click on the rotary controller. Turning the rotary while on that page moves through the different settings als allows for changes to the BII registers.
A single click will change inputs on the MUX by changing the state of 2 Arduino outputs. I also implemented a LCD subroutine to reflect the change of input on the MUX.
A long-click switches off my UCD400 amps and deactivates a relay which causes the DAC enclosure to power-off (hence my question on startup order...).
So, I would like to thank both Brian/Russ and glt for their work!
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 11/9/2007(UTC)
Posts: 453
Location: usa
|
I power the DAC and Arduino at the same time. I have a tiny delay while displaying the "welcome screen" before programming the volume registers. This works fine. If you power cycle the DAC, then Arduino would not know and the DAC will come up with the default values (means full volume, etc). The datasheet tells you what are the default values.
According the Russ, you really never have to reset the DAC. The Arduino has a reset button where you can restart the program from the beginning. But I don't have a "reset to default" routine in my code yet. Ideally you might want to reprogram all the registers to a "default value" when you reset the Arduino without resetting the DAC (I'll do that in the next version).
Good idea having multiple screens to set parameters.
|
|
|
|
|
|
Rank: Administration
Groups: Administration, Customer
Joined: 10/24/2006(UTC)
Posts: 3,979
Location: Nashville, TN
Thanks: 25 times
Was thanked: 89 time(s) in 83 post(s)
|
That is where checking that the registers are what you expect them to be at a regular interval comes into play. :) If you then for some reason have a DAC reset without the controller, the controller can then easily recover and return the DAC to the state you really want it in. Edited by user Thursday, December 23, 2010 7:37:24 PM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 11/9/2007(UTC)
Posts: 453
Location: usa
|
Yes.
Ideally the DAC should restart in mute and indicate a startup/reset condition with a pin, then the controller can poll that pin and reset the registers.
|
|
|
|
|
|
Rank: Administration
Groups: Administration, Customer
Joined: 10/24/2006(UTC)
Posts: 3,979
Location: Nashville, TN
Thanks: 25 times
Was thanked: 89 time(s) in 83 post(s)
|
No, that actually would not be very ideal for apps that don't even need a controller. Which are many, :) The DAC correctly fires up completely ready to play. It is up to the controller to implement logical responses to varying conditions. Edited by user Thursday, December 23, 2010 7:55:04 PM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 11/9/2007(UTC)
Posts: 453
Location: usa
|
True. I'm only familiar with one other device: WM8741 in the OPUS. That chip has two modes: H/W and S/W. The Sabre doesn't have a h/w or s/w mode.
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 9/4/2008(UTC)
Posts: 11
Location: NL
|
Thanks for pointing out that I _should_ implement some logic to monitor at lease the DAC volume registers... I do NOT want to suddenly use the DAC with no attenuation... As I am powering the GLT by its own psu, I now use the 3.3v originally intended to power the volumite as a sort of DAC-status-pin. This is the code: Code:while(digitalRead(DACSENSE)==LOW)
{
lcd.clear();
lcd.print("The DAC is off!");
DACRESET=true;
delay(2000);
}
if(DACRESET)
{
lcd.clear();
lcd.setCursor(0,0);
lcd.print("Hello...");
lcd.setCursor(0,1);
lcd.print("the DAC is back!");
// Assign and set default values for DAC
delay(500);
dpllBW=1; // This is the default value of dpll bandwidth (1=lowest)
sharp=true; // This is the default value of roll-off filter (sharp)
jitter=true; // This is the default value for jitter reduction (ON)
writeSabreReg(25,0); // Allow all DPLL settings
setSabreVolume(currAttnu); // Set volume at startup otherwise full volume
delay(2000);
mainScreen();
DACRESET=false;
}
What do you think? How soon after finding the pin high again can I initialize the registers? Is the 500ms it currently is, enough? Edited by user Sunday, December 26, 2010 3:42:32 PM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Administration
Groups: Administration, Customer
Joined: 10/24/2006(UTC)
Posts: 3,979
Location: Nashville, TN
Thanks: 25 times
Was thanked: 89 time(s) in 83 post(s)
|
That's a good start but actually more complex than it needs to be. :) Still your thinking along the right lines. Good work!
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 11/9/2007(UTC)
Posts: 453
Location: usa
|
Hello Lennert, If you power the DAC separately from the controller, then something like this may work better so you don't have to depend on a fixed dealy: if 3.3V line is low --DACOFF==true else (//3.3 line is high) --if DACOFF (// Only reset if DAC was off) ----ResetDAC ----DACOFF==false (ignore the dashes, just for formatting) Edited by user Monday, December 27, 2010 11:06:59 AM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Administration
Groups: Administration, Customer
Joined: 10/24/2006(UTC)
Posts: 3,979
Location: Nashville, TN
Thanks: 25 times
Was thanked: 89 time(s) in 83 post(s)
|
It is much better(read safer) to actually *query* the DAC, than it is to simply react to your own signals. Because there are reasons the DAC can reset that are actually beyond your control. This way you don;t have to worry about "why" just "what". Edited by user Monday, December 27, 2010 1:59:46 PM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 9/4/2008(UTC)
Posts: 11
Location: NL
|
Russ White wrote:It is much better(read safer) to actually *query* the DAC, than it is to simply react to your own signals. Because there are reasons the DAC can reset that are actually beyond your control. This way you don;t have to worry about "why" just "what". Yes, I figured that would be better, but without the datasheet (and I am going through the NDA to get it) it is a little difficult to find all adresses and values. As is fiddling with I2C is for me... An example of my intentions: Quote:byte readSabreReg() {
Wire.beginTransmission(0x48); // Hard coded the Sabre/Buffalo device address
Wire.send(0x0A); // Hard coded to Jitter register for now
Wire.endTransmission();
Wire.requestFrom(0x48,1); // Hard coded to Buffalo, request one byte from address
// specified with Wire.send()
//while(!Wire.available()) { // Wait for byte to be available on the bus
if(Wire.available()) {
}
return Wire.receive(); // Return the value returned by specified register
} I deducted from glt's code that 0x0A is the Jitter register. If it contains 0xCE (206), it means Jitter control is on, if it contains 0xCA (202), it's off. Right? If I call this routine and print the result, as HEX, I get either CA for 'Off' or CE for 'On' as a result... So far so good. Now I can compare it to what I want it to be and correct if it deviates. If you agree with the above, this is what I'm going to work with to make sure that the (important) registers (like volume) are what I want them to be... One 'wierd' thing, which appears to be I2C related. Sometimes, if I power-cycle the DAC (to mimic what my wife might do somewhere down the line...:) the I2C link appears to not recover well. The Arduino seems to hang... Do you recognize this? So, I concluded to power the Arduino from the DAC's PSU as well, this means I do not have to worry about this scenario. BTW: credits for this code to glt! Edited by user Monday, December 27, 2010 3:07:00 PM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 11/9/2007(UTC)
Posts: 453
Location: usa
|
Lennert, I'll add some of the register definitions to the code in a few days... Regarding "hanging" if the DAC is off, I'll have to check the code. Used to have a routine waiting for the status register to be available for reading. It could be hanging there... Edited by user Monday, December 27, 2010 8:58:39 PM(UTC)
| Reason: Not specified
|
|
|
|
|
|
Rank: Member
Groups: Member
Joined: 8/26/2008(UTC)
Posts: 11
|
glt, is it possible to control multiple DACs (Opus) with a single arduino?
:)
|
|
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
