I modified some old assembly code that I wrote up for a Wolfson WM8741 DAC last year. For the PS I'm using a simple LM337/317 pair running at +/-8.5V. Connected the +8.5V to a 3.3V LDO for VD. No real surprises, pretty much followed the data sheets and it came right up. I did include the errata register settings as recommended.
Last edited:
Interesting, I hadn't heard of this IC before, looks promising!
I have some questions for those who have used it...
The datasheet says zero crossing detection applies to start-up and shut-down. Does this mean it is silent when powering on/off, unlike the PGA2310?
Apart from the number of channels, most of the specs look pretty similar to the PGA. Has anyone noticed any advantages the CS3318 has over the TI PGA?
I have some questions for those who have used it...
The datasheet says zero crossing detection applies to start-up and shut-down. Does this mean it is silent when powering on/off, unlike the PGA2310?
Apart from the number of channels, most of the specs look pretty similar to the PGA. Has anyone noticed any advantages the CS3318 has over the TI PGA?
It seems absolutely INSANE that the errata quoted in post #6 of this thread concerning the CS3318 is not in the data sheet (or ANYWHERE to be found on the Cirrus website)! It is either:
- A HUGE oversight by Cirrus
- The bug has been fixed and thus the document is no longer valid
- Something else?
Hi fualcar,
I removed the errata registers from my code, it appears to make no difference. But I agree with you, Cirrus in their most current data sheets should write in detail why it was necessary and has the bug been totally fixed. I'll call tech support later today and let you know what's the latest.
Best Regards,
Al
I removed the errata registers from my code, it appears to make no difference. But I agree with you, Cirrus in their most current data sheets should write in detail why it was necessary and has the bug been totally fixed. I'll call tech support later today and let you know what's the latest.
Best Regards,
Al
I plan to use muting relays on mine, that much I know.
almost no electronics is graceful on up/down's, these days.
maybe its a cop-out but I'll just have output muting relays that protect against power ons and offs.
I did read a thread about some magic spells you can do on the pga to quiet it down but again, the relay is the conclusion the other author came to, as well, iirc.
almost no electronics is graceful on up/down's, these days.
maybe its a cop-out but I'll just have output muting relays that protect against power ons and offs.
I did read a thread about some magic spells you can do on the pga to quiet it down but again, the relay is the conclusion the other author came to, as well, iirc.
finally, an update!
and.....
it works
some pics attached. note that the one marked 10khz is actually 20khz, I mislabled it.
this board took me about a week to build. this was the proof-of-concept phase. its not something I would want to build a second time by hand, though
now begins the testing phase. trying differing PSUs, buffers and so on.
oh, and software. lots more software. I'm making a CLI for it so that you can console in over serial, enter either people-friendly or machine-friendly commands and the arduino will translate to cirrus-talk, over the spi bus.
when I get the CLI working to the point where its useful, I'll post the whole driver and app set for the arduino (standard C++).
and.....
it works
some pics attached. note that the one marked 10khz is actually 20khz, I mislabled it.
this board took me about a week to build. this was the proof-of-concept phase. its not something I would want to build a second time by hand, though
now begins the testing phase. trying differing PSUs, buffers and so on.
oh, and software. lots more software. I'm making a CLI for it so that you can console in over serial, enter either people-friendly or machine-friendly commands and the arduino will translate to cirrus-talk, over the spi bus.
when I get the CLI working to the point where its useful, I'll post the whole driver and app set for the arduino (standard C++).
Attachments
installed the board into my test chassis.
giving it a simple 7808/7908 supply from a diy proto board, in the chassis. trafo is on the floor in its own box along with bridge and caps. using a simple easy to find 5pin midi cable to join the 2 boxes
the 78xx reg chips are not all that bad, here! I'm pretty sure my chip-amps are now noisier than this cirrus system is.
the behringer source is WAY WAY too hot for this chip, though! I think I need a 15db pad or something high like that. some input buffers are next to be built for this.
giving it a simple 7808/7908 supply from a diy proto board, in the chassis. trafo is on the floor in its own box along with bridge and caps. using a simple easy to find 5pin midi cable to join the 2 boxes
the 78xx reg chips are not all that bad, here! I'm pretty sure my chip-amps are now noisier than this cirrus system is.
the behringer source is WAY WAY too hot for this chip, though! I think I need a 15db pad or something high like that. some input buffers are next to be built for this.
Attachments
No it's not, if you power the internal opamps down you get a nasty thump on the output.
Ditch the DCX output board as 0dBFS is about +22dBu and the DAC o/p is standard 5vpp offset around +2.5V. Or reduce the gain in the o/p board by changing a couple of SMD resistors/ch.
I plan to attack the high levels in 2 ways. at the dcx (in some way) and also via a selectable 14db pad on/off relay. it will either pad or pass thru. just in case anyone needs it, on a per-port basis.
at the dcx, I'm thinking of sending i2s or spdif out instead of analog. then using the dac-of-the-day to supply me the analogs
at the dcx, I'm thinking of sending i2s or spdif out instead of analog. then using the dac-of-the-day to supply me the analogs
my proto output buffer/relay board. i2c controlled on the digital side. on analog, it gets power via a 6pin bipolar psu (not shown, only the empty red header in the middle). 8pin opa2134 style footprint chips can go in the sockets, or not! builder's choice. simply stub +input to output and you're done. this will run in unity non-inverting mode and so you can run OA's, or external buffers that have cables into the OA sockets or just wire stubs to ignore buffers.
relays are muting function as well as output selection. that's all the controller chip is there for.
the i2c connection can go to the master UI controller or a secondary embedded controller, such as the one on the cirrus proto board. if the relay board is behind the embedded arduino, then it 'proxies' for the relays upstream to the real UI master. otoh, if the master has the i2c connection, its sort of a tree, now, with the master UI controlling the vol control board over spi and the relays that 'match' it over i2c.
the ribbon i2c uses the lcduino 'standard' of 2 pins for 5v, 2 for gnd, 1 for i2c-clock and 1 for i2c-data. doubling up on power/gnd lets you supply running current to the 'remote' boards in addition to i2c control signals.
these are non-latching relays and will draw a little current (about 30ma each) during operation. they will be clicked down to UNMUTE them. any loss of power or control signal causes them to click-up and that causes the output pins to short to gnd, making the downstream amps 'safe'. the muting relays are as much a safety design detail as an output sel/muting feature.
relays are muting function as well as output selection. that's all the controller chip is there for.
the i2c connection can go to the master UI controller or a secondary embedded controller, such as the one on the cirrus proto board. if the relay board is behind the embedded arduino, then it 'proxies' for the relays upstream to the real UI master. otoh, if the master has the i2c connection, its sort of a tree, now, with the master UI controlling the vol control board over spi and the relays that 'match' it over i2c.
the ribbon i2c uses the lcduino 'standard' of 2 pins for 5v, 2 for gnd, 1 for i2c-clock and 1 for i2c-data. doubling up on power/gnd lets you supply running current to the 'remote' boards in addition to i2c control signals.
these are non-latching relays and will draw a little current (about 30ma each) during operation. they will be clicked down to UNMUTE them. any loss of power or control signal causes them to click-up and that causes the output pins to short to gnd, making the downstream amps 'safe'. the muting relays are as much a safety design detail as an output sel/muting feature.
Attachments
I can't see exactly how you've got these relays arranged, but I use muting relays in a PGA volume control system. I was recently reminded that most relays have a pull-in current higher than their holding current, so if you can arrange to drive them with a lower current once pulled-in this saves a bit of current.
In my case the relays are 10mA 5V driven directly by PIC outputs (TE Connectivity Axicom IM23GR). I've got spare pins on the PIC, so on the next iteration of the board I intend to pull in the relays with one pin but hold them on with another pin connected through a diode, probably a LED because of its greater voltage drop. With the LED dropping some voltage the relay coils will pass less current, it's just a question of trying a few different LEDs, red, green and blue to see how low I can get the current and still hold the relay on. Since it's a battery application, it makes a difference. If the current is important to you, and you've got spare uProc pins, you could try it.
on the AMB delta1 and delta2, we used latching relays which save even MORE power but they take up twice as many pins, sounding a bit like your idea.
these are fairly low current relays (20ma or 30ma at most) and I'm not sure how much is saved by adding more complexity in lowering relay 'hold' voltage. this is an AC powered project, for sure, though.
for input selection, I do like using latchers since there's no reason to have to let them click-up on power loss. its only the power loss thing that made me want to use non-latchers for output.
the relays are omron g6j-2p-y
which ones are you using, that use only 10ma?
but they take up twice as many pins, sounding a bit like your idea.these are fairly low current relays (20ma or 30ma at most) and I'm not sure how much is saved by adding more complexity in lowering relay 'hold' voltage. this is an AC powered project, for sure, though.
for input selection, I do like using latchers since there's no reason to have to let them click-up on power loss. its only the power loss thing that made me want to use non-latchers for output.
the relays are omron g6j-2p-y
which ones are you using, that use only 10ma?