Basically I am putting out an open call for suggestions for corrections and improvements to the batch of boards I am working on.
Essentially: where you foresee problems, egregious errors, things I overlooked etc.
I'm not too worried about the firmware aspect of the board, that's mostly written and well there is always ways to fix that! Mostly I'm looking for areas where I could have messed up: Trace widths, Introducing Noise, Potential for cross-talk, hardware level problems.
I just want to make sure this stage is done before I fret anymore about writing firmware for a board I don't have yet.
http://www.xcore.com/projects/mad-scien ... -interface Project Link.
Mad Scientist Audio Interface
-
- Member
- Posts: 14
- Joined: Sat Nov 10, 2012 6:08 am
-
- XCore Expert
- Posts: 970
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Any chance of some PDFs?
-
- Member
- Posts: 14
- Joined: Sat Nov 10, 2012 6:08 am
Well I am not quite sure what you want pdfs of but here are a slew of them;
Schematics for boards and Datasheets for ADC and DAC and Clock.
Schematics for boards and Datasheets for ADC and DAC and Clock.
You do not have the required permissions to view the files attached to this post.
-
- Respected Member
- Posts: 259
- Joined: Thu Sep 16, 2010 9:15 am
I have a couple of comments...
schematics: have a look at XMOS' schematics and try to draw them in a simmiar way. don't cram the components together, and avoid diagonal wires. You already divided in functional blocks. Use the space. And don't use juntions to symbol a port. You have the ports there, connect the wires to them.
Board: Avoid unnecessarily thing traces.
L2: Unless you plan to send the boards to manufacture, you may be well served with two L1-TQFP 64 or 48 that can be easily soldered by hand. You are anyway not using all pins...
Are you planning SPDIF Ins and Outs ?
schematics: have a look at XMOS' schematics and try to draw them in a simmiar way. don't cram the components together, and avoid diagonal wires. You already divided in functional blocks. Use the space. And don't use juntions to symbol a port. You have the ports there, connect the wires to them.
Board: Avoid unnecessarily thing traces.
L2: Unless you plan to send the boards to manufacture, you may be well served with two L1-TQFP 64 or 48 that can be easily soldered by hand. You are anyway not using all pins...
Are you planning SPDIF Ins and Outs ?
-
- XCore Expert
- Posts: 970
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Have you considered using the CS2100 (with external reference)? We find the output jitter to be much smaller than the CS2300 (The CS2100 is what we now recommend)
-
- Member
- Posts: 14
- Joined: Sat Nov 10, 2012 6:08 am
Explicate. Specifics are better.ale500 wrote: Board: Avoid unnecessarily thing traces.
I would except i wasn't planning on doing any real hand soldering other than the jacks and ports.ale500 wrote: L2: Unless you plan to send the boards to manufacture, you may be well served with two L1-TQFP 64 or 48 that can be easily soldered by hand. You are anyway not using all pins...
I was instead and will Have a Solderpaste mask template cut and use a bed of sand in a Hotplate skillet to reflow the components actually. and while a bit risky -- meticulous placement of the L2 should have it right itself when the solder reflows.
No, never planned on this as a stereo system component.ale500 wrote: Are you planning SPDIF Ins and Outs ?
I might perhaps draw up an XLR variant.
This was more working on DJ/Producer style of Audio Interface.
-
- Member
- Posts: 14
- Joined: Sat Nov 10, 2012 6:08 am
I had not, but I will now and will probably re-work as a revision.Ross wrote:Have you considered using the CS2100 (with external reference)? We find the output jitter to be much smaller than the CS2300 (The CS2100 is what we now recommend)
** I have now started working on Ironing out putting that in, where Can I find the software control of the clock and such. In the USB 2.0 Multichannel SDK there was control for the 2300, is there equivalent for the 2100?
-
- XCore Expert
- Posts: 970
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
The setup/control is exactly the same.CivilDecline wrote:I had not, but I will now and will probably re-work as a revision.Ross wrote:Have you considered using the CS2100 (with external reference)? We find the output jitter to be much smaller than the CS2300 (The CS2100 is what we now recommend)
** I have now started working on Ironing out putting that in, where Can I find the software control of the clock and such. In the USB 2.0 Multichannel SDK there was control for the 2300, is there equivalent for the 2100?
Edit: Just read your post re: S/PDIF input, if you have no digital streams to sync to I would advise using fixed local oscillators. We only use the clock multiplier so we can lock to an incoming digital stream (e.g. ADAT or S/PDIF). I would take a look at the clocking on the L1 board.
-
- Member
- Posts: 14
- Joined: Sat Nov 10, 2012 6:08 am
Awesome.Ross wrote: The setup/control is exactly the same.
its for changing bitrates between 44.1 and 48 families of sample ratesRoss wrote: Edit: Just read your post re: S/PDIF input, if you have no digital streams to sync to I would advise using fixed local oscillators. We only use the clock multiplier so we can lock to an incoming digital stream (e.g. ADAT or S/PDIF). I would take a look at the clocking on the L1 board.
(i think unless your referencing something else)
-
- XCore Expert
- Posts: 970
- Joined: Thu Dec 10, 2009 9:20 pm
- Location: Bristol, UK
Okay, you don't need a clock-multiplier to do that, just two different master clock sources (say two oscillators with a software controlled switch). We just use this multiplier when we want to lock to a external digital stream (the reference given to the clock multiplier from the XCore is derived from the stream).CivilDecline wrote:Awesome.Ross wrote: The setup/control is exactly the same.
its for changing bitrates between 44.1 and 48 families of sample ratesRoss wrote: Edit: Just read your post re: S/PDIF input, if you have no digital streams to sync to I would advise using fixed local oscillators. We only use the clock multiplier so we can lock to an incoming digital stream (e.g. ADAT or S/PDIF). I would take a look at the clocking on the L1 board.
(i think unless your referencing something else)
You will get better performance, lower BOM and use less MIPS (since you wont have to generate this reference to the clock multiplier) if you use fixed master clocks (e.g. oscillators).
You could, of course, use an audio clock generator also to generate these fixed master clock frequencies.