Hi Frex,
It has indeed been very quiet here for some time, so I just saw your post now.
I do appreciate the contributions you have made to this forum and since you ask so nicely I have decided to reveal the trick. The document also covers the question from Ikarus65.
In some cases the external MCLK may not always be present. This is the case in my isolated design because the isolated part may not be powered even if the USB part is powered. In my interface I have therefore included a multiplexer, which switches over to the local clock output from the USBStreamer, if there is no external MCLK. It has been a long time since, but as far as I remember, it would partly lock the PC driver if no MCLK was available.
I am in the process of moving to an own design for my Audio Analyzer. This design of course implements the external MCLK input, mux and isolators etc. on one PCB. It even has an isolated I2C interface for control purposes.
It has indeed been very quiet here for some time, so I just saw your post now.
I do appreciate the contributions you have made to this forum and since you ask so nicely I have decided to reveal the trick. The document also covers the question from Ikarus65.
In some cases the external MCLK may not always be present. This is the case in my isolated design because the isolated part may not be powered even if the USB part is powered. In my interface I have therefore included a multiplexer, which switches over to the local clock output from the USBStreamer, if there is no external MCLK. It has been a long time since, but as far as I remember, it would partly lock the PC driver if no MCLK was available.
I am in the process of moving to an own design for my Audio Analyzer. This design of course implements the external MCLK input, mux and isolators etc. on one PCB. It even has an isolated I2C interface for control purposes.
Thank you for this! In the meantime, I received word from miniDsp support that 3.3V is available at pin 2 of J2 for a max of 10mA ("to be safe"). I assume this info is to be treated as 'unofficial', since they did not include it in the document. I measured the resistance between this point and yours, but they are not directly connected.
Hello JensH,
Thank you for the tips.
Anyway, you maybe have seen that i finally bought a DIYink XMOS board instead of USBstreamer.
Mainly because modifications and integration in new interface project seem lot easier.
I see that you also think to design other thing for your ADC analyser,
i understand and think we have both the same need...
And using a USBstreamer in the analyser will rise much the final price too.
So i've preferred to get a XMOS board to build an interface prototype, but when we see that the board include
only the XMOS IC and very few parts we soon feel that building an interface including the XMOS DSP would be
the smartest solutions.
But, we would need to develop our own firmware that is a time consuming time task.
Is it that way you have choosen ?
Regards.
Frex
Thank you for the tips.
Anyway, you maybe have seen that i finally bought a DIYink XMOS board instead of USBstreamer.
Mainly because modifications and integration in new interface project seem lot easier.
I see that you also think to design other thing for your ADC analyser,
i understand and think we have both the same need...
And using a USBstreamer in the analyser will rise much the final price too.
So i've preferred to get a XMOS board to build an interface prototype, but when we see that the board include
only the XMOS IC and very few parts we soon feel that building an interface including the XMOS DSP would be
the smartest solutions.
But, we would need to develop our own firmware that is a time consuming time task.
Is it that way you have choosen ?
Regards.
Frex
Hi Frex,
The need for SW development and the issues with the PC driver made me go for an existing solution initially. But I have now developed an XMOS based design, which is tailor made for the Audio Analyzer. So one PCB will provide the interface between the USB and the I2S audio interface as well as an I2C control interface. The USB section is galvanically isolated from the USB and thereby the PC to avoid noise and ground issues.
An external clock source is of course a standard feature of this design. Since this was always the plan, I have not included on-board oscillators for the audio clocks. But there are control signals to select the correct clock frequency and sample rate setting (if needed).
I expect prototypes of the PCB to be assembled within the next week or so.
An experienced SW developer is currently developing the firmware for the XMOS, including control for the attenuators etc.
The need for SW development and the issues with the PC driver made me go for an existing solution initially. But I have now developed an XMOS based design, which is tailor made for the Audio Analyzer. So one PCB will provide the interface between the USB and the I2S audio interface as well as an I2C control interface. The USB section is galvanically isolated from the USB and thereby the PC to avoid noise and ground issues.
An external clock source is of course a standard feature of this design. Since this was always the plan, I have not included on-board oscillators for the audio clocks. But there are control signals to select the correct clock frequency and sample rate setting (if needed).
I expect prototypes of the PCB to be assembled within the next week or so.
An experienced SW developer is currently developing the firmware for the XMOS, including control for the attenuators etc.
Hi Jens,
Are you willing to share the schematic for your PCB? I'm looking to integrate a similar solution for the usbstreamer but with flipflops clocked from a clean master clock but onto the DAC board (so that clock can be close to the DAC, less critical for the XMOS).
Or if you are not willing to divulge the schematic (which I assume is the case as you have not posted earlier), if I post what I think it should be can you give me some tips based on your experiences with the different versions you have developed?
Thanks.
Are you willing to share the schematic for your PCB? I'm looking to integrate a similar solution for the usbstreamer but with flipflops clocked from a clean master clock but onto the DAC board (so that clock can be close to the DAC, less critical for the XMOS).
Or if you are not willing to divulge the schematic (which I assume is the case as you have not posted earlier), if I post what I think it should be can you give me some tips based on your experiences with the different versions you have developed?
Thanks.
Jens,
Reason for the flip-flop is to clean up any jitter from the I2S output of the USBstreamer as well as jitter from the isolator (I'm using the Si86xx 150Mhz isolators).
Although the MCLK is the most sensitive to jitter (compared to the other I2S lines) and it will be clean on the DAC side as the clock source will be from the DAC (fed back to the USBstreamer via the isolator), the other I2S lines will be impacted by using the isolator scheme:
1) There is a propagation delay of 10nS + extra jitter from the isolator sending the MCLK back to the USBstreamer
2) any additional clocking delays from the USBstreamer when clocking out the I2S lines
3) Another propagation delay and additional jitter added to the I2S lines going through the isolator
So the idea of the flipflop is to clean up the delays and additional jitter from the I2S lines by reclocking the I2S lines with the original MCLK using a D Flip-Flop. You mention earlier in this thread that a flipflop to reclock the I2S lines isn't needed - can you elaborate on the reasons why?
Thanks.
Reason for the flip-flop is to clean up any jitter from the I2S output of the USBstreamer as well as jitter from the isolator (I'm using the Si86xx 150Mhz isolators).
Although the MCLK is the most sensitive to jitter (compared to the other I2S lines) and it will be clean on the DAC side as the clock source will be from the DAC (fed back to the USBstreamer via the isolator), the other I2S lines will be impacted by using the isolator scheme:
1) There is a propagation delay of 10nS + extra jitter from the isolator sending the MCLK back to the USBstreamer
2) any additional clocking delays from the USBstreamer when clocking out the I2S lines
3) Another propagation delay and additional jitter added to the I2S lines going through the isolator
So the idea of the flipflop is to clean up the delays and additional jitter from the I2S lines by reclocking the I2S lines with the original MCLK using a D Flip-Flop. You mention earlier in this thread that a flipflop to reclock the I2S lines isn't needed - can you elaborate on the reasons why?
Thanks.
OK, so the flip-flops are intended to remove the jitter from the I2S signals.
I think that most (perhaps all?) delta-sigma DAC's are insensitive to jitter on the I2S Signals, as long as the MCLK is clean.
An example, from the AK4490 data sheet: "The external clocks, which are required to operate the AK4490, are MCLK, BICK and LRCK. MCLK should be synchronized with LRCK but the phase is not critical. The MCLK is used to operate the digital interpolation filter and the delta-sigma modulator."
Similar descriptions can be found for e.g. TI DAC's.
For a DAC-only application the propagation delays are not critical, because the I2S signals will have almost the same delay and the phase relationship to the MCLK is not critical.
For an ADC application the delays can be a problem, especially at high sample rates.
Some DAC's, like R2R DAC's will be sensitive to jitter on the I2S clock and perhaps other signals as well. I don't have recent experience with R2R DAC's though.
Re-clocking the I2S signals will not hurt, as long as you make sure that the clock for the flip-flops has a proper timing related to the I2S signals, so that the setup and hold times are OK. If not, you will get errors.
I once tried reclocking the I2S signals going to a delta-sigma DAC, but I couldn't measure any difference in performance.
I think that most (perhaps all?) delta-sigma DAC's are insensitive to jitter on the I2S Signals, as long as the MCLK is clean.
An example, from the AK4490 data sheet: "The external clocks, which are required to operate the AK4490, are MCLK, BICK and LRCK. MCLK should be synchronized with LRCK but the phase is not critical. The MCLK is used to operate the digital interpolation filter and the delta-sigma modulator."
Similar descriptions can be found for e.g. TI DAC's.
For a DAC-only application the propagation delays are not critical, because the I2S signals will have almost the same delay and the phase relationship to the MCLK is not critical.
For an ADC application the delays can be a problem, especially at high sample rates.
Some DAC's, like R2R DAC's will be sensitive to jitter on the I2S clock and perhaps other signals as well. I don't have recent experience with R2R DAC's though.
Re-clocking the I2S signals will not hurt, as long as you make sure that the clock for the flip-flops has a proper timing related to the I2S signals, so that the setup and hold times are OK. If not, you will get errors.
I once tried reclocking the I2S signals going to a delta-sigma DAC, but I couldn't measure any difference in performance.
Thanks Jens for the informative answer. I wasn't aware of the insensitivity of jitter on I2S lines for delta-sigma DACs (I'm using a Ti PCM4104) and the datasheet indeed mentions keeping MCLK phase jitter low but no call out for the other I2S lines (hence OK). Propagation delays are also fine as MCLK is much faster than the other I2S clocks.
So I will skip the reclock and save some board space. It also makes this hack easy as it only needs the isolator. Thanks again for this informative thread.
So I will skip the reclock and save some board space. It also makes this hack easy as it only needs the isolator. Thanks again for this informative thread.
Hi, just some toughts...
The USBStreamer has an 13Mhz Citizen FFB oscillator. After datasheet it has 50ppm frquency stability, that means about -116dB phase noise.
An NDK2520SD e.g. has about -155dB. So, this is a huge difference!
So, what if when we simply change the oscillator on the Streamer? Does it makes sense?
The USBStreamer has an 13Mhz Citizen FFB oscillator. After datasheet it has 50ppm frquency stability, that means about -116dB phase noise.
An NDK2520SD e.g. has about -155dB. So, this is a huge difference!
So, what if when we simply change the oscillator on the Streamer? Does it makes sense?
I don't think it will make any difference.
The frequency stability is not directly related to the phase noise.
And the clock signal goes through a PLL, which adds a lot of jitter. Part of this is probably due to the low reference frequency used (300 Hz). Further jitter is added by the XMOS I/O's.
The frequency stability is not directly related to the phase noise.
And the clock signal goes through a PLL, which adds a lot of jitter. Part of this is probably due to the low reference frequency used (300 Hz). Further jitter is added by the XMOS I/O's.
Yeah but how are you connecting the source to the DAC and are the N DACs getting the same clock?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.