From your scope pictures:
(I gleaned the extra precision in these numbers by assuming standard values.)
LRCLK: 44.1KHz (1fs)
MCLK: 11.2896MHz (256fs)
BCLK: 5.6448MHz (128fs) <<<<!!!!!
Width of shortest apparent data bit: 177.2nS (Matches one BCLK cycle).
Calculated width of 24bit data packet: 4.252uS
(It looks like there's only 18 apparent bits).
**********
This Rio device is putting out a 64bit frame size!
32bits is the standard frame size.
The Rio's PCM1716 DAC can handle arbitrary frame size, so this isn't a problem.
Looking at the Crystal CS8405 data sheet (page 6):
Notes: 7. No more than 128 SCLK(your BCLK) per frame...
I think they mean two word frames (i.e. 64bit / channel), so you're right at the limit, but OK.
They have some more restrictions on the phase relationship between signals, that might be the problem.
Could you post DATA, LRCLK and BCLK scanned at the same time?
IF not, could you post three pairs?
Also,
are you probing at the CS8405 end of the connections (rather than where they originate)? It's important to see what the CS8405 is seeing.
Regards,
Brian.
(I gleaned the extra precision in these numbers by assuming standard values.)
LRCLK: 44.1KHz (1fs)
MCLK: 11.2896MHz (256fs)
BCLK: 5.6448MHz (128fs) <<<<!!!!!
Width of shortest apparent data bit: 177.2nS (Matches one BCLK cycle).
Calculated width of 24bit data packet: 4.252uS
(It looks like there's only 18 apparent bits).
**********
This Rio device is putting out a 64bit frame size!
32bits is the standard frame size.
The Rio's PCM1716 DAC can handle arbitrary frame size, so this isn't a problem.
Looking at the Crystal CS8405 data sheet (page 6):
Notes: 7. No more than 128 SCLK(your BCLK) per frame...
I think they mean two word frames (i.e. 64bit / channel), so you're right at the limit, but OK.
They have some more restrictions on the phase relationship between signals, that might be the problem.
Could you post DATA, LRCLK and BCLK scanned at the same time?
IF not, could you post three pairs?
Also,
are you probing at the CS8405 end of the connections (rather than where they originate)? It's important to see what the CS8405 is seeing.
Regards,
Brian.
I only have access to a dual trace scope. So I won't be able to show three signals together, but I can do pairs. I was getting the signal from the connector that feeds the Crystal board. I assume you are suggesting I instead get them right at the Crystal input pins (12,13,14,21).
I'll try to get the scope out again and post.
With regard to the pins, it looks like from the schematic that 18 and 25 of the CS8405 were left floating.
Thanks again everybody!
Stu
I'll try to get the scope out again and post.
With regard to the pins, it looks like from the schematic that 18 and 25 of the CS8405 were left floating.
Thanks again everybody!
Stu
If one accepts that the PCM1716 section works, the CS8405A is in hardware mode and configured as a slave and all unused input pins are tied off as needed then signal integrity and, to a lesser extent, the phase relationship between the generated masterclock and the I2S signal is all that is left. Given that you have already tried buffering, have considered tightening up the timing with flip-flops?
ray
ray
Brian Brown said:
Could you post DATA, LRCLK and BCLK scanned at the same time?
IF not, could you post three pairs?
Also,
are you probing at the CS8405 end of the connections (rather than where they originate)? It's important to see what the CS8405 is seeing.
Regards,
Brian.
Here are the pictures of each of the signal pairs excluding master clock. They were all taken from the input pins of the CS8405, post buffer.
I have not tried flip flops, but I guess I'll have to look into it.
Thanks again,
Stu
An externally hosted image should be here but it was not working when we last tested it.
An externally hosted image should be here but it was not working when we last tested it.
Hi Stu,
I'm afraid the sweep rate on this last set of scope plots is way too slow (1mS/div). Also put it back into Sample mode instead of Peak Detect.
To look at the data we'll need sweep rates in the same range that you used the first time. I'd suggest 2uS/div or 1uS/div to begin with.
I'm a little concerned that all of the data lines look about the same: a 1.2KHz square wave. This may just be due to aliasing from the slow sweep rate or from the peak detect mode, but it might also indicate a problem with your interface wiring. If you still see matching signals at the faster sweep rates, go scope the signal pairs back at the Rio board. If they still match, then there's a problem with the way you're probing them with the scope. If they're correct back at the Rio board, then re-examine your wiring.
Also I missed this the first time, but it probably would be better to set the scope's inputs to DC coupling instead of AC coupling. If you could get it to trigger on the falling edge of LRCLK, that would also help.
Let's give it another try.
Brian.
I'm afraid the sweep rate on this last set of scope plots is way too slow (1mS/div). Also put it back into Sample mode instead of Peak Detect.
To look at the data we'll need sweep rates in the same range that you used the first time. I'd suggest 2uS/div or 1uS/div to begin with.
I'm a little concerned that all of the data lines look about the same: a 1.2KHz square wave. This may just be due to aliasing from the slow sweep rate or from the peak detect mode, but it might also indicate a problem with your interface wiring. If you still see matching signals at the faster sweep rates, go scope the signal pairs back at the Rio board. If they still match, then there's a problem with the way you're probing them with the scope. If they're correct back at the Rio board, then re-examine your wiring.
Also I missed this the first time, but it probably would be better to set the scope's inputs to DC coupling instead of AC coupling. If you could get it to trigger on the falling edge of LRCLK, that would also help.
Let's give it another try.
Brian.
Aliasing
Hi Stu,
OK, these new pictures are an improvement, but we still need to tweak your scope settings. These are some good concepts to learn while you're still new with scopes.
The time base and scope mode are right now, and we can see the outlines of the packets of data. We're still not seeing all of the individual data bits, though.
In many respects, a digital scope is very similar to PCM digital audio, so what we're seeing might also help some people understand more about digital audio.
What's happening is called 'aliasing'.
Your digital scope takes individual data measurements at regular intervals. It misses anything that might happen with the signal between these measurements. When it displays these measurements, it 'connects the dots' with lines. (It probably has another mode where it just displays the dots without anything in between).
If the signal you are trying to measure changes faster than the scope takes readings (the scope's 'sampling rate'), then the lines connecting the dots in the display don't represent an accurate picture of the signal. That's what's happening here.
A guy named Nyquest came up with a theorem that showed that you need to use a sampling rate that is at least twice the frequency of the signal you are trying to capture. If you exceed Nyquest's limit, then the captured image won't look like the original signal (there weren't enough dots to connect).
(This is why they originally choose 44.1KHz sampling rate for CDs: It's a little over twice the traditionally accepted 20KHz upper range of human hearing.)
The length of the jagged edges of the signals in your display (these are the lines connecting the measurement dots) are about 2uS long. Converting to frequency, this shows that your scope is currently set to a 500KHz sampling rate. I know from your first picture of MCLK that your scope is capable of at least a 100MHz sampling rate, and probably more.
We already know that your MCLK is at 11.2896 MHz, so your scope should be set for a 50MHz sampling rate, or 20nS sample period.
Typically a scope has a certain amount of RAM to store measurements. You then have the option of making a compromise between the sampling rate and the overall length of the sample you are trying to capture. A higher sampling rate gives better resolution of high frequency signals, while a lower sampling rate lets you make a recording for a longer period of time.
Hopefully your scope has enough RAM to capture a full screen of data at 2uS/div at a 50MHz sampling rate. This would require:
50Msamples/second x two channels x 10divisions x 2uS/division = 2000samples. (I don't think this will be an issue).
I don't know the specifics of how to adjust the acquisition settings for your scope, so it might be different than I describe. Hopefully this will at least give you an idea of how to look for it.
Try looking under either the 'horizontal' menu, 'acquire' menu, or 'setup' menu. You should be able to find options like '1000 samples in 20divs'. We want 2000 (or more) samples in 10divs. There might also be a 'fit to screen' option. This would be good to use if it's available.
Hopefully, with a little more tweaking, we'll be able to see what's going on and get back to troubleshooting your problem.
Hang in there,
Brian.
Hi Stu,
OK, these new pictures are an improvement, but we still need to tweak your scope settings. These are some good concepts to learn while you're still new with scopes.
The time base and scope mode are right now, and we can see the outlines of the packets of data. We're still not seeing all of the individual data bits, though.
In many respects, a digital scope is very similar to PCM digital audio, so what we're seeing might also help some people understand more about digital audio.
What's happening is called 'aliasing'.
Your digital scope takes individual data measurements at regular intervals. It misses anything that might happen with the signal between these measurements. When it displays these measurements, it 'connects the dots' with lines. (It probably has another mode where it just displays the dots without anything in between).
If the signal you are trying to measure changes faster than the scope takes readings (the scope's 'sampling rate'), then the lines connecting the dots in the display don't represent an accurate picture of the signal. That's what's happening here.
A guy named Nyquest came up with a theorem that showed that you need to use a sampling rate that is at least twice the frequency of the signal you are trying to capture. If you exceed Nyquest's limit, then the captured image won't look like the original signal (there weren't enough dots to connect).
(This is why they originally choose 44.1KHz sampling rate for CDs: It's a little over twice the traditionally accepted 20KHz upper range of human hearing.)
The length of the jagged edges of the signals in your display (these are the lines connecting the measurement dots) are about 2uS long. Converting to frequency, this shows that your scope is currently set to a 500KHz sampling rate. I know from your first picture of MCLK that your scope is capable of at least a 100MHz sampling rate, and probably more.
We already know that your MCLK is at 11.2896 MHz, so your scope should be set for a 50MHz sampling rate, or 20nS sample period.
Typically a scope has a certain amount of RAM to store measurements. You then have the option of making a compromise between the sampling rate and the overall length of the sample you are trying to capture. A higher sampling rate gives better resolution of high frequency signals, while a lower sampling rate lets you make a recording for a longer period of time.
Hopefully your scope has enough RAM to capture a full screen of data at 2uS/div at a 50MHz sampling rate. This would require:
50Msamples/second x two channels x 10divisions x 2uS/division = 2000samples. (I don't think this will be an issue).
I don't know the specifics of how to adjust the acquisition settings for your scope, so it might be different than I describe. Hopefully this will at least give you an idea of how to look for it.
Try looking under either the 'horizontal' menu, 'acquire' menu, or 'setup' menu. You should be able to find options like '1000 samples in 20divs'. We want 2000 (or more) samples in 10divs. There might also be a 'fit to screen' option. This would be good to use if it's available.
Hopefully, with a little more tweaking, we'll be able to see what's going on and get back to troubleshooting your problem.
Hang in there,
Brian.
The scope is a fairly old (Tektronix 2230 circa 1984) 100 mHz model and I'm not sure that it has sufficient sampling capabilities to reach the Nyquest frequency with anything usable. Faster rates than previously posted yield a series of useless dots with no discernable waveform. The master clock I posted was done in analog mode, but I have not been able to get a dual trace setup to yield anything useful in analog. The biggest problem faced with the scope is getting a waveform that can be recognized as such. Slower rates at least achieved that much.
The only thing halfway useable was obtained with LRCK and BCLK, but there was no apparent way to connect the few samples so I don't know how usable it is. See below.
Very frustrating,
Stu
The only thing halfway useable was obtained with LRCK and BCLK, but there was no apparent way to connect the few samples so I don't know how usable it is. See below.
Very frustrating,
Stu
maczrool said:
Bummer.
You've done a good job trying on this. Nice screen photos too...
Reminds me of when I used to try to get a Polaroid to trigger on an event (no storage scope). Lots of wasted film.
I guess we won't be able to use this scope to check for timing issues. It still might be useful to get some single trace shots like your first set, only taken at the CS8405 side. This will at least help give a clue about signal quality.
Brian.
I took another crack at comparing the various signals to each other, but I really wasn't able to get a distinct waveform of both signals simultaneously. I did compare the signals at the input pins and at the signal source. Except for amplitude, they are identical, with the signals post buffer being hotter. That being the case, the original scope photos should suffice for analysis of signal quality. I have attached the photos depicting my most recent attempt at signal comparison in case there was something of value in them.
Given that at least one of the channels works, but with clipping, I was wondering if the problem might stem from the fact that the I2S signals are 24-bit? Would a CS8420 help?
Anyone care to guess what the song in that clip in the first post of this thread is?
Happy holidays,
Stu
Given that at least one of the channels works, but with clipping, I was wondering if the problem might stem from the fact that the I2S signals are 24-bit? Would a CS8420 help?
Anyone care to guess what the song in that clip in the first post of this thread is?
Happy holidays,
Stu
Your latest plots help confirm that the Rio device is only producing 18bits of actual data.
Since your waveforms look about the same on both boards, I think we can focus away from general signal quality and wiring issues. I don't want to rule it out 100%, but I don't think that's your issue.
There's still a chance that there could be a set-up and hold timing issue (that we're unable to check with your scope). But I really doubt that's the issue either. I2S is usually fairly liberal with its timing allowance: data is written on the falling edge of the clock and read on the rising edge. I would only expect to run into a timing issue if there was also a problem with the signal quality.
That leads me back to to 64bit channel frame size that the Rio is producing. I think it's your problem. 32bit is the typical frame size for I2S. The CS8405 is supposed to be able to handle a 64bit frame, but that's right at its limit.
I can't think of anything else that's a likely cause of your problem.
There's only two ways I can think of to fix this, and unfortunately they both involve a change to your circuit design.
The first approach would be to put some additional logic between the Rio and the CS8405. It would involve clocking the data into a FIFO buffer with the Rio's clock, then clocking it out of the buffer with the clock divided by two. The buffer should be reset at every transition of LRCLK. This approach would present a 32bit frame to the CS8405. Presuming I'm correct about the frame size being the cause of the problem, this should fix it.
This approach could be done either with discrete logic or a PLD. The PLD would be easier to wire in, but you'd need access to a programmer to get the design into the part. If you'd like to persue either implementation of this approach, I could give you more details or a PLD programming file.
The second approach would be to use something else besides the CS8405. The CS8420 you mentioned would be one possibility. I didn't see any restrictions specifically spelled out regarding frame size, so it might be successful at interfacing to the Rio. (I haven't fully studied all of the timing, so there's a chance that there's still a catch hidden in there).
Even though this would mean constructing an entirely new circuit, it might be worth the effort - even if it still had an issue with the Rio. Personally I'm a big fan of ASRCs. I feel they offer a big improvement in sound quality. So even if it didn't work with the Rio, it might be useful to you for other applications.
That's all I can think of at this point.
Brian.
Since your waveforms look about the same on both boards, I think we can focus away from general signal quality and wiring issues. I don't want to rule it out 100%, but I don't think that's your issue.
There's still a chance that there could be a set-up and hold timing issue (that we're unable to check with your scope). But I really doubt that's the issue either. I2S is usually fairly liberal with its timing allowance: data is written on the falling edge of the clock and read on the rising edge. I would only expect to run into a timing issue if there was also a problem with the signal quality.
That leads me back to to 64bit channel frame size that the Rio is producing. I think it's your problem. 32bit is the typical frame size for I2S. The CS8405 is supposed to be able to handle a 64bit frame, but that's right at its limit.
I can't think of anything else that's a likely cause of your problem.
There's only two ways I can think of to fix this, and unfortunately they both involve a change to your circuit design.
The first approach would be to put some additional logic between the Rio and the CS8405. It would involve clocking the data into a FIFO buffer with the Rio's clock, then clocking it out of the buffer with the clock divided by two. The buffer should be reset at every transition of LRCLK. This approach would present a 32bit frame to the CS8405. Presuming I'm correct about the frame size being the cause of the problem, this should fix it.
This approach could be done either with discrete logic or a PLD. The PLD would be easier to wire in, but you'd need access to a programmer to get the design into the part. If you'd like to persue either implementation of this approach, I could give you more details or a PLD programming file.
The second approach would be to use something else besides the CS8405. The CS8420 you mentioned would be one possibility. I didn't see any restrictions specifically spelled out regarding frame size, so it might be successful at interfacing to the Rio. (I haven't fully studied all of the timing, so there's a chance that there's still a catch hidden in there).
Even though this would mean constructing an entirely new circuit, it might be worth the effort - even if it still had an issue with the Rio. Personally I'm a big fan of ASRCs. I feel they offer a big improvement in sound quality. So even if it didn't work with the Rio, it might be useful to you for other applications.
That's all I can think of at this point.
Brian.
I think those were the fastest sweep rates that would yield a useable picture, but I'll try again.
Still need to post a block diagram of what I'm doing too. I had one made and then the computer crashed.
At any rate, I think the CS8420 is the way to go. It has the same foot print as the CS8405 and some of the same pins. I may be able to hack one up from my current circuit boards. I have a couple AD1896s around, but they don't have a S/PDIF transmitter in them, and I want to minimize rework at this point.
Thanks everybody!
Stu
Still need to post a block diagram of what I'm doing too. I had one made and then the computer crashed.
At any rate, I think the CS8420 is the way to go. It has the same foot print as the CS8405 and some of the same pins. I may be able to hack one up from my current circuit boards. I have a couple AD1896s around, but they don't have a S/PDIF transmitter in them, and I want to minimize rework at this point.
Thanks everybody!
Stu
UPDATE:
I tried the CS8420. Same thing
! I get terrible noise in the right channel and noise at higher digital levels in the left. I tried the onboard clock of the MP3 player as well as a separate oscillator, with identical results. If only I had a scope to analyze the timing...
Anyone have anymore ideas why it doesn't work in this device and does in others? The I2S source is a Cirrus EP-7212, connected to the CS8420 through buffers and 6 inches of ribbon cable.
Thanks,
Stu
I tried the CS8420. Same thing
! I get terrible noise in the right channel and noise at higher digital levels in the left. I tried the onboard clock of the MP3 player as well as a separate oscillator, with identical results. If only I had a scope to analyze the timing...Anyone have anymore ideas why it doesn't work in this device and does in others? The I2S source is a Cirrus EP-7212, connected to the CS8420 through buffers and 6 inches of ribbon cable.
Thanks,
Stu
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.