John Swenson tutoring paper: "Considerations regarding usage of external reference clocks" (EtherREGEN and other): Sine vs. square, impedance, cables—and a money saving surprise at the end.

11 hours ago, GMG said:

If I got it right, a better clock in general means less jitter. 
The thing that has me a bit confused is that I also understood that there is a thing called jitter rejection on the DAC - which I’m not quite sure I understand what it means - maybe it means the DAC is performing a reclocking process at its input?
So if I have a DAC that has been shown with measurements that it has near perfect jitter rejection would I ever benefit from a better clock up stream?

I’m not saying measurements are the only thing that matters, but if I should still expect to hear a different/better sound with an upstream clock, will it be due to less jitter or is there something else at play here?

 

@JohnSwenson I would appreciate your insight here. You mentioned to me in a different thread when I asked about adding a reclocker before the DAC, that some DACs will not benefit from a reclocker (especially if the DAC doesn’t have clock inputs). Would that be the same with upstream clocks?

 

for reference, my stream: router—>Optical rendu deluxe—>ER—>miniDSP shd studio—>Chord Qutest—>Naim Supernait2 + TeddyCap power upgrade. 

There is no such thing as full jitter rejection, it doesn't exist, so any real circuit has to have SOME jitter sensitivity. A major issue is to look for what units are being used for jitter. Some companies have decided that 1ns of jitter is "essentially zero jitter", so if they can get their jitter down to 1ns, they consider that to be all that is necessary and market that as zero jitter. BUT there is a whole world below 1ns. This is where everything we are working on here resides. If a company says that no matter what the input is the signals going into the DAC have 1ps or less, THEN you can say they really do have an effective jitter rejection. But I don't think anybody is actually making that claim.

So unless some company really has come up with something truly amazing, I think that these things being talked about here will still be useful, even with DACs that say they have "near perfect" jitter rejection.

John S.

16 hours ago, GMG said:

Thanks Martin, 

Sure, but are saying that the clock adds to the clean up of the ground noise?

The proper response to this question is a book, there is no way I can respond to it in one post. Ultimately what really matters is the jitter inside the DAC chip (or on the PCB traces in a discrete DAC). There are MANY, MANY possible contributors to that.  The EtherREGEN white paper covers a lot of this, please read that first.

Noise on a PCB ground plane or in a chip's power network can be converted to jitter in several ways (again see the ER white paper). These processes can happen in many different places in a chain. Ground plane noise can come from many places (see paper).

A reclocking that happens to signals after a ground plane noise conversion to jitter will attenuate the affects, but it will NOT affect ground plane noise effects after the reclocking. Reclocking by itself just affects jitter, so it's affects on ground plane noise only occur after the ground plane noise gets converted to jitter. But remember this process can happen in many places so a particular reclocking my affect some and not others.

As the ER paper mentions reclocking can itself generate ground plane noise which can partially negate its effectiveness.

The jitter on the clock doing the reclocking is very important. If the clock used for reclocking is has higher jitter than the what you are reclocking it makes things worse. So reclocking only makes sense when you have or can generate a clock that is better than what your data has. There are methods of extracting a clock and lowering its jitter so it can be used to reclock the data, this is what most S/PDIF "reclockers" do, but this can only go so far, it is really only useful when the data has a lot of jitter. If your data is already quite low jitter then using this process makes things worse.

If you can't do this then things get quite a bit more complicated and more sophisticated methods have to be used to get a lower jitter clock than your already good data.

I'm sorry this is all very vague, but unfortunately it is a complicated subject and a thorough deep dive is long. AND the processes can happen in so many different ways and permutations that is is impossible to make simple statements about what happens in a system. 

John S.

32 minutes ago, Mihaylov said:

Here are examples of various BG7TBL's products:

 

 

 

 

 

Mini-Circuits (from datasheet):

 

 

It can be seen that simple LCL low pass filters are responsible for creating a square wave signal at the output, exactly as in the Mini-Circuits and Crystek filters (circled in yellow). Blue circled where there is no LCL filter at the output and the sine wave signal at this output accordingly. So how do the recommended Mini-Circuits filters differ fundamentally from LCL filters in BG7TBL's products? Only more steep filter?

 

 

 

Huh? The filters are designed to produce a sine wave from a square wave not the other way around. These filters are at the source of the signal. The external filter is to be used AT THE RECEIVER. The reason for this is that the input circuit is very sensitive to AM noise on the sine wave. Putting the filter at the receiver attenuates noise picked up by the cable as well as noise in the source. Of course the external filters mentioned have quite a bit steeper attenuation curve which also helps.

John S.

I have to post a quick note of thanks for @JohnSwenson for thinking of and informing us about this low pass filter for sine wave clocks.

Although I didn't use it for my EtherRegen, it goes to show that the filters do work nicely.

I have a Cybershaft OP-14 which was part of my earlier Trifecta Stable system. I don't use it anymore since upgrading to a Pink Faun streamer but I was curious about the effect of the low pass filters on the clock. So I purchased 2 of them - the Crystek CLPFL-0010-BNC and the MiniCircuits BLP-10.7+.

I figured that if one worked, then perhaps 2 might be better. From their performance graphs the insertion loss was only 60-80db for some frequencies so  perhaps using 2 in series would make the slope steeper with better total attenuation.

It worked! Through a sMS-200neo (clocked by tx-USBultra) and a tx-USBultra reclocked by the Cybershaft with it’s Cybershaft branded 50ohm BNC cable, the sound is clearly better with the Crystek filter added and when the MiniCircuits filter was added in series, further improved.

From memory, it brought my trusty Cybershaft OP-14 up to possibly a Mutec clock or at the very least sounded like I added the expensive Habst ultra BNC cable.

So thanks for the tip, gratefully accepted. 😄

6 hours ago, Mihaylov said:

Do I understand correctly that in order to convert the 75 ohm version of ER to 50 ohm, is it enough to replace the BNC connector with a 50 ohm connector and replace the R86 resistor with 50 ohms?

That is correct.  However, removal of the 75-Ohm BNC without damaging the circuit board is difficult. The BNC jack, in addition to it's two small pins for electrical connection, has two large diameter alignment/securing pins. Unsoldering all pins--with full release so that the jack can be wrestled off the board--takes time, patience, and good nerves. We are not responsible for torn up traces resulting in a ruined board.

I have done the conversion once--took me nearly an hour--and have sworn not to do it again. 

From the next run of 225 EtherREGENs (boards due mid-January), 15 units will be made with 50-Ohm BNC (and matching termination resistor). Anyone can request reservation of one of those when they order.

4 hours ago, feelingears said:

 

Hi, @JohnSwenson

 

There may have been relevant context prior to this statement that I have taken out by mistake, but this comment seems to imply that reclocking devices added in series is "likely" to make things worse as you say. I've not been one to do or test this but of course people here have put two EtherRegens inline and so on. And I'm asking about Ethernet and USB where reclockers have, to my ear, definitely improved most things. And there again people have "stacked" reclockers in series. (Maybe crossing over from one, um, protocol (is that the right term for this change of data?) to another increases jitter or something, I dunno.)

 

So it makes sense that some have found stacking to make things worse per your comment above, and I guess my question with the EtherRegen more specifically is that if one has a sufficiently good streamer or DAC, say, with a better clock than the EtherRegen, then it's likely the EtherRegen will do more harm than good?

Alex knows that I just purchased a JS-2 for use with the manta ray Aries streamer, and that's a different topic (yes it's a solid improvement, thank you!) and because the manta ray is such an old unit I'd think the EtherRegen should help (my ears say yes). But, what if I had a streamer or a DAC or combo that's more modern and more high end with a similar clock as the EtherRegen with Ethernet as an input?

 

Forgive me if this is an oversimplification (I'm sort of guessing it is) and I'm asking just to clarify the practical implication of your statement.

 

 

The issue is not that "reclocking is bad" but that reclocking with poor clock is bad. All reclocking systems have SOME level of sensitivity to the jitter of the incomming data. The ER has an extremely low sensitivity (but it is not completely zero). The result of this is that in DACs,  streamers etc out there taking in Ethernet data there will be some effect on the internal jitter from the input data no matter how good the internal clock is. The ER is designed to produce very low jitter data coming out no matter what the incoming data jitter is.

So in order to determine whether a particular reclocking will be useful you need to know the jitter on the data coming in to the reclocker, the sensitivity of the reclocker, the phase noise of the clock, and the sensitivity of the device fed by the reclocker. In the real world none of these are known (except for maybe the phase noise of the clock) thus there is no way to know if a given reclocking somewhere in the stream is going to improve any thing. And this is ignoring leakage from power supplies.

So don't even try making assumptions about what will improve things, there is no way to know. Trial and error is your only real method. Even reading posts from other is not a real option since these effects are quite system specific and unless your system is EXACTCTLY the same it could wind up with very different behavior.

John S.

1 hour ago, feelingears said:

Yeah, that has been my general impression lurking the clock threads and such. I've avoided "over-reclocking" in part due to diminishing returns and the fact that 90% of my listening is Red Book or 24/96. And my rack is spaghetti enough with cables sticking out three sides and not just the back. 😉

My listening is probably 99% redbook and 24/96, mostly via Qobuz these days.  All resolutions improve, but diminishing returns always apply.   I'm sure you have seen on the threads that not only does the eR alone elevate all resolutions (I would also include internet radio), but that using a quality external clock for the eR makes a significant difference (depends, of course, on listener preferences, budget, rest of setup, etc.).  

All of this does indeed make for more complexity and crazy number of cables in all directions.  I hadn't anticipated that I would add anything after adding the first stock eR.  Went down the rabbit hole and found it interesting.   What I have now (I think of it as the boiler room) probably cost 60% of the cost of the streamer solution I was considering.  So, seems to have worked out well, for me anyway.