• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Custom firmware for B3/B3SEPro

Status
Not open for further replies.
Jump to Latest
H

harruharru

Member
Joined 2005
#1
I have just finished building the 9038 pro with the Mercury. It sounds a bit darker, but with a lot of details and a large sound stage.

However I am at a dead end to get i2c communication working. I am using a Buffalo III for 6 channels and the 9038 pro for two channels. An Arduino Uno is connected to the Buffalo III then i2c cables from the Buffalo III to the 9038. The 9038 is replacing a Buffalo II. For some reason I do not manage to get the i2c communication working for the 9038. I have removed the chip and connected the cables to the i2c header. The code has also been modified to work with the 9038. However no luck so far. I put the DAC in Reset mode and out of reset mode via software.

Any suggesion?

Do I have to short the ADC header?

I have tried to set the addr header on both boards. The Buffalo III works in both cases, but not the 9038
 
Last edited:
#3
I believe that you do.

Brian's controller does it through software control of the reset pin.

The proper thing to do appears to be to control the reset pin by the arduino, so as to properly reset the 9038 after power-on, but in all of my testing I've had no problems with the reset pin being always pulled down.
 
#4
Dimdim
Just so I understand you correctly. Pin 1 on the GPIO could be connected with a jumper to ground (kept low) all the time and then I can do the reset by i2c via software?

If I understand Brian's code correctly. The pin1 is kept low when the dac turns on and then after 1500ms pulled up.

Just for referrence of the reset pin: The reset pin should be kept low until all power supplies are up and running. Then the reset pin should be set high. To reset the dac after the power up sequence the reset pin needs to be pulled low then high. Is this correct understanding?
 
Last edited:
#5
harruharru said:
Dimdim
Just so I understand you correctly. Pin 1 on the GPIO could be connected with a jumper to ground (kept low) all the time and then I can do the reset by i2c via software?
Click to expand...

Pin 1 should be connected to gnd through a resistor (it probably already is..).

At power-on, after the supplies have stabilized, it should be pulled high by a digital line from the arduino, not through i2c.

harruharru said:
If I understand Brian's code correctly. The pin1 is kept low when the dac turns on and then after 1500ms pulled up.

Just for referrence of the reset pin: The reset pin should be kept low until all power supplies are up and running. Then the reset pin should be set high. To reset the dac after the power up sequence the reset pin needs to be pulled low then high. Is this correct understanding?
Click to expand...

Exactly.

In my previous post I meant that I have the reset line constantly pulled high, not low.
 
#10
I use an anolog devices ADuM1250 so no spare output. I go for a relay.

I measure 256 ohm between pin 8 on the dac and pin 1. I do not know if a resistor is needed. The traces are not visible on the board so it is difficult to know if a resistor is needed. I would beleive it is not needed since pin 2 is DVCC. It seems logical to be short pin1 to pin2 without a resistor. Same goes for pin 11 DAC_ADDR short to Pin 12 DVCC.
 
#14
Russ White said:
BTW it is absolutely not a good idea to just hold reset high all the time - while the DAC will operate (usually) - it will not be properly initialized. This actually matters much more than you might think - as the initialization sets analog operating points.
Click to expand...

This is interesting. I thought that I had just got lucky with my power supplies power-up sequencing. I'll do a revision of my code supporting the proper dac reset procedure.
 
#15
I guess this question fits in this thread.. 🙂 My first build is using an Arduino Due to switch the IO header pins and a MUX. The Arduino is powered from a separate transformer and regulator from all the TPA boards.

The configuration is:

Mercury fed from a TPA Placid BP HD (From transformer 1)
BIIISE fed from one channel of a LPDPS HO and Cronus / Hermes fed from the other. (from transformer 2)
MUX 4:1 fed from one output of a LPDPS at 5v and the other output feeds a Arduino Due. (from transformer 3)

My question is how to connect (on not connect) the grounds, or I guess whether the 0v lines should connect to a case/supply ground. Should the analog and digital ground connect at all?

I am a relative novice when it comes to interfacing analog and digital circuits and not a EE by training so please excuse the perhaps dumb questions!
 
#16
Using a relay to switch the reset pin high worked fine. I finished writing a new firmware for the DAC this weekend. The DAC with my custom firmware works fine. The Buffalo 38Pro is a big upgrade in SQ over the Buffalo II with IVY it is replacing. The sound is warmer with more details and bigger soundstage.
 
Last edited:
#17
MartinC700 said:
I guess this question fits in this thread.. 🙂 My first build is using an Arduino Due to switch the IO header pins and a MUX. The Arduino is powered from a separate transformer and regulator from all the TPA boards.

The configuration is:

Mercury fed from a TPA Placid BP HD (From transformer 1)
BIIISE fed from one channel of a LPDPS HO and Cronus / Hermes fed from the other. (from transformer 2)
MUX 4:1 fed from one output of a LPDPS at 5v and the other output feeds a Arduino Due. (from transformer 3)

My question is how to connect (on not connect) the grounds, or I guess whether the 0v lines should connect to a case/supply ground. Should the analog and digital ground connect at all?

I am a relative novice when it comes to interfacing analog and digital circuits and not a EE by training so please excuse the perhaps dumb questions!
Click to expand...

You must have a common ground - I would simply connect it at the IO header.
 
#18
harruharru said:
Using a relay to switch the reset pin high worked fine. I finished writing a new firmware for the DAC this weekend. The DAC with my custom firmware works fine. The Buffalo 38Pro is a big upgrade in SQ over the Buffalo II with IVY it is replacing. The sound is warmer with more details and bigger soundstage.
Click to expand...

Awesome! Glad it is working well for you! Enjoy the music.
 
#19
All is working well now, thanks for the help. Russ, in a prior thread you mentioned the possibility of customizing the onboard firmware to give additional display outputs, is there anyway that one could get the onboard controller to capture the DAC sampling frequency so that could be read by an external device like an Arduino? - (I know you noted that the data could not read from I2S, there any other way a secondary device can be supplied data from the ATMEL?) My simplistic code now switches all the inbuilt switch functions and displays the settings but is lacking the ability to display the frequency, which would be a nice finishing touch.
 
Last edited:
Status
Not open for further replies.
Top Bottom