uC DAC tester?

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
You know what else this would be great for?

Hint: Instead of 1kHz. How about 60Hz?

I2S to a nice DAC and a beefy output stage with lots of voltage gain. And you have yourself a absolutely pristine AC source for the rest of your equipment. You could have the anti-aliasing filter corner frequency set at something super low, like 240Hz. Any remaining digital noise would be far too low to measure.
 
Cameron said:
You know what else this would be great for?

Hint: Instead of 1kHz. How about 60Hz?

I2S to a nice DAC and a beefy output stage with lots of voltage gain. And you have yourself a absolutely pristine AC source for the rest of your equipment. You could have the anti-aliasing filter corner frequency set at something super low, like 240Hz. Any remaining digital noise would be far too low to measure.


If you do build it, you might want to consider a sample rate a bit less than 44100Hz.
 
jbokelman said:


:) That's well advised because jobstens' circuit won't work at 44100Hz.

Why ? You only need more ROM.
60 Hz@44100 - one wave is 735 Samples long. That's 11760 Bits - You need a 27128.


But for this project I would prefer fs=192kHz with 24Bit.
I also would add two channels for threephase - that's better for the car-lift (or something ...) :)



Regards

Jobstens
 
I would also stick with a higher frequency sample rate. Otherwise you won't get the benefits of massively filtered and clean output. If your corner frequency is 240Hz, the drop at 60Hz is like .01dB, but at 352.8kHz (for 44.1kHz), the drop is huge. That's over 10 octaves. Even a simple 2 pole filter would then yield roughly 126dB down.

Another modification might be to synchronize the synthesized 60Hz with the line, compare the two, and amplify a difference signal. That way, the vast majority of the power comes straight from the line, but you still get stupid clean power at the output. You would still need a fairly decent power output stage capable of RF frequencies. Otherwise it would not be able to cancel out RF in the line.
 
Originally posted by jobstens
Why ? You only need more ROM.

The size of the ROM is not the problem. But, hey, you're the expert with 26 years experience. I'm sure you wouldn't post a design for others to copy if you hadn't first built it and verified that it works. Right? Or at least done a thorough desk check to verify that, considering the access time of the ROM and the setup requirements of the DIT, the 4040 ripple counter could settle a 13-bit address with time to spare.

What's going on here? It looks like a bunch of analog weenies playing with DACs and nobody knows diddlysquat about digital circuits. As I said, this web site should be called cseAudio and this forum should be called SingleChipDACAudio because anything beyond connecting a CS8412 to a TAD154x is unfathomable.
 
At 24/192 thats a lot of samples and at 352.8KHz things are starting to get excessive given that a small microcontroller and a pair of R/C filters would suffice for a turntable. But since the engineers have obviously kidnapped the accounts department and the financial director,replacing them with robots, abandoning all sense of restraint along the way,lets go crazy.
On a more serious note, why use audio sample rates? I would chose a convenient number of samples per quadrant and derive the sample rate from that.
 
jbokelman,

I don't really understand your argument. I can do digital designs much more easier than analog designs. In a good DAC you need analog AND digital you know. Look at the DAC designs on this forum. Lots are very good designs. I'm using the DAC using the CS8420 and a CS43122 by jwb. Best sound I've heard in all the digital equipment I own. jwb did well, and took into account noise aquired from poor ground plane layout and power supply sources. Most of it is surface mount except for the electrolytic caps, the HEXFETS, BJT transistors, and LEDs in the line driver section. Check out the thread for the revision 2 of his DAC. The board layout is kick *** in my opinion. He even used small MSOP (3mmx3mm case size) 5V regulators. In my opinion, it's one of the best DAC designs on this forum. It's one of my favorite designs too. It's sound is quite good. Only two sources I've tested it with are CDs and XM radio. CDs sound great, XM radio sounds like a badly compressed mp3, but it's sample length is 24 bits. The other source I plan to use is music choice on directv, but my 20Mbps RS422/485 tranceiver ICs used to transmit the S/PDIF over long distances have not arrived yet. Please don't critisize other people's work.
 
jbokelman said:


The size of the ROM is not the problem. But, hey, you're the expert with 26 years experience. I'm sure you wouldn't post a design for others to copy if you hadn't first built it and verified that it works. Right? Or at least done a thorough desk check to verify that, considering the access time of the ROM and the setup requirements of the DIT, the 4040 ripple counter could settle a 13-bit address with time to spare.

What's going on here? It looks like a bunch of analog weenies playing with DACs and nobody knows diddlysquat about digital circuits. As I said, this web site should be called cseAudio and this forum should be called SingleChipDACAudio because anything beyond connecting a CS8412 to a TAD154x is unfathomable.


Hmmm ...

In my circuit all addresslines (output from 4040) are approx. 100ns set after rising edge of BCLK. Approx. 170ns after the rising edge of BCLK D0 is set. (By the way: in my diagram i have written D2 instead of D0) That is approx. 180ns before rising edge from BCLK. The DIT4192 needs 15ns ...
The circuit works fine with my DACs, but I haven't tested it with a SPDIF-Transmitter.


Regards

Jobstens
 
Sorry ... I have made 2 mistakes ...

In my circuit all addresslines (output from 4040) are approx. 100ns set after falling edge of BCLK. Approx. 170ns after the falling edge of BCLK D0 is set. (By the way: in my diagram i have written D2 instead of D0) That is approx. 180ns before rising edge from BCLK. The DIT4192 needs 15ns ...
The circuit works fine with my DACs, but I haven't tested it with a SPDIF-Transmitter.


Regards

Jobstens
 
Originally posted by jobstens
In my circuit all addresslines (output from 4040) are approx. 100ns set after falling edge of BCLK.

That’s hard to believe. Using the typical propagations times listed in the Philips HEF4040B data sheet you posted, the settling time for a 13-bit address is 525ns. That includes 1 CP->D0 time (105ns) and 12 Dn->Dn+1 times (35ns). Using the maximum guaranteed times, the total is 1050ns. To get the times you report would require a 4040 that is more than five times faster than the specified typical times. It’s unusual for chips to beat their specs by that margin.
 
Originally posted by emuman100
Please don't critisize other people's work.

I didn’t realize criticism was against the rules of this forum. So, if I happen to see an obvious error in a posted schematic, I should keep my mouth shut. OK.

If proposed designs cannot be critically evaluated and discussed, what’s the point of this forum? How does anyone learn in an environment where mediocrity is celebrated?
 
That's happen, if you have your head full with other things.

jbokelman, you're right, those timings are impossible with a standard 4040. Sorry. I have used, and I have thought about a 74HC4040. Thanks for the hint.

emuman100: It is strongly recommended that you use the 74HC4040 !

This is the right Datasheet:

http://www.semiconductors.philips.com/acrobat/datasheets/74HC_HCT4040_CNV_2.pdf



Regards

Jobstens
 
Jobstens, there is another detail in your circuit that does not conform to standard accepted digital design practice. I’m sure you know what it is, but I can’t say because that would be criticism and emuman says I shouldn’t criticize someone else’s design. If emuman builds your circuit he may or may not experience a problem, depending on the particular characteristics of the parts he uses. But, if he is as expert a digital designer as he thinks he is, he shouldn’t have any trouble diagnosing and correcting the problem.
 
Jobstens, without further criticism of your design and upsetting emuman, let me just say: It is bad practice to allow an asynchronous control line, such as RESET, persist in an undefined state. The data outputs of a ROM are undefined until Taccess time after the address lines are settled.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.