NDK
I have had some NDK oscillators measured by a colleague for phase noise down to 2 Hz. They handily beat the published spec for the CCHDs. They are a little hard to get hold of, except in large quantities, but there are ways... and I am told they vary enough to make measuring and sorting them worthwhile (I wonder about th CCHDs in this regard, but have not heard of anyone measuring them).
I have had some NDK oscillators measured by a colleague for phase noise down to 2 Hz. They handily beat the published spec for the CCHDs. They are a little hard to get hold of, except in large quantities, but there are ways... and I am told they vary enough to make measuring and sorting them worthwhile (I wonder about th CCHDs in this regard, but have not heard of anyone measuring them).
But then again if you already have Ian's FIFO this would make the 'cape' redundant and I reckon the FIFO is a better product for post processing. So for those who have an RPi and Ian's FIFO you practically have everything you need now for full sync operation onto ESS DACs. Plus VolumeIO, the convenience and performance is right in your hands now.
But the 'BBB Cape' can have other advantages (apart from being a compact add-on) that Russ could explain to us.
Sorry, I didn't mean to cast aspersions but I am just commenting from a technical point of view. Hope I can be proven wrong
Acko,you put me doubt,the FIFO does not make the BBB bitperfect?you mean the FIFO makes a source I2S no bitperfect -bitperfect,because of its resampling.
Last edited:
Hi,
I would expect that the cape does not re-clock but instead replace the onboard clock of the BBB itself so there is no need for re-clocking.
The Wave IO does re-clocking (and conversion from USB to I2S) and I find this not better sounding than a Raspberry Pi I2S output. So I guess re-clocking is not a fix all for a bad source clock.
Russ, can you elaborate on the way the cape clocks will function?
Regards,
XMOS
The Wave IO clocks the XMOS chip, but, developers have found that while the XMOS operates asynchronously from the USB input stream, it still does not output a low jitter I2S feed.
the best XMOS based USB interfaces actually re-clock the I2S after the output of the XMOS chip. Because there is no long term jitter (same master clock is in command) this re-clocking can be done via a very small buffer (FIFO).
So Wave IO does not really re-clock, Lorien's add on daughter board will do this, or one could add Ian's FIFO, but wave IO alone is going to have fairly high jitter as it is the output from the XMOS.
The Wave IO clocks the XMOS chip, but, developers have found that while the XMOS operates asynchronously from the USB input stream, it still does not output a low jitter I2S feed.
the best XMOS based USB interfaces actually re-clock the I2S after the output of the XMOS chip. Because there is no long term jitter (same master clock is in command) this re-clocking can be done via a very small buffer (FIFO).
So Wave IO does not really re-clock, Lorien's add on daughter board will do this, or one could add Ian's FIFO, but wave IO alone is going to have fairly high jitter as it is the output from the XMOS.
Before I answer this just wanted to know if this is an open project where contribution or comments for software and hardware are welcome from other parties?
The...
right, and I said that in my response. The problem is that while XMOS re-clocks relative to the incoming USB stream (it re-clocks to the masterclock feed one gives it), the I2S output from the XMOS chip is still jittered at a fairly high rate. Most folks who are doing really good XMOS based USB interfaces have realized this, and they end up re-aligning the data after the XMOS chip with the master clock again. This what Lorien is doing with his new daughter board add on to the Wave IO, this is what I am doing with the USB interface I am involved with, and it is also what Joro does on his USB interface.
If you just use the straight I2S feed from the XMOS as is, it has a lot of jitter.
As Xmos works asynchronously it effectively re-clocks
right, and I said that in my response. The problem is that while XMOS re-clocks relative to the incoming USB stream (it re-clocks to the masterclock feed one gives it), the I2S output from the XMOS chip is still jittered at a fairly high rate. Most folks who are doing really good XMOS based USB interfaces have realized this, and they end up re-aligning the data after the XMOS chip with the master clock again. This what Lorien is doing with his new daughter board add on to the Wave IO, this is what I am doing with the USB interface I am involved with, and it is also what Joro does on his USB interface.
If you just use the straight I2S feed from the XMOS as is, it has a lot of jitter.
Barrows and GLT,
The data on the diyinhk site looks promising. I would hope that we wouldn't have to sort for phase noise as the setup to do so is far from trivial. It's a shame that, as with so many Japanese products, there is so little detail in the datasheet and one is left to (1) characterize for oneself and (2) trust on consistency of un-spec'ed parameters. It's curious that he phase noise plot on the diyinhk web site, supposedly from the NDK web site, isn't actually in their datasheet. On the positive side, my experience with NDK in a previous life was very good, at least for 100kHz crystal bandpass filters.
The data on the diyinhk site looks promising. I would hope that we wouldn't have to sort for phase noise as the setup to do so is far from trivial. It's a shame that, as with so many Japanese products, there is so little detail in the datasheet and one is left to (1) characterize for oneself and (2) trust on consistency of un-spec'ed parameters. It's curious that he phase noise plot on the diyinhk web site, supposedly from the NDK web site, isn't actually in their datasheet. On the positive side, my experience with NDK in a previous life was very good, at least for 100kHz crystal bandpass filters.
There will be no need to reclock after the "Botic" cape. Everything will be perfectly aligned with the master clocks.
As for the design goals, they have already been laid out. The idea is an ideal source - for relatively very little cost.
I am currently looking at designing this in two stages.
Botic version 1.0 with just the features described already:
1) I2S(up to 8 channel)/DSD (up to 4 channel) output mapped for easy input to B3 and BSSE.
2) All audio signals synchronously reclocked to the master clocks - no jitter from McASP.
3) Terminal for external power of the cape - and optionally the BBB as well (they can be powered seperately)
4) Access to all P9 signals for I2C etc.
This will give us a great starting point.
Soon after I plan to update (after we have solidified drivers and all I/O) with bi-directional isolation between the clocks and DAC and the BBB for audio and I2C.
What I hope to do is to get something in the hands of users sooner rather than later, so that the community can give feedback right away - thus improving the next edition.
Brian and I are open the idea of other clocks, especially seeing as board space is a premium.
Cheers!
Russ
As for the design goals, they have already been laid out. The idea is an ideal source - for relatively very little cost.
I am currently looking at designing this in two stages.
Botic version 1.0 with just the features described already:
1) I2S(up to 8 channel)/DSD (up to 4 channel) output mapped for easy input to B3 and BSSE.
2) All audio signals synchronously reclocked to the master clocks - no jitter from McASP.
3) Terminal for external power of the cape - and optionally the BBB as well (they can be powered seperately)
4) Access to all P9 signals for I2C etc.
This will give us a great starting point.
Soon after I plan to update (after we have solidified drivers and all I/O) with bi-directional isolation between the clocks and DAC and the BBB for audio and I2C.
What I hope to do is to get something in the hands of users sooner rather than later, so that the community can give feedback right away - thus improving the next edition.
Brian and I are open the idea of other clocks, especially seeing as board space is a premium.
Cheers!
Russ
Hey Russ,
Just a quick question, for the early adopters how hard will it be to update to the revision if any is required? I know it is impossible to say right now, but just figure I'll throw that out as well, looking forward to this, way beyond my skillset!
Kudos for the efforts!
Chuz,
Drew.
Just a quick question, for the early adopters how hard will it be to update to the revision if any is required? I know it is impossible to say right now, but just figure I'll throw that out as well, looking forward to this, way beyond my skillset!
Kudos for the efforts!
Chuz,
Drew.
I am envisioning the first version being very "prototypish" the next version being very much more polished. So likely you would just want to pick up the new cape - updating the old one may not be practical - still many may never find the need to update.
We are going to do our best to keep the costs reasonable, this is another reason I am open to looking at other clocks (like the NDK)
We are going to do our best to keep the costs reasonable, this is another reason I am open to looking at other clocks (like the NDK)
yup
Testing for phase noise is not trivial. I am aware of this, my colleague does have the required gear and knowledge to do so, and has tested and sorted a lot of NDK oscillators. Unfortunately, not all of them are really good. This makes me wonder if Crystek also has similar variances, unless one measures, one does not really know.
Some of the "reject" NDKs are no better than a run of the mill Expresso, so there you have it.
Testing for phase noise is not trivial. I am aware of this, my colleague does have the required gear and knowledge to do so, and has tested and sorted a lot of NDK oscillators. Unfortunately, not all of them are really good. This makes me wonder if Crystek also has similar variances, unless one measures, one does not really know.
Some of the "reject" NDKs are no better than a run of the mill Expresso, so there you have it.
1) B2 also, at least for 2 channel I2S?
3) I still love the idea of regulator mount points for Trident-style regs, at least for the clocks!
And all this with the bi-directional isolation would make a GREAT & inexpensive source.
Greg in Mississippi
Yes - B2 and even Opus/COD will work fine.
Probably will not do (at least initially) Trident style reg header because we need some power management that would not be so simple with a potentially unknown remote reg like that. Do things wrong - and you kill the BBB.
Besides that we chose a local reg that is pretty near impossible to beat for the application.
Probably will not do (at least initially) Trident style reg header because we need some power management that would not be so simple with a potentially unknown remote reg like that. Do things wrong - and you kill the BBB.
Besides that we chose a local reg that is pretty near impossible to beat for the application.
Relieved to hear thus Russ. I was getting concerned around potential costs especially with mention of the Crystek oscillators which I know are expensive.
Difficult being on a budget yet still wishing for high end but I imagine, especially as a community of DIYers, many others are in the same boat.
Fantastic stuff, looking forward to the results of your labours.
Hi Russ,
I think you may have mentioned this much earlier in the thread but do you intend to include a header for a Teleporter?
Cheers
Steve
I think you may have mentioned this much earlier in the thread but do you intend to include a header for a Teleporter?
Cheers
Steve
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.