BCLK/DATA/LRCK are the PCM signals that are part of I2S bus. Then there are the I2S bus formats/protocols, such as RJ, LJ, I2S (the protocol, not the bus).
https://www.nxp.com/docs/en/user-manual/UM11732.pdf
https://infocenter.nordicsemi.com/index.jsp?topic=/ps_nrf9160/i2s.html
https://www.nxp.com/docs/en/user-manual/UM11732.pdf
https://infocenter.nordicsemi.com/index.jsp?topic=/ps_nrf9160/i2s.html
Last edited:
Hmmm... looks like I could only get 16.9344 by multiplying the following frequencies available in the CDP:
8,64MHz (x1.96)
2,16MHz (x7.84)
88.2KHz (x192)
I assume multiplying 88.2KHz 192 times to get 16.9344MHz (or 128 times to get 11.2896MHz) is the simplest, but I have no idea
how to achieve this...
8,64MHz (x1.96)
2,16MHz (x7.84)
88.2KHz (x192)
I assume multiplying 88.2KHz 192 times to get 16.9344MHz (or 128 times to get 11.2896MHz) is the simplest, but I have no idea
how to achieve this...
... which means I need to know the frequency of the "Bitclock" and "L/R Clock", the signals a transmitter like the DIT4192 needs besides Data?
Fun fact: In order not to open my working CDP-101, I use a broken / spare CDP-101 with the common problem of burned STK6922 that I removed.
These amplifiers drive the laser and tray and are known to fail. To my knowledge, for measuring the L/R clock and bitclock, no CD needs to be inserted and running.
Even though it is Saturday the 14th, it could be Friday the 13th. My oscilloscope blew two hours ago, luckily after checking the clock signals.
While measuring the bitclock with a frequency counter that lags a lot, the +5V supply of the CDP - 101 died!
So I hope this makes sense.
L/R Clock - 44.1 KHz indeed.
Bitclock: 2.1605 MHz ( a second later, the internal 5V supply of the CDP-101 died)
BUT: There is a German tutorial that was issued to German service personnel when the CDP-101 was released:
https://www.bramjacobse.nl/wordpress/wp-content/uploads/2023/10/Sony-CDP101-Schulungsunterlagen.pdf
I fact it states 2.16MHz as the bitclock, 44.1KHz as L/R clock. Data is MSB first.
2.16MHz divided through 44.1kHz equals a rounded 48.98 (Fs?)
If further measurements need to be made, we'll need to wait a bit...
Fun fact: In order not to open my working CDP-101, I use a broken / spare CDP-101 with the common problem of burned STK6922 that I removed.
These amplifiers drive the laser and tray and are known to fail. To my knowledge, for measuring the L/R clock and bitclock, no CD needs to be inserted and running.
Even though it is Saturday the 14th, it could be Friday the 13th. My oscilloscope blew two hours ago, luckily after checking the clock signals.
While measuring the bitclock with a frequency counter that lags a lot, the +5V supply of the CDP - 101 died!
So I hope this makes sense.
L/R Clock - 44.1 KHz indeed.
Bitclock: 2.1605 MHz ( a second later, the internal 5V supply of the CDP-101 died)
BUT: There is a German tutorial that was issued to German service personnel when the CDP-101 was released:
https://www.bramjacobse.nl/wordpress/wp-content/uploads/2023/10/Sony-CDP101-Schulungsunterlagen.pdf
I fact it states 2.16MHz as the bitclock, 44.1KHz as L/R clock. Data is MSB first.
2.16MHz divided through 44.1kHz equals a rounded 48.98 (Fs?)
If further measurements need to be made, we'll need to wait a bit...
Last edited:
That looks like a problem. Usually the way it works is that clocks are related to each other by factors of powers of 2. For example, at 44.1kHz (the frame rate, Fs), if we need to send 16-bits of data per channel, and we have two channels, then the bit clock would have to be 16 x 2 x 44,1000 = 1,411,200Hz (1.4412MHz). That would amount to 32Fs, or 32 times the frame sample rate.
OTOH, 2.1605 MHz is not so clear where the data is. The clock rate is high enough so that 16 x 2 bits of data could be sent, but how they fit in with the bit clock is not clear. If its MSB left justified, then is the first 16-bits, starting from an Fs clock edge, the data for each channel? Or else how is the data fit in there? Maybe it is the first 16-bits, and all the following bits are zeros? if that were the case, would a SPDIF transmitter know to discard the trailing zeros and send a normal embedded clock frequency for 16/44 that a normal SPDIF receiver would understand? Probably not, would be my guess.
If you knew the internal CD player I2S protocol for sure, then you might be able to program a CPLD or something to help make the format conversion.
OTOH, 2.1605 MHz is not so clear where the data is. The clock rate is high enough so that 16 x 2 bits of data could be sent, but how they fit in with the bit clock is not clear. If its MSB left justified, then is the first 16-bits, starting from an Fs clock edge, the data for each channel? Or else how is the data fit in there? Maybe it is the first 16-bits, and all the following bits are zeros? if that were the case, would a SPDIF transmitter know to discard the trailing zeros and send a normal embedded clock frequency for 16/44 that a normal SPDIF receiver would understand? Probably not, would be my guess.
If you knew the internal CD player I2S protocol for sure, then you might be able to program a CPLD or something to help make the format conversion.
Hello Folks,
please excuse my (potentially incompetent) "Interrupt"....
The discussion reminded me of an add-in board available at Audiophonics in France which may be worth evaluating for the case: Digital Interface I2S to SPDIF with WM8805
Maybe worth a try? Or why not? If my proposal makes no sense, please just "Return from Interrupt"
Thanks for your patience,
Regards,
Winfried
please excuse my (potentially incompetent) "Interrupt"....
The discussion reminded me of an add-in board available at Audiophonics in France which may be worth evaluating for the case: Digital Interface I2S to SPDIF with WM8805
Maybe worth a try? Or why not? If my proposal makes no sense, please just "Return from Interrupt"
Thanks for your patience,
Regards,
Winfried
I think the I2S of the Sony CDP-101 is not the same as today's I2S, but I might be wrong. Looking at the Audiophonic board's description, MCK of the I2S needs 11.2896Mhz. This very likely would need to run in sync with the CDP-101, what this thread is about.
Maybe this 1983 document sheds some light? Translated from the German CDP-101 tutorial for Sony engineers, see link in post #29, page 87:
"The data offered to the CX-20017 (NOS DA-Converter from Sony) is a serial digital signaI in two's complement form. The data is synchronised with the rising edge of the bit clock (BLCK), starting at the MSB. The data change occurs at the falling edge of the BCLK! At the 24th falling edge of the BCLK, the word clock (WLCK) goes from high to low and the 16-bit data is transferred from the shift register to the signal memory (latch) (internal process)."
Maybe this 1983 document sheds some light? Translated from the German CDP-101 tutorial for Sony engineers, see link in post #29, page 87:
"The data offered to the CX-20017 (NOS DA-Converter from Sony) is a serial digital signaI in two's complement form. The data is synchronised with the rising edge of the bit clock (BLCK), starting at the MSB. The data change occurs at the falling edge of the BCLK! At the 24th falling edge of the BCLK, the word clock (WLCK) goes from high to low and the 16-bit data is transferred from the shift register to the signal memory (latch) (internal process)."
Last edited:
BCLK is very strange looking. Seems to invert phase every few cycles.
I suppose someone could to some extent probe how this thing works by burning a test CD with some test signals, then observing the behavior of the data relative to BCLK.
Regarding the German tutorial, I think it would be reasonable for the OP to use Google Translate or other translation to make an English version of the section which describes the I2S bus format and post it as a document here. No reason all the readers of this thread to each do the translation for themselves.
I suppose someone could to some extent probe how this thing works by burning a test CD with some test signals, then observing the behavior of the data relative to BCLK.
Regarding the German tutorial, I think it would be reasonable for the OP to use Google Translate or other translation to make an English version of the section which describes the I2S bus format and post it as a document here. No reason all the readers of this thread to each do the translation for themselves.
Which I did already in post #32 above the image, using the better www.deepl.com
No more information in this section. Also translation would be a hassle because the text is scanned and not a TrueType font or vectorized
like in modern PDF.
Could it be that it follows the Wordclock of 88.2khz?
Maybe there was an English version of the tutorial (though the German division of Sony wrote it) maybe someone has it on his attic...
Looks like they didn't call it I2S back then.
Good old YEDS-18 at hand. But what would be the benefit? Shouldn't the bitclock look the same, no matter the signal fed...?
Last edited:
BCLK inversion pattern is new to me. Maybe someone else knows about it. Otherwise a test which dac designers sometimes use is send a fixed DC signal to dac to look at its noise as a function of DC level.
In this case it might helpful to be able to create similar test signals but for a different purpose. Fixed DC signal level wav files in both the + and - directions, and at a few signal levels could show how the encoding on the dac internal I2S bus works. It could show where the MSB is, and whether data gets stretched out in time when BCLK inverts, or whatever.
The trick to doing would be to look at the format of wav files, and from that create some suitable test files. Then burn the files to a CD. Watch with a scope to see what happens. Maybe a lot of work, but not sure how else to find out exactly what we're dealing with.
As an alternative to that, maybe finding a complete version of the dac chip datasheet would give the answers. Don't know.
Also, if someone reading along is already familiar with the BCLK scheme, then maybe they could clarify how it works.
EDIT: The thing about it that may be troublesome is that rising and falling edges of BCLK are not uniformly timed. A SPDIF receiver tries to extract a clock signal from the SPDIF stream. That BCLK pattern and presumably stretched out data bits might look like EXTREME jitter to a receiver device. Seems likely the internal I2S would need to be processed digitally to remove that issue. Could need an ASRC after that. Then into a SPDIF transmitter.
Anyway, before programing a CPLD or something like that to change to timing format, it might help a lot to double check and be really sure about how the I2S bus works. If not done at the start, maybe there should at least be a backup plan to do it in case assumptions about reformatting end up with with a conversion circuit that is problematic. How to troubleshoot if there is no way to send useful test signals?
In this case it might helpful to be able to create similar test signals but for a different purpose. Fixed DC signal level wav files in both the + and - directions, and at a few signal levels could show how the encoding on the dac internal I2S bus works. It could show where the MSB is, and whether data gets stretched out in time when BCLK inverts, or whatever.
The trick to doing would be to look at the format of wav files, and from that create some suitable test files. Then burn the files to a CD. Watch with a scope to see what happens. Maybe a lot of work, but not sure how else to find out exactly what we're dealing with.
As an alternative to that, maybe finding a complete version of the dac chip datasheet would give the answers. Don't know.
Also, if someone reading along is already familiar with the BCLK scheme, then maybe they could clarify how it works.
EDIT: The thing about it that may be troublesome is that rising and falling edges of BCLK are not uniformly timed. A SPDIF receiver tries to extract a clock signal from the SPDIF stream. That BCLK pattern and presumably stretched out data bits might look like EXTREME jitter to a receiver device. Seems likely the internal I2S would need to be processed digitally to remove that issue. Could need an ASRC after that. Then into a SPDIF transmitter.
Anyway, before programing a CPLD or something like that to change to timing format, it might help a lot to double check and be really sure about how the I2S bus works. If not done at the start, maybe there should at least be a backup plan to do it in case assumptions about reformatting end up with with a conversion circuit that is problematic. How to troubleshoot if there is no way to send useful test signals?
Last edited:
Do you mean new related to an early Sony CD-Player from the time range 1982 to 1986 or new in general?
Could it also be that the inversion / irregular bitclock pattern is an error of the authors?
Because in the CDP-101 service manual the bitclock @ DA05 is shown as a regular signal.
I also remember that I did see it that way as well on my scope but need to verify.
Unfortunately no time for this today.
BTW when LRCK is low, the right channel is transferred.
I would take that 49Fs figure as read. It is not unique to the CDP-101 and it isn't the problem it appears to be. The DIT4192 can deal with it. The problem is the 196Fs master clock which leaves you with two options for for getting the DIT and the CX7934 into the same clock domain assuming, that is, you don't want to use an ASRC. Use a VCXO with the CX7934 providing the reference or divide down from a common frequency.
As far as I understand the datasheets, the SPDIF transmitters DIT4192 / DIT4096 / CS8406 only allow 128fs / 256fs/ 384fs / 512 fs. This is why I originally hoped to find a 4.2336MHz base frequency in the CDP-101 as those FS work with muliples of it. As far as I know, no SPDIF transmitter device offered operates with 196fs. But is my assumption correct that I could still use those transmitters with i.e. 256fs running on a 11.2896Mhz clock, that is referenced by the wordlock of 88.2KHz (1/128) inside the CDP-101?
Last edited: