Mod for optical to coaxial - musiland us
Feb 18, 2010 at 2:38 AM Thread Starter Post #1 of 16

dazedbus

New Head-Fier
Joined
Jan 17, 2010
Posts
47
Likes
12
I'm wondering if there is a simple way of modding the spdif on the musiland from toslink to coaxial or bnc. I didn't realize that my DAC doesn't take optical input so I am wondering if I make a simple mod on the musiland (from the schematics that I've seen it seems that I can just pop in a pulse transformer and then connect it to a 75 ohm RCA or BNC). I'm hoping that someone understands this better than I do and can give me a little feedback. Thanks.
 
Feb 18, 2010 at 3:14 AM Post #2 of 16
what you need is a 'media converter', as an external box. better that way since it applies to any gear, not just this one 'trouble spot' of gear to gear hookup.

monoprice has them, believe it or not. not the best quality but they work. coax to opto and opto to coax. in the $10 range, last time I looked.

if you need to upgrade, you can yank out the cheap optos they use and put in better quality ones. not much else needed.

you can always embed these things if you have enough room. take the plastic shells apart (on those monoprice things) and use the boards. I've done that before..
wink.gif
 
Feb 18, 2010 at 4:29 AM Post #3 of 16
Toslink is SPDIF, so adding a BNC (or RCA) should be doable. Pulse transformer such as Newava would be a good idea. The only harder to do (figure out) part is terminating it so that the impedence is 75 ohms. Do some searches on diyaudio (jocko's posts, etc.) and you should get some ideas.
 
Feb 18, 2010 at 6:58 AM Post #4 of 16
linux, I am specifically trying to avoid the seemingly pointless conversion of electrical -> optical -> coax -> electrical. I do agree that terminating at 75 ohms will probably be difficult and I guess I could try to see if I can find anything on that from the pcb side... maybe it's worth doing it with a bnc instead and modding my dac in the same fashion as well.
 
Feb 18, 2010 at 2:01 PM Post #6 of 16
Quote:

Originally Posted by dazedbus /img/forum/go_quote.gif
linux, I am specifically trying to avoid the seemingly pointless conversion of electrical -> optical -> coax -> electrical. I do agree that terminating at 75 ohms will probably be difficult and I guess I could try to see if I can find anything on that from the pcb side... maybe it's worth doing it with a bnc instead and modding my dac in the same fashion as well.


bnc's don't matter. impedance does not matter! people say it does but I strongly disagree. over 20 years of 'mis running cables' (for fun and non-profit, lol) and not a single digital bit error or 'smear' has occurred in my own personal experience. I abuse spdif standards almost daily, too
wink.gif


the bits always get thru. those selling expensive 'solutions' will disagree but spdif IS robust and quite reliable. it takes a lot to corrupt it.

if you have a toslink, you already have a buffered ttl out. to go from that to toslink is this:

2441313263_45de7cd89f.jpg


for a driver, I like:

ua9637
ua9638

those are rs422 diff drivers and I use them to convert opto to coax and back again.

you can also use the 74hcu04 (unbuffered) to drive from ttl level to .5v coax 'pulse trafo' level.
 
Feb 18, 2010 at 6:13 PM Post #9 of 16
Quote:

Originally Posted by FallenAngel /img/forum/go_quote.gif
I follow the whole 75-ohm coax cable everywhere, pulse transformers everywhere, BNC everywhere, but honestly - this is just an extreme in practice, simply running a pair of wires to a BNC or RCA jack in that musiland will get you what you want to do. Toss in a pulse transformer if you want (good idea).


Fallen, I will try your idea today to see how this goes. I unfortunately do not have a pulse transformer on hand to test it as our parts storeroom does not carry them to my knowledge.


Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif
bnc's don't matter. impedance does not matter! people say it does but I strongly disagree. over 20 years of 'mis running cables' (for fun and non-profit, lol) and not a single digital bit error or 'smear' has occurred in my own personal experience. I abuse spdif standards almost daily, too
wink.gif



While I may not be knowledgeable in audio or the signal processing involved, I understand the physics behind the conversion. An electrical signal is sent in bits towards which is converted into an optical signal (probably a modulator + LED). The signal from the LED is caught by a receiver and converted back into an electrical signal. Efficiency for both conversion and receiving are fairly good (probably around 50%), but this is just inefficient and while it may not result in bit-errors (the LED is plenty strong so the power really isn't too big of an issue) it is more complicated and will probably introduce a larger amount of noise in the audio path compared to a direct removal of the optical output.
 
Feb 18, 2010 at 6:26 PM Post #10 of 16
Quote:

Originally Posted by dazedbus /img/forum/go_quote.gif
will probably introduce a larger amount of noise in the audio path compared to a direct removal of the optical output.


sorry, but that's just not correct.

you could go thru dozens of opto/coax conversions and it won't harm a thing. the signal will be received by any competant/modern dac just fine.

a single (or even double) media conversion will not even be detectable by audio analyzer programs. this is NOT lossy analog transfer, the rules are entirely different.
 
Feb 19, 2010 at 5:25 AM Post #11 of 16
I had to make sure voltages were correct before doing the quick switch. I don't think it will work since toslink operates at 0/5 V and coaxial uses a +-0.5V signal. Therefore, I will simply have to use a toslink to coaxial converter... linux could you explain to me why there is no real loss in data or increase in noise. As far as my understanding of signals in the physical world goes, extra conversions will lead to increased noise. To me, changing electrical -> optical -> electrical seems simply redundant to me.
 
Feb 19, 2010 at 1:21 PM Post #12 of 16
to make a long story short, the only time that jitter (which is what we are talking about) matters is when its at the last d/a stage. a long time ago, I used to do DAT taping and some of us would attend concerts and tape them (legally). we learned about digital i/o and that dat->dat->dat->dat->...->dac works just fine and only the last stage 'matters'. you can convert media a hundred times and it won't hurt a thing. no data is lost and only 'timing' might change. but the timing is 'fixed' at the last stage (reclocking) and so none of this matters.

its all about digital information theory. read pohlman's book as a starter.

when I send email or post, my data goes thru hundreds of routers, switches, lans, wans and so on. the bits get to the end, still. the only issue that audio has over data is timing and the timing is embedded in the data and does not change during transmission as the timing is EMBEDDED in the signal. every modern dac I've tried (and even 15 yr old ones) extract timing just fine. there is enough 'room' in a wave to know if its a 1 or 0 and there's enough time to know where 'in time' that sample is supposed to be. its not hard anymore. $5 and $10 chips do all this for you.
 
Feb 19, 2010 at 2:04 PM Post #13 of 16
Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif
when I send email or post, my data goes thru hundreds of routers, switches, lans, wans and so on. the bits get to the end, still. the only issue that audio has over data is timing and the timing is embedded in the data and does not change during transmission as the timing is EMBEDDED in the signal. every modern dac I've tried (and even 15 yr old ones) extract timing just fine. there is enough 'room' in a wave to know if its a 1 or 0 and there's enough time to know where 'in time' that sample is supposed to be. its not hard anymore. $5 and $10 chips do all this for you.


That's a bad analogy, and knowing that you are a network guy, you know it. TCP, which handles all of those transmissions, has error correction and re-transmit in the stack. Email or post is also time in-sensitive, so re-transmit doesn't matter.

SPDIF is different is that it is one-way with no error correction or re-transmit mechanism. Sort-of like VoIP, which runs UDP. Delay, mis-time or drop a UDP packet and see what happens to your call quality.

There are instructions, on another site, on how to use a 100MHz scope as a TDR to watch the effect of the reflections to see the wave come back from bad impedance matching. There are posted graphs from the results. It is visible and measurable.

Does it make a difference? Possibly. Depends upon when that reflections hits the receiver. If it hits in the "decision window," or read period, it can. Also how many reflections are you dealing with at once?
 
Feb 19, 2010 at 2:09 PM Post #14 of 16
Quote:

Originally Posted by cobaltmute /img/forum/go_quote.gif
That's a bad analogy, and knowing that you are a network guy, you know it. TCP, which handles all of those transmissions, has error correction and re-transmit in the stack. Email or post is also time in-sensitive, so re-transmit doesn't matter.


I was not at all talking about retries or queuing, ONLY media conversion and bit swapping, many many times as a handoff from one box to another.

there is no 'distortion or noise' in digital, which is what the poster was implying. the bits can fly from media type (100baseT) to my phone wan then up to atm, then (etc etc). bits don't get 'distorted' when they convert from one interface to another.

and while you can see the analog effects of the transmission line, the digital receivers ignore that. they simply care about getting timing and the right bit and I've never seen a modern dac fail, no matter HOW I abuse the spdif wiring (and I do that quite a lot, just informally when I test protos).

if I had not spent a lot of timing 'mis wiring' spdif and still getting it to work, maybe I'd believe in digital 'distortion and noise' too but I've never seen it in my lifetime.

what I'm sayhing is that the shape of the signal means almost nothing to modern spdif receivers. they extract data even in the worst of 'analog situations' for the cabling and connectors.

I would start to believe this if I saw it happen but I just don't see this in the real world, sorry. have to go with my own lying eyes, I guess.
 
Feb 19, 2010 at 2:12 PM Post #15 of 16
Quote:

Originally Posted by cobaltmute /img/forum/go_quote.gif

Does it make a difference? Possibly. Depends upon when that reflections hits the receiver. If it hits in the "decision window," or read period, it can. Also how many reflections are you dealing with at once?



decision window is VERY implementation dependant. some dac chips (or receivers) just work no matter what. some need 'clean' signals but those are, more and more, older tech.

reflections and such are small enough that they are ignored at reception-side. you'd have to have MASSIVE reflections to truly interfere and 'confuse' the receiver.

each bit only contains 1 of 2 levels; how hard can that be, really, to figure out on a half volt signal if its a 1 or 0? its not that hard and reflections do not matter when the receiver is decent enough.
 

Users who are viewing this thread

Back
Top