It sure has be noted already somewhere but I want to bring it up again: All the efforts for low jitter and brutal stability fly out of the window once the crystal is subject to any vibration.... unless it was clearly optimized for low vibrational sensitivity which may be at odds with low phase noise design.
Reference to Cosmos ADC is irrelevant as ES9822PRO outputs I2S so all phase noise inducing processing is done already by ES9822PRO. All CT7601 does is convert I2S to PCM for USB output. That does not induce any phase noise.
Ok, I agree, but if there were any anomalies on the USB src bridge they would certainly be reflected in the measurement and there certainly wouldn't be a -126dBc noise level floor on the E1DA, right? I accept every recommendation regarding master clock.
Anomalies in the I2S-USB bridge would show up as invalid or dropped samples so not directly related to noise floor.
Ok, regarding master clock what you think is better choice for me, used MV85 OCXO or one Driscoll based from attachment? Making an ocxo is in my opinion very hard job, expecialy if there is no equipment for phase measurement which is very expensive, maybe the best choice is used mv85? Why used? Because it has stabilized after many years of use and its aging characteristics should now be significantly less.
Or maybe an Crysteq xo and put them in oven? Ian Canada femto is very expensive, in my opinion not much better for ten time lower price Crysteq?
Can you please tell me where I can get link for reclocker v14 ?
Or maybe an Crysteq xo and put them in oven? Ian Canada femto is very expensive, in my opinion not much better for ten time lower price Crysteq?
Can you please tell me where I can get link for reclocker v14 ?
Last edited:
As I mentioned previously, there is no link to the v14 yet, I haven't released it since I have a problem on the last board I constructed and I am holding off until I can figure out whether it is simply a solder joint problem in the build or something more subtle with the design itself. I will keep you posted.
V13, v12, v11... etc link is available? I'm just interested in design and eventualy I can get some idea out of it, maybe I not need that at all. One question trought, how peoples from this thread allready know that v14 is good at all when there is no schematic,pcb,measuements,results... etc available?
Last edited:
The principles, component choices, layout advice and a lot more were discussed on this thread:
Markw4 designed the general purpose clock board and the re-clocker/isolation board and made them available to the community. All I did was try to compress the functionality down to fit the amount of space I had left in the case of my already built DAC. In hindsight that was probably a mistake and sticking with Mark's boards would've been easier and ultimately superior, given the other considerations of case layout, spacing between components to reduce crosstalk, etc.
However, I learned a lot from Mark's generous help over many iterations and I believe the v14 board is a reasonable compromise if space is limited.
I will upload the gerbers and BOM once I am happy with the latest misbehaving board but here is the schematic and image of the layout.
Some pics of a prototype general purpose DAC Clock board, for which I plan to post the Kicad project. First pic is driving a Andrea Mori FIFO Buffer board; second pic is driving a @MarcelvdG RTZ FIRDAC with asynchronous USB, and reclocking before the dac board (clock board prototype is outlined in red).
The original premise was that the clock board would use 45/49MHz clock modules (or external clocks, including sine wave oscillators using suitable squaring adapters). The 45/49MHz frequencies can be used to externally clock an I2SoverUSB board. The clock...
The original premise was that the clock board would use 45/49MHz clock modules (or external clocks, including sine wave oscillators using suitable squaring adapters). The 45/49MHz frequencies can be used to externally clock an I2SoverUSB board. The clock...
Markw4 designed the general purpose clock board and the re-clocker/isolation board and made them available to the community. All I did was try to compress the functionality down to fit the amount of space I had left in the case of my already built DAC. In hindsight that was probably a mistake and sticking with Mark's boards would've been easier and ultimately superior, given the other considerations of case layout, spacing between components to reduce crosstalk, etc.
However, I learned a lot from Mark's generous help over many iterations and I believe the v14 board is a reasonable compromise if space is limited.
I will upload the gerbers and BOM once I am happy with the latest misbehaving board but here is the schematic and image of the layout.
I've decided to read and understand (rather than asking a bunch of questions), but I have been following and learning everything I can on the way. I just wanted to say thanks to everyone who's been contributing. This is really cool stuff.
Occurs to me that since you now have an MCLK output available, you might be able to follow this board with my reclocker board. Maybe just as an experiment to see if more isolation and or physical separation can make any audible difference.
Thanks, I like the use of lmk1c1104 clock buffer, nice clock buffer! But apsolutly not like reclocker based on flip-flops to reclock lrck,bck and things in the same time, thats wrong way. Flip-flop have minimum 3.5ns propagation delay and every flip-flop doesn't guarant that each will have the same propagation delays, flip-flops for reclocking purpose have no sense!
Faster logic family individual D-flip-flops are the best way to reclock that I know of. Under stable temperature, bypass, voltage regulation, taken off the same reel, etc., conditions they do better than the worst case skew. The actual practical problems with designing a pretty good reclocker you still need to figure out. Reading the General Purpose Clock Board thread more carefully might help. It goes into some problems found with an older reclocker design.
You just adding huge jitter between clkin and datain for example while reclocking those two lines trought two flip-flops. Ct7302 will do that better with their internal clkin freq detection circuity and digital pll and automaticaly adjust all data lines simultaneously to the clkin freq.
Clock board I like, expecialy choice of clock buffer, but not like reclocker, thats not good in my opinion. You need something in femtoseccond guaranted propagation match between all channels if goal is an ultra good reclocker, that way all channels might be synchronised to clkin. Using few flip flops with not guaranted p.d. and you can't expect an good synchronisation to clkin. Even with Potato you can't get perfect channel to channel match.
Clock board I like, expecialy choice of clock buffer, but not like reclocker, thats not good in my opinion. You need something in femtoseccond guaranted propagation match between all channels if goal is an ultra good reclocker, that way all channels might be synchronised to clkin. Using few flip flops with not guaranted p.d. and you can't expect an good synchronisation to clkin. Even with Potato you can't get perfect channel to channel match.
Last edited:
Did you look at the RTZ dac schematic? What do think happens in there? You are guessing/assuming rather than experimenting to see what actually works. Of course that's perfectly okay with me and I think probably about the same feeling with most of the other folks here. Please have fun whatever you decide to do 🙂
Last edited:
NC7SZ74K8X have propagation delay of about 5ns, even thats not guaranted! We speaking here about femtosecconds jitter?
Propagation delay and jitter are two entirely different things. 
Last edited:
To be honest, the schematic is so confusing and unclear, those data lines in,out with mark J...etc, what you reclocking there?
The board pic shows everything labeled on the silkscreen layer. You should study the board pic anyway to understand how the layout is designed. Its just as important as the schematic, IMHO.
Hi Marcel,
I've been trying a couple of different PCM-DSD512 software file encoders. When I play back a 16/44 wav file in HQ Player, the audio comes out reasonably good when your PWN FPGA code is running (its not distorted or noisy). When I try to play one of the DSD512 files from HQ Player, there is some music there but its mostly noise and distortion. I'm wondering if the FPGA DSD passthrough mode has the same propagation delay (relative to MCLK, given the reclocker) as when doing the PCM->DSD conversion in the FPGA? Otherwise, I might need to design a selectable dual delay reclocker depending on what encoder/source someone is trying to use. Or, maybe there is some other issue?
EDIT: Thinking about some more, the phase of MCLK going into the USB board is shifted by the PLL. The way I have the delays set, it works with okay with PJotr25 firmware including with external DSD files up to DSD256, and it also works okay with your firmware at DSD512. Its just the DSD512 passthrough that is having a problem.
Mark
I've been trying a couple of different PCM-DSD512 software file encoders. When I play back a 16/44 wav file in HQ Player, the audio comes out reasonably good when your PWN FPGA code is running (its not distorted or noisy). When I try to play one of the DSD512 files from HQ Player, there is some music there but its mostly noise and distortion. I'm wondering if the FPGA DSD passthrough mode has the same propagation delay (relative to MCLK, given the reclocker) as when doing the PCM->DSD conversion in the FPGA? Otherwise, I might need to design a selectable dual delay reclocker depending on what encoder/source someone is trying to use. Or, maybe there is some other issue?
EDIT: Thinking about some more, the phase of MCLK going into the USB board is shifted by the PLL. The way I have the delays set, it works with okay with PJotr25 firmware including with external DSD files up to DSD256, and it also works okay with your firmware at DSD512. Its just the DSD512 passthrough that is having a problem.
Mark
Last edited: