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.

[JohnSwenson]

20 minutes ago, LowMidHigh said:

Thank you for the pointed white paper. 99% clear.

 

Since I use a quality Ref10 clock, I'm left  wondering about my cables.

 

How much does attenuation plays a rule in a 1.5 cable? Professional companies gives  their specs @ 100m runs. 

For example, the attenuation of Canare LV-77S @ 100' is 1.0. Can things get any lower? LV-61S @ 100' is 1.3.

 

 

Secondly, if performance can be improved, can anyone recommend a low attenuation 75ohm cable?  By the meter or feet is better, as I solder my BNC cables myself.

Raw attenuation doesn't matter, it is how the attenuation changes with frequency that matters. So the numbers you quoted don't make any difference, what you need is the attenuation vs frequency graph. The flatter the graph below 1GHz the better. The problem is you cannot compare graphs from different companies since the scales are almost always different. Even within the same company the scales are frequently different.

 

The Canare LV-77S spec sheet has a table for this with several of their models. You can tell by looking at this table that the LV-77S has significantly less change with frequency than the others do. This is the information you need to look at to compare cables.

 

Note this is only if you are using square wave output, if you are using sine wave it doesn't matter.

 

John S.

[JohnSwenson]

47 minutes ago, R1200CL said:

 

I wouldn’t mind you tell us how to implement as DIY. If even possible?

 

It is actually very easy to implement a mod to just feed the sine wave out of the OCXO to the BNC jack. I don't have the time to take the box apart and take photos etc.

 

The concept is:

Use Xacto knife to cut the trace coming off the output pin from the OCXO

Unsolder (or cut pins) of the voltage regulator driving everything except the OCXO

cut the wire going from the board to the BNC jack

Solder another wire from the OCXO pin to the BNC jack.

 

Presto the sine wave from the OCXO goes directly to the BNC jack.

 

This bypasses all the circuitry on the board.

 

John S.

[JohnSwenson]

1 hour ago, DarqueKnight said:

The filter did not just damage the square wave, it changed it back to a sine wave!

 

Figure 1. Scope setup with unfiltered BG7TBL square wave output.

 

Figure 2. Scope setup with filtered BG7TBL square wave output. The square wave became a sine wave.

 

 

Figure 3. BG7TBL's unfiltered square wave pulse train.

 

 

Figure 4. Frequency domain (Fast Fourier Transform) plot of the BG7TBL's square wave output. This square wave is composed of the fundamental frequency at 10 MHz and odd order harmonics at 30, 50, 70, 90, and 110 MHz and the attenuated even order harmonics at 20, 40, 60, 80, 100, and 120 MHz.

 

 

Figure 5. BG7TBL's filtered square wave output - converted back to a sine wave.

 

 

Figure 6. Frequency domain (Fast Fourier Transform) plot of the BG7TBL's filtered square wave output.

 

 

Figure 7. BG7TBL's unfiltered 75 ohm sine wave output.

 

 

Figure 8. Frequency domain (Fast Fourier Transform) plot of the BG7TBL's unfiltered 75 ohm sine wave output.

 

 

Figure 9. BG7TBL's filtered 75 ohm sine wave output.

 

 

Figure 10. Frequency domain (Fast Fourier Transform) plot of the BG7TBL's filtered 75 ohm sine wave output.

 

That is exactly what it is supposed to do. The purpose of that filter is to get rid of everything above the fundamental. The reason I mentioned it was to use with a sine wave which is much more susceptible to AM noise, either from the clock itself or picked up in the cable. Most of that noise gets taken care of by the filter.

 

If you already have a good square wave the filter is not appropriate.

 

John S.

[JohnSwenson]

2 minutes ago, MartinT said:

Sound quality is going to be dependent on the consistency and noise at the exact trigger point threshold of the clock receiving equipment.  Whether the clock is square or sine doesn't matter at that level.  At the point of crossing the trigger point, how much jitter and phase noise there is superimposed on the signal (remember, it's an analogue signal) will count for a lot, because it will determine the amount of uncertainty.  Also, consistency from one crossing point to the next, which depends on the receiving circuit design.

This is a major point of the paper, how AM noise gets converted to PM noise in the receiver depends on the slope of the signal at the threshold. Since sine waves have much lower slope at the threshold than a square wave, they are much more susceptible to AM noise than a square wave. Thus shielding is very important for a sine wave.

 

This is the reason for the filter, it will filter out a lot of the AM noise picked up by less than perfectly shielded cables resulting is considerably less AM noise converted to PM noise in the receiver.

 

John S.

[JohnSwenson]

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.

[JohnSwenson]

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.

 

 

[JohnSwenson]

10 hours ago, GMG said:

@JohnSwenson, Sorry for a slightly off topic question, but I have a question related to the Low Pass Filter suggested in the paper

 

Would it make sense to add such a filter to the input of a DAC? maybe with a 1Mhz cut-off frequency

 

Came across this:

https://audiowise-canada.myshopify.com/products/gnd-zro-signal-ground-isolation

I presume you are talking about S/PDIF, a low pass filter is not good for this since it is a square wave with complicated frequency components going up quite high. The low pass filter would destroy the signal.

 

That filter you link to on the other hand IS a useful device. Since leakage current is primarily low frequency, a HIGH PASS filter attenuates the leakage current while letting the signal you want (S/PDIF) go through. It probably has a significant attenuation for low impedance leakage, but probably not effective for high impedance leakage. So for most systems it is probably useful but not a complete solution.

 

John S.

[JohnSwenson]

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.

 

 

[JohnSwenson]

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.