Well,
I do have a scope, but it has been put in storage due to having the house presentable as it is for sale.
However, I do feel the need to dig it out and investigate (if I get the chance).
I think starting with what should be a more sensible clock circuit might be a start either way though (it was a very quick test that I performed).
I might get the scope out this weekend (if I can find it amongst all the junk in the garage!).
Cheers,
Phil
I do have a scope, but it has been put in storage due to having the house presentable as it is for sale.
However, I do feel the need to dig it out and investigate (if I get the chance).
I think starting with what should be a more sensible clock circuit might be a start either way though (it was a very quick test that I performed).
I might get the scope out this weekend (if I can find it amongst all the junk in the garage!).
Cheers,
Phil
Hi All,
Well, I've finally managed to save my scope from the utter mess that is our garage full of clutter. Hurray!
Anyway, it seems the 7220 is alive. I can see a poor, almost sinusoidal clock on XSYS, and I can see a the output BCLK and WS are present, and that BCLK is half the frequency of XSYS and twice that of the input/NOS BCLK. So that's good.
When I apply an input (interestingly, I see that the output WS and BCLK occur without an input) I see that there is data being output too - I obviously can't tell if this is any good.
As I said before, all the signals are terrible, but I imagine they'd just about work as TTL signals - I've seen worse.
Anyway, this is badly knocked up, so I'm going to rebuild, thinking more carefully about grounding, PSU decoupling, signal lengths etc.
However, there are other possibilities that could be causing the problem.
The XSYS is not used to feed the transport (i.e. the transport is independently clocked). Although not ideal, I had previously set up a new clock for just the decoder, whilst leaving the digital filter and DAC onboard with the original clock, and it worked, so I'm not ruling it out, but it should be okay.
Also, I am using my TDA1541A NOS DAC prototype board as DAC, and it only has filtering on the IV opamp, as per datasheet. Should I have some more filtering prior to the opamp? Perhaps the opamp is oscillating, causing a LOT of hash over the audio signal? I guess the amount of hash present is dependent on the properties of the digital filter.
And, I haven't rechecked whether my DAC board is in offset binary or twos compliment mode. It works with the I2S from the decoder. I know the 7220 inputs and outputs twos compliment, so I assume that's the mode its in (i.e. unchanged from the DAC).
Anyway, there's my current thoughts on the issue. I shall keep looking.
I'm sure I've done something stupid.
I hope this has provided ample entertainment. LOL!
Cheers,
Phil
Well, I've finally managed to save my scope from the utter mess that is our garage full of clutter. Hurray!
Anyway, it seems the 7220 is alive. I can see a poor, almost sinusoidal clock on XSYS, and I can see a the output BCLK and WS are present, and that BCLK is half the frequency of XSYS and twice that of the input/NOS BCLK. So that's good.
When I apply an input (interestingly, I see that the output WS and BCLK occur without an input) I see that there is data being output too - I obviously can't tell if this is any good.
As I said before, all the signals are terrible, but I imagine they'd just about work as TTL signals - I've seen worse.
Anyway, this is badly knocked up, so I'm going to rebuild, thinking more carefully about grounding, PSU decoupling, signal lengths etc.
However, there are other possibilities that could be causing the problem.
The XSYS is not used to feed the transport (i.e. the transport is independently clocked). Although not ideal, I had previously set up a new clock for just the decoder, whilst leaving the digital filter and DAC onboard with the original clock, and it worked, so I'm not ruling it out, but it should be okay.
Also, I am using my TDA1541A NOS DAC prototype board as DAC, and it only has filtering on the IV opamp, as per datasheet. Should I have some more filtering prior to the opamp? Perhaps the opamp is oscillating, causing a LOT of hash over the audio signal? I guess the amount of hash present is dependent on the properties of the digital filter.
And, I haven't rechecked whether my DAC board is in offset binary or twos compliment mode. It works with the I2S from the decoder. I know the 7220 inputs and outputs twos compliment, so I assume that's the mode its in (i.e. unchanged from the DAC).
Anyway, there's my current thoughts on the issue. I shall keep looking.
I'm sure I've done something stupid.
I hope this has provided ample entertainment. LOL!
Cheers,
Phil
Re: Which opamps?
Cd 304 mk2 is heavy build, solid and simple, the first 16 bit player based on older 14 bit cd304, with an dye-cast aluminium CDM. Slow servo though.
Modded IV and bufferopamps yes. But some other prefer the LM4562 for that. I stayed on the THS so far. The cdm uses same +- 12volt, better would be a separate ps for the I/v opamps.
hollowman said:
Cd 304 mk2 is heavy build, solid and simple, the first 16 bit player based on older 14 bit cd304, with an dye-cast aluminium CDM. Slow servo though.
Modded IV and bufferopamps yes. But some other prefer the LM4562 for that. I stayed on the THS so far. The cdm uses same +- 12volt, better would be a separate ps for the I/v opamps.
Re: Re: Which opamps?
Agreed on separate pwr supplies.
As far as servo perfomance ... see this diyhifi message on how that may be improved.
tubee said:
Agreed on separate pwr supplies.
As far as servo perfomance ... see this diyhifi message on how that may be improved.
Blimey,
This thread has ressurected.
And, its got me thinking...
I haven't progressed with the 7220 at all since my last post - I've been busy rebuilding my TDA1541A DAC (better PSU, with LM317/337 followed by TL431 regulations makes SO much difference!).
I was of the opinion that, because the oversampling makes filtering essentially easier, it should be okay to quickly test the setup unfiltered.
Does anybody think my actual problem could be, because of the oversampled output being unfiltered, the opamp IV conversion is oscillating and creating next to nothing of a distorted signal?
If this is so, I always thought the reconstruction filter should be after the I/V stage (maybe I've just seen badly implemented NOS DACs where its less important?), but in my case it would have to be beforehand?
Is there an expert out there who can promptly laugh at my antics and set me off in the right direction? Could lack of filtering be the problem? Or is the problem more likely to do with weak (but reasonable for TTL) I2S signals?
Cheers,
Phil
This thread has ressurected.
And, its got me thinking...
I haven't progressed with the 7220 at all since my last post - I've been busy rebuilding my TDA1541A DAC (better PSU, with LM317/337 followed by TL431 regulations makes SO much difference!).
I was of the opinion that, because the oversampling makes filtering essentially easier, it should be okay to quickly test the setup unfiltered.
Does anybody think my actual problem could be, because of the oversampled output being unfiltered, the opamp IV conversion is oscillating and creating next to nothing of a distorted signal?
If this is so, I always thought the reconstruction filter should be after the I/V stage (maybe I've just seen badly implemented NOS DACs where its less important?), but in my case it would have to be beforehand?
Is there an expert out there who can promptly laugh at my antics and set me off in the right direction? Could lack of filtering be the problem? Or is the problem more likely to do with weak (but reasonable for TTL) I2S signals?
Cheers,
Phil
Okay.
I've finally rebuilt the clock circuit (using the correct component values) as per SAA7220 datasheet - and I'm using my newer TDA 1541A DAC (with the better regulation).
I'm still getting a lot of noise, but the IV opamp isn't getting hot.
So, a vague improvement.
Not sure if its due to the more proper clock output, or the better regulation and decoupling of the IV stage.
Anyway, I reckon that its now okay, but I just need a suitable 2nd or 3rd order Bessel filter after the IV stage.
Hopefully I'll then have a reasonable OS DAC.
Any suggestions for the Bessel filter? Or do I just need to make sure its all attenuated before 176kHz?
I'm tempted to reverse engineer the analogue filter of the CD610 for this. However, my DAC is a 1541, and my CD610 uses the 1543 - but I assume the main difference in output stage is in the IV converter.
I've finally rebuilt the clock circuit (using the correct component values) as per SAA7220 datasheet - and I'm using my newer TDA 1541A DAC (with the better regulation).
I'm still getting a lot of noise, but the IV opamp isn't getting hot.
So, a vague improvement.
Not sure if its due to the more proper clock output, or the better regulation and decoupling of the IV stage.
Anyway, I reckon that its now okay, but I just need a suitable 2nd or 3rd order Bessel filter after the IV stage.
Hopefully I'll then have a reasonable OS DAC.
Any suggestions for the Bessel filter? Or do I just need to make sure its all attenuated before 176kHz?
I'm tempted to reverse engineer the analogue filter of the CD610 for this. However, my DAC is a 1541, and my CD610 uses the 1543 - but I assume the main difference in output stage is in the IV converter.
A bessel would fit best to the 7220's analog output signal. Maybe you can calculate it yourself, i assume passive is better than active when a "slow" opamp is used. If i am not mistaken the original philips filters are not bessel, but they are active allright.
http://www-users.cs.york.ac.uk/~fisher/mkfilter/trad.html
http://www-users.cs.york.ac.uk/~fisher/mkfilter/trad.html
Don't forget that the 7220's output is about 1dB up[/i] at 44.1khz*. So you need to correct for that in your output stage design also. One good way would be to pick the roll-off cap for the I/V conversion such that you're down 1dB c.45Khz, and follow that with your Bessel-based design.
* this pole isn't mentioned in the SAA7220 datasheet at all, but appears in some Analog Devices App note - the one on interfacing to the AD1862 dac IIRC. If many designs leave the HF rise uncompensated it would partially explain the complaints ...!
* this pole isn't mentioned in the SAA7220 datasheet at all, but appears in some Analog Devices App note - the one on interfacing to the AD1862 dac IIRC. If many designs leave the HF rise uncompensated it would partially explain the complaints ...!
martin clark said:
That is what i ment
And its Ap. note 207 if i am not mistaken, oh yes here it is:
http://www.analog.com/UploadedFiles/Application_Notes/383160163AN207.pdf
Thanks for the replies. I could do with the moral support!
Before reading your replies, I went away and knocked up a passive third order filter, using Ray's design in the gargantuan cd 63 thread. Its corner frequency is about 33kHz. I had the parts to build one for my cd63 in the past, so it was a quick and easy way to have a vaguely appropriate filter for this.
(interestingly, it does affect the NOS sound slightly, I'll investigate those differences another day).
Thanks for your comments on the roll off cap. I've always had a 10pF roll off capacitor in the feedback loop of the IV converter opamp circuit anyway (and might be a bit big, but it was the closest I had). I found early on (with NOS) that faster opamps seemed to oscillate badly if you didn't have a roll off capacitor there.
Anyway, with the passive filter on the output, I am still getting this noise.
So, I think I've ruled that out now, and I am suspecting other potential problems.
My next concern is the I2S coming out of the transport (in I2S) is clocked differently to the SAA7220. I thought it would be a risk, but up until now, I can hear the music, as well as the noise, so I assumed it was clocking reasonably okay, and something else must have been causing the problem.
I can build a clock module and reclock everything to eliminate that (it is something I wanted to do anyway for NOS). I'll probably build something that can do 2Mhz for BCLK into the 7220, 11Mhz for the 7220, and 5Mhz for 1541, and reclock the DATA and WS.
So, that could be a problem.
Another point I wonder about is that my opamp IV gain might be a little high. The feedback resistor is 1.8k (as per TDA1541A datasheet), but all the other opamp IV converters I've seen have lower resistances, and thus lower voltage outputs. Maybe I am hearing some weird oscillation because I am asking the opamp to do too much? Its an LM6172, so I assume it can cope.
I'm sure there are further potential issues(like SCAB, SDAB, MUTE* and ATSB* need pulling up or down differently or something), but these two are probably the next two to look into.
Also, I can have my SAA7220 board still powered up, but out of the I2S stream, and the noise vanishes. I haven't had just its inputs connected up in this scenario. That way I could totallly rule out power rail pollution. I'd be surprised if it is polluting power rails. It has hefty capacitor decoupling, its own regulator, and its own inductor/PI filter on its power rails.
I have a test CD of single frequencies and stuff, and I'll get my scope out and have a look at some point.
The plot thickens. This better sound good when it works.
Cheers,
Phil
Before reading your replies, I went away and knocked up a passive third order filter, using Ray's design in the gargantuan cd 63 thread. Its corner frequency is about 33kHz. I had the parts to build one for my cd63 in the past, so it was a quick and easy way to have a vaguely appropriate filter for this.
(interestingly, it does affect the NOS sound slightly, I'll investigate those differences another day).
Thanks for your comments on the roll off cap. I've always had a 10pF roll off capacitor in the feedback loop of the IV converter opamp circuit anyway (and might be a bit big, but it was the closest I had). I found early on (with NOS) that faster opamps seemed to oscillate badly if you didn't have a roll off capacitor there.
Anyway, with the passive filter on the output, I am still getting this noise.
So, I think I've ruled that out now, and I am suspecting other potential problems.
My next concern is the I2S coming out of the transport (in I2S) is clocked differently to the SAA7220. I thought it would be a risk, but up until now, I can hear the music, as well as the noise, so I assumed it was clocking reasonably okay, and something else must have been causing the problem.
I can build a clock module and reclock everything to eliminate that (it is something I wanted to do anyway for NOS). I'll probably build something that can do 2Mhz for BCLK into the 7220, 11Mhz for the 7220, and 5Mhz for 1541, and reclock the DATA and WS.
So, that could be a problem.
Another point I wonder about is that my opamp IV gain might be a little high. The feedback resistor is 1.8k (as per TDA1541A datasheet), but all the other opamp IV converters I've seen have lower resistances, and thus lower voltage outputs. Maybe I am hearing some weird oscillation because I am asking the opamp to do too much? Its an LM6172, so I assume it can cope.
I'm sure there are further potential issues(like SCAB, SDAB, MUTE* and ATSB* need pulling up or down differently or something), but these two are probably the next two to look into.
Also, I can have my SAA7220 board still powered up, but out of the I2S stream, and the noise vanishes. I haven't had just its inputs connected up in this scenario. That way I could totallly rule out power rail pollution. I'd be surprised if it is polluting power rails. It has hefty capacitor decoupling, its own regulator, and its own inductor/PI filter on its power rails.
I have a test CD of single frequencies and stuff, and I'll get my scope out and have a look at some point.
The plot thickens. This better sound good when it works.
Cheers,
Phil
I've been scouring datasheets.
As before, when I checked all this the first time, SCAB, SDAB, ATSB*, MUTE* and even EFAB have internal pull ups/downs. So if disconnected, they should all be pulled in the right direction for default operation. I have pulled MUTE* and ATSB* up anyway, and I could with the other inputs, but they shouldn't be causing a problem the way they are.
So its unlikely to be that.
I've also confirmed the data into the 7220 is expected to be 2's compliment, which I assume is correct because the TDA1541A is configured for 2's compliment, and in NOS mode it sounds fine.
The 7220 outputs 2's compliment as well.
So, the data is probably correct, if clocked properly.
So, I think I can rule those problems out.
So, opamp gain could be too high, reclocking might be required, power rail pollution (a quick one to eliminate).
Can anyone think of anything else it could be?
I reckon its a clocking issue at the moment. Unfortunately, that'll take the most time to try to investigate (unless I can quickly use xsys to drive some flip flops to reclock/synchronise the I2S data from the transport).
Cheers,
Phil
As before, when I checked all this the first time, SCAB, SDAB, ATSB*, MUTE* and even EFAB have internal pull ups/downs. So if disconnected, they should all be pulled in the right direction for default operation. I have pulled MUTE* and ATSB* up anyway, and I could with the other inputs, but they shouldn't be causing a problem the way they are.
So its unlikely to be that.
I've also confirmed the data into the 7220 is expected to be 2's compliment, which I assume is correct because the TDA1541A is configured for 2's compliment, and in NOS mode it sounds fine.
The 7220 outputs 2's compliment as well.
So, the data is probably correct, if clocked properly.
So, I think I can rule those problems out.
So, opamp gain could be too high, reclocking might be required, power rail pollution (a quick one to eliminate).
Can anyone think of anything else it could be?
I reckon its a clocking issue at the moment. Unfortunately, that'll take the most time to try to investigate (unless I can quickly use xsys to drive some flip flops to reclock/synchronise the I2S data from the transport).
Cheers,
Phil
From the SAA7220 datasheet, page 5:
"Serial data formatted in two's compliment (DAAB: pin 3) is clocked in by its bit clock (CLAB: pin2) together with word select (WSAB: pin 1) and error flag (EFAB: pin4) as shown in fig 1."
Fair enough, then get this...
"After resynchronisation with the internal clocks the data is seperated into left and right channels...."
So, if its resynchronised with internal clocks (I assumed derived from the oscillator fed into XIN) then it can't matter that my transport runs off its own clock.
So, I'm not sure resyncing the clocks prior to input to the 7220 can help.
But something must be wrong!
Maybe I'm just experiencing teething problems caused by those 'common features' that people dislike about the SAA7220?
Its going to be something subtle, and my vaguely common sense isn't helping me narrow it down.
On a side note (and this is why I questioned it beforehand) all this argument in general about the DAC being the master clock and everything upstream being slave to this DAC clock. Is it, to some extent in this case, irrelevant if the SAA7220 reclocks its input? I'm sure there is merit that the DAC clock is the main one, and others are given a clean version of this to avoid jitter, but I don't know if it should be so they are in sync with each other necessarilly.
Maybe that should be a new thread.
I'm going now. I shall leave you in peace and mull over this for a while, and probably end up scoping around the circuit for peculiar noise.
"Serial data formatted in two's compliment (DAAB: pin 3) is clocked in by its bit clock (CLAB: pin2) together with word select (WSAB: pin 1) and error flag (EFAB: pin4) as shown in fig 1."
Fair enough, then get this...
"After resynchronisation with the internal clocks the data is seperated into left and right channels...."
So, if its resynchronised with internal clocks (I assumed derived from the oscillator fed into XIN) then it can't matter that my transport runs off its own clock.
So, I'm not sure resyncing the clocks prior to input to the 7220 can help.
But something must be wrong!
Maybe I'm just experiencing teething problems caused by those 'common features' that people dislike about the SAA7220?
Its going to be something subtle, and my vaguely common sense isn't helping me narrow it down.
On a side note (and this is why I questioned it beforehand) all this argument in general about the DAC being the master clock and everything upstream being slave to this DAC clock. Is it, to some extent in this case, irrelevant if the SAA7220 reclocks its input? I'm sure there is merit that the DAC clock is the main one, and others are given a clean version of this to avoid jitter, but I don't know if it should be so they are in sync with each other necessarilly.
Maybe that should be a new thread.
I'm going now. I shall leave you in peace and mull over this for a while, and probably end up scoping around the circuit for peculiar noise.
1K8 no problem, but a few tens of pF across it seems way too small. 2nF here puts you in the balpark for the filter to follow.
The big cap has a side-effect that's not obvious - it limits the opamp input 'seeing' voltage steps it can't deal with. This really helps in the NOS case, where the transients are the largest. Much more analysis on this over on diyhifi in an old thread called " 'opamps unsuitable for audio dac i/v?' - Myth?"
philpoole said:
Phil, do you still refer to the noise?
Once i fitted a new clock in the cd304mk2, i had some problems, and fitted the old cristal back to solve them, but i soldered it on the other side as it had to be: result a huge noise. Also i discovered a 7220 can "broadcast" around a lot of hf noise, a Gnd shield must allways be used with this chip. And a copper shield added on top doesn't hurt either.