esmith@goofy.apple.com (Eric Smith) (09/12/90)
In article <1770016@otter.hpl.hp.com> sgm@otter.hpl.hp.com (Steve Methley) writes: > > I'm looking for the specifications of the DIGITAL OUT signal on > > the Philips CD620. I guess it's some kind of standard. > > I've mailed the original poster, but I think it's general interest; - you can > get details from Philips Data Book 4 Part IC01, under part number SAA7220. > Here you can find voltage levels and recommended load etc...... >n > It is a standard produced by Philips and Sony and used in very many CD players, > although sometimes the data is inverted before transmission for no apparent > reason. The reason the data is sometimes inverted is that the digital audio interconnect standard specifically states that the polarity of the signal is undefined, and is allowed to change (even on one piece of equipment). Since the code is self-clocking (Biphase Mark), the polarity doesn't matter at all. In biphase mark encoding, there is a transition on the line between each pair of bit cells. There is an additional transition in the center of the bit cell for 1 bits. This is equivalent to frequency modulation. To receive the code, you use a PLL to recover the clock, and you can easily do away with the polarity problem by differentiating the data, something like this ____ Input Signal >---+------------------+--------------\ \ \ | | | |XOR|----- Output | | ------ +--/ /___/ | +---|D Q|--+ | ------- | | +--| PLL |--clock--+---|> | ------- | ------ | +-------------------------- Clock where the PLL recovers the half-bit cell clock, and the output will be a one for one clock cycle whenever the input transitions. Then you need to detect the three different sync patterns. I use a PAL as a shift register and comparator to do this. Data Input (on wire or optical) Output of circuit above __ __ 1 / \__/ or \__/ \ 11 _____ 0 / \ or \_____/ 10 ________ __ Sync / \________/ \__/ 10010011 or ________ __ \________/ \__/ \ ________ ________ Sync / \__/ \__/ 10011001 or __ __ \________/ \________/ \ ________ __ Sync / \__/ \________/ 10011100 or __ ________ \________/ \__/ \ Note that the sync patterns take 4 bit times (8 half-bits), and do not meet the normal biphase mark encoding rules. I don't remember the designations or meanings of the sync patterns offhand. There is one for the left channel sub-frame, one for the right channel sub-frame, and one that is used every 192 frames to indicate the beginning of a channel status block. Of course, the simplest way to deal with it is to use a receiver chip, such as the Yamaha DIR or DIR-2. These have the PLL and decode the bit stream, to give you a serial digital audio stream without the extra junk, and a subset of the channel status info. -- Eric L. Smith Opinions expressed herein do not necessarily reflect those esmith@apple.com of my employer, friends, family, computer, or even me! :-)
sgm@otter.hpl.hp.com (Steve Methley) (09/12/90)
esmith@goofy.apple.com (Eric Smith) writes in <ESMITH.90Sep11181129@goofy.apple.com>: > The reason the data is sometimes inverted is that the digital audio > interconnect standard specifically states that the polarity of the > signal is undefined, and is allowed to change (even on one piece of > equipment). Since the code is self-clocking (Biphase Mark), the > polarity doesn't matter at all. > In biphase mark encoding, there is a transition on the line between > each pair of bit cells. There is an additional transition in the > center of the bit cell for 1 bits. This is equivalent to frequency > modulation. A little confusion here, I think (correct me if I'm wrong): Data is composed of information bits and when a coding scheme eg Biphase Mark is applied _symbols_ are the result, which are transmitted along the line. In Biphase Mark, what doesn't matter is the polarity of the _symbols_. Data 1's are data 1's whether the _code_ is upside down or not. (If the polarity of the data truly didn't matter, then we couldn't transmit information at all). What sometimes happens is that the data is inverted before coding - so that the symbols with the transition in the center of the bit cell actually desribe zeros not ones. ie we transmit data(bar) not data. We have to know which this is before further processing; the code cannot help us. Some CD players, a minority, transmit data(bar), but don't make a point of saying so. This was really the point of my original posting. > To receive the code, you use a PLL to recover the clock It's surprising how often this simple approach is missed in commercial audio equipment. I could name two audio products which go to excessive lengths with non-linear elements for clock recovery, simply because they don't realise that Biphase Mark belongs to the set of comms codes which possess a discrete clock component for random data. A simple filter is all that's required. The other thing about Biphase Mark is that it has no dc component, another typical comms code property. Cheers, Steve. (my own opinions)
esmith@goofy.apple.com (Eric Smith) (09/13/90)
In article <1770018@otter.hpl.hp.com> sgm@otter.hpl.hp.com (Steve Methley) writes: > A little confusion here, I think (correct me if I'm wrong): Data is > of information bits and when a coding scheme eg Biphase Mark is applied > _symbols_ are the result, which are transmitted along the line. In > Biphase Mark, what doesn't matter is the polarity of the _symbols_. > Data 1's are data 1's whether the _code_ is upside down or not. > ... No confusion on this point. I was stating the same thing. > What sometimes happens is that the data is inverted before coding ... I hadn't heard of that. How disgusting! -- Eric L. Smith Opinions expressed herein do not necessarily reflect those esmith@apple.com of my employer, friends, family, computer, or even me! :-)
sgm@otter.hpl.hp.com (Steve Methley) (10/11/90)
There's been a lot of mention of Biphase Mark encoded signals in this string. Can anyone show me an elegant coder for this? Assume NRZ or RZ data and clock are available. ( I have an NRZ psuedorandom data source, but want psuedorandom Biphase Mark encoded signals) All comments appreciated. Cheers, Steve. (standard disclaimer here)