Arh, yes - the OLED panels for you, I collected it last month while in Asia. If you send an Email to Renata with your Address etc. we will post it to you
![]()
Just to clarify -am I right in thinking that the purpose of the clock link back from the mdac/fdac is to synchronise the usb clock with the dac clock? not necessarily to make the dac clock less jittery as such, although bthe jitter may (possibly) be made more benign by randomising/dithering it? And the purpose of synchronising is to reduce the interaction between the usb clock and the dac clock(?)The hard part of designing the clock-lock interface was to insure that the inherent Jitter of the Clock-Lock "Clock" signal does not degrade the clock in the Detox.
https://dl.dropboxusercontent.com/u/86116171/Detox Clock Proto.JPG
If you look at my Rats nested prototype circuit of the Detox Clocklock circuit in the above link you can see the x3 Crystals (Silver metal cans) - these are arrange to "filter" the incoming clock signal removing the Phase noise. The crystal filter only passes a very narrow signal bandwidth, any signal that falls outside of this bandwidth (Jitter Phase noise) is heavily attenuated.
https://dl.dropboxusercontent.com/u/86116171/Detox Band Pass.jpg
This rather phallic shaped filter characteristic (The final filter has a stopband attenuation of around -90dB) is the first stage of rejecting external Jitter on the Clocklock link, this is then followed by a PLL circuit with a very low frequency cutoff point to further attenuate any remaining jitter.
I'll verify the final performance levels on the "production PCBs" but after such lengths I don't expect (I'd like to believe) that the Detox is immune to external jitter.
Just to clarify -am I right in thinking that the purpose of the clock link back from the mdac/fdac is to synchronise the usb clock with the dac clock? not necessarily to make the dac clock less jittery as such, although the jitter may (possibly) be made more benign by randomising/dithering it? And the purpose of synchronising is to reduce the interaction between the usb clock and the dac clock(?)
Sorry if I have got this wrong, but I've slightly lost the thread of what we are going, especially in the light of the point that a great distributed clock could end up more jittery than an fairly good local clock (aka the argument as to why external aftermarket clocks aren't necessarily a good idea unless you need to synchronise devices.)
Of curse in the case of a S/PDIF device sending the clock back allows the conversion clcok to be indpedent of the transmitting clock. But since we are using asych usb here the conversion clock is not derived from the transmitting clock anyway. So the point of sending the clock back is therefore more subtle
Detox payment sent .... I sense we are almost getting there!
In answer to your PM, your salvaged MDAC will be swapped directly for the FWC at no extra cost to you
Later I'll try and repair the salvaged units to turn them back into cash - but TBH I don't see me having the time...
Thanks. As I understand this point,Yes, in consideration that digital logic offers very poor isolation between input and output jitter, the clock-lock data streams insures that the incoming USB data is synchronizes with the audio conversion clock so that all clocks including the USB data are derived from the audio master clock.
.....
The is no such thing as true finite 1 and 0 in real world logic hardware, if you zoom out it looks like 1's and 0's but zoom in with greater dynamic range and you see that its really only an Analogue signal represented by two discrete voltage states with significant dynamic range between these two states. OK for computation, but when we are constructing an analogue signal with over 120dB DR the finite SNR between 1's and 0's becomes a problem which manifests itself as Jitter.... in audio conversion there is no such thing as "only Ones and Zeros"....
Thanks. As I understand this point,
- every time a clock ticks the tick slightly interferes with the other clocks and hence ultimately the conversion clock
If the clocks tick in time there won't be any interference between them.
- the tick may also directly affect the analog output
I'm not quite sure I follow why this is better from the point of view of the pollution which clocks bring directly to the analog output- is the idea that it's better that there should be a single RF component derived from the conversion clock rate rather than lots of different RF components?
I think you may have answered this before so forgive me asking but I can't remember your answer - are you deriving the 12Mhz USB clock (or 24Mhz clock) from the audio clocks of 22.XXXMhz or 24.XXXMHz? Does this make them synchronous? - I don't see it, sorry.Yes, in consideration that digital logic offers very poor isolation between input and output jitter, the clock-lock data streams insures that the incoming USB data is synchronizes with the audio conversion clock so that all clocks including the USB data are derived from the audio master clock.
The Detox Clocklock interface attenuates the MDAC/FDAC clock output jitter to below the Noise Floor so that there is no measurable difference between the Detox's own onboard clock or when externally clock locked - the circuit took a good few days to develop. I have the advantage that that the input clock is a known variable with tight PPM error and slow drift which allowed the use of a cascaded crystals to act as a very narrow passband filter.
I point you to the my earlier test which shows the very finite isolation between logic gates on a silicon substrate :-
http://www.pinkfishmedia.net/forum/showpost.php?p=2695927&postcount=1373
This proves the need to do everything in ones power to prevent unwanted Phase noise entering the DAC as digital logic has very poor isolation due to limited gain of the logic block and other device parasitics (unwanted capacitance and inductance etc).
When I designed the discrete 1 bit converter of the Dacapo I coined the term "Logic Induced Modulation" LIM to describe this coupling effect between individual logic gates - theres no mystery around LIM, rather the limited gain of the logic cell to "square" the input pulse and other real world parasitics of a physical device.
The is no such thing as true finite 1 and 0 in real world logic hardware, if you zoom out it looks like 1's and 0's but zoom in with greater dynamic range and you see that its really only an Analogue signal represented by two discrete voltage states with significant dynamic range between these two states. OK for computation, but when we are constructing an analogue signal with over 120dB DR the finite SNR between 1's and 0's becomes a problem which manifests itself as Jitter.... in audio conversion there is no such thing as "only Ones and Zeros"....
I'm always glad for the benefit of John's skill and knowledge, but the "ones and zeros" thing is actually a bit confusing, if popular. Digital and Analogue are in fact strictly ways of coding information. The information has to be coded in something. Digital audio information is transmitted using a carrier medium which is the same as the medium under which analogue information can be carried. That carrier medium is in fact not properly described as digital or analog, it just is. The carrier signal is often described as being "really analogue" but what does that mean?"The is no such thing as true finite 1 and 0 in real world logic hardware, if you zoom out it looks like 1's and 0's but zoom in with greater dynamic range and you see that its really only an Analogue signal represented by two discrete voltage states with significant dynamic range between these two states. OK for computation, but when we are constructing an analogue signal with over 120dB DR the finite SNR between 1's and 0's becomes a problem which manifests itself as Jitter.... in audio conversion there is no such thing as "only Ones and Zeros".... "
John
This is a very informative and valuable insight. It shows how little the "ones and zeros" acolytes actually know.
I think you may have answered this before so forgive me asking but I can't remember your answer - are you deriving the 12Mhz USB clock (or 24Mhz clock) from the audio clocks of 22.XXXMhz or 24.XXXMHz? Does this make them synchronous? - I don't see it, sorry.
Or are you saying that the Detox USB clock & the FDAC's USB clock will both be synchronous?
If so, could you not just send the FDAc's clock back to the Detox device for use as it's local clock - do you need the clocklock function?
Give me a week or so to answer as I'll be working on the connector arrangement so the vendor can produce the completed ID drawings and start on the chassis prototypes.
Will I get any potential improvement of the USB signal being sent to my DAC beyond that offered by the 3 levels of signal regeneration and filtering?
Also, since the DETOX will be generating a clean 5V output to the downstream DAC if I understand correctly, is there any downside to having this voltage supplied to the USB input of a DAC that does not need power or a handshake such as mine?
John, any progress on the FDAC digital board?
/Lars
Perhaps the effect on the analogue output needs a new way of measurement to reveal it.