So, S/PDIF sucks bad. RCA-terminated coax sucks really, really bad. I decided to use something better for my digital interconnect.
I started with El Cheapo, my JVC DVD/CD transport. Under the cover, there is an integrated stereo DAC with a 3-wire serial input. The data format is I2S. To move the I2S out of the box, I decided to use a quad LVDS transmitter (National DS90C031 in a SO-16) on the transport side and a quad LVDS reciever (National DS90C032 in the same package) on the DAC side. These parts are really small, but that's part of their advantage, and it could be worse: the 3.3V parts come in TSSOP. You can get them from Digi-Key which is a triple bonus in my book.
For the physical interface, I got some 3M surface-mount mini-d ribbon (MDR) connectors (part 10226-1210VE). Allied stocks these. This is a nice cable tech: 13 shielded twinax pairs in one cable, and the cables are widely available from computer stores. You could also use the more widely available 20-pin MDR connector, but Allied only stocks the through-hole version of that part. If you need to make your own cables, you could use twinax or twisted pair for runs up to a few meters.
After I got these parts and some tiny PCBs made up, everything else was cake. The LVDS parts need decoupling, and I went with the triple decoupling scheme described in National's data sheet. The LVDS tx/rx chips look pretty dinky next to a 1206 cap
Also the reciever required a quartet of 100Ω terminators.
So far, no listening. The digital signal emerges at the other end of the receiver, which is good, but I need to modify the DAC to use the serial input instead of the AES receiver. But I'm pretty geeked about this interconnect, and I believe it will work better. It almost could not be worse than S/PDIF over coax.
There is a lot of room for variation here. SCSI VHDCI or HD80 connectors are suitable and widely available, albiet with 36 unused cable pairs. I would have used SCSI connectors if I had some laying about. Certainly you could also just use a group of twinax, or STP ethernet cable, or DVI.
Have fun, and to hell with S/PDIF.
I started with El Cheapo, my JVC DVD/CD transport. Under the cover, there is an integrated stereo DAC with a 3-wire serial input. The data format is I2S. To move the I2S out of the box, I decided to use a quad LVDS transmitter (National DS90C031 in a SO-16) on the transport side and a quad LVDS reciever (National DS90C032 in the same package) on the DAC side. These parts are really small, but that's part of their advantage, and it could be worse: the 3.3V parts come in TSSOP. You can get them from Digi-Key which is a triple bonus in my book.
For the physical interface, I got some 3M surface-mount mini-d ribbon (MDR) connectors (part 10226-1210VE). Allied stocks these. This is a nice cable tech: 13 shielded twinax pairs in one cable, and the cables are widely available from computer stores. You could also use the more widely available 20-pin MDR connector, but Allied only stocks the through-hole version of that part. If you need to make your own cables, you could use twinax or twisted pair for runs up to a few meters.
After I got these parts and some tiny PCBs made up, everything else was cake. The LVDS parts need decoupling, and I went with the triple decoupling scheme described in National's data sheet. The LVDS tx/rx chips look pretty dinky next to a 1206 cap
Also the reciever required a quartet of 100Ω terminators.So far, no listening. The digital signal emerges at the other end of the receiver, which is good, but I need to modify the DAC to use the serial input instead of the AES receiver. But I'm pretty geeked about this interconnect, and I believe it will work better. It almost could not be worse than S/PDIF over coax.
There is a lot of room for variation here. SCSI VHDCI or HD80 connectors are suitable and widely available, albiet with 36 unused cable pairs. I would have used SCSI connectors if I had some laying about. Certainly you could also just use a group of twinax, or STP ethernet cable, or DVI.
Have fun, and to hell with S/PDIF.
Not as complicated as it looks Just 'extra' components : input transformers, impedance matching resistors, pullup resistors, and so on. IMHO, the same goes for LVDS. If impedance matching is achieved (even with your ribbon cable - typically around 100R), you will have IMHO much better results than with no matching. Transformers are nice here, but you can try without... It's up to you. Whatever the technology behind, you must take care of the propagation between transmitters and receivers, and try to avoid any reflections caused by improper matching. Jocko ?
Just 'extra' components : input transformers, impedance matching resistors, pullup resistors, and so on. IMHO, the same goes for LVDS. If impedance matching is achieved (even with your ribbon cable - typically around 100R), you will have IMHO much better results than with no matching. Transformers are nice here, but you can try without... It's up to you. Whatever the technology behind, you must take care of the propagation between transmitters and receivers, and try to avoid any reflections caused by improper matching. Jocko ?
With LVDS, you don't need the pullup resistors. That is a PECL-specific thing. Of course you terminate your cable with a 100Ω resistor. In fact LVDS doesn't work *at all* without the resistor at the end. But still, it is extremely simple: on tx->cable->resistor->rx. Pulse transformers not needed.
Hi,
I'm new to this forum, and this seemed to be a good place to jump in since it's a subject near and dear to me.
I was planning on using the same approach with LVDS transmitters and receivers, although I haven't actually done it yet.
My thoughts had been to use a CAT5 flat cable (four twisted pairs) with an eight pin modular connector. It's reasonably cheap, easy to put together, and can easily be fitted on the transmitter circuit board in a small space with a square hole to plug in the cable on the back panel of most players.
One concern that I've had with this approach is how much jitter exists in the player to begin with. You don't want to simply transmit and capture the timing of a clock that's jittery to begin with.
My plan with the CAT5 cable is to use a precision oscillator *at the receiving end*, transmit it over an LVDS pair to the disk player to replace the player's original clock source, and then have it reflected back by a transmitter back to the receiver along with the data. The data would be latched into a buffer using the reflected clock, and read out of the buffer with the clock directly from the oscillator. This way both units are fully synchronous with each other, but with the clock source closest to where the data timing is most critical.
Anyway, that was my plan on how to approach this. It'll be at least a couple of months before I can actually turn boards to give it a try. I'd be interested to hear other peoples' thoughts and experiences regarding this topic.
Regards,
Brian.
P.S.
I think there's a lot to be said for using an ASRC on the receiving end. IMHO these really do a great job, even if S/PDIF is used.
I'm new to this forum, and this seemed to be a good place to jump in since it's a subject near and dear to me.
I was planning on using the same approach with LVDS transmitters and receivers, although I haven't actually done it yet.
My thoughts had been to use a CAT5 flat cable (four twisted pairs) with an eight pin modular connector. It's reasonably cheap, easy to put together, and can easily be fitted on the transmitter circuit board in a small space with a square hole to plug in the cable on the back panel of most players.
One concern that I've had with this approach is how much jitter exists in the player to begin with. You don't want to simply transmit and capture the timing of a clock that's jittery to begin with.
My plan with the CAT5 cable is to use a precision oscillator *at the receiving end*, transmit it over an LVDS pair to the disk player to replace the player's original clock source, and then have it reflected back by a transmitter back to the receiver along with the data. The data would be latched into a buffer using the reflected clock, and read out of the buffer with the clock directly from the oscillator. This way both units are fully synchronous with each other, but with the clock source closest to where the data timing is most critical.
Anyway, that was my plan on how to approach this. It'll be at least a couple of months before I can actually turn boards to give it a try. I'd be interested to hear other peoples' thoughts and experiences regarding this topic.
Regards,
Brian.
P.S.
I think there's a lot to be said for using an ASRC on the receiving end. IMHO these really do a great job, even if S/PDIF is used.
"standard" for DIY digital interconnect?
Lookin good... I was going to use LVDS with a different connector for exactly this same purpose, but jwb, I think you've chosen a better one... Should we create our own little "standard" for high grade DIY digital interconnect?
Then we could exchange digital module designs, PCB layouts etc based on this scheme...
If there's enough interest, we should add this to the wiki. I'd be happy to collect the info and do the first draft write-up.
Lookin good... I was going to use LVDS with a different connector for exactly this same purpose, but jwb, I think you've chosen a better one... Should we create our own little "standard" for high grade DIY digital interconnect?Then we could exchange digital module designs, PCB layouts etc based on this scheme...
If there's enough interest, we should add this to the wiki. I'd be happy to collect the info and do the first draft write-up.
Should we create our own little "standard" for high grade DIY digital interconnect?
There is already a standard, SPDIF.
This interface can be made to sound excellent if you know what the hell you are doing.
The issues of impedence matching, pulse transformers, cable length, connector reflections, common mode noise rejection, optimum rise times, and hysterisis in receivers will not dissappear by jumping to LVDS. 
You think impedance matching for coax is hard, wait till you match twisted pair which has a differential AND common mode characteristic impedance.
I think you guys had better understand the limitations and strengths of SPDIF before you throw even more complicated "solutions" at the problem.
Like Mark Twain said:
"Everyone complains about the weather but nobody does anything about it."
Sorry to rain on your parade.
Art
There is already a standard, SPDIF.
This interface can be made to sound excellent if you know what the hell you are doing. The issues of impedence matching, pulse transformers, cable length, connector reflections, common mode noise rejection, optimum rise times, and hysterisis in receivers will not dissappear by jumping to LVDS. You think impedance matching for coax is hard, wait till you match twisted pair which has a differential AND common mode characteristic impedance.I think you guys had better understand the limitations and strengths of SPDIF before you throw even more complicated "solutions" at the problem.Like Mark Twain said:
"Everyone complains about the weather but nobody does anything about it."
Sorry to rain on your parade.
Art
artnyos:
I agree with you that S/PDIF can be made to work well, especially if it is reclocked on the receiving end.
Yes, proper design guidelines must be followed for LVDS, but I don't consider these insurmountable.
(For those interested,
LVDS Design Guide
is an excellent source of information.)
My main motivation for an alternate interface is for a multichannel audio: direct digital from a DVD-A, DTS, or SACD source. S/PDIF doesn't support this without resorting to some form of compression.
1394 or USB could be used as an interface, but the overhead for these is much more painful than a proper interface that transfers discrete signals in real-time, rather than in packets.
As far as options for getting audio clock and data signals from one box to another, I've considered 422, PECL, LVDS, and even plain single-ended TTL (for a very short distance).
My conclusion was the same as jwb, that LVDS offered the best combination of performance and ease of implementation.
I like hifiZen's idea of trying to come up with a standard for this.
There could be some degree of flexibility for variations in the clocking and data formats.
I'll have to think a bit more about MDR vs RJ-45 modular connectors. MDRs are a more expensive solution, but they do offer more pairs. In order to limit the number of pairs needed for multichannel, I was considering an EPLD to switch between different data sources in the disk player (2 channel IIS, 6 channel IIS, 2 channel DSD, 6 channel DSD) and then pack the selected source together in a TDM type stream. The use of an MDR connector would possibly allow the data lines to remain separated, but this would also require at least one additional quad LVDS transmitter/receiver pair (almost the same cost as the EPLDs).
Anyway, I'd appreciate feedback.
Brian.
I agree with you that S/PDIF can be made to work well, especially if it is reclocked on the receiving end.
Yes, proper design guidelines must be followed for LVDS, but I don't consider these insurmountable.
(For those interested,
LVDS Design Guide
is an excellent source of information.)
My main motivation for an alternate interface is for a multichannel audio: direct digital from a DVD-A, DTS, or SACD source. S/PDIF doesn't support this without resorting to some form of compression.
1394 or USB could be used as an interface, but the overhead for these is much more painful than a proper interface that transfers discrete signals in real-time, rather than in packets.
As far as options for getting audio clock and data signals from one box to another, I've considered 422, PECL, LVDS, and even plain single-ended TTL (for a very short distance).
My conclusion was the same as jwb, that LVDS offered the best combination of performance and ease of implementation.
I like hifiZen's idea of trying to come up with a standard for this.
There could be some degree of flexibility for variations in the clocking and data formats.
I'll have to think a bit more about MDR vs RJ-45 modular connectors. MDRs are a more expensive solution, but they do offer more pairs. In order to limit the number of pairs needed for multichannel, I was considering an EPLD to switch between different data sources in the disk player (2 channel IIS, 6 channel IIS, 2 channel DSD, 6 channel DSD) and then pack the selected source together in a TDM type stream. The use of an MDR connector would possibly allow the data lines to remain separated, but this would also require at least one additional quad LVDS transmitter/receiver pair (almost the same cost as the EPLDs).
Anyway, I'd appreciate feedback.
Brian.
I like your ideas Brian. I'll try to post my schematics and layouts here when I get some time. This weekend, I suspect.
I don't think RJ-45 termination is going to work for a standard. As you correctly point out, that only gives you 4 pairs. You'd need five pairs for 6-channel audio and two clocks. Actually, if you know the word length, you can derive the word clock from the bit clock, so I guess four pairs would work. I'll have to think about it.
For that matter, you could multiplex more than two channels on one serial stream, through obvious methods. You would need more logic, though.
Another disadvantage of twisted pair over twinax is distance. You could easily run twinax across or between rooms. I don't know why that would be desirable, but there you go.
I don't think RJ-45 termination is going to work for a standard. As you correctly point out, that only gives you 4 pairs. You'd need five pairs for 6-channel audio and two clocks. Actually, if you know the word length, you can derive the word clock from the bit clock, so I guess four pairs would work. I'll have to think about it.
For that matter, you could multiplex more than two channels on one serial stream, through obvious methods. You would need more logic, though.
Another disadvantage of twisted pair over twinax is distance. You could easily run twinax across or between rooms. I don't know why that would be desirable, but there you go.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.